GNOME Bugzilla – Bug 686224
playbin: Regression with EOS when playing backwards in GStreamer 1.0
Last modified: 2012-10-23 16:15:28 UTC
Created attachment 226552 [details] Test program The test program for GStreamer 1.0 does the following: 1. Goes to paused 2. Seeks 3. Plays 4. Sets rate to backwards 5. Waits for EOS. This is the output: $ G_MESSAGES_DEBUG=all ./test file:///home/calvaris/store/gnome/WebKit/LayoutTests/media/content/test.mp4 6000 (process:27634): main-test-DEBUG: initializing (test:27634): main-test-DEBUG: playbin: NULL->READY=>PAUSED (test:27634): main-test-DEBUG: playbin: READY->PAUSED=>VOID_PENDING (test:27634): main-test-DEBUG: paused, seeking (test:27634): main-test-DEBUG: duration: 6027200000 (test:27634): main-test-DEBUG: seeking to 6000000000 (test:27634): main-test-DEBUG: playbin: PAUSED->PAUSED=>PAUSED (test:27634): main-test-DEBUG: playbin: PAUSED->PAUSED=>VOID_PENDING (test:27634): main-test-DEBUG: seeking finished, position: 6000000000 (test:27634): main-test-DEBUG: playbin: PAUSED->PLAYING=>VOID_PENDING (test:27634): main-test-DEBUG: playing, position: 6000000000 (test:27634): main-test-DEBUG: duration: 6027200000 (test:27634): main-test-DEBUG: setting rate to -1,0 from 6000000000 (test:27634): main-test-DEBUG: playbin: PAUSED->PAUSED=>PAUSED (test:27634): main-test-DEBUG: playbin: PAUSED->PAUSED=>PLAYING (test:27634): main-test-DEBUG: playbin: PAUSED->PLAYING=>VOID_PENDING (test:27634): main-test-DEBUG: playing, position: 6000000000 As you can see, we are not reaching EOS.
Created attachment 226553 [details] Patch to make the test work in 0.10 The output in 0.10 is the following: $ G_MESSAGES_DEBUG=all ./test file:///home/calvaris/store/gnome/WebKit/LayoutTests/media/content/test.mp4 6000 (process:28411): main-test-DEBUG: initializing (test:28411): main-test-DEBUG: playbin: NULL->READY=>PAUSED (test:28411): main-test-DEBUG: playbin: READY->PAUSED=>VOID_PENDING (test:28411): main-test-DEBUG: paused, seeking (test:28411): main-test-DEBUG: duration: 6027200000 (test:28411): main-test-DEBUG: seeking to 6000000000 (test:28411): main-test-DEBUG: playbin: PAUSED->PAUSED=>PAUSED (test:28411): main-test-DEBUG: playbin: PAUSED->PAUSED=>VOID_PENDING (test:28411): main-test-DEBUG: seeking finished, position: 6000000000 (test:28411): main-test-DEBUG: playbin: PAUSED->PLAYING=>VOID_PENDING (test:28411): main-test-DEBUG: playing, position: 6000000000 (test:28411): main-test-DEBUG: duration: 6027200000 (test:28411): main-test-DEBUG: setting rate to -1,0 from 6000000000 (test:28411): main-test-DEBUG: playbin: PAUSED->PAUSED=>PAUSED (test:28411): main-test-DEBUG: playbin: PAUSED->PAUSED=>PLAYING (test:28411): main-test-DEBUG: playbin: PAUSED->PLAYING=>VOID_PENDING (test:28411): main-test-DEBUG: playing, position: 5851428571 (test:28411): main-test-DEBUG: EOS in 796800000 As you can see, in this case we get the EOS.
This problem does not happen 100% of the times in 1.0, but it is close to that when we seek to close to less than 2s from the beginning. The WebKit test program motivating this seeks 300ms.
You can find for download the media file we are using at https://svn.webkit.org/repository/webkit/trunk/LayoutTests/media/content/test.mp4 .
Created attachment 226557 [details] Test program with ifdefs for both 0.10 and 1.0 You can compile now either: $ gcc -o test -Wall -Werror `pkg-config --libs --cflags gstreamer-0.10` main.c $ gcc -o test -Wall -Werror `pkg-config --libs --cflags gstreamer-1.0` main.c -DGSTREAMER_1_0
Created attachment 226561 [details] Test for both 1.0 and 0.10 Forgot about playbin2
Likely a playbin/streamsynchronizer issue, moving there.
From what I traced, it looks like both EOS events are sent by the muxer and queued at the multiqueue (in simple 0 and 1) and then it gets lost. Actually, the difference I could see is that with a normal run, the second queue pushes the event after it the first was attended by the streamsynchronizer, but in the failing one, both are fire at almost the same time.
Happens because pulsesink is prerolled by a gap event and never gets any audio buffers, thus the clock is never advancing... and xvimagesink is waiting forever for it to advance to render all buffers and then shutdown. *** This bug has been marked as a duplicate of bug 685273 ***