[FFmpeg-devel] [PATCH] new version of libdc1394 - resubmitting after review

Alessandro Sappia a.sappia
Wed Jan 9 07:09:35 CET 2008


HI all,
Attached a patch which reformat code to be as suggested
by roman.

how to fix  a fixme should be addressed with you:
camera connected by libdc1394 are selected by comparing
the guid (and eventually a unit) with a given one.

guid is a unit64_t
unit is an int
one should eventually add a command line option for show
connected guids and how many unit that guid has (to select
proper camera)
may I add such command line options ?

Useful thing should be shutter time and some controls (white balance,
gain, transmission speed, etc...)
Should we expose them to ffmpeg users ?

Roman, did you check my patch for fps and fmt default value handling ?
I ask this because it happened to me that

$ ./ffplay -f libdc1394 /dev/video1394/1
FFplay version git-06d4c94, Copyright (c) 2003-2008 Fabrice Bellard, et al.
  configuration: --enable-decoders --enable-encoders --enable-muxers
--enable-demuxers --enable-parsers --enable-protocols --enable-bsfs
--enable-indevs --enable-outdevs --enable-libdc1394 --disable-strip
  libavutil version: 49.6.0
  libavcodec version: 51.49.0
  libavformat version: 52.3.0
  built on Jan  9 2008 05:42:10, gcc: 4.1.3 20070929 (prerelease)
(Ubuntu 4.1.2-16ubuntu2)
[libdc1394 @ 0x84181b4]Can't find matching camera format for uyvy422,
320x240 at 25000:1000fps
/dev/video1394/1: Error while opening file
$

This happens because DCcamera in Format0 can't acquire at any speed,
but there are some fixed. It seems that ffplay asks for 25 fps while 25 fps
is not a standard acquiring fps for dc1394.
Related to that, the DC1394 standard for format0 define fps up to 240fps
per second, may these speed useful in ffmpeg ?

I was thinking about using format7 acquire mode, but while it gives us
the ability of asking the cam for a precise fps, this has the overload of
having to do the debayer in software. what do you think about it ?

Alessandro

Roman Shaposhnik ha scritto:
>
>    Ok, I do have one last question here, though. It is 
> minor nit, but if anybody besides me cares we might as well
> take care of it. So, here's the deal: what you currently have
> in your patch is fine and readable, but personally I really
> dislike #if[def] sections which are longer than just a couple
> of lines. On top of that, one would hope that support for 
> libdc1394 v. 1 is going to be dropped sometime in the future.
> Hence, I'd rather have this (in skeletal form):
>
>    #if ENABLE_LIBDC1394_2
>    #include <dc1394/dc1394.h>
>    #elif ENABLE_LIBDC1394_1
>    #include <libraw1394/raw1394.h>
>    #include <libdc1394/dc1394_control.h>
>    #define DC1394_VIDEO_MODE_320x240_YUV422 MODE_320x240_YUV42
>    ....
>    #define DC1394_FRAME_RATE_1_875 FRAME_RATE_1_875
>    ....
>    #endif /* ENABLE_LIBDC1394_1 */
>    
>    static inline int dc_1394_read_header_common(...)
>
>    static int dc1394_v1_read_header(...)
>    {
>        dc_1394_read_header_common();
>        ....
>    }
>
>    static int dc1394_v2_read_header(...)
>    {
>        dc_1394_read_header_common();
>        ....
>    }
>
>    .....
>   
>    #if ENABLE_LIBDC1394_1
>    AVInputFormat libdc1394_demuxer = {
>     .name           = "libdc1394",
>     .long_name      = "dc1394 v1 A/V grab",
>     .priv_data_size = sizeof(struct dc1394_data),
>     .read_header    = dc1394_v1_read_header,
>     .read_packet    = dc1394_v1_read_packet,
>     .read_close     = dc1394_v1_close,
>     .flags          = AVFMT_NOFILE
>    };
>    #elif ENABLE_LIBDC1394_2
>    AVInputFormat libdc1394_demuxer = {
>     .name           = "libdc1394",
>     .long_name      = "dc1394 v2 A/V grab",
>     .priv_data_size = sizeof(struct dc1394_data),
>     .read_header    = dc1394_v2_read_header,
>     .read_packet    = dc1394_v2_read_packet,
>     .read_close     = dc1394_v2_close,
>     .flags          = AVFMT_NOFILE
>    }; 
>    #endif
>
>
>   
>   Well, beyond the question above and somebody for whom English is a 
> mother tongue looking over the output messages, I believe this patch
> is now ok to be included. Good work!
>
> Thanks,
> Roman.
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libdc1394-new.patch
Type: text/x-patch
Size: 10985 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080109/cf935280/attachment.bin>



More information about the ffmpeg-devel mailing list