mozilla :: #media

6 Oct 2017
00:33jw_wanggerald: no particular reason, It is just less code not to add an entry to MediaPrefs.
00:33jw_wangthe merit of MediaPrefs is that it is readable off the main thread.
00:34jw_wangand MediaCache::Update() also read prefs without using MediaPrefs
00:34jw_wangso I want to be consistent.
00:38geraldFair enough, thanks.
02:43Caspy7here is a user asking if there's a way to control how much a video is buffered before playback begins
02:43Caspy7anyone know if there's a pref for that?
03:28jw_wangCaspy7: no such pref, we always preroll about 1s audio before starting playback.
03:29Caspy7jw_wang: thanks
03:29jw_wanginitial delay is bad for UX.
03:34Caspy7jw_wang: you think it should start playing initially? Shall a bug be filed?
03:34jw_wangCaspy7: no I mean our design decision is not to start immediately
03:35jw_wanginstead we preroll some amount of data to prevent underflow during playback.
03:35Caspy7ah, ok
04:22alwujya : ping
04:24alwujya : could you help me point out where is the mechanism, that MediaSourceTrackDemuxer could know whether its TBM is detached?
04:34alwuIn addition, we still need the change for [1] to avoid running task on non-task queue, right? because |!GetTaskQueue() | is not a correct checking criteria .
04:51cpearcedjg|kamidphish: ok, thanks
04:51djg|kamidphishcpearce: I see that you have linux passing but osx fails now.
04:52djg|kamidphishcpearce: Assertion failed: (stm->context->active_streams >= 1), function audiounit_stream_destroy, file gecko/src/media/libcubeb/src/cubeb_audiounit.cpp, line 2616.
04:52djg|kamidphishDid the stream fail to create or is it being double freed?
04:52* djg|kamidphish fires up the rMBP
04:53cpearcedjg|kamidphish: where do you see that? I see the latest MacOS build as queued.
04:53jyaalwu: give me 5 minutes
04:54alwusure, thank you
04:54jyaalwu: and no you don't need to change [1]
04:54djg|kamidphishcpearce: Travis on my version of gecko-media
04:54jyaOnTaskQueue() is only ever used to decide on what to do in TBM::QueueTask
04:54jyaeverywhere else it's only used in MOZ_ASSERT
04:55jyafollowing your change, a task can never be queued on the wrong task queue
04:57alwujya : yes, but the task would be executed after detach(), and it would break the assert (mTaskQueue=null) even the task might be run on the correct thread (but we couldn't verify that)
04:58jyathe only task that can get executed after a detach are GetSample / Seek / GetNextRandomAccessPoint right?
04:58jyathey all start with MOZ_ASSERT(OnTaskQueue())
04:59jyaOnTaskQueue() returns true if mTaskQueue is null, so that's covered/okay
04:59jyanow what would happen if you call GetSample() when mTaskQueue is null, the track buffers is empty.
05:00jyathe first test is if (!track.Length()) { aResult = NS_ERROR_DOM_MEDIA_END_OF_STREAM; return; }
05:00jyasame for seek and all the others
05:00alwulet me check
05:01jyaso while it's not explicit ; if the track demuxer ever attempt to use the TrackBuffersManager after a detach, every function will immediately fail
05:01jyareturning EOS
05:02jyathe reason we had the bug was because prior your fix, the detach queue could run on both the task queue and the main thread
05:02djg|kamidphishcpearce: Oh, it looks like we don't run the cubeb tests on travis.
05:02jyathe detach task running on the main thread, would cause a race with the potential GetSample/Seek etc...
05:02jyathat's no longer the case
05:02djg|kamidphishcpearce: For OSX, that is.
05:03cpearceOh hmm... Is there a good reason for that?
05:03jyaalwu: so if you want to be anal about it, and make the code more explicit, you can of course add an extra check to not call the TBM if it has been detached. But that's not a must to do.
05:03jyanow what I dont like with your implementation is that you're asking a dead object if its dead
05:04alwujya : ok, got it. I was confused before because I can't find the place you mention which would check the buffer length
05:05jyaand so this is dependent on how the TBM gets detached. If we ever change the TBM it could potentially break the MediaSource Demuxer
05:06jyathere's a mechanism in place telling the MediaSourceDemuxer that one of its TrackBuffersManager got detached. We should use that mechanism to avoid using that TBM
05:06jyaI find this far more elegant than checking a particular member of the TBM, relying on an implementation detail of a different object
05:07jyawhen the SourceBuffer is detached (
05:08jyathat calls the DetachSourceBuffer method (
05:11jyafrom the TrackBuffersManager being detached, you can retrieve that MediaSourceTrackDemuxer , and add a method to detach it too
05:11jyaand so rather than calling mManager->mTaskQueue to find out if mManager is usable, you rely on whatever atomic / thread safe method
05:12alwuwait, if I close the bug1247189, what else I need to do?
05:12alwunow MediaSourceDemuxer would remove the TBM after it detached, and then MediaSourceDemuxer won't access it anymore, the only place to access TBM is from MFR's MediaSourceTrackDemuxer. since we have the length checking for GetSample / Seek / GetNextRandomAccessPoint (), what is the actual problem here?
05:12firebot NEW, Null deref in TrackBuffersManager
05:12jyayou'll need to tell the demuxer that the source buffer is detached, *before* detaching the TBM. We must make sure that the task the MediaSourceDemuxer will use is uqueued before the detach task on the TrackBuffersManager
05:13jyaalwu: as I said, bug 1247189 is I believe fixed... you can check in the crash signature that it hasn't occurred since you push your fix
05:14jyaI'm not the one trying to fix it anyway :)
05:14jyaI'll be okay if you simply closed it with a link to the bug that fixed it
05:15jyabut if you want to be extra cautious
05:15jyaand prevent the MediaSourceTrackDemuxer to access the TrackBuffersManager after it's been detached
05:15jyathen I'd like you to do it by only using methods in the MediaSourceDemuxer
05:16jyaand not ask the TrackBuffersManager if it's dead
05:17alwuok let me think a while
05:25alwujya : ok, will commit new patch and ask for review later. Thanks!
05:26jyaalwu: great. does me rant above makes sense
05:26jyado you see why I want that it's up to the MediaSourceDemuxer/MediaSourceTrackDemuxer to handle the detach ?
05:29alwubecause is it more intuitive? telling all demuxer the TBM would be detached before doing TBM detach.
05:29jyayes, that too.
05:37jyakentuckyfriedtakahe: for fun with lightest nightly:
05:38* kentuckyfriedtakahe updates
05:39jyainteresting, chromium can't display VP9 profile 1 (YUV422 8 bits)
05:45jyaalwu: BTW, for the comments about the unused variable
05:46jyayou can also use DebugOnly<T>
05:46alwuok, thanks!
05:53kentuckyfriedtakahejya: \o/
05:54kentuckyfriedtakahejya: has green pajama stripes
05:55kentuckyfriedtakaheit must be encoded differently
05:59jyakentuckyfriedtakahe: is that a recent regression?
06:00kentuckyfriedtakahejya: yes but rillian can figure it out next week
06:01jyai mean is that following the 10 bis chnge?
06:04alwukentuckyfriedtakahe : the 1080p video on your link would not av sync (video would freeze and only audio, every 3s would happen once) on my mac with latest Nightly
06:05jyaalwu: what machine do you have? probably too slow and you&#39;re seeing keyframes
06:05alwuMacBook Pro (Retina, 15-inch, Mid 2014)
06:05jyaif decoding is too slow, we go from keyframe to keyframe
06:06jyathe 1080p is very CPU intensive
06:07kentuckyfriedtakahealwu: the current decoder is really slow so you can&#39;t expect higher resolutions to work
06:07bwuskipToNextFrame is triggered.
06:09jyaalwu: the decoder doesn&#39;t appear to make good use of multi-code
06:10jyaI see one CPU at 100% , on my quad-core, i still dropped heaps of frame toward the middle of the video
06:10jyaalwu: btw, the issue you described about only seeing frozen frame when your slow at feeding content, is the skipToNextKeyframe being triggered
06:35JamesChengcpearce: hi Chris, I don&#39;t know why I use test account No.1 , I cannot watch Star Trek Discovery. But I found using test account No.5 , I can watch it.
06:35JamesChengcpearce: But those works well on windows and mac.
11:43afilipwhois whimboo
11:55padenotpehrsons, ping
12:21achronoppadenot: how argent is bug 1316934?
12:22firebot NEW, Illegal access to system library
12:22padenotachronop, &quot;quite urgent&quot;
12:22padenotit&#39;s also not hard, just rebasing stuff
12:22padenotit blocking fennec folks for 58
12:32pehrsonspadenot: pong
12:32pehrsonsI&#39;ve been looking for you all morning ;-)
12:33pehrsonspadenot: did you see my comments and patch on bug 1406027?
12:33firebot ASSIGNED, input-only AudioCallbackDriver overchurns MediaStreamGraph
12:36padenotpehrsons, yes
12:36padenotpehrsons, for some reason my IRC client decided to disconnect me, but without telling me ;-(
12:36padenotnot ;
12:39pehrsonsnot using irccloud? :-)
12:39padenotmaybe I should
12:39pehrsonsmy test didn&#39;t work though, would webaudio not be affected I wonder
12:40padenotweb audio always use a mixer
12:40padenotbecause it always has an output
12:40padenotthat&#39;s what I wanted to tell you
12:40padenotyou need to replicate the test-case
12:40padenotand do the recording and the analysis in two separate steps
12:41pehrsonsah, cool
12:42pehrsonsyeah, just tested in
13:03padenotpehrsons, at some point, i think you told me you wanted to make the MSG MediaStreamTrack centric and not MediaStream centric, did I dream that, or did you really say it?
13:04pehrsonspadenot: you heard it right
13:04padenotit&#39;s a good idea
13:05pehrsonsjib also opened a bug about it a long time ago
13:08padenotplease explain all the benefits when you have time
13:09padenotI think we have other priorities for now, but it&#39;s always good to have some docs
13:15pehrsonsyeah I haven&#39;t had time to think about it too much, but I think it would simplify MSG quite a bit
13:20pehrsonswhat I need to figure out is whether the grouping of tracks into streams *inside* MSG is actually required by any api we have
13:22padenotpehrsons, in any case, these days, are the principal info on the track, the stream ?
13:22pehrsonspadenot: in main thread and media chunks
13:22pehrsonsso tracks, not streams, as far as MSG is concerned
13:23pehrsonsDOMMediaStream also has principal info but it&#39;s the combination of its live tracks
13:25padenotthere is the principalchangelistener on the MediaStream, though, how does that fit in ?
13:25padenotcontext, I&#39;m having french students implement MediaStreamTrackAudioSourceNode
13:25padenotwhich is exactly like MediaStreamAudioSourceNode, but takes a track and not a stream
13:27pehrsonspadenot: so the MediaStream looks at principal changes on the tracks and updates its principal accordingly
13:27pehrsonspadenot: if they&#39;re doing a track source they should just look at the track principal
13:28padenotthat will come later
13:28padenotfor now, they&#39;re doing the webidl bits, and compiling gecko, and understanding the various concept at play, etc.
13:29pehrsonspadenot: the MediaStreamTrackSource notifies the track of a principal change at the source first on main thread. At that point the principal of the track is changed to the combination of the old and the new principal. When chunks arrive on the msg thread with the new principal, the track will update its principal to the new one.
13:30pehrsonspadenot: so they&#39;ll need and
13:30padenotthat&#39;s great info, thanks
13:37jyaalwu: it happened again: so the theory that it was detached on a different thread than the task queue isn&#39;t the reason
14:09padenotpehrsons, hopefully it fails this time!
14:10pehrsonspadenot: yah, I tested that the test records distorted audio when using a non-default device, so hopefully it doesn&#39;t pass by accident on linux :-)
14:21padenotpehrsons, how about directly calling into AudioMixer with a stack buffer so we save a few allocs ?
14:22padenotah no
14:22padenotit should work maybe ?
14:23pehrsonspadenot: I&#39;ll note it, I&#39;ll have to check on monday
14:42pehrsonspadenot: it&#39;s already on the stack no?
14:43padenotpehrsons, sorry I mean the segment
14:44padenotpehrsons, I think you&#39;re right
14:44padenotmaybe not
14:45pehrsonspadenot: it&#39;s null data though, so the segment shouldn&#39;t allocate more than the class
14:46padenotthis allocates
14:46padenotbecause it&#39;s an nsTArray (vs. AutoTArray)
15:12jibpadenot, achronop: I&#39;m concerned we have two reports about static noise buildup and cpu use, bug 1404244 and bug 1405893. The first one is jsut with webrtc-landing. Can either of you own those to try to repro and follow up with reporters of both bugs to see if we can get the necessary info to repro?
15:12firebot DUPLICATE webrtc poor sound quality, too noise
15:12firebot UNCONFIRMED Increasing static noise makes WebRTC-based apps unusable in Firefox (CPU uptick 80%)
15:14achronoppadenot, jib : I can
15:14jibok thanks!
15:15padenotjib, this is known and captured in the document
15:15padenotjib, first paragraph, &quot;resource usage over time (= resource leaking)&quot;
15:15padenotI mean, to be honest, it&#39;s been the case for ever
15:16jibWe have poor communication then. These reports sound like severe regressions
15:16padenotsometimes we regress it, sometimes we make the situation better
15:16padenotjib, to me, it means that people are starting to use firefox for their webrtc app
15:17jibWe need to get regression ranges from these reporters, or repro ourselves. We have to assume the worst here, and respond
15:17jibThis is the exact thing that burned us in 56
15:18jibWe need to get better at jumping on these. The first bug was filed 7 days ago
15:18jibI would love to think this is not a major regression, but it smells like one, and we need to assume so until we can find evidence otherwise
15:20jibI&#39;m going to post a comment in both bugs to have them test 55
15:24padenotjib, also, the reason this took 7 days is because it was misfiled
15:24jibpadenot: Good point. Yeah that&#39;s out of our control sadly
15:26padenotit&#39;s not
15:27padenotthis problem is endemic
15:27padenotbugzilla is just not approachable
15:27padenotwe should fix it
15:27jibexcept bug 1404244 got triaged to us 7 days ago AFAICT
15:27firebot DUPLICATE, webrtc poor sound quality, too noise
15:28padenotjib, right, I misread
15:28padenothowever this report is of very low quality
15:28jibthere are two bugs, one got misfiled
15:29jibyes we need to turn them into high quality
15:29padenotyeah the first one is not actionable, besides what we already know and have planned to fix
15:29padenotthe second one is a bit better, but still we can&#39;t do much
15:30jibhaving two bugs filed increases the odds of a 56 regression I think
15:31padenothowever, it&#39;s not something we can fix
15:32padenot56 is current release
15:37jibIf it&#39;s in 56 it&#39;s in 57, and we may be able to fix that
15:40jibWe do have email threads going with a couple of companies, like with the Hangoouts team atm, but they&#39;re not having audio issues. I&#39;m not aware of one with Twilio, but will check with nils when he comes in. Mostly, per-site issues have tended to be network related
15:43jibthis may be network as well. It&#39;s not clear if the cpu issue is network related and merely causing the audio static, or if the audio stack is causing the cpu problem
16:56jyagerald: what&#39;s the good way to report issues for the media devtools?
17:00bwukentuckyfriedtakahe: jya: are you in SF office?
17:00jyabwu: not yet, in about 45m-1h
17:07bwuok. My flight is 1:40 PM, so I will not go to office. Just thought if you too are in the office, we can sync up some things.
17:09bwus/you too/you two
17:12jesupjib: note that twilio said they see it with This report strikes me as odd, though I&#39;d like to know why he&#39;s affected. Perhaps some 3rd-party thing? Certainly we haven&#39;t seen that, and if it was common we&#39;d see it and/or hear more than we&#39;re hearing
17:17fippomight just be &quot;apprtc is neutral/google territory, its not my fault&quot;?
17:35jibdrno knows people at twilio, said he&#39;d reach out
17:36jyakentuckyfriedtakahe, bwu : my stuff is taking longer than expected
17:39kentuckyfriedtakahejya: you mean going to Apple?
17:40jyaAfter 1h wait, I&#39;m told they don&#39;t have it in stock, but can go to another apple store 2.7mi away to get it replaced
17:40jyaThey had told me 15m at first.
17:40jyaWell, I did some reviews while at it, internet is good :)
18:33drnojib, padenot: twillio is testing for the information you asked for as we speek
18:37jyaWell, that is service. Replaced it for free because of the inconvenience of having to pick it up at another Apple store
18:39bwukentuckyfriedtakahe: jya I am hearing to the airport. See you next time!
18:39kentuckyfriedtakahebwu: ok. spot you later
18:41jyabwu: oh that early :( sorry I couldn&#39;t say proper goodbye
19:11jyakentuckyfriedtakahe: I&#39;ve arrived. Still on the 7th floor?
19:12jyaThere&#39;s lunch here
19:14kentuckyfriedtakahejya: yes. I&#39;m on the 7th floor
19:24jyaok.. let me find how to get there
19:44ngripgrep is crazy fast
20:30mjfng: wow that is really fast
20:31mjf20X is not a small diff
20:33ngmjf: I installed it via `cargo install ripgrep`, if you are interested in trying it out.
20:34mjfng: sweet - I will do that.
20:34DuClare_Yep it&#39;s awesome for grepping in large source trees
20:34drnodear mozreview why do you claim that I have remembered a file already, when Im looking at revisions of a file which I have not reviewed. argh
20:34ngI love that it is making good use of my cores
20:35drnong: is it getting cold down there in the south? ;)
20:35ngdrno: heh. I have a picture of people taking pictures of frost on the grass last year, so that might tell you how cold it gets here.
20:36ngpeople start putting on parkas at ~60 F.
20:36drnong: here is another option to create heat: leave your Mac after a software update running without completing the last steps after reboot
20:37drnong: I bet they turn on the heated seats at 70F
20:37drnomy laptop was really hot this morning, after I forgoto complete the login/update last night
20:37ngThey definitely start up the patio heaters in the 60s.
20:38drnono idea what the cores were doing all night long but they were busy
20:38mjfng, drno: parkas in the 60s. :-) People are still water skiing here in the 60s.
20:39drnomjf: you are more like Britain where people start running around in short when its above 50
20:39ngPeople buy &quot;snow clothes&quot; for their kids for the weekend that Sea World turns on some snow machines.
20:39drnothat is the one thing I appreciate about the bay area: t-shirt weather all year long
20:40mjfWell, we have t-shirt weather year round too. You just dont want to dilly-dally on your way from the house to the car. ;-)
20:40ngHow many t-shirts have you wrapped your self in?
20:41mjfBut you know, that brisk walking really gets the blood pumping!
20:41nguntil it freezes.
20:41mjfng: you wrap the t-shirts into small bundles and pack your parka with them for extra insulation.
20:42mjfOr as my friend says, Oofda, its a little chilly today. Looking at the -20F reading on the thermometer in Jan/Feb.
20:43mjfThe real positive there is staying up while water skiing is so much easier at that temp.
20:44mjfYou just need to remember to dodge the people ice fishing.
20:44ngThat is only -28C, you don&#39;t have to worry about the CO2 freezing out for another 40.
20:45ngSo pretty much 1/2 between the freezing point of CO2 and t-shirt weather.
21:10geraldjya: I see you found a way to report the media-devtools issue. Thanks, I&#39;ll have a look...
21:21jyagerald: yeah, not sure if that was even the right project
21:21jyabut seeing that you had committed there recently
21:26jesupjib: ping - you saw the comment in bug 1405893 (audio)? not a regression, which is even odder. Also why they&#39;re seeing it (now?) and no one (?) else has
21:26firebot UNCONFIRMED, Increasing static noise makes WebRTC-based apps unusable in Firefox (CPU uptick 80%)
21:27jibjesup: that is indeed odd
21:28jesupmac (laptop I presume) + HD video may be a hint
21:29jibwell they claim this happens on so I&#39;m not sure how that&#39;s HD
21:29jesupHD video over non-local links is less common. Wonder if they&#39;re sending full-HD, and after ~ 3 min (on a LAN) it gets up to full-HD i.e. LOTS of cpu for encoding
21:29jesupand it&#39;s causing audio underruns/etc
21:29jesuppadenot: ^
21:30jesupcould ask them in a FF<->Chrome call to watch webrtc-internals for bitrate and size (sent and received)
21:31jesupAlso note that things like fippo&#39;s extension, if installed, might warp the results (IIRC drno mentioned that coudl happen)
21:31jyakentuckyfriedtakahe: the video I was telling you about:
21:32jyajesup: is video encoding and audio decoding on the same thread?
21:32jesupvideo encode is on it&#39;s own thread
21:32jesupwebrtc has Many Threads
21:32jyawhy the buffer underruns due to video encode (assuming multi-threading works properly)
21:34jesupprobably because ETOOMANY threads active. I also don&#39;t remember if the libvpx encoder uses multiple threads by default. And these are mac presumed laptops -- if not 15&quot; (i7), they have max 4 cores IIRC. If MacBook non-pro - 2??
21:35jesupbut without a trace hard to be sure (or log)
21:35jibIt does sound like they have calls with a mix of browsers: &quot;The problems happens only on Firefox end&quot;
21:35jesupit it&#39;s repeatable, an Instruments trace should be easy
21:35jesupand it supposedly is repeatable
21:36jesupbut we use it on mac for (long) calls All The Time, without seeing this
21:36jesupso something is odd
21:36drnoIll try to repro here between Mac (Fx) and Win (chrome)
21:37jibThis does remind me of the weekly calls weeks ago where my CPU went real high. Haven&#39;t seen that in a while though
21:38drnoYes I also noticed that for the whole week my CPU fan hasnt kicked in as much as it used to the last several weeks
21:39drnoI wondered if the video freeze on the receiver side caused CPU usage to go up?
21:45jyaTD-Linux: I can&#39;t find z.Img on github liked you showed me :(
21:45TD-Linuxnote you can also build ffmpeg with it and use it instead of libswscale
21:46jyawhat&#39;s the difference with this one?
21:46jibdrno: we should have them try 58
21:47TD-Linuxthat one is an unrelated project
21:48TD-Linuxjya, on closer inspection, it looks like there&#39;s no NEON, so it may not be able to completely replace libyuv as-is
21:48jyaTD-Linux: yeah, was just looking at that, seems to be only AVX2 optimised
21:48jyaso very recent machines
21:49jibdrno: didn&#39;t we uplift the video freeze fix to 57?
21:49jyaah no, i see others
21:49jyatoo tired today
21:52TD-Linuxyeah. afaik the only other option is libswscale. but that&#39;s it&#39;s whole own can of worms.
21:57jyacan always use that one :)
22:13TD-Linuxoh right there&#39;s also vf_colorspace which is newer. it only converts, no scaling. but it may also be handy as a reference for correctness
22:14TD-Linux(written by BBB)
22:16TD-Linuxbtw the 10 bit ogl patches that landed work great on linux too :)
23:01jyaTD-Linux: that&#39;s where I first started to write/test it
23:11drnojib: video freeze patch should be in 57
23:11drnojib: but not in 56 yet
23:11jibright and may never be
7 Oct 2017
No messages
Last message: 10 days and 14 hours ago