October 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20191025
by burek 26 Oct '19

26 Oct '19

[00:26:08 CEST] <cone-304> ffmpeg 03Michael Niedermayer 07master:42eb78059d14: avcodec/takdec: Fix overflow with large sample rates [00:26:09 CEST] <cone-304> ffmpeg 03Michael Niedermayer 07master:f4ecf6c39de9: avcodec/ralf: Skip initializing unused filter variables [00:26:10 CEST] <cone-304> ffmpeg 03Michael Niedermayer 07master:000494fed932: tools/target_dec_fuzzer: Adjust ffwavesynth threshold [00:26:11 CEST] <cone-304> ffmpeg 03Michael Niedermayer 07master:8caa7166676e: tools/target_dec_fuzzer: Adjust threshold for CFHD [00:26:12 CEST] <cone-304> ffmpeg 03Michael Niedermayer 07master:b63fbc19c09d: avcodec/qdrw: Check input for header/skiped space before get_buffer() [00:26:13 CEST] <cone-304> ffmpeg 03Michael Niedermayer 07master:4834ec926aa5: avcodec/hcom: Check the root entry and the right entries [00:26:14 CEST] <cone-304> ffmpeg 03Michael Niedermayer 07master:3948d80842f5: avcodec/interplayacm: Fix integer overflows in juggle() [00:26:15 CEST] <cone-304> ffmpeg 03Michael Niedermayer 07master:66589d9bd990: avcodec/truespeech: Fix integer overflow in truespeech_synth() [00:26:16 CEST] <cone-304> ffmpeg 03Michael Niedermayer 07master:698e042c77ec: avcodec/vp5: Check render_x/y [00:26:17 CEST] <cone-304> ffmpeg 03Andreas Rheinhardt 07master:6f2a3958cfac: fftools/ffmpeg: Free swresample dictionary during cleanup [06:26:06 CEST] <cone-218> ffmpeg 03Jun Li 07master:155508c6e925: avformat/tee.c: steal bsf option before passing to fifo muxer [10:14:26 CEST] <durandal_1707> ubitux: the max level for 3d lut is 256, so I will split patch into two, awaiting review [10:15:43 CEST] <ubitux> durandal_1707: can you try if there is a benefit in aligning to the next ^2 each dimension? [10:15:54 CEST] <ubitux> like, if you get a 17x17x17, you would alloc 32x32x32 [10:20:49 CEST] <durandal_1707> ubitux: that would allocate 256 for 144? [10:25:05 CEST] <ubitux> durandal_1707: yeah [10:26:40 CEST] <ubitux> maybe a 16 align instead would be enough though [10:26:45 CEST] <ubitux> instead of a pow of 2 [10:27:00 CEST] <ubitux> (144 would stay 144, but 17 would become 32) [11:25:16 CEST] <durandal_1707> ubitux: doesn't make any difference here [11:39:30 CEST] <durandal_1707> michaelni: looked at that interplay mve bug? [12:25:17 CEST] <michaelni> durandal_1707, nope, i have enough bugs to work ok [12:25:24 CEST] <michaelni> oN [12:25:46 CEST] <durandal_1707> michaelni: but this is regression [12:28:24 CEST] <cone-218> ffmpeg 03Paul B Mahol 07master:9d711a90fdf3: avformat/bintext: avoid division by zero [12:35:32 CEST] <michaelni> iam not sure it is, linesize could be anything before too. But if this bug interrests you so much, you should look into it. I dont see the connection between me and this bug. Its not code i wrote nor maintain nor did i write the commit triggering this and iam working on other bugs ATM [12:38:27 CEST] <durandal_1707> michaelni: i failed to fix it, it is very hard to fix [12:43:45 CEST] <michaelni> well, i can try to look at it later but there are quite a few things i wanted to do "yesterday" so iam not sure when [16:23:26 CEST] <durandal_1707> i have much better metric than vmaf, psnr and ssim all together [16:32:07 CEST] <Lynne> you use your eyes? [16:32:55 CEST] <durandal_1707> no [17:04:18 CEST] <durandal_1707> michaelni: i found source of bug, 0x06 variant can have negative x when copying data from other frames, if worked with old linesize by pure luck [17:04:53 CEST] <durandal_1707> ie. x + delta_x is negative [17:32:53 CEST] <michaelni> durandal_1707, great, i didnt yet had time to look ... [17:43:53 CEST] <cehoyos> Was there already a discussion if a "Japan Rail Pass" is useful? [17:46:35 CEST] <durandal_1707> ? [17:47:39 CEST] <cehoyos> VDD [17:57:40 CEST] <Chagall> probably depends on how much you are planning on taking the train [17:58:57 CEST] <cehoyos> From Tokyo to Kyoto and back but I wonder if I will use it to get from Haneda airport to the hotel [18:30:19 CEST] <cone-218> ffmpeg 03Paul B Mahol 07master:0481a1f6e5b8: avcodec/interplayvideo: properly decode motion vectors [19:08:31 CEST] <BBB> jamrial: ping [19:08:40 CEST] <jamrial> BBB: pong [19:08:44 CEST] <BBB> hey [19:09:06 CEST] <BBB> is there some way that ffprobe or so allows me to print the "frame_type" field from an av1 frame? [19:09:23 CEST] <jamrial> -show_frames should do that [19:09:31 CEST] <BBB> does it just show key/notkey? [19:09:37 CEST] <BBB> or does it also mark other frame types? [19:09:50 CEST] <BBB> like s-frame or intra_only etc. [19:09:55 CEST] <jamrial> i think it shows both frame type (I, P, etc) and also key or not key [19:10:35 CEST] <BBB> AV_PICTURE_TYPE_SP? [19:11:16 CEST] <jamrial> key_frame={0,1} [19:11:22 CEST] <jamrial> pict_type={I,B,P} [19:11:57 CEST] <BBB> ffprobe ~/Downloads/test_sframe_2_1_lag0_new.ivf -c:v libdav1d ? [19:12:07 CEST] <BBB> djeez, my ffprobe knowledge is low [19:12:25 CEST] <Lynne> use the trace_headers bsf if you need something more detailed, but its extremely verbose and printed on stderr [19:12:26 CEST] <jamrial> ffprobe -show_frames ~/Downloads/test_sframe_2_1_lag0_new.ivf [19:12:48 CEST] <jamrial> it will use the available decoder to parse the stream and output information for each frame [19:13:16 CEST] <BBB> pict_type=? using libaom [19:13:30 CEST] <BBB> how do I force libdav1d? [19:13:36 CEST] <BBB> (older ffmpeg version here) [19:13:39 CEST] <jamrial> yeah, our libaom wrapper isn't tagging frames right [19:14:01 CEST] <BBB> -vcodec or -c:v doesn't appear to work [19:14:11 CEST] <jamrial> neither -codec:v [19:14:22 CEST] <jamrial> not sure if you can force it [19:15:20 CEST] <jamrial> can't you use a more recent ffmpeg build with libdav1d as default? [19:15:34 CEST] <jamrial> and as Lynne said, you could always instead use the trace_headers bsf [19:15:39 CEST] <BBB> probably, but it's not for me, I'm trying to help someone else [19:15:42 CEST] <BBB> let me try trace_headers [19:15:43 CEST] <jamrial> ah [19:16:05 CEST] <jamrial> trace_headers will show you the av1 bitstream fields as named in the spec [19:16:08 CEST] <BBB> telling an external person to use current git/master isn't exactly helpful, might just as well write them a bash script to parse the field directly then :-p [19:16:20 CEST] <BBB> how do I do that? -trace_headers? [19:16:43 CEST] <jamrial> yeah, in that case i guess trace_headers isn't ideal because all the show_existing_frame stuff will make it hard to know which frame is which :p [19:16:54 CEST] <jamrial> ffmpeg -i INPUT -c:v copy -bsf:v trace_headers -f null - [19:18:39 CEST] <BBB> tnx! [19:22:19 CEST] <durandal_1707> Lynne: its gmsd, gradient magnitude similarity deviation, and its better than vmaf [19:34:13 CEST] <durandal_1707> ubitux: nobody gonna review lut3d patches except you [19:35:40 CEST] <ubitux> will do tonight [19:35:49 CEST] <ubitux> ping me tomorrow if i forgot [19:38:48 CEST] <durandal_1707> okay [22:08:42 CEST] <cone-487> ffmpeg 03Paul B Mahol 07master:9e283aa24eca: avfilter/vf_psnr,vf_ssim: add warning if different timebases are encountered [22:36:55 CEST] <cone-487> ffmpeg 03Paul B Mahol 07master:487a1f28e283: doc/filters: add one more example for ssim/psnr [23:02:04 CEST] <cone-487> ffmpeg 03Paul B Mahol 07master:296296a4d519: doc/filters: add one more example for libvmaf [23:32:09 CEST] <cone-487> ffmpeg 03Andreas Rheinhardt 07master:2e37237ff107: avformat/aiffenc: Add deinit function [23:32:09 CEST] <cone-487> ffmpeg 03Andreas Rheinhardt 07master:09e938b3a129: avformat/asfenc: Remove unnecessary header [23:32:11 CEST] <cone-487> ffmpeg 03Andreas Rheinhardt 07master:982539a07af7: avformat/avidec: Remove superfluous header [23:32:11 CEST] <cone-487> ffmpeg 03Andreas Rheinhardt 07master:b78227e1684a: avformat/avienc: Remove superfluous header [00:00:00 CEST] --- Sat Oct 26 2019

1 0

ffmpeg.log.20191025
by burek 26 Oct '19

26 Oct '19

[00:00:20 CEST] <kepstin> hmm? a widescreen dvd should be either 854 or 872 by 480 for ntsc, or 1024 or either 1048 by 576 for pal [00:01:08 CEST] <kepstin> the 854/872 or 1024/1048 depends on whether the video had the areas past the edge of the clean picture cropped off or not [00:02:46 CEST] <void09> kepstin: yeah it's a rip of a dvd, was probably cropped [00:03:04 CEST] <void09> but no matter, the -vf 'setsar=2,scale=w=trunc(if(gte(sar\,1)\,iw*sar\,iw)/ohsub)*ohsub:h=trunc(if(gte(sar\,1)\,ih\,ih/sar)/ovsub)*ovsub,setsar=1' - is wrong [00:03:22 CEST] <void09> tested it in command line, you can test it too [00:04:07 CEST] <kepstin> I've confirmed that it works correctly in my testing. [00:04:18 CEST] <kepstin> er, wait, error there [00:04:19 CEST] <void09> also takes about 15 seconds to process [00:04:24 CEST] <kepstin> remove the setsar=2 from the start :) [00:04:30 CEST] <kepstin> that was from when i was testing it [00:04:31 CEST] <void09> yeah i thought it might be that [00:05:03 CEST] <void09> before: Stream #0:0: Video: png, rgb24, 3840x1080 [SAR 1:1 DAR 32:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default) [00:05:11 CEST] <void09> after: Stream #0:0: Video: png, rgb24, 1920x1440 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default) [00:05:33 CEST] <kepstin> that setsar does exactly like it says, ignores the input sar and sets it to 2 [00:05:38 CEST] <kepstin> (dar gets recalculated) [00:05:47 CEST] <realies> is there any linux binaries available compiled with --enable-lv2? [00:05:56 CEST] <void09> still takes a bit long to process [00:05:59 CEST] <kepstin> the setsar=1 at the end is to fix rounding errors [00:09:45 CEST] <void09> yeay it works [00:10:23 CEST] <void09> submit edit doc request :) [00:14:38 CEST] <kingsley> How would you add the options "-row-mt 1" and "-threads" to speed up the following ffmpeg command? [00:14:49 CEST] <kingsley> $ ffmpeg -f lavfi -i mandelbrot=s=1920x1080 -frames 10 -f null - [00:15:54 CEST] <BtbN> Using all available CPU threads is the default. [00:17:46 CEST] <kingsley> BtbN: Yes, but, I wonder if ffmpeg recently implemented a new and faster algorithm for using all CPU threads: row multi threading, and if it needs to be manually specified. [00:18:19 CEST] <void09> anyone know where you can get free cpu cores for encoding ? [00:18:45 CEST] <kingsley> FWIW, the closest I get to using -row-mt 1 is [00:18:59 CEST] <BtbN> Isn't row-mt a libvpx thing? [00:19:13 CEST] <kingsley> $ ffmpeg -threads 1 -f lavfi -i mandelbrot=s=1920x1080 -row-mt 1 -frames 10 -f null - [00:19:23 CEST] <kingsley> but ffmpeg complains with [00:19:29 CEST] <BtbN> yeah, libvpx and libaom. [00:19:38 CEST] <BtbN> Since you're not encoding, the option does not apply. [00:19:40 CEST] <kingsley> Codec AVOption row-mt (Row based multi-threading) specified for output file #0 (pipe:) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream [00:20:25 CEST] <kingsley> BtbN: I'll try writing to a file other than null. [00:20:39 CEST] <BtbN> It's an option for libvpx... [00:20:48 CEST] <BtbN> so unless you use libvpx, it doesn't make any sense. [00:22:27 CEST] <kingsley> BtbN: Thank you very much for your astute observation that -row-mt 1 would not apply because I wasn't writing to a file. [00:22:35 CEST] <kingsley> I'm happy to report [00:22:44 CEST] <BtbN> It has nothing to do with writing to a file or not... [00:22:49 CEST] <kingsley> $ ffmpeg -threads 1 -f lavfi -i mandelbrot=s=1920x1080 -row-mt 1 -frames 10 /tmp/cores.webm [00:22:51 CEST] <BtbN> it's an option for libvpx/aom [00:22:59 CEST] <kingsley> didn't complain. [00:23:14 CEST] <BtbN> Because webm probably defaults to VP8 or 9 which defaults to libvpx. [00:24:01 CEST] <kingsley> BtbN: Yes, your theory of .webm->libvpx seems plausible to me. [00:33:11 CEST] <realies> aand got stuck at ffmpeg: error while loading shared libraries: libavdevice.so.58: cannot open shared object file: No such file or directory [00:33:29 CEST] <realies> following https://seanthegeek.net/455/how-to-compile-and-install-ffmpeg-4-0-on-debian… on ubuntu 18.04 [00:36:16 CEST] <realies> guess no other way to get lv2 without recompiling from source [00:51:20 CEST] <kingsley> Feel free to benchmark how well "-row-mt 1" and "-threads 1" allow rendering .webm format video to scale with various numbers of cores and let us know what happens. [00:51:30 CEST] <kingsley> I humbly suggest trying [00:51:51 CEST] <kingsley> $ ffmpeg -y -f lavfi -i mandelbrot=s=1920x1080 -threads 1 -row-mt 1 -frames 50 -c:v libvpx /tmp/bench.webm [00:52:12 CEST] <kingsley> and letting us know how many cores you have. [00:53:10 CEST] <kingsley> Bonus: If you want to see in more detail how well libvpx scales with cores, try running it with my humble script at [00:53:29 CEST] <kingsley> http://loaner.com/how_fast_do_various_numbers_of_cores_run [00:54:17 CEST] <kingsley> to bench mark ffmpeg with a variety of core counts. [00:54:30 CEST] <kingsley> The syntax is [00:54:46 CEST] <kingsley> $ how_fast_do_various_numbers_of_cores_run "ffmpeg -y -f lavfi -i mandelbrot=s=1920x1080 -threads 1 -row-mt 1 -frames 50 -c:v libvpx /tmp/bench.webm" [04:19:42 CEST] <realies> can't compile ffmpeg with lv2 on ubuntu nor macos... [04:20:14 CEST] <realies> macos gives me Segmentation fault: 11 and ubuntu ffmpeg: error while loading shared libraries: libavdevice.so.58: cannot open shared object file: No such file or directory [04:27:50 CEST] <ponyrider> realies: apt-get install libavdevice58? [08:56:15 CEST] <th3_v0ice> How to handle different number of samples between input and output when using swr_convert? [14:42:59 CEST] <Jendrej> Hello. Could someone explain to me how is "adjusting the volume" different from "setting the volume"? ( https://trac.ffmpeg.org/wiki/AudioVolume ) [14:43:57 CEST] <DHE> a fixed adjust adjustment vs a fixed target peak/average [14:44:20 CEST] <Jendrej> i need a more simple explanation [14:44:38 CEST] <DHE> doing the latter usually requires doing a measurement of the input first to calculate the needed adjustment. or you can just yolo it and set the adjustment and go [14:45:22 CEST] <Jendrej> oh i think i get it, setting lets me set in decibels, right? [14:45:32 CEST] <Jendrej> and adjust is just %? [14:46:00 CEST] <Jendrej> thanks [14:46:23 CEST] <DHE> so ffmpeg provides a volume filter to apply the adjustment, and volumedetect to do the measurements... [14:47:18 CEST] <Jendrej> nah, I think I'll just do it by trial and error [14:47:25 CEST] <Jendrej> it doesn't need to be super precise [14:49:51 CEST] <furq> you should definitely use volumedetect if you're increasing the volume unless you like clipping [14:49:54 CEST] <furq> if you're reducing it then do whatever [14:52:14 CEST] <Jendrej> why would that happen? [14:53:29 CEST] <durandal_1707> google for audio clipping [14:54:07 CEST] <DHE> you know that awful sound people make when they yell into their PC Microphone? [14:54:17 CEST] <DHE> when they max out their micophone? [14:54:28 CEST] <Jendrej> but why would it clip with one of these options vs not with the other [14:55:02 CEST] <DHE> you can't max the sample range out by turning the volume down [14:55:48 CEST] <Jendrej> I mean I want to turn the volume up. Why would it clip when I don't use when I do the settings [14:55:51 CEST] <Jendrej> setting* [14:56:01 CEST] <furq> if you have one sample at -5dB and one sample at -10dB, and you increase the volume by 10dB, you now have two samples at 0dB [14:56:55 CEST] <furq> volumedetect will print the peak volume, which is as much as you can increase the volume by without any clipping [14:56:55 CEST] <Jendrej> sorry i don't even know how minus decibels work :E [14:57:14 CEST] <furq> https://en.wikipedia.org/wiki/DBFS [14:57:25 CEST] <furq> in short, 0 is the maximum [14:58:24 CEST] <Jendrej> oh [14:58:49 CEST] <Martchus> Is the SSL support via --enable-openssl and --enable-gnutls equivalent? Using OpenSSL instead of GnuTLS would ease creating a static build for Windows because p11-kit required by gnutls can not be built as static library. [14:59:15 CEST] <furq> Martchus: they should have equivalent functionality, but the licensing will be different [14:59:35 CEST] <furq> openssl is listed as nonfree so you wouldn't be able to distribute the binaries [15:00:46 CEST] <Jendrej> what does "-f null /dev/null" do and can i use it on windows? [15:00:49 CEST] <Martchus> furq: Thanks for the quick answer. I suppose the nonfree classification of OpenSSL is still a problem when my own application is actually using GPL? [15:01:00 CEST] <furq> well ffmpeg is lgpl so it's already a problem [15:01:29 CEST] <furq> Jendrej: it means to output nothing and send it to /dev/null, which isn't really necessary because you're outputting nothing [15:01:34 CEST] <furq> you can just do -f null - [15:01:36 CEST] <furq> to send it to stdout [15:01:58 CEST] <Martchus> furq: But if my own code is GPL I should be able to use the LGPL ffmpeg. [15:02:09 CEST] <furq> sure, but probably not with openssl [15:03:12 CEST] <Martchus> Mh... other projects such as Qt (which is GPL/LGPL) also use OpenSSL. [15:03:17 CEST] <furq> yeah i don't really know how the whole dual licensing thing works with openssl [15:03:20 CEST] <furq> i just know ffmpeg has it listed as nonfree [15:03:33 CEST] <furq> openssl and/or libressl which has even more confusing licensing iirc [15:06:38 CEST] <Jendrej> thank you for the help [15:06:46 CEST] <Martchus> So the OpenSSL license is at least LGPL compatible: https://unix.stackexchange.com/questions/523188/ffmpeg-claims-openssl-is-no… [15:07:37 CEST] <furq> openssl isn't actually under apache v2 yet [15:07:45 CEST] <furq> the latest release is still under the old dual license [15:07:53 CEST] <Martchus> I know, the link states it. [15:08:35 CEST] <Martchus> I was referring to "The Fraunhofer FDK AAC and OpenSSL libraries are under licenses which are incompatible with the GPLv2 and v3. To the best of our knowledge, they are compatible with the LGPL.". [15:32:44 CEST] <kepstin> i've seen people who write gpl applications add an additional permissions grant to the license that allows linking with openssl [15:32:55 CEST] <kepstin> as your lawyer for details :) [15:45:19 CEST] <DHE> yeah but it can be hard with a massive collaboration project like ffmpeg to make licensing changes [15:57:19 CEST] <realies> ponyrider, ubuntu 18.04 does not have it [16:52:04 CEST] <wildefyr> hi, using ffmpeg with -f pulse to record my microphone through my audio interface works nicely, however, my mic is a mono input and the audio interface only outputs on the left channel. I want to remux the left channel to just be a mono source and output on both l&r channels, is this possible when initially recording? [17:36:32 CEST] <kepstin> wildefyr: the "-channels 1" input option will probably do the trick (it defaults to 2). There's also the -map_channel option or filters that can probably fix it [17:37:05 CEST] <kepstin> wildefyr: on my audio interface which has the same problem, I load some channel remapping config into pulseaudio to make it act like two mono inputs instead of one 2-channel input [17:41:12 CEST] <kepstin> wildefyr: something like `pacmd load-module module-remap-source master=alsa_input.usb.YourAudioInterface.analog-stereo master_channel_map=front-left channel_map=mono source_properties=device.description='"YourAudioInterface\ Input\ 01"'` (changing the device name with yours), then you record from the "alsa_input.usb.YourAudioInterface.analog-stereo.remapped" device. [17:41:43 CEST] <kepstin> i do that since it makes it work with other software, like webrtc in browsers and stuff :) [17:43:39 CEST] <realies> how should I debug this? https://dpaste.de/ztfX/raw [17:44:29 CEST] <cehoyos> You could update to current FFmpeg and run with valgrind [17:45:10 CEST] <cehoyos> Does the crash happen with any input file (possibly /dev/zero) or only with a specific file? [17:46:11 CEST] <realies> cehoyos, not really sure, can I test the lv2 plugin on its own somehow? [17:46:28 CEST] <cehoyos> You could use another input file [17:46:44 CEST] <realies> will try /dev/zero [17:46:52 CEST] <cehoyos> or "-f f32le -i /dev/zero" [17:47:41 CEST] <realies> https://dpaste.de/y7Af/raw :( [17:48:29 CEST] <cehoyos> :-) <- it is reproducible without having access to your sample [17:48:39 CEST] <cehoyos> Try current FFmpeg git head and run with valgrind [17:49:55 CEST] <realies> I think I'm trying current ffmpeg [17:50:14 CEST] <realies> actually https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 [17:50:44 CEST] <realies> should be current? [17:50:57 CEST] <realies> followed https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu and added -enable-lv2 [17:51:10 CEST] <realies> I need to see how to work with valgrind [17:52:25 CEST] <cehoyos> No, it is old and unsupported [17:53:49 CEST] <realies> but ffmpeg-snapshot.tar.bz2 2019-10-24 19:23 [17:53:59 CEST] <realies> that seems like yesterday [17:55:10 CEST] <cehoyos> [lv2 @ 0x1185000] Plugin <https://github.com/lucianodato/noise-repellent> not found [17:55:12 CEST] <cehoyos> This is what I get [17:55:44 CEST] <cehoyos> It's six months old but why do you ask here if you no better than I do? [17:55:52 CEST] <cehoyos> know [17:57:54 CEST] <wildefyr> kepstin: okay thanks!! [17:59:29 CEST] <realies> cehoyos, not having a real strategy to debug it other than attaching a debugger to it [17:59:43 CEST] <cehoyos> Did you try valgrind? [18:00:11 CEST] <cehoyos> But as long as you are not testing a current snapshot I agree it has limited relevance [18:26:09 CEST] <realies> cehoyos assumed the timestamp from yesterday would be a recent snapshot, will try with tarballs from the releases section on the website later [18:26:57 CEST] <cehoyos> The link is horribly broken which you cannot know [18:27:17 CEST] <cehoyos> It leads to a version for which you get no support here and you cannot use it for bug reports [18:27:27 CEST] <cehoyos> https://ffmpeg.org/releases/ffmpeg-snapshot-git.tar.bz2 [18:27:30 CEST] <cehoyos> This should work [18:29:00 CEST] <cehoyos> Sorry, let me try again: [18:29:19 CEST] <cehoyos> The version for which you posted console output on dpaste is six months old [18:29:45 CEST] <cehoyos> The version for which you showed a link above - https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 - is current FFmpeg as you correctly claimed. [18:29:53 CEST] <cehoyos> The link I gave is the same version but with git information. [18:30:40 CEST] <realies> ohhh I thought you refer to the plugin being 6+ months old [18:30:58 CEST] <realies> will be right on it when I get back to my computer, thanks [18:31:01 CEST] <cehoyos> I don't know the plugin and I am not sure the console output shows the age [18:32:19 CEST] <realies> I probably need to test it separately somehow but not sure they've brought up that UI that can be seen on the demo [19:04:54 CEST] <jemius> I have a ripped DVD which is partly broken. I can watch the ripped stream if I skip the broken part of the video. Are there alternatives to -ignore_unknown to repair such a video? [22:26:28 CEST] <realies> cehoyos, using the git snapshot made it work ^^ [22:27:43 CEST] <realies> not seeing any processing effects with ./ffmpeg -i ~/test.mp3 -af "lv2=p=https\\\\://github.com/lucianodato/noise-repellent:c=reduction=48.0" ~/test-processed.mp3 when the plugin props are http://ix.io/1ZQi [22:29:47 CEST] <realies> do the input and output have to be engaged in any way? [22:32:49 CEST] <durandal_1707> you picked worst lv2 plugin [22:36:11 CEST] <realies> why? [22:36:29 CEST] <realies> seems to do alright https://www.youtube.com/watch?v=iNVxCvgcnig [22:39:12 CEST] <realies> -af "lv2=p=https\\\\://github.com/lucianodato/noise-repellent:c=reduction=22.656…" also does not change the input file :( [22:41:23 CEST] Action: realies has got a feel there is some routing missing [22:42:54 CEST] <durandal_1707> realies: nope [22:43:14 CEST] <durandal_1707> add adaptive_noise_learn=1 option [22:52:52 CEST] <kingsley> I'm considering buying a new computer with more CPU cores to render video faster in to the .webm format. I wonder if passing the unusual options "-threads 1" and "-row-mt 1" to ffmpeg speeds it up by more than the 3X of one CPU core I'm told is otherwise possible. If you happen to share my curiousity, and already have a computer with more CPU cores than me (2), feel free to bench mark the following command on various numbers of CPU cores [22:52:52 CEST] <kingsley> and post your results! [22:53:15 CEST] <kingsley> $ ffmpeg -y -f lavfi -i mandelbrot=s=1920x1080 -threads 1 -row-mt 1 -frames 50 -c:v libvpx /tmp/bench.webm [22:54:47 CEST] <kingsley> For your convenience, I posted a script that automates bench marking pretty much any command you want on 1 of your CPU cores, 2 cores, 3, etc... all the way up to how many you have. [22:54:52 CEST] <kingsley> It's at [22:54:55 CEST] <kingsley> http://loaner.com/how_fast_do_various_numbers_of_cores_run [22:55:44 CEST] <kingsley> For example, to bench mark how well libvpx's "-threads 1" and "-row-mt 1" options speed up ffmpeg, you could do [22:55:52 CEST] <kingsley> $ how_fast_do_various_numbers_of_cores_run "ffmpeg -y -f lavfi -i mandelbrot=s=1920x1080 -threads 1 -row-mt 1 -frames 50 -c:v libvpx /tmp/bench.webm" [22:59:05 CEST] <realies> durandal_1707, that made it work, seems that video demonstrates a lot better results than what I can get [22:59:32 CEST] <realies> perhaps the plugin has been calibrated to the background noise beforehand [22:59:33 CEST] <durandal_1707> realies: you need to carefully pick options [22:59:47 CEST] <durandal_1707> also what is your input? [23:00:13 CEST] <realies> a voice mp3 with minimal background noise [23:00:41 CEST] <realies> why? [23:02:18 CEST] <durandal_1707> sample rate? [23:03:36 CEST] <realies> 44100 [23:08:54 CEST] <durandal_1707> what kind of noise? white noise? [00:00:00 CEST] --- Sat Oct 26 2019

1 0

ffmpeg-devel.log.20191024
by burek 25 Oct '19

25 Oct '19

[02:36:01 CEST] <philipl> jkqxz: https://github.com/philipl/FFmpeg/pull/1/files [02:36:05 CEST] <philipl> Lynne: That should be it [02:36:15 CEST] <philipl> I'll squash and reorganise the commits if we're all happy [02:38:56 CEST] <Lynne> philipl: I'm fine with it, squash them into something that makes sense so I can finish it up and submit it [04:59:22 CEST] <philipl> Lynne: changes squashed [05:13:55 CEST] <mkver> Can actually any contributor get access to FFmpeg's coverity reports or is this restricted like the security ML that Paul wanted access to? [05:18:13 CEST] <jamrial> it's restricted, but i don't think the security ml alias is related to it [05:49:54 CEST] <mkver> Thanks for the answer. I now applied for Coverity access. [08:33:17 CEST] <nevcairiel> coverity is not open to the public, but any contributor that requested access usually got it [14:01:18 CEST] <durandal_1707> ubitux: i did it, seems not much impact performance [14:01:51 CEST] <ubitux> cool, good news, and thanks\ [16:14:38 CEST] <cehoyos> durandal_1707: interplay mixes width and linesize but I don't see where exactly [16:21:43 CEST] <durandal_1707> cehoyos: yes, i know that already [20:16:12 CEST] <cone-304> ffmpeg 03Andreas Rheinhardt 07master:c36eae65e488: avformat/mpeg: Add padding to extradata [20:16:12 CEST] <cone-304> ffmpeg 03Andreas Rheinhardt 07master:f53525d24863: avformat/aiffenc: Use better error codes [20:16:13 CEST] <cone-304> ffmpeg 03Andreas Rheinhardt 07master:3d5d0301c3d8: avformat/icoenc: Add deinit function [20:16:14 CEST] <cone-304> ffmpeg 03Ramiro Polla 07master:531fbce0b281: mpegvideo_enc: add intra_penalty option for p frames [20:47:18 CEST] <durandal_1707> jamrial: libavformat/mpeg.c:892:9: warning: variable 'header_str' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] [20:51:49 CEST] <cone-304> ffmpeg 03Andreas Rheinhardt 07master:262eef6b899c: avformat/mpeg: Don't free unintialized pointer [20:51:52 CEST] <jamrial> durandal_1707: ^ [20:54:43 CEST] <durandal_1707> nice [20:56:40 CEST] <cone-304> ffmpeg 03Paul B Mahol 07master:f166951d6e32: avfilter: add maskedmin/maskedmax filters [20:56:46 CEST] <JEEB> oh wow [20:57:08 CEST] <JEEB> someone at a conf noted that the FFmpeg HEVC decoder was fast [20:57:17 CEST] <nevcairiel> in comparison to..? :D [20:57:19 CEST] <JEEB> or well, fast enough for their use case :) [20:57:27 CEST] <nevcairiel> its not so bad [20:57:38 CEST] <nevcairiel> its just not that optimized as many others [20:57:43 CEST] <JEEB> yea [20:57:57 CEST] <JEEB> I need to thank the guy because generally people just see its slowness and complan [20:58:25 CEST] <durandal_1707> yes, people using potato [21:00:00 CEST] <cone-304> ffmpeg 03Paul B Mahol 07master:9bf5e7992f03: avcodec/interplayvideo: cosmetics [21:08:04 CEST] <durandal_1707> michaelni: why interplay video decoder misbehaves when stride is not aligned to 32 but to 64? [21:08:25 CEST] <durandal_1707> see #7945 [21:18:00 CEST] <michaelni> durandal_1707, i guess something in the decoder assumes stride has a particular value, accessing pixels beyond or such. But thats a guess [21:20:30 CEST] <durandal_1707> michaelni: i changed % / part to use width instead of linesize, but even that it does not work [21:43:20 CEST] <cone-304> ffmpeg 03Paul B Mahol 07master:37d8ae9da8ac: doc/filters: fix another typo [00:00:00 CEST] --- Fri Oct 25 2019

1 0

ffmpeg.log.20191024
by burek 25 Oct '19

25 Oct '19

[01:50:26 CEST] <DanielTheFox> Hello, has anybody ever written a pal8 colorspace encoder for ffmpeg? [01:50:59 CEST] <DanielTheFox> (as far as I know, ffmpeg official sources/builds don't output pal8, although they can read and decode it) [01:55:47 CEST] <JEEB> do you mean something specific with "encoder" [01:56:30 CEST] <JEEB> since pal8 is a pixel format, not video format [02:02:28 CEST] <Reinhilde> when recording to a YouTube RTMP stream, after around 7 hours the encoder goes from 15fps (the -f x11grab input framerate) to 4.5 fps (less than a third the rate). [02:05:57 CEST] <DanielTheFox> JEEB: a pixel format, actually [02:06:14 CEST] <DanielTheFox> normally, ffmpeg can read pal8 [02:06:17 CEST] <DanielTheFox> but can't write it [02:06:41 CEST] <pink_mist> can't it? shouldn't it just be a matter of specifying -pix_fmt pal8 or somesuch? [02:06:50 CEST] <DanielTheFox> has somebody been able to build or write an ffmpeg able to encode/write/output pal8 pixel format? [02:06:57 CEST] <pink_mist> assuming the format you're encoding to supports it [02:07:53 CEST] <DanielTheFox> pink_mist: if you execute ffmpeg -pix_fmts, you'll notice pal8 exists, but only input is supported [02:07:53 CEST] <DanielTheFox> I..P. pal8 1 8 [02:07:53 CEST] <DanielTheFox> there's I, but not O [02:08:16 CEST] <pink_mist> I see [02:08:19 CEST] <pink_mist> bummer [02:08:52 CEST] <DanielTheFox> yeah, that's why I'm asking if someone has ever seen anything (even if unsupported/unofficial) able to output pal8 pixel format [02:10:54 CEST] <Reinhilde> what would cause monotonically declining framerate over time? [02:13:37 CEST] <JEEB> DanielTheFox: wouldn't be surprised if it works by converting from paletted to normal rgb or just taking in pal8 in the video encoder since I don't remember if pal8 has the palette in there as well... [02:14:42 CEST] <JEEB> like gif, i think it generates a palette from rgb input if i recall it correctly [04:27:54 CEST] <kingsley> Do you happen to have any good advice for how to render faster on a computer with many cores with ffmpeg, or better yet, with melt, and ideally, kdenlive? [04:49:13 CEST] <kepstin> doesn't the palettegen/paletteuse filter set let you convert to pal8? [04:52:05 CEST] Action: kepstin confirms that yes it does. [05:31:20 CEST] <causasui> I have a video clip I'd like to turn into an infinite loop. I dont know the word for it. Basically take the video, reverse it, and then appened the reversed version onto the original. I've been googling this like mad and ffmpeg is hard. anyone who can help? [05:31:36 CEST] <causasui> example: this https://media.giphy.com/media/LXfS9EGAqBI2PIo9la/giphy.gif becomes this https://i.imgur.com/wirhoyF.mp4 [05:43:22 CEST] <cptnoblivious> Not sure what I'm looking at in those examples. I've used something like this "ffmpeg -i "input.webm" -filter_complex "[0]reverse[r];[0][r]concat" -c:v libvpx -crf 4 -b:v 3000K -an "output.webm"" for foward/reverse loops [06:00:43 CEST] <causasui> cptnoblivious: the second one is the first one except it has a loop back to the beginning. note it's precisely twice as long. anyway I'll try that, thanks [06:01:34 CEST] <cptnoblivious> Ah I see. Yeah that should do it [08:32:57 CEST] <Shezi> What are the side effects of setting -max_muxing_queue_size too high? [08:34:23 CEST] <Shezi> We are getting issues like "Too many packets buffered for output...", setting this to in range between 1024 .... 9999 solves the problem. But what are the possible side effects if we are setting it manually to high value? [08:35:44 CEST] <JEEB> memory usage and possibly the issues due to the packets ssuddenly sluuurpsing out at once if your thing requires stable output [08:36:26 CEST] <JEEB> i would rather attempt to see wjy ffmpeg.c decides it needs to buffer [10:54:09 CEST] <Shezi> Sorry JEEB got disconnected. Memory usage is not an issue for us but "packets suddenly sluuurpsing" I didn't get this point. About ffmpeg decision what it needs to buffer is causing the "Too many packets buffered for output" issue. [10:54:16 CEST] <Shezi> Its in some videos, not all. [12:28:44 CEST] <zamba> i want to continously read in .ts files and stream these as audio to an icecast server [12:28:48 CEST] <zamba> can ffmpeg handle this? [19:42:52 CEST] <void09> how to tell ffmpeg to respect Display aspect ratio set in the .mkv header when taking a screenshot ? [19:42:56 CEST] <void09> snapshot* [20:23:20 CEST] <DanielTheFox> How do I set ffmpeg to insert keyframes each X frames? [20:24:10 CEST] <DanielTheFox> When I encode using MSV1, apparently (by default) they're one each 25 frames, I guess they're necessary for proper video seeking, but I feel like I'm going to sacrifice that and see what happens... [20:28:51 CEST] <realies> Why do you have to specify a URI with the lv2 filter? Can't you just use something locally? [20:33:21 CEST] <durandal_1707> realies: lv2 works that way [20:33:52 CEST] <durandal_1707> and plugins are installed locally... [20:38:21 CEST] <realies> oh [20:39:11 CEST] <realies> docs example has a URL it seems lv2=p=http\\\\://calf.sourceforge.net/plugins/BassEnhancer:c=amount=2 [20:40:18 CEST] <durandal_1707> that is not URL [20:40:30 CEST] <durandal_1707> nothing is fetched from net [20:40:51 CEST] <DanielTheFox> no proper http:// is present [20:41:07 CEST] <durandal_1707> run lv2ls if you have it, you will see it [20:41:17 CEST] <durandal_1707> DanielTheFox: but no net is used.... [20:41:30 CEST] <DanielTheFox> cool [20:41:55 CEST] Action: DanielTheFox keeps scanning the entire ffmpeg-all manpage looking for keyframe interval manipulation [20:42:20 CEST] <durandal_1707> that is called gop code [20:43:19 CEST] <durandal_1707> -g is option [20:44:04 CEST] <DanielTheFox> ok [20:44:17 CEST] <DanielTheFox> what is -keyint_min then? [20:44:25 CEST] <DanielTheFox> something for variable GOP, I guess... [21:14:10 CEST] <void09> how to tell ffmpeg to respect Display aspect ratio set in the .mkv header when taking a snapshot ? [21:42:10 CEST] <kepstin> void09: ffmpeg doesn't have any functionality to "take a snapshot", what are you doing? [21:42:29 CEST] <kepstin> (i'm pretty sure mpv, for example, does support correcting aspect ratio when taking snapshots) [21:43:26 CEST] <kepstin> if by "taking snapshot" you mean "re-encoding a single frame from an input video to an output image", then it's up to you to write a scale filter to adjust the image size if desired. [21:43:28 CEST] <void09> kepstin: it does, -vframes 1 -q:v 2 whatever.png [21:44:16 CEST] <void09> yes, I was just going to do that, use the mediainfo provided value to scale it.. [21:44:53 CEST] <kepstin> scale filter has all the info available in variables, so you can write an expression in the scale filter to do it if you don't know the size/sar in advance. [21:45:17 CEST] <void09> how :? [21:47:15 CEST] <kepstin> depends exactly how you want to do the correction, but there's an example in the docs that scales width (preserves height). [21:47:32 CEST] <kepstin> if you want to do it by always making the video bigger, it's a bit more work to add the conditionals [21:48:37 CEST] <void09> well, I want it to read the display width height values from the mkv, and scale to that (1080p video scaled to 4:3 for example) [21:49:54 CEST] <kepstin> well, if you have, say, a 1920x1080 video which you want to be snapshot at 4:3, do you want that image to be 1440x1080 or 1920x1440? [21:50:13 CEST] <kepstin> either gotta squish it or stretch it :) [21:50:27 CEST] <void09> squish it [21:51:05 CEST] <void09> yeah, keep the height [21:51:08 CEST] <kepstin> then the example in the docs will work for you, it keeps the same height and scales the width [21:51:26 CEST] <void09> what should i google? [21:51:58 CEST] <kepstin> you google https://www.ffmpeg.org/ [21:52:33 CEST] <kepstin> then click on Documentation, then Filters under the Components header, then the scale video filter [21:53:33 CEST] <kepstin> you want the "Make pixels square..." example. [21:58:05 CEST] <void09> pixels are already square in the source video [21:58:09 CEST] <void09> internally [21:58:29 CEST] <void09> the video is just stretched horizontally, and i want it to display at the original AR which is 4:3 [22:09:29 CEST] <void09> hmm or maybe not. just took a snapshot with mpv, which plays by the DAR, and the image is 1920x1440 [22:10:04 CEST] <void09> so I guess it kep the width, and stretched the height ;o [22:10:26 CEST] <void09> a bit counter intuitive for me, any idea why it would do this ? [22:15:19 CEST] <kepstin> mpv by default always makes the video to correct sar [22:15:42 CEST] <kepstin> so if the sar >1, it'll correct it by scaling wider, if sar <1, it'll correct it by making it taller [22:15:53 CEST] <kepstin> always makes the video bigger* [22:17:00 CEST] <void09> but this is about dar, not sar [22:17:12 CEST] <kepstin> sar and dar are related [22:17:59 CEST] <kepstin> sar * (pixel width / pixel height) = dar [22:18:04 CEST] <void09> interesting. I would have thought it's best to squeeze the pixels in width [22:18:20 CEST] <kepstin> that would potentially lose detail [22:18:58 CEST] <void09> lose detail, but no artefacts with stretching ? [22:19:08 CEST] <kepstin> if you have "square pixels", that means that (pixel width / pixel height) = dar [22:19:36 CEST] <kepstin> in other words, sar = 1 [22:21:19 CEST] <kepstin> sar is more commonly used than dar when working on video, because sar remains constant when you do things like crop video, when dar changes. [22:21:37 CEST] <kepstin> but you can calculate one from the other if you know the video size in pixels. [22:55:05 CEST] <kingsley> Do you happen to have any good advice for how to render the .webm format faster by using many cores with ffmpeg, or better yet, with melt, and ideally, kdenlive? [22:55:52 CEST] <kepstin> kingsley: make sure you use vp9, not vp8. make sure you are using a recent version of libvpx. use the '-row-mt 1' option. Set '-threads', by default it only uses 1. [22:58:57 CEST] <kepstin> hmm. the xstack filter could really use some documentation on what happens if items overlap, and what is displayed in places not covered by an image. [22:59:21 CEST] <kingsley> kepstin: I'm researching your speed up suggestions... [22:59:23 CEST] <kepstin> (the answers appear to be "later inputs draw over earlier ones" and "uninitialized data") [23:09:30 CEST] <void09> kepstin: seems I have 2 possible cases, one with SAR = 1 but DAR not 1; and SAR not 1 (DAR is calculated from SAR) - like dvds [23:09:45 CEST] <void09> is ther a scale parameter that would work for both of these ? [23:10:09 CEST] <void09> example 1: 1920x1080 video, sar=1, dar=1.333 (4:3) [23:10:31 CEST] <kepstin> That makes no sense [23:10:38 CEST] <void09> example 2: 720x554 video, SAR 1.422 => DAR 1.85:1 [23:11:22 CEST] <void09> so in the first case i'd get a 1,920px × 1,440px snapshot [23:12:18 CEST] <void09> and the second example would result in a 1024x554 snapshot [23:12:36 CEST] <void09> what does not make sense ? [23:13:16 CEST] <kepstin> 1920x1080 with sar=1 has dar=16/9 [23:14:27 CEST] <void09> kepstin: yes, but the dar is set manually to 4/3 cause the video is actually stretched (and appears normal only if resized to 4/3) [23:14:36 CEST] <kepstin> 1920x1080 with dar=4/3 means sar=3/4 [23:14:48 CEST] <void09> it's a tv recording with 16:9 AR of a 4:3 movie [23:14:58 CEST] <void09> with no black bars [23:15:54 CEST] <void09> kepstin: sar is 1, only dvds (from what I found so far) have non 1 sar [23:16:06 CEST] <void09> anamorphic dvds [23:17:27 CEST] <void09> so basically i want ffmpeg to take the same kind of snapshot mpv would [23:17:48 CEST] <void09> without having to write logic oustide ffmpeg [23:26:11 CEST] <void09> or maybe i should just use mpv to take snapnshots [23:26:22 CEST] <kepstin> If your 1920x1080 video has a sar of 1, it would display as 16/9. [23:26:49 CEST] <kepstin> Anyways, ffmpeg can do that, just need some conditionals in the filter expression [23:27:33 CEST] <void09> kepstin: it displays as 4:3, since i edited the mkv header and changed dispay width/height to 4 and 3 [23:28:37 CEST] <kingsley> kepstin: My limited research results suggest the "-row-mt 1" option to the libvpx .webm encoder spreads .webm rendering across multiple cores, and thus is faster. Thank you. If you happen to have the time, and it would be convenient, comfortable, and all those good things, I'd be happy to receive any further thoughts you care to share on: [23:29:13 CEST] <kingsley> 1.) How recent of a version of libvpx should one use to render faster with multiple cores? [23:29:29 CEST] <kingsley> 2.) Is it possible to specify both [23:29:44 CEST] <kingsley> 2a.) "-row-mt 1" and [23:29:58 CEST] <kingsley> 2b.) "-threads" [23:30:20 CEST] <kepstin> kingsley: libvpx 1.7.0 or later. ANd you need to specify *both* -row-mt and -threads [23:31:01 CEST] <kepstin> void09: when you changed the dar without changing image size, sar got recalculated [23:31:14 CEST] <kingsley> in kdenlive->render->more options->the window's data entry field that contains, by default "f=webm vcodec=libvpx acodec=libvorbis crf=%quality vb=0 quality=good aq=%audioquality max-intra-rate=1000"? [23:32:13 CEST] <void09> kepstin: oh it did ? I didn't know it works like that. Mediainfo did not display any value for sar (which means it's =1) [23:32:38 CEST] <kingsley> 3.) Are -row-mt and -threads available when libvpx is compiled for IBM' [23:32:45 CEST] <kepstin> void09: remember, sar * (pixel width / pixel height) = dar is the definition [23:33:08 CEST] <kepstin> void09: if you change dar, and pixel size stays the same, then by definition that means you changed sar [23:33:15 CEST] <kingsley> (Oops! I accidentally pressed my <enter> key...) [23:33:36 CEST] <kingsley> 3.) Are -row-mt and -threads available when libvpx is compiled for IBM's POWER9 instruction set architecture? [23:33:55 CEST] <kepstin> kingsley: I assume you mean IBM power processor? those options are independent of cpu arch. But note that libvpx is probably poorly optimized for power in general, and you'd probably be better off using x86 [23:34:12 CEST] <void09> kepstin: well isn't there a difference between anamorphic dvd >1 SAR, and just modifying DAR in a video with SAR=1 ? [23:34:28 CEST] <kingsley> kepstin: Yes, you are correct. I assumed IBM's power processor. [23:34:56 CEST] <kepstin> void09: no difference at all, really, except that different containers signal sar/dar in different ways [23:35:18 CEST] <kepstin> void09: containers have to provide any two of (sar, resolution, dar) and the other one is calculated [23:36:14 CEST] <kepstin> well, i suppose you can't provide both sar and dar and no resolution [23:36:30 CEST] <kepstin> so containers have to provide either (sar, resolution) or (dar, resolution) and the missing sar or dar is calculated [23:37:14 CEST] <kingsley> kepstin: Yes, I agree with your astute observation that video encoders are often poorly optimized for IBM's power. As a practical matter, at least without -row-mt and -threads, my humble script at [23:38:05 CEST] <kingsley> http://loaner.com/how_fast_do_various_numbers_of_cores_run [23:39:15 CEST] <kingsley> suggests encoding .webm with a single thread on POWER9, with its current lack of optimization, is about as fast as a 13 year old x86. [23:39:49 CEST] <kepstin> even with -row-mt, which helps a lot, libvpx doesn't scale super well with larger number of threads [23:40:07 CEST] <kepstin> void09: -vf 'setsar=2,scale=w=trunc(if(gte(sar\,1)\,iw*sar\,iw)/hsub)*hsub:h=trunc(if(gte(sar\,1)\,ih\,ih/sar)/vsub)*vsub,setsar=1' [23:40:15 CEST] <kepstin> void09: should replicate mpv's behaviour [23:40:43 CEST] <void09> ;o [23:40:54 CEST] Action: pink_mist would just use mpv [23:41:08 CEST] <void09> i just realized mpv has no static build for linux [23:41:12 CEST] <void09> so probably no go [23:41:16 CEST] <kepstin> if you have the video open in mpv anyways to find the right time, especially [23:42:11 CEST] <kingsley> Maybe I'll ask in the #talos-workstation channel if someone could test ffmpeg with -row-mt and -threads with my humble little script and report how well render times scale with cores. I think it'd be great to find a faster way to render video on hardware that respects your privacy (POWER9 (no Intel Management Engine)). [23:42:48 CEST] <kepstin> oh, hmm, i made a mistake, that should be 'ohsub' and 'ovsub' anywhere it says 'hsub' and 'vsub' :) [23:43:13 CEST] <kepstin> so -vf 'setsar=2,scale=w=trunc(if(gte(sar\,1)\,iw*sar\,iw)/ohsub)*ohsub:h=trunc(if(gte(sar\,1)\,ih\,ih/sar)/ovsub)*ovsub,setsar=1' [23:44:56 CEST] <kepstin> maybe i should make a pr to add that to the docs, since it's probably pretty generally useful. [23:45:55 CEST] <void09> of course it is ! [23:56:41 CEST] <void09> kepstin: kinda works, 1440x554 png though, instead of the epxected 1024x554 for a wide screen dvd [23:58:55 CEST] <void09> and 3840 x 1080 for the 1920x1080 to 1920 x 1440 one :\ [23:59:10 CEST] <void09> but let me check again from the command line, maybe there's a bug in my script [00:00:00 CEST] --- Fri Oct 25 2019

1 0

ffmpeg-devel.log.20191023
by burek 24 Oct '19

24 Oct '19

[00:28:16 CEST] <taliho> :jamrial is it acceptable to add a sleep inside the internal send_frame of the encoder? [00:28:25 CEST] <BtbN> no [00:29:09 CEST] <taliho> wouldn't you have this kind of behvaviour if the encoder is working asyncrhonously? [00:29:32 CEST] <BtbN> A hard sleep? No [00:29:33 CEST] <taliho> what if there is some internal initialization time [00:29:47 CEST] <BtbN> That's what the init function is for [00:30:08 CEST] <BtbN> But I can't think of any situation where sleeping in a hot function is ever acceptable [00:30:19 CEST] <BtbN> Or really, ANY function in an encoder/decoder [00:30:38 CEST] <taliho> ok [00:31:41 CEST] <philipl> BtbN: These boards have the normal nvdec/nvenc hardware, but for them, nvidia are using completely different software. They don't release an equivalent of the desktop drivers. Instead they have these v4l2m2m drivers... [00:31:45 CEST] <philipl> It's silly. [00:32:08 CEST] <BtbN> Yeah, and from the sounds of it, the driver is pretty hot garbage as well. [00:32:14 CEST] <philipl> yes. [00:32:48 CEST] <philipl> the kernel part is open-source hot garbage though. [00:32:50 CEST] <taliho> in their sample code, they deque the compressed packets in a separate thread [00:35:44 CEST] <taliho> in our code, we send a frame and then deque packets in the same thread. so I feel if the encoder is working in asynchronously it may return EAGAIN if the device is busy [00:40:37 CEST] <BtbN> Why would it ever return EAGAIN after you took all frames out of it that are in there? [00:40:47 CEST] <BtbN> When sending in new ones [00:44:04 CEST] <taliho> in the send_frame call you check, are there any buffers to push this frame. if there is you push the frame. otherwise it returns EAGAIN [00:44:36 CEST] <taliho> you only take out the frames from the buffers in the send_frame call [00:47:21 CEST] <taliho> in the avcodec_receive_packet call you remove compressed packets from a different buffer on the hardware device [04:43:54 CEST] <taliho> :jamrial :BtbN to follow on send_frame returning EAGAIN... I suspect this was a bug in our v4l2_m2m code [04:45:36 CEST] <taliho> some initialization code is being done after the first frame has been sent to the nano [04:46:26 CEST] <taliho> in receive_packet [04:50:31 CEST] <taliho> moving this code to init so that it's called before send_frame solves the problem [04:53:40 CEST] <jamrial> cool [09:32:52 CEST] <cone-199> ffmpeg 03Paul B Mahol 07master:dd239bdb65c6: avfilter/vf_vaguedenoiser: add more gray formats [09:40:59 CEST] <cone-199> ffmpeg 03Paul B Mahol 07master:1f327f5d277c: avfilter/vf_bm3d: add gray14 format [09:45:55 CEST] <cone-199> ffmpeg 03Paul B Mahol 07master:7832e05c35ee: avfilter/vf_lut2: fix typo, correctly support gray14 [09:50:43 CEST] <cone-199> ffmpeg 03Jun Zhao 07master:0e3d5bdc0802: lavfi/bilateral: Clean the option description and unused code [09:55:26 CEST] <cone-199> ffmpeg 03Paul B Mahol 07master:ba7d55d3fc98: avfilter/vf_deband: add more gray formats [10:22:57 CEST] <cone-199> ffmpeg 03Paul B Mahol 07master:1cdc805228c7: avfilter/vf_floodfill: add more gray formats [10:22:59 CEST] <cone-199> ffmpeg 03Paul B Mahol 07master:8732eb124e56: avfilter/vf_floodfill: better fix for crash [12:41:36 CEST] <cone-199> ffmpeg 03Paul B Mahol 07master:7df808ea8443: avfilter/settb: switch to activate [14:59:40 CEST] <cone-199> ffmpeg 03Zhao Zhili 07master:eafc8afafcd6: avcodec/tests: add h265_levels to .gitignore [14:59:41 CEST] <cone-199> ffmpeg 03Zhao Zhili 07master:11cfff04eda7: FATE/dnn: add .gitignore [17:14:41 CEST] <taliho> anyone know if Marton is on irc? [17:18:28 CEST] <durandal_1707> jamrial: have any more comments to latest clamp patch? [17:27:19 CEST] <jamrial> durandal_1707: no [17:43:49 CEST] <cone-199> ffmpeg 03Paul B Mahol 07master:ac0f5f4c1717: avfilter/vf_maskedclamp: add x86 SIMD [18:41:21 CEST] <durandal_1707> ubitux: found 144x144x144 cube file in the wild [18:41:48 CEST] <ubitux> that's unfortunate [18:42:08 CEST] <ubitux> downsample it to our max size and no one will notic [18:42:10 CEST] <ubitux> +e [18:58:39 CEST] <durandal_1707> ubitux: its just 10mb more [19:07:36 CEST] <taliho> :jamrial http://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/252020.html [19:07:49 CEST] <taliho> would appreciate if you could have a look when you have some time [19:22:19 CEST] <durandal_1707> Lynne: what's status of vulkan and its filters? are you still working on it? [19:24:37 CEST] <Lynne> waiting on jkqxz to okay the cuda interop [19:40:47 CEST] <taliho> :jamrial thanks [19:51:31 CEST] <philipl> jkqxz: https://github.com/philipl/FFmpeg/pull/1/files [19:51:49 CEST] <philipl> That's after addressing all the last feedback. The git history is a mess, but I will squash and adjust once it's finalised. [19:56:06 CEST] <jkqxz> "if (src->hw_frames_ctx && dst->hw_frames_ctx) {" is true in the sw-map + upload to other device case (because the mapped sw frame has an associated hw_frames_ctx to keep track of the mapping). [19:56:31 CEST] <jkqxz> Similarly downloading from one device to a frame mapped from another device. [20:01:22 CEST] <philipl> That's why I added the additional checks on source_frames [20:01:40 CEST] <philipl> Did I not achieve the result I wanted? [20:02:00 CEST] <philipl> it should reject transfers if either src or dst is a derived frame context, meaning mapped frames. Yes? [20:08:02 CEST] <philipl> jkqxz: ^ [20:11:45 CEST] <ubitux> durandal_1707: at this point we probably want to allocate dynamically according to the input [20:12:46 CEST] <durandal_1707> ubitux: but that will make filtering much slower [20:13:32 CEST] <ubitux> it's already on the heap, i'm just asking to make that alloc conditional on the input [20:13:54 CEST] <ubitux> one heap alloc of N*N*N, but with N from the input instead of harcoded [20:16:52 CEST] <durandal_1707> as alreay said, can not be done without making filter significally slower, try it [20:17:05 CEST] <durandal_1707> otherwise i would do it already [20:26:41 CEST] <jkqxz> philipl: But it should be able to upload them using the SW transfer on the other context. [20:49:02 CEST] <jkqxz> Hmm, no. I'm confusing it with the hw_frames_ctx carried through AVFilterLinks. The frame itself carries it in the HWMapDescriptor, so it doesn't interfere. [21:08:45 CEST] <philipl> jkqxz: I'm not sure what the conclusion of your line of thinking is. :-) I'd at least start with establishing if the logic I wrote is safe. And if there are scenarios where a frame from a derived context can be used, we could add support for it. Given the specific devices we support and the mapping and transfer combinations we support, I don't think any real case exists. [21:10:40 CEST] <jkqxz> The case I was thinking of (single-copy cross-device via sw-mapping) is not a problem. [21:11:08 CEST] <jkqxz> (For example: "./ffmpeg_g -y -init_hw_device vaapi:/dev/dri/renderD129 -init_hw_device vaapi:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_device vaapi0 -hwaccel_output_format vaapi -i in.mp4 -an -filter_hw_device vaapi1 -vf 'hwdownload,format=nv12,hwmap=mode=write+overwrite+direct:reverse=1' -c:v h264_vaapi out.mp4".) [21:13:18 CEST] <philipl> OK. [21:15:28 CEST] <jkqxz> doc/errno.txt suggests that ENOTSUP is not suitable for use everywhere. [21:15:50 CEST] <philipl> OK. I can switch that to ENOSYS. [21:16:23 CEST] <philipl> ENOTSUP seemed semantically closest but we use ENOSYS in other places for it. [21:19:11 CEST] <jkqxz> Without an external query I'm not sure that transfer_data_hw_supported is doing anything any more? [21:19:54 CEST] <philipl> It's still used. [21:19:55 CEST] <jkqxz> Using the av_hwframe_map() approach of just calling the other direction function if the first one returns ENOSYS might be simpler. [21:20:09 CEST] <philipl> Fair. [21:20:16 CEST] <philipl> I can do that. [21:27:19 CEST] <jkqxz> For the doc, I'm not sure it says quite the right thing. A device /is/ required when the filter is initialised (coming directly from the user or on the inlink to derive from). [21:28:27 CEST] <jkqxz> Dunno what the right phrasing is there. [21:30:08 CEST] <jkqxz> Having thought about that more, I agree with your comment above about the derived frames contexts. [21:30:44 CEST] <jkqxz> So generic parts LGTM after that. [21:34:52 CEST] <philipl> jkqxz: thanks. I'll adjust the ENOSYS and remove the transfer direction supported function. For the docs, i tried to copy the phrasing from hwmap. If I've diverged, I'll correct it. [21:41:21 CEST] <Lynne> https://paste.sr.ht/~sircmpwn/23e31a29f427066ef261b2ffa7fd9bf46530d904 [21:41:37 CEST] <Lynne> nice, gitlab started spying [21:42:21 CEST] Action: ddevault stirs [21:47:42 CEST] <ubitux> jamrial: http://coverage.ffmpeg.org/ [21:47:48 CEST] <ubitux> i think you asked me to fix that a while ago [21:48:02 CEST] <ubitux> i moved to gcovr since lcov does not seem to work anymore [21:48:06 CEST] <jamrial> ubitux: yes, awesome, thank you :D [21:48:24 CEST] <ubitux> i'll check if it still works over time [21:48:47 CEST] <ubitux> but i had to look into this for another project, and gcovr did the trick so... [21:49:38 CEST] <ubitux> this is basically the result of gcovr -r . --html-details -o foo.html after a make fate on a --toolchain=gcov build [21:49:54 CEST] <ubitux> (with debug on, and CPUFLAGS=none for the run) [21:50:56 CEST] <ubitux> we should probably add a rule in the Makefile for that (maybe i'll send a patch) and drop the old wonky lcov rules [21:51:04 CEST] <ubitux> anyway, gtg, cya [21:51:35 CEST] <jamrial> later [00:00:00 CEST] --- Thu Oct 24 2019

1 0

ffmpeg.log.20191023
by burek 24 Oct '19

24 Oct '19

[05:34:29 CEST] <MoziM> are there changes in opencv4 that make it unsafe to add to ffmpeg's configure file? [06:41:45 CEST] <Diag> Simple question, assuming i have hdyc coming in, whats the best color space to convert to for playback on rgb screens [07:03:21 CEST] <kingsley> Do you happen to know of a command line option that limits how many cores ffmpeg uses to render .webm? [07:03:36 CEST] <kingsley> I tried [07:03:42 CEST] <kingsley> -threads [07:03:57 CEST] <kingsley> -filter_threads and [07:04:15 CEST] <kingsley> -filter_complex_threads [07:05:09 CEST] <kingsley> but they all seem to me to use every CPU core available. [08:01:59 CEST] <MoziM> cpulimit -l 50 -v ffmpeg.... [09:10:51 CEST] <YellowOnion> my ffmpeg consistently stops working after 35mins of streaming to a rtmp, "Non-monotonous DTS in output stream 0:0; previous: 2147423, current: -2147484; changing to 2147423" [09:32:30 CEST] <YellowOnion> I think it's the concat filter causing this issue.... [09:33:20 CEST] <durandal_1707> no, your input have bad timestamps [09:38:54 CEST] <YellowOnion> no it's concat filter, it's fine without it. [09:39:05 CEST] <YellowOnion> doesn't matter what the input file is. [10:14:03 CEST] <durandal_1707> YellowOnion: your bug report is invalid [10:15:53 CEST] <YellowOnion> durandal_1707, the log file is 17MB what am I supposed to do with it. [17:56:02 CEST] <dmsilva> Hi, we are currently using ffmpeg 4.0.4 and would like to mitigate the vulnerability mentionned here https://nvd.nist.gov/vuln/detail/CVE-2019-17539.Is applying the commit here https://github.com/FFmpeg/FFmpeg/commit/8df6884832ec413cf032dfaa45c23b1c787… to the ffmpeg version I am using is sufficient? [17:57:52 CEST] <dmsilva> I messed up the link for the CVE. here it is: https://nvd.nist.gov/vuln/detail/CVE-2019-17539 [17:59:22 CEST] <sc_> hello, can someone explain the reason ffmpeg relies on unbound? [18:04:58 CEST] <kepstin> sc_: it doesn't, but certain uses of ffmpeg might need the ability to resolve dns, however your os is set up to do that [18:05:51 CEST] <DHE> or it may use some 3rd party library that itself uses unbound [18:07:08 CEST] <sc_> thanks, I found it odd homebrew ffmpeg listed it as a dependency... [19:56:56 CEST] <phobosoph> So my hikvision webcam streams in yuvj420p. [19:57:07 CEST] <phobosoph> Is there an option to let it stream in yuv420p? [19:57:11 CEST] <phobosoph> Is there a difference anyway? [19:57:22 CEST] <phobosoph> I stream yuvj420p to youtube and I don't notice any oddities [19:57:38 CEST] <phobosoph> do colours look better with yuv420p? is it more compatible? [19:57:39 CEST] <phobosoph> :) [20:00:16 CEST] <klaxa> yuv420p has more colors than yuvj420p iirc [20:00:46 CEST] <klaxa> ah, the other way around [20:00:51 CEST] <klaxa> https://wiki.videolan.org/YUV#J420 [20:18:17 CEST] <kepstin> phobosoph: the only problem is that iirc browsers don't support yuvj420p playback in general, so the videos might appear overly-contrasty, with loss of detail in shadows/highlights [21:28:46 CEST] <phobosoph> kepstin: can I somehow simulate this? so I can see the difference? [21:30:04 CEST] <phobosoph> frame=66455 fps= 11 q=-1.0 size= 1665277kB time=00:36:55.18 bitrate=6158.4kbits/s speed=0.37x [21:30:05 CEST] <phobosoph> oh no [21:30:12 CEST] <phobosoph> why is the speed going down, again? :( [21:31:14 CEST] <phobosoph> https://pastebin.com/9WRV3AZv [21:31:18 CEST] <phobosoph> that's the ffmpeg command used [21:31:23 CEST] <phobosoph> I don't see anything wrong with it :/ [21:34:25 CEST] <kepstin> phobosoph: your first task is to rule out network or cpu bottlenecks. [21:38:46 CEST] <phobosoph> kepstin: right, how can I do that? :/ [21:38:48 CEST] <phobosoph> speedtest? [21:48:50 CEST] <phobosoph> hmmm [21:49:02 CEST] <phobosoph> kepstin: is the command in the nopaste link looking good? [21:50:21 CEST] <kepstin> nothing obviously wrong, which is why the issue is most likely due to external circumstances. [21:50:47 CEST] <phobosoph> I see [21:50:49 CEST] <phobosoph> thanks [21:50:50 CEST] <phobosoph> :/ [21:50:58 CEST] <phobosoph> thing is that ffmpeg happily sends the data [21:51:03 CEST] <phobosoph> usually with 1x speed [21:51:07 CEST] <phobosoph> I am also using the newest ffmpeg [21:53:02 CEST] <phobosoph> "RTP H.264 NAL unit type 25 is not implemented." [21:53:05 CEST] <phobosoph> but it still works [22:08:19 CEST] <jokoon> Is there a standard to store metadata in a video file, like an image? I'm thinking about storing a thumb atlas to display on the video progress bar... [22:08:38 CEST] <jokoon> apparently it would be expensive to do it when you open a video file with videolan for example [22:09:32 CEST] <jokoon> what do video website do for this? I guess ffmpeg already does generate previews? [22:21:36 CEST] <DHE> youtube has their own custom player, and they are the video source, so they make their own thumbnails [22:32:19 CEST] <jokoon> yeah but other web video solution might use ffmpeg [22:35:03 CEST] <furq> obviously you can use ffmpeg (or anything) to generate them, but their player and frontend is all custom [22:40:56 CEST] <jokoon> what else can you tell me about their tools? [00:00:00 CEST] --- Thu Oct 24 2019

1 0

ffmpeg-devel.log.20191022
by burek 23 Oct '19

23 Oct '19

[01:36:48 CEST] <cone-221> ffmpeg 03Andreas Rheinhardt 07master:982a98a0e341: avformat/matroskaenc: Fix memleak upon failure [01:36:49 CEST] <cone-221> ffmpeg 03Andreas Rheinhardt 07master:7797fdfe6f33: avformat/matroskaenc: Use ffio_free_dyn_buf [02:16:20 CEST] <cone-221> ffmpeg 03Andreas Rheinhardt 07master:65ef74f74900: avformat/matroskaenc: Move track-related fields to mkv_track [02:16:21 CEST] <cone-221> ffmpeg 03Andreas Rheinhardt 07master:b4e36df74faf: avformat/matroskaenc: Remove redundant assert [02:16:22 CEST] <cone-221> ffmpeg 03Andreas Rheinhardt 07master:c486fe206eac: avformat/matroskaenc: Use more appropriate function name [02:16:23 CEST] <cone-221> ffmpeg 03Andreas Rheinhardt 07master:74cafb0e6f3c: avformat/matroskaenc: Cosmetics [05:20:36 CEST] <cone-217> ffmpeg 03Steven Liu 07master:d92b2296f854: avformat/segafilmenc: remove unneeded code [05:20:36 CEST] <cone-217> ffmpeg 03Steven Liu 07master:36ed8ae52cb7: avcodec/hevcdec: remove unneeded code [05:20:36 CEST] <cone-217> ffmpeg 03Steven Liu 07master:388e1fc9b5be: avcodec/psd: remove unneeded code [05:20:36 CEST] <cone-217> ffmpeg 03Steven Liu 07master:0b8956b25c2c: avformat/mpeg: move the header_str free into end label [10:40:10 CEST] <cone-950> ffmpeg 03Paul B Mahol 07master:5561a1de90cd: avfilter/vf_premultiply: fix signed integer overflow [11:45:38 CEST] <durandal_1707> michaelni: if you not gonna relicense geq, i will write eval/evalsrc LGPL filters [11:57:24 CEST] <michaelni> durandal_1707, if you care so much, you can use the code i wrote in geq under LGPL but i still think its silly to change the license when noone needs it [12:00:59 CEST] <thardin> durandal_1707: michaelni is not the only author [12:01:45 CEST] <thardin> you'd have to ask marc-antoine, nicolas, clément etc also [12:03:13 CEST] <BradleyS> keyword=ask, not blackmail [12:03:22 CEST] <thardin> I also don't think we should downgrade to weaker licenses without a very good reason [12:18:09 CEST] <durandal_1707> so now i blackmail people? you called for this! [12:18:50 CEST] <BradleyS> i mean no disrespect, but that's how your first comment came off to me [12:19:04 CEST] <BradleyS> "do this or else" [12:19:26 CEST] <BradleyS> unless i missed something, you still haven't explained which company wants to use geq under lgpl [12:20:17 CEST] <durandal_1707> FFmpeg users [12:20:45 CEST] <nevcairiel> normal users can use GPL software [12:22:00 CEST] <nevcairiel> You shouldnt expect someone to agree to relicensing if you cant even explain your reason in a proper coherent sentence [12:27:46 CEST] <durandal_1707> then i will write LGPL filter, NIH! [12:45:28 CEST] <mkver> durandal_1707: After your recent patches, the transpose.h filter is no longer self-contained: http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-checkheaders&ti… [12:49:10 CEST] <durandal_1707> mkver: what you mean? [12:49:37 CEST] <mkver> The header uses uint8_t, but doesn't include the necessary header for it. [12:50:05 CEST] <durandal_1707> mkver: please send patch [15:50:12 CEST] <cone-964> ffmpeg 03James Almer 07master:78a24fd0140e: avcodec/atrac9tab: use explicit ATRAC9BlockConfig struct initializers [16:08:54 CEST] <haasn> durandal_1707: http://sofacoustics.org/data/database/ari/ how the fuck do you choose? [16:08:58 CEST] <haasn> try them all until you find one that sounds good? [16:09:54 CEST] <durandal_1707> haasn: pick ones that matches anatomy of you ears? [16:10:02 CEST] <haasn> how do I know the anatomy of my ears? [16:10:13 CEST] <durandal_1707> or just buy 7.1 speakers [16:10:34 CEST] <haasn> I'm trying to make my IEMs sound more like speakers [16:10:44 CEST] <haasn> as if the sound is coming from in front of me rather than "inside my head" [16:10:51 CEST] <durandal_1707> haasn: contact people to measure your ears [16:10:53 CEST] <haasn> hmm [16:12:10 CEST] <durandal_1707> haasn: the main issue is getting one that have back channels right [16:12:39 CEST] <haasn> back channels are irrelevant if the source is 2.0, right? [16:13:14 CEST] <durandal_1707> if your audio is stereo only use earwax joke filter [16:13:44 CEST] <haasn> interesting [16:13:50 CEST] <haasn> why 'joke'? [16:13:59 CEST] <durandal_1707> have you tried bs2b filter instead? [16:14:06 CEST] <haasn> I haven't tried anything [16:14:49 CEST] <durandal_1707> haasn: its is broken, right channel only audio will become mostly left channel audio and other way around [16:15:14 CEST] <haasn> oh [16:16:27 CEST] <durandal_1707> so try it in this order: bs2b, crossfeed, earwax and report your subjective findings to jury [16:25:24 CEST] <haasn> hmm none of those seem to make any noticeable difference [16:25:31 CEST] <haasn> except 'earwax' which makes it sound like crap [16:25:46 CEST] <haasn> I probably wouldn't be able to ABX between normal / bs2b / crossfeed [16:25:57 CEST] <haasn> so is measuring my head the only solution? [16:31:43 CEST] <durandal_1707> haasn: well, you could use sofalizer, but need to lower gain for stereo [16:34:20 CEST] <durandal_1707> and also change speaker positions from default ones [16:35:51 CEST] <BradleyS> crossfeed (if the filter mixes left and right to create less stereo separation, more mono) should work [16:36:11 CEST] <BradleyS> i suspect you can configure the amount [16:36:26 CEST] <haasn> rotation=60 should correspond to a standard triangle setup, right? [16:36:33 CEST] <haasn> i.e. steroe speakers [16:37:02 CEST] <durandal_1707> haasn: no, rotation just rotates things around [16:37:29 CEST] <durandal_1707> you need to set speakers options [16:38:19 CEST] <haasn> the documentation doesn't say what the numbers mean but judging by the example I guess for azimuth 0 is front/center and 90 is left? [16:38:27 CEST] <BradleyS> try experimenting with crossfeed strength and range [16:38:42 CEST] <durandal_1707> haasn: does demos here sounds out of your head? https://fongaudio.com/demo/ [16:39:31 CEST] <BradleyS> try strength 0.4 and range 0.25 [16:39:52 CEST] <durandal_1707> BradleyS: that is not sofalizer... [16:39:53 CEST] <BradleyS> which reduces the side channel more and lowers the frequency cutoff [16:40:15 CEST] <BradleyS> that is crossfeed [16:40:38 CEST] <durandal_1707> haasn: speakers=FL 90|FR 270 [16:40:41 CEST] <bencoh> durandal_1707: I wouldn't call that "out of my head", to be honest [16:40:45 CEST] <bencoh> (fongaudio demo) [16:41:08 CEST] <haasn> why 90 / 270? [16:41:14 CEST] <haasn> shouldn't it be 60 300 if anything [16:41:19 CEST] <BradleyS> some people find a stereo signal to be coming from the middle of their head, while others find mono that way [16:41:32 CEST] <BradleyS> if the stereo signal is what bothers, you can reduce it with crossfeed [16:41:38 CEST] <BradleyS> this is the common case [16:41:57 CEST] <haasn> A mono signal on my IEMs sounds like it's coming from the middle of my head [16:42:02 CEST] <BradleyS> sofalizer is usually used to enhance stereo wideness [16:42:07 CEST] <haasn> a mono signal on my speakers sounds like it's coming from a spot on the wall dead center between the speakers [16:42:15 CEST] <haasn> I want the latter effect but using the former [16:42:18 CEST] <haasn> Does that clarify things at all? [16:42:34 CEST] <BradleyS> yes it does, then you probably want the opposite of crossfeed, so use sofalizer or similar [16:42:51 CEST] <haasn> if I close my eyes while listening to my speakers it sounds like the entire song is coming from a range of positions spanning a line from one speaker to the other [16:43:03 CEST] <haasn> i.e. a fully FL signal will be coming from the left speaker's position [16:43:17 CEST] <haasn> with my IEMs a song sounds like it's coming from a line stretching from my left ear to my right ear [16:43:42 CEST] <BradleyS> you could also try stereotools to reduce the mid/mono signal [16:44:33 CEST] <BradleyS> stereotools=mlev=0.7 [16:44:47 CEST] <BradleyS> less is more mid signal reduction [16:45:39 CEST] <haasn> that 'out of your head' demo sounds like it's coming from further left and further right than my ears, or perhaps from slightly behind my head [16:45:50 CEST] <haasn> still not close to what I want: I want the sound to feel like it's coming from in front of me [16:46:03 CEST] <haasn> as if I had speakers in front of me rather than to either side [16:46:30 CEST] <haasn> I guess there's no way to accomplish this without measurements at the end of the day [16:46:36 CEST] <BradleyS> stereotools and stereowiden are probably only going to affect width, so you will have to play with sofalizer [16:46:49 CEST] <haasn> yeah stereo width seems irrelevant to the problem tbh [16:47:21 CEST] <BradleyS> it depends on which part of the problem you want to solve, you have two [16:47:31 CEST] <BradleyS> 1) feels like inside head 2) want in front [16:47:51 CEST] <BradleyS> most people solve 1 by adjusting the stereo wideness with crossfeed or stereowiden [16:48:22 CEST] <BradleyS> but they won't accomplish 2, that requires sinusoidal/binaural processing, so i guess you're stuck testing sofa [16:48:43 CEST] <durandal_1707> for stereo only: sofalizer=sofa=X.sofa:speakers="FL 80|FR 280":gain=-10 [16:49:37 CEST] <durandal_1707> for the exact spot in front of you, only if you do measurements [16:51:31 CEST] <BradleyS> it looks like you need to use the radius option to simulate speaker distance [16:51:50 CEST] <BradleyS> "Set distance in meters between loudspeakers and the listener with near-field HRTFs. Default is 1." [16:51:59 CEST] <ePirat> just tried the Transformers 3 demo there and it sounds absolutely awful O_O [16:52:11 CEST] <BradleyS> try 3 meters radius [16:53:49 CEST] <durandal_1707> BradleyS: that depends on measurements done... [16:53:58 CEST] <haasn> so watching the entire thing with visuals this time [16:54:03 CEST] <durandal_1707> some sofa files have only fixed distance [16:54:22 CEST] <haasn> I think it'S trying to do the right thing but while it's exceptionally good at making things sound like they're coming from behind me, it's extremely bad (for me) at making things sound like they're coming from in front [16:54:29 CEST] <haasn> (re: "out of your head" video) [16:54:48 CEST] <BradleyS> well, if he wants it more in front, distance matters [16:54:49 CEST] <bencoh> haasn: that's roughly the same for me tbh [17:04:51 CEST] <durandal_1707> haasn: issue is also when you can get front speaker from sofa, you have only L and R channel, and not Front channel, which then when summed give back in-head effect [17:04:56 CEST] <cone-964> ffmpeg 03James Almer 07master:a34d06222f12: avcodec/libdav1d: fix setting AVFrame reordered_opaque [17:05:27 CEST] <durandal_1707> so real solution is using ambisonics [17:05:59 CEST] <haasn> I also just realized, I don't want the speakers at +/- 60, I want 60° separation i.e. the speakers at 30 and 330 [17:07:01 CEST] <durandal_1707> that will give same awfull audio like earwax [17:07:15 CEST] <haasn> why? [17:07:30 CEST] <durandal_1707> it will be very monoish [17:07:43 CEST] <haasn> isn't that exactly the point? like with real speakers [17:08:13 CEST] <bencoh> haasn: I still doubt it would solve your "in-my-head line" issue [17:09:19 CEST] <haasn> the weirdest thing about sofalizer is that every sofa file I've tested just completely removes low frequencies [17:10:08 CEST] <haasn> I'm also not sure what the difference is between HRTF and DTF [17:14:37 CEST] <haasn> oh well [17:14:51 CEST] <haasn> don't feel like playing the hrtf lottery so I guess it's either measure or no solution [17:16:46 CEST] <durandal_1707> haasn: there is lfegain option just for that [17:17:01 CEST] <durandal_1707> nut it will not work for stereo only files [17:17:12 CEST] <durandal_1707> *but [17:19:28 CEST] <durandal_1707> haasn: for full experience you need to take you room measurement too, and use afir with other filters instead [17:36:59 CEST] <haasn> I use drc-fir to remove room echo anyways [17:37:12 CEST] <haasn> so in theory my speakers should be 'close' to an ideal impulse response [17:37:42 CEST] <haasn> (part of the reason the stereo image works so well to begin with) [18:14:05 CEST] <cone-964> ffmpeg 03Paul B Mahol 07master:2a75006ddca9: avfilter/vf_maskedclamp: rewrite using macro [18:15:19 CEST] <durandal_1707> mkver: gonna write patch or not? [18:18:25 CEST] <haasn> oh I also just realized this was #ffmpeg-devel and not #ffmpeg, oops [18:56:07 CEST] <cone-964> ffmpeg 03James Almer 07master:738bc3e74207: x86/vf_transpose: make ff_transpose_8x8_16_sse2 work on x86_32 [19:54:36 CEST] <cone-964> ffmpeg 03Paul B Mahol 07master:ec5d385722d9: avfilter/transpose: add missing headers [21:51:45 CEST] <taliho> Hello, I fixed the problem from yesterday and managed get encoded h264 on the Jetson Nano through ffmpeg [21:55:10 CEST] <taliho> at the moment though, I have to throttle the rate of frames going into avcoded_send_frame [21:57:22 CEST] <taliho> if I don't throttle, V4L2 essentially says I don't have any more empty buffers for the data [21:58:07 CEST] <taliho> i.e. EAGAIN return [21:59:03 CEST] <taliho> but avcodec_send_frame will treat this as a fatal error, and not retry sending the frame for compression [22:17:12 CEST] <durandal_1707> increase queue? [22:22:18 CEST] <taliho> yeah will try that [22:23:02 CEST] <taliho> there's a poll to ask for empty buffers.. the timeout is 0 atm. Trying to see if increasing timeout helps [22:39:10 CEST] <BtbN> send_frame should be perfectly fine to return EAGAIN [22:40:36 CEST] <taliho> fftools/ffmpeg.c:1287 [22:42:20 CEST] <jamrial> send_frame is not expected to return EAGAIN at that point because the decoder queue is emptied in the receive_frame loop below [22:43:37 CEST] <jamrial> receive_packet, i mean [22:54:58 CEST] <taliho> yes, I see. for some reason the nano is not dequing it's frame buffers (fast enough) even after the packets are emptied [22:56:31 CEST] <taliho> at least for the first few frames. after it seems fine [22:57:33 CEST] <BtbN> that sound very broken [22:57:44 CEST] <BtbN> Isn't that an nvidia board? Can it not just use nvenc? [23:00:15 CEST] <taliho> yes it's nvidia, but they don't support nvenc on aarch64 [23:01:00 CEST] <taliho> btw... i tried the omx approach first, but that seemed worse [00:00:00 CEST] --- Wed Oct 23 2019

1 0

ffmpeg.log.20191022
by burek 23 Oct '19

23 Oct '19

[03:28:50 CEST] <YellowOnion> is matroska not good for udp streaming? [03:31:30 CEST] <ponyrider> why not? isnt it just the open source version of mp4 [03:32:08 CEST] <pink_mist> not even close, ponyrider [03:32:17 CEST] <pink_mist> in any case, mp4 isn't good for udp streaming [03:32:21 CEST] <pink_mist> dunno about mkv [03:33:04 CEST] <YellowOnion> I'm getting massive amount of errors about seeking issues [03:42:45 CEST] <DHE> the best supported format for udp streaming is mpegts, but that has quite a few limitations.... [03:48:39 CEST] <YellowOnion> yeah mpegts has minimal errors [14:54:09 CEST] <sidar> hey silence remove doesn't seem to work on m4a, is this a limitation? [14:56:16 CEST] <durandal_1707> sidar: give more info, you are very vague [14:56:44 CEST] <sidar> I export a wav to m4a but there is always a silence/padding at the start and end [14:57:04 CEST] <sidar> while for ogg it matches the original wav file [14:57:30 CEST] <sidar> is there a way to make ffmpeg correctly strip that or is it an m4a ( aac format ) problem? [14:59:40 CEST] <sidar> I read that the aac encoder skips pre-roll data, so the file might be alright as it is [14:59:47 CEST] <sidar> have to test [15:01:28 CEST] <JEEB> pre-roll in formats where there isn't just one such and thus the decoder outputs it you have to skip until pts zero. ffmpeg.c last I checked didn't handle this correctly [15:02:11 CEST] <JEEB> and not to mention that if you encoded and put aac into mp4 or other container in separate steps then you lost the preroll size [15:03:05 CEST] <JEEB> f.ex. if you with ffmpeg.c output to wav it will see that wav does not support negative timestamps and moves that to zero [15:03:29 CEST] <JEEB> api users have the chance of doing this correctly which many do [15:10:32 CEST] <GingerGeek> I'm using ffmpeg to ingest a m3u8 stream and output in realtime to another device, when the stream goes onto a new chunk there is a ever so slight stutter, you can't notice it in video but you can notice it in the audio - is there a way to get ffmpeg to use an intermediatery buffer of maybe a second inbetween the m3u8 and the live output? [15:15:59 CEST] <BtbN> it already buffers every input stream. Sounds more like it's an issue with the stream itself. [15:19:59 CEST] <sidar> JEEB: so no solution then other then editing in a tool or anthing? [15:32:03 CEST] <JEEB> sidar: possibly seeking with ss when decoding? not sure [15:32:12 CEST] <DHE> or a player that isn't doing any buffering and expects everything to be on a fast local disk? [15:33:00 CEST] <JEEB> skipping data until pts 0 should do the trick, if possible [15:36:28 CEST] <sidar> it's for web content [15:36:34 CEST] <sidar> not sure how much control ill have over that [15:37:02 CEST] <sidar> The wav file itself doesn't have any padding at the start and end [00:00:00 CEST] --- Wed Oct 23 2019

1 0

ffmpeg-devel.log.20191021
by burek 22 Oct '19

22 Oct '19

[06:58:23 CEST] <cone-221> ffmpeg 03Limin Wang 07master:0afc1fe14700: avfilter/af_silencedetect: document metadata [09:27:06 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:a174e5f8da77: avfilter/vf_nlmeans: round values toward nearest integer [10:37:17 CEST] <ePirat> is ff_format_set_url internal on purpose? [10:37:35 CEST] <ePirat> why is it mentioned in the API changelog if its not public API? [10:38:21 CEST] <JEEB> good question [10:40:54 CEST] <ePirat> (and why would it not be public API? it seems quite useful) [10:43:12 CEST] <nevcairiel> honestly it d oesnt seem useful to me, its like one line of real code in there [10:47:46 CEST] <ePirat> it sets the old field too [10:48:01 CEST] <nevcairiel> there is really no reason to do so externally [10:48:06 CEST] <ePirat> oh ok [10:48:16 CEST] <nevcairiel> internal code doesnt read it, so its only provided for compat with old callers [10:48:35 CEST] <nevcairiel> but if you are aware of it and want to use an api to set both - why not simply not read it anymore :D [11:50:12 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:c6e01ebe411e: avfilter: add bilateral filter [12:14:36 CEST] <cone-221> ffmpeg 03Limin Wang 07master:190f52ba3b16: avfilter/af_silencedetect: use AV_OPT_TYPE_DURATION [12:14:37 CEST] <cone-221> ffmpeg 03Limin Wang 07master:9c3178808ddf: avfilter/af_silencedetect: change mono default to integer literal [13:04:42 CEST] <durandal_1707> can someone review settb patch? [13:05:49 CEST] <durandal_1707> mkver, michaelni, Lynne, nevcairiel, kierank ? [13:10:35 CEST] <kierank> I don't know anything about activate [13:17:44 CEST] <mkver> And I don't know anything about avfilter at all. [15:36:31 CEST] <durandal_1707> kierank, mkver: you can learn anytime, it is easy [15:37:51 CEST] <kierank> durandal_1707: I don't want to learn about Nicholas pet mess project [15:43:13 CEST] <durandal_1707> kierank: his name is Nicolas, not Nicholas, and it is not mess project, why do you think so? [15:45:22 CEST] <durandal_1707> nobody wants to oppose George except only me [15:52:55 CEST] <Lynne> its not worth trying; take my word for it [15:55:50 CEST] <durandal_1707> Lynne: why? just reply to patch LGTM, and he can do nothing [15:58:03 CEST] <mkver> Because you should only lgtm a patch if you actually reviewed it. [16:01:27 CEST] <durandal_1707> otherwise what? Nicolas George police will knock out on your door? [16:07:54 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:aa26f83bdd7e: avfilter/af_join: fix possible memory leaks [17:52:01 CEST] <durandal_1707> what speeds you get with transpose_vaapi and transpose_opencl compared to just transpose? [17:57:30 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:f7f4691f9f74: avfilter/x86/vf_atadenoise: fix comment [19:02:04 CEST] <durandal_1707> x32 have 8 mX registers, right? [19:02:20 CEST] <jamrial> yeah [20:41:02 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:ccd9bca15a46: avfilter/vf_transpose: add x86 SIMD [20:43:16 CEST] <taliho> Hello, I'm working on a patch support to support Jetson nano GPU h264/hevc encoding via v4l2 framework [20:43:51 CEST] <JEEB> cool [20:45:12 CEST] <taliho> I need to link to a library that doesn't have a pkg-config... any way to do this without using --extra-libs flag? [20:46:40 CEST] <BtbN> So it's not v4l2? [20:48:30 CEST] <taliho> I'm using most of the code from libavcodec/v4l2_* [20:48:57 CEST] <taliho> but needed to make some changes to it [20:50:28 CEST] <taliho> one change I had to make is that the ioctl calls have to be made via libv4l2 library [20:51:41 CEST] <taliho> so I did something similar to what libavdevice/v4l2.c is doing [20:55:12 CEST] <taliho> I hav link to -lnvbuf_utils .. there's no pkg-config.pc for this unforutnately. I'm just parsing this to --extra-flags to configure atm. Wondering if there's a better way to do it [21:03:56 CEST] <taliho> test_pkg_config() seems to set xx_extralibs variable. Maybe I can do something similar, i.e. tegra_extralibs="-lnvbuf_utils" ? [21:05:34 CEST] <JEEB> fun license that thing has https://docs.nvidia.com/jetson/l4t-multimedia/nvbuf__utils_8h_source.html :/ [21:05:48 CEST] <JEEB> why can't nvidia just play ball with open source [21:06:11 CEST] <durandal_1707> we do not allow non-free license code in codebase. [21:06:12 CEST] <JEEB> nvidia wants open source to use its stuff, but it doesn't want to make it all usable [21:07:05 CEST] <JEEB> unless that header and friends is in our nvidia headers library which contains those which nvidia has licensed under a usable license [21:08:47 CEST] <taliho> ah, that's a shame. I didn't see that license header [21:10:01 CEST] <JEEB> see if it's in http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary [21:10:04 CEST] <JEEB> although I bet it isn't [21:10:19 CEST] <JEEB> nope [21:10:44 CEST] <durandal_1707> well it could be used if no such header is put into our codebase [21:11:00 CEST] <JEEB> yea but do we want yet another thing that makes the thing non-distributable? [21:11:10 CEST] <JEEB> since it's bound to get built and distributed since everyone wants that [21:11:19 CEST] <JEEB> just like with many other hw vendors [21:11:37 CEST] <JEEB> they get their stuff in as nonfree, then you find them distributing binaries with --enable-nonfree :P [21:12:00 CEST] <JEEB> (nonfree in this context meaning "licenses mismatch, cannot distribute" [21:12:32 CEST] <taliho> any chance, they can do a different license for us? [21:13:01 CEST] <JEEB> taliho: it's worth a try at least. getting the required headers and library to be licensed nicely [21:13:01 CEST] <taliho> similar to nv-codec-headers.git? [21:13:40 CEST] <taliho> ok, I'll get it working first and worry about the license later [21:43:51 CEST] <philipl> I bought a jetson nano and returned it as soon as I realised the video api was completely different. [21:44:14 CEST] <philipl> I think the basic v4lm2m stuff works but their interop for rendering/display is, of course, special. [21:44:18 CEST] <philipl> I guess that's the issue here. [21:47:28 CEST] <JEEB> :/ [21:47:37 CEST] <JEEB> "the knights that say NIH" [21:50:43 CEST] <philipl> Cynically, I'd say it's because they are, once again, refusing to support dma_buf and gbm, but I might be wrong - this was a few months ago and I didn't read deeply once I understood the punchline. [21:52:21 CEST] <philipl> It's also possible that it's just a gap in v4lm2m and every vendor does their own stupid shit. [21:55:37 CEST] <JEEB> possible yes [21:59:26 CEST] <taliho> philipl: In the nano you have to export the buffers as a DMABUF file descriptor before using mmap [22:00:42 CEST] <JEEB> also we'll have to see how badly the vulkan hwdec API will go [22:00:52 CEST] <JEEB> should be ready first half 2020? [22:01:10 CEST] <JEEB> kind of wish someone from a project like us would be related to that [22:01:55 CEST] <taliho> I just added a -use_dma option.. which if set calls v4l2_ioctl(fd, VIDIOC_EXPBUF, .. ) on each plane [22:03:20 CEST] <cone-221> ffmpeg 03James Almer 07master:27bae5aacafe: x86/vf_transpose: fix cpuflags check [22:20:39 CEST] <philipl> taliho: so what's the proprietary nvbuf stuff for? [22:29:45 CEST] <taliho> philipl: before writing to the output buffers, they always call a synchronization function from this library [22:31:48 CEST] <taliho> the function is NvBufferMemSyncForDevice( dma fd, plane, mapped_memory) [22:36:09 CEST] <taliho> I'm testing atm.. definitly getting some correct dequed packets, but also getting gibberish out. trying to debug [22:37:11 CEST] <cone-221> ffmpeg 03James Almer 07master:02cf2391966a: avformat: call AVOutputFormat->deinit() when freeing the context [22:37:12 CEST] <cone-221> ffmpeg 03James Almer 07master:a581bb66ea5e: avformat/avienc: add deinit function [22:37:13 CEST] <cone-221> ffmpeg 03James Almer 07master:b46cdd9d2370: avformat/ttaenc: add a deinit function [22:37:14 CEST] <cone-221> ffmpeg 03James Almer 07master:df57246aafea: avformat/mp3enc: add init and deinit functions [22:37:15 CEST] <cone-221> ffmpeg 03James Almer 07master:aeb8b65cdf3e: avformat/flacenc: add a deinit function [22:37:16 CEST] <cone-221> ffmpeg 03James Almer 07master:cecf29eb1c41: avformat/oggenc: free buffered page lists while uninitializing the muxer [23:16:19 CEST] <cone-221> ffmpeg 03Limin Wang 07master:7a477c4b631b: avfilter/vf_unsharp: rename config_props -> config_input, link -> inlink [23:16:20 CEST] <cone-221> ffmpeg 03Limin Wang 07master:6079bd5c63e5: avfilter/vsrc_mptestsrc: add options to set the maximum number of frames [23:16:21 CEST] <cone-221> ffmpeg 03Michael Niedermayer 07master:e85eb7cb04ce: avcodec/atrac9dec: Set channels [23:16:22 CEST] <cone-221> ffmpeg 03Limin Wang 07master:887db368212b: avfilter/vsrc_mptestsrc: simplify the code and change the type of frame [00:00:00 CEST] --- Tue Oct 22 2019

1 0

ffmpeg.log.20191021
by burek 22 Oct '19

22 Oct '19

[00:16:46 CEST] <cards> Is it possible to mux multiple audio tracks to a single MPEG (.mp4) container? (non-mkv) [00:17:49 CEST] <furq> yes [00:18:44 CEST] <cards> and most players will be able to manage that? ie, VLC [00:19:00 CEST] <furq> sure [00:19:34 CEST] <furq> maybe not web players but afaik those will just ignore the extra tracks [06:36:48 CEST] <JohnGritt> is this the channel to find a codecs dealer on the down low? [13:55:39 CEST] <termos> I'm muxing something to HLS, but if there's an error pushing my segments i'm buffering up AVPacket's. The problem is I don't want to call avformat_free_context when the output stops working since I want to keep the internal AVPacket buffers in the HLS muxer as well, so I don't lose any segments [13:56:13 CEST] <termos> though there seems to be some memory leaking every time I'm doing this, is there a best practice way to do something like this? I avio_open every time I retry instead [14:33:32 CEST] <termos> I guess I want to avoid the call to flush_packet_queue, but do everything else that avformat_free_context does, hmmm [14:55:05 CEST] <ponyride1> termos: i just opened the man page on hls :( [15:03:21 CEST] <termos> hehe, not helpful? i'm considering creating an avformat_free_context_noflush function and frees the streams and everything except flushing the internal buffers. The problem is I'm losing segments if they are flushed, causing my bitrates to run out of sync [15:18:32 CEST] <ponyride1> termos: lhls -- experimantal [15:18:56 CEST] <termos> ah i'm not using lhls right now [15:19:45 CEST] <ponyride1> segments do not need to be complete to be buffered, the server is able to push partial segments to the client [15:20:45 CEST] <ponyride1> the more i read, the more i die inside lol its complicated [15:22:18 CEST] <DHE> lhls? [15:23:03 CEST] <ponyride1> yeah im just reading about it [15:24:36 CEST] <DHE> yeah I'm finding references now [15:25:49 CEST] <DHE> looks like low-latency HLS variant... which sounds nutty but... [15:28:29 CEST] <ponyride1> termos: what does 'error pusing segments' mean [15:28:34 CEST] <ponyride1> * pushing [15:29:42 CEST] <termos> error POST/PUT-ing them to a temporarily unavailable http endpoint [15:45:55 CEST] <termos> something similar to lhls exists for dash, but lhls was kind of hijacked by Apple creating their own standard which uses http/2 [15:58:46 CEST] <ponyride1> well they own hls and lhls will have to be compliant so Apple will have to set the spec no? [16:09:49 CEST] <termos> true they can do whatever they want, was just a bit of annoyance in the hls.js community that Apple didn't build on their "lhls community version" but went and did something very different [16:10:21 CEST] <JEEB> technically HLS is now in the hands of IETF, but yes - de facto leader is Apple [16:10:37 CEST] <JEEB> termos: when has apple really played well with the other kids in the sand box :) [16:10:57 CEST] <termos> i think never :D apple's gonna apple [16:17:26 CEST] <delsol> I'm getting a "nousable encoding entrypoint found for profile VAProfileH264High (7)" error and then error initializing output stream. The same command works on another machine, no idea what the difference is. [16:18:07 CEST] <delsol> I can run command locally on machine 1, or ssh run it on machine1 from machine2.... but it doesn't run locally on machine2 or via ssh from machine 1. [16:23:10 CEST] <JEEB> delsol: check vainfo? [16:25:32 CEST] <delsol> vainfo is same on both machines. [16:26:15 CEST] <delsol> gives error it can't connect to X server, and "libva error: /usr/lib64/dri/i965_drv_video.so has no function __vaDriverInit_1_0" [16:27:31 CEST] <ponyride1> vaapi [16:27:34 CEST] <ponyride1> device is either an X11 display name or a DRM render node. [16:28:33 CEST] <ponyride1> does this mean no DISPLAY:0? [16:28:50 CEST] <delsol> DISPLAY=:0 ffmpeg -vaapi_device /dev/dri/renderD128 -framerate 15 -f x11grab -video_size1024x768 -i :0 -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -qp 30 /video/video.mp4 [16:28:56 CEST] <delsol> works fine on one machine, doesn't work on the other [16:29:28 CEST] <ponyride1> but when you run ssh... there is no x11 [16:29:51 CEST] <delsol> I can run it on machine 1 via ssh from machine2 [16:29:53 CEST] <delsol> works fine [16:30:44 CEST] <delsol> doesn't work locally even when run in X, in a terminal window on second machine. [16:31:40 CEST] <ponyride1> delsol: try something like xhost + [16:32:05 CEST] <ponyride1> just temporarily.. maybe its a permssion thing? are you sshing as root or as another user [16:32:14 CEST] <delsol> no dice with xhost + [16:32:42 CEST] <delsol> even locally, on an xterm, on the DISPLAY=:0 of the second machine, it still doesn't run. [16:32:45 CEST] <delsol> as root [16:33:18 CEST] <ponyride1> delsol: you should take this to your distro maybe.. [16:33:39 CEST] <ponyride1> im not sure if this is really an ffmpeg error? [16:34:22 CEST] <delsol> It worked fine without hardware accel. [16:34:57 CEST] <delsol> I upgraded Xorg and intel drivers, etc, it still worked fine without hardware accel. [16:35:46 CEST] <delsol> turn hardware accel on, to reduce CPU load of encoding the X11grab, and works fine on main machine, doesn't work on any of the client machines. [16:41:04 CEST] <ponyride1> delsol: better ask your distro ^^ [16:42:03 CEST] <delsol> ffmpeg -y -framerate 15 -video_size 1024x768 -f x11grab -i :0 -vcodec libx264 -crf 30 -x264-params scenecut=10:keyint=450 -pix_fmt yuv420p -preset ultrafast /video/vido.mp4 -nostdin -nostats </dev/null 2>&1 works fine [16:42:19 CEST] <delsol> ffmpeg -vaapi_device /dev/dri/renderD128 -framerate 15 -f x11grab -video_size 1024x768 -i :0 -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -qp 30 /video/video.mp4 -nostdin -nostats </dev/null 2>&1 doesn't work on the client machines. [16:43:08 CEST] <ponyride1> what machine is it? [16:43:30 CEST] <delsol> model name : Intel(R) Pentium(R) 3560Y @ 1.20GHz [16:43:59 CEST] <ponyride1> what linux [16:44:09 CEST] <ponyride1> what distro [16:44:33 CEST] <delsol> slackware-(not_quite)current [16:45:19 CEST] <delsol> with a newer Xorg, newer intel drivers, newer ffmpeg, etc [16:45:30 CEST] <delsol> Fluxbox is the window manager. [16:48:15 CEST] <ponyride1> i really dont know. it could be your drivers, it could be some packaging error of your distro, it could be a bug elsewhere [16:48:32 CEST] <delsol> Other machines that work just fine are other haswell boxes, [16:48:49 CEST] <delsol> including i3-4030U [16:49:36 CEST] <delsol> oh shit. I know why [16:49:37 CEST] <ponyride1> delsol: you could just have some bad command too... i [16:49:55 CEST] <delsol> Intel® Quick Sync VideoNo [16:50:13 CEST] <delsol> Looks like its hardware disabled on the pentium.... [16:50:22 CEST] <delsol> well shit [16:50:47 CEST] <delsol> (is there a way to detect quicksync?) [16:51:16 CEST] <ponyride1> huh [16:54:42 CEST] <ponyride1> !man [16:57:01 CEST] <ponyride1> you should look at teh man page for qsv though [16:57:38 CEST] <ponyride1> i think your barking up the wrong tree [16:58:38 CEST] <delsol> I think its the fact that the one machine has quicksync disabled by intel.... [16:58:50 CEST] <delsol> according to ark.intel.com [17:00:42 CEST] <Fenrirthviti> it's not disabled, it just doesn't exist [17:01:02 CEST] <Fenrirthviti> quicksync is a dedicated hardware encoder that's part of the integrated GPU [17:01:23 CEST] <Fenrirthviti> so the physical chip for that is just nonexistent on such a low-end CPU [17:01:54 CEST] <delsol> .... its disabled, since that chip comes off the same wafer as the other chip. [17:01:57 CEST] <Fenrirthviti> typically the only way to check is to try and start an encode session [17:02:11 CEST] <delsol> so its laser-disabled, or firmware disabled from the GPU. [17:02:43 CEST] <ponyride1> delsol: the man page also states Note that most acceleration methods are intended for playback and will not be faster than software decoding [17:02:46 CEST] <ponyride1> on modern CPUsy [17:05:07 CEST] <ponyride1> delsol: i3-4030U - qucksync = yes, 3560Y quickync = NO [17:06:15 CEST] <ponyride1> Fenrirthviti: i just looked up the specs. ur right it doesnt exist [17:06:22 CEST] <ponyride1> anyway i gtg to bed gooluck [17:06:37 CEST] <delsol> ponyride1: switching to quicksync encode of the x11grab takes a shitty machine from roughly 40% of a core during screen abuse, to 25%.... [17:07:29 CEST] <delsol> with several VNC sessions to record potentially, that makes a difference, thats why I was trying to offload what I could. [17:07:36 CEST] <ponyride1> i dont really see how this is relevant [17:08:37 CEST] <delsol> I guess I need to find a way to detect quicksync support now, run the accelerated command on machines with quicksync, run the other command on machines without. [17:10:21 CEST] <ponyride1> you misunderstand [17:10:38 CEST] <ponyride1> https://ark.intel.com/content/www/us/en/ark/products/76622/intel-pentium-pr… [17:10:42 CEST] <ponyride1> no quicksync for you [17:11:25 CEST] <delsol> yeah, I saw that. I mentioned that 20 minutes ago.... [17:11:51 CEST] <delsol> the question now, is how the hell can I detect quicksync = YES vs quicksync = NO automatically. [17:14:44 CEST] <grill05> I'm using a custom video encoder with ffmpeg. I pipe using yuv4mpegpipe to stdout, and the encoder reads from stdin via a pipe. Unfortunately the encoder doesn't write to stdout. So right now, I have to use a tmp video file (made with encoder) and encode audio later separately [17:15:06 CEST] <grill05> I'd like to do this in 1 command. If the encoder could write to stdout, I could do sometimething like [17:15:55 CEST] <grill05> ffmpeg -i input.mkv -f yuv4mpegpipe - | custom_encoder -i - -o - | ffmpeg -i - -i input.mkv -map 0:0 -c:v copy -map 1:0 -c:a copy output.mkv [17:16:30 CEST] <grill05> Since the custom encoder cant write to stdout, is there a way using FIFOs (on linux) to achieve the same effect as two pipes ? [17:16:46 CEST] <Fenrirthviti> delsol: we have a check somewhere in here: https://github.com/obsproject/obs-studio/tree/master/plugins/obs-qsv11 but I don't know exactly where off the top of my head [17:16:55 CEST] <Fenrirthviti> there's no simple way with just ffmpeg though, afaik [17:16:57 CEST] <TheAMM> grill05: yes [17:17:07 CEST] <TheAMM> I haven't looked at your commands at all, but FIFOs work, yes [17:17:14 CEST] <grill05> please post a sample command line [17:17:20 CEST] <TheAMM> mkfifo foo [17:17:32 CEST] <delsol> Fenrirthviti: hmmm. I'll take a glance. [17:17:33 CEST] <TheAMM> ffmpeg -i a.mkv -y foo, iirc [17:17:49 CEST] <grill05> I mean the whole thing, that acts in same way as two pipes joined together, maybe on pastebin ? [17:17:54 CEST] <grill05> ok [17:18:00 CEST] <TheAMM> Nah [17:18:13 CEST] <TheAMM> I'm just here to confirm that FIFOs do work as outputs (and inputs) [17:18:26 CEST] <TheAMM> (depending on your containers ofc etc) [17:20:36 CEST] <grill05> TheAMM, ok. If I do the first command (write to fifo with custom video encoder), wont the command block till the whole video is encoded ? That would defeat the purpose, which is simultaneous encoding of audio+video [17:21:38 CEST] <TheAMM> Open two shells or background the jobs [17:22:13 CEST] <grill05> hmm..backgrounding might work. thanks. I'll try it out [17:29:00 CEST] <grill05> TheAMM, so backgrounding did'nt work. starting two shells (encoding video to FIFO in shell 1 and muxing it with audio on shell 2), gives these errors (in shell 2) "Timestamps are unset in a packet for stream 0" [17:29:25 CEST] <grill05> The video is normally written as .ivf (AV1) [17:30:58 CEST] <TheAMM> ð€· [17:31:05 CEST] <TheAMM> Someone else will have to help [17:32:47 CEST] <grill05> thanks anyway. This is farther along than I would have reached by myself :) [17:41:08 CEST] <voxelcloud> Hi, I'm trying to figure out if I've found a bug. I'm using the drawtext filter to write out frames with frame numbers drawn on. One frame gets printed twice, as in there are two frames with the same frame number printed on it (and the same frame content). The video is mpeg1. Command line is here: https://pastebin.com/xBf50Wbp. I've tested 4.1.4 on Fedora 30 and built it from master with the same issue. [17:51:26 CEST] <kepstin> voxelcloud: expected behaviour. The image output is cfr (by default) since you lose frame timing information. So it may drop or duplicate frames if the input is not cfr. [17:52:02 CEST] <kepstin> voxelcloud: you can use `-vsync vfr` option to override that behaviour [17:55:06 CEST] <voxelcloud> kepstin, Thanks! Makes perfect sense. [17:55:35 CEST] <voxelcloud> and that does indeed fix it. [18:06:49 CEST] <JordiGH> What's going on with the first command here? https://video.stackexchange.com/a/28276 [18:07:09 CEST] <JordiGH> What's with the /dev/null? Where is anything being saved, then? [18:07:24 CEST] <JEEB> 1st pass video generally isn't kept [18:07:41 CEST] <JEEB> might as well do that without the -f webm and instead -f null - [18:07:44 CEST] <kepstin> libvpx doesn't even generate any video output when you run pass 1, you just get an empty file [18:08:51 CEST] <kepstin> the log output used by pass 2 is saved to a separate file. it's configurable, but there's a default that's saved to the cwd [18:09:28 CEST] <JordiGH> I still don't understand. Is pass 1 writing anything to disk? [18:09:36 CEST] <JordiGH> You're saying it's saving a log file to cwd? [18:10:10 CEST] <JordiGH> ffmpeg2pass-0.log [18:10:12 CEST] <JordiGH> Oh, boy, there it is. [18:10:17 CEST] <JordiGH> That was generated by pass 1? [18:10:24 CEST] <kepstin> yes, and read by pass 2 [18:11:43 CEST] <kepstin> note that you shouldn't run multiple two-pass encodes in the same directory without specifying a different filename for the 2pass log for each, otherwise they'll clobber each-others log files :) [18:11:45 CEST] <JordiGH> Aha. So anyway, thanks for helping me generate this: https://mathstodon.xyz/@JordiGH/102998504788285261 [18:12:59 CEST] <kepstin> hmm. for mastodon there's normally an upload size limit, you might want to do a 2pass encode with a bitrate that'll result in maxing out the file size to the limit. [18:13:18 CEST] <JordiGH> It was less than 2 megs, well within the limit. [18:13:33 CEST] <JordiGH> I just didn't want my waves to get all pixelly. [18:53:29 CEST] <familiya> Hi, I am pretty new at using ffmpeg, I have a requirement where in I want to produce output in raw y416 pixel format. Not sure if AV_PIX_FMT_AYUV64LE would be helpful [18:54:08 CEST] <BtbN> what even is y416? [18:54:21 CEST] <familiya> Its pixel format [18:55:38 CEST] <familiya> More information available at https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-y… [18:56:46 CEST] <BtbN> "Bits 0-15 contain the U sample, bits 16-31 contain the Y sample, bits 32-47 contain the V sample, and bits 48-63 contain the alpha value." [18:56:50 CEST] <BtbN> I don't think ffmpeg has that. [18:57:11 CEST] <BtbN> AYUV64 is close, but the ordering seems off [18:57:49 CEST] <familiya> Just curious as ffmpeg wiki has a ref to y416 https://en.wikipedia.org/wiki/FFmpeg#Pixel_formats [19:02:44 CEST] <kepstin> could probably do a hack where you use a filter to swap some of the planes around then output as AYUV64 [19:03:10 CEST] <kepstin> but yeah, AVYU (or UYVA depending on endianness) is such a weird order. [19:15:01 CEST] <familiya> kepstin: Not sure if I understand your suggestion, as far I understand Y416 is a packed pixel format. Not sure how can I swap planes and from where. I would like to apologies in advance as I am pretty new to ffmpeg, and would end up asking pretty trivial questions [19:16:06 CEST] <kepstin> https://www.ffmpeg.org/ffmpeg-filters.html#shuffleplanes [19:16:35 CEST] <kepstin> iirc it works on packed formats too, but the video's probably in planar format in ffmpeg then converted to packet to output in many cases [19:44:55 CEST] <familiya> how about adding support in codec, where I can shuffle the planes from pixel format AV_PIX_FMT_YUVA444P16 [21:14:46 CEST] <realies> hey I'm using ebur128 to get loudness data and wonder what I and Threshold mean in the Integrated loudness section [21:17:01 CEST] <kepstin> realies: I is the important one, that's the integrated loudness (loudness over the entire track) [21:17:57 CEST] <kepstin> in order to understand the threshold you need to read the math in https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-4-201510-I!!PDF-E… - it's an internal detail about the loudness gating to make sure the calculated loudness is representative of most of the track, and excludes stuff like silence and outliers. [21:18:21 CEST] <realies> kepstin, using a VST plugin (https://youlean.co/download-youlean-loudness-meter/) to measure the integrated loudness of the same clip and it gives me -34 LUFS, while ffmpeg gives me -25 LUFS, both using EBU standard [21:18:56 CEST] <realies> ok, Threshold: -35.9 LUFS in ffmpeg is closer to the -34 from the VST plugin [21:19:14 CEST] <kepstin> it's likely that the meters are measuring different audio [21:19:31 CEST] <kepstin> like your vst plugin is running on audio that's ~10dB louder than the audio that ffmpeg is measuring [21:19:56 CEST] <kepstin> probably due to settings inside the application you're using, or possibly settings in how you're exporting the audio before running ffmpeg on it [21:20:36 CEST] <kepstin> ffmpeg's calculation is correct, and is consistent with other implementations when run over the same audio [21:21:06 CEST] <realies> was looking to match the values from the VST with ffmpeg I guess [21:21:26 CEST] <kepstin> you first need to match the audio gain that you're feeding as input to both [21:21:43 CEST] <kepstin> if the audio gain is different, then the measured loudness will be different by the same amount [21:22:03 CEST] <kepstin> (if it's consistent difference, you can just use an offset equal to the gain difference tho) [21:22:37 CEST] <realies> all channels are on 0db [21:22:49 CEST] <kepstin> make sure you didn't insert the VST plugin before e.g. a compressor or levels plugin [21:22:55 CEST] <realies> new, empty project [21:23:25 CEST] <realies> anyways, matching the data with a VST is not that important, trying to automate a filter chain to make voice audio sound 'broadcast compatible' [21:23:46 CEST] <kepstin> well, all i can tell you is that there's either some gain being changed somewhere or that the plugin you're using is wrong :/ [21:23:54 CEST] <realies> perhaps [21:24:10 CEST] <kepstin> since it seems like the levels in the exported audio that you're running through ffmpeg don't match the levels that the vst plugin sees [21:24:21 CEST] <durandal_1707> realies: do you use video output from ebur128? [21:24:38 CEST] <realies> I've downloaded a few broadcasts from BBC's website and I get I: -18.4 LUFS when they specify about -23 LUFS in their broadcast specs lol [21:24:51 CEST] <realies> durandal_1707, no, ffmpeg -hide_banner -nostats -i BroadcastingHouse-20191006.mp3 -af ebur128=framelog=verbose -f null - [21:25:17 CEST] <kepstin> realies: interesting. -18 LUFS is the ReplayGain reference loudness, commonly used for people normalizing their music collections. [21:25:46 CEST] <kepstin> youtube for reference seems to use something around -14 LUFS (but they only lower gain if it's louder, they never increase gain) [21:25:47 CEST] <realies> hmm, could it be that they loudness normalise downloads with different settings to what's being broadcasted? seems unlikely though [21:26:17 CEST] <kepstin> -23 is the standard for tv broadcasts, but afaik there's no radio standards [21:27:14 CEST] <realies> -23 sounds like the upper limit... what about the expected dynamic range for voice? :) no one is saying anything about that [21:27:45 CEST] <kepstin> dynamic range is a completely separate issue [21:27:50 CEST] <realies> indeed [21:28:08 CEST] <kepstin> (although the ebu r128 meters do measure something sort of dynamic rangey) [21:28:18 CEST] <realies> 'Loudness range' [21:29:26 CEST] <kepstin> the value ffmpeg outputs as LRA is the loudness range, which is equavalent to the LRA high minus LRA low [21:30:03 CEST] <kepstin> iirc those are the highest and lowest instantaneous loudness values excluding values outside the threshold, but check the spec to confirm that [21:30:57 CEST] <kepstin> note that these values are all negative, so -23 LUFS is more of a lower limit than an upper limit [21:31:19 CEST] <kepstin> it's kind of quiet, tbh, but provides lots of headroom for dynamic loud sound effects in movies and stuff [21:32:44 CEST] <kepstin> most modern pop/rock music ends up being mastered to around -8 to -10 LUFS, fwiw, so it basically always ends up having gain lowered by streaming services. [21:33:05 CEST] Action: kepstin has seen higher than that even in some things [21:33:14 CEST] <realies> sure [21:33:48 CEST] <realies> just wondering how could one make an universal processing filter chain for voice input... :) [21:34:31 CEST] Action: realies goes looking up dynaudnorm || loudnorm [21:34:35 CEST] <kepstin> hmm. main issue there would be dealing is people moving around closer/further from the mic [21:35:04 CEST] <realies> you would hope that the loudnorm deals with that [21:35:08 CEST] <kepstin> i've successfully helped someone here recently using loudnorm on an audiobook file with inconsistent levels, just set the target LRA fairly low. [21:35:09 CEST] <realies> or dynaudnorm [21:35:26 CEST] <realies> yeah, should act like a compressor I assume [21:36:58 CEST] <kepstin> dynaudnorm is a normalizer, not loudness adjustment, so it doesn't take perceptual loudness into effect. However, it should be ok with keeping voice from a single speaker at a consistent level. [21:37:56 CEST] <kepstin> assuming you don't have any clipping [21:38:17 CEST] <kepstin> (or use rms mode) [21:39:12 CEST] <realies> was thinking of chaining dynaudnorm to loudnorm for more 'even sounding' result [21:39:57 CEST] <kepstin> might work, use dynaudnorm to do the short-term normalization, then loudnorm to adjust the result to the desired LUFS target. [21:40:10 CEST] <realies> it does something weird... [21:40:25 CEST] <durandal_1707> really? what weird? [21:40:35 CEST] <realies> https://i.snipboard.io/5eXwRo.jpg [21:40:52 CEST] <realies> beginning and end are 'quiet' and the middle is boosted [21:41:17 CEST] <durandal_1707> that is normalizer [21:41:37 CEST] <durandal_1707> if you want begining and end also boosted use alt boundary option [21:41:39 CEST] <realies> that's dynaudnorm [21:42:00 CEST] <kepstin> dynaudnorm documentation explicitly says that it has this behaviour [21:42:23 CEST] <realies> sorry, I've missed altboundary :) [21:43:02 CEST] <realies> awesome [21:44:08 CEST] <kepstin> note that you might want to try the rms option for dynaudnorm too, see which way works better. [21:46:46 CEST] <realies> I've added r=1.0 but not seeing/hearing any difference [21:47:55 CEST] <kepstin> i'd expect you'd have to use a lower value, with rms 1 it would hitting the peak limit the whole time :) [21:49:08 CEST] <realies> ah [21:49:21 CEST] <kepstin> i assume the scale 0-1 represents the linear pcm levels, so 1 would be 0 dBFS and 0 is silence [21:49:39 CEST] <realies> so 0.23 could be a good value? lol [21:49:48 CEST] Action: realies hasn't got a clue [21:50:16 CEST] <kepstin> i dunno, probably ok? :) [21:50:21 CEST] <realies> :) [21:51:36 CEST] <durandal_1707> you can use dB: dynaudnorm=b=1:r=-30dB [21:51:51 CEST] <realies> :o [21:52:02 CEST] <kepstin> oh, it can take a value in dB directly? that's handy [21:52:14 CEST] <realies> awesome [21:52:14 CEST] <kepstin> i guess the conversion is done by the ffmpeg option parser units stuff [21:52:19 CEST] <durandal_1707> yes [21:52:34 CEST] Action: kepstin does not recommend setting bitrate in dB [21:52:57 CEST] <durandal_1707> but not all options supports that, some take dB directly [21:53:25 CEST] <durandal_1707> *other filters [21:53:39 CEST] <realies> feels like I should use dynaudnorm to expand the audio and maybe add a bit of compression before it goes to the loudness normaliser [21:55:14 CEST] <durandal_1707> i prefer vanilla audio [21:55:22 CEST] <kepstin> dynaudnorm doesn't do any expanding, not sure what you mean? [21:55:42 CEST] <kepstin> (it does have a builtin compressor, fwiw, but it's off by default) [21:56:44 CEST] <kepstin> dynaudnorm is basically equivalent to a person sitting watching a dB meter (either peak or rms) and turning the volume knob to try to keep the level mostly the same [21:57:05 CEST] <durandal_1707> expanding is fixed operation [21:57:50 CEST] <durandal_1707> you can expand audio with agate filter and setting mode to upward [21:59:13 CEST] <phobosoph> hi [21:59:21 CEST] <phobosoph> so I found a mystery! :D [21:59:29 CEST] <phobosoph> ffmpeg shows me the stats while streaming to YouTube Live [21:59:40 CEST] <phobosoph> suddenly YouTube Live doesn't recognize the stream anymore (No data) [21:59:44 CEST] <phobosoph> so I checked the logs [21:59:54 CEST] <phobosoph> frame=331657 fps= 24 q=-1.0 size= 8311736kB time=03:04:41.19 bitrate=6144.6kbits/s speed=0.807x [22:00:01 CEST] <phobosoph> can you see it? speed is 0.8...x [22:00:11 CEST] <realies> sorry, wrong terminology, i meant to even out the audio level and maybe shorten the dynamic range before it goes to the loudness normaliser [22:00:12 CEST] <phobosoph> it started with speed=1.03x or something like that [22:00:20 CEST] <phobosoph> The speed drops over time! [22:00:22 CEST] <phobosoph> why [22:00:22 CEST] <realies> phobosoph, maybe -r? [22:00:42 CEST] <phobosoph> aha [22:00:56 CEST] <phobosoph> realies: so the source stream of the webcam got 30fps [22:01:02 CEST] <phobosoph> ideally this fps is kept for youtube [22:01:05 CEST] <phobosoph> otherwise it would be a waste [22:01:17 CEST] <kepstin> if you use no special options, ffmpeg will do that by default [22:01:36 CEST] <phobosoph> right [22:01:43 CEST] <phobosoph> but why is the speed constantly dropping? [22:01:45 CEST] <durandal_1707> depends what processing is done ... any filtering or similar? [22:01:49 CEST] <kepstin> the speed going low usually means that you're either network limited or cpu limited (it can't send data fast enough, or it can't encode video fast enough) [22:02:11 CEST] <kepstin> is your internet connection good enough to send 6mbit/s upstream? :) [22:02:54 CEST] <phobosoph> No filter, mute audio is added [22:02:58 CEST] <phobosoph> yes, internet connection is not saturated [22:03:17 CEST] <phobosoph> https://pastebin.com/kgaZqwD2 [22:03:26 CEST] <kepstin> btw, does anyone know offhand if mp3 audio in a video file with mp4 container plays on iOS? [22:03:27 CEST] <phobosoph> that's the ffmpeg command used [22:03:40 CEST] <kepstin> phobosoph: don't use -re [22:03:41 CEST] <phobosoph> it adds mute audio channel, otherwise youtube will not accept it [22:03:53 CEST] <phobosoph> kepstin: so just ommit '-re'? [22:03:53 CEST] <ritsuka> kepstin: it does not [22:04:08 CEST] <kepstin> ritsuka: ah :/ well, aac it is then, i guess. [22:04:23 CEST] <phobosoph> kepstin: thanks, so when I ommit -re do I need something else? [22:04:25 CEST] <kepstin> phobosoph: -re is not needed if your input is already realtime, it only causes desync issues then [22:04:28 CEST] <phobosoph> ah [22:04:30 CEST] <phobosoph> thanks!!!!! [22:05:07 CEST] <peloverde> What's the correct filter chain for going from rgb24 to y420p8 with dither? Do I need to go through a high bit depth intermediate? [22:05:51 CEST] <JEEB> peloverde: I would recommend testing out between scale and zscale [22:06:21 CEST] <durandal_1707> scale would be needed anyway, as it will unpack rgb24 into gbrp [22:06:22 CEST] <JEEB> something like -vf scale,format=yuv420p [22:06:26 CEST] <phobosoph> ok, restarted ffmpeg without -re [22:06:28 CEST] <JEEB> durandal_1707: yes [22:06:34 CEST] <phobosoph> speed is at 1.03x currently [22:06:39 CEST] <phobosoph> 0.02 [22:06:55 CEST] <kepstin> phobosoph: it'll usually burst a little bit at the start because of how the encoder works, then converge to 1.0 [22:07:03 CEST] <JEEB> -vf format=gbrp,zscale,format=yuv420p [22:07:09 CEST] <JEEB> something like that I guess for zscale comparison [22:07:14 CEST] <phobosoph> that's ok! I just want the stream to be recognized by YouTube Live [22:07:21 CEST] <phobosoph> right, 1.01 [22:07:30 CEST] <phobosoph> looks good [22:07:33 CEST] <phobosoph> crazy, a stupid -re flag did that [22:07:34 CEST] <phobosoph> lol [22:07:35 CEST] <JEEB> although the filter chain might add the rgb to gbrp conversion automagically? [22:08:03 CEST] <phobosoph> kepstin: well, thank you! You helped me a lot. I will now monitor this for some hours. [22:08:06 CEST] <kepstin> JEEB: the filter chain will automatically convert to *something* zscale accepts as input, but it's hard to predict what it'll pick :) [22:08:14 CEST] <JEEB> kepstin: aye-men [22:08:26 CEST] <phobosoph> kepstin: "yuv420p instead of yuvj420p" - can this be done without re-encoding? video is currently just copied [22:08:28 CEST] <durandal_1707> JEEB: yes, but that may have been gray8 [22:08:29 CEST] <JEEB> I specifically often disable automagic conversions in my filter chains [22:08:34 CEST] <phobosoph> I don't think I can make my webcam use yuv420p instead of yuvj420p [22:08:44 CEST] <phobosoph> hm, I hadn't tried the base profiles enough yet I think [22:09:19 CEST] <kepstin> phobosoph: changing that (that's converting from full range/pc levels to limited/tv levels) cannot be done without re-encoding [22:09:27 CEST] <phobosoph> kepstin: I see, thanks [22:09:33 CEST] <phobosoph> I try to convince my webcam then [22:10:39 CEST] <phobosoph> I can select a profile: Baseline, Main, High [22:10:45 CEST] <phobosoph> from what I understand is High profile for higher quality [22:10:56 CEST] <phobosoph> as YouTube Live does the video distribution I can pick High then? [22:11:06 CEST] <phobosoph> and let YouUtbe encode/compress as demanded by devices? [22:11:17 CEST] <kepstin> no reason to use anything other than high, yeah. [22:11:21 CEST] <realies> eh?... Number of attacks/decays bigger than number of channels. [22:11:38 CEST] <kepstin> but that has no relation to the levels issue [22:11:58 CEST] <kepstin> it's strange that you'd be getting yuvj420p from an h264 stream, tho [22:13:24 CEST] <realies> does compand specify attacks/decays for individual channels separately? compand=0|0:1|1:-90/-900|-70/-70|-30/-9|0/-3:6:0:0:0 [22:16:01 CEST] <phobosoph> kepstin: I switched to high profile :D [22:16:03 CEST] <phobosoph> let's see [22:16:19 CEST] <realies> it seems so, although it's not very clear from the docs [22:16:25 CEST] <phobosoph> Non-monotonous DTS in output stream 0:0; previous: 0, current: -167; changing to 0. This may result in incorrect timestamps [22:16:31 CEST] <realies> how should they be formatted [22:16:32 CEST] <phobosoph> I get four warnings at the beginning [22:17:07 CEST] <kepstin> phobosoph: a couple at the start like that can just be ignored, quirk of joining the stream in the middle. [22:17:25 CEST] <phobosoph> good! [22:17:26 CEST] <phobosoph> thanks man [22:17:29 CEST] <phobosoph> it seems to work now [22:17:41 CEST] <phobosoph> finally, I already thought of force-terminating ffmpeg each hour or so and restart it [22:19:13 CEST] <phobosoph> yes, speed converged to 1x now as you said [22:23:07 CEST] <realies> why is compand=.3|.3:1|1:-90/-60|-60/-40|-40/-30|-20/-20:6:0:-90:0.2 failing with Number of attacks/decays bigger than number of channels.? [22:24:16 CEST] <durandal_1707> realies: mono audio? [22:24:32 CEST] <realies> yes [22:24:37 CEST] <durandal_1707> use latest version of ffmpeg, there are extra entries ignored [22:25:27 CEST] <realies> assuming brew does not provide the latest version (4.2.1_1) [22:26:13 CEST] <durandal_1707> compand is for more advanced users, try acompressor instead [22:27:18 CEST] <realies> fine using compressors as long as I get the parameter syntax [22:27:22 CEST] <realies> *parameters [22:28:30 CEST] <realies> hmm... latest seems to be 4.2.1 [22:30:07 CEST] <delsol> .... is there an easy way to know how much of the quicksync hardware is being used at any given time? a way to do a "htop" for quicksync or something? [22:30:46 CEST] <durandal_1707> realies: compand=.3:1:-90/-60|-60/-40|-40/-30|-20/-20:6:0:-90:0.2 [22:31:07 CEST] <realies> oh now I see it :) [22:31:14 CEST] <realies> thanks! [22:31:38 CEST] <realies> using ffmpeg-95459-ged78ca4123 also helped [22:33:54 CEST] <realies> durandal_1707, that compand produces a different output vs the other one [22:34:33 CEST] <durandal_1707> realies: for same, mono audio? [22:35:08 CEST] <realies> yes, just different compand (and ffmpeg version) https://i.snipboard.io/hNDZuz.jpg, first is the one you've posted, second the one from above with latest ffmpeg [22:35:57 CEST] <realies> could be the diff versions, tbc [22:36:43 CEST] <durandal_1707> use same version of ffmpeg [22:36:46 CEST] <realies> nope, it's the compand parameters [22:37:40 CEST] <kepstin> delsol: on windows the task manager gpu view will show it. On linux, install intel-gpu-tools and use the intel_gpu_top command [22:37:48 CEST] <realies> peaks are identical to the screenshot above when processing using the same ffmpeg version [22:37:54 CEST] <kepstin> (fedora calls it igt-gpu-tools instead) [22:38:32 CEST] Action: realies goes retrying [22:40:18 CEST] <realies> durandal_1707, ignore what i've said :) [22:56:25 CEST] <realies> kepstin, ReplayGain seems to be -14, not -18 LUFS (ITU 1770) :P [22:59:39 CEST] <kepstin> realies: https://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification#Re… explains it [22:59:50 CEST] <kepstin> the replaygain -14 is measured differently, but is close ot -18 LUFS [23:35:37 CEST] <realies> interesting [23:36:34 CEST] <realies> wondering what would be an adequate approach to profile and remove background noise [23:41:32 CEST] <realies> this is to remove background noise from speech [23:58:52 CEST] <realies> arnndn seems pretty interesting, is there any sample models? [00:00:00 CEST] --- Tue Oct 22 2019

1 0