[00:09:37 CEST] <J_Darnley> FFS! This shit is impossible to get working. It's not the same as C. It's not the same as MMX. [00:09:53 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:88a2e4504d18: hevc: Fix scaling list prediction delta for the 32x32 inter matrix [00:10:27 CEST] <durandal_1707> J_Darnley: really? [00:11:43 CEST] <J_Darnley> As far as I can tell [00:12:27 CEST] Action: J_Darnley will slap together a commit and push that somewhere [00:12:32 CEST] <nevcairiel> did you guys ever figure out why mmx and C differ? That alone seems like a bad sign of the hacks to me [00:13:22 CEST] <J_Darnley> No [00:13:23 CEST] <kierank> no questioning old neckbeard code nevcairiel! [00:13:53 CEST] <J_Darnley> I never went looking for emails from 2002 which I think is where the 16383 comes from. [00:16:54 CEST] <J_Darnley> If you only skimmed the discussion earlier I think it could be summed up as "16383 was a better match for other encoders at the time" [00:18:45 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:900fe8ee5d17: avcodec/dnxhdenc: Assert that frame size is not assigned an error code [00:18:46 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:0a87be404ab7: avcodec/mpeg4videodec: Fix integer overflow in num_sprite_warping_points=2 case [00:18:47 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:12245ab1f677: avcodec/mpeg4videodec: Check sprite delta upshift against overflowing. [00:20:11 CEST] <iive> J_Darnley: I thought that the C version remained with 16384 has been kept in C code, because it is done by shift and is faster (with int) [00:20:29 CEST] <iive> on mmx it doesn't matter, since it uses mul anyway. [00:20:54 CEST] <iive> ops... [00:21:06 CEST] <J_Darnley> In the "dc only" bit it will use 16384 but in the actual idct it will use 16383 [00:21:23 CEST] <iive> c or mmx ? [00:22:13 CEST] <cone-862> ffmpeg 03James Almer 07master:37388b119cf8: checkasm: add a checkasm_checked_call function that doesn't issue emms [00:22:14 CEST] <cone-862> ffmpeg 03James Almer 07master:5b10f484e2b3: checkasm: add float_dsp tests [00:22:15 CEST] <cone-862> ffmpeg 03James Almer 07master:e53c9065ca08: avutil/tests: remove float_dsp test [00:22:21 CEST] <J_Darnley> Both I think. [00:27:37 CEST] <iive> so... if both do the same, what causes the difference [00:27:58 CEST] <BBB> J_Darnley: wait I thought with my changes it matches? [00:28:02 CEST] <J_Darnley> I wish I knew [00:28:05 CEST] <BBB> J_Darnley: or is there another issue that I caused? [00:28:33 CEST] <J_Darnley> BBB: dct is the same on all 3 tests [00:28:44 CEST] <BBB> ok, so thats promising, right? [00:28:44 CEST] <J_Darnley> but I get an error with a vsynth2 test [00:28:48 CEST] <J_Darnley> Yes! [00:28:52 CEST] <BBB> hm... [00:29:28 CEST] <BBB> can you set aborts in each of put, add and regular idct to see which ones it calls? [00:29:39 CEST] <BBB> or breakpoints [00:29:43 CEST] <BBB> I guess I can do it myself as well [00:29:47 CEST] <BBB> which vsynth2 test? [00:30:47 CEST] <J_Darnley> I think it was fate-vsynth1-wmv1 [00:30:55 CEST] <J_Darnley> (so not vsynth2) [00:33:26 CEST] <iive> J_Darnley: so... there is difference between C and MMX version and you don't know what causes it. [00:33:53 CEST] <iive> and there is difference between MMX and SSE2 version and you don't know what causes that either? [00:34:07 CEST] <BBB> do you know from the multiple commands it executes (see V=1) whether its the encode or decode that changed? [00:34:22 CEST] <J_Darnley> I think it must be the decode [00:34:32 CEST] <J_Darnley> the input video is generated [00:34:56 CEST] <J_Darnley> oh but the encoder needs to decode to produce ref frames [00:35:45 CEST] <iive> J_Darnley: can you setup a bit of glue code, that uses both mmx and sse idct and checks if their result differ? [00:35:45 CEST] <J_Darnley> so in that case... both? [00:36:03 CEST] <J_Darnley> that is libavcodec/tests/dct [00:36:21 CEST] <J_Darnley> It doesn't directly compare, that is out job [00:36:31 CEST] <J_Darnley> I guess I could modify it. [00:36:35 CEST] <iive> J_Darnley: do you have a specific input that causes a difference [00:36:53 CEST] <iive> you don't need statistics, you need a specific input. [00:36:54 CEST] <J_Darnley> Not with tool [00:37:22 CEST] <BBB> J_Darnley: can you run md5 on the generated file to see whether encode changed before/after your changes? [00:37:28 CEST] <BBB> thats actually helpful to know [00:38:22 CEST] Action: J_Darnley swears [00:38:26 CEST] <J_Darnley> In a moment [00:51:44 CEST] <BBB> lol [00:51:49 CEST] <BBB> I think youre pretty close [00:51:58 CEST] <BBB> if wmv failed, that means its probably a type check missing somewhere [00:52:05 CEST] <BBB> but it suggests the larger body of work is finished [00:52:39 CEST] <jkqxz> wm4: The obvious change is not going to work because of the videotoolbox_pixfmt thing (which looks like some sort of crazy hack). I think it needs someone who can actually compile it to look. [00:53:22 CEST] <wm4> what thing? [00:53:53 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_opt.c;h=bb6001f534d0c82592a56b3d4efe315466b49d70;hb=HEAD#l3609> [00:54:11 CEST] <jkqxz> Which gets to <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_videotoolbox.c;h=e9039654b93de84cfb1fe4c1387dc036fa777249;hb=HEAD#l155>. [00:54:19 CEST] <wm4> oh that [00:54:29 CEST] <wm4> you can just set the format on the hwframes ctx [00:54:36 CEST] <jkqxz> So it's -hwaccel_output_format except using the native name? [00:54:45 CEST] <jkqxz> Or something else. [00:54:59 CEST] <jkqxz> Ha, does that need init_hw_frames then? [00:55:06 CEST] <wm4> yeah I think it uses a native name [00:55:12 CEST] <wm4> hm probably [00:55:28 CEST] <wm4> videotoolbox is pretty "special" in that it can output any format, and the decoder/whatever converts [00:55:43 CEST] <wm4> so this is atypical [00:56:03 CEST] <wm4> (another +1 for VT as standalone decoder instead of hwaccel) [00:57:19 CEST] <nevcairiel> wasnt the problem with that that the VT API is dumb as fuck and requires a lot of code, including re-ordering? [01:09:23 CEST] Action: J_Darnley facepalms [01:09:42 CEST] <J_Darnley> I will address *that* bug later [01:10:29 CEST] <wm4> nevcairiel: yes, we'd have to do reordering ourselves [01:10:32 CEST] <J_Darnley> Okay, good. Back on course [01:11:12 CEST] <nevcairiel> you would also end up duplicating all sorts of SEI handling and whatnot, which is why hwaccels are so nice, you get all of that for free [01:11:25 CEST] <wm4> videotoolbox is really a hysteric API... it's neither hwaccel not full decoder, and just makes your life harder for no reason at all [01:11:35 CEST] <iive> J_Darnley: do you have a debugger where you can step through the asm code and see the registers? [01:11:43 CEST] <J_Darnley> Yes, gdb [01:12:09 CEST] <iive> does gdb have a mode where it outputs the changed register automatically? [01:12:31 CEST] <J_Darnley> Maybe, I don't know it though. [01:12:57 CEST] <iive> i've looked and i haven't found it. [01:13:15 CEST] <iive> last time i tried ddd also didn't had it. [01:14:42 CEST] <iive> J_Darnley: you might want to give a try to `edb` it is assembler oriented and i find it quite useful, despite needing some polish. [01:15:12 CEST] <J_Darnley> noted [01:15:14 CEST] <iive> i'm also not sure if it supports avx and ymm, but it works for sse [01:15:54 CEST] <J_Darnley> BBB: the encoded video differs [01:16:22 CEST] Action: J_Darnley can't believe that took him 30 minutes [01:16:48 CEST] <J_Darnley> Also, you should use the mpeg2_asm5 branch on my gitlab [01:17:30 CEST] <J_Darnley> It avoids a bug I've got in add/put and has your patch working. [01:17:37 CEST] <kierank> J_Darnley: what was the problem [01:18:02 CEST] <J_Darnley> We don't know yet [01:18:28 CEST] <kierank> ok [01:18:52 CEST] <J_Darnley> But my 30 minute problem was trying to make a clean commit [01:19:13 CEST] <J_Darnley> That didn't make a step backwards [01:22:08 CEST] <kierank> anyway it will make a good blog [01:55:42 CEST] <BBB> J_Darnley: okiedokie, good to know. I will check wmv2enc [01:58:54 CEST] <BBB> oh, not wmv2enc [01:58:56 CEST] <BBB> hm... [02:01:22 CEST] <BBB> J_Darnley: why FF_IDCT_SIMPLE as idct_algo in your assignment? [02:01:28 CEST] <BBB> J_Darnley: the mmx function doesn't [02:02:05 CEST] <J_Darnley> So that it runs more in fate [02:04:00 CEST] <BBB> but its not compatible with FF_IDCT_SIMPLE, I think [02:07:04 CEST] <BBB> (I dont know why, but the mmx function is also not assigned for algo==simple) [02:08:41 CEST] <BBB> its possible that it doesnt have to do much with the idct itself, but rather with the fact that perm_type is not default for the non-C version [02:08:43 CEST] <BBB> I dont know [02:19:39 CEST] <J_Darnley> Can I ask you to revert that and then test fate? [02:25:47 CEST] <philipl> jkqxz: So what's the generic hwaccel syntax I should try for cuda? Is it documented in your changes? [02:33:10 CEST] <J_Darnley> I get no errors in that case. But I also got no errors on fate before michaelni made us go looking for problems. [02:41:10 CEST] <philipl> \jkqxz: Looks like something like "ffmpeg -y -hwaccel cuvid -hwaccel_output_format cuda -c:v h264_cuvid -i sample.mp4 -c:v h264_nvenc -map 0:0 -f rawvideo /dev/null" [02:44:17 CEST] <J_Darnley> What the fuck have I been doing this week? [02:44:33 CEST] <J_Darnley> Wasting everyone's time by the look of it. [02:47:20 CEST] <philipl> BtbN, jkqxz: https://github.com/philipl/FFmpeg/commit/951e804c33bf77d87c67e11b9354c3c2672... [03:10:31 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:1cb4ef526dd1: avcodec/hevc_refs: Check nb_refs in add_candidate_ref() [03:10:32 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:bc4067446207: avcodec/hevcdec: Check nb_sps [03:11:54 CEST] <J_Darnley> Christ. I think I might have finished. [03:12:07 CEST] <J_Darnley> I do have a bug in my add function. [03:12:41 CEST] <J_Darnley> the sse2 branch didn't store correctly [03:13:13 CEST] <J_Darnley> I added a new fate test based on that matrixbench clip michaelni pointed out. [03:13:59 CEST] <J_Darnley> That does manage to get identical output for C, MMX, and now SSE2 [03:17:04 CEST] <J_Darnley> Maybe this week hasn't been wasted [03:21:03 CEST] <J_Darnley> Pull my mpeg2_asm5 branch and make fate-simpleauto [03:21:11 CEST] <J_Darnley> Good night [11:21:26 CEST] <cone-854> ffmpeg 03Paul B Mahol 07master:9b667f609c50: avfilter/af_headphone: fix possible memory leaks on failure [12:10:15 CEST] <BBB> should --enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no] disappear from configure? [12:10:20 CEST] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=e3941f9dfd79557af... [12:13:44 CEST] <BBB> J_Darnley: I just noticed your msgs yesterday, good idea to add a fate test [12:14:03 CEST] <BBB> J_Darnley: does the fate test execute all three (idct, idct_put and idct_add) versions of the function? [12:14:35 CEST] <BBB> J_Darnley: and a potential problem may be that the fate test does not give the same results across platforms ... [12:20:27 CEST] <J_Darnley> It does do both add and put. If forgot to check whether the plain idct is used. [12:25:13 CEST] <J_Darnley> Ah. A quick check suggests that it does not use the plain idct. [14:33:59 CEST] <atomnuker> durandal_1707: bored? there's still an atrac9 decoder to write [14:39:06 CEST] <JEEB> :D [14:39:23 CEST] <JEEB> I had a dump of the reference binary somewhere [17:06:04 CEST] <BBB> J_Darnley: hurray [17:06:10 CEST] <J_Darnley> FUCK HOW THE FUCK DID I DROP THAT FUCKING CHANGE GOD FUCKING DAMMIT [17:06:26 CEST] <BBB> hey hey hey now now now [17:06:32 CEST] <BBB> hush [17:06:43 CEST] <BBB> I think dc-only is a fine name btw [17:06:44 CEST] <J_Darnley> I somehow dropped the 32 byte stack space change [17:06:56 CEST] <BBB> in a 2d context, dc is top/left [17:07:00 CEST] <BBB> in a 1d context, dc is just the first [17:07:01 CEST] <RiCON> BBB: what's wrong with fdk-aac? [17:07:06 CEST] <BBB> it was dropped [17:07:12 CEST] <BBB> but the configure option is still there [17:07:16 CEST] <RiCON> it was? [17:07:19 CEST] <BBB> I believe so [17:07:29 CEST] <RiCON> i don't believe so [17:07:35 CEST] <BBB> oh wait its still there [17:07:36 CEST] <BBB> nevermind [17:07:38 CEST] <BBB> <- stupid [17:07:41 CEST] <RiCON> faac and aacplus were [17:07:58 CEST] <BBB> aha ok [17:08:27 CEST] <atomnuker> michaelni: why does ffv1 have a max packet size? [17:08:34 CEST] <BBB> I believe next, we should drop support for all hevc decoders and deprecate hevc :-p [17:08:39 CEST] <BBB> hevc encoders* [17:08:52 CEST] <atomnuker> it breaks encoding of high resolution (e.g. 15000x9000) images [17:09:38 CEST] <atomnuker> and ffv1 and png are the only ones capable of lossless rgb I think [17:09:50 CEST] <atomnuker> (and png is slow and very inefficient) [17:10:35 CEST] <RiCON> doesn't x264 do lossless rgb too? [17:10:38 CEST] <BBB> J_Darnley: is simple_auto maybe a poor fate test because its results will differ from arch to arch? [17:15:38 CEST] <BBB> J_Darnley: the rest looks good to me, nice! [17:15:48 CEST] <BBB> J_Darnley: I look forward to the angry blog post :D [17:17:46 CEST] <J_Darnley> I will endavour to leave out the swearing rant sections. [17:18:04 CEST] <J_Darnley> And I forgot the message-id for that email. [17:18:08 CEST] <BBB> its ok [17:18:23 CEST] <BBB> maybe you shouldnt blog, but do a VDD talk about this work [17:25:05 CEST] <jkqxz> But the swearing rant sections are the best bits! [17:26:39 CEST] <jkqxz> On the subject of swearing rants, do people actually approve of the NV12 warning patch or not? [17:29:36 CEST] <BBB> Im indifferent to it [17:29:39 CEST] <BBB> I think its fine [17:43:19 CEST] <cone-959> ffmpeg 03Tyler Jones 07master:5a2ad7ede33b: vorbisenc: Separate copying audio samples from windowing [17:43:20 CEST] <cone-959> ffmpeg 03Tyler Jones 07master:f57f66518359: vorbisenc: Apply and output correct length window and mdct [17:43:21 CEST] <cone-959> ffmpeg 03Tyler Jones 07master:752dd1952a7b: vorbisenc: Stop tracking number of samples per frame [18:10:55 CEST] <kierank> BBB: should we submit it to demuxed or is it too technical for them? [18:11:20 CEST] <BBB> I thought the goal of demuxed was to be technical? :-p [18:11:26 CEST] <BBB> peloverde: ^^ [18:20:31 CEST] <kierank> I've submitted something myself but in a different area (uncompressed video transport) [18:59:10 CEST] <philipl> jkqxz: I lost track - what's the plan for not having to specify the output format to ffmpeg to make transcoding work without download/upload by default? [19:01:57 CEST] <jkqxz> No plan yet. I was wondering whether we could do it by detecting fake hwaccels, or maybe there could be a new flag in the HWAccel table? [19:04:18 CEST] <wm4> fake hwaccels? wut? [19:33:32 CEST] <cone-959> ffmpeg 03Rostislav Pehlivanov 07master:b52b398c30a7: vc2enc: decrease default strictness level [19:48:21 CEST] <michaelni> atomnuker, the max packet size is the worst case size, its smaller in version > 3. It could be reduced in older versions if some reallocation support is added [19:49:02 CEST] <michaelni> it would be trivial to realloc if it wasnt for the slice / thread code [19:49:03 CEST] <atomnuker> but it can be exceeded, so its not the worst case [19:49:23 CEST] <michaelni> it should not be exceeded [19:49:33 CEST] <atomnuker> so its a bug then? [19:49:56 CEST] <michaelni> dunno, but sounds like one, how can it be reproduced? [19:50:14 CEST] <atomnuker> "[ffv1 @ 0x3770f00] Cannot allocate worst case packet size, the encoding could fail" [19:50:29 CEST] <michaelni> "could fail" doesnt mean it does fail [19:50:30 CEST] <atomnuker> makes it sound like I'm running out of memory [19:50:40 CEST] <atomnuker> "Assertion bytes < (1 << 24) failed at libavcodec/ffv1enc.c:1216" [19:50:53 CEST] <michaelni> assert failure is always a bug [19:51:13 CEST] <nevcairiel> worst case is quite huge, it could overflow 32-bit, maybe you should try a 64-bit build [19:52:23 CEST] <atomnuker> ./ffmpeg_g -f rawvideo -s 14027x9924 -pix_fmt rgb24 -i /dev/urandom -frames 1 -c:v ffv1 -f null - [19:52:31 CEST] <atomnuker> this always fails here [19:52:40 CEST] <nevcairiel> worst case for ffv1 1 and 3 is w*h*37*4 [19:52:45 CEST] <nevcairiel> so thats 20602184304 bytes [19:53:15 CEST] <atomnuker> happens with -level 4 as well [19:53:25 CEST] <nevcairiel> its w*h*3*4 for 4 [19:54:01 CEST] <nevcairiel> that should in theory fit into an int though [19:55:29 CEST] <atomnuker> seems like it doesn't though, it exceeds INT_MAX - 64 [19:57:10 CEST] <nevcairiel> its still a huge buffer and easy to run out of memory from [19:57:51 CEST] <atomnuker> you might be right actually [19:58:10 CEST] <atomnuker> didn't realize the worst case packet is *that* big [19:58:37 CEST] <atomnuker> 19 gigabytes, damn [20:00:01 CEST] <atomnuker> I think there should be an option which insteads uses a lower worst case packet size and instead reallocs if the buffer runs out, though it'll be slower and messier [20:01:24 CEST] <atomnuker> or maybe something like running the encoder once to determine the exact buffer size needed [20:04:49 CEST] <nevcairiel> at least 4 has a PCM mode that greatly reduces the worst case [20:06:32 CEST] <nevcairiel> and you could probably reduce the worst case further if you made it dependent on the pixel format used, instead of a generic value for all [20:27:56 CEST] <michaelni> yes, there also seems to be a bug in slices with huge resolutions [22:50:03 CEST] <BBB> wbs: do you have any recollection what type of decoding speed I could expect for regular content at typical resolutions using e.g. 1 core on aarch64? [22:50:16 CEST] <BBB> wbs: e.g. 10fps? 50fps? 5000 fps? [22:53:46 CEST] <atomnuker> on an odroid c2 for a standard 1080p24 bluray m2ts I get around 14fps with 1 thread [22:54:39 CEST] <atomnuker> divide that by 4 or 5 for a raspberry pi 3 even if you somehow get some aarch64 image running [22:58:00 CEST] <atomnuker> 10 fps now after letting it run for 5 minutes [22:58:59 CEST] <atomnuker> no audio decoding, just ~30mpbs h264 (or were you interested in vp9?) [23:01:27 CEST] <durandal_1707> atomnuker: filter status asap! [23:03:07 CEST] <atomnuker> nothing new since tuesday, but I'll have something to review by sunday [23:03:49 CEST] <atomnuker> durandal_1707: how is the ambisonics gsoc going? [23:05:29 CEST] <durandal_1707> well, its mainly figuring proper stuff for making decoder ambidonic regarding various speakers layouts [23:06:48 CEST] <atomnuker> isn't it going to only support outputting to headphones initially? [23:07:14 CEST] <durandal_1707> that would be too trivial to do [23:08:55 CEST] <J_Darnley> Did someone recently flush the moderation queue for ffmpeg-user? [23:09:15 CEST] <durandal_1707> why? [23:11:37 CEST] <J_Darnley> I just noticed a few old emails that were marked unread [23:22:17 CEST] <BBB> atomnuker: vp9 obviously :-p [23:22:39 CEST] <BBB> atomnuker: all these devices have hw h264 decoders ;) [23:24:11 CEST] <TD-Linux> unfortunately there's a lot of variance for aarch64... the a57 has double the throughput per-clock as the a53, for example [23:31:13 CEST] <atomnuker> BBB: around 24 fps for a 1080p30 at ~3.5Mbps youtube rip on a single thread [23:32:06 CEST] <atomnuker> for a month old 3.3 release [23:32:21 CEST] <BBB> wow :) [23:33:14 CEST] <JEEB> atomnuker: vp9? nice [23:34:17 CEST] <atomnuker> will try git master if I can get it to build without much trouble [23:34:41 CEST] <atomnuker> to hell with gas and that damned script [23:35:23 CEST] <jamrial> oh neat, we have aarch64 vp9 asm [23:35:39 CEST] <BBB> wbs is a hero [23:44:04 CEST] <BBB> atomnuker: thanks for testing [00:00:00 CEST] --- Fri Jun 16 2017