xbmc
xbmc copied to clipboard
FernetMenta
Refresh-rate switching and "frame rate differs from container frame rate"
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 [email protected] 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 [email protected] 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?
There are 2 types of NTSC DVDs.
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.
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.
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.
btw: what strange version of XBMC are you running? I have removed the call to nvidia-settings for quite a while because its unreliable.
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.
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.
RE: nvidia-settings, is it just f9ff975ce7aee035c9957ce5f5668618af4c7d6b and a1685ad825cf106913d232b7e5f7adb064231825 that I need to cherrypick, or are there more commits I should be picking up?
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.
1387 may not cover your use case. Consider that the video plays well for approximately 10 min before the first special effect.
@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?
@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"
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.