change "location" of filesrc element without breaking tcpserversink connection

Fri Aug 2 04:07:22 PDT 2013

Thank you for your help.
It looks like I have done it, but with some differencies, I didn't change
any buffers because it works good without modification and wasn't work with
my buffer modifications, Is it good? Or it might cause the some problems in
future or with different formats? I use mp4(h264) and webm(vp8) as input
and webm as output. I have not tried h264 for output.

2013/7/30 Sergio Ortega <sortegagamero at gmail.com>

> HI,
>
> well, as the log says: "not negotiated". Each time that you plays another
> file the decodebin will create new pads for the decoding. You will plug
> those pads. At the beginning all the pipeline will negotiated all the caps
> which will flow through all the pads. The problem arises the first time
> that you change the file, since the decodebin will try to output some caps
> through the new pads, but the rest of the pipeline has already got the
> caps, so if the new file is not of the exactly same type than the old one
> you will have that error. Solution? Easy. Adapt those caps. Put after the
> decodebin some elements which will adapt the caps. For example for video it
> means adapting frame rate, video width and height and maybe the color
> space. Watch out with the frame rate. Increasing the frame rate or audio's
> sample rate ( oversampling) is not a problem since it's an excess of
> information, but doing the opposite ( undersampling) could bring to you
> some consequences not very nice ( you can watch jumps inside a video or
> hear cuts in the audio). Adding those elements implies that at the same
> time that you put the filesrc and the decodebin to NULL you must also put
> those elements to NULL to force the renegotiation.
>
> Tell me if you have some other problem.
>
> SERGIO
>
> 2013/7/29 Serhiy Stetskovych <patriotyk at gmail.com>
>
>> Thank you for answer,
>>  I have tried change the location in the thread and now I have only one
>> error:
>>
>> Error: GStreamer encountered a general stream error. qtdemux.c(3891):
>> gst_qtdemux_loop ():
>> /GstPipeline:player/GstDecodeBin2:decoder/GstQTDemux:qtdemux0:
>> streaming stopped, reason not-negotiated
>>
>> I just put to STATE_NULL decodebin2 and filesrc, change location, and put
>> them back to play.
>>
>> Thank you for your help
>>
>>
>>
>> 2013/7/29 Sergio Ortega <sortegagamero at gmail.com>
>>
>>> What kind of errors have you got? Could you put here the logs?
>>>
>>> When do you have to change the location? Well, basically when you want.
>>> If you want to play a video until its end then you have to wait for the EOS
>>> event. If you want to do it at second 20, then you must wait for the
>>> corresponding DTS buffer. I forgot to tell you one thing. You can't do a
>>> seek or set to NULL an element from within the event probe. You must start
>>> a thread ( usually a pthread or a GTask) and do it from outside of the
>>> probe. Of course the probe must wait for the operation, so that also
>>> implies using a semaphore.
>>>
>>> You're welcome!
>>>
>>> SERGIO
>>>
>>>
>>> 2013/7/29 Serhiy Stetskovych <patriotyk at gmail.com>
>>>
>>>> Thank you for so detailed explanation, I am not much familiar with
>>>> gstreamer so I don't understand some things. I was able to add event
>>>> hendler  and got all events. I was able to block and modify segment events.
>>>> But I can't understand when exactly I need to change the location, I get
>>>> two EOS events for video and audio. So when I am changing location in any
>>>> of them I got many errors.
>>>> Thank you
>>>>
>>>>
>>>> 2013/7/26 Sergio Ortega <sortegagamero at gmail.com>
>>>>
>>>>> Hi,
>>>>>
>>>>> What you are trying to do is simulating a live from a file, aren't
>>>>> you? You don't want to break the tcpserversink connection when you change
>>>>> the filesrc's location. Then you must do the next thing. You must install a
>>>>> pad-probe outside the decodebin or whatever demuxer you use. That pad probe
>>>>> must do several things.
>>>>>
>>>>> The first one is modifying the first segment event. That event will
>>>>> have the video's original duration. It must be modified to have 0 as start
>>>>> and -1 as end. In such way you won't let the final muxer to know the
>>>>> duration, and it will assume that video has no end ( you can, of course,
>>>>> put whatever duration you wan, of course, for example half of the first
>>>>> video and the whole of the second one).
>>>>>
>>>>> The second one is blocking the rest segment events which you will have
>>>>> when you replace the location. We will see later how to replace it.
>>>>>
>>>>> The third thing is blocking the flush events.
>>>>>
>>>>> The fourth thing is blocking the EOS events ( if you want to play a
>>>>> video until the end, of course).
>>>>>
>>>>> The fifth thing ( and this is very important) is modifying the
>>>>>  buffer's PTS and DTS. Several muxers ( like mp4mux or oggmux) will
>>>>> multiplex a video and an audio depending on each PTS and DTS frame. If they
>>>>> detect that repeated PTS's or DTS's, they will discard the buffer, so in
>>>>> the best case you will see the video delayed ( in the worst you will see
>>>>> nothing but errors in the logs). Think that video and audio have their own
>>>>> PTS's and DTS's, but they are related when you replace a file ( at the end
>>>>> both files must maintain the synchronization).
>>>>>
>>>>> And now how to change a file. First of all emit a flush start and a
>>>>> flush end in the filesrc to clean the buffers. After it, put filesrc and
>>>>> the demuxer or the decodebin to NULL, change filesrc's location and put
>>>>> those elements again into PLAYING state.
>>>>>
>>>>> Watch out with the events and the DTS's!!
>>>>>
>>>>> 2013/7/26 Serhiy Stetskovych <patriotyk at gmail.com>
>>>>>
>>>>>> I think the second option with locking might help me but I don't
>>>>>> understand how to use it.
>>>>>>
>>>>>>
>>>>>> 2013/7/25 Serhiy Stetskovych <patriotyk at gmail.com>
>>>>>>
>>>>>>> Just investigated and found that after changing location, stream
>>>>>>> begins with new webm header. So Is it possible to create one stream from
>>>>>>> several files?
>>>>>>>
>>>>>>>
>>>>>>> 2013/7/25 Serhiy Stetskovych <patriotyk at gmail.com>
>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> I have tried with state READY and thought it don't work, but
>>>>>>>> problem wasn't in connection. Looks like when file reaches end, gstreamer
>>>>>>>> sends some end information, or there is some gap between streams or
>>>>>>>> something else. Because connections still alive, but video didn't displays
>>>>>>>> in browser, it begin playing again after refresh(reconnect)
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/7/25 Stirling Westrup <swestrup at gmail.com>
>>>>>>>>
>>>>>>>>>  On Thu, Jul 25, 2013 at 6:44 AM, Serhiy Stetskovych <
>>>>>>>>> patriotyk at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello, I have a problem with changing media file in filesrc.
>>>>>>>>>> After finishing playing one file I get event and in this point I need
>>>>>>>>>> change media file to another but without breaking clients connected to
>>>>>>>>>> tcpserversink. I can change file only after setting STATE_NULL, and  then
>>>>>>>>>> setting back to STATE_PLAYING. But this breaks all my connections.
>>>>>>>>>>
>>>>>>>>>> Actually I use multifdsink with writing to sockets, but in
>>>>>>>>>> explanation above I wrote about tcpserversink because It is easier to
>>>>>>>>>> explain, but I think it doesnt matter.
>>>>>>>>>> <http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
>>>>>>>>>>
>>>>>>>>> You have two options. First, you can change the media file in
>>>>>>>>> filesrc when you are in STATE_READY rather than STATE_NULL. You only really
>>>>>>>>> need to go into STATE_NULL when you are about to dismantle your pipeline
>>>>>>>>> (ie for program cleanup).
>>>>>>>>>
>>>>>>>>> If for some reason you have to put filesrc in a state that causes
>>>>>>>>> your sink to perform an action you don't like, you can LOCK the state of
>>>>>>>>> the sink so it ignores requests to change state. This is done with one of
>>>>>>>>> the gst_element_... function calls.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Stirling Westrup
>>>>>>>>> Programmer, Entrepreneur.
>>>>>>>>> https://www.linkedin.com/e/fpf/77228
>>>>>>>>> http://www.linkedin.com/in/swestrup
>>>>>>>>> http://technaut.livejournal.com
>>>>>>>>> http://sourceforge.net/users/stirlingwestrup
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> gstreamer-devel mailing list
>>>>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> gstreamer-devel mailing list
>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> gstreamer-devel mailing list
>>>>> gstreamer-devel at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130802/8fcff913/attachment-0001.html>