View Full Version : vstrip bug


hellgauss
17th October 2002, 16:57
Hallo, i use vstrip (CSS) to copy film on my hd, using the command line.
I think i've found a little bug (but maybe i'm wrong):
when i rip a film, at the end of the rip i have a summary (something like this:

Summary:
MPEG Packs = 2712841
System headers = 13285
Private 1 packets = 389119, total bytes = 777657029
Sub 0x20 packets = 1663, total bytes = 2008703 (delay 0:00:47.680)
Sub 0x21 packets = 1533, total bytes = 1787521 (delay 0:00:37.040)
Sub 0x22 packets = 1627, total bytes = 1906711 (delay 0:00:46.360)
Sub 0x23 packets = 1592, total bytes = 1852180 (delay 0:00:46.360)
Sub 0x24 packets = 1676, total bytes = 2036436 (delay 0:00:46.360)
Sub 0x25 packets = 1697, total bytes = 2013805 (delay 0:00:41.400)
Sub 0x26 packets = 9, total bytes = 16497 (delay 0:00:00.985)
Sub 0x80 packets = 189753, total bytes = 383206116 (delay -0:00:00.080)
Sub 0x81 packets = 189569, total bytes = 382829060 (delay -0:00:00.104)
Padding packets = 21800, total bytes = 21728010
Private 2 packets = 26570, total bytes = 26543430
Video 0 packets = 2310437, total bytes = 370045948

In the last line there are informations about video stream, but i think that "total bytes" is wrong. I had a look to the source code and i see that this variable is a dword (=unsigned int), and so the number is the number of bytes % (2^32). Just change the dword type with unsigned __int64 and change %d with %I64d.
I think that this number should be useful to calculate exact bitrate and avoid undersized divx avi.

HG

maven
19th October 2002, 17:23
yep, the dword does overflow, but int64 support is a bit problematic because it is very different on windows / linux... but it'll think of something... ;)