[Ffmpeg-devel] h264/rtp transport (RFC 3984)
Wed Oct 4 22:26:28 CEST 2006
Okay, I'll look for that as well.
To make sure I understand:
The decoder needs to have all the nals for one frame (based on
timestamp?) in the same AVPacket.
Currently, I'm just using the same code in rtp.c, and modifying it,
so once I hand it a packet, I have no idea what it does with it (I'll
follow that path as well).
If not with timestamp, how do I know when there is a new frame?
On Oct 4, 2006, at 3:14 PM, Michael Niedermayer wrote:
> On Wed, Oct 04, 2006 at 02:40:33PM -0500, Ryan Martell wrote:
>> Okay, so I'm really, really close to implementing h264 over rtp (per
>> RFC 3984).
>> I am getting video, but there is lots of grey. I am getting lots of
>> "Concealing 150 MV errors, .." messages.
>> I have looked over my byte manipulations all morning, and I am pretty
>> sure that I am decoding the stream correctly, and creating the AvCC
>> stuff from the SDP announce (I have verified that my code produces
>> the same avc block as the file that is sourced from the server). I
>> am prepending a 4 byte NAL packet length to the start of every
>> packet, so it goes through the AVC loop just fine. Byteswapping all
>> looks good.
>> So... I'm thinking that the problem has to do with my timestamps and
>> sequence numbers. I'm going to start looking into this right now,
>> but if anyone knows whether that would account for lots of grey
>> (including grey on the bottom half of the full frames?), I would
>> appreciate knowing that I am on the right track.
> this sounds a little like you feed incomplete frames into the decoders
> this is not supported concatenate all packets for one frame and then
> give it to the decoder, you can also use a AVParser to do that for
> you ...
> Michael GnuPG fingerprint:
> In the past you could go to a library and read, borrow or copy any
> Today you'd get arrested for mere telling someone where the library is
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel