[01:06:04 CEST] <Compn> i'll announce mplayer dead when vlc doesnt take 2 minutes to load on my slow computer :P [01:06:17 CEST] <Compn> otherwise mplayer file still is fastest... [01:06:25 CEST] <Compn> i kno he gone :P [03:45:34 CEST] <Chloe> Compn: have you tried mpv? [08:54:26 CEST] <cone-800> ffmpeg 03Vishwanath Dixit 07master:37abfe8c2dd9: avfilter/drawtext: present 'hms' formatted 'pts' in 24h format [10:16:54 CEST] <jya> anyone could point me at some code that would generate a dummy SPS NAL (i only want to check if the resolution is supported by the VideoToolbox H264 decoder) [10:26:05 CEST] <kierank> jya: https://git.videolan.org/?p=x264.git;a=blob;f=encoder/set.c;h=39e5f07d1dc597... [10:26:51 CEST] <jya> kierank: thanks... [11:51:14 CEST] <jdarnley> I shocked! There's no existing pd_2 assembly constant. [11:52:55 CEST] <jdarnley> ah, most of them are words [12:37:21 CEST] <jdarnley> Does anyone know how I can make objdump show the rodata section and disassemble the text section at the same time? [12:37:33 CEST] <jdarnley> Without using -s? [12:41:19 CEST] <jkqxz> "objdump -d -j .rodata -j .text ..."? [12:43:24 CEST] <jdarnley> That disassembles rodata rather than just showing its contents [12:43:51 CEST] <jkqxz> "-d", not "-D". [12:44:18 CEST] <jdarnley> which is what I typed [12:44:30 CEST] <jdarnley> i know -D is --disassemble-all [12:44:51 CEST] <jkqxz> Or is it somehow failing at recognising which segments would contain code for your platform? It works for me on x86-64 Linux. [12:46:05 CEST] <jdarnley> Maybe but this is only Arch Linux so not *that* obscure. [12:48:32 CEST] <jkqxz> <https://0x0.st/s_q7.txt> [12:49:26 CEST] <jdarnley> Maybe I'll blame the objects prodiced by NASM. [12:49:31 CEST] <jdarnley> *produced [12:49:45 CEST] <jdarnley> Thanks anyway [12:53:17 CEST] <jkqxz> It probably depends on the flag in the section header. Can nasm set those? [12:54:11 CEST] <jkqxz> Look at -h output. My .text section from gcc has "CONTENTS, ALLOC, LOAD, READONLY, CODE", while .rodata has "CONTENTS, ALLOC, LOAD, READONLY, DATA". [12:56:25 CEST] <jdarnley> It does set those and .text gets RELOC too [12:57:08 CEST] <jdarnley> .rodata seems to comes before .text in the file [12:57:31 CEST] <jkqxz> My function was trivial enough that it didn't need any relocations! [13:16:14 CEST] <atomnuker> why do you need to look at the disassembly of an assembly file? [13:20:10 CEST] <iive> can't objdump help with that? [14:59:29 CEST] <durandal_1707> kierank: are you sure about av_filter_frame(AVFrame *in, AVFrame **out)? is caller supposed to allocate output frame or callee? [15:00:20 CEST] <kierank> if it's NULL allocate internally, if not let the user provide [15:00:23 CEST] <kierank> but I prefer user [15:00:31 CEST] <kierank> allocating the avframe but not the data planes [15:10:49 CEST] <durandal_1707> kierank: and how to handle cases when filter needs more input frames for 1 output frame, or can give more output frames per 1 input frame? [15:11:15 CEST] <kierank> EAGAIN [15:16:36 CEST] <jkqxz> For non-1:1 cases it might be better to make it avfilter_send_frame() / avfilter_receive_frame(). [15:16:50 CEST] <jkqxz> That would also let you feed input to multiple pads. [15:16:52 CEST] <durandal_1707> but how will it know which of those 2 cases is actually happening [15:18:07 CEST] <jkqxz> You need a bit of state around it anyway, so something there. [15:21:03 CEST] <durandal_1707> jkqxz: how would you signal with avfilter_send_frame() to which input is frame sent? [15:21:21 CEST] <jkqxz> Extra int argument? [15:34:42 CEST] <durandal_1707> what if user calls avfilter_send_frame() too much times? [15:36:04 CEST] <jkqxz> EAGAIN. [15:36:57 CEST] <JEEB> what was the flow with the dec/enc api flow? [15:37:04 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [15:37:17 CEST] <JEEB> also doesn't this one ignore feeding different slots? [15:37:21 CEST] <JEEB> or did I miss something [15:37:31 CEST] <JEEB> such as overlay etc [15:38:50 CEST] <durandal_1707> jkqxz: EAGAIN means give me more.. it already gave too much, and any extra input should be just ignored [15:41:02 CEST] <jkqxz> EAGAIN means "not until something else happens". In this case the something else is you calling receive_frame(). [15:42:49 CEST] <durandal_1707> im running in circles [15:43:45 CEST] <jkqxz> I guess it depends what other people want from this one-filter API. [15:44:13 CEST] <jkqxz> If the 1:1 case is the most interesting then the single call would be simpler and better. [15:56:38 CEST] <nevcairiel> i would use it, but i need 1:n since i want it for deint [15:56:46 CEST] <nevcairiel> so an API like avcodec might be suitable [16:06:42 CEST] <nevcairiel> but i basically only ever use a single filter, so all that boilerplate around it is really a lot of noise [16:09:13 CEST] <jkqxz> Were there any thoughts on how this should be initialised? Do you have some sort of AVFilterSingleContext holding it? [16:11:01 CEST] <jdarnley> I need to stop writing my assembly with do-while loops when the rest of the code assumes a for loop. [16:12:28 CEST] <jdarnley> or just get the condition check right [16:36:17 CEST] <cone-452> ffmpeg 03Jerome Borsboom 07master:f56a0b02cdbf: avcodec/vc1: fix out-of-bounds reference pixel replication [18:14:40 CEST] <jkqxz> rcombs: Do you have any more context for that Apollo Lake issue? I've tried a few variations on it (input vaapi/yuv420p/nv12/p010, scale_vaapi to nv12, encode with H.264/H.265) and not seen any problems. [18:39:28 CEST] <rcombs> jkqxz: oh I totally forgot to mention, input is 10-bit HEVC and output is H264 [18:41:13 CEST] <rcombs> user was able to repro with http://jell.yfish.us/media/jellyfish-3-mbps-hd-hevc-10bit.mkv [18:41:51 CEST] <rcombs> example command that repro'd for the user: [ffmpeg] -hwaccel vaapi -ss 17 -i jellyfish-3-mbps-hd-hevc-10bit.mkv '-vaapi_device' '/dev/dri/renderD128' '-filter_complex' '[0:0]hwupload,scale_vaapi=w=1278:h=538:format=nv12,hwupload[0]' -map '[0]' -t 3 '-codec:0' 'h264_vaapi' '-b:0' '2717k' jellyfish-out2.mp4 [18:42:44 CEST] <rcombs> this ffmpeg is a few months behind at this point, but I don't see any obviously-relevant differences in vaapi code [18:45:16 CEST] <rcombs> and libva+driver are 2.1.0, which is latest [18:45:21 CEST] <rcombs> (but not master) [18:46:23 CEST] <jkqxz> So that's doing a download-upload probably in p010? [18:46:51 CEST] <jkqxz> I don't see anything funny with that file. [19:12:45 CEST] <rcombs> jkqxz: the actual command has `-hwaccel_output_format:0 vaapi`; happens whether with or without that [19:22:57 CEST] <jkqxz> I tried both. [19:23:51 CEST] <rcombs> hmm [19:23:59 CEST] <jkqxz> I guess I should try with the 2.1 release version. [19:24:31 CEST] <rcombs> it's a J3455 [19:24:57 CEST] <rcombs> here's the full thread https://forums.plex.tv/discussion/comment/1665703#Comment_1665703 [19:25:14 CEST] <jkqxz> This is an N4200. [19:26:22 CEST] <rcombs> I dunno how much the graphics vary between them [19:27:04 CEST] <rcombs> "HD Graphics 505" vs "HD Graphics 500" sounds like they _should_ be similar [19:28:08 CEST] <jkqxz> It's 18 vs. 12 execution units and a bit of clock speed. [19:28:15 CEST] <jkqxz> The video stuff should be identical. [19:30:32 CEST] <rcombs> my latest merge is with 0419623cdc [19:33:38 CEST] <jkqxz> Urgh, got it. What the hell. [19:34:35 CEST] <jkqxz> I think I might have had it earlier, but it's totally invisible most of the time. You really do need the jellyfish halfway through with tentacles pointing upwards. [19:46:29 CEST] <jkqxz> <http://ixia.jkqxz.net/~mrt/ffmpeg/apl/in.mp4> -> <http://ixia.jkqxz.net/~mrt/ffmpeg/apl/out.mp4> [19:46:55 CEST] <jkqxz> It does require the H.265 Main 10 input. [19:47:07 CEST] <rcombs> ah [19:48:24 CEST] <jkqxz> Uh, I mean it requires the 10-bit input. [19:48:38 CEST] <jkqxz> Decoding in software and uploading does fail. [19:50:35 CEST] <jkqxz> It's something to do with the scaling used. If you scale to 1280x720 then it doesn't happen. [19:51:00 CEST] <rcombs> huuuuh [19:51:12 CEST] <rcombs> maybe non-mod4? [19:52:22 CEST] <jkqxz> Oh, that might just be passthrough or not. Seems to happen with any non-1280x720 value with that 1280x720 input. [19:54:00 CEST] <jkqxz> Must be a driver issue somehow. I'll see if I can reproduce it on any other system and then raise a bug against the driver. [19:57:31 CEST] <rcombs> cool, thanks [21:25:09 CEST] <gagandeep> kierank: finally, the blurring will be solved, the last inverse transforms that i needed to apply weren't spatial but horizontal-temporal [21:25:18 CEST] <gagandeep> rest of the data is working good [21:25:57 CEST] <kierank> gagandeep: which blurring? [21:27:46 CEST] <gagandeep> i mean, the last inverses were causing problem, so the image quality wasn't perfect [21:28:19 CEST] <durandal_1707> atomnuker: you owe me reviewe [21:28:20 CEST] <gagandeep> the inverse was different and i was not able to see it as the last process was done in threads so was not visible [21:28:47 CEST] <gagandeep> will read in wavelet file of cfhd and perform the final inverse acording to specs [21:29:04 CEST] <gagandeep> other decoding and dequantization is running good [21:30:10 CEST] <gagandeep> though, it is good we were able to spot other nuances in interlacing issue as they could have caused problems with other samples [21:34:33 CEST] <gagandeep> durandal_1707 and kierank: you both were right there is some mixing in 2 frames at the initial transform [21:35:02 CEST] <gagandeep> i assumed mistakingly it was just spatial as they had used temporal afterwards as well [21:41:07 CEST] <atomnuker> durandal_1707: for the nlmeans audio denoiser? [21:43:16 CEST] <durandal_1707> atomnuker: yes [21:44:43 CEST] <atomnuker> "Deprecation of OpenGL and OpenCL" - "Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, but these legacy technologies are deprecated in macOS 10.14." [21:44:56 CEST] <atomnuker> welp, so much for opencl being supported everywhere [21:45:23 CEST] <nevcairiel> do they in the same sentence announce official Vulkan support, or are tehy just screwing everyone into using Metal? [21:45:53 CEST] <atomnuker> lol no, metal only [21:46:26 CEST] <nevcairiel> well if they actually remove OpenGL, I'll just petition work for dropping support entirely [21:49:02 CEST] <atomnuker> where? [21:57:48 CEST] <rcombs> "you know what macOS needed? its very own DirectX" [21:57:59 CEST] <rcombs> ETA on ANGLE Metal backend? [22:09:27 CEST] <iive> i think that there are project that implement d3d9 and d3d11 on vulkan, there is also project that implements vulkan on metal [22:10:14 CEST] <BtbN> ok, so on OSX there will be ANGLE on d3d11 on Metal soonß [22:10:43 CEST] <rcombs> there's a GL-on-Metal implementation, but khronos charges for it [22:14:19 CEST] <Chloe> there's a VK-on-Metal implementation too, which is free and open source [22:15:56 CEST] <rcombs> yeah, which is nice if you're already porting to vulkan [22:40:24 CEST] <cone-139> ffmpeg 03Vishwanath Dixit 07master:146cdf7e4bb0: fftools/ffmpeg: fix for all forced key frames when 'copyts' is enabled [00:00:00 CEST] --- Tue Jun 5 2018