[FFmpeg-devel] CrystalHD: Correcting use of h264 parser

[Michael Niedermayer]

On Sat, Jun 04, 2011 at 03:18:22PM -0700, Philip Langdale wrote:
> Hi all,
> 
> It's been pointed out on the mplayer list that the way the
> CrystalHD decoder uses the h264 parser leads to memory leaks
> under certain circumstances. I'd like to get some advice on
> how to correct this - there's no direct usage of parsers in
> any other decoder so I have no examples to go by. Additionally,
> I don't even use the parsed data - just metadata.
> 
> Today, I set up the parser in the decoder's init function and
> then call it on each decode() call to retrieve the h264 picture
> structure information. I then ignore the out buffer and 
> pass the original stream to the hardware.
> 
> One obvious thought is that I should be explicitly freeing the
> out buffer returned by parse2(), but it doesn't look like the
> implementation of the parser is allocating anything.
> 
> Reimar says I should be using COMPLETE_FRAMES, which has been
> discussed before, but my past attempts have lead to the parser
> freaking out and not working at all - he then went on to say
> that the parser only supports annex b - and as most content
> I test with isn't in annex b format, that would explain the
> failure. So, it sounds like I would need to run the stream
> through the annex b filter and then into the parser to allow
> for COMPLETE_FRAMES to work and then the leak should go away?
> 
> That sounds like a lot of overhead for a single metadata field.
> 
> Is there anything simpler I can do?

you could add mp4-style support the parser then the bitstream filter
wont be needed. That wont the simpler in terms of work but the final
solution would look simpler

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- 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/20110605/ea8b26a9/attachment.asc>