+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: OS independent / Other (https://forum.kodi.tv/forumdisplay.php?fid=228)
+---- Thread: [Dharma Beta2] Stutter on a blu-ray rip (/showthread.php?tid=81442)
[Dharma Beta2] Stutter on a blu-ray rip - pennant - 2010-09-18
I'm having a problem with some of my blu-ray rips. Most of them manage to play flawlessly, but some stutter at certain points. The only thing that is changed from the original .mt2s is that the video and audio are muxed into a MKV container with FLAC multichannel audio. I use Another EAC3to GUI Plus (http://forum.doom9.org/showthread.php?p=1393863).
I have refresh rate change and sync a/v (resample audio) enabled. Vsync is always enabled.
The problem is at it's worst with my rip of Batman Begins (VC-1 video). It changes to 23.976 just fine, but the intro stutters at certain points and continues to do so into the movie. When I press "o", I notice the stutters occur when the PC:24 changes to PC:none, the FPS drops, and the error% goes crazy. It recovers, but eventually happens again. No frame drops are recorded. The stutters always occur at the same parts of the movie.
The behavior happens in both a clean install of Windows 7 and the Linux Beta2 livecd. MPC-HC and VLC play the file perfectly. I'm running an ION system (ASUS AT3IONT-I motherboard) with 4GB of RAM.
I've noticed a lot of the ffmpeg code is a few months old (in particular VC-1 which is 8 months out). http://trac.xbmc.org/browser/branches/Dharma/xbmc/cores/dvdplayer/Codecs/ffmpeg/libavcodec Could a newer version of ffmpeg solve the problem?
Debug log: http://pastebin.com/Fg1tK94A
First 50 seconds of the film: http://www.multiupload.com/SFLXGT6P8P
Update 10/16/10:
Mnementh has conducted some tests and it seems like the problem is with the multichannel FLAC audio. Regardless of what encoder is used, Blu-ray rips with FLAC audio exhibit stuttering and framerate problems. If the FLAC is converted to PCM, the file plays fine.
Update 10/25/10:
I've created a bug report ticket: http://trac.xbmc.org/ticket/10581
- pennant - 2010-09-19
Bump. Is there any other info that would help?
- bobo1on1 - 2010-09-19
There seems to be an issue with the audio timestamps on that sample.
- pennant - 2010-09-19
Any recommendations on how to remedy that? I ran the file through mkvmerge again with no luck.
- boykster - 2010-09-19
any reason for using FLAC vs the AC3 or DTS audio? I only ask because I have a similar setup (ION box) and my mkv repackaged BD rip of that movie plays flawlessly with the native digital audio track.
- pennant - 2010-09-19
I want the TrueHD and DTS-HD audio. AC3 and DTS are lossy. I only use AC3/DTS if HD audio is not available.
FLAC preserves the lossless format and is more universally supported than TrueHD and DTS-HD.
- boykster - 2010-09-20
Ah, got it....
- pennant - 2010-09-20
Any advice on how to fix the audio timestamps (without compression)? Again, this file plays fine in MPC-HC and VLC.
- bobo1on1 - 2010-09-20
Hm dunno about that, I think I saw some jerks with VLC, but they seem to handle it a little better.
- live4ever - 2010-09-21
I have no problems playing Batman Begins (VC-1 + TrueHD) on an Atom 330 ION board I send out LPCM audio.
Why not keep the audio intact in its native format? XBMC can't bitstream but it can decode it.
- pennant - 2010-09-21
I may have to do that. It's just that I have around 150 rips. Some of them play fine, so either I go through and do them all again or I'll randomly come across a movie that stutters. I could also use the DSplayer build, but that is a bit unstable in other areas.
bobo1on1, I noticed that the latest changeset in trunk addresses stutter and discontinuity errors: http://trac.xbmc.org/changeset/34015
Are you able to test the sample on 34015? If not I'll compile myself. It just takes a couple hours on my ION system.
And I just tried the sample again on my Macbook with VLC 1.1.3 and it plays smoothly. Default settings.
- pennant - 2010-09-21
pennant Wrote:bobo1on1, I noticed that the latest changeset in trunk addresses stutter and discontinuity errors: http://trac.xbmc.org/changeset/34015
Are you able to test the sample on 34015? If not I'll compile myself. It just takes a couple hours on my ION system.
Just tried trunk svn 34016. Same issue.
- pennant - 2010-10-14
Same problem under Dharma Beta3
- Mnementh - 2010-10-15
I can confirm the problem is definitely with FLAC audio.
My hardware is the same as the OP only with 2GB of RAM not 4
I installed a fresh copy of Dharma beta 3 yesterday (had the same issue with beta 2 but thought I'd use the latest release while testing). I then proceeded to test with a rip of my Phantom of the Opera Blu-ray with every combination of audio and video etc I could think of, I used this because the problem occurs as soon as the audio kicks in during the opening credits so it made testing quick and easy without waiting for long periods of time or introducing possible errors while seeking to a problem area.
I used Another EAC3to GUI Plus as per the OP to rip the disc to .mkv with FLAC audio created from the TRU-HD original (the issue also occurs with FLAC created from DTS-HD).
I did this with both mkvmerge 4.0.0 and 4.3.0 to eliminate whether the problem is caused by header compression or not, the results were the same with both versions.
I then tried creating the .mkv without converting the TRU-HD stream to FLAC using Another EAC3to GUI Plus, again with both versions of mkvmerge, the resulting files played perfectly no slowdown of video with the then rather annoying attempt to "catch up" (can't think of another way to explain sorry).
I then set about determining whether the problem was with the FLAC audio itself or the way EAC3to was creating it or whether Another EAC3to GUI Plus was doing something funky. I manually demuxed the .m2ts files with EAC3to and TSMuxer without converting the audio to FLAC, ran the resulting files through mkvmerge and both files played with no problems. I then converted both audio files manually to FLAC using the FLAC Frontend bundled with FLAC-1.2.1b (Another EAC3to GUI Plus uses MADFLAC and I wanted to eliminate this as a cause), and again muxed with both versions of mkvmerge. All four files (EAC3to - FLAC - With compression, Without compression & TSMuxer - FLAC - With compression, Without compression) exhibited the stuttering problem.
So we can definitely say at this moment in time that the problem is with FLAC audio in an mkv container.
I then wanted to see whether it was a problem with the way the audio was encoded (is the process introducing errors somewhere) or if it was in the way xbmc (or ffmpeg more than likely) is playing it back.
I took the original FLAC audio stream created by Another EAC3to GUI Plus and converted it to PCM using EAC3to and DBPoweramp, muxed to mkv etc etc and tested again. All four files played with no stuttering. The only issue I have with this particular test is, if there were errors when converting to FLAC originally they could be removed when converting back as it is a lossless codec, I tried to alleviate this by using DBPoweramp as well but I don't know enough about how it works to say 100% that this is the case.
I can't think of any other tests to try and I've done so many different permutations now that any debug logs would be torturous to read through, though if they are wanted I can run the tests again over the weekend and post them all but they look the same as the one in the OP.
If anybody can think of anything else to test I'm more than willing.
- CrystalP - 2010-10-16
Does the same file work fine on a system stronger than Atom+Ion?