After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 687684 - gstavviddec doesn't set top field first and repeat field flags in some cases
gstavviddec doesn't set top field first and repeat field flags in some cases
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
1.0.2
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-05 19:59 UTC by Michael Rubinstein
Modified: 2018-11-03 12:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Rubinstein 2012-11-05 19:59:58 UTC
We're using avdec_mpeg2video to decode MPEG2 from a broadcast encoder.  All are content is interlaced.  We find that the "top field first" and "repeat first field" flags are not always set in the decoded buffers.

gstavviddec.c only sets GST_VIDEO_BUFFER_FLAG_TFF and GST_VIDEO_BUFFER_FLAG_RFF when it thinks that the content is interlaced.

The code in question is in gst_ffmpegviddec_video_frame().

  if (ffmpegdec->ctx_interlaced) {
    /* set interlaced flags */
    if (ffmpegdec->picture->repeat_pict)
      GST_BUFFER_FLAG_SET (out_frame->output_buffer, GST_VIDEO_BUFFER_FLAG_RFF);
    if (ffmpegdec->picture->top_field_first)
      GST_BUFFER_FLAG_SET (out_frame->output_buffer, GST_VIDEO_BUFFER_FLAG_TFF);
    if (ffmpegdec->picture->interlaced_frame)
      GST_BUFFER_FLAG_SET (out_frame->output_buffer,
          GST_VIDEO_BUFFER_FLAG_INTERLACED);
  }

The frames in question have these variables:

progressive_sequence=0
picture_structure=3 (Frame)
progressive_frame=1

The MPEG spec. says that TFF and RFF have meaning in this case.

mpegvideo.c contains this line:

 s->current_picture_ptr->f.interlaced_frame = !s->progressive_frame &&
                                                     !s->progressive_sequence;

Also, the above definition of interlaced causes our system to renegotiate frequently.

I'm not sure if these frames should be called "interlaced" but the flags should be set.  IMHO I don't think we should renegotiate.
Comment 1 Edward Hervey 2013-07-23 11:59:15 UTC
Michael, Could you provide a sample file that reproduces the behaviour ?
Comment 2 Michael Rubinstein 2013-07-23 13:07:38 UTC
Here's a transport stream that demonstrates the problem.
All the content is interlaced, some of it is in film mode.
There are two programs.  I use program 2.

https://app.box.com/s/i4n3gybgd8wo3vk5hiib
Comment 3 Tim-Philipp Müller 2018-01-25 12:35:04 UTC
I know it's been a while. Not quite sure what needs to be done here though.

With git master all output buffers have:

 - the INTERLACED flag set
 - the TFF flag unset (implying BFF)
 - the RFF flag unset

There is no caps renegotiation as far as I can tell.

You're saying this is not how it should be?

> We find that the "top field first" and "repeat first field"
> flags are not always set in the decoded buffers.

This sounds like you're saying it was inconsistent. Now it's consistent at least, but neither TFF nor RFF are ever set.
Comment 4 GStreamer system administrator 2018-11-03 12:55:47 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/8.