> > The difference is that "avcodec_decode_video" in case of multithreading > simply always returns 0 and sets "*got_picture_ptr" to 0 for the first > packet. > I (obviously falsely) interpreted that as end of video. If you just ignore > it and go on then it works. > Now I extended the end of video test to also include a "no more packets for > that stream" condition. > I did not used return value because it useless (for me)! I feed the avcodec_decode_video() until has packets and got the frame when (got_picture_ptr != 0). I really don't care if decoder failed to decode some packets (probably broken stream or error in decoder itself) - if something wrong than errors often come into console from FFmpeg itself. I interested only in valid frames ;).
By the way, is there a reliable way to know if you have read the last packet > of a stream before you reach end of file? > Have no idea what for you need this... I read context(s) until them has packets. And then you may determine that 'previously' decoded packet was last :D. 2011/3/27 Ole Dittmann <[email protected]> > Think I got it now! > > The difference is that "avcodec_decode_video" in case of multithreading > simply always returns 0 and sets "*got_picture_ptr" to 0 for the first > packet. > I (obviously falsely) interpreted that as end of video. If you just ignore > it and go on then it works. > Now I extended the end of video test to also include a "no more packets for > that stream" condition. > > By the way, is there a reliable way to know if you have read the last > packet of a stream before you reach end of file? > Otherwise you will always have to read (and probably buffer) all the rest > of a file until you know that one stream ended which would become > problematic if you have files with very differing stream lengthts. > The given length of a stream or number of frames is unfortunately not a > very reliable source as in case of many transport stream formats it is not > existant at all and for others like wmv it is just "guessed". > You may also stop after some maximum interleaving length but that appears > complicated to me and for my experiences the correct detection of less used > parameters like that is again very format dependent. > > > Am 25.03.2011 19:31, schrieb Kirill Gavrilov: > > So the difference must be somewhere in my using code on visual studio side. >> Unfortunately that code is a bit more complicated but at least I know >> where to search now. >> > Good luck! > > - If you set ffmpegs --arch configure option to x86_32 then you are not >> able to use swscale lib with resolutions above 2048. I use just --arch x86 >> for 32 bit and --arch=x86_64 for 64 bit, that leads to ARCH_X86 defined and >> sets that resolution border up to 5120 (see swscale_internal.h, line 36 ff). >> Maybe there are also other Implications like optimizations - I dont know. >> > Thanks for your information. Actually I already knew about that limitation > but not yet investigate how to increase it. > 5120 is not applicable for me too however for main purposes I didn't use > swscale at all. Planar yuv -> rgb conversion performed via GLSL shader in my > application > and this is much faster... I need swscale only for formats that I natively > not support and to convert format when save the image. > > - I think you are using the lib files that mingws dlltool created. That >> turned out problematic for me in bigger projects with more references >> because It seems there are much more... >> > Nope. I do that in very... strange way ;). Actually I created dummy > projects (in my main IDE Code::Blocks) with exported functions that I need > with empty body. > Thus I generate the .lib files via the msvc and that libraries work perfect > with both - msvc and MinGW linkers later. > ----------------------------------------------- > Kirill Gavrilov, > Software designer. > > _______________________________________________ > Libav-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user > > ----------------------------------------------- Kirill Gavrilov, Software designer.
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
