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

[burek]

[00:00:04 CEST] <hanna> JEEB: oh joy
[00:00:04 CEST] <JEEB> https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-2-2017-PDF-E.pdf
[00:00:19 CEST] <JEEB> "High dynamic range television for production and international programme exchange"
[00:01:52 CEST] <hanna> https://0x0.st/UY2.png yeah herp
[00:01:56 CEST] <hanna> this is exactly what I was talking about
[00:02:02 CEST] <hanna> outdoor scenes in movies now hurt my eyes just like outdoor scenes in real life
[00:02:55 CEST] <alexpigment> jeeb: "Of these, we will only address the first one here." , nice going on that Common Misconceptions section ;)
[00:03:09 CEST] <JEEB> :D
[00:03:18 CEST] <hanna> JEEB: honestly I'm liking what I'm reading in this report
[00:03:22 CEST] <hanna> may even convince me not to do a blog article on HDR
[00:03:24 CEST] <JEEB> anyways, I just happened to notice that spec
[00:03:25 CEST] <hanna> and just link to that report instead
[00:03:29 CEST] <JEEB> completely randomly
[00:03:52 CEST] <JEEB> part 6 is all about HLG it seems
[00:04:34 CEST] <alexpigment> hanna: if you have a blog that focuses on this sort of thing, feel free to PM me the link. I'm always interested in reading about video technology
[00:04:44 CEST] <hanna> also good diagram of what tone mapping is about https://0x0.st/UY_.png
[00:05:01 CEST] <hanna> alexpigment: not really, I just randomly post shit whenever I feel like it and not all of it has to do with video stuff
[00:05:12 CEST] <alexpigment> ah
[00:07:53 CEST] <hanna> https://0x0.st/UY9.png interesting
[00:08:17 CEST] <hanna> reminds me of the tone mapping curve I came up with
[00:09:06 CEST] <hanna> https://camo.githubusercontent.com/ac457c2ff89d541bf365aa1294ab4aad3be364ef/68747470733a2f2f3078302e73742f49314f2e706e67 (green curve is the one we use in mpv now)
[00:11:12 CEST] <komanda> iive: you don't put your local /etc/passwd in the video, you make an avi that when transcoded to mp4 will open the servers /etc/passwd and put that in the mp4
[00:12:12 CEST] <komanda> i need out server to support transcoding m3u8 to mp4 but want to disallow it from opening local filesystem files
[00:12:58 CEST] <iive> komanda: i really hope you've read the .py file and you are sure that it does what you say it does.
[00:15:08 CEST] <komanda> iive: i tried it in a sandboxed docker container and it does work, for any local file, not just /etc/passwd
[00:15:27 CEST] <JEEB> yes but did you check it does what you think it does?
[00:15:41 CEST] <komanda> iive: the container I made the exploit avi didn't even have the file that was in the output mp4
[00:15:56 CEST] <JEEB> as far as I can tell with http://git.videolan.org/?p=ffmpeg.git;a=commit;h=189ff4219644532bdfa7bab28dfedaee4d6d4021 the HLS decoder checks files for extension
[00:16:06 CEST] <JEEB> local files that is
[00:16:29 CEST] <BtbN> make sure you are actually testing with the latest ffmpeg
[00:16:55 CEST] <JEEB> komanda: also you can build your FFmpeg without the file protocol altogether
[00:17:06 CEST] <JEEB> and most likely other ways are there as well
[00:23:05 CEST] <iive> JEEB: are m3u8 handled by hls code?
[00:23:18 CEST] <JEEB> those that are actual HLS playlists, yes
[00:24:19 CEST] <hanna> hmm
[00:24:20 CEST] <iive> and if you give them raw text m3u8?
[00:24:37 CEST] <JEEB> what?
[00:24:44 CEST] <JEEB> HLS playlists /are/ raw text m3u8
[00:24:49 CEST] <JEEB> (´4@)
[00:25:24 CEST] <hanna> no idea if I generated these images correctly but if it worked, then https://0x0.st/UYV.jpg is what mpv does out of the box (assume 1000 cd/m² display, tone map down to 1.0) and https://0x0.st/UYW.jpg is what I get when I plug the parameters of an SDR display into the HLG ootf (results in gamma 0.78, peak = 1.0)
[00:25:27 CEST] <iive> i mean, if you give the list as local text file.
[00:25:37 CEST] <hanna> keeping in mind both are tone-mapped to my display
[00:25:54 CEST] <JEEB> iive: local HLS playback is something often done which is why I guess http://git.videolan.org/?p=ffmpeg.git;a=commit;h=189ff4219644532bdfa7bab28dfedaee4d6d4021 was done
[00:26:25 CEST] <JEEB> since originally it just had `if (!av_strstart(proto_name, "http", NULL) && !av_strstart(proto_name, "file", NULL))` there
[00:27:53 CEST] <hanna> here is mpv with hable tone mapping instead of mobius https://0x0.st/UY4.jpg
[00:28:45 CEST] <iive> JEEB: so If I give ffmpeg a local file with extension .m3u8, it will parse it with the hls code,
[00:29:16 CEST] <JEEB> well, yes
[00:29:18 CEST] <hanna> and with clipping instead of tone mapping: https://0x0.st/UYJ.jpg
[00:29:33 CEST] <hanna> hard to prefer the HLG OOTF here
[00:29:45 CEST] <JEEB> iive: it probably has some checks with the probing so it at least looks like a HLS playlist though
[00:29:48 CEST] <hanna> it makes all the colors more flat, while the contrast in the other tone mapping curves is more objectively closer to ground truth (clipping)
[00:29:51 CEST] <JEEB> but that doesn't require much
[00:30:03 CEST] <iive> i ask, because i remember m3u playlist been a thing in winamp, long before i've heard abuot hls
[00:30:15 CEST] <iive> and winamp turned into video player too.
[00:30:20 CEST] <JEEB> hanna: I like it how this recommendation mentions "hey, yo, we have the CL version of BT.2020 too - which fixes these certain issues you know!"
[00:30:29 CEST] <hanna> mobius unfortunately warps the colors as it clips
[00:30:31 CEST] <hanna> hmm
[00:30:39 CEST] <hanna> this might be a good test sample to train a different tone mapping colorspace on
[00:30:46 CEST] <hanna> actually
[00:30:53 CEST] <hanna> maybe it's the =clip image that's distorting the colors
[00:31:10 CEST] <JEEB> iive: well yes it came from audio playlists and then got used by apple for other means
[00:31:25 CEST] <meriipu> if I use split on a video stream and map them to two outputs, how could I only encode audio once and copy it to the second destination?
[00:31:44 CEST] <JEEB> meriipu: ffmpeg.c doesn't let you do that as far as I know
[00:31:57 CEST] <JEEB> you have to write an API client yourself for that
[00:32:13 CEST] <JEEB> which encodes once and then pushes those coded packets to multiple muxers
[00:33:10 CEST] <meriipu> is real time audio encoding on (fairly) recent hardware to say mp3 fast enough that two streams hardly makes a difference over one?
[00:33:27 CEST] <JEEB> yes
[00:33:52 CEST] <JEEB> if you're not using something like a low-power ARM CPU you should be OK
[00:34:00 CEST] <meriipu> I suppose I can live with the non-neat but simple way for now then. Thanks.
[00:35:58 CEST] <hanna> this is =mobius before the XYZ patch: https://0x0.st/UYx.jpg
[00:36:17 CEST] <hanna> and this is =clip before the XYZ patch: https://0x0.st/UY3.jpg
[00:37:38 CEST] <hanna> skin color doesn't seem to be significantly affected
[00:37:56 CEST] <hanna> but the color of all the reds changes, hmm
[00:39:41 CEST] <hanna> anyway what this image tells me is that mpv tone mapping still needs to be improved by a *lot*
[00:39:49 CEST] <hanna> but unfortunately, tone mapping in a way that doesn't distort colors is extremely tricky
[00:40:02 CEST] <hanna> you can do the tone mapping on the luma channel instead of per-RGB but that result in a weird flatness to the image
[00:40:08 CEST] <hanna> as colors also need to be desaturated
[00:40:12 CEST] <hanna> in order to fit again
[00:41:24 CEST] <durandal_1707> JEEB: you can encode once mux many with ffmpeg
[00:41:32 CEST] <JEEB> oh
[00:41:41 CEST] <hanna> what you could do is e.g. do tone mapping in LCh: 1. tone map lightness, 2. compute relative size of the chromaticity plane at that brightness, 3. tone map the saturation component according to this
[00:41:43 CEST] <JEEB> without piping?
[00:41:59 CEST] <hanna> but I can never figure out how to actually do clipping in LCh except by trial and error
[00:42:31 CEST] <durandal_1707> JEEB: there is somewhere in muxers docs
[00:42:39 CEST] <hanna> I think what we ought to do is move this into the 3DLUT and do it offline with high quality tone mapping algorithms
[00:42:42 CEST] <JEEB> oh right, the tee muxer_
[00:42:46 CEST] <JEEB> that thing existed :P
[00:48:01 CEST] <hanna> https://0x0.st/UYl.jpg this is what I get if I tone-map on the luma channel only
[00:48:38 CEST] <hanna> actually I think I prefer that
[00:48:41 CEST] <hanna> it's way closer to ground truth
[00:48:46 CEST] <hanna> and basically just nukes specular detail completely
[00:48:57 CEST] <hanna> I think the flatness I was complaining about was the fact that tone mapping this way removes specular highlights
[00:49:00 CEST] <hanna> instead of distorting them
[00:49:28 CEST] <hanna> so yeah let's do it this way
[02:18:34 CEST] <hiihiii> can I tell ffmpeg to half the framerate using fps filter without actually describing any number?
[02:19:03 CEST] <hiihiii> if the input is 60fps I don't want to say -vf "fps=30"
[02:19:14 CEST] <nicolas17> what's a good lossless format to store my original data? currently I have a folder with tens of thousands of JPEG files and it's unmanageable
[02:19:44 CEST] <nicolas17> it's too big, and since it's one file per frame I don't get filesystem readahead
[02:20:27 CEST] <nicolas17> the latter could be solved by packing it into a single video file with MJPEG codec using -vcodec copy, but that will still be too big :p
[02:20:50 CEST] <nicolas17> it's ~2MB/frame
[02:23:59 CEST] <hiihiii> lossless means you'll still get a big output whatever codec you use
[02:24:08 CEST] <nicolas17> sure
[02:25:03 CEST] <hiihiii> try lib256 with -crf 0
[02:26:12 CEST] <nicolas17> I'd love to do this on some VPS with fast SSD storage, but it will take me 15 days to upload it :P
[02:26:54 CEST] <hiihiii> if your frames are "generic" in nature and/or have a lot of similarities then maybe you'll get a good compression
[02:27:40 CEST] <nicolas17> probably
[02:27:44 CEST] <nicolas17> this was like a security camera
[02:28:22 CEST] <nicolas17> (GoPro fixed to the ceiling doing timelapse)
[02:28:57 CEST] <furq> you probably won't get any smaller than mjpeg
[02:29:04 CEST] <furq> unless most frames are identical
[02:29:51 CEST] <hiihiii> if it's a security camera then you'd probably be ok
[02:29:55 CEST] <furq> flv1 and x264 lossless are probably your best choices
[02:30:05 CEST] <furq> and most security cameras have a lot of sensor noise which will screw that up
[02:30:28 CEST] <furq> not to mention the jpeg compression artifacts
[02:30:41 CEST] <nicolas17> furq: it was a GoPro HERO (I think first gen), just saying it was fixed in the room in a similar way to a security camera
[02:30:42 CEST] <furq> i guess try it with a short sample first
[02:31:06 CEST] <furq> probably depends on the lighting then
[02:31:29 CEST] <furq> either way try it with 1000 frames or so and see if you get passable results
[02:31:55 CEST] <furq> either -c:v libx264 -qp 0 -preset veryslow or -c:v ffv1
[02:32:12 CEST] <hiihiii> why not libx265?
[02:32:22 CEST] <nicolas17> I'm trying x264 with crf 0 now
[02:32:28 CEST] <furq> shrug
[02:32:31 CEST] <furq> i've never used x265 lossless
[02:32:35 CEST] <nicolas17> it's eating my laptop CPU :D
[02:32:36 CEST] <furq> i assume it'll be incredibly slow
[02:32:36 CEST] <hiihiii> I understand the playback issues but still
[02:32:52 CEST] <furq> and i have no idea if it's noticeably better than x264
[02:33:21 CEST] <furq> nicolas17: you can use a faster preset if x264 is too slow
[02:33:25 CEST] <furq> obviously that'll compress worse
[02:33:58 CEST] <hiihiii> well lossless x264 will probably be ok with his input. I'm guessing the entropy is good even with noise
[02:34:27 CEST] <furq> if it's a gopro in good light then it should be fine
[02:34:51 CEST] <furq> really bad grain/noise will destroy any chance of compressing it further
[02:37:16 CEST] <hiihiii> btw is there a way to use fps filter such that it halfs the framerate without knowing the source's fps?
[02:41:19 CEST] <nicolas17> 217M    vid-copy-2s.mkv (-vcodec copy, ie. mjpeg)
[02:41:21 CEST] <nicolas17> 222M    vid-x264-crf0-2s.mkv
[02:41:23 CEST] <nicolas17> 185M    vid-ffv1-2s.mkv
[02:41:59 CEST] <hiihiii> try x265
[02:43:35 CEST] <meriipu> I am not really sure how I can fit encoding of audio into this (so that it is encoded twice, once for each output) https://bpaste.net/show/8986832214d9
[02:46:31 CEST] <nicolas17> damn, x265 takes seconds per frame
[02:47:54 CEST] <grublet> Yeah totally not worth it IMO
[02:51:37 CEST] <nicolas17> 127M    vid-x265-crf0-2s.mkv
[02:51:51 CEST] <nicolas17> but the encode went at 0.4fps
[02:53:46 CEST] <furq> try with x264 -preset veryslow
[03:39:47 CEST] <eric__> Is there documentation somewhere about aevalsrc expressions? The fancy filtering example (https://trac.ffmpeg.org/wiki/FancyFilteringExamples#aevalsrc) is helpful, but I'm unfamiliar what language it is written in. Any help?
[03:44:41 CEST] <furq> http://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation
[03:44:53 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#aevalsrc
[03:45:52 CEST] <utack> didn't the last moscow university test determine x265 is better than x264, even when faster?
[03:45:58 CEST] <eric__> @furq Thank you!
[03:46:04 CEST] <furq> utack: link
[03:46:21 CEST] <utack> this one http://compression.ru/video/codec_comparison/hevc_2016/
[03:46:21 CEST] <furq> last benchmark i saw was rbultje's benchmark which showed x265 was worse at the same speed as x264 veryslow
[03:46:27 CEST] <furq> that's from late 2015 though
[03:46:36 CEST] <utack> fig 33
[03:46:51 CEST] <furq> http://compression.ru/video/codec_comparison/hevc_2016/figures/videos.png
[03:46:57 CEST] <furq> this looks like it'll be an easy article to follow
[03:46:59 CEST] <utack> yeah unfortunately, but unlikely it got worse?
[03:47:12 CEST] <utack> this one http://compression.ru/video/codec_comparison/hevc_2016/figures/graph3.png
[03:48:18 CEST] <utack> now of course the measurement for quality...always debatable i know
[03:48:25 CEST] <furq> Overall, the leaders in this comparison are Intel MSS HEVC and Kingsoft HEVC encoders!
[03:48:28 CEST] <furq> uh
[03:48:36 CEST] <furq> i take it these are commercial because i've never heard of them
[03:48:52 CEST] <furq> also wtf are nj264 and nj265
[03:50:31 CEST] <furq> literally the only reference i can find to nj264 is this comparison
[03:55:08 CEST] <Syl20> Hi, I'm trying to compile ffmpeg with --enable-decklink option, can someone help me please ?
[04:08:58 CEST] <utack> furq seems to be some patched version https://mirror.tuna.tsinghua.edu.cn/solus/unstable/x/x264/
[04:16:35 CEST] <myke> what's the sanest way to use a gif for a stream?  -loop doesn't work on gifs and converting the gif to a video and then looping it with -stream_loop doesn't quite work right either
[04:17:17 CEST] <furq> -ignore_loop 0 -i foo.gif
[04:19:36 CEST] <myke> holy cow i did not find that on stack overflow or anywhere, thanks
[04:19:40 CEST] <myke> exactly what i wanted
[04:30:04 CEST] <m1a0yu3> Hi, Does anyone know how to disable ffmpeg from grabbing local files in m3u8 format?
[05:11:10 CEST] <Syl20> Hi, I'm trying to compile ffmpeg with --enable-decklink option, can someone help me please ?
[06:21:46 CEST] <androclu`> furq, you out there?
[06:26:06 CEST] <thebombzen> kerio: it's called colorlevels but I don't know how to do it automatically
[06:29:42 CEST] <androclu`> i am getting errors from ffmpeg, ever since upgrading to debian 9 (stretch).
[06:30:04 CEST] <androclu`> both from repo version and static.
[06:30:19 CEST] <androclu`> so i went a 3rd route and compiled my own
[06:30:22 CEST] <androclu`> that breaks too
[06:30:32 CEST] <nicolas17> define "breaks"
[06:30:55 CEST] <androclu`> this time i compiled with debugging symbols
[06:30:56 CEST] <androclu`> the output is here https://bpaste.net/show/8c30dd176628
[06:31:30 CEST] <androclu`> i guess the debugging symbols give more info. without these, i was just getting seg-faults, and no info at all
[06:31:53 CEST] <androclu`> while we speak, i am re-running same command, but inside gdb.. i suppose i should have something come up shortly
[06:32:06 CEST] <nicolas17> you'd have to run it under gdb and get a backtrace
[06:32:57 CEST] <androclu`> okay. that info at bottom not helpful, eh?
[06:33:57 CEST] <nicolas17> "illegal instruction" does look somewhat suspicious; what CPU do you have?
[06:35:25 CEST] <androclu`> 8-core Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz .. have /proc/cpu if u need it..
[06:36:33 CEST] <androclu`> possible i have a cpu going bad (one of the 8)?
[06:36:49 CEST] <androclu`> (although i am not experiencing any other problems..)
[06:37:08 CEST] <nicolas17> does it fail always at the same point?
[06:38:12 CEST] <androclu`> well, i can't say i know because that output is the first one i captured that had any helpful info
[06:38:31 CEST] <androclu`> is the "0x55fdf56319c0" the address it fails at?
[06:38:54 CEST] <nicolas17> well if it once failed very shortly after you started the encoding, and another time it failed after several minutes of processing, then you know it's not deterministic :)
[06:39:18 CEST] <androclu`> yes, well *that* much i can confirm. sometimes 2 minutes in.. sometimes 15.. etc
[06:39:47 CEST] <nicolas17> hmmm then it does have a chance of being a hardware issue
[06:39:56 CEST] <androclu`> grrrr...
[06:40:10 CEST] <nicolas17> it's not certain, it absolutely could be something else
[06:40:16 CEST] <androclu`> hrmm...
[06:41:35 CEST] <androclu`> do you know of any linux (or other) utilities for checking hardware?
[06:41:58 CEST] <nicolas17> linux distros usually put memtest86 in the boot menu
[06:42:03 CEST] <nicolas17> that would check RAM
[06:42:05 CEST] <androclu`> yes..
[06:42:08 CEST] <androclu`> and cores?
[06:43:23 CEST] <androclu`> i see one out there called, 'cpuburn'
[06:43:49 CEST] <nicolas17> I knew of that one, but I couldn't find it...
[06:43:54 CEST] <nicolas17> I'm in debian testing, maybe they removed it
[06:48:37 CEST] <goppo> hi
[06:48:42 CEST] <goppo> is there a way to specify the output dir?
[06:49:47 CEST] <goppo> my current command looks like ffmpeg -i rtsp://admin@192.168.1.104/user=admin_channel=1_stream=0.sdp -acodec aac -strict -2 -vcodec copy -f segment -segment_time 1800 -segment_format mpegts -strftime 1 "%Y-%m-%d_%H-%M.mpeg"
[06:50:14 CEST] <nicolas17> uh, "path/to/dir/%Y-%m-%d_%H-%M.mpeg"?
[06:50:45 CEST] <goppo> oh!
[06:50:50 CEST] <goppo> lol
[06:50:51 CEST] <goppo> thanks
[06:54:11 CEST] <androclu`> nicolas17: yeah, same. but debian does have stress-ng and psensor
[06:54:32 CEST] <androclu`> nicolas17: maybe cpuburn was only compiled for ubuntu :(
[06:55:05 CEST] <nicolas17> looks like cpuburn is old
[06:55:18 CEST] <nicolas17> and not optimized for modern CPUs
[06:56:10 CEST] <androclu`> i'm fine with that :P .. stress-ng is working, and apparently there is also phoronix-test-suite
[06:56:37 CEST] <androclu`> i suppose i shall have to play with them a bit to figure out how to stress each core separately
[06:56:52 CEST] <androclu`> psensor, however, does say 0RPM for my cpu fan
[06:58:22 CEST] <nicolas17> peek inside your computer and see if it's spinning or not :P
[07:02:12 CEST] <androclu`> nicolas17: yeah, there are actually 2 big fans on either side of it -- both spinning
[07:17:44 CEST] <Fenrirthviti> Hmm, anyone familiar with NVENC limitations? What's the max framerate it will encode at 1080p?
[07:29:42 CEST] <androclu`> nicolas17: bingo
[07:30:19 CEST] <nicolas17> CPU caught fire?
[07:30:31 CEST] <androclu`> heheh..
[07:30:39 CEST] <androclu`> at this point, i almost sort of wish it would
[07:31:02 CEST] <androclu`> oh, crap. this is my first time reading gdb output. i guess it actually finished! crud
[07:31:13 CEST] <androclu`> "[Inferior 1 (process 810) exited normally]"
[07:31:46 CEST] <nicolas17> bah
[07:31:55 CEST] <androclu`> agreed
[07:32:08 CEST] <androclu`> "when the mechanic is looking, the car works"
[07:36:36 CEST] <androclu`> nicolas17: i have to call it a day.  but i'll run it again overnight without gdb. the only thing i did differently (besides run it through gdb) was that i took the top off the case.  maybe running just a tad cooler was what it needed (crossing fingers).
[07:37:22 CEST] <androclu`> nicolas17: and the guy i bought this comp. from 2 years ago did say he overclocked the cpus.  maybe there is just something a tad different in this new kernel for stretch that manages temps or cores a little differently?
[07:38:01 CEST] <androclu`> nicolas17: anyway, thx for your ideas and support.. i'll find out in the morning if it barfed.
[08:13:06 CEST] <Kirito> https://a.uguu.se/eg1r0OJrDXbx_dopus_2017-06-27_02-08-16.png two versions of the same clip encoded with the same settings at constant framerates. Only difference is one was exported from Adobe Premiere at 30fps with optical flow interpolation and one at 60fps with the same. Somehow the 60fps version apparently compresses better. That is.. weird o_O.
[08:59:02 CEST] <kerio> thebombzen: ye colorlevels worked
[08:59:06 CEST] <kerio> with manually specified limits
[08:59:18 CEST] <kerio> which probably make sense, cuz otherwise the effect would be quite jarring
[08:59:37 CEST] <thebombzen> yea, you have to do it manually. doing it frame-by-frame would be wrong (duh) but I was hoping it could autodetect it based on the first frame
[08:59:43 CEST] <thebombzen> or an average of the first frame
[08:59:49 CEST] <thebombzen> first few frames
[09:00:31 CEST] <kerio> well no i mean i kinda want that i guess
[09:00:34 CEST] <kerio> because of reasons
[09:00:35 CEST] <thebombzen> also I think it's probably better to increase the precision to 16-bit before doing colorlevels, then you can deband and reduce to 10-bit before encoding
[09:00:44 CEST] <kerio> this is 16 bit already
[09:01:04 CEST] <thebombzen> alright good. Something you can do is dump the first frame and open it with an image editor like GIMP, and pick "autolevels" and see what values it comes up with
[09:02:04 CEST] <kerio> does colorlevels adjust values linearly
[09:02:09 CEST] <kerio> because this ain't really rgb
[09:03:22 CEST] <thebombzen> well it's in float
[09:03:36 CEST] <thebombzen> so the depth doesn't affect the input values
[09:03:51 CEST] <thebombzen> but given that colorlevels affects rgb, I assume you'd have to convert it to rgb first to make it work well
[09:03:58 CEST] <thebombzen> like zscale,format=gbrp16le
[09:04:40 CEST] <kerio> no i mean that's fine i guess
[09:05:07 CEST] <kerio> but are the values adjusted linearly between imin/imax and omin/omax?
[09:05:14 CEST] <kerio> or does it use some other relation
[09:05:36 CEST] <thebombzen> yea, it's linear as long as the gray point is 1.0
[09:05:39 CEST] <kerio> rgb is supposed to have output levels proportional to the square root of the actual value
[09:06:00 CEST] <thebombzen> I believe it's quadratic if you set the gray point
[09:06:16 CEST] <thebombzen> the gray point is the gamma. if you set it to 1 then it's linear. the color curves tell this to you
[09:06:19 CEST] <kerio> but colorlevels doesn't have a gray point D:
[09:06:51 CEST] <thebombzen> then it will be linear
[09:06:52 CEST] <kerio> but yea
[09:06:54 CEST] <kerio> coeff = (omax - omin) / (double)(imax - imin);
[09:07:00 CEST] <kerio> dst[x + offset] = av_clip_uint8((src[x + offset] - imin) * coeff + omin);
[09:07:16 CEST] <thebombzen> ah yep, it's linear
[09:07:39 CEST] <thebombzen> I wish there was a filter like detectlevels
[09:07:55 CEST] <thebombzen> -vf colorlevelsdetect that just works like cropdetect
[09:08:09 CEST] <thebombzen> best used with -frames:v 1
[09:08:18 CEST] <kerio> i should probably use a real colorizer actually
[09:08:23 CEST] <thebombzen> probably
[09:08:28 CEST] <kerio> with output that's perceptually uniform
[09:08:39 CEST] <kerio> but eh, pretty cool
[09:13:44 CEST] <thebombzen> kerio: I do know about the square root thing but I was under the impression that modern imaging technology knew that
[09:13:50 CEST] <thebombzen> like photoshop and GIMP both accounted for tha
[09:33:33 CEST] <Gertm> Having trouble hardcoding subs. When doing it with files where the subs are SSA, it works fine, but not with srt subs. This is what I've tried: https://pastebin.com/JnMrpg3D
[09:33:42 CEST] <Gertm> Does anyone have experience with that?
[09:38:49 CEST] <thebombzen> Gertm: try ffmpeg -i input.mkv -vf subtitles=input.mkv output.mkv
[09:39:08 CEST] <thebombzen> of course, set the encoding options, and you probably don't want to map the subtitle stream.
[09:39:14 CEST] <Gertm> thebombzen: Did that, didn't work.
[09:39:23 CEST] <thebombzen> what does "didn't work" mean
[09:39:29 CEST] <Gertm> Yet with ass subs, it does work.
[09:39:39 CEST] <Gertm> thebombzen: THe video output does not have the subs on it.
[09:39:50 CEST] <Gertm> They have not been hardcoded onto the video.
[09:39:54 CEST] <thebombzen> did you try -vf subtitles=subs.srt
[09:39:59 CEST] <thebombzen> after extracting the subrip stream
[09:40:23 CEST] <thebombzen> ffmpeg -i input.mkv -map s -c copy subtitles.srt
[09:40:33 CEST] <thebombzen> ffmpeg -i input.mkv -vf subtitles=subtitles.srt
[09:41:04 CEST] <Gertm> The pastebin entry has all the different commands I tried.
[09:41:17 CEST] <Gertm> That one was one of them.
[09:41:19 CEST] <thebombzen> well the pastebin entry has "-s"
[09:41:22 CEST] <thebombzen> which is not an option
[09:41:33 CEST] <thebombzen> so I assume you modified it and then I elected to ignore it
[09:42:02 CEST] <Gertm> I will go over it again.
[09:42:14 CEST] <thebombzen> why don't you try the command I suggested without using -ss and -t and then saying the one I suggested doesn't work
[09:42:23 CEST] <thebombzen> when you didn't try it, you tried something approximately equal
[09:42:48 CEST] <thebombzen> for the record, -ss can mess up the subtitles filter because it relies on the timestamp of the frames being sent to it
[09:43:23 CEST] <thebombzen> if you use ffmeg -ss 1:00 -i input.mkv -vf subtitles then it'll put the subtitles at the beginning of the stream, they will be off by one minute, because the subtitles being passed to the subtitles filter start at a timestamp of 0
[09:43:31 CEST] <Gertm> Aha
[09:43:41 CEST] <thebombzen> so keep that in mind
[09:43:50 CEST] <Gertm> I'll try it on the full file without cutting. I was cutting it to speed up the encoding times.
[09:44:02 CEST] <thebombzen> You can cut it, you just need to also offset the timestamp of the input
[09:44:23 CEST] <thebombzen> something like ffmpeg -ss 2:00 -copyts -start_at_zero -i input.mkv
[09:45:11 CEST] <thebombzen> if you do that, then the video frames passed to the filterchain will start at two minutes rather than 0. However, you will need to append setpts=PTS-STARTPTS to the filterchain so the final video has it start at zero and not two minutes
[09:47:17 CEST] <Gertm> Ok, let me parse all that info and try again.
[09:48:31 CEST] <Gertm> This is what I have now: ffmpeg -y -i input.mkv -c:v h264 -crf 18 -c:a copy -map 0:0 -map 0:1 -vf subtitles=subs.srt output.mkv
[09:48:50 CEST] <Gertm> I extracted the srt files with mkvextract.
[09:48:57 CEST] <Gertm> This didn't result in the subs being hardcoded.
[09:50:09 CEST] <Gertm> I do get fontconfig errors, but it says it'll use the fallback.
[09:50:48 CEST] <Gertm> Could it go wrong because ffmpeg can't find the correct font to use?
[10:20:40 CEST] <thebombzen> Gertm: post the complete output
[10:21:38 CEST] <Gertm> Hold on, I screwed up my fonts in general. Mixed up the symlink config from linux.
[10:21:50 CEST] <Gertm> I think my windows fonts are screwed now, lemme fix this first. :)
[10:21:59 CEST] <thebombzen> symlinks technically work on windows nowadays but lots of stuff hates them
[10:22:20 CEST] <Gertm> Oh yeah, even windows itself.
[10:30:14 CEST] <Gertm> thebombzen: https://pastebin.com/CjX3g56P  Obviously something with my font config is screwed up.
[10:32:24 CEST] <thebombzen> Hm
[10:32:31 CEST] <thebombzen> what build of ffmpeg is this?
[10:32:48 CEST] <thebombzen> cause the Zeranoe builds link in fontconfig, freetype, and fribidi
[10:33:04 CEST] <Gertm> Hmm probably installed through chocolatey
[10:33:20 CEST] <Gertm> I'll replace it with the zeranoe builds if that'll fix it.
[10:33:48 CEST] <thebombzen> yea, let's see. the command you entered looks like it works, although I'd replace -c:v h264 with -c:v libx264
[10:34:00 CEST] <thebombzen> I think it's chosen that way by default but it's good to be unambiguous about which h.264 encoder you want
[10:34:22 CEST] <thebombzen> otherwise it'll autoselect that one, or h264_qsv or something
[10:36:27 CEST] <Gertm> Ok I'll change that now.
[10:37:17 CEST] <Gertm> Ok the zeranoe build doesn't start, it's complaining about libsnappy. I downloaded the wrong thing probably. Lemme try again.
[10:42:23 CEST] <Gertm> thebombzen: I was using the 3.3.1 build from zeranoe it seems. I switched to a working version of the nightlies (20170620) and now it works. The subs have been hardcoded.
[10:42:26 CEST] <Gertm> Thanks for your help!
[10:44:35 CEST] <thebombzen> you're welcome
[10:44:45 CEST] <thebombzen> in this case it was just a font issue. figures. FOONNNNNTSS
[10:45:11 CEST] <Gertm> Still, without you asking the right questions, I wouldn't have been able to solve it.
[10:45:43 CEST] <dongs> how the hell do I trim stuff with ffmpeg BETWEEN two timestamps. a basic freaking feature --ss 00:10:00 -to 00:20:00 i expect resulting file to be 10 seconds, not 20 or 30 or wahtever teh shit it ended up being
[10:45:56 CEST] <dongs> -to needs claculating minus offset, -t needs length calculation
[10:46:04 CEST] <dongs> i just want to take 2 timestamps in media player and trim between them
[10:52:01 CEST] <dongs> anyone?!
[10:52:54 CEST] <thebombzen> dongs: it's 5 a.m. in US Eastern, be patient
[10:53:02 CEST] <thebombzen> to answer your question, -to does not work the way you think it does
[10:53:10 CEST] <thebombzen> or it doesn't work the way it seems like it should
[10:53:16 CEST] <dongs> well, no kidding
[10:53:36 CEST] <dongs> i dont want to do h:m:s calculations for -t or -to
[10:53:37 CEST] <thebombzen> the reason being that -ss not only seeks to a particular time but it also shifts all the video timestamps to the left by that time, which makes sense
[10:54:12 CEST] <thebombzen> so if you use -ss 10:00, it starts the video at 0, so if you use -ss 10:00 -to 20:00, it stops encoding at the 20:00 timestamp.... which is inconveniently 20 minutes after the start of the video
[10:54:27 CEST] <dongs> correct.
[10:54:39 CEST] <dongs> i know the problem and the cause, waht im trying to figure out is a solution for hte lazy (like me)
[10:55:07 CEST] <dongs> also for some reason just muxing is pretty slow in general
[10:55:16 CEST] <dongs> im working on a SSD, trimming a ~40gb hevc .ts file
[10:55:20 CEST] <dongs> and its only doing like 40meg/sec
[10:55:33 CEST] <dongs> surely it should be way faster than that just doing stream copy
[10:55:34 CEST] <thebombzen> so there's two solutions I can think of
[10:56:00 CEST] <thebombzen> one is to be disappointed and convert all your timestamps into seconds, and do the subtraction yourself
[10:56:06 CEST] <thebombzen> you can do this with awk
[10:56:49 CEST] <dongs> that... isnt gonna work :p
[10:56:51 CEST] <dongs> next choice?
[10:56:53 CEST] <thebombzen> why not?
[10:57:17 CEST] <thebombzen> is there any particular reason you are intentionally avoiding it?
[10:57:52 CEST] <dongs> -ss 00:04:11 -i trash.ts -to 02:27:33
[10:58:00 CEST] <dongs> because convertting this to seconds is super fucking annoying
[10:58:06 CEST] <thebombzen> not if you're using a script
[10:58:17 CEST] <dongs> surely theres gotta be a better way
[10:58:20 CEST] <thebombzen> awk -F: '{ n = 1; for (i = NF; i > 0; i--) { out = $i * n + out; n = n * 60 } print out }'
[10:58:24 CEST] <thebombzen> this for example does it
[10:58:27 CEST] <dongs> yeah i dont have awk.exe
[10:58:48 CEST] <thebombzen> ah, on windows.
[10:59:00 CEST] <thebombzen> also, you should not really be seeking mpegts files
[10:59:12 CEST] <thebombzen> mpegts seeking is not guaranteed to work. it might, but you should not expect it to
[10:59:32 CEST] <thebombzen> but anyway, try this:
[10:59:49 CEST] <thebombzen> ffmpeg -i trash.ts -c copy temp1.mkv
[10:59:57 CEST] <thebombzen> just to get it out of mpegts
[11:00:42 CEST] <dongs> 40 gigs at 30meg/sec jsut to change container type?
[11:00:52 CEST] <dongs> the whole reason I'm chatting here is cuz im trying to avoid having to re-trim this thing again
[11:00:55 CEST] <dongs> :)
[11:01:22 CEST] <dongs> ts seeking works fine btw thats all i ever worked with
[11:01:31 CEST] <thebombzen> Well mpegts is not easily seekable, unless you want to decode, but okay.
[11:01:47 CEST] <dongs> what? you dont need to decode to seek in it
[11:01:52 CEST] <dongs> there's PTS
[11:01:59 CEST] <thebombzen> you do if you want to seek mpegts reliably
[11:02:09 CEST] <thebombzen> because mpegts is not a seekable container by design
[11:02:28 CEST] <thebombzen> however, you seem to have two conflicting issues here
[11:02:39 CEST] <dongs> start trim worked just fine
[11:02:42 CEST] <dongs> (and it alawys has)
[11:02:56 CEST] <thebombzen> 1. You (for some reason) are very very resistant to just calculating the duration of the output in seconds
[11:03:04 CEST] <dongs> its hard to do man
[11:03:07 CEST] <thebombzen> No it's not
[11:03:21 CEST] <thebombzen> 2. You are trying to avoid disk reads/writes
[11:03:42 CEST] <thebombzen> unfortunately, what you want to do is hard
[11:03:52 CEST] <thebombzen> to actually answer your question, you have two options
[11:04:03 CEST] <thebombzen> 1. suck it up and push the calculator button
[11:04:48 CEST] <thebombzen> 2. ffmpeg -ss start_timecode -copyts -start_at_zero -i input.ts -to end_timecode out.ts
[11:05:08 CEST] <thebombzen> make sure you set the codec options as well
[11:05:30 CEST] <thebombzen> however, out.ts will have a start timecode that is not zero
[11:05:46 CEST] <thebombzen> which only works because it's mpegts, and some players might still reject it
[11:06:06 CEST] <thebombzen> if you want it to not do that, you'll need to process the video afterward with a setpts filter
[11:07:28 CEST] <thebombzen> alternatively, you can do ffmpeg -ss start_timecode -copyts -start_at_zero -i input.ts -vf 'trim=end=end_timecode,setpts=PTS-STARTPTS' codec_options out.ts
[11:07:50 CEST] <thebombzen> dongs: ^ this here works, but takes more time to type than just using -t and subtracting
[11:09:14 CEST] <nahsi> I need to generate a sample clip from a movie which will consist of random parts of it preferably not so random (ie some scenes with motion, some dark scenes, some scenes with low contrast etc) so I can then encode this clip with different settings and see a difference. How can I do that? I was not able to generate a search query for google sorry
[11:10:20 CEST] <thebombzen> well if you're looking for particular scenes with certain properties, you probably have to find the time of them manually
[11:11:27 CEST] <thebombzen> there is no filter to automatically generate a short representative set of scenes of a movie
[11:11:32 CEST] <thebombzen> you just have to do that one by hand
[11:13:03 CEST] <nahsi> thebombzen: thanks a lot
[11:17:34 CEST] <dongs> thebombzen: end_timecop and pts-startpts are the start/end timestamps?
[11:17:39 CEST] <dongs> err end_timecode lu
[11:17:44 CEST] <thebombzen> in seconds yea
[11:17:47 CEST] <dongs> .. ins econds
[11:17:49 CEST] <thebombzen> or in time duration
[11:17:50 CEST] <dongs> that doesnt solve anything at all
[11:17:52 CEST] <dongs> oh
[11:18:05 CEST] <thebombzen> I meant not actually in PTS units
[11:18:08 CEST] <thebombzen> or in timebase units
[11:18:11 CEST] <dongs> 00:04:11 -i trash.ts -to 02:27:33
[11:18:14 CEST] <dongs> are you saying i can use these
[11:18:15 CEST] <dongs> and it will wokr?
[11:18:29 CEST] <thebombzen> well if you're going from 4 minutes 11 seconds to 2 hours 27 minutes 33 seconds? yes
[11:18:33 CEST] <dongs> yes
[11:19:38 CEST] <dongs> what is PTS-STARTPTS is that atuallty 00:04:11 or some kinda keyword
[11:19:52 CEST] <dongs> no looks like keyword
[11:20:50 CEST] <dongs> Filtergraph ''trim=end=02:27:33,setpts=PTS-STARTPTS'' was defined for video output stream 0:0 but codec copy was selected.
[11:20:54 CEST] <dongs> Filtering and streamcopy cannot be used together.
[11:25:14 CEST] <thebombzen> you need to escape the \s
[11:25:17 CEST] <thebombzen> er escape the :s
[11:25:30 CEST] <dongs> whaT?
[11:25:48 CEST] <thebombzen> the filtergraph uses : to separate  arguments to a filter
[11:26:00 CEST] <thebombzen> in this case end=02:27:33 is the argument
[11:26:13 CEST] <thebombzen> otherwise end=02 will be passed as one argument, 27 will be passed as the second, and 33 will be the third
[11:26:15 CEST] <thebombzen> you don't want that
[11:26:30 CEST] <dongs> wtf
[11:26:31 CEST] <thebombzen> also, you can't use codec copy with filters. You need to re-encode the video
[11:26:39 CEST] <dongs> latest "static" zeranoa builds are asking for libsnappy or some other shit
[11:26:44 CEST] <dongs> and i just deleted whatever old exes I had
[11:26:46 CEST] <dongs> fuuuuu
[11:26:53 CEST] <thebombzen> They shouldn't
[11:26:55 CEST] <dongs> they are
[11:27:05 CEST] <dongs> The program can't start because libvidstab.dll is missing from your computer. Try reinstalling the program to fix this problem.
[11:27:13 CEST] <dongs> and libsnappy.dll
[11:28:03 CEST] <dongs> well if i need to reencode this whole thing is useless, thats waht I dont wanna do
[11:28:15 CEST] <thebombzen> that's not ordinary, so it's probably just a bug in the build
[11:28:34 CEST] <dongs> I jsut realized, i downloaded some nightly bullshit
[11:28:35 CEST] <thebombzen> well if you don't want to re-encode then you won't get accurate timestamps
[11:28:38 CEST] <dongs> deleting it
[11:28:46 CEST] <thebombzen> nightly is not "bullshit"
[11:28:51 CEST] <thebombzen> it master is the most stable verion of FFmpeg
[11:28:54 CEST] <dongs> of course it is, it doesnt even work :)
[11:29:05 CEST] <thebombzen> that's not an issue with Zeranoe, not FFmpeg
[11:29:15 CEST] <dongs> the 1st not isnt needed
[11:29:37 CEST] <thebombzen> yes congrants you recognized the intent through my typo
[11:29:46 CEST] <thebombzen> either way, you don't want to re-encode which means the timecodes won't be perfect
[11:29:49 CEST] <thebombzen> are you okay with that?
[11:30:04 CEST] <dongs> i dont want them perfect, regular -c copy trim works fine if only the fucking timestamps didnt need calculation
[11:30:33 CEST] <thebombzen> dongs: you realize that if you had pulled up your calculator, you'd have solved this already, right?
[11:30:38 CEST] <dongs> for sure
[11:30:41 CEST] <dongs> but i want a permanent solution
[11:30:50 CEST] <dongs> this is something i have to do enough times for it to get annoying
[11:31:05 CEST] <dongs> and I always have ONLY start/end timestamps
[11:31:10 CEST] <dongs> not duration or other bullshit.
[11:31:31 CEST] <thebombzen> well you could write a script. but either way, try this:
[11:31:32 CEST] <dongs> i suppose if there was a webshit i can type in 2 hms timestamps and get a hms duration that would work but even thats more work than just typing nubmers in
[11:32:20 CEST] <thebombzen> ffmpeg -ss 4:11 -copyts -start_at_zero -i input.ts -to 02:27:33 -c copy -f mpegts - | ffmpeg -f mpegts -i - -c copy output.ts
[11:32:52 CEST] <thebombzen> the purpose of the second ffmpeg is to sanitize the timestamps so the output file doesn't have timestampsstarting at 4:11 but rather at 0
[11:33:46 CEST] <thebombzen> keep in mind, it takes more time to type this command out than it does to pull up a calculator and do the arithmetic
[11:33:53 CEST] <dongs> not to me
[11:34:17 CEST] <dongs> i wonder if i can skip the second one. pts doesnt need to start at zero in mpegts, infact it rarely does in captures anyway
[11:35:29 CEST] <dongs> stream copy speed decreased...
[11:35:35 CEST] <dongs> with new build vs ~last year
[11:35:59 CEST] <thebombzen> that's because you're running two ffmpeg processes that are also doing it
[11:36:04 CEST] <thebombzen> also streamcopy speed is extremely fast
[11:36:07 CEST] <dongs> no i skipped the second one
[11:36:09 CEST] <thebombzen> that should not really be an issue
[11:36:19 CEST] <dongs> thebombzen: then why is it only going at 30meg/sec
[11:36:34 CEST] <thebombzen> didn't you just say that was your hard drive read speed
[11:37:36 CEST] <dongs> http://bcas.tv/paste/results/rAUtwz32.html
[11:37:37 CEST] <dongs> thats not what i said
[11:39:14 CEST] <dongs> i can copy a file off same ssd to nas, while its trimming, and it will saturate gbit link (110meg/sec around). so its not the read OR the write speed
[11:39:48 CEST] <dongs> neways tryimg to trim without 2nd ffmpeg, see what happens
[11:42:33 CEST] <dongs> ok
[11:42:35 CEST] <dongs> thebombzen: this works
[11:43:02 CEST] <dongs> ffmpeg -ss 00:04:11 -copyts -start_at_zero -i fail.ts -to 02:27:33 -c copy trim.ts
[11:46:16 CEST] <thebombzen> alright
[11:46:30 CEST] <dongs> i dont mind that pts doesnt start at zero, like i said, it never does in ts anyway
[12:10:30 CEST] <modestpharaoh> hi, Is there a way to update quicktime metadata (com.apple.quicktime.location.name & com.apple.quicktime.location.date) that specified here https://developer.apple.com/library/content/documentation/QuickTime/QTFF/Metadata/Metadata.html  using ffmpeg
[14:46:37 CEST] <meriipu> is there a sane limit to how high I should set thread_queue_size for audio? I have raised it to 4096 and still get warnings about considering raising it
[15:11:57 CEST] <DHE> audio is probably fine to skyrocket. just make sure you're not actually CPU-bound in your encoding.
[15:17:29 CEST] <atomnuker> meriipu: using alsa? its probably alsa.
[15:25:27 CEST] <meriipu_> oh it actually ended up using 100% memory somehow completely locking compoop
[15:30:57 CEST] <__deivid__> Hi. I think I talked to you before DHE, about my servers reaching ~75% cpu usage
[15:31:51 CEST] <__deivid__> I have 4 servers with CPU E5-2640 v4 (20 cores, 40 threads)
[15:32:44 CEST] <__deivid__> Running 9 ffmpeg instances, each with 4 threads for the video transcode and (I guess?) 1 for the audio transcode. My problem is that the cpu usage is like 75%
[15:33:53 CEST] <BtbN> doesn't seem overly unexpected?
[15:33:56 CEST] <iive> well, you might be hitting bottleneck somewhere else. like HDD read/write speed
[15:34:22 CEST] <iive> or even getting short on RAM.
[15:34:26 CEST] <__deivid__> I'm reading/writing to ram
[15:34:31 CEST] <__deivid__> nah. I have 64gb
[15:34:44 CEST] <__deivid__> and pci-e ssds
[15:35:03 CEST] <__deivid__> (These are not my servers, a guy hired me to transcode, a fuckton of videos)
[15:35:15 CEST] <__deivid__> http://i.imgur.com/zLpyc2I.png
[15:36:01 CEST] <iive> well, each instance could easily eat 2-4GB, and if the files are few GB eatch...
[15:37:00 CEST] <__deivid__> That's what the load looks like. Running 8,9 or 10 jobs shows the same load with average cpu usage (user) ~75%
[15:38:09 CEST] <BtbN> Just overcommit a bit
[15:38:24 CEST] <BtbN> ffmpeg/x264 will never fully use all its threads to 100%
[15:39:28 CEST] <Threads> isnt it best to just have it set to 0 so it cant set the threads its self.
[15:39:35 CEST] <Threads> cant = can
[15:39:53 CEST] <__deivid__> Maybe, but then how many jobs should I run?
[15:40:11 CEST] <BtbN> If you want one job to use all it can get and use, yes
[15:40:11 CEST] <__deivid__> I have a central queue and all servers pick up jobs and start transcoding
[15:40:20 CEST] <BtbN> but for multiple things in parallel, limiting might be a good idea
[15:42:54 CEST] <__deivid__> `perf` shows 49% libavcodec, 30% libx264, 13% libswscale
[15:44:22 CEST] <iive> does avcodec use automatically threading for decoding?
[15:46:07 CEST] <__deivid__> My videoflags are -vf scale=-2:720 -profile:v high -level 4.0 -pix_fmt yuv420p -threads:v 4
[15:47:23 CEST] <iive> yes, but are these threads for the encoder or the decoder?
[15:47:59 CEST] <iive> e.g. profile, level are encoder options
[15:48:14 CEST] <kepstin> since you haven't specified any other options, I guess that means x264 is using the defaults, which iirc are -preset medium -crf 23. If you want it to use more cpu, you can try a slower preset :)
[15:48:18 CEST] <DHE> BtbN: the "concern" is that, on my own similar system, 92% seems like a sort of total CPU limit. Adding more jobs (not disk bottlenecked) doesn't raise overall CPU usage any
[15:48:39 CEST] <__deivid__> preset is 'veryfast' right now for some quality/speed testing
[15:49:26 CEST] <kepstin> using faster presets, veryfast in particular, limits the amount of multithreading x264 can do.
[15:49:29 CEST] <iive> if you are still doing testing, try decoding the files, to raw encoder and pipe the output to /dev/null
[15:49:46 CEST] <iive> this should test your reading and decoding speed.
[15:50:23 CEST] <__deivid__> I have to transcode like 14k hours so testing more stuff is always worth
[15:50:33 CEST] <kepstin> you could also play around with cpu affinities, assigning each encoder some dedicated cores, might help if the issue is scheduling related.
[15:50:54 CEST] <DHE> I tried it with preset 'slow' and 1080p output. no love
[15:51:17 CEST] <DHE> <Threads> isnt it best to just have it set to 0 so it can set the threads its self.  # you'd think so, but when you hit 40 threads (80 if you're dual socket) this becomes a bad idea.
[15:52:23 CEST] <kepstin> also note that the same crf with different presets will give slightly different quality, so if you're checking quality you should use the preset you're actually going to be using.
[15:52:36 CEST] <kepstin> the difference is usually fairly minor, tho.
[16:15:09 CEST] <fin-ger> Hi, I'm currently trying to create a tiled video from 4 video files (with audio). The videos should be arranged in a grid (2x2). Additionally one audio file should be mixed into the output video. I want to adjust the volume of each audio stream separately. This is what I've got: https://dpaste.de/UXcR Currently ffmpeg hangs when rendering has nearly finished (a couple of seconds are missing in the output file). What is wrong with my filter?
[16:24:39 CEST] <__deivid__> kepstin: I just set the affinity to all process to dedicated cores and it's the same
[16:27:20 CEST] <__deivid__> kepstin: `perf` changed from 49% libavcodec, 30% libx264 to 40%, 40%
[16:30:27 CEST] <kepstin> so when you look at the cpu usage in 'top', you are actually seeing some significant percentage idle ('id')?
[16:31:16 CEST] <kepstin> and there's no/minimal time spend in io wait ('wa')?
[16:33:22 CEST] <__deivid__> 45.0 user,  4.0 system, 15.9 nice, 34.0 idle,  0.5 wait
[16:33:33 CEST] <__deivid__> yup
[16:33:59 CEST] <__deivid__> idle in general is ~25 instead of 34
[16:34:16 CEST] <__deivid__> I have a 48hour average cpu usage on 75%
[16:37:24 CEST] <meriipu> I have been searching around but I have not really found much of a solution to warnings of the sort [libfdk_aac @ 0x121fb60] Queue input is backward in time/on-monotonous DTS in output stream 0:1   it gets printed a lot of times for the first few seconds of my ffmpeg instantiation and then seems to stop
[16:38:06 CEST] <meriipu> they might not be related but they were printed together a lot
[16:53:20 CEST] <fin-ger> anybody?
[17:08:43 CEST] <fin-ger> I think my issue is related to inputs of unequal length... But I don't know how to fix this.
[17:09:41 CEST] <__deivid__> fin-ger: that's your problem. You can use -shortest I think so the output file will end when the first input ends
[17:11:45 CEST] <tezogmix> On some devices that can't handle 59-60fps, I've been converting them to 1/2 of their fps (e.g. -r 30000/1001) and same resolution scale (mostly 1080p, 8000+ bitrate and using -crf 15, fast/veryfast preset). Is there a command I can add to compensate for some of the visually lost effects of the downgrade in fps? I've been looking at the "-tune film"
[17:12:18 CEST] <tezogmix> The content is live/action.
[17:12:46 CEST] <fin-ger> __deivid__: Hmm -shortest does not change anything
[17:13:28 CEST] <__deivid__> it's an output option, are you using it correctly?
[17:13:46 CEST] <__deivid__> I remember having the same issue a while back and I fixed it with -shortest
[17:14:50 CEST] <fin-ger> __deivid__: I added it after the `-i` input parameters (my command line: https://dpaste.de/UXcR)
[17:16:06 CEST] <__deivid__> try before $6 ? I think it should work anyway, maybe there's a weird interaction between filter-complex and shortest
[17:16:31 CEST] <tezogmix> I'm not sure if there's a filter that could be used.... live/action example: animals moving around at the zoo
[17:16:53 CEST] <__deivid__> https://ffmpeg.org/ffmpeg-filters.html#Examples-9
[17:16:55 CEST] <kepstin> tezogmix: converting to ½fps basically means dropping every other frame, there's no way to retain smoothness of motion when doing that.
[17:16:59 CEST] <__deivid__> check that example
[17:17:53 CEST] <tezogmix> ah hey kepstin , that's the word I was looking for "smoothness" - yeah, it's quite noticeable with the 1/2fps... didn't know if there was something I could add to the command line to possibly make up for that.
[17:17:59 CEST] <kepstin> tezogmix: there's some things you can do to e.g. blend the dropped frames into the kept frames, which can sometimes look like motion blur.
[17:18:12 CEST] <kepstin> but in general, if you want smoothness, you need more frames per second.
[17:18:20 CEST] <kepstin> that's it, really...
[17:18:35 CEST] <__deivid__> fin-ger https://stackoverflow.com/questions/33330279/ffmpeg-selects-shortest-movie-but-leaves-full-length-audio
[17:19:09 CEST] <kepstin> tezogmix: if your devices support 1080i at 60 fields/s, you might consider doing an interlaced encode to tradeoff spatial resolution for temporal.
[17:20:08 CEST] <tezogmix> cool kepstin , I'll have to try both of your suggestions, is it a string we can just add to the executed ffmpeg command?
[17:20:39 CEST] <fin-ger> __deivid__: It is still hanging...
[17:21:02 CEST] <tezogmix> I meant, independently to test and inserted before the output file name....
[17:21:08 CEST] <kepstin> tezogmix: only consider the interlaced option if you know your playback devices have reasonable support for deinterlacing (e.g. you're outputting to aTV or something)
[17:21:43 CEST] <tezogmix> yes will need to check on the specifics on the latter kepstin -
[17:23:05 CEST] <tezogmix> kepstin, googling real quick, is it "blend or tblend" ?
[17:23:54 CEST] <tezogmix> https://www.ffmpeg.org/ffmpeg-filters.html#blend_002c-tblend
[17:27:37 CEST] <fin-ger> __deivid__: This is what I got now: https://dpaste.de/BVv5 All inputs are ~16sec long. ffmpeg stops at ~time=00:00:15.87 The (so far) written output file is ~9 seconds long when played with vlc
[17:28:35 CEST] <__deivid__> try adding shortest=1 to the overlay filters
[17:28:38 CEST] <__deivid__> https://ffmpeg.org/ffmpeg-filters.html#overlay-1
[17:29:25 CEST] <kepstin> tezogmix: hmm, I don't actually know how to get ffmpeg to blend frames in the way I was thinking of. The 'framerate' filter won't do it with an simple multiple like ½.
[17:31:00 CEST] <tezogmix> ah ok kepstin appreciate the remarks to simply be aware of... just in awe with how much is under the hood with possibilities in using ffmpeg... much respect to all who work on the project :)
[17:31:01 CEST] <kepstin> you might be able to do with with tblend, try "-vf tblend=all_mode=average,fps=30000/1001" or so. The result will probably be very blurry
[17:31:34 CEST] <fin-ger> __deivid__: Now it hangs with the messages: `[Parsed_overlay_18 @ 0xafe680] [framesync @ 0xb03428] Sync level 1` where this message appears for Parsed_overlay_16, Parsed_overlay_17 and Parsed_overlay_18
[17:32:15 CEST] <kepstin> (and the tblend idea won't handle scene cuts well, so it'll generally look pretty bad)
[17:32:30 CEST] <__deivid__> fin-ger I don't know. Maybe someone else can help you. When I tried to do some weird stuff with ffmpeg eventually I gave up and used gstreamer
[17:33:02 CEST] <fin-ger> __deivid__: Ok ^^ thank you for your help :)
[17:34:44 CEST] <tezogmix> I see kepstin , it seems the effort may not be worth the implementation... most of the considerations were on older android OS tablets.
[17:35:21 CEST] <kepstin> tezogmix: you'd probably be better off encoding a 720p60 rather than 1080p30 or 1080i60, to be honest.
[17:35:24 CEST] <tezogmix> for now, all the earlier tips and suggestions you've all shared over the months with me have been working alright in those regards...
[17:36:15 CEST] <tezogmix> 720p60 works well I know for a fact.
[17:36:25 CEST] <tezogmix> Hmm, good point...
[17:37:02 CEST] <kepstin> that said, if you want to try 1080i60 for some reason, adding "-vf interlace -flags ildct" should do it with the x264 encoder. Might be worthwhile to test it and see whether it looks better/worse than 720p60 on your target devices.
[17:37:33 CEST] <kepstin> assuming the devices have ok deinterlacing, it'll probably look better on static or nearly static scenes, and worse on motion than 720p60
[17:38:28 CEST] <alexpigment> maybe i'm out of the loop, but I just sort of assumed that mobile chips didn't do any sort of deinterlacing (at least at the OS level)
[17:38:41 CEST] <alexpigment> (again, I'm probably out of the loop)
[17:38:46 CEST] <kepstin> if your target is mobile then yeah, skip the interlaced video.
[17:39:14 CEST] <kepstin> if you're targetting something with tv playback it *might* be worth considering (but interlaced video is annoying to work with even then)
[17:39:32 CEST] <tezogmix> so cool kepstin, thanks for the suggested options to try and test... with -vf interlase + vf scale function on the latter to 720p...
[17:40:18 CEST] <tezogmix> is the -vf interlace a markedly time intensive process that I should be expecting?
[17:40:22 CEST] <alexpigment> not to hijack, but I've always done both ilme and ildct flags. is there no reason to specify -flags ilme anymore?
[17:41:13 CEST] <alexpigment> -vf interlace does slow the process down
[17:41:17 CEST] <tezogmix> i'll have to check the tegra 3 nividia details alexpigment , i know it can play some 1080p60 but it really depends on the source
[17:41:40 CEST] <alexpigment> tezogmix: i presume you mean 1080i60, right?
[17:42:27 CEST] <kepstin> alexpigment: the x264 encoder driver checks the ildct flag (and only that flag) to determine whether to tell the x264 encoder to do interlaced encoding.
[17:43:06 CEST] <alexpigment> but does the motion estimation benefit from ilme?
[17:43:36 CEST] <DHE> doesn't matter. there's only one setting that matters and kepstin already explained that
[17:44:02 CEST] <alexpigment> ok, well I guess I can stop specifying that from now on
[17:44:14 CEST] <tezogmix> no alexpigment, i haven't ever looked into 1080i60 point...
[17:44:23 CEST] <kepstin> alexpigment: the flag name is actually meaningless, it's just turned into "please do interlaced encoding however you feel like" to the x264 encoder.
[17:44:41 CEST] <alexpigment> kepstin: ah, thanks for the clarification
[17:44:49 CEST] <tezogmix> the tegra 3 nvidia definitely can't handle 2160/4k
[17:45:00 CEST] <tezogmix> and so i've had to vf scale those
[17:45:31 CEST] <kepstin> for mobile devices that aren't capable of decoding 1080p60, the screen is probably small enough that people wouldn't notice a 720p downscale anyways.
[17:45:34 CEST] <tezogmix> i'm not sure of the newer android processors and gpu's...
[17:46:06 CEST] Action: kepstin finds it ridiculous that his phone can take 4k video, but only has a 720p screen ;)
[17:46:41 CEST] <alexpigment> kepstin: would you trade battery life for being able to view the full number of pixels on such a small device?
[17:46:54 CEST] <tezogmix> hehe, yeah... the tablets from 7-10" do vary on how noticeable it could be... but all goes to how the source/bitrate is...
[17:47:02 CEST] <alexpigment> kepstin: if i had to take a side here, i'd go with 720p screen every time
[17:47:20 CEST] <tezogmix> why's that alexpigment ?
[17:47:31 CEST] <alexpigment> tezogmix: i don't like charging things every day
[17:47:38 CEST] <tezogmix> oh right,
[17:48:06 CEST] <alexpigment> i surely couldn't see anything close to 4k at a normal distance from my phone
[17:48:13 CEST] <kepstin> alexpigment: heh, yeah, even the 720p screen is still >300ppi on my 4.6" phone, which is plenty high enough.
[17:48:25 CEST] <tezogmix> i was specifically about non-mobile (i.e. tablets with 7-10" screens)
[17:48:56 CEST] <tezogmix> on mobile of 4-6", I can't tell a difference...
[17:49:50 CEST] <tezogmix> unfortunately, there aren't too many higher end android specs on tablets nowadays and i don't think i'd ever spend more than $300-400 on one...
[17:49:51 CEST] <alexpigment> yeah, i was really just responding to kepstin's (presumably not that serious) comment
[17:50:09 CEST] <tezogmix> ah it's ok :)
[17:50:30 CEST] <alexpigment> but i also don't get the point of tablets at all, so I'm going to just play the "old man" card
[17:50:34 CEST] <kepstin> on a 7" device with a 1080p screen (the original nexus 7 only had 1280x800...) you'd probably only notice a 720p encode if the video contains a lot of text overlays, or if you had a magnifying glass
[17:52:20 CEST] <kepstin> dropping the framerate to 30fps would certainly be more noticable than reducing the video resolution.
[17:52:47 CEST] <alexpigment> kepstin: yes, 100%. which is why i hate streaming video compared to broadcast TV
[17:53:03 CEST] <alexpigment> i'd like to highlight your comment in gold and show it to major companies
[17:53:07 CEST] <tezogmix> ah yes... the nexus line was great, sad that they stopped... the nvidia shield k1 or something to that model was a notable successor.... not sure about the samsung lines but they're much more costly... my interest was for standalone/offline portable playback via USB-otg + external hdd's in a tablet form and there are a few good android media apps which do the job.
[17:55:44 CEST] <tezogmix> what would you like to emphasize to those companies alexpigment ?
[17:56:09 CEST] <alexpigment> tezogmix: that dropping the framerate to 30fps is very noticeable
[17:56:27 CEST] <alexpigment> from a few feet away, you can't tell the difference between 1080p and 720p
[17:56:47 CEST] <alexpigment> but you can notice the difference between 60p and 30p, or 60i and 30p from any distance
[17:57:13 CEST] <tezogmix> yeah, plus the bitrates too I would imagine....
[17:57:19 CEST] <alexpigment> and yet most streaming video online, or even paid TV streaming services (DirecTV, Hulu, etc) just drop everything to 30p
[17:57:30 CEST] <tezogmix> what does netflix do nowadays?
[17:57:35 CEST] <tezogmix> and amazon
[17:57:37 CEST] <alexpigment> the thing is, the bitrate requirements between 30p and 60p or 60i is not that big
[17:57:57 CEST] <kepstin> tezogmix: most content on netflix/amazon is cinematic (or cinematically-styled), which usually means 24fps.
[17:57:59 CEST] <tezogmix> I have amazon prime but rarely use their streaming....
[17:58:05 CEST] <alexpigment> netflix i think caps out at 30fps for 1080p conent i believe. at least on my apple tv
[17:58:35 CEST] <alexpigment> but yeah, it's awful seeing something you *know* was recorded in 60i and watching it in 1080p24
[17:58:36 CEST] <tezogmix> i was thinking of picking up an android box (e.g. roku)
[17:58:53 CEST] <tezogmix> for the netflix service...
[17:59:09 CEST] <kepstin> they have some TV shows that were probably recorded (not "filmed") at 60i, and I'd expect they're mostly deinterlaced 30p for streaming :/
[17:59:10 CEST] <tezogmix> i can't stream on my main computer since i'm on vpn all the time
[17:59:14 CEST] <kepstin> but I haven't checked
[17:59:15 CEST] <alexpigment> tezogmix: if I knew for a fact that a modern Roku and *any* streaming service streamed in 1080p60, I would buy one today
[17:59:19 CEST] <tezogmix> and netflix has blocked all that...
[17:59:37 CEST] <alexpigment> kepstin: yes, I mean "filmed" in the loosest sense obviously :)
[18:00:02 CEST] <tezogmix> i'm not sure alexpigment , i haven't checked the newer roku iterations , apparently there's 4k support but to what degree it is, don't know offhand.
[18:00:04 CEST] <kepstin> yeah, most shows that are "filmed" are probably native 24fps.
[18:00:30 CEST] <tezogmix> has anyone had any good experience with the netflix 4k/uhd content?
[18:00:33 CEST] <alexpigment> yeah, I just don't watch many dramas or anything. most things I watch are definitely recorded in 60i
[18:01:04 CEST] <alexpigment> tezogmix: i haven't tried it
[18:01:59 CEST] <kepstin> I'm kinda sad that so much content is still recorded at 1080i60 rather than progressive, if only because of using older/cheaper equipment.
[18:02:13 CEST] <alexpigment> kepstin: well i think you can blame atsc for that
[18:02:18 CEST] <alexpigment> or broadcast standards in general
[18:02:49 CEST] <alexpigment> it's easier to justify keeping old equipment when you know that it's going to be broadcast in the same format you're shooting in
[18:03:13 CEST] <alexpigment> if the companies had to deinterlace everything though, they'd probably find the budget for upgrading :)
[18:03:58 CEST] <alexpigment> but still, 1080i = 1080p for static parts of a frame
[18:04:12 CEST] <alexpigment> i certainly can't tell the difference between the two from my couch
[18:04:38 CEST] <alexpigment> (or probably from my monitor, for that matter)
[18:13:12 CEST] <rsilvapt> Hi!, I'm using FFmpeg on Debian 8 to stream an online radio with a single image as a video to Facebook. However, after some hours of work, FFmpeg just stops working. Here is the command: ffmpeg -loop 1 -i live.jpg -i http://server.example.com -r 1 -acodec aac -strict experimental -b:a 128k -b:v 256k -minrate 128k -maxrate 512k -bufsize 768k -f flv -metadata:s:a:0 title="Here is the title" 'rtmp://rtmp-api.facebook.com:80/rtmp/xxxxxxxxxx
[18:13:12 CEST] <rsilvapt> xxxxxxxxxxxxxxxxxxxxxxx'
[18:14:31 CEST] <BtbN> define "a couple hours"
[18:15:31 CEST] <rsilvapt> after ~ 24hours
[18:15:55 CEST] <BtbN> probably some timestamp overflowing. But 24h seems a bit low for that.
[18:16:01 CEST] <BtbN> Just restart it every 12h or so
[18:16:30 CEST] <BtbN> also, if you still need experimental for aac, you are in bad need for an update.
[18:18:33 CEST] <rsilvapt> ok... thank you. I'll do the update right now
[19:16:00 CEST] <tezogmix> have a good rest of your day/evening all.
[19:49:42 CEST] <alexpigment> I really wish NVENC and QSV had the ability to use a quality factor *and* a maxrate
[19:50:07 CEST] <alexpigment> :(
[19:51:16 CEST] <alexpigment> You really just have to choose to a) waste bits, b) have an unpredictable bitrate
[19:54:50 CEST] <kepstin> well, if you're using a hardware encoder, you've already chosen to waste bits; I guess it's just whether you want to waste more :)
[19:56:29 CEST] <kepstin> but yeah, that sort of quality factor + maxrate kind of thing would probably make their rate control more complicated & harder to implement (i.e. bigger) on silicon
[19:59:19 CEST] <DHE> wish there was a good offload option for h264 or hevc. nvenc and qsv have the above problems. x264 opencl is minimal benefit at the risk of actually harming performance sometimes...
[20:03:15 CEST] <kepstin> i don't even think any of the hw encoders actually support a constant quality mode at all, it's just static qp or something like that?
[20:03:51 CEST] <BtbN> nvenc supposedly has it
[20:03:59 CEST] <BtbN> but I don't understand it, and nvidia didn't bother to explain
[20:04:39 CEST] <BtbN> nvenc has cqp and targetQuality
[20:04:47 CEST] <BtbN> no idea when targerQuality has any meaning
[20:08:15 CEST] <BtbN> also, rc_max_rate is universally passed to nvenc
[20:08:17 CEST] <BtbN> in all rc modes
[20:08:28 CEST] <BtbN> How much it cares about it is up to itself
[20:08:37 CEST] <kittyfoots> qq -- is there a way of making ffprobe (with -show_frames) show video sample timestamps and stuff even though it isnt able to decode them (I have a ts segment that is missing sps/pps but I want to see what the video timestamps look like)
[20:08:44 CEST] <BtbN> I'd assume you can do vbr with a maxrate and a targetQuality
[20:10:46 CEST] <kittyfoots> oh i could use show_packets instead maybe
[20:55:49 CEST] <alexpigment> kepstin: yeah, nvenc and qsv both have constant quality mode. the numbers don't correlate well to CRF, but they're there technically. -qp 24 works well for nvidia, ~19 or so is good for intel, but there is some occasionally macroblocking that i haven't figured out a way to dial out
[20:56:05 CEST] <BtbN> nothing correlates well to crf
[20:56:16 CEST] <BtbN> crf is x264 implementation specific, it's nothing standard
[20:56:39 CEST] <kepstin> crf is just (or at least originally was) simply part of how x264 calculated complexity when doing 2-pass encodes.
[20:57:28 CEST] <alexpigment> yeah, I'm just saying that the numbers don't really line up for a given level of quality, regardless of the efficiency that is inherent with CRF
[20:57:33 CEST] <alexpigment> i realize they're not the same thing at all
[20:57:50 CEST] <alexpigment> so i had to do a bunch of quality tests on my own to find good numbers
[20:57:52 CEST] <BtbN> fell free to play around with target quality and maxrate in vbr mode
[20:57:55 CEST] <user890104> hello, i am trying to use RTSP input buffering, but there's an error message saying that my build does not support pthreads (windows 7, zeranoe shared build), are there pthreads-enabled binaries available?
[20:58:11 CEST] <BtbN> pthreads is a linux/unix api
[20:58:16 CEST] <alexpigment> BtbN: I already have. I didn't find that the maxrate was respected at all
[20:58:27 CEST] <BtbN> target quality, not constant quality
[20:59:35 CEST] <user890104> BtbN: older builds seem to have it supported: https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=2&t=4837
[20:59:37 CEST] <alexpigment> -q:v?
[21:00:05 CEST] <alexpigment> i've been using qp, but maybe that's a different thing altogether
[21:00:35 CEST] <BtbN> ask nvidia what exactly it is
[21:00:44 CEST] <BtbN> they sent a patch to set it, but I never figured out what it is and how it works
[21:01:30 CEST] <alexpigment> on the phone with Jensen Huang right now... ;)
[21:01:39 CEST] <furq> zeranoe builds used to have --disable-w32threads (i.e. pthreads)
[21:01:48 CEST] <furq> i guess he changed it a while back though
[21:02:31 CEST] <user890104> furq: yes, that's exactly the problem
[21:02:45 CEST] <user890104> it broke buffered rtsp input
[21:02:50 CEST] <furq> you'll probably have to build yourself
[21:03:19 CEST] <user890104> is there an automated way to fetch all dependecies?
[21:03:41 CEST] <user890104> or this is for #ffmpeg-devel?
[21:03:42 CEST] <nicolas17> on Windows? have fun...
[21:05:35 CEST] <user890104> well, mingw64 with pacman feels like Arch a bit, so if there's a linux script, it should work with minimal (or none) modifications
[21:10:18 CEST] <BtbN> zeranoe jumps through quite some hoops to build all that stuff statically
[21:10:33 CEST] <alexpigment> BtbN: yeah, it's really hard to test thing stuff sometimes because each encoder takes non-private parameters differently. for example, I just tried -cq with nvenc and wasn't getting expected results. as it turns out, when you don't set a bitrate, it assumes 2Mbps (at least in my case). it's pretty annoying when this stuff isn't hooked up. if I was a developer, I'd take some of my freetime and whip this thing into shape so that it works more like
[21:10:33 CEST] <alexpigment> libx264 where possible
[21:10:43 CEST] <alexpigment> *test things
[21:11:13 CEST] <BtbN> if you set -cq with nvenc without further parameters, it will go into constqp mode and not care about any bitrates
[21:12:18 CEST] <alexpigment> i was doing cq + maxrate + bufsize
[21:12:35 CEST] <BtbN> set an rc mode explicitly if you are doing that kinda mixes
[21:12:41 CEST] <BtbN> otherwise results can be unexpected
[21:13:11 CEST] <alexpigment> well, cq by itself still is assuming 2mbps
[21:13:33 CEST] <BtbN> constant quality does not assume anything like that
[21:13:39 CEST] <alexpigment>  cpb: bitrate max/min/avg: 0/0/2000000 buffer size: 4000000 vbv_delay: -1
[21:13:42 CEST] <BtbN> it outputs a constant quality, not caring about the bitrate
[21:14:01 CEST] <BtbN> that's ffmpeg.c outputting some defaults. nvenc does not care
[21:14:04 CEST] <alexpigment> BtbN: I don't know what to tell you. the proof is right there
[21:14:43 CEST] <alexpigment> ok, so why does the same not apply for libx264?
[21:14:53 CEST] <BtbN> The same what?
[21:15:04 CEST] <BtbN> x264 in constant quality mode also does not care about bitrate
[21:15:26 CEST] <alexpigment> I'm not sure what I'm saying that is confusing here
[21:15:38 CEST] <BtbN> almost all of it right now.
[21:15:56 CEST] <BtbN> if you put an encoder into pure constant quality mode, that's what you'll get.
[21:16:05 CEST] <BtbN> no matter what is written in the in that case unused bitrate fields
[21:16:09 CEST] <alexpigment> what is an equivalent pure constant quality mode for libx264?
[21:16:16 CEST] <BtbN> the constant quality mode?
[21:16:40 CEST] <kepstin> alexpigment: -crf mode is roughly constant perceptual quality, -qp is also a "constant quality" mode
[21:16:40 CEST] <alexpigment> yes, i'm going to follow your directions, and then we'll see what libx264 does compared to nvenc
[21:16:45 CEST] <furq> constant quality is crf
[21:16:47 CEST] <kepstin> so there's two of them I guess
[21:16:52 CEST] <furq> constqp is constant quantiser
[21:17:04 CEST] <furq> which is sort of constant quality but not really
[21:17:29 CEST] <alexpigment> ok, so crf and cq, when set alone, do not assume any bitrates
[21:17:40 CEST] <alexpigment> the bitrates show as '0' in the command line
[21:17:56 CEST] <alexpigment> nvenc, on the other hand, shows a bitrate of 2Mbps when setting a cq and nothing else
[21:18:05 CEST] <BtbN> nvenc does not show anything
[21:18:08 CEST] <furq> 20:14:01 ( BtbN) that's ffmpeg.c outputting some defaults. nvenc does not care
[21:18:16 CEST] <nicolas17> sounds like a UI bug then
[21:18:21 CEST] <furq> probably
[21:18:34 CEST] <BtbN> ffmpeg.c has no clue about rc modes. It just outputs some pre defined fields
[21:18:47 CEST] <alexpigment> nicolas17: it's not a UI thing. setting the bitrate to zero allows it to operate as expected
[21:19:03 CEST] <BtbN> again: _WHAT_ bitrate?
[21:19:08 CEST] <BtbN> There is like 5 diffrent ones you can set
[21:19:15 CEST] <alexpigment> target
[21:19:26 CEST] <alexpigment> "average"
[21:19:38 CEST] <alexpigment> i'll repeat what I pasted above: "cpb: bitrate max/min/avg: 0/0/2000000 buffer size: 4000000 vbv_delay: -1"
[21:20:06 CEST] <nicolas17> so if you set avg to 0 instead of 2M it "works as expected"?
[21:20:12 CEST] <BtbN> That line has no meaning for nvenc at all.
[21:20:17 CEST] <furq> what does "operate as expected" mean
[21:20:20 CEST] <kepstin> alexpigment: all that says is that the encoder is setting some metadata fields to those values, it doesn't say anything about the actual video
[21:20:23 CEST] <BtbN> so avctx->bit_rate? Or avctx->rc_max_rate?
[21:20:52 CEST] <alexpigment> BtbN: -b:v is the parameter I'm talking about
[21:21:43 CEST] <BtbN> that's ignored in -rc constqp mode
[21:21:51 CEST] <alexpigment> OK, I'll try to explain this again, because I feel like this is not getting through at all
[21:21:54 CEST] <kepstin> the ffmpeg code puts the avctx->bit_rate value into the cpb info regardless of whether the nvenc settings would use the bitrate value or not.
[21:22:03 CEST] <kepstin> so that log message is irrelevant
[21:22:22 CEST] <alexpigment> -c:v h264_nvenc -cq 10 produces a file with a target bitrate of 2Mbps
[21:22:42 CEST] <alexpigment> -c:v h264_nvenc -cq 10 -b:v 0 produces a file without a target bitrate (and is much larger)
[21:22:43 CEST] <BtbN> -cq is not constqp. -qp is
[21:22:46 CEST] <BtbN> -cq is a whole other story
[21:23:18 CEST] <BtbN> The one that I don't fully understand. It's basically a target quality for vbr mode.
[21:23:20 CEST] <alexpigment> BtbN: the original message from me was "I just tried -cq with nvenc and wasn't getting expected results. as it turns out, when you don't set a bitrate, it assumes 2Mbps (at least in my case). it's pretty annoying when this stuff isn't hooked up"
[21:23:40 CEST] <BtbN> I think 2mbps is the default libavcodec sets for -b:v
[21:23:41 CEST] <alexpigment> I'm sorry you didn't catch those details, but I believe it was clear the first time
[21:23:53 CEST] <alexpigment> BtbN: then why doesn't it apply to libx264?
[21:24:03 CEST] <furq> x264 doesn't set a default bitrate
[21:24:08 CEST] <furq> the default is -crf 23
[21:24:31 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/options_table.h#L42
[21:24:34 CEST] <BtbN> that's where it comes from
[21:24:42 CEST] <BtbN> x264 default, if no parameter is given, is crf
[21:24:48 CEST] <furq> yeah
[21:24:58 CEST] <furq> it's usually a default bitrate for most codecs
[21:25:01 CEST] <furq> which is generally far too low
[21:25:14 CEST] <alexpigment> OK, so the problem here is that target bitrate mode is the default with NVENC
[21:25:24 CEST] <alexpigment> and it uses the generic target bitrate from libavcodec
[21:25:26 CEST] <BtbN> I don't see a problem here at all
[21:25:39 CEST] <furq> the problem is that you misread cq as qp
[21:25:42 CEST] <BtbN> If you use default parameters, you get defaults. They are not good quality, but they are default.
[21:25:54 CEST] <alexpigment> BtbN: if you're trying to use these emerging technologies, it makes it hard to go from libx264 to nvenc without reading the source code
[21:26:01 CEST] <furq> or maybe not
[21:26:03 CEST] <BtbN> If you use -cq, it will be in vbr mode, which is default. And indeed care about the value of -b
[21:26:17 CEST] <BtbN> nvenc and x264 are highly diffrent
[21:26:28 CEST] <BtbN> there is already a lot of magic in place to make them similar. But they just aren't.
[21:26:42 CEST] <BtbN> crf simply does not exist for nvenc, and it can't be emulated.
[21:27:26 CEST] <alexpigment> well, i'm only trying cq right now because you mentioned that maxrates will work when used with target quality, and cq is noted as the target quality
[21:27:46 CEST] <BtbN> They might. I have no idea what actually works. I never got consistent results with -cq
[21:27:49 CEST] <alexpigment> i've been using -q:v , which doesn't work with maxrates
[21:28:15 CEST] <BtbN> you mean -cq?
[21:28:22 CEST] <BtbN> sorry, qp...
[21:28:46 CEST] <alexpigment> yes, -qp (my bad)
[21:28:55 CEST] <BtbN> I think -q is some weird thing ffmpeg.c maps to -global_qualiy, with some weird factor applied.
[21:29:06 CEST] <BtbN> mpeg2 qscale stuff
[21:29:17 CEST] <The_8472> I'm trying to achieve an equivalent to ffmpeg's out%d.png output format through libavcodec. I've gotten to the point where it writes some empty png files but it doesn't generate numbered file names. So I think I'm not configuring up the output format properly. Is the multi file png output actually treated as a video codec or do I have to deal with AVPicture?
[21:29:37 CEST] <alexpigment> BtbN: one of the parameters mentions that global_quality is deprecated
[21:29:54 CEST] <BtbN> yes, in favor of qp
[21:29:58 CEST] <alexpigment> -q:v is mapped to global_quality. it says to use qp instead
[21:30:00 CEST] <alexpigment> right
[21:30:11 CEST] <furq> The_8472: out%d.png is the image2 muxer in libavformat
[21:30:11 CEST] <alexpigment> i switched from global_quality to qp when that warning started appearing
[21:30:36 CEST] <BtbN> global_quality was never intended for that purpose, I'm not sure why I used it in the first place
[21:30:48 CEST] <alexpigment> global_quality worked fine, to be honest
[21:31:10 CEST] <alexpigment> I believe it's 'global' because you're not setting the q for i, p, and b separately
[21:31:20 CEST] <alexpigment> which you can do with other encoders
[21:31:28 CEST] <BtbN> For cq you'd need something like -rc vbr_hq -cq 20 -b avg_bitrate -maxrate max_bitrate
[21:31:56 CEST] <BtbN> you totally can set the i/p/b quants independently
[21:32:20 CEST] <alexpigment> yeah, I haven't tested it with ffmpeg, just with other encoders
[21:32:34 CEST] <alexpigment> I know there's an "init" for each, but I don't know if that's the same thing
[21:32:38 CEST] <The_8472> furq, and it takes a video stream?
[21:33:03 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L562
[21:33:15 CEST] <alexpigment> I'm also not looking forward to researching the results of setting I/P/B with separate q values. sounds daunting
[21:33:22 CEST] <BtbN> the -qp initially sets all 3 of them. Then you can override the b and i ones if they are set
[21:33:37 CEST] <kepstin> The_8472: it should take a series of AVPacket as produced by the png encoder.
[21:34:04 CEST] <alexpigment> BtbN, well it's good to know that you can override just one
[21:34:27 CEST] <alexpigment> I just don't know that I have the knowledge to know when a I/P/B is being starved
[21:34:31 CEST] <BtbN> i_qfactor/i_qoffset and b_qfactor/b_qoffset are the parameters ffmpeg.c uses I think
[21:34:52 CEST] <BtbN> Which are all set to non-zero by default
[21:34:55 CEST] <alexpigment> ok, so those aren't private options
[21:34:59 CEST] <BtbN> so if not specificey, they are not all the same
[21:35:21 CEST] <The_8472> kepstin, thx. so I have to initialize a) the muxer b) the encoder c) some converter to adjust the pix format from the source, right?
[21:36:20 CEST] <alexpigment> BtbN: is there an obvious way to tell when you need to adjust the quality of an I P or B frame separately from the others?
[21:36:37 CEST] <kepstin> The_8472: more or less, yeah. Note that the 'some converter' is also provided by ffmpeg, in libswscale.
[21:36:42 CEST] <BtbN> I don't think you ever really need to.
[21:36:57 CEST] <alexpigment> Good to know
[21:37:12 CEST] <BtbN> by default it favors I frames a bit
[21:37:22 CEST] <BtbN> so you don't get too bad of a quality hit from them
[21:37:32 CEST] <BtbN> and dis-favors B frames
[21:37:48 CEST] <alexpigment> Btbn - yeah Staxrip defaults to I/P/B of 20/23/25
[21:38:30 CEST] <kepstin> the only time you're likely to notice an issue is when vbv controls cause i frames to become bitrate starved, and you get quality pulsing as the b-frames look better than i frames, but that's not really directly solvable with this mechanism
[21:38:38 CEST] <alexpigment> Their implementation of NVENC seems very thorough in general
[21:39:26 CEST] <alexpigment> kepstin: yeah, I've had to do that with MPEG-2 as I recall - good to have a refresher on what to do with the quality pulsing
[21:41:01 CEST] <nicolas17> last time I wanted to do decent mpeg2 I used tmpgenc :/
[21:42:08 CEST] <nicolas17> maybe ffmpeg's rate control improved since then
[21:42:30 CEST] <alexpigment> nicolas17: nope
[21:42:33 CEST] <alexpigment> :(
[21:42:59 CEST] <The_8472> kepstin, thx
[21:43:08 CEST] <alexpigment> some source material is fine. but some source material makes it clearly obvious that mpeg2video is bested by pretty much any other encoder
[21:45:06 CEST] <BtbN> mpeg2 is a diffrent story, as non-I frames don't recovery quality, but slowly degrade
[21:45:22 CEST] <BtbN> so you want I frames to be super crisp
[21:45:41 CEST] <BtbN> with h264 you can go without I frames forever
[21:47:02 CEST] <alexpigment> BtbN: as long as seeking isn't important, yes :)
[21:47:26 CEST] <alexpigment> usually if you're working with MPEG-2, you're doing something that requires more I frames for compatibility in my experience
[21:49:01 CEST] <nicolas17> yeah I was making DVD-Video :P
[21:50:50 CEST] <notdaniel> rebuilt our video platform in-house using ffmpeg+nvenc for encoding uploads and getting h264 output how we wanted has been a bit tricky without crf as we were used to
[21:56:26 CEST] <alexpigment> notdaniel: yep, I'm dealing with that sort of stuff at the moment. it sucks :( I'm also doing Intel QSV as well, which is actually a lot worse than NVENC
[21:56:43 CEST] <alexpigment> notdaniel: do you have any huge bitrate or file size limitations you have to work within?
[21:56:56 CEST] <alexpigment> huge = major
[21:59:50 CEST] <notdaniel> alexpigment, not explicitly, but we're a public video platform and users expect to be able to upload videos and play them back in decent quality without buffering much
[22:00:09 CEST] <alexpigment> yeah, understandable
[22:00:51 CEST] <alexpigment> I haven't tackled streaming-friendly stuff yet, but since BtbN let me know that -cq and -maxrate/bufsize will work together, it gives me hope
[22:01:16 CEST] <BtbN> for streaming you want a cbr anyway
[22:01:42 CEST] <alexpigment> BtbN: actually, that's why I like libx264's crf+maxrate mode
[22:01:42 CEST] <notdaniel> yeah it's all being served up via DASH in the end
[22:02:05 CEST] <alexpigment> but this is not HLS or Dash or anything - just basic HTML5 compatibility
[22:02:05 CEST] <BtbN> no, you want strict cbr
[22:02:07 CEST] <BtbN> not max-rate
[22:02:12 CEST] <BtbN> you also don't want it to go lower
[22:02:32 CEST] <notdaniel> we're using it 100% now on tens of thousands of videos and it seems to be okay, it was just a learning curve to understand their implementation of some of these flags and not behaving as originally expected
[22:02:39 CEST] <alexpigment> BtbN: for my purposes, crf+maxrate is superior
[22:02:56 CEST] <BtbN> So you are not using TCP?
[22:03:17 CEST] <alexpigment> just a video that's being served up (not live) through a basic HTML5 player like videojs
[22:03:37 CEST] <kepstin> notdaniel: if you're using nvenc just for speed, it probably makes sense to do a second encode with x264 later and replace the nvenc encode with it :/
[22:03:44 CEST] <kepstin> (unless it's live stuff)
[22:04:17 CEST] <notdaniel> kepstin, weve gotten nvenc to look okay, and it wasnt for speed from a user standpoint so much as for rented cpu time
[22:04:22 CEST] <BtbN> that's not what I'd call streaming.
[22:04:36 CEST] <notdaniel> so making the x264 later defeats the purpose of less cpu time
[22:05:07 CEST] <alexpigment> BtbN: I just meant web playback with bitrates that don't cause buffering
[22:05:22 CEST] <BtbN> well, that depends on the users internet speed
[22:05:30 CEST] <notdaniel> all bitrates cause buffering for the right client
[22:05:41 CEST] <alexpigment> yes, but there are expected tolerances
[22:05:52 CEST] <alexpigment> if you have a 1080p video, you don't want it to hit 30Mbps
[22:05:54 CEST] <kepstin> notdaniel: huh, so you're limited more by expenses on cpu time than expenses on bandwidth? kind of odd, but ok.
[22:06:01 CEST] <alexpigment> but 5-8Mbps is fine for most users
[22:06:29 CEST] <alexpigment> but if your video is mostly stills, you don't want to waste storage on a constant bit rate
[22:06:43 CEST] <BtbN> cbr is for streaming
[22:06:45 CEST] <BtbN> not flat files
[22:07:06 CEST] <notdaniel> that said, for x264 we set maxrate, crf, cq
[22:07:20 CEST] <alexpigment> BtbN: i agree with your statement. apologies for using "streaming" in a misleading way
[22:07:36 CEST] <notdaniel> in the end theyre fragmented with segments served up via dash
[22:07:41 CEST] <BtbN> cbr for streaming is because TCP is bad with sudden bitrate bursts
[22:07:44 CEST] <BtbN> so you don't want it to fall
[22:07:55 CEST] <BtbN> if you have a flat file, you just download the whole thing as fast as you can anyway
[22:08:14 CEST] <alexpigment> yes, i agree with this
[22:08:41 CEST] <alexpigment> I used streaming in the "YouTube" sense earlier and I think that brought on some unnecessary confusion
[22:08:45 CEST] <kepstin> with segmented video the players usually end up buffering far enough ahead anyways that tcp issues with varying rates have less effect.
[22:08:57 CEST] <kepstin> well, sometimes.
[22:09:18 CEST] <nicolas17> with segmented video you usually have multiple qualities
[22:09:45 CEST] <notdaniel> oh, using dash/hls comes with its own new hilarious issues, but obviously in general it's a much better experience
[22:09:46 CEST] <nicolas17> if the client decides it can't keep up, it picks a lower quality for the next segment it downloads
[22:10:18 CEST] <kepstin> as an aside, whoever set up the current encoders at crunchyroll didn't align the segments for different qualities, so the video jumps back or skips forwards a bit whenever the player does a quality switch
[22:10:22 CEST] <kepstin> yey :/
[22:10:25 CEST] <notdaniel> we're probably shortly removing the fallback to flat mp4s entirely
[22:10:27 CEST] <nicolas17> kepstin: eww
[22:10:46 CEST] <furq> good job animes is bad
[22:11:08 CEST] <notdaniel> especially now that you can use the same fragmented media for both hls and dash, and that you dont need to segment the files
[22:11:10 CEST] <kepstin> they used to get that right at least, seems like they broke it at some point :(
[22:12:05 CEST] <nicolas17> notdaniel: "now"? what changed to allow reusing the segments?
[22:12:09 CEST] <nicolas17> (I know almost nothing about dash)
[22:12:28 CEST] <nicolas17> I mean why was it not possible before?
[22:12:30 CEST] <notdaniel> nicolas17, hls changed to support it
[22:12:36 CEST] <nicolas17> oh, huh
[22:13:05 CEST] <notdaniel> dash and hls previously had very different requirements, both in terms of the format as well as how they were segmented
[22:13:46 CEST] <notdaniel> both of those changed, so you can serve up one mp4, properly fragmented but not split, and serve up bitrange segments to both
[22:13:54 CEST] <nicolas17> "Unlike, HLS, HDS and Smooth Streaming, DASH is codec-agnostic" ughh why are there so many options, I hadn't even heard of HDS
[22:13:56 CEST] <notdaniel> you just generate 2 manifests
[22:14:42 CEST] <notdaniel> in practice, dash is the way to go, with hls for people on specific older apple devices
[22:14:51 CEST] <notdaniel> and again it doesnt matter anymore since they are using the same media
[22:15:11 CEST] <nicolas17> does apple support dash natively now?
[22:15:15 CEST] <notdaniel> you dont have to think about it or worry about it. smooth streaming and other solutions though, whatever
[22:15:45 CEST] <nicolas17> or would you need your app (or website with HTML5 MSE) to handle DASH?
[22:16:00 CEST] <notdaniel> no dash on ios period
[22:16:30 CEST] <nicolas17> oh, no MSE on ios? :/
[22:17:00 CEST] <notdaniel> you just need MSE on the client (which is almost everyone) and the server needs to be able to serve a specific byterange of one file
[22:18:42 CEST] <notdaniel> i very very rarely see the fallbacks kicking in. dash can come with its own optimization hilarity but it's mostly well-supported
[22:35:09 CEST] <ultrav1olet> Hi, ffmpeg doesn't want to pass tune=film option to libx265 - in the log it says [libx265 @ 0xxxxxxxx] Unknown option: tune.
[22:35:42 CEST] <ultrav1olet> -tune film is ever worse - an instant error: "Unrecognized option 'tune=grain' Error splitting the argument list: Option not found"
[22:36:03 CEST] <ultrav1olet> Is this a known bug? Should I file a bug report?
[22:39:18 CEST] <thebombzen> ultrav1olet: afaik "-tune film" is not an x265 option
[22:39:34 CEST] <thebombzen> when I try to use that I get an error telling me this: Possible tunes: psnr ssim grain zerolatency fastdecode
[22:41:47 CEST] <ultrav1olet> thebombzen: the documentation disagrees with you: http://x265.readthedocs.io/en/default/presets.html
[22:42:06 CEST] <thebombzen> that's x265's binary
[22:43:28 CEST] <thebombzen> ultrav1olet: try this, what do you get? x265 --help | grep -A1 -e --tune
[22:43:46 CEST] <ultrav1olet> thebombzen: strings libx265.a  | grep grain => grain/rc-grain/no-rc-grain
[22:44:01 CEST] <thebombzen> no need to strings the static library
[22:44:07 CEST] <thebombzen> try this: x265 --help | grep -A1 -e --tune
[22:44:25 CEST] <ultrav1olet> I didn't build the binary - I only have two libraries installed
[22:44:33 CEST] <thebombzen> ultrav1olet: also the docs do not disagree with me
[22:44:36 CEST] <thebombzen> did you read them?
[22:45:06 CEST] <ultrav1olet> it's called grain, not film - right
[22:45:11 CEST] <ultrav1olet> but "tune" is there
[22:45:27 CEST] <thebombzen> when did I say it wasn't
[22:45:33 CEST] <thebombzen> http://0x0.st/UDV.png
[22:46:02 CEST] <thebombzen> I said "-tune film" is not an option
[22:46:13 CEST] <thebombzen> which it isn't
[22:46:17 CEST] <ultrav1olet> I must be stupid today
[22:46:26 CEST] <thebombzen> lol everyone has one of those days
[22:46:29 CEST] <thebombzen> but yea try -tune grain
[22:46:44 CEST] <thebombzen> it's the only psy tuning it appears that's useful. psnr and ssim are just for the objective tests.
[22:47:35 CEST] <ultrav1olet> -c:v libx265 -preset veryslow -x265-params crf=18:no-sao=1:tune=grain 265.mkv results in "[libx265 @ 0xxxxxxxx] Unknown option: tune."
[22:48:10 CEST] <thebombzen> btw, you can use -tune grain -crf 18 as x265 options
[22:48:18 CEST] <thebombzen> er, as ffmpeg options
[22:48:19 CEST] <ultrav1olet> also, the ".so" library doesn't contain "grain. So, something is not right with how libx265 gets built
[22:48:43 CEST] <thebombzen> not necessarily, "strings" is not perfect
[22:49:00 CEST] <thebombzen> try using -crf 18 -tune grain -x265-params no-sao=1
[22:49:15 CEST] <thebombzen> see if that does what you need it to
[22:50:36 CEST] <ultrav1olet> it seems like you're insisting on running x265 directly while I cannot 'cause I prefer to use x265 as ffmpeg's library
[22:51:22 CEST] <ultrav1olet> actually it worked
[22:51:25 CEST] <ultrav1olet> OMG
[22:51:34 CEST] <ultrav1olet> the order of arguments matter. FML
[22:52:44 CEST] <ultrav1olet> this works: ffmpeg -i input.mp4 -c:a null -c:v libx265 -preset veryslow -tune grain -x265-params crf=18:no-sao=1 265.mkv
[22:53:01 CEST] <ultrav1olet> this doesn't: ffmpeg -i input.mp4 -c:a null -c:v libx265 -preset veryslow -x265-params crf=18:no-sao=1 -tune grain 265.mkv
[22:53:14 CEST] <nicolas17> o.o
[22:53:30 CEST] <ultrav1olet> Is this an expected behaviour? ;-)
[22:54:33 CEST] <thebombzen> and no I wasn't I meant don't put -tune grain inside x265-params
[22:54:35 CEST] <thebombzen> but you figured it out :)
[22:54:36 CEST] <nicolas17> maybe -tune sets crf or no-sao differently
[22:54:54 CEST] <thebombzen> as for is this expected behavior? no. order option matters in ffmpeg for somethings but not others
[22:55:11 CEST] <thebombzen> you should be able to interchange -x265-params crf=18:no-sao=1 with -tune grain
[22:55:19 CEST] <thebombzen> that sounds like a bug to me
[22:56:33 CEST] <ultrav1olet> -tune doesn't affect crf at all
[22:57:08 CEST] <ultrav1olet> you always either set crf manually, or it's set to its default which is 28 or you use some bitrate control
[22:57:10 CEST] <thebombzen> it doesn't and it shouldn't
[22:57:26 CEST] <thebombzen> those options should be interchangeable, that sounds like a bug.
[22:57:39 CEST] <thebombzen> also what is -c:a null? that doesn't work on my build.
[22:57:46 CEST] <ultrav1olet> (dunno why 28 is default - it's faaaaaar from being transparent or even acceptable)
[22:57:48 CEST] <thebombzen> what version are you using?
[22:57:55 CEST] <thebombzen> of FFmpeg
[22:58:04 CEST] <ultrav1olet> the one I compiled manually on Linux
[22:58:13 CEST] <thebombzen> that doesn't actually answer my question
[22:58:16 CEST] <ultrav1olet> 3.3.2 at the moment
[22:58:26 CEST] <thebombzen> hm, how did you get -c:a null :O
[22:58:28 CEST] <ultrav1olet> you need my compilation flags?
[22:58:42 CEST] <ultrav1olet> I thought -c:a null equals to no audio
[22:58:57 CEST] <ultrav1olet> in my case it works this way :-D
[22:58:57 CEST] <thebombzen> no, it produces the "unknown encoder: null" error
[22:59:03 CEST] <thebombzen> which you would know if you actually ran it
[22:59:28 CEST] <ultrav1olet> I'm running it right now quite successfully
[22:59:59 CEST] <ultrav1olet> and the output is quite correct - the only stream which is video
[23:01:23 CEST] <thebombzen> now I'm confused, how did you do that?
[23:02:42 CEST] <ultrav1olet> thebombzen: https://pastebin.com/karxm3Qq
[23:04:30 CEST] <ultrav1olet> the right option is of course -an but it's kinda non-obvious
[23:04:43 CEST] <kepstin> ah, your input file has no audio, so it doesn't try to initialize an audio encoder, so the "-c:a null" is ignored
[23:05:11 CEST] <ultrav1olet> I'm indeed the idiot here
[23:08:13 CEST] <ultrav1olet> -tune grain increases bitrate threefold. Wow.
[23:10:35 CEST] <furq> yeah it'll do that
[23:16:50 CEST] <asdzxc> Hey everyone. I had a quick question about md5 checksumming outputs of ffmpeg.
[23:17:04 CEST] <asdzxc> I saw this ticket from 3 years ago: https://trac.ffmpeg.org/ticket/3524
[23:17:42 CEST] <asdzxc> I'm running the same ffmpeg command twice, but my 2 outputs are not the same md5.
[23:18:16 CEST] <kepstin> asdzxc: as expected, not a bug.
[23:18:54 CEST] <kepstin> asdzxc: there's some metadata and such in various containers that's either random or time sensitive each run; some codecs (e.g. x264 multithreaded) are non-deterministic.
[23:20:27 CEST] <kepstin> there are options that cover some cases which can make things deterministic, but they're ether not recommended for general use (e.g. deterministic ogg stream ids can cause issues) or cause slowdowns (like doing single-threaded x264).
[23:21:57 CEST] <kepstin> asdzxc: of course, with md5, you could probably just add some padding to the files then calculate a collision ;)
[23:22:29 CEST] <kepstin> ... and I guess none of that was seen.
[23:37:17 CEST] <ultrav1olet> how can I concatenate two mkv (the same video codec, the same resolution) files without reencoding so that video streams get rebuilt?
[23:39:00 CEST] <ultrav1olet> right now the second part gets totally corrupted - I see some funny illumination/random noise/strange effects instead of the actual video
[23:39:20 CEST] <kepstin> ultrav1olet: concat format should do it: https://www.ffmpeg.org/ffmpeg-formats.html#concat-1
[23:39:40 CEST] <kepstin> ultrav1olet: might be something in mkvtoolnix that could give you something useful, too
[23:40:30 CEST] <ultrav1olet> I'm using concat indeed. It's just the output which is broken: millions of messages like [hevc @ 0xXXXXXXXXX] The cu_qp_delta -49 is outside the valid range [-26, 25]
[23:41:03 CEST] <ultrav1olet> the first part of the video uses different H265 encoding parameters than the second one
[23:41:12 CEST] <ultrav1olet> I'm not even sure that's allowed
[23:41:18 CEST] <kepstin> ultrav1olet: that's odd... are you sure the codec parameters are compatible? e.g. don't mix 8 and 10 bit video
[23:41:37 CEST] <ultrav1olet> However both parts are "x265 [info]: Main profile, Level-4 (Main tier)"
[23:42:04 CEST] <ultrav1olet> absolutely - the same encoding string aside from tune=grain for the second part
[23:42:44 CEST] <kepstin> I really don't know enough about hevc to say what's going on, then.
[23:43:16 CEST] <kepstin> would be helpful to see the full ffmpeg output from the concat run
[23:43:40 CEST] <kepstin> (and maybe the individual video encodes too, if you have that)
[23:44:35 CEST] <ultrav1olet> kepstin: https://pastebin.com/j75r3qNN
[23:46:22 CEST] <ultrav1olet> perhaps it's a bug in ffmpeg - I need to test some other decoder
[23:51:20 CEST] <kepstin> ultrav1olet: it really looks like the files have mismatched bit depths, can you paste the output of "ffmpeg -i <filename>" from each?
[23:54:08 CEST] <ultrav1olet> kepstin: https://pastebin.com/raw/yetfuZT7
[23:56:32 CEST] <ultrav1olet> maybe there's a way to use some raw intermediate container?
[23:57:42 CEST] <kepstin> ultrav1olet: yeah, I'm at a bit of a loss there, then. either something going wrong with the dumuxing/parsing (I assume the files can be independently played back fine?) or there's some other not-obvious parameter or something that's incompatible
[23:58:18 CEST] <ultrav1olet> yep, independently they can be played just fine
[00:00:00 CEST] --- Wed Jun 28 2017