mozilla :: #media

15 May 2017
00:43jesup|macdminor|afk: ng: mjf: I pushed patches that stop simulcast from asserting. Looks like it's timing out
01:26rilliangerald: thanks!
02:41kamidphishkinetik: ping
02:43kinetikkamidphish: hi
02:45kamidphishkinetik: I'm trying to build cubeb on Windows. But I think I just worked out the problem
02:45kinetikkamidphish: oh?
02:46kamidphishkinetik: I forgot to git submodules
02:46kinetikkamidphish: ah
02:46kinetikthere's probably some way to teach cmake to complain in a nicer way about that
02:51kinetikoh, it does print an error, but it potentially scrolls away as it prints a bunch of other stuff
02:53kamidphishI looked at saw "Can't find DOXYGEN"
02:54kamidphishin the scroll back there was a message about not finding CMakeLists.txt in googletest
02:54kinetikdoxygen is optional
02:54kinetikyeah, that's it, but it's not obvious
02:56kinetikkamidphish: might improve that a bit
03:01kamidphishkinetik: let me test that
03:19kinetikkamidphish: sweet, thanks for pointing it out
03:39kamidphishkinetik: So I've pushed a PR against cubeb to "intern" the device ids. It was the simplest solution I could think of.
03:40kamidphishkinetik: How is the IPC prototype coming along?
03:40kinetikkamidphish: cool, i'll try to take a look soon... it'd be good to get some feedback from the webrtc team (padenot is away, but maybe jesup or achronop) on it as well
03:41kinetikkamidphish: slowly making progress, behind where i wanted to be due to sickness and other work last week :-/
03:41kamidphishkinetik: Anything I can help with?
03:50kinetikkamidphish: not at the moment, but i'll let you know if i think of anything
05:23cpearcejw_wang: Are you still on PTO?
05:25cpearcejw_wang: I was wondering about Bug 1361756, are you sure that it is WebM non-MSE only? I have observed on MacOS on facebook and YouTube that sometimes I am unable to advance a video load past first frame loaded... I was wondering if your patch will help with that. I have observed this bug on beta54 on MacOS.
05:25firebot FIXED, WebM video format not working if site triggers network download for invisible media elements
05:25cpearcebwu: is jw_wang still on PTO?
05:51jw_wangcpearce: I am sure it is non-MSE only.
05:52jw_wangbut not sure if there are some other decoders that need to fetch data while resetting.
05:53jw_wangcpearce: is your problematic video a webm?
06:18cpearcejw_wang: I had thought that facebook would be using MP4... I've seen it on YouTube on my MacBook Pro too, and that's getting WebM/VP9/MSE.
06:19jw_wangcpearce: in the case of facebook, it could be that many invisible webm use up all decoding threads and new video won't decode.
06:20jw_wanghowever, I don't have a theory for youtube.
06:21jw_wangwait, if all decoding threads are used up, new video won't decode at all, no matter it is MSE or not.
06:21cpearceMaybe they're converting animated gifs to WebM?
06:22cpearceThe YouTube problem I thought was a cubeb problem; as I saw that the buffered ranges were growing, but we were stuck after first frame loaded.
06:22cpearcei.e. I thought the audio clock wasn't advancing.
06:22jw_wangit is easy to repro the issue by: 1. revert bug 1361756. 2. open 10 about:addons windows. 3. open youtube
06:22firebot FIXED, WebM video format not working if site triggers network download for invisible media elements
06:23jw_wangand youtube should get stuck.
06:29bwucpearce: I am the one on PTO today. :-)
06:52jyajw_wang: it appears that we have a few audio mp4 in our mochitest where decoding the first frame always fail...
06:55jw_wangjya: how did we handle that?
06:56jw_wangskip to next key frame?
06:56jyawell more exactly with audio, it just flush the decoder and decode the next
06:56jyaI didn't make an exception between audio and video, always attempting to decode the first frame by seeking back
06:57jw_wangso the content is bad, you still get the error even with decoder fallback.
07:00jyawell yes, because we always attempt to decode the first frame over and over
07:22padenotmreavy, jesup, jib, achronop, I'm here for three days if anybody needs anything
07:23jyaso am I ^
07:46jyakikuo: ping
07:57jyajw_wang: I could make a special handling for audio, that is don't attempt to decode the frame again if it's audio. and in order to make sure the behaviour is deterministic, if we get a WAITING_FOR_DATA error from the demuxer (that is we've exhausted the data we have) then we make that error fatal
07:57jyathat's in order to guarantee we can determine that we're done when decoding the first frame
07:58jw_wangsgtm for audio
08:00jyaI'll fix those files too.. they would have never got in if we didn't blindly skip any errors.
08:00jw_wangthose files are invalid?
08:02jyathe first few frames don't decode
08:02jyaaudio frames
08:03jyathey were created by kikuo in bug 1257116
08:03firebot FIXED, Make playback mochitests faster by making test media files shorter
08:03jyai wonder what tool he used to create those...
08:05jyai hope those files are using the same original codec data and it's just remuxing, otherwise we stopped testing what was once broken
08:05jyaall the original file, prior shortening were files giving us issues.
08:14jyajw_wang: hmmmm, on further thought, if we got to skip errors for audio, we're back to the problem that decoding the first frame may not complete. It's difficult when we should accept a WAITING_FOR_DATA result and when we should error on it.. I think because of this, the entire set of assumptions we discussed last week is wrong
08:15jw_wangonly for audio, right?
08:16jyawell yes.
08:17jyabut say with MSE, there's been an append buffer with 3 audio frames. all 3 are wrong (we skip 3 errors). So we attempt to decode, fail, and continue demuxing audio
08:17jw_wangthe change allows us to decode 1st frames without wanting more data.
08:17jyanow we've run out of audio to decode. we enter waiting for more data mode.
08:17jw_wangyou will treat it as an error, right?
08:18jw_wangsince you can't finish decoding 1st frame without wanting more data.
08:19jyamediasource won't get to know that the MDSM has done anything it could do and fire updateend
08:20jyait's not that obvious one when it's okay to have waiting_For_data (we have nothing) and when we're running out of data due to error skipping
08:20jyai guess I could check the value of error count and if != 0
08:20jyathat starts to become ugly
08:21jyaand then you have to handle real case of waiting_For_data: like aac or opus with preroll value where you need to input more than one frame to get a decoded one
08:22jw_wangso draining won't work in that case?
08:22jyai think really, we need a way for the MDSM to tell the MediaDecoder that it has done everything it could do with the data it has
08:23jyano draining won't work... AAC typically has 2192 frames of encoder delay
08:23jyaand a AAC packet is typically 1024 frames
08:23jyaso you need more than 2 packets to get on frame out
08:23jyaone frame out
08:26jyajw_wang: so back to the first option I had mentioned last week, that I need you to do: have the MDSM tells the MediaDecoder that it's done or it's waiting on something it has no control off (like waiting_for_data)
08:28jw_wanghas done decoding 1st frame?
08:28jw_wangit is already done in MDSM::EnqueueFirstFrameLoadedEvent().
08:29jw_wangwe just need to have MDSM notify waiting_for_data when decoding promise is rejected.
08:34jyajw_wang: no, hasn't done decoding 1st frame, and can't with the current input
08:35jyathough, it would be nice to know there's no pending MSE operation going. Like we're in the middle of an appendBuffer, the MFR rejected the decode promise with waiting_for_data, but the data is coming...
08:36jyait's all going to be racy :(
08:37jyawe have to give up on implementing that part of the spec...
08:37jyawe may have to give up that is
10:37dminorjesup: ping, are you willing to trade triage days next week (Monday <-> Tuesday)? Monday is a holiday in Canada.
11:03jesupdminor: sure
11:05dminorjesup: thanks!
11:06dminorMy daughter and I have dentist appointments this morning, I&#39;m bringing my laptop, planning to work, not sure if I&#39;ll internet, though...
11:07jesupdminor: have to go afk for an hour+, but where do we stand on android tests? I&#39;m working on simulcast right now, and there&#39;s one hitting a few tests on Windows. Mac is looking pretty good too
11:08jesupafk but will read when back
13:05JamesChengjya: ping , but the 4byte avcc might start with 3byte 0x 00 00 01 and 1 byte data right?
13:05jyaand what valid NAL would be 1 byte long?
13:06jyaeach NAL starts with a nal type, and various information.
13:07JamesChengthe total 4 bytes is not 1, isn&#39;t it?
13:07jyaJamesCheng: I don&#39;t know what made you believe that the error was due to the NAL starting with 00 00 00 01 when it was AVCC
13:07jyabecause I&#39;m fairly certain there&#39;s no way you could have seen this.
13:08jyaand by design, the NAL content can NOT have data that looks like an annexB start code, it&#39;s encoded so that all 0x00 00 00 are encoded
13:08JamesChengSince I print the log in &quot; if IsAnnexb &quot; in the beginning of convertsampletoannexb . The log prints out
13:09jyaDid you actually test and verify that the comment you wrote is accurate, or you&#39;re just guessing?
13:09jyaI wrote in the bug where the error was. You call IsAVCC(aSample) right after converting aSample from AVCC to AnnexB, so IsAVCC will always return false
13:10JamesChengI&#39;ve verified , I will provide the log and sample data hex form for you.
13:10jyathat&#39;s what&#39;s causing the bug, not that aSample starts with 00 00 00 01
13:10jyathat just can&#39;t happen
13:13JamesChengjya: but IIUC even the sample is converted to annexb, the extra data is still there and not be modified? So IsAvcc can validate the case if extra data is null
13:15jyaThe original input data is AVCC
13:16jyathere&#39;s not going to be any annexB data up to this point
13:17jyaall the input is AVCC, until we do HLS, there&#39;s never any possibility for the input data being annexB.
13:17jyaSo what your stating (that the input is annexB) can&#39;t be true
13:19JamesChengjya:Is it impossible to have the nal length size equals to 0x000001a8?
13:20JamesChengI remember I got this value when I debug. I will try to print it again when I got my laptop
13:31jyaJamesCheng: maybe the easiest is to avoid the problem entirely, by simply never calling ConvertToAnnexB if the original data wasn&#39;t AVCC to start with
13:32jyaWe could give that information to H264Converter to start with, so that we don&#39;t need to guess what the data is (avcc or annexb)
15:14jesupjya: so Nightly on win10 for me is now playing videos (cool), but is also constantly getting obvious decode errors that persist to the next iframe (in this case I&#39;m seeing it on facebook)
15:15jesupThere errors appear reproducible (seek back to 0, see same errors). And it&#39;s not jsut one video, it&#39;s pretty much all facebook videos. Will check youtube
15:18jesupYoutube shows no errors
15:20jesupvisible (though different errors) if I open a tab with the &quot;video URL&quot; from the video (which shows a larger one than the one in the scrolling feed)
15:20jesupjya: ^
15:22jyajesup: there&#39;s a bug for that. The culprit change was reverted. A new nightly should fix it.
15:22jesupjya: cool. I&#39;ll stop worrying about it then
15:23jyaBug 1363984
15:23firebot FIXED, stylo: font-feature-settings should be a subproperty of font shorthand
15:23jyaWrong bug obviously.
15:23jyaBug 1361984
15:23firebot REOPENED, [Fennec][HLS] Make the H264Converter which treats the sample with AnnexB format correctly.
15:25jyaBug 1361984
16:40kikuojya: Hi, I had a PTO in the afternoon, in Bug 1257116, I used this command to shorten files. &quot;ffmpeg -i INPUT -t DURATION -c copy OUTPUT&quot;, I think it should just remux with original codec.
16:40firebot FIXED, Make playback mochitests faster by making test media files shorter
16:46jyakikuo: I don&#39;t know what it did. But I&#39;m getting a decode error on all first frame. Either on audio or video track.
16:46jyaThey only play because we&#39;re ignoring the errors.
16:55kikuoI just tested the 2 files &#39;vp9.webm&#39; & &#39;vp9-short.webm&#39; with ffprobe , both showed &#39;Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv), 320x240, SAR 1:1 DAR 4:3, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)&#39;
16:57kikuoThe only difference between them is the encoder version. Lavf55.22.100 for vp9.webm ; Lavf57.41.100 for vp9-short.webm ...
17:00kikuoI will dig further tomorrow, it&#39;s AM 1:00 here ^^||
22:58drnojesup: does bug 1365081 ring any bells?
22:58firebot NEW, Data channel fails to open if maxPacketLifeTime is set
16 May 2017
No messages
Last message: 9 days and 15 hours ago