April 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190424
by burek 25 Apr '19

25 Apr '19

[00:01:20 CEST] <durandal_1707> cehoyos: why? [00:02:19 CEST] <cone-633> ffmpeg 03Takayuki 'January June' Suwa 07master:f9a061a31c3d: avdevice/alsa: fix indefinite stop on closing PCM capture [00:03:08 CEST] <cehoyos> Why I was asking for aac? Or why I closed the ticket where it is claimed that either Dolby or DTS are "not normal" (don't remember which)? [00:03:40 CEST] <cehoyos> There is already a ticket for the stupid resampling for dts -> ac3 [00:03:49 CEST] <cehoyos> (a "new team" regression) [00:03:57 CEST] <cehoyos> sorry, a paid new team regression [00:04:29 CEST] <durandal_1707> frei0r [00:04:34 CEST] <cehoyos> ;-) [00:04:48 CEST] <cehoyos> The patch that fixes the warning is wrong afaict, I sent a new patch. [00:05:04 CEST] <cehoyos> But I could not really test so maybe I miss a lot... [00:06:28 CEST] <cehoyos> Please review [00:06:47 CEST] <durandal_1707> fetch frei0r and test it? [00:08:13 CEST] <cehoyos> I did and I can reproduce the original issue (before the patch last year) and the warning but frei0r crashes here elsewhere, but since my patch should not change the actual argument to frei0r, I don't think that really matters. [00:08:30 CEST] <cehoyos> The warning fix was just wrong imo. [00:09:04 CEST] <durandal_1707> where it crashes? [00:10:04 CEST] <cehoyos> Sorry, I removed the binary: An assertion failure in frei0r [00:11:21 CEST] <cehoyos> Did you look at my patch? [00:12:22 CEST] <durandal_1707> no, its not in mail as txt but attached as binary [00:12:58 CEST] <durandal_1707> tomorrow,now sleep time [00:13:05 CEST] <cehoyos> Good night! [00:20:02 CEST] <durandal_1707> patch looks fine, will test tomorrow [00:22:58 CEST] <cehoyos> Please do, thank you [01:41:49 CEST] <cone-633> ffmpeg 03Cyber Sinh 07master:499b46fd0a89: compat/windows/makedef: Allow building shared libs with MSVC under WSL [01:43:37 CEST] <cone-633> ffmpeg 03Carl Eugen Hoyos 07master:d0ca749adbf2: tests/fate-run: New variable hostexecsuf for local fate tools. [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:caa9b4ff89c0: avcodec/agm: Check that there is available input in read_code() [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:fee666104519: avcodec/dsicinvideo: check the amount decoded by cin_decode_huffman() [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:9570322a2d8c: avcodec/dxtory: Check slice_size against minimum in dxtory_decode_v2() [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:ed188f6dcdf0: avformat/aadec: Check for scanf() failure [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:18a567c369d7: avformat/mov: Skip stsd adjustment without chunks [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:6f0e9a863466: avutil/avstring: Fix bug and undefined behavior in av_strncasecmp() [17:08:10 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:8b10f09fd537: avcodec/arbc: Skip unchanged frames [17:08:11 CEST] <cone-882> ffmpeg 03Michael Niedermayer 07master:7c2ee8d43d95: avcodec/arbc: Try to correct keyframe/frame type [17:10:45 CEST] <philipl> BtbN: so the nvenc thing? should we just make the change and document the assumption? [17:16:27 CEST] <jamrial> jkqxz: there's a bunch of cbs patches from andreas and some by me, if you can look whenever you have time [18:08:07 CEST] <BtbN> philipl, I looked into reverting the relevant patch, but it needs more indepth changes to do things properly. [18:08:30 CEST] <BtbN> And I haven't found time to do so yet. [18:10:33 CEST] <philipl> Bok [18:12:01 CEST] <BtbN> There are two patches which basically need reverted again, so there is only a global list of mappings, and not one per frame [18:14:55 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=bbe1b21022e4872bc64066… see commit message as to why it can't just be reverted. [18:18:03 CEST] <BtbN> ok, it's not as complicated. Unfortunately, I can't test if it works, cause I'm not seeing any performance regression at all. [18:21:58 CEST] <philipl> I assume these guys will let us know :-) [18:27:08 CEST] <BtbN> Did you see the patch about the nvidia h264 parser getting interlaced flags wrong? [18:49:26 CEST] <philipl> BtbN: I totally believe it. [18:49:52 CEST] <BtbN> It's easily reproducible (dude that sent the patch prepared half a dozen docker containers for some reason) [18:50:03 CEST] <BtbN> Run these in order to see! [18:50:17 CEST] <BtbN> And before that do these 12 commands to make using GPUs in Docker possible in the first place [18:50:27 CEST] <philipl> I did not think hard, but doesn't this mean that mixed interlacing streams will have problems because we are making a stream level decision? [18:50:55 CEST] <BtbN> I don't think so, cause the sequence callback will be re-called for those I believe. [18:51:50 CEST] <BtbN> Which is also why I moved the location where it's set from the original patch to the display callback [18:52:13 CEST] <BtbN> to make sure an intermediate re-call of the sequence callback does not make it use the new flag on old frames still in the queue [18:55:45 CEST] <BtbN> Where would you even document special behaviour of an encoder that only an API user would care about? [18:56:46 CEST] <BtbN> nvenc does not have an entry in encoders.texi. Maybe it should? [19:03:08 CEST] <JEEB> yea [19:03:30 CEST] <BtbN> philipl, I'm tempted to just #ifdef out the part that unregisters the frames. That way someone who really relies on the behavour can easily build a version that does so. [19:05:09 CEST] <BtbN> Could also turn it into a normal option, but it seems a bit arcane to expose that way. [19:05:24 CEST] <BtbN> Is there a way to make options hidden? [19:06:59 CEST] <BtbN> doesn't seem like it [19:07:47 CEST] <philipl> BtbN: we discussed making it an option when it first came up. I'd be ok with it. Others might not be. [19:08:19 CEST] <philipl> It's only relevant for a very customised application usage pattern. Documenting it as such seems to be fine. [19:20:43 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commit/5f77951908677d1f9a0f27bb19ebaa6cb5679… [19:22:11 CEST] <nevcairiel> why not have fully compatible method be default, and the performance edge-case require special compilation? [19:24:55 CEST] <nevcairiel> potential leaks are worse then slowdown in extreme special cases [19:32:02 CEST] <philipl> because there's no way to directly use ffmpeg that requires the compatible path [19:32:15 CEST] <philipl> You need a custom pool allocator [19:32:23 CEST] <nevcairiel> people use APIs as well you know [19:32:38 CEST] <nevcairiel> and such an option is pretty well hidden [19:32:55 CEST] <philipl> Of course, but the edge case, in practice, the non-performant one. [19:32:58 CEST] <philipl> that's what I mean. [19:33:59 CEST] <philipl> When I say directly use, I mean you must provide a custom allocator that doesn't re-use a fixed pool to need the aggressive unregistration. [19:34:07 CEST] <philipl> You can't combine off-the-shelf parts to create that situation. [19:35:12 CEST] <nevcairiel> you would be surprised how many people just grab zeranoe windows builds to use the .dlls because they cant build their own [19:35:28 CEST] <nevcairiel> and even if you do compile yourself, finding and knowing about that option is still quite a step [19:36:49 CEST] <philipl> Oh, I thought it was a runtime option. [19:36:57 CEST] <philipl> I'm seeing now it's not [19:37:58 CEST] <nevcairiel> it could be i suppose, but even then the option thats not error prone in some situations is usually favorable over performance optimizations [19:38:21 CEST] <nevcairiel> ideally you would be able to detect this from the pool or something [19:47:04 CEST] <BtbN> nevcairiel, it's not a leak though [19:47:15 CEST] <BtbN> The resources are eventually unregistered [19:47:31 CEST] <BtbN> Just not immediately, but at the end of the session, of if the buffer is full [19:48:05 CEST] <nevcairiel> so what actually happens if i use new buffers for every frame? [19:48:49 CEST] <BtbN> The undefined situation happens when you free the CUdevptr that nvenc still has registered [19:49:21 CEST] <BtbN> as long as you just keep feeding in an endless stream of new handles it will eventually run out of buffer space to store them, free one, and register there. [19:49:34 CEST] <nevcairiel> obviously i would relesae those frames [19:49:43 CEST] <BtbN> What happens then is up to the nvidia driver. [19:50:02 CEST] <BtbN> If it implicitly unregisters them, and doesn't complain when trying to do so again, all will be fine [19:51:10 CEST] <BtbN> But in what situation would you not keep re-using the same set of input surfaces over and over again? [19:52:10 CEST] <BtbN> Keep in mind that the behaviour I'm restoring right now was the default in nvenc for the longest time, and nobody ever had issues. [19:54:36 CEST] <BtbN> I'm just gonna try doing that, it's an easy test [19:59:37 CEST] <BtbN> nevcairiel, how do I free whatever d3d11va gives to nvenc in frame->data[0]? [19:59:42 CEST] <nevcairiel> this only affects cuda input, not software or d3d? [19:59:56 CEST] <BtbN> Software input does not care, d3d11va is equally affected [20:01:50 CEST] <nevcairiel> ID3D11Texture2D_Release(frame->data[0]) i think [20:02:06 CEST] <BtbN> yeah, looking at the hwcontext stuff for it, seems like that's it [20:02:45 CEST] <nevcairiel> not sure if it needs a cast [20:02:46 CEST] <nevcairiel> maybe [20:02:47 CEST] <BtbN> I have just thrown that in right after registering a frame, and then try to unregister it again right away [20:02:51 CEST] <BtbN> ID3D11Texture2D_Release((ID3D11Texture2D *)frame->data[0]); [20:03:14 CEST] <nevcairiel> the way d3d11 frames are allocated its even less l ikely to get that problem tho [20:03:52 CEST] <BtbN> If the unregister succeeds (or throws a well defined error like "not registered"), there is no need for the special flag in the first place [20:04:02 CEST] <BtbN> cause that can be handled and safely ignored [20:07:20 CEST] <nevcairiel> thinking about it, d3d11 is a bad test, since there is only one ref-counted texture object with X layers, so it'll never actually be free'ed [20:09:52 CEST] <BtbN> Yeah, d3d11 has those sub layers [20:27:31 CEST] <BtbN> it works just fine if I free the thing. Unregisters without errors [20:27:35 CEST] <BtbN> for d3d11 [20:27:38 CEST] <BtbN> testing CUDA now [20:28:42 CEST] <BtbN> Yeah, works just fine as well. [20:41:17 CEST] <philipl> BtbN: so you can unregister after free in practice? [20:41:36 CEST] <BtbN> it does not throw an error at least [20:41:50 CEST] <philipl> heh. Ship it. [20:47:11 CEST] <BtbN> I guess it would explode if you were to actually re-use it [20:58:06 CEST] <philipl> BtbN: I don't get the first_round thing [20:59:30 CEST] <BtbN> It avoid unregistering frames if there are still slots without a registered frame int hem [20:59:34 CEST] <BtbN> *in them [21:00:02 CEST] <BtbN> Cause right now, if it's looking for an unmapped spot, it'll just unregister whatever is in there [21:00:28 CEST] <BtbN> And not prefer fully empty ones [21:01:08 CEST] <philipl> ah, ok. [21:05:04 CEST] <BtbN> though in reality, it'll never reach that function again after a short while, because all input surfaces will be registeres already [21:10:54 CEST] <philipl> sure. [22:57:25 CEST] <cone-887> ffmpeg 03Paul B Mahol 07master:e1cfb01b054b: avfilter/af_surround: fix typo [22:57:25 CEST] <cone-887> ffmpeg 03Paul B Mahol 07master:e1e0f94dc956: avfilter/af_surround: add angle option [22:57:25 CEST] <cone-887> ffmpeg 03Paul B Mahol 07master:2d16b83824c1: avfilter/af_surround: check for invalid magnitude and phase difference [22:57:25 CEST] <cone-887> ffmpeg 03Paul B Mahol 07master:604421630bd5: avfilter/af_surround: improve rear channels separation [23:36:41 CEST] <cone-887> ffmpeg 03James Almer 07master:53cc3338f7b2: avcodec/h264_ps: fix storage size for offset_for_ref_frame [23:36:42 CEST] <cone-887> ffmpeg 03James Almer 07master:a42e761b9623: avcodec/h264_ps: use get_se_golomb_long() to parse some sps fields [00:00:00 CEST] --- Thu Apr 25 2019

1 0

ffmpeg.log.20190424
by burek 25 Apr '19

25 Apr '19

[00:01:29 CEST] <BtbN> mkv is just fine [00:08:36 CEST] <dablitz> can anyone continue to help me [00:08:50 CEST] <cehoyos> Yes [00:09:00 CEST] <dablitz> cehoyos: [00:09:18 CEST] <cehoyos> No, sorry, I don't know much about rtp (if that is the question) [00:09:29 CEST] <dablitz> yes that is the question [00:11:33 CEST] <Atlenohen> calamari: OBS broadcaster specifically uses MKV for failsafe when abrupt shutdown or crash, I was benchmarking, ran out of RAM, it crashed, the video was fine [00:11:47 CEST] <cehoyos> He has left [00:11:52 CEST] <Atlenohen> Oh [00:12:18 CEST] <cehoyos> But using broken mkv as "failsafe" is of course also not a useful answer;-) [00:12:29 CEST] <cehoyos> Do you still have your configure line? It looked a little broken to me... [00:12:36 CEST] <Atlenohen> Atleast in comparison to MP4 [00:13:22 CEST] <Atlenohen> You mean my ffmpeg compiling saga? [00:13:37 CEST] <cehoyos> Iirc, you used both --disable-all and --disable-everything [00:13:59 CEST] <cehoyos> everything is a debug options that you should not use and it is always a subset of all [00:14:13 CEST] <cehoyos> You should not use "--disable-everything"! [00:14:14 CEST] <cehoyos> You should not use "--disable-everything" [00:14:39 CEST] <Atlenohen> Oh I did sort it out tho fully, however, I'll check that right now [00:14:40 CEST] <cehoyos> Don't remember the other issues atm, saw them in the log [00:14:59 CEST] <cehoyos> But if you run "./ffmpeg", I can have another look [00:16:10 CEST] <cehoyos> I meant: If you post your configure line again, I can have a look [00:16:38 CEST] <Atlenohen> FFmpeg was building fine, the two other issues were that I had to modify x264.header for ffmpeg to know it's getting a static x264 lib instead of dynamic, the X264_API_IMPORTS stuff [00:17:06 CEST] <Atlenohen> and I had to simply include bcrypt.lib in the additional libraries of the project settings linker in VS2017, presto [00:17:09 CEST] <elmofan> can any deshaker for ffmpeg also correct rotational shake? or is it all translation? [00:17:34 CEST] <Atlenohen> Sure [00:17:58 CEST] <cehoyos> Of course, I believed we resolved bcrypt originally ("in a minute" iirc), you just added some additional options, some of them are wrong afair, one of them was "--disable-everyhing" [00:18:05 CEST] <Atlenohen> not sorry, to ceyehos: sure I can, moment, [00:18:34 CEST] <Atlenohen> I did fiddle in depth with the options too, but I don't remember [00:19:07 CEST] <Atlenohen> cehoyos: # ./configure.txt --toolchain=msvc --arch=x86_64 --target-os=win64 --extra-cflags=-I./dependency/x264/include --extra-cflags=-MT --extra-cflags=-GS- --extra-ldflags='-LIBPATH:./dependency/x264/lib' --prefix=./CAKE --disable-all --disable-everything --disable-network --disable-debug --enable-static --enable-avformat --enable-avcodec --enable-swscale --enable-swresample --enable-gpl --enable-protocol=file --enable-muxer='matros [00:19:07 CEST] <Atlenohen> ka,mpegts,mxf,webm,rawvideo,frame*' --enable-libx264 --enable-encoder='mpeg4,libx264*,bmp,ffv*,rawvideo' [00:19:25 CEST] <cehoyos> Are you using msys or wsl? [00:19:29 CEST] <Atlenohen> msys2 [00:20:04 CEST] <Atlenohen> it's more like msys2+mingw64, properly. [00:20:07 CEST] <cehoyos> Remove arch (it does not do what you think it does, if it had an effect, it would break compilation) and target [00:20:45 CEST] <cehoyos> Remove --disable-everything (it is a subset of all, and a subset that you are not interested in) [00:21:14 CEST] <cehoyos> Remove --disable-static (it has been the default since forever, much more than a decade) [00:21:21 CEST] <cehoyos> Remove --enable-static (it has been the default since forever, much more than a decade) [00:21:23 CEST] <cehoyos> (sorry) [00:21:41 CEST] <Atlenohen> You sure, I did went into the configure and hard edited some stuff that were annoying me, but it's working now, althought, who knows maybe theres some unforseen consequences when encoding [00:22:00 CEST] <cehoyos> Remove --disable-network as it is a subset of --disable-all [00:22:08 CEST] <Atlenohen> Ah if it's a subset then probably not necessary [00:22:16 CEST] <cehoyos> Yes, I am sure that --enable-static is the default since forever and that forever is >10 years [00:24:05 CEST] <Atlenohen> I see that there's multiple things leading to x86 like i[3-6]86*|i86pc|BePC|x86pc|x86_64|x86_32|amd64) [00:24:05 CEST] <Atlenohen> arch="x86" - so I left it be as it probably didn't break anything [00:24:32 CEST] <cehoyos> Again: arch breaks compilation [00:24:53 CEST] <cehoyos> target is useless because it is set by toolchain=msvc [00:25:16 CEST] <Atlenohen> how does it break it? [00:26:03 CEST] <cehoyos> If your compiler actually is configured for "x86_64", arch does nothing, if your compiler happens to be configured for another target, arch breaks (or maybe: can break) compilation [00:26:06 CEST] <cehoyos> Please remove it [00:26:11 CEST] <cehoyos> to be on the safe side. [00:28:27 CEST] <cehoyos> Did you benchmark "-GS-"? I ask because I believe we should make it the default (but only if it has an effect). [00:29:07 CEST] <Atlenohen> Not, I've not done that specifically, since I did more side stuff in the VS project [00:29:32 CEST] <Atlenohen> However MSVC has win32 not win64 as the target_os_default [00:29:56 CEST] <Atlenohen> and there is no arch [00:30:35 CEST] <cehoyos> There is no difference between "win32" and "win64" [00:30:49 CEST] <cehoyos> There is no arch because the option can break compilation, you should not use it [00:30:49 CEST] <Atlenohen> yeah it's one of those duds again [00:30:59 CEST] <cehoyos> (Unless you cross-compile which you are not) [00:31:32 CEST] <cehoyos> If you have not benchmarked it, why do you use it? [00:31:52 CEST] <Atlenohen> most of this stuff was in the original configure statement [00:32:16 CEST] <cehoyos> Do you know what -GS- does? [00:32:33 CEST] <Atlenohen> which is several years old, or so, when I wasn't around [00:32:43 CEST] <Atlenohen> I figured out all the options yes [00:32:51 CEST] <cehoyos> So what does it? [00:33:41 CEST] <Atlenohen> I had to, It was quite a run, I worked 16 hours strait for 3 days lol, finally found I suppose to be using -LIBPATH: not -L [00:33:57 CEST] <Atlenohen> Disables buffer security [00:34:28 CEST] <cehoyos> That took me more than a minute arguably (in the meantime I also compiled for Windows but decided to use wsl, not msys), but fortunately not days;-) [00:34:43 CEST] <cehoyos> to find out about LIBPATH [00:35:07 CEST] <cehoyos> But I decided to install into /lib/x86-64/whatever to avoid this issue;-) [00:36:11 CEST] <Classsic> hi [00:36:35 CEST] <Classsic> somebody know how add buffer on rtp output? [00:38:59 CEST] <Atlenohen> the linker is looking at 5 places in my case by default, without LDFLAGS, unfortunately I figured that out too late, some lib folders in MS NET, SDK and VC paths on the system, but the two easy ones were that it looked in msys64/mingw64/lib/x264.lib and ffmpeg's root github folder all that time, facepalm [00:40:15 CEST] <Atlenohen> it does not look into ffmpeg-repo/lib/x86-64/ AFAIK [00:46:42 CEST] <Atlenohen> would be a good idea updating configure for using LIBPATH: for windows, it's only using it one odd case in PKCONFIG but even that by just [00:47:27 CEST] <Atlenohen> And there's a lot of other stuff in those 3 days, that was quite a summary I made there [01:45:36 CEST] <Atlenohen> later [02:10:55 CEST] <LunaLovegood> The docs about AVCodecContext::time_base say to use 1/framerate, but wouldn't 1/90000 make more sense for MPEG stuff? [07:08:36 CEST] <elmofan> how can i auto-censor faces [13:49:01 CEST] <Numline1> Hey guys. So, what does -ss stand for? [13:49:08 CEST] <Numline1> I know it's for seeking, but what's the other s [13:49:15 CEST] <Numline1> seek start? [14:01:20 CEST] <DHE> it may just be different than -s because it's already used for scaling the image size. eg: -s 1920x1080 [14:14:04 CEST] <Numline1> DHE tl;dr ffmpeg devs are nazis [14:18:30 CEST] <Numline1> anyway, jokes aside - I was kind wondering, with all the protocols supported by ffmpeg [14:18:53 CEST] <Numline1> I kinda need to process a file from Google Storage without downloading it locally [14:19:08 CEST] <Numline1> Since my app running in app engine can't really access local storage anyway [14:19:15 CEST] <Numline1> what protocol could be used for this? [14:19:24 CEST] <Numline1> it seems async could be the one? [14:22:44 CEST] <DHE> you can always write your own or shoehorn a pipeline that the ffmpeg CLI makes awkward or impossible. [14:26:42 CEST] <Mavrik> Just read via HTTP? :) [14:27:04 CEST] <DHE> Maybe. If you need to do something more complicated, see doc/examples/avio_reading.c to write your own IO handler for ffmpeg [14:27:37 CEST] <Numline1> DHE Well, I suck at C so that's a nope :) [14:27:44 CEST] <Numline1> Mavrik will it be a streamed input though? [14:28:15 CEST] <Numline1> I'm actually going to try it right now, but I do a lot of seeking and stuff, so I'd prefer the file doesn't get downloaded in its entire for no reason [15:00:18 CEST] <elmofan> did you know the talmud is pure evil? [16:08:02 CEST] <PixelHir> Hi, I need a bit of help [16:08:14 CEST] <PixelHir> How can you convert mp3 to mp4? without image etc, sound only [16:08:26 CEST] <PixelHir> Facebook's voice messages are stored in mp4 for some reason [16:08:34 CEST] <PixelHir> and i need to convert but i don't know how [16:12:56 CEST] <pink_mist> ffmpeg -i in.mp3 -a:c copy out.mp4? [16:13:15 CEST] <DHE> that's -c:a [16:13:40 CEST] <pink_mist> ah [16:33:59 CEST] <Numline1> Folks, one more question - is it possible to pipe out from ffmpeg when creating multiple output files/images? [16:34:32 CEST] <Numline1> I'm doing this at the end of my command - thumb%04d.jpg [16:34:43 CEST] <Numline1> And I'm trying to process the result programatically if possible [16:37:28 CEST] <Numline1> ffmpeg -ss 1 -i https://example.com/test.mp4 -t 200 -vf scale=1280:-1,thumbnail=50 -vsync 0 thumb%04d.jpg [16:37:32 CEST] <Numline1> would be the entire command :) [16:37:34 CEST] <kepstin> Numline1: you can with some image formats (using either image2pipe or mjpeg for example), but note that ffmpeg will simply write one frame then the next, so you have to parse the images yourself afterwards. [16:38:05 CEST] <kepstin> (you might consider a raw image format rather than e.g. jpg if you're passing it to another program - then the images are all fixed sizes and you don't have to decode it again) [16:38:22 CEST] <pomaranc> Numline1: aren't you from slovakia by any chance? [16:38:56 CEST] <Numline1> kepstin yeah that's what I was wondering how that behaves. One output is easy to handle, multiple outputs to stdout are a mystery to me :) [16:39:00 CEST] <Numline1> pomaranc o/ [16:39:34 CEST] <kepstin> Numline1: it's not multiple outputs, it's just one output, a stream of bytes containing one image then the next. [16:39:48 CEST] <Numline1> kepstin will it send EOF though? [16:39:55 CEST] <Numline1> if so, I can easily handle that I think [16:39:56 CEST] <kepstin> Numline1: only after the last frame [16:40:26 CEST] <Numline1> kepstin that's a problem :D [16:40:55 CEST] <kepstin> that's why I recommend using a raw image format - since each frame is the same number of bytes (calculated from frame size), you just read N bytes, treat as a frame, repeat. [16:43:24 CEST] <Numline1> kepstin well, that might work, if it's not prone to errors. What I'm actually doing is I'm processing a video in Go, trying to get multiple outputs. Since the app is going to run in app engine, I'm avoiding file writes. I can get a Reader from the stdout and pass that directly to Google Storage library [16:43:56 CEST] <Numline1> but let's pretend it's language agnostic - doesn't ffmpeg output also some verbose crap to stdout? [16:44:06 CEST] <kepstin> no, stderr (and you can turn that off) [16:46:24 CEST] <Numline1> I mean, I'm getting stuff like [16:46:25 CEST] <Numline1> ffmpeg version 4.1.1 Copyright (c) 2000-2019 the FFmpeg developers [16:46:25 CEST] <Numline1> built with Apple LLVM version 10.0.0 (clang-1000.11.45.5) [16:46:36 CEST] <Numline1> judging by the exit code, it might be stdout, but I'm not arguing with you [16:47:07 CEST] <another> that is going to stderr [16:47:14 CEST] <Numline1> oh :) good to know [16:47:36 CEST] <Numline1> kepstin another okay guys, anyway, I'm going to fiddle with it a bit more, thanks for the tips on handling the outputs :) much appreciated [17:11:41 CEST] <Numline1> kepstin so um :) I was trying your advice about raw data - ffmpeg -ss 1 -i https://something.com/something.mp4 -t 200 -vf scale=1280:-1,thumbnail=50 -vsync 0 -f data - | cat - [17:11:47 CEST] <Numline1> Output file #0 does not contain any stream [17:11:59 CEST] <Numline1> The error kinda makes sense, but I'm not sure why the output needs to contain a stream [17:12:50 CEST] <furq> Numline1: you want -f rawvideo [17:13:09 CEST] <Numline1> oh shoot, yea, I just found that furq [17:13:10 CEST] <furq> although you probably actually want something like -f yuv4mpegpipe [17:13:10 CEST] <kepstin> Numline1: the "data" format isn't what you want here. Try something like "-pix_fmt bgr0 -f rawvideo" (change the -pix_fmt option to taste) [17:13:19 CEST] <Numline1> I thought that doesnt make sense since the output is actually images :) [17:13:27 CEST] <furq> video is actually images [17:13:40 CEST] <Numline1> touche [17:14:00 CEST] <furq> if go has an mjpeg demuxer/decoder then that's probably the easiest answer [17:14:38 CEST] <furq> or a y4m demuxer [17:15:06 CEST] <Numline1> well I found an encoder (images > video) [17:15:16 CEST] <Numline1> I wonder if it has the reverse :) [17:15:26 CEST] <furq> the problem with rawvideo is you need to hardcode the dimensions, pixel format etc in your receiving application [17:15:29 CEST] <Numline1> I liked the idea kepstin had, to use rawvideo and just somehow separate the bytes [17:15:43 CEST] <furq> y4m is pretty much the same thing except with a header that contains all that [17:15:51 CEST] <furq> you could probably write a demuxer in five minutes [17:16:02 CEST] <furq> https://wiki.multimedia.cx/index.php/YUV4MPEG2 [17:16:29 CEST] <Numline1> Okay, I'll try y4m and output that stuff into a file to see the format. I can probably easily decode that into images by just reading the file via buffer [17:16:35 CEST] <Numline1> furq kepstin thanks again fellas [17:16:40 CEST] <kepstin> with raw video, as long as you know the frame size and pixel format in advance, reading a frame is just "read width * height * bytes per pixel bytes into a buffer" [17:16:45 CEST] <kepstin> and repeat :/ [17:16:54 CEST] <furq> yeah which is fine if that's always the same [17:17:09 CEST] <furq> if it's not and you're using yuv images anyway (which you are if it's always jpeg) then y4m will ultimately be less hassle [17:17:39 CEST] <Numline1> Yeah, that would be ez to implement, I just don't trust that rawvideo solution. It's probably just a matter of time before something somewhere breaks and suddenly there's a frame that's incorrect and it screws all further images [17:17:43 CEST] <kepstin> y4m (or even something like nut) lets ffmpeg pass the information about width, height, pixel format, etc. to you in the container. [17:18:12 CEST] <Numline1> tbh I honestly wish I could just output the files somewhere and get JSON from ffmpeg on output to see where they are [17:18:26 CEST] <furq> there is an image2pipe muxer but i don't think anyone's ever used it [17:18:30 CEST] <kepstin> there's more moving parts involved encoding video, stuffing it into a container, demuxing it, and decoding it again... tbh i'd normally expect that to be more fragile :) [17:18:30 CEST] <furq> only the demuxer is documented anywhere [17:18:31 CEST] <Numline1> or just somehow loop the ffmpeg in some weird way and get single image for each loop [17:19:04 CEST] <Numline1> furq yeah but image2pipe (if it does what the name sounds like) probably only does one image :) [17:19:23 CEST] <furq> well the demuxer is used like cat *.jpg | ffmpeg -f image2pipe -i - ... [17:19:29 CEST] <furq> so i assume the muxer works the same way [17:19:29 CEST] <kepstin> no, image2pipe puts multiple images into a pipe [17:19:46 CEST] <furq> it's worth trying just to see what it actually outputs [17:19:48 CEST] <Numline1> kepstin yeah, but you still have to process and split them eventually :) [17:19:53 CEST] <kepstin> but i'm pretty sure it has the issue that it doesn't indicate frame boundaries in any way, you're required to parse the image somehow to find them [17:20:02 CEST] <furq> yeah i'm not sure about that either [17:20:34 CEST] <Numline1> yeah, the yuv thingie seems to be more viable in the end [17:21:10 CEST] <kepstin> but yeah, I use the piped raw video quite a bit in production, one app I have is actually a python script that renders frames with pycairo and then sends them to ffmpeg over a pipe to be encoded. [17:21:54 CEST] <Numline1> kepstin I'll save that as a fallback if YUV4MPEG2 fails for some reason, I already have metadata from ffprobe anyway [17:25:06 CEST] <Numline1> ERROR: yuv4mpeg can only handle yuv444p, yuv422p, yuv420p, yuv411p and gray8 pixel formats. And using 'strict -1' also yuv444p9, yuv422p9, yuv420p9, yuv444p10, yuv422p10, yuv420p10, yuv444p12, yuv422p12, yuv420p12, yuv444p14, yuv422p14, yuv420p14, yuv444p16, yuv422p16, yuv420p16, gray9, gray10, gray12 and gray16 pixel formats. Use -pix_fmt to select one. [17:25:08 CEST] <Numline1> yikes [17:25:10 CEST] <Numline1> which one do I want [17:25:21 CEST] <furq> don't set -pix_fmt at all [17:25:55 CEST] <Numline1> furq that's when I got the error :P [17:26:26 CEST] <Numline1> ffmpeg -ss 1 -i https://blah.com/mp4 -t 200 -vf scale=1280:-1,thumbnail=50 -vsync 0 -f yuv4mpegpipe - | cat > test.txt [17:26:52 CEST] <furq> what pixel format is the input video [17:28:23 CEST] <Numline1> ooff. It can be pretty much anything in the actual app. When it comes to this specific one, I'm not sure, how can I find out? [17:28:38 CEST] <Numline1> I ran ffprobe on it, I just dont see it there [17:29:35 CEST] <furq> Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x1080, 30 fps, 30 tbr, 1k tbn, 60 tbc (default) [17:29:41 CEST] <furq> it should say there [17:29:59 CEST] <furq> like 99% of videos you'll ever encounter are yuv420p so i figured y4m was a safe bet [17:30:18 CEST] <Numline1> furq oh :) Stream #0:1(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 2161 kb/s, 30 fps, 30 tbr, 30k tbn, 60 tbc (default) [17:30:40 CEST] <Numline1> I ran a ffmpeg command from stackoverflow which should determine that, it said: yuv420p [17:30:44 CEST] <another> furq: except mjpeg [17:31:03 CEST] <furq> mjpeg is always one of the supported y4m pixel formats [17:31:54 CEST] <another> Stream #0:0: Video: mjpeg (MJPG / 0x47504A4D), yuvj422p(pc, bt470bg/unknown/unknown), 1280x720, 18252 kb/s, 23.98 fps, 23.98 tbr, 23.98 tbn, 23.98 tbc [17:32:08 CEST] <furq> yuvj422p isn't a real pixel format [17:32:20 CEST] <furq> although idk how the y4m muxer deals with that [17:32:21 CEST] <another> it's not? [17:32:33 CEST] <furq> no it's just yuv422p with the full range flag [17:32:41 CEST] <Numline1> well I add -pix_fmt yuv420p and it works (?) [17:32:43 CEST] <furq> using the yuvj pixel formats has been deprecated for ages [17:32:47 CEST] <Numline1> It started spitting out output at least [17:33:06 CEST] <Numline1> however I can't verify it makes sense (the output), it's bunch of jibberish at this point [17:33:53 CEST] <another> furq: does this full range flag mean anything? [17:34:12 CEST] <furq> it means full colour range (0-255) instead of limited range (16-235) [17:34:31 CEST] <furq> limited range is a tv thing which is why jpeg doesn't use it [17:34:48 CEST] <Numline1> Well, I've piped the output to a file, the header says YUV4MPEG2 W1280 H720 F30:1 Ip A1:1 C420mpeg2 XYSCSS=420MPEG2 [17:34:48 CEST] <Numline1> FRAME [17:34:59 CEST] <Numline1> I guess that's it and it worked :) Now I just need to decode it in Go [17:35:27 CEST] <Numline1> The first result in Google is to use ffmpeg, lol [17:35:58 CEST] <furq> ok i checked and yuvj444p to y4m works fine [17:36:01 CEST] <furq> so that's nice to know [17:36:12 CEST] <furq> i have no idea why it would want you to set pix_fmt with a yuv source though [17:36:37 CEST] <Numline1> No idea man, but since it's the default one anyway... [17:36:55 CEST] <Numline1> Thanks again though, hopefully I'll be able to go from here [17:37:01 CEST] <Numline1> literally, since I'm using Go [17:37:08 CEST] <Numline1> *awkward silence* [18:00:05 CEST] <irwiss> not seeing this mentioned anywhere so could be a silly question, but given a naive read_frame/send_packet/receive_frame decoding loop, can frames come out of decoder out-of-order when using udp transport(or may be tcp too?) [18:01:35 CEST] <Mavrik> You'll get broken frames first [18:01:46 CEST] <Mavrik> Although it's not very likely :) [18:01:56 CEST] <Mavrik> Basically the decoder needs packets in order since frames depend on each other [18:02:17 CEST] <Mavrik> But most protocols that use UDP have some kind of timestamp counter so you can reorder packets back :) [18:02:20 CEST] <irwiss> ah so if i need to reorder it has to happen before decoder gets them [18:02:34 CEST] <Numline1> kepstin sorry, one more thing if you don't mind. You've mentioned it's basically width * height * bytes per pixel. How do I figure how many bytes there are per pixel? [18:02:48 CEST] <furq> Numline1: the pixel format [18:03:12 CEST] <furq> 4:2:0 is 12 bits per pixel, 4:2:2 is 16, 4:4:4 is 24 etc [18:03:19 CEST] <kepstin> Numline1: for this application, you'd request ffmpeg convert to a specific pixel format with a known bits/bytes per pixel [18:03:37 CEST] <furq> well y4m signals that so you could just handle it in your code [18:03:42 CEST] <irwiss> Mavrik: thanks i think this clears up my confusion [18:03:44 CEST] <Numline1> Oh I already did that, yuv420p [18:03:47 CEST] <Numline1> I'm a dummy :) Thanks! [18:03:51 CEST] <Mavrik> There's a helper function somewhere [18:03:58 CEST] <Mavrik> That gives you number of bytes per plane for pixel format [18:04:00 CEST] <pink_mist> furq: but those are bits, not bytes ... and 12 bits is hard to fit along a byte boundary :P [18:04:12 CEST] <furq> fortunately 4:2:0 is always mod2 [18:05:00 CEST] <Mavrik> Yeah, but YUV420P will be planar [18:05:08 CEST] <Mavrik> So you'll have a plane that's width*height [18:05:10 CEST] <Mavrik> and two planes that are half [18:05:18 CEST] Action: Numline1 is confused [18:05:41 CEST] <Numline1> "two planes that are half" [18:05:49 CEST] <Numline1> ChanServ: NSA wants to know your location [18:06:16 CEST] <furq> Numline1: if you're just handing the frame off to something else, it's not something you need to care about [18:07:10 CEST] <Numline1> furq oh, I'm actually trying to split that YUV4MPEG2 input into separate frames [18:07:19 CEST] <Mavrik> That's fine then [18:07:24 CEST] <Mavrik> I mean, everything will be in AVFrame struct [18:07:27 CEST] <Mavrik> And you don't need to care [18:07:29 CEST] <Mavrik> :) [18:07:41 CEST] <Numline1> oh is it in a separate struct? I didn't see that in the binary blob [18:07:44 CEST] <Numline1> I've seen the header [18:07:51 CEST] <Numline1> I thought I had to do the math myself [18:07:54 CEST] <furq> Mavrik: this is ffmpeg.c's y4m output being read into something else [18:08:19 CEST] <Numline1> oh, yeah, that's true. AVFrame is a ffmpeg struct [18:08:25 CEST] <Numline1> I just have the raw output [18:09:24 CEST] <Numline1> basically just to sum up, all I need is to split the output (input in my app) into a bunch of images. Since it's 12 bits, I'm not entirely sure I'll be able to find the amount of bytes per frame [18:09:37 CEST] <furq> Numline1: like i said, a 4:2:0 frame is always mod2 [18:09:38 CEST] <Numline1> this is all new to me, so the answer might be obvious though [18:09:45 CEST] <furq> so it'll always be some multiple of 48 bits [18:10:39 CEST] <Numline1> thinking emoji [18:10:51 CEST] <furq> which is to say width * height * 1.5 will always be an integer [18:11:03 CEST] <Mavrik> Numline1: YUV420 frames are funny because as opposed to more usual RGB images, they have one channel that's full sized (Y) and two channels that are half sized (UV) [18:11:17 CEST] <Mavrik> so the size of each frame is width * height * 1.5 :) [18:11:31 CEST] <kepstin> actually quarter size - U and V are both 1/2 height and 1/2 width [18:11:36 CEST] <furq> half sized in both dimensions yeah [18:11:54 CEST] <Numline1> y u do this frames [18:12:21 CEST] <Numline1> Mavrik I understand what you're saying, I just can't imagine how that's actually looking in the end (the frame) [18:12:25 CEST] <Numline1> isn't it stretched? [18:12:33 CEST] <furq> the U and V planes are chroma [18:12:45 CEST] <furq> so you have full-size luma and then the chroma planes are resized to match on playback [18:12:56 CEST] <furq> like i said, 99% of video uses 4:2:0 [18:13:00 CEST] <kepstin> Y is encoder full resolution, U and V are quarter resolution because they encode information the eye is less sensitive to [18:13:09 CEST] <furq> so you've seen it a million times and never noticed [18:13:55 CEST] <Numline1> that's interesting and a bit funky :) [18:14:03 CEST] <furq> unless you've seen youtube videos of screen captures or coloured text overlays and wondered why they look so bad [18:14:04 CEST] <JEEB> yes, all players and things convert YCbCr to RGB [18:14:05 CEST] <Numline1> I always thought it's just a series of x y images [18:14:22 CEST] <JEEB> yes, it's three "images" per image [18:14:27 CEST] <JEEB> Y is teh "grayscale" image [18:14:33 CEST] <JEEB> then Cb ir Chroma-blue [18:14:36 CEST] <JEEB> and Cr is chroma-red [18:14:49 CEST] <JEEB> and the chroma planes are "one sample for each 2x2 block" [18:14:51 CEST] <JEEB> that is 4:2:0 [18:15:02 CEST] <JEEB> full resolution chroma and luma is 4:4:4 [18:15:16 CEST] <Numline1> ahhh [18:15:23 CEST] <Numline1> well, I know two things [18:15:25 CEST] <JEEB> so when a player plays video, it receives 4:2:0 YCbCr from decoder, then scales the chroma to full resolution [18:15:31 CEST] <Numline1> 1) It's more complicated than I thought [18:15:34 CEST] <JEEB> and then converts to RGB [18:15:35 CEST] <Numline1> 2) Jesus christ why [18:15:36 CEST] <JEEB> so it can be shown [18:15:51 CEST] <kepstin> Numline1: why? because video is huge and this lets it be smaller [18:15:54 CEST] <JEEB> there's a lot of details in this too [18:16:07 CEST] <furq> the historical motivation is that the luma plane in YUV is the same thing that black-and-white tv transmissions used [18:16:12 CEST] <JEEB> like, the chroma samples aren't actually in the middle of that 2x2 block [18:16:15 CEST] <Mavrik> Numline1: if you want pictures: https://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios :) [18:16:20 CEST] <furq> so YUV itself is for backward compatibility, and then the small chroma planes are to save bandwidth [18:16:24 CEST] <JEEB> the MPEG-2 Video and H.264 default is "top left" if I recall correctly [18:16:40 CEST] <JEEB> so when you pull the chroma to full resolution, you will have to scale correctly [18:16:41 CEST] <Numline1> Mavrik thank you, that makes it more clear :) [18:16:42 CEST] <JEEB> \o/ [18:16:56 CEST] <furq> and yes of course we're still using a format designed for backward compatibility with the 1950s [18:16:59 CEST] <furq> why wouldn't we be [18:17:03 CEST] <Mavrik> And https://stackoverflow.com/questions/27822017/planar-yuv420-data-layout :) [18:17:06 CEST] <Numline1> wow, I never knew this stuff is so complex [18:17:26 CEST] <Numline1> btw I've noticed the output I generated actually has one frame per line [18:17:37 CEST] <Numline1> If I'm reading that correctly [18:18:05 CEST] <Numline1> which is a lie because I'm not, there's 3 frames on 2 lines. I thought I found a shortcut [18:18:30 CEST] <Numline1> It seems to be delimited by something like "¬¬¬¬¬FRAME" [18:18:36 CEST] <furq> the frame always ends with a newline [18:18:49 CEST] <furq> but there could obviously be an 0x0A in the actual frame data [18:19:03 CEST] <kepstin> the newline byte is valid in the data, yeah, so you can't rely on it as a delimiter [18:19:03 CEST] <Numline1> who's that? [18:19:11 CEST] <furq> 0x0A is \n [18:19:17 CEST] <Numline1> oh, gotcha [18:19:17 CEST] <kepstin> don't use a text parser for binary data :) [18:19:27 CEST] <JEEB> thankfully the pixel format should tell you the frame sizes :P [18:19:33 CEST] <furq> yeah it's easy to calculate the dimensions [18:19:37 CEST] <Numline1> Hah, I just wanted to see the header before I do any decoding :) [18:19:53 CEST] <furq> you really don't need to care about how the data is packed, you just need to know the bits per pixel and dimensions [18:20:05 CEST] <Numline1> It's just a bit weird. I should have at least <amount_of_frames> newlines [18:20:06 CEST] <Numline1> or more [18:20:09 CEST] <Numline1> I have one less, which is weird [18:20:54 CEST] <Numline1> basically ffmpeg said it parsed 3 thumbnails, the file has 4 lines (header, "FRAMES" and then two actual lines). But I guess it's just Sublime being funky, I'll try to actually parse it in code :) [18:21:31 CEST] <JEEB> I recommend hex editors :P [18:21:36 CEST] <JEEB> hxd on windows [18:21:40 CEST] <JEEB> and I think I use bless on linux [18:21:47 CEST] Action: Numline1 uses macOS [18:21:50 CEST] <Numline1> :P [18:21:55 CEST] <JEEB> then whatever is sane for that [18:22:05 CEST] <JEEB> text editor usually isn't nice for this sort of stuff :P [18:23:05 CEST] <Numline1> yeah, poor VisualStudio Code is just displaying empty space :P [18:23:11 CEST] <Numline1> I'll try to find something [18:23:35 CEST] <JEEB> https://github.com/ridiculousfish/HexFiend [18:23:37 CEST] <JEEB> something like this? [18:24:44 CEST] <Numline1> yeah I found something similar :) Basically looks like this - https://numshare.s3-eu-west-2.amazonaws.com/Screen-Shot-2019-04-24-18-24-25… [18:25:01 CEST] <Numline1> you guys can possibly reconstruct part of my first frame now #securityleak [18:49:40 CEST] <Numline1> btw I've just noticed, ppm might be used as well :) Is that better/worse in some way? [18:53:11 CEST] <Numline1> although it probably just saved the latest image, so that's irrelevant :) [19:09:47 CEST] <emsjessec> why does ffmpeg get stuck sometimes and I have to ctrl+c it? [19:09:57 CEST] <emsjessec> ffmpeg -y -nostdin -i (input file) -filter:a loudnorm (output file) 2>&1 [19:10:17 CEST] <emsjessec> it's running from PHP's exec function and there's no input being sent to STDIN [19:12:41 CEST] <durandal_1707> emsjessec: is it using CPU? [19:15:47 CEST] <ChocolateArmpits> emsjessec, where did you get the binary [19:16:48 CEST] <ChocolateArmpits> Also for loudnorm you may want to downsample to 48kHz because it always outputs an upsampled stream [19:17:22 CEST] <ChocolateArmpits> It does that to increase measurement accuracy [19:39:55 CEST] <emsjessec> ok [20:27:33 CEST] <DHE> is there documentation about what mpegtsraw does differently from the regular mpegts demuxer? [21:16:18 CEST] <zerodefect> When using the C-API and setting up the x264 encoder, is it possible to somehow log the low-level settings (x264_params) after the encoder is configured? [21:19:48 CEST] <kepstin> zerodefect: the x264 encoder itself already logs (as a text log message) its internal settings when it starts up [21:20:08 CEST] <kepstin> other than that, the answer is "anything is possible if you code it" :/ [21:20:31 CEST] <JEEB> after you have applied the AVOptions they get eaten from the list [21:20:53 CEST] <JEEB> so log them before you apply them to libx264's AVCodecContext [21:21:01 CEST] <JEEB> if you want to log them [21:21:16 CEST] <JEEB> and then you'll have to log all of the AVCodecContext parameters you are interested in [21:24:19 CEST] <zerodefect> Ok. Nothing elegant. The reason I ask is that I'm trying to set a CBR stream but the bitrate is fluctating to above 4.2 MBit/s and the HW IRD receving is very unhappy about the video bitrate. I've set NAL=HRD/vbv-bufsize, but I clearly need to tweak something else. I was wanting to drill down into x264_params a bit more :/ [21:25:37 CEST] <JEEB> make sure it's complaining about the video stream [21:25:44 CEST] <JEEB> also you need to set both maxrate and bufsize [21:26:20 CEST] <JEEB> nal-hrd has to be set to either vbr or cbr for getting the HRD headers written into the video stream regarding the buffering parameters [21:26:52 CEST] <JEEB> often when people have things receiving complaining it's more often about the muxer/transmission [21:27:00 CEST] <JEEB> rather than actual video encoding rates [21:27:48 CEST] <JEEB> make sure you're using muxrate with MPEG-TS if you're using that, and if my development VM would boot at least once a day proper I would be able to tell you the bit rate option for the UDP protocol :P [21:28:05 CEST] <zerodefect> Ok. What is a sensible vbv-bufsize? Bitrate / fps? [21:28:19 CEST] <JEEB> that 100% depends on your requirements [21:28:43 CEST] <zerodefect> Do you know if this is outlined in any of the DVB docs? [21:29:02 CEST] <JEEB> I think DVB specs only talk about the MPEG-TS level mux [21:29:13 CEST] <JEEB> but feel free to check, I haven't checked too hard :P [21:29:28 CEST] <JEEB> most encoders out there don't let you tweak this stuff too much if I understand it correctly [21:29:51 CEST] <JEEB> usually it's (maxrate * seconds of initial buffer) [21:29:53 CEST] <JEEB> kidn of thing [21:29:54 CEST] <zerodefect> Yes, that is what I've seen thus far. It feels a bit more like an art to find the best settings to keep this HW encoders happy. [21:32:33 CEST] <Mavrik> There's of course also an option in x264 to stuff the stream with null packets :) [23:47:03 CEST] <GuiToris> hey, I have a problem. I created some lossless video files with ffmpeg and imported them into Premiere and they look like this : http://ix.io/1H7N [23:47:33 CEST] <GuiToris> -c:v libx264 -preset veryslow -crf 0 [23:47:39 CEST] <GuiToris> that's what I used [23:48:28 CEST] <GuiToris> if I reencode the video with ffmpeg -i lossless.mp4 new.mp4 this color artifact disappears [23:48:34 CEST] <GuiToris> what should I do? [23:48:37 CEST] <furq> that link doesn't work [23:48:54 CEST] <GuiToris> furq, weird it works here :S [23:49:03 CEST] <GuiToris> can't you download it with wget? [23:49:23 CEST] <GuiToris> wget 'http://ix.io/1H7N' [23:50:29 CEST] <GuiToris> it also works here but you'll lose the extension (it's jpg) [23:50:38 CEST] <GuiToris> could you open it? [23:51:48 CEST] <another> not sure if premiere support the lossless profile [23:52:37 CEST] <GuiToris> I could edit and play back them but they are all ugly [23:52:44 CEST] <GuiToris> isn't it just a color profile or something? [23:53:21 CEST] <GuiToris> I would keep the good quality but right now even ffmpeg -i lossless lossy is way much better [23:55:01 CEST] <GuiToris> isn't premiere the leading video editing software? that would be a shame if it didn't support lossless files [23:57:10 CEST] <GuiToris> My format profile is 'High 4:4:4 Predictive(a)L5.1' [23:57:31 CEST] <GuiToris> CABAC / 16 Ref Frames [00:00:00 CEST] --- Thu Apr 25 2019

1 0

ffmpeg-devel.log.20190423
by burek 24 Apr '19

24 Apr '19

[02:37:47 CEST] <cone-924> ffmpeg 03Jun Zhao 07master:a0877648472a: examples/avio_reading: Use avio_context_free() to free AVIOContext [07:30:52 CEST] <rcombs> the file produced by fate-lavf-mkv produces warnings in matroskadec and I'm not entirely sure it demuxes correctly [07:32:22 CEST] <rcombs> mkvalidator doesn't complain about anything relevant, so I think this is probably demux-side [07:32:47 CEST] <rcombs> seems like it overreads the last cluster [08:24:00 CEST] <rcombs> oh, I guess this is probably a regression in 18a851aca766ff8c7199c9e0c37d8fa642e41920 [08:25:18 CEST] <rcombs> &nope [08:25:52 CEST] <rcombs> regressed in 9326117bf63b04a466d9e787224e56ba8cdbb215, I guess? [08:25:57 CEST] <rcombs> seems to happen at EOF in most files [12:51:07 CEST] <cone-318> ffmpeg 03Sergey Svechnikov 07master:703583dbb1f3: avcodec/cuviddec: improve progressive frame detection [12:59:27 CEST] <cone-318> ffmpeg 03Sergey Svechnikov 07release/4.1:7c2dd1f969c9: avcodec/cuviddec: improve progressive frame detection [13:04:50 CEST] <cone-318> ffmpeg 03Sergey Svechnikov 07release/4.0:fc630d7b437b: avcodec/cuviddec: improve progressive frame detection [13:41:36 CEST] <cone-318> ffmpeg 03Paul B Mahol 07master:ccc07ebe4527: avfilter/af_surround: add 6.1/6.0 upmix from stereo [13:41:37 CEST] <cone-318> ffmpeg 03Paul B Mahol 07master:7a128ac2bca2: avfilter/af_surround: expose window size to user [13:41:38 CEST] <cone-318> ffmpeg 03Paul B Mahol 07master:ce15c3a4c8d6: avfilter/af_surround: switch to activate [18:12:46 CEST] <cone-834> ffmpeg 03Paul B Mahol 07master:4a69b18242dc: avfilter/af_surround: export more channel's in/out gains [22:44:11 CEST] <cone-633> ffmpeg 03Dan Sanders 07master:22c820f50904: libavformat/mov: limit nb_frames_for_fps to INT_MAX [22:58:06 CEST] <cehoyos> Has anybody ever used frei0r? [00:00:00 CEST] --- Wed Apr 24 2019

1 0

ffmpeg.log.20190423
by burek 24 Apr '19

24 Apr '19

[04:18:08 CEST] <TheBest_F-22> Does anyone know where to get the Latest FFmpeg "Stable" (4.1.3) for Windows (pre-built)? [04:19:15 CEST] <TheBest_F-22> Zeranoe tends to no longer keep up-to-date with "Stable", for some Reason... [04:25:49 CEST] <TheBest_F-22> Anyone knows if Kyle/Zeranoe simply gave up on Building "Stable" Releases? [04:25:52 CEST] <TheBest_F-22> (even though there are so few of them...) [05:14:32 CEST] Action: TheBest_F-22 wonders if there's anyone listening... [05:23:37 CEST] <elmofan> TheBest_F-22: those who read your question do not know the answer, or are witholding it from you. [05:23:44 CEST] <elmofan> Perhaps you need to offer incentives. [05:23:57 CEST] <elmofan> but i doubt that would help [05:27:22 CEST] <TheBest_F-22> elmofan: Thanks. I'm actually wondering if it's because Kyle/Zeranoe is the only one still bothering to do a Proper "trustworthy" Windows Build of FFmpeg from Source (as feature complete as possible on this Platform)... [05:28:02 CEST] <elmofan> does he have an email addr? [05:30:46 CEST] <TheBest_F-22> Maybe He (Zeranoe) doesn't think that the Changes from 4.1.1 to 4.1.3 are "Worth it"(?)... (Or He just has an Automated Process for Git "Nightlies" that isn't capable of Processing "Releases"/"Stable"s... Who knows...) [05:31:09 CEST] <TheBest_F-22> He has a Forum, a Contact Page, and a Twitter account... [05:31:29 CEST] <elmofan> i expect he knows better why he does or doesn't do things than I do [05:31:40 CEST] <TheBest_F-22> Last time I gave him this thread -> twitter.com/TheBestF22/status/1098260668191510528 [05:32:02 CEST] <TheBest_F-22> He apparently hear it and it appeared a couple of days later. [05:32:47 CEST] <TheBest_F-22> I just was hoping for him to get back to what he did before: He was almost always only half a week behind a Stable Release... [05:33:14 CEST] <TheBest_F-22> (but normally, just a single day, I think...) [05:37:11 CEST] <TheBest_F-22> I just read through "https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/4154f8967820ca734a77ce91bb590…" and there seems to be a lot of useful "Fixes"... [05:38:05 CEST] <TheBest_F-22> it's weird that Termux for Android (on arm64) got the Stable update before Windows... [05:39:04 CEST] <TheBest_F-22> (BTW: Zeranoe seems to be the only Windows Build Listed on the Official "http://ffmpeg.org/download.html#build-windows" Page... [05:49:33 CEST] <TheBest_F-22> Maybe it has to do with what's written on the right side of said Official Download site... (in the "Get the Sources" Section" [05:52:13 CEST] <TheBest_F-22> Sometimes, it seems that FFmpeg developers themselves recommend the Latest Git Commit Snapshot over the "Stable" one that, hopefully, should be more Reliable and with less possible Security Vulnerabilities... [05:56:01 CEST] <TheBest_F-22> Even Zeranoe's Own Website has "hover text" on the "Version" selection that Defaults and suggests the Latest "Git Version" over the "Stable" one... [05:58:04 CEST] <TheBest_F-22> I'd Like to see all those Fixes (and Security Patches) on Windows too... (though I doubt that I would encounter an exploit coming from Videos on Legal Streaming Sites, the Source of most of My FFmpeg use cases...) [06:00:24 CEST] <TheBest_F-22> I just Noticed I've been at this for far too long... Gotta go get some Dinner and some Sleep too... --> 5 a.m. here in Lisbon, Portugal... [06:00:36 CEST] <TheBest_F-22> C Ya L8r then!. ;P [06:04:46 CEST] <TheBest_F-22> if someone sees Zeranoe around Here, Kindly ask Him to Build a "Stable" (4.1.3) Release of FFmpeg... [06:05:32 CEST] <TheBest_F-22> K thx Bai. (for now) [07:48:31 CEST] <gour> ll [07:50:01 CEST] <gour> morning [07:51:00 CEST] <gour> our non-profit organization is recorring video from our public programs/lectures and here is the ffmpeg -i output: https://pastebin.com/vR5Sv2U6 [07:53:01 CEST] <gour> i need some recommendation how (to what) convert such recordings to make them smaller for more convenient upload to the server's public download area, but not to sacrifice quality too much? now ~1hr15min is ~1.7G [08:28:54 CEST] <elmofan> gour: will the users want to view them in browser? [08:29:53 CEST] <gour> elmofan: i belive that downloading them is preferred option, although we make a version for online viewing as well [08:30:05 CEST] <gour> *we can make... [08:30:43 CEST] <elmofan> i tend to prefer h264, but browsers don't generally seem to support it [08:30:52 CEST] <elmofan> so that is one consideration [08:31:07 CEST] <elmofan> i am no expert in encoding though, so I can not advise [08:31:07 CEST] <furq> all browsers support h264 [08:31:24 CEST] <elmofan> is it the container then? no .mp4? [08:31:40 CEST] <furq> h264/aac in mp4 is the most widely supported thing there is [08:32:03 CEST] <furq> gour: 1.7G for 75 minutes of 720p is already pretty small [08:32:44 CEST] <elmofan> thank you for the correction furq [08:33:01 CEST] <gour> furq: so, not much can be saved space-wise? [08:33:17 CEST] <furq> probably not without downscaling or something like that [08:33:25 CEST] <furq> it depends on the content though [08:34:09 CEST] <gour> it's kind of "classical" presentation with light usage of flip-chart [11:54:51 CEST] <seni> how does one read from an input audio stream? im getting an "invalid start code [..] pipe::invalid data found when proc input".the input format is mulaw in wav. im reading like `ffmpeg -y -loglevel error -acodec:a pcm_mulaw -f wav -i` [14:37:50 CEST] <Ariyasu> i have a h264 video that plays back fine and a e-ac3 audio file that also plays back fine [14:38:10 CEST] <Ariyasu> when i mux the two together, the output becomes very stuttery/jerky/choppy [14:38:26 CEST] <Ariyasu> any ideas why ? or how i can prevent/fix it [14:45:40 CEST] <elmofan> what are you using for playback Ariyasu [14:45:53 CEST] <elmofan> try with -ao null [14:48:10 CEST] <Ariyasu> mpc but it doesn't matter what media player i use [14:48:17 CEST] <Ariyasu> i will give -ao null a try [14:50:32 CEST] <Ariyasu> "Unrecognized option 'ao'." [14:51:22 CEST] <elmofan> well it's a long shot anyway [14:51:28 CEST] <lemourin> Is it possible to distinguish mp4 from mov using ffmpeg? Other than just looking at the extension. [14:51:47 CEST] <Ariyasu> what was -ao null supposed to do? [14:52:09 CEST] <elmofan> selects a null sink for your audio output [14:52:36 CEST] <elmofan> to eliminate possibility of your player+system having audio driver issues [14:52:46 CEST] <elmofan> that might get triggered by unusual files [15:10:00 CEST] <Ariyasu> elmofan i see this error in output everytime i try to mux [15:10:03 CEST] <Ariyasu> "[eac3 @ 0000000002c4e040] Estimating duration from bitrate, this may be inaccurate" [15:10:18 CEST] <Ariyasu> you think this is the cause of the choppy playback? [15:10:36 CEST] <elmofan> this is beyond my knowledge [15:13:02 CEST] <ritsuka> lemourin: you can check the major_brand with ffprobe [15:19:59 CEST] <lemourin> ritsuka: this won't work most of the time because i have mov files which don't have this metadata field set [15:20:29 CEST] <lemourin> MediaInfo manages to differentiate those files somehow though [15:20:36 CEST] <ritsuka> uh, major_brand is a required part of mov/mp4 [15:20:55 CEST] <lemourin> oh [16:27:24 CEST] <Ariyasu> [matroska,webm @ 00000000005895c0] Element at 0x2687a58 ending at 0x268b7b6 exceeds containing master element ending at 0x2687a52 [16:27:30 CEST] <Ariyasu> what does this mean? [17:15:59 CEST] <Adcock> I need help to reverse a video and the reversed portition at the end of actual video. [17:16:07 CEST] <Adcock> Can this be done? [17:16:40 CEST] <Adcock> I need help to reverse a video and then add reversed portition at the end of actual video. [17:49:46 CEST] <Adcock> I figured it out guys. [17:49:48 CEST] <Adcock> :D [19:55:56 CEST] <dablitz> good afternoon channel I want to rtp stream audio and also recieve rtp audio at the same time. is there a command with ffmpeg where I can ffmepg and ffplay off 2 seperate ports simulataniously [20:03:06 CEST] <dablitz> I am thinking, and please correct me --> ffmpeg -re -f alsa -i hw,1:0 -acodec mulaw -f rtp rtp://xxx.xxx.xxx.xxx:1234 | ffplay rtp://xxx.xxx.xxx.xxx:4321 [20:12:00 CEST] <dablitz> I have to run out a get some batteries, i will be back in 30 minutes [21:25:49 CEST] <dablitz> can anyone help [21:49:17 CEST] <ChocolateArmpits> dablitz, yeah go ahead [21:55:27 CEST] <DHE> he's doing rtp shenanigans [21:57:39 CEST] <another> why don't you just start two processes separately? [22:19:25 CEST] <dablitz> ChocolateArmpits: good afternoon channel I want to rtp stream audio and also recieve rtp audio at the same time. is there a command with ffmpeg where I can ffmepg and ffplay off 2 seperate ports simulataniously [22:19:50 CEST] <dablitz> ChocolateArmpits: I am thinking, and please correct me --> ffmpeg -re -f alsa -i hw,1:0 -acodec mulaw -f rtp rtp://xxx.xxx.xxx.xxx:1234 | ffplay rtp://xxx.xxx.xxx.xxx:4321 [22:20:17 CEST] <ChocolateArmpits> wew you don't want to use a pipe for that [22:20:29 CEST] <dablitz> this is for my ham network and I don't know how [22:22:34 CEST] <dablitz> I have 6 radio repeaters, and my home pc. I want to be able to key up my radio at home and rtp audio direct to all my repeaters at once [22:22:37 CEST] <ChocolateArmpits> While it's possible to have both a sender and receiver in the same process via output mapping it would probably be much better launch two separate processes as another suggests [22:22:53 CEST] <dablitz> ok [22:23:03 CEST] <dablitz> is my ffmpeg string correct [22:23:08 CEST] <ChocolateArmpits> It's not [22:23:20 CEST] <dablitz> can i get a correction [22:25:07 CEST] <ChocolateArmpits> Provided your output destination is correct [22:25:09 CEST] <ChocolateArmpits> Maybe this: ffmpeg -re -f alsa -i hw,1:0 -i rtp://xxx.xxx.xxx.xxx:4321 -map 0 -acodec mulaw -f rtp rtp://xxx.xxx.xxx.xxx:1234 -map 1 -codec copy -f nut - | ffplay -sync ext -probesize 32 -f nut - [22:25:25 CEST] <ChocolateArmpits> But because I don't know bash I can't suggest to how to start two processes at once :/ [22:25:57 CEST] <ChocolateArmpits> That sample should work but it's not an ideal case [22:27:29 CEST] <dablitz> the reason for the ffplay is when my repeaters receive RF they will stream that to my home pc, hence the two [22:29:46 CEST] <dablitz> so I need to send to each repeater and receive back from the repeater, I dont mind having 6 different instances of this running I just need to know the config is correct [22:35:46 CEST] <pzich> ChocolateArmpits: are you proposing using something like a fifo instead of a pipe? Or a different approach entirely? [22:38:24 CEST] <ChocolateArmpits> dablitz, by sending to the repeater do you mean sending anything or what you expect to get back? [22:39:50 CEST] <dablitz> ChocolateArmpits: my radio is connected to my mic input on my computer, so when I key my mic it streams to the raspberry pi at the repeater, and when the repeater recieves RF from another radio it streams back to my pc and out soundcard into my radio and I hear it [22:45:40 CEST] <ChocolateArmpits> dablitz, by radio you mean using it as a loudspeaker? [22:45:58 CEST] <ChocolateArmpits> I'm trying to figure it one by one [22:47:26 CEST] <dablitz> yes kindof. the radio on my desk will play as a loud speaker what it recieves, but will also tx via vox (inside the radio) on a simplex channel to my portable radio that I carry around town with me [22:48:08 CEST] <dablitz> i just need to have the stream of unencrypted audio go back and forth [23:10:39 CEST] <ChocolateArmpits> dablitz, do you want only one mic to engage all the repeaters? [23:11:24 CEST] <dablitz> the raspberry pi on each repeater only has 1 mic [23:12:49 CEST] <dablitz> all pi's are on a vpn and I was multicasting [23:12:55 CEST] <dablitz> on the vpn [23:13:30 CEST] <dablitz> that way I can use internal ip's and not have to worry about remotes having static public ip's [23:39:38 CEST] <calamari> The AVI container has a multitude of drawbacks, but one nice thing is that if you only copy some of it, you can still have a playable file, which isn't the case with MKV for example. Does anyone know of other containers that can tolerate truncated containers? [23:40:10 CEST] <cehoyos> All do iirc [23:40:50 CEST] <calamari> cehoyos: not true.. MKV doesn't work if you don't have the end [23:40:58 CEST] <cehoyos> That's news to me. [23:41:31 CEST] <cehoyos> (With mov and friends, the part that can be at the end of the file but can as well be at the beginning is needed - if it is at the end, you cannot cut the file) [23:41:48 CEST] <calamari> cehoyos: try ripping a blu-ray with MakeMKV. It's writing a mkv all along, but you can't play it until it finishes up [23:42:14 CEST] <furq> that sounds like a makemkv problem [23:42:16 CEST] <cehoyos> So your questions was actually: Which applications apart from MakeMKV write files so that they cannot be played while written? [23:42:33 CEST] <calamari> LOL! [23:42:43 CEST] <furq> anyway mpegts is the canonical unbreakable container format [23:42:58 CEST] <cehoyos> You mean like mpeg-ps? [23:43:14 CEST] <cehoyos> And without pat/pmt? [23:43:16 CEST] <calamari> furq: I'll give it a try, thanks [23:46:42 CEST] <calamari> I believe the problematic part of mp4 and mkv is called the MOOV atom, which has to be updated for the file not to be corrupted [23:46:50 CEST] <furq> of mp4, sure [23:46:56 CEST] <furq> there's no such thing in mkv [23:48:22 CEST] <BtbN> There is, but it doesn't break the file to uselessness if it's missing. It's just not seekable. [23:48:34 CEST] <cehoyos> as said, the moov atom can be at the start of the file, if it is at the start of the file, you can cut it and (still) play it. [23:48:34 CEST] <furq> i meant it's not called a moov atom [23:49:02 CEST] <calamari> BtbN: are there any containers besides AVI that don't have a moov atom or anything like it? [23:49:10 CEST] <furq> mpegts [23:49:10 CEST] <BtbN> mpegts [23:49:11 CEST] <cehoyos> All except mov? [23:49:12 CEST] <BtbN> flv [23:49:24 CEST] <furq> flv as well but that's much more restrictive in terms of codecs [23:49:30 CEST] <BtbN> mkv in streamable mode [23:49:32 CEST] <furq> basically any container designed for streaming [23:49:42 CEST] <calamari> alrighty, thanks! sounds like mpeg-ts is the answer [23:49:47 CEST] <furq> bear in mind mpegts has no seek index [23:49:53 CEST] <BtbN> mpeg-ts is pretty heavy in terms of overhead as well [23:49:56 CEST] <BtbN> I'd just go for mkv [23:50:00 CEST] <BtbN> for pretty much everything [23:50:10 CEST] <calamari> mkv doesn't work, it's broken if you don't have the entire file [23:50:15 CEST] <furq> yeah idk what makemkv is doing but ffmpeg's mkv output will work if it's truncated [23:50:15 CEST] <cehoyos> No [23:50:17 CEST] <BtbN> Unless you want it to play in a Browser, then you have the choice between mp4 and mp4 [23:50:42 CEST] <cehoyos> Your application is "broken" because it does not write mkv in the normal way where it can be played before being finished. [23:50:53 CEST] <cehoyos> In any case, you can certainly cut your finished mkv file and it is still playable. [23:51:03 CEST] <calamari> cehoyos: in this case I'm not using makemkv, I was just offering that as an example [23:51:16 CEST] <furq> what player are you using [23:51:19 CEST] <furq> maybe that's broken [23:52:52 CEST] <calamari> furq: well with the partial mkvs, I tried vlc, mpv, a browser, an old mplayer.. it seemed universally broken [23:53:09 CEST] <furq> weird [23:53:27 CEST] <calamari> I realize mkv and mplayer are probably not really a different test [23:53:43 CEST] <calamari> err mpv * [23:54:02 CEST] <calamari> anyhow thanks everyone, I'll try it with mpeg-ts [23:54:05 CEST] <cehoyos> They all work fine with cut mkv files [23:54:41 CEST] <cehoyos> None of them can play invalid mkv file which is likely what your application produces if you don't allow it to run until the end. [23:58:12 CEST] <calamari> can you seek in a partial mpeg-ts? [23:58:27 CEST] <calamari> (you can in avi) [23:58:41 CEST] <calamari> I can try it and see :) [23:58:46 CEST] <BtbN> mpeg-ts is not seekable [23:59:34 CEST] <calamari> bummer. maybe AVI is the only answer then [00:00:00 CEST] --- Wed Apr 24 2019

1 0

ffmpeg-devel.log.20190422
by burek 23 Apr '19

23 Apr '19

[00:51:17 CEST] <cone-203> ffmpeg 03Michael Niedermayer 07master:f17e8e90bb1f: avcodec/ccaption_dec: Add a blank like at the end to avoid rollup reading from outside [00:51:17 CEST] <cone-203> ffmpeg 03Michael Niedermayer 07master:158efc045c71: avcodec/agm: Do not crash on invalid codes [00:51:17 CEST] <cone-203> ffmpeg 03Michael Niedermayer 07master:7ee7bb92e603: avcodec/agm: Check for too many too short codes in make_new_tree() [00:51:17 CEST] <cone-203> ffmpeg 03Michael Niedermayer 07master:df9ef925f97d: avcodec/agm: remove ;; [07:07:04 CEST] <cone-379> ffmpeg 03Steven Liu 07master:613ca7b100ac: avformat/dashdec: add ProgramInformation parser [08:08:46 CEST] <cone-379> ffmpeg 03Karthick J 07master:eeca67e0232c: avformat/dashenc: Fix a bug with writing "final" manifest [12:04:12 CEST] <durandal_1707> michaelni: did we requested slots for GSoC? [12:10:33 CEST] <michaelni> durandal_1707, just checked, yes, min/max slot request has been entered already [12:37:40 CEST] <durandal_1707> atomnuker: come on, push some patches finally! [14:45:03 CEST] <atomnuker> durandal_1707: don't have any, I'm busy [14:48:56 CEST] <durandal_1707> atomnuker: with what? [14:54:01 CEST] <atomnuker> metro 2033 [15:01:35 CEST] <durandal_1707> not again [15:10:43 CEST] <atomnuker> hey, it beats thinking about how every place in the universe is fucked up and I have to pick my poison [15:12:23 CEST] <durandal_1707> atomnuker: nooooooo [15:15:23 CEST] <BBB> atomnuker: don't you want to write new codecs anymore? [15:35:57 CEST] <atomnuker> BBB: I do, its very fun to experiment, but right now I can't seem to get motivated [15:36:32 CEST] <BBB> but you don't want to play games all day for the rest of your life, right? [15:36:36 CEST] <BBB> what are you looking for? [15:37:00 CEST] <BBB> more money? more purpose? social connection? life companion? sth. else? [15:37:12 CEST] <BBB> or just to be left alone? [16:45:09 CEST] <thebombzen> I'm looking into writing a fate test for the patch I submitted a few weeks ago, at Michael N's recommendation. problem is... I'm not entirely familiar with how to write a fate test or the standards thereof. [16:45:14 CEST] <thebombzen> I read fate.html but it mostly says how to run fate tests, not how to write fate tests [16:45:39 CEST] <thebombzen> is there any documentation on this or developer policy [16:47:25 CEST] <JEEB> seems to be pretty scattered. for example the doc/developer.texi talks aoubt adding new files to fate-suite but not related to the details of fate [16:47:39 CEST] <JEEB> anyways, the core is that the tests are in Makefiles under tests/fate/* [16:48:09 CEST] <JEEB> your patch was regarding the ffmpeg.c cli so most likely a test file that tests ffmpeg.c would be the default spot to add it to [16:48:46 CEST] <thebombzen> should I just emulate what other fate tests do? [16:48:52 CEST] <JEEB> something like tests/fate/ffmpeg.mak is probably the place? [16:49:31 CEST] <JEEB> you can look at some FATE sample that is good enough for your input, and then see if one of the framemd5/crc/etc muxers is good enough for your purpose [16:49:37 CEST] <JEEB> since it gives you DTS/PTS and some other stuff [16:50:29 CEST] <thebombzen> alright [16:50:35 CEST] <JEEB> there are various raw H.264 etc samples in the FATE test suite thankfully [17:46:38 CEST] <cone-583> ffmpeg 03Jun Zhao 07master:8d3630c5402f: lavf/oggparsevorbis: Fix change the case of metadata keys issue [18:03:00 CEST] <cone-583> ffmpeg 03Gyan Doshi 07master:6829c3cbe480: avformat/mpegenc - reject unsupported audio streams [22:29:19 CEST] <cone-133> ffmpeg 03Paul B Mahol 07master:c6c94303d447: avfilter/af_surround: avoid divisions with very small numbers [22:29:19 CEST] <cone-133> ffmpeg 03Paul B Mahol 07master:dbb35abf2897: avfilter/af_surround: add lfe_mode option [22:29:19 CEST] <cone-133> ffmpeg 03Paul B Mahol 07master:26fd40b568b8: avfilter/af_surround: make channel spread from stereo image user configurable [00:00:00 CEST] --- Tue Apr 23 2019

1 0

ffmpeg.log.20190422
by burek 23 Apr '19

23 Apr '19

[00:32:07 CEST] <kepstin> M6HZ: no, it would make it harder to use, because making a single complex filter chain which handles multiple streams is more work than doing separate simple "audio" and "video" chains that are applied to all of the relevant streams automatically. [00:36:39 CEST] <M6HZ> kepstin: Hum, fair enough. It's just that there are at least four ways to apply filters with ffmpeg, -vf, -af, -complex_filer, -lavfi, all of these having their limitations. Trying to unify them into something more intuitive could be a nice idea. [00:37:03 CEST] <kepstin> you only listed 3 ways, since -filter_complex and -lavfi are the same thing :) [00:37:19 CEST] <kepstin> (there's also options that load filter chain descriptions from files) [00:37:26 CEST] <M6HZ> Well, yes, I've read that earlier, but there are two different options. [00:37:27 CEST] <kepstin> and the lavfi input device [00:38:14 CEST] <M6HZ> "there's also options that load filter chain descriptions from files" What is that. Can you give me an example? [00:41:06 CEST] <kepstin> -filter_script is the same thing as -filter (which is the long form of the -af and -vf options), except it reads the filter chain description from a file rather than from the command line. [00:41:15 CEST] <kepstin> same for -filter_complex_script vs. -filter_complex [00:41:43 CEST] <M6HZ> ok [00:43:00 CEST] <furq> what limitations does filter_complex have that vf/af don't [00:48:15 CEST] <M6HZ> kepstin: And you see there is another source of confusion "-lavfi" and "lavfi input virtual device", I had always conflated both. [00:48:33 CEST] <M6HZ> furq: kepstin gave at least one of them earlier. [00:49:20 CEST] <M6HZ> kepstin: It is also the case for the term "codec" in the man page, being either related to an encoder name or to a bitstream format name. [00:49:24 CEST] <kepstin> hmm? I don't recall saying anything of the sort. [00:49:44 CEST] <M6HZ> "[18:32] <kepstin> M6HZ: no, it would make it harder to use, because making a single complex filter chain which handles multiple streams is more work than doing separate simple "audio" and "video" chains that are applied to all of the relevant streams automatically." [00:49:56 CEST] <kepstin> i said that -af/-vf are often easier to use, but that's not really a "limitation" [00:50:21 CEST] <M6HZ> Alright the word is maybe too strong. [07:40:52 CEST] <koz_> I'm using (successfully) ffmpeg with Intel's VA-API HEVC encoder. If I wanna do a lot of files (say, 12), does it make sense for me to use something like GNU Parallel to execute ffmpeg in parallel on each one, or will that not really help? [07:41:14 CEST] <koz_> I assume it won't, because I have only one DRI device, and I guess that all that parallel-hammering won't play very nicely with it. [07:52:58 CEST] <TikityTik> koz_: there's a -threads option and a -cpu option [07:53:17 CEST] <koz_> TikityTik: I understand that. I'm asking more about processing multiple files, not one file faster. [07:53:41 CEST] <koz_> Because I'm not sure that I can hardware encode 12 things in parallel, even though my CPU has 12 hyperthreads. [07:54:05 CEST] <koz_> I've done some tests, the results are inconclusive, and I'd like to hear from someone who can give me a definitive answer on whether that's a) even possible and b) worthwhile. [07:54:18 CEST] <koz_> I can give the exact ffmpeg invocations I'm feeding to GNU parallel if that'd help. [07:57:05 CEST] <furq> i don't think it'll make any difference [07:57:28 CEST] <koz_> furq: So what you're saying is 'don't bother using GNU parallel,just process the files in sequence'? [07:57:32 CEST] <furq> yeah [07:57:49 CEST] <koz_> furq: Could you explain your reasoning for that? Not disagreeing, but just curious why. [07:57:59 CEST] <koz_> Is it because the hardware can only encode one file at a time anyway? [08:00:23 CEST] <furq> each encode will slow down pretty much in line with however many streams you're running [08:00:31 CEST] <koz_> Ah, I see. [08:00:33 CEST] <furq> plus i assume you lose some more in overhead [08:00:40 CEST] <koz_> Yeah, I'm _definitely_ noticing that. [08:00:43 CEST] <furq> although you'd gain a tiny bit from running the decoder closer to capacity [08:01:09 CEST] <koz_> On just FPS alone, 1 proc = 60fps, 2 procs = 48fps, but 4 already kick me to like, 27. [08:02:26 CEST] <furq> that sounds better than i thought [08:02:56 CEST] <furq> unless you mean 27fps in total [08:06:57 CEST] <koz_> This is per ffmpeg process. [08:14:01 CEST] <koz_> furq: So I guess either I do it entirely serially, or at most 2 processes at a time? [09:29:23 CEST] <vishnuyr> Hi [09:29:57 CEST] <vishnuyr> I need help with encoding of DVCPro HD to XDCAM HD 422. [09:30:21 CEST] <vishnuyr> has anyone tried it? [09:37:25 CEST] <KaitoDaumoto> idk [09:37:25 CEST] <KaitoDaumoto> :( [10:47:21 CEST] <Hypnotoad90_> hey, is it possible to request a specific frame size AVCodecContext? [10:48:33 CEST] <Hypnotoad90_> or from the codec [10:48:37 CEST] <Hypnotoad90_> by frame size i mean a specific nb_samples [10:50:09 CEST] <Hypnotoad90_> alternatively, is it possible to have swr_convert write to your sample buffers with a sample offset, rather than having it write from the beginning of the buffer? [13:01:51 CEST] <Hypnotoad90> not sure how to phrase that question properly [13:46:04 CEST] <Hypnotoad90> or am i only supposed to be writing to new buffers each frame? [13:49:45 CEST] <JEEB> Hypnotoad90: you're talking about audio, so I know the libavfilter interfaces which behind the scenes utilize swresample has a function to request XYZ samples [13:49:53 CEST] <JEEB> not sure if swresample itself has that [13:50:08 CEST] <Hypnotoad90> hmm cool [13:50:48 CEST] <Hypnotoad90> if i just want to decode and resample an audio stream, libavfilter is a suitable thing to use? [13:51:26 CEST] <JEEB> yes, it basically wraps around swresample so it's less nitty gritty and more "feed me AVFrames and you get AVFrames back" [13:51:42 CEST] <JEEB> although I thought swresample also has an AVFrame based API, but I'm now having trouble noticing it :P [13:51:55 CEST] <Hypnotoad90> sounds great, and i can use it without it actually 'filtering' the audio? [13:52:14 CEST] <JEEB> well you define the filter chain [13:52:18 CEST] <JEEB> that can just be "aresample" [13:52:27 CEST] <JEEB> input -> aresample -> output [13:52:38 CEST] <Hypnotoad90> aresample is like swrseample? [13:52:47 CEST] <JEEB> it's the filter that wraps swresample, yes [13:52:58 CEST] <Hypnotoad90> awesome, i'll def look into that in a bit [13:53:06 CEST] <Hypnotoad90> is there some good example code showing its usage? [13:53:25 CEST] <JEEB> doc/examples has an example of using the "just give it a string" interface [13:53:44 CEST] <JEEB> which builds a filter chain from a string you pass libavfilter [13:54:20 CEST] <Hypnotoad90> oh btw forgot to mention, i'm forced to use a specific version of ffmpeg, i think it might be 2.4.1 or something, if that matters [13:54:28 CEST] <JEEB> yes it does [13:54:39 CEST] <JEEB> you're very unfortunate in various ways :P [13:54:44 CEST] <Hypnotoad90> yup :( [13:55:30 CEST] <JEEB> that's old enough for many things to have changed or gotten fixed since [13:55:53 CEST] <JEEB> ok, and I found the AVFrame based API in swresample for the record. it's indeed documented in swresample.h as I remembered :P [13:59:08 CEST] <Hypnotoad90> ah i see there's swr_convert_frame [13:59:48 CEST] <JEEB> and swr_config_frame for reconfiguration in case of changes [14:00:03 CEST] <Hypnotoad90> JEEB, actually can i explain my overall situation: [14:00:10 CEST] <Hypnotoad90> basically im dealing with an old code base [14:00:25 CEST] <Hypnotoad90> the old code base will call a function with a char* buffer [14:00:34 CEST] <Hypnotoad90> of a given size [14:00:46 CEST] <Hypnotoad90> basically this codebase has its own 'frame' concept distinct from ffmpeg's [14:00:53 CEST] <Hypnotoad90> so the char it sends is the buffer size for the whole frame [14:01:20 CEST] <Hypnotoad90> and i basically need to get audio out of ffmpeg and pack it into this data [14:02:23 CEST] <Hypnotoad90> now if i could get codec ffmpeg uses to have the same frame size as this function requests, that would be perfect, as it would all match up and i could just use swr_convert to write to the frame directly [14:02:38 CEST] <Hypnotoad90> write to the char* [14:02:51 CEST] <Hypnotoad90> i dunno if any of that made sense [14:03:04 CEST] <JEEB> given that FFmpeg itself has alignment requirements I'm not sure if you can just feed the buffer as-is to FFmpeg's APIs [14:03:18 CEST] <JEEB> but you can indeed with various APIs request XYZ samples [14:03:37 CEST] <JEEB> including that AVFrame API and probably the non-AVFrame one too :P [14:03:47 CEST] <Hypnotoad90> well this codebase has functions to prepare the sample format etc.. [14:04:12 CEST] <JEEB> so then all you need to do is transfer those samples from f.ex. the received AVFrame to your buffer [14:04:21 CEST] <JEEB> which should in general be one or multiple memcpys [14:04:24 CEST] <Hypnotoad90> but anyway, suppose i wanted to request an arbitrary number of samples from an arbitrary sample offset, would that be possible? [14:04:38 CEST] <JEEB> why do you need the offset? [14:04:44 CEST] <JEEB> you want to skip samples? [14:04:54 CEST] <Hypnotoad90> well so the codebase will request a frame as well [14:04:57 CEST] <JEEB> or do you mean "don't start at the beginning of the output buffer"? [14:05:01 CEST] <Hypnotoad90> so it might call the function and ask for audio at frame 30 [14:05:15 CEST] <Hypnotoad90> and say frame 30 is 5000 samples in [14:05:23 CEST] <Hypnotoad90> so i need to get data from the audio stream 5000 samples in [14:05:36 CEST] <Hypnotoad90> and lets say the frame size its requesting is 1000 [14:05:49 CEST] <Hypnotoad90> so i need to get 1000 samples of audio data beginning at sample 5000 from the stream, if that makes sense [14:06:30 CEST] <Hypnotoad90> i know i can use av_seek_frame or something like that to find the frame that contains the sample number [14:06:54 CEST] <JEEB> that's a container level seek to a position [14:07:02 CEST] <JEEB> time-wise position [14:07:05 CEST] <JEEB> not in samples [14:07:08 CEST] <Hypnotoad90> right [14:07:18 CEST] <Hypnotoad90> but i believe it was possible to calculate the right time position from samples [14:07:23 CEST] <JEEB> (you can also seek in bytes) [14:07:25 CEST] <Hypnotoad90> using AV_TIME_BASE or something [14:07:33 CEST] <Hypnotoad90> oh that might be easier [14:07:35 CEST] <JEEB> yes, if your definition is number of samples in the input format [14:07:54 CEST] <JEEB> as opposed to number of samples after whatever conversion you need to do with resampling [14:07:57 CEST] <JEEB> :P [14:08:23 CEST] <Hypnotoad90> anyway getting precisely the right frame is secondary atm, the main thing is being able to read an arbitrary number of samples [14:09:15 CEST] <JEEB> well at least the AVFrame API for swresample and the libavfilter stuff lets you basically request X amount of samples [14:09:30 CEST] <JEEB> as swr_convert_frame f.ex. notes [14:09:36 CEST] <Hypnotoad90> theres the decoder i need to deal with too [14:09:46 CEST] <JEEB> well yes, but decoder will just churn AVFrames for you [14:10:00 CEST] <JEEB> what you are interested in is that you get the output in XYZ sample chunks [14:10:09 CEST] <JEEB> which is what these APIs will give you [14:10:16 CEST] <Hypnotoad90> not sure what you mean by XYZ exactly [14:10:28 CEST] <JEEB> some arbitrary number of samples [14:10:43 CEST] <JEEB> see the sentence starting with "The output AVFrame can be NULL or have fewer allocated samples than required." [14:10:46 CEST] <JEEB> in swresample.h [14:11:01 CEST] <Hypnotoad90> right, but the decoder still forces a specific nb_samples size it seems [14:11:08 CEST] <JEEB> of course it does [14:11:16 CEST] <JEEB> it just outputs decoded AVFrames as-is [14:12:05 CEST] <JEEB> and read that explanation to the start of which I pointed please, that will probably clear some doubts on your side :P [14:12:33 CEST] <Hypnotoad90> which explanation sorry? [14:12:48 CEST] <JEEB> fourth line before the "and read that explanation..." [14:12:56 CEST] <JEEB> referencing to swresample.h [14:14:35 CEST] <Hypnotoad90> okay so [14:16:04 CEST] <Hypnotoad90> so i can see that could be used if my frame is smaller than the one the codec produces, but lets say my frame is the size of 3 frames the codec churns out, i guess i want swr to read to the same frame 3 times with those 3 input frames? [14:16:06 CEST] <Hypnotoad90> if possible? [14:16:09 CEST] <Hypnotoad90> write to* [14:17:31 CEST] <Hypnotoad90> or otherwise i need to just write 3 frames and pack them all into the char* somehow [14:17:54 CEST] <JEEB> I would think that at least some API will just outright tell you that the internal buffer doesn't yet have enough data [14:17:59 CEST] <JEEB> if you request a larger frame size [14:18:33 CEST] <JEEB> although I have not touched swresample and most of my experience has been writing relatively simple stuff with libavfilter in the audio department [14:19:38 CEST] <Hypnotoad90> okay so i think it sounds like i'll have multiple frames to deal with and i need to write them all into a single char* buffer, im not sure how id do that [14:19:54 CEST] <JEEB> ? I don't think that's what I said [14:20:09 CEST] <Hypnotoad90> i cant see what else i could do reading the doc [14:20:26 CEST] <JEEB> I would rather have f.ex. avfilter handle the buffering (or swresample if it indeed tells you that if you try to request more samples from it than it has in buffer) [14:21:17 CEST] <JEEB> you can relatively easily test what the thing tells you if you request more samples than you have fed it :P [14:21:45 CEST] <JEEB> and if that's not possible, you can always copy the buffer and offset the pointer to your output buffer :P [14:21:46 CEST] <Hypnotoad90> but i'll already know in advance if im requesting more samples than available, not entirely sure why its useful if swresample tells me or not [14:21:58 CEST] <JEEB> because tehn you can just keep feeding more data in? [14:22:09 CEST] <Hypnotoad90> right, as in additional frames? [14:22:11 CEST] <JEEB> it should then buffer internally until it has a full frame's amount of stuff [14:22:20 CEST] <Hypnotoad90> thats why im saying i'd end up with multiple frames [14:22:28 CEST] <JEEB> on the input side? [14:22:29 CEST] <JEEB> yes [14:22:32 CEST] <JEEB> on the output side? why [14:22:39 CEST] <Hypnotoad90> are you saying i can write multiple times to the same frame? [14:22:44 CEST] <JEEB> no? [14:23:06 CEST] <Hypnotoad90> so how am i supposed to use multiple input frames for one output frame? [14:23:08 CEST] <JEEB> I'm saying taht you request XYZ samples out of the resampler it should hopefully either tell you it has no such amount of samples yet, or it will be dumb and give what it has [14:23:47 CEST] <JEEB> Hypnotoad90: it references an internal buffer so you can easily test which the swresample lib does if you ask for more than it's got :P [14:23:55 CEST] <JEEB> since it does have internal buffering as per the doc [14:24:03 CEST] <Hypnotoad90> i get that, but i dont know what im supposed to do with that info [14:24:16 CEST] <JEEB> "I ate your input frame, feed more" [14:24:19 CEST] <JEEB> is what that means [14:24:29 CEST] <JEEB> *feed more if you want output [14:24:41 CEST] <Hypnotoad90> oh so you mean it wont write to the output frame right away until enough input has been added? [14:24:58 CEST] <JEEB> yes, that is what I'm hoping for since it has the same thing for asking for less samples than it has in buffer [14:25:03 CEST] <Hypnotoad90> like the "gotframe" thing from the decoder? [14:25:04 CEST] <JEEB> which is why I said "just try it out" [14:25:16 CEST] <JEEB> Hypnotoad90: oh boy, those old APIs [14:25:21 CEST] <JEEB> nowadays we have separate feed/receive [14:25:23 CEST] <JEEB> functions :P [14:25:31 CEST] <JEEB> which both report "cannot do that yet" [14:25:42 CEST] <JEEB> if the internal state isn't ready for your request yet [14:25:43 CEST] <JEEB> :P [14:25:54 CEST] <Hypnotoad90> swr_convet_frame, doc says: Returns [14:25:54 CEST] <Hypnotoad90> 0 on success, AVERROR on failure or nonmatching configuration. [14:26:25 CEST] <Hypnotoad90> doesnt look like it returns info about needing more data [14:26:26 CEST] <JEEB> yup, so it will probably return an AVERROR [14:26:29 CEST] <Hypnotoad90> oh? [14:26:35 CEST] <Hypnotoad90> hmm [14:26:36 CEST] <JEEB> or I would guess so [14:26:41 CEST] <JEEB> test it and it'll be quick [14:26:43 CEST] <JEEB> then we'll know :P [14:26:53 CEST] <Hypnotoad90> i'll test in a bit [14:26:55 CEST] <JEEB> just like it returns AVERROR_{OUTPUT,INPUT}_CHANGED [14:27:01 CEST] <JEEB> if the input or output config changed [14:27:02 CEST] <JEEB> :P [14:27:12 CEST] <JEEB> (and thus a reconfig is needed) [14:27:56 CEST] <Hypnotoad90> alternatively, in case this doesn't work out, before i was writing directly to the buffer with: av_samples_alloc((uint8_t**) &buffer, NULL, numchans, MAX_AUDIO_FRAME_SIZE, sample_fmt, 0); [14:28:39 CEST] <Hypnotoad90> is there someway i can offset the buffer pointer so it fills say the end half of the buffer [14:28:58 CEST] <Hypnotoad90> i couldnt quite figure it out how to do it properly, i was constantly getting bad access errors [14:29:03 CEST] <Hypnotoad90> if it's even possible [17:46:39 CEST] <Hypnotoad90> alright lets give this a shot [17:57:07 CEST] <Hypnotoad90> noooo [17:57:19 CEST] <Hypnotoad90> JEEB, looks like swr_convert_frame isn't available in my version of ffmpeg :( [18:36:43 CEST] <JEEB> Hypnotoad90: too bad [18:36:59 CEST] <JEEB> although I think you could request for XYZ samples in teh buffer based API too? [18:44:54 CEST] <Hypnotoad90> JEEB, right but how? [18:46:15 CEST] <Hypnotoad90> oh i pasted the wrong function before [18:47:11 CEST] <Hypnotoad90> i do the conversion atm with: swr_convert(swr, (uint8_t**)&buffer, frame->nb_samples, (const uint8_t**)frame->data, frame->nb_samples); [18:47:54 CEST] <Hypnotoad90> id like at least for now to be able to call that swr_convert function multiple times on the same buffer, i.e. writing several frames to one buffer, im assuming i can do that by offsetting the pointer to buffer somehow but not sure how [00:00:00 CEST] --- Tue Apr 23 2019

1 0

ffmpeg-devel.log.20190421
by burek 22 Apr '19

22 Apr '19

[06:38:53 CEST] <cone-736> ffmpeg 03Gyan Doshi 07master:6e0488cac431: doc/codecs: mention error returned for flag AV_CODEC_FLAG_DROPCHANGED [15:22:06 CEST] <cone-098> ffmpeg 03Jun Zhao 07master:b272d5b9b6e1: lavfi/frei0r: Fixes the compilation warnings [19:45:37 CEST] <cone-006> ffmpeg 03Paul B Mahol 07master:833ae5f4bfdc: avcodec/dvdec: add frame threads [21:14:31 CEST] <cone-006> ffmpeg 03Paul B Mahol 07master:dafcdeb25823: lavfi/avf_showwaves: fix extra gaps at end of waveform [00:00:00 CEST] --- Mon Apr 22 2019

1 0

ffmpeg.log.20190421
by burek 22 Apr '19

22 Apr '19

[00:10:02 CEST] <TikityTik> i'm surprised the subtitles filter still doesn't work off streams [00:13:43 CEST] <JEEB> subtitles are the one part of libavcodec that doesn't return AVFrames [00:13:48 CEST] <JEEB> and libavfilter only takes in AVFrames [00:14:13 CEST] <JEEB> so to get a similar result like what the sub2video thingamajig does in ffmpeg.c, you would have to re-implement what the subtitle filter does in tehre [00:14:23 CEST] <JEEB> as in, call libass or so on the subtitle lines [00:15:07 CEST] <JEEB> but yea, an old technical piece of debt is why a filter cannot take in subtitles :) [00:16:36 CEST] <JEEB> the ffmpeg.c sub2video thing already does generation of overlay images from picture based AVSubtitles, so one would just have to write handling of text AVSubtitles there that more or less duplicates what the subtitle filter does :) [00:26:06 CEST] <FreeBDSM> could someone help me? [00:27:21 CEST] <klaxa> from the paste it looks like your file is simply corrupted [00:28:55 CEST] <FreeBDSM> klaxa: it is not [00:29:09 CEST] <klaxa> can you play it back with something? [00:29:14 CEST] <FreeBDSM> no [00:29:32 CEST] <klaxa> then how do you know it is not corrupted? [00:29:38 CEST] <FreeBDSM> you may try it yourself, the file may be obtained via `youtube-dl -f 397 "https://www.youtube.com/watch?v=o6xQDChpUR0"` [00:29:56 CEST] <FreeBDSM> I doubt google would upload corrupted audio [00:30:43 CEST] <klaxa> maybe update your ffmpeg [00:30:46 CEST] <klaxa> works for me: https://gist.github.com/klaxa/6a59b49272d33b927af33d087a0bbdc7 [00:30:55 CEST] <JEEB> ah [00:30:56 CEST] <JEEB> av01 [00:30:57 CEST] <JEEB> yes [00:31:17 CEST] <JEEB> that needs FFmpeg to be built with an AV1 decoder (libaom or libdav1d) [00:31:37 CEST] <JEEB> libdav1d is faster by now so that is recommended [00:31:46 CEST] <FreeBDSM> aw, crap [00:31:52 CEST] <FreeBDSM> so it's not in ubuntu's repos yet [00:32:05 CEST] <JEEB> the format was stabilized in summer 2018 [00:32:06 CEST] <FreeBDSM> 3.4.4 version here [00:32:12 CEST] <JEEB> so very unlikely to be in any LTS currently [00:32:35 CEST] <FreeBDSM> got it, thanks [00:32:50 CEST] <JEEB> and then of course you need the mapping for AV1 in mp4, which is probably in a newer version as well, as that was finished after the format was finished I think [00:32:55 CEST] <JEEB> around sept, 2018? [00:35:15 CEST] <JEEB> so yea, you're dealing with rather fresh stuff :) [00:36:24 CEST] <FreeBDSM> well, basically, I don't have problems with ffmpeg, I do have problems with youtube-dl downloading non-supported stuff :( [00:36:31 CEST] <FreeBDSM> (by default) [00:37:51 CEST] <JEEB> well, youtube-dl doesn't know how old your other software is, and I'm not sure if it should be trying to :) [00:38:11 CEST] <JEEB> you can just disable AV1 in the youtube-dl config or get newer copies of FFmpeg (or build it yourself) [00:38:24 CEST] <JEEB> of course it will not fix AV1 decoding in other apps like vlc or mpv [00:38:43 CEST] <FreeBDSM> JEEB: looks like only AV1 audio is not supported [00:39:11 CEST] <furq> av1 audio is just opus [00:39:11 CEST] <JEEB> I think that was a bug with youtube-dl if it's old enough? AV1 has no audio [00:39:24 CEST] <JEEB> AV1 is a video format [00:39:24 CEST] <FreeBDSM> oh [00:39:42 CEST] <furq> also youtube-dl doesn't default to av1 here [00:39:44 CEST] <JEEB> I think old enough youtube-dl will guess that av1 in mp4 must be audio :P [00:41:01 CEST] <FreeBDSM> hold on, so https://gist.github.com/klaxa/6a59b49272d33b927af33d087a0bbdc7 is a video? [00:41:19 CEST] <furq> Stream #0:0(und): Video: av1 (Main) (av01 / 0x31307661), yuv420p(tv), 600x480, 0 kb/s, 25 fps, 25 tbr, 12800 tbn, 12800 tbc (default) [00:41:24 CEST] <FreeBDSM> riiight, fps [00:41:24 CEST] <klaxa> yes [00:41:29 CEST] <FreeBDSM> audio with fps, lol [00:41:31 CEST] <furq> well also "Video:" [00:41:36 CEST] <JEEB> yes, it is av1 video [00:42:10 CEST] <FreeBDSM> `youtube-dl -F "https://www.youtube.com/watch?v=o6xQDChpUR0" | pastebinit` > http://paste.ubuntu.com/p/KcvFXDvjG7/ [00:42:27 CEST] <JEEB> yup, too old youtube-dl [00:42:29 CEST] <JEEB> what I just said :P [00:42:37 CEST] <JEEB> I think I commented on youtube-dl's bug tracker about this [00:42:49 CEST] <JEEB> it was basically going "I don't know what this codec id is and it's mp4" [00:42:54 CEST] <JEEB> thus "This must be audio" [00:43:26 CEST] <FreeBDSM> but fps... [00:43:30 CEST] <furq> https://clbin.com/PbJlr [00:43:41 CEST] <JEEB> yes, they then fixed it [00:43:50 CEST] <JEEB> like furq's output shows [00:44:10 CEST] <FreeBDSM> I see [00:44:14 CEST] <FreeBDSM> thanks for the info [00:44:38 CEST] <FreeBDSM> I hope they downport this version to LTS Ubuntu [00:44:54 CEST] <furq> just uninstall it from apt and install it with pip [00:45:11 CEST] <JEEB> probably not unless you bug them about it :P and even then they might go "we do not new versions, only bug fixes" :P [00:45:24 CEST] <FreeBDSM> furq: no, this is a path to hell [00:45:26 CEST] <furq> i do that on debian testing because it's always outdated otherwise [00:45:26 CEST] <JEEB> also for reference the bug https://github.com/ytdl-org/youtube-dl/issues/17506#issuecomment-419710634 [00:45:33 CEST] <FreeBDSM> learned the hard way that pip breaks system [00:45:44 CEST] <JEEB> I actually like how fedora updates youtube-dl regularly [00:46:00 CEST] <JEEB> which makes sense since it's so much up to the systems it interfaces with [00:46:03 CEST] <JEEB> which can change [00:46:12 CEST] <furq> debian updates it pretty regularly but i've still needed newer versions a lot [00:46:16 CEST] <furq> also on freebsd [00:46:33 CEST] <JEEB> FreeBDSM: you can use a virtualenv if you want to keep it out of your main python root [00:46:37 CEST] <JEEB> so it's all in your home dir [00:46:39 CEST] <FreeBDSM> also, updating just youtube-dl wouldn't help [00:47:05 CEST] <JEEB> well right now it only picks av01 becuase it thinks it's the highest bit rate audio :P [00:47:07 CEST] <FreeBDSM> I still have old ffmpeg [00:47:09 CEST] <JEEB> as soon as you fix that [00:47:11 CEST] <furq> ^ [00:47:15 CEST] <FreeBDSM> oh, right [00:47:15 CEST] <furq> like i said it doesn't default to av1 here [00:47:25 CEST] <furq> on youtube-dl from this month [00:47:43 CEST] <JEEB> also the ffmpeg/ffprobe you showed actually had libaom built in [00:47:52 CEST] <JEEB> so whatever that was it could decode it [00:48:03 CEST] <furq> probably just no mapping for av1 in mp4 then [00:48:36 CEST] <JEEB> if that was true it wouldn't probe :P [00:48:45 CEST] <furq> it didn't [00:48:47 CEST] <furq> that was his problem [00:48:51 CEST] <JEEB> oh wait, that was klaxa's pastebin [00:48:54 CEST] <furq> yeah [00:49:01 CEST] <JEEB> ok, never mind then :) [00:49:05 CEST] <JEEB> anyways, night'o [00:50:36 CEST] <FreeBDSM> well, I've installed youtube-dl into a virtualenv [00:50:58 CEST] <FreeBDSM> but `which youtube-dl` shows that it still uses the one in /usr/bin/ [00:51:35 CEST] <FreeBDSM> ah, venvs don't seem to replace stuff in PATH [00:51:48 CEST] <FreeBDSM> wait, no, it did [00:52:28 CEST] <FreeBDSM> ah... zsh issue [00:52:44 CEST] <FreeBDSM> one needs to 'rehash' after activating a virtualenv [00:57:58 CEST] <FreeBDSM> well, that doesn't help if I used `-f 'bestvideo,bestaudio'` [01:00:38 CEST] <FreeBDSM> it throws ERROR: WARNING: unable to obtain file audio codec with ffprobe [01:00:46 CEST] <FreeBDSM> but there's no audio in that file [01:03:54 CEST] <FreeBDSM> nvm, looks like there's a difference between bestvideo,bestaudio vs bestvideo+bestaudio [01:05:57 CEST] <FreeBDSM> oh my, youtube-dl is a total crap [01:12:24 CEST] <FreeBDSM> turns out -x in user config breaks --merge-output-format 'mkv': it merges stuff but then deletes video + video+audio files, leaving only audio [01:28:40 CEST] <XLS202> Hey, I use ffmpeg as a recording and restreaming software for twitch. First i stream to an instance that records it and sends it to a second instance. And for example if I chance the scence in OBS or sometimes if a start a program the Stream crashes on twitch with the twitch error #2000. In the sametime the line "Sending bytes read report" is missing in the log from ffmpeg (https://pastebin.com/VdgVNUFT) has anyone an idea after what i [06:15:25 CEST] <pk08> hi [06:16:32 CEST] <pk08> i am trying to output TS stream in UDP multicast using complex_filter (used filters: show_volume, scale, overlay, nullsrc, setpts, etc) [06:17:06 CEST] <pk08> but when i try to pull ts from buffersink i only gets I frames for few seconds only [06:17:36 CEST] <pk08> after that i am getting `avcodec_receive_packet failed while encoding packet for output! Error: -541478725[End of file]` [06:17:57 CEST] <pk08> even if i push frames in filtersrc [06:18:15 CEST] <pk08> can anyone please tell me what can be the problem? [06:18:30 CEST] <pk08> why am I getting only I-Frames? [06:18:41 CEST] <pk08> and getting error after few sec? [06:19:05 CEST] <pk08> and thank you faLUSE for you help [06:19:37 CEST] <pk08> i have fixed PTS issue which we were discussed last time [10:06:13 CEST] <Filarius> for pet project I need settings for ffmpeg to make video as like it was re-encoded by youtube. Making some hobby research on video what target youtube, but I have slow internet to use youtube directly [10:06:55 CEST] <Filarius> even do not know how to google this right [14:43:01 CEST] <XLS202> Hey, I use ffmpeg as a recording and restreaming software for twitch. First i stream to an instance that records it and sends it to a second instance. And for example if I chance the scence in OBS or sometimes if a start a program the Stream crashes on twitch with the twitch error #2000. In the sametime the line "Sending bytes read report" is missing in the log from ffmpeg (https://pastebin.com/VdgVNUFT) has anyone an idea after what i [16:13:40 CEST] <M6HZ> Hi, I'm trying to understand how the links between filters are made one of the examples of the category "Filtergraph syntax" in the man page. [16:13:54 CEST] <M6HZ> This is the example: "nullsrc, split[L1], [L2]overlay, nullsink" [16:14:43 CEST] <M6HZ> My question is, are both of the outputs of "split" linked to "overlay" or just one of them? [16:42:00 CEST] <DHE> split produces 2 outputs. one is named L1, the other is being passed along to overlay which is also taking a second input named L2 [16:42:36 CEST] <DHE> with a comma, the two filters have a direct attachment. whereas with a semicolon; all inputs and outputs are explicit for the filters [16:59:25 CEST] <M6HZ> DHE: Thanks, alright. I would like to know, are both outputs of "split" connected to both inputs of "overlay"? [17:03:56 CEST] <DHE> no [17:04:23 CEST] <M6HZ> DHE: Ok, that's what I thought. [17:05:03 CEST] <DHE> I'm assuming the example you pasted is incomplete since there's no L2 output but it's used as an input [17:09:25 CEST] <M6HZ> DHE: So, if I understand correctly, the "split"'s output L1 goes the unlabelled input of "overlay", and the unlabelled "split"'s output goes to "nullsink"? [17:12:06 CEST] <DHE> well I was going to link you to https://ffmpeg.org/ffmpeg-filters.html#Filtergraph-description but I suspect you're already there now based on your example [17:12:36 CEST] <kepstin> no. the unlabelled output of split goes to the unlabelled input of overlay. There's no connection between split and nullsink [17:13:14 CEST] <M6HZ> DHE: Yes, I had written where It came from ;) [17:13:17 CEST] <kepstin> where L1 and L2 come from and go... isn't shown in the part of the filter chain you've pasted [17:14:07 CEST] <DHE> here's the same filtergraph in no-commas syntax: nullsrc[u1]; [u1]split[L1][u2]; [L2][u2]overlay[u3]; [u3]nullsink [17:14:33 CEST] <DHE> where u1, u2, and u3 are unlabeled connections formed by using the commas, [17:15:13 CEST] <M6HZ> kepstin: You're saying that "There's no connection between split and nullsink", but it is written that :If an output pad is not labelled, it is linked by default to the first unlabelled input pad of the next filter in the filterchain.". [17:15:38 CEST] <kepstin> M6HZ: nullsink isn't the next filter in the filterchain after split [17:15:48 CEST] <kepstin> M6HZ: overlay is the next filter [17:16:27 CEST] <M6HZ> sure. but if there is no available input in the next filter, isn't it going to search an input with the next filter? [17:16:32 CEST] <kepstin> M6HZ: no [17:16:41 CEST] <M6HZ> Alright. [17:16:46 CEST] <DHE> overlay takes 2 inputs. thats its job. [17:16:54 CEST] <kepstin> the `,` operator connects the filter before it to the filter after it. that's it. [17:16:58 CEST] <DHE> one is implied by the comma, one is explicitly specified with a label. [17:17:02 CEST] <DHE> (not in that order though) [17:18:16 CEST] <kepstin> if you need to do something other than connect all the outputs of one filter to all the inputs of the next filter, then you have to use labels to specify the connections to use. [17:20:15 CEST] <M6HZ> kepstin: but then, in this example, where is going the output L1? [17:20:36 CEST] <kepstin> M6HZ: your example is incomplete and doesn't say what L1 is connected to [17:21:00 CEST] <M6HZ> kepstin: True, but it is from the man page. [17:21:07 CEST] <M6HZ> I was confused [17:21:18 CEST] <chinknot> do I need any special option to trim flac files? the generated output loses duration metadata entirely if I use "-acodec=flac" and keeps the original input duration if I use "-acodec=copy" [17:22:02 CEST] <kepstin> M6HZ: ah. that example simply doesn't say. that example is not a complete filter chain, it's just demonstrating how a particular connection works. [17:22:55 CEST] <kepstin> M6HZ: just assume that L1 goes somewhere else, and L2 comes from somewhere else. [17:23:06 CEST] <M6HZ> kepstin: alright thank you :) [17:24:13 CEST] <kepstin> note that you are allowed to have labelled outputs in a filter chain that don't connect to anything. You can then put a `-map [L1]` or so in your ffmpeg command line, and that filter chain output will be stored as a stream in the output file. [17:26:06 CEST] <M6HZ> kepstin: ok, good to know. [17:28:31 CEST] <furq> chinknot: loses duration metadata? [17:28:41 CEST] <chinknot> yeah [17:29:09 CEST] <chinknot> if I inspect it with mediainfo there's no duration, if I try to use ffprobe same result [17:29:23 CEST] <furq> that sounds broken [17:29:31 CEST] <M6HZ> kepstin: I had understood things differently by reading : "A filtergraph is considered valid if all the filter input and output pads of all the filterchains are connected." [17:29:41 CEST] <furq> pastebin the command line and output [17:29:53 CEST] <chinknot> indeed. I tried inspecting the flac file with a flac frontend but there's no error in the file [17:30:01 CEST] <kepstin> M6HZ: it can be connected to something outside of the filterchain [17:30:23 CEST] <M6HZ> ok [17:32:02 CEST] <chinknot> for instance, the command was something as simple as ffmpeg -i input.flac -ss 10 -to 20 -acodec flac output.flac [17:33:29 CEST] <furq> yeah that works fine here [17:33:57 CEST] <chinknot> I downloaded a flac sample from internet and the same command works ok trimming and generating a new file with correct duration [17:37:36 CEST] <chinknot> something I noticed when comparing different flac files is the stream size. on the working flac the stream size is 100%, on the other flac is 98% [17:37:42 CEST] <chinknot> does that mean anything? [17:39:54 CEST] <TikityTik> chinknot: flac files do compression [17:40:15 CEST] <TikityTik> chinknot: they only compress if there's no audio [17:40:36 CEST] <TikityTik> unlike wav that wastes space to represent the no audio part [17:41:21 CEST] <TikityTik> which could possibly explain the different file size [17:51:36 CEST] <chinknot> I just tried re encoding it with a modern libflac but same issue. it isn't exported correctly [18:04:46 CEST] <chinknot> it's the -ss and -to part failing the conversion. it happens if I re encode in another format entirely as well. just tried libvorbis [20:11:50 CEST] <chinknot> I'm the guy who was having troubles with flac files before. I tried downloading previous ffmpeg builds and trying something more stable (not the nightly branch, the distributor builds) and I found out ffmpeg 3.4.2 is the latest version that works for me [20:12:37 CEST] <chinknot> no errors and the output files correctly displays a duration [22:15:18 CEST] <Kingslayer> howdy [22:30:24 CEST] <pomaranc> Kingslayer: oathbreaker! [22:31:09 CEST] <Kingslayer> hey is it possible to set the size in number of samples an audio frame will be that's returned by avcodec_decode_audio4 or similar? [22:43:56 CEST] <Kingslayer> also anyone know why i might get "bad access" error when calling av_samples_get_buffer_size? [22:44:15 CEST] <Kingslayer> sorry nvm it wasnt that [22:59:55 CEST] <M6HZ> Does someone have a clue about the meaning of this sentence present in the man page "The -lavfi option is equivalent to -filter_complex." ? [23:00:13 CEST] <JEEB> they are synonyms [23:00:19 CEST] <JEEB> as in, the point internally to the same thing [23:00:26 CEST] <JEEB> *they [23:00:47 CEST] <M6HZ> Alright [23:02:11 CEST] <M6HZ> I was also wondering, is there a good reason to have both -vf and -filter_complex since the second one is able to do the work of the first? [23:06:29 CEST] <furq> -vf and -af are useful shorthands [23:07:12 CEST] <JEEB> also vf and af build separate filter chains (which are less powerful) [23:08:07 CEST] <M6HZ> What do you mean by "separate filter chains" ? [23:08:55 CEST] <JEEB> you will have two separate filter chains, as it says on the tin [23:09:00 CEST] <JEEB> -filter_complex is a single filter chain [23:09:37 CEST] <JEEB> in many cases it doesn't matter but I've had reconfiguration of audio happen to affect video due to the whole filter chain getting re-configured [23:10:13 CEST] <M6HZ> Oh you mean when both -vf and -af are used simultaneously? [23:10:44 CEST] <JEEB> each creates a single filter chain, yes. so if you are using both you are getting two separate filter chains: one for video and one for audio [23:10:52 CEST] <M6HZ> Ok [23:11:49 CEST] <M6HZ> Why not to replace both by a new command -fc (because it's short) ? [23:27:06 CEST] <M6HZ> Wouldn't it make the whole program easier to use? [23:32:33 CEST] <Kingslayer> brb [00:00:00 CEST] --- Mon Apr 22 2019

1 0

ffmpeg-devel.log.20190420
by burek 21 Apr '19

21 Apr '19

[00:14:25 CEST] <cone-932> ffmpeg 03Carl Eugen Hoyos 07master:48860df34df6: configure: Add .exe suffix to toolchain calls. [00:17:57 CEST] <cehoyos> Any comments about -Wno-gnu-variable-sized-type-not-at-end? http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241729.html [00:19:07 CEST] <cehoyos> What are win32 arm/arm64 devices? Compilation works fine but I wonder what to do with the binaries... [00:20:16 CEST] <nevcairiel> technically you can run Windows 10 IoT on a variety of ARM devices, including a Pi3 [00:20:40 CEST] <cone-932> ffmpeg 03Carl Eugen Hoyos 07master:93209902ede3: lavfi/fspp: Simplify a macro. [00:20:47 CEST] <nevcairiel> not sure if any are officially sold yet [00:21:11 CEST] <cehoyos> I see. [00:21:20 CEST] <cehoyos> Did you look again into the aac vs2019 issue? [00:21:42 CEST] <nevcairiel> not yet, probably not before next week [00:22:45 CEST] <cehoyos> In-tree compilation works now without changes, I will look into mslink next week to see if I can fix out-of-tree builds. [00:22:56 CEST] <cehoyos> mklink [00:25:55 CEST] <cehoyos> Matebook E 2019 is apparently a real-life arm Windows device [00:27:00 CEST] <nevcairiel> wbs has been doing a lot of work with windows on arm if there is any problems [00:28:47 CEST] <cehoyos> I had to realize that gas-preprocessor is needed, then it worked fine [00:29:12 CEST] <cehoyos> I know now how to test future arm64 patches for compilation issues. [01:28:17 CEST] <cone-932> ffmpeg 03Jun Zhao 07master:d93e44332f1b: lavf: bump version/add APIchanges entry when cleanup applehttp [05:21:06 CEST] <hanetzer> question. should I be using https://github.com/FFmpeg/FFmpeg.git or git://source.ffmpeg.org/ffmpeg.git ? [05:34:32 CEST] <kierank> the latter [05:34:35 CEST] <kierank> the former is a mirror [05:34:38 CEST] <kierank> it may not be up to date [05:34:47 CEST] <kierank> likely it will be but i have seen it be delayed before [06:46:19 CEST] <hanetzer> kierank: gotcha. looking into the possibility of porting ffmpeg to meson as 'exercise' and it may be useful to you guys as well :) [07:16:38 CEST] <cone-553> ffmpeg 03Gyan Doshi 07master:3153a6502a28: avcodec: add AV_CODEC_FLAG_DROPCHANGED to flags [07:19:09 CEST] <cone-553> ffmpeg 03Gyan Doshi 07master:3a07aec82741: doc/APIchanges: update for 3153a6502a [08:21:15 CEST] <nevcairiel> hanetzer: someone already did that once [08:21:27 CEST] <hanetzer> orly. [08:21:37 CEST] <nevcairiel> i forgot where its at [11:06:18 CEST] <durandal_1707> ubitux: i did .csp for lut3d/lut1d on ML [11:16:20 CEST] <ubitux> looks fine at first glance, i'll send an official answer soon [11:16:53 CEST] <ubitux> can you give me some context on where it comes from and why the sudden interest in it? [11:20:15 CEST] <durandal_1707> ubitux: i work for secret agency and they work with bunch of cineSpace LUTs, on serios side I just found it exists [11:20:53 CEST] <ubitux> ok :) [11:24:25 CEST] <J_Darnley> hanetzer: look in the ML archives if you want to see when it was last discussed [11:24:46 CEST] <J_Darnley> June and July 2018 http://ffmpeg.org/pipermail/ffmpeg-devel/2018-June/thread.html http://ffmpeg.org/pipermail/ffmpeg-devel/2018-July/thread.html [11:28:53 CEST] <BtbN> don't use git:// urls, ever. They are unsafe. [11:29:30 CEST] <BtbN> I also don't think a switch of build-systems would be possible to get accepted. [11:29:44 CEST] <BtbN> Unless you somehow manage to make it 100% regression free, which seems impossible. [11:29:45 CEST] <hanetzer> BtbN: yeah. I was more pointing at the domain/etc; I believe some portion of the documentation mentions the git:// url [11:33:52 CEST] <hanetzer> BtbN: elaborate the regression free bit? [11:34:13 CEST] <BtbN> Someone on the ML will find an edge case the new build system breaks, and veto it on that basis. [11:34:48 CEST] <hanetzer> gotcha. so until its 1:1 feature parity that's a no until it is [11:35:04 CEST] <BtbN> Even then I'd suspect people will give it a hard time [11:35:19 CEST] <BtbN> Cause, the bunch of script we have right now do work surprisingly fine [11:36:32 CEST] <J_Darnley> I too think it is unlikely to get accepted wih anything less then full feature parity [11:36:41 CEST] <J_Darnley> *than [11:36:53 CEST] <BtbN> I also still don't feel like meson is mature enough [11:37:13 CEST] <BtbN> Every time I use it I end up in a situation where I have to manually install a sometimes project-specific version of it [11:37:54 CEST] <hanetzer> expected. I did the mesonbuild port for mate-desktop and there is currently some grumbling about ninja uninstall 'erroring' because it tries to remove icon files twice, but honestly irl make install and the equivalent to the root filesystem is rather uncommon [11:39:25 CEST] <J_Darnley> I think meson looks like one of the configure & make relacements with promise [11:40:03 CEST] <BtbN> But why does ffmpeg configure need replaced? [11:40:27 CEST] <hanetzer> BtbN: do me a favor; got a clone? assume you do. time ./configure [11:41:04 CEST] <J_Darnley> I don't really think it does, especially not since some genius fixed the massive slow-down that crept in. [11:42:16 CEST] <J_Darnley> But as I'd like to say to people who say "why don't you write it in X?": please go ahead and do that [11:42:46 CEST] <hanetzer> J_Darnley: found the stuff you were talking about; https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg << gonna give this a go [11:44:12 CEST] <nevcairiel> configure time complaints are such an overrated problem, especially since the big slowdown from recent years has been fixed [11:44:26 CEST] <nevcairiel> so it takes 30 second to configure, big deal [11:44:51 CEST] <JEEB> yea, I stopped building on windows when it was 10min, but since that has dropped dramatically [11:46:07 CEST] <J_Darnley> Ah look at that repo. Good to see gaps being papered over with python scripts. [11:46:37 CEST] <nevcairiel> that sort of defeats the purpose doesnt it [11:46:37 CEST] <hanetzer> nevcairiel: that's fair. but then again, the fact that 'some genius' had to fix that issue and not just 'some dude' kinda sucks :) [11:47:32 CEST] <hanetzer> J_Darnley: directory of python scripts? curious, I am :) [11:47:53 CEST] <hanetzer> theoretically said gaps could be included into meson proper if needed. [11:47:54 CEST] <J_Darnley> The root directory! [11:48:04 CEST] <nevcairiel> there is at least 7 python scripts that fix up a lacking build system [11:48:39 CEST] <BtbN> And then we end up with the same situation other projects have. A build system that only works with a very specific and/or super bleeding edge meson version [11:48:40 CEST] <J_Darnley> And "some dude" won't know how to profile a shell script, let alone python. [11:50:16 CEST] <hanetzer> J_Darnley: ah, that's a place I personally wouldn't put my extra glue so was looking in ./tools :P [11:50:29 CEST] <nevcairiel> if anything it should've gone into ffbuild [11:50:42 CEST] <J_Darnley> Sure, a new build system will have some gaps but why would you chose python, aka the worst language [11:51:01 CEST] <hanetzer> that too, but ffbuild is the ./configure guts right? thought they may want to avoid mixing it up :) [11:51:06 CEST] <durandal_1707> ubitux: the cineSpace luts supports XxYxZ luts (instead of just YxYxY) is such thing easily added to lut3d? [11:51:11 CEST] <nevcairiel> they choose meson, meson is in python, so one might assume python is already installed [11:51:23 CEST] <nevcairiel> ... unless you're on windows and use meson.exe which has python baked in =p [11:51:39 CEST] <J_Darnley> Yeah but I don't have to see any python code with meson (unlike scons) [11:51:56 CEST] <BtbN> Python is probably the best choice for build systems right now [11:52:00 CEST] <hanetzer> nevcairiel: yep. a simple port I'm working on (icon theme, only one source file for the theme engine but its mostly install_data and install_subdir ca [11:52:03 CEST] <hanetzer> lls) [11:52:08 CEST] <BtbN> it's relatively fast and powerful, super portable and widely available [11:52:13 CEST] <nevcairiel> i rather like how i can build eg. dav1d with meson without needing msys at all [11:52:39 CEST] <nevcairiel> or python for that matter [11:52:51 CEST] <hanetzer> the current Makefile solutions I've seen in icon themes are terrible lol, so I'm writing that bit for index.theme generation in python because I know meson users will have python :) [11:52:55 CEST] <nevcairiel> but its a far simpler project then ffmpeg [11:53:17 CEST] <J_Darnley> I'd probably like meson when its "finished" [11:53:26 CEST] <hanetzer> J_Darnley: or at least a 1.x release eh? [11:53:50 CEST] <BtbN> It would also be entirely possible to just clone what configure does, but writing it in Python instead. Would be a serious performance boost, and if done right, provide the exact same features. [11:54:16 CEST] <nevcairiel> but outside of possibly performance enhancements, also doesnt offer anything else [11:54:29 CEST] <nevcairiel> one point of using something like meson is to claim that in the long run its simpler to maintain [11:54:46 CEST] <nevcairiel> because you dont have to work on the plumbing all the time [11:54:49 CEST] <hanetzer> aight guys, later. $dayjob [11:54:55 CEST] <hanetzer> J_Darnley: thanks for the links [11:55:00 CEST] <J_Darnley> no problem [11:55:15 CEST] <BtbN> My experience with build systems is that you have to work on plumbing a lot, because the build systems break thing all the time. [11:55:18 CEST] <J_Darnley> or you're welcome [11:55:40 CEST] <BtbN> That primarily a problem of all the fancy new "better" build systems though [11:55:50 CEST] <BtbN> autotools and cmake always are rock stable in that regard [11:59:13 CEST] <nevcairiel> writing autotools files is even more arcane magic then writing custom shell scripts tho [11:59:43 CEST] <BtbN> Yep, autotools is horrible to work with. [11:59:43 CEST] <J_Darnley> Except for when a dev puts checks in the wrong order letting it detect signed c99 stdint but not unsigned stdint [11:59:53 CEST] <BtbN> But stuff written 20 years ago pretty much still works unchanged [12:07:22 CEST] <cone-429> ffmpeg 03Paul B Mahol 07master:fee7c15d8754: avfilter/af_surround: allow user to change overlap and win_func [12:30:31 CEST] <hanetzer> I don't much mind autotools were it not for the m4sh syntax and long ./bootstrap-alike and ./configure times :) [13:38:46 CEST] <cone-429> ffmpeg 03Gyan Doshi 07master:bf4245e9521b: doc/filters: list values for af_surround window function [14:15:14 CEST] <cone-429> ffmpeg 03Paul B Mahol 07master:b9d25b1a6ef0: avfilter/vf_lut3d: add cineSpace 1D lut parsing [14:15:15 CEST] <cone-429> ffmpeg 03Paul B Mahol 07master:e20ad3bd59cc: avfilter/vf_lut3d: add cineSpace 3D lut support [14:23:36 CEST] <cone-429> ffmpeg 03Paul B Mahol 07master:782ae68a117f: avfilter: add lagfun filter [17:46:19 CEST] <cone-100> ffmpeg 03Jarek Samic 07master:1c46ab4815f8: lavfi: add colorkey_opencl filter [23:56:43 CEST] <cone-146> ffmpeg 03Lou Logan 07master:d8245cff167f: doc/mailing-list-faq: auto unsubscribe due to DMARC [00:00:00 CEST] --- Sun Apr 21 2019

1 0

ffmpeg.log.20190420
by burek 21 Apr '19

21 Apr '19

[02:18:30 CEST] <ncouloute> Since I cant get the concat muxer to output a cfr for mp4. I'm looking into using the concat filter, but is there any way to find out where the files start and end after they have been concatenated? [02:23:12 CEST] <TheAMM> ffprobe the files before doing the encode, add the durations [02:23:43 CEST] <TheAMM> file 1 starts at 0, file 2 starts at file_1_duration [02:24:10 CEST] <TheAMM> probably + one frame [02:27:56 CEST] <ncouloute> problem is I'm changing the framerate of the files as well. [02:30:08 CEST] <JEEB> I'd probably just stick the video/audio streams together separately and then apply the stream copy frame rate patch so -r XX would work [03:28:32 CEST] <ncouloute> Not sure I understand what all that means.I think you mean combine the video stream together as one file and combine the audio together as one file and then custom build ffmpeg with a patch located somewhere.. Currently using zeranoe build. Where would I find this patch? Cant be too hard [03:55:31 CEST] <friendofafriend> ls [03:55:37 CEST] <friendofafriend> Excuse me. [04:10:33 CEST] <obscure> can ffmpeg trim bits out of a 250 mb webm video [07:43:21 CEST] <__raven__> processing images to video clips sometimes leads to an endless loop caused by "invalid data found..." due to negative duration. how to exit that? [23:43:32 CEST] <FreeBDSM> hello [23:44:57 CEST] <FreeBDSM> it looks like I'm having problems with ffmpeg being unable to play a file: `ffprobe -show_streams 'file:that_file.mp4'` results into `Unsupported codec with id 32797 for input stream 0` [23:46:50 CEST] <TikityTik> can you reference subtitle streams? -filter_complex "[0:v]subtitles=[0:s]" [23:51:53 CEST] <furq> TikityTik: -i foo.mkv -vf subtitles=foo.mkv [23:52:08 CEST] <TikityTik> furq: sometimes the filenames are too long [23:52:20 CEST] <TikityTik> which is why i was wondering if i could do it through those stream identifies [23:52:51 CEST] <furq> yeah you can't use labels like that [23:56:09 CEST] <FreeBDSM> tech is crap :( [23:56:16 CEST] <FreeBDSM> nothing just works [23:57:04 CEST] <TikityTik> lol [23:58:35 CEST] <TikityTik> ah got it working [23:58:48 CEST] <TikityTik> err nevermind [00:00:00 CEST] --- Sun Apr 21 2019

1 0