[FFmpeg-devel] rtpdec_h264.c RTP to annex-b patch

[Matthew Szatmary]

 The stream I'm testing with is generated by a security camera. (And ffmpeg completely chokes). This patch works perfectly for my stream. Thank you for testing an providing a sample stream. I'll modify the patch so it works with this source as well. 

Please ignore this patch for now. I'll post a new version soon. 

Sent from my phone

On Feb 1, 2012, at 3:06 PM, Michael Niedermayer <michaelni at gmx.at> wrote:

> On Wed, Feb 01, 2012 at 09:45:45PM +0200, Martin Storsjö wrote:
>> On Wed, 1 Feb 2012, Michael Niedermayer wrote:
>> 
>>>> The h264_mp4toannexb bsf isn't exactly what's needed in this case -
>>>> the data is in annex b format already, but with SPS/PPS as extradata
>>>> instead of inline in the stream. (This is exactly the same format as
>>>> libx264 outputs if encoding for mp4 files, when the global header
>>>> flag is set, FWIW.) Not sure if there currently is any bitstream
>>>> filter to do exactly this conversion (removing extradata and
>>>> embedding it into the stream) though.
>>> 
>>> dump_extra maybe
>>> 
>>> but in how far that would produce valid annex b iam not sure.
>>> Our decoder will handle it of course but that doesnt mean its compliant
>>> to the spec.
>> 
>> Hmm, that might actually work.
>> 
>>> [...]
>>>> Currently, the rtp depacketizer sets timestamps for all packets, but
>>>> it seems that the h264 parser clears this from the first frame, so
>>>> that it has dts=pts=N/A.
>>> 
>>> that sounds like a bug
>>> 
>>> 
>>>> With the current code, this frame has
>>>> keyframe=1 set, and the mkv muxer will fail to write it with "Can't
>>>> write packet with unknown timestamp". With your patch applied, this
>>>> frame is marked as keyframe=0 by the parser, and ffmpeg.c won't
>>> 
>>> Is it or is it not a keyframe ?
>>> either way this too sounds like theres a bug somewhere
>> 
>> I do think it's a keyframe.
>> 
>> The stream is available publicly in the url as in the previous mail
>> (rtsp://albin.abo.fi:8554/sample_h264_100kbit.mp4), if you want to
>> have a look.
> 
> hmm
> this doesnt look good with the patch, i get 2 startcodes
> 0 0 0 1 0 0 0 1
> then duplicate SPS & PPS
> 
> 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> The worst form of inequality is to try to make unequal things equal.
> -- Aristotle
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel