[Webkit-unassigned] [Bug 77087] [GStreamer] 0.11 video-sink

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=77087


Sebastian Dröge <slomo at circular-chaos.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slomo at circular-chaos.org




--- Comment #6 from Sebastian Dröge <slomo at circular-chaos.org>  2012-02-07 04:03:09 PST ---
(In reply to comment #5)

> >> Source/WebCore/platform/graphics/gstreamer/VideoSinkGStreamer1.cpp:351
> >> +        gst_buffer_pool_config_add_option(config, GST_BUFFER_POOL_OPTION_VIDEO_META);
> > 
> > Do you handle the video meta in the request-repaint signal handlers? There might be any possible stride used if you add this meta instead of the old GST_ROUND_UP_4(width) strides.
> 
> Hum I don't use it in the signal handler. I guess it's best to remove this option from the pool then?

Or support and use the metadata in the signal handler. Which would be preferred because it will give you better performance. And as you use cairo, supporting random strides should be quite easy.

> >> Source/WebCore/platform/graphics/gstreamer/VideoSinkGStreamer1.cpp:356
> >> +    gst_query_add_allocation_meta(query, GST_VIDEO_META_API);
> > 
> > You might want to add support for the crop meta too here
> 
> Is it really needed?

No, but if you support it, it will give you much better performance if cropping is required somewhere (e.g. non-multiple of 16 widths/heights in h264 or Theora). I remember that adding cropping support to xvimagesink and gst-ffmpeg for this gave ~25% performance improvement for some videos. And cropping support is really easy if you use cairo for rendering anyway.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.