mozilla :: #media

13 Jul 2017
01:06bwualfredo: do we have a telemetry to know how many times demuxing falls back from rust demuxer to stagefright demuxer?
01:09bwuWhat I really wonder is when we can finally get rid of SF demuxer.
01:12alfredobwu: we have telemetry for parser success or failure.
01:15alfredobwu: I plan to remove stagefright at next half year, it depends on how complicated we have integrated stagefright codes into gecko.
01:16alfredobwu: or maybe disable it first if it is too complicated to remove it completely.
02:48bwualfredo: Cool. Can we make it happen on 57?
02:51alfredobwu: it depends on situation. Maybe 58 or 59, I guess.
02:55alfredobwu: is there any reason to disable stagefright on 57?
04:28djg|kamidphishkinetik: Is there a streams-per-context limit in cubeb or any of the backends?
05:17bwualfredo: We have planned it to remove it for a while. It is really nice to see it to be moved out of our codes quickly. Then we can focus on something more interesting.
05:32robswain-Mrillian: do you specifically need something paid or are you happy to use public instances / deploy your own? How many simultaneous meetings and how many participants are you expecting? I would also recommend jitsi and meet.jit.si is the public deployment
05:59achronopdjg|kamidphish: can you chec this try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=03c43f4a96ffb82debbedeeee0ff2fe2c8e7a707
06:01achronopdjg|kamidphish: I try to update latest cubeb with your change in cubeb_get_min_latency
06:04achronopdjg|kamidphish: does the same change exist in rust backend?
06:10djg|kamidphishachronop: Let me check. Is this the change that has the new entry in cubeb_ops?
06:11djg|kamidphishachronop: I believe this version of cubeb-pulse-rs is required: https://github.com/djg/cubeb-pulse-rs/commit/3b8cfba161cec66bee6a755bce102466baa92ddb
06:11achronopdjg|kamidphish: no, this one change the signature of one of the methods
06:12djg|kamidphishachronop: The get_min_latency change?
06:12achronopdjg|kamidphish: just a minute
06:13achronopdjg|kamidphish: yeah, this version has both changes
06:13achronopthe get_min_latency and the change in cubeb_ops
06:14djg|kamidphishachronop: I bet cubeb-pulse-rs doesn't have this change: https://github.com/kinetiknz/cubeb/commit/7590a1e232bc3c1c2d97e2c5c517404cc3c73388#diff-217e6e6ac78cd44250d7bf39776f2144
06:15achronopok, what about this one https://github.com/kinetiknz/cubeb/commit/d16db3b6926ecfa8b1afff599dd40205d8eecc2b ?
06:21djg|kamidphishThat's only at the API level. The pointer is deref'd and passed to backends by value.
06:22achronopnice
06:27djg|kamidphishachronop: Yeah, I was lazy. :-/
06:27djg|kamidphishachronop: I allowed the public API to change with out having to give any more thought to what it meant for the backends.
06:38achronopdjg|kamidphish: well, it's useful here so maybe it was the right thing to do in terms of portability
07:07kinetikdjg|kamidphish: not on any of the Tier 1 platforms, but there has been in the past and for other backends
07:07djg|kamidphishkinetik: Ok.
07:08kinetikdjg|kamidphish: that is, not in cubeb, but there may be limits at the OS API level
07:08kinetike.g. PA has a per-context stream limit (64?)
07:28djg|kamidphishkinetik: So there's no stream limit to the users of cubeb (ie. WebAudio)
07:33kinetikdjg|kamidphish: right, not as part of the cubeb API
13:31jyakentuckyfriedtakahe: received the HP laptop. The build quality is so atrocious. I'm ashamed a brand like HP could now produce stuff like that. I understand things are made to a price. But really.
13:32jyaIt wasn't even that cheap.
14:39jesupjya: is this the "standard" laptop for QF bugs?
14:40jesupdminor: any luck on the AEC logging? I want to use it since I twice caused echo in the standups yesterday. I could jump in and look if need be
14:40jesupI have a meeting in a few minutes (11-12 EDT, though often shorter)
14:42jyajesup: no idea. Its a la
14:42jyaa laptop with an AMD A12, that has VP9 how decoder (and encoder)
14:43jyafor whatever reason, amd decided not to expose the HW decoder via the official Microsoft MFT.
15:03rillianrobswain-M: thanks for the suggestions. We'll eventually want something open-source we can host ourselves for privacy, but right now I'm just looking for something we can try out, so public instances are fine. It's usually 5-8 streams.
15:04rillianmost participants have the bandwidth for n-n, but not all.
15:06robswain-Mpublic appear.in is still full mesh iirc, but fippo is working on an SFU...?
15:06robswain-Mthough i don't think that's going to be open-sourced, is it fippo?
15:06robswain-Mor i wouldn't have guessed it would, but maybe it will be :)
15:06robswain-Mjitsi is open source
15:09dminorjesup: testing it on try, I can put the patch up now
15:17jibjesup: Hi, could you add me to bug 1380610 ?
15:17firebotBug https://bugzil.la/1380610 is not accessible
15:23jibor anyone else: ^
18:05mjfAnyone else seeing lots of mochitest failures on the latest from m-c when running on OSX?
18:08mjfhttps://pastebin.mozilla.org/9027020
18:12ngmjf: I'll give it a shot
18:39fippojib: congrats, i think your commit is #3000 on webrtc-pc!
18:39jib
18:40ngjib: congrats
18:41fippohttps://github.com/w3c/webrtc-pc -- 3004 commits now
18:41fipponot taking bets if we will finish 1.0 in less than 5k
18:41mjfjib: \o/
20:10cpearcejya: I'm trying to understand your comments on the test in Bug 135112... the both streams are appended in their entirety (so initdata+sampledata) in a single append, one append for each stream to a new source buffer. And one stream is appended in its entirety (in a single append) before the second stream is appended. This appears to be working. Are you
20:10cpearcesaying that I need to split off the init data for each stream and append that separately before I should append the sample data? Appending each stream in its entirety seems to be working...
20:10firebothttps://bugzil.la/135112 FIXED, karnaze@formerly-netscape.com.tld [PATCH]Combing "border-collapse: collapse" and DHTML doesn't work
20:10cpearceI mean bug 1351124
20:10firebothttps://bugzil.la/1351124 UNCONFIRMED, cpearce@mozilla.com [EME] support for key rotation
20:11jyacpearce: my point exactly. The code is okay if you do a single append buffer containing both init and media segment. Seeing that this code is duplicated in a few EME test, it would be nicer to handle it properly so that you can do multiple appendBuffer.
20:13cpearcejya: Most of the other EME tests do multiple appends. I was trying to make more focused tests that limit the number of things we test, rather than huge monolithic tests which test everything at once.
20:13cpearceOK, it sounds like what we're doing here is OK then.
20:14jyaIf other tests using that routine do multiple append per stream, success will be timing dependent.
20:16SingingTreecpearce: I'm looking at a media recorder test that's intermittenting. The test sets up some prefs such that it wants to make sure the media element does multiple requests to grab a file: https://searchfox.org/mozilla-central/source/dom/media/test/test_mediarecorder_principals.html#45
20:16SingingTreeDo you think recent MediaCache changes may have an impact on the behaviour of this?
20:17cpearcejya: That routine is locally defined, and not shared or reused. I was planning on refactoring it to be shared, once I got things working. I'll look out for this problem when I do.
20:17jyaI've seen that code elsewhere with the same name.
20:17cpearcejya: yes, I copied it.
20:19kentuckyfriedtakaheI filed bug 1380795 for the camera selection
20:19firebothttps://bugzil.la/1380795 NEW, nobody@mozilla.org WebRTC defaults to back camera instead of front on Android
20:19kentuckyfriedtakahejib: ^^^ and I also filed bug 1380793 that was causing echo on the conference unit
20:20firebothttps://bugzil.la/1380793 NEW, nobody@mozilla.org WebRTC does not use default communications device
20:20cpearceSingingTree: if your file is less than 32kb in size, we'll just buffer the whole thing in memory now (in media tests, 8MB in the wild), and we won't throttle. so that may affect your results. You should also set (and ensure you unset) the media.memory_cache_max_size pref there too.
20:20kentuckyfriedtakahewe still need to figure out what is going on with echo on my mobile
20:20jibkentuckyfriedtakahe: Thanks!
20:23jibkentuckyfriedtakahe: Note on changing the cam default, the web site can and should in theory specify which camera it wants, e.g. a face-calling website should specify getUserMedia({video: {facingMode: "user"}}) - https://stackoverflow.com/questions/32086122/getusermedia-facingmode/32364912#32364912
20:24kentuckyfriedtakahemaybe it is just me but I'd expect that face would be the right default
20:24jibthough I suppose it might make sense to change the system-wide default to front camera regardless on
20:24jibphones
20:25kentuckyfriedtakahejib: I've filed the bug, it is up to you to figure out the right thing to do
20:25jibsure, just a good time to mull on it now that it is n my head :)
20:25SingingTreecpearce: Do mochitests provide any auto pref popping? I see a swag pushing prefs but never popping
20:25jibThere might be a web compat issue with changing it. I'll check Chrome for Android
20:26mjfjib: ping
20:27jibmjf: pong
20:27mjfDo you know if MediaRecorder supports pcm (.wav)? This is from Bug 1379241
20:27firebothttps://bugzil.la/1379241 NEW, nobody@mozilla.org support WAV format for MediaRecorder
20:28mjfpcm would be a default encoding, yes?
20:30cpearceSingingTree: pushPrefEnv auto pops I believe.
20:30SingingTreeAh, cheers
20:34jyahttps://irccloud.mozilla.com/file/ASEQQxA9/1499978077.JPG
20:34jyaHappy July 14th, 1.5h early
20:37jibkentuckyfriedtakahe: Chrome for Android appears to default to the front camera now, so good idea to change it!
20:39cpearcejya: We only demux when the media data is appended, and store the resulting demuxed samples. So if we seek in the stream, we won't re-demux the MOOFs right? So we shouldn't run the code re-demux and check for PSSH boxes again on the same MOOFs when we seek? We should only redemux if we re-append, and if so I think dispatching again is allowed under the EME
20:39cpearcespec.
20:40jyacpearce: for plain mp4 we will. But I guess you don't care :)
20:40cpearcejya: yeah, not supported at this stage.
21:24jyacpearce: does that look right to you?
21:24jyahttps://dxr.mozilla.org/mozilla-central/source/dom/media/DecoderTraits.cpp#150
21:25jyaon platform other than android <= 16, supportedCodecs will always be empty, and so CanHandleCodecsType always return MAYBE for any format we don&#39;t support
21:26jyawhich is different to CanHandleMediaType, that has the same logic at the end for android, except that it return CANPLAY_NO
21:27cpearcejya: aren&#39;t we removing this logic anyway?
21:27jyawell, if i remove the OMX part , then supportedCodec will always be empty
21:28jyabut never mind, the way CanHandleCodecType is called, it needs to return something different to YES or NO to try things again
21:28jyaso it&#39;s all good
21:28* jya off to bed
21:29jyajesup: do you plan on ever looking at my changes to webRTC ?
21:29cpearcejya: you could quickly re-review my PSSH in MOOF changes before you go? am pushing now...
21:30jyait&#39;s super late, and i had way too much wine tonight
21:30jyabut sure.... going to have a rinse first
21:30cpearcehaha
21:30cpearceI&#39;m sure the wine will make my code more palatable!
21:32cpearcejya: there you go...
21:39jyacpearce: was just thinking for box with 64 bits size. It&#39;s impossible for a pssh box to have a size exceeding 32 bits. Could simply rewrite the header so that the size is written in the 4 bytes always.
21:40jya(A great idea I had while having a shower, in my best source if inspiration :D )
21:43cpearcejya: well... we could reject/ignore a pssh box with size exceeding 32bits. That would be a ridiculous sized PSSH.
21:43cpearcejya: if we rewrote, we&#39;d need to reject if the size was > 32bit anyway, as we&#39;d not be able to fit the size in the 4 byte size field.
21:45jyaThe issue isn&#39;t with size > 32 bits. It&#39;s that some muxers write the size on 64 bits int.
21:46jyaSo even a size of 100 bytes is written as 000001 FOURCC size_64_bits
21:46jyaSo yes, ignoring pssh whose size is greater than 2GB is fine.
21:47cpearcejya: I would prefer to pass the whole box unmodified to the JS app, so that it gets out what it puts in.
21:47cpearceThe app may have assumptions about the crypto initdata, and I don&#39;t want to mess with them.
21:49jesupjya: yes. Sorry, still digging out of workweek and PTO. Will look tonight
21:50jesupI don&#39;t block reviews when on PTO; I dislike doing that generall
21:53jyajesup: thanks.
21:54jyaIIRC, i may not have handled rotation information properly.
21:54jyacpearce: done. Just one comment
21:54cpearcejya: great, thanks for staying up.
22:00jesupjya: we haven&#39;t (yet) utilized rotation. It can help a bit in some cases on Android
23:23kentuckyfriedtakahecpearce: can we close bug 1287352 yet?
23:23firebothttps://bugzil.la/1287352 NEW, cpearce@mozilla.com Bitmovin Dash Player doesn&#39;t play in Nightly with Firefox profile on network drive
23:24cpearcekentuckyfriedtakahe: not until we roll out the Widevine 970 update.
23:24cpearcekentuckyfriedtakahe: which it looks like won&#39;t happen until tomorrow
23:24cpearcekentuckyfriedtakahe: the update is on the test channel, and I&#39;ve tested it, but the guy pushing it out is on GMT. :(
23:24kentuckyfriedtakahecpearce: do you have a bug number for that?
23:25cpearcekentuckyfriedtakahe: bug 1380175
23:25firebothttps://bugzil.la/1380175 NEW, mtabara@mozilla.com Update Widevine CDM to version 970
23:26kentuckyfriedtakahecpearce: how about bug 1286685?
23:26firebothttps://bugzil.la/1286685 UNCONFIRMED, cpearce@mozilla.com Widevine CDM: MediaKeySystemAccess.createMediaKeys returns a promise that doesn&#39;t resolve
23:27cpearcekentuckyfriedtakahe: I am not sure about that one.
23:28kentuckyfriedtakahecpearce: can you save me some time and see if any of these are obviously fixed https://mzl.la/2sVU7XM ?
23:29cpearcekentuckyfriedtakahe: ok, I&#39;ll finish my reviews first.
23:31kentuckyfriedtakahecpearce: no worries. looks like the 2nd bug has the same crash signature as the first
23:32cpearcekentuckyfriedtakahe: lots of things end up with that signature, that&#39;s why I&#39;m not sure.
14 Jul 2017
No messages
   
Last message: 72 days and 20 hours ago