[FFmpeg-devel] RFC - Uncompressed MP4

[Devon Sookhoo]

I appreciate your feedback. Doing the decoder side first is a good
suggestion, I certainly want to start with whichever is easier. I
originally started with the encoder simply because of the limited number of
existing test files. However, I believe that GPAC is able to generate some.

I thought the option  "-c:v rawvideo"  was the way to go because it's used
to generate an uncompressed avi file:
$ ffmpeg -i input.mp4  -c:v rawvideo  out.avi

Is this an exception? If "-c:v rawvideo" isn't typically used to generate
uncompressed files, then what is?

On Fri, Oct 4, 2024 at 8:14 AM martin schitter <ms+git at mur.at> wrote:

>
>
> 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
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>