[xine-devel] Strangely formed MPG (Boszormenyi Zoltan)

[R. B. <ro...@pa...>]

Boszormenyi Zoltan queries:
 > I came across an MPG file that is recognized as a RIFF AVI
 > by the utility 'file'. What I found wierd is that xine plays
 > this file nicely but not the srt subtitle that came with this file.
 > Then I found vcdimager-0.7.14 

vcdimager 0.7.20 was recently released.  Download from
  ftp://ftp.vcdimager.org/pub/vcdimager/vcdimager-0.7_UNSTABLE
or 
  http://www.vcdimager.org/pub/vcdimager/vcdimager-0.7_UNSTABLE/

  (and RPMs can be obtained from packman
    http://packman.links2linux.org/?action=295
    http://packman.links2linux.org/?action=251)

Some memory leaks were fixed, so if you use this xine VCD playing will
probably be slightly improved. 

 > and it turned out to be a CDXA RIFF.

Not exactly sure what you mean by this, but I'll take it to mean (and
guess it is) an AVI file contained inside CD-XA formatted sectors with
a RIFF header surrounding the whole thing.

 > With the cdxa2mpeg utility I extracted the mpeg stream out of this file
 > and now the subtitle is displayed, too. Even when I repackage
 > this MPG into a real SVCD format, put the srt file on the
 > ISO9660 track, burn it into a CD, xine is able to play them.

SVCD's use their own format: Philips OGT. In this sense what you are
doing is using xine VCD plugin to pick out the MPEG payload from the
mode2 sectors (just as cdxa2mpeg does) and then using xine's subtitle
mechanism to read the SRT file. Of course, a real SVCD player will
probably not be able to handle the subtitles.

 > 
 > But I don't understand the original problem. 

Another of the many improvements of vcdimager 0.7.20 is a better
description of what cdxa2mpeg does. I quote from the 0.7.20's revised
description of cdxa2mpeg (with emphasis added):

   cdxa2mpeg: 
   A program to strip the RIFF header on CD-XA format tracks containing
   a RIFF header.

   On Microsoft Windows, people would extract the payload tracks of
   Video CD's (e.g the tracks other than the first one) by simply copying
   the .dat/.mpg files as seen in the filesystem of a (Video) CD.

   Since many MPEG players will play tracks copied this way, people
   tend to think of these as an MPEG files, but they are not. Instead they
   have a RIFF container around the MPEG stream, including some mode2
                                                 ^^^^^^^^^^^^^^^^^^^^
   sector headers prepended to each MPEG "sector". Presumably the RIFF
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   container is automatically inserted by the Operating System or
    filesystem; it isn't part of a Video CD.

   In such a setting, `cdxa2mpeg' will extract the MPEG portion by
   stripping off the (inserted) RIFF container and mode2 sector headers.


 > If I guess right,
 > two demuxers are needed to play this MPG. The extracted file is
 > more than 10MB less than the original, so it's not only a header I guess.

Yep, not a single "header" but a header at the beginning of each
sector (and possibly end - my definition of cdxa2mpeg above may be
wrong now that I think of it).

 > I may be wrong, the binary file produced by vcdimager is larger
 > about the same amount. 

That is probably roughly true, if not exactly true.

 > How comes that xine does not display the
 > subtitle with the original? 

I'm not exactly sure where the SRT-format subtitle was in the original
file. Is this a separate entity or intermixed in with the AVI? Given
what's going on, you are sort of lucky that media players try to all
sorts of things to tolerate whatever's there. I'm not sure how
otherwise something *could* deal with this funny hybrid. 

(The AVI was probably created on Microsoft Windows where the OS
probably added that RIFF header and then it was copied with the header
onto disk and probably transported to another OS which may not deal
with RIFFs in the same way.)

 > How this CDXA RIFF fits into the
 > master/slave demuxer architecture of xine?

As far as I know, in xine there is no CD-XA RIFF handler in xine other
than what you incidentally get when you fool xine into thinking what
you have is a VCD. It is very likely that in such circumstances xine
will play whatever is in the container, whether it is MPEG, DIVX;-),
or MPEG4. In contrast to vlc where the VCD input plugin specifies a
specific kind of demuxer (like MPEG I-II), in xine I think the demuxer
determination is automatic based on looking at what comes back. But I
could be wrong on this.