I am sending and receiving h.264 video on mpeg2-ts over udp. After noticing some lag, I added code that prints a timestamp and framenumber after sending and after av_read_frame returns. when comparing timestamps between frames with the same frame number, there is a ~60 ms delay (when sending 30 fps). Furthermore, if I stop at a breakpoint and delay the sending of frame number X, the timestamp of receiving frame number X-2 corresponds to the time of sending of X (i.e., the time between receiving frame number X-3 and frame number X-2 is longer if I delay the sending of X longer). The unavoidable conclusion is that av_read_frame *does not return* with frame X-2 until frame X starts arriving.
Carmel 2011/7/27 Alex Cohn <[email protected]> > On Wed, Jul 27, 2011 at 10:27, כרמל מגן <[email protected]> wrote: > >> av_read_frame does not return until the third frame arrives. This >> introduces 2 frames delay *before* the decoding. >> > > What do you mean "av_read_frame does not return"? > > from avformat.h: > * This function returns what is stored in the file, and does not validate > * that what is there are valid frames for the decoder. It will split what > is > ... > * @return 0 if OK, < 0 on error or end of file > > So, does it return negative number? Or the packet is not a video packet? > Maybe, you have the first video packet spliced into three network packets? > Note that the first video frame is large (it is a key frame, naturally). The > subsequent packet are much much smaller, becasue they encode only delta. > > Cheers, > Alex > > > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user > >
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
