[MPlayer-dev-eng] [PATCH] VCD Playback via libdcio

[R. Bernstein]

Sorry this is long...

Diego Biurrun writes:
 > OK, let me explain my background.  VCD playback has always been broken
 > on my machine.  I have an old Plextor SCSI CD-ROM and for some reason
 > it reads VCDs extreeeeeeeemely slow, audio CPU usage goes up to about
 > 1000% and MPlayer displays one frame a second or so.  In short VCDs
 > are unusable for me and I am thus interested in alternative ways of
 > playing them.  It's not a hardware problem, way back when I still had
 > Windows on my machine I could play VCDs without problems.

Oy. I see I'm going to have a tough sell here. The short answer is I
don't really expect this plugin to do better here as currently
written. It might, but I doubt it.

However if you are of a scientific mind and want to get down to the
root of the problem (after all this mailing list purports to be
*development* and *engineering*), then I think we can probably fix this
problem. 

The first thing that would be helpful to me is to run the cd-drive
program from libcdio to see the properties of the drive.

Next let me switch a the problem to CD-DA since that is probably an
easier thing to address/fix. In working on CD-DA plugins for xine and
videolan, the thing that I think helps performance the most is
requesting multi-frame reads. I think the SCSI MMC3 specs allow up to
25 blocks to be read in a single command. On GNU/Linux for a
multi-block audio-mode read, libcdio uses SCSI passthrough; I just
looked at the source to GNU/Linux 2.4.20 and ioctl mechanism issues
frame requests one at a time.

I thought it clever for Mplayer to use cdparanoia for CDDA access, and
I'm surprised this idea wasn't jumped on in xine or videolan. (Ooops,
sorry, I may have just let the cat out of the bag...) Although I'm
sure you've thought of this, you have turned off paranoia correction,
right? If it not it will probably eat up lots of CPU time.

Another thing I'm sure you've thought of is setting the drive speed to
the maximum beforehand, right? (The next release of libcdio will have
something for setting the drive speed as cdparanoia's interface does;
therefore media plugins it should be possible to have user-adjustable
parameters for drive speed while playing; parameters for adjusting the
number of block reads are already there)

Although I don't see how libcdio would beat cdparanioa at raw audio
reading, I suppose it is worth a try and I can probably make up a
simple Mplayer CD-DA thingy (plugin? module?) via libcdio that has
adjustable blocked reads. If you are game, so am I and it may
help. (My own results on both xine and videolan is that I was getting
better performance via libcdio for differing reasons.)

Now back to VCDs. Well, the 3rd time around at VCD handling for media
players (yes, I saved the best for last ;-) it comes with startling
clarity that what is needed in libcdio is a better multi-block mode2
format2 reading. The interface is there, but underneath a read goes on
one at a time. 

In the early days of libcdio this wasn't possible since I don't think
it's possible on most platforms via an ioctl mechanism. And in fact
none of the big 3 media players do it on any OS that I am aware
of. However recently I added an interface for SCSI MMC commands and I
think that it is possible by issuing an appropriate command. For
devices that don't support SCSI-MMC, libcdio can always fall back to
reading a block at time as it does now. (But I think on GNU/Linux
SCSI-MMC is provided by emulation if it isn't native).


 > So libcdio may be an alternative way of handling VCDs that might
 > actually work on my box (and might also give us VCD support under
 > Windows).  From a cursory reading of the code I cannot really tell if
 > I am using libcdio or MPlayer's native VCD handling when I type
 > 'mplayer vcd://'.

All I did was replace the custom CD reading routines with those from
libcdio. The simplification and cleanup were a by-product :-) So is that
fancy CD-media classifiation routine since that too is in libcdio. (In
the libcdio package, the standalone program cd-info gives you this
information too.)

 > 
 > Some more comments on your patch: On line 117 of stream_vcdx.c you
 > have ;; which fails to compile with gcc 2.95.  

Fixed.
 > You should add doxygen
 > comments to your file, the new patch policy demands it.  

Done. 

 > Furthermore,
 > you have trailing whitespace here and there, it's nicer without.
Fixed. 

Here's the new stream_vcdx.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stream_vcdx.c
Type: application/octet-stream
Size: 6156 bytes
Desc: stream_vcd.c via libcdio
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20041217/5716a777/attachment.obj>
-------------- next part --------------

By the way, I notice some "stream" plugins start stream_xxx.c and
there is dvdnav_stream.{c,h}. And then there's cdda.c which doesn't
have stream anywhere in it. Is there a preferred convention?