GStreamer-devel

Presuming the data flow after EOS & Accessing a file by two applications

Classic

List

Threaded

5 messages Options

Jyoti-2

Presuming the data flow after EOS & Accessing a file by two applications

Hi all,

I am currently writing an application to save data from a live source
into file. The server streams a file RTP payloaded H.264 video packets
and AAC audio packets on separate ports. The reciever receives the
data and saves it into a file. I could save the file properly.

But now my problem is I want to do trickmode operations on this file even
when it is downloading(while the file is still been written on client side).
Currently I have written separate application to do trickmode opearations
on a file. But when I do trickmode operations on the file which is still
writing contents in to it, the pipeline gets into ASYNC state & when the
application is forceably closed the qtdemuxer throws an error.

One thing I thought is to send an EOS for every 5 secs on the client side
while writing data into file. So that the muxer gracefully writes the
proper data after EOS and the chunk of data can be considered for trickmode.
But after sending the first EOS I can't set pipeline to any state and the
data flow on pad is stopped.

I would be very thankful if anyone could just tell me
* how can I access the file even when its writing.
* Or in any way can I start the data flow even after sending EOS?

Thanks in advance.

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Arnout Vandecappelle

Re: Presuming the data flow after EOS & Accessing a file by two applications

Accessing a file while it is being written is as such not a problem.
However, there's no index yet at that point, and also some of the headers
(e.g. duration) may not be filled in.

Sending an EOS doesn't solve the issue here, because you'd either have a file
which contains multiple indices (probably not a legal file), or you'd
overwrite the index immediately while recording continues and end up reading
a corrupted index.

The solution is for your reading application to somehow support the case
where the file doesn't have an index yet. When I had this problem, I
considered four solutions:
- make sure the writer and reader are in the same GStreamer process, and
somehow share the index being built up in the muxer element with the reader;
- write the index to a separate file while it is built up, and let the reader
read from this file;
- make sure the reader doesn't need an index, i.e. convert time-based seeking
into bytes-based seeking using some binary search approach;
- make the reader build an index while it is reading - for forward seeking
that means the whole file has to be parsed (but not decoded), obviously.

In my case, I choose the third option because I didn't need to do actual
demuxing so I could easily write a custom stream parser.

Unfortunately, all four solutions require changes in the muxer/demuxer
elements - it simply cannot be solved as a separate element. My guess is
that the fourth option is the easiest to implement in a demuxer.

Regards,
Arnout

On Tuesday 12 May 2009 06:39:58 Jyoti wrote:

> Hi all,
>
> I am currently writing an application to save data from a live source
> into file. The server streams a file RTP payloaded H.264 video packets
> and AAC audio packets on separate ports. The reciever receives the
> data and saves it into a file. I could save the file properly.
>
> But now my problem is I want to do trickmode operations on this file even
> when it is downloading(while the file is still been written on client
> side). Currently I have written separate application to do trickmode
> opearations on a file. But when I do trickmode operations on the file which
> is still writing contents in to it, the pipeline gets into ASYNC state &
> when the application is forceably closed the qtdemuxer throws an error.
>
> One thing I thought is to send an EOS for every 5 secs on the client side
> while writing data into file. So that the muxer gracefully writes the
> proper data after EOS and the chunk of data can be considered for
> trickmode. But after sending the first EOS I can't set pipeline to any
> state and the data flow on pad is stopped.
>
> I would be very thankful if anyone could just tell me
> * how can I access the file even when its writing.
> * Or in any way can I start the data flow even after sending EOS?
>
> Thanks in advance.

--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: D206 D44B 5155 DF98 550D 3F2A 2213 88AA A1C7 C933

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Jyoti-2

Re: Presuming the data flow after EOS & Accessing a file by two applications

Hi Arnout,

Thanks for the reply and the information about the possible solutions.

I would be greatful if you can tell me more about the index.
As of my knowledge the index has the info on the number of
audio and video streams in media stream, with their proprties (like
width & height of a video stream). If I am not wrong the "av_write_trailer"
function in gstffmpegmux.c helps writing the index in muxers.

Now if I am opting fourth option can I parse whole file. As
the incoming data is from live source, and the duration is not known.
Can you hint me on how do I build index ?

Thanks.

On Wed, May 13, 2009 at 8:15 PM, Arnout Vandecappelle <[hidden email]> wrote:

Accessing a file while it is being written is as such not a problem.
However, there's no index yet at that point, and also some of the headers
(e.g. duration) may not be filled in.

Sending an EOS doesn't solve the issue here, because you'd either have a file
which contains multiple indices (probably not a legal file), or you'd
overwrite the index immediately while recording continues and end up reading
a corrupted index.

The solution is for your reading application to somehow support the case
where the file doesn't have an index yet. When I had this problem, I
considered four solutions:
- make sure the writer and reader are in the same GStreamer process, and
somehow share the index being built up in the muxer element with the reader;
- write the index to a separate file while it is built up, and let the reader
read from this file;
- make sure the reader doesn't need an index, i.e. convert time-based seeking
into bytes-based seeking using some binary search approach;
- make the reader build an index while it is reading - for forward seeking
that means the whole file has to be parsed (but not decoded), obviously.

In my case, I choose the third option because I didn't need to do actual
demuxing so I could easily write a custom stream parser.

Unfortunately, all four solutions require changes in the muxer/demuxer
elements - it simply cannot be solved as a separate element. My guess is
that the fourth option is the easiest to implement in a demuxer.

Regards,
Arnout

On Tuesday 12 May 2009 06:39:58 Jyoti wrote:
> Hi all,
>
> I am currently writing an application to save data from a live source
> into file. The server streams a file RTP payloaded H.264 video packets
> and AAC audio packets on separate ports. The reciever receives the
> data and saves it into a file. I could save the file properly.
>
> But now my problem is I want to do trickmode operations on this file even
> when it is downloading(while the file is still been written on client
> side). Currently I have written separate application to do trickmode
> opearations on a file. But when I do trickmode operations on the file which
> is still writing contents in to it, the pipeline gets into ASYNC state &
> when the application is forceably closed the qtdemuxer throws an error.
>
> One thing I thought is to send an EOS for every 5 secs on the client side
> while writing data into file. So that the muxer gracefully writes the
> proper data after EOS and the chunk of data can be considered for
> trickmode. But after sending the first EOS I can't set pipeline to any
> state and the data flow on pad is stopped.
>
> I would be very thankful if anyone could just tell me
> * how can I access the file even when its writing.
> * Or in any way can I start the data flow even after sending EOS?
>
> Thanks in advance.

--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: D206 D44B 5155 DF98 550D 3F2A 2213 88AA A1C7 C933

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Arnout Vandecappelle

Re: Presuming the data flow after EOS & Accessing a file by two applications

With the index I mean a table of pointers into the stream that is typically
used by demuxers to seek in the stream. When you want to seek to a position
in time, the demuxer can look up in the index which byte position corresponds
to that time, and request a seek in bytes upstream. Typically, this index is
present in the muxed file. In a matroska file (which I'm most familiar
with), the index is written at the end of the file. Also, it is only written
when the stream has finished, because before that time the size of the index
isn't known, nor the offset at which it should be written.

When parsing a stream, the demuxer will read the index and store it
internally. If no index is present, it will typically disable seeking
altogether. However, it could also build the index dynamically, based on the
data that passes through the demuxer. For every buffer that is pushed out of
the demuxer, you write its timestamp and offset into the dynamic index. (Not
actually for every buffer, the index would become too large... Let's say
every 10 keyframes, for instance).

When seeking with this dynamic index, the behaviour is slightly different
than with the normal index. With the dynamic index, it is possible to seek
forward, beyond the duration already stored in the index. In that case, you
shouldn't return an error, but you should continue parsing the stream
(without pushing out any buffers) until you have the seek position.

Note that implementing all this is not going to be easy. It requires a much
deeper understanding of GStreamer than to implement a new element...

Regards,
Arnout

On Thursday 14 May 2009 13:18:52 Jyoti wrote:

> Hi Arnout,
>
> Thanks for the reply and the information about the possible solutions.
>
> I would be greatful if you can tell me more about the index.
> As of my knowledge the index has the info on the number of
> audio and video streams in media stream, with their proprties (like
> width & height of a video stream). If I am not wrong the "av_write_trailer"
> function in gstffmpegmux.c helps writing the index in muxers.
>
> Now if I am opting fourth option can I parse whole file. As
> the incoming data is from live source, and the duration is not known.
> Can you hint me on how do I build index ?
>
> Thanks.

Jyoti-2

Re: Presuming the data flow after EOS & Accessing a file by two applications

Thanks for the information Arnout.

I'll try to do the changes in muxer & demuxer code.
Though I am not an expert in Gstreamer, but I'll give a try.
Thanks for the help. The solutions you mentioned are of
great help for me to start with.

Thanks.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel