bryce: can you rubber stamp my mochitest for the YT bug please? I'd like to nominate the fix uplift in the next dot release

kinetik: or you can do it: phabricator.services.mozilla.com/D18762

jya: done

drno: thanks!

jya: were you and padenot able to determine if we have a cropping issue in 65?

drno: not yet, but the last report showed smething I can exercise here

and it was to do with h264

it may be that the issue is the same regardless of the decoder used

bug 1525286 reports the same

like somehow the resolution of the image coming out of the decoder isn't used

and it use instead the resolution as the decode method gets (which is given by webrtc.org and is typically wrong)

jya: do you have another bug I can link 1525286 to?

in that report, they were using h264. Paul was using vp8, but on a machine with hardware VP8, so not your usual libvpx decoder

i was referring to bug 1525286

1525230 is another one

also h264

I'll have a look later.

sotaro: ping

CosminS|sheriffduty, pong

drno: I think I see what the problem could be

we only check content change on video frames marked as keyframe

but sometimes they aren't marked at all

or more accurately, we use the keyframe flag as reported by webrtc.org

if that's wrong, we will misbehave.

I don't know if that's the reason mind you, but looking at the code it could be

drno: whenever I pause my current firefox with the debugger (to check the decoder) and resume, I get a crash on resume

new state is TS_ERROR and the previous state (state_) is also TS_ERROR

jib: don't you have a nice promise/await pattern for "iceConnectionState is connected or completed"?

yes, this would definitely benefit from that, but it would still time out, unless we rewrite the test to expect the event within a certain envelope

wpt has shit helpers though so let me look for what we've done in the past here

github.com/web-platform-tests/wpt/b…on-track-stats.https.html#L606-L622 - i looked at that but... too many lines

(also i wasn't asking about a specific bug?)

fippo: ah sorry, wrong window :-P

await new Promise(r => pc1.onsignalingstatechange = () => pc1.signalingState == "stable" && r());

bwc was asking me about connectionState at the same time in a different thread :-P

I'm using that pattern in blog.mozilla.org/webrtc/rtcrtptransceiver-explored

that was what i remembered. thank you!

pehrsons, you're back, do you want me to handle 1521577, or are you going to do it ?

jya: have you seen the issue where the audio plays but it shows an old frame of the video as well as buffering spinner? I've seen this on YouTube.

Who will win, my Windows build which has been running since before the dawn of time, or WebRTC during standup? Let's find out

all, was my audio late during the standup ?

padenot: I didn't notice any audio delay.

Correct what I said on implementing a trait on the other trait: It can work. bryce told me it it's possible to implement `Debug` on `MyTrait` by `trait MyTrait : Foo`. Here is an example I used: play.rust-lang.org/?version=stable&…st=9832f58ca6db9f6e6c597f7dfead994c

padenot: It sounds normally no my side.

s/`trait MyTrait : Foo`/`trait MyTrait : Debug`

ok good

padenot: AFAIK pehrsons is out sick today, so if you could request the uplift for 1521577 that would be appreciated

yep I was doing that now after having seen him sick in the standup notes

padenot: your audio was fine for me

cool

achronop, maybe it was something on your end ?

yeah probably

actually I had the sense that your video was early

and the audio was ahead

something that we haven't seen so far

video was late and audio ahead ?

or something

you can't have two things ahead

but the resolution was bad and it was not easy to say for sure

hmm what did I say

right video was late

jya: I think that is to be expected. If you stop in the debugger while ICE and DTLS are setting up the connection timeouts will fire once you continue and things will have timed out

drno, done

achronop, ok

drno, ping

padenot: just grabbed headphones :)

superb, joining your room in a sec

it's very slow to connect

I don't know what's up

do we have telemetry data that can show the the percentage of the audio/video files format used in Firefox? or how many times a specific file format is played in some period ?

I want to implement a fingerprinting page using MediaCapabilities... I'd like to enumerate all the codecs a user supports (and if they're hardware accelerated.

Does FF whitelist only certain codecs; or if I have installed uncle-achmed's codec would that be used if the video specified it?

gerald: I'm trying to get logs out of the MoofParser: searchfox.org/mozilla-central/rev/e…b5e/dom/media/mp4/MoofParser.cpp#19 and am surprised to not see them logged. I figure I should switch the code to the decoder doctor logging, but am wondering if you know why I'm not currently seeing logs with MOZ_LOG?

tjr, we're very strict about exposing codecs to the web

tjr, with a whitelist approach

more or less: theora, h264, vp8, vp9, av1

and audio would be mp3, vorbis, opus, flac, wav

tjr, jya will wake up in a few minutes/hours, and will be able to tell you everything you need about all that, and he's the one who implemented MediaCapabilities

padenot: Oh that's good to hear! What would I need to do to button down the 'more or less' into exactness?

tjr, developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats seems up to date

sheppy, is that the page you're working on ^ ?

That page will be replaced by my new content

sheppy: nice, is your new stuff available somewhere for tjr to have a look at it ?

hrm I have to run, sorry

but jya will be there soon (he's in melbourne)

hello everyone, sorry to interject. I'm trying to find the "area" (no specifics needed) on what areas of the code are responsible for rendering frames of video (at the application level [ie., independent gfx card, etc]), I would *really* appreciate it! I know you are all busy -- apologies again for parachuting in on the channel!

whawkins: The code that's taking the video we've already decoded and draws that to the screen?

bingo!

sorry, bryce : bingo :-)

whawkins: There's a swag of different pieces involved. At a high level on the media stack side we shuffle frames into sinks, like here: searchfox.org/mozilla-central/rev/e…m/media/mediasink/VideoSink.cpp#291, which then pass frames over to the gfx stack which does the drawing part via the compositors:

#gfx would know more about the latter part, while here is the right place for things leading up to the passing across the boundary

that's perfect -- that's exactly what I needed! Thanks bryce

tjr: good morning.

jya: Hey! I am working on my script and can show you what i have when I think it's in a good spot, so need to need to dig out more infor for me right now :)

*no need

The only codecs for which reports can vary are aac, h264 and vp9. Aac and h264 may not be supported if the required framework aren't there,

On Mac it will always be there

On Windows it may not be there on Windows version KN and N

On Linux it depends if ffmpeg is there and compiled with h264 support

ah okay, thanks! That'll make this way easier

Vp9 may be HW accelerated on Windows only..and the smooth value may change.

H264 will never be HW accelerated on Linux, on Mac it almost always will be (except hackintosh with nvidia cards and the mac pro 2013 trashcan)

On Windows it almost always is HW accelerated, except if the GPU card is blacklisted.

ajones: is this with YT only?

jya: I don't think so but I don't watch that much video elsewhere

The spinner should only be shown if we are waiting for data, either audio, video or both,

Seeing a video frame behind could happen if we're too slow to decode.

jya: I think I've seen it elsewhere with a frozen video but progressing audio. It happens after seeking or at the beginning of a video

But I can't imagine a case from the top of my head where you would have both the spinner and the video frame late.

that was the weird thing.

jya: What's the correct string to pass for h264 and theora? (Assuming my mac supports them; I can't figure out how to format them to get a type:file, contentType: 'video/<any-container>?codecs=h264' to return 'true')

H264 mimetype is avcN.PPLLNN

Where N is 1.2 or 3, P is for profile, L is level, C constraints

Sorry, avcN.PPLLCC

Aac is mp4a.XX.YY

Where XX depends on the type of aac etc.

For us, none of those values will make a difference so long as they are valid.

On Windows, you can't decode a video of the width or height isn't a multiple of 16.

tjr: it will be pretty tough to get exact info with Media Capabilities, we kept it rather the same across platforms for the explicit purpose of not allowing finger printing.

MediaCapabilities doesn't expose data that wasn't there before. To test codec you could instead attempt to play a video instead. You only need to craft the metadata and attempt to play it.

So, to pick up where I had to leave off earlier... I'm doing a whole new section of articles on MDN about media formats used on the web with compatibility information for containers and codecs. We'll be adding files to our Browser Compatibility Database that cover media format compatibility, and that data will be used to build support matrices and such on MDN.

Along with guidance about use cases for various formats, etc.

Writing work has just begun and collection of data is ongoing, but the root of the doc tree is here: developer.mozilla.org/en-US/docs/Web/Media/Formats

bryce: No reason why MoofParser MOZ_LOGs shouldn't appear, if you have set MOZ_LOG=MediaDemuxer:5. Are other logs visible?

bryce: All the calls to LOG relate to errors; maybe there are no errors? 😜

gerald: I see the ones for the WebMDemuxer, but both MoofParser and MP4Demuxer do not log. I'm fairly confident they should be, as I'm able to hit breakpoints in them. Let me double check

You could be right that it's only errors :S Let me see

gerald: Yep, looks like the problem is between my monitor and my chair 😢 What's the benefit of using the DD Logging? Better for perf?

bryce: Woops 😆 DDMOZ_LOG just offers an extra output to the DevTools Media Panel (so, a bit worse for perf!) -- but I think it's broken at the moment. mjf and I need to have a look one of these days...

Thanks for the explanation

drno: seems that the regression with resolution changing is in webrender

so not surprised you're seeing this on windows and I'm not on mac

I've tried it all using the Network Link Conditioner on the safari sender

I see the resolution changing (quite quickly too I'm quite impressed). And the receiver updates very nicely

jya: ahh. I was wondering at some point if the cropping is a platform specific problem. thank you for digging in on this

jya: did you open a bug for that webrenderer regression yet?