Video playback issues on Windows

[jli13]

Hello,

Setup: I was able to recompile the native libraries for desktop with support for mp4. The device I was testing on was a mini PC (Windows 10, Intel Atom Cherry Trail X5 z8300, 2GB RAM). The Libgdx project is just a desktop project that just plays a video upon starting up.

Issue: As far as I can tell, video playback is fine with some videos and just freezes with others.

Additional information: I went and enabled debugging in the videodecoder.cpp and noticed that the issue seems to occur when the number of buffer frames drops to zero (assuming that the buffer index caught up to the buffered frames). In nextVideoFrame(), I noticed that its locking but not unlocking when the number of buffered frames is less than 1 (not sure if this is intentional since the following issue occurs after unlocking). After adding in an unlock before returning, I don't hit the freezing issue anymore but then the video starts skipping back and forth in between frames. (Seemingly jumping back a couple of frames?)

I'm still trying to figure out how everything works so I'm might be doing something completely wrong. Please let me know if you have any idea on what's happening or any suggestions/advice to address this issue.

Thanks!

[RBogie]

It sounds like it's not able to decode more frames. Does this always happen in the same files, and on the same frames within that file? It might be that ffmpeg can't read the file beyond that point.

In the debug log enabled version, do you still see [VideoPlayer::run] Filled buffer on position %d with frame %d appearing after the freeze happens? This runs in a seperate thread filling the buffer with new frames continuously.

[jli13]

As far as I can tell, it does not seem to be decoding any new frames after it freezes. It continuously prints "last returned timestamp is of index %d" and "no new frame avaiable yet!". I've ran the program multiple times and it freezes on different frames (Anywhere from frame 325 - 410 with the video I'm testing).

The one thing that I can confirm is that the videoNumFrameBuffered variable hits 0 each time the freezes occur. In the VideoDecoder.cpp, in VideoDecoder::nextVideoFrame(), it seems like it's locking and returning without unlocking. Just to test this, I've tried unlocking before returning the current frame and it fixes the freezing issue but it introduces a whole new issue. Is there a reason why the mutex isn't release when the videoNumFrameBuffered < 1?

[RBogie]

Hmm, it indeed seems like a mistake. I'll try to debug it myself tomorrow. I probably never noticed because the decode thread always was able to stay ahead of the render thread.

[RBogie]

I still didn't find time to look into it, sorry 😞 I'll try to look into it somewhere this week.

[jli13]

No worries. Let me know if there's anything I can do to help. Thanks.

[SonicACCEL]

Hi everyone!

I've been trying to run video on some new Windows stick PC's which also have Z8300 as the processor and the video playback stutters and has a low frame rate, the same libgdx project runs fine on my ODROID Android box and also on my Windows desktop PC ( http://www.intel.com/content/www/us/en/nuc/nuc-kit-nuc5i3ryk.html )

Is there any special consideration for running GDXVideo with intel cherry trail PC?