I could make some full TAB and SBS also but I’m not using them.
Thanks for all the samples, I think they will be of help! I’ll download them tomorrow.
Regarding the bug (sometimes big scaled off screen), I remember now that I’ve seen it earlier: with the Pi I’m still on 17.6 because jumping to 18 resulted in this bug. Too bad it looks like it still rears it’s ugly head.
When I’m examining the PGS files I guess it looks like this bug occurs when the PGS picture size exceeds 960 pixels horzontal (half the 1920 screen resolution size)
I’m still having a lot of half Top Bottom 3D’s but - at a slow pace - moving to MVC so it’s less of importance for me but it’s still a very common used format in the wild…
That would definitely help me! 30 second clips will do. Thanks!
Yes, we had such an issue. I can’t tell when I’ve fixed it, but in the current version it should be fixed.
Right. Exactly that was the issue. As mentioned above, that should have been fixed. But you’ve mentioned above that it happens with the current version?
Since you’ve mentioned the Pi - just to be sure, we’re talking about playback issues on the Vero 4k/4k+ here, right?
Yep, Vero 4K+ 19.4
All of that is what you would expect. There’s no need to adjust the depth of PGS subtitles that are authored to have the correct depth on a per-subtitle basis. You only need the depth adjustment on subtitles that aren’t sensitive to per-subtitle depth values, e.g. SRT.
Perhaps the lack of per-subtitle depth information for PGS in the other two formats is because the information is not actually in the video file? If I recall correctly, the subtitle track itself doesn’t do any more than associate itself with a particular plane index (e.g. plane 0, plane 1, etc. ) The information about what depth plane 0 should be displayed at, at any given moment, is contained within the video stream, and updated every frame. So, maybe the process you used to create the HSBS and HTAB files doesn’t actually add the subtitle plane depth information to the video file?
@tanio99 can tell us whether the depth information is actually present in your hsbs and htab samples; if it isn’t, then that explains some of what’s going on
P.S. Try using WeTransfer.com next time, it’s less annoying. 
@tanio99 , I did some more testing, using @movieaddict’s samples. The good news (from your perspective!) is that the corruption I was seeing along the top edge of tab and along the right edge of sbs are, indeed, being created by my video processor 
so you don’t have to worry about those. 
The bad news is that picture going crazy when I try to adjust the SRT subtitle vertical position on sbs or tab is a bona fide issue.
Another thing I noticed is an (I think, long-standing) thing where the Vero tells the television that the aspect ratio is 4:3 rather than 16:9. I don’t normally notice that, because I keep the TV locked to 16:9 mode and use my video processor to control aspect ratio; but I happened to be using a different input on the TV today and the Vero switched the TV to 4:3 as soon as I started playing the MVC sample.
Here are some logs of me playing the sbs sample and attempting to adjust the subtitle position:
Full SBS and full TAB samples:
1 Like
Fresh installed the RPI 3B+ to 18.9 to check: same bug.
I guess it was fixed in the later 17 versions and sneaked back in afterwards.
Same here…
That’s right. The video stream contains the depth information on a per frame basis. If that info is lost, well then the depth info is lost. I can check the hsbs/htab files later today.
Yeah, I can see in the log what’s wrong. Somehow the position change has an influence on the display geometry and that’s weird because that shouldn’t be the case. I need to investigate it.
Hmm, I wasn’t aware of that issue. Will have a look, too.
Will check, maybe there’s a regression - I’ve fixed that issue some time ago.
If those files are supposed to be full SBS and TAB, I would expect their dimensions to be roughly 3840x1080 for SBS and 1920x2160 for TAB. But they both seem to be 1920x1080…?
Sorry, you are totally right!
I’m getting old 
I have upload another set (hopefully right this time / with correct audio) and edit the original link to the new ones.
@angry.sardine, I had a look at it today. I think to support 1920x2160 as FP would be easier to implement than 1920x1600 as FP. It would also be possible to convert full-sbs/tab to half-sbs/tab for those TVs that don’t support frame-packed input.
Note: I don’t say that I do implement it 
.
How many displays are there which are 3D-capable but don’t support frame-packed input?
Well, I can’t tell, maybe some PC displays?