mozilla :: #media

17 May 2017
00:15Caspy7can anyone verify this in regards to H.264? "most videos online use the "High" profile"
00:16Caspy7I'm writing something and was hoping for a fact check :)
00:19rillianCaspy7: that's a resonable, but not very precise statement.
00:20Caspy7rillian: well, this isn't for a paper :) How about "it is the most commonly used profile"?
00:29jesupCaspy7: I'm not the expert (jya or cpearce perhaps), but that sounds reasonable
00:49Caspy7thanks
01:09cpearceI thought we had telemetry to confirm that.
01:12cpearceCaspy7: our telemetry https://mzl.la/2pUJW3C shows that about 80% of H264 that Firefox beta encounters has profile 77, which is main profile, see http://blog.pearce.org.nz/2013/11/what-does-h264avc1-codecs-parameters.html for profile levels. 100 is high, and it's about 12%.
01:13Caspy7cpearce: thanks!
01:17Caspy7cpearce: so I'm guessing youtube uses Main then?
01:18cpearceCaspy7: On most modern computers it would deliver WebM.
01:18Caspy7well, I mean when it's not using webm
01:19Caspy7I'm guessing 66 on that chart is baseline?
01:19Caspy7oh, I think it's in the list on the blog
01:19Caspy7yeah
01:20cpearceCaspy7: If i turn off WebM, YouTube is giving me high profile
01:20Caspy7ah, dang, gave wrong facts
01:22Caspy7ok, edited
01:22Caspy7thanks for the information guys!
01:33bwukentuckyfriedtakahe: meeting?
01:34kentuckyfriedtakahesure
01:57kinetikkamidphish: kft is in rangitoto so i'll call you direct at 2
01:58kamidphishkinetik: Roger
04:06Caspy7got someone in #firefox asking how they can make Firefox prefer their Nvidia GPU over the integrated one
04:06Caspy7any input?
04:31auenf2Caspy7, optimus?
04:34Caspy7auenf2++
08:39pehrsonsjw_wang: ping, still around?
08:48jw_wangpehrsons: yes.
08:49pehrsonsjw_wang: cheers, I have a question on MozPromise
08:49jw_wangyes?
08:49pehrsonswhen chaining, I cannot change the type of the returned promise?
08:50jw_wangno. It is not like JS.
08:50pehrsonsRight
08:51pehrsonsIt would have been nice to be able to reduce an AllPromiseType
08:51pehrsonsI'll work around it for now
08:51jw_wangI wish I could do that because it is useful to chain promises of different types.
08:52jw_wangso it feels more like a JS promise.
08:53pehrsonsc++ limitation?
08:56jw_wangI think there is a way around it.
08:57jw_wangsince C++ is a strong typed language, you can't store different types in a container.
08:57jw_wangyou need some tricks like type-erasure and downcasting to create a heterogeneous container.
08:58jw_wangVariant<> is a heterogeneous container.
08:59jw_wangneed to go now.
08:59pehrsonsright
08:59pehrsonssee you!
13:05mreavyachronop: ping - is now a good time to talk?
13:06achronopmreavy: sure, heading to your room
13:48jesupthe talk will be recorded
13:52jesupsoft freeze
14:26mjfjib: ping
14:27jibmjf: pong
14:27mjfWell, sadly, our nifty move trick for the RefPtr still breaks windows builds.
14:29mjfI finally got to start a good try run after all the infra breakage from yesterday, and I got windows bustage:
14:29mjf14:21:18 INFO - z:\build\build\src\media\webrtc\signaling\src\peerconnection\peerconnectionimpl.cpp(2367) : warning C4172: returning address of local variable or temporary
14:29jibgah
14:29mjfI think were just going to have to deal with a temporary ref cnt bump.
14:29mjf*sigh*
14:30jibmjf: is the line it&#39;s complaining about the RefPtr<>(nullptr)?
14:30mjfyep
14:30mjfwell, return Move(RefPtr<>(nullptr));
14:31mjfWhich I suppose makes sense given what were asking it to do there.
14:32gregcrankwhen i enumerateDevices in chrome I see audiooutput devices. firefox only seems to list input devices
14:32gregcrankany ideas why?
14:34jibmjf: it&#39;s a bit of a hack, but you could keep a single static instance
14:34jibin the class
14:35jibthat should work
14:37mreavyjib: ping -- sorry for the delay. Is now a good time to talk?
14:37gregcranki&#39;m trying to use setSinkId, but need audiooutput devices.
14:38gregcranki guess firefox doesn&#39;t support that anyway
14:39gregcrank*bangs head*
14:40jibmreavy: sure, be right there
14:46mjfjib: That seems like a lot of hack just to avoid an rarely used testing method that increases the ref count for a very short time.
14:51jibmaybe
15:57pehrsonsgregcrank: right, we don&#39;t support changing sink yet, so we don&#39;t enumerate output devices either
16:03gregcrankpehrsons: makes sense. thank
16:03gregcranks
17:55dminordrno: the dtmf bug is Bug 1364900
17:55firebothttps://bugzil.la/1364900 NEW, nobody@mozilla.org Received DTMF tones was not played for OPUS 48kHz
17:56drnodminor: thx
17:56dminornp
19:10jesupdrno: ping
19:10drnojesup: pong
19:10jesupdrno: bug 1338521 - where do we stand? We&#39;ll need a fix soon if we want to uplift to 54
19:10firebothttps://bugzil.la/1338521 NEW, rjesup@jesup.org Video fails to appear (or freezes?) after refreshing page during a Jitsi call
19:11jesupgot pinged in the regression triage today
19:13drnojesup: so Im trying to write code which ensures that the PTs are unique, but I get distracted by chrash bugs
19:13drnojesup: I think we agree that we should land the one fix we have in the ticket already
19:14drnojesup: and then we can handle unquie PTs hopefully as a separate item, and see how the timing works out?
19:14jesupdrno: so if we land the fix there, how much of this problem in practice does this fix?
19:16drnojesup: well the problem remains that we/I still dont understand when or how we get into the assertion on destroy
19:16drnobut my theory is that the assertion is only a fraction of the problem here
19:16drnothe good news is that at least for the assertion we can now monitor it in crash stats
19:17drnoif jitsi sends us stray/old RTP packets it can easily confuse us right. so my hope is that unique PTs are going to help us with that.
19:18drnobut the be fully honest I dont think that we fully fix all Jitsi related issues in 54
20:02drnomjf: ping
20:02mjfdrno: pong
20:53jesupMOZ_LOG=signaling:5,jsep:5,rtplogging:5
20:53jesuppaulej: ^
20:55paulejack
20:59drnopaulej: you are right. I forgot to kick a try run an bug 1361206. Running now. Will land later today
20:59firebothttps://bugzil.la/1361206 NEW, drno@ohlmeier.org RTP Header Extension IDs in Offer/Answer Exchange
21:00paulejthans
21:00paulejthanks
22:01jesuperahm: You missed a bunch of PR_LogPrintf&#39;s in netwerk/sctp/datachannel/DataChannel.cpp...... :-/ I&#39;m fixing it. (Broke packet logging for SCTP)
22:13erahmjesup: bah, sorry :(
22:13erahmjesup: I wonder why I didn&#39;t catch them? I think I was mostly searching through dxr, I wonder if they&#39;re ifdefed?
22:13jesupyou might want to check the rest of the tree. Likely ok, but rarely-used logs might be missed
22:15jesupnope, not ifdefed
22:15jesupI wouldn&#39;t trust dxr for a tree-wide replacement myself. There are patterns of stuff (as you mention) it might miss (even if it&#39;s bug-free)
22:16jesupI&#39;ve always used scripts (and put them in the checkin message) similar to tree-wide changes done by others such as ehsan
22:17jesupor you can put the script in an attachment on the bug
22:17erahmjesup: oooooh it&#39;s direct usage of PR_LogPrint, not the macros
22:17jesupyes
22:17jesupsome people do that
22:17erahmthat&#39;s on you man :P
22:18erahmI would&#39;ve expected build failures though
22:18jesupespecially if they are in code that tests the debug flags because there&#39;s code they don&#39;t want run if it&#39;s off
22:18jesupPR_LogPrintf is still there apparently
22:18jesupLikely works if I use NSPR_LOG_MODULES
22:19erahmjesup: well I removed the prlog.h included from mozilla/Logging.h and removed all PR_LogModules, so you&#39;d have to #include prlog.h directly
22:20jesupit uses lazylog now, and you converted it to MOZ_LOG_TEST -- just not the call following it
22:21erahmyeah so, it&#39;s not broken per se
22:21jesupactually mcmanus/gosu did
22:22erahmhah!
22:22jesupthey converted netwerk to LazyLog; so it might kinda be their bug
22:22jesupbug 1219466
22:22firebothttps://bugzil.la/1219466 FIXED, mcmanus@ducksong.com Replace PRLogModuleInfo usage with LazyLogModule in network/
22:22jesupstill, worth checking for other PR_LogPrintf&#39;s
22:23erahmjesup: so yeah it&#39;s probably worth filing something for the remaining PR_LogPrints, but it&#39;s going to be pretty low priority since nothing is really broken.
22:30jyarillian: ffvp9 supports all profiles.
22:42rillianjya: great
22:50jyarillian: who wrote the vp9 in mp4 spec?
22:51rocplease get rid of the PR_LogPrintfs since they don&#39;t work with rr replay-only logging :-)
22:58jyarillian, alfredo : ffmpeg folks tell me that since they updated the vpcc box to be up to the final version (1.0) of the vp9 in mp4 box, we no longer play the file they generate
22:59rilliankentuckyfriedtakahe: https://github.com/rust-lang/rust/issues/40460
23:04rillianjya: some folks at netflix threw something up on github
23:04jyabug 1365787
23:04firebothttps://bugzil.la/1365787 NEW, nobody@mozilla.org vp9 in mp4 files generated by latest FFmpeg don&#39;t play
23:05rillianthanks, jya
23:06jyarillian: their specs don&#39;t make much sense:
23:06jyabox type &#39;vp_xx_&#39; where &#39;xx&#39; is one of &#39;08&#39;, &#39;09&#39; or &#39;10&#39;
23:07jyaso the box type name is 6 bytes long?
23:07jyahow do they manage that with mp4?
23:08rillianjya: that&#39;s bizarre. maybe the _ are substitution quotes?
23:08rilliani.e. it&#39;s vp09
23:09rillianyes, look at the syntax boxes
23:09rillianinteresting that they&#39;ve still got vp10 in there
23:12jyaindeed
23:12jyarillian: you may want to join #ffmpeg-devel
23:12rillianas you say, at least the box is properly versioned. Does the &#39;unknown vpcC version&#39; error make it to the console?
23:13jyavp10 was mentioned there too, and I mentioned that we&#39;ve added av1 support to our playback
23:13jyakind of complaining about that :)
23:14jya&quot;supporting decoding today already just encourages idiots to start spreading files, and they&#39;ll be around for e ver and haunt us =p&quot;
23:37kamidphishrillian: If you have a chance to look over the rust-style for the changes I made to https://github.com/djg/cubeb-pulse-rs, I&#39;d appreciate it. I&#39;m not super happy with the callback wrapping limitations, but, eh.
18 May 2017
No messages
   
Last message: 7 days and 15 hours ago