+- 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: Mac OS X (https://forum.kodi.tv/forumdisplay.php?fid=56)
+---- Thread: I think I finally found the cause of my stutter problem. (/showthread.php?tid=44992)
Pages:
1
2
I think I finally found the cause of my stutter problem. - dan1son - 2009-02-05
I've been fighting XBMC/boxee for the last couple of months related to choppy, stuttery, or basically not smooth playback of video. I was seeing choppy playback, mostly noticable on slow panning scenes (video would sort of go smooth, stutter, smooth, stutter in a very random way). I was also seeing no frame drops on the media info screen and extra idle CPU, so it wasn't bandwidth or processing power.
I finally came to a revelation when looking through my log file for any random issues in playback when I noticed this...
Code:
ERROR: CDVDPlayerVideo::OpenStream - Invalid framerate 48000, using forced 25fps and just trust timestamps
...
NOTICE: fps: 25.000000, pwidth: 720, pheight: 480, dwidth: 720, dheight: 40425fps is weird to me since I'm running 24fps video into a 60hz set, so I thought maybe my encodes are wonky. I have only been using Handbrake (I run a mac, not much else) and pretty much always with the framerate set to "Same as source". I went back into handbrake and ran a new encode with a forced framerate of 23.976, played it in XBMC and it looks smooth.
It appears as though XBMC has some issues with frame timing on handbrake encoded videos with "same as source" fps. The ATV plays these back perfectly...
I'm running some more encodes tonight so I'll update this thread with some additional results. So far it looks promising...
- severe - 2009-02-05
Ahhh... Ok.
I thought you were gonna say it was neurogenic or a learned behavior, or maybe even genetic.
But yea.. good for you anyway.
- dan1son - 2009-02-05
I guess I should've used a different title
.So I took a look at some of my encodes from last night and have to say everything seems smooth now with the FPS forced to 23.976 in handbrake. I'm convinced XBMC has some problems playing back the VFR (Variable frame rate) files created by Handbrake. I'll have to do some further tests with other encoders to see if it's a VFR problem across the board.
The choppiness with VFR is somewhat subtle and almost looks like a random jump in frames, so I could see how some people wouldn't really notice, especially on slower refresh TVs.
Is it expected that XBMC can't see a framerate for VFR and just decides on 25fps? Or should it be seeing something else?
- severe - 2009-02-05
Kidding aside, those are interesting results you're getting.
I haven't had a problem with "Same as source" in HB. I believe I'm using a tweaked out version of Apple's Universal setting that was suggested somewhere. I had spent a decent amount of time weighing the options at one point.
I started with the Universal setting, checked "Web optimized", and added":nf=1" to the end of the "Advanced Option String" in Advanced settings.
I kept Constant quality at 59% and use Loose Anamorphic mostly.
The entire string looks like, "level=30:cabac=0:ref=3:mixed-refs=1:analyse=all:me=umh:no-fast-pskip=1:nf=1"
These settings have given me smooth, high quality results I can use in both XBMC and Boxee. Check it out, if you have a minute. I'm interested in your results.
- dan1son - 2009-02-05
I've tried that one... same choppy effects. It's sort of hard to explain. I was always convinced it was the lack of 2:3 pulldown that was causing it, but now I believe that wasn't it. There's still the sort of rhythmic chop effects caused by additional frames being added going from 24 to 30fps, but what I'm seeing with "Same as Source" HB encodes is a more random and larger stutter. In a way it looks like the frames go backwards since the movement stops. It's very fast and hard to really notice unless the whole screen is panning... then it truly bothers me.
I have been meaning to hook my ATV up to another TV in the house to see if the effect is less obvious. I'm running it on a 120hz SXRD Sony set right now that has notably fast refresh, especially compared to LCDs.
- garyi - 2009-02-05
Hi, being as I am some what stupid, why did you go for a frame rate of 23.976?
I am getting some drop out issues with conversions I am doing, and int he logs it does mention unexpected frame rates. This was done with Visualhub though.
- dan1son - 2009-02-05
23.976 is the NTSC film framerate. That's the framerate stored on most NTSC film based DVDs.
- dan1son - 2009-02-07
I have some results from further tests.
I tried encoding some MKV files in handbrake using their "Same as Source" fps settings, both with and without the detelecine filter. Those played nicely in XBMC and even picked up the correct framerate when loaded. They did not, however, play back with Perian in ATVFiles very well. It appears as though Perian requires the entire MKV file to be loaded before it'll playback properly, something to do with indexing. Not a huge downer for XBMC use, but not ideal for ATV use.
So XBMC does struggle with timing when playing back M4V files encoded with Handbrake (not sure about others) when they are "same as source" or Variable framerate ("same as source" with detelecine filter).
It seems fine with M4V files with set framerates and MKV files with "same as source", Variable framerate, or set framerates.
All of my tests were done with a specific episode of Battlestar Galactica ripped from a DVD. The intro video (Universal) makes a fine test sequence.
Should a bug be written for XBMC related to this? Or do the devs think Handbrake isn't putting a proper framerate flag on the files? These files playback fine in every other player I've tried... so I'm gearing towards XBMC having a timing issue.
- davilla - 2009-02-07
dan1son Wrote:I have some results from further tests.
I tried encoding some MKV files in handbrake using their "Same as Source" fps settings, both with and without the detelecine filter. Those played nicely in XBMC and even picked up the correct framerate when loaded. They did not, however, play back with Perian in ATVFiles very well. It appears as though Perian requires the entire MKV file to be loaded before it'll playback properly, something to do with indexing. Not a huge downer for XBMC use, but not ideal for ATV use.
So XBMC does struggle with timing when playing back M4V files encoded with Handbrake (not sure about others) when they are "same as source" or Variable framerate ("same as source" with detelecine filter).
It seems fine with M4V files with set framerates and MKV files with "same as source", Variable framerate, or set framerates.
All of my tests were done with a specific episode of Battlestar Galactica ripped from a DVD. The intro video (Universal) makes a fine test sequence.
Should a bug be written for XBMC related to this? Or do the devs think Handbrake isn't putting a proper framerate flag on the files? These files playback fine in every other player I've tried... so I'm gearing towards XBMC having a timing issue.
If you can package up a selection of these with good descriptions, I can PM you a ftp server address and I'll check them out. I only need 50-100MB per file to see the issues.
- dan1son - 2009-02-09
Sorry for the delay... crazy weekend. I'll try to get something together this evening.
- Z3rO - 2009-02-09
I have stuttering issues too with .ts files recorded from my PVR (Humax Icord HD)
Heres a pastebin of my logfile when playing back one of those files:
Console: http://pastebin.com/m7a9092e1
Logfile: http://pastebin.com/mfb1d861
I can upload you a sample if you want.
[edit]The first pastebin is from the console messages, the second one from the logfile[/edit]
- dan1son - 2009-02-11
davilla Wrote:If you can package up a selection of these with good descriptions, I can PM you a ftp server address and I'll check them out. I only need 50-100MB per file to see the issues.
For the record, about the same time I posted this original thread I also posted a similar post on an existing thread on the handbrake forums. One of the Handbrake developers responded with an interesting response.
http://forum.handbrake.fr/viewtopic.php?f=7&t=7718
- davilla - 2009-02-11
dan1son Wrote:For the record, about the same time I posted this original thread I also posted a similar post on an existing thread on the handbrake forums. One of the Handbrake developers responded with an interesting response.
http://forum.handbrake.fr/viewtopic.php?f=7&t=7718
interesting discussion.
I've got the files and will be looking into them. I'm heavily multiplexed right now so it might take a few days to get back to you.
- Z3rO - 2009-02-11
davilla Wrote:interesting discussion.
I've got the files and will be looking into them. I'm heavily multiplexed right now so it might take a few days to get back to you.
Anything exciting about my logfiles. Should I open a bug on trac?
- davilla - 2009-02-12
Z3rO Wrote:Anything exciting about my logfiles. Should I open a bug on trac?
can't tell anything from the log files except for
Quote:number of reference frames exceeds max (probably corrupt input), discarding one
Use MediaInfo to determine what your ts files really are.
upload a sample somewhere. it only need to be 50-100MBs for me to check.
Hold off on the trac less you get slammed
, stuttering issues can also be due to incorrect user settings.