I have a number of UK DVDs which suffer the PAL speed-up problem. Once your ear is tuned to this, it can make the title hard to watch. I stumbled across a guide for converting the mkv: export the video via MKVToolNixGUI with the framerate changed, import the audio to Audacity and change the duration, remux and you have a 720x576@23.976 file. Playback is perfect on the Pi (screenshot below is from an LE Pi, I think my OSMC Pi is also fine)
with the Vero, I get the following, which might best be described as confused? I have nothing set in the whitelist. Is this an issue with the 3.14 kernel that might be fixed in 4.9?
It would help to see some logs, a sample, and know how you’ve encoded the file.
The frame rate looks off across the two playback screenshots, which is certainly odd.
You could also change Accelerate MPEG2. to HD and up for MPEG2 under Settings -> Playback
If you set a whitelist and while playing the original file bring up the settings from the OSD and select “change resolution” does selecting a different frame rate fix the issue without having to mess around editing the file?
First of all, I should acknowledge this is a pretty niche use case, but curious to see where this goes. Details on file creation: UK disc, makemkv, MKVToolNIX → split out the video and audio tracks to mkv and mka files. For the video select the option for Default duration/FPS as 24000/1001. Load the video back in to the toolnix Info tool to get the precise play time, use this as the stretch-to in Audacity for the audio. Export audio to multi-track PCM and remux back to a single mkv file. I’ve checked, the OSMC Pi plays this fine.
Here is a log from the Vero.
https://paste.osmc.tv/qasecapemi
I inititiate playback twice, once with hardware decoding, then software. Software decoding also gets it wrong as the output is 60Hz, but at least the player process info is more sensible.
What’s MediaInfo say?
You can’t just change the frame rate like that – the container frame rate then won’t match the video frame rate.
If software decoding is also problematic then ffmpeg is also having troubles.
We expect the frame rate in the container to be accurate and not misinform the decoder when setting it up. You could probably stretch the timecodes instead.
2020-04-11 19:14:38.944 T:3478897376 DEBUG: CAMLCodec::OpenDecoder hints.width(720), hints.height(576), hints.codec(2), hints.codec_tag(0)
2020-04-11 19:14:38.944 T:3478897376 DEBUG: CAMLCodec::OpenDecoder hints.fpsrate(25000), hints.fpsscale(1000), video_rate(3840), hints.bitsperpixel(8)
2020-04-11 19:14:38.944 T:3478897376 DEBUG: CAMLCodec::OpenDecoder hints.aspect(1.777778), video_ratio.num(1), video_ratio.den(1)
2020-04-11 19:14:38.944 T:3478897376 DEBUG: CAMLCodec::OpenDecoder hints.orientation(0), hints.forced_aspect(1), hints.extrasize(164)
yes, this method works, the output is now 24p and all looks good. The player process info still shows the wrong framerate.
Here is the Mediainfo. Clearly the Pi and the Vero are handling this differently, as both my OSMC and LE Pi’s play this without issue.
Format : Matroska
Format version : Version 4
File size : 6.69 GiB
Duration : 1 h 25 min
Overall bit rate mode : Variable
Overall bit rate : 11.2 Mb/s
Encoded date : UTC 2020-04-11 15:41:25
Writing application : mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
Writing library : libebml v1.3.10 + libmatroska v1.5.2
Video
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings : CustomMatrix / BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : Variable
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 1 h 25 min
Bit rate mode : Variable
Bit rate : 6 542 kb/s
Maximum bit rate : 9 800 kb/s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Original frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.658
Time code of first frame : 00:59:59:00
Time code source : Group of pictures header
GOP, Open/Closed : Open
GOP, Open/Closed of first frame : Closed
Stream size : 3.92 GiB (59%)
Language : English
Default : No
Forced : No
Color primaries : BT.601 PAL
Transfer characteristics : BT.470 System B/G
Matrix coefficients : BT.470 System B/G
Audio
ID : 2
Format : PCM
Format settings : Little / Signed
Codec ID : A_PCM/INT/LIT
Duration : 1 h 25 min
Bit rate mode : Constant
Bit rate : 4 608 kb/s
Channel(s) : 6 channels
Sampling rate : 48.0 kHz
Frame rate : 32.000 FPS (1500 SPF)
Bit depth : 16 bits
Stream size : 2.76 GiB (41%)
Default : Yes
Forced : No
Menu
00:00:00.000 : en:Chapter 01
00:14:43.920 : en:Chapter 02
00:19:38.200 : en:Chapter 03
00:28:18.720 : en:Chapter 04
00:42:05.560 : en:Chapter 05
00:43:32.400 : en:Chapter 06
00:46:05.040 : en:Chapter 07
00:51:20.680 : en:Chapter 08
00:59:45.920 : en:Chapter 09
01:08:43.680 : en:Chapter 10
The Vero and Pi are completely different hardware, with different hardware video decoder implementations.
It looks like the Pi chooses to favour the frame rate reported in the container.
We prefer to favour the actual frame rate of the video stream being played.
We can look in to this but it’s low priority, particularly we seem to be doing the right thing. There are ramifications of blindly trusting the container frame rate – low resolution content like AVI is a good example of this.
(if you get rid of this flag), I would expect the video will play perfectly on all platforms.
I had a look at the mkvtoolnix header editor, and could not see an entry for original framerate. Do you happen to know how this field can be removed? I’ve really only looked into this out of curiosity, not much of my film library is in SD 50Hz now. It sounds like an explanation for the difference in behaviour across platforms might have been identified.
It would be good to get a sample of this file.
MKVtoolnix has an option (not the default) to fix all the timestamps on a video stream to match either the framerate derived from looking at the source file, or a fixed value input by the user. This has fixed some playback issues for me.
MKVtoolnix is getting the info from the raw stream. Remux and set the new frame rate with “Fix bitstream timing info” checked.
thanks - but I still get MediaInfo with original frame rate = 25fps and the Vero still does not play correctly. Perhaps I’m doing something wrong in mkvtoolnix.
Might this only be relevant for certain video codecs? I just tried this on a bluray-sourced 50i film, and the Fix bitstream timing info option did remove the Original Framerate field from the media info (most of the titles I’m interested in converting this way are MPEG2, perhaps this codec does not support the option?)
Unfortunately, the Vero still cannot play this properly, per the attached screenshot. I wonder if it’s confused by 23.976 arriving in interlaced format (Pi/MMAL is fine, and I can force weave deinterlace at 23.976).
Mediainfo:
Format : Matroska
Format version : Version 4
File size : 21.2 GiB
Duration : 1 h 50 min
Overall bit rate mode : Variable
Overall bit rate : 27.4 Mb/s
Movie name : Educating Rita
Encoded date : UTC 2020-04-12 08:47:12
Writing application : mkvmerge v45.0.0 ('Heaven in Pennies') 64-bit
Writing library : libebml v1.3.10 + libmatroska v1.5.2
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Format settings, GOP : M=3, N=24
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 50 min
Bit rate mode : Variable
Bit rate : 27.0 Mb/s
Maximum bit rate : 35.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : MBAFF
Scan type, store method : Interleaved fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.542
Stream size : 20.9 GiB (98%)
Language : English
Default : No
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 1 h 50 min
Bit rate mode : Variable
Bit rate : 435 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 11.719 FPS (4096 SPF)
Bit depth : 16 bits
Compression mode : Lossless
Stream size : 345 MiB (2%)
Writing library : libFLAC 1.3.1 (UTC 2014-11-25)
Default : Yes
Forced : No
Menu
00:00:00.000 : en:Chapter 01
00:04:23.480 : en:Chapter 02
00:14:35.080 : en:Chapter 03
00:22:03.960 : en:Chapter 04
00:31:21.720 : en:Chapter 05
00:45:54.280 : en:Chapter 06
00:53:38.960 : en:Chapter 07
01:01:00.600 : en:Chapter 08
01:09:49.120 : en:Chapter 09
01:21:40.400 : en:Chapter 10
01:32:56.840 : en:Chapter 11
01:43:24.240 : en:Chapter 12
I downloaded the latest 4.9 to my test Vero and behaviour is slightly different. It’s switching my TV to 24Hz, which is promising, but the playback itself is very stuttery and player process info reports a framerate of 47.962. Hardwared and software playback for SD content behaved the same in this regard.
Either the last time I tested one of my “48i” files under 4.9 I did something wrong, or otherwise something has changed since I last updated my 4.9 Vero. Software playback of the MPEG2 SD files converted from 50i is now working, TV switches to 24Hz, playback is smooth. Have not had chance to compare scaling vs the Pi, first impressions are good.
Hardware playback is still very choppy, but 48i is hardly a standard, surprised the Pi copes with it.
