1073805 - Audio does not play

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Alice0775 White]

Attachment: 5.1_aac.mp4

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

Steps To Reproduce:
1. Open attached and play

Actual Results:
Audio does not play

Expected Results:
Audio Play. 
(But, sound Front-Right and Front-Center are interchanged due to another Bug 1073793)


Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b91deae84856
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140825183854
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/efe5844c9a5b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140825193622
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b91deae84856&tochange=efe5844c9a5b

Regressed by:
efe5844c9a5b	Chris Pearce — Bug 1057879 - Enable MP4Reader on Windows. r=kentuckyfriedtakahe

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

The file is 6 channel audio, whereas the WMFAudioMFTManager is only able to handle 2 channel audio; it doesn't have a resampler, and presumably the WMFReader uses the one that ships with WMF.

Comment 2

[Alice0775 White]

FYI,
Setting media.fragmented-mp4.exposed = false helps

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

Right, that switches back to the WMFReader from the MP4Reader. Presumably the WMFReader resamples the audio down from 5.1 to 2 channel.

Comment 4

[Alice0775 White]

To be clear.

In Firefox33
When load the file, autoplay start properly

In Nightly35.0a1
When load the file, no autoplay.
Click play button, the button shape changes to ||. but, progress remains 0:00 despite total is 0:47. And no sound.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

OK, it's not as simple as I thought; the WMF says the file's AAC profile level indication is 46, but our demuxer is extracting a profile level of 0, and Adts::ConvertEsdsToAdts() is failing to convert to ADTS due to the profile level being <1 or > 4. So even if the demuxer extracted the profile level indication, Adts::ConvertEsdsToAdts() still needs to be patched to handle the profile level=46.

Comment 6

[Lawrence Mandel [:lmandel] (use needinfo)]

Chris - Your last comment was from a couple of weeks ago. Can you take this bug?

Comment 7

[Karl Tomlinson (:karlt)]

Perhaps Ralph can help here.

We're not clear how widespread this issue will be, but it may be necessary to revert changes from bug 1057879, for now.

Comment 8

[Ralph Giles (:rillian)]

I don't see the 'profile 46' cpearce reported from WMF. Stagefright parses the ESDS atom as giving Audio Object Type 5, which is 'SBR' i.e. HE-AAC v1 (LC-AAC + SBR) according to http://wiki.multimedia.cx/index.php?title=MPEG-4_Audio#Audio_Object_Types.

MPEG4Extractor checks if this is in [1,4] before writing it to the Metadata dictionary. Since it's not, DataDecoder reads 0 for this key, passes it to Adts::ConvertEsdsToAdts, which rejects it, because there's only room for profiles 1-4 in the ADTS header.

In the absence of a spec reference for HE-AAC in ADTS, I think we need to test all the platform to see if they will take the data in ADTS with an incorrect profile value, or failing that, take the raw AAC samples without ADTS framing. HE-AAC is mostly and mpeg-4 thing, and ADTS seems to be mostly an mpeg-2 thing. avconv doesn't know how to remux this file into .aac, for example.

If anyone knows how we're supposed to represent profile 5 or 6 in ADTS, please share.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Proof of concept patch for Windows

After talking to Ralph, it seems that the problem is that the ADTS header has a limit of 2 bits to represent the audioProgilLevelIndication, and obviously profile level 46 can't be represented in 2 bits, so it's reasonable for Adts::ConvertEsdsToAdts() to fail.

We can make WMF's AAC decoder accept raw AAC, as in this patch.

This still needs to be plumbed up correctly; the MacOSX backend fails on this file too.

I guess that we should actually send through raw AAC for *all* backends, i.e. not make our demuxer output ADTS. We'll need to figure out how to make every backend accept raw AAC then... :(  Or something...

Comment 10

[Ralph Giles (:rillian)]

Sadly we'd need to rewrite AppleATDecoder to pass raw AAC on MacOS. I copied the mp3 code, where we pass it to AudioFile Services, which parses out the packet boundaries from an un-delimited stream. Without the ADTS headers there's no way to do that for AAC.

Given there are HE-AAC files which use lower-spec object types, like :jya's http://www-tvline-com.vimg.net/streaming/tvline/MAA101-Medianet.mp4 I want to investigate picking a random profile level for the ADTS header and seeing what else is blocking playback.

Comment 11

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

(In reply to Chris Pearce (:cpearce) from comment #9)
> I guess that we should actually send through raw AAC for *all* backends,
> i.e. not make our demuxer output ADTS. We'll need to figure out how to make
> every backend accept raw AAC then... :(  Or something...

In theory it would be a case of plumbing up the extradata.

(In reply to Ralph Giles (:rillian) from comment #10)
> Given there are HE-AAC files which use lower-spec object types, like :jya's
> http://www-tvline-com.vimg.net/streaming/tvline/MAA101-Medianet.mp4 I want
> to investigate picking a random profile level for the ADTS header and seeing
> what else is blocking playback.

My instinct would be to set the profile level to 4 and hope for the best.

Comment 12

[Ralph Giles (:rillian)]

Comment on attachment 8510682 [details] [diff] [review]
Proof of concept patch for Windows

Review of attachment 8510682 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry, missed the f? on the patch. As mentioned above, this approach isn't easy for Mac. Not sure about Android. If we make ADTS mux conditional like we did for Annex B, this could land to fix it just for windows.

::: content/media/fmp4/wmf/WMFAudioMFTManager.cpp
@@ +60,5 @@
>    // the rest can be all 0x00.
>    BYTE heeInfo[heeInfoLen] = {0};
>    WORD* w = (WORD*)heeInfo;
> +  w[0] = 0x0; // Payload type raw AAC packet
> +  w[1] = aAACProfileLevelIndication;

Propagating this seems helpful regardless?

Comment 13

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Ralph Giles (:rillian) from comment #12)
> Comment on attachment 8510682 [details] [diff] [review]
> Proof of concept patch for Windows
> 
> Review of attachment 8510682 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Sorry, missed the f? on the patch. As mentioned above, this approach isn't
> easy for Mac. Not sure about Android. If we make ADTS mux conditional like
> we did for Annex B, this could land to fix it just for windows.

That seems like a win to me, as we'd want to uplift the fix to Beta.

Comment 14

[Ralph Giles (:rillian)]

Ok.

Meanwhile, forcing profile to 1 in the ADTS header, we fail to play file because:

  Audio Decoder configuration: audio/mp4a-latm 44100 Hz 6 channels 16 bits per channel
  ...
  128 frames decoded
  pushed audio at time 0.000000s; duration 0.001451s
  MP4Reader::Output change of sampling rate:44100->88200

The decoder thinks it's producing 44.1 kHz audio, but when it sees the first chunk of data, MP4Reader reads the sample rate as 88.2 kHz. The decoder then sees it can't produce as much data as is requested and errors out.

Comment 15

[Ralph Giles (:rillian)]

Attachment: Handle AppleATDecoder::Flush before setup.

So today's master no longer sees 88.2 kHz. Still doesn't play though.

Jean-Yves, your type detection code is shutting down the decoder before it has itself determined the type and set up the AudioConverter instance so it can start producing output. We're returning an error, but it seems to be ignored.

This patch stops returning the error. Is that correct, or should we be doing something else here? If you're trying to get to metadataloaded I assume this isn't what you want.

Comment 16

[Ralph Giles (:rillian)]

Comment on attachment 8512228 [details] [diff] [review]
Handle AppleATDecoder::Flush before setup.

Ok, this was happening when the ADTS header function rejected the sample, so I think we do want to return an error here. Should still probably make it explicit though.

Comment 17

[Ralph Giles (:rillian)]

Ok, Apple's AudioConverter rejects this stream with the ADTS header on it (for any of the four profile levels). Back to Chris' patch to fix the Windows regression.

Comment 18

[Ralph Giles (:rillian)]

Attachment: Treat unknown AOT as ADTS profile 4

Here's the patch I was using to test ADTS pass-through, for completeness. As I said, this doens't work on MacOS, so I don't think this is a useful route.

Comment 19

[Ralph Giles (:rillian)]

Attachment: Part 1: Export Adts.h

Comment 20

[Ralph Giles (:rillian)]

Attachment: Part 2: Return raw AAC from mp4_demuxer

Comment 21

[Ralph Giles (:rillian)]

Attachment: Part 3: Accept raw AAC in the Windows Platform Decoder Module

Rebased version of cpearce's proof-of-concept patch.

Comment 22

[Ralph Giles (:rillian)]

Attachment: Part 4: Rename Adts conversion method

Comment 23

[Ralph Giles (:rillian)]

Attachment: Part 5: Apply ADTS header on MacOS X

This doesn't fix the issue on Mac, just supports the Windows work-around.

Comment 24

[Ralph Giles (:rillian)]

Attachment: Part 6: Apply ADTS header on Android

Doesn't fix the problem on Android either.

Comment 25

[Ralph Giles (:rillian)]

Attachment: Part 7: Apply ADTS header for ffmpeg

Comment 26

[Ralph Giles (:rillian)]

Attachment: Part 8: Apply ADTS header on gonk

Comment 27

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8514637 [details] [diff] [review]
Part 5: Apply ADTS header on MacOS X

Review of attachment 8514637 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/fmp4/apple/AppleATDecoder.cpp
@@ +367,5 @@
>  AppleATDecoder::SubmitSample(nsAutoPtr<mp4_demuxer::MP4Sample> aSample)
>  {
> +  // Prepend ADTS header to AAC audio.
> +  if (!strcmp(mConfig.mime_type, "audio/mp4a-latm")) {
> +    bool rv = mp4_demuxer::Adts::ConvertEsdsToAdts(mConfig.channel_count,

mp4_demuxer::Adts::ConvertSample ?

Comment 28

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8514641 [details] [diff] [review]
Part 8: Apply ADTS header on gonk

Review of attachment 8514641 [details] [diff] [review]:
-----------------------------------------------------------------

This won't compile; mConfig is not a field on the GonkAudioDecoderManager...

Comment 29

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8514640 [details] [diff] [review]
Part 7: Apply ADTS header for ffmpeg

Review of attachment 8514640 [details] [diff] [review]:
-----------------------------------------------------------------

Oops, same compile error here as before; mConfig is not (yet) a member of this class...

Comment 30

[Ralph Giles (:rillian)]

Attachment: Part 8: Apply ADTS header on gonk v2

Good point. This better?

Comment 31

[Ralph Giles (:rillian)]

Comment on attachment 8514652 [details] [diff] [review]
Part 8: Apply ADTS header on gonk v2

Nevermind, forgot the mime type.

Comment 32

[Ralph Giles (:rillian)]

Attachment: Part 8: Apply ADTS header on gonk v3

Just apply the ADTS header unconditionally on gonk.

It looks like this module assumes aac-with-adts all the time. Maybe mp3 just happened to be accepted by that decoder, or maybe it didn't work at all?

Jean-Yves, did you test mp3-in-mp4 on Firefox OS?

Comment 33

[Ralph Giles (:rillian)]

Attachment: Part 7: Apply ADTS header for ffmpeg v2

Add a reference to the AudioDecoderConfig to the ffmpeg decoder so we can use it to access parameters we need for Adts.

Comment 34

[Ralph Giles (:rillian)]

Attachment: Part 8: Apply ADTS header on gonk v4

Fix gonk properly. Check at ctor time whether we're passed the mp4a-latm mime type and save that as a member bool.

Comment 35

[Ralph Giles (:rillian)]

Attachment: Part 6: Apply ADTS header on Android v2

Rebase android patch on top of changes from bug 1089159. Carrying forward r=cpearce; it was a merge conflict from overlapping context.

Comment 36

[Jean-Yves Avenard [:jya]]

(In reply to Ralph Giles (:rillian) from comment #32)
> Created attachment 8514661 [details] [diff] [review]
> Part 8: Apply ADTS header on gonk v3
> 
> Just apply the ADTS header unconditionally on gonk.
> 
> It looks like this module assumes aac-with-adts all the time. Maybe mp3 just
> happened to be accepted by that decoder, or maybe it didn't work at all?
> 
> Jean-Yves, did you test mp3-in-mp4 on Firefox OS?

no.

mp3 in fmp4 was only enabled on ffmpeg, apple and windows.
this is done in PlateformDecoderModule::SupportsAudioMimeType

the default implementation is audio/mp4a-latm only.
Gonk still doesn't support it
I've seen changes happening on the Android decoder module, but I don't know if that added mp3 support. the logs do not mention it

Comment 37

[Ralph Giles (:rillian)]

Ok, thanks.

Comment 38

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8514688 [details] [diff] [review]
Part 8: Apply ADTS header on gonk v4

Review of attachment 8514688 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/fmp4/gonk/GonkAudioDecoderManager.cpp
@@ +47,5 @@
>    MOZ_COUNT_CTOR(GonkAudioDecoderManager);
>    MOZ_ASSERT(mAudioChannels);
>    mUserData.AppendElements(&aConfig.audio_specific_config[0],
>                             aConfig.audio_specific_config.length());
> +  // Pass through mp3 without applying an ADTS header.

B2G doesn't support MP3 in MP4 yet:

http://mxr.mozilla.org/mozilla-central/source/dom/media/fmp4/MP4Decoder.cpp#62

It's probably OK to keep this however, to future proof it...

Comment 39

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8514672 [details] [diff] [review]
Part 7: Apply ADTS header for ffmpeg v2

Review of attachment 8514672 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/fmp4/ffmpeg/FFmpegAudioDecoder.h
@@ +35,4 @@
>    void DecodePacket(mp4_demuxer::MP4Sample* aSample);
>  
>    MediaDataDecoderCallback* mCallback;
> +  AudioDecoderConfig& mConfig;

const AudioDecoderConfig& mConfig;

The AudioDecoderConfig passed to the constructor is a const reference, so this may lose the const-ness?

Comment 40

[Ralph Giles (:rillian)]

Attachment: Part 7: Apply ADTS header for ffmpeg v3

Fix const reference issue with the ffmpeg patch. Carrying forward r=cpearce.

Comment 41

[Ralph Giles (:rillian)]

Attachment: Part 5: Apply ADTS header on MacOS X v5

Fix rebase error; the previous patch was using the old Adts conversion method name. Carrying forward r=cpearce.

Comment 42

[Ralph Giles (:rillian)]

Attachment: Part 6: Apply ADTS header on Android v5

Fix build problems with the previous android patch.

No AudioDecoderConfig structure is available in the android AudioDataDecoder, so query these out of the format dictionary instead. For AAC files, also record the AAC profile level in this dictionary when it is created.

Comment 43

[Ralph Giles (:rillian)]

Attachment: Part 7: Apply ADTS header for ffmpeg v5

Fix build problem with the ffmpeg patch. The previous version was missing some namespace qualifications. Carrying forward r=cpearce.

Comment 44

[Ralph Giles (:rillian)]

Attachment: Part 8: Apply ADTS header on gonk v5

Fix build issues with the gonk patch: add missing Adts.h include and fix syntax typo. Carrying forward r=cpearce.

Comment 45

[Ralph Giles (:rillian)]

This set builds on all platforms:

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=85c4613ea312

Comment 46

[Ralph Giles (:rillian)]

Pushed to inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/d760936fd2a5
https://hg.mozilla.org/integration/mozilla-inbound/rev/ff6fa5f20fe0
https://hg.mozilla.org/integration/mozilla-inbound/rev/ad8c843d5ed4
https://hg.mozilla.org/integration/mozilla-inbound/rev/e3a96f15fd4f
https://hg.mozilla.org/integration/mozilla-inbound/rev/0100718aabc8
https://hg.mozilla.org/integration/mozilla-inbound/rev/5a47d6e6d979
https://hg.mozilla.org/integration/mozilla-inbound/rev/a3283c5f051e
https://hg.mozilla.org/integration/mozilla-inbound/rev/ba521101c7c3

Comment 47

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d760936fd2a5
https://hg.mozilla.org/mozilla-central/rev/ff6fa5f20fe0
https://hg.mozilla.org/mozilla-central/rev/ad8c843d5ed4
https://hg.mozilla.org/mozilla-central/rev/e3a96f15fd4f
https://hg.mozilla.org/mozilla-central/rev/0100718aabc8
https://hg.mozilla.org/mozilla-central/rev/5a47d6e6d979
https://hg.mozilla.org/mozilla-central/rev/a3283c5f051e
https://hg.mozilla.org/mozilla-central/rev/ba521101c7c3

Comment 48

[Ralph Giles (:rillian)]

Attachment: Aurora backport

Squashed patch, ported to Aurora: s/dom/content/ for media tree move, and drop android patch; that code isn't in Firefox 35.

Approval Request Comment
[Feature/regressing bug #]: Bug 1057879

[User impact if declined]: Users on Windows will experience a regression where some video files with HE-AAC 2 audio which used to play no longer play.

[Describe test coverage new/current, TBPL]: Landed on m-c. Passes mochitests there.

[Risks and why]: Behaviour is the same on all other platforms, and the change is small, just moving a step from one part of the code to the other. However, there are a lot of different files and each platform is different, so I'd like to get this deployed for broader testing asap.

[String/UUID change made/needed]: None.

Comment 49

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Ralph Giles (:rillian) from comment #48)
> Created attachment 8516198 [details] [diff] [review]
> Aurora backport
> 
> Squashed patch, ported to Aurora: s/dom/content/ for media tree move, and
> drop android patch; that code isn't in Firefox 35.
> 
> Approval Request Comment
> [Feature/regressing bug #]: Bug 1057879
> 
> [User impact if declined]: Users on Windows will experience a regression
> where some video files with HE-AAC 2 audio which used to play no longer play.
> 
> [Describe test coverage new/current, TBPL]: Landed on m-c. Passes mochitests
> there.
> 
> [Risks and why]: Behaviour is the same on all other platforms, and the
> change is small, just moving a step from one part of the code to the other.
> However, there are a lot of different files and each platform is different,
> so I'd like to get this deployed for broader testing asap.
> 
> [String/UUID change made/needed]: None.

Note: if uplift is declined, we will have to disable the new MP4 <video> backend on Windows in Firefox 34 and 35, and revert to the old <video> playback backend that we used in previous Firefox versions. This just requires a pref change. However the new <video> backend is more reliable, so we'd like to ship it in Firefox 34 if possible.

Comment 50

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8514634 [details] [diff] [review]
Part 3: Accept raw AAC in the Windows Platform Decoder Module

Review of attachment 8514634 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/fmp4/wmf/WMFAudioMFTManager.cpp
@@ +22,4 @@
>  namespace mozilla {
>  
>  static void
> +AACAudioSpecificConfigToUserData(uint8_t aAACProfileLevelIndication,

I just discovered that we actually don't need to pass that aAACProfileLevelIndication here. The demuxer only outputs aacProfileLevelIndication values in range [1..4]:
http://mxr.mozilla.org/mozilla-central/source/media/libstagefright/frameworks/av/media/libstagefright/MPEG4Extractor.cpp#2336

So the profileLevelIndication value for the file in question here (46 IIRC) will in fact be output as 0 by the demuxer.

So in practice we'll be passing aAACProfileLevelIndication==0 for the oddball types anyway. I think WMF is smart enough to figure it out based on the AudioSepcificConfig we pass in (the "user data"). We can prune this off in a follow up.

Comment 51

[Ralph Giles (:rillian)]

Thanks for the follow-up. I've filed bug 1093318 to track this.

Comment 52

[Ralph Giles (:rillian)]

Comment on attachment 8516198 [details] [diff] [review]
Aurora backport

Approval Request Comment

[Feature/regressing bug #]: Bug 1057879

[User impact if declined]: We'll revert the pref change enabling the new mp4 backend to avoid this regression, leaving Firefox 34 on the older, less stable decoder. Or be forced to allow a serious regression to propagate to release.

[Describe test coverage new/current, TBPL]: Landed on m-c, passing mochitests there.

[Risks and why]: The change is straightforward and behaviour should be the same except for Windows, where it should be more correct. However there are a lot of file variations and every platform is handled separately, so we won't know for sure until it sees wider testing in deployment.

On the balance we think this is worth the risk relative to the problems we had with the old mp4 back-end prior to Firefox 34.

[String/UUID change made/needed]: None.

Comment 53

[Ralph Giles (:rillian)]

Beta try push failed 'make check' on Windows. Any idea what could have caused this, Chris?

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=e45376debaa1

Comment 54

[Chris Pearce [:cpearce (Not reading bugmail)]]

Uh, that push looks pretty sick. Are you sure the parent changeset wasn't bad?

Comment 55

[Lukas Blakk [:lsblakk] use ?needinfo]

Triage drive-by: waiting for a clean landing before approving for uplift.

Comment 56

[Ralph Giles (:rillian)]

(In reply to Chris Pearce (:cpearce) from comment #54)
> Uh, that push looks pretty sick. Are you sure the parent changeset wasn't
> bad?

It's mozilla-beta, which passed on the official build. I guess I can try pushing my tree without the patch. I tried again with today's tree (only two changes) but hit the same error. https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=8608a0123e78

I'll try to build on windows see if I can reproduce tomorrow.

Comment 57

[Ralph Giles (:rillian)]

I think beta is just broken on try, or there's something wrong with my repo. Pushing my beta checkout to try fails the same way without the patch applied. Patch is green pushed on top of Aurora.

Read for uplift approval.

Comment 58

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8516198 [details] [diff] [review]
Aurora backport

OK. Let's try landing this on beta. If the tree burns, this will of course get backed out. Beta+ Aurora+

Comment 59

[Ralph Giles (:rillian)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/ab9c1b8628c9

Comment 60

[Ralph Giles (:rillian)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/ab9c1b8628c9

Comment 61

[Ralph Giles (:rillian)]

https://hg.mozilla.org/releases/mozilla-beta/rev/decaff6b28c7

Sorry, wrong link in comment 60.

Comment 62

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

Attachment: Don't set the is-adts flag for the Android PDM

While uplifting the Android PDM to 34 (Beta), I noticed audio didn't work. The attached patch fixes. We'll also need it for Aurora.

Nightly has the patch attached to this bug (Part 6), but I think this patch might be better.

Comment 63

[Ralph Giles (:rillian)]

Comment on attachment 8524907 [details] [diff] [review]
Don't set the is-adts flag for the Android PDM

Review moved to bug 1101225.

Comment 64

[Ryan VanderMeulen [:RyanVM]]

TM tracks landing on m-c. Please don't change it around for branch uplifts.

Comment 65

[Jean-Yves Avenard [:jya]]

this has regressed. Can't play it anymore with current nightly.