[FFmpeg-devel] [PATCH] Improving support for IIDC cameras (libavdevice/libdc1394.c)

[Michael Niedermayer]

On Thu, May 26, 2011 at 08:53:37PM +0200, Martin Lambers wrote:
> On 20/05/11 21:45, Michael Niedermayer wrote:
> > On Tue, May 10, 2011 at 09:20:25PM +0200, Martin Lambers wrote:
> >> Hello all,
> >>
> >> currently, the libdc1394 format only supports very few video modes:
> >> 320x240 or 640x480, and only two pixel formats. Furthermore, these modes
> >> have to be selected via AVFormatParameters, there is no autodetection.
> >>
> >> I'd like to change that so that the camera is queried for the modes it
> >> supports, and a suitable mode is selected with regard to
> >> AVFormatParameters. If no parameters are given, the best mode should be
> >> chosen automatically. Furthermore, I'd like to add support for more
> >> pixel formats.
> >>
> >> The attached patches do this in two steps:
> >>
> >> 1) Remove support for the libdc1394 v1 API. V2 has been available for
> >> ages (it even is in Debian oldstable), and V1 is not shipped with
> >> current distributions anymore (it does not work with current kernels).
> >>
> >> 2) Replace the mode selection code in dc1394.c (but leave the rest of
> >> the code untouched). Use the libdc1394 v2 API to query available video
> >> modes, remove those that we currently do not support, and sort the rest
> >> according to preference. Then pick a mode according to
> >> AVFormatParameters, or use a fallback based on the preferences list. At
> >> the same time, support all dc1394 color codings for which there is a
> >> corresponding FFmpeg pixel format.
> > 
> > This mode selection code looks quite complex.
> > why is this complexity needed?
> > 
> > I think it should be possible to have a single loop that goes over
> > all the modes then
> > * skip what we do not support
> > * assign a score to the rest depending on matching what was requested
> >   as well as bigger/better style, like score= width + A*fps
> >   + B*(width == requested_width) ...
> > * just keep track of which had the highest score and then use this
> > 
> > maybe iam missing something but sorting and removial from the list
> > dont seem needed
> 
> You are right, thanks for the suggestion. I have a attached a simplified

thanks, applied



> patch, however this conflicts with recent changes: to my surprise, there
> was a change to the libdc1394-v1 part of the code while the libdc1394-v2
> part was not changed.

its just some changes merged from libav. Ill wager a bet it was not
tested probably not even compiled, given there where seperate compile
fixes commited afterwards.

if iam wrong users will report it and we can put the v1 path back

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110527/c8b9cc6b/attachment.asc>