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>
}
if (G_UNLIKELY (modified || h264parse->update_caps)) {
- GstVideoInterlaceMode imode = GST_VIDEO_INTERLACE_MODE_PROGRESSIVE;
gint width, height;
GstClockTime latency = 0;
latency);
}
- /* upstream overrides or uses sps info */
- if (s && gst_structure_has_field (s, "interlace-mode"))
- imode =
- gst_video_interlace_mode_from_string (gst_structure_get_string (s,
- "interlace-mode"));
- else if (sps->frame_mbs_only_flag == 0)
- imode = GST_VIDEO_INTERLACE_MODE_MIXED;
-
- gst_caps_set_simple (caps, "interlace-mode", G_TYPE_STRING,
- gst_video_interlace_mode_to_string (imode), NULL);
-
bit_depth_chroma = sps->bit_depth_chroma_minus8 + 8;
switch (sps->chroma_format_idc) {