GNOME Bugzilla – Bug 740045
gst-play-1.0 --gapless file1.mp4 file2.mp4 stops after first file
Last modified: 2018-11-03 11:32:42 UTC
Created attachment 290575 [details] The log files 1.2.4.log and 1.4.4.log The test mp4 files are http://cdn.clipcanvas.com/sample/clipcanvas_14348_offline.mp4 http://cdn.clipcanvas.com/sample/clipcanvas_14348_H264_640x360.mp4 In 1.4.4 it stops after first file GST_DEBUG=decodebin*:9,play*:9 gst-play-1.0 --gapless clipcanvas_14348_offline.mp4 clipcanvas_14348_H264_640x360.mp4 2>1.4.4.log Volume: 100% Now playing clipcanvas_14348_offline.mp4 Redistribute latency... About to finish, preparing next title: clipcanvas_14348_H264_640x360.mp4 Redistribute latency... ^C00:08.0 / 0:00:08.0 The same command works fine in 1.2.4 GST_DEBUG=decodebin*:9,play*:9 gst-play-1.0 --gapless clipcanvas_14348_offline.mp4 clipcanvas_14348_H264_640x360.mp4 2>1.2.4.log Now playing clipcanvas_14348_offline.mp4 Redistribute latency... About to finish, preparing next title: clipcanvas_14348_H264_640x360.mp4 Redistribute latency... 0:00:08.0 / 0:00:08.0 Reached end of play list.
This was introduced by https://bugzilla.gnome.org/show_bug.cgi?id=738064
The hang seems to be in streamsynchronizer, which waits indefinitely here: 348 GST_DEBUG_OBJECT (pad, "Stream %d is waiting", stream->stream_number); 349 g_cond_wait (&stream->stream_finish_cond, &self->lock);
From the logs with gst_debug=qtdemux:9 I noticed that qtdemux-1.4.4 process the frames much faster than 1.2.4 With gstreamer 1.2.4 0:00:06.731083145 qtdemux.c:4115:gst_qtdemux_decorate_and_push_buffer:<qtdemux0> Pushing buffer with dts 0:00:07.960000000, pts 0:00:08.000000000, duration 0:00:00.040000000 on pad video_0 With gstreamer 1.4.4 0:00:02.054549015 qtdemux.c:4137:gst_qtdemux_decorate_and_push_buffer:<qtdemux0> Pushing buffer with dts 0:00:07.960000000, pts 0:00:08.000000000, duration 0:00:00.040000000 on pad video_0 I don't have enough experience in video processing so don't know if it is relevant to this problem.
I can confirm that reverting http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=a391dfe17f1a325f60e1d51a6d40c1a68eb196de on top of 1.4.4 fixes this.
With the new code, an EOS event (from the first file) reaches the audiotee element, and is never cleared. This causes the next stream-start event to be dropped, and in turn streamsynchronizer to wait indefinitely. With the old code, that EOS event never reaches the audiotee.
I'm not sure how to really fix this now. If the drained signal is to be sent at the last "main" group, the EOS events for the previous groups will go through and we don't want that. I think it might need some insight from someone who knows about the playbin/decodebin logic.
Ideally the drained signal would be emitted *before any* EOS event goes downstream but *after* all EOS events of the current group have arrived in decodebin. There's a patch to do that in bug #738285 Unfortunately it causes problems in playbin, where the input-selector for disabled tracks are blocking the complete pipeline then :) I think all this gapless playback in playbin needs someone to take a step back, find a clean solution, remove all the current code and then implement it properly. We're only patching over different bugs while creating new bugs there currently.
Not a blocker anymore as the patch in question is reverted. See bugs #740949, #738064, #738285 for things that need to be done at least but might not be enough yet. I'll keep this bug open as it also contains valuable extra information.
*** Bug 744398 has been marked as a duplicate of this bug. ***
I also came across an issue similar to this, in 1.10. I observed the problem with short files: gst-launch-1.0 \ webmmux name=mux ! filesink location="sample_440hz.webm" \ videotestsrc num-buffers=1 pattern=black ! \ textoverlay valignment=center halignment=center font-desc="Mono, 72" text="440Hz" ! \ queue ! vp9enc ! mux. \ audiotestsrc num-buffers=188 freq=440 ! audio/x-raw,rate=48000 ! \ queue ! audioconvert ! vorbisenc quality=0.5 ! queue ! mux. gst-launch-1.0 \ webmmux name=mux ! filesink location="sample_880hz.webm" \ videotestsrc num-buffers=1 pattern=black ! \ textoverlay valignment=center halignment=center font-desc="Mono, 72" text="880Hz" ! \ queue ! vp9enc ! mux. \ audiotestsrc num-buffers=188 freq=880 ! audio/x-raw,rate=48000 ! \ queue ! audioconvert ! vorbisenc quality=0.5 ! queue ! mux. gst-play-1.0 --gapless sample_440hz.webm sample_880hz.webm However in my case not even the first file is played correctly. Ciao, Antonio
Ah, the problem I was seeing in Comment #10 was due to the particular test files that only had _one_ video buffer, which resulted in the video stream being a lot shorter then the audio stream. With the test files generated in the following way (i.e. 4 seconds worth of audio buffers, and actually 4 seconds worth of video buffers too), the gapless playback works a lot better: gst-launch-1.0 -e \ webmmux name=mux ! filesink location="sample_440hz.webm" \ videotestsrc pattern=black num-buffers=100 ! video/x-raw,framerate=25/1 ! \ textoverlay valignment=center halignment=center font-desc="Mono, 72" text="440Hz" ! \ queue ! vp9enc ! mux. \ audiotestsrc num-buffers=188 freq=440 ! audio/x-raw,rate=48000 ! \ queue ! audioconvert ! vorbisenc quality=0.5 ! queue ! mux. gst-launch-1.0 -e \ webmmux name=mux ! filesink location="sample_880hz.webm" \ videotestsrc pattern=black num-buffers=100 ! video/x-raw,framerate=25/1 ! \ textoverlay valignment=center halignment=center font-desc="Mono, 72" text="880Hz" ! \ queue ! vp9enc ! mux. \ audiotestsrc num-buffers=188 freq=880 ! audio/x-raw,rate=48000 ! \ queue ! audioconvert ! vorbisenc quality=0.5 ! queue ! mux. gst-play-1.0 --gapless sample_440hz.webm sample_880hz.webm I still get that the video is updated with a delay, and that seems to be the case with the files in the original report too.
-- 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-plugins-base/issues/143.