Dear Mr. Daede,
>I don't think we should support interlacing in the netvc bitstream. I bring
>this up because draft-filippov-netvc-requirements-01 still specifies some
>interlaced modes.
Sorry but your understanding of my document is incorrect. I included interlaced
modes into the table titled "IPTV: typical values of resolutions,
frame-rates..." because these formats are actually used by different companies
in practice. It is confirmed by Mr. Coppa from CBS in his comment ("a very
typical format for the typical content types noted is 1080i at 59.94 fields per
second (29.97 frames per second) and I suggest that this be added to Table 1 as
a typically delivered content type."). So, I guess it would be incorrect to
ignore a consumer request (I mean, for example, CBS that can potentially decide
to use a new netvc codec ) and exclude these formats from the list of input
sequences for testing a new codec. However, it doesn't mean that a codec has to
support tools like MBAFF or PAFF adopted for AVC/H.264. I agree that a common
way to avoid dealing with interlaced formats is to use a deinterlacer before
encoding. The main disadvantage of this approach is blurring caused by applying
a low-pass filter (deinterlacer) to an interlaced picture. So, it's necessary
to show that deinterlacing before encoding is better than using specific tools
inside the codec. If anyone has counterarguments, I'd like to hear them.
--
Best regards,
Alexey Filippov
_______________________________________________
video-codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/video-codec
