On Sun, 1 Jun 2003, Todd Vierling wrote:

> On Sun, 1 Jun 2003, Frederick Bruckman wrote:
>
> : Your package leaves out "libavcodec" -- that directory is supposed to
> : be dropped in from out of the "ffmpeg" repository -- and you forgot to
> : do "mencoder".
>
> I didn't change the CONFIGURE_ARGS.

The developers have some funny ideas about release engineering. The
code for the principle Open Source codecs is actually missing from the
CVS version. (Without it, you can still play many of the same files
using the win32 codecs.) The configure script automatically detects
the "libavcodec" subdirectory and adapts accordingly. It's not visible
in the PLIST, either, because the native codecs are linked staticly.

> : Both builds do fail the way you describe with a single argument of
> : "vcd://". You have to use "vcd://2" to play the first mpeg stream,
> : "vcd://3" to start with the second one, and so on. Is that it?
>
> @$?&!

<Heh.> If you'd posted the command line in your original post, I might
have caught that earlier. For the record, "mplayer vcd://2//dev/rcd0d"
should always work, even without a "/dev/cdrom" symlink.

> Yes, that's it.  This is obviously a huge bug, because the GUI gmplayer uses
> only "vcd://" as the URL for opening the disc itself, causing those errors
> and making it look like the disc is messed up.

I agree. The command line parser should at least complain, rather than
letting the SCSI layer fly off into space. You might try sending a bug
report to mplayer-users.

Frederick