[FFmpeg-devel] Uncompressed MP4

martin schitter ms+git at mur.at
Wed Sep 25 04:47:19 EEST 2024



On 25.09.24 01:34, Devon Sookhoo wrote:
> 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. 

Sure, a few simple old fashioned solutions were always around. But most 
of them only worked for a few 'classic' bit depths or didn't support 
synchronized AV, timing and metadata channels at all. Nevertheless I 
would simply say: before DNxUncompressed became widely accessible 
nothing similar/suitable was available for this kind of high-end demands.

And hopefully the MPEG Uncompressed format will indeed stay as free as 
this other SMPTE standardized alternative in the long run. As we all 
know, this wasn't always the case with MPEG efforts.

> 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. 

It's definitively an interesting solution. MP4/ISOBMFF could be a better 
base for use in streaming applications. That's a kind of utilization 
which is explicitly excluded in the offical description of MXF based 
DNxUncompressed files. But on the other hand hardly anybody will choose 
an utterly uncompressed video data format for streaming purposes. 
Although DNxUncompressed would be a slightly better candidate in this 
case, because its more dense bit-packed than this MP4 alternative.

> 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.

We'll see! :)

I wouldn't overestimate the practical usefulness and popularity of this 
kind of file formats. Beside a very few practical applications they are 
just extraordinary inefficient and bloated.

You also have to see the fact, that already existing commercial driven 
alternatives are simply distributed beside much more popular and 
practical useful compression formats in the same SDKs and DLLs by their 
vendors. That's often a more suitable way to gain popularity in case of 
exotic minority products than propagating standards just by marked 
shares and patent claims.

Martin


More information about the ffmpeg-devel mailing list