Error: AVI files are not played correctly with the new kernel. They work fine with the old kernel, and they work fine with amcodec hardware acceleration disabled on the new kernel. With new kernel and amcodec HW acceleration enabled, they play with maybe double the video speed and stuttering, aka: video is running quickly away from audio.
Repeat by:
get an example mp4 file, here is one freely downloadable from german TV:
This plays fine on any other kodi i have and old kernel vero4k, but not new kernel amcodec enabled. Does play of course fine with amcodec acceleration disabled.
For whatever reason i have disks full of TV recordings in avi format and converting them all for one odd broken media player doesn’t seem appropriate.
old kernel == re-installed vero4k+ from latest sd card image:
OSMC_TGT_vero3_20201023.img.gz
can’t remember kernel version of that. something like 3.141592653… ?
new kernel = 4.9 kernel after following the upgrade instructions from post 1 of this thread.
Sam: my first post had simple instructions for you to create such a file. Just play that file with an old 3.14 kernel OSMC with/without amcodec enabled, or any other kodi, play it with new 4.9 kernel OSMC with amcodec disabled in player settings: All these will play these files perfectly fine.
ONLY on OSMC 4.9 kernel will these files not play correctly.
It doesn’t matter – the frame rate in the file you have produced is incorrectly reported.
If your AVI files have been produced in this manner, then it’s no surprise that they don’t play properly, and not a fault of OSMC.
I can look in to it at a later date, but it’s very low priority. The file should have the correct characteristics in its container for us to play it properly.
We are trying to play the content at the frame rate reported in the container – i.e. doing the right thing.
As a work around – you can change hardware acceleration to ‘HD and up’. This will not use hardware acceleration for these files, and ffmpeg will be able to detect the correct frame rate.
Aka: No differering “frame rate” and “original frame rate”.
Both files will equally play fine on any player HW/SW i have (older OSMC, any other kodi, VLI, etc. pp), OSMC kernel 4.9 without acceleration. Both files will equally play incorectly on OSMC kernel 4.9 with acceleration.
Displaying “video process information” shows for both files:
Resolution: 1,024x576 px, 1.78 AR, 25.000 FPS - on working system
Resolution: 1,024x576 px, 1.78 AR, 277.778 FPS - on OSMC 4.9 accelerated (after waiting for a few seconds, it starts with 25, probably from file info and then updated dynamically from decoder ?).
Aka: whether the frame rate shown by mediainfo is 50 in one file or 25 in the other file does not make a difference in behavior. And it works either way on any player i have except your new 4.9 code ;-(
What log do you need, just normal kodi debug log ?
The URL i gave you is not quite what i have been converting into avi for 12 years now (hence the TV of stored data and the reason for sticking to .avi given how this is the first avi related problem i had in 12 years ):
All the public german TV stations seem to have the same format, right now i can receive what i think is the original on Astra satellite. It seems to be 720p50 h264, obviously in TS container. From what i see, the highest resolution version they put onto their web service is just converted from TS to mp4 container and bitrate compression by about factor 4, but no change in frame rate. For example same video clip, highest resolution:
Then they also have a medium size format for which i gave you the url first, where they do some spatial downscaling and reduce the frame rate to 25fps. Probably just by cutting every second frame without changing the clock/timecodes in h264. Then they also create an interlaced version, 50i which they encode into MPEG2 for SD on satellite.
The problems with OSMC are the same with conversions from satellite TS avi as from web mp4 to avi. I gave the web mp4 because i don’t have a place to upload some Gigabyte TS files. And of course, in my actual workflow, i am further compressing the h264 without frame rate changes.
In reality of course, most of my terrabytes of recorded TV is from pre-HD time, aka: 576i, encoded first with mencoder then ffmpeg as h264 interlaced, of course with avi. And the effects are exactly the same when playing on OSMC 4.9.
I did an update from the command line earlier this evening and got lots of warning messages about folders that couldn’t be deleted because they weren’t empty. Should I be concerned?
And talking of updating from the command line, I know people have mentioned this before, but something that I’ve tripped over several times recently is the thing where, if the Vero reboots with the TV turned off, it deletes all the entries in the whitelist and refuses to switch resolution or refresh rate until after it has been rebooted with the TV on. Is that going to be fixed at some point?
I’ve seen this (or something similar) in several logs:
Preparing to unpack .../mediacenter-addon-osmc_3.0.692_all.deb ...
Unpacking mediacenter-addon-osmc (3.0.692) over (3.0.689) ...
dpkg: warning: unable to delete old directory '/usr/share/kodi/addons/script.module.osmcsetting.updates/resources/osmc': Directory not empty
dpkg: warning: unable to delete old directory '/usr/share/kodi/addons/script.module.osmcsetting.services/resources/osmc': Directory not empty
dpkg: warning: unable to delete old directory '/usr/share/kodi/addons/script.module.osmcsetting.remotes/resources/osmc': Directory not empty
dpkg: warning: unable to delete old directory '/usr/share/kodi/addons/script.module.osmcsetting.networking/resources/osmc': Directory not empty
dpkg: warning: unable to delete old directory '/usr/share/kodi/addons/script.module.osmcsetting.logging/resources/osmc': Directory not empty
dpkg: warning: unable to delete old directory '/usr/share/kodi/addons/script.module.osmcsetting.apfstore/resources/osmc': Directory not empty
I can’t shake the feeling there is some sort of logic issue here. It’s as if it tries to read an EDID, doesn’t get anything back, and then treats that as if it were a valid but empty EDID rather than an entirely non-existent one.
I’m sure this has been raised before - people complaining about it switching to 720p if you reboot with the TV off.
This specifically was solved some time ago. Whenever there is an HPD event, our monitor will reparse the EDID accordingly.
Do you have a log of this occurring so we can see what Kodi does?
I agree that if EDID is empty, we should not edit whitelist. I’m surprised Kodi is doing this at all.