[FFmpeg-devel] [PATCH 2/2] avformat/aviobuf: prefer to use avio_read_partial()

lance.lmwang at gmail.com lance.lmwang at gmail.com
Fri Dec 3 14:50:21 EET 2021


On Fri, Dec 03, 2021 at 01:59:16PM +0200, Martin Storsjö wrote:
> On Fri, 3 Dec 2021, lance.lmwang at gmail.com wrote:
> 
> > On Fri, Dec 03, 2021 at 10:47:00AM +0100, Marton Balint wrote:
> > > 
> > > 
> > > On Fri, 3 Dec 2021, lance.lmwang at gmail.com wrote:
> > > 
> > > > From: Limin Wang <lance.lmwang at gmail.com>
> > > > 
> > > > This is allowed to read fewer bytes than requested. The missing bytes can
> > > > be read in the next call.
> > > 
> > > I don't think this is needed, after all we want to read all data, there is
> > > no point in reading it in smaller chunks, no?
> > 
> > Now the buf is 1024, in case I'm using sdp file, most of my simple
> > testing sdp is about 300 byte, so I think it's preferable to use
> > avio_read_partial and let it return directly. as we don't expect to read
> > 1024 at all.
> 
> No, that's not how it works.
> 
> avio_read_to_bprint loops until it either has read max_size bytes, or until
> it reaches EOF. If you use avio_read_partial, it would only loop more times,
> but it would take the exact same amount of time.
> 
> If you read a file from disk, once it has read the 300 bytes of actual data,
> and reach EOF, it returns directly.
> 
> avio_read_partial is only relevant for reading data e.g. over a network,
> where there's more data following, but you want to consume and process the
> initially received data before waiting for more. But with avio_read_partial
> it doesn't return until all data has been received anyway.

Thanks for the comments, it seems that I misunderstand the usage of 
avio_read_partial, please ignore the patch then.

> 
> // Martin
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang


More information about the ffmpeg-devel mailing list