[FFmpeg-devel] [PATCH] RTSP-MS 14/15: ASF packet parsing

[Michael Niedermayer]

On Tue, Apr 21, 2009 at 08:29:53PM -0400, Ronald S. Bultje wrote:
> Hi Michael,
> 
> On Tue, Apr 21, 2009 at 1:33 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > There seem 2 variants and i belive both should be implemented because
> > they are both usefull in different circumstances.
> >
> > The first is that the rtp code should provide a fully functional
> > ByteIOContext, not one that has a EOF before the end of the file.
> > That means it must provide a read_packet() callback.
> > Such callback would of course block until the data has been received.
> > This first variant is usefull for a multithreaded application that runs
> > the demuxer in a seperate thread and is thus unaffected by the blocking.
> >
> > The second is that when no more data is available this
> > state should be signaled to the demuxer (iam not sure if we have any
> > means to do this yet) also iam not sure which way is the nicest to
> > do this
> > a url_fwouldblock() could be used, that is the asf demuxer could do
> > if(url_fwouldblock(pb))
> > ? ?return AVERROR(EAGAIN);
> > before reading the first byte of the next packet
> [..]
> > Either way comments and alternative suggestions are definitly welcome.
> 
> Any ideas about a push-based instead of pull-based mechanism / basis
> for the demuxer?

you mean rewriting all demuxers to be state machines that can use any
amount of bytes and return seek requests to the user?

doesnt sound particularely pretty ...
but maybe you meant something else?

anyway 
if(url_fwouldblock(pb))
    return AVERROR(EAGAIN);

is pretty close to push based

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090422/c8542f14/attachment.pgp>