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

[burek]

[08:42:46 CEST] <stevenliu> Hi guys, i get a problem about the vf_hue   ./ffmpeg -f lavfi -i color=red -filter_complex "hue=h=90" -vframes 1 test.png   the test.png is green, value:0e9400     when i use Canvas try the red color mp4 file: ctx.filter = 'hue-rotate(70deg)'; ctx.drawImage(v,0,0,270,135);    the color value is = 005b00,   is the hue have problem?
[08:43:21 CEST] <stevenliu> I use the WeVideo preview, the color is same with Canvas color
[08:58:27 CEST] <blap> my current project - shader all the windows https://abload.de/img/noisebacktjl01.png
[09:19:50 CEST] <Nacht> Anyone ever did something with adding transparent bumpers to your video ?
[11:58:36 CEST] <lethalwp> i can hwdecode hevc on an rxvega with opensource amdgpu,  but on another system with more or less the same driver/ffmpeg/... versions and rx480 i get the following error:[ffmpeg] AVHWFramesContext: Failed to create surface: 14 (the requested RT Format is not supported).
[11:59:00 CEST] <lethalwp> could this be some kind of bug? should i try with a git ffmpeg on both systems?
[12:04:46 CEST] <jkqxz> This is 10-bit H.265?  Probably an older Mesa without 10-bit support.
[12:05:42 CEST] <lethalwp> jkqxz, yes 10bits, ok will check mesa (mpv maybe got statically linked..)  thx for the hint
[12:07:43 CEST] <lethalwp> jkqxz, my mpv is dynamically linked for mesa and use "ii  libgl1-mesa-glx:amd64                        1:17.3~git171011125800.b20bccb~x~padoka0"
[12:09:43 CEST] <jkqxz> Paste the whole log somewhere?
[12:47:47 CEST] <Fyr> guys, I can't find description of -bf option. what does it do?
[12:50:14 CEST] <furq> b-frames
[12:50:43 CEST] <furq> it's an encoder private option but it's shared by (presumably) every encoder that supports b-frames
[12:50:52 CEST] <Fyr> oops
[12:51:07 CEST] <Fyr> perhaps, this option should be added to the documentation.
[12:51:22 CEST] <furq> it is
[12:51:24 CEST] <furq> https://www.ffmpeg.org/ffmpeg-codecs.html
[12:51:30 CEST] <furq> it's there with the other encoder private options
[12:51:47 CEST] <Fyr> I've grepped http://ffmpeg.org/ffmpeg-all.html
[12:51:57 CEST] <furq> search for "bf", not "-bf"
[12:52:36 CEST] <furq> that page is also missing a lot of encoders
[12:52:44 CEST] <furq> you're better off using -h full or -h codec=libx264 or whatever
[12:53:25 CEST] <Fyr> -h encoder=h264_nvenc
[12:53:30 CEST] <Fyr> it lacks of it.
[12:54:20 CEST] <furq> http://vpaste.net/cf8U5
[12:54:44 CEST] <Fyr> yes, no bf there.
[12:55:26 CEST] <furq> shrug
[12:58:05 CEST] <uorbe001> Hi, we are trying to create videos with ffmpeg on the fly and pipping those to http clients. We have this working for desktop browsers and android, but we've hit a roadblock with ios. We've come to the conclusion that the problem we have with ios is that when the video isn't served with a byte-range header, it just refuses to load it (and we don't know the byte-range because we don't have the full-video when served).
[12:59:16 CEST] <uorbe001> we are wondering if it is calculate to generate the length of the video with ffmpeg before the video itself is created, does anyone know? Or an alternative solution to the problem if someone has gone through it before?
[13:02:55 CEST] <c_14> uorbe001: sounds like you wanted chunked http
[13:03:02 CEST] <c_14> -ed
[13:12:30 CEST] <uorbe001> c_14: you might be right, I haven't looked at chunked http yet, gotta check with my coworker if he has.
[13:32:52 CEST] <Fyr> guys, is it possible to use two-pas encoding with NVENC?
[13:33:01 CEST] <Fyr> google gives something incomprehensible.
[13:35:30 CEST] <Fyr> >>"-rc vbr_2pass -rc-lookahead
[13:35:30 CEST] <Fyr> 32" to the command line. The encoder cannot actually do two full passes, but it
[13:35:30 CEST] <Fyr> can look ahead up to 32 frames, which acts as a substitute for 2-pass encoding
[13:35:30 CEST] <Fyr> and can improve the picture quality a lot especially around I-frames.
[14:05:33 CEST] <BtbN> Fyr, nvenc does not support twp pass encoding.
[14:06:09 CEST] <Fyr> -h encoder=h264_nvenc hase options like -2pass 1 and -rc vbr_2pass
[14:06:13 CEST] <Fyr> ='(
[14:08:24 CEST] <furq> yeah nvenc decided to call lookahead "2-pass"
[14:08:37 CEST] <furq> because apparently they suffered some kind of terrible head trauma
[14:09:00 CEST] <Fyr> is there a way to imporve quality with NVENC?
[14:10:26 CEST] <furq> probably -preset hq
[14:10:37 CEST] <Fyr> ='(
[14:10:45 CEST] <Fyr> it brings nothing. =(
[14:10:50 CEST] <furq> maybe -preset slow is better
[14:11:18 CEST] <furq> nvenc is never going to be able to compare with x264
[14:12:02 CEST] <BtbN> That's some other kind of two-pass. Not encoding in two passes.
[14:12:34 CEST] <BtbN> if you want good quality from nvenc, you need to throw more bitrate at it
[14:13:01 CEST] <furq> are there docs somewhere about what the presets actually enable
[14:13:16 CEST] <BtbN> Only the ones ffmpeg made up
[14:13:19 CEST] <furq> i assume slow enables AQ and stuff
[14:13:21 CEST] <BtbN> which is just slow/medium/fast
[14:13:32 CEST] <BtbN> The ones coming from the driver are pretty much opaque
[14:14:01 CEST] <furq> fun
[14:14:33 CEST] <furq> Fyr: you should probably manually enable b-adapt, aq etc just to make sure you're not missing anything
[14:14:49 CEST] <Fyr> ok
[14:15:45 CEST] <uorbe001> c_14: I just checked and it appears ios wants the range to be provided even if using the chunked transport encoding, so unless I misundertood what you mean I'm back to needing the size of a video we haven't yet finished generating :(. Thanks for the suggestion though.
[14:16:59 CEST] <furq> that doesn't sound right
[14:17:07 CEST] <furq> the whole point of chunked is for when the response size isn't known
[14:17:32 CEST] <c_14> uorbe001: yeah, but you know the range for each chunk
[14:20:28 CEST] <uorbe001> Oh, you are both right, the range header doesn't need the full size (got mixed up with the content-range), we might be able to make that work then.
[14:20:44 CEST] <uorbe001> Thanks, will try that!
[14:27:33 CEST] <stevenliu> furq: ping
[14:28:03 CEST] <stevenliu> http://bbs.chinaffmpeg.com/a.html  i get a problem about the ffmpeg avfilter hue
[14:28:46 CEST] <stevenliu> the result different with chroma/firefox canvas filter
[15:17:02 CEST] <Xogium> so, trying to encode from alsa to rtp, I used this command like: ffmpeg -f alsa -i hw:0,0 -acodec libopus -ac 1 -b:a 20k -re -f rtp rtp://234.5.5.5.5. However despite this I get that message: [alsa @ 0xaaaade80b240] cannot set channel count to 2 (Invalid argument). Why is it trying to use 2 channel when I asked -ac 1 ?
[15:17:39 CEST] <Xogium> my mic is mono only so obviously 2 channels will fail
[15:27:59 CEST] <Xogium> seems like no matter what value I set the -ac option to, it's completely ignored
[15:28:35 CEST] <DHE> you're confusing the inputs and outputs
[15:28:35 CEST] <Xogium> I tried 3.1 or even 6 for fun, still I see ffmpeg trying to use 2
[15:28:39 CEST] <Xogium> hmm
[15:28:48 CEST] <DHE> ffmpeg [input-options] -i input1  [output-options] output1
[15:28:56 CEST] <DHE> you put "-ac 2" into the output-options side
[15:28:58 CEST] <Xogium> so where should I put that ? Before the -acodec option ?
[15:29:11 CEST] <DHE> it'll have to go before -i hw:0,0
[15:29:17 CEST] <Xogium> oh
[15:29:19 CEST] <BtbN> you should also use -c instead of the old acodec/vcodec
[15:29:37 CEST] <Xogium> I thought input option were not finished until the -acodec part
[15:29:49 CEST] <BtbN> the acodec is an output option.
[15:30:00 CEST] <Xogium> right
[15:31:54 CEST] <Xogium> is the rest of my command line fine then ? I used -c instead of -acodec
[15:32:30 CEST] <Xogium> also I guess ffmpeg can't do srtp ?
[15:33:07 CEST] <zerodefect> There has been work happening on srtp. Not sure how far along it is :)
[15:35:04 CEST] <zerodefect> Here is something from 2014: https://stackoverflow.com/questions/21433027/using-ffmpeg-for-stream-encryption-by-srtp-in-windows
[15:35:30 CEST] <zerodefect> That individual was perhaps unsuccesfful, but I'd be amazed if it doesn't work.
[15:37:01 CEST] <Xogium> I tried -f srtp and srtp::// address but doesn't seem like it's a suitable protocol
[15:48:08 CEST] <Xogium> also using a :1234 at the end of the url is the correct way to specify a port or not ? Guess not sinc ffmpeg is using 38686 and 38687
[15:48:22 CEST] <Xogium> *since
[16:02:54 CEST] <DHE> also, don't use -re. your source material (physical hardware capturing real-time events) is already going to cause a real-time bottleneck
[16:06:02 CEST] <Xogium> okay
[16:06:31 CEST] <Xogium> I still can't figure the whole rtp range and port stuff either
[16:08:49 CEST] <fred1807> I am creating a slideshow using https://trac.ffmpeg.org/wiki/Slideshow. Generated movies plays fine on desktop VLC, but omxplayer acused of bad framerate , and wont play it.  Can I improve framerate information?
[16:09:00 CEST] <fred1807> used: ffmpeg -framerate 10 -pattern_type glob -i '*.jpg' -c:v libx264 -pix_fmt yuv420p out.mp4
[16:27:03 CEST] <Xogium> so I tried to use the ports that I see in ss -tulp in vlc, both refuses to play anything, same for my attempt at using port 1234
[16:28:28 CEST] <c_14> Xogium: IPv4 addresses have 4 octets, not 5
[16:28:37 CEST] <c_14> also, ffmpeg will output the sdp info on stdout
[16:28:41 CEST] <c_14> the client needs that
[16:29:16 CEST] <Xogium> with this exact formatting ?
[16:29:34 CEST] <c_14> yeah
[16:29:38 CEST] <c_14> usually as a file input
[16:29:52 CEST] <c_14> you can use the -sdp_file option to write the info to a file instead
[16:30:50 CEST] <Xogium> mmh, alright, let's try this
[16:36:40 CEST] <c_14> And srtp should work just fine as well, needs -f rtp srtp:// as well as an -srtp_out_suite and -srtp_out_params
[16:37:52 CEST] <Xogium> meh, vlc doesn't list the sdp file
[16:40:25 CEST] <Xogium> and if I force it to take it it doesn't play
[16:41:33 CEST] <Xogium> I'll try to see why..
[16:41:38 CEST] <c_14> https://wiki.videolan.org/SDP
[16:41:40 CEST] <c_14> *shrug*
[16:43:28 CEST] <Xogium> I'm flooded with gtk errors that makes it impossible to read anything else
[16:45:01 CEST] <c_14> try using mpv
[16:45:04 CEST] <c_14> that works for me
[16:45:13 CEST] <c_14> if that works, then the problem is somewhere in vlc
[16:46:24 CEST] <Xogium> so mpv <sdp file> ?
[16:47:50 CEST] <Xogium> error reading packets from lavf
[16:48:39 CEST] <Xogium> do I need something else to be open apart from udp port 1234 ?
[16:48:54 CEST] <Xogium> open to outside, that is..
[16:49:31 CEST] <c_14> yeah, port+1
[16:49:46 CEST] <Xogium> so 1235 as well ?
[16:49:52 CEST] <c_14> yes
[16:50:04 CEST] <Xogium> aww, rtp seems very complicated
[16:51:27 CEST] <Xogium> errr, same error
[16:51:39 CEST] <c_14> what's your current ffmpeg command?
[16:52:49 CEST] <Xogium> ffmpeg -f alsa -ac 1 -i hw:0,0 -c libopus -b:a 20k -ac 1 -f rtp rtp://10.0.0.1:1234 -sdp_file sdp.input
[16:54:54 CEST] <Xogium> but I definitely don't see ffmpeg binding to port 1234 in udp, only port 40514 and 40515
[16:55:45 CEST] <Xogium> yet it generates sdp with port 1234
[16:57:33 CEST] <Xogium> I even tried to set the rtcpport to 1235, nada
[16:57:44 CEST] <Xogium> still doing as it wants :D
[16:57:58 CEST] <Xogium> that is, completely choosing ports to bind to at random
[16:58:01 CEST] <c_14> is 10.0.0.1 the local or the remote address?
[16:58:15 CEST] <c_14> rtp is a push protocol, not a pull protocol
[16:58:21 CEST] <c_14> you have to send to the remote address
[16:58:29 CEST] <Xogium> it's the machine from where I run that ffmpeg command
[16:58:40 CEST] <Xogium> hmm
[16:58:45 CEST] <c_14> you have to put the address of the machine you're sending it to
[16:58:53 CEST] <c_14> (this is usually a multicast address)
[16:58:53 CEST] <Xogium> so I'd have to send to my laptop in this case
[16:59:03 CEST] <Xogium> or not
[16:59:45 CEST] <c_14> if you want to watch it on your laptop, you need to put your laptop's ip
[17:00:49 CEST] <Nacht> *listen
[17:00:58 CEST] <Xogium> hmmm, I will try that :D I'll understand how it really works someday
[17:01:16 CEST] <Xogium> this is very confusing for me, first time I mess with that
[17:01:27 CEST] <Nacht> Xogium: What are you trying to create then ?
[17:02:42 CEST] <Xogium> oh not something real pro, just trying to learn new stuff and get the lowest latency possible (that is while audio is still understandable and not too messed up)
[17:03:10 CEST] <Xogium> someone suggested me rtp so I'm trying that route
[17:05:26 CEST] <Xogium> oof, I, finally, got it :D
[17:06:02 CEST] <Xogium> but I'll need to amplify the audio on the fly, is this doable with ffmpeg ? Add some gain, I mean
[17:07:27 CEST] <iwkse> hi, I have some issues with cutting slices with ffmpeg. I have mp4 files (downloaded from youtube) and when I cut slices audio is out of sync. I've tried the aresample filter but it doesn't seem to work. I notice though, vlc shows it in sync but mplayer not. Any hint?
[17:08:20 CEST] <iwkse> Xogium: you can use filters
[17:08:36 CEST] <Xogium> kay, looking into it
[17:08:44 CEST] <Xogium> thanks all :)
[17:08:49 CEST] <iwkse> Xogium: http://ffmpeg.org/ffmpeg-all.html#loudnorm
[17:09:09 CEST] <iwkse> http://ffmpeg.org/ffmpeg-all.html#dynaudnorm
[17:10:08 CEST] <Johnjay> why would cutting slices cause desyncing of audio ?
[17:11:38 CEST] <iwkse> Johnjay: I don't know yet
[17:14:05 CEST] <Xogium> very interesting, it introduces an *extremely* high latency with loudnorm
[17:18:13 CEST] <Nacht> doesn't -af volume just do the trick ?
[17:19:38 CEST] <Xogium> heh, could do maybe.. Loudnorm is nice though but I guess it needs time to do its work
[17:24:04 CEST] <Xogium> yeah volume seems to do it
[17:25:48 CEST] <durandal_1707> volume may introduce clipping and distort audio
[17:27:47 CEST] <Xogium> nods, being careful with it, but loudnorm introduces like 15 seconds of latency
[17:42:15 CEST] <alexpigment> Xogium: normalization always introduces delay because it requires looking at the context of other volumes around it; it can't be done on the fly
[17:42:23 CEST] <alexpigment> it sounds like you need to use a compressor
[17:47:45 CEST] <Xogium> yeah I'm looking at other filters
[17:50:13 CEST] <Xogium> mic volume is too low even with the gain set to its max in alsamixer :O
[17:50:19 CEST] <Fyr> guys, is hdmv_pgs_subtitle a video format? can I pipe it?
[18:02:32 CEST] <alexpigment> Xogium: acompressor
[18:02:54 CEST] <alexpigment> https://ffmpeg.org/ffmpeg-filters.html#acompressor
[18:03:29 CEST] <Xogium> there is just so much things it can do, this software is amazing :D
[18:04:43 CEST] <WeiJunLi> im checking ffmpeg source code and im wondering if user can control the struct pointers *avctx and *avpkt
[18:04:56 CEST] <WeiJunLi> stands for AVCodecContext struct
[18:04:59 CEST] <WeiJunLi> and AVPacket struct
[18:05:09 CEST] <WeiJunLi> do user control struct member values on both cases?
[18:13:59 CEST] <WeiJunLi> anyone?
[18:16:14 CEST] <ChocolateArmpits> WeiJunLi, can you repost your problem, just got here
[18:16:27 CEST] <WeiJunLi> 17:04 WeiJunLi: im checking ffmpeg source code and im wondering if user can control the struct pointers *avctx and *avpkt
[18:16:27 CEST] <WeiJunLi> 17:04 WeiJunLi: stands for AVCodecContext struct
[18:16:27 CEST] <WeiJunLi> 17:04 WeiJunLi: and AVPacket struct
[18:16:29 CEST] <WeiJunLi> 17:05 WeiJunLi: do user control struct member values on both cases?
[18:16:41 CEST] <ChocolateArmpits> oh can't help there, sorry
[18:41:10 CEST] <blap> nice nickname
[18:43:57 CEST] <DHE> WeiJunLi: read avcodec.h or use the documentation viewer. the fields are described and specified whether they are meant to be read, written, or in what situations.
[18:44:21 CEST] <DHE> usually there's an indication of what is even intended to be public API and where the line between public and private is
[19:06:32 CEST] <WeiJunLi> DHE: tks
[19:07:53 CEST] <squarecircle> heyo
[19:09:06 CEST] <squarecircle> I created a test video from pure green RGB(0,255,0) png files
[19:09:39 CEST] <squarecircle> but ffmpeg reads them as (0,255,1)
[19:09:50 CEST] <squarecircle> any idea where to search?
[19:15:55 CEST] <JEEB> just out of interest, how did you test and did you make sure your test didn't include any colorspace conversions
[19:16:09 CEST] <squarecircle> so RGB(255,0,0) becomes RGB(254,0,0)
[19:16:14 CEST] <squarecircle> JEEB: no
[19:16:23 CEST] <squarecircle> JEEB: that may be a problem
[19:16:36 CEST] <squarecircle> Ill post my encoding and my decoding
[19:17:19 CEST] <JEEB> just pastebin the full command line and terminal output onto a pastebin and link here if you're using the command line application
[19:17:35 CEST] <squarecircle> JEEB: thats not possible ^^
[19:18:23 CEST] <JEEB> well then there's not really much for me to help with
[19:19:11 CEST] <squarecircle> JEEB: I call ffmpeg in a python subprocess
[19:19:19 CEST] <squarecircle> JEEB: feed it into my decoder
[19:19:24 CEST] <fred1807> any tip how could I fix a slideshow movie in mp4 container, so this raspberry pi's omxplayer wont complain and just play it?
[19:20:19 CEST] <JEEB> squarecircle: well you still are capable of receiving the stderr in python
[19:20:52 CEST] <JEEB> fred1807: I don't think you can fix it much more if the MMAL decoder just gives up on it, unless you re-encode it :P
[19:21:04 CEST] <JEEB> I would first though try it out with FFmpeg+mpv built with MMAL/rpi stuff
[19:21:13 CEST] <JEEB> then if that fails you can try re-encoding
[19:25:17 CEST] <fred1807> not a codec problem...
[19:25:30 CEST] <fred1807> problem seems to be with the container
[19:25:49 CEST] <fred1807> I am playing with omxplayer
[19:47:30 CEST] <koyglreg> When converting color spaces - say you're going from 4:2:0 to 4:4:4 - are there different algorithms for this?
[19:48:09 CEST] <koyglreg> Is it like encoding an 8-bit video into 10-bit, and introducing more colors?
[19:48:56 CEST] <JEEB> well with bit depths at the most you might have dithering when going downwards, but there's really nothing else than the "correct way" of doing it
[19:49:19 CEST] <JEEB> with 4:2:0 to 4:4:4 you hit scaling, where you have so many alternatives to choose from I won't even go further :P
[19:49:36 CEST] <JEEB> although generally as long as you're doing your scaling correctly it shouldn't really matter too much with the chroma scaling
[19:49:54 CEST] <JEEB> (since that's what in 4:2:20 is a single sample for 2x2 area, while in 4:4:4 each luma sample has its own chroma sample
[19:50:07 CEST] <koyglreg> ok, well here's something i actually come across.  i have 4:1:1 ntsc dv avi video.
[19:50:18 CEST] <JEEB> yes, which has even less chroma
[19:50:19 CEST] <koyglreg> and i want to convert it to yuv420p
[19:50:53 CEST] <koyglreg> yeah, so do i just put -pix_fmt yuv420p, or are there different algorithms beyond this generic paramter?
[19:50:56 CEST] <JEEB> which is just upscaling the chroma and most likely converting it to the top-left instead of whatever it was for the DV with regards to chroma location
[19:51:36 CEST] <JEEB> -vf format=yuv420p is what I prefer since it gets you used to the video filter chains :P but I have no idea if there's any different chroma upscaling algorithms available
[19:51:58 CEST] <JEEB> (nor am I sure if the chroma location difference is taken into account between DV and the more usual elsewhere thing)
[19:52:37 CEST] <koyglreg> hmm, didn't know you could change color space in "vf"
[19:53:08 CEST] <JEEB> it will also automagically insert conversions where "required"
[19:53:17 CEST] <furq> a lot of commands are just aliases for filters
[19:53:23 CEST] <JEEB> I mean, FFmpeg in general. you can have that logged with -v verbose
[19:53:26 CEST] <JEEB> I think at least
[19:53:33 CEST] <JEEB> if not, -v debug then tells you
[19:54:05 CEST] <koyglreg> i wonder if avisynth has different algorithms for chroma upscaling
[19:57:24 CEST] <JEEB> well the zscale filter at least lets you set the chroma location (it uses the zimg scaling/colorspace conversion library which vapoursynth also now uses) https://www.ffmpeg.org/ffmpeg-all.html#zscale
[19:57:33 CEST] <koyglreg> #avisynth
[19:57:54 CEST] Action: koyglreg meant to type /join #avisynth
[19:59:12 CEST] <koyglreg> JEEB: that is interesting.  i will look at that filter
[20:02:20 CEST] <koyglreg> ohhh... so if I theoretically separated a "YUV" video into three separate videos like this: https://en.wikipedia.org/wiki/YCbCr#/media/File:Barns_grand_tetons_YCbCr_separation.jpg
[20:02:59 CEST] <koyglreg> ... then I could apply whatever scaling algorithm to each channel, and then merge them again later.
[20:03:04 CEST] <koyglreg> could that be done?
[20:03:16 CEST] <Johnjay> so if I try to do ffmpeg with concat it chokes if the filename mylist.txt has ' anywhere in the file name
[20:03:22 CEST] <Johnjay> and without the exterior ' and ' it won't work at all
[20:03:30 CEST] <Johnjay> am I doing something wrong here?
[20:03:54 CEST] <Johnjay> should i just strip all ' out of filenames?
[20:04:47 CEST] <ChocolateArmpits> Johnjay, did you try using escape character?
[20:58:29 CEST] <CFS-MP3> I'm having a problem compiling the current FFMpeg on a freshly installed Ubuntu 16.04.3 LTS 64 bits
[20:58:36 CEST] <CFS-MP3> I've tried everything I could think of
[20:58:42 CEST] <CFS-MP3> but it always ends like this:
[20:58:55 CEST] <CFS-MP3> ffmpeg/libpostproc/version.h
[20:58:55 CEST] <CFS-MP3> ERROR: libmp3lame >= 3.98.3 not found
[20:59:46 CEST] <CFS-MP3> The end of the build log:
[20:59:47 CEST] <CFS-MP3> gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -I/home/captions/ffmpeg_build/include -std=c11 -fomit-frame-pointer -pthread -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/freetype2 -I/home/captions/ffmpeg_build/include -I/usr/include/freetype2 -c -o /tmp/ffconf.b0ukzlsd/test.o /tmp/ffconf.b0u
[20:59:48 CEST] <CFS-MP3> kzlsd/test.c
[20:59:48 CEST] <CFS-MP3> gcc -L/home/captions/ffmpeg_build/lib -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/ffconf.b0ukzlsd/test /tmp/ffconf.b0ukzlsd/test.o -lmp3lame
[20:59:48 CEST] <CFS-MP3> gain_analysis.c:(.text+0x2412): undefined reference to `__log10_finite'
[20:59:48 CEST] <CFS-MP3> lame.c:(.text+0x1c94): undefined reference to `cos'
[20:59:49 CEST] <CFS-MP3> lame.c:(.text+0x233f): undefined reference to `cos'
[20:59:49 CEST] <CFS-MP3> lame.c:(.text+0x2589): undefined reference to `cos'
[20:59:50 CEST] <CFS-MP3> lame.c:(.text+0x2625): undefined reference to `cos'
[21:00:02 CEST] <CFS-MP3> howver lame was compiled just fine
[21:00:35 CEST] <DHE> add -lm
[21:00:49 CEST] <CFS-MP3> DHE where? -lm appears in a number of places
[21:01:00 CEST] <DHE> oh this is from the config.log ?
[21:01:38 CEST] <JEEB> CFS-MP3: are you using pkg-config or without?
[21:02:07 CEST] <JEEB> also if you're doing static linking are you passing the --static flags in pkg-config options (there's a configure option for that)
[21:02:09 CEST] <CFS-MP3> JEEB I'm following the build tutorial completely - from a freshly installed Ubuntu
[21:02:22 CEST] <CFS-MP3> Just pasting, not adding anything myself at this point
[21:02:37 CEST] <DHE> I think this is the configure test and it's failing. like it's using the static .a library because there's no .so available?
[21:02:39 CEST] <JEEB> yea, but not like I know what this tutorial of yours is? can you post your full config.log
[21:02:47 CEST] <JEEB> on pastebin
[21:02:48 CEST] <CFS-MP3> It's strange because this has always worked for me, but something has changed I guess in this Ubuntu
[21:02:48 CEST] <JEEB> and link here
[21:02:57 CEST] <JEEB> CFS-MP3: no, it's FFmpeg trusting libraries more now
[21:03:01 CEST] <JEEB> which has brought a lot of "fun"
[21:03:11 CEST] <CFS-MP3> JEEB: This tutorial :-) https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[21:03:26 CEST] <JEEB> yes, please post the ffbuild/config.log in a pastebin or so
[21:03:29 CEST] <JEEB> and link here
[21:04:55 CEST] <JEEB> and yes, unfortunately that "guide" goes around static linking, which is the bane of everyone's pain so far because now that the configure script was changed to trust the pc files more it was found out that whadda you know, they lacked stuff :P
[21:05:23 CEST] <JEEB> I think I reviewed a change to add -lm globally now because of that but I don't think that got reviewed yet. the correct thing would be to change the pc file and add -lm to Libs.private
[21:05:40 CEST] <CFS-MP3> https://pastebin.com/CE3TeRXs
[21:05:42 CEST] <JEEB> thanks
[21:06:21 CEST] <JEEB> ugh, so that's not even pkg-config
[21:06:32 CEST] <JEEB> fuck all the library checks without pkg-config checks
[21:07:51 CEST] <CFS-MP3> Is the tutorial that needs updating, or some file?
[21:08:11 CEST] <JEEB> can you check how the LAME pc file looks like, btw?
[21:08:30 CEST] <JEEB> it's in your prefix under "$HOME/ffmpeg_build/lib/pkgconfig"
[21:08:34 CEST] <JEEB> and pastebin that one
[21:09:45 CEST] <CFS-MP3> No such file. Files there: fdk-aac.pc  opus.pc  vpx.pc  x264.pc  x265.pc
[21:09:50 CEST] <JEEB> :|
[21:10:01 CEST] <JEEB> or did you install LAME?
[21:10:07 CEST] <JEEB> via the packaging system?
[21:10:12 CEST] <CFS-MP3> No, built from source
[21:10:23 CEST] <DHE> maybe you did --enable-static --disable-shared or such?
[21:10:28 CEST] <JEEB> the tutorial does that :P
[21:10:31 CEST] <JEEB> static everything
[21:10:32 CEST] <CFS-MP3> cd ~/ffmpeg_sources
[21:10:32 CEST] <CFS-MP3> wget http://downloads.sourceforge.net/project/lame/lame/3.99/lame-3.99.5.tar.gz
[21:10:32 CEST] <CFS-MP3> tar xzvf lame-3.99.5.tar.gz
[21:10:32 CEST] <CFS-MP3> cd lame-3.99.5
[21:10:32 CEST] <CFS-MP3> ./configure --prefix="$HOME/ffmpeg_build" --enable-nasm --disable-shared
[21:10:32 CEST] <CFS-MP3> make
[21:10:33 CEST] <CFS-MP3> make install
[21:10:37 CEST] <CFS-MP3> That's exactly what I did
[21:10:37 CEST] <DHE> oh dear
[21:10:43 CEST] <JEEB> > LAME has no pc file
[21:10:48 CEST] <JEEB> ok, excuse me while I weep a bit
[21:10:50 CEST] <relaxed> CFS-MP3: with ffmpeg's configure add --extra-libs="-lm"
[21:10:50 CEST] <DHE> well there's one major problem
[21:11:34 CEST] <JEEB> CFS-MP3: ok, let me explain why this happened
[21:11:46 CEST] <JEEB> before FFmpeg's configure would splat random linker flags
[21:11:49 CEST] <JEEB> on all checks
[21:11:52 CEST] <JEEB> which included -lm
[21:11:57 CEST] <JEEB> so it happened to work until now
[21:12:02 CEST] <JEEB> now it was cleaned up
[21:12:19 CEST] <JEEB> also holy crap why the flying fuckload does LAME have no pc file :|
[21:12:25 CEST] <JEEB> because pkg-config is how you generally handle this
[21:12:38 CEST] <relaxed> when was the last lame release?
[21:12:40 CEST] <JEEB> the library you're linking against has a pc file that contains the info what is needed to link
[21:12:42 CEST] <BtbN> because it's ancient
[21:12:50 CEST] <JEEB> well 3.99 most certainly isn't ancient
[21:12:54 CEST] <JEEB> much less ancient than pkg-config
[21:13:06 CEST] <JEEB> lame-3.99.5.tar.gz, 2012-02-28
[21:13:13 CEST] <CFS-MP3> If I add that -lm the error goes to x265:
[21:13:14 CEST] <CFS-MP3> $ PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \
[21:13:15 CEST] <CFS-MP3> >   --prefix="$HOME/ffmpeg_build" \
[21:13:15 CEST] <CFS-MP3> >   --pkg-config-flags="--static" \
[21:13:15 CEST] <CFS-MP3> >   --extra-cflags="-I$HOME/ffmpeg_build/include" \
[21:13:15 CEST] <CFS-MP3> >   --extra-ldflags="-L$HOME/ffmpeg_build/lib" \
[21:13:15 CEST] <CFS-MP3> >   --extra-libs="-lm" \
[21:13:15 CEST] <CFS-MP3> >   --bindir="$HOME/bin" \
[21:13:16 CEST] <CFS-MP3> >   --enable-gpl \
[21:13:16 CEST] <CFS-MP3> >   --enable-libass \
[21:13:17 CEST] <CFS-MP3> >   --enable-libfdk-aac \
[21:13:17 CEST] <CFS-MP3> >   --enable-libfreetype \
[21:13:18 CEST] <CFS-MP3> >   --enable-libmp3lame \
[21:13:18 CEST] <CFS-MP3> >   --enable-libopus \
[21:13:19 CEST] <CFS-MP3> >   --enable-libtheora \
[21:13:19 CEST] <CFS-MP3> >   --enable-libvorbis \
[21:13:21 CEST] <JEEB> stop spamming please
[21:13:40 CEST] <CFS-MP3> Sorry... pastebin for everything?
[21:13:47 CEST] <JEEB> everything more than one or two lines :P
[21:13:49 CEST] <CFS-MP3> OK
[21:13:58 CEST] <JEEB> and yes, you will get issues with x265 because C++ (and they for some godawful reason strip the lstdc++ off the pc file
[21:14:21 CEST] <JEEB> relaxed: also why extra-libs and not extra-ldflags?
[21:14:27 CEST] <BtbN> because it's not called -lstdc++ everywhere and there is no proper way to find the right name everyehere
[21:14:46 CEST] <JEEB> yes, I know. but cmake has some awful stuff to try and find out the stdlib :P
[21:14:56 CEST] <JEEB> which is what they seem to have started removing
[21:15:06 CEST] <JEEB> I think jamrial made a bug report to x265 about that
[21:15:29 CEST] <BtbN> and they replied. It's intentional because they have no way to find the right thing to put there
[21:15:33 CEST] <JEEB> ok
[21:15:43 CEST] <JEEB> CFS-MP3: anyways the LAME issue would be "fixed" in master soon since we just add -lm everywhere
[21:16:05 CEST] <JEEB> the x265 issue is --extra-ldflags="-lstdc++" -fixable :P
[21:16:26 CEST] <JEEB> such a fucking mess when things get cleaned up and the shit underneath gets shown \o/
[21:17:05 CEST] <JEEB> (also -lm was additionally added because a lot of libraries' pc files would lack it, and/or possibly the threading library if one was needed)
[21:18:43 CEST] <JEEB> partially to blame is of course the format for static libraries we have :P
[21:21:05 CEST] <CFS-MP3> so do I add that --extra-ldflags="-lstdc++" to the configure part in x265?
[21:21:12 CEST] <CFS-MP3> or in ffmpeg's configure?
[21:21:19 CEST] <JEEB> FFmpeg's
[21:22:05 CEST] <JEEB> and this is an old issue, which you might have not noticed if you enabled something else that happened to have lstdc++ added in its configure check before. for example I've had that issue for a while because x265 was the only thing I linked against which was C++-based
[21:30:29 CEST] <CFS-MP3> Um, same issue
[21:30:29 CEST] <CFS-MP3> ERROR: x265 not found using pkg-config
[21:31:02 CEST] <JEEB> post config.log into pastebin
[21:32:49 CEST] <CFS-MP3> https://pastebin.com/14yRBNRw
[21:33:32 CEST] <JEEB> ah
[21:33:33 CEST] <JEEB> pthreads
[21:33:35 CEST] <JEEB> the other derp
[21:33:58 CEST] <JEEB> in addition to lstdc++ also add -lpthread
[21:34:01 CEST] <JEEB> separate by space
[21:34:24 CEST] <JEEB> now this one is something that is 100% on x265's side :P
[21:34:31 CEST] <JEEB> even more than the C++ stdlib case
[21:35:09 CEST] <JEEB> (because the C++ stdlib case can be actually hard while this is just another library linked against)
[21:39:59 CEST] <CFS-MP3> OK , so like this (in ffmpeg's configure): --extra-ldflags="-lstdc++ -lpthread"
[21:40:11 CEST] <JEEB> yup
[21:40:26 CEST] <CFS-MP3> same issue :-( ERROR: x265 not found using pkg-config
[21:40:33 CEST] <JEEB> once again, time for config.log :P
[21:40:45 CEST] Action: JEEB wonders wtf it is this time
[21:42:27 CEST] <CFS-MP3> seems the same thing: https://pastebin.com/BUcn1qbh
[21:43:31 CEST] <JEEB> ah
[21:43:35 CEST] <JEEB> ok, so extra-libs goes at the end
[21:43:49 CEST] <JEEB> move those two to extra-libs instead of extra-ldflags :P
[21:44:17 CEST] <JEEB> it's an order thing. it worked for stdc++ because that's global but the rest needs the actual stuff you are building before it
[21:45:36 CEST] <CFS-MP3> OK, that worked. Next error is a separation from the tutorial. I could live without this but would be useful to have:
[21:45:38 CEST] <CFS-MP3> --enable-libzvbi
[21:45:38 CEST] <CFS-MP3> ERROR: zvbi-0.2 not found using pkg-config
[21:45:59 CEST] <JEEB> that one is so old so you don't have to build it
[21:46:02 CEST] <JEEB> install libzvbi-dev
[21:46:06 CEST] <CFS-MP3> wait actually I think since it's a fresh ubuntu I might just not have the package (libzvbi is the exception)
[21:46:08 CEST] <JEEB> (or something like that)
[21:46:20 CEST] <JEEB> yes, just install the zvbi dev package
[21:46:51 CEST] <JEEB> it's a shared library so it will not have these issues :P
[21:47:11 CEST] <CFS-MP3> fuck yeah
[21:47:13 CEST] <CFS-MP3> finally
[21:47:17 CEST] <CFS-MP3> configure is happy
[21:47:24 CEST] <CFS-MP3> let's see if make is too
[22:01:52 CEST] <CFS-MP3> This is the end of make:
[22:01:53 CEST] <CFS-MP3> https://pastebin.com/88hUBHMC
[22:02:41 CEST] <CFS-MP3> I do have a ffmpeg binary at least
[22:02:42 CEST] <CFS-MP3> ./ffmpeg
[22:02:43 CEST] <CFS-MP3> ffmpeg version N-87875-gf685bbc Copyright (c) 2000-2017 the FFmpeg developers
[22:02:43 CEST] <CFS-MP3>   built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.5) 20160609
[22:28:51 CEST] <CFS-MP3> thanks for your help, JEEB
[23:04:21 CEST] <squarecircle> sorry
[23:04:29 CEST] <squarecircle> stuff exploded in RL
[23:07:25 CEST] <squarecircle> JEEB: ping
[23:10:53 CEST] <squarecircle> JEEB: http://paste.ubuntu.com/25761768/
[23:11:24 CEST] <squarecircle> JEEB: all the context will be lost, but that are actually the parts working with the data
[23:12:53 CEST] <squarecircle> same question as earlier today: I'm creating a video from pure green, red pictures
[23:13:18 CEST] <squarecircle> and I get RGB(0,255,0) -> RGB(0,255,1)
[23:13:35 CEST] <squarecircle> or RGB(255,0,0) -> RGB(254,0,0)
[23:13:43 CEST] <squarecircle> which is irritating
[23:29:11 CEST] <Xogium> so trying to set it up via srtp now.. I need a base64 encoded string.. But how do I even generate one ?
[23:40:13 CEST] <alexpigment> squarecircle: I know you've been working with JEEB on this, but out of curiosity, how are you getting the RGB values from the video?
[00:00:00 CEST] --- Wed Oct 18 2017