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
