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

Mon Nov 13 03:05:03 EET 2017

[00:05:17 CET] <cone-192> ffmpeg 03Anton Khirnov 07master:ec0f4fa17ce2: FATE: add a test for the H.264 sample fixed by 7c4f6f6
[00:05:18 CET] <cone-192> ffmpeg 03James Almer 07master:b125822d1d07: Merge commit 'ec0f4fa17ce29cf01d4def21041b0b87f7e3105d'
[00:05:34 CET] <iive> ok, they do mean i-frames
[00:05:38 CET] <BBB> BtbN: omg that is hideous
[00:05:49 CET] <BBB> but hey, it works :-p
[00:05:55 CET] <BtbN> BBB, hm?
[00:06:08 CET] <BtbN> You mean that crazy long line?
[00:06:14 CET] <BtbN> I didn't actually do it that way :D
[00:06:20 CET] <BBB> thank goodness
[00:06:33 CET] <BtbN> Specially as the frames are not always set, it's just a crash anyway
[00:08:15 CET] <jamrial> BtbN: https://github.com/jamrial/FFmpeg/commits/mergework can you give that a look (and maybe test :P)?
[00:08:22 CET] <jamrial> it's the next commit in the queue, "lavc: external hardware frame pool initialization"
[00:09:07 CET] <jamrial> plus the cuvid port to it by wm4 adapted to work with nvdec
[00:09:24 CET] <BtbN> github is bad at displaying merges
[00:09:47 CET] <jamrial> no, it's actually great. It shows the exact changes instead of a three way mess
[00:09:59 CET] <jamrial> like gitweb does
[00:10:06 CET] <nevcairiel> gitweb has a button to show that too
[00:10:12 CET] <nevcairiel> its usually the "1"
[00:10:34 CET] <BtbN> Well, it only shows me a list of a huge bunch of merges, and I have no idea which ones are interesting without clicking on every single one
[00:10:41 CET] <jamrial> oh, that
[00:10:45 CET] <jamrial> last two commits
[00:10:47 CET] <nevcairiel> the very top one
[00:10:48 CET] <nevcairiel> :)
[00:11:14 CET] <jamrial> "Merge commit 'b46a77f19ddc4b2b5fa3187835ceb602a5244e24'" and "nvdec: add frames_params support"
[00:13:10 CET] <BtbN> Yeah, with only 1~2 commits it's not too bad
[00:13:35 CET] <nevcairiel> but thats just a typical git history problem, i dont know if anything shows such things differently
[00:14:06 CET] <BtbN> "Set the width/height fields to the coded frame size" hm, at least for cuvid, that is not correct
[00:14:23 CET] <BtbN> it wants the actual frame size, without codec-specific cropping
[00:14:36 CET] <BtbN> They got that wrong in their cuvid.c as well
[00:14:55 CET] <jamrial> oh, the patch you sent earlier today?
[00:15:00 CET] <BtbN> yeah
[00:15:36 CET] <BtbN> like, the hw_frames_ctx for cuvid expects 1920x1080, and not 1088
[00:15:49 CET] <nevcairiel> cuvid is rather peculiar in that, all others are different
[00:15:51 CET] <jamrial> it can be applied after this or before (in which case i'll have to adapt the last commit)
[00:16:16 CET] <BtbN> well, as that function sets it, the user doesn't need to care
[00:18:03 CET] <BtbN> That merge should definitely be applied first
[00:18:54 CET] <jamrial> you can adapt the vp9 nvdec hwaccel for this thing as well afterwards
[00:19:01 CET] <BtbN> yeah
[00:27:20 CET] <BtbN> hm, do I bother making vp8 hwaccel-aware for nvdec
[00:28:24 CET] <BtbN> jamrial, your merge branchs builds and works fine for me
[00:28:57 CET] <c3r1c3-Win> eh, why not? It's supported and wouldn't hurt for all those old mixer streamers. ;-)
[00:29:15 CET] <BtbN> Because vp8 does not have hwaccel hooks
[00:29:29 CET] <BtbN> And decodes lightning fast in software anyway
[00:29:44 CET] <nevcairiel> yeah i was pondering on doing that some time ago, but i was just like, is it worth all that effort
[00:29:48 CET] <nevcairiel> the answer was mostly no
[00:31:08 CET] <jamrial> BtbN: ok, going to push, thanks
[00:31:47 CET] <BtbN> I'm not sure if there's anyone to really review my other changes, so I'm tempted to adapt and push them right after
[00:34:17 CET] <cone-192> ffmpeg 03wm4 07master:b46a77f19ddc: lavc: external hardware frame pool initialization
[00:34:18 CET] <cone-192> ffmpeg 03James Almer 07master:48e4eda11d53: Merge commit 'b46a77f19ddc4b2b5fa3187835ceb602a5244e24'
[00:34:19 CET] <cone-192> ffmpeg 03wm4 07master:7546964f9616: nvdec: add frames_params support
[00:41:12 CET] <atomnuker> michaelni: the mb_types API seems quite inflexible for modern codecs
[00:41:55 CET] <michaelni> atomnuker, what is missing ?
[00:46:46 CET] <atomnuker> michaelni: I'd prefer for it to output the same information that av1's analyzer takes in (which is I think an xml file)
[00:47:29 CET] <atomnuker> since if the api did export that then we'd have a directly usable analyzer
[00:48:22 CET] <JEEB> &21
[00:48:24 CET] <atomnuker> the av1 structure is basically already a superset of the api you propose
[00:48:50 CET] <nevcairiel> as long as you're not proposing to actually put xml into an internal struct
[00:49:04 CET] <nevcairiel> because i'll send someone to kill you before that'll happen =p
[00:50:27 CET] <atomnuker> lol no, some function would do the translating somewhere in lavu
[00:51:03 CET] <atomnuker> the analyzer is basically this: https://goo.gl/VqovuK
[00:53:23 CET] <atomnuker> its actually json generated by this: https://github.com/atomnuker/aom/blob/master/examples/inspect.c
[01:18:50 CET] <BtbN> "news" https://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-NVDEC-H264-Acceleration
[01:20:38 CET] <michaelni> atomnuker, IIUC thats quite a bit more detailed and a bunch of additional stuff. I was thinking of some of this before (like bit sizes) i ommited that because i didnt see a efficient way on how to extract it in a normal decoder. But thats surely no reason not to support in the API. The other stuff like transforms and modes should be addedof course. Do you want to update the patch? i think you know what is missing for AV1 
[01:20:38 CET] <michaelni> already
[01:22:01 CET] <BtbN> jamrial, hm, on Windows, nvdec now fails with "Error 1". No idea if I broke that or the merge. Will investigate. Pre-Merge commit still works
[01:22:11 CET] <BtbN> Linux still works fine with both
[01:22:12 CET] <BtbN> weird
[01:22:46 CET] <atomnuker> michaelni: ok, in that case all I'd like is an extendable api, so no hardcoded mb types as well as signed qindex rather than unsigned
[01:23:06 CET] <atomnuker> also maybe actual mv per block rather than just a direction
[01:23:37 CET] <atomnuker> maybe even 3 vectors, one for motion, one for luma and one for chroma
[01:24:39 CET] <atomnuker> though for general debugging and inspection just having flexible block types would be enough
[01:25:03 CET] <atomnuker> (as well as signed qindex params, I don't like -128 for lossless, 0 makes the most sense)
[01:26:13 CET] <atomnuker> better make it an uint16_t and fit all special values (e.g. not applicable) at UINT16_MAX so the entire range of 0-255 is usable
[01:26:55 CET] <michaelni> qp is signed already, i was thinking about MV per block too but that would duplicate the existing MV api (libavutil/motion_vector.h) but maybe we could deprecate it ?
[01:28:50 CET] <michaelni> i avoided using qp = 0 as a special value because codecs could very conceivable use 0 for something else
[01:29:15 CET] <michaelni> about 3 MVs, in the most general sense, this might be not enough
[01:29:35 CET] <michaelni> y+cb+cr+alpha coded as planes could have 4 seperate MVs
[01:31:26 CET] <michaelni> we can do 1 MV / 2 MV for bidir and have 4 flags so that a block as a whole can apply to a subset of planes
[01:31:57 CET] <durandal_1707> will we ever use this?
[01:32:40 CET] <atomnuker> if there's a filter to render those
[01:32:46 CET] <durandal_1707> will someone implement this for major decoders so we have full analyzer in lavfi?
[01:33:48 CET] <michaelni> svq1 is coded in 3 seperate planes IIRC so it has different block sizes and MVs for the planes
[01:40:22 CET] <iive> h264 does use qp==0, doesn't it?
[01:40:31 CET] <atomnuker> yeah, I guess in that case make the block structure plane-generic, each with its own size, transform type (as a string), an array of prediction types and a vector
[01:41:13 CET] <kierank> TD-Linux: damn you beating me in the demuxed viewer count!!!
[01:41:29 CET] <durandal_1707> haha
[01:49:45 CET] <iive> btw, iirc mpeg2 has mbtype where you have 4 vectors, it combines from 4 fields (aka interlaced b-frame)
[02:25:47 CET] <cone-192> ffmpeg 03James Almer 07master:91df92e44284: avcodec/Makefile: build libxvid_rc.o only if libxvid_encoder is enabled
[02:31:00 CET] <michaelni> send a more generic mb type API, thats field & plane generic, allows string descriptions, multiple predict, transform, filter, vectors, ...
[02:34:27 CET] <atomnuker> michaelni: yeah, this one's alright
[02:34:36 CET] <atomnuker> how do you plan to expose this? side data?
[02:35:01 CET] <michaelni> yes, same as the motion vector stuff was
[02:35:12 CET] <michaelni> new side data type of course
[02:35:30 CET] <atomnuker> is there any way to get the codec_id?
[02:35:43 CET] <atomnuker> since you'd get this alongside an uncompressed frame
[02:36:00 CET] <michaelni> from a filter, iam not sure
[02:36:44 CET] <atomnuker> maybe make the structure <codec_id> <num_blocks> <blocks> inside the side data's buf field?
[02:36:58 CET] <atomnuker> since you'll need the codec_id to make sense of the extra flags per block
[02:37:14 CET] <michaelni> yes thats agood idea
[02:42:50 CET] <kierank> michaelni: how can we upload slice threads samples to the google fuzz suite
[03:03:21 CET] <michaelni> the code should use the fate samples, iam not sure it actually does though i see outcommented code in https://github.com/google/oss-fuzz/blob/master/projects/ffmpeg/build.sh but if it doesnt use the samples that should be fixed by someone. and so adding it to fate samples should do the trick either way
[03:06:43 CET] <kierank> not sure any of the fate samples are sliced threads
[03:11:45 CET] <michaelni> if fate doesnt test something then fate should be extended quite independantly of any fuzzing
[03:15:17 CET] <kierank> not sure if any of the h264 samples in fate are necessarily sliced threads capable
[03:25:38 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:c6496de33456: configure: Move enabling libc_type into probe_libc() function
[03:25:39 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:62be1caf161c: configure: Bail out early if neither static nor shared libs are built
[03:25:40 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:cbcdb2d8e47f: build: Delete compiler-generated compat files on 'make clean'
[03:25:41 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:68649bfed30a: configure: Group system feature variables and system libraries together
[03:25:42 CET] <cone-192> ffmpeg 03James Almer 07master:3e9fd83592cf: Merge commit 'c6496de33456f20144b994ac38f308f2de333608'
[03:25:43 CET] <cone-192> ffmpeg 03James Almer 07master:d168ff70ea41: Merge commit '62be1caf161c1241a9e148f347850cfe092588dc'
[03:25:44 CET] <cone-192> ffmpeg 03James Almer 07master:e29e7b630504: Merge commit 'cbcdb2d8e47f62f69accee62c08f487a27848174'
[03:25:45 CET] <cone-192> ffmpeg 03James Almer 07master:3749d0defc38: Merge commit '68649bfed30a35dc3e45ea240541b2774b2f282b'
[03:31:42 CET] <cone-192> ffmpeg 03wm4 07master:e724bdfffbd3: lavc: fix hw_device_ctx operation
[03:31:43 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:17f5171cd475: arm: Check for have_vfp_vm instead of !have_vfpv3 for float_dsp_vfp
[03:31:44 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:b487add7ecf7: arm: Remove a redundant check in fmtconvert_init_arm.c
[03:31:45 CET] <cone-192> ffmpeg 03James Almer 07master:507e3f7d26ce: Merge commit '17f5171cd4753e7f50e6d95df069bccbc90265bf'
[03:31:46 CET] <cone-192> ffmpeg 03James Almer 07master:68e479e3ada8: Merge commit 'b487add7ecf78efda36d49815f8f8757bd24d4cb'
[03:36:25 CET] <cone-192> ffmpeg 03Mark Thompson 07master:94ab0bef408c: vaapi: Disable deprecation warnings around use of struct vaapi_context
[03:36:26 CET] <cone-192> ffmpeg 03Mark Thompson 07master:a126b67e1b01: configure: Add config option for libva2 (VAAPI 1)
[03:36:27 CET] <cone-192> ffmpeg 03Mark Thompson 07master:f0a978a51916: vaapi: Remove H.264 baseline profile
[03:36:28 CET] <cone-192> ffmpeg 03Mark Thompson 07master:bfc83acfd6b3: vaapi: Always free parameter buffers after vaEndPicture() with libva2
[03:36:29 CET] <cone-192> ffmpeg 03Mark Thompson 07master:2708c8e8efef: hwcontext_vaapi: Set message callbacks on internally-created devices
[03:36:30 CET] <cone-192> ffmpeg 03James Almer 07master:4a54ef7a0f4c: Merge commit '2708c8e8efefaad337ccab1e3bf59dcde66c6bc5'
[03:50:13 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:0af8a7217410: build: Drop support for legacy TI ARM compiler
[03:50:14 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:9dc79b2943d9: configure: Drop support for legacy PGI compiler
[03:50:15 CET] <cone-192> ffmpeg 03Luca Barbato 07master:0e702124ee14: doc: Provide better examples for hls and segment muxing
[03:50:16 CET] <cone-192> ffmpeg 03James Almer 07master:12f4e2ba023e: Merge commit '0af8a72174108b9bb482f1073a1e9a3bc258af51'
[03:50:17 CET] <cone-192> ffmpeg 03James Almer 07master:82fc222f676f: Merge commit '9dc79b2943d99f256a3279f09580b27a95fb9aa8'
[03:50:18 CET] <cone-192> ffmpeg 03James Almer 07master:27aa69896bd6: Merge commit '0e702124ee149593168cbbb7b30376249a64ae66'
[04:18:50 CET] <cone-192> ffmpeg 03Anton Schubert 07master:4723c6226aa1: dashenc: fix bitrate estimation with correct scaling
[04:18:51 CET] <cone-192> ffmpeg 03Peter Große 07master:91760a934055: dashenc: copy stream frame rate to output stream
[04:18:52 CET] <cone-192> ffmpeg 03James Almer 07master:362372c46be6: Merge commit '4723c6226aa1ece4099338cc9b38a9cef4fa4846'
[04:18:53 CET] <cone-192> ffmpeg 03James Almer 07master:34cfb73b9928: Merge commit '91760a934055ab06812885ab5ec1a97a8db6d217'
[04:22:38 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:67c72f08a470: configure: Stop using dlltool to create an import library
[04:22:39 CET] <cone-192> ffmpeg 03James Almer 07master:5b5365fe9d63: Merge commit '67c72f08a4707c18a67a4734660e3a23cc9488b6'
[04:22:46 CET] <jamrial> nevcairiel: ^
[04:29:57 CET] <cone-192> ffmpeg 03Carl Eugen Hoyos 07master:b998a56b0ac9: lavc/jpeg2000dec: Fix used variables reading palette.
[04:38:40 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:61a17423d371: configure: Miscellaneous small changes to helper functions
[04:38:41 CET] <cone-192> ffmpeg 03James Almer 07master:e0f84c303db7: Merge commit '61a17423d3711cb34a18b44e1ec2510c2f70a56c'
[04:41:10 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:14bba662d489: configure: Remove unused apply() helper function
[04:41:11 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:192fe52e42f6: configure: Miscellaneous minor changes to config file handling
[04:41:12 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:9b0aff51a7ae: configure: Simplify MIPS instruction set handling
[04:41:13 CET] <cone-192> ffmpeg 03James Almer 07master:4aefe010e308: Merge commit '14bba662d489a58fe88240fc4d14238bf17ca203'
[04:41:14 CET] <cone-192> ffmpeg 03James Almer 07master:e55781954fdc: Merge commit '192fe52e42f64a493c47cad1461b20fe1149dbea'
[04:41:15 CET] <cone-192> ffmpeg 03James Almer 07master:5e4923b411b9: Merge commit '9b0aff51a7ae03215c4e1a3e7220fdbcfb858b08'
[04:44:11 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:2cf3c0ab0d84: Revert "configure: Detect AIX ar command instead of hardcoding it in the OS section"
[04:44:12 CET] <cone-192> ffmpeg 03James Almer 07master:221d813599e4: Merge commit '2cf3c0ab0d84b5cdb379059f8570809a13a306b9'
[04:45:06 CET] <cone-192> ffmpeg 03Martin Storsjö 07master:1746c7c8f2f9: libspeexenc: Use speex_lib_get_mode instead of the speex_foo_mode data symbols
[04:45:07 CET] <cone-192> ffmpeg 03James Almer 07master:a629bc99fd11: Merge commit '1746c7c8f2f9a6c5eacb486426dd0a579b4b7498'
[04:48:25 CET] <cone-192> ffmpeg 03James Almer 07master:55fe72a841ba: matroskadec: don't warn about unknown spherical medata when none is present
[04:48:26 CET] <cone-192> ffmpeg 03James Almer 07master:f5c67c431ef9: Merge commit '55fe72a841ba306370e68e86c88f34b4456aa4dd'
[04:52:02 CET] <cone-192> ffmpeg 03Peter Große 07master:22241208eb7d: avconv.c: fix calculation of input file duration in seek_to_start()
[04:52:03 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:8e0febe28eff: configure: Use right variable and right value for AIX ar flags
[04:52:04 CET] <cone-192> ffmpeg 03James Almer 07master:ab77c4007b2f: Merge commit '22241208eb7d0168b2afc128af5a128a9ef0a89b'
[04:52:05 CET] <cone-192> ffmpeg 03James Almer 07master:792802f5f91a: Merge commit '8e0febe28effe7f427e45190eab37110126161ea'
[04:55:31 CET] <cone-192> ffmpeg 03Sean McGovern 07master:fbca6e7d162b: matroskadec: allow RealAudio/Cook/Sipro streams of flavor 0
[04:55:32 CET] <cone-192> ffmpeg 03James Almer 07master:6bf041a2333a: Merge commit 'fbca6e7d162b9a7105d1059826dfe96616fa803a'
[05:04:23 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:fbf77b5ac37b: build: Add uninstall-pkgconfig target to match install-lib*-pkgconfig
[05:04:24 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:7ebe7e8e7a76: build: Remove pkg-config files on clean instead of on distclean
[05:04:25 CET] <cone-192> ffmpeg 03Diego Biurrun 07master:17b6c7efb471: build: Add missing config.sh dependency for pkg-config files
[05:04:26 CET] <cone-192> ffmpeg 03James Almer 07master:64581372005d: Merge commit 'fbf77b5ac37bf2a807d8336450801d7aecf2e359'
[05:04:27 CET] <cone-192> ffmpeg 03James Almer 07master:e0087a562411: Merge commit '7ebe7e8e7a76c0ce302f4f583ef0d14220031214'
[05:04:28 CET] <cone-192> ffmpeg 03James Almer 07master:ccf7bca1c9bb: Merge commit '17b6c7efb471e8ff1b8a7271f6531ba1d52bf69c'
[05:14:09 CET] <cone-192> ffmpeg 03Michael Niedermayer 07master:cd4663dc8032: smacker: add sanity check for length in smacker_decode_tree()
[05:14:10 CET] <cone-192> ffmpeg 03Andreas Cadhalpun 07master:0ccddbad200c: smacker: limit recursion depth of smacker_decode_bigtree
[05:14:11 CET] <cone-192> ffmpeg 03James Almer 07master:b3e5899e475d: Merge commit 'cd4663dc80323ba64989d0c103d51ad3ee0e9c2f'
[05:14:12 CET] <cone-192> ffmpeg 03James Almer 07master:d2ad6f11920e: Merge commit '0ccddbad200c1d9439c5a836501917d515cddf76'
[05:17:06 CET] <cone-192> ffmpeg 03James Almer 07master:5c22c90c1d50: vp9_superframe_bsf: cache packets by creating new references instead of moving pointers
[05:17:07 CET] <cone-192> ffmpeg 03James Almer 07master:6c0509ae860f: Merge commit '5c22c90c1d5050f1206e46494b193320ac2397cb'
[05:17:22 CET] <jamrial> and that's it
[10:16:51 CET] <durandal_1707> is hw stuff tested ?
[11:42:33 CET] <nevcairiel> not in fate, if you mean that
[12:04:16 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:2afeb3f8ab00: avfilter/vf_maskedclamp: ignore SAR from all inputs
[12:04:17 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:19d2108a984f: avfilter/vf_hysteresis: ignore SAR from all inputs
[12:04:18 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:79aa9d8aeee0: avfilter/vf_blend: ignore SAR from all inputs
[12:04:19 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:a28e70beab05: avfilter/vf_lut2: ignore SAR from all inputs
[12:04:20 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:789731affa81: avfilter/vf_maskedmerge: ignore SAR from all inputs
[12:04:21 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:5f1bb258aba5: avfilter/vf_hysteresis: allow using framesync options
[12:20:41 CET] <BtbN> I need more screens
[12:20:44 CET] <BtbN> 2 is just not enough
[12:23:38 CET] <nevcairiel> I have 3, happy with that
[12:23:49 CET] <BtbN> I don't have space for 3 though
[12:23:53 CET] <BtbN> otherwise I'd long have 3
[12:46:51 CET] <BtbN> nevcairiel, are hwaccels really supposed to output frames with 1920x1088?
[12:46:58 CET] <BtbN> Where does the extra garbage get chopped off?
[12:47:11 CET] <BtbN> The frame carries no information about those 8 pixels being dead
[12:53:08 CET] <nevcairiel> The height field should be setup appropriately in the avframe
[12:53:45 CET] <nevcairiel> For more complex cropping there is also crop fields in avframe
[12:55:15 CET] <nevcairiel> The actual size of the hardware buffers should be inconsequential, the sw decoder also has 1088 height
[12:57:56 CET] <BtbN> Cause right now, I'm getting frames that have their width/height set to 1920x1088, and it makes things explode, as the internal buffer from cuvid is only 1080. And I have no idea where that frame comes from, as the hw_frames_ctx is properly set up to have 1080
[13:01:08 CET] <nevcairiel> If coded_height is set to 1088 then one can usually assume that this is also the buffers size
[13:01:26 CET] <nevcairiel> Heck usually the hardware doesn't care about the cropping rectangle
[13:01:56 CET] <nevcairiel> Since that is only for interpretation, not decoding
[13:02:24 CET] <BtbN> Yeah, coded_height is fine at 1088
[13:02:30 CET] <BtbN> But the frames hight is also 1088
[13:04:07 CET] <BtbN> This did not break before the recent merges, but nothing in there looks like it could cause this
[13:11:14 CET] <BtbN> https://bpaste.net/show/a8620456d601 what the hell is this. Something randomly using that memory?
[13:45:33 CET] <BtbN> nevcairiel, found the commit at fault: d14179e3d49eb0f2533db16151e01abb0018b165
[13:45:48 CET] <BtbN> This just seems wrong, or at least dangerous, to me
[13:46:20 CET] <BtbN> The cuvid/nvdec hw_frames_pool gives out frames _smaller_ than the coded width/height. So this is bound to cause failures
[13:47:55 CET] <BtbN> I'd enhance it with a check to not increase the frame size
[13:54:19 CET] <BtbN> That whole commit seems strange to me. The aligned size should be in linesize, not in width/height
[14:00:37 CET] <BtbN> But anyway, not returning the full size frame is wrong, as all the parsers properly set the cropping info
[14:33:20 CET] <BtbN> Well, now I know why with that patch-set applied, it fails on Windows
[14:33:28 CET] <BtbN> It's because my CPU has 16 Threads
[14:33:36 CET] <BtbN> which somehow causes it to add 32 buffer frames
[14:33:46 CET] <BtbN> Which there is simply not enough VRAM available for
[14:41:10 CET] <durandal_1707> what instructions to use for thresholding 8bit unsigned pixels?
[15:13:20 CET] <BtbN> Why is there even frame threading for a hwaccel?
[15:13:30 CET] <BtbN> I'm pretty sure cuvid would explode if it actually was used in parallel
[15:21:44 CET] <cone-547> ffmpeg 03Steven Liu 07master:56960ed9c3a6: Revert "lavf/dashdec: Fix several memleaks."
[15:21:45 CET] <cone-547> ffmpeg 03Carl Eugen Hoyos 07master:52b9575d4a90: lavf/dashdec: Fix several memleaks.
[15:27:41 CET] <atomnuker> durandal_1707: compare ones?
[15:28:02 CET] <jamrial> what the hell was that revert and reply the exact same commit just now?
[15:32:54 CET] <durandal_1707> did carl just started revert war?
[15:33:21 CET] <BtbN> "committer	Steven Liu <lq at chinaffmpeg.org>"
[15:33:37 CET] <BtbN> I don't think carl was involved there at all, other than authoring the commit?
[15:34:11 CET] <BtbN> Which doesn't make it any less weird
[15:34:47 CET] <BtbN> jamrial, I found out why nvdec fails on Windows now
[15:35:09 CET] <jamrial> i read the logs. some old commit at fault?
[15:35:13 CET] <BtbN> The new logic from the merge adds one buffer frame per frame threads
[15:35:31 CET] <BtbN> And the nvdec code itself already does the same, and it was not removed in the process
[15:35:36 CET] <BtbN> So now it adds two buffer frames per thread
[15:35:45 CET] <BtbN> Which, with my 16 thread CPU, is 32 extra frames
[15:35:48 CET] <BtbN> That's just too much
[15:36:22 CET] <BtbN> First step is to just remove the redundant thread addition from nvdec
[15:36:44 CET] <BtbN> And then maybe think about if it needs a hard upper limit. Trying to figure out if cuvid has one
[15:36:57 CET] <BtbN> 32 1080p frames shouldn't be enough to fill all my VRAM
[15:39:37 CET] <jkqxz> Does the same case work with another hwaccel API (dxva2/d3d11va/vdpau)?  They should all allocate the same number of frames, I think.
[15:40:54 CET] <BtbN> No idea, I got non of them in a working state
[15:41:09 CET] <BtbN> vdpau might work, but it needs X. Don't have that on the test box
[15:43:01 CET] <BtbN> The other hwaccels are also kind of different
[15:43:21 CET] <BtbN> For cuvid, it uses internal buffer frames, but the generic code also pre-allocates the buffer pool with output frames with the same number
[15:43:27 CET] <BtbN> Which I don't think is needed for it
[15:53:03 CET] <cone-547> ffmpeg 03Timo Rothenpieler 07master:65c4f4d1069b: MAINTAINERS: update for cuvid/nvdec changes
[15:53:04 CET] <cone-547> ffmpeg 03Timo Rothenpieler 07master:3e0e1634585b: avcodec/nvdec: don't add thread buffer twice
[15:53:05 CET] <cone-547> ffmpeg 03Timo Rothenpieler 07master:c60bc02bf4bc: avcodec/nvdec: check hardware capabilities
[15:53:06 CET] <cone-547> ffmpeg 03Timo Rothenpieler 07master:3f6294a53d58: avcodec/nvdec: add support for 12 bit formats
[16:25:20 CET] <jamrial> jkqxz: are my patches for cbs (the bsfs, rather) ok?
[16:28:28 CET] <jkqxz> Where am I looking?
[16:29:31 CET] <jkqxz> AVClass versions?
[16:30:16 CET] <jkqxz> I don't even know what that is used for...
[16:34:05 CET] <jamrial> neither do i, but every other module uses the full lavu version :p
[16:36:04 CET] <jkqxz> Sounds good to me, then.
[16:38:59 CET] <cone-547> ffmpeg 03Mark Thompson 07master:1ef4af2d492e: hwcontext_vaapi: Fix build with libva 2.0
[16:50:27 CET] <jamrial> jkqxz: ok, thanks
[16:50:28 CET] <cone-547> ffmpeg 03James Almer 07master:9a6e4c88d641: avcodec/h264_metadata_bsf: fix the AVClass version number
[16:50:29 CET] <cone-547> ffmpeg 03James Almer 07master:9549f22bf88d: avcodec/h265_metadata_bsf: fix the AVClass version number
[16:50:30 CET] <cone-547> ffmpeg 03James Almer 07master:a7e7abf8495f: avcodec/mpeg2_metadata_bsf: fix the AVClass version number
[18:03:47 CET] <BtbN> I suppose a hwaccel cannot say "Don't use me with more than X threads"?
[18:04:04 CET] <BtbN> And I also still don't understand how threading with a hwaccel does not explode
[18:05:22 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:7a060867f3d7: avfilter/vf_tile: add overlap option
[18:32:56 CET] <ubitux> jamrial: damn man, good job with the merges
[18:38:12 CET] <rcombs> BtbN: it used to
[18:38:22 CET] <rcombs> no idea what changed to fix that
[18:54:58 CET] <BtbN> rcombs, it does not appear to be actually multi-threaded
[18:55:27 CET] <BtbN> But a side effect of it is that you can control the frame-delay-buffering with it, which makes cuvid go fast
[18:55:53 CET] <BtbN> But for some reason, nvdec via native ffmpeg hwaccels is still notably slower than pure cuvid
[19:01:16 CET] <jamrial> ubitux: thanks :D
[19:01:28 CET] <ubitux> thanks to you...
[19:01:54 CET] <jamrial> outside of a couple commits that required some work, most applied relatively cleanly or were noops
[19:03:36 CET] <atomnuker> jamrial: gcc git master from 3 days ago is miscompiling ffmpeg again
[19:03:46 CET] <atomnuker> libavcodec/motionpixels.c:66:20: internal compiler error: in max, at profile-count.h:889
[19:09:27 CET] <jamrial> ok, i'll try to reproduce and open a ticket
[19:21:28 CET] <nevcairiel> BtbN: there is some magic to serialize hwacxels
[19:21:55 CET] <BtbN> Yeah, I ran into it and its tripple indirection when trying to debug something
[19:21:59 CET] <nevcairiel> But still uses multiple threads, they just don't run in parallel, so still needs the buffer
[19:22:16 CET] <BtbN> For nvdec, the buffer doubles the vram usage
[19:22:37 CET] <BtbN> But it makes it fast at the same time, because it achives the frame download delay it needs that way
[19:22:47 CET] <nevcairiel> Can always run with -threads 1 on the cli
[19:22:55 CET] <BtbN> If you set -threads 1 nvdec goes slow
[19:23:08 CET] <nevcairiel> But yeah it helps for that, which is silly
[19:23:21 CET] <nevcairiel> In the past it let people to believe threading actually helps
[19:23:32 CET] <nevcairiel> But it was just the delay
[19:24:20 CET] <JEEB> ayup
[19:27:12 CET] <nevcairiel> It was hard to convince people when all they had to say was "using threads makes it faster"
[19:49:40 CET] <cone-547> ffmpeg 03wm4 07master:c31ce95f1c4c: videotoolbox: add frame_params support
[19:51:08 CET] <jamrial> atomnuker: can't reproduce with current trunk :/
[19:51:33 CET] <jamrial> what configure options did you use for ffmpeg and for gcc?
[20:02:11 CET] <atomnuker> jamrial: https://0x0.st/simQ.txt
[20:29:52 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:6665938ca8b7: avformat/ty: check if header is correctly parsed and is still present
[20:39:53 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:a38b14a432b3: avformat/ty: fix memory leaks
[21:12:00 CET] <BtbN> coverity really hates those huge inline struct initializations
[21:12:18 CET] <BtbN> Something in there seems to be dead code. Or coverity is just plain broken
[21:12:32 CET] <BtbN> CID 1421005 if anyone feels like staring at it as well
[21:23:50 CET] <atomnuker> how much 64-bit only .asm files do we have?
[21:24:16 CET] <atomnuker> it might be worth making configure somehow exclude them if there's many
[21:25:11 CET] <jamrial> atomnuker: movd is not for gprs
[21:25:48 CET] <jamrial> he should use movsxd, or keep the mov as is and change cglobal to not load them as well
[21:26:28 CET] <atomnuker> ah, right
[21:27:12 CET] <jamrial> also, the whole thing can be made to work on x86_32 easily
[21:27:44 CET] <jamrial> it's a billion linesize values that have no reason to be in a gpr if there are none available
[21:43:21 CET] <atomnuker> jamrial: isn't REP_RET needed because of some amd CPUs?
[21:43:37 CET] <jamrial> not anymore
[21:43:42 CET] <atomnuker> why not?
[21:43:46 CET] <jamrial> also, it was needed for < ssse3 functions
[21:43:50 CET] <jamrial> this is sse4
[21:44:07 CET] <jamrial> because RET now automatically adds rep ret if needed
[21:44:30 CET] <iive> it should be used only right after branch destination, iirc
[21:45:22 CET] <atomnuker> jamrial: cool, would you mind me sending a huge patch to remove all REP_RET usage then?
[21:46:00 CET] <jamrial> no, go ahead
[21:46:05 CET] <iive> i don't think that x86asm has been changed recently
[21:46:09 CET] <iive> have i missed it?
[21:46:21 CET] <jamrial> no
[21:46:22 CET] <nevcairiel> its not a recent change, its been a long time already
[21:47:02 CET] <iive> my point is, that handling already existed, when REP_RET has been spreded all over
[21:48:29 CET] <jamrial> old habit die hard, i guess :p
[22:00:09 CET] <atomnuker> patch sent, this was fun
[22:09:59 CET] <jamrial> atomnuker: does assembly change in any of the files?
[22:10:24 CET] <jamrial> x86inc says "We can automatically detect 'follows a branch', but not a branch target."
[22:16:46 CET] <cone-547> ffmpeg 03Marton Balint 07release/3.4:0ca0ec26a62e: ffmpeg: always init output stream before reaping filters
[22:16:46 CET] <cone-547> ffmpeg 03Marton Balint 07release/3.4:0158fd527691: ffplay: create the window and the renderer before starting playback
[22:16:48 CET] <cone-547> ffmpeg 03Marton Balint 07release/3.4:46aa73464627: ffplay: only use hardware accelerated SDL texture formats
[22:16:49 CET] <cone-547> ffmpeg 03Marton Balint 07release/3.4:88a6fca74d24: ffplay: use SDL2 audio API
[22:17:25 CET] <atomnuker> jamrial: seems like a few did
[22:17:57 CET] <atomnuker> so do we keep the requirement for REP_RET after a branch or do we change all files which don't change with REP_RET -> REP only?
[22:18:53 CET] <atomnuker> (a few == h264_idct, h264_qpel, huffyuv, sbr, me_cmp)
[22:18:54 CET] <nevcairiel> you should probably just not care =p
[22:19:07 CET] <jamrial> you'd have to check x86_32, where there are many more chances that the function will have an "epilogue"
[22:19:38 CET] <atomnuker> there you go then, we should continue to use REP_RET after a branch
[22:20:29 CET] <jamrial> if you want to keep things as is, then that's fine
[22:21:00 CET] <jamrial> but as i said, it's not needed for this new function, since it's sse4
[22:23:46 CET] <atomnuker> nah, better keep things as they are
[22:58:51 CET] <cone-547> ffmpeg 03Paul B Mahol 07master:f38d0d0c22c1: avformat/ty: check cur_chunk_pos before using it
[23:39:04 CET] <cone-547> ffmpeg 03Aman Gupta 07master:fd18d310ec20: lavf/tls_securetransport: build on iOS
[00:00:00 CET] --- Mon Nov 13 2017