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

[burek]

[01:27:58 CET] <cone-754> ffmpeg 03James Zern 07master:b765a04550ff: configure: require libvpx-1.4.0 for vp[89] support
[01:27:59 CET] <cone-754> ffmpeg 03James Zern 07master:e54061ae6a5e: libvpx: remove pre-1.4.0 checks
[01:28:00 CET] <cone-754> ffmpeg 03James Zern 07master:e60dbe421c7e: libvpxdec: remove pre-1.4.0 checks
[01:28:01 CET] <cone-754> ffmpeg 03James Zern 07master:753074721bd4: libvpxenc: remove pre-1.4.0 checks
[03:06:12 CET] <atomnuker> oh look, another option to hack around libvpx's rate control
[03:07:41 CET] <atomnuker> you know, it would be better to just let our rate control system handle it if we could adjust the quantization index per frame without the encoder touching it
[03:09:11 CET] <atomnuker> though even if we could, the encoder still touches the quantization index in constant quantizer mode (on every frame with a pyramid-like interval between golden frames + some random magic offset IIRC)
[03:14:16 CET] <cone-754> ffmpeg 03Dale Curtis 07master:7010dd98b575: Fix undefined shift on assumed 8-bit input.
[03:14:17 CET] <cone-754> ffmpeg 03Dale Curtis 07master:bce8fc0754c4: Close ogg stream upon error when using AV_EF_EXPLODE.
[03:14:18 CET] <cone-754> ffmpeg 03Jacob Trimble 07master:2d9cf3bf16b9: avformat/mov: Propagate errors in mov_switch_root.
[03:14:19 CET] <cone-754> ffmpeg 03Karthick J 07master:d24e08e97879: avformat/dashenc: Added configuration to override HTTP User-Agent
[03:14:20 CET] <cone-754> ffmpeg 03Jun Zhao 07master:a5870cb37f7a: ffmpeg: add return value check to supress the build warning.
[09:05:39 CET] <cone-724> ffmpeg 03Martin Vignali 07master:6a7eb65e1b1f: checkasm : add utvideodsp test
[09:05:39 CET] <cone-724> ffmpeg 03Martin Vignali 07master:48b7c45b0c6f: avcodec/x86/utvideodsp : make macro for func
[09:05:39 CET] <cone-724> ffmpeg 03Martin Vignali 07master:b5ebe3844354: avcodec/utvideodsp : add avx2 version for the dsp
[09:05:39 CET] <cone-724> ffmpeg 03Martin Vignali 07master:caf51a573d64: avcodec/x86/utvideodsp.asm : cosmetic
[09:27:51 CET] <JEEB> great, someone reviewed those. didn't have the time to pass those through FATE
[09:43:42 CET] <cone-724> ffmpeg 03Martin Vignali 07master:4a6aa6d1b274: checkasm : add test for huffyuvdsp add_int16
[09:43:43 CET] <cone-724> ffmpeg 03Martin Vignali 07master:7f9b67bcb61d: avcodec/huffyuvdsp(enc) : move duplicate macro to a template file
[09:43:44 CET] <cone-724> ffmpeg 03Martin Vignali 07master:6955e8842e24: avcodec/huffyuvdsp : reorganize add_int16 asm
[09:43:45 CET] <cone-724> ffmpeg 03Martin Vignali 07master:e641c94190b6: avcodec/huffyuvdsp : add add_int16 AVX2 func
[09:43:46 CET] <cone-724> ffmpeg 03Martin Vignali 07master:d189a426fa0e: avcodec/huffyuvdspenc : reorganize diff_int16
[09:43:47 CET] <cone-724> ffmpeg 03Martin Vignali 07master:ba98f8463fd1: avcodec/huffyuvdspenc : add diff_int16 AVX2 func
[11:30:10 CET] <stevenli_> GENTEXI	doc/avoptions_format.texi
[11:30:11 CET] <stevenli_> GENTEXI	doc/avoptions_codec.texi
[11:30:13 CET] <stevenli_> i see there have two documents in complie message:
[11:30:41 CET] <stevenli_> are these merge from libav and forget do something?
[12:07:32 CET] <cone-724> ffmpeg 03Martin Vignali 07master:518b9ee3d16f: avcodec/hapdec : reorganize code before adding multi-texture decoding
[12:07:33 CET] <cone-724> ffmpeg 03Martin Vignali 07master:fca891996159: avcodec/hapdec : indent after previous commit
[12:07:34 CET] <cone-724> ffmpeg 03Martin Vignali 07master:2053832d1caa: avcodec/hapdec : add support for hapqa decoding
[12:07:35 CET] <cone-724> ffmpeg 03Martin Vignali 07master:37810bee7839: fate/hapdec : add test for hapqa decoding
[12:27:15 CET] <cone-724> ffmpeg 03Paul B Mahol 07master:afd2bf54c31b: avfilter/avf_avectorscope: add swap and mirror options
[14:10:49 CET] <cone-724> ffmpeg 03Michael Roitzsch 07release/3.4:752659ff1e0f: lavfi/af_pan: fix sign handling in channel coefficient parser
[15:31:24 CET] <cone-724> ffmpeg 03James Almer 07master:ebf352116b31: x86/constants: make pb_80 32 byte wide
[15:31:25 CET] <cone-724> ffmpeg 03James Almer 07master:beb63baa6961: x86/utvideodsp: reuse shared constants
[15:31:26 CET] <cone-724> ffmpeg 03James Almer 07master:9a05c873cf2c: checkasm/utvideodsp: fix mixed declarations and code
[15:31:27 CET] <cone-724> ffmpeg 03James Almer 07master:bea8eeaa2c0c: checkasm/utvideodsp: zero initialize the entire buffer
[16:37:39 CET] <JEEB> grumblegrumble. found breakage in the awesome thingamajig that's called sub2video
[16:38:31 CET] <JEEB> if you get only enough data from a live input and overlay stuff then you can end up in a situation where an SD subtitle isn't getting scaled to the video frame
[16:39:42 CET] <JEEB> was able to replicate same scenario with -probesize 50000
[16:40:49 CET] <JEEB> although funny enough actual non-file inputs do happen to get the video track probed w/h wise, so it's not lacking the parameter sets
[16:41:14 CET] <JEEB> and it works if I just add a scale to the video's resolution manually before overlaying
[16:48:28 CET] <JEEB> the funny thing is that sub2video: using %dx%d canvas seems to give the video's resolution correctly even when it fails, so it doesn't seem to be that?
[17:03:59 CET] <JEEB> ok, [Parsed_overlay_1 @ 0x268f260] main w:1920 h:1080 fmt:yuv420p overlay w:720 h:576 fmt:yuva420p
[17:04:21 CET] <JEEB> while this is what is an OK case
[17:04:23 CET] <JEEB> [Parsed_overlay_1 @ 0x1bbac80] main w:1920 h:1080 fmt:yuv420p overlay w:1920 h:1080 fmt:yuva420p
[17:30:09 CET] <JEEB> jamrial: this seems to have actually fixed the crash (!) https://kuroko.fushizen.eu/samples/ffmpeg_d3d11va_uninit.diff
[17:30:20 CET] <JEEB> (I added a bit more unsetting)
[17:31:18 CET] <jamrial> JEEB: so wait, the crash in CloseHandle() wasn't because you were using a debugger?
[17:33:10 CET] <nevcairiel> it probably crashed differently on some other double free later
[17:36:03 CET] <JEEB> possibly
[17:37:46 CET] <jamrial> send it to the ml or poke jkqxz here then
[17:41:51 CET] <nevcairiel> if you feel like it, might want to set the lock_ctx value to INVALID_HANDLE_VALUE as well
[17:45:29 CET] <JEEB> jamrial: will do as I get to the hotel
[17:45:49 CET] <JEEB> nevcairiel: gotcah
[18:32:45 CET] <cone-724> ffmpeg 03Paul B Mahol 07master:000836c2a98e: avfilter/af_asetnsamples: add missing error check
[20:59:30 CET] <thardin> where is kostya going with nihav?
[21:00:27 CET] <durandal_1707> nihland
[21:06:26 CET] <durandal_1707> ops
[21:09:27 CET] <thardin> behave or you'll get an fflogging
[21:11:43 CET] <SortaCore> so what's going on with cuvid, nvdec and nvenc now?
[21:16:02 CET] <durandal_1707> they are still available...
[21:20:59 CET] <SortaCore> wasn't nv being worked on
[21:22:18 CET] <SortaCore> I see bt and philp talking about it
[21:24:38 CET] <cone-724> ffmpeg 03Michael Niedermayer 07master:0e7865ce4152: avcodec/mpeg4videodec: Check also for negative versions in the validity check
[21:38:23 CET] <philipl> SortaCore: what's the question?
[22:11:40 CET] <SortaCore> is there new stuff to be tested
[23:03:06 CET] <philipl> SortaCore: If you're looking for things to test, sure. :-) I've been working on getting the full set of codecs supported through nvdec so we have parity with cuviddec. That's conceptually done at this point, although vp8 and mjpeg are still waiting on jkqxz to get the hwaccel hooks in.
[23:04:24 CET] <philipl> In an ideal world, we'd then be able to deprecate cuviddec, but there are two outstanding issues: 1) nvdec is slower for a couple of reasons and 2) The de-interlacing capability isn't exposable.
[23:26:43 CET] <nevcairiel> deinterlacing was a hack even before =p
[23:28:37 CET] <philipl> and yet there is no better option.
[23:28:54 CET] <nevcairiel> thats because the cuvid api is terrible in that regard
[23:29:01 CET] <philipl> This is true.
[23:29:29 CET] <nevcairiel> its easy if you want a simple quick all in one solution, but if you try to separate everything properly, stuff gets complicated
[23:29:59 CET] <philipl> Someone could write a vf that uses the claimed ability to 'decode' raw yuv and run it through the deinterlacer.
[23:30:17 CET] <nevcairiel> BtbN tried, but he didnt get it to work
[23:30:28 CET] <philipl> he didn't get the 'decode' part to work, yeah.
[23:31:26 CET] <BtbN> well, the decode-part is all there is
[23:32:12 CET] <philipl> What error did you get?
[23:32:20 CET] <BtbN> a green output
[23:32:34 CET] <philipl> It's a great colour. You shouldn't complain.
[23:32:49 CET] <nevcairiel> everyone likes YUV-zero green
[23:34:59 CET] <philipl> BtbN: did you try using MapVideoFrame with the raw input pointers and not using the decoder at all?
[23:35:21 CET] <BtbN> https://github.com/BtbN/FFmpeg/tree/nvpp
[23:35:23 CET] <nevcairiel> i dont think it takes any input  pointers, does it
[23:35:37 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/bd28b75ded557f68bb9aa7ec8afcb1c93e43f810#diff-df0f5d219a2ac8932fd7a44c36dd41c7R128
[23:35:39 CET] <BtbN> it does
[23:35:46 CET] <BtbN> but if you don't give it a decoder, you just get an error
[23:36:48 CET] <philipl> BtbN: umm.
[23:36:57 CET] <philipl> You didn't set any bistream info when calling the decoder.
[23:37:31 CET] <BtbN> well, there is no bitstream info to be set?
[23:37:38 CET] <philipl> Maybe you need to set it anyway.
[23:37:41 CET] <philipl> One slice, raw yuv frame data
[23:37:58 CET] <BtbN> I tell it about me wanting to input cudaVideoCodec_NV12
[23:38:03 CET] <BtbN> what else would I possibly need to tell it?
[23:38:14 CET] <philipl> but that's in the map call
[23:38:20 CET] <BtbN> no it's not
[23:38:45 CET] <philipl> You are calling cuvidDecodePicture wit no data.
[23:38:47 CET] <philipl> That's my point
[23:40:57 CET] <BtbN> No data in there that I could possibly set makes any sense for yuv input
[23:41:24 CET] <BtbN> the few fields that do make some sense are set
[23:42:01 CET] <philipl> Did you ask one of the nvidia guys how to make this work?
[23:42:05 CET] <philipl> I can't remember.
[23:42:16 CET] <BtbN> Yes, all I got from them was "It should work"
[23:42:24 CET] <philipl> wonderful.
[23:43:16 CET] <philipl> It just seems to me that you have to pass the yuv data to decodePicture somehow. I know that seems weird due to both the PROCPARAMS having input data fields and the fact that the bitstream fields in the PICPARAMS are supposed to be system memory.
[23:43:34 CET] <philipl> What if you stick the CUdeviceptr value in for the bitstream. Just do it. see what happens.
[23:43:53 CET] <BtbN> If it'd be missing a pointer there, I'd expect an error
[23:44:07 CET] <BtbN> and why else would the raw_input_* stuff exist on the vpp_params otherwise?
[23:44:35 CET] <philipl> So many questions, so few answers.
[23:48:10 CET] <philipl> Next silly question - did you look at what was in the returned mapped_frame memory? Could it be there instead of in the raw_output_dptr?
[00:00:00 CET] --- Wed Nov 22 2017