Thread: Re: [new version of xdvplay]
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-devel
|
From: Gord W. <Gor...@ne...> - 2000-05-20 17:31:20
|
Any chance of making a non MMX version? I'm still on a non MMX pentium. I suppose non MMX wouldn't be fast enough to run xdvplay? Gord Wait Arne Schirmacher <ar...@sc...> wrote: > I have made an own home page for the xdvplay program: > > http://www.schirmacher.de/arne/xdvplay/index_english.html > > There is also a new xdvplay version. It is adapted to the latest version of > libdv. The tar file now contains a copy of a known working copy of libdv, > because the libdv changes rapidly and several users could not compile xdvplay.c > with the latest and greatest libdv version. It has however additional > instructions where and how to get the very latest version. > > http://www.schirmacher.de/arne/xdvplay/xdvplay_latest.tar.gz > > We should really have libdv in library format, as its name suggests... is > anybody listening ? :-) > > I am also working on a patch to the xanim video player program to use the libdv > code. Stay tuned. > > > Arne > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel ____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com. |
|
From: Erik W. <om...@cs...> - 2000-05-20 20:07:01
|
On 20 May 2000, Gord Wait wrote:
> Any chance of making a non MMX version? I'm still on
> a non MMX pentium. I suppose non MMX wouldn't be fast enough
> to run xdvplay?
It's been suggested that libdv be set up with a quality control variable,
which could be tuned all the way down to only decode the DC components (as
demonstrated by someone else's package, the name escapes me at the
moment), which will yield a small thumbnail window (1/8 size both axes),
but can be done on just about any machine capable of actually transfering
25Mbps through it.
Keeping MMX out of the loop will be a function of how the library is
utilized. I've got a prototype of this library style set up in my
bitstream code (which will be used in libdv RSN), but libdv is
sufficiently different that it'll need a different style (difference:
bitstream code is all inlined, so #ifdefs work, but libdv is all library
code, so function pointers must be used).
Just as a general note, we're aiming right now at a 400MHz PII as our
target for non-accellerated playback (i.e. no XFree 4.0 YUV hardware
overlays), and we may eventually be able to squeeze it into to a 300MHz
box, but don't hold your breath. It's that hard of a problem.
Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI
Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
__
/ \ SEUL: Simple End-User Linux - http://www.seul.org/
| | M E G A Helping Linux become THE choice
_\ /_ for the home or office user
|
|
From: Kay S. <kay...@vr...> - 2004-10-20 20:44:19
|
On Wed, Oct 20, 2004 at 01:44:58PM -0400, Paul Blazejowski wrote: > On Wed, 2004-10-20 at 15:17 +0200, Kay Sievers wrote: > > > > '/class/net/eth1' properly (no device symlink) or the sysfs-support of > > > your device's driver needs to be fixed > > > > What driver creates the eth1 device? It needs to crete the "device" symlink > > and the maintainer should know. > > eth1 Link encap:UNSPEC HWaddr > 8A-1C-C7-FF-FF-00-20-ED-00-00-00-00-00-00-00-00 > > is created by the eth1394 driver. [CC: to the 1394 devel-list] The eth1394.c driver needs to create the symlinks in its sysfs representation to get support for modern userspace integration. Most networkd drivers use: SET_NETDEV_DEV(dev, &pdev->dev); to do that. Thanks, Kay |
|
From: Randy.Dunlap <rdd...@os...> - 2004-10-20 23:36:17
Attachments:
eth1394_sysfs.patch
|
Kay Sievers wrote: > On Wed, Oct 20, 2004 at 01:44:58PM -0400, Paul Blazejowski wrote: > >>On Wed, 2004-10-20 at 15:17 +0200, Kay Sievers wrote: >> >> >>>>'/class/net/eth1' properly (no device symlink) or the sysfs-support of >>>>your device's driver needs to be fixed >>> >>>What driver creates the eth1 device? It needs to crete the "device" symlink >>>and the maintainer should know. >> >>eth1 Link encap:UNSPEC HWaddr >>8A-1C-C7-FF-FF-00-20-ED-00-00-00-00-00-00-00-00 >> >>is created by the eth1394 driver. > > > [CC: to the 1394 devel-list] > > The eth1394.c driver needs to create the symlinks in its sysfs > representation to get support for modern userspace integration. > Most networkd drivers use: > > SET_NETDEV_DEV(dev, &pdev->dev); > > to do that. Paul, Can you test this patch, please? Thanks, -- ~Randy |
|
From: Paul B. <pa...@bl...> - 2004-10-21 04:09:47
|
On Wed, 2004-10-20 at 16:26 -0700, Randy.Dunlap wrote: > Kay Sievers wrote: > > On Wed, Oct 20, 2004 at 01:44:58PM -0400, Paul Blazejowski wrote: > >=20 > >>On Wed, 2004-10-20 at 15:17 +0200, Kay Sievers wrote: > >> > >> > >>>>'/class/net/eth1' properly (no device symlink) or the sysfs-support o= f > >>>>your device's driver needs to be fixed > >>> > >>>What driver creates the eth1 device? It needs to crete the "device" sy= mlink > >>>and the maintainer should know. > >> > >>eth1 Link encap:UNSPEC HWaddr > >>8A-1C-C7-FF-FF-00-20-ED-00-00-00-00-00-00-00-00 > >> > >>is created by the eth1394 driver. > >=20 > >=20 > > [CC: to the 1394 devel-list] > >=20 > > The eth1394.c driver needs to create the symlinks in its sysfs > > representation to get support for modern userspace integration. > > Most networkd drivers use: > >=20 > > SET_NETDEV_DEV(dev, &pdev->dev); > >=20 > > to do that. >=20 > Paul, > Can you test this patch, please? >=20 > Thanks, Randy applied the patch to kernel 2.6.9 and now eth1394 creates symlink under /sys/class/net/eth2 lrwxrwxrwx 1 root root 0 2004-10-20 23:58 device -> ../../../devices/pci0000:00/0000:00:0d.0/fw-host0/ Thank you, Paul --=20 FreeBSD -- The Power to Serve! |
|
From: Randy.Dunlap <rdd...@os...> - 2004-10-21 04:14:45
|
Paul Blazejowski wrote: > On Wed, 2004-10-20 at 16:26 -0700, Randy.Dunlap wrote: > >>Kay Sievers wrote: >> >>>On Wed, Oct 20, 2004 at 01:44:58PM -0400, Paul Blazejowski wrote: >>> >>> >>>>On Wed, 2004-10-20 at 15:17 +0200, Kay Sievers wrote: >>>> >>>> >>>> >>>>>>'/class/net/eth1' properly (no device symlink) or the sysfs-support of >>>>>>your device's driver needs to be fixed >>>>> >>>>>What driver creates the eth1 device? It needs to crete the "device" symlink >>>>>and the maintainer should know. >>>> >>>>eth1 Link encap:UNSPEC HWaddr >>>>8A-1C-C7-FF-FF-00-20-ED-00-00-00-00-00-00-00-00 >>>> >>>>is created by the eth1394 driver. >>> >>> >>>[CC: to the 1394 devel-list] >>> >>>The eth1394.c driver needs to create the symlinks in its sysfs >>>representation to get support for modern userspace integration. >>>Most networkd drivers use: >>> >>> SET_NETDEV_DEV(dev, &pdev->dev); >>> >>>to do that. >> >>Paul, >>Can you test this patch, please? >> >>Thanks, > > > Randy applied the patch to kernel 2.6.9 and now eth1394 creates symlink > under /sys/class/net/eth2 > > lrwxrwxrwx 1 root root 0 2004-10-20 23:58 device > -> ../../../devices/pci0000:00/0000:00:0d.0/fw-host0/ > > Thank you, > > Paul So is this correct? Does it do the right thing? -- ~Randy |
|
From: Paul B. <pa...@bl...> - 2004-10-21 04:22:41
|
On Wed, 2004-10-20 at 21:10 -0700, Randy.Dunlap wrote: > > Randy applied the patch to kernel 2.6.9 and now eth1394 creates symlink > > under /sys/class/net/eth2 > >=20 > > lrwxrwxrwx 1 root root 0 2004-10-20 23:58 device > > -> ../../../devices/pci0000:00/0000:00:0d.0/fw-host0/ > >=20 > > Thank you, > >=20 > > Paul >=20 > So is this correct? Does it do the right thing? udev still complains about bus specific file unavailable=20 Oct 20 23:58:12 blaze wait_for_sysfs[2039]: either wait_for_sysfs (udev 040) needs an update to handle the device '/devices/pci0000:00/0000:00:0d.0/fw-host0' properly (bus specific file unavailable) or the sysfs-support of your device's driver needs to be fixed, please report to <lin...@li...> Oct 20 23:58:12 blaze ieee1394.agent[4202]: ... no drivers for IEEE1394 product 0x/0x/0x Regards, Paul --=20 FreeBSD -- The Power to Serve! |
|
From: Kay S. <kay...@vr...> - 2004-10-21 07:57:33
|
On Thu, Oct 21, 2004 at 12:22:46AM -0400, Paul Blazejowski wrote: > On Wed, 2004-10-20 at 21:10 -0700, Randy.Dunlap wrote: > > > > Randy applied the patch to kernel 2.6.9 and now eth1394 creates symlink > > > under /sys/class/net/eth2 > > > > > > lrwxrwxrwx 1 root root 0 2004-10-20 23:58 device > > > -> ../../../devices/pci0000:00/0000:00:0d.0/fw-host0/ > > > > > > Thank you, > > > > > > Paul > > > > So is this correct? Does it do the right thing? Yes, I think so. Randy, thanks a lot for the fast fix. > udev still complains about bus specific file > unavailable I hopefully fixed this one now. Paul, I will send a new patch in reply to your other mail. Thanks, Kay |
|
From: Dan D. <da...@de...> - 2004-11-24 00:25:51
|
Herman, all your points are completely valid; why did you not copy the list? Of course, being valid and being a priority are 2 different things :-). I have agreed to help start managing linux1394 patches, and I have 2 contracts at the moment that is requiring focus on linux1394. However, I am only going to be focusing on stabilisation, compatibility, and udev issues. Recently, I have put a good amount of work into libiec61883, which is nearing a release (by end of year). This new lib is the next generation for streaming media on linux1394 including DV, MPEG2-TS, and AMDTP (audio and music data). Today, it occurred to me that this lib, after some maturity in userspace, could probably be ported easily into kernel code and interfaced into v4l2 and alsa. I am not making any promises and am still not that interested, but it is an approach I recommend to someone considering it. On Tue, 2004-11-23 at 10:22 +0100, Herman Robak wrote: > On Tue, 2004-11-23 at 03:07, Richard Baverstock wrote: > > The reply I got from Dan Dennedy regarding ieee1394 and v4l/alsa > > > > -------- Forwarded Message -------- > > From: Dan Dennedy <da...@de...> > ... > > It is possible when somebody programs it :-). v4l2 provides a stream > > format field that includes an enum for DV. It is not forseeable to > > provide uncompressed video unless using the vloopback device because > > decoding in the kernel is a no-no. > > How about getting pluggable userspace drivers? ALSA can have > soft synthesizers impersonating a sequencer device, after all. > (BTW: Is there a handy mechanism for launching a synth server > automatically on demand?) > > > > Personally, I do not think it is very interesting because there > > are mulitmedia frameworks and uberlibs like ffmpeg that already > > support DV over 1394. Even apps that disguise their framework > > like Xine, VLC, and mplayer can read from DV on stdin. > > But many don't. We're not just talking players here. I am thinking > of NLEs, video surveillance, video conferencing ... -any software that > uses video. Having each application support several APIs and stream > formats internally is a horrible lot of duplicate effort. It holds > back the state of the art for video on FreeNIX. > > > > > and a seperate audio device (instead or in addition to the one > > > (/dev/dv1394) that currently exists)? We're thinking something along the > > > lines of how USB audio devices, when plugged in, become alsa/oss devices > > > or appear to be alsa devices. > > > > It might make more sense for audio since that area on 1394 is less > > mature and established. However, I would expect most folks using > > 1394-based audio devices are working on the professional level and > > therefore using Jack. One could easily write a daemon that uses > > libiec61883 or libraw1394 and supplies a jack connection. > > Jack is neat, but it has a chicken-egg problem. Currently, it does not > work out of the box on all distros. If you are not a _motivated_ pro, > you may find it unusable. As long as this is the case, the distros may > choose to not include jack setup in their baselining tests. Hence, it > remains tricky, adoption is slow and time passes. Jack becomes its own > enemy if it's a prerequisite for too many things. > |
Thanks for helping keep SourceForge clean.
X