[Ffmpeg-devel] RTP patches & RFC

Ryan Martell rdm4
Thu Oct 26 05:09:58 CEST 2006

FYI, I have solved my A/V sync issues, and the h264 rtp streaming is  
functionally complete.

If you run under UDP, it times out after 2 minutes (due to not  
getting the Statistics).  Once we get the statistics sending code in  
to the base and my code in, i'll integrate the two to get this working.

If you run under TCP, it works indefinitely.


On Oct 25, 2006, at 9:02 PM, Ryan Martell wrote:

> On Oct 25, 2006, at 7:56 PM, Michael Niedermayer wrote:
>>>> but note, i wont reject this because of the {} placement if you
>>>> disslike
>>>> it (fixing it myself would just need ~5min or so ...)
>>> Hope this is a winner; I really want to get the rest of this  
>>> stuff in...
>> could you document the fields of RTPDynamicProtocolHandler?
>> and rename the following, unless i missunderstood their intent,  
>> but their
>> current names really confused me :)
>> protocol_new_extradata_proc()    -> open()
>> protocol_free_extradata_proc()   -> close()
>> protocol_handle_sdp_a_line_proc()-> parse_sdp_a_line()
>> dynamic_protocol_data            -> dynamic_protocol_context
>> protocol_handle_packet_proc      -> parse() or parse_packet() or  
>> even handle_packet()
>> dynamic_packet_handler()         -> parse_dynamic_packet()
> Done.
>> and what would be your oppinion about changing
>> DynamicPayloadPacketHandlerProc to RTPDynamicProtocolHandler in
>> RTPDemuxContext? i think it would be better to have the whole struct
>> available instead of just one function pointer from it
> I can do that, but then I'm keeping it around even more places  
> (beside the internal copy in rtsp.c).  The only thing i need in the  
> rtp.c code is the handle_packet() function, so instead of a double  
> dereference on every packet, i was just going to do one.
>> also a  int priv_data_size; could be added to  
>> RTPDynamicProtocolHandler
>> similar to the other stuff in lav* so that the context alloc/free  
>> can be
>> done outside/without open/close
> No, because I have pointers to pointers in there; it's not just a  
> flat allocated block.
> So, barring the above two, here's the newest patch.  (I really want  
> to get this in, so I can get working on the h264 stuff.  I'm still  
> having an audio sync issue, and I've also found a bug in the rtp/ 
> aac stuff (mono doesn't work) that i've fixed...)
> <patch.txt>
> <rtp_internal.h>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list