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
