Hi, I'm trying to create an application where the video of a camera is encoded and transported to a client via a LAN (UDP), with as less latency as possible. I use the FFMpeg API on both the server and client side. The source has a rate of 50 Hz. I've opted for the following:
* encoder: libx264 (tune zerolatency, preset ultrafast, sliced threads; about 4 threads seems optimal) * protocol: UDP (either uni-cast or muli-cast) * format/muxer: mpegts The ultimate goal is to have the picture on the screen of the client in only a few tens of milliseconds (lets say 100ms max). I've read a lot of guides resulting in that there is no added latency on the server side, i.e. an encoded H264 frame gets transported immediately; Great! On the client side, however, one frame is always held back. It seems that the mpegts demuxer is the cause. I'm using av_read_frame() to read a complete frame. Consequently, the mpegts demuxer needs to be able to find the end of a frame in the bitstream. From looking at the code, i think the mpegts demuxer returns a complete frame, only when the beginning of the next frame is received, hence the extra latency of one frame. Is there a way the eliminate the extra delay of one frame when demuxing? Possibly using a different muxer/demuxer? Any other advice? I'm using the latest FFmpeg 2.2.1 and libx264 20131210-2245-stable. Peter This mail contains only Unclassified information. ------------------------------------------------------------------------------------------------------------ Disclaimer: If you are not the intended recipient of this email, please notify the sender and delete it. Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578. ------------------------------------------------------------------------------------------------------------ _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
