Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2019

1 participants
62 discussions

ffmpeg-devel.log.20190320
by burek 21 Mar '19

21 Mar '19

[02:48:45 CET] <KombuchaKip> Why does the ffmpeg write it's own ./configure manually instead of using the autotools? Isn't it more work to reinvent its functionality? [06:50:39 CET] <cone-487> ffmpeg 03Jun Li 07master:0739d5cd5c92: avformat/smoothstreamingenc:add bitrate calculate [09:19:33 CET] <cone-487> ffmpeg 03Lauri Kasanen 07master:ac3062f1a4e7: swscale/ppc: Clean up some mixed decl warnings [09:19:34 CET] <cone-487> ffmpeg 03Lauri Kasanen 07master:6b5ea90eace8: swscale/ppc: Add av_unused to template vars only used in one includer [11:43:45 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:4b32f8b3ebfa: lavd: Remove libndi_newtek [11:49:39 CET] <thardin> woop-woop [11:51:26 CET] <durandal11707> without REVIEW and VOTES, how ABSURD !! [11:51:49 CET] <thardin> I hadn't noticed the NDI thing until a friend of mine mentioned it over beer a few weeks ago [11:52:41 CET] <BtbN> This is unacceptable imo. There were plenty of people voicing against it, and maybe a handful of people for it. [11:53:07 CET] <BtbN> Yet it just got pushed. [11:53:42 CET] <BtbN> It's a major API break, but if it can harm a big bad commercial company, that's just ok. [11:54:17 CET] <thardin> they've been threatening RE:ers, no? [11:55:11 CET] <BtbN> Supposedly, but to get access to the library, you need to accept a license that prohibity you from doing that. So at least legally, they were correct there. [11:56:48 CET] <BtbN> This feels way to much like someones personal crusade rather than proper technical reasons. [11:57:17 CET] <thardin> legally yes, ethically no [11:58:49 CET] <thardin> but perhaps a discussion needs to be had whether ffmpeg should serve the interest of free software or the interest of capital [11:59:20 CET] <BtbN> From what I've been told, Newtek was actively working on a "peaceful solution", that did not include shutting the project down at all, but the developers weren't cooperating. Then again, this is a very one sided view, as I have still not heard any reports from the affected developers. [12:00:01 CET] <thardin> it's always possible to re-add it [12:00:28 CET] <thardin> newtek can also maintain their own fork [12:00:34 CET] <atomnuker> how is it an api break? its no different from when we've removed decoders from lavc [12:01:06 CET] <BtbN> Those went through the regular deprecation period and everything. [12:01:17 CET] <BtbN> This is just gone without a major bump. [12:01:52 CET] <BtbN> I know at least two bigger Events who are affected by this, since they are using NDI setups with ffmpeg in the background. [12:02:13 CET] <BtbN> They are now forced to use old ffmpeg code or maintain the patch themselves. [12:02:29 CET] <BtbN> And realistically, they will probably just never update ffmpeg again. [12:02:53 CET] <durandal11707> NDI did not wanted to send some money to us? [12:03:38 CET] <BtbN> I think NDI does not want to talk to FFmpeg as a project at all anymore, since everyone that did got personally attacked. [12:24:29 CET] <atomnuker> BtbN: no? libfaac didn't go through that [12:24:57 CET] <BtbN> Pretty sure it printed a big warning for quite a while, didn't it? [12:26:19 CET] <JEEB> yea the unfortunate point is that we weren't specific in our nonfree rules to begin with, that started the whole mess :P [12:28:04 CET] <JEEB> if we were just "no, nonfree is not for closed source software-only things" back then we might have gone much smoother :P although even that as a rule is a slippery slope since we would prefer OSS-"standard" driver interfaces compared to minor vendor XYZ's own custom interfaces [12:28:16 CET] <atomnuker> BtbN: nope, it didn't [12:28:32 CET] <BtbN> weird. That also seems wrong then. [12:28:55 CET] <atomnuker> I also removed libschroedinger, and that didn't have any warning either [12:29:04 CET] <atomnuker> and the libnut wrapper [12:29:10 CET] <BtbN> Well, following that rule over half of the nvidia stuff would have to go as well. [12:29:19 CET] <BtbN> At the very least everything that uses libnpp [12:30:33 CET] <BtbN> The rest is probably fine now that it does not use the actual CUDA SDK anymore [12:32:45 CET] <JEEB> but yea, whatever the rule set is we should be more clear with it. [12:33:10 CET] <JEEB> so that stuff just doesn't get pushed after X amount of time just because nobody has time or doesn't care about such and such thing [12:33:20 CET] <BtbN> Seems like the ruleset is if someone hates the company behind the non-free part enough. [12:33:36 CET] <BtbN> People did care about ndi, and voiced their disagreement. It just got ignored. [12:34:51 CET] <JEEB> NDI as a feature is useful and even I agree with that; I would have preferred not to link against a non-open source implementation since it's a 100% protocol thing, and since I think enable-nonfree was not a thing to enable closed source stuff but rather just open source stuff with incompatible licenses, such as faac or fdk-aac [12:35:14 CET] <JEEB> thus I see it as a collective failure including myself that it was not blocked during the review phase [12:36:58 CET] <JEEB> and that goes back to the part of rules + rules on nonfree not being clear enough :P [12:37:29 CET] <JEEB> because if someone could have just pointed towards some basic check-list that would have been a simple way to not have the patch set be pinged [12:37:36 CET] <JEEB> until that issue got resolved [12:38:33 CET] <BradleyS> seems that in addition to having policy regarding such additions, there should be policy regarding their removal as well [12:38:56 CET] <JEEB> sure [12:39:10 CET] <JEEB> but the addition part should IMHO be done first [12:39:37 CET] <JEEB> since that minimizes the possibility of people just starting "vendettas" if it passed the check list [12:41:06 CET] <BradleyS> removal could be quite concise and in parallel [12:41:21 CET] <JEEB> I don't disagree [12:41:30 CET] <BradleyS> if any party violates the license, x happens [12:41:46 CET] <BradleyS> list remedy and also consequences for non-remedy and repeat violations [12:42:14 CET] <BradleyS> perhaps describe a process for communication and remedy [12:42:38 CET] <BradleyS> license violations themselves are defined by the license, so that's pretty cut and dry in theory [12:44:07 CET] <JEEB> yes [12:47:32 CET] <kierank> I removed a ton of aac stuff in the past that was nonfree [12:48:33 CET] <kierank> 11:03:38 <"BtbN> I think NDI does not want to talk to FFmpeg as a project at all anymore, since everyone that did got personally attacked. [12:48:34 CET] <kierank> hahahahaha [12:48:43 CET] <kierank> as opposed to the guy who was sent legal threads [12:48:44 CET] <kierank> threats [12:48:51 CET] <kierank> you have this nonsensical belief that ndi are nice peopel [12:49:11 CET] <BradleyS> how are they even in a position to threaten legally [12:49:19 CET] <BradleyS> sounds like a ridiculous move on their part [12:49:38 CET] <kierank> because they want to protect their proprietary protocol [12:49:58 CET] <JEEB> yes, they want everyone to base it on *their* SDK [12:50:22 CET] <BradleyS> i get the why on their end, but certainly they must realize they can't make ffmpeg include their software [12:50:25 CET] <JEEB> anyways, that's beside the point - the point is that we let it slip through in the first place I think since so many people seem to have been against it on some level [12:50:42 CET] <JEEB> and thus as soon as there was a "reason" to remove it, that was utilized [14:38:14 CET] <BBB> BtbN: this is probably frustrating for some users, yes. I think in terms of a project, we've got to come to terms with the fact that there's multiple reasons some of us contribute [14:38:36 CET] <BBB> BtbN: some of us do it for work/company; some of us do it as a hobby [14:38:54 CET] <BBB> BtbN: there's going to be a huge difference in how you look at sth. like NDI depending on why you do it [14:39:53 CET] <BBB> I still see my ffmpeg contributions primarily as a hobby, and so I have *huge* (like trump: **YUGE!!**) issues with closed-source code linked to by ffmpeg [14:40:25 CET] <BBB> because I essentially see a company like NDI taking my contributions and saying "oh look let's plug it into our cash cow and use ronald's code to make EVEN MORE MONEY$$$" [14:40:44 CET] <BBB> (I know it's not exactly like that, but that's how some of us feel about it anyway) [14:43:23 CET] <BBB> if your contributions are work/company in nature, this is probably hugely annoying, "why can't these kids grow up" - and again, I get it, I have a job etc. [14:44:21 CET] <JEEB> well I don't think the project having a guide line / check list for contributions being a sign of immaturity [14:44:30 CET] <durandal11707> lol people who removed ndi are not doing it because its their hobby [14:44:47 CET] <BBB> they're doing it b/c they're pissed off [14:44:47 CET] <JEEB> that's just what we lack right now, and that's why we get these things where something like NDI can get into the code to begin with [14:44:51 CET] <JEEB> :P [14:45:02 CET] <BBB> I agree NDI should never have been let in [14:45:04 CET] <JEEB> (clearly software only, closed source) [14:45:08 CET] <BBB> I proposed a vote on closed-source contributions [14:45:14 CET] <BBB> but nobody seconded it [14:45:20 CET] <BBB> so... :-/ [14:45:31 CET] <kierank> BBB: I think hardware closed source is a tricky one [14:45:37 CET] <thardin> working with ffmpeg professionally doesn't need to imply one wants proprietary stuff in it [14:45:44 CET] <thardin> that's an opensourceism [14:45:53 CET] <kierank> ^ that [14:46:53 CET] <BBB> probably true, yes [14:47:59 CET] <JEEB> yea, hardware is less simple. what is enough of open source (vaapi could also be thought of as a dload wrapper, but we don't have an issue with it atm), and what is considered as "OS provided interfaces" esp. with something like linux [14:48:11 CET] <JEEB> closed source vs fully open source are clear cut [14:51:19 CET] <thardin> it amounts to kicking the can to kernel devs. which may be fine [14:51:52 CET] <thardin> in theory libre hardware and/or drivers could be made that use the same APIs [14:52:26 CET] <thardin> and libre silicon is slowly becoming a thing [14:53:58 CET] <BBB> yeah [14:54:08 CET] <BBB> I really don't like the hardware or system exceptions [14:54:17 CET] <BBB> the way I understand it is that it means there is an open alternative [14:54:24 CET] <BBB> even if the one a particular user may be using could be closed [14:54:32 CET] <BBB> if there's only closed options, it's literally just a loophole [14:54:39 CET] <BBB> and then I don't buy the exception anymore [14:55:07 CET] <JEEB> for proprietary OS the GPL exception is funny enough more clear-cut since DXVA2 or D3D11VA or VideoToolbox (mac) are all OS interfaces xD [14:55:21 CET] <thardin> even rms accepts propreitary software if it's in devices he doesn't expect to need to hack. like microwaves [14:55:22 CET] <BBB> "the user may have a non-GPL-compatible libc, but there's also GPL-compatible libc with the same interface so it's ok" [14:55:39 CET] <BBB> I don't see how that works for NDI [14:55:46 CET] <BBB> is there an open version of NDI? [14:55:47 CET] <JEEB> yea, NDI clearly was outside [14:56:01 CET] <JEEB> it's not hardware, and it's not an OS provided interface [14:56:02 CET] <BBB> and as for nvidia... [14:56:05 CET] <BBB> I don't know [14:56:17 CET] <kierank> BBB: no [14:56:18 CET] <kierank> closed source [14:56:28 CET] <JEEB> (also I noted "not hardware" but that doesn't mean justby being hardware it's OK) [14:56:35 CET] <BBB> right [14:56:39 CET] <JEEB> just that it makes it even more clear [14:57:04 CET] <JEEB> since we have OSS wrappers for hardware drivers, such as VAAPI or nvdec already [14:57:42 CET] <JEEB> and with proprietary systems we just have OS provided interfaces, which are OK even according to GPL (which is more strict than LGPL) [14:57:55 CET] <JEEB> (the ones I juts mnetioned for hwdec) [15:03:12 CET] <thardin> shouldn't enabling libnvidia-encode1 make the build non-free? [15:03:28 CET] <thardin> uhm, assuming nvenc is using it.. [15:04:41 CET] <thardin> ah cuda_nvcc is [15:04:41 CET] <nevcairiel> we dont link against that, there is a OSS loader in between [15:05:08 CET] <j-b> nvidia thingie is for drivers [15:07:20 CET] <nevcairiel> (and we've come to the conclusion a few years ago that the graphics driver can safely be considered a system library) [15:07:59 CET] <j-b> I agree [15:08:02 CET] <j-b> NDI is not a driver [15:08:17 CET] <j-b> NDI is not part of the system libraries [15:08:18 CET] <nevcairiel> yeah that thing definitely doesnt fall under any exceptions [15:08:21 CET] <j-b> NDI is not open source [15:08:25 CET] <j-b> NDI should go. [15:08:26 CET] <nevcairiel> but thats why the build with it was non-free [15:08:38 CET] <j-b> non-free is a mistake [15:08:54 CET] <nevcairiel> although it really was the only thing in the non-free list that wasnt either hardware or some incompatible oss license [15:09:06 CET] <j-b> see the homebrew rules [15:09:57 CET] <j-b> I would argue that libfdk-aac must go too [15:10:26 CET] <j-b> but at least, this one is open-source, but not *GPL-compatible [15:10:28 CET] <durandal11707> remove everything [15:10:33 CET] <j-b> same for openssl [15:10:44 CET] <nevcairiel> speaking of openssl, didnt they want to relicense that [15:10:53 CET] <BtbN> it's an ongoing endeavour [15:10:56 CET] <j-b> yes, they want to [15:11:20 CET] <j-b> tbh, they are doing it now. [15:11:34 CET] <nevcairiel> i had to use gnutls because of that, and compiling that is awlays so annoying :-D [15:12:17 CET] <j-b> Technically, the openssl usage is not-nonfree on OSX [15:12:19 CET] <JEEB> j-b: the non-free in FFmpeg used to be just "incompatible OSS licenses" [15:12:30 CET] <j-b> JEEB: that is always how I understood it [15:12:44 CET] <j-b> JEEB: I remember suggesting calling it non-gplcompat [15:12:46 CET] <JEEB> that should just be documented so that people wouldn't try to pull a fast one with closed source stuff [15:12:51 CET] <JEEB> :P [15:12:58 CET] <JEEB> (like some have been able to) [15:13:12 CET] <durandal11707> so does that means no MF wrapper can go in? [15:13:17 CET] <JEEB> MF is OS [15:13:21 CET] <JEEB> just like DirectShow [15:13:23 CET] <JEEB> or DXVA2 [15:13:26 CET] <JEEB> or D3D11VA [15:13:33 CET] <JEEB> so technically if we want it, it's a system lib [15:13:33 CET] <durandal11707> we have apple shit too [15:13:34 CET] <JEEB> :P [15:13:52 CET] <JEEB> the question is then purely opinionated, do we want it and how does the code look? [15:13:56 CET] <j-b> durandal11707: which ones? [15:14:02 CET] <durandal11707> just remove all support for non-open source code at once [15:14:14 CET] <JEEB> like the windows C runtime? [15:14:16 CET] <j-b> durandal11707: I would argue that this is exactly what was done [15:14:44 CET] <j-b> JEEB: courmisch's opinion, for example, is that compiling with MSVC is not-GPL compatible. [15:14:54 CET] <j-b> JEEB: and same for every crt that is not installed by default [15:15:00 CET] <durandal11707> j-b: audiotoolbox [15:15:07 CET] <j-b> durandal11707: part of the OS [15:15:21 CET] <durandal11707> OS that is not OSS [15:15:35 CET] <nevcairiel> so if I compile with msvc on windows 10, which comes with the correct crt already, its fine then? =p [15:15:56 CET] <durandal11707> i said, no tolerance will be made [15:16:22 CET] <j-b> nevcairiel: if you compile with gcc with the crt from win10, yes. [15:16:50 CET] <j-b> but with msvc, it is always game-over, since the compiler adds code [15:17:05 CET] <j-b> This is a minority opinion, though. But it has some valid points [15:17:47 CET] <nevcairiel> the compiler is freely available without even a sign-up wall or anything though, so at the very least it should be able to make LGPL binaries [15:22:14 CET] <j-b> but it is not part of the OS,technically. [15:32:00 CET] <j-b> nevcairiel: as for me, I don't care, because the fact that MSVC is not part of Windows is mostly a size issue. [15:41:57 CET] <philipl> Ok, so we got to compilers. The historical GPL context is that the first GPL software was compiled with proprietary compilers and that was considered fine - there were no free compilers. [15:42:11 CET] <philipl> MSVC or nvcc are proprietary compilers. So what? [15:43:29 CET] <j-b> the historical context was that the compiler was part of the OS. [15:43:50 CET] <j-b> but that is why I don't care about MSVC, but I'm just saying that some people do care. [15:44:27 CET] <philipl> I care because I think the argument for putting nvcc under non-free is the same one that either says msvc is compatible or it is not. [15:45:28 CET] <philipl> I've talked to various people outside our community here who deal with linux and open source development and licencing seriously and they think it's a crazy question to even ask. [15:46:05 CET] <j-b> philipl: can I help by saying I will bring this up with Bradley Kuhn next time I see him? [15:46:26 CET] <philipl> j-b: please do. He's never replied to me when I've emailed him about it - not that I really expected a reply. [15:46:39 CET] <j-b> philipl: yes, but I am more annoying than you :) [15:46:44 CET] <philipl> heh. [15:46:46 CET] <j-b> and I know Karen quite a bit :) [15:47:11 CET] <j-b> but I have to say that I need to understand more about nvcc [15:47:52 CET] <philipl> It does various things, but the thing it does for us, that matters, is that it compiles the cuda source to an intermediate assembly format. which is then compiled to gpu binary code at runtime by the driver. [15:48:08 CET] <philipl> So it doesn't even have the fuzzy issue of injecting code fragments. [16:07:18 CET] <vel0city> durandal11707: We can talk here if you want, maybe it'll be quicker (if so, read my newest reply first) [16:28:25 CET] <BtbN> The big difference is that you can easily and freely get _a_ C compiler to build ffmpeg with. [16:28:44 CET] <BtbN> But you can not get any other nvcc without going through nvidias registration process and agreeing to two EULAs. [16:30:15 CET] <durandal11707> vel0city: ther are multi-pages tiffs [16:30:46 CET] <philipl> While that's true, I don't see how it actually intersects with the GPL any differently. Many other and previous proprietary compilers had similar burdens. [16:30:52 CET] <philipl> Pre OpenJDK java worked that way [16:34:52 CET] <vel0city> durandal11707: Right, related to NewSubfileType Bit1 that I mentioned. But those are not handled atm, are they? [16:35:20 CET] <durandal11707> no, support is incomplete [16:36:11 CET] <vel0city> Good to know, but is it related to my patch? [16:38:11 CET] <durandal11707> no, but you could implement it [16:53:27 CET] <jdarnley_obs> you found one [16:53:29 CET] <vel0city> durandal11707: I could in the future, but what about this one? [16:53:39 CET] <jdarnley_obs> wrong channel [16:54:07 CET] <vel0city> don't want to merge it so incomplete? [16:55:36 CET] <durandal11707> vel0city: write more lines [16:58:07 CET] <vel0city> durandal11707: Anything more specific to suggest? :p [16:58:34 CET] <vel0city> I suppose working on improving something for TIFF fiels would be more contained, probably better for a qualification task. [16:59:06 CET] <durandal11707> TIFF is so huge, just anything [16:59:11 CET] <vel0city> yeah [16:59:16 CET] <vel0city> got any multi-page tiffs? [16:59:31 CET] <durandal11707> don't think so [17:01:03 CET] <vel0city> oh nvm, apparently photoshop can save its layers as tiff pages [17:01:56 CET] <vel0city> any pointers on how to demux to multiple images? maybe some existing formats I can look at? [17:07:07 CET] <durandal11707> vel0city: you are not doing demuxers [17:07:26 CET] <durandal11707> just skip/ignore it [17:10:26 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:6fcf7adc019b: lavc/tiff: Support decoding 16bit cmyk. [17:11:55 CET] <faLUCE> Hello. is the lavf matroska muxer strictly coupled with AVCodecContext? It seems that codecpars for the avstream require "extradata" value that can be obtained only with a full AVCodecContext initialization. Then, it could be a bug of the matroska muxer [17:14:42 CET] <vel0city> right, decoder not demuxer [17:15:16 CET] <vel0city> what do you mean by "ignore it"? isn't the goal to decode all pages in a tiff? [17:15:32 CET] <vel0city> you mean like, have the user select the page they want? [17:17:05 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:ba0a56e0b004: lavc/qtrle: Avoid an unaligned 64-bit write. [17:19:36 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:a171cafb3559: lavf/sdp: Change pointer to configuration from char* to uint8_t*. [17:20:22 CET] <durandal11707> vel0city: select [17:20:44 CET] <vel0city> cool [17:23:42 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:801d78f0d898: lavc/truehd_core: Initialize the last bytes of the output buffer. [17:39:47 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:5247c4328bb9: lavf/spdifenc: Do not overwrite buffer when muxing TrueHD. [17:43:40 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:7be245498b1d: lavf/http: Print metadata updates with -loglevel verbose. [17:50:57 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:82fd7866a3d7: lavc/tiff: Allow decoding of cmyka (five components). [18:02:38 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:4602456c4f18: lavc/arbc: Use AV_WB24() where applicable. [18:40:31 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:9461e4bc694b: lavf: Constify AVOutputFormat pointer. [18:54:40 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:3aa6208db966: lavf: Constify AVInputFormat pointer. [18:57:27 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:cc49341084f0: lavf/avformat: Add a warning that ff_const59 is not part of the public api. [19:05:36 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:6a3520bf9845: lavf: Constify AVProbeData* in av_probe_input_format(). [20:40:43 CET] <j-b> I'm sooo surprised that people like this NDI thing [20:42:01 CET] <nevcairiel> honestly i dont even know wtf it does [20:42:07 CET] <nevcairiel> i tried to read about it and it just confused me [20:42:11 CET] <thardin> seems it's a protocol for piping video? [20:42:22 CET] <j-b> yes [20:43:04 CET] <j-b> it's a protocol to replace SDI and make it over IP [20:43:10 CET] <j-b> so, UDP+FEC [20:45:59 CET] <thardin> FEC feels like something that belongs in the link layer [20:46:47 CET] <nevcairiel> so .. TCP? =p [20:47:06 CET] <thardin> or ARQ or SCTP or [20:48:52 CET] <BtbN> There isn't really any alternative to NDI, even though it would be easy to implement it with existing open tools, nobody put the parts together. [20:48:59 CET] <j-b> RIST and SRT [20:49:17 CET] <BtbN> It's pretty much just mDNS and an mjpeg stream via some low-latency protocol [20:49:31 CET] <j-b> with a custom codec [20:49:56 CET] <BtbN> mJpeg works just fine for the same purpose, on high quality settings. [20:50:42 CET] <BtbN> But it's really the ease of use that makes NDI popular. On the setups we use we just plug every device into the 10G network, and on the Main-PC all the various sources just show up and can be added to the scene. [20:51:37 CET] <BtbN> That includes a lot of hardware transcoders and the like, where implementing an open solution wouldn't even be possible. [20:51:49 CET] <j-b> yes, that, I agree, it is simple to use. [20:52:23 CET] <j-b> but open solutions are always possible [20:52:30 CET] <BtbN> The alternative to that setup would be a dozen capture cards and an equal amount of SDI wires [20:53:28 CET] <BtbN> Or a capture PC on every single output, that converts to mjpeg and does mDns stuff to announce the stream. And then there is not really network protocol that reliably allows joining the stream. [20:53:52 CET] <j-b> SRT or RIST should allow to do that [20:54:33 CET] <BtbN> Both don't look exactly popular or widely adopted [20:56:33 CET] <BtbN> Their codec is also interesting in that it offers a nice tradeof between speed, quality and no generation loss. [20:57:04 CET] <j-b> No denying that. [20:57:15 CET] <j-b> but that does not warrant an inclusion in FFmpeg [20:58:22 CET] <BtbN> The result of the removal pretty much means that nobody will ever touch the ffmpeg version running on various devices in that setup. [20:59:38 CET] <BtbN> With it's popularity and wide adoption, ffmpeg supporting it is very much warranted. [21:02:46 CET] <nevcairiel> if they wanted that to be possible, they could just open-source it, or at least stop being generally evil towards open-source (ie. sueing any attempts at independent implementations) [21:03:03 CET] <j-b> and violating FFmpeg, x264 licenses [21:03:32 CET] <BtbN> They fixed that, but nobody seems to care. [21:03:46 CET] <j-b> Fixing a violation does not repair the violation [21:03:56 CET] <BtbN> They want to make money by selling commericial licenses. [21:04:11 CET] <j-b> "I stopped stealing from the shop 6 months ago, why do you arrest me?" [21:04:23 CET] <j-b> what kind of argument is that? [21:04:37 CET] <BtbN> What kind of comparison is that? No damage was done. [21:04:37 CET] <j-b> They are greedy, you mean? [21:05:47 CET] <j-b> The cannot get both the "we want to be in FFmpeg, so we can be everywhere" and "we want to sell our library" [21:05:52 CET] <j-b> It is one, or the other [21:06:23 CET] <j-b> Not cool? maybe. but this is what the (L)GPL are about [21:06:56 CET] <BtbN> Which is why it clearly makes the build non-free. [21:07:43 CET] <BtbN> This whole debate really does not make FFmpeg look good. A bunch of people I talked to found the ticket on trac and immediately decided that "the ffmpeg people" are at fault here. [21:07:47 CET] <j-b> Non-free was for open-source projects with non-GPL compatible licenses [21:08:26 CET] <j-b> Not for merging non-open-source software [21:08:45 CET] <BtbN> Nobody merged the whole library. Just a wrapper for it. [21:08:52 CET] <BtbN> Which itself was under a free license. [21:08:54 CET] <j-b> Because then, you merge RVHD, Adobe, Microsoft dll loader, QT [21:09:11 CET] <j-b> and then, why not merge EVE, technicolor, and Fraunhoffer decoders [21:09:32 CET] <BtbN> If they are useful and available, yes, why not? [21:09:52 CET] <j-b> I disagree. [21:10:10 CET] <j-b> but that's a point where we're going to agree to disagree [21:10:27 CET] <BtbN> The really biggest problem of this whole thing is the insame amount of hate some people put into it. [21:10:50 CET] <durandal11707> ndi stuff is not freely available at all? [21:10:50 CET] <j-b> And seeing the current debate on funding open source, that is the hot topic, I think the opposite: [21:10:53 CET] <BtbN> This could have been solved without personally attacking anyone, and with proper discussion. [21:11:09 CET] <BtbN> NDI stuff is available free of cost, but you have to agree to a license. And you have to pay if you use it comercially. [21:11:11 CET] <j-b> removal of this NDI makes the FFmpeg project look good. [21:11:24 CET] <BtbN> Nobody I talked to agreed to that. [21:11:33 CET] <BtbN> Sounded more like it makes FFmpeg look like GPL extremists. [21:11:57 CET] <j-b> You talk to people who profit from FFmpeg a lot, and don't contribute [21:12:17 CET] <j-b> like a lot of the broadcaster comapanies [21:12:25 CET] <BtbN> If there is nobody profiting from a project, the project in itself is pointless. [21:12:39 CET] <j-b> come on [21:12:53 CET] <j-b> FFmpeg is used everywhere without needed to violate our own license [21:12:54 CET] <BtbN> Can't we just relicense everything to 3-Clause BSD? [21:13:26 CET] <j-b> too late [21:14:01 CET] <nevcairiel> You can profit from it and still help the overall community [21:14:04 CET] <j-b> and that goes directly against the current debate of funding open source [21:14:36 CET] <j-b> FFmpeg is used everywhere, and the removal of a niche library is not gonna impact that [21:14:41 CET] <BtbN> The projects I'm working with are all non-profit Charity events btw. [21:14:52 CET] <cone-487> ffmpeg 03Michael Niedermayer 07master:21b90435d602: tools/target_dec_fate.list: add issues 4000 to 6000 [21:14:53 CET] <cone-487> ffmpeg 03Michael Niedermayer 07master:8f63fa4c2ec1: avcodec/scpr: Perform frame copy later [21:14:54 CET] <cone-487> ffmpeg 03Michael Niedermayer 07master:9d20901b92b5: avcodec/arbc: Check nb_segments before allocating and copying frame [21:15:09 CET] <kurosu> j-b: equating Technicolor and Fraunhoffer to EVE was mean :p [21:15:18 CET] <j-b> kurosu: I know :) [21:15:28 CET] <j-b> I was trolling BBB, who's my friend. [21:16:01 CET] <kurosu> I suppose that if one highlight doesn't work, this one has to :D [21:16:17 CET] <j-b> :D [21:16:49 CET] <j-b> BBB is the one advocating against closed-source, while he could be one profitting from it. [21:25:02 CET] <durandal11707> lets add VFW to ffmpeg [21:25:53 CET] <j-b> exactly [21:28:36 CET] <jamrial> kierank: someone came to the conclusion you're the main "agitator" in this whole NDI thing :p [21:29:28 CET] <j-b> lol [21:29:41 CET] <j-b> this guy is a mpv developer, no? [21:29:49 CET] <j-b> I answered very politely [21:31:19 CET] <gnafu> j-b: I would like to see EVE included in ffmpeg. [21:31:28 CET] <gnafu> In the form of BBB open sourcing EVE ;-D. [21:32:47 CET] <gnafu> I know I don't have a stake in it, at least as far as not having contributed any code, but I definitely feel that a GPL violation does harm and is only truly made up for when the offending closed source is made open. [21:33:28 CET] <gnafu> Maybe not "as bad" as stealing a loaf of bread or robbing a bank, but still "bad". It's a violation, and doing nothing in response sends a message that violations are okay. [21:34:21 CET] <gnafu> Otherwise, why use GPL? I would love it if a) we lived in a world where everyone wanted to contribute out in the open, and b) everything could then just be BSD-licensed with no worries. [21:35:02 CET] <gnafu> But I think the GPL has a place specifically because people don't always play nice. You need a legal recourse sometimes. [21:35:56 CET] <thardin> robbing a bank isn't bad [21:36:58 CET] <thardin> and yes, gpl is necessary because without it you just get enclosure [21:48:42 CET] <BBB> huh :) [21:48:54 CET] <BBB> I specifically said that if realvideo was accepted, I'd send an eve patch also [21:49:04 CET] <BBB> (since then apparenntly closed source is not an issue) [21:49:14 CET] <BBB> I'm obviously joking, closed source has no place in ffmpeg [21:50:30 CET] <JEEB> j-b: i don't remember his name on any recent prs but being polite is always good even if the other side isn't as much [21:50:55 CET] <uau> j-b: who were you asking about being an mpv developer? [21:51:18 CET] <gnafu> BBB: :-) [21:52:49 CET] <JEEB> we aren't lgpl, but i think there are people who think that closed source can not be utilized in lgpl software becsude it makes publishing the source for the lgpl component impossible [21:53:37 CET] <JEEB> I will have to see if I reply on ml but I feel like the discussion has to be steered towards msking a setof guide lines [21:54:13 CET] <JEEB> (i don't like the word rules) [21:56:30 CET] <BBB> I agree [21:56:52 CET] <BBB> in the end, the broader issue is not legal, but community preference [21:57:28 CET] <BBB> and that should be addressed by the whole community, not just its loudest voices [21:57:37 CET] <JEEB> *we aren't gpl [21:57:55 CET] <JEEB> man beer makes typing in a train harder [21:58:04 CET] <JEEB> BBB: aye [21:58:25 CET] <BBB> so.... vote? :D [21:58:30 CET] <j-b> gnafu: lol :) [21:59:30 CET] <j-b> I think people here are underestimating the inpact of FFmpeg out there. [21:59:51 CET] <JEEB> i think some sort of poll from the people who pushed during the ladt 12-24 months makes sense or something to gauge people's feelings [21:59:53 CET] <j-b> It is now becoming the standard for cloud encoding [22:00:22 CET] <j-b> If you don't put a limit, it will get patches for everything under the sun [22:00:30 CET] <JEEB> yes [22:00:48 CET] <JEEB> real video was just the beginning [22:01:38 CET] <kierank> jamrial: rofl I am accused of being influential [22:01:55 CET] <j-b> gnafu: I attack regularly on VLC for GPL violations [22:02:35 CET] <j-b> In the more philosophical sense, the respect for our licenses is the social contract of our communities [22:02:50 CET] <gnafu> j-b: Totally. [22:02:57 CET] <JEEB> kierank: why don't I have beers with you so we can decide on the future of things :D [22:03:07 CET] <j-b> this is the only thing that gets us together [22:03:10 CET] <JEEB> ye influential one [22:03:13 CET] <j-b> (and Brexit hate) [22:03:21 CET] <gnafu> I also agree that sometimes the perception of ffmpeg undersells just how foundational it is to so much of the modern multimedia web. [22:03:47 CET] <JEEB> we sre at the same point the butt of people's jokes [22:04:02 CET] <JEEB> but at the same point a lot of stuff wpuldn't exist [22:04:07 CET] <JEEB> without FFmoeg [22:04:18 CET] <gnafu> I'd rather that than be thought of as more important only to be easily replaced. [22:04:23 CET] <JEEB> (sorry for the touchscreen English) [22:04:37 CET] <j-b> kierank: can I attack you too? for fun, though! :D [22:04:38 CET] <gnafu> JEEB: I, for one, am so offended. [22:04:41 CET] <gnafu> ;-D [22:05:00 CET] <JEEB> ;D [22:06:00 CET] <gnafu> #triggered [22:06:17 CET] <j-b> Offended! Did you remember this page on unencyclopedia [22:06:33 CET] <gnafu> Sounds familiar. [22:06:49 CET] <j-b> It was the most horrible page of the internet [22:06:54 CET] <j-b> even I could not bear it :) [22:10:04 CET] <jdarnley_obs> :( Have I been missing out on a shit show? [22:26:29 CET] <thardin> jdarnley_obs: just look at the libndi threads in the archives [22:28:16 CET] <thardin> btw, what ff-related conferences are there? I know of vdd, but i recall there's a few more. and ibc of course [22:29:48 CET] <jdarnley_obs> fosdem often has a large ffmpeg contingent [22:30:29 CET] <thardin> fosdem is on my list of things to visit next time. and ccc [22:30:41 CET] <jdarnley_obs> there's been an open media room the past few years [22:44:04 CET] <j-b> thardin: fosdem and vdd. I advise demuxed, foms, nab, ibc too. [22:44:08 CET] <j-b> less open source, though [22:44:45 CET] <durandal11707> NTTW is only about FFmpeg [22:45:05 CET] <JEEB> no that is the mediainfo conf [22:45:06 CET] <JEEB> :V [22:45:14 CET] <JEEB> but I still will try to join [22:46:08 CET] <j-b> good point [22:49:35 CET] <thardin> j-b: ack, north america [22:49:48 CET] <thardin> that's going to be a pain to get to [22:51:06 CET] <thardin> durandal11707: nttw? [22:51:14 CET] <JEEB> no time to waste [22:51:18 CET] <JEEB> I think octobero r so? [22:51:44 CET] <durandal11707> *wait [22:52:26 CET] <thardin> october last year [22:56:24 CET] <thardin> we've been tossing around the idea starting a foss conference here in umeå lately. especially since there's fossnorth in gothenburg which isn't particularly north at all :] [22:57:52 CET] <BBB> thardin: I hear NAB is full of ffmpeg also [22:58:11 CET] Action: BBB runs [22:58:46 CET] <cone-487> ffmpeg 03Aman Gupta 07master:9e40c97a844d: doc/ffmpeg: muxdelay and muxpreload are output options [22:59:14 CET] <thardin> BBB: getting across the pond is a huge hassle [23:01:43 CET] <BBB> some of us attend vdd, and some attend linuxtag also [23:02:03 CET] <Gramner> umeå? I'd attend [23:03:12 CET] <atomnuker> every day on this channel is an ffmpeg conference if you feel like it, lol [23:03:56 CET] <thardin> yes [23:05:16 CET] <thardin> Gramner: noted [23:06:16 CET] <atomnuker> plus, there are some things you can only do here [23:06:43 CET] <atomnuker> like referencing a meme without your organs exploding out of your body to escape the shame [23:08:05 CET] <thardin> memes can only be referenced afk with the utmost irony with friends, and even then it's risky [23:09:47 CET] <thardin> and let's not forget the classic ircing with someone who sits at the same dinner table [23:11:40 CET] <j-b> atomnuker: can't we do that on other cool channels? [23:13:45 CET] <atomnuker> depends on how srs bsns other channels are [23:38:02 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:3ac474892c38: lavf/allformats: Remove an accidentally committed line. [23:54:33 CET] <cone-487> ffmpeg 03James Almer 07master:70c8c8a818f3: avcodec/hevcdec: decode at most one slice reporting being the first in the picture [00:00:00 CET] --- Thu Mar 21 2019

1 0

ffmpeg.log.20190320
by burek 21 Mar '19

21 Mar '19

[00:01:00 CET] <ElePHPhant> All of those steps are a mystery to me. :/ [00:02:00 CET] <faLUCE> what I don't understand is that if I exec "ffmpeg -f v4l2 -i /dev/v4l/by-id/usb-046d_0825_9C957210-video-index0 -c:v libx264 -f mpegts test.ts" the bytes at the beginning of the produced file are "ffmpeg service". Is this a sorft of "ffmpeg header" or a part of another header? [00:02:32 CET] <JEEB> latter [00:03:10 CET] <JEEB> by default in the MPEG-TS metadata the program is called Service01 and the provider name is FFmpeg [00:03:23 CET] <faLUCE> JEEB: so, it's a part of the MPEGTS header... [00:03:45 CET] <faLUCE> JEEB: is this a "global" header? [00:04:00 CET] <faLUCE> WIth global I mean a header that has to be put on each frame [00:04:16 CET] <JEEB> I thought that meant the other way? [00:04:28 CET] <JEEB> global headers were only written once and non-global were in-band? [00:04:45 CET] <JEEB> anyways, it should be written every now and then again [00:04:53 CET] <JEEB> as it's part of PMT I think [00:04:55 CET] <JEEB> or PAT [00:05:03 CET] <faLUCE> JEEB: me too. But IIRC avcodeccontext->flags |= GLOBAL_HEADER means a header on each frame [00:06:11 CET] <JEEB> libavcodec/avcodec.h- * Place global headers in extradata instead of every keyframe. [00:06:14 CET] <JEEB> libavcodec/avcodec.h- */ [00:06:16 CET] <JEEB> libavcodec/avcodec.h:#define AV_CODEC_FLAG_GLOBAL_HEADER (1 << 22) [00:06:22 CET] <JEEB> so yes, it means what I thought it did [00:06:39 CET] <JEEB> and then AVFormat has its own field for that since you should set that field according to your muxer [00:06:58 CET] <JEEB> see the transcoding example [00:07:05 CET] <JEEB> it checks if the oformat has that flag [00:07:12 CET] <JEEB> and if yes, sets that flag for the enc_ctx [00:07:22 CET] <faLUCE> JEEB: but it says "on every keyframe", not "once" [00:07:41 CET] <JEEB> Extradata instead of every keyframe [00:07:49 CET] <JEEB> extradata is avctx global field [00:08:10 CET] <faLUCE> I see but, in each case, it's not a header that must be written once at beginning of the stream [00:08:10 CET] <JEEB> what it means is that you should only get a single set of extradata, and that is in the avctx's extradata :P [00:08:36 CET] <faLUCE> for example, mkv needs a header that must be put at the beginning of the stream [00:08:58 CET] <JEEB> does matroska have AVFMT_GLOBALHEADER ? [00:09:15 CET] <faLUCE> JEEB: it needs it, yes [00:09:18 CET] <faLUCE> it's necessary [00:09:26 CET] <JEEB> yes, and you already got me fucking confused [00:09:36 CET] <faLUCE> but other than that, it also needs a header at the beginning of the stream [00:09:40 CET] <JEEB> I already said it meant "put into a global header" (extradata) [00:09:46 CET] <JEEB> what do you mean with that? [00:10:01 CET] <JEEB> matroska definitely does not need in-band headers [00:10:05 CET] <JEEB> of H.264 or so [00:10:13 CET] <JEEB> you can put them there if you really really want [00:10:17 CET] <JEEB> but they are not required to be there [00:10:44 CET] <faLUCE> I mean: maybe (but I could be wrong) mkv needs a header at the beginning of the stream, which is different than the header on the keyframes [00:11:18 CET] <JEEB> if you're talking about the matroska container then yes, it has different stream-specific structures yes. but it has nothing to do with decoding init data in extradata and the stream-global header [00:11:58 CET] <JEEB> global header = extradata should be put into encoder's extradata field and it will get written into a place in the container (usually a structure per stream) [00:12:01 CET] <faLUCE> ok, that is what I was saying. There is a "global-global header" (at the beginning of the stream) and a "global header" on each keyframe [00:12:11 CET] <JEEB> that is fucking completely different semantics [00:12:49 CET] <JEEB> I was talking about the lavf/lavc flag which I thought you were talking about [00:13:02 CET] <JEEB> if you want to talk about container structure's that separate [00:13:12 CET] <JEEB> please tell so if you're going to switch the talk [00:13:26 CET] <JEEB> that just confuses the fuck of me because you're using the same "global header" terminology [00:13:50 CET] <faLUCE> JEEB: as said before, I don't know how to call this header [00:14:11 CET] <faLUCE> libavformat calls it "header" [00:14:42 CET] <faLUCE> anyway, what I want to understand is: [00:14:57 CET] <faLUCE> 1) does MPEGTS need this "container header" ? [00:15:10 CET] <faLUCE> 2) doese MPEGTS need GLOBAL header? [00:15:21 CET] <JEEB> ok, now you're using the word global header agian [00:15:28 CET] <JEEB> please tell me what the meaning of that for you is [00:15:58 CET] <faLUCE> Global header = header at the beginning of each encoded keyframe [00:16:14 CET] <JEEB> ok, so different to lavf/lavc flag [00:16:15 CET] <JEEB> got it [00:16:23 CET] <JEEB> although that doesn't make any sense [00:16:30 CET] <JEEB> anyways, mpeg-ts is simple [00:16:41 CET] <JEEB> it has no real concept of headers or footers [00:16:52 CET] <JEEB> a parser will start reading MPEG-TS packets (188 bytes) [00:16:59 CET] <JEEB> it will keep reading until it gets PAT [00:17:10 CET] <faLUCE> so, it doesn't need a container header, although some strange players want it (IIRC) [00:17:18 CET] <JEEB> wait until I finish [00:17:32 CET] <JEEB> PAT is a packet that tells it "this stream has these programs in it" (think of "program" as in a channel on TV) [00:17:42 CET] <faLUCE> I remember that, just want a confirmation [00:18:08 CET] <JEEB> then it gets PMT, and that is the mapping of streams within programs [00:18:13 CET] <JEEB> after that it can start reading [00:18:39 CET] <faLUCE> but I also remember that some weird players wanted a header also for the container, at the beginning of the stream. But I could be wrong [00:18:41 CET] <JEEB> most likely FFmpeg's MPEG-TS muxer puts PAT+PMT at each keyframe, or possibly more often. not sure what the spec was. every 0.5s? [00:18:53 CET] <JEEB> there's no header. you just need to have PAT+PMT [00:19:01 CET] <JEEB> I know some stupid stream dumpers cut out PAT+PMT [00:20:12 CET] <JEEB> so in FFmpeg terms, MPEG-TS is not a format with the global header flag. because you put the decoding initialization packets in-band, into the stream. into your AVPackets [00:20:38 CET] <faLUCE> then, calling av_write_header() for MPEGTS is needed only for internal stuff, but not for writing a header on the container, right? [00:21:02 CET] <faLUCE> or it is not needed at all? [00:22:51 CET] <JEEB> you should still call it because the framework expects it, but there is no write_header function in the mpegts muxer :P [00:23:36 CET] <faLUCE> JEEB: in fact I said "for internal stuff".... maybe it allocates stuff needed for the stream? [00:23:54 CET] <JEEB> that probably happens in init [00:24:07 CET] <JEEB> because you are supposed to not add streams after you call init() [00:24:18 CET] <JEEB> but anyways, yes [00:24:22 CET] <JEEB> internally it's part of the flow [00:24:29 CET] <JEEB> in the worst case it just does nothing :P [00:24:37 CET] <JEEB> because the muxer doesn't have such a function [00:25:08 CET] <JEEB> although mpegtsenc does have a write_trailer, which is peculiar [00:25:26 CET] <JEEB> oh, that just flushes :P [00:25:37 CET] <faLUCE> so I can call it safely [00:25:57 CET] <faLUCE> (this is very confusing anyway) [00:26:05 CET] <JEEB> well it's part of the flow so you should be calling it at the end anyways :P [00:26:10 CET] <JEEB> it's part of the framework flow [00:26:23 CET] <JEEB> different containers do different things in different parts of it [00:26:31 CET] <JEEB> some might just not have some steps [00:26:35 CET] <faLUCE> ok. In case of matroska, it writes the container's header too [00:26:59 CET] <JEEB> yes, that's 100% up to the muxer what it does [00:27:10 CET] <JEEB> and if you're trying to expect something from those then just please don't [00:29:18 CET] <faLUCE> now, if I mux h264 with matroska, this means that I CAN put the GLOBAL_HEADER flag on the muxer's avcodeccontext if I don't put it on the encoder's avcodeccontext, right? [00:29:33 CET] <faLUCE> sorry: [00:29:42 CET] <faLUCE> now, if I mux h264 with matroska, this means that I NEED TO put the GLOBAL_HEADER flag on the muxer's avcodeccontext if I don't put it on the encoder's avcodeccontext, right? [00:30:24 CET] <faLUCE> so the muxer can add the extradata to the packets incoming to av_write_frame [00:31:55 CET] <JEEB> not muxer [00:32:03 CET] <JEEB> you are getting the flag from the muxer and setting the flag accordingly in encoder [00:32:45 CET] <JEEB> if you are not encoding in lavc then you have to make sure that your headers are in the extradata field of the avcodecparameters of the AVStream [00:32:57 CET] <JEEB> as in, the stream extradata [00:33:05 CET] <faLUCE> are you sure? if for example with the same encoder I want to feed a mpegts muxer and mkv muxer? [00:33:26 CET] <faLUCE> mpegts doesn't want global header, but mkv does [00:33:54 CET] <JEEB> not sure if matroskaenc.c takes in Annex B [00:34:03 CET] <JEEB> if it does and auto-converts then it's kind "OK" [00:34:10 CET] <JEEB> (it's not, but you get away with it) [00:34:35 CET] <JEEB> another alternative is to have a bit stream filter where needed [00:34:40 CET] <JEEB> so you get AVCc for matroskaenc [00:34:47 CET] <JEEB> and Annex B for mpegtsenc [00:35:18 CET] <JEEB> although I think in some cases nowadays bit stream filters get auto-inserted in some cases [00:36:21 CET] <JEEB> yea, I think *_mp4toannexb gets inserted automagically nowadays in various cases [00:36:23 CET] <faLUCE> JEEB: I could set globalheaderextradata and extradata_size to 0 for mpegts, or is it unsafe? [00:36:38 CET] <faLUCE> sorry: [00:36:58 CET] <faLUCE> JEEB: I could set globalheader for the eancoder + extradata and extradata_size to 0 for mpegts, or is it unsafe? [00:38:24 CET] <JEEB> faLUCE: libavformat/mpegtsenc.c auto-inserts to annex b bit stream filter, so I think you should be OK with global header if one of your formats requires global header, and the other is mpegts [00:38:33 CET] <JEEB> with H.264 and HEVC at least [00:39:30 CET] <faLUCE> JEEB: but AVPacket has "side_data" field [00:39:38 CET] <JEEB> side data is different [00:39:42 CET] <faLUCE> I see [00:39:47 CET] <JEEB> side data is additional metadata etc [00:39:55 CET] <faLUCE> then, extra_data is computed by the codecpar [00:40:46 CET] <JEEB> well if you are encoding with lavc it should be easy :P [00:40:57 CET] <JEEB> since you have the to and from params functions [00:41:11 CET] <JEEB> and in this case you want from your AVCodecContext to the AVstream's AVCodecParameters [00:42:25 CET] <faLUCE> JEEB: I know, but you think it's not necessary to "reset" the extradata and extradata_size params for the mpegts muxer, after copying avcodec params? [00:42:42 CET] <JEEB> I'm not sure if mpegtsenc cares [00:44:02 CET] <JEEB> also remember, mpegtsenc auto-inserts the bit stream filter [00:44:08 CET] <JEEB> although I'm not sure if that touches extradata [00:44:20 CET] <faLUCE> from what I see mpegtsenc.c uses codec->extradata for AAC and H264 [00:44:28 CET] <JEEB> I see that mpegtsenc has an Annex B check for extradata [00:44:47 CET] <JEEB> but the question is, since you get the mp4 to annex-b bit stream filter applied [00:44:52 CET] <JEEB> does that touch your extradata, too [00:45:48 CET] <faLUCE> this "extradata" field is used for different things [00:46:13 CET] <JEEB> h264_extradata_to_annexb [00:46:39 CET] <JEEB> extradata in general is supposed to be the initialization data for a codec, and in cases where such a thing doesn't exist it covers other internal usages [00:47:06 CET] <JEEB> and what I wanted to say, the bit stream filter does touch your extradata [00:47:13 CET] <JEEB> it will convert it to annex b [00:47:29 CET] <JEEB> so no, you don't have to clear it yourself [00:47:38 CET] <faLUCE> JEEB: I see [00:48:24 CET] <JEEB> at least looking at the fact that there's h264_extradata_to_annexb in the h264_mp4toannexb bsf [00:48:26 CET] <faLUCE> but if I set GLOBAL_HEADER for h264, does it touch extradata for annex_b ? [00:48:33 CET] <JEEB> ?! [00:48:38 CET] <faLUCE> I mean: [00:48:52 CET] <faLUCE> when I set GLOBAL_HEADER, I see that extradata becomes not null [00:49:17 CET] <JEEB> yes, libx264 writes the parameter sets to extradata in your AVCodecContext [00:49:25 CET] <JEEB> I think it writes AVCc extradata there [00:50:10 CET] <faLUCE> ok, now, given that x264 needs other extradata, I could "corrupt" the extradata content if I write GLOBALHEADER on it [00:50:16 CET] <faLUCE> ? [00:50:23 CET] <JEEB> wat [00:50:42 CET] <faLUCE> I mean: [00:52:11 CET] <faLUCE> [00:47] <JEEB> and what I wanted to say, the bit stream filter does touch your extradata <--- is it supposed to touch an extradata set by the encoder, or the extradata set with GLOBAL_HEADER? [00:52:38 CET] <JEEB> what do you mean with the latter part? [00:53:17 CET] <faLUCE> I mean that setting GLOBAL_HEADER affects "extradata". But when the encoder inits, extradata is affected as well for other things, right? [00:53:30 CET] <JEEB> ?! [00:53:41 CET] <JEEB> also what is supposed to be touching extradata? [00:54:12 CET] <faLUCE> avcodeccontext->flags |= AV_GLOBAL_HEADER <----- this touches extradata [00:55:26 CET] <faLUCE> shortly, I don't understand if I can set safely AV_GLOBAL_HEADER on the h264 encoder's context, for mpegts [00:56:00 CET] <faLUCE> given that it affects extradata, and extradata is then touched by mpegts for other reasons [00:56:52 CET] <JEEB> ok, let's go step by step [00:58:15 CET] <faLUCE> ok [00:58:29 CET] <JEEB> 1) setting AV_CODEC_FLAG_GLOBAL_HEADER to an encoder AVCodecContext tells the encoder that if it cares about that flag, that it should write the decoder initialization data into its extradata field (AVCodecContext) [00:58:46 CET] <JEEB> that is why the extradata starts existing for libx264 for example [00:59:09 CET] <JEEB> libx264 being one of the encoder wrappers that care about this flag [00:59:22 CET] <faLUCE> ok [01:00:39 CET] <JEEB> 2) Yes, you should be OK to set that flag safely for libx264 if you know all of your muxers will work with it. MPEG-TS should work because it auto-inserts a bit stream filter. [01:01:36 CET] <faLUCE> JEEB: this is the point. It checks specific bit(s), not the complete extradat [01:01:39 CET] <faLUCE> a content [01:01:40 CET] <JEEB> 2.1) the bit stream filter does not touch the encoder AVCodecContext.extradata as it is called by the muxer, it only touches the AVStream's [01:01:55 CET] <JEEB> faLUCE: yes, it checks it for the Annex B start code [01:02:13 CET] <JEEB> if it has Annex B start codes no bit stream filter and you should be OK [01:02:21 CET] <JEEB> if it has no, it will auto-insert the bsf [01:02:35 CET] <JEEB> at least that is how it looks to me looking at mpegts.c [01:02:38 CET] <JEEB> *mpegtsenc.c [01:02:48 CET] <faLUCE> ok, thanks, then it won't care about the AV_CODEC_FLAG_GLOBAL_HEADER bit in extradata [01:02:53 CET] <JEEB> ?! [01:02:59 CET] <JEEB> the flag will not be in extradata [01:03:26 CET] <JEEB> AVCodecContext.extradata is a buffer of data [01:03:32 CET] <JEEB> AVCodecContext.flags is separate [01:03:44 CET] <JEEB> I probably got those wrong but you understand me :P [01:03:50 CET] <JEEB> *what I mean [01:04:55 CET] <faLUCE> I understand, the result is that in extradata the avcodeccontext puts different things [01:05:12 CET] <faLUCE> as a buffer [01:05:13 CET] <JEEB> depends on the encoder, and you are specifically requesting it with the flag [01:05:22 CET] <JEEB> because your output format requested it [01:05:27 CET] <JEEB> I don't see what hte problem is [01:05:41 CET] <JEEB> anyways, I give up now. I need sleep. [01:05:45 CET] <faLUCE> I thought that extradata was not a buffer [01:05:51 CET] <faLUCE> but a "all in one field" [01:05:56 CET] <faLUCE> ok, many thanks [01:27:29 CET] <bintran2812> I have a problem with muxing HLS segments manually using ffmpeg [01:27:54 CET] <bintran2812> detail description is here: https://pastebin.com/F0eedCbu [01:28:23 CET] <bintran2812> I think I need to specify more information from m3u8 file in ffmpeg command [01:29:30 CET] <net|> is there a flag to write ffmpeg in playable chunks for live streaming that overwrite themselfs ? [01:29:53 CET] <net|> do i need webm chunks for that or is there a filesize limit flag [01:31:53 CET] <DHE> the hls muxer should take care of everything. normally the sequence counts up forever. just use the delete_segments flag so it cleans up after itself. [01:32:22 CET] <DHE> oh these aren't related I assume... [01:32:36 CET] <bintran2812> yeah [01:33:20 CET] <bintran2812> I mean in case I do it manually, like if I have video_segment.mp4 and audio_segment.mp4 [01:33:20 CET] <DHE> don't mind me... [01:34:06 CET] <bintran2812> I cannot mux them manually with ffmpeg -i video_segment.mp4 -i audio_segment.mp4 .... [01:34:44 CET] <bintran2812> Don't know if there is a special flag that can mimic what HLS muxer doing [02:01:24 CET] <bintran2812> actually it should be how hls demuxer work [02:16:13 CET] <net|> is there a way to stop recording video when it hits 1M filesize ? [02:16:45 CET] <net|> i had a look at the man pages and found max_size and chunk_size but neither worked [02:22:47 CET] <another> -fs 1M [02:24:35 CET] <KombuchaKip> Why does the ffmpeg write it's own ./configure manually instead of using the autotools? Isn't it more work to reinvent its functionality? [02:32:11 CET] <iive> KombuchaKip, quite the opposite [02:32:39 CET] <KombuchaKip> iive: Care to elaborate? [02:34:29 CET] <net|> thank you [02:36:33 CET] <iive> KombuchaKip, autotools is language on its own. ffmpeg configure is written entirely on bash script. [02:37:28 CET] <KombuchaKip> iive: Yes, I'm aware of that. But autoconf generates a POSIX shell script that is more portable than bash and with much less work. So the question still is why? [02:37:40 CET] <KombuchaKip> iive: I'm not questioning their reasoning, I just would like to know it. [02:37:57 CET] <KombuchaKip> iive: They'd obviously have had to have had a good reason to do what they did. [02:39:16 CET] <iive> it takes quite an effort to make autotools do what you want. you can use some pre-existing things, but trying anything custom and you start fighting it. [02:39:31 CET] <KombuchaKip> iive: Isn't that what M4 macros are for? [02:39:54 CET] <iive> m4 are the pre-existing stuff. [02:40:40 CET] <iive> writing your own configure is simpler. and you don't depend on another project to fix their own bugs. [02:40:43 CET] <KombuchaKip> iive: No, you can write your own M4 macros which are effectively just plugins. [02:40:55 CET] <iive> well... what's the point then? [02:41:35 CET] <iive> why involve two languages, to get one job done? [02:41:52 CET] <KombuchaKip> iive: Is your reasoning shared with the rest of the ffmpeg maintainers? [02:42:01 CET] <iive> ask them yourself. [02:42:09 CET] <KombuchaKip> iive: I did above. [02:43:18 CET] <iive> this is user channel [02:43:26 CET] <iive> a lot of developers are not here. [02:45:27 CET] <iive> hum, ffmpeg configure is actually just /bin/sh . [02:48:03 CET] <iive> KombuchaKip, ask in #ffmpeg-devel [02:48:12 CET] <KombuchaKip> iive: Ok [02:48:43 CET] <iive> any reason to ask that? do you want to rewrite it to use autoconf? [02:50:10 CET] <KombuchaKip> iive: No. But I use both the Autotools daily and ffmpeg as well. It just seemed very counter intuitive what they had done, so I was curious to know their reasoning given that they surely had some. Based on what you shared, although I think your reasons are quite out dated, I can see how they would have made sense a long time ago back when the Autotools were more of a black art with no good books on them. [02:51:03 CET] <iive> it's possible ffmpeg configure is older than autotools [02:52:48 CET] <iive> so the cost of maintaining has always been lower than rewriting it. [02:52:58 CET] <KombuchaKip> iive: Yes, that would make sense. [02:53:24 CET] <KombuchaKip> iive: And of course it's not just ./configure that would have to be rewritten as configure.ac, but also all the makefile templates too. [02:55:38 CET] <iive> maybe mason would be good enough to warren a switch. I see it used for a number of projects. [02:57:03 CET] <KombuchaKip> iive: I've not much experience with it. [02:59:25 CET] <iive> me either. But seeing how mesa3d transitioned to using it, almost effortlessly... makes me quite optimistic. [02:59:42 CET] <iive> and they already had autoconf and cmake in place. [03:49:25 CET] <xxxmaker> anybody here who is expert in video/camera/photo [04:53:20 CET] <xxxmaker> what is the command to extract just the audio.wma file out of video-audio.wmv file [04:59:56 CET] <TheAMM> ffmpeg -i file.wmv -map 0:a -c copy audio.wma, possibly [05:00:35 CET] <xxxmaker> what does -map 0:a do [05:00:38 CET] <xxxmaker> never seen that command [05:04:14 CET] <another> it selects all audio from input 0 for the output [05:06:07 CET] <xxxmaker> you mean 0 video for output? [05:07:05 CET] <another> specifying a map disables automatic stream selection [05:07:17 CET] <another> https://ffmpeg.org/ffmpeg-all.html#Stream-selection [05:07:25 CET] <another> so it only maps audio [05:08:18 CET] <xxxmaker> is it normal that seeking is super slow on .opus audio [05:08:31 CET] <xxxmaker> it takes like 5 seconds after seeking to hear a sound [07:42:02 CET] <xxxmaker> why do i get so many of this error: Non-monotonous DTS in output stream 0:0; previous: 17928, current: 16656; changing to 17929. This may result in incorrect timestamps in the output file. [07:42:13 CET] <xxxmaker> when i try to convert wma to opus [09:04:50 CET] <xxxmaker> [libfdk_aac @ 040536e0] Note, the VBR setting is unsupported and only works with some parameter combinations [09:05:00 CET] <xxxmaker> why am i getting this error [09:06:13 CET] <ritsuka> are you sure you are converting wma to opus? [09:06:43 CET] <xxxmaker> ritsuka yes [09:06:44 CET] <ritsuka> libfdk_aac is a aac encoder [09:07:00 CET] <xxxmaker> ritsuka i get 100 errors when i do wma to opus [09:07:10 CET] <xxxmaker> i get 2 errrors when i do wma to aac [09:07:16 CET] <xxxmaker> i get 0 errors when i do wma to flac [09:07:42 CET] <xxxmaker> why is that? [09:07:54 CET] <ritsuka> well, post the whole output (in a pastebin) and maybe someone will know the reason [09:08:26 CET] <xxxmaker> what is the command to output a log [09:09:28 CET] <JEEB> 2> ffmpeg_sucks.log [09:09:47 CET] <JEEB> 2> is "redirect standard error" and then the file name [09:09:49 CET] <xxxmaker> huh [09:10:02 CET] <JEEB> standard wnidows command line or linux shell stuff :P [09:10:22 CET] <JEEB> ffmpeg.c outputs to standard error since standard input/output can be utilized for piping stuff in/out [09:10:38 CET] <xxxmaker> ffmpeg.exe -i extra.wma -acodec libopus -vbr on extra.opus [09:10:58 CET] <xxxmaker> where do i put output a log to extra.txt file [09:16:47 CET] <xxxmaker> ritsuka https://pastebin.com/pE62qS52 [09:24:34 CET] <xxxmaker> ritsuka https://pastebin.com/HVGutYGx [09:25:00 CET] <xxxmaker> ritsuka so? [10:30:05 CET] <xxxmaker> x265 2.1:[Windows][GCC 5.4.0][64 bit] 8bit [10:30:05 CET] <xxxmaker> Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=3 / subme=3 / merange=57 / rect / no-amp / max-merge=3 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / no-strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / [10:30:05 CET] <xxxmaker> interlace=0 / keyint=300 / min-keyint=30 / scenecut=40 / rc-lookahead=25 / lookahead-slices=4 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=3 / limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock [10:30:05 CET] <xxxmaker> / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30 [10:30:05 CET] <xxxmaker> Default : Yes [11:51:35 CET] <xxxmaker> i need help : https://pastebin.com/pE62qS52 [12:31:26 CET] <faLUCE> I'm trying to decouple encoders from muxers as much as I can. With mpegts-video I can do that: the avcodeccontext of the muxer only requires width, height and the codecId params, without having to allocate a full avcodeccontext for it. But it seems that matroska, for example, requires much more params and a full avcodeccontext allocation: why? which params does matroska really need by the avcodeccontext? [12:32:43 CET] <DHE> it just has way more metadata than mpegts, which has little more than codecid and some minimal non-codec information like audio language, etc. [12:35:29 CET] <faLUCE> DHE: but which params exactly? it needs a global header... and what else? I don't know which params from avcodeccontext I have to set [12:35:30 CET] <DHE> ...if the mkv muxer is actually requiring an AVCodecContext, there's something wrong. or you're using a version pre-codecpar [12:35:43 CET] <faLUCE> I'm using 4.1.1 [12:38:02 CET] <DHE> that seems new enough.. [12:38:17 CET] <JEEB> he means copying values/buffers from avctx to codecpar [12:38:22 CET] <JEEB> just putting it badly :P [12:39:44 CET] <faLUCE> I use: avcodec_parameters_from_context(mVideoStream->codecpar, mVideoCodecContext); [12:40:25 CET] <faLUCE> mVideoCodecContext is not allocated. It's only filled with width, height, and codecId [12:40:30 CET] <DHE> so you're decoding the video just enough to get the codeccontext parameters, then copying that to the actual output->streams[x]->codecpar ? [12:41:22 CET] <faLUCE> I get that parameters not by the decoded video [12:42:24 CET] <faLUCE> I set them manually on an avcodeccontext object, then I copy them on the stream with avcodec_parameters_from_context [12:43:26 CET] <faLUCE> JEEB: why do you think I put badly the params? [12:43:38 CET] <JEEB> I meant you worded it badly [12:43:42 CET] <JEEB> just like I can word things badly [12:43:50 CET] <JEEB> you made him think that you were using avctx in avstream [12:43:57 CET] <JEEB> which is an old thing that hasn't been in FFmpeg for a while [12:43:58 CET] <faLUCE> I see [12:44:29 CET] <DHE> and I'm confused. you can set values on the avcodecparameters object yourself as well. it's not an opaque structure. don't need to fill in a codeccontext and then use the copy function [12:44:59 CET] <JEEB> I think he was more wondering what he exactly needed to be put into the codecpar because he wanted to minimize his code orso [12:45:07 CET] <JEEB> which of course "depends on the format" [12:45:34 CET] <faLUCE> JEEB: exactly [12:45:50 CET] <faLUCE> for mpegts I only needed width, height and codecId [12:46:01 CET] <JEEB> yes, because the container level stuff that's put in is minimal [12:46:16 CET] <faLUCE> but for matroska it seems that I need much stuff [12:46:19 CET] <JEEB> matroska on the other hand needs to generate stuff that contains the decoder initialization stuff [12:46:28 CET] <DHE> I don't think you actually need width and height for mpegts either [12:47:06 CET] <faLUCE> matroska seems to need all the parameters I set for the x264 encoding... tune, bitrate etc. [12:49:45 CET] <faLUCE> is this true? It seems overkill [12:50:40 CET] <DHE> mkv is the overkill format. chapters, multi-track, supports nearly any codec and subtitles, [12:51:02 CET] <JEEB> I don't think it utilizes bit rate nor tune [12:51:16 CET] <JEEB> I would think having extradata and width/height etc should be enough? [12:51:23 CET] <JEEB> you wouldn't know exactly without looking at the muxer, though :P [12:51:29 CET] <JEEB> see the write_header function [12:51:58 CET] <DHE> tune seems excessive from a need-to-know standpoint. profile (baseline, main, high) could make sense if you're including resolution [12:52:27 CET] <faLUCE> by looking at matroscaenc.c it uses par->extradata [12:52:44 CET] <JEEB> that one we could guess by the format's requirements, yes [12:53:01 CET] <JEEB> since you have the decoder initialization data structure which is out-of-band [12:56:02 CET] <faLUCE> [12:51] <JEEB> I would think having extradata and width/height etc should be enough? <---- but is extradata affected by tune, preset, bitrate, profile ? [12:57:02 CET] <JEEB> it is literally a set of bytes you get from an encoder or a stream you're copying through [12:57:17 CET] <JEEB> thus your question doesn't make sense [12:57:36 CET] <JEEB> even if it is affected, what does that matter if you are properly passing it through from your input stream [12:58:02 CET] <faLUCE> JEEB: if my initial question was "how can I decouple the muxer from the encoder" [12:58:57 CET] <DHE> sadly you can't. if you know the codec, you probably have a usable AVCodecPar, either because you are encoding it, or are demuxing it from something that can provide its own AVCodecPar for you to copy [12:59:54 CET] <faLUCE> DHE: but with mpegts I can... [13:00:27 CET] <JEEB> because mpeg-ts is a format that doesn't require more info [13:00:43 CET] <JEEB> if you want to decouple from the encoder then just add a parser of your own [13:00:48 CET] <DHE> if the input is mpeg-ts, I suggest avformat_find_stream_info() which will fill in the codecpar for all the input streams which you can copy [13:00:49 CET] <JEEB> which extracts the parameter sets [13:01:40 CET] <faLUCE> [13:00] <DHE> if the input is mpeg-ts, I suggest avformat_find_stream_info() <--- do you mean if the input is matroska? [13:02:09 CET] <faLUCE> with mpegts I just need the codecId.... [13:02:26 CET] <DHE> that works too. point is avformat_find_stream_info does its best to fill in all the codecpar fields for all the streams [13:03:10 CET] <DHE> then avcodec_parameters_copy(outputctx->streams[x]->codecpar, inputctx->streams[y]->codecpar); // regardless of formats [13:08:19 CET] <faLUCE> DHE: in this case I would not need to use an AVCodecContext for filling the params, right? [13:29:31 CET] <DHE> no [13:43:44 CET] <faLUCE> DHE: so the procedure would be that: I alloc an AVFormatContext with a specific format (for example: matroska). Then I av_write_frame() some incoming packets and call, after each av_write_frame(), avformat_find_stream_info() until it returns >= 0. At this point I'm sure that the codecpars are filled and then I can mux the packets with that format, right? [14:26:24 CET] <dongs> dongs [14:27:00 CET] <pink_mist> pink_mist [16:32:21 CET] <faLUCE> I don't get the point yet. With avformat_find_stream_info() I can get infos of a MUXED stream. But I can't use it for filling the codecparameters of an output stream if I don't have a muxed input stream but I have only encoded packets. There seems to be a bad coupling of the matroska format with avcodeccontext. I mean: why would this format require a full allocated avcodeccontext with all its parameters for working? [16:32:53 CET] <drew32> Hey all! [16:33:45 CET] <drew32> https://www.ffmpeg.org/ffmpeg-formats.html#dash-2 shows a -streaming 1 option but when I added it, it tells me option not found. Was it removed? [16:34:31 CET] <faLUCE> matroska format should work regardless of all the codec's infos, like bitrate, tune etc. [16:34:59 CET] <JEEB> faLUCE: it doesn't need *all* [16:35:03 CET] <JEEB> it does need extradata [16:35:10 CET] <JEEB> which you can get by parsing the stream that you are going to pass to it [16:35:19 CET] <JEEB> mp4 does the same thing, it needs H.264 etc initialization data [16:35:27 CET] <JEEB> different formats are different [16:35:41 CET] <JEEB> like, if you want to completely black box what you're passing to the muxer [16:35:55 CET] <Ducky^> I'm trying to do a two pass encode from asf to mp4 with a very old version of ffmpeg (which can't be upgraded..) [16:35:56 CET] <JEEB> then you just add a parser in front of the muxing thing that gets the required stuff from the bit stream you're passing [16:36:02 CET] <Ducky^> https://pastebin.com/Y5Skjjij [16:36:11 CET] <JEEB> drew32: the AVOption is still there [16:36:16 CET] <Ducky^> I want to target a file size of 2MB [16:36:32 CET] <Ducky^> I get the error - [libx264 @ 0x7c41430]Error: 2pass curve failed to converge [16:36:37 CET] <JEEB> drew32: libavformat/dashenc.c: { "streaming", "Enable/Disable streaming mode of output. Each frame will be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E }, [16:36:43 CET] <JEEB> so you might actually have a too old version? [16:37:11 CET] <Ducky^> and the log file is empty [16:37:20 CET] <Ducky^> the resulting file is 10MB [16:37:23 CET] <faLUCE> JEEB: and how could I parse that stream for getting the extradata value? they are only encoded packets [16:37:33 CET] <JEEB> yes, for H.264 you use a H.264 parser [16:37:36 CET] <JEEB> for HEVC you use a HEVC parser [16:38:10 CET] <faLUCE> JEEB: I see, but is there such a parser wrapped in lavc? or do I need to call x264 natively ? [16:38:41 CET] <drew32> ah I think you are right I have version 3.4.4-0ubuntu-.19.04.1 [16:38:42 CET] <JEEB> lavf has a raw H.264 parser. but seriously, if you have an encoder yourself under your control, just pass the extradata from the encoder forwards [16:39:14 CET] <JEEB> also if you are using lavf for input reading then you can pass the extradata from there [16:39:24 CET] <JEEB> if you are having some custom input that doesn't use lavf [16:39:28 CET] <JEEB> then you will have to parse the stream [16:39:36 CET] <JEEB> either with lavf or by yourself [16:39:38 CET] <JEEB> sorry [16:39:59 CET] <faLUCE> JEEB: right [16:44:26 CET] <faLUCE> JEEB: you are right, but it seems a sort of hack/workaround. I mean: the extradata depends on the encoder's settings (bitrate,tune etc.) but the extradata needed by the format doesn't have to depend by them. I don't know how to explain better, but you can get it [16:47:40 CET] <faLUCE> it seems a bug of the matroska muxer [16:50:15 CET] <faLUCE> the problem is not if I have or not have custom input. Even if the input is made by lavc, the container's initialization should not be coupled with the encoder [17:05:21 CET] <faLUCE> so, JEEB no: I don't want to black box what I'm passing to the muxer. I just want to pass the muxer the right number of params, not an obscure field wich mixes together stuff not associated with the matroska container [17:05:59 CET] <faLUCE> let's try to ask to the devel channel [17:38:27 CET] <cj> o/ [17:39:18 CET] <cj> I'm looking to convert an .mkv to .mp4 and re-order the audio tracks - or mark the second audio track as default, while keeping the subtitles tracks. [17:39:30 CET] <cj> could I get some help building up my command? [17:39:58 CET] <cj> it looks something like this: [17:39:59 CET] <cj> ffmpeg -i "$in" -map 0:v:0 -map 0:a:1 -map 0:a:0 -c:v libx264 -preset veryslow -crf 22 -c:a libmp3lame -qscale:a 2 -ac 2 -ar 44100 "$out" [17:40:38 CET] <cj> wait, that's the one going from ogm to mp4 [17:40:43 CET] <furq> cj: -disposition:a:0 0 -disposition:a:1 default [17:40:50 CET] <furq> or the other way round. 0 clears the flag, default sets it [17:40:57 CET] <cj> thanks, furq! [17:41:08 CET] <furq> this is assuming you've already tried it and the wrong track is selected [17:41:16 CET] <furq> otherwise just the -maps you have will work [17:41:35 CET] <furq> also you would normally use aac audio in mp4 [17:41:38 CET] <cj> so maybe `ffmpeg -i "$in" -disposition:a:0 0 -disposition:a:1 default -codec copy "$out"` ? [17:41:47 CET] <furq> well you still want the maps as well [17:41:49 CET] <DHE> also, unless you have codec problems you probably just want to copy the coded video/audio from the source. [17:41:57 CET] <cj> okay, do I replace libmp3lame with libaac ? [17:42:02 CET] <furq> DHE: if the source is ogm then that's vorbis [17:42:05 CET] <Ducky^> ffmpeg -y -i /tmp/test.mpeg -b 270k -vcodec libx264 -an test.mp4 [17:42:07 CET] <furq> idk if that muxes into mp4 but probably not [17:42:23 CET] <Ducky^> I'm using this line with an old version of ffmpeg, but the video bitrate comes out to around 1700k instead of 270k [17:42:27 CET] <DHE> would ogm have h264, or would it be something like theora [17:42:30 CET] <Ducky^> is there a limit to how low the bitrate can be? [17:42:32 CET] <furq> cj: -c:a aac -vbr 5 or -c:a aac -b:a 128k [17:42:37 CET] <furq> er [17:42:39 CET] <furq> actually just the second one [17:42:45 CET] <cj> thanks [17:42:48 CET] <furq> -vbr 5 is for libfdk_aac which you won't have unless you built ffmpeg yourself [17:43:37 CET] <Ducky^> if I set the bitrate to something like 3000k it actually comes out as 3000k [17:43:43 CET] <cj> I had debian build it for me. is it a better codec? [17:44:07 CET] <cj> coder, I suppose [17:47:41 CET] <furq> cj: yes but it's not gpl compatible so you can't distribute binaries with it [17:47:48 CET] <furq> also it's not that much better for cbr, the builtin encoder is fine [17:58:54 CET] <faLUCE> well, DHE, from what I see the matroska header is strictly coupled with the encoder's params: https://lists.matroska.org/pipermail/matroska-devel/2012-April/004196.html . So, DHE, you were wrong when you said "<DHE> it just has way more metadata than mpegts, which has little more than codecid and some minimal non-codec information like audio language, etc." [17:59:06 CET] <faLUCE> or do I miss something? (I could be wrong as well) [17:59:26 CET] <cj> maybe I don't understand streams or maps correctly... this command results in the error "Stream map '0:a:1' matches no streams. [17:59:29 CET] <cj> ffmpeg -i "$in" -map 0:v:0 -map 0:a:1 -map 0:a:0 -disposition:a:0 0 -disposition:a:1 default -codec copy "$out" [18:00:53 CET] <cj> Stream #0:1(jpn): Audio: aac (HE-AAC), 32000 Hz, stereo, fltp (default) and Stream #0:2(eng): Subtitle: ass (default) [18:00:55 CET] <DHE> cj: ffmpeg should output a quick analysis of the input file including the streams in the orders and identities. it only shows 0:0, 0:1, ... names though [18:01:00 CET] <DHE> yeah that [18:01:18 CET] <DHE> that's presumably 0:0 as video, 0:1 as audio (japanese) and 0:2 as subtitles (english) [18:01:26 CET] <cj> I guess I should disable default on the eng stream. that might be sufficient maybe [18:01:55 CET] <DHE> here (default) is more an indication that if ffmpeg had to select one audio stream (eg: simply 0:a) this would be its selection [18:02:41 CET] <cj> why might it be telling me that "Stream map '0:a:1' matches no streams ? [18:03:40 CET] <DHE> because you only have 1 video stream, 1 audio stream, and 1 subtitle stream (based on what you pasted above). there is no second audio stream [18:03:46 CET] <cj> oh, I see. only a single audio stream in this one, apparently. I thought they all had two audio streams [18:03:58 CET] Action: cj opens with vlc to verify [18:04:41 CET] <cj> so I guess my script needs to determine whether there is one or two audio stream/s. [18:04:56 CET] <cj> and do the re-order and mapping only if there are two [18:05:18 CET] <cj> I was hoping there would be something to dump json or something more easily parsable than `ffmpeg -i $in -no_banner` [18:05:28 CET] <cj> does anything like that exist, or shall I write a parser function? :-) [18:05:34 CET] <furq> ffprobe has a json output format [18:05:41 CET] <cj> \o/ [18:05:52 CET] <furq> also yeah if your source already has aac or mp3 audio then you should just use -c:a copy [18:08:57 CET] <faLUCE> well, they are telling to me that matroska's header does need h264 encoder's params... [18:09:38 CET] <faLUCE> so, there's no way to decouple the muxer from the encoder. It's not a ffmpeg problem, but it's a spec of matroska [18:17:50 CET] <faLUCE> I don't understand why, in each case, the matroska header wants that infos, if a raw h264 video can be played as well [18:22:01 CET] <kepstin> a "raw" h264 stream requires the same information, it's put into a packet at the start of the data. [18:23:02 CET] <kepstin> iirc with mpeg-ts, the codec initialization data is supposed to repeated periodically through the stream so you can jump in at an arbitrary point. [18:24:12 CET] <kepstin> matroska (and mp4/mov too) store that information in a spot defined by the container. [18:24:35 CET] <faLUCE> kepstin: they are answering to me in the #matroska channel [18:24:48 CET] <kepstin> with mp4, that's not written until the *end* of the stream, which is why mp4 files that were interrupted/truncated are not playable [18:30:58 CET] Action: DHE patches lavf/udp.c for realtime threading. :/ [18:44:46 CET] <faLUCE> kepstin: finally I got the point. Matroska is coupled with the encoder's params because it's not "bytestream". Then, all the infos for decoding frames are in the header. Then you can start decoding immediatly [18:47:45 CET] <faLUCE> in this way, for example, if the codec's params change, you can tune the decoder soon [18:54:54 CET] <drew32> Hey so I followed a guide to compile a newer version of ffmpeg on ubuntu. My version now shows N-93414-g4602456. looks like this is what I compiled: https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 [18:55:05 CET] <drew32> Anyone know if this is an up to date version or did I follow an incorrect guide [18:56:05 CET] <DHE> that's dated today. how new do you need it? [18:56:22 CET] <drew32> I think that's new enough lol, how did you tell it was dated today? [18:56:23 CET] <kepstin> there's only been 1 commit since that tarball :) [18:56:28 CET] <DHE> I see 2, but still [18:56:35 CET] <kepstin> drew32: the stuff after the g on the end is the git commit hash [18:56:42 CET] <DHE> go to my git dir, and run: git log 4602456 [18:56:49 CET] <drew32> ahh thanks! I'm still new to this stuff [18:58:45 CET] <DHE> of course its' so new I have to `git fetch origin` first. :) [19:00:39 CET] <BtbN> Put the commit ID into github, and it's pretty clear: https://github.com/FFmpeg/FFmpeg/commits/4602456 [19:02:06 CET] <drew32> Hopefully this version fixes some of the DASH issues ive been having [19:06:39 CET] <cj> hurm. so the map / disposition thing didn't change the default audio stream from english to japanese. how would I go about doing this? I extracted the stream metadata with ffprobe, so I have that info to throw in to the command if needed. [19:10:10 CET] <another> cj: maybe your player has a lang preference? [19:13:07 CET] <drew32> wow finally the dash stream no longer crashes after a few mins! [19:13:16 CET] <drew32> i'm loving this new version lol [20:20:02 CET] <retal> faLUCE, Hi i still have problem with compiling with nvresize and x264 [20:20:13 CET] <retal> what can i do ? [20:25:59 CET] <BtbN> nvresize? Are you using that ancient patch from nvidia? If so, just don't. There are two CUDA based scaling filters that are actually part of ffmpeg. [20:26:33 CET] <retal> BtbN, yes i patched [20:26:52 CET] <BtbN> Don't. [20:27:26 CET] <retal> How to using CUDA resize in ffmpeg ? [20:29:02 CET] <BtbN> Don't use that ancient pointless patch. [20:30:30 CET] <retal> BtbN, ok, thank you. But how use scaling filters with CUDA acceleration ? [20:30:49 CET] <BtbN> "There are two CUDA based scaling filters that are actually part of ffmpeg." [20:31:20 CET] <BtbN> scale_cuda for the simple case, and the npp based on for more features but more of a hassle to get a working [20:31:49 CET] <retal> BtbN, thank you [20:34:34 CET] <ginel> I'd like to build a live video stream with ffmpeg and I'd like to include multiple layers [20:35:19 CET] <ginel> is there a way to have ffmpeg dynamically load text from a file each frame? [20:36:40 CET] <ginel> I'm trying to figure out how to have a progress bar fill up with color and a text label as the value increases [20:38:05 CET] <ChocolateArmpits> That sounds like something Avisynth would do more easily [20:38:12 CET] <ChocolateArmpits> but if it's a live one [20:38:15 CET] <ChocolateArmpits> .. [20:40:15 CET] <ginel> I will experiment with 'textfile="/path/file.txt":reload=1' here [20:40:23 CET] <retal> BtbN, should i install https://git.videolan.org/git/ffmpeg/nv-codec-headers.git ? [20:40:45 CET] <BtbN> You'll have to if you want to build ffmpeg with any kind of CUDA/nvenc/nvdec features. [20:41:08 CET] <retal> thank you [20:58:12 CET] <ginel> what does this mean: [20:58:14 CET] <ginel> Cannot find a matching stream for unlabeled input pad 0 on filter Parsed_drawtext_1 [20:58:19 CET] <ginel> when trying to run this: [20:58:48 CET] <ginel> http://paste.debian.net/1073998/ [21:06:35 CET] <retal> libavformat/libavformat.a(allformats.o):(.data.rel.ro+0x398): undefined reference to `ff_kux_demuxer' [21:06:35 CET] <retal> collect2: error: ld returned 1 exit status [21:06:35 CET] <retal> Makefile:108: recipe for target 'ffmpeg_g' failed [21:06:35 CET] <retal> make: *** [ffmpeg_g] Error 1 [21:06:56 CET] <retal> how to fix ? [21:09:27 CET] <ChocolateArmpits> ginel, you need to use a comma instead of a semicolon between the two filters [21:10:26 CET] <ginel> gotcha [21:23:03 CET] <retal> guys, how to fix error: libavformat/libavformat.a(allformats.o):(.data.rel.ro+0x398): undefined reference to `ff_kux_demuxer' [21:23:03 CET] <retal> collect2: error: ld returned 1 exit status [21:23:03 CET] <retal> Makefile:108: recipe for target 'ffmpeg_g' failed [21:23:03 CET] <retal> make: *** [ffmpeg_g] Error 1 [21:24:50 CET] <faLUCE> hello retal :-) [21:25:48 CET] <faLUCE> in order to fix the error you shuld tell what kind of configure you want [21:27:24 CET] <faLUCE> and which patches you applied [21:31:43 CET] <retal> faLUCE, Hi, i am configuring: ./configure --enable-nonfree --enable-nvenc --enable-libx264 --enable-gpl --enable-cuda --enable-cuvid [21:31:43 CET] <retal> So i need CUDA transcoding and software 264 codec. [21:31:43 CET] <retal> BtbN told me i dont need use ancient patches for nvresize, instead i can use "scale_cuda" [21:31:43 CET] <retal> So i didnt apply patches [21:32:43 CET] <furq> ginel: replace the ; with , [21:32:54 CET] <ginel> yeah done [21:33:04 CET] <furq> oh christ this is that french gist again isn't it [21:33:09 CET] <furq> i thought i'd finally seen the last of that thing [21:33:36 CET] <faLUCE> retal: are you sure the error tells "ff_kux_demuxer" ? [21:34:06 CET] <faLUCE> did you copy/paste it ? [21:34:41 CET] <furq> ginel: get rid of pretty much the entire second line of that gist (-acodec to 512k) because basically all of it is wrong or stupid [21:35:01 CET] <furq> and replace it with -c:a aac -b:a 128k [21:35:22 CET] <retal> faLUCE, may be i shuld tri install on clean system [21:35:24 CET] <retal> look https://pastebin.com/geczWC1i [21:35:46 CET] <ginel> how much of that second line is defaults? [21:35:50 CET] <ginel> out of curiosity [21:35:56 CET] <furq> none of it except possibly -ar [21:36:04 CET] <faLUCE> retal: it seems that some patch is still in memory [21:36:16 CET] <furq> depending on the source sample rate [21:36:16 CET] <ginel> ok well I need the preset [21:36:28 CET] <retal> faLUCE, may be [21:36:31 CET] <furq> i meant the line starting with -acodec [21:36:40 CET] <ginel> ok [21:37:05 CET] <faLUCE> retal: you just have to grep "ff_kux_demuxer" in the src [21:37:06 CET] <furq> also it looks like you already got rid of -deinterlace but definitely don't ever use that [21:37:09 CET] <furq> not even if the source is interlaced [21:37:11 CET] <ginel> this is going to be sent to an RTMP ingest for what it's worth [21:37:15 CET] <faLUCE> then, tell me the file where you find it [21:37:18 CET] <furq> yeah there's no other reason to use flv [21:37:46 CET] <furq> if it was just a file i'd also say to get rid of -g but youtube recommends two seconds for some reason so why not [21:38:03 CET] <ginel> -vcodec libx264 -pix_fmt yuv420p -preset ultrafast -r 30 -g $((30 * 2)) -b:v 2500k -a:c aac -crf 23\ [21:38:08 CET] <ginel> how about that [21:38:14 CET] <furq> -b:v and -crf are incompatible [21:38:26 CET] <furq> i assume it uses whichever comes last [21:38:29 CET] <ginel> ah yeah that makes sense [21:38:33 CET] <ginel> didn't catch that [21:39:17 CET] <ginel> surprised it didn't warn me [21:40:09 CET] <furq> if you do use crf you'll probably want something like -maxrate 2500k -bufsize 5000k [21:40:22 CET] <furq> it's not a bad idea to set that with -b:v either but you'll definitely want it for crf to avoid rate spikes [21:42:33 CET] <ginel> any idea why YouTube says it's receiving data then pretty much immediately says it's not? [21:43:40 CET] <ginel> http://paste.debian.net/1074006/ [21:43:47 CET] <ginel> new paste, minus my damn stream key [21:43:53 CET] <ginel> didn't notice I'd included that [21:45:18 CET] <furq> probably because there's no audio source [21:45:34 CET] <ginel> ah might be [21:45:35 CET] <furq> -f lavfi -i anullsrc [21:47:33 CET] <ginel> for the curious I'm trying to put a countdown and "raised funds" progress bar on a VPS and run the stream from there [21:51:08 CET] <cj> another: good point. I'll check the docks. [21:51:15 CET] <cj> s/k// [21:51:49 CET] <ginel> it looks like YouTube doesn't want to archive the 60 second test stream I did using this command. the archive is stuck at processing in the old dashboard and in the new dashboard it's not even there [21:52:07 CET] <ginel> can anyone see any issues with the command that YouTube might be having an issue with? [22:15:04 CET] <retal> faLUCE, Binary file libavformat/libavformat.a matches [22:15:05 CET] <retal> libavformat/demuxer_list.c: &ff_kux_demuxer, [22:15:05 CET] <retal> Binary file libavformat/allformats.o matches [22:15:05 CET] <retal> libavformat/allformats.c:extern AVInputFormat ff_kux_demuxer; [22:18:32 CET] <furq> retal: looks like that line was added three hours ago and there's no corresponding symbol yet [22:18:36 CET] <furq> so maybe that latest commit is broken [22:18:53 CET] <retal> :)))) [22:19:04 CET] <retal> what can i do ? :) [22:19:26 CET] <retal> how to clone right commit ? [22:21:02 CET] <furq> if you already cloned the repo then git checkout 4602456c4f18d111131d4d6a1d0a150474c74d58 [22:21:20 CET] <retal> friki, thanks [22:22:10 CET] <furq> http://fate.ffmpeg.org/ [22:22:12 CET] <furq> looks like it's not just you [22:22:41 CET] <retal> :) [22:28:50 CET] <faLUCE> retal: in each case, I would not use the git image [22:29:00 CET] <faLUCE> use the stable image, instead [22:29:12 CET] <faLUCE> why are you using the git one? [22:30:31 CET] <retal> faLUCE, i am cloning from git://source.ffmpeg.org/ffmpeg.git, stabile image i shuld download from ffmpeg website ? [22:32:02 CET] <faLUCE> retal: yes, download it from the home page, don't use git, you don't need the git image [22:33:06 CET] <retal> faLUCE, thank you, in next time i will use home page, anyway i just aplyed: git checkout 4602456c4f18d111131d4d6a1d0a150474c74d58, and compile without error [22:33:35 CET] <faLUCE> ok [22:33:59 CET] <faLUCE> but you should use the stable image in any case [22:34:28 CET] <faLUCE> git is for development or for experimental stuff, or if you really need something that you don't have in the stable image [22:34:37 CET] <faLUCE> but it's not stable [22:36:26 CET] <retal> faLUCE, you right i just a user :) [22:41:08 CET] <BtbN> don't use git:// urls. They are inherently insecure and entirely unencrypted. [23:03:20 CET] <cj> git+ssh ftw [23:04:53 CET] <faLUCE> do you know if avcodec_parameters_from_context() are all copies? I see that extradata is a pointer and I wonder if it's a reference or a copy of the stuff [23:05:59 CET] <faLUCE> sorry, just checked: it's a copy (memcpy) [23:08:09 CET] <faLUCE> then I wonder: what's the best way to free it? manually or is it freed by the cleanup avstream's stuff ? [23:20:39 CET] <DHE> avcodec_parameters_free() obviously [23:21:17 CET] <DHE> I assume avformat will call that during its own cleanup as it cleans up the streams [23:21:37 CET] <faLUCE> yes, I thought about avformat, not avstream [23:51:41 CET] <retal> guys how to enable scale_cuda ? [23:54:56 CET] <furq> --enable-cuda-nvcc [23:54:59 CET] <furq> or just use scale_npp [00:00:00 CET] --- Thu Mar 21 2019

1 0

ffmpeg-devel.log.20190319
by burek 20 Mar '19

20 Mar '19

[01:11:44 CET] <cone-319> ffmpeg 03PaweB Wegner 07master:4ed6a485d324: libavformat/movenc: mov: added subtitle codec tags to codec tag list [01:22:15 CET] <jamrial> jkqxz: think you can give removing the copy overheard for the av1 parser a try, like you just did for vp9? [01:25:34 CET] <jkqxz> I was thinking of that. It's a bit harder there because you do want the OBUs split out to look through. [01:27:08 CET] <jkqxz> And the split function is trickier than VP9, where it doesn't seem objectionable to duplicate the superframe iteration. [05:10:33 CET] <cone-606> ffmpeg 03James Almer 07master:f8075b2c91c3: tests/fate-run: fix regression in encoding options [11:55:13 CET] <thardin> there used to be ffmpeg t-shirts, right? are they still available? [12:02:42 CET] <nadermx> Hi all, I posted the question on #ffmpeg, but feel this chat might be more appropriate, https://superuser.com/questions/1415281/ffmpeg-freezes-when-piping-two-inpu… [12:07:52 CET] <thardin> nadermx: does it work if you replace ytdl with cat:ing downloaded files, and does it work if you just pipe in one stream instead of two? [12:27:54 CET] <sourabhboss> How I can write bit in 4 size using avio [12:30:28 CET] <kierank> sourabhboss: bit in 4 size? [12:35:04 CET] <sourabhboss> I need something like avio_wb4 [12:45:20 CET] <kierank> sourabhboss: do you want to write 4 bits or 4 bytes? [13:47:46 CET] <thardin> wait a sec [13:47:58 CET] <thardin> baptiste revoked his gpg key [17:19:18 CET] <thardin> he's got a new one even [18:11:46 CET] <cone-785> ffmpeg 03James Almer 07master:5cd60b6f2ed8: avcodec/libdav1d: reset pool size on allocation failure [18:11:47 CET] <cone-785> ffmpeg 03James Almer 07master:9e62e1a1104b: avcodec/libdav1d: use a reference to the allocated buffer instead of wrapping the Dav1dPicture [19:24:37 CET] <kierank> j-b: what does carl mean about a NEWS entry? [19:35:04 CET] <kierank> ah for website [20:56:37 CET] <cone-785> ffmpeg 03Derek Buitenhuis 07master:90b85ab21fcb: h2645_parse: Fix loglevel for NAL header parsing [21:48:11 CET] <cone-785> ffmpeg 03Gyan Doshi 07master:41ef6dd67d48: doc/ffmpeg: remove entry for -loop_output [22:56:55 CET] <cone-785> ffmpeg 03Rodger Combs 07master:ce6301a46fae: avcodec/vt_hevc: fix crash if vps_list[0] or sps_list[0] are null [00:00:00 CET] --- Wed Mar 20 2019

1 0

ffmpeg.log.20190319
by burek 20 Mar '19

20 Mar '19

[00:13:24 CET] <bindi> I have two videos i'd like to combine side-by-side and I'm trying to avoid using a "movie maker", but can I alternate between the audio? as in, play audio from video1 0-5secs, then video2 5-10 secs, and so on [01:49:33 CET] <friki> bindi: https://stackoverflow.com/questions/35349935/ffmpeg-crop-with-side-by-side-… like that? [01:50:33 CET] <bindi> I managed the side by side part with google but the audio alternating I could not find. But combined audio worked just fine for this use case [01:51:10 CET] <friki> like diagonal example [01:51:33 CET] <friki> probably you can found a function based on time that fits [02:00:44 CET] <friki> bindi: ffmpeg -f lavfi -i color=color=red -t 30 red.mp4 && ffmpeg -f lavfi -i color=color=blue -t 30 blue.mp4 && ffmpeg -i red.mp4 -i blue.mp4 -filter_complex '[1:v][0:v]blend=all_expr=if(gt(T\,9)\,B\,A)' fcb.mp4 [02:01:52 CET] <friki> [...] \,A\,B)' fcb.mp4 # probably better :-) [02:10:49 CET] <friki> bindi: I think now here is the complete solution, switching video each 10 seconds: ffmpeg -f lavfi -i color=color=red -t 60 red.mp4 && ffmpeg -f lavfi -i color=color=blue -t 60 blue.mp4 && ffmpeg -i red.mp4 -i blue.mp4 -filter_complex "[1:v][0:v]blend=all_expr=if(gt(mod(T\,20) \,10)\,A\,B)" fcb.mp4 [02:16:17 CET] <bindi> friki: works, but the audio isn't alternated with it :P [02:16:26 CET] <bindi> and my original question was to have them side-by-side and alternate the audio only [02:16:45 CET] <bindi> however I was satisfied with the one I managed to create which is just side by side and combined audio :D [02:16:53 CET] <bindi> or rather, I am :P [02:53:54 CET] <friki> oh, sorry. similar efect with audio should be possible with audio pan filter [02:58:45 CET] <xxxmaker> anybody here who is video/camera/photo expert ? [03:05:35 CET] <TheSashm_> is there anyone that can properly explain qmin and qmax when dealing with mpeg2?? [03:05:38 CET] <TheSashm_> so confused... [03:30:55 CET] <dongs> xxxmaker: i thought we already determined this yesterday. the one wiht shit colors, same camera as the other one? [03:31:18 CET] <xxxmaker> it should be, but i wasn't at the scene [03:31:46 CET] <dongs> really low saturation, maybe someone didn't set it up properly for low-light shooting [03:32:43 CET] <xxxmaker> dongs join #photogeeks [03:33:08 CET] <dongs> nah i got shit to do man, the point here is you arent gonna be able to fix that video, so you might as well just reshoot [03:33:13 CET] <dongs> you can't fix that shit in post [04:48:02 CET] <xxxmaker> what can i do to make video encoding faster with ffmpeg? [04:51:21 CET] <dongs> use nvenc [04:51:57 CET] <xxxmaker> how do i do that [04:52:15 CET] <xxxmaker> is that totally separate program? [04:52:33 CET] <dongs> no, its nvenc encode pipeline in ffmpeg [04:52:53 CET] <dongs> i.e. -c:v h264_nvenc -preset slow -profile high -level 4.1 -b:v 9M [04:53:26 CET] <xxxmaker> okay [04:53:32 CET] <dongs> on a consumer nvidia card you can encode 2 streams at ~120fps each, on quadro you can do like 4 streams+ at 60fps [04:53:36 CET] <xxxmaker> what is the downside/negative of using nvenc [04:53:40 CET] <dongs> none [04:54:04 CET] <dongs> it uses hardware h264/265 encoder thats on every ~recent nvidia card [04:54:23 CET] <dongs> basically same thing thats in phones/etc that does video encoding/decoding by hardware instead of CPU [04:54:25 CET] <xxxmaker> so if i use nvenc, does it use any CPU usage? [04:54:36 CET] <dongs> nope, barely any CPU [04:54:40 CET] <xxxmaker> i see [04:54:57 CET] <dongs> just wahtever is needed to copy to/from GPU and any overhead of parsing input + applying filters (if any) [04:55:14 CET] <kepstin> well, the downside is that you can attain better compression ratios for a given quality if you do cpu encoding - the hardware encoer isn't as good as a cpu encoder [04:55:17 CET] <dongs> the above nvenc line for me when I'm encoding 1080p stuff runs at 240fps [04:55:21 CET] <kepstin> but it sure is fast [04:55:21 CET] <xxxmaker> i have gt 1030 [04:55:27 CET] <dongs> works [04:55:30 CET] <kepstin> gt 1030 does not have a hardware encoder [04:55:38 CET] <dongs> https://developer.nvidia.com/video-encode-decode-gpu-support-matrix [04:55:42 CET] <dongs> does it not? [04:55:50 CET] <dongs> oh lul [04:55:52 CET] <dongs> right on top of that page [04:55:56 CET] <dongs> with NO everywehre [04:55:56 CET] <kepstin> nope, minimum is gtx 1050 for the encoder [04:56:26 CET] <dongs> geez thats terrible, well okay. pickup a chceap 1050 then. [04:57:01 CET] <xxxmaker> dongs kepstin is claiming the hardware encoer isn't as good as a cpu encoder [04:57:04 CET] <kepstin> or stick with software encoding and assuming you're using x264 just use a faster preset [04:57:14 CET] <kepstin> which will make it go faster, but not be as good [04:57:50 CET] <dongs> unless you're authoring bd quality stuff and hand-tuning encoding paramters i think nvenc is perfectly fine for modern media for consumption [04:57:54 CET] <kepstin> the benefits of the software encoder kind of go away if you try to speed it up to match the hardware encoder. [04:59:04 CET] <xxxmaker> if i encode a raw video with cpu encoder and encode a same raw video with nvidia encoder, are you able to tell the difference which is which? [04:59:54 CET] <kepstin> xxxmaker: if they're both encoded with settings that result in the same quality, you can't tell visually - but the filesize from the nvidia encoder will probably be bigger, depending on settings used. [05:00:24 CET] <xxxmaker> kepstin what if i made the filesize of both of them equally [05:00:33 CET] <xxxmaker> which one would have better quality [05:00:58 CET] <kepstin> then assuming you were using x264 with a preset that makes it run slower than the hardware encoder, it'll probably look better - although this depends on video content. [05:01:26 CET] <kepstin> if you set the output filesize sufficiently large, you won't be able to tell them apart [05:01:59 CET] <kepstin> differences are bigger when files are being compressed smaller/lower quality [05:02:03 CET] <xxxmaker> dongs 240 fps ? wow are you serious? [05:02:27 CET] <xxxmaker> cpu encoder does 3 fps for 1080p [05:03:07 CET] <kepstin> depending on use case, hardware encoders definitely can be the best option. [05:04:22 CET] <xxxmaker> kepstin what fps would you get if you do 1080p video using hevc using nvenc [05:04:39 CET] <kepstin> xxxmaker: see the nvidia documentation, they provide specs [05:05:23 CET] <kepstin> well, i thought they did. lets see if i can find them [05:06:21 CET] <xxxmaker> kepstin i see YES for gt 1030 on the second part: https://developer.nvidia.com/video-encode-decode-gpu-support-matrix [05:06:33 CET] <kepstin> it has a hardware *decoder* [05:06:38 CET] <kepstin> but not an *encoder* [05:06:47 CET] <xxxmaker> i see [05:06:50 CET] <kepstin> it's a consumer chip meant for media consumption :) [05:07:35 CET] <xxxmaker> is it possible to use both cpu and gpu at the same time to speed up the encoding (if you have the right nvdia hardware) [05:07:44 CET] <xxxmaker> or is that not possible? [05:07:59 CET] <kepstin> xxxmaker: yes, by encoding two videos at once - one on the cpu, the other on the gpu :) [05:08:21 CET] <xxxmaker> what about for one video [05:08:31 CET] <xxxmaker> can it be hybrid? [05:08:42 CET] <kepstin> looks like nvidia claims around 120-150fps hevc 1080p 4:2:0 8bit encoding, although they specify that using a quadro card running 4 or 5 concurrent 30fps streams [05:08:44 CET] <kepstin> no [05:08:52 CET] <kepstin> the hardware encoder is an encoder on its own [05:09:04 CET] <kepstin> there's nothing that can be broken out to software [05:09:19 CET] <kepstin> (it would probably slow it down if there was, since stuff would have to be copied in/out of gpu ram) [05:10:03 CET] <kepstin> consumer geforce cards are capped at encoding either 1 or 2 concurrent streams, even tho the hardware is capable of more. [05:10:16 CET] <xxxmaker> it says gtx 1050 does not support b frame; is b frame important? [05:11:32 CET] <kepstin> b frame is required for modern codecs to achieve the compression ratios that people claim they can do [05:11:57 CET] <xxxmaker> kepstin so it's very important [05:12:07 CET] <xxxmaker> especially for people who care about file size [05:12:34 CET] <kepstin> i don't know for sure, but i suspect that the hevc encoder on pascal might not actually provide better results than the h264 encoder in terms of quality/bit [05:12:46 CET] <kepstin> since the h264 encoder can use b-frames [05:13:23 CET] <kepstin> be interesting for someone to test that [05:13:27 CET] <xxxmaker> it says GeForce RTX 2080 support b frames but i am guessing GeForce RTX 2080 is super expensive [05:13:31 CET] <kepstin> (maybe someone has and i just haven't seen it) [05:14:11 CET] <kepstin> all turing cards should, a gtx 1660 would do it and that's around $230usd iirc? [05:14:29 CET] Action: cards passed a turing test [05:15:34 CET] <xxxmaker> cards what gpu do you have [05:15:45 CET] <kepstin> i assume they'll come out with a tu117 based gtx 1650 at some point, which would be the cheapest card with turing's nvenc. [05:15:46 CET] <cards> nothing of note. [05:16:04 CET] <cards> i'm not a cutting edge fan [05:16:35 CET] <xxxmaker> what is better turing or volta [05:18:10 CET] <kepstin> xxxmaker: they do different things. but turing is *newer* and has a newer hardware encoder revision, so for encoder purposes turing is probably better for most use cases. [05:18:26 CET] <xxxmaker> kepstin okay [05:18:48 CET] <xxxmaker> kepstin what gpu do you have? [05:19:56 CET] <kepstin> i've got a bunch of intel integrated stuff (intel actually has an ok hardware encoder too), a radeon rx 560 (which has a pretty bad hardware encoder with iffy drivers), some radeon vega integrated stuff that i haven't really tested yet, and a gt 1030 :) [05:20:49 CET] <kepstin> i mostly do software encoding, fits my use cases best (picked up a ryzen chip with lots of cores for that) [05:21:21 CET] <kepstin> at work, i do cpu encoding on amazon spot instances mostly :) [05:21:31 CET] <xxxmaker> does amd GPU support nvenc too? [05:21:43 CET] <kepstin> hint: the nv stands for nvidia [05:22:26 CET] <xxxmaker> does amd GPU support hardware encoding too? [05:22:27 CET] <kepstin> "nvenc" is the name of nvidia's hardware encoder, which uses proprietary drivers & api to access. so nvidia only [05:23:12 CET] <kepstin> amd gpus have hardware encoders, accessible via different apis, e.g. vaapi on linux. their encoders tend to not be as good as nvidia's [05:23:48 CET] <kepstin> intel's igpus have a hardware encoder named 'quicksync' which is generally considered ok, you might even already have one of those [05:24:28 CET] <kepstin> (quicksync is sometimes disabled if you have an external gpu added, depending on motherboard settings - and xeon chips with no igpu don't have quicksync at all) [05:24:46 CET] <xxxmaker> i have i7 3770 [05:25:00 CET] <xxxmaker> with geforce gt 1030 [05:25:40 CET] <kepstin> hmm. ivy bridge is kinda old at this point. i'd have to check references, but I think it can encode h264 ok. [05:26:04 CET] <xxxmaker> i am getting 2 fps [05:26:11 CET] <xxxmaker> 2-3 fps [05:27:56 CET] <kepstin> that number is meaningless without knowing what encoder settings and filtering you're using. [05:28:28 CET] <xxxmaker> x265 3.0:[Windows][GCC 7.1.0][64 bit] 8bit+10bit+12bit [05:28:28 CET] <xxxmaker> Encoding settings : cpuid=1049583 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1600x900 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / [05:28:28 CET] <xxxmaker> keyint=240 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra [05:28:28 CET] <xxxmaker> / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 [05:28:28 CET] <xxxmaker> / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / [05:28:29 CET] <xxxmaker> min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / refine-ctu-distortion=0 / [05:28:29 CET] <xxxmaker> no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / qp-adaptation-range=1.00 [05:28:30 CET] <xxxmaker> Default : Yes [05:28:38 CET] <kepstin> and don't spam the irc channel [05:28:47 CET] <xxxmaker> sorry didn't realize it was this long [05:29:06 CET] <kepstin> i don't care about x264's internal settings, just the ffmpeg command line you're using [05:29:20 CET] <kepstin> i can't read that mess :/ [05:29:21 CET] <xxxmaker> x265 [05:29:29 CET] <kepstin> oh, hevc, lol [05:29:31 CET] <kepstin> that's why it's slow [05:29:35 CET] <kepstin> use x264 [05:30:08 CET] <kepstin> hevc software encoders are slow, hevc hardware encoders are fast but barely better than the h264 encoders :/ [05:30:32 CET] <kepstin> (although now that turing added b-frame support, that might have changed a bit) [05:30:50 CET] <xxxmaker> you mean turing didn't support b-frame before? [05:31:23 CET] <kepstin> you read that chart - pascal (the previous nvidia generation - 10XX cards) doesn't do b frames in hevc. [05:32:06 CET] <xxxmaker> correct [05:32:56 CET] <kepstin> turing is so new that i haven't seen any comparisons on the efficiency of the hevc encoding, but i suspect it has improved compared to pascal. [05:33:32 CET] <xxxmaker> when did turing come out [05:34:39 CET] <kepstin> late 2018/early 2019 depending on card model [05:34:46 CET] <kepstin> the extremely high end stuff came out first [05:36:18 CET] <xxxmaker> wow didn't realize turing is so new [05:37:02 CET] <kepstin> like, the gtx 1660 (non-ti) was announced just last week. [05:37:28 CET] <xxxmaker> is it safe to assume youtube uses GPU-hardware encoding [05:37:44 CET] <kepstin> youtube almost certainly uses software (cpu) encoding [05:38:06 CET] <xxxmaker> kepstin why do you say that [05:38:50 CET] <kepstin> google has a lot of cpus, and not a lot of gpus. they encoder a lot of videos using vp9, which doesn't really have a competitive hardware encoder out yet (they're probably using libvpx) [05:39:33 CET] <xxxmaker> youtube started using av1 [05:39:39 CET] <xxxmaker> as well [05:39:46 CET] <xxxmaker> which is suppose to be even better [05:40:03 CET] <kepstin> only google has enough cpu power available to encode any meaningful amount of av1 video [05:40:17 CET] <kepstin> if you think x265 is slow, well, av1 is a lot slower :) [05:40:35 CET] <kepstin> (at least with libaom, the primarily google-developed reference encoder) [05:40:54 CET] <xxxmaker> does ffmpeg support av1 encoding? [05:41:14 CET] <kepstin> can't remember. last i checked, libaom api wasn't stable enough yet. [05:42:20 CET] <kepstin> (i should probably say that libaom dev is "google led", i don't know who the main developers on it actually are, and there's a lot of people involved) [05:42:46 CET] <xxxmaker> wonder if there is freenode channel for libaom [05:48:10 CET] <xxxmaker> has anybody here used nvenc for video encoding? [07:47:01 CET] <dongs> xxxmaker: thats all i use [07:47:04 CET] <dongs> i even pasted you command line [07:47:09 CET] <dongs> but you need a less shitty GPU [07:47:49 CET] <xxxmaker> dongs what GPU do you have [07:48:01 CET] <dongs> quadro P2000 [07:48:13 CET] <dongs> the encoding hardware is same in all pascal cards. its just artificially limited by driver [07:48:19 CET] <dongs> so quality etc is all same across the board. [07:49:28 CET] <xxxmaker> i see [07:49:59 CET] <xxxmaker> can you paste me the meta data that video file shows after using nvenc [07:51:13 CET] <dongs> you mean like mediainfo? [07:51:57 CET] <dongs> http://bcas.tv/paste/results/IuWk8j47.html [07:52:57 CET] <dongs> http://bcas.tv/paste/results/QhN3kv74.html [07:52:59 CET] <dongs> some other shit [07:54:34 CET] <xxxmaker> i see [07:54:39 CET] <xxxmaker> you dont' get meta like this? Encoding settings : cpuid=1049583 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 [07:54:50 CET] <dongs> no cuz there aren't any settings with nvenc [07:55:03 CET] <dongs> < xxxmaker> dongs 240 fps ? wow are you serious? [07:55:07 CET] <dongs> yes serious [07:55:11 CET] <dongs> its hardware encoder [07:57:53 CET] <dongs> xxxmaker: frame= 1905 fps=150 q=12.0 size= 74922kB time=00:01:03.46 bitrate=9671.0kbits/s dup=0 drop=1 speed=5.01x [07:57:59 CET] <dongs> this is encode w/deinterlace filter [07:58:03 CET] <dongs> so its slowing shit down a bit [07:58:16 CET] <xxxmaker> isn't deinterlacing done by CPU though? [07:58:16 CET] <dongs> ffmpeg -hwaccel dxva2 -threads 1 -i video.mkv -filter:v yadif -c:v h264_nvenc -preset slow -profile:v high -level 4.1 -b:v 10M output.mkv [07:58:19 CET] <dongs> yes [07:58:26 CET] <dongs> thats why encode fps is lower [07:59:09 CET] <dongs> frame= 1872 fps=218 q=12.0 size= 75185kB time=00:01:02.36 bitrate=9876.3kbits/s dup=0 drop=1 speed=7.26x [07:59:13 CET] <dongs> same source without filter [07:59:33 CET] <xxxmaker> i see [07:59:50 CET] <dongs> anyway, still way better than 3 fps haha. [08:00:04 CET] <xxxmaker> try using h265 nvenc [08:00:17 CET] <dongs> yes, it should be same [08:00:22 CET] <furq> nvdec/cuvid does deinterlacing fyi [08:00:25 CET] <furq> supposedly it's pretty good [08:00:35 CET] <dongs> furq, yeah im sure. i was jsut too lazy to look it up. [08:00:48 CET] <furq> -deint adaptive -c:v h264_cuvid -i ... [08:00:49 CET] <xxxmaker> but i was told pascal doesn't do b-frames [08:00:50 CET] <dongs> i onyl had that one interlaced source from an old mpeg2 camera [08:00:59 CET] <dongs> furq: nice, saved [08:01:14 CET] <furq> or -deint bob but i guess adaptive is better [08:01:57 CET] <xxxmaker> i hate 3 fps encoding [08:02:01 CET] <xxxmaker> too slow [08:03:19 CET] Action: JEEB still remembers doing encodes circa 2006 with an amd laptop (lol) [08:03:26 CET] <JEEB> 0.6fps or so [08:03:52 CET] <JEEB> so x264 f.ex. is fast now on any modern cpu by comparison [08:05:35 CET] <JEEB> last I tested on my desktop I could go all 'tard with preset placebo with I think 720p at 8fps [08:05:41 CET] <JEEB> (4790k) [08:06:31 CET] <JEEB> and on various boxes doing 1080p25 with preset veryslow was very muchos realtime [08:08:49 CET] <JEEB> hw encoders are for low latency and speed without cpu usage, anyways. so for example I would utilize my nvidia's encoder when doing lossless captures of gaming or whatever [10:48:21 CET] <Dragas> Yo! I'm trying to cross compile for android but I keep getting the following error: `ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc is unable to create an executable file.` This is my config.log that's provided at ffbuild [10:48:22 CET] <Dragas> https://pastebin.com/r9XGSdNb [10:49:38 CET] <Dragas> And I'm using the following script to cross compile it: https://pastebin.com/2UPe390g [10:49:42 CET] <Dragas> What am I doing wrong here? [10:51:47 CET] <furq> ./configure: line 968: /Users/mantas/Library/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc: No such file or directory [10:51:53 CET] <furq> maybe this has something to do with it [10:54:15 CET] <Dragas> Hmm. You're right. It doesn't include gcc [11:01:32 CET] <net|> anyone know how to fix mjpeg errors ? [11:01:53 CET] <net|> [video4linux2,v4l2 @ 0x56511c3f99e0] Cannot find a proper format for codec 'mjpeg' (id 8), pixel format 'none' (id -1) [11:02:45 CET] <net|> ./configure says mjpeg was included [11:02:54 CET] <furq> set -pix_fmt before -i [11:03:46 CET] <net|> awesome thanks much [11:08:50 CET] <net|> seems to be working, http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live… this code keeps spitting out chunks of files.. i just want a single webm file to access via website is that doable ? [11:09:20 CET] <net|> makes alot of chk files [11:11:24 CET] <net|> also seems to use all my cpu [11:13:24 CET] <net|> i had too many threads [11:30:57 CET] <nadermx_> Hi all I'm trying to fun a command that pipes two outputs into ffmpeg, but the program seems to only half recive one of them and then just hangs [11:33:11 CET] <nadermx_> { command1 -o; command2 -o; } | ffmpeg -i pipe:0 -i pipe:1 -c:v copy -c:a aac -strict experimental output.mp4 [13:21:42 CET] <Abdullah> I'm using this command but getting not good result in output video. even I tried to increase framerate. ffmpeg -video_size 1600x900 -framerate 30 -f x11grab -i :0.0 -f pulse -ac 2 -i default output.mkv [13:22:03 CET] <Abdullah> did with 60 framerate but still no good response. [13:27:38 CET] <MatthewAllan93> Hey :), I am trying to use encode x265 with Opus, therefore using this part of the command for audio "-c:a libopus -b:a 128k -vbr on -ac 2". But I have checked in Mediainfo program, to check the output file. I saw that it isn't using the 128kb vbr and instead using the bitrate that is in the input video. Any help would be appreciated :). [13:43:11 CET] <lethyr> can ffmpeg concatenate a video file and standard input? [13:43:51 CET] <lethyr> to avoid XY problems I'll write up a description of my desired end result [13:45:23 CET] <lethyr> I have a script that checks for live video streams on a cron job and downloads those live streams. a second script later uploads them to a YouTube channel for backup. I'd like to add an intro to the files before they are uploaded to YouTube and concatenating two files together takes a very long time. I was hoping to do it on the fly instead. [13:58:08 CET] <lethyr> I have tried: [13:58:10 CET] <lethyr> cat input_test.mp4 | ffmpeg -i input_test.mp4 -i - -filter_complex "[0:v] [0:a] [1:v] [1:a] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" output_test.mp4 [14:00:01 CET] <lethyr> this results in multiple errors: https://pastebin.com/raw/0qYHUXVa [14:02:47 CET] <lethyr> the concat demuxer will not accept standard input as a valid entry [14:11:11 CET] <mickeyl> Hey. I'm working on decoding a H264 stream sent by an IP cam. This IP cam does not send SPS and PPS NALUs, still FFmpeg manages to gather the correct parameters by looking at the slices. Perhaps someone has a some insight in how that works. (At the end of the day, I'm trying to initialize the hardware decoder on iOS which absolutely needs the SPS and PPS for proper format initialization) [14:19:37 CET] <BtbN> They have to be somewhere. [14:22:56 CET] <furq> MatthewAllan93: opus vbr is actual proper vbr, not abr [14:23:21 CET] <furq> -b:a 128k won't attempt to hit 128kbps, it's just a quality level [14:23:31 CET] <brejeiro> kepstin: I'm using Windows, and was trying to avoid changing the cursor system-wide. I'd like to only change in the recording... But, if this is not possible, I'll just change it for the whole system. [14:23:34 CET] <furq> also i wouldn't necessarily trust mediainfo to give the right bitrate there anyway [14:23:41 CET] <brejeiro> Thanks for the answer! [14:23:43 CET] <furq> especially if this is mkv [14:24:48 CET] <kepstin> brejeiro: the way the screen capture on windows works, you could actually edit the gdigrab.c file to change the cursor image used, but you can't change it without editing the ffmpeg code. [14:25:13 CET] <furq> lethyr: that command won't work because the input is an mp4 [14:25:24 CET] <furq> as a rule you can't read or write mp4s from or to pipes [14:25:28 CET] <MatthewAllan93> furq: Ah ok, thanks for your answer. It was just because I am use to FFMPEG encoding at 128kb vbr around that bitrate, not at 320kb for an example. [14:25:50 CET] <furq> if it's showing as 320k then either this is incredibly pathological audio or mediainfo is just reporting it wrong [14:25:53 CET] <lethyr> @furq thanks [14:25:53 CET] <brejeiro> Hmmm, got it. As I'm deploying it via chocolatey to hundreds of computers, I think it will be easier to just change the current cursor. Not a big deal, anyway! [14:25:55 CET] <furq> probably the second one [14:26:16 CET] <lethyr> I can use mpegts files which is what I'm experimenting with now if that'll get me in the right direction [14:26:29 CET] <furq> well if nothing else ts will give you a more useful error [14:26:39 CET] <furq> i feel like that should work though [14:26:46 CET] <MatthewAllan93> furq: I thought that but wanted to make sure, thanks for your answer anyway :). [14:27:43 CET] <furq> MatthewAllan93: you can demux the audio stream if you want to check the actual bitrate [14:27:52 CET] <furq> -i foo.mkv -map 0:a bar.opus [14:27:59 CET] <furq> er [14:28:01 CET] <furq> -i foo.mkv -map 0:a -c copy bar.opus [14:29:30 CET] <brejeiro> Another thing I was wondering is: is there a way to get the current frame/exact time of a recording? I'm recording some stuff in my desktop, and I need the precise moment that an event occurred. As the recording start a few moments before I manage to do things, If I try to use the times as my system sees it, I'll get close to a second or two of delay, which is not desirable. Is there anyway I could "ask" ffmpeg what's the actual t [14:30:46 CET] <furq> brejeiro: yes but it depends what you want to do with it [14:31:21 CET] <furq> e.g. some filters have ways to use the wallclock time [14:31:21 CET] <brejeiro> furq: I'd like to break the video in chapters. Or, if it is not possible, just getting the time is enough [14:31:58 CET] <furq> how are you starting the recording [14:34:03 CET] <brejeiro> via command line... [14:34:19 CET] <brejeiro> It runs in the background. Do you need the full command line? [14:34:34 CET] <furq> no but if it's a script then you could presumably just get the wallclock time in there [14:34:43 CET] <brejeiro> ffmpeg -f gdigrab -i desktop -vcodec libx264 -y -force_fps -framerate 30 myvideo.mp4 [14:35:31 CET] <brejeiro> Well, it is. The problem is that from the point I send the command, to the point that it actually starts recording, I loose a couple of seconds... [14:35:41 CET] <brejeiro> I'm actually doing that... [14:36:44 CET] <lethyr> streamlink -o - <url> best | ffmpeg -i mixer.ts -i - -filter_complex "[0:v] [0:a] [1:v] [1:a] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" output_test.ts [14:36:45 CET] <furq> oh right the filename is a few seconds early [14:36:53 CET] <furq> there is a -strftime option but it only works for certain muxers [14:36:54 CET] <lethyr> this complains about the resolutions not matching [14:37:54 CET] <furq> apparently -strftime only works for hls/segment/image2 muxers [14:38:28 CET] <furq> -strftime 1 "%Y%m%d%H%M%S.mp4" if you happen to be using any of those [14:38:59 CET] <brejeiro> I'll give them a try! Thanks! [14:40:02 CET] <lethyr> I see this discusses the error I'm getting https://stackoverflow.com/questions/37327163/ffmpeg-input-link-in1v0-parame… [14:40:19 CET] <lethyr> however their issue is the sample aspect ratio doesn't match. mine is that the size (resolution) doesn't match. [14:40:35 CET] <lethyr> can I modify the best answer there to solve my problem? [14:40:36 CET] <furq> lethyr: you'd need to scale it before concat [14:40:51 CET] <furq> you can do pretty much the same thing as that SO answer, just replace setdar with scale [14:41:04 CET] <furq> or scale2ref rather [14:42:31 CET] <furq> -i intro.ts -i - -lavfi "scale2ref[tmp];[tmp][1:v]concat=n=2:v=1:a=1" out.ts [14:44:51 CET] <lethyr> "Stream specifier ':v' in filtergraph description scale2ref[tmp];[tmp][1:v]concat=n=2:v=1:a=1 matches no streams." [14:45:05 CET] <lethyr> I'm not familiar enough with filters to know what that means [14:48:03 CET] <raytiley> Is there a reason release_request_pad api is different on a audiomixer vs compositor? https://www.irccloud.com/pastebin/qykYyNbZ/api_difference.rs [14:48:59 CET] <raytiley> nevermind... see my typo [14:58:34 CET] <lethyr> streamlink -o - https://www.youtube.com/c/mtcdood/live best | ffmpeg -i mixer.ts -i - -lavfi "[1:v][0:v]scale2ref[wm][base];[wm]setsar=1[wm];[base][wm]concat=2" output.flv [14:58:43 CET] <lethyr> this command appears to work. do you see any problems with it? [15:00:41 CET] <furq> it looks fine but that's scaling the stream to the size of your intro video [15:00:47 CET] <furq> i assume you want it the other way round [15:00:57 CET] <furq> although if it's for youtube then maybe not [15:04:18 CET] <lethyr> hmm. [15:04:35 CET] <lethyr> nah I want it to scale the intro to the stream [15:05:10 CET] <furq> just get rid of [1:v][0:v] then [15:05:34 CET] <furq> or swap them around, but either should work [15:12:03 CET] <lethyr> I get messages like "Buffer queue overflow, dropping.= 889.8kbits/s speed=0.744x" [15:12:19 CET] <lethyr> it looks like I might be able to fix that with advice from https://stackoverflow.com/questions/39574032/ffmpeg-error-buffer-queue-over… [15:34:43 CET] <lethyr> I notice that that command results in the intro's audio being overlapped with the stream, but the intro's video is not concatenated [15:35:43 CET] <kepstin> lethyr: the concat filter by default only does the video streams, you have to provide additional options to set the number of audio streams [15:36:08 CET] <lethyr> ah I didn't realize that [15:39:31 CET] <lethyr> regarding the advice given about which input is being scaled to which, simply removing or reversing the two portions of the filter does not perfom as expected [15:39:49 CET] <faLUCE> I don't understand why the matroska muxer, at least in H264 case, wants so many params from the avocedcontext. For example: if I don't set the bitrate even on the muxer, the stream can't be muxed [15:39:50 CET] <lethyr> doing either results in the intro's video simply not being concatenated to the beginning of the stream [15:40:09 CET] <furq> oh right [15:40:19 CET] <furq> lethyr: scale2ref only produces one output iirc [15:40:31 CET] <furq> so get rid of [base] and replace [base][wm] with [0:v][wm] [15:42:53 CET] <lethyr> that doesn't have any effect on the result [15:43:13 CET] <lethyr> I should point out that I've started outputting in .flv for these tests by the way [15:43:29 CET] <lethyr> ultimately I'll need something YouTube will happily accept as an upload [15:44:18 CET] <lethyr> that particular command won't work with flv because "at most one video stream is supported in flv" [15:44:18 CET] <kepstin> youtube happily accepts basically anything [15:44:46 CET] <lethyr> I'll check a mpegts file real quick, for some reason I thought they wouldn't take them [15:45:16 CET] <kepstin> furq: lethyr: scale2ref does actually produce two outputs [15:47:25 CET] <kepstin> the first input to scale2ref is the video to be scaled, the second input is the reference video. The first output is the newly scaled video, the second output is a pass-through of the reference video. [15:48:06 CET] <furq> fun [15:48:10 CET] <furq> not sure what's going on there then [15:49:58 CET] <lethyr> YouTube will happily accept mpegts [15:50:02 CET] <lethyr> that simplifies one thing [15:52:06 CET] <lethyr> https://pastebin.com/raw/1DP3kxXY [15:52:18 CET] <lethyr> here are two commands and their results [15:53:32 CET] <lethyr> actually the stream looks bad in both results [15:57:27 CET] <kepstin> lethyr: of course the video looks bad, you haven't set an output codec or options [15:57:36 CET] <kepstin> it's probably using terrible mpeg2 settings or something [15:57:49 CET] <lethyr> aha [15:58:13 CET] <lethyr> I hoped it'd use the settings of the standard input [15:58:25 CET] <lethyr> but glad to understand why it looks like that [15:59:09 CET] <kepstin> there's no way to know what settings the input was encoded with in general, and even if you're using the same settings and encoder, you'll lose quality due to generation loss with lossy codecs. [15:59:26 CET] <lethyr> hmm [15:59:45 CET] <kepstin> lethyr: anyways, your first command in that paste looks roughly correct, except that you haven't set the concat filter to concat the audio streams [16:00:08 CET] <lethyr> yeah [16:07:23 CET] <lethyr> I've been trying to find someone using both concat with audio and scale2ref at once but I can't find any examples [16:07:48 CET] <kepstin> the scale2ref usage doesn't change how concat works... [16:08:24 CET] <kepstin> concat in this case would be "[firstvideo][firstaudio][secondvideo][secondaudio]concat=n=2:v=1:a=1" [16:09:27 CET] <lethyr> ffmpeg -i intro.ts -i - -lavfi "[0:v][0:a][1:v]scale2ref[1:a][wm][base];[wm]setsar=1[wm];[base][wm]concat=n=2:v=1:a=1" output.ts [16:09:48 CET] <lethyr> this does not work because I don't know where to put the audio in reference to the scaling and aspect ratio synching [16:09:57 CET] <kepstin> lethyr: why are you adding an audio intput to scale2ref? that filter can't take audio [16:10:03 CET] <kepstin> you need to pass the audio to the concat filter [16:10:15 CET] <lethyr> you seem to be under the impression I know what I'm doing [16:10:21 CET] <lethyr> I'm not sure what gave you that idea [16:11:51 CET] <lethyr> moving [1:a] before scale2ref yields the same result [16:11:55 CET] <kepstin> assuming your first example from your paste has the video in the correct order, you'd want "[0:v][1:v]scale2ref[wm][base];[base][1:a][wm][0:a]concat=n=2:v=1:a=1" [16:13:43 CET] <kepstin> (actually, how does that even work? i'd think your command should give an error since you're using the same link name as an input and an output on one filter) [16:16:49 CET] <lethyr> that still doesn't concatenate the video [16:17:10 CET] <lethyr> I need the intro with its audio to play, then the stream with its audio to play [16:17:58 CET] <kepstin> ah, i guess the order is wrong then [16:18:17 CET] <kepstin> change it to '[wm][0:a][base][1:a]' before the concat filter then [16:18:22 CET] <Dragas> In what cases does can be stream's codec information be missing? [16:18:59 CET] <kepstin> Dragas: no idea, need more context. [16:18:59 CET] <lethyr> that modification plays the intro's audio over the stream's video [16:19:26 CET] <Dragas> With ffprobe and ffmpeg tools my rtsp stream information is reported just fine, but when I try to set it up with AVStream, the reported codec is NULL [16:19:51 CET] <kepstin> lethyr: oh, huh, still wrong. there's only so many permutations, it should be easy to fix that with a little logical thinking and problem solving. [16:20:10 CET] <lethyr> yeah [16:20:29 CET] <lethyr> I do want to bring up these messages I'm seeing though: "[Parsed_concat_2 @ 0x55bdb1953e60] Buffer queue overflow, dropping.=14807.6kbits/s speed=0.474x" [16:20:46 CET] <Dragas> https://i.imgur.com/3QaIoz9.png [16:20:51 CET] <Dragas> For example [16:20:54 CET] <kepstin> lethyr: those messages are happening because the wrong video and audio streams are paired, they'll go away once you fix that [16:21:00 CET] <lethyr> ah ok [16:21:16 CET] <lethyr> I just wanted to make sure it wasn't "your machine is too slow to do this, don't waste more time" [16:23:55 CET] <lethyr> [wm] here is the intro after it's been scaled right? [16:24:07 CET] <lethyr> and [base] is just the standard input being passed to ffmpeg? [16:24:23 CET] <kepstin> the first input to scale2ref is scaled and sent to the first output [16:24:32 CET] <kepstin> the second input to scale2ref is passed through to the second output [16:27:36 CET] <kepstin> Dragas: hard to say without seeing your code. some information might not be populated until you call avformat_find_stream_info, but I'm not familiar enough with rtsp to know if that's the issue. [16:27:39 CET] <lethyr> and "[wm]setsar=1[wm]" is just taking [wm], applying an aspect ratio of 1, and passing the output to the same variable name? [16:28:01 CET] <kepstin> lethyr: no, since you can't have an input and output with the same name. I have no idea what that's doing. [16:28:11 CET] <kepstin> maybe nothing? i'd expect it to be an error, but... ? [16:28:19 CET] <lethyr> makes sense to try removing it then [16:28:54 CET] <Dragas> Hold on, i'll post how I open up my stream. [16:29:03 CET] <kepstin> the scale2ref should be taking care of making sure sar matches, i think? if not, you might have to put it back, but make sure you use different name for the output (and update the concat filter to use the new name in the input) [16:30:14 CET] <lethyr> I admit I didn't understand what any of this was supposed to do an hour ago but it *looks* like it should work [16:34:48 CET] <lethyr> even the command that I documented as concatenating the video doesn't do it anymore [16:35:04 CET] <Dragas> kepstin: https://pastebin.com/e20NgqTm [16:35:18 CET] <Dragas> I'm using the following snippet to open up stream information [16:35:22 CET] <Dragas> the stream, rather [16:38:11 CET] <lethyr> ffmpeg -y -i intro.ts -i - -filter_complex "[0:v] [0:a] [1:v] [1:a] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" output.ts [16:38:52 CET] <lethyr> this will work if the resolutions are the same [16:41:36 CET] <lethyr> can I work from here instead of starting completely over with a new command? [16:42:03 CET] <kepstin> lethyr: yeah, that would be where you start from. [16:42:07 CET] <lethyr> I tried this but I'm jumbling up the scale and the concat [16:42:09 CET] <lethyr> ffmpeg -y -i intro.ts -i - -filter_complex "[0:v][1:v]scale2ref[vid0][vid1];[vid0][vid1][0:a][1:a]concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" output.ts [16:42:25 CET] <faLUCE> do you know if is there a function for obtaining the header of a muxer? I'm forced to use av_write_frame and() for the first packet but then I don't know how to separate the header part from the muxed frame part.... [16:42:42 CET] <faLUCE> do you know if is there a function for obtaining the header of a muxer? I'm forced to use av_write_frame() for the first packet but then I don't know how to separate the header part from the muxed frame part.... [16:42:44 CET] <kepstin> lethyr: you changed the order of the inputs to the concat - it's first video, first audio, second video, second audio [16:44:06 CET] <kepstin> faLUCE: why do you think you want that info? at that point, the muxer output is an opaque bytestream. [16:44:49 CET] <faLUCE> kepstin: I have to put the header at the beginning of each http stream that I produce with the same muxer [16:45:26 CET] <kepstin> faLUCE: you should really just run a separate muxer for each stream. [16:45:32 CET] <faLUCE> kepstin: I mean, I send muxed date to a custom streamer, made without ffmpeg, and I need the header at the beginning [16:45:34 CET] <lethyr> thanks @kepstin that works perfectly except for the poor quality which you already mentioned the reason for [16:46:33 CET] <faLUCE> kepstin: that's not possible [16:46:47 CET] <kepstin> lethyr: yeah, to fix the quality start by adding "-c:v libx264" to your output to get a reasonable video codec, then see https://trac.ffmpeg.org/wiki/Encode/H.264 for details about options. [16:48:25 CET] <kepstin> faLUCE: what container are you using? [16:48:48 CET] <faLUCE> kepstin: matroska [16:49:35 CET] <faLUCE> kepstin: I wonder if is there a way to pick it in the opaque priv_data [16:50:02 CET] <kepstin> faLUCE: but yeah, no way to do this in general. the closest thing to a "proper" way would be to parse the muxer output to find the header, but imo you should really use separate muxers. [16:51:01 CET] <kepstin> faLUCE: i assume this is a live streaming application where you're continuously encoding video, but whenever someone connects to http they get the stream starting at the time they connected? [16:51:18 CET] <faLUCE> kepstin: exactly [16:52:01 CET] <faLUCE> kepstin: I used a bad hack: I muxed a dummy packet (without data) soon after write_header [16:52:18 CET] <faLUCE> so I got the header from that, but it's not a proper way [16:52:24 CET] <kepstin> faLUCE: yeah, i'd do that by creating a new muxer when someone connects, and start muxing encoded video packets at the point where they connected (but note that you will probably need to cache the codec initialization data to feed to the new muxer) [16:53:32 CET] <faLUCE> kepstin: this is overkill [16:53:47 CET] <lethyr> ... why is ffmpeg taking two 1080p videos and outputting a 240p video? [16:53:49 CET] <lethyr> that's why it looks so bad [16:54:09 CET] <kepstin> lethyr: oh, right, you need to set some options on the scale2ref filter :) [16:54:19 CET] <lethyr> ok I'll look it up [16:55:15 CET] <kepstin> i'm surprised it's not the default, but "scale2ref=w=iw:h=ih" should do it [16:55:35 CET] <kepstin> hmm, but that's weird, that shouldn't be scaling your other input video at all [16:55:59 CET] <kepstin> lethyr: i suspect your second input isn't actually 1080p like you think it is [16:56:07 CET] <kepstin> lethyr: ffmpeg's output will tell you [16:56:09 CET] <lethyr> LOL [16:56:16 CET] <kepstin> (if you can't read it, please pastebin the entire output) [16:56:19 CET] <lethyr> remember when I said it doesn't work when the resolution changed [16:56:37 CET] <lethyr> I specifically started grabbing the lowest possible resolution to make sure it worked with different resolutions [16:56:44 CET] <faLUCE> it's very strange the libavcodec doesn't have at least an opaque field where to get that header [16:57:25 CET] <kepstin> faLUCE: libavcodec has nothing to do with it, and libavformat produces opaque muxed output, you're supposed to demux it again if you want data from it. [16:58:26 CET] <kepstin> breaking apart and mashing together output after muxing requires that you know how to parse the muxed output [16:58:39 CET] <kepstin> (it's not even necessarily possible in all formats) [16:59:27 CET] <Dragas> kepstin: well apparently the issue was caused by av_register_all, which is deprecated [16:59:51 CET] <kepstin> Dragas: shouldn't cause an issue. with old ffmpeg that's required or nothing works, with new ffmpeg it does nothing. [17:00:02 CET] <Dragas> hmm [17:00:14 CET] <Dragas> to be honest it's the only thing i removed and it started working [17:03:22 CET] <faLUCE> kepstin: well, I could demux, then. but in which way? with av_read_frame() I could get again the packet but how could I get the header? [17:03:45 CET] <kepstin> faLUCE: you can't, ffmpeg is not designed to do this. [17:03:53 CET] <lethyr> "frame= 1012 fps= 21 q=0.0 size= 12456kB time=00:00:16.86 bitrate=6050.4kbits/s speed=0.352x" since this is live stdin what are the ramifications of ffmpeg not being able to process the video at or above 1.0x? [17:04:06 CET] <lethyr> is it using memory, losing the video data, something else? [17:04:35 CET] <kepstin> lethyr: eventually the pipe buffer leading into the ffmpeg will fill, and then it will cause whatever application is sending video to block [17:04:46 CET] <kepstin> what happens then depends on the application sending stuff to ffmpeg [17:05:13 CET] <faLUCE> there should be a way [17:05:41 CET] <kepstin> faLUCE: yes, it's possible. using your own knowledge of how matroska is constructed, you can identify the header in the muxer output bytestream and save it your self. [17:06:16 CET] <lethyr> lol this machine can't even keep up with a CRF of 51 [17:06:35 CET] <lethyr> I guess I wasted 3 hours figuring out how to do this on the fly only to learn that I can't do this on the fly [17:07:53 CET] <kepstin> lethyr: are you using a raspberry pi or something? :/ [17:08:13 CET] <faLUCE> kepstin: I wonder if is there a way to av_write_frame() on a dummy packet [17:08:13 CET] <kepstin> note that crf doesn't make a big difference on encoding speed - change the "-preset" option to do that [17:08:20 CET] <faLUCE> a safe way, I mean [17:08:49 CET] <lethyr> no this is a VPS from OVH [17:09:10 CET] <kepstin> faLUCE: why can't you use the avformat_write_header() anyways? [17:10:03 CET] <kepstin> it might work well enough for your use case if you're luck, although it depends on muxer implementation (some don't write anything until you write a frame) [17:10:13 CET] <faLUCE> kepstin: because in order to produce the header, AFAIK/IIRC it needs to call av_write_frame() with a new packet [17:10:56 CET] <kepstin> faLUCE: anyways, ffmpeg is not designed to do this, and there's no ffmpeg api to do this. if you really want to mess around with the output bytestream after it's muxed, then you have to mess around with the output bytestream after it's muxed by yourself. [17:11:51 CET] <faLUCE> I understood that ffmpeg is not designed to do that, but I wonder if is there a way to send a "dummy packet" to the muxer, safely [17:11:56 CET] <faLUCE> so I can get the header [17:12:13 CET] <kepstin> faLUCE: if there's a way to send a dummy packet safely, then the muxer would be free to ignore it and do nothing. [17:12:54 CET] <faLUCE> the muxer would ignore the packet, but not what preceeds the packet [17:13:06 CET] <kepstin> faLUCE: the "proper" way to do what you want with ffmpeg is to use separate muxers for each output stream. If you want to hack up the bytestream from one muxer, you have to do that yourself. [17:13:24 CET] <kepstin> faLUCE: nothing preceeds the packet tho [17:13:35 CET] <kepstin> faLUCE: the muxer generates the header and writes it whenever it feels like doing that [17:14:15 CET] <kepstin> the way it works is "avpacket -> muxer -> opaque bytestream of muxed data" [17:15:27 CET] <faLUCE> kepstin: ok. do you know if the muxer safely discards too non keyframes soon after the header? [17:15:33 CET] <faLUCE> (h264) [17:16:09 CET] <kepstin> faLUCE: you should discard them yourself before muxing [17:16:27 CET] <faLUCE> I see. [17:17:16 CET] <lethyr> with a CRF of 28 and the ultrafast preset my bitrate has slowly increased and just passed 9K [17:17:45 CET] <lethyr> as a result I started at 1.4x and have dropped to 0.7x [17:17:47 CET] <faLUCE> anyway, there should be some hack for obtaining the header using some deep function of libavcodec... instead of parsing the data [17:17:56 CET] <lethyr> how can I reign in ffmpeg so it behaves sanely [17:17:56 CET] <kepstin> lethyr: bitrate has nothing to do with speed. [17:18:13 CET] <kepstin> lethyr: many vps systems have cpu limits, where if you use a lot of cpu for a while, they start throttling you [17:18:22 CET] <kepstin> lethyr: recommend you get a better server. [17:18:26 CET] <lethyr> bitrate does have to do with speed. as the bitrate has gone up the speed has gone down. [17:18:35 CET] <kepstin> lethyr: probably coincidence [17:18:40 CET] <lethyr> lol [17:18:53 CET] <lethyr> you think it's a coincidence that processing literally more data might take longer [17:19:15 CET] <kepstin> "ultrafast" mode turns off much of the processing that depends on output video size [17:19:54 CET] <lethyr> looks like it stabilized at 10.8K [17:20:01 CET] <kepstin> ("cabac", an arithmetic encoder run over the output bitstream, can cause h264 encoding to be slower at higher bitrates, but cabac turns off with ultrafast mode) [17:20:20 CET] <lethyr> the source video is nowhere near that. [17:20:30 CET] <lethyr> it makes no sense for it to be doing that [17:20:49 CET] <kepstin> lethyr: it's being encoded from scratch (raw video), the source video has nothing to do with it [17:22:13 CET] <kepstin> lethyr: for your use case, you might actually want to run a separate ffmpeg command to attempt to encode the intro with matching settings to the real video, save that to a file, then do a plain file-level concatenation of the newly scaled intro video and the pass through video [17:22:23 CET] <kepstin> lethyr: rather than re-encode the entire thing [17:22:58 CET] <lethyr> the reason I was trying to do it on the fly was because I didn't want to use 50 gigs of disk space to process files [17:23:01 CET] <kepstin> lethyr: that'll require more coding on your end, or pre-generating a bunch of intro videos for different settings. [17:23:08 CET] <kepstin> you only need to store the intro videos... [17:27:27 CET] <kepstin> lethyr: to do this, you'd just pre-run some ffmpeg commands like "ffmpeg -i intro.ts -s 320x240 -c:v libx264 intro-240.ts" to make the various intro video sizes, then replace the ffmpeg command you're doing now with "cat intro-240.ts - >output.ts" [17:28:05 CET] <kepstin> you'd have to look at the exact specs of the input video - it might need some extra options to set a specific audio codec and maybe certain stream ids. [17:30:29 CET] <lethyr> I've been up for 34 hours. I'll decide if I really want to deal with it after some sleep. [17:51:44 CET] <ncouloute> Is there a easy way to parse the -vf "showinfo" data in windows? I'm having to rely on it because ffprobe,ffms2 is providing me with different frame+timestamps than ffmpeg showinfo. I'm guessing it has something to do with the built in deinterlacing that ffmpeg is doing. Although when I specify my own deinterlacer I'm unable to get it to maintain the timestamps. Is there a way to deinterlace and maintain the timings of [17:51:45 CET] <ncouloute> the frames for vfr interlaced content. Any idea what is going on? Would I be better off learning and using the ffmpeg api to get this info in a easier to use format? [18:04:49 CET] <JEEB> ncouloute: ffmpeg.c by default pokes the timestamps [18:04:52 CET] <JEEB> you can see it with -debug_ts [18:05:16 CET] <JEEB> you can try and minimize ffmpeg.c's pokings with -vsync passthrough -copyts [18:05:41 CET] <JEEB> and yes, depending on your use case I would recommend utilizing either ffms2's or FFmpeg's API [18:13:32 CET] <brimestone> I'm doing a -filter_complex [0]scale=480:-1:flags=fast_bilinear,split=2[h264][dnx36] -map [h264] <output codec and path> and I think I'm missing the audio... [18:13:50 CET] <brimestone> How do I copy the audio over? [18:13:58 CET] <DHE> -map 0:a (typically) [18:14:57 CET] <brimestone> Let me try that.. thanks [18:14:59 CET] <DHE> so I imagine something like: ffmpeg -i $INPUTFILE -filter_complex $THAT_FILTER -map [h264] -map 0:a $H264_OPTS h264.mp4 -map [dnx36] -map 0:a $DNX36_OPTS dnx36_output [18:20:05 CET] <brimestone> Seems to have worked... thanks [18:30:22 CET] <ncouloute> Use Case: Trying to find a given frame location in the original file in the output file after its been converted. You would think it would be at the same timestamp as it was originally but apparently after its been read by ffmpeg the timestamps shifts somewhat for whatever reason. So I'm stuck with getting the showinfo output and trying to parse that. Maybe its easier to get that info using the api? Sounds like -copyts [18:30:22 CET] <ncouloute> might help going to try that. Cant use vsync passthrough because I'm actually trying to change the file to cfr at 60000/1001. [18:32:44 CET] <JEEB> you can do that in the filter chain, though? [18:33:04 CET] <JEEB> as opposed to -r 60000/1001 after input on the ffmpeg.c cli :P [18:33:23 CET] <brimestone> Looks like -map 0:a errors out if source input doesn't have audio.. [18:33:26 CET] <JEEB> yes [18:33:39 CET] <JEEB> there's a way to say "map, if available" but normal map requires you to have the streams [18:33:52 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html [18:33:56 CET] <JEEB> might have been a question mark or something [18:34:03 CET] <JEEB> ctrl+F'ing "-map" in that should bring something up [18:40:05 CET] <brimestone> Like an Optional in SwiftLang :) I like it! [21:09:15 CET] <furq> so i'm reading about this google stadia thing, and [21:09:17 CET] <furq> Stadia is perfectly playable and presentable here, but it's clear that there is a noticeable visual hit when the encoder - which is a bespoke Google creation, and not a part of the AMD GPU - is presented with more a more detail-rich, fast-moving scene process. [21:09:24 CET] <furq> anyone have any speculation to what this "bespoke Google creation" is [21:10:05 CET] <JEEB> something something gaikai 2010-2011 something something points at the clouds [21:10:24 CET] <furq> i'm going to guess it's some kind of vp9 asic, but who knows [21:10:39 CET] <furq> also yeah obviously the console will fail for the same reason all the others did [21:11:05 CET] <JEEB> gaikai actually got bought proper and not "we just want the patents please" [21:11:14 CET] <JEEB> (which is what happened with onlive three years later) [21:11:18 CET] <furq> yeah onlive is ps live now [21:11:21 CET] <JEEB> no [21:11:33 CET] <furq> not the service but sony acquired the company and then launched ps live [21:11:35 CET] <JEEB> gaikai is what became ps live and onlive just had its patents bought [21:11:39 CET] <furq> oh really [21:11:41 CET] <JEEB> yes [21:11:47 CET] <JEEB> I just learned of it as well and laughed out loud [21:11:58 CET] <JEEB> because onlive was the one that was marketing stuff while gaikai did tech [21:12:10 CET] <furq> one of my friends went to some gamers conference thing where they launched onlive in the uk [21:12:11 CET] <JEEB> sony bought gaikai in 2012 (as the whole team) [21:12:29 CET] <furq> he had been dragged along by his friend and his friend got a free demo console and then immediately went and paid full MSRP for three more [21:12:48 CET] <JEEB> and according to wikipedia onlive saw its closure after its patents got bought by sony in 2015 [21:12:54 CET] <furq> meanwhile my friend got his free one home and found he couldn't change the region from US-West so he was getting 300ms input lag on everything [21:13:28 CET] <JEEB> gaikai also seemed to have a much more realistic business position. they were doing promotions and time limited demos [21:13:45 CET] <JEEB> instead of trying to sell/rent games over video to people [21:14:19 CET] <JEEB> anyways, gaikai is why we have intra refresh and reference frame invalidation in x264 [21:14:37 CET] <furq> anyway this article claims it's 25mbit 1080p30 (no 60fps support at all) and it still looks blocky in complex scenes [21:14:48 CET] <shibboleth> isn't this like doing "web-based MS Office replacement" [21:15:11 CET] <shibboleth> doing heavy stuff in js in browser will be slower than native code [21:15:11 CET] <furq> no because google docs doesn't become unusable due to input lag [21:15:34 CET] <furq> or stream your document to you as a video with a too-low bitrate [21:15:39 CET] <shibboleth> as will gaming "by vnc/rdp/whatever" [21:15:44 CET] <tdr> JEEB, i met with them on-site about a year before they were acquired. some very tallented folks there. [21:16:02 CET] <furq> the code execution has nothing to do with it, it's just running native code on a dedicated remote machine [21:16:04 CET] <JEEB> :) [21:16:12 CET] <furq> the problem is getting the video output to you in a reasonable time at a reasonable quality [21:16:18 CET] <furq> that's what killed all the other companies that tried this [21:16:37 CET] <furq> none of them had anything like google's infra or resources, of course [21:17:03 CET] <furq> but the next problem is home internet connections, which still aren't good enough for a lot of people [21:17:10 CET] <shibboleth> wifi [21:17:13 CET] <furq> that as well [21:17:28 CET] <furq> anyway i got sidetracked here, i just wanted to talk about google's bespoke video encoder [21:18:08 CET] <JEEB> no idea what it is, but it's most likely some fast enough implementation of a standard codec hopefully in low latency yet compressing mode [21:18:13 CET] <JEEB> like periodic intra refresh [21:18:27 CET] <furq> i assume it's an asic just because of the way DF phrased it [21:18:42 CET] <furq> if it's a software encoder that isn't "we made libvpx not suck ass" then i'm going to be unhappy about it [21:19:01 CET] <furq> and if it's an entirely new codec then wtf [21:19:10 CET] <JEEB> unlikely a new codec [21:19:28 CET] <JEEB> if they used VP9 they might have tried to hack something like intra refresh into it [21:19:40 CET] <furq> it'll probably turn out to be a patched x264 or something [21:19:45 CET] <JEEB> although realistically yes [21:19:49 CET] <JEEB> x264 or so [21:19:56 CET] <JEEB> because you need users to decode the video [21:20:26 CET] <shibboleth> and somehow overcome the latency of wifi+dsl/docsis [21:20:29 CET] <furq> yeah there's no actual box to decode it, it just goes straight to a device [21:20:34 CET] <shibboleth> anyone seen "valley of the boom"? [21:20:36 CET] <furq> so it probably has to be h264 just for compat [21:21:07 CET] <furq> i sort of wonder if they made a bespoke asic for that [21:21:25 CET] <furq> or if the guy giving this interview is just full of marketing shit [21:22:23 CET] <furq> i don't suppose it matters, they're probably never going to release it [21:28:23 CET] <Mavrik> Google kinda uses VP9 a lot these days tho [21:28:52 CET] <Mavrik> Even on devices which have H.264 HW decoders and no VP9 decoder [21:30:03 CET] <furq> yeah i only thought vp9 because they're so invested in it and doubtless they want to avoid fees [21:30:14 CET] <furq> i just don't know if it's practical [21:30:17 CET] <JEEB> anyways, we'll see when the bits start flying :P [21:31:28 CET] <Mavrik> Did anyone manage to take a closer look when they were running the Project Stream preview? [21:32:05 CET] <furq> all the hands-on stuff i've seen hasn't mentioned the codec [21:32:26 CET] <furq> which makes me suspect it is h264, otherwise google would probably be bragging about it [21:45:45 CET] <ElePHPhant> Can ffmpeg be used to remove all metadata from an OGG? I tried multiple commands from shitty web articles but none of them actually worked. [21:46:16 CET] <ElePHPhant> The purpose is just for my own use, to hide the title from myself, in order to avoid spoilers. [21:46:26 CET] <ElePHPhant> It's not to steal people's work, if that's what you suspect. [21:47:55 CET] <M6HZ> Hello, I would like to know if it possible to precisely cut a movie with -ss and -t without re-encoding. I always have an error of about 1 sec when I use them in conjunction of -c copy. Here is what the man page states -ss: «in most formats it is not possible to seek exactly [...] When transcoding and -accurate_seek is enabled [...] this extra segment [...] will be decoded and discarded. When doing stream copy or when -noaccurate_seek i [21:49:42 CET] <pink_mist> M6HZ: no, you need to re-encode to get exact cutting [21:50:30 CET] <ElePHPhant> That re-encoding thing has destroyed so many video files... [21:50:40 CET] <ElePHPhant> I wasn't even aware that video editors did this for the longest time. [21:50:56 CET] <M6HZ> pink_mist: Alright, do you know precisely why this is not possible? [21:50:58 CET] <ElePHPhant> I assumed that "obviously", if I just cut away parts, it would not re-encode anything, but simply remove those portions. [21:51:56 CET] <pink_mist> M6HZ: because of the different types of frames; without re-encoding you can only cut on a certain type of frame, which only comes around occasionally. the subsequent frames rely on that frame as their basis [21:52:07 CET] <pzich> M6HZ: basically, videos aren't just stored as a series of pictures, but a few pictures (key frames) and updates on those images [21:52:31 CET] <pzich> M6HZ: so if you cut just after that key frame, there's nothing to base the next few images on. [21:53:13 CET] <M6HZ> pink_mist, pzich : Alright, really interesting! [21:53:18 CET] <ElePHPhant> ... except that it already has that data? [21:53:37 CET] <pzich> well it did, but you're trying to cut it off! [21:53:49 CET] <ElePHPhant> So re-encode those little segments? [21:54:00 CET] <pink_mist> but then you're not copying [21:54:12 CET] <ElePHPhant> Any idea about my own question? [21:54:31 CET] <pink_mist> I have no clue about ogg [21:54:55 CET] <pzich> yeah I've googled around to remove this kind of stuff off of MKVs or MP4s and it worked, but I don't work with OGG much [21:57:25 CET] <furq> ElePHPhant: did you try -map_metadata -1 [21:58:21 CET] <furq> also there are tools which will only reencode the gop you need for exact cutting, but ffmpeg isn't one of them [21:58:48 CET] <furq> and by "there are tools" i mean people have posted their own github links in here and i don't remember what they are [21:59:31 CET] <furq> you can somewhat do it yourself with ffmpeg with a bit of manual labour [22:02:59 CET] <ElePHPhant> furq: ? [22:03:08 CET] <ElePHPhant> What's the command? [22:03:17 CET] <furq> -i foo.ogg -map_metadata -1 -c copy bar.ogg [22:21:20 CET] <ElePHPhant> furq: I shall try it now. [22:23:12 CET] <ElePHPhant> furq: Ah. Works. Thanks. [22:23:50 CET] <ElePHPhant> I just wish it were more straight-forward, like: -i foo.ogg --remove-all-metadata -o bar.ogg [22:23:56 CET] <ElePHPhant> But now that I know the command, I can use it. [22:55:56 CET] <net|> http://www.netpipe.ca/paste/paste.php?id=25 [22:58:13 CET] <Hello71> no. [22:59:57 CET] <faLUCE> kepstin (and others): regarding the past discussion, I'm seeing that the formats which have a .write_header function, do outoput the header in the avio context of the muxer. Then, given that the aviocontext can be flushed (avio_flush()) the the header of the muxers can be obtained without hacks.... [23:03:29 CET] <ElePHPhant> After all these years of dealing with video files and crap, I still have no clue what "mux" or "muxing" means. [23:04:27 CET] <JEEB> think of it like this [23:04:41 CET] <JEEB> 1. you have the I/O layer (reading writing, be it files or network) [23:04:57 CET] <JEEB> 2. you have the DEmuxing (demultiplexing) phase [23:05:16 CET] <JEEB> (reads the data coming from I/O and puts the stuff into streams and packets) [23:05:48 CET] <JEEB> 3. you have the decoding (decompression of compressed packets into raw frames and everything that comes with it) [23:06:02 CET] <JEEB> 4. you have possibly filtering (frames to filtered frames) [23:06:19 CET] <JEEB> 5. you have encoding (compression of frames into packets with compressed data) [23:06:39 CET] <JEEB> 5. you have muxing (multiplexing), which puts packets into streams and into some sort of format [23:06:52 CET] <JEEB> 7. you have I/O layer again [23:07:14 CET] <JEEB> so from just bunch of bytes to raw audio/video/subtitle frames and back [23:07:43 CET] <faLUCE> JEEB: I know that [23:08:11 CET] <JEEB> yup, and ElePHPhant just noted that he had no clue about what mux or muxing is :P [23:08:26 CET] <faLUCE> JEEB: ah, the answer was for ElePHPhant [23:08:28 CET] <faLUCE> :-) [23:09:22 CET] <faLUCE> IMHO the "mux" term is much more clear than encoding/multiplexing etc. [23:09:48 CET] <faLUCE> in fact, the muxers (IMHO) should be called, for example, mpegtsmux/demux.c [23:09:53 CET] <faLUCE> not enc/dec [00:00:00 CET] --- Wed Mar 20 2019

1 0

ffmpeg-devel.log.20190318
by burek 19 Mar '19

19 Mar '19

[02:02:07 CET] <af-inet> hi, im new and attempting to implement animated webp decode (#4907) [02:02:52 CET] <af-inet> after some analysis, Ive concluded I need to first implement a webp demuxer, because it's currently using img2dec which doesn't seem to be able to separate multiple frames. does this sound like a correct approach? I can give more detail if necessary. [02:07:48 CET] <jamrial> af-inet: probably, yes. that's apparently what apng is doing [07:28:02 CET] <cone-277> ffmpeg 03Zhong Li 07master:15d016be30bd: lavu/qsv: allow surface size larger than requirement [13:31:34 CET] <JEEB> wow, I did think if this was the case but after checking it out it seems like timeout AVOption in udp protocol literally just is a thing to override rw_timeout with [13:32:44 CET] <JEEB> and it's always setting the value no matter if you actually set the AVOption or not, so if you try setting the timeout through rw_timeout it will get ignored [13:32:47 CET] Action: JEEB golfclaps [13:40:15 CET] <atomnuker> and I noticed twitch's ads break decoding/demuxing when mid-stream [13:41:16 CET] <atomnuker> figures, given timestamps going backwards mp4 transported over hls [13:42:48 CET] <JEEB> yes [13:43:02 CET] <JEEB> you can partially try and fixup with adding the FMT_DISCONT flag to hls.c [13:43:13 CET] <JEEB> but I heard that it doesn't always work :P [13:48:16 CET] <atomnuker> at least they apparently signal that over scte-35 (which we only support for mpegts atm) [13:48:27 CET] <atomnuker> so they could be filtered at the... muxer level [14:16:08 CET] <atomnuker> JEEB: --demuxer-lavf-o-add=fflags=+genpts+igndts also works for me [14:17:13 CET] <atomnuker> though sound disappears [15:36:09 CET] <kierank> atomnuker: doubt they send scte-35 to end users [15:36:22 CET] <kierank> if they do then they are dumb as hell [16:19:59 CET] <atomnuker> kierank: https://github.com/instance01/Twitch-HLS-AdBlock [16:20:08 CET] <atomnuker> " edits the m3u8 playlist that gets requested every few seconds to simply remove segments that are marked as advertisments with SCTE-35 flags." [16:20:12 CET] <kierank> atomnuker: wow [16:20:14 CET] <kierank> just wow [16:25:11 CET] <nevcairiel> i would wager its mostly a left over from development, and is likely going to get removed, one doesnt mark ads on purpose =p [16:26:05 CET] <nevcairiel> i've personally not seen a single twitch ad, but i only use it sparingly [16:26:16 CET] <atomnuker> they only started 2 days ago I think [16:26:51 CET] <nevcairiel> perhaps, but t hat project there is from september [16:26:57 CET] <nevcairiel> so they must've at least tested it once before [18:12:26 CET] <JEEB> tmm1: cheers. hopefully the guy responds [21:15:22 CET] <JEEB> tmm1: nice [21:15:26 CET] <JEEB> we got authorship info [21:21:13 CET] <tmm1> awesome [22:45:02 CET] <nevcairiel> was there some trick to convince ffmpeg to copy data to an output file irregardless of keyframes being present? trying to make a test file here =p [22:45:22 CET] <wbs> -copyinkf or something similar [00:00:00 CET] --- Tue Mar 19 2019

1 0

ffmpeg.log.20190318
by burek 19 Mar '19

19 Mar '19

[00:21:56 CET] <net|> was wondering if anyone knows why i get mjpeg error after it compiled with it [00:22:07 CET] <net|> Cannot find a proper format for codec 'mjpeg' (id 7), pixel format 'none' (id -1) [00:22:29 CET] <net|> was trying to get this working http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live… [00:26:38 CET] <hanetzer> there we go. [00:30:14 CET] <hanetzer> so, here's a question. I have about 15m of h264 video from a security camera, and I'm trying to coerce ffmpeg into transcoding it from that to hevc using vaapi. it produces a file, but the resultant video is pretty much entirely grey with the exclusion of large noticeable motions in it (mostly static vid of an office with me in it working at a pc) [00:31:24 CET] <hanetzer> the last thing I tried was `ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device foo -i testing.mp4 -filter_hw_device foo -vf 'format=nv12|vaapi,hwupload' -c:v hevc_vaapi output.mp4 [00:31:40 CET] <JEEB> sounds like the vaapi decoding is failing [00:31:50 CET] <JEEB> try removing vaapi from before -i [00:32:11 CET] <JEEB> also I'm not sure how much you gain with that [00:32:26 CET] <JEEB> your input is probably badly compressed AVC with artifacts, and your output will be badly compressed HEVC :D [00:32:43 CET] <JEEB> (since hw encoders are meant for low latency and "it doesn't utilize CPU" use cases) [00:49:48 CET] <thebombzen> is there any reason not to use software decoding and encoding here? [01:09:17 CET] <hanetzer> yeah, the amount of streams [01:09:51 CET] <hanetzer> something like 32 video feeds, runnign throug a ryzen 2700x machine [01:10:17 CET] <hanetzer> JEEB: honestly the original video is quite clear, 1920x1080 [01:10:47 CET] <hanetzer> oh wait... [01:11:34 CET] <hanetzer> so, I was viewing the resultant encoded file via vlc (version currently unknown) on a win10 machine [01:11:55 CET] <hanetzer> however, it plays back fine on vlc-3.0.6-r1 on my gentoo box [01:28:27 CET] <dongs> jeeb, nice [01:28:33 CET] <dongs> thats the 100meg .tlv sample then [01:28:38 CET] <dongs> since it was from channel 881 [01:30:19 CET] <JEEB> yea [01:30:36 CET] <xxxmaker> hi everybody i work in adult industry [01:30:49 CET] <dongs> what a coincidence, me too [01:32:45 CET] <xxxmaker> dongs usa or europe? or somewhere else [01:33:11 CET] <JEEB> dongs: added a bit more handling of the descriptors http://up-cat.net/p/2865cb7d [01:33:38 CET] <JEEB> although I guess the network side of things is less interesting :P [01:34:16 CET] <dongs> yeah for a single stream it doesnt matter. not like you're gonna use this info to find other muxes/channels [02:13:57 CET] <ossifrage> hanetzer, try doing the conversion without any hardware accel and see how it looks [02:14:47 CET] <hanetzer> ossifrage: will do, though I'm currently in a 4hr crunch to finish some homework [02:20:20 CET] <hanetzer> ossifrage: and I'll have to test it on the same hardware which I'm away from (since my linux vlc can read it, I must assume its the windows one that's the problemish for now) [02:22:07 CET] <ossifrage> hanetzer, depending on the camera SOC, I suspect you'll find that the encoder on the camera is better then what you get out of your gpu [02:23:22 CET] <hanetzer> its a hi3521a from hisilicon, with nextchip ahd stuff [02:23:38 CET] <ossifrage> hanetzer, ah I'm working on firmware for a hi3519a camera right now [02:24:06 CET] <hanetzer> ossifrage: oh nice. I'm actually fairly knowledgeable about those; are you talking about the mpp kernel modules/userspace libs? [02:24:37 CET] <ossifrage> Userspace stuff, I don't work for hisilicon [02:24:39 CET] <hanetzer> as in, foss drivers? because if so, do tell and I'd be more than willing to help :D [02:24:42 CET] <hanetzer> nor I. [02:25:02 CET] <hanetzer> I just own a fair amount of their chinesium consumer electronics [02:25:05 CET] <ossifrage> I'm doing an opensource firmware replacement project [02:25:24 CET] <hanetzer> nice, got a repo? [02:25:39 CET] <ossifrage> Buy a camera with the hi3519a and a support sensor and you get something that is less horrible [02:26:06 CET] <ossifrage> hanetzer, it isn't public yet, I'm still in early devel and trying to find a suitable donor camera [02:27:17 CET] <ossifrage> I only have drivers 2 sensors and the cameras you can buy (cheaply) on aliexpress all use a sensor I don't have a driver for :-( [02:27:29 CET] <hanetzer> what sensor? [02:27:45 CET] <ossifrage> The camera I have has a imx334 [02:27:59 CET] <hanetzer> k, I'll look into that. do you hang out here often? [02:28:06 CET] <ossifrage> (the SDK only has a driver for the imx290 and imx334) [02:28:27 CET] <ossifrage> hanetzer, yeah I have been [02:28:28 CET] <hanetzer> I don't follow that logic [02:28:51 CET] <hanetzer> camera has imx334 and sdk has imx334 seems like no problem [02:29:12 CET] <ossifrage> The camera I'm using was $600 and from a company that I think has gone bust [02:29:36 CET] <xxxmaker> anybody here who is video/camera expert ? [02:30:01 CET] <ossifrage> It is basically a naked eval board (and they didn't even ship it with the right cables) [02:30:51 CET] <ossifrage> (it was from Taobao, so not a good candidate for my project) [02:30:56 CET] <xxxmaker> anybody here who is expert in video production or shooting camera? [02:33:58 CET] <another> just ask your question instead of meta-questions [02:35:28 CET] <xxxmaker> another are you able to visit NSFW website [02:36:55 CET] <xxxmaker> yes or no [02:37:02 CET] <another> not really [02:37:51 CET] <xxxmaker> you cannot help me then [02:38:44 CET] <xxxmaker> anybody here who is expert in video production or shooting camera? (who is able to visit NSFW websites) ? [02:44:21 CET] <hanetzer> ossifrage: nice. have you been just repackaging their mpp or are you actually going for a full foss stack rewrite? [02:44:32 CET] <xxxmaker> anybody here who is expert in video production or shooting camera? [03:15:00 CET] Last message repeated 1 time(s). [03:15:46 CET] <dongs> xxxmaker: how many times you gonna ask that? [03:15:58 CET] <xxxmaker> till somebody says yes [03:16:10 CET] <dongs> or till you get banned, what's more likely outcome [03:16:19 CET] <dongs> i've got some 4K cams, but i'm far from expert [03:16:35 CET] <xxxmaker> dongs i see, are you able to visit NSFW website? [03:16:43 CET] <xxxmaker> dongs nice to meet you [03:17:02 CET] <dongs> I'm actually making JAV but like, it doesn't really need any skill [03:17:33 CET] <dongs> its mostly the post that takes time, blurring out all those pubic hairs [03:17:42 CET] <dongs> tracking the position and shit. [03:17:52 CET] <dongs> luckily there's j-software for windows thats designed specifically for this purpose [03:18:42 CET] <xxxmaker> how hard is it to blurr out hairs? [03:20:02 CET] <dongs> just tedious mostly [03:20:07 CET] <dongs> not hard [03:20:14 CET] <xxxmaker> is it illegal to NOT blurr them out? [03:20:19 CET] <dongs> correct [03:20:32 CET] <dongs> well, if the stuff is to be sold/rented legitimately [03:21:12 CET] <xxxmaker> japanese have weird fetishes [03:21:28 CET] <xxxmaker> that i cannot comprehend [03:23:26 CET] <xxxmaker> dongs can i post you some links [03:27:09 CET] <hanetzer> JEEB: yep, looks like vlc on the windows box is a 2.x release :P [03:27:24 CET] <dongs> what is teh question, i can probably gather it from textual description [03:28:40 CET] <xxxmaker> dongs i am just wondering why one video look ook and one video look so bad, same lighting/location [03:28:50 CET] <xxxmaker> dongs i am just wondering why one video look good and one video look so bad, same lighting/location [03:30:34 CET] <dongs> ok lets see [03:30:55 CET] <xxxmaker> i am sure you can figure out which one is which [03:31:08 CET] <dongs> . hopefully that site doesn't ban japan [03:31:17 CET] <dongs> ah it works jsut slow as balls [03:31:24 CET] <xxxmaker> dongs are you japanese? [03:32:31 CET] <dongs> man you gotta host this shit somewehre less retarded. the site is literally dead [03:32:40 CET] <xxxmaker> it's super fast here [03:33:42 CET] <xxxmaker> try using wget http://url [03:33:48 CET] <dongs> what do you think im doing [03:33:56 CET] <xxxmaker> what speed you getting? [03:34:01 CET] <dongs> none [03:34:02 CET] <dongs> Connecting to trailer-stream-ht.realitykingscontent.com (trailer-stream-ht.realitykingscontent.com)|208.99.84.114|:443... connected. [03:34:05 CET] <dongs> HTTP request sent, awaiting response... [03:34:05 CET] <dongs> its not even connecting. [03:34:19 CET] <dongs> it connected once and downloaded a ~500byte 'gateway timeout" message [03:34:26 CET] <xxxmaker> try http not https [03:34:52 CET] <dongs> that works slightly better [03:35:08 CET] <xxxmaker> how fast ? [03:35:20 CET] <dongs> 100k+- but pauses often [03:35:30 CET] <xxxmaker> that is weird [03:36:01 CET] <xxxmaker> i get 3Mbyte/s here [03:36:09 CET] <dongs> 2019-03-18 11:36:00 (56.2 KB/s) - Connection closed at byte 4388268. Retrying. [03:36:11 CET] <xxxmaker> not bit, but byte [03:36:17 CET] <dongs> yeah i mean, if you're local to the hosting sure it will be fast [03:37:07 CET] <dongs> ya now its just failing with gateway timeout. [03:37:09 CET] <dongs> man, your internet sucks [03:37:39 CET] <xxxmaker> i can try sending directly by dcc [03:37:58 CET] <xxxmaker> but i can't see that being better [03:38:23 CET] <dongs> it will download eventually i think [03:38:29 CET] <dongs> shit's slow but its moving after a few retries. [03:39:00 CET] <xxxmaker> is that normal that Asian country have hard time downloading from USA hosts ? [03:39:16 CET] <xxxmaker> is that normal that Asian countries have hard time downloading from USA servers? [03:39:39 CET] <pink_mist> very normal. this is why sites like AWS have options to have hosts in those countries [03:39:51 CET] <pink_mist> like, on both sides of the link [03:39:59 CET] <xxxmaker> pink_mist are you able to visits NSFW site? [03:40:19 CET] <pink_mist> yes, but I've got no clue about ffmpeg stuff really, so not sure what the use would be [03:40:29 CET] <xxxmaker> pink_mist what country are you in? [03:40:32 CET] <pink_mist> sweden [03:40:58 CET] <xxxmaker> pink_mist how fast can you download that [03:41:18 CET] <pink_mist> 100%[====================================================================================================>] 17.05M 9.81MB/s in 1.7s [03:41:23 CET] <dongs> xxxmaker: eva looks much better, the aubrey colors are garbage [03:41:27 CET] <xxxmaker> lol 9.81MB/s [03:41:36 CET] <pink_mist> well, because I'm on a 100Mbit link [03:41:38 CET] <xxxmaker> that's faster than mine [03:41:49 CET] <pink_mist> I bet if I was on a Gbit link it'd be faster than that [03:41:49 CET] <xxxmaker> and i am not in europe [03:42:09 CET] <xxxmaker> dongs exaclty, why is that do you think [03:42:26 CET] <dongs> yeah second link over http:// downloaded at 5.6meg here. it just sounds like whatever hosting service is beat up with traffic [03:44:50 CET] <pink_mist> second link: 100%[====================================================================================================>] 20.28M 10.3MB/s in 2.0s [03:44:58 CET] <xxxmaker> lol 10.3MB/s [03:45:05 CET] <xxxmaker> that's really fast [03:45:14 CET] <xxxmaker> but you are in europe [03:45:19 CET] <xxxmaker> how is that possible [03:45:47 CET] <pink_mist> between US and EU the links are much much faster than between Asia and US [03:46:16 CET] <pink_mist> plus it's 3:45 am here, so most people are asleep [03:46:23 CET] <pink_mist> thus a bit less network usage [03:48:30 CET] <xxxmaker> pink_mist actually iplocation is saying the ip is located in Netherland [03:48:56 CET] <pink_mist> hah, well alright, that explains it then :P [03:48:57 CET] <xxxmaker> but i don't know how accurate that info is [03:49:30 CET] <pink_mist> do note that I didn't get the same IP as dongs got ... [03:49:34 CET] <xxxmaker> pink_mist now can you view the 2 videos and tell me which one is bad and good [03:50:13 CET] <xxxmaker> pink_mist what IP did you get then? [03:51:34 CET] <pink_mist> Resolving trailer-stream-ht.realitykingscontent.com (trailer-stream-ht.realitykingscontent.com) 64.210.135.16, 64.210.135.28, 64.210.135.18, ... [03:51:48 CET] <xxxmaker> wow totally different IP than mine [03:52:36 CET] <pink_mist> I'd agree with dongs that eva looks much better [03:52:46 CET] <xxxmaker> pink_mist right, so why is that [03:52:54 CET] <xxxmaker> i am trying to figure out why [03:53:01 CET] <xxxmaker> same lighting/location [03:53:15 CET] <xxxmaker> same codec/format [03:55:20 CET] <pink_mist> if you hadn't said it was the same lighting I would have guessed on that ... but then I have no idea :/ [04:01:43 CET] <pink_mist> oh, a third one too, let me check [04:02:24 CET] <pink_mist> looks good to me [04:02:37 CET] <xxxmaker> yes exactly [04:02:53 CET] <xxxmaker> try to understand why [05:19:17 CET] <xxxmaker> anybody here who is expert in video production or shooting camera? [05:23:33 CET] <fling> xxxmaker: hey [05:23:42 CET] <xxxmaker> fling are you expert? [05:23:50 CET] <fling> also ask at #photogeeks and #photography [05:23:56 CET] <fling> What is your question? :D [05:23:59 CET] <xxxmaker> i see, thanks [05:24:09 CET] <xxxmaker> fling first, are you able to visit NSFW sites [05:24:18 CET] <fling> I am. [05:24:23 CET] <xxxmaker> good [05:25:08 CET] <xxxmaker> watch 2 videos and tell the difference [05:32:27 CET] <xxxmaker> fling ?? [05:46:44 CET] <fling> xxxmaker: where are the videos? Have I missed a link? [05:47:30 CET] <xxxmaker> fling do you see it now? [05:51:21 CET] <fling> sorry, no [05:51:31 CET] <xxxmaker> i did /notice fling [05:51:45 CET] <fling> ok see it [05:52:13 CET] <xxxmaker> sorry i typed one link twice [05:54:49 CET] <fling> xxxmaker: what do you mean by difference? :P [05:54:58 CET] <xxxmaker> did you watch both videos? [05:55:39 CET] <xxxmaker> yes or no [05:55:57 CET] <fling> Yes. [05:56:41 CET] <xxxmaker> one has good color/sharp and one has bad color/not-sharp [05:56:50 CET] <xxxmaker> can you tell which one is bad [05:57:24 CET] <fling> Both are bad [05:58:00 CET] <xxxmaker> no one is good [05:58:32 CET] <fling> the one from 2015 is better than one from 2012 [06:00:19 CET] <xxxmaker> you mean 2014 ? [06:00:21 CET] <fling> you can probably get dmc-gx7 or something even better from injapan.ru for cheap for shooting such things. [06:00:35 CET] <fling> Stop using your phone for shooting videos ;P [06:01:50 CET] <fling> I got years from the metadata. [06:02:21 CET] <xxxmaker> oh [06:03:58 CET] <fling> with micro four thirds hardware you can get a fine fast lens with wide aperture but it will still give you the deep depth of field [06:04:05 CET] <fling> xxxmaker: which is good for shooting in the dark [06:04:20 CET] <fling> xxxmaker: this way the picture will stay sharp in you will open the aperture [06:05:11 CET] <fling> s/in/if/ [06:56:00 CET] <jgb> everybody: https://www.cloudflare.com/ssl/encrypted-sni/ do you pass all 4 test : if not you have issues with security [07:59:38 CET] <jgb> i noticed ffmpeg.exe has one .exe file and has no additional .dll file or nothing. is that possible for all apps? [09:20:08 CET] <jgb> hi i am doing a survey: what is the first 5 third party application do you install after doing clean installation of windows: thanks [11:04:24 CET] <pink_mist> either: 1: linux, or if I'm going to be playing games: 1: firefox 2: cygwin 3: xplorer² 4: steam 5: cccp [11:42:49 CET] <th3_v0ice> How can I force muxer to send a packet even if its DTS is not monotonically increasing? How is FFmpeg achieving this? Because if I understand correctly from the info that FFmpeg is printing it just increaseses DTS by (int)1, in case that the packet's DTS from the input is not monotonically increasing and the packet is still sent by the muxer. In my case, I am doing the same, but muxer seems [11:42:49 CET] <th3_v0ice> to be dropping packets, nothing is written to the output. [11:44:38 CET] <DHE> that's what ffmpeg the CLI tool does. libavformat does reject it [11:52:15 CET] <th3_v0ice> I am not sure what to do then. I tried calculating precisely what the next DTS should be, but it proved that in some scenarios, variable packet duration, it cause audio sync issues. [11:52:58 CET] <th3_v0ice> What should I do then? Increase the DTS that is problematic by what amount? So it doesnt cause sync issues. [12:13:40 CET] <fling> th3_v0ice: this is interesting, tell me if you will figure out how do to this and/or if it will help. [12:28:03 CET] <dongs> Media Type 0: [12:28:04 CET] <dongs> -------------------------- [12:28:04 CET] <dongs> Audio: AAC 64000Hz 3ch 403kbps [12:28:18 CET] <dongs> JEEB: ^ some weird shit [12:28:59 CET] <JEEB> :D [12:29:10 CET] <dongs> im not sure if this is correct. hold on [12:29:12 CET] <JEEB> reminds me of some people using 3.1ch [12:29:24 CET] <JEEB> and almost every audio API then proceeding to take that in as 4ch [12:29:40 CET] <dongs> http://bcas.tv/paste/results/LxCWeK58.html [12:29:47 CET] <dongs> i donno wats going on, could be my shit busted too [12:30:02 CET] <dongs> the other guy is taking a look now to see wat i fucked up [12:41:59 CET] <dongs> Audio: AAC 64000Hz 28ch 349kbps [12:42:01 CET] <dongs> ah yes. [12:44:47 CET] <dongs> ideo: HEVC 7680x4320 59.94fps [V: hevc main 10, yuv420p10le, 7680x4320] [12:54:38 CET] <dongs> kek, mpv uses 80% cpu [12:54:42 CET] <dongs> decodign this at like 1/2 framerate [12:54:54 CET] <dongs> mpc-hc is OK tho, liek 2% [12:55:31 CET] <durandal_1707> dongs: you are not using hw decoder [12:55:48 CET] <dongs> no shit [12:56:12 CET] <dongs> which is why mpc-hc is playing it ok [12:56:20 CET] <dongs> i donno, id idnt expect mpv to decode it in harwdare [12:56:22 CET] <dongs> was just testing mostly [13:20:34 CET] <satoshi2> 2 hours later autobuild suite is still installing and compiling shit [13:20:44 CET] <satoshi2> what a hog [13:26:23 CET] <aboxer> #join gstreamer [13:32:41 CET] <BtbN> "autobuild suite" [13:32:52 CET] <BtbN> there is nothing like that ffmpeg offers, you'll have to complain to who made it [13:42:25 CET] <JEEB> dongs: hwdec=d3d11va-copy or just d3d11va should work [13:42:38 CET] <JEEB> just not enabled by default, but I think LAV doesn't enable that either [13:43:16 CET] <faLUCE> Do you know if with the current version of libavcodec I can mux (mpegts+h264) video non keyframes before muxing a keyframe? I remember that I could do that safely with 2.8.7 and, pheraps, the muxer itself discarded the non keyframes. [13:43:30 CET] <JEEB> I don't think it would care? [13:43:51 CET] <JEEB> I'd be surprised if the muxer would wait until you gave it a RAP packet (keyframe flag) [13:45:23 CET] <faLUCE> JEEB: is this info stored into "flag" field of avframe or into "key_frame" ? or both? (I don't have key_frame on av_packet) [13:46:50 CET] <JEEB> AVPacket has the keyframe flag and setting that correctly is the encoder's job [13:47:11 CET] <JEEB> since you were talking about a muxer AVFrame doesn't even relate [13:47:28 CET] <faLUCE> ok, but where is this this value? in the "flags" field? [13:47:40 CET] <faLUCE> (of avpacket) [13:48:23 CET] <faLUCE> the api doc doesn't say anything about this field [13:49:06 CET] <JEEB> yes, it has bit fields (AV_PKT_FLAG_KEY) unfortunately they're not listed right next from it [13:49:12 CET] <JEEB> pkt->flags |= AV_PKT_FLAG_KEY*pic_out.b_keyframe; <- so AV_PKT_FLAG_KEY [13:49:22 CET] <JEEB> that's from libx264.c for example [13:49:31 CET] <JEEB> it sets that flag on the AVPacket if x264 tells it it's a RAP [13:49:56 CET] <faLUCE> so, before sending the first packet to av_write_frame() should I check if it's keyframe? [13:50:05 CET] <JEEB> depends on what you want to do? [13:50:16 CET] <faLUCE> I have to record a muxed file [13:50:20 CET] <JEEB> yes? [13:50:27 CET] <JEEB> do you want to start at a RAP or not? [13:50:46 CET] <faLUCE> ok, but I remember that I did not have to do that in the 2.8.7 version [13:50:51 CET] <JEEB> you still don't [13:50:56 CET] <JEEB> where did you get that idea? [13:51:23 CET] <faLUCE> I mean: if I record a file, it should start with a keyframe [13:51:38 CET] <JEEB> I don't think it ever filtered [13:51:41 CET] <JEEB> if it did that's funky [13:52:00 CET] <JEEB> also check if packets containing the parameter sets are muxed in first [13:52:07 CET] <JEEB> those you want first in any case [13:52:11 CET] <JEEB> 725 [13:53:40 CET] <faLUCE> what is 725 ? [13:53:50 CET] <faLUCE> (and yes, they are muxed) [14:22:29 CET] <satoshi2> BtbN it is linked on the compilation guide [14:22:38 CET] <satoshi2> but it seems completely broken [14:22:57 CET] <satoshi2> on a clean win8 install it borked now while compiling ffmpeg [14:23:22 CET] <satoshi2> undefined references to clCreateImage and a bunch of other cls [14:33:25 CET] <dongs> im pretty sure nobody in here builds this stuff on a real OS [14:33:31 CET] <dongs> do they even provide a visual studio build project? [14:33:36 CET] <dongs> or is it all retarded MakeFiles [14:35:34 CET] <DHE> configure and retarded makefiles, thankyou [14:45:29 CET] <BtbN> the compilation guide? If you mean the wiki, that is also just someone put there themselves, nothing official. [14:48:53 CET] <satoshi2> yes [14:50:50 CET] <JEEB> dongs: there are people who depend on having MSVC-built FFmpeg, so while we're doing the retarded thing of not duplicating our build system, we do even test it http://fate.ffmpeg.org/report.cgi?time=20190317214954&slot=x86_64-msvc15-wi… [14:57:33 CET] <dongs> cool [14:57:56 CET] <dongs> prefix=c%3a/dev [14:57:58 CET] <dongs> the fuck [14:58:08 CET] <JEEB> we basically trolled MS to support C99 in MSVC in 2012-2013 [14:58:21 CET] <JEEB> because we made a thingamajig that preprocessed C99 into C89 [14:58:24 CET] <JEEB> for MSVC [14:58:37 CET] <JEEB> and then in 2013 MS announced that they could build FFmpeg with MSVC 2013 [14:58:47 CET] <JEEB> (without that stuff) [15:00:18 CET] <JEEB> and yea, the path stuff takes forward slashes on windows as well IIRC [15:00:22 CET] <JEEB> so c:/ would also work [15:00:44 CET] <JEEB> why it became c%3a is probably up to the FATE webui [15:06:55 CET] <satoshi2> what would make ffmpeg complain about libopenh264.dll ? [15:07:14 CET] <BtbN> Something being wrong with openh264 [15:08:47 CET] <satoshi2> nevermind, found it [15:09:11 CET] <satoshi2> it creates a folder somewher else with the exes and required dlls [16:59:49 CET] <satoshi2> JEEB i love you in a non twi way [17:00:07 CET] <satoshi2> just tested on a AD and it worked [17:00:43 CET] <satoshi2> on the dumped mp4 file the video just stopped when the ad started, and returned playing after the time passed [17:01:47 CET] <satoshi2> resumed playing* [17:09:13 CET] <satoshi2> ah, it misses a few seconds of video due to that ad [17:09:37 CET] <satoshi2> the playback skips a few seconds ahead [17:10:21 CET] <satoshi2> i guess the resolution change is confusing the player/demuxer [17:12:51 CET] <JEEB> probably closer to timestamp stuff :/ [17:58:10 CET] <ncouloute> So it seems as if after my files are deinterlaced the timestamps are changed. Is there no way to get the exact same frame timing after deinterlacing on vfr content. Seems like a nasty combination. Although it seems as if showinfo is giving me the frame timing after the built in ffmpeg deinterlacing. So I could use those just harder to parse than the Matroska V2 Timecodes file. [18:29:43 CET] <satoshi2> "Looks like the playlist containing the EXT-X-DISCONTINUITY tag is the one with ads (and the following ones until the next tag)" [18:29:52 CET] <satoshi2> they are following standards for the ADs at least [18:29:56 CET] <JEEB> yea [18:30:17 CET] <JEEB> we just need to re-calculate timestamps so that they become consistent [18:52:48 CET] <retal> faLUCE hi, do you remember my problem with disappearing lines? [19:20:46 CET] <faLUCE> hello retal, yes, should has been the patch you used [19:21:28 CET] <retal> faLUCE, yes y found prublem :) git apply ../ffmpeg_NVIDIA_gpu_acceleration.patch [19:21:47 CET] <faLUCE> (for all others: do you know is there a way to force the encoder to produce a keyframe? I tried by setting avframe->key_frame = 1 but had no effect [19:21:49 CET] <faLUCE> ) [19:22:22 CET] <faLUCE> retal: anyway, if you still want to use that patch it should not be difficult to re-patch it [19:23:08 CET] <retal> faLUCE, but i think i need use that patch , because i need nvresize [19:24:01 CET] <faLUCE> retal: did you check if the patch has been updated ? [19:24:52 CET] <retal> i dont now , i download from http://developer.download.nvidia.com/compute/redist/ffmpeg/1511-patch/ffmpe… [19:25:05 CET] <retal> then git reset --hard b83c849e8797fbb972ebd7f2919e0f085061f37f [19:26:22 CET] <faLUCE> retal: you should ask to people that made that patch. Even if we modify the patched code, in order to compile fine, it could be unstable at runtime [19:28:45 CET] <retal> faLUCE, i dint know who wrote this patch, also it will take take long time. So no other way compile ffmpeg with nvresize ? [19:30:01 CET] <faLUCE> retal: as said before, the problem is not to compile it. The problem is that you can have an unstable program [19:30:23 CET] <retal> oh [19:30:42 CET] <faLUCE> anyway, paste again the patch, I tell you how to modify it (then you can try the result) [19:31:02 CET] <faLUCE> I mean, paste the patched libx264.c [19:31:32 CET] <retal> ok, in 30 min i let you kbow [19:34:23 CET] <faLUCE> (solved: I set avrame->pict_type) [19:36:41 CET] <faLUCE> (now I wonder if is there anything similar for an audio frame) [20:15:14 CET] <kepstin> audio codecs don't have any concept like keyframes [20:16:08 CET] <kepstin> you can generally start decoding audio at any frame, although depending on the codec and decoder you may have to discard the first N decoded samples before you get something useful. [20:20:01 CET] <faLUCE> kepstin: this is why I don't get errors when the decoder picks unuseful frames before useful ones ;-) [20:20:20 CET] <brejeiro> Hello, is it possible to change the mouse cursor image that goes to the video, when recording the desktop? [20:52:49 CET] <xxxmaker> x265 1.9:[Windows][GCC 4.9.0][64 bit] 8bit [20:52:49 CET] <xxxmaker> Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=300 [20:52:49 CET] <xxxmaker> / min-keyint=30 / scenecut=40 / rc-lookahead=30 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 [20:52:49 CET] <xxxmaker> / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30 [20:52:49 CET] <xxxmaker> Default : Yes [21:02:24 CET] <kepstin> brejeiro: it's supposed to be using the system cursor image, so in theory you could do that by changing the system cursor them. What OS and capture device are you using? [22:27:43 CET] <retal> faLUCE, a am ready. I have new ffmpeg src's just pulled, x264 [22:27:53 CET] <retal> what shuld i do now ? :) [00:00:00 CET] --- Tue Mar 19 2019

1 0

ffmpeg-devel.log.20190317
by burek 18 Mar '19

18 Mar '19

[03:57:25 CET] <vel0city> about Carl's TIFF patch [03:57:41 CET] <vel0city> do _all_ patches usually take a month+ to be reviewed?? [03:58:21 CET] <vel0city> Also, I asked him on email and he said that he knows of no discussions regarding it. [12:18:25 CET] <cone-788> ffmpeg 03Michael Niedermayer 07master:efe4aef90fd8: avcodec/ffv1dec_template: Optimize golomb run mode [12:18:26 CET] <cone-788> ffmpeg 03Michael Niedermayer 07master:dd2a2a51fe47: avcodec/diracdec: Count truncated parts as errors in decode_component() [12:18:27 CET] <cone-788> ffmpeg 03Michael Niedermayer 07master:41f93f941155: avcodec/clearvideo: Check remaining data in P frames [12:18:28 CET] <cone-788> ffmpeg 03Michael Niedermayer 07master:f20760fadbc7: avcodec/dfa: Check the chunk header is not truncated [12:18:29 CET] <cone-788> ffmpeg 03Michael Niedermayer 07master:14eea7c47a92: avcodec/pnm: Optimize reading loop in pnm_get() [17:32:38 CET] <durandal_1707> huh, i managed to hang clang building when enabling sanitizer stuff, it fails to compile codec [19:29:49 CET] <atomnuker> twitch started muxing in ads directly into streams [19:30:03 CET] <durandal_1707> nice! [19:30:36 CET] <JEEB> and they derp up the timestamps so you need to add discontinuity flagging [19:30:45 CET] <JEEB> otherwise I feel like it's going to derp [19:30:56 CET] <JEEB> currently hls.c for some reason is noted as not having discontinuities [19:31:05 CET] <atomnuker> I somewhat doubt they check to make sure a decoder doesn't need to get reinit'd after a switch [19:33:07 CET] <atomnuker> though now you could probably reliably detect when ads occur and just block them [19:33:27 CET] <kierank> atomnuker: yes the gave a presentation about this at demuxed [19:33:38 CET] <kierank> they* [19:34:35 CET] <atomnuker> would be neat if they implemented their not very smart vp9 transcoding idea, then google would be the second if they ever do iti [19:34:41 CET] <atomnuker> *it [19:42:16 CET] <atomnuker> I wonder what'll be done first, twitch implementing vp9 transcoding or some company using svt-av1 for the first av1 livestream of something for non-demo/testing purposes [00:00:00 CET] --- Mon Mar 18 2019

1 0

ffmpeg.log.20190317
by burek 18 Mar '19

18 Mar '19

[00:12:32 CET] <damdai> is ffmpeg still better than libav [00:12:47 CET] <damdai> better as in can do more things [00:13:02 CET] <JEEB> given that FFmpeg merges almost anything, most likely yes :P [00:13:21 CET] <JEEB> I think the people using Libav specifically know exactly what they want [00:13:34 CET] <JEEB> like the guy maintaining movenc, who uses it exactly for that [00:13:42 CET] <damdai> does libav not able to merge almost everything like ffmpeg [00:14:01 CET] <JEEB> I think libav specifically doesn't want to merge everything. [00:15:00 CET] <damdai> interesting [00:23:01 CET] <ncouloute> hmm with just decoding to null I get Application provided invalid. non monotonically increasing tds to muxer in stream 0: 960 >=960... then 5 reference picture missing during reorder/missing reference picture default is x. Sidenote: It seems fine if I let it do a variable fps output. [00:26:22 CET] <JEEB> dongs: btw did you have anything with the 22.2ch stuff? would be nice to get a sample of such audio track [01:40:58 CET] <faLUCE> do you know if is it possible to debug ts and/or print encoded pkt size before they are decoded, with ffplay ? [02:04:23 CET] <Soni> what's the human-friendly documentation for the lowpass filter? [03:09:16 CET] <KombuchaKip> JEEB: Thank you. [03:27:56 CET] <agris> Is there any way to tell ffmpeg to create a directory if the output folder doesn't exist? [03:28:17 CET] <agris> I'm writing a automated script with GNU Parallel and it deals with subfolders [03:29:34 CET] <c_14> pretty sure you can't [04:50:55 CET] <damdai> everybody: i just realized there is no way to visit youtube site by just typing http://ip.address.of.youtube [04:51:00 CET] Last message repeated 1 time(s). [04:51:40 CET] <another> yes. that's very likely true [04:52:04 CET] <another> look into virtual hosts if you're interested. gotta go [04:53:30 CET] <damdai> that's a huge flaw in the internet [04:53:38 CET] <damdai> this must be fixed [04:57:56 CET] <another> no. that's intentional [04:58:35 CET] <another> https://en.wikipedia.org/wiki/Virtual_hosting [04:59:37 CET] <damdai> youtube is not using vhost [04:59:59 CET] <damdai> that might be true for small websites [05:12:22 CET] <klaxa> if it was a flaw, it would have been fixed ages ago, i don't think you stumbled upon something nobody has every questioned [05:12:54 CET] <klaxa> also [05:12:55 CET] <klaxa> <damdai> youtube is not using vhost [05:12:56 CET] <klaxa> proof? [05:13:11 CET] <damdai> why would website that big use vhost [05:13:30 CET] <klaxa> because it makes mangement of domains and subdomains easier [05:13:39 CET] <damdai> no it doesn't [05:13:40 CET] <klaxa> also load-balancers are probably used for a multitude of hosts [05:14:03 CET] <klaxa> so not having a Host parameter in the http header makes the server wondering what site you wanted to access [05:14:13 CET] <klaxa> *makes the server wonder [05:14:20 CET] <damdai> i can visit google.com [05:14:22 CET] <damdai> by using ip [05:14:58 CET] <damdai> if what you say is true, then i shouldn't able to do that either [05:15:12 CET] <klaxa> i would guess that is convenience for people who don't have dns but want to google [05:15:21 CET] <klaxa> look [05:15:25 CET] <klaxa> the burden of proof is on you [05:15:35 CET] <klaxa> <damdai> that's a huge flaw in the internet [05:15:35 CET] <klaxa> <damdai> this must be fixed [05:15:42 CET] <klaxa> extraordinary claims require extraordinary evidence [05:15:55 CET] <damdai> it is a falw [05:15:58 CET] <damdai> it is a flaw [05:16:10 CET] <damdai> i should able to visit a website by typing the ip address [05:16:23 CET] <damdai> dns could go down [05:16:43 CET] <damdai> if dns goes down, you are screwd [05:16:53 CET] <klaxa> if dns goes down you have /etc/hosts [05:17:13 CET] <damdai> i should able to just type the ip address [05:17:17 CET] <klaxa> and you probably have other problems than watching youtube [05:17:33 CET] <damdai> klaxa , lol true, but still [05:17:42 CET] <klaxa> i am not going to discuss internet standards you don't seem to understand any further with you [05:19:20 CET] <damdai> what if i don't have a domain name, and just want to host a website by using IP [05:32:51 CET] <another> go ahead and do that [06:58:31 CET] <Snoober> I'm having trouble going from yuvj420p (full color range, 8-bit) h264 -> dnxhd (which always uses yuv422p) -> back to h264 but wanting to convert back to yuvj420p [06:59:03 CET] <Snoober> am i supposed to use -pix_fmt yuvj420p or I also read some commands -dst_range 1 -color_range 2 to use. i'm not sure [12:42:51 CET] <__raven__> hi [12:46:26 CET] <__raven__> i need to compose a mosaic "multiviewer" of up to 32 rtmp input streams. to avoid a frozen output if just one input fails or buffers, is there any (recommended) step to "normalize" those input streams? [13:10:55 CET] <JEEB> __raven__: I don't think FFmpeg's framework itself provides a dynamic switch from f.ex. what you are providing to an alternative source which can come and go [13:11:13 CET] <JEEB> there's a filter that will fall back to alternative generated input, yes. but that only works once and will not go back [13:12:15 CET] <JEEB> so you would have to handle each AVFormatContext yourself and handle the concept of real world time yourself, basically [13:12:42 CET] <JEEB> I know that upipe has something dynamic but that's a whole other framework (mostly meant for broadcasting) [14:12:42 CET] <faLUCE> hello. When printing the timestamps of packets with ffprobe, how can I print the date (year-month-day-hour-seconds-millisecs. etc.) as well? [14:25:21 CET] <__raven__> JEEB: do you have an example of what this preprocessing would look like? it would be no problem to normalize each input stream on our rtmp server before it gets into the mosaic chain [15:18:52 CET] <faLUCE> do you know if 1 frame is the minimum latency for demuxing an opus mpegts stream? [15:36:21 CET] <satoshi2> hello [15:37:59 CET] <satoshi2> i was wondering if anybody have reported this already, twitch seems to have started using SureStream, which inserts ADs on the raw video stream [15:38:44 CET] <dongs> JEEB: will decode some samples i capped this week. [15:38:50 CET] <dongs> a bit busy with unrelated stuff [15:39:00 CET] <dongs> satoshi2: why is that worth reporting [15:39:15 CET] <satoshi2> i have come across a channel that is inserting a ad with dts sound, and it breaks the file after that [15:39:21 CET] <JEEB> dongs: as proof of my masochism http://up-cat.net/p/5421c134 [15:39:28 CET] <dongs> cilcking furiously [15:39:35 CET] <dongs> hot [15:39:51 CET] <dongs> lokoing good [15:40:00 CET] <satoshi2> i have tried a few workarounds liek this https://github.com/ytdl-org/youtube-dl/issues/10719#issuecomment-364389876 but none of them worked [15:40:10 CET] <satoshi2> the resulting file is broken after teh ad [15:40:18 CET] <dongs> satoshi2: is original audio AAC? [15:40:21 CET] <dongs> (before dts) [15:40:23 CET] <satoshi2> yes [15:40:27 CET] <dongs> as i thought [15:40:33 CET] <dongs> you can blame AAC being fucking garbage for this [15:41:15 CET] <satoshi2> what a rip [15:41:33 CET] <JEEB> oh, so DTS as not the audio format, but just derping up the timestamps [15:43:09 CET] <dongs> no, the audio format [15:43:14 CET] <dongs> and i guess AAC decoder crashes when it sees it [15:43:33 CET] <JEEB> well the issue he linked was about discontinuities [15:43:46 CET] <dongs> i think vlc &* co still break when kouhaku mpegts switches from 5.1 audio to 2.0 during mid-time news segment [15:43:50 CET] <JEEB> unless he was talking about the audio format and then misunderstood :P [15:44:04 CET] <JEEB> dongs: pretty sure FFmpeg fixed that since I provided a sample of that ages ago [15:44:07 CET] <dongs> ya? [15:44:38 CET] <dongs> next year my target is clean 8k kouhaku recording [15:44:49 CET] <dongs> going to be the biggest waste of bandwidth ever [15:45:12 CET] <JEEB> at least I have an aac_decoding_regression.ts in my files and that is 7:15 news->kouhaku stereo to 5.1 switch [15:45:17 CET] <JEEB> and it works nicely [15:45:20 CET] <dongs> cool [15:46:40 CET] <satoshi2> https://pastebin.com/xpbtJJna [15:46:44 CET] <JEEB> also I remember TheFluff derping me up even earlier with a mono to stereo switch in like 2011 or so [15:46:55 CET] <JEEB> moshidora sample [15:47:34 CET] <JEEB> and that one was fixed by then [15:48:08 CET] <dongs> i forgot which aac decoder ate shit with format switching midstream. im thinking the helix aac or wahtever that everyone used [15:48:21 CET] <JEEB> a lot of decoders did [15:48:30 CET] <dongs> oh, faad2 [15:48:31 CET] <dongs> that. [15:48:33 CET] <JEEB> yup [15:49:41 CET] <JEEB> I think it was circa 2011 or whatever when most of that stuff started getting fix'd and people started moving off of faad2 more [15:50:11 CET] <dongs> i think around the time i stopped fucking around wiht j-tv stuff [15:50:18 CET] <dongs> and just gave up at it being broken shit [15:50:46 CET] <dongs> and yeah... satoshi's shit is talking about displaytimestamp, not DTS audio [15:50:55 CET] <JEEB> *decoding time stamp [15:51:00 CET] <JEEB> PTS is presentation time stamp [15:51:43 CET] <JEEB> right, so then the discontinuity handling with the meta HLS demuxer doesn't work right [15:52:07 CET] <JEEB> pretty sure someone added a patch to add that flag to the HLS demuxer (which just uses an mpeg-ts demuxer in the background) [15:52:08 CET] <satoshi2> heh [15:52:18 CET] <satoshi2> i thought it was teh audio lol [15:52:34 CET] <JEEB> as far as I can tell the segment just derps [15:52:48 CET] <JEEB> if you can take a look at the HLS playlists, check if the playlists actually mark discontinuities [15:53:06 CET] <JEEB> if they don't, that's a twitch boog [15:53:23 CET] <JEEB> (although we should still check if the timestamps are continuous on our side) [15:54:11 CET] <satoshi2> is there any way i can force it? [15:55:29 CET] <JEEB> towards the end of libavformat/hls.c in the AVInputFormat structure, switch the .flags to `.flags = AVFMT_NOGENSEARCH | AVFMT_TS_DISCONT,` [15:55:54 CET] <JEEB> the AVFMT_TS_DISCONT notifies the framework that this thing can have discontinuities [15:57:54 CET] <satoshi2> i am looking at a m3u8, how should it look liek if they are marked? [15:58:29 CET] <JEEB> https://tools.ietf.org/html/rfc8216#page-14 [15:58:38 CET] <JEEB> EXT-X-DISCONTINUITY [15:58:58 CET] <dongs> you expect people to actually follow a standard?! [15:59:28 CET] <satoshi2> i can confirm, that tag isn't there, fucking twitch [15:59:30 CET] <JEEB> it's actually something you can complain about, yes. whether they will do anything about that is not as relevant [15:59:43 CET] <JEEB> satoshi2: even if it was HLS in FFmpeg is not marked as "can have discontinuities" :P [15:59:57 CET] <JEEB> that's the part I noted that you should change libavformat/hls.c [16:00:13 CET] <JEEB> but yes, if they were proper the profile playlist should have the discontinuity flag [16:09:24 CET] <satoshi2> JEEB would you mind making a build? media autobuild suite seems to require a 13gb install lol [16:14:27 CET] <JEEB> satoshi2: that sounds /really/ excessive [16:14:42 CET] <JEEB> I am currently poking at something else so not right away at least :P [16:15:17 CET] <dongs> after pulling 2.5gb of that hevc reference shit, the actual -top- branch was only like few megs of sores and built without a single warning with VC [16:15:34 CET] <dongs> if only svn wasn't complete shit [16:15:37 CET] <JEEB> inorite [18:08:40 CET] <faLUCE> there's some ambiguity about that: if I receive a mpegts stream with ffprope, what does "show_frame" shows? the demuxed frames or the decoded ones? [18:09:35 CET] <DHE> should be that frames are decoded. packets are raw on-the-wire payloads. [18:09:53 CET] <DHE> ffmpeg terminology, not container-specific terminology [18:19:46 CET] <faLUCE> DHE: then, packets are the content of demuxed data and frames are the decoded frames? [18:20:07 CET] <JEEB> generally what lavf outputs is something you should be able to feed to a decoder of that format [18:20:23 CET] <JEEB> with mpeg-ts if the format doesn't need a parser it will output the result of the relevant PES packet [18:20:42 CET] <JEEB> if the format needs a parser the PES packet(s) will be fed to a parser until that outputs a single decode'able AVPacket [18:21:13 CET] <faLUCE> JEEB: with "lavf output" do you mean packets? [18:21:24 CET] <JEEB> lavf only outputs AVPackets [18:21:28 CET] <DHE> mpegts does preserve packet boundaries, at least as best I understand it. I'm using lavf & lavc with mpegts in for several codecs without any issues [18:21:35 CET] <faLUCE> ok [18:22:02 CET] <JEEB> DHE: well for some formats extra parsing is needed [18:22:19 CET] <JEEB> I think video formats are most common [18:22:26 CET] <JEEB> because a single PES packet is 188 - <overhead> [18:22:32 CET] <JEEB> but yes, that is handled automagically for you [18:22:45 CET] <DHE> JEEB: true, but there is also a bit in the header to indicate it starts a new avpacket [18:23:21 CET] <JEEB> AVPacket is on a higher level of abstraction but yes a new AVpacket is probably going to be generated from the read buffer [18:24:38 CET] <JEEB> 34 [18:25:24 CET] Action: DHE wrote his own mpegts parser a while back [18:26:18 CET] <DHE> shoutouts to wireshark which really helps understanding the format [18:26:41 CET] <JEEB> DVB Inspector is something I recommend for checking out MPEG-TS [18:26:59 CET] <JEEB> life saver with checking the packets all the way to graphing the timestamps etc [18:27:28 CET] <JEEB> it's java, but I am an equal opportunity person if it'll get the job done [18:28:02 CET] <DHE> my company bought some physical hardware that does the same thing. quite expensive, but it'll handle a gigabit port's worth of traffic before the switch it's plugged into is the one that ruins the statistics [18:28:12 CET] <DHE> :/ [18:28:26 CET] <JEEB> lol, I do so know that feeling :P [18:34:32 CET] <DHE> tfw you learn that the tiny packet buffer on this big switch is shared across all ports, and not actually "shared" but small dedicated buffers on ports that don't need it exist. [18:41:58 CET] <__raven__> JEEB: do you have an example of what this preprocessing would look like? it would be no problem to normalize each input stream on our rtmp server before it gets into the mosaic chain [18:44:48 CET] <JEEB> __raven__: it's one thing to normalize timestamps according to reception etc, but handling the inputs so that you switch back and forth between a generated back-up thing to show there while the actual input is dead [18:44:59 CET] <JEEB> the synchronization based on reception time is probably the simpler part :P [18:47:40 CET] <__raven__> JEEB: the synchronisation between those pip inputs is not the problem. those can drift far away from each other no matter. but the generated mosaik must not freeze if just one stream fails for just a few seconds or even if it misses a few frames [18:48:12 CET] <JEEB> yes [18:48:21 CET] <JEEB> that is the second part which I noted is the less simple part of it [18:48:47 CET] <JEEB> there is a filter in libavfilter that can fall back to a secondary input if things fail, but it will never ever go back to the primary input [18:49:36 CET] <kepstin> i'd suggest having some custom code which - if it notices that it's not receiving something from an input - just passes duplicates of the last seen frame to the filter chain at regular intervals. [18:49:43 CET] <__raven__> JEEB: in my naive imagination maybe there is "just" the need for an intermediate "baseband"? [18:51:47 CET] <__raven__> input stream frame rate is between 15 and 30 fps but the decoder needs to "scan" it on a fixed rate of 25fps [18:52:36 CET] <__raven__> maybe kind of the old line/scan converters used for apollo landings with display-camera-chain ;) [18:53:53 CET] <JEEB> well, with digital usually you do the frame rate normalization after decoding [18:54:19 CET] <JEEB> but yes, you will have to have a filter doing frame rate normalization if you need that - and also a deadline for when you should get a new packet out of the input protocol [18:54:29 CET] <JEEB> say, 250ms or something like that :P [18:54:35 CET] <kepstin> you can't change framerate before decoding with modern codecs, because of reference frames etc. [18:55:23 CET] <JEEB> latter meaning that you start feeding a constant back-up feed of 25Hz or whatever your rate is while the input is down, and then when you start getting stuff again you feed it the input stuff again [18:56:29 CET] <kepstin> note that this can't be done *in* the filter chain, due to the construction of the framework (a filter requests a new frame, and then it doesn't get run again until a new frame is available) [18:56:42 CET] <JEEB> yes, I have already mentioned that [18:56:55 CET] <__raven__> JEEB: yes but i need no backup stream/input for it. it should just freeze on the last received image or in other words duplicate this as many times to reach the 25fps [18:57:05 CET] <JEEB> __raven__: that's still a back-up feed [18:57:26 CET] <__raven__> kepstin: i do not need that to be in the filter chain [18:58:06 CET] <__raven__> i could do a normalization process for every input apart from that [18:58:51 CET] <__raven__> anything what feeds fixed framerate into a fifo, our rtmp server, a pipe or something else [18:59:17 CET] <kepstin> the code to do this has to run after the decoder, before the filter chain. [18:59:47 CET] <kepstin> since it will work by passing duplicates of the last decoded frame to the filter when no frames were decoded in some timeout. [19:00:10 CET] <JEEB> as I noted, upipe has logic for async primary/back-up switching if you are interested in looking at that logic [19:00:24 CET] <JEEB> where back-up includes "just show the last image at a static rate" [19:01:15 CET] <__raven__> not sure if i got you right: do you mean the filter chain within the mosaique command or the filter chain of "any ffmpeg command"? [19:01:46 CET] <JEEB> you will not be able to do this with just ffmpeg.c [19:01:50 CET] <JEEB> in its current state [19:02:06 CET] <JEEB> unless you handle all this logic with another thing that does a lot of the stuff that ffmpeg.c already does [19:03:45 CET] <__raven__> what i mean is "vfrInputStreamFromRtmp{i} -> [ffmpegNormalizationProzess{i}] -> toRtmp -> allRtmpInputs -> [ffmpegMosaiqueProcess] [19:04:31 CET] <JEEB> not sure why you're going back to RTMP there but if that's how you want to handle that - sure (Ž4@) [19:05:00 CET] <__raven__> could be pipe, fifo or something else too [19:06:45 CET] <kepstin> that sounds like kind of a pain to set up - you'd basically be writing a new program that reads from rtmp, demuxes, decodes, duplicates frames if needed to ensure a constant stream, then remuxes the frames (i'd probably use nut) - to feed it into an ffmpeg.c process [19:07:06 CET] <__raven__> :/ [19:07:07 CET] <kepstin> at that point you might as well put the final mosaic and encoding step into your new program too [19:08:33 CET] <JEEB> yea, that's what I meant :P [19:08:48 CET] <__raven__> what is coming out in general by transcoding an rtmp with vfr with a fixed -r 25? [19:09:13 CET] <JEEB> static 25Hz unless your input goes wee-wee [19:09:26 CET] <JEEB> which includes the protocol going dead as well as just having really low frame rate [19:10:05 CET] <JEEB> like if you get a frame every second or so, you will only get those next 25 output images after the logic has noticed the amount of duplication that has to be done [19:10:09 CET] <kepstin> the really fun thing is when you get e.g. a 10 second gap - then it'll pause output for 10 seconds, then output 250 frames as fast as possible. [19:10:18 CET] <JEEB> yes [19:10:21 CET] <JEEB> that's what I meant [19:10:36 CET] <JEEB> ffmpeg.c is really based on file-to-file workflows where such pauses are OK [19:11:03 CET] <__raven__> hm but that sounds like everything i want so far [19:11:05 CET] <kepstin> (i recently fixed an issue in the fps filter when it was doing that - it used to create all the avframes to fill the gap in memory, and I had it oom on a file with a multi-hour timestamp gap) [19:11:36 CET] <__raven__> real breakdowns of single input streams are not my concern - we would just sort that stream out and restart the generator [19:12:19 CET] <kepstin> __raven__: the issue is that ffmpeg.c as currently designed cannot produce a continuous properly paced output stream given unstable inputs. [19:12:42 CET] <__raven__> more important is, if it either exits if output rate generally above average input rate or slows down the video if averaged below [19:13:14 CET] <__raven__> kepstin: any way to catch that with buffers and timeouts? [19:13:28 CET] <JEEB> sure, but even that is extra code [19:13:36 CET] <kepstin> __raven__: the required buffers and timeouts would have to be added inside ffmpeg.c [19:13:55 CET] <JEEB> or you just make your own API client with your own requirements [19:14:14 CET] <JEEB> ffmpeg.c can get you surprisingly far - until it can't :P [19:14:25 CET] <__raven__> yeah ^^ [19:15:18 CET] <kepstin> i mean, you could do something utterly ridiculous like have an ffmpeg read the input, decode, output raw frames, pipe that to a new application you write that paces and drops/duplicates the raw frames, then pipe that to another ffmpeg that encodes. [19:15:36 CET] <kepstin> but i wouldn't recommend that, seems likely to be fragile :) [19:16:22 CET] <kepstin> (you'd need to put the frames in some container so they have timestamps, too, which means you still need a demuxer/muxer in your app) [19:16:38 CET] <__raven__> going down the line lets say i do not need realtime: "sampling" every input stream into a still image and working with loop input on the generator script......? [19:17:08 CET] <kepstin> you can't sample images in an encoded stream [19:19:24 CET] <kepstin> if you don't need realtime (e.g. you're just archiving to disk), then ffmpeg will be fine [19:19:38 CET] <JEEB> well [19:19:46 CET] <JEEB> think of the scenario where one input goes dead [19:19:48 CET] <kepstin> as long as the gaps aren't too long, i guess (it might have to generate a lot of data to fil gaps) [19:19:51 CET] <JEEB> and the lavfi chain is waiting [19:20:03 CET] <__raven__> indeed it is just a multiviewer to get an overview of the input streams [19:20:39 CET] <kepstin> for a multiviewer, I'd honestly just run a bunch of independent mpv with the windows titled :) [19:21:40 CET] <__raven__> kepstin: it is a headless server [19:21:59 CET] <__raven__> the multiviewer should be sent out via rtmp too [21:33:58 CET] <JEEB> dongs: http://up-cat.net/p/d4d024e2 [21:34:10 CET] <JEEB> I think for today that's enough masochism :P [22:05:47 CET] <TheAMM> When using -dump_attachment, is there any sane way not to have ffmpeg complain about the lack of an output file? [22:06:24 CET] <JEEB> probably only by doing -f null - [22:06:26 CET] <JEEB> or something [22:06:41 CET] <JEEB> welcome to features that don't really mix with the ffmpeg.c flow vOv [22:07:49 CET] <TheAMM> Leads to decoding [22:08:04 CET] <TheAMM> I'll just ignore the error and check if the dumped attachment exists [22:08:55 CET] <JEEB> aye [22:45:09 CET] <ossifrage> I'm amazed that chrome is playing the crap I'm sending it, shame firefox doesn't like it as well [22:48:44 CET] <ossifrage> I'm just writing one GOP frame by frame as a fragmented mp4 file and then truncating the file at the end of the GOP, the webserver is effectively doing 'tail -f' [23:38:33 CET] <__raven__> opening all input videos (those are rtmp streams) for the mosaique generator takes ages. i ws not able to find out about the reason yet. how to speed that up or parallelize it? [23:42:46 CET] <JEEB> if you are using ffmpeg.c most likely they are opened and probed one by one :P [23:53:20 CET] <__raven__> JEEB: yes thery are but why does it take around 20 seconds for one stream? i already fixed gop, cbr, fps, pts and such [23:54:06 CET] <JEEB> probing takes time? [23:55:41 CET] <__raven__> any workaround? [00:00:00 CET] --- Mon Mar 18 2019

1 0

ffmpeg-devel.log.20190316
by burek 17 Mar '19

17 Mar '19

[01:41:57 CET] <cone-930> ffmpeg 03Mathieu Duponchelle 07master:6cfa17330317: mpeg12enc: Use Closed Captions if available [13:15:23 CET] <cone-387> ffmpeg 03Gyan Doshi 07master:d15117c996d9: doc/ffmpeg: add entry for itsscale [14:40:45 CET] <sourabhboss> Hi [14:41:54 CET] <sourabhboss> Mov muxer writing header(mov_write_header) and packet and also trailer what's the difference [14:42:42 CET] <JEEB> those are three of the things that are defined in our libavformat API [14:42:56 CET] <JEEB> header writing is called by API client when it has configured its streams etc [14:43:37 CET] <JEEB> then write packet gets called by the API client when the client wants to write an AVPacket into a stream within that muxer [14:43:58 CET] <JEEB> and then finally trailer writing is done to finish up anything that has to be done at the end [14:44:09 CET] <JEEB> if a muxer doesn't define one of those it's just nothing [15:18:27 CET] <durandal_1707> kierank: no deal for ndiexit [15:20:59 CET] <kierank> durandal_1707: why [00:00:00 CET] --- Sun Mar 17 2019

1 0

ffmpeg.log.20190316
by burek 17 Mar '19

17 Mar '19

[00:13:44 CET] <faLUCE> kepstin: the API example I made two years ago works perfectly with opus... with very few changes [00:15:06 CET] <faLUCE> so, there's something wrong elsewhere in the "big" program. but not in the procedure we described [01:48:14 CET] <retal> kepstin, sorry i was out of office when you wrote. I dont think i have different versions of x264 [01:56:14 CET] <faLUCE> retal: check the id in you x264 version [01:56:50 CET] <retal> faLUCE, how i can check it [01:56:51 CET] <retal> ? [01:57:32 CET] <damdai> why can't mkvtoolnix support wmv as source but ffmpeg CAN? [01:59:13 CET] <faLUCE> retal: execute version.sh inside the x264 dir [01:59:57 CET] <damdai> why doesn't this work? ffmpeg -i R:\9-3000.wmv -vcodec copy -acodec copy -movflags faststart R:\1.mp4 [02:00:25 CET] <retal> faLUCE, #define X264_REV 2970 [02:00:25 CET] <retal> #define X264_REV_DIFF 0 [02:00:25 CET] <retal> #define X264_VERSION " r2970 5493be8" [02:00:25 CET] <retal> #define X264_POINTVER "0.157.2970 5493be8" [02:00:26 CET] <damdai> oops made a mistake [02:01:01 CET] <faLUCE> retal: you can also execute "x264 -h" [02:01:07 CET] <faLUCE> it will show the version [02:02:54 CET] <faLUCE> you also have the version in x264.h : #define X264_BUILD ... [02:05:14 CET] <damdai> why can't mkvtoolnix support wmv as source but ffmpeg CAN? [02:06:53 CET] <retal> faLUCE, x264 -h [02:06:57 CET] <retal> sorry [02:07:15 CET] <faLUCE> retal: look inside x264.h [02:07:21 CET] <retal> X264_BUILD 157 [02:07:44 CET] <faLUCE> retal: now, look inside libx264.c of your ffmpeg source [02:08:08 CET] <faLUCE> find the line with if (x4->params.i_bitdepth > 8) [02:09:32 CET] <faLUCE> and see if it is defined something like "#if X264_BUILD >= 153" [02:13:55 CET] <retal> faLUCE, its strange . but look like i dont have line if (x4->params.i_bitdepth > 8) [02:14:14 CET] <faLUCE> retal are you looking into libx264.c ? [02:14:21 CET] <faLUCE> (of ffmpeg src) [02:14:47 CET] <retal> yes , /ffmpeg/libavcodec/libx264.c [02:15:11 CET] <faLUCE> ok, let me git the latest, I check [02:19:49 CET] <faLUCE> retal: just checked, line 293 [02:20:16 CET] <faLUCE> (latest git version) [02:21:48 CET] <faLUCE> retal: where/how did you download the ffmpeg version? [02:22:04 CET] <retal> faLUCE, empty line :( [02:22:28 CET] <retal> let me reinstall celan system on Monday i try again [02:22:37 CET] <faLUCE> retal: can you write how you downloaded ffmpeg? [02:22:44 CET] <faLUCE> that line MUST be in the source code [02:23:16 CET] <retal> as i remember yetorday it cloned from git [02:23:37 CET] <faLUCE> in which way? [02:23:41 CET] <retal> git clone git://source.ffmpeg.org/ffmpeg.git [02:24:41 CET] <faLUCE> retal: pastebin the content of libx264.c .... this is weird :-) [02:24:49 CET] <retal> :))))) [02:25:38 CET] <faLUCE> that line must be either in the latest git, either in the last stable version. Unless you seriously messed up something [02:26:50 CET] <retal> faLUCE, https://pastebin.com/aFfrfZHd [02:28:58 CET] <retal> one intresting tink, today before this error i was compiled successful couple times with different options [02:29:46 CET] <faLUCE> retal: which configure cmd did you use? [02:29:54 CET] <faLUCE> (the last one) [02:30:23 CET] <retal> --enable-nonfree --enable-nvenc --extra-cflags=-I../cudautils --extra-ldflags=-L../cudautils --enable-gpl --enable-libx264 [02:30:55 CET] <retal> but error i recived with nvresize [02:31:52 CET] <retal> also i remember aplyed patch for session count limitation remove, maybe it broke someting ? [02:34:16 CET] <faLUCE> retal: the only thing you can do is to git again the src. Then check if that line is in libx264.c (and it will be there) [02:34:21 CET] <faLUCE> then configure again [02:35:33 CET] <faLUCE> i will solve your problem but it won't explain why that line disappeared :-) [02:37:10 CET] <faLUCE> I don't know which patch you applied, but: was it for libx264.c ? [02:37:44 CET] <faLUCE> retal: ^ [02:38:06 CET] <retal> faLUCE, thank you so much for your help, now i should go, on Monday i will do clean setup and let you know [02:38:17 CET] <faLUCE> ok [02:38:30 CET] <retal> faLUCE, thank you again ! [02:38:36 CET] <faLUCE> np [02:38:47 CET] <retal> :) [05:19:13 CET] <brimestone> Anyone still awake here? [10:41:00 CET] <rememberYou> hello friends, I would like to only record my microphone and save the record to a file. Any idea how I could achieve that? [10:41:17 CET] <rememberYou> NOTE: the microphone is internal to my laptop [10:51:35 CET] <Foaly> rememberYou, have you tried https://trac.ffmpeg.org/wiki/Capture/Desktop [10:52:28 CET] <rememberYou> well, I don't want to capture my screen, I just would like to record the audio from my microphone [10:52:56 CET] <Foaly> have you read the article? [10:53:20 CET] <rnmhdn> we have so many videos [10:53:46 CET] <rnmhdn> but there is a mistake in the end part of them all [10:54:01 CET] <rnmhdn> so we want to replace the last 3 minutes off all videos with something else. [10:55:12 CET] <rememberYou> Foaly: thank you, it seems that https://trac.ffmpeg.org/wiki/Capture/ALSA answer the question [10:55:45 CET] <rnmhdn> we have already exported some of the videos [10:56:16 CET] <rnmhdn> but some are still in a premier project [10:57:08 CET] <rnmhdn> should I ask my people to fix the videos and export them then [10:57:55 CET] <rnmhdn> or should I ask them to export the wrong videos and later I replace the last 3 minutes of all videos with the correct one without any re encoding(so fast) [11:01:04 CET] <rnmhdn> when I do [11:01:06 CET] <rnmhdn> ffmpeg -i N1.5_6.mp4 -ss 0:0 -to 0:30 -codec copy b.mp4 [11:01:28 CET] <rnmhdn> the first second of the b.mp4 video becomes problematic while the original file was just fine [11:03:59 CET] <rnmhdn> problematic means that when I play it one second is black but the audio is fine(starts automatically in the right way) [11:04:32 CET] <rnmhdn> but the first second of the video is fine [11:04:42 CET] <rnmhdn> not fine! lost! [11:22:33 CET] <iTommix> Hi @ all. I try to record a TV-Stream (RTP) to mp4 in linux for later watching on a AppleTV. But even the Stream is in SD the output quality is bad (artefacts etc.). Here is my log from capture and with wich command i use it. Maybe anyone see a mistake i do: https://pastebin.com/76RQ8NnJ [11:27:52 CET] <iTommix> maybe because of the input is already in h264 i dont have to send the stream trough the libx264 codec? [11:28:14 CET] <iTommix> just copy the video stream? [12:34:06 CET] <phinxy> I'd like to compile ffmpeg with libmp3lame statically lined. --extra-cflags='-static-libmp3lame' did not work because the command is unrecognizeable by gcc. "did you mean -static-libmpx"? [12:38:01 CET] <phinxy> I have a libmp3lame.a (not an shared object). That is why. [13:04:53 CET] <lezsakdomi_> Hi! I have issues using a V4L2 device. The video captured is nice and dandy, but there is a constant ~2s delay. It looks like the delay is caused because of the slow opening of the device. [13:05:25 CET] <lezsakdomi_> Is there an option to wait for opening all inputs and starts muxing them after? [13:14:26 CET] <faLUCE> lezsakdomi_: paste the command [13:19:21 CET] <lezsakdomi_> ffmpeg -f v4l2 -video_size 800x600 -input_format yuyv422 -i /dev/video0 -f pulse -i alsa_input.usb-046d_0825_AF679DA0-02.analog-mono test.mkv [13:19:26 CET] <lezsakdomi_> or just: [13:19:42 CET] <lezsakdomi_> ffplay -f v4l2 -i /dev/video0 [13:20:40 CET] <lezsakdomi_> Cheese and OBS studio can show the camera picture with almost zero latency which I can't reproduce using ffplay :( [13:21:09 CET] <durandal_1707> ffplay is demo [13:21:46 CET] <lezsakdomi_> Yes, but I think 2s is a bit much. [13:22:20 CET] <lezsakdomi_> When recording and then playing back that test.mkv the delay is clearly seen. [13:22:54 CET] <faLUCE> lezsakdomi_: add --fflags nobuffer [13:23:51 CET] <faLUCE> (-fflags nobufer, one "-") [13:24:42 CET] <lezsakdomi_> Whoa, it solved it! [13:24:54 CET] <lezsakdomi_> Thank you really much! [13:24:59 CET] <faLUCE> :-) np [14:39:06 CET] <lezsakdomi_> Interestingly `ffmpeg -i /dev/video0 -f opengl -pix_fmt rgba "Webcam"` removes latency too. [14:40:12 CET] <phinxy> Why is there a wingcommander III .c in ffmpeg? [14:40:15 CET] <lezsakdomi_> While there's still a delay when I try to save multiple streams to a file: https://termbin.com/4g8b [14:41:12 CET] <JEEB> phinxy: because someone thought it would be cool to be able to play those videos in that game [14:41:25 CET] <JEEB> a lot of stuff in FFmpeg is purely due to someone's tastes and likes :D [17:10:06 CET] <astericks> Hi just wondering if I can set the "Writing Applicaiton" metadata to something custom [17:10:16 CET] <astericks> in mp4 or mov [19:18:27 CET] <damdai> does ffmpeg support encoding to wmv ? [19:18:48 CET] <JEEB> on some level yes [19:19:12 CET] <JEEB> there are some wmv encoders (I think at least wmv2 which is I think known was "windows media 8" [19:19:41 CET] <JEEB> what you most likely want is wmv3 aka windows media 9, which then also morphed into vc1 [19:19:56 CET] <JEEB> but I'm not sure how good the encoders are for any of those formats [19:20:03 CET] <JEEB> or if we even have a vc1 encoder [19:24:04 CET] <damdai> i am only interested because to test the difference between wmv2 and wmv3 [19:25:10 CET] <JEEB> not sure how good either of those encoders were compared to whatever other encoders there were from MS etc [19:27:20 CET] <damdai> is it true that vc1 was better than h264 when there was only 1st generation encoders [19:28:27 CET] <JEEB> I'm not sure what you mean with 1st gen [19:28:48 CET] <JEEB> what would be considered first gen because f.ex. x264 development was started around 2003 [19:30:02 CET] <damdai> not sure about vc1 was included in bluray [19:30:10 CET] <damdai> not sure but vc1 was included in bluray [19:30:17 CET] <JEEB> yes, it was. just like mpeg-2 video was [19:30:29 CET] <JEEB> I hvae some 2005 MPEG-2 Video blu-rays :P [19:30:34 CET] <damdai> but now h264 is way better than vc1 [19:30:36 CET] <JEEB> delicious macroblocking [19:30:56 CET] <JEEB> (also enabling mpeg-2 video basically meant you could stick DVD SD stuff as-is to blu-rays) [19:31:10 CET] <damdai> right [19:31:36 CET] <JEEB> I think the reason for various formats to be in blu-ray can be due to various factors like politics between companies etc [19:31:39 CET] <JEEB> and the age of the format [19:31:57 CET] <JEEB> I don't remember when the first blu-ray specs were ratified [19:32:50 CET] <damdai> somebody in x264 told me it was because there weren't any good h264 encoder at the time and vc1 was actually better [19:33:45 CET] <JEEB> I'm not 100% sure about that, but it depends on the age [19:34:00 CET] <JEEB> because from circa 2006 you could say that even x264 already was going better [19:34:33 CET] <JEEB> but if the spec is older than that (it probably is) it might have been a political thing to get HD-DVD mastering places etc on board [19:34:34 CET] <damdai> circa 2006 ? [19:36:52 CET] <damdai> btw, wmv3 is decent but i've seen so many bad videos of wmv2, just horrible [19:40:47 CET] <Hello71> also I'm sure it's partly design-by-committee [19:41:05 CET] <JEEB> also VC-1 was actually standardized in 2006 [19:41:20 CET] <JEEB> of course the format was available as more or less WMV3 since 2003 [19:42:43 CET] <damdai> why does wmv2 sucks so much? wmv2 @ 4500 bps is worse than wmv3 @ 2000 bps [19:43:30 CET] <damdai> sorry kbps [19:43:54 CET] <JEEB> shitty encoders? [19:44:06 CET] <JEEB> I mean, without making a proper comparison we wouldn't know [19:44:17 CET] <JEEB> but you're probably not in posession of the proper encoders etc to do a test [19:44:21 CET] <JEEB> thus there is no answer [19:44:31 CET] <damdai> i am going to test how good ffmpeg's wmv is [19:44:54 CET] <JEEB> probably shit :P [19:45:25 CET] <JEEB> lossy encoders were never the forte of FFmpeg, even if the mpeg4 one could be configured nicely and in some tests beat xvid [19:45:51 CET] <JEEB> they generally are made for "I just need a video in this format because windows media player or something else cannot play my MPEG-4 Part 2 or H.264" [19:47:41 CET] <damdai> i don't understand, shouldn't ffmpeg's x264 exact same as x264.exe ? [19:48:27 CET] <JEEB> libx264 in FFmpeg utilizes the x264 library yes, it's a wrapper around an external library. what I meant are lossy encoders *within* FFmpeg itself [19:49:04 CET] <JEEB> there are some OK ones, but esp. if it's a minor format they probably are not really good :P [19:50:10 CET] <damdai> ffmpeg is so powerful though, did you know that mkvtoolnix doesn't even support wmv as source? [19:50:56 CET] <JEEB> I don't see any reason for it to do so? its focus is on getting raw media into matroska [19:51:12 CET] <JEEB> it has an AVI support, but that sucks as it uses the VFW compatibility mode [19:51:22 CET] <JEEB> which you don't want to use in 99% of all cases [19:57:00 CET] <damdai> pretty much every video encoder before h264 sucks i wonder how youtube survived before h264 existed [20:17:34 CET] <another> h264 is not an encoder but a standard [20:17:54 CET] <another> youtube was using flash video before [20:19:03 CET] <JEEB> vp62 basically :P [20:19:13 CET] <furq> weren't they using flv1 [20:19:48 CET] <JEEB> they probably utilized different things at different times. I do remember them using VP6 at some point since I think flash supported that? [20:19:53 CET] <JEEB> or do I remember completely incorrectly [20:19:59 CET] <furq> you might be right tbh [20:20:07 CET] <furq> i know it was flv1 when they first launched and then h264 as of about 2007 [20:20:40 CET] <furq> but flash tried to deprecate flv1 in favour of vp6 at some point [20:20:49 CET] <furq> so it's totally plausible [20:20:59 CET] <JEEB> > Flash Video FLV files usually contain material encoded with codecs following the Sorenson Spark or VP6 video compression formats. [20:21:05 CET] <damdai> another: pretty much every video format before h264 sucks [20:21:06 CET] <furq> right [20:22:35 CET] <damdai> youtube was using vp6 ? i wonder how good/bad is vp6 [20:22:48 CET] <furq> it's two worse than vp8 [20:23:06 CET] <damdai> wmv9 was best format before h264 but seeking is slow [20:27:24 CET] <damdai> <furq> it's two worse than vp8 , that doesn't tell me much [20:39:59 CET] <TSaari> (JEEB: pm pong, making sure) [20:48:07 CET] <ossifrage> I've been playing with trying to compile a minimal ffmpeg, I'm only using libavformat. If you build with --disable-avcodec --enable-avformat, it doesn't actually build avformat. [21:13:54 CET] <ossifrage> Also, even though I don't have jpeg turned on, I'm picking up a symbol dep for avpriv_mjpeg_bits_dc_chrominance [21:17:45 CET] <faLUCE> ossifrage: because formats are linked to codec contexts [21:18:45 CET] <ossifrage> Yeah, but I'm running with --disable-{encoders,decoders,muxers,demuxers,parsers,..} and only turning on what I need [21:19:29 CET] <ossifrage> faLUCE, and none of them are *jpeg* [21:20:20 CET] <faLUCE> ossifrage: which compiler error do you have? [21:20:33 CET] <ossifrage> undefined reference to `avpriv_mjpeg_bits_dc_chrominance' [21:20:57 CET] <ossifrage> and several other avpriv_mjpeg_bits_* [21:21:41 CET] <faLUCE> ossifrage: paste the error. I don't understand if is it a linker or a compiler error [21:21:49 CET] <ossifrage> link time [21:22:13 CET] <ossifrage> ...../libavformat.so: undefined reference to `avpriv_mjpeg_bits_dc_chrominance' [21:23:02 CET] <faLUCE> are you compiling ffmpeg or a program with libavcodec ? [21:23:47 CET] <ossifrage> a program linking against ffmpeg, ffmpeg itself compiles just fine [21:24:05 CET] <faLUCE> so, a program with libavcodec, right? [21:24:33 CET] <ossifrage> The program only links with .. -lrt -lavutil -lavformat [21:25:37 CET] <ossifrage> (which worked when I had a big ffmpeg, compile, but it picked up a huge pipe of dep libraries) [21:26:31 CET] <faLUCE> but how did you disabled the codec? [21:26:39 CET] <faLUCE> but how did you disabled the codecS? [21:27:22 CET] <faLUCE> I mean: you can disable separate codecs, but I don't think you can disable the codec library [21:27:26 CET] <ossifrage> You can't do --disable-avcodec, but you can do --disable-encoders --disable-encoders [21:27:42 CET] <ossifrage> (err --disable-decoders) [21:27:47 CET] <JEEB> also probably parsers? [21:27:51 CET] <JEEB> unless you need those :P [21:28:33 CET] <ossifrage> It doesn't help that I'm cross compiling this with buildroot which complicate things [21:28:59 CET] <ossifrage> Yeah, the goal is to get a starting point that is the minimal set to do h264/hevc -> mp4 muxing [21:29:00 CET] <faLUCE> ossifrage: then, you just have to add lavcodec to the linker [21:29:13 CET] <JEEB> just means that you want to first optimize it outside of that natively :P atl east that IMHO would be a faster way of iterating [21:29:33 CET] <JEEB> anyways, you can start figuring out what exactly brings what in [21:29:44 CET] <faLUCE> ossifrage: the linker shows that you did not link avcodec. [21:30:07 CET] <ossifrage> JEEB, I did do that but just to compile ffmpeg, but I didn't bother testing the library because what I'm building won't build on the host [21:30:24 CET] <JEEB> the symbol you mentioned is in lavc's jpegtables [21:30:31 CET] <JEEB> and actually the table is being utilized from libavformat! [21:30:38 CET] <JEEB> rtpdec_jpeg [21:30:41 CET] <JEEB> needs that for some reason [21:31:00 CET] <ossifrage> faLUCE, previous when the ffmpeg had a big pile of stuff in it I did *not* need to link against -llibavcodec, that dep got picked up by the linker [21:31:21 CET] <ossifrage> I do have --enable-muxer=rtp [21:31:32 CET] <JEEB> configure:rtpdec_select="asf_demuxer jpegtables mov_demuxer mpegts_demuxer rm_demuxer rtp_protocol srtp" [21:32:01 CET] <JEEB> the RTP "demuxer" needs that stuff [21:32:33 CET] <JEEB> also rtpenc *also* uses jpegtables.h... [21:32:56 CET] <JEEB> ok, so I just didn't notice it with the first git grep [21:33:04 CET] <ossifrage> JEEB what turns on jpegtables? [21:33:06 CET] <JEEB> both the RTP JPEG demuxer and muxer in libavformat [21:33:14 CET] <JEEB> include and utilize that symbol that you noted [21:33:20 CET] <faLUCE> ossifrage: then, in the previous situation, you did not link against libavcodec but you did not use --enable-muxer=rtp, right? [21:33:39 CET] <JEEB> ossifrage: but it seems like rtpenc doesn't have a dependency on jpegtables [21:33:42 CET] <JEEB> that might be a bug [21:34:01 CET] <JEEB> if you look at configure and grep "jpegtables" which is what provides that symbol [21:34:04 CET] <ossifrage> The previous working build did not have any --disable-{codec,muxers,...} [21:34:14 CET] <ossifrage> It was just the whole thing [21:34:25 CET] <faLUCE> ossifrage: ok, but it did not have --enable-muxer=rtp, right? [21:34:25 CET] <JEEB> yes, thus something else brought the dependency in most likely [21:34:34 CET] <JEEB> like rtpdec [21:34:46 CET] <ossifrage> Yup no --enable-{muxer,demuxer,...} lines [21:35:03 CET] <faLUCE> ossifrage: then it's the --enable-muxer=rtp thant wants libavcodec [21:35:27 CET] <JEEB> ossifrage: anyways so what your actual issue is? "extraneous" symbol requirements or something else? does the pkg-config file get generated with correct dependencies? [21:35:51 CET] <JEEB> (the RTP muxer does not that symbol you mentioned so it's not extraneous as long as you have the RTP JPEG muxer enabled) [21:36:05 CET] <JEEB> *RTP muxer needs that symbol [21:36:13 CET] <JEEB> multitasking and English are not good :P [21:36:16 CET] <ossifrage> I thought the extra deps came from the .so [21:36:39 CET] <JEEB> .so will have deps too [21:36:42 CET] <JEEB> for the runtime linker [21:36:50 CET] <JEEB> (as opposed to the build-time linker) [21:37:27 CET] <JEEB> and yes, my question would also be regarding if there's a missing dep if you disable RTP "decoder" in libavformat since the RTP "encoder" uses the jpegtables thing as well but configure doesn't seem to have it listed [21:37:56 CET] <faLUCE> ossifrage: so, consider to use another rtp library [21:38:14 CET] <JEEB> wat [21:39:01 CET] <faLUCE> I mean: if you can't modify the code, you could use another rtp library [21:39:05 CET] <ossifrage> I'm not using rtp right now, I just added it for future use. [21:39:18 CET] <faLUCE> so you won't have linker errors [21:39:58 CET] <ossifrage> Patching is just fine and very common for cross compile builds like this [21:40:31 CET] <ossifrage> I'm trying without the rtp stuff [21:41:17 CET] Action: JEEB sighs [21:41:51 CET] <ossifrage> My point for bring this up is that the ./configure hell seems to be missing some deps [21:42:00 CET] <JEEB> yes, which is what I tried to confirm [21:42:11 CET] <JEEB> but I didn't get a reply [21:42:12 CET] <JEEB> :V [21:42:32 CET] <JEEB> because it seemed like mjpegtables was being utilized from the RTP "encoder", but only marked as a dependency for the RTP "decoder" [21:42:55 CET] <ossifrage> I had rtp enabled for the muxers [21:42:56 CET] <JEEB> thus it was a valid dependency from libavcodec, even if by the symbol name you might have thought of it as an unnecessary thing [21:43:22 CET] <JEEB> yes I know, that's the goddamn reason why I am trying to confirm what your goddamn issue was [21:43:38 CET] <JEEB> if there was a dependency on another lib's symbol which wasn't getting done through the dynamic linker or whatever [21:44:15 CET] <JEEB> you can also check if it gets fixed by enabling the RTP demuxer [21:44:24 CET] <JEEB> because that one has the dependency marked [21:44:26 CET] <JEEB> if it does, it's a bug [21:44:27 CET] <JEEB> :P [21:45:14 CET] <faLUCE> JEEB: but rtp jpeg needs that table, so why do you think it could be a bug? [21:45:52 CET] <ossifrage> Removing the --enable-muxer=rtp fixed the problem [21:46:03 CET] <faLUCE> ossifrage: as I said before ;-) [21:46:08 CET] <ossifrage> I had --disable-demuxers set [21:46:17 CET] <JEEB> faLUCE: THE LACK OF DEPDENDENCY [21:46:23 CET] <JEEB> vittu saatana read what I said [21:46:24 CET] <JEEB> please [21:46:35 CET] <JEEB> if it uses a symbol and doesn't depend on what provides it [21:46:59 CET] <JEEB> and of course disabling the rtp muxer fixes it as well, but I was more interested in if it gets fixed by enabling the demuxer [21:47:06 CET] <JEEB> because then marking the dependency fixes it [21:47:07 CET] <JEEB> vittusaatana [21:47:44 CET] <faLUCE> JEEB: afaik mjpeg tables are needed both by the demuxer and the muxer [21:47:50 CET] <JEEB> I KNOW [21:47:52 CET] <JEEB> I JUST FUCKING SAID THAT [21:48:04 CET] <faLUCE> JEEB: be calm [21:48:18 CET] <ossifrage> JEEB, sorry, but this crap compiles pretty slowly, I had already started the build without the rtp stuff [21:48:32 CET] <ossifrage> I'll go back and try again with the muxer and demuxer [21:48:47 CET] <JEEB> faLUCE: I knew that in theory enabling the dependency should fix it, but I was still fucking not sure what was ossifrage's actual issue [21:48:55 CET] <JEEB> so if adding a component that rightly has that dependency [21:49:03 CET] <JEEB> fixes th eissue [21:49:11 CET] <JEEB> then adding that dependency to rtpenc would fix it [21:49:20 CET] <JEEB> I was just fucking trying to get that fucking confirmation for fuck's sake [21:49:46 CET] Action: JEEB goes away to calm down for a bit [21:52:56 CET] <JEEB> ossifrage: also you can just build locally without doing cross-compile or anything. the issue should be visible without all that [21:53:15 CET] <JEEB> also, most cross-compiles to ARM or otherwise have actually had zero patching [21:53:41 CET] Action: JEEB has done ARMv7 standard lunix, ARMv7 and aarch64 android, win32/64 [21:53:47 CET] <ossifrage> JEEB, I thought everything was ready to go when I compiled it locally, which is why I switched to the cross build [21:54:18 CET] <JEEB> I was mostly referring to you saying it takes long to compile :P [21:54:18 CET] <ossifrage> Yeah ARM stuff cross compiles really well [21:54:33 CET] <JEEB> so you don't have to test with whatever you're compiling for [21:54:42 CET] <JEEB> you could just do a local x86_&4 build with similar params [21:54:53 CET] <JEEB> unless you meant that as taking time [21:55:33 CET] <ossifrage> The minimal x86_64 compile is fast, but it wasn't actually compiling something that linked against the library [21:55:59 CET] <JEEB> you should be able to check with ldd or something [21:56:10 CET] <JEEB> although that only has the dependencies there [21:56:16 CET] <JEEB> I don't think it checks for missing symbols? [21:56:29 CET] <JEEB> although I would have thought that would get a failure during link phase in building? [21:56:33 CET] <JEEB> (of FFmpeg that is) [21:56:55 CET] <ossifrage> BR2_PACKAGE_FFMPEG_MUXERS="dash,hls,h264,hevc,mov,mp4,m4v,smoothstreaming,segment,webvtt,rtp" [21:56:55 CET] <ossifrage> BR2_PACKAGE_FFMPEG_DEMUXERS="dash,hls,h264,hevc,mov,m4v,webvtt,rtp" [21:57:28 CET] <ossifrage> That results in the jpeg tables dep, it worked without rtp [21:57:44 CET] <ossifrage> Adding -lavcodec does not help [21:58:02 CET] <JEEB> rtpdec should have the jpegtables dep [21:58:22 CET] <JEEB> (you can look at git grep "jpegtables" -- configure [22:01:22 CET] <ossifrage> is rtpdec the same as the demuxer/muxer? I only turned on the muxer/demuxer, not the encoder/decoder (none of the encoder/decoders are enabled at ./configure) [22:01:53 CET] <JEEB> yea, the nomenclature is just used for (de)muxers as well in some file names etc [22:16:49 CET] <damdai> anybody who is video expert who can maybe help me? [22:17:53 CET] <damdai> i have like 6 1920x1080 2 are sharp/looksgood 2 are grainy/non-sharp 1 = grainy/sharp [22:18:14 CET] <damdai> they are all 1920x1080 so they are all HD [22:18:50 CET] <damdai> but 2 of them just looks bad [22:18:53 CET] <damdai> why is that [22:22:54 CET] <Mavrik> damdai, did the camera have the wrong focus set? :) [22:23:39 CET] <damdai> mavrik maybe, i am trying to figure out, if it's lighting/wrongcamerasetup/editing [22:23:46 CET] <damdai> or something else [22:24:04 CET] <Mavrik> Also, besides resolution, the quality of an encoded video is also determined by the bitrate [22:24:17 CET] <Mavrik> But before you go look at that, first figure out if your source was the same :) [22:24:32 CET] <damdai> they all use h264 with similar bitrate [22:25:08 CET] <damdai> Overall bit rate : 10.2 Mb/s [22:25:08 CET] <damdai> Encoded date : UTC 2010-12-14 01:52:31 [22:25:08 CET] <damdai> Tagged date : UTC 2010-12-14 01:52:31 [22:25:08 CET] <damdai> Writing library : Apple QuickTime [22:26:00 CET] <damdai> they all are 10.2Mb/s apple qt [23:31:37 CET] <ncouloute> So I have a slight variable fps interlaced file that I converted with ffmpeg the resulting file seems to have frames missing and the time stamp is off. Any advice on that? I dont have an deinterlacing settings in play but it seems it was deinterlaced automatically which is what i want anyways. Using fps filter to convert to 60000/1001 [23:55:56 CET] <KombuchaKip> What is the current state of the relationship between libav and ffmpeg? I know it was bad in the past. [23:59:03 CET] <JEEB> nobody really cares at this point. The loud people from both sides are long gone. Libav is at this point a hobby project of a few people who know what they want from the thing, and FFmpeg is the mess it is (in both good and bad) [23:59:28 CET] <JEEB> speaking as someone who has contributed to both [00:00:00 CET] --- Sun Mar 17 2019

1 0