[FFmpeg-devel] [PATCH] CrystalHD: Use mp4toannexb bitstream filter.
philipl at overt.org
Sun Jun 12 19:03:59 CEST 2011
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the ffmpeg-devel