Hello Martin, I work with various scientific communities that have adopted the ISO BMFF architecture, which includes the MP4 and HEIF file formats. Historically, whenever an application required the use of uncompressed data, it was a "wild west" of file formats, with no shortage of proprietary options which has lead to interoperability issues across communities. The release of ISO/IEC 23001-17 is exciting because it enables users to leverage uncompressed capabilities while continuing to use the common MP4 file format. Even though ISO/IEC 23001-17:2024 was just released this year, it has already gained significant momentum and will likely become the de facto general-purpose option for uncompressed media, given that it was developed and is maintained by an accredited international standards organization.
Thanks, Devon Sookhoo On Tue, Sep 24, 2024 at 4:49 PM martin schitter <ms+...@mur.at> wrote: > > > On 23.09.24 16:36, Devon Sookhoo wrote: > > I'm interested in implementing uncompressed MP4 parsing according to the > > newly released ISO/IEC 23001-17:2024. Would anyone be interested in > further > > discussing this with me? > > As you have most likely already seen I've worked on a rather similar > project recently: DNxUncompressed / SMPTE RDD 50 support. > > This format seems to provide very similar capabilities, but it's already > supported by most commercial closed source high-end video production > solutions today. > > Both formats are in fact very inefficient and bandwidth wasting ways of > storage and information exchange. Nevertheless, they are often the only > workaround to somehow "pipe" closed source black boxes with the "free" > world of more customizable infrastructure and computing facilities. > > Right now I've just implemented a very basic CPU based decoder, which > supports at least most of DaVinci Resolve DNxUncompressed export > variants. It's more a side-product enabling experiments with rather > uncommon software integration approaches. > > Unfortunately I'm not an experienced ffmpeg developer, increasingly > prefer to write code in rust over C and also enjoy the comfort of GitLab > based CI/CD development workflows most of the time. That's why my > contribution resp. the never-ending list of requested modifications here > on the list feels more like a very strange adventure trip back into the > wild jungle than efficient development work and exchange of efforts. ;) > > But it was an impressive experience and a necessary first step to get > closer to some practical insight concerning my main project. I still > have to contemplate about desirable optimizations, which are required > for huge uncompressed data exchange, examine more real world testing and > profiling, and perhaps even experiment with shader based concurrent > decoding alternatives, but this present implementation is at least a > starting point. > > It would be nice if you could tell us more about your specific interest > in this other very similar format resp. its real world application. > > Martin > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
