[FFmpeg-devel] [PATCH] libavcodec/qsvdec_h264.c bug fixed: decoder fails after restart on non-annex-b content.

[Michael Niedermayer]

On Fri, Jul 24, 2015 at 03:28:22PM +0300, Ivan Uskov wrote:
> Hello Hendrik,
> 
> Friday, July 24, 2015, 2:37:11 PM, you wrote:
> >> The attached patch solves this issue. The corresponded code was taken
> >> from \libavcodec\crystalhd.c which also uses the h264_mp4toannexb_bsf
> >> filter.
> 
> HL> I don't think this is safe. avctx->extradata is user-managed and
> HL> allocated, so mocking with it from within a decoder seems rather
> HL> unsafe.
> I totally agree. In general it is issue of old-old h264_mp4toannexb_bsf.c
> which kills original extradata and silently replaces it by own
> version, with annex-b prefixes. Most fanny fact that this filter
> can not handle correctly own extradata changes if it creates second
> time for the same context.
> 
> I can not patch h264_mp4toannexb_bsf because here can be side effects
> in other codecs which can wait replaced extradata (SPS/PPS transformed
> to annex-b kind) after this filter work.
> Please note that dirty trick with original extradata storing/restoring
> does present currently in another codecs which use h264_mp4toannexb_bsf.c.
> it is libavcodec\crystalhd.c and libavcodec\libstagefright.cpp,
> 
> I can not left libavcodec/qsvdec_h264.c as is because it is not able
> to decode mp4 and mkv at all which is definitely bug.
> 
> Do you have any constructive idea how bad behavior of the
> h264_mp4toannexb_bsf.c can be overcome into the libavcodec/qsvdec_h264.c?
> Should I write own "good" mp4toannexb filter?
> Any other ideas?

it should be possible to add a parameter (passed through args)
which disables extradata mangling to h264_mp4toannexb_bsf

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150724/364822e6/attachment.sig>