mozilla :: #media

26 May 2017
00:37snorpcpearce: we should have varying policies depending on connection type and charging vs noy
00:40jesupcpearce: yes, ReleaseFrame releases the frame; actually it's recycled. Hmmmm. Let me check
00:41jesupand in fact we copy all the data out of it in Decode_g(), which is called synchronously from Decode(), so we're safe: // XXX It'd be wonderful not to have to memcpy the encoded data! memcpy(frame->Buffer()+4, aInputImage._buffer+4, frame->Size()-4);
01:37cpearcesnorp: Ok. I'll keep the existing behaviour for mobile and file a follow up to differentiate between connection type and charging status.
04:20geraldjya: Pinga
04:33cpearcemattwoodrow: does the GPU process run inside firefox.exe, or in a binary of some other name?
04:33mattwoodrowcpearce: Yeah, its firefox.exe
04:33cpearcemattwoodrow: any plans to move it out?
04:33mattwoodrowcpearce: Not that I know of
04:34cpearcemattwoodrow: ok, if you hear of any, please let me know.
04:46jesupcpearce: good catch; I'll fix the queuing
04:47cpearcejesup: Great, jolly good.
05:01jesupcpearce: It does allocate-and-copy: VCMEncodedFrame::VCMEncodedFrame(const webrtc::EncodedImage& rhs) {... VerifyAndAllocate(rhs._length + EncodedImage::GetBufferPaddingBytes(_codec)); memcpy(_buffer, rhs._buffer, rhs._length);
05:03jesupcpearce: Ugh, that's VCMEncodedFrame, not EncodedImage
05:03jesupI'll fix it
05:11* cpearce needs to do a daycare run
05:15jesupcpearce: if you're still around or come back - are you good with the patch other than that?
05:15* jesup crashes
05:45jyagerald: pong
05:49geraldjya: Yo! I was having some fun in MediaResourceIndex::ReadAt(), and found out that SourceBufferResource::ReadAt seems to be the only MediaResource::ReadAt that blocks if there's not enough data as requested (others give "up to" the requested amount). Thoughts?
05:53jyagerald: it can't have no enough resource.
05:54jyaIt's also never used on the main thread.
05:55jyaThe TrackBuffersManager add data to the resource that it knows can be fully demuxed.
05:56geraldjya: `ReadAtInternal(..., /* aMayBlock = */ true)`
05:57geraldjya: For more context, I'm adding a cache in MediaResourceIndex, so I'm trying to read more than what the caller wants; but then I hit this blockage in the mediasource case.
05:57jyaDoesn't mean the case can happen. It's used in a non blocking way by the MP4 demuxer which always check the amount of data available before reading it.
05:58jyaDon't cache SourceBufferResource.
05:58jyaIt's all ram based already.
05:58geraldjya: But it takes a lock, I'm trying to avoid that.
05:59jyaMy brain isn't fully operational yet. But I'm how many cage are we going to have?
05:59geraldjya: Anyway, I'm trying not to read past GetLength(), will see if that helps; otherwise I'll just not cache in the mediasource case.
05:59geraldjya: One small cache per MediaResourceIndex.
06:00jyaMediaResourceIndex is just a helper of MediaResource which uses MediaCache if needed.
06:00geraldjya: No worries if you cannot help me now, I'll keep exploring ;-)
06:00jyaWhy add an extra layer of cache on top of that?
06:00geraldjya: Right, but then MediaCache has locks and IOs, and I'm trying to make things better there; got some nice wins from my current attempt :-)
06:01geraldsince MediaResourceIndex is only used on one thread at a time, there's no locking needed
06:01jyaWouldn't it be better to improve MediaCache than adding yet another layer ?
06:01jyaLet's cache the cache!
06:01geraldjya: After discussing with cpearce, we thought MediaResourceIndex would be a better place
06:03jyaSounds weird to me, an just adding a workaround without fixing the actual problem (caching the cache). In any case You can remove all requirements for a lock in the SourceBufferResource. They are no longer needed
06:05jyaIt's only ever accessed on the same thread (own by the MediaSourceDemuxer)
06:27kamidphishbug 136646
06:27firebot WONTFIX, ability to query for changes to all files since a branch/rev tag
06:27kamidphishbug 1367646
06:27firebot NEW, Update cubeb from upstream to 4efb2e6
06:32jya15 years ago, someone wished for a proper CVS
06:38kamidphishjya: And yet here we are
06:44geraldjya: (sorry, didn't see your response) "You can remove all requirements for a lock in the SourceBufferResource" -- that'd be great to do anyway! Want to open a bug for that?
06:44gerald(and good news: Checking the GetLength() first makes my blocking issue go away)
06:45jyagerald: I'm fairly certain all demuxers checks with GetLength first.
06:45jyabecause at the time there were concurrent reads, it could cause deadlocks
06:45geraldmakes sense
06:46jyai don't mind removing the locks in SourceBufferResource (fairly certain we never exercise those code though), but by definition, a MediaResource is thread safe
06:46jyaso having SourceBufferResource be different than all the others could lead to issue somewhere. unless we change the definition of the MediaResource
06:50geraldbetter not change it then, if by contract it should be thread-safe
06:53jyawith MSE it doesn't matter it's always used on the same thread. within the TrackBuffersManager
06:54jyai only use it as a container really
06:54jyawhich can be truncated at the front
07:05geraldjya: So maybe there should be LockLessSourceBufferResource that only MSE can use; and if needed as a proper MediaResource, SourceBufferResource would wrap it with proper locking?
07:06* gerald heads home
09:32jyakaku: should have updated the commit message. as the function is no longer called Transit()
09:34kakujya: @@
09:34kakujya: anyway to stop the landing?
09:34jyanope... too late :) doesn't matter much anyway now
09:36jyayou could ask for a backout and reland... but for just the commit message, not worth it I think
09:38kakujya: yup......, sorry about the miss...
09:42bwujya: I am so sorry that I missed our meeting. (but maybe you have not noticed that.. :-) )
09:42jyabwu: I have.. but I'm kind of glad.. because I feel very crooked anyway :)
09:42jyabetter not have any human interactions for a while
09:44bwuGot it. Anthony told me you are sick as well. I was in a long meeting and just finished.
09:44bwuTake care.
10:19achronopchunmin: ping
10:25chunminachronop: pong
10:25achronopchunmin: hi, I am trying stereo cubeb capture on windows and does not work
10:26achronopany idea what is going on?
10:26achronophave you tried it lately ?
10:29chunminachronop: No. I haven't tried it. Does handle_channel_layoit work?
10:30chunminOh I was wrong. The code shouldn`t call i5
10:31achronopchunmin: if I use layout undefined it crashes
10:33achronopwith layout = stereo the sound is basted
10:34achronopI test using a modified version of test_duplex
10:35chunminachronop: Can I reply you later because I am on my way home. Sorry for that
10:38achronopchunmin: sure, sorry for bothering during your evening, I did not realize it
10:40chunminachronop: It's ok. It's not easy for me to trace code on smartphone. Haha.
11:02achronopchunmin: I found it, thank anyway
11:15achronopchunmin: the question I have is what is going on with undefined layout, is it expected and why does it crash?
11:16achronopbut no rush
11:59kamidphishNetflix Error Code: F7053-1803
11:59kamidphishNo Netflix for me
13:20chunminachronop: I found that the error is in cubeb_mixer. I'll fix it ASAP.
13:21achronopwhich error?
13:22achronopchunmin: ^
13:30achronopchunmin: if you need to test check my fix, I just created a pr
13:33chunminI found that downmix is called from stereo to stereo.
13:35chunminYes. I saw your pull! Thanks!
13:36achronopchunmin: what is going on with undefined layout in windows? is it valid to use it?
13:37chunminYes. It's allowed to use it when it's input.
13:38achronopdoes it cause any mixing when in use?
13:40chunminIt depends on channel counts. For undefined layout, we should call dowox_fallback when converting N channels to M channels, where N > M
13:41achronopchunmin: I thought we complare the channels count vs layout channels, is that correct?
13:46achronopchunmin: after the wasapi fix it works well with undefined layout
14:01chunminachronop: For downmixing, we compare the channel counts first. If the input channel couts > out channels counts, it's ok. If the input channel counts = output channel counts, then we check its layout. If its layout is from 3F2 to 2F2-LFE or 3F1-LFE then we call downmix_3f2. If its layout is undefined, then we will call downmix_fallback
14:01chunminI think I give you wrong message "downmix is called from stereo to stereo"
14:02chunminIt's not be called.
14:09achronopchunmin: that's great, I pushed a new try ... thanks for spending your evening with that
14:43jesup!seen cpearce
14:43firebotcpearce was last seen 4 hours and 54 minutes ago, talking in #auckland.
14:43jesuphmmm, weekend there
15:14jesupAll hail the new AreWeSlimYet:
15:44jesuppehrsons: ping
15:45* jesup shares the review load around... :-)
15:47jesuponly 45 patches on the bug for review so far! (and maybe one or two on other bugs)
16:05jesupI'm getting back into the pure conflict-resolution stuff, which needs less review
16:19jesupdminor: lunching. Still hoping to land Moinday or even maybe on the weekend
16:21jesupdminor: ng: pehrsons: drno|irccloud: updated queue
16:21dminorjesup: cool, I'm going through the reviews, just taking breaks when my eyes start to glaze over...
16:42ng jesup: thanks, looking at the new reviews
17:14jesupdminor: I hear you... I'm going through them all, merging and doing cleanup before pushing them. My eyes glazed over long ago ;-)
17:16jesupGrrr. H264 tests are still semi-orange, timeouts, mostly but not quite only on non-e10s. (Linux only, also)
17:17jesupI could swear I was green, but maybe it was a 'lucky' run (or better vm perf that time of night)
17:39mconleyrillian: ping
17:53drnojesup: do we really want assert crash Fx release?
18:06rillianmconley: hey. what's up?
18:06mconleyrillian: hey - for bug 1368075, are you experiencing this while in fullscreen?
18:06firebot NEW, location bar doesn't focus when new tab opens
18:07rillianmconley: I am!
18:07mconleyrillian: excellent, thanks!
18:07rillianmconley: I also just noticed that if I click the '+' button to make a new tab, the location bar does have keyboard focus
18:08mconleyrillian: also in fullscreen?
18:08rillianso just cmd+t in fullscreen mode
18:09rillianfunny, that's two fullscreen mac bugs since I got my new laptop with the smaller screen... :)
18:09mconleyrillian: thanks for reporting, anywho
18:09mconleya fix is in the pipe
18:13jesupdrno: which are you referring too? There's a lot of code...... ;-)
18:13jesupng: making some major fixes to stats reporting
18:13drnojesup: Im referring to RTC_CHECK_EQ and similar result in MOZ_CRASH
18:14ngjesup: ok
18:15drnoFrom the code I have seen the RTC_CHECK_EQ look to me like assert, which should crash maybe debug builds, or even Nightly and maybe Beta.
18:15jesupWe're running with RTC_CHECK's now; they're their equivalent to MOS_RELEASE_ASSERT. Remove them/switch-to-dcheck and you have to add error paths and the like
18:15drnoBut they dont look like they need to crash Release on purpose
18:16jesupIn most cases (and with most of the DCHECKs too) if they don't force a crash, you'll crash shortly after
18:16jesupand they give a pretty bright signature in crash-stats- and avoid someone being able to leverage into an exploit
18:17jesupIf there's on in a hot path you're concerned about, or something that should be a soft failure?
18:18drnojesup: not a special one. Its just that with simulcast I have looked at lot of them lately. And they are mostly about failing to enable RTP header extension etc
18:18jesupOpen to suggestions to make some soft fails
18:19jesupthough failures-to-enable seems like something nasty is wrong (so many extensions ran out of ids?)
18:19drnojesup: maybe you are right that it is good to have hard failures. I guess with e10s being it only a tab crash its even less anyoing to users
18:20drnoand we just need to be getting better in tracking these and fixing them quick
18:28jesupng: switching AudioConduit to use mChannelProxy->GetRTCPStatistics(); which has all the bits we want instead of GetRTCPReceiverInfo(). (We're still cheating on the timestamp, though)
18:28jesuplets me get rid of a lot of code we added
18:29ngjesup: that is great, it was really accreting
18:35jesupng: oh, feh, it has a thread restriction on it
18:37jesupwants to be called on MainThread, not SocketThread
18:37jesupironically, we bounce it to STS thread
18:41jesupng: I think I can move some of this into BuildStatsQuery_m, though
18:43* jesup wonders if I can move most of it to mainthread
26 May 2017
Last message: 4 minutes and 37 seconds ago