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

[burek]

[00:45:25 CEST] <TheXzoron> still trying to make a general record script but I'm running into issues with audio still https://dpaste.de/5fTk
[00:45:39 CEST] <TheXzoron> example http://thex.oniichan.me:1600/i/vlcsnap-2016-10-27-17h43m19s666.mp4
[00:48:42 CEST] <TheXzoron> please excuse profanity in that I forgot to cleanse it
[00:50:01 CEST] <klaxa> ah, the dreaded alsa xrun
[00:50:13 CEST] <klaxa> i have yet to see someone "solve" that
[00:51:07 CEST] <klaxa> if you ran pulse you would not run into this problem
[00:51:13 CEST] <TheXzoron> recording in obs works
[00:51:21 CEST] <klaxa> but using pulse is quite the "hefty workaround"
[00:51:54 CEST] <TheXzoron> so I'm sure there is a way in ffmpeg
[00:54:17 CEST] <klaxa> are you sure obs is also using alsa?
[00:54:41 CEST] <TheXzoron> I have the yes
[00:54:46 CEST] <TheXzoron> *yes
[00:57:41 CEST] <TheXzoron> https://a.desu.sh/zehdjm.mp4
[00:58:33 CEST] <TheXzoron> klaxa:
[00:59:13 CEST] <klaxa> ok
[00:59:16 CEST] <klaxa> hmm...
[01:00:44 CEST] <klaxa> what made you use -thread_queue_size 67?
[01:01:24 CEST] <TheXzoron> it kept asking me to increase it and I was grasping at straws even thouhg it did not make sense
[01:01:56 CEST] <iive> do you have pulse audio on your system?
[01:02:42 CEST] <iive> usually pulse solves problem, that pulse have caused itself... e.g. it intercepts alsa
[01:03:08 CEST] <TheXzoron> I do have it on my system but I have chosen to get rid of it due to instability
[01:03:11 CEST] <TheXzoron> it crashes often
[01:03:21 CEST] <TheXzoron> right now it it marked unexecutable
[01:03:28 CEST] <TheXzoron> so that it does not start up out of nowhere
[01:03:41 CEST] <iive> ok
[01:04:46 CEST] <klaxa> in the video it sounds like ffmpeg is reading from alsa too fast
[01:05:04 CEST] <klaxa> must -ar be used with -f alsa?
[01:05:18 CEST] <klaxa> would adding -re change anything?
[01:05:34 CEST] <iive> he have ar, but it is in the codec section.
[01:05:43 CEST] <iive> position does matter
[01:05:59 CEST] <klaxa> no, it's in the input section for the audio input
[01:06:13 CEST] <klaxa> [...] -f alsa -ac 2 -ar 48000 -thread_queue_size 67 -i looprec [...]
[01:06:15 CEST] <iive> klaxa: i do agree with you
[01:06:34 CEST] <klaxa> oh, yes, codec == coder/decoder
[01:06:41 CEST] <klaxa> nevermind me :)
[01:08:44 CEST] <debianuser> TheXzoron: does simple recording from just alsa works fine? Try `arecord -v -Vstereo -fdat -Dlooprec somefile.wav`  and copy whatever it prints to some pastebin. Also check if the audio file it recorded is fine.
[01:09:50 CEST] <debianuser> ("-fdat" is a shorcut for "-fS16_LE -r48000 -c2")
[01:12:28 CEST] <TheXzoron> https://a.desu.sh/krjnhi.wav
[01:12:38 CEST] <TheXzoron> it seems to record just fine with alsa
[01:14:04 CEST] <TheXzoron> http://thex.oniichan.me:1600/i/vlcsnap-2016-10-27-18h08m18s666.mp4 I cleaned up the ffmpeg command line to just ffmpeg -f x11grab -s "$W"x"$H" -i :0.0+$X,$Y -f alsa -i looprec /tmp/$TIMESTAMP
[01:14:11 CEST] <TheXzoron> and it still does that
[01:16:09 CEST] <iive> TheXzoron: try without capturing the screen (x11grab)
[01:18:13 CEST] <TheXzoron> https://a.desu.sh/ongmnz.mp4
[01:18:19 CEST] <debianuser> good idea. try just alsa, but with ffmpeg: `ffmpeg -f alsa -i looprec anotherfile.wav`
[01:18:31 CEST] <TheXzoron> I get an xrun in the begining
[01:18:35 CEST] <TheXzoron> but then it's smooth
[01:18:47 CEST] <TheXzoron> ffmpeg -f alsa -i looprec /tmp/test.mp4
[01:21:07 CEST] <debianuser> Maybe just not enough cpu for encoding, so ffmpeg doesn't process incoming data fast enough, thus it doesn't read alsa fast enough, and that causes buffer overrun?
[01:22:39 CEST] <iive> possible,
[01:22:52 CEST] <iive> i don't see encoder, so it might be hdd io blocking
[01:23:12 CEST] <iive> try with /dev/null output. -f null is a thing too, i think
[01:23:51 CEST] <TheXzoron> I have a 4790k
[01:24:02 CEST] <TheXzoron> I'm pretty sure the cpu is ample enough
[01:24:07 CEST] <iive> also, somebody had hight cpu usage when captuing its intel video card.
[01:24:22 CEST] <iive> he had to set some acceleration mode in xorg.conf.d/
[01:24:55 CEST] <TheXzoron> I'm recording to /tmp
[01:25:00 CEST] <TheXzoron> which I have tmpfs mounted to
[01:25:21 CEST] <TheXzoron> I also use a gtx 970
[01:28:42 CEST] Action: debianuser doesn't know what's the fastest ffmpeg encoding... Try something like: `ffmpeg -f x11grab -r 15 -s 320x240 -i :0 -f alsa -ac 2 -ar 48000 -i looprec -vcodec libx264 -preset ultrafast -tune zerolatency -acodec libvorbis somefile.mkv` Encoding 320x240 should be fast :)
[01:30:30 CEST] <iive> TheXzoron: uncompressed hdtv video could eat your space pritty quickly.
[01:31:16 CEST] <TheXzoron> I have mounted put 12GB of space in tmpfs
[01:31:41 CEST] <TheXzoron> interestingly debianuser's ffmpeg options do not cause a single xrun
[01:31:58 CEST] <TheXzoron> while recording audio only got 1 xrun in the begining
[01:32:16 CEST] <iive> well, at 155mb/s it would take you 77 seconds to fill it all up
[01:32:53 CEST] <TheXzoron> well I'm not recording at that quality :p
[01:33:05 CEST] <iive> don't you?
[01:33:47 CEST] <TheXzoron> don't I what?
[01:33:54 CEST] <debianuser> :)
[01:34:13 CEST] <iive> record at that quality...
[01:34:27 CEST] <iive> you don't have -vcodec or -c:v
[01:34:39 CEST] <TheXzoron> so far all my recirding have been arround 10-60mb with 60mb going on for a good  5 to 10 minutes
[01:34:51 CEST] <TheXzoron> *recordings
[01:35:00 CEST] <iive> ok
[01:35:09 CEST] <iive> let's say you got mpeg4 asp
[01:36:57 CEST] <debianuser> TheXzoron: that command captures 15fps of 320x240, it should be rather fast, but not too useful. Try to increase those values, first try to increase image size e.g. -s 800x600: `ffmpeg -f x11grab -r 15 -s 800x600 -i :0 -f alsa -ac 2 -ar 48000 -i looprec -vcodec libx264 -preset ultrafast -tune zerolatency -acodec libvorbis somefile.mkv` If that would still work - try higher fps (`-r 25` or `-r 30`).
[01:37:22 CEST] <furq> i don't think tune zerolatency increases throughput
[01:39:40 CEST] <TheXzoron> iive: actually all my recordings that I have not deleted since I decided to try to make this script total to 64mb...
[01:40:02 CEST] <iive> strange
[01:40:29 CEST] Action: debianuser doesn't know if zerolatency makes it faster either...
[01:40:45 CEST] <iive> furq: it disables a lot of complicated stuff
[01:41:27 CEST] <furq> i just tested and it's noticeably slower
[01:41:57 CEST] <furq> it disables frame multithreading which is a very bad idea for throughput
[01:42:13 CEST] <furq> it also disables cabac, but preset ultrafast already does that
[01:44:24 CEST] <iive> hum... disabling mt actually increases latency
[01:44:41 CEST] <furq> well it switches to slice multithreading, which is slower
[01:44:54 CEST] <furq> but it means you're not buffering $threads input frames
[01:45:26 CEST] <furq> but yeah in general don't use zerolatency unless you actually need zero latency
[01:45:56 CEST] <TheXzoron> so
[01:46:10 CEST] <TheXzoron> what's causing the xruns exactly
[01:47:15 CEST] <iive> at playback they are caused when the sound cards play all the data but cpu doesn't supply new one
[01:47:45 CEST] <iive> at recording i guess it might be when cpu doesn't take all the data in time.
[01:48:07 CEST] <iive> but then bigger buffers should help.
[01:49:24 CEST] <TheXzoron> so if I want to record a quick mp4 on the fly I should increase the buffer
[01:49:33 CEST] <TheXzoron> what settings tune this
[02:01:01 CEST] <TheXzoron> https://a.desu.sh/rrdjyo.mp4
[02:01:03 CEST] <TheXzoron> this works
[02:01:15 CEST] <TheXzoron> so I guess I needed to specify more stuff
[02:01:43 CEST] <TheXzoron> although the xrun in the begining is odd
[02:07:38 CEST] <TheXzoron> now I need to look into why browser are being poopy and not playing the file
[02:07:54 CEST] <TheXzoron> and decide on what codec will work for everyone's special and cool browser
[02:09:32 CEST] <tontonth> TheXzoron: nice windows dance :)
[02:10:56 CEST] <TheXzoron> thank you I apreciate that someone can see nice things in my workflow
[02:14:47 CEST] <TheXzoron> ok so acc works in both firefox and chrome
[02:14:53 CEST] <TheXzoron> so that is what I will use then
[02:16:41 CEST] <TheXzoron> thank you guys
[02:28:58 CEST] <TAFB2> I love ffmpeg :)
[02:31:52 CEST] <TheXzoron> same
[02:41:45 CEST] <TAFB2> and I love HLS streaming!!! With my up and down internet, I could never stream properly without HLS! Now it's flawless
[02:56:36 CEST] <klaxa> well you actually have to thank apple for that
[04:37:26 CEST] <hamsheet> hi i downloaded bunch of youtube videos but they are hd and huge files like couple gigs each. Any recommendations for keeping the resolution same but opotimizing the file size a bit? I d onot care about the sound quality much
[04:38:47 CEST] <hamsheet> 94 files, 98 gbs
[04:43:08 CEST] <klaxa> youtube already does pretty good encoding
[04:43:52 CEST] <klaxa> you can decrease sound quality though, but i'm not sure how much that will help
[04:44:27 CEST] <klaxa> to do so do: ffmpeg -i input.mkv -c copy -c:a aac -b:a 96k output.mkv
[04:44:46 CEST] <furq> download them in webm
[04:45:00 CEST] <klaxa> that might be better
[04:45:16 CEST] <hamsheet> furq: some videos are not avail in webm?
[04:51:09 CEST] <furq> the audio will probably be 128k aac if these are mp4, so reencoding the audio is barely going to make a dent
[04:51:34 CEST] <furq> if these are 1080p then i would probably just use 720p instead
[04:51:40 CEST] <furq> youtube's 1080p looks pretty crap anyway
[04:52:03 CEST] <dl2s4> youl could reencode the video as well, i cant imagine that reencode audio will save good space
[04:52:36 CEST] <furq> you could but it probably won't achieve much
[04:52:42 CEST] <hamsheet> dl2s4: i can reencode sure, any recommendation for the cli?
[04:52:54 CEST] <dl2s4> like idk -c:v x264 -crf 30 or something
[04:53:04 CEST] <furq> youtube videos are already heavily optimised for low bitrate
[04:53:13 CEST] <dl2s4> ok
[04:53:27 CEST] <hamsheet> furq: so i should redownloaded in webm?
[04:53:34 CEST] <furq> i would probably redownload in 720p
[04:53:38 CEST] <furq> webm if you can get it
[04:53:45 CEST] <hamsheet> i use oyutube dl, I acn do that it is just that i will have to download gigs of data again
[04:53:48 CEST] <dl2s4> yeah i never tried it for youtube videos, but furq could be right
[04:54:10 CEST] <furq> 720p webm is normally about half the size of 1080p mp4
[04:54:14 CEST] <furq> and it looks roughly the same
[04:54:48 CEST] <hamsheet> furq: thanks I will try that
[04:55:17 CEST] <hamsheet> the reason I want to optimize is that I serv the videos over my upnp server via the wireless
[04:55:23 CEST] <hamsheet> and save space a bit
[04:55:58 CEST] <hamsheet> the server can transcode but  withtranscode  i loose some  playback features
[04:56:07 CEST] <hamsheet> it uses ffmpeg for the transcode backend
[04:58:11 CEST] <furq> http://vpaste.net/1S60u
[04:58:47 CEST] <hamsheet> furq: do you know if youtube creates the webms on demand?
[04:59:09 CEST] <furq> it's google so it's a bit of a mystery
[04:59:20 CEST] <furq> at least on my channel it seems to be videos uploaded after a certain date that have >150 views
[04:59:21 CEST] <hamsheet> for instance if the video does not have a webm format, does it create the webm once it is requested?
[04:59:24 CEST] <hamsheet> I see
[04:59:35 CEST] <dl2s4> i would try 136
[04:59:46 CEST] <hamsheet> I see makes sense, they measure the effort
[04:59:56 CEST] <furq> get 247 if you can, otherwise 136 is fine
[04:59:56 CEST] <hamsheet> dl2s4: thanks I will try
[05:00:12 CEST] <furq> iirc you can tell youtube-dl to try multiple formats
[05:01:22 CEST] <hamsheet> furq: I did not know that
[05:01:33 CEST] <dl2s4> why do you prefer 246? i dont know much about vp9
[05:01:42 CEST] <hamsheet> I just see that the webm version of a 4gb movie file is like 1.98gb, already better
[05:02:15 CEST] <furq> -f 247+251/136+140
[05:02:18 CEST] <furq> that should do it
[05:02:27 CEST] <furq> dl2s4: he wants to save as much space as possible
[05:02:35 CEST] <hamsheet> ahh that is nice
[05:02:48 CEST] <furq> youtube webm is normally smaller than the corresponding mp4
[05:02:56 CEST] <dl2s4> ah right that was the goal ;)
[05:02:56 CEST] <hamsheet> yeah that is for sure
[05:03:05 CEST] <dl2s4> this*
[05:03:33 CEST] <furq> but yeah youtube denoise everything so aggressively that there's not much difference between 720p and 1080p
[05:03:51 CEST] <furq> 720p normally looks better to me
[05:03:58 CEST] <furq> although granted i'm not watching on a big screen
[05:07:51 CEST] <hamsheet> furq: they know what they are doing i guess
[05:08:27 CEST] <hamsheet> it is a remarkable piece of achievment I mean serving and storing crazy amouunt of data in realtime, which serves to billions
[05:08:46 CEST] <hamsheet> a bit fucked up
[05:32:57 CEST] <bibble> got some massive .mkv files, 40min each. looking for ffmpeg command to reduce size whilst keeping as much quality as possible. don't mind doing 2pass
[05:35:03 CEST] <bibble> currently done "ffmpeg -i "$v" -c:v copy -c:a copy out/"$v".mp4", which reduced each file from 2G to 1.6G really quickly. but looking to get them under 700M each.
[05:37:10 CEST] <kepstin> hamsheet: note that youtube creates two different webms - they make a vp8 one on all videos (presumably for compat reasons), then a vp9 webm later/after some view threshold.
[05:42:18 CEST] <furq> bibble: you'll struggle to get them that small without quality loss
[05:42:37 CEST] <furq> you probably want to use -preset veryslow
[05:43:43 CEST] <kepstin> bibble: do you have an exact target size you need, or just "smaller than they are now"?
[05:43:45 CEST] <furq> the default crf is 23 which is already pretty high
[05:44:17 CEST] <furq> actually nvm i can't read
[05:44:43 CEST] <furq> just get rid of -c:v copy and see how big they turn out
[05:44:43 CEST] <TAFB2> crf 0 veryslow ftw :)
[05:45:07 CEST] <bibble> ah, ok furq kepstin , thanks. just smaller, as too large to stream currently.
[05:45:46 CEST] <kepstin> tbh, I'm surprised the file size that much at all with -c copy; did the original have multiple audio tracks maybe? (That command would only copy the first)
[05:46:02 CEST] <furq> either that or the source is mpegts
[05:46:51 CEST] <kepstin> bibble: do something like ffmpeg -i "$v" -c:v libx264 -preset veryslow -crf 23 -c:a copy out/"$v".mp4
[05:47:03 CEST] <bibble> yeah, good point, thought was strange too that 400M had been reduced
[05:47:12 CEST] <kepstin> bibble: use smaller crf if file looses too much quality, use bigger crf if file is too big.
[05:47:15 CEST] <bibble> ok, will do kepstin
[05:47:34 CEST] <kepstin> (range of around 18-28 or so is useful)
[05:47:41 CEST] <bibble> used "ffmpeg -i in.mkv -vcodec libx264 -crf 20 out.mp4", and got 1.1G file
[05:48:28 CEST] <furq> crf 23 is probably about right then
[05:48:33 CEST] <kepstin> bibble: the 'veryslow' (default is medium) improves compression efficiency a bit, other than that, just play with crf.
[05:48:41 CEST] <bibble> great :)
[05:48:50 CEST] <furq> the preset doesn't normally have much effect on filesize, it'll just retain more quality at a given crf
[05:51:32 CEST] <ossifrage> Is there a way to draw the frame size on the image with the drawtext vf? The docs mention pict_type, pts, n, etc...
[05:52:39 CEST] <furq> if you mean dimensions then w and h
[05:52:47 CEST] <Elronnd> do you lose any quality converting a lossy audio format to a lossless one?
[05:53:08 CEST] <ossifrage> I tried to use metadata:pkt_size but no love
[05:53:34 CEST] <Elronnd> I have a song only in mp3, and I want to convert it to flac for consistency
[06:08:06 CEST] <TD-Linux> Elronnd, no, you don't lose any quality (but you don't gain any either)
[06:13:07 CEST] <Elronnd> thanks
[06:17:48 CEST] <fa0> Hello all
[06:19:05 CEST] <Elronnd> hey
[06:19:40 CEST] <fa0> with libfaac removed from 3.2, is libfdk-aac the only aac support?
[06:20:42 CEST] <fa0> Actually, I'm compiling ffmpeg against everything it needs without them installed, so from what I can tell at the moment making this happen with libaacplus is not working
[06:21:30 CEST] <furq> fa0: there's a builtin aac encoder now
[06:22:12 CEST] <furq> it's not as capable as fdk but it's better than faac and vo-aacenc
[06:22:24 CEST] <fa0> actually I think it's building against libaacplus, from what I can tell --enable-libaacplus is for non free code
[06:22:57 CEST] <furq> i thought libaacplus was deprecated now
[06:23:16 CEST] <furq> either way you should use fdk if you don't mind having a non-free binary
[06:23:30 CEST] <furq> assuming you need he-aac support
[06:23:33 CEST] <fa0> Ahh yes 3.0; libaacplus and libvo-aacenc support removed
[06:23:46 CEST] <furq> faac was removed in 3.0 as well
[06:24:08 CEST] <furq> fdk is the best oss library anyway
[06:24:11 CEST] <fa0> actually faac in 3.2
[06:24:14 CEST] <furq> it's just slightly gpl incompatible
[06:25:09 CEST] <fa0> Ok wait, I'm starting to get aac confused wheeee LOL
[06:25:16 CEST] <fa0> So it's good to keep fdk-aac?
[06:25:21 CEST] <furq> yeah
[06:25:34 CEST] <furq> the builtin aac encoder is fine if you just want cbr lc-aac
[06:25:47 CEST] <furq> if you want he-aac then use fdk
[06:25:48 CEST] <fa0> ok, I'm hacking through a compile script someone else created that didn't keep this thing updated...
[06:25:54 CEST] <furq> that sounds about right
[06:26:00 CEST] <fa0> ok
[06:30:40 CEST] <fa0> is libass still used for something?
[06:33:50 CEST] <fa0> furq: if you might know, these are the extra libs/deps I was compiling before for 3.1x; http://dpaste.com/0YA91FK
[06:34:11 CEST] <fa0> Not sure there's anything else there not needed for 3.2, but looking over the Changlog I don't see anything I'd need to remove, no longer needed...
[06:34:43 CEST] <fa0> Or if anyone else knows if these libs are all still ok for 3.2?
[06:45:12 CEST] <furq> looks ok to me
[06:50:42 CEST] <fa0> ok
[06:51:03 CEST] <fa0> wasn't sure if anything good to add in too... hmm
[06:52:03 CEST] <fa0> Like I see there's openh264
[06:52:12 CEST] <furq> you probably want libvorbis and libvpx
[06:52:54 CEST] <furq> openh264 is only really useful if you're encoding h264 commercially
[06:53:39 CEST] <fa0> These are my comppile flags for it; http://dpaste.com/1SARVWR
[06:55:29 CEST] <fa0> I just do small time stuff with ffmpeg, personally, most of the time, for videos, I just re-encode them for low volume is pretty much all I mess with it at the moment
[06:56:00 CEST] <fa0> Like this;
[06:56:02 CEST] <fa0> urxvt -g 150x40 -e ffmpeg -i "$i" -vcodec copy -acodec aac -ar 48000 -ab 133k -af volume=15dB "$OUTPUT/${i%.*}.mp4"
[06:56:19 CEST] <fa0> 99.9% off all I do LOL
[06:56:24 CEST] <fa0> off/of...
[06:56:35 CEST] <furq> you can often use replaygain for that
[06:56:38 CEST] <furq> depends what player you're using
[06:56:42 CEST] <furq> mpv definitely supports it
[06:57:01 CEST] <fa0> This is when watching on the HDTV
[06:57:14 CEST] <furq> ah
[06:57:28 CEST] <fa0> never thought about replaygain
[06:57:41 CEST] <fa0> but this works easy enough
[06:58:10 CEST] <fa0> do you think those compile flags I had for 3.1x I just showed are still good for 3.2?
[06:58:23 CEST] <furq> http://vpaste.net/jDUue
[06:58:26 CEST] <furq> that's all i build with
[06:58:53 CEST] <fa0> hmm
[06:59:06 CEST] <furq> maybe lame as well
[06:59:27 CEST] <fa0> Well to be honest, not sure what you know of Slackware, this is taken from alienbob's slack build script I've been hacking on;
[06:59:29 CEST] <fa0> http://www.slackware.com/~alien/slackbuilds/ffmpeg/build/
[06:59:50 CEST] <fa0> So he's the one that made it with all those build options, and I'm no real pro to know the reasons why hehe
[07:00:24 CEST] <fa0> But on the URL I just showed, it's somewhat dated, so I re did it for the 3.1x
[07:00:48 CEST] <fa0> I guess for now until someone says otherwise I'll keep it as is...
[07:00:49 CEST] <furq> i use my own build script on desktop and freebsd ports on my nas, so it's easy enough to pick what i want
[07:00:58 CEST] <furq> there's no harm in having everything other than build time
[07:01:31 CEST] <furq> libzimg is probably the only thing i actually use that you don't have
[07:01:43 CEST] <furq> https://github.com/sekrit-twc/zimg/
[07:01:58 CEST] <fa0> If you looked at that .SlackBuild script he made, I like how it just compiles against everything at run time and no need to have it all installed
[07:02:45 CEST] <furq> fwiw libmp3lame isn't non-free
[07:02:46 CEST] <furq> it's gpl
[07:03:01 CEST] <fa0> Can't say I know much about zimg, if I'm doing some basic encode jobs is this being taken advantage of, used?
[07:03:18 CEST] <furq> you can use it instead of swscale
[07:03:39 CEST] <furq> if you're not resizing stuff or doing colourspace conversions then it's not used
[07:03:46 CEST] <fa0> ok
[07:04:26 CEST] <fa0> hmm not sure why he has lame as nonfree then...
[07:05:43 CEST] <fa0> libfdk-aac is non-free?
[07:05:55 CEST] <furq> yeah
[07:06:26 CEST] <furq> https://github.com/mstorsjo/fdk-aac/blob/master/NOTICE#L51-L58
[07:06:30 CEST] <furq> that clause is gpl incompatible iirc
[07:06:36 CEST] <fa0> actually lame is LGPL
[07:06:41 CEST] <furq> close enough
[07:06:44 CEST] <fa0> hehe
[07:06:59 CEST] <fa0> sheesh to be honest I haven't been paying attention to this stuff in years
[07:07:13 CEST] <furq> you've not been missing much
[07:07:33 CEST] <fa0> So to be technically correct, I'd remove lame from that non-free section and just add it to the ffmpeg compile flags section?
[07:07:38 CEST] <furq> yeah
[07:07:42 CEST] <fa0> ok thanks
[07:08:22 CEST] <furq> the only gpl incompatible libs are cuda, cuvid, libnpp, fdk and openssl
[07:09:35 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L5069-L5090
[07:10:59 CEST] <fa0> ok
[07:30:09 CEST] <fa0> thanks for the help furq
[07:38:38 CEST] <fa0> WoOt got the compile script reconfigured and it compiled and here's the options;
[07:38:40 CEST] <fa0> http://dpaste.com/3JE46R1
[07:38:49 CEST] <fa0> looking good, thanks again, I'm happy :)
[07:40:22 CEST] <fa0> later... :)
[09:26:57 CEST] <k_sze[work]> What's the surest way to probe the version of the ffmpeg command?
[09:27:16 CEST] <k_sze[work]> I mean programmatically, something I can extract and do a simple comparison of in a bash script.
[09:28:26 CEST] <k_sze[work]> Is the output of `ffmpeg -version` supposed to be machine parsable?
[09:45:06 CEST] <relaxed> k_sze[work]: ffmpeg -version | awk '/^ffmpeg/ {print $3}'
[09:45:14 CEST] <relaxed> would that work?
[09:45:53 CEST] <k_sze[work]> let me try
[09:46:36 CEST] <k_sze[work]> hmm, maybe
[09:46:51 CEST] <k_sze[work]> let me try another ffmpeg verison
[09:47:19 CEST] <k_sze[work]> oh, btw
[09:47:24 CEST] <k_sze[work]> since when was the 'n' dropped?
[09:47:47 CEST] <k_sze[work]> e.g. back then I see "n2.5.3", now I only see "3.1.5"
[09:49:17 CEST] <relaxed> ffmpeg -version | awk '/^ffmpeg/ {sub(/n/,"");print $3}'
[09:50:19 CEST] <relaxed> ^^ should remove the "n" from the version
[09:50:46 CEST] <sopparus> anyone know if rtmpdump is involded in parsing m3u8? in this case for kodi
[09:52:36 CEST] <relaxed> k_sze[work]: er, change "sub" to "gsub"
[11:01:14 CEST] <sopparus> anyone knows hat ffmpeg[45A153A0]: [tls] error:00000000:lib(0):func(0):reason(0) means?
[11:01:54 CEST] <flux> no, but it would seem like an instance of the famous "Error: Success"..
[11:03:50 CEST] <sopparus> :)
[11:08:08 CEST] <jkqxz> sopparus:  That message is coming from openssl, which is notoriously helpful.
[11:08:21 CEST] <jkqxz> Is something actually going wrong?
[11:08:33 CEST] <sopparus> yes, I cant play the file
[11:08:38 CEST] <sopparus> its from within kodi actually
[11:09:29 CEST] <sopparus> https://valizadeh.se/sassatv/index.m3u8 is the file, works with vlc
[11:09:39 CEST] <sopparus> ffmpeg is compiled --enable-openssl
[11:09:46 CEST] <sopparus> openssl being libressl in this case
[11:24:11 CEST] <jkqxz> It works for me on 3.1 but not on current git.
[11:26:22 CEST] <jkqxz> I'm not sufficiently familiar with it to say anything useful about why, though.  Maybe make a bug report?  Or wait for someone who actually knows how that works here...
[11:34:29 CEST] <sopparus> kodi uses 3.1.5
[11:35:32 CEST] <sopparus> did you test with ffplay?
[11:37:47 CEST] <jkqxz> Just ffmpeg, using the 3.1 build in debian testing.
[11:38:10 CEST] <jkqxz> Ah, which is built against gnutls rather than openssl.
[11:38:46 CEST] <sopparus> I see
[11:38:53 CEST] <sopparus> sounds like that could be the thing
[11:39:38 CEST] <jkqxz> Yeah, that's a much more interesting difference.
[11:42:52 CEST] <sopparus> on freebsd the package is compiled with gnutls and it work
[11:43:00 CEST] <sopparus> how does it look for you when it doesnt work?
[11:43:43 CEST] <BtbN> are you sure ffmpeg is compatible with libressl?
[11:43:49 CEST] <jkqxz> Exactly the same error as you have above.
[11:44:30 CEST] <sopparus> BtbN, yes https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/package.mk#L149
[11:44:31 CEST] <sopparus> ok
[11:44:52 CEST] <sopparus> oh sorry
[11:44:54 CEST] <jkqxz> And I am using openssl, not libressl.
[11:44:55 CEST] <sopparus> misread question
[11:45:00 CEST] <sopparus> hm
[11:45:22 CEST] <sopparus> that im not sure of, but there is very little difference. most programs that supports openssl works right away with libressl
[11:45:33 CEST] <BtbN> There's a patch on the ML, claiming to make ffmpeg master compatible with libressl
[11:45:40 CEST] <BtbN> So I'd guess it currently is not compatible with it.
[11:45:43 CEST] <sopparus> hm
[11:45:46 CEST] <sopparus> do you have the link?
[11:46:05 CEST] <BtbN> https://patchwork.ffmpeg.org/patch/1212/
[11:46:11 CEST] <furq> fwiw you can build the ffmpeg port on freebsd with openssl
[11:46:21 CEST] <furq> it's still 2.8 though so it's probably not much use for bug hunting
[11:46:51 CEST] <sopparus> thanks
[11:46:59 CEST] <sopparus> ill see if I can build libreelec with that patch
[11:47:55 CEST] <sopparus> jkqxz, but you have original openssl where it also didnt work right?
[11:48:51 CEST] <jkqxz> Yes, (1.0.2).
[11:49:54 CEST] <sopparus> ok
[11:57:23 CEST] <sopparus> ill try gnutls vs openssl on ubuntu then
[12:42:52 CEST] <sopparus> compiled with openssl on ubuntu, same error
[12:42:57 CEST] <sopparus> gnutls up next..
[13:16:13 CEST] <sopparus> this computer sure sucks for compiling...
[13:20:01 CEST] <iive> ccache might help
[13:20:23 CEST] <sopparus> I rarely compile, no big issue
[13:20:35 CEST] <sopparus> think im close to done now... :)
[13:22:35 CEST] <furq> you could just use the static linux builds if you want to test with gnutls
[13:23:12 CEST] <sopparus> but now its the same git version
[13:23:16 CEST] <sopparus> same os everything
[13:23:26 CEST] <sopparus> only change is gnutls/openss
[13:23:28 CEST] <sopparus> l
[13:23:39 CEST] <furq> are you running make -j
[13:23:46 CEST] <sopparus> no
[13:23:51 CEST] <sopparus> ok done
[13:24:42 CEST] <sopparus> yep works
[13:24:55 CEST] <sopparus> I guess its confirmed then that something goes wrong when using openssl
[13:29:59 CEST] <sopparus> note that other programs such as curl and wget linked with openssl works
[13:30:09 CEST] <sopparus> on the same site, its nothing special with it
[13:32:20 CEST] <sopparus> so should I do a bug report then?
[13:43:50 CEST] <sopparus> if only the register on trac wasent broken... :)
[13:45:06 CEST] <sopparus> ok it was just really slow
[13:53:09 CEST] <sopparus> made one, https://trac.ffmpeg.org/ticket/5915#ticket
[13:53:11 CEST] <sopparus> see what happens
[15:12:39 CEST] <sopparus> jkqxz, do you think you could post complete output when using openssl linked binary?
[15:12:51 CEST] <sopparus> i needed that for the ticket, but I prefer not to compile again.. :)
[15:46:09 CEST] <jkqxz> sopparus:  I'll add it to the ticket.
[15:46:24 CEST] <sopparus> thanks!
[15:51:58 CEST] <jkqxz> sopparus:  Done.
[15:52:06 CEST] <sopparus> thanks alot
[18:29:15 CEST] <t4nk465> Hello, I had a small question. Does ffmpeg lose data when it converts rgb to yuv444 colorspace? (Or is it perfectly lossless?).
[18:30:17 CEST] <t4nk465> I I used the following command with x264: ffmpeg -i $INPUT -c:v libx264 -qp 0 -pix_fmt yuv444p $OUTPUT
[18:31:03 CEST] <t4nk465> and wanted perfectly lossless, but there seems to be some difference, as the framehash of the individual frames does not match the x264 video frames
[19:14:46 CEST] <DHE> t4nk465: I don't think it's lossless. colourspace conversion rarely is. I don't think even 8->10 bit conversion and back is guaranteed to be clean
[19:22:32 CEST] <c_14> I have achieved a lossless (according to checksums) by converting from iirc rgb to yuv444p16le and back with ffmpeg
[19:22:39 CEST] <c_14> But I wouldn't bet on it
[19:25:32 CEST] <klaxa> it is theoretically possible, wait... yuv444p16le is 12 samples for 2x2 at 16 bit per sample?
[19:27:27 CEST] <c_14> wait, it was rgba to yuva444p16le
[19:27:38 CEST] <c_14> so 32bpp to 64bpp and back
[19:28:33 CEST] <klaxa> did you use the whole rgba spectrum?
[19:29:30 CEST] <c_14> I used testsrc (or smptehdbars) can't remember which
[19:33:20 CEST] <sopparus> jkqxz, http://pastebin.com/raw/Tags85Xp
[19:33:25 CEST] <sopparus> a libreelec developer made that
[19:33:37 CEST] <sopparus> and then it worked
[19:33:41 CEST] <sopparus> compiling myself to extra sure
[20:31:17 CEST] <jkqxz> sopparus:  Right, the server rejects anything before TLS 1.2: <https://www.ssllabs.com/ssltest/analyze.html?d=valizadeh.se>.
[20:31:42 CEST] <sopparus> yes, but I removed that as a test
[20:31:53 CEST] <sopparus> tried force 1.1, 1.0
[20:31:56 CEST] <sopparus> and no force
[20:32:22 CEST] <sopparus> http://vpeter.libreelec.tv/tmp/ffmpeg-tls-1.2.patch here is the patch that applies cleanly
[20:32:33 CEST] <sopparus> tested it myself now too, it works
[20:36:20 CEST] <jkqxz> Using TLSv1_client_method there goes back a long way.  <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=92db95e9ca5f8249e69e5ef7e1c31c835813e764>
[20:37:40 CEST] <sopparus> hehe
[20:37:58 CEST] <jkqxz> Not sure where the motivation for restricting that came from, but it's certainly worth discussing on the ML.  The SSLv23_client_method case should probably be given SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 to block it from using the older protocols.
[20:38:00 CEST] <sopparus> are you a dev? do you want to take care/review it or should i send to ML?
[20:46:38 CEST] <jkqxz> sopparus:  I can do it.
[20:46:55 CEST] <sopparus> ok, thanks again
[20:47:16 CEST] <sopparus> now I just sent it, but it doesnt seem it got through
[20:47:20 CEST] <sopparus> i never registered
[20:47:29 CEST] <jkqxz> If you haven't registered it ends up in a moderation queue.
[20:47:47 CEST] <sopparus> ok
[20:48:14 CEST] <sopparus> it can be removed then
[21:03:07 CEST] <sopparus> can I close the stream now or do you want it up for a while for some extra testing?
[21:04:56 CEST] <jkqxz> I've sent an email, but it hasn't appeared on the archive yet.  Other people might be interested in trying it, though I imagine they can make their own TLSv1.2-only servers if necessary.
[21:05:53 CEST] <sopparus> ill keep it up for a while then
[21:05:55 CEST] <sopparus> no problem
[21:09:29 CEST] <jkqxz> Here you go: <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201918.html>.
[21:10:05 CEST] <sopparus> thanks
[21:14:25 CEST] <sopparus> if this gets merged which I guess it will be how likely is it that it ends up in 3.1.6?
[21:14:32 CEST] <sopparus> i was thinking of kodi17 :)
[00:00:00 CEST] --- Sat Oct 29 2016