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