dynamic live source and linear muxed output stream

[Edouard Dupin]

Hello,

Thank you for your answer, we use your solution that is better than ours.
We Flush the stream and we get the pad time with 
gst_pad_query_position() on sources before the pad remove and set the 
offset with gst_pad_set_offset() when link the new pad on raw stream.

We not set the continuous stream on the output, but the bigger timestamp 
to keep synchronisation, because this might be the job of videorate and 
audioresample to generate continuous stream when detecting gaps, isn't it?

Thanks

Edouard D.

Le 04/02/2014 14:41, Edouard Dupin a écrit :
> Hello,
>
> We have a dynamic live source that can change the type of stream 
> (mpegts to ???) and we need to keep a static output (constant 
> framerate, and specific size)
> Note that our output is a http sink.
>
> After the first start the pipeline seems like:
> gst-launch-1.0 filesrc location=input_01.ts ! queue ! decodebin 
> name=decoder ! queue ! videoconvert name=videostream  ! videoscale ! 
> videorate  ! capsfilter caps=video/x-raw,width=640,height=480 ! 
> x264enc ! mpegtsmux name=outputmuxer ! filesink 
> location=output_plop.ts sync=true decoder. ! queue ! audioconvert 
> name=audiostream ! audioresample ! capsfilter 
> caps=audio/x-raw,format=S16LE,rate=48000,channels=2,layout=interleaved 
> ! twolamemp2enc ! outputmuxer.
>
> Our problem is simple
> When we detect the input change we remove "filesrc 
> location=input_01.ts ! queue ! decodebin name=decoder", And we create 
> a new source and decoder of the pipeline.
> The muxer generate the followings warnings :
> 0:00:08.405527100 32432 0x7fe8a80d46d0 WARN mpegtsmux 
> mpegtsmux.c:1010:mpegtsmux_clip_inc_running_time:<outputmuxer:sink_66> 
> ignoring DTS going backward
> 0:00:08.405622170 32432 0x7fe8a80d46d0 WARN mpegtsmux 
> mpegtsmux.c:1010:mpegtsmux_clip_inc_running_time:<outputmuxer:sink_66> 
> ignoring DTS going backward
>
> ==> and no output is generate after input change.
>
> We have tried some solution, but we request your opinion about our 
> choice.
>
> Our tested solution:
> - Re-timestamp the buffer "PTS" just after push out of the decoder and 
> send modified segment->position to the current push time (linear 
> timestamp from the starting of the pipeline) to the muxer ==> but it 
> does not seams to be a good solution.
> - An other way could be to modify the muxer to manage change input 
> segment to generate continuous output.
>
> If you think of a cleaner way to do this, your input would be greatly 
> appreciated.
> Thanks
>
>