[FFmpeg-devel] [PATCH] rdt.c: don't reuse the same AVStream in both RTSP and RM demuxer
Ronald S. Bultje
rsbultje
Fri Dec 19 14:05:02 CET 2008
Hi,
On Fri, Dec 19, 2008 at 4:56 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Thu, Dec 18, 2008 at 09:38:54PM -0500, Ronald S. Bultje wrote:
>> On Thu, Dec 18, 2008 at 9:18 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Thu, Dec 18, 2008 at 08:54:36PM -0500, Ronald S. Bultje wrote:
>> >> On Thu, Dec 18, 2008 at 8:36 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> >> > On Wed, Dec 17, 2008 at 09:17:01AM -0500, Ronald S. Bultje wrote:
>> >> >> as a continuation of [1], which implemented support for multiple
>> >> >> streams of the same type (audio, video) in a single RM stream, this
>> >> >> patch separates the RTSP demuxer AVStream from the RM demuxer AVStream
>> >> >> in RDT. This is needed because some variables in the AVStream context
>> >> >> (e.g. priv_data) have a different meaning in RM than in RDT and can
>> >> >> thus not be shared.
>> >> >
>> >> > how hard (and ugly) would it be to make them shareable?
>> >>
>> >> Practically impossible, the st->priv_data value would clash (it's a
>> >> RTSPStream for RTSP and a RMStream for RM), I'd have to change it in
>> >> every single function call... I'd love to do that, but it's not
>> >> clean...
>> >>
>> >> Unless we come up with a way to assign multiple priv_data fields to a
>> >> single AVStream or something along those lines. (?)
>> >
>> > hmm, i see the problem
>> > I just fear that copying could become a source of bugs
>> >
>> > would
>> > stream->priv_data=a;
>> > some_call_in_the_rm_muxer()
>> > stream->priv_data=b;
>> >
>> > work easily?
>>
>> It would work. My fear is that it's ugly, similar to the
>> AVFormatContext->pb discussion we had a few weeks ago. If it's OK, I
>> can attempt that.
>
> well, can the shared functions be changed to not use priv_data ?
> otherwise we have no choice, its then either this uglyness or
> cloning streams ugliness
I can add RMStream as a function argument...
Ronald
More information about the ffmpeg-devel
mailing list