GNOME Bugzilla – Bug 517203
[dshowvideosrc] creates wrong caps on the source pad (width and height range)
Last modified: 2011-11-02 06:44:14 UTC
In the actual source code of gstdshwvideosrc.h and .c, it is not possible to use other video size than the default (one default for each video format rgb ,yuv..., often 320*240) This problem is the same as described there: http://bugzilla.gnome.org/show_bug.cgi?id=506682
So I propose to define 3 more properties: force_size (is yes, filter will use given size) width (given frame width) height (given frame height) So then gst-inspect-0.10 return : force-size : Use forced size flags: readable, writable Boolean. Default: false Current: false width : Forced frame width flags: readable, writable Integer. Range: 80 - 1920 Default: 720 Current: 0 height : Forced frame height flags: readable, writable Integer. Range: 60 - 1080 Default: 576 Current: 0 And the command line is like this : gst-launch-0.10 dshowvideosrc force-size=1 width = 720 height = 576 ! ffmpegcolorspace ! autovideosink or gst-launch-0.10 dshowvideosrc force-size=1 width = 720 height = 576 ! video/x-raw-yuv, format=(fourcc)UYVY ! ffmpegcolorspace ! autovideosink if I want to be sure to use UYVY for example. It is possbile to use the filter normally : gst-launch-0.10 dshowvideosrc ! ffmpegcolorspace ! autovideosink or gst-launch-0.10 dshowvideosrc ! video/x-raw-yuv, format=(fourcc)UYVY, width=320, height=240 ! ffmpegcolorspace ! autovideosink or gst-launch-0.10 dshowvideosrc ! video/x-raw-rgb ! ffmpegcolorspace ! autovideosink
Created attachment 105488 [details] [review] suggest fix Implementation of the suggested 3 more properties. Now it is possible to use other video sizes than the default for each video format, for example if you want use 720*576 or 1920*1080 .. and if the default is 320*240 ...)
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 Please check those pipelines work without your patch, if not that's what needs to be fixed. 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, ...))
Created attachment 105489 [details] modified gstdshowvideosrc.c first attachement is a zip now it is a .c
Created attachment 105491 [details] modified gstdshowvideosrc.h and the .h
(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
replace the sentence : "And that why the actual source code of gstdshwovideosrc does not list only the DEFAULT video size for each format." by this one : -> "And that why the actual source code of gstdshwovideosrc lists only the DEFAULT video size for each format."
Ok, hum..., I understand just now your reply. yes I am sure 10000% your suggested commadlines are not working. (Only work for the default size) So for my video capture device the most commonly used sizes are : 80*60, 320*240, 640*480, 720*576. The default is 320*240. So gst-launch-0.10 dshowvideosrc ! ffmpegcolorspace ! directdrawsink and gst-launch-0.10 dshowvideosrc ! video/x-raw-rgb,width=320,height=240 ! ffmpegcolorspace ! directdrawsink works very fine. (congratulation to Sebastien Moutte) But those are not working : gst-launch-0.10 dshowvideosrc ! video/x-raw-rgb,width=720,height=576! ffmpegcolorspace ! directdrawsink or any video format or any video sizes (diffrent than the default) Why ? I explain it in my previous reply. (gstdshwovideosrc list only the default size (320*240) and then 720*576 is not in the gstreamer capabilities listed so the pipiline is stopped) I will try to fix it using the normal behaviour.
Created attachment 105912 [details] the .h gstdshowvideosrc.h fix (using normal behaviour)
Created attachment 105913 [details] the .c gstdshowvideosrc.c fix (using normal behaviour)
Now : gst-launch-0.10 dshowvideosrc ! ffmpegcolorspace ! directdrawsink or gst-launch-0.10 dshowvideosrc ! video/x-raw-rgb,width=320,height=240 ! ffmpegcolorspace ! directdrawsink or gst-launch-0.10 dshowvideosrc ! video/x-raw-rgb,width=720,height=576! ffmpegcolorspace ! directdrawsink ... works fine. Now any video sizes, different than the default but supported by the device, works.
ok, I have done more stuff about default video size negociation using : "gstbasesrc_class->fixate = GST_DEBUG_FUNCPTR (gst_dshowvideosrc_src_fixate);" when no video size is asked: example : gst-launch-0.10 dshowvideosrc ! ffmpegcolorspace ! directdrawsink or gst-launch-0.10 dshowvideosrc ! video/x-raw-yuv, format=(fourcc)UYVY ! ffmpegcolorspace ! directdrawsink I am waitting answers from my email to gst devel mailing list to post the new files gstdshowvideosrc.c and .h : " Hi, I would like to know if an existing GST_TYPE_... can do the following thing : [start, end, step] I mean, for example with GST_TYPE_INT_RANGE, [10, 100] all value bettween 10 and 100 are accepted. But I need something like GST_TYPE_INT_RANGE_STEP, [10, 100, 5], and only value 10, 15, 20, 25, 30, ....., 90, 95, 100 are accepted. I need it in dshowvideosrc, because video size have a step. For EXAMPLE, accepted video width are bettween 80 and 768 with a step of 4, and accepted video height are bettween 60 and 576 with a step of 2. I am sure it is the same thing for v4l2src. "
Created attachment 105944 [details] updated .c manage default video size using "fixate"
Created attachment 106124 [details] candidate .c This is the candidate .c that I want someone validate it
Created attachment 106125 [details] candidate .h This is the candidate .h, if someone could validate it
Now with the two candidate attachements it is also possible to change the framerate: example : gst-launch-0.10 dshowvideosrc ! video/x-raw-yuv, framerate=(fraction)2/1 ! ffmpegcolorspace ! directdrawsink
I am waitting someone could validate it and update cvs Sincerely, Julien
I have change email: julien.isorce@gmail.com
> I am waitting someone could validate it and update cvs Please post patches/diffs to the existing code, not whole new files.
Created attachment 109156 [details] [review] the .h patch
Created attachment 109157 [details] [review] the .c path
Hi Can someone commit the patch please. It works fine for several months ... Thx
Created attachment 114008 [details] [review] patch for dshowvideosrc and dshowaudiosrc I have bring together the 2 previous patch into one patch file. I fixed "spec->segtotal" calculation in dshoaudiosrc::prepare (was set to 1 everytime which made this element not working)
Created attachment 126508 [details] [review] patch for dshowvideosrc and dshowaudiosrc Some updates: - can use different video sizes, format and framerates than the default one. - The video capture filter must be added to the graph before to list the pins (if not, it fails on some devices) - For some video devices, the IAMStreamConfig interface on the pins is not implemented and so the solution is to enemurate the mediatypes on the pins. - can set latency-time for dshowaudiosrc (which was equals to buffer-time equals to 500 000 ...) - fix audio segsize and segtotal computation. - implements GstMixer interface and so now you can select Line-in, S/PDIF, microphone and all other audio inputs that your device has. For some guys the original dshowsrcwrapper plugin is in bad design (the one in gst-plugins-bad CVS repository). Even if I do not care about having my changes on the official repository, I would share experience on this plugin. Note that we are using it a lot and it has proven its stability. If the guys who know a better design for this plugin, they have to take my changes into account. I mean, they can rewrite it but keep all capabilities that my patch offers. Sincerely Julien
Julien, is this patch still necessary with latest GIT? If so, could you update it to apply cleanly? There's no gst-libs/dshow anymore it seems :/
For now I am doing some refactoring in latest git. When it will be done I will put manually the improvement that come with this patch, in latest git. Then I will just close this bug.
Hi Julien, What is the current state of the refactoring? Can I help you somehow?
Hi, About 50%. I have to commit audiomixer interface of dshowaudiosrc. You can help checking if there is no regression in the current state. I think I would have more time this summer to finish it
I found this one -> https://bugzilla.gnome.org/show_bug.cgi?id=613708 Can you commit it?
Any progress on this? Is the change still needed?
Julien, do you have any news reg. this issue?
Closing this bug report as no further information has been provided.