Open pkrae opened 3 months ago
Interlacement
is deprecated, out of topic.
We have ScanType
(Way in which lines of video are displayed) and ScanOrder
(Order in which lines are encoded).
MBAFF was not planned when the fields were defined.
MBAFF is something in between, partly progressive and partly interlaced. I agree that "Interlaced" could be a way to show that because in practice progressive parts are for compression optimization. Thinking more about it, maybe MBAFF should be in "Format settings" as a feature rather than scan type.
That said, I am reluctant to change that now for avoiding to break app which expect MBAFF at this place (bit is there any app expecting that and breaking if I change? I don't know), on another side it would be good to have something coherent...
I'll give myself a week to think about it.
Thanks for the quick reply and the explanation. From a technical perspective, I'd probably prefer to have ScanType representing the nature of the video which is either full frames (progressive) or field (half-)pictures (interlaced). MBAFF is just a coding tool specific to H.264 and also a strong indicator that the video is interlaced (although in theory even progressive content could be coded with MBAFF when POCs for both field pictures are the same). On the other hand, I understand if some people rely on MBAFF as legacy. Actually for my purpose, either solution is fine. If MBAFF remains an optional value for ScanType, I would adapt my application and translate it to 'Interlaced'. Let me know once you've decided. Thanks
My understanding is that
ScanType
is allowed to have one of two values,Progressive
orInterlaced
. Other details about the field arrangement or field order are inScanOrder
,ScanType_StoreMethod
andInterlacement
. However, if an AVC stream contains frames coded with MBAFF, theScanType
is set toMBAFF
(inFile_Avc::Streams_Fill()
). My expectation in this case would be thatScanType
is set toInterlaced
andInterlacement
toMBAFF
.