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

[burek]

[00:00:08 CET] <Mavrik> But that's not a useful information to have when x264 isn't on the table.
[00:00:38 CET] <BtbN> h264 is still the kind of gold standard any codec has to compare to. Specially with x264.
[00:00:42 CET] <Mavrik> kingsley, unfortunately there's no such thing
[00:00:42 CET] <BtbN> So flat out ignoring it is silly.
[00:00:50 CET] <Mavrik> kingsley, and faster you want the encode, the worse the quality
[00:00:58 CET] <Mavrik> BtbN, again, not useful.
[00:01:03 CET] <BtbN> lol
[00:01:17 CET] <kingsley> Mavrik: Sorry. I don't know what you mean by "realtime transcode" or "Archival". FWIW, I'm basically bench marking how many more frames per second can be rendered with royalty free encoders by parallelizing the job across multiple CPUs, cores and threads.
[00:01:43 CET] <BtbN> The only relevant "royalty free" encoder is libvpx anyway, so not much to compare there
[00:01:53 CET] <Mavrik> mhm
[00:01:54 CET] <furq> kingsley: -row-mt 1 -threads n
[00:02:08 CET] <furq> libvpx only has slice threading so it'll probably be faster to just have one thread per instance
[00:02:10 CET] <Mavrik> And enabling row-mt is pretty much the only thing you can tweak
[00:02:13 CET] <BtbN> av1 kinda is as well, but it's so slow that it's not useful for most things yet
[00:02:34 CET] <furq> if you already have a workflow for splitting up the encode then vpx should be ok
[00:02:44 CET] <furq> single thread performance isn't too bad, it's just the multithreading that sucks
[00:02:53 CET] <kingsley> BtbN: Isn't the encoder named "av1" also royalty-free?
[00:03:07 CET] <BtbN> That's what I just said.
[00:03:08 CET] <furq> yes it is but also the encoders are either slow or poor quality
[00:03:11 CET] <BtbN> And av1 isn't an encoder, but a codec.
[00:03:22 CET] <furq> and by slow i mean like 50x slower than x265 veryslow
[00:05:19 CET] <kingsley> furq: Please elaborate on what -row-mt, -threads and slices are.
[00:05:35 CET] <BtbN> libvpx arguments.
[00:05:56 CET] <kingsley> furq: Or maybe refer me to some good documentation.
[00:05:57 CET] <furq> https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/oiHjgEdii2U
[00:06:12 CET] <furq> slice threading means the encoder breaks each frame up into multiple slices and encodes them independently
[00:06:33 CET] <furq> as opposed to frame threading where the encoder will encode different frames in different threads
[00:06:57 CET] <furq> slice threading is generally worse and causes a quality hit
[00:08:04 CET] <kingsley> furq: Thank you.
[01:21:45 CET] <Kaedenn> I got the montage part working nicely.
[01:22:19 CET] <kingsley> Is my preliminary observation consistent with yours, that among royalty free encoders, libvpx renders faster than libvpx-vp9, which renders faster than av1?
[01:22:21 CET] <Kaedenn> I give it a video file and it gives me a 4x3 collage of equally-spaced frames from the video.
[02:06:03 CET] <kepstin> kingsley: depending on video properties and encoder settings, libvpx's vp9 can sometimes be better than vp8 since it has better multithreading.
[02:06:10 CET] <kepstin> er, faster*
[02:56:41 CET] <MerlinTheWizard> Hi all.
[02:57:23 CET] <MerlinTheWizard> What codec can I use for highest decode efficiency in pure software?
[02:57:52 CET] <pink_mist> what type of efficiency are you looking for?
[02:58:08 CET] <MerlinTheWizard> I want to avoid high cpu usage
[02:58:25 CET] <MerlinTheWizard> This is on an older laptop, (2010)
[02:58:27 CET] <pink_mist> mpeg2 perhaps then
[02:58:38 CET] <MerlinTheWizard> Mpeg2?
[02:59:00 CET] <pink_mist> even old 486 cpus could decode that
[03:00:08 CET] <MerlinTheWizard> pink_mist, I could try it. How does it compare to webm and h.264
[03:00:10 CET] <MerlinTheWizard> ?
[03:00:31 CET] <pink_mist> it's completely awful compared to those
[03:00:35 CET] <MerlinTheWizard> It's not that my laptop can't decodde things, it's just that I don't want my battery to be drained.
[03:00:37 CET] <pink_mist> but should require little cpu
[03:00:57 CET] <MerlinTheWizard> pink_mist, does it use non-compute intensive compression?
[03:01:09 CET] <MerlinTheWizard> And why is it aweful?
[03:01:21 CET] <MerlinTheWizard> It's used in DVD's and stuff, right?
[03:01:50 CET] <pink_mist> it has a pretty bad tradeoff between space and quality
[03:02:12 CET] <MerlinTheWizard> Ok, I want decent compression though.
[03:02:20 CET] <MerlinTheWizard> So, I'll need something a little better.
[03:02:33 CET] <pink_mist> h264 is probably a good idea then
[03:02:47 CET] <MerlinTheWizard> How does it compare with webm?
[03:04:22 CET] <pink_mist> webm is a container, not a codec
[03:04:31 CET] <pink_mist> pretty sure you can put h264 inside webm
[03:05:19 CET] <MerlinTheWizard> I see. How does it compare with vp8 then?
[03:05:44 CET] <pink_mist> that I'm not sure about, sorry, you'll haveto wait for someone else who knows better
[03:05:54 CET] <MerlinTheWizard> Ok, thanks.
[03:13:30 CET] <Hello71> pretty sure most 2010 gpus have hwdec
[03:13:38 CET] <Hello71> at least for h264
[03:14:42 CET] <Hello71> ah, arrandale
[03:15:04 CET] <Hello71> so if your laptop was already obsolete in 2010 then it wouldn't have avc decode
[03:15:53 CET] <MerlinTheWizard> Hello71, the issue is with my driver. I haven't yet figured out how to tell the intel driver that my display is 1920x1200.
[03:16:00 CET] <Hello71> lol
[03:16:07 CET] <Hello71> did you at least install linux
[03:16:13 CET] <MerlinTheWizard> Yes.
[03:16:24 CET] <MerlinTheWizard> I'm running artix
[03:17:03 CET] <MerlinTheWizard> So I'm writing some bash scripts, a theme center, and I want it to be able to set animated backgrounds for me.
[03:17:18 CET] <MerlinTheWizard> But I don't want them to drain my battery.
[03:17:42 CET] <MerlinTheWizard> So far, the best I've tested has been webm. But I've only tested webp, gif, and webm
[03:18:14 CET] <Hello71> most of these "systemd less" distros are jokes
[03:18:22 CET] <MerlinTheWizard> Not mine.
[03:18:23 CET] <Hello71> but I guess it's hard to fuck up an arch-based one
[03:18:32 CET] <Hello71> well you can make it *less* of a joke
[03:18:38 CET] <Hello71> but it's still usually dumb
[03:18:51 CET] <MerlinTheWizard> I don't see how systemd is going to speed up my old laptop.
[03:20:11 CET] <MerlinTheWizard> And I don't run KDE or Gnome. If not being a joke means running KDE or Gnome, I'd rather run a 'joke' distro'.
[03:20:45 CET] <MerlinTheWizard> Like Gentoo for example, which I've run on my desktop using openrc for like 15+ years.
[03:21:54 CET] <MerlinTheWizard> Or, maybe not the openrc part
[03:33:19 CET] <Hello71> lol
[05:39:17 CET] <kingsley> kepstin: If you happen to have the time, and are so inclined, feel free to suggest fast encoding settings for rendering video with libvpx's vp9. Like maybe for multithreading.
[06:00:42 CET] <kepstin> it's mostly just using the "-row-mt 1" option to enable the faster multithreading mode.
[06:05:52 CET] <kingsley> kepstin: I just timed...
[06:06:34 CET] <kepstin> (you also have to manually set -threads when using libvpx)
[06:06:44 CET] <kingsley> $ for encoder in libvpx libvpx-vp9 ; do time ffmpeg -y -f lavfi -i testsrc2=s=1920x1080 -row-mt 1 -frames 100 -c:v ${encoder} /tmp/bench.webm ; done
[06:06:58 CET] <kingsley> My results?
[06:07:24 CET] <kingsley> libvpx: 19 seconds
[06:07:35 CET] <kingsley> libvpx-vp9" 69 seconds.
[06:09:50 CET] <kepstin> i'm not sure the default quality settings are comparable, you probably got a different pixel format (vp9 supports 4:4:4, vp8 does not), and you didn't actually enable multithreading.
[06:10:57 CET] <kingsley> Is my guess correct that ffmpeg's "-threads" option is thought to enable multithreading?
[06:12:27 CET] <kepstin> what the -threads option does depends on where in the command line it is and which encoder/decoder you're using.
[06:13:13 CET] <kepstin> in the case of encoding with libvpx, the default value is equivalent to "disable multithreading", and you need to explicitly set -threads to enabled multithreaded encoding with that many threads.
[06:14:14 CET] <kepstin> in the case of libx264, the default is to enable multithreading with an autodetected number of threads based on your available processor cores.
[06:15:26 CET] <kingsley> I just ran...
[06:15:30 CET] <kingsley> $ for encoder in libvpx libvpx-vp9 ; do time ffmpeg -y -f lavfi -i testsrc2=s=1920x1080 -loglevel fatal -threads 8 -row-mt 1 -frames 100 -c:v ${encoder} /tmp/bench.webm ; done
[06:15:38 CET] <kingsley> My results?
[06:15:54 CET] <kingsley> libvpx: 20 seconds
[06:16:08 CET] <kingsley> libvpx-vp9" 75 seconds.
[06:18:15 CET] <kepstin> hmm, i get a smaller difference than that. but honestly for vod the improvement in quality is probably worth the extra time to go with vp9 instead (and you can still tweak the speed/quality tradeoff with other options)
[06:19:06 CET] <BeerLover> I am trying to compile FFMPEG 4.2.2 on Alpine 3.10 in  docker image. I keep getting ERROR: openssl not found
[06:19:21 CET] <BeerLover> But i installed openssl 1.1.1d-r4
[06:19:43 CET] <kepstin> you need to install the -dev package for any libraries you want to compile against
[06:20:05 CET] <diederik> you probably need the -dev package installed
[06:20:23 CET] <kepstin> (and possibly also pkgconf)
[06:21:42 CET] <kepstin> kingsley: fwiw, setting -quality good -speed 2 on the vp9 encode on my box brings the speed up to match -quality good -speed 1 on vp8, but I haven't actually compared the visual quality between those options.
[06:22:41 CET] <kepstin> note also that the default for libvpx encoders is to do an abr encode at 400kbit/s if you don't specify other options, and that's pretty terrible for most videos.
[06:22:47 CET] <kepstin> er, 300kbit/s even
[06:23:56 CET] <kingsley> kepstin: Your interest in quality is understandable.
[06:31:52 CET] <kepstin> (you also have to be careful benchmarking short clips in sequence like that: in many configurations, modern cpus have shortish all-core turbo durations, my laptop is around 30s, so the first encode might run in turbo but the second one runs at lower clocks)
[06:33:27 CET] <kepstin> might be better to do a longer encode and see what the steady-state fps trends towards - on a sample video with representative content rather than testsrc.
[06:55:22 CET] <hendry> I have the same problem as https://devtalk.nvidia.com/default/topic/1070014/linux/ffmpeg-f-kmsgrab-is-failing-failed-to-open-drm-device-/ [kmsgrab @ 0x5629bb90d080] Failed to set universal planes capability: primary planes will not be usable. But on Intel [AVHWDeviceContext @ 0x55d0922d5040] Opened DRM device /dev/dri/card0: driver i915 version 1.6.0.
[07:03:56 CET] <hendry> being root doesn't appear to help
[11:24:53 CET] <Renari> Has anyone experienced ffmpeg corrupting metadata when converting audio files?
[11:25:32 CET] <Renari> I'm having this happen with multiples files, on windows and debian.
[11:28:27 CET] <durandal_1707> Renari: pastebing full ffmpeg command and its output
[11:31:40 CET] <Renari> sec
[11:33:14 CET] <Renari> hm I believe this is related to wav files only
[11:33:18 CET] <Renari> testing on mp3 it doesn't happen
[11:54:40 CET] <Renari> https://pastebin.com/raw/dGZ5DJYU
[11:54:57 CET] <Renari> command: ffmpeg -i sample.wav -acodec flac sample.flac 2> out.log
[11:57:10 CET] <durandal_1707> looks like input metadata is not read correctly
[11:58:01 CET] <Renari> Yeah I wonder if there's a way to specify an encoding to use when reading metadata.
[11:59:18 CET] <Renari> since I believe the encoding of that metadata is Shift-JIS
[11:59:28 CET] <Renari> and it's being interpreted as something else
[12:20:14 CET] <furq> Renari: ffmpeg -i sample.wav -f ffmetadata - | iconv -f sjis -t utf8 | ffmpeg -i sample.wav -f ffmetadata -i - -map_metadata 1 -c:a flac sample.flac
[12:21:15 CET] <Renari> furq, you're a god
[12:21:16 CET] <Renari> that works
[15:23:25 CET] <pink_mist> furq: that's a very nifty oneliner
[15:25:29 CET] <JEEB> (49
[16:22:12 CET] <diederik> I'm trying to create a shell script for converting videos to x265: https://paste.debian.net/1129223/
[16:23:45 CET] <diederik> But when I try to run it, it seems to mangle the variables, so "--loglevel debug" seems to turn into "-loglevel" which in turn causes failure as "-loglevel" isn't a valid parameter
[16:24:33 CET] <diederik> here is the output of 2 different variations/runs: https://paste.debian.net/1129283/
[16:26:10 CET] <diederik> I've tried many more variations, but these illustrate the problem I consistently run into with it
[16:36:57 CET] <DHE> ffmpeg doesn't use double-hyphen for any of its parameters
[16:37:14 CET] <danilo82> ayght, i encode a video using ffmpeg, but when i send to facebook it gets corrupted
[16:39:24 CET] <danilo82> ffmpeg -i "sain.mkv" -ss 00:18:50.00 -to 00:22:25.00 -map 0:0 -map 0:1 -c:v libx264 -preset veryslow -vf subtitles="sain.mkv",scale=720:540 out.mp4
[16:39:34 CET] <danilo82> is there any motive to be corrupted?
[16:41:13 CET] <diederik> DHE: thx! It turns out "--log-level" is from x265
[16:43:26 CET] <DHE> well you're setting the output to to h264 here, not h265. which should be fine, but clearly isn't h265
[16:44:14 CET] <diederik> why is that? because of the .mp4 extension?
[16:44:29 CET] <DHE>  -c:v libx264
[16:46:08 CET] <diederik> am I missing something? VIDEO_PARAMS="-c:v libx265 ..."
[16:49:17 CET] <DHE> oh I'm mixing up people whose names begin with 'd'
[16:49:18 CET] <DHE> :/
[16:50:37 CET] <diederik> np :)
[16:57:21 CET] <diederik> Having 'loglevel' works helps a lot. But it's now showing another error (which I've seen before):
[16:57:25 CET] <diederik> Reading option '-pix_fmt yuv420p10le' ...Unrecognized option 'pix_fmt yuv420p10le'.
[16:58:30 CET] <DHE> you're overquoting. the shell is turning the two statements into a single parameter with a space in it
[16:58:31 CET] <diederik> but that parameter is listed in man:ffmpeg under 'Advanced Video options'
[16:59:01 CET] <DHE> which actually might explain your other issues as well
[17:01:00 CET] <diederik> it looks like you're right. shellcheck is usually quite helpful, but apparently not in this case
[17:07:03 CET] <diederik> you were right :) removing quotes also fixed other issues. Thanks again.
[17:08:31 CET] <DHE> if a variable is meant to be a single arg then this is correct. but it's not - the spaces are meant to split arguments
[17:08:43 CET] <DHE> FILENAME="a filename with spaces"
[17:08:54 CET] <DHE> ls -l $FILENAME   # incorrect, you'll likely get 4 error of missing files
[17:17:46 CET] <diederik> bummer that the option parsing is debug level and not verbose. Debug outputs a lot I don't care about (or understand)
[17:20:46 CET] <JEEB> diederik: i have been thinking about per module verbosity levels, but not sure how simple that'dbe to do :p it's a life saver with mpv
[17:20:55 CET] <pagios> hi, let struct = ['-vf','scale='+transcodingProfile["resolution"],"-vb",test"bitrate"],"-g",90,"-framerate",30,"-hls_time",3,"-f","hls",channelPath]; <--- when using this my ffmpeg is transocding correctly BUT at some point in time the m3u8 playlist is being removed from the directory, it reappears after few seconds, any idea how to keep the m3u8 file at all time? Thank you
[17:23:39 CET] <pagios> JEEB, any idea?
[17:27:39 CET] <diederik> JEEB: that might be useful as well (I'm a noob wrt this/ffmpeg). To me, the parsing of the input params is sth entirely different from what fills my screen now "[h264 @ 0x5629d93d1400] [debug] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0"
[17:28:33 CET] <diederik> verbose logging does show the consequences of the input params, just not the input params themselves
[17:34:13 CET] <DHE> while ffmpeg is running you can press + and - to adjust the debug level
[17:34:26 CET] <DHE> as long as stdin is a console
[17:36:08 CET] <diederik> stdin is a console and it does work. Did you mean loglevel instead of debug level or are there indeed different levels within debug level?
[17:46:54 CET] <DHE> it's the same thing
[17:46:58 CET] <DHE> maybe I'm using the wrong term
[17:51:03 CET] <diederik> ok. it is a HUGE help now that I don't see 99% which are useless to me :)
[18:10:53 CET] <pagios> how can i set the hls base directory?
[18:31:35 CET] <redeeman> hello, can i specify -vcodec and -acodec to a specific stream? if my output contains multiple video streams and i want to encode them with different codecs?
[18:32:11 CET] <BtbN> first of all -v/acodec are deprecated, use -c:v and so on
[18:32:59 CET] <BtbN> and then you can use not only :v or :a, but can select a specific stream like :v:0 is the first video stream, and :v:1 the second, and so on.
[18:38:23 CET] <redeeman> BtbN: thanks
[18:42:15 CET] <diederik> is HDR useful and sth that I would want? I'm experimenting with https://www.youtube.com/watch?v=gvDDiKsChsM and when I use '-x265-params "colormatrix=bt2020nc"' Jeremy's face has more color then in the original.  When I use "colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc" his face turns rather red
[18:43:33 CET] <diederik> I'm a noob, so there is a high chance I'm doing sth wrong. But if this is a 'natural' consequence of (trying to) use HDR, then I should look into an entire different direction
[18:45:40 CET] <BtbN> Do you have a HDR screen, and a chain to it that actually works?
[18:47:57 CET] <diederik> my PC screen doesn't support it, but my TV does. I don't know about the chain. I learned that HandBrake uses an 8-bit pipeline, so I thought I'd try it with ffmpeg directly instead
[18:48:29 CET] <JEEB> diederik: post the result of it with -v verbose on a pastebin or so
[18:48:31 CET] <JEEB> and link here
[18:49:03 CET] <JEEB> basically if your output colorimetry parameters match the input, and you have no conversions in the middle it should all be the same as in input
[18:49:41 CET] <JEEB> you don't have to actually do the full clip, just enough that it does like a few frames' worth of encode and thus you have all the filter chain etc logging there
[18:50:35 CET] <diederik> https://paste.debian.net/1129304/ the 2nd line shows the ffmpeg command that should be invoked
[18:55:02 CET] <JEEB> [format @ 0x55cde98c1e40] [verbose] auto-inserting filter 'auto_scaler_0' between the filter 'Parsed_null_0' and the filter 'format'
[18:55:05 CET] <JEEB> [auto_scaler_0 @ 0x55cde98c4340] [verbose] w:1920 h:1080 fmt:yuv420p sar:1/1 -> w:1920 h:1080 fmt:yuv420p10le sar:1/1 flags:0x4
[18:55:14 CET] <JEEB> so your input is 4:2:0 8bit?
[18:55:38 CET] <JEEB> which is agreed upon by the verbose output of the input listing
[18:55:39 CET] <JEEB>  yuv420p(tv, bt709, left)
[18:55:42 CET] <JEEB> ok
[18:55:53 CET] <diederik> I think so
[18:55:57 CET] <JEEB> and yea, then you just set output to another colorspace
[18:56:01 CET] <JEEB> as in, the value in the metadata
[18:56:02 CET] <JEEB> nothing else
[18:56:13 CET] <JEEB> so metadata != actual content
[18:56:17 CET] <JEEB> not sure what you expected to happen
[18:57:13 CET] <diederik> so that means that I'm not doing it right, rather then an inherent consequence of using HDR?
[18:57:27 CET] <JEEB> yes, you are not doing it right. also your input in no way is HDR
[18:57:59 CET] <diederik> and if the input is not HDR, then it's useless to 'add' it?
[18:58:06 CET] <JEEB> yes
[18:58:18 CET] <diederik> ok, thx
[18:58:21 CET] <JEEB> you can do a 10bit encode, but just set the colormatrix to bt709 like it is in the input
[19:00:08 CET] <diederik> I also have a 4k HDR file and I looked with mpv what properties it had and tried to apply that. Now I know that that would be useless
[19:01:05 CET] <JEEB> you can make the conversion with the zscale filter if you really, really want. but your content is not going to become any more HDR than it already is. it will just be scaled to a wider canvas of the HDR colorspace/transfer function
[19:02:37 CET] <JEEB> BT.2020 is just a wider color space, and then SMPTE ST.2084 aka PQ is one of the HDR transfer functions :P
[19:02:40 CET] <JEEB> (other being HLG)
[19:04:31 CET] <diederik> I thought/hoped that bt2020nc would be a superset of bt709 and would therefor be harmless. I guess I need to make my conversion script more intelligent

[19:11:29 CET] <diederik> a bit, I think. Probably not enough to understand the (actual) implications ;)
[19:12:22 CET] <diederik> let alone how to deal with it (without some significant study on the subject)
[19:13:20 CET] <JEEB> basically what I mean is that the output should be exactly the same or in the worst case with a stupid box like a TV or something worse
[19:13:51 CET] <JEEB> something like mpv will actually check dynamically how much of that wider canvas you're using and not attempt to keep "possible more bright parts" (which you will never have because your content is not HDR)
[19:14:06 CET] <JEEB> while a dumb TV or something might do that
[19:14:46 CET] <JEEB> so if you do a proper conversion the output should be exactly the same, which is why I wouldn't recommend doing a conversion :
[19:16:48 CET] <JEEB> there are ways of pulling that content in different ways across the wider canvas, but like... really?
[19:18:23 CET] <JEEB> (and that's no longer considered a colorspace conversion but rather something completely different)
[19:28:23 CET] <diederik> yeah, that very much sounds like sth I don't want or need. My main goal is using less storage for my content with the minimal quality loss.
[23:31:32 CET] <nickname123> hi
[23:33:53 CET] <nickname123> relaxed: can i report a problem that i have with the FFmpeg Static Builds under ubuntu to you?
[23:35:04 CET] <pink_mist> is it a fontconfig issue?
[23:35:24 CET] <nickname123> it is a foncfonfig issue
[23:35:27 CET] <nickname123> -c+t
[23:35:59 CET] <pink_mist> ah, just looked back in the scrollback and saw that it was you who mentioned that before too
[23:44:39 CET] <nickname123> someone on ##linux found this thread: https://bbs.archlinux.org/viewtopic.php?id=235643
[23:45:00 CET] <nickname123> i guess the 2.13.1-2ubuntu2 fontconfig of my kubuntu 19.10 is too new for the ffmpeg static build
[23:45:27 CET] <nickname123> under raspian and fontconfig 2.11.0-6.3+deb8u1 the static build works fine
[23:47:58 CET] <nickname123> the thread mentions "changes appeared in the new fontconfig 2.13.0 release." and the thread starter got about the same errors as i get
[23:49:18 CET] <pink_mist> should probably file the bug against fontconfig tbh .. making incompatible changes between 2.x releases
[00:00:00 CET] --- Thu Feb  6 2020