Revert "h264parse: Include `interlace-mode` in caps"
authorVivia Nikolaidou <vivia@ahiru.eu>
Thu, 18 Jun 2020 18:21:26 +0000 (21:21 +0300)
committerSebastian Dröge <slomo@coaxion.net>
Mon, 22 Jun 2020 16:08:41 +0000 (16:08 +0000)
commit652773de366a98e155332bf8ffb83ee5e6bea9e5
tree7464f9ef0f1fd61826660dbb354ef99a8bde5eed
parent863c663b1d54e64da27bae01ae32aec4a476ec03
Revert "h264parse: Include `interlace-mode` in caps"

This reverts commit b75a61342f4ea039d922a966f36b02cd9d9c3ad8.

The parser would only set the mode to progressive or mixed, missing the
cases where it should have been interleaved. Interleaved is more
difficult to detect because in h264 it happens per frame. On the other
hand, h264 decoders detect the interlacing information per-frame and set
the caps correctly. By giving potentially incorrect interlacing
information in the parser already, it's being enforced downstream even
after decoding, breaking some use cases (e.g. an encoder can't properly
mark the stream as TFF or BFF). On the other hand, there's no valid use
case for having interlacing information on the caps at the parsing
stage, so after a lot of discussion, it was decided to revert this.

Initial commit message:
=========================
Those are the rules:

In the SPS:
  * if frame_mbs_only_flag=1 => all frame progressive
  * if frame_mbs_only_flag=0 => field_pic_flag defines if each frame is
    progressive or interlaced, thus the mode is 'mixed' in GStreamer
    terms.

https://bugzilla.gnome.org/show_bug.cgi?id=779309
=========================

Fixes #1313

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1335>
gst/videoparsers/gsth264parse.c