[FFmpeg-devel] [PATCH 04/10] avio: rename ByteIOContext->AVIOContext

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Sat, Feb 19, 2011 at 10:15:21AM -0500, Ronald S. Bultje wrote:
>> Hi,
>> 
>> On Sat, Feb 19, 2011 at 10:04 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Sat, Feb 19, 2011 at 12:42:48PM +0100, Anton Khirnov wrote:
>> [..]
>> >> ?140 files changed, 868 insertions(+), 864 deletions(-)
>> >>
>> >> diff --git a/ffserver.c b/ffserver.c
>> >> index 7a16b2d..c2563b7 100644
>> >> --- a/ffserver.c
>> >> +++ b/ffserver.c
>> >> @@ -163,7 +163,7 @@ typedef struct HTTPContext {
>> >>
>> >> ? ? ?/* RTSP state specific */
>> >> ? ? ?uint8_t *pb_buffer; /* XXX: use that in all the code */
>> >> - ? ?ByteIOContext *pb;
>> >> + ? ?AVIOContext *pb;
>> >> ? ? ?int seq; /* RTSP sequence number */
>> >
>> > The context has nothing to do with audio & video input/output.
>> > I support ByteIOContext getting a prefix but not to remove the "Byte" part
>> 
>> AVByteIOContext is fine, avbyteio_*() is not ideal (IMO), too long.
>> Are you OK with avio_*() along with AVByteIOContext?
>
> iam not opposed, maybe avbio_*() would be better, i dont know

Perhaps a bit of a stretch, but bio could be confused with the
same-named things in the Linux kernel, where it means block I/O.

>> Also, what about URLContext? AVUrlContext OK or would you prefer
>> something else?
>
> i have no better idea ATM
>
>> And for functions, is av_url_*() OK? (And then,
>> likely, url_f*() will be renamed to avio_*().)
>
> avuio_*() maybe for things taking a AVURLContext

What would you do with a URL if not I/O?  I think the URL part should
have more emphasis than the I/O part.  Names like read and write make
the I/O aspect even more obvious.

-- 
M?ns Rullg?rd
mans at mansr.com