gst-play-1.0 --gapless file1.mp4 file2.mp4 stops after first file

Vincent Penquerc'h @vincent said:

This was introduced by https://bugzilla.gnome.org/show_bug.cgi?id=738064

Vincent Penquerc'h @vincent said:

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);

Andrey said:

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.

Christoph Reiter (lazka) said:

I can confirm that reverting

http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=a391dfe17f1a325f60e1d51a6d40c1a68eb196de

on top of 1.4.4 fixes this.

Vincent Penquerc'h @vincent said:

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.

Vincent Penquerc'h @vincent said:

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.

Sebastian Dröge @slomo said:

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.

Sebastian Dröge @slomo said:

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.

Vincent Penquerc'h @vincent closed a related bug:

*** Bug 744398 has been marked as a duplicate of this bug. ***

Antonio Ospite @ao2 said:

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

Antonio Ospite @ao2 said:

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.

mentioned in issue #552

mentioned in merge request !160 (merged)

mentioned in issue #930 (moved)

mentioned in merge request !1250 (closed)

added Base Plugins labels

mentioned in merge request gstreamer!976 (closed)

gst-play-1.0 --gapless file1.mp4 file2.mp4 stops after first file

Submitted by Andrey

Description

Designs

Child items ...

Activity

Admin message

Admin message

gst-play-1.0 --gapless file1.mp4 file2.mp4 stops after first file

Submitted by Andrey

Description

Activity