DVD (ISO) MPEG2 Playback Choppy

Playing DVD ISO’s with the Vero has choppy video. The same files on RaspBMC/RP1 works flawlessly. MP4 files play flawlessly on the Vero.

Is there a setting I need to adjust?

Are you getting alot of skips (check the info screen)? I have the same or a similar issue as you can see at MPEG2 decoding drop/skip Vero

Yes, after only 89 seconds of playback the skip count is already 919 and the drop count is 60.

Having checked a few example files, I am seeing consistently bad behaviour with mpeg2 encoding but not with mp4 encoding.

Your original thread doesn’t appear to have any resolution so I assume that this is still an open issue.

Codec screen is not a benchmark. IMX renders in a special way. It has a fb that directly display the video and the gui, which is rendered differently. Whenever the OSD / codecscreen comes up, the data from the video and the menu need to be “combined”, that costs too much bandwidth.

I added some code to xbmc, that sam already picked, during the we. That way the gui is slowed down and you not see “false skips”, e.g. skips introduced by the overlays.

Though, to make that clear: As of current development, vero is fully maxed out when having to display 50 fps … I don’t have a vero, those are i4 stats.

1 Like

I understood that it is on Sam’s todo list (at least 5 days ago). For now i’m keeping my ATV1 next to the Vero specifically for this issue because the ATV1 has no problems with MPEG2. Cannot imagine that the Vero cannot handle this though.

Vero has no crystalhd (which is good), but it has other limitations, that appear on bus transfer, which need far different workarounds and kodi optimizations than ATV ever needed. It’s different and misses a whole lot of workarounds. Think of it as the RPi1 after approx 1 year: many things work, but far more don’t … it’s wip.

Ah and something else I have missed.

DVD isos are (in comparison to bluray isos) only SW accelerated (CPU only), cause of the still frames, which kill certain hw decoders - the Pi has workarounds for this and does it on HW, but the rest of the world, be it VDPAU, VAAPI cannot. So here it was the 700 Mhz P3 of the ATV vs. the arm chip, which seemed to have worked in favor of ATV.

Thanks for the context fritsch, do you expect that this could be fixed with Vero? Not being able to view ripped VOB’s is a real dealbreaker for me as alot of the movies for my kids are in this format. Kids not happy means parents not happy :wink:

Try something: Video -> Acceleration -> Decoding Method: Software.

And then play only those files. This will enable multithreaded sw decoding. Cause of shortcomings in our DVDVideoCodecFFMPeg, we cannot fallback to multithreaded sw decoding when the hw decoder fails to open.

If this makes those isos playing smoothly, then it will work with upcoming v15, cause we have fixed this threading handling and auto fallback correctly.

Edit: Obviously you need to switch back the method to Hardware, cause cubox is too slow to decode h264 on the cpu alone.

I’ll try that tonight, thanks.

Ah that is something to look forward to. :smile:

I first noticed this quirk on my 2007 Mac Mini (which does not support hardware decoding in Gotham/Helix at all) - if it was set to hardware decoding it would always drop back to software, but despite multi-threaded decoding being shown as enabled (but greyed out) in the UI it was not using multi-threaded decoding.

I didn’t realise this for nearly a year, then discovered if I disabled hardware acceleration (which it couldn’t use anyway) it suddenly started doing multi-threaded decoding - boosting maximum playback bitrate from 25Mbps to 50Mbps. :smile:

Meh, no improvement when acceleration is set to software.

Sad. To be fully sure, test them from local (usb) disk and post a debuglog, please. My crystalball is afk :slight_smile: Normal mpeg-2 should be no issue for imx hw. CPU load is maxed? Both cores?

one is 100% and the other around 50%, i’ll try to post a debuglog later tonight

Check http://paste.osmc.io/bijiwudeye.coffee , i did cut some scraper results from the log. CPU load is about 60% (30, 30 each).

I’m really lost now, the example VOB i used is now using:

dc:iMX-mpeg2

and is no longer stuttering. When switching back to software it is using:

dc:ff-mpeg2video

and is stuttering. Now if i change back to hardware acceleration it keeps using ff-mpeg2video instead of dc:iMX-mpeg2.

That’s perfectly fine. the Vob itself is done with imx hw. You talked about “isos” … but if you play vobs, that something else :slight_smile:

Edit: What? :slight_smile: that’s now really curious. Try to capture both in one debuglog, please.

I’m not able to upload a debug log at the moment but here is what i observe trying to reproduce the issue. Playing a single VOB uses:

dc:iMX-mpeg2

If i try to play the Video_TS folder (containing that specific VOB) as a ‘movie’ in Kodi it uses

dc:ff-mpeg2video

and it stutters. The weird thing is that i’m pretty sure playing a single VOB also was a problem, at least a couple of days ago.

Good now that gets clear. VOB, kodi parses and finds mpeg-2, uses hw accel, complete video_ts folder it realizes dvd iso -> sw decoding.

That is what i could reproduce yes.