[FFmpeg-devel] [PATCH] Use the actual RTSP peer IP for RTP sessions

Michael Niedermayer michaelni
Thu Mar 11 00:36:57 CET 2010


On Wed, Mar 10, 2010 at 10:35:09PM +0200, Martin Storsj? wrote:
> On Tue, 9 Mar 2010, Michael Niedermayer wrote:
> 
> > I assume you know how AVOptions are used to set things in AVFormatContext
> > the idea is to do the same with AVFormatContext->priv_data
> 
> Ah, I see. That generally feels like a good idea. However, here's the list 
> of open questions in this approach, as far as I can tell from the code:
> 
> Should one be able to do av_set_string3() directly on an AVFormatContext, 
> with the name of a private context option, and this should either succeed 
> or fail depending on which (de)muxer it actually is? In that case, 
> av_find_opt would need to be extended to look for options other than just 
> the list found in the AVClass.

this would be nice but not essential in an initial implementation
Maybe a offset in the AVClass struct could point to priv_data
or NULL for structs not having a priv_data with its own AVClass


> 
> Or if we're supposed to do the av_set_string3() on 
> AVFormatContext->priv_data instead, we would have to make sure all 
> instances of priv_data actually has an AVClass.
> 
> In ffmpeg.c/cmdutils.c, the options are temporarily stored in an 
> AVFormatContext before they're later applied to the actual muxer using 
> set_context_opts. In this scenario, setting a muxer-specific setting 
> wouldn't work since the temporary AVFormatContext wouldn't have the 
> private data for that particular muxer.

hmm, that may need a little redesign then
i never liked that storing of things in that temporary contexts

either way codec specific options would make alot of people happy
i think, personally i never understood it but it seems people really
dont like adding their stuff to a ever growing context

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100311/32b93201/attachment.pgp>



More information about the ffmpeg-devel mailing list