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

[burek]

[00:07:11 CET] <jkqxz> BtbN:  <http://sprunge.us/dQTH>?
[00:07:21 CET] <jkqxz> (Noticed by checkheaders.)
[00:07:50 CET] <BtbN> Yeah. I wonder why this didn't break when I did the other patch to make checkheaders work
[00:08:45 CET] <jkqxz> I'm not quite sure what the ordering requirements are there.
[00:09:16 CET] <BtbN> the d3d/windows headers have to be included before the cuvid header, because they otherwise define GUID
[00:09:34 CET] <BtbN> so putting config.h to the top is fine
[00:09:38 CET] <BtbN> I hope?
[00:10:38 CET] <BtbN> yeah, it doesn't include anything
[00:13:12 CET] <jkqxz> Happy with that, then?
[00:14:42 CET] <BtbN> sure, feel free to push that.
[00:14:54 CET] <jkqxz> Ok, thanks!
[00:16:51 CET] <SortaCore> speaking of which, I saw comments that D3D11 is slower than DX9
[00:17:10 CET] <jkqxz> Can anyone here test XvMC or videotoolbox?  I'd like to be sure I'm not accidentally breaking them somehow.
[00:17:41 CET] <jkqxz> Other than that, I would push 1-12 of the hwaccel configuration set (including VP8 but not MJPEG).
[00:19:14 CET] <SortaCore> https://github.com/rigaya/QSVEnc/blob/master/QSVEncC/QSVEncC.cpp#L435 sauce
[00:19:21 CET] <jkqxz> SortaCore:  They should be identical underneath, but at least the copy-back behaviour has significantly different paths and therefore possibly different performance.
[00:19:44 CET] <nevcairiel> dont believe everything you need
[00:19:46 CET] <nevcairiel> read*
[00:19:53 CET] <SortaCore> should I believe you when you say that
[00:20:18 CET] <BtbN> jkqxz, is it already possible for a hwaccel to output a sw format with that?
[00:20:41 CET] <nevcairiel> in my tests copy-back d3d11 is actually faster, despite (or maybe because of?) the on-gpu copy to a staging texture, but it does use a tad bit more cpu
[00:21:24 CET] <jkqxz> Yes, as long as it is different from associated software formats.  If they are the same then we need something other than get_format() to distinguish the choice.
[00:21:41 CET] <BtbN> hm. It'd be NV12.
[00:21:50 CET] <BtbN> Or P010/P016
[00:22:05 CET] <nevcairiel> doesnt that limit this to one hwaccel doing that?
[00:22:09 CET] <nevcairiel> seems kinda annoying
[00:22:13 CET] <jkqxz> Yes, it would.
[00:22:27 CET] <nevcairiel> i would rather not tie one particular hwaccel to say nv12
[00:22:27 CET] <jkqxz> We could maybe do something like checking the device in hw_device_ctx/hw_frames_ctx to get past that.
[00:22:39 CET] <jkqxz> But I haven't written that.
[00:22:53 CET] <BtbN> Or intruduce ugly fake-hw-formats that can be no-op downloaded
[00:23:06 CET] <nevcairiel> lets not do more fake hwaccel hacks
[00:23:21 CET] <BtbN> it would be something like PIX_FMT_CUDA_SW_NV12
[00:23:28 CET] <BtbN> Which is just PIX_FMT_NV12...
[00:23:43 CET] <jkqxz> nevcairiel:  +
[00:24:06 CET] <BtbN> Is there even another true hwaccel that can output software frames right away, other than nvdec?
[00:25:12 CET] <jkqxz> You could make some other cases faster by doing it.
[00:26:31 CET] <SortaCore> I'm just trying to feed H264 into it
[00:26:31 CET] <jkqxz> I think at least VAAPI (and D3D11?) could have an internal copy to CPU-memory-but-GPU-visible frames, avoiding another copy further down the stack.
[00:26:43 CET] <SortaCore> but the stream is decoding to YUV420P so NV12 conversion is a bit weird
[00:27:01 CET] <BtbN> nvdec outputs nv12
[00:27:02 CET] <jkqxz> But I don't really like that idea, because hwaccel output to software isn't a particularly common case.
[00:27:04 CET] <SortaCore> I have to receive it from rtsp, re-encode to NV12, pass to encoder...
[00:27:23 CET] <SortaCore> *convert frame to NV12
[00:27:34 CET] <SortaCore> is there a way to RTSP HWA decode?
[00:27:41 CET] <BtbN> what?
[00:27:53 CET] <jkqxz> (Well, maybe it is a common case, but I don't care about it myself.  If you're on the GPU, stay there.)
[00:27:55 CET] <BtbN> last time I checked, rtsp was not a video codec
[00:28:06 CET] <SortaCore> get from RTSP and pass into HWA for transcoding immediately
[00:28:39 CET] <BtbN> jkqxz, the issue for nvdec right now is, if the filter chain and everything expects software frames, the decoder will first copy from the mapped cuvid surface to a on-device CUDA frame. And then ffmpeg.c will download that to software.
[00:28:53 CET] <BtbN> But the cuvid surface can also be loaded into system memory immediately, which is substantially faster
[00:29:49 CET] <jamrial> jkqxz: poke iive about xvmc
[00:30:06 CET] <iive> what are these changes?
[00:31:25 CET] <jkqxz> iive:  Improving hwaccel setup - <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220733.html>.
[00:32:04 CET] <jkqxz> iive:  Can you test XvMC?  I can give you a set of patches, or a git repo.
[00:32:22 CET] <jkqxz> (Some changes since the last email set.)
[00:41:38 CET] <iive> jkqxz: repo or a single patch over current git ffmpeg
[00:41:40 CET] <SortaCore> whenever I try to switch h264 native decoder to a HWA h264 it doesn't decode
[00:42:29 CET] <iive> these patches does look ... messy
[00:46:03 CET] <jkqxz> iive:  <http://ixia.jkqxz.net/~mrt/ffmpeg/hwaccel/all.patch>
[00:46:37 CET] <jkqxz> (Full set of single patches available in the same directory.)
[00:52:09 CET] Action: iive compiling
[00:53:59 CET] <jkqxz> Thank you!
[01:24:15 CET] <iive> jkqxz: gonna take a while, since moving the hwaccel structures breaks the way mplayer configure finds them out.
[01:27:01 CET] <jkqxz> Does it look inside the AVHWAccel structures?
[01:28:00 CET] <iive> no, but HWACCEL is moved from allcodecs.c to hwaccels.h
[01:28:47 CET] <jkqxz> Right, mplayer configure stuff.  You should be able to replace it with the same mechanism as bsfs.
[01:29:42 CET] <jkqxz> $(list_subparts_extern AVHWAccel hwaccel codec/hwaccels.h) maybe.
[01:32:44 CET] <iive> yes already did it :D
[01:33:01 CET] <iive> and that's exactly how it looks :D
[01:44:21 CET] <iive> jkqxz: it segfaults in libavcodec/decode.c:1251 that is "err = hwaccel->init(avctx);" I suspect that init might be null, but gdb is been mean to me, saying variables are optimized out, even when i set breakpoing.
[01:46:54 CET] <jkqxz> Put "if (hwaccel->init) { }" around that and the error check?
[01:46:57 CET] <iive> jkqxz: should I make a stub init function and place it in hwaccel struct, or you'll add an if() check before calling init.
[01:47:26 CET] <iive> i don't set .init, so it is NULL in the best case :D
[01:47:36 CET] <jkqxz> The check used to be there, but I dumped it when eliminating the fake hwaccels.
[01:47:47 CET] <jkqxz> Apparently xvmc doesn't have it set either (though it does have the other calls)>
[01:47:59 CET] <jkqxz> So the if should stay.
[01:50:14 CET] <iive> with that change 
[01:50:18 CET] <iive> it seems to work.
[01:51:39 CET] <jkqxz> Yay!  I've changed that here as well.
[01:51:42 CET] <jkqxz> Thank you for testing!
[01:51:54 CET] <jkqxz> Videotoolbox, anyone?
[01:54:36 CET] <jamrial> ubitux or nevcairiel, maybe
[01:55:46 CET] <iive> what is videotoolbox, arm/rpi ?
[01:55:46 CET] <jamrial> or wm4. i think he wrote some videotoolbox patches before, so he probably has a mac laying around
[01:55:52 CET] <jamrial> osx
[01:55:57 CET] <iive> oh
[01:57:55 CET] <jamrial> mmal seems to be rpi
[02:11:20 CET] <Compn> videolan has some vtb people if you ask in their channel to test maybe ? 
[02:11:22 CET] <Compn> :)
[02:11:51 CET] <atomnuker> rcombs did some videotoolbox stuff too I think
[02:32:56 CET] <rcombs> yeah I know a thing or two about both
[02:33:34 CET] <rcombs> you may notice my name is in the copyright header for mmaldec.c
[02:33:55 CET] <rcombs> been a while, though
[02:34:13 CET] <tmm1> i can test videotoolbox stuff too, is there a git url/branch?
[02:42:28 CET] <jamrial> jkqxz: ^
[02:44:43 CET] <iive> tmm1:  same patch should work for you. <jkqxz> iive:  <http://ixia.jkqxz.net/~mrt/ffmpeg/hwaccel/all.patch>
[02:50:24 CET] <tmm1> ok, am i just checking to see if vt hwaccel decoding still works?
[02:52:12 CET] <iive> i guess, compilation and working :D
[02:56:59 CET] <tmm1> its segfaulting
[02:57:24 CET] <tmm1> https://gist.github.com/tmm1/990cb460f0cfe8a6880728d0a9141649
[03:09:11 CET] <rcombs> tmm1: happen to know much about OpenAL?
[03:12:45 CET] <tmm1> not really
[03:14:14 CET] <atomnuker> why would anyone use openal?
[03:14:29 CET] <atomnuker> (besides to get eax working)
[03:14:58 CET] <iive> is there anything better?
[03:15:58 CET] <atomnuker> ...not really, its the most decent library out there for platform-independent audio
[03:16:25 CET] <cone-321> ffmpeg 03James Almer 07master:08b294bf5f4e: avformat/isom: return proper error values in ff_mp4_read_dec_config_descr
[03:16:25 CET] <cone-321> ffmpeg 03James Almer 07master:abf669479c00: avformat/mov_esds: check return value of ff_mp4_read_dec_config_descr
[03:16:27 CET] <iive> how about sound 3d positioning ?
[03:17:39 CET] <cone-321> ffmpeg 03Rostislav Pehlivanov 07master:3154f4417ab5: lavc/utils.c: use C11 atomics for entangled thread handling
[03:17:40 CET] <cone-321> ffmpeg 03Rostislav Pehlivanov 07master:590136e78da3: libavcodec/utils.c: simplify avcodec locking with atomics
[03:17:41 CET] <cone-321> ffmpeg 03Rostislav Pehlivanov 07master:3701d499f873: error_resilience: remove avpriv_atomic usage
[03:18:01 CET] <atomnuker> now only that annoying cas function remains
[03:18:37 CET] <atomnuker> iive: it does 3d positioning I think, it has to in order to provide software eax emulation
[03:19:13 CET] <iive> atomnuker: i know it does. i ask if there is a library that does it better.
[03:22:06 CET] <atomnuker> not sure any other library does 3d positioning apart from fmod which sucks and is closed source
[03:24:12 CET] <iive> :)
[03:24:17 CET] <iive> n8 ppl
[04:25:04 CET] <atomnuker> michaelni: afaik the api for c11 threads was more limited than pthreads
[04:26:06 CET] <atomnuker> they should have just made pthreads part of the standard somehow
[04:26:30 CET] <atomnuker> and should have just standardized all the non portable functions like namesetting
[04:26:37 CET] <atomnuker> (no ubitux, I haven't forgotten yet)
[04:51:34 CET] <michaelni> atomnuker, it seems many of the additions in the recent years arent at the quality level the original K&R C was. But pthreads itself is also not all that great
[09:03:28 CET] <kurosu> what's with all the avx2 for lossless decoders?
[09:03:38 CET] <kurosu> has the overall speed been benchmarked?
[09:04:01 CET] <kurosu> I suspect that's actually a slowdown because the CPU is forced to downclock
[09:04:33 CET] <kurosu> in those, bitstream reading should be like 80-90% of the decoding time
[09:30:46 CET] <c3r1c3-Win> the only thing I can think of as to using AVX2 is double width registers, so in theory if your clock speed drops 30% it's still a win...but I'm not the expert on such.
[10:17:50 CET] <kurosu> If you halve 10%, you get 5% speedup, but if you loose even 10% on 80% it's 8%: net loss
[10:18:25 CET] <kurosu> (well, halve 20%, but 10% loss was conservative)
[11:37:08 CET] <jkqxz> tmm1:  Er, does that work before the change?  The hwaccel initialisation hasn't run when get_format() is called, so hwaccel_priv_data can't be filled (nothing has been chosen yet).
[11:39:25 CET] <jkqxz> It will only be set after get_format() returns, because it's created just before AVHWAccel.init is called.
[13:36:53 CET] <omerjerk> Hi, how do I mark the encoder as experimental? I know I asked this question before but I seem to have lost the message.
[13:37:15 CET] <omerjerk> There's some flag need to be set in codec capabilities.
[13:37:19 CET] <omerjerk> What's it exactly?
[13:43:13 CET] <jdarnley> omerjerk: There is a struct for every codec usually at the bottom of their file.
[13:43:36 CET] <jdarnley> In the strcut there is a capabilities field
[13:43:58 CET] <jdarnley> That is where you need to addthe experimental flag.
[13:43:59 CET] <omerjerk> yeah I know. I need to know the exact flag which needs to be set to mark the encoder as experimental. 
[13:44:12 CET] <omerjerk> what's the flag exactly?
[13:44:25 CET] <jdarnley> AV_CODEC_CAP_EXPERIMENTAL
[13:51:59 CET] <omerjerk> thanks. :)
[14:05:51 CET] <cone-523> ffmpeg 03Paul B Mahol 07master:ffc01280be63: avfilter: add lv2 wrapper filter
[14:38:38 CET] <durandal_1707> YEAH!
[14:56:38 CET] <cone-523> ffmpeg 03Derek Buitenhuis 07master:52a44d50beb2: h264_picture: Actually return error during alloc failure
[16:07:37 CET] <jdarnley> You know how I was wondering whether my flac assembly was correct?
[16:07:49 CET] <jdarnley> My test for checkasm doesn't work.
[16:08:06 CET] <jdarnley> I'm not sure the asm works with order=0 but then I'm not sure whether that is possbile in the real code.
[16:31:04 CET] <jdarnley> Gah!
[16:31:09 CET] <jdarnley> I'm just too incompetent.
[16:31:18 CET] <jdarnley> I want to pass the same value into the function
[16:31:24 CET] <jdarnley> not call rnd() twice
[16:33:51 CET] <jdarnley> oh but that was a separate issue to the 0 order problem
[16:40:39 CET] <cone-523> ffmpeg 03Mark Thompson 07master:6e0e3e1d8ddc: hwcontext_vaapi: Do not assume that sw_format is transferable
[16:40:40 CET] <cone-523> ffmpeg 03Mark Thompson 07master:3fbd4fc47621: nvenc: Include config.h before checking for D3D11 support
[16:40:41 CET] <cone-523> ffmpeg 03Mark Thompson 07master:022ddff0b2c2: doc/fftools: Remove documentation for old -opencl_bench option
[16:40:42 CET] <cone-523> ffmpeg 03Mark Thompson 07master:37c57df18e7c: doc/ffmpeg: Document opencl for -init_hw_device
[18:27:33 CET] <cone-523> ffmpeg 03Derek Buitenhuis 07master:e7af1394ecd0: vorbisenc: Check the return value of av_frame_clone
[18:36:43 CET] <cone-523> ffmpeg 03Michael Niedermayer 07master:2b6964f76438: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*
[18:36:44 CET] <cone-523> ffmpeg 03Michael Niedermayer 07master:2779d33ed998: avformat/aacdec: Fix leak in adts_aac_read_packet()
[19:06:05 CET] <philipl> jkqxz: back to mjpeg. What's the pix_fmt remapping meant to avoid? I commented it out and it didn't stop the hwaccel from working. I tried with 420, 422 and 444 samples.
[19:27:17 CET] <philipl> jkqxz: I guess it's because there's a code path where get_format is bypassed and you want the pix_fmt to match the pre-set sw_pix_fmt, but what usage follows this path? I didn't hit it using 'ffmpeg' or mpv
[19:45:53 CET] <tmm1> jkqxz: you're right it crashes on master too
[20:15:38 CET] <jkqxz> tmm1:  Presumably it is caused by 259dc4e01381c0d01fb1dbb8509c5087d621a0d7, which adds the reference to the VTContext which doesn't necessarily exist when videotoolbox_start is called externally?
[20:16:56 CET] <jkqxz> (It would work in a hw_device_ctx-only case, because start is called internally by AVHWAccel.init (after get_format) there.)
[20:22:36 CET] <jkqxz> I think you want to move that saving of the SPS profile/constraint/level bits somewhere later.
[20:22:59 CET] <tmm1> yea its my bug, will fix
[20:23:16 CET] <tmm1> need to figure out where best to move it
[20:23:24 CET] <jkqxz> To make it work in ffmpeg for testing, you can probably just delete the hwaccel definition in fftools/ffmpeg_opt.c - it will then use the generic setup only.
[20:24:42 CET] <jkqxz> (Which would be nice, though it kills the videotoolbox_pixfmt option.  That's why I didn't do it already, along with inability to test anything.)
[20:26:05 CET] <jcdutton> I am trying to use the segment muxer, so I have capture from a web cam, and store the files in 10 minute chunks.  The HLS muxer lets you create date directories, but the segment one appears not to
[20:26:17 CET] <jcdutton> Is there a patch for it somewhere?  Or shall I write one?
[20:29:28 CET] <tmm1> there is no patch, you would need to write it
[20:41:59 CET] <jkqxz> tmm1:  Mind trying <http://ixia.jkqxz.net/~mrt/ffmpeg/hwaccel/all_vt-hdc.patch>?  That's as before, but without the non-hw_device_ctx path for videotoolbox.
[20:46:10 CET] <tmm1> sure
[20:52:03 CET] <tmm1> jkqxz: works as expected
[20:57:49 CET] <jkqxz> tmm1:  Great, thank you.  I think that means I can push the set, then.
[20:59:26 CET] <tmm1> awesome
[21:00:31 CET] <jkqxz> Whether to get rid of ffmpeg_videotoolbox.c can be decided separately.
[21:10:01 CET] <jcdutton> tmml, thank you. Just checking. Not wanting to duplicate effort
[21:34:42 CET] <jamrial> carl literally behaves like a bot in the above ticket, wtf
[21:36:25 CET] <BtbN> well, that guy is very good at ignoring what he says though
[21:37:10 CET] <jamrial> repeating himself will not get him make the user understand
[22:36:50 CET] <atomnuker> jamrial: https://www.phoronix.com/scan.php?page=news_item&px=LLVM-6.0-3DNow-Improvements
[22:40:42 CET] <atomnuker> wouldn't it be a twist if some big corporate intel user requested 3dnow support to migrate their handwritten simd to new cpus
[22:41:20 CET] <jamrial> "So if you're running an AMD K6 up to Bulldozer CPU still, with the upcoming LLVM 6.0 release you may find better performance"
[22:41:37 CET] <jamrial> what a load of bullshit
[22:41:55 CET] <atomnuker> or maybe arm throws some cents at amd and buys a 3dnow license and adds support for it in armv9 or whatever's next
[22:41:56 CET] <jamrial> anything from athlon xp and newer has sse
[22:42:05 CET] <jamrial> there's zero gain in using 3dnow if you have sse
[22:42:26 CET] <jamrial> it's not like mmx where you can still see some advantage in using the smaller regs compared to sse2
[22:42:48 CET] <atomnuker> well intel still owns the sse license and won't give it to anyone else unless forced
[22:42:58 CET] <atomnuker> anyone else like people who want to emulate them
[22:43:35 CET] <atomnuker> (actually they have a patent, not a license)
[22:43:44 CET] <jamrial> i'm talking about that closing line. it's not only factually wrong (bulldozer doesn't have 3dnow), it's also absurd
[22:44:27 CET] <BtbN> He also made news about every little change we pushed for nvdec, even though the same feature was available forever, just called cuvid.
[22:44:42 CET] <atomnuker> yeah, it is, its phoronix after all
[22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:24cc0a53e99e: lavc: Add codec metadata to indicate hardware support
[22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:758fbc54fef2: lavc: Add hardware config metadata for decoders supporting hardware output
[22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:67e81d79ccfc: lavc: Use hardware config information in ff_get_format()
[22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:3536a3efb9fd: lavc: Deprecate av_hwaccel_next() and av_register_hwaccel()
[22:47:57 CET] <cone-822> ffmpeg 03Mark Thompson 07master:9bd326ac465d: lavc: Remove register mechanism for hwaccels
[22:47:58 CET] <cone-822> ffmpeg 03Mark Thompson 07master:da4e02b19615: lavc: Delete all fake hwaccels
[22:47:58 CET] <cone-822> ffmpeg 03Mark Thompson 07master:3a71bcc213f2: lavc: Mark all AVHWAccel structures as const
[22:47:59 CET] <cone-822> ffmpeg 03Mark Thompson 07master:b0cd14fb1dab: ffmpeg: Use codec hardware config to configure hwaccels
[22:47:59 CET] <cone-822> ffmpeg 03Mark Thompson 07master:efd0612fdcb7: vaapi: Make the decode profile matching more explicit
[22:48:00 CET] <cone-822> ffmpeg 03Mark Thompson 07master:9f00fa536938: vp8: Add hwaccel hooks
[22:48:01 CET] <cone-822> ffmpeg 03Mark Thompson 07master:40b75a943bcb: vaapi: Add VP8 decode hwaccel
[22:48:02 CET] <cone-822> ffmpeg 03Mark Thompson 07master:f69e9365f6e0: vaapi_decode: Ignore the profile when not useful
[22:50:05 CET] <atomnuker> jkqxz: is there still something to do to the mjpeg hooks?
[22:50:39 CET] <jkqxz> Yes, make them work properly.
[22:52:27 CET] <jkqxz> 4:2:0 still doesn't work in VAAPI without external allocation hackery.
[22:53:08 CET] <jkqxz> There is more to do around getting the right huffman/quant tables (it only works with JPEGs containing everything inline at the moment, ones with implicit tables don't).
[22:54:26 CET] <BtbN> Is this compatible with the way nvdec wants its jpeg stuff?
[22:55:19 CET] <jkqxz> And I don't much like how pulling the bitstream out for the hardware works at the moment.
[22:55:33 CET] <philipl> jkqxz: yay!
[22:57:33 CET] <jkqxz> BtbN:  Still unclear on that.  It's good using the whole packet for whatever cases philipl tried, but I'd still like to know how nvdec deals with implicit tables.
[22:57:57 CET] <BtbN> I'd guess it doesn't
[22:58:27 CET] <jkqxz> philipl:  nvdec VP8 -> ML, then?
[22:58:58 CET] <jkqxz> BtbN:  If it doesn't then some splicing of reconstructed tables into the bitstream may be desirable.
[22:59:10 CET] <philipl> jkqxz: I'll send it shortly
[23:04:35 CET] <philipl> sent
[23:13:10 CET] <philipl> jkqxz: the lazy option is to say it's extremely unlikely that any new mjpeg hw will show up so pass what nvdec wants to start_frame and what vaapi wants to decode_slice. :-)
[23:13:43 CET] <jkqxz> I don't think that's true, webcams are still all MJPEG.
[23:14:36 CET] <atomnuker> well some have uncompressed modes at least
[23:14:37 CET] <jkqxz> In fact, they seem to be going away from H.264 now that every machine has a better H.264 encoder than the webcam could possibly implement.
[23:16:50 CET] <jkqxz> Logitech's 4K webcam gives you MJPEG at 0.5Gbps or so, and doesn't have any other compressed mode at all.  (4K isn't really doable uncompressed over USB 3.)
[23:18:48 CET] <nevcairiel> high bitrate jpeg isnt that terrible, if they assume you're going to re-compress it anyway
[23:19:30 CET] <jkqxz> Yeah, which means everyone needs a fast MJPEG decoder.
[23:19:48 CET] <nevcairiel> not that this hardware is really faster on most pcs
[23:20:49 CET] <nevcairiel> didnt you test that our single-threaded software decoder almost beats vaapi
[23:20:53 CET] <jkqxz> It uses a lot less power.
[23:21:29 CET] <philipl> no one has benchmarked nvidia yet
[23:21:49 CET] <nevcairiel> running a dGPU might throw out the power rating tho =p
[23:21:55 CET] <philipl> heh
[23:22:41 CET] <jkqxz> It was pretty much best-case single-threaded, and the stuff after the decode is going to be nontrivial too.
[23:23:10 CET] <nevcairiel> i also dont think anyone took a real good look at making mjpegdec really efficient on modern hardware, because its just fast enough as it is
[23:24:16 CET] <philipl> jkqxz: do you have a source for samples of implicit tables and the different dcts? i haven't tested all the cases.
[23:26:03 CET] <jkqxz> The 4K from that webcam barely works on an Intel desktop if you want to do anything with the result.
[23:26:41 CET] <jkqxz> philipl:  Not really, I have some random webcams to test because that's the interesting case.
[23:26:52 CET] <jkqxz> I can make some streams.
[23:29:12 CET] <philipl> Hard to distribute due to size :-)
[23:42:51 CET] <philipl> jkqxz: regarding the conflict marker - it seems I fixed that when resolving a subsequent change in my stack. Now have to fiddle that around. good times.
[23:43:42 CET] <philipl> BtbN: should ff_nvdec_frame_params be called with the total number of frames (current + references) or just references?
[23:44:15 CET] <philipl> I did just references for vc1 and mpeg but current + references for vp8 and now I'm not sure which one is preferred.
[23:44:24 CET] <BtbN> not sure either
[23:44:41 CET] <BtbN> For VP9 it's just the 8 reference frames
[23:44:59 CET] <philipl> it grows the pool when needed so having it one short doesn't break anything but if the goal is to set it to the maximum, then it should be current + references
[23:45:31 CET] <philipl> I guess I'll stick to just references as that's what all the pushed ones have
[23:45:46 CET] <BtbN> the buffer is slightly too big all the time anyway
[23:52:37 CET] <jdarnley> atomnuker: I've just sent a patch set almost dedicated to you :)
[23:54:11 CET] <jcdutton> jkqxz, have you tried nvdec instead of vaapi?
[23:56:01 CET] <cone-822> ffmpeg 03Philip Langdale 07master:1da9851e3470: avcodec/nvdec: Implement vp8 hwaccel
[23:56:04 CET] <jcdutton> my nvidia card does nvdec at 200 fps for 1920x1080 frames.
[00:00:00 CET] --- Mon Nov 27 2017