[Live-devel] Lot of late pictures skipped by VLC

[Cristiano Belloni]

Hi to everybody,

I'm implementing a live rtsp server with liveMedia libraries.

I subclassed H263plusVideoFileServerMediaSubsession, so that any time an 
RTSP client makes a request, it starts a thread which takes frames from 
an analog camera and encode the frames in h263+ format (encoding is done 
by ffmpeg library with the 'h263p' codec).

As any encoded frame is ready, the thread write()s it on a unix named 
pipe (fifo) and goes on encoding the next frame available, while the 
main thread streams the contents of the fifo, which I previously added 
as a subsession.

In wireshark, the servers seems to send RTP/UDP packets correctly, with 
consequential timestamps.
Anyways, it seems the UDP checksum value is not correct. Wireshark keeps 
complaining something like: "Checksum: 0x89ac [incorrect, should be 
0x2017 (maybe caused by "UDP checksum offload"?)]" for every packet sent 
(obviously, checksum values differ).

When I try to view the stream with vlc, it decodes 4-5 frames then 
starts saying "[00000332] main video output warning: late picture 
skipped (979326)" for 20-30 frames (and the video blocks), then decodes 
another 4-5 frames and so on.

You may say: vlc's problems (and I will probably post this in vlc's 
mailing list too).

But the strange thing is that when I stream - with the same (slightly 
modified) liveMedia server - the same exact frames stored in a file 
(acquired the same way, encoded the same way, saved in a regular file), 
vlc magically plays it perfectly, with no frame skipped.

Maybe there's some thing I don't know, or possibily a parameter I don't 
define or define wrongly, in the way liveMedia libraries interact with 
non-regular, non-seekable files in which liveMedia read()s may block 
until the thread write()s  the freshly encoded frames in the fifo?

Or maybe it is something about concurrent threading? I already tried to 
start another process instead of a thread to do the encoding and writing 
on the fifo, but I had no luck. same behaviour.

Did it ever happen to any of you?

Thanks!

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni@imavis.com>