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

[burek]

[04:42:59 CET] <cone-918> ffmpeg 03Philip Langdale 07master:bb4c9d0a8ead: avcodec: Don't assume separate u and v planes in ff_alloc_picture
[04:43:00 CET] <cone-918> ffmpeg 03Philip Langdale 07master:912ceba61b0d: avcodec: Implement vc1 nvdec hwaccel
[05:18:47 CET] <cone-918> ffmpeg 03James Almer 07master:c4131a0613c4: avcodec: deprecate getters and setters for AVCodecContext and AVCodec fields
[05:18:48 CET] <cone-918> ffmpeg 03James Almer 07master:e9025beacb86: ffmpeg: remove usage of AVCodecContext accessors
[05:18:49 CET] <cone-918> ffmpeg 03James Almer 07master:b2731bcd1dc7: ffprobe: remove usage of AVCodecContext accessors
[05:18:50 CET] <cone-918> ffmpeg 03James Almer 07master:e61825d5b4c3: ffplay: remove usage of AVCodecContext accessors
[05:18:51 CET] <cone-918> ffmpeg 03James Almer 07master:21add0c228e0: avcodec/pthread_frame: remove usage of AVCodecContext accessors
[05:18:52 CET] <cone-918> ffmpeg 03James Almer 07master:03dae121c050: avfilter/vf_subtitles: remove usage of AVCodecContext accessors
[05:18:53 CET] <cone-918> ffmpeg 03James Almer 07master:d8ea66ab3325: avformat/utils: remove usage of AVCodecContext accessors
[06:05:10 CET] <philipl> BtbN: mpeg4 is proving obnoxious with weird flags that don't obviously map to anything the other hwaccels do.
[06:05:22 CET] <philipl> Did you try capturing the param values from the nvidia parser?
[06:05:27 CET] <philipl> I think that's my next step
[06:13:20 CET] <tmm1> is there a way for filter_frame to trigger config_props on the outlink
[06:20:06 CET] <tmm1> i want my filter to set the output w/h on a per-frame basis
[07:26:16 CET] <philipl> BtbN: so, it looks like the mpeg4 decoder is expecting the full chunk of frame data and the hwaccel hook is sending it without some of the header.
[07:26:31 CET] <philipl> I ended up comparing slice lengths and they differ
[09:52:01 CET] <nevcairiel> mpeg4 has always been a bit iffy because of all the hacks around that format
[09:52:34 CET] <nevcairiel> the cuvid parser is also not quite fool proof with mpeg4 and various bitstream "features"
[10:45:03 CET] <cone-854> ffmpeg 03Hendrik Leppkes 07master:6fcbf39f9ec7: nvenc: factor context push/pop into functions
[10:45:04 CET] <cone-854> ffmpeg 03Hendrik Leppkes 07master:bff6d98ba3e7: nvenc: support d3d11 surface input
[10:47:32 CET] <BtbN> philipl, for VP9 is pretty much dumped both the ffmpeg and the nvcuvid parameters, and searched for matching things that weren't obvious
[11:16:56 CET] <durandal_1707> C90 mixed declaration and code in libavutil/timer.h
[16:29:43 CET] <philipl> BtbN: It's confusing. The decode_slice callback passes a smaller buffer than what the cuvid parser passes, and start_frame passes a larger buffer.
[16:30:11 CET] <SortaCore> how do I invoke D3D11VA on Windows? it's saying h264_vaapi encoder is missing when I just make'd it
[16:30:30 CET] <philipl> So they seem to strip off only part of whatever our parser considers to be the header
[16:31:39 CET] <JEEB> SortaCore: the hwaccel decoding example uses D3D11VA and DXVA2, and it should work
[16:35:56 CET] <SortaCore> for encoding?
[16:36:12 CET] <JEEB> is there D3D11VA encoding?
[16:37:08 CET] <SortaCore> there's an encoder for it
[16:37:19 CET] <SortaCore> hol' up I'll check configure
[16:38:45 CET] <JEEB> nope, seems not to have. nvenc did get support for getting d3d11va surfaces, though
[16:39:07 CET] <SortaCore> hwaaccel for d3d11va2, and I assumed the encoder was the one with va, h264_vaapi
[16:39:17 CET] <JEEB> vaapi is *nix API
[16:39:48 CET] <SortaCore> so what's the best encoder for d3d11?
[16:39:53 CET] <SortaCore> barring nvenc
[16:40:15 CET] <JEEB> there is none that uses just DXVA/D3D11 APIs as far as I can see, if there are such APIs
[16:40:23 CET] <JEEB> watches are pelcome if such API exists
[16:42:07 CET] <SortaCore> ok, and with the nvenc, I have encoders for h264_nvenc,nvenc,nvenc_h264, which should I add to configure
[16:46:24 CET] <nevcairiel> philipl: how much smaller? maybe it needs some sort of startcodes
[16:46:56 CET] <nevcairiel> JEEB: no such API; only vendor stuff
[16:48:22 CET] <philipl> nevcairiel: So, just looking at the first few frames of my sample (which has packed b-frames, for my sins), I see three/four types of frames.
[16:48:46 CET] <philipl> There's the initial I frame which is non-trivially sized. I'll come back to those numbers.
[16:49:42 CET] <philipl> There's a few that are always 130 bytes in cuvid and either 139 or 131 from start_frame
[16:49:44 CET] <jkqxz> NVENC accepts D3D11 input now, and AMD has it pending in their stuff.  It's broken in libmfx (D3D11 texture arrays, that is; DXVA2 input does work), but Intel people have expressed interest in supporting it so maybe in future.
[16:49:55 CET] <philipl> Then there are the packing markers which are 9 bytes in both cases
[16:51:10 CET] <philipl> If I use the decode_slice buffer, then the 130 byte slice is 131 and 9 the byte one is 1 byte
[16:51:39 CET] <philipl> For the I frame, the numbers are: cuvid 2683, start_frame 2741, decode_slice 2676
[16:52:23 CET] <philipl> For reference, the vdpau hwaccel uses the buffer from start_frame and not decode_slice, so it seems logical that nvdec would be the same, but that doesn't lead it working
[16:52:36 CET] <philipl> This is where we wish we could see the cuvid parser code.
[16:52:57 CET] <nevcairiel> i told you, mpeg4 is all sorts of fucky
[17:30:35 CET] <SortaCore> so is there any way to run ffmpeg decoding single-threaded
[17:31:23 CET] <JEEB> -thread 1
[17:31:36 CET] <JEEB> and you can set the amount of threads in the AVCodecContext
[17:31:47 CET] <cone-854> ffmpeg 03Michael Niedermayer 07master:380b48fb9fdc: avcodec/h264dec: Fix potential array overread
[17:31:48 CET] <cone-854> ffmpeg 03Michael Niedermayer 07master:eec67f7b24da: avcodec/dvbsubdec: Avoid re-computing clut
[17:31:49 CET] <cone-854> ffmpeg 03Michael Niedermayer 07master:6d00905f8134: avcodec/vc2enc: Clear coef_buf on allocation
[17:31:55 CET] <SortaCore> in C++
[17:32:04 CET] <SortaCore> I mean the receive -> decode loop
[17:32:13 CET] <SortaCore> catch up on network packets and then resume rest of app
[17:32:38 CET] <JEEB> I did reply :P
[17:32:43 CET] <JEEB> also this stuff is #ffmpeg material
[17:33:00 CET] <SortaCore> yea
[17:41:41 CET] <BtbN> philipl, I have absolutely zero experience with mpeg1/2/4
[18:09:57 CET] <philipl> BtbN, nevcairiel: Yeah, this is all kinds of shitty. I'll take a look at mpeg2; maybe that will work cleanly. *sigh*
[18:10:21 CET] <BtbN> wait, there are hwaccel hooks for more than mpeg2?
[18:10:47 CET] <BtbN> philipl, have you checked if the buffer it gives you is cut off at the beginning or the end?
[18:10:54 CET] <BtbN> Maybe ffmpeg just has padding at the end or something?
[18:11:15 CET] <BtbN> For h264/hevc, it has to add the startcode as well
[18:14:31 CET] <nevcairiel> mpeg2 should be fine, its supported by all others
[18:15:28 CET] <nevcairiel> mpeg4 is just special
[18:16:12 CET] <BtbN> Isn't mpeg4 also the one with all the tons of vendor-specific variants like DivX and xvid?
[18:23:50 CET] <jamrial> jkqxz: i'm trying to test your opencl patchset. do you have a sample command line like the one you posted for vaapi?
[18:29:13 CET] <jkqxz> For what?
[18:29:48 CET] <jkqxz> If you just want opencl in isolation (without any interop) then add hwupload/hwdownload around the opencl filters.
[18:30:47 CET] <jamrial> do i need -init_hw_device? I can't seem to find a way to get a device name to pass to it
[18:31:08 CET] <jkqxz> Ohyeah, you need that too.
[18:31:22 CET] <jamrial> i have an amd gpu on windows
[18:31:45 CET] <jamrial> clinfo mentions "Tahiti" as name for the gpu device, but that doesn't seem to work
[18:31:50 CET] <jamrial> it just errors out with "More than one matching device found"
[18:31:54 CET] <jkqxz> The name you can pass is the platform.device index.
[18:32:07 CET] <jkqxz> And you can also match by the device strings.
[18:32:39 CET] <jkqxz> Try "opencl:,device_name=Tahiti"?
[18:33:07 CET] <jkqxz> The clinfo program should be able to tell you the index numbers / strings you can use.
[18:38:43 CET] <jamrial> jkqxz: https://pastebin.com/raw/JMHg8KZk curious, two platforms
[18:46:59 CET] <jkqxz> Er, wtf?  Give it "opencl:0.0", I guess.
[18:47:18 CET] <jkqxz> (Maybe two different versions of the driver both installed?  I would have expected it to stop you doing that sort of thing.)
[18:48:53 CET] <jamrial> jkqxz: uninstalled the sdk and there's now one platform
[18:49:00 CET] <jamrial> weird
[18:49:19 CET] <jamrial> i copied the libraries and headers to the mingw folder anyway
[18:50:09 CET] <jkqxz> You shouldn't need the libraries, just the ICD loader which is part of Windows (it's in c:\windows\system32).
[18:50:51 CET] <jkqxz> And the headers are packaged by mingw, "opencl-headers".
[18:51:41 CET] <jkqxz> But using the AMD SDK ones would work, sure.
[18:52:50 CET] <jamrial> ah, wasn't aware msys2 shipped opencl headers
[18:54:02 CET] <jkqxz> So I think the minimal setup in msys2 is to install the opencl-headers package and to copy c:\windows\system32\opencl.dll to somewhere in the library search path.
[18:56:16 CET] <BtbN> nevcairiel, the nvenc d3d11va patches broke cygwin. It seems to be in some weird in-between state that confuses stuff
[18:56:24 CET] <BtbN> well, the one patch, not patches
[18:56:45 CET] <BtbN> A bit confused about the way it breaks though: ./libavutil/hwcontext_d3d11va.h:124:5: error: unknown type name 'intptr_t'
[18:57:05 CET] <BtbN> CONFIG_D3D11VA is yes, so this should have broken before? Or all other uses just include the right header first.
[18:57:23 CET] <jkqxz> checkheaders should have found that if it's a problem.
[18:58:11 CET] <BtbN> is that some fate test?
[18:58:30 CET] <jkqxz> Yeah.
[18:58:36 CET] <jamrial> no, make checkheaders is not run as part of fate
[18:58:43 CET] <jamrial> it's run as part of make check, though
[18:59:16 CET] <jkqxz> Which is what everyone runs before pushing, right?
[18:59:37 CET] <jamrial> hah :p
[18:59:39 CET] <BtbN> Well, there is no issue on Linux or MSVC, or mingw
[18:59:43 CET] <BtbN> it only explodes on cygwin
[19:01:04 CET] <BtbN> The header is just plain missing an include on stdint.h or whatever one includes nowdays
[19:01:06 CET] <jamrial> BtbN: none of nevcairiel's patches touch hwcontext stuff, though
[19:01:20 CET] <BtbN> yes, it's broken like that since forever
[19:01:31 CET] <jamrial> oh wait, it included it in nvenc.h
[19:01:41 CET] <BtbN> It just never blew up, because everything including that header included stdint first
[19:01:59 CET] <BtbN> And I'm also slightly confused why it only breaks on cygwin
[19:02:50 CET] <jkqxz> Does it have a different d3d11.h somehow?
[19:03:01 CET] <BtbN> It has its own one somewhere, yes.
[19:03:05 CET] <BtbN> make checkheader also fails on the file
[19:03:15 CET] <jkqxz> (Which doesn't include stdint indirectly somehow.)
[19:03:24 CET] <jamrial> checkheaders passes on mingw64
[19:04:22 CET] <jamrial> maybe intptr_t is defined in stddef.h on cygwin
[19:04:38 CET] <jamrial> like ptrdiff_t
[19:06:12 CET] <BtbN> well, just including stdint.h in hwcontext_d3d11va.h should be fine
[19:06:56 CET] <BtbN> oh great, and once that's resolved it blows over because it double-defines GUID
[19:07:36 CET] <jkqxz> configure += "if cygwin ; then disable d3d11 ; fi
[19:07:45 CET] <BtbN> d3d11 works though
[19:07:51 CET] <BtbN> so no reason to disable something that's working
[19:12:13 CET] <J_Darnley> fg
[19:25:54 CET] <tmm1> i'm trying to write a vf that changes resolution mid stream.. i'm setting the outlink's w/h but it doesn't seem to reconfig the encoder on the other side
[19:27:42 CET] <BtbN> I highly doubt doing that is supported
[19:28:04 CET] <atomnuker> no encoder I know of in our codebase supports it
[19:31:10 CET] <nevcairiel> cygwin sure sounds broken, shouldnt they just use mingw headers
[19:32:20 CET] <BtbN> It looks like those are mostly just mingw headers
[19:32:40 CET] <BtbN> d3d11.h might be from wine
[19:32:49 CET] <BtbN> carries a /*** Autogenerated by WIDL 1.6 from direct-x/include/d3d11.idl - Do not edit ***/ header
[19:34:11 CET] <jamrial> so does the mingw-w64 one
[19:54:13 CET] <philipl> BtbN: There's literally a 'divx_flags' field in the mpeg4 params we have to fill in. Apparently my test file has a value of '5' from the cuvid parser. Yay...
[19:57:24 CET] <omerjerk> Hey, I'm trying to merge some old code into current FFmpeg head. 
[19:57:35 CET] <omerjerk> any idea what's the alternative of FF_INPUT_BUFFER_PADDING_SIZE?
[19:58:19 CET] <J_Darnley> AV_INPUT... maybe?
[19:58:27 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/7546964f96168cd6ac819ef4c3212ee586619f1a/doc/APIchanges#L553
[19:58:36 CET] <omerjerk> okay
[21:14:26 CET] <J_Darnley> Fucking gentoo users ^
[21:30:51 CET] <philipl> -funroll-loops
[21:31:08 CET] <thardin> fun-roll
[21:32:43 CET] <J_Darnley> I'm amazed that he's running this code on the first generation of Athlon 64
[21:33:14 CET] <J_Darnley> Why else would you disable code you're never going to use (--disable-sse3)
[21:33:41 CET] <J_Darnley> But those still had 3dnow
[21:33:58 CET] <J_Darnley> Is it a first generation intel chip then
[21:34:41 CET] <nevcairiel> gentoos configure invocation is all sorts of brainded re: asm stuff, so i wouldnt be surprised its just unrelated to hardware
[21:35:28 CET] <J_Darnley> But gentoo is for ricers and Xtreme speed.  They wouldn't cripple themselves(!)
[21:36:20 CET] <nevcairiel> you would think it wouldnt disable all asm by default then =p
[21:41:25 CET] <Compn> did docs.google.com go down? lol
[21:43:06 CET] <atomnuker> i think so
[21:44:16 CET] <Compn> hahaha
[21:44:29 CET] <Compn> never trust the cloud
[21:45:43 CET] <JEEB> cloud^Wsomeone else's data center
[21:45:58 CET] <JEEB> on the other hand some of OVH's DCs went down a week+ ago
[21:46:04 CET] <JEEB> &32
[23:19:53 CET] <tmm1> i guess doing autocrop with vf=cropdetect,ctop is not possible in ffmpeg. the filter chain configures the resolution up-front before any frames are fed in
[23:22:45 CET] <atomnuker> what are you trying to do?
[23:29:01 CET] <DHE> plus the decisions of cropdetect may change over the execution of the video
[23:33:29 CET] <jamrial> BtbN: going to push your flatten_libs fix?
[23:33:57 CET] <BtbN> jamrial, I can. Not sure if people might want to test/look at it more.
[23:34:13 CET] <jamrial> ok
[23:34:38 CET] <jamrial> give it a bit more time, and if nobody comments then push it
[23:45:36 CET] <jamrial> wbs: ping
[23:47:53 CET] <tmm1> atomnuker: cropdetect puts the x/y/w/h in per-frame metadata, i was trying to use that in a downstream filter to crop. but it doesn't work because filterpad width/height cannot be dynamic
[23:49:31 CET] <BtbN> yeah, a filter with non-fixed parameters like that might be problematic
[23:51:34 CET] <tmm1> i thought maybe i could buffer frames in the vf, but that doesnt' work either because width/height have to be set when the filtergraph is configured
[23:53:27 CET] <atomnuker> tmm1: avframes have crop fields, don't they?
[23:54:03 CET] <BtbN> those implicitly change their size
[23:54:17 CET] <BtbN> and most (all?) stuff that comes after filters will just ignore it
[23:55:10 CET] <atomnuker> yep, so you can keep the width and height constant and use those fields
[23:55:24 CET] <BtbN> I don't see how that would help at all
[23:55:34 CET] <atomnuker> because the filters wouldn't get reconfigured
[23:55:38 CET] <BtbN> The cropping info already is in the frame
[23:55:59 CET] <BtbN> They wouldn't get reconfigured, but they also wouldn't care about the cropping you tried to do
[23:56:22 CET] <atomnuker> and that's okay
[23:56:31 CET] <tmm1> yea that might work.. where are the crop fields used?
[23:56:33 CET] <BtbN> That makes the entire thing pointless
[23:56:41 CET] <BtbN> Pretty much only after decoding
[23:56:50 CET] <BtbN> Because codecs like to add extra padding
[23:56:55 CET] <BtbN> that is cropped away with those fields
[23:57:07 CET] <atomnuker> you sure?
[23:57:19 CET] <atomnuker> most decoders adjust the data pointers
[23:57:29 CET] <atomnuker> rather all decoders I know of
[23:57:37 CET] <BtbN> A lot of decoders return 1080p with a height of 1088 and crop_bottom of 8
[23:57:43 CET] <BtbN> all hwaccels do
[23:58:16 CET] <atomnuker> why don't they set the height? this seems like stupid design
[23:58:31 CET] <BtbN> By convention
[23:58:56 CET] <atomnuker> right, so its a retarded design
[23:59:12 CET] <BtbN> I don't see the issue with putting in the frame what is actually in there?
[23:59:25 CET] <BtbN> That's what those fields are there for after all
[23:59:45 CET] <BtbN> And after decoding is done something calls apply_cropping anyway, and they are gone and the actual height is in the height field
[23:59:53 CET] <atomnuker> wait, its not by convention!
[00:00:00 CET] --- Thu Nov 16 2017