[gst-devel] muxers, timestamps, sparse and continuous recordings

[ved kpl]

Hi,

Stefan, I also got it working with pad probe. In my case, the pipeline
has recordbin and  previewbin right from the start. So the first data
should flow right till the sinks, to make sure that the pipeline is
prerolled and then trigerring the probe ON/Off for recording.
Eric, I guess a new base time is set when the pipeline is set to
paused. I dont think that should pose any problem (other than AV sync
maybe). Please correct me on this.

Ved

On Thu, Sep 11, 2008 at 10:53 AM, sudarshan bisht
<bisht.sudarshan at gmail.com> wrote:
> Hi ,
>        I had also tried this thing , I was getting same video frames for
> the particular duration . Its not a problem of muxers i guess  . Because
> muxer creates its own timestamp and attach it to the buffer . Its problem of
> tea element where you connect your preview and record pipeline  . Whenever
> you add a new pipeline to the running pipeline so what I think is all the
> elements of second pipelines should be  in sync with the existing pipeline
> because source element is common here .  So in order to do that tea element
> keep pushes same video frame for that particular duration that is same as
> the time till you press record.  To fix this problem what I did is wrote a
> plugin which sends running pipeline's position as a timestamp for the first
> buffer , only for the very first time . And I insert this plugin right after
> tea element in record pipeline.
>
>  This has fixed my problem .
>
>
> On Thu, Sep 11, 2008 at 6:50 AM, Eric Zhang <nicolas.m.zhang at gmail.com>
> wrote:
>>
>> Hi, Stefan:
>>
>>     I think your pipeline is using GstSystemClock because you mentioned
>> the source is a live element. If it is, the clock will keep increasing even
>> if the pipeline is paused. This makes the timestamp noncontinuous. To
>> generate a continuous timestamp, I think you can try to use the clock
>> provided by your sink elements. Maybe this is not easy because the live
>> element is different with other source elements.
>>
>> Eric
>>
>> 2008/9/10 Stefan Kost <ensonic at hora-obscura.de>
>>>
>>> hi,
>>>
>>> i was wondering how muxers should handle timestamps on incoming buffers.
>>> Assume an applications that shows video from a camera. When you click a
>>> button it records to file, allowing to pause and unpause in between. The
>>> recorded file should have a continuous stream. If I don't do any special
>>> casing this is not the case.
>>>
>>> 1) When I playback the recorded file, I have an initial pause before
>>> video start (if I pressed record after two seconds, the video will start
>>> after two seconds).
>>>
>>> 2) If I pause in between, also in the playback there is a pause.
>>>
>>> Right now I work around with a pad probe that looks at disconts to
>>> aggregate a time_stamp_offset and correct all incoming buffers by
>>> subtracting that. It works but probably is not the right way. I believe
>>> this involves the use of segments, but I am not sure how. Also both
>>> behaviors might be valid (having a sparse and having a continuous
>>> stream). So the application would somehow be involved to select the
>>> desired behavior. Any comments?
>>>
>>>
>>> Stefan
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>
>
>
> --
> Regards,
>
> Sudarshan Bisht
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>