Subject: [video-codec] Interlacing support

From: Filippov Alexey <[email-masked]>
Date: Wed, 8 Jul 2015 06:23:51 +0000

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

---

From: Thomas Daede <[email-masked]>
Date: Mon, 13 Jul 2015 14:35:41 -0700

On 07/07/2015 11:23 PM, Filippov Alexey wrote:
> 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.

Any blurring caused by the deinterlacer will also happen if the video is
encoded interlaced, it will just happen on the decoder side instead.

I agree that we should test this. We also need a way to compare the
quality of the two methods. Here is my suggested test:

original video -> deinterlacer
original video -> x265 -> deinterlacer
original video -> deinterlacer -> x265

All three will result in progressive output that can be compared with
standard metrics.