[FFmpeg-devel] 'ffmpeg' decoder init behaviour

[Michael Niedermayer]

On Wed, Jan 11, 2012 at 09:18:46AM -0800, Philip Langdale wrote:
> Hi all,
> 
> Regarding: http://ffmpeg.org/trac/ffmpeg/ticket/857
> 
> This is a regression in the CrystalHD decoder. When you use the
> ffmpeg command line tool, it will init the decoder to probe the
> file and then re-init it when doing actual decoding. This is fine
> most of the time, but the CrystalHD decoder needs to use a bitstream
> filter to ensure that H.264 content is in Annex B format. This becomes
> a problem because the filter rewrites avctx->extradata and the decoder
> has to test avctx->extradata to decide if the filter is necessary or
> not.
> 
> The end result is that the probe pass works correctly, but then the
> decode pass fails because the content is misdetected. In the older 
> CrystalHD code, I did the extra data detection by hand and had a work
> around that would restore the avctx values after detection. But now
> I use the filter all the way through - and it requires the avctx
> values to be converted and stay converted. Is there anything sane I
> can do to make this work?

Id say the decoder should not write into extradata, it violates the
API. Or less clean it should restore extradata on close when it
modified it on init

The bitstream filter could be given a dummy AVCodecContext with
duplicated extradata

a prettier solution would probably need some thinking and work on API
extensions/changes

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/20120111/fa9e8987/attachment.asc>