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? Thank. -- Best regards, Ivan mailto:ivan.us...@nablet.com _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
