Hi! I have posted this question to StackOverflow some time ago, but apparently there is no activity compared to this list, so I'm reposting. I've been struggling with this problem for some time now, with no success. What I am trying to do is to play two container files with multiple streams inside (I take one video and just one audio) one after another without a gap. I am using filesrc/decodebin for input, then some simple processing, then playing to autosinks. As one file ends, I am relinking the pipeline dynamically, following the procedure described in the app dev guide. So far so good, but when I try to run the actual production-like pipeline, it gets stuck on EOS processing. The "production" pipeline is encoding to x264/AAC, then muxing to MPEGTS, then packetizing using RTP, then sending to UDP. What I see is that it blocks as soon as I drop the EOS event on the audio stream and block the pad. The audio stream somehow flows quicker at least before the encoder, and the moment I get EOS on audio stream, the video stream is still a couple of seconds in the past. So, I reckon I must block the audio source pad, drop the EOS, and wait for EOS on the video stream before actually changing the input bin. Alas, as soon as I mess with the audio EOS, pipeline gets stuck and no further callback is called. Is there anything I am missing? Can you suggest another way how to implement relinking of the pipeline to play multi-stream containers so that there are no gaps? In case you want to visualise, here is the pipeline DOT file after it is stuck: https://drive.google.com/open?id=0Bz5JvqnApX6WTkNuZVFZbzBCNjA I am not posting the code as it is quite lengthy. I will post fragments on as needed basis. Thank you so much in advance, all hope is on you :-) -- Best, Vlad _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Tue, 2017-05-30 at 11:22 +0300, Vladislavs Zaluckis wrote: Hi Vlad,
There's this example which may come in handy: It should do what you want, minus the encoding/streaming parts. Cheers -Tim -- Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi Tim, Thank you for the pointer! Indeed, it looks precisely what I need. Will give it a try shortly. -- Best regards, Vlad
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi Tim, After sleeping on the example app for some time, I don't get why it needs to be so complicated. Could you (or anybody) explain, why can't I just use concat element in each of the streams to stitch the adjacent items? Say I prepare (preroll) the next item and connect its video and audio streams to corresponding concat elements. Then concat will do the rest -- switch to the next item as soon as the current one ends with EOS, each in its own stream. Don't you think it could work? Thank you so much! -- Best regards, Vlad
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hi everyone, Tim,
I have made an attempt to implement that approach with concat elements (see my previous email in the chain). Well, ... unfortunately, it does not want to work out of the box, but I want to understand why. May I ask you to take a look at my pipeline snapshots at two different points -- after initialization and after the input is added. Can you tell why the hell are the autosinks stalled in the READY state??? The post-init pipeline: https://drive.google.com/open?id=0Bz5JvqnApX6Wc2JpZGh6S1ZzRXM The pipeline with an input added: https://drive.google.com/open?id=0Bz5JvqnApX6Wd29MMkI2NlZoT0k Here are some lines from the debug output that say that the sinks are kind of going to change the state (during initialization), but this never happens. -------------------- 0:00:00.094213487 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2521:gst_bin_element_set_state:<autoaudiosink0-actual-sink-pulse> current READY pending VOID_PENDING, desired next PAUSED 0:00:00.094243110 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2975:gst_bin_change_state_func:<autoaudiosink0> child 'autoaudiosink0-actual-sink-pulse' is changing state asynchronously to PAUSED 0:00:00.094255412 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2975:gst_bin_change_state_func:<encoder_bin> child 'autoaudiosink0' is changing state asynchronously to PAUSED 0:00:00.094262285 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2521:gst_bin_element_set_state:<autovideosink0> current READY pending VOID_PENDING, desired next PAUSED 0:00:00.094270350 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2521:gst_bin_element_set_state:<autovideosink0-actual-sink-xvimage> current READY pending VOID_PENDING, desired next PAUSED 0:00:00.094279694 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2975:gst_bin_change_state_func:<autovideosink0> child 'autovideosink0-actual-sink-xvimage' is changing state asynchronously to PAUSED 0:00:00.094299766 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2975:gst_bin_change_state_func:<encoder_bin> child 'autovideosink0' is changing state asynchronously to PAUSED -------------------- later on, when I dump the state of the pipeline (as pipeline-init), here is what I see in the log: -------------------- 0:00:01.095350817 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2110:gst_bin_get_state_func:<pipeline> getting state 0:00:01.095771643 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2137:gst_element_get_state_func:<pipeline> waiting for element to commit state 0:00:01.095819139 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2151:gst_element_get_state_func:<pipeline> timed out 0:00:01.095897058 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2110:gst_bin_get_state_func:<encoder_bin> getting state 0:00:01.095945534 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2137:gst_element_get_state_func:<encoder_bin> waiting for element to commit state 0:00:01.095986413 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2151:gst_element_get_state_func:<encoder_bin> timed out 0:00:01.096129980 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2110:gst_bin_get_state_func:<autoaudiosink0> getting state 0:00:01.096175755 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2137:gst_element_get_state_func:<autoaudiosink0> waiting for element to commit state 0:00:01.096217180 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2151:gst_element_get_state_func:<autoaudiosink0> timed out 0:00:01.096324883 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2137:gst_element_get_state_func:<autoaudiosink0-actual-sink-pulse> waiting for element to commit state 0:00:01.096371078 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2151:gst_element_get_state_func:<autoaudiosink0-actual-sink-pulse> timed out 0:00:01.096837925 14344 0x563aa7545400 INFO GST_STATES gstbin.c:2110:gst_bin_get_state_func:<autovideosink0> getting state 0:00:01.096894019 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2137:gst_element_get_state_func:<autovideosink0> waiting for element to commit state 0:00:01.096936085 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2151:gst_element_get_state_func:<autovideosink0> timed out 0:00:01.097035379 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2137:gst_element_get_state_func:<autovideosink0-actual-sink-xvimage> waiting for element to commit state 0:00:01.097078770 14344 0x563aa7545400 INFO GST_STATES gstelement.c:2151:gst_element_get_state_func:<autovideosink0-actual-sink-xvimage> timed out -------------------- Thank you so much for your help! Best, Vlad 2017-06-05 22:49 GMT+03:00 Vladislavs Zaluckis <[hidden email]>:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |