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

[burek]

[00:02:54 CET] <diverdude> hi, i am trying to run this command : ffmpeg -f lavfi -i testsrc=duration=10:size=4096x3000:rate=30 testsrc.mov  but I cannot play it back and it only takes up 536kb, so something is going wrong. Why acnt i generate this testsource?
[00:05:19 CET] <r0ute> Huh, threads just for multi core stuff? Seems they've been around for quite a while and I've used them plenty on single core architectures.
[00:05:54 CET] <BtbN> diverdude, that exact command works fine for me.
[00:06:01 CET] <BtbN> Defaults to mpeg4 for the video codec
[00:06:23 CET] <diverdude> BtbN: which OS are you on?
[00:06:32 CET] <BtbN> That shouldn't matter at all
[00:07:46 CET] <diverdude> BtbN: how big is the file you generate when you run the command?
[00:08:02 CET] <BtbN> 12
[00:08:06 CET] <BtbN> MB
[00:08:11 CET] <diverdude> 12MB?
[00:08:12 CET] <diverdude> ok
[00:08:32 CET] <BtbN> using latest ffmpeg master
[00:09:23 CET] <diverdude> i have ffmpeg version 3.2.4
[00:09:45 CET] <diverdude> and file i create is just 583K
[00:10:07 CET] <llogan> nightlingo: if you want to save to local file and stream it at the same time see tee muxer (but maybe I didn't really follow what you wanted)
[00:12:12 CET] <r0ute> diverdude: 3.2.4 here as well and I get a @12MB file
[00:12:17 CET] <r0ute> ~12MB
[00:13:37 CET] <nightlingo> llogan: Id like to avoid saving to a local file but maybe Ill do it as a last resort. What about that tee muxer?
[00:13:38 CET] <diverdude> so why on earth is mine not working :/
[00:14:24 CET] <llogan> nightlingo: oh, so you don't even need a local mp4 file. i guess I don't know what you want to do then. as for tee: http://ffmpeg.org/ffmpeg-formats.html#tee
[00:14:54 CET] <diverdude> r0ute: you are running this command right? ffmpeg -f lavfi -i testsrc=duration=10:size=4096x3000:rate=30 testsrc.mov
[00:16:25 CET] <nightlingo> llogan: what I want to do is to be able to split an .mp4 file (say a 5 min part out of an hour long  video) and output that part to sdtout
[00:16:54 CET] <diverdude> llogan: this is my exact command and output from terminal : http://paste.ubuntu.com/24154404/
[00:17:34 CET] <llogan> nightlingo: ffmpeg -ss 30 -i input -t 00:05:00 -f mpegts -
[00:17:55 CET] <r0ute> diverdude: I copied ad pasted yours and it worked fine
[00:18:07 CET] <nightlingo> llogan: unfortunately the output of this doesnt work well with Windows Media Player on Windows 7
[00:18:07 CET] <llogan> diverdude: from your console output: "No pixel format specified, yuv444p for H.264 encoding chosen. Use -pix_fmt yuv420p for compatibility with outdated media players."
[00:18:18 CET] <llogan> ah, WMP.
[00:18:40 CET] <llogan> assumed a sane player
[00:18:44 CET] <nightlingo> lol
[00:19:02 CET] <nightlingo> llogan: if it was up to me I would ban this from my users :)
[00:19:57 CET] <diverdude> llogan: hmmm then i get error : Option pixel_format not found.
[00:20:14 CET] <diverdude> llogan: this is my command : ./ffmpeg -f lavfi -pix_fmt yuv420p -i testsrc=duration=10:size=4096x3000:rate=30 testsrc.mov
[00:20:51 CET] <llogan> option placement matters. use it as an output option
[00:21:23 CET] <diverdude> llogan: mm ok. how so? Can you show me an example?
[00:21:41 CET] <llogan> ./ffmpeg -f lavfi -pix_fmt yuv420p -i testsrc=duration=10:size=4096x3000:rate=30 -vf format=yuv420p testsrc.mov
[00:21:47 CET] <llogan> ./ffmpeg -f lavfi -pix_fmt yuv420p -i testsrc=duration=10:size=4096x3000:rate=30,format=yuv420p testsrc.mov
[00:21:54 CET] <llogan> ./ffmpeg -f lavfi -pix_fmt yuv420p -i testsrc=duration=10:size=4096x3000:rate=30 -pix_fmt yuv420p testsrc.mov
[00:22:08 CET] <llogan> oh, remove that input one
[00:22:19 CET] <llogan> c&p fail
[00:26:33 CET] <llogan> also, you're exceeding level limits so maybe your player won't like that.
[00:27:39 CET] <diverdude> llogan: ok it works now....but strange enough file is only 836kb and not 12mb
[00:28:09 CET] <diverdude> llogan: what level limits?
[00:28:46 CET] <llogan> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
[00:30:14 CET] <llogan> why should it be 12mb? it's not a very complex input.
[00:31:40 CET] <diverdude> llogan: because some other guys in here ran my command and got a 12mb file output
[00:32:46 CET] <llogan> they ran a different command and some used a different encoder
[00:33:19 CET] <diverdude> llogan: ok...so exceeding level limits...it seems..at least according to that table that no level can handle 4096x3000 reslution, so that is probably what you are referring to when you say 'exceed level limits'. But then how should i encode a video of this size if its not supported in any level?
[00:35:59 CET] <llogan> you can still encode 4096x3000. just make sure your player likes it. or use a different encoder such as libx265.
[00:37:01 CET] <diverdude> llogan: right ok i see.
[00:37:07 CET] <ZeroWalker> which library has "sws_getContext", i thought it was swscale.lib but it seems not
[00:40:08 CET] <thebombzen> diverdude: yea around 400-500 kbps is fine for libx264, but I recommend libx265
[00:40:36 CET] <thebombzen> 12M is what you'll get if you use mpeg4 as the default, which defaults to 2 Mbps rather than crf 23
[00:41:09 CET] <thebombzen> I"m not sure why BtbN's build defaulted to mpeg4 when the mov muxer requests h.264 by default
[00:41:33 CET] <llogan> because it probably wasn't built with --enable-gpl --enable-libx264
[00:41:44 CET] <thebombzen> haha true lol
[00:42:02 CET] <thebombzen> speaking of which, why does nut still not support opus
[00:42:11 CET] <thebombzen> nut still requests mpeg4
[00:42:17 CET] <thebombzen> and vorbis afaik
[00:42:27 CET] <thebombzen> which is really annoying. it should request ffv1 and flac
[00:42:32 CET] <thebombzen> and it should support opus
[00:44:35 CET] <kepstin> probably needs some work done to add an opus codec mapping, which iirc mostly means some way of storing the samples to discard at start/end. Might need some work to handle seeking differently? I dunno how exactly seeking works in nut.
[00:47:21 CET] <llogan> thebombzen: i don't know. patch welcome, but be warned that there are like some who will automatically oppose any change.
[00:47:45 CET] <llogan> don't know where that "like" came from.
[00:48:08 CET] <thebombzen> well the issue is more that "nut should support anything that ffmpeg can produce"
[00:48:12 CET] <thebombzen> which is currently not the case
[00:48:26 CET] <thebombzen> the defaulting to mpeg4 is annoying but not as problematic as "doens't support opus"
[01:41:55 CET] <nightlingo> is there any option to skip mdat when writing the output ? or just extract the MOOV atom of the operation?
[04:09:46 CET] <FFmpegFTL> Hello folks. We currently trying to get a rtmp server up and running, only using ffmpeg. We have found a old version of ffmpeg with build in rtmp_listen option. After we downloaded the latest ffmpeg version from the official website we saw there is no option like rtmp_listen anymore. Has rtmp_listen been removed, or does it changed in any way ?
[04:11:00 CET] <FFmpegFTL> The old repo can bei found here https://github.com/WatchBeam/ftl-ffmpeg
[04:13:28 CET] <furq> FFmpegFTL: it's just listen now
[04:13:42 CET] <furq> although i don't think that'll work as you hope it will
[04:14:04 CET] <FFmpegFTL> So it has been completely removed ?
[04:15:59 CET] <furq> no, the option was renamed
[04:16:17 CET] <FFmpegFTL> Thats sad. We are currently trying to get multiple streams (4) and merge them together to one stream to push it to streaming services like twitch
[04:16:50 CET] <furq> but it works the same as all the other ffmpeg server functionality, i.e. not very well
[04:17:07 CET] <furq> it'll only serve one client, it won't do anything until a client connects and then it'll die when the client disconnects
[04:17:18 CET] <furq> use nginx-rtmp or something
[04:17:41 CET] <FFmpegFTL> We tried to avoid that :/
[04:17:57 CET] <furq> what's wrong with it
[04:18:23 CET] <FFmpegFTL> In my opinion, it just adds more latency to the stream
[04:19:35 CET] <FFmpegFTL> So when using streaming services like beam.pro which have nearly realtime (~500ms delay)
[04:19:58 CET] <FFmpegFTL> Thats not a good thing to add more latency to the stream
[04:23:00 CET] <FFmpegFTL> Can you give me a starting point on how to get the latest ffmpeg to listen for a incoming rtmp stream ?
[04:23:35 CET] <furq> oh
[04:23:40 CET] <furq> i don't know if it can listen for an incoming stream
[04:24:14 CET] <furq> -listen will serve a stream to the next client that connects
[04:24:35 CET] <FFmpegFTL> Thats what i meant with the rtmp_listen option
[04:24:57 CET] <FFmpegFTL> It actually listens for an incoming rtmp stream
[04:25:30 CET] <furq> oh i guess that does work
[04:28:13 CET] <furq> just put -listen 1 before -i rtmp://..
[04:28:23 CET] <furq> this seems incredibly flaky though
[04:29:18 CET] <FFmpegFTL> The syntax when using the old source is
[04:29:35 CET] <FFmpegFTL> ffmpeg -rtmp_listen 1 -re -i rtmp://0.0.0.0:8090
[04:29:47 CET] <furq> like i said, -listen is the same option
[04:29:49 CET] <furq> it was just renamed
[04:32:37 CET] <FFmpegFTL> When Ich try this, it says that ist cant connect
[04:32:51 CET] <FFmpegFTL> *when i try this
[04:34:23 CET] <FFmpegFTL> RTMP_Connect0, failed to connect socket. 10049 (Unknown Erröten)
[04:34:32 CET] <FFmpegFTL> *Error
[04:34:58 CET] <furq> it works for me but i was providing the app name
[04:35:05 CET] <furq> -i rtmp://0.0.0.0:1935/live/foo
[04:40:58 CET] <FFmpegFTL> Same error
[04:41:17 CET] <FFmpegFTL> Just for make thing
[04:41:51 CET] <FFmpegFTL> Just for making things clear, can u send me the complete line ?
[04:43:51 CET] <furq> ffmpeg -listen 1 -i rtmp://0.0.0.0:1935/live/foo -f null -
[04:44:11 CET] <furq> ffmpeg -f lavfi -re -i testsrc -c:v libx264 -f flv rtmp://localhost:1935/live/foo
[04:48:25 CET] <FFmpegFTL> Ich think something is wrong here on my side
[04:48:37 CET] <FFmpegFTL> RTMP_Connect0, failed to connect socket. 10049 (Unknown error) rtmp://0.0.0.0:1935/live/foo: Unknown error occurred0
[04:48:59 CET] <FFmpegFTL> Thats what I get then
[04:50:14 CET] <FFmpegFTL> I am using version 3.2.2 on windows
[04:58:07 CET] <FFmpegFTL> Does it make a difference when using this on Windows ?
[04:58:39 CET] <furq> it shouldn't
[04:58:48 CET] <furq> it might make a difference if you have a build with librtmp
[04:58:58 CET] <furq> mine doesn't have it
[04:59:28 CET] <FFmpegFTL> Mine has --enable-librtmp flag set
[05:02:18 CET] <FFmpegFTL> I will try to compile it without this flag, and try again tomorrow. Thanks for your help :)
[05:46:31 CET] <ZeroWalker> anyone know how to convert rgba to yuv420p with swscale (coding)
[11:20:00 CET] <nightlingo> hi
[11:20:18 CET] <nightlingo> is there any option to skip the mdat part when writing the output ? or just save the MOOV atom of the operation?
[11:38:00 CET] <thebombzen> nightlingo: why do you want to do that
[11:38:17 CET] <thebombzen> you could always use -movflags +faststart to move it to the front of the file instead
[11:38:22 CET] <thebombzen> and then just cut it
[11:40:58 CET] <nightlingo> thebombzen: the reason is that I want to avoid having to produce the whole
[11:41:52 CET] <nightlingo> thebombzen: file. My ultimate goal is to be able to split an mp4 and have the output sent to stdout. Since ffmpeg doesnt allow writing mp4 format to stdout Im trying to do it manually
[11:42:13 CET] <nightlingo> thebombzen: faststart requires the whole file to be written anyway
[11:53:48 CET] <kerio> what about fragmented mp4
[11:54:35 CET] <nightlingo> kerio: fragmented mp4 doesnt work well on some older players like WMP windows 7
[11:55:02 CET] <kerio> sorry :(
[11:55:26 CET] <nightlingo> :)
[11:55:39 CET] <kerio> i mean
[11:56:12 CET] <kerio> i don't think there's a way to write the moov atom beforehand
[11:56:48 CET] <nightlingo> kerio
[11:57:02 CET] <nightlingo> kerio: seems like it. I was hoping at least a way to skip writting the mdat part altogether
[11:57:09 CET] <nightlingo> but cant find anything
[12:43:23 CET] <luc4> Hello! I frequently build ffmpeg for embedded platforms. I sometime get these kinds of errors: https://paste.kde.org/pjc33vtva. It seems like configure cannot find libs that are actually on the device. I added rpath as you can see in the command line. Isnt this sufficient? Maybe it is not added to the link command? Any advice?
[12:58:46 CET] <DHE> is this the real thing or a cross compiler on your own PC?
[13:16:39 CET] <luc4> DHE: crosscompiler
[13:18:05 CET] <JEEB> luc4: you would have to have the sysroot on the build machine as well
[13:18:18 CET] <JEEB> otherwise the cross-compiler will just be "lol cannot find what against to link"
[13:18:31 CET] <DHE> with all the needed libraries, and probably the pkg-config metadata
[13:18:58 CET] <JEEB> pkg-config files help together with PKG_CONFIG_LIBDIR set correctly, yes
[13:20:53 CET] <luc4> JEEB, DHE: the sysroot is properly mounted, I already built GBs of sources with the same toolchain and sysroot
[13:21:38 CET] <luc4> also I already built ffmpeg for the same platform a hundred times, but this problem with libssh and libsmbclient keeps popping up
[13:22:08 CET] <luc4> I was hoping someone could explain the situation properly because it is not completely clear to me what is happening
[13:22:30 CET] <luc4> paths to the pkg-config paths are set
[13:23:19 CET] <JEEB> right
[13:23:23 CET] <luc4> pkg-config libssh libs and cflags properly returns -L/opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf -lssh
[13:23:29 CET] <JEEB> that seems pretty obvious, though. a library is missing
[13:23:38 CET] <JEEB> warning: libgssapi_krb5.so.2, needed by /opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/libssh.so, not found
[13:23:41 CET] <luc4> where /opt/rpi/sysroot is where the sysroot is mounted
[13:24:12 CET] <luc4> JEEB: I checked a few and those where installed, let me check that specifically
[13:24:54 CET] <luc4> JEEB: preset in /usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2
[13:25:22 CET] <JEEB> which is not your sysroot :D
[13:25:31 CET] <luc4> of course it is
[13:25:39 CET] <luc4> that is the path in the board
[13:25:55 CET] <JEEB> well then tell me if you have /opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2
[13:26:11 CET] <JEEB> on the build machine
[13:26:47 CET] <luc4> JEEB: -rw-r--r-- 1 root root 233K feb  4  2016 /opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2
[13:27:15 CET] <luc4> it is there
[13:27:17 CET] <JEEB> alright, so your lovely toolchain is fscking things up for some reason :)
[13:27:33 CET] <JEEB> if it can find the ssh lib there, but not look for the gssapi one
[13:28:32 CET] <luc4> JEEB: I had situations like this other times, and the solution was to, in fact, set a rpath
[13:29:09 CET] <luc4> JEEB: https://paste.kde.org/pt9ejv2cy
[13:29:17 CET] <luc4> here I set rpath manually
[13:29:41 CET] <luc4> but I see it appears in the compile line and not in the link line
[13:29:55 CET] <luc4> do you think that may be the problem?
[13:30:48 CET] <JEEB> that's still weird because I would expect a cross-toolchain to just find things in its own sysroot (I've had multiple ARM/x86 cross-compilers and I've not needed rpath)
[13:33:06 CET] <JEEB> also both of those calls seem to be just calling the compiler and outputting an object file, so I would say similar thing would be needed for similar results, although I would really check what rpath does and any possibility of you actually doing something "non-standard" (path-wise or otherwise for the cross-toolchain/sysroot) in a way that the library searches would break
[13:40:32 CET] <luc4> JEEB: actually I think this cross compiler is not entirely related to the sysroot
[13:41:09 CET] <luc4> JEEB: they are not providing a proper toolchain, but this seemed very good and worked with many many other frameworks
[13:41:45 CET] <luc4> do you think it is possible to configure so that rpath appears also in the linker command?
[13:42:15 CET] <JEEB> well that's why ./configure --help |grep "extra-"
[13:46:38 CET] <luc4> JEEB: --extra-ldflags maybe?
[13:46:48 CET] <JEEB> that's for linker lines, yes
[13:50:05 CET] <Voltasalt> Trying to make a screen recorder using ffmpeg, it's dropping a lot of frames under a relatively simple workload. Any tips on tuning?
[13:55:19 CET] <durandal_1707> Voltasalt: what coded?
[13:55:52 CET] <Voltasalt> x264
[13:57:25 CET] <durandal_1707> preset?
[13:57:30 CET] <Voltasalt> ultrafast
[14:01:20 CET] <vlt> Hello. Im using ffmpeg to encode h.264 video. When I use the default settings (no -preset or -profile) a "High" profile video file is created and its playable also on my Samsung TV.  When I try to use -preset veryslow that TV doesnt recognize the video format. Any idea what might be the reason? What could I tweak to get smaller file sizes?
[14:13:00 CET] <furq> vlt: check the level of the first file and set -level xx when using veryslow
[14:13:49 CET] <furq> i forget if level caps bframes but it definitely caps refs
[14:52:09 CET] <vlt> furq: -level 4.0 helped
[14:52:12 CET] <vlt> Thanks!
[14:58:50 CET] <JEEB> furq: it sets refs since bframes are unrelated to memory limiting
[17:07:10 CET] <Voltasalt> Is it possible to make ffmpeg output the status updates more often?
[17:08:19 CET] <aguardar> loglevel
[17:08:47 CET] <Voltasalt> thanks
[17:16:39 CET] <Voltasalt> Wait no, loglevel=debug doesn't print more status updates (as in, the ones going frame=xxx time=xxx fps=xxx etc), just prints more internal encoder garbage
[17:18:15 CET] <DHE> no, it's hard-coded to aim for 1/2 second intervals. see print_report() in ffmpeg.c
[17:18:20 CET] <Voltasalt> dang
[18:00:59 CET] <thebombzen> Voltasalt: if you build ffmpeg yourself you can change that
[19:52:32 CET] <Tatsh> confused by this message
[19:52:32 CET] <Tatsh> [Parsed_pan_0 @ 0x2366f20] This syntax is deprecated. Use '|' to separate the list items.
[19:52:44 CET] <Tatsh> from -af pan=1:c0=c0
[19:53:24 CET] <c_14> use | instead of :
[19:53:28 CET] <durandal_1707> its self explanatory
[19:53:54 CET] <c_14> https://ffmpeg.org/ffmpeg-filters.html#pan
[19:54:46 CET] <Tatsh> oh
[20:25:07 CET] <DHE> also use quotes or backslashes so your shell doesn't interpret pipes for itself
[20:31:58 CET] <Tatsh> yea
[20:32:03 CET] <Tatsh> so analyzeduration works wonders
[20:32:35 CET] <Tatsh> on cut h264 streams i get 'unspecified pixel format' a lot
[21:58:49 CET] <ldiamond> I have a MP4 taken from an android phone which I want to use in Blender for video editing. mediainfo says it's variable framerate, not sure it actually is, but the framerate on blender is 60000/1001 (59.94fps) so the imported video doesn't play properly (it's faster on the video).
[21:59:11 CET] <ldiamond> I assume I need to convert the android mp4 to a 59.94fps video.
[22:22:52 CET] <jarkko> has anyone solved this issue? http://www.makemkv.com/forum2/viewtopic.php?f=3&t=224
[22:23:13 CET] <jarkko> makemkv doesnt find up to date libavcodec
[22:27:42 CET] <JEEB> if they utilize old APIs then their configure check probably doesn't catch it
[22:32:29 CET] <Rickky> Hi guys, I'm trying to compile ffmpeg on Debian. I keep getting "ERROR: librtmp not found using pkg-config" in my configure.log. I'm a bit stuck as I confirmed librtmp to be present in /usr/lib/x86_64-linux-gnu/librtmp.so. Even while it's in a default path, I've included the dir explicitly in the pkg config path. "pkg-config --exists --print-errors librtmp" is also pretty silent (= ok afaik).
[22:33:06 CET] <JEEB> Rickky: do you have the -dev package installed for it?
[22:33:32 CET] <JEEB> also do note that libavformat now has an internal RTMP(E) protocol handler, so librtmp is not necessarily required unless something specifically doesn't work with the libavformat one
[22:35:12 CET] <Rickky> JEEB: Yup, apt-get install librtmp-dev
[22:35:59 CET] <Rickky> JEEB: I'm not sure about libavformat tbh -- ./configure keeps complaining about librtmp
[22:37:00 CET] <JEEB> post your config.log on pastebin or so
[22:37:03 CET] <JEEB> and link here
[22:37:16 CET] <Rickky> JEEB: Sure, hang on
[22:37:17 CET] <JEEB> also librtmp is one of those things that you have to specifically enable in the configuration
[22:37:28 CET] <JEEB> while the libavformat one is always built unless you specifically disable it
[22:37:49 CET] <JEEB> so effectively if you build with librtmp and the internal one enabled, you have two things handling rtmp protocol :P
[22:38:31 CET] <JEEB> so if you don't know why you are enabling librtmp specifically, try building without it and see if it works. because it should unless there's a bug in the libavformat one
[22:40:27 CET] <Rickky> JEEB: http://pastebin.com/raw/zbNsLavu
[22:41:01 CET] <JEEB> so yes, you are trying to enable librtmp specifically on your command line
[22:41:26 CET] <Rickky> Yeah I just realized that as well -- so while I do need rtmp that's actually not needed I take from your earlier message
[22:41:41 CET] <JEEB> yea, unless there's a bug in the libavformat one
[22:42:00 CET] <Rickky> Out of curiousity, why does it fail anyway?
[22:42:01 CET] <JEEB> also the reason for librtmp not getting found is actually simple it seems :P
[22:42:03 CET] <Rickky> The lib is there for sure
[22:42:04 CET] <JEEB> gcc: error: unrecognized command line option '-R'
[22:42:17 CET] <Rickky> lol
[22:42:21 CET] <JEEB> -L/usr/lib/x86_64-linux-gnu -R/usr/lib/x86_64-linux-gnu
[22:42:27 CET] <JEEB> wherever that came from
[22:42:47 CET] <Rickky> That's the dir where apt installed librtmp into...
[22:42:57 CET] <JEEB> yes, but I have no idea what -R is :P
[22:43:04 CET] <JEEB> but it seems like the pkg-config file might contain that
[22:43:20 CET] <JEEB> in which case it would be a boog
[22:43:28 CET] <Rickky> Let me just try without librtmp then, if av already provides an rtmp handler
[22:43:30 CET] <JEEB> (in debian's librtmp thing)
[22:43:34 CET] <JEEB> yea
[22:44:15 CET] <Rickky> Seems to pass, sort of, ERROR: libvpx decoder version must be >=0.9.1
[22:44:18 CET] <Rickky> On to the next error :D
[22:45:35 CET] <JEEB> as a quick hint I recommend you just enable the exact stuff that you specifically need
[22:46:11 CET] <JEEB> especially if you're trying to keep to what's in likely by now ancient debian's repositories
[22:46:32 CET] <Rickky> JEEB: Yeah I already omitted some stuff I didn't need. librtmp was one I did specifically needed for my usecase
[22:46:52 CET] <Rickky> The others... copy and pasting from a ffmpeg installation I know works as I need it
[22:47:13 CET] <Rickky> But it's failing on openssl now as well for example, removing that one now as well indeed
[22:47:37 CET] <JEEB> openssl or gnutls is needed for HTTPS
[22:47:42 CET] <JEEB> and RTMPE, I think?
[22:47:55 CET] <Rickky> I understand, but I'm not pushing over an encrypted endpoint for now
[22:47:58 CET] <JEEB> ok
[22:48:46 CET] <Rickky> yup, it got through configure. make running now
[22:48:51 CET] <Rickky> ... for the next 30 mins probably
[22:49:50 CET] <Rickky> JEEB: I was running in a working docker container first, but I got stuck with fontconfig issues with drawtext, so somewhat against my will I'm compiling it manually myself now
[22:50:24 CET] <JEEB> do note that anything configured with enable-nonfree is not OK to distribute
[22:50:47 CET] <Rickky> JEEB: completely fine, this is for own use, not re-distribution
[22:50:53 CET] <JEEB> k
[22:51:00 CET] <Rickky> thx for the pointers though :)
[22:51:08 CET] <JEEB> also thank goodness for the internal AAC encoder getting useful
[22:51:25 CET] <JEEB> because fdk-aac is pretty much the only real reason to build with enable-nonfree
[22:51:51 CET] <Rickky> exact reason why I'm running nonfree
[22:52:43 CET] <Rickky> JEEB: out of curiousity, have you ever run ffmpeg continously as a stream encoder?
[22:53:06 CET] <JEEB> yes, but I would really recommend making a thing with libavformat/avcodec for it
[22:53:09 CET] <Rickky> e.g. continous stream for consecutive hours / non batch/file based processing
[22:53:23 CET] <JEEB> you end up  with having to deal with ffmpeg.c bullshit which will eat you inside
[22:53:41 CET] <JEEB> (granted, it's scary how far you can get with just ffmpeg.c)
[22:54:05 CET] <Rickky> You mean omitting ffmpeg all together?
[22:54:18 CET] <JEEB> ffmpeg.c, yes. but using FFmpeg's libraries
[22:54:52 CET] <Rickky> yeah I'm not experienced enough with this to use libavformat/codec directly
[22:55:18 CET] <JEEB> also ffmpeg.c really does lack some things with regards to broadcast
[22:55:38 CET] <JEEB> although partially due to how for example the mpeg-ts demuxer handles some things
[22:57:19 CET] <Rickky> Not really sure what you mean with difference between ffmpeg as a bin and ffmpeg.c tbh -- not a C dev
[22:57:36 CET] <Rickky> I'm not writing any code, just using ffmpeg bin
[22:58:58 CET] <JEEB> ffmpeg.c is the command line ffmpeg application
[22:59:15 CET] <JEEB> the project is called FFmpeg and while some people understand the difference I usually end up talking about the cli application as ffmpeg.c
[22:59:18 CET] <JEEB> to differentiate
[22:59:41 CET] <JEEB> because quite literally a fuckload of the bullshit is in ffmpeg.c
[23:00:55 CET] <Rickky> JEEB: yeah okay just making sure, I'm indeed using the command line binary ffmpeg.c then yeah
[23:01:42 CET] <Rickky> I've used ffmpeg for pretty straight forward stuff, but now first time really digging into it trying to generate real time overlays and such on input stream and outputting it again as a stream too
[23:01:57 CET] <Rickky> First thing I've noticed is how _much stuff_ you can do through ffmpeg.c indeed
[23:02:02 CET] <Rickky> endless amount of params
[23:02:05 CET] <JEEB> yes
[23:02:18 CET] <JEEB> that's one of the good and bad things, because those things can and will end up having limitaitons
[23:02:44 CET] <JEEB> plus, then you have various hacks for various cases that happened N years ago, and nobody knows if they're still required. usually for broken input
[23:03:03 CET] <Rickky> story of any monolithic, old, app
[23:03:10 CET] <JEEB> yup
[23:03:15 CET] <Rickky> I face this shit day to day at work
[23:04:18 CET] <JEEB> which is why usually for some use cases, of which live broadcast is one, I would just recommend making a limited tool with the APIs provided. there's examples under docs/examples, even
[23:04:32 CET] <Rickky> I'm afraid compiling is still going to take a while... It's just at libswscale
[23:04:38 CET] <JEEB> but yes, you can get scary far
[23:04:40 CET] <Rickky> Only using 50% cpu unfortunately as well
[23:04:41 CET] <JEEB> with just ffmpeg.c
[23:04:50 CET] <JEEB> didn't put enough -j into your make :P
[23:04:56 CET] <Rickky> :p
[23:05:02 CET] <Rickky> so you mean basically forking ffmpeg.c?
[23:05:05 CET] <JEEB> no
[23:05:25 CET] <JEEB> I mean, in theory ffmpeg.c could even be in its own repo, the libraries are just something it utilizes
[23:05:37 CET] <Rickky> ah like that
[23:05:39 CET] <Rickky> yeah definitely
[23:06:02 CET] <Rickky> it seems unnecessarily coupled
[23:06:10 CET] <JEEB> so you just make a limited, meant for something specifically kind of app
[23:06:10 CET] <Rickky> but I haven't looked at the internals that much
[23:06:20 CET] <JEEB> usually that works even better than ffmpeg.c :D
[23:06:26 CET] <Rickky> hehe
[23:06:39 CET] <Rickky> For starters I'm eager to get this proof of concept running
[23:06:43 CET] <JEEB> yea
[23:07:09 CET] <JEEB> the problem is if that ends up being the end product and then you're stuck with ffmpeg.c. which will work for a while but will sooner or later start pulling your speed down
[23:07:26 CET] <Rickky> tbh for this use case it's not that much of an issue
[23:07:35 CET] <Rickky> if this end up working, it wouldn't become a redistributable app anyway
[23:07:42 CET] <Rickky> more to server internal purposes with a single use case
[23:07:50 CET] <Rickky> not like it's going to become a product
[23:07:59 CET] <Rickky> but I get what you're saying, but ymmv
[23:08:05 CET] <JEEB> indeed
[23:08:35 CET] <Rickky> ah, compile is done already
[23:08:46 CET] <Rickky> This is weird to say but I'm only now realizing how much I miss IRC
[23:08:56 CET] <JEEB> :)
[23:08:57 CET] <Rickky> I used to hang around all day long in tons of chatrooms and communities
[23:09:15 CET] <Rickky> When I started at this job almost 4 years ago IRC was blocked and it kind of faded away in my routine
[23:09:29 CET] <Rickky> But I just realized I miss it :)
[23:22:27 CET] <Rickky> JEEB: stream --> stream remotely over mpeg1 is _really_ laggy
[23:22:36 CET] <Rickky> audio dropping, frames dropping etc.
[23:31:35 CET] <jarkko> when i run .configure what file i need to start looking for that could have this text "configure: error: The libavcodec library is too old. Please get a recent one from http://www.ffmpeg.org" ?
[23:31:58 CET] <jarkko> i need to just disable the version check and it could work
[23:32:02 CET] <JEEB> that is the configure script you're running
[23:32:10 CET] <JEEB> and no, it is likely testing for APIs
[23:32:12 CET] <JEEB> which might be old
[23:32:29 CET] <JEEB> but you might want to check config.log if that third party thing has that for specifics
[23:36:36 CET] <jarkko> frustfrating, it worked around 2-3 versions ago
[23:37:12 CET] <JEEB> find out what it is and report upstream
[23:41:13 CET] <jarkko> hmm actually that configure might be right
[23:41:21 CET] <jarkko> libavcodec-dev_7%3a2.8.11-0ubuntu0.16.04.1_amd64.deb
[23:41:51 CET] <jarkko> googling that gave filename ffmpeg56_
[23:42:02 CET] <jarkko> and i think that configure needs 57
[23:42:35 CET] <JEEB> weren't you supposed to have your own built and setting PKG_CONFIG_PATH to the install prefix of your copy :P
[23:42:47 CET] <JEEB> also learn to look into actual logs
[23:43:00 CET] <JEEB> config.log in case of configuration issues for anything having a configure script
[23:43:26 CET] <jarkko> JEEB: it didnt work any better
[23:44:23 CET] <JEEB> and since this has nothing to do with upstream FFmpeg, please move on to #makemkv or some other media which the makemkv folks are running
[00:00:00 CET] --- Sun Mar 12 2017