[Ffmpeg-devel-irc] ffmpeg-devel.log.20180206

[burek]

[00:27:48 CET] <rcombs> anyone wanna review https://patchwork.ffmpeg.org/patch/7498/
[00:28:13 CET] <rcombs> maybe tmm1 
[00:33:32 CET] <nevcairiel> didnt someone else post a patch that tried to do that
[00:34:33 CET] <nevcairiel> apple sure could use some pain for their weird design
[00:57:09 CET] <Chloe> https://github.com/eintw1ck/FFmpeg/blob/array/libavformat/allformats.c#L566 this might actually be an issue
[00:57:27 CET] <Chloe> (using lavd stuff in the old api wrapper for lavf)
[00:58:15 CET] <Chloe> oh actually dont worry. I just need to use indev_list instead
[02:15:18 CET] <atomnuker> jkqxz: I've sent an opencl related patch on the ml, could you take a look?
[02:25:22 CET] <philipl> At least it's not me timing out all the time for a change.
[03:20:49 CET] <iive> so quiet in here.
[03:22:02 CET] <Chloe> iive: should there be discussions about anything in particular?
[03:22:56 CET] <iive> maybe about spaceX launch, of Falcon Heavy, that is supposed to be tomorrow?
[03:23:11 CET] <iive> i remember people around here following stuff like that.
[03:27:09 CET] <rcombs> tmm1: got a sample that hits that videotoolbox failure case? I'm not exactly sure which code path it'd go down right now
[03:38:14 CET] <tmm1> used to happen on live tuner streams for me
[03:38:36 CET] <tmm1> i can try that patch tomorrow and see
[03:41:38 CET] <FishPencil> Is anyone working on adding support for 8 and 10-bit support in the same FFmpeg build? x264 and x265 both support mulibitdepth now
[03:41:38 CET] <rcombs> thanks
[03:42:44 CET] <tmm1> does avcodec_send_packet() invoke AVCodec.receive_frame ?
[03:44:32 CET] <rcombs> tmm1: yes
[03:44:59 CET] <rcombs> if there's not already a buffered frame
[03:45:39 CET] <tmm1> huh i didn't realize it buffered frames
[03:47:17 CET] <rcombs> didn't used to
[03:47:26 CET] <rcombs> it was tweaked to simplify the internal implementation
[03:54:50 CET] <rcombs> >If we wanted to we could actually add two more side boosters and make it Falcon Super Heavy
[04:37:44 CET] <tmm1> is there a way to query the size of the packet buffer?
[04:38:20 CET] <tmm1> i.e. after you call avcodec_send_packet() multiple times
[04:48:08 CET] <rcombs> tmm1: lavc itself will only buffer one frame (no packets)
[04:48:43 CET] <rcombs> individual codecs can buffer whatever they want internally, and there's no generic way to query that
[04:49:27 CET] <rcombs> you have to call receive until you get EINVAL whenever you call send, though
[05:47:57 CET] <tmm1> sure one frame on the output, but wont incoming packets queue up?
[11:07:54 CET] <BtbN> So, Firefox is now using ffmpeg completely it seems. With all the new hwaccel stuff, using vaapi/vdpau/cuvid hwaccel should be super easy for them, but it's still missing?
[11:10:51 CET] <atomnuker> yes, I've been wondering exactly that as well
[11:11:36 CET] <atomnuker> they just need to add a few calls during init to run whatever hwaccel is found, and then some code to map what they get to opengl
[11:12:18 CET] <atomnuker> jya: any info why no one has bothered to do so?
[11:13:21 CET] <atomnuker> I've noticed things at firefox move at glacial pace, the wayland patches were around for literal years before they got merged just recently
[11:18:38 CET] <atomnuker> oh wait, I think I know why
[11:19:12 CET] <atomnuker> they don't use opengl compositing on anything but windows afaik, not even on linux and not even if you enable all flags and force it
[11:20:33 CET] <atomnuker> so even if they did implement it they'd still need to download them to system ram, compose and then back to the gpu
[11:20:59 CET] <atomnuker> would still take less cpu though
[11:27:52 CET] <BtbN> Even hwaccel with plain stupid hwdownload/sw output would be a huge improvement and would need zero changes outside of ffmpeg code
[11:28:15 CET] <BtbN> Does Chrome even support vaapi?
[11:28:21 CET] <BtbN> Or vdpau, or any video hwaccel on Linux?
[11:39:39 CET] <atomnuker> maybe TD-Linux knows
[11:39:51 CET] <TD-Linux> they added vaapi
[11:41:43 CET] <TD-Linux> firefox still doesn't use gl on linux
[11:41:46 CET] <TD-Linux> so it's less useful
[11:49:03 CET] <jya> atomnuker: what's that about?
[11:49:27 CET] <nevcairiel> BtbN: browsers are obsessed with decoding actually working, which is why the simple method of just turning on hwaccel is often not s omething they want to do, but add complex checks based on hardware and video properties that ffmpeg doesnt do
[11:50:05 CET] <jya> BtbN: if you saw the amount of crashes we get due to bad drivers on windows... how could we ever hope for drivers to be in any better shapes on linux
[11:50:22 CET] <BtbN> I understand that, and I totally agree with not enabling it by default.
[11:50:31 CET] <BtbN> But at least an option for the experimental testers?
[11:50:54 CET] <jya> TD-Linux: well, we can use opengl rendering, it's just disabled by default. It causes kernel crash with many versions of X
[11:50:57 CET] <nevcairiel> you could see how the amount of work required is not really warranted if its not going to be used by anyoen that matters :D
[11:50:58 CET] <BtbN> I'm not aware of the Firefox Codebase, but with current ffmpeg hwaccel, it can't be a lot of code
[11:51:15 CET] <jya> BtbN: the issue isn't in the decoder, that's trivial
[11:51:57 CET] <jya> it's the compositor. adding vdpau decoding is great, but then how do you paint it and do whatever is required to do with some crazy css?
[11:51:59 CET] <TD-Linux> jya, yeah. I really would like to see a whitelist though, especially because we happily enable webgl 2.0 on most hardware yet can't manage drawing quads. but that's offtopic :)
[11:52:33 CET] <BtbN> jya, you slap a hwdownload filter in the chain and get software frames like you do with the software decoder. Not nearly as efficient, but an improvement over no hwaccel at all.
[11:52:41 CET] <jya> TD-Linux: it's only in ubuntu 17.10 that I finally managed to not get complete freezing or the kernel stopping to respond . and that's not in our code
[11:53:20 CET] <TD-Linux> jya, that's not my experience, but regardless is solved by a whitelist.
[11:53:30 CET] <jya> BtbN: actually, our tests show the opposite. We had a prototype with vaapi running, doing the gpu read killed all the performance, there was no worthy benefit
[11:53:59 CET] <nevcairiel> didnt vaapi have like three ways to do gpu reads, with only one being fast
[11:54:04 CET] <TD-Linux> yeah also remember that firefox uses ffvp9 whereas chromium uses libvpx so the improvement is going to be way smaller just due to that
[11:54:07 CET] <BtbN> Yeah, GPU reads from VAAPI are special
[11:54:08 CET] <jya> and it was even worse with nvidia
[11:54:12 CET] <BtbN> But I think that was recently solved.
[11:54:35 CET] <BtbN> nvidia is super fast with read-backs from my experience. Barely any difference when doing transcoding via cuvid->nvenc
[11:54:50 CET] <BtbN> Difference between on-device transcode and download + re-uploading frames
[11:54:52 CET] <jya> BtbN: the "recently" is what worries me
[11:55:08 CET] <BtbN> It's not super recently, 3.4 should have it
[11:55:11 CET] <jya> heck, we still have a fair amount of crash report of people using Libav 8
[11:55:16 CET] <TD-Linux> BtbN, is that also true with vaapi? firefox would only implement vaapi or maybe vdpau, not cuvid.
[11:55:37 CET] <BtbN> vaapi and vdpau would work for pretty much everything
[11:55:52 CET] <jya> i think vaapi is the way to go
[11:55:52 CET] <BtbN> well, except for VP9 for vdpau
[11:55:55 CET] <BtbN> that's only in cuvid
[11:56:00 CET] <jya> especially with the future of vdpau in taters
[11:56:03 CET] <BtbN> vaapi is pretty much Intel-Only
[11:56:09 CET] <BtbN> Nvidia is all abouv nvdec now
[11:56:20 CET] <nevcairiel> all the apis are vendor exclusive, which is why linux is so terrible to support
[11:56:22 CET] <BtbN> vdpau still works, but does not get new features, those go to nvdec
[11:56:28 CET] <jya> yeah, until next year when it will all about "*****"
[11:58:09 CET] <BtbN> ffmpeg currently does a decent job abstracting vdpau/vaapi/nvdec hwaccels.
[11:58:24 CET] <jya> yes, from the decoding side of things
[11:58:31 CET] <jya> that still requires custom compositing
[11:58:52 CET] <BtbN> Are you sure for nvdec a copy-back is a problem? From my experience it's barely noticeable if at all.
[11:59:12 CET] <jya> and ffmpeg hwaccel isn't that great when it comes to uniformity. I mean to retrieve the pointer, where you get it from varies depending on the API
[11:59:23 CET] <jya> that may have changed though, I haven't looked in over a year
[11:59:37 CET] <BtbN> There are abstracted hwdownload functions
[11:59:46 CET] <BtbN> and a filter that just gives you software frames no matter what hwformat you throw at it
[12:00:00 CET] <BtbN> For at least the 3 or 4 major hwaccel APIs
[12:00:09 CET] <BtbN> (Not sure about the OSX stuff)
[12:00:15 CET] <jya> last time i looked, you had to take the 4th element of the array to get the handle for vdpau
[12:00:19 CET] <jya> while nvidia was at 0
[12:00:23 CET] <nevcairiel> re: nvidia copyback, on low-end systems it can be the difference between 4k 60fps working or not, but thats mostly because you also need to upload again eventually, which just eats into memory bandwidth, but those will also struggle with software decode (if not more so), so its nothing really lost
[12:00:45 CET] <BtbN> That's how the HWACCEL pix_fmts work
[12:00:50 CET] <BtbN> but you don't need to touch that manually anymore
[12:00:56 CET] <jya> good
[12:00:57 CET] <BtbN> Downloading them to software is abstracted now
[12:01:25 CET] <jya> may be worth looking again, but we have more pressured needs
[12:01:28 CET] <BtbN> You just run them through the hwdownload avfilter, and you get whatever software format is inside. Mostly NV12
[12:01:45 CET] <nevcairiel> every hwaccel pixfmt is a special type anyway, if you need to access them directly for on-gpu processing, you need to know how to handle each one invidually anyway, so which data member they are in is rather irrelevant since you need special code anyway. if all you need is download, there are generic functions now that do that for you
[12:02:03 CET] <nevcairiel> also if all you want is download, dont use avfilter for that, thats just silly
[12:02:08 CET] <nevcairiel> hwcontext has a download function
[12:02:13 CET] <jya> ok
[12:02:21 CET] <jya> there's doc for that somewhere?
[12:02:23 CET] <BtbN> unless you already have a filter chain anyway
[12:02:29 CET] <BtbN> for pix_fmt conversion or whatever
[12:02:38 CET] <jya> we do not, we don't have have libavfilter in our tree
[12:02:41 CET] <nevcairiel> avutil/hwcontext.h contains most of that
[12:02:52 CET] <BtbN> Yeah, downloading directly is better then
[12:03:33 CET] <atomnuker> BtbN: amd went with vaapi as well
[12:03:39 CET] <nevcairiel> also with amf
[12:03:48 CET] <BtbN> Isn't AMF encode-only and windows-only?
[12:04:30 CET] <atomnuker> jya: I think you'd be surprised how difficult it is to crash mesa on intel with opengl/vulkan, I've never done so despite the crazy things I've done
[12:04:55 CET] <nevcairiel> its decode too, and the sdk works on linux, but i dont think their linux drivers support it yet, but they say they are supposed to in the future
[12:05:14 CET] <BtbN> great
[12:05:17 CET] <jya> atomnuker: as always with you, it's so easy... I suggest you take on the task.. it's open source after all... let me find the link to the bug you can take
[12:05:24 CET] <BtbN> I can see why all the vendors create their own encode API
[12:05:35 CET] <atomnuker> not sure about how stable amd is though, and I do know nvidia binaries are prone to crashing on valid vulkan uses
[12:05:38 CET] <BtbN> But for decode it would be really nice if they could all just properly support something common
[12:05:41 CET] <nevcairiel> probably because the vaapi encode api is so terrible :D
[12:05:56 CET] <BtbN> like, vdpau, if nvidia would not have let it die
[12:06:01 CET] <nevcairiel> its so super low level
[12:06:12 CET] <BtbN> vaapi is just tailored around Intel GPUs
[12:06:24 CET] <BtbN> any other vendor trying to use it will run into trouble
[12:06:33 CET] <jya> https://bugzilla.mozilla.org/show_bug.cgi?id=1210727
[12:06:40 CET] <jya> atomnuker: feel free to take it ^
[12:06:56 CET] <jya> and that's the easy part of just doing the decoding.
[12:08:49 CET] <BtbN> Talking about weird (driver?) bugs, I have this very weird issue on my Laptop right now that the menu in Firefox is not visible(but interactible) if I logout of my X session and then re-login without reboot.
[12:09:07 CET] <BtbN> On first X login everything works just fine.
[12:09:14 CET] <jya> is that with the default layout?
[12:09:17 CET] <BtbN> Yes
[12:09:26 CET] <BtbN> The menu is there and works, I can click things. Just can't see it.
[12:09:33 CET] <jya> when is the last time you've done a config refresh? it usually helps, espeically on linux.. 
[12:09:56 CET] <BtbN> This happenes on a new user as well. Some other non-firefox menus are also weird, but not invisible. So I doubt it's Firefoxs fault
[12:10:38 CET] <BtbN> Like, the Plasma Task-Bar is half-transparent-greyish instead of its normal color.
[12:10:41 CET] <jya> i had plenty of weird things when I changed to gnome
[12:10:55 CET] <BtbN> I blame mesa and/or Plasma so far
[12:11:15 CET] <BtbN> Luckily I don't usually restart my X session
[12:11:21 CET] <jya> not sure which distrib you're using, but there's been great progress in the past 3-4 months 
[12:11:27 CET] <BtbN> Gentoo
[12:11:34 CET] <BtbN> I'm not on the very latest Plasma though
[12:11:35 CET] <jya> oh I misread
[12:11:41 CET] <jya> it's if you logout
[12:11:50 CET] <jya> I've stopped login out and back in
[12:11:51 CET] <BtbN> It's if I logout and re-login without reboot
[12:11:59 CET] <BtbN> Which I don't usually do anyway
[12:12:00 CET] <jya> sometimes I get a complete hang on my dell xps 15
[12:12:12 CET] <jya> that if I had nvidia enabled
[12:12:28 CET] <BtbN> I just happened to do it when I first setup this Laptop, so stuff was broken. I spent hours debugging, gave up, went to bed, and when I came back the next day (and rebooted in turn) everything was fine.
[12:12:32 CET] <jya> I have a gigabyte aero 14
[12:12:39 CET] <jya> when I do that the screen turns black
[12:12:56 CET] <BtbN> This is a thinkpad T550
[12:13:05 CET] <BtbN> With a super shitty Broadwell CPU/GPU
[12:13:16 CET] <jya> and the keyboard is no longer functional. so I must do a hard reset. but if doing so then the trackpad will no longer work until i reboot under windows. 
[12:13:17 CET] <BtbN> (And a horrible nvidia GPU, which I just started ignoring)
[12:13:25 CET] <jya> then the trackpad works again, and i go back into linux
[12:13:49 CET] <BtbN> sounds like something needs firmware that only the Windows driver can upload correctly
[12:14:19 CET] <jya> yes I believe so... it's a crappy trackpad , there's plenty of fixes for asus and othrer device. doesn't work with mine
[12:14:44 CET] <jya> (I love my aero otherwise, stays super cool and very silent.. unlike the dell xps 15)
[12:14:54 CET] <BtbN> My laptop has incredible thermal issues as well. Watching YouTube puts the CPU into thermal throttle to ~1GHZ
[12:15:17 CET] <BtbN> So to watch Videos I'm forced to download them and play them with mpv or VLC, which is why I'm so interested in full hwaccel
[12:15:56 CET] <jya> on the xps 15 I solved this doing so: https://www.ultrabookreview.com/14875-fix-throttling-xps-15/
[12:17:38 CET] <BtbN> I'm pretty sure it's a firmware issue with my CPU
[12:18:01 CET] <BtbN> It starts throtling at 65°C, but the fans do not turn on at all until it reaches 60°C
[12:18:22 CET] <BtbN> software control of the fan seems to be impossible
[12:27:02 CET] <atomnuker> jya: thanks, I'll look into it, have to start compiling because of wayland anyway
[15:28:55 CET] <kierank> jya: weird, i have not had that issue
[15:30:30 CET] <jya> kierank: which issue is that? 
[15:30:56 CET] <kierank> with the xps 15
[16:20:30 CET] <jdarnley> Does anyone know how there are no vsynth3 tests for the vc2 encoder?
[16:21:42 CET] <jdarnley> does adding them to RESIZE_OFF doit?
[16:22:47 CET] <jdarnley> ah
[16:22:49 CET] <jdarnley> "VSYNTH3_OFF  = $(RESIZE_OFF) $(INC_PAR_OFF)"
[16:51:55 CET] <philipl> BtbN: Is the avcodec built by mozilla just upstream code? You could build your own with a patch to rename the cuvid decoder so that it provides 'vp8' and 'vp9' and that would be a drop in replacement. Don't even need download logic.
[16:52:16 CET] <BtbN> It does not bundle ffmpeg
[16:52:30 CET] <BtbN> it uses system ffmpeg via some elaborate dynamic loading and version detection logic
[16:52:37 CET] <philipl> libmozavcodec.so does not agree with you
[16:53:01 CET] <BtbN> Are you sure it's not just a wrapper?
[16:53:21 CET] <BtbN> At least jya just complained about users using libav 8
[16:53:27 CET] <philipl> I ran strings on it.
[16:53:35 CET] <philipl> Yes, he did. Which confused me. Maybe he can clarify
[16:53:41 CET] <philipl> but this library is a libavcodec.
[16:53:44 CET] <philipl> I ran strings on it
[16:53:53 CET] <jya> BtbN: it is not a wrapper
[16:54:11 CET] <jya> it's libavcodec with ffvp8, ffvp9 and flac
[16:54:25 CET] <jya> this is for use on *all* platform
[16:54:44 CET] <jya> for other codecs, and where libavcodec system is present, then it will be dynamically loaded
[16:55:25 CET] <philipl> jya: so, vp8/9 and flac come from the bundled one, and h264/aac/etc come from the system one?
[16:55:40 CET] <jya> I can only officially confirm the former :)
[16:55:49 CET] <philipl> heh.
[16:56:00 CET] <jya> we certainly do not tell people to install anything in particular
[16:56:20 CET] <philipl> BtbN: So yeah, if you just do a patched build that renames the codecs, cuvid should just work transparently.
[16:56:25 CET] <philipl> I'm going to try it :-)
[16:56:26 CET] <jya> but yes, if a system ffmpeg is present, and it supports h264, aac or mp3 it will be used
[16:56:36 CET] <jya> what's cuvid?
[16:56:41 CET] <BtbN> old name for nvdec
[16:56:48 CET] <jya> ah ok
[16:56:53 CET] <philipl> jya: but not just a name. It's written as a full decoder rather than an hwaccel
[16:56:53 CET] <BtbN> but still present as a stand-alone decoder
[16:57:08 CET] <philipl> So it does download-to-system-memory automatically if you ask for a SW format
[16:57:15 CET] <jya> cool
[16:57:26 CET] <BtbN> It behaves like a normal decoder unless you explicitly ask it not to
[16:57:36 CET] <jya> philipl: you may find it easier to patch the existing code
[16:57:46 CET] <jya> happy to give you pointers
[16:57:59 CET] <philipl> jya: I can rebuild ffmpeg quicker than Firefox to prove the concept.
[16:57:59 CET] <BtbN> From how I understand it, that mozavcodec is stripped down to what the lawyers okayed
[16:58:10 CET] <BtbN> so cuvid won't be even in there
[16:58:12 CET] <philipl> BtbN: command line is available from 'strings'
[16:58:15 CET] <philipl> Rebuild away
[16:58:53 CET] <philipl> jya: I'll ping you if I fail to get it building. Last time I built firefox was about 15 years ago.
[16:59:02 CET] <jya> philipl: https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#371 here is where from the codec mimetype, the ffmpeg codec_id is returned
[16:59:17 CET] <jya> so my guess here is that say for h264 you return the cuvid one
[16:59:31 CET] <philipl> jya: yes. that would be it, and similarly for vp8/9
[16:59:40 CET] <jya> and here is where you ask what format you want: https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#50
[17:00:01 CET] <jya> the issue now is that we have no ffmpeg fallback mechanism
[17:00:09 CET] <jya> so if say ffvp9 fails 
[17:00:26 CET] <jya> then it will attempt ffvp9 from the system libavocdec, and if that fails that will use libvpx
[17:00:55 CET] <jya> we would need something that attempt to use the cuvid one and if that fails fall back to AV_CODEC_ID_H264
[17:01:05 CET] <philipl> jya: So, if I was to move libmozavcodec out of the way, it would fall back to system for all codecs?
[17:01:18 CET] <jya> philipl: there's a much easier way :)
[17:01:33 CET] <BtbN> It's probably this that needs to be changed to use cuvid: https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp#261
[17:02:03 CET] <philipl> jya: some config key?
[17:02:04 CET] <jya> philipl: go to the about:config page, search for the media.ffvpx.enabled preference and set it to false
[17:02:17 CET] <BBB> ;( fallback to libvpx ;(
[17:02:26 CET] <philipl> jya: ok.
[17:02:33 CET] <BBB> jya: on a more practical note, do you have statistics on how often that happens?
[17:02:49 CET] <jya> BBB: for vp9?
[17:02:51 CET] <jya> never
[17:02:54 CET] <BBB> for example
[17:03:03 CET] <BBB> oh, cool
[17:03:09 CET] <jya> unless played with the pref
[17:03:11 CET] <BBB> *silent voice* and vp8?
[17:03:16 CET] <jya> same thing
[17:03:23 CET] <BBB> *pheew*
[17:03:37 CET] <jya> and we favour *our* ffvp8/ffvp9 over the system vp9
[17:03:48 CET] <jya> just because we control that code and it's a known entity
[17:03:53 CET] <BBB> yup
[17:04:03 CET] Action: BBB goes slack in a corner again
[17:04:11 CET] <jya> libvpx was kept for webrtc (which still doesn't use it)
[17:04:19 CET] <BBB> I was scared something was wrong and this fallback mechanism was added to cover up my failures
[17:04:31 CET] <jya> because that libvpx decoder isn't used for webrtc, but the one deep in the webrtc.org code
[17:04:59 CET] <jya> BBB: no no, that fallback was added so I could test, and if close to release we found something was screwed up we could disable the code path
[17:05:36 CET] <jya> ohhh... actually we can use libvpx 
[17:05:44 CET] <jya> vp8/vp9 with transparency layer
[17:05:55 CET] <jya> only the libvpx code was patched up 
[17:06:10 CET] <jya> forgotten about that one.. it's so messy
[17:06:13 CET] <BBB> ah yes I remember that
[17:06:15 CET] <BBB> yes its messy
[17:06:17 CET] <BBB> sorry about that
[17:06:25 CET] <jya> i've seen such horrible videos with transparency
[17:06:27 CET] <BBB> its not hard to add to native vp8/9 decoders but someone needs to care
[17:06:39 CET] <jya> like the keyframes don't match between the two streams
[17:06:47 CET] <BBB> yikes
[17:07:21 CET] <jya> so now when you seek, if the transparency isn't a keyframe, we skip backward until we find one
[17:07:35 CET] <jya> and we skip backward because sometimes the keyframe is just at the start
[17:07:49 CET] <jya> that kills our cache handling and we have a bug opened that seeking is now slow
[17:08:04 CET] <jya> from always the same guy, who always manage to create the worse encoding of all kind
[17:11:21 CET] <nevcairiel> I like ignoring such people and their artifical samples =p
[17:12:50 CET] <nevcairiel> if you try to fix every broken sample out there, you go insane
[17:14:21 CET] <wm4> seems pretty sane to require that transparency data has the same keyframe flags at least
[17:14:25 CET] <wm4> but really this is such a shit hack
[17:16:49 CET] <jamrial> <@nevcairiel> if you try to fix every broken sample out there, you go insane
[17:16:51 CET] <jamrial> that explains so much about ffmpeg :p
[17:59:29 CET] <BBB> wm4: the sad part is that the samples created in the wild with the tools given to us dont actually do that
[17:59:39 CET] <BBB> so requiring something that is not actually true by default is & not going to work
[17:59:40 CET] <BBB> :(
[17:59:47 CET] <BBB> I dont disagree it *should* be that way
[17:59:49 CET] <BBB> but it is not :/
[18:00:27 CET] <nevcairiel> just have to make a stand and fail decoding any samples that are just crap like that
[18:00:36 CET] <nevcairiel> or hire assassins to purge the world of bad developers that enabled this
[18:01:23 CET] <wm4> what tools do create it=
[18:01:26 CET] <wm4> ?
[18:01:37 CET] <philipl> jya: where's the part that builds libmozavcodec?
[18:14:53 CET] <philipl> jya: found it
[18:19:43 CET] <philipl> jya: Yeah, so even the cuvid decoder won't actually drop in and work as it doesn't return any of the SW formats that firefox expects. It does NV12 and P010
[18:36:22 CET] <Chloe> why do all commits have to build in sequence
[18:37:04 CET] <Chloe> What's the issue with not merging two commits which are very different (i.e. shouldnt be merged), but they are dependent
[18:38:02 CET] <wm4> because that makes bisecting easier
[18:42:24 CET] <nevcairiel> yeah its super annoying when you bisect and stuff doesnt build
[18:42:26 CET] <DHE> `git bisect` is a great thing.
[18:46:14 CET] <Chloe> how are you using `git bisect`?
[18:47:25 CET] <DHE> any time I run into a regression, I pick 2 versions of $SOFTWARE, one working and one broken, and run "git bisect start; git bisect good $WORKINGVERSION ; git bisect bad $BROKENVERSION"
[18:47:45 CET] <DHE> and git picks a revision in  between for you to test. you report good or bad and it repeats the process until it nails the commit that broke it
[18:48:05 CET] <DHE> but for this to work, each version needs to build and work properly. and preferably be small-ish, easy to digest updates
[18:49:17 CET] <Chloe> ah right that's interesting, sounds useful
[18:50:06 CET] <hanna> git bisect is also a good reason not to use merge commits
[18:50:15 CET] <hanna> git needs to test each merge base every time
[18:50:33 CET] <nevcairiel> that works surprisingly well however
[18:50:40 CET] <hanna> it works but it takes longer
[18:51:07 CET] <hanna> although I guess git could make an effort to pick a bisection that avoids merge commits if possible
[18:51:11 CET] <hanna> which should be possible for small merge branches
[18:51:19 CET] <hanna> not sure if it does this, though?
[18:51:41 CET] <nevcairiel> in our case you can just skip the steps where you end up on the libav branch, so it doesnt really add any extra steps
[18:51:54 CET] <nevcairiel> we even have a helper script that just does this for you by checking if ffmpeg.c exists
[18:51:57 CET] <hanna> ah
[18:52:02 CET] <hanna> well that sounds useful
[18:52:08 CET] <hanna> but it also sounds like a hack
[18:52:32 CET] <nevcairiel> well "git bisect skip" is a thing, so
[18:52:36 CET] <hanna> anyway git needs to be replaced by a patch-based system :^)
[18:52:43 CET] <hanna> everybody uses git in a patch-based workflow anyway
[18:53:07 CET] <hanna> state based 3-way merge is broken
[18:54:14 CET] <hanna> https://pijul.org/ is the latest meme
[18:55:07 CET] <Chloe> tools/bisect-create?
[19:21:08 CET] <iive> If there are still people who are interested in SpaceX stuff, falcon heavy is scheduled for launch in 2 hours. get popcorn for the fireworks :D
[19:22:38 CET] <jdarnley> I'll watch the gif highlights for any fireworks
[19:49:53 CET] <durandal_1707> iive: im watching p0rn instead
[19:57:59 CET] <cone-205> ffmpeg 03Josh de Kock 07master:7e8eba2d8755: lavc: add new API for iterating codecs and codec parsers
[19:58:00 CET] <cone-205> ffmpeg 03Josh de Kock 07master:61974537610d: lavf/rtp: replace linked list with array
[19:58:01 CET] <cone-205> ffmpeg 03Josh de Kock 07master:598d5f8579b3: lavf: move fifo test muxer into separate file
[19:58:02 CET] <cone-205> ffmpeg 03Josh de Kock 07master:0694d8702421: lavf: add new API for iterating muxers and demuxers
[19:58:03 CET] <cone-205> ffmpeg 03Josh de Kock 07master:0fd475704e87: lavd: add new API for iterating input and output devices
[19:58:04 CET] <cone-205> ffmpeg 03Josh de Kock 07master:cdc78058c78d: cmdutils: make use of new iteration APIs
[19:58:05 CET] <cone-205> ffmpeg 03Josh de Kock 07master:26d879c1cea1: lavc/bsf: make BSF iteration the same as other iterators
[20:00:05 CET] <jamrial> Chloe: that set wasn't fully reviewed and oked
[20:00:32 CET] <jamrial> why did you push it?
[20:00:40 CET] <durandal_1707> oh nooo, what have you done!
[20:01:52 CET] <Chloe> you serious? I've been asking for comments for ages, and again, people wait until after things are pushed. I fixed all the issues which were described
[20:02:20 CET] <Chloe> but if that's not good enough then fuck it, revert and fix it yourself.
[20:03:10 CET] <atomnuker> well that was a bit rude of him, michaelni just emailed him -f lavfi didn't work
[20:03:30 CET] <atomnuker> I'll try to fix it
[20:03:54 CET] <JEEB> huh, so michael now posts under an alias of Muhammad?
[20:04:01 CET] <JEEB> I thought that was a separate person :P
[20:04:01 CET] <durandal_1707> yes
[20:04:20 CET] <atomnuker> misremembered, oh well
[20:04:25 CET] <JEEB> it happens
[20:04:56 CET] <JEEB> anyways, that wasn't nice. since while `-f LIBAVDEVICE` probably is a hack, it still used to work
[20:07:23 CET] <jamrial> seriously, no patch in the set has gotten an ok. there were unaddressed design suggestions
[20:07:25 CET] <jamrial> there was even a "competing" set doing the same thing in a different way
[20:07:45 CET] <jamrial> this needed at the very least a ping before being pushed. it's a massive API change
[20:09:13 CET] <jamrial> i don't understand the rush, and much less the reaction he had at being told hadn't even gotten one ok yet...
[20:10:46 CET] <hanna> so michaelni unironically sockpuppets?
[20:10:48 CET] <durandal_1707> people cant wait for comments that happen like every 96h
[20:10:54 CET] <hanna> does he use it to agree with himself? :^)
[20:11:36 CET] <durandal_1707> michaelni is not problem here
[20:11:45 CET] <JEEB> hanna: he misremembered :P
[20:12:14 CET] <wm4> jamrial: maybe it's because he's been trying to get in for weeks and it was all bikeshedding and people going "hey this patch set was there for weeks but suddenly I have an important opinion about it"
[20:12:58 CET] <jamrial> wouldn't you have an opinion about a full API replacement?
[20:13:28 CET] <hanna> oh now I get it
[20:13:49 CET] <hanna> fucking pronouns man
[20:13:52 CET] <hanna> just say atomnuker
[20:14:09 CET] <jya> philipl: that's easy fix, we have backend for both nv12 and 10 bits image. 
[20:14:23 CET] <JEEB> I was trying to think if the "allocate the whole thing for each request of a list" thing made any sense
[20:14:41 CET] <JEEB> but then didn't have that much time to give it (´4@)
[20:14:46 CET] <jya> 10 bits image only works on OGL machines though, so Linux and max
[20:15:26 CET] <atomnuker> hmm, I can't replicate "./ffmpeg -f lavfi -i aevalsrc=0 -f null -" or any lavfi source
[20:16:12 CET] <JEEB> yea
[20:16:22 CET] <JEEB> he said to me he had tested that and full FATE worked for him
[20:16:30 CET] <JEEB> he could have replied to that mail at least :P
[20:18:14 CET] <jamrial> he mentioned lavfi worked for him in a reply to the thread, just not to Faiz's email
[20:18:53 CET] <JEEB> right
[20:19:01 CET] <jamrial> i don't know if because he fixed it before pushing, or because it was fixed in a subsequent patch in the set, meaning a bisect would be able to reproduce that failure
[20:21:17 CET] <JEEB> at least there's just a single cmdutils commit
[20:21:32 CET] <JEEB> and before that it utilizes the old API?
[20:23:32 CET] <philipl> jya: so how do I express that NV12 has only two planes in the YCbCrBuffer? It's enough for the plane[3] data to be null?
[20:23:35 CET] <philipl> I don't see any type flag
[20:25:43 CET] <JEEB> set pix_fmt to NV12 and use the two first planes
[20:25:49 CET] <JEEB> set third to NULL I think
[20:26:06 CET] <philipl> jya: this is the firefox specific buffer metadata
[20:26:09 CET] <philipl> JEEB: sorry
[20:26:28 CET] <JEEB> oh
[20:41:36 CET] <atomnuker> is there any way to prevent ffmpeg.c doing a full decode to figure out parameters before doing a second decode to actually decode?
[20:42:09 CET] <tmm1> isn't there some way to skip find_stream_info
[20:44:25 CET] <JEEB> probesize/analyzeduration was it?
[20:49:35 CET] <wm4> tmm1: by not calling the function, and if ffmpeg.c always calls it, an option to prevent it should be added
[20:49:47 CET] <wm4> unfortunately random things tend to break when skipping it
[20:55:37 CET] <tmm1> i thought i saw some commit where you could set probesize to 0 or -1 to skip
[20:55:41 CET] <tmm1> but don't remember if it was committed
[21:33:59 CET] <iive> T-12minutes
[21:37:04 CET] <durandal_1707> iive: climax approaching
[22:06:26 CET] <philipl> jya: Looks like YCbCrBuffer is not usable today to pass NV12. I see assertions in MediaData.cpp that plane[1] and plane[2] have the same dimensions and that all three planes are present.
[22:06:54 CET] <jya> not nv12 no
[22:07:13 CET] <jya> but there's a nv12 buffer , let me think
[22:08:09 CET] <jya> https://searchfox.org/mozilla-central/source/gfx/layers/ImageContainer.h#916
[22:08:38 CET] <jya> philipl: that code may not have been well tested I'm afraid
[22:08:51 CET] <jya> i saw some bad things a while ago when i went over that code
[22:10:23 CET] <jya> also, you'll need to add libavcodec.58.so support there https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegRuntimeLinker.cpp#35 
[22:10:59 CET] <jya> and if doing so, you can take bug 1435212 and ask me for review
[22:11:03 CET] <philipl> jya: SO MediaData returns a PlanarYCbCrData, which can store NV12. So enabling that is relatively simple, I think. Then we need to see whether the consumer knows or whether more adapting is required.
[22:12:09 CET] <jya> not quite
[22:13:21 CET] <jya> MediaData *takes* a YCbCrBuffer, but it can also take an image
[22:13:33 CET] <jya> so for that you create a NV12Image instead
[22:15:23 CET] <jya> https://searchfox.org/mozilla-central/source/dom/media/MediaData.cpp#428
[22:15:34 CET] <jya> so you can create a VideoData from an image
[22:16:23 CET] <philipl> jya: Yeah, of course, this is way ahead of knowing what you're dealing with - you don't know if it will come back as YUV420P or NV12
[22:16:32 CET] <jya> so if nv12 buffer, rather than recreate the YCbCrBuffer and make VideoData::CreateAndCopy create the YCbCrImage for you, you need to create the nv12 image yourself
[22:16:58 CET] <jya> well, it doesn't matter what it is, it takes an Image
[22:17:05 CET] <jya> an Image can be of many types
[22:17:54 CET] <jya> so you need to add that special case there: https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#289
[22:18:15 CET] <jya> if the pixel type is nv12, then handle the case and return early
[22:18:22 CET] <philipl> jya: Yeah, I get it
[22:18:45 CET] <jya> that type of type is a bit easier to handle in C++ than in C!
[22:19:37 CET] Action: jya grrmrmrmbl i receive my neighbour wifi signal better than my own
[22:22:03 CET] <iive> durandal_1707, https://youtu.be/wbSwFU6tY1c?t=37m47s double culmination  ;)
[22:23:02 CET] <philipl> jya: Ok, so I create an NVImage, and to do that I need to create a PlanarYCbCrData and fill that in for it. Then I call CreateFromImage to get the VideoData
[22:23:06 CET] <durandal_1707> iive: its all cgi
[22:23:29 CET] <jya> philipl: looks like it
[22:23:31 CET] <iive> of course, the earth is flat.
[22:24:06 CET] <jya> \o/ ... the i9-7980EX has finally shipped
[22:24:29 CET] <durandal_1707> iive: im serious, look at that frames with car in space
[22:25:43 CET] <jya> philipl: if you have any questions, lodge them to the bug I pointed to earlier today, or put them on mozilla's irc #media and I'll get back to it tomorrow
[22:26:56 CET] <philipl> jya: Ok. Will do
[22:28:49 CET] <feliwir> hey, i have a video file that should be playable with ffmpeg but isn't picked up
[22:28:59 CET] <feliwir> could anyone maybe take a look? 
[22:30:55 CET] <feliwir> https://ufile.io/qrhak
[22:31:07 CET] <feliwir> this should be an EA container with vp6 content
[22:34:35 CET] <feliwir> ffmpeg-probe just says "Invalid data found when processing input"
[22:35:16 CET] <feliwir> nvm it's contained in another ea format
[22:35:57 CET] <JEEB> :)
[22:42:55 CET] <feliwir> well, now i really good a file that doesn't work
[22:44:09 CET] <feliwir> https://youtu.be/E-j66dZo3Ms?t=2m50s
[22:44:23 CET] <feliwir> those videos in the topright don't have alpha in ffmpeg
[22:46:41 CET] <feliwir> it only finds a single vp6 stream, but doesn't recognize the alpha channel
[22:47:31 CET] <feliwir> https://ufile.io/7hwh5
[22:47:55 CET] <feliwir> I fixed vp6 alpha in ea files already a while ago
[22:48:02 CET] <feliwir> but those are other files from newer games
[22:49:44 CET] <feliwir> there is some "ALhd" tag
[22:50:13 CET] <feliwir> https://github.com/FFmpeg/FFmpeg/blob/9ec8790ac4787d3d514c5fa27b66d581614fd1be/libavformat/electronicarts.c#L67
[22:50:19 CET] <feliwir> which is not supported
[22:57:31 CET] <philipl> jya: Well, I managed to get some recognisable frames on the screen with messed up chroma and then the process crashed. Progress.
[22:57:39 CET] <philipl> Had to disable seccomp sandbox for cuda
[22:58:09 CET] <jya> Not surprising that the sandbox would kick in.
[23:00:13 CET] <philipl> jya: It's not showing me a backtrace from the content process
[23:00:53 CET] <jya> Disable multi-process, much easier to debug
[23:01:38 CET] <jya> If you start Firefox using Mach, you do ./mach run --disable-e10s
[23:02:34 CET] <philipl> jya: thanks
[23:08:50 CET] <cone-205> ffmpeg 03Menno 07master:204c7caf0d77: avcodec/libopus: support disabling phase inversion.
[23:08:51 CET] <cone-205> ffmpeg 03Jérôme Martinez 07master:698d5eb5bf83: avcodec/ffv1: Support for RGBA64 and GBRAP16
[23:08:52 CET] <cone-205> ffmpeg 03Michael Niedermayer 07master:8f6a71f7f13d: avformat/bintext: Implement bin_probe()
[23:10:09 CET] <SortaCore> well, good thing I read the backlog
[23:10:20 CET] <SortaCore> otherwise I'd never have got so intimate with steven's connection
[23:11:19 CET] <philipl> jya: Ok, so my UV plane representation is wrong. Need to work out what it's expecting.
[23:12:14 CET] <philipl> jya: hard to tell if I'm supposed to just fill in one plane or I'm supposed to set it up to look at the interleaved plane as two planes (using skip and offsets)
[23:12:20 CET] <jya> As I said, it's very likely the nv12 image code is broken
[23:12:22 CET] <philipl> The only example I can see is a test that does this
[23:12:25 CET] <philipl> :-/
[23:13:07 CET] <jya> When I added the 10 bits support, I had to go over all images, and the calculations and handling of strides was all wrong
[23:14:18 CET] <jya> (For nv12)
[23:14:45 CET] <jya> I think I created a bug thst it was broken, but as it's currently unused no one cared.
[23:32:36 CET] <philipl> jya: getting closer. Got something that looks more correct before it crashes
[00:00:00 CET] --- Wed Feb  7 2018