On Sun, Sep 18, 2016 at 01:46:07PM +0200, Timo Rothenpieler wrote: > Fixes a crash when decoding with for example h264_cuvid, as > avpriv_h264_has_num_reorder_frames assumes the AVCodecContext->priv_data > to be a H264Context. > --- > libavformat/utils.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)
Relevant IRC discussion: <michaelni> BtbN, JEEB why is st->internal->avctx not the libavcodec software decoder ? <BtbN> because it's the cuvid h264 decoder. <michaelni> I mean if this is the hw decoder you would be running the hw decoder twice <michaelni> once in the application and once in libavformat <michaelni> is that intended ? <BtbN> hm? <michaelni> or am i misunderstanding? <BtbN> the cuvid h264 decoder is completely inside of lavc, completely independend from the outside <michaelni> sure but libavformat opens a decoder to get some information about a stream, if thats the hw decoder then there would be 2 as the user app would also have a decoder independat of libavformat <BtbN> It indeed seems to open it twice <BtbN> But I don't see anything I could possibly do about that from inside of the cuvid decoder, and it also works just fine. <michaelni> not from the inside but the code setting up st->internal->avctx should maybe not open a hw decoder <michaelni> or if we want it to do that then indeed the avpriv_h264_has_num_reorder_frames() call is garbage <BtbN> Forcing it to use the software decoder for the initial parsing seems like the better solution. As it returns way more information about the stream. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
