[mduran]

I've also have a thread on raspbmc.com but no solution yet.

The problem is: If I play a MKV file with DTS audio, the picture stutters, you see hickups and freezes or drops almost every second in the picture. I already tried several actions but none of them solved this issue. It started with the July release of RaspBMC. BackPort2 nightly also does not have this issue.

* Sync screen to video is on.
* Tried several cachemembuffer settings.
* Playing with AC3 does not have stutter,
* Downmixing DTS track does not have stutter.
* I am using NFS share, with 9.5MB download
* Reinstalled RaspBMC without even adjusting one setting also has the same issue.

The most interesting thing that I see is DVDPlayer does not have this issue. Not with AC3, Not with DTS.

So it must be something in OMXPlayer. Already have latest fixup and startup files. Tried every RaspBMC nightly builds from here and Sam but none of them helped. Only OMX Backport 2 helps.

Here is a test file, you can see the stars over the lake stutter.

download sample (67 MB)

Please try this file and tell me if it stutters?

P.s. There is no audio stutter, just picture that has hickups. And the stutter issue does not occur with all dts mkv files, just a few, let's say half of them.

[popcornmix]

I've watched this file very closely and it played perfectly for me. DTS passthrough enabled, using omxplayer with Milhouse's last build.
Do you have "adjust display framerate to match video" enabled? (You should if you want stutter free playback).

[mduran]

Yes I do have it enabled. I know it works because tvservice -a and -s gives me hdmi mode with 24hz. And it also would not explain why dvdplayer plays it without stutter. And you don't need to look very closely it the stutter is real obvious to see.

[popcornmix]

Can anyone else test this file?

[mduran]

What is drops when playing with DVDplayer? The drops counts real fast, like a formula 1 car. ;-)

Please can someone test the file. Perhaps someone with a Yamaha RX-Vxxx receiver...

[melfy]

Don't know if a test with openelec is valid or not but it plays flawlessly on openelec Milhouse build from 2 days ago via a yamaha rx-v475. No stutter at all using OMX or DVD
Ps My amp didn't detect this as DTS, rather just Dolby digital. When I play other DTS movies the amp says DTS.

[mduran]

You need to change audio track to DTS. The sample has 2 streams. One Dolby Digital. One DTS track. Did you enable DTS Capable receiver?

[mduran]

I installed OpenELEC latest Millhouse build, and have the same issue. So I can reproduce it,

@popcornmix what can I do to find out what's causing it. Is there a extra debug or something that will give me more information. Same movie with AC3 plays flawless, same movie with DTS downmix plays flawless. I already tried a different HDMI cable, and used a different HDMI input port on TV as wel as receiver. Copied the file to USB3 stick and same issue. I have this on a lot of mkv's.

Driving me crazy....

[popcornmix]

Ah - it wasn't clear you had to switch audio tracks. I can see it now.

Interestingly when starting with AC3 playing, and then switching to DTS, no stutter occurred.
After switching on the next play it will start with DTS and stutter. For me, doing an immediate seek back stops the stuttering. Does that work for you?

Now I can reproduce the issue, it should be solvable.

[mduran]

Yes. Like I explained on raspbmc forum. Seeking back and restarting movie results in stutterfree playback for a while. I thought it was buffering issue.

[janaha]

Toggling "enable passthrough" from audio menu while playing a movie works for me.
OMX,DTS, 1080p.

DVDPlayer works great though

[mduran]

Oh, finally, I was about to order a new RaspBerry PI thinking mine was broken.

[popcornmix]

Can you try enabling "sync playback to display"?

Analysis:

Your file is DTS @ 48kHz. Each frame is 512 samples, or 10.666ms.

Here are the timestamps (pts, dts and frame number):
http://pastebin.com/EuVDKxX3

You see they typically increase by 10 or 11 ms as you would expect. However after about 2 seonds:

Code:

2003 2003 188
2013 2013 189
2023 2023 190
2033 2033 191
2006 2006 192
2016 2016 193
2026 2026 194
2036 2036 195

What's happened here? The timestamps have jumped backwards by about 40ms.

At about 3 seconds:

Code:

3030 3030 288
3040 3040 289
3050 3050 290
3060 3060 291
3114 3114 292
3124 3124 293
3134 3134 294

This time a jump forward of about 40ms more than we'd expect.

Basically there is a glitch in the timestamps roughly once a second. The file is broken.

But, given the file is broken, what should we do with it?

The default bevaviour of omxplayer is to treat the audio clock as master and video as a slave.
The audio clock is simply the number of audio samples played / sample rate.
If the timestamp of the next packet to play is more that 50ms away from out audio clock we consider that a discontinuity, and reset the audio clock to the timestamp of the next packet.
This means the next audio frame will play seamlessly, but the video will stutter (~2 video frames will be dropped or duplicated).

"sync playback to display" means that we treat video as the master clock. This should mean that video plays without stutter, but we will sometimes have additional or missing (typically 4) audio packets.
This will result in an audio glitch. You may find this preferable (some receivers are quite good at hiding audio errors).

As it turns out in your sample, the audio timestamps errors seem to alternate forwards and back, so there is a third possible solution of increasing the allowed error in timestamp.
For your sample, 70ms still glitches occasionally, but 80ms never does (although possibly the whole film may include some bigger errors).

We don't necessarily want to increase the 50ms theshold.
E.g. if someone had introduced a constant audio/video offset error when editing out the adverts in a file, currently it will be corrected if more than 50ms (by introducing a video frame drop/dupe).
Increasing the allowed audio error does allow a worse lipsync error to persist.

So, the best solution is to fix the files. If you encode them yourself then consider changing the tools you are using - one of them is buggy.
If someone else produces them consider looking elsewhere.

Try "sync playback to display". You may prefer it.

With next firmware update I'll add a config.txt option to override the 50ms threshold. You may find setting it to 80 or 100 solves your problem.

But note there is no perfect solution to dealing with incorrect timestamps in files. It's always a compromise between video glitches, audio glitches or lipsync errors.
I imagine dvdplayer has a higher error threshold if it is avoiding the glitches.

[mduran]

Funny thing is, omxbackport 2 plays it flawless. Why is that?

[popcornmix]

Funny thing is, omxbackport 2 plays it flawless. Why is that?

That was a long time ago and a lot of code was different.
Specifically we used to do some bad timestamp workarounds on the arm, and then some bad timestamp workarounds on the gpu.
This was not ideal and could result in lipsync issues.