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

[burek]

[00:09:00 CEST] <DHE> ffmpeg's libs are static, but what other 3rd party libs (eg: x264) end up used remain in their original form and are pulled in as needed during compiling of real aps
[00:15:26 CEST] <Atlenohen> Yeah I also had to modify the x264 header so that it doesn't use X264_API _dllImport thingy, and then rebuild ffmpeg
[00:16:23 CEST] <Atlenohen> DHE: Cehoyos and others forgot this when they talked about BCrypt.lib with me, they kept telling me ffmpeg did not compile it
[00:16:45 CEST] <Atlenohen> That apparently ffmpeg did not had a message about it it supposed to (about missing bcrypt.lib
[00:27:00 CEST] <ncouloute> Concat Demuxer - 11.253-59.940 variable fps + frames shifting.
[00:27:01 CEST] <ncouloute> Concat Protocol - 59.920-59.940 varible fps + no frame shifting
[00:27:01 CEST] <ncouloute> . Concat Filter - 59.940 constant fps + frames shifting
[00:27:01 CEST] <ncouloute> . My guess is since concat Protocol method first involves going from mp4 to ts then concat then remix back to mp4.
[00:27:02 CEST] <ncouloute>  Concat just doesnt work very well for h264 mp4s.
[00:27:04 CEST] <ncouloute> Strangely enough h264_nvenc/h264_qsv encoded files dont have the frame shifting.
[00:41:29 CEST] <cehoyos> That FFmpeg did not compile what?
[01:49:35 CEST] <Atlenohen> cehoyos: Well, I got other people telling me bcrypt.lib wasn't suppose to be compiled with ffmpeg anyway as it's a standard practice that static libraries don't pack other libraries, unless specifically instructed.
[01:50:48 CEST] <Atlenohen> I remember you thought that ffmpeg had to "compile" it and that there was a no error/warning about it being "missing".
[01:55:19 CEST] <chinknot> I tried using a file with square brackets in its path with ffprobe but the terminal returns "No such file or directory". Is it possible this is a ffprobe related issue? I tried opening an issue on git-for-windows github but using the same path with other commands work without problems
[01:57:44 CEST] <Ariyasu> encase the path in "
[01:57:50 CEST] <Ariyasu> "path to input"
[01:58:04 CEST] <chinknot> I tried that but same result
[01:58:09 CEST] <Ariyasu> or caret the [] like ^[ and ^]
[01:58:17 CEST] <chinknot> I'll try ^
[01:58:38 CEST] <chinknot> anyway sorry if I didn't mention it but I launched it via git-for-windows
[01:59:45 CEST] <chinknot> ^ and \ didn't work
[01:59:55 CEST] <chinknot> also replacing ' with " didn't help
[02:20:40 CEST] <cehoyos> Atlenohen: You definitely don't "compile" bcrypt with FFmpeg, you need it to link the final executable, since you only build static libraries, you never need it. But FFmpeg's pkg-config file tells you that bcrypt is a dependency of libavutil.
[02:21:30 CEST] <cehoyos> None of this is secret in any way and none of this is difficult in any way. You just manage to always mix your issue reports with some unrelated and wrong opinions (possibly of others) making helping you more difficult than necessary.
[02:22:33 CEST] <Atlenohen> I didn't say it's secret, I obviously had no idea PKGCONFIG reports that ... if that's the standard place fine, but I'd have it in the terminal at the end of the build
[02:24:51 CEST] <Atlenohen> You certainly didn't explain this back then, I was then looking what's making ffmpeg not get bcrypt, in the process I found other bugs and also figured out the whole thing I either would need to anyway so I lost no time and I'm actually glad now I went as deep as I did, I'm not blaming you, just asking if you have meant something else, or misunderstood the situation at the time.
[02:26:31 CEST] <HickHoward> https://www.v-nova.com/tryPERSEUS/
[02:26:38 CEST] <HickHoward> perseus is going real live this time around
[02:26:45 CEST] <Atlenohen> Because that day we concluded "it doesn't have an error for bcrypt, patch welcome", there were 3 other guys looking into bcrypt is needed, none of them mentioned it's not suppose to pack bcrypt.lib inside FFmpeg's libs.
[02:33:17 CEST] <cehoyos> You reported a link error with your application yesterday and as I told you yesterday, it took me (who had never heard of this library) a minute to find out what you were missing. This simply isn't FFmpeg-related, the fact that the library doesn't show up in a list of external libraries that you most likely would have missed anyway is a bug but not one that ranks high on any list.
[03:03:49 CEST] <Kaedenn> Are there Python bindings for libffmpeg or libavconv?
[04:06:11 CEST] <Atlenohen> Cehoyos: sure that's right, I just wanted to clear out we both understand the same, I see now brcrypt.lib reported in the EXTRALIBS-avutil variable inside config.mak, not sure how do you guys feel about printing extralibs that at the end of thhe configuration process but it be kinda handy, for future new people dealing with it for example.
[08:34:26 CEST] <pranayvshah> Is there a way to explicitly set the shaper when using the subtitles filter? I know there is for the ass filter. FFmpeg v4.1.3 sets ass->shaping to 0 with my subtitles filter command; if I use ass and set shaper to complex everything works
[08:35:07 CEST] <pranayvshah> Even if there isn't a way, what can I do to have a value of 1 for ass->shaping
[11:02:56 CEST] <superware> how can I detect (from AVFormatContext/AVStream) that the opened media is a file OR a real-time stream?
[11:04:03 CEST] <while> I find vlc is having trouble playing a udp stream from ffmpeg, but it can be played with ffplay, is there a way to stream udp that vlc can read?
[11:04:22 CEST] <while> (both audio and video)
[11:05:20 CEST] <superware> while: output to "udp://ip:port?pkt_size=1316", and then try VLC
[11:06:11 CEST] <JEEB> superware: I think lavf didn't have a flag for that
[11:06:32 CEST] <JEEB> the previous mpv maintainer was pretty heavily herping a derp about that
[11:07:02 CEST] <Mavrik> superware: that would be a property of AVIOContext more
[11:07:04 CEST] <Mavrik> so something like
[11:07:23 CEST] <JEEB> seeking was already mentioned but something rtsp might have support for seeking
[11:07:26 CEST] <Mavrik> avformatcontext->pb->seekable == 0
[11:07:37 CEST] <JEEB> and yes, usually a protocol thing
[11:07:45 CEST] <JEEB> although then you have the stuff on top of HTTP etc
[11:12:50 CEST] <superware> while: output to "udp://ip:port?pkt_size=1316", I have a MediaInput raising PacketReady events, and a MediaPlayer receiving each packet, decoding the video stream and delaying (current_pkt_pts - last_pkt_pts), all that in a single thread. then I have a render thread being signaled for each delayed frame...
[11:13:15 CEST] <superware> Problem is the video isn't smooth at all, so I guess the pts sync is wrong..
[11:13:41 CEST] <superware> (forget the "output to" :)
[11:13:50 CEST] <while> I am trying your suggestion of output
[11:14:04 CEST] <while> $ ffmpeg -re -i output.ogg -vcodec mpeg4 -f mpegts 'udp://127.0.0.1:10000?pkt_size=1316'
[11:14:21 CEST] <while> is how I am currently issuing the command
[11:14:41 CEST] <JEEB> you probably want to do multicast into localhost
[11:14:50 CEST] <JEEB> that way multiple things can connect to it methinks
[11:15:01 CEST] <superware> I was asking about detecting a real-time streams because I thought frames sync should be different for file vs. stream
[11:15:30 CEST] <JEEB> yes, you may attempt low latency sync (aka ignoring some sync) with live streams
[11:15:57 CEST] <JEEB> so that you show video f.ex. as fast as possible
[11:16:03 CEST] <JEEB> as you receive the images from the decoder
[11:17:33 CEST] <superware> from my experience you must do some syncing since incoming packets can be received at different times
[11:18:37 CEST] <superware> only with syncing video will be smooth, otherwise they simply jitter, am I wrong?
[11:20:00 CEST] <Mavrik> What's syncing in this case?
[11:20:08 CEST] <Mavrik> You'll need to obey PTS for playback
[11:20:28 CEST] <superware> that's what I mean
[11:23:59 CEST] <while> so far adding the pkt_size option doesn't seem to have fixed it for VLC, but it still works in ffplay
[11:23:59 CEST] <superware> what's the most simple syncing method?
[11:24:30 CEST] <superware> while: I experienced VLC-udp issues, for me it worked
[11:27:54 CEST] <while> I notice in Wireshark, is seems the udp packets are coming right before icmp port unreachable messages
[11:28:24 CEST] <superware> while VLC is opening stream?
[11:28:44 CEST] <while> here is vlc's log if it helps: https://wieldfield.com/downloads/20190415_ISO8601_vlclog.txt
[11:28:56 CEST] <while> I have the VLC window open, and it still has the orange bouncing bar
[11:29:29 CEST] <superware> try udp://@:10000
[11:29:56 CEST] <while> superware: yes it works!
[11:33:01 CEST] <while> thank you
[11:34:42 CEST] <superware> while: update your blog posts regarding ffmpeg/udp/vlc :)
[11:35:12 CEST] <superware> it doesn't work without the "?pkt_size=1316", right?
[11:35:21 CEST] <while> I haven't tried it without that yet
[11:35:53 CEST] <while> I read that suggestion 2 other places, although trying with or without, both didn't work at the time
[11:36:44 CEST] <while> to answer your question though, it is working without the "?pkt_size=1316"
[11:37:21 CEST] <superware> Mavrik: after avcodec_receive_frame on the input thread, how should I calculate the delay in order to sync frames?
[11:42:18 CEST] <superware> until now, what USED to work for me was no sycning on input thread (since I only played realtime streams) and syncing the frames from queue on a render thread. but now since I want to play files, I MUST sync on the input thread or else it will read frames at the speed of light
[11:59:53 CEST] <superware> can someone please help me with how to sync frames (video-only)?
[12:00:31 CEST] <superware> how much should I delay before rendering current frame?
[12:02:05 CEST] <BtbN> Until the pts of the frame you want to present is reached
[12:14:15 CEST] <superware> and when is that for the first frame?
[12:18:52 CEST] <pk08> hello again
[12:18:52 CEST] <pk08> i am developing an application which scales (scale filter) muliple input streams and overlay on single nullsrc filter using complex filter
[12:18:52 CEST] <pk08> now i have problems in dts in output stream (outputing in h264(libx264) codec), Error: Application provided invalid, non monotonically increasing dts to muxer in stream
[12:18:52 CEST] <pk08> and it only outputs I frames, no B or P frames. Log: [libx264 @ 0xea9b40] frame=   0 QP=11.24 NAL=3 Slice:I Poc:0   I:8160 P:0    SKIP:0    size=4038 byte
[12:18:54 CEST] <pk08> can anyone please tell me how to fix these?
[12:20:30 CEST] <pk08> output stream config: https://pastebin.com/e9QpvHhb
[12:33:33 CEST] <pk08> rescaling packet: https://pastebin.com/QmR3MuCv
[13:14:34 CEST] <superware> BtbN?
[13:30:50 CEST] <pranayvshah> How/from where is this config_input function in vf_subtitles.c called please? https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_subtitles.c#L141
[13:35:36 CEST] <superware> How should I calculate delay between video frames in order to sync them for playback?
[13:40:46 CEST] <superware> (with the master clock)
[13:41:49 CEST] <BtbN> Like I said, based on the pts, presentation timestamps.
[13:41:55 CEST] <BtbN> If you substract them, you get your delay.
[13:46:21 CEST] <superware> but for real-time streams, frames can only be on-time OR late, so the delay isn't only based on pts subtraction, am I wrong?
[13:47:11 CEST] <superware> when you open a file, you always get frames before their presentation time
[13:55:13 CEST] <t3st3r> btw... does anyone knows if ffmpeg + VP9 supports "constrained quality" (CQ) mode in 2-pass mode and is it works with ffmpeg? Man/faqs/search results weren't conclusive.
[13:55:56 CEST] <t3st3r> That is - what happens with ffmpeg + livbpx if I both specify -crf and non-zero bitrate?
[13:56:10 CEST] <t3st3r> while doing 2 pass
[13:56:55 CEST] <JEEB> that's up to libvpx
[13:58:06 CEST] <JEEB> and the results differ between VP8 and VP9 most likely
[13:58:13 CEST] <JEEB> since google changed the behavior of various options in libvpx
[13:59:00 CEST] <pranayvshah> Hey JEEB, would you know how is this function called ? https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_subtitles.c#L141
[13:59:40 CEST] <t3st3r> This question about VP9 and how this particular combo + ffmpeg could/would perform.
[14:00:31 CEST] <JEEB> t3st3r: ok, then you should first request info from folk who know libvpx better. you could guesstimate how it works from the libvpx vp9 wrapper but after all the final decision making is up to libvpx
[14:00:34 CEST] <t3st3r> I've got idea I overall like CRF/CQ idea but I also like 2-pass. However I don't want "potentially unrestricted" bitrate.
[14:01:24 CEST] <t3st3r> hmm any ideas of better channel to ask this question?
[14:01:37 CEST] <t3st3r> do libvpx haves channel in freenode?
[14:24:05 CEST] <Atlenohen> Hey guys, these are all the warnings I get in my FFmpeg build, there's no problem, just checking if anyone thinks anything's worth taking a look at https://pastebin.com/6v9d2FWN
[14:28:43 CEST] <JEEB> t3st3r: I think at one point there was a #vp8 channel at least, also check the webm project's site
[14:39:52 CEST] <t3st3r> JEEB> it really here, let's see if someone here got idea, thanks.
[14:43:07 CEST] <kuznetsss> Hello, I am writing C++ application using FFmpeg libraries.
[14:43:09 CEST] <kuznetsss> Here is part my code: https://pastebin.com/UEeEvZwq
[14:43:11 CEST] <kuznetsss> I don't understand which function should initialize flags in AVOutputFormat which is inside AVFormatContext (format_context->oformat->flags)?
[14:52:51 CEST] <t3st3r> interesting, google's developer pages actually recommend doing what I described and at 1st glance it does more or less what could be expected.
[14:53:22 CEST] <Atlenohen> cehoyos: pkgconfig for ffmpeg isn't autogenerated so I couldn't have found out about bcrypt.lib that way, and in many places there doesn't appear to be windows compatible arguments, it uses /L almost everwhere instead of /LIBPATH:
[14:57:48 CEST] <t3st3r> Also ... I've got rather odd problem. I did realtime vp9 encode and managed to box it into some strange (bugged?) bitrate allocation.
[14:58:19 CEST] <t3st3r> At the end of day I've got some videos which look virtually perfect except some few frames that are AWFUL.
[14:58:27 CEST] <JEEB> libvpx's rate control is known to be funky
[14:58:29 CEST] <JEEB> have fun :)
[14:58:32 CEST] <t3st3r> (likely very low quantizer)
[14:59:03 CEST] <t3st3r> So the real quation is: are there way to programmatically detect such frames and chop 'em out under software control?
[14:59:14 CEST] <t3st3r> and could ffmpeg do that? :D
[15:00:04 CEST] <JEEB> nothing is impossible but do you really want to be working around libvpx's rate control in FFmpeg's wrapper or in your own API client :P
[15:01:03 CEST] <t3st3r> No, I don't want to work it around :). Seems thx to google dev pages and #vp8 I got idea I know how to make it more or less behave.
[15:01:48 CEST] <t3st3r> But I did few captures where I boxed rate-control decision pretty badly - and it elected to make perfect sequence at expence of few totally borkz0r3d frames :D
[15:02:27 CEST] <t3st3r> I'm 100% fine with just throwing these away (as they cause very unpleasant "oscillation" but I'm not sure how to detect 'em software way.
[15:02:38 CEST] <t3st3r> (and if ffmpeg can do it)
[15:02:53 CEST] <JEEB> theoretically everything is possible with enough code, the question is whether it's worth the while
[15:03:18 CEST] <JEEB> also if your results are due to boxing the rate control too much then maybe that should be tweaked instead :P
[15:03:32 CEST] <JEEB> or if there's a global "don't use quantizer higher/lower than X" option in libvpx
[15:03:35 CEST] <JEEB> :P
[15:03:43 CEST] <t3st3r> Hmm good answer. I've hoped it could be done by just ffmpeg commands. Say some filter "if ...quantizer is bogusly high ... drop it"
[15:04:17 CEST] <t3st3r> I've ofc tweaked it - but I have some captures I don't stand chance to recapture :D
[15:04:47 CEST] <JEEB> also the problem is if some other picture used that as reference
[15:04:52 CEST] <JEEB> that's now completely broken
[15:04:55 CEST] <t3st3r> at which point I've both sorted out bitrate control but also 2nd part is fixing what I already had.
[15:05:16 CEST] <JEEB> also I'm not sure if dropping random packets is OK in VP9; I don't remember if the coding engine's state is dependant on the pictures in the GOP
[15:05:27 CEST] <JEEB> you should ask the libvpx/VP9 folk regarding that to begin with :P
[15:05:36 CEST] <t3st3r> <JEEB> also the problem is if some other picture used that as reference <- not seems so. Somehow it did full-frames with very low Q
[15:05:55 CEST] <JEEB> otherwise even if you take a bad picture out, you might just cause regressions until the end of GO
[15:05:58 CEST] <JEEB> *GOP
[15:06:16 CEST] <t3st3r> er I mean it used very high q, so frame is grossly overcompressed and looks like tetris. But all frames around are fine.
[15:06:30 CEST] <t3st3r> (so bitrate control did really strange way of controlling bitrate)
[15:07:19 CEST] <t3st3r> so most obvious idea would be just drop these few offending frames and re-encode rest using more sane parameters :)
[15:08:32 CEST] <t3st3r> I've failed to find major damage on other frames - seems to be localized to certain frames - just them alone. I'd be damned, never seen such way to control bitrate in my whole life.
[15:09:45 CEST] <t3st3r> technically idea to notice you've exceeded allowed bitrate and grossly overcompress few frames is valid, but result looks ... strange.
[15:15:47 CEST] <t3st3r> I would surely use more sane bitrate control next time. Yet fixing few movies is an issue. Can ffmpeg filters see quantizers? -vf select is almost what I need. Except I can't readily formulate drop criterion.
[19:58:14 CEST] <Atlenohen> Hi
[19:58:30 CEST] <Atlenohen> Does x264 even support GOP = 1 ?
[19:59:02 CEST] <Atlenohen> I get High Intra at L4.2
[19:59:29 CEST] <Atlenohen> But the quality quicly boggles down to sometihng like worse than old nokia phone quality
[19:59:57 CEST] <Atlenohen> bitrate at 3000 kbps at around 1200x900
[20:01:18 CEST] <furq> just because it's intra-only doesn't mean it'll look good
[20:01:33 CEST] <furq> you still need to set appropriate quality settings
[20:03:54 CEST] <Atlenohen> Any other way to improve seeking then without having this quality destroying effect?
[20:04:22 CEST] <furq> use a higher bitrate
[20:05:02 CEST] <Atlenohen> Oh, okay, just checking if such a low GOP may be breaking some things, compat, stability ?
[20:05:17 CEST] <Atlenohen> maybe i could use 2,4 later on but we'll see
[20:05:30 CEST] <furq> i assume it has lower compatibility if it's using one of the intra profiles
[20:05:37 CEST] <furq> it obviously has a very negative effect on compressibility
[20:06:18 CEST] <furq> i assume you're doing this to feed into an NLE or something
[20:08:44 CEST] <Atlenohen> No rush tho I can play with it and see what I like, oh and I just played them with MVP this time, didn't test with other players yet
[20:13:48 CEST] <Atlenohen> It feels a bit better but the longer video plays the worse it gets
[20:50:59 CEST] <kepstin> Atlenohen: most of the efficiency of codecs like h264 comes from its ability to use predicted frames (P,B frames). if you turn that off by setting -g 1 then either your video will be *much* lower quality at the same bitrate, or it'll be *much* larger
[20:51:24 CEST] <kepstin> the gradual quality loss in 1-pass encode mode with bitrate set is just the bitrate controls taking a while to adapt to the situation.
[20:51:47 CEST] <kepstin> (if you did a 2-pass encode, the video would be consistently low quality)
[20:53:58 CEST] <kepstin> rather than setting gop size to 1, you'll normally want to compromise between seekability and file size. The default gop size for x264 is very large - lowering it down to ~1 second (e.g. -g 30 in a 30fps video) might be worth trying.
[21:27:49 CEST] <Atlenohen> kepstin: thanks for the explanation, I'll have to figure out the basics yes, aren't intra frames full ones or I have mistaken them?
[21:28:31 CEST] <kepstin> intra frames refers to frames that can be decoded on their own, without referring to data from other previously decoded frames.
[21:28:37 CEST] <Atlenohen> kepstin: efficiency in compression, efficency in encoding, that's different then, if it's just compression, then it just be a size thing, not a quality one but I goess it's a bit more complicated
[21:29:39 CEST] <kepstin> when referring to "efficiency" of a video codec, that almost always refers to "the bitrate required to achieve a certain quality level"
[21:31:06 CEST] <kepstin> note that x264 has an encoding mode (using the "crf" parameter) where you can (approximately) set a quality level you want, and let the encoder choose the bitrate required to achieve that.
[21:31:33 CEST] <kepstin> in many use cases, that's preferred over setting a bitrate
[21:32:03 CEST] <Atlenohen> Oh, this is an older implementation that uses fixed bitrate, not crf, I do actually know a thing about video transcoding since I did a lot of archiving in the past but I have to refresh some memory
[21:32:49 CEST] <Atlenohen> So I'm modifying the implementation, the ffmpeg api has probably changed since this was initially designed
[21:34:46 CEST] <Atlenohen> Oh 0 is for intra only, interesting.
[21:40:22 CEST] <cahoots> hi, do i need to pay royalties or anything if using ffmpeg's h.264 encoder?
[21:42:13 CEST] <kepstin> cahoots: ffmpeg doesn't include an h264 encoder, it normally uses the implementation from the x264 library
[21:42:38 CEST] <kepstin> cahoots: nobody here can give you a definitive answer on whether you need to pay patent royalties.
[21:45:23 CEST] <JEEB> cahoots: for software licensing the open source licenses under which we have modules (LGPL and/or GPL) are rather simple. if you're talking about patent licensing then unfortunately you will not find an answer in here
[21:48:43 CEST] <DHE> I would suggest googling "MPEG LA" and contacting your legal council
[22:23:30 CEST] <cahoots> kk thanks
[23:17:48 CEST] <phinxy> I can not get mp3 encoding recognized.  There is a /usr/lib/libmp3lame.so and I've configured with --extra-cflags='-I/usr/include --enable-libmp3lame'.  Could the reason ffmpeg does not find the lame encode have something to do with the error "WARNING: Libarary configuration mismatch"?  avutil, avcodec, avformat does not have the extra --enable-libmp3lame flag (WHY NOT?).
[23:20:24 CEST] <kepstin> phinxy: you should not need to set extra-cflags - you need to ensure your distribution's devel package for the lame library (which includes headers and pkg-config file) is installed
[23:20:48 CEST] <kepstin> phinxy: what command are you running that gives this library configuration mismatch error?
[23:22:07 CEST] <BtbN> --enable-libmp3lame inside of extra-cflags is also not going to do any good
[23:22:46 CEST] <phinxy> BtbN: Right -- It's not in the cflags
[23:22:58 CEST] <kepstin> phinxy: in your paste it was in the cflags
[23:24:10 CEST] <kepstin> (if you copy-paste text, please copy-paste it rather than retyping where possible to avoid typos, since that can really affect the meaning of the command)
[23:24:15 CEST] <phinxy> Let me get you the corrent ./configure flags I have used: https://termbin.com/q652e
[23:25:17 CEST] <kepstin> right, that looks fine. what does the output of ./configure with those options look like?
[23:25:42 CEST] <kepstin> although note that you shouldn't ever have to specify -I/usr/include
[23:26:15 CEST] <kepstin> because the include paths are loaded from pkg-config and set automatically
[23:27:15 CEST] <kepstin> if that doesn't work, it usually means that you need to install the -dev or -devel package from your distro (e.g. on ubuntu "apt-get install libmp3lame-dev"
[23:28:15 CEST] <kepstin> also note that after re-running configure with changed options, it's sometimes a good idea to "make clean" and do a fresh build (even tho that'll be pretty slow on a little arm box like that...)
[23:29:40 CEST] <kepstin> also, raspberry pis make terrible media processing platforms, when people come around with problems with them, the best advice is often "get a faster computer" :(
[23:30:46 CEST] <phinxy> Perhaps the installation of libmp3lame was not correctly done.  I might have put the headers in the wrong place or something
[23:34:06 CEST] <phinxy> I recall having difficulty compiling libmp3lame so I fetched the .so and the single header file from a ftp server.
[23:34:47 CEST] <kepstin> doesn't the distro you're running have it packaged?
[23:35:39 CEST] <phinxy> I just checked ftp.slackware.org.uk/slackwarearm-14.2 , cant find it
[23:36:07 CEST] <phinxy> hmm my package manager have it.
[23:36:14 CEST] <phinxy> why have I not installed it from there?
[23:37:25 CEST] <phinxy> I might have wanted to compile it "for fun" with my own configuration options.  I'll try get it from the package manager without overwriting the previous, customized version.
[23:39:10 CEST] <c_14> phinxy: what's the actual error you're getting
[23:43:21 CEST] <phinxy> c_14: https://termbin.com/hrlc https://termbin.com/rtwi
[23:44:34 CEST] <c_14> looks like you built a shared ffmpeg binary and it's linking against your system builds at runtime
[23:44:57 CEST] <c_14> either rebuild static (--disable-shared) or use LD_RUNTIME_PATH to set the correct lib path
[23:50:37 CEST] <phinxy> output of ./configure says "static yes" and libmp3lame is listed under External libraries.  https://termbin.com/rjvg
[23:51:49 CEST] <c_14> I'm not entirely sure what the preference is when both are enabled, you can always check by running `ldd' on the ffmpeg binary and checking if it links the libav* libraries
[23:51:56 CEST] <c_14> s/links/lists/
[00:00:00 CEST] --- Tue Apr 16 2019