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

[burek]

[03:15:09 CET] <raphieps> hey all! I'm using ffmpeg to convert a video file into individual PNG frames for further, parallelized analysis in OpenCV. I figure my code is wasting a lot of time encoding, decoding, and reading the PNG's. is there a way to have ffmpeg spit out a single, big mmap'able file containing the raw RGB pixels? or some established best practice for this sort of thing?
[03:16:25 CET] <furq> -c:v rawvideo will just be the (yuv or rgb) pixel data
[03:16:48 CET] <furq> it doesn't store the framerate or frame size though so you'll need to pass that to the decoder
[03:19:46 CET] <raphieps> amazing - how would I force it to output RGB and not YUV?
[03:20:14 CET] <furq> it'll be rgb if that's the input colourspace
[03:20:19 CET] <furq> otherwise -vf format=rgb24
[03:22:57 CET] <raphieps> great! only one problem: it's erroring "Unable to find a suitable output format for 'output.raw'"
[03:23:11 CET] <raphieps> here's my command: ffmpeg -i longerscan.mov -c:v rawvideo -vf format=rgb24 output.raw
[03:24:38 CET] <raphieps> ah, turns out I needed to pass output.rgb instead. thank you so much furq!!
[12:16:31 CET] <zamba> i'm using ffmpeg to capture to file.. is there a way i can also output to screen so i can see when the capture is done?
[12:17:54 CET] <durandal_1707> zamba: can't you open file with player?
[12:18:31 CET] <zamba> durandal_1707: no, just shows gibberish as long as the capture is running
[12:19:16 CET] <durandal_1707> zamba: to what container are you capturing?
[12:19:21 CET] <zamba> mp4
[12:19:46 CET] <DHE> hmm... codec permitting, tee to mpegts on a socket and watch the socket?
[12:20:09 CET] <durandal_1707> or nut
[12:20:41 CET] <DHE> nut is stream-friendly?
[12:20:44 CET] <zamba> DHE: command?
[12:21:23 CET] <DHE> http://ffmpeg.org/ffmpeg-formats.html#tee-1
[12:21:36 CET] Action: DHE backstabs Chrome for being clipboard-quirky on linux
[12:22:41 CET] <pos> https://pastebin.mozilla.org/9080290
[12:23:06 CET] <pos> doesn't look all that good with height 540 and ofc only half the screen at 270
[12:24:22 CET] <durandal_1707> pos: what's your monitor resolution?
[12:27:04 CET] <pos> 1080
[12:27:27 CET] <durandal_1707> then buy something better :)
[12:27:51 CET] <pos> i meant to say, the output looks mangled at height 540
[12:29:33 CET] <pos> only two rows, height should be 540, no?
[12:30:06 CET] <durandal_1707> yes
[12:30:49 CET] <pos> that ofc doesn't jive well with width=480 if the source is 16:9
[12:31:00 CET] <durandal_1707> it still will look bad if input is HD
[12:31:03 CET] <pos> i'm guessing that isn't entirely unrelated to the issue :)
[12:31:47 CET] <pos> when i say mangled i mean that i get a letterboxing effect where the border are filled with expanded parts of the sources
[12:33:05 CET] <pos> the playback frames also start freezeing after a few seconds, then start playing again at what looks to be random intervals
[12:33:20 CET] <pos> may have to do with ffmpeg wanting to cache them?
[12:33:25 CET] <durandal_1707> and CPU usage is?
[12:33:38 CET] <pos> 7400
[12:33:49 CET] <durandal_1707> if it is high usage, your CPU is weak
[12:34:03 CET] <pos> my bad, that was the model
[12:34:13 CET] <pos> cpu usage is inconsequential
[12:34:28 CET] <pos> as in very low
[12:36:48 CET] <durandal_1707> pos: it could be pts stuff AND small cache
[12:37:37 CET] <durandal_1707> you want REALTIME stuff but framesync (which vstack/hstack use) was never designed for such situations
[12:39:43 CET] <pos> what about the old pad and overlay stuff?
[12:40:58 CET] <durandal_1707> same, also uses framesync and is slower, because needs more horsepower to do same thing
[12:41:09 CET] <pos> any other suggestions? vlc is quite capable of creating the mosaic but doesn't really do -c:v
[12:41:36 CET] <durandal_1707> pos: if this is vlc bug, report it to vlc developers
[12:41:40 CET] <pos> alas, the is a bug in some vlc dependancy which causes my old stuff to not work on xenial
[12:42:15 CET] <durandal_1707> pos: how one enable this mosaic thing in VLC?
[12:44:00 CET] <pos> custom vlm script
[12:44:38 CET] <pos> https://wiki.videolan.org/VLC_HowTo/Make_a_mosaic/
[12:48:25 CET] <durandal_1707> pos: mpv can have big cache
[12:57:57 CET] <durandal_1707> pos: mpv 1 --external-file=2 --external-file=3 --external-file=4 --lavfi-complex "[vid1]scale=vga,setpts=PTS-STARTPTS[v1];[vid2]scale=vga,setpts=PTS-STARTPTS[v2];[vid3]scale=vga,setpts=PTS-STARTPTS[v3];[vid4]scale=vga,setpts=PTS-STARTPTS[v4];[v1][v2]hstack[t];[v3][v4]hstack[b],[t][b]vstack[vo]"
[13:07:50 CET] <pos> seemingly fails when using rtsp as sources
[13:08:45 CET] <durandal_1707> pos: fails in which way?
[13:08:53 CET] <pos> https://pastebin.mozilla.org/9080307
[13:09:09 CET] <pos> Error parsing option external-file (option not found)
[13:09:23 CET] <pos> Setting command line option '--external-file=rtsp://1.2.3.4/live' failed.
[13:09:58 CET] <durandal_1707> pos: your mpv is extremly old
[13:11:16 CET] <pos> apparently so :)
[13:11:35 CET] <pos> mpv 0.14.0
[13:13:43 CET] <pos> anyway, using ffmpeg for input is prolly for the best, that way i should have more options on hand re customizations like borders etc
[13:14:16 CET] <pos> now, if it could only be convinced not to buffer the inputs
[13:24:56 CET] <pos> hmm, when doing inputs with ffmpeg and piping it to mpv or mplyer the top left frame always hangs every five secs
[13:25:04 CET] <pos> even if all four frames are from the same source
[13:40:58 CET] <pos> sh, there we go
[14:22:21 CET] <pos> i've got up running, stable
[14:22:49 CET] <pos> but, eh. there seems to be something i'm missing re hstacking and vstacking
[14:25:13 CET] <pos> https://pastebin.mozilla.org/9080309
[14:25:49 CET] <pos> i would've though with a 4x4 grid one should just divide 1920 and 1080 and you'd get a fullscreen image?
[14:34:31 CET] <pos> with the paste above i get the right height but not width
[14:42:01 CET] <Kam_> Hi, I'm trying to compile FFmpeg with '--enable-libvorbis --extra-cflags=-I/path/to/vorbis/include --extra-ldflags=-L/path/to/vorbis/lib' in the same way I do sucessfully with --enable-libvpx and --enable-zlib, but configure complains about not finding vorbis: "ERROR: vorbis not found using pkg-config".  What am I doing wrong?
[14:42:31 CET] <BtbN> libvorbis requires pkg-config
[14:42:39 CET] <BtbN> make sure it finds its .pc file, and you'll be fine
[14:43:19 CET] <Kam_> pkg-config is on the system, how can I make sure that it finds the .pc file? it is in /path/to/vorbis/lib/pkgconfig
[14:43:29 CET] <BtbN> set the pkg-config path correctly
[14:44:40 CET] <pos> also, make sure you've updated libvorbis in the last few days :)
[14:47:45 CET] <Kam_> it is from yesterdays git master :)
[14:49:28 CET] <Kam_> hmm.. I've set 'export PKG_CONFIG_PATH=/path/to/vorbis/lib/pkgconfig' before configure, but it still complains
[15:01:19 CET] <pos> ah, both mplayer and mpv will have to be told the aspect
[15:01:26 CET] <pos> -aspect 16:9
[15:06:07 CET] <tester> i'm trying to use ffmpeg -f mpegts -i "concat:*.ts" -c copy -bsf:a aac_adtstoasc output.mkv
[15:06:13 CET] <tester> i'm getting concat:*.ts: Invalid argument
[15:06:32 CET] <tester> the goal is to put a bunch of .ts files into a single mkv
[15:09:21 CET] <tester> apparently i need the files listed with "concat:1.ts|2.ts|3.ts..."
[15:09:22 CET] <tester> damn it.
[15:09:22 CET] <Kam_> tester, afaik concat takes a text file that contains a list of input files
[15:09:34 CET] <tester> Kam_ example?
[15:10:10 CET] <Kam_> tester, the manual describes how it looks like: https://ffmpeg.org/ffmpeg-all.html#concat-1
[15:10:36 CET] <Kam_> there is an example when you scroll down
[15:11:21 CET] <tester> okay thanks
[15:12:41 CET] <Kam_> I've no idea how to do it like you wanted to do it, I think the order of files would be an issue.  close comes 'image2', but that probably for image files only.
[15:16:36 CET] <furq> there are three different concat methods
[15:16:39 CET] <furq> https://trac.ffmpeg.org/wiki/Concatenate
[15:19:09 CET] <Kam_> on the terminal 'pkg-config --modversion vorbis' finds libvorbis; configure doesn't?
[15:19:45 CET] <furq> Kam_: check config.log
[15:19:59 CET] <furq> "not found using pkg-config" usually doesn't actually mean that
[15:24:28 CET] <Kam_> config.log: https://pastebin.com/Ap0ngJkv
[15:48:20 CET] <pos> furq, https://pastebin.mozilla.org/9080312 is working swell, thanks
[15:49:15 CET] <pos> was looking into https://video.stackexchange.com/questions/18419/add-black-or-other-color-padding-when-doing-vstack-or-hstack, any suggestions as to how it could be worked in to the prev paste?
[15:52:28 CET] <durandal_1707> pos: it can't be worked, you will get more and more spaghetti lines
[15:54:35 CET] <pos> i'm tellin' ya, works just fine atm
[15:55:42 CET] <durandal_1707> pos: watch it all bombs out when rstp suddenly do pts jump
[16:15:24 CET] <pos> durandal_1707, running long test now
[17:03:04 CET] <Kam_> I tracked down my issue: --extra-ldflags='-static' causes configure to complain/not to find libvorbis.  what can I do?
[17:04:54 CET] <JEEB> if you require static libs and you think you have it and you're using pkg-config, you need to add "-static" to the pkg-config options
[17:05:19 CET] <JEEB>  --pkg-config-flags=FLAGS pass additional flags to pkgconf []
[17:05:26 CET] <JEEB> so static there
[17:06:31 CET] <Kam_> I'll try that.  my goal is to build a shared ffmpeg, but not requring shared libs from gcc (e.g. pthreads, libstdc++).
[17:10:38 CET] <furq> do you not just want -static-libgcc -static-libstdc++ then
[17:11:15 CET] <Kam_> --extra-ldflags='-static' --pkg-config-flags='--static' doesn't work
[17:11:52 CET] <JEEB> show the failure from ffbuild/config.log then in a pastebin or so
[17:12:11 CET] <JEEB> although I will bet it's just you not having a static libvorbis or so?
[17:12:16 CET] <JEEB> (or the pc file sucking)
[17:12:25 CET] <furq> if you want a dynamic libvorbis then -static is no good to you
[17:12:29 CET] <Kam_> libvorbis and ogg are static only
[17:12:39 CET] <furq> nvm then
[17:12:51 CET] <Kam_> no, I want to have everything static, but ffmpeg itself shall be dynamic
[17:13:04 CET] <furq> right
[17:13:27 CET] <sfan5> then you don't want --extra-ldflags='-static'
[17:14:20 CET] <Kam_> I'll try with -static-libgcc etc. then.  what would ldflags -static do?  it worked so far in the past few month, until I want to add libvorbis to it.
[17:15:16 CET] <JEEB> "only take in static libraries" generally for the linker
[17:15:44 CET] <sfan5> -static will link everything statically, that includes libc libgcc libm [...]
[17:15:53 CET] <Kam_> sounds like what I want, to only consider static libs
[17:15:57 CET] <sfan5> the ffmpeg produced would not be dynamic
[17:16:11 CET] <JEEB> pretty sure if you output .so you will get a shared lib?
[17:16:19 CET] <JEEB> just that all deps linked are static
[17:16:31 CET] <sfan5> not sure what that does on .so files
[17:16:54 CET] <JEEB> although I do wonder if it also links the sister libs (libav*) into the SO libraries statically :P
[17:17:14 CET] <Kam_> I'm linking the produced .so/.dlls against another software, so I suppose they were dynamic so far.
[17:17:28 CET] <FishPencil> Is there a way to format filter results? I need SIMM and PSNR results in comma separated format. I can parse the command output, but I'm wondering if there's a more native way
[17:18:19 CET] <JEEB> I'm not 100% sure, but I think the results are output as AVFrames with side data?
[17:18:33 CET] <JEEB> the "output to a file" stuff is just a hack in the ssim filter, for example
[17:19:02 CET] <JEEB> so the proper way would be to get that side data (given it exists) and parsing those values accordingly and writing in  a format you need
[17:19:40 CET] <JEEB> so if you need it with ffmpeg.c you'd write a patch to ffmpeg.c to properly output PSNR/SSIM results into a file in some way
[17:20:24 CET] <FishPencil> Just using the command line right now, going into the API is going to be more work than parsing the stdout
[17:20:42 CET] <durandal_1707> JEEB: output to file is NOT fucking HACK
[17:21:14 CET] <JEEB> it is
[17:21:21 CET] <JEEB> it should be parsed from the output AVFrame
[17:21:31 CET] <JEEB> and then the API client can handle the writing
[17:21:39 CET] <durandal_1707> nonsense
[17:21:50 CET] <JEEB> I know it's simpler to just hack around that and write to a file from a filter
[17:21:55 CET] <JEEB> and not think about the big picture
[17:22:36 CET] <durandal_1707> nonsense
[17:22:43 CET] <JEEB> what is nonsense?
[17:23:12 CET] <JEEB> FishPencil: anyways at least the ssim filter has "write stats into a file" option, so you don't need to parse stderr :P
[17:24:02 CET] <JEEB> durandal_1707: I mean, the hack might or might have not made sense when it was made, but generally it is circuimventing the idea of adding that information into the filter chain and utilizing the result of the filter through it
[17:26:39 CET] <JEEB> and I'm not trying to insult you, I've done my share of things that might have not been the best of ideas in the end looking at it months/years later :P
[17:27:06 CET] <JEEB> ok, ssim doesn't seem to export the values through side data
[17:27:59 CET] <JEEB> durandal_1707: do you happen to know how you're supposed to utilize the results of the SSIM filter as an API client?
[17:28:36 CET] <JEEB> oh it adds metadata
[17:28:46 CET] <JEEB> yes, that makes sense
[17:35:31 CET] <Kam_> new config.log: https://pastebin.com/3GY918jh -- it looks like it doesn't pick up libogg
[17:36:19 CET] <JEEB> add -lm and -logg to Libs.private in the pkg-config .pc file
[17:36:45 CET] <JEEB> since it seems to fail to find the math lib and libogg
[17:37:35 CET] <FishPencil> or export pkg_config="pkg-config --static"
[17:38:01 CET] <JEEB> he already has that
[17:38:21 CET] <JEEB> or at least I told him how to set it with FFmpeg's configure :P
[17:38:31 CET] <JEEB> --pkg-config-flags=FLAGS pass additional flags to pkgconf []
[17:39:17 CET] <JEEB> also I'm not sure if FFmpeg's configure takes into mention PKG_CONFIG , it has "--pkg-config=PKGCONFIG   use pkg-config tool PKGCONFIG [pkg-config]" instead :P
[17:39:53 CET] <FishPencil> JEEB: it does
[17:40:07 CET] <FishPencil> that export forces including the private libs
[17:40:27 CET] <JEEB> so does --pkg-config-flags="-static" which I mentioned to him before
[17:40:46 CET] <JEEB> the specifics here is that libvorbis seems to then lack the Libs.private :P
[17:40:47 CET] <FishPencil> also true
[17:40:54 CET] <JEEB> rather than "Libs.private is there but not used"
[17:42:12 CET] <JEEB> Kam_: I think you should report this to xiph I think? if they don't have Libs.private set properly in case of static build
[17:42:24 CET] <JEEB> it's not simple to make perfect, but at the very least they could have added libogg there :P
[17:51:46 CET] <Kam_> re-added --pkg-config-flags='--static' works (so does 'export pkg_config=...')
[17:52:19 CET] <JEEB> oh so that was without pkg-config --static :P
[17:52:26 CET] <JEEB> then it might have had Libs.private in there
[17:52:47 CET] <Kam_> Libs.private in vorbis.pc lists -lm only
[17:52:56 CET] <JEEB> ok, and it links?
[17:52:59 CET] <JEEB> as in, configure finishes
[17:53:02 CET] <Kam_> but has 'Requires.private: ogg'
[17:53:05 CET] <JEEB> or it still complains about libogg
[17:53:06 CET] <JEEB> right
[17:53:09 CET] <JEEB> then it has both
[17:53:18 CET] <JEEB> --static in pkg-config brings both out
[17:53:41 CET] <Kam_> configure finishes, I'm gradually adding the others things now and see whether I face any trouble
[18:41:17 CET] <FishPencil> How do I take three input videos and horizontally stack them? ffmpeg -i a.mp4 -i b.mp4 c.mp4 -vf hstack=inputs=3 o.mp4 results in:
[18:41:18 CET] <FishPencil> Simple filtergraph 'hstack=inputs=3' was expected to have exactly 1 input and 1 output. However, it had >1 input(s) and 1 output(s).
[18:42:27 CET] <FishPencil> + -i before c.mp4
[18:43:08 CET] <durandal_1707> FishPencil: substitute -vf with -lavfi
[18:49:44 CET] <FishPencil> curious
[20:48:14 CET] <Kam_> I'm cross-compiling unix to windows (gcc-mingw64), when I add '--target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --enable-cross-compile --arch=x86' to configure, it complains again about not finding libvorbis. :(  'pkg-config --modversion vorbis' will find vorbis.  What am I missing?  config.log: https://pastebin.com/NKKjUeJK
[20:49:25 CET] <JEEB> have you set PKG_CONFIG_LIBDIR correctly to be in your cross-prefix sysroot's lib/pkgconfig ?
[20:49:34 CET] <JEEB> and that you have that libvorbis et al for that
[20:49:42 CET] <BtbN> is arch=x86 even valid for x86_64?
[20:50:19 CET] <JEEB> right, just checked my params
[20:50:20 CET] <JEEB> --arch=x86_64 --enable-cross-compile --target-os=mingw64 --cross-prefix="x86_64-w64-mingw32-"
[20:50:36 CET] <JEEB> this is what i use for mingw-w64 cross-compilation to 64bit
[20:50:51 CET] <Kam_> not PKG_CONFIG_LIBDIR, I'll have a look at that. arch=x86 should be for x86_64, I've made that sure a few month ago and everything works without libvorbis.
[20:51:35 CET] <JEEB> also you might need --pkg-config=pkg-config to stop it warning that it might not find the stuff you want (as long as you're setting PKG_CONFIG_LIBDIR)
[20:51:51 CET] <JEEB> otherwise it's a very similar exersize to linux building
[20:53:37 CET] <JEEB> and yea, that seems to be a thing regarding it wanting cross-prefix-pkg-config so it uses "false" instead of pkg-config to mark that there's no cross-prefix-pkg-config (which usually is a shell script that sets PKG_CONFIG_LIBDIR according to your sysroot)
[20:54:30 CET] <JEEB> also generally if you are using pkg-config you generally don't need to add the manual -L flags, those are picked from the .pc files that get generated when you `make install` the dependency libraries
[20:54:39 CET] <JEEB> although I still haven't sent in the patch for zlib
[20:54:49 CET] <JEEB> so that's the only thing I still need the -L and -I for :<
[20:55:03 CET] <JEEB> for some reason there's no pkg-config check for it even though zlib provides it
[20:55:15 CET] <Kam_> I'd prefer not to have to use pkg-config.
[20:55:37 CET] <JEEB> well it's explicitly for the use cases of picking linking and inclusion parameters
[20:55:53 CET] <JEEB> I don't see how it is better than coming up with the dependency flags by yourself
[20:56:57 CET] <JEEB> as long as your PKG_CONFIG_PATH (when not cross-compiling, as it just appends) and PKG_CONFIG_LIBDIR (overrides the whole search path) are set, it works as long as the projects make their .pc files properly (which thankfully quite a few seem to do)
[20:57:54 CET] <JEEB> I'm using it for *nix, mingw-w64 and android compilation, and probably would use it for even more if required.
[20:58:48 CET] <Kam_> wouldn't PKG_CONFIG_SYSROOT_DIR work/be better?
[20:59:18 CET] <sfan5> pretty sure you need to set both
[20:59:36 CET] <JEEB> umm, I haven't looked into that one, might do some additional things that might or might not be required. I have my own cross-prefix sysroot in addition to the toolchain's default sysroot search paths. the main thing PKG_CONFIG_LIBDIR does is it resets the search path for .pc files
[20:59:45 CET] <JEEB> not sure what the sysroot one would do even more?
[21:00:03 CET] <sfan5> hm wait
[21:00:46 CET] <sfan5> LIBDIR is needed so it find the .pc files
[21:00:59 CET] <sfan5> SYSROOT_DIR is needed so it can modify include paths correctly
[21:01:02 CET] <JEEB> yes, and the toolchains I've used have the sysroot available for them by default
[21:01:05 CET] <furq> fwiw i don't think you need to bother setting --arch
[21:01:25 CET] <furq> my crossbuilt binaries just have cross-prefix and target-os
[21:01:43 CET] <JEEB> that in theory should be enough, yes
[21:01:47 CET] <JEEB> cross-prefix is for the tools
[21:01:57 CET] <JEEB> and target os gives some hint which system the compilation's going for
[21:02:06 CET] <Kam_> furq, you're probably relying on configure to autodetect it.  I wanted to set it explicitly.
[21:02:16 CET] <sfan5> >    test -n "$arch" && test -n "$target_os" || die "Must specify target arch (--arch) and OS (--target-os) when cross-compiling"
[21:02:38 CET] <sfan5> though maybe it can autodetct it
[21:02:49 CET] <JEEB> yea, I remember hitting that at various points
[21:03:29 CET] <JEEB> Kam_: as far as I can tell PKG_CONFIG_LIBDIR is the primary thing you care about
[21:03:35 CET] <furq> you probably need it if you're actually compiling for another arch
[21:03:44 CET] <furq> although i'm not setting it on i686 builds from amd64
[21:03:50 CET] <furq> actually i should check that
[21:04:27 CET] <JEEB> oh
[21:04:29 CET] <JEEB> it's like a prefix
[21:04:46 CET] <JEEB> so if you're using a cross-compilation sysroot which originally was located in /usr or something
[21:04:50 CET] <JEEB> and the .pc files are aimed at that
[21:05:04 CET] <sfan5> yeah that's why you should set it
[21:05:09 CET] <JEEB> you can set PKG_CONFIG_SYSROOT_DIR and it will prepend it
[21:05:17 CET] <sfan5> it can work without if you're lucky
[21:05:19 CET] <JEEB> sfan5: I can see that back-firing if your .pc files already have correct paths
[21:05:20 CET] <furq> PKG_CONFIG_PATH prepends to the existing path doesn't it
[21:05:27 CET] <JEEB> furq: *search* path
[21:05:34 CET] <JEEB> this is the received paths in -I/-L
[21:05:53 CET] <JEEB> "PKG_CONFIG_SYSROOT_DIR variable, which is set to the path of the sysroot, and is inserted in-between the -I or -L flags and the following path."
[21:05:57 CET] <JEEB> https://autotools.io/pkgconfig/cross-compiling.html
[21:05:59 CET] <furq> 19:56:57 ( JEEB) as long as your PKG_CONFIG_PATH (when not cross-compiling, as it just appends)
[21:06:02 CET] <furq> i meant this
[21:06:07 CET] <sfan5> JEEB: sure but I wouldn't consider it "clean" to have /home/whatever/my_toolchain/sysroot/usr/include hardcoded in your .pc's
[21:06:24 CET] <JEEB> sfan5: yes if you plan on distributing the sysroo
[21:06:27 CET] <JEEB> *sysroot
[21:06:43 CET] <JEEB> my --prefix is always in the homedir somewhere and the .pc files have it there
[21:07:03 CET] <sfan5> I had to make it stop doing this when travis was added (https://git.io/vx3z2)
[21:07:24 CET] <JEEB> makes sense
[21:07:36 CET] <JEEB> when distributing your cross-sysroots it makes very much sense
[21:07:50 CET] <JEEB> just that for a random home builder it kind of matters much less
[21:07:52 CET] <sfan5> it's also a lot cleaner :P
[21:08:04 CET] <JEEB> sure
[21:08:30 CET] <JEEB> what was the thing during make install that let you install into another root?
[21:08:46 CET] <JEEB> so you can have --prefix= as /usr/ but install into /home/blah
[21:09:06 CET] <JEEB> it's usually implemented in various packages' makefiles because binary packaging usually utilizes it
[21:09:08 CET] <sfan5> DESTDIR
[21:09:14 CET] <JEEB> right, DESTDIR
[21:09:14 CET] <JEEB> yes
[21:09:39 CET] <furq> does that actually work
[21:09:51 CET] <sfan5> it does
[21:09:53 CET] <furq> i'm apparently using make install-progs prefix=$(PREFIX)
[21:10:10 CET] <JEEB> furq: FFmpeg is part of the commit that sfan5 just linked
[21:10:15 CET] <JEEB> so yea, it works
[21:11:25 CET] <furq> fun
[21:38:41 CET] <Kam_> adding --pkg-config=pkg-config works, no need to set PKG_CONFIG_LIB etc., only PKG_CONFIG_PATH is enough.
[21:42:12 CET] <JEEB> Kam_: umm
[21:42:16 CET] <JEEB> that will append, yes
[21:42:22 CET] <JEEB> but you don't want your native libraries
[21:42:28 CET] <JEEB> so PKG_CONFIG_LIBDIR
[21:42:30 CET] <JEEB> is needed
[21:42:36 CET] <JEEB> (for cross-compilation)
[21:42:40 CET] <JEEB> PKG_CONFIG_PATH appends
[21:42:54 CET] <JEEB> PKG_CONFIG_LIBDIR resets and adds what you set only
[21:42:59 CET] <furq> PKG_CONFIG_PATH prepends
[21:44:06 CET] <Kam_> no, true, I don't want to mix anything from the system I'm working on into this. where do I have to point the PKG_CONFIG_LIBDIR to, then?
[21:44:40 CET] <furq> the same thing you would set PKG_CONFIG_PATH to
[21:44:53 CET] <Kam_> ok
[21:46:04 CET] <JEEB> but yea, given how PATH works it's not exactly the same :P
[21:46:14 CET] <Kam_> shall I omit PKG_CONFIG_PATH then?
[21:46:19 CET] <furq> you only need one or the other
[21:46:56 CET] <furq> also apparently some implementations of pkg-config do append
[21:47:05 CET] <furq> the freedesktop.org one prepends, but freebsd pkgconf appends
[21:47:18 CET] <furq> so yeah probably best to avoid that
[21:59:01 CET] <azarus> I'd like to have fast VP9 encodes, currently I'm using this commandline: "ffmpeg -i pipe:0 -c:v libvpx-vp9 -crf 31 -b:v 0 -threads 8 -speed 4 -c:a libopus out.webm", anything more I can add to make it faster?
[21:59:16 CET] <azarus> I tried -deadline realtime, but it seems to make it slower?
[22:00:09 CET] <BtbN> vp9 won't be fast
[22:00:13 CET] <JEEB> better to ask the libvpx people since that's their encoder
[22:00:20 CET] <JEEB> but yes, it's generally not fast
[22:01:43 CET] <azarus> Hrm. x265 somehow looks bad to me, using these test images: https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/
[22:01:55 CET] <azarus> and it seems to me, those encode times are not realistic
[22:02:47 CET] <BtbN> they seem reasonable to me
[22:07:24 CET] <azarus> -cpu-used seems to help somewhat
[22:14:21 CET] <Kam_> azarus, does it actually use multiple cores?  I remember having to set -tile-columns=8 or something like that to make use of it.
[22:14:51 CET] <furq> azarus: make sure your ffmpeg has the latest libvpx and use row-mt
[22:14:51 CET] <azarus> Kam_: seems to use about 4 of my 8 threads
[22:15:15 CET] <furq> also yeah that page is using x265 preset medium
[22:15:23 CET] <furq> which is about the same speed as x264 veryslow
[22:15:25 CET] <azarus> furq: what's the syntax for row mt?
[22:15:42 CET] <furq> -row-mt 1 iirc
[22:15:49 CET] <Kam_> oh, the manual says set -tile-columns=3 to get 8 tiles
[22:17:21 CET] <azarus> furq: since what version is row-mt supported?
[22:17:26 CET] <furq> 1.6.2
[22:17:33 CET] <azarus> Ah, ok
[22:17:35 CET] <azarus> Thanks
[22:17:46 CET] <furq> or oh
[22:17:47 CET] <furq> uh
[22:17:49 CET] <furq> 1.7.0
[22:17:52 CET] <furq> 1.6.2 never got released
[22:18:45 CET] <azarus> Compiling 1.7.0 right now
[22:19:12 CET] <furq> i forget if you're supposed to disable tile-columns with row-mt
[22:19:20 CET] <furq> i've never really paid much attention to vpx
[22:19:51 CET] <azarus> time for some experimentation?
[22:20:00 CET] <azarus> or is it documented somewhere? :P
[22:20:02 CET] <furq> TD-Linux: hi
[22:20:57 CET] <azarus> the wiki doesn't even mention -row-mt
[22:22:06 CET] <azarus> Oh, -row-mt seems to be stressing all my 8 threads much more
[22:22:34 CET] <furq> yeah the vpx docs are absolutely terrible
[22:23:17 CET] <furq> apparently tile-columns needs to be >1
[22:23:20 CET] <furq> thanks, mailing list post
[22:23:38 CET] <azarus> Okay, i've set that
[22:23:40 CET] <furq> or >=1 rather
[22:23:52 CET] <azarus> i'm trying 3
[22:24:04 CET] <Kam_> hm, I have to keep '--extra-cflags=-I/path/to/vorbis/include' when I set PKG_CONFIG_SYSROOT_DIR , otherwise it complains.
[22:26:05 CET] <furq> you really shouldn't need to set that
[22:28:11 CET] <Kam_> here is the log https://pastebin.com/hRhiguuJ
[22:30:04 CET] <Kam_> ah, it prepended PKG_CONFIG_SYSROOT_DIR to the whole path where /path/to/vorbis is located :-/
[22:30:12 CET] <sfan5> you built libvorbis with --prefix so it did the above ^
[22:30:23 CET] <JEEB> yes, if you set --prefix don't use SYSROOT_DIR
[22:30:24 CET] <sfan5> also libvorbis is not in your sysroot, so even if it did that correctly it wouldn't work
[22:30:36 CET] <sfan5> unset SYSROOT_DIR and it should work
[22:31:06 CET] <Kam_> can I be sure that it will never try to include files from the system?
[22:31:40 CET] <sfan5> no
[22:31:51 CET] <JEEB> it shouldn't find anything from your usual sysroot with pkg-config because you set PKG_CONFIG_LIBDIR
[22:32:15 CET] <sfan5> yes but a .pc file might include -I/usr/include for some dumb reason
[22:32:38 CET] <JEEB> otherwise unless something has hardcoded your standard (non cross-prefix) sysroot somewhere and your toolchain properly sets its include/lib search paths
[22:32:48 CET] <JEEB> well yea, I haven't had that dumb shit so far, thankfully
[22:32:56 CET] <JEEB> otherwise my cross-compilation would be much less fun
[22:34:11 CET] <Kam_> ah ok I understand.  I'd consider that a bug if it'd be hardcoded anywhere.
[22:35:59 CET] <Kam_> is there any special reason that vorbis requires pkgconfig, shall I change my configuration line for libvpx and zlib, too?
[22:36:50 CET] <JEEB> generally anything that needs any deps and uses pkg-config to find them would better have that
[22:36:58 CET] <JEEB> zlib for example is so basic that it just doesn't need any
[22:37:11 CET] <JEEB> on the other hand, I wish FFmpeg would use pkg-config for zlib
[22:37:27 CET] <JEEB> I hate having -I/prefix/include -L/prefix/lib just for zlib
[22:37:47 CET] <JEEB> I had a patch for it around but wasn't sure if I had done it correctly so I didn't post it
[22:38:08 CET] <Kam_> my zlib doesn't even have a pkgconfig file
[22:38:23 CET] <JEEB> for me make install installed one
[22:38:30 CET] <JEEB> and I build straight out of the zlib tarballs
[22:38:42 CET] <JEEB> I was surprised myself, but it was there and got installed
[22:39:00 CET] <Kam_> not here, I build it via cmake
[22:39:19 CET] <JEEB> also I wouldn't remove the manual check for zlib, just that since the project delivers pc file might as well first try it
[22:39:59 CET] <JEEB> Kam_: there's "zlib.pc.cmakein"
[22:40:00 CET] <Kam_> I see what pkgconfig is trying to achieve
[22:40:17 CET] <JEEB> so it seems like the cmake build stuff for zlib is also having the pc file there
[22:40:43 CET] <JEEB> http://up-cat.net/p/884749c1
[22:41:01 CET] <Kam_> ah right, found it, it IS there, in zlib/share/pkgconfig
[22:41:19 CET] <JEEB> o_O
[22:41:25 CET] <JEEB> it installs it there?!
[22:41:46 CET] <JEEB> which is probably a packaging fail from zlib since x265 uses cmake as well and the pc file goes into the right place
[22:41:55 CET] <Kam_> yes.. it's in share
[22:42:06 CET] <JEEB> what I do for zlib for mingw-w64 is
[22:42:07 CET] <JEEB> make -f win32/Makefile.gcc PREFIX=x86_64-w64-mingw32-
[22:42:13 CET] <JEEB> make install -f win32/Makefile.gcc PREFIX=x86_64-w64-mingw32- prefix=/home/jeeb/ownapps/mingw64_prefix/ CP=install INCLUDE_PATH=/home/jeeb/ownapps/mingw64_prefix/include/ LIBRARY_PATH=/home/jeeb/ownapps/mingw64_prefix/lib/ BINARY_PATH=/home/jeeb/ownapps/mingw64_prefix/bin/
[22:42:21 CET] <JEEB> and that installs things properly
[22:42:37 CET] <JEEB> (or at least it's got a pc file in the correct place etc)
[22:43:58 CET] <Kam_> set(INSTALL_PKGCONFIG_DIR "${CMAKE_INSTALL_PREFIX}/share/pkgconfig" CACHE PATH "Installation directory for pkgconfig (.pc) files")
[22:44:19 CET] <Kam_> might be a mistake in their CMakeLists.txt
[22:44:23 CET] <JEEB> probably
[22:44:38 CET] <JEEB> as I know that cmake is capable of being used correctly
[22:44:51 CET] <JEEB> (f.ex. x265 puts the pc file in the correct place)
[22:46:01 CET] <furq> what's wrong with using zlib's configure script
[22:47:20 CET] <JEEB> I think I just followed their mingw/windows gcc build docs
[22:47:31 CET] <JEEB> which use the win32/Makefile.gcc thing
[22:47:34 CET] <JEEB> which seems to work
[22:47:41 CET] <JEEB> thus never tried the configure script
[22:47:42 CET] <JEEB> lol
[22:47:53 CET] <Kam_> I switched over to CMake, I found it easier to maintain for cross-compiling, I can simply switch one variable and all libraries I build it with should target another system (or switch between 32bit and 64bit)
[22:47:59 CET] <furq> fair enough
[22:48:24 CET] <JEEB> Kam_: yea lachs0r does cross-compilation of multiple things orchestrated by cmake
[22:48:36 CET] <JEEB> so it seems to be OK for that?
[22:48:45 CET] <JEEB> but he doesn't try to use cmake for each project building
[22:48:46 CET] <Kam_> I've got this in my build script for CMake, I can reuse it for anything that builds with CMake: CM_GENERAL="-DCMAKE_SYSTEM_NAME=Windows -DCMAKE_C_COMPILER="$CROSS_HOST"-gcc -DCMAKE_RC_COMPILER="$CROSS_HOST"-windres -DCMAKE_FIND_ROOT_PATH="$HD_GCC_PREFIX"/"$CROSS_HOST" -DCMAKE_BUILD_TYPE=Release"
[22:49:58 CET] <sfan5> cmake supports a "toolchain file" for this exact purpose
[22:50:13 CET] <sfan5> then you specify -DCMAKE_TOOLCHAIN_FILE=... instead of all those
[22:50:20 CET] <Kam_> yes, you can also use the toolchain file..
[22:52:42 CET] <JEEB> right, shaderc used cmake
[22:59:16 CET] <azarus> -row-mt (VP9) is cutting my encode time from 6 hours to 4 hours, yay :D
[23:00:19 CET] <azarus> (totally scientific, btw)
[23:00:20 CET] <JEEB> azarus: I hope you at least made some tests that you're actually gaining compression
[23:00:41 CET] <JEEB> as in, the bang for the buck is there
[23:00:48 CET] <azarus> Yup.
[23:01:42 CET] <JEEB> also it's funny how some people think that they can only set bit rate to 50kbps with newer formats, or that the defaults making a smaller file automagically means that it's better (not looking at the actual result otherwise)
[23:01:48 CET] <azarus> I'm using Constant Rate Factor, so it might be quite variable
[23:02:18 CET] <JEEB> I don't think libvpx has that, the FFmpeg wrapper just maps -crf to some option within libvpx
[23:02:31 CET] <azarus> i do think vpx has crf$
[23:02:39 CET] <azarus> s/crf$/crf/
[23:03:41 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libvpxenc.c#L688
[23:03:57 CET] <JEEB> the libavcodec wrapper maps "crf" to CQ level
[23:04:06 CET] <azarus> ooh, interesting
[23:04:11 CET] <azarus> i've been proven wrong
[23:04:29 CET] <JEEB> CRF as an option is specific to x264 (and then copied into x265)
[23:04:40 CET] <JEEB> but then people decided it was a good idea to map it against the CQ option in libvpx
[23:04:58 CET] <JEEB> I think the VP9 one is more similar to the x264 one, I think?
[23:04:59 CET] <sfan5> shouldn't -q:v rather map to cq?
[23:05:13 CET] <JEEB> depends on what CQ means in this context
[23:05:17 CET] <JEEB> if it's constant quantizer, yes
[23:05:22 CET] <JEEB> if it's something dynamic then not
[23:05:40 CET] <sfan5>             --cq-level=<arg>           	Constant/Constrained Quality level
[23:05:40 CET] <sfan5> so no
[23:06:29 CET] <azarus> http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide even recommends using -crf
[23:06:38 CET] <azarus> (if you want constant quality)
[23:06:42 CET] <JEEB> well yea, since that's the option mapped against CQ level
[00:00:00 CET] --- Mon Mar 19 2018