[FFmpeg-devel] RFC - Uncompressed MP4

[martin schitter]

On 04.10.24 15:11, Devon Sookhoo wrote:
> You're correct that I'm primarily interested in uncompressed data and not
> raw bayer sensor data. 

Yes -- it was more a rather extreme example to remind, that this file 
format isn't as simple and limited as many old and simple AV packaging 
solutions for uncompressed pixel data. This opens interesting new 
applications, but it also comes with lots of complex management and 
configuration demands.

> However, it seems like the  "-c:v rawvideo"  option
> is the convention in other formats to generate uncompressed video data. 

No -- I think, in the context of ffmpeg "rawvideo" is just used for 
io-data streams, files and pipes, which are not packed in any mediating 
container format. In this case you just get a "raw" stream of bytes 
without any information about the used format.

ISO/IEC 23001-17:2024 stands for the strict opposite: a way to precisely 
describe lots of possible variants of utilized image data pixel format 
and bit-packaging options.

> I'm
> just trying to follow the pattern and reuse what is already there. If there
> is a better option, then please suggest one.

Perhaps you should start by implementing the decoder side first.
That's at least the strategy, that I've chosen in case of 
DNxUncompressed to reduce complexity and concentrate on those aspects, 
which are essential for exchange with existing end user software resp. 
already existing implementations of this file format.

On the decoder side you also do not need any configuration options, 
because everything is already defined by the given input file, but it 
will nevertheless give you a vague orientation, what's really relevant 
for your own encoding design resp. some insight, which subset of the 
specification is actually used by others and required for compatibility 
and real world data exchange.

> If ISO/IEC 23001-17:2024 requires its own .c file, then perhaps that
> filename should use the term "uncompressed" instead of "raw". For example,
> mpeg_unc_enc.c

Yes -- although it's "uncompressed" and it's processing not much more 
than just trivial bit and byte juggling of unmodified pixel data, you 
will still have to implement specific codecs and package parsers for 
this particular file format to support the actual embedding within the 
surrounding containers.

martin