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.
