Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Refresh-rate switching and "frame rate differs from container frame rate" #108

Open
macmenot opened this Issue · 12 comments

2 participants

macmenot Rainer Hochecker
macmenot

seems like a similar issue to #52 but no mention of variable frame rate in my files

I have some old x264 encodes of my NTSC Babylon 5 DVDs. Initially in XBMC they correctly start playing at 1080p@59.94 and seem smooth

NOTICE:  fps: 29.970030, pwidth: 708, pheight: 480, dwidth: 858, dheight: 480
NOTICE: Display resolution ADJUST : HDMI-0: 1920x1080 @ 59.94Hz (18) (weight: 0.000)

However, after a few seconds of playback it inexplicably switches to 1080p@23.97 and doesn't play smoothly.

NOTICE:  fps: 23.976024, pwidth: 708, pheight: 480, dwidth: 858, dheight: 480
NOTICE: Display resolution ADJUST : HDMI-0: 1920x1080 @ 23.98Hz (23) (weight: 0.000)

However, looking at the file in mkvinfo, ffmpeg, and mediainfo we can see that the container and the video file itself differ in what they believe the correct fps is:

$ mkvinfo *s03e16*.mkv | grep -i frame
|  + Default duration: 33.367ms (29.970 frames/fields per second for a video track)
$ ffmpeg -i *s03e16*
Seems stream 0 codec frame rate differs from container frame rate: 49.22 (25203/512) -> 23.98 (24000/1001)
Input #0, matroska,webm, from 'Babylon 5 - s03e16 - War Without End (1).mkv':
  Duration: 00:43:44.62, start: 0.000000, bitrate: 448 kb/s
    Stream #0.0(eng): Video: h264 (High), yuv420p, 708x480, PAR 40:33 DAR 59:33, 29.97 fps, 23.98 tbr, 1k tbn, 49.22 tbc (default)
    Stream #0.1: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s (default)
$ mediainfo *s03e16* | grep -i 'frame rate'
Original frame rate                      : 24.612 fps

Is this just a badly encoded file? Is XBMC doing the right thing?

Rainer Hochecker
Owner

There are 2 types of NTSC DVDs.

1)
Content is stored as progressive 23.97 and requires the DVD player to on-the-fly telecine for playback on old NTSC TV equipment. Those DVDs should play at 23.76 in XBMC.

2)
Content is telecined and written to DVD. Those play at 59.98 using de-interlacing.

Seems your file got messed up during encoding and is a mixture of both. But this is guessing. Can you post a debug log.

macmenot

So I googled a little, and it would appear that the Babylon 5 source material is indeed variable frame rate:

Hybrid sources typically require VFR (variable frame rate) so that film sequences are inverse telecined and shown at 23.976 frames/sec, and non-film sequences (usually special effects) are shown at 29.970 frames/sec.

Rainer Hochecker
Owner

btw: what strange version of XBMC are you running? I have removed the call to nvidia-settings for quite a while because its unreliable.

macmenot

I'm running frodo 12.0 final from debian (2:12.0~git20130127.fb595f2-1) with pull xbmc/xbmc#870 on top, and no other changes.

macmenot

now that I realize the source is VFR, perhaps I am just re-reporting the issue originally raised under xbmc/xbmc#1387 ? i.e., that xbmc switches to the lower frame rate and then stays there, which makes the special effects scenes look jerky, but does keeps the film sequences smooth.

macmenot

RE: nvidia-settings, is it just f9ff975 and a1685ad that I need to cherrypick, or are there more commits I should be picking up?

Rainer Hochecker
Owner

yes, it seems like the issue we discussed on 1387.

Not sure if it's enough just to apply those 2 commits (I have never tried). Maybe those are dependent on dropsdl in which case you'd better use my entire master branch.

Rainer Hochecker
Owner

1387 may not cover your use case. Consider that the video plays well for approximately 10 min before the first special effect.

macmenot

@FernetMenta so currently XBMC is switching to 23.976 and staying there as the majority of the episode plays smoothly. However, the special effects sections seem to play OK and then jump forwards and play OK and jump forwards etc. Is this because it is incorrectly attempting to do inverse telecine, or some other reason?

macmenot

@FernetMenta the avisynth docs here discuss this decimation. So it would seem that we would want to "to reduce their [the non-film sections] frame rate by blend decimating each cycle of frames from 5 frames to 4 frames"

Rainer Hochecker
Owner

not sure how this would help. We have to do this in realtime with the infrastructure in place. Currently best we can do is just to drop one frame in 5 or run at 59.98 with 3:2 cadence for film sequences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.