[vlc-devel] live555: default video frame size

[Gilles Chanteperdrix]

On 12/28/2013 03:43 PM, Gilles Chanteperdrix wrote:
> On 12/28/2013 03:41 PM, Rémi Denis-Courmont wrote:
>> Le samedi 28 décembre 2013, 15:39:56 Gilles Chanteperdrix a écrit :
>>> To avoid the corrupted video which happens when vlc determines it needs
>>> to double its buffer size (which appears to me to be the reassembled
>>> frame size, and not the rtp packet size), by picking a more sensible
>>> "initial guess"
>>
>> Sorry but this makes no sense.
>>
> 
> I assure you I see corrupted video, with vlc telling me that it doubles
> the "buffer size", on some RTSP streams, with avcodec complaining that
> the frame is corrupted. I hoped I could help solve this issue.
> 
Sorry to insist, I will try and be precise. In:

rtsp://xenomai.org:8554/video-tests/hd-fast.mp4

around 2:06, I get, in the text console:
MultiFramedRTPSource::doGetNextFrame1(): The total received frame size
exceeds the client's buffer size (100000).  1812 bytes of trailing data
will be dropped!
[h264 @ 0x7f76e405d560] error while decoding MB 31 33, bytestream (-24)

In the message logs, I get:
ive555 debug: lost 1812 bytes
live555 debug: increasing buffer size to 200000

The recovery of the H264 frame from the RTP packets happens in live555
code, so vlc's live555.cpp recovers entire H264 frames (or slices, if
the video is encoded with slices). The only case where I believe you
recover packets from live555 and recompose the frames later is if you
receive MPEG TS over RTP, like is the case for the "free multiposte" use
case.

-- 
                                                                Gilles.