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

[burek]

[00:00:27 CEST] <evgeniy> How can I include an audio stream to a video recording with ffmpeg
[00:01:17 CEST] <evgeniy> Particularly pulseaudio desktop audio
[00:01:30 CEST] <thebombzen> alexpigment: it does
[00:01:39 CEST] <thebombzen> so instead of -crf 0 -maxrate
[00:01:54 CEST] <thebombzen> it'd probably be better to set the crf to something crazy low but not truly zero
[00:01:56 CEST] <thebombzen> like 15
[00:02:19 CEST] <evgeniy> higher crf = higher cpu usage, right?
[00:04:47 CEST] <alexpigment> evgeniy: in my experience, not noticeably so
[00:04:57 CEST] <alexpigment> but perhaps if you're on a slow single core, you'd notice
[00:05:05 CEST] <furq> there is a noticeable difference
[00:05:16 CEST] <furq> it's not that big though
[00:06:03 CEST] <alexpigment> furq: even on an i7 4c/8t?
[00:06:16 CEST] <alexpigment> just asking for my own personal curiosity at this point
[00:06:19 CEST] <furq> yeah
[00:06:39 CEST] <alexpigment> k
[00:06:41 CEST] <evgeniy> i'm on a i5 2540M
[00:06:58 CEST] <evgeniy> and for now only lossless satisfies my needs ;/
[00:07:08 CEST] <evgeniy> not needs but interest
[00:07:30 CEST] <alexpigment> visually lossless or actually losless?
[00:07:34 CEST] <alexpigment> *lossless
[00:08:00 CEST] <evgeniy> actually
[00:08:09 CEST] <evgeniy> it just doesn't use the cpu
[00:08:12 CEST] <evgeniy> almost at all
[00:15:00 CEST] <djk> evgeniy: are you suggesting I try the crf 0 and reduce cpu hit?
[00:15:18 CEST] <evgeniy> Dunno man
[00:15:22 CEST] <evgeniy> I'm not suggesting you anything
[00:15:23 CEST] <evgeniy> :D
[00:16:40 CEST] <djk> alright then I'll a different question is crf 0 less of hit to the cpu than crf 18 ro 15?
[00:17:30 CEST] <evgeniy> Well it would make sense for it to be
[00:17:40 CEST] <evgeniy> Since the input is lossless
[00:17:46 CEST] <evgeniy> compressing it more would mean more cpu
[00:17:52 CEST] <evgeniy> i'm really not competent though
[00:31:02 CEST] <evgeniy> ffmpeg -video_size 1364x768 -framerate 60 -f x11grab -i :0.0+0,1200 -c:v libx264 -qp 0 -preset ultrafast capture.mkv
[00:31:07 CEST] <evgeniy> this is how i record video
[00:31:17 CEST] <evgeniy> how would i add the sound i hear
[00:31:19 CEST] <evgeniy> to the video?
[00:31:42 CEST] <evgeniy> i'm looking at the manual
[00:31:48 CEST] <evgeniy> but it doesn't work..
[00:32:06 CEST] <furq> https://trac.ffmpeg.org/wiki/Capture/ALSA
[00:46:24 CEST] <CFS-MP3> why could this possible not being generating a .mp4 file exactly every 10 seconds?
[00:46:25 CEST] <CFS-MP3> ffmpeg -i udp://127.0.0.1:7316 -deinterlace -filter_complex "[0:v]split=2[in1][in2];[in1]fps=12,scale=416:-2:flags=lanczos[out1];[in2]fps=1/10,scale=416:-2:flags=lanczos[out2]" -map '[out1]' -codec:v libx264 -x264opts "keyint=120:min-keyint=120:no-scenecut"  -f segment -segment_time 10 -segment_list_type m3u8 -segment_list segments.m3u8  seg_%06d.mp4 -map '[out2]' img_%06d.jpg
[00:46:41 CEST] <CFS-MP3> there's a (I think) keyframe every 120 frames, framerate 10
[01:37:12 CEST] <nightlingo> any ideas on how to programmatically mux an audio and a video stream?
[01:41:13 CEST] <nightlingo> I have an idea about how to join the two mdat atoms, but, how should I join the two mdats?  should I simply just write one video chunk and then one audio chunk alternately into the new mdat atom?
[01:42:28 CEST] <JEEB> nightlingo: see how remuxer in L-SMASH does it?
[01:43:22 CEST] <nightlingo> JEEB: thanks Ill check it oout
[01:53:07 CEST] <nightlingo> JEEB: regarding our previous conversation earlier about non-keyframe cutting of a x264 stream. Do you think it would be possible to have two video trak atoms in the same file, each track having  different codec settings so as to avoid re-encoding the first part with the second parts codec settings? (And then somehow, have the second trak play after the second trak finishes)
[07:58:12 CEST] <iMath> a video file size in bytes is always an even number?
[11:26:20 CEST] <ozan> Hello guys i have an interesting problem. i've rotated couple of videos with ffmpeg but one. i Tried on ubuntu with ffmpeg version git-2017-01-22-f1214ad Copyright (c) 2000-2017 the FFmpeg developers...... i tried on centos ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers   built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-11)... also ffmpeg 2.6.8... there 2 problems depends on version. 1. problem is after rotation au
[11:26:56 CEST] <ozan> 2. problem is audio sync until 1minute in the video and suddenly different frames appearing
[11:57:05 CEST] <xxx_> does anyone noticed that master version vf_scale_npp filter have segfault bug?
[12:37:28 CEST] <durandal_1707> xxx_: where?
[13:55:05 CEST] <dv_> hm out of curiosity, are any ffmpeg devs also participating in the development of that new av1 codec
[13:55:06 CEST] <dv_> ?
[14:01:21 CEST] <atomnuker> I do, peloverde does as well
[14:01:50 CEST] <furq> TD-Linux does as well but idk if he's an ffmpeg dev
[14:03:29 CEST] <nightlingo> Hello
[14:05:39 CEST] <nightlingo> Im trying to programmatically mux an MP4 file containing an audio stream and an MP4 file containing a video stream. How should I join the two mdats atoms?  should I simply just write one video chunk and then one audio chunk alternately into the new mdat atom?
[14:10:56 CEST] <BtbN> extract the two streams, and mux a whole new mp4 file
[14:12:30 CEST] <nightlingo> BtbN: I need to do it programmatically
[14:12:42 CEST] <BtbN> yes, so?
[14:13:49 CEST] <nightlingo> BtbN: I mean,  without using ffmpeg
[14:14:38 CEST] <nightlingo> BtbN: write my own code to read the source streams, process them, and write them
[14:15:03 CEST] <nightlingo> BtbN: so Im trying to understand the method
[14:15:14 CEST] <BtbN> Well, that is the method
[14:15:18 CEST] <furq> i take it exec("ffmpeg") doesn't count
[14:15:26 CEST] <BtbN> you get the streams, and mux them into an mp4 file
[14:16:06 CEST] <nightlingo> BtbN: yeah, the question is: how is the mux performed in the resulting mdat atom
[14:16:13 CEST] <nightlingo> furq: unfortunately not :)
[14:16:15 CEST] <BtbN> in the resulting what?
[14:16:33 CEST] <BtbN> You just tell avformat to make you an mp4 file with those streams, and so it does.
[14:16:42 CEST] <BtbN> At no point do you need to touch mp4 internals
[14:17:02 CEST] <nightlingo> BtbN: is avformat able to write to stdout?
[14:17:20 CEST] <BtbN> that's not the job of avformat
[14:17:49 CEST] <furq> writing an mp4 to stdout probably isn't going to work
[14:17:53 CEST] <nightlingo> BtbN: what is the job of avformat in a nutshell?
[14:17:59 CEST] <BtbN> muxing and demuxing
[14:18:15 CEST] <nightlingo> furq: ive already done it for cutting an mp4 file
[14:18:42 CEST] <nightlingo> BtbN: cool thanks, Ill check it out
[14:18:42 CEST] <BtbN> it's pretty much impossible for an mp4 file, as the destination needs to be seekable, which stdout is not
[14:18:59 CEST] <nightlingo> BtbN: for cutting there is no need for it to be seekable
[14:19:10 CEST] <BtbN> there is, as it needs to write the moov atom at the very end
[14:19:27 CEST] <nightlingo> BtbN: you can pre-calculate the moov atom and write it in the beginning
[14:19:41 CEST] <nightlingo> BtbN: or at the end, no problem there
[14:19:42 CEST] <BtbN> moving the moov-atom to the beginning is a post-processing operation
[14:20:33 CEST] <nightlingo> BtbN: post-processing for ffmpeg, but if you make a custom app to do this , it can be pre-processing
[14:21:11 CEST] <BtbN> The format doesn't allow that, as the information in the moov atom isn't known before the file is finished
[14:21:45 CEST] <nightlingo> BtbN: I think this depends on the process you want to perform on the streams. For cutting, you have all the info you need from the beginning
[14:21:57 CEST] <nightlingo> BtbN: Im not sure about muxing yet
[14:22:30 CEST] <BtbN> no idea what you are on about
[14:22:36 CEST] <BtbN> to cut stuff, you need to demux it first
[14:22:47 CEST] <BtbN> There is no support for cutting without remuxing in ffmpeg
[14:23:17 CEST] <nightlingo> BtbN: I said that im doing this without ffmpeg. with my own code
[14:23:59 CEST] <BtbN> Well, how should I know... you are asking in #ffmpeg, so I'll assume you are using ffmpeg.
[14:24:11 CEST] <nightlingo> BtbN: because I mentioned it : )
[14:24:19 CEST] <BtbN> no you didn't
[14:24:44 CEST] <furq> 13:13:49 ( nightlingo) BtbN: I mean,  without using ffmpeg
[14:24:45 CEST] <marbar> hey guys i have a sort of off topic question, but everyone's asleep in #chrome and i miss you guys
[14:24:56 CEST] <furq> he did, but it was fair for you to assume he meant he was using libav*
[14:24:58 CEST] <marbar> anyone here ever mess with the media source extensions?
[14:25:03 CEST] <marbar> like, html5 MediaRecorder?
[14:25:27 CEST] <nightlingo> yeah no big deal
[14:25:31 CEST] <marbar> (and if this question doesn't fly here, any channel recommendations?)
[14:27:44 CEST] <nightlingo> BtbN: thtnks for the avformat recommendation though, Ill check it out
[14:28:02 CEST] <BtbN> it's probably still easier than messing with the mov-format yourself
[14:28:41 CEST] <BtbN> But I'm pretty sure writing mp4 to stdout doesn't work
[14:29:01 CEST] <nightlingo> I see
[14:29:27 CEST] <BtbN> Not 100% sure though, as the moov atom is at the very end, it might have no need to seek if you are ok with it being at the end.
[14:30:29 CEST] <nightlingo> BtbN: I think most likely Ill have to do the muxing myself
[14:30:45 CEST] <BtbN> Why do you even need to write it to stdout? Seems like a strange requirement
[14:31:18 CEST] <nightlingo> BtbN: Im working on a video server project and it is one of the requirements they gave me
[14:31:33 CEST] <nightlingo> BtbN: thats why Im also writing the moov atom at the beginning
[14:31:59 CEST] <BtbN> it's a bad requirement then, and I'd ask them why
[14:32:48 CEST] <nightlingo> BtbN: its because they want to be able to stream the resulting video on the fly, without waiting for the whole thing to process first
[14:33:07 CEST] <BtbN> mp4 is not the right format for streaming stuff
[14:33:10 CEST] <BtbN> it's not streamable
[14:33:35 CEST] <BtbN> There is some hacked version of it though, where that kind of works. DASH uses it
[14:33:39 CEST] <nightlingo> BtbN: I know, but they want at the same time as it is streaming to save it as an .mp4 file for later use
[14:34:15 CEST] <furq> you can write fragmented mp4 to stdout
[14:34:36 CEST] <nightlingo> furq: fragmented doesnt work with some crappy old players like windows media player (windows 7)
[14:34:58 CEST] <furq> oh
[14:35:07 CEST] <BtbN> if you stitch it back together it looks like a mostly normal mp4 file.
[14:35:16 CEST] <furq> yeah these requirements sound bad
[14:36:02 CEST] <BtbN> -movflags frag_custom+dash+delay_moov
[14:36:06 CEST] <BtbN> is what the DASH muxer sets
[14:36:33 CEST] <nightlingo> furq: yeap, pretty demanding :/
[14:37:09 CEST] <furq> delay_moov isn't even documented
[14:37:22 CEST] <nightlingo> BtbN: Ill try this with WMP but I doubt it will work. WMP is a nightmare
[14:37:23 CEST] <BtbN> dash isn't either
[14:37:47 CEST] <furq> any project where you have to support wmp seems like a bad deal
[14:38:12 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/movenc.c#L72 it's here, but somehow missing from the docs
[14:38:29 CEST] <furq> i can't imagine frag_custom will do anything different from frag_keyframe as far as wmp is concerned
[14:38:40 CEST] <furq> and frag_custom doesn't do anything if you use it with ffmpeg afaik
[14:38:51 CEST] <BtbN> frag_custom is for cutting at custom points, not at keyframes
[14:38:52 CEST] <furq> unless you're using the dash muxer
[14:39:05 CEST] <BtbN> It's useless for use with ffmpeg.c, only for API users
[14:39:10 CEST] <furq> and yeah i meant as far as wmp playback is concerned
[14:39:31 CEST] <furq> i guess you could just use the dash muxer though
[14:40:22 CEST] <nightlingo> I just tried: ffmpeg -y -i ~/tmp/input22.mp4  -c copy -movflags frag_custom+dash+delay_moov ~/tmp/frag.mp4
[14:40:33 CEST] <nightlingo> but unfortunately the output doesnt work even in VLC
[14:41:03 CEST] <BtbN> use frag_keyframe, and omit dash
[14:41:09 CEST] <nightlingo> ok
[14:41:21 CEST] <BtbN> frag_custom is for using the muxer via API, to trigger custom fragment cuts
[14:41:26 CEST] <furq> oh hey did the mp3 muxer get xing header support
[14:42:04 CEST] <furq> thank you failed firefox search for alerting me to this
[14:42:14 CEST] <nightlingo> BtbN: yah it doesnt work on WMP unfortunately
[14:42:32 CEST] <BtbN> nothing works on WMP
[14:42:42 CEST] <nightlingo> BtbN: I know : (
[14:42:43 CEST] <furq> does mpegts work in wmp
[14:44:36 CEST] <nightlingo> furq: it opens the file, but it plays it weirdly
[14:44:53 CEST] <nightlingo> furq: like, it plays first some of tha audio, then starts playing a bit of the video and suddenly stops
[14:45:54 CEST] <BtbN> -movflags frag_keyframe+delay_moov -f mp4 - > test.mp4
[14:46:10 CEST] <BtbN> produces a playable mp4 file for me. Just the time and seek bar is messed up
[14:46:35 CEST] <nightlingo> BtbN: did you use -c copy ?
[14:46:54 CEST] <BtbN> no
[14:47:20 CEST] <nightlingo> yeah I forgot, another requirement :/
[14:47:50 CEST] <BtbN> works with -c copy as well.
[14:47:57 CEST] <nightlingo> BtbN: in WMP ?
[14:48:04 CEST] <BtbN> In VLC
[14:48:10 CEST] <BtbN> wmp has no idea how to play mp4 for me.
[14:48:19 CEST] <nightlingo> ah ok yes I know, VLC works there
[14:48:25 CEST] <BtbN> Not even normal mp4 files
[14:48:46 CEST] <nightlingo> wmp is crappy but unfortunately still used by lots of people
[14:49:03 CEST] <nightlingo> just because its the default player
[14:49:37 CEST] <furq> can you not just make this work in browsers
[14:50:02 CEST] <furq> by which i mean can you not just go and tell your client that they are wrong and also stupid
[14:50:08 CEST] <nightlingo> furq: lol
[14:51:09 CEST] <BtbN> Yeah, WMP even fails to play a plain old mp4 file without any fragmenting
[14:51:14 CEST] <jcay_mb> ^^
[14:51:14 CEST] <BtbN> claiming it's an unknown format
[14:51:40 CEST] <nightlingo> BtbN: which version of WMP is that?
[14:51:47 CEST] <BtbN> There are versions of it?
[14:51:50 CEST] <BtbN> Whatever came with my OS
[14:52:06 CEST] <nightlingo> BtbN: which version of Windows is that?
[14:52:08 CEST] <jcay_mb> there are versions, sure
[14:52:09 CEST] <BtbN> 10
[14:52:15 CEST] <furq> lol
[14:52:22 CEST] <furq> it's actually got better since 7
[14:52:27 CEST] <furq> at least according to some people in here
[14:52:28 CEST] <nightlingo> BtbN: thats weird, mine plays old mp4 files and its windows 7
[14:52:50 CEST] <BtbN> I think they dropped support for some formats in later versions, because they didn't want to pay license fees
[14:52:52 CEST] <nightlingo> BtbN: maybe its just an unsupported codec
[14:52:53 CEST] <furq> is it just h264/aac and no extra streams
[14:52:59 CEST] <jcay_mb> i havent been using wmp for ages
[14:53:01 CEST] <furq> if so that's pretty funny
[14:53:08 CEST] <BtbN> h264 + aac
[14:53:11 CEST] <nightlingo> wow
[14:53:14 CEST] <BtbN> in mp4, without faststart
[14:53:39 CEST] <nightlingo> thats so lame
[17:13:11 CEST] <Hfuy> Hello.
[17:13:19 CEST] <Hfuy> Strange result for a very simple command line: https://pastebin.com/T19KXNFK
[17:13:41 CEST] <Hfuy> For some reason, x264 complains "unable to set encoding parameters" on a simple ffmpeg -i in.mov out.mp4
[17:13:51 CEST] <Hfuy> But it doesn't really say why.
[17:14:13 CEST] <JEEB> it's not x264
[17:14:31 CEST] <Hfuy> Oh, so it isn't. I still don't understand the problem.
[17:14:42 CEST] <JEEB> first of all, the last line mentions (output) stream #0:1, which is the audio one
[17:14:46 CEST] <JEEB> then you scroll up
[17:14:55 CEST] <JEEB> [libvo_aacenc @ 04dff960] Unable to set encoding parameters
[17:15:02 CEST] <Hfuy> Yes, I see that now. I still don't understand the problem.
[17:15:19 CEST] <JEEB> now, this is where that wrapper doesn't do sanity checks well enough
[17:15:23 CEST] <JEEB> it only handles stereo
[17:15:27 CEST] <JEEB> and you're feeding it 4ch
[17:15:31 CEST] <Hfuy> I certainly am.
[17:15:33 CEST] <JEEB> that said
[17:15:41 CEST] <JEEB> stop using vo_aacenc
[17:15:52 CEST] <JEEB> it's worse than the internal AAC encoder in post 2015 versions of FFmpeg
[17:15:59 CEST] <Hfuy> Well, I didn't specifically ask for that encoder. If they don't want it used, I query why it's the default.
[17:16:15 CEST] <JEEB> well that is quite an old version of ffmpeg.c
[17:16:35 CEST] <JEEB> that might be from before the internal one got improved
[17:16:37 CEST] <Hfuy> I did download a new binary today.
[17:16:45 CEST] <Hfuy> Not that one, I hasten to add.
[17:17:18 CEST] <JEEB> anyways, in general I've learned not to trust the default selection of encoders even if the pick lists have been recently made sane(r)
[17:17:23 CEST] <Hfuy> My object here is to produce some demos showing how two different h.264 encoders (and h.265 encoders, if I can get my hands on one) produce different results at the same bitrate by using different encoding options.
[17:17:37 CEST] <Hfuy> I was thinking I'd compare the ultra-high-speed and ultra-careful presets.
[17:18:25 CEST] <JEEB> I think someone made a nice "bang for buck" comparison for x264
[17:18:50 CEST] <Hfuy> I can also compare MPEG-2, which I guess is still being used for broadcasting.
[17:18:55 CEST] <JEEB> holy crap this is old by now, although x264 hasn't changed that much in recent years https://gist.github.com/kodabb/9272807132e5438dfd269482d33b670c
[17:18:59 CEST] <Hfuy> Is there a JPEG-2000 encoder in ffmpeg?
[17:19:50 CEST] <JEEB> at the very least there's a wrapper for some encoder I think
[17:20:04 CEST] <JEEB> generally JPEG2000 seems like something made to sell HW decoders (and encoders)
[17:20:11 CEST] <Hfuy> My biggest complaint is that it's very hard to get ffmpeg to actually stick to a bitrate.
[17:20:24 CEST] <JEEB> that is up to the encoder rather than FFmpeg in general
[17:20:26 CEST] <Hfuy> People reading the article I'm preparing are likely to want to see it at, say, 100Mbps.
[17:20:47 CEST] <JEEB> some encoders suck at rate control, others (like libx264) are good at it
[17:20:56 CEST] <Hfuy> Eh, well, ffmpeg supplies the encoder, that's between ffmpeg and the encoder people.
[17:21:01 CEST] <JEEB> no
[17:21:03 CEST] <JEEB> or well
[17:21:09 CEST] <JEEB> depends on if the encoder is within libavcodec
[17:21:36 CEST] <Hfuy> Not my problem. It's up to ffmpeg to provide the tools. There's a limit to how involved I can be as a user.
[17:21:43 CEST] <JEEB> ...
[17:22:18 CEST] <Hfuy> It seems to aim for about 15Mbps on "veryslow."
[17:22:39 CEST] <Hfuy> ...and similar rates on "ultrafast
[17:24:22 CEST] <JEEB> with libx264 for example what FFmpeg provides is a light shim between the libx264 library and the libavcodec framework. so there can be issues in that shim/wrapper, but generally then the issue is in the encoder (and it can be most likely also repro'd with the x264's own command line tool). so saying "FFmpeg provides something" is so wrong on so many levels :D then again with stuff like mpeg-2 video the
[17:24:28 CEST] <JEEB> encoder is 100% within libavcodec so that's something completely up to FFmpeg
[17:24:47 CEST] <JEEB> anyways, if you set a bit rate (and if you require VBV/HRD, -maxrate and -bufsize) libx264 does keep to that
[17:24:51 CEST] <Hfuy> Does x265 support -presets like 264 does? Some guides suggest it does.
[17:25:07 CEST] <JEEB> yes, libx265 (Which is confusingly enough completely separate from libx264) does have presets
[17:25:17 CEST] <JEEB> and the -preset option in libavcodec is mapped to it
[17:25:19 CEST] <Hfuy> Same people, isn't it?
[17:25:22 CEST] <JEEB> no
[17:25:38 CEST] <JEEB> x264 was a collaborative thing, x265 was licensed as a name from x264 LLC
[17:25:42 CEST] <JEEB> by MultiCoreWare
[17:25:49 CEST] <JEEB> and it is a barely-open-source kind of project
[17:26:07 CEST] <Hfuy> Oh, dear. "Unknown encoder x265"
[17:26:13 CEST] <furq> libx265
[17:26:15 CEST] <JEEB> libx265 if you have it linked in
[17:26:22 CEST] <Hfuy> Oh for...
[17:26:24 CEST] <JEEB> if the build was made without it then nope
[17:26:40 CEST] <furq> external encoders are generally (always?) prefixed with lib
[17:26:41 CEST] <JEEB> they (MCW) do keep the source open, but no attempt at making a community
[17:26:43 CEST] <Hfuy> Seems OK with the lib prefix.
[17:27:02 CEST] <JEEB> the open source part was mostly dictated in their license to get the name I guess
[17:27:10 CEST] <JEEB> (and they got the right to use parts they want from libx264)
[17:27:30 CEST] <Hfuy> My understanding is that x264 was fundamentally the personal project of one individual.
[17:27:36 CEST] <JEEB> no
[17:27:46 CEST] <Hfuy> ...but I doubt that based on other information.
[17:27:46 CEST] <JEEB> well, projects usually start with one or a couple of people
[17:28:03 CEST] <JEEB> but at the point where I started being around the project there were multiple very active developers
[17:28:29 CEST] <JEEB> there were two "leads" with one of them being more outwards being, but you couldn't at that point call it a single person's thing
[17:28:52 CEST] <JEEB> so many people had contributed between 2003 and 2007-8 (which is when I started hanging around that community)
[17:29:00 CEST] <Hfuy> I have long held the feeling that the person we're discusssing is a ruthless self-promoter.
[17:29:16 CEST] <JEEB> dunno
[17:30:15 CEST] <iive> i've never got the impression that pengvado is self-promoter
[17:30:41 CEST] <JEEB> anyways, I'm just going to say that I have no idea of the rate control capabilities of libx265, although it is most likely better than libvpx
[17:30:50 CEST] <furq> it'd struggle to be worse
[17:30:58 CEST] <JEEB> exactly
[17:31:00 CEST] <Hfuy> I'm in the process of finding out.
[17:31:18 CEST] <JEEB> do note that if you're aiming for a specific bit rate you want to use two-pass encoding
[17:31:36 CEST] <Hfuy> Well, I have to be a bit careful as I'm trying to design a (fairly informal) demonstration of something.
[17:31:52 CEST] <Hfuy> I'll probably want to use fairly low rates so as to make the differences more obvious.
[17:32:07 CEST] <JEEB> yes, at high enough bit rates you might as well be using MPEG-2 Video
[17:32:15 CEST] <Hfuy> Quite.
[17:32:19 CEST] <JEEB> it just doesn't matter (too much) at that point
[17:32:38 CEST] <JEEB> at most it's a case of what the format supports in terms of features
[17:32:47 CEST] <JEEB> like colorimetry metadata or so
[17:32:51 CEST] <JEEB> not actual compression stuff
[17:33:24 CEST] <Hfuy> This is something that's mainly of interest to camerapeople for recording the original material. So, the bitrates tend to be quite high.
[17:33:51 CEST] <Hfuy> 50mbps is a low bitrate for us.
[17:34:03 CEST] <JEEB> at that point I wish more people were just using some sort of lossless compression, which some things thankfully do.
[17:34:14 CEST] <Hfuy> It's moving that way.
[17:34:22 CEST] <Hfuy> Flash is becoming sufficiently cheap.
[17:35:39 CEST] <Hfuy> The problem we mainly have is constant attempts at vendor lock-in, which is even more irriating since every year, they announce a new, mutually incompatible in-camera format, which turns out to be h.264 with slightly different settings.
[17:35:55 CEST] <JEEB> oh, hi there AVC Intra
[17:36:14 CEST] <JEEB> which is supposed to be specified in one way but then you have to get the NDA'd specs from <corp> to actually implement it in a way that things will ingest it
[17:36:20 CEST] <Hfuy> good morrow, XAVC!
[17:36:28 CEST] <JEEB> not to mention that the NDA'd one breaks the goddamn AVC specification
[17:36:39 CEST] <JEEB> so the streams are officially broken as <beep>
[17:36:55 CEST] <JEEB> but hey, can't have no vendor lock-ins with modern standards amirite ;)
[17:37:07 CEST] <Hfuy> Better yet, take two Apple-approved implementations of ProRes, and find they won't play each other's files. Looking at you, Blackmagic and Atomos.
[17:38:04 CEST] <JEEB> well, that at least is an Apple-proprietary JPEG copycat
[17:38:17 CEST] <Hfuy> I believe it has demonstrably rather better performance than JPEG.
[17:39:16 CEST] <Hfuy> Still, my purpose here is to demonstrate why a $1500 DSLR doesn't get such good results from its h264 codec than a $50,000 encoder.
[17:39:21 CEST] <Hfuy> I'm sure I can do that.
[17:43:34 CEST] <Mandevil> So I reencoded a video and the result is... lighter (less contrasty).
[17:43:37 CEST] <Mandevil> What happened?
[17:44:20 CEST] <Mandevil> This is the cmdline used: https://pastebin.com/avLkT5Rm
[17:45:03 CEST] <JEEB> the actual output of the tool to the terminal would be useful
[17:46:41 CEST] <Mandevil> https://pastebin.com/d6Hdj4Z9 ... only the end, since there was lot of those progress lines.
[17:46:58 CEST] <Mandevil> Don't think it shows anything interesting.
[17:47:01 CEST] <JEEB> unfortunately just that part is pretty useless
[17:47:05 CEST] <Mandevil> Yeah.
[17:47:11 CEST] <Mandevil> It was 30+ hrs encode.
[17:48:18 CEST] <pihpah> Is there any way to get the size of audio stream in a video file?
[17:48:19 CEST] <JEEB> you can make another one that just has -vframes XX as well, which encodes that many video frames (of course change the output file name), and also do 2> output.log
[17:48:50 CEST] <JEEB> that way the full log goes into output.log if your command line doesn't have history enabled for enough lines
[17:50:09 CEST] <Mandevil> 2> will work in Windows cmd.exe?
[17:50:14 CEST] <JEEB> yes
[17:50:29 CEST] <pihpah> I have been preparing video files for streaming  for quite a time and only recently discovered that I completely missed out on audio enconding so even some 240p videos have 320k audio bitrate, what a fail.
[17:50:59 CEST] <Mandevil> JEEB: I can just restart the encode to see what's at the start...
[17:51:17 CEST] <JEEB> Mandevil: note the vframes XX and change output file name thing :P
[17:51:27 CEST] <JEEB> that way it will just encode a few frames in the beginning
[17:51:35 CEST] <Mandevil> Oh right.
[17:53:57 CEST] <Mandevil> JEEB: Here it is... https://pastebin.com/9gtVHRLj
[17:54:54 CEST] <Mandevil> "deprecated pixel format used, make sure you did set range correctly"
[17:54:59 CEST] <Mandevil> This sounds suspicious.
[17:55:43 CEST] <furq> yeah that's converting from full range to limited range
[17:56:57 CEST] <furq> try with -x265-params range=full
[17:57:16 CEST] <furq> there might be a better way though
[17:57:48 CEST] <JEEB> right, I expected something like that :)
[17:57:56 CEST] <JEEB> also not sure how many players support full range
[17:58:22 CEST] <furq> yeah setting full range should look correct but it might be better to do the conversion differently
[17:58:30 CEST] <furq> not something i've ever done though
[17:58:50 CEST] <JEEB> zscale's full=>limited range conversion should be good enough if required
[17:59:29 CEST] <Mandevil> Shouldn't the player handle the displaying the range correctly?
[17:59:36 CEST] <Mandevil> Ie. if it's limited, remap it?
[17:59:44 CEST] <Mandevil> (ie. stretch)?
[17:59:53 CEST] <JEEB> you'd be surprised how many players (both HW and SW) don't have a mode for full range YCbCr at all
[18:00:03 CEST] <JEEB> but if your player has that support and that's all you care about
[18:00:16 CEST] <Mandevil> I care about doing things correctly.
[18:00:19 CEST] <JEEB> then all you need is to get the information through, which somehow gets lost between input and output
[18:00:39 CEST] <JEEB> Mandevil: well both are "correct" :) just depends on which end result you need
[18:00:54 CEST] <JEEB> anyways, will start with the thought that your player(s) that you care about support full range
[18:01:02 CEST] <JEEB> in that case furq's x265-params thing will work
[18:01:14 CEST] <furq> you probably want to check that before another 30 hour encode though
[18:01:17 CEST] <JEEB> yes
[18:01:26 CEST] <JEEB> with -vframes XXXX to limit it somewhat
[18:01:28 CEST] <Mandevil> I still don't understand how these ranges work.
[18:01:29 CEST] <Mandevil> :-(
[18:01:54 CEST] <JEEB> well in YCbCr there's the full (pc) range, which is 0-255 everywhere. barely used at all.
[18:01:59 CEST] <JEEB> then there's the limited (tv) range
[18:02:04 CEST] <Mandevil> That much I know.
[18:02:10 CEST] <JEEB> which is 16-235 or 240 depending on luma/chroma
[18:02:19 CEST] <Mandevil> But how does the player know which range is used in a video?
[18:02:27 CEST] <JEEB> there's a parameter set/header value for that
[18:02:34 CEST] <JEEB> default is limited/tv
[18:02:43 CEST] <JEEB> so in your case something between input and output didn't pass that flag on
[18:02:51 CEST] <JEEB> most likely swscale or something just happily ignored it
[18:02:59 CEST] <Mandevil> I wasn't scaling at all.
[18:03:03 CEST] <Mandevil> It was just pure reencode.
[18:03:06 CEST] <furq> yeah probably some confusion between two different ways of flagging it
[18:03:08 CEST] <JEEB> yea, but swscale is an everpresent thing
[18:03:17 CEST] <Mandevil> Can I explicitly set this flag?
[18:03:20 CEST] <furq> x264 uses a full range pixel format (yuvj420p) but x265 has a separate flag for it
[18:03:28 CEST] <furq> and yeah that's what -x265-params range=full does
[18:03:30 CEST] <JEEB> yes, in the way that furq ntoed
[18:03:33 CEST] <Mandevil> Ah.
[18:03:34 CEST] <JEEB> *noted
[18:03:47 CEST] <JEEB> although in theory the flags from avframes should be propagated into the encoder
[18:04:01 CEST] <Mandevil> Apparently did not work in this case.
[18:04:03 CEST] <djk> I keep getting and increasing the value maybe I am missing something. Is there a linux system setting I should adjust or something else to avoid this?
[18:04:03 CEST] <djk>  Thread message queue blocking; consider raising the thread_queue_size option (current value: 4096)
[18:04:19 CEST] <JEEB> Mandevil: yea. and I see swscale did get into the mix even if it did nothing
[18:04:25 CEST] <furq> djk: you can normally ignore that message
[18:04:26 CEST] <JEEB> [swscaler @ 0000000002debfc0] deprecated pixel format used, make sure you did set range correctly
[18:04:32 CEST] <JEEB> or supposedly "nothing" :P
[18:04:48 CEST] <JEEB> Mandevil: see in input there's yuvj420p(pc, bt709)
[18:04:55 CEST] <Mandevil> Yeah, see that.
[18:05:00 CEST] <djk> so i shouldn't set it or just leave it
[18:05:00 CEST] <JEEB> and in the output it's just yuv420p
[18:05:17 CEST] <Mandevil> Can this be considered a bug?
[18:05:20 CEST] <JEEB> of course
[18:05:58 CEST] <Hfuy> ffmpeg does sometime seem to make some quite poor decisions about luminance range.
[18:06:10 CEST] <JEEB> there's some really awful legacy shit there
[18:06:20 CEST] <Hfuy> I noticed.
[18:06:26 CEST] <Hfuy> Same issue with colour primaries.
[18:06:29 CEST] <JEEB> like, "[swscaler @ 0000000002debfc0] deprecated pixel format used, make sure you did set range correctly"
[18:06:36 CEST] <JEEB> and then suddenly all metadata disappears
[18:06:52 CEST] <Hfuy> I get the (strong) feeling that most of the people who wrote this stuff were software engineers first and video engineers a poor forty-fifth.
[18:06:52 CEST] <furq> the most awful thing about that is "make sure you did set"
[18:07:32 CEST] <JEEB> the actual warning is about the J pixel format, which is correct. those shouldn't be used any more. but then while it's OK to remove the J it didn't actually pass any other info through :P
[18:07:56 CEST] <furq> it would be nice if the warning itself told you it was changing it
[18:08:00 CEST] <Hfuy> What on earth is a J pixel format?
[18:08:06 CEST] <furq> i know that's shown elsewhere but it'd still be nice
[18:08:10 CEST] <JEEB> Hfuy: the old awful way of marking full range
[18:08:14 CEST] <furq> Hfuy: yuvj420p
[18:08:16 CEST] <furq> e.g.
[18:08:24 CEST] <Hfuy> Oh, I see. J for Japan, as in zero setup?
[18:08:25 CEST] <furq> j for jpeg
[18:08:29 CEST] <Hfuy> Ah.
[18:08:35 CEST] <Hfuy> What a terrible, terrible nomenclature.
[18:08:49 CEST] <JEEB> yes, which has been deprecated for almost ten years now I think
[18:09:15 CEST] <Hfuy> Even now it can be alarmingly difficult to get ffmpeg to encode things for sRGB distribution without sitting all the blacks up at 16.
[18:09:26 CEST] <Hfuy> Which looks £$*&ing terrible.
[18:09:28 CEST] <atomnuker> J stands for "Just Awesome"
[18:09:35 CEST] <JEEB> you can basically walk around all that crap if you make your own API client
[18:09:42 CEST] <atomnuker> you know, in contrast with the TV propaganda limited range shit
[18:09:43 CEST] <JEEB> but ffmpeg.c is completely hosed
[18:09:56 CEST] <JEEB> and nobody seems to want to touch that side of things :)
[18:10:11 CEST] <Hfuy> A friend of mine wrote a tool for handling Canon DSLR video (which is 601 primaries with full range luma, and 1920x1080 frames)
[18:10:33 CEST] <Hfuy> Admittedly that format setup is also, what's the term, hosed, but ffmpeg could not handle it a few years ago. I don't believe it'll handle it correctly even now.
[18:10:47 CEST] <furq> i believe the term is "fucked"
[18:10:54 CEST] <JEEB> mixed luma and chroma ranges?
[18:10:59 CEST] <JEEB> I don't think zimg even would support that
[18:11:07 CEST] <Hfuy> I don't think so. I think it was all full range.
[18:11:08 CEST] <furq> that sounds ghastly
[18:11:24 CEST] <JEEB> ok, if it's all limited or full then newer stuff like zimg will support it just fine
[18:11:26 CEST] <Hfuy> But ffmpeg tends to assume 709 primaries for all HD-ish frame sizes, from what I can tell.
[18:11:36 CEST] <Hfuy> Thus everything goes neon orange.
[18:11:43 CEST] <JEEB> not FFmpeg itself but most likely swscale if so
[18:11:48 CEST] <JEEB> which is awful garbage
[18:12:09 CEST] <JEEB> I mean, it does a lot of crap that is more or less OK, but it was not written during times when correctness was one the top of the list
[18:12:14 CEST] <Hfuy> I have tried repeatedly to be of assistance to the ffmpeg people on this, but this is FOSS, so they do not take advice from non-coders.
[18:13:14 CEST] <JEEB> it speaks well enough that there's now a "colormatrix" filter instead of someone fixing swscale :)
[18:13:24 CEST] <Hfuy> I noticed that.
[18:13:42 CEST] <JEEB> also the zscale filter that utilizes zimg inside
[18:13:47 CEST] <Hfuy> That struck me as a sort of throwing-up-of-hands with the words "Aargh, we don't understand this stuff, you do it for us."
[18:14:19 CEST] <Hfuy> To be fair writing a full blown colourspace converter is not entirely trivial, although it's not THAT big a deal. It's just 3D scaling.
[18:14:29 CEST] <JEEB> the stuff is not that hard, it's just that swscale does so many things and people don't want to get into arguments when they remove features from something
[18:14:42 CEST] <JEEB> so (almost) nobody wants to do things to it
[18:14:59 CEST] <JEEB> oh, and it also does some automagic stuff which is another reason why people don't want to go near it
[18:15:05 CEST] <furq> it'd be nice if zimg got merged into the core
[18:15:16 CEST] <furq> although i guess the author has reasons to want to keep it a separate library
[18:15:29 CEST] <Hfuy> I have had a poor view of all this stuff ever since a few years ago when there was a move to delete some sort of drop-frame timecode provisions from some part of libav, on the basis that someone thought it was untidy.
[18:15:32 CEST] Action: Hfuy holds head in hands
[18:15:34 CEST] Action: Hfuy weeps quietly
[18:15:51 CEST] <JEEB> furq: even if zimg was taken in
[18:15:56 CEST] <JEEB> swscale would still be there
[18:16:21 CEST] <JEEB> and you can't replace swscale officially because everyone's dad's hacks are in tehre which are essential (To at least some theoretical person)
[18:16:33 CEST] <furq> does swscale do anything that zimg doesn't
[18:16:37 CEST] <JEEB> yes
[18:16:39 CEST] <furq> other than generate arguments
[18:16:50 CEST] <JEEB> it has a lot of edge stuff like paletted support tec
[18:16:52 CEST] <JEEB> *etc
[18:16:53 CEST] <JEEB> IIRC
[18:17:19 CEST] <JEEB> but yes, for most use we could just make simpler tools for specific use cases without swscale :P
[18:17:27 CEST] <Hfuy> They will eventually find that 100% back compat is non-feasible.
[18:17:29 CEST] <JEEB> and people are already doing that
[18:17:51 CEST] <furq> it'd still be nice if it was in the core though
[18:17:55 CEST] <Hfuy> I would very much like to make tools using libav, but the documentation is such a messy abortion that I've never been able to motivate myself to do it.
[18:18:05 CEST] <furq> you could e.g. remap -s and -pix_fmt to use zscale
[18:19:31 CEST] <Hfuy> This is strange. In my tests, HEVC is producing macroblocking artifacts with diagonal edges. Can it do that?
[18:19:33 CEST] <JEEB> Hfuy: I've found it to be better in recent years compared to quite a few of proprietary things. not going to mention names. but yes, a lot of stuff (Esp. the older stuff) is not explained well enough in documentation.
[18:20:20 CEST] <Hfuy> I would also note that libx265 is actually worse on "veryslow" than 264 is.
[18:20:33 CEST] <JEEB> you should think of those two as completely different things
[18:20:44 CEST] <JEEB> and yes, pyschovisual stuff is much less done in x265
[18:20:47 CEST] <Hfuy> I do. But the point is, 265 is supposed to be better.
[18:20:56 CEST] <JEEB> as a format, yes
[18:21:07 CEST] <Hfuy> The bitrates are similar. Presumably "veryslow" means something different in the two formats.
[18:21:12 CEST] <JEEB> yes
[18:21:23 CEST] <JEEB> which is why you either match speeds or you match both at "slowest settings"
[18:21:31 CEST] <JEEB> otherwise there's no comparison point
[18:21:38 CEST] <Hfuy> This raises the spectre that the "veryslow" 265 setting is not actually "best possible."
[18:21:45 CEST] <Hfuy> At least I hope like hell it isn't.
[18:21:52 CEST] <JEEB> well both of the encoders have placebo
[18:22:15 CEST] <JEEB> also check that you're using a recent enough lib265
[18:22:21 CEST] <JEEB> but yea (´4@)
[18:22:28 CEST] <JEEB> they never went for a community
[18:22:42 CEST] <JEEB> so I wouldn't be surprised if a lot of stuff never got found, reported or fixed/improved
[18:23:46 CEST] <Hfuy> Either way it's an interesting resulyt
[18:24:29 CEST] <Hfuy> I should note that the 265 encode was VASTLY slower for worse results.
[18:26:08 CEST] <Hfuy> Why is 265 producing all these strange triangular artifacts, I wonder?
[18:27:06 CEST] <kerio> the illuminati
[18:27:51 CEST] <Hfuy> In general this is terribly alarming, because 264 outperforms 265 gigantically, at least using the presets.
[18:28:01 CEST] <kerio> at which resolution?
[18:28:04 CEST] <Hfuy> 1080
[18:28:22 CEST] <Hfuy> Let me double check comparable bitrates, here.
[18:29:01 CEST] <andy_____> I am using kubuntu 14.04. Which is the best ffmpeg for me
[18:29:22 CEST] <JEEB> so you've set a bit rate, doing a 2pass encode with both libx264 and libx265 with the same-named preset (which will be different because different encoders etc blah blah, but still)
[18:29:31 CEST] <Hfuy> When I ffmpeg -i filename and it gives me a bitrate, how is it calculating that? It doesn't seem to take long enough to scan the whole file.
[18:29:41 CEST] <Hfuy> No, I'm doing a single-pass encode.
[18:29:44 CEST] <kerio> Hfuy: that's average bitrate
[18:29:51 CEST] <kerio> duration / file size
[18:29:56 CEST] <kerio> wait
[18:29:59 CEST] <kerio> file size / duration
[18:30:18 CEST] <kerio> or maybe it's the nominal bitrate embedded in the container?
[18:30:30 CEST] <JEEB> Hfuy: well then bugs in either encoder with a single pass + bit rate could be happening
[18:30:44 CEST] <JEEB> also are you passing -pass 1 or not?
[18:30:45 CEST] <Hfuy> There are certainly very large variations in the "very slow" bitrates.
[18:30:47 CEST] <kerio> itunes reports the wrong bitrate for ffmpeg-created ALAC files
[18:31:13 CEST] <Hfuy> veryslow 265 is yeilding about 185kbps, whereas veryslow 264 is around 996.
[18:31:27 CEST] <Hfuy> Perhaps I do need to two-pass it.
[18:31:27 CEST] <JEEB> yea, completely different encoders and rate control methods
[18:31:41 CEST] <JEEB> x264's generally is one of the best ones in town
[18:32:11 CEST] <kerio> what's the point of fitting a video in a certain size?
[18:32:19 CEST] <kerio> do people really use optical media in current_year
[18:32:31 CEST] <Hfuy> It's not so much about fitting it within a certain size, it's about total instantaneous bandwidth.
[18:32:33 CEST] <JEEB> well it's useful to limit a bit rate for tests
[18:32:43 CEST] <JEEB> so that you have a comparison point
[18:32:48 CEST] <kerio> hm, i guess
[18:32:54 CEST] <Hfuy> I wish yet again that ffmpeg had a -bitrate option.
[18:32:58 CEST] <JEEB> uhh
[18:33:01 CEST] <kerio> it doesn't help for streaming workloads tho
[18:33:02 CEST] <JEEB> -b:v XXXk
[18:33:11 CEST] <Hfuy> Yes, JEEB, but it doesn't actually work very well.
[18:33:18 CEST] <JEEB> and then if you need HRD/VBV there's -maxrate and -bufsize
[18:33:24 CEST] <JEEB> Hfuy: well that depends on the encoder, once again
[18:33:30 CEST] <JEEB> rather than FFmpeg's option
[18:34:03 CEST] <Hfuy> Talk to the hand, I'm afraid.
[18:34:07 CEST] <Hfuy> Write code so that code works.
[18:34:38 CEST] <Hfuy> If you can't provide video bitrate control, don't provide an option which claims to provide it.
[18:34:52 CEST] <JEEB> that's because we support a fuckload of video/audio encoder libraries
[18:34:57 CEST] <JEEB> and some of them suck dicks with some things
[18:35:43 CEST] <Hfuy> Why on earth is this video now 1072 pixels high?
[18:36:43 CEST] <JEEB> anyways, in my testing of x265 I haven't trusted various bits of its rate control, and I've used various 20+ CRF values to create the initial encodes
[18:36:57 CEST] <JEEB> and then I've done 2pass encodes with libx264 to match those
[18:37:03 CEST] <JEEB> in bit rate, that is
[18:37:16 CEST] <Hfuy> All I have to do is set -pass 1 then -pass 2, right?
[18:37:22 CEST] <JEEB> yes
[18:37:53 CEST] <Hfuy> I asked for 1000k, it's given me 803 on the very-slow, and 826 on the ultrafast, over a 125-frame clip.#
[18:37:59 CEST] <Hfuy> This strikes me as reasonable.
[18:38:41 CEST] <JEEB> that undercut it by quite a few bits :/
[18:38:55 CEST] <Hfuy> 20%. But I've struggled to ever have ffmpeg do better.
[18:39:03 CEST] <Hfuy> I find it almost always undershoots terribly.
[18:39:37 CEST] <JEEB> ok, since you know what I'm going to say I'm just going to switch channel at this point because the only thing that FFmpeg can do in libavcodec is map that bit rate option to an option in an encoder
[18:39:53 CEST] <JEEB> if the encoder the proceeds to fuck shit up it's none of my business unless I am working on that specific encoder
[18:41:06 CEST] <iive> i remember that ffmpeg had some problem with passing options to libx265
[18:41:22 CEST] <JEEB> yes, the libavcodec wrapper just doesn't map some options
[18:41:58 CEST] <iive> you have to use the specific x265 option to pass arguments to the x265 encoder
[18:42:06 CEST] <JEEB> not all, mind you
[18:42:18 CEST] <JEEB> but yes, for maxrate/bufsize for example the mapping just wasn't there for some reason :P
[18:42:35 CEST] <furq> kerio: why did you have to ruin the streak of people with the correct nick length
[18:43:47 CEST] <djk> getting - VBV is incompatible with constant QP, ignored, Should I just ignored or adjust the parms?
[18:43:47 CEST] <djk> ffmpeg  -thread_queue_size 4096 -probesize 128M -framerate 30 -r 30 -f x11grab -s 1200x700  -i :0.0+1280,0 -f lavfi -i anullsrc -c:v libx264 -pix_fmt yuv420p -g 60 -b:v 2560k -c:a aac -ar 44100 -b:a 128k -vf "pad=width=1280:height=720:x=40:y=5:color=black" -crf 0 -maxrate 2560k -bufsize 960k -r 30 -f flv "rtmp://rtmp-api.facebook.com:80/rtmp/$KEY"
[18:44:03 CEST] <furq> thebombzen: look what you did
[18:44:05 CEST] <furq> this is your fault
[18:44:48 CEST] <JEEB> djk: constant quantizer is the dumbest rate control there is and VBV/HRD with it is just a thing you shouldn't be asking for. if you need VBV/HRD you use CRF (or average bit rate)
[18:46:46 CEST] <djk> Also getting - WriteN, RTMP send error 104, sending to facebook is this a facebook issue or something else?
[18:48:13 CEST] <Hfuy> JEEB: I'm not asking you to fix it. I had no idea you were even involved.
[18:51:12 CEST] <JEEB> but yes, the general thing is that there are general parameters in libavcodec like bit rate. and then when people add new things they try to map some of them at the very least. how well that fucking works is up to that 3rd party thing someone is adding support for
[18:51:40 CEST] <JEEB> and yes, in theory if something is broken for something that's known it'd be nice if there was a warning/error
[18:52:07 CEST] <JEEB> but since the main point just seems to be add all the things, that isn't a priority (not to mention that third party things can improve or worsen with time)
[18:52:40 CEST] <JEEB> there are some internal things, but generally not many lossy video encoders get added lately :P
[18:55:12 CEST] <djk> JEEB: This all still new to me so where am I setting the the vbv
[18:57:28 CEST] <djk> the goal is to have as stable and efficient a stream to facebook as possible
[19:11:52 CEST] <Hfuy> JEEB I think the thing to bear in mind is that if you have a tool called ffmpeg and that tool doesn't, for instance, listen to instructions about bitrate very reliably, then the tool is going to be blamed.
[19:12:09 CEST] <Hfuy> At some point, interfacing with third-party shenanigans is a problem of the software engineer, to wit, you.
[19:12:30 CEST] <Hfuy> It's not as if the user is in a position to do much about it.
[19:13:25 CEST] <JEEB> yes, and I've had plenty of bullshit with interfacing with third parties. but in this case it's not like FFmpeg or ffmpeg.c are this opaque NDA'd piece of shit
[19:13:48 CEST] <JEEB> and in that case barking at the wrong tree really picks me up the wrong way
[19:14:31 CEST] <Hfuy> I understand your concern. The problem is that this is an endemic issue in open source software. It really is not the user's problem if they have a tool, they ask for X, get Y.
[19:15:05 CEST] <Hfuy> If you are not a software engineer, as almost everyone isn't, the inner workings of it are indeed completely opaque.
[19:15:36 CEST] <JEEB> well even fucking third grade fuck-dumb end users on this IRC channel generally understand the concept of picking an encoder, and if I tell them the encoder is broken they will understand it
[19:15:43 CEST] <Hfuy> I understand it.
[19:15:53 CEST] <Hfuy> Many won't, and they honestly shouldn't have to.
[19:16:04 CEST] <Hfuy> It's not a user problem. It's an engineering problem.
[19:16:12 CEST] <furq> it sort of sounds like a user problem
[19:16:28 CEST] <JEEB> it's a problem with unstable software and people wanting to integrate that shit into libavcodec
[19:16:37 CEST] <JEEB> and then of course you have batshit fucking awful shit in libavcodec itself
[19:16:51 CEST] <JEEB> which is a fucking separate problem and which is something that should be then fixed within FFmpeg
[19:17:17 CEST] <JEEB> and yes, this is why nobody just opens up every fucking encoder in the fucking libavcodec with all parameters to users if they sell software based on libav*
[19:17:36 CEST] <JEEB> because there's over fucking nine thousand bullshit pieces of shit that just won't always work right
[19:17:41 CEST] <CFS-MP3> This generates a screenshot every 10 seconds and a segment every 10 seconds. It works OK, except that the screenshot is not the first frame in the segment... what could be the reason?
[19:17:41 CEST] <CFS-MP3> ffmpeg -i udp://127.0.0.1:7316 -deinterlace -filter_complex "[0:v]split=2[in1][in2];[in1]fps=12,scale=416:-2:flags=lanczos[out1];[in2]fps=1/10,scale=416:-2:flags=lanczos[out2]" -map '[out1]' -codec:v libx264 -x264opts "keyint=120:min-keyint=120:no-scenecut"  -f segment -segment_time 10 -segment_start_number 1 -segment_list_type m3u8   seg_%06d.mp4 -map '[out2]' img_%06d.jpg
[19:17:47 CEST] <JEEB> and/or mixes of parameters
[19:18:23 CEST] <Hfuy> JEEB: I did notice the mildly shocking size of ffmpeg.exe. That's a large piece of software.
[19:18:36 CEST] <JEEB> that's mostly because it's generally a static thing
[19:18:41 CEST] <JEEB> most of that is outside of ffmpeg.c
[19:18:44 CEST] <Hfuy> Nearly 40MB, statically linked.
[19:18:54 CEST] <Hfuy> That's a metric shit-ton of code.
[19:18:56 CEST] <JEEB> even within FFmpeg you have multiple libraries
[19:19:19 CEST] <JEEB> that said, ffmpeg.c is a full-on shitfest of itself with the relevant related source files
[19:19:29 CEST] <JEEB> I've seen the "vsync" code paths and I don't even want to look at that side of things
[19:19:42 CEST] <JEEB> many of those ancient hacks nobody even knows if they're required any more
[19:20:06 CEST] <furq> a build with pretty much no external libs is about 13MB
[19:20:25 CEST] <JEEB> Hfuy: anyways that binaries is just so big because it's a full static link of various 3rd party libraries and the FFmpeg-internal ones also being in one big shtick
[19:20:37 CEST] <JEEB> and yes, about 10 megs for just the FFmpeg-internal stuff with all enabled
[19:20:54 CEST] <JEEB> if you use separate DLLs for stuff you separate that even more
[19:21:01 CEST] <JEEB> ffmpeg.c itself is not that huge. it is big but lol
[19:21:05 CEST] <Hfuy> My only feeling remains - that's a lot of code. A lot of a lot of code.
[19:21:12 CEST] <furq> yeah a dynamically linked ffmpeg is about 250KB
[19:21:16 CEST] <Hfuy> 40MB of compiled machine instructions is... really a lot of code.
[19:21:29 CEST] <JEEB> welcome to someone providing you a binary with the kitchen sink
[19:22:09 CEST] <furq> on which note i need to rebuild ffmpeg on my nas again because for some reason they don't think you should build with lame
[19:22:11 CEST] <Hfuy> It works. It's portable. I'm happy.
[19:22:12 CEST] <JEEB> anyways, there's quite a lot of stuff in the libav* libraries, but in general those tend to be "OK"
[19:22:15 CEST] <furq> freebsd ;_;
[19:22:46 CEST] <JEEB> size wise that is, although there's some ancients in mpeg-ps/ts demuxing for example
[19:23:03 CEST] Action: JEEB should really get ATRAC3+ parsing done from MPEG-PS
[19:23:12 CEST] Action: JEEB should really get Earthsoft DV finished in demuxing and decoding
[19:23:17 CEST] <furq> oh christ not atrac3+
[19:23:18 CEST] <Hfuy> Who on earth needs ATRAC?
[19:23:21 CEST] <Hfuy> I thought that was minidisc.
[19:23:22 CEST] <thebombzen> decoding
[19:23:30 CEST] <thebombzen> well, parsing
[19:23:31 CEST] <furq> i guess the ps3 uses it
[19:23:41 CEST] <thebombzen> but essentially if you have crappy old formats, being able to read them is nice
[19:23:52 CEST] <thebombzen> either way, some things about the ffmpeg project I don't understand
[19:23:52 CEST] <JEEB> Hfuy: there's plenty of sony game console games with ATRAC3+ audio, and I'd like to not have to select a separate audio file when playing those
[19:23:54 CEST] <furq> another thing that is nice is throwing atrac3 in the fucking bin
[19:24:01 CEST] <JEEB> Hfuy: encoding that shit. never.
[19:24:15 CEST] <thebombzen> it's like mp2
[19:24:17 CEST] <furq> i'm still annoyed that someone convinced me to buy a hi-md player instead of an mp3 player
[19:24:21 CEST] <thebombzen> there's no reason to ever encode mp2
[19:24:33 CEST] <Hfuy> Where are you finding that data - as part of a Sony game disc with video on it?
[19:24:36 CEST] <JEEB> yes
[19:24:38 CEST] <furq> that must have been about 14 years ago
[19:24:47 CEST] <JEEB> Hfuy: sometimes the encodes with a game are the best source for some video content
[19:24:54 CEST] <furq> i still got viscerally angry when you said "atrac3" and images of sonicstage appeared in my mind
[19:25:01 CEST] <thebombzen> either way, some code in the FFmpeg project I don't understand
[19:25:13 CEST] <JEEB> Hfuy: I'd probably use another audio source if I ever were to re-encode it (probably never), but for playback
[19:25:16 CEST] <thebombzen> for example, I'm not sure why people are dedicating time and effort to an internal opus encoder
[19:25:28 CEST] <Hfuy> I know nothing of ATRAC. It's a psycho-acoustic thing, though, isn't it?
[19:25:31 CEST] <thebombzen> why is that worth the time, when libopus already exists and is really good
[19:25:40 CEST] <JEEB> thebombzen: I think it's mostly someone's hobby thing
[19:25:44 CEST] <thebombzen> o
[19:25:46 CEST] <JEEB> for the decoder there was a requirement for it
[19:25:53 CEST] <thebombzen> decoder, absolutely I get that.
[19:25:55 CEST] <JEEB> as the EBU wanted at least two implementations
[19:26:08 CEST] <thebombzen> EBU? but either way yea I understand opusdec
[19:26:09 CEST] <JEEB> Hfuy: it's an old-ass audio format yes.
[19:26:11 CEST] <furq> yeah having an encoder is just going to confuse people
[19:26:13 CEST] <Hfuy> I would like to put it on record that libx265 on "veryslow" is indeed very slow.
[19:26:15 CEST] <furq> same as having a vorbis encoder
[19:26:25 CEST] <thebombzen> cause ffmpeg's decoders are generally faster than the reference decoder
[19:26:36 CEST] <JEEB> furq: at least atomnuker puts more effort than the vorbis encoder's author :)
[19:26:37 CEST] <thebombzen> ffvp8 is faster than libvpx, and ffvorbis is faster than libvorbis
[19:26:39 CEST] <thebombzen> decoder-wise
[19:26:48 CEST] <JEEB> although that's not much I guess :P
[19:26:52 CEST] <JEEB> because the vorbis one was a mistake
[19:27:04 CEST] <Hfuy> I love ffmpeg mainly for x264 on veryfast. Be still, my beating heart. Oh, the proxies. Oh, the burned-in timecode.
[19:27:15 CEST] <Hfuy> Oh, the extremely low CPU utilisation.
[19:27:16 CEST] <thebombzen> yea. I like having (finally) a good freeware AAC encoder
[19:27:20 CEST] <thebombzen> that was *LONG* overdue
[19:27:24 CEST] <furq> fdk is freeware
[19:27:26 CEST] <furq> it's just gpl incompatible
[19:27:33 CEST] <thebombzen> true
[19:27:50 CEST] <thebombzen> I guess I meant gpl-compatible freeware AAC encoder, one useable in ffmpeg without --enable-nonfree
[19:27:56 CEST] <furq> but yeah it's nice having something usable that you can distribute
[19:28:15 CEST] <thebombzen> well, vo-aacenc did exist
[19:28:15 CEST] <thebombzen> but
[19:28:19 CEST] <furq> i said usable
[19:28:22 CEST] <thebombzen> lolyea
[19:28:30 CEST] <furq> see also faac
[19:28:31 CEST] <JEEB> even google noticed vo-aacenc was garbage
[19:28:40 CEST] <JEEB> since they quickly bought fdk-aac
[19:28:53 CEST] <thebombzen> lol
[19:28:54 CEST] <Hfuy> Where does this thing put the -pass 1 rate control data?
[19:29:00 CEST] <furq> in pwd
[19:29:04 CEST] <JEEB> Hfuy: fully left to the encoder
[19:29:08 CEST] <JEEB> not specific to FFmpeg or libavcodec
[19:29:12 CEST] <furq> oh yeah
[19:29:15 CEST] <furq> but still, usually in pwd
[19:29:17 CEST] <thebombzen> usually in a some sort of text file in the current working directory
[19:29:21 CEST] <JEEB> (unless someone decided to be a smart-ass)
[19:29:21 CEST] <thebombzen> CWD, not PWD
[19:29:36 CEST] <thebombzen> PWD is "print working directory" cwd is "current working directory"
[19:29:46 CEST] <Hfuy> Called what?
[19:29:48 CEST] <JEEB> but yes, general gist is that you get a relatively large stats file in your currnet directory
[19:29:53 CEST] <thebombzen> Hfuy: it depends on the encoder
[19:29:56 CEST] <furq> why is the env var called PWD then
[19:30:01 CEST] <Hfuy> Oh. ffmpeg2pss-0.log.mbtree
[19:30:05 CEST] <JEEB> that's one of them
[19:30:07 CEST] <JEEB> that's the mbtree one
[19:30:11 CEST] <thebombzen> furq: because it's the result of running /usr/bin/pwd
[19:30:25 CEST] <thebombzen> yea but the logs are just large textfiles put in the current working directory
[19:30:27 CEST] <JEEB> also oh gawd, did they really change the file names :D
[19:30:30 CEST] <thebombzen> the actual name depends on the encoder
[19:30:42 CEST] <furq> yeah i'm pretty sure that's wrong
[19:30:45 CEST] <furq> it's pathname of working directory
[19:31:19 CEST] <thebombzen> https://en.wikipedia.org/wiki/Working_directory
[19:31:31 CEST] <thebombzen> "It is sometimes called the current working directory or CWD"
[19:31:40 CEST] <furq> yes?
[19:31:41 CEST] <Hfuy> "veryslow" on h.264 seems to be something like realtime.
[19:31:45 CEST] <furq> you're the one arguing that they're different
[19:31:58 CEST] <Hfuy> On 265, it seems to be about... er... many tens of realtime.
[19:32:15 CEST] <JEEB> Hfuy: yes, evolution in computer hardware does miracles to older software
[19:32:26 CEST] <JEEB> also x264 was quite optimized in its heydays
[19:32:48 CEST] <JEEB> x265 on the other hand is an encoder for a 10 years newer format plus other reasons
[19:32:59 CEST] <Hfuy> The impression I got was that x264 was hand optimised in assembler by twitching, emaciated nerds with extra brains in jars plugged into their cranial socketry.
[19:33:05 CEST] <thebombzen> yea, libx264 is great. x264's veryslow generaly can't do realtime for highdetail hd1080 video
[19:33:21 CEST] <thebombzen> it's very highly assembly optimized and mature
[19:33:24 CEST] <Hfuy> You know. Green glow. Throbbing sound.
[19:33:32 CEST] <thebombzen> something of that sort, yes
[19:33:50 CEST] <JEEB> yea, the community brought some really great stuff. also people used to care about the results
[19:34:03 CEST] <JEEB> nto that corps can't do great stuff of course, but x264/x265 really shows the divide
[19:34:11 CEST] <thebombzen> but yea HEVC is a much more complex format than H.264 so it should take longer to encode
[19:34:18 CEST] <thebombzen> plus, x265 is far far less optimized
[19:34:34 CEST] <Hfuy> You know what I'm talking about: https://www.youtube.com/watch?v=KlJ8eTuFe9U
[19:34:47 CEST] <thebombzen> generally, I feel that x265 is generally not worth the encoding time
[19:35:06 CEST] <thebombzen> but this was true about x264 in 2004 as well
[19:35:18 CEST] <furq> was it really
[19:35:31 CEST] <JEEB> yea, although already in 2006 you'd be using it
[19:35:33 CEST] <Hfuy> What was the alternative? Cinepak?!
[19:35:35 CEST] <furq> i remember x264 being faster than xvid the first time i ever used it
[19:35:40 CEST] <furq> mostly because you didn't need 2pass any more
[19:35:53 CEST] <JEEB> furq: yes, also in the end xvid never got as much optimizations
[19:35:54 CEST] <furq> also obviously being much better than xvid because xvid is piss
[19:36:04 CEST] <JEEB> more like MPEG-4 Part 2 was bad
[19:36:09 CEST] <furq> granted that probably wasn't 2004
[19:36:09 CEST] <JEEB> and yes, that's part of the thing
[19:36:18 CEST] <Hfuy> Let's put it this way.
[19:36:22 CEST] <JEEB> MPEG-4 Part 2 => AVC was a nice leap
[19:36:25 CEST] <Hfuy> Nobody is making broadcast cameras that record 265.
[19:36:39 CEST] <dsc_> what was the 'standard' for pirates before xvid? i remember some crappy mpeg2 type stuff going on in the early 2000s
[19:36:43 CEST] <JEEB> AVC => HEVC is harder to be better than the best encoder of the previous gen
[19:37:08 CEST] <Hfuy> My understanding is that HEVC was specced for a given amount of PQ improvement at no more than n-times the decoding effort.
[19:37:10 CEST] <JEEB> no more huge things like CABAC and in-loop deblocking
[19:37:12 CEST] <Hfuy> Encoding effort was not considered.
[19:37:13 CEST] <furq> divx was the standard before xvid
[19:37:18 CEST] <furq> before that probably mpeg2video
[19:37:22 CEST] <dsc_> right
[19:37:23 CEST] <JEEB> Hfuy: encoding effort wasn't really considered in AVC either
[19:37:25 CEST] <Hfuy> I may be misremembering.
[19:37:34 CEST] <Hfuy> Neither of them actually spec the encoder, do they?
[19:37:34 CEST] <JEEB> since encoders are expected to find the optimizations themselves
[19:37:45 CEST] <JEEB> nope, just that the output of the encoder is decode'able by the spec
[19:38:05 CEST] <JEEB> in AVC and HEVC there's even a mode where you can just dump the raw data. that is valid AVC/HEVC as well
[19:38:11 CEST] <JEEB> as long as you make the packets correct
[19:38:27 CEST] <Hfuy> Hmm. I'm reading both veryslow and ultrafast 264 as about 5 seconds to encode 125 frames, so I assume that's too short a clip for realistic timings.
[19:38:45 CEST] <JEEB> yea, I usually start with at least 2500+
[19:38:52 CEST] <JEEB> which usually isn't too long, either
[19:38:59 CEST] <Hfuy> veryslow 265 takes 145 seconds to encode 125 frames, which is vaguely ludicrous, too.
[19:39:14 CEST] <Hfuy> It seems to lock up for a while when it's fundamentally finished processing the frames. Some glitch at play?
[19:39:14 CEST] <furq> fyi "decodable" is a perfectly cromulent word
[19:39:26 CEST] <Hfuy> furq: I am thus embiggened.
[19:39:32 CEST] <furq> no need for the neologism apostrophe
[19:40:29 CEST] <Hfuy> Can I easily make ffmpeg dump frame 1 of these files as a jpeg?
[19:40:48 CEST] <Hfuy> Or better a PNG, actually. Something uncompressed.
[19:40:49 CEST] <furq> -frames:v 1 out.jpg
[19:41:00 CEST] <JEEB> after your initial output file do that what furq said
[19:41:08 CEST] <Hfuy> Thanks seems good.
[19:41:09 CEST] <JEEB> although if you are doing YCbCr->RGB make sure swscale doesn't touch it
[19:41:26 CEST] <furq> yeah you might want to save to tif or some lossless yuv image format
[19:41:36 CEST] <furq> some other, rather
[19:41:36 CEST] <JEEB> I'd just use zscale or so
[19:41:40 CEST] <furq> that works too
[19:41:46 CEST] <Hfuy> It's good enough for an online article.
[19:41:48 CEST] <JEEB> although you still have to keep an eye on the log
[19:41:50 CEST] <Hfuy> I'm not writing an SMPTE paper.
[19:42:03 CEST] <JEEB> because swscale creeps in the weirdest parts due to the automagic'ism
[19:42:35 CEST] <Hfuy> Put it this way: when I wrote some simple software to record input from SDI boards, I wrote my own file writer rather than get involved with avcodec and avformat.
[19:42:57 CEST] <Hfuy> Now, it would have been very nice to record a low-res proxy in tandem with the main event, but sheesh, the prerequisites. Sheesh, the godawful non-docs.
[19:43:27 CEST] <furq> i'm going to say it
[19:43:28 CEST] <furq> are you ready
[19:43:32 CEST] <furq> "contributions welcome"
[19:43:40 CEST] Action: Hfuy reaches for the flamethrower
[19:44:08 CEST] <Hfuy> I am a published technical writer and I would be happy to contribute, but they simply won't take advice from anyone who isn't a coder.
[19:52:06 CEST] <Hfuy> Is there some reason that x265 should introduce an small, single-digit-pixel vertical shift into an image on "ultrafast"
[19:53:53 CEST] <furq> it's not very good?
[19:54:57 CEST] <Hfuy> Well, so far it's being roundly outperformed by x264, I must say.
[19:55:06 CEST] <Hfuy> And I mean embarrassingly outperformed.
[19:56:08 CEST] <Hfuy> Perhaps I should compare some other sort of codec. MPEG-2, perhaps? JPEG-2000 if it's available?
[20:00:44 CEST] <thebombzen> furq: I menat more like
[20:00:50 CEST] <thebombzen> x264 was extremely slow in 2004
[20:01:00 CEST] <thebombzen> because it was not only unoptimized but computers sucked ass
[20:01:29 CEST] <Hfuy> If I ask it for -b:v 10000k on 264, I get roughly 10000k.
[20:01:44 CEST] <Hfuy> If I ask it for -b:v 10000k on 265, I get about 17000k.
[20:01:58 CEST] <thebombzen> #ratecontrol
[20:02:06 CEST] <JEEB> rate control is hard, just try libvpx's vp9
[20:02:26 CEST] <JEEB> I think in AOM they're trying to get theora's rate control in there for beep's sake :D
[20:02:32 CEST] <thebombzen> um
[20:02:40 CEST] <thebombzen> I haven't heard anything good about libvpx
[20:02:44 CEST] <JEEB> that's the joke
[20:02:49 CEST] <Hfuy> What's very odd is that both the start frames from the 1000k and 10000k h.264 appear identical.
[20:02:54 CEST] <Hfuy> I mean, bit for bit.
[20:03:10 CEST] <thebombzen> well Iframes are very highbitrate anyway
[20:03:24 CEST] <thebombzen> the keyframes are probably going to be similar
[20:03:55 CEST] <Hfuy> Perhaps I should take the second frame, for better comparison
[20:05:04 CEST] <kepstin> single-pass non-vbv bitrate controls is really something that's not optimized for much these days, since 2-pass gives better results, and with vbv you're often doing live stuff, which means compromising quality for speed anyways... :/
[20:05:18 CEST] <Hfuy> This is 2-pass.
[20:05:57 CEST] <kepstin> hmm, you're getting significantly wrong bitrates with x265 in 2-pass mode? That does sound odd :/
[20:06:07 CEST] <kepstin> I really would expect that to work.
[20:06:17 CEST] <Hfuy> Let me triple-check.
[20:09:41 CEST] <Hfuy> Pardon me, I am in fact entirely wrong - it's the 264 that's incorrect.
[20:10:02 CEST] <furq> that's pretty weird then
[20:10:06 CEST] <furq> x264's vbv is pretty good
[20:10:09 CEST] <Hfuy> C:\Users\CobaltUser>c:\ffmpeg -i D:\codecdemo\test.mov -an -c:v libx264 -preset ultrafast -pass 2 -b:v 10000k D:\codecdemo\ultrafast_264-2pass_10000k_ratecheck.mp4
[20:10:09 CEST] <furq> or er
[20:10:11 CEST] <furq> ratecontrol
[20:10:29 CEST] <Hfuy> bitrate=17664.1kbits/s
[20:10:32 CEST] <furq> maybe ultrafast is fucking it up
[20:10:38 CEST] <furq> since that turns off pretty much everything
[20:10:53 CEST] <Hfuy> Suggest a profile.
[20:11:00 CEST] <furq> even superfast would be a big improvement
[20:11:29 CEST] <Hfuy> Wait one.
[20:13:06 CEST] <Hfuy> Superfast is still 12000 or so.
[20:27:42 CEST] <Hfuy> So. The results of my experiment are essentially that 265 is in fact worse than 264 in essentially all circumstances.
[20:27:46 CEST] <Hfuy> This ought not to be the case.
[20:33:57 CEST] <JEEB> I think the last time I tested x264 and x265 at slowest presets by matching bit rate, x265 was "OK" but a lot of the coding tools seem to make optimization for PSNR real simple
[20:34:04 CEST] <JEEB> as in, what was added with HEVC
[20:34:08 CEST] <JEEB> and PSNR loves blur
[20:34:34 CEST] <JEEB> and the speed was completely different
[20:34:51 CEST] <JEEB> although the speed aspect is kind of expected because they're encoders of different time periods
[20:46:43 CEST] <Hfuy> I've written quite a bit about how it's possible to engineer a codec which achieves incredible PSNR while simultaneously looking like shit.
[20:47:54 CEST] <Hfuy> I have to say, though, and against all information to the contrary - x265 is simply a worse codec than x264. I can't make it look better.
[20:48:17 CEST] <Hfuy> 264 gives better PQ for the bitrate, in every circumstance I've tried.
[20:49:34 CEST] <JEEB> x265 doesn't have a lot of psychovisual optimizations, or at least not by default. some of the HEVC functionality enables you to get better PSNR very easily but I bet optimizing those tools for non-PSNR is harder
[20:50:05 CEST] <Hfuy> It's possible that what looks like sharpness in the 264 encode is actually just blocking.
[20:50:06 CEST] <JEEB> x264 actually has somewhat worse tooling in the format, but on the other hand a lot of the stuff has been grasped wrt how to (ab)use things for better visual quality
[20:50:08 CEST] <Hfuy> Which is sort of the same thing.
[20:50:10 CEST] <JEEB> yes
[20:50:13 CEST] <JEEB> perceived detail
[20:50:20 CEST] <JEEB> psy-rd/trellis in x264 were exactly that
[20:50:37 CEST] <JEEB> keeping the power or whatever of the output closer to the input even if the image is not exactly the same
[20:50:44 CEST] <Hfuy> I'm not aware of what those things are.
[20:51:03 CEST] <JEEB> something it enables by default for years now
[20:52:32 CEST] <zuiss1> hi. i have a bunch of .ts files which are pieces of a clip names like xyz001.ts, xyz002.ts, xyz003.ts, etc. i am reading the documentation on how to concatenate these into one file, and wanted to check here to make sure i am reading it right. do i need to create a list text file and do ffmpeg -f concat on the text file?
[20:54:00 CEST] <JEEB> zuiss1: if it's stuff from the same input just separated you should be able to concatenate by just stitching them together with cat or something
[20:54:10 CEST] <JEEB> MPEG-TS in that sense is simple
[20:55:21 CEST] <zuiss1> JEEB: i was actually planning on using ffmpeg to convert the final file from .ts to .avi or something
[20:55:37 CEST] <zuiss1> is .ts a common video format? i am not familiar with it
[20:55:48 CEST] <JEEB> in broadcast and blu-ray you have MPEG-TS used
[20:56:17 CEST] <JEEB> yea, if you're not just remuxing then you could use ffmpeg's concatenation (either the video filter or the demuxer or whatever you like)
[20:56:17 CEST] <zuiss1> oh
[20:56:37 CEST] <JEEB> for remuxing if the source is the same then you could have just slapped them together
[20:56:41 CEST] <JEEB> which you of course could just do
[20:56:46 CEST] <durandal_1707> concat protocol
[20:56:46 CEST] <JEEB> even if you're going to re-encode
[20:57:10 CEST] <zuiss1> would i use this: ffmpeg -f concat -safe 0 -i mylist.txt -c copy output
[20:57:25 CEST] <JEEB> for mpeg-ts don't do that
[20:57:33 CEST] <JEEB> since you could just cat
[20:57:44 CEST] <zuiss1> ok i can just use cat then
[20:59:04 CEST] <JEEB> yea, if it's MPEG-TS and from the same source
[21:01:55 CEST] <zuiss1> would this be correct? i don't really know bash. cat file{1..12}.ts > file.ts
[21:02:12 CEST] <zuiss1> i am trying to put it in a script
[21:05:49 CEST] <thebombzen> mpegts is very convenient in that concatenating .ts files (with cat) actually concatenates the videos together
[21:05:59 CEST] <thebombzen> so yes cat 1.ts 2.ts 3.ts >total.ts would work
[21:06:33 CEST] <thebombzen> you could also pipe it into ffmpeg. for example, try: cat {1..12}.ts | ffmpeg -f mpegts -i - other_options
[21:08:46 CEST] <zuiss1> thanks thebombzen
[21:09:22 CEST] <thebombzen> keep in mind that if the various .ts files don't have the same codec information it could cause problems
[21:09:42 CEST] <Hfuy> HEVC can have non-square macroblocks, yes?
[21:09:42 CEST] <thebombzen> but if they're all the same codecs with the same frame dimensions, there should be no problem with it
[21:09:49 CEST] <JEEB> Hfuy: no
[21:09:54 CEST] <thebombzen> Hfuy: HEVC doesn't have macroblocks
[21:10:12 CEST] <Hfuy> Well, OK, coding tree units.
[21:10:17 CEST] <thebombzen> it has "Coding Tree Units" which are squares, and can be subdivided into smaller squares
[21:10:34 CEST] <JEEB> there are some filters etc that could lead to funky artifacts if there's bugs etc
[21:10:46 CEST] <Hfuy> It really looks like it's using 32x16 blocks
[21:10:48 CEST] <thebombzen> the subdivision doesn't have to be uniform, but all the smaller sub-units have to be squares
[21:10:55 CEST] <Hfuy> Presumably it's a 64x64 block which is being coded down from there.
[21:11:02 CEST] <thebombzen> or 32x32
[21:11:09 CEST] <thebombzen> into 16x16 subblocks
[21:11:55 CEST] <thebombzen> also Hfuy you mentioned that HEVC screwed with one pixel
[21:12:00 CEST] <thebombzen> or rather x265 did
[21:12:09 CEST] <thebombzen> was it by any chance a screengrab subsampled to 4:2:0
[21:12:23 CEST] <Hfuy> I'm not sure.
[21:12:25 CEST] <thebombzen> screengrabs should generally not be subsampled becaused colored text will look wrong.
[21:13:50 CEST] <Hfuy> Oh. No, it's a reencode of some live action video.
[21:14:38 CEST] <thebombzen> then never mind
[21:15:20 CEST] <thebombzen> also, this is weird... but it seems to me that a remarkably simple way to turn color video into B&W is to just take the green channel
[21:15:29 CEST] <thebombzen> and it works surprisingly well
[21:15:40 CEST] <thebombzen> or rather... gray. not B&W
[21:18:29 CEST] <furq> i hope you're not converting a football game
[21:18:51 CEST] <Hfuy> The luma channel in most video formats is made largely of the green channel, for complicated reasons due to the sensitivity of human vision.
[21:18:58 CEST] <Hfuy> The green channel is also usually the quietest.
[21:21:41 CEST] <thebombzen> yea, I'm aware of how Y is mostly depdent on green
[21:21:56 CEST] <thebombzen> I just did a comparison where I took a photo I had and dumped it as gbrp rawvideo
[21:22:05 CEST] <thebombzen> and then as yuv444p rawvideo
[21:22:17 CEST] <thebombzen> then, I re-interpreted the rawvideo as gray8, to visualize
[21:23:05 CEST] <thebombzen> what I found was that while I knew Luma was more depedent upon green than others, I didn't realize how close they looked. the only real differences were the slight color range differences (15-285) and the large red object looked different^_^
[21:23:14 CEST] <thebombzen> really noticable differences, that is
[21:23:23 CEST] <thebombzen> 285 I mean 235 lol
[21:23:44 CEST] <thebombzen> unless it's 240. either way the modified color range was more apparent at the lower end, which the 15 lower bound being a problem
[21:23:48 CEST] <thebombzen> or not a "problem" but apparent
[21:34:17 CEST] <Hfuy> ffmpeg constantly gets that wrong.
[21:34:33 CEST] <Hfuy> sometimes there isn't sufficient information in the file to get it right, but it doesn't seem very smart about it, sometimes.
[21:57:10 CEST] <djk> The video is reasonably fluid but the bitrate goes to high causing facebook warnings of Too high bit rate. What am I missing to keep it down?
[21:57:10 CEST] <djk> nohup ffmpeg  -thread_queue_size 4096 -probesize 128M -framerate 30 -r 30 -f x11grab -s 1200x700  -i :0.0+1280,0 -f lavfi -i anullsrc -c:v libx264 -pix_fmt yuv420p -g 30 -b:v 2560k -c:a aac -ar 44100 -b:a 128k -vf "pad=width=1280:height=720:x=40:y=5:color=black" -crf 0 -maxrate 2560k -bufsize 960k -r 30 -f flv "rtmp://rtmp-api.facebook.com:80/rtmp/$KEY" &
[21:59:31 CEST] <furq> please look up what -crf 0 does
[21:59:36 CEST] <furq> and then stop using it
[22:00:46 CEST] <djk> does mean to take the maxrate and bufsize too? Yesterday it was encouraged to use for lossless and reduced CPU load
[22:01:20 CEST] <djk> when I have take it out the bitrate still goes to high and not as fluid
[22:08:58 CEST] <kerio> HOW DO YOU PLAN ON REDUCING THE BITRATE IF YOU ALSO TELL IT "BTW DO NOT LOSE ANY INFO"
[22:09:07 CEST] <kerio> MY MIND IS SO FULL OF FUCK RIGHT NOW
[22:09:40 CEST] <durandal_1707> no caps, please
[22:11:38 CEST] <Fenrirthviti> you probably want crf=18 for facebook, not crf=0
[22:11:39 CEST] <thebombzen> djk: lossless video means 100% of the information is encoded
[22:11:48 CEST] <furq> thebombzen: like i said, this is your fault
[22:11:54 CEST] <thebombzen> this is not possible at 2.5 Mbps
[22:12:10 CEST] <thebombzen> if you only want to have 2.5 Mbps, yo'll need some data
[22:12:17 CEST] <thebombzen> furq: also what is my fault?
[22:12:20 CEST] <furq> this
[22:12:52 CEST] <furq> 21:53:01 ( thebombzen) if you use -crf 0 -maxrate
[22:12:52 CEST] <furq> 21:53:07 ( thebombzen) will that emulate CBR in x264
[22:13:11 CEST] <thebombzen> and then I immediately corrected it to -crf 15
[22:13:16 CEST] <thebombzen> like 30 seconds later
[22:13:44 CEST] <furq> you mean 70 minutes later
[22:13:52 CEST] <thebombzen> was it really 70 minutes?
[22:13:55 CEST] <thebombzen> lol
[22:13:59 CEST] <thebombzen> using -crf 0 -maxrate shoudl work in theory, but it appears that when you set the crf to 0, libx264 locks into lossless mode
[22:14:08 CEST] <thebombzen> and ignores the maxrate option when using -crf 0
[22:14:16 CEST] <furq> 23:01:54 ( thebombzen) it'd probably be better to set the crf to something crazy low but not truly zero
[22:14:19 CEST] <furq> 23:01:56 ( thebombzen) like 15
[22:14:26 CEST] <furq> 68. i'm sorry i lied
[22:14:29 CEST] <thebombzen> good enough
[22:14:47 CEST] <thebombzen> but either way, I didn't realize libx264 ignored the maxrate option when you set the crf to 0
[22:14:57 CEST] <thebombzen> because it doesn't for any other crf
[22:15:15 CEST] <thebombzen> but I wouldn't say this is "all my fault"
[22:15:28 CEST] <furq> i didn't say that either
[22:15:37 CEST] <thebombzen> [16:11:49] <furq> thebombzen: like i said, this is your fault
[22:15:40 CEST] <thebombzen> you kind of did
[22:15:42 CEST] <djk> so keep the -crf but at something like 1 or 15?
[22:16:01 CEST] <djk> and the maxrate will not be lost?
[22:16:06 CEST] <thebombzen> I'm not going to answer this quesiton cause furq just going to blame me if you keep asking.
[22:16:14 CEST] <thebombzen> even if my answer is correct
[22:16:58 CEST] <djk> lol
[22:17:27 CEST] <thebombzen> but also, you should avoid using -b:v and -crf at the same time
[22:17:49 CEST] <thebombzen> one of them is ABR (average bitrate) and one is VBR (or quality-based encoding)
[22:17:59 CEST] <thebombzen> they're mutally exclusive
[22:18:11 CEST] <Fenrirthviti> start at 18 and lower until your PC explodes.
[22:18:50 CEST] <djk> so going lower is more taxing on the cpu?
[22:19:13 CEST] <djk> I thought someone said the opposite
[22:20:39 CEST] <Fenrirthviti> lower = more quality = more cpu
[22:21:00 CEST] <Fenrirthviti> it's a bit confusing at first
[22:21:36 CEST] <djk> ok so I had the understanding correct.
[22:21:56 CEST] <djk> nohup ffmpeg  -thread_queue_size 4096 -probesize 128M -framerate 30 -r 30 -f x11grab -s 1200x700  -i :0.0+1280,0 -f lavfi -i anullsrc -c:v libx264 -pix_fmt yuv420p -g 30 -b:v 2560k -c:a aac -ar 44100 -b:a 128k -vf "pad=width=1280:height=720:x=40:y=5:color=black"  -bufsize 960k -r 30 -f flv "rtmp://rtmp-api.facebook.com:80/rtmp/$KEY" &
[22:22:11 CEST] <djk> that is my current state.
[22:22:49 CEST] <dsc_> thats some command
[22:26:49 CEST] <djk> I want to keep quality consistent -crf 15 -maxrate 2560k is the better way and drop the -b:v?
[22:27:22 CEST] <djk> also want to reduce the buffer the Facebook showing
[22:27:42 CEST] <Fenrirthviti> I feel like most of those settings are completely unnecessary :x
[22:28:04 CEST] <Fenrirthviti> What exactly are you trying to stream? Just your desktop?
[22:28:33 CEST] <djk> a portion on the one display
[22:29:49 CEST] <djk> this is a kludge to provide a live stream of a webcam on a raspberry pi that using Hawkeye (mpeg-streamer based)
[22:30:14 CEST] <Fenrirthviti> have you tried an actual stream tool like OBS or similar? Might be easier on your sanity.
[22:30:28 CEST] <furq> uh
[22:30:31 CEST] <djk> the pi is not capable of ffmpeg encoding
[22:30:33 CEST] <furq> can you not just capture from the webcam directly
[22:30:48 CEST] <djk> the pi is remote
[22:30:58 CEST] <furq> h264_omx should be able to do 720p30 easily
[22:31:15 CEST] <djk> it is a usb webcam
[22:31:54 CEST] <djk> tried obs the machine hardware isn't supported
[22:32:05 CEST] <djk> this the closest I have come to the answer
[22:33:04 CEST] <kerio> your "closest to the answer" is pretty awful
[22:33:25 CEST] <kerio> why are you doing 2 or possibly 3 transcodes
[22:33:35 CEST] <kerio> with a display and a x11grab in the middle
[22:34:10 CEST] <kerio> if hawkeye can use your webcam, it's likely just a v4l2 device
[22:34:31 CEST] <kerio> if you can get h264 out of your camera, you're set
[22:34:40 CEST] <kerio> if you can get raw video, you're probably also set if you use h264_omx
[22:34:55 CEST] <kerio> if you get something else it depends
[22:36:04 CEST] <djk> USB_Camera (usb-3f980000.usb-1.5):
[22:36:04 CEST] <djk>         /dev/video0
[22:38:13 CEST] <djk> pixel format: yuyv and mjpeg
[22:38:27 CEST] <thebombzen> there you go
[22:38:32 CEST] <thebombzen> also mjpeg is not a pixel format
[22:38:46 CEST] <thebombzen> but there. just use ffmpeg -f v4l2 -i /dev/video0
[22:39:06 CEST] <thebombzen> you might have options on which frame size to use. if so, put -video_size WxH before -i /dev/video0
[22:39:17 CEST] <thebombzen> some webcams will give you higher framerates at 640x480 than 1280x720
[22:40:28 CEST] <kerio> djk: ffplay -f v4l2 -list_formats all /dev/video0
[22:41:12 CEST] <Hfuy> OK thanks folks, later
[22:41:47 CEST] <djk> [video4linux2,v4l2 @ 0x71d004a0] Raw       :   yuyv422 :           YUYV 4:2:2 : 640x480 160x120 176x144 320x240 352x288 800x600 1280x720 1920x1080
[22:41:47 CEST] <djk> [video4linux2,v4l2 @ 0x71d004a0] Compressed:     mjpeg :          Motion-JPEG : 640x480 160x120 176x144 320x240 352x288 800x600 1280x720 1920x1080
[22:41:52 CEST] <furq> 720p yuy2 over usb2 probably isn't going to work well
[22:42:01 CEST] <furq> and mmal doesn't expose the mjpeg decoder yet
[22:42:05 CEST] <kerio> :(
[22:42:18 CEST] <kerio> furq: hold on why not
[22:42:20 CEST] <furq> 480p should be fine though
[22:42:23 CEST] <furq> kerio: which
[22:42:35 CEST] <kerio> usb2 is 400ish mbps isn't it
[22:43:28 CEST] <furq> 720p30 yuy2 is 440mbps
[22:43:37 CEST] <kerio> D:
[22:43:48 CEST] <furq> usb2 is theoretically 480 but anything more than about 300 is going to suck
[22:43:50 CEST] <furq> especially on a pi
[22:43:59 CEST] <kerio> djk: if you're fine with 480p you can do it all from the pi
[22:44:04 CEST] <furq> yeah 480p should be ok
[22:44:05 CEST] <djk> v4l2-ctl --list-formats-ext show yuyv 640x480 at 30fps
[22:44:12 CEST] <kerio> nice
[22:45:35 CEST] <kerio> ffmpeg -f v4l2 -input_format yuyv422 -video_size 640x480 -framerate 30 /dev/video0 -c:v h264_omx -f flv rtmp//whatever
[22:45:36 CEST] <djk> the other part I want to grab stills every x seconds so after the event we can make a time-lapse
[22:45:54 CEST] <TD-Linux> I would seriously hope a rpi3 would be fast enough to decode mjpeg in software
[22:46:14 CEST] <furq> actually the last person who tried that and couldn't do it was on a pi zero
[22:46:24 CEST] <furq> 720p30 mjpeg might work ok on a pi 3
[22:46:25 CEST] <djk> this a 3
[22:46:30 CEST] <furq> give it a try then
[22:46:43 CEST] <furq> although if 480p is acceptable then i'd just stick with rawvideo
[22:46:45 CEST] <kerio> >:(
[22:46:53 CEST] <kerio> disgusting multicore cpu
[22:46:58 CEST] <kerio> pi0 master race
[22:47:10 CEST] <TD-Linux> many webcams are noisy enough that 480p is probably enough
[22:47:14 CEST] <furq> 720p30 at 2.5mbit might be too much for that encoder anyway
[22:47:22 CEST] <furq> especially if it's a noisy sensor
[22:47:34 CEST] <kerio> furq: just -crf 0 brah
[22:47:36 CEST] <kerio> :^)
[22:47:36 CEST] <furq> ofc
[22:47:46 CEST] <furq> that doesn't work with h264_omx though so your joke is ruined
[22:47:50 CEST] <furq> rip
[22:47:51 CEST] <kerio> rip
[22:48:20 CEST] <djk> ok going to give this a try on the test setup.
[22:48:34 CEST] <kerio> would a playstation 2 eyetoy work as a usb v4l2 camera
[22:52:09 CEST] <djk> This is the camera low cost wide field of view
[22:52:09 CEST] <djk> https://www.amazon.com/gp/product/B0080CE5M4
[22:52:10 CEST] <furq> there's only one way to find out
[22:52:27 CEST] <kerio> furq: yea but like
[22:52:37 CEST] <kerio> my pi0 is in the living room
[22:52:43 CEST] <kerio> and i'm on my bed
[22:52:43 CEST] <furq> the way to find out is to google it and find out that it does work
[22:53:08 CEST] <kerio> i doubt the eyetoy will output h264 tho :<
[22:53:19 CEST] <furq> it's only 240p
[22:57:16 CEST] <djk> Unknown encoder 'h264_omx'
[22:58:29 CEST] <djk> kerio: I am using the static ffmpeg download were you thinking I would compile?
[23:04:31 CEST] <djk> guess everyone got busy
[23:09:04 CEST] <kerio> djk: i was thinking you'd use ffmpeg from the repository?
[23:09:15 CEST] <kerio> assuming you use raspbian, that is
[23:10:35 CEST] <djk> yes but the one I was a 2.x release and that wasn't working at all
[23:10:45 CEST] <djk> for rtmp
[23:22:03 CEST] <djk> and the apt install version is 2.6.9 and no h264_omx
[23:22:33 CEST] <kerio> hmm
[23:22:34 CEST] <kerio> hmmmmmmmmm
[23:25:05 CEST] <djk> maybe I have wrong repository?
[23:25:57 CEST] <djk> If you're curious this is the desktop stream on FB
[23:25:57 CEST] <djk> https://www.facebook.com/BRPCwebcam/
[23:26:16 CEST] <kerio> which static build are you using?
[23:26:42 CEST] <djk> 3.2.4
[23:26:56 CEST] <djk> I can get the nightly
[23:26:57 CEST] <kerio> no, which build
[23:27:37 CEST] <djk> https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-64bit-static.tar.xz
[23:28:25 CEST] <kerio> why isn't there a build anywhere
[23:28:27 CEST] <kerio> jesus
[23:28:41 CEST] <kerio> is there some license restriction regarding the openmax stuff
[23:28:42 CEST] <kerio> ?
[23:29:00 CEST] <BtbN> it's just new
[23:29:17 CEST] <kerio> so everyone just uses johnvansickle's build?
[23:29:26 CEST] <BtbN> isn't that amd64?
[23:29:37 CEST] <djk> oops
[23:29:39 CEST] <kerio> he's got a bunch of architectures
[23:30:14 CEST] <djk> https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-armhf-32bit-static.tar.xz
[23:37:51 CEST] <djk> giving this a try
[23:37:51 CEST] <djk> https://www.reddit.com/r/raspberry_pi/comments/5677qw/hardware_accelerated_x264_encoding_with_ffmpeg/
[23:38:41 CEST] <furq> kerio: omx doesn't work with -static
[23:38:46 CEST] <kerio> D:
[23:38:48 CEST] <furq> same as nvenc and qsv (?)
[23:38:52 CEST] <kerio> well i mean
[23:39:04 CEST] <kerio> i don't necessarily want a static build
[23:39:07 CEST] <kerio> just a build
[23:39:36 CEST] <furq> djk: the guy who wrote that doesn't even know the difference between x264 and h264
[23:39:40 CEST] <furq> and also is generally wrong
[23:39:43 CEST] <furq> and is on reddit
[23:40:03 CEST] <djk> yeah reddit
[23:40:09 CEST] <kerio> well, "git clone" and "./configure --help" will likely tell you all you need
[23:40:15 CEST] <furq> actually it's not that bad
[23:40:22 CEST] <furq> i like how much he's clearly edited this post though
[23:40:29 CEST] <furq> the preamble and the actual post don't match up at all
[23:40:33 CEST] <furq> presumably because people yelled at him
[23:40:59 CEST] <furq> you don't need most of that shit he's telling you to get from apt
[23:41:28 CEST] <djk> well it is compiling will see
[23:41:40 CEST] <furq> all you need is build-essential and pkg-config
[23:41:56 CEST] <furq> and maybe libasound2-dev if you want microphone audio
[23:42:27 CEST] <furq> the rest of it looks passable
[23:42:32 CEST] <furq> it's much faster to cross-compile though
[23:45:54 CEST] <djk> not done a cross-compile lots of learning curving going here ;-)
[23:48:28 CEST] <djk> I really appreciate the patience and help guys
[23:52:28 CEST] <ZexaronS> hello
[23:52:45 CEST] <ZexaronS> is it possible to extract part of a TS file without remuxing?
[23:53:07 CEST] <ZexaronS> Basically just lowering the size, because I need to extract a bit-exact sample for debu
[23:53:10 CEST] <ZexaronS> debug*
[23:53:25 CEST] <ZexaronS> video is some 40 mins long, i need only last minute
[23:53:49 CEST] <furq> you should be able to cut ts at any point and it'll survive
[23:53:52 CEST] <furq> use dd or something
[23:54:10 CEST] <furq> or tail should work
[23:54:15 CEST] <ZexaronS> I'm on windows
[23:54:18 CEST] <furq> oh
[23:54:32 CEST] <kerio> install WSL
[23:54:36 CEST] <kerio> use dd or tail
[23:54:40 CEST] <furq> well yeah ffmpeg can't do anything like that
[23:55:11 CEST] <ZexaronS> Well I just wanted to make sure here first before I go hex editing
[23:55:32 CEST] <furq> just grab gnuwin32 or something
[23:55:41 CEST] <furq> that's much less hassle than wsl/cygwin/msys
[23:56:03 CEST] <ZexaronS> I can turn on my secondary (super old and slow PC) linux mint here, but if I can do it in windows in some 10 minutes it wouldn't be worth transferring the multi-gb file over
[23:56:04 CEST] <furq> http://gnuwin32.sourceforge.net/packages/coreutils.htm
[23:56:59 CEST] <furq> tail -c 1048576 foo.ts
[23:57:04 CEST] <furq> will give you the last 1MB
[23:57:26 CEST] <furq> in other news, i found the bsp leak
[23:57:29 CEST] <furq> hooray for me
[23:57:33 CEST] <CFS-MP3> is to possible to autodetect + crop black bars in one pass? (I mean, not using cropdetect first to get values and then crop to actually do the work. I'd need to do this in a live stream
[23:57:36 CEST] <thebombzen> furq: installing git on windows gives you msys and bash
[23:57:41 CEST] <thebombzen> so that's the easist way to do it
[23:57:59 CEST] <furq> nothing involving msys is easy
[23:58:10 CEST] <thebombzen> well, I just went to git-scm and downloaded an installer and ran it
[23:58:20 CEST] <thebombzen> and now I can use bash intead of cmd
[23:58:30 CEST] <thebombzen> so you tell me if that's easy
[23:58:44 CEST] <furq> to run one command once?
[23:59:17 CEST] <thebombzen> yea, it's overkill, but it's still easy.
[23:59:31 CEST] <furq> i disagree and i will fight you to the death
[23:59:38 CEST] <furq> my opinion will be the best one
[23:59:41 CEST] <thebombzen> lol
[00:00:00 CEST] --- Sat Apr 15 2017