i stumbled across a very odd thing when i tried to playback MovieTextures like in the mediaplayer code.
the movies didnt run smooth, so first i blamed the weak cpu, but then i notice panda itself ran at 800fps and there was plenty of cpu power left for decoding.
so i tried a lot of different codes, video, audio, on windows an linux , on 2 different computers. and it was the same for every combination.
the video only drew every second frame, cutting the effective video framerate in half and producing nonsmooth playback this way.
can anyone else confirm this bug?
[EDIT] it appears that this also introduces a lot of visual glitches for codecs that rely on the last frames visual content (most modern codecs like h.264 mpeg do so).
Is this in the trunk or 1.8 version, or in a 1.7.2 or earlier version? There were some issues with ffmpeg decoding that I recently fixed.
I’m also, incidentally, working on some further performance issues in there as we speak, by offloading the video decoding onto a secondary thread if requested.
hm… it is in the daily build. in 1.7.2 i could not test anything cause any codec other then the one used in the sneezing panda failed to play.
my linux panda version is from 5th okt. the windows one is build 368 (8th november). both versions are affected.
i do not remember having choppy playback when i worked with it in march. so i guess it is a bug that sneaked in during the last 6 month or so.
I haven’t seen any problem with any of my videos; perhaps there’s something unique about this one? Can you perhaps post it where I can try it out as well?
it is not one particular video. it affects everything i tested. big bucks bunny, sintel, a whole set of videos i had on my disks. i also tried to change encoding of sintel clips. mjpeg, h.246, h.236, mpeg2, divx5,YV12 (raw). same for all.
good thing is: ffmpeg spams me with warnings every frame it decodes. so i set up a task that prints the time every 1./24 second (movies has 24 fps)
as you can see, 2/24 second pass between each frame.
that makes 12 fps for the actualy decoded frames. the movie is still in sync with the audio, it just skips every 2nd frame.
setting the playback rate to 1/24 allows me to count frames,too. one every 2 seconds.
the effect is less noticeable for movies with 29 or 30 fps. but still pretty visible for scenes with motion if you have a side by side playback with vlc-player.
the effect is subtle, especially for movies with 29 or 30 fps. try setting the playrate to 1/fps. if you get one frame second, it is ok. if you wait 2 seconds for a frame. then you have the bug.
output from debug (the tick task is still running):
:movies:ffmpeg(debug): Sliding forward to 6.00195 from 6
:movies:ffmpeg(debug): Wanted 6.00195, got 6.08333
:movies:ffmpeg(warning): No accelerated colorspace conversion found.
tick 1320882601.34
tick 1320882601.38
:movies:ffmpeg(debug): Sliding forward to 6.08573 from 6.08333
:movies:ffmpeg(debug): Wanted 6.08573, got 6.16667
:movies:ffmpeg(warning): No accelerated colorspace conversion found.
tick 1320882601.42
tick 1320882601.47
....
looks like the problem pops up in the numbers there,too.
i tested 60fps movie that had every frame double.
it displayed 30 and showed smooth playback.
oh and. another bug. i can open movie files ok. but when i open the same movie a 2nd time, it crashes.
:movies(error): Seek failure. Shutting down movie.
i can load as many movies as i want, but when i want to play a file i already opened, bang.
how are chances to get those bugs fixed before december? i sorta wanted to deploy stuff end of november but if they presist i have to hack some vlc player or so.
I’ve just committed several tasty fixes, please give them a try and see if it solves this issue for you. It should also improve performance considerably.
I haven’t been able to reproduce this problem:
partly because I don’t understand what you mean by “open the same movie a 2nd time”. If you use loader.loadTexture(), of course, you actually get the same Texture object back, and there’s no problem–but both instances have to show the same frame. If you create a MovieTexture explicitly and use tex.read() to explicitly re-read the same file, so you have two compies of the same file open that you can set to different frames, then again there’s no problem, because they are two completely unrelated copies of the same file.
What else might you mean by “open the same movie a 2nd time”?
i researched a bit more.
the first movie i load with this function runs fine,i can re-load it as often as i want.
i can also load any other movie, but those i can only load once. when i load any movie (except the first one i loaded) again, then it segfaults.
one interesting exception of that rule is the sneezing panda video. that one is perfectly fine no matter how often or when i load it. unfortunately i dont even have an divx encoder to test other vids with that codec. but even divx is affected by the half-fps bug. wasn’t able to test your patches so far.
i will test as soon as the buildbot is finishes the new version. i dont have a build environment set up right now.
performance improvements are also very very welcome as i run that on an atom-cpu. so, my very personal thanks for optimizing that one,too.
the good news: it did fix the half-frame issue for all videos.
more semi-good news. the crash-on-2nd-play is now less present. it still crashes if i play mjpeg encodes a 2nd time. some h.246 codecs run perfectly fine, other crash right away on first load.
i totaly cant find any differences in the files that run an the ones that dont.
and, indeed. decoding videos now takes a lot less time! big thx for that.
i will be testing all sorts of videos,container,codecs and encoders and report back as soon as i figured out what combination triggers the segfaults.
once again. thanks for your patch it really helped me out.
pretty much all formats i tested work when encoding with “mencoder”.even the one that crashed earlier. so i guess this is more an issue of avidemux output or so. anyway videos now work pretty well. thanks a ton.
one thing you may wish to fix, as videos now spawn a new thread, they also appear as such in the pstats window-menu-bar. opening new videos will add more and more entries to the menu, old ones apparently are not removed, their stats data remains accessible.
Interesting. It must be something with the sound channel, since the video channel is completely unique in this case, but your sound file is the same object (due to loader.loadSfx() returning a handle to the same object). Perhaps you could try forcing a new sound file to load with AudioManager.uncacheSound(filename). Edit: loader.unloadSfx() is probably the better interface to do this rather than low-level AudioManager.uncacheSound().
Oops, yeah, this is a PStats bug. I wasn’t thinking in terms of threads coming and going when I built this PStats interface, so there’s no removal of a thread from the menu after it stops. Hmm, I’ll definitely have to do something about that.
Do you get the same warning when you just run pview on the video file? Did you get this warning prior to today’s fixes? Can you post the video file where I can try it too?
