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

[burek]

[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=39e5f07d1dc597303b5ba972529bafbca64fe4df;hb=HEAD#l270
[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