GNOME Bugzilla – Bug 622696
ffmpegcolorspace: Speed up caps nego by using simpler caps
Last modified: 2010-06-25 15:08:23 UTC
Use a pre-written and more concise pad template caps instead of the programatically-generated one to: * speed up plugin registration * speed up caps negotiation (the caps intersection becomes simpler)
Created attachment 164591 [details] [review] ffmpegcolorspace: Use a more concise pad template Speeds up caps nego 2 fold
One could also get rid of all the now-unused code in gstffmpegcodecmap.c to slim down the plugin.
What exactly makes the difference here? Only that all YUV formats are in a single structure? Everything else should be more or less the same...
I don't know how much it matters, but this patch also changes the order of the structures within the announced caps a littile, e.g. before we had UYVY, YVYU, IYU1 (mmh?), v308, and AYUV at the very end of the caps, after the RGB caps, whereas now that's all in the very first structure.
It shouldn't matter if it was just used for the template. But as long as ffmpegcolorspace uses the template's order in its getcaps function, it's possible to (accidentally?) abuse this to get weird caps. See bug 619844 for an example. i don't think it's a real-world problem though.
(In reply to comment #1) > Created an attachment (id=164591) [details] [review] > ffmpegcolorspace: Use a more concise pad template > > Speeds up caps nego 2 fold > Would it work to call gst_caps_simplify() on the generated caps instead of adding a hardcoded version? That should give you roughly the same caps I guess?
It gives reordered caps though. But I don't think that the order is important for ffmpegcolorspace... the order is absolutely arbitrary anyway. But it might be a good idea to now order it correctly, with the formats with the most information first, etc. (AYUV, ARGB variants, v380/Y444/xRGB/RGB, ....)
Going to commit it then in a few mins.
Attachment 164591 [details] pushed as 3a00a97 - ffmpegcolorspace: Use a more concise pad template