[Ffmpeg-devel] feeding lavf with a ByteIOContext ?

Aurelien Jacobs aurel
Thu May 19 02:09:22 CEST 2005


On Thu, 19 May 2005 01:21:05 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> Hi
> 
> On Thursday 19 May 2005 00:50, Aurelien Jacobs wrote:
> > Hi,
> >
> > I wanted to use lavf, but I wanted to feed it with my own source of
> > data. (not a file nor an url).
> > I've seen 2 ways to do this with lavf :
> >  - using an URLProtocol with a fake protocol
> >  - using directly a ByteIOContext
> >
> > For my purpose I really don't need all the overhead of URLProtocol
> > so I would like to use ByteIOContext directly. The URLProtocol seems
> > well supported but not the ByteIOContext, so I first would like to
> > know if ByteIOContext is really meant to be used outside of lavf or
> > if it's reserved for internal purpose ?
> >
> > I finally managed to get ByteIOContext working directly, setting it
> > with init_put_byte and then using av_open_input_stream. But I had
> > to workaround a problem in lavf. In few places, lavf "suppose" that
> > the ByteIOContext struct was built through an URLProtocol, and
> > uses url_fileno to get the URLProtocol related to this
> > ByteIOContext. This obviously crashes when using ByteIOContext
> > directly. It was quite simple to avoid all those url_fileno calls in
> > lavf, so here is a patch.
> > The only 2 remaining url_fineno calls are in yuv.c and are used to
> > determine and generate the filenames for the Y,U and V planes, so I
> > guess that anyway, yuv.c will never be usable with a single
> > ByteIOContext.
> > So what about this patch ? is it the right thing to do ? should I
> > commit it ? (tested with make test and with mplayer -demuxer 35)
> 
> killing the url_fileno() hack is certainly good, so patch ok, commit

done.

> it though i dont know if ByteIOContext was originally supposed to be
> used  directly or not, but i see no reason why it shouldnt if it works

and if I find some time to document it, this could become "officially"
supported :-)

Aurel





More information about the ffmpeg-devel mailing list