[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/ff... [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