[FFmpeg-devel] [Uncompressed MP4] RFC - Draft Encoder

[Devon Sookhoo]

Sounds good, I'll look into adding rawvideo to the list of movcodec_tags.

Looking at the AVPixFmtDescriptor, I noticed: AVComponentDescriptor
comp[4]; Does this line limit the component count to only four? Encoding
video with many components is an important use case.

Yes, there are various interleave_types defined in the spec. Hopefully, a
satisfactory solution for these can eventually be found to handle them all.

Complex pixels are used in applications that involve both amplitude and
phase information, particularly in signal processing and imaging techniques
where the Fourier transform is frequently applied. Examples include
Synthetic Aperture Radar (SAR), MRI scans, and radio astronomy.



On Wed, Oct 9, 2024 at 1:32 PM Tomas Härdin <git at haerdin.se> wrote:

> ons 2024-10-09 klockan 07:38 -0600 skrev Devon Sookhoo:
> > With this patch, I was able to use the following command to generate
> > an
> > uncompressed mp4:
> > $ ffmpeg  -i input.mp4   -c:v rawvideo   -pix_fmt rgb24   -tag:v uncv
> >  out.mp4
> >
> > The output file successfully played in GPAC.
> >
> > My first question is whether to reuse the existing
> > AV_CODEC_ID_RAWVIDEO, or
> > if a brand new codec should be created specifically for handling
> > uncompressed MP4 files. For those not familiar with ISO/IEC 23001-
> > 17:2024,
> > this uncompressed codec has many input parameters, making it
> > configurable
> > enough to handle just about any type of data. A complete
> > implementation would be quite involved which is why I'm questioning
> > if
> > "-c:v rawvideo" is the correct choice.
>
> You should add rawvideo to the list of mov codec_tags. That way you
> don't have to specify -tag:v
>
> From a quick glance at the spec it looks like you should be able to
> derive the ComponentDefinitionBox from the pixel format descriptor for
> whole classes of pixel formats, a task the belongs in the muxer (and
> demuxer). There isn't really anything for an encoder to "do".
>
> I see that the spec allows a bunch of different FrameLayouts to use MXF
> parlance, or interleave_type in this spec. The issue of how to deal
> with for example SEPARATE_FIELDS vs MIXED_FIELDS has been brought up
> and, as I recall, no satisfactory solution was found.
>
> I also see complex valued pixel formats are supported. Not sure what
> the use of that is, but it certainly is interesting..
>
> /Tomas
> _______________________________________________
> 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".
>