[VCDImager Bugs/Devel] Re: new vcdimager

[Herbert Valerio Riedel]

btw, the developer list is still at address@hidden :-)

On Sun, 24 Dec 2000, Mike Bernson wrote:
> I have still have a problem with times on the current
> vcdimager. The vcd plays but does not show time on the
> front of the dvd player. The player also lockup when
> trying to fast forward or do time searches.
are you really talking about VCD2.0? or are you refering to SVCD1.0?

as for SVCD, I haven't filled search.dat yet, since I wanted to have an
alpha release out for this year to get more feedback from a wider
userbase. I'll put this issue as a 'known bug' on the hp.

> We still do not have a vaild PSD.VCD file. Does someone
> have the format info for this file. I would be willing
> to look into build the file correct.
u really mean '/VCD/PSD.VCD'?

I'm quite sure it is valid already... I couldn't see any difference when
comparing them to other VideoCDs not made with vcdimager...

btw, all information about those files is in /libvcd/vcd_files_private.h,
and it's quite complete thanks to jens.

> Is there any other files that deal with time info. I would
> like to have the time function working. I would be willing
> to help/do the need work but do not have the standard doc
> for vcd or svcd. The doc I have does not go into the detail
> for this file.

...the main problem is more how to do it the-right-way(tm) without
breaking the actual program design too much :-)

the correct way would be to scan the mpeg streams beforehand while
building the search.dat timestamp list, and then reread them when creating
the image. (the idea is not to have to seek around in the output image
file, since the output should be pipe-able in future, as to be able to burn
a VCD on-the-fly...)

the efficient way would be to build the search.dat table while writting
the image.. but this would imply to have to reserve some fixed space for
that search.dat file, and after having finished writing the image to have
to seek to the beginning again, to write that file... well... actually
that'd be neat, but it would result in some ugly-hack...

another way was to just guess where those timestamps may be... this would
be efficient and not-too-hacky but everything else but correct...

...

it'll be the first way, the correct one, I'd want to use...
maybe there is a clever way to scan an mpeg2 stream without having to read
_every_ mpeg packet and still be able to build a correct search.dat...


PS: can anyone tell me, what the header of an MPEG streams system header
exactly looks like? especially for mpeg1... (and then, if it's still valid
for mpeg2 streams...)

since I've had to add the following 'hack', in order to get playable
MPEGAVxx.DATs... (I had some mpeg1 streams, whose first 2 mpeg packets
were otherwise detected as 'MPEG_TYPE_NULL'... since they contained only
a packet, a system and a null block...)

from vcd_mpeg.c:

              case MPEG_SYSTEM_HEADER_CODE:
                {
                  int size = _bitvec_get_bits32 (data, offset, 16);
                  /* fixme -- boundary check assert (offset + 16 < 2324 *
8) */
                  offset += 16;

                  /* just a hack, since I don't know exactly what the
                     format of the system header is */
                  if (!extended_type_info && size > 6)
                    switch (_bitvec_get_bits32 (data, offset + (6 * 8),
8))
                      {
                      case 0xe0:
                        return MPEG_TYPE_VIDEO;
                        break;
                      case 0xc0:
                        return MPEG_TYPE_AUDIO;
                        break;
                      default:
                        /* noop */
                        break;
                      }

                  offset += size * 8;
                }
                break;


-- 
Herbert Valerio Riedel      /     Finger address@hidden for GnuPG Public Key
GnuPG Key Fingerprint: AC2A CD57 A5C8 A1CB 0A18  DA95 CB0B DB23 60B6 16F5