[FFmpeg-devel] [PATCH] CrystalHD: Use mp4toannexb bitstream filter.

[Philip Langdale]

On Sun, 12 Jun 2011 17:39:56 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Sat, Jun 11, 2011 at 11:07:21AM -0700, Philip Langdale wrote:
> > The H.264 parser that we use to detect interlacing can only handle
> > an Annex B stream, so we need to actually use the filter. This may
> > seem unfortunate as it requires an extra copy, but I suspect the
> > crystalhd library is doing it internally for non-Annex B streams
> > anyway.
> > 
> > This diff seems functional in that it prevents the parser errors
> > I was seeing when playing non-Annex B streams, but it apparently
> > doesn't fix the memory leak that wallak saw. In additional testing,
> > he showed that the filter was the source of the leak, so I must
> > be using it incorrectly, but I'm not sure what I should be doing
> > different.
> > ---
> >  libavcodec/crystalhd.c |   24 +++++++++++++++++++-----
> >  1 files changed, 19 insertions(+), 5 deletions(-)
> 
> the return code from av_bitstream_filter_filter() tells you if the
> output uses the original buffer or a new buffer and thus the original
> has to be freed

So, this confuses me. The mp4toannexb filter either does nothing, and
returns 0, or it goes through a process of 'alloc_and_copy' which calls
av_realloc on the outbuf. On top of that av_bitstream_filter_filter
sets the outbuf to be the input buffer - so the effect is that it
automatically replaces the input buffer with the new buffer. And this
is reflected in my code - if I try and av_free the old buffer, I get
a glibc error that the pointer is invalid. But nevertheless, I see
the memory leak while the program is running.

--phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110612/0ecf3356/attachment.asc>