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

[Jyoti]

 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 <arnout at mind.be>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
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20090514/cb6e6855/attachment.htm>