Odd replay issue...

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Odd replay issue...

Nathanael D. Noblet
Hello,

   I have written a GTK based app, it has been fun using and learning
gstreamer. I've gotten most everything working well and the way I need,
however I've noticed a bit of an issue I can't seem to figure out. My
app has two separate pipelines, one for viewing a source (and recording
it), and a second to replay recorded files. Everything is pretty much
working well.

   Here's the problem, I start up my application, and start the
recording viewer, at which point it is basically src->xvimagesink. Then
when I click record and it adds a bin to a tee src and starts recording.

   When I go to review it by loading the file in the other viewer
pipeline I have some odd behaviour. Suppose I watched the recording
pipeline for 5 minutes before clicking the record button. When I go to
review that recording, the timeoverlay on display starts the clock at
00:05:00 instead of 00:00:00. I don't get it. If I use gst-launch
filesrc="file.mpg" !timeoverlay !xvimagesink it starts at 00:00:00... so
why is my separate pipline showing a timestamp at the point of recording?

Any help would be appreciated.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Odd replay issue...

Stefan Sauer
Am 10.08.2010 19:58, schrieb Nathanael D. Noblet:

> Hello,
>
>    I have written a GTK based app, it has been fun using and learning
> gstreamer. I've gotten most everything working well and the way I need,
> however I've noticed a bit of an issue I can't seem to figure out. My
> app has two separate pipelines, one for viewing a source (and recording
> it), and a second to replay recorded files. Everything is pretty much
> working well.
>
>    Here's the problem, I start up my application, and start the
> recording viewer, at which point it is basically src->xvimagesink. Then
> when I click record and it adds a bin to a tee src and starts recording.
>
>    When I go to review it by loading the file in the other viewer
> pipeline I have some odd behaviour. Suppose I watched the recording
> pipeline for 5 minutes before clicking the record button. When I go to
> review that recording, the timeoverlay on display starts the clock at
> 00:05:00 instead of 00:00:00. I don't get it. If I use gst-launch
> filesrc="file.mpg" !timeoverlay !xvimagesink it starts at 00:00:00... so
> why is my separate pipline showing a timestamp at the point of recording?
>
> Any help would be appreciated.
>

It is a nasty problem. The stream time of the pipeline is 00:05:00 when you
start recording and in some file-formats (e.g. iso mp4) that is preserved.

camerabin 'solves' that problem by tracking the non-recording phases in the
piepline and rewriting the timestamps on buffers then go to the recording
branch. People have been sugesting to use the a newsegment event instead, but I
haven't verified the idea.

Stefan

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Odd replay issue...

Nathanael D. Noblet
On 08/11/2010 03:15 PM, Stefan Kost wrote:

> It is a nasty problem. The stream time of the pipeline is 00:05:00 when you
> start recording and in some file-formats (e.g. iso mp4) that is preserved.
>
> camerabin 'solves' that problem by tracking the non-recording phases in the
> piepline and rewriting the timestamps on buffers then go to the recording
> branch. People have been sugesting to use the a newsegment event instead, but I
> haven't verified the idea.


So the question is, how come if I run

'gst-launch filesrc location="file.mpg" ! timeoverlay ! xvimagesink'

it displays it as starting from 00:00:00,400 instead? The time/stream or
whatever couldn't possibly be embedded in the file otherwise shouldn't
it also give that odd time?  The viewer in source is setup nearly
identical to that same gst-launch command so that is what has got me
fairly confused...

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Odd replay issue...

Stefan Sauer
Am 12.08.2010 06:30, schrieb Nathanael D. Noblet:

> On 08/11/2010 03:15 PM, Stefan Kost wrote:
>
>> It is a nasty problem. The stream time of the pipeline is 00:05:00
>> when you
>> start recording and in some file-formats (e.g. iso mp4) that is
>> preserved.
>>
>> camerabin 'solves' that problem by tracking the non-recording phases
>> in the
>> piepline and rewriting the timestamps on buffers then go to the recording
>> branch. People have been sugesting to use the a newsegment event
>> instead, but I
>> haven't verified the idea.
>
>
> So the question is, how come if I run
>
> 'gst-launch filesrc location="file.mpg" ! timeoverlay ! xvimagesink'

well timeoverlay has nothing to do with the recorded video. It is just starting
with the video. In the recodring case you have overlayed the time while
recordgin and then the timeoverlay gfx are part of the frames. So it shows which
segment you have recorded.

Stefan

>
> it displays it as starting from 00:00:00,400 instead? The time/stream or
> whatever couldn't possibly be embedded in the file otherwise shouldn't
> it also give that odd time?  The viewer in source is setup nearly
> identical to that same gst-launch command so that is what has got me
> fairly confused...


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Odd replay issue...

Nathanael D. Noblet
On 08/12/2010 03:08 PM, Stefan Kost wrote:

> Am 12.08.2010 06:30, schrieb Nathanael D. Noblet:
>> On 08/11/2010 03:15 PM, Stefan Kost wrote:
>>
>>> It is a nasty problem. The stream time of the pipeline is 00:05:00
>>> when you
>>> start recording and in some file-formats (e.g. iso mp4) that is
>>> preserved.
>>>
>>> camerabin 'solves' that problem by tracking the non-recording phases
>>> in the
>>> piepline and rewriting the timestamps on buffers then go to the recording
>>> branch. People have been sugesting to use the a newsegment event
>>> instead, but I
>>> haven't verified the idea.
>>
>>
>> So the question is, how come if I run
>>
>> 'gst-launch filesrc location="file.mpg" ! timeoverlay ! xvimagesink'
>
> well timeoverlay has nothing to do with the recorded video. It is just starting
> with the video. In the recodring case you have overlayed the time while
> recordgin and then the timeoverlay gfx are part of the frames. So it shows which
> segment you have recorded.

Not quite, the timeoverlay item is in the viewing branch of the
pipeline, not prior to the tee, so wouldn't have been recorded.

pipeline:
                        queue->filesink
                       /
filesrc (mpeg) -> tee -
                       \
                        queue->decode->timeoverlay->xvimagesink


there are more pieces than that, but that's the gist of it.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel