[Ffmpeg-devel] RTP patches & RFC

[Ryan Martell]

On Oct 12, 2006, at 4:29 PM, Ryan Martell wrote:
> On Oct 12, 2006, at 5:29 AM, Michael Niedermayer wrote:
>> Hi
>>
>> On Wed, Oct 11, 2006 at 10:41:36PM -0500, Ryan Martell wrote:
>> [...]
>>>>
>>>> either way you should set AVStream->need_parsing=1 and leave the
>>>> merging
>>>> of packets to the AVParser
>>>
>>> Okay, sorry to be dense about this, but I'm still confused.  The
>>> packets that come over rtp have their size indicated in various  
>>> ways,
>>> depending on the packet.  That information is NOT in the NAL, and  
>>> the
>>> NAL is NOT preceeded by the start sequence.  So what I was doing was
>>> converting them to AvC style (preceded by length) packets.  This is
>>
>> iam more in favor of adding the startcode prefix instead of the  
>> length
>> i dont think the avc style length stuff is supported by our AVParser
>>
>
> I changed the code, so that in my init routine you can specify if  
> you want the bitstream version or the avcc version.  Both work, as  
> long as I don't set needs_parse= 1 for the stream.  When I do that,  
> I never get past the setup code (I don't know why).  (Maybe it's  
> because I only had 001 instead of 0001 on the sps/pps packets, from  
> derk above?).  This is the same issue i was having when i first  
> started this, where there was no data in the extradata field, it  
> wouldn't get to the point where it showed the stream types.
>
>>
>> it doesnt need the pts for this, it will analize the nal units
>
> This doesn't work for me; probably because I am not using the  
> AVParser yet?

Okay, if i change the code a bit, I can get the AVParser to do my  
conglomeration of packets for a given frame.

As the code stands, it can generate either AVCC style or Bytestream  
style streams.

It didn't look like the AVParser knew how to handle AVCC style  
streams, so if I change the code, it will break the AVCC stuff.

So, should i leave it as is (where it works for both), or modify it  
to use the AVParser, which reduces code size (it gets rid of  
put_packet_at_head_of_queue and create_frame_packet)?

  I still seem to have random frame rates (sometimes it's 10,  
sometimes 29.97).  I am thinking that using AVParser should get me  
closer to getting my video/audio in sync.