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 636279 - REGRESSION: Video often freezes during playback of mpeg2 files
REGRESSION: Video often freezes during playback of mpeg2 files
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal blocker
: 0.10.21
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-12-02 10:02 UTC by Vladimir Eremeev
Modified: 2011-06-20 12:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vladimir Eremeev 2010-12-02 10:02:39 UTC
I play files using 
$ gst-launch playbin2 uri=file:////path/to/file.mpg 

I'm getting lots of messages 

WARNING: from element /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage: A lot of buffers are being dropped.
Additional debug info:
gstbasesink.c(2699): gst_base_sink_is_too_late (): /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage:
There may be a timestamping problem, or this computer is too slow.

during freezes. Sound plays smoothly during freezes.

I use JHBuild with the latest changes from freedesktop git repository.

Tried playing the same file with the GStreamer packages installed from gstreamer-developers PPA, it plays fine.

Sample video can be found at http://dl.dropbox.com/u/11507187/F12811_cnn.mpg
Comment 1 Vladimir Eremeev 2010-12-02 10:03:34 UTC
Same thing on windows with the latest OSSBuild, which was synced with git several hours ago.
Comment 2 Tim-Philipp Müller 2010-12-02 10:07:39 UTC
> Sample video can be found at http://dl.dropbox.com/u/11507187/F12811_cnn.mpg

That gives me a 404 not found.
Comment 3 Vladimir Eremeev 2010-12-02 10:20:51 UTC
It's still uploading currently.
Dropbox client promises 10 minutes more.
Comment 4 Vladimir Eremeev 2010-12-02 10:32:52 UTC
Done, you can download the file.
Comment 5 Tim-Philipp Müller 2010-12-02 11:47:19 UTC
Works fine for me, with and without deinterlacing.

> Tried playing the same file with the GStreamer packages
> installed from gstreamer-developers PPA, it plays fine.

Could you specify the exact versions you got from the PPA?
Comment 6 Vladimir Eremeev 2010-12-02 12:24:08 UTC
gstreamer-tools - 0.10.30.5-1~lucid1
gstreamer-0.10-plugins-base - 0.10.30.5-2~lucid1
gstreamer-0.10-plugins-good - 0.10.25.5-1~lucid1
gstreamer-0.10-plugins-bad  - 0.10.20-2~lucid3
gstreamer-0.10-plugins-ugly - 0.10.16-1~lucid1

Other accompanying packages have similar version.

My system checks for updates every day, so I have most recent packages.
Comment 7 Tim-Philipp Müller 2010-12-02 12:43:27 UTC
Thanks, just checking you were in fact using the pre-releaes. This is a bit surprising, because the changes between the last pre-relases and the releases don't look particularly intrusive or relevant:


commit 7b312c5980f80b96afde55e3055d7b50a05693dc
Author: Stefan Kost <ensonic@users.sf.net>
Date:   Wed Nov 24 17:34:21 2010 +0200

    uridecodebin: disconnect signal handlers before disposing


commit b27d93a84a3f7c2474c91479a5554de0fa1b1a29
Author: David Schleef <ds@schleef.org>
Date:   Tue Nov 30 15:28:50 2010 -0800

    deinterlace: analyse RFF fields in correct order
    
    Code was repeating the second field, not the first.
    Fixes: #636179.

commit b6b0de0c49816c5acb5c9635b2fe8dd4d4dc5215
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Mon Nov 29 15:32:40 2010 +0100

    rtspsrc: handle stale digest authentication session data
    
    In particular, handle Unauthorized server response when trying to convey
    keep-alive.
    
    Fixes #635532.

commit e7b1655069fe2f03daf9e53b865bc110bd3c5131
Author: Thijs Vermeir <thijsvermeir@gmail.com>
Date:   Fri Nov 26 15:00:29 2010 +0100

    rtph264depay: fix segfault on empty payload
    
    https://bugzilla.gnome.org/show_bug.cgi?id=635843
Comment 8 Vladimir Eremeev 2010-12-02 12:55:13 UTC
I also think so.
Now I'm trying to roll back and check.
Comment 9 Vladimir Eremeev 2010-12-02 14:35:49 UTC
Have found that this bug is observed on all my OSSBuilds after 2010-11-11.
Logs show there was some manipulation with the streamsynchronizer on 17-11...
Comment 10 Vladimir Eremeev 2010-12-02 15:16:52 UTC
Have downloaded updates from PPA.
Again, plays fine.
Comment 11 Vladimir Eremeev 2010-12-02 16:23:45 UTC
Here are two excerpts from logs.
The ossbuild version of 03-11-2010

0:00:12.593750000  3204   0A6AB990 LOG                 mpeg2dec gstmpeg2dec.c:854:clip_buffer:<mpeg2dec0> timestamp:0:00:01.407300000 , duration:0:00:00.040000000
0:00:12.593750000  3204   0A6AB990 LOG                 mpeg2dec gstmpeg2dec.c:880:clip_buffer:<mpeg2dec0> not dropping
0:00:12.593750000  3204   0A6AB990 LOG                 mpeg2dec gstmpeg2dec.c:1037:handle_slice:<mpeg2dec0> pushing buffer 0A6BA218, timestamp 0:00:01.407300000, duration 0:00:00.040000000
0:00:12.593750000  3204   0A6AB990 LOG                 mpeg2dec gstmpeg2dec.c:1038:handle_slice:<mpeg2dec0> ... with flags 300
0:00:12.640625000  3204   0A79D650 DEBUG                GST_QOS gstbasesink.c:2760:gst_base_sink_do_render_stats:<videosink-actual-sink-d3dvideo> avg_render: 0:00:00.011326760
0:00:12.640625000  3204   0A79D650 DEBUG                GST_QOS gstbasesink.c:2562:gst_base_sink_perform_qos:<videosink-actual-sink-d3dvideo> start: 0:00:00.519988889, entered 0:00:00.501201814, left 0:00:00.519988889, pt: 0:00:00.021212925, duration 0:00:00.040000000,jitter -18787075
0:00:12.640625000  3204   0A79D650 DEBUG                GST_QOS gstbasesink.c:2567:gst_base_sink_perform_qos:<videosink-actual-sink-d3dvideo> avg_duration: 0:00:00.039997759, avg_pt: 0:00:00.014848474, avg_rate: 0.143256
0:00:12.640625000  3204   0A79D650 DEBUG                GST_QOS gstbasesink.c:2602:gst_base_sink_perform_qos:<videosink-actual-sink-d3dvideo> updated: avg_duration: 0:00:00.039998039, avg_pt: 0:00:00.015644030, avg_rate: 0.158747
0:00:12.640625000  3204   0A79D650 DEBUG                GST_QOS gstbasesink.c:2490:gst_base_sink_send_qos:<videosink-actual-sink-d3dvideo> qos: proportion: 0.158747, diff -18787075, timestamp 0:00:00.519988889


latest ossbuild version

0:00:02.546875000  2456   00B86AB8 LOG                 mpeg2dec gstmpeg2dec.c:1037:handle_slice:<mpeg2dec0> pushing buffer 00B97220, timestamp 0:00:01.407300000, duration 0:00:00.040000000
0:00:02.546875000  2456   00B86AB8 LOG                 mpeg2dec gstmpeg2dec.c:1038:handle_slice:<mpeg2dec0> ... with flags 300
0:00:02.562500000  2456   01B31EE8 DEBUG                GST_QOS gstbasesink.c:2760:gst_base_sink_do_render_stats:<videosink-actual-sink-d3dvideo> avg_render: 0:00:00.009012112
0:00:02.562500000  2456   01B31EE8 DEBUG                GST_QOS gstbasesink.c:2562:gst_base_sink_perform_qos:<videosink-actual-sink-d3dvideo> start: 0:00:00.519988889, entered 0:00:01.577641723, left 0:00:01.577641723, pt: 0:00:00.017652834, duration 0:00:00.040000000,jitter 1057652834
0:00:02.562500000  2456   01B31EE8 DEBUG                GST_QOS gstbasesink.c:2567:gst_base_sink_perform_qos:<videosink-actual-sink-d3dvideo> avg_duration: 0:00:00.039997759, avg_pt: 0:00:00.014220253, avg_rate: 0.12753
0:00:02.562500000  2456   01B31EE8 DEBUG                GST_QOS gstbasesink.c:2602:gst_base_sink_perform_qos:<videosink-actual-sink-d3dvideo> updated: avg_duration: 0:00:00.039998039, avg_pt: 0:00:00.014649325, avg_rate: 0.14245
0:00:02.562500000  2456   01B31EE8 DEBUG                GST_QOS gstbasesink.c:2490:gst_base_sink_send_qos:<videosink-actual-sink-d3dvideo> qos: proportion: 0.142450, diff 1057652834, timestamp 0:00:00.519988889
0:00:02.562500000  2456   01B31EE8 DEBUG                GST_QOS gstbasetransform.c:2674:gst_base_transform_update_qos:<vscale> qos: proportion: 0.142450, diff 1057652834, timestamp 0:00:00.519988889
0:00:02.562500000  2456   01B31EE8 DEBUG                GST_QOS gstbasetransform.c:2674:gst_base_transform_update_qos:<vconv> qos: proportion: 0.142450, diff 1057652834, timestamp 0:00:00.519988889

As can be seen, the same frame causes the jitter of -18787075 in one case and 1057652834 in another
Comment 12 Vladimir Eremeev 2010-12-02 19:24:01 UTC
I also have found that the bug exists in this revision: 
http://code.google.com/p/ossbuild/source/detail?r=926

But doesn't exist in the previous revision.
Comment 13 Tim-Philipp Müller 2010-12-02 19:37:13 UTC
Sounds like a regression in -bad then, moving..
Comment 14 Vladimir Eremeev 2010-12-03 07:27:20 UTC
The commit, caused the regression:

http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=2271608c4314d6d0a685c18c5c47d55495586159
Comment 15 Thijs Vermeir 2010-12-03 13:24:38 UTC
I think that the commit that is referred to triggers a bug. This stream is using the same time_code for every 2 GOP's. for example, the first GOP's have time_code:
17:46:35.000000000 and the next 2 have TS 17:46:36.000000000. Using the same time_code for another GOP doesn't look normal, but don't know yet if this is allowed in the stream or how to handle this...
Comment 16 Vladimir Eremeev 2010-12-03 13:55:23 UTC
GOPchop (http://outflux.net/unix/software/gopchop/) shows different codes for all GOPs, at least for the first 20.
Comment 17 Thijs Vermeir 2010-12-03 14:23:22 UTC
I tried this in gopchop and I see:
1 -> 17:46:34.09
2 -> 17:46:35.21
3 -> 17:46:35.08

So, yes in this tool they are different. But not increasing, which looks invalid...
Comment 18 Vladimir Eremeev 2010-12-03 15:56:08 UTC
Authors of the DVDlab reference some specification, saying that GOP time code is not necessary and can be invalid.

http://www.mediachance.com/dvdlab/Help/chapters_idx.htm
"Other problem with GOP timecode is that by specification it is not required to be present in the mpeg file, the file plays fine without it. Some encoders (very few actually) may not put the timecode, or the timecode may be totally wrong."

I don't know which specification they mean.

However, this file is real, and I have lots of similar ones.
Comment 19 Tim-Philipp Müller 2010-12-30 11:03:22 UTC
Not sure what to do with this for the release - revert for now? Thijs?
Comment 20 Thijs Vermeir 2011-01-04 09:41:27 UTC
Well, the problem is that I don't know how to create valid timestamps from invalid data in the stream. I also can't confirm that invalid GOP time code is accepted in the specifications.

Maybe providing how this files are generated can help to find a work around for this. As the time information in the stream is wrong, the time in the container should be right. Otherwhise I don't know how correct timestamps could be created.

The patch is solving a "real" problem with the specifications and triggering a bug from a unwritten "feature". Don't know what the (commit/revert) policy is in this case?
Comment 21 Tim-Philipp Müller 2011-01-04 10:58:56 UTC
mplayer plays this file fine. vlc plays this file fine. GStreamer with -bad 0.10.20 plays this file fine.

GStreamer with 0.10.21 doesn't play this file fine any longer, that's something we need to fix IMHO.

Correct me if I'm wrong, but whatever your patch fixes, was broken in the previous release as well, right? So maybe that's unfortunate, but causing playback regressions with a major format seems even more undesirable to me, regardless of the rights and wrongs and the spec.

Isn't there something we can do better here? How do mplayer/vlc handle this?
Comment 22 Tim-Philipp Müller 2011-01-07 19:07:53 UTC
Reverted this for the release:

commit e5f1cdd0e9362c14784c4e1e8c762623537af4c7
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Fri Jan 7 18:49:02 2011 +0000

    Revert "mpegvideoparse: fix timestamp generation"
    
    This reverts commit 2271608c4314d6d0a685c18c5c47d55495586159.
    
    This patch needs more work so it doesn't cause grave playback
    regressions (multi-second freezes) with some files that have
    slightly broken timestamps but play fine everywhere else.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=636279
    https://bugzilla.gnome.org/show_bug.cgi?id=632222


Original bug has been re-opened so closing this one.
Comment 23 Thijs Vermeir 2011-01-10 09:15:06 UTC
I don't want to close this just now because the problem is not solved, only moved.

(In reply to comment #21)
> mplayer plays this file fine. vlc plays this file fine. GStreamer with -bad
> 0.10.20 plays this file fine.

Because they don't look at the time-code, and push all buffers based on framerate.
Which is IMHO wrong.

> ... but causing
> playback regressions with a major format seems even more undesirable to me,
> regardless of the rights and wrongs and the spec.

AFAIK only this file is broken with the patch, and not the whole format.

I think it can help to get more information on this file and how it is created.
Comment 24 Vladimir Eremeev 2011-01-14 08:45:03 UTC
(In reply to comment #23)
> AFAIK only this file is broken with the patch, and not the whole format.
> I think it can help to get more information on this file and how it is created.

These files were created by remuxing MPEG-2 transport stream from DVB-S with the FFmpeg. 
I stress that this was remuxing, not re-encoding, i.e. command line parameters were -vcodec copy -acodec copy

FFmpeg doesn't touch GOP headers, therefore these data came from a satellite.
Unfortunately, I don't know neither the satellite, nor the provider.
Comment 25 Thijs Vermeir 2011-01-14 08:56:53 UTC
Ok, now we are there :-)

(In reply to comment #24)
> (In reply to comment #23)
> These files were created by remuxing MPEG-2 transport stream from DVB-S with
> the FFmpeg. 

In DVB-S streams the timing information is inside the transport stream. (We are testing here with similar DVB-S streams)

> FFmpeg doesn't touch GOP headers, therefore these data came from a satellite.
> Unfortunately, I don't know neither the satellite, nor the provider.

This means you dropped the timing information (from the TS) stream and didn't fix the timing information in the GOP headers. (which is wrong)

With this information I consider this files as not correct.
Comment 26 Sebastian Dröge (slomo) 2011-04-08 12:27:38 UTC
Let's close this then?
Comment 27 Vladimir Eremeev 2011-06-20 09:31:34 UTC
(In reply to comment #25)
> > FFmpeg doesn't touch GOP headers, therefore these data came from a satellite.
> > Unfortunately, I don't know neither the satellite, nor the provider.
> This means you dropped the timing information (from the TS) stream and didn't
> fix the timing information in the GOP headers. (which is wrong)

I'm not sure about GOP headers, seems FFmpeg doesn't touch them, indeed.

But it uses timing information in the TS to construct correct timestamps, so the first clause is invalid, timing information in the TS is not dropped.
Comment 28 Thijs Vermeir 2011-06-20 09:39:02 UTC
(In reply to comment #27)
> But it uses timing information in the TS to construct correct timestamps, so
> the first clause is invalid, timing information in the TS is not dropped.

Who is reconstructing correct timestamps? The stream is not a TS anymore, so reconstructing correct timestamps now is not possible anymore if the information is not saved in the GOP headers.
Comment 29 Vladimir Eremeev 2011-06-20 10:06:15 UTC
> Who is reconstructing correct timestamps? 
FFmpeg, or, more exactly, functions from its libraries libavformat, libavutil, etc.

> The stream is not a TS anymore, so
Right, but FFmpeg stores every access unit (a video frame or a batch of audio samples) in a separate structure AVPacket, which also carries all necessary information.

Its demuxing function av_read_frame() calls low-level functions that parse MPEG-2 TS, read PTS and DTS from TS headers, assemble PES packets from the transport packets and store their data bytes, timestamps, and all other information in the AVPacket exemplars.

These AVPackets are presented to the calling application. 
I have developed that application and it simply subtracts a constant from all timestamps to make them start from near 0.

High-level muxing functions (av_write_frame and av_interleaved_write_frame) use information, stored in the AVPacket to correctly mux packets they receive.

> reconstructing correct timestamps now is not possible anymore if the
> information is not saved in the GOP headers.

So, all timing information is stored and used, and everything is possible.
GOP headers are left intact, right.
Comment 30 Thijs Vermeir 2011-06-20 10:12:18 UTC
(In reply to comment #29)
> So, all timing information is stored and used, and everything is possible.
> GOP headers are left intact, right.

So where is this information stored in the current file?
Comment 31 Vladimir Eremeev 2011-06-20 10:57:25 UTC
(In reply to comment #30)
> (In reply to comment #29)
> > So, all timing information is stored and used, and everything is possible.
> > GOP headers are left intact, right.
> So where is this information stored in the current file?
As usual, in PES headers.
Comment 32 Vladimir Eremeev 2011-06-20 11:03:21 UTC
I should also mention, that GOP headers are stored among other data bytes in memory, pointed by AVPacket::data
Comment 33 Thijs Vermeir 2011-06-20 11:07:15 UTC
Can you make that file available again, looks like I lost it...
Comment 34 Vladimir Eremeev 2011-06-20 11:24:59 UTC
Sorry, I also have lost it.

Errm, to make sure, I'm correctly understood :)
GOP headers are left untouched, the same as they were in the incoming TS stream.
Comment 35 Vladimir Eremeev 2011-06-20 12:18:36 UTC
One more thing.
The "ISO/IEC 13818-2 Part 2" standard says that GOP time code is not used in the decoding process (in 6.1.1.7 and in 6.3.8). 
I think it is the artifact from the past.
Comment 36 Tim-Philipp Müller 2011-06-20 12:26:12 UTC
I still have the file, uploading it to http://people.freedesktop.org/~tpm/samples/636279-F12811_cnn.mpg (but might take a while until it's done).