RESOLVED FIXED Bug 180370
[GStreamer] <img> tag needs to support video formats
https://bugs.webkit.org/show_bug.cgi?id=180370
Summary [GStreamer] <img> tag needs to support video formats
Michael Catanzaro
Reported 2017-12-04 12:48:44 PST
I'm adding a skip expectation for layout test http/tests/images/image-supports-video.html, which ensures that video formats can be used in an image tag. I think the expected behavior is for the first frame of the image to be displayed. Unfortunately websites are actually doing this. I had previously skipped fast/images/animated-image-mp4.html for the same reason. I'll associate that expectation with this bug as well.
Attachments
Patch (32.77 KB, patch)
2020-05-17 05:27 PDT, Philippe Normand
no flags
Patch (32.84 KB, patch)
2020-05-17 09:58 PDT, Philippe Normand
no flags
Patch (32.91 KB, patch)
2020-05-20 02:10 PDT, Philippe Normand
no flags
Miguel Gomez
Comment 1 2018-05-31 03:14:59 PDT
Adding fast/images/animated-image-mp4-crash.html here as well, which is timing out.
Philippe Normand
Comment 2 2020-05-09 10:51:50 PDT
I... kinda... started having a look... :D
Philippe Normand
Comment 3 2020-05-17 05:27:34 PDT
Philippe Normand
Comment 4 2020-05-17 09:58:29 PDT
Xabier Rodríguez Calvar
Comment 5 2020-05-18 07:12:48 PDT
Comment on attachment 399594 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=399594&action=review > Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.cpp:65 > + m_image = ImageGStreamer::createImage(gst_sample_ref(platformSample().sample.gstSample)); From what I am seeing, I think you're leaking the sample here. It is true that the ImageGStreamer::createImage adopts, but it adopts the ImageGStreamer object, not the sample (at least in the Cairo Impl). This said, I think this API is confusing and it could be well using either a const GstSample* or maybe a GRefPtr<GstSample>&&. In this case the pointer would be destroyed after the call because nobody will use it. > Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.cpp:351 > +void ImageDecoderGStreamer::pushEncodedData(SharedBuffer& buffer) Maybe you can switch to const SharedBuffer& all the way in the onion > Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.h:102 > + ImageDecoderGStreamer* m_decoder; Would it make sense to make this refcounted or weak?
Philippe Normand
Comment 6 2020-05-20 02:10:20 PDT
Philippe Normand
Comment 7 2020-05-20 02:11:50 PDT
Comment on attachment 399594 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=399594&action=review >> Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.cpp:65 >> + m_image = ImageGStreamer::createImage(gst_sample_ref(platformSample().sample.gstSample)); > > From what I am seeing, I think you're leaking the sample here. It is true that the ImageGStreamer::createImage adopts, but it adopts the ImageGStreamer object, not the sample (at least in the Cairo Impl). > > This said, I think this API is confusing and it could be well using either a const GstSample* or maybe a GRefPtr<GstSample>&&. In this case the pointer would be destroyed after the call because nobody will use it. Can't be const GstSample* because the gst_sample_* APIs expect a non-const pointer. I don't really see the point of using a GRefPtr either because the sample is already owned by the MediaSampleGStreamer :)
Xabier Rodríguez Calvar
Comment 8 2020-05-20 07:28:21 PDT
Comment on attachment 399822 [details] Patch I still see lots of SharedBuffer& not turned into const, please do that.
Philippe Normand
Comment 9 2020-05-20 07:34:42 PDT
Those are part of the ImageDecoder API. Why should I change all the implementations for the sake of another one?
Xabier Rodríguez Calvar
Comment 10 2020-05-20 08:15:16 PDT
(In reply to Philippe Normand from comment #9) > Those are part of the ImageDecoder API. Why should I change all the > implementations for the sake of another one? ok, you might go ahead.
EWS
Comment 11 2020-05-20 08:52:40 PDT
Committed r261922: <https://trac.webkit.org/changeset/261922> All reviewed patches have been landed. Closing bug and clearing flags on attachment 399822 [details].
Philippe Normand
Comment 12 2020-06-14 04:33:39 PDT
Comment on attachment 399594 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=399594&action=review >> Source/WebCore/platform/graphics/gstreamer/ImageDecoderGStreamer.h:102 >> + ImageDecoderGStreamer* m_decoder; > > Would it make sense to make this refcounted or weak? Making it weak wasn't a good idea: https://bugs.webkit.org/show_bug.cgi?id=213178
Note You need to log in before you can comment on or make changes to this bug.