[gstreamer-bugs] [Bug 517203] [dshowvideosrc] creates wrong caps on the source pad (width and height range)

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=517203

  GStreamer | gst-plugins-bad | Ver: HEAD CVS

Julien Isorce changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |julien.isorce at etu.enseeiht.f
                   |                            |r
             Status|NEEDINFO                    |UNCONFIRMED




------- Comment #6 from Julien Isorce  2008-02-24 22:11 UTC -------
(In reply to comment #3)
> This is not how it should be done.
> 
> You should be able to select the width/height by using filtered caps. For
> example :
> 
> dshowvideosrc ! video/x-raw-yuv,width=720,height=576 ! autovideosink
> OR:
> dshowvideosrc ! video/x-raw-yuv,width=720,height=576,format=(fourcc)UYVY !
> ffmpegcolorspace ! autovideosink
> 

Hi, I think you do not know the pb. I'll try to explaint it.
When the user types this : 
dshowvideosrc ! video/x-raw-yuv,width=720,height=576 ! autovideosink,  
first the dshowvideosrc lists all supported formats (using directshow api) and
constructs corresponding gstreamer capabilities. Then the program check if
"video/x-raw-yuv,width=720,height=576" is in the listed capabilities.
If yes, pipelines continues, if not, all is stopped.

Ok, now the problem is that the listed capabilities (using directshow code) are
not exaustive. I mean, even if the video capture device is able to deliver many
video sizes (... 80*60 ... 180*120 .... 320*240 ... 720*576 ...), ONLY the
default size for each format (yuv, rgb ...) is listed.
Why ? Because there is too much possibilities. So directshow API lists only the
defaults.

I mean with directshow API (and I am sure it is the same thing with v4l2), you
have for each format (yuv, rgb, ...) , the MinOutputWidth (example: 80), the
MinOutputheight (ex:60), the MaxOutputWidth (ex:768), the MaxOutputheight
(ex:576), the default width (ex:320), the default height (ex:240), and
IMPORTANT, the OutputGranularityX (horizontal step size) (ex: 4), and the
OutputGranularityY (vertical step size) (ex:2).

Then how many are the possible size ? (768-80)/4 * (576-60)/2 = 44376 formy
video capture device.

So I understand that is crazy to create a gstreamer caps as longer as 44376
possibilities. And that why the actual source code of gstdshwovideosrc does not
list only the DEFAULT video size for each format.

But how can we do ? I want to use 720*576 or 640*380, but the default size is
320*240. So the program reject it.

Now I think you can understand why I suggested

3 more properties:
force_size (is yes, filter will use given size)
width (given frame width)
height (given frame height)

I know that is not the normal behaviour but, we cannot create a caps that
countains 44376 possibilities ?
Maybe the most commonly used ? (320*240, 640*480, 720*576, 1920*1080 ... when
stop ?)


> dshowvideosrc should be fixed in order for those pipelines to work (which is
> the same behaviour as used with other video sources (videotestsrc, v4lsrc,
> v4l2src, ...))
> 

What do you suggest to have the same behaviour ? I am ready to implement it.

Sincerely,

Julien


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=517203.