February 2020 - Ffmpeg-devel-irc

ffmpeg-devel.log.20200208
by burek 09 Feb '20

09 Feb '20

[00:21:07 CET] <cone-215> ffmpeg 03Zane van Iperen 07master:3b860bfd6fc9: fate/adpcm: add adpcm_ima_ssi tests

1 0

ffmpeg-devel.log.20200207
by burek 08 Feb '20

08 Feb '20

[10:33:47 CET] <durandal_1707> Lynne: looks like i need that configure patch after all [11:09:50 CET] <cone-559> ffmpeg 03Thilo Borgmann 07master:2ca14d84eefd: lavd/avfoundation.m: Add an option to drop late frames. [11:19:22 CET] <ffmpeguser> Ffmpeg ideas page seems empty for gsoc2020? [11:19:46 CET] <durandal_1707> press reload [11:21:15 CET] <ffmpeguser> I can see only 1 idea in the list [11:21:31 CET] <durandal_1707> yes, do you have own idea? [11:22:18 CET] <ffmpeguser> Not sure, what are the criteria for selection of ideas? [11:22:53 CET] <durandal_1707> that idea is not out of scope of project [11:23:14 CET] <durandal_1707> like writing GUI for text editor [11:24:10 CET] <ffmpeguser> Is there gui version of ffmpeg? [11:24:29 CET] <durandal_1707> only bad attempts [11:31:31 CET] <thardin> handbrake maybe [11:40:27 CET] <durandal_1707> perfect multiband dynamic normalizer: "acrossover=150[b][t];[b]dynaudnorm=m=100:b=1[b];[b][t]amix" [12:13:59 CET] <cone-648> ffmpeg 03Paul B Mahol 07master:cd671ea08351: avfilter/af_acrossover: add slice threading support [12:13:59 CET] <cone-648> ffmpeg 03Paul B Mahol 07master:7e8721e98e91: avfilter/af_acrossover: free all output frames on error [12:26:00 CET] <durandal_1707> why it takes so long to post results of ffmpeg-meeting? [12:36:08 CET] <cone-648> ffmpeg 03Andreas Rheinhardt 07master:0f0f2ab0c3b3: avcodec/cavsdsp: Fix undefined left shifts of negative numbers [16:08:06 CET] <Lynne> does anyone have a 960 sample aac file thats not latm and not hevc? [16:08:19 CET] <Lynne> err, he-aac [16:26:09 CET] <kierank> afaik dab+ is he-aac [16:26:14 CET] <kierank> so maybe they have reference samples [16:28:10 CET] <jamrial> Lynne: maybe https://0x0.st/iieW.m4a [16:44:25 CET] <Lynne> jamrial: no, its he-aac but signalled as aac-lc in the container [17:02:26 CET] <durandal_1707> why it takes so long to post results of ffmpeg-meeting? [17:06:36 CET] <Lynne> nothing was decided, only to start new votes to elect memebers is all [17:10:20 CET] <cone-426> ffmpeg 03Paul B Mahol 07master:ae5a43530036: avfilter: add afirsrc filter [17:13:49 CET] <durandal_1707> so nobody have ideas for GSOC this year? [17:14:24 CET] <durandal_1707> Lynne: are you against my configure patch that fixes linking order? [17:18:10 CET] <thilo> durandal_1707: porting more filters to vulcan as a project [17:19:02 CET] <durandal_1707> ok, who will be mentor for that one? [17:21:33 CET] <Lynne> durandal_1707: no, just haven't seen it on the ml [17:21:45 CET] <thilo> none yet, proposed to Lynne - but many could mentor that [17:23:34 CET] <Lynne> durandal_1707: saw it, lgtm, just push it [17:23:57 CET] <durandal_1707> ok, thanks! [17:24:25 CET] <Lynne> (I don't think glslang devs know what linking order is, or even what linking is, since you must link to pthreads even though its not in ldflags) [17:25:44 CET] <cone-426> ffmpeg 03Paul B Mahol 07master:2b61c908b1a1: configure: fix order of linking for libglslang [17:37:34 CET] <cone-426> ffmpeg 03Anton Khirnov 07master:af1f1e866541: ac3enc: drop a global variable [17:51:51 CET] <mindfreeze> Hi, [17:51:51 CET] <mindfreeze> Is having AVIF into FFmpeg solid enough for a summer of code work ? (https://trac.ffmpeg.org/ticket/7621) [17:52:45 CET] <durandal_1707> isnt that thing for dav1d? [17:55:27 CET] <Lynne> as long as carl doesn't mentor it again and somehow external API users use the new API [17:56:37 CET] <mindfreeze> durandal_1707: AFAIK, AVIF is a image format from AV1 with better quality trade-off, [17:56:37 CET] <mindfreeze> https://aomediacodec.github.io/av1-avif/ [17:56:37 CET] <mindfreeze> So I was wondering, like to have support to have avif into ffmepg, so there would be some better use-cases like this [17:57:05 CET] <durandal_1707> mind you there is no native decoder for av1 in ffmpeg [17:57:56 CET] <kierank> Oh no what a shame [17:59:02 CET] <j-b> Seeing that soon dav1d will have more asm than the whole libavcodec... [17:59:09 CET] <durandal_1707> haha [17:59:34 CET] <j-b> Not a joke. [17:59:48 CET] <durandal_1707> it is funny little project [18:00:18 CET] <j-b> 54633 x86 asm=41795,ansic=12838 [18:00:25 CET] <j-b> 27819 arm asm=24752,ansic=3067 [18:00:32 CET] <j-b> 14107 aarch64 asm=12719,ansic=1388 [18:01:16 CET] <j-b> that's 80k of asm [18:01:50 CET] <rcombs> is there more duplication or something [18:02:01 CET] <durandal_1707> new quant computers will make all that obsolete [18:07:27 CET] <rcombs> just as soon as we figure out how to decompress video by factoring large integers [18:08:14 CET] <j-b> rcombs: I don't think so. [18:09:21 CET] <Gramner> rcombs: not a lot of duplication, no. in fact a lot of effort is spent trying to minimize binary size [18:09:25 CET] <j-b> dav1d is currently at 66k of asm [18:10:02 CET] <rcombs> does AV1 have more routines that are well-suited to asm than most codecs, or something? or is the project just really willing to write asm for more complex branching or non-leaf routines where lavc tends to stick to C? [18:10:35 CET] <Gramner> each new generation of codecs will have more features than the previous one, which means more DSP code to write [18:11:12 CET] <Gramner> it's also more optimized than most libavcodec stuff [18:11:41 CET] <rcombs> mm, impressive [18:16:25 CET] <durandal_1707> how much time it takes to build dav1d with nasm 2.15-rc0 ? [18:16:36 CET] <durandal_1707> it takes eternity here [18:18:01 CET] <Gramner> 11 seconds for me [18:18:12 CET] <durandal_1707> with same nasm version? [18:18:26 CET] <durandal_1707> it passed more than minute here [18:18:41 CET] <Gramner> that was with 2.14 [18:19:29 CET] <durandal_1707> it unbuildable with rc15 [18:21:07 CET] <JEEB> reminds me of yasm having a small hash map with x264 [18:21:12 CET] <JEEB> so [18:21:30 CET] <JEEB> i would recommend posting your results to nasm project [18:21:41 CET] <JEEB> since it seems like a perf regression? [18:22:03 CET] <Gramner> just tried git master of nasm, works fine [18:22:37 CET] <jamrial> latest snapshot seems to take a long time to compile dav1d, yeah [18:22:40 CET] <jamrial> https://www.nasm.us/pub/nasm/snapshots/latest/ [18:23:00 CET] <Gramner> no difference in compilation time of git master vs 2.14 for me [18:23:02 CET] <jamrial> from October 2019, though [18:23:23 CET] <Gramner> last nasm commit was in october 2019 so [18:23:32 CET] <jamrial> also a crapload of warnings from -w+macro-params-multi [18:24:45 CET] <Gramner> huh. no warnings here (on linux) [18:24:49 CET] <jamrial> Gramner: tried their precompiled win64 binary. dunno what durandal_1707 used [18:26:57 CET] <jamrial> Gramner: https://pastebin.com/raw/pPDRj5f2 [18:27:05 CET] <jamrial> fails on msac.asm, then freezes with cdef.asm [18:27:27 CET] <jamrial> probably not imporant until an actual rc is released, though [18:27:35 CET] <Gramner> I guess they broke windows [18:27:48 CET] <Gramner> note that historically nasm rc versions have had a lot of bugs [18:28:34 CET] <Gramner> I'm guessing the devs doesn't use windows so breaking that probably goes unnoticed for a while [18:29:44 CET] <nevcairiel> i wonder if nasm+msvc can build ffmpeg yet properly, it produced some object file that the msvc linker doesnt like in some situations [18:30:58 CET] <durandal_1707> NASM version 2.14.03rc2 compiled on Feb 7 2020 [18:31:02 CET] <durandal_1707> that one works [18:31:17 CET] <durandal_1707> lates 2.15 rc does not, ubuntu [18:32:10 CET] <durandal_1707> huh, but this 2.14 nasm version segv when building ffmpeg asm code [18:35:49 CET] <durandal_1707> this NASM is piece of shit [18:36:06 CET] <Gramner> just use a release version instead of rc:s [18:38:11 CET] <durandal_1707> ok [18:38:45 CET] <Gramner> 2.14.02 is the latest, and I think that should be good on linux/windows/macos [18:41:52 CET] <durandal_1707> yes [18:49:14 CET] <wbs> jamrial: is 1/3 of the fdk-aac settings tweak (and the updated 2/3) ok? [18:53:42 CET] <wbs> rcombs: re dav1d asm, there's just sooo many dsp functions, and so many variants of them. and for itx, there's 4x4 up to 64x64, with rectangular forms for all shapes with aspects 2:1, 4:1, 1:2, 1:4, and all transforms up to 16x16 come in combinations of {dct, adst, flipadst, idenity} as both horizontal and vertical transforms for all transform sizes up to 16x16 [18:54:07 CET] <rcombs> wow [18:54:17 CET] <jamrial> wbs: isn't 1/3 what the avctx->delay field is for? [18:54:21 CET] <rcombs> guess the variants aren't that macroize-able? [18:54:44 CET] <durandal_1707> assembly <<<<< rust [18:55:18 CET] <Gramner> partially macroizable [18:56:19 CET] <wbs> rcombs: they can share a reasonable amount of code (like just having one idct4, iadst4, flipadst4, identity4, idct8, ... and so on, and separate skeletons for each shape - but it's still a metric shitton of code [18:56:28 CET] <rcombs> mmm [18:56:43 CET] <wbs> rcombs: checkasm lists 433 different tested functions [18:57:02 CET] <wbs> and then there'll be 433 new cases for 10 bit [18:57:03 CET] <Gramner> also the avx2 ones macroizes less due to doing multiple lines per register for narrow sizes [18:57:07 CET] <wbs> :-( [18:58:07 CET] <wbs> jamrial: hmm, I'll have to check what it does - does some framework level code apply it on the timestamps? [19:02:12 CET] <jamrial> wbs: apparently it's to discard samples before the first valid one, so i'm not sure [19:17:39 CET] <Lynne> yeah, one thing which I don't like about av1 is how you can have different transforms for w/h of a block [19:18:50 CET] <Lynne> its so incredibly niche, most don't keep coefficients in a purely frequency domain and the signalling costs aren't cheap [19:19:21 CET] <Lynne> then you feed the not-entirely-frequency-domain coeffs into a zigzag which doesn't really adapt at all and you get a mess [19:21:06 CET] <Lynne> oh, and the qcoeff encoding process relies on knowing and minimizing the last non-zero coeff, which is only valid for when your coeffs are in a normal pure dct domain [19:24:14 CET] <Lynne> the quantization is still a scalar div so it feels like every single coding tool keeps the div quantization on life support [19:26:07 CET] <Lynne> it gets better though, the coefficient coder is kinda nerfed partly because of political reasons so it uses miniature CDFs [19:27:27 CET] <Lynne> I'm betting it will be replaced by something different in av2 which will use bigger cdfs, then you'll see why an avx2 adapt16 was needed [19:27:43 CET] <Gramner> that part is weird, yes [19:27:55 CET] <Lynne> speaking of that, I still disagree with having 3 separate decoding functions for differently sized CDFs [19:28:08 CET] <Lynne> just have 1 and have branches [19:28:09 CET] <Gramner> e.g. the hi_tok decoding. "let's do a bunch of width-4 entropy decode steps in a loop" [19:28:20 CET] <Gramner> instead of just doing them all at once in parallel [19:28:53 CET] <Lynne> before google conceded lvmap coded entirely boolean symbols [19:29:15 CET] <Lynne> and even when they did concede cisco did the work to use the multisymbol coder [19:29:45 CET] <Lynne> I think a reason why they conceded was because coding a tree of booleans is kinda sorta what cabac does [19:30:46 CET] <Gramner> uh, why would you want to have a bunch of extra branches at run time for things that are known at compile time? [19:31:36 CET] <Gramner> in a function that's called billions of times [19:34:33 CET] <Lynne> you actually don't, you can have just 1 version of the function [19:34:50 CET] <Lynne> saves binary space too and removes around 200 lines of asm [19:36:11 CET] <Lynne> and being called billions of times means that you'll keep the instructions of the function in the instruction cache for longer [19:36:53 CET] <cone-426> ffmpeg 03Paul B Mahol 07master:bfdd6304fbd4: avfilter/af_crystalizer: add slice threading support [19:37:56 CET] <Lynne> I mean look at the benchmark, the difference between adapt4, adapt8 and adapt16 (avx2) is minimal [19:38:19 CET] <Lynne> 0.2 decicycles for adapt8 <- adapt16_avx2 [19:38:32 CET] <Lynne> for 1<<22 runs [19:45:54 CET] <Gramner> the main reason for having multiple sizes it that the load/store sizes are different. you can't just replace a call to the size-4 function with one to size-16. also the binary size of those functions are absolutely tiny (<100 bytes for size-8) [19:48:04 CET] <Lynne> you can just make all CDFs 32 bytes [19:49:24 CET] <Gramner> which wastes an order of magniture more cache then what you save from eliminating a small bit of code [19:52:24 CET] <Gramner> actually more like >2 orders of magnitude [19:52:41 CET] <Gramner> if not even 3 [19:52:43 CET] <Lynne> yeah, but you don't really keep CDFs around for long in memory [19:54:44 CET] <Lynne> and its not like you waste that much space, the CDF sizes are already somewhat aligned to the nearest 64 bits for adapt4 and 128bits for adapt8 [20:08:28 CET] <wbs> jamrial: yeah, doesn't look like avctx->delay's documentation matches this case [20:11:56 CET] <kurosu> hey, hardcore entropy coding discussions in my #ffmpeg-devel? too many channels to keep up with [20:20:43 CET] <Lynne> speaking of that stuff the uncompressed header should have been entropy coded with fixed probabilities [20:22:08 CET] <Lynne> and no trailing bits, mandatory zero bits or anything of that [20:22:28 CET] <kurosu> a bit harder to parse, maybe? though I don't have the details in mind, so I may be mistaken [20:22:36 CET] <kurosu> as long as the important stuff comes first [20:26:18 CET] <Lynne> they just didn't want people to have to implement 10 lines of EC decoding code to parse the header [21:22:33 CET] <darkapex> would a flif encoder/decoder make a good gsoc project? also using libflif v/s native lavc implementation? [21:23:01 CET] <darkapex> i would like to mentor it as well if it seems useful [21:23:41 CET] <durandal_1707> i do not think flif is stable? [21:24:32 CET] <darkapex> hmm yeah just saw. v0.3 hmm [21:47:17 CET] <thilo> could be added as experimental until stable is reached [21:48:44 CET] <Lynne> we generally don't have experimental decoders [21:54:39 CET] <thilo> AFAICT they called their v0.2 from 2016 "stable" already... "The latest stable version is FLIF16 and is documented here." [21:57:50 CET] <darkapex> yeah i was going through their spec and it looks ok https://flif.info/spec.html . but the reference decoder/encoder don't seem that great. [21:58:51 CET] <thilo> then it might be even more worth doing and maybe push the format [22:01:08 CET] <darkapex> good point. ill add it on the trac with a short warning that this might have moving (or undefined) parts but still a good learning experience. [22:02:30 CET] <durandal_1707> darkapex: best ask flif devs themselves [22:03:56 CET] <darkapex> durandal_1707: will do thx [22:37:36 CET] <cone-215> ffmpeg 03Paul B Mahol 07master:e3e559829040: avfilter/vf_xfade: add dissolve transition [22:37:36 CET] <cone-215> ffmpeg 03Paul B Mahol 07master:3720153ffca6: aviflter/vf_xfade: add pixelize transition [00:00:00 CET] --- Sat Feb 8 2020

1 0

ffmpeg.log.20200207
by burek 08 Feb '20

08 Feb '20

[00:50:50 CET] <Synoptic> Hi there [00:51:22 CET] <Synoptic> I need to grab /dev/video0 (v4l2) and output it to my rtsp server. [00:52:08 CET] <Synoptic> I can get it to work, but I do not know ffmpeg very well, and all the examples I can find are hard for me to understand. I would like someone that could take me by the hand and help me get what I need. [00:52:42 CET] <Synoptic> ideally, I would like to transcode the input of /dev/video0 to a h264 stream [00:54:23 CET] <Synoptic> brb [01:05:37 CET] <c_14> I recommend reading https://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 and https://ffmpeg.org/ffmpeg-protocols.html#rtsp [01:06:40 CET] <c_14> in general it'll be something like `ffmpeg -f v4l2 -i /dev/video0 -f rtsp rtsp://host/path' [01:07:20 CET] <c_14> any encoder options and the like go after video0 and before rtsp:// [01:07:24 CET] <Synoptic> c_14 : Yes indeed. This works, but the quality it outputs is nowhere near the actual stream from the device. [01:07:45 CET] <Synoptic> c_14 : thank for the tip, will try a bit and see [01:07:54 CET] <c_14> then you want to touch the encoder settings [01:08:12 CET] <Synoptic> let me paste my line on pastebin, ok ? [01:08:28 CET] <c_14> yeah [01:10:08 CET] <Synoptic> https://pastebin.com/mq2080GF [01:11:13 CET] <c_14> you probably want to encode with -c:v libx264 [01:11:33 CET] <c_14> default quality is probably fine for that encoder, but you can play around with it with -crf [01:11:50 CET] <Synoptic> "ffmpeg -f v4l2 -video_size 1920x1080 -i /dev/video0 -r 10 -f -c:v libx264 rtsp rtsp://localhost:8554/unicast" like this ? [01:12:07 CET] <c_14> the -f goes before rtsp and after libx264 [01:12:24 CET] <Synoptic> ok [01:12:53 CET] <Synoptic> ffmpeg -f v4l2 -video_size 1920x1080 -i /dev/video0 -r 10 -c:v libx264 -f rtsp rtsp://localhost:8554/unicast [01:13:31 CET] <c_14> are you purposefully setting the output framerate instead of the input framerate? [01:14:10 CET] <c_14> use -framerate <number> before the input to change the input framerate [01:14:16 CET] <Synoptic> not really. The devic can output 15fps, but with the current line, it shows 5... I was messing around, [01:15:01 CET] <c_14> use -framerate 15 before -i [01:15:36 CET] <c_14> and get rid of the -r 10 [01:17:34 CET] <Synoptic> ok did that, but the command gets killed, let me paste it [01:18:28 CET] <Synoptic> https://pastebin.com/pSYrRcDS [01:18:50 CET] <Synoptic> command was : ffmpeg -f v4l2 -video_size 1920x1080 -framerate 15 -i /dev/video0 -c:v libx264 -f rtsp rtsp://localhost:8554/unicast (forgot to paste it) [01:19:55 CET] <c_14> check the output of dmesg? [01:20:22 CET] <c_14> that killed looks a lot like something the os would do [01:20:25 CET] <Synoptic> out of memory. I am running on a raspberry pi [01:21:50 CET] <Synoptic> maybe we can skip the h264 thing if its too much for the pi, we could maybe just tweak the native mpeg4 format ? [01:21:54 CET] <c_14> check if your ffmpeg has the h264_omx encoder [01:22:06 CET] <c_14> ffmpeg -encoders | grep h264 [01:22:15 CET] <c_14> otherwise you can just boost the mpeg4 encoder's bitrate, yeah [01:23:01 CET] <Synoptic> DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_mmal h264_vdpau ) (encoders: libx264 libx264rgb h264_omx h264_vaapi ) [01:23:13 CET] <Synoptic> its seems to be there [01:23:21 CET] <c_14> then try -c:v h264_omx [01:23:40 CET] <c_14> might need to set -pix_fmt yuv420p or so [01:23:58 CET] <c_14> probably not a terrible idea in either case [01:24:03 CET] <Synoptic> it runs, but fps are stuck around 5 [01:24:19 CET] <Synoptic> Stream #0:0: Video: h264 (h264_omx), yuv420p, 1920x1080, q=2-31, 200 kb/s, 5 fps, 90k tbn, 5 tbc [01:24:36 CET] <furq> Synoptic: pastebin the output of ffmpeg -f v4l2 -list_formats all -i /dev/video0 [01:24:51 CET] <c_14> Synoptic: yeah, I noticed that in the output earlier. You're requesting 15fps but the device is lowering the fps [01:25:15 CET] <c_14> do what furq says and check what exactly the device supports [01:25:26 CET] <Synoptic> furq : https://pastebin.com/UQq9DcyJ [01:26:02 CET] <Synoptic> I could try mjpeg [01:26:07 CET] <furq> is this usb2 [01:26:44 CET] <furq> usb2 wouldn't have the bandwidth for 1080p 4:2:2 at 15fps anyway [01:28:16 CET] <Synoptic> furq : yep, usb2 [01:28:29 CET] <Synoptic> furq : good to know, thnaks [01:28:30 CET] <furq> try ffmpeg -f v4l2 -input_format mjpeg -video_size 1920x1080 -framerate 30 -i /dev/video0 -c copy -f rtsp rtsp:// [01:30:26 CET] <Synoptic> furq : https://pastebin.com/jmgcFKTY [01:30:39 CET] <Synoptic> but I get 15 fps [01:43:45 CET] <Hello71> I think v4l2-ctl is better [01:45:02 CET] <Synoptic> Hello71 : are you talking to me ? [01:45:11 CET] <Hello71> meh [01:47:59 CET] <Synoptic> c_14, furq : I think the PI is just too weak to handle 1080p [02:07:48 CET] <Synoptic> c_14, furq : thanks for your help [12:08:12 CET] <pagios> what is more dominatn a tune zerolatency or a preset ultrafast? [12:08:26 CET] <pagios> do they work together? [12:10:19 CET] <pagios> -preset","uultrafast","-framerate",30,"-g",30,"-hls_init_time",1,"-hls_time",1,' VS -tune","uzerolatency","-framerate",30,"-g",30,"-hls_init_time",1,"-hls_time",1,' [12:52:10 CET] <Tyras> hello... I'm having some issues wne rewrapping video files with ffmpeg. Can't really find anything about these problems.... [12:54:33 CET] <Tyras> the first one, is when rewrapping a h264 video from mpegts to mp4. The input is a CBR h264 video, but the output always comes out as VBR. The CLI I'm using ffmpeg -i video.ts -c copy -f mp4 output.mp4; Is this a known issue? [14:23:31 CET] <tomb^> Hi, I'm trying to concat several files and get the following error: "[mxf @ 000002db09f893c0] inconsistent FooterPartition value: 567259648 != 350554112", "found essence prior to first PartitionPack [14:23:31 CET] <tomb^> concat:c:\0\temp\052d614a-9d97-45bc-bf59-dee0f87a3d01.mxf|c:\0\temp\1ee4a935-2fbc-4b33-9bce-9f9a97f19f65.mxf: Invalid data found when processing input [14:23:48 CET] <tomb^> what am I doing wrong? [18:58:19 CET] <HickHoward> hey [18:59:16 CET] <HickHoward> so i want to know if it's possible to encode a lossless 7.1 audio file into some 7.1 E-AC-3 file through ffmpeg if at all [18:59:56 CET] <microchip_> no, eac3 encoder in ffmpeg is still limited to 6 channels (5.1) [19:00:01 CET] <HickHoward> damn [19:01:49 CET] <HickHoward> as a side note there's this new sound codec i've heard being talked about [19:01:54 CET] <HickHoward> and it's being called LC3 [19:02:17 CET] <HickHoward> apparently it's a new audio codec for bluetooth devices [19:02:49 CET] <microchip_> yup [19:03:13 CET] <microchip_> there's also AC-4 and someone is already working on a decoder for ffmpeg [19:03:40 CET] <HickHoward> nice [19:03:51 CET] <HickHoward> that aside, i already got the source code from ETSI through a link iis.fraunhofer posted on their LC3 page [19:03:58 CET] <HickHoward> seems rather generous for them to do that [19:06:04 CET] <JEEB> HickHoward: fraunhofer (generally) has some code, which often isn't compatible with other projects' licensing [19:06:27 CET] <JEEB> so you can have the source code, but whether someone can utilize that code for an open source project depends on how they licensed it [19:07:06 CET] <HickHoward> i was just picking that source code for myself [19:07:17 CET] <HickHoward> i have no intention to spread it aboard, which means i might not even [19:07:26 CET] <HickHoward> be able to keep that code [19:07:41 CET] <HickHoward> for how many years [19:08:08 CET] <JEEB> what I'm saying is that fraunhofer might have some issues as an organization, but they generally are less bad than those companies that mostly depend on forcing people to utilize their implementation [19:08:21 CET] <JEEB> *cough* dolby, dts *cough* [19:09:13 CET] <HickHoward> i guess apple doesn't count...? [19:09:45 CET] <JEEB> I think apple just generally doesn't do much of those. it's mostly been prores so far? [19:09:51 CET] <pink_mist> alac? [19:09:52 CET] <JEEB> apple just generally doesn't play well with other kids in the sandbox [19:09:57 CET] <JEEB> right, that too [19:10:10 CET] <HickHoward> maybe i need to do more research on the "forcing people" part [19:10:38 CET] <pink_mist> not sure if quicktime was like that [19:10:57 CET] <JEEB> QT file format was actually quite well documented [19:11:03 CET] <JEEB> see qtff.pdf [19:12:04 CET] <JEEB> anyways, apple has at least during the last 15 or so years that I remember been less of a patent licensing and sales buzzword thing with regards to multimedia formats. they buzzword their products up, sure [19:12:36 CET] <JEEB> but generally speaking they have only tried to get places to use their decoder with regards to prores [19:13:13 CET] <JEEB> and that hasn't been "let's throw some nice legal threats at places" level :) [19:13:50 CET] <HickHoward> i haven't seen much from apple at all [19:14:02 CET] <HickHoward> at the very least, not much insanity as far as i can tell [19:16:50 CET] <HickHoward> in any case i've somehow managed to get a part of EC3plus compiled into an exe using VS2019 [19:17:09 CET] <HickHoward> code had some issues here and there but nothing i can't fix any time soon [19:20:57 CET] <HickHoward> oh, another question [19:21:17 CET] <HickHoward> i want to know if Dolby AC-4 supports source files that are supposed to be using some Dolby Atmos technology? [19:22:34 CET] <JEEB> how does that matter if it's an ac-4 decoder? if it's a valid ac-4 stream it would get decoded [19:22:43 CET] <HickHoward> i ask this because Netflix released another open-source "movie" called Nocturne [19:23:22 CET] <HickHoward> they've even released some lossless assets related to that movie in question, including an .wav file designed to be encoded into an Dolby Atmos stream [19:24:05 CET] <JEEB> dolby generally doesn't put their "atmos" stuff into parts of their stuff that is standardized [19:24:21 CET] <JEEB> also the "atmos" keyword is highly overloaded at dolby jus like dolby vision [19:24:27 CET] <HickHoward> damn [19:24:52 CET] <JEEB> I think the funniest was TrueHD where they just expected a decoder to not try to decode all of the things from a stream [19:25:09 CET] <JEEB> and they just stuck some random data onto one of the data streams [19:25:14 CET] <JEEB> so you actually have to actively ignore that [19:25:29 CET] <JEEB> or get the otherwise ok truehd stream output garbage [19:25:51 CET] <HickHoward> so basically Dolby Atmos is a big nothing burger [19:26:06 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=dc2d0e06af459af9a7f91b65e0… [19:26:30 CET] <HickHoward> makes sense [19:26:50 CET] <JEEB> HickHoward: it's sales keywords, classic dolby style. also dolby is well known for skipping parts of their stuff in the specifications that they publish [19:27:02 CET] <JEEB> because they don't expect anyone to actually implement it. you pay dolby and you get a decoder :P [19:27:25 CET] <JEEB> I think DTS did the same? [19:28:15 CET] <JEEB> because DTS had to publish "a spec" (that looked good enough to pass a glancing look) for broadcast use of DTS-XLL (lossless extensions, aka "DTS HD-MA") [19:28:24 CET] <JEEB> and dolby for AC-4 as well [19:29:00 CET] <HickHoward> these companies must really suck [19:29:37 CET] <HickHoward> release a bare-bones PR book and call it "a spec" [19:30:02 CET] <HickHoward> though i don't really think that's the intent there [19:30:20 CET] <JEEB> the specs generally seem to go technical enough [19:30:35 CET] <JEEB> it's just that at some point you notice that something in the middle is conveniently missing [19:31:33 CET] <JEEB> anyways, for the sales pitch things you generally can find related documentation from... patents [19:31:52 CET] <HickHoward> patents [19:32:09 CET] <JEEB> like f.ex. certain dolby HDMI packets' struct definition is... in a patent :P [19:32:42 CET] <HickHoward> i'm guessing patents describe these kinds of technologies at more detail? [19:33:11 CET] <rcombs> I still want to discuss marking FDKAAC as non-nonfree [19:33:13 CET] <JEEB> if you find them, you can quite possibly gain one step closer to figuring out what is behind the buzzwords [19:35:08 CET] <HickHoward> i suppose that's somewhat helpful [19:35:11 CET] <HickHoward> if it is at all [19:35:46 CET] <JEEB> rcombs: you're free to do that. I think some time ago I joined some discussion that was about that [19:35:58 CET] <JEEB> would have to recall things from the logs what it was that time [19:36:14 CET] <rcombs> I just dunno whose buy-in it needs [19:37:12 CET] <furq> did they change the license or is someone just interpreting it more charitably [19:37:19 CET] <rcombs> the latter [19:37:27 CET] <JEEB> I don't even remember if the discussion was about the fedora patched version or the original [19:37:48 CET] <JEEB> since fedora OK'd a version which was without LC-AAC. although I'm not sure if they link it against GPL stuff? [19:37:58 CET] <rcombs> red hat's interpretation is that the patent clause is a no-op if you use a version of the decoder without HE, since LC's expired [19:37:59 CET] <JEEB> LGPL is OK even atm with configure? [19:38:09 CET] <JEEB> yea [19:38:13 CET] <rcombs> our lawyer's interpretation is that the patent clause is a no-op period [19:38:35 CET] <rcombs> because it's essentially just a "you have to follow local law", which doesn't actually do anything [19:38:41 CET] <rcombs> (you have to follow local law anyway) [23:16:23 CET] <MerlinTheWizard> Hi all. [23:16:53 CET] <MerlinTheWizard> Can anyone tell me what is the limit of precision for the -framerate option while encoding a video from still frames?' [23:40:29 CET] <furq> i don't think there is one [23:42:50 CET] <MerlinTheWizard> furq, is there a limit defined on a per codec basis? And if so, is there an easy way to find it? [23:43:26 CET] <BtbN> codecs don't care about framerate [23:43:28 CET] <BtbN> they just encode frames [23:43:38 CET] <furq> the limit would normally be on the container level if there is one [23:43:50 CET] <furq> any decent container won't care though [23:44:17 CET] <MerlinTheWizard> furq, ok. So I can throw any decimal number at it and it should usually be fine. [23:44:20 CET] <MerlinTheWizard> Okay, thanks [23:44:41 CET] <BtbN> keep in mind that very non standard FPS might not be treated the way you expect it to by whatever plays or decode that [23:44:43 CET] <furq> if you're worried about losing precision then use a rational number [23:44:53 CET] <furq> also yeah players probably won't handle 0.00001fps very nicely [23:45:15 CET] <furq> specifically seeking [23:45:54 CET] <MerlinTheWizard> furq, okay, so don't use a ridiculous framerate... And how do I specify a rational number? Just decimal, right? [23:46:06 CET] <furq> -framerate 12/34 [23:46:20 CET] <MerlinTheWizard> Oh, that works? That's even better. [23:46:23 CET] <MerlinTheWizard> Thanks a lot. [00:00:00 CET] --- Sat Feb 8 2020

1 0

ffmpeg-devel.log.20200206
by burek 07 Feb '20

07 Feb '20

[02:58:44 CET] <cone-044> ffmpeg 03James Almer 07master:2383021a7a1c: avcodec/aptx: split decoder and encoder into separate files [08:29:33 CET] <thardin> maybe add an option to link with libtiff? [08:32:09 CET] <thardin> I wonder if there's any TIFF bombs in the wild.. [08:34:40 CET] <thardin> goodie, it's based around pointers+lengths [14:28:21 CET] <cone-146> ffmpeg 03James Almer 07master:616e9b5cff69: avfilter/Makefile: add vulkan.h to the list of skipped headers [15:45:33 CET] <cone-146> ffmpeg 03Paul B Mahol 07master:270068b5af28: avfilter/af_acrossover: improve filter output [16:53:35 CET] <Lynne> philipl: could you look at ^^ [17:08:06 CET] <durandal_1707> anybody working on pad_vulkan filter? [17:08:56 CET] <cone-146> ffmpeg 03Praveen Karadugattu 07master:31d7b17c4671: avcodec/hevc: add support for Frame Duplication (Doubling/Tripling) [17:09:49 CET] <Lynne> durandal_1707: you can emulate it for now using the overlay filter [17:10:07 CET] <durandal_1707> that is awful [17:10:18 CET] <durandal_1707> solution [17:10:41 CET] <Lynne> no hw filter has a pad filter so I guess no one really needed one so far [17:11:11 CET] <durandal_1707> someone complained on trac and on ml long ago [17:12:33 CET] <durandal_1707> i know how to do it, but i wonder if there is faster way to do it? [17:14:16 CET] <Lynne> there isn't realloc for vulkan memory so you have to memcpy [17:15:23 CET] <Lynne> I'm kind of interested in someone writing an in-place filter [17:15:27 CET] <durandal_1707> i thought just to do kernel which would set color to input or fixed color... [17:15:29 CET] <Lynne> be it me or someone else [17:15:55 CET] <Lynne> the framework supports it and I did test that it works, could write vf_eq_vulkan maybe [17:16:22 CET] <Lynne> durandal_1707: vf_pad pads the video, as in its actual size, doesn't it? [17:16:55 CET] <durandal_1707> pad=W:H:X:Y... [17:17:04 CET] <durandal_1707> its absolute pad [17:20:36 CET] <JEEB> hmm... I wonder if we have an issue with the DVB subtitle decoder, or if this stream is broken [17:21:09 CET] <JEEB> apparently if I start playback on a point where the DVB subtitles are of SD size, things are fine (there's a switch to full-HD bitmaps during *commercials* and then back to SD) [17:21:28 CET] <JEEB> but if I start during the HD part (commercials) I get ayy lmao [17:22:01 CET] <JEEB> so the subtitles end up as SD on top of a HD """bitmap""" [17:22:13 CET] <JEEB> after the couple of HD lines which show up properly are shown [17:27:17 CET] <cone-146> ffmpeg 03Zane van Iperen 07master:5d038a86d69c: avcodec: add decoder for Simon & Schuster Interactive's ADPCM variant [17:27:18 CET] <cone-146> ffmpeg 03Zane van Iperen 07master:343ccfcc4deb: avformat: add demuxer for Simon & Schuster Interactive's VAG format [17:34:42 CET] <Polochon_street> hi! I'm maintaining something that uses ffmpeg, and I kinda want to remove `av_register_all()` since it's deprecated, but my CI uses Ubuntu 18.04, so the ffmpeg version is less recent [17:35:03 CET] <Polochon_street> what do you think would be the prettiest fix? Just leave `av_register_all()` until my CI gets an update? Or something else? [17:37:43 CET] <philipl> Lynne: I have looked. I think it's just the lack of setting the hwaccel_output_format, which everyone forgets. [17:37:46 CET] <philipl> I added a comment. [17:39:05 CET] <Lynne> yeah, I saw that, its weird how by default -hwaccel outputs to software [17:39:39 CET] <Lynne> Polochon_street: just leave it until it updates [17:39:58 CET] <Polochon_street> alright. Thanks :) [17:42:29 CET] <kurosu> Lynne / philipl: that is for vaapi or anything hwaccel? because I have a user-level question about dxva2 then (which maybe nevcairiel may know to answer as well) from a few days back [17:43:17 CET] <kurosu> Basically, to decode a video using GPU, then encoding to HEVC Main10 using x265, I have come up with: ffmpeg -hwaccel dxva2 -threads 1 -i <input> -sn -an -pix_fmt yuv420p10le -c:v libx265 <options> -y out.mkv [17:43:58 CET] <kurosu> when testing, I wasn't so sure it was actually using the gpu (forgot to log) [18:31:09 CET] <philipl> kurosu: it will be decoding with the GPU, but copying back to system memory implicitly. If you turn the log level up, you should see the hwaccel in use. [18:37:33 CET] <kurosu> yeah, that's what I told myself once I saw it was kind of a dumb question, thanks [18:37:40 CET] <kurosu> (haven't checked yet) [18:40:38 CET] <nevcairiel> well with a software encoder you have to copy back eventually, but it should leave some extra cpu free [21:16:31 CET] <Lynne> I do wonder why someone would use scale_vulkan instead of scale_cuda [21:16:56 CET] <Lynne> lack of llvm or that nvidia library? [21:17:22 CET] <nevcairiel> or just a general lack of knowledge and assuming the vulkan is just awesome for everything [00:00:00 CET] --- Fri Feb 7 2020

1 0

ffmpeg.log.20200206
by burek 07 Feb '20

07 Feb '20

[01:21:48 CET] <relaxed> nickname123: can you pastbin.com a command and the output so I can reproduce? [01:21:59 CET] <relaxed> er, pastebin [07:01:54 CET] <sagax> hi all! [07:02:05 CET] <sagax> i can make video from picture with ffmpeg [07:02:10 CET] <sagax> and it's great for m [07:02:12 CET] <sagax> e [07:02:38 CET] <sagax> but - how to make video from picture and move picture? [07:38:04 CET] <funyun> hi. i use minterpolate to encode 30fps vids to 60fps. but i have one video which has some incorrect interpolation already used. how would i go about removing every other frame and then using minterpolate to go from 30fps to 60fps? [13:29:47 CET] <funyun> hi. how can i remove every even frame of a video? [13:30:15 CET] <BtbN> halve the fps [13:30:39 CET] <BtbN> though that will only remove every other frame, no guarantee about even or odd numbered ones [13:30:55 CET] <BtbN> But I guess if you skip the first one, it will adjust [13:31:14 CET] <funyun> BtbN: thanks [13:41:48 CET] <zerodefect> In hlsenc.c, I see there are some flags one can set for example 'temp_file'. How do I use av_dict_set() to set that? av_dict_set(&pHeaderOptions, "temp_file", 1, 0); ? [13:45:05 CET] <BtbN> What do you mean? [13:46:12 CET] <zerodefect> I notice that it's a flag. I do enable toggle that particular bit on the flag? [13:46:26 CET] <zerodefect> *How do I toggle that... [13:50:45 CET] <zerodefect> Hmmm. mIRC is giving me problems. I think I'm going to restart and try again. It keeps freezing for a few seconds. [13:52:31 CET] <BtbN> It's a flag to the -flags options. [13:52:38 CET] <BtbN> -s [14:57:05 CET] <void09> what is the scalabilty of ffmpeg livestream encoding ? how many cores it can use, with x264/x265 ? assuming one wants zerolatency [14:57:33 CET] <durandal_1707> zerolatency does not exist [15:00:18 CET] <void09> durandal_1707: i mean the -zerolatency tune parameter :P [15:17:47 CET] <kurosu> void09: the scalability, baring you don't use too many filters, is mainly dictated by the library/codec, its settings, and the resolution [15:18:31 CET] <kurosu> basically, codecs can't cut things into too many pieces (eg x265 will probably use 64 pixels wide stuff) [15:18:41 CET] <kurosu> *block-based codecs [15:20:11 CET] <kurosu> iirc, you get very diminishing returns with x265 above 8 cores and 1080p [15:21:04 CET] <DHE> yeah, multi-core encoding will require slice based encoding to work. scaling will be poor [15:25:30 CET] <pagios> hi all, i am trying to achieve the lowest latency with an acceptable quality, using 30fps from source with 2.5kbps bitrate, on receiving side using a command with -g 30 , -framrate 3- . hls_init_time 1 hls_time 1 -hls flags delete segments, hls_list_size, is there any way to lower latency while preserving quality? [15:27:36 CET] <Mavrik> Can you switch away from HLS? [15:27:41 CET] <Mavrik> That will buy you way more than any settings. [15:27:56 CET] <Mavrik> Also smaller GOP and smaller segments would help I guess. [15:27:58 CET] <pagios> Mavrik, i agree with you [15:28:06 CET] <pagios> its a requirement... not my product [15:28:27 CET] <pagios> Mavrik, since i am using 30fps, would it make sense to lowe the -g ? [15:28:30 CET] <DHE> for HLS, 1 second is about as small as I think you can get away with [15:28:46 CET] <pagios> DHE, so what can be optimized in the above? [15:29:40 CET] <DHE> some encoder settings may help. x264 (I assume that's what you're using) defaults to buffering a lot of frames. but at the same time you don't want to overdo it because quality suffers [15:30:08 CET] <pagios> DHE, you mean from the client software that is encoding? [15:30:27 CET] <pagios> or from ffmpeg that is receiving the stream? [15:30:45 CET] <pagios> and yes i am using x264 [15:32:38 CET] <DHE> fun experiment: run a test encode with ffmpeg, but make 2 small changes: input from a file rather than whatever live source you're using, and use -preset:v placebo [15:32:55 CET] <Mavrik> I don't think you can get away from the fact [15:32:58 CET] <Mavrik> That your segments are 1 full second [15:33:05 CET] <pagios> forgot to meantion its a livestream [15:33:14 CET] <DHE> that much was obvious [15:33:26 CET] <pagios> DHE, should i play with the gop/ [15:33:58 CET] <DHE> back to the experiment: when you see the ffmpeg progress message updating, press 'Q' to shut down, but watch how long it takes to actually stop and exit. estimate how many frames it encoded during this shutdown phase [15:34:02 CET] <DHE> no. god no. [15:34:24 CET] <durandal_1707> best meme [15:34:24 CET] <Mavrik> We've been running low-latency video at 15 or even 10 GOP to get lag down. [15:34:32 CET] <Mavrik> With obvious quality effects. [15:34:38 CET] <Mavrik> But there has to be punishment for using apple stuff [15:34:39 CET] <Mavrik> :P [15:34:42 CET] <pagios> Mavrik, what fps? [15:34:52 CET] <Mavrik> 30 mostly [15:34:55 CET] <DHE> yeah but the HLS driver will still write 1 second increments, so you'll just have 2 or 3 GOPs in a single file [15:35:13 CET] <DHE> so you'd have to set -hls_time 0.5 or such [15:35:19 CET] <DHE> at which point I will begin crying [15:35:23 CET] <pagios> haha [15:35:41 CET] <Mavrik> DHE, yeah, we didn't use ffmpegs muxer but our own [15:35:44 CET] <pagios> so what can i do? [15:35:46 CET] <Mavrik> But obviously you need smaller segments. [15:35:51 CET] <Mavrik> Since HLS is shitty like that. [15:36:07 CET] <DHE> if you want to go whole ham on experimentation, you can try: -tune zerolatency [15:36:23 CET] <DHE> I do NOT recommend this for real video streaming, but for testing see how much this improves your latency [15:36:42 CET] <DHE> if the results are staggering, then there are other x264 parameters that can be adjusted [15:37:31 CET] <pagios> DHE, i tried the zerolatency it sucks had issues [15:37:40 CET] <pagios> so what params can i check in x264 [15:37:59 CET] <DHE> never mind the quality of zerolatency. how was the latency? [15:38:40 CET] <pagios> the stream didnt go up honestly [15:38:53 CET] <pagios> cpu suffered [15:39:13 CET] <furq> i don't think zerolatency will ever make a difference with hls [15:39:20 CET] <furq> since the player always buffers two segments ahead anyway [15:39:24 CET] <DHE> furq: I want to quantify that first though [15:39:41 CET] <DHE> x264 will buffer enormous amounts of frames in memory for its own rate control if not manage [15:39:43 CET] <DHE> *managed [15:45:25 CET] <Mavrik> DHE, does zerolatency actually do anything on HLS? [15:45:35 CET] <Mavrik> Since that just improves the encoding pipeline. [15:45:50 CET] <Mavrik> But if the client grabs a 1sec old segment, no zerolatency will help. [15:46:01 CET] <furq> well if it's a live input then improving the encoding pipeline will push segments out faster [15:46:08 CET] <furq> which i assume it is [15:50:14 CET] <furq> i'm not sure how i feel about describing disabling lookahead as "improving the encoding pipeline" but you know what i mean [15:53:01 CET] <DHE> ^^ all of that [15:54:11 CET] <DHE> x264, depending on settings and presets, will absolutely buffer 40-60 frames within itself for rate control reasons. with live content that's 1.3 to 2 seconds of additional latency that could be eliminated with zerolatency [15:54:41 CET] <DHE> in practice I would just reduce the number of buffered frames way down, maybe 10 or 20. zerolatency mode sets this to 0 along with a bunch of other things [16:04:50 CET] <pagios> so to sum up, cant do anything? [16:29:46 CET] <pagios> DHE, you meantioned some x264 i can play with what are they [16:30:37 CET] <DHE> pagios: -x264-params rc-lookahead=15 # or maybe 10 [16:30:58 CET] <DHE> zerolatency mode sets this to 0. don't do it quite that extreme [16:34:07 CET] <furq> yeah zerolatency also disables bframes and cabac and some other stuff that will kill quality but make no difference here [16:34:22 CET] <furq> and frame threading which might make a small difference but probably not enough to matter [16:36:04 CET] <DHE> should still allow frame slicing, which isn't ideal but it better than nothing [16:40:26 CET] <furq> pagios: probably also use the lowest -threads value you can get away with [16:40:47 CET] <pagios> -threads 0 ? [16:40:51 CET] <furq> no that's auto [16:40:56 CET] <furq> that's the same as not setting it [16:41:06 CET] <pagios> -threads 1 ? [16:41:14 CET] <furq> if you can encode in realtime with one thread then sure [16:41:26 CET] <furq> iirc with frame threading, every thread is +1 frame of latency [16:41:42 CET] <furq> so if this is a 16-core box or something then that's going to be ~24 frames [16:42:16 CET] <pagios> its a virtual machine :D with 2 cpu [16:42:24 CET] <furq> nvm then [16:42:50 CET] <pagios> should i use 1 thread with 2 cpu or better to leave it 0 [16:43:01 CET] <furq> i wouldn't touch it if you only have two cores [16:44:17 CET] <pagios> -x264-params rc-lookahead=15 tune zerolatency so this [16:44:36 CET] <DHE> *thunk* [16:44:39 CET] <furq> zerolatency implies lookahead 0 [16:44:43 CET] <DHE> avoid zerolatency mode [16:44:52 CET] <furq> you can use zerolatency if you want but it'll murder the quality for no good reason [16:45:03 CET] <furq> lookahead should give you like 90% of the gains [16:45:21 CET] <DHE> zerolatency is good for webcam chats... and that's about it [16:45:46 CET] <furq> yeah it's totally useless outside of webrtc [17:01:02 CET] <bencoh> I beg to differ, but ... the usecase I know of would require a crazy-high bitrate :) [17:04:27 CET] <furq> does it also require turning off cabac [00:00:00 CET] --- Fri Feb 7 2020

1 0

ffmpeg-devel.log.20200205
by burek 06 Feb '20

06 Feb '20

[00:19:12 CET] <cone-605> ffmpeg 03Michael Kuron 07master:bf070a9171d9: lavc/dvdsubdec: Move palette parsing to new function [00:19:12 CET] <cone-605> ffmpeg 03Michael Kuron 07master:d4440c7e91b0: lavc/dvdsubenc: accept palette from options [00:19:12 CET] <cone-605> ffmpeg 03Zane van Iperen 07master:d84a30e1238b: fate/adpcm: add adpcm_argo tests [00:33:28 CET] <cone-605> ffmpeg 03Philip Langdale 07master:d7210ce7f541: lavu/hwcontext: Add support for HW -> HW transfers [00:33:29 CET] <cone-605> ffmpeg 03Lynne 07master:a88449ffb2f2: lavu: add Vulkan hwcontext code [00:33:30 CET] <cone-605> ffmpeg 03Philip Langdale 07master:88d2ccbe9384: lavfi/vf_hwupload: Add support for HW -> HW transfers [00:33:31 CET] <cone-605> ffmpeg 03Lynne 07master:6fca61bbc917: lavfi: add Vulkan filtering framework [00:33:32 CET] <cone-605> ffmpeg 03Lynne 07master:d95c509cc643: lavfi: add an scale_vulkan filter [00:33:33 CET] <cone-605> ffmpeg 03Lynne 07master:7bb443137c65: lavfi: add an overlay_vulkan filter [00:33:34 CET] <cone-605> ffmpeg 03Lynne 07master:a2db7343e02f: lavfi: add an avgblur_vulkan filter [00:33:35 CET] <cone-605> ffmpeg 03Lynne 07master:907ae87d6eb7: lavfi: add an chromaber_vulkan filter [00:33:36 CET] <cone-605> ffmpeg 03Philip Langdale 07master:7f149b04520c: lavu/hwcontext_cuda: refactor context initialisation [00:34:06 CET] <Lynne> that was the longest time I've seen a git push command take [00:34:46 CET] <Lynne> and now I can delete 5 directories all of which carried a different revision of the patch [00:47:43 CET] <jamrial> Lynne: you did not bump lavu version, but added an apichanges entry [00:50:56 CET] <jamrial> or lavfi for all the new filters [00:53:21 CET] <Lynne> and now I can delete 5 directories all of which carried a different revision of the patch [00:53:37 CET] <Lynne> s/*// [00:58:26 CET] <cone-605> ffmpeg 03Lynne 07master:73a8c8e6e470: lavu: bump minor version for the Vulkan patchset [00:58:27 CET] <cone-605> ffmpeg 03Lynne 07master:ee81713fe395: doc/APIchanges: update with Vulkan commit info [00:58:28 CET] <cone-605> ffmpeg 03Lynne 07master:a71a5d9214eb: lavfi: bump minor version for the Vulkan filters [00:58:45 CET] <Lynne> fixed [01:00:38 CET] <jamrial> thanks [01:33:04 CET] <J_Darnley> That is a strangely polite email on the user list. [01:33:13 CET] <J_Darnley> "Please be informed" [02:02:29 CET] <cone-605> ffmpeg 03James Almer 07master:d1f9abca0953: configure: don't enable $ARCH_external if $ARCH is disabled [03:14:21 CET] <philipl> Lynne: w00t [03:21:40 CET] <Illya> Lynne: nice [04:04:10 CET] <cone-605> ffmpeg 03James Almer 07master:e6891d1b7ccd: avcodec/Makefile: combine dvdsub dependencies into one entry per module [10:33:15 CET] <durandal_1707> Lynne: i can not build mpv with libavfilter+vulkan [10:40:27 CET] <Lynne> durandal_1707: is it complaining about header location? [10:40:41 CET] <Lynne> check ffbuild [10:40:49 CET] <durandal_1707> no, missing symbols [10:41:00 CET] <durandal_1707> you do wrong order when linking [10:43:39 CET] <Lynne> durandal_1707: pkg-config glslang SPIRV-Tools SPIRV-Tools-shared --libs [10:43:52 CET] <Lynne> does this print the same flags as used in ./configure [10:45:08 CET] <Lynne> should be pkg-config glslang SPIRV-Tools SPIRV-Tools-shared spirv --libs [10:46:27 CET] <durandal_1707> i do not have glslang and spirv pc files [10:46:35 CET] <durandal_1707> i combiled master glslang [10:46:39 CET] <durandal_1707> *compiled [10:47:58 CET] <durandal_1707> libavfilter reports missing sprivtools symbols with ldd -r [10:49:21 CET] <Lynne> maybe I have the order wrong in configure then, my compiler didn't care [10:49:28 CET] <durandal_1707> undefined symbol: _ZN8spvtools5utils5Timer5StartEv (/usr/local/lib/libavfilter.so) [10:49:37 CET] <durandal_1707> i use clang9 [10:52:08 CET] <durandal_1707> perhaps because i compile mpv with gcc and ffmpeg with clang? [10:54:42 CET] <durandal_1707> /usr/local/lib/libavfilter.so: undefined reference to `vtable for spvtools::utils::Timer' [10:58:20 CET] <kurosu> durandal_1707: don't know how the C++ name mangling works, so the _ZN8 part may be an indication about the function (parameters, ordinal, whatever) or the C++ ABI ? relating to your clang9 vs gcc discussion [10:59:09 CET] <Lynne> lol, /usr/bin/ld: cannot find -lstdc++ [10:59:48 CET] <durandal_1707> fixed it [10:59:50 CET] <Lynne> will check out what clang means by that later [11:00:24 CET] <durandal_1707> did rm libavfilter/*.o [11:02:59 CET] <Lynne> cool [11:05:10 CET] <nevcairiel> kurosu: C++ mangling is pretty easy once you understand the scheme, everything starts with _Z, the N means that it has nested namespaces, and the numbers define the length of the immediately following name segment, the E at the end means parameters start here, and v is of course void [11:06:03 CET] <kurosu> nevcairiel: yeah, I know it is interpretable, just that I never actually need to know it [11:06:03 CET] <nevcairiel> (parameters are the only part that can get complex after that :D) [11:06:14 CET] <kurosu> so yeah, nothing about the C++ ABI in there [13:53:42 CET] <Lynne> 7.1. AVIF Image Item Media Type Registration: [13:53:53 CET] <Lynne> File extension(s): avif, heif or hif [13:54:16 CET] <Lynne> nice [14:27:59 CET] <kierank> Lynne: lol [15:05:52 CET] <Lynne> durandal_1707: so, think you can write docs for the vulkan filters and the new hwupload feature? [15:23:44 CET] <durandal_1707> durandal_1707: if nobody goanna do it... [15:23:51 CET] <durandal_1707> Lynne: ^ [15:51:02 CET] <cone-174> ffmpeg 03Martin Storsjö 07master:0815a22dccbb: vf_ssim: Fix loading doubles to float registers on i386 [15:54:17 CET] <cone-174> ffmpeg 03James Almer 07master:ca9bbfb8e5d0: avcodec/av1_parse: don't look for trailing bits in Tile List OBUs [16:48:56 CET] <Lynne> I'm tempted to write a vulkan vc2 encoder because its just so easy [16:51:36 CET] <gnafu> Lynne: Ooh, I like the sound of that. [16:52:24 CET] <gnafu> Would you say it's easy to make a rudimentary encoder, or easy to make a good one? [16:52:32 CET] <gnafu> (I'll let you define what "good" would mean.) [16:52:41 CET] <Lynne> yeah, its perfect for a low overhead screen codec, and it supports rgb [16:53:05 CET] <gnafu> Oh, now I like the sound of it even more. [16:56:37 CET] <cone-174> ffmpeg 03Paul B Mahol 07master:10f4441acb14: avfilter/vf_xfade: add vertopen/close transition [16:56:38 CET] <cone-174> ffmpeg 03Paul B Mahol 07master:2d58fa6d9e2d: avfilter/vf_xfade: add horzopen/close transition [18:27:05 CET] <Lynne> no, will be replaced by dav2d and dav3d sometime in the future [18:27:20 CET] <Lynne> thankfully, because dav1d is a really really lame project name [18:28:42 CET] <durandal_1707> i disagree, it cool name [18:30:17 CET] <durandal_1707> 2020 is year of AV1 :? [18:33:16 CET] <cone-174> ffmpeg 03Ting Fu 07master:e934194b6a41: libswscale/x86/yuv2rgb: Change inline assembly into nasm code [18:33:17 CET] <cone-174> ffmpeg 03Andreas Rheinhardt 07master:b4f300f8ea20: avformat/matroskaenc: Check functions that can fail [18:36:30 CET] <kierank> durandal_1707: av1 is the biggest thing ever to happen to OSS multimedia [18:36:36 CET] <kierank> So yes it's important [18:38:30 CET] <kurosu> wat, dav3d - is AoM buying into the point cloud/360°/plenoptic hype ? [18:38:49 CET] <durandal_1707> kierank: you troll again [18:38:51 CET] <kurosu> Lynne: vulkan and vc2? bitstream generation would still happen on the CPU or ? [18:39:12 CET] <kierank> durandal_1707: ??? [18:39:19 CET] <kurosu> Lynne: no rdo to do so there's that [18:52:19 CET] <Lynne> kurosu: on the GPU, all slices are aligned to a huge multiple of bytes [18:53:22 CET] <kurosu> Lynne: hum, I don't follow, my problem is with a serial process writing variable length stuff - but then I know nothing about Vulkan or modern GPUs [18:54:12 CET] <Lynne> its simple, first do a mock encode at your target quantizer, counting the number of bits each slice would require [18:54:37 CET] <Lynne> then get the max sized slice, align all sizes to it, then run a second pass [18:55:17 CET] <Lynne> in the second pass each workgroup would have an assigned slice and a buffer location where to dump the bitstream [18:56:30 CET] <Lynne> glsl supports almost-pointers so I don't think it would be hard to write a bitstream writer [21:36:20 CET] <cone-639> ffmpeg 03Marton Balint 07master:a8a05340de72: avformat/hlsenc: allow a custom SDT and PAT period [00:00:00 CET] --- Thu Feb 6 2020

1 0

ffmpeg.log.20200205
by burek 06 Feb '20

06 Feb '20

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

1 0

ffmpeg-devel.log.20200204
by burek 05 Feb '20

05 Feb '20

[03:58:37 CET] <inventednight> hi all! [10:31:55 CET] <durandal_1707> thilo: how long takes spi to send money? [11:09:41 CET] <darkapex> durandal_1707: thx for the patch ill check with valgrind tonight. if you have any samples on which you know its failing to encode, share em pls! [11:13:25 CET] <thilo> durandal_1707: I heard during the weekend you're still waiting for GSoC money like others. Usually it does not take this long, I'll check [11:15:34 CET] <durandal_1707> darkapex: it fails with any sample with not 0000 number of samples at end, it works with lynne sample because it is cut [11:16:07 CET] <darkapex> ah i see [11:18:03 CET] <cone-036> ffmpeg 03Paul B Mahol 07master:efee86fafa9c: avfilter/vf_xfade: add circleopen & circleclose transition [11:21:50 CET] <durandal_1707> darkapex: what case your first mlpenc patch fixes? [11:22:08 CET] <durandal_1707> commit log seems illogical for me [11:25:32 CET] <darkapex> yeah with the previous change number_sbits(-1) returned 1 [11:25:57 CET] <darkapex> which caused lossless failures for some files iirc [11:26:36 CET] <darkapex> after this commit it returns 2. that is the only case for which output of number_sbits is changed [11:27:22 CET] <darkapex> i will try to find the sample for which it was causing lossless errors on `number < 0` but not on `number < -1` [11:30:47 CET] <durandal_1707> darkapex: not needed, i see now [11:31:04 CET] <darkapex> cool! [11:31:22 CET] <darkapex> https://samples.ffmpeg.org/flac/When%20I%20Grow%20Up.flac this was the sample in any case [11:32:12 CET] <darkapex> i think it had blocks with only 0s and -1s lol [11:32:39 CET] <durandal_1707> :) [11:37:44 CET] <cone-036> ffmpeg 03Jai Luthra 07master:c1c3916cec9c: mlpenc: fix lossless check error in number_sbits [11:37:45 CET] <cone-036> ffmpeg 03Jai Luthra 07master:990990ed5d72: mlpenc: fix huff offset calculation [11:37:46 CET] <cone-036> ffmpeg 03Jai Luthra 07master:ddeb58d58c77: mlpenc: prevent negative lsb_bits lshift [11:37:47 CET] <cone-036> ffmpeg 03Jai Luthra 07master:bc0ed176024b: mlpenc: improve lpc filtering [11:37:48 CET] <cone-036> ffmpeg 03Jai Luthra 07master:ad2638473486: mlpenc: clean up [11:37:49 CET] <cone-036> ffmpeg 03Jai Luthra 07master:d6cef144e217: mlpenc: fix some -fsanitize=integer errors [11:37:50 CET] <cone-036> ffmpeg 03Jai Luthra 07master:49cfbedb9d5a: mlp: check huff_lsbs only when codebook is used [11:37:51 CET] <cone-036> ffmpeg 03Paul B Mahol 07master:c35382aaf471: avcodec/mlpenc: fix small memory leak [11:44:44 CET] <darkapex> thanks durandal_1707 ! [18:31:04 CET] <cone-669> ffmpeg 03Paul B Mahol 07master:fcc0424c9337: avfilter/vf_ssim: improve precision [18:32:55 CET] <durandal_1707> both fate and fatebeta are dead [18:33:25 CET] <durandal_1707> bad infrastructure is killing this project [19:29:03 CET] <durandal_1707> heh, nobody gives a shit, lets work on something else [20:04:09 CET] <durandal_1707> michaelni: is fate gonna be fixed soon? [20:05:33 CET] <michaelni> durandal_1707, fatebeta fixed [20:06:21 CET] <durandal_1707> if this is similar hw issue like described in blog post? [20:08:24 CET] <durandal_1707> BtbN: you uploaded testsrc or testsrc2 video? [20:08:33 CET] <michaelni> i hope the server doesnt have such issues ;) [20:09:21 CET] <BtbN> durandal_1707, testsrc [20:11:30 CET] <durandal_1707> BtbN: who was listed as copyright owner? [20:12:26 CET] <BtbN> durandal_1707, https://i.imgur.com/tMCoOaJ.png [20:18:09 CET] <Polochon_street> Hi! I remember writing this https://github.com/Polochon-street/bliss/blob/master/src/decode.c#L226-L335 some time ago, which basically takes an audio input, converts it to s16le if it's not already the case, and then puts it into an uint8_t array [20:18:26 CET] <Polochon_street> I'm wondering, how difficult would that be to make that thread multi-threaded, these days? [20:18:52 CET] <Polochon_street> just asking for some pointers/links, because I have no clue where to start with, maybe my code is completely outdated and there are simpler way to do this? [20:30:28 CET] <taliho> durandal_1707: fate seems to get stuck on some of the tags [20:30:51 CET] <taliho> i.e... <tr class="slotfail" id="armv7l-panda-gcc4_6-armv4"> [20:31:55 CET] <taliho> maybe those results are being fetched from somewhere with a slow response? [20:32:23 CET] <durandal_1707> i have no powers around fate in any way [20:40:49 CET] <cone-669> ffmpeg 03Paul B Mahol 07master:a15618d2c3a2: avformat/sccdec: use av_sscanf() instead [20:46:42 CET] <durandal_1707> taliho: arent those michael hw slots? [20:48:35 CET] <taliho> i've got no idea [22:50:04 CET] <Polochon_street> hm, the ability to use more threads for decoding/encoding in ffmpeg is dependent on the codec, right? [22:52:27 CET] <BBB> yes [22:52:39 CET] <BBB> most intra codecs support it generically (frame threading) [22:52:56 CET] <BBB> and some inter codecs support it customly (vp8, vp9, h264, hevc, a couple of others) [22:53:27 CET] <BBB> and then some codecs support slice (or tile) threading also, e.g. mpeg, h264, vp8/9? (iirc) and agin a couple of others [22:53:31 CET] <Polochon_street> alright, because directly setting codec_context->thread_count to something higher than one works for, f.ex., flac, but not for mp3 [22:54:10 CET] <BBB> ah, audio is different [22:54:15 CET] <Polochon_street> but I'm getting super confused at all these terms, came accross https://github.com/FFmpeg/FFmpeg/blob/master/doc/multithreading.txt [22:54:30 CET] <BBB> or video, check AV_CODEC_CAP_FRAME_THREADS and AV_CODEC_CAP_SLICE_THREADS in AVCodec.capabilities [22:54:37 CET] <Polochon_street> I'm only doing audio [22:54:40 CET] <BBB> ../libavcodec/flacdec.c: .capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS, [22:55:10 CET] <Polochon_street> but this is inherent to the decoding process itself, right? If I'm processing stuff frame by frame, it should be transparent to me? [22:55:24 CET] <BBB> yes [22:55:37 CET] <BBB> api usage is no different [22:55:50 CET] <Polochon_street> thanks a lot, that makes everything much simpler :D [22:56:05 CET] <BBB> the likely explanation for audio is that overlapping stuff makes it hard to do frame-mt for compressed audio codecs [22:56:41 CET] <BBB> I think Lynne knows more about that than me [22:57:19 CET] <Polochon_street> BBB: that's what occured to me as well, it doesn't seem to work for ogg as well [22:57:34 CET] <BBB> I'd expect it to only work for lossless audio codecs TBH, yes [22:57:45 CET] <Polochon_street> that's still a huge improvement for me :D [22:58:20 CET] <Polochon_street> (is there some helpers to get the current number of the computer's thread on ffmpeg, or should directly use pthread for that?) [22:58:53 CET] <BBB> if you set thread_count to 0 or -1, and thread_type to frame, it should set it automatically [22:59:23 CET] <BBB> -threads auto [22:59:24 CET] <Lynne> Polochon_street: yes, for decoding the lapping makes it difficult to do threading, though in theory you could just wait until you have the previous frame and in the meantime decode whatever you can [23:00:04 CET] <Lynne> won't work well with opus though, since opus has intra/inter frames where seeking is kinda pushing what desync is tolerable [23:00:15 CET] <Polochon_street> okay [23:00:20 CET] <Polochon_street> thanks for the detailed explanation [23:00:34 CET] <Lynne> for encoding you can thread as much as you want though, in fact I did a quick opus encoder hack to do that [23:01:16 CET] <Lynne> really no one has tried threading lossy audio decoders since they're not very slow, like both mp3 and opus are 500x realtime on a modern machine [23:01:30 CET] <Polochon_street> oh, that's why as well [23:01:48 CET] <Lynne> ac3 is I think even faster, 700x realtime [23:02:17 CET] <Polochon_street> I always thought ac3 was crappy ^^' [23:03:02 CET] <Lynne> its okay, the native encoder is good, but you still need at least 160kbps for stereo to sound acceptable [23:03:34 CET] <Polochon_street> do you consider 128kbps for mp3 acceptable? [23:07:07 CET] <Lynne> depends on the lame settings and content, its anywhere from okay (for simple things like piano) to not great (wall of sound) [23:09:03 CET] <Polochon_street> oops(), setting `codec_context->thread_count = 0;` and `codec_context->thread_type = FF_THREAD_FRAME;` changes the number of samples [23:10:15 CET] <Lynne> if its a lossless codec you'll definitely need to flush the decoder [23:10:27 CET] <Polochon_street> it's flac, yep [23:12:30 CET] <Polochon_street> is it something I should do at the end of the iteration, or regularly? [23:13:18 CET] <nevcairiel> At the end of the file [23:14:15 CET] <Lynne> it kind of happens naturally if you always expect a single packet to produce multiple frames [23:14:26 CET] <Polochon_street> https://github.com/Polochon-street/bliss/blob/466f8571f8ec1ef815fe8241942bf… isn't what I'm doing here? [23:15:15 CET] <Lynne> no, you need to give the decoder a NULL packet and read out all the frames [23:15:45 CET] <Lynne> in a loop, since with threading there won't be just 1 packet left but N, one for each thread usually [23:16:06 CET] <Polochon_street> oh, so almost the same thing, except with a NULL packet? [23:18:43 CET] <Lynne> well no, completely different since you need to call avcodec_receive_frame multiple times after you give a null packet [23:19:23 CET] <Polochon_street> ah, so I send a NULL packet once, and then avcoded_receive_frame as long as it outputs something [23:19:36 CET] <Polochon_street> sorry, I'm a bit slow but just restarted working on that :D [00:00:00 CET] --- Wed Feb 5 2020

1 0

ffmpeg.log.20200204
by burek 05 Feb '20

05 Feb '20

[00:35:26 CET] <arhat> cehoyos: Sorry, had to leave for a bit. Thanks! Actually, it's a DCP (.mxf) file that i believe is made up for JPEG 2000's (not sure what the technical way to describe that is?). By compare, do you mean just check visually, or is there some more robust method that doesn't depend on my eyes :P? [00:40:58 CET] <arhat> made up of* [01:59:42 CET] <cehoyos> If the input is lossless j2k (I don't know since you didn't show us command line including console output), you can export the single j2k frames with jpeg, decode them with another software and compare the results (not visually) with FFmpeg's output. This is only to check if there is something wrong [02:28:53 CET] <nickname123> hi [09:26:15 CET] <gusandrianos> Hello! [09:26:30 CET] <gusandrianos> I have set up an rtsp server to stream something and I am using ffmpeg to open the stream to the server. I am streaming h.263 with a low resolution for a specific use case but the stream plays in a very poor way and drops many frames [09:26:57 CET] <gusandrianos> I get this [09:26:59 CET] <repo> hi again. i'm still trying to debug my issue with concatenating two videos in sequences [09:27:02 CET] <gusandrianos> [h263 @ 0x55fe20d5f5a0] warning, clipping 1 dct coefficients to -127..12743 drop=0 speed= 191x Last message repeated 979 times [09:27:15 CET] <repo> here's my log output: [09:27:32 CET] <repo> it's 3 lines, is it ok if i paste them directly? [09:28:12 CET] <repo> i take that as a yes! :) [09:28:14 CET] <repo> eb 04 09:24:14 Stitching video for uuid jokke... Running ffmpeg with params: ["-y", "-loglevel", "error", "-f", "v4l2", "-framerate", "30", "-video_size", "1920x1080", "-t", "10", "-i", "/dev/video0", "-f", "alsa", "-t", "10", "-i", "hw:2", "-map", "0:v", "-map", "1:a", "-codec:v", "h264", "-codec:a", "aac", "/tmp/jokke.mp4"] [09:28:16 CET] <repo> Feb 04 09:24:25 Running ffmpeg with params: ["-y", "-loglevel", "error", "-filter_complex", "[0:v:0][1:v:0][2:v:0]concat=n=3:v=1[outv]", "-map", "[outv]", "-map", "0:a", "-codec:v", "h264", "-codec:a", "aac", "-r", "30", "-max_muxing_queue_size", "8192", "/data/jokke.mp4"] [09:28:18 CET] <repo> Feb 04 09:25:14 Too many packets buffered for output stream 0:0. [09:29:22 CET] <repo> so the second command fails with the error in the last line [09:29:52 CET] <repo> the weird thing is, that most of the time this works. [09:31:02 CET] <repo> the command is exactly the same [09:31:23 CET] <repo> the only variance being the captured video [09:46:39 CET] <repo> hm ok i took a closer look at the captured video files when it works and when it doesn't. https://p.jokke.space/m-maS/ [09:48:40 CET] <repo> the one that is broken shows a duration of 10s but when played, the player shows weird time codes (it starts playing at 0:29:00 and stops at 0:29:03) [09:48:59 CET] <repo> also the broken one is half the size of the working one [09:49:14 CET] <repo> any idea what might be going on? [17:22:03 CET] <kikuchi> Hello, I have a .png image folder [17:22:03 CET] <kikuchi> I'm trying to convert png to gif with Ffmpeg -i D:\adiirc\buffer\mario%d.png D:\Adiirc\buffer\test.gif [17:22:07 CET] <kikuchi> But I still have this error [png @ 000001e5cfe7dac0] Invalid PNG signature 0xFFD8FFE000104A46. [17:22:08 CET] <kikuchi> How I can override and create my gif please ? [17:29:58 CET] <BtbN> looks like your png is either not a png, or broken. As ffmpeg does not overly care about the file extension, I'd guess the later [17:31:43 CET] <furq> those are jpeg magic bytes [17:32:16 CET] <kikuchi> But i can view my png [17:32:39 CET] <furq> i would expect that your image viewer can view jpegs, yes [17:32:57 CET] <furq> but presumably image2 expects every image to be the same format [17:34:31 CET] <kikuchi> Actually it works if i change to jpg [17:34:36 CET] <kikuchi> Thx ! [20:37:47 CET] <ralphcor> I will be obtaining a hardware MJPEG encoder that does differential MJPEG. Before then, I'd like to get some idea of the size of video that results so my first thought was to use ffmpeg. It has a encoder mjpeg, but ffmpeg-all(1) doesn't suggest it does differential, i.e. key frame and updates. Am I correct? Does anyone here know a Linux encoder that does? [20:39:46 CET] <slimschwifty> Hey all, I'm planning to add a Radeon RX580 to my headless server to use to encode my DVR captures. Will I need to install X or Wayland to utilize VAAPI? If so, is there a bare minimum consider it wouldn't be used for anything else? [20:40:45 CET] <slimschwifty> considering* [20:56:32 CET] <BtbN> differential mjpeg sounds like h264 but bad [20:57:16 CET] <ralphcor> BtbN: Yes, I accept that, but it's a tiny embedded device, low power, 640x480, and hardware differential MJPEG is what I have. :) [20:57:37 CET] <BtbN> I never before heard of that term, are you sure it isnt something that device made up? [20:59:30 CET] <ralphcor> BtbN: I find Google hits, e.g. https://www.researchgate.net/publication/4128956_Low-bit_rate_motion_JPEG_u… [21:02:11 CET] <ralphcor> Conexant CX93510 is one example hardware device. [21:04:48 CET] <furq> i've never seen mjpeg-dpcm mentioned outside of academic papers [21:08:27 CET] <ralphcor> Well, the CX93510 datasheet says JPEG & MJPEG-DPCM Image Compression (ISO/IEC 10918-1/2). Those two ISO references are just JPEG though IIRC. [21:14:19 CET] <BtbN> sounds like they cooked something together themselves [21:14:52 CET] <furq> well it's described by/referenced in a bunch of papers as far back as 2004 [21:14:55 CET] <furq> so it's "a thing" [21:15:03 CET] <furq> but i don't think it's a thing that caught on [21:15:09 CET] <BtbN> yes, but papers aren't a standard to implement a decoder/encoder by [21:15:10 CET] <furq> idk if ffmpeg would even decode it [21:15:25 CET] <furq> or anything that would [21:17:22 CET] <ralphcor> Then this will be fun. :) [22:09:41 CET] <kingsley> Can any royalty-free encoders render faster with ffmpeg's "-threads <n>' option, besdies libxpx? If so, which one(s)? [22:10:59 CET] <BtbN> av1 probably [22:12:04 CET] <furq> kingsley: https://clbin.com/tKE15 [22:12:12 CET] <furq> not a complete list since it's missing anything with threading: auto [22:13:43 CET] <kepstin> slimschwifty: don't need X, it should work fine in a headless config as long as the user can access the appropriate /dev/dri/render* device [22:15:12 CET] <kepstin> slimschwifty: that said, the hardware encoder on polaris is kinda 'meh', and you could certainly get equivalent results with a lower-power card. [22:16:27 CET] <kingsley> furq: That's a nice list of encoders. May I please have the benefit of your thoughts on 3 questions? Question #1.) Why don't I see libvpx in it? Question #2.) How do you know they support ffmpeg's "-threads <n>" option? Question #3.) Asking if I could ask! ;-) [22:17:16 CET] <BtbN> The only actually useful encoder is libx264 and libvpx anyway [22:17:23 CET] <BtbN> and libx265 in some limited cases [22:17:56 CET] <BtbN> The other ones are mostly for special case uses [22:25:40 CET] <furq> kingsley: afaik external libs that support threading are all listed as "auto" which doesn't get reported in the -encoders output [22:25:52 CET] <furq> auto meaning just pass a threads param to the encoder and let it deal with it [22:26:41 CET] <furq> and everything listed there supports -threads [22:26:52 CET] <furq> to some varying degree [22:31:31 CET] <furq> https://clbin.com/nvJXR [22:32:17 CET] <furq> no big surprises there really [22:34:01 CET] <kingsley> furq: I said it before. I'll say it again. Thanks! [22:34:40 CET] <furq> you should probably run that locally if you're on *nix since it's dependent on what libs your ffmpeg links to [22:34:41 CET] <kingsley> BtbN: Do you happen to know if libx265 is royalty-free? [22:34:56 CET] <furq> x265 is the least royalty-free codec [22:36:07 CET] <BtbN> No codec is truly royalty free. Even VPx has patents behind it. [22:36:08 CET] <furq> it's got more royalty than the battle of hastings [22:36:09 CET] <slimschwifty> kepstin: I just happen to have a spare RX580, I have a GTX 260 as well but I figured I'd get more out of the AMD [22:36:22 CET] <BtbN> gtx260 doesn't have an encoder. [22:38:00 CET] <furq> also yeah vpx is most likely safe but the license doesn't grant proper patent indemnification [22:39:01 CET] <slimschwifty> BtbN: good to know, I wasn't even considering it since it's so old anyway [22:39:27 CET] <BtbN> Kinda sad that VPx is such a mess [22:39:31 CET] <BtbN> libvpx in particular [22:39:49 CET] <furq> i know at least nokia claim that they hold vpx patents that aren't part of the mpeg-la/google agreement [22:40:03 CET] <furq> and i'm sure others will crawl out of the woodwork if they sniff a dollar or two [22:40:14 CET] <furq> but really that's true of all codecs [22:59:27 CET] <kingsley> Is my understanding correct that encoders can be ranked by how encumbered they are by royalties as: libvpx (least), libx264 and libx265 (most)? [23:00:07 CET] <BtbN> hardly [23:00:15 CET] <BtbN> Cause for private use, it's a non-issue [23:01:02 CET] <pink_mist> wait, libx264 is encumbered by royalties? 0_o [23:01:10 CET] <furq> h264 is [23:01:30 CET] <furq> kingsley: libvpx is royalty free, that just doesn't imply patent indemnity [23:01:42 CET] <furq> you don't have to pay any royalties but you may still be sued [23:02:03 CET] <furq> av1 is in the same boat which is a bit of a shame [23:02:13 CET] <furq> you'd think aom would have enough cash between them to cover that [23:02:25 CET] <BtbN> it's just impossible to make a decent video encoder without hitting any patents... [23:02:50 CET] <furq> sure but the richest companies in the world ought to be able to stump up for a patent indemnity clause [23:03:40 CET] <furq> anyway x265 is definitely worse than x264 in this regard [23:03:54 CET] <BtbN> it has not one, but TWO independend patent pools asking for money [23:03:58 CET] <furq> four [23:04:04 CET] <BtbN> When did they multiplay? [23:04:24 CET] <furq> mpeg-la, hevc advance, technicolour and velos media iirc [23:04:38 CET] <furq> some of them might have merged or split since i last checked [23:07:04 CET] <furq> apparently technicolor rejoined hevc advance so i guess it's three now [23:16:41 CET] <kingsley> What do you think of libvpx-vp9? Is it also royalty free? Can it render as fast as libvpx -threads <n>? [23:20:06 CET] <Kaedenn> I have a video file that's like ~80MB. How much of it do I need to read to extract the first frame as an image? [23:31:27 CET] <Kaedenn> ...well, how about this. I want to extract 16 images from a video, equally spaced across the video's timeline. So if the video is 16 minutes long, then I'd extract an image every 60*fps seconds. [23:31:32 CET] <Kaedenn> s/seconds/frames/ [23:33:12 CET] <Mavrik> Kaedenn, you also need to tell which format you have [23:33:34 CET] <Kaedenn> It's almost always going to be h264 [23:33:55 CET] <Kaedenn> The following example command seems to be a good starting point, as it takes an image every 400 frames $ ffmpeg -ss 00:00:05 -i YosemiteHDII.webm -frames 1 -vf "select=not(mod(n\,400)),scale=160:120,tile=4x3" tile.png [23:33:58 CET] <Mavrik> in what conatiner? [23:34:02 CET] <Kaedenn> mp4 [23:34:04 CET] <Mavrik> *container [23:34:21 CET] <Mavrik> Well, for first frame you need the header + frame data [23:34:32 CET] <Mavrik> The header can be either at the start or at the end of the file. [23:34:44 CET] <Kaedenn> ...oh. [23:34:46 CET] <Mavrik> For extracting frames every N steps you probably need more or less the whole file. [23:35:28 CET] <Kaedenn> Would it be possible to "sniff" a frame of video based on byte patterns? [23:36:02 CET] <Kaedenn> In theory I'd have the resolution of the video. In practice I don't always do. [23:36:42 CET] <Kaedenn> (the extract-first-frame and make-a-collage questions are two separate projects) [23:37:20 CET] <Kaedenn> What's the variable for the length of the movie in -vf? [23:38:51 CET] <Mavrik> You need the header in any case to get SPS/PPS [23:39:00 CET] <Mavrik> And the header also has the index [23:39:14 CET] <Mavrik> So after that you can access keyframes without getting the whole file (assuming it's not segmented) [23:52:35 CET] <kingsley> Do you happen to know of nice, clean, reliable documentation for how to speed up a royalty free encoder, like libvpx, libvpx-vp9 or av1 across many cores, threads and or slices? [23:55:32 CET] <Mavrik> What's your goal? Meaning, what are you encoding? [23:56:01 CET] <kingsley> Mavrik: Thanks for asking. [23:56:36 CET] <kingsley> Short answer? testsrc2. [23:57:31 CET] <Mavrik> ?? [23:57:43 CET] <Mavrik> I mean, are you doing realtime transcode? [23:57:52 CET] <Mavrik> Archival? [23:58:05 CET] <Mavrik> What's your quality goal? [23:58:11 CET] <kingsley> Long answer? Bench mark how well render can be sped up by running it in parallel across multiple CPUs, cores and threads. [23:58:15 CET] <BtbN> libvpx is a pretty terrible encoder [23:58:23 CET] <Mavrik> All of these are :P [23:58:24 CET] <BtbN> it does not scale too great, and has horrible rate control [23:58:56 CET] <Mavrik> BtbN, then again, VP9 got better multithreading in 1.7 it seems [23:59:06 CET] <kingsley> Mavrik: I suppose the default quality would be a reasonable standard. [23:59:07 CET] <Mavrik> And it does have a realtime transcode mode used by Hangouts IIRC [23:59:30 CET] <BtbN> still has laughably bad rate control compared to x264 [23:59:51 CET] <Mavrik> BtbN, sure. [00:00:00 CET] --- Wed Feb 5 2020

1 0

ffmpeg-devel.log.20200203
by burek 04 Feb '20

04 Feb '20

[00:08:56 CET] <taliho> :jamrial do the docs need an update for the export_side_data flag? [00:10:56 CET] <jamrial> taliho: yeah [00:12:45 CET] <taliho> do you have any thoughts about the patch for exporting hevc motion vectors? [00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:be54da2117a6: avcodec/snappy: Sanity check bytestream2_get_levarint() [00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:985d3666f672: avcodec/pcm: Fix invalid shift in pcm_decode_frame for LXF [00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:6847e22c8c85: avcodec/wmavoice: sanity check block_align [00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:38d375844487: avcodec/wmavoice: Fix rounding and integer anomalies in calc_input_response() [00:13:02 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:94ac2c757663: avcodec/8svx: Use av_assert1(0) instead of error message in unreachable code [00:13:03 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:bfea054a75f1: avcodec/dca_lbr: Fix some error codes and error passing [00:13:03 CET] <cone-547> ffmpeg 03Michael Niedermayer 07master:fd313d8cf836: avcodec/ralf: Fix integer overflow in apply_lpc() [00:19:36 CET] <taliho> jamrial: do you think parts of hevc export motion vector patch belong in mpegutils.c? [00:22:33 CET] <jamrial> i can't say. i only replaced the flag, no idea if that's the correct place for the existing code [00:23:16 CET] <jamrial> but mpegutils doesn't sound like the place for hevc related code [00:26:28 CET] <taliho> ok, just feel sorry for the guy. he's pinged a few times [01:36:52 CET] <BBB> taliho: in all honesty, I think hevc suffers from an utter lack of interest ("nobody cares") [01:36:58 CET] <BBB> taliho: and this is a typical example of this [01:37:30 CET] <BBB> it's funny, because hevc is supposed to be all the hype, but hype does not grow in a vacuum. nobody cares about yet another lossless screen codec, and nobody cares about hevc [01:37:41 CET] <BBB> ¯\_(Ä)_/¯ [01:38:15 CET] <BBB> taliho: the best way for that patch to go in is for someone to take over long-term maintainership of hevc functionality in ffmpeg, and by that I really mean "work on it as a main project" [01:38:23 CET] <BBB> (and for the long term) [01:38:26 CET] <BBB> interested? :) [02:09:06 CET] <kierank> tragedy of the commons [08:22:52 CET] <cone-605> ffmpeg 03Tomas Härdin 07master:1c15111148b5: MAINTAINERS: Add myself as mxf* maintainer [09:43:51 CET] <cone-605> ffmpeg 03Paul B Mahol 07master:6d5e9ed67cf0: avfilter/vf_xfade: move passthrough code before eof check [09:43:52 CET] <cone-605> ffmpeg 03Paul B Mahol 07master:c4e29d0ba316: avfilter/vf_xfade_opencl: move passthrough code before eof check [09:54:26 CET] <durandal_1707> darkapex: not all integer overflows have been fixed by your patch [09:55:35 CET] <darkapex> durandal_1707: ok you can ignore that patch for now ill do more testing with undefined santize as well [09:55:56 CET] <darkapex> do rest of the changes look ok? [09:56:28 CET] <durandal_1707> darkapex: i'm talking only about integer one [09:56:49 CET] <darkapex> ok ill try to send an update tonight [10:02:48 CET] <durandal_1707> darkapex: ctx->dts = -avctx->frame_size; ----> why is that initialized this way? it seems pointless [10:06:26 CET] <darkapex> durandal_1707: i am unsure about most of the code tbh. i did not touch what seemed to work when i was merging ramiro's original code. i can take a look if you think this might be causing the issues with the last few blocks not getting encoded. [10:08:13 CET] <durandal_1707> darkapex: it have nothing to do with that [10:08:41 CET] <durandal_1707> darkapex: look at your old changes, perhas you introduced this invalid items at first time [10:09:27 CET] <darkapex> this was there in ramiro's original tree as well https://github.com/ramiropolla/mlpenc/blob/master/mlp/mlpenc.c#L570 [13:21:45 CET] <durandal_1707> Lynne: ok to push mlp stuff? its all experimental anyway, also apply mlp decoder patch? [13:38:38 CET] <durandal_1707> darkapex: what about 20/24 mode? [13:39:49 CET] <darkapex> durandal_1707: haven't tested that properly yet. i would guess it would still fail lossless checks as there is assumption in code at many places. [13:40:05 CET] <darkapex> lets keep it disabled for now i would say [13:41:31 CET] <darkapex> ill test it once i solve the unencoded last few samples issue [13:41:48 CET] <durandal_1707> ok [16:53:07 CET] <Lynne> durandal_1707: yeah, go ahead [16:53:31 CET] <Lynne> you know more about the encoder than I do now anyway [16:55:59 CET] <durandal_1707> i doubt that [18:05:17 CET] <darkapex> durandal_1707: you are correct the dts code is completely useless. ctx->timestamp already holds the correct timestamp [18:06:02 CET] <darkapex> ill check with the surcode decoder when i boot into windows, it should be able to play it though [18:08:09 CET] <durandal_1707> darkapex: i just tell about negative for unsigned value [18:08:33 CET] <darkapex> yeah i know but it is useless on top of that [18:10:44 CET] <Lynne> the whole thing is weird, it looks like its doing container-level work [18:11:07 CET] <Lynne> and it calls access units frames [18:11:31 CET] <Lynne> moreover, afq does all the work to set the pts/dts for you [18:16:13 CET] <darkapex> yeah if i get time i will look at other encoders like flacenc and try to use newer util functions in mlpenc as well [18:16:38 CET] <darkapex> the code is an absolute mess rn [18:22:22 CET] <darkapex> ok i see ctx->dts is stored in the access unit header which is decoding time stamp. and ctx->timestamp is stored in restart header which is presentation timestamp [18:22:30 CET] <darkapex> both are ignored by mlpdec.c [18:22:48 CET] <darkapex> now question is if some weird dvd-a player or surcode ignore it as well [18:23:17 CET] <durandal_1707> i'm just talking about invalid initialization [18:23:20 CET] <darkapex> anyway ill just change dts to int64_t and cast it wherever [18:23:22 CET] <darkapex> yeah [18:23:34 CET] <darkapex> will do that i dont want things to explode in future due to this [18:23:36 CET] <durandal_1707> look how dts looks from surcode encoder? [18:23:52 CET] <darkapex> ok yeah that is an excellent idea will try [18:24:02 CET] <durandal_1707> no point in casting, just initialize it to 0 [18:24:20 CET] <darkapex> then first access unit header will have wrong dts no? [18:24:35 CET] <durandal_1707> how so? [18:24:54 CET] <Lynne> darkapex: it rerolls back to 0 after 1<<16 frames, and the value in the bitstream is 16bit [18:24:55 CET] <darkapex> right now the first dts going in the bitstream is unsigned cast of the initial value of dts.. [18:26:25 CET] <darkapex> Lynne: yeah right. does that mean that it does not matter if we start from 0 or -frame_size and any decoder should be able to take the first dts from bitstream as starting point? [18:27:04 CET] <durandal_1707> look what surcode does [18:27:14 CET] <darkapex> alright time too boot into window$ [18:46:59 CET] <durandal_1707> darkapex: i have encoded file, just dunno how to modify mlpdec [18:48:03 CET] <darkapex> durandal_1707: i checked, surcode dts starts from 0 when logged in mlpdec and so does original mlpenc's. if i set dts = 0 it starts at 40 in the mlpdec logs which is weird [18:48:14 CET] <darkapex> wait ill share the logging patch for mlpdec [18:49:16 CET] <darkapex> https://pastebin.com/9xPpUfJJ [18:54:46 CET] <durandal_1707> darkapex: hmm, than current code is fine, just need cast [18:57:19 CET] <darkapex> durandal_1707: yeah i'll do that for now. [18:57:49 CET] <darkapex> also i think the last access unit is probably not written due to https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mlpenc.c#L2256 [18:58:10 CET] <darkapex> this might also solve the weird dts initialization as dts is written in access unit [18:58:54 CET] <darkapex> note how it skips writing access unit a few lines below if data is not found. i am suspecting this is causing the last block to not get written but ill need to check more [21:39:53 CET] <cone-711> ffmpeg 03Wonkap Jang 07master:b93098253ece: avcodec/libvpxenc: add VP9 temporal scalability encoding option [21:59:39 CET] <cone-711> ffmpeg 03Marton Balint 07master:3cdc71348e03: avformat/dashenc: use AV_OPT_TYPE_DICT for http_opts [22:04:32 CET] <durandal_1707> darkapex: https://0x0.st/izlr.patch [22:05:44 CET] <durandal_1707> it fails to encode end frames in some cases, there are out memory access [22:06:05 CET] <durandal_1707> use valgrind with -fsanitize=address [22:06:21 CET] <durandal_1707> i mean and/or [22:06:27 CET] <durandal_1707> not with [23:22:52 CET] <BtbN> I uploaded a video with the testsrc test pattern to YouTube. And it got immediately copyright flagged and blocked worldwide [23:22:54 CET] <BtbN> the hell [23:23:12 CET] <BtbN> nothing else in there. Just 10 minutes of testsrc, no audio. [23:23:25 CET] <cehoyos> michaelni: If you have time, please look at ticket 8508, a mov stsc regression [23:24:29 CET] <jdarnley> BtbN: youtube all over [23:24:58 CET] <BtbN> It doesn't even let me myself watch it... [23:25:08 CET] <jdarnley> someone fed test footage into the copyright bot to claim it from others [23:25:09 CET] <BtbN> and here I am wanting to test weird stutter issues [23:25:18 CET] <jdarnley> happens with static too IIRC [23:25:24 CET] <BtbN> Well, it's not even claimed. It's straight up shot down entirely. [23:25:52 CET] <cone-711> ffmpeg 03Michael Kuron 07master:beab188c615d: doc: Fix typo for dvdsubdec [23:59:50 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:eb64a5c6f949: avcodec/apedec: Fix integer overflows in predictor_decode_mono_3950() [23:59:51 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:861183f2e655: avcodec/pngdec: Check amount decoded [23:59:52 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:fb3855342b9e: avcodec/lagarith: Sanity check scale [00:00:00 CET] --- Tue Feb 4 2020

1 0