2012/1/13 Malcolm Bechard <[email protected]>: > Is there any pre-buffering that occurs? If so, can I control the buffer > size?
It depends on exact implementation of exact protocol client. This should or should not be a concern depending on the case. In case of http proto implementation, i believe there is no "caching" on the layer substanding to av_read_frame() call. I think it returns data as soon as it reads from the socket, in case of downloading. > If not, is there any best practice advice for calling av_read_frame()? Just do it :) HTTP is on top of TCP, so you usually cannot fail by reading data when you are ready to process it. The problem may be very slow reading, in such case particular remote server can disconnect such a "slow client". The client becomes slow if it has no enough bandwidth, or cannot process media stream in time. In both cases the fashion of av_read_frame() calling is not likely to be the problem. > Is av_read_frame() a blocking call that sends a request to the server and > waits for a audio packet in response? Yes, it's blocking operation generally. > I assume it's possible to call av_read_frame() too fast, as to request data > faster than the stream is creating. Wrong. It could be, if this op was non-blocking. AFAIK non-blocking protocol r/w functions are available in libavformat, but they are experimental. > Is there a way to tell if there is data > ready to be read by a call to av_read_frame()? These questions do not make sense as i answered to previous one. > Is there a way to tell if the connection was lost? av_read_frame() returns AVERROR_EOF in this case. > Thanks for any help anyone can provide. Thanks for clear questions. I hope there're not so many mistakes in my answers. -- Andrey Utkin _______________________________________________ libav-api mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-api
