[BUG]Movie texture only decoding every 2nd frame

So, using today’s CVS and after generating a Windows built

if the movie file is directly dropped into pview:

my movie test file is around 1Gb, I’ll try to megaupload it, but it may take some time…

any faster way to upload?

ok, I have another one to drop into pview

uploading.com/files/9377a5bm/test_2.avi/

2shared.com/video/1VV_il5X/test_2.html

the :movies::ffmpeg(error) warning here are differents

try this one for immediate crash!
uploading.com/files/1314136f/test_3.avi/

test_3.avi runs fine for me on linux, just the regular warnings about non accelerated color-space.

OK, I found and fixed a few more problems. Please give it another try. Thanks for your help!

Edit: Thomas, I didn’t do anything with the multi-load movie issue yet. Not sure what’s going on with that.

David

No more crashes but still getting plenty of

tons of it for test2.avi file!

for test3.avi

And still getting tons of spam on my test1.avi

When this warning starts the displayed movie texture remains black…

so i am back from testing on my windows target machine with the latest daily build.

my mencoder movies run perfectly fine now. both , mpeg4 and mjpeg perform good, no warnings no errors. that atom-cpu even chews 720p pretty well.

i did try a 1080p vid (just for fun and testing) with 120Mbit/s video stream (even blueray is only 50MBit/s or so) and i got a whole bunch of the errors jean-claude is getting. but i don’t get those for regular videos.

once again drwr, thanks a lot. if i ever open up a national park/panda protection park you will get your own monument :smiley:

FYI. Tried again this morning with latest CVS… still the same symptoms as Saturday!
Use of pview - build on Windows

jean-claude: these error messages are coming from the ffmpeg library which we use to decode the video. Maybe there really is something wrong with the video files? It’s possible to squelch the error messages by adding the line:

notify-level-ffmpeg fatal

to your Config.prc file. However, this won’t help you for the file that displays black when the error messages start. It sounds like my latest “fixes”, which make Panda more responsible about responding to error conditions reported from ffmpeg, are actually causing you problems here by making Panda refuse to display a video that’s reporting errors, even though it may be possible to display it anyway.

I can’t reproduce this problem with my own videos. If you can post your test1.avi somewhere in spite of its size, or find a smaller video that demonstrates the same problem, I’ll be happy to try to make Panda work around the problems that ffmpeg is yelling about.

Edit: I do see a problem with your test_2.avi going black after playing the first time through. Investigating.

David

Hi David,
Here are some more details after additional testing.
I’ve been using test1.avi (which I’ll be uploading in the next hour).

(1) Launched it with the latest pview built this afternoon (Paris time) from CVS.
The only warnings I’m getting are:

Then it runs fine upto the end

(2) BUT!!! :exclamation: Whenever launched in my app.
Don’t get any warnings at all… upto the time the quad on which the video is expected to play becomes visible by the camera.
At this point, ffmpeg starts spamming:

and the quad remains black!

So:

at init the camera is not looking at the quad: :slight_smile:
as soon as the quad is supposed to be seen : :frowning:

fyi, code used to attach the video

PT(Texture) stagescreen_tex = TexturePool::load_texture("test_1.avi");
cmp.set_frame(-32*dm, 32*dm, -24*dm, 24*dm);	
cmp.set_uv_range(stagescreen_tex);

NodePath stagescreen = stage.attach_new_node(cmp.generate());
    stagescreen.set_effect(CompassEffect::make(render, CompassEffect::P_scale));
stagescreen.set_texture(stagescreen_tex);
stagescreen.set_pos( 140*dm, 80*dm, 60*dm); 
stagescreen.set_two_sided(true);
stagescreen.look_at( 140*dm, 160*dm, 60*dm); 
stagescreen.set_light(evambientLightNP);

BTW. It may well be that this is likely to happen with others avi. I’m on my way to check it!

Tried exactly the same approach with test_2

(1) at init (with quad not visible by the camera): one junk message then ok
(2) as soon as the quad is in the camera’s frustum:
spam, spam, spam…

funny enough: apparently there’s always an offset of 2 bytes?!?

BUT: in this case, the movie plays!

I’m not able to reproduce this spammage. My copy of your test_2 plays fine with no per-frame error messages. Curious.

David

(1) here is test_1.avi
rapidshare.com/files/250936288/test_1.avi

please note that this file is insanely heavy!!

(2) again, with pview things are almost ok (apart 1 or 2 warnings)
but the issue pops up whenever the app is started with no view on the video (ie video not visible by the camera) and then while moving the camera as soon as the quad supporting the video display enters in the camera frustum.

please note too: that I have 4 task_chains threaded, but the video is simply loaded as mentionned in my previous post…

I’m puzzled, wind back:just with test_2 on pview, aren’t you observing a spam with this???
rapidshare.com/files/3078077278/pview.exe
rapidshare.com/files/1990279957/test_2.avi

Nope, and not with the buildbot Panda3D-1.8.0 neither. It plays happily, quietly. Maybe it’s a difference in the codecs we have installed on our machines; maybe it has something to do with CPU performance. Who knows?

David

Did you try my pview (it is compiled with SSE2 and aligned Z16)? Maybe this is related (ie byte alignment shift…)

btw. I just noticed you made some changes in the cvs (ffmpeg…). Let me regenerate a build!

with the latest cvs I’m now getting this build error:

I think it’s time for me to go to bed!
Tomorrow is another day…

I can’t run your pview.exe without also having your libpanda.dll, libp3dtool.dll, and so on, as well as any thirdparty dll’s your build is made against (including ffmpeg if required).

Sorry about the build error; I just committed a fix that might address it. Not entirely sure why this latest version presents this build error that wasn’t a problem in earlier versions. But my latest fixes don’t do anything about your ffmpeg errors, so I don’t think it will help this particular problem much.

David

jean-claude, another thought occurred to me: does setting “ffmpeg-max-readahead-frames 0” in your Config.prc file improve the error situation in your case? This disables the use of threads in ffmpeg playback; I’m wondering if the problem might be a subtle race condition somewhere.

David

Hi David,
Just tried to run test_1.avi with:

load_prc_file_data("", "support-threads 0");
load_prc_file_data("", "ffmpeg-max-readahead-frames 0"); 
load_prc_file_data("", "sync_video 1");

Same effect, apart that the fps is now divided by 12!
This occurs as soon as the camera is ‘looking at’ the video quad

Just for the record the same file used to work ok in the app a few weeks ago… Weird!