Re: [FFmpeg-devel] avformat/mxfenc: fix stored/sampled/displayed width/height

From: Jerome Martinez <jerome@mediaarea.net>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] avformat/mxfenc: fix stored/sampled/displayed width/height
Date: Mon, 16 Jan 2023 15:28:50 +0100
Message-ID: <1e94dee6-7418-1daa-f579-d8af025c0aa8@mediaarea.net> (raw)
In-Reply-To: <5af8e03ddf331c24e40e42bff8fec71baab466d7.camel@haerdin.se>

On 16/01/2023 14:50, Tomas Härdin wrote:
> lör 2023-01-14 klockan 16:48 +0100 skrev Jerome Martinez:
>> Before the patch:
>> - stored values were rounded to upper 16 multiple also for formats
>> not
>> using macroblocks (should be st->codecpar->width and
>> st->codecpar->height when not MPEG formats; note that I found no
>> other
>> muxer doing the rounding for AVC, only for MPEG-2 Video, but I find
>> no
>> reason in specs for doing the difference so I kept the rounding for
>> AVC)
>> - sampled and displayed widths were stored width (should be
>> st->codecpar->width like it is already done for height, with the
>> DV50/100 exception)
> Another option might be to omit these values for non-macroblock codecs.

I planned to send a patch for removing all redundant information 
(sampled width/height is stored width/height by default etc), but as it 
is changing the current behavior of FFmpeg so can be more controversial 
I preferred to have it in a different patch.
After this patch it would be only a bunch of "if (sampled!=stored)" 
additions.
Would it be fine to do that separately?

> There is also potentially one use-value: when remuxing BMP to MXF it
> may be necessary to deal with BMP's 16-bit alignment. I'm not sure if
> this happens in the wild, and we certainly don't support muxing it.

I don't get what I should change in the patch for that, AFAIK I don't 
touch stuff around that.

> Another very close reading of the spec seems appropriate.

Tried to do so, as well as checking the other files I have from other 
muxers.
When I don't get the difference between what is in specs and FFmpeg or 
other muxer behavior, I let current FFmpeg behavior untouched.

Jérôme
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".