<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span style="font-size: 12pt;">Firstly, I'm loving the live555 libraries, if you're reading Ross - a big thank you for making this open source! I've learnt a lot about the technologies from running up and debugging through the source code :o)</span><br></div><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"><div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"><div id="yiv1811178887"><div><div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"><div id="yiv1811178887"><div><div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"><br>I've been using the RTSP client of
live555 to receive a 'full-hd' stream of H264 encoded video over RTSP, sent by VLC (2.0.5). I have been using the NAL units sent from live555 (via H264VideoRTPSource) and passing them directly (no packetizer or grouper e.g, just prefixing the start code) to a Media Foundation H264 decoder. This worked perfectly, so then I changed decoder to avcodec (ffmpeg libraries) and the same video
source has corrupted decoder output (sort of grey smudges with bits of the actual frames in).<br><br>I've been reading through the live555 code and searching through posts on forums to try and see if this is
a issue with live555 or the av decoder. FYI, the same RTSP stream works in VLC as client, but *only* with the use of a H264 packetizer in between the RTSP and decoder modules. What I see if I WireShark the RTP packets is what looks like several NAL units per timestamp, and when I debug VLC I notice these are "collected" by the packetizer before being presented to avcodec, but my code just passes these one by one to avcodec.<br><br>Then I found this post, which seemed to indicate the person asking the question was seeing H264 over RTP with a similar nature:<br><br>http://stackoverflow.com/questions/6756770/libavcodec-how-to-tell-end-of-access-unit-when-decoding-h-264-stream<br><br>So as an experiment I have put some extra code in my RTPSink which collects these NAL units together based on the RTP timestamp and then I pass this collection to the decoder. This appears to work perfectly with both avcodec and the media foundation h264
decoder.<br><br>I've sent a lot of other H264 streams fine from VLC, but only the full-hd ones seem to need this "collection" method in my live555-based client. These other streams play just fine using avcodec just passing the NAL units directly to the decoder.<br><div id="yiv1811178887yui_3_7_2_17_1363001920968_39"><br></div><div id="yiv1811178887yui_3_7_2_17_1363001920968_39">I'm not asking VLC to re-encode the footage just read the .mov file (H264/AAC) and serve it up as RTSP - which makes me wonder if the source file was encoded in a non-standard way, somehow fragmenting the NAL units or maybe splitting them down because the units are so large being for full hd?</div><div id="yiv1811178887yui_3_7_2_17_1363001920968_39"><br></div><div id="yiv1811178887yui_3_7_2_17_1363001920968_39">I'm happy enough leaving the collection method in my RTSP client, maybe perhaps just for H264, but I was wondering if this is masking a problem with something else,
or
maybe collecting by timestamp isn't a good idea for some reason?</div><div id="yiv1811178887yui_3_7_2_17_1363001920968_39"><br></div><div id="yiv1811178887yui_3_7_2_17_1363001920968_39">Thanks in advance for any suggestions,</div><div id="yiv1811178887yui_3_7_2_17_1363001920968_39">Mark.</div></div></div></div></div></div></div><meta http-equiv="x-dns-prefetch-control" content="on"><br><br> </div> </div> </div></body></html>