[FFmpeg-devel] [PATCH] Add a priv_data pointer to AVFormatParameters

Andy Parkins andyparkins
Wed Oct 3 16:24:29 CEST 2007

On Wednesday 2007 October 03, Michael Niedermayer wrote:
> > The solution is this patch; we add a priv_data pointer to
> > AVFormatParameters.  AVFormatParameters is created filled with NUL bytes
> > by default so if the user chooses not to supply priv_data, the custom
> > read_header() will receive a NULL priv_data pointer.
> rejected

Okay, it's not problem to me.  Although I think you're rejecting it because 
you think I'm on a secret mission to create a new muxer format that I'm not 
going to share.  Is there some technical reason you're rejecting it?  I'd be 
happy to try and "do it the right way", if that's possible.

It just occurred to me that someone else might one day want to do the same 
sort of thing as I am doing.

> > If the user _does_ want to pass some custom options to their custom
> > read_header() they can make a AVFormatParameters structure and pass
> > whatever they want through by setting priv_data.
> the user should submit their "custom" demuxer here for inclusion in svn

I don't think you'd want it.  It's just a wrapper around the existing RTSP 
input format.  In essence it sets a few variables, issues a couple of log 
messages in it's read_header() implementation, and everything else is just a 
pass through to the real input format - RTSP.  It also lets me get at the UDP 
and TCP handles used by the RTSP input format.  As I say, I doubt very much 
that you'd want it.

I'm also hoping that it will eventually let me solve the problem in 
libavformat/rtsp.c:udp_read_packet() that causes ffmpeg to lock up 
permanently when RTP packets stop coming in, but I'm not sure how just 
yet :-)

Dr Andy Parkins, M Eng (hons), MIET
andyparkins at gmail.com

More information about the ffmpeg-devel mailing list