Patch by Todd Schmuland.
Explanation by Todd Schmuland:
I own a WDTV. So far it's the only hardware media player that can
handle VobSub subtitles. It's not perfect however. One major flaw it
has is not displaying subtitles that have no SPU duration embedded in
them (the cause of the vobsub_reader: Could not extract the duration
for a SPU packet). The normal behavior a player should do is display
the subtitle frame until the next subtitle is displayed, but the WDTV
simply chooses to not display the subtitle at all.
So I wrote a hack --engage vobsub_subpic_stop_cmds that writes in a
Stop Display command into these packets. The end result is that the
WDTV displays the subtitles now. There is a slight flicker if the two
subtitle frames are the same, but it's a lot better than not seeing
the subtitle at all. Since this is adding SPU content not in the
original VobSub, I used the hacks mechanism to implement it.
Hopefully WD will properly handle VobSub subtitle frames with no Stop
Display command in a future firmware update, but until then I'll use
this hack.
Patch by Todd Schmuland (see AUTHORS).
His explanation:
I was muxing a DVD and mkvmerge complained about losing sync while
parsing the vob. I checked to see what was happening and discovered
the length of a 00 00 01 BE padding packet was way too long. This
resulted in several packets being skipped over and therefore caused a
gap in the resulting mkv. I've seen this before where the packet
length specified in a 00 00 01 BE padding packet is incorrect.
I've made adjustments to the r_mpeg_ps.cpp code to detect when 00 00
01 BE padding packets have the wrong length specified. Padding
packets should always fill the gap to the next 2048 (800 hex) page in
the file. Now the code will detect lengths that are way too long, or
lengths that are just under or just over what they should be, and
correct it.
I also changed it so that with one -v switch, you won't get 100s of
mpeg_ps: parse_packet failed messages anymore. Adjusted padding
packet lengths will be indicated with one -v switch, but now good 00
00 01 BE padding stream packets and 00 00 01 BF private 2 stream
packets won't be output as failing anymore.
I was finally able to get a good mkv mux of the DVD with the attached
r_mpeg_ps.cpp file.
I just did another DVD and it had a similar bad padding stream packet.
Packet length in vob was 44036 but should only be 1918. The new
r_mpeg_ps detected and corrected it, whereas the old code would have
skipped (44036-1918)/2048 = ~21 good packets of video/audio.
Fix for bug 245. Patch by Todd Schmuland (see AUTHORS).
Explanation from Todd:
I tried using mkvextract to get VobSub tracks out of a mkv to make sure I
muxed in the correct subtitle stream. What I noticed is that programs like
Subtitle Creator and VobSubStrip would error out on one particular sub file.
After looking into it, the issue is in how mkvextract handles padding
lengths of 1 to 7.
There are two methods, the one mkvextract currently uses is to use the 00 00
01 BA packet where the 3 least significant bits of the last header byte
indicate how many padding FF bytes follow. There's nothing wrong with this,
however, many programs don't decode this properly and error out since they
are expecting the next bytes to be 00 00 01.
The other method is to pad the 00 00 01 BD packet header with FF bytes and
simply increase the header length byte to include the pad count. For
example where padding = 5:
method 1
00 00 01 BA 44 32 4C 46 44 01 01 89 C3 FD FF FF FF FF FF
00 00 01 BD 07 E7 81 80 05 21 0C 93 11 91 <payload>
becomes
method 2
00 00 01 BA 44 32 4C 46 44 01 01 89 C3 F8
00 00 01 BD 07 EC 81 80 0A 21 0C 93 11 91 FF FF FF FF FF <payload>
Notice the 00 00 01 BD total packet length increased from 07E7 to 07EC and
the packet header length increased from 05 to 0A. The benefit of this is
that the 00 00 01 BD header length includes the pad length with no
additional work by a program's decoder, so the SUB file is always properly
parsed while decoding. In fact the DVD this particular VobSub came from
used method 2.
Some Windows installation use code pages as its ANSI code page
that are not supported by the iconv library (e.g. code page 720).
These have to be converted using Windows' own MultiByteToWideChar
and WideCharToMultiByte functions.
Fix for bug 376.
