Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2017

1 participants
62 discussions

ffmpeg-devel.log.20171210
by burek 11 Dec '17

11 Dec '17

[04:54:27 CET] <cone-765> ffmpeg 03James Almer 07master:a4fc63c0f9eb: x86/lossless_videodsp: don't overread the dst buffer in ff_add_left_pred_unaligned_avx2 [04:54:28 CET] <cone-765> ffmpeg 03James Almer 07master:438f884fc48b: x86/lossless_videodsp: rename ff_add_left_pred_int16_sse4 to ff_add_left_pred_int16_unaligned_ssse3 [04:54:29 CET] <cone-765> ffmpeg 03James Almer 07master:1215889bc189: checkasm/llviddsp: fix mixed code and declarations [12:22:47 CET] <durandal_1707> why everybody is silent when big stuff is posted on ml, but like to shit about it when nobody tackles it? [12:51:01 CET] <atomnuker> everyone's silent because its sunday and for some reason everyone's silent on sundays [13:08:32 CET] <durandal_1707> atomnuker: no, devs are worse people than users [13:17:16 CET] <durandal_1707> i will spam ml until you accept all my patches, enjoj spam! [14:02:17 CET] <JEEB> begesus [14:09:29 CET] <wm4> I see 154 new mails - yeah, not today [14:18:17 CET] <durandal_1707> what not today? [14:43:20 CET] <cone-761> ffmpeg 03Mateusz 07master:149268b47c4b: fix MSVC compilation errors [15:29:52 CET] <durandal_1707> atomnuker: atrac9 released, do you want to write decoder for lavc? [15:32:38 CET] <JEEB> I thought ATRAC9 was released ages ago? [15:32:51 CET] <JEEB> I've had some binaries for it since... [15:33:08 CET] <JEEB> nov, 2015 [15:33:10 CET] <durandal_1707> the SOURCE [15:33:13 CET] <JEEB> oh [15:33:39 CET] <JEEB> well that's an unexpected change of events if it got OSS'd :P [15:34:11 CET] <durandal_1707> it was REd [15:34:57 CET] <JEEB> https://github.com/Thealexbarney/VGAudio/tree/atrac9-docs/docs/atrac9 [15:35:01 CET] <JEEB> at least some docs [15:35:06 CET] <durandal_1707> in this cs files [15:35:14 CET] <durandal_1707> C sharp for you [15:35:23 CET] <JEEB> yea, it's a UWP app [15:35:54 CET] <JEEB> wait :D [15:35:58 CET] <JEEB> https://github.com/Thealexbarney/VGAudio/commit/42cede619a6afba149da7ec2d80… [15:36:12 CET] <JEEB> > At9ToolPath = Path.Combine(directory, "at9tool.exe") [15:36:26 CET] <JEEB> oh there we go [15:36:27 CET] <JEEB> https://github.com/Thealexbarney/VGAudio/commit/6a4062cc43da458dc71b698de77… [15:36:38 CET] <atomnuker> durandal_1707: there's no code, right? [15:36:46 CET] <JEEB> see the last commit I posted [15:36:53 CET] <JEEB> that seems like their decoder [15:37:21 CET] <JEEB> also the ATRAC3+ decoder needs to be fixed to work with MPEG-PS. it's been on my roadmap for a while but all the other things have popped up instead :V [15:37:39 CET] <JEEB> currently the decoder wants all the info in extradata [15:37:43 CET] <JEEB> but there's a format with a per-frame header [15:37:48 CET] <JEEB> which is used in MPEG-PS [15:38:24 CET] <JEEB> there were some attempts by the PPSSPP guy and the Shiz but they never got through due to the parser not being right or something [15:38:42 CET] <JEEB> since i think they were poking extradata from the parser or something [15:39:08 CET] <JEEB> how does lavc in general handle formats like this btw? [15:39:29 CET] <JEEB> is it just a case of checking "is there something in avcodeccontext?" [15:39:34 CET] <atomnuker> what does the PS stand for? [15:39:43 CET] <JEEB> it's standard MPEG-PS [15:39:53 CET] <JEEB> program stream [15:40:12 CET] <durandal_1707> atomnuker: it have imdct, so code is available [15:40:22 CET] <JEEB> https://github.com/jeeb/ffmpeg/commit/ad1652a0c9ddaf76ee7c1f955057d66c7581b… [15:41:02 CET] <JEEB> also I think I had a newer version which included the header sony used for PS3 [15:41:13 CET] <atomnuker> durandal_1707: yeah I'll do it alongside the denoise filter [15:41:40 CET] <atomnuker> but first I need to finish the bloody atomics and I've encountered a big distraction - pillars of ethernity [15:41:47 CET] <JEEB> heh :D [15:41:51 CET] <durandal_1707> it will be finished in next year? [15:42:57 CET] <atomnuker> maybe not, yesterday I saved av1 thanks to TD-Linux so I should have more time now [15:43:06 CET] <durandal_1707> just write rust decoder i will c one [15:43:38 CET] <atomnuker> bah sorry mate I don't write rust just loads of C code [15:45:34 CET] <iive> i thought we are rewriting ffmpeg in rust ;) [15:47:35 CET] <durandal_1707> iive: thats your only full time job [15:52:32 CET] <iive> nope [15:53:18 CET] <durandal_1707> dont nope here [16:34:36 CET] <atomnuker> jamrial / nevcairiel / michaelni: I could use some help with the atomics patches [16:35:38 CET] <atomnuker> I think the only way to solve the locking issue is to use mutexes [16:35:52 CET] <atomnuker> (e.g. when registering filters) [16:36:17 CET] <atomnuker> I can't make the entire array atomic and even if I did another thread trying to add would probably mess things up [16:36:22 CET] <nevcairiel> I still have no clue why you are trying to even change the logic instead of just replacing the atomics functions [16:36:45 CET] <nevcairiel> all of those resolve to the same underlying hardware instructions [16:36:49 CET] <atomnuker> can't replace the bloody avpriv cas function [16:37:00 CET] <nevcairiel> you claim that, but i dont believe you [16:37:09 CET] <atomnuker> have you looked at it? [16:37:15 CET] <nevcairiel> sure [16:37:22 CET] <nevcairiel> i even posted a proposal on the ml [16:37:31 CET] <atomnuker> link? [16:38:20 CET] <nevcairiel> dont have that handy right now, but the gist of it is that compare_exchange_strong is basically the same as the avpriv cas [16:38:32 CET] <atomnuker> well it isn't [16:39:18 CET] <atomnuker> the issue is that the avpriv one takes in a pointer to the new value [16:39:48 CET] <atomnuker> and the c11 one takes a value directly [16:40:28 CET] <atomnuker> this is the main issue why you can't replace it directly, you'll need a temp value to store the newval [16:40:33 CET] <atomnuker> which breaks atomicity [16:42:15 CET] <atomnuker> I think if I take the patches I posted which removed atomics and just added a mutex at start/end it would be better [16:42:40 CET] <atomnuker> because unlike the avpriv function you'll not be locking/unlocking at every iteration while adding a filter but only once [16:42:41 CET] <nevcairiel> static mutexes dont work portably [16:42:53 CET] <nevcairiel> and you have no context to put them in [16:43:16 CET] <atomnuker> what about pthread_once? we have that all over the codebase? [16:43:35 CET] <atomnuker> to init the mutex during the first execution [16:45:33 CET] <nevcairiel> i still dont understand your problem with the cas function, it doesnt take any unexpected arguments, the only difference is that it takes a pointer for the old value (so it can return the found value in it), but that value is NULL initially anyway so it makes no difference what kind of variable it is [16:46:02 CET] <atomnuker> no, it takes a value for the new value, the old one's identical [16:46:32 CET] <atomnuker> and also the avpriv one always returns the old value [16:47:28 CET] <nevcairiel> so does the c11 one, just differently [16:47:32 CET] <atomnuker> but the c11 atomics returns what we need in the old value [16:47:42 CET] <nevcairiel> they both do the exact same thing with different syntax [16:48:12 CET] <atomnuker> I tried to replace them - that was my first attempt and it didn't work [16:48:26 CET] <atomnuker> but if you could show me how to do it properly for one, I could do the rest [16:49:13 CET] <nevcairiel> i can make an actual patch later [16:49:32 CET] <atomnuker> thanks [16:58:39 CET] <wm4> the correct solution is to make the lists static [16:59:34 CET] <atomnuker> yeah, I agree, I don't get why there's a need to register anything at all [16:59:56 CET] <atomnuker> future external filter registration? [17:00:36 CET] <atomnuker> (which is also pointless when you'll just have your own AVFilter struct [17:02:05 CET] <wm4> you can't have external filters because there's a whole load of issues about it needing private APIs [17:02:27 CET] <wm4> and if libs could register process global filters it'd be chaos anyway [17:02:40 CET] <wm4> so that needs to be fundamentally changed from the current API and design anyway [17:02:41 CET] <nevcairiel> more importantly we should fix the currently-broken atomics thing with msvc, either revert the patch because thsoe variables dont need atomic access (they werent even before), or just remove them entirely [17:02:48 CET] <wm4> (but some people don't want to understand this) [17:02:57 CET] <iive> in theory they could be complete autonomous implementations. But somehow this is not feature I like. [17:03:56 CET] <atomnuker> nevcairiel: I posted a patch on the ml to remove them a few days ago, could use a review [17:04:46 CET] <atomnuker> oh nvm, you did post something as a reply but michaelni thought they're useful [17:05:46 CET] <nevcairiel> usually it would likely deadlock from the pthread lockmgr anyway before those things become useufl, but shrug [17:05:56 CET] <atomnuker> michaelni: would you mind if we remove them anyway? [17:10:00 CET] <durandal_1707> there are no 3rd party filters [17:10:57 CET] <durandal_1707> and any 3rd filters are circulated as patches anyway [17:11:20 CET] <nevcairiel> third party registration is not really possible right now, you need too much internal apis to build them [17:12:24 CET] <durandal_1707> what about codecs? [17:13:03 CET] <atomnuker> not possible and with good reason too I think [17:13:11 CET] <JEEB> if we really want to support that it has to be thought well. right now we might as well not have those APIs that seem as if we support it [17:13:24 CET] <JEEB> because currently if someone wants to use that public API that we have they need to use private symbols [17:13:29 CET] <JEEB> which is a no-go anyways [17:13:43 CET] <atomnuker> we do not want to support external codecs, filters maybe, but not codecs [17:14:03 CET] <durandal_1707> no [17:14:14 CET] <nevcairiel> filters maybe in the future [17:14:54 CET] <durandal_1707> there is enough filters, you do not need more ever! [17:15:14 CET] <JEEB> yea, currently we don't properly support external registration so when someone thinks that needs to be properly supported we can think about it. right now fixing builds and possibly cleaning up the public API that doesn't make sense are OK. [17:15:26 CET] <JEEB> if removing that public API for registration is what fixes things, that is [17:15:40 CET] <wm4> if external registration ever becomes possible, it won't be a global registration anyway [17:15:44 CET] <JEEB> yea [17:15:47 CET] <wm4> so the current API and code can't be used [17:15:55 CET] <JEEB> ayup [17:20:07 CET] <durandal_1707> make those functions nop and deprecate them [17:39:35 CET] <michaelni> For an open source project, not supporting external filters is very odd. Also some filters i was considering to write, iam not sure would really fit that well into libavfiler core though i have way too much to do anyway then start working on mor things [17:40:36 CET] <wm4> and here you go, completely ignoring all the arguments [17:40:37 CET] <michaelni> also libavfilter had a usable public API that allowed external filters which is step by step disappearing [17:41:37 CET] <nevcairiel> it was never really usable, and keeping it stable would hinder the ability to further develop avfilter [17:46:00 CET] <cone-761> ffmpeg 03Thomas Guillem 07master:84936f68ede2: lavc: Make hardware config method support more explicit for hwaccels [17:46:12 CET] <michaelni> nevcairiel, i dont agree that it wasnt usable. But of course aou are correct that a public API restricts the kind of changes that can be done. I do belive that a stable and public API is very important. A always changing API is not good even if its not public [17:47:05 CET] <wm4> you mean you want to prevent that some things can ever be fixed or improved [17:48:43 CET] <durandal_1707> if you want to prevent stuff from happening just leave [17:49:35 CET] <jamrial> changing api if it's needed to move forward is obviously acceptable [17:50:06 CET] <michaelni> durandal_1707, do you mean me ? if so i think you misunderstand what i meant, i just stated my oppinion [17:50:25 CET] <jamrial> we're not the win32 kernel. we can remove old deprecated api every couple of years [17:57:36 CET] <iive> michaelni: i would very much prefer if filter you write are in libavfilter, even if they do not fit into the core and use private ffmpeg apis [17:58:12 CET] <iive> I'm still angry at BBB for blocking the 100fps interpolation filter [17:58:38 CET] <durandal_1707> iive: where is such filter posted? [17:58:56 CET] <JEEB> how is a 100Hz interpolation filter any different from the interpolation filters we currently have? [17:59:09 CET] <iive> JEEB: using motion estimation? [17:59:12 CET] <JEEB> yea [17:59:21 CET] <durandal_1707> also michaelni only have to write gpl fitlers [17:59:23 CET] <JEEB> we also have the simple thing that just duplicates stuff [17:59:57 CET] <durandal_1707> no. you are wrong. again. [18:00:01 CET] <iive> JEEB: what's the name of that one? [18:00:21 CET] <JEEB> which one? [18:00:33 CET] <durandal_1707> framerate, fps, minterpolate [18:00:42 CET] <JEEB> but yes, those are the three [18:00:54 CET] <JEEB> first two are simple, minterpolate does actual mocomp etc [18:09:52 CET] <iive> michael's filter has been named vf_mcfps and it has been proposed around august 2015. minterpolate seems to land a year later 2016. [18:11:22 CET] <JEEB> I just replied at the comment about blocking a "100Hz interpolation filter" regarding teh current state [18:12:06 CET] <durandal_1707> why. dont be mean. [18:17:38 CET] <iive> JEEB: i'm glad you did. [18:18:21 CET] <cone-761> ffmpeg 03Mark Thompson 07master:2adfb1092166: configure: Move V4L2 M2M help line to the hardware library section [18:20:11 CET] <iive> anyway, back to the topic. [18:20:36 CET] <jkqxz> Has something horrible happened recently to configure on Windows? "Real 24m26.712s" [18:21:01 CET] <wm4> shell programming [18:22:04 CET] <JEEB> ^ [18:22:04 CET] <jkqxz> I can't see anything in the history, but it was only five minutes or so a week or two ago. [18:22:23 CET] <JEEB> but yea, that sounds real bad [18:22:31 CET] <durandal_1707> Diego happened [18:22:33 CET] <JEEB> and thus makes me real happy that I'm doing the shell part from *nix [18:22:38 CET] <wm4> the deps handling changes make it slower [18:22:44 CET] <JEEB> durandal_1707: that happened more than 2 weeks ago [18:23:08 CET] <jamrial> yeah, but not 24m [18:23:17 CET] <jamrial> it was more like 15m [18:23:19 CET] <JEEB> yea [18:23:31 CET] <wm4> also I suspect a win10 update shat on performance [18:23:42 CET] <wm4> maybe something about fork performance [18:23:48 CET] <jamrial> still awful, but not "lets watch an anime episode while this thing figures out dependencies" awful [18:23:55 CET] <wm4> or filesystem peformance [18:24:02 CET] <wm4> +r [18:24:09 CET] <jamrial> yes, win10 fall creator fucked up somewhere it seem [18:24:16 CET] <jamrial> it wasn't this bad in the previous build [18:24:28 CET] <wm4> but yeah recently running configure on windows has meant "take a break" even more recently [18:24:31 CET] <jkqxz> It uses very little CPU, and feels like it's just not doing anything most of the time. [18:25:09 CET] <jamrial> if you look at task manager, you'll see sh.exe spawning constantly [18:25:47 CET] <durandal_1707> somebody added bunch of sleep calls [18:25:55 CET] <wm4> so when will the current build system be replaced wih cmake [18:26:21 CET] <durandal_1707> next gsoc 2018 [18:26:58 CET] <wm4> ok let's stop the nasty jokes... meson would potentially be good [18:27:00 CET] <jamrial> agree, cmake is what all the cool github c++ kids are using nowadays [18:27:54 CET] <wm4> more realistically, "someone" could probably investigate whether other shells spawn fewer processes [18:28:13 CET] <wm4> and I think someone actually did that? [18:28:21 CET] <JEEB> yea I think ash was faster? [18:29:20 CET] <jamrial> or microsoft could fix whatever broke so we can go back to ~1m configure times [18:29:56 CET] <JEEB> of course that's a thing that I'd like anyways :P [18:30:05 CET] <JEEB> since it most likely would speed up other things as well [18:30:06 CET] <durandal_1707> or fix configure to give rt feedback [18:30:50 CET] <wm4> can their new linux subsys be used for building? [18:30:53 CET] <JEEB> yes [18:31:10 CET] <wm4> hm I assume technicallly that'd be a cross compile [18:31:13 CET] <JEEB> yup [18:31:19 CET] <wm4> weird shit [18:31:36 CET] <JEEB> well, not like cygwin isn't a cross compile either (mingw-w64 compiler in cygwin) [18:31:49 CET] <iive> the spawning slowdown is caused by the tests themselves [18:31:53 CET] <JEEB> just that they all look like "exe"s [18:32:21 CET] <iive> so using another method would be helpful only if they run less tests. [18:32:49 CET] <durandal_1707> tests can run in parallel [18:33:11 CET] <wm4> could, not can [18:34:55 CET] <iive> as for the slowdown. it might be related to antivirus, checking for signatures and even dns/inet lookup. [18:35:13 CET] <iive> there's been an old issue with offline C# startup. [18:37:19 CET] <wm4> dns lookups? [18:44:26 CET] <BtbN> jkqxz, try rebooting [18:44:41 CET] <BtbN> windows has a bug that creating a new process gets slower the more processes it has created since it started [18:45:00 CET] <durandal_1707> huh? [18:45:24 CET] <BtbN> so configure on a fresh boot is like 5-10 minutes, after a couple days of uptime(which is easy, as windows does suspend to disk by default when you tell it to shut down) it goes to shit [18:45:38 CET] <nevcairiel> mine has never done suspend by default [18:45:45 CET] <BtbN> Windows 10 does that [18:45:49 CET] <nevcairiel> not mine [18:45:51 CET] <BtbN> you have to dig deep to turn that off [18:46:02 CET] <BtbN> It being used as dev machine that constantly spews processes doesn't help with that issue either [18:47:11 CET] <jkqxz> Another run got "Real 24m50.485s User 1m48.368s System 2m15.295s", so pretty close to the first one. [18:47:16 CET] <jkqxz> I'll reboot and see if it helps. [18:47:44 CET] <BtbN> https://www.techpowerup.com/235169/windows-10-process-termination-bug-slows… was the related article iirc [19:20:16 CET] <jkqxz> "Real 26m40.647s User 1m52.611s System 2m19.629s" [19:20:17 CET] <jkqxz> Oh well. [19:20:33 CET] <jkqxz> I shall be glad that I do not build on Windows very often. [19:21:43 CET] <JEEB> I just used Fedora's mingw-w64 toolchain and updated mingw-w64 crt and headers manually (for the D3D11 stuff in mpv) [19:27:43 CET] <durandal_1707> JEEB: where you posted that 100Hz mcfps message? [19:27:52 CET] <JEEB> what [19:28:18 CET] <JEEB> I have no idea of the darn context, I just replied that there might (you know, right now) be a reason to say no to a specific mocomp interpolation filter [19:28:24 CET] <JEEB> which is limited to 100Hz [19:29:04 CET] <JEEB> and you were replying on this channel at that time as well [19:29:07 CET] <JEEB> so this is like ?!?!?! [19:29:25 CET] <durandal_1707> yea, very strange [19:29:49 CET] <iive> i don't think it was lmited to 100Hz [19:30:09 CET] <iive> i just used it as generic name... [19:54:37 CET] <durandal_1707> michaelni: and to what it should convert formats instead? [19:55:01 CET] <durandal_1707> you dont like to provide solutions at all [19:59:37 CET] <durandal_1707> i see nothing wrong with it [20:00:25 CET] <durandal_1707> you just dont want to get rid of yuvj and instead picks random nonissues at a whim [20:09:11 CET] <michaelni> durandal_1707, it should not convert twice as it needs just one convertion, noise supports yuv420p which the encoder uses [20:14:01 CET] <durandal_1707> michaelni: i dont think what you reported is valid, the same issue existed before. And since when the encoding pixel format should be in priority when filtering [20:14:34 CET] <nevcairiel> behavior of any given command should not result in a worse result then before [20:15:18 CET] <durandal_1707> the same issue existed before [20:15:37 CET] <durandal_1707> i dont think my patch introduces this [20:16:38 CET] <JEEB> yes, probably not. there's probably an issue somewhere in the filter chain generation [20:16:46 CET] <cone-761> ffmpeg 03Michael Niedermayer 07master:1d0817d56b66: avcodec/amrwbdec: Fix division by 0 in voice_factor() [20:16:47 CET] <cone-761> ffmpeg 03Michael Niedermayer 07master:eaff5fcb7cde: avcodec/vp9_superframe_split_bsf: Fix integer overflow in frame_size/total_size checks [20:17:44 CET] <durandal_1707> its not a bug, first filter can not know encoder format [20:17:58 CET] <durandal_1707> *should not [20:20:30 CET] <michaelni> the format lists are merged step wise, convertion would occur where merge is not sensible or possible, so if noise and the output have a comon format the lists would be merged and no convert would occur there. That is what i would guess should happen but something seems not to work this way after the patches [20:49:05 CET] <cone-761> ffmpeg 03Carl Eugen Hoyos 07master:514cf22a0d3a: lavc/huffyuvenc: Move a variable declaration up. [20:52:11 CET] <durandal_1707> michaelni: there are only 2 cases: convert to encoder fornat first and do filtering or second convert to filter format and do filtering [20:53:53 CET] <durandal_1707> which case have more sense to you? [21:03:43 CET] <michaelni> each filter has a list of formats on each of its in and outputs together with linkage where they need to match. These lists are merged or linked, only once such merging is not possible is convertion needed [21:04:15 CET] <michaelni> this can sometimes be on the input and sometimes be the output side of a filter [21:05:43 CET] <michaelni> in A->B->C if A and B have a common format but B and C do not then convert is needed between B and C if its the other way around then A and B [21:06:57 CET] <michaelni> this worked last time i looked at the code which indeed was some time ago [21:09:55 CET] <durandal_1707> im this case scale is inserted only for color range from output [21:13:06 CET] <michaelni> noise should support any color range, it should not care about it as long as input and output match [21:13:34 CET] <michaelni> so noise out shouldnt need a convert [21:17:49 CET] <cone-761> ffmpeg 03Michael Niedermayer 07release/3.4:c5fd23879ac2: avformat/utils: Fix warning: ISO C90 forbids mixed declarations and code [21:17:50 CET] <cone-761> ffmpeg 03Michael Niedermayer 07release/3.4:60d250386bb1: avcodec/amrwbdec: Fix division by 0 in voice_factor() [21:17:51 CET] <cone-761> ffmpeg 03Michael Niedermayer 07release/3.4:1fab842fbb43: avcodec/vp9_superframe_split_bsf: Fix integer overflow in frame_size/total_size checks [21:56:26 CET] <durandal_1707> michaelni: mpeg encoder does care as it supports limited only color range [22:06:09 CET] <michaelni> yes, the filter chain end has to produce what the next part (the encoder) needs [22:12:43 CET] <durandal_1707> michaelni: so how should i proceed? [22:27:07 CET] <michaelni> i didnt debug this / didnt review all the chnages but spliting color_range out of pixel format should not worsen the amount of inserted converters [22:28:35 CET] <michaelni> maybe s/ not worsen the amount of inserted converters/not make the converter choices worse/ [22:31:28 CET] <michaelni> the audio codepath may have had similar issues to deal with as audio is also split in several paramaters (layout, sample format ...) [22:31:56 CET] <michaelni> s/may have// [22:36:12 CET] <durandal_1707> atomnuker: what you managed to code today? [22:57:10 CET] <cone-761> ffmpeg 03Michael Niedermayer 07release/3.4:bc839fb39dc3: Changelog: Update for the last 3 commits [23:03:48 CET] <durandal_1707> michaelni: i see no code where this can be changed [23:17:01 CET] <cone-761> ffmpeg 03Carl Eugen Hoyos 07n3.4.1:HEAD: lavc/huffyuvenc: Move a variable declaration up. [23:50:22 CET] <BtbN> 115 new mails since a few hour ago... [00:00:00 CET] --- Mon Dec 11 2017

1 0

ffmpeg.log.20171210
by burek 11 Dec '17

11 Dec '17

[00:08:15 CET] <Taity> hi [00:09:12 CET] <Taity> i am using ffmpeg with cuvid accel and nvenc, and i getting a green vertical green line, the video size is 854 x 480 [00:09:32 CET] <Taity> this is the command line i am using: ./ffmpeg -v debug -y -hwaccel cuvid -c:v h264_cuvid -deint adaptive -resize 864x480 -i ./54voONSXMrc.mkv -vcodec h264_nvenc /mnt/disk2/hls/video/out.mp4 [00:09:46 CET] <Taity> is a bug on h264_cuvid ? [00:10:29 CET] <Taity> here https://live01.tvpublica.com.ar/video/ you can get original and the trancoded video [00:10:37 CET] <Taity> to view the results [00:13:09 CET] <Taity> some body can help me? [00:13:19 CET] <Taity> Thanxs [00:15:02 CET] <FishPencil> So it looks like FFmpeg is unhappy with the version of AMF that's found. I'm using version 1.4.4. Here's the output: https://paste.ubuntu.com/26150370/ [00:15:49 CET] <JEEB> looks like it needs just something newer than 1.4.4 [00:15:54 CET] <JEEB> (1.4.4.1+) [00:16:51 CET] <FishPencil> Sooo git? I don't see a 1.4.4.1 [00:21:00 CET] <JEEB> most likely [00:24:05 CET] <FishPencil> Looks like yes, it's building now [00:25:44 CET] <Sun> Seems, my problem is solved, thank You all very much :) [01:00:18 CET] <furq> oh wow, amf [01:08:33 CET] <ArsenArsen> anyone got a C x11grab example. I'm wondering how to do it programatically [01:09:09 CET] <ArsenArsen> (I meant to put a question mark there, oops)\ [01:12:21 CET] <DHE> ArsenArsen: to a certain degree ffmpeg features all operate the same way. you can specifically requst the x11grab demuxer, specify ":0.0" like it was a filename and pass your other input command-line parameters in the AVDictionary [01:13:18 CET] <ArsenArsen> I've noticed they operate the same, and it's amazing, but the real thing killing me right now is how do I manage to sync up the timings properly so it's neither slower nor faster than the required speed. [01:14:32 CET] <DHE> that's handled by x11grab itself, as long as you pull data from it fast enough that it doesn't backlog internally. specify a "framerate" in the AVDictionary to specify how fast [01:15:02 CET] <DHE> ffmpeg -h demuxer=x11grab # and see what's available [01:16:32 CET] <ArsenArsen> alright, so I assume it'll wait until the time's right? [01:23:22 CET] <ArsenArsen> but, another one, does the same apply with GDIGrab or whatever it is on windows [01:23:34 CET] <ArsenArsen> and avifoundation, the mac one [01:24:01 CET] <DHE> don't see why not. query them in the same way (on their respective platforms) to see what options they offer [01:26:52 CET] <ArsenArsen> alright, thank you! [02:50:51 CET] <kepstin> The timing code in gdigrab is just borrowed from x11grab, yeah [02:52:00 CET] <kepstin> other interfaces like webcams and avfoundation, dshow? do timing externally, so ffmpeg just blocks until a frame is available iirc. [04:41:12 CET] <TheRock> Hello i was in the channel #ffmpe, but it doesnt exist [04:43:00 CET] <furq> i don't know what to do with this information [04:44:33 CET] <DHE> I've noted it for future reference and will assign someone to idle in that channel [04:51:46 CET] <TheRock2> if we put 100 idler in #ffmpe, #ffmp, #ffm, #ff. we could cover typing mistakes [04:51:58 CET] <DHE> 2 should be sufficient... [04:52:01 CET] <DHE> I have one [04:58:00 CET] <TheRock2> how do you control the bots ? [04:58:15 CET] <TheRock2> Assuming 350 bots in this channel, anyone must have access to them [05:01:11 CET] <rajkosto> so theres absolutely no way to 1. get frames as soon as they are decoded in decode order 2. have each frame be marked with picture_number [05:01:46 CET] <rajkosto> in ffmpeg ? i can get that stuff off hardware decoders, and i had to do horrible buffering hacks for the ffmpeg way to accomplish this, since it doesnt fill in display_picture_number in avframe (only coded_picture_number) [05:17:38 CET] <kepstin> rajkosto: the libavcodec apis all return frames in presentation order (they're buffered and reordered in the decoder). Why do you want them in decode order? [05:18:11 CET] <kepstin> that said, the dts values should be passed through to the decoded frames, so you should be able to re-sort them yourself [05:18:14 CET] <aiena1> I have wbm video and m4a audoio gow do I merge these into one file? [05:18:19 CET] <aiena1> *webm [05:18:23 CET] <aiena1> *audio [05:18:28 CET] <aiena1> what container is appropriate [05:18:41 CET] <kepstin> you just want it for local playback? [05:19:07 CET] <kepstin> probably use mkv container then, so something like "ffmpeg -i video.webm -i audio.mp4 -c copy combined.mkv" [05:21:36 CET] <aiena1> kepstin: yes [05:22:02 CET] <aiena1> also just curious if given a choice between vp9 and mp4 if size was not a concern which would provide better quality? [05:22:39 CET] <kepstin> if size isn't a concern it doesn't matter, because you can do lossless with both :) [05:22:54 CET] <aiena1> actually that is a bad question would be based on how the encoding was done [05:23:31 CET] <aiena1> just curious about whether youtube vp9 videos are better quality than the mp4 equivalents or the same [05:23:58 CET] <kepstin> it looks like vp9 provides comparable or somewhat better efficiency (quality per bit) than h264, but the libvpx encoder for vp9 is a lot slower than the x264 encoder for h264 [05:24:29 CET] <kepstin> in youtube's case specifically, I think the vp9 encode is usually their highest quality encode. [05:25:43 CET] <kepstin> (If you're downloading videos from youtube, just use youtube-dl and let it pick the "best" format, it can even merge the result into an mkv for you) [05:27:47 CET] <aiena1> kepstin: I am using youtube-dl only I use d acomma instead of a plus [05:32:21 CET] <furq> 04:24:28 ( kepstin) in youtube's case specifically, I think the vp9 encode is usually their highest quality encode. [05:32:24 CET] <furq> yeah it is [05:32:39 CET] <furq> they use roughly the same bitrate for both and i would assume they're using the best settings for libvpx [05:32:52 CET] <furq> on account of they want to push it as a superior format and also on account of how long it takes for vp9 to show up [05:44:31 CET] <rajkosto> kepstin, pts/dts are passed as opaque values yes [05:44:38 CET] <rajkosto> but what if im just decoding an annex-b NAL stream [05:44:56 CET] <rajkosto> and i still want the frames in decode order so that i can reorder them myself [05:45:51 CET] <rajkosto> so i need decode order and reordering info, if i dont need the latter (if im getting the NALs via RTP or similar) then im ok with just 1. which i can already do by giving avcodec_decode_frame a NULL pkt [05:46:38 CET] <kepstin> i'm still a bit confused as to why you want the frames out of order in the first place, rather than just letting ffmpeg reorder than into presentation order [05:49:58 CET] <aiena1> kepstin: when I merge the webm and the mkv I get some artifacts in the video [05:50:05 CET] <aiena1> *webm and m4a [05:53:10 CET] <aiena1> kepstin: I get this one second pixelation in between which on playing the original webm video is not there [05:53:46 CET] <kepstin> aiena1: that's really strange, i'm not sure what could cause that :/ [05:54:25 CET] <rajkosto> kepstin, i just do. its not a very strange use case for the application to want to reorder the frames itself [05:54:44 CET] <aiena1> kepstin: actually sorry it is there in the original video it was hard to find the exact point [05:56:14 CET] <kepstin> rajkosto: it is a pretty strange use case, really; there's hundreds of apps out there using ffmpeg in part because they don't want to have to care about internal codec details like out-of-order predicted frames :/ [05:57:42 CET] <kepstin> either way, there's no way to get un-reordered frames from libavcodec using public apis, afaik. [05:58:17 CET] <kepstin> you might be able to do it using internal apis, e.g. by calling the specific video decoder directly, but i honestly wouldn't know where to start. [05:59:08 CET] <rajkosto> i told you how i can do it [05:59:19 CET] <rajkosto> but you broke that in 3.3 and later [05:59:48 CET] <rajkosto> in 3.2 it works though, just feed a null avpkt to the "deprecated" decode2 interface after youre sure you fed it enough for a full frame [06:00:09 CET] <rajkosto> but it doesnt mark the resulting avframe in any way about the reodering info, neither can i get it with internal contexts [06:01:15 CET] <kepstin> sending a null packet is how you indicate end of stream tho, so you couldn't use that for continuous decoding anyways? [06:01:30 CET] <rajkosto> it works on 3.2 [06:01:37 CET] <rajkosto> i put one frame in, get one frame out [06:01:56 CET] <rajkosto> its not marked with reordering info in any way though, so if im playing a raw annex-b stream i have no clue what its presentation order is [06:02:38 CET] <rajkosto> the solution would be for the decoder to just mark the avframe with display_picture_number like it does with coded_picture_number [06:02:54 CET] <rajkosto> display_picture_number is always 0 for me, maybe im doing something wrong [06:04:16 CET] <kepstin> well, if you're only decoding one frame, of course it'll always be the first frame? [06:05:24 CET] <rajkosto> im not [06:05:30 CET] <rajkosto> and this happens even if i dont do the null packet dance [06:05:43 CET] <rajkosto> also how is it "the first frame" when coded_picture_number is increasing ? [06:06:28 CET] <kepstin> sending a null packet means "end of stream, flush the decoder", and continuing to use the encoder after that is undefined behaviour [06:06:55 CET] <kepstin> and if you don't do that, you should be getting frames in presentation order, with *something* useful in the pts and probably dts fields. [06:07:10 CET] <aiena1> kepstin: does ffmpeg have a vp9 encoder? [06:07:29 CET] <aiena1> vp9 has creates really small file sizes with very little loss in quality [06:07:32 CET] <kepstin> aiena1: not built-in, but it can encode vp9 using the libvpx library [06:07:41 CET] <rajkosto> kepstin, no, what i get in pts/dts is just what i put in the avpacket pts/dts [06:07:47 CET] <aiena1> so how do I do that on say ubuntu? [06:07:50 CET] <rajkosto> if i put nothing there or AV_NOPTS_VALUE i still get that back [06:08:22 CET] <rajkosto> kepstin, before 3.3, sending a null packet does not do that. you have to manually do avcodec_flush_decoder [06:08:25 CET] <kepstin> rajkosto: oh, you're putting nals directly into the decoder, rather than going through ffmpeg's parser? [06:08:38 CET] <rajkosto> im putting annex-b chunks of nals for exactly one frame each time [06:09:03 CET] <aiena1> kepstin: oh ffmpeg needs to be compiled with vp9 support? [06:09:06 CET] <rajkosto> even with ONLY this information, it KNOWS how to reorder the frames if i dont flush it with NULL each time [06:09:12 CET] <aiena1> so I need to build from source? [06:09:16 CET] <kepstin> aiena1: with libvpx support, yes. [06:09:30 CET] <kepstin> most ffmpeg packages should have that by default nowadays... [06:09:52 CET] <rajkosto> i just want to get this reordering information out WITHOUT actually introducing the max_num_b_frames latency beefore i can get pixels out [06:09:56 CET] <aiena1> kepstin: how do I check if mine has it? [06:10:29 CET] <kepstin> aiena1: "ffmpeg -h encoder=libvpx-vp9" should print several pages of options if you have it [06:13:01 CET] <aiena1> kepstin: hmm there is a --enable-libvpx [06:13:11 CET] <aiena1> but no -vp89 [06:13:16 CET] <aiena1> is libvpx vp8? [06:13:24 CET] <kepstin> aiena1: libvpx encodes both vp8 and vp9 [06:13:26 CET] <rajkosto> i just need to fill hardware buffers with frames as soon as i decode the input frame, it doesnt matter if its not in presentation order as long as i can mark it [06:13:37 CET] <aiena1> kepstin: ok so I have it that means [06:13:50 CET] <aiena1> now ned to see how to rencode an mp4 [06:13:55 CET] <aiena1> need [06:14:02 CET] <aiena1> let me dig up documentation [06:14:08 CET] <aiena1> ffmpeg is huge though [06:14:12 CET] <kepstin> aiena1: don't re-encode an mp4 if you don't have to, it'll *always* drop in quality since it's a lossy-lossy decode [06:14:17 CET] <rajkosto> there's no need for ffmpeg to reorder the frames for me as i will be doing it myself, right now i have to hack around this "feature" [06:14:38 CET] <kepstin> rajkosto: it sounds like you're trying to do something that the ffmpeg api doesn't support, and were previously making use of undocumented/undefined behaviour to do it, which broke. [06:14:44 CET] <rajkosto> by lying to the API user and stashing buffers around until i can fill them, and the performance isnt consistent because of it [06:14:52 CET] <aiena1> kepstin: ok [06:14:57 CET] <rajkosto> kepstin, no. i was NEVER able to get the reorder info out ! [06:15:02 CET] <rajkosto> im fine with staying on 3.2 [06:21:03 CET] <kepstin> rajkosto: at this point, the best I could suggest is filing a ticket saying "please add an api to get un-reordered frames (with reordering info)" and hoping that you can find someone other than you who wants this to help out :/ [06:21:15 CET] <kepstin> but it would be really painful to add, would require modifications to all the decoders [06:21:58 CET] <rajkosto> or they could just not have the decode2 api be a wrapper around the new push/pull apis (which are the first one to designate null packets as end of stream), and then just fill in display_picture_number [06:22:20 CET] <rajkosto> actually it might be pretty easy to fill in display_picture_number myself by editing the decoder, but ffmpeg is written in an entirely "mess of C code" way that its indecipherable [06:33:06 CET] <Aelius> I found a very weird bug [06:33:12 CET] <Aelius> https://i.imgur.com/yuGZ5ny.png [06:37:01 CET] <Aelius> context: I have Windows set to use jpn locale for non unicode programs [06:37:24 CET] <Johnjay> i dunno where else to ask this [06:37:27 CET] <Aelius> somehow, ffprobe is taking that and running with it unnecessarily [06:37:35 CET] <Johnjay> but i can't seem to use my video download extension on mp2t stuff [06:37:37 CET] <Aelius> clearly the environment can display russian [06:38:02 CET] <Johnjay> is there a way to download those things somehow, like with curl or something? [06:38:27 CET] <Aelius> "download those things" where from? [06:39:02 CET] <Aelius> but as with all things media-scraping, go try youtube-dl. It'll probably work. [06:39:03 CET] <Johnjay> from a webpage with embedded video [06:39:10 CET] <Johnjay> i tried it [06:39:25 CET] <Johnjay> at least with the main url [06:39:25 CET] <Aelius> then there is no hope [06:39:31 CET] <Johnjay> maybe i can get a url from the page somehow it will accept [06:39:46 CET] <kepstin> if youtube-dl doesn't get it, then you'll have to manuall attempt to find a stream url, yeah [06:40:15 CET] <Johnjay> well my video download plugin shows a dozen links [06:40:22 CET] <Johnjay> all about a few KB or 1 MB in size [06:40:25 CET] <Johnjay> instead of one video link [06:40:33 CET] <Johnjay> i guess that's somehow related to the mp2t part [06:40:43 CET] <kepstin> Johnjay: it might be segmented video, you should look for an 'm3u8' file [06:41:04 CET] <kepstin> that's the playlist, which you can use ffmpeg to download and put into a container. [06:50:32 CET] <Johnjay> hmm there was an m3u8 on the other one [06:51:52 CET] <Johnjay> ffmpeg can download it? [06:52:37 CET] <Johnjay> hmm i tried feeding it to -i and it rejected it [06:52:57 CET] <Johnjay> unknown error [07:37:53 CET] <dystopia_> hello [07:38:23 CET] <dystopia_> im trying to downscale a video and stream it from one pc on my lan to another one [07:39:31 CET] <dystopia_> https://pastebin.com/raw/dZ5K5Ju0 [07:40:09 CET] <dystopia_> No application or playpath in URL! [07:40:09 CET] <dystopia_> RTMP_Connect0, failed to connect socket. 10061 (Unknown error) [07:40:09 CET] <dystopia_> rtmp://localhost:2345: Unknown error occurred [07:40:19 CET] <dystopia_> does anyone know what im doing wrong? [09:36:23 CET] <dystopia_> got it working [12:33:44 CET] <Fyr> guys, I'm trying to convert WAV or FLAC into ALAC in MP4 container. I get: [12:33:44 CET] <Fyr> [mp4 @ 0000000000389e20] Could not find tag for codec alac in stream #0, codec not currently supported in container [12:34:16 CET] <Fyr> it always worked like a charm, now I get this error. [12:34:22 CET] <Fyr> what has been changed? [12:34:39 CET] <durandal_1707> what version? [12:34:53 CET] <Fyr> stable 3.4 and one of the latest from git. [12:35:45 CET] <durandal_1707> i think you want .mov? [12:35:52 CET] <Fyr> mp4 [12:35:55 CET] <Fyr> or m4a [12:37:33 CET] <durandal_1707> m4a should work [12:38:36 CET] <Fyr> strange, but it works. [12:39:06 CET] <Fyr> durandal_1707, why does FFMPEG see difference between mp4 and m4a? [12:41:16 CET] <Fyr> durandal_1707, now I need to mux a video and an ALAC m4a into mp4. [12:41:37 CET] <Fyr> how can I do that? [12:54:35 CET] <durandal_1707> Fyr: i dont think mp4 supports alac [12:54:53 CET] <Fyr> MP4 and M4A is the same thing. [12:54:58 CET] <durandal_1707> nope [12:55:09 CET] <durandal_1707> find mp4 with alac [12:55:10 CET] <Fyr> what's the difference? [12:55:34 CET] <durandal_1707> see source code [12:55:44 CET] <Fyr> I muxed many ALAC files into MP4 with FFMPEG a few years ago. [13:12:02 CET] <Netun0> sorry, ffmpeg are still working with youtube live? [13:16:45 CET] <Netun0> it's why IRC is almost dead, channel is full of people but no talks. [13:17:29 CET] <durandal_1707> lol [13:18:35 CET] <durandal_1707> Netun0: what you use for youtube live? [13:21:47 CET] <Netun0> ffmpeg -re -f x11grab -video_size 1024x768 -i :1 -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p \ [13:21:47 CET] <Netun0> -acodec libmp3lame -ar 44100 -b:a 128k -f flv -s 426x240 \ [13:23:03 CET] <Netun0> -f tee "rtmp://a.rtmp.youtube.com/<key>|rtmp://live.twitch.tv/app/<key> [13:23:07 CET] <Netun0> durandal_1707: thanks [13:24:53 CET] <Netun0> ffmpeg -re -f x11grab -video_size 1024x768 -i :1 -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p -f flv -s 426x240 rtmp_url/key [13:26:18 CET] <Netun0> I have tried all kind of arguments, if I output to file works nicely. [13:42:34 CET] <c_14> and what's the problem? [13:42:47 CET] <c_14> I know twitch for one has hard gop size requirements, which you don't seem to be setting at all [13:43:13 CET] <c_14> can your computer encode preset slow in realtime? [13:46:37 CET] <Netun0> c_14: changed to medium. [13:49:40 CET] <Netun0> Trying periscope It seems better to diagnose. so, It now shows in red the msg "Max keyframe interval: 3.0 s." [13:50:01 CET] <Netun0> ffmpeg -re -f x11grab -video_size 1024x768 -i :1 -c:v libx264 -preset medium -crf 3 -c:a aac -b:a 64k -pix_fmt yuv420p -r 30 -g 15 -b:v 800k -bufsize 512k -f flv -s 960x540 rtmp://or.pscp.tv:80/x [13:53:32 CET] <c_14> your probably want to pass -x264-params keyint=60 since I think that's a harder limit than -g [13:54:13 CET] <c_14> ah, no [13:54:17 CET] <c_14> -g 60 maps to that [13:56:56 CET] <Netun0> c_14: let me see here, thanks. [14:10:16 CET] <Netun0> switched from 800k to 2500k too. [14:36:13 CET] <Netun0> at periscope now it goes live but black screen.. :( [14:59:18 CET] <Netun0> give up [15:01:02 CET] <Fyr> guys, what is the least harmful way to change yuv444p to yuv420p? [15:08:40 CET] <kerio> average U and V? [15:09:02 CET] <DHE> I was going to say "at the last possible second"... [15:09:45 CET] <dystopia_> stick "-pix_fmt yuv420p" on your line and hope it looks good [15:11:01 CET] <Fyr> dystopia_, FFMPEG will use standard parameter set, like CRF 23, profile auto, preset medium etc. [15:11:01 CET] <durandal_1707> Fyr: use zscale filter [15:12:26 CET] <Fyr> thanks [15:13:53 CET] <JEEB> Fyr: only for those lossy encoders that people have cared about, btw. the global libavcodec defaults are still 200kbps and some mpeg-1 level parameters :) (generally relevant to the internal ones) [15:14:40 CET] <JEEB> I think libx264 still has a check in its code base that errors out if the old FFmpeg defaults are used :D [15:15:36 CET] <JEEB> (before libx264 wrapper overrode the lavc defaults) [15:28:36 CET] <kerio> lmao [15:49:26 CET] <Tester_> can I ask about ffmpeg commands here? I imagine yes.. so [15:49:51 CET] <Tester_> basically I wanna batch convert .wav to .mp4 , adding a still image [15:50:19 CET] <Tester_> i know examples of this are all over the internet [15:50:31 CET] <Tester_> but I'm getting error after error [15:51:55 CET] <Tester_> https://pastebin.com/v5jruaTc [15:52:00 CET] <Tester_> I'm on windows 10 [15:52:23 CET] <dystopia_> https://trac.ffmpeg.org/wiki/Slideshow worth a read Tester_ [15:52:50 CET] <c_14> Tester_: that doesn't show the output [15:52:58 CET] <durandal_1707> you pasted command but not and output [15:54:18 CET] <Tester_> https://pastebin.com/RXHpxyC6 [15:55:05 CET] <durandal_1707> use video with width divisible by 2 [15:55:10 CET] <Tester_> that`s the error only, but I think I`ll follow dystopia_ `s advice [15:55:19 CET] <Tester_> hmmm [15:55:23 CET] <Tester_> will try that [15:56:43 CET] <dystopia_> load a scaler and scale it to like 1920 while maintaining mod2 [15:58:03 CET] <dystopia_> -sws_flags spline -vf scale=1920:-4,setsar=1/1 [15:58:12 CET] <dystopia_> add that to your line for example [16:08:38 CET] <Tester_> dystopia_: that worked, thanks. It's pretty slow now though. I'll keep tweaking [17:39:59 CET] <therage3> so i've been doing some research on this cartoon i've been trying to rip properly for a while now [17:40:05 CET] <therage3> i came across this today [17:40:07 CET] <therage3> https://www.animemusicvideos.org/guides/avtech31/video-analyze.html [17:40:43 CET] <therage3> it seems parts of the cartoon use a Partial Field Blended Source method [17:40:53 CET] <therage3> which, as the page states, is pretty much impossible to fix <.< [18:17:12 CET] <furq> therage3: http://avisynth.nl/index.php/Srestore [18:18:06 CET] <therage3> furq: interesting, looks pretty fiddly though [18:18:29 CET] <furq> i've used that before on a really shit field blended pal dvd and got decent results [18:18:44 CET] <furq> i might still have the script somewhere but iirc i pretty much used the defaults [18:18:51 CET] <therage3> furq: interesting [18:19:04 CET] <furq> you're obviously never going to get comparable results to a good source though [18:19:12 CET] <therage3> right [18:36:15 CET] <Lunchbox> anyone have suggestion on how to maintain the same colors in a video being upscaled from 360p to 720p? i change the color matrix from 601 to 709 after scaling but it still looks off [18:36:36 CET] <ritsuka> either use the same color matrix as the input [18:36:45 CET] <ritsuka> or use the colorspace conversion filter [18:37:15 CET] <Lunchbox> if i use the same color matrix the colors look way off after upscaling [18:37:32 CET] <Lunchbox> ill look up the conversion filter [18:37:35 CET] <ritsuka> did you set the color primaries and transfer function too? [18:38:02 CET] <ritsuka> if you don't set them, the player will guess the colorspace [18:38:34 CET] <Lunchbox> i just used -vf colormatrix=bt601:bt709 [18:39:13 CET] <ritsuka> you need the other values too [18:39:23 CET] <durandal_1707> colormatrix is old, incorrect and bad [18:39:30 CET] <ritsuka> color matrix is just for the yuv<->rgb conversion [18:39:48 CET] <Lunchbox> ok haha well how do i do this correctly then [18:40:46 CET] <Lunchbox> am i at least correct for using 601 on the initial 360p video? [18:40:53 CET] <Lunchbox> any other option looks wrong [18:42:08 CET] <ritsuka> if the file doesn't have any color info, you can only guess& [18:42:16 CET] <kepstin> assuming that sd sources are bt.601 and using bt.601 for output will generally be correct [18:42:22 CET] <ritsuka> if you want convert colorspace you can use the colorspace filter [18:42:27 CET] <kepstin> but if it's a downscale from HD content, then who knows. [18:43:17 CET] <Lunchbox> i'm just trying to resize 360p in 601 to 720p without the colors changing [18:44:12 CET] <durandal_1707> and what you use for playback? [18:44:37 CET] <Lunchbox> final video will mostly be viewed in web browsers [18:45:30 CET] <durandal_1707> just dont use ffplay [18:46:42 CET] <kepstin> mpv is known to have good colorspace handling, so use that as a reference player to test stuff, but you'll have to also check the browsers :/ [18:47:24 CET] <Lunchbox> looks like -vf colorspace=bt709 should do the trick? looks like colormatrix doesn't support some stuff like colorspace does according to the documentation [18:48:16 CET] <kepstin> colorspace has lots of options, but if it's guessing the input correctly, that should suffice to convert to bt709 [18:48:28 CET] <kepstin> if it's not guessing the input correctly, you'll need more options. [18:48:52 CET] <Lunchbox> what are the other params i can provide to make sure it's correct [18:49:13 CET] <Lunchbox> i guess i can just see what happens if i use only colorspace [18:49:27 CET] <kepstin> well, first you need to know what color primaries and transfer characteristics your input has :/ [18:49:37 CET] <kepstin> e.g. is it from an SD NTSC tv source, or what? [18:50:51 CET] <Lunchbox> it's just a recording of my computer screen [18:51:06 CET] <kepstin> made with what software? [18:51:23 CET] <Lunchbox> open broadcaster software [18:51:48 CET] <Lunchbox> obs studio specifically [18:51:50 CET] <kepstin> huh, I really have no idea what obs would be doing here [18:52:05 CET] <Lunchbox> well you can set whatever you want for it to record with [18:52:22 CET] <Lunchbox> right now the settings [18:52:24 CET] <kepstin> yeah, but the defaults are bt709, limited range [18:52:26 CET] <Lunchbox> for 360p [18:52:28 CET] <Lunchbox> are [18:52:29 CET] <kepstin> iirc [18:52:45 CET] <Lunchbox> yuv color space 601 yuv color range partial color format nv12 [18:52:48 CET] <kepstin> i guess they might do something different for 360p? [18:52:58 CET] <Lunchbox> you can set it to whatever you want [18:53:03 CET] <Lunchbox> those are the defaults [19:03:29 CET] <TAFB> can I tell ffmpeg to use all my 12 cores when encoding libx264? [19:03:43 CET] <BtbN> it will be default [19:03:47 CET] <BtbN> *by [19:04:08 CET] <kepstin> TAFB: but note that with smaller video sizes (sd) and faster presets, it might not actually scale to use all those cores. [19:04:26 CET] <JEEB> or what's more often happening, something else is limiting your speed [19:04:41 CET] <TAFB> hmmm, only appears to be using "core 19" at the moment, 82% loaded, the rest of the cores are at 0 to 3% :( [19:04:53 CET] <Fyr> sometimes all cores are not the fastest option. [19:05:03 CET] <JEEB> have you built x264 with threading? [19:05:10 CET] <JEEB> have you built FFmpeg with threading? [19:05:20 CET] <TAFB> just downloaded the pre-build Windows ffmpeg [19:05:20 CET] <JEEB> are you sure you are not being limited by something *before* libx264? [19:05:55 CET] <kepstin> if you're hitting single-core limits, it's probably an ffmpeg filter or something that's slowing you down rather than x264, yeah. [19:06:25 CET] <therage3> if you want to use pastebin.com, try to give us the raw link [19:06:51 CET] <Fyr> JEEB, how will the conversion will go if -threads is set to 4, but -x264-params is set to 8? [19:06:57 CET] <Fyr> or 2? [19:07:11 CET] <TAFB> https://pastebin.com/1UpT4EH3 [19:07:21 CET] <therage3> ... [19:07:22 CET] <JEEB> not sure in which order those work, but whichever gets applied later wins in init() [19:07:25 CET] <kepstin> Fyr: settings in -x264-params should override other options (they're applied to x264 after the other options) [19:07:45 CET] <JEEB> ^ ok, so that's the order then [19:08:07 CET] <Fyr> kepstin, ok, but -threads 4 will be used when converting the audio stream? [19:08:09 CET] <kepstin> TAFB: I suspect your bottleneck is the lagarith decoding. [19:08:21 CET] <TAFB> kepstin: figured as much :( [19:08:22 CET] <kepstin> Fyr: all the audio encoders are single-threaded [19:08:23 CET] <JEEB> Fyr: depends on the encoder anyways. most don't [19:08:32 CET] <JEEB> because audio encoding generally is "fast enough" [19:08:51 CET] <kepstin> TAFB: you can check this by running "ffmpeg -i "amarec(20171210-1216).avi" -f null -" and see what fps/core usage you get [19:09:23 CET] <TAFB> checking... [19:09:30 CET] <JEEB> I like how that one french dude has rencetly added nice optimizations to Ut Video [19:09:34 CET] <JEEB> <3 [19:11:39 CET] <TAFB> kepstin: that command loads all "real" cores, fps=255! [19:11:59 CET] <kepstin> alright, so decoding isn't the bottleneck then [19:12:27 CET] <JEEB> libx264 is properly setting threads to 12 [19:12:35 CET] <kepstin> try "ffmpeg -i "amarec(20171210-1216).avi" -pix_fmt yuv420p -f null -" [19:12:40 CET] <JEEB> so then it's either the pix_fmt conversion or libx264 [19:12:42 CET] <kepstin> might be the pixel format conversion is slow [19:12:57 CET] <JEEB> or just the preset veryslow might be heavy on a single thread at that point [19:13:02 CET] <JEEB> but you should be able to confirm [19:13:03 CET] <JEEB> with that [19:13:17 CET] <kepstin> i'd expect 720p with veryslow it should be able to load up the threads pretty good [19:13:32 CET] <kepstin> might not if e.g. the video is a still image or something tho. [19:13:52 CET] <JEEB> it's still definitely fast, (13fps) [19:14:13 CET] <TAFB> -pix_fmt yuv420p still uses all 12 cores, 300fps [19:16:05 CET] <kepstin> TAFB: right then, either you have a misbuilt libx264 with threading disabled somehow!? or the characteristics of your video just don't allow the threading to work well :/ [19:16:16 CET] <JEEB> well it's preset veryslow [19:16:31 CET] <JEEB> because I don't think libx264 would set the threads if threading is not enabled [19:16:33 CET] <JEEB> I think [19:17:10 CET] <TAFB> freaky. I'll try a slightly older pre-built ffmpeg and see if I see the same thing [19:17:11 CET] <TAFB> thanks guys [19:17:34 CET] <JEEB> also do note that sometimes -f null for benchmarking doesn't bring what you need onto the table [19:17:52 CET] <JEEB> -c:v rawvideo -c:a pcm_XXXX -f nut with output to NUL or something [19:18:01 CET] <JEEB> that generally tends to give a realistic picture [19:18:13 CET] <JEEB> (or /dev/null on *nix) [19:25:46 CET] <TAFB> can you use a cluster of computers to encode with ffmpeg? [19:26:30 CET] <JEEB> yes but it's not automated of course. it's the "magic sauce" that all of those video sites use [19:27:08 CET] <TAFB> ahhhh, nice. [19:27:48 CET] <Fyr> guys, is there a difference between -pix_fmt and -pixel_format? [19:28:03 CET] <BtbN> one is shorter [19:28:15 CET] <TAFB> wow, crf 18 sure is pretty [19:28:23 CET] <Fyr> if I set -pixel_format, FFMPEG responds: [19:28:23 CET] <Fyr> No pixel format specified, yuv444p for H.264 encoding chosen. [19:28:23 CET] <Fyr> Use -pix_fmt yuv420p for compatibility with outdated media players. [19:28:38 CET] <Fyr> if I set -pix_fmt, it's set normally. [19:28:43 CET] <BtbN> well, then the difference is that the long version doesn't exist [19:29:02 CET] <Fyr> but it doesn't say that it didn't recognized the option. [19:32:05 CET] <Fyr> Reading option '-pixel_format' ... matched as AVOption 'pixel_format' with argument 'yuv420p'. [19:36:21 CET] <durandal_1707> can be raw demuxer option [19:36:34 CET] <JEEB> yea I see it in avdevice.h [19:36:57 CET] <JEEB> rawvideo and img2dec have it too [19:37:31 CET] <JEEB> http://up-cat.net/p/9343135d [20:01:08 CET] <Fyr> is it worth bugreporting? [20:01:42 CET] <durandal_1707> Fyr: what is bugggy? [20:03:14 CET] <Fyr> -pixel_format [20:03:33 CET] <TAFB> is there something slower than veryslow? [20:03:52 CET] <Fyr> TAFB, placebo [20:04:00 CET] <durandal_1707> Fyr: i dont see how that can be bug [20:04:15 CET] <TAFB> Fyr: I need about 2% more compression, think it would do it? [20:04:34 CET] <Fyr> durandal_1707, unexpected behavior. a user sets an option, but it's ignored. [20:04:43 CET] <therage3> TAFB: see here https://trac.ffmpeg.org/wiki/Encode/H.264 [20:04:56 CET] <Fyr> TAFB, try both and compare. [20:05:01 CET] <TAFB> will do [20:05:03 CET] <durandal_1707> Fyr: read documentation wisely [20:05:05 CET] <therage3> TAFB: https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ [20:05:44 CET] <TAFB> ahh, about 1%. I'ma give it a try and see if it does what I need :) [20:05:50 CET] Action: therage3 nods [20:44:03 CET] <TAFB> "-c:a aac -b:a 320k" gets me "Audio: AAC 48000Hz stereo 321kbps [SoundHandler - MPEG-4 Audio (AAC, 48.0 kHz, 2 chn, 16 bit, 321.5 kbit/s)]" is it possible to get it exactly 320.0kbit/s? [20:46:59 CET] <kepstin> what program is displaying that? it might be including the container overhead [20:47:14 CET] <TAFB> MPC-BE [20:49:38 CET] <TAFB> and do you know a program that can tell me how many "real" fps/sec my video is? My capture card does it at 60fps but lots of frames are doubled and tripled. [20:50:05 CET] <TAFB> sorry, ALL frames are doubled or tripled. [20:50:54 CET] <TAFB> looks like one frame is doubled, next one tripled, next one doubled, next one tripled [20:55:15 CET] <Johnjay> I can't get ffmpeg to download a mp2t stream like in this SO thread. suggestions? [20:55:25 CET] <Johnjay> https://stackoverflow.com/questions/32528595/ffmpeg-mp4-from-http-live-stre… [20:55:48 CET] <Johnjay> the command I tried is near the bottom [20:58:23 CET] <Johnjay> Well there's not really any output [20:58:27 CET] <Johnjay> it just says unknown error [20:58:47 CET] <Johnjay> youtube-dl seems to know what to do though. it's involking ffmpeg on the same m3u8 URL [21:26:56 CET] <TAFB> placebo is MUCH slower than veryslow, lol. 3x slower or so. [21:27:07 CET] <JEEB> yes [21:27:16 CET] <JEEB> it's called like that for a reason, more or less [21:27:17 CET] <furq> the clue's in the name [21:27:42 CET] <TAFB> looks like my source is 24fps or 25fps, not sure how to tell exactly which [21:28:32 CET] <TAFB> I guess I could run an encode at 25fps and look for duplicate frames [21:29:36 CET] <JEEB> if you need to check actual content rate, just use a player to go frame forwards/backwards [21:29:44 CET] <JEEB> like with ,. in mpv :P [21:30:17 CET] <TAFB> I use avidemux to check for duplicate frames :) [21:30:30 CET] <JEEB> well whatever works for you [21:30:52 CET] <TAFB> "ffmpeg -i input.mp4 -vf mpdecimate -loglevel debug -f null -" seems to mistake some similar frames for duplicate frames :( [21:34:23 CET] <TAFB> looks like 24fps it is! [21:55:19 CET] <furq> TAFB: you can adjust the params to mpdecimate if it's being overzealous [21:55:22 CET] <furq> !filter mpdecimate [21:55:22 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate [22:06:43 CET] <TAFB> sweet! thanks! [22:10:21 CET] <Lunchbox> i'm getting "no such filter 'colorspace'" when trying to use -vf colorspace=bt709 [22:11:24 CET] <JEEB> too old FFmpeg? [22:14:33 CET] <Lunchbox> version is N-75137-g2c1ec57 [22:14:34 CET] <Lunchbox> lol [22:15:22 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=2c1ec57 [22:15:39 CET] <JEEB> now you know that you can throw that identifier without the g in front there to see how old it is :P [22:17:39 CET] <Lunchbox> how can i tell if my version is too old [22:17:46 CET] <Lunchbox> or should i just update anyways [22:17:53 CET] <JEEB> well, you just found your own version [22:18:03 CET] <JEEB> and then you can search the history for the colorspace filter :P [22:18:35 CET] <JEEB> like this http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=colorspace [22:19:05 CET] <JEEB> and you can find that the colorspace filter was added in April, 2016 [22:19:11 CET] <Lunchbox> oh dang [22:19:14 CET] <Lunchbox> yep haha [22:19:14 CET] <JEEB> while as I linked your version is from somewhere in 2015 [22:19:16 CET] <Lunchbox> thank u [22:20:11 CET] <Lunchbox> can't believe mine was that old [22:20:21 CET] <Lunchbox> pretty sure it was the latest when i downloaded it at the time [22:20:25 CET] <Lunchbox> has it really been that long [22:20:27 CET] <Lunchbox> sheesh [22:20:47 CET] <therage3> what OS are you on? [22:20:57 CET] <therage3> some distros have really old versions of some stuff, Debian in particular [22:20:57 CET] <Lunchbox> windows 7 [22:21:02 CET] <therage3> o.o [22:21:10 CET] <Lunchbox> lol [22:21:11 CET] <therage3> you sure downloaded it a long time ago then :) [22:22:30 CET] <Johnjay> You mean 2016-04-12 Ronald S. Bultje lavfi: new colorspace conversion filter. ? [22:22:49 CET] <JEEB> yes [22:23:04 CET] <JEEB> but if you are on such an old thing you just want the latest and go from there [22:23:27 CET] <Lunchbox> where is the bin folder in the latest release haha [22:23:33 CET] <Johnjay> my windows 7 box has ffmpeg version N-87353-g183fd30 [22:23:48 CET] <Lunchbox> oh nvm [22:23:52 CET] <Lunchbox> downloaded the wrong one [22:26:27 CET] <Lunchbox> what does unsupported input primaries mean? [22:26:35 CET] <Lunchbox> sorry for the billion questions [22:31:28 CET] <JEEB> if that comes from the filter (inside the [] in the log) then whatever your input is is not supported by it [22:33:20 CET] <Johnjay> Lunchbox: don't worry asking annoying questions is pretty much all I do on here [22:33:57 CET] <Lunchbox> https://paste.ofcode.org/8UxCqqmhFJ8wAwqa7XDSyu [22:34:22 CET] <JEEB> yea [22:34:28 CET] <JEEB> your input parameters are unknown [22:34:47 CET] <JEEB> and new filters that don't want to be guessing (zscale, colorspace) specifically want you be explicit [22:34:47 CET] <Lunchbox> how can i find them out? [22:34:52 CET] <durandal_1707> need to specify/set them [22:35:00 CET] <JEEB> Lunchbox: you know the source, right? [22:35:01 CET] <Lunchbox> in the command? [22:35:05 CET] <Lunchbox> yes i do [22:35:29 CET] <JEEB> ok, so what's the source and how did it end up not being tagged? :) [22:36:02 CET] <JEEB> so that you can then tag it accordingly so that the filter would be usable [22:36:08 CET] <Lunchbox> not sure [22:36:16 CET] <Lunchbox> i mentioned i was using obs earlier for recording the videos [22:36:22 CET] <JEEB> ok [22:36:26 CET] <Lunchbox> but idk if it actually tags the video like you're saying [22:36:31 CET] <Lunchbox> which is something new to me [22:36:38 CET] <JEEB> it's not tagging, otherwise it'd not say unknown [22:36:51 CET] <JEEB> I think the simplest is to check with mpv or something [22:36:56 CET] <Lunchbox> does this mean i'm screwed haha [22:37:02 CET] <JEEB> ask on #mpv how to switch between BT.709 and BT.601 [22:37:09 CET] <Lunchbox> i dropped it in mediainfo but doesn't really tell me anything i think is useful' [22:37:15 CET] <JEEB> you can find mpv binaries for windows @ https://mpv.srsfckn.biz/ [22:37:24 CET] <JEEB> well mediainfo can only find out what's tagged in the file [22:37:30 CET] <JEEB> in this case OBS did not write any metadata [22:37:31 CET] <JEEB> :P [22:37:50 CET] <Lunchbox> https://paste.ofcode.org/HD3UHJiZk9vxhxyZm96WQH [22:38:18 CET] <Lunchbox> didn't look like any of that was what i needed to know [22:38:29 CET] <JEEB> yup, so unfortunately OBS doesn't tag even though it's doing the colorspace conversion most likely :/ [22:38:36 CET] <Lunchbox> shoot [22:38:36 CET] <JEEB> it's either BT.709 or BT.601 [22:38:52 CET] <Lunchbox> it's supposed to currently be 601 according to the obs settings [22:38:55 CET] <JEEB> that's why I said grab an mpv binary and ask #mpv how to set one or the other [22:38:57 CET] <JEEB> ok [22:39:09 CET] <JEEB> because the best way to check is to verify which looks correct [22:39:15 CET] <JEEB> and since you knwo the source you should know the difference [22:39:27 CET] <Lunchbox> yea it's definitely 601 for sure [22:39:36 CET] <JEEB> ok [22:39:39 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#colorspace [22:39:42 CET] <Lunchbox> i've recorded with both and it's obviously different [22:39:49 CET] <JEEB> uhh [22:39:56 CET] Action: JEEB sighs [22:40:01 CET] <JEEB> it's different because players don't know you switched [22:40:02 CET] <Lunchbox> i had that page open [22:40:07 CET] <TAFB> recording to my 64gb ramdrive, see if that gets rid of some dropped frames :( [22:40:10 CET] <JEEB> that's why I noted mpv [22:40:15 CET] <JEEB> you could SWITCH which it used [22:40:27 CET] <JEEB> because when not tagged the players have to guess [22:40:31 CET] <Lunchbox> ohhh [22:40:32 CET] <JEEB> which is usually done by resolution or something [22:40:37 CET] <Lunchbox> that's realyl dumb actually lol [22:40:39 CET] <JEEB> so to see which it is [22:40:44 CET] <c3r1c3-Win> The OBs color space settings are in settings->Advanced->Color space [22:40:45 CET] <JEEB> you switch between them [22:40:49 CET] <JEEB> and look which is correct [22:40:49 CET] <Lunchbox> i gtg picking up christmas tree [22:40:56 CET] <Lunchbox> be back in a little bit [22:41:16 CET] <Lunchbox> yea that's were i double checked the settings c3r1c3 [22:41:21 CET] <durandal_1707> thats little early for tree? [22:41:34 CET] <Lunchbox> it's december!! [22:41:39 CET] <JEEB> c3r1c3-Win: nothing wins learning to check which it is (when you know your source colors) [22:41:49 CET] <JEEB> but yes, OBS should just darn flag the files [22:41:52 CET] <Lunchbox> okok brb [22:41:53 CET] <JEEB> so we wouldn't have this crap :P [22:42:04 CET] <Lunchbox> ill yell at them later in #obsproject [22:42:39 CET] <JEEB> funny enough when you use the nvidia encoder from OBS it actually (probably properly) tags the video as BT.601 [22:42:48 CET] <JEEB> but not when it uses libx264? [22:42:49 CET] <JEEB> lol [22:44:25 CET] <c3r1c3-Win> You can also yell at them in #obsdev. ;-) [22:44:44 CET] <JEEB> I have my own set of projects I poke [22:45:01 CET] <c3r1c3-Win> (on Quakenet, almost no one every visits the freenode one) [23:32:06 CET] <SolarAquarion> i'm getting a ffmpeg launch failure [23:32:32 CET] <SolarAquarion> https://paste.debian.net/1000116/ [23:34:02 CET] <TheRock2> Have you double clicked the player ? [23:34:18 CET] <SolarAquarion> it could be a mpv issue [23:34:55 CET] <sfan5> something is broken with your cuda [23:35:49 CET] <SolarAquarion> sfan5: tell me about it [23:36:04 CET] <sfan5> recently upgraded drivers or something similar? [23:37:57 CET] <SolarAquarion> sfan5: i use nouveau really, but i only was having the cuda problems recently like in the last few days [23:38:10 CET] <SolarAquarion> when i upgraded ffmpeg or maybe cuda upgraded [23:38:40 CET] <SolarAquarion> not cuda [23:46:34 CET] <sfan5> nouveau supports cuda? [23:47:27 CET] <SolarAquarion> it did, but i guess i should disable it [23:47:34 CET] <SolarAquarion> or disable cuda [00:00:00 CET] --- Mon Dec 11 2017

1 0

ffmpeg-devel.log.20171209
by burek 10 Dec '17

10 Dec '17

[01:24:00 CET] <sfan5> michaelni: was it an oversight that you didn't apply the actual skip_frame implemention (patch 2/2)? [01:32:35 CET] <jamrial> sfan5: if he didn't reply to it then he didn't yet look at it [01:35:04 CET] <sfan5> alright [05:55:08 CET] <Compn> ugh [05:55:23 CET] <Compn> the comments on hacker news are not fun to read [05:55:44 CET] <Compn> i need a site where its mandatory people read the article before posting :D [05:57:44 CET] <wm4> is it about ffmpeg [07:26:30 CET] <Dis> Hi, I am trying to encrypt the dash segments hence passing encryption key and kid to mp4 muxer. With ffmpeg command generating dash single file for playback. But when I play using ffplay I see failed to read the IV from auxiliary info. [07:27:50 CET] <Dis> ffmpeg -y -f mp4 -i SampleVideo_1280x720_20mb.mp4 -map 0:v:0 -c copy -f dash -encryption_scheme cenc-aes-ctr -encryption_key <key> -encryption_kid <kid> -min_seg_duration 4000000 -use_timeline 1 -use_template 1 -single_file 1 ./ffenc_new1.mpd [07:28:19 CET] <Dis> ffplay ffenc_new1-stream0.m4s -decryption_key <key> [07:28:56 CET] <Dis> I get the error "[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fa3040008c0] failed to read iv from the auxiliary info" [07:30:05 CET] <Dis> I am unable to locate the issue. Please provide inputs. On side note: with mp4 muxer alone... I do not see any error while playback. [14:48:53 CET] <cone-893> ffmpeg 03Martin Vignali 07master:869efbf97120: avfilter/x86/vf_threshold : add threshold16 SIMD (SSE4 and AVX2) [14:48:54 CET] <cone-893> ffmpeg 03Martin Vignali 07master:179a2f04eb2b: checkasm/vf_threshold : add test for threshold16 [15:12:03 CET] <cone-893> ffmpeg 03Martin Vignali 07master:9e1c9633cc7b: avcodec/utvideodec : use dsp add_median_pred for second line [15:13:38 CET] <JEEB> :) [15:14:32 CET] <cone-893> ffmpeg 03Martin Vignali 07master:57877f2b449f: avcodec/huffyuvenc : increase scalar loop count [15:14:33 CET] <cone-893> ffmpeg 03Martin Vignali 07master:001173b8ff8e: avcodec/huffyuvenc : remove code duplication in sub_left_prediction [15:14:34 CET] <cone-893> ffmpeg 03Martin Vignali 07master:dc9a187c3d1b: avcodec/huffyuvenc : sub_left_prediction_bgr32, call dsp after 32 first byte of the line in order to try to call the align version (diff bytes have avx2 version) [15:17:50 CET] <cone-893> ffmpeg 03Martin Vignali 07master:5bda11e70ef1: checkasm/llviddsp : test return of add_left_pred(16) [15:17:51 CET] <cone-893> ffmpeg 03Martin Vignali 07master:cfbcea1cca7f: avcodec/x86/lossless_videodsp.asm : make macro for add_left_pred_unaligned in order to add avx2 version [15:17:52 CET] <cone-893> ffmpeg 03Martin Vignali 07master:4353c3506742: avcodec/x86/lossless_videodsp : add avx2 version for add_left_pred [15:20:22 CET] <cone-893> ffmpeg 03Martin Vignali 07master:630967ef63d0: avcodec/utvideodec : add SIMD (SSSE3 and AVX2) for gradient_pred [15:20:23 CET] <cone-893> ffmpeg 03Martin Vignali 07master:e1121f9723b1: checkasm/llviddsp : add test for add_gradient_pred [16:38:41 CET] <durandal_1707> spam incoming [16:47:55 CET] <durandal_1707> it appears some messages didnt make in? [16:52:59 CET] <jamrial> i got all 27 [20:39:28 CET] <JEEB> last call if anyone has any issues with https://patchwork.ffmpeg.org/patch/6618/ ? [20:39:39 CET] <JEEB> it fixes compilation and the change itself seems OK [20:39:54 CET] <JEEB> (just resets the literal pool before that function) [20:49:56 CET] <cone-765> ffmpeg 03James Almer 07master:36de24d5b7d6: arm/hevc_idct: fix compilation on Android [20:50:08 CET] <JEEB> jamrial: thanks for posting it :) [20:50:31 CET] <sfan5> nitpick: it worked on Android+gcc, just not on Android+clang [20:50:59 CET] <ubitux> they're pretty much killing gcc lately [20:51:17 CET] <ubitux> not sure it will last long; is it even part of the toolchain in recent ndk? [20:51:30 CET] <wbs> it is still present in the latest vrsions, but very deprecated [20:51:33 CET] <wbs> and not updated since 4.9 [20:51:46 CET] <wbs> and all the release notes are saying that it will be removed soon [20:51:53 CET] <JEEB> yea [20:52:08 CET] <sfan5> pretty sure it has been saying "soon" since the last 6 months [20:52:24 CET] <JEEB> yea they had some issues with c++ until now [20:52:31 CET] <JEEB> but I think the C++ stdlib issues they had are fixed now [21:23:54 CET] <jamrial> JEEB: no prob [21:34:51 CET] <cone-765> ffmpeg 03James Cowgill 07master:02ba4b91b561: avcodec/decode: reset codec on receiving packet after EOF in compat_decode [21:35:25 CET] <durandal_1707> why is this crap in master? [21:44:16 CET] <cone-765> ffmpeg 03James Cowgill 07release/3.4:d8d1689f929c: avcodec/decode: reset codec on receiving packet after EOF in compat_decode [22:02:25 CET] <jamrial> because nobody vetoed it or stated it wasn't acceptable, whereas at least two people said it was good and approved it [22:05:23 CET] <BtbN> From how I understand it, it turns an error code being returned in an coded implementation defined "either it works or crashes"? [22:05:30 CET] <BtbN> *codec [22:06:19 CET] <Chloe> turing codec still only supports a very specific target [22:08:45 CET] <Chloe> its API (and actually the whole codec) is also of very questionable design [23:16:15 CET] <cone-765> ffmpeg 03Jacob Trimble 07master:b38f222165f9: avcodec/Makefile: Fix opus parser dependency. [23:16:16 CET] <cone-765> ffmpeg 03tiejun.peng 07master:ab651587a715: lavf/mov: add some useful warning log of eof [23:16:17 CET] <cone-765> ffmpeg 03tiejun.peng 07master:6bf5d69b2ffa: lavf/mov: modify code indentation [23:16:18 CET] <cone-765> ffmpeg 03Mironov, Mikhail 07master:f20c8f6ec9ec: amf: fix wrong profile level after auto-correction in H264 and HEVC [00:00:00 CET] --- Sun Dec 10 2017

1 0

ffmpeg.log.20171209
by burek 10 Dec '17

10 Dec '17

[00:13:56 CET] <orbisvicis> I'm trying to remove a xing header from a cbr mp3 with reencoding, can ffmpeg help with this? [00:15:04 CET] <orbisvicis> the obvious doesn't work: ffmpeg -i IN.mp3 -c copy OUT-unxing.mp3 [00:16:51 CET] <BtbN> why do you want to remove it? It serves a somewhat vital purpose. [00:17:23 CET] <orbisvicis> well, it prevents mp3splt from working in bit reservoir mode. But what purpose does it serve on cbr files ? [00:17:42 CET] <BtbN> pure information [00:18:30 CET] <orbisvicis> i think mp3splt assumes it is a vbr file and bails [00:19:48 CET] <orbisvicis> BtbN: xing provides frame/bytes/toc/quality. None of that is necessary for a cbr file [00:22:48 CET] <orbisvicis> anyway, I would like to remove it [00:30:01 CET] <BtbN> so turn it off if you really want to [00:32:00 CET] <BtbN> According to the option, it contains the duration. [00:37:55 CET] <orbisvicis> what option ? [00:38:07 CET] <orbisvicis> (turn it off how) [00:39:38 CET] <orbisvicis> anyway duration in cbr depends only on file size [00:53:47 CET] <orbisvicis> fwitw, this file was created by lavc56.60 [01:00:29 CET] <orbisvicis> well, problem solved with tail -c +... [03:03:31 CET] <Rajko> hello i need to get the picture num of a h264 frame output in an AVFrame, the respective fields are always 0 [03:04:07 CET] <Rajko> int coded_picture_number and int display_picture_number [03:20:53 CET] <RoyK> hi all. I want to setup a few machines for streaming video to central storage, think of it as cctv storage, somehow. It's a private experiment, filming birds. I'm using some orange pi zero things, which have pretty good performance cpu-wise, but I'm lost to how I can configure the streaming. The howtos on the net are a mix of a brazillion of ffmpeg versions, pretty incompatible. I'm on ffmpeg 3.2.5 now, so [03:20:59 CET] <RoyK> if someone has something that works with that version, it'd be nice [03:26:39 CET] <DHE> for continuous recording? a few options. an output format that splits into multiple chunks like segment or hls helps make things manageable... or stream over the network and have some app on the storage machine collect them? [03:34:53 CET] <RoyK> DHE: not sure yet, but I was wondering about the syntax first. Haven't used ffmpeg for this in quite a few years. The cameras do 720p, so I guess it should do with a few terabytes of storage [03:36:07 CET] <RoyK> DHE: btw, looking at things like motion or zoneminder, those look good, and I use motion today, but there's no audio option with that. Any idea how to solve that easily? [03:37:38 CET] <DHE> that's not my area of expertise unfortunately. I deal with non-stop recording... [03:38:15 CET] <RoyK> ok - no problem [03:39:02 CET] <RoyK> but would you suggest a simple "just grab the shit and dump it somewhere" for a simple 720p camera? Or something for streaming it further to a central server? [03:40:08 CET] <DHE> depends on the camera. is it something that integrates directly into the Pis? [03:40:27 CET] <DHE> I mostly use webcams so I can just have one machine pull from them and store locally [03:40:53 CET] <RoyK> just a cheap USB camera [03:41:13 CET] <RoyK> storing it locally should work [03:41:27 CET] <RoyK> over nfs or something [03:46:20 CET] <Rajko> actually coded_picture_number is A-OK ! but display_picture_number is always 0 [03:49:47 CET] <RoyK> DHE: IIRC you were hanging in here 15 years ago ;) [03:51:30 CET] <DHE> here? ffmpeg, no [03:51:42 CET] <RoyK> ok [03:52:38 CET] <RoyK> anyway - is there a quick way without a ton of magick options to just rip off things off a webcam and either dump it as it is or transcode it to h.264? [03:53:44 CET] <DHE> RoyK: ffmpeg [input-options] -i inputdev -c copy -f segment -segment_time 60 -segment_list_type flat -segment_list /nfsshare/camera1.txt /nfsshare/camera1-%04d.mp4 [03:54:14 CET] <DHE> this is a very rough starting point. splits files into 60 second increments. try it, see how it works for you, and tweak [03:57:54 CET] <RoyK> DHE: hm - http://paste.debian.net/999909/ [03:59:21 CET] <DHE> aww... camera doesn't output encoded data. you'll have to use "-c libx264 -crf 20" or such. or something better that the pi supports [03:59:45 CET] <RoyK> for input? [04:01:13 CET] <DHE> some hardware outputs h264 directly or such. was hoping so. means less work for you. [04:01:49 CET] <RoyK> yeah, can see that [04:02:24 CET] <RoyK> perhaps time to get a better cam :þ [04:03:38 CET] <furq> RoyK: what does v4l2-ctl --listofmrats say [04:03:41 CET] <RoyK> it's just an experiment - I love corvidae, and I want to just film them doing experiments, trying to solve things to find their food [04:03:42 CET] <furq> er [04:03:44 CET] <furq> --list-formats [04:04:40 CET] <DHE> also note that your camera isn't producing audio... [04:05:26 CET] <furq> doh [04:05:28 CET] <furq> --list-formats-ext [04:05:37 CET] <RoyK> DHE: pretty sure why this thing was cheap http://paste.debian.net/999910/ [04:05:51 CET] <furq> yeah sorry it's --list-formats-ext to list them all [04:06:10 CET] <RoyK> http://paste.debian.net/999911/ [04:06:12 CET] <furq> with that said if the camera only does 480p then raw yuv is fine [04:06:21 CET] <DHE> so that's a no then. transcode required... unless you want to dump some crazy high bitrate [04:06:26 CET] <furq> it looks like that ffmpeg build has omx [04:06:32 CET] <furq> so you can use the pi's builtin encoder [04:06:45 CET] <furq> use -c:v h264_omx and be prepared to throw a ton of bitrate at it because omx isn't very good [04:07:28 CET] <furq> oh [04:07:29 CET] <furq> orange pi? [04:07:51 CET] <furq> i guess you're stuck with x264 then [04:08:11 CET] <RoyK> ffmpeg -i /dev/video0 -c:v h264_omx -crf 20 -f segment -segment_time 60 -segment_list_type flat -segment_list camera1.txt camera1-%04d.mp4 # ? [04:08:32 CET] <furq> no omx is a raspberry pi thing [04:08:38 CET] <furq> the orange pi has a hardware encoder but it's not in ffmpeg yet [04:08:44 CET] <RoyK> ah [04:08:46 CET] <furq> there's some fork that has it but that's probably more trouble than it's worth [04:08:49 CET] <RoyK> no, it doesn't [04:09:00 CET] <RoyK> guess I'll just find another cam [04:09:13 CET] <furq> does x264 ultrafast run in realtime for 480p [04:09:15 CET] <RoyK> or perhaps use a raspberry pi zero [04:09:30 CET] <RoyK> I tried hw encoding with raspberry pi - worked well [04:09:47 CET] <furq> it's worth trying x264 [04:09:54 CET] <furq> i wouldn't be surprised if it runs ok at 480p [04:10:15 CET] <RoyK> at 720p the cpu load was at 90% or so [04:10:29 CET] <furq> that should probably work ok then [04:11:25 CET] <RoyK> seemed to spread out well over the cores [04:11:48 CET] <RoyK> I remember Måns Rullgård started working with that parallallism& [04:12:39 CET] <furq> you might even be able to use superfast [04:12:44 CET] <furq> superfast is a huge step up from ultrafast [04:13:07 CET] <RoyK> higher compression? [04:13:32 CET] Action: RoyK worked with Måns around 2001 when he started working on that [04:13:47 CET] <DHE> more CPU usage, but better quality/ratio [04:14:14 CET] <RoyK> can't afford more cpu here [04:16:48 CET] <RoyK> A small investment in new cameras can be a good idea, perhaps& [04:37:35 CET] <Rajko> PLEAS how do i get picture_number of the ffmpeg h264 decoder ? [04:37:50 CET] <Rajko> technically its in the parser [04:42:18 CET] <DHE> if it has no b-frames or you're looking at an i-frame, then coded picture equal display picture. otherwise you'll have to do some pts tracking and looking ahead [04:42:31 CET] <Rajko> it has b-frames [04:42:34 CET] <Rajko> 2 [04:42:54 CET] <Rajko> why doesnt the h264 decoder fill in display_picture_number, its always 0 [04:43:19 CET] <Rajko> it KNOWS what it is, since it can delay the frame output until it reaches the correct one (reordering) [04:43:29 CET] <Rajko> even with no PTS supplied (annex-B stream only) [04:44:27 CET] <DHE> really? because I thought with b-pyramid it would need to do some level of decoding [04:44:37 CET] <DHE> if pts values were unavailable [04:44:50 CET] <Rajko> well the decoder is giving me AVFrames [04:44:55 CET] <Rajko> it should fill in display_picture_number [04:46:17 CET] <Rajko> but the h264 one never writes to it [04:55:32 CET] <Rajko> how do i get a ptr to the current h264 parser from the decoder context ? [06:23:41 CET] <Cracki__> I notice chanserv gives a notice to joining people ("When asking a question be precise..."). how is that done? [06:24:06 CET] <Cracki__> nvm, entrymsg [08:03:46 CET] <illegal> Would there be a reason as to why trimming/cutting a part of a video with ffmpeg might yield 1. incorrect starting position and 2. incorrect timing numbers? [08:04:30 CET] <illegal> Example; starting at 6 seconds instead of 00 [08:04:35 CET] <illegal> 0* [12:02:03 CET] <Fyr> guys, is development of x265 stalled? [12:02:40 CET] <Fyr> I saw their bitbucket commits, nothing was worth looking at. [12:11:50 CET] <adimit> Hi, I have an MKV with text-based subtiles, and I want to create an MPG that I can burn to a DVD, if possible, with the subtitles as a separate track (dvdsub instead of burning them straight onto the movie.) Is there a way to this with FFMPEG? I know how to burn them into the image, but I'd like them to be selectable. [12:12:18 CET] <adimit> If I use -c:s dvdsub it complains that the source subs aren't in bitmap format, which they're not, but I don't know how to convert them first. [12:16:55 CET] <dystopia_> in my experience adimit ffmpeg is of at extracting subs [12:17:00 CET] <dystopia_> when built with libzvbi [12:17:07 CET] <dystopia_> but not converting to another type [12:17:12 CET] <dystopia_> i use external programs [12:17:58 CET] <JEEB> there is no external file format for teletext [12:18:24 CET] <JEEB> as in, there is no official format that's ~one-to-one to teletext [12:18:28 CET] <BtbN> ffmpeg should be perfectly able to convert text-based subtitles to dvdsubs [12:18:28 CET] <adimit> dystopia_: cool, I'm fine with extracting the SRT, then creating bitmap overlays and putting them back into the video, I just don't know how to do it :-( [12:18:46 CET] <JEEB> but if you were using the API you could get the timing data and text [12:19:01 CET] <JEEB> oh, wait. you meant something else. sorry [12:19:04 CET] <JEEB> still waking up [12:19:05 CET] <adimit> BtbN: do you know how? I've been trying to, but the only thing I can do is burn them into the image. [12:19:18 CET] <BtbN> The plain stupid way should just work [12:19:41 CET] <BtbN> -target pal-dvd -c:s dvdsub ... [12:19:52 CET] <JEEB> I think there might have been some issues with palettes, but not sure. I think Chloe was poking that at some point. [12:20:34 CET] <adimit> BtbN: if this is the plain stupid way, I haven't been smart enough: ffmpeg -i cut.mkv -c:s dvdsub -f dvd -target pal-dvd output.mpg It complains that the input doesn't have bitmap subtitles. [12:22:09 CET] <JEEB> uhh [12:22:19 CET] <JEEB> oh, two discussions even [12:22:33 CET] <JEEB> yea, text-based to image based requires some effort [12:22:44 CET] <JEEB> not sure if filter_complex works out of the box [12:22:56 CET] <JEEB> if you try to overlay the subtitles you get on top of a correctly sized overlay [12:23:14 CET] <JEEB> for DVD/DVB/PGS subtitles [12:23:23 CET] <JEEB> and then -map the output of that [12:25:08 CET] <adimit> JEEB: -filter_complex "[0:v][0:s]overlay[v]" -map "[v]" didn't work for me, as it, too, complains about non-text based subs. But -vf subtitles=input.mkv did work, albeit with some timing issues, that I'd have to resolve. And, of course, it permanently burns the subs into the image. [12:25:27 CET] <JEEB> yea, that's not what I meant [12:25:46 CET] <JEEB> like, both of those are just overlaying subtitles on top of the video [12:27:27 CET] <adimit> oh. Ok. I don't know how to use filter_complex to create a separate stream. I would probably need to create it with -map, no? [12:28:35 CET] <JEEB> the basics would be to have a see-through generated frame instead of 0:v, and then you'd use the subtitle filter to overlay on top of it (I think overlay only works with image based subtitles) [12:29:02 CET] <JEEB> and then you -map the output of that (in the thing you pasted it's called "v" but you can call it however you want [12:29:40 CET] <JEEB> if you set the size of the generated frame right it might go through to the subtitle encoder, although how those work with AVFrames (I don't think they do?) is still up to grabs [12:29:53 CET] <adimit> JEEB: do you think I can use the text2movsub -bsf instead? [12:29:56 CET] <JEEB> the API would work with this, but we're currently talking about ffmpeg.c I bet :P [12:30:02 CET] <JEEB> adimit: no [12:30:10 CET] <JEEB> that's completely different [12:30:28 CET] <JEEB> the mere fact it mentions "movsub" already is a red flag that it has nothing to do with your case [12:30:39 CET] <adimit> JEEB: Ok, thanks, I was confused, then. [12:34:55 CET] <adimit> I think I might end up not using ffmpeg for this, then. What you're saying sounds a bit complicated for me :-( [12:35:53 CET] <adimit> Thank you anyway for the help! [12:36:16 CET] <JEEB> if it works with filter_complex, it's not really complicated [12:36:32 CET] <JEEB> there's a filter that gives you base images that you can tell it you want transparent [12:36:48 CET] <JEEB> the size should be whatever are your needs for DVB subtitles (720x576?) [12:37:09 CET] <Fyr> guys, what does it mean: "Thread message queue blocking; consider raising the thread_queue_size option"? [12:37:12 CET] <JEEB> then you use the subtitle filter or so to overlay the image [12:37:32 CET] <Fyr> I set -threads 8 [12:38:08 CET] <adimit> OK, I'll see what I can do, thanks. [12:38:50 CET] <JEEB> of course it is possible that ffmpeg.c just can't handle that, but in that case you can make a ticket for that use case so people know it :P it, after all, is possible with the API [15:10:36 CET] <matt3o12> Hey, I have two videos of variable sizes which I want to overlay. The second video should use 25% of the size of the first video and the second video should be placed on the right bottom corner. How can I do that? [15:12:00 CET] <JEEB> the overlay part takes parameters regarding its position and you can scale the thing to be overlayed to be smaller or exactly the same size as the viewport [15:12:05 CET] <JEEB> as in, the canvas [15:12:11 CET] <JEEB> so I don't see anything special in that? [15:12:19 CET] <JEEB> scale the thing you want to overlay to your preferred size [15:12:24 CET] <JEEB> set the position params [15:14:03 CET] <matt3o12> I have troubles understand the ffmpeg command line syntax and I have no expierence working with ffmpeg in general. [15:14:29 CET] <matt3o12> Can you point me to any links where to get started? `man ffmpeg` is rather difficult to understand. [15:14:37 CET] <JEEB> yes, that's not the best part to start with [15:14:43 CET] <JEEB> as it just gives you a lot of stuff [15:16:59 CET] <JEEB> but basically -filter_complex '[1:v:0]scale=w=300:h=200[scaled_overlay];[0:v:0][scaled_overlay]overlay[overlay_out]' -map '[overlay_out]' [15:17:02 CET] <JEEB> is an example [15:17:13 CET] <JEEB> this is with two input files which both have video tracks [15:17:33 CET] <JEEB> the first part takes the second video file (nr 1 when starting from zero) [15:17:45 CET] <JEEB> scales it to w=300:h=200 [15:17:52 CET] <JEEB> and outputs its as 'scaled_overlay' [15:18:08 CET] <JEEB> then we take the video from the first input, and the 'scaled_overlay' [15:18:19 CET] <JEEB> and tell libavfilter to use those two for overlaying purposes [15:18:26 CET] <JEEB> and output those as 'overlay_out' [15:18:51 CET] <JEEB> I recommend searching through ffmpeg-all.html for these filters [15:18:56 CET] <JEEB> a la https://www.ffmpeg.org/ffmpeg-all.html#overlay-1 [15:19:17 CET] <JEEB> also this can be maybe useful with various more or less non-simple examples [15:19:18 CET] <JEEB> https://trac.ffmpeg.org/wiki/FilteringGuide [15:19:31 CET] <Fyr> guys, do 16-bit, 24-bit and 32-bit audio have difference to a human ear? [15:20:07 CET] <neverminder> Hi JEEB, gotta minute to take a quick peak at my log? I'm trying to record video/audio and it hangs. Video alone or audio alone records just fine. [15:20:16 CET] <redrabbit> Fyr: its going to be hard to notice [15:20:19 CET] <sfan5> Fyr: no https://people.xiph.org/~xiphmont/demo/neil-young.html [15:20:29 CET] <redrabbit> but you can between 16-bit 24-bit [15:20:38 CET] <redrabbit> 24-bit vs 32 however [15:20:38 CET] <JEEB> ahahaha [15:21:04 CET] <JEEB> 16bit already provides quite a bit of headroom and range of values as sfan5's linked article notes [15:21:20 CET] <JEEB> additional precision is good for filtering, which is when filtering you should be using something like float or double :P [15:21:24 CET] <redrabbit> imho 96khz 24bit is a tiny bit better than 44.1k 16b [15:21:26 CET] <kerio> you can take my 24bit radiohead out of my cold dead hands [15:21:35 CET] <Fyr> redrabbit, but it's possible to discern if one has a good earphones? [15:21:40 CET] <kerio> Fyr: no [15:22:01 CET] <redrabbit> with very good gear you can "feel" something [15:22:15 CET] <redrabbit> idk if you can blind determine between [15:22:22 CET] <sfan5> lmao [15:22:25 CET] <redrabbit> maybe you can with super high end gear and good ears. [15:22:29 CET] <kerio> redrabbit: was there ever a published double-blind test result about it? [15:22:29 CET] <sfan5> redrabbit: ABX test results or gtfo [15:22:38 CET] <JEEB> just watch the thing sfan5 linked [15:22:58 CET] <JEEB> what was picked for audio CDs was surprisingly sane in hindsight [15:23:03 CET] <kerio> "by the way these are 800$ headphones" "omg i can totally hear the extra bits" [15:23:04 CET] <redrabbit> i did some vinyl rips [15:23:08 CET] <kerio> JEEB: fuck 44100 tho [15:23:14 CET] <redrabbit> and the rips with 96khz 24bit sound better [15:23:16 CET] <redrabbit> more natural [15:23:21 CET] <kerio> vinyl isn't natural [15:23:34 CET] <redrabbit> if you downsample it it sounds more closed [15:23:36 CET] <JEEB> kerio: well even that is 22.050kHz minus some with nyquist [15:23:55 CET] <kerio> JEEB: i'm not arguing about the magnitude [15:24:37 CET] <kerio> i'm arguing against choosing 44100 instead of 48000 [15:24:43 CET] <JEEB> sure [15:24:45 CET] <kerio> fuck that 49 factor [15:24:51 CET] <JEEB> I have no historical info on that [15:25:11 CET] <JEEB> and no idea why broadcast and music CDs ended up with different rates [15:25:15 CET] <kerio> it's 2*2*3*3*5*5*7*7 [15:25:20 CET] <matt3o12> Sorry, Ive been disconnected. Does the channel have a log for any message I might have missed? [15:25:40 CET] <kerio> and they specifically chose a different sample rate than DAT so people couldn't copy them as easily [15:25:44 CET] <redrabbit> The key difference between 24 bit audio and 16 bit audio is the noise floor. In other words, a quiet sound recorded in 24 bit has less inherent noise than the same sound recorded in 16 bit. This allows for a much wider dynamic range in 24 bit recordings. You can see hear for yourself if you record a very quiet sound in both 16 and 24 bit, then normalize both files to a higher output level; the 16 bit f [15:25:50 CET] <JEEB> matt3o12: http://up-cat.net/p/a93537a7 [15:25:50 CET] <redrabbit> ile will be audibly noisy compared to the 24 bit file. [15:25:53 CET] <redrabbit> boom headshot [15:26:01 CET] <matt3o12> JEEB: thanks :) [15:26:22 CET] <JEEB> and then I linked the filtering guide as well https://trac.ffmpeg.org/wiki/FilteringGuide [15:26:24 CET] <kerio> "if you fuck up your audio file in this specific way, 24 bit ends up better than 16 bit" [15:26:36 CET] <redrabbit> quit trolling [15:26:45 CET] <redrabbit> better noise floor [15:26:48 CET] <redrabbit> fact. [15:27:18 CET] <redrabbit> mathematically superior [15:27:18 CET] <JEEB> redrabbit: for filtering higher precision is useful, but that's it :P [15:27:43 CET] <JEEB> if you're supposed to be listening it there should be no discerning differences [15:27:46 CET] <redrabbit> well 98% of my library is 44.1 [15:28:09 CET] <JEEB> anyways, please have a watch of that xiph.org video article [15:28:12 CET] <JEEB> it is useful [15:28:45 CET] <neverminder> What could be the problem here? It just hangs while eating 100% of one CPU core: https://pastebin.com/tAc9AU46 [15:29:06 CET] <kerio> om nom nom [15:29:21 CET] <kerio> neverminder: does guvcview work? [15:29:24 CET] <redrabbit> 44.1-16 is fine, its silly to say anything above it isnt better [15:29:38 CET] <redrabbit> ok it can restitute up to 20khz [15:29:39 CET] <sfan5> neverminder: uh? https://trac.ffmpeg.org/ticket/6889 [15:29:44 CET] <redrabbit> but how ugly is that restitution [15:29:54 CET] <JEEB> please just watch the video [15:30:04 CET] <JEEB> or read the article in text [15:30:19 CET] <neverminder> sfan5: I closed the ticket, because after latest update the problem changed [15:30:20 CET] <JEEB> but the video might help you understand these things better as it's not just text but actual tests with things as well [15:30:38 CET] <neverminder> kerio: what exactly is that? [15:30:55 CET] <kerio> some other program to view webcams or other v4l2 sources [15:31:09 CET] <redrabbit> theres no vid on that link [15:31:30 CET] <sfan5> redrabbit: https://video.xiph.org/vid2.shtml (?) [15:31:45 CET] <neverminder> kerio: well recording video alone works, same with audio alone, so not sure why combined it doesn't? [15:31:46 CET] <kerio> actually it might be just for UVC devices [15:31:49 CET] <JEEB> redrabbit: it has a link to what sfan5 just linked [15:31:51 CET] <redrabbit> high frequency sounds are more detailed with 96-24 [15:31:56 CET] <kerio> oh then idk [15:32:03 CET] <redrabbit> the highs are smoother at high volume [15:32:21 CET] <redrabbit> less agressive [15:32:52 CET] <sfan5> I like my music aggressive [15:33:19 CET] <redrabbit> you punk [15:34:31 CET] <redrabbit> that dude on the vid is too old to hear the difference [15:34:37 CET] <redrabbit> im probably as well [15:34:45 CET] <redrabbit> i could hear it when i was younger. [15:34:56 CET] <JEEB> just watch through it [15:34:56 CET] Action: redrabbit speak the true true [15:37:47 CET] <redrabbit> i hope he test other stuff than sins [15:38:00 CET] <redrabbit> sinus obviously is gonna be pretty transparent [15:39:10 CET] <redrabbit> music aint a sine wave [15:39:13 CET] <redrabbit> dumb shit [15:39:49 CET] <redrabbit> try with a f-ing square pls [15:40:00 CET] <JEEB> go poke #xiph with that [15:40:19 CET] <redrabbit> do the same shit with a square signal at 22khz [15:40:23 CET] <redrabbit> and gimme the lols [15:40:31 CET] <redrabbit> its gonna look like shit [15:41:56 CET] <redrabbit> its mathematically impossible to get a proper square signal at 22khz at these sample rates [15:42:28 CET] <redrabbit> however 96-24 can do it. [15:43:59 CET] <redrabbit> so, better highs, better depth, better dynamic. [15:44:18 CET] <redrabbit> sure its marginal, but saying it doesnt do anything is silly [15:45:29 CET] <kerio> redrabbit is literally a dog [16:02:49 CET] <redrabbit> woof [16:23:11 CET] <Fyr> guys, when converting a 8k video, FFMPEG tries to mallocate a huge amount of memory. is there a way to avoid such mallocation? [16:23:46 CET] <Fyr> it seems like 24 Gb of RAM and 2 Gb of swap is not enough. [16:24:54 CET] <DHE> each frame has 32 million pixels. multiply by the sample sizes, multiply by internal buffering for look-ahead and bframes and stuff... that doesn't sound COMPLETE nuts... [16:25:10 CET] <DHE> maybe turn down lookahead frames? (if your codec does so) [16:25:21 CET] <Fyr> ok, DHE, how much memory is required to convert 8k video? [16:25:30 CET] <JEEB> depends on the encoder and the settings [16:25:40 CET] <JEEB> if you do just `ffmpeg -i input -f null -` [16:25:44 CET] <JEEB> you can see how much pure decoding takes [16:25:45 CET] <Fyr> libx264, the setting are set to default. [16:25:46 CET] <JEEB> :P [16:25:55 CET] <JEEB> yes, libx264 I think buffers 40 or 60 frames by default [16:26:08 CET] <DHE> dunno. but my multi-bitrate application takes like 700 MB of RAM with 1080p input.. so crank that by 16x sounds completely reasonable actually [16:27:53 CET] <Fyr> JEEB, will NVENC require such amount of memory? [16:28:20 CET] <JEEB> Fyr: you sure fly from one topic to another don't you [16:28:29 CET] <JEEB> why didn't you rather ask "how do I minimize the buffering"? [16:28:41 CET] <DHE> I though 4096x4096 was the nvenc limit [16:28:50 CET] <Fyr> oh, ='( [16:28:50 CET] <JEEB> anyways, no idea how fucking much nvenc buffers but DHE noted the max res [16:29:10 CET] <DHE> Fyr: add -tune zerolatency and see if the memory usage goes way down (at the expense of quality mind you) [16:29:25 CET] <Fyr> ok, thanks [16:29:38 CET] <JEEB> that is just the single-line way of disabling as much buffering as possible [16:29:57 CET] <JEEB> you can then move into tweaking if you want [16:30:35 CET] <DHE> yeah this is intended as "proof that internal buffering is the cause" by eliminating internal buffering. though I'm 97% sure I'm right [16:31:01 CET] <JEEB> well yea [16:31:12 CET] <JEEB> that's pretty obvious that it is the reason because libx264 buffers 40-60 pictures [16:31:15 CET] <JEEB> by default [16:31:18 CET] <JEEB> (preset medium) [16:31:20 CET] <Guest64446> Is this the right channel to ask about how to record an OpenGL animation to an mp4 file? [16:34:36 CET] <Guest64446> I used this command on the apitrace page but the output is very pixelated and grainy: apitrace dump-images -o - solid.trace | ffmpeg -r 30 -f image2pipe -vcodec ppm -i pipe: -vcodec mpeg4 -y solid.mp4 [16:38:36 CET] <DHE> Guest64446: mpeg4 is an old codec and you didn't specify any settings like bitrates. add "-qp 3" just after -y for a pretty high quality version [16:40:11 CET] <Guest64446> basically, I want to put this animation on my web page and have anyone with a browser be able to watch it. I assumed mpeg4 was the most popular - but if there's something better I'm all ears ... [16:41:18 CET] <Guest64446> Sorry, I don't mean in a web browser, I mean someone with your typical Windows 10 computer [16:42:15 CET] <Guest64446> or I suppose in a browser - I'm not sure if/which video is viewable in a browser [16:42:18 CET] <DHE> mpeg4 can be misleading as technically it's a multi-section document describing multiple codecs. "mpeg4" is mpeg4 part 2 (once known as DivX in the early 2000s) [16:42:40 CET] <DHE> nowadays you want h264 (aka mpeg4 part 10) which requires -c libx264 with ffmpeg [16:43:24 CET] <DHE> with h264 instead try encoding with -crf 22 for your quality setting [16:45:53 CET] <Guest64446> what should the extension of an h264 output file be? [16:46:56 CET] <DHE> .mp4 is fine [16:47:23 CET] <DHE> if you want streaming support there's more options you should add, but let's do one step at a time [16:48:40 CET] <Guest64446> well with those settings you mentioned, it looks great... [18:57:29 CET] <Darxus> I'm using ffmpeg version 2.8.11-0ubuntu0.16.04.1. I'm trying to convert a bunch of png's to webm. It works until I specify a framerate with "-r 2". Without specifying a framerate, I get this at 25fps, which is fine: http://www.eternalmachinery.com/ecar/ebucket25fps.webm With "ffmpeg -i ebucket%04d.png -r 2 ebucket2fps.webm" I get this, which is all messed up: [18:57:34 CET] <Darxus> http://www.eternalmachinery.com/ecar/ebucket2fps.webm Is this a known bug? How ... [18:57:37 CET] <Darxus> ... do I get a slower video from these images? [18:59:20 CET] <DHE> put "-framerate 2" ahead of -i instead so it's treated as a 2fps input [19:00:36 CET] <Darxus> DHE: Hah, that did it, thank you. [19:01:22 CET] <Darxus> I did try playing with -framerate, but it's... not actually documented in the man page? [19:01:56 CET] <DHE> ffmpeg is a collection of modules which accept different options. -framerate is an option specific to the demuxer that makes a movie out of a series of still image files [19:02:23 CET] <DHE> https://ffmpeg.org/ffmpeg-formats.html#image2-1 [19:02:53 CET] <Darxus> Ahh, thanks. You've resolved an awful lot of frustration for me. [19:22:57 CET] <Darxus> I'm currently rendering that same animation at 1920x1080, with 800 frames, instead of 20. If I want to reduce that to a 1 megabyte video, what would give me the best results? Leave the resolution and frame rate, and use lots of compression? Reduce the frame rate? Reduce the resolution? [19:23:07 CET] <d9867eb> hi [19:23:42 CET] <durandal_1707> hi [19:25:26 CET] <d9867eb> I wrote a script https://pastebin.com/DLfpDn5L for encoding movies to x265 or theora. can you please critique it? [19:26:35 CET] <sfan5> why theora [19:26:53 CET] <d9867eb> because it is opensource [19:27:21 CET] <BtbN> x265 is as well [19:27:39 CET] <d9867eb> no just parts [19:27:50 CET] <BtbN> uhm, no [19:28:36 CET] <DHE> you mean the mpeg licensing stuff? [19:29:01 CET] <d9867eb> hmm probably [19:29:17 CET] <DHE> Darxus: 800 frames at 1080p for 1 megabyte of file size? dunno if the quality is going to be there unless it's very low motion [19:29:43 CET] <sfan5> aside from your script being totally unreadable: use a proper option parser, why is quality different when not using -i? why are you using mp3 for audio? why aren't you using vp8/vp9 instead of theora? [19:30:29 CET] <sfan5> Darxus: you can also keep both and just turn the quality of the video down, and make sure to use 2pass encoding when targeting a specific file size [19:30:38 CET] <Darxus> DHE: I'd say it's low motion. I'm mostly just curious. I feel like I should be able to tell ffmpeg a target file size and have it figure out the best way to get there, by cranking up compression / dropping frames / reducuing resolution. [19:30:57 CET] <DHE> Darxus: how long is the video? (for calculation purposes) [19:31:24 CET] <d9867eb> sfan5: what is option parser? [19:31:26 CET] <Darxus> DHE: Say 60fps, 13 seconds. [19:31:35 CET] <sfan5> d9867eb: e.g. GNU getopt [19:33:08 CET] <DHE> Darxus: making it up as I go, I'd start with: ffmpeg -framerate 60 -i ebucket%04d.png -c:v libx264 -r 20 -pix_fmt yuv420p -g 300 -preset slow -s 1280x720 -b:v 600k -pass 1 output.webm [19:33:16 CET] <d9867eb> sfan5: why is quality different? becuase if I expect DVD to have higher quality than a already encoded file [19:33:20 CET] <DHE> then run it again with -pass 2 instead [19:33:57 CET] <d9867eb> sfan5: then what is a okay quality to use in the script? [19:34:11 CET] <DHE> bring it down to 20fps, 720p, and see how it looks. [19:34:31 CET] <sfan5> d9867eb: that depends very much on the input video, your qualitty settings are not necessarily bad [19:34:38 CET] <sfan5> was just wondering why they differ in specific cases [19:35:24 CET] <Darxus> DHE: Thanks. [19:35:47 CET] <d9867eb> sfan5: isnt vp8/vp9 intended for video on the web? [19:35:58 CET] <sfan5> sort of, is that a problem? [19:36:04 CET] <DHE> Darxus: take a look and play with it a bit. bitrate tweaks can be done with only a pass 2 re-run. other changes require running both passes again [19:36:22 CET] <sfan5> theora is pretty old and you should be using something better if you can [19:36:35 CET] <Darxus> DHE: Nice, thanks. [19:36:37 CET] <d9867eb> sfan5: not necesseraly [19:38:27 CET] <d9867eb> but i thoght a more general format would be better for longterm video storing [19:40:25 CET] <d9867eb> when encoding using my script it dosent skip the dvd_nav_packet. how do I skip it but keep all other streams? [19:44:46 CET] <Darxus> Wow, it came out as 384K with the defaults: http://www.eternalmachinery.com/ecar/ebucket4big.webm [19:50:41 CET] <ayum> Hi, Seems ffmpeg will according to the timestamp to drop or duplicate frame sometimes, but my current project require ffmpeg do no drop and duplicate frames, is this possible by setting some ffmpeg options? [19:51:34 CET] <JEEB> -vsync vfr or -vsync copy [19:51:44 CET] <ayum> okay, let me try it [19:53:16 CET] <ayum> it's still dropping [19:53:52 CET] <ayum> I wrote a compare filter for used to compare 2 v4l2 streams [19:54:14 CET] <ayum> the compare filter is based framesync [19:55:01 CET] <ayum> perhaps framesync will cause some problem and make 2 v4l2 input streams not synchronized [19:58:34 CET] <durandal_1707> ayum: you need to setpts filter for pts to be always properly defined, otherwise you will get wrong results [20:00:44 CET] <ayum> can you give me an example command about setpts filter? I am not sure how to use it. like: -filter_complex setpts=??? [20:03:49 CET] <durandal_1707> setpts=N ? [20:04:21 CET] <ayum> This is my current command: [20:04:22 CET] <ayum> ./ffmpeg -f v4l2 -thread_queue_size 256 -i /dev/video1 -f v4l2 -thread_queue_size 256 -i /dev/deo0 -f alsa -thread_queue_size 256 -i hw:2,0 -filter_complex "[0:v]setpts='(RTCTIME - RTCSTART) / (TB * 1000000)'[o0];[1:v]setpts='(RTCTIME - RTCSTART) / (TB * 1000000)'[o1];[o0][o1]compare" -c:v h264_nvenc -b:v 4M -maxrate 5M -c:a libfdk_aac -ar 44100 -ac 2 -b:a 128k -f mpegts udp://192.168.2.2:9999 -loglevel verbose [20:04:48 CET] <ayum> and works good, but many "Past duration too large" warnings [20:14:05 CET] <DHE> Darxus: turn out okay? [20:14:57 CET] <Darxus> DHE: Not great, still playing. Doing two pass right now. [20:28:27 CET] <ayum> I am using this filter complex, is it correct? "[0:v]setpts=FRAME_RATE[o0];[1:v]setpts=FRAME_RATE[o1];[o0][o1]compare,setpts=N/FRAME_RATE/TB" [20:29:11 CET] <ayum> I think it's wrong, especially. setpts=FRAME_RATE. [20:30:31 CET] <durandal_1707> that sets pts to constant value [20:54:00 CET] <Darxus> Wow, that's quite a difference in the two video loops at the top of this page: http://www.eternalmachinery.com/ecar/ [20:54:56 CET] <Darxus> The top, smoother one, is 452K webm, the second, with far fewer frames, is 452K ogg theora. [20:59:31 CET] <d9867eb> sfanhi [20:59:33 CET] <d9867eb> hi [20:59:44 CET] <sfan5> what [20:59:45 CET] <d9867eb> i am still having problems [21:00:10 CET] <d9867eb> also when i encode *.VOB files using my script, the navigation is displayed in the begginning of the movie. how do i skip it? [21:00:55 CET] <sfan5> you probably need to choose the correct vob file to skip those [21:01:08 CET] <d9867eb> and flac dosent seem to work my script. why? should i use another codec? [21:01:35 CET] <sfan5> i'd suggest using a different utility first to remux the DVD to some usable format, after that you can re-encode it [21:02:14 CET] <d9867eb> sfan5: like what? [21:02:59 CET] <sfan5> makemkv [21:03:30 CET] <d9867eb> is that open source? [21:03:59 CET] <sfan5> no [21:04:26 CET] <d9867eb> sfan5: i want that [21:04:32 CET] <durandal_1707> why you promote closed payware here? [21:04:52 CET] <sfan5> because it just works" [21:05:08 CET] <sfan5> d9867eb: then consider something like handbrake instead, it should also be able to read DVDs [21:06:44 CET] <d9867eb> sfan5: but i had like to use ffmpeg instead, isnt there some way to make my script work? [21:07:39 CET] <sfan5> this would be helpful [21:10:03 CET] <d9867eb> here is the output from my script https://pastebin.com/Z4z2xkD8 [21:10:18 CET] <d9867eb> sfan5: [21:10:50 CET] <sfan5> i thought there was a problem with flac? [21:12:24 CET] <d9867eb> sfan5: script in current state https://pastebin.com/uNDLSbJi [21:13:06 CET] <sfan5> also since your source is DVD you probably want to deinterlace [21:14:14 CET] <d9867eb> sfan5: how? [21:15:10 CET] <sfan5> -vf yadif [21:17:55 CET] <d9867eb> sfan5: my script doesent appear to recognise audio from dvds. [21:18:15 CET] <sfan5> this is why i suggested a different utility [21:19:29 CET] <d9867eb> sfan5: so this is like impossible to do? [21:19:35 CET] <sfan5> dunno [21:19:47 CET] <sfan5> it's just that I do not know what's wrong here [21:22:00 CET] <d9867eb> ok thanks anyway [21:23:15 CET] <d9867eb> i remember reading a blog about this some time ago, I will go search for that [21:42:03 CET] <d9867eb> navigation issue solved [21:42:38 CET] <d9867eb> audio seems to work with a another video [21:57:27 CET] <neverminder> is it possible to record video and output it to screen at the same time? [22:53:40 CET] <Sun> Hello! I'm trying to add a logo to the video. Is it possible to scale image according to the video resolution? I found the variables about the image's itself width and height only... I would like to use something like: -filter_complex "scale=772*main_w/1920:184*main_h/1080[logo], [src][logo]overlay=32*main_w/1920:872*main_h/1080". So here as I understand, overlay works fine, but with scale there are some problems... [22:54:40 CET] <Sun> So is there kind of variables I could use instead of "main_w" and "main_h" in the "scale" section? [22:55:49 CET] <durandal_1707> see scale2ref filter [23:05:17 CET] <Sun> Thank You :) But it seems, the filter section becomes more and more complicated... is it possible to debug the inputs and outputs between the filters somehow? [23:06:23 CET] <Sun> So for example, now I've got the problem, that scale generated only one stream (or so), and it was ok for overlay filter. So as I understand, scale2ref generate 2 outputs? [23:06:30 CET] <durandal_1707> scale2ref filter needs 2 inputs and give two outputs [23:15:28 CET] <Sun> Sorry, got completely confused :( So I'm using this: "... [deint][2]scale2ref=772*main_w/1920:184*main_h/1080[logo], [logo]overlay=32*main_w/1920:872*main_h/1080". So ffmpeg shows me many errors [23:16:12 CET] <Sun> Undefined constant or missing '(' in 'main_w/1920', Failed to configure output pad on Parsed_scale2ref_1 and so on [23:17:03 CET] <durandal_1707> Sun: have you read documentation of scale2ref filter? [23:19:09 CET] <Sun> Yes, but only this one: https://ffmpeg.org/ffmpeg-filters.html#scale2ref - maybe the problem is I'm not so experienced how to use filter chains and so on, but please, could You give me a hint, what could be wrong here? [23:24:06 CET] <Darxus> Re-rendering with -deadline best gave me a 7.0% decrease in file size. Took an hour and 20 minutes. I think the default encoding took something like 7 minutes. [23:26:52 CET] <durandal_1707> Sun: you need to specify 2 outpads for scale2ref filter [23:27:55 CET] <Sun> it's strange, but I did, and it didn't help, the same errors... "... [2][deint]scale2ref=772*main_w/1920:184*main_h/1080[logo][vid], [vid][logo]overlay=32*main_w/1920:872*main_h/1080" [23:29:03 CET] <Sun> Here are the errors: https://pastebin.com/rZt6VnDX [23:30:47 CET] <durandal_1707> Sun: what ffmpeg version? [23:31:29 CET] <Sun> ffmpeg version N-79143-g8ff0f6a Copyright (c) 2000-2016 the FFmpeg developers [23:31:50 CET] <BtbN> that's quite old [23:32:36 CET] <durandal_1707> why dont you try more recent one, main_w should be recognized [23:34:23 CET] <Sun> Ouch... just used it for long time without problem and didn't even noticed that it has been outdated :) I try new one [23:35:58 CET] <BtbN> well, if you used it for a long time, and never updated it, what did you expect? :D [23:48:27 CET] <Sun> lol, now it works :D [23:49:36 CET] <Sun> But still a little problem: width not divisible by 2 (257x61) - it seems, the problem is that by scaling it became odd... Is it possible to round somehow that it be dividable by 2? :) [23:51:06 CET] <zash> Heh, two primes for size [23:51:38 CET] <Sun> Found only this solution: scale="854:trunc(ow/a/2)*2" [23:52:06 CET] <BtbN> put -2 for one of the two [23:52:27 CET] <BtbN> Or what kind of weird scaling do you want to do that does not keep aspect? [23:54:33 CET] <FishPencil> Where does FFmpeg need to find AMF to be included? I just keep getting 'ERROR: amf requested but not found'. The header can be found in AMF/core/Version.h [23:55:22 CET] <sfan5> it should be in your compiler's default include folder [23:55:23 CET] <FishPencil> That error doesn't really help much either [23:55:33 CET] <sfan5> also take a look at ffbuild/config.log [23:55:41 CET] <FishPencil> I did, that's the last line [23:55:44 CET] <FishPencil> All it says [23:56:04 CET] <sfan5> there's more usually (detailing what it ran to check for amf) [23:56:38 CET] <FishPencil> That's all it says [23:57:27 CET] <Sun> BtbN: I have a bit non-standard picture size, which I want to embed in the video, and it doesn't want to embed any pictures, which sizes are both non-dividable by 2... [00:00:00 CET] --- Sun Dec 10 2017

1 0

ffmpeg-devel.log.20171208
by burek 09 Dec '17

09 Dec '17

[00:31:05 CET] <SortaCore> I'm completely bricked from using my project because of this atomic bug [00:31:52 CET] <nevcairiel> dont use git master if you cant deal with occasional breakage =p [00:34:57 CET] <SortaCore> I expected quality control, and I am just feeling sooooo victimised here! [00:35:58 CET] <SortaCore> more to the point, if it breaks my project, it could potentially break a lot of projects [00:36:02 CET] <JEEB> report the issue on the trac and/or on the -devel ML if you know at least some specifics [00:36:21 CET] <Compn> SortaCore : not many projects use git master ffmpeg [00:36:23 CET] <SortaCore> I figured atom made the changes so he could investigate easier than anyone else [00:36:45 CET] <JEEB> yea, if he comes around. [00:37:08 CET] <Compn> SortaCore : just git pull back a few revisions and stick with that [00:37:20 CET] <Compn> no use in complaining about what is broke (sorry) :) [00:37:22 CET] <nevcairiel> the issue is being discussed on the ML already [00:37:25 CET] <JEEB> well yes, that is the short time workaround [00:37:28 CET] <JEEB> nevcairiel: ah [00:37:30 CET] <JEEB> good then [00:37:47 CET] <Compn> and yes, no one is supposed to break git master, but it does happen [00:37:59 CET] <JEEB> yea, the main part is to try and start flagging breakages [00:38:11 CET] <Compn> rarely i would say [00:38:11 CET] <Compn> monthly ? [00:38:13 CET] <JEEB> because if no-one knows it's never going to be fixed [00:38:27 CET] <nevcairiel> especially on some compilers that only few people use on a daily basis [00:38:32 CET] <Compn> SortaCore : remember we are all volunteer army here :) [00:39:02 CET] <Compn> did anyone ever reply to the amd guy about moving nvidia headers to a new repo ? [00:39:59 CET] <JEEB> Compn: lately breakages have been the addition of windows.h to a lot of stuff, the HEVC NEON SIMD breaking clang on 32bit ARM and seemingly also gcc with aarch64? [00:40:07 CET] <SortaCore> volunteers huh [00:40:19 CET] <SortaCore> I could accidentally slip some money to a random paypal address [00:40:36 CET] <JEEB> the windows.h stuff quickly got stuff on the ML as far as I can see, but not sure if that got fixed [00:40:53 CET] <JEEB> the NEON thing I tried to bring up on the ML, but seems like not many cared [00:41:21 CET] <nevcairiel> not yet, but hopefully soon [00:42:48 CET] <JEEB> rcombs: have you hit this one btw? https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221518.html [00:42:57 CET] <JEEB> I remember you poking android [00:43:15 CET] <JEEB> and/or if it just happened to be something that would get fixed with R16 [00:43:32 CET] <rcombs> my fork's a bit behind right now, but I haven't seen that so far [00:44:17 CET] <vicky_> ============== [00:44:18 CET] <vicky_> File : /home/ppxyz/public_html/clip/files/thumbs/2017/12/07/1512668598dc0ae-768x432-1.jpg ====== End : Thumbs Generation ======= Conversion Completed -------------------- Time Took : 1.4912 seconds conversion_status : failed [00:44:20 CET] <vicky_> ================= [00:44:21 CET] <nevcairiel> did you try asking wbs about that? [00:44:26 CET] <vicky_> How we can fix this issue? [00:44:39 CET] <JEEB> nevcairiel: I guess I'll build what he cares about (libav) and see if it's broken there [00:45:07 CET] <jdarnley> What issue? I see no error message. [00:45:24 CET] <vicky_> conversion_status : failed [00:45:27 CET] <nevcairiel> he is a reasonable guy, he might be able to help no matter what =p [00:45:33 CET] <nevcairiel> finding out which commit caused it might help [00:45:47 CET] <rcombs> so, does anyone have any input on this thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221880.html [00:45:48 CET] <JEEB> it was one of the semi-recent merges, that much I remember [00:45:52 CET] <vicky_> I'm getting this error "conversion_status : failed" only [00:45:54 CET] <Compn> vicky_ : ask in #ffmpeg , not here [00:46:16 CET] <vicky_> ok, tx [00:46:18 CET] <JEEB> I don't think that's on-topic even for #ffmpeg [00:46:18 CET] <rcombs> tl;dr I'm trying to deal with users who get corrupted data back from their tuners [00:46:30 CET] <Compn> JEEB : shhhhhhhh [00:46:36 CET] <JEEB> since it's not FFmpeg itself [00:46:47 CET] <tmm1> rcombs: two options sound reasonable [00:46:55 CET] <JEEB> rcombs: that makes total sense and I guess the third timestamp @ upipe is for that [00:47:22 CET] <rcombs> upipe? [00:47:40 CET] <JEEB> the live/MPEG-TS centric multimedia framework [00:47:43 CET] <JEEB> they have three timestamps IIRC [00:47:56 CET] <nevcairiel> rcombs: i always wondered about the error bit, i mean if its just corrupt data, is there any guarantee that the flag is set and not just the data corrupted? [00:48:16 CET] <JEEB> one for coded timestamp, another for "fixed to be actually usable" timestamp and then the receipt timestamp [00:48:29 CET] <rcombs> nevcairiel: that bit is supposedly set _by the tuner_ [00:48:32 CET] <JEEB> if I recall correctly [00:48:33 CET] <rcombs> rather than coming in OTA [00:48:52 CET] <nevcairiel> so the tuner knows stuff is broke? [00:48:55 CET] <rcombs> specifically, it's supposed to be set if applying FEC resulted in uncorrectable errors [00:49:19 CET] <rcombs> i.e. there were more than N bitflips [00:49:23 CET] <rcombs> JEEB: ah [00:50:30 CET] <tmm1> what was the behavior when one of those was encoutered before the patch? [00:50:52 CET] <rcombs> you'd just get a corrupted packet, and the timestamp may have had bitflips [00:51:11 CET] <tmm1> i see, so the ts could be totally incorrect and would affect playback etc [00:51:18 CET] <rcombs> timestamp bitflips are about the worst thing that can happen in a lavf/ffmpeg pipeline [00:51:43 CET] <rcombs> so, let's say one timestamp comes in that's ridiculously high [00:51:58 CET] <rcombs> ffmpeg.c will see that as the "last known timestamp" [00:52:07 CET] <rcombs> and then correct _all future timestamps to be monotonically increasing from there_ [00:52:14 CET] <tmm1> oh yea, ick [00:52:26 CET] <rcombs> so your output has a giant discontinuity, followed by every timestamp increasing by 1 [00:52:32 CET] <JEEB> yup [00:52:55 CET] <rcombs> also, I'm taking input from a tuner and writing output using segment.c [00:53:11 CET] <rcombs> so the segment.c output manifest would have that segment as absurdly long [00:53:32 CET] <tmm1> nasty [00:53:41 CET] <rcombs> I used to make the mistake of feeding that data back into another lavf as HLS [00:53:57 CET] <rcombs> turns out if hls.c encounters a timestamp of 12 hours, it& waits 12 hours before refreshing the manifest [00:54:14 CET] <JEEB> ayup [00:54:39 CET] <rcombs> which is stupid in itself; I need to patch that to use FFMAX(last_seg_duration, target_duration) [00:54:45 CET] <SortaCore> why does hwcontext_qsv.c have a bunch of serious-looking error message with "verbose" level instead of error? [00:55:21 CET] <JEEB> ok, so libav isn't affected with the HEVC NEON stuff (Ž4@) [00:55:52 CET] <tmm1> wow i finally figured out this yadif + hlsenc timestamp issue [00:55:54 CET] <JEEB> might try to check which merge it was [00:56:00 CET] <JEEB> but not tonight [00:56:29 CET] <SortaCore> tonight he parties [00:57:09 CET] <JEEB> no, I just used up my time with another project putting acceptable PRs in :P [00:57:37 CET] <JEEB> LOL [00:57:51 CET] <JEEB> on the ML I find a patch from eleks.com for seemingly to fix the build error [00:58:37 CET] <tmm1> link? [00:59:14 CET] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221881.html [00:59:25 CET] <JEEB> (I like the bog-standard e-mail footer) [00:59:46 CET] <tmm1> oh i think i saw that earlier and didn't boether clicking through [01:00:02 CET] <tmm1> is there an easy way to map ffmpeg-devel message url to the patchwork url? [01:00:24 CET] <JEEB> in this case the patch is an attachment so it's linked there [01:00:46 CET] <JEEB> so you can get the patch from pipermail [01:01:02 CET] <tmm1> yea but my browser tries to download it and then i have to go view it on disk [01:01:21 CET] <JEEB> "Fixed by added "ltorg" directive after the function end, allowing compiler to allocate the local storage just after the function code if neccessary." [01:01:36 CET] <JEEB> tmm1: I got recommended an extension for that by wm4 [01:01:50 CET] <JEEB> https://github.com/Rob--W/open-in-browser [01:02:05 CET] <tmm1> cool [01:02:22 CET] <tmm1> huh i just clicked it and it showed as text in the browser this time [01:02:32 CET] <JEEB> vOV [01:02:46 CET] <tmm1> looks like an easy enough fix [01:02:52 CET] <JEEB> yup [01:10:34 CET] <jamrial> JEEB: did you see vlc's commit d14c813b19? [01:10:50 CET] <JEEB> not yet [01:11:10 CET] <jamrial> it fixes something related to hevc in arm in ffmpeg [01:11:30 CET] <jamrial> no idea what neon failure you're talking about above, but maybe it's related? [01:15:35 CET] <tmm1> phew, two days of head-scratching for a 20 byte patch [01:32:21 CET] <Chloe> turing codec is back [01:33:02 CET] <Chloe> meanwhile, literally none of the issues blocking it previously have been resolved [01:34:47 CET] <JEEB> tmm1: yea I kind of guessed that it might actually solve it after seeing it the first time :D [01:37:19 CET] <tmm1> JEEB: hah! [01:37:58 CET] <tmm1> i'll send you an invoice for my gray hairs [01:40:48 CET] <JEEB> that was after I linked it to you, that is [01:40:57 CET] <JEEB> and I didn't test it :D [01:41:00 CET] <JEEB> but glad it does work [01:41:24 CET] <JEEB> and yea, I wish I knew enough NEON to catch that one myself :P [01:41:51 CET] <JEEB> looking at the patch and explanation it was just one of those "d'oh" moments where I bet it would fix it if it was this simple [02:12:16 CET] <atomnuker> daddesio: nope, doesn't fix the errors [02:13:08 CET] <atomnuker> SortaCore: I don't know what weird system you're compiling on but the logic's solid [02:19:14 CET] <SortaCore> Windows mingw64 [02:19:37 CET] <SortaCore> static library used in 32-bit [02:38:09 CET] <daddesio> atomnuker: it does on my end. I'll submit my patch on the ML. [02:39:24 CET] <atomnuker> + int offset = (8 << f->size) * ff_celt_freq_bands[i]; [02:39:26 CET] <atomnuker> + int count = (8 << f->size) * (ff_celt_freq_range[i] - ff_celt_freq_range[i-1]); [02:39:39 CET] <atomnuker> is your patch basically this? [02:47:17 CET] <atomnuker> daddesio: could you reduce the diff from libopus by allocating 1 band's worth of coeffs? [02:47:31 CET] <atomnuker> maybe it'll speed it up even [04:23:40 CET] <SortaCore> atomnuker: it's because you use _Bool for exp, and on non-gcc atomic_bool is defined to intptr_t [04:25:03 CET] <SortaCore> there's also no initialising for ff_avcodec_locked, like there is for entangled_thread_counter, that may be a factor too [04:27:10 CET] <wm4> I didn't really follow this atomic stuff, but the compat wrapper defines atomic_bool to intptr_t because there's no other way to support the "generic" atomic_ macros [04:27:17 CET] <wm4> which in real C11 are compiler magic [04:27:54 CET] <SortaCore> well, I replaced that and it works [04:29:41 CET] <daddesio> atomnuker: int offset = ff_celt_freq_bands[i] << f->size and int count = (ff_celt_freq_range[i] - ff_celt_freq_range[i-1]) << f->size. [04:29:51 CET] <daddesio> In fact, then offset = band_offset :P [04:30:39 CET] <daddesio> I could rewrite the function to always use 8x indexing, but there's no real need [04:30:51 CET] <daddesio> I don't see how one way is faster than the other. [04:32:48 CET] <atomnuker> you save having to copy an entire stack's worth of coefficients? [04:33:09 CET] <daddesio> then isn't our way faster? since we're using the minimal indexing possible [04:33:21 CET] <atomnuker> no, indexing is cheap [04:33:22 CET] <daddesio> e.g. 4x indexing when f->size = 2. [04:33:52 CET] <daddesio> actually, where does that copy take place, that you're referring to? [04:33:52 CET] <atomnuker> and indexing is basically free on x86 [04:34:09 CET] <daddesio> my memcpy? [04:35:08 CET] <atomnuker> that and the is/ds switch [04:37:07 CET] <daddesio> well our Special Hybrid Folding memcpy will be faster than libopus (once we correct the patch to << f->size instead of * 8), since our version of norm[] uses tighter indexing. [04:37:40 CET] <daddesio> libopus always multiply by 8. we do a shift by 0, 1, 2, or 3. [04:37:46 CET] <daddesio> multiplies* [04:39:56 CET] <daddesio> if libopus wanted it to do it faster, they could have done a for loop with a stride of 8 >> f->size. [04:42:25 CET] <atomnuker> ok, this works, I'll run fate to make sure the tests pass without deviation and push it [04:43:33 CET] <daddesio> Yeah, don't forget, you can get rid of the "int offset" variable and replace it with band_offset. [05:15:11 CET] <SortaCore> can anyone confirm switching the variable type inside the lock/unlock fixes it? [05:15:47 CET] <wm4> can you paste a diff? [05:16:12 CET] <wm4> (you probably posted it on the ML, but I'm not following this discussion closely) [05:16:19 CET] <wm4> just getting curious why it's such a problem [05:17:57 CET] <SortaCore> it does "atomic var == expected var" check with an atomic function [05:18:06 CET] <SortaCore> and it fails, because expected var type doesn't match atomic var type [05:18:56 CET] <wm4> which atomic function? [05:19:26 CET] <SortaCore> atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 1) [05:19:48 CET] <SortaCore> I would post a diff but my version is packed with av_log stuff to see how it broke [05:20:19 CET] <jamrial> ff_avcodec_locked is _Atomic _Bool and exp is _Bool, so they are the same type [05:20:45 CET] <SortaCore> nah, atomic_bool is intptr_t [05:20:58 CET] <SortaCore> ...well, I'd check at runtime, if there was a way to do that [05:21:03 CET] <jamrial> are you using msvc? [05:21:09 CET] <SortaCore> just replace the _Bool variable with atomic_bool, around line 1953 and the exchange works as expected [05:21:12 CET] <wm4> jamrial: those are not the same type [05:21:13 CET] <SortaCore> otherwise assert fails [05:21:21 CET] <SortaCore> yea, msvc [05:21:36 CET] <SortaCore> although, only gcc has atomic_bool typedef'd to _Bool, the rest have it to intptr_t [05:22:18 CET] <wm4> static inline int atomic_compare_exchange_strong(intptr_t *object, intptr_t *expected, [05:22:18 CET] <wm4> intptr_t desired) [05:22:22 CET] <wm4> oh yeah, this is horseshit [05:22:28 CET] <SortaCore> it's a problem because when you go to open a codec, any codec, the lock fails, so you can't use it [05:22:39 CET] <wm4> it's directly in conflict what stdatomic requires [05:22:44 CET] <jamrial> all the wrappers except the one for old gcc are kinda hacky, yeah [05:22:55 CET] <wm4> in particular this " intptr_t *expected" [05:23:10 CET] <wm4> this just can't work, it's simply the wrong pointer type [05:23:28 CET] <wm4> SortaCore: so congratulations, you found a design bug [05:23:37 CET] <SortaCore> yay, what do I win [05:23:38 CET] <jamrial> nah, it's been found before [05:23:46 CET] <jamrial> there's a patch in the ml for the msvc case [05:23:52 CET] <jamrial> doing what he suggested [05:23:54 CET] <SortaCore> @.@ [05:24:14 CET] <SortaCore> when was the patch posted? [05:24:14 CET] <wm4> since the actual pointer is never passed to some other functions and just dereferenced in the inline fn, it could be made a macro [05:24:15 CET] <jamrial> it's still, well, hacky [05:24:32 CET] <SortaCore> this only turned up since atom's commits like max two weeks ago [05:24:52 CET] <wm4> in mpv we also have a stdatomic emulation, but it requires a gnu extension now [05:25:12 CET] <wm4> what was the patch to fix this? [05:25:50 CET] <jamrial> "fix MSVC compilation errors" by Mateusz [05:26:07 CET] <SortaCore> there wasn't a compilation error, though [05:26:15 CET] <SortaCore> it was just at runtime the problem turned up [05:27:07 CET] <SortaCore> [01:13] <@atomnuker> SortaCore: I don't know what weird system you're compiling on but the logic's solid [05:27:21 CET] <SortaCore> <.< [05:27:25 CET] <jamrial> it is [05:27:32 CET] <jamrial> the wrapper just isn't correct [05:27:40 CET] <SortaCore> solid as pumice rock [05:28:18 CET] <jamrial> nope [05:28:18 CET] <wm4> av_assert0(atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 0)); [05:28:23 CET] <wm4> man what the fuck is this [05:28:46 CET] <wm4> is this the thing that breaks it? [05:29:11 CET] <jamrial> nevcairiel argues it could maybe not even use atomics at all [05:29:29 CET] <wm4> the proposed fix (is there even a patch or is it just informally copied into the mail) is wrong too [05:29:40 CET] <SortaCore> yes, the exp above is wrong type [05:29:41 CET] <wm4> the stdatomic function expects bool*, not _Atomic bool* [05:29:59 CET] <wm4> and the emulation wrapper expects intptr_t*, which is also wrong [05:30:18 CET] <SortaCore> although msvc seems happy to use _Bool as a variable type, intptr_t is what I'm guessing it's using instead [05:30:27 CET] <wm4> so the existing code is correct (just ridiculously absurd and dumb, wtf is with that assert), and the emulation wrapper is wrong [05:30:36 CET] <jamrial> wm4: that code was added in 590136e78d [05:30:43 CET] <wm4> I suggest turning the emulation atomic_compare_exchange_strong into a macro [05:30:47 CET] <SortaCore> also, above that where ff_avcodec_locked is declared, it's not intiialised [05:30:59 CET] <SortaCore> not sure if that's important [05:31:55 CET] <jamrial> the wrapper for old gcc uses a macro and __typeof__ magic, but i suppose that can't be done for msvc [05:33:18 CET] <wm4> that's probably challenging [05:33:28 CET] <SortaCore> wm4: doesn't that break the "put stack variables first" rule [05:34:06 CET] <wm4> the new code is the only thing that uses these functions [05:40:39 CET] <SortaCore> I'm gonna get to bed, y'all have a good one [05:42:50 CET] <cone-915> ffmpeg 03Rostislav Pehlivanov 07master:c67c7191b1c2: fate-opus: run and test inactive samples [05:42:50 CET] <cone-915> ffmpeg 03Rostislav Pehlivanov 07master:4678339e745d: opus: fix hybrid folding indexing during band quantization [08:15:08 CET] <liyou> i want to link static-ffmpeg into so file, how can i do it? [08:23:59 CET] <atomnuker> daddesio: any progress on replacing the silk lpc? [10:35:49 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:561e276899bb: ffserver: Fix off by 1 error in path [10:35:50 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:7ff156b11285: tests/ffserver.regression.ref: update checksums to what ffserver currently produces [10:35:51 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:1c931d5ab99a: avcodec/jpeglsdec: Check ilv for being a supported value [10:35:52 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:7a23220bf947: avcodec/jpeglsdec: Check for end of bitstream in ls_decode_line() [10:35:53 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:b3bdb0ddc15b: avcodec/aacdec_fixed: Fix integer overflow in predict() [10:35:54 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:dccead84c658: avcodec/aacdec_fixed: Fix integer overflow in apply_dependent_coupling_fixed() [10:35:55 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:6be60aedcb76: avcodec/xan: Improve overlapping check [10:35:56 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:66e65e0a686a: avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add() [10:35:57 CET] <cone-365> ffmpeg 03Luca Barbato 07release/3.4:78b8aeee585b: avformat: Free the internal codec context at the end [10:35:58 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:0ee2cb866c02: avcodec/exr: fix undefined shift in pxr24_uncompress() [10:35:59 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3ca4f1868d66: avcodec/xan: Check for bitstream end in xan_huffman_decode() [10:36:00 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:56ce961cc3dd: avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add() [10:36:01 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3f2be02b4d77: avutil/softfloat: Add FLOAT_MIN [10:36:02 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:8ec1ff14fe88: avcodec/aacsbr_fixed: Fix division by zero in sbr_gain_calc() [10:36:03 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:87f39642f329: avcodec/sbrdsp_fixed: Fix integer overflow in shift in sbr_hf_g_filt_c() [10:36:04 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:ed87b8b61fcd: avcodec/cngdec: Fix integer clipping [10:36:05 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3a143bfa19a3: avcodec/snowdec: Fix integer overflow in header parsing [10:36:06 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:168ee582559d: avcodec/mdct_*: Fix integer overflow in addition in RESCALE() [10:36:07 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:db82e4f1e059: avcodec/aacdec_fixed: Fix undefined shift [10:36:08 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:44fb1201123e: avcodec/aacpsdsp_template: Fix integer overflows in ps_decorrelate_c() [10:36:09 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:6ccf19198b36: avcodec/x86/mpegvideodsp: Fix signedness bug in need_emu [10:36:10 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:d25736dc871b: avcodec/h264dec: Fix potential array overread [10:36:11 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:7b16eacf81dc: avcodec/vc2enc: Clear coef_buf on allocation [10:36:12 CET] <cone-365> ffmpeg 03Fredrik Hubinette 07release/3.4:53715eb13ee1: avformat/mov: Check size of STSC allocation [10:36:13 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:77cfc820cfb5: avcodec/snowdec: Check intra block dc differences. [10:36:14 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:23d5f15b42fd: avcodec/snowdec: Check for remaining bitstream in decode_blocks() [10:36:15 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:ecf2755a41b4: avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb() [10:36:16 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:0ba93614cf22: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD137iL0() [10:36:17 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:cc9d1bb83922: avcodec/zmbv: Check that the buffer is large enough for mvec [10:36:18 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:4942de6f9385: avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output() [10:36:19 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:2e58db3db00b: avcodec/hevcdsp_template: Fix invalid shift in put_hevc_epel_bi_w_v() [10:36:20 CET] <cone-365> ffmpeg 03Jacob Trimble 07release/3.4:8aabc4fdb56c: avformat/mov: Propagate errors in mov_switch_root. [10:36:21 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:9a00ce0ff864: Fix leak of frame_duration_buffer in mov_fix_index(). [10:36:22 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:50c93ce5ef71: Use ff_thread_once for fixed, float table init. [10:36:23 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:f8fcb6bbf0e6: Fix undefined shift on assumed 8-bit input. [10:36:24 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:35c7a1df8ae5: Close ogg stream upon error when using AV_EF_EXPLODE. [10:36:25 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:154989003586: avcodec/mpeg4videodec: Check also for negative versions in the validity check [10:36:26 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:de20dad15e42: avcodec/sbrdsp_fixed: Fix integer overflow [10:36:27 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:f2f0273588ed: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi* [10:36:28 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3ae71b648ad0: avformat/aacdec: Fix leak in adts_aac_read_packet() [10:36:29 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:e56f691283f0: avcodec/kgv1dec: Check that there is enough input for maximum RLE compression [10:36:30 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:983d119c9b73: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct8_add [10:36:31 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:ed87667bd3d4: avcodec/mlpdsp: Fix signed integer overflow, 2nd try [10:36:32 CET] <cone-365> ffmpeg 03John Stebbins 07release/3.4:f7357facd833: lavf/mov: fix huge alloc in mov_read_ctts [10:36:33 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:0ccbbf034dc0: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_epel_bi_w_h() [10:36:34 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:17f05ff656ff: avcodec/j2kenc: Fix out of array access in encode_cblk() [10:36:35 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:36db62ca984b: avformat/utils: Prevent undefined shift with wrap_bits > 64. [10:36:36 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:23319f77645d: avcodec/vorbis: 1 << 31 > int32_t::max(), so use 1u << 31 instead. [10:36:37 CET] <cone-365> ffmpeg 03Dale Curtis 07release/3.4:c147aefc3ecd: avcodec/vorbis: Fix another 1 << 31 > int32_t::max() with 1u. [10:36:38 CET] <cone-365> ffmpeg 03Nikolas Bowe 07release/3.4:a749f4864e48: avcodec/extract_extradata_bsf: Fix leak discovered via fuzzing [10:36:39 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:3a6140e4cf89: avcodec/dirac_dwt: Fix integer overflows in COMPOSE_DAUB97* [10:36:40 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:b2169c8bcc43: avcodec/diracdsp: Fix integer overflow in PUT_SIGNED_RECT_CLAMPED() [10:36:41 CET] <cone-365> ffmpeg 03Michael Niedermayer 07release/3.4:c741095eecee: Update for 3.4.1 [10:50:20 CET] <durandal_1707> now mjpeg fate passes after yuvj removal [10:50:37 CET] <durandal_1707> \o/ [10:52:51 CET] <wm4> are these formats really dying? [10:53:00 CET] <wm4> don't forget to deprecate-deprecate them [10:53:20 CET] <wm4> they were deprecated for years, but everyone had to use them, so it can't be justified to remove them immediately [10:53:31 CET] <atomnuker> yeah they can [10:58:01 CET] <durandal_1707> wm4: they are not removed from lavu, just from lavc codebase [10:59:15 CET] <nevcairiel> so how do I know now that mjpegenc wants a fullrange image? Previously it used to tell me this through .pix_fmts [11:00:06 CET] <wm4> even more, mjpegenc failed to init if you didn't give it a J format [11:00:11 CET] <wm4> and now it's the reverse? [11:02:18 CET] <durandal_1707> you set color_range option [11:03:02 CET] <wm4> but you don't know what the encoder wants [11:03:11 CET] <wm4> or is there now an AVCodec.color_ranges[] [11:03:28 CET] <durandal_1707> patch welcome [11:03:45 CET] <nevcairiel> you want to replace yuvj formats, you need to provide replacements for their functionality [11:04:13 CET] <wm4> yes, so it's not "patch welcome" but "patch rejected" [11:04:44 CET] <wm4> to be fair last time we tried to do this, it failed because of libavfilter [11:07:32 CET] <durandal_1707> wm4: i fixed lavfi and ffmpeg, look at the patch and review it, dont be lazy [11:10:34 CET] <wm4> that's only for vf_scale [11:12:41 CET] <durandal_1707> no, its not [11:17:58 CET] <wm4> weren't there filters which require full or half range [11:18:01 CET] <wm4> ubitux should know [11:23:29 CET] <ubitux> wm4: we don't have a filter that convert from one to another? :p [11:24:30 CET] <ubitux> vf_kerndeint.c: // y <- 235, u <- 128, y <- 235, v <- 128 [11:24:35 CET] <ubitux> vf_lut.c: max[Y] = 235 * (1 << (desc->comp[0].depth - 8)); [11:24:41 CET] <ubitux> vf_pseudocolor.c: s->var_values[VAR_YMAX] = 235 * (1 << (depth - 8)); [11:24:51 CET] <ubitux> a few matches for "235" [11:25:01 CET] <ubitux> probably related one way or another to mpeg range [11:32:06 CET] <durandal_1707> ubitux: scale and zscale [11:32:46 CET] <durandal_1707> lut works with both [11:32:54 CET] <ubitux> so they have to query these specific formats in inlink and outlink i guess [11:33:20 CET] <durandal_1707> and checking color range in inlink is easy [11:33:58 CET] <durandal_1707> i just concentrated on lavc side of things [12:15:04 CET] <durandal_1707> added color range to mjpeg encoders [12:25:33 CET] <wm4> probably could argue that you should keep yuvj support in the encoder for now (and print a warning if it's used) [12:33:30 CET] <cone-365> ffmpeg 03Paul B Mahol 07master:299a62229766: avfilter/vf_waveform: add default case when picking input formats [12:34:53 CET] <durandal_1707> wm4: no [12:50:57 CET] <atomnuker> this is going to be a huge bump anyway [12:51:28 CET] <atomnuker> with ffserver being dropped, loads of deprecated stuff being removed, new hwaccel code to handle things for you... [12:51:40 CET] <nevcairiel> thats no excuse to break all the things w hen it would be trivial to keep it working [12:52:41 CET] <atomnuker> that's pretty much the point of a bump [12:52:48 CET] <atomnuker> and the removal of deprecated things [16:10:03 CET] <cone-365> ffmpeg 03Paul B Mahol 07master:a41a5db79766: avformat: add NSP demuxer [16:12:12 CET] <cone-365> ffmpeg 03Vittorio Giovara 07master:bc38c8f44249: vf_zscale: Fix alpha destination graph for floating point pixel formats [16:47:46 CET] <daddesio> atomnuker: i'm not going to replace the LTP synthesis or LPC synthesis for loops, since they both clamp y[] to +/- 1.0f. since they're IIR filters, I'm hesitant to just remove that clamping. [16:49:01 CET] <daddesio> erm, actually only the LPC filter does the clamping. [16:49:30 CET] <daddesio> but there is no "LTP synthesis" function in libavcodec/libavutil. remember, LTP is technically a huge-ass filter with hundreds of zero coeffs in the middle of a[]. [16:55:57 CET] <daddesio> actually, it looks like libopus doesn't do that clamping. https://github.com/xiph/opus/blob/master/silk/PLC.c#L342 [17:05:41 CET] <daddesio> wait, that's the packet-loss concealment code [17:23:11 CET] <daddesio> the actual LPC code is here. and again, it does not do clamping: https://github.com/xiph/opus/blob/master/silk/decode_core.c#L198 [17:26:56 CET] <atomnuker> so it can replace the non-clamping lpcs? [17:28:29 CET] <daddesio> it seems SILK does LPC with fixed-point arithmetic with no clamping, while FFmpeg does LPC with floating-point arithmetic with clamping to +/- 1.0. [17:30:07 CET] <daddesio> SILK does it with Q14 integers (2 integer bits, 14 fractional bits) which means it works with numbers in the range [-2.0, 2.0). [17:30:47 CET] <daddesio> I don't see any saturating macros in SILK's code [17:32:06 CET] <daddesio> Aha [17:32:47 CET] <daddesio> RFC6716 says this: [17:32:50 CET] <daddesio> "Then, the signal is clamped into the final nominal range: out[i] = clamp(-1.0, lpc[i], 1.0) [17:32:52 CET] <daddesio> This clamping occurs entirely after the LPC synthesis filter has run. The decoder saves the unclamped values, lpc[i], to feed into the LPC filter for the next subframe, but saves the clamped values, out[i], for rewhitening in voiced frames." [17:33:43 CET] <daddesio> so we should be able to get rid of the clamp()s. the question is, do we want to convert it to fixed-point like SILK? [17:36:33 CET] <durandal_1707> michaelni: does in your system hflip pixfmt test passes? [17:37:56 CET] <michaelni> durandal_1707, all tests pass except the newly added [17:47:54 CET] <daddesio> ... again, I'm an idiot. FFmpeg only clips the output (lpc[j] = sum; dst[j] = av_clipf(sum, -1.0f, 1.0f);. [17:49:08 CET] <daddesio> So FFmpeg is doing the right thing. But now, that means we can replace the for loop with ff_celp_lp_synthesis_filterf which might be faster (since it's unrolled), but we'll still have to clamp the output afterwards. [17:52:43 CET] <daddesio> erm, no, we can't use ff_celp_lp_synthesis_filterf because that uses the Direct-Form coefficients a[i] = -lpc[i] (so the for loop uses a subtraction instead of an addition). we have to use ff_celp_lp_zero_synthesis_filterf--which has not been unrolled, as of yet. [18:03:53 CET] <daddesio> meh. I say the existing code is fine. [18:05:39 CET] <daddesio> to use ff_celp_lp_zero_synthesis_filterf, you'll have to create a tmp1[] array with the excitation signal premultiplied by sf[i].gain and a tmp2[] array to hold the output. then call the LPC filtering function. then copy it over to out[] (with clamping). [18:09:44 CET] <cone-365> ffmpeg 03Jacob Trimble 07master:2fdc9f7c4939: avcodec/nvdec: Fix capability check with old drivers. [18:25:25 CET] <durandal_1707> if yuvj changes are ok i will split patches in smaller chunks [18:37:45 CET] <durandal_1707> we should move on, or dont ever mention yuvj shit to me again [18:55:19 CET] <jamrial> if it works then sure [20:03:22 CET] <cone-365> ffmpeg 03sfan5 07master:a428f2fcd959: libavcodec/hevc_filter: move AVDISCARD_NONREF switch-case into function [20:03:23 CET] <cone-365> ffmpeg 03Mark Reid 07master:ad2641c36bf6: avformat/mxfenc: use track count to generate component instance uuid [20:03:24 CET] <cone-365> ffmpeg 03Mark Reid 07master:901d87aa83aa: avformat/mxfenc: write reel_name if metadata key is present [20:03:25 CET] <cone-365> ffmpeg 03Mark Reid 07master:0091a54f6487: fate/mxf: add reel name test [20:03:26 CET] <cone-365> ffmpeg 03Michael Niedermayer 07master:b404d41b1962: fate: Fix fate-mov-bbi-elst-starts-b on ARM [20:39:01 CET] <cone-365> ffmpeg 03Paul B Mahol 07master:713f9c5b5d64: avfilter/vf_scale: add more aliases for "range" options [21:24:59 CET] <durandal_170> what about gl filter wrapper that can apply custom shaders? [21:34:16 CET] <durandal_170> michaelni: thank you for your comments, they are very helpfull [21:42:33 CET] <Compn> gl filter wrapper eh [21:42:38 CET] <durandal_170> obviously i tested only mjpeg so it can pass fate [21:42:38 CET] <Compn> sounds complicated :) [21:43:10 CET] <durandal_170> Compn: kill mplayer project when? [21:43:44 CET] <JEEB> well, you at got to something passing o/ [21:44:22 CET] <Compn> durandal_170 : ehhhh still works for me playing the files i have :p [21:45:16 CET] <durandal_170> we must change ffmpeg in way that breaks mplayer in so many ways that devs give up developing it [21:46:17 CET] <Compn> durandal_170 : quite a few ffmpeg and even vlc devs use mplayer :P [21:47:51 CET] <durandal_170> its like mencoder, ignorant people use it [21:54:06 CET] <Compn> ignorant youtube :) [21:54:29 CET] <Compn> youtube keeping us afloat [21:59:58 CET] <durandal_170> michaelni: perhaps nasm misinterprets asm somehow? [22:00:36 CET] <gnafu> YouTube uses mencoder? [22:04:08 CET] <durandal_170> it is secret [22:04:14 CET] <Compn> for binary codec support gnafu [22:04:28 CET] <jamrial> durandal_170, michaelni: https://pastebin.com/SK5NPxxv [22:04:29 CET] <Compn> durandal_170 : so , your misson, get binary codec support in ffmpeg [22:04:34 CET] <Compn> durandal_170 : that will kill mencoder finally [22:04:50 CET] <Compn> durandal_170 : binary codec support , as long as you dont use mplayer code, will be accepted to ffmpeg :) [22:05:01 CET] <durandal_170> Compn: never, fix your brain already [22:05:11 CET] <jamrial> nasm 2.13 vs 2.10 [22:05:25 CET] <jamrial> no idea if that makes any difference [22:05:34 CET] <Compn> durandal_170 : i'm serious though, binary codec support (only a few wine files in total) will kill mplayer 100% [22:07:41 CET] <durandal_170> Compn: vfw must be abandoned, same for dshow, qt and similar incarnations [22:09:48 CET] <gnafu> Compn: Oh, right. I remember seeing that mentioned before (probably in here). It's a shame there's any need for that at this point. [22:09:56 CET] <Compn> durandal_170 : sure, when you RE every codec... [22:10:00 CET] <Compn> bit exact too [22:11:30 CET] <durandal_170> Compn: relevant ones are already reversed, remainder are already dead or not supported by mplayer conf [22:16:24 CET] <durandal_170> and emulator code is far from stable or perfect [22:23:33 CET] <thardin> use there a way to make the paletteuse filter use the literal palette in a file? [22:25:49 CET] <durandal_170> thardin: what format of palette in file? [22:26:10 CET] <thardin> I have two options actually: either grab the palette in an 8-bit BMP or use a JASC palette [22:26:38 CET] <thardin> maybe I can trick gimp into generating a png with indexes 0..255 and apply the JASC palette to it.. [22:26:45 CET] <Compn> thardin : probably not since we would have to map each palette format and how to convert it ... [22:26:56 CET] <durandal_170> thardin: and BMP is 16x16? [22:27:10 CET] <thardin> no the bmp is any size. 40x96 in this case [22:27:12 CET] <Compn> thardin : what are you trying to do ? [22:27:28 CET] <thardin> I want a bunch of pngs to use the exact same paalette as a bmp file I have [22:27:30 CET] <thardin> same indexes [22:27:39 CET] <thardin> and also convert them to bmp of course [22:27:57 CET] <Compn> i mean, why not use image magick to do the heavy lifting then just use ffmpeg later on ? [22:28:22 CET] <thardin> that is also an option [22:29:15 CET] <Compn> i'm not telling you how to do it, just saying i've seen people struggle for hours trying to get some weird setup working when you could just add another scriptable step and be done with it quickly [22:30:01 CET] <thardin> in the worst case I'll do it by hand in gimp. but that can't be scripted [22:30:32 CET] <thardin> or maybe you can? hmm [22:30:50 CET] <durandal_170> thardin: i still do not understand what you need? [22:31:15 CET] <Compn> i mean, why would you want to reuse a palette ? why are you dealing with palettes at all ? [22:31:16 CET] <thardin> I want to convert a series of images to bmp, using a given palette [22:31:24 CET] <thardin> the palette is fixed [22:31:31 CET] <thardin> to a specific 8-bit platform [22:31:40 CET] <Compn> palettes are for old image things that no one uses anymore [22:31:46 CET] <Compn> :P [22:31:54 CET] <thardin> exactly! :] [22:32:11 CET] <durandal_170> and palette is custom image with different layouts? [22:32:50 CET] <Compn> https://en.wikipedia.org/wiki/Palette_(computing) [22:32:51 CET] <thardin> no I just have the palette in two formats. both as the colormap in a bmp and as a jasc palette [22:33:12 CET] <Compn> durandal_170 : custom color palette, e.g. this image will only use these colors [22:33:14 CET] <Compn> i think ? [22:33:23 CET] <durandal_170> thardin: how that colormap looks like? [22:33:57 CET] <durandal_170> Compn: dont think. act. [22:34:03 CET] Action: Compn runs [22:34:09 CET] <thardin> lol [22:34:45 CET] <thardin> I'm converting graphics for atari 2600 [22:34:55 CET] <thardin> and want a little pipeline for it [22:35:42 CET] <durandal_170> send link to bmp colormap [22:36:51 CET] <thardin> http://härdin.se/40x96-boring.bmp [22:38:13 CET] <durandal_170> is that some kind of lut? [22:38:32 CET] <thardin> no, just the palette is in the palette [22:38:53 CET] <thardin> the damn palette chunk in the bmp [22:39:07 CET] <thardin> the pixels are irrelevant [22:39:08 CET] <durandal_170> really strange format/layout [22:39:39 CET] <thardin> let's see if convert -remap does what I want. I suspect not [22:39:57 CET] <durandal_170> i guess you are left to code it by hand [22:40:40 CET] <thardin> possibly [22:40:44 CET] <durandal_170> thardin: so you saying that bmp is actually pal8 format? [22:40:56 CET] <thardin> yes [22:41:19 CET] <durandal_170> thardin: tried showpalette? [22:41:39 CET] <durandal_170> does our bmp decoder supports pal8? [22:42:16 CET] <thardin> zomg [22:42:26 CET] <thardin> except it's the wrong size [22:42:47 CET] <durandal_170> you can change that i think... [22:43:12 CET] <thardin> nearest neighbour in gimp [22:43:34 CET] <thardin> interesting that it doesn't use pal8 for showpalette output [22:44:32 CET] <durandal_170> i mean showpalette filter supports 1x1 size for each item [22:45:06 CET] <thardin> this works well enough. thanks! :] [22:45:39 CET] <Compn> durandal_170 says vfw is outdated and then helps thardin with atari 2600 stuffs... ok [22:45:43 CET] Action: Compn runs faster [22:47:09 CET] <durandal_170> video for winblows = vfw [22:47:42 CET] <durandal_170> *d [22:50:12 CET] <thardin> of course it tosses the indexes around [22:50:41 CET] <thardin> sorts them it seems. wonderful [22:55:42 CET] <wbs> jamrial: JEEB: about the .ltorg patch for arm asm; if you diff the hevc_idct*.S between libav and ffmpeg, the only diffrence is one function at the start of the ffmpeg file; if you move that to the end of the file instead of having it at the start, the current .ltorg should line up fine, so that might result in less maintainance [22:56:51 CET] <jamrial> wbs: ok, let me check [22:57:30 CET] <wbs> JEEB: also, that issue shouldn't relate to aarch64 whatsoever; if there's an issue with aarch64 builds, it's something else [22:58:15 CET] <BBB> durandal_170: THANK YOU!!!!!!!!! [22:58:23 CET] <BBB> durandal_170: (for yuvj* removal) [22:58:28 CET] <BBB> you are amazing [22:58:34 CET] <JEEB> :) [22:58:55 CET] <wbs> jamrial: that _might_ require a .ltorg before the added function though, but that should be more maintainable at least, to have the common code end up aligned in the same way [22:59:15 CET] <durandal_170> BBB: now pay me $$$$ or give me your vp9 encoder [22:59:21 CET] <BBB> lol [22:59:24 CET] <BBB> ehm... [22:59:27 CET] <BBB> hm... [22:59:33 CET] <BBB> what country are you in again? [23:00:10 CET] <durandal_170> im just kidding [23:01:00 CET] <BBB> Im not [23:01:03 CET] <BBB> what country are you in? [23:01:23 CET] <durandal_170> and yuvj removal only started, need to check more things [23:04:08 CET] <BBB> youre not answering my genuine question ;( [23:04:17 CET] <jamrial> wbs: like this? https://pastebin.com/YE8vGCg9 [23:04:30 CET] <jamrial> includes the extra .ltorg [23:05:01 CET] <jamrial> can't test so i'm doing this blindly :p [23:05:49 CET] <wbs> jamrial: yep, that one should be the least extra maintainance going forward, and should fix the issue [00:00:00 CET] --- Sat Dec 9 2017

1 0

ffmpeg.log.20171208
by burek 09 Dec '17

09 Dec '17

[00:39:31 CET] <vicky> Video conversion_status failed due to libx264 or any codes that is installed by your application. Please read this link for more details: https://docs.clipbucket.com/how-to-fix-video-conversion-problem [00:40:00 CET] <vicky> how to fix this issue? [00:40:50 CET] <vicky> ====== [00:40:52 CET] <vicky> File : /home/ppxyz/public_html/clip/files/thumbs/2017/12/07/1512668598dc0ae-768x432-1.jpg ====== End : Thumbs Generation ======= Conversion Completed -------------------- Time Took : 1.4912 seconds conversion_status : failed [00:40:54 CET] <vicky> ===== [00:41:04 CET] <vicky> this is a conversion error [00:41:12 CET] <vicky> Can anyone help on this issue? [00:47:43 CET] <vicky> Can anyone check my query? [00:56:53 CET] <SortaCore> vicky: IRC is not a fast thing [00:57:08 CET] <SortaCore> you should expect up to a few hours [00:57:26 CET] <vicky> @sortacore - okay, will wait [00:57:43 CET] <SortaCore> at a guess, do you have perms for it? [00:57:57 CET] <vicky> what perms? [00:58:08 CET] <vicky> Can you please clarify on this? [00:58:12 CET] <SortaCore> looks like linux-style path [00:58:29 CET] <SortaCore> so writing file perms always makes me question folder permissions [00:59:35 CET] <vicky> @sortacore - will check that path on my server [01:09:59 CET] <vicky> @sortacore - Can you please tell me path linux-style? [01:21:16 CET] <SortaCore> you put the path up there [01:21:40 CET] <SortaCore> try running whatever you were doing for video conversion with sudo [01:43:47 CET] <kisahoshi> Hi guys [01:45:17 CET] <kisahoshi> I am trying to run ffmpeg to record desktop + audio but unfortunately its not working sa intended. it wont capture my audio but it records just fien [01:45:33 CET] <kisahoshi> ffmpeg -video_size 1336x768 -framerate 30 -f x11grab -i :0.0 -f alsa -i hw:0 -qscale:a 2 -c:v libx264 -crf 20 -preset veryfast vid.mkv [01:55:27 CET] <kisahoshi> hello [01:56:56 CET] <kisahoshi> hi [01:59:00 CET] Last message repeated 1 time(s). [02:03:06 CET] <kisahoshi> Helloooo [02:03:09 CET] <kisahoshi> Can someone help [04:36:25 CET] <hendry> has anyone made a script to do a animated Youtube style poster of an MP4? [04:38:59 CET] <SortaCore> isn't that just pulling every X frame from a video? [04:39:21 CET] <SortaCore> probably not a script, but you would get the duration, get frame rate, then pick frame by modulus or multiplier [04:39:42 CET] <SortaCore> chuck them into a video output and you're good [05:04:32 CET] <furq> -skip_frame nokey will get you most of the way there [05:04:36 CET] <furq> depending on the codec [05:04:58 CET] <furq> if that's still too many frames then ffprobe -count_frames and then -vf select [05:05:14 CET] <furq> don't expect it to be quick though [08:11:02 CET] <liyou> i want to link static-ffmpeg into so file, how can i do it? [10:40:02 CET] <pihpah_> The question is HLS vs progressive downloading (mp4, h.264). Currently I utilize the latter method, now I am thing of the former. The problem is I already serve tons of videos using progressive downloading. [10:40:17 CET] <pihpah_> I am thinking* [10:41:11 CET] <pihpah_> And for some reason on macOS I can't play those videos, don't know why. [10:41:32 CET] <pihpah_> I already asked about that problem in this channel. [11:06:09 CET] <kerio> "on macOS"? [11:06:13 CET] <kerio> you mean in safari? [11:10:34 CET] <pihpah> kerio: I have the same problem both in Safari and Firefox on macOS. [11:12:39 CET] <pihpah> I've tried HLS streaming, works fine for Safari but now it does not work on Linux in Firefox and Chromium, jeez. [11:13:31 CET] <Nacht> Firefox and Chrome dont have native support for HLS [11:13:35 CET] <Nacht> Only Edge and Safari [11:13:46 CET] <ritsuka> pihpah: wasn't that a issue with your server configuration? [11:14:09 CET] <ritsuka> or something like that [11:14:45 CET] <kerio> yeah firefox does its own thing [11:14:59 CET] <pihpah> ritsuka: does not think so. All I know HLS works on Android and Safari, but does not work on Chromium and Firefox [11:15:00 CET] <kerio> video playback shouldn't differ between different OSes [11:15:25 CET] <ritsuka> pihpah: I mean the issue with progressive download [11:16:19 CET] <Nacht> If you use a HTML5 player, such as JWPlayer or some sorts, you can play HLS perfectly on Firefox and Chrome [11:16:25 CET] <pihpah> ah, no, that does not relate to this problem. I run all tests locally. [11:16:50 CET] <pihpah> Nacht: I test using html5 video tag [11:17:25 CET] <pihpah> Ok, I'll try using JWPlayer [11:26:49 CET] <Nacht> pihpah: the HTML5 video tag alone isn't enough [11:27:00 CET] <Nacht> That's only for MP4, WebM and OGG [11:27:29 CET] <Nacht> You need an actual player, like TheoPlayer, JWPlayer or Meisterplayer [11:46:53 CET] <JEEB> or just a basic thing on top of hls.js or dash.js. they generally provide you enough for a PoC [12:40:50 CET] <th3_v0ice> Hello, I would like to call the FFmpeg from my application but not trough system calls like I am doing now, I would like to do it with the function call. The easies way is to rename the int main() of ffmpeg.c and call that method with already constructed arguments. The problem is that after including required headers, putting requred files where they belong I cant compile the project. For example I am getting libavutil/x86/asm.h No such file or [12:40:50 CET] <th3_v0ice> directory, but the file is there. I am guessing that gcc is not invoked with proper arguments from the Eclipse. Thanks for the help! [12:51:18 CET] <BtbN> th3_v0ice, that's not supported. Either use the API, or run the program. [12:55:25 CET] <th3_v0ice> Ok, thanks! Will use the API. [13:07:43 CET] <tommy``> there is a windows build with installer? [13:09:08 CET] <tommy``> i would like to add PATH on windows [13:09:45 CET] <pihpah> Okay, nice. Looks like the pain in my ass for about half year was just one byte I have been failing to read: https://pastebin.com/wksvKN2k [13:09:53 CET] <pihpah> Darn it [15:18:21 CET] <kerio> Nacht: but <video> is enough for safari :3 [15:22:01 CET] <Nacht> kerio: For HLS you mean ? [15:22:13 CET] <JEEB> and edge [15:22:28 CET] <JEEB> (edge actually supports both DASH mpd and HLS m3u8 in <video>) [15:22:31 CET] <JEEB> but it's the exception [15:22:37 CET] <JEEB> everything else wants you to parse everything in JS <3 [15:23:17 CET] <Nacht> As JEEB says, you want to use JS. As Safari and Edge aren't really the most used browsers :) [15:45:32 CET] <Intektor> I am trying to do a really low latency p2p network stream, but I cant seem to get the right variables, I still have a latency of around 1 second, any tips? [15:46:17 CET] <Intektor> this is my current command: https://i.imgur.com/Laxk5WH.png [16:02:21 CET] <InTheWings> wth does an ffmpeg remuxed AAC with its 2 bytes of extra, ends with 24 extradata bytes (22 more in front) in AVI ? [16:02:52 CET] <InTheWings> and that's not an adts header [16:06:27 CET] <InTheWings> WAVE_FORMAT_EXTENSIBLE ok [16:07:37 CET] <kepstin> Intektor: hard to say where the latency is being added - it might actually be in the pipe connecting the process generating the images to ffmpeg, rather than something ffmpeg is doing. [16:07:50 CET] <alexpigment> does using CRF add latency? [16:08:02 CET] <kepstin> no [16:08:18 CET] <alexpigment> gotcha. i didn't know if certain rate control methods were slower than others [16:08:20 CET] <Intektor> kepstin, thats sounds interesting, I will take a look at that [16:08:55 CET] <kepstin> (well, crf mode might be a bit slower than other rate control methods, but it doesn't cause any additional frame buffering) [16:09:06 CET] <alexpigment> is rc lookahead even used at all for CRF? [16:09:20 CET] <kepstin> it depends on other settings [16:09:32 CET] <kepstin> in this case, the -tune zerolatency disables all lookahead [16:09:44 CET] <alexpigment> ah, good to know [16:10:12 CET] <kepstin> in normal usage with slower presets, rc lookahead will be used with crf mode. [16:10:31 CET] <kepstin> i think? need to confirm that. [16:11:05 CET] <kepstin> it certainly does some lookahead and/or frame buffering, but it might not be due to the rc code. hmm. [17:19:27 CET] <tmatth> kepstin: is CRF ok for live/real-time use (I've been it in conjunction with veryfast and zerolatency) [17:20:49 CET] <kepstin> it doesn't give you any direct control over the stream bitrate, so it might not be useful for network streaming to people with limited bandwidth. [17:21:30 CET] <kepstin> (you can use crf in combination with vbv controls, tho) [17:41:10 CET] <tomtomb> hey, another question, can ffmpeg create AAF files, somehow? [17:51:59 CET] <tmatth> kepstin: yeah that's what i've been doing [18:01:43 CET] <kepstin> huh, aaf files are weird. use the storage mechanism from old ms documents, which is basically a fat filesystem in a file? [18:02:33 CET] <kepstin> looks like there was an open-source implementation way back when. If you really need it, might be best to encode media with ffmpeg then find some external tool to put everything in the aaf file. [18:33:16 CET] <delsol> if I'm encoding with x11grab, ffmpeg -framerate 15 -video_size 1024x768 -f x11grab -i :0 -vcodec libx264 -crf 30 -preset ultrafast /video/2017-11-30/TEST_VIDEO.mkv are there any easy format changes that could reduce CPU load without making filesize skyrocket? Bit depth? [18:36:16 CET] <alexpigment> delsol: do you have the option to use hardware encoding? [18:36:40 CET] <delsol> I can't get it to work. intel embedded GPU [18:36:49 CET] <alexpigment> vaapi should support that i thought [18:36:57 CET] <delsol> Yeah, i can't get it to work. [18:37:11 CET] <delsol> in some cases doing 3-4-5-10 encodes at once from different screens :0, :1, :2, etc [18:37:21 CET] <alexpigment> k [18:37:24 CET] <delsol> not sure it'll work there either, or if it'll even help [18:37:36 CET] <alexpigment> what's your current problem with CPU load? [18:38:58 CET] <delsol> when multiple encodes going, non-encoding tasks slow down. Additional memory bandwidth with same task (by inserting second stick of ram to get dual channel) made recordings better, less dropped frames, but slowed actual workload task from 6 seconds to 10 seconds [18:39:17 CET] <alexpigment> also another member here mentioned using -tune zerolatency to solve a latency issue, but he mentioned that it tuns off rc_lookahead (and presumably the lookahead threads). might be worth trying that [18:41:11 CET] <alexpigment> delsol: well, at a certain point you have to accept that CPU encoding x264 is not a trivial task, so maybe it's worth considering another format [18:42:01 CET] <alexpigment> or, perhaps a better CPU [18:42:23 CET] <alexpigment> lastly, make sure you're writing to an SSD or at least a non-OS HDD [18:42:36 CET] <alexpigment> and not in a virtual machine if that's a factor [18:42:36 CET] <delsol> yeah, writing to a non-OS drive. [18:43:30 CET] <alexpigment> and my 2 cents on this: i would not personally want to work on a computer that is live capturing my screen doing x264 encoding [18:44:16 CET] <alexpigment> it's pretty much always going to affect performance, unless you have a monster CPU [18:45:08 CET] <delsol> not a VM. current CPU is G3258 @ 3.2ghz most are similar. Have over 50 locations. Most would only be doing 1-2 encodes though. [18:45:20 CET] <alexpigment> that's dual core, right? [18:45:22 CET] <delsol> yeah [18:45:34 CET] <delsol> dual core haswell, no hyperthreading. [18:45:50 CET] <alexpigment> multiple encodes on a dual core haswell just doesn't seem like a good idea imho [18:46:04 CET] <delsol> its what I've got. [18:46:07 CET] <alexpigment> you'd ideally want something like ryze [18:46:10 CET] <alexpigment> *ryzen [18:46:41 CET] <alexpigment> understandable. my 2 cents (others may disagree), you've got the wrong tool for the job, so you need to make some sacrifices somewhere [18:47:52 CET] <delsol> well, I can't just go spend a new car on hardware. Thats why I'm looking for ways to reduce load in an acceptable manner. [18:50:43 CET] <delsol> figured maybe color bit depth would be an easy gimme or something [18:50:51 CET] <delsol> or maybe theres no more to give there... [18:51:34 CET] <alexpigment> well, try -pix_fmt yuv420p if you haven't tried already [18:59:12 CET] <delsol> 14% without / 10% with but mostly 12% without, 10% with at 15fps, 30 quality [18:59:33 CET] <alexpigment> ok [19:00:10 CET] <alexpigment> from my perspective, that's the best you're going to get [19:01:34 CET] <delsol> thats a good difference if the quality is still usable. [19:04:04 CET] <pszafer> hi, few years ago I converted music cd to mp3. ffmpeg saying for most of files that header is missing. I see similar bug and fix for it 803c058a6f0c835c3094621d03d6e8c02565f28e [19:04:07 CET] <alexpigment> well if you want to have maximum compatibility, you want to be using yuv420p [19:04:43 CET] <pszafer> do you know for which version fix suppose to be released? I'm using 3.4 [19:04:44 CET] <alexpigment> which has half the chroma resolution compared to the luma resolution, but it's sadly still the de facto standard [19:05:01 CET] <delsol> thanks alexpigment :) gets me closer and pushes hardware limits further away. [19:11:31 CET] <notbatman_> Hello. Would like to use ffmpeg to convert RealMedia RV40 video stream to almost anything else. Is RV40 video conversion supported in the current build v3.4? [19:12:11 CET] <alexpigment> yes, there's a decoder for it [19:12:16 CET] <alexpigment> (at least on paper) [19:12:31 CET] <alexpigment> whether you have any problems with it is another story [19:12:38 CET] <alexpigment> i haven't seen a realvideo file in many years [19:13:04 CET] <notbatman_> Yes, these are from 2005-2006 [19:13:24 CET] <alexpigment> right [19:13:41 CET] <alexpigment> well, rv40 decoder support has been in ffmpeg for quite a while [19:14:22 CET] <notbatman_> As I understand it, the conversion selects the highest resolution stream of video and audio and converts that unless specified otherwise. [19:15:05 CET] <alexpigment> are you implying that there are multiple video and audio streams in your video files? [19:15:36 CET] <notbatman_> Yes, there typically are multiples to accommodate different bandwidth users [19:16:03 CET] <alexpigment> gotcha [19:16:33 CET] <alexpigment> if you do a test conversion with just ffmpeg -i [input] output.mp4 , it'll show you all the streams available [19:16:46 CET] <notbatman_> Will do. [19:16:54 CET] <alexpigment> so just make sure the final resolution is the same size as the highest resolution listed [19:17:12 CET] <alexpigment> of course, you'll probably want to specify more parameters than the command above [19:17:50 CET] <notbatman_> Will see if that works first and add more later if that works. [19:20:23 CET] <notbatman_> Ugh. Not good. Conversion failed. [19:37:42 CET] <notbatman_> @alexpigment Tried the basic input-output conversion and it failed. Pasted terminal output to pastebin under notbatmanbgordon. [19:40:19 CET] <SortaCore> just link the pastebin here [19:42:10 CET] <alexpigment> sorry back [19:42:18 CET] <alexpigment> i'm an old technologically-challenged man [19:42:26 CET] <alexpigment> paste the pastebin link here and i'll click on it [19:42:36 CET] <notbatman_> Ah. Sorry. Here's the link: https://pastebin.com/RfCsW2q1 [19:44:18 CET] <alexpigment> there are others here who know a lot more than me about ffmpeg [19:44:36 CET] <alexpigment> but just based on this, i would try specifically mapping one of the other video streams and seeing if that works [19:45:07 CET] <alexpigment> for example, stream 0:2 or 0:6 [19:45:38 CET] <notbatman_> Makes sense. Thanks. [19:46:09 CET] <alexpigment> i mean it's complaining about headers being incorrected and bad packet sizes and invalid data, so another stream might not have those same problems [19:46:25 CET] <alexpigment> *incorrect, rather [19:48:36 CET] <notbatman_> Yeah, let's hope that's it. Will give it a shot in my copious free time. Back when I do. [21:47:22 CET] <delsol> so --scenecut XX is a % of pixel change to determine if a new keyframe is generated? [21:48:27 CET] <delsol> and --keyint YYY gives a number of frames maximum before a new keyframe is generated? [21:51:26 CET] <sfan5> -I, --keyint <integer or "infinite"> Maximum GOP size [250] [21:51:26 CET] <sfan5> --scenecut <integer> How aggressively to insert extra I-frames [40] [21:51:30 CET] <sfan5> from x264 --fullhelp [21:52:42 CET] <sfan5> if you need it more precise you might need to read the code, but those sounds correct to me [22:04:17 CET] <delsol_> looks like things have changed, --scenecut and --keyint don't seem to be supported anymore or I'm doing it wrong. [22:08:37 CET] <BtbN> Those are x264 options [22:08:40 CET] <BtbN> not ffmpeg. [22:08:46 CET] <kepstin> those aren't ffmpeg options; keyint maps to '-g' in ffmpeg, and for scenecut you need to use -x264-params [22:09:06 CET] <kepstin> hmm, or maybe it's -sc_threshold? not sure, actually [22:09:24 CET] <kepstin> the -x264-params way will def. work, tho :) [22:10:06 CET] <kepstin> and I can never remember which of -x264opts or -x264-params is preferred [22:15:56 CET] <delsol_> ahhhh [22:16:29 CET] <furq> params is preferred now [22:19:01 CET] <notbatman_> Has anyone been successful in converting RealMedia RV40 streams to any format using FFmpeg 3.4, or even earlier versions? Just curious. [22:21:36 CET] <JEEB> notbatman_: I'm pretty sure some of my playback test samples are RV [22:21:39 CET] <JEEB> either 30 or 40 [22:22:03 CET] <delsol_> should i care about "Past duration 0.999413 too large" blowing up my command line repeatedly? [22:24:03 CET] <durandal_170> notbatman_: if samples don not decode with ffmpeg, open bug report on trac to link of sample [22:36:02 CET] <kepstin> delsol_: that usually means the framerate of the input file was misdetected. It can mean some frames get dropped. If it's supposed to be constant framerate and you know the correct value, you can throw a -r 24 or whatever on the output to fix it. [22:36:39 CET] <kepstin> or I think you can work around with with some settings of the -vsync option to force it to assume vfr output [22:37:26 CET] <delsol_> ahh. I don't give a rats ass about dropped frames within reason, so long as there isn't massive huge amounts of time-skew over a 20-30-60 minute screengrab [22:37:43 CET] <kepstin> it doesn't affect a/v sync [22:38:08 CET] <delsol_> its just screen capture for security purposes, there is no audio at this time. [22:38:51 CET] <alexpigment> delsol_: the past duration too large will always occur when your output framerate is lower than your input frame rate, from what i recall [22:39:01 CET] <alexpigment> and if you're doing 15fps, it probably means you're intentionally dropping frames [22:43:16 CET] <alexpigment> notbatman_: assuming this is a one-time project and you don't mind using a different tool, realmedia has their own converter: http://www.real.com/features/basic/convert [22:43:41 CET] <alexpigment> that'll at least get you out of realvideo, presumably, if not into the format you want in the end anyway [22:47:34 CET] <notbatman_> alexpigment_: Thanks, I may try that--although I'm sure to run into more RealMedia, so it would be nice eventually to work with FFmpeg in the CLI. [22:48:51 CET] <durandal_170> notbatman_: tried ffmpeg already or? [22:51:15 CET] <delsol_> alex: so in software, i've got selection spots to do 10,15,20 FPS, and quality 20,25,30,35,40 if I remember right. I'm doing 15 fps, quality 30 default. (will have to go lower quality on machines doing many encodes at once) [22:51:57 CET] <delsol_> thinking about nice 5'ing the main encode, :0 and maybe nice 8 or so on :1, :2, :3, etc [22:52:03 CET] <kepstin> delsol_: what input options are you using? [22:52:21 CET] <kepstin> if you're getting that past duration message during the live capture, something's messed up [22:52:43 CET] <delsol_> ffmpeg -framerate 15 -video_size 1024x768 -f x11grab -i :0 -vcodec libx264 -crf 30 -pix_fmt yuv420p -preset ultrafast /video/2017-11-30/TEST_VIDEO.mkv [22:53:46 CET] <kepstin> hmm, strange, that really should be ok. That's the correct way to specify the capture framerate, and it shouldn't ever be capturing frames *faster* than that, especially under load. [22:54:37 CET] <delsol_> after about 10 seconds I've got: frame= 142 fps= 15 q=-1.0 Lsize= 130kB time=00:00:11.40 bitrate= 93.5kbits/s dup=0 drop=29 speed=1.23x [22:54:37 CET] <notbatman_> @durandal_170_: Yes that's why I'm here:) The RealMedia files play fine in RealPlayer. FFmpeg sees the streams and all the metadata but says they're f-ed up--not in those exact words. [22:56:20 CET] <durandal_170> notbatman_: pastebin ffmpeg output [22:56:27 CET] <kepstin> delsol_: can you pastebin the full output up until you get a 'past duration too large' message? [22:56:58 CET] <delsol_> you just want 2-3 seconds of pastebin from start to end? [22:58:05 CET] <kepstin> I want the console output from the ffmpeg command from start to the point where you see that message. [22:58:30 CET] <delsol_> https://pastebin.com/mR6GjENu [22:58:36 CET] <delsol_> thats from start to end for about 4 seconds [22:58:43 CET] <delsol_> with both ends of the console output [23:01:30 CET] <notbatman_> @durandal_170_: pasted at https://pastebin.com/22aLfUrc [23:01:38 CET] <kepstin> alright, so the input is setting the framerate to 15 with 1000k tb, that's correct, the output framerate is 15, and it's converting to timebase of 15, which should be fine. [23:01:57 CET] <kepstin> so the only explanation is that x11grab is actually grabbing frames slightly faster than 15fps, which is really odd [23:02:33 CET] <notbatman_> Gotta catch a train. Continue later. [23:02:39 CET] <kepstin> well, in this case, I'd just ignore the message - the final result will be 15fps, although there might be minor jitter. [23:02:44 CET] <durandal_170> notbatman_: rm demuxer issue, upload sample if you can [23:02:56 CET] <notbatman_> ok [23:05:20 CET] <delsol_> 1000k tb? [23:08:16 CET] <kepstin> the x11grab pts values work by simply setting the frame timestamp to the current realtime (ms accuracy), converted to ffmpeg's internal "AV_TB" (µs, iirc) [23:09:05 CET] <kepstin> so it grabs a frame, sets timestamp to current time, sends it on, then sleeps until it's supposed to grab the next frame & repeat. [23:09:34 CET] <delsol_> ahhhhh [23:10:20 CET] <delsol_> so its grabbing a frame slightly earlier/later than expected, and thus throwing warnings [23:10:59 CET] <kepstin> slightly earlier - or maybe one slightly later and the next on time? [23:11:11 CET] <kepstin> hard to say. [23:11:54 CET] <kepstin> you can either ignore it and maybe have some jitter, or throw a "-r 15" or "-vf fps=25" on the output and hope that cleans up the timestamps (should be minimal overhead) [23:12:20 CET] <kepstin> I typoed that 1525, but I assume you get the idea :) [23:19:34 CET] <delsol_> if the extraneous output on shells that don't really exist isn't going to memory leak horribly, and isn't going to somehow declare world war three on my drive or cause kernel panics, I give zero shit about some random extra output [23:19:59 CET] <delsol_> video starts every login, [23:20:33 CET] <delsol_> on logout, ps ax gets grepped for ffmpeg on the right display :0, :1, etc and gets killed. [23:23:32 CET] <delsol_> video files get named according to YYYYMMDD_HH-MM-SS_<userid>_<loginid>_<machinename> in a directory named after sales date. :) makes it easy to blow away days worth of video when free space is less than a given amount or given %. [23:24:10 CET] <delsol_> while(drive_too_full_%) {delete_oldest_day} [23:24:36 CET] <delsol_> while(drive_not_enough_gb_free) {delete_oldest_day} [00:00:00 CET] --- Sat Dec 9 2017

1 0

ffmpeg-devel.log.20171207
by burek 08 Dec '17

08 Dec '17

[00:30:16 CET] <philipl> jkqxz: So with paul's changes to remove yuvj stuff, does that unblock mjpeg hwaccel? [02:58:18 CET] <atomnuker> durandal_1707: do these remove all yuvj references in the codebase? [02:59:04 CET] <atomnuker> if the end of those is near it would make sense to get that while the abi unstable period is still going [03:00:19 CET] <Chloe> Anyone debugged zlib/deflate in PNG? What tools did you use? (or just make custom ones?) [06:04:01 CET] <wm4> so does the hls demuxer not handle tags like "#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="stereo",LANGUAGE="en",NAME="English",DEFAULT=YES,AUTOSELECT=YES,URI="audio/stereo/en/128kbit.m3u8"" correctly? [06:04:47 CET] <wm4> oh it does, my error [08:02:14 CET] <tmm1> i can't figure out why mpegts created directly vs with hlsenc have different frame rates: https://gist.github.com/tmm1/fcbe42e9da85514fde48238463400552 [09:30:03 CET] <durandal_1707> atomnuker: nope, i first need to make it working for yuvj but cant [09:30:12 CET] <durandal_1707> in mjpeg [10:37:32 CET] Action: rcombs realizes he just sent 2 patches on top of an old version, having forgotten to rebase [10:54:28 CET] <atomnuker> daddesio: can you look into the valgrind issues with the hybrid folding patch? [12:58:48 CET] <tguillem> Hello guys. VLC is still using the old way to configure avcodec hwaccel. We don't want to change it for VLC 3.0 that is freezed but we'll change it for 4.0. In the meantime, hwaccel is not working anymore for us with a up to date master. I did a quick fix to identify the problem: https://gist.github.com/tguillem/038b593bdc47954e386e7d3b83789115 VLC 3.0 is not using [12:58:53 CET] <tguillem> AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX/AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX. Internal method seems to work fine with vdpau/vaapi. Any thought ? [13:04:45 CET] <Compn> hmm there was a lot of discussions about hwaccel lately [13:04:52 CET] <Compn> removing some old interfaces tguillem [13:05:33 CET] <nevcairiel> The hwaccel infrastructure was changed quite a bit recently, I would suggest to stick to the last release if you dont use hwcontext functions yet [13:05:45 CET] <nevcairiel> (also, git master is still in an unstable period right now) [13:07:09 CET] <wm4> tguillem: these methods are just metadata [13:07:19 CET] <wm4> they don't change anything for the API user [13:07:25 CET] <nevcairiel> actually get_format enforces that [13:07:40 CET] <nevcairiel> maybe its a bug that it blocks usage that otherwise works fine [13:07:43 CET] <wm4> yeah... and that's because they replace AVHWaccel [13:07:54 CET] <wm4> or well not really replace, but it's wired up differently [13:08:11 CET] <wm4> what I mean is, vlc doesn't need to care [13:08:14 CET] <wm4> modulo bugs [13:08:23 CET] <nevcairiel> I mean, before those changes I could still use dxva2 or d3d11 without hwcontext, afterwards I cant, for arbitrary reasons, apparently [13:08:45 CET] <wm4> and this bug will break most existing hwaccel users too [13:08:51 CET] <wm4> so it's just a bug [13:09:27 CET] <wm4> nevcairiel: not sure what you're saying, you still should be able to, although the above bug probably broke it [13:09:43 CET] <tguillem> we have the "Invalid setup..." error here: https://gist.github.com/tguillem/72b7225b075f16c341e4515956c8b105 [13:09:45 CET] <nevcairiel> yeah its broken right now is the point [13:09:53 CET] <tguillem> if you do nothing in the else, it works for us [13:09:55 CET] <nevcairiel> everything that used hwaccel_context before wont work right now [13:10:10 CET] <wm4> so what tguillem posted is a bug fix, nothing else [13:10:21 CET] <nevcairiel> because all those hwaccels are only flagged as hwcontext/hwframesctx [13:10:32 CET] <jkqxz> tguillem: Most of those hwaccels do not offer an internal setup method. [13:10:48 CET] <wm4> oh wait it should eb AD_HOC here, right? [13:10:51 CET] <wm4> *be [13:10:54 CET] <nevcairiel> probably adhoc yes [13:10:55 CET] <wm4> instead of INTERNAL [13:10:56 CET] <tguillem> maybe [13:11:16 CET] <jkqxz> They do offer ad-hoc, but I didn't include that where others are available. [13:11:22 CET] <wm4> AD_HOC means you have to do weird hw-API-specific stuff to get it to work [13:11:25 CET] <nevcairiel> please do, though [13:11:28 CET] <jkqxz> Because people using it already know that, and new users shouldn't do that. [13:11:29 CET] <wm4> like setting hwaccel_context [13:11:42 CET] <nevcairiel> well it breaks existing code if its not included in the list [13:11:46 CET] <nevcairiel> because get_format bails out [13:11:57 CET] <tguillem> AD_HOC means deprecated and that's what we do (for 3.0) [13:12:15 CET] <wm4> whether it's considered deprecated is probably contentious [13:12:23 CET] <wm4> for now it's clearly a bug that it doesn't work [13:12:39 CET] <tguillem> an other fix is just to remove the goto try_again in the last ifelse (fix that doesn't touch HW_ACCEL defines) [13:13:29 CET] <wm4> I think adding AD_HOC to d3d/vaapi/vdpau/vt should be fine [13:13:35 CET] <tguillem> but maybe not all HWAPI works with AD_HOC ? We know for sure that vdpau/VAAPI/DXVA2/D3D11 works with ADHOC [13:13:47 CET] <tguillem> Ok I'll send a patch [13:13:52 CET] <wm4> (d3d meaning dxva2 and the "old" d3d11) [13:14:09 CET] <jkqxz> Right, yeah. It should include AD_HOC. [13:14:14 CET] <wm4> and d3d11va2 doesn't support ad-hoc I think [13:14:17 CET] <nevcairiel> the old d3d11 is already defined to be only adhoc right now [13:14:22 CET] <wm4> ah [13:14:30 CET] <wm4> correct [13:14:40 CET] <nevcairiel> and the new one could support adhoc with like a one-line change, but apparently people didnt like that =p [13:14:47 CET] <jkqxz> Yeah, only some want it. NVDEC doesn't support AD_HOC either. [13:15:28 CET] <wm4> personally I'd really like to see the d3d code cleaned up, and the AD_HOC methods seem to make this much harder [13:16:25 CET] <nevcairiel> I liked the old way of keeping control over all the d3d stuff and only giving the necessary interface to avcodec, but apparently everyone else wants avcodec to do everything [13:17:40 CET] <jkqxz> Well, they want it to do everything which can't matter to anything outside lavc :P [13:18:04 CET] <nevcairiel> But what if it does? [13:19:23 CET] <wm4> I'm not sure if I'm overly happy with the new API, but I like that it handles most things automagically [13:19:50 CET] <jkqxz> What does? The frame stuff is deliberately external-allowed (via hw_frames_ctx) because it can be relevant. What are you going to do with the decoder objects? [13:20:08 CET] <nevcairiel> Internally its basically the same anyway, the only difference is who fills the objects, so the complexity from allowing that is minimal [13:20:15 CET] <wm4> I think he has some weird dshow requirements :) [13:20:57 CET] <jdarnley> Does anyone have experience of clang complaining about "error: invalid application of 'sizeof' to an incomplete type"? Specifically use of FF_ARRAY_ELEMS in checkasm. [13:20:59 CET] <wm4> I wouldn't mind allowing decoder creation by API user and such, but please make hwaccel_context die [13:21:14 CET] <nevcairiel> you need some way to pass the decoder etc into it [13:25:36 CET] <jkqxz> wm4: Did you see <https://github.com/intel/media-driver>? It's the Media SDK driver, but now works without hacked kernel. [13:25:44 CET] <JEEB> funky [13:26:43 CET] <nevcairiel> They only have vp9 decode on cannonlake? didnt their earlier cpus have that, or is the driver just weird that way? [13:26:46 CET] <jkqxz> (But the same "only some specific SKUs" restriction. No recent processors at all.) [13:27:07 CET] <jkqxz> It doesn't support anything between Skylake and Cannonlake. [13:32:16 CET] <wm4> jkqxz: no, what is it even? [13:32:24 CET] <wm4> their hybrid driver for vaapi? [13:33:18 CET] <jkqxz> It's a whole separate driver for VAAPI. [13:35:01 CET] <wm4> naturally I'm not interested in it anymore, anyway [13:35:21 CET] <wm4> but what does it have over the normal driver? [13:36:23 CET] <wm4> lol https://raw.githubusercontent.com/intel/media-driver/master/media_driver/ag… [13:36:28 CET] <jkqxz> Possibly-better performance, some different features (that group has been pushing stuff at official libva recently, which is implemented in their driver). [13:36:29 CET] <wm4> I have no idea what it is but still [13:37:00 CET] <jkqxz> Open source! [13:38:59 CET] <jkqxz> And fair enough to not interested. I imagine some people might try to use it with mpv, though I don't think it currently works. [13:40:17 CET] <wm4> hm, why not? shouldn't it just follow the vaapi api? [13:40:21 CET] <wm4> does it work with ffmpeg? [13:40:44 CET] <jkqxz> Not currently. [13:41:26 CET] <jkqxz> I think they only test against their Media SDK stuff, so it has a lot of implementation holes. [13:41:38 CET] <wm4> heh [13:45:29 CET] <rcombs> >CNL: Hardware accelerated encoding is not supported in the first release. [13:45:53 CET] <rcombs> >SKL: Green or other incorrect color will be observed in output frames when using YV12/I420 as input format for csc/scaling/blending/rotation, etc. [13:46:00 CET] <rcombs> > The issue can be addressed with the kernel patch: WaEnableYV12BugFixInHalfSliceChicken7 [13:46:06 CET] <rcombs> ah yes, WaEnableYV12BugFixInHalfSliceChicken7 [13:46:19 CET] <rcombs> complete with a link to a nonexistent commit [13:46:43 CET] <rcombs> I appreciate the open-source effort but& seems like intel's still gonna intel [13:52:04 CET] <wm4> poor chickens [16:45:04 CET] <BBB> atomnuker: do you have a libaom wrapper for ffmpeg? [16:46:54 CET] <BBB> jamrial: or maybe you? [16:47:09 CET] <jamrial> i don't [16:47:39 CET] <jamrial> one was sent to libav long ago (decoder only), but it may not work anymore [16:48:28 CET] <jamrial> i don't know how much the api evolved since then. it was written not too long after their renamed everything from vpx to aom [16:48:44 CET] <jamrial> s/their/they [17:02:21 CET] <wm4> shouldn't there rather be an internal decoder that's 1000x faster [17:02:30 CET] <wm4> (joking) [17:08:04 CET] <BBB> someone writing that decoder would probably appreciate being able to test it against some reference :-p [17:10:37 CET] <jamrial> BBB: https://lists.libav.org/pipermail/libav-devel/2016-August/078848.html [17:10:46 CET] <BBB> yes I found that :) tnx [17:10:55 CET] <BBB> trying to get it to work now [17:11:02 CET] <BBB> my configure/patch skills are clearly lacking [17:11:46 CET] <BtbN> wm4, at least with the old driver the source assembly for those was right next to them. But not this time. [17:12:47 CET] <daddesio> atomnuker: sure, let me fire up valgrind. [17:15:57 CET] <jamrial> BBB: the imgfmt_to_pixfmt stuff doesn't look correct. it's similar to code we have disabled in the libvpx wrappers [17:16:30 CET] <jamrial> because we implemented it in a different way [17:16:51 CET] <daddesio> if there's any valgrind issue, I'm guessing it's an overlapping memcpy bug? [17:17:00 CET] <BBB> case AOM_IMG_FMT_I420: return AV_PIX_FMT_YUV420P; looks ok [17:17:04 CET] <BBB> I dont think any others are supported [17:17:08 CET] <jamrial> that one is, yes [17:18:18 CET] <BBB> so whats wrong? [17:18:19 CET] <jamrial> i was talking about the 16bps ones, which are mapped to lavu 16bps pix_ftms in there, when we're instead mapping them to 10bps or 12bps depending on vpx_image->bit_depth value [17:18:37 CET] <BBB> ah [17:18:46 CET] <jamrial> if you're only testing yuv420p then it doesn't matter :p [17:23:40 CET] <BBB> Ill add the relevant if for 10/12bits also [17:23:43 CET] <BBB> I see what you mean [17:23:45 CET] <BBB> easy to change [17:38:42 CET] <BBB> [libaom @ 0x7fb4a0801a00] [bla bla] [17:38:43 CET] <BBB> Segmentation fault: 11 [17:38:44 CET] <BBB> right.... [17:46:45 CET] <jdarnley> I think I should ask again... [17:46:46 CET] <jdarnley> Does anyone have experience of clang complaining about "error: invalid application of 'sizeof' to an incomplete type"? Specifically use of FF_ARRAY_ELEMS in checkasm. [17:48:51 CET] <BBB> what type? [17:49:02 CET] <BBB> you cant do it on forward-declared structs, specificall [17:49:03 CET] <BBB> y [17:52:44 CET] <jdarnley> It is an anonymous struct [17:53:05 CET] <jkqxz> You also can't make arrays of them, so FF_ARRAY_ELEMS isn't very meaningful. [17:53:19 CET] <jdarnley> struct { fields } var_name[] { ... } [17:53:51 CET] <BBB> that should be ok [17:53:57 CET] <BBB> if you name the struct, does it work? [17:54:40 CET] <jdarnley> I'm trying to recreate the error but it is buried in this travis testing rubbish [18:29:17 CET] <SortaCore> so, what's up with nvenc vs cuvid [18:30:37 CET] <BBB> ok now it works [18:33:55 CET] <jdarnley> How do I disable the stupid versions appended to library filenames? [18:34:05 CET] <SortaCore> cuvid decoding + old encoding, nvenc new encoding, nvdec soon"? [18:34:15 CET] <BtbN> cuvid never did any encoding. [18:34:27 CET] <nevcairiel> nvenc is the only Nvidia encoding [18:34:37 CET] <nevcairiel> And nvdec already exists [18:34:43 CET] <BtbN> And nvdec and cuvid are the exact same thing. [18:34:49 CET] <BtbN> They just decided to rename it at some point. [18:34:52 CET] <jdarnley> Is it --disable-symver? [18:35:01 CET] <SortaCore> ah, rebrand, now I'm with ya [18:35:30 CET] <BtbN> They just wanted to get rid of the association with CUDA I guess [18:36:19 CET] <nevcairiel> Which is probably a good idea, too many people thought it was a cuda decoder, as in a cuda program [18:36:19 CET] <nevcairiel> Although they did actually have a cuda decoder for mpeg2 [18:36:39 CET] <BtbN> Yeah, they also did for h264 [18:36:41 CET] <BtbN> it was shit [18:36:58 CET] <BtbN> put 100% load on your GPU, and still barely any noticeable CPU load reduction [18:37:02 CET] <nevcairiel> The mpeg2 one has some use on oldish gpus [18:37:10 CET] <nevcairiel> Not anymore [18:37:23 CET] <BtbN> Only ever tested the one for h264 [18:37:27 CET] <BtbN> which is canned by now I think [18:39:52 CET] <nevcairiel> No idea if the mpeg2 one still exists, easy to use through nvdec but just not even worth a option [18:41:29 CET] <SortaCore> will ffmpeg be getting a rename for cuvid? [18:44:13 CET] <BtbN> you're late to the party :P [18:44:47 CET] <BtbN> jdarnley, the symver is pretty important. It's a bad idea to turn it off [18:45:22 CET] <BtbN> Applications link to the .so with the version appended [18:45:33 CET] <BtbN> so getting rid of it will cause issues [18:45:46 CET] <jdarnley> I don't know what that is but it didn't fix my problem anyway [18:46:29 CET] <jdarnley> But this isn't linking at all, linking fails because the swr isn't named .so.3 [18:46:47 CET] <jdarnley> make install [18:47:14 CET] <BtbN> The symver was bumped recently [18:47:22 CET] <BtbN> so you'll have to rebuild stuff still using the old [18:47:45 CET] <jdarnley> I am building and building fails because this libs are named like shit. [18:48:27 CET] <jdarnley> Fuck shared libs. Fuck travis. Fuck debian. [18:49:57 CET] <BtbN> seems like whatever you're building has a questionable build system [18:50:26 CET] <jdarnley> It is autotools! Of course it is questionable! [18:53:43 CET] <jamrial> the ffmpeg build system should afaik create the shared libswresample as .so, .so.3 and .so.3.x.x (two of them as symlinks) [18:55:30 CET] <jdarnley> And why can't I have just .so and leave it at that? [19:00:38 CET] <BtbN> What if the soname gets bumped? [19:00:57 CET] <BtbN> It's used to indicate abi breaks, and enable installing abi-incompatible versions alongside one another [19:20:23 CET] <iive> jamrial: i thought that ldconfig does that. [19:20:35 CET] <iive> or is it already deprecated and not used ? [19:21:05 CET] <BtbN> ldconfig fixes missing symlinks or something like that [19:30:05 CET] <SortaCore> shared libs can return to the firey chasm from whence they came [19:44:45 CET] <SortaCore> err [19:44:59 CET] <SortaCore> I'm getting codec locked up on qsv [19:46:48 CET] <SortaCore> I initialise a context with it, then free the context, and then later initialise another context and use it, but it locks up on avcodec_open2 due to codec being locked [19:47:07 CET] <SortaCore> Assertion atomic_compare_exchange_strong(&ff_avcodec_locked, &exp, 0) failed at libavcodec/utils.c:1976 [19:49:15 CET] <SortaCore> who was messing with atomic? [19:51:56 CET] <SortaCore> Rostislav? [19:52:23 CET] <BtbN> atomnuker [19:54:35 CET] <SortaCore> *stares blankly at @atomnuker* [19:55:41 CET] <SortaCore> I'll see if I can isolate it a bit better [21:03:23 CET] <daddesio> atomnuker: ... I'm an idiot! 8 is the *maximum* frequency resolution (allocated on the stack), but the actual one in use is given by 1 << f->size. (I see f->size varying between 2 and 3 in testvector05.) i.e. every instance of 8 * <blahblah> in the Hybrid Folding patch should really be <blahblah> << f->size. That got rid of all errors in valgrind/MSAN. [21:06:14 CET] <daddesio> libopus has norm[] organized so that it coeffs are populated at the 8* offsets (i.e. there may be gaps between coefficients in norm[]). But FFmpeg uses << f->size offsets (so there are no gaps between coeffs, but there may be unused space at the end of norm[].) [21:10:36 CET] <SortaCore> atomnuker: need a hand with atomics, it's dying on first usage [21:11:40 CET] <SortaCore> https://pastebin.com/raw/UV3aFAzC [21:16:34 CET] <tmm1> anyone have thoughts on what might be going on here: https://gist.github.com/tmm1/fcbe42e9da85514fde48238463400552 [21:18:06 CET] <SortaCore> I have to double PTS/DTS in my vids for some reason [21:19:08 CET] <SortaCore> I see your tbr is doubled [21:20:29 CET] <SortaCore> when I do H264 RTSP -> H264 video file, I manually set timing to match, and do manual incrementing +1, but you have to double pts/dts for some reason or the end video file plays at half speed [21:23:41 CET] <SortaCore> I'm not sure but I think JEEB said something about it? [21:23:55 CET] <atomnuker> SortaCore: weird, keep in mind atomic functions take pointers to atomic variables [21:24:13 CET] <SortaCore> I've not modified your code, just added av_log [21:24:28 CET] <SortaCore> -your code +any ffmpeg code [21:24:49 CET] <SortaCore> this is from master branch, I just tacked in extra av_log for debugging [21:25:15 CET] <SortaCore> so atomic_bool, atomic_int, how do you read them for av_log? [21:32:18 CET] <SortaCore> atm I'm passing the first with ? 1 : 0 and the second flat [21:36:01 CET] <SortaCore> is lockmgr_cb meant to be set there? [21:59:27 CET] <llogan> ubitux: would you (or durandal_1707 perhaps) be willing to look at "Patch vf_blackdetect" (the 2nd version) from "Jon bae"? Looks ok to me but i've never really used these filters. He asked on user ML what he did wrong because nobody replied. [22:10:33 CET] <jamrial> llogan: he should ping it if it's been several days since he sent it [22:11:06 CET] <llogan> yeah, we told him to do that [22:31:31 CET] <jdarnley> That one? He should definitely ping it so we know which one we are supposed to look at. Although I guess we could guess from the dates on them. [22:35:17 CET] <BBB> jamrial: I got libaom working on git master now, should I push this patch somewhere so others can use it too for whatever people want to use this for? [22:38:32 CET] <BBB> https://github.com/rbultje/ffmpeg/commit/d96a0aad4633d22c03e930bc10689c4144… << that works for me, on a somewhat old branch [22:39:01 CET] <BBB> one month old, not too bad I guess [22:39:12 CET] <jamrial> BBB: sure, a branch in your github for it sounds good [22:39:29 CET] <jamrial> if it's not ready to hit git master [22:40:14 CET] <jamrial> you should change the configure check into a pkgconfig one in any case [22:40:29 CET] <BBB> probably not, I mean, av1 isnt finished yet [22:40:29 CET] <BBB> but up to you guys [22:40:33 CET] <BBB> maybe itd be useful for atomnuker [22:40:47 CET] <BBB> pkgconfig doesnt work for non-installed software so unfortunately not useful for me :( [22:41:08 CET] <BBB> (I dont run make install on dev trees such as libaom) [22:42:19 CET] <jamrial> alright [22:42:32 CET] <jamrial> and yeah, probably best to wait at least until the first version post bitstream freeze is tagged [22:53:40 CET] <SortaCore> atomnuker: any idea why Broke [22:55:51 CET] <cone-820> ffmpeg 03John Stebbins 07master:79a744768aa6: lavc/libx265: mark disposable frames [23:05:46 CET] <TD-Linux> I think the bigger issue is that the libaom API might break. as long as it's marked experimental, it being unstable shouldn't be an issue [23:06:23 CET] <TD-Linux> note that it's a good time to go fix any API issues that make it annoying to integrate in ffmpeg [23:49:45 CET] <SortaCore> atomnuker: is this a bad time or something [00:00:00 CET] --- Fri Dec 8 2017

1 0

ffmpeg.log.20171207
by burek 08 Dec '17

08 Dec '17

[00:01:36 CET] <SortaCore> everyone activate your reality anchors [00:01:50 CET] <iive> furq: mister president, I had no idea you also irc, not just twitter! [00:11:07 CET] <kerio> scranton pls [00:20:11 CET] <delsol> the other thing thats awesome about YYYY-MM-DD is that you can use 2017-11-00 and 2017-11-99 for start of month/end of month files..... and they ALSO sort correctly. [00:20:55 CET] <delsol> (where you have stuff that happens nebulously before start of business on the 1st of the month, or happens nebulously after end of business on last day of month. [00:21:16 CET] <alexmarkley> hey friends, i am looking at the ffmpeg-tutorial referenced from the documentation page: https://github.com/chelyaev/ffmpeg-tutorial [00:21:32 CET] <alexmarkley> very helpful for understanding some basic concepts, however appears to be somewhat out of date [00:22:27 CET] <alexmarkley> i have tutorial06.c compiling and working (albiet with lots of deprecation warnings) in my fork: https://github.com/markleybros/ffmpeg-tutorial/commit/054b60b0c85824031b449… [00:23:09 CET] <alexmarkley> can somebody look at that commit / patch and tell me if i am introducing a memory management issue by removing references to *release_buffer ? [00:24:51 CET] <pzich> I would think so. There's an av_malloc() above that and you're not freeing it [00:24:56 CET] <alexmarkley> i am also going to be combing through the code and trying to fix deprecation warnings and such [00:26:40 CET] <alexmarkley> pzich, that's what i suspected -- what is the newer / recommended API for accomplishing this? [00:27:21 CET] <alexmarkley> i notice that currently ffplay does not use get_buffer2 at all [00:27:46 CET] <alexmarkley> struggling to follow the recommended flow here [00:29:05 CET] <pzich> why do you need to remove the free? [00:30:14 CET] <alexmarkley> pzich, the "release_buffer" struct member is completely gone in the current version of the API [00:30:31 CET] <alexmarkley> as is avcodec_default_release_buffer() [00:30:56 CET] <alexmarkley> not finding a ton of discussion around it either [00:32:24 CET] <pzich> hmm, unfortunately I don't know much about it. does the middle response here sound reasonable? https://lists.ffmpeg.org/pipermail/libav-user/2013-November/005840.html [00:36:42 CET] <alexmarkley> pzich, yeah i'm just now coming to a similar conclusion [00:36:52 CET] <alexmarkley> i think the get_buffer callback is declared incorrectly [00:40:21 CET] <JEEB> alexmarkley: under docs there's examples in the git tree [00:40:34 CET] <JEEB> they're not perfect but they should get you through the usual things [00:40:51 CET] <JEEB> and the new push/pull decoding API and the refcounted AVFrames thing are generally <3 [00:40:57 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [00:42:41 CET] <alexmarkley> JEEB, i saw some examples there... got stuck trying to figure out how to automatically detect the proper codec for the video file [00:42:47 CET] <Rajko> hmm how do i get the decode/presentation order from an AVFrame after decoding ? [00:42:55 CET] <Rajko> both of those variables seem to be 0 [00:45:28 CET] <alexmarkley> oh hmm, looks like docs/examples/demuxing_decoding.c has the basics [00:45:35 CET] <JEEB> yes [00:45:44 CET] <JEEB> lavf for reading/writing streams into files/streams [00:45:47 CET] <JEEB> lavc for decoding/encoding [00:45:54 CET] <JEEB> lavfi for filtering video/audio [00:48:48 CET] <alexmarkley> JEEB, thanks for pointing this out... i will start here and come back when i have more questions ;) [00:50:17 CET] <JEEB> alright [02:33:33 CET] <TheRock> I heard all warnings will be fixed until today evening [03:47:51 CET] <fella> ^sb e [06:03:18 CET] <DeexGerm> Hello, is it possible to use fading effects (crossfade) after every image file with concat in the textfile? [07:57:23 CET] <rjp421> during ./configure, how do i force it to find OMX_Core.h? [07:59:56 CET] <rjp421> which type of path do i need to define? ELIB? [08:02:55 CET] <rjp421> -extra-libs or --extra-ldflags etc [08:04:24 CET] <rjp421> the file is in /opt/vc/include/IL [08:59:24 CET] <rjp421> i removed --enable-omx and kept enable-omx-rpi, seems to be working now [10:17:38 CET] <traw> is avcodec_send_packet/frame functions are thread safe? [10:39:10 CET] <EriC^^> is there a way to make ffmpeg faster? [10:43:10 CET] <Nacht> EriC^^: There are a few ways, but it really depends on what you're doing [10:43:24 CET] <Nacht> And what you wish the output to be [10:43:53 CET] <JEEB> traw: not sure, never looked into calling those from different threads [10:44:05 CET] <JEEB> they might or might not be [10:45:02 CET] <EriC^^> Nacht: i'm trying to convert .opus to .mp3 128K bitrate [10:46:04 CET] <Nacht> EriC^^: Do you have to transcode ? [10:46:36 CET] <EriC^^> Nacht: tbh i dont know what that is [10:46:48 CET] <EriC^^> it's already 128K .opus [10:47:06 CET] <EriC^^> Stream #0:0(eng): Audio: opus, 48000 Hz, stereo, fltp [10:47:20 CET] <EriC^^> Stream #0:0(eng): Audio: mp3 (libmp3lame), 48000 Hz, stereo, fltp [10:47:23 CET] <JEEB> that doesn't really matter, you're taking something in, decoding it, then passing it to another encoder [10:47:37 CET] <JEEB> and that should in theory be darn fast already [10:47:48 CET] <JEEB> the best way to optimize is to do multiple files at once then [10:59:30 CET] <EriC^^> i noticed that youtube-dl runs ffmpeg after it downloads the file and ffmpeg only uses 4% of the cpu, when i run ffmpeg it uses 80% so it's way faster [11:00:24 CET] <JEEB> CPU usage != speed [11:00:27 CET] <EriC^^> how could i tell youtube-dl to just download the webm music and i could use ffmpeg after that manually, if i run youtube-dl without the -x (extract audio) argument it downloads a huge video file [11:00:40 CET] <JEEB> just tell it to only pick the audio format? [11:00:44 CET] <JEEB> -F for listing them [11:00:45 CET] <EriC^^> JEEB: it is actually making a huge difference, 1min vs 20secs [11:02:28 CET] <infinisil> EriC^^: Try figuring out how youtube-dl and you are invoking ffmpeg differently [11:02:32 CET] <JEEB> then it's something else [11:02:52 CET] <EriC^^> how can i tell what to download? i tried youtube-dl -f webm [11:03:00 CET] <EriC^^> infinisil: ok i'll check the command it's running [11:03:51 CET] <infinisil> EriC^^: And I believe you can use --postprocessor-args to give additional arguments to ffmpeg [11:13:27 CET] <JEEB> EriC^^: -F gives you the full list of alternative streams [11:13:33 CET] <JEEB> which with youtube includes audio-only [11:13:51 CET] <JEEB> after that read the darn youtube-dl documentation on how to tell youtube-dl to only download that specific thing [11:13:56 CET] Action: JEEB goes back to $dayjob [11:14:10 CET] <sfan5> >being on IRC @ work [12:07:03 CET] <mz_> Hello, I'm curious about the -copyts flag [12:07:52 CET] <mz_> Can omitting it desynchronize audio and video? [12:58:32 CET] <wouter> hi -- I've got a .webm file and several .vtt subtitle files [12:58:56 CET] <wouter> I'd like to create one .webm file with all the subtitles in the same container, and the proper metadata so that the language tags are assigned [12:59:42 CET] <wouter> "ffmpeg -i foo.webm -i foo.en.webm -i foo.nl.webm -y foo.subbed.webm" only contains the first subtitle, so I'm assuming I'll need to add a -map? [12:59:50 CET] <wouter> I'd also need to be able to set the subtitle metadata... [13:09:02 CET] <wouter> nvm, found it [13:09:52 CET] <wouter> ffmpeg -i foo.webm -i foo.en.vtt -i foo.nl.vtt -map 0:v -map 0:a -map 1:s -map 2:s -metadata:s:a language=eng -metadata:s:s:0 language=eng -metadata:s:s:1 language=nld -c copy -y foo.subbed.webm [13:14:48 CET] <CoreX> why do i keep thinking ffplay can also encode ? [14:53:37 CET] <termos> can't seem to get the "image2" muxer to work properly, "file image.jpg" just tells me the image is data. Is there a header missing? [14:55:12 CET] <termos> hm I guess I can't use h264 encoded data into any image container? [14:57:37 CET] <SortaCore> hmm, maybe explicit codec, maybe filename needs macros [14:58:21 CET] <kepstin> termos: for image formats, they usually have bespoke formats per codec. So you puts jpeg images in jpeg (well, jif/jfif) files; png images in png files, etc. [14:58:58 CET] <kepstin> as far as I know, there's no widely supported still image container which you can put h264 into [15:00:04 CET] <termos> i see, thanks! my program is using the libavcodec for this so I need to make support for another codec to encode into then [15:00:35 CET] <kepstin> libavcodec can encode to many popular still image formats, you shouldn't need any other library [15:00:45 CET] <kepstin> just encode to the correct format for the desired output type [15:20:55 CET] <BtbN> Aren't jpeg and an h264 I-Frame pretty similar? [15:50:13 CET] <termos> I guess they should be, some dct'ed data [15:56:19 CET] <tommy``> guys whats wrong on my command? [15:56:23 CET] <tommy``> ffmpeg -i "What is Planet Hulk.mp4" -vf subtitles=PlanetHulk.it_it.srt force_style=FontName=Arial,FontSize=16,OutlineColour=&H55000000,BorderStyle=3,Alignment=6 PH.mp4 [16:07:30 CET] <Nacht> subtitles=PlanetHulk.it_it.srt force_style=FontName=Arial > subtitles=PlanetHulk.it_it.srt,force_style=FontName=Arial ? [16:08:24 CET] <Nacht> Anyone know the max ammount of input's a filter_complex allows ? [16:27:00 CET] <alexpigment> has anyone done any testing with the h264_amf (AMD hardware) encoder? [16:27:18 CET] <alexpigment> i can't figure out how to control the constant quality mode [16:29:15 CET] <alexpigment> maybe I have to specify each qp_i/qp_b/qp_p rather than a global option? [16:39:13 CET] <DHE> alexpigment: from the source, did you specify an "-rc" value? For constant quality you set cqp but this is NOT the same thing as x264's -crf [16:39:51 CET] <alexpigment> DHE: no, i didn't explicitly set it, because that's the default option [16:40:05 CET] <alexpigment> i was looking for a global command to set the qp [16:40:24 CET] <alexpigment> i'm now specifying each b/i/p quality, but it's a bit tedious [16:48:42 CET] <tomtomb> Hello all.. I got a question, hope somebody could help [16:49:53 CET] <tomtomb> i'm trying to split an xdcam mxf file to 3 different files, one for video, one for audio1, one for audio2 (3 opatom's) however ffmpeg says it needs a video stream for mxf files... is there anyway to split op1a to 3atoms with ffmpeg? [16:51:38 CET] <alexpigment> tomtomb: can you pastebin your command and include the error as well? [16:54:45 CET] <tomtomb> alexpigment: https://pastebin.com/0xykdVXf - thanks! [16:56:39 CET] <alexpigment> tomtomb: what happens if you set your outputs to video.m2v, audio1.wav, and audio2.wav ? [16:57:16 CET] <tommy``> Nacht, strange i got another error now: ffmpeg -i "What is Planet Hulk.mp4" -vf subtitles=PlanetHulk.it_it.srt,force_style=FontName=Arial,FontSize=16,OutlineColour=&H55000000,BorderStyle=3,Alignment=6 PH.mp4 [16:57:37 CET] <tommy``> "At least one output file must be specified" but i've PH.mp4 [16:59:48 CET] <alexpigment> tommy: put a colon after .srt [17:00:49 CET] <alexpigment> you might also need to do force_style='parameters,parameters,parameters' [17:01:00 CET] <alexpigment> it shows that in the documentation [17:01:10 CET] <alexpigment> https://ffmpeg.org/ffmpeg-filters.html#toc-subtitles-1 (see last example) [17:01:15 CET] <tommy``> ok [17:01:18 CET] <tommy``> let see [17:02:29 CET] <tommy``> alexpigment now i've: [17:02:30 CET] <tommy``> >ffmpeg -i "What is Planet Hulk.mp4" -vf subtitles=PlanetHulk.it_it.srt:force_style='FontName=Arial,FontSize=16,OutlineColour=&H55000000,BorderStyle=3,Alignment=6' PH.mp4 [17:02:47 CET] <alexpigment> yeah, that looks correct compared to the example [17:02:53 CET] <tommy``> same error [17:03:33 CET] <alexpigment> tommy: i wonder if it's possible the name isn't being escaped correctly [17:03:47 CET] <tommy``> the input? yes i've used TAB [17:03:52 CET] <alexpigment> does the same error occur if you use PlanetHulk.srt etc? [17:04:18 CET] <tommy``> yes [17:05:05 CET] <alexpigment> no clue then. i'd remove each option (e.g. Alignment=6) and see if it starts working after your remove one of the options [17:05:23 CET] <alexpigment> maybe someone else here can spot the problem [17:05:25 CET] <tommy``> seems it doesnt like the HEX code [17:05:45 CET] <tommy``> outlineColour=&H5500000 [17:05:51 CET] <alexpigment> ah [17:05:54 CET] <tomtomb> alexpigment, if I set it to mxf, wav and wav it works.. but I need it as an mxf, to create opatom to import into avid's interplay system [17:05:55 CET] <alexpigment> it uses that in the example [17:06:28 CET] <alexpigment> tomtomb: it may just be a limitation of ffmpeg's mxf muxer [17:06:38 CET] <alexpigment> it seems to explicitly need a video stream to exist as the first stream [17:06:48 CET] <alexpigment> in which case, the pcm streams will fail [17:07:31 CET] <tomtomb> alexpigment, sounds about right.. so you think ffmpeg isn't capable of creating mxf atoms at all? [17:07:40 CET] <tommy``> >ffmpeg -i "What is Planet Hulk.mp4" -vf subtitles=PlanetHulk.it_it.srt PH.mp4 [17:07:42 CET] <tommy``> ops [17:07:43 CET] <tommy``> sorry [17:09:10 CET] <tommy``> alexpigment, found solution!!!!! [17:09:33 CET] <tommy``> need ----> " before subtitles and at the end of Alignement=6' " [17:10:01 CET] <alexpigment> tommy: good work :) i figured it was a character escaping issue [17:10:24 CET] <alexpigment> tomtomb: honestly, i'm not familiar enough with working with mxf files that only have audio streams [17:10:41 CET] <tommy``> alexpigment econding speed=0.274 :(( [17:10:50 CET] <alexpigment> tomtomb: i'll have to take your word for it that avid can't accept wav files [17:11:26 CET] <alexpigment> tommy: if speed is a concern, you may want to try -preset veryfast [17:11:49 CET] <alexpigment> understanding that veryfast produces slightly worse quality at a given crf value [17:11:50 CET] <tommy``> no no, i don't have rush, it's my pc that is 10 years aold :D [17:12:00 CET] <alexpigment> tommy: oh, that'll do it :) [17:12:02 CET] <alexpigment> core 2 duo? [17:12:13 CET] <tommy``> you're a wizard, yes [17:12:21 CET] <tommy``> E6600 with 6GB ram and ssd 250gb [17:13:34 CET] <alexpigment> well, i'm not sure where you're at, but decommissioned business desktop computers (e.g. dell optiplex, hp elitedesk, etc) are usually very cheap on ebay [17:13:51 CET] <alexpigment> and a 3-year old core i5 or i7 is going to be miles ahead of what you have [17:14:04 CET] <alexpigment> on the other hand, a newer AMD Ryzen is a fine choice for encoding [17:18:53 CET] <alexpigment> tomtomb: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/168073.html [17:19:11 CET] <alexpigment> that was ~3 years ago, but it seems to explicitly mention that audio won't work in the muxer [17:27:10 CET] <alexpigment> tomtomb: add -f mxf_opatom to each output [17:29:28 CET] <tommy``> alexpigment the guide of ffmpeg in the website exists in pdf? [17:31:49 CET] <alexpigment> tommy: not sure. i've only ever looked at the website [17:31:59 CET] <alexpigment> which is probably a good thing, because it changes regularly [18:22:43 CET] <tommy``> is possible before enconding to see the result of encodes live during settings? [18:25:03 CET] <takov751> greetings [18:25:29 CET] <takov751> Is there anyone who has experience with ffmpeg build with cuvid support? [18:28:54 CET] <SortaCore> wasn't it replaced with nvenc? [18:29:50 CET] <alexpigment> cuvid is still used for decoding, at least in name [18:30:05 CET] <alexpigment> takov751: are you talking about accelerated decoding or encoding? [18:32:22 CET] <alexpigment> at any rate, if you actually mean nvenc encoding, then yes. i have a decent amount of experience [18:33:07 CET] <takov751> decoding [18:33:20 CET] <alexpigment> ah, then the answer is "i have very little" ;) [18:33:21 CET] <takov751> i just found the officall build instruction [18:35:17 CET] <takov751> but the whole problem is probably that i have a geforce 840m (mg108) [18:35:36 CET] <takov751> but on the windows version i could use it [18:36:03 CET] <takov751> which is really annoying [18:36:13 CET] <alexpigment> is this is a linux driver thing? [18:37:30 CET] <takov751> might be [18:37:37 CET] <alexpigment> have you tried vdpau? [18:38:01 CET] <takov751> its not seems to be working with the property driver [18:38:05 CET] <alexpigment> that might be your only option if cuvid doesn't work [18:38:06 CET] <takov751> and with nouveau [18:38:16 CET] <alexpigment> hmm [18:40:28 CET] <takov751> i did downloaded the video sdk which was suggested in the nvidia website [18:46:16 CET] <BtbN> takov751, build ffmpeg without --disable-cuvid, and you will get it. [18:47:44 CET] <takov751> when i builted it it was with --enable-cuvid XD [18:47:50 CET] <takov751> --enable-nonfree --enable-nvenc --enable-nvresize --enable-gpl --enable-libx264 --enable-cuda --enable-cuvid --enable-libnpp [18:48:04 CET] <BtbN> That's for some nvidia-crippled version of ffmpeg. [18:48:08 CET] <BtbN> There is no nvresize in ffmpeg. [18:50:28 CET] <takov751> yes i had to remove that option, and it did build that way [18:50:37 CET] <takov751> butstill the same error [18:51:26 CET] <alexpigment> takov751: for what it's worth, i don't think you ever mentioned what the error was [18:51:37 CET] <alexpigment> (or i may have missed it) [19:05:46 CET] <takov751> [h264_cuvid @ 0x563c06e0dc60] Codec h264_cuvid is not supported. [19:08:31 CET] <BtbN> Is this an Optimus card? [19:09:33 CET] <takov751> yep [19:09:42 CET] <BtbN> They don't have a video unit. [19:09:45 CET] <takov751> but nvidia prime working [19:09:48 CET] <BtbN> You are supposed to use the Intel Card. [19:10:02 CET] <takov751> with the libmfx? [19:10:09 CET] <BtbN> vaapi [19:10:54 CET] <sfan5> optimus configurations have no video units?? [19:11:02 CET] <BtbN> Not in the Nvidia-Side of things, no [19:11:18 CET] <BtbN> It's made for energy efficiency. So having two of them would be counter-productive. [19:11:43 CET] <sfan5> huh [19:12:46 CET] <alexpigment> BtbN: are you sure you're not talking about nvenc specifically? [19:12:53 CET] <BtbN> yes I am [19:13:16 CET] <alexpigment> unless they turn off the nvdec feature of the 840m when it's paired with intel, it should be able to do hardware decoding from what I understand [19:13:25 CET] <alexpigment> https://en.wikipedia.org/wiki/Nvidia_PureVideo [19:13:27 CET] <alexpigment> 840m [19:13:40 CET] <BtbN> well, that's exactly what they do in Optimus-Setups [19:13:42 CET] <alexpigment> feature set E [19:13:49 CET] <BtbN> They just completely turn off that part of the chip, to save energy [19:13:54 CET] <alexpigment> BtbN: ok, i'll take your word for it [19:14:08 CET] <BtbN> So far I had two optimus laptops where that was and is the case [19:14:12 CET] <BtbN> latest one has a 940M [19:14:28 CET] <BtbN> So I can't say for sure if it's still like this with Pascal, but everything older definitely works like that [19:15:12 CET] <alexpigment> i mean it makes sense from one perspective, but it also seems weird to turn off something that the chip natively has and probably performs better than the built-in intel solution [19:15:47 CET] <BtbN> The Nvidia chip is turned off most of the time [19:15:52 CET] <BtbN> And is only powered on for games [19:16:02 CET] <alexpigment> BtbN: yes, but you're saying a particular feature is completely disabled from the GPU [19:16:04 CET] <BtbN> It makes perfect sense to leave video de/encoding to the Intel chip, which is on at all times [19:16:26 CET] <alexpigment> again, i'll take your word for it [19:17:05 CET] <BtbN> It really shouldn't be any performance difference [19:17:18 CET] <BtbN> Intel GPUs are well capable of decoding stuff in real time [19:17:39 CET] <BtbN> It's just annoying because of all the different APIs. On Windows it's perfectly transparent, as both use the same API [19:17:42 CET] <alexpigment> BtbN: I was really referring to quality, but yes, anything will be fast [19:18:00 CET] <BtbN> At least on the decoder side there is no quality difference [19:18:21 CET] <BtbN> And from my experience the intel and nvidia encoders are about even. But never did any serious quality comparisons. [19:18:37 CET] <alexpigment> the deinterlacing on Nvidia seems superior to my eyes [19:18:39 CET] <BtbN> But you have to deal with QSV or VAAPI to use them [19:19:41 CET] <BtbN> https://developer.nvidia.com/nvidia-video-codec-sdk even specifically mentions that GM108 is not supported [19:19:53 CET] <BtbN> so it might just be that specific chip that's lacking a video unit [19:20:35 CET] <sfan5> decoding is certainly supported/enabled on both cards https://0x0.st/sHfS.txt [19:20:43 CET] <sfan5> my nvidia card doesn't have nvenc so can't check that [19:21:36 CET] <BtbN> What card is that? [19:21:58 CET] <BtbN> it looks old, being snb [19:22:00 CET] <sfan5> GTX 520M [19:22:07 CET] <sfan5> old indeed [19:22:20 CET] <BtbN> yeah, so it might just be specifically the GM108 that's lacking any kind of video acceleration [19:22:30 CET] <BtbN> My 940M is one as well [19:22:37 CET] <BtbN> 840M should be as well [19:26:29 CET] <takov751> thanks for the help :D [19:50:39 CET] Action: kepstin notes for reference that the gp108 (GTX 1030, MX150) has video decoding, but not encoding. [19:50:53 CET] <Rajko> for real ? [19:52:22 CET] <kepstin> er, it's GT 1030, not GTX 1030. Apparently the cut down card wasn't felt worthy of the X ;) [19:53:02 CET] <DHE> yeah the really low-end cards don't have nvenc support [21:08:13 CET] <redrabbit> weak ! [21:12:24 CET] <alexpigment> man, this AMF encoder causes all kinds of weird graphical issues when playing the videos back in WMP [21:12:48 CET] <alexpigment> i don't even know what this implies, but there will be places in the video that have just random colors until the next IDR [21:24:41 CET] <mbrr> Cross-compiling FFmpeg for RPi3, Asus Tinkerboard, and Beaglebone Black. Following the guide for the Pi. Do I need to change "--extra-cflags='-march=armv6' --extra-ldflags='-march=armv6'" in the Compiling libx264 section? I read ARMv7 is backwards compatible but just checking. [21:44:41 CET] <korpen> Hi! I am following the ffmpeg tutorial over at dranger.com but I am quickly running into problems. The code there was updated in 2015, and seeing as some stuff has been deprecated since then I'm wondering: does anyone know of a more up-to-date tutorial or at least a list of deprecations? I'm looking at the documentation and can find in what version the feature was removed but I can't for the life of me find what was supposed to replace [21:45:49 CET] <alexpigment> korpen: this isn't exactly an answer to your question, but what exactly is not working or deprecated? [21:46:01 CET] <alexpigment> also most of the stuff on ffmpeg's wiki and documentation is still accurate [21:47:21 CET] <korpen> AVStream::codec has been deprecated, avcodec_copy_context, avpicture_get_size, avpicture_fill, avcodec_decode_video2, av_free_packet [21:48:34 CET] <BtbN> What are you even building that you need to care about that? [21:49:09 CET] <BtbN> If you're just building ffmpeg, you don't need to care about deprecation warnings it throws [21:49:44 CET] <korpen> I'm building an application that uses the ffmpeg libraries, I figured the first step then is to get a video playing [21:50:37 CET] <korpen> The problem is in using the libraries, not building them [21:51:47 CET] <BtbN> If it hasn't been updated for the new APIs, you're going to have a hard time with that [21:55:05 CET] <korpen> Which is why I asked if there was some deprecation documentation that I have been unable to find [21:55:57 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/APIchanges [21:57:00 CET] <korpen> Thanks! [21:59:38 CET] <JEEB> anyways, since the AVStream's avcodec context was never meant to be re-used it has since been in removal [22:00:29 CET] <JEEB> what's supposed to happen is you create your own avcodec context for the avstream's codec, and then use the "copy from codec parameters" function to initialize your own avcodec context :) [22:17:47 CET] <sparks56> hello chatpeople --> need help compiling vlc [22:19:43 CET] <sparks56> problem --> configure fails on libavcodec and libavutil. I just compiled and installed the latest version of ffmpeg and vlc will not recognize it [22:20:45 CET] <sparks56> anyone out there [22:20:54 CET] <sfan5> .. [22:20:56 CET] <sfan5> pastebin the configure logfile [22:21:15 CET] <BtbN> stable vlc does not support current ffmpeg master [22:22:41 CET] <sparks56> ./configure --prefix=/usr --enable-gpl --doxygen=doxygen --enable-nonfree --enable-shared --enable-libx264 --enable-libmp3lame --enable-libpulse --enable-libtheora --enable-libvorbis --enable-libxvid --as=yasm [22:26:47 CET] <sparks56> BtbN: what is the preferred branch [22:27:22 CET] <BtbN> you should ask the vlc people [22:28:47 CET] <sparks56> recommendation for vlc build [22:30:02 CET] <sparks56> need to fight with pillow bye for now [22:32:12 CET] <teratorn> what do folks use instead of ffserver for basic rtp publishing? [23:39:34 CET] <teratorn> anyone know how you would connect the output of ffmpeg to dvblast? [00:00:00 CET] --- Fri Dec 8 2017

1 0

ffmpeg-devel.log.20171206
by burek 07 Dec '17

07 Dec '17

[00:11:59 CET] <kierank> atomnuker: why do you think it is ffmpeg [00:21:13 CET] <nevcairiel> also, it doesnt mention vp9 anywhere on there [00:21:19 CET] <nevcairiel> or opus for that matter [00:22:29 CET] <kierank> doesnt install here [01:28:11 CET] <tmm1> jkqxz: any ideas about this error mateo` ran into: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221692.html [01:30:36 CET] <jkqxz> That's the missing device type which you've already fixed. [01:31:01 CET] <JEEB> :) [01:38:51 CET] <tmm1> hah [01:41:48 CET] <cone-036> ffmpeg 03sfan5 07master:d3a2100c67a0: fate/hevc: add skip_loop_filter test [01:41:49 CET] <cone-036> ffmpeg 03Michael Niedermayer 07master:c8bd2c7d09bf: tests/fate/mov: Fix fate-mov-invalid-elst-entry-count failure on ARM [01:51:48 CET] <tmm1> mateo`: can you try changing mediacodec_hw_configs .device_type and see it works? [01:52:43 CET] <tmm1> if you want to amend the docs as you suggested and push the commits, feel free [04:01:32 CET] <atomnuker> kierank: https://blogs.windows.com/msedgedev/2017/12/05/introducing-web-media-extens… [04:02:32 CET] <kierank> Oh nice [04:07:50 CET] <wm4> I wonder if they can play ogg theora correctly (unlike ffmpeg) [06:15:31 CET] <TD-Linux> wm4, what are you referring to? the zero length packet? [06:15:36 CET] <TD-Linux> (still updating my vm to test) [06:15:44 CET] <TD-Linux> wm4, note that it uses ffmpeg [06:16:22 CET] <TD-Linux> https://github.com/Microsoft/FFmpegInterop [06:16:51 CET] <wm4> fucked up timestamps [06:18:04 CET] <TD-Linux> oh, it does granulepos wrong? [06:18:40 CET] <wm4> no idea, never cared about it [06:18:58 CET] <wm4> rmuxing to mkv with mkvmerge makes such files playable [06:19:16 CET] <TD-Linux> you haven't described the problem enough for me to have a hope of reproducing it [06:20:09 CET] <wm4> actually wait, maybe it was ogm [06:20:18 CET] <wm4> which is apparently completely different [06:20:31 CET] <TD-Linux> yeah, ogm is a hack to put vfw into ogg [06:21:54 CET] <wm4> can't find a sample file anyway [06:23:14 CET] <TD-Linux> katawa shoujo has some [06:24:00 CET] <TD-Linux> (that said, I don't really care about ogm either) [10:39:51 CET] <fx159159> Is my assumption correct that when I have a YUV picture where U and V are interleaved and U starts at 0xcc8e0001 and V at 0xcc8e0000 that the format is actually NV21? [10:55:18 CET] <nevcairiel> sounds like it [10:59:44 CET] <fx159159> nevcairiel: Weird.. I have to set the opposite (NV12) on my AVStream, otherwise the colors are swapped [11:04:20 CET] <wm4> I think ffmpeg's plane order conventions are swapped relative to other systems [11:04:35 CET] <wm4> you see the same with 3 plane 4:2:0 yuv [11:12:12 CET] <fx159159> Swapped relative to what? So ffmpeg's NV12 is actually NV21 in other definitions? [11:15:25 CET] <wm4> no idea, just saying that it might be possible that it's a confusion of conventions [11:22:26 CET] <nevcairiel> NV12 is NV12 [11:22:39 CET] <nevcairiel> the only confusion is that people assume that yuv420p == YV12 [11:22:52 CET] <nevcairiel> but yuv420p is I420 if you want to stay with FourCCs [11:23:01 CET] <nevcairiel> YV12 is I420 with swapped chroma planes [11:25:45 CET] <wm4> I mean, if you use libswscale or something to convert a 3 plane format to nv12, the confusion could still occur [11:26:04 CET] <fx159159> Well... could it be that Android actually fucks up again and swaps U and V planes? [11:26:28 CET] <nevcairiel> from the same reason tho, that people assume yuv420p = YV12. YV12 is really the only common "FourCC" format which is swapped [11:26:43 CET] <nevcairiel> all others have U first [11:26:53 CET] <nevcairiel> including NV12 [11:27:23 CET] <nevcairiel> if Android doesnt even call it NV12, they can do whatever, I guess? [11:27:30 CET] <fx159159> https://developer.android.com/ndk/reference/group___media.html#gga9c3dace30… [11:27:50 CET] <nevcairiel> their definition is so broad that it might as well be NV21 [11:27:53 CET] <fx159159> They call it YUV_420_888 with a pixel stride of 2 ;-) [11:28:11 CET] <nevcairiel> it could be I420, YV12, NV12, NV21 .. all in one name with added properties [11:28:41 CET] <fx159159> I relied on their order of the planes but then U and V are probably swapped [11:30:28 CET] <wm4> what a surprise that mediacodec doesn't even get this right, sigh [11:31:45 CET] <nevcairiel> well, they have a generic description, its not inherently "wrong" [11:32:28 CET] <nevcairiel> its just uncommon [11:42:23 CET] <jdarnley> I would agrue that it is wrong to make people think that there is junk between each U and each V sample with their silly "pixel stride" value. [11:42:48 CET] <jdarnley> But perhaps I am just too used to stride being used for alignment and padding for SIMD. [11:43:27 CET] <BtbN> There can be anything in the "empty space" between the width and the linesize [11:46:41 CET] <jdarnley> True, you need to read some docs to discover whether you can write to it or not. [11:47:19 CET] <BtbN> It usually exists because certain instructions do write to it, so they do not write over the next line [11:49:12 CET] <atomnuker> jdarnley: have you heard of v210a? [11:49:20 CET] <jdarnley> I have not [11:49:44 CET] <atomnuker> there's some v210 out there with an alpha channel in the 2 bits of padding [11:50:48 CET] <jdarnley> Oh, not as bad as I expected. [11:50:50 CET] <jdarnley> I am lead to believe the those two bits must be zero otherwise. [11:51:01 CET] <jdarnley> So you can't put junk there anyway. [11:53:36 CET] <nevcairiel> I only know Y410 wich packs 2-bit alpha with 3x10bit pixel into one, i've always wondered if 2-bit alpha are really worth having [11:54:20 CET] <nevcairiel> 0/25/75/100 arent exactly that high granularity for alpha [11:55:31 CET] <wm4> probably good enough if you need only binary transparency, and the other bit is a free extra so they included it [11:55:35 CET] <jdarnley> y410 huh? Based on the previous discussion is that v210 with swapped chroma? :) [11:55:44 CET] <nevcairiel> no, its 4:4:4 [11:55:54 CET] <jdarnley> ah [11:56:27 CET] <jdarnley> Are you sure it isn't 4:1:0 :) [11:57:02 CET] <nevcairiel> yes, the 10 indicates bitdepth, there is also a Y416 which is 64bpp and includes full 16-bit alpha [11:57:56 CET] <rcombs> MediaCodec used to have a bunch of different IDs for different ways to encode YUV 4:2:0 [11:58:28 CET] <rcombs> they deprecated them all and replaced them with one "flexible" ID meant to represent any 8-bit YUV 4:2:0, with an additional struct describing the plane layout [11:58:37 CET] <rcombs> (said struct is not available via the C API) [11:58:47 CET] <rcombs> thanks, android [11:58:49 CET] <rcombs> thandroid [11:59:51 CET] <nevcairiel> I dont know if microsoft really defined those formats, but its their recommended YUV formats following a fixed structure .. P or Y for planar or packed (no idea why Y for packed, but hey), 0/2/4 for the chroma variants (4:2:0, 4:2:2, 4:4:4), and followed by the bitdepth (10/16) .. so that makes P010, P016, P210, P216, Y210, Y216, Y410, Y416 (for some reason they dont like planar 4:4:4) [15:01:00 CET] <thardin> I want to insert a bunch of stuff in a binary file. anyone know a good editor for that? mostly copy-pasting bytes. but I do need insert functionality, not replace [15:02:34 CET] <sfan5> any hex editor? [15:02:48 CET] <sfan5> i mostly use ghex / bless if I need to do this [15:03:07 CET] <thardin> I'm used to vbindiff, which only does replace [15:03:17 CET] <JEEB> vbindiff is good for binary diffs, yea [15:03:30 CET] <JEEB> but yes, bless I think I've used on *nix and hxd on windows [15:03:50 CET] <thardin> better yet, is there a binary template editor? [15:04:05 CET] <thardin> like 010 [15:04:12 CET] <JEEB> ah [15:04:31 CET] <thardin> it would be nice if length fields and alignment pads were recomputed automagically [15:04:45 CET] <JEEB> I think hexamonkey had some templates for file types [15:04:53 CET] <JEEB> but I don't know if it works for modifications [15:05:20 CET] <thardin> neat [15:05:47 CET] <thardin> 010 is pretty crazy. you can edit DEFLATEd data for example [15:05:50 CET] <JEEB> yea [15:05:58 CET] <JEEB> 010 I've thought of getting every now and then [15:11:18 CET] <thardin> I think I'll modify the code I'm looking at and pretend it's getting a bad file for now [15:15:45 CET] <thardin> getting ffprobe to choke, woo! [15:18:08 CET] <JEEB> :) [15:19:10 CET] <thardin> I can construct a file that makes ffprobe spec 1 ms parsing every 4 specially crafted bytes on an i7 [15:19:17 CET] <thardin> spend not spec [15:20:36 CET] <thardin> will have to write a patch for it [15:20:52 CET] <thardin> and check some other libs for similar issues [16:00:26 CET] <thardin> is there a way to get overcommit to play nice with av_calloc? [16:01:04 CET] <thardin> if I allocate a rather hefty chunk of memory but only use it very sparsely but still want it filled with zeroes [16:01:50 CET] <cone-040> ffmpeg 03Paul B Mahol 07master:53855e3c040a: avfilter: add setrange filter [16:06:49 CET] <thardin> seems linux might actually do what one expects, but av_calloc spoils it [16:07:29 CET] <BtbN> How would you zero initialize memory that's not allocated? [16:07:37 CET] <BtbN> calloc is alloc + zero-fill after all [16:09:23 CET] <thardin> I wouldn't, the kernel would [16:09:28 CET] <thardin> on page fault [16:09:32 CET] <DHE> I think your only other option is to mmap /dev/zero, but that's not av_free*() friendly [16:10:04 CET] <iive> isn't that what glibc does for calloc? [16:10:06 CET] <thardin> we had a similar discussion in the local HPC group. don't bother with packed matrix formats, just allocate as much space as a full matrix would use [16:10:37 CET] <thardin> you can allocate 1000,000x100,0000 no problem [16:12:55 CET] <BtbN> How would the kernel know to zero-allocate the new memory? [16:13:15 CET] <thardin> that's the question [16:14:50 CET] <BtbN> https://github.com/bminor/glibc/blob/master/malloc/malloc.c#L3360 it's definitely a complex one [16:16:45 CET] <BtbN> But even that ultimately just doe memset(d, 0, clearsize); [16:16:49 CET] <BtbN> *does [16:16:51 CET] <thardin> probably possible is going to be my guess. not going to worry about it since it's only a matter of half a meg in this case [16:19:47 CET] <thardin> the code I'm looking to replace might allocate up to 1 MiB anyway [16:24:39 CET] <iive> BtbN: the actual question is, why a kernel would allocate anything bug zeros? [16:24:46 CET] <iive> bug/but [16:24:53 CET] <BtbN> Because it's faster. [16:25:05 CET] <iive> and may leak confidential data [16:25:16 CET] <jkqxz> Yeah, anonymous mmap() always gives you zero pages. [16:25:38 CET] <jkqxz> Or, more accurately, anonymous mmap() always gives you the zero page (possible lots of times). [16:26:12 CET] <jkqxz> It's then CoW, so calloc() filling with zeroes will force the copy even though it isn't changing anything. [17:56:51 CET] <durandal_1707> if i insert scale filter to convert from limited to full range yuvj test passes [17:58:10 CET] <durandal_1707> thing is the scale filter should be already autoinserted anyway [18:07:09 CET] <funman> __av500__: is http://www.tp-link.fr/products/details/cat-18_TL-PA4010P.html any good ? [18:37:23 CET] <cone-040> ffmpeg 03Nikolas Bowe 07master:5a412a5c3cc2: avcodec/extract_extradata_bsf: Fix leak discovered via fuzzing [20:49:00 CET] <cone-040> ffmpeg 03James Almer 07master:d6d605eb05c3: avformat/mux: stop delaying writing the header [21:20:35 CET] <SortaCore> best way to retain a AVFrame for later sws_scale? [21:20:43 CET] <SortaCore> is it av_frame_clone or av_frame_ref? [21:22:27 CET] <JEEB> the doc tells you if you look at both of then https://ffmpeg.org/doxygen/trunk/group__lavu__frame.html#ga46d6d32f6482a3e9… [21:22:32 CET] <JEEB> *them [21:23:01 CET] <JEEB> with ref you need to have another AVFrame already created, if you don't want to be calling that all the time, then clone handles that for you [21:23:12 CET] <JEEB> (or if you want to share an AVFrame instead of creating a new one) [21:31:27 CET] <SortaCore> hmm, I'm doing a while loop and pulling avframes until it can't get any, I want to keep the old... one... [21:31:36 CET] <SortaCore> why'd they all quit [21:32:00 CET] <SortaCore> s/old/first [21:32:13 CET] <JEEB> the docs tell you exactly what those functions do, thankfully :P [21:32:18 CET] <JEEB> also this is #ffmpeg stuff [21:32:32 CET] <SortaCore> yea, but whenever I ask there, people think I want commandline >.> [22:09:50 CET] <cone-040> ffmpeg 03Michael Niedermayer 07master:5e9a13a5a33b: avcodec/dirac_dwt: Fix integer overflows in COMPOSE_DAUB97* [22:09:51 CET] <cone-040> ffmpeg 03Michael Niedermayer 07master:610dd74502a5: avcodec/diracdsp: Fix integer overflow in PUT_SIGNED_RECT_CLAMPED() [23:02:50 CET] <cone-040> ffmpeg 03Gyan Doshi 07master:dc7d5f9f1904: avcodec/libx265 - Add named option to set profile [23:16:01 CET] <gander83> Using the ffmpeg loudnorm filter; having a hard time flushing it. I have tried avfilter_graph_request_oldest - but am getting only some of the buffered samples. Any ideas [23:27:25 CET] <SortaCore> send null stuff [23:43:15 CET] <tmm1> i'm trying to figure out why ffprobe reports field_order as interlaced on 720p mpeg2video [23:45:00 CET] <nevcairiel> the global field_order field isnt very reliable if the container doesnt provide it [23:54:56 CET] <tmm1> looks like an easy fix for the mpeg2 case [00:00:00 CET] --- Thu Dec 7 2017

1 0

ffmpeg.log.20171206
by burek 07 Dec '17

07 Dec '17

[00:00:14 CET] <sfan5> >supporting webm but not mkv [00:00:15 CET] <sfan5> smh [00:00:33 CET] <furq> browsers [00:00:36 CET] <furq> what do you expect [00:00:45 CET] <sfan5> more like Google [00:00:53 CET] <furq> firefox is the same [00:00:54 CET] <illegal> by support you mean the browser can't play .mkvs? [00:00:57 CET] <sfan5> damn [00:00:58 CET] <furq> illegal: yes [00:01:04 CET] <illegal> well yeah, even in firefox... [00:01:20 CET] <furq> chrome, firefox and edge don't support mkv, and apple doesn't support vp9 or opus or webm [00:01:21 CET] <alexpigment> i have a feeling MKV support is usually just because you can't make a blanket statement about supporting them, so don't even try [00:01:30 CET] <alexpigment> it's like saying "my program supports AVIs" [00:01:36 CET] <furq> i mean the same is true of mp4 [00:01:43 CET] <furq> browsers won't play my mpeg-4 part 2 and ac3 mp4s [00:01:46 CET] <furq> if i chose to make any [00:01:49 CET] <alexpigment> the official spec of MP4 is much more limited in terms of codecs [00:02:36 CET] <alexpigment> MKV is like "here's Cineform + Opus" [00:02:46 CET] <alexpigment> good luck finding enough players that support that combo [00:03:06 CET] <alexpigment> anyway, my two cents on the problem of MKV support [00:03:07 CET] <alexpigment> ;) [00:11:36 CET] <therage3> isn't mkv like [00:11:49 CET] <therage3> "ok, take whatever stream formats you want and shove them in here. you're welcome" [00:12:44 CET] <SortaCore> so uh [00:12:51 CET] <SortaCore> does rtsp h264 have a set pixel format or not [00:13:25 CET] <JEEB> in theory H.264 can dynamically change it dynamically but it always some /some/ [00:13:32 CET] <JEEB> you get that information as soon as you get the parameter sets [00:15:40 CET] <SortaCore> some some wat [00:18:45 CET] <SortaCore> so it can change in the middle of a h264 stream, but it's always set to something? [00:19:26 CET] <JEEB> yes [00:20:01 CET] <JEEB> H.264 and HEVC decoding works like this: 1) wait for parameter sets (the stuff that tells you WTF is in those coded pictures etc.) 2) decode pictures [00:20:16 CET] <DHE> that's the SPS in the headers? [00:20:45 CET] <JEEB> people call parameter sets the "headers" yes, and they're generally put into a separate thing in mp4/matroska [00:25:05 CET] <SortaCore> so I can't say "decode from whatever to NV12" without keeping whatever pix fmt it was, and then converting [00:27:37 CET] <SortaCore> atm I'm doing it src -> AVFrame, AVFrame sws_scale -> NV12 AVFrame, then passing to hwa encoder [00:28:32 CET] <sfan5> the decoder is going to give you whatever pixfmt it wants, there's nothing wrong with having to use sws_scale inbetween [00:30:25 CET] <DHE> the encoded picture does explicitly specify the colourspace used. it's why yuv420p is so strongly encouraged. many decoders just don't support anything else [00:30:32 CET] <DHE> so yes, conversion is often required between steps [00:34:48 CET] <JEEB> SortaCore: basically you can set up your filter chain when you get your first AVFrame from the decoder. if it's NV12 (for example since you mentioned it), great. Otherwise start building a filter chain and convert to whatever your requirements are [00:43:23 CET] <SortaCore> so is a filter chain just passing it to sws_scale [00:45:04 CET] <SortaCore> it just seems a bit dumb you get HWA decoders and you can't use most of them because they want NV12 [00:50:11 CET] <JEEB> hardware likes NV12/P010 while software has historically done planar [00:50:47 CET] <JEEB> NV12 is half-planar 4:2:0 (luma is separate, chroma packed), and what's called YUV420P in FFmpeg is fully planar 4:2:0 [00:51:24 CET] <JEEB> I think libx264 is one of the few SW encoders that takes in NV12 as well (no idea about the libavcodec wrapper, of course) [00:51:29 CET] <SortaCore> if I wanted to convert that "by hand" would that be a couple memcpy or lots of complex stuff [00:52:34 CET] <JEEB> so you have the planes separate in fully planar AAAA , BBBB , CCCC. NV12 is the same data but AAAA , BCBCBCBC [00:53:24 CET] <JEEB> so not exactly rocket science, but it's not just memcpys or switching pointers' values [00:53:39 CET] <JEEB> memcpys as in a single memcpy I mean [00:53:52 CET] <JEEB> you can of course do a crapload of memcpys if you really want but I don't recommend it [00:55:29 CET] <SortaCore> and there's no way to get the hardware encoder to do that? [00:56:19 CET] <SortaCore> really trying to reduce any cpu footprint [00:57:46 CET] <SortaCore> eventually, I'll need to put in rotate/flip to the image as well [00:57:52 CET] <SortaCore> for some reason the feeds are coming in upside-down [00:57:58 CET] <SortaCore> although VLC displays them right way up [01:01:48 CET] <SortaCore> ...oh I see [01:02:03 CET] <SortaCore> it's because BGR is right way up, but BMP24 expects pixels in reverse [01:02:31 CET] <SortaCore> "The pixel data is organized in rows from bottom to top and, within each row, from left to right. Each row is called a "scan line". If the image height is given as a negative number, then the rows are ordered from top to bottom." [01:02:40 CET] <SortaCore> oh, then easy fix by flipping image height [01:02:42 CET] <SortaCore> ima try that [01:05:45 CET] <JEEB> SortaCore: I don't think BGR or such define limitations on stride or height or width or so. use cases do. and yes, windows bitmaps go upside down [01:05:53 CET] <JEEB> so that's separate from pixel formats [01:07:38 CET] <SortaCore> I'm using a slightly dodgy way of copying files which uses an in-memory image file [01:07:53 CET] <SortaCore> copying files to rendering part, that is [01:08:52 CET] <SortaCore> it's an in-memory bitmap, since I thought that'd be the fastest and easiest file format to use [01:11:59 CET] <xylc> I tried to remux a video and audio file, but for some reason, the source gave them a starting offset of 1000 (Duration: 00:16:40.09, start: 1000.158000), which cuts off most of the video. Is it possible to make ffmpeg use a starting offset of 0? [01:12:46 CET] <xylc> Using mkvmerge results in a video that works fine (presumably because it ignores the starting offset), but I'm curious if it's possible to do this in ffmpeg as well [01:35:29 CET] <xylc> I managed to do it in a slightly hacky way, "-ss 0 -seek_timestamp -2147483648.000000 -i ..." [01:35:38 CET] <xylc> Not sure if there's any better way [03:49:20 CET] <TAFB> how do I get minutes in hls_segment_filename? [04:21:45 CET] <Rajko> is there any tutorial on how to use the h264 PARSER in ffmpeg ? [04:22:39 CET] <Rajko> how would i get all the pps/sps parameters out, as well as enumerating pictures and slices inside them ? [09:48:15 CET] <ayum> Hi, anyone know how to compile 32 bit ffmpeg executable on 64 bit linux? [09:57:45 CET] <DHE> --extra-cflags=-m32 --extra-ldflags=-m32 [09:58:17 CET] <DHE> note that you may have issues due to library availability. if your system doesn't have parity between 64 bit and 32 bit libraries some features may be missing or building may fail [10:09:02 CET] <illegal> Why did ffmpeg devs remove the auto detection of broken x264 files? [10:18:10 CET] <ayum> @DHE, yes, add above flags is necessary, also I added --cc="gcc -m32" option [10:18:32 CET] <ayum> otherwise, some object files still is 64 bit [10:18:50 CET] <DHE> yeah I'm looking at my own system. looks like I missed --arch=i686 [10:19:05 CET] <DHE> otherwise nasm is building 64 bit assembly objects [10:19:34 CET] <ayum> yes, I have to disable many libraries. I even disable h264 and h265 codec [10:20:04 CET] <ayum> but it's okay, I only need a i386 version ffmpeg for test purpose. I can use rawvideo codec [10:24:26 CET] <xylc> I would recommend checking arch linux PKGBUILDs https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lib32-ffmpeg [10:25:26 CET] <xylc> I found a lot of build troubles I had with various source packages were solved in some way in PKGBUILDs [10:25:47 CET] <xylc> Including how to build 32 bit, or enable a certain option :) [10:46:48 CET] <fx159159> Is my assumption correct that when I have a YUV picture where U and V are interleaved and U starts at 0xcc8e0001 and V at 0xcc8e0000 that the format is actually NV21? [11:32:33 CET] <dradakovic_> i have another question regarding streaming into mpegts. I try to output the .avi file on udp but it ends almost instantly as it outputs at very high speed. It says speed x178 [11:32:40 CET] <dradakovic_> How can i normalize that [11:33:16 CET] <DHE> add -re on the input [11:33:31 CET] <DHE> also I'm guessing you got bitrate issues again [11:34:03 CET] <dradakovic_> i dont even know how to solve my bitrate issues or what kind of issues i have anyway [11:38:37 CET] <dradakovic_> I am trying to send audio stream from file now as i cannot solve the http radio stream. [11:40:33 CET] <dradakovic_> @DHE would you mind telling me where i should put the -re option in my command [11:40:35 CET] <dradakovic_> https://pastebin.com/zxMeMPpv [11:40:43 CET] <dradakovic_> dont mind the comments in the command [11:40:55 CET] <DHE> that looks fine... [11:41:47 CET] <dradakovic_> But i get the: Option re (read input at native frame rate) cannot be applied to output url udp://232.50.50.2:5200?localaddr=172.20.188.170&pkt_size=188&fifo_size=1000000 [11:43:01 CET] <dradakovic_> you are trying to apply an input option to an output file or vice versa. Move this option before the file it belongs to. [11:43:18 CET] <dradakovic_> So i don't have a clue where to put it [11:44:10 CET] <DHE> so I have a problem with your command. you've \"escaped\" the quotes around your output URL which means that is literally the output filename, and "udp isn't a protocol [11:44:16 CET] <DHE> so this command wouldn't work in the first place [11:44:34 CET] <dradakovic_> ahhh yes [11:44:36 CET] <dradakovic_> got it [11:44:46 CET] <dradakovic_> thank you DHE [11:45:11 CET] <DHE> ./ffmpeg -re -i test.ts -c copy -f mpegts -pkt_size 1316 -bitrate 9000k -muxrate 9000k udp://239.30.20.10:12345 # this is the command I am using. works great. [11:46:16 CET] <dradakovic_> Got it, it works great. So now i know the problem. If i send the stream from the online http radio i get lost packets. If i send the stream from a file, everything is fine [11:46:39 CET] <dradakovic_> Will build on that and maybe ask here again for advice. Thank you again [11:50:15 CET] <dradakovic_> Hell yeah i sorted the issues up. Even with http streaming you need -re option. Oh man DHE i owe you a dinner [11:50:24 CET] <dradakovic_> You solved an issue i had for days [11:50:40 CET] <DHE> ... is the http file a live stream, or some pre-created mp4? that seems odd [11:51:03 CET] <BtbN> If you want to output a live stream, you pretty much always need -re, if you are streaming from a static input [11:51:10 CET] <BtbN> Otherwise it will go as fast as the CPU allows [11:51:47 CET] <dradakovic_> Exactly [11:52:01 CET] <DHE> yeah that's why I asked... the UDP -bitrate will throttle but the buffer size will easily overflow and ffmpeg fails [11:56:07 CET] <DHE> but even with -re, I very strongly recommend using -muxrate and -bitrate [14:23:29 CET] <ootje> anyone know if it is possible to tell by the ffproble --show_frames output if an mp4 has b-pyramid frames? (a method is described here, but it refers to nal_ref_idc which is not in the -show_frames output, http://www.ramugedia.com/hierarchical-b-frames-or-b-pyramid) [15:03:28 CET] <DHE> ootje: you can dump the timestamps of individual video frames and observe the pattern of the PTS values [15:04:07 CET] <ootje> DHE: i tried doing that, but it seems as if --show_frames show dts=pts and a steady increase.. --show_packets however shows dts!=pts [15:26:55 CET] <ootje> (seems -show_frames sorts the frames by order, ordering by pkt_pos brings back the original I guess) [15:42:52 CET] <DHE> yeah, show packets will be what you want... [15:43:49 CET] <DHE> or is it... because this might be easier with frames so you can see pict_type=B [15:45:47 CET] <DHE> nope.. [15:47:54 CET] <ootje> i did -show_packets and -show_frames and matched them with pkt_pos and pos ;) [15:48:10 CET] <DHE> so basically what you need to do is classify frames as either B or not-B. next for each group of B frames see if the PTS values are ascending/sequential or jumbled [15:48:31 CET] <DHE> this is where it would have been nice if show_frames gave you that information or if you would have to either infer it or cross-reference it [15:48:35 CET] <ootje> yes, will try that now.. [15:49:51 CET] <DHE> eg: with 8 b-frames in a row, the I,P,Bx8 pattern should have relative timestamps like 1, 10, 2,3,4,5,6,7,8. With b-pyramid it might be 1,10,4,2,6,7,5,3,9,8 [15:50:16 CET] <DHE> ... forgot '9' in the first pattern. bu you get the idea [15:52:22 CET] <ootje> the funny thing is there are no consequtive B frames in this file, IPPBPPBPPBPBPBPBPPB etc, so I guess that rules it out? [15:52:54 CET] <DHE> if bframes=1 then the setting is irrelevant [16:01:28 CET] <ootje> am i supposed to use the order output by -show_packets or -show_frames to evaluate this? [16:03:22 CET] <ootje> i was expecting to use the packet position in the file, as that probably reflects the stream order [16:06:17 CET] <DHE> I guess step 1 is to run show_frames to find consecutive frames with pict_type=B. note the pts timestamps. step 2: find the dts values from the packets. the pts values are your cross-reference fields [16:06:32 CET] <ootje> this is the output of my test script anyway, https://imgur.com/a/0pXwE [16:07:00 CET] <DHE> there is another possibility. if the encoder was x264, there's a good chance you can just run "strings" on the input file and search for x264 and see if it just tells you what the encoder settings were. [16:07:09 CET] <ootje> don't really see any consequtive B's any way, so i guess there's something else that's the issue here ( AE has an issue importing mp4s with B-pyramids, apparently ) [16:07:43 CET] <ootje> ..and it is resolved by disabling it when encoding the mp4s - otherwise suddenly there's a frame or two missing [16:08:28 CET] <ootje> (was just trying to write a preprocessor to check if i could tell if the file would be troublesome, or if i have to transcode to eg huffyuv, which i'd like to skip if i don't need to) [18:07:52 CET] <oerg866> Quick question, say i have two files that have the top and bottom fields of an interlaced video, how would i turn that back into a single interlaced video file? [18:13:16 CET] <durandal_1707> oerg866: ffmpeg -i top -i bottom -filter-complex interleave,weave output [18:13:24 CET] <oerg866> sick, thanks man [18:15:44 CET] <kepstin> in the case that doesn't work, you might have timestamp issues, which could be worked around by using the -r input option or settb+setpts filters. [18:16:30 CET] <oerg866> it's all gucci, working perfectly [18:20:26 CET] <oerg866> https://i.snag.gy/2WaJUH.jpg [18:20:36 CET] <oerg866> dunno if that's an ideal result but i'm pretty happy with that for now [18:20:56 CET] <furq> what filters did you use for that [18:21:35 CET] <oerg866> well first i split up the original interlaced video into two files for top and bottom fields and denoised those with hqdn3d [18:22:46 CET] <oerg866> simply because deinterlacing first would make the speccles bigger than they would be and denoising the interlaced video would mess up the interlacing because the hqdn3d isn't line based [18:23:36 CET] <oerg866> i still don't know if there's a line based blur filter / video low pass filter that i could apply here since the noise is so much higher bandwidth than the actual picture behind it :P [19:04:38 CET] <delsol_> Is there a way to do an x11grab using less CPU? currently using: ffmpeg -framerate 25 -video_size 1024x768 -f x11grab -i :0 -vcodec libx264 -crf 20 -preset ultrafast /video/12345.mkv [19:06:11 CET] <delsol_> but where I've got like 5-7 going at once, (:0, :1, :2, :3, :4, :5, :6) I end up with both CPU cores being 85%+ loaded and performance starts becoming unacceptable. [19:06:53 CET] <pzich> I don't think 7 x11grabs is ever going to be performant [19:07:09 CET] <delsol_> changing -crf 20 to -crf 40 with 6 recording at once, changed overall load basically none. [19:09:31 CET] <DHE> is that really where all the CPU time is going though? 7 instances of 25ps 1024x768 is going to use a lot of CPU power and RAM even at ultrafast presets [19:09:38 CET] <delsol_> but if each one could use 20% less CPU than it does now, then that would help push performance issues further into the future, or reduce the effect of more clients. [19:09:58 CET] <DHE> sounds like a job for perf (linux-specific tool) [19:11:00 CET] <delsol_> DHE: seems to be where it all goes according to HTOP. although the ffmpeg sub-threads are niced at 10, and seem to calm down a bit and give up their slice of time to allow the machine to not total drag-ass... [19:11:55 CET] <DHE> I suggested perf because it can help actually measure the amount of time going into the x11 code and the x264 code independently [19:12:38 CET] <delsol_> ahhhh..... gotcha, so then I could possibly see how much is x11grab load, and how much is x264 load [19:13:41 CET] <kepstin> delsol_: honestly, you probably have a pretty good use case for getting a quadro card so you can do hardware encoding. [19:13:58 CET] <kepstin> a single modern card should be able to encode all those streams at once. [19:14:37 CET] <JEEB> but does that help with the x11grab :P [19:14:48 CET] <kepstin> it wouldn't help if x11grab is the issue, yeah [19:15:16 CET] <kepstin> wait, "both CPU cores"... you're trying to do that many video streams on a dual-core box? what kind of cpu? [19:15:20 CET] <DHE> even without a quadro, you can do 2 instances on any (?) GeForce GTX 680 or higher. can confirm a 770 and 1060 both support it [19:15:43 CET] <DHE> oh... I didn't even notice he said that... oh god. yeah ultrafast is no miracle worker [19:16:14 CET] <JEEB> not to mention x11grab being a semi-unknown as well. [19:16:44 CET] <delsol_> kepstin: G3258 @3.2 [19:17:09 CET] <kepstin> delsol_: well, there's your problem [19:17:19 CET] <mampf> Hello =) I need some help. I try to compile ffmpeg 3.2 with only decoder h264_vdpau. But when I play with the options I only get no h264 decoder or h264 and h264_vdpau https://pastebin.com/nQ7S13b5 [19:17:53 CET] <kepstin> you simply don't have enough processing power to do the thing you seem to want to do. Can fix that by adding a hardware encoder or more cpu, which would help more is hard to determine. [19:17:53 CET] <JEEB> seven screen recordings on a haswell pentium (celeron) <3 [19:18:02 CET] <delsol_> kepstin: I've got more than 50 locations. moving to 50 i7's isn't exactly cheap. :) [19:18:40 CET] <delsol_> and most locations won't be doing more than 2 on the main machine... with the other encodings done on client machines and dumped into NFS share [19:18:41 CET] <DHE> mampf: sorry, the pure software h264 decoder is still a dependency of the vdpau decoder [19:18:41 CET] <kepstin> hmm. that haswell chip has quick sync, so that should help a bit [19:19:10 CET] <JEEB> kepstin: that kind of recommendation is always fun because then you end up with something else being the bottleneck and what do you say then? please recommend that stuff after it's been checked which parts are actually the bottlenecks in the end (f.ex. can he even handle 7 x11grabs :P) [19:19:10 CET] <kepstin> use it via the vaapi interface on linux, and it'll help a little :/ [19:19:40 CET] <delsol_> kepstin: Tried getting vaapi working, doesn't seem to work. [19:19:48 CET] <JEEB> after it's been checked that 7 x11grabs work, then you can start recommending things [19:20:13 CET] <mampf> Thanks! Is it possible to change the default decoder? I try to run Ultrastar a Singstar game on an orange pi. And Ultrastar choose the default decoder [19:20:19 CET] <mampf> from ffmpeg [19:20:35 CET] <delsol_> JEEB: I was doing 7 yesterday. Worked fine other than performance of the app being grabbed started turning to crap anytime something CPU intensive happened. [19:20:56 CET] <kepstin> delsol_: if you don't want to bother with the perf tool, you can check the x11grab performance separate from video encoding by just doing something like "ffmpeg -f x11grab -i :0 -f null -" a bunch of times and see your fps. [19:21:14 CET] <kepstin> using whatever x11grab options you'd be using otherwise [19:21:29 CET] <JEEB> yea, that way you'd check if whatever encoder you'd be using would be having the problems [19:21:45 CET] <delsol_> aha! grab framebuffer, dump to /dev/null without encoding [19:21:50 CET] <delsol_> good idea. [19:22:08 CET] <kepstin> that would check if the fb grab vs. video encoding is where perf problems are coming in, yeah. [19:22:33 CET] <JEEB> mampf: no, but if the API client has requirements you can always request another encoder, although hwaccels are somewhat special. also if that board has a mmal decoder it's shit but might work :P [19:22:52 CET] <JEEB> of course the mmal crap generally tends to want the whole screen with a measly overlay to itself [19:23:32 CET] <JEEB> (also I have no idea if the "orange pi" has anything to do with the raspberry pi boards but these comments assumed they have) [19:23:41 CET] <mampf> No it doesn't have mmal. OK I try to find a person which can develop this :D [19:24:15 CET] <mampf> It's a cheaper version than the raspberry pi or a faster :D [19:24:15 CET] <JEEB> ok, then you're fscked unless the hw decoding drivers offer some common and usable-from-FFmpeg interface [19:24:23 CET] <JEEB> welcome to ARM world [19:24:31 CET] <JEEB> everything sucks and sticks things that hurt into you [19:25:02 CET] <JEEB> android's mediacodec kind of got better after google started doing integration testing as requirements for passing their tests [19:25:22 CET] <mampf> it has h264_vdpau and runs 1080p in mpv player without any problems, but I need the same with ffmpeg :D [19:25:25 CET] <JEEB> before then HW accelerated decoding was the wild west, I think until 5 or so [19:25:34 CET] <mampf> Thank you very much for you help! [19:25:36 CET] <JEEB> mampf: huh, it has vdpau? [19:25:36 CET] <JEEB> wtf [19:25:46 CET] <JEEB> that's surprisingly sane if the drivers work [19:26:18 CET] <JEEB> mampf: but yes, someone will have to develop the app to make use of hwaccel decoding, which has some specialities that differ from sw decoding as you have to initialize the device contexts etc [19:26:20 CET] <mampf> It should decode 4k but I think there isn't an working driver idk. But it's advertised that it can run 4k :D [19:26:24 CET] <JEEB> but there are examples for that [19:26:35 CET] <JEEB> well yes of course they advertise everything the ASIC can do [19:26:40 CET] <JEEB> uhh [19:26:49 CET] <JEEB> how can it run h264_vdpau with mpv if it doesn't have a driver?! [19:26:51 CET] <mampf> yes that would be nice. It's made in pascal and I can't cde that :D [19:27:11 CET] <mampf> It has a 1080p driver I think but not a 4k [19:27:14 CET] <kepstin> mampf: see the caveats about vdpau at https://trac.ffmpeg.org/wiki/HWAccelIntro#VDPAU [19:27:35 CET] <kepstin> it's a presentation api for rendering to screen, if that's what you want great, but it's not a general decoding api. [19:27:48 CET] <JEEB> I think you could get the YCbCr from it? [19:27:56 CET] <JEEB> since mpv separates the decoding and the rendering [19:28:07 CET] <JEEB> also mpv utilizes FFmpeg's hwaccels for the decoding so then you just need your API client to utilize the hwaccel mampf [19:28:43 CET] <mampf> Yes I think the App just need to select hwaccel. [19:28:53 CET] <kepstin> hmm, i guess some gpus allow frame copy back from vdpau. [19:28:54 CET] <mampf> Thank you very much ;) [19:28:55 CET] <JEEB> yes, your app is an API client as far as FFmpeg is concerned [19:29:17 CET] <JEEB> kepstin: it seems like you can generally get YCbCr out of the VDPAU *decoder* as long as you don't enable deint or vdpau post-processing [19:29:40 CET] <JEEB> scroll down @ https://mpv.io/manual/master/#options-hwdec [19:29:50 CET] <JEEB> it has the possible downsides of various hwaccels there [19:30:40 CET] <mampf> Yes I think the only problem is that Ultrastar must select hwaccel [19:31:07 CET] <mampf> So if you nothing to do and you can write pascal fix this please :DD [19:31:08 CET] <mampf> https://github.com/UltraStar-Deluxe/USDX/tree/master/src/lib/ffmpeg-3.2 [19:57:42 CET] <jfmcarreira> heyyy guys [19:57:55 CET] <jfmcarreira> how can i get the number of frame in stream like .264 and .265 [19:58:40 CET] <JEEB> lavf doesn't handle that for you, you have to index it [19:58:47 CET] <JEEB> or lavc for that matter [19:59:02 CET] <JEEB> you can use something like ffms2 to get frame-exact access [19:59:11 CET] <JEEB> because it uses lavf to index the whole input [20:52:02 CET] <Timmey> Does anyone know what pgk I need for .srt encoder? My mac has it standard, but my raspberry2 (raspbian) is missing it. [21:01:12 CET] <BtbN> ffmpeg/libavcodec [21:25:13 CET] <SortaCore> Timmey: did you see btb's reply [21:31:18 CET] <Timmey> Yeah, so libavcodec should always be in standard right.. no need for extra flags? [21:31:55 CET] <Timmey> I just finished a new build instead of the apt-get pkg, so i'm gonna try it now. [21:35:05 CET] <BtbN> Possible that Debian removed it, because reasons [21:44:32 CET] <Timmey> @BtbN a manual install of added the srt encoder :) so it's working now! [21:45:23 CET] <Timmey> of ffmpeg* [22:23:34 CET] <therage3> for the native Native FFmpeg AAC Encoder, is there any recommended quality setting for audible transparency? [22:24:43 CET] <another> i think the wiki says >=128k [22:25:33 CET] <another> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio [22:26:39 CET] <therage3> another: thing is, that 128 figure is for Fraunhofer FDK AAC [22:26:58 CET] <therage3> that is specifically why I asked about the native encoder [22:27:27 CET] <klaxa> >aac usable range e 32Kbps (depending on profile and audio). Recommended range e 128Kbps [22:28:13 CET] <therage3> but is that true for the native encoder as well? because the 128 figure is there in https://trac.ffmpeg.org/wiki/Encode/AAC for the Fraunhofer encoder [22:28:43 CET] <klaxa> the line i pasted is specifically for the native encoder [22:29:02 CET] <klaxa> that page as well has a section about the native aac encoder [22:29:21 CET] <therage3> so they have the same recommended range? [22:29:27 CET] <therage3> huh, i was told the Fraunhofer one was better. weird [22:29:37 CET] <klaxa> it is [22:29:40 CET] <therage3> ... [22:29:47 CET] <klaxa> >Which encoder provides the best quality? [22:29:47 CET] <klaxa> >For AAC-LC: libfdk_aac > Native FFmpeg AAC encoder (aac). [22:29:51 CET] <klaxa> also on that page [22:30:37 CET] <therage3> indeed [22:30:48 CET] <therage3> so the same recommended range seems a bit odd to me, i dunno [22:30:59 CET] <klaxa> recommended does not mean it has the same quality at the same bitrate [22:31:15 CET] <therage3> i see, i guess it'll have a similar audible transparency then? [22:31:48 CET] <klaxa> tbh, i don't know you'd have to test that, maybe there are test series around where someone tested it [22:31:52 CET] <furq> there's not really any consensus because no proper listening tests have been done [22:31:59 CET] <therage3> furq: i figured [22:32:16 CET] <therage3> you know, i'm going to test this out myself in a bit [22:32:17 CET] <furq> i would probably go above 128k for cbr [22:32:29 CET] <furq> and i don't know if the builtin encoder has a usable vbr mode yet [22:32:41 CET] <therage3> the Wiki says it's experimental [22:32:48 CET] <therage3> and likely to get worse results than CBR [22:32:58 CET] <klaxa> >Note: -strict experimental (or -strict -2) was previously required for this encoder, but it is no longer experimental and these options are unnecessary since 5 December 2015. [22:33:02 CET] <furq> the wiki isn't always very up to date though [22:33:06 CET] <klaxa> >no longer experimental [22:33:08 CET] <BtbN> it's not experimental anymore for a while now [22:33:10 CET] <furq> he means vbr mode [22:33:10 CET] <ChocolateArmpits> native encoder performs quite bad at low bitrates and produces nasty artifacts, libfdk is far better if you intend to encode 64kbitps or lower audio [22:33:17 CET] <klaxa> oh [22:33:29 CET] <BtbN> You don't want to use AAC-LC for those low bitrates anyay [22:33:31 CET] <therage3> "Effective range for -q:a is around 0.1-2. This VBR is experimental and likely to get even worse results than the CBR." [22:33:33 CET] <BtbN> That's what HE-AAC exists for [22:33:34 CET] <klaxa> nvm then [22:33:37 CET] <therage3> I was talking about this :P [22:33:41 CET] <furq> yeah that was the last i heard [22:33:51 CET] <therage3> i see [22:33:52 CET] <JEEB> you should poke atomnuker regarding the "VBR" mode [22:33:52 CET] <furq> also some nice incomprehensible -q mapping there [22:34:04 CET] <ChocolateArmpits> BtbN, 32kbps-48kbps is acceptable for speech really [22:34:08 CET] <furq> for the first time ever [22:34:11 CET] <therage3> well, I understand it as 0.1 all the to 2, with 0.1 increments [22:34:16 CET] <therage3> I don't know if that's the intended meaning [22:34:19 CET] <BtbN> With AAC-LC? I'd rather use HE [22:34:41 CET] <furq> i just use fdk -vbr 5 anyway [22:34:49 CET] <klaxa> nowadays i just encode evertyhing in opus anyway [22:35:09 CET] <iranen> yes opus is best [22:35:20 CET] <ChocolateArmpits> well LC has higher compatibility [22:35:24 CET] <furq> yeah if you can do that then that's much simpler [22:36:11 CET] <furq> that page should probably be updated to include the audiotoolbox encoders on osx [22:38:45 CET] <alexpigment> furq: does ffmpeg take advantage of audiotoolbox? [22:38:54 CET] <alexpigment> (and videotoolbox for that matter) [22:39:00 CET] <alexpigment> ? [22:39:40 CET] <JEEB> it has some hwaccels for that IIRC [22:39:45 CET] <JEEB> &45 [22:40:16 CET] <alexpigment> interesting. i'll have to look into that at some point [22:40:27 CET] <BtbN> hwaccel for audio is hardly worth it [22:40:43 CET] <JEEB> VT was mostly what I was talking about [22:41:08 CET] <alexpigment> yeah, i was hoping audiotoolbox support meant that there was also videotoolbox support [22:41:13 CET] <alexpigment> which is obviously much more important [22:41:25 CET] <alexpigment> although an OS-level aac encoder is not a bad thing to have around [22:41:43 CET] <kepstin> even if it's not accelerated, using the system/quicktime aac encoder on a mac is probably a good idea, it's def. one of the better aac encoders around. [22:41:48 CET] <furq> yeah it's itunes aac on osx afaik [22:41:52 CET] <furq> which is the best aac encoder [22:42:06 CET] <furq> and it doesn't require a nonfree build [22:42:16 CET] <alexpigment> yep [22:50:34 CET] <alexpigment> speaking of hwaccel stuff [22:51:03 CET] <alexpigment> i get the feeling from the mailing list that the AMD VCE/AMF integration is at a standstill because of the header integration [22:51:36 CET] <alexpigment> does anyone know if there's more movement behind the scenes, or is it just the same status as the last message from friday? [22:52:47 CET] <jkqxz> Is was merged a week ago. [22:58:33 CET] <alexpigment> jkqxz: but that requires external headers still? [22:59:10 CET] <delsol> how do I make null output again to determine performance of x11grab vs performance of encoding? [22:59:15 CET] <alexpigment> i tried figuring out how to integrate that into the build script i was using but ultimately my lack of knowledge and/or lack of flexibility with the build script prevented me from geting anywhere [22:59:19 CET] <jkqxz> alexpigment: Just like every other package every. [23:00:27 CET] <jkqxz> s/every\./ever./ [23:00:32 CET] <alexpigment> jkqxz: just checked the new version of the build script and it looks like it's already in there [23:00:38 CET] <alexpigment> so nm then ;) [23:00:39 CET] <alexpigment> thanks [23:10:49 CET] <SortaCore> ah, x264 guys got back to me [23:11:22 CET] <SortaCore> "give more details about how you will sell this, and here's an NDA so you can never say about our little arrangement" [23:12:11 CET] Action: JEEB wonders if it's still corecodec or is it videolan handling it now [23:12:20 CET] <SortaCore> corecodec [23:13:18 CET] <SortaCore> I see in the forms they sent me, they didn't bother to fill in the parts that my email said already [23:13:30 CET] <JEEB> oh well [23:14:06 CET] <JEEB> and I wonder what the NDA is for, other than "we want to price each customer 100% separately" [23:14:21 CET] <SortaCore> possibly that [23:14:30 CET] <SortaCore> but it seems to be "every detail is NDA don't breathe a word" [23:14:47 CET] <JEEB> that's how NDAs are esp. in the US it seems [23:15:44 CET] <JEEB> where I work there's general law that if you hurt a company by speaking about internal stuff that doesn't need additional stuff. generally a "gentleman's agreement" or so [23:15:53 CET] <SortaCore> https://pastebin.com/raw/t3BT83rT [23:16:03 CET] <SortaCore> mm, I prefer that idea [23:16:14 CET] <JEEB> but then you get foreign corps buying companies they tend to try and stick NDAs [23:16:24 CET] <SortaCore> they could just have pricing and how the codecs work internally be NDA [23:16:36 CET] <SortaCore> seems a lot less suspicious than everything [23:16:37 CET] <JEEB> well the code workings are OSS anyways [23:16:51 CET] <JEEB> since what you get as far as I can tell is the same thing, just under a diff license [23:17:04 CET] <JEEB> + IIRC if you make changes to the core you have to give them back to the LLC [23:17:14 CET] <JEEB> and then the LLC will decide whether to incorporate them or not [23:17:36 CET] <JEEB> there were some people making MVC etc patches, but those were decided that to hone them up would require E_TOO_MUCH_EFFORT [23:17:51 CET] <JEEB> but the pastebins are still out there [23:18:41 CET] <JEEB> SortaCore: looks like standardo US lawyerisms [23:18:52 CET] <SortaCore> yea, that's my take too [23:19:01 CET] <SortaCore> not that I have much experience with licensing [23:19:21 CET] <JEEB> this is just the "business people got into the loop" kind of stuff [23:19:26 CET] <JEEB> IANAL though [23:19:50 CET] <SortaCore> whenever I'm presented with legal absolutely-no-two-ways-to-read-this-no-common-sense-required text, my brain just gives up and sums it to maximum possible [23:47:29 CET] <SortaCore> Intel Corp: "We would appreciate your response by: 12/15/2017" [23:47:41 CET] <SortaCore> that's not a real date [23:47:53 CET] <alexpigment> in the US it is [23:47:57 CET] <SortaCore> sounds like Trump mischief [23:48:02 CET] <alexpigment> MM/DD/YYYY [23:48:11 CET] <SortaCore> why would you order dates like that? [23:48:22 CET] <alexpigment> all standards are wrong tbh [23:48:30 CET] <alexpigment> it should be YYYY/MM/DD [23:48:37 CET] <alexpigment> and yet no one does that [23:49:10 CET] <SortaCore> yyyy:mm:dd:hh:mm:ss:ms:ns [23:49:19 CET] <alexpigment> sure [23:49:32 CET] <alexpigment> basically a format that can be sorted in a file system alphanumerically [23:49:47 CET] <SortaCore> don't file systems have date fields [23:49:56 CET] <SortaCore> which are internally binary [23:50:02 CET] <SortaCore> instead of textuals [23:50:48 CET] <alexpigment> here's what i'm saying: if you name a file MM-DD-YYYY.file or DD-MM-YYYY.file, neither will be in order over time [23:51:08 CET] <alexpigment> at least the current US standard works within a given year (but fails the next year) [23:51:18 CET] <alexpigment> the european standard fails every single month [23:51:27 CET] <alexpigment> YYYY-MM-DD is the only format that doesn't fail [23:52:06 CET] <SortaCore> sort(f => reverse(f.filename)); [23:52:15 CET] <SortaCore> 100% no problems [23:52:40 CET] <alexpigment> SortaCore: are you actually defending DD/MM/YYYY ? [23:52:49 CET] <alexpigment> i'm not sure if that's what you're doing [23:52:52 CET] <SortaCore> I'm vaguely obligated as I'm British [23:53:10 CET] <alexpigment> well i'm american and humble enough to know we're both wrong [23:53:10 CET] <SortaCore> we'll defend our ways to the death, but complain the whole time we use them [23:53:33 CET] <SortaCore> don't bring humility magic into this [23:53:45 CET] <alexpigment> fair enough ;) [23:54:01 CET] <SortaCore> it's something as soon as you say you have it, you don't have it [23:54:13 CET] <SortaCore> I mean, my humility is totally outmatched [23:54:26 CET] <furq> most of east asia uses YMD [23:54:28 CET] <SortaCore> no one can stand up to the sheer amount of humility I weild [23:54:43 CET] <SortaCore> (server dies and interrupt speech) [23:54:59 CET] <SortaCore> why do I have the one-character-must-be-typoed bug now? [23:55:04 CET] <furq> you're not as humble as me [23:55:12 CET] <furq> i am the most humble person who has ever lived [23:55:17 CET] <SortaCore> I could talk about my humility all day [23:55:26 CET] <SortaCore> and still not describe even a sliver of it [23:55:42 CET] <SortaCore> also, did today seem slow to you guys? [23:55:50 CET] <SortaCore> (bit off topic) [23:56:11 CET] <alexpigment> furq: good to know that east asia took the logical approach [23:57:02 CET] <alexpigment> SortaCore: actually yes. although I went through 210+ windows updates on a VM, so that kinda added to the slowness [23:58:40 CET] <SortaCore> I think we're in a temporal distortion, I'm getting reports from around the world about today feeling slow [00:00:00 CET] --- Thu Dec 7 2017

1 0