1167647 - cookpad.com videos fail to play in Fennec (give "file is corrupt" message)

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Audio/Video, defect)

Description

[Mike Taylor [:miketaylr]]

Originally reported as https://github.com/webcompat/web-bugs/issues/1050. 

These mp4 videos work in Desktop Firefox, B2G and Chrome Mobile, but Fennec doesn't like them.

Media codec logcat details at: https://github.com/webcompat/web-bugs/issues/1050#issuecomment-103923037

One of the cookpad engineers gave the following info about their encoding setup:

"""
Our video is encoding by [Amazon Elastic Transcoder](http://aws.amazon.com/elastictranscoder).

MP4 file detail is...

Type | Codec
---  | ---
Video | H.264
Audio | AAC

You can find other videos in http://cookpad.com/videos

ex.

- http://cookpad.com/videos/933
- https://video.cpcdn.com/cookpad/recipe_video/666/80d40c9c683cb6706db968f2ec33d181/low.mp4
- http://cookpad.com/videos/836
- https://video.cpcdn.com/cookpad/recipe_video/580/1c2304f3170bdd43ef5897cf3c8f328c/low.mp4
"""

Comment 1

[Eugen Sawin [:esawin]]

It's reproducing on Nexus 5 (Android L) and Nexus 7 (KitKat). Nexus S on Android 2.3 doesn't show the video image at all.

Comment 2

[Hallvord R. M. Steen [:hallvors]]

I browsed several videos when testing this and saw the same problem everywhere - very consistent at least. If it's some odd feature Amazon's transcoder uses and we don't support or handle well we should give this high pri IMHO.

Comment 3

[Mike Taylor [:miketaylr]]

Attachment: elastic-video-settings.png

Screenshot of the settings used by Cookpad.

Comment 4

[Mike Taylor [:miketaylr]]

Attachment: fromWebMbitrate80.mp4

OK, vladikoff helped reduce this further. Transcoding a video using Elastic Transcoder using cookpad's video settings is fine, using default AAC audio. But looking at the file itself, it seems they're actually using HE-AAC as their audio codec.

Vlad used that, and indeed we get the "Video can't be played because the file is corrupt" message. Firefox Desktop and Chrome Mobile continue to play the file just fine.

Source video: http://techslides.com/demos/sample-videos/small.webm
Uploading the transcoded result.

Comment 5

[Mike Taylor [:miketaylr]]

JeanYves, can you take a peek at the fromWebMbitrate80.mp4 video?

Comment 6

[Jean-Yves Avenard [:jya]]

I see nothing special with that video. I don't have the device to reproduce either. It could be a dupe of bug 1166760

Comment 7

[Vlad Filippov (:vladikoff)]

Attachment: Screenshot_2015-06-05-11-16-21.png

Comment 8

[Vlad Filippov (:vladikoff)]

Attachment: Screenshot_2015-06-05-11-17-07.png

Comment 9

[Mike Taylor [:miketaylr]]

Thanks for looking Jean-Yves.

> I don't have the device to reproduce either

It happens on all my Android devices, as well as the other people in this bug who have tried. So setting back to NEW.

Comment 10

[Vlad Filippov (:vladikoff)]

Not a dupe of bug 1166760 (`Videos on Facebook play back with extremely slow audio`).

In this case the video does not load at all, sometimes says "Unsupported"
Screenshot via a simulator: http://v14d.com/i/5571bf94a4651.png

Easy video URL to test: http://v14d.com/vid/fromWebMbitrate80.mp4

You don't need a real device to confirm this bug. Use a simulator.

To reproduce WITHOUT a device:

- Install an Android simulator (I used https://www.genymotion.com/#!/)

- Create a device profile ( I used Nexus 4 - Android 4.3 API 18)

- Open the simulator, enabled third party sources to install external APKs, open browser, download Fennec Nightly ( I used the Fennec X86 build)

- Install Fennec, navigate Fennec to http://v14d.com/vid/fromWebMbitrate80.mp4

- See unsupported screen.

Comment 11

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

James - any clues?

Comment 12

[Blake Wu [:bwu][:blakewu]]

attachment 8614783 [details] cannot be played on gonk PDM either. I am going to check it.

Comment 13

[Blake Wu [:bwu][:blakewu]]

If I disable ADTS[1][2] which is default true, that file can be played well on B2G gonk PDM. Not sure it is the same cause in Fennec. 

[1]https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/gonk/GonkAudioDecoderManager.cpp#41
[2]https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/gonk/GonkAudioDecoderManager.cpp#89

Comment 14

[Jean-Yves Avenard [:jya]]

This file has a HE-AACv2 audio track, with out of band SBR AAC (profile 5). Those can't be encoded in a ADTS container (which only support a profile <= 4)

Comment 15

[James Willcox (:snorp) ([e-mail]) (he/him)]

Sounds like the file is busted. Can we work around that in the parser?

Comment 16

[Blake Wu [:bwu][:blakewu]]

IMO, it seems not a parser problem. It is more likely we don't configure codec in a proper way.

Comment 17

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Blake Wu [:bwu][:blakewu] from comment #16)
> IMO, it seems not a parser problem. It is more likely we don't configure
> codec in a proper way.

We configure the decoder based on data from the parser, though, so a workaround there would fix it I believe.

Comment 18

[Jean-Yves Avenard [:jya]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #17)
> (In reply to Blake Wu [:bwu][:blakewu] from comment #16)
> > IMO, it seems not a parser problem. It is more likely we don't configure
> > codec in a proper way.
> 
> We configure the decoder based on data from the parser, though, so a
> workaround there would fix it I believe.

And what could be busted in that file?
What work around could be done in the parser when the gonk decoder encapsulate the data in an adts stream a stream that can't be?

The decoder receives all the data it needs to take the right action. It receives an AudioInfo with a profile value of 0, and an extended_profile value of 5.
The decoder needs to handle raw AAC. If it can't well, it can't play that particular file. But there's nothing you can do in the MP4 Demuxer that can get around this.

Comment 19

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

James - is it possible convince the decoder to not use ADTS? We had to do that for all the other decoders.

Comment 20

[Blake Wu [:bwu][:blakewu]]

Basically, the decoder/codec Fennec use should be the same to B2G. I have tried to not use ADTS in comment 13 on B2G, so Fennec should be able to decode raw AAC I believe.

Comment 21

[Jean-Yves Avenard [:jya]]

(In reply to Blake Wu [:bwu][:blakewu] from comment #20)
> Basically, the decoder/codec Fennec use should be the same to B2G. I have
> tried to not use ADTS in comment 13 on B2G, so Fennec should be able to
> decode raw AAC I believe.

to reduce the likelihood of regression, you could still use ADTS if AudioInfo::mExtendedProfile is <= 4 (or if AudioInfo::mProfile != 0), and pass raw aac for others.

The vast majority of files I've seend seems to use inband SBR and advertise themselves as AAC-LC (AudioInfo::mExtendedProfile = 2)

Comment 22

[Mike Taylor [:miketaylr]]

Unsure if Bug 1174784 is caused by the same issue, but it's using AAC (see comment 3) and works on Desktop and not Fennec.

Comment 23

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Jean-Yves Avenard [:jya] from comment #21)
> to reduce the likelihood of regression, you could still use ADTS if
> AudioInfo::mExtendedProfile is <= 4 (or if AudioInfo::mProfile != 0), and
> pass raw aac for others.

We should just stop using ADTS on Fennec like we've done on every other platform.

Comment 24

[Blake Wu [:bwu][:blakewu]]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #23)
> (In reply to Jean-Yves Avenard [:jya] from comment #21)
> > to reduce the likelihood of regression, you could still use ADTS if
> > AudioInfo::mExtendedProfile is <= 4 (or if AudioInfo::mProfile != 0), and
> > pass raw aac for others.
> 
> We should just stop using ADTS on Fennec like we've done on every other
> platform.
For omx decoders used by Fennec and Gonk, it needs to know if the data is in ADTS format or not. So it would be better to expose this information via AudioInfo.

Comment 25

[James Willcox (:snorp) ([e-mail]) (he/him)]

We're already not using ADTS in the Android PDM. https://hg.mozilla.org/mozilla-central/rev/e30507b1a89fe26d8e0631e5375fb9e7462f8764

Comment 26

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Pass all of the content specific data to decoder, not just two bytes

Comment 27

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1536177b3d46

Comment 28

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/1536177b3d46

Comment 29

[Mike Taylor [:miketaylr]]

Karl, can you test on your device please?

Comment 30

[Karl Dubost💡 :karlcow]

Tested on 42.0a1 (2015-07-01) the following URIs

* Working https://video.cpcdn.com/cookpad/recipe_video/666/80d40c9c683cb6706db968f2ec33d181/low.mp4
* Working http://cookpad.com/videos/933

Comment 31

[Mike Taylor [:miketaylr]]

Awesome, thanks.