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

[burek]

[01:08:00 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07master:3228ac730c11: vc2enc_dwt: pad the temporary buffer by the slice size
[02:01:31 CET] <rcombs> ubitux: so what does subtitles-in-lavfi need again
[03:10:27 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07release/3.0:94e538aebbc9: vc2enc_dwt: pad the temporary buffer by the slice size
[03:11:05 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07release/3.4:a94cb36ab2ad: vc2enc_dwt: pad the temporary buffer by the slice size
[03:11:22 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07release/3.3:a7aac19933a9: vc2enc_dwt: pad the temporary buffer by the slice size
[03:11:34 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07release/3.2:519a54cc195b: vc2enc_dwt: pad the temporary buffer by the slice size
[03:11:42 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07release/3.1:7cce80093055: vc2enc_dwt: pad the temporary buffer by the slice size
[03:36:10 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07master:723b6baaf8db: pngdec: check for bprint finalization sucess on icc data parsing
[03:58:05 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07master:0a771e6b3242: pngdec: expose gAMA and cHRM chunks as side/meta data
[03:58:10 CET] <atomnuker> hanna: ^
[03:58:44 CET] <hanna> neat
[04:38:48 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07master:fbf295e2bd4d: aacenc: support extended channel layouts using PCEs
[04:38:54 CET] <atomnuker> rcombs: ^
[04:39:05 CET] <rcombs> ooooooooooh
[04:49:23 CET] <jamrial> atomnuker: that's great to test the PCE handling in extradata using adtstoasc bitstream filter and matroska muxer
[05:08:00 CET] <stevenliu> &&
[05:36:21 CET] <cone-410> ffmpeg 03Rostislav Pehlivanov 07master:7b7775a604fb: aacenc: use the PCE comment field for encoder ID
[06:36:03 CET] <atomnuker> 2nd patchset I've seen which has fucked up patches
[06:36:24 CET] <atomnuker> honestly why do people fuck that up and create patchsets which are _impossible_ to apply
[07:50:15 CET] <ubitux> rcombs: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202152.html
[07:50:18 CET] <ubitux> this&
[10:57:33 CET] <rcombs> ubitux: is that up on a git repo somewhere?
[10:59:26 CET] <rcombs> ubitux: also, for context on the heartbeat problem, I actually also need something like this at the lavf level: I sometimes use two segment.c muxers (one for A/V and one for subs), and I need the subs one to know when there are no further subs up to its target cut point
[10:59:56 CET] <ubitux> it might be on an old branch of my github
[11:00:13 CET] <ubitux> but i haven't bumped it for a long time
[11:01:36 CET] <rcombs> I think there does need to be some way to express "no further events until at least [timestamp]" through a lavf->lavc->lavfi->lavc->lavf pipeline, but I don't know if it has to be in the form of regular heartbeats
[11:02:06 CET] <rcombs> yes AST is out of scope
[11:03:13 CET] <rcombs> I need to look closer at how frame reffing works; couldn't frame->buf handle that?
[13:59:13 CET] <cone-833> ffmpeg 03Rostislav Pehlivanov 07master:fc9dcfe7d50d: aacenc: mark the preset 5.0/5.1 layouts correctly with back speakers
[14:14:57 CET] <cone-833> ffmpeg 03Nicolas George 07master:dfa859b85a52: lavc/pngdec: fix av_bprint_finalize() usage.
[14:45:01 CET] <ubitux> i might be wrong but i believe Aurelien still has write rights
[14:45:18 CET] <ubitux> but maybe he lost/changed his key since then
[14:46:20 CET] <ubitux> rcombs: i don't remember the details, it's always pretty challenging to go back on this shit
[14:46:29 CET] <ubitux> i need to take time for it again
[14:46:45 CET] <ubitux> i have some holidays by the end of the year, i'll probably do that in that period of time
[14:49:47 CET] <jamrial> ubitux: ah, didn't know
[16:50:08 CET] <kierank> https://www.youtube.com/watch?v=n1XYEVtxzU8
[16:50:09 CET] <kierank> CARL LIVE
[16:51:24 CET] <jamrial> he's part of the panel or public?
[16:51:56 CET] <kierank> panel
[16:52:00 CET] <kierank> in the midlde
[16:53:15 CET] <jamrial> i was under the impression he disliked mediainfo
[17:00:01 CET] <durandal_1707> kierank: Carl who?
[17:00:08 CET] <kierank> EUGEN HOYOS
[17:01:28 CET] <durandal_1707> the one with bald head?
[17:02:54 CET] <thardin> stream ended
[17:03:38 CET] <jamrial> durandal_1707: kierank said he was the one in the middle of the panel, so no
[17:26:59 CET] <Gramner> he's at 1:34:04
[18:06:44 CET] <SortaCore> Heyo folks, looks like libmfx isn't configuring properly under master branch, mingw64/msvc vs2015 toolchain for win32
[18:07:35 CET] <SortaCore> any suggestions, I  have "RegQueryInfoKey" coming up as unresolved external symbol which should be Advapi32.dll
[18:08:51 CET] <SortaCore>  ./compat/windows/mslink -nologo -LARGEADDRESSAWARE -out:./ffconf.NllrH54M/test.exe ./ffconf.NllrH54M/test.o libmfx.lib
[18:09:00 CET] <SortaCore> libmfx.lib(mfx_win_reg_key.obj) : error LNK2019: unresolved external symbol __imp__RegOpenKeyExW at 20 referenced in function "public: bool __thiscall MFX::WinRegKey::Open(struct HKEY__ *,wchar_t const *,unsigned long)" (?Open at WinRegKey@MFX@@QAE_NPAUHKEY__@@PB_WK at Z)
[18:09:23 CET] <SortaCore> I'm on Windows 10 x64 but compiling for Win32
[18:10:44 CET] <SortaCore> I'll reclone from master and try again
[18:11:33 CET] <jamrial> SortaCore: there's a patch in the ml to solve this, yes
[18:13:15 CET] <SortaCore> ml?
[18:13:42 CET] <jamrial> mailing list
[18:15:49 CET] <SortaCore> google's not turning it up, how do I access it?
[18:17:01 CET] <jamrial> http://ffmpeg.org/pipermail/ffmpeg-devel/
[18:17:16 CET] <jamrial> i'll push it plus the follow up fix now
[18:19:06 CET] <nevcairiel> I'm still not happy with the silly rename
[18:19:29 CET] <jamrial> nevcairiel: i'll add a new entry just for advapi32
[18:19:53 CET] <jamrial> i'll not rename it since an upcoming merge expects it as it is right now
[18:20:12 CET] <SortaCore> it also seemed to be ignoring some include and library paths in there, is that related?
[18:20:17 CET] <nevcairiel> advapi32 is basic functionality anyway, on win32 you should always expect it to be presebt
[18:21:06 CET] <nevcairiel> The crypt check was more for the benefit of old mingw, not windows versions
[18:21:10 CET] <SortaCore> can't find libmfx.lib from the usr\local\lib folder, likewise couldn't see the mfx\*.h files under usr\local\include
[18:21:14 CET] <jamrial> but the mfx check is not linking to it
[18:24:12 CET] <SortaCore> I ended up putting the mfx folder and libmfx.lib under Visual Studio's VC folder
[18:25:31 CET] <nevcairiel> VC doesn't use usr or usr/local, it's not designed to, it's a windows environment
[18:25:49 CET] <SortaCore> I had them linked under PATH
[18:26:59 CET] <SortaCore> VC folder in path first, then mingw
[18:27:19 CET] <nevcairiel> You can add additional things into the INCLUDES and LIBS env variables, or just specify them in extra cflags to configure. PATH is for executables, not libraries
[18:30:11 CET] <nevcairiel> Every system has its own way of finding things :)
[18:32:04 CET] <jamrial> just sent an updated patch to the ml instead
[18:36:46 CET] <nevcairiel> Can't test but it's probably ok
[18:40:31 CET] <jamrial> i dislike all these hw stuff dependency chains. h264_qsv_decoder depends qsvdec which in turn depends on qsv which in turns depends on libmfx which in turn suggests avdapi32
[18:42:59 CET] <nevcairiel> In before linking breaks again
[18:47:15 CET] <jamrial> SortaCore, AaronL: can you test http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219496.html?
[18:48:55 CET] <jamrial> actually, i can probably remove the suggest line. it should be added to libmfx_extralibs in the require() call
[18:54:32 CET] <SortaCore> so it's git fetch --all, git pull, then the ./configure
[18:57:40 CET] <SortaCore> well that didn't work
[18:58:12 CET] <jamrial> no, that's a patch you need to apply manually
[18:58:20 CET] <SortaCore> rats, how do
[18:58:21 CET] <jamrial> it's not pushed to the git repo yet
[18:59:25 CET] <SortaCore> how do I apply a manual patch?
[19:00:11 CET] <SortaCore> I rarely use mingw, git, ffmpeg, intel qsv, so treat me like a newbie
[19:00:15 CET] <JEEB> copypasta it into a file, then `git am thing.patch`
[19:00:37 CET] <SortaCore> from what, the line that says index?
[19:00:44 CET] <JEEB> the whole contents
[19:00:56 CET] <JEEB> the git version at the end can be included too
[19:01:07 CET] <jamrial> SortaCore: https://pastebin.com/raw/5jmUwJ9J
[19:01:45 CET] <JEEB> or have it brought to you like that in which case `curl -L 'https://pastebin.com/raw/5jmUwJ9J' > thing.patch` will get your patch
[19:01:53 CET] <JEEB> and then `git am thing.patch` applies it
[19:03:04 CET] <SortaCore> alrighty, it looks happy
[19:03:08 CET] <SortaCore> reconfigurin'
[19:03:24 CET] <SortaCore> this configure could really do with some progress reports
[19:03:34 CET] <JEEB> oh yea, native windows is SLOOOOOW
[19:03:40 CET] <JEEB> I think it's ~10min right now
[19:03:52 CET] <SortaCore> yea, I had it at 7min, but it was erroring out
[19:03:53 CET] <JEEB> which effectively makes me not want to do any builds of FFmpeg on windows any more
[19:04:07 CET] <SortaCore> what was it, slow fork?
[19:04:10 CET] <JEEB> (although WSL is somewhat slower)
[19:04:14 CET] <JEEB> s/slower/faster/
[19:04:26 CET] <JEEB> SortaCore: yea, although they seem to have implemented it in WSL
[19:04:32 CET] <JEEB> where you run native linux binaries
[19:04:52 CET] <SortaCore> is that the bash on ubuntu on windows
[19:05:05 CET] <SortaCore> I have that too but I figured mingw would be more likely to work
[19:05:08 CET] <JEEB> that's one of the things using Windows Subsystem for Linux
[19:05:15 CET] <JEEB> (which is WSL)
[19:05:21 CET] <SortaCore> yea, I'm with you
[19:05:26 CET] <atomnuker> why is it so slow?
[19:05:38 CET] <JEEB> haven't profiled it
[19:05:54 CET] <JEEB> but basically making a meson/cmake version actually is starting to sound good
[19:06:08 CET] <JEEB> just to no longer have to configure for 10 minutes
[19:06:09 CET] <JEEB> lol
[19:06:09 CET] <jamrial> atomnuker: it became stupidly slow with windows 10 falls creator build
[19:06:23 CET] <SortaCore> when I came on last year or so with ffmpeg problem, you told me it was something to do with mingw path-finding
[19:06:24 CET] <JEEB> and the libav changes made it slow too
[19:06:30 CET] <jamrial> i don't know what microsoft did with it. creators build was "ok"
[19:07:44 CET] <jamrial> windows was always slow with process creation. running make with several jobs is still slower than on linux
[19:08:17 CET] <jamrial> but the falls creator build seemingly fucked something up
[19:09:36 CET] <SortaCore> patch didn't work
[19:10:10 CET] <BtbN> it's primarily slow because it spawns tons of processes, and fork-emulation on windows is slow as hell
[19:10:13 CET] <jamrial> can you post your config.log somewhere?
[19:13:05 CET] <SortaCore> https://pastebin.com/TFhNXwqj
[19:13:10 CET] <SortaCore> or do you want the full thing
[19:13:27 CET] <SortaCore> that's the ending part
[19:14:22 CET] <jamrial> ah, you're using the libmfx package with a pkg-config file, in which case the fix is in their hands, not ours
[19:14:44 CET] <SortaCore> the pc file I had to make myself
[19:15:18 CET] <jamrial> why would you do that and then claim configure isn't work?
[19:15:23 CET] <AaronL> sorry, just saw the stuff about advapi32
[19:15:28 CET] <jamrial> there's a fallback path for libmfx without pkg-config files
[19:15:36 CET] <alevinsn> I'm happy to submit new patches
[19:15:40 CET] <SortaCore> like I said, I'm new to this stuff
[19:15:43 CET] <alevinsn> that add a new entry for advapi32
[19:15:45 CET] <jamrial> which you should be using
[19:15:51 CET] <SortaCore> I chucked it on the Libs line
[19:15:58 CET] <alevinsn> rather than replace wincrypt
[19:16:16 CET] <SortaCore> I think that was the recommended method for compiling on a guide
[19:16:22 CET] <SortaCore> so I should delete libmfx.pc?
[19:16:44 CET] <alevinsn> jamrial:  I see that you already did this
[19:17:05 CET] <alevinsn> SortaCore:  if you want to use the alternate path
[19:17:08 CET] <alevinsn> that doesn't need pkg-config
[19:17:21 CET] <alevinsn> just make sure that the headers and libraries are available
[19:17:31 CET] <alevinsn> on Windows, that would be in INCLUDE and LIB
[19:17:34 CET] <alevinsn> environment variables
[19:17:39 CET] <jamrial> well, you could just add -ladvapi32 to it and call it a day, but if you want configure to detect it the proper way, remove your custom .pc file and let configure use the fallback path
[19:18:48 CET] <alevinsn> jamrial:  I'm not sure if RegQueryInfoKey is such a good choice
[19:18:55 CET] <alevinsn> since technically it would be RegQueryInfoKeyA/W
[19:19:03 CET] <alevinsn> RegCloseKey will work though
[19:19:18 CET] <alevinsn> that's what I would recommend
[19:19:40 CET] <jamrial> sure, any function is fine for me
[19:20:00 CET] <jamrial> but i need to know if the patch works for the non pkg-config path or not
[19:20:28 CET] <alevinsn> jamrial:  is the _suggests route preferred?  The approach I used was one that you had used in an earlier commit
[19:20:50 CET] <jamrial> no, the suggest line is actually not needed
[19:21:16 CET] <jamrial> alevinsn: https://pastebin.com/raw/5jmUwJ9J this one removes it
[19:22:20 CET] <jamrial> i don't want to rename wincrypt because a future merge will make use of it, so a new entry for advapi32 is the better solution
[19:22:40 CET] <alevinsn> yeah, that makes sense
[19:23:17 CET] <alevinsn> Yes, that looks good, but I would replace RegQueryInfoKey with RegCloseKey, since RegQueryInfoKey doesn't technically exist
[19:23:39 CET] <jamrial> alright, will change that and push it
[19:23:44 CET] <alevinsn> although it might work anyway because RegQueryInfoKey is defined to be the A or W version depending on whether or not UNICODE is enabled
[19:24:17 CET] <alevinsn> its also possible something similar would be needed on Linux, but I haven't looked into it
[19:24:24 CET] <alevinsn> so, regarding the log message
[19:24:33 CET] <alevinsn> might want to clarify that it is for Windows
[19:29:42 CET] <SortaCore> well, adding to pc worked, I'm trying without PC file now
[19:34:48 CET] <SortaCore> doesn't work
[19:35:08 CET] <SortaCore> can't find the include file for mfx/mfxvideo.h
[19:35:32 CET] <SortaCore> where should it be by default?:
[19:36:19 CET] <jamrial> anywhere in your PATH
[19:36:58 CET] <jamrial> and if it's not, then add the path to --extra-cflags
[19:37:35 CET] <SortaCore> it is in there, the user path
[19:39:02 CET] <alevinsn> make sure the directory where it can be found
[19:39:05 CET] <alevinsn> is in INCLUDE
[19:39:13 CET] <alevinsn> for the .lib file
[19:39:19 CET] <alevinsn> make sure that the directory in which it can be found
[19:39:23 CET] <alevinsn> is in the LIB environment variable
[19:39:27 CET] <alevinsn> example:
[19:39:44 CET] <alevinsn> export INCLUDE="${INCLUDE};${BONDING_PATH_WIN}\thirdparty\inc\intel_media_sdk"
[19:39:53 CET] <alevinsn> needs to use Windows-style paths
[19:40:14 CET] <alevinsn> since it is used by cl.exe, which is the MSVC compiler executable
[19:40:29 CET] <alevinsn> and for LIB:
[19:40:30 CET] <alevinsn> -- For release ffmpeg builds:  export LIB="${LIB}${BONDING_PATH_WIN}\thirdparty\bin\win32\64\Release"
[19:40:30 CET] <alevinsn> -- For debug ffmpeg builds:  export LIB="${LIB}${BONDING_PATH_WIN}\thirdparty\bin\win32\64\Debug"
[19:40:43 CET] <alevinsn> these are from my own instructions, but adapt as necessary
[19:40:52 CET] <alevinsn> this is also after starting msys2
[19:41:00 CET] <alevinsn> you would use set from a Windows command prompt
[19:41:29 CET] <jamrial> or just use --extra-cflags to add "-I/path/to/include -L/path/to/lib" during configure
[19:41:35 CET] <jamrial> in any case, at this point this is user support and this channel is not the place for that
[19:42:01 CET] <jamrial> i'll push the patch now
[19:42:37 CET] <alevinsn> thanks
[19:43:02 CET] <alevinsn> on a separate note, I've also submitted a different configure/Makefile patch relevant for Windows for installing the .pdb files
[19:43:19 CET] <alevinsn> which I've been maintaining in one form or another over the last several months
[19:43:34 CET] <alevinsn> does no one else have an interest in the .pdb files being part of the install/uninstall process?
[19:44:14 CET] <cone-833> ffmpeg 03James Almer 07master:bf7ae32a0814: avdevice/decklink_dec: make some function static
[19:44:15 CET] <cone-833> ffmpeg 03James Almer 07master:28f5753fed4b: configure: fix the non pkg-config libmfx check on Windows
[19:45:59 CET] <alevinsn> its common practice to package .pdb files as part of an installation package on Windows
[19:46:22 CET] <jamrial> ping the patch if nobody looked at it
[19:51:47 CET] <BtbN> I don't think anyone on Windows debugs ffmpeg out-of-tree
[19:52:03 CET] <BtbN> Or on any OS really
[19:53:19 CET] <alevinsn> Well, I build debug and release builds of ffmpeg
[19:53:23 CET] <alevinsn> from the same tree
[19:53:39 CET] <BtbN> It builds both every time
[19:53:54 CET] <alevinsn> no it doesn't--by a "release build"
[19:53:58 CET] <alevinsn> I mean built with -MD
[19:54:07 CET] <alevinsn> and linking to release builds of some binaries
[19:54:11 CET] <alevinsn> also build with avx2
[19:54:21 CET] <alevinsn> a debug build is built with -MDd
[19:54:30 CET] <alevinsn> this isn't done by the ffmpeg build itself
[19:54:35 CET] <alevinsn> they are flags I pass in
[19:55:40 CET] <alevinsn> Regardless, whether or not you would benefit from the .pdb files being part of the make install/uninstall process, it certainly doesn't hurt to do so, and it makes things equivalent to a gcc-based build
[19:55:47 CET] <alevinsn> which packages the symbols are part of the binaries themselves
[19:55:57 CET] <alevinsn> s/are/as
[19:56:33 CET] <alevinsn> also --disable-optimizations for a debug build
[19:56:36 CET] <alevinsn> as much as can be doe
[19:56:37 CET] <alevinsn> done
[19:58:06 CET] <BtbN> I don't think the gcc builds install the non-stripped versions of the binaries
[19:58:42 CET] <cone-833> ffmpeg 03Michael Niedermayer 07master:51090133b31b: avcodec/cngdec: Fix integer clipping
[19:59:29 CET] <alevinsn> that is true--although it is possible to disable stripping
[19:59:53 CET] <alevinsn> in which case it is fairly easy to get symbols as part of make install
[20:00:03 CET] <alevinsn> which is not an option on Windows
[20:00:37 CET] <alevinsn> plus, I think that only applies to the executables
[20:00:41 CET] <alevinsn> ffmpeg, etc
[20:00:52 CET] <alevinsn> I think the symbols are packaged in the .so files automatically
[20:02:09 CET] <alevinsn> hmm, maybe that's not true
[20:02:16 CET] <alevinsn> but, regardless, still possible to disable stripping
[20:03:30 CET] <alevinsn> anyway, there is no equivalent to disabling stripping on Windows
[20:04:19 CET] <jamrial> BtbN: is the latest private_ref patch ok?
[20:04:37 CET] <BtbN> It looks ok to me
[20:04:49 CET] <alevinsn> BtbN:  so, to summarize, with gcc-based builds, you're correct, symbols are automatically stripped out, unless disabled with --disable-stripping
[20:05:15 CET] <jamrial> i'll have to update wm4's set after it in any case, to replace opaque_ref uses. especially the wrapped_avframe part probably needs to be different
[20:05:39 CET] <alevinsn> BtbN:  but on Windows, there is no equivalent--stripping is turned off by default on Windows, since it likely doesn't work and won't do anything anyway, and there is no way to get the symbols included
[20:05:58 CET] <BtbN> jamrial, it should make the patchset a bit simpler. As it doesn't need to be wrapped in get_buffer
[20:06:19 CET] <BtbN> MSVC just isn't the most common platform to build and use ffmpeg with
[20:06:25 CET] <BtbN> And I don't think Windows-Gcc uses PDB files?
[20:06:49 CET] <alevinsn> BtbN:  what do you think about this?  If the user specifically enables --disable-stripping with MSVC builds, it does the equivalent and includes the .pdb files in the install?  And only in this case?
[20:07:01 CET] <JEEB> mingw-w64 binaries just have the debug symbols included
[20:07:02 CET] <alevinsn> any gcc-based builds won't use .pdb files
[20:07:13 CET] <JEEB> pdb is a MSVC concept
[20:07:58 CET] <jamrial> so all the wrapping code in decode.c can be removed?
[20:08:59 CET] <jamrial> the draw_horiz_band stuff is still needed in some form, i guess, since it's passing the frame to the user
[20:10:06 CET] <alevinsn> BtbN:  anyone who wants to use FFmpeg libraries in their MSVC-based software project must build FFmpeg with MSVC if they want to be able to debug FFmpeg
[20:10:22 CET] <alevinsn> gcc-based builds of FFmpeg on Windows can't be debugged with anything besides gdb
[20:10:33 CET] <alevinsn> and sometimes that doesn't even work
[20:11:12 CET] <BtbN> jamrial, not all of it, as it will still need to be freed when returning the frame from lavc, but there is no need to unwrapp while calling get_buffer
[20:11:29 CET] <JEEB> gdb on windows has been pretty stable for me but on the other hand I build my gdb binaries myself
[20:11:46 CET] <JEEB> and I mostly utilize the toolchain that nev builds
[20:14:24 CET] <alevinsn> JEEB:  the fact that I build with MSVC has allowed me to automatically discover things such as memory leaks in FFmpeg and memory corruption
[20:14:45 CET] <JEEB> yea if you have the intel tools that are like valgrind that's awesome
[20:14:59 CET] <alevinsn> just functionality built into Windows
[20:15:01 CET] <JEEB> I'm not saying anything against MSVC builds :P when you need them you need them
[20:15:04 CET] <JEEB> eh
[20:15:08 CET] <JEEB> > memory leak detection in windows?
[20:15:14 CET] <alevinsn> well, _Crt stuff
[20:15:15 CET] <JEEB> where's my valgrind!
[20:15:18 CET] <JEEB> :D
[20:15:21 CET] <alevinsn> that is automatically turned on when using MFC
[20:15:27 CET] <alevinsn> or debug builds rather
[20:15:47 CET] <JEEB> never seen that thing. I just usually make most of my code cross platform and use valgrind on lunix
[20:16:04 CET] <alevinsn> won't work for things like D3D11 though on Linux :-)
[20:16:05 CET] <JEEB> because valgrind - while slow - is a godsends
[20:16:08 CET] <JEEB> well sure :)
[20:16:14 CET] <JEEB> platform specifics make you :<
[20:16:26 CET] <JEEB> I think the last platform specific thing I did was IStream AVIO wrapper
[20:16:31 CET] <JEEB> for making an explorer plugin
[20:16:33 CET] <alevinsn> memory corruption detected in the form of exceptions on Windows sometimes
[20:16:39 CET] <alevinsn> when using the debug CRL
[20:16:41 CET] <alevinsn> CRT
[20:16:49 CET] <alevinsn> when heap is freed, etc
[20:17:15 CET] <alevinsn> Intel tools like memory checker are practically useless for real software projects
[20:18:03 CET] <jamrial> michaelni: can you push the private_ref patch? but fix the typos in the library names first
[20:31:31 CET] <alevinsn> is there a proper way to withdraw a previously submitted patch so that is shows up as withdrawn or whatever the equivalent is on patchwork?
[20:34:01 CET] <BtbN> which patch?
[20:34:05 CET] <jamrial> change its state to withdrawn or superseded
[20:34:54 CET] <jamrial> for that matter, it's not showing patches sent during the last three days
[20:35:59 CET] <BtbN> We should steal the patchwork from Intel/Freedesktop
[20:36:02 CET] <BtbN> it's way better
[20:36:09 CET] <durandal_1707> atomnuker: gonna push aptX before it becomes invalid again?
[20:36:32 CET] <atomnuker> no, it still has issues, waiting for the author to fix
[20:36:32 CET] <alevinsn> jamrial:  by creating an ffmpeg patchwork account and withdrawing it there?  Or is there a way to send an e-mail to the list to get the equivalent done?
[20:36:46 CET] <atomnuker> michaelni / jamrial: don't push the private ref patch yet, I have issues with it
[20:36:47 CET] <jamrial> durandal_1707: considering he requested changes, i assume no
[20:37:21 CET] <jamrial> atomnuker: what issues? if it's the wording in the doxy then that can be changed later just fine
[20:37:28 CET] <jamrial> alevinsn: creating an account, obviously
[20:37:36 CET] <atomnuker> michaelni: I want it made clear to API users that its just temporary storage that won't get used for library to library stuff
[20:37:58 CET] <alevinsn> jamrial:  I tried that but got server 500 error or something like that
[20:38:08 CET] <michaelni> atomnuker, ok, ill wait
[20:39:02 CET] <jamrial> michaelni, atomnuker: instead of "waiting", please write a doxy you both agree with and push. or modify it later
[20:39:58 CET] <BtbN> yeah, patchwork indeed seems to be not picking up new mails
[20:40:47 CET] <jamrial> seriously, drop the bikeshedding. the post bump unstable api/abi period is not over yet, so a doxy wording for a new field is the least important thing in the world right now
[20:40:54 CET] <michaelni> jamrial, "waiting" == iam working on some other FFmpeg stuff
[20:41:03 CET] <jamrial> michaelni: alright
[20:49:56 CET] <SortaCore> Should I still be getting messages from h264 when I'm using h264_qsv?
[20:59:43 CET] <alevinsn> SortaCore:  there are some samples in doc/examples that you might find helpful for hardware-accelerated decoding
[20:59:54 CET] <alevinsn> no examples for encoding though
[21:00:46 CET] <BtbN> Isn't there one for vaapi on the list?
[21:01:09 CET] <BtbN> but most hardware encoders are just a matter of specifying a different name than libx264 anyway
[21:01:19 CET] <alevinsn> under doc/examples?  No, there is only only encode_video.c
[21:01:23 CET] <alevinsn> which is pretty generic
[21:01:32 CET] <alevinsn> there is more to do with hardware encoding than just what is done in encode_video.c
[21:01:36 CET] <jkqxz> hw_decode.c.  It works with all the proper decoders.
[21:01:37 CET] <BtbN> https://patchwork.ffmpeg.org/patch/5883/ not even a week ago
[21:02:00 CET] <jkqxz> Bleh, I read that wrong.
[21:02:37 CET] <jkqxz> And yes, encode doesn't really need much more unless you want to do other stuff too.
[21:03:17 CET] <BtbN> some encoders might need a hwcontext or so
[21:03:20 CET] <BtbN> but that's about it
[21:03:32 CET] <BtbN> with the logic to create them being in avutil by now, that's not a lot ot work
[21:03:51 CET] <alevinsn> does new hwaccel API apply to encoders as well as decoders?
[21:04:48 CET] <alevinsn> for QSV encoding, I had to do quite a bit more than what is done in encode_video.c
[21:05:04 CET] <alevinsn> particularly if I wanted to use video memory
[21:05:33 CET] <alevinsn> but that was 4-5 months ago or so, so maybe it is easier now
[21:06:40 CET] <alevinsn> jkqxz:  I wanted to tell you, I know you aren't the only one that has worked on the new hwaccel stuff, but I decided to add HW-accelerated decoding to my project recently, and it was extremely easy to do so and works really well.  There is no reason to ever use h264_qsv for decoding anymore.  Anyway, thanks.
[21:07:18 CET] <alevinsn> in fact, h264_qsv doesn't work in some cases, particularly if you are decoding an mpegts and don't get the mpegts after it has been streaming from some time
[21:07:27 CET] <alevinsn> i.e. start in the middle--h264_qsv can't cope with that
[21:07:28 CET] <jkqxz> If you want to encode from GPU memory then yes, because you need all of the GPU setup to get the frames from somewhere.  From system memory it should just want a device and nothing else.
[21:07:43 CET] <jkqxz> Yeah, I regard h264_qsv decode as deprecated and don't want to touch it.
[21:08:26 CET] <alevinsn> the GPU memory stuff doesn't apply to HW-accelerated decoding, right?  It seems like it uses HW frames automatically.
[21:08:50 CET] <jkqxz> I'm thinking of going further and making a new encoder which just accepts dxva2/d3d11/vaapi frames and has all the libmfx shit internally, with intent to kill external visibility of qsv surfaces entirely (use the platform API only).
[21:09:02 CET] <jkqxz> Yes, the decoding will make the GPU frames for you in hw_device_ctx mode.
[21:09:10 CET] <alevinsn> you had mentioned that you thought h264_qsv should go away several months ago, I didn't exactly believe you then--I should have :-)
[21:09:54 CET] <alevinsn> there are two improvements to hw_decode.c that I will submit a patch for at some point
[21:10:38 CET] <alevinsn> jkqxz:  still, there are options for QSV encoding that are relevant
[21:11:11 CET] <jkqxz> Yeah, the encoder would keep the options.  It just wouldn't expose any of the surface stuff externally.
[21:11:43 CET] <alevinsn> so, no need to include any QSV-specific FFmpeg header files or work with AVQSVFramesContext?
[21:11:54 CET] <jkqxz> (And I would call it "libmfx" rather than "qsv" to reduce stupid confusion with people on Linux installing the Media SDK and destroying any hope of having working video stuff.)
[21:12:20 CET] <jkqxz> They might need the platform one instead (D3D or VAAPI), but yes, ideally.
[21:13:38 CET] <alevinsn> the main deficiency in hw_decode.c is that it doesn't have a call to av_frame_copy_props() after calling av_hwframe_transfer_data()
[21:14:05 CET] <alevinsn> none of the timestamp stuff gets copied over without doing that--not exactly relevant for the sample, but likely relevant for anyone who uses it
[21:16:44 CET] <jkqxz> Huh, yeah.  Patch definitely welcome for that one!
[21:17:29 CET] <jkqxz> (Though yes, it's kindof pointless in the example (hence it being missed, probably), but useful for anyone doing anything more sophisticated.)
[21:17:59 CET] <jya> out of topic, but is there a way with ffplay to not treat EOS in a URL as EOS, but just that it isn't available  *yet* ?
[21:20:58 CET] <jamrial> jya: you should probably ask marton balint, since he's the main ffplay dev
[21:27:39 CET] <SortaCore> so for QSV I have to do a lot more then specify encoder h264_qsv?
[21:30:35 CET] <atomnuker> michaelni / jamrial: does "Field for temporary usage inside the project libraries only, does not get used anywhere outside. Can be safely zero'd, however users should use opaque_ref instead." sound good? plus making the field a void * instead of an avbufferref
[21:31:01 CET] <BtbN> So you want to cast it back and forth all the time?
[21:31:37 CET] <BtbN> Why not just add "Do not use for intra-library data exchange."?
[21:31:58 CET] <BtbN> *inter
[21:32:47 CET] <michaelni> atomnuker, " Can be safely zero'd" by whom ? this documentation would be read by ffmpeg developers too ...
[21:33:00 CET] <jamrial> no, leave it as avbufferref. casting it everywhere will add pointless complexity to what's otherwise going to be simple code
[21:33:13 CET] <BtbN> And it can't be safely zeroed. It has to be freed
[21:33:25 CET] <atomnuker> okay, I guess it can be avbufferref
[21:33:37 CET] <atomnuker> "Can be safely zero'd by API users" then?
[21:33:49 CET] <michaelni> atomnuker, yes
[21:33:56 CET] <BtbN> API users should not need to care about the existence of that field in any way
[21:33:57 CET] <atomnuker> and lets add a note for developers it'll be automatically unref'd
[21:34:07 CET] <BtbN> It already has that?
[21:34:57 CET] <atomnuker> BtbN: they should know what its for, why they shouldn't touch it and why they'll be safe when passing avframes with it unset
[21:35:08 CET] <atomnuker> otherwise they'll use it and it'll break eventually
[21:35:18 CET] <atomnuker> or they'll think they need to preserve it
[21:35:41 CET] <atomnuker> and they'll go to extraordinary lengths to move around a NULL in their internal avframe-like structures
[21:36:45 CET] <atomnuker> okay, so ""Field for temporary usage inside the project libraries only, does not get used anywhere outside. Can be safely zero'd by API users, however for private storage users must use opaque_ref instead."?
[21:37:58 CET] <atomnuker> and "For project developers: this field is automatically unref'd after its no longer needed." on another line
[21:38:30 CET] <BtbN> It already does say that it's automatically copied/unrefed
[22:25:23 CET] <llogan> atomnuker: is the "kind benefactor"? i was going to re-tweet but wanted to mention name unless I should for any reason.
[22:25:29 CET] <llogan> *pkviet
[22:25:51 CET] <llogan> *shouldn't
[22:26:03 CET] <llogan> brain and fingers don't work well together
[22:26:07 CET] <atomnuker> yeah, pkviet (pkv.stream)
[22:26:22 CET] <atomnuker> he doesn't mind, but 2 people seem to be using that email address
[22:26:35 CET] <llogan> that's odd
[22:29:29 CET] <atomnuker> yeah, the other one's nick is "Kv Pham"
[22:30:06 CET] <llogan> whoops. already tweeted.
[22:32:17 CET] <atomnuker> its alright, pkviet's the nick that did the work
[22:33:19 CET] <atomnuker> I suppose in the future when everyone clones themselves we'll have to get used to this :)
[22:40:09 CET] <nevcairiel> jkqxz: speaking about platform decoding and GPU encoding, I don't suppose you have any clue if nvenc accepts dxva2 or d3d11 surfaces? Or BtbN maybe?
[22:40:38 CET] <BtbN> nvenc does have some DirectX stuff iirc
[22:40:42 CET] <BtbN> let me check
[22:42:04 CET] <jkqxz> That would make the paths easier on Windows at least, because you could use the same code except for the encoder.
[22:42:05 CET] <nevcairiel> I already have some infra for dxva2/d3d11 decoding in place, so it would be best to be able to use zero copy decoding with that, instead of adding cuvid decoding
[22:42:07 CET] <jkqxz> (I've no idea, though.)
[22:42:50 CET] <BtbN> nevcairiel, https://github.com/FFmpeg/FFmpeg/blob/master/compat/nvenc/nvEncodeAPI.h#L649
[22:44:11 CET] <nevcairiel> A quick Google suggest it should be possible, maybe I'll wip up a patch
[22:44:21 CET] <BtbN> Only DirectX9 though
[22:44:25 CET] <BtbN> no idea how compatible that is
[22:45:11 CET] <BtbN> nevcairiel, the biggest problem would be, in order for nvenc to accept directx input surfaces, it needs to be created on top of a directx context, instead of a cuda one
[22:45:52 CET] <nevcairiel> Well we have a dxva2 hwcontext
[22:45:52 CET] <BtbN> But with the current hw_frames_ctx stuff, even that shouldn't be too crazy
[22:47:45 CET] <BtbN> https://github.com/loskutov/VideoCapture/blob/master/src/NvencEncoder.cpp#L13 comes up in a random google search, and it successfully uses a D3D11DecivePtr
[22:48:23 CET] <nevcairiel> Worst case I could copy the D3d11 texture to cuda memory, still much better then CPU copy
[22:48:45 CET] <BtbN> It should be 100% possible to use nvenc with d3d11 stuff
[22:48:52 CET] <BtbN> Very curious how it turns out
[22:49:06 CET] <nevcairiel> I'll give it a try
[22:49:25 CET] <nevcairiel> Been pushing the hw encoding stuff for too long
[22:50:57 CET] <BtbN> can ffmpeg.c use d3d11va?
[22:51:32 CET] <nevcairiel> Yes
[22:51:48 CET] <BtbN> So this should actually be super easy to test and everything
[22:52:04 CET] <BtbN> Only thing I'm unsure about is pixel formats inside of d3d textures, as I lack experience with how they work
[22:52:18 CET] <BtbN> Or does it just not matter, as it's a Texture and nvenc will know how to access it?
[22:52:32 CET] <nevcairiel> Straight from a decoder it's just nv13
[22:52:37 CET] <nevcairiel> Nv12
[22:52:41 CET] <BtbN> in a texture?
[22:52:41 CET] <nevcairiel> Or p010
[22:53:00 CET] <nevcairiel> Yeah d3d11 added those as full texture formats
[22:53:13 CET] <BtbN> I guess the sw_pix_fmt is properly set, so stuff will just work
[22:53:28 CET] <nevcairiel> It does away with the separation of surfaces and textures that D3d9 had
[22:53:55 CET] <BtbN> I guess it will need some poking around to figure out what references nvenc expects
[22:54:02 CET] <BtbN> But d3d11 looks supported
[22:55:18 CET] <BtbN> ID3DTexture2D is what it expects it seems
[22:56:03 CET] <nevcairiel> Yeah that's what the decoder gives you as well
[22:56:24 CET] <nevcairiel> Although hopefully it accepts array textures properly
[22:58:15 CET] <jkqxz> Ha, yes.  That's still outstanding for libmfx.  An Intel person said that noone had asked for array texture input before, which I found a bit wtf since it's what the decoder has to use.
[23:00:32 CET] <nevcairiel> Ah nvenc has a subResourceIndex field, hope is alive
[23:01:46 CET] <BtbN> "Subresource Index of the DirectX resource to be registered."
[23:01:50 CET] <BtbN> I'd guess so
[23:02:05 CET] <nevcairiel> Zero-copy encoding through d3d11 and nvenc would definitely make my life easier
[23:02:26 CET] <BtbN> It really does not look crazy to do at all to me
[23:02:31 CET] <BtbN> should not even be a big patch
[23:02:41 CET] <nevcairiel> Only missing piece in between might be a d3d11 scaler
[23:02:50 CET] <nevcairiel> But even that might not be too crazy
[23:05:42 CET] <BtbN> Pretty much just a shader
[23:06:26 CET] <nevcairiel> Was more thinking of using the video processing API and also get deint
[23:06:42 CET] <BtbN> That exists for d3dva?
[23:06:49 CET] <nevcairiel> Of course
[23:07:16 CET] <BtbN> Well, in theory it also exists for CUDA. Within cuvid. But nvidia won't fucking tell anyone how to use it.
[23:08:57 CET] <nevcairiel> I should check my work schedule if I can do it on paid time anytime soon
[00:00:00 CET] --- Fri Nov 10 2017