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

[Дима Зинченко]

Hi!
I think we had similar problem but on the receiving side of the software. We had a goal to create Java application to receive and display several MJPEG streams from Live server. The available Java soft was unable to receive Live stream, so we decided to link modified Live openRTSP code to Java through JNI. We had a thread with Live code to receive the stream and put in the named pipe (on both Windows/Linux) and Java thread to read from the named pipe and display the image. Actually Java was unable to properly read from the pipes, so we used some C functions again linked through JNI to actually read and pass the buffer to Java. Anyway, the problem was that the reading part often started to read from pipe BEFORE the frame was fully written, which caused sequences of 2 buffers with wrong content (splitted JPEG) to appear. Our quick and ugly solution was to use second pipe to write 1 byte after main pipe was written, so reading part was blocked until it received that 1 byte and only after that it read from image pipe. We planned to pass presentation time information through this pipe actually because it isn't contained in JPEG. But then we realized that Java was very slow at displaying the received image and this part was abandoned completely.

-----Original Message-----
From: Cristiano Belloni <belloni at imavis.com>
To: live-devel at ns.live555.com
Date: Wed, 09 Jan 2008 13:28:01 +0100
Subject: [Live-devel] Lot of late pictures skipped by VLC

> 
> 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>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>