mozilla :: #media

8 Aug 2017
00:00sheppyThat's what I think, yeah.
08:04djg|kamidphishkinetik: Been trying to setup rust-bindgen for cubeb. What a pain. Much easier with my hand written code.
08:07padenotdjg|kamidphish, what do you see ? It was not too hard last time I did things like that ?
08:07djg|kamidphishpadenot: Well it's not generating Copy on a type that is totally Copy.
08:08djg|kamidphishpadenot: So compilation fails.
08:09djg|kamidphishhttps://irccloud.mozilla.com/pastebin/L4Erxxjl/
08:09padenotdjg|kamidphish, do you have code up somewhere?
08:09padenotI can have someone looking at this right now
08:10padenot(as in, the servo person that does the spidermonkey integration, should be good enough)
08:10djg|kamidphishpadenot: I'm currently looking at how to teach rust-bindgen to do the right thing, but if someone knows the tool better that would shorten the turn around.
08:11padenotdjg|kamidphish, if you can put code up somewhere, he can have a quick look yeah
08:11padenotor else, ping emilio or nox in #servo
08:11padenotthey're up right now it seems
08:12djg|kamidphishpadenot: I'm uploading my script
08:13padenotcool
08:15djg|kamidphishpadenot: https://github.com/djg/cubeb-rs/commits/rust-bindgen
08:16djg|kamidphishI pushed to a working branch
08:16djg|kamidphishneeds to have a cubeb checkout with cubeb_exports.h
08:18djg|kamidphishOh, cubeb on github and libcubeb in gecko don't have the same layout. :-(
08:21padenotthat can happen yeah
08:22padenotis that the root of your issue do you think ?
08:27padenotI'm using most recent cubeb upstream and your repo and I can repro
08:30padenotdjg|kamidphish, also, why is it generating a struct for this one, and just a type alias for the other very similar cases ?
08:34padenotdjg|kamidphish, I have something that work
08:36padenothttps://pastebin.mozilla.org/9029106, the first one is not a bitfield, and the second one could be considered as a bitfield, but I don't know, the generated code looks correct
10:09cpearcejw_wang: FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1382574#c13
10:09firebotBug 1382574 NEW, alwu@mozilla.com Can't play vimeo video when setting "media.autoplay.enabled=false"
10:31geraldcpearce: How do you do a non-unified build?
10:31cpearcegerald: by editing moz.build files; change UNIFIED_SOURCES to SOURCES
10:32geraldduh :-P
10:33geraldI expected some kind of magic env-var to do that
10:34gerald(But I guess it would affect the whole build, and you only wanted to do that for media stuff; makes sense, thanks!)
12:02padenotmreavy, ping
13:03padenotjib, ping
13:03jibpadenot: pong
13:05* jib bbiab
14:10Caspy7I had no idea Hardware acceleration for VP9 was on or in 55
14:11Caspy7good job folks!
14:12padenotyou have to have the hw, that is pretty rare
14:15Caspy7padenot: sure, understood, but I'm pleased that it's there and the hardware coverage is growing
14:15padenotyeah it's great
14:17Caspy7padenot: do I recall some other effort to up the ability of HWA for video? There was some sort of tech that Edge was using that allowed them to be more efficient on videos but we hadn't finished it
14:17Caspy7sorry about the vagueness of the question
14:18padenothm there is the fact that they use the OS' compositor, for starters, and not a different compositor for the browser
14:20Caspy7I recall one user in particular who could get higher res videos working smoothly in Edge but not Firefox, then they tried Nightly and found it was much better
14:21Caspy7I was thinking it was one of these acronym techs...D3D or something
14:21padenotah that's possible yes
14:21padenotD2D maybe, for video ?
14:22Caspy7padenot: wait, maybe directx 11?
14:23padenotwe've been using dx11 for some time, but maybe we've changed how we use it
14:24Caspy7well, it was a few months ago that they reported this, I don't remember which was nightly at the time, though it may have only been enabled on Nightly
14:24Caspy7for testing
14:26Caspy7padenot: I don't remember right now, it's not a huge deal, thanks for the info
14:33padenotjesup, are you not in the sec-bug group anymore ?
14:36Caspy7padenot: oh, and I wanted to note this comment from a new 55 user today saying that they've got a significant reduction in CPU when using Twitch at 1080p https://www.reddit.com/r/firefox/comments/6scsiu/firefox_notes_550/dlbtq3e/
14:37padenotCaspy7, cool !
14:38padenotthere are so many moving parts when in comes to playing a 1080p live stream on twich that I wouldn't know what made it better
14:38padenotor even if it's not a combination of things
14:38Caspy7"down from ~25% while watching a 1080p Stream on Twitch to ~ 12-15%"
14:38* Caspy7 nods
14:39padenotalways good the for morale to read something like this, though
14:39padenotso thanks !
14:40Caspy7
14:42Caspy7though apparently there is an issue with Firefox and twitch in 1080p. That user has to use an addon to force it. The other user replying to them why Firefox isn't getting it by default
14:42Caspy7presumably in comparison to Chrome
14:45padenotunclear, this is something that is either related to how the internet connection is estimated in chrome vs. firefox, or a twitch policy, or...
14:57* Caspy7 nods
15:15sheppyWorking to sort out the wording I need to put on the explanations about this going away to be sure I cover it accurately.
15:16jibyeah we should get rid of that
15:16sheppyThere are still open bugs to improve it in various ways, but none about just getting rid of it. :)
15:17jibI suspect s/LocalMediaStream/Mediastream/ in those bugs and close those that are fixed
15:18sheppyjib: probably
15:18sheppyhttps://bugzilla.mozilla.org/buglist.cgi?quicksearch=LocalMediaStream&list_id=13716398
15:19sheppyI think at least one of these, and probably two or all three, are either wontfix or already fixed.
15:50* sheppy can't figure out if we've ever actually used LocalMediaStream and if so when we stopped.
15:59jibAs far as documentation I would just remove it
16:00jib"Our testing suggests this is fixed in Firefox 38."
16:01jibclosed
16:02jesup(catching up...) fippo: nice work! https://addons.mozilla.org/en-US/firefox/addon/webrtc-externals/
16:05* mjf admires fippos addon ooohh...
16:05mjfNice!
16:06jesuphttps://webrtchacks.com/webrtc-externals/
16:28fippoits a hack :-)
17:48qDotAnyone around that's familiar with mediacache? I'm trying to figure out whether bug 1388125 is a problem on the file API side for the mediacache side.
17:48firebothttps://bugzil.la/1388125 NEW, nobody@mozilla.org Video elements with URL Object srcs pointing to large video files can hang content process on MediaC
17:52dmajorqDot: gerald should be around in 2-3 hours, if you don't find anyone else
17:52qDotdmajor: Awesome, thanks!
18:01ngjib: 1-1?
18:01jibyes! appear.in/jan-ivar ?
18:02jibsudo killall VDCAssistant
18:04ngjibbox $ _
18:04jibls
18:05ngNo space left on device.
18:24fippobwc: is there anything apart from media.peerconnection.ice.loopback set to true that i need to process and generate candidates from 127.0.0.1? it works in my normal profile but not in a selenium one and this puzzles me
18:27bwcfippo: Well, you might be running into the rtcweb ip-handling logic?
18:28fippohrm, i'll try that!
18:33fippobwc: no luck. and i dont see 127.0.0.1 candidates when using that profile which suggests something is not working
18:35bwcHmm. Might be that we lost that when we moved the interface gathering logic off of the content process.
18:36fippobut why would it work on my normal profile but not one created by selenium?
18:45bwcSo are there any other non-default values in about:config for media.peerconnection?
19:13jibjesup: So the number of proponents for the original discovery model of the getUserMedia API seem to be dwindling https://github.com/w3c/mediacapture-main/issues/466#issuecomment-321050942
19:14fippobwc: yeah, everything else is normal. will try to reproduce with a fresh profile
19:15bwcfippo: I really think you may be running into something related to ip-handling. You may have a persistent capture permission grant on your personal profile for the origin you're using, but the profile selenium created doesn't.
19:15bwcfippo: That changes which candidates are exposed to content.
19:17fippobwc: i've called GUM before but it was fake gum... does that not change which candidates are exposed?
19:17bwcfippo: That's an excellent question
19:18jibfippo: depends, have you granted persistent gum permissions?
19:18fippojib: on the normal profile: yes. i'll revoke them and see what happens
19:20fippolooks like bwc is correct
19:20fipporevoking the persistent permissions and using fake gum lead to ice failure
19:20jibthat makes sense to me
19:22fippoyes. so for testing i need to generate a proper profile with gum permissions
19:30jibfippo: you can set media.navigator.permission.disabled=true
19:31fippojib: i have that by default in webdriver (even though fake doesnt require it)
19:32* jib thought that would have helped, but could be wrong
19:38geraldqDot: Hi! I had noticed bug 1388125 in my inbox but haven't had time yet to look into it. Not sure what your question about "file API side" means. Anyway, from your profiling analysis in the bug (thanks!), my gut feel would be that the block-list algorithm may just be doing a lot of work: each block represents a 32KB portion of the resource, so a big file
19:38geraldwould mean dealing with lots of blocks; and the list of blocks is a deque, but the next/prev pointers for each block is kept in a hashtable, which would explain seeing lookups in the profiler... To be investigated! ;-)
19:38firebothttps://bugzil.la/1388125 NEW, nobody@mozilla.org Video elements with URL Object srcs pointing to large video files can hang content process on MediaC
19:39* gerald hunts for breakfast
19:49qDotgerald: Yeah, the weird part is, if we load this from a file url, there's no hang.
19:49qDotgerald: If we use <input type=&quot;file&quot;> and window.URL.createObjectURL, that&#39;s when things go bad. Hence &quot;File API&quot;.
19:50qDotWhat I was wondering if the blocklist is storing references that we have to fetch via the ObjectURL interface instead of direct file accesses, but that&#39;s a completely naive hypothesis of how any of this actually works.
19:51geraldqDot: Just replied in the bug: Local files bypass the MediaCache completely (as MediaCache&#39;s first function is to deal with the network), that&#39;s why they&#39;re not affected. ;-)
19:51qDotOh, well then.
19:52qDotSorry, just got in from a meeting and checked IRC before bugmail :)
19:52geraldno worries
19:52geraldI&#39;ll try to investigate this bug soon, it&#39;s quite &quot;interesting&quot; :-)
9 Aug 2017
No messages
   
Last message: 13 days and 9 hours ago