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

[burek]

[00:30:52 CET] <alevinsn> who is responsible for FFmpeg's patchwork site?
[00:31:24 CET] <alevinsn> it appears to have stopped working properly on Monday
[00:42:29 CET] <michaelni> if ER doesnt work with slice threads, that should be added to the list, also using multiple threads for ER is a good idea
[00:42:47 CET] <michaelni> but ER should work with slice threads
[01:08:22 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:004ea63714e3: cuvid: add cuvid.h to SKIPHEADERS
[01:08:23 CET] <cone-305> ffmpeg 03Peter Große 07master:a58873b11198: avconv: when using -loop option bail out if seek to start fails
[01:08:24 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:00fd914d4912: hevcdec: set the active SPS before calling get_format()
[01:08:25 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:770cf1dbc2c8: fate/hevc: specify output pixel format explicitly
[01:08:26 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:b90fdb2c7199: hevcdec: add a CUVID hwaccel
[01:08:27 CET] <cone-305> ffmpeg 03James Almer 07master:fd352fadbbdf: Merge commit '004ea63714e31ed43326ad00d7420d104f0dab38'
[01:08:28 CET] <cone-305> ffmpeg 03James Almer 07master:09100ccc1469: Merge commit 'a58873b11198d04670b7f98f5a8a749d742db7c5'
[01:08:29 CET] <cone-305> ffmpeg 03James Almer 07master:7762942045a0: Merge commit '00fd914d4912322212e924c15f325cebf2fde8d3'
[01:08:30 CET] <cone-305> ffmpeg 03James Almer 07master:ec54df7dcd59: Merge commit '770cf1dbc2c8fe9b84300439ad0cd85036480388'
[01:08:31 CET] <cone-305> ffmpeg 03James Almer 07master:1178babacaaa: Merge commit 'b90fdb2c7199cc8b0e8d994fafba1fb4dc181d88'
[01:08:32 CET] <cone-305> ffmpeg 03James Almer 07master:276045494562: avcodec/nvdec: fix copyright headers
[01:10:40 CET] <jamrial> BtbN: ^
[01:12:04 CET] <jamrial> BtbN: now we need to see what to do with wm4's commits that are neither in libav or sent to the ml
[02:47:57 CET] <jamrial> BtbN: it would for that matter be nice if you could comment on the videotoolbox patchset by aman gupta
[02:48:04 CET] <jamrial> it's apparently going in a different direction than the stuff we're merging from libav
[02:48:56 CET] <iive> is video tool box an apple api?
[02:52:50 CET] <jamrial> yeah
[02:54:44 CET] <jamrial> the set is making changes to AVHWAccel that might not be compatible with wm4 and elenril's work
[04:29:44 CET] <cone-305> ffmpeg 03Sean McGovern 07master:d7bdab1ad78e: mov: log and return early on non-positive stsd entry counts
[04:29:45 CET] <cone-305> ffmpeg 03Sean McGovern 07master:3050dabaa9a3: mov: Do not set stsd_count if mov_read_stsd() fails
[04:29:46 CET] <cone-305> ffmpeg 03Sean McGovern 07master:defe307fb22b: mov: move stsd finalization to an appropriate place
[04:29:47 CET] <cone-305> ffmpeg 03James Almer 07master:73198aca2c27: Merge commit 'defe307fb22beca60a632e976ab97e5edd4aee25'
[04:41:58 CET] <cone-305> ffmpeg 03Mark Thompson 07master:aaf441465080: h264: Add stream constraint values to the common header
[04:41:59 CET] <cone-305> ffmpeg 03Mark Thompson 07master:b88da98b3480: hevc: Improve stream constraint values in common header
[04:42:00 CET] <cone-305> ffmpeg 03Mark Thompson 07master:1329c08ad6d2: hevc: Validate the number of long term reference pictures
[04:42:01 CET] <cone-305> ffmpeg 03James Almer 07master:95a52ca884ce: Merge commit 'b88da98b34809dedf8882d43ed543632ed233538'
[04:42:02 CET] <cone-305> ffmpeg 03James Almer 07master:36e0093dd91f: Merge commit '1329c08ad6d2ddb304858f2972c67b508e8b0f0e'
[04:52:11 CET] <cone-305> ffmpeg 03Mark Thompson 07master:19388a7200e5: vaapi_encode: Move quality option to common code
[04:52:12 CET] <cone-305> ffmpeg 03Vittorio Giovara 07master:ebf3b9e8a875: h264: Add support for alternative transfer characterics SEI
[04:52:13 CET] <cone-305> ffmpeg 03Vittorio Giovara 07master:538e50875105: pixfmt: Support chroma-derived and ictcp color matrices
[04:52:14 CET] <cone-305> ffmpeg 03Mark Thompson 07master:18f1706f331b: lavc: Add coded bitstream read/write API
[04:52:15 CET] <cone-305> ffmpeg 03Mark Thompson 07master:acf06f45441b: lavc: Add coded bitstream read/write support for H.264
[04:52:16 CET] <cone-305> ffmpeg 03Mark Thompson 07master:867381b8b51f: lavc: Add coded bitstream read/write support for H.265
[04:52:17 CET] <cone-305> ffmpeg 03Mark Thompson 07master:f11d8a5e8b18: lavc: Add trace_headers bitstream filter
[04:52:18 CET] <cone-305> ffmpeg 03Mark Thompson 07master:9e93001b6135: lavc: Add h264_metadata bitstream filter
[04:52:19 CET] <cone-305> ffmpeg 03Mark Thompson 07master:e6874bc3af2f: lavc: Add h264_redundant_pps bitstream filter
[04:52:20 CET] <cone-305> ffmpeg 03Mark Thompson 07master:b31a9eae0233: lavc: Add hevc_metadata bitstream filter
[04:52:21 CET] <cone-305> ffmpeg 03Mark Thompson 07master:7a4fac5e9178: vaapi_h264: Convert to use coded bitstream infrastructure
[04:52:22 CET] <cone-305> ffmpeg 03Mark Thompson 07master:820a4483af13: vaapi_h264: Add support for AUD NAL units
[04:52:23 CET] <cone-305> ffmpeg 03Mark Thompson 07master:a49ee60d5fdb: vaapi_h264: Add support for SEI recovery points
[04:52:24 CET] <cone-305> ffmpeg 03Mark Thompson 07master:ac12486714b4: vaapi_h265: Convert to use coded bitstream infrastructure
[04:52:25 CET] <cone-305> ffmpeg 03Mark Thompson 07master:e3e8eab35923: vaapi_h265: Add support for AUD NAL units
[04:52:26 CET] <cone-305> ffmpeg 03Mark Thompson 07master:a14a12ca137b: vaapi_h265: Reduce the amount of padding in the stream
[04:52:27 CET] <cone-305> ffmpeg 03James Almer 07master:924978341516: Merge commit 'e3e8eab359238486dc233f7aa89b7bb3cb19ec38'
[04:52:28 CET] <cone-305> ffmpeg 03James Almer 07master:e6d70494ce03: Merge commit 'a14a12ca137bf1526452b97bedfc9f7b301d4e04'
[04:56:20 CET] <cone-305> ffmpeg 03Diego Biurrun 07master:d34a133b78af: dfa: Disallow odd width/height and add proper bounds check for DDS1 chunks
[04:56:21 CET] <cone-305> ffmpeg 03James Almer 07master:ecf4e6b7205f: Merge commit 'd34a133b78afe2793cd8537f3c7f42437f441e94'
[05:07:36 CET] <cone-305> ffmpeg 03Piotr Bandurski 07master:a05c6e8c11b1: xwddec: support 8bpp grayscale
[05:07:37 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:f70f71d60c7a: h264dec: use a large enough field for reference list modification values
[05:07:38 CET] <cone-305> ffmpeg 03Mark Thompson 07master:768eb9182e94: cbs_h2645: Return error if writing fails
[05:07:39 CET] <cone-305> ffmpeg 03Mark Thompson 07master:2bc9ba8d3c41: lavc: Add coded bitstream read/write support for MPEG-2
[05:07:40 CET] <cone-305> ffmpeg 03Mark Thompson 07master:b78c30d7ec26: lavc: Add mpeg2_metadata bitstream filter
[05:07:41 CET] <cone-305> ffmpeg 03James Almer 07master:53fc4310f1ba: Merge commit 'b78c30d7ec26af67c00ce2002709a189f6a87a7e'
[05:26:50 CET] <cone-305> ffmpeg 03Mark Thompson 07master:4c0588b4562a: mpeg2enc: Don't mark all streams as component video
[05:26:51 CET] <cone-305> ffmpeg 03James Almer 07master:700da852b58b: Merge commit '4c0588b4562abad5540f6a5435c62828de9e4fdf'
[05:42:55 CET] <cone-305> ffmpeg 03James Almer 07master:006546c635f0: avcodec/mpegaudiodecheader: remove dead code
[05:42:56 CET] <cone-305> ffmpeg 03James Almer 07master:1b6e52c68fd0: avcodec/dnxhddata: remove dead code
[12:08:02 CET] <BtbN> michaelni, what commandline triggers that assertion?
[12:08:15 CET] <BtbN> Just trying to decode that file is enough?
[12:09:33 CET] <michaelni> was just decoding to -f null - 
[12:16:09 CET] <nevcairiel> it probably doesnt release the private_ref on decode errors
[12:16:19 CET] <BtbN> yeah, actually compiling with assert level 1 helps...
[12:16:21 CET] <nevcairiel> so it remains in the AVFrame, which gets reused
[12:16:46 CET] <nevcairiel> its not a real error, just unclean to leak it
[12:17:22 CET] <BtbN> Well, I guess fixing it should not be too hard
[12:17:33 CET] <BtbN> Just adding a free in the right error case
[12:29:39 CET] <BtbN> weird, even if I just unconditionally free the private_ref in decode_receive_frame_internal, it still fails
[12:39:24 CET] <BtbN> https://bpaste.net/show/e3eb825a4e28 this makes no sense. It indicates that it's being freed correctly. Yet it still runs into that exception
[12:39:55 CET] <BtbN> hm, it's suddenly a different frame
[12:40:36 CET] <BtbN> 0x207dd20 changes to 0x207cf80
[12:41:05 CET] <nevcairiel> the frame get_buffer runs on and the frame that the API call gets are never the same actual frame instance
[12:42:29 CET] <nevcairiel> or to be more precise, they could be in simple decoders, but they dont have to be
[12:42:52 CET] <BtbN> it is always the same frame
[12:42:57 CET] <BtbN> up until the point when the assertion fails
[12:46:58 CET] <nevcairiel> presumably at the point it errors about the bitstream
[12:47:25 CET] <BtbN> It's weird, looking at decode_audio in ffmpeg.c, that would be the point where I don't expect it to change
[12:48:00 CET] <nevcairiel> reading the code, it looks like it will keep reusing the same frame after a decode error, which would still contain the allocated pointer then
[12:48:17 CET] <nevcairiel> looks specific to wmavoice
[12:48:35 CET] <nevcairiel> a single packet can contain multiple superframes, and when one of them fails to parse, it'll just try the next
[12:49:14 CET] <nevcairiel> although it errors out pretty early so i dont think it should call the stuff wrong
[12:49:15 CET] <nevcairiel> odd
[12:53:36 CET] <BtbN> It calls synth_superframe twice. Once in line 1927, then in 1950.
[12:53:47 CET] <BtbN> In the case where it explodes, it calls both
[12:53:55 CET] <BtbN> and both call ff_get_buffer on the same frame
[12:54:13 CET] <nevcairiel> the only time it would do that is if the first call fails
[12:54:28 CET] <BtbN> Or does not return a frame
[12:54:50 CET] <nevcairiel> thats basically failure
[12:55:50 CET] <BtbN> so, do we considder it a bug that it calls ff_get_buffer twice on the same frame, or should that work?
[12:56:21 CET] <nevcairiel> there is probably no reason that shouldnt work, even if its a bit unusual
[12:57:08 CET] <BtbN> So that would mean just dropping the assert
[13:01:43 CET] <BtbN> hm, I wonder, is ff_get_buffer prepared to be called twice? Or does that leak stuff?
[13:02:55 CET] <BtbN> line 1635 in decode.c, get_buffer_internal, certainly suggests that for video, calling it twice is an error
[13:03:37 CET] <nevcairiel> its audio tho
[13:04:21 CET] <BtbN> But should that really be different between audio and video?
[13:19:02 CET] <BtbN> michaelni, see my latest two patches to the ml. The first one is not required to fix the assertion, but it seems cleaner to me to always free the private ref. Can't think of a reason why it would be needed intact on a failure
[13:59:15 CET] <cone-192> ffmpeg 03Luca Barbato 07master:9f5b77c16f4d: png: Report more details regarding unsupported pixel formats
[13:59:16 CET] <cone-192> ffmpeg 03James Almer 07master:bdbf14abba9d: Merge commit '9f5b77c16f4da6248b57f0601364d9c762c620c2'
[14:03:44 CET] <cone-192> ffmpeg 03Luca Barbato 07master:0c99b900d874: png: Support RGBA64 pixel format
[14:03:45 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:7b7760ad6efb: aarch64: Fix negative movrel offsets for windows
[14:03:46 CET] <cone-192> ffmpeg 03James Almer 07master:87681ba97b70: Merge commit '0c99b900d874b60ce89b94742b2215f163c87a2b'
[14:03:47 CET] <cone-192> ffmpeg 03James Almer 07master:28bb96c408e3: Merge commit '7b7760ad6efb7b96122aa7133ad21e22653ae222'
[14:11:24 CET] <cone-192> ffmpeg 03Michael Niedermayer 07master:feed239021ba: yadif: Account for the buffer alignment while processing the frame edges
[14:11:25 CET] <cone-192> ffmpeg 03James Almer 07master:672e704e4a40: Merge commit 'feed239021bad89743d5e7989b426ae594322eb7'
[14:14:53 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:29ba1e60761f: configure: Include d3d11va_extralibs in libavutil
[14:14:54 CET] <cone-192> ffmpeg 03Derek Buitenhuis 07master:5e3f6dc70198: swscale: Do not expand a macro with 'defined' in it
[14:14:55 CET] <cone-192> ffmpeg 03wm4 07master:173b56218f39: lavf: make avio_read_partial() public
[14:14:56 CET] <cone-192> ffmpeg 03James Almer 07master:9194d3d3806f: Merge commit '173b56218f39c6463be0e182259e2deead106936'
[14:16:21 CET] <cone-192> ffmpeg 03John Stebbins 07master:c84bc81158da: avformat/utils: preserve AV_PKT_FLAG_DISCARD in parse_packet
[14:16:22 CET] <cone-192> ffmpeg 03Michael Niedermayer 07master:b197d83ca3f7: avformat/utils: Look at the first 3 frames if timestamps indicate frame reorder but decoder delay does not
[14:16:23 CET] <cone-192> ffmpeg 03Aleksandr Slobodeniuk 07master:85af60df89ed: avcodec: fix wrong duration of packets (dvd, bluray)
[14:16:24 CET] <cone-192> ffmpeg 03Sasi Inguva 07master:bc509617310d: lavf/mov.c: Parse upto 2 keyframes after the edit list end in mov_fix_index.
[14:16:37 CET] <michaelni> BtbN, patch(es) should be ok 
[14:17:13 CET] <BtbN> michaelni, what do you think about calling ff_get_buffer on the same frame twice? Maybe that should be documented as not supported.
[14:17:52 CET] <michaelni> yes, calling it twice feels unexpected to me
[14:19:42 CET] <BtbN> jamrial, can I safely push stuff right now, without interrupting merges?
[14:20:16 CET] <jamrial> BtbN: sure
[14:20:32 CET] <jamrial> i need to rebase the one i was doing since the four commits above went in first anyway :p
[14:20:42 CET] <cone-192> ffmpeg 03Timo Rothenpieler 07master:6a4d1c906317: ffmpeg: use explicitly requested hwaccel only
[14:20:43 CET] <cone-192> ffmpeg 03Timo Rothenpieler 07master:8dd73f68a631: avcodec/decode: always free private_ref
[14:20:44 CET] <cone-192> ffmpeg 03Timo Rothenpieler 07master:7e76e1ea8005: wmavoice: free frame before ff_get_buffer
[14:29:44 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:e41daa624650: Remove support for building for mingw32ce (Windows CE)
[14:29:45 CET] <cone-192> ffmpeg 03James Almer 07master:f87ad3a058bf: Merge commit 'e41daa62465036ad36ad0bd14e4936e848d7f07e'
[14:41:01 CET] <jamrial> wbs: ping
[14:41:41 CET] <wbs> jamrial: pong
[14:45:05 CET] <jamrial> wbs: https://github.com/jamrial/FFmpeg/commit/8441b9845aad5549068d0a8e995f22d6ad8da9cf does this look good?
[14:45:37 CET] <jamrial> i had to add av_export_avutil for two libavutil avpriv functions
[14:45:51 CET] <kierank> michaelni: https://github.com/FFmpeg/FFmpeg/blob/d49ca877d0e4cd953a28be41f3df8724f0179918/libavcodec/h264dec.c#L438
[14:45:52 CET] <jamrial> err, not functions
[14:45:55 CET] <kierank> yes, not supported
[14:46:19 CET] <wbs> jamrial: yeah, looks straightforward enough; as long as a --enable-shared build still links with either msvc or mingw, it should be fine iirc
[14:46:53 CET] <jamrial> ok, thanks
[14:47:26 CET] <wbs> (current self also notices that the dllexport actually is superfluous since we need to manually mangle the def files anyway)
[14:47:44 CET] <wbs> and without the dllexport, we could avoid using makedef, but that wouldn't work with lld for llvm-mingw that I'm working on
[14:48:21 CET] <wbs> (so I might send a patch that gets rid of dllexport, that's just a few lines, but I won't remove makedef until I/someone else has implemented support for the version script thingie for exporting symbols with a pattern, in lld)
[14:50:29 CET] <BtbN> Time to clean up that nvdec decoder a bit I guess
[15:29:40 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:abf1c058d1bd: msvc: Properly specify dllexport for data symbols shared across dll boundaries
[15:29:41 CET] <cone-192> ffmpeg 03James Almer 07master:87865bf6c700: Merge commit 'abf1c058d1bd0ed1b820ea5e501a4484756f00b0'
[15:31:09 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:44aa9105c535: makedef: Fold as much text transformations as possible into the initial dump
[15:31:10 CET] <cone-192> ffmpeg 03James Almer 07master:24f1685f6eb2: Merge commit '44aa9105c535471ca9e23796d7ca29b341f47636'
[15:32:05 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:1a7bf48eed80: makedef: Extend the script for use with mingw tools as well
[15:32:05 CET] <nevcairiel> do i need some special commandline for zero-copy encoding? it seems to always want to do copyback
[15:32:06 CET] <cone-192> ffmpeg 03James Almer 07master:c14f8125a893: Merge commit '1a7bf48eed806beea7e835b31b06aa6bc94da5da'
[15:33:23 CET] <nevcairiel> apparently -hwaccel_output_format
[15:33:43 CET] <BtbN> Yeah, that
[15:34:13 CET] <nevcairiel> Failed creating D3D11 CUDA context for NVENC: 0x3, boo
[15:35:06 CET] <nevcairiel> oh i need to call cuInit
[15:35:38 CET] <BtbN> You shouldn't really need a CUDA context at all?
[15:35:44 CET] <BtbN> but cuInit might be needed
[15:35:45 CET] <nevcairiel> of course you d o
[15:35:55 CET] <BtbN> Don't you just give the D3D context to nvenc?
[15:36:06 CET] <nevcairiel> doesnt it always need a cuda context
[15:36:20 CET] <nevcairiel> i f igure i would just make one with cuD3D11CtxCreate
[15:36:37 CET] <BtbN> it needs either a CUDA context, a D3D context(Win only) or an OpenGL context iirc
[15:38:07 CET] <BtbN> In nvenc_open_session you can set the deviceType to NV_ENC_DEVICE_TYPE_DIRECTX and pass the DirectX context instead of the cuda one
[15:42:33 CET] <nevcairiel> hm thats probably easier then
[15:42:59 CET] <BtbN> it will be a bit annoying because there is a lot of cuda context pushing/poping all around the code
[15:43:31 CET] <BtbN> But I'm pretty sure if you want it to accept DirectX input surfaces, you cannot create it any other way than with NV_ENC_DEVICE_TYPE_DIRECTX
[15:46:16 CET] <nevcairiel> perhaps, but i wonder if it maybe still wants a cuda context
[15:46:27 CET] <BtbN> I don't think so, no
[15:46:50 CET] <BtbN> It originally was DirectX-Only, and only later was enhanced to run on CUDA
[15:47:45 CET] <BtbN> No idea how DirectX handles that, but I'd expect that you have to do something similar to pushing/poping the CUDA contexts. At least for OpenGL You'd have to make sure your context is bound while invoking nvenc on it
[15:48:53 CET] <nevcairiel> d3d11 is mt-safe, mostly
[15:49:04 CET] <nevcairiel> it does that internally
[15:55:30 CET] <nevcairiel> i should probably wrap all the push/pop calls into a function and add a check to skip them in d3d mode, otherwise its going to get ugly
[15:57:13 CET] <BtbN> yeah, something like that
[15:57:24 CET] <BtbN> I kind of planned to do exactly that, but forgot
[16:00:19 CET] <RT|Chatzilla> @devs it is possible to enable opus decoder without libavresample?
[16:01:18 CET] <BtbN> Does someone have a ridiculously large resolution h264 file?
[16:01:49 CET] <BtbN> width or height bigger than 4096
[16:02:04 CET] <BtbN> can just be a single frame
[16:02:05 CET] <nevcairiel> RT|Chatzilla: it uses swresample in ffmpeg, but no, it requires resampling to function
[16:02:07 CET] <JEEB> is this big enough "mp4        7680x4320  DASH video 78632k , avc1.640033, 30fps,"
[16:02:12 CET] <BtbN> Yeah, easily
[16:02:42 CET] <jamrial> youtube serves 8k h264?
[16:02:48 CET] <JEEB> yes
[16:02:49 CET] <JEEB> https://www.youtube.com/watch?v=Jld-YVcu3cY
[16:02:53 CET] <BtbN> Can probably also just create one
[16:02:54 CET] <JEEB> format 138
[16:03:10 CET] <JEEB> youtube-dl -f 138 "https://www.youtube.com/watch?v=Jld-YVcu3cY"
[16:03:11 CET] <jamrial> i'd have expected they would only serve vp9 at that resolution
[16:03:13 CET] <JEEB> I think
[16:03:49 CET] <jamrial> nvidia gpus can probably handle 8k vp9 (or maybe just hevc), but afaik not h264
[16:04:37 CET] <BtbN> yes, they are stupidly limited at h264
[16:04:46 CET] <BtbN> 8 bit: supported: 1, min_width: 48, max_width: 4096, min_height: 16, max_height: 4096
[16:04:49 CET] <BtbN> no 10/12 bit
[16:05:43 CET] <BtbN> For HEVC: 12 bit: supported: 1, min_width: 144, max_width: 8192, min_height: 144, max_height: 8192
[16:05:49 CET] <BtbN> 8/10/12 bit support is there
[16:06:18 CET] <jamrial> and vp9?
[16:06:34 CET] <BtbN> Need to grab a sample first, but I'd expect similar values to HEVC
[16:07:17 CET] <jamrial> the youtube link above has an 8k vp9 stream. format 272
[16:07:20 CET] <JEEB> yea
[16:07:26 CET] <JEEB> :D
[16:07:36 CET] <jamrial> 60fps
[16:07:55 CET] <JEEB> it's a mobile game engine running hacked with some nicer resolution and frame rate
[16:07:59 CET] <BtbN> yeah, vp9 caps are identical to HEVC
[16:08:34 CET] <jamrial> cool
[16:12:26 CET] <BtbN> libav people forgot that nvdec supports 12 bit
[16:12:33 CET] <BtbN> was pretty much a one line change to add support
[16:13:48 CET] <BtbN> nice, the capability check in nvdec also works just fine, and causes it to auto-fallback to swdec
[16:13:59 CET] <JEEB> cool
[16:14:08 CET] <BtbN> (libav also didn't add that)
[16:14:36 CET] <nevcairiel> wouldnt decoder creation just fail on  unsupported stuff
[16:14:44 CET] <BtbN> you'd hope so
[16:14:44 CET] <nevcairiel> i never understood the need for the check function
[16:15:08 CET] <BtbN> But first, I don't trust nvidia there
[16:15:33 CET] <BtbN> And second, having a visible reason(your stuff is too high/wide) is just plain nicer
[16:15:45 CET] <BtbN> instead of "unknown error"
[16:26:46 CET] <nevcairiel> BtbN: so far so good, encoder instance is being created and everything, now just to handle the surfaces
[16:47:36 CET] <nevcairiel> BtbN: it seems to work, wee
[16:48:23 CET] <nevcairiel> almost twice the fps then doing software decode + nvenc
[16:48:48 CET] <nevcairiel> and over 4x the fps of doing d3d11 -> download -> nvenc
[16:48:56 CET] <JEEB> nice
[16:49:16 CET] <nevcairiel> (although i have another 3d app running right now, which might influence that last one)
[16:53:40 CET] <nevcairiel> https://github.com/Nevcairiel/FFmpeg/commits/nvenc_d3d11 some ugly parts in it still, need to clean up a bit
[17:18:14 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:accb06120c13: configure: Use dllexport/dllimport for data symbols across DLLs with mingw
[17:18:15 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:39e16ee2289e: Revert "fate: Skip the checkasm test if CONFIG_STATIC is disabled"
[17:18:16 CET] <cone-192> ffmpeg 03James Almer 07master:98a9b1f0de0b: Merge commit 'accb06120c13a4ead442464d96f2fa318fa07a4e'
[17:18:17 CET] <cone-192> ffmpeg 03James Almer 07master:37d5c6c30d38: Merge commit '39e16ee2289e4240a82597b97db5541bbbd2b996'
[17:20:21 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:547db1eaecd5: checkasm: Test more h264 idct variants
[17:20:22 CET] <cone-192> ffmpeg 03James Almer 07master:2d263188ba87: Merge commit '547db1eaecd597031165a2bf637acaaacde52788'
[17:20:28 CET] <nevcairiel> jamrial: did you intentionally remove support for using lib.exe in that merge? historically it has always produced better lib files
[17:20:50 CET] <philipl> BtbN: So with nvdec now in play, hwaccel_output_format is unavoidable. So, to dig up the old thread about how to handle it when moving cuviddec to a generic hwaccel - what are your thoughts now? Don't bother ever converting it? Just accept that you need hwaccel_output_format? We never reached an agreement on how to do autodetection
[17:21:15 CET] <jamrial> nevcairiel: yes. an upcoming merge will remove the usage of dlltool anyway
[17:22:01 CET] <jamrial> not sure how far away in the queue, though. i can search for it and cherry pick it now if you prefer
[17:25:36 CET] <nevcairiel> would have to test later if all stuff still works
[17:27:10 CET] <BtbN> philipl, it's not an API break for a new decoder though
[17:27:22 CET] <BtbN> and cuvid, once nvdec has feature parity, will go through normal deprecation
[17:27:53 CET] <BtbN> If some kind of auto-detection can be done, it will be generic
[17:31:17 CET] <philipl> BtbN: Sounds like you're ok with just leaving it non-generic until it gets removed.
[17:32:50 CET] <BtbN> yeah
[17:56:56 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:9dde6ab06c48: arm: Fix SIGBUS on ARM when compiled with binutils 2.29
[17:56:57 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:e12f1cd61657: Revert "checkasm: Test more h264 idct variants"
[17:56:58 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:585dc1aecef0: flvdec: Check the avio_seek return value after reading a metadata packet
[17:56:59 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:f19fbfbdc637: aviocat: Check for output write errors
[17:57:00 CET] <cone-192> ffmpeg 03James Almer 07master:640073ecebc4: Merge commit '9dde6ab06c48f9447cd16f39bee33569cddb7be4'
[17:57:01 CET] <cone-192> ffmpeg 03James Almer 07master:e49bfbe0864f: Merge commit 'e12f1cd616573795681ce939113ac6cdad4c1f2b'
[17:57:02 CET] <cone-192> ffmpeg 03James Almer 07master:4c01fa0bc5ac: Merge commit '585dc1aecef0371ad6f16cb3750ae2a6da9cf00a'
[17:57:03 CET] <cone-192> ffmpeg 03James Almer 07master:460e7596cb5b: Merge commit 'f19fbfbdc637e08ad5c980807ede2d023f20c049'
[17:58:16 CET] <BtbN> nevcairiel, I'd be careful with using a void* for a CUdeviceptr
[17:58:28 CET] <BtbN> it's just a typedef for an integer
[17:59:13 CET] <cone-192> ffmpeg 03Luca Barbato 07master:b05128f3c953: qsv: Load the hw hevc plugin by default on Linux
[17:59:14 CET] <cone-192> ffmpeg 03James Almer 07master:d59efe4ca63d: Merge commit 'b05128f3c953bd66483e697d60a2e7e45ee9cfa0'
[17:59:46 CET] <BtbN> Otherwise the only real issue I have is that I'm not a fan of indenting pre-processor directives. Don't know, just looks weird to me. Would prefer them all without spaces in front.
[18:03:52 CET] <BtbN> size wise the CUdevptr should fit though. It's 32bit on 32bit platforms.
[18:08:02 CET] <cone-192> ffmpeg 03Mark Thompson 07master:44cde38c8acb: cbs: Always check for bitstream end before reading
[18:08:03 CET] <cone-192> ffmpeg 03Mark Thompson 07master:e7f64191b27b: cbs: Add buffer padding when splitting fragments
[18:08:04 CET] <cone-192> ffmpeg 03Mark Thompson 07master:c42b62d1f964: h264_metadata: Fix double-free
[18:08:05 CET] <cone-192> ffmpeg 03Mark Thompson 07master:f940c859c23a: Revert "vaapi_h265: Reduce the amount of padding in the stream"
[18:08:06 CET] <cone-192> ffmpeg 03James Almer 07master:e493ede4ae9a: Merge commit 'c42b62d1f9641f10ffc23cad9abbe47d8a4a165b'
[18:08:07 CET] <cone-192> ffmpeg 03James Almer 07master:f1fdd17d3959: Merge commit 'f940c859c23ae201b0170cf541ea8f6b7a52dd49'
[18:11:16 CET] <cone-192> ffmpeg 03Mark Thompson 07master:30645174e333: vaapi_h264: Fix CPB/DPB delays
[18:11:17 CET] <cone-192> ffmpeg 03Mark Thompson 07master:f76348936441: cbs_h265: Fix reading of unknown parameter set extension data
[18:11:18 CET] <cone-192> ffmpeg 03Mark Thompson 07master:067a9ddeb8fe: cbs_h265: Fix ranges of prediction weight offsets
[18:11:19 CET] <cone-192> ffmpeg 03Mark Thompson 07master:a41b69b5eb95: cbs_mpeg2: Add support for picture display extension
[18:11:20 CET] <cone-192> ffmpeg 03Mark Thompson 07master:b5859e0b04bd: mpeg12: Move finding the best frame rate to common code
[18:11:21 CET] <cone-192> ffmpeg 03Mark Thompson 07master:10eb496d9ae9: vaapi_mpeg2: Convert to use coded bitstream infrastructure
[18:11:22 CET] <cone-192> ffmpeg 03James Almer 07master:3af2bf0af049: Merge commit '10eb496d9ae94df6f792b0e1d8750738eb3a0952'
[18:11:25 CET] <jamrial> sooo close now
[18:12:26 CET] <durandal_1707> so close to what?
[18:12:57 CET] <BBB> to being uptodate w.r.t. libav, I think
[18:13:00 CET] <BBB> nice work jamrial
[18:13:11 CET] <BBB> I admire your dedication
[18:17:05 CET] <JEEB> from #elsewhere as well < CounterPillow> jamrial is the true hero
[18:17:14 CET] <jamrial> lol
[18:18:55 CET] <nevcairiel> BtbN: ultimately we only store the bit pattern of those things anyway, for comparison, could make it a intptr_t if that seems better
[18:19:56 CET] <BtbN> It shouldn't really matter, as it's a pointer in data[] anyway
[18:20:09 CET] <BtbN> avoids a few casts that way
[18:27:35 CET] <jamrial> nevcairiel: can you test if some qsv patches compile?
[18:34:30 CET] <nevcairiel> i guess
[18:36:45 CET] <jamrial> nevcairiel: https://github.com/jamrial/FFmpeg/commits/mergework
[18:41:44 CET] <nevcairiel> its only a matter of hours to run configure, and hope the mfx stuff is still installed =p
[18:41:58 CET] <jamrial> heh
[18:41:58 CET] <nevcairiel> note i cant actually run it, no intel gpu :)
[18:42:06 CET] <BtbN> Do I see this right that VP9 has just plain 8 reference frames at all times? And no variable count like h264/5?
[18:42:41 CET] <nevcairiel> there can be up to 8, but not all are always used
[18:42:47 CET] <nevcairiel> so not sure what you mean with "at all times"
[18:43:09 CET] <nevcairiel> every frame itself can only reference 3 others
[18:43:17 CET] <nevcairiel> out of that pool of 8
[18:46:19 CET] <BtbN> nvdec needs the size of the pool of reference frames to hold on hwaccel init
[18:46:22 CET] <BtbN> so that would be 8 then
[18:46:30 CET] <BtbN> And not something from the SPS or so like with h264
[18:46:50 CET] <nevcairiel> wtf is wrong wit hthe configure libmfx entry
[18:46:54 CET] <nevcairiel> -llibmfx
[18:46:55 CET] <nevcairiel> really
[18:47:01 CET] <nevcairiel> as if shit is named liblibmfx.a
[18:47:12 CET] <JEEB> wat
[18:47:30 CET] <rcombs> my crazy build involves a liblibx264_encoder.so
[18:47:37 CET] <rcombs> I'm so sorry
[18:48:07 CET] <ubitux> nevcairiel: 164e2773261451ef33c4616296ec5bebecff42af
[18:48:14 CET] <ubitux> see the note
[18:48:28 CET] <ubitux> > Note that the reason that require() is passed -llibmfx as the last argument, instead of -lmfx, is the file name for the library produced from the Intel Media SDK starts with "libmfx".
[18:48:56 CET] <nevcairiel> every library starts with libmfx
[18:48:59 CET] <nevcairiel> eh lib
[18:49:00 CET] <nevcairiel> like libz
[18:49:05 CET] <nevcairiel> yet we dont write -llibz
[18:49:11 CET] <rcombs> maybe it's on windows
[18:49:14 CET] <rcombs> where libs usually don't
[18:49:18 CET] <ubitux> yes, i don't know :)
[18:49:20 CET] <BtbN> On Windows, libmfx.lib would indeed be -llibmfx
[18:49:32 CET] <nevcairiel> not with gcc
[18:49:48 CET] <nevcairiel> and msvc doesnt use that particular syntax anyway
[18:50:05 CET] <BtbN> But configure translates that syntax to something msvc understands iirc
[18:50:16 CET] <BtbN> replace -l with a .lib suffix
[18:50:26 CET] <nevcairiel> yeah but if there is a special case for something, it should be handled special, and not break shit
[18:50:43 CET] <rcombs> libiberty
[18:51:15 CET] <nevcairiel> i have two mfx variants installed, one from luca and one straight from the sdk, one has libmfx.a and one has mfx.lib
[18:51:21 CET] <nevcairiel> so no clue what that commit is on about
[18:51:39 CET] <nevcairiel> .. and neither work after that commit
[18:53:04 CET] <jamrial> that commit shouldn't affect the variant that ships with a pkg-config file
[18:53:20 CET] <nevcairiel> as if you use pkg-config on windows
[18:53:57 CET] <jamrial> why wouldn't i? lots of external deps need it after all
[18:54:39 CET] <nevcairiel> because you have to manually add shit to the pkg-config path lookup thing, which is for me less intuitive then just adding -I and -L flags
[18:55:30 CET] <jamrial> in my case i don't since i use the msys2's mingw package :p
[18:56:51 CET] <jamrial> for development, though. to compile actual static binaries i use your gcc builds
[18:57:47 CET] <nevcairiel> anyway that commit there still assumes nothing but a msvc environment, which is not a given,  might as well be gcc
[19:06:15 CET] <nevcairiel> jamrial: builds fine
[19:06:30 CET] <jamrial> nevcairiel: thanks
[19:08:27 CET] <cone-192> ffmpeg 03James Almer 07master:ac6691ab9938: avio: update avio_alloc_context() doxy
[19:08:28 CET] <cone-192> ffmpeg 03Huang, Zhengxu 07master:8d3666c42560: libavfilter/vf_vpp: Add common filters of the qsv vpp
[19:08:29 CET] <cone-192> ffmpeg 03Huang, Zhengxu 07master:a5a6ac1a123a: libavfilter/overlay_qsv: Add QSV overlay vpp filter
[19:08:30 CET] <cone-192> ffmpeg 03James Almer 07master:64f9188aae2d: Merge commit 'ac6691ab9938107d818cd8066ce3ea329ad14d8d'
[19:08:31 CET] <cone-192> ffmpeg 03James Almer 07master:4391d6cb8180: Merge commit 'a5a6ac1a123a927e5bed984ed757a29b7ff87dab'
[19:22:43 CET] <nevcairiel> BtbN: i pushed a new version with the #ifs reindented
[19:22:59 CET] <cone-192> ffmpeg 03Vittorio Giovara 07master:2b50847e0f8f: pixdesc: Add API to map color property names to enum values
[19:23:00 CET] <cone-192> ffmpeg 03Sean McGovern 07master:9e3610227825: smacker: return meaningful error codes on failure
[19:23:01 CET] <cone-192> ffmpeg 03Michael Niedermayer 07master:ec683ed527ce: smacker: fix integer overflow with pts_inc
[19:23:02 CET] <cone-192> ffmpeg 03Mark Thompson 07master:9ed18f302b09: cbs_h264: Fix writing streams with auxiliary pictures
[19:23:03 CET] <cone-192> ffmpeg 03Jacek Jendrzej 07master:9b1c0911146c: http: Reset compressed header flag when starting to read a request
[19:23:04 CET] <cone-192> ffmpeg 03Mark Thompson 07master:3cae7f8b9baa: cbs: Add some read/write tests
[19:23:05 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:516c47917275: checkasm: Test more h264 idct variants
[19:23:06 CET] <cone-192> ffmpeg 03James Almer 07master:f14644188440: Merge commit '3cae7f8b9baaf43789490b676d8f5825f2e1bc2c'
[19:23:07 CET] <cone-192> ffmpeg 03James Almer 07master:0cef66c906a5: Merge commit '516c479172755c63063180b0c0953b68b670cdbd'
[19:23:50 CET] <BtbN> nevcairiel, it's not on github though
[19:24:19 CET] <nevcairiel> oh, now it is
[19:25:05 CET] <cone-192> ffmpeg 03Luca Barbato 07master:ccbb31c14b76: qsv: Make sure the session is set with the latest version
[19:25:06 CET] <cone-192> ffmpeg 03Luca Barbato 07master:ea25ccd1b2a9: qsv: Join the derived session to the parent
[19:25:07 CET] <cone-192> ffmpeg 03James Almer 07master:8c82c4d25d36: Merge commit 'ccbb31c14b766ef666ef2daa8c467e478183a957'
[19:25:08 CET] <cone-192> ffmpeg 03James Almer 07master:1a24d4f020ee: Merge commit 'ea25ccd1b2a980df8d43cc1f86a23e3c094090a6'
[19:25:48 CET] <BtbN> AV_PIX_FMT_D3D11 is always defined, even on Linux, right?
[19:25:58 CET] <nevcairiel> yeah
[19:26:38 CET] <nevcairiel> i wonder if i can use some generic type for ctx->d3d11_device and avoid a bunch more of those #ifs
[19:27:24 CET] <BtbN> well, can always use a void* and cast
[19:27:41 CET] <nevcairiel> its C, dont really need to cast pointers
[19:28:11 CET] <BtbN> Or you could just typedef ID3D11Device to void* in the else clause of the include in the header
[19:32:01 CET] <BtbN> I wonder why the nvdec people at libav copy the bitstream all the time
[19:32:54 CET] <BtbN> All the other hwaccels just use the buffer they get, as it always has all slices in the same buffer anyway
[19:33:17 CET] <BtbN> Oh wait, I see why... Because at least for h264/hevc, CUVID wants start codes...
[19:33:41 CET] <BtbN> so it's copied with size + 3, and the then the 3 byte start code is inserted
[19:33:42 CET] <BtbN> great
[19:33:54 CET] <nevcairiel> dxva also copies the buffer, because you need to use a buffer provided by the API. So you need to copy the slice into that one (and add start codes in the process)
[19:33:54 CET] <BtbN> lets hope VP9 doesn't need something like that
[19:34:32 CET] <BtbN> dxva2_vp9.c does not do any copying in fill_slice
[19:35:07 CET] <nevcairiel> its in commit_bitstream_and_slice_buffer
[19:35:16 CET] <BtbN> ah, it does it in the end
[19:35:39 CET] <nevcairiel> its entirely unavoidable for dxva/d3d11va tho, because you need to use the drivers buffers
[19:35:40 CET] <BtbN> nvdec just wants system buffers, and reads them only once, during cuvidDecodePicture
[19:36:04 CET] <BtbN> So the only reason it needs a copy for h264 and hevc is that it wants start-codes
[19:49:52 CET] <cone-192> ffmpeg 03Mark Thompson 07master:d41e10c1485e: hevc: Fix aligned array declarations
[19:49:53 CET] <cone-192> ffmpeg 03Mark Thompson 07master:2068d116db98: hapdec: Delete include for nonexistent file
[19:49:54 CET] <cone-192> ffmpeg 03Mark Thompson 07master:92f0aceb36c6: cinepakenc: Move declaration out of for initialisation statement
[19:49:55 CET] <cone-192> ffmpeg 03James Almer 07master:d66fe7ff53a5: configure: Add test_pkg_config()
[19:49:56 CET] <cone-192> ffmpeg 03James Almer 07master:b212eff773b8: Merge commit '92f0aceb36c6e4412d4cf346e70dc74b5a4069e9'
[19:49:57 CET] <cone-192> ffmpeg 03James Almer 07master:93ccba96df63: Merge commit 'd66fe7ff53a5cade7a702100a9006dfe5ae1c473'
[19:58:05 CET] <cone-192> ffmpeg 03James Almer 07master:ebfcce16ac44: configure: Use test_pkg_config() for the SDL check
[19:58:06 CET] <cone-192> ffmpeg 03James Almer 07master:3d828c9fd51a: cpu: split flag checks per arch in av_cpu_max_align()
[19:58:07 CET] <cone-192> ffmpeg 03James Almer 07master:2014231039de: extract_extradata: return an error when buffer allocation fails
[19:58:08 CET] <cone-192> ffmpeg 03James Almer 07master:ab6422e1333e: configure: rename hevc_ps to hevcparse
[19:58:09 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:09c98327b9f2: build: Drop support for Tru64 Unix (OSF/1)
[19:58:10 CET] <cone-192> ffmpeg 03James Almer 07master:8a5e1a4b4673: Merge commit 'ab6422e1333e1c8b99e97ac61e3e9b2f6a2b4936'
[19:58:11 CET] <cone-192> ffmpeg 03James Almer 07master:c58436881798: Merge commit '09c98327b9f25c6c1716c0ee82ce09d8b484887a'
[20:01:35 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:fca9ca539c8c: configure: Drop unused or internally-used entries from variable lists
[20:01:36 CET] <cone-192> ffmpeg 03James Almer 07master:0efdc768eb63: Merge commit 'fca9ca539c8c6e4fe0072486c7e0479a08a15e7c'
[20:04:04 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:4064f4288968: build: Drop explicit check for dlfcn.h
[20:04:05 CET] <cone-192> ffmpeg 03James Almer 07master:1409c2b7baa9: Merge commit '4064f42889685e7122cfad4934b060098c147753'
[20:05:20 CET] <wbs> nevcairiel: about gnu vs lib.exe produced import libraries, so the only issue I knew about seems to have been fixed in MSVC 2012
[20:06:13 CET] <nevcairiel> so they work properly now with all optimizations on? previously you had to disable some or it would lose symbols
[20:06:35 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:e7168d4c0cb2: configure: Drop redundant header check for d3d11.h
[20:06:36 CET] <cone-192> ffmpeg 03James Almer 07master:084e7fbe49fb: Merge commit 'e7168d4c0cb279cf267690549ca92ad564572bc6'
[20:06:36 CET] <wbs> yes, with MSVC 2010 you had to do -opt:noref in the linker in order for it not to crash at runtime
[20:06:41 CET] <wbs> with 2012 it seems to be fine to me
[20:06:55 CET] <wbs> dunno if it's just a lucky coincidence for the test case I've used or actually fixed
[20:08:56 CET] <nevcairiel> still somewhat of a sign that the gnu import libraries arent all perfect
[20:09:11 CET] <wbs> yes, they are doing things completely differently
[20:09:35 CET] <wbs> FWIW, lld can only link to the MSVC style import libraries currently
[20:09:58 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:29ccc641b17a: build: Drop check for sys/mman.h in favor of mmap() check
[20:09:59 CET] <cone-192> ffmpeg 03James Almer 07master:869401cefc22: Merge commit '29ccc641b17afad058a5c24071ea827865a8b3a9'
[20:10:31 CET] <wbs> the lld author said he hadn't figured out how to do it for real, so it's doing some kind of weird shortcut - we haven't really figured out the right way to make the logic to make it work properly (and trying to read GNU binutils source probably produces more headache than trying to reverse engineer it :P)
[20:11:23 CET] <wbs> not sure if that means that the gnu ones are out of spec or just that lld doesn't implement The Right Way of doing linking
[20:14:29 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:8e97a8c69162: build: Remove check for gsm/gsm.h for libgsm
[20:14:30 CET] <cone-192> ffmpeg 03James Almer 07master:1a4315f24d2c: Merge commit '8e97a8c69162afce47abea96c8c0914f3550e212'
[20:20:53 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:b586903ae1b8: build: Drop redundant check for soundcard.h
[20:20:54 CET] <cone-192> ffmpeg 03James Almer 07master:fdd03d2d790e: Merge commit 'b586903ae1b89e2d8b99c79f33cabe9b3ca03784'
[20:25:05 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:421c10ed4fb0: configure: Drop test for fork()
[20:25:06 CET] <cone-192> ffmpeg 03James Almer 07master:08fd6e8e3c8f: Merge commit '421c10ed4fb0475a2cb055dd130ba12a6adb9f70'
[20:29:36 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:3e5950287317: configure: Drop unused attribute checks
[20:29:36 CET] <cone-192> ffmpeg 03James Almer 07master:814e217d14e4: Merge commit '3e5950287317938e6b81e7ef8f024b403c303289'
[20:30:49 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:1c047c8f4d5e: configure: Drop stray extralibs for libspeex
[20:30:50 CET] <cone-192> ffmpeg 03James Almer 07master:b9ab980cd94f: Merge commit '1c047c8f4d5e016e89250afdeb88a4fea707cc1c'
[20:32:34 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:76481f57b528: configure: Remove pointless empty *_COMPONENTS variables
[20:32:35 CET] <cone-192> ffmpeg 03James Almer 07master:e2989c74dcf1: Merge commit '76481f57b528168b00035aee76f7e0878669011f'
[20:33:45 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:010baac12a14: configure: Fix stupid typo in gsm.h header name
[20:33:46 CET] <cone-192> ffmpeg 03James Almer 07master:d80abb645f8d: Merge commit '010baac12a14d684a1ae72f6b7509e642c40f3b3'
[20:34:29 CET] <jamrial> does anyone use --enable-random?
[20:34:41 CET] <nevcairiel> fate does
[20:35:02 CET] <jamrial> i remember there was a client using it, but it's not listed anymore
[20:35:10 CET] <jamrial> i think it was ubitux's
[20:36:45 CET] <jamrial> eh, it doesn't hurt, so i'll not remove it for now
[20:41:00 CET] <lrusak> jkqxz: ping
[20:43:02 CET] <lrusak> here is a test patch I did to get drmprime working in v4l2. I'm not sure how to get this into something that would be able to go upstream http://sprunge.us/IMOS
[20:43:49 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:a688b64fcf4a: configure: Drop feature for randomly disabling/enabling components
[20:43:50 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:8594ec3dd59e: configure: Drop fallback for deprecated avserver command line options
[20:43:51 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:3613063e8730: configure: Simplify nvenc check (and move it to the correct spot)
[20:43:52 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:4f6401df43d7: configure: Merge separate parts of GnuTLS test
[20:43:53 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:b46900914a1f: build: Merge mach/mach_time.h and mach_absolute_time() checks
[20:43:54 CET] <cone-192> ffmpeg 03James Almer 07master:28e012234a9b: Merge commit '4f6401df43d7ee9082ea591037b9f9284217d834'
[20:43:55 CET] <cone-192> ffmpeg 03James Almer 07master:4e754e94195b: Merge commit 'b46900914a1f25ce8dbf49d7c53766ff1f18b60f'
[20:45:16 CET] <ubitux> jamrial: wtf, random they dropped --enable-random??
[20:45:22 CET] <jamrial> yeah
[20:45:28 CET] <jamrial> i nooped the commit
[20:45:46 CET] <jamrial> your fate instance is gone, but figured you'd put it back eventually :p
[20:46:23 CET] <ubitux> heh yeah i will
[20:46:23 CET] <iive> atomnuker: because I remember you had some issues with rpi, this might be interesting read https://www.raspberrypi.org/blog/xenon-death-flash-a-free-physics-lesson/
[20:46:29 CET] <ubitux> it's very useful
[20:46:38 CET] <ubitux> it often raises configure bugs
[20:47:12 CET] <wbs> ubitux: fwiw, for finding such bugs, an even more effective way is to exhaustively try components with --disable-everything --enable-decoder=one
[20:47:37 CET] <ubitux> random is to be used with --disable-everything
[20:48:16 CET] <wbs> yes
[20:48:29 CET] <ubitux> jamrial: i will update the flags of the random instance soon
[20:48:42 CET] <ubitux> it's broken for a while bc of Unknown option "--enable-netcdf".
[20:48:55 CET] <ubitux> probably done some shit in it
[20:49:23 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:62d5b5a9d3b0: configure: Extend check_header() to allow checking for multiple headers
[20:49:24 CET] <cone-192> ffmpeg 03James Almer 07master:84522ad3fe77: Merge commit '62d5b5a9d3b0181335072d6fa792f2d805bc27b6'
[20:52:24 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:93797681c231: build: Rename stdatomic_h variable to stdatomic
[20:52:25 CET] <cone-192> ffmpeg 03James Almer 07master:8882e8ad0d5c: Merge commit '93797681c2310faeeb0158f66f471965213904c6'
[20:54:34 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:7ac092d05de4: build: CryptGenRandom --> wincrypt, it is a better name
[20:54:35 CET] <cone-192> ffmpeg 03James Almer 07master:3f272009547f: Merge commit '7ac092d05de487d088bc96ab4a7bd6207fbfa98c'
[20:56:22 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:f951837ce58e: configure: Don't add -fPIC to cflags for target_os=win32
[20:56:23 CET] <cone-192> ffmpeg 03James Almer 07master:7e3d6f10f08a: Merge commit 'f951837ce58e8588b175fb53a76fd453a81528ec'
[20:57:55 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:0ca66409911e: configure: Don't add -fPIC to asflags when targeting windows
[20:57:56 CET] <cone-192> ffmpeg 03James Almer 07master:ce726e775793: Merge commit '0ca66409911e9fba940424be8bdfa54e056b0a4b'
[20:58:49 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:40d5df67d2c4: configure: Add a comment about why we don't try to enable pic on arm on target_os=win32
[20:58:50 CET] <cone-192> ffmpeg 03James Almer 07master:1338cc1ac293: Merge commit '40d5df67d2c4e1f0dd1e902435567eb5edad6a9a'
[20:59:06 CET] <atomnuker> iive: yeah, I've seen that, in my case it was crapbian's fault
[21:00:05 CET] <iive> software fault... heh
[21:00:11 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:a37e84be6931: makedef: Add support for identifying the ARM64 machine type
[21:00:12 CET] <cone-192> ffmpeg 03James Almer 07master:ab7c8e1d6cc9: Merge commit 'a37e84be69310cd7de9540c8bc194cb0a6d158ed'
[21:01:07 CET] <atomnuker> speaking of software faults I'm very disappointed with ipfs
[21:01:26 CET] <atomnuker> "lets write a decentralized filesystem to make the net p2p!"
[21:01:34 CET] <atomnuker> "lets do it in fucking go!"
[21:02:28 CET] <atomnuker> and they did, and it only works with very specific revisions of around 300 (seriously!) repositories
[21:02:43 CET] <atomnuker> and it doesn't support anything that isn't mainstream (no aarch64)
[21:03:01 CET] <JEEB> that somehow feels like a problem not with golang but with something else. other than the aarch64 part, although I thought golang supported that?
[21:03:30 CET] <atomnuker> it does, but the make process itself doesn't, if your system is unsupported you need to use make install_unsupported
[21:03:42 CET] <atomnuker> which clones each repo's git master and tries to go with that
[21:03:47 CET] <JEEB> geez
[21:03:48 CET] <cone-192> ffmpeg 03Michael Niedermayer 07master:eb3c1a94adbc: pictor: Correctly check frame dimensions
[21:03:49 CET] <cone-192> ffmpeg 03James Almer 07master:f72ebccb7689: Merge commit 'eb3c1a94adbc28411610167d3dac583436e50125'
[21:03:51 CET] <atomnuker> which doesn't work because lol what's a stable api
[21:04:14 CET] <JEEB> I mean, go get does that but I think every project I know that's sane does dependency handling versioned with godep or something
[21:04:36 CET] <atomnuker> this one uses gx which isn't in the arch repos
[21:04:58 CET] <JEEB> and it seems the golang people finally figured that defaulting to HEAD of master in dependencies is not really applicable outside of GOOG
[21:05:09 CET] <JEEB> so they're now making their official proper dependency handler thingamajig
[21:05:53 CET] <jamrial> huh
[21:05:57 CET] <jamrial> "Remove all output devices"
[21:06:21 CET] <atomnuker> also ipfs doesn't actually use encryption by default so like what's the point of makit it decentralized
[21:06:23 CET] <jamrial> yeah, i don't think this one will fly
[21:07:17 CET] <atomnuker> and looking at their issue tracker the devs are the slowest I've seen at getting things done
[21:07:43 CET] <atomnuker> "there's a fix and its in this pr but it'll take a month or so to test it, verift it, etc, etc."
[21:10:15 CET] <jamrial> oh right, there was a thread about this
[21:11:52 CET] <ubitux> durandal_1707: netcdf seems more common than mysofa
[21:12:08 CET] <ubitux> at least the former is packaged here
[21:13:05 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:8e7e042d41ac: Remove all output devices
[21:13:06 CET] <cone-192> ffmpeg 03James Almer 07master:cd95074ff441: Merge commit '8e7e042d41ac42f01d5573a4b0f7d9060356bd46'
[21:13:07 CET] <cone-192> ffmpeg 03James Almer 07master:e5233b15814d: doc/libav-merge: mention skipped outdev removal commit
[21:13:42 CET] <durandal_1707> netcdf is bloated
[21:14:42 CET] <durandal_1707> and have dependency hell
[21:16:54 CET] <ubitux> okay
[21:17:33 CET] Action: ubitux can't find the config.log anymore with fate
[21:18:15 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:8d3db95f201f: sndio: Coalesce source files after outdev removal
[21:18:16 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:6ce13070bdde: oss: Coalesce source files after outdev removal
[21:18:17 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:d46cd2498614: alsa: Coalesce source files after outdev removal
[21:18:18 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:543f00c78e6d: avfoundation: Drop silly _dec suffix from filename
[21:18:19 CET] <cone-192> ffmpeg 03Josh de Kock 07master:762ab2de6ead: Remove dv1394 input device
[21:18:20 CET] <cone-192> ffmpeg 03James Almer 07master:24204eae1c7d: Merge commit '762ab2de6ead68cfe6617d1960921878ddece9e1'
[21:18:21 CET] <cone-192> ffmpeg 03James Almer 07master:ac36d0c97a9d: doc/libav-merge: mention more skipped outdev removal commits
[21:19:45 CET] <BtbN> VP9 is annoying with its lack of a proper spec
[21:20:05 CET] <BtbN> every implementation asks for way different things, because they interpret the reference implementation differently
[21:22:04 CET] <omerjerk> Hi
[21:30:04 CET] <durandal_1707> hi
[21:30:29 CET] <BtbN> If someone has a some vp9 experience, I'm looking for all the stuff marked with TODO: https://github.com/BtbN/FFmpeg/commit/f01a3efa00660db31dd888ca9dbd3e694f89eb02
[21:31:08 CET] <jamrial> michaelni: can you upload h264/ref-pic-mod-overflow.h264 from libav's fate samples suite to ours?
[21:40:29 CET] <jamrial> BtbN: poke BBB
[21:41:12 CET] <atomnuker> does cuda support full-range output? I've seen full range vp9 files out there
[21:41:16 CET] <cone-192> ffmpeg 03Luca Barbato 07master:077011b5af2b: qsv: Expose idr_interval for hevc as well
[21:41:17 CET] <cone-192> ffmpeg 03James Almer 07master:643e3369369f: Merge commit '077011b5af2b3150efc52a9b58f5ef9bb0235087'
[21:41:23 CET] <atomnuker> erm nvdec
[21:41:47 CET] <BtbN> It does check the colorspace at lest
[21:41:52 CET] <BtbN> but no colorrange i think
[21:42:53 CET] <atomnuker> (what I really meant by "I've seen" was I've made one a year ago)
[21:46:23 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:1c5f264787b1: mss1: Add missing macro parameters to ARITH_GET_* macros
[21:46:24 CET] <cone-192> ffmpeg 03Mark Thompson 07master:fbd63170bcbc: cbs: Add test dependencies
[21:46:25 CET] <cone-192> ffmpeg 03James Almer 07master:17126f126838: Merge commit 'fbd63170bcbc5cad8965edad7c357f6eb4132250'
[21:47:24 CET] <omerjerk> How do I run date tests for one particular codec only?
[21:47:38 CET] <omerjerk> I couldn't find this information on the website.
[21:48:22 CET] <JEEB> make fate-SOMETHING
[21:48:34 CET] <JEEB> for example make fate-movenc
[21:49:04 CET] <JEEB> you will see the groups and specific tests' names in the Makefiles
[21:50:13 CET] <atomnuker> there's a lot of makefiles so I just run a full fate until something fails and it prints out what
[21:50:48 CET] <omerjerk> Thanks a lot! I was looking for this only.
[21:51:06 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:69ac24e556c6: aarch64: Get rid of a stray double space
[21:51:07 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:732510636e59: aarch64: Remove a dot from a label
[21:51:08 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:41df62fd674b: configure: Set the default assembler to armasm64 for MSVC for arm64
[21:51:09 CET] <cone-192> ffmpeg 03Luca Barbato 07master:98afe3fb71af: qsv: Make the hevc idr_interval consistent with the h264 one
[21:51:10 CET] <cone-192> ffmpeg 03James Almer 07master:529de4f1b6ae: Merge commit '69ac24e556c6fbc7138be5a60d0b90d2a5676c3d'
[21:51:11 CET] <cone-192> ffmpeg 03James Almer 07master:0525722ca03a: Merge commit '732510636e597585a79be7d111c88b3f7e174fe7'
[21:51:12 CET] <cone-192> ffmpeg 03James Almer 07master:5fd3e6c3a619: Merge commit '41df62fd674bd0c67f7b6952381d235a393245d6'
[21:51:13 CET] <cone-192> ffmpeg 03James Almer 07master:8725cf424c90: Merge commit '98afe3fb71afd4a18009924aaba56bc577bbd400'
[21:51:47 CET] <BtbN> BBB, primarily looking for frameTagSize and offsetToDctParts. When spying on what the cuvid-native parser does, the offset is 3 most of the time, and the tag size is 10 or 11 mostly, but sometimes the offset is notably larger
[21:51:48 CET] <jamrial> make fate-list should show you all the test
[21:51:49 CET] <jamrial> or most
[21:54:16 CET] <omerjerk> okay. Thanks for this information. 
[21:56:47 CET] <nevcairiel> BtbN: if refFrameSignBias is anything like dxva, then index 0 is always 0, and the other are shifted one up
[21:57:50 CET] <BtbN> nevcairiel, it's kinda hard to verify that, as when spying on original cuvid, they are all always 0
[21:59:05 CET] <BtbN> activeRefIdx seems to have the values 0, 1 and 2 in various orders
[22:02:34 CET] <nevcairiel> thats probably h->h.refidx[0-3]
[22:02:44 CET] <nevcairiel> 0-2
[22:03:22 CET] <nevcairiel> hm or maybe not, apparently you set those already to something else
[22:07:15 CET] <nevcairiel> anyway a bunch of those properties i exported from vp9dec when i wrote the dxva support, so if you need anything else
[22:08:03 CET] <cone-192> ffmpeg 03James Almer 07master:fb94e7b39a17: Revert "Merge commit '8e97a8c69162afce47abea96c8c0914f3550e212'"
[22:17:44 CET] <BtbN> .frameTagSize = h->h.uncompressed_header_size, .offsetToDctParts = h->h.compressed_header_size,
[22:17:52 CET] <BtbN> that matches perfectly it seems
[22:19:14 CET] <BBB> BtbN: line 104-6, this is the index in the array of 8 of available references
[22:19:52 CET] <BBB> I think line 111 is the data2size
[22:20:03 CET] <BBB> basically the size of the compressed header
[22:20:20 CET] <BBB> line 80 makes no sense, theres noly 3 reference so there can never be a ref[3]
[22:20:46 CET] <BtbN> Yeah, it seems they just start counting at 1 for some reason
[22:20:51 CET] <BBB> oh
[22:20:51 CET] <BBB> aha
[22:20:57 CET] <BBB> its probably libvpx'ish
[22:21:01 CET] <BtbN> so 0 is always empty
[22:21:02 CET] <BBB> they count ref[0] as intra
[22:21:03 CET] <nevcairiel> refFrameSignBias[0] is supposedly for intra frames
[22:21:06 CET] <nevcairiel> yeah
[22:21:07 CET] <BtbN> DXVA seems to work the same
[22:21:09 CET] <nevcairiel> its a bit odd
[22:21:12 CET] <BBB> theres an enum { INTRA, LAST, GOLDEN, ALTREF }
[22:21:19 CET] <BBB> its totally bonkers
[22:21:23 CET] <BBB> bit odd"
[22:21:43 CET] <BtbN> Where would I get that index of reference frames?
[22:21:49 CET] <BBB> look for refidx
[22:22:03 CET] <BBB>             s->s.h.refidx[0]      = get_bits(&s->gb, 3);
[22:22:07 CET] <BBB> use that
[22:22:13 CET] <BtbN> refidx goes into LastRefIdx/GoldenRefIdx/AltRefIdx
[22:22:22 CET] <BtbN> and does not match what nvidias parser puts into activeRefIdx
[22:22:46 CET] <BBB> uh...
[22:22:51 CET] <BBB> then I dont know?
[22:23:36 CET] <BBB> maybe it has to do with fix vs. var ref in compound (bidirectional) prediction?
[22:23:49 CET] <BtbN> That's an example of some values the nvidia parser sets: https://bpaste.net/show/409c0a25d158
[22:24:03 CET] <BtbN> LastRefIdx: 10 seems way too large?
[22:24:11 CET] <BtbN> they are way larger than 8 most of the time
[22:24:51 CET] <BBB> maybe its the index of the buffer in your internal bufpool?
[22:24:53 CET] <nevcairiel> it uses the surface index, which could be higher
[22:25:24 CET] <BBB> right
[22:25:29 CET] <BtbN> h->h.refidx[0] indeed seems to go into activeRefIdx, and alt/last/golden is something else
[22:25:58 CET] <BBB> lines 98-101 should be ok as-is
[22:26:18 CET] <BBB> I dont know what last/alt/golden is, very confusing to have two indirections there instead of one ...
[22:26:33 CET] <BtbN> vaapi also has some that are called like that
[22:26:47 CET] <BtbN> but there it's just the refidx
[22:38:51 CET] <BtbN> I think I understand what it is
[22:39:16 CET] <nevcairiel> one is probably the array index, one the surface index
[22:39:30 CET] <nevcairiel> you dont set the surface index anywhere, so thats probably missing
[22:39:32 CET] <BtbN> the last/alt/golden ones are constantly increasing
[22:39:53 CET] <BtbN> the activeRefIdx are just 0/1/2 for my test video all the time, so likely the array index
[22:40:48 CET] <BtbN> hm, nope, not constantly increasing. It stops at some point
[22:41:12 CET] <BtbN> Is the surface index already somewhere in vp9shared.h? Can't seem to see it
[22:41:35 CET] <nevcairiel> you would have to extract that from the avframe
[22:41:45 CET] <nevcairiel> ie something like ff_dxva2_get_surface_index
[22:41:47 CET] <nevcairiel> for nvdec
[22:42:13 CET] <BtbN> I'd have to get in there somehow first
[22:45:11 CET] <nevcairiel> apparently that number is stored in NVDECFrame in FrameDecodeData->hwaccel_priv
[22:45:39 CET] <BtbN> yes, it's what goes into .CurrPicIdx        = cf->idx,
[22:48:05 CET] <nevcairiel> h->refs[i].f gets you to the frame, so deref stuff from there
[22:48:08 CET] <BtbN> .LastRefIdx = ((NVDECFrame*)((FrameDecodeData*)h->refs[h->h.refidx[0]].f->private_ref->data)->hwaccel_priv)->idx,
[22:48:09 CET] <BtbN> great
[22:48:15 CET] <nevcairiel> make a helper function =p
[22:49:51 CET] <BtbN> Yeah, definitely needs one
[22:50:05 CET] <BtbN> as it just explodes with a segfault done the dumb way
[22:56:56 CET] <BtbN> yep, that looks promising
[22:57:03 CET] <nevcairiel> thats why i dont like that inline struct syntax, it doesnt leave you as flexible to put logic in there
[22:57:53 CET] <BtbN> Well, even in that case, I'd have used a function
[22:58:23 CET] <BtbN> refreshEntropyProbs is the only thing left TODO now
[22:58:28 CET] <atomnuker> oh wow, patches by Jaroslav Kysela, the original alsa dev
[22:58:42 CET] <BtbN> it's a single bit value, so it shouldn't be terrible hard to find in vp9.c
[22:59:56 CET] <michaelni> jamrial, uploaded
[23:00:20 CET] <ubitux> tsan doesn't like cfhd it seems
[23:00:36 CET] <jamrial> michaelni: thanks
[23:00:42 CET] <ubitux> jamrial: random is restored btw, thanks for not merging it
[23:01:06 CET] <nevcairiel> BtbN: h->h.refreshctx maybe?
[23:01:36 CET] <BtbN> yeah, looking at that as well
[23:01:54 CET] <nevcairiel> i pass that value to dxva for one variable
[23:02:22 CET] <BtbN> it has to be that, it's like the only simple single bit value it does not get yet
[23:03:56 CET] <jamrial> ubitux: no prob
[23:13:40 CET] <BtbN> Yeah, seems to work flawlessly now
[23:24:02 CET] <BtbN> hm, do I cast away a const qualifier, or do I do an extra memcpy
[23:33:39 CET] <kierank> michaelni: do you want sliced threads ER fuzzed?
[23:40:50 CET] <michaelni> we could push the patch and make tools/target_dec_fuzzer.c test slices 50% of the cases maybe, if the patches are ok
[23:41:19 CET] <ubitux> mmh mpeg hacks @ https://www.reddit.com/r/programming/comments/7carby/youtube_commenter_describes_how_him_and_his_team/dpoewdz/
[23:45:28 CET] <BtbN> I'm a bit confused about I/P/B frames they use
[23:45:32 CET] <BtbN> cummulative errors in I frames?
[23:46:06 CET] <nevcairiel> yeah it sounds totally odd
[23:46:21 CET] <nevcairiel> it sounds like they mixed up the types entirely
[23:46:32 CET] <nevcairiel> We immediately eliminated P-frames and tried to place as many I-frames as we could between B-frames.
[23:46:33 CET] <nevcairiel> like, what
[23:48:30 CET] <BtbN> I assume they eliminated B frames, and wanted to have the gop as long as possible?
[23:48:41 CET] <BtbN> So as many P bframes between I frames as possible
[23:48:47 CET] <BtbN> which sounds about normal
[23:51:12 CET] <iive> it sounds totaly fake
[23:51:26 CET] <iive> and the low resolution of the b-frames thing too.
[23:52:16 CET] <iive> e.g. spp filter blurs low quants more, since b-frames usually have lower quants, there was quite visible pulsing.
[23:53:26 CET] <BtbN> keep in mind, they mean the I frames with that
[23:53:40 CET] <BtbN> so the I frames were encoded at lower res
[23:53:48 CET] <iive> no, they don't
[23:54:26 CET] <BtbN> That text definitely massively mixes up I/P/B
[23:56:56 CET] <iive> well, 2 I frames per second makes more sense :D
[23:57:47 CET] <iive> cummulative errors in I-frames, indicates they are actually P-frames.
[23:58:52 CET] <iive> btw, mpeg1 had a frame type, that had only DC encoded.
[23:59:27 CET] <iive> something for faster decoding when seeking in editing.
[00:00:00 CET] --- Sun Nov 12 2017