Device for DVD with mplayer/current/devfs?
Edwin Culp
following error with acd0a and acd0c and devfs doesn't have a dvd device :
# mplayer -dvd 1 /dev/acd0c
MPlayer 0.50pre-1(C) 2000-2001 Arpad Gereoffy (see DOCS!)
Reading /root/.mplayer/codecs.conf: 18 audio & 39 video codecs
Font /root/.mplayer/font/font.desc loaded successfully! (495 chars)
Playing /dev/acd0c
libdvdread: Can't open path /dev/acd0c.
Couldn't open DVD device: /dev/acd0c
Exiting... (End of file)
Thanks,
ed
---
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message
Thomas E. Zander
Am Fr , dem 12. Okt 2001, um 12:28 -0700 Uhr schrubte Edwin Culp
zum Thema [Device for DVD with mplayer/current/devfs?]:
> I decided to try playing a dvd on my laptop running current. I get the
> following error with acd0a and acd0c and devfs doesn't have a dvd device :
>
> # mplayer -dvd 1 /dev/acd0c
>
> MPlayer 0.50pre-1(C) 2000-2001 Arpad Gereoffy (see DOCS!)
>
> Reading /root/.mplayer/codecs.conf: 18 audio & 39 video codecs
> Font /root/.mplayer/font/font.desc loaded successfully! (495 chars)
> Playing /dev/acd0c
> libdvdread: Can't open path /dev/acd0c.
> Couldn't open DVD device: /dev/acd0c
>
> Exiting... (End of file)
Although I don't have a -current system at the moment, I saw this on a
-stable machine using libdvdread in a version earlier than 0.9.
Riggs
--
- Die Welt schläft tief schon lange Zeit | Sent with RiggiSmooth [tm] -
-- Mich nur flieht die Dunkelheit | ------------------------- --
--- Denn per Infrarot seh ich | just to fit your ---
---- Die Nacht ist wirklich widerlich. | primitive screen. ----
Edwin Culp
Using dvdread 9.2, solved the device problem. It works ! G R E A T ! and
so much better and easier than other solutions and hacking I've done previously.
Thanks,
ed
Quoting Randall Hopper <aa...@nc.rr.com>:
| Edwin Culp:
| || |# mplayer -dvd 1 /dev/acd0c
| || ...
| || |libdvdread: Can't open path /dev/acd0c.
| || |Couldn't open DVD device: /dev/acd0c
| ||
| || Don't have current here either. mplayer works here on 4.3-stable (from
| || June) with dvdread 0.9.2 as mentioned on the list, with /dev/acd1c
| linked
| || to /dev/dvd, and running as root.
| ...
| |I tried that this morning and I get "can't open path /dev/dvd"
| |I can dd if=/dev/dvd with a block size and a count and read the title
| |so the link works.
|
| Your mplayer is still linked with libdvdread-0.8.0. 0.8.0 contains that
| error string, but 0.9.2 does not.
|
| This may help:
|
| > /bin/ls -l /usr/local/lib/libdvdread* | cut -c47-
| /usr/local/lib/libdvdread.a
| /usr/local/lib/libdvdread.la
| /usr/local/lib/libdvdread.so -> libdvdread.so.2 <------------
| /usr/local/lib/libdvdread.so.1
| /usr/local/lib/libdvdread.so.2
|
| > ldd /usr/local/bin/mplayer
| /usr/local/bin/mplayer:
| ...
| libdvdread.so.2 => /usr/local/lib/libdvdread.so.2 (0x2843c000)
| ...
|
| And FWIW, this is what I did to build mplayer with libdvdread-0.9.2:
|
| - Installed dependencies (less libdvdread); namely: win32-codecs,
| svgalib, sdl, png, libaudiofile, imake, gtk, glib, gettext, freetype2,
| esound, aalib, XFree86, Mesa, libdvdcss
|
| - Fetched libdvd 0.9.2 src pkg to /usr/ports/distfiles
|
| - Fetched libdvd port, nuked files/ subdir, change PORTVERSION in
| Makefile to 0.9.2, make makesum, make configure,
| ln -s /usr/local/bin/libtool work/libdvdread-0.9.2/, make install
|
| - Fetched mplayer port, and installed with:
|
| make WITH_MMX=YES WITH_3DNOW=YES WITH_DSP=YES WITH_GUI=YES \
| WITH_OPTIMIZED_CFLAGS=YES WITH_CSS=YES \
| install
|
| Note that this doesn't result in a correct package list for
| libdvdread-0.9.2 (so pkg_delete won't work perfectly), but that's not a big
| deal to me.
|
| Randall
|
| --
| Randall Hopper
| aa...@nc.rr.com
Randall Hopper
|| |# mplayer -dvd 1 /dev/acd0c
|| |libdvdread: Can't open path /dev/acd0c.
|| |Couldn't open DVD device: /dev/acd0c
||
This may help:
Randall
--
Randall Hopper
aa...@nc.rr.com
To Unsubscribe: send mail to majo...@FreeBSD.org
Volker Stolz
Reading disc structure, please wait...
libdvdread: Can't open file VIDEO_TS.IFO.
Can't open VMG info!
although I did update libdvdread (0.9.2) & mplayer (0.50.2?).
Any more hints?
--
Volker Stolz * st...@i2.informatik.rwth-aachen.de * PGP + S/MIME
Jason Andresen
>
> Hrmpf, I keep getting:
>
> Reading disc structure, please wait...
> libdvdread: Can't open file VIDEO_TS.IFO.
> Can't open VMG info!
>
> although I did update libdvdread (0.9.2) & mplayer (0.50.2?).
> Any more hints?
Make sure you are passing the correct device to your program,
some of them (ogle) don't chase symlinks for some reason and
only work when I give them /dev/acd0c as the device.
--
\ |_ _|__ __|_ \ __| Jason Andresen jand...@mitre.org
|\/ | | | / _| Network and Distributed Systems Engineer
_| _|___| _| _|_\___| Office: 703-883-7755
Volker Stolz
> > libdvdread: Can't open file VIDEO_TS.IFO.
> > Can't open VMG info!
> >
> some of them (ogle) don't chase symlinks for some reason and
> only work when I give them /dev/acd0c as the device.
Thanks, the problem vanished after the next reboot. Maybe the
DVD-drive didn't like me probing around :-)
Anyways, both the new xine version and mplayer now play DVDs,
but mplayer is dead SLOW. It says to RTFM, but I can't find
any hints :-/ (It's using Xv)
--
Volker Stolz * v...@foldr.org * PGP + S/MIME
Rahul Siddharthan
> Anyways, both the new xine version and mplayer now play DVDs,
> but mplayer is dead SLOW. It says to RTFM, but I can't find
> any hints :-/ (It's using Xv)
-framedrop
(by default it plays all frames, which tends to make the video out of
sync with the audio, if that's what you mean)
R
Mario Sergio Fujikawa Ferreira
> Volker Stolz wrote:
> >
> > Hrmpf, I keep getting:
> >
> > Reading disc structure, please wait...
> > Can't open VMG info!
> >
> > Any more hints?
>
> some of them (ogle) don't chase symlinks for some reason and
> only work when I give them /dev/acd0c as the device.
Well, since picking the right device will be a problem.
What's the device people want as the default? I will be committing
ogle in the next few days and I would like to know which is the
most preferred device. I chose /dev/racd0c as the default (raw, c
slice) but I can change that if there is enough desire.
Regards,
--
Mario S F Ferreira - UnB - Brazil - "I guess this is a signature."
lioux at ( freebsd dot org | linf dot unb dot br )
flames to beloved dev...@someotherworldbeloworabove.org
feature, n: a documented bug | bug, n: an undocumented feature
Brooks Davis
> Well, since picking the right device will be a problem.
> What's the device people want as the default? I will be committing
> ogle in the next few days and I would like to know which is the
> most preferred device. I chose /dev/racd0c as the default (raw, c
> slice) but I can change that if there is enough desire.
Under current no r* devices exist and they are only compatability devices
in 4.4, IIRC. Also, in current /dev/acd0[ac] are historical links and
/dev/acd0 is the disk device.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
Mario Sergio Fujikawa Ferreira
On Mon, Oct 22, 2001 at 06:49:26PM +0200, Oliver Brandmueller wrote:
> On Mon, Oct 22, 2001 at 02:43:48PM -0200, Mario Sergio Fujikawa Ferreira wrote:
> > Well, since picking the right device will be a problem.
> > What's the device people want as the default? I will be committing
> > ogle in the next few days and I would like to know which is the
> > most preferred device. I chose /dev/racd0c as the default (raw, c
> > slice) but I can change that if there is enough desire.
>
> Just make a note about it and let one set it via a simple variable.
>
> make DVDDEV=/dev/racd0c install clean
>
> or something should be fine. If the user does not give a device, assume
> /dev/racd0c - I think, whis would be the most interesting solution.
Yeah, that could do but it should be noted that (I might
be wrong, correct me please if I am) racd0c is a raw device whilst
acd0c is a cooked device
Ogle gets direct access with racd0c. Unnecessary caching
occur with acd0c since the disk cache is used but is not necessary
(gives no performance boost) for dvd playback. The developers say
they can change that in the future, racd0c for ioctl and acd0c for
rest if we find it necessary.... however, I think racd0c is the
right device.
What do you think?
Regards,
--
Mario S F Ferreira - UnB - Brazil - "I guess this is a signature."
lioux at ( freebsd dot org | linf dot unb dot br )
flames to beloved dev...@someotherworldbeloworabove.org
feature, n: a documented bug | bug, n: an undocumented feature
To Unsubscribe: send mail to majo...@FreeBSD.org
Mario Sergio Fujikawa Ferreira
> On Mon, Oct 22, 2001 at 02:43:48PM -0200, Mario Sergio Fujikawa Ferreira wrote:
> > Well, since picking the right device will be a problem.
> > What's the device people want as the default? I will be committing
> > ogle in the next few days and I would like to know which is the
> > most preferred device. I chose /dev/racd0c as the default (raw, c
> > slice) but I can change that if there is enough desire.
>
> in 4.4, IIRC. Also, in current /dev/acd0[ac] are historical links and
> /dev/acd0 is the disk device.
Ahhh, that's what I wanted to know, I did not know that. However,
it seems that /dev/MAKEDEV (latest stable) does not create /dev/acd0
per default, so we should go with acd0c. Or, better, we could add a
/dev/dvd link which points to the correct acd0{,[ac]} like we do with
sysmouse.
Regards,
--
Mario S F Ferreira - UnB - Brazil - "I guess this is a signature."
lioux at ( freebsd dot org | linf dot unb dot br )
flames to beloved dev...@someotherworldbeloworabove.org
feature, n: a documented bug | bug, n: an undocumented feature
To Unsubscribe: send mail to majo...@FreeBSD.org
Scott Long
> > Volker Stolz wrote:
> > >
> > > Hrmpf, I keep getting:
> > >
> > > Reading disc structure, please wait...
> > > libdvdread: Can't open file VIDEO_TS.IFO.
> > > Can't open VMG info!
> > >
> > > although I did update libdvdread (0.9.2) & mplayer (0.50.2?).
> > > Any more hints?
> >
> > Make sure you are passing the correct device to your program,
> > some of them (ogle) don't chase symlinks for some reason and
> > only work when I give them /dev/acd0c as the device.
>
> What's the device people want as the default? I will be committing
> ogle in the next few days and I would like to know which is the
> most preferred device. I chose /dev/racd0c as the default (raw, c
> slice) but I can change that if there is enough desire.
There really isn't such a thing as a raw device anymore, the r* devices
in -stable are just there for compatability sake. Further, -current
does not have r* devices at all, so I would suggest that you make
/dev/acd0c the default.
To add my $0.02, I'm 95% happy with ogle as a DVD player. I have
three gripes, which I think have all been mentioned before.
1) It keeps you waiting while it unlocks all of the titles on the
disk. Maybe just unlock the first few, then unlock the rest
while the copyright or menu screens are on. Or just unlock
each title as it's needed.
2) I get a lot of MPEG artifacts. I'm using a PIII/700MHz machine
with plenty of RAM, XF4.1.0 with XVideo, and xine doesn't have
this problem. It's not so severe as to make the viewing
unpleasant, but it is annoying. Running 'top' shows that the
CPU is 40% idle, so I'm not sure what's going on. There was a
discussion a while back concerning xine and how it seemed that
frame decompression was fine, but frame delivery was abnormally
slow. I'd welcome more thoughts on this.
3) The ogle_gui doesn't work for me. It just sits and waits
forever after displaying 'xsniff_mouse'. This could either be
that I'm using KDE, not Gnome, and it's expecting some piece of
infrastructure that I don't have, or that it spawned a thread
that blocked in the kernel. I haven't looked to much into it.
Other than that, I'm very impressed with ogle. Keep up the good
work!
Scott
Brooks Davis
> Ahhh, that's what I wanted to know, I did not know that. However,
> it seems that /dev/MAKEDEV (latest stable) does not create /dev/acd0
> per default, so we should go with acd0c. Or, better, we could add a
> /dev/dvd link which points to the correct acd0{,[ac]} like we do with
> sysmouse.
For now you are probably best off with acd0c. If acd0 is MFC'd then you
can switch to that (with an appropriate check of __FreeBSD_verion if you
care about 4.4-RELEASE users).
Volker Stolz
> On Mon, Oct 22, 2001 at 03:05:34PM -0200, Mario Sergio Fujikawa Ferreira wrote:
> > Ahhh, that's what I wanted to know, I did not know that. However,
> > it seems that /dev/MAKEDEV (latest stable) does not create /dev/acd0
> > per default, so we should go with acd0c. Or, better, we could add a
> > /dev/dvd link which points to the correct acd0{,[ac]} like we do with
> > sysmouse.
>
> For now you are probably best off with acd0c.
Why? My DVD-player is at /dev/cd0c. So I'd prefer /dev/dvd.
--
Volker Stolz * st...@i2.informatik.rwth-aachen.de * PGP + S/MIME
To Unsubscribe: send mail to majo...@FreeBSD.org
Brooks Davis
> On Mon, Oct 22, 2001 at 10:11:56AM -0700, Brooks Davis wrote:
> > On Mon, Oct 22, 2001 at 03:05:34PM -0200, Mario Sergio Fujikawa Ferreira wrote:
> > > Ahhh, that's what I wanted to know, I did not know that. However,
> > > it seems that /dev/MAKEDEV (latest stable) does not create /dev/acd0
> > > per default, so we should go with acd0c. Or, better, we could add a
> > > /dev/dvd link which points to the correct acd0{,[ac]} like we do with
> > > sysmouse.
> >
> > For now you are probably best off with acd0c.
>
> Why? My DVD-player is at /dev/cd0c. So I'd prefer /dev/dvd.
Because acd0c will work for the most people out of the box. ATAPI DVD
drives outnumber SCSI ones by at least 10:1 and probably more like
100:1 if not 1000:1. I'd rather limit the number of people who are
inconvenienced then make the inconvenience equal.
A standardized make.conf variable for ports would be a better solution.
That would resolve the OS version differences and if you defaulted it to
/dev/acd0c in stable and /dev/acd0 in current it would let those work out
of the box while providing a single place to make the change for SCSI or
other weird cd devices. The problem with /dev links is there are just
too many choices (cdrom, cd, dvd, dvdrom, etc.) and most of them are
used somewhere out there. I think it would be better to standardize it
in the build system since that's something we have some control over.
Mario Sergio Fujikawa Ferreira
On Mon, Oct 22, 2001 at 11:04:07AM -0600, Scott Long wrote:
>
> There really isn't such a thing as a raw device anymore, the r* devices
> in -stable are just there for compatability sake. Further, -current
> does not have r* devices at all, so I would suggest that you make
> /dev/acd0c the default.
That's what I wanted to know. acd0c will be the default but
users can pick another default in build time with WITH_DVD_DEVICE.
Check the updated port
http://people.freebsd.org/~lioux/ogle.tgz
> To add my $0.02, I'm 95% happy with ogle as a DVD player. I have
> three gripes, which I think have all been mentioned before.
>
> 1) It keeps you waiting while it unlocks all of the titles on the
> disk. Maybe just unlock the first few, then unlock the rest
> while the copyright or menu screens are on. Or just unlock
> each title as it's needed.
> 2) I get a lot of MPEG artifacts. I'm using a PIII/700MHz machine
> with plenty of RAM, XF4.1.0 with XVideo, and xine doesn't have
> this problem. It's not so severe as to make the viewing
> unpleasant, but it is annoying. Running 'top' shows that the
> CPU is 40% idle, so I'm not sure what's going on. There was a
> discussion a while back concerning xine and how it seemed that
> frame decompression was fine, but frame delivery was abnormally
> slow. I'd welcome more thoughts on this.
I forwarded both to the developers. I will be echoing the
feedback later.
> 3) The ogle_gui doesn't work for me. It just sits and waits
> forever after displaying 'xsniff_mouse'. This could either be
> that I'm using KDE, not Gnome, and it's expecting some piece of
> infrastructure that I don't have, or that it spawned a thread
> that blocked in the kernel. I haven't looked to much into it.
It's not limitted to your system. That's not an I-am-not-running-gnome issue
since developers use twm and fvwm instead of gnome. :)
The problem is inside an Ogle library called by Ogle_gui.
Ogle_gui is only a gui shell to Ogle calls. The program is locking
up calling msgrcv in MsgNextEvent inside ogle-0.8.0/ogle/msgevents.c
DEBUG: inside MsgNextEvent before msgrcv; params q->msqid (1245184), q->mtype (5)
I am forwarding all logs to the developers, let's hope we
can smooth this out.
Thanks for the feedback.
--
Mario S F Ferreira - UnB - Brazil - "I guess this is a signature."
lioux at ( freebsd dot org | linf dot unb dot br )
flames to beloved dev...@someotherworldbeloworabove.org
feature, n: a documented bug | bug, n: an undocumented feature
To Unsubscribe: send mail to majo...@FreeBSD.org
Oliver Fromme
> That's what I wanted to know. acd0c will be the default but
> users can pick another default in build time with WITH_DVD_DEVICE.
More importantly, is there a way to change the drive at
runtime? Otherwise you cannot share the binary between
different machines (e.g. in environments using NFS or rdist
for a pool of different machines), which would be a PITA.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
Alexander Leidinger
> I'm running current with devfs son I just adjust everything in the
> script that I use to call ogle or mplayer by checking to see if I have
> a link to /dev/dvd or /dev/racd0c depending on which player and if not
> I create the ln -s /dev/acd0c /dev/dvd or racd0c and then start the
> player. Works fine and I just don't worry about reboots etc. Simple
> solution for a simple problem:-)
echo 'ln -sf /dev/acd0c /dev/dvd' >>/etc/rc.devfs
Bye,
Alexander.
--
Where do you think you're going today?
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7