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

[burek]

[00:30:16 CET] <philipl> jkqxz: So with paul's changes to remove yuvj stuff, does that unblock mjpeg hwaccel?
[02:58:18 CET] <atomnuker> durandal_1707: do these remove all yuvj references in the codebase?
[02:59:04 CET] <atomnuker> if the end of those is near it would make sense to get that while the abi unstable period is still going
[03:00:19 CET] <Chloe> Anyone debugged zlib/deflate in PNG? What tools did you use? (or just make custom ones?) 
[06:04:01 CET] <wm4> so does the hls demuxer not handle tags like "#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="stereo",LANGUAGE="en",NAME="English",DEFAULT=YES,AUTOSELECT=YES,URI="audio/stereo/en/128kbit.m3u8"" correctly?
[06:04:47 CET] <wm4> oh it does, my error
[08:02:14 CET] <tmm1> i can't figure out why mpegts created directly vs with hlsenc have different frame rates: https://gist.github.com/tmm1/fcbe42e9da85514fde48238463400552
[09:30:03 CET] <durandal_1707> atomnuker: nope, i first need to make it working for yuvj but cant
[09:30:12 CET] <durandal_1707> in mjpeg
[10:37:32 CET] Action: rcombs realizes he just sent 2 patches on top of an old version, having forgotten to rebase
[10:54:28 CET] <atomnuker> daddesio: can you look into the valgrind issues with the hybrid folding patch?
[12:58:48 CET] <tguillem> Hello guys. VLC is still using the old way to configure avcodec hwaccel. We don't want to change it for VLC 3.0 that is freezed but we'll change it for 4.0. In the meantime, hwaccel is not working anymore for us with a up to date master. I did a quick fix to identify the problem: https://gist.github.com/tguillem/038b593bdc47954e386e7d3b83789115 VLC 3.0 is not using 
[12:58:53 CET] <tguillem> AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX/AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX. Internal method seems to work fine with vdpau/vaapi. Any thought ?
[13:04:45 CET] <Compn> hmm there was a lot of discussions about hwaccel lately
[13:04:52 CET] <Compn> removing some old interfaces tguillem
[13:05:33 CET] <nevcairiel> The hwaccel infrastructure was changed quite a bit recently, I would suggest to stick to the last release if you dont use hwcontext functions yet
[13:05:45 CET] <nevcairiel> (also, git master is still in an unstable period right now)
[13:07:09 CET] <wm4> tguillem: these methods are just metadata
[13:07:19 CET] <wm4> they don't change anything for the API user
[13:07:25 CET] <nevcairiel> actually get_format enforces that
[13:07:40 CET] <nevcairiel> maybe its a bug that it blocks usage that otherwise works fine
[13:07:43 CET] <wm4> yeah... and that's because they replace AVHWaccel
[13:07:54 CET] <wm4> or well not really replace, but it's wired up differently
[13:08:11 CET] <wm4> what I mean is, vlc doesn't need to care
[13:08:14 CET] <wm4> modulo bugs
[13:08:23 CET] <nevcairiel> I mean, before those changes I could still use dxva2 or d3d11 without hwcontext, afterwards I cant, for arbitrary reasons, apparently
[13:08:45 CET] <wm4> and this bug will break most existing hwaccel users too
[13:08:51 CET] <wm4> so it's just a bug
[13:09:27 CET] <wm4> nevcairiel: not sure what you're saying, you still should be able to, although the above bug probably broke it
[13:09:43 CET] <tguillem> we have the "Invalid setup..." error here: https://gist.github.com/tguillem/72b7225b075f16c341e4515956c8b105
[13:09:45 CET] <nevcairiel> yeah its broken right now is the point
[13:09:53 CET] <tguillem> if you do nothing in the else, it works for us
[13:09:55 CET] <nevcairiel> everything that used hwaccel_context before wont work right now
[13:10:10 CET] <wm4> so what tguillem posted is a bug fix, nothing else
[13:10:21 CET] <nevcairiel> because all those hwaccels are only flagged as hwcontext/hwframesctx
[13:10:32 CET] <jkqxz> tguillem:  Most of those hwaccels do not offer an internal setup method.
[13:10:48 CET] <wm4> oh wait it should eb AD_HOC here, right?
[13:10:51 CET] <wm4> *be
[13:10:54 CET] <nevcairiel> probably adhoc yes
[13:10:55 CET] <wm4> instead of INTERNAL
[13:10:56 CET] <tguillem> maybe
[13:11:16 CET] <jkqxz> They do offer ad-hoc, but I didn't include that where others are available.
[13:11:22 CET] <wm4> AD_HOC means you have to do weird hw-API-specific stuff to get it to work
[13:11:25 CET] <nevcairiel> please do, though
[13:11:28 CET] <jkqxz> Because people using it already know that, and new users shouldn't do that.
[13:11:29 CET] <wm4> like setting hwaccel_context
[13:11:42 CET] <nevcairiel> well it breaks existing code if its not included in the list
[13:11:46 CET] <nevcairiel> because get_format bails out
[13:11:57 CET] <tguillem> AD_HOC means deprecated and that's what we do (for 3.0)
[13:12:15 CET] <wm4> whether it's considered deprecated is probably contentious
[13:12:23 CET] <wm4> for now it's clearly a bug that it doesn't work
[13:12:39 CET] <tguillem> an other fix is just to remove the goto try_again in the last ifelse (fix that doesn't touch HW_ACCEL defines)
[13:13:29 CET] <wm4> I think adding AD_HOC to d3d/vaapi/vdpau/vt should be fine
[13:13:35 CET] <tguillem> but maybe not all HWAPI works with AD_HOC ? We know for sure that vdpau/VAAPI/DXVA2/D3D11 works with ADHOC
[13:13:47 CET] <tguillem> Ok I'll send a patch
[13:13:52 CET] <wm4> (d3d meaning dxva2 and the "old" d3d11)
[13:14:09 CET] <jkqxz> Right, yeah.  It should include AD_HOC.
[13:14:14 CET] <wm4> and d3d11va2 doesn't support ad-hoc I think
[13:14:17 CET] <nevcairiel> the old d3d11 is already defined to be only adhoc right now
[13:14:22 CET] <wm4> ah
[13:14:30 CET] <wm4> correct
[13:14:40 CET] <nevcairiel> and the new one could support adhoc with like a one-line change, but apparently people didnt like that =p
[13:14:47 CET] <jkqxz> Yeah, only some want it.  NVDEC doesn't support AD_HOC either.
[13:15:28 CET] <wm4> personally I'd really like to see the d3d code cleaned up, and the AD_HOC methods seem to make this much harder
[13:16:25 CET] <nevcairiel> I liked the old way of keeping control over all the d3d stuff and only giving the necessary interface to avcodec, but apparently everyone else wants avcodec to do everything
[13:17:40 CET] <jkqxz> Well, they want it to do everything which can't matter to anything outside lavc :P
[13:18:04 CET] <nevcairiel> But what if it does?
[13:19:23 CET] <wm4> I'm not sure if I'm overly happy with the new API, but I like that it handles most things automagically
[13:19:50 CET] <jkqxz> What does?  The frame stuff is deliberately external-allowed (via hw_frames_ctx) because it can be relevant.  What are you going to do with the decoder objects?
[13:20:08 CET] <nevcairiel> Internally its basically the same anyway, the only difference is who fills the objects, so the complexity from allowing that is minimal
[13:20:15 CET] <wm4> I think he has some weird dshow requirements :)
[13:20:57 CET] <jdarnley> Does anyone have experience of clang complaining about "error: invalid application of 'sizeof' to an incomplete type"?  Specifically use of FF_ARRAY_ELEMS in checkasm.
[13:20:59 CET] <wm4> I wouldn't mind allowing decoder creation by API user and such, but please make hwaccel_context die
[13:21:14 CET] <nevcairiel> you need some way to pass the decoder etc into it
[13:25:36 CET] <jkqxz> wm4:  Did you see <https://github.com/intel/media-driver>?  It's the Media SDK driver, but now works without hacked kernel.
[13:25:44 CET] <JEEB> funky
[13:26:43 CET] <nevcairiel> They only have vp9 decode on cannonlake? didnt their earlier cpus have that, or is the driver just weird that way?
[13:26:46 CET] <jkqxz> (But the same "only some specific SKUs" restriction.  No recent processors at all.)
[13:27:07 CET] <jkqxz> It doesn't support anything between Skylake and Cannonlake.
[13:32:16 CET] <wm4> jkqxz: no, what is it even?
[13:32:24 CET] <wm4> their hybrid driver for vaapi?
[13:33:18 CET] <jkqxz> It's a whole separate driver for VAAPI.
[13:35:01 CET] <wm4> naturally I'm not interested in it anymore, anyway
[13:35:21 CET] <wm4> but what does it have over the normal driver?
[13:36:23 CET] <wm4> lol https://raw.githubusercontent.com/intel/media-driver/master/media_driver/agnostic/gen9/codec/kernel/igcodeckrn_g9.c
[13:36:28 CET] <jkqxz> Possibly-better performance, some different features (that group has been pushing stuff at official libva recently, which is implemented in their driver).
[13:36:29 CET] <wm4> I have no idea what it is but still
[13:37:00 CET] <jkqxz> Open source!
[13:38:59 CET] <jkqxz> And fair enough to not interested.  I imagine some people might try to use it with mpv, though I don't think it currently works.
[13:40:17 CET] <wm4> hm, why not? shouldn't it just follow the vaapi api?
[13:40:21 CET] <wm4> does it work with ffmpeg?
[13:40:44 CET] <jkqxz> Not currently.
[13:41:26 CET] <jkqxz> I think they only test against their Media SDK stuff, so it has a lot of implementation holes.
[13:41:38 CET] <wm4> heh
[13:45:29 CET] <rcombs> >CNL: Hardware accelerated encoding is not supported in the first release.
[13:45:53 CET] <rcombs> >SKL: Green or other incorrect color will be observed in output frames when using YV12/I420 as input format for csc/scaling/blending/rotation, etc. 
[13:46:00 CET] <rcombs> > The issue can be addressed with the kernel patch: WaEnableYV12BugFixInHalfSliceChicken7
[13:46:06 CET] <rcombs> ah yes, WaEnableYV12BugFixInHalfSliceChicken7
[13:46:19 CET] <rcombs> complete with a link to a nonexistent commit
[13:46:43 CET] <rcombs> I appreciate the open-source effort but& seems like intel's still gonna intel
[13:52:04 CET] <wm4> poor chickens
[16:45:04 CET] <BBB> atomnuker: do you have a libaom wrapper for ffmpeg?
[16:46:54 CET] <BBB> jamrial: or maybe you?
[16:47:09 CET] <jamrial> i don't
[16:47:39 CET] <jamrial> one was sent to libav long ago (decoder only), but it may not work anymore
[16:48:28 CET] <jamrial> i don't know how much the api evolved since then. it was written not too long after their renamed everything from vpx to aom
[16:48:44 CET] <jamrial> s/their/they
[17:02:21 CET] <wm4> shouldn't there rather be an internal decoder that's 1000x faster
[17:02:30 CET] <wm4> (joking)
[17:08:04 CET] <BBB> someone writing that decoder would probably appreciate being able to test it against some reference :-p
[17:10:37 CET] <jamrial> BBB: https://lists.libav.org/pipermail/libav-devel/2016-August/078848.html
[17:10:46 CET] <BBB> yes I found that :) tnx
[17:10:55 CET] <BBB> trying to get it to work now
[17:11:02 CET] <BBB> my configure/patch skills are clearly lacking
[17:11:46 CET] <BtbN> wm4, at least with the old driver the source assembly for those was right next to them. But not this time.
[17:12:47 CET] <daddesio> atomnuker: sure, let me fire up valgrind.
[17:15:57 CET] <jamrial> BBB: the imgfmt_to_pixfmt stuff doesn't look correct. it's similar to code we have disabled in the libvpx wrappers
[17:16:30 CET] <jamrial> because we implemented it in a different way
[17:16:51 CET] <daddesio> if there's any valgrind issue, I'm guessing it's an overlapping memcpy bug?
[17:17:00 CET] <BBB>     case AOM_IMG_FMT_I420:      return AV_PIX_FMT_YUV420P; looks ok
[17:17:04 CET] <BBB> I dont think any others are supported
[17:17:08 CET] <jamrial> that one is, yes
[17:18:18 CET] <BBB> so whats wrong?
[17:18:19 CET] <jamrial> i was talking about the 16bps ones, which are mapped to lavu 16bps pix_ftms in there, when we're instead mapping them to 10bps or 12bps depending on vpx_image->bit_depth value
[17:18:37 CET] <BBB> ah
[17:18:46 CET] <jamrial> if you're only testing yuv420p then it doesn't matter :p
[17:23:40 CET] <BBB> Ill add the relevant if for 10/12bits also
[17:23:43 CET] <BBB> I see what you mean
[17:23:45 CET] <BBB> easy to change
[17:38:42 CET] <BBB> [libaom @ 0x7fb4a0801a00] [bla bla]
[17:38:43 CET] <BBB> Segmentation fault: 11
[17:38:44 CET] <BBB> right....
[17:46:45 CET] <jdarnley> I think I should ask again...
[17:46:46 CET] <jdarnley> Does anyone have experience of clang complaining about "error: invalid application of 'sizeof' to an incomplete type"?  Specifically use of FF_ARRAY_ELEMS in checkasm.
[17:48:51 CET] <BBB> what type?
[17:49:02 CET] <BBB> you cant do it on forward-declared structs, specificall
[17:49:03 CET] <BBB> y
[17:52:44 CET] <jdarnley> It is an anonymous struct
[17:53:05 CET] <jkqxz> You also can't make arrays of them, so FF_ARRAY_ELEMS isn't very meaningful.
[17:53:19 CET] <jdarnley> struct { fields } var_name[] { ... }
[17:53:51 CET] <BBB> that should be ok
[17:53:57 CET] <BBB> if you name the struct, does it work?
[17:54:40 CET] <jdarnley> I'm trying to recreate the error but it is buried in this travis testing rubbish
[18:29:17 CET] <SortaCore> so, what's up with nvenc vs cuvid
[18:30:37 CET] <BBB> ok now it works
[18:33:55 CET] <jdarnley> How do I disable the stupid versions appended to library filenames?
[18:34:05 CET] <SortaCore> cuvid decoding + old encoding, nvenc new encoding, nvdec soon"?
[18:34:15 CET] <BtbN> cuvid never did any encoding.
[18:34:27 CET] <nevcairiel> nvenc is the only Nvidia encoding
[18:34:37 CET] <nevcairiel> And nvdec already exists
[18:34:43 CET] <BtbN> And nvdec and cuvid are the exact same thing.
[18:34:49 CET] <BtbN> They just decided to rename it at some point.
[18:34:52 CET] <jdarnley> Is it --disable-symver?
[18:35:01 CET] <SortaCore> ah, rebrand, now I'm with ya
[18:35:30 CET] <BtbN> They just wanted to get rid of the association with CUDA I guess
[18:36:19 CET] <nevcairiel> Which is probably a good idea, too many people thought it was a cuda decoder, as in a cuda program
[18:36:19 CET] <nevcairiel> Although they did actually have a cuda decoder for mpeg2
[18:36:39 CET] <BtbN> Yeah, they also did for h264
[18:36:41 CET] <BtbN> it was shit
[18:36:58 CET] <BtbN> put 100% load on your GPU, and still barely any noticeable CPU load reduction
[18:37:02 CET] <nevcairiel> The mpeg2 one has some use on oldish gpus
[18:37:10 CET] <nevcairiel> Not anymore
[18:37:23 CET] <BtbN> Only ever tested the one for h264
[18:37:27 CET] <BtbN> which is canned by now I think
[18:39:52 CET] <nevcairiel> No idea if the mpeg2 one still exists, easy to use through nvdec but just not even worth a option
[18:41:29 CET] <SortaCore> will ffmpeg be getting a rename for cuvid?
[18:44:13 CET] <BtbN> you're late to the party :P
[18:44:47 CET] <BtbN> jdarnley, the symver is pretty important. It's a bad idea to turn it off
[18:45:22 CET] <BtbN> Applications link to the .so with the version appended
[18:45:33 CET] <BtbN> so getting rid of it will cause issues
[18:45:46 CET] <jdarnley> I don't know what that is but it didn't fix my problem anyway
[18:46:29 CET] <jdarnley> But this isn't linking at all, linking fails because the swr isn't named .so.3
[18:46:47 CET] <jdarnley> make install
[18:47:14 CET] <BtbN> The symver was bumped recently
[18:47:22 CET] <BtbN> so you'll have to rebuild stuff still using the old
[18:47:45 CET] <jdarnley> I am building and building fails because this libs are named like shit.
[18:48:27 CET] <jdarnley> Fuck shared libs.  Fuck travis.  Fuck debian.
[18:49:57 CET] <BtbN> seems like whatever you're building has a questionable build system
[18:50:26 CET] <jdarnley> It is autotools!  Of course it is questionable!
[18:53:43 CET] <jamrial> the ffmpeg build system should afaik create the shared libswresample as .so, .so.3 and .so.3.x.x (two of them as symlinks)
[18:55:30 CET] <jdarnley> And why can't I have just .so and leave it at that?
[19:00:38 CET] <BtbN> What if the soname gets bumped?
[19:00:57 CET] <BtbN> It's used to indicate abi breaks, and enable installing abi-incompatible versions alongside one another
[19:20:23 CET] <iive> jamrial: i thought that ldconfig does that.
[19:20:35 CET] <iive> or is it already deprecated and not used ?
[19:21:05 CET] <BtbN> ldconfig fixes missing symlinks or something like that
[19:30:05 CET] <SortaCore> shared libs can return to the firey chasm from whence they came
[19:44:45 CET] <SortaCore> err
[19:44:59 CET] <SortaCore> I'm getting codec locked up on qsv
[19:46:48 CET] <SortaCore> I initialise a context with it, then free the context, and then later initialise another context and use it, but it locks up on avcodec_open2 due to codec being locked
[19:47:07 CET] <SortaCore> Assertion atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 0) failed at libavcodec/utils.c:1976
[19:49:15 CET] <SortaCore> who was messing with atomic?
[19:51:56 CET] <SortaCore> Rostislav?
[19:52:23 CET] <BtbN> atomnuker
[19:54:35 CET] <SortaCore> *stares blankly at @atomnuker*
[19:55:41 CET] <SortaCore> I'll see if I can isolate it a bit better
[21:03:23 CET] <daddesio> atomnuker: ... I'm an idiot! 8 is the *maximum* frequency resolution (allocated on the stack), but the actual one in use is given by 1 << f->size. (I see f->size varying between 2 and 3 in testvector05.) i.e. every instance of 8 * <blahblah> in the Hybrid Folding patch should really be <blahblah> << f->size. That got rid of all errors in valgrind/MSAN.
[21:06:14 CET] <daddesio> libopus has norm[] organized so that it coeffs are populated at the 8* offsets (i.e. there may be gaps between coefficients in norm[]). But FFmpeg uses << f->size offsets (so there are no gaps between coeffs, but there may be unused space at the end of norm[].)
[21:10:36 CET] <SortaCore> atomnuker: need a hand with atomics, it's dying on first usage
[21:11:40 CET] <SortaCore> https://pastebin.com/raw/UV3aFAzC
[21:16:34 CET] <tmm1> anyone have thoughts on what might be going on here: https://gist.github.com/tmm1/fcbe42e9da85514fde48238463400552
[21:18:06 CET] <SortaCore> I have to double PTS/DTS in my vids for some reason
[21:19:08 CET] <SortaCore> I see your tbr is doubled
[21:20:29 CET] <SortaCore> when I do H264 RTSP -> H264 video file, I manually set timing to match, and  do manual incrementing +1, but you have to double pts/dts for some reason or the end video file plays at half speed
[21:23:41 CET] <SortaCore> I'm not sure but I think JEEB said something about it?
[21:23:55 CET] <atomnuker> SortaCore: weird, keep in mind atomic functions take pointers to atomic variables
[21:24:13 CET] <SortaCore> I've not modified your code, just added av_log
[21:24:28 CET] <SortaCore> -your code +any ffmpeg code
[21:24:49 CET] <SortaCore> this is from master branch, I just tacked in extra av_log for debugging
[21:25:15 CET] <SortaCore> so atomic_bool, atomic_int, how do you read them for av_log?
[21:32:18 CET] <SortaCore> atm I'm passing the first with ? 1 : 0 and the second flat
[21:36:01 CET] <SortaCore> is lockmgr_cb meant to be set there?
[21:59:27 CET] <llogan> ubitux: would you (or durandal_1707 perhaps) be willing to look at "Patch vf_blackdetect" (the 2nd version) from "Jon bae"? Looks ok to me but i've never really used these filters. He asked on user ML what he did wrong because nobody replied.
[22:10:33 CET] <jamrial> llogan: he should ping it if it's been several days since he sent it
[22:11:06 CET] <llogan> yeah, we told him to do that
[22:31:31 CET] <jdarnley> That one?  He should definitely ping it so we know which one we are supposed to look at.  Although I guess we could guess from the dates on them.
[22:35:17 CET] <BBB> jamrial: I got libaom working on git master now, should I push this patch somewhere so others can use it too for whatever people want to use this for?
[22:38:32 CET] <BBB> https://github.com/rbultje/ffmpeg/commit/d96a0aad4633d22c03e930bc10689c4144796a4a << that works for me, on a somewhat old branch
[22:39:01 CET] <BBB> one month old, not too bad I guess
[22:39:12 CET] <jamrial> BBB: sure, a branch in your github for it sounds good
[22:39:29 CET] <jamrial> if it's not ready to hit git master
[22:40:14 CET] <jamrial> you should change the configure check into a pkgconfig one in any case
[22:40:29 CET] <BBB> probably not, I mean, av1 isnt finished yet
[22:40:29 CET] <BBB> but up to you guys
[22:40:33 CET] <BBB> maybe itd be useful for atomnuker
[22:40:47 CET] <BBB> pkgconfig doesnt work for non-installed software so unfortunately not useful for me :(
[22:41:08 CET] <BBB> (I dont run make install on dev trees such as libaom)
[22:42:19 CET] <jamrial> alright
[22:42:32 CET] <jamrial> and yeah, probably best to wait at least until the first version post bitstream freeze is tagged
[22:53:40 CET] <SortaCore> atomnuker: any idea why Broke
[22:55:51 CET] <cone-820> ffmpeg 03John Stebbins 07master:79a744768aa6: lavc/libx265: mark disposable frames
[23:05:46 CET] <TD-Linux> I think the bigger issue is that the libaom API might break. as long as it's marked experimental, it being unstable shouldn't be an issue
[23:06:23 CET] <TD-Linux> note that it's a good time to go fix any API issues that make it annoying to integrate in ffmpeg
[23:49:45 CET] <SortaCore> atomnuker: is this a bad time or something
[00:00:00 CET] --- Fri Dec  8 2017