mozilla :: #media

11 Jul 2017
00:47kentuckyfriedtakaheSingingTree: does Chrome support media recording of H.264 in Matroska?
01:00jesupdrno: it was.... why do you ask?
01:02drnojesup: I cant get it to work. turned off e10s, set sandbox to 0. still files in /tmp/
01:02drnos/still/still no/
01:03jesupAh.... AEC logging, not AEC
01:03drnoohh yes :D
01:03jesupphew
01:03drnosorry about AEC logging
01:04jesupcheck with ng and dminor... I forget who did the AEC logging patch
01:04* jesup afk
01:04drnoalright. ng, dminor ^ ? :)
01:13ngdrno: ACK. I am not sure which AEC logging patch is in question, but I will take a look.
01:14ngdrno: OS X?
01:22drnong: yes on OS X
01:22drnong: well Im running 56.0a1 (2017-07-10) on OS X and cant get any log files
01:23drnong: do you know if e10s and/or sandbox problems are solved for the AEC logging?
01:23ngdrno: I believe pkerr fixed them, but the sandbox may have changed.
01:24drnong: thx
01:25drnong: I started bug 1379836 for it, although the title might be mis-leading
01:25firebothttps://bugzil.la/1379836 NEW, nobody@mozilla.org Hide "Start AEC Logging" button under e10s
01:28ngdrno: ok, thanks for the link. I'll update it with findings.
01:52SingingTreekentuckyfriedtakahe: Looks like they do
01:53kentuckyfriedtakaheFreaks
01:53SingingTreeThe args to specify it are a bit wonky, but example here: https://jsfiddle.net/SingingTree/8apqycL1/
01:53SingingTreeSeems to work in chrome
02:21jesupdrno: ng: this was the patch (by dminor) for the AEC logging: https://pastebin.mozilla.org/9026810
02:21ngjesup: thanks!
02:33dmajorkentuckyfriedtakahe: I'd subscribe to your video blogs :-)
03:27derfdmajor: Instead of filing your bug, I convinced them to give you an account with CC'ing privileges. Do you have a Google/GMail account you'd like to use?
03:27derfrillian: Same question.
05:21achronopchunmin: hi, do you have the time to review #337
05:23chunminachronop: yes, I'll do it today
05:23achronopthanks
05:24chunminSorry for the delay.
06:07rillianderf: I've been using my mozilla gmail account with aomedia: rgiles@mozilla.com.
06:08rillianso far I've gotten by with adding reviewers to poorly written patches, but I guess filing issues might be good too.
10:23jyakentuckyfriedtakahe: so I have HDR working with OpenGL, and the software compositor (for now I convert to 8 bits YUV). The single YouTube HDR file I got max out my quad core when using the software compositor. It only have time to display the first frame.
10:24kentuckyfriedtakahe\o/
10:25kentuckyfriedtakahejya: do you need someone to write SIMD?
10:28jyaIdeally we would need to adapt libyuv to work on uint16
10:29jyaPlus, I'm confused with the colorspace conversion. I can't make sense of what we are using for conversion coefficient (which is the same as what's on Wikipedia)
10:29jyaAnd our entire code assume everywhere Y is between 16-235, which isn't always true (if using full range videos)
10:30jyaThe video range with BT2020 is 4-1018
10:30jyaThere's so much tweaks to make the conversion fast for 601 and 709, it makes it impossible to adjust for another colorspace.
10:32jyakentuckyfriedtakahe: I've ordered the Hp laptop, should get here on Wednesday.
10:35robswain-Mhas anyone here started noticing that at least built-in facetime cameras stop working randomly and entirely in macOS?
10:35robswain-Ma few colleagues have experienced it but i never had until today
10:35robswain-Mit's not browser-related but seems to be OS-wide
10:38robswain-Mhmm
10:38robswain-Mkilling VDCAssistant fixed it for me
12:56Caspy7so...what happened to the H264 hardware acceleration line in about:support?
13:30jyaCaspy7: implementing it with the new remote GPU process was non trivial.
13:30mjfdminor: ping
13:31jyaWhen you run about:support you're in the main process. Not even the content one.
13:31Caspy7jya: so...if you have the GPU process you don't have h.264 HWA?
13:31Caspy7so detection is the issue
13:31jyaYou do. But the web page running in about:support can't synchronously query the GPU process.
13:31dminormjf: pong
13:31jyaThere's no mechanism in place to do that.
13:31Caspy7gotcha
13:32Caspy7jya: is it possible at all to detect if HWA in general is enabled?
13:32mjfdminor: is it possible to build and run the webrtc.org unittests that are in our tree?
13:32mjf(Ive made some local changes that I want to make sure still work)
13:32jyaOne way to check is installing the about:media extension. If in the decoder type you see RemoteDataDecoder ; then it's the GPU process one, and that only runs with HW decoding.
13:33dminormjf: yes, by running ./mach webrtc-gtest - it works easily on Linux, on Mac the build files are not in the place that the mach command expects them, and I'm not sure about Windows :)
13:33* dminor will now file the bug to fix them on mac
13:34mjfdminor: Thank you! I can easily move my patch to my linux box for testing this.
13:35dminormjf: np
13:37dminormjf: there are two known failures on Linux since 57 landed (bug 1374291)
13:37firebothttps://bugzil.la/1374291 NEW, nobody@mozilla.org VideoCaptureTest webrtc gtest failures
13:38mjfdminor: ah! Thank you for the heads up.
13:38jibI'm looking for help to triage bug 1379365
13:38firebothttps://bugzil.la/1379365 NEW, nobody@mozilla.org Intermittent TestNrSocketTest.PrivateToPublicConnectivityTcp | Value of: CheckTcpConnectivity(privat
13:38jibLooks like a crash?
13:38jibor is this normal test failure behavior?
13:40jibSyncRunnable ugh
13:40dminorjib: looks like an assertion failure to me
13:41jibbut the crash seems to be in RingbufferDumper::DumpRingBuffer_s ?
13:41jibcalled from MOZ_ReportAssertionFailure
13:42jibmaybe broken debug output?
13:45jibdminor: maybe p1 to fix the broken debug output? wdyt?
13:45jibor p2
13:48dminorjib: I'd say low priority p1 or high priority p2.
13:48jibwfm thanks
13:48dminorI guess we could check to see if any similar crashes are occuring in crashstats
13:52jibno hits
13:52jibmaking high p2
15:13jyaany ideas why attempting to open a webm link in my local central build would attempt to download it rather than play?
15:15jyaon windows that is... no such issue on mac and linux
15:35dmajorderf: my moco address is fine
15:36derfdmajor: Great, thanks.
15:36dmajorderf: though I really don't know what I'm doing. :-) whom do you want me to cc?
15:36derfdmajor: Jingning Han is the author of that experiment.
17:11kentuckyfriedtakahejya: isn't that a sniffer issue?
19:12dmajorderf: this is probably a good time to ask, what is monorail?
19:26derfdmajor: The AOM bug tracker.
19:27dmajorderf: where can I find it?
19:27derfhttps://bugs.chromium.org/p/aomedia/issues/advsearch
19:27derfWell, maybe that's not the best URL, but.
19:30dmajorok, thanks
19:38dmajorderf: say, this looks promising: /me tries to do some research be
19:38dmajoralso
19:38dmajorit helps if I paste the right thing
19:38dmajorderf: https://aomedia.googlesource.com/aom/+/52ece8844b0b1cedcad2afb116c7278f103af00e
19:40derfdmajor: Good find.
19:54dmajorkentuckyfriedtakahe: I missed your message earlier. What do you mean by "compiling with the wrong SIMDs"?
19:57kentuckyfriedtakahedmajor: I was referring to what libaom was doing as "compiling with the wrong SIMDs" in a managery over simplification as part of my dilbert principle
19:59dmajorkentuckyfriedtakahe: oh, you were asking if that was also occurring in libotherthing. gotcha. I didn't read carefully enough!
19:59* dmajor makes a note to poke at it
20:01kentuckyfriedtakahedmajor: basically I'm wondering if we're accidentally making vp9 decoding slower than it needs to be. we use two different libraries for that.
20:02dmajorkentuckyfriedtakahe: right.
20:26kentuckyfriedtakaheTD-Linux: are you going to have a squiz at the av1 demo glitching?
20:26TD-Linuxkentuckyfriedtakahe, I can. the gray squares are due to it referencing a frame that the decoder doesn't have
20:26TD-LinuxI suspect this may have been due to them incorrectly slicing up the webm file for dash
20:28TD-Linuxmay be easily "fixed" just by slicing out the offending frame.
20:28kentuckyfriedtakaheTD-Linux: can you advise them on the thread how to debug it?
20:28TD-Linuxyes
20:29kentuckyfriedtakaheta
20:37rillianTD-Linux: thanksf for taking a look. I was suspicious that it was happening at the chunk boundaries
20:38TD-Linuxso to be fair this is mostly unvalidated at the moment
20:39TD-Linuxare any non-default configuration options used for that particular git hash?
20:39rillianTD-Linux: supposedly it's the default build
20:39TD-Linuxok. I can try finding the appropriate chunk
20:40rillianI don't see how it could be sequential encode though. I started one June 29 and it's still not finished. They were able to turn it around faster than that.
20:40rillianoh, but I'm probably using --cpu-used=0
20:41rillian--cpu-used=1, that seems to be the default
20:43TD-Linuxthey are using cpu-used=8 I believe
20:43TD-LinuxI am struggling to find the exact commit mime type
20:43TD-Linuxit's not in about:media or the DOM
20:44rillianTD-Linux: https://github.com/mozilla/gecko-dev/blob/master/media/libaom/README_MOZILLA
20:44rillianor read their dash manifest
20:44TD-Linuxah it's part of the URL too
20:44TD-Linuxthanks
20:44rillianoh, right :
20:44rillian:)
20:46rillianTD-Linux: I still see the glitch when I concatenate segments
20:46rillianand play it as a normal webm
20:58rilliankentuckyfriedtakahe: are you setting up a webhost for us, or should I find something on my own?
21:00dmajorkentuckyfriedtakahe: these #ifdef SSE issues appear to be limited to aom/
21:01dmajor(I can't promise we're not messing up simd in other ways, though!)
21:02rilliandmajor: is that because libvpx doesn't have any post-sse2 asm?
21:02rillianno, it does...
21:03rillianbut it's guarded by the configure-defined HAVE_SSE41 instead of the __SSE4_1__ predefine
21:03rillianso yay, a recent bug :)
21:15dmajorheh
21:16TD-Linuxrillian, heh the answer was simple :)
21:16TD-Linuxsee email (hint: look at the text encoded at the top of the video...)
21:18rillianTD-Linux: good spottind
21:21* rillian can't type today
21:28rilliankentuckyfriedtakahe: I like how the office is gone, but I can still join the rangitoto vidyo room
21:45dmajorderf: what is 'cdef'?
21:45derfThe Constrained Directional Enhancement Filter.
21:46derfBasically, it's a filter that runs after the main decoding to clean up a bunch of the artifacts.
21:47dmajoris it reasonable for it to take 15% of decoding time?
21:47derfLast I recall it was around 8%.
21:48dmajorI have 4k/26k samples in av1_cdef_frame
21:48derfBut that sort of thing depends on the bitrate, etc., so maybe, maybe not.
21:49derfI think we're likely to land some major changes to it in the near future, though.
21:50derfhttps://aomedia-review.googlesource.com/#/c/10440/
21:51dmajorderf: also, we seem to be ping-pong-ing back and forth between two different threads doing decoding. is that intended?
21:52derfdmajor: I'm not sure. I've personally been pretending threads don't exist.
21:53dmajormaybe it's more a rillian question, I guess it could depend on how Firefox uses the code
22:08kentuckyfriedtakaherillian: http://www.bridgetonowhere.co.nz/
22:13kentuckyfriedtakaherillian: https://www.nzonscreen.com/title/goodbye-pork-pie-1981
22:40* ng forgot to change his handle after lunch.
23:04rilliankentuckyfriedtakahe: OpenBSD explainer is https://bugzilla.mozilla.org/show_bug.cgi?id=1370874#c16
23:04firebotBug 1370874 NEW, giles@thaumas.net Require Rust 1.18
23:04rillianfreebsd afaik works fine with rustup
23:57kinetikrillian: i was actually surprised how well/easy rust stuff worked on freebsd
23:57kinetikalthough the debugging is not great
23:59rilliankinetik: ah, good to hear.
23:59rillianJan has been very helpful maintaining the bootstrap stuff
12 Jul 2017
No messages
   
Last message: 12 days and 23 hours ago