[vlc-devel] [PATCH 3/7] video_format: add a interlaced flag in the video format

[Steve Lhomme]

On 2020-11-09 12:27, Rémi Denis-Courmont wrote:
> Le maanantaina 9. marraskuuta 2020, 9.47.26 EET Steve Lhomme a écrit :
>> It is currently designed for a pull system. This existing code doesn't
>> even deinterlace the first interlaced frame. So I don't think the
>> current design should tell us how it should be done in pull model.
> 
> You mean push model? I don't particularly like the current system. The
> structure belongs in picture_t at least in the case that one picture_t is one
> field. I agree however that the interlacing could be notionally in the video
> format.
> 
> Still, the patch looks like the worse of both worlds. On one hand, we lose the
> flexibility to change the interlacing parameter per picture, and on the other

Not really. The video_format_t is still attached to the picture. But 
switching to push for interlacing means each source of interlaced 
content will need to push the format change. This is what patches 4 and 
5 do. They always change the value before a decoder_UpdateXXX.

> hand, we don't seem to gain the ability to pass interlacing infos from the
> demuxer (which is why it's broken in V4L at the moment).

We do. More than before at least since the demuxer can set whatever 
value it wants in the video_format_t of each es_format. The decoder 
might overwrite this value if it detects some interlacing. So just like 
colorimetry parameters we could allow an UNDEFINED value (rather than 
just a boolean) and set the value when it's not known/forced.

In Matroska it's possible to set the interlacing info in the container, 
for raw content. So having the possibility to set it out the demuxer 
output could be useful as well.

In the case of interlaced HEVC the decoder (lavc, nvdec) don't see it at 
all. But the packetizer can set the value (that's further in my work 
branch).