[gst-devel] Presuming the data flow after EOS & Accessing a file by two applications

[Arnout Vandecappelle]

 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