bug-vcdimager
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VCDImager Bugs/Devel] problems with vcdimager 0.7.x


From: Arnd Bergmann
Subject: Re: [VCDImager Bugs/Devel] problems with vcdimager 0.7.x
Date: Thu, 16 Aug 2001 00:27:05 +0200 (MET DST)

On Wed, 15 Aug 2001 address@hidden wrote:

> I'm not sure if this is a bug or not, but I'm getting an assertion 
> when attempting to use either vcdimager.exe or vcdxbuild.exe to 
> create a bin/cue image of a mpeg2 file that I have.  The mpeg2 was 
> encoded with tmpeg1.2a, and was muxed with bbmpeg 1.24 as a SVCD.  
> Vcdimager v 0.6.2 works fine with the mpeg, however both 0.7.7 and 
> 0.7.9 give an assertion about the user data length not being 14.  
> This has happened with every mpeg that I have tried, so either I am 
> doing something VERY wrong or there is a legitimate bug.  Let me 
> know if you need the stack dump file or any sample mpegs to 
> reproduce the problem, as I can make those available if needed.
> 
> [c:\dl\vcdimager]vcdimager -c c:\foo.cue -b c:\foo.bin -t svcd 
> h:foo1.mpg
> ++ WARN: initializing libvcd 0.7.9 [cygwin/i686]
> ++ WARN:
> ++ WARN:  this is the UNSTABLE development branch!
> ++ WARN:  use only if you know what you are doing
> ++ WARN:  see http://www.hvrlab.org/~hvr/vcdimager/ for more 
> information
> ++ WARN:
>    INFO: scanning mpeg sequence item #0 for scanpoints...
> !ASSERT: file vcd_mpeg.c: line 329 (_parse_user_data): assertion 
> failed: (usdi->len == 14)
>       0 [sig] vcdimager 1176 open_stackdumpfile: Dumping stack 
> trace to VCDIMAGER.EXE.stackdump

I am pretty sure this is a bug. The parse_user_data function
does not seem to consider the fact that user_data() in the MPEG
standard can contain any data and not just what may be in
allowed for VCD. My guess is that either tmpeg inserts some
user data of its own (e.g. 'encoded with tmpeg1.2a at ...') or
bbmpeg inserts invalid scan information.

The patch below is a quick fix for the problem, but I don't
have the (S)VCD standard, so I can't tell if it might miss
scan data now.

Hvr probably wants the beginning of the MPEG file to
give a more complete analysis, the interesting part is
whatever follows '000001b2'.

Arnd <><

--- libvcd/vcd_mpeg.c   2001/08/15 08:18:16     1.1.1.3
+++ libvcd/vcd_mpeg.c   2001/08/15 22:06:00
@@ -326,7 +326,11 @@
           {
             struct vcd_mpeg_scan_data_t *usdi = (void *) udg;
             vcd_assert (sizeof (struct vcd_mpeg_scan_data_t) == 14);
-            vcd_assert (usdi->len == 14);
+            if (usdi->len != 14)
+              {
+                vcd_debug ("invalid scan information (len=%d) found", 
usdi->len);
+                return;
+              }
             _check_scan_data ("previous_I_offset", &usdi->prev_ofs, state);
             _check_scan_data ("next_I_offset    ", &usdi->next_ofs, state);
             _check_scan_data ("backward_I_offset", &usdi->back_ofs, state);
@@ -342,7 +345,7 @@
           break;
 
-        default:
-          break;
+        default: /* any unknown user data */
+          return;
         }
 
       pos += udg->len;






reply via email to

[Prev in Thread] Current Thread [Next in Thread]