[FFmpeg-devel] [PATCH] rdt.c: don't reuse the same AVStream in both RTSP and RM demuxer

Michael Niedermayer michaelni
Fri Dec 19 10:56:58 CET 2008


On Thu, Dec 18, 2008 at 09:38:54PM -0500, Ronald S. Bultje wrote:
> Hi Michael,
> 
> 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

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

It is not what we do, but why we do it that matters.
-------------- 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/20081219/e84c2b4d/attachment.pgp>



More information about the ffmpeg-devel mailing list