[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 :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins at gmail.com
More information about the ffmpeg-devel
mailing list