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

[burek]

[00:39:25 CET] <buu> If I have two files that identify as gdq.2018.1515369400.mpeg: MPEG transport stream data and I want to join them together, one after the other, what magic do I need to have ffmpeg 'remux' the parts around the join so there's no disruption?
[00:44:52 CET] <kerio> ".mpeg" is not a thing, those should be .ts
[00:44:59 CET] <kerio> and you should be able to literally just cat them together
[00:48:58 CET] <furq> yeah .mpeg is normally mpegps, not mpegts
[00:49:31 CET] <kerio> furq: .mpeg is normally .mpg tho :^)
[00:49:39 CET] <furq> i've seen .mpeg
[00:49:50 CET] <furq> much like i've seen .jpeg
[00:50:40 CET] <furq> buu: concatenation is a bit tricky to get right without reencoding
[00:50:44 CET] <furq> https://trac.ffmpeg.org/wiki/Concatenate
[00:50:59 CET] <furq> either of those should work with mpegts, and like kerio said you should also just be able to cat 1.ts 2.ts > out.ts
[00:51:10 CET] <furq> either meaning the demuxer or the protocol
[00:51:32 CET] <furq> but yeah if you end up with audio glitches around joins then you might need to reencode
[00:55:33 CET] <buu> if I tell it to use a mpeg codec wouldn't it refuse to encode since it already is?
[00:58:46 CET] <furq> why would it do that
[01:00:23 CET] <buu> That seemed like my past experience
[04:48:02 CET] <Johnjay> buu: the default is to encode if you specify a codec, you have to say -c copy if you want copy
[05:14:34 CET] <buu> Well, ok then
[09:50:12 CET] <Kartagis> hi
[09:53:50 CET] <Kartagis> how can I add a language track to a .mp4? I tried -i video -i audio -map 0:v -map 1:a but it replaces the audio from the video. I tried using -i video -i video -i audio -map 0:v -map 1:v -map 2:a but it says Stream map '1:v' matches no streams.
[09:59:42 CET] <Kartagis> yippee. https://superuser.com/a/800251/319961 worked
[13:22:58 CET] <Imaster> Hi... Using FFMPEG, is it possible to add some custom atom in the header of a video file?
[13:23:29 CET] <Imaster> I need to add the term "loop" in the header of MP4 files before the "moov" atom
[13:23:37 CET] <Imaster> More information can be found here : https://stackoverflow.com/questions/44893316/whatsapp-video-as-gif-sharing-on-android-programatically
[13:23:51 CET] <Imaster> I o not want to edit the headers via too much calculations...
[13:24:12 CET] <Imaster> Is there a simple FFMPEG command to add the header "loop" to any MP4 files?
[13:25:34 CET] <Imaster> WhatsApp does a smart thing.. Their animated GIFs are actually MP4 files (which contain this atom "loop"), and the MP4 files which it wants to treat as videos in their UI, they do not add that "loop" atom
[13:25:45 CET] <Imaster> Actually the mp4 files do not loop...
[13:25:55 CET] <Imaster> Any FFMPEG experts, please help...
[13:26:24 CET] <Imaster> I tried loads of -loop and stream loop commands.. Nothing is adding the atom "loop" to my mp4 files
[13:27:59 CET] <Imaster> My current command for converting a GIF to MP4 is as follows :
[13:28:00 CET] <Imaster> ffmpeg -i giphy9.gif -c:v libx264 -c:a aac -pix_fmt yuv420p -movflags +faststart  giphy9_loop.mp4
[13:28:19 CET] <Imaster> I wish to add some parameter to the above command so that the output mp4 file has that "loop"
[13:28:26 CET] <Imaster> atom in the header
[14:03:19 CET] <strongcoffee> not sure where to ask this tbh but this isn't exactly crystal clear with what the dimensions of embedded MKV cover art should be. https://matroska.org/technical/cover_art/index.html
[14:04:12 CET] <strongcoffee> it gives examples of 960x600px for landscape cover art but then 600x800 for portrait. Does the height for portrait not matter? Confused as to the exact max dimensions as the '600' statements I don't find clear.
[14:27:27 CET] <dystopia_> are the meltdown/spectre fixes going to significantly harm ffmpegs performance?
[14:27:57 CET] <dystopia_> intel is saying home users won't notice a diffrence when opening email and browsing the web :|
[14:28:42 CET] <dystopia_> but thats seems like their way of saying if you are doing anything intensive you will have a big performance hit
[14:28:46 CET] <BtbN> define significantly
[14:28:59 CET] <BtbN> it slowd down syscalls
[14:29:02 CET] <BtbN> slows
[14:29:10 CET] <dystopia_> i get about 60fps encoding 1080i to 720p x264
[14:29:17 CET] <dystopia_> before fixes
[14:29:17 CET] <BtbN> adds 250~350ns per syscall
[14:29:45 CET] <strongcoffee> there were linux benchmarks of ffmpeg posted when its early patch was released here: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2
[14:30:13 CET] <strongcoffee> not very comprehensive, mind
[14:30:37 CET] <BtbN> memory-only ffmpeg operation will most likely not see any hit at all
[14:30:42 CET] <BtbN> lots of IO will see one
[14:31:37 CET] <dystopia_> thats seems encouraging strongcoffee / BtbN
[14:33:37 CET] <BtbN> nothing to be done anyway, the patches are mandatory for any system
[14:34:04 CET] <dystopia_> im on 7 so i could have avoided them
[14:34:18 CET] <dystopia_> but if it doesn't hit ffmpeg i will take them when they are ready
[14:34:20 CET] <BtbN> "on 7"?
[14:34:25 CET] <dystopia_> windows 7
[14:34:34 CET] <dystopia_> ie, updates are user choice, not enforced like 10
[14:34:38 CET] <BtbN> not updating Windows anymore from now on seems like a horrible idea
[14:34:45 CET] <dystopia_> it is
[14:34:59 CET] <BtbN> Windows 10 being more aggressive aboud updates is a good thing
[14:35:59 CET] <BtbN> n
[14:50:28 CET] <Fyr> guys, I have a broken TS, FFMPEG can mux it into MP4, not into MK4.
[14:50:28 CET] <Fyr> if I try to mux the file into matroska, it gives:
[14:50:28 CET] <Fyr> [matroska @ 00000000032ae4c0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[14:50:28 CET] <Fyr> [matroska @ 00000000032ae4c0] Can't write packet with unknown timestamp
[14:50:49 CET] <Fyr> why does it happen?
[14:57:15 CET] <CoreX> sounds like you have a fucked file, try using mkvmerge
[14:57:43 CET] <Fyr> CoreX, why muxing into MP4 works?
[15:02:48 CET] <pagios> quick question, is there any advantage of using pure rtp without rtsp when it comes to latency? i am thinking of media delivery withoutthe sdp overhead and such
[15:12:25 CET] <CoreX> Fyr i have no clue as im not a wizard
[15:22:34 CET] <kepstin> pagios: the sdp transfer and whatnot doesn't affect the video latency, it only affects the initial setup time
[15:23:09 CET] <kepstin> if you can arrange in advance so both sides already know what is streaming, when, where, then you could skip that so the setup is faster, sure
[15:26:26 CET] <pagios> kepstin, what is the advantage of the sdp
[15:27:12 CET] <kepstin> sdp is just one way of encoding all of the stuff you need to know to get rtp working (codecs, port numbers, ip addresses, etc)
[15:27:55 CET] <kepstin> it can do negotiation if both ends support different codecs or whatnot, but iirc ffmpeg doesn't support that
[15:35:14 CET] <pagios> if userA wants to communicate with userB using rtp, userA streams his data to user's B port and userB streams data from that port on his machine into his player? and vice versa?
[15:38:37 CET] <kepstin> more complicated than that - if you're doing 2-way streaming, both directions are set up more or less independently.
[15:39:05 CET] <kepstin> ffmpeg only supports 1-way media using its builtin rtp
[15:39:51 CET] <dradakovic> May i know what the parameter max_delay does in FFMPEG? And in what unit is the value of this parameter?
[15:40:56 CET] <kepstin> not totally sure what it does, but the unit is in microseconds (which I found out quickly by reading the man page)
[15:41:27 CET] <kepstin> it probably depends on the output format (container) what exactly that option does, or if it does anything at all
[15:42:45 CET] <dradakovic> Thank you kepstin. It does indeed to something. My output is mpegts on udp. I see that the graph monitoring the stream gets changed if i manipulate this option
[15:46:52 CET] <DHE> it's listed as 'maximum muxing delay' and the mpegts muxer does use it
[15:50:16 CET] <dradakovic> Does that mean that it is easier for the stream to have more delay?
[17:03:49 CET] <JonG_> I am trying to perform a complex filter to merge two videos one after the other. The output video appears to have black frames in it where the input videos do not (at the end of the first and second video). The FFmpeg command and output is here: https://pastebin.com/vp0E8uuV. I understand there are easier ways to concatenate two videos, but this is a simplification of a more complicated command. The input files are here: https://we.tl
[17:05:12 CET] <JonG_> I made the input files using Android MediaCodec, so I suspect there may be some issue with the timings of frames or something. FFmpeg does not output any warnings though.
[17:58:01 CET] <the_k> https://bitcointalk.org/index.php?topic=145386.0
[17:58:10 CET] <the_k> just some random google match
[17:59:16 CET] <the_k> i'll just use bitcoin core
[18:00:50 CET] <klaxa> okie-dokie
[19:34:34 CET] <Syffer> hi guys
[19:37:37 CET] <Syffer> I've a little problem, i'm wondering if you could help, i've been testing encoding HDR UHD content, and well it's working pretty fine now except that I don't seem to be able to get the total duration of the video. So i can't navigate in it with any video player. You can see my encore cmd on windows here: https://pastebin.com/pXbKsfDf
[19:39:25 CET] <Syffer> It's probably just a missing parameter on ffmpeg side when piping to x265, but can't find any clue google
[19:39:35 CET] <Fyr> Syffer, what does ffprobe "F:\my_vid_out.mkv" return?
[19:42:17 CET] <Syffer> Fyr: here is the result https://pastebin.com/g9j92mji
[19:42:49 CET] <JEEB> ok, so your output file name is .mkv but it's just raw HEVC
[19:42:59 CET] <JEEB> which is why it's not seekable :P
[19:43:09 CET] <Fyr> Syffer, try to remux with FFMPEG or use FFMPEGto convert video.
[19:44:36 CET] <Syffer> Oh yeah, I indeed just named it mkv like the source file, but I didn't know i had to contain it in matroska again
[19:44:46 CET] <Syffer> ffmpeg can go that ?
[19:44:58 CET] <Syffer> do*
[19:45:27 CET] <JEEB> yes
[19:45:54 CET] <JEEB> if you tell ffmpeg to output matroska with either -f matroska or by having the output file name be "SOMETHING.mkv" it will write matroska
[19:46:15 CET] <JEEB> if you just want to remux you can do `ffmpeg -i INPUT -c copy OUT.mkv`
[19:46:19 CET] <JEEB> which should just remux
[19:48:58 CET] <Syffer> JEEB: I got this with the remux: https://pastebin.com/M1ri2Z5F
[19:49:20 CET] <JEEB> oh the fun of libavformat
[19:49:31 CET] <JEEB> try -r FRAME_RATE before -i (the input)
[19:49:45 CET] <JEEB> -r "24000/1001" I guess?
[19:50:53 CET] <Syffer> Same error
[19:51:10 CET] <JEEB> file a bug then after making sure you're running the latest FFmpeg if possible
[19:51:13 CET] <JEEB> trac.ffmpeg.org
[19:51:43 CET] <JEEB> I knew there are issues with raw AVC/H.264 muxing, but this also shows that HEVC has the same thing
[19:52:23 CET] <JEEB> and it's IMHO not really acceptable that lavf's raw AVC or HEVC demuxer can come up with the frame rate value from the time base value in the bit stream but not make up the timestamps accordingly :P
[19:52:42 CET] <JEEB> Syffer: for mp4 use L-SMASH, or mkvtoolnix's mkvmerge gui for matroska then, unfortunately
[19:52:52 CET] <JEEB> latter has a GUI so you might prefer that
[19:53:11 CET] <Syffer> Yeah i use mvkmerge on regular basis
[19:53:21 CET] <Syffer> witj mkvtoolnix
[19:53:24 CET] <Syffer> with*
[19:53:35 CET] <Syffer> Itwould do the trick too ?
[19:53:42 CET] <JEEB> yes
[19:54:30 CET] <JEEB> also if you encoded with libx265 through FFmpeg the encoder would generate the timestamps and thus that would work as well
[19:54:55 CET] <JEEB> but now that you already have raw "annex b" HEVC stream the reader for that is herping a derp
[19:55:07 CET] <JEEB> I remember having some discussions about these issues in Paris last september
[19:55:13 CET] <JEEB> at the yearly meet-up
[19:55:15 CET] <Syffer> would I be able to use exactly the same parameters ? hdr (master display and such)...
[19:55:27 CET] <sfan5> yes, there's an -x265-params option
[19:55:33 CET] <JEEB> yes, since in the worst case -x265-params exists
[19:55:44 CET] <Syffer> damn I took the hard way
[19:55:48 CET] <JEEB> which lets you put libx265 parameters as key-value pairs into libx265 itself
[19:55:59 CET] <JEEB> so as long as you know what the API key and value are
[19:56:06 CET] <sfan5> JEEB: s/worst case/usual case/ the encoder supports barely any useful settings
[19:56:08 CET] <JEEB> you can do -x265-params "key=value:key=value"
[19:56:18 CET] <sfan5> apart from crf, preset and sucjh
[19:56:20 CET] <sfan5> such*
[19:56:30 CET] <JEEB> yea I remember stuff like maxrate/bufsize even missing :)
[19:56:42 CET] <Syffer> well yeah that's why i took directly x265
[19:56:50 CET] <Syffer> but didn't see the x265-params
[19:56:57 CET] <Syffer> will try that
[19:57:14 CET] <JEEB> yea, x264 has a similar thing where it parses key=value:key=value pairs and just pushes them to the library
[19:57:17 CET] <sfan5> ffmpeg -h encoder=libx265 can be quite useful if you're searching for something specific
[19:57:37 CET] <JEEB> thus FFmpeg itself doesn't even try to do anything more than just parse the key and the value
[19:58:04 CET] <JEEB> sfan5: I wish I cared more about x265 ;)
[19:58:12 CET] <JEEB> I should probably do another round of tests with it
[19:58:18 CET] <JEEB> (and be disappointed, har har)
[19:58:29 CET] <sfan5> heh
[19:58:51 CET] <JEEB> it's good for low bit rate scenarios though
[19:58:58 CET] <Syffer> Haha why are you disappointed ?
[19:59:33 CET] <JEEB> Syffer: when you get to the ranges of "I want to keep as much detail as possible with OK bit rates", the encoder is much less optimized with the new HEVC tools
[19:59:35 CET] <Syffer> I mean it's usefull only for uhd content, I still prefer x264 for FullHD
[19:59:47 CET] <JEEB> I mean, even for UHD stuff
[19:59:58 CET] <JEEB> although the 64x64 coding units do kinda help there
[20:00:08 CET] <JEEB> but the detail retention is still meh
[20:00:14 CET] <sfan5> which "new HEVC tools"?
[20:00:16 CET] <Syffer> I agree on the details
[20:00:25 CET] <sfan5> or am i just stupid
[20:00:26 CET] <JEEB> sfan5: SAO, >16x16 coding units
[20:00:31 CET] <sfan5> oh
[20:00:36 CET] <JEEB> everything that HEVC added
[20:00:48 CET] <JEEB> aka "what wasn't possible to copy from x264"
[20:01:26 CET] <JEEB> Syffer: yea, basically if you want to squish a somewhat watchable video into the lowest bit rate then x265 is OK
[20:01:36 CET] <JEEB> both AVC and HEVC would suck, but HEVC would suck less
[20:01:47 CET] <JEEB> that's what I call a low bit rate scenario :P
[20:01:55 CET] <Syffer> the lack of details is why i still choose x264 over x265 in any other scenarios, but since UHD content has naturally more details, well it kind of compensate. But x264 still does better in terms of quality yes.
[20:02:11 CET] <JEEB> x264 had so much love put into it :D
[20:02:16 CET] <JEEB> x265 kind of doesn't
[20:02:25 CET] <JEEB> since it's MCW's baby and the "community" never came to be
[20:02:26 CET] <Syffer> but having 40G movies on my drive is herrrr
[20:02:45 CET] <Syffer> so i have to go for hevc now :<
[20:02:56 CET] <JEEB> the other primary reason for HEVC is because HW decoders generally support 10bit with it, so that + HDR metadata
[20:03:44 CET] <Syffer> HDR hasn't been implemented in x264, never tried to see if it existed ?
[20:04:02 CET] <JEEB> Syffer: the metadata is there in AVC as well just fine
[20:04:12 CET] <JEEB> it's just that HW decoders generally didn't support 10bit AVC
[20:04:21 CET] <JEEB> so even if x264 could encode it, it was never widely used
[20:04:32 CET] <Syffer> Oh ok
[20:04:47 CET] <JEEB> I mean, 10bit AVC was pushed for its better compression capabilities in specific niche areas
[20:04:57 CET] <JEEB> and streaming companies wish they could use it
[20:05:16 CET] <JEEB> but the lack of end-user HW decoders meant it never was ubiquitous
[20:05:22 CET] <JEEB> (or however that word was written)
[20:06:07 CET] <JEEB> basically some streaming person tested and noted that switching x264 to 10bit was more useful than keeping to 8bit and using a slower profile, which was a fun thing to learn :)
[20:06:50 CET] <Syffer> Yeah i guess that's why it's so widely used in fansub communities
[20:06:59 CET] <Syffer> anime and such
[20:07:06 CET] <JEEB> that's the niche thing I mentioned, yes
[20:07:57 CET] <Syffer> (My merging is done and i've got my video duration now o/ )
[20:08:03 CET] <Syffer> (Thanks a lot :) )
[20:08:06 CET] <JEEB> since the video is now in a container, yes :)
[20:08:13 CET] <JEEB> with an index n' all
[20:08:21 CET] <Syffer> good guy index
[20:08:25 CET] <Syffer> indexing and shit
[20:08:39 CET] <JEEB> instead of [00 00 00 01][data][00 00 00 01][data]
[20:10:57 CET] <Syffer> I will do a comparison batch with source/result now, but i'm pretty happy of what i just saw.
[20:11:55 CET] <Syffer> I just don't have the HDR screen yet... But well, maybe when they will produce rec2020 display i will buy one
[20:12:46 CET] <sfan5> you could buy a 4K/HDR TV and use it as display
[20:12:56 CET] <sfan5> just a little too big likely
[20:13:11 CET] <Syffer> well i'm talking about a TV
[20:13:25 CET] <Syffer> but they just have reach 100% of DCI-P3
[20:13:35 CET] <Syffer> so they're still far from rec.20202
[20:13:37 CET] <Syffer> -2
[20:14:47 CET] <Syffer> didn't see if these new laser video projectors is CES have some colors to give
[20:15:36 CET] <Syffer> (and all of that to watch post-prod filters which ruins colors :D)
[20:16:33 CET] <Syffer> anyway i'm hungry, thanks a lot for you help sfan5 JEEB Fyr
[20:26:41 CET] <lomancer1> I am updating some code which used ffmpeg 2.7 to work with 3.4 and a ton of functions i used to use are now deprecated is there an easy way to figured out what replaced deprecated functions?
[20:28:04 CET] <JEEB> the APIChanges document should mention the alternatives
[20:28:13 CET] <lomancer1> thanks!
[20:28:13 CET] <JEEB> alternatively, take a look at the examples in docs/examples
[20:28:33 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/APIchanges
[20:28:36 CET] <JEEB> APIchanges
[20:28:53 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc/examples
[20:28:54 CET] <JEEB> examples
[20:29:14 CET] <JEEB> do note that the examples aren't perfect either, but at least in *general* should be OK
[20:55:48 CET] <fenix333> Hello everyone <3
[20:56:15 CET] <fenix333> I would love to know if its possible to stream a silent video and shuffle music?
[20:56:21 CET] <fenix333> I already searched but found nothing
[20:57:09 CET] <JEEB> I would probably recommend an API client that utilizes the FFmpeg libraries to do that
[20:57:31 CET] <JEEB> so that it would generate "empty" stuff if no inputs/playlist are defined and otherwise whatever was picked
[20:57:48 CET] <JEEB> ffmpeg.c isn't really meant for dynamic stuff like that
[20:58:29 CET] <fenix333> Hmmm Im understanding. Cause my idea was to do a simples 24/7 music live stream
[20:58:35 CET] <fenix333> simple*
[20:59:02 CET] <fenix333> You know some better solution?
[21:00:18 CET] <JEEB> the best solution I could come up with would be a dynamic API client for FFmpeg's libraries
[21:00:26 CET] <JEEB> no idea if someone has made such (probably has)
[21:05:53 CET] <TekniQue> so, question, how can I print what the filter graph looks like for a given ffmpeg command? See what filters it added by itself
[21:06:40 CET] <JEEB> not sure at which point they get logged, but -v verbose or -v debug should have it (debug is really long)
[21:06:51 CET] <JEEB> there's a nice visualization function in lavfi which IIRC ffmpeg.c doesn't utilize
[21:07:09 CET] <JEEB> in theory you could patch ffmpeg.c to use that to print out the filter chain
[21:07:15 CET] <TekniQue> ok
[21:07:43 CET] <TekniQue> I have a performance problem, with a single thread running out of CPU and lagging the entire chain
[21:08:18 CET] <JEEB> also there's a parameter you can set in lavfi that is basically "don't implicitly add anything to the chain"
[21:08:20 CET] <TekniQue> and I'm wondering if I can insert a buffer or something to split threads
[21:08:43 CET] <TekniQue> split filters across thread boundaries
[21:09:21 CET] <TekniQue> because I've got 10 cores but the process is lagging on the performance of a single core
[21:09:32 CET] <TekniQue> and the rest are idle
[21:09:49 CET] <fenix333> @jebb thank you very much! One last questions, what would be the best words to search for it?
[21:10:24 CET] <JEEB> fenix333: no idea, unfortunately :P
[21:10:35 CET] <JEEB> other than "streaming server something"
[21:10:40 CET] <fenix333> ahaha
[21:10:43 CET] <JEEB> although that mostly brings you media servers, not transcoding ones
[21:10:59 CET] <fenix333> okok thank you very much <3
[21:11:12 CET] <JEEB> (media servers serve data they are fed by encoders, basically)
[21:11:23 CET] <JEEB> which is how most streaming setups work
[21:12:01 CET] <fenix333> Ahh thanks for the info
[21:30:26 CET] <Tobit> Hello, I wish to down sample 24/192 pcm file to 24/176 pcm and change the sample rate from 192000 to 176400.  I tried, ffmpeg -i input.wav -ar 176400 output.wav, and the output was 16/176 so I tried, ffmpeg -i input.wav -sample_fmt s32 -ar 176400 output.wav, and it errored with, invalid or unsupported sample format.  Where should I got from here?
[21:31:31 CET] <Tobit> er, go
[21:32:49 CET] <Tobit> i also tried using other versions of sample format notation, based on what ffmpeg itself seems to use and also what alsa uses
[21:32:58 CET] <Tobit> got same result
[21:33:34 CET] <Tobit> do i need to specify a codec to ffmpeg?
[21:36:44 CET] <sfan5> seems like ffmpeg does not support putting 24-bit audio into wav
[21:37:25 CET] <sfan5> ah no, that's just the wrong option
[21:37:37 CET] <sfan5> Tobit: -c:a pcm_s24le
[21:38:32 CET] <Tobit> sfan5: ahh, i will try that one.  i saw that in a thread but it was dealing with video and i didn't understand the context.
[21:38:59 CET] <Tobit> i am only changing a wav to another wav so all audio, but ill try it
[21:43:11 CET] <Tobit> sfan5: cool, man, that was it<grin>
[21:43:37 CET] <Tobit> thanks
[21:45:35 CET] <oborot> Has anybody manage to get this guide working? https://trac.ffmpeg.org/wiki/CompilationGuide/Centos
[21:46:02 CET] <oborot> I'm running into issues compiling libx264, I get the error: "Found no assembler. Minimum version is nasm-2.13"
[21:46:14 CET] <oborot> They have a warning about that with a proposed solution, but it doesn't seem to work.
[21:46:32 CET] <oborot> I guess it can't find my nasm binary
[21:46:40 CET] <atomnuker> no, its too old
[21:47:05 CET] <oborot> My binary is old, or the guide is old?
[21:47:37 CET] <atomnuker> binary
[21:48:01 CET] <oborot> Well, it's 2.13.02
[21:48:37 CET] <oborot> I don't even have nasm pre-installed as the guide suggests
[21:48:44 CET] <atomnuker> it can't find it then
[21:49:19 CET] <oborot> Is there an argument I can pass to help it? I'm installing it under root if it matters.
[21:50:18 CET] <oborot> as in the root user
[21:50:31 CET] <oborot> Only because I'm doing this inside of a docker container
[21:50:44 CET] <oborot> Just trying to get a static binary, them I'm scrapping it
[21:51:21 CET] <oborot> nasm is sitting under $HOME/bin
[00:00:00 CET] --- Thu Jan 11 2018