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. <div class="gmail_quote"> On Wed, May 13, 2009 at 8:15 PM, Arnout Vandecappelle <<a href="mailto:arnout@mind.be">arnout@mind.be</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 <div><div></div><div class="h5"> 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. </div></div>-- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind <a href="http://www.mind.be" target="_blank">http://www.mind.be</a> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: <a href="http://www.linkedin.com/in/arnoutvandecappelle" target="_blank">http://www.linkedin.com/in/arnoutvandecappelle</a> 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. <a href="http://p.sf.net/sfu/kodak-com" target="_blank">http://p.sf.net/sfu/kodak-com</a> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a> </blockquote></div>