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