[Live-devel] Questions about project to dump Images frames from H264 stream using live555 and ffmpeg

[Brad O'Hearne]

David -- If you don't mind, I'm going to piggy-back on your thread -- I have the exact same use case (H.264 stream over RTSP > Live 555 > ffmpeg), and it would appear maybe a very similar problem (though I have a different SDP description).

To all -- I have implemented a MediaSink subclass (based on an adaptation of the DummySink in the testRTSPClient sample), which takes the receive buffer and hands it off to ffmpeg to decode the frame. Note that I've received varying input on whether you need to prepend a start code to the frame first -- I've tried it both with and without, but with the same result. In my case, the problem is that the decoding step in ffmpeg doesn't return any bytes, and logs the following message to the console: 

[h264 @ 0xe2dbc00] no frame!

I know this isn't an ffmpeg support forum, but I'm not seeking ffmpeg support with this question -- I'm merely mentioning it to give a context for the problem. My suspicions are that the problem is in the handling taking place in Live555, not in ffmpeg -- that the decode failure is merely a downstream symptom of a problem handling the stream. 

A few questions:

1. What is the exact nature of the data in the receive buffer at the time that the afterGettingFrame() method of the MediaSink subclass is called, when an H.264 stream from RTSP is in play? 

2. When an H.264 stream from RTSP is in play, is there any massaging of data in the receive buffer that needs to take place prior to decoding an H.264 frame in ffmpeg? Does it need a start code or not, and if yes, does it need a start code every time, or just conditionally?

3. Ross, you seem to know your stuff, so I'd be very appreciative if you or anyone else could take a look at my SDP description and let me know if you see any red flags. My description is below: 

[URL:"rtsp://192.168.1.100:8080/test.sdp"]: Got a SDP description:
v=0
o=- 13553521053896953521 13553521053896953521 IN IP4 boundary
s=N/A
u=http
c=IN IP4 0.0.0.0
t=0 0
a=control:rtsp://192.168.1.100:8080/test.sdp
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42001f;sprop-parameter-sets=Z0IAH6aAyBLk,aM4wpIA=;
a=control:rtsp://192.168.1.100:8080/test.sdp/trackID=0

Thanks,

Brad

Brad O'Hearne
Founder / Lead Developer
Big Hill Software LLC
http://www.bighillsoftware.com

On Mar 2, 2012, at 3:25 PM, David Scravaglieri wrote:

> Ok,
>  
> Thank you Ross.
> 
> David.
> 
> Le 2 mars 2012 à 23:08, Ross Finlayson a écrit :
> 
>>> So what do I have to do now ?
>> 
>> You do whatever you need to do to decode a MPEG Transport Stream.  But (because we don't do decoding or encoding) that's off-topic for this mailing list.
>> 
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>> 
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120305/2cfbe3be/attachment.html>