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