On Thu, Oct 14, 2004 at 05:25:49PM -0700, john Galloway wrote:
>
> On Oct 13, 2004, at 6:09 PM, Roman Shaposhnick wrote:
> > So, since I don't have an access to any "IIDC-based" cameras
> > (donation anyone :-) ?) I need someone motivated enough to
> > test this for me. If there's somebody interested -- let me
> > know. The idea is to be able to do:
> >
> > $ ./ffmpeg -video1394 test.mpeg
> >
> I've been doing some tests using dc1394_vloopback and the v4l
> vloopback.ko module. Comparing my Dell 2.4Ghz P4 with my
> mini-itx 1Ghz VIA C3, cpu percentages are
> DELL miniitx
> dc1394_vloopback 22 54
> ffmpeg 7 27
> ffplay 4 17
>
> So while ffmpeg and ffplay consume 4x the cpu on the tiny box
> and dc1394_vloopback is only 2.5x, I need both of the ff's, and
> they are still low compared to 1394 4vl loopback which maybe
> can be eliminated.
>
> This is running entirely locally with the camera in 320x240 mode
> dc1394_vloopback --vloopback=/dev/video0 --width=320 --height=240
> ffmpeg -an -s 320x240 -vd /dev/video1 -intra -vcodec h263p -f h263 |
> ffplay -
>
> All the binaries were built on the Dell so its also possible that gcc
> could produce better code for the C3 if the C3 was the target, I don't
> know that one way or the other.
>
> I'm using h263 as it just seemed to produce the best results with
> lower overhead than mpeg (when transmitting this over a wireless link
> which is the goal). Not sure -intra effects h263 either, but was left
> from mpeg testing where it definitely helps with real time.
>
> The camera produces (depending on settings) YUV422 or YUV411
> (with 640x480 or 320x240 and fps options), which dc1394_vloopback
> translates into YUV420p as that is what is negotiated with
> v4l, and I think it does this first by translating into RGB.
> So if ffmpeg can directly understand YUV422 and/or YUV411 (which
> seems likely) then a lot of crunching might be eliminated with
> lower memory bandwidth used (also a big factor).
>
> Given the example of dc1394_vloopback it "should" not be tooooo
> hard (but having not looked into the innards of ffmpeg...).
> Anyway I'll be looking into it over the next few days.
Right. That's exactly how -dv1394 works in ffmpeg -- zerro copying.
And it sure frees quite a few CPU cycles. Plus there's no '|' overhead
too.
Let's continue to work offline on hacking up a dc1394 capturing module.
Thanks,
Roman.
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user
Received on Sun Oct 17 03:49:17 2004
This archive was generated by hypermail 2.1.8 : Mon 02 May 2005 - 09:16:50 CEST