Marco, > 2. error handling ui is a good choice. > Marco: This is a good following item too. May I know the bug number about > this?
We don't have a bug filed yet cause currently we think the unplayable audio files shouldn't be listed in music app, and the error handling ui needs new localized strings so we probably cannot have it in v1.0.1, v1.1 is possible I think. But we still need UX to comment on this. > step a. To find signatures which is mapped to some media file spec by music > app itself. > step b. If a is failed then using audio.canPlayType() to judge. > step c. If b is still failed then try set up audio tag and wait "canplay" > event. (this will really create a decoder) > What I want to clarify here is focused on step a & b not step c. One role > in audio.canPlayType() is nsMediaSniffer and > it did the same thing with what Music app did on step a. Also > audio.canPlayType() doesn't really create a decoder and try to decode it. It's my misunderstanding on "audio.canPlayType()" and "canplay" event, sorry about that. I was talking about the canplay event. Actually works in step a is to parse the metadata of the various formats, if we can't recognize the metadata, then we will try to test it with step b and step c, because the metadata parser doesn't cover all the supported formats and the files that with unparseable metadata might be still playable. So if audio.canPlayType() does the same work with step a and reports the trusty supported formats, then it would be nice to move step b before step a since we don't have to duplicate some works, and the metadata parser can concentrate on the parsing works. But what's the correct way to judge the the return string of audio.canPlayType()? I have looked on https://developer.mozilla.org/en-US/docs/DOM/HTMLMediaElement and the canPlayType section says there will be three kinds of the strings: 1. probably 2. maybe 3. empty string >From these three words I can only tell that "empty string" is unplayable for >sure, but for "probably" and "maybe", it might still be unplayable so we will get errors when we try to play files with an <audio> tag? or we still need step c to confirm? Thanks, Dominic ----- Original Message ----- From: "Marco Chen" <[email protected]> To: "Dominic Kuo" <[email protected]> Cc: "Paul Adenot" <[email protected]>, "dev-b2g" <[email protected]> Sent: Monday, May 6, 2013 12:12:39 PM Subject: Re: [b2g] [Media] The media filter between Gaia - music app and Gecko - nsMediaSniffer & nsExternalHelperAppService Hi Dominic, Thanks for your reply and I split your reply into separate items then continue to discuss them. 1. About syncing between DeviceStorage.properties, nsMediaSniffer and nsExternalHelperAppService. Marco: Good suggestion and we already tried to discuss it on Bug 859711. Welcome to join there. 2. error handling ui is a good choice. Marco: This is a good following item too. May I know the bug number about this? 3. About filtering whether audio file can be playable or not? Marco: I tried to trace the filtering flow of Music app and it will be step a. To find signatures which is mapped to some media file spec by music app itself. step b. If a is failed then using audio.canPlayType() to judge. step c. If b is still failed then try set up audio tag and wait "canplay" event. (this will really create a decoder) What I want to clarify here is focused on step a & b not step c. One role in audio.canPlayType() is nsMediaSniffer and it did the same thing with what Music app did on step a. Also audio.canPlayType() doesn't really create a decoder and try to decode it. So if there is no performance issue between step a & b 3-Q:May I know is there any other reason we need to duplicate step b as step a and do it again by Music app? Thanks, Sincerely yours. ----- Original Message ----- From: "Dominic Kuo" <[email protected]> To: "Marco Chen" <[email protected]> Cc: "Paul Adenot" <[email protected]>, "dev-b2g" <[email protected]> Sent: Friday, May 3, 2013 8:28:46 PM Subject: Re: [b2g] [Media] The media filter between Gaia - music app and Gecko - nsMediaSniffer & nsExternalHelperAppService Hi Marco, I think before synchronizing the supported formats in Gaia and Gecko, maybe Gecko can first sync with DeviceStorage.properties, nsMediaSniffer and nsExternalHelperAppService. Music app uses MediaDB which integrates the DeviceStorage API and the IndexedDB API, and DeviceStorage will return files to be parsed with metadata parser in Music app. Because DeviceStorage returns formats base on DeviceStorage.properties, if we already know some formats are not supported in Gecko, we shouldn't pass them to the metadata parser, also MediaDB will not record them and not to mention they will not be listed in Music app. And for the known supported formats, nsExternalHelperAppService should not block them, right? If we filter out the unsupported formats with the first step, it's still possible that some supported formats/containers with unsupported encodings will be recorded in MediaDB, and when Music app tries to play them, we might still encounter the error of "Warning: HTTP "Content-Type" of "audio/xxx" is not supported." But does using only the logic of audio.canPlayType() to judge files can playable or not solve this problem? I guess probably, but the metadata parsing time will take even longer because we have to try to decode every files before we parse the metadata, I am not sure how long it takes to decode one audio file, but certainly it saves time if we parse files without decoding them first. I am thinking that maybe error handling ui is a good choice if we cannot guarantee the so-called "audio" files listed in Music app can be playable or not. Cheers, Dominic ----- Original Message ----- From: "Marco Chen" <[email protected]> To: "dev-b2g" <[email protected]> Cc: "Paul Adenot" <[email protected]> Sent: Friday, May 3, 2013 6:46:00 PM Subject: [b2g] [Media] The media filter between Gaia - music app and Gecko - nsMediaSniffer & nsExternalHelperAppService Hi all, Even this topic seems to be related to media (dev-media) but according it also related to Gaia and b2g I post it to dev-b2g first. Issue: Currently, we met a bug about some files which can be listed by Music app but can't play by Gecko. The main reason is that there are two media sniffer mechanism performed by Gaia and Gecko separately. Detail: Gaia: Music app used media sniffer mechanism from metadata.js which will try to parse metadata by itself in first. If first step is failed then fall into Gecko's mechanism (audio.canPlayType()) Gecko:nsMediaSniffer implemented metadata parsing for some media type too. If nsMediaSniffer is failed then check into nsExternalHelperAppService's mimetype entries. So if Gaia's metadata.js is implemented with different way then Gecko's then issue mentioned by this mail will be occurred. Discussion Item: Do we really need Gaia to do filter by itself or just to use Gecko's mechanism (audio.canPlayType()) is enough? Then this way can avoid the in-consistent filter capability between Gaia & Gecko. Thanks, Sincerely yours ------------------------------------- Marco Chen System Engineer in Firefox OS Mozilla Taiwan Tel: +886-2-87861100 # 352 mail: [email protected] _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
