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

[burek]

[00:38:58 CET] <cone-680> ffmpeg 03Mark Thompson 07master:d0897da92450: vaapi_h264: Constify pointers
[00:38:58 CET] <cone-680> ffmpeg 03Mark Thompson 07master:6bc2808c41a3: vaapi_mpeg2: Constify pointers
[00:38:58 CET] <cone-680> ffmpeg 03Mark Thompson 07master:845c2c140b5e: vaapi_vc1: Constify pointers
[00:38:58 CET] <cone-680> ffmpeg 03Mark Thompson 07master:d07d01bcce4d: vaapi_vc1: Remove redundant version check
[00:38:58 CET] <cone-680> ffmpeg 03Mark Thompson 07master:79307ae56374: lavc: Rewrite VAAPI decode infrastructure
[00:38:59 CET] <cone-680> ffmpeg 03Mark Thompson 07master:c8b26d5954fc: vaapi_h264: Convert to use the new VAAPI hwaccel code
[00:38:59 CET] <cone-680> ffmpeg 03Mark Thompson 07master:71acbea112e5: vaapi_mpeg2: Convert to use the new VAAPI hwaccel code
[00:39:00 CET] <cone-680> ffmpeg 03Mark Thompson 07master:32b3812b60e9: vaapi_vc1: Convert to use the new VAAPI hwaccel code
[00:39:01 CET] <cone-680> ffmpeg 03Mark Thompson 07master:fd1a6a01065a: vaapi_mpeg4: Convert to use the new VAAPI hwaccel code
[00:39:02 CET] <cone-680> ffmpeg 03Anton Khirnov 07master:adb54e59c18d: vaapi_hevc: Convert to use the new VAAPI hwaccel code
[00:39:03 CET] <cone-680> ffmpeg 03Mark Thompson 07master:defbb8bc26c7: vaapi_vp9: Convert to use the new VAAPI hwaccel code
[00:39:04 CET] <cone-680> ffmpeg 03Mark Thompson 07master:542a65d0b33a: ffmpeg_vaapi: Convert to use hw_frames_ctx only
[00:39:05 CET] <cone-680> ffmpeg 03Mark Thompson 07master:2a4a8653b6ca: lavc: Remove old vaapi decode infrastructure
[00:39:06 CET] <cone-680> ffmpeg 03Mark Thompson 07master:f7e9275f83ec: hwcontext_vdpau: Fix missing subscripts
[14:58:07 CET] <durandal_1707> michaelni: i need decoder to always receive 2048 bytes at input except last frame
[14:58:33 CET] <durandal_1707> how to acomplish that?
[15:01:38 CET] <atomnuker> durandal_1707: are the packets not 2048 bytes big?
[15:02:06 CET] <wm4> parser?
[15:02:22 CET] <wm4> or bsf
[15:02:42 CET] <durandal_1707> atomnuker: they are, but decoder doesnt consume all packet
[15:03:01 CET] <durandal_1707> so at end one get overreads
[15:03:46 CET] <atomnuker> durandal_1707: check and prevent overreads then?
[15:04:15 CET] <durandal_1707> by using another buffer?
[15:04:43 CET] <atomnuker> I mean while reading
[15:10:52 CET] <durandal_1707> this is wmapro decoder, trying to add multichannel support for xma
[18:09:10 CET] <cone-302> ffmpeg 03Clément BSsch 07master:c3050fcbdcb2: lavc/h264dec: remove flush goto in decode callback
[18:55:39 CET] <philipl> jkqxz: Do you have access to coverity? warnings in the new vaapi code
[19:23:06 CET] <jkqxz> philipl:  I do not.  How do I look at that?
[19:27:08 CET] <BtbN> it's non-public, you need an invite
[19:33:16 CET] <philipl> what's your github email? I'll send the invite
[19:48:56 CET] <atomnuker> bofh_: ping
[22:26:27 CET] <infinito> i cant select gpu in nvenc using a tesla m60 Nvidia card. Allways choose the same gpu, not matter if i use -gpu 0 or -gpu 1, some ideas about that?
[22:48:18 CET] <BtbN> infinito, -> #ffmpeg and the full commandline and output please.
[22:54:54 CET] <infinito> @BtbN they dont have idea whats append, i think is a bug
[22:55:20 CET] <infinito> n60 gpus have 2xgpu, using internal switching pcie
[22:55:57 CET] <BtbN> I'm aware, but this channel is about development of ffmpeg and the libav* libraries, not for user support.
[22:56:24 CET] <BtbN> And without the commandline and its output I won't be able to tell you what's going on.
[22:56:30 CET] <BtbN> So please provide that, in #ffmpeg
[22:58:16 CET] <infinito> ok
[23:02:58 CET] <BtbN> philipl, did I miss something, or is this all it takes to make the indices reliable and avoid needlessly checking all cards? https://github.com/BtbN/FFmpeg/commit/ef94a140215b0d98ec4921f8a4eaf59e39f12d34
[23:31:03 CET] <BBB> wbs: thats some pretty amazing work there
[23:31:46 CET] <BBB> how come the A7 itxfm speedup vs. C is so much larger than for A8/9? is the C very inefficient on A7?
[23:32:52 CET] <BBB> its true for MC/lpf also
[23:32:56 CET] <BBB> very strange
[23:33:21 CET] <wbs> it's the A8 that has got a larger speedup; I think the neon unit is pretty beefy on that one but the scalar core is really slow
[23:34:17 CET] <wbs> A7/A8/A53 all also lack out-of-order execution, so they gain quite a bit from me just testing different instruction schedulings to see which ones work the best. sometimes it's a compromise though, where one version gains on one cpu but loses on another
[23:34:40 CET] <wbs> (so most of the microoptimizations that one tries give no effect at all on the A9)
[23:34:42 CET] <BBB> oh I see
[23:34:55 CET] <BBB> Im looking at it in gmail so the table is all screwed up, I mis-read it
[23:35:02 CET] <wbs> ah
[23:35:28 CET] <wbs> iirc mru used to say that one should handtune asm for the A8; when it works well there, it should be good on other cores as well
[23:35:31 CET] <BBB> I wish I could give more useful comments than cool
[23:35:41 CET] <BBB> but Im not an arm guy, so & cool :D
[23:35:52 CET] <wbs> lol, thanks :-)
[23:36:03 CET] <BBB> sorry :/
[23:39:14 CET] <wbs> anyway, these should incorporate all the hints I got on the 8 bit version in review from janne so far, so in that respect there's not much to see; just the same but adapted for 10/12bpp
[23:45:01 CET] <BBB> neon is probably structured better than x86
[23:45:16 CET] <BBB> for half of the instructions on x86, the word/byte versions are not strictly exchangeable
[23:46:13 CET] <BBB> did you do anything special in the itxfm to fit 64bit intermediates? did you use the same trick as x86? or does neon have better support for 64bit integer instructions than x86 (where they dont exist)?
[23:50:21 CET] <Gramner> x86 simd is "slightly" messy. lots of instructions arbitrarily only exist for a single data type or a subset of types. also fun stuff like pshuflw and pshufhw because who needs a pshufw instruction anyway for non-mmx registers
[00:00:00 CET] --- Thu Jan 19 2017