Bug 29532 – [GTK] media tests failing after their rework

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Gustavo Noronha (kov)]

A Chromium developer reworked the tests to allow testing using formats/codecs that are supported. GStreamer supports the formats that are used in the tests, but doesn't correctly advertise them, so we started failing.

[Gustavo Noronha (kov)]

Created attachment 39836 [details]
proposed fix

[Philippe Normand]

GStreamer doesn't report the mime-types like the ones listed in
/etc/mime.types. The typefind functions (src ! typefind) report things like
content-type/container:

audio/mpeg

or video/x-msvideo for an avi file.

More data is probably available in the caps property of the typefind element.

So I'm not sure it's a good idea to have that mapping between Gstreamer formats
and WebKit. Would need to think more about it.

[Xan Lopez]

(In reply to comment #2)
> GStreamer doesn't report the mime-types like the ones listed in
> /etc/mime.types. The typefind functions (src ! typefind) report things like
> content-type/container:
> 
> audio/mpeg
> 
> or video/x-msvideo for an avi file.
> 
> More data is probably available in the caps property of the typefind element.

Right, so gustavo's comment about gst failing to report things is not accurate.

> 
> So I'm not sure it's a good idea to have that mapping between Gstreamer formats
> and WebKit. Would need to think more about it.

Keep in mind that it's the HTML5 standard that says we should work with mime types, so this is not really up to debate (unless you convince the HTML5 guys we shouldn't use mime types). See: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html

[Gustavo Noronha (kov)]

(In reply to comment #2)
> GStreamer doesn't report the mime-types like the ones listed in
> /etc/mime.types. The typefind functions (src ! typefind) report things like
> content-type/container:
> 
> audio/mpeg

Right. But we are given the mime type as defined in HTML5 to find out if we do support it or not, so we need some kind of mapping here.

> or video/x-msvideo for an avi file.
> 
> More data is probably available in the caps property of the typefind element.

We are using data from caps to get what we do now. Any suggestions on how we could improve this to correctly say we support video/mp4, audio/mp3, and the others?

[Gustavo Noronha (kov)]

Some discussoin down at #gstreamer:

<slomo> kov: you need a MIME type <-> caps conversion and then you could check the registry
<slomo> or what everybody else said before ;)
<bilboed-pi> even then, it's not guaranteed
<__tim> we should add an FAQ entry for this somewhere ;)
<kov> __tim, I did look for that in the FAQ ;D
<bilboed-pi> i.e. MIME-TYPE : video/x-asf => neat, I have an asfdemux, all good => but you fail because you don't have the decoders
<ensonic> yes, if you don't find elements, then it won't play, but the opposite doe not have to be tru automatically
<kov> bilboed-pi, right, but I may also have the codec names
 does that help somehow?
 such as: type: video/ogg, codec: speex
 sorry, audio/ogg, speex
<bilboed-pi> you'd have to do a mapping table
 between your application's type system and gstreamer caps
<kov> bilboed-pi, sounds like a plan
<bilboed-pi> there are corner cases where it will fail though... because that codec description isn't verbose enough
<kov> I have made a quick try to see if I could get the tests working: https://bugs.webkit.org/attachment.cgi?id=39836&action=review
 I guess I'll have to play with that quite a bit more =)
<bilboed-pi> mp3 => audio/mpeg, mpegversion=1, layer=3
 wav is tricky
 it's a container format
 which, agreed, is mostly used for raw pcm... but can contain mp3 or other codecs
<kov> I guess we can handle corner cases as we find them
 if we get 80% coverage I'll be happy

[Philippe Normand]

About last part of the patch, mapping audio/mpeg to audio/mp3 mime-type, what about mp1 and mp2 ?

[Gustavo Noronha (kov)]

(In reply to comment #6)
> About last part of the patch, mapping audio/mpeg to audio/mp3 mime-type, what
> about mp1 and mp2 ?

I'll fix that =). We will need a quite big mapping. I am inclined to write it on demand like I did with those, and in the near future refactor it into a separate file, so that we can easily use the same code in other projects.

[Xan Lopez]

Comment on attachment 39836 [details]
proposed fix

Let's get this for now and improve it gradually :)

r=me

[Gustavo Noronha (kov)]

Landed as r48671, thanks!