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