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

[burek]

[01:53:07 CET] <jamrial> jkqxz: consider adding something like "v2" when you re send patchsets, at least to the first email
[01:53:17 CET] <jamrial> makes it easier to recognize :p
[02:02:19 CET] <JEEB> took a while, but finally posted the d3d11va uninit patch to the ML
[02:03:26 CET] <JEEB> and now sleep :V
[03:03:01 CET] <SortaCore> gj JEEB
[03:31:30 CET] <jamrial> michaelni: 3d5822d9cf seems to have introduced some memleaks
[03:34:31 CET] <michaelni> jamrial, how can i reproduce ?
[03:34:55 CET] <jamrial> michaelni: valgrind with the jpeg2000 vsynth tests
[03:34:56 CET] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20171123211725&slot=x86_64-archlinux-gcc-valgrind-no-undef
[04:03:27 CET] <SortaCore> So if I wanted to MFXClose() on QSV session as part of a restart, how do I undo that?
[04:03:35 CET] <SortaCore> this is in response to device failed
[04:04:15 CET] <SortaCore> atm I do MFXClose(q->internal_session); then ff_qsv_init_internal_session(), and it breaks with "not initialised" in later intel calls
[04:05:27 CET] <cone-076> ffmpeg 03Michael Niedermayer 07master:7c191dfba76c: avcodec/j2kenc: Only allocate cblk.data once
[04:05:30 CET] <SortaCore> afk
[04:05:39 CET] <michaelni> jamrial, should be fixed
[12:33:00 CET] <durandal_170> doom9 folks still trolls about cineform
[12:36:51 CET] <kierank> durandal_170: just that one guy
[12:36:52 CET] <kierank> kolak
[12:38:14 CET] <durandal_170> would wrapper around sdk be acceptted here?
[12:38:41 CET] <nevcairiel> does it actually expose a usable api?
[12:38:58 CET] <kierank> for encoder, sure
[12:39:17 CET] <nevcairiel> looks like its c++, thats always fun
[12:40:39 CET] <nevcairiel> well partially c++ anyway
[13:38:31 CET] <cone-220> ffmpeg 03Paul B Mahol 07master:59365e634552: avfilter/af_ladspa: remove duplicate code lines
[14:04:03 CET] <kierank> Gramner: is there any document that explains the avx-512 blend stuff
[14:20:36 CET] <atomnuker> jdarnley: hey didn't you say you had some unfinished flac simd?
[14:20:54 CET] <jdarnley> yes I did
[14:22:18 CET] <atomnuker> thinking of finishing it?
[14:22:19 CET] <jdarnley> I don't remember what state I left it in though
[14:23:45 CET] <jdarnley> On second thoughts I might be using it
[14:24:20 CET] <jdarnley> Oh wow, I rebased it as recent as that?
[14:24:28 CET] <jdarnley> commit 498c90c708
[14:24:28 CET] <jdarnley> Date:   Thu Aug 3 01:48:06 2017 +0200
[14:25:14 CET] <jdarnley> Hm.  I hope it was working because I've encoded a lot of stuff since then.
[14:28:25 CET] <kierank> lol
[14:43:03 CET] <atomnuker> jdarnley: send it to the ml for review?
[14:43:48 CET] <jdarnley> yeah, I'll to do that this weekend
[14:43:54 CET] <jdarnley> *try to
[15:09:24 CET] <durandal_170> what it is about?
[15:23:25 CET] <jdarnley> durandal_170: what?  my assembly?
[16:05:06 CET] <durandal_170> jdarnley: yes, it is for decoding or encoding?
[16:05:18 CET] <jdarnley> encoding, yes
[16:05:42 CET] <jdarnley> it is the 32-bit version of my existing 16-bit LPC coder
[16:51:55 CET] <cone-220> ffmpeg 03Paul B Mahol 07master:ec5328aa6f3c: avfilter: add mix filter
[17:12:00 CET] <cone-220> ffmpeg 03Paul B Mahol 07master:63826a0b8288: avfilter/af_amix: make use of av_asprintf()
[17:38:44 CET] <jdarnley> In checkasm, how does the cosmetic name of a test given to check_func() and report() affect the result of the test?
[17:39:30 CET] <jdarnley> I wanted to drop the first 4 chars from the string but that causes the test to fail
[17:43:42 CET] <jamrial> jdarnley: make sure the cosmetic name in check_func() is unique
[17:43:52 CET] <jamrial> and not only within the module you're writing
[17:44:07 CET] <jdarnley> That'll do it
[17:44:25 CET] <jdarnley> thanks
[17:44:42 CET] <jamrial> no prob
[17:45:17 CET] <jamrial> i spent a long time pulling my hair with this situation with float_dsp and fixed_dsp :p
[17:45:41 CET] <jdarnley> :)
[17:52:41 CET] <jamrial> https://pastebin.com/raw/pg6r1RQa is this a bogus warning?
[17:53:42 CET] <jamrial> the buffer size there afaik can't be a compile time constant
[17:57:26 CET] <nevcairiel> jamrial: it happens to be INT64_MAX * 2, presumably its taking some kind of worst case, but it seems weird that gcc would do static analysis like that
[17:58:03 CET] <nevcairiel> (or UINT64_MAX for that matter)
[17:59:25 CET] <jamrial> buf_size is an int, though
[18:00:13 CET] <nevcairiel> even weirder
[18:28:05 CET] <jamrial> would changing https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avio.h;h=75912ce6bed97dd2cb9ca503d7103821c1f10db1;hb=HEAD#l242 into an uint32_t mean an api break?
[18:36:50 CET] <philipl> jkqxz: For mjpeg hooks, nvdec still needs even more of the buffer. I patched it to pass the entire avpkt->data and then it's happy
[18:37:57 CET] <Gramner> kierank: intel reference manuals I guess. what in particular are you wondering about?
[18:38:08 CET] <kierank> the non zmm additions
[18:39:09 CET] <Gramner> https://software.intel.com/en-us/intel-architecture-instruction-set-extensions-programming-reference
[18:39:33 CET] <Gramner> or was that the wrong one, hmm
[18:41:00 CET] <Gramner> https://www-ssl.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf maybe
[18:46:59 CET] <philipl> jkqxz, BtbN: HEre's a good one.
[18:48:02 CET] <philipl> I have a jpeg sample with an odd height (1071). nvdec doesn't support that, and it's returning a surface with height 1070.
[18:48:40 CET] <philipl> mpv ends up failing because it's using the decoder reported height which is still 1071 and then the cuda memcpy fails because it knows the source buffer is too small to copy 1071 lines
[18:49:16 CET] <philipl> With cuvid, the parser knows the limitation, or calculates it differently so the reported height is 1070
[18:49:27 CET] <BtbN> it should round up?
[18:49:28 CET] <kierank> Gramner: my question is more whether there is just the new stuff 
[18:49:35 CET] <philipl> BtbN: You'd think, but it does not
[18:49:41 CET] <BtbN> I patched it to do so
[18:49:45 CET] <philipl> Oh.
[18:49:49 CET] <philipl> where?
[18:49:58 CET] <BtbN> With the initial nvdec patches
[18:50:16 CET] <BtbN> Just a ( + 1) & ~1 around the width/height
[18:50:21 CET] <philipl> Hmm.
[18:50:34 CET] <philipl> Well, we're still ending up with a surface that can only have 1070 lines copied out of it.
[18:50:48 CET] <philipl> I need to see where the failure is. In the non-interop mode, it works out fine.
[18:51:40 CET] <Gramner> kierank: I'm not sure I understand the question, please clarify
[18:51:45 CET] <philipl> BtbN: this?             .Height        = frame->height >> (i ? 1 : 0),
[18:51:53 CET] <BtbN> no
[18:51:55 CET] <kierank> Gramner: is there basically a changelog explaining the new ymmm additions
[18:51:57 CET] <kierank> i guess not
[18:52:14 CET] <Gramner> don't think so
[18:52:21 CET] <philipl> BtbN: Then I can't find it.
[18:53:11 CET] <BtbN> https://patchwork.ffmpeg.org/patch/5937/
[18:53:29 CET] <BtbN> I think I dropped that patch because of no need for the other part of it
[18:53:52 CET] <philipl> BtbN: Yeah, this is not applied.
[18:54:15 CET] <philipl> Sorry, maybe you were not telling me it was in the tree, but that you had written a patch
[18:54:32 CET] <BtbN> I just forgot it never pushed
[18:55:25 CET] <jkqxz> philipl:  Wrt XvMC, are you able to test it?
[18:55:41 CET] <philipl> I tested compilation, but not runtime
[18:55:54 CET] <philipl> I have a local patch that does the obvious.
[18:55:59 CET] <philipl> Can send it if you wnat
[18:56:16 CET] <jkqxz> philipl:  And how can the nvdec decoder possibly need more than the SOF to EOI?  (Or have I actually messed up what you get...)
[18:57:31 CET] <philipl> jkqxz: I don't know. It may not need it, but maybe it expects the whole lot and then skips stuff
[18:58:59 CET] <jkqxz> Hmm, right.  I guess it needs SOI to EOI, there can be tables before SOF.
[18:59:10 CET] <philipl> xvmc fix: http://paste.ubuntu.com/26035814/
[19:00:28 CET] <jkqxz> I guess I'll split the raw buffer thing into SOI->EOI and scan blocks.
[19:00:59 CET] <jkqxz> Yep, I've already written exactly that for XvMC.
[19:01:02 CET] <philipl> BtbN: Will you push that change?
[19:01:07 CET] <Gramner> kierank: but the new stuff is basically opmasks, compress/expand, ternary logic, better shuffles, embedded broadcast, static rounding (zmm only though), scatters, better qword simd support, conflict detection, and better reciprocal instructions
[19:01:12 CET] <BtbN> philipl, no, it's broken
[19:01:13 CET] <philipl> It produces equivalent results to cuvid
[19:01:27 CET] <kierank> Gramner: hmm quite a lot then
[19:01:30 CET] <philipl> BtbN: the other part is broken you mean? Or rounding up is broken?
[19:01:38 CET] <Gramner> oh, and broadcasts from GPR:s
[19:01:46 CET] <BtbN> hwaccels must return full size frames
[19:01:54 CET] <BtbN> as the sw part sets cropping info on the frame
[19:02:26 CET] <philipl> BtbN: OK, so the other part is broken.
[19:02:46 CET] <jkqxz> Odd-size frames for MJPEG do work on Intel.  I still want to try AMD, but I need some sort of kernel or firmware upgrade for it.
[19:03:16 CET] <philipl> BtbN: so I'll make a separate change to put the rounding in?
[19:03:17 CET] <jkqxz> And I think it would be helpful to see it working on one of the Windows APIs as well before saying it's done.
[19:03:23 CET] <philipl> jkqxz: to be sure.
[19:03:35 CET] <jkqxz> Because there is much more trickiness here than with VP8.
[19:03:50 CET] <philipl> It's funny how this ends up being the most pathological hwaccel
[19:04:07 CET] <cone-220> ffmpeg 03Dale Curtis 07master:03fbc0daa7e3: avformat/utils: Prevent undefined shift with wrap_bits > 64.
[19:04:08 CET] <cone-220> ffmpeg 03Dale Curtis 07master:9648cc6d7fdb: avcodec/vorbis: 1 << 31 > int32_t::max(), so use 1u << 31 instead.
[19:04:15 CET] <jkqxz> Well, why do you think noone wrote it before now?  :P
[19:04:21 CET] <philipl> heh.
[19:04:28 CET] <BtbN> feel free too, I'm kinda short on time right now
[19:04:35 CET] <philipl> BtbN: Ok, I will.
[19:05:05 CET] <nevcairiel> jkqxz: for jpeg? dxva/d3d11 don't specify it
[19:05:25 CET] <jkqxz> Wrt the YUVJ stuff, the comment at the top was meant to say it was a hack and comments were invited.  Maybe it wasn't clear, since two people have replied with 'wtf why are you changing this' now.
[19:06:13 CET] <cone-220> ffmpeg 03James Almer 07master:e97667c82f4c: avformat/ttaenc: buffer packets directly
[19:06:14 CET] <cone-220> ffmpeg 03James Almer 07master:fa4121507ca4: avformat/ttaenc: add tta_init()
[19:08:03 CET] <philipl> jkqxz: I understood it was a hack. I'm just trying to wrap my head around what we really want to happen.
[19:08:25 CET] <jkqxz> nevcairiel:  Oh, that's unfortunate.  You only get hardware MJPEG decode through MediaFoundation or maybe DirectShow, then?
[19:08:53 CET] <philipl> jkqxz: We want to do hwaccel pix_fmt matching with the non-yuvj versions - that's basically it right?
[19:08:56 CET] <jkqxz> sw_pix_fmt needs to be the YUVnotJ format.
[19:09:02 CET] <jkqxz> Yeah.
[19:09:18 CET] <nevcairiel> jkqxz: only if the vendors provide proprietary filters for those
[19:09:40 CET] <philipl> jkqxz: Could we do it in get_format? If we see yuvj, switch to yuv when evaluating hwaccels?
[19:09:52 CET] <philipl> It's probably sufficiently close to globally true that it's safe to do there
[19:13:28 CET] <jkqxz> Hmm, maybe.  get_format needs to offer e.g. { CUDA, VAAPI, YUVJ422 }, so we can't mess too much.
[19:14:02 CET] <jkqxz> The code there also needs more logic to decide when to reinitialise - currently it doesn't have anything for that, since every frame stands alone.
[19:14:21 CET] <jkqxz> (And calling get_format on every frame is bad, which is the main thing I was avoiding with the current mess.)
[19:16:36 CET] <philipl> jkqxz: ok. but do we know that an hwaccel has been requested at that point? I think we do, because you call start_frame below this block. So can't you just conditionalise the pix_fmt messing around with 'if (s->avctx->hwaccel)' ?
[19:16:58 CET] <philipl> but no, ff_get_format picks the hwaccel doesn't it...
[19:17:23 CET] <jkqxz> Yeah, you only know after get_format.
[19:17:37 CET] <jkqxz> That's why start_frame is there :)
[19:17:41 CET] <philipl> yeah, yeah.
[19:18:15 CET] <philipl> So we need to fiddle the pix_fmt at the right points in ff_get_format so that they can match
[20:44:06 CET] <jdarnley> Holy shit!  A local store has slashed their price for the Ryzen 1800X.  Now just ¬314.
[20:46:16 CET] <BtbN> Guess nobody wants to buy the biggest one, and they are sitting on massive stocks.
[20:53:13 CET] <SortaCore> "h264 : left block unavailable for requested intra4x4 mode -1"
[20:53:17 CET] <SortaCore> why tho
[21:02:55 CET] <c3r1c3-Win> Maybe, maybe not. It could be that since all of those chips cost the same for AMD they are trying to move as much Christmas inventory for a good 4Q report.
[21:12:16 CET] <SortaCore> why would TCP H264 have unavailable blocks
[21:13:46 CET] <jdarnley> bitstream error?
[21:21:19 CET] <cone-220> ffmpeg 03Philip Langdale 07master:4186a77f26a8: avcodec/nvdec: Round up odd width/height values
[21:36:29 CET] <BtbN> hm, a spice input protocol/demuxer would be really handy right now
[21:36:43 CET] <BtbN> But the available libraries for that are outright horrible
[21:40:21 CET] <atomnuker> spice?
[21:40:50 CET] <BtbN> a better VNC like protocol to remote-control (mostly qemu) VMs
[21:43:01 CET] <SortaCore> there be no bitstreams or filters tho
[21:47:42 CET] <cone-220> ffmpeg 03James Almer 07master:31de45d20b1f: avformat/utils: fix mixed declarations and code
[22:05:38 CET] <jdarnley> Huh?  No bitstreams?  Then what is the h264 coming from?  the ether?
[22:05:54 CET] Action: jdarnley notes that would sill be a bitstream
[22:16:36 CET] <durandal_1707> im sick of nicolas, every damn change needs to be rewritten so it does oposite in code but with same funcionality
[23:02:17 CET] <SortaCore> from RTSP
[23:02:25 CET] <SortaCore> altho, no problem there, it's TCP
[23:02:27 CET] <SortaCore> so it shouldn't die
[00:00:00 CET] --- Sat Nov 25 2017