GStreamer-devel

muxers, timestamps, sparse and continuous recordings

Classic

List

Threaded

6 messages Options

Stefan Sauer

muxers, timestamps, sparse and continuous recordings

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Eric Zhang-6

Re: muxers, timestamps, sparse and continuous recordings

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 <[hidden email]>

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Sudarshan Bisht

Re: muxers, timestamps, sparse and continuous recordings

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 <[hidden email]> 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 <[hidden email]>

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
Regards,

Sudarshan Bisht

ved kpl

Re: muxers, timestamps, sparse and continuous recordings

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
<[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>>>
>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>

Stefan Sauer

Re: muxers, timestamps, sparse and continuous recordings

In reply to this post by Eric Zhang-6

hi,

Eric Zhang schrieb:
> 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.

I meant pausing as on the application level. The videosrc ! tee name=t !
queue ! xvimagesink runs continously. It only t. ! queue ! encoder !
muxer ! filesink that get paused.

Stefan

>
> Eric
>
> 2008/9/10 Stefan Kost <[hidden email]
> <mailto:[hidden email]>>
>
> 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=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> <mailto:[hidden email]>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

Andoni Morales

Re: muxers, timestamps, sparse and continuous recordings

hi,

I've been working on a dv capturer and I implemented the play/pause recording doing the following:

When I decide to start the recording, I add the encodebin to the main pipeline and then I link it to the tee.

If you want to pause the encoding while previewing, unlink the encodebin, remove it from the main pipeline and I set it in the paused sate. If you want to restart the recording, readd it to the main pipeline and then relink it to tee. Finally, to stop the recording, send and eos event to the encodebin sink pad.

The recorded file have a continous stream.

Regards, Andoni Morales

2008/9/11 Stefan Kost <[hidden email]>

hi,

Eric Zhang schrieb:

> 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.

I meant pausing as on the application level. The videosrc ! tee name=t !
queue ! xvimagesink runs continously. It only t. ! queue ! encoder !
muxer ! filesink that get paused.

Stefan

>
> Eric
>
> 2008/9/10 Stefan Kost <[hidden email]
> <mailto:[hidden email]>>

>
> 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=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> <mailto:[hidden email]>

> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel