I’m having trouble with HSBS playback of this file ( Brian_Mays_Brief_History_Of_3D_3D_HSBS.mkv ), and the results get weird in different ways, depending on which projector I’m using … Tried all kinds of naming conventions (3D SBS, 3D HSBS, 3D.HSBS etc) but it won’t work properly. All frame packed MVC works perfectly, always did.
On my Optoma UHD3200A I get 2D, but kind of strangely framed, in the upper left corner: On my Epson TW6700 I get actual 3D, but squished to the top half of the image (as if it were TAB), and the bottom half consists of something like the bottom line of pixels being smeared out over the remaining image space …
HSBS should be the simplest thing in the world, but acts really strange.
Is it a Kodi thing, an MKV format thing, or what is this?
I’m on Kodi 20.2 Nexus, Vero 4K+
Log is here: https://paste.osmc.tv/igutehofem
Thanx in advance!
Does it only happen with this one HSBS file?
If I remember correctly, the filename should be movie_name (year).3d.sbs.mkv
So far, yes. I have a couple of others, which are also HSBS, and seemingly exactly the same mkv specs. I tried naming the file as suggested below ( Brian May’s Brief History of 3D (2011).3d.sbs.mkv or Brian May’s Brief History of 3D (2011).3d.hsbs.mkv ), same result.
Initially I just played back from a random folder, but then tried adding the file to the general library, hoping it would make a difference (which I doubt) …
It gets scraped correctly by Kodi, shows as 3D HSBS in the movie info, but still plays back awkwardly … Would it help with log files on playback of a file that works?
The logs don’t show any errors. Can you provide a short (about 30 to 50 second) clip that can be used to reproduce that issue?
That is what I’ve always thought, too . But unfortunately it’s a more complex thing. I couldn’t believe it, but there are clips out there where the left/right or top/bottom images are in a “right eye first setup”. That means we have to split the picture into two parts, exchange them (if needed) and merge them together again. But that is something that wouldn’t cause the weird results you’re getting.
So seeing is believing :-), the best would be to have a clip which can be used to reproduce it.
Unfortunately, I’ll be on vacation the next couple of weeks and won’t have much time to look into that issue.
You may want to open it up in something like mkvtoolnix-gui, and check the stereoscopy metadata setting under the “video properties” of the video track on the file and make sure that is correct. As well as the aspect-ration or “display width/height” settings there. I think any explicit 3d metadata settings in the file itself takes precedence over any file-naming convention (and if the metadata setting is set, it doesn’t matter what the filename is)
Also, open it up in something like vlc to play it “raw” and double-check that the video itself actually is SBS, and not actually a tab file (or some other 3d format!) that was miss-named.
Maybe it’s related too the projector(s) and how the signal is received, but I still find it curious, because other seemingly similar files work fine …
It’s an HDTV rip, so maybe that’s causing some trouble in some way?
In other working HSBS files, mkvtoolnix shows “display width/height” as 1920x1080 and “Stereoscopy” as Side by Side / Left eye first.
This one is the same, except it doesn’t have any setting in the Stereoscopy field. I tried changing that to Side by Side / Left eye first, but it didn’t really help …
And yes, the raw file is unmistakably HSBS in how it looks, and not TAB, but maybe there’s some crazy header info in there somewhere, screwing things up
I’ve downloaded it and will have a look later today.
I think I know what’s going on here. Tools like ffmpeg and mediainfo tell me that the stream is
progressive, but it isn’t. It’s an interlaced stream:
Input #0, matroska,webm, from 'Brian May's Brief History of 3D (2011).3d.hsbs.mkv':
title : Brian May's Brief History of 3D (2011) in 3D
encoder : libebml v1.4.4 + libmatroska v1.7.1
creation_time : 2023-08-24T13:03:30.000000Z
Duration: 00:44:49.31, start: 0.000000, bitrate: 4367 kb/s
Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080, SAR 2:1 DAR 32:9, 25 fps, 25 tbr, 1k tbn, 50 tbc (default)
The decoder correctly returns the interlaced flag in the kernel, and the kernel (I suppose) would handle it correctly, but somewhere that info is lost .
I’m sorry, I think you’ll have to wait a bit for a solution, I’ll have a look at it after my vacation.
Aaaaaah … that might even make a bit of sense … ever so vaguely
It’s originally an HDTV stream, so interlaced makes total sense. I wonder if a quick fix could be to Handbrake the file into some kind progressive stream?
Thanx for your help so far, don’t stress over it !!
I’ve found and fixed that issue. An “interlaced check” was missing in the 3D code.
I’ve built @tanio99’s fix.
I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:
- Login via the command line
- Run the following command to add the staging repository:
echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list
- Run the following commands to update:
sudo apt-get update && sudo apt-get dist-upgrade && reboot
- Your system should have have received the update.
Please see if the issue is resolved.
I also recommend you remove
/etc/apt/sources.list.d/osmc-devel.list after updating.
This will deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.
Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.