Page 2 of 2
Re: MKV issue with 3.0.0-a3
Posted: Tue Sep 03, 2013 5:29 pm
by DeFlanko
Subjunk thats what i thought too but as more and more of those post come up i'm really wondering how those 3D MKV's are built... Is there anyway to tell? or have the Posters run an app to see what kind of 3D MKV it is?
Re: MKV issue with 3.0.0-a3
Posted: Tue Sep 03, 2013 11:24 pm
by Wolfgan
DeFlanko wrote:Subjunk thats what i thought too but as more and more of those post come up i'm really wondering how those 3D MKV's are built... Is there anyway to tell? or have the Posters run an app to see what kind of 3D MKV it is?
Usually scene codes 3D videos in a plain mkv were the video is coded as SBS (Side By Side, screen splitted in 2 vertical or horizontally), and the TV engine is then forced to interpret it as a 3D video. Usually the problem comes with harcoded subtitles, where they are pasted in full video width size, instead of replicate it in both video halves for the TV to combine them...
Re: MKV issue with 3.0.0-a3
Posted: Wed Sep 04, 2013 8:29 am
by SubJunk
Yeah in the case of SBS or OU video with subtitles another program is needed like 3DSubtitler to convert the 2D subtitles to 3D. Then they will work on UMS.
I guess it's possible to automate that in UMS. We wouldn't be able to reliably detect whether the video is 3D if the person has renamed the file, because those files have no difference to 2D files in terms of container settings, but we could detect things like "3D" or "SBS" from the filename. We wouldn't be able to support vobsub subtitles because we couldn't know if they had already been converted to 3D, but we could do SRT conversion which I guess is the most common one.