[two_OH_five]

I'm having an issue with a few videos in the collection

This one is the most serious as it's one of my favorite films and it will not play correctly if I enable refresh rate changes

Full Media Info http://pastebin.com/eK6WMTgG
Video excerpt

Code:

General
ID                                       : 1 (0x1)
Complete name                            : The Big Bus (1976) 1080i HDTV DD2.0 MPEG2-TrollHD.ts
Format                                   : MPEG-TS
File size                                : 9.93 GiB
Duration                                 : 1h 28mn
Overall bit rate mode                    : Variable
Overall bit rate                         : 16.1 Mbps

Video
ID                                       : 532 (0x214)
Menu ID                                  : 1 (0x1)
Format                                   : MPEG Video
Format version                           : Version 2
Format profile                           : Main@High
Format settings, BVOP                    : Yes
Format settings, Matrix                  : Custom
Codec ID                                 : 2
Duration                                 : 1h 28mn
Bit rate mode                            : Variable
Bit rate                                 : 14.9 Mbps
Maximum bit rate                         : 18.0 Mbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 29.970 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Compression mode                         : Lossy
Bits/(Pixel*Frame)                       : 0.239
Stream size                              : 9.19 GiB (93%)

Full Debug log
http://pastebin.com/Cti4Kv1K

There are 3 attempts to play the movie.
The first is from time 0 in the movie (Timestamp 21:44:31). The movie starts at the correct frame rate but as my UK TV doesn't support 29.xFPS the refresh is 60
After about 30 seconds refresh switches to 23.98 and playback goes to hell as you'd expect. This happens consistently

Then I stop and play again (Timestamp 21:46:07). This time from a resume point at 18:3something. Playback starts at 60FPS then switches again to 23.97 with heelarious stop motion effects. This runs for a minute or so when I stop it. I then resume playback (Timestamp 21:47:35) from the last stopped position, 19:30 odd and despite the pullup correction warnings it doesn't switch refresh rate before I stop (although it might if allowed to continue)

One thing I notice is that before the refresh rate change the rendered FPS in codec info display is all place from 40something to 60 odd
After the refresh switch the rendered frame rate is solid at 23.96

Hardware
i3 2105 CPU @stock 3.1GHz
ATI 6570 GPU

Software
The log is from openelec build OpenELEC-Generic.i386-devel-20120125153526-r9647
This indicates XBMC 11.0-BETA2 Git: f76c547
OpenGL version 4.2.11318

settings
Direct XVBA acceleration with shared surfaces enabled in the logfile.
The same behaviour is apparent with vaapi enabled or with all acceleration disabled

Logfile was with Advanced shader as render method but behaviour is the same using software rendering too

Sync playback to display is on with Video clock (drop/dupe audio) sync method


I have also observed the same CPullupCorrection eerrors happening on Windows Eden Beta 1 (and all versions prior to that)


I do also have a few other video files that exhibit the same CPullup errors but none of them seem to make the same bad rate switch, they just keep exhibiting some stutter while PC drops back to None then carry on again when it's re-established

[bobo1on1]

The framerate calculation was added to make adjust refreshrate work for files with an incorrectly set framerate, it seems to be failing here, I'll look into it.

[bobo1on1]

This should fix it https://github.com/xbmc/xbmc/commit/142e...613674f991

[Shine]

I don't know whether this is related, but I've seen CPullupCorrection failing consistently with OGM files. All the files I tried are CFR 23.976fps, so (if I understood this correctly), the pattern should always be "1". Very few are detected this way and play fine. Most OGM files, however, lead to a debug output like the following:

Code:

20:17:36 T:1408   DEBUG: CPullupCorrection: detected pattern of length 2: 125124.90 -41708.30, frameduration: 41708.333333
20:17:42 T:1408   DEBUG: CPullupCorrection: pattern lost on diff 83416.600000
20:17:59 T:1408   DEBUG: CPullupCorrection: detected pattern of length 58: 125124.90 -41708.30 125124.90 -41708.30 83416.60 41708.30 83416.60 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30 125124.90 -41708.30, frameduration: 41708.333333
20:18:01 T:1408   DEBUG: CPullupCorrection: pattern lost on diff 125124.900000
20:18:24 T:1408   DEBUG: CDVDPlayerVideo::CalcFrameRate counted 1000 frames without being able to calculate the framerate, giving up
20:18:51 T:1408   DEBUG: CPullupCorrection: detected pattern of length 2: 125124.90 -41708.30, frameduration: 41708.333333
20:18:57 T:1408   DEBUG: CPullupCorrection: pattern lost on diff 83416.600000
20:19:02 T:1408   DEBUG: CPullupCorrection: detected pattern of length 2: 125124.90 -41708.30, frameduration: 41708.333333
20:19:09 T:1408   DEBUG: CPullupCorrection: pattern lost on diff 83416.600000

or

Code:

20:23:28 T:720   DEBUG: CPullupCorrection: detected pattern of length 3: 166833.20 -83416.60 41708.30, frameduration: 41708.333333
20:23:28 T:720   DEBUG: CPullupCorrection: pattern lost on diff -41708.300000
20:23:41 T:720   DEBUG: CPullupCorrection: detected pattern of length 3: 166833.20 -83416.60 41708.30, frameduration: 41708.333333
20:23:48 T:720   DEBUG: CPullupCorrection: pattern lost on diff 125124.900000
20:23:56 T:720   DEBUG: CDVDPlayerVideo::CalcFrameRate counted 1000 frames without being able to calculate the framerate, giving up
20:24:25 T:720   DEBUG: CPullupCorrection: detected pattern of length 36: 166833.20 -83416.60 41708.30 166833.20 -83416.60 41708.30 166833.20 -83416.60 41708.30 166833.20 -83416.60 41708.30 83416.60 83416.60 -41708.30 166833.20 -83416.60 41708.30 166833.20 -83416.60 41708.30 166833.20 -83416.60 41708.30 166833.20 -83416.60 41708.30 166833.20 -83416.60 41708.30 166833.20 -83416.60 41708.30 166833.20 -83416.60 41708.30, frameduration: 41708.333333
20:24:27 T:720   DEBUG: CPullupCorrection: pattern lost on diff 125124.900000

Of course, there's judder like hell, which reduces siginificantly during the short periods when the pattern changes to "2" (or "3"). Remuxing to MKV completely fixes this, the pattern is properly detected as "1" in all cases and the judder is gone. So XBMC seems to do something wrong with OGM files, specifically...

Tested with various pre-Eden and post-Eden builds. The above debug log excerpts are from (12.0-ALPHA1 Git:20120416-2065cb5).

P.S.
I've also seen (CFR) MKV files occasionally losing the pattern, but that never leads to any siginificant judder. Perhaps CPullupCorrection is a bit too oversensitive altogether, in addition to the obvious OGM problem?


Edit: Checked some affected OGM files with MediaInfo. XviD encoded files seem to be only affected when muxed as packed bitstream. Divx5 seems affected in either case. Any other codec doesn't seem affected at all (but I don't really have enough files to test for a closer look). "Packed bitstream" seems to have something to do with it, though. I assume CPullupCorrection doesn't take into account the necessary reordering of the frame timestamps in packed bitstream streams?

[elupus]

Do we have a sample for these junky files somewhere? Should be fixed in demuxer.