I’m watching an episode of the original series of Planet Earth. It’s in a slightly unusual format - it’s a direct rip from the blu ray, but it plays at 50Hz rather than 24 (I would guess it’s 1080i/50 native), it’s encoded as VC-1 rather than h.264, and it’s an m2ts file rather than an mkv.
If I allow the episode to play from the beginning without skipping forward, it plays okay; but as soon as I skip forward 5 minutes, the picture disappears, and instead I get a static pattern of coloured bands.
To be clear: if I watch the first ten minutes without skipping, it’s fine; but if I watch a few seconds and then skip forward five minutes, I lose the picture. (I guess it’s the buffering that triggers the problem?)
Sometimes, for variety, the picture just freezes and never unfreezes instead of turning into coloured bands.
Logs: https://paste.osmc.tv/xijafesubu
This is probably caused by writing the header in again to set up the decoder when you skip forward.
Do you have a small sample to reproduce this?
I have Planet Earth on HD-DVD – but I’m not sure where. I believe the Blu-ray release is the same as the HD-DVD version.
Remuxing to mkv is very easy should it be a container issue.
Here’s a MediaInfo dump, by the way:
General
ID : 0 (0x0)
Complete name : [REDACTED]
Format : BDAV
Format/Info : Blu-ray Video
File size : 12.5 GiB
Duration : 47 min 52 s
Overall bit rate mode : Variable
Overall bit rate : 37.4 Mb/s
Maximum Overall bit rate : 48.0 Mb/s
Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : Advanced@L3
Codec ID : 234
Duration : 47 min 52 s
Bit rate : 33.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.636
Stream size : 11.0 GiB (88%)
Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS XBR
Format/Info : Digital Theater Systems
Commercial name : DTS-HD High Resolution Audio
Muxing mode : Stream extension
Codec ID : 133
Duration : 47 min 51 s
Bit rate mode : Constant
Bit rate : 2 046 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 700 MiB (5%)
Audio #2
ID : 4353 (0x1101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 47 min 52 s
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 153 MiB (1%)
Service kind : Complete Main
Audio #3
ID : 4354 (0x1102)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 47 min 52 s
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 153 MiB (1%)
Service kind : Complete Main
Text
ID : 4608 (0x1200)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Delay relative to video : 29 s 80 ms
No.
I can remux a small section to MKV easily enough, but 1) it’s possible that the fact that it’s in m2ts format is contributing to the problem (haven’t checked yet), and 2) to trigger the issue I need to skip far enough ahead to get to a part of the video it hasn’t buffered yet - skipping just 10 seconds, for example, doesn’t crash it; even skipping 1 minute tends not to. So, a file less than 5 or 6 minutes long won’t be able to reproduce the problem, and one 5 or 6 minutes long will (I guess) be too big to upload.
Having now had time to check: remuxing to MKV seems to solve the problem, so it must be something to do with it being in m2ts format.
M2TS doesn’t have any kind of index like MKV has, so the only way to seek is to jump to close to the right time and then start reading the file until you hit a keyframe. Since the video is VC-1, it might be that Kodi doesn’t understand the format well enough to pick out a keyframe from the rest of the stream.
BluRay discs solve this problem by having MPLS and CLPI files to index the M2TS file.
We have some patches to handle key frames when seeking backwards, but they may not be working as expected for all containers
Sam
In my case I was seeking forwards, if that’s relevant.
Does that theory explain why a 1-minute jump works but a 5-minute one doesn’t?
The difference, I think, is to do with whether the point being jumped to is already cached or not: the moment when it crashes is after it does some buffering; if there’s no buffering, it recovers and carries on.
As far as I’m concerned, this isn’t a major problem, incidentally - if necessary I can just remux everything as mkv - but I thought you guys might be interested in checking it out anyway.
If I have time tomorrow I’ll check to see if the same thing happens with an h.264 m2ts.
Is the scene relatively static while Attenborough commentates?
If so, yes, because the complexity (without getting on to the different types of frames), will be reduced.
VC1 has always been a pain. I’ll look in to this.
