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

[Nicolas Gaullier <nicolas.gaullier@cji.paris>]

>>> The width is one thing; for whatever reason, there is a divergence between DV100 on one hand and AVCI/XDCAMHD35 on the other. In my understanding, in current practices, DV obey s337 (stored width includes scaling) but >xdcam&avci does not, so current code is fine >but maybe this is an opportunity to document this ?
>>
>>AFAIK:
>>- DV in MXF: found old Omneon with no scaling for stored value, no sampled value (so stored value), scaled value for displayed value, old Quantel with scaling everywhere. From my understanding of spec, I would keep the scaling.
>>- MPEG-2 Video including XDCAMHD35 in MXF obey "including any decoder 
>>scaling or padding" wording with a 16x16 rounding for height, I have no 
>>file not 1920 or 3840 width
>>- AVC in MXF: found old Omneon or old Quantel  or old Telestream with no padding value for stored value (height of 540 for interlaced). I don't understand why it is not same as with MPEG-2 Video so I don't touch FFmpeg behavior >there (rounding). Actually checking >again SMPTE ST 381-2013, there is an explicit example: "1088: 1080-line progressive".
>
>I totally agree they are so many weird things in the wild, particularly looking at some early implementations. I also have fully broken DV100 and XDCAMHD35 Omneon records with release v6.1 (2010) at the early stages of HD, but it was fixed afterwards (with many other >issues too!). Looking at GVG, 1440x1088i stored size was implemented from the early beginnings (2010 too) : sample clips are still available here : http://www.gvgdevelopers.com/concrete/products/k2/test_clips/
>There is also "kind of" reference sony implementation available here both for xdcamhd35/avc-1440:  https://www.sonycreativesoftware.com/catalystbrowse
>Anyway, I think we all agree not to change anything related to MPEG2 and AVC.
>
>>I don't have DV in MXF with non multiple of 16 (I thought that DV is 
>>only 720x576 or 720x480 or 1280x720 or 1920x1080, all values multiple of
>>16) and don't know about video encoding in DV so I didn't want to change the behavior of FFmpeg when I don't know, but case AV_CODEC_ID_DVVIDEO:
>>line could be definitely removed if it is fine for you.
>DV is questionable. Currently, the dust is under the rug (as a defaults behaviour), which is an issue with very little concern.
>Now, with the patch, the dust become visible, the DV rule is made explicit and moreover it is presented as an exception, sharing code with macroblock codecs... I think it is time to fix, even if it was not your prior intention.
>I don't have an extensive experience with DV too, I just have samples here and there like you, but it seems we share the same information.
>Let see if someone else react and ask for keeping the current 1088 lines for DV stored height, but if nobody does, I think it should be okay.
>
>> Do you want me to add a comment line e.g. "obey 'including any decoder scaling or padding' from SMPTE ST 377"?
>I am not a core developer and will let others give their feedback. My personal opinion is that the spec is supposed to be well known and does not require commenting, but that it would be interesting to explicit why we make a difference between DV and MPEG2/AVC. And >personally, I don't have the answer to this question. If nobody has one, maybe a comment could say "because this is the observed common practice".
>
>Nicolas

Some weeks later now and no replies, maybe time to go on ?
I think the "case AV_CODEC_ID_DVVIDEO:" can be removed as discussed, fate updated and that should be ok for everybody.
(Ideally, it could have been an opportunity to document why we have this "DV exception", but I understand it is not very comfortable to write as there is no meaningful reason, so forget about this, this won't hold up the patch anyway)
For information, there was a long thread recently on ffmpeg-user about a "bug" in dnxhd stored_height (will be fixed with your patch):
https://ffmpeg.org/pipermail/ffmpeg-user/2023-February/056111.html

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