[FFmpeg-devel] [PATCH] libavcodec/utils: Simplify get_buffer compatibility wrapper.
Michael Niedermayer
michaelni at gmx.at
Mon Feb 17 01:05:54 CET 2014
On Sun, Feb 16, 2014 at 11:57:23PM +0100, wm4 wrote:
> On Sun, 16 Feb 2014 23:43:44 +0100
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
[...]
> > Also, more specifically this might reveal other ways to solve this that
> > does not require so much messy code.
> > Also slightly related, can someone explain to me these code snippets which
> > I've seen in multiple places (e.g. at the end of av_frame_make_writable in libavutil/frame.c)
> > > *frame = tmp;
> > > if (tmp.data == tmp.extended_data)
> > > frame->extended_data = frame->data;
> >
> > Because either the "if" part
> > a) is a completely obvious and stupid no-op, but I can't understand how this was missed, in multiple places to top it off
> > b) isn't a no-op and I don't understand how I can't see it
>
> It's not a no-op. AVFrame was probably designed for video data, but
> then someone came and thought it was a good idea to reuse it for audio.
> Video has only 4 planes max, but audio (ever since "planar audio" was
> invented) can have much more frames. Since the plane array was fixed
> size, and someone wanted to avoid having each AVFrame user allocate the
> data array in the video case, extended_data was introduced to handle
> the needs of audio in case there are more channels than the data array
The problem is not that someone though "ohh lets reuse it for audio"
the problem is that someone thought "lets add a pointer to the struct
pointing to itself".
Doing that makes it impossible to move the structure in memory,
which is what many of these checks are for. First move and 2nd
fix it so that pointer hack isnt breaking. Or check before deallocating
the array
> can handle. The ffmpeg API is fun.
true, though this comes from libav, its in ffmpeg just for
compatibility
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140217/7a7cdd6d/attachment.asc>
More information about the ffmpeg-devel
mailing list