Closed GoogleCodeExporter closed 9 years ago
Do you know how this VOBSUB was created? If I open and re-save with BDSup2Sub
it plays fine, which suggests a possible authoring error from not following the
VOBSUB specification properly. As you mentioned, it does seem to display with
VLC, and also FFPlay & MPlayer. MPlayer2 & MPV show corruption or no display
depending on the renderer. No display with xy-VSFilter, VSFilter, MPC-HC/MPC-BE
ISR.
We'll look into it though, as your linked sample also seems to hang madVR when
XySubFilter is used. Hopefully that will give us a clue about what is wrong.
Original comment by cyber.sp...@gmail.com
on 2 Aug 2013 at 1:10
Attachments:
Honestly, I don't know how they were created - I will ask the user and try and
find out, and will post back here. The Zoom Player forum thread is here:
http://forum.inmatrix.com/index.php?showtopic=14114
Both the user and I tried with BDSup2Sub, and it crashed the program while
trying to load them (I tried with both the current stable 5.1.1 and the latest
snapshot - looks like some sort of Java error). However, I see you have
attached the BDSup2Sub exported version to your post, so I will see if it works
on my end.
Also, I didn't notice originally that my sample hung madVR when used with
XySubFilter. Now that you have pointed it out, I can see the same thing. Do you
want me to post a separate bug report for that?
Original comment by forum.an...@gmail.com
on 3 Aug 2013 at 2:10
I used BDSup2Sub++ (C++ fork) rather than the Java version. The reason the Java
version errors out is because the language code was "eng" when it should be
"en", while the C++ version catches this error. This isn't the reason for the
display issue though.
> Do you want me to post a separate bug report for that?
No, they should both be the same issue. madVR frozen display issues like this
are madVR bugs, either from lack of support or error handling on that end. We'd
first like to investigate if the subtitle bitmap is actually valid, before
reporting the bug to madshi though.
Original comment by cyber.sp...@gmail.com
on 3 Aug 2013 at 4:01
I looked into it a bit more, and that file has yet another issue with the
VOBSUB idx aside from just the language code. The vob.idx "size:" is set
incorrectly to 1920x818, when the vob.sub seems to be 1920x1064, and the
bitmaps are sometimes 1920x819. This is invalid.
The idx "size:" is supposed to represent the video size, and needs to be equal
or greater than the bitmaps and coordinates in the sub file. BDSub2Sub fixes
the sub file to match the idx resolution of 1920x818, which is why it works.
Though in this case I would expect this .sub was authored for a 1920x1080
video, so it can be easily fixed by changing "size: 1920x818" to "size:
1920x1080" in the .idx file. (see attached)
I would recommend reporting this as a bug to whatever application is producing
these invaild VOBSUB idx files. I'm considering closing this as "WontFix".
Original comment by cyber.sp...@gmail.com
on 3 Aug 2013 at 7:28
Attachments:
The madVR freeze occurs since XySubFilter Beta reports a bitmap size and
position of 0px width x 0px height with such samples, which VSFilter.dll likely
just discards. You can workaround the freezing issue by enabling "Override
Placement" in XySubFilter, but the proper solution is just fix the "size:" in
the idx file as described in my previous comment.
Original comment by cyber.sp...@gmail.com
on 3 Aug 2013 at 8:14
Yes, looks like DVDFab (which was the application concerned) had a few problems
with this rip. Thanks for checking this out :)
Original comment by forum.an...@gmail.com
on 4 Aug 2013 at 7:50
The next XySubFilter release will contain a fix for madVR freezing with bad
VOBSUB files. No subtitles will be displayed unless the VOBSUB idx "size" field
is valid for the the coordinates and bitmaps encoded within the VOBSUB sub file.
Original comment by cyber.sp...@gmail.com
on 21 Aug 2013 at 3:14
Original issue reported on code.google.com by
forum.an...@gmail.com
on 2 Aug 2013 at 10:39