[Ffmpeg-devel] RTP patches & RFC

[Michael Niedermayer]

Hi

On Wed, Oct 11, 2006 at 10:41:36PM -0500, Ryan Martell wrote:
[...]
> >
> >[...]
> >> 4) I am using my own packet queues.  This means that a packet comes
> >>in (from network), gets allocated and copied to a packet, and once a
> >>full frame is received, is conglomerated and
> >>    copied into an AVPacket.  I got rid of the extra allocations and
> >>reallocations and copies with the fragmentation packets (see the
> >>add_h264_partial_data)
> >
> >either
> >A. you support out of order packets (like with a n packet buffer which
> >   reorders packets) and then after reordering you output them
> >B. you output packets in their order and fragmentation
> >
> >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


> step one, which I don't think the need_parsing can handle for me  
> (right?). 

yes, the AVParser expects a mostly complete h.264 stream


> (Or does the AVParser know enough about h264 nals to  
> determine where they start and end?).  There are no sequence packets  
> in the stream (it relies on the rtp timestamps).  Furthermore, if  
> they are fragmented, they aren't just a fragmented bitstream, they  
> have header data that must be stripped first, and they have to be  
> accumulated, and only if certain parameters are met.
> 
> Step two, is accumulating all of the packets with the same timestamp  
> into a frame.  I can see how the AVParser could do this for me, based  
> on the pts of the packet.

it doesnt need the pts for this, it will analize the nal units


[...]
> >>
> >>struct h264_packet {
> >>    uint8_t *data;
> >>    uint32_t length;
> >>    uint32_t timestamp;
> >>
> >>    struct h264_packet *next;
> >>};
> >
> >timestamps probably need to be 64bit
> 
> they're only 32 bit in the rtp packet.

ok, if you just compare them for equality then thats fine otherwise
you should use libavformat/utils.c lsb2full() to make 64bit timestamps
out of them as they will overflow after ~ 13h (assuming 90khz) and
13h isnt that long ...


[...]
> 
> >>//    av_set_pts_info(s->st, 33, 1, 90000);
> >
> >you must set the timebase correctly (the default of 90khz is very  
> >likly not
> > correct)
> 
> h264/rtp is automatically 90khz. It's also specified on the sdp line,  
> but it will always be 90kHz.  

what does the ADJUST_TIMESTAMP or whatever it was called code do then?


> Is this the correct way to set it?

yes, though the 33 should match the number of bits in the AVPacket->pts


[...]
> I'm also having to get the rtsp rtcp packet (receiver reports)  
> working, because that's why the server is cutting me off after two  
> minutes.

great


> 
> Finally, I can give a Blocksize parameter to the server on RTSP  
> initial handshake.  With this, I could specify a maximum packet size,  
> which would allow me to preallocate all of my internal packets (using  
> around 2k buffers each, since MTU is 1500 by default).  This would  
> basically mean that there would be initial memory allocation for  
> packets until I had enough in the packet pool, and I could retire  
> them to another linked list and pull them from there.  So there would  
> be no malloc's after an initial startup period.  I think this would  
> be a good thing, but I'm not sure how the rest of FFMPEG feels about  
> memory allocation.  Is this a better approach?

yes, less *malloc() and *free() is better

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is