Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

July 2017

1 participants
62 discussions

ffmpeg-devel.log.20170705
by burek 06 Jul '17

06 Jul '17

[00:00:43 CEST] <atomnuker> so lets have some random companies who did no work whatsoever "protect" them and collect their share [01:08:23 CEST] <iive> actually, patents are a way worse. There have been awarder about million patents doing existing things but this time "on internet" or "on mobile" [01:08:35 CEST] <iive> awarded [03:20:39 CEST] <cone-184> ffmpeg 03Michael Niedermayer 07master:7592d97f1013: avcodec/h264_slice: Fix signed integer overflow [03:20:39 CEST] <cone-184> ffmpeg 03Michael Niedermayer 07master:c07af720984a: avcodec/wavpack: Fix invalid shift [04:03:52 CEST] <cone-184> ffmpeg 03James Almer 07master:440285474bb8: x86/utvideodsp: make restore_rgb_planes functions work on x86_32 [04:03:53 CEST] <cone-184> ffmpeg 03James Almer 07master:bcbe9e444790: x86/sbrdsp: zero extend m_max in apply_noise_main [04:03:54 CEST] <cone-184> ffmpeg 03James Almer 07master:3d3243577cfd: checkasm: use declare_func_float() in sbrdsp sum_square test [04:37:44 CEST] <cone-184> ffmpeg 03James Almer 07master:24bb7db40378: x86/sbrdsp: remove unnecessary sign extend instruction in apply_noise_main [04:38:21 CEST] <cone-184> ffmpeg 03Michael Niedermayer 07master:c8cfbc6629c1: avcodec/hevcdec: do not let updated extradata corrupt state [05:17:22 CEST] <cone-184> ffmpeg 03Steven Liu 07master:d01b8f8683df: avformat/hlsenc: optimize help message default value. [05:21:15 CEST] <cone-184> ffmpeg 03Steven Liu 07master:1fe40e73a67c: avformat/hlsenc: copy codec_tag when stream copy [11:51:11 CEST] <durandal_1707> atomnuker: see my aac branch on github, now i get segfaults [12:33:48 CEST] <iive> durandal_1707: link? [12:37:05 CEST] <durandal_1707> iive: https://github.com/richardpl/FFmpeg/tree/aac [12:48:19 CEST] <funman> doing hbrmt2bmd + obe on same source [12:48:33 CEST] <kierank> funman: wrong channel [12:48:49 CEST] Action: funman blames his huge hands [12:49:03 CEST] <iive> durandal_1707: does it segfault on 64 bit or 32? [12:50:11 CEST] <durandal_1707> 64bit in sbrdsp asm [12:53:09 CEST] <nevcairiel> i'm sure james will fix it when he wakes up [13:03:13 CEST] <iive> durandal_1707: well, there are 2-3 changes, one removes a sign extend, another uses declare float [13:05:00 CEST] <iive> asm check specially feeds garbade, and the sign extend could be there to remove it. [13:05:12 CEST] <iive> garbage [13:13:30 CEST] <iive> durandal_1707: where and when does it segfault? [14:22:57 CEST] <J_Darnley> dammit. Why do I always pick the moments when BBB is offline to ask him a question? [14:41:21 CEST] <wm4> well he goes offline all the time [14:41:35 CEST] <kierank> J_Darnley: it is holidays in usa [14:42:19 CEST] <J_Darnley> I guess they need another day to recover from their collective booze and fireworks hangovers [14:45:01 CEST] <J_Darnley> heh. speak of the devil [14:45:59 CEST] <J_Darnley> BBB: Do you have a website that we should link to in another blog post? [14:46:34 CEST] <BBB> did you know my nickname (BBB) was originally Beelzebubu, which is a wordplay on Beelzebub, the devil? :-p [14:46:59 CEST] <BBB> (BeelzeBuBu -> BBB, because Im now old and boring) [14:47:14 CEST] <BBB> as for website, Id link to this: https://blogs.gnome.org/rbultje/ [14:47:15 CEST] <J_Darnley> You mean you're not a fan of the Blender video project? I am gutted(!) [14:47:25 CEST] <BBB> sorry [14:47:42 CEST] <BBB> its not a very good test video, CGI after all [14:49:47 CEST] <kierank> J_Darnley: I already linked to that [14:50:14 CEST] <J_Darnley> I missed that [15:32:57 CEST] <kierank> wm4: wtf is up with that api patch [15:33:16 CEST] <wm4> you mean the compat one? [15:33:21 CEST] <kierank> yeah [15:33:32 CEST] <kierank> zero byte packets [15:33:48 CEST] <kierank> wtf [15:33:48 CEST] <cone-820> ffmpeg 03James Almer 07master:9d5e81d3b160: Revert "x86/sbrdsp: remove unnecessary sign extend instruction in apply_noise_main" [15:33:48 CEST] <wm4> basically the old API ate any shit you gave it [15:33:51 CEST] <wm4> the new API is a bit stricter [15:34:01 CEST] <JEEB> :D [15:36:08 CEST] <wm4> that reminds me (unfortunately) that I volunteered to push libturing [15:36:54 CEST] <TMM> is the actual implementation of libturing any good? [15:37:21 CEST] <TMM> I read the patchset and the libturing website and I'm not entirely sure what it's FOR in the context of ffmpeg [15:37:43 CEST] <BBB> its a hevc encoder, right? [15:38:11 CEST] <wm4> + #if defined(_MSC_VER) [15:38:11 CEST] <wm4> +#define TURING_API_IMPORTS 1 [15:38:11 CEST] <wm4> +#endif [15:38:13 CEST] <wm4> ....wat [15:38:27 CEST] <BBB> welcome to microsft symbol exports [15:38:31 CEST] <BBB> I love that stuff [15:38:55 CEST] <TMM> BBB, it is a hevc encoder indeed, but, wouldn't that be the 3rd one in ffmpeg? [15:38:56 CEST] <JEEB> TMM: "we made a research encoder like kvazaar at the BBC" [15:38:57 CEST] <jamrial> then why is its entry in allcodecs.c before x265? [15:38:59 CEST] <wm4> every lib that actually uses that (you don't have to) has the decency to do it transparently/internally [15:39:25 CEST] <jamrial> it should be below, in the "external libraries, that shouldn't be used by default" list [15:39:28 CEST] <JEEB> libkvazaar is being developed by a Finnish university, while libturing is BBC R&D :D [15:39:30 CEST] <BBB> jamrial: alphabetical? [15:39:57 CEST] <jamrial> BBB: there's a section for libraries that should not be used if another better one is also available [15:40:04 CEST] <TMM> I'm not trying to say it shouldn't be merged or anything [15:40:05 CEST] <jamrial> that's where libopen264 is, for example [15:40:15 CEST] <JEEB> what jamrial notes is valid tho [15:40:17 CEST] <TMM> I really have no stake in this, I just wondered why it was there I suppose [15:40:21 CEST] <BBB> jamrial: review ;) [15:40:24 CEST] <BBB> I dont care about hevc :-p [15:40:34 CEST] <JEEB> TMM: because people want their R&D stuff to be "It's usable from FFmpeg!" [15:40:48 CEST] <jamrial> thign is, i think i did mention it long ago in one of the first iterations of this patch... [15:40:51 CEST] <TMM> JEEB, I guess that does help with getting testers [15:41:06 CEST] <wm4> turingcodec/boost/libs/program_options/src/../../../boost/function/function_base.hpp:308:13: warning: placement new constructing an object of type boost::detail::function::functor_manager_common<boost::_bi::bind_t<std::vector<boost::program_options::basic_option<char> >, boost::_mfi::mf1<std::vector<boost::program_options::basic_option<char> >, boost::program_options::detail::cmdline, std::vector<std::__cxx11::basic_string<char> >&> [15:41:06 CEST] <wm4> , boost::_bi::list2<boost::_bi::value<boost::program_options::detail::cmdline*>, boost::arg<1> > > >::functor_type {aka boost::_bi::bind_t<std::vector<boost::program_options::basic_option<char> >, boost::_mfi::mf1<std::vector<boost::program_options::basic_option<char> >, boost::program_options::detail::cmdline, std::vector<std::__cxx11::basic_string<char> >&>, boost::_bi::list2<boost::_bi::value<boost::program_options::detail::cmdline*>, [15:41:07 CEST] <wm4> boost::arg<1> > >} and size 24 in a region of type char and size 1 [-Wplacement-new=] [15:41:10 CEST] <wm4> nice start [15:41:20 CEST] <jamrial> >boost [15:41:23 CEST] <BBB> boost \o/ [15:41:27 CEST] <nevcairiel> its a warning, just ignore it =p [15:41:46 CEST] <RiCON> they'd get the same amount of testers if they made a simple turingenc.exe that used lavf/lavc like x264 [15:41:48 CEST] <BBB> jamrial: ignoring reviews means unfortunately we have to re-review it [15:41:50 CEST] <nevcairiel> template related warnings can look rather frightening [15:41:50 CEST] <TMM> that's a pretty dire warning though [15:42:30 CEST] <TMM> if you're trying to placement new into a region where it won't fit and you place another thing next to it you may end up with interesting results [15:42:42 CEST] <JEEB> TMM: it's for advertisement :P [15:43:04 CEST] <JEEB> maybe extra testers but not many will build libturing to begin with [15:43:13 CEST] <TMM> ah, this warning is actually a boost bug [15:43:31 CEST] <TMM> and it's largely cosmetic, apparently the target for the placement is the middle of a char[] [15:44:06 CEST] <TMM> still... use the goddamn language so you can get the compiler to help you avoid bad fuckups [15:44:34 CEST] <BBB> lol [15:44:42 CEST] <iive> why boost?! WHY?! [15:44:57 CEST] <nevcairiel> compilers arent actually as smart as you seem to give them credit for =p [15:45:21 CEST] <TMM> nevcairiel, they *can* help in the c++ case if you provide correct typing infos etc [15:45:36 CEST] <TMM> And rustc can really help you a lot if you give it correct metadata :) [15:45:44 CEST] <TMM> otoh, rustc will tell you to go fuck yourself if you don't [15:45:49 CEST] <TMM> which is nice [15:45:59 CEST] <wm4> make install will install stuff like lib/boost/libboost_filesystem.a [15:46:20 CEST] <TMM> wm4, can't libturing build against OS supplied boost? [15:46:22 CEST] <wm4> ubitux: ok to push that br tag patch? [15:46:30 CEST] <wm4> TMM: who knows [15:46:55 CEST] <TMM> I mean, shipping boost with your app is fine and all, but if you detect system headers you should really use them imho [15:47:41 CEST] <BBB> imagine if diego got his hands on libturing [15:47:57 CEST] <BBB> they should really have sent this patch to libav-devel also [15:48:07 CEST] <nevcairiel> maybe he would die of disgust? [15:48:08 CEST] <TMM> I thought libav was done now? [15:48:14 CEST] <BBB> I think it wouldve significantly enhanced the code quality of turing [15:48:20 CEST] <BBB> (by some metrics) [15:48:33 CEST] <BBB> which is probably what they were hoping for by integrating in ffmpeg in the first place [15:48:36 CEST] <TMM> oh, libav still lives? [15:48:48 CEST] <BBB> TMM: I believe it still exists, I dont know, some poeple here contribute to it I believe [15:48:49 CEST] <nevcairiel> its not our job to judge the quality of the code of that library, or even include that in a decision if we want to support it or not, its not like we work on their code [15:49:04 CEST] <BBB> nevcairiel: I agree, I think [15:49:18 CEST] <wm4> BBB: almost all recent hw transcode stuff you see in ffmpeg was developed in Libav [15:49:21 CEST] <TMM> BBB, urgh, does that mean I should send my patches to the libav devel list too? [15:49:54 CEST] <BBB> TMM: & thats a politically loaded question that Im going to stay out of :-p [15:49:56 CEST] <JEEB> depends on if you care about libav [15:50:06 CEST] <TMM> BBB, sorry, I really didn't mean to [15:50:07 CEST] <nevcairiel> wm4: thats all they do lately though, hw stuff and api stuff, everything else seems to basically not improve [15:50:22 CEST] <BBB> TMM: dont worry, its fine, dont take it negatively, I didnt mean it that way [15:50:24 CEST] <TMM> JEEB, I don't know if I should or not I suppose, is it actually used? I thought all the linux distros switched back to ffmpeg [15:50:42 CEST] <TMM> Linux distros is all I care about :) [15:50:44 CEST] <JEEB> I see a lot of people not caring about Libav, and then there's a few people who use Libav in $dayjob or so which is why they throw the patch to both sides, or just libav. [15:50:51 CEST] <nevcairiel> its probably just handbrake that still uses libav for some reason, not sure anyone else does [15:50:52 CEST] <jamrial> nevcairiel: the api that expects a command line as parameter deserves to be judged :p [15:51:03 CEST] <BBB> TMM: its a personal decision and there are some valid reasons to do it, and some valid reasons not to do it. nobody tells you what to do, and both decisions would be fine [15:51:13 CEST] <JEEB> BBB: yup [15:51:24 CEST] <nevcairiel> jamrial: like i said on the ML, thats basically how x264 and x265 work as well for anything beyond the absolute most basic options =p [15:51:44 CEST] <nevcairiel> we hand-off strings to their option parsing [15:52:23 CEST] <jamrial> fair enough [15:52:26 CEST] <JEEB> yup [15:52:31 CEST] <wm4> ffmpeg libs also work this way [15:52:33 CEST] <BBB> TMM: I believe most distros use ffmpeg nowadays, yes [15:52:36 CEST] <wm4> which I dislike btw. [15:52:56 CEST] <nevcairiel> lavfi graph building with the string thingys does feel awkward [15:53:07 CEST] <TMM> ghe, libav has a cinepak *encoder*? [15:53:08 CEST] <TMM> crazy [15:53:14 CEST] <nevcairiel> someone made a CLI api and then forgot to actually make a C api [15:53:29 CEST] <wm4> TMM: isn't it ported from ffmpeg's? [15:53:32 CEST] <nevcairiel> it is [15:54:02 CEST] <TMM> Ah, I didn't notice it before in ffmpeg I guess, I should check there first next time :) [15:54:28 CEST] <nevcairiel> they rarely have original things these days, outside of api changes [15:54:39 CEST] <jamrial> curious how they get rid of toy en/decoder snow then add toy encoder cinepak :p [15:55:02 CEST] <nevcairiel> i didnt feel like starting a troll thread by asking whats the motivation of importing it [15:55:07 CEST] <TMM> cinepak is super relevant! If you want to convert a DVD to watch on your 1992 mac it's ESSENTIAL [15:57:10 CEST] <thardin> I'm surprised someone bothered to complete it [15:57:32 CEST] <thardin> I wrote it as a bit of a joke, then someone took it seriously [15:57:42 CEST] <TMM> I kind of want to write an MVE encoder .... :-) [15:57:53 CEST] <thardin> I think there's one floating around already [15:58:04 CEST] <thardin> for encoding videos for fallout, baldur's gate etc [15:58:19 CEST] <TMM> probably not for the old-ass mve frame formats I reverse engineered [15:58:39 CEST] <TMM> since nobody knew how they worked :) [15:58:50 CEST] <thardin> cinepak is useful for that early-90's a e s t h e t i c [15:59:19 CEST] <TMM> may be useful for people who do fan translations of old games for scummvm too [15:59:24 CEST] <jamrial> glorious 15 fps 320x240 cutscenes? [15:59:33 CEST] <atomnuker> BBB: nonsense, taking no sides and saying there are reasons for and agains is how you worsen the issue [15:59:39 CEST] <wm4> Version: 72b085e [15:59:40 CEST] <TMM> although, I suppose you may as well use a modern codec then [15:59:50 CEST] <wm4> libturing's .pc version field contains garbage [15:59:54 CEST] <wm4> a git hash is unusable [16:00:26 CEST] <TMM> Why do people even think that's acceptable? People do it internally here all the time too it's maddening because figuring out what's actually the LATEST version is fucking impossible [16:00:45 CEST] <BBB> atomnuker: I dont think the situation can be improved [16:00:51 CEST] Action: TMM shares your frustration :) [16:01:01 CEST] <BBB> its like most western countries political climate, its totally screwed up and I dont know how to fix it [16:01:17 CEST] <BBB> so I ignore it and move on to actually doing other stuff, like coding [16:05:01 CEST] <wm4> also why is the start of config.log full of configure boilerplate spam [16:05:08 CEST] <atomnuker> BBB: it'll fix itself in due time, just don't make people doubt themselves [16:05:11 CEST] <wm4> make sit so hard to figure out the simplest things [16:08:07 CEST] <BBB> atomnuker: okiedokie [16:08:15 CEST] <BBB> TMM: I personally dont contribute to libav, if that helps [16:36:45 CEST] <iive> TMM: how essential is boost for libturing? how much effort would it be to remove that dependency? [16:45:49 CEST] <iive> my distro does come with libboost, however every minor update breaks all programs that I've compiled and that depend on it. [16:46:08 CEST] <iive> libstdc++ at least provides some backward compatibility. [16:52:26 CEST] <Shiz> W [16:57:57 CEST] <TMM> iive, I don't know I'm not a libturing developer. But in general a program that depends on boost:: will not be super easy to move off of it. If it was written in an ancient c++ it's usually a bit easier as a lot of boost features made it into newer c++ versions. [16:59:53 CEST] <iive> oh, since you were talking about sending libturing integration patch to libav, i assumed you are one of the developers. [17:00:07 CEST] <TMM> iive, I was just talking about the patch in general, sorry. [17:11:10 CEST] <wm4> jkqxz: so, any idea how the DRM hwctx should be done? or is your latest patch still how you want to do it? [17:21:23 CEST] <jkqxz> wm4: What changes are you wanting? I was assuming LongChair would finish the RockChip decoder using it (possibly with some minor fixups to the DRM bit), and then they would commit together. [17:22:37 CEST] <wm4> well he made a suggestion [17:22:54 CEST] <wm4> which looked ok to me [17:22:59 CEST] <wm4> he claimed that it'd be simpler [17:23:40 CEST] <jkqxz> Going back to the nested arrays? I'm fine with that. [17:24:37 CEST] <jkqxz> Do you want me to send a new version using that? [17:27:08 CEST] <wm4> sure [17:27:38 CEST] <wm4> well my complaint about the nested arrays is that they can bloat quickly, not because I dislike them [17:27:57 CEST] <wm4> so if we hardcode them to size 4, I'm fine with it [17:45:03 CEST] <ubitux> wm4: if it works with the trailing / form [17:45:20 CEST] <ubitux> please. [17:45:28 CEST] <ubitux> (re: br tag) [17:47:44 CEST] <wm4> what does the trailing form do? [17:48:11 CEST] <wm4> does it exist in your subtitle corpus? [18:15:39 CEST] <ubitux> wm4: it will take a while to check but i will in a moment [18:18:08 CEST] <ubitux> wm4: the trailing form is just the html standard for standalone tags btw [18:19:02 CEST] <ubitux> or maybe that was the xhtml thing [18:19:36 CEST] <ubitux> that has nothing to do with subtitles but i know that typically graphviz will error out if you use instead of (they also use some kind of html markup system) [18:19:45 CEST] <kierank> is it intentional for multi field closed captions to be broken [18:20:12 CEST] <ubitux> (https://stackoverflow.com/questions/1946426/html-5-is-it-br-br-or-br) [18:22:22 CEST] <RiCON> and shouldn't show up in srt [18:22:31 CEST] <RiCON> (neither should , though) [18:22:42 CEST] <wm4> and ? [18:22:57 CEST] <RiCON> that never shows up [18:23:00 CEST] <RiCON> it's like <img> [18:23:12 CEST] <ubitux> yeah, br, hr, img, ... [18:23:20 CEST] <ubitux> all standalone tags could have a trailing / [18:23:59 CEST] <RiCON> isn't even valid xhtml or html, iirc [18:24:08 CEST] <ubitux> you mean without space? [18:24:11 CEST] <RiCON> yeah [18:24:54 CEST] <RiCON> "Since some earlier browsers that would parse XHTML as earlier HTML would choke on but not on such extra whitespace is the norm, for backwards compatibility (more backwards kludging it, but still...)." [18:25:00 CEST] <RiCON> "compatibility" [18:25:57 CEST] <thardin> should be valid xhtml. it is how you do it in normal xml at least [18:26:11 CEST] <RiCON> anyway, it could be parsed for compatibility-sake, unless it unnecessarily adds complexity [18:26:17 CEST] <thardin> xmllint certainly thinks so at least [19:05:26 CEST] <kierank> how do I return side data from a frame that isn't decoded [19:05:29 CEST] <kierank> field 1? [19:48:21 CEST] <durandal_1707> is alex converse on irc? [19:49:03 CEST] <nevcairiel> durandal_1707: its peloverde [19:50:44 CEST] <peloverde> durandal_1707: pong [19:51:43 CEST] <durandal_1707> peloverde: how good do you know aac 960/120 mdct? [19:52:14 CEST] <peloverde> pretty well [19:59:33 CEST] <peloverde> if this is about the scale though, taking some educated guesses will be way faster than reasoning from proper principles [20:01:44 CEST] <durandal_1707> peloverde: there are artifacts, even with 0 to 0 sequence [20:02:46 CEST] <durandal_1707> see on: https://github.com/richardpl/FFmpeg/tree/aac [20:05:40 CEST] <peloverde> what do you mean by 0 to 0? [20:10:55 CEST] <durandal_1707> peloverde: long to long [20:11:06 CEST] <durandal_1707> define is 0 [20:12:44 CEST] <peloverde> if you plug in the reference transfom does it work? I can take a better look when I'm back at my desk. [20:16:10 CEST] <durandal_1707> i tried one from faad2 and got gibberish, completly white spectrum [20:16:38 CEST] <durandal_1707> perhaps i did something wrong [20:20:29 CEST] <peloverde> I think it's way more likely that something else is a little off than that the transform is busted. The transfom is one of the few things that we do test in isolation. [20:33:04 CEST] <ubitux> wm4: i'm uncompressing the data again, it takes some time, then i'll run the research [21:45:13 CEST] <jpabq> Is there anything I need to be doing to get https://patchwork.ffmpeg.org/patch/3860/ committed? [21:54:55 CEST] <cone-746> ffmpeg 03James Almer 07master:9878935927c5: fate: add fate-checkasm-sbrdsp target [21:54:55 CEST] <cone-746> ffmpeg 03John Stebbins 07master:a188942efe7b: movenc: simplify codec_tag lookup [21:54:55 CEST] <cone-746> ffmpeg 03John Stebbins 07master:f55c42c14655: movenc: move tags definitions to where they are used [21:54:55 CEST] <cone-746> ffmpeg 03John Stebbins 07master:da002b99b335: movenc: write correct format hvcc when tag is hvc1 [21:54:55 CEST] <cone-746> ffmpeg 03John Stebbins 07master:62861660fa4a: movenc: allow alternative hvc1 h.265 codec tag [21:56:11 CEST] <cone-746> ffmpeg 03John Stebbins 07master:e199d90da647: movenc: simplify codec_tag lookup [21:56:12 CEST] <cone-746> ffmpeg 03John Stebbins 07master:38d808d72e39: movenc: move tags definitions to where they are used [21:56:13 CEST] <cone-746> ffmpeg 03John Stebbins 07master:974d508e5710: movenc: write correct format hvcc when tag is hvc1 [21:56:14 CEST] <cone-746> ffmpeg 03John Stebbins 07master:369a3e111cb8: movenc: allow alternative hvc1 h.265 codec tag [21:56:44 CEST] <jamrial> wonder if that's what happens when two people try to push at the exact same time... [21:57:24 CEST] <BtbN> what? [21:57:29 CEST] <nevcairiel> only one of those sets of changes arrived [21:57:30 CEST] <nevcairiel> so weird [21:57:54 CEST] <jamrial> yeah, i pushed my commit there, but cone reported the five from derek as well [21:58:30 CEST] <BtbN> the push hook probably runs earlier than actually pushing the commits? [21:58:31 CEST] <jamrial> i assume we pushed at the same time, and while only one succeded the other push somehow "got through" in some way [21:58:44 CEST] <jamrial> derek then rebased and pushed again, and cone reported it as well [22:00:08 CEST] <jamrial> i almost panicked thinking i somehow made a push with a dirty tree full of unrelated commits :p [22:05:45 CEST] <durandal_1707> jpabq: ping it on ml [22:06:00 CEST] <jpabq> durandal_1707: Okay, will do. [22:24:57 CEST] <durandal_1707> atomnuker: have you installed new system? [22:32:49 CEST] <iive> durandal_1707: i can recommend you `edb` if you need to debug asm code. [22:33:26 CEST] <durandal_1707> what is tthat? [23:01:45 CEST] <atomnuker> durandal_1707: no, also my router's messed up so internet is crappy, my thoat hurts, I can't hear well with my left ear which also hurts and I can't sleep well [23:02:44 CEST] <atomnuker> I'm not a very happy person right now [23:03:13 CEST] <durandal_1707> atomnuker: seriously? just take few blue pills [23:05:11 CEST] <durandal_1707> sleep well and dontt code at home [23:06:29 CEST] <atomnuker> oh yeah, and I really want to get off this rock and move to someplace in Europe [23:09:58 CEST] <atomnuker> where ISPs give you either an ethernet cable or a fiber with a media converter rather than router tracking everything to room humidity [23:10:42 CEST] <durandal_1707> where are you? [23:11:08 CEST] <iive> sounds like usa [23:11:08 CEST] <atomnuker> but can't blame them for giving people routers, because PHONE CABLES aren't really where packets are meant to go [23:11:31 CEST] <atomnuker> iive: its not that bad thankfully, I'm in the UK [23:12:09 CEST] <iive> :P [23:15:22 CEST] <iive> british telecon was the big government monopoly, afair [23:15:31 CEST] <iive> telecom... [23:26:27 CEST] <cone-746> ffmpeg 03Azamat H. Hackimov 07master:121ab69c9d06: libavformat/gdv: Fix parsing for soundless video [23:36:17 CEST] <kierank> atomnuker: no virgin media where you live? [23:37:16 CEST] <atomnuker> bt was faster and cheaper [23:37:53 CEST] <atomnuker> (seriously, a phone cable? and for TV they give you a box which requires an antenna) [23:38:31 CEST] <atomnuker> and you also need an amplifier because the signal isn't good enough and even then its still not good enough [23:39:08 CEST] <atomnuker> its like I've gone somewhere rural with phone cables and TV antenna amplifiers [23:39:49 CEST] <BtbN> atomnuker, you wish. The standard in europe is to use ancient two-wire phone lines and squish as much bandwidth through them as possible, with crappy plaster-routers. [23:40:03 CEST] <BtbN> Germany is especially bad [23:40:15 CEST] <JEEB> le VDSL [23:40:30 CEST] <kierank> atomnuker: virgin does 200mbps now [23:40:51 CEST] <BtbN> Ethernet/Fiber is the absolute exception [23:41:09 CEST] <atomnuker> oh yeah and bt by default disable using a non-dhcp given DNS [23:41:26 CEST] <kierank> Huh, I don't use their crappy dns [23:41:52 CEST] <atomnuker> I had to login to the account page on their website and wait a few hours until it was disabled [23:45:19 CEST] <atomnuker> what has the world come down to, I remember getting 50mbps symmetric back in 2005 where the ISP would have an FTP server filled with movies and games and such [23:45:51 CEST] <atomnuker> and ISPs would compete to see who can amass the largest collection and attract the most customers [23:46:34 CEST] <BtbN> that sound mildly illegal [23:47:10 CEST] <BtbN> Something amazing the German Telekom does: Block foreign SMTP servers. [23:47:11 CEST] <atomnuker> (they usually hijacked chinese websites like gamez.com.tw or magnet.co.jp via their DNS to a look-alike page with listings and search of what they had) [23:47:40 CEST] <BtbN> So if you want to use SMTP to something that's not their Mail-Server, you need to unlock the specific server first [23:47:41 CEST] <JEEB> lol [23:48:04 CEST] <BtbN> And it's a per-server unlock, not a general "Let me use SMTP" [23:48:53 CEST] <atomnuker> sure its illegal, but back then there was no danger for ISPs which were never ever big enough to cover an entire city of 300 000 people [23:49:35 CEST] <atomnuker> and who'd report them, everyone was happy to be getting all this stuff and took it for granted [23:51:42 CEST] <atomnuker> oh and you could get even more stuff out of people because everyone was wired directly and could see each other and everyone was on the default windows WORKGROUP workgroup [23:53:05 CEST] <atomnuker> windows didn't even have a firewall or malware detector or antivirus by default so sasser spread like wildfire [00:00:00 CEST] --- Thu Jul 6 2017

1 0

ffmpeg.log.20170705
by burek 06 Jul '17

06 Jul '17

[00:01:36 CEST] <SpeakerToMeat> uuhhhh.... https://pastebin.com/aUSPe62q [00:20:10 CEST] <SpeakerToMeat> Ok I give up for today, the debian build system is playing tricks on me with the "flavor" hack on the rules file.... I'll keep on trying un thu if I'm alive [00:21:09 CEST] <furq> i wouldn't bother trying to build a package [00:21:15 CEST] <furq> just patch git master and install to /usr/local [00:33:59 CEST] <Yawnny> Hey all.. I'm trying to convert a VFR video to a CFR one.. I'm trying to frankenstein a script together but having mixed results. [00:34:07 CEST] <Yawnny> My current script: ffmpeg -i (input file).mp4 -c:v dnxhd -b:v 290M -c:a pcm_s16le -r 60 (output).mxf [00:34:22 CEST] <Yawnny> I was told dnhxd would be the way to go.. and maybe .mov at the end [00:34:43 CEST] <Yawnny> With my filenames the script looks like: ffmpeg.exe -i ("C:\Users\Yawnny\Desktop\test\encodeThis_withFFMPEG.mp4").mp4 -c:v dnxhd -b:v 290M -c:a pcm_s16le -r 29.97 ("C:\Edit\converted.mov").mov [00:35:15 CEST] <Yawnny> But then CMD opens and closes immediately..I have a feeling I'm fudging it up with the filenames and whether I need quotes or not, etc... [00:36:30 CEST] <Yawnny> After I tried handbrake on a long 4 hour video with mixed succsess the advice given to me was: "I'd suggest looking at a fuller FFMPEG encode over handbrake - and encode to dnxhr. Audio at 48k uncompressed please." [00:36:53 CEST] <Yawnny> So at some point I think I have to insert -af aresample=48000:async=1 from what I've read [00:46:33 CEST] <furq> who told you this [01:08:41 CEST] <Yawnny> If someone responded would you mind pasting the reply again? Didn't realize my computer crashed.. had to reboot [01:09:03 CEST] <Threads> only thing said was [23:46:37] <furq> who told you this [01:11:06 CEST] <Yawnny> Oh okay. Well in response to that: someone on the adobe premier subreddit [01:11:57 CEST] <Yawnny> https://www.reddit.com/r/premiere/comments/6koba3/helpaudio_out_of_sync_ove… [01:12:07 CEST] <Yawnny> That's where I initially brought up my issue [02:01:04 CEST] <iive> Yawnny: you are not telling us what error you do get [02:01:40 CEST] <iive> also resampling lowers quality, do it only if necessery. [04:37:20 CEST] <nicolas17> to get the input format for demuxing, I use av_find_input_format("image2") [04:37:44 CEST] <nicolas17> but how do I get an AVOutputFormat by name to use when muxing? I can't see an av_find_output_format [04:41:48 CEST] <nicolas17> looks like that's av_guess_format [04:41:51 CEST] <nicolas17> o_o [04:41:59 CEST] <nicolas17> weird name if I want to get an exact match but okay [04:49:38 CEST] <nicolas17> why does conversion from yuvj422p give this warning from swscaler? "deprecated pixel format used, make sure you did set range correctly" [10:08:02 CEST] <a__pi> im trying to convert a mp4 to another one with hardware acceleration with profile baseline 3.0. I'm using ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i file -vf 'format=nv12,hwupload,scale_vaapi=w=640:h=360' -map 0:0 -map 0:1 -threads 8 -y -acodec copy -b:v 12500k -vcodec h264_vaapi /tmp/file.mp4 that command. how can i specify the profile in it ? i tried profile 66 as per https://www.reddi [10:08:08 CEST] <a__pi> t.com/r/linux_gaming/comments/4q5orj/using_vaapis_hardware_accelerated_video_encoding/ but it's failing with Encoding profile not found (5). [10:21:50 CEST] <Mavrik> why not -profile:v baseline ? [10:23:49 CEST] <a__pi> Undefined constant or missing '(' in 'baseline' Unable to parse option value "baseline" Error setting option profile to value baseline. [10:23:57 CEST] <a__pi> it says that with baseline [10:30:39 CEST] <Mavrik> Hmm, new ffmpeg? [10:32:36 CEST] <Mavrik> Ahh. [10:32:44 CEST] <Mavrik> a__pi, if I read this correctly: https://gist.github.com/Brainiarc7/95c9338a737aa36d9bb2931bed379219 [10:32:51 CEST] <Mavrik> You'd have to use -hwaccel_output_format [10:33:09 CEST] <Mavrik> And use `vainfo` to find out what the right name for it is, e.g. VAProfileH264ConstrainedBaseline [10:34:29 CEST] <a__pi> Option hwaccel_output_format (select output format used with HW accelerated decoding) cannot be applied to output url [10:37:18 CEST] <a__pi> moved the option before first file but its ignoring it its generating high [11:25:01 CEST] <jkqxz> a__pi: I doubt you want baseline; nothing supports it. Try "-profile:v 578" for constrained baseline. [11:25:34 CEST] <a__pi> i require baseline :) its for and old device [11:25:38 CEST] <a__pi> an* [11:25:54 CEST] <a__pi> but i'll try constrained baseline :) [11:25:57 CEST] <a__pi> thx [11:27:11 CEST] <jkqxz> You really don't want baseline - nothing supports it at all. (Some old streams do lie about it, though - they are actually constrained baseline with incorrect marking.) [11:28:13 CEST] <a__pi> its for a projector that max resolution is 640x360.... [11:30:20 CEST] <hojuruku> a__pi, vaapi has big problems with filters, due to some locking, i played with it and gave up [11:30:37 CEST] <hojuruku> a__pi, it works fine on my old haswell, just make sure you test first with no filters. [11:31:20 CEST] <a__pi> thx [11:31:30 CEST] <a__pi> i'll do :) [11:31:37 CEST] <hojuruku> a__pi, you are on the right track, I'm too overrealmed with my kerberos/ldap setup geek stuff now to dive in and give you the exact syntax, but keep plodding at it. you'll get it. [11:32:16 CEST] <hojuruku> by filters i mean stuff that modifies the final output - so you can't even select a time duration. I tried very hard to do that, and I saw bug reports etc.. let me see my browser history to give you the details. [11:33:19 CEST] <hojuruku> https://trac.ffmpeg.org/ticket/5532 a__pi that's the error i was hitting, solution no filters. [11:35:21 CEST] <hojuruku> a__pi, that's me tweeting about fiddling with it 2 months ago. Oh i'm banned from twitter ;) https://gab.ai/ozzieslovepedos/posts/7802589 [11:35:32 CEST] <jkqxz> Er, what? That bug is incorrect priority in encoders, and was fixed more than a year ago. [11:36:09 CEST] <jkqxz> If you want software filters on hardware frames then use hwmap, or download/upload them. [11:37:58 CEST] <hojuruku> a__pi, haswell doesn't support intel qsv, but if you have a newer processor this looks like the GO - the newer intel binary interface to the gpu. https://trac.ffmpeg.org/wiki/HWAccelIntro [11:38:50 CEST] <hojuruku> jkqxz, i assure you i was getting it when trying to use input filters with vaapi hardware encoding. Under normal use the commandline etc would work, but using vaapi there was some kind of issue. [11:39:32 CEST] <hojuruku> i'm useless because I haven't played with it for 2 months. All I got is a massive binge in my web browsers history researching ffmpeg. The bug is real and it's in git. Tested on a haswell refresh gpu. [11:39:42 CEST] <hojuruku> and gentoo with everything up to date and fffmpeg git. [11:41:34 CEST] <hojuruku> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2016-June/032484.html i was trying to use vaapi in the filter chain it has two ways to invoke it. Neither worked with filters. [11:42:56 CEST] <hojuruku> vaapi has two modes, one mode for input and or output only and one mode for full vaapi transcoding. https://lists.ffmpeg.org/pipermail/ffmpeg-user/2016-June/032484.html a__pi sorry I wish i could be more help to you. If you got to me sooner i'd have my bash history ;) [11:47:26 CEST] <jkqxz> VAAPI uses hardware surfaces (on the GPU); most filters want to act on software frames in CPU memory. Hence if you want to use any such filters then you need to deal with transferring between the two. [11:56:08 CEST] <hojuruku> jkqxz, i realize that, but i think the problem was the software filters were called at the wrong order in the chain, like I said i'm no use, I haven't tried to RTFM up on this for 2 months. If you can get it working make a blog post or something because I spent a few days on it and gave up. [11:57:02 CEST] <hojuruku> I wasn't trying to use the hardware services, there is an option to export from VAAPI back into ffmpeg. I was trying that before trying to use any filters of course. [12:21:05 CEST] <kerio> yo is there a suggested ffmpeg binary build for raspberry [12:37:10 CEST] <kerio> o no this ffmpeg doesn't have h264 omx D: [13:24:07 CEST] <acresearch> people i have 2250 HD PNG images that I am trying to make into a video, this is the code i am using, does this result in HD quality video? i want it 1080p: ffmpeg -f image2 -i video%4d.png -r 30 -vcodec libx264 -pix_fmt yuv720p -acodec libvo_aacenc -ab 128k video.mp4 [13:24:42 CEST] <acresearch> sorry this is the command: ffmpeg -f image2 -i video%4d.png -r 30 -vcodec libx264 -pix_fmt yuv420p -acodec libvo_aacenc -ab 128k video.mp4 [13:55:56 CEST] <acresearch> people i have the following code to convert images into a video, my question is how can i make it work in a ios iphone? it doesn't seem to like to format or coding: ffmpeg -f image2 -i video%4d.png -r 30 -vcodec libx264 -pix_fmt yuv420p -acodec libvo_aacenc -ab 128k video.mp4 [13:57:58 CEST] <squ> acresearch: https://trac.ffmpeg.org/wiki/Encode/H.264#Compatibility [13:58:52 CEST] <acresearch> squ: so i should include this flag? -profile:v high -level 4.2 [13:59:03 CEST] <squ> I don't know [14:09:06 CEST] <acresearch> squ: doesn't seem to work, is there a format that just works everywhere? this issue with different formats for different platforms is a real pain in the butt !!! it wastes a lot of time [14:09:22 CEST] <squ> doesn't it say which one [14:09:50 CEST] <acresearch> squ: what do you mean? [14:11:24 CEST] <squ> doesn't table by that link say which format is compatible with All devices [14:13:02 CEST] <acresearch> yes, i get a very nice exported video, but the ios still stays it is incompatible and won't import it [14:57:40 CEST] <sedri> Hello [15:02:27 CEST] <sedri> I'm trying to use ffmpeg to split and merge several video files but I get an error message I don't know how to resolve: https://pastebin.com/raw/CGyvfX3i [15:04:32 CEST] <DHE> "record or transcode stop time" is the description of the "-to" parameter. it isn't supported for an input file option [15:05:16 CEST] <DHE> you'll have to use filter-based cutting, like [a]trim [15:05:57 CEST] <kepstin> sedri: you can either use the -t input option or throw some trim filters in the filter chain (note that in both cases, you'll be providing duration of the clip, not end time) [15:47:06 CEST] <sedri> Thank you kepstin. [16:28:56 CEST] <wpppp> hi [16:29:12 CEST] <spaam> Hello and welcome to #ffmpeg. [16:29:14 CEST] <wpppp> GOV length in h264 - a higher value yields better compression - but it can affect quality? [16:29:17 CEST] <wpppp> spaam: hi! :O [16:30:17 CEST] <BtbN> do you mean gop? [16:30:27 CEST] <wpppp> GOV length in ONVIF h264 settings [16:30:33 CEST] <wpppp> maybe they have a typo in the caption? [16:30:41 CEST] <BtbN> no idea what that is [16:32:23 CEST] <wpppp> hm, thanks :D [16:33:06 CEST] <wpppp> The GOP (Group of Pictures) refers to the type of setting in camera firmware by which it is possible to further reduce the bandwidth and storage consumption of video stream up to 10 times. [16:33:09 CEST] <wpppp> (citation) [16:33:22 CEST] <wpppp> http://www2.acti.com/support_old/Package/%7B6060C79F-2A5D-40A4-8837-16B835E… [16:33:26 CEST] <wpppp> for example ^ [16:35:06 CEST] <wpppp> BtbN: ^ [16:36:46 CEST] <alexpigment> Long GOP lengths affect seeking because decoding usually wants to start at the nearest I-frame. It can also affect hardware compatibility to some degree. In general though, if you don't need to seek in the video, long GOPs are fine. [16:37:05 CEST] <alexpigment> (and they do decrease file size because you have less I-frames) [16:38:22 CEST] <alexpigment> Personally, I *always* use 1-second GOPs, but I realize that this is not how most people work with H.264 [16:43:04 CEST] <wpppp> alexpigment: so GOP = GOV, right? :D [16:43:09 CEST] <wpppp> I mean from the docs I linked to [16:43:11 CEST] <wpppp> they mean the same? [16:43:17 CEST] <kepstin> wpppp: the h264 format allows basically infinitely long GOP without any reduction in quality [16:43:44 CEST] <wpppp> kepstin: cool, so just better compression? there is some point of diminishing returns? [16:44:19 CEST] <alexpigment> wpppp: today is the first time i've ever heard of "GOV", so I'm not sure [16:44:23 CEST] <kepstin> wpppp: I assume that there's diminishing returns eventually, yeah, but the main reason not to do it is the seeking issue. [16:44:36 CEST] <wpppp> kepstin: so if someone wants to seek in the stream? [16:44:42 CEST] <wpppp> in the already downloaded, buffered stream? [16:45:09 CEST] <wpppp> if it is a livestream, streamed to youtube live - then the GOV/GOP thing doesn't really matter because youtube takes care for the seeking stuff? [16:45:45 CEST] <kepstin> wpppp: for live streaming it's a bit of a different case, and depends on whether the remote side is just bouncing the stream or if they're re-encoding. [16:46:01 CEST] <kepstin> wpppp: live streaming sites will usually give you a recommended gop size (keyframe interval) [16:46:08 CEST] <wpppp> ah, good to know [16:46:26 CEST] <kepstin> main issue there is people joining the stream late - they can't see any video until a new gop starts [16:46:37 CEST] <wpppp> "YouTube's pipeline requires a Closed GOP for optimal transcoding." [16:46:43 CEST] <wpppp> what does that mean? [16:46:50 CEST] <wpppp> kepstin: hm, youtube can timeshift up to some hours [16:47:14 CEST] <kepstin> wpppp: sure, but you'd still have the seeking problem then [16:47:26 CEST] <kepstin> can't seek into the middle of a gop, can only decode from the start. [16:47:58 CEST] <wpppp> kepstin: what gov/gop youtube live recommends? [16:48:09 CEST] <kepstin> wpppp: google it? :) [16:48:27 CEST] <wpppp> I did [16:48:28 CEST] <wpppp> not sure [16:49:14 CEST] <kepstin> wpppp: the difference between closed gop and open gop is that with open gop, you can have bidirectionally predicted frames at the end of one gop which reference stuff in the next [16:49:29 CEST] <kepstin> which can cause issues with segmented media, like used in most http live streaming [16:49:57 CEST] <wpppp> kepstin: ah! [16:50:04 CEST] <wpppp> kepstin: I googled as you said and I found indeed something: https://datarhei.github.io/restreamer/wiki/iframe.html [16:50:47 CEST] <kepstin> wpppp: regarding gop size (keyframe interval), see https://support.google.com/youtube/answer/3006768?hl=en [16:50:53 CEST] <kepstin> they want one every 2 seconds. [16:51:26 CEST] <kepstin> they're probably ok with anything in the range of 2-4s, really [16:54:42 CEST] <wpppp> kepstin: so a gop/gov value of 2 to 4? [16:54:55 CEST] <kepstin> no, a gop length of 2-4 seconds [16:55:12 CEST] <wpppp> I understand [16:55:13 CEST] <kepstin> so multiply that by your framerate to set the gop size/ keyframe interval [16:55:17 CEST] <wpppp> ah! [16:55:20 CEST] <wpppp> framerate, of course [16:56:32 CEST] <wpppp> kepstin: frames/s * 2 to 4 s = frames (gop/gov value)? :) [16:56:38 CEST] <wpppp> unit cancellation included :O [17:09:49 CEST] <alexpigment> wpppp: if your stream is 30fps, a GOP value of 60 will be 2 seconds [17:10:06 CEST] <alexpigment> if your stream is 25fps, a GOP value of 50 will be 2 seconds [17:10:25 CEST] <alexpigment> if your stream is 30fps, a GOP value of 120 will be 4 seconds [17:10:27 CEST] <alexpigment> etc [17:10:33 CEST] <alexpigment> hopefully that clears up any confusion [17:10:52 CEST] <wpppp> yes [17:11:04 CEST] <wpppp> so google/youtube wants up to 4 seconds [17:13:11 CEST] <wpppp> 2-4 and restreamer docs recommend 25 to max. 61 - so with smallest GOP I would scratch at that limit [17:14:02 CEST] <alexpigment> I haven't read the documentation, but I can't imagine YouTube would have a problem with a GOP of 1 second [17:14:07 CEST] <kepstin> looks like youtube prefers 2, since that is pretty much the min you can use for segmented streaming, andy longer and you get more latency. [17:14:21 CEST] <kepstin> at least in their transcodes, I think they use 2. [17:15:02 CEST] <alexpigment> Anyway, just set it to 50 or 60 (depending on your original framerate) and call it a day :) [17:15:43 CEST] <wpppp> that's what I wanted to know :D [17:15:46 CEST] <wpppp> thanks man [17:16:42 CEST] <wpppp> alexpigment: ha, let's crack open another nice can of worms [17:17:10 CEST] <wpppp> alexpigment: Hm, what is an Encoding interval? [17:17:20 CEST] <wpppp> what is optimal? I guess it also has to do with GOV? [17:17:34 CEST] <kepstin> wpppp: not standard encoder terminology, reference the docs for the product :/ [17:18:15 CEST] <wpppp> kepstin: like https://wiki.allprojects.info/display/ODMDOC/6.+Managing+Video#id-6.Managin… [17:19:11 CEST] <kepstin> wpppp: that seems to describe what it does pretty accurately? [17:19:53 CEST] <wpppp> kepstin: right and I found out that the encoding interval has to be at least as large as GOV length [17:19:58 CEST] <wpppp> which makes sense somehow I think [17:19:59 CEST] <__deivid__> Hi! I have over 6k video files (mp4) and I want to detect if they have "faststart" enabled. What can I do? [17:20:29 CEST] <__deivid__> I know *some* don't have it, but most do [17:20:30 CEST] <kepstin> wpppp: that doesn't make sense... you want encoding interval to be 1 in almost all cases... [17:21:22 CEST] <kepstin> wpppp: only reason to use anything other than 1 is if your cpu is overloaded by video encoding, so you want to skip frames. (e.g. using 2 halves the framerate, which also means you should halve the gop size) [17:21:54 CEST] <wpppp> kepstin: ok, for whatever strange reason the UI sets the encoding interval from 1 back to GOP size :/ [17:22:22 CEST] <wpppp> aha, maybe it is something different [17:22:25 CEST] <wpppp> a bug maybe, sec [17:39:04 CEST] <BtbN> kepstin, there's no diminishing returns at all. [17:39:16 CEST] <BtbN> It's pretty common to use endless gops in applications where seeking is not needed [17:39:41 CEST] <BtbN> Like, for example the Wii U tablet uses a P/B Only stream, only sending I frames when required [17:40:15 CEST] <kepstin> well, the longer the gop, the smaller the increase in bitrate adding each keyframe is. so the gains re relatively smaller for longer gops? [17:40:43 CEST] <kepstin> diminishing doesn't mean there aren't still returns of course :) [17:49:53 CEST] <BtbN> kepstin, depending on the connection, the burst caused by an IFrame may still be a significant problem [18:12:31 CEST] <Hopper_> Hey all, anyone available to help me troubleshoot my FFmpeg command? [18:12:36 CEST] <Hopper_> https://pastebin.com/uSibwXrN [18:13:15 CEST] <DHE> so what's wrong with it? [18:13:22 CEST] <Hopper_> DHE: Glad you're here! [18:13:27 CEST] <DHE> oh god [18:14:07 CEST] <Hopper_> When I run that command I get a bunch of brown "Past duration 0.0numbers too large" responses. [18:14:24 CEST] <Hopper_> Oh god? [18:14:30 CEST] <Hopper_> Is it that bad? [18:17:14 CEST] <DHE> no, I'm just busy and you're pouncing on my specifically [18:17:26 CEST] <durandal_1707> depends [18:17:57 CEST] <Hopper_> DHE: I certainly didn't mean to single you out, but I appreciate your help previously. [18:18:16 CEST] <Hopper_> durandal_1707: What do you mean? [18:21:01 CEST] <thebombzen> Hopper_: "past duration too large" is usually not a problem [18:21:41 CEST] <Hopper_> Okay, but when I attempt to open the file my players don't display anything. [18:21:59 CEST] <thebombzen> did you try playing it in ffplay or mpv as a test? [18:22:45 CEST] <Hopper_> mpv [18:23:00 CEST] Last message repeated 1 time(s). [18:23:08 CEST] <Hopper_> Hah, sorry wrong keyboard. [18:23:17 CEST] <thebombzen> what "past duration too large" basically means in this case, is well, ffmpeg receives variable framerate content from the filtergraph and doesn't know the framerate so it tries to guess based on the timestamps [18:23:25 CEST] <thebombzen> and if it's slightly off you get this error [18:24:05 CEST] <thebombzen> In this case, you know what the framerate is. It's 30. Try adding -r 30 after the filtergraph to force it to be constant framerate 30 fps [18:24:32 CEST] <Hopper_> Okay, I'll still get a feed, it is just likely to have bad timing. [18:24:37 CEST] <Hopper_> Okay, I'll try that. [18:24:52 CEST] <thebombzen> -r 30 will force 30 fps constant framerate and duplicate/drop frames to achieve it... which should not be a problem for you seeing as it's already 30 fps [18:25:00 CEST] <thebombzen> but what it does do is set the mpegts container to 30 fps [18:26:05 CEST] <thebombzen> Hopper_: also, if you're trying to put two videos side-by-side, use the hstack filter. It's better than pad/overlay [18:26:13 CEST] <Hopper_> thebombzen: which component is the filtergraph? [18:26:23 CEST] <Hopper_> Okay, I'll look into that as well! [18:26:25 CEST] <thebombzen> the filtergraph is your -filter_complex [18:26:42 CEST] <thebombzen> and yea, hstack does what you need without messing with huge canvasses or transparency or whatever [18:26:55 CEST] <thebombzen> it's much faster but less powerful because it only stacks videos horizontally [18:27:02 CEST] <thebombzen> (for vertically, you can use vstack accordingly) [18:28:15 CEST] <Hopper_> Hm, mpv seems unresponsive in my version of debian. [18:29:04 CEST] <wpppp> hi again [18:29:21 CEST] <wpppp> in youtube in "nerds" statistics I see 30fps, is that really 30fps? or will youtube transform all streams to 30fps? [18:29:22 CEST] <wpppp> even 25fps? [18:29:49 CEST] <furq> it's really 30fps [18:30:51 CEST] <wpppp> ah cool [18:30:53 CEST] <wpppp> why? :) [18:31:16 CEST] <furq> i don't know how to answer that [18:32:57 CEST] <Hopper_> thebombzen: hstack is slick, but again produces a file that wont play on VLC or MPV. [18:33:36 CEST] <thebombzen> Hopper_: what does "won't play" mean [18:33:59 CEST] <Hopper_> VLC tries, mpv opens and immediately closes. [18:34:13 CEST] <thebombzen> what does mpv say on the command line? [18:34:17 CEST] <furq> i don't think mjpeg is supported in mpegts [18:34:43 CEST] <Hopper_> furq: It works when I was using a single video feed. [18:34:56 CEST] <thebombzen> wpppp: youtube doesn't transform streams to 30 fps, so if you see a 30 fps video, it means whoever uploaded it uploaded a 30 fps video [18:34:59 CEST] <thebombzen> there isn't more to it [18:35:14 CEST] <furq> thebombzen: i'm not entirely sure of that [18:35:35 CEST] <thebombzen> (I know that. If you upload a video with a weirdass framerate between 30 and 60 it might turn it to 30) [18:35:37 CEST] <furq> obviously it does support 24/25/30/48/50/60 amongst others [18:35:47 CEST] <furq> but i assume like 28 or something would get converted to 30 [18:35:53 CEST] <furq> that's the uploader's fault for having a dumbass video though [18:35:54 CEST] <thebombzen> 28 goes to 25 I think [18:36:15 CEST] <furq> i know anything below 6 gets converted to 6 [18:36:18 CEST] <wpppp> apparently my ipcam only supports 24/25fps although they advertised 30fps for full hd resolution :/ [18:36:28 CEST] <wpppp> anyhow, I don't think there is a big difference between 25 and 30fps [18:36:33 CEST] <furq> 25 is fine [18:36:36 CEST] <wpppp> when it would be 24 vs 60fps, then I would understand it [18:36:36 CEST] <wpppp> right [18:36:39 CEST] <furq> as anyone in a pal region knows [18:36:39 CEST] <wpppp> but still :/ [18:36:47 CEST] <wpppp> hmm, isn't NTSC a bit higher? and why? [18:36:52 CEST] <furq> ntsc is 30 [18:37:01 CEST] <wpppp> that's explains it :D [18:37:05 CEST] <wpppp> my ipcam uses pal right now [18:37:07 CEST] <thebombzen> ntsc is 30 if interlaced, but ntsc films are still 24 in progressive [18:37:12 CEST] <wpppp> I see [18:37:15 CEST] <furq> because pal regions have 50hz power and ntsc regions have 60 [18:37:18 CEST] <wpppp> ah [18:37:21 CEST] <wpppp> crazy analog stuff [18:37:27 CEST] <thebombzen> but they still use 24 for films in North America [18:37:30 CEST] <furq> pal is traditionally higher vertical resolution to make up for it [18:37:31 CEST] <wpppp> hm [18:37:41 CEST] <furq> but not really since everything switched to HD [18:37:56 CEST] <wpppp> why do all these IPcams still offer the PAL/NTSC option? even if they got full hd rtsp streaming and onvif and all the other digital stuff? [18:38:04 CEST] <thebombzen> but 30 is not super relevant anymore [18:38:08 CEST] <thebombzen> outside of interlaced content [18:38:18 CEST] <thebombzen> hd content is usually 24 fps or 60 fps most of the time [18:38:24 CEST] <wpppp> thanks! :D [18:38:26 CEST] <wpppp> this explains [18:38:39 CEST] <thebombzen> (in North America I mean. I have no idea what is standard in Europe) [18:38:57 CEST] <furq> 50i or 25p is standard in europe for hd and sd [18:39:10 CEST] <wpppp> I hope the last left overs of analog PAL/NTSC interleaving, power frequency crap will be removed soon :D [18:39:16 CEST] <furq> good luck with that [18:39:26 CEST] <thebombzen> power frequency will always be relevant [18:39:35 CEST] <wpppp> even in digital world? [18:39:41 CEST] <furq> we're still using yuv, which is for backward compatibility with black and white tvs [18:39:42 CEST] <thebombzen> but also keep in mind that it already is being phased out [18:39:57 CEST] <furq> and by "we" i mean basically all video on the internet [18:39:58 CEST] <thebombzen> furq: YUV also is more compressible than RGB, so there's still a reason to use it [18:40:01 CEST] <furq> sure [18:40:09 CEST] <thebombzen> chroma subsampling OP [18:40:10 CEST] <wpppp> and thanks for the hint! I switched my ipcam to NTSC mode and now I can select 30fps - the question is: Are these real 30 Full HD fps? [18:40:21 CEST] <thebombzen> how are we supposed to answer that [18:40:25 CEST] <thebombzen> you're the one with the camera [18:40:30 CEST] <alexpigment> chroma subsampling is pretty dumb :( not sure why we still do it [18:40:38 CEST] <furq> because it's half the bandwidth [18:40:39 CEST] <thebombzen> because it saves 50% of the bitrate instantly [18:40:46 CEST] <thebombzen> for no visually noticable difference [18:40:48 CEST] <furq> except it isn't really with modern codecs [18:40:53 CEST] <alexpigment> yeah, but it's also throwing away half the color information [18:40:55 CEST] <furq> it's still an appreciable saving though [18:41:00 CEST] <thebombzen> so? humans suck ass at seeing color [18:41:03 CEST] <thebombzen> that's the whole point [18:41:11 CEST] <alexpigment> try using chroma key on anything that's subsampled [18:41:25 CEST] <thebombzen> sure, it's less information for editing [18:41:35 CEST] <thebombzen> but it makes a lot of sense outside of intermediary storage [18:41:35 CEST] <furq> i don't think your tv station is really that bothered about your ability to chromakey [18:42:01 CEST] <thebombzen> the whole point is that it's a human-specific visual optimization. Most data like that that gets thrown out is intentionally thrown out for realtime playback [18:42:15 CEST] <furq> itunes continue to ignore my requests for 24/96 flac so that i can remaster their music in my shed [18:42:18 CEST] <furq> the bastards [18:42:26 CEST] <alexpigment> yeah, i just think it's a dumb way to think about information. just throw away half. we're MP3-izing broadcast and hard media [18:42:30 CEST] <furq> thanks to them i don't even have a shed [18:42:48 CEST] <thebombzen> alexpigment: well once you deal with lossless video you appreciate lossy [18:43:10 CEST] <nicolas17> alexpigment: do you expect them to stream lossless RGB video to you? [18:43:12 CEST] <alexpigment> thebombzen: doing 4:4:4 lossy is still by no means anywhere near lossless [18:43:20 CEST] <alexpigment> nicolas17: see above [18:43:34 CEST] <thebombzen> alexpigment: well you *can* use 4:4:4 for intermediary editing. [18:43:40 CEST] <alexpigment> of course I can [18:43:45 CEST] <nicolas17> chroma subsampling is just yet another lossy compression technique adapted to human eyes [18:43:47 CEST] <thebombzen> then why are you complaining [18:43:52 CEST] <alexpigment> i'm saying we shouldn't be using 4:2:0 as a broadcast and physical media standard [18:43:57 CEST] <furq> how would they stream all 900 high-quality tv channels if they weren't saving so much bandwidth [18:44:07 CEST] <thebombzen> alexpigment: why not? You can't see the difference if you're playing in realtime. [18:44:08 CEST] <alexpigment> aight, you guys are just missing the point [18:44:18 CEST] <alexpigment> why do we even use PCM on DVD? [18:44:18 CEST] <furq> i will gladly take fucked video quality on shows i like so that SUPERCASINO +1 can continue to exist [18:44:22 CEST] <alexpigment> or PCM on CD? [18:44:27 CEST] <thebombzen> alexpigment: we don't use pcm on a dvd [18:44:33 CEST] <furq> you can [18:44:38 CEST] <alexpigment> thebombzen: ??????? [18:44:43 CEST] <alexpigment> thebombzen: ???????????? [18:44:44 CEST] <thebombzen> we can, but we don't. [18:44:48 CEST] <alexpigment> who is we? [18:44:49 CEST] <furq> i've seen it lots of times [18:44:52 CEST] <alexpigment> of course they use it [18:44:58 CEST] <alexpigment> i've got hundreds of dvds with PCM [18:44:59 CEST] <furq> most DVDAs use lpcm [18:45:08 CEST] <thebombzen> why do we use pcm on a CD? idk it was written in the 1970s or whatever [18:45:11 CEST] <furq> and concert videos etc [18:45:20 CEST] <alexpigment> yeah, i have tons of music dvds [18:45:24 CEST] <nicolas17> alexpigment: what else could CDs have possibly used? [18:45:25 CEST] <thebombzen> go ask the people who originally wrote CD-audio [18:45:28 CEST] <furq> also yeah if CDs were invented today there's no way they'd use PCM [18:45:32 CEST] <thebombzen> you know, before mp3s existed [18:45:45 CEST] <thebombzen> before flac existed [18:45:55 CEST] <alexpigment> the point being is that we already had lossless standards. why are we settling for this subsampled BS in 2017, when we have more storage and bandwidth than ever? [18:45:58 CEST] <nicolas17> before either mp3 or flac was computationally feasible [18:46:00 CEST] <furq> they'd use AAC or some similarly patent-encumbered bullshit so that they could fill the rest of the disc with ads for dick pills [18:46:09 CEST] <nicolas17> alexpigment: we have more computing power than ever :P [18:46:11 CEST] <thebombzen> alexpigment: because lossless audio and lossless video are very different [18:46:16 CEST] <thebombzen> lossless audio isn't impractically large [18:46:22 CEST] <furq> alexpigment: inertia [18:46:22 CEST] <alexpigment> sure [18:46:27 CEST] <furq> everything already supports yuv420p [18:46:27 CEST] <thebombzen> video is orders of magnitude larger than audio [18:46:29 CEST] <alexpigment> and i'm not talking about lossless video here [18:46:33 CEST] <alexpigment> just 4:4:4 [18:46:38 CEST] <furq> and so everyone only broadcasts yuv420p [18:46:39 CEST] <alexpigment> this is not a huge increase in size [18:46:42 CEST] <alexpigment> 2x at most [18:46:46 CEST] <thebombzen> that is enormous [18:46:51 CEST] <alexpigment> compared to what? [18:46:55 CEST] <alexpigment> it's small stuff [18:46:57 CEST] <thebombzen> a 100% increase in size is enormous [18:47:04 CEST] <furq> if you started broadcasting 444 then nobody would notice except the vast numbers of people whose shit tvs can't decode it [18:47:07 CEST] <nicolas17> 2x is "small stuff"? [18:47:13 CEST] <alexpigment> yeah, 2x is small [18:47:17 CEST] <furq> it wouldn't be 2x [18:47:18 CEST] <thebombzen> also, alexpigment, you're overestimating the visual difference of 4:2:0 [18:47:21 CEST] <nicolas17> it's by definition twice as big :P [18:47:21 CEST] <thebombzen> it's pretty neglibible [18:47:25 CEST] <furq> even mpeg2video would compress it much more than that [18:47:42 CEST] <alexpigment> thebombzen: not at all. i realize it's a very small difference. it's just a thing we shouldn't be doing [18:47:48 CEST] <ritsuka> alexpigment: are you a friend of the guy on doom9.org that derails every thread in a 4:4:4 versus 4:2:0 flame? ;) [18:48:01 CEST] <thebombzen> alexpigment: on principle? because it's not noticable to humans [18:48:03 CEST] <alexpigment> no, i'm not a doom9 kinda person [18:48:06 CEST] <thebombzen> it's really not noticable [18:48:10 CEST] <thebombzen> it's a very good optimization [18:48:12 CEST] <furq> it is noticeable sometimes [18:48:20 CEST] <furq> i agree it's not worth it in general though [18:48:25 CEST] <thebombzen> furq: yea, I know that, it's noticable rarely [18:48:30 CEST] <furq> even assuming every decoder magically supported 444 tomorrow [18:48:41 CEST] <thebombzen> but in cases where it matters (like a screengrab) you can use it [18:48:47 CEST] <alexpigment> thebombzen: yes, on principal mostly. because you can't do chroma key on 4:4:4 and yet that's the current video standard is kinda dumb [18:49:02 CEST] <nicolas17> the people producing 4:2:0 don't care if you can't do chroma key [18:49:04 CEST] <furq> you can't practically use it because any consumer-friendly endpoint you'd send the video to would convert it to 420 [18:49:15 CEST] <thebombzen> alexpigment: you're complaining about being unable to do an intermediary video editing thing on end-user video [18:49:19 CEST] <wpppp> constant bitrate, variable bitrate and finally "fixed quality" with "very high, low, etc" subjective selection [18:49:20 CEST] <wpppp> what is better? :) [18:49:26 CEST] <nicolas17> furq: most consumer cameras would save 4:2:0 too [18:49:42 CEST] <furq> you don't do screen capture with a camera [18:49:51 CEST] <alexpigment> thebombzen: i'm saying that we shouldn't be standardizing a format that's functionally ill-equiped for editing [18:49:55 CEST] <thebombzen> alexpigment: you say you can't do chroma key and then you're complaining that your end-user video can't do it. pick one - end-user video? or intermediary editing? [18:50:08 CEST] <thebombzen> it's only standard for consumers [18:50:11 CEST] <alexpigment> end user video should be, if anything, a bitrate change [18:50:12 CEST] <alexpigment> that's all [18:50:15 CEST] <thebombzen> why? [18:50:28 CEST] <alexpigment> because i don't think it's right to make gimpy standards [18:50:33 CEST] <alexpigment> it's a shortsighted notion [18:50:39 CEST] <thebombzen> no, no it's not [18:50:39 CEST] <nicolas17> that's why 4:4:4 h264 is a standard too [18:50:42 CEST] <alexpigment> yes it is [18:50:43 CEST] <furq> this isn't a recent thing though [18:50:47 CEST] <alexpigment> it is extremely short-sighted [18:50:47 CEST] <furq> these standards date back to the 70s [18:50:55 CEST] <furq> there's just no impetus to change them [18:51:20 CEST] <alexpigment> man, i feel like i'm talking to people who work at YouTube or something [18:51:21 CEST] <thebombzen> alexpigment: you keep complaining that end-user tools are different than intermediary industry codecs [18:51:34 CEST] <furq> you'd need everyone to agree that it would be good to move to gbrp or xyz12le or whatever [18:51:37 CEST] <furq> and that's not going to happen [18:51:52 CEST] <thebombzen> this is not a fair complaint, there's a reason consumer tools and industry tools are different. [18:51:54 CEST] <nicolas17> why would broadcast video care about your ability to chroma-key? it's illegal for you to edit it that way anyway :P [18:52:43 CEST] <alexpigment> nicolas17: because your camera follows the dumb standards. and you can't do chroma key on your phone videos, for example, because people like you guys are justifying these dumb standards [18:52:49 CEST] <wpppp> NTSC vs PAL in a _IP_camera - why at all? [18:52:50 CEST] <alexpigment> for a cost of what? 2x bitraet [18:52:55 CEST] <alexpigment> *bitrate [18:53:02 CEST] <furq> again, it's much less than 2x bitrate [18:53:05 CEST] <furq> unless you're streaming rawvideo [18:53:15 CEST] <alexpigment> talking max here [18:53:17 CEST] <furq> it's a few percent with h264 [18:53:40 CEST] <nicolas17> alexpigment: I have 260GB of iframe-only 4:2:0 video, that means 30 days vs 15 days for me to upload it to the internet [18:53:51 CEST] <nicolas17> if it was 2x as you say [18:54:10 CEST] <alexpigment> nicolas17: doesn't it feel dumb to have i-frame video that's always throwing away half the color information? [18:54:11 CEST] <nicolas17> also means the memory card would have lasted half as long while recording the timelapse [18:54:14 CEST] <alexpigment> like why do iframe video at that point [18:54:15 CEST] <thebombzen> alexpigment: are you seriously complaining that your phone camera doesn't use industry-quality recording [18:54:18 CEST] <alexpigment> you already have a gimpy video [18:54:34 CEST] <nicolas17> alexpigment: for ease of editing, also that's how this camera did timelapses [18:54:43 CEST] <alexpigment> thebombzen: why the hell are you justifying this divide between industry and consumer standards? do you *want* to have to pay a premium? [18:54:54 CEST] <thebombzen> alexpigment: because there's different tools for differnet purposes [18:54:54 CEST] <nicolas17> alexpigment: why are you trying to convince *us* about it? [18:55:15 CEST] <furq> because it's fun to have a moan on irc [18:55:17 CEST] <alexpigment> i'm not sure why any of you are even arguing with this. do any of you work in the tv/film industry at all?? [18:55:30 CEST] <thebombzen> alexpigment: I don't use ffv1 on my computer because I don't like paying for external hard drives [18:55:32 CEST] <alexpigment> or do you guys just watch youtube all day? [18:55:33 CEST] <nicolas17> alexpigment: no, so why are you trying to convince us that things should be different? [18:55:44 CEST] <thebombzen> alexpigment: you just barge in and tell us that we're all wrong [18:55:53 CEST] <alexpigment> you guys are the only ones arguing. all i said was that chroma subsampling is dumb. that's how this started [18:55:59 CEST] <alexpigment> i didn't think i needed to defend that statement [18:56:02 CEST] <nicolas17> well it's not dumb, /thread :P [18:56:09 CEST] <alexpigment> ok, it's settled then [18:56:44 CEST] <furq> it is a bit dumb [18:57:05 CEST] <Hopper_> Okay, now I'll jump in again. [18:57:40 CEST] <Hopper_> For the hstack file I generated, ffplay fails and says "Failed to open file or configure filtergraph" [19:00:07 CEST] <Hopper_> thebombzen: Any ideas? [19:00:44 CEST] <thebombzen> Hopper_: furq said mpegts doesn't support mjpeg (or rather, might not) [19:01:23 CEST] <thebombzen> also [19:02:07 CEST] <Hopper_> And I said that mpegts works fine when I'm not using filter_complex [19:02:18 CEST] <thebombzen> okay, but still post the complete command and output [19:02:45 CEST] <Hopper_> Sorry, for creating or playback? [19:04:24 CEST] <kepstin> Hopper_: both if you can, the creating ffmpeg command at a minimum [19:06:28 CEST] <Hopper_> Creation- https://pastebin.com/3KMf9mC1 [19:06:46 CEST] <Hopper_> Playback- https://pastebin.com/RrqSFpTp [19:07:49 CEST] <Hopper_> I assume it's an issue with different codecs. [19:11:46 CEST] <kepstin> Hopper_: those are both the playback logs, you're missing the creation log [19:12:03 CEST] <kepstin> but yeah, looks like it's an unsupported codec in mpegts, so the player can't figure out how to play it [19:12:26 CEST] <Hopper_> Embarrassing. I'll put creation up now. [19:12:30 CEST] <Hopper_> pastebin [19:14:21 CEST] <Hopper_> creation- https://pastebin.com/Teg5ydJ9 [19:14:48 CEST] <Hopper_> I wonder why the ts worked when it was just one video stream but fails with two. [19:15:43 CEST] <alexpigment> for what it's worth - this is anecdotal really - the mpegts muxer fails in a lot of stupid ways in my experience. but it's usually just that the audio doesn't get included in my tests [19:16:04 CEST] <kepstin> dunno, what was your full command and output with one video stream? [19:16:27 CEST] <kepstin> my guess is that you it was just using a different video codec... [19:17:54 CEST] <Hopper_> Sorry for being so slow on the pastebins, the comp I'm using for the encoding isn't networked. [19:19:16 CEST] <Hopper_> Single source- https://pastebin.com/r3ZCvQpM [19:19:31 CEST] <Hopper_> Nope, messed that up again, one sec. [19:21:00 CEST] <kepstin> Hopper_: you didn't include the -vcodec (or -c:v) option on that one, so it defaulted to mpeg2, which is a codec which works fine in mpegts [19:21:14 CEST] <kepstin> the -vcodec output option* [19:21:46 CEST] <kepstin> so yeah, the reason the one with the filter didn't work is because you also changed the output codec from mpeg2 to mjpeg. [19:22:48 CEST] <Hopper_> It works if I let it use the default codec, it just has a TERRIBLE framerate. [19:24:41 CEST] <kepstin> the framerate issues are unrelated to the selected codec - you see all those 'past duration too large' messages? they indicate a framerate problem in the filter graph. [19:25:02 CEST] <Hopper_> So it's an issue with the output of my camera? [19:25:32 CEST] <kepstin> Hopper_: it looks like the cameras are giving you 60fps even though you asked for 30 [19:25:44 CEST] <kepstin> try switching the -framerate option to 60 on both, and see if that helps [19:26:09 CEST] <Hopper_> And the output? [19:26:34 CEST] <kepstin> the output will be 60fps then.. if you want 30, you can add an fps filter [19:27:10 CEST] <wpppp> what is so bad about 60fps? :P [19:27:15 CEST] <wpppp> it is awesome [19:27:18 CEST] <Hopper_> Output started at 15 and is dropping. [19:27:18 CEST] <wpppp> so why less? [19:29:16 CEST] <nicolas17> uh [19:29:33 CEST] <nicolas17> ...are you talking about the fps= in the progress line while ffmpeg runs? [19:30:12 CEST] <Hopper_> Yes, but it is obviously not playing back at 30fps. [19:31:06 CEST] <nicolas17> "frame= 605 fps=16 q=-0.0 Lsize=..." that thing? [19:31:32 CEST] <nicolas17> that 'fps' says how many frames per second ffmpeg is processing, it has nothing to do with the output you will get [19:32:01 CEST] <nicolas17> it lets you know how fast the encoding process is doing [19:32:42 CEST] <Hopper_> I understand, and VLC is playing the file back at 9fps. [19:41:51 CEST] <Hopper_> It looks like my cameras only put out 10fps at 720 when I'm using yuv420p, instead of mjpeg [19:42:23 CEST] <furq> are they usb [19:42:31 CEST] <Hopper_> Yup [19:42:35 CEST] <furq> that's about right then [19:43:14 CEST] <furq> usb2 can't really handle 720p30 rawvideo [19:43:35 CEST] <Hopper_> So would I have to use mjpeg to create a different file type, then convert that file into a .ts? [19:43:53 CEST] <furq> well mpegts can't contain rawvideo either [19:43:57 CEST] <furq> so you'd have to convert it either way [19:44:21 CEST] <furq> ideally you'd use the uncompressed source, but if you're rate limited by usb2, it's probably better to start with mjpeg [19:44:40 CEST] <furq> do you have any requirements for the output other than it being mpegts [19:44:55 CEST] <wpppp> over 802.11, bandwidth is higher than 8mbit/s required [19:44:58 CEST] <wpppp> hm, right [19:45:03 CEST] <wpppp> ohhhh wrong user [19:45:54 CEST] <Hopper_> I don't know about my output requirements fully, I'm using a transcoder to push my stream over the air at 1.2GHz. [19:46:29 CEST] <furq> what's receiving it [19:46:56 CEST] <Hopper_> A computer with receiver. [19:47:08 CEST] <furq> you can presumably use any codec then [19:47:14 CEST] <furq> in which case you probably want to convert it with x264 [19:48:09 CEST] <Hopper_> I'm using a UT-100 if anyone is familiar with that. [19:48:27 CEST] <Hopper_> http://www.hides.com.tw/product_cg74469_eng.html [19:49:10 CEST] <furq> if it's a dvb-t transmitter then h.264 should be supported [19:49:24 CEST] <furq> add -c:v libx264 as an output option [19:49:31 CEST] <furq> it should be faster and look much better than mpeg2video [19:50:21 CEST] <Hopper_> So use -vcodec mjpeg for input and -c:v libx264 for output? [19:50:25 CEST] <furq> yeah [19:50:33 CEST] <BtbN> Isn't dvb-t mpeg2? [19:50:44 CEST] <furq> it can be either [19:51:00 CEST] <Hopper_> So what should my output file type be? [19:51:02 CEST] <BtbN> iirc DVB-T2 added h264 and hevc [19:51:04 CEST] <furq> mpegts [19:51:17 CEST] <kepstin> Hopper_: you're using v4l2 grabbing? The input option you should be using is "-input_format mjpeg", I think [19:51:39 CEST] <furq> i'm pretty sure regular dvb-t is mpeg2video/h.264 and dvb-t2 is h.264/h.265 [19:51:41 CEST] <furq> i'm not an expert though [19:51:56 CEST] <kepstin> if -vcodec works as an input option there, then it must be a weird legacy thing :/ [19:51:58 CEST] <JEEB> you can look at EBU specs or so [19:52:04 CEST] <furq> most countries broadcast m2v over dvb-t but apparently some countries broadcast h.264 over it [19:52:08 CEST] <JEEB> kepstin: it still works I think, it's just not recommended for usage [19:52:17 CEST] <furq> it's probably faster to just see if it works [19:52:23 CEST] <furq> if it doesn't then use -c:v mpeg2video as an output option [19:52:28 CEST] <BtbN> setting the input codec seems like a normal thing to me? [19:52:36 CEST] <BtbN> Like, for example selecting the cuvid decoders [19:52:43 CEST] <furq> yeah that makes more sense to me than input_format [19:53:07 CEST] <furq> i guess it often means "interpret what you get as" rather than "tell the device to send" [19:53:32 CEST] <JEEB> very technically DVB-T is just the way the signal is broadcast. after that it's just data, and generally if you pass MPEG-TS through it if something supports AVC over MPEG-TS in DVB-T2 will also most likely take AVC over MPEG-TS from DVB-T stuff [19:53:40 CEST] <kepstin> BtbN: the input codec option selects which *decoder* to use, yes, that makes sense. But here it's overloaded to mean "have the camera provide a format that's compatible with the decoder I've selected manually", which is strange [19:53:52 CEST] <furq> JEEB: yeah i'm thinking about what the receiver will accept [19:53:57 CEST] <furq> rather than what the transmitter will send [19:54:07 CEST] <furq> i assume the transmitter will send any mpegts stream [19:54:22 CEST] <BtbN> kepstin, maybe it does still do that, and the ffmpeg.c auto graph building then selects the right format from the supported inputs of the decoder? [19:59:06 CEST] <Hopper_> Newest Result- https://pastebin.com/RswnwYGd [19:59:31 CEST] <Hopper_> It's listing the stream output as being 9fps. [20:02:20 CEST] <kepstin> Hopper_: you didn't set the input codec on one of the cameras, and you set the output codecs twice [20:02:44 CEST] <kepstin> Hopper_: input options go *before* the inputs [20:02:52 CEST] <kepstin> before the -i specificall [20:03:11 CEST] <Hopper_> Oh, I do that before -i? [20:03:33 CEST] <nicolas17> yes [20:03:43 CEST] <Hopper_> Thanks, didn't understand that element of the syntax. [20:03:54 CEST] <nicolas17> ffmpeg <input options> -i input.file <output options> output.file [20:03:58 CEST] <nicolas17> or rather [20:04:18 CEST] <kepstin> Hopper_: the command i'd expect you to use is `ffmpeg -f v4l2 -input_format mjpeg -framerate 60 -video_size 1280x720 -i /dev/video0 -input_format mjpeg -video_size 1280x720 -framerate 60 -i /dev/video1 -filter_complex hstack -c:v libx264 outputsplit.ts` [20:04:19 CEST] <nicolas17> ffmpeg <options for input 1> -i input1.file <options for input 2> -i input2.file ... <output options> output.file [20:04:44 CEST] <Hopper_> Thanks! [20:04:59 CEST] <kepstin> Hopper_: you might have to add an `-pix_fmt yuv420p` output option as well, since your cameras are giving you yuv422 [20:05:10 CEST] <kepstin> depends on the dvb specs whether 4:2:2 is allowed I guess [20:05:25 CEST] <nicolas17> why does conversion from yuvj422p give this warning from swscaler? "deprecated pixel format used, make sure you did set range correctly" [20:05:47 CEST] <kepstin> nicolas17: internal deprecated stuff, don't worry about it unless you're developing ffmpeg [20:06:52 CEST] <Hopper_> So Mjpeg must require more cpu power. [20:07:15 CEST] <Hopper_> My little lattepanda is pegged at 100% and it looks far worse than the default codec. [20:07:37 CEST] <kepstin> Hopper_: when using mjpeg you're getting more frames to encode (higher framerate), so yes it needs more cpu power [20:08:09 CEST] <kepstin> 'lattepanda'? oh, gah, are more people doing video encoding on underpowered systems? :( [20:08:37 CEST] <kepstin> you've only got an atom in there :( [20:08:38 CEST] <Hopper_> Yes, but this system will be airborne so I don't have a choice to send up a nice powerful system. [20:09:08 CEST] <kepstin> Hopper_: well, to start, add "-preset veryfast" output option to make the x264 encoder use less cpu [20:09:43 CEST] <kepstin> and as far as quality, well, you have to pick either a bitrate or crf value that's appropriate for your use case; the default is just a sort of "medium quality" [20:10:27 CEST] <nicolas17> how do I achieve a target file size, without caring about bitrate at any particular point in the stream? [20:10:57 CEST] <nicolas17> does that need two-pass? [20:11:00 CEST] <nicolas17> AIUI there are ways to limit max bitrate because some devices/networks can't load the input any faster, but that's not what I need [20:11:15 CEST] <kepstin> nicolas17: do a 2pass encode with bitrate set, yes [20:11:35 CEST] <Hopper_> kepstin: crf value? [20:14:39 CEST] <kepstin> Hopper_: what are you doing with the media stream that you're encodign? sending over network, storing on local hd, ...? [20:15:20 CEST] <Hopper_> Broadcasting OTA. [20:15:48 CEST] <kepstin> ok, directly from that box, not being transferred somewhere else first? [20:16:16 CEST] <kepstin> if you don't want to re-encode again, then you need to look up what the broadcast specs for bitrate are, and then encode to those specs. [20:16:16 CEST] <nicolas17> wait [20:16:29 CEST] <nicolas17> you're encoding stuff, and sending it over the air to a receiver, and what does the receiver do? [20:16:38 CEST] <Hopper_> Correct, but my hope is to save and transmit simultaneously. [20:17:05 CEST] <Hopper_> nicolas17: Saves the file locally and streams it online. [20:17:22 CEST] <kepstin> Hopper_: assuming you're transmitting with DVB, you'll want to set an appropriate bitrate and also do some vbv controls, since it's a fixed bitrate channel... [20:17:35 CEST] <nicolas17> so either your receiver system will have to decode and re-encode to the needs of the online stream [20:18:02 CEST] <nicolas17> or you should make your original sender encode in an online-stream-ready way; but it might not have enough CPU power for that [20:18:05 CEST] <Hopper_> Ya, I know about the bitrate, I'm just trying to sort out the video to make sure it's even possible before nit picking. [20:18:54 CEST] <kepstin> presumably the receiver system on the ground can actually be a reasonably powerful pc, so re-encoding there should be fine if needed. [20:19:03 CEST] <Hopper_> My receiver will have as much power as I need, and I need to keep the transmission lean, since it's not powerful. [20:19:14 CEST] <Hopper_> kepstin: Exactly. [20:20:46 CEST] <kepstin> so yeah, find out how many bits you can get through your transmission channel, then use that to configure the encoder bitrate and vbv settings. [20:22:06 CEST] <thebombzen> Hopper_: do you have to use mpegts? [20:22:09 CEST] <leif> Has anyone else noticed a huge memory spike when they use the `trim` and `atrim` filters? (In the libavfilter library)? [20:23:24 CEST] <Hopper_> thebombzen: That's the firmware for the transmitter requires. [20:23:25 CEST] <leif> Like, when I use it from the command line app, everything works fine. But when I take the same filtergraph to a program using libav, I get a huge memory leak. If I replace trim with, say, copy, the memory leak goes away. [20:23:37 CEST] <thebombzen> Are you re-encoding later? [20:24:08 CEST] <thebombzen> I ask because you could always encode to H.264 in realtime and put that inside mpegts [20:24:13 CEST] <Hopper_> kepstin: 9.952Mbps max data rate on the .ts file. [20:24:32 CEST] <Hopper_> thebombzen: Will I really have the CPU power for that? [20:24:45 CEST] <thebombzen> I cannot answer that question without knowing what CPU model you have [20:24:57 CEST] <DHE> also there are options to reduce CPU power required (with a quality penalty) [20:25:16 CEST] <Hopper_> The preset verfast help tremendously. [20:25:21 CEST] <kepstin> thebombzen: it's a 1.8ghz quad core atom of some vintage [20:25:36 CEST] <thebombzen> but libx264's faster presets should be fast enough for realtime, but they're going to be lower-quality than the slower presets that aren't intended for realtime [20:25:45 CEST] <thebombzen> they should still be better than mpeg2video in quality as well [20:26:00 CEST] <thebombzen> -preset veryfast, for example, will be much faster. [20:26:07 CEST] <thebombzen> and also much better quality than mpeg2video [20:26:26 CEST] <thebombzen> er, not faster, but better quality and fast enough for your needs. [20:26:51 CEST] <thebombzen> if -preset veryfast isn't fast enough, then you can try -preset superfast as well. only go to ultrafast if you have to - it's basically the nuclear option. [20:27:22 CEST] <kepstin> Hopper_: so yeah, I assume your transmitter handles padding internally, so just something like '-b:v 9M -vbv-maxrate 9M -bufsize 18M' or something should be good enough [20:27:24 CEST] <thebombzen> ultrafast is far far faster than superfast and also far far worse quality. usually it's not worth it [20:27:39 CEST] <kepstin> err, '-b:v 9M -maxrate 9M -bufsize 18M' [20:27:48 CEST] <kepstin> I think, always forget those option names? [20:27:53 CEST] <kepstin> probabyl still have it wrong [20:28:03 CEST] <thebombzen> bufsize is right, I have no idea about maxrate [20:29:23 CEST] <kepstin> yeah, it's just -maxrate [20:31:23 CEST] <furq> 19:05:25 ( nicolas17) why does conversion from yuvj422p give this warning from swscaler? "deprecated pixel format used, make sure you did set range correctly" [20:31:34 CEST] <furq> nicolas17: using yuvj pixel formats for full range isn't recommended any more [20:31:42 CEST] <furq> it's recommended to use yuv422p and -color_range [20:31:56 CEST] <furq> yuvj will probably still work though [20:32:06 CEST] <kepstin> furq: sure, but this message is printed without the user manually specifying color ranges at all, in the ffmpeg cli [20:32:17 CEST] <furq> if the source is yuvj then yeah [20:32:36 CEST] <furq> as usual, ffmpeg and the libs disagree on what the right thing to do is [20:32:41 CEST] <kepstin> furq: source is mjpeg, being decoded by ffmpeg :/ [20:32:42 CEST] <furq> or more accurately ffmpeg just doesn't give a shit [20:33:09 CEST] <nicolas17> my source is a folder full of yuvj422p .JPG files [20:35:10 CEST] <furq> does color_range actually do anything as an output option [20:35:18 CEST] <furq> the docs list it as input/output but only document what it does as an input option [20:35:21 CEST] <kepstin> it sounds like the issue is that ffmpeg's mjpeg/jpeg decoder is producing frames containing yuvj422p instead of yuv422p with color range set. [20:35:35 CEST] <furq> well that's expected isn't it [20:35:40 CEST] <nicolas17> what is yuvj anyway? [20:35:57 CEST] <furq> yuv with full colour range [20:36:04 CEST] <kepstin> nicolas17: yuv with the "jpeg" color range (aka full range aka pc range) [20:36:29 CEST] <furq> as opposed to limited/mpeg/tv range [20:36:38 CEST] <furq> which is what video normally uses [20:37:02 CEST] <kepstin> nicolas17: anyways, you don't need to do anything - the decoder's using some deprecated stuff internally, but the scaler is still handling it correctly, so everything works. [20:37:15 CEST] <furq> are you converting to yuv422p [20:37:20 CEST] <furq> or is that being autoinserted [20:39:15 CEST] <nicolas17> furq: if I do nothing, and I just turn this folder of JPEGs into -f mp4 -c:v libx264, I get yuvj422p in the video too, and these warnings: [20:39:24 CEST] <nicolas17> deprecated pixel format used, make sure you did set range correctly [20:39:26 CEST] <nicolas17> No pixel format specified, yuvj422p for H.264 encoding chosen. [20:39:27 CEST] <nicolas17> Use -pix_fmt yuv420p for compatibility with outdated media players. [20:40:07 CEST] <nicolas17> and if I pass "-pix_fmt yuv420p" I get only the first line of warning, about "deprecated pixel format used" [20:40:38 CEST] <furq> that is pretty dumb then [20:41:31 CEST] <nicolas17> I'm not using git master though, I'm on 3.2.6 from Debian testing [20:42:24 CEST] <furq> yeah i'm messing with it on 3.3 [20:42:40 CEST] <furq> i can't find any way to use -color_range to silence that warning [20:42:51 CEST] <Hopper_> So what are the options under -preset, and what do they change? [20:42:52 CEST] <nicolas17> in my little test program using the API, I was using swscale to convert the frame to RGB24 to output a .ppm [20:42:55 CEST] <nicolas17> same warning [20:43:02 CEST] <furq> Hopper_: http://dev.beandog.org/x264_preset_reference.html [20:43:07 CEST] <Hopper_> ty [20:43:27 CEST] <furq> you should generally use the slowest preset that's fast enough [20:43:39 CEST] <furq> depends how much bitrate you have though [20:43:51 CEST] <furq> 9mbit for 720p should be pretty forgiving [20:44:15 CEST] <Hopper_> How do I determine the correct preset based on that table? [20:44:20 CEST] <furq> you don't [20:44:28 CEST] <furq> you run slower presets until one is too slow [20:44:50 CEST] <nicolas17> test until your particular CPU can't keep up with real-time encoding [20:45:04 CEST] <furq> the slow presets are mostly there for archival [20:45:11 CEST] <Hopper_> Okay, I really don't need it to be in real time. [20:45:18 CEST] <furq> or situations where you can't just give it more bitrate [20:45:32 CEST] <kepstin> if you're capturing from a camera in realtime, you kind of do need the encoding to work in realtime? [20:45:37 CEST] <furq> also yeah [20:45:52 CEST] <furq> except without "kind of" [20:46:19 CEST] <Hopper_> That makes sense, jut trying to figure out the most effective method for using ffmpeg. [20:46:20 CEST] <kepstin> well, if it's too slow, you might just get dropped frames and weirdness, but it could still technically work i guess :/ [20:46:35 CEST] <furq> it's more likely you'll just run out of buffer and then it will die [20:46:42 CEST] <furq> either is generally bad [20:47:25 CEST] <furq> veryfast is probably fine for this use case anyway [20:47:27 CEST] <Hopper_> Dropped frames are not that much of an issue for me here. [20:47:29 CEST] <Hopper_> Okay [20:47:34 CEST] <Hopper_> I'll stick with that for now. [20:47:54 CEST] <furq> they'll all look equally good if you give them enough bitrate [20:48:20 CEST] <furq> except maybe ultrafast which pretty much turns everything off [20:52:48 CEST] <Hopper_> Okay, here's the latest function. https://pastebin.com/PqCbXW9Q [20:53:18 CEST] <Hopper_> I run that and it produces and output file just fine, but maxes my cpu which apparently causes some kind of instability and my machine crashes. [20:54:19 CEST] <nicolas17> oh, two cameras? [20:54:23 CEST] <Hopper_> Yup [20:54:39 CEST] <nicolas17> in what computer did you run that? in the one that will be the sender? [20:54:45 CEST] <Hopper_> Yes [20:55:15 CEST] <nicolas17> how much RAM do you have? [20:55:29 CEST] <nicolas17> seems unlikely to be a RAM-heavy encode, but... [20:55:57 CEST] <nicolas17> (slower presets keep more frames in memory and can use a lot; you're in veryfast, that shouldn't happen) [20:58:06 CEST] <Hopper_> It doesn't seem to be ram, watching the resources CPU is maxed ram is just over half. [21:00:34 CEST] <Hopper_> Can I reduce the framerate somewhere? It seems to be keeping far more frames than needed. [21:02:11 CEST] <nicolas17> I don't think -framerate is a valid output option [21:02:22 CEST] <nicolas17> try -r 30 for the output instead of -framerate 30 [21:02:50 CEST] <nicolas17> for some reason it's grabbing 120fps from video0, and making the output framerate 120 too [21:03:10 CEST] <Hopper_> That's it! [21:03:35 CEST] <Hopper_> That reduced my cpu usage by ~30%! [21:03:55 CEST] <nicolas17> if the input and filter is really producing 120fps, using -r 30 in the output will drop frames to reach 30fps [21:04:34 CEST] <nicolas17> I was going to suggest going from 30 to 15fps as a test, then I realized from your paste that it was currently using 120 instead of 30 :P [21:04:57 CEST] <Hopper_> Ya, that ends up being great, can I get it to only use 30 on the input to save even more overhead? [21:05:03 CEST] <Hopper_> Or is that what it is doing now? [21:05:21 CEST] <nicolas17> I don't know why it's grabbing from video0 at 120fps and from video1 at 30fps, you have the same options on both [21:06:27 CEST] <furq> [video4linux2,v4l2 @ 0x1bcc740] The driver changed the time per frame from 1/30 to 513/61612 [21:06:30 CEST] <furq> wtf [21:06:33 CEST] <Hopper_> They are different pieces of hardware, but I do have the same input specified, like you said. [21:07:00 CEST] <nicolas17> "the driver ignored your request and did whatever it felt like doing" [21:07:02 CEST] <nicolas17> great [21:07:36 CEST] <Hopper_> That's what I get for using a no name camera. [21:08:07 CEST] <nicolas17> anyway, x264 encoding will be the most CPU-intensive part, and you're now doing that at 30fps [21:08:25 CEST] <nicolas17> I think you wouldn't gain much more by making the input 30fps too [21:08:36 CEST] <furq> fyi if you're doing 480p then you should be able to use rawvideo instead of mjpeg [21:08:47 CEST] <furq> that might inadvertently fix the framerate issue as well [21:09:16 CEST] <Hopper_> furq: I kept knocking the res down to make it functional. [21:09:16 CEST] <nicolas17> oh, get raw video from the cameras? [21:09:19 CEST] <furq> that will be marginally faster and higher quality [21:09:43 CEST] <nicolas17> it's definitely worth a try [21:09:45 CEST] <Hopper_> Here's the misbehaving camera. http://a.co/cKGGsiG [21:10:09 CEST] <Hopper_> Raw wont take more CPU power? [21:10:19 CEST] <furq> it'll take less [21:10:33 CEST] <nicolas17> will take more USB bandwidth, but at 640x480 it probably can cope [21:10:35 CEST] <furq> the issue with rawvideo over usb2 is the data rate [21:10:39 CEST] <furq> but at 480p it should be fine [21:10:40 CEST] <Hopper_> Let's hope the USB bus has enough IO for that. [21:10:43 CEST] <furq> right [21:10:49 CEST] <nicolas17> worth a try in any case [21:11:17 CEST] <furq> 480p30 yuv420p is only about 110mbps [21:11:19 CEST] <furq> which should be fine [21:11:26 CEST] <furq> usb2 is normally good for 250ish [21:11:47 CEST] <Hopper_> so -vcodec what? [21:11:54 CEST] <furq> nothing [21:11:57 CEST] <furq> get rid of -vcodec [21:12:00 CEST] <furq> it should default to rawvideo [21:12:02 CEST] <Hopper_> Okay [21:12:43 CEST] <nicolas17> furq: on some devices like the raspberry pi you would need to fit both cameras into that 250 [21:12:44 CEST] <Hopper_> 146Mbps [21:12:58 CEST] <furq> this is a pc iirc [21:12:59 CEST] <nicolas17> since all USB ports end in a hub [21:13:33 CEST] <furq> oh right it's yuv422p [21:13:41 CEST] <furq> 146mbps is right then [21:14:14 CEST] <nicolas17> if this device has actual independent usb2 ports, that should work fine [21:14:37 CEST] <furq> i guess we'll find out [21:15:10 CEST] <Hopper_> It's functioning but I'm getting LOTS of "past duration too large" lines. [21:15:23 CEST] <furq> you can usually ignore those [21:15:50 CEST] <furq> as long as the output looks ok and you're still encoding at realtime [21:16:11 CEST] <Hopper_> It seems just fine. [21:16:53 CEST] <nicolas17> what CPU%? [21:16:57 CEST] <Hopper_> This method uses less CPU, but seems to be more volatile, there are ore spikes. [21:16:58 CEST] <furq> add -v error if you want to shut those warnings up [21:17:17 CEST] <furq> and yeah if you have >2 usb ports you might want to switch the ports you're using around [21:17:21 CEST] <Hopper_> Thanks, I might do that. [21:17:30 CEST] <Hopper_> Why switch the ports? [21:17:37 CEST] <furq> you'll want the devices on different hubs [21:17:50 CEST] <Hopper_> ~58% cpus average. [21:18:10 CEST] <nicolas17> if both cameras are connected to a single (possibly internal) hub, your USB I/O will be quite more limited [21:18:11 CEST] <Hopper_> One is on the usb2 one is on the usb1, I assume they're different busses, I didn't check. [21:18:41 CEST] <nicolas17> oh, usb1? I'd probably keep that one as mjpeg :D [21:19:08 CEST] <Hopper_> It seems to be functioning, why would there be an issue? [21:19:09 CEST] <nicolas17> you mean usb 1.1 standard, or "ports 1 and 2"? [21:19:14 CEST] <Hopper_> 1.1 [21:19:20 CEST] <Hopper_> A not-blue port. [21:19:38 CEST] <nicolas17> I thought blue meant usb3 [21:20:03 CEST] <Hopper_> I'm wrong! it's usb 3 and usb 2. [21:20:12 CEST] <Hopper_> nicolas17: Good call. [21:20:15 CEST] <nicolas17> yeah that makes more sense [21:20:20 CEST] <nicolas17> usb1 is 12Mbps, it certainly won't cope with rawvideo [21:21:40 CEST] <Hopper_> Can't do 720 in raw, the driver dropps the framerate to 9. [21:21:52 CEST] <furq> yeah that's way too much [21:21:56 CEST] <furq> for 720 you'll need mjpeg [21:22:06 CEST] <Hopper_> Okay, [21:22:15 CEST] <nicolas17> can ffmpeg decode on separate threads? [21:22:21 CEST] <furq> width * height * bpp * framerate [21:23:08 CEST] <furq> (1280 * 720 * 16 * 30) / 1000000 = much more than 300 [21:23:21 CEST] <furq> 442 apparently [21:27:02 CEST] <Hopper_> What do the brown past duration lines actually mean? [21:27:11 CEST] <thebombzen> furq: fyi, sometimes cameras will output 10 fps for rawvideo even if USB2 should be able to handle 30 fps [21:27:35 CEST] <thebombzen> also, where did you get 16 bits per pixel? [21:27:39 CEST] <furq> yuv422p [21:27:54 CEST] <thebombzen> *does some quick arithmetic* [21:28:19 CEST] <furq> http://vpaste.net/ZXbYK [21:28:23 CEST] <furq> hi [21:28:58 CEST] <thebombzen> yea, 422@8 is 16bpp [21:29:03 CEST] <thebombzen> just did the arithmetic [21:29:11 CEST] <thebombzen> although it's probably yuyv422 rather than yuv422p [21:29:22 CEST] <thebombzen> I haven't seen yuv422p in a while [21:29:30 CEST] <kepstin> Hopper_: basically, those 'past duration' lines mean that for some reason, frames are being output from the filter chain faster than the framerate ffmpeg was configured for, and it's therefore dropping them [21:29:55 CEST] <kepstin> Hopper_: if one of your cameras is outputting higher fps than you asked it to, that might cause that message. [21:30:28 CEST] <Hopper_> Heh, ya the one that's spitting out 120 even when I asked the driver for 30. [21:30:50 CEST] <thebombzen> You might want to prepend an fps filter before you feed it to hstack [21:30:55 CEST] <furq> is it still doing 120 with rawvideo [21:31:10 CEST] <Hopper_> What furq said. [21:31:21 CEST] <thebombzen> and fps filter will duplicate/drop frames to force a constant framerate [21:31:29 CEST] <thebombzen> so if you're receiving 120 and only wnat 30, fps=30 will drop frames to get 30 [21:35:35 CEST] <Hopper_> One of my cameras is on a slight delay, I assume that's driver based and not ffmpeg, right? [21:35:45 CEST] <nicolas17> probably [21:36:35 CEST] <kepstin> Hopper_: ffmpeg opens the inputs one at a time, so there can be a slight delay on one if the first is slow to initialize, i guess. [21:40:09 CEST] <Hopper_> You folks are awesome, thanks so much for all of your help. I'm certainly not done, but want to show my appreciation for all of your efforts so far. [21:40:53 CEST] <Hopper_> And thanks to this wonderful community ffmpeg will be getting a donation from me. [22:00:31 CEST] <danieeel> the i420 format is full-range or limited range? i can not get my picture to be shown correctly :/ [22:01:09 CEST] <kepstin> danieeel: could be either, you need additional metadata to know. I'd expect it to normally be limited range when dealing with video. [22:01:21 CEST] <furq> there is no such format in ffmpeg [22:01:26 CEST] <furq> but yeah it's probably limited range [22:01:42 CEST] <kepstin> i420 is equivalent more or less to yuv420p in ffmpeg, yeah [22:01:50 CEST] <furq> it could be yuvj420p though right [22:01:58 CEST] <danieeel> yes, it is yuv420p [22:02:10 CEST] <furq> that's limited range then [22:02:14 CEST] <BtbN> yuvj420p is just yuv420p with jpeg color range. The pixel format is identical [22:02:18 CEST] <furq> right [22:02:20 CEST] <kepstin> but yuvj420p is deprecated, it should be yuv420p with the range set appropriately ;) [22:02:24 CEST] <furq> i420 by itself isn't enough information [22:02:33 CEST] <furq> yuv420p is definitely limited range though [22:02:46 CEST] <furq> kepstin: i still haven't figured out how you set the range appropriately [22:02:49 CEST] <BtbN> it's nothing. The color_space defines what it is [22:03:00 CEST] <furq> do you mean -color_range [22:03:09 CEST] <BtbN> something like that [22:03:10 CEST] <furq> i'm yet to figure out how to make that do anything [22:03:15 CEST] <kepstin> furq: it's api internal stuff, not exposed on ffmpeg cli, really, aside as options to the scaler filters [22:03:20 CEST] <furq> the docs are incredibly unclear about it [22:03:32 CEST] <danieeel> when i export a frame from a broadcast camera it shows luma range 17-255 [22:03:39 CEST] <furq> er [22:03:42 CEST] <danieeel> from mp4 [22:04:21 CEST] <kepstin> danieeel: most limited range video contains overshoot above white or below black, that's normal [22:04:25 CEST] <kepstin> it'll be clipped during playback [22:05:50 CEST] <nicolas17> what is AVProgram for? [22:07:16 CEST] <danieeel> btw the choice of 601/709 standard and others can be enforced some way? (use case: read my raw and convert to rgb.... as reference checker) [22:08:24 CEST] <JEEB> there's a colorspace filter in libavfilter, and then there's the zscale filter that does colorspace conversions and scaling with the zimg library [22:08:49 CEST] <thebombzen> what's the recommended denoise filter of the day? [22:08:50 CEST] <JEEB> I haven't used the colorspace filter myself, but it seems like some people like it. zimg is what I've been planning to use in my own things [22:09:24 CEST] <thebombzen> JEEB: doesn't swscale also do colorspace converstion? [22:09:42 CEST] <thebombzen> but yea what is the denoise filter that is recommended nowadays? there's a whole bunch of them [22:09:48 CEST] <nicolas17> hmph [22:09:51 CEST] <JEEB> yes, but I'm pretty much not sure it follows colorspace information [22:10:03 CEST] <nicolas17> I created an output format context with avformat_alloc_output_context2 [22:10:07 CEST] <JEEB> nor am I sure that even if it does that, that I would want to use swscale [22:10:11 CEST] <JEEB> I've used swscale before :P [22:10:13 CEST] <nicolas17> added a video stream to it with avformat_new_stream [22:10:20 CEST] <nicolas17> then called avformat_init_output [22:10:29 CEST] <nicolas17> warning: Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. [22:11:17 CEST] <nicolas17> was I supposed to set anything in AVStream.codecpar myself? I didn't touch any fields, dunno why it's complaining that I'm using AVStream.codec [22:13:00 CEST] <JEEB> unless you're using that thing yourself it's an internal issue due to the usage of that variable [22:18:57 CEST] <nicolas17> okay, I guess it complained because I *didn't* set things in codecpar [22:19:07 CEST] <nicolas17> so it warned, and looked at codec (where I hadn't set anything either) [22:38:01 CEST] <furq> thebombzen: probably hqdn3d [22:38:32 CEST] <thebombzen> I did a quick test of atadenoise, hqdn3d, and pp=tn just to see [22:38:35 CEST] <furq> or nlmeans but iirc that's really slow in lavf [22:38:52 CEST] <furq> there's an opencl version in vapoursynth that i've used before [22:38:55 CEST] <thebombzen> I found that hqdn3d was the most effective at denoising but it also was kind of blurry [22:39:07 CEST] <furq> try nlmeans [22:39:18 CEST] <furq> do it quick before durandal_1707 shows up and tells us it's only for animes [22:39:33 CEST] <thebombzen> eh, I'll keep that in mind [22:39:34 CEST] <nicolas17> furq: hush, don't highlight them [22:39:39 CEST] <furq> it isn't only for animes [22:40:01 CEST] <thebombzen> well if it's best at that, I'll keep that in mind. but speaking of things only useful for anime, the video I had was really noisy and nothing in lavfi really could handle it [22:40:09 CEST] <furq> it isn't even best at that afaik [22:40:14 CEST] <furq> not that i'd know [22:40:15 CEST] <furq> animes are bad [22:40:27 CEST] <thebombzen> so I ended up dumping the frames and batch filtering through waifu2x [22:40:42 CEST] <thebombzen> slow as fuck, but kind of the nuclear option cause the video was so noisy [22:41:17 CEST] <thebombzen> it works even on non-anime stuff too, even though it's designed to remove JPEG crud and not actual noise [22:41:45 CEST] <nicolas17> nice [22:41:48 CEST] <durandal_1707> you havent tried vaguedenoiser [22:41:54 CEST] <thebombzen> correct, I have not [22:41:56 CEST] <nicolas17> does waifu2x *need* a GPU? [22:41:56 CEST] <thebombzen> what is that [22:42:15 CEST] <thebombzen> nicolas17: no, but it's not fast enough to batch process large amounts of images without one [22:42:30 CEST] <thebombzen> mine has CUDA support compiled in. I'm already half-done processing the ~3000 frames [22:42:48 CEST] <durandal_1707> thebombzen: for animes [22:42:48 CEST] <nicolas17> I'll need The Cloud then [22:43:08 CEST] <nicolas17> my laptop has an Intel integrated GPU [22:43:45 CEST] <thebombzen> durandal_1707: that answers what it's for but not what it is [22:43:50 CEST] <thebombzen> is vaguedenoiser a filter in lavfi? [22:43:57 CEST] <furq> !filter vaguedenoiser [22:43:57 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#vaguedenoiser [22:44:37 CEST] <thebombzen> how does vaguedenoiser stack up to waifu2x as a denoiser? [22:44:50 CEST] <thebombzen> also does it work in realtime? [22:45:01 CEST] <nicolas17> how do I encode video with the API? [22:45:40 CEST] <nicolas17> to demux I just pass a URL to avformat_open_input, to mux I don't see anything getting a URL, do I need to create my own IOContext and stuff? [22:45:57 CEST] <durandal_1707> is waifu2x rt? [22:48:46 CEST] <durandal_1707> vaguedenoiser could be speed up with frame threading [22:52:58 CEST] <furq> you mean like with vapoursynth [22:53:39 CEST] <thebombzen> is it rt? I'm not sure what you mean by rt [22:53:49 CEST] <thebombzen> oh realtime [22:53:52 CEST] <thebombzen> no it's not [22:54:16 CEST] <thebombzen> does vaguedenoiser work as effectively as a denoiser as waifu2x? and does vaguedenoiser work in realtime? [22:56:22 CEST] <durandal_1707> i dunno who is your waifu [22:59:24 CEST] <thebombzen> durandal_1707: I don't have a waifu. I just meant at denoising anime screenshots [23:00:59 CEST] <thebombzen> durandal_1707: what are the value ranges of vaguedenoiser's threshold? [23:02:03 CEST] <durandal_1707> ffmpeg -h filter=vaguedenoiser [23:02:39 CEST] <thebombzen> well it goes from 0 to DBL_MAX [23:02:42 CEST] <thebombzen> what are *sane* values? [23:03:14 CEST] <thebombzen> durandal_1707: I assume I'm not supposed to enter 7.8 * 10^9 [23:04:15 CEST] <durandal_1707> something up to 15 [23:06:18 CEST] <leif> I'm tryin to figure out a memory leak whenever I use the 'trim' filter (as mentioned a few hours ago), anyway, it looks like I get an EOF on the output buffer, but the input buffer still seems to happily accept packets. Is that expected behavior? [23:06:24 CEST] <leif> errr...frames, not packets. [23:06:29 CEST] <leif> It still accepts frames [23:09:19 CEST] <durandal_1707> leif: full comnand line output missing [23:12:30 CEST] <leif> durandal_1707: I'm using the libavfilter API rather than the command line. [23:12:58 CEST] <leif> The command line output isn't particularly illuminating, here it is: [23:13:12 CEST] <leif> https://gist.github.com/LeifAndersen/74a0eeff053ee6f425a3c87b681c73ed [23:14:47 CEST] <thebombzen> durandal_1707: Thanks. It wasn't quite realtime, but it worked well [23:15:00 CEST] <thebombzen> I discovered that waifu2x doesn't have temporal consistency so it's not good to use on framedumps [23:15:12 CEST] <thebombzen> it works fine on individual images though [23:18:26 CEST] <leif> Hmm...looking at ffmpeg.c's `transcode_from_filter` function, it looks like once a sink returns EOF, you're supposed to stop putting frames into the source. [23:18:44 CEST] <leif> Now I just need to figure out how to map sinks to their sources (in case of the copy/acopy filter) [23:18:47 CEST] <leif> Anyway, thanks. [23:20:58 CEST] <leif> Oh.... `av_buffersrc_get_nb_failed_requests`...so that's what that's used for. :) [00:00:00 CEST] --- Thu Jul 6 2017

1 0

ffmpeg-devel.log.20170704
by burek 05 Jul '17

05 Jul '17

[01:11:27 CEST] <atomnuker> durandal_1707: better just mark the function as sse4 since its been around for 11 or so years now [09:23:44 CEST] <cone-829> ffmpeg 03Paul B Mahol 07master:c3f10ea4bb04: avcodec/alsdec: remove unused header [09:25:51 CEST] <cone-829> ffmpeg 03Paul B Mahol 07master:cbbd330abc95: avcodec/alsdec: fix some undefined shifts [10:00:59 CEST] <durandal_1707> isnt aac-sls storing lossless part in separate stream? [10:11:10 CEST] <wm4> API question: we're doing some kind of live streaming with HLS (with ffmpeg being on both muxing and demuxing side), which involves a sliding window of active content [10:11:19 CEST] <wm4> apparently HLS has mechanisms for that, but there's no API that could be used to let the HLS demuxer report the current window start/end to the API user [10:11:26 CEST] <wm4> any ideas [10:22:51 CEST] <cone-829> ffmpeg 03Paul B Mahol 07master:1212041c91b7: avfilter/vf_ssim: use unsigned so result can be properly stored [13:21:28 CEST] <wm4> jkqxz: does that patch apply to ffmpeg too? [13:22:42 CEST] <jkqxz> Maybe? I didn't try. [13:23:11 CEST] <wm4> would be more convenient because I have my ffmpeg build configured to link to mfx [13:26:13 CEST] <wm4> it did [13:26:31 CEST] <wm4> jkqxz: what's the command line for it? [13:27:53 CEST] <jkqxz> "-hwaccel d3d11va -hwaccel_output_format d3d11 -i in.mp4 -an -vf 'hwmap=derive_device=qsv,format=qsv' -c:v h264_qsv -frames:v 1000 out.mp4" [13:29:51 CEST] <wm4> jkqxz: Error during encoding: device failed (-17) [13:31:56 CEST] <jkqxz> Ha. [13:32:14 CEST] <jkqxz> A third behaviour, then. [13:33:47 CEST] <wm4> using h264_qsv without any hw stuff works [13:34:12 CEST] <jkqxz> Does it work with dxva2? [13:34:25 CEST] <jkqxz> (Replace above with "-hwaccel dxva2 -hwaccel_output_format dxva2_vld".) [13:35:54 CEST] <wm4> different error [13:36:10 CEST] <wm4> Error in child device handle setup: type mismatch (3 != 1) [13:36:15 CEST] <jkqxz> Oh, you need to do that on vanilla. [13:36:31 CEST] <jkqxz> The patch breaks DXVA2 because I didn't sort out how to manage the differences. [13:38:47 CEST] <wm4> I get tons of get_buffer failures [13:45:58 CEST] <jkqxz> Running out of surfaces? [13:57:34 CEST] <wm4> possibly [13:58:41 CEST] <wm4> or leaking them [13:58:48 CEST] <wm4> encoding a small number of frames makes it work [13:59:39 CEST] <jkqxz> Ohyeah, ffmpeg h264_qsv defaults to 9001 frames of lookahead. [14:00:03 CEST] <jkqxz> -look_ahead 0 [14:01:15 CEST] <BBB> 9000 frames lookahead o_O [14:02:38 CEST] <jkqxz> Well, some number which is, relatively speaking, over nine thousand. It might atually be 50 or something. [14:02:52 CEST] <wm4> it doesn't find a -look_ahead option [14:03:35 CEST] <nevcairiel> if your qsv sdk is too old its not available [14:03:47 CEST] <nevcairiel> otherwise it should be called look_ahead [14:04:12 CEST] <jkqxz> This one: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/qsvenc_h264.c;h=3…>. [14:04:19 CEST] Action: J_Darnley loves that vintage meme [14:17:06 CEST] <iive> over 9000 ! [15:12:20 CEST] <cone-362> ffmpeg 03Kevin Mark 07master:d32a6c36e44c: libavfilter/scale2ref: Maintain main input's DAR [15:19:26 CEST] <durandal_1707> atomnuker: im adding 960 support to aac decoder and ffmpeg stills decodes with frequency response lower than faad2 [15:20:02 CEST] <durandal_1707> all frequencies are lower than they should be [15:21:00 CEST] <atomnuker> oh hey I did some work on that too [15:21:06 CEST] <atomnuker> I almost got it to run as well [15:21:40 CEST] <atomnuker> anyway, just add a 960 mdct context and a 120 mdct context [15:21:55 CEST] <atomnuker> change the nb_samples on the output depending on whether short_frame is on [15:22:01 CEST] <nevcairiel> i was told some time ago that its still more work then just replacing the mdct [15:22:51 CEST] <atomnuker> set the mdct scale to be the same as the mdct480 transform [15:23:14 CEST] <atomnuker> and write a new imdct_and_windowing function [15:23:36 CEST] <atomnuker> I got as far as to change all the windowing to what I believe to be right and almost got correctly decoded stuff [15:24:01 CEST] <atomnuker> but the issue was the tables [15:24:13 CEST] <atomnuker> the tables need to be either rewritten or patched [15:24:31 CEST] <atomnuker> some tabled have the last entry set to 0 and some are completely different [15:26:51 CEST] <atomnuker> search for 960 in ISO 13818-7, that has all the tables [15:30:04 CEST] <atomnuker> durandal_1707: here's my diff https://pars.ee/temp/aac_960.diff [15:38:02 CEST] <atomnuker> the only 960 sample I have is that weird 20sec lounge music which seems to have SBR as well [15:38:29 CEST] <atomnuker> (and oddly enough SBR works as is, without any changes) [15:38:42 CEST] <atomnuker> maybe my window is wrong as well [15:44:03 CEST] <J_Darnley> WTF! That VC2 reference encoder needs boost?! What a POS! [15:45:45 CEST] <JEEB> :D [15:46:53 CEST] <wm4> whatever vc2 is, it's probably a POS too [15:47:14 CEST] <J_Darnley> also known as Dirac, a "professional" video format [15:47:19 CEST] <wm4> oh [15:47:22 CEST] <kierank> J_Darnley: oh forget about the reference encoder [15:47:26 CEST] <kierank> seriously it's a world of pain [15:47:37 CEST] <kierank> atomnuker can tell you [15:47:49 CEST] <J_Darnley> No. I need a correct video file. [15:48:22 CEST] <J_Darnley> One that is supposed to have slices [15:48:28 CEST] <kierank> ffmpeg can do that [15:49:02 CEST] <kierank> seriously the reference encoder is near-impossible to use [15:49:11 CEST] <atomnuker> there is no special sliced version of dirac, it always has slices and they're all individually decodable [15:49:27 CEST] <kierank> yeah it's not like h264 [16:17:13 CEST] <J_Darnley> You were right. It is even more rubbish than I thought. [16:17:38 CEST] <J_Darnley> 4fps and a file 10x bigger than ffmpeg's [16:17:50 CEST] <J_Darnley> even then ffmpeg cannot decode it [16:37:19 CEST] <J_Darnley> I have no idea what's wrong [16:40:47 CEST] <J_Darnley> changing the strides just makes it worse [16:41:24 CEST] <kierank> can you push your latest code and I will look [16:41:40 CEST] <J_Darnley> It is already on gitlab, apparently [16:45:26 CEST] <kierank> i would still suggest implementing your own naive haar [16:53:41 CEST] <kierank> J_Darnley: i think the dsp functions assume stuff you can't assume per slice [17:13:02 CEST] Action: J_Darnley signs [17:13:09 CEST] <J_Darnley> well I sigh [17:47:51 CEST] <durandal_1707> atomnuker: i dont see 960 related numbers in that pdf [17:50:27 CEST] <atomnuker> durandal_1707: they start on page 62 (as printed on the pdf) or page 73 (as total document page number goes) [17:56:59 CEST] <durandal_1707> atomnuker: those are for 128 [18:00:56 CEST] <atomnuker> durandal_1707: actually you're right, check out page 561 in 2010318163752818.pdf [18:04:33 CEST] <durandal_1707> atomnuker: gone from net [18:05:49 CEST] <atomnuker> durandal_1707: https://0x0.st/0y2.pdf [18:15:36 CEST] <J_Darnley> atomnuker, kierank: where can I find the basic description of the haar transform? I couldn't see it in the two BBC papers I have [18:15:44 CEST] <kierank> J_Darnley: in the spec, no? [18:17:15 CEST] <atomnuker> yeah, I think the spec has 'em [18:17:25 CEST] <J_Darnley> where did I put that then [18:17:28 CEST] <atomnuker> or just look at the forward transforms and change the signs IIRC [18:19:28 CEST] <J_Darnley> oh right, I got it from your NAS so it won't be in my d/l folder [18:44:23 CEST] <J_Darnley> up yours Telenet [19:00:35 CEST] <atomnuker> 53 euro for unlimited 200mbps with only 20mpbs upload? [19:01:15 CEST] <atomnuker> well its not much better here, in fact its worse [19:02:11 CEST] <atomnuker> I miss getting 150mpbs symmetric unfiltered ftth for 15 euros [19:03:55 CEST] <J_Darnley> It isn't the worst advertised but their infrastructure leaves much to be desired. [19:04:05 CEST] <JEEB> 100/10 in my case for 49 [19:04:16 CEST] <JEEB> would go 1000/10 for like 70 or 80 [19:04:37 CEST] <BtbN> 10 Mbit upload can't even saturate 1Gbit down [19:05:02 CEST] <JEEB> yea [19:05:05 CEST] <J_Darnley> UDP man! No need to send any acks! [19:05:11 CEST] <JEEB> :D [19:06:45 CEST] Action: J_Darnley goes afk [19:13:44 CEST] <durandal_1707> atomnuker: so whats missing for 960 case? [19:23:09 CEST] <atomnuker> fix the tables where actually needed and investigate why the window seems wrong (makes a spike every 20msec) [19:23:43 CEST] <atomnuker> in the opposite order of importantness, the tables will work as they are [19:24:06 CEST] <atomnuker> (just won't be correct/up to spec but they'll sound alright) [19:26:00 CEST] <durandal_1707> with sinc sample i have i only see different spectrum comparing to faad2/fdk output [19:26:25 CEST] <durandal_1707> eg its have some artefacts but not spikes [19:26:42 CEST] <atomnuker> you do use the 960 transform, right? [19:26:48 CEST] <atomnuker> what's the scaling factor you have? [19:26:51 CEST] <durandal_1707> yes [19:26:53 CEST] <atomnuker> (mine is wrong too) [19:28:02 CEST] <atomnuker> try -1.f/(16*1024*480) for the 960 transform [19:28:40 CEST] <atomnuker> and -1.f/(16*1024*3840) for the 120 transform [19:34:22 CEST] <durandal_1707> worse [19:39:48 CEST] <durandal_1707> if i multiply 960 one with 2 i get perfect result for long part [19:40:07 CEST] <atomnuker> okay, then its that [19:40:42 CEST] <atomnuker> according to peloverde the only way to know the correct scale is to trial and error until it sounds correct [19:41:12 CEST] <atomnuker> (certainly helped for opusenc, 68 << transform size is weird but works exactly) [19:42:56 CEST] <durandal_1707> atomnuker: you forgot to increase buffer pointer for half case [19:43:11 CEST] <durandal_1707> thats source of artifacts [19:44:16 CEST] <atomnuker> huh [19:44:21 CEST] <atomnuker> so it sounds right now? [19:47:50 CEST] <durandal_1707> i get frequencies which shouldnt be there [19:49:31 CEST] <atomnuker> spectrogram? [19:51:43 CEST] <durandal_1707> https://transfer.sh/15Wwmp/o.png [19:52:32 CEST] <durandal_1707> left is ffmpeg [19:55:05 CEST] <atomnuker> hm, do you have the original uncompressed sample somewhere? [20:01:13 CEST] <durandal_1707> no, i have only what faaad and fdk decompress and its same [20:03:10 CEST] <atomnuker> are they audiable? [20:06:16 CEST] <durandal_1707> nope [20:07:03 CEST] <durandal_1707> do you have better sample? [20:08:08 CEST] <atomnuker> durandal_1707: https://pars.ee/temp/2013_03_02_16.49.29_LoungeFM.DAB_.mp4 [20:47:07 CEST] <durandal_1707> atomnuker: i get very bad artifacts with that one, something is not right with your code [20:50:31 CEST] <atomnuker> durandal_1707: maybe its because this is SBR [20:50:40 CEST] <atomnuker> could you give me your sample? [20:51:45 CEST] <durandal_1707> if its SBR it should report that somehow [20:52:07 CEST] <atomnuker> it is SBR [21:00:11 CEST] <durandal_17> atomnuker: http://streams.videolan.org/Mpeg_Conformance/ftp.iis.fhg.de/mpeg4audio-conf… [21:01:32 CEST] <durandal_17> specifically: http://streams.videolan.org/Mpeg_Conformance/ftp.iis.fhg.de/mpeg4audio-conf… [21:03:48 CEST] <atomnuker> durandal_17: seems like they do a lowpass [21:04:13 CEST] <atomnuker> and it seems like SBR needs to be adjusted for 960 so it doesn't work [21:04:27 CEST] <atomnuker> (SBR does stuff in the time domain so it'll be a pain) [21:15:12 CEST] <durandal_1707> why it reports sbr -1 [21:15:49 CEST] <atomnuker> dunno, broken sample maybe [21:16:13 CEST] <atomnuker> its cut from a larger one and AFAIK SBR data is not sent on every frame [21:22:55 CEST] <durandal_1707> atomnuker: it doesnt look so complicated, how other decoders managed it.. [21:40:22 CEST] <durandal_1707> also this sbr is very generic [21:50:24 CEST] <durandal_1707> atomnuker: for example if i decode 960 as 1024 i get no artifacts at all [21:54:38 CEST] <atomnuker> yes, but everything is slowed down [22:02:55 CEST] <cone-835> ffmpeg 03Martin Storsjö 07master:d086e40459ab: lavf: Remove codec_tag from dashenc and smoothstreamingenc [22:02:56 CEST] <cone-835> ffmpeg 03John Stebbins 07master:95f3c85976ff: movenc: use correct tag list for AVOutputFormat.codec_tag [22:03:01 CEST] <durandal_1707> atomnuker: and disabling sbr have minimal effect [22:04:58 CEST] <atomnuker> huh, so maybe its the window then [22:05:14 CEST] <atomnuker> yep, it probably is, I don't do LONG_START and LONG_END [22:21:42 CEST] <durandal_1707> i think it does [22:22:09 CEST] <atomnuker> no, it doesn't, the shape of the window is different [22:22:16 CEST] <atomnuker> and the decoder only has tables [22:22:30 CEST] <atomnuker> so there's nothing to handle 960 sample windows [22:22:40 CEST] <atomnuker> hence you get artifacts [22:23:53 CEST] <durandal_1707> so whats missing? [22:26:26 CEST] <atomnuker> nevermind, the function does something clever so it doesn't have to have tables to do transitions [22:27:30 CEST] <atomnuker> so dunno what's missing, but on my sample it sounds like the window has an issue [22:27:48 CEST] <atomnuker> maybe its using some other feature like tns [22:50:24 CEST] <dcherednik> atomnuker: Hi! About dcaenc and fft function. I had a chat with author of original dcaenc codec. He told that indeed, function named fft is not fft function ) [22:53:26 CEST] <atomnuker> dcherednik: yep, certainly looks like a forward mdct (2x in, 1x out) [22:53:34 CEST] <dcherednik> Yep [22:58:56 CEST] <atomnuker> apparently he wrote it fixed point because of arm almost 10 year ago [22:59:00 CEST] <atomnuker> little did he know... [23:01:24 CEST] <dcherednik> atomnuker: Moreover, situation with psychoacoustic model also is not good [23:02:53 CEST] <dcherednik> atomnuker: so, I am thinking about porting musepack psychoacoustic... It also should be suitable for mp2 encoder... [23:05:42 CEST] <dcherednik> Or this is overkill? [23:09:44 CEST] <atomnuker> dcherednik: musepack? [23:14:27 CEST] <dcherednik> https://www.musepack.net/ Probably this is one of the best subband encoders [23:14:46 CEST] <atomnuker> no, we don't need a fourth psychoacoustic system in ffmpeg [23:14:54 CEST] <atomnuker> use the AAC encoder one [23:15:02 CEST] <atomnuker> just use it to get the energy per band [23:15:11 CEST] <atomnuker> and the thresholds, it'll be all you need [23:15:24 CEST] <atomnuker> you'll have to convert the encoder to use floats though [23:16:13 CEST] <dcherednik> Ok. [23:20:44 CEST] <dcherednik> If I use AAC psychoacoustic can I consider filterbank aliasing? [23:21:22 CEST] <dcherednik> Ou. It looks I can [23:22:30 CEST] <atomnuker> you can also just use the functions that the aac psychoacoustic system calls directly, it uses a bunch of QMFs internally IIRC [23:23:10 CEST] <atomnuker> (if you don't care about masking effects which can be pretty important in these codecs) [23:38:18 CEST] <atomnuker> basing a codec on mpeg2 audio, this was begging to see no usage anywhere [23:42:33 CEST] <dcherednik> Why? [23:43:26 CEST] <atomnuker> lets say you'd like to support that codec in some hardware or sell software to encode or decode that format [23:44:16 CEST] <atomnuker> you have to pay patent fees to whatever patents may be in it [23:45:04 CEST] <atomnuker> unless you'd like to only sell your device to china or whatever other country which won't confiscate it [23:45:42 CEST] <atomnuker> and thats if you manage to get the patent holders to sell you the rights to sell your stuff [23:46:26 CEST] <atomnuker> they won't be happy to hear someone has modified it and if they even suspect that they might just say no [23:46:48 CEST] <atomnuker> this is the hell software patents are [23:47:33 CEST] <atomnuker> (some even require that you use their encoder binary or they'll say no, like dolby) [23:50:13 CEST] <atomnuker> so to avoid this shit reject software patents, give your stuff out for free with source code in a nice license and make sure your research is public [23:52:45 CEST] <atomnuker> also opus demonstrated that avoiding patents leads to discovering new ways of being more efficient [23:54:34 CEST] <atomnuker> it also doesn't help that everything related to audio or video encoding IS FUCKING MATHEMATICS, but no, to the free companies participating in the open market of the us its not mathematics if its done on a computer [23:57:43 CEST] <dcherednik> I see [23:58:16 CEST] <J_Darnley> Putting math together in the right order is an innovative invention and needs protection. [23:59:25 CEST] <durandal_1707> with patents? [23:59:32 CEST] <atomnuker> too bad mostly everyone who wrote it hundreds of years ago is dead and spinning in their graves! [00:00:00 CEST] --- Wed Jul 5 2017

1 0

ffmpeg.log.20170704
by burek 05 Jul '17

05 Jul '17

[00:26:50 CEST] <meriipu> is there a way to with x11grab or ffmpeg otherwise not capture application windows matching certain criteria like window name (including capturing them as black rectangles)? e.g if I would like to not capture terminals or file managers, but capture everything else. [00:59:36 CEST] <leif> Is there a guide when I should be using av_packet_unref vs av_packet_free. [01:00:06 CEST] <leif> I seem to have a rather large memory leak I kind of wonder if its possible I should be freeing packets explicitely. [01:00:25 CEST] <leif> (rather than just calling av_packet_unref) [01:01:14 CEST] <DHE> leif: you should always allocate your packets with av_packet_alloc and free them with av_packet_free. the ref/unref is for making copies that you need to hold onto even though someone else might free it/take ownership of the pointer [01:01:43 CEST] <DHE> outside of such a scenario, you should probably avoid the ref/unref functions [01:03:27 CEST] <leif> DHE: Ah, okay, thanks. [01:04:02 CEST] <leif> So I should never use av_malloc to allocate a packet then? [01:04:24 CEST] <DHE> yes. I would also discourage allocation on the stack. [01:04:43 CEST] <leif> He, he, ya, I agree. Thanks. I'll give that a go. [01:05:25 CEST] <DHE> and even if you did use av_malloc, you should use av_mallocz to zero out all fields [01:05:54 CEST] <leif> Yup, I agree there. [01:06:52 CEST] <leif> (Although I was actually using a malloc that cooperated with a GC. But I was trying av_malloc to see if I could figure out if that was causing the leak.) [01:06:58 CEST] <leif> Anyway, thanks. :) [01:20:06 CEST] <leif> DHE: Also, are you required to call av_init_packet (or av_packet_new?) (in addition to av_packet_alloc) before passing it into av_read_frame? [01:20:48 CEST] <leif> It looks like it doesn't matter, but if we don't, the packet becomes invalid after the next av_read_frame. [01:23:53 CEST] <DHE> I'm suggesting you should av_packet_alloc() a new one before the next av_read_frame. you can call av_read_frame on the freshly allocated packet immediately, no init required [01:24:31 CEST] <DHE> and av_packet_free() the packet as soon as you are done with it [01:33:55 CEST] <leif> DHE: Cool, that seems to work, thank you. [02:55:57 CEST] <Kaedenn> I'm building a timelapse video as I go. How do I append one frame to an existing 30fps video? [02:56:11 CEST] <Kaedenn> All frames will be jpeg, same size, same color depth, etc [02:56:55 CEST] <thebombzen> Kaedenn: it depends on the 30 fps video. If the 30 fps video is mjpeg, you might want to just have separate jpeg files. If it's a raw mjpeg stream, you can literally concatenate the files. [02:57:13 CEST] <Kaedenn> Basically, rather than creating a folder with a thousand JPGs I want to build a video as I go [02:57:30 CEST] <Kaedenn> Uh, I'm just picking mp4 as a container at the moment and letting ffmpeg figure all that out [02:57:31 CEST] <thebombzen> ffmpeg supports the "mjpeg" format which is literally "jpeg images concatenated together" [02:57:51 CEST] <grublet> glorious intraframe codecs [02:57:57 CEST] <Kaedenn> \o/ [02:58:00 CEST] <thebombzen> to see what I mean, try running: cat first.jpg second.jpg third.jpg >total.jpg [02:58:10 CEST] <thebombzen> and then try running: ffplay -f mjpeg -i total.jpg [02:58:17 CEST] <Kaedenn> ...interesting. [02:58:20 CEST] <Kaedenn> I'll do that now. [02:58:45 CEST] <thebombzen> Ideally though, if you're going to be recompressing the video later, you might want to use PNGs instead of jpegs. [02:59:20 CEST] <thebombzen> In this case though you'd have to use ffmpeg -f image2pipe -i concatenated_png_file [03:00:13 CEST] <thebombzen> you can also just concatenate PNG images together, and then use "ffmpeg -f image2pipe -i concatenated_png_images_file" [03:00:37 CEST] <thebombzen> This will assume the framerate is 25 fps, but you can use -framerate to override that. "ffmpeg -f image2pipe -framerate 1 -i images_in_one_file" [03:00:47 CEST] <Kaedenn> The source I'm querying from responds in JPGs. [03:01:10 CEST] <Kaedenn> Should I convert those to PNGs, cat them, use image2pipe? [03:01:17 CEST] <furq> no [03:01:22 CEST] <Kaedenn> Thought that was the case [03:01:26 CEST] <furq> just use mjpeg [03:01:39 CEST] <Kaedenn> mjpeg is the easiest solution. The result seemed perfectly fine [03:01:42 CEST] <thebombzen> No, you should not. I recommended PNGs because if you were generating the images yourself, then no reason to compress them to jpeg and then re-compress them later. [03:02:00 CEST] <thebombzen> But if you receive jpegs directly then there is no reason to convert them to PNGs, so don't. [03:02:07 CEST] <Kaedenn> Aha. Yeah I'm not generating them; I'm just doing the equivalent of a wget/curl and storing them in a folder, named sequentially. [03:02:07 CEST] <furq> obviously you'll probably want to recompress this when you're done [03:02:09 CEST] <furq> on account of mjpeg sucks [03:02:16 CEST] <furq> but you will have a playable video in the interim [03:02:22 CEST] <Kaedenn> furq: I'm assuming having ffmpeg write to a mp4 does this? [03:02:33 CEST] <furq> yes [03:02:35 CEST] <furq> that uses x264 by default [03:02:42 CEST] <Kaedenn> Awesome, so there's almost nothing I need to do differently [03:03:05 CEST] <Kaedenn> There's a thundercell rolling in and so I booted up the timelapse generation script to capture it roll in [03:03:08 CEST] <thebombzen> MJPEG (i.e. just a sequence of jpeg images) is not efficient because it doesn't do any sort of time-based optimization. So it's bad compared to, like, a proper video codec. [03:03:10 CEST] <furq> you could presumably have an image2pipe waiting for new frames and go to mp4 directly [03:03:19 CEST] <furq> but then you won't have a playable video until all frames are done [03:03:26 CEST] <thebombzen> furq: sounds like a bad idea in case of a process crash [03:03:29 CEST] <furq> also yeah, that [03:03:37 CEST] <Kaedenn> furq: having a playable video to monitor as I go is quite important [03:03:41 CEST] <furq> right [03:03:59 CEST] <furq> that's not possible if you want the final output to be mp4 without doing two passes [03:04:15 CEST] <Kaedenn> I don't care how many passes it takes; I'm storing thousands of JPGs at the moment as it is :P [03:04:16 CEST] <furq> so mjpeg and then a final pass is probably the best [03:04:23 CEST] <furq> sure [03:04:34 CEST] <thebombzen> Kaedenn: in that case, you can just concatenate the jpeg images together and use the "-f mjpeg" I told you about to view them on the fly. You can put stuff inside an mp4 once everything is fully done. [03:04:54 CEST] <Kaedenn> Capturing a thousand images at ten second intervals is what takes the time. Everything else is effectively on-demand [03:05:09 CEST] <thebombzen> Are you capturing 1000 images once every ten seconds? [03:05:28 CEST] <Kaedenn> Capturing one image every ten seconds, a total of a thousand images. [03:05:33 CEST] <thebombzen> Ah, okay. [03:05:34 CEST] <Kaedenn> Timelapse, not high-speed [03:05:55 CEST] <thebombzen> Oh yes. Then do as above for the realtime capture. Just concatenate the files together. [03:06:02 CEST] <thebombzen> the JPEGs I mean [03:06:17 CEST] <Kaedenn> I'm fairly certain I'd get yelled at if I taxed their servers for downloading a ton of images all at once from an internal camera :P [03:06:49 CEST] <Threads> taxed as in money ? [03:06:56 CEST] <furq> curl http://foo >> out.mjpeg [03:06:58 CEST] <furq> should be all you need [03:07:24 CEST] <Kaedenn> taxed as in taxing electronics as in demanding a ton of resou--that was a lightning bolt [03:11:13 CEST] <Kaedenn> thank you all [06:35:25 CEST] <_yashi_> hello, is it possible for ffprobe to print / decode h.264 bytestream like mediaconch? [06:38:10 CEST] <british_scientis> what is mediaconch [06:38:26 CEST] <_yashi_> https://mediaarea.net/MediaConch/ [06:39:54 CEST] <_yashi_> it prints like this: https://pastebin.com/p6P77QsU [06:40:19 CEST] <british_scientis> try verbose options [06:43:54 CEST] <_yashi_> you mean -loglevel verbose ? [06:44:11 CEST] <british_scientis> yes [06:45:12 CEST] <_yashi_> i don't even know how to tell ffprobe to print nal level info, -show_packets seems to print access unit but not nal [07:51:09 CEST] <JC_Yang> I'm using libavformat to parse some h264 videos in my app, I now use av_register_all() and the linked binary size is quite large, more than 60M single executable, I guess if I just specify the format that I need to support, I can greatly cut the built binary size, but AFAIK, the only way to enumerate the supported format should be done by first av_register_all() then av_iformat_next(), then... [07:51:10 CEST] <JC_Yang> ...the built binary won't be optimized anyway. How to simply av_register_input_format() for just one or two formats? [08:58:44 CEST] <buu> Why would ffmpeg produce a file, that when I fed it to ffmpeg again, produced: [matroska,webm @ 0x558e0df1f3c0] Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x720): unspecified pixel format [08:58:52 CEST] <buu> And how can I get it to produce a file it can actually understand? [09:29:51 CEST] <buu> augh [09:29:56 CEST] <buu> Why is my audio desynced into youtube [10:19:33 CEST] <thebombzen> why are you asking us [10:26:21 CEST] <buu> thebombzen: Because I created the file with ffmpeg =] [10:27:18 CEST] <buu> Also I'm rapidly running out of guesses [10:28:07 CEST] <buu> thebombzen: If ffmpeg produced the file, why does it say: [matroska,webm @ 0x561fd570eaa0] Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x720): unspecified pixel format ? [10:28:28 CEST] <buu> Is there some way to fix that? [10:28:55 CEST] <durandal_1707> post full uncut command line output [10:29:08 CEST] <durandal_1707> via pastebin [10:30:57 CEST] <buu> durandal_1707: http://paste.debian.net/plain/974691 [10:33:16 CEST] <durandal_1707> with output [10:33:20 CEST] <buu> er [10:34:45 CEST] <buu> durandal_1707: http://paste.debian.net/plain/974693 [10:39:10 CEST] <durandal_1707> buu: first maske sure it decodes/plays without issues [10:39:17 CEST] <durandal_1707> input video [10:40:11 CEST] <buu> durandal_1707: er, how? I mean, what am I supposed to do if it doesn't? [10:40:50 CEST] <durandal_1707> buu: how are you supposed to transcode file which doesnt decode at all? [10:41:14 CEST] <durandal_1707> buu: from where is your input video? [10:41:16 CEST] <buu> Well, it does decode [10:41:21 CEST] <buu> durandal_1707: twitch tv in this case [10:41:34 CEST] <buu> durandal_1707: When I upload it to youtube I get this: https://www.youtube.com/watch?v=yEjz6LqfiHE [10:42:28 CEST] <durandal_1707> buu: but your output says different story [10:42:53 CEST] <buu> durandal_1707: http://rdsw.rmz.gs/audiotest.mkv [10:42:55 CEST] <buu> This is the actual file [10:42:59 CEST] <durandal_1707> it can not detect pixel format of input video [10:43:13 CEST] <buu> durandal_1707: Yes, but what am I supposed to do about it? [10:43:24 CEST] <buu> I'm attempting to fix the audio desync [10:43:41 CEST] <durandal_1707> im interested about input file and not output [10:43:46 CEST] <buu> When I attempt to play it locally in vlc I get 'blank screen' for a couple of seconds but the audio plays, then the video starts and it is synced to the audio [10:44:54 CEST] <buu> durandal_1707: Unfortunately the ultimate source file is ~20gb so not practical to upload during this conversation [10:45:07 CEST] <buu> the sub-source is a file I 'clipped' out using ffmpeg in the first place [10:45:31 CEST] <durandal_1707> you could trim and codec copy it [10:46:34 CEST] <buu> durandal_1707: The very original file is created by livestreamer sending output to ffmpeg as such: ffmpeg -i pipe:0 1499147789.sgdq.mkv [10:48:14 CEST] <durandal_1707> pastebin output of ffmpeg -i test.mkv [10:48:31 CEST] <buu> using ffmpeg -to 3:00 -c:a copy -c:v copy upload.mkv from the very original to http://rdsw.rmz.gs/upload.mkv [10:48:54 CEST] <buu> durandal_1707: http://paste.debian.net/plain/974697 [10:49:29 CEST] <buu> The source: http://paste.debian.net/plain/974698 [10:49:41 CEST] <durandal_1707> and does test.mkv plays in ffplay? [10:51:34 CEST] <buu> durandal_1707: yes [10:52:01 CEST] <buu> the audio is synced [10:52:31 CEST] <buu> It does the same thing where I get audio for 1-2 seconds then the video starts [10:53:06 CEST] <buu> It's like the file I produce is missing the initial video .. packet.. and ffplay/vlc figures it out and waits [10:53:09 CEST] <buu> but youtube gets confused [10:53:27 CEST] <durandal_1707> im out of ideas, trim first few seconds [10:53:35 CEST] <buu> durandal_1707: of test.mkv? [10:54:03 CEST] <buu> You mean like, -ss 00:02 ... out.mkv ? [10:54:49 CEST] <buu> I'll note I do get the error: Too many packets buffered for output stream 0:1. [10:54:56 CEST] <buu> Without the muxing option [11:12:25 CEST] <buu> aughhhhhhhhhh [11:12:30 CEST] <buu> Stream specifier ':v:0' in filtergraph description [0:v:0] [1:v:0] [1:a:0] concat=n=2:v=1:a=1 [v] [a] matches no streams. [11:13:44 CEST] <squ> do you really need trailing :0? [11:15:23 CEST] <buu> Apparently what I need is a file with both an audio and a video stream [11:15:24 CEST] <buu> oops [11:16:01 CEST] <buu> Ok, something is seriously wrong here [11:17:08 CEST] <buu> Can you please look at this file: http://rdsw.rmz.gs/concat.mkv [11:17:30 CEST] <buu> I used ffmpeg to generate a black video/blank audio, then used the concat filter to prepend it to my video file [11:17:41 CEST] <buu> And the audio starts over the black screen like.. 4 seconds early? [11:17:51 CEST] <squ> then [0:v] and [0:a] [11:18:09 CEST] <squ> concat=n1:v=1:a=1 [11:18:14 CEST] <squ> n=1 [11:18:23 CEST] <buu> what? [11:18:47 CEST] <buu> squ: I want 5 (or whatever) seconds of blankness then my video file to start [11:18:54 CEST] <buu> Why does the audio play while the video doesn't? [11:21:39 CEST] <buu> clearly ffmpeg understands that there is infact audio and video streams [11:24:24 CEST] <mort> hey [11:25:33 CEST] <mort> It seems to me like libavformat has some functionality which fragmentizes h264 into NAL units, but I can't figure out how to use it. Would anyone here happen to know anything about it? [11:38:57 CEST] <buu> Also note this important point from that page: "If you use -ss with -c:v copy, the resulting bitstream might end up being choppy, not playable, or out of sync with the audio stream, since ffmpeg is forced to only use/split on i-frames." [11:39:01 CEST] <buu> hmmmmmmmmmm [11:39:38 CEST] <buu> I begin to have ideas. [11:48:11 CEST] <squ> what ideas? [12:09:13 CEST] <samgoody> Hi all. Am trying to compile ffmpeg, according to the (understandable and easy-to-follow) wiki https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu. [12:09:25 CEST] <samgoody> But am getting ERROR: x265 not found using pkg-config [12:10:03 CEST] <samgoody> I installed libx265-dev, and seeing that wasn't enough also libx265-79 [12:10:47 CEST] <samgoody> (ie, which caused it to be set to manual, since it was already installed). But that didn't help. So how can I get the compiler to see the x265 lib and continue compiling? [12:13:07 CEST] <samgoody> As far as I can tell, the issue is that libx265 no longer includes support for ffmpeg, and needs to be compiled specifically for ffmpeg. [12:13:51 CEST] <samgoody> If that is correct, then the compile wiki page should be updated to reflect that. Is that correct? [12:14:09 CEST] <kerio> samgoody: tbh i'd just compile the latest versions of everything [12:14:27 CEST] <samgoody> That's because _you_ are competent [12:15:04 CEST] <samgoody> But me, if I don't use apt, the libs will go out of date, and I wil never get around to recompiling, and that will leave gaping security holes [12:15:43 CEST] <samgoody> So ffmpeg needs to recompiled - will do, no choice. But as much as I can take from apt, I would like to. BTW, is my stance an odd one? [12:15:51 CEST] <PharaohAnubis> you can try to automate everything [12:19:41 CEST] <samgoody> Right, of course. I'll make sure to set that up tomorrow ;) [12:20:09 CEST] <samgoody> Tomorrow is a black hat's best friend [12:21:37 CEST] <buu> I just compiled ffmpeg using ii libx265-79:amd64 1.9-3 amd64 H.265/HEVC video stream encoder (shared library) [12:21:41 CEST] <buu> ii libx265-dev:amd64 1.9-3 amd64 H.265/HEVC video stream encoder (development files) [12:21:44 CEST] <buu> on ubuntu [12:21:47 CEST] <buu> 3.3.2 [12:22:06 CEST] <samgoody> So how would I debug why it didnt work for me? [12:22:55 CEST] <buu> what ubuntu version [12:22:56 CEST] <buu> ? [12:44:23 CEST] <JC_Yang> mort: yes, you can. read the libavformat.h, though it's not quite good documented, and more specifically, av_read_frame() does read a NAL unit for you [15:28:07 CEST] <JC_Yang> it seems like that av_register_input_format() is not intended to be a public API at all...but it is so documented in the header... the only way to properly register a format require some key function pointers which are implementation details... am I wrong? how f**king messy is this project... that's why C is just a dinosaur... [15:29:44 CEST] <JEEB> more like that part of lavf is WTF. because yes, it looks as if you can plug things during runtime while that is most definitely not true [15:30:07 CEST] <JEEB> I mean, even if you use a "better" language if you make it public it's public and you've fscked your API [15:30:35 CEST] <JEEB> I think someone had posted a patch that would remove it but then it got fought against or something? [15:31:42 CEST] <furq> if you rewrote ffmpeg in rust then the mailing list would be a harmonious place of wonderful collaboration [15:31:49 CEST] <JEEB> har har har [15:31:54 CEST] <JEEB> Kostya is doing just that I think [15:32:01 CEST] <JEEB> with nihav [15:32:04 CEST] <nicolas17> lol [15:32:33 CEST] <furq> http://24.media.tumblr.com/75e2ef1b386d1c16931c12c5f36ffad8/tumblr_mhtufc4t… [15:32:36 CEST] <furq> can you imagine a world without C [15:32:39 CEST] <JEEB> JC_Yang: or that thing might be a case of getting the private demuxers in lavf and registering them one by one [15:32:42 CEST] <JC_Yang> well, yes, you're right, but look at all other half public structs in the api, I can't imagine using comments as fences to users is a good idea... [15:33:15 CEST] <JEEB> it isn't, and that's why you get opaque things in many things I think [15:33:21 CEST] <JEEB> or you just don't get references to them in the public structs [15:33:26 CEST] <nicolas17> ffmpeg isn't going to change language anytime soon [15:33:37 CEST] <nicolas17> so what's the point of "disagreeing" with its choice of language? :P [15:34:31 CEST] <JC_Yang> I don't care this ugly API now, I just like to know, how to cut the binary size down to a reasonable range, while I only need to support one or two formats [15:34:43 CEST] <JEEB> just build with less formats? [15:34:51 CEST] <nicolas17> JC_Yang: --disable-formats --enable-format=foo --enable-format=bar [15:34:52 CEST] <nicolas17> in configure [15:35:08 CEST] <JEEB> (I think enable-*= takes things comma-delimited as well) [15:35:12 CEST] <furq> --enable-muxer [15:35:14 CEST] <furq> not --enable-format [15:35:17 CEST] <JEEB> and yes [15:35:19 CEST] <JEEB> demuxer or muxer [15:35:22 CEST] <furq> and yeah, you can do --enable-muxer=foo,bar [15:35:35 CEST] <JC_Yang> well, thank u, will try it soon [15:35:45 CEST] <DHE> it also accepts --enable-muxer=mp* [15:35:55 CEST] <furq> you'll probably want demuxers, muxers and parsers [15:36:01 CEST] <nicolas17> I'm curious how you ended up messing with the code and private APIs before finding the configure options [15:36:03 CEST] <nicolas17> :P [15:36:40 CEST] <middleman_> Hello, i have a problem to compile ffmpeg from source by cude support so that i can use nvenc. [15:36:44 CEST] <JEEB> well, av_* is public API [15:36:46 CEST] <DHE> libavfilter is also huge and trimming the list of filters can help immensely [15:36:55 CEST] <furq> yeah dropping libavfilter will give the biggest benefit [15:37:04 CEST] <furq> ideally you want --disable-everything and then just enable the stuff you want [15:37:09 CEST] <furq> but you will almost certainly end up with a broken build [15:37:26 CEST] <furq> so it's better to go through and disable stuff one by one before getting to that point [15:37:35 CEST] <middleman_> Always got error "ERROR: CUVID not found" [15:38:07 CEST] <JEEB> furq: basically knowing the exact components you need (as in, starting with the file protocol etc usually) is a good idea :D [15:38:09 CEST] <middleman_> Anyone could advise me what shuold i do to specify dependencies for cuda nvenc api ? [15:38:13 CEST] <JC_Yang> I haven't tried any private apis, just read some codes and get where I am, and, give up and complain, then get the probable the right solutions from you guys, though haven't tried it, but it sounds [15:38:15 CEST] <furq> yeah that helps [15:38:34 CEST] <JEEB> because that's the classic failure with disable-everything :D [15:38:40 CEST] <furq> there is a lot of stuff that isn't immediately obvious [15:38:43 CEST] <JEEB> "hey why can't I open this JPEG file any more?" [15:38:44 CEST] <BtbN> cuvid and nvenc do not have any special dependencies. [15:38:49 CEST] <JEEB> "I enabled the demuxer and decoder!" [15:39:05 CEST] <JEEB> (but then you don't have the file protocol and d'uh) [15:39:30 CEST] <middleman_> This one configuration does not work. [15:39:31 CEST] <middleman_> ./configure --enable-cuda --enable-cuvid --enable-nvenc --enable-nonfree --enable-libnpp --extra-cflags=-I/usr/local/cuda/include --extra-ldflags=-L/usr/local/cuda/lib64 [15:39:43 CEST] <middleman_> It throws that error i noticed before [15:39:54 CEST] <BtbN> are you using latest master? [15:40:08 CEST] <middleman_> Me ? [15:40:27 CEST] <BtbN> who else? [15:40:55 CEST] <middleman_> i am using apt souce ffmpeg git.... link [15:41:13 CEST] <BtbN> so probably something horribly old, use latest master [15:41:36 CEST] <nicolas17> what even is "apt souce ffmpeg git"? [15:41:53 CEST] <middleman_> VERSION file reports 3.2.6 [15:42:53 CEST] <BtbN> yeah, as expected [15:43:04 CEST] <middleman_> I have installed 375.66 driver , cuda-8.0 and also toolkit [15:43:28 CEST] <BtbN> nvenc and cuvid have zero external dependencies in latest master. [15:43:30 CEST] <BtbN> Just use that. [15:44:20 CEST] <DHE> speaking of which, the nvenc version dependency is very high. you might need to update your nvidia driver further. not sure if 375 is enough [15:44:28 CEST] <BtbN> 378 iirc [15:45:34 CEST] <middleman_> so what is the way to ./configugre it ? [15:45:55 CEST] <DHE> BtbN: I was running 352 for the longest time. so disappointed... :/ [15:46:18 CEST] <BtbN> On master just a plain ./configure will give you nvenc and cuvid. [15:46:28 CEST] <middleman_> ok, will try it [15:46:38 CEST] <BtbN> But it won't work with your old driver version [15:47:12 CEST] <hojuruku> x86_64-pc-linux-gnu-gcc is unable to create an executable file. At first you would think my gcc is broken but no... gentoo's ffmpeg-9999999 ebuild multilib just broke working with git. I assure you my compiler is working and I can build other multilib ebuilds fine. [15:47:13 CEST] <BtbN> If you insist on using the old ffmpeg version for the old driver, your configure line looks fine to me [15:47:22 CEST] <hojuruku> any ideas? [15:47:28 CEST] <BtbN> if the CUDA SDK is actually installed where you are telling it it is [15:47:53 CEST] <middleman_> I see that Enabled encoders encover nvenc [15:48:01 CEST] <middleman_> looks promising [15:48:08 CEST] <BtbN> nvenc never really had any dependencies [15:48:11 CEST] <hojuruku> i'm not crying i've still got the recent git one installed from last month. It was just my only issue with my monthly updates. [15:48:17 CEST] <BtbN> it's just about cuvid and the filters. [15:48:48 CEST] <middleman_> do i need something else ? [15:48:56 CEST] <BtbN> The CUDA SDK. [15:48:56 CEST] <hojuruku> i may have to DIY and look at the configure.log to see what's going wrong / what the tests are [15:49:16 CEST] <middleman_> already have cuda-8.0 [15:49:38 CEST] <BtbN> You are not specifying its path correctly then [15:49:42 CEST] <BtbN> or it's not properly installed. [15:51:26 CEST] <middleman_> So what --enable-* i need to entirely correctly get cuda support so that nvenc could work properly ? [15:51:57 CEST] <nicolas17> there's nothing else to enable [15:52:35 CEST] <middleman_> Than this one is deprecated --enable-cuda --enable-cuvid ? [15:52:42 CEST] <nicolas17> those are correct [15:52:52 CEST] <nicolas17> "You are not specifying its path correctly, or it's not properly installed" -> specify its path correctly or install it properly, you don't need to "enable" more things [15:52:53 CEST] <BtbN> depends on the version. Recent versions also have cuda-sdk [15:53:06 CEST] <BtbN> but it very specifically gives you an error [15:53:14 CEST] <BtbN> check config.log to find out what exactly it's not finding. [15:55:06 CEST] <middleman_> i see, -lnvcuvid [15:58:33 CEST] <BtbN> usr/local also looks weird for the cuda sdk [16:18:49 CEST] <thomedy> if i ffmpeg -i ./movie.mp4 ./frames/frame%d.jpg how does it determine what the frame numbers will be [16:18:53 CEST] <thomedy> is it fps [16:18:59 CEST] <thomedy> i was anticipating more frames from my film [16:20:26 CEST] <BtbN> it just counts them? [16:21:13 CEST] <thomedy> which then i can use the fps anyway [16:21:24 CEST] <thomedy> okay so that means i just had them wrong in my head [16:21:36 CEST] <thomedy> fps 30, 30 second film 900 frames? [16:21:45 CEST] <thomedy> reasonable/ [16:21:46 CEST] <thomedy> ? [16:30:27 CEST] <JC_Yang> well, questions, if what I need maybe just the muxer and demuxer, should I disable all other modules in config? I mean, avcodec and swresample and the possibly not used codes? [16:33:55 CEST] <nicolas17> JC_Yang: what are you doing that only needs muxer/demuxer? :o [16:34:18 CEST] <JC_Yang> maybe also parser [16:35:25 CEST] <JC_Yang> I don't have very clear mind about the distinctions between muxer and parser, any pointers? [16:37:20 CEST] <bencoh> if I had to guess I'd say the parser allows you to extract (still encoded) frames from an encoded video bitstream, for instance [16:37:33 CEST] <bencoh> to feed the decoder with those frames [16:38:19 CEST] <bencoh> (but that's plain educated guess) [17:21:18 CEST] <samgoody> Hi i reencoded audio on some videos from mp3 to aac [17:21:46 CEST] <samgoody> the size jump was enourmous. Eg. 569M -> 629M [17:22:25 CEST] <samgoody> The original sound was encoded someowhere in the range of 50kbps, and the aac at 128kbps [17:23:12 CEST] <samgoody> Is that size expected? Is there any reason to use higher than the original kbps size? If not, is there any way to get the original size? [17:23:47 CEST] <nicolas17> you *asked* for a bigger filesize :P [17:24:12 CEST] <nicolas17> if you want the same file size, use the same bitrate; no warranties of the quality being the same though [17:24:40 CEST] <samgoody> I want the quality to be as close to the original without enlarging it more than needed. [17:25:05 CEST] <nicolas17> quality is subjective though, especially when switching codecs [17:25:13 CEST] <samgoody> If it is enough to use 54kbps when reencoding from 45kbps, than I dont need 128kbps. [17:25:23 CEST] <nicolas17> you'll have to try it [17:25:35 CEST] <samgoody> I have over 500 videos [17:25:43 CEST] <nicolas17> well try it on one [17:25:56 CEST] <furq> why are you reencoding the audio [17:26:15 CEST] <nicolas17> aac might be able to have *lower* bitrate and still keep the same quality, but Who Knows [17:26:20 CEST] <samgoody> And I am not an audiophile, so to me it all sounds the same. It is for streaming the video, using HLS which doesn't support MP3 [17:26:46 CEST] <furq> hls does support mp3 [17:28:23 CEST] <samgoody> Not this version of MP3 (mp4a.40.34). At least not for native playback in FF or Chrome while streaming. [17:29:00 CEST] <samgoody> I want my clients happy, but increasing each file by 10% is significant [17:29:23 CEST] <nicolas17> uh, I'm pretty sure mp4a is aac [17:29:46 CEST] <samgoody> So if there is some way I could ffprobe the original bandwidth and add 20% and be pretty sure than users won't hear a difference, I would do that. [17:30:45 CEST] <nicolas17> experiment with one video, and then assume the quality loss will be similar on the rest [17:31:02 CEST] <samgoody> Ie, see that the original was encoded at 96k, add 20% == 116k. Would that work? [17:31:18 CEST] <nicolas17> try same bitrate first [17:31:45 CEST] <samgoody> The videos were recrded in many settings, and besides, I am not very good at sound tests. I couldn't carry a tune if it had handles [17:32:56 CEST] <samgoody> If there is no other solution, I will encode at 128k at call it a day. But that increases bandwidth on playback as well as storage costs. So would have preferred a skinnier approach. [17:34:03 CEST] <samgoody> is there no proportion that is considered somewhat "safe"? [17:34:33 CEST] <samgoody> And if so, can I rely on ffprobe to get orig bandwidth? [17:40:12 CEST] <hojuruku> ffmpeg is a bit flakey when using FILTERS with v4 intel graphics (eg haswell) vaapi actually very flakey. [17:40:30 CEST] <hojuruku> it works... but you can't say take the first 10 mins of the video etc... [19:52:02 CEST] <tezogmix> goal: convert to mp4 with minimal artifact/grain - source: (wmv/mpg) quality is visually low, very grainy /// does the "-tune film or grain" feature or crf 15/crf 18 parameter or some other correction help? I've read that too low crf may cause more enhancement of grain artifacts. I think the grain preserves the grain and film will try to reduce that but not sure if it's helpful on already low quality sources/ [19:52:30 CEST] <furq> they both bias towards preserving grain [19:52:53 CEST] <furq> and using a very low crf will preserve more grain as well [19:52:56 CEST] <JEEB> if your source is already of visually low quality I am not sure if you want to re-encode to begin with... [19:53:13 CEST] <furq> it's sometimes worth it if you're resizing down [19:53:19 CEST] <furq> but if you have mpegs then that's probably not what you're doing [19:53:20 CEST] <JEEB> because unless there's some real bit rate overusage going on, you probably won't get a compression gain [19:53:38 CEST] <tezogmix> it was more for device format compatibility to mp4 [19:53:40 CEST] <JEEB> but then again if the source had enough bit rate it wouldn't be of bad quality [19:54:05 CEST] <furq> you probably want to run a denoise filter anyway [19:54:24 CEST] <JEEB> tezogmix: the gist is: pick like 2500 frames of content that your stuff will have in general [19:54:33 CEST] <JEEB> then pick your libx264 preset [19:54:40 CEST] <JEEB> speed-wise [19:54:48 CEST] <JEEB> (basically check at which point it gets too slow for you) [19:55:03 CEST] <JEEB> and then just test on that clip various CRF values until you find the highest that still looks good enough for you [19:55:07 CEST] <JEEB> start at around 21 to 23 [19:55:07 CEST] <furq> yeah [19:55:11 CEST] <JEEB> that's literally it [19:55:12 CEST] <furq> experiment with tunes and filters as well [19:55:17 CEST] <furq> you probably don't want to use any tune [19:55:29 CEST] <tezogmix> size wasn't an issue, the source files are considerably small (under 1gb), the bitrates are also pretty low in the sub 1-2k range [19:55:37 CEST] <furq> they're generally useless if you have a poor quality source [19:56:23 CEST] <klaxa> just throwing this in here :P <pengvado> Of course it doesn't look better than the source. It's --deblock, not --pixie-dust. [19:56:40 CEST] <klaxa> pretty much applies here too from what i can tell [19:57:07 CEST] <tezogmix> thanks all, what's the denoise parameter to try out? [19:57:21 CEST] <furq> there are loads [19:57:26 CEST] <furq> start with -vf hqdn3d [19:57:35 CEST] <tezogmix> oh yeah, i see many on the official page [19:57:39 CEST] <furq> !filter hqdn3d [19:57:40 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#hqdn3d-1 [19:57:46 CEST] <tezogmix> preset, i've been using veryfast [19:57:53 CEST] <nicolas17> hm [19:58:04 CEST] <tezogmix> maybe will try fast [19:58:12 CEST] <nicolas17> I'm supposed to av_packet_unref() for every packet I read, even if I'm reusing the AVPacket? [19:58:57 CEST] <tezogmix> default ffmpeg crf is 20 ? [19:59:00 CEST] <furq> 23 [19:59:03 CEST] <tezogmix> oh ok... [19:59:33 CEST] <tezogmix> for all my hq sources, 15-18 have been working well [19:59:57 CEST] <tezogmix> but from my testing of the same commands on lower quality, it looks a tad bit worse than the source [20:00:26 CEST] <nicolas17> using low quality is not a way to get rid of noise present in the source :P [20:00:31 CEST] <tezogmix> so i'll try maybe the higher crf like JEEB mentioned and furq's -vf denoise [20:00:46 CEST] <klaxa> nicolas17: av_interleaved_write_frame() takes care of unref'ing the packet iirc but av_write_frame() does not https://ffmpeg.org/doxygen/2.8/group__lavf__encoding.html#ga37352ed2c63493c… [20:01:00 CEST] <nicolas17> if you have artifacts in the source video, reencoding will waste bits trying to preserve the artifacts as well as possible [20:01:08 CEST] <nicolas17> klaxa: sorry, I'm decoding [20:01:10 CEST] <tezogmix> ah yeah nicolas17 , i know it wouldn't be eliminated... i've just noticed it much more enhanced than i was expecting in the conversion.... [20:01:18 CEST] <klaxa> ah... hmm... [20:02:16 CEST] <klaxa> in my program i do av_read_frame(ifmt_ctx, &pkt); [...] ret = av_write_frame(seg->fmt_ctx, &pkt); av_packet_unref(&pkt); [20:02:20 CEST] <klaxa> so i would assume, yes [20:02:28 CEST] <nicolas17> hmm okay [20:02:38 CEST] <tezogmix> btw kepstin , that suggestion of scaling down source 1080p60 to 720p60 was much better than 1080p60 to 1080p30 [20:02:57 CEST] <nicolas17> I wrapped some things in C++ classes, I might make my read_frame unref the packet before overwriting it... [20:03:26 CEST] <klaxa> when in doubt, valgrind [20:03:46 CEST] <nicolas17> hmm nope that doesn't work ^^ [20:04:07 CEST] <nicolas17> it crashes on the first frame, I can't call av_packet_unref on a brand new AVPacket that has nothing in it ^^ [20:06:37 CEST] <nicolas17> ahh nevermind [20:06:45 CEST] <nicolas17> I can av_packet_unref an "empty" AVPacket [20:06:55 CEST] <nicolas17> but what I had wasn't even zeroed out, it had stack garbage [20:09:14 CEST] <SpeakerToMeat> Hi everybody. [20:09:26 CEST] <SpeakerToMeat> Question, if I use the subtitles filter I can't use a -v copy, right? [20:09:42 CEST] <furq> right [20:09:56 CEST] <kepstin> SpeakerToMeat: you cannot use -c copy on any streams which are being filtered, yes [20:10:13 CEST] <kepstin> (you could for example filter video, but copy audio) [20:10:44 CEST] <SpeakerToMeat> Hmmm so I need to see from j2k->j2k how much of a loss there'd be [20:10:46 CEST] <SpeakerToMeat> thanks [20:11:24 CEST] <nicolas17> the subtitles filter is for hardsub? [20:11:40 CEST] <kepstin> nicolas17: yes [20:11:50 CEST] <nicolas17> yeah there's no way you're doing that without reencoding :) [20:16:19 CEST] <SpeakerToMeat> Huh I lost an HDD.... [20:16:22 CEST] <tezogmix> thanks everyone for the help + tips! [20:16:46 CEST] <nicolas17> SpeakerToMeat: restore from backup \o/ [20:18:18 CEST] <kepstin> hmm, "Huh I lost an HDD" seems a little low-key for someone needing to restore from backups, maybe this just requires replacing a drive in raid? :) [20:18:58 CEST] <nicolas17> kepstin: an important KDE server has been reporting 8 "pending" sectors for like a month [20:19:35 CEST] <SpeakerToMeat> nicolas17: it was lose on the bay [20:20:17 CEST] <SpeakerToMeat> Time to get the tape out [20:20:19 CEST] <nicolas17> apparently "pending" means they are bad and need to be reallocated elsewhere, but the drive didn't even manage to read the original contents [20:20:31 CEST] <kepstin> ah, so you didn't lose an hdd, you loosened an hdd. [20:20:41 CEST] <nicolas17> :D [20:21:07 CEST] <furq> nicolas17: you can sometimes clear those by forcing a write to that sector [20:21:17 CEST] <kerio> do i shill znc [20:21:19 CEST] <SpeakerToMeat> kepstin: No the hdd loosened itself :D I discovered it by losing the /dev/sdX [20:21:27 CEST] <kerio> this sounds like a situation where i should shill znc [20:21:29 CEST] <furq> smartctl will sometimes report the sector [20:21:35 CEST] <kerio> er what the fuck [20:21:37 CEST] <kerio> zfs [20:21:40 CEST] <furq> although it doesn't on my disk with a pending sector [20:21:42 CEST] <kerio> i can't brain D: [20:21:54 CEST] <nicolas17> I couldn't find the sector number, even after an "extended" self-test [20:21:54 CEST] <kepstin> nicolas17: yeah, if you have "pending" sectors, you might not even notice until you try to read some file that happens to be there; if it's in unallocated filesystem space, then it'll fix itself if the fs decides to write something there [20:22:02 CEST] <nicolas17> kerio: it is in fact using zfs [20:22:20 CEST] <nicolas17> so that server could explode for all I care, as long as the shards don't damage the others :P [20:22:24 CEST] <kepstin> but in general if you have a drive with pending sectors, you probably want to preemptively replace it. [20:22:24 CEST] <nicolas17> er that disk* [20:22:39 CEST] <kerio> yay [20:22:54 CEST] <kerio> furq they're using zfs :3 [20:23:17 CEST] <kerio> hey SpeakerToMeat [20:23:18 CEST] <kerio> use zfs [20:23:27 CEST] <nicolas17> :P [20:23:30 CEST] <kepstin> if you do a full filesystem scrub and it doesn't fix the pending sectors, then they're probably in unallocated space and were only found during a smart self-test or something [20:23:33 CEST] <SpeakerToMeat> kerio: I always use zfs when possible, I'm finishing a project that uses zfs heavily [20:23:40 CEST] <nicolas17> kerio: are you a door-to-door zfs salesman? [20:23:56 CEST] <SpeakerToMeat> nicolas17: No, he sells ram [20:24:01 CEST] <kerio> ayyy [20:24:09 CEST] <kerio> RAM FOR THE RAM GOD [20:24:11 CEST] <SpeakerToMeat> Because any self respecting ZFS user NEEDS dedup [20:24:27 CEST] <nicolas17> not using dedup but still getting RAM problems lol [20:24:51 CEST] <SpeakerToMeat> Huh dedup is the biggest user of ram with ZFS, my current project has only 8Gb ram total. [20:25:27 CEST] <kerio> don't use dedup [20:25:30 CEST] <SpeakerToMeat> On a Xeon DL380-G9 2U bitch chock full of LDDs [20:25:34 CEST] <SpeakerToMeat> I don't use dedup [20:25:36 CEST] <kerio> it's a bad idea [20:25:41 CEST] <SpeakerToMeat> dedup is not accounted into the project or needs [20:25:46 CEST] <furq> prefetch as well [20:25:46 CEST] <kerio> unless you have VERY peculiar data [20:25:51 CEST] <SpeakerToMeat> specially for what we're using it. [20:26:01 CEST] <SpeakerToMeat> kerio: I have very peculiar data, but it wouldn't benefit from dedup [20:26:07 CEST] <kerio> furq: well i mean [20:26:13 CEST] <kerio> you might as well use the ram for *something* [20:26:23 CEST] <SpeakerToMeat> kerio: Blu-Ray and DVD rips mostly [20:26:29 CEST] <kerio> what's the alternative, running chrome? [20:26:39 CEST] <nicolas17> this server has download.kde.org, files.kde.org, and a few other data-heavy thingies :P [20:31:13 CEST] <SpeakerToMeat> kerio: Run chrome and go into newgrounds [20:31:44 CEST] <SpeakerToMeat> nicolas17: dedup might help a little there but I wouldn't use it.... read caching though.... [20:32:35 CEST] <SpeakerToMeat> I'm trying to move a client to a newer PHP for his site, so I can enable memcached php compilation cache, he has few php which are repeatedly used a lot, and lots of free ram still [20:32:58 CEST] <SpeakerToMeat> I'm also excited about getting him away from an older vulnerable php but, oh well [20:33:42 CEST] <SpeakerToMeat> Do I write image sequence outputs the same way as inputs? [20:34:09 CEST] <SpeakerToMeat> nicolas17: Are you a sysadmin for kde? [20:34:51 CEST] <nicolas17> yes [20:35:26 CEST] <SpeakerToMeat> nicolas17: I think with enough humph I might be able to do something like that. And I'd probably be dead within three months from the stress [20:35:59 CEST] <SpeakerToMeat> nicolas17: So, thank you for your service. Even if all I use from kde right now is yaquake and k3b [20:36:18 CEST] Action: nicolas17 lives in yakuake [20:36:35 CEST] <SpeakerToMeat> nicolas17: you do, in fact you're in yakuake right now... wanna see? [20:38:45 CEST] <SpeakerToMeat> nicolas17: There you are, you all are shoved into yaquake right now. http://imgur.com/a/rR2a2 [20:39:08 CEST] <SpeakerToMeat> Rather you're all inside yaquake->mosh->screen->weechat now in glorious xterm-256color [20:40:02 CEST] <SpeakerToMeat> psst. please don't tell the couchdb and mongodb guys that their buffers are neighbours [20:40:45 CEST] <nicolas17> join #elasticsearch or something and put it in the middle :o [20:41:04 CEST] <SpeakerToMeat> nicolas17: Buffe 21 [20:41:31 CEST] <nicolas17> :D [20:41:53 CEST] <SpeakerToMeat> This project I'm talking about uses couchdb+elasticsearch... such a "winning" combination [20:42:20 CEST] <SpeakerToMeat> That one alone drove me almost to drinking, specially years ago when the river changed from the shoddy plugin to the direct method [20:43:36 CEST] <SpeakerToMeat> Ok, first "subtitling jpeg2000 movies with ffmpeg" test [20:44:26 CEST] <kerio> jpeg2000 D: [20:45:27 CEST] <SpeakerToMeat> kerio: DCI [20:46:36 CEST] <kepstin> I guess cinema projectors tend not to have softsub renderers that can handle SRT or ASS, do they :/ [20:46:45 CEST] <nicolas17> lolno [20:46:52 CEST] <kepstin> that seems like something they should fix. [20:47:14 CEST] <SpeakerToMeat> kepstin: Actually. [20:47:40 CEST] <SpeakerToMeat> kepstin: Both Interop and SMPTE have xml based subtitle formats, SMPTE's wrapped in MXF [20:48:18 CEST] <SpeakerToMeat> kepstin: But, sometimes the projector has Texas Instrument's cinecanvas inside to render them, and supposedly sometimes not, and the media server/media block doesn't always have an internal renderer [20:48:24 CEST] <nicolas17> "XML is like violence, if it doesn't solve the problem, use more" [20:48:57 CEST] <SpeakerToMeat> kepstin: Plus, some sites haven't updated to SMPTE able hardware/firmware, so doing subtitles in digital cinema is a minefield, and sometimes like festivals or some/many distributors preffer burned in subs for that reason [20:49:13 CEST] <kepstin> well, the real solution is to just master stuff to a blu-ray and play it on a ps3 in the projection boot, right? :) [20:49:40 CEST] <nicolas17> ^ [20:49:46 CEST] <SpeakerToMeat> Also, if you're using a type 1 texas instrument dlp based projector (very old), the ram space for the font is limited to 256Kb, so you normally cut unused glyphs out of your font [20:49:57 CEST] <SpeakerToMeat> kepstin: I have seen worse, much worse. [20:50:57 CEST] <SpeakerToMeat> Two things, how the heck did I get the help for a codec? I try all ways and always fail :/ [20:51:17 CEST] <kepstin> SpeakerToMeat: for an encoder, "ffmpeg -h encoder=<name>" [20:51:23 CEST] <SpeakerToMeat> and second, what's the right way to specify the fps for an image sequence input? nto for modifying but for specifying what it's supposed to be [20:51:36 CEST] <kepstin> but that'll only show encoder-specific avoptions, many codecs also use common options [20:51:40 CEST] <SpeakerToMeat> kepstin: Huh, thanks and sory, I tried format, codec, etc [20:51:56 CEST] <nicolas17> SpeakerToMeat: "-framerate 30" before the -i for the images [20:51:57 CEST] <kepstin> SpeakerToMeat: input fps? depends on the format - what do you have? [20:52:07 CEST] <nicolas17> I assume you're using image2? [20:52:09 CEST] <kepstin> but yes, what nicolas17 said for many formats ;) [20:52:21 CEST] <SpeakerToMeat> image2? [20:52:48 CEST] <nicolas17> image2 is a demuxer that... pretty much reads individual image files and feeds them unmodified to the decoder [20:53:22 CEST] <nicolas17> I think support for -i "foo%03d.jpg" frame number formatting is in the image2 (de)muxer too [20:53:58 CEST] <SpeakerToMeat> So I should change demuxers? [20:54:15 CEST] <nicolas17> what are you using now? [20:54:44 CEST] <SpeakerToMeat> nicolas17: whathever defaults for ffmpeg -i image%06d.j2c [20:55:05 CEST] <kepstin> SpeakerToMeat: then it's using the image2 demuxer. [20:55:29 CEST] <SpeakerToMeat> Ok [20:55:52 CEST] <SpeakerToMeat> Hmmm for subs I guess my best bet for setting up everything as I want it is to use ASS and the ass filter (that sounds nasty) [20:56:25 CEST] <kepstin> SpeakerToMeat: probably the subtitles filter actually, but I think they're more or less equivalent if you just have an external standalone .ass file [20:56:53 CEST] <furq> ass is only useful if you don't have libavcodec and libavformat [20:57:10 CEST] <kepstin> (subtitles filter can do things like read embedded fonts from mkv, and subtitle formats other than ass) [20:57:22 CEST] <SpeakerToMeat> kepstin: I think the subtitle filter builds on top of ass doesn't it? and if I have a meatada clean sub format like srt I'd have to specify a lot of style options like font and color, which I can pre-set on ASS [20:57:38 CEST] <furq> subtitles will treat ass files the same as ass [20:57:40 CEST] <SpeakerToMeat> Oh well I can use ass with vf=subtitle [20:57:52 CEST] <nicolas17> as long as it doesn't treat the subtitles like ass [20:57:59 CEST] <nicolas17> which means something else :> [20:58:13 CEST] <SpeakerToMeat> Sometimes they deserve to be treated so [20:58:19 CEST] <SpeakerToMeat> Not all subtitles are created equal [20:58:40 CEST] <nicolas17> https://pbs.twimg.com/media/DD2qQLnUwAEUnh6.jpg:large [20:59:07 CEST] <kepstin> i'm still annoyed that they went with image subtitles on bd, but I guess the alternative would have been something weird that was built in java. [20:59:15 CEST] <furq> i would've thought it'd be easier to just use srt and set the options in the filter [20:59:27 CEST] <furq> unless you need specific text positioning or effects or whatnot [20:59:47 CEST] <SpeakerToMeat> nicolas17: Was gonna say "wat" but you reminded me of this: http://www.bathroomreader.com/wp-content/uploads/2010/04/ToiletComputerTerm… [20:59:54 CEST] <furq> i guess it's easier to preview the options if they're in the subtitle file [21:00:42 CEST] <nicolas17> okay! how do I encode an mp4/x264 [21:01:00 CEST] <nicolas17> *with the API* :D [21:04:45 CEST] <kerio> furq: i like ass [21:06:29 CEST] <DHE> we know [21:09:02 CEST] <SpeakerToMeat> Is there a list of subtitle style options somewhere? [21:10:33 CEST] <kepstin> SpeakerToMeat: probably the aegisub docs are a good play to start? [21:11:18 CEST] <kepstin> the closes thing to a "spec" for ass, as far as I know, is this old document: http://www.cccp-project.net/stuff/ass-specs.pdf which might be out of date compared to current renderers? not sure. [21:12:27 CEST] <furq> http://webcache.googleusercontent.com/search?q=cache:Ynjy50wO8WYJ:moodub.fr… [21:12:50 CEST] <furq> there's also a wiki page on libass' github repo, but it's for ass v5 [21:13:09 CEST] <JEEB> the ASS "spec" in reality ended up being VSHitler [21:13:09 CEST] <furq> i'm pretty sure ffmpeg only accepts v4 options [21:14:05 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/ass.c#L45-L53 [21:14:08 CEST] <furq> that's probably better [21:14:09 CEST] <JEEB> kepstin: ASS did get various additions that had limited usage or implementation [21:14:25 CEST] <JEEB> but in the end ASSv4 seems to be the canonical thing + how VSHitler filters it [21:14:43 CEST] <JEEB> libass tries to emulate VSHitler - with exceptions where it's not feasible/possible [21:15:02 CEST] <nicolas17> okay I'll dive into the docs and see if I can manage to do encoding by myself [21:15:35 CEST] <JEEB> I think things like Aegisub mostly kept ASS from becoming irrelevant [21:15:43 CEST] <kepstin> yeah, it's one of those crazy things where an internal format for some subtitle editor was extended and became a defacto-standard subtitle working format for multiple tools [21:15:45 CEST] <JEEB> I mean, heck, there's at least one major VOD service which uses ASS [21:15:51 CEST] <JEEB> for the subtitles [21:33:04 CEST] <SpeakerToMeat> kerio: Youre not razor1000 right? [21:36:00 CEST] <kerio> no [21:39:13 CEST] <SpeakerToMeat> Hmmmm how can I tell ffmpeg not to convert color space between in and out? [21:39:49 CEST] <durandal_1707> SpeakerToMeat: post full command line output [21:41:02 CEST] <SpeakerToMeat> in is in xyz12dfull command line, or related output? [21:41:10 CEST] <SpeakerToMeat> blergh [21:41:55 CEST] <SpeakerToMeat> ffmpeg -framerate 24 -i ../subs-in/image%06d.j2c -vf subtitles=/home/lars/Desktop/Prueba-Sub.srt image%06d.j2c [21:42:15 CEST] <SpeakerToMeat> It's tryign to convert from xyz (xyz12le), I want the same output, no conversion... maybe an encoder setting [21:48:13 CEST] <furq> did you build ffmpeg with libopenjpeg [21:48:29 CEST] <furq> the builtin j2k encoder doesn't support xyz [21:49:34 CEST] <SpeakerToMeat> hmm [21:59:26 CEST] <SpeakerToMeat> ok --enable-libopenjpeg [22:00:40 CEST] <SpeakerToMeat> It was compiled with openjpeg [22:01:23 CEST] <furq> try with -c:v libopenjpeg [22:02:15 CEST] <furq> you might want to check -h encoder=libopenjpeg [22:02:25 CEST] <furq> i don't have a build with it but apparently there's some dcp compat options in there [22:03:02 CEST] <SpeakerToMeat> furq: Ok but first I need to find otu why force_style in the subtitles filter insists PrimaryColour which is both on the online documentation, and the ASS specs is treated as invalid [22:03:13 CEST] <SpeakerToMeat> furq: thanks [22:09:07 CEST] <SpeakerToMeat> furq: It still argues that "Color conversion not implemented for xyz12le" setting the encoder is ok but how do I set the decoder? [22:10:32 CEST] <furq> -c:v libopenjpeg before -i [22:11:43 CEST] <kepstin> SpeakerToMeat: the issue is probably that the subtitles filter can't render onto xyz12le video, you'll probably have to convert to yuv or rgb. [22:12:01 CEST] <kepstin> that warning is coming from in the libavfilters/drawutils code [22:12:03 CEST] <SpeakerToMeat> ugh precedence of parameters [22:12:13 CEST] <kepstin> which is used in the subtitles filter [22:12:15 CEST] <furq> well you'd need it in both places [22:12:19 CEST] <furq> but yeah kepstin is probably right [22:12:31 CEST] <SpeakerToMeat> kepstin: Can I tell it not to convert and just use it in the colors I give it? (I've converted the colors beforehand) [22:12:48 CEST] <SpeakerToMeat> Maybe with the ass filter [22:13:23 CEST] <SpeakerToMeat> Actually it was the decoder whining [22:13:35 CEST] <kepstin> SpeakerToMeat: I thought ass colors are all in 32bit BGR/BGRA, I don't think you can preconvert them? [22:13:58 CEST] <SpeakerToMeat> hmm I don't entirely like this, if the subs are in rgb/yuv and there's no whining there's probably xyz->rgb->xyz going on the background and I don't like that [22:14:38 CEST] <SpeakerToMeat> kepstin: Not all formats support xyz, many times when you work with xyz you're just using rgb value holders to hold the xyz coordinates. [22:15:39 CEST] <kepstin> SpeakerToMeat: anyways, the filter is going "draw this stuff using this rgba color", then the drawutils code is going "I don't know how to convert that color to the frame pixel format" [22:15:42 CEST] <SpeakerToMeat> It's 3 values same as RGB, same possibilities of bit widths (8, 10, 12, cinema is 12 bits only) [22:15:50 CEST] <SpeakerToMeat> hmmm [22:16:12 CEST] <SpeakerToMeat> I wonder if it'll work if I convert the subs to alpha channeled images and composit them instead [22:16:28 CEST] <kepstin> SpeakerToMeat: yeah, that's a possibility. [22:17:18 CEST] <kepstin> hmm, there's no XYZ pixel formats with alpha channels in ffmpeg, tho [22:18:05 CEST] <SpeakerToMeat> If I could just tell it "don't touch colors, no matter what you think color is, don't change colors at all) and be done with it [22:18:27 CEST] <kepstin> I suppose you'll have gamut problems converting to either a yuv or rgb format? [22:18:39 CEST] <kepstin> if you use a 16bit temp format the precision loss should be minimal [22:19:11 CEST] <SpeakerToMeat> yes [22:19:44 CEST] <SpeakerToMeat> There's formulas to convert back and forth taking gamut in account but I want to lose as little as possible so I don't want to go converting back and forth :/ [22:21:56 CEST] <kepstin> SpeakerToMeat: about the only way I can think to to get it to work would be to add XYZ12 pixel format support to the ffmpeg drawutils [22:22:10 CEST] <kepstin> and it's a strange packed format, so that'll probably be a pain :/ [22:22:51 CEST] <kepstin> hmm, well, 36 bits (12x3), so at least it's an integer number of bytes per pixel. might not be that bad actually [22:25:01 CEST] Action: kepstin doesn't know anything about the format, he's just looking at the pixel format list in ffmpeg headers [22:25:20 CEST] <SpeakerToMeat> kepstin: It's deffinitively doing something odd.... let me show you.... [22:26:19 CEST] <kepstin> SpeakerToMeat: in the case when the color conversion is missing, it defaults to using a color filled with '128' bytes, which should be a neutral grey in both YUV and RGB. [22:29:06 CEST] <SpeakerToMeat> kepstin: http://imgur.com/a/8Nqia command line: ffmpeg -framerate 24 -c:v libopenjpeg -i ../subs-in/image%06d.j2c -c:v libopenjpeg -profile:v cinema2k -cinema_mode 2k_24 -vf subtitles=/home/lars/Desktop/Prueba-Sub.ass image%06d.j2c [22:30:04 CEST] <kepstin> impressive. [22:30:38 CEST] <SpeakerToMeat> Yes, it's so pretty [22:30:45 CEST] <SpeakerToMeat> so very 80's [22:33:26 CEST] <SpeakerToMeat> Hmmm the input thinks the color space is yuv444p16le, it's not [22:33:35 CEST] <SpeakerToMeat> it's xyz12le [22:33:50 CEST] <kepstin> SpeakerToMeat: full ffmpeg output please? [22:33:54 CEST] <SpeakerToMeat> I wonder if I can tell the decoder that, I can't use -profile:v before -i [22:37:35 CEST] <SpeakerToMeat> Any prefered channel paste? [22:37:56 CEST] <kepstin> just use a pastebin service, doesn't matter too much which one [22:38:14 CEST] <kepstin> lists a few [22:38:32 CEST] <SpeakerToMeat> Ok I have a pastebin account but some channels hate it [22:39:33 CEST] <SpeakerToMeat> https://pastebin.com/M6kmySXC [22:39:51 CEST] <SpeakerToMeat> It's detecting the input as yuv444p16le [22:40:45 CEST] <kepstin> no, actually it's detecting the input as rgb48le (12bpp) [22:41:05 CEST] <kepstin> which.. might actually be ok, if it wasn't *converting* to yuv, but just passed it through [22:42:00 CEST] <SpeakerToMeat> Huh true I read output as input right [22:43:08 CEST] <SpeakerToMeat> Ok setting input and output to xyz12le [22:43:23 CEST] <kepstin> SpeakerToMeat: try throwing a "-pix_fmt rgb48le" output option on there [22:43:29 CEST] <SpeakerToMeat> And there we have the color conversion not implemented, so it is the subtitles. [22:43:34 CEST] <kepstin> to stop it from adding a conversion to yuv [22:44:15 CEST] <SpeakerToMeat> So leave out "same" as in, [22:44:38 CEST] <kepstin> SpeakerToMeat: if you do the "-pix_fmt rgb48le", please run the command with "-v verbose" so it'll tell you if it's autoinserting any scale/conversion filters [22:46:25 CEST] <SpeakerToMeat> Ok if I set both the input and output formats to xyz12le it works well (subtitles are horrible but I'll fix that by color converting to xyz by hand the ass file), but if I throw an output format as rgb48le it minces the image [22:47:15 CEST] <SpeakerToMeat> Andyes there's four auto inserted scalers [22:47:28 CEST] <kepstin> hmm, you won't be able to fix the subtitle colors - if you're getting that "Color conversion not implemented" then it's ignoring the provided color and using 128,128,128 [22:48:24 CEST] <kepstin> which could of course be fixed by implementing the color conversion :) [22:48:45 CEST] <kepstin> if the actual rendering is fine other than the color, I don't even think it would be that hard to do [22:49:00 CEST] <nicolas17> oh ugh, he can't convert the video to RGB first because that's lossy? out of gamut? [22:49:34 CEST] <SpeakerToMeat> Yes [22:49:49 CEST] <kepstin> SpeakerToMeat: can you paste the full output of the "-pix_fmt xyz12le" encode with "-v verbose"? I'm just curious about how exactly it set up the filter chain. [22:50:03 CEST] <SpeakerToMeat> I want to minimize the conversions [22:50:04 CEST] <SpeakerToMeat> kepstin: sure [22:50:42 CEST] <kepstin> SpeakerToMeat: the only place the code should be doing a color conversion is taking the 32bit bgra colors from the ass file and converting them to the pixel format of the actual frame. [22:52:05 CEST] <SpeakerToMeat> kepstin: https://pastebin.com/PFzmrNHR [22:52:23 CEST] <SpeakerToMeat> kepstin: If I only could -pix_fmt the subtitle filter too :D [22:52:49 CEST] <kepstin> SpeakerToMeat: that paste is missing parts...? [22:53:50 CEST] <SpeakerToMeat> Hmm only input #0 sorry but no other chain info [22:54:09 CEST] <mkrs> Does anyone know if the -t (duration) option uses different units now than v2.0? Seems to be seconds for me now. I'm trying to make sense of script that ran the older build. [22:54:23 CEST] <furq> it's always been a duration specification [22:54:34 CEST] <kepstin> SpeakerToMeat: can you just paste the *entire* output from the command? That output seems to be missing a fair bit [22:55:36 CEST] <furq> 12345 or 205:45 or 3:25:45 should all work [22:56:01 CEST] <SpeakerToMeat> kepstin: not much really https://pastebin.com/VzgGk23f [22:57:19 CEST] <kepstin> SpeakerToMeat: hmm, you're right. Well - good news, that filter chain is *not* doing any extra colorspace conversions, the subtitles are being drawn directly on the xyz12 frames. [22:57:36 CEST] <SpeakerToMeat> AH good [22:57:49 CEST] <kepstin> so if you just implement the missing colour conversion in libavfilter/drawutils.c, it should work perfectly. [22:58:30 CEST] <mkrs> furq, thanks. [23:00:51 CEST] <kepstin> SpeakerToMeat: in the "ff_draw_color" function in that file [23:06:03 CEST] <SpeakerToMeat> hmmm I wonder if I should just treat it like rgb [23:07:57 CEST] <SpeakerToMeat> I worry that color->comp is using either u8 or u16 [23:13:50 CEST] <kepstin> SpeakerToMeat: in this case, you'd want to set the u16, since the 12bit per component in the xyz12 is stored in 16 bit [23:14:29 CEST] <kepstin> so you'd use the rgb with depth=12 as a reference [23:16:26 CEST] <cbsrobot> SpeakerToMeat: why do you want to hardsub j2c files ? [23:16:59 CEST] <kepstin> cbsrobot: because cinema projectors, apparently. [23:17:03 CEST] <cbsrobot> can't you just add interop or smtpe subtitles to your DCP ? [23:17:06 CEST] <cbsrobot> way simpler [23:17:38 CEST] <nicolas17> we went through that already [23:17:56 CEST] <cbsrobot> I mean if you have time to implement xyz support in drawutils - go for it [23:18:15 CEST] <nicolas17> <SpeakerToMeat> But, sometimes the projector has Texas Instrument's cinecanvas inside to render them, and supposedly sometimes not, and the media server/media block doesn't always have an internal renderer [23:18:17 CEST] <nicolas17> <SpeakerToMeat> Plus, some sites haven't updated to SMPTE able hardware/firmware, so doing subtitles in digital cinema is a minefield, and sometimes like festivals or some/many distributors preffer burned in subs for that reason [23:18:35 CEST] <kepstin> it's just a packed 2 byte per channel format, so it looks like it already works with drawutils other than the missing color conversion. [23:19:15 CEST] <cbsrobot> I think most problems come from the fact of not sanitizing subtitles [23:20:00 CEST] <cbsrobot> meaning you have to convert all characters not available in your font file [23:20:24 CEST] <SpeakerToMeat> yeah [23:20:44 CEST] <SpeakerToMeat> cbsrobot: Sometimes hardsubs are requested [23:21:36 CEST] <SpeakerToMeat> cbsrobot: Yes, and most of the world has moved to smpte actually, plus the isdcf has a strong push to go to smpte, but distributors and film festivals are still reticent as they've been burned in the past [23:21:47 CEST] <cbsrobot> I mean I create multipe cpl dcps - mostly one video file, multiple language audio tracks and a then I add few subtiles to it [23:22:04 CEST] <cbsrobot> so I end up with one dcp for all kind of festivals [23:22:16 CEST] <cbsrobot> never heard of a festival refusing it [23:22:18 CEST] <SpeakerToMeat> We do too, but some people DO NOT accept those or they strongly request hardsubs [23:22:21 CEST] <SpeakerToMeat> Ok [23:22:43 CEST] <cbsrobot> maybe some convert it themselfs to a usable format [23:22:54 CEST] <cbsrobot> but hey - thats their problem [23:23:52 CEST] <cbsrobot> I heard about TI v1 v2 subtile problems and thats why dolby etc. created a subtitle overlay in software [23:24:42 CEST] <cbsrobot> btw - I'm curious - which festival forces you to send hardsubs ? [23:29:29 CEST] <SpeakerToMeat> cbsrobot: Most accept xml subs, but most suggest burned in. [23:29:45 CEST] <cbsrobot> xml subs are interop [23:30:11 CEST] <SpeakerToMeat> mxf subs in smpte are generated from xml too, and it's just the xml and ttf wrapped in a mxf [23:30:19 CEST] <cbsrobot> yeah [23:30:22 CEST] <SpeakerToMeat> plus the possibility of encryption [23:30:25 CEST] <cbsrobot> th'ats what i meant [23:31:03 CEST] <cbsrobot> so if you say: Most accept xml subs. Interop or smpte then ? [23:32:39 CEST] <SpeakerToMeat> You'd have to discuss with their technical staff, the documents aren't always the most precise, for example the Berlinale (which suggests burned in) will accept both interop and smpte, but mentions subtitles as xml [23:33:41 CEST] <cbsrobot> send them smtpe - and if they complain tell them to upgrade their hardware :) [23:33:54 CEST] <SpeakerToMeat> Yeah that always goes over right [23:33:56 CEST] <cbsrobot> eh firmware I mean [23:33:58 CEST] <SpeakerToMeat> :P [23:34:25 CEST] <SpeakerToMeat> Well locally my country arrived at DCPs pretty late, so all our equipment is smpte ready, so for local we mostly do smpte [23:34:31 CEST] <cbsrobot> did you ever had to send a dcp to the oscars ? [23:34:51 CEST] <SpeakerToMeat> Nope [23:34:57 CEST] <cbsrobot> they are the real pain! [23:35:07 CEST] <SpeakerToMeat> But we had to send DCPs to braindead distributors. [23:35:27 CEST] <nicolas17> speaking of braindead [23:35:30 CEST] <cbsrobot> hehe [23:35:46 CEST] <cbsrobot> barcos do not like interop subtitles [23:35:48 CEST] <SpeakerToMeat> One failed the QA because there was one duplicate frame (from source) and there was one text in a cell phone screen that wasn't removed (the dcp wasn't textless).... they offered to fix the DCP, at a cost [23:35:58 CEST] <cbsrobot> but most vendors are ok with smpte [23:36:02 CEST] <cbsrobot> in my experience [23:36:25 CEST] <nicolas17> if I do extern "C" { #include <libavformat/avformat.h> } KDevelop *sometimes* stops highlighting ffmpeg functions :/ [23:36:46 CEST] <cbsrobot> lol [23:36:51 CEST] <SpeakerToMeat> cbsrobot: Odd, we've not done many interops locally, but we've not had troubles with Barcos in general. The onyl time we had troubles was with an old ass Dolby DSS-220 [23:37:26 CEST] <nicolas17> I have to comment out the extern "C", reload file, and it works... and if I un-comment it still works [23:38:02 CEST] <SpeakerToMeat> kepstin: should I be safe setting only the u16? or do I need to somehow set the u8 too? [23:38:32 CEST] <SpeakerToMeat> cbsrobot: And this is a test btw only to hardsub existing j2c set rather than producing a new set from the dcdm [23:38:33 CEST] <kepstin> SpeakerToMeat: I think it's a union, so you'd set just the one that's used. [23:39:14 CEST] <cbsrobot> SpeakerToMeat: Well maybe I did some weird cpls then .... [23:40:41 CEST] <cbsrobot> SpeakerToMeat: are you working on drawutils ? [23:41:30 CEST] <SpeakerToMeat> cbsrobot: It could be... media server/block wise dolbys are pretty finicky to standards, doremis tend to support almost everything :D in fact we had to fix a DCP that had been done in 23.976 (on smpte)..... and a bloody doremi played it ok! [23:41:55 CEST] <SpeakerToMeat> cbsrobot: I'm doing a quick dirty horrible "test this shit" hack. if it works, I might consider doing a propper xyz->rbg converter [23:43:44 CEST] <SpeakerToMeat> cbsrobot: Btw did you see the IMS3000 finally has usb3? Ingest should take less than half your lifetime now! [23:44:00 CEST] <kepstin> SpeakerToMeat: the quick&dirty hack is to just do color->comp[i].u16[0] = rgba[i] << 4; and put xyz colors in the rgb valus in the ass file. [23:44:26 CEST] <SpeakerToMeat> kepstin: Yeppers that's what I am doing [23:44:34 CEST] <SpeakerToMeat> kepstin: I based the loop off the rgb if [23:45:09 CEST] <SpeakerToMeat> SHough I didn't think about the bit shift... duh [23:46:06 CEST] Action: SpeakerToMeat hits his head against a wall [23:47:28 CEST] <SpeakerToMeat> It's fun when you're trying to build the source based on the package you use.... from a backport [23:47:35 CEST] <SpeakerToMeat> I need to get half the deps manually fromt he backports [23:50:17 CEST] <furq> this probably isn't what you want to hear right now, but you should probably update to debian 9 [23:50:49 CEST] <SpeakerToMeat> furq: With how my system is set up with third party stuff, I think I'd rather jump off the balcony [23:51:36 CEST] <cbsrobot> SpeakerToMeat: opening windows or not - that's the question [23:53:33 CEST] <SpeakerToMeat> cbsrobot: I almost never use windows. Much less now with Resolve 14 out [23:53:46 CEST] <SpeakerToMeat> cbsrobot: Though I have to boot into centos, resolve is buggy on debian [23:54:03 CEST] <SpeakerToMeat> cbsrobot: The windows person is dad, he's the Premiere expert in the family [23:54:23 CEST] <SpeakerToMeat> I'm just IT (mostly :D) he's the cinema person :D [23:54:31 CEST] <cbsrobot> SpeakerToMeat: I was ment to be a joke about you jumping off the balcony [23:54:47 CEST] <SpeakerToMeat> ... [23:54:50 CEST] <SpeakerToMeat> oh [23:54:54 CEST] Action: SpeakerToMeat sighs [23:54:58 CEST] <cbsrobot> lol [23:55:03 CEST] <SpeakerToMeat> Long day... I'll go with that excuse, long and tiring day [23:55:50 CEST] <SpeakerToMeat> Ok, building my abomination of a ffmpeg now [23:56:18 CEST] <furq> meanwhile [23:56:20 CEST] <furq> http://i.imgur.com/K1sZ5VQ.png [23:56:39 CEST] <SpeakerToMeat> kepstin: if I ever do correct color conversion for drawsomething.c should I take gamut conversion in account? I'm not sure if XYZ per se is a different gamut, only its most common use (digital cinema) is. [00:00:00 CEST] --- Wed Jul 5 2017

1 0

ffmpeg-devel.log.20170703
by burek 04 Jul '17

04 Jul '17

[00:01:38 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vQEqZ [00:01:38 CEST] <KGB> 13FFV1/06master 14e9b17db 15Dave Rice: escape underscore [00:10:46 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vQEq7 [00:10:46 CEST] <KGB> 13FFV1/06master 145db2c80 15Dave Rice: bump to wg doc version 00... [00:59:48 CEST] <KGB> [13FFV1] 15michaelni tagged 06draft-ietf-cellar-00 at 06master: 02https://git.io/vQEOZ [02:09:39 CEST] <iive> is there a way for the announce bot to remain in the channel and not join and exit on every message? [02:10:47 CEST] <atomnuker> yes [02:11:45 CEST] <atomnuker> but you need to allow external messages in the channel [02:13:50 CEST] <iive> you mean, to allow the bot to message in the channel without joining it? That sound like horrible idea. [02:14:16 CEST] <atomnuker> yep [02:14:20 CEST] <iive> i didn't even thought it is possible to do such thing. [04:23:47 CEST] <Compn> maybe we can whitelist the bot [04:23:52 CEST] <Compn> so it can do external messages [04:23:57 CEST] <Compn> with +t still enabled [04:24:04 CEST] <Compn> or , let him do /onotice [12:58:28 CEST] <cone-051> ffmpeg 03wm4 07master:64ecb78b7179: vdpau: do not use buggy HEVC support by default [13:28:09 CEST] <wm4> man htmlsubtitles.c is another source file where the author's intention seems to be to make life harder for whoever was going to hack on it later [13:44:48 CEST] <ubitux> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [13:44:51 CEST] <ubitux> wtfff [13:47:25 CEST] <kierank> ubitux: arm did the same for java [13:47:33 CEST] <kierank> and sparc does the same of oracle dbs [13:47:35 CEST] <kierank> so nothing new [13:47:40 CEST] <BBB> ubitux: I dont think thats crazy [13:48:03 CEST] <BBB> the commit message is misleading to bystanders, but it just exposes instructions that are useful for certain purposes [13:48:12 CEST] <BBB> thats convenient, and probably a good thing [13:48:27 CEST] <BBB> they could have named it better ;) [13:48:50 CEST] <ubitux> ok :) [13:48:56 CEST] <ubitux> still surprising [13:49:07 CEST] <BBB> its certainly unconventional... [13:49:17 CEST] <BBB> but hey, theres all kind of crazy stuff out there [13:50:00 CEST] <BBB> didnt libavformat have a file browser API at some point? </crazy> [13:50:08 CEST] <BBB> maybe its still there :-o [13:50:36 CEST] <wm4> what's special about javascript conversions? [13:50:41 CEST] <wm4> different rounding mode or what? [13:51:29 CEST] <nevcairiel> maybe it didnt have a instruction for double -> int at all before [13:51:39 CEST] <nevcairiel> the mention of javascript is just troll bait tho [13:53:45 CEST] <wm4> well the instruction name/feature identification seems to have J in it? [13:53:56 CEST] <wm4> "JSCVT" [14:22:13 CEST] <cone-051> ffmpeg 03Steven Liu 07master:274bd1670b9c: avfomat/hlsenc: support fmp4 format in hls [14:30:28 CEST] <cone-051> ffmpeg 03Matthieu Bouron 07master:7864e07f4af2: checkasm: add sbrdsp tests [14:30:29 CEST] <cone-051> ffmpeg 03Matthieu Bouron 07master:0a24d7ca831b: lavc/aarch64: add sbrdsp neon implementation [17:08:28 CEST] <durandal_1707> atomnuker: finished anything? [17:10:19 CEST] <atomnuker> no, have to reinstall machine, apt destroyed python during an upgrade and can't install or upgrade anything [17:10:23 CEST] <atomnuker> gdb is dead because of it [17:13:10 CEST] <wm4> lol debian [17:13:25 CEST] <BBB> poor atomnuker [17:14:39 CEST] <funman> apt-get install -f ? [17:15:03 CEST] <atomnuker> "Could not find platform independent libraries <prefix>" [17:15:40 CEST] <atomnuker> yes, I even removed the problematic packages from the dpkg database but still, the way apt uses python is broken or something [17:16:01 CEST] <atomnuker> and dpkg since python is used for post/pre install scripts [17:16:32 CEST] <atomnuker> I'm even more convinced python is a bad choice for anything [17:26:37 CEST] <J_Darnley> Fuck this shit. [17:26:57 CEST] <J_Darnley> "Just run the transform on a slice" "haar is simple" [17:27:25 CEST] <atomnuker> the decoder's the hard part [17:29:54 CEST] <J_Darnley> Screw it. I am dumping 1 slice to see whether it looks anything close to right. [17:33:10 CEST] <BBB> poor J_Darnley [17:33:12 CEST] Action: J_Darnley makes note to not do this in his personal project [17:36:37 CEST] <kierank> atomnuker: decoder is easy part [17:40:11 CEST] <atomnuker> the transforms make it the hard part [17:54:21 CEST] <J_Darnley> WTF?! Why isn't that stride constant? [17:54:51 CEST] <atomnuker> it changes between planes? [17:55:11 CEST] <J_Darnley> No between whatever these strauctures are. Subbands? [17:55:49 CEST] <J_Darnley> It halves as they get bigger [17:57:07 CEST] <J_Darnley> Oh I guess they have to because it "splats" the data back out for the full plane transform. [17:57:56 CEST] <J_Darnley> No, splat is the wrong term [17:59:12 CEST] <J_Darnley> Whatever, it throws the data all across the frame [18:02:17 CEST] <J_Darnley> I think this shit is impossible without writing the decoder from scratch [18:06:06 CEST] <J_Darnley> The DSP functions need frame properties as arguments [18:06:18 CEST] <J_Darnley> The coeffs need to red into the right place [18:06:29 CEST] <J_Darnley> The transform needs to be moved inwards [18:15:22 CEST] <kierank> Just delete the transform [18:15:31 CEST] <J_Darnley> I did [18:15:36 CEST] <kierank> Ah [18:15:55 CEST] <kierank> You should be able to see the lowest level [18:17:19 CEST] <J_Darnley> I can see green, lots of green, nothing else though [18:19:45 CEST] <J_Darnley> although when I disable chroma I do get a little noise [18:21:13 CEST] <J_Darnley> Woo! segfault [18:23:50 CEST] <J_Darnley> Ah ha! Missing a factor of h and now I see something [18:25:41 CEST] <J_Darnley> The changes from the digit in testsrc is visible but that's about it [18:41:07 CEST] <J_Darnley> Well I think that looks something like increasing frequency data [18:49:41 CEST] <kierank> J_Darnley: can you paste photo [18:50:11 CEST] <J_Darnley> Probably [18:55:33 CEST] <J_Darnley_irssi> http://imgur.com/a/SnHIT [18:55:47 CEST] <J_Darnley> kierank ^ [18:56:04 CEST] <kierank> thanks [18:57:25 CEST] <J_Darnley> Will crop in future [18:57:33 CEST] <J_Darnley> 4x neighbour scaling [19:00:12 CEST] <kierank> i have a 4k screen, idon'tcare :) [19:01:38 CEST] <J_Darnley> Ah dinner is being cooked without me [19:01:46 CEST] Action: J_Darnley hurredly commits [19:04:11 CEST] <J_Darnley> Code is https://gitlab.com/J_Darnley/ffmpeg dirac branch if you want it. [19:04:14 CEST] Action: J_Darnley afk [19:18:18 CEST] <wm4> so we're doing some kind of live streaming with HLS (with ffmpeg being on both muxing and demuxing side), which involves a sliding window of active content [19:18:40 CEST] <wm4> apparently HLS has mechanisms for that, but there's no API that could be used to let the HLS demuxer report the current window start/end to the API user [19:18:48 CEST] <wm4> any suggestions how that would be done best? [19:36:56 CEST] <wm4> nevcairiel: ok with pushing libturing? [19:37:30 CEST] <wm4> you were the last person to comment on it [19:39:02 CEST] <durandal_1707> how to pass function args to mX registers? [19:40:01 CEST] <iive> x86asm ? [19:42:42 CEST] <durandal_1707> yes [19:43:05 CEST] <durandal_1707> its int and i want just byte part [19:45:16 CEST] <kierank> movb? [19:46:31 CEST] <BBB> durandal_1707: pinsrb [19:46:41 CEST] <BBB> (if its from memory) [19:46:56 CEST] <BBB> if its from a register, use movd [20:00:02 CEST] <durandal_1707> BBB: its ugly i call it 16 times [20:00:13 CEST] <BBB> call what? [20:04:35 CEST] <kierank> durandal_1707: why [20:04:43 CEST] <kierank> why do you need to load bytes like that [20:04:45 CEST] <durandal_1707> pinsrb [20:05:09 CEST] <durandal_1707> to put each byte into position in mX [20:05:29 CEST] <atomnuker> couldn't you mova and the pshufb (SPLATB_REG)? [20:05:34 CEST] <kierank> but you can load and shuffle etc [20:05:51 CEST] <durandal_1707> i dunmo [20:10:38 CEST] <durandal_1707> https://pastebin.com/BzXJ2R1x [20:12:22 CEST] <atomnuker> mova + pshufb [20:12:43 CEST] <durandal_1707> doesnt work [20:12:53 CEST] <atomnuker> why not? [20:13:02 CEST] <durandal_1707> i get errors [20:13:11 CEST] <durandal_1707> when compilimg [20:13:22 CEST] <atomnuker> invalid operand or something like that..? [20:13:27 CEST] <atomnuker> oh, you need minbq [20:15:10 CEST] <atomnuker> so SPLATB_REG m1, minbq, [splat_table] [20:16:10 CEST] <atomnuker> and your splat_table would just be splat_table: times 16 0x0 [20:22:43 CEST] <atomnuker> (you could just pxor m2, m2 and use that as your splat table) [20:25:45 CEST] <BtbN> Can someone with Windows and an Intel-CPU(Shouldn't matter how recent), run this https://btbn.de/files/ffmpeg.exe with this command line: ./ffmpeg.exe -cpuflags 0 -f lavfi -i anoisesrc=r=48000 -t 1:00:00 -strict -2 -c:a opus -b:a 96k -f null - [20:32:48 CEST] <J_Darnley> BtbN: 46555 UNITS in pvq_search, 8385232 runs, 3376 skips [20:33:12 CEST] <BtbN> hm, ok. So it's not entirely a Ryzen problem [20:33:25 CEST] <BtbN> what CPU at what clock is that? [20:34:37 CEST] <J_Darnley> 17 750 (Nehalem) 2.66GHz (I think [20:34:46 CEST] <BtbN> hm [20:34:48 CEST] <J_Darnley> i7 I mean [20:35:04 CEST] <BtbN> I get 55k UNITS on a 1800X with 3.7GHz [20:35:50 CEST] <durandal_1707> atomnuker: and how to do same but with words instead of bytes? [20:36:20 CEST] <BtbN> iive, in case you also want to test ^ [20:38:12 CEST] <iive> BtbN: sure [20:41:18 CEST] <atomnuker> durandal_1707: same as you do bytes, just change your splat_table to times 8 0x0, 0x1 [20:41:29 CEST] <iive> BtbN: my wine is 32bit only... WOW is a lot more effort and problem. [20:41:34 CEST] <iive> in short, can't test it ATM [20:42:33 CEST] <atomnuker> (SPLATD assumes your word is already loaded and SPLATW also assumes its already loaded in another/the same register, so you have to do a shuffle anyway) [20:42:44 CEST] <iive> but 46k is quite slow too. [20:44:29 CEST] <jkqxz> 61450 UNITS. [20:44:38 CEST] <jkqxz> N3700, Braswell @ 2.4GHz. Is there a prize? :) [20:45:00 CEST] <iive> is that intel of amd? [20:45:20 CEST] <atomnuker> yes, that of the world's least optimizing compiler (I get 6000 on linux x86 gcc) [20:45:21 CEST] <jkqxz> Intel low-power. [20:45:35 CEST] <iive> atom like? [20:46:30 CEST] <jkqxz> Yeah. It's current-minus-one generation atom-type. [20:49:09 CEST] <jkqxz> Ah, I screwed up the command line and set the wrong bitrate when transcribing it to windows. Actually it's only 41k. [20:49:42 CEST] <iive> :) [20:49:54 CEST] <BtbN> hm [20:49:59 CEST] <BtbN> it's notably better than on Ryzen [20:50:05 CEST] <BtbN> but still worlds slower than the gcc version [20:50:13 CEST] <iive> i bet the lrintf is not that slow on intel. [20:51:02 CEST] <iive> well, at least this settles it as MSVC missing optimization. [20:53:00 CEST] <wm4> everything silent about libturing, so I guess I'm forced to push it [20:54:02 CEST] <durandal_1707> atomnuker: thereis no splatw_reg [20:54:49 CEST] <atomnuker> no, so you use SPLATB_REG [20:56:18 CEST] <jkqxz> wm4: Does it actually build and work by default now? [20:56:35 CEST] <wm4> maybe? [20:56:43 CEST] <wm4> at least the guy claimed it does [20:56:56 CEST] <wm4> meh I guess I'll do it tomorrow [20:58:13 CEST] <jkqxz> If it builds and works for you then just do it, IMO. [20:58:42 CEST] <wm4> just that building libturing is probably a project on its own and can't just be done in 2 minutes [20:59:01 CEST] <wm4> but I fully agree that this should be done at least before pushing [20:59:46 CEST] <durandal_1707> atomnuker: i get wrong output with that [21:00:18 CEST] <durandal_1707> for w case i fetch words into regs [21:02:43 CEST] <atomnuker> durandal_1707: hm, maybe I forgot to account for endianess, try times 8 0x1, 0x0 [21:08:14 CEST] <durandal_1707> atomnuker: https://paste.ubuntu.com/25013117/ [21:10:56 CEST] <atomnuker> does it work? [21:12:46 CEST] <durandal_1707> nope [21:14:33 CEST] <atomnuker> both versions or only the 16 bit version? [21:15:19 CEST] <durandal_1707> 8bit works, 16bit doesnt [21:19:20 CEST] <atomnuker> mova the m1 and m2 regs, RET and see what they have in there [21:24:17 CEST] <iive> there is SPLATW [21:27:46 CEST] <durandal_1707> iive: and how im supposed to use it? [21:29:38 CEST] <iive> movd m1, min [21:29:45 CEST] <iive> SPLATW m1, m1 [21:31:30 CEST] <iive> maybe you have to add 'dword mind' [21:32:59 CEST] <iive> not that there would be a problem if it picks 64bit movd. [21:33:24 CEST] <iive> but that's usually movq [21:38:46 CEST] <iive> also, SPLATB_REG , the 3'd parameter is immediate value. 0 should work just fine. [21:39:23 CEST] <iive> no [21:39:25 CEST] <iive> mybad [21:47:57 CEST] <ubitux> durandal_1707: s/limiter/clamp/? [21:48:08 CEST] <ubitux> (typical GL naming) [21:48:20 CEST] <durandal_1707> ubitux: i prefet vs name [21:48:37 CEST] <durandal_1707> thereis also alimiter :) [21:52:26 CEST] <ubitux> ok ok [22:37:01 CEST] <durandal_1707> atomnuker: regarding new bitstream , how you supposed to handle vlc stuff. its in separate header? [22:41:08 CEST] <atomnuker> I pasted it in so its just 1 file like get_bits again [22:45:45 CEST] <durandal_1707> nooo [22:45:56 CEST] <atomnuker> you'd like it to be separate? [22:46:07 CEST] <atomnuker> I don't mind [22:46:15 CEST] <durandal_1707> it is separate [22:47:05 CEST] <atomnuker> get_vlc2 is in get_bits.h, but in libav its in libavcodec/vlc.h (IIRC) [22:47:57 CEST] <durandal_1707> atomnuker: just add cache of 64 bits [22:54:51 CEST] <atomnuker> its not that simple [22:55:23 CEST] <atomnuker> (but if you think it is go ahead and send a patch, I can't do anything until I finish installing debian again tonight) [23:43:45 CEST] <cone-230> ffmpeg 03Aman Gupta 07master:6d4a686d4521: lavc/mediacodec: add missing newline on warning [23:43:46 CEST] <cone-230> ffmpeg 03Aman Gupta 07master:aad79e4323bb: lavc/mediacodec: rescale pts before decoding for both hw and sw buffers [23:46:00 CEST] <TMM> durandal_1707, sorry for the stupid patch... I actually had corrected that before sending it but ended up reverting it back to the stupid comparison again for some reason? I don't even know... [00:00:00 CEST] --- Tue Jul 4 2017

1 0

ffmpeg.log.20170703
by burek 04 Jul '17

04 Jul '17

[02:18:16 CEST] <bismusus> I'm trying to encode this multisub opera video and burn a dvdsub track into it [02:18:56 CEST] <bismusus> I've been using -filter_complex '[0:x] [0:y:z] overlay ' letters pertaining to stream name [02:19:55 CEST] <bismusus> instead of burning in it seems to attach a sub track with nothing but the chapter name [02:20:14 CEST] <bismusus> did something change before the documentation could catch up? [11:36:17 CEST] <superware> with ffmpeg libav, is it possible to mux a private data stream into an mpeg2ts stream? [11:50:42 CEST] <bismusus> I tried adding simple srt subs to another file using -vf subtitles=foo.srt, before it was picture subs but this time it isn't anything fancy at all: subs don't appear at all on mpv and on VLC there's a sub track with the chapter name [11:51:07 CEST] <bismusus> does it matter to the filter that I'm picking a random minute with -ss and -t? [12:02:28 CEST] <bismusus> turns out it does [12:11:33 CEST] <bismusus> turns out that my problem is one of many caused by putting the -ss argument before the -i [12:43:20 CEST] <c_14> bismusus: yeah, putting -ss before -i adjusts the timestamps of the file before it does anything else. either put the -ss after (so the timestamps are adjusted after doing everything else) or add -copyts (so they aren't adjusted) [12:45:06 CEST] <samgoody> I need libfdk_aac on Ubuntu. [12:45:24 CEST] <samgoody> From what I gather, that means I need to compile ffmpeg on my own. [12:45:27 CEST] <samgoody> Is that correct? [12:45:55 CEST] <samgoody> Or is there some more benign (for a newb. Since if I compile, I will forget to ever update it) way [12:47:24 CEST] <DHE> licensing doesn't allow redistribution. yes, you'll have to build it yourself [12:47:42 CEST] <DHE> which means you'll also need any other 3rd party extras you want (most notably libx264) for your build [12:47:52 CEST] <samgoody> Actually, I guess I should first ask. For conversion from MP3 to AAC, is it really important to use libfdk_aac or is the internal free encoder good enough? [12:48:33 CEST] <DHE> the latest version (3.3) is good enough. libfdk_aac is considered superior still, but stock is now acceptable [12:49:00 CEST] <kerio> is the difference in any way relevant at 128kbps stereo [12:49:07 CEST] <kerio> ? [12:49:25 CEST] <kerio> i thought it was more about HE-AAC [12:50:21 CEST] <samgoody> I am using 54Kbs - 96Kbs if that matters [12:50:42 CEST] <DHE> samgoody: single channel? or stereo? [12:51:05 CEST] <DHE> at those low bitrates you might want to start considering HE-AAC like kerio mentioned. which makes libfdk_aac more important [12:51:28 CEST] <kerio> DHE: but the builtin encoder is fine at 128kbps stereo right [12:52:01 CEST] <samgoody> stereo. I don't really understand audio, and don't understand the real difference between HE and LC [12:52:06 CEST] <DHE> I think so. I'd conduct listening tests to be sure if it matters [12:52:34 CEST] <DHE> I'm just a user who uses ffmpeg. I don't know nearly as much as some people think [12:52:50 CEST] <samgoody> I have a bunch of video files created with an apparently buggy implementation of MP3 and they dont play audio when streaming. [12:53:09 CEST] <samgoody> The internets say to reencode them to AAC, and ffmpeg makes that really easy [12:53:22 CEST] <kerio> oh lmao [12:53:38 CEST] <kerio> just do 128kbps honestly [12:53:44 CEST] <DHE> that is technically correct [12:53:50 CEST] <kerio> also if you're fine with chrome, just use opus [12:54:00 CEST] <kerio> i mean it's fine for everything but ios [12:54:04 CEST] <kerio> (and macos) [12:54:18 CEST] <samgoody> But I known nothing about audio, but the incoming audio, according to itunes is only 54K to 96K. [12:54:29 CEST] <samgoody> hence my assumptions. [12:54:32 CEST] <kerio> yes but [12:54:37 CEST] <kerio> i mean [12:54:42 CEST] <kerio> you're transcoding [12:55:30 CEST] <kerio> from a bad source [12:55:38 CEST] <kerio> the last thing you want is to add more loss [12:55:57 CEST] <kerio> samgoody: ooh have you tried remuxing them? [12:56:02 CEST] <kerio> it might help! [12:56:33 CEST] <kerio> ffmpeg -i foo.mp3 -c:a copy bar.mp3 [12:56:52 CEST] <kerio> should be near instant [12:57:26 CEST] <samgoody> That just fixes the MP3? [12:57:48 CEST] <samgoody> That would be awesome. Gee, thanks for taking time to even help no-nothings like me [12:57:54 CEST] <kerio> it will take everything from foo.mp3, copy the audio without transcoding, and put anything that fits into a mp3 in bar.mp3 [12:57:59 CEST] <squ> kerio: it will increase size with bad quality [12:58:00 CEST] <kerio> it'll jumble it up a bit [12:58:30 CEST] <kerio> maybe it'll help with streaming idk [13:01:10 CEST] <samgoody> The audio file is mp4a.40.34 [13:01:45 CEST] <samgoody> Which is not supported by FF or Chrome. So w/o understanding remuxing, will that output a better MP3 that is then understand by the browsers? [13:01:54 CEST] <kerio> wait what [13:01:56 CEST] <kerio> that is not mp3 [13:02:01 CEST] <kerio> samgoody: can you upload this file somewhere? [13:02:04 CEST] <squ> m4a should be supported [13:02:07 CEST] <kerio> or is it private/confidential/stuff [13:02:32 CEST] <kerio> alternatively, pastebin the output of `ffprobe path/to/your/file` [13:03:06 CEST] <samgoody> Not confidential. Happy to upload. one min [13:04:49 CEST] <squ> > The MP4 container format with the H.264 video codec and the AAC audio codec is natively supported by desktop/mobile Internet Explorer, Safari and Chrome [13:05:06 CEST] <kerio> i'm just gonna open the link in safari and proclaim that it's perfectly fine if it plays btw :^) [13:05:09 CEST] <samgoody> https://pastebin.com/gp18Dnsc [13:05:26 CEST] <squ> I can tell you Chrome plays mp4a [13:06:10 CEST] <kerio> oh so it's a video file [13:06:45 CEST] <kerio> i'd honestly just try ffmpeg -i path/to/foo.mp4 -c:v copy -c:a copy bar.mp4 [13:06:54 CEST] <kerio> and see if bar.mp4 plays fine in browsers [13:07:08 CEST] <kerio> because h264/mp3 should play fine anywhere, i think [13:07:20 CEST] <kerio> hm maybe the h264 part is causing problems? [13:09:11 CEST] <samgoody> Firstly, you are right: here is the file and it plays in the browser - https://therapistexpress.com/dev/videoplayers/transaudio_1.mp4 [13:09:44 CEST] <samgoody> However, when I try to stream that with Wowza, audio doesn't play. And when I rencode to AAC and stream with Wowza, audio does play [13:09:54 CEST] <samgoody> Both when using HLS and Dash [13:10:30 CEST] <samgoody> So, some very quick research implies that the issue is with the HLS handling of that format of audio in the browsers. I found a Chromium bug report, one sec [13:10:36 CEST] <squ> what is Wowza [13:11:02 CEST] <squ> samgoody: it means Wowza using video container which does not support mp3 [13:11:26 CEST] <kerio> the rapist express :thinking_face: [13:11:59 CEST] <squ> I don't see why you should bug report Chrome [13:12:07 CEST] <kerio> ah yes, HLS does not support mp3 [13:12:20 CEST] <kerio> so yeah, convert to aac [13:13:25 CEST] <kerio> just do -c:a aac [13:13:40 CEST] <samgoody> That's it? I dont need a bitrate? [13:14:29 CEST] <samgoody> ffmpeg -i input.mp4 -c:v copy -c:a libfdk_aac output.mp4 [13:14:29 CEST] <samgoody> And should I use libfdk_aac [13:14:31 CEST] <squ> copy the parameters close to input [13:15:10 CEST] <squ> to not reduce quality, or increase size for bad quality [13:15:27 CEST] <samgoody> Is there a way to have it figure out the optimal bitrate (which I assume is very close to original bitrate)? [13:15:36 CEST] <kerio> that is a VERY bold assumption [13:15:48 CEST] <squ> can't you look it up? [13:15:59 CEST] <kerio> samgoody: just do 128kbps aac, relaly [13:16:01 CEST] <kerio> really [13:16:53 CEST] <squ> samgoody: https://trac.ffmpeg.org/wiki/Encode/AAC [13:17:09 CEST] <samgoody> I have to reencode all of my old videos, in order to stream them. That is several hundred. Would rather just run a bash script. So just using 128kbps, if it won't ruin anything by being much larger than the original, and won't bloat the size crazily (as it is for streaming) is great. [13:17:28 CEST] <samgoody> Will read the link, thanks. [13:17:39 CEST] <squ> just do it now [13:19:48 CEST] <squ> several hundred 3 minute sound files take an hour to encode [13:20:44 CEST] <kerio> make sure to use -c:v copy [13:20:59 CEST] <squ> yes [13:26:26 CEST] <squ> samgoody: can help you with a script [13:27:00 CEST] <squ> I've done it to copy source to destination with path/subpath structure [13:28:18 CEST] <kerio> samgoody: why can't you just convert it to HLS with ffmpeg? [13:28:46 CEST] <samgoody> would appreciate help with a script, but figured I should at least try on my own. [13:29:20 CEST] <samgoody> kerio, what do you mean? HLS is just a streaming container format, that can take mpeg-2 or mp4, or at least that is how I undertsand it [13:29:38 CEST] <kerio> yeah but ultimately it's a bunch of .ts and a .m3u8 [13:30:46 CEST] <kerio> ffmpeg can produce that [15:22:28 CEST] <gaviriar> Hi There, I am curious about wether It is possible to compile FFMPEG for an ARM target on bare metal, i.e. without an OS. [15:22:37 CEST] <BtbN> no [15:22:55 CEST] <gaviriar> Was curious to know if this has ever been attempted, or wether it is possible? [15:23:17 CEST] <BtbN> If you write an OS that supports everything ffmpeg needs, and has a full C toolchain, sure [15:23:29 CEST] <BtbN> But why not use one that already exists, like, Linux? [15:23:54 CEST] <gaviriar> well, I was thinking of using FFMPEG on a bare metal target. [15:24:18 CEST] <BtbN> ffmpeg is not an OS [15:25:39 CEST] <gaviriar> Sure, I am aware of that, but I was wondering if is it tightly coupled with the OS system libraries? [15:25:50 CEST] <leif> Hey all, I am using FFmpeg's C API ot encode packets taht come out of a filtergraph. However, I am noticing that the number of audio samples is larger than the codec's framesize. [15:26:23 CEST] <leif> Namely, i'm trying to encode aac, with a frame size of 1024 samples. All of the frames have 1024 samples, follwed by one lest than 1024, and one at 44100 samples. [15:26:33 CEST] <leif> Has anyone seen this pattern? [15:26:48 CEST] <leif> (Otherwise I will continue trying to make a more minimal example.) [15:28:21 CEST] <leif> gaviriar: as far as I can tell, it is not tied to any particular os library, but it most certainly is tied to the existance of an OS library. [15:28:40 CEST] <leif> (Although I'm new here, so I couldvery easily be wrong.) [15:34:23 CEST] <leif> Anyway, I find it bizare that the frame size is 44100 samples, but only for the last frame... [15:35:25 CEST] <leif> Oh, also, when I manually use an asetnsamples filter (set to 1024), the video will render, but the audio is delayed. [15:38:43 CEST] <leif> ooh...actually, I just had an idea. Perhaps it's not the last frame, but one in the middle. (I'm using the acrosfade filter, and perhaps that doesn't set the output framesize the way I would expect it to.) [15:39:03 CEST] <leif> Which would explain why using the asetnsamples filter would work. [15:40:06 CEST] <leif> (Although the problem with using it is that the encoder won't know what frame size it needs until _after_ it calls avcodec_open2, but I can't call that until after I've already built the filtergraph. :/ [15:43:31 CEST] <leif> Oh derp, `av_buffersink_set_frame_size`... *facepalm* Anyway, thanks for being being my rubber ducks. :) [15:44:32 CEST] <JEEB> :) [15:44:39 CEST] <JEEB> always good to let it out once [15:56:18 CEST] <DHE> gaviriar: something needs to feed it the data from whereever... network, camera, disk. I mean ffmpeg should work on DOS or something but that's still a (minimal) OS. [16:06:51 CEST] <gaviriar> DHE: Ok thanks for the input, I guess I will have to dig into this a bit further. My guess is that the target device I plan to use has some minimal OS but ffmpeg may not support it out of the box? [17:18:56 CEST] <kerio> gaviriar: i don't think libavcodec needs anything beyond a basic c library [17:19:09 CEST] <kerio> however, it will also do nothing with your hardware [17:37:59 CEST] <DHE> is open(filename, O_RDONLY) considered standard? I thought it was POSIX [17:53:02 CEST] <roxlu> hey! I'm using the zeranoe downloads in my (win64) application. When I run my app I get a message "The procedure entry point av_dump_format could not be located in the dynamic link library". When I open my app with dependecy walker I do see av_dump_format listed. Am I doing something wrong? [18:08:26 CEST] <roxlu> Ah.. I was linking with the .dll.a files instead of the .lib [18:51:04 CEST] <The_8472> DHE, fopen would be C-standard. open / O_RDONLY are posix, but windows' c library has something mimicking them. but idk if that's what ffmpeg uses [18:58:31 CEST] <DHE> The_8472: it uses the latter. so the C library would have to be a bit better than historical ANSI-style C [18:58:35 CEST] <DHE> but anyway... [19:14:12 CEST] <mcgrew> I have an encoding question (I'm using the 2.6.8 api because redhat). I'm encoding a series of jpegs and raw audio into an MP4. Everything is working except that the video stream start time is non-zero (usually between 1-2 sec). I've verified that the ptd & dts of the first frame are zero, along with start_time of the AVStream. Does anyone have any other ideas where I could look to determine why this is happening? [19:14:42 CEST] <mcgrew> pts, not ptd* [19:22:08 CEST] <mcgrew> I'm using libx264 + libfdk_aac for the encoders in case that matters. [19:40:58 CEST] <thebombzen> DHE: you should use fopen() anyway rather than the system call. There's a reason the standard C library exists [19:43:33 CEST] <thebombzen> mcgrew: libx264 and libfdk_aac have incompatible licenses, so in order to do that you need to build FFmpeg yourself and it's nonfree and unredistributable. If that's the case, is there a reason you're locked into the 2.6.8 API? [19:44:06 CEST] <thebombzen> Specifically, libx264 is GPLed and libfdk_aac has a GPL-incompatible license. [19:44:44 CEST] <DHE> thebombzen: normally I would agree, but ffmpeg is using open(), read() and so on rather than standard C library. so... [19:45:11 CEST] <kerio> DHE: surely that's the ffmpeg command line tool, not ffmpeg as a whole [19:45:37 CEST] <thebombzen> ffmpeg.c is not known for having beautiful code [19:48:42 CEST] <DHE> kerio: libavutil/file_open.c has both methods in it, and that seems to be how the file protocol handles it [19:50:07 CEST] <mcgrew> thebombzen: For now this isn't going to be distributed, but if that changes I'll bear it in mind. I suppose I could build against a later version of the API if that is the only solution, but that's the latest version on the Redhat version bieng used. [19:50:12 CEST] <mcgrew> being* [19:51:26 CEST] <mcgrew> It's much easier from a logistical standpoint to use that version if possible. [20:56:52 CEST] <thebombzen> mcgrew: I'd recommend using the built-in AAC encoder anyway if you're going to be using the latest version of FFmpeg. At this point in git master it's actually better than fdk-aac [20:57:23 CEST] <thebombzen> However 2.6.8 is ancient, so it's very possible that you're having issues because you're using an older version. [20:57:46 CEST] <thebombzen> mcgrew: If you're interested in a legacy ABI, you might want to check out the 2.8 branch, which is still having major bugfixes ported today afaik. [20:58:02 CEST] <thebombzen> Especially since if you're distributing binaries, you care more about the ABI than the API anyway. [21:01:06 CEST] <thebombzen> mcgrew: But if the latest RHEL package is 2.6.8, that is pretty ancient. There's a good chance you're just experiencing this bug because you're using an older FFmpeg, not because you're misapplying the library. [21:03:06 CEST] <thebombzen> for reference, RPM Fusion has the ffmpeg 2.8 branch in its RHEL7 "free" repository [21:05:11 CEST] <thebombzen> http://download1.rpmfusion.org/free/el/updates/7/x86_64/repoview/index.html [21:05:24 CEST] <mcgrew> thebombzen: I don't have much control over the server this will be running on, but I'll look into it. From my understanding ffmpeg is not shy about making breaking API changes, which is one of my concerns with moving to a newer version. [21:06:03 CEST] <thebombzen> They are not super shy about it, but they do bump version numbers if they do. However, they do try a lot harder to preserve ABI compatibility [21:06:30 CEST] <thebombzen> which means you might have extra work to keep up to date on the source-level compatibility, but the binary compatibility will be there, so your end users should not have to worry. [21:07:08 CEST] <nicolas17> well, libavformat has changed ABI 56 times :P [21:07:25 CEST] <thebombzen> depends on what you mean by "changed ABI [21:07:40 CEST] <nicolas17> bumped soname [21:07:55 CEST] <thebombzen> doesn't mean that the library is incompatible [21:08:06 CEST] <BtbN> a soname bump means exactly that [21:08:09 CEST] <nicolas17> that's the *whole point* of changing the soname [21:08:27 CEST] <thebombzen> shrug [21:08:42 CEST] <thebombzen> either way, there's a reason the 2.8 branch is still updated. git master might change a lot, but the branches shouldn't [21:08:53 CEST] <BtbN> It's still updated so distros are happy [21:09:10 CEST] <BtbN> Once no major distro uses 2.8 anymore, there won't be further backports [21:09:12 CEST] <mcgrew> But to be clear the AAC encoder doesn't seem to be the issue, just that the h264 stream start is at ~1.5 sec, which throws video & audio out of sync. [21:40:27 CEST] <thebombzen> mcgrew: yea, my comment was more that using internal AAC solves the license issue (and it's got better quality, if you are using a recent enough version) [21:41:29 CEST] <thebombzen> As for the 1.5 second issue, I don't know. What happens if you try using libavfilter to insert a setpts=PTS-STARTPTS filter? I ask because if the issue is still occurring on the output of that filter, then it means it's probably an issue with the muxing. If this fixes it, then the issue is somewhere else. [21:47:59 CEST] <mcgrew> I'm not sure. I'm not currently using libavfilter in any capacity and I imagine a lot of changes would be needed to use it. [21:48:32 CEST] <DHE> for how easy that is to implement I woudln't bother with libavfilter [21:49:50 CEST] <nicolas17> if you're using the API you don't need avfilter for that [21:49:54 CEST] <nicolas17> just mess with the pts yourself [21:56:28 CEST] <mcgrew> I've verified that the pts and dts of the first frame is 0. Is there another way to set the start_pts? [21:56:49 CEST] <mcgrew> I also set AVStream::start_time to 0. [22:06:30 CEST] <mcgrew> Also the pts & dts of the AVPacket are set to the pts of the AVFrame, which is 0 for the first frame. [22:11:40 CEST] <DHE> you should set the pts to the AVFrame and then just use the pts/dts provided by the encoder in the AVPacket [22:28:36 CEST] <mcgrew> That's what I was doing previously - I switched it back. Same result though. [22:30:10 CEST] <mcgrew> Possibly related: ffprobe on my output video is reporting 23 less frames than it should have. This happens on 130 frame video and a 7k+ frame video. [22:31:43 CEST] <mcgrew> Could this have something to do with keyframes? [22:39:13 CEST] <mcgrew> Alright I'm giving up on this for now. I'll poke around on it more later. Thanks for the help. [00:00:00 CEST] --- Tue Jul 4 2017

1 0

ffmpeg-devel.log.20170702
by burek 03 Jul '17

03 Jul '17

[00:00:02 CEST] <nevcairiel> (unless you count USB slots on power outlets :p) [00:01:01 CEST] <rcombs> how long until we get in-wall USB-C supplies that actually put out a decent amount of power [00:01:09 CEST] <iive> well, with DC you still have same problem with Voltage and Current. [00:01:10 CEST] <rcombs> (inb4 never because heat dissipation problems) [00:01:39 CEST] <nevcairiel> dont know about C, but there are in-wall outlets with USB-A connectors, not sure how much power they provide tho [00:01:47 CEST] <rcombs> not a whole lot [00:01:51 CEST] <rcombs> 10~20W tops [00:02:00 CEST] <rcombs> I want 87 [00:02:14 CEST] <iive> have in mind, 20W on 5V is 4A [00:02:45 CEST] <atomnuker> the cables are the issue IMO [00:02:48 CEST] <BtbN> USB-C increases the voltage for power-delivery [00:02:49 CEST] <rcombs> yeah, that's why USB-C does higher voltages [00:02:56 CEST] <nevcairiel> not sure what latest gen quick charge is rated at, however keep in mind that those high-power chargers do take a toll on the batteries [00:03:09 CEST] <BtbN> USB-C does 100W max, at 20V [00:03:29 CEST] <rcombs> i.e. up to 5A [00:03:41 CEST] <rcombs> (the cable indicates its max current) [00:04:46 CEST] <wm4> wow that's high [00:49:48 CEST] <kierank> BtbN: usb-c pd [00:49:49 CEST] <kierank> yes [00:50:09 CEST] <kierank> 10:58 PM <"atomnuker> DC is scary as fuck and I'm not touching it [00:50:10 CEST] <kierank> yes [00:50:12 CEST] <kierank> dc is fucking scary [00:50:16 CEST] <kierank> ac throws you off [00:50:20 CEST] <kierank> dc you stick to it [01:44:08 CEST] <iive> electricity makes your muscles contract, dc or ac. If you grab a power wire you are stuck to it. [01:46:12 CEST] <atomnuker> yes, but the latter also expands any contracted muscles every 1/2 period [01:46:31 CEST] <iive> no expanding [01:48:01 CEST] <iive> muscles only contract and relax. [01:49:35 CEST] <iive> that's why you have different muscle groups for closing your fingers and "expanding" them. [01:50:06 CEST] <iive> and these for closing are stringer and will win. [01:54:40 CEST] <iive> so as safety tip, if you absolutely must touch a metal part that might be under power, touch it with the outside of your hand. [03:07:42 CEST] <iive> n8 ppl [03:10:33 CEST] <DHE> atomnuker: muscles only pull. the "squeeze" muscles in your hand are stronger than the "release" muscles so you squeeze. AC will just cycle squeeze<->relax [07:18:58 CEST] <LongChair> wm4, jkqxz: here is my proposal https://github.com/LongChair/FFmpeg/blob/rockchip-new/libavutil/hwcontext_d… [12:09:00 CEST] <wm4> LongChair: does it really need multiple FDs for a single layer? [12:21:14 CEST] <LongChair> not for rockchip, but most of the primitives for EGL & DRM have an fd array. so i believe it could be used [12:21:53 CEST] <LongChair> theorically i think you could maybe have an fd for each layer planes ... with offset = 0 [12:24:20 CEST] <LongChair> for EGL CreateImageKHR uses attributes, and you could have several FDs in there ... and drmModeAddFB2 also has and array of fds / offsets / pitches [12:25:14 CEST] <LongChair> in rk implementation the nv12 decoder output only has one fd with different offsets for planes, but iirc v4L2 decoder could have one gd per plane [12:25:37 CEST] <LongChair> so just wanted to play it safe as it doesn't add a lot of overhead :) [12:38:09 CEST] <wm4> so why distinguish between layers and planes again? [13:00:07 CEST] <LongChair> because if we just keeps planes it doesn't make it handy to group planes by formats to build the strides & offsets [13:00:53 CEST] <LongChair> basically with nv12 usual format you would have one layer and multiple offsets / strides that would become a texture or a drm layer [13:01:20 CEST] <LongChair> with vaapi, you would have 2 layers with different format each that would become 2 textures [13:01:44 CEST] <LongChair> each layer would have zero offset and one stride [13:02:04 CEST] <LongChair> in the end a layer becomes a texture for egl or a drm layer [13:02:47 CEST] <LongChair> if we don't handle that in the frame to group them, then we'll have to do it in renderer, and that would add overhead [13:04:12 CEST] <LongChair> several layers is not useful for drm as drm can only cope with a dingle format data [13:04:24 CEST] <LongChair> but it does for EGL / vaapi afaik [13:04:37 CEST] <LongChair> this is what mpv renderer would look like https://github.com/LongChair/mpv/blob/9e8564950ba4360a6c015d434cf994d296ca4… [13:05:50 CEST] <jkqxz> Is this the same as the nested-structures version we had a while ago? (Except with multiple arrays rather than an array of structures.) [13:07:15 CEST] <jkqxz> I'm not convinced that multiple objects in a layer is meaningful. The whole point is that it's a single DRM_FORMAT_foo instance, and that must be within a single object. [13:08:58 CEST] <jkqxz> I think that would look better as nested structures rather than the arrays. Also I think it should have an nb_planes element, because valid/invalid values there are not clear. [13:09:53 CEST] <wm4> fine... [13:11:26 CEST] <jkqxz> wm4: It was mainly you that didn't like the nested structures, IIRC. [13:11:36 CEST] <wm4> yes [13:27:07 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #74: len - 1 is unsigned (06master...06len) 02https://git.io/vQ0Xc [15:41:41 CEST] <KGB> [13FFV1] 15michaelni closed pull request #56: Improvement of context and quantization tables paragraphs (06master...06context) 02https://git.io/vSQ3j [15:58:40 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vQ0Sj [15:58:40 CEST] <KGB> 13FFV1/06master 1445e70a0 15Jérôme Martinez: len - 1 is unsigned... [16:16:11 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #75: Move of sample names to a dedicated paragraph (06master...06Sample) 02https://git.io/vQ0HU [16:20:32 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #76: Restrictions section is a top level section (06master...06Restrictions) 02https://git.io/vQ0H4 [16:35:18 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #77: White space for forcing carriage return in a paragraph (06master...06Markdown) 02https://git.io/vQ0Qm [17:34:36 CEST] <cone-397> ffmpeg 03Paul B Mahol 07master:c8853568b177: avcodec/alsdec: call correct function for multi-channel coding [18:10:40 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vQ0FR [18:10:40 CEST] <KGB> 13FFV1/06master 14a45be46 15Jérôme Martinez: Move of sample names to a dedicated paragraph [18:13:01 CEST] <KGB> [13FFV1] 15michaelni closed pull request #76: Restrictions section is a top level section (06master...06Restrictions) 02https://git.io/vQ0H4 [20:37:39 CEST] <KGB> [13FFV1] 15michaelni closed pull request #73: update to version 03 (06master...06update-to-version-03) 02https://git.io/vQBV4 [21:41:51 CEST] <TMM> I'm trying to make an ffmpeg trac account but something appears to be wrong [21:42:08 CEST] <TMM> it seems to be hanging on the post to register_ffmpeg_two [21:43:05 CEST] <TMM> nvm, it eventually went through, took several minutes though [23:36:31 CEST] <KGB> [13FFV1] 15michaelni tagged 06draft-ietf-cellar-03 at 06master: 02https://git.io/vQELr [23:44:53 CEST] <KGB> [13FFV1] 15dericed opened pull request #78: escape underscore (06master...06fix-subscript-in-quant_tables) 02https://git.io/vQEtI [23:53:56 CEST] <KGB> [13FFV1] 15dericed opened pull request #79: bump to wg doc version 00 (06master...06bump-to-wg-doc-00) 02https://git.io/vQEtM [23:57:16 CEST] <KGB> [13FFV1] 15michaelni 04deleted 06draft-ietf-cellar-03 at 143b6a14d: 02https://git.io/vQEtj [00:00:00 CEST] --- Mon Jul 3 2017

1 0

ffmpeg.log.20170702
by burek 03 Jul '17

03 Jul '17

[01:02:46 CEST] <DHE> marcoslater: there's a setsar and setdar filter to help during encoding time [01:41:20 CEST] <hiru> hello I have a issue with video filters and subtitles. I can import subtitles from a file only if I previously use cd moving in the video file and using the file name instead of the full path [01:41:24 CEST] <hiru> why is this happening? [01:41:41 CEST] <hiru> *moving in the video file path [01:50:27 CEST] <marcurling> hiru: which OS are you using? maybe try to double quote full path... [01:55:33 CEST] <nicolas17> yeah do you have spaces in your paths? [02:01:37 CEST] <hiru> using win10 [02:02:07 CEST] <hiru> the command is something like: -vf "scale=-1:360,subtitles='file_path'" [02:02:59 CEST] <hiru> the output command and the error in the output report the path correctly [02:03:10 CEST] <hiru> the error says "no such file or directory.." tho [02:04:03 CEST] <hiru> something I forgot to mention is that the file is shared via smb so the beginning part of the path is "\\device\path\to\file.mkv" [02:11:33 CEST] <nicolas17> the backslashes are probably interpreted in a special way [02:13:26 CEST] <hiru> Error reinitializing filters! Failed to inject frame into filter network: Invalid argument Error while processing the decoded data for stream #0:0 [02:13:30 CEST] <hiru> what does it mean [02:14:11 CEST] <hiru> I always use " and ' to enclose paths so there should be no problem with spaces or special characters [02:20:26 CEST] <hiru> I tried escaping the \ characters adding an additional \ before each one of them but it didn't help, same error [02:30:21 CEST] <marcurling> hiru Do you have to double quote your -vf params? I use smb pathes also (but only for input or output file) : seems to me I had some similar error when using filters [02:30:52 CEST] <hiru> I have the scale parameter too so I have to quote the whole -vf thing somehow [02:31:19 CEST] <marcurling> using filters under Win seems to 'corrupt' prarmeters/options parsing [02:32:03 CEST] <hiru> maybe I should open a issue on github about this [02:32:44 CEST] <marcurling> wouldn't -vf scale=-1:360 -vf subtitles="file_path" work? [02:33:46 CEST] <hiru> I think you can use only one -vf parameter. one of the two will be ignored in the end [02:36:49 CEST] <hiru> I'll try again with the same command on the host pc since there is raspbian installed [02:39:57 CEST] <marcurling> so try to put your -vf param in a var (and eventually in a .bat) [02:42:06 CEST] <marcurling> syntax should be: (I'm looking for it...) [02:45:46 CEST] <slalom> anybody here have nielsen encoding in their pipeline? [02:45:48 CEST] <slalom> in production [02:46:35 CEST] <nicolas17> no idea what it is [02:46:51 CEST] <slalom> nielsen watermarks [02:46:55 CEST] <slalom> e.g. for nielsen ratings [02:47:11 CEST] <slalom> if you're not in the US you probably won't know what that is [02:47:59 CEST] <slalom> their VOD encoder only supports ac3 audio properly and inside mpegts only.. and since we don't use any of those formats i have to convert the WAV to an mpegts container, encode and export it for our actual pipeline that makes all the versions [02:48:03 CEST] <slalom> super lame [02:48:39 CEST] <slalom> also its through a GUI, i was wondering if anyone has done it with command line [02:56:20 CEST] <marcurling> hiru I think your problem comes from the simple quotes for path (I just test it): it should be double ones [02:56:54 CEST] <marcurling> Let see if inverting the simple and double quotes in your given example works [04:34:17 CEST] <convert> that sucks that ffplay doesnt work with SDL-1 anymore. it immediately broke stuff I've been using for 10 years [04:34:42 CEST] <convert> the software renderer gives an black screen, and the opengl renderers cannot be maximised [04:35:37 CEST] <convert> i mean it is a good thing not to depend on a renderer [04:36:10 CEST] <convert> maybe i should try disabling the option in sdl [04:40:36 CEST] <convert> i reverted back to 2.9 anyway [04:44:03 CEST] <nicolas17> SDL1? what year is it? [04:49:31 CEST] <convert> nope "SDL: could not set video mode - exiting" [04:49:49 CEST] <convert> the year when things stop working because of "progress" [05:57:38 CEST] <convert> sdl1's on x11 was superior, dropping support is most likely the work of some agency infiltrate [05:58:13 CEST] <convert> luckily other players that use ffmpeg still support sdl1 [05:59:11 CEST] <convert> pity that the best player that shipped with ffmpeg itself fails completely, the diabolical hand in development [07:14:37 CEST] <convert> disabling AV_PIX_FMT_YUV420P in ffplay.c fixes the fullscreen issue [07:14:53 CEST] <convert> with the opengl renderer [07:15:20 CEST] <convert> i mean with the software renderer [07:15:39 CEST] <convert> disabling AV_PIX_FMT_YUV420P in ffplay.c makes the software renderer work again, including fullscreen [07:16:11 CEST] <convert> opengl renderer still has problems [07:37:13 CEST] <convert> with opengl renderer it needs to be SDL_WINDOW_FULLSCREEN not SDL_WINDOW_FULLSCREEN_DESKTOP [07:43:05 CEST] <relaxed> convert: file a bug report [09:54:46 CEST] <durandal_1707> i like when they tell its agency doings [11:04:02 CEST] <blaze06> anyone here who can help me with some questions?? [15:05:49 CEST] <JC_Yang> are there good ways to read/parse sps nal unit in h264 streams? from the public api, I can't figure out a way to read the desired parameter, that's no obvious side data types which represent fps in AVPacket, for example. [15:10:39 CEST] <BtbN> you get the packet timestamp [15:11:03 CEST] <BtbN> The h264 parsing API is private as far as I'm aware [15:11:17 CEST] <JC_Yang> avg_frame_rate in AVStream is 0, so have to read sps(maybe libavformat does not do it for me in raw streams) [15:11:51 CEST] <BtbN> pts [15:11:53 CEST] <JEEB> it does get some "possibly the frame rate" from raw AVC streams, though. if you ffprobe the file you should see it [15:11:54 CEST] <BtbN> not avg_frame_rate. [15:12:31 CEST] <BtbN> I also don't think a raw h264 stream has a framerate. You need a container for that. [15:12:37 CEST] <JC_Yang> I haven't analyzed the stream myself, but players like mpc-hc do recognize the fps correctly, so I think there should be a way to do it with libavformat [15:13:01 CEST] <JEEB> just check what ffprobe says :P [15:13:04 CEST] <JEEB> first [15:13:16 CEST] <JEEB> before saying things about libavformat [15:13:22 CEST] <BtbN> is it a raw h264 file, or some container? [15:13:31 CEST] <JC_Yang> raw [15:13:40 CEST] <BtbN> there's no framerate/timestamps then [15:13:46 CEST] <JEEB> you will get the "maximum time base" thing from the parameter sets, and IIRC lavf does parse that [15:13:50 CEST] <JEEB> you would see that in ffprobe [15:21:17 CEST] <JC_Yang> just confirmed, yes, ffprobe do recognize the fps. then how to do it in with its public api? I've tried, av_open_input() yet nothing usable from AVStream pts time_base and avg_frame_rate are both 0, and when I read each frame av_read_frame, all pts are set to 0 too. any clues? [15:21:58 CEST] <BtbN> ffprobe only uses public API [15:22:12 CEST] <BtbN> if it is able to do some guess on the framerate, look at what prints it and where it comes from [15:22:27 CEST] <JC_Yang> so I'm asking for suggestions here [15:22:30 CEST] <BtbN> But I wouldn't be surprised if it just displays the default fps guess, which happens to be right for this sample [15:23:26 CEST] <JC_Yang> Duration: N/A, bitrate: N/A [15:23:27 CEST] <JC_Yang> Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 1280x720, 25 fps, 25 tbr, 1200k tbn, 50 tbc [15:26:05 CEST] <BtbN> the fps there is from AVFormatContext::streams[x]::avg_frame_rate [15:26:20 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dump.c#L510 [15:27:22 CEST] <BtbN> And I think 25 is just the default if nothing is set? [15:27:55 CEST] <JEEB> yes, although I clearly remember it also can parse the maximum time base value if it's there. but yes, with 25 it's not easy to know which you're currently having there [15:28:08 CEST] <JEEB> without maybe some -v debug? not sure if the H.264 parser logs that stuff, though [15:29:02 CEST] <BtbN> I'm not aware of the h264 parser exporting and framerate/timestamp info [15:29:05 CEST] <BtbN> *any [15:29:16 CEST] <JEEB> well demuxer really [15:29:29 CEST] <JEEB> but yes it will lack a lot of the timestamp fields [15:29:34 CEST] <JEEB> as you demux stuff [15:29:58 CEST] <BtbN> I also don't think any of that information is there in a raw h264 stream? [15:30:24 CEST] <JEEB> there's a "maximum time base" thing which many things take as "frame rate" [15:30:43 CEST] <JEEB> yea, checked ffprobe with an old encode of mine that was still a raw bit stream [15:30:48 CEST] <JEEB> it gets the 24000/1001 [15:31:16 CEST] <JEEB> but I distinctly remember that lavf is bad at properly calculating time stamps for those things if you try to mux them with that rate into a container [15:31:25 CEST] <JEEB> which is why I usually use L-SMASH's muxer for that [15:31:43 CEST] <JEEB> but yes, the information is most definitely exported if it's there in the bit stream :P [16:00:28 CEST] <JC_Yang> just tried ffprobe with -v debug, it indicate that ffprobe does read sps(nal unit type 7 and 8) and pps, which is what I suspected, same as my initial question, how to do so in with the public api? [16:02:55 CEST] <JC_Yang> hmm... I may know the solution now. [16:03:36 CEST] <JC_Yang> avformat_find_stream_info() should come to rescue. let me try it [17:18:44 CEST] <JC_Yang> it is confirmed as the solution, thank u [17:19:17 CEST] <BtbN> What field does it set its framerate guess? [17:19:30 CEST] <BtbN> And I still don't think it will lead to valid timestamps unless you make some up yourself [17:24:53 CEST] <Filystyn> how to make video louder but keep video quality [17:25:12 CEST] <Filystyn> ffmpeg -i vid1 -vol 1280 vid2 this has killed my quality [17:34:21 CEST] <ChocolateArmpits> Filystyn, copy the video stream while encode only the audio ? [17:34:34 CEST] <ChocolateArmpits> use -vcodec copy [17:34:53 CEST] <BtbN> -c:v [17:34:56 CEST] <BtbN> vcodec is deprecated. [17:36:54 CEST] <Filystyn> nvm got it [19:15:31 CEST] <Ommand> stupid question for you guys, lets say I'm cutting a video with the following command [19:15:37 CEST] <Ommand> ffmpeg -ss 00:00:30 -i input.mp4 -t 45 output.mp4 [19:15:58 CEST] <Ommand> does that preserve all the previous encoder settings? it seems like it probably does [19:16:19 CEST] <atomnuker> use -c copy and it will, otherwise it reencodes [19:16:34 CEST] <Ommand> yea I need it to re-encode to remove black bits caused by key frames [19:20:16 CEST] <kerio> black bits? [19:20:26 CEST] <ChocolateArmpits> Ommand, outside of profile, level , pixel format used it won't preserve previous settings [19:20:42 CEST] <Ommand> kerio: a couple of seconds of video will be black until it hits the next key frame [19:20:49 CEST] <Ommand> ok ChocolateArmpits thanks [19:20:57 CEST] <Ommand> suppose my best bet is to just cut at key frames and deal with the rest later [19:21:06 CEST] <JEEB> ChocolateArmpits: uhh no. it will not [19:21:12 CEST] <JEEB> profile depends on what the encoder picks depending on your parameters [19:21:15 CEST] <JEEB> level's the same [19:21:39 CEST] <ChocolateArmpits> well in his case there are no custom parameters [19:21:42 CEST] <JEEB> literally the only thing that generally doesn't change unless you specify it is the pixel format, but you cannot promise that either (since ffmpeg.c will convert between them) [19:22:03 CEST] <JEEB> even with that, how the <bleep> do you know how his original videos were encoded [19:22:23 CEST] <ChocolateArmpits> well if the resolution is hd i wouldn't expect the level to be below 4 [19:22:41 CEST] <Ommand> well regardless, using that command I'll be reducing video quality for no reason [19:22:46 CEST] <kerio> WTF is level [19:22:46 CEST] <Ommand> no benefit, rather [19:22:50 CEST] <JEEB> making such promises that sound like some parameters get parsed from the input stream and the encoder gets configured to that (which, btw, doesn't make any sense) [19:22:58 CEST] <JEEB> is just bullcrap [19:23:28 CEST] <JEEB> kerio: in video formats usually profiles = features available/used by the stream, level = how much memory the decoder requires to decode the clip [19:23:34 CEST] <ChocolateArmpits> i never implied it honors previous settings [19:23:56 CEST] <ChocolateArmpits> just that he shouldn't expect other settings to actually match on output [19:23:59 CEST] <JEEB> > "outside of profile, level, pixel format used it won't preserve previous settings" [19:24:06 CEST] <Ommand> alright well, it sounds like you guys could really use a drink [19:24:11 CEST] <JEEB> that's a fucking literal quote of what you just mentioned [19:24:13 CEST] <Ommand> so I'm jsut gonna go, thanks for the help [19:24:15 CEST] <JEEB> np [19:24:52 CEST] <JEEB> I know I might sound anal but not giving people weird ideas is the best way of helping them with regards to the future [19:26:25 CEST] <kerio> oh so profiles and levels are things used by hardware accel [19:26:33 CEST] <kerio> meh [19:27:04 CEST] <JEEB> well they are ways of marking the streams regarding features/memory required [19:27:29 CEST] <JEEB> x264 sets the profile and level automagically to the minimum values based on the parameters given to it [19:27:46 CEST] <JEEB> (and if you set the profile/level to less than that, it will then constrain the encoder) [19:28:22 CEST] <JEEB> but basically yes, with SW decoders it generally doesn't matter other than profiles that enable usage of things like non-4:4:4 or non-8bit [19:28:27 CEST] <JEEB> *non-4:2:0 [19:28:46 CEST] <JEEB> because non-libavcodec software decoders often don't support non-4:2:0 or non-8bit [19:29:07 CEST] <JEEB> (mainconcept which is utilized by adobe's flash being one of the exceptions, suporting up to 10bit 4:2:2) [19:30:08 CEST] <kerio> why would you use that :^) [19:30:26 CEST] <JEEB> that's a whole separate discussion. [19:30:36 CEST] <kerio> jk I like QuickTime accelerated decoding [19:31:23 CEST] <JEEB> but yea, the profiles and levels mostly became a real thing with AVC, before that the landscape of decoders used to be much more chaotic [19:32:11 CEST] <JEEB> mpeg-4 part 2 being one of the major headaches of early/middle 2000s if you cared about plastic toys [20:11:41 CEST] <samgoody> Hi, [20:11:53 CEST] <samgoody> Am trying to use ffmpeg on Ubuntu 16.04 [20:15:48 CEST] <samgoody> apt-get claims it is up to date, but the version is ffmpeg version 2.8.11-0ubuntu0.16.04.1 Copyright (c) 2000-2017 the FFmpeg developers [20:17:37 CEST] <kerio> isn't 16.04 a LTS releas3 [20:17:40 CEST] <DHE> up-to-date is relative. long term supported distros prefer to backport bugfix patches. [20:17:41 CEST] <kerio> release [20:17:45 CEST] <kerio> it's like super old [20:18:22 CEST] <DHE> which is good for reliability of existing scripts and apps which depend on an ABI or parameter option specification, but bad for being truly "up to date" [22:11:07 CEST] <DeHeiligeGeest> could someone explain to me how HLS kinda works [22:11:17 CEST] <DeHeiligeGeest> specifically, you've got 1 big .mp4 [22:11:28 CEST] <DeHeiligeGeest> you split that up into parts, it creates a playlist file [22:11:34 CEST] <DeHeiligeGeest> (ffmpeg can do this) [22:11:47 CEST] <DeHeiligeGeest> but then it's only one quality right? how do you generate 'SD' or 'HD' [22:12:49 CEST] <c3r1c3-Win> You create the split files for each resolution. [22:13:13 CEST] <c3r1c3-Win> and in the m3u8 file you follow the Apple specs/guidelines for the new m3u8 file. [22:13:27 CEST] <c3r1c3-Win> +*for the expanded/multi-bitrate m3u8 file. [22:13:53 CEST] <DeHeiligeGeest> aye, cool [22:14:12 CEST] <DeHeiligeGeest> second question: should there only be one playlist? [22:14:39 CEST] <DeHeiligeGeest> in the scenerio that there are 2 versions [22:14:49 CEST] <DeHeiligeGeest> (one low quality, one high) [22:14:54 CEST] <JEEB> HLS has a definition of master and non-master playlists [22:14:59 CEST] <JEEB> master playlist is a "meta" playlist [22:15:04 CEST] <JEEB> which lists the alternatives [22:15:05 CEST] <DeHeiligeGeest> haha, ok kill me now [22:15:14 CEST] <JEEB> then the non-master ones actually contain the timeline [22:15:25 CEST] <JEEB> just read the spec if you want to know how it works :P [22:15:29 CEST] <DeHeiligeGeest> fair enough [22:15:34 CEST] <JEEB> https://tools.ietf.org/html/draft-pantos-http-live-streaming-23 [22:15:40 CEST] <JEEB> that IIRC was the most recent version [22:15:54 CEST] <DeHeiligeGeest> I was just hoping someone made one big bash file that ... does all :P (create the 2 streams, one playlist) [22:16:42 CEST] <DeHeiligeGeest> ok, ill read that RFC. If meanwhile you can think of any scripts that can do this somewhat easily, do let know [22:17:16 CEST] <JEEB> lavf can create the media playlists :P you can set the name for them [22:17:28 CEST] <JEEB> creating a master playlist for them shouldn't be too hard :P [22:17:57 CEST] <DeHeiligeGeest> I think I'm currently able to create a master playlist using: https://github.com/bentasker/HLS-Stream-Creator [22:18:19 CEST] <DeHeiligeGeest> (yes im cheating) [22:18:35 CEST] <DeHeiligeGeest> i just need 2 versions (SD/HD) [22:22:08 CEST] <DHE> I'm using HLS. Honestly my "master" playlist is just the same file for everything (since it's all relative paths). to the point that I'm hard linking them. :) [22:22:27 CEST] <JEEB> sounds good enough [22:22:33 CEST] <DHE> and ffmpeg can handle the rest [22:22:35 CEST] <JEEB> since you know what your file names [22:22:41 CEST] <JEEB> for the media playlists [22:24:21 CEST] <DeHeiligeGeest> apple should be banned from creating RFCs or any kind of protocol/interface [22:25:10 CEST] <DHE> I don't think it's all THAT bad. I'd rather HLS than having to parse the XML of DASH most days [22:25:24 CEST] <DeHeiligeGeest> the fact its over http is cool i guess [22:25:42 CEST] <DeHeiligeGeest> but right now im trying to understand how to generate those master/meta playlist or whatever [22:25:44 CEST] <DeHeiligeGeest> and i dont get it [22:25:59 CEST] <JEEB> go look at the examples at the end of the spec :P [22:26:01 CEST] <DHE> there's a whole section of examples in the spec [22:26:03 CEST] <JEEB> like seriously [22:26:03 CEST] <DHE> yes, that [22:26:40 CEST] <furq> 8.4 should be all you need [22:26:48 CEST] <furq> it's not exactly complicated [22:27:10 CEST] <DeHeiligeGeest> take 8.4 as an example yes [22:27:31 CEST] <DeHeiligeGeest> oh [22:28:01 CEST] <DHE> 8.5 is an example with relative paths. which is where I get away with using 1 master playlist consistently [22:28:45 CEST] <DeHeiligeGeest> i dont see why you would want to hardcore the domain + scheme in there [22:28:47 CEST] <DeHeiligeGeest> @ 8.4 [22:29:22 CEST] <DeHeiligeGeest> s/hardcore/hardcode [22:29:43 CEST] <DHE> depends. many of the decisions in the draft imply the use of a content delivery network (eg: Akamai). after all, it's just HTTP [22:30:14 CEST] <DHE> so you might be offloading content delivery to another company [22:30:27 CEST] <DeHeiligeGeest> fair nuff [22:31:52 CEST] <DHE> and of course its' an example. they want to cover all sorts of concepts there [22:33:16 CEST] <DeHeiligeGeest> HA. that bash thing I linked earlier can already do exactly what I want it seems [22:33:35 CEST] <DeHeiligeGeest> that means I can stay a script kiddie and avoid having to read the RFC [22:33:44 CEST] <DeHeiligeGeest> mua-ha-ha [22:33:58 CEST] <JEEB> well not like the master playlists are dark magic [22:34:03 CEST] <DeHeiligeGeest> true [22:34:08 CEST] <DeHeiligeGeest> well thanks for the explanation anyway [22:35:41 CEST] <DeHeiligeGeest> yep, it worked :) cool script, ill link it again: https://github.com/bentasker/HLS-Stream-Creator [00:00:00 CEST] --- Mon Jul 3 2017

1 0

ffmpeg-devel.log.20170701
by burek 02 Jul '17

02 Jul '17

[01:50:08 CEST] <cone-525> ffmpeg 03James Almer 07master:fb7b477a91fe: checkasm: fix size of input buffer in test_hybrid_analysis [03:46:58 CEST] <durandal_1707> als gets samples backwards, what a waste [03:52:13 CEST] <cone-525> ffmpeg 03James Almer 07master:0eb783eb0613: checkasm: randomize the full input buffer in test_hybrid_analysis [07:37:21 CEST] <LongChair> jkqxz: I have been looking at the rendering side for the drmprime stuff, and something isn't handy, that is to browse the planes and group them into renderable layers [07:38:46 CEST] <LongChair> you basically have to group the with formats and that makes some overhead in the code, both drm & dmabuf will use format and pitches[] offsets[] in their primitives [07:39:41 CEST] <LongChair> so i was wondering if we could swap the AVDRMPlaneDescriptor with an AVDRMLayerDescriptor [07:39:58 CEST] <LongChair> which would be something like this : https://gist.github.com/LongChair/b97cf74cf66d72c4fdb518bee12663df [07:40:20 CEST] <LongChair> on nv12 you would then have one layer with DRM_FORMAT_NV12 [07:40:54 CEST] <LongChair> and for vaapi you would end up with two layers one for Y, and one for UV [11:11:10 CEST] <nevcairiel> can someone delete that page? the guy keeps spamming that stupid thing [11:15:19 CEST] <thebombzen> wouldn't it make more sense to revoke editing privileges from the user, rather than delete the page? can you even ban a user from the trak wiki? [11:15:20 CEST] <nevcairiel> he just doesnt get the clue [11:15:33 CEST] <nevcairiel> someone probably can [11:36:54 CEST] <durandal_1707> michaelni: see above [11:43:35 CEST] <wm4> yeah that warrants a permanent ban [11:48:45 CEST] <wm4> mateo`: any chance you can port mediacodec to hwframes? [12:06:33 CEST] <wm4> ah, backporting that hevc fix is very annoying, so I'd rather not [12:06:52 CEST] <wm4> so plan B... when will ffmpeg 3.4 be released? [12:07:49 CEST] <durandal_1707> wm4: when CE says [12:09:14 CEST] <durandal_1707> michaelni: you seems very busy lately. do you mind sharing rest of your powers with me? [12:10:48 CEST] <wm4> LongChair: so there are going to be AV_NUM_DATA_POINTERS AVDRMLayerDescriptor elements? [12:50:12 CEST] <michaelni> nevcairiel, we can remove a user account from trac but this case doesnt look like standard spam. rather it looks like a difference in oppinion about listing and how to list non standard ways to build with msvc, though maybe i miss something [12:50:36 CEST] <michaelni> we should talk with that user [12:50:46 CEST] <michaelni> unless that has already happened ? [12:51:45 CEST] <michaelni> he added a email address to the msvc2 page IIUC so talking with him seems trivial [12:52:00 CEST] <wm4> it's advertisment and inciting an edit war [12:52:31 CEST] <wm4> so it's not our problem to talk with him nicely to stop him from vandalizing the wiki [12:56:32 CEST] <michaelni> we have wiki entries about xvid, divx, windows media player, eclipse ide, "Lei Xiaohua's Simplest FFmpeg Demos" and i guess many others that link or contain someones work related and less related to ffmpeg, this doesnt seem much different [12:57:07 CEST] <nevcairiel> this links to a repository of a fork of ffmpeg claiming it as a "compilation guide", its plenty different [12:57:32 CEST] <iive> michaelni: to be it does look like spam [12:57:56 CEST] <mateo`> wm4: sure, i'll look into next week [12:58:16 CEST] <iive> michaelni: 1. he is recommending entirely different project. 2. The name of that project is trademark violation of the vlc [12:58:56 CEST] <iive> michaelni: I don't know about permanent ban, but this page should be removed and account suspended, until things are cleared up. [13:00:45 CEST] <michaelni> ill, take the nice approuch and write him a mail first so he gets a change to defend his point. if he doesnt reply ill remove the page and the account unless someone else does before [13:01:17 CEST] <michaelni> anyone i should put in CC ? should i put ffmpeg-devel in CC ? [13:03:07 CEST] <iive> he is not likely to be subscribed, so his replies might end in moderators queue. [13:06:33 CEST] <iive> btw, VLC does provide windows binaries. Don't they already support msvc ? [13:07:37 CEST] <wm4> maybe j-b is interested in suing him [13:19:28 CEST] <j-b> sue whom? [13:19:37 CEST] <j-b> (yes, I highlight on sue) [13:21:25 CEST] <nevcairiel> the guy with his "vlc2" fork on sourceforge [13:21:58 CEST] <j-b> is it the stupid guy with MSVC? [13:22:17 CEST] <ubitux> likely, with a yahoo mail [13:22:34 CEST] <ubitux> TarmoPikaro [13:24:25 CEST] <j-b> it's not like we already gave hm the git to the MSVC version of vlc [13:28:05 CEST] <michaelni> mail sent [13:28:39 CEST] <wm4> oh great giving this guy my email [13:28:44 CEST] <wm4> how fucked up is this whole thing [13:30:51 CEST] <michaelni> your email is public in git, so is this irc channel and log of it [13:31:30 CEST] <michaelni> noone gave any email, you are just CC-ed together with others as you asked for the page to be removed [13:32:46 CEST] <wm4> let me rephrase: put me into a personal conversation with him [13:33:44 CEST] <michaelni> iam sorry about that, i asked about CC before sending the mail, you didnt say you dont want to be cced [13:40:11 CEST] <iive> even gmail thinks this is spam. This is where i found the mail :D [14:22:20 CEST] <sfan5> the AVX asm for fft seems to have a bug [14:22:34 CEST] <sfan5> i get this crash http://sprunge.us/ZJdH passing --disable-avx eliminates it [14:22:43 CEST] <sfan5> application in question is https://github.com/alexkay/spek [14:23:44 CEST] <sfan5> should I open a bug on the tracker or am I missing something here? [14:26:34 CEST] <atomnuker> sfan5: you do make sure the buffer is aligned, right? [14:27:41 CEST] <atomnuker> (you should be using the showspectrumpic filter, its much better than spek) [14:30:46 CEST] <sfan5> dunno about the buffer, I should investiage the spek code further [14:42:28 CEST] <RiCON> atomnuker: dunno, spek seems nicer [14:42:57 CEST] <RiCON> and using size= on showspectrumpic apparently truncates the Hz scale instead actually scaling it [14:44:40 CEST] <sfan5> spek relies on std::vector aligning it's data good enough for ffmpeg :/ [14:47:32 CEST] <RiCON> https://i.fsbn.eu/0_61.260836.png vs with size=hd1080 https://i.fsbn.eu/0_1.230496.png [14:47:37 CEST] <atomnuker> RiCON: mpv --pause --lavfi-complex="[aid1] showspectrumpic=size=2048x1024:color=rainbow:saturation=2:scale=log:win_func=bharris [vo]" [14:47:53 CEST] <atomnuker> this aliased to something shorter works fine for me [14:49:00 CEST] <RiCON> doesn't that also truncate it vertically? [14:49:27 CEST] <durandal_170> no if its power of 2 [14:49:56 CEST] <RiCON> oh, that's not documented [14:52:35 CEST] <sfan5> yup the align was the problem [15:39:25 CEST] <JEEB> sfan5: yea that happens often. f.ex. if you take the lavfi input and try to feed it to something else... [15:39:39 CEST] <JEEB> certain filters after the lavfi input thing then require more alignment and bang! [16:09:09 CEST] Action: Compn wonders why his emails were bouncing hmmm [16:35:47 CEST] <durandal_170> JEEB: are you on drugs? sfan5 uses spek not lavfi [16:38:22 CEST] <sfan5> ¯\_(Ä)_/¯ [16:41:14 CEST] <BtbN> with the latest BIOS Updates, I'm finally able to actually boot my system with the advertised RAM speed [16:41:24 CEST] <BtbN> It's highly unstable then, but hey, before it didn't even POST [16:41:45 CEST] <BtbN> Dropping one nodge on the RAM speed makes it stable as far as I can see, which also was non-booting before [16:41:59 CEST] <BtbN> Only took like half a year to make Ryzen stable [16:42:45 CEST] <DHE> what mobo? I'm in a similar boat [17:04:24 CEST] <cone-279> ffmpeg 03foo86 07master:f8b1a70412b5: avcodec/s302m: fix AVOption flags [17:06:57 CEST] <iive> BtbN: are you with AMD cpu? [17:07:12 CEST] <JEEB> durandal_170: well it sounded like filtering and since IIRC all filtering in FFmpeg goes through lavfi... [17:07:12 CEST] <BtbN> Ryzen is from AMD, yes [17:07:20 CEST] <JEEB> of course sure, I could be on drugs [17:07:31 CEST] <JEEB> and was replying to what I was seeing on the backlog :P [17:07:47 CEST] <iive> BtbN: may I ask you to run some benchmarks? patch is on the maillist. [17:08:02 CEST] <BtbN> Just the normal checkasm ones? [17:08:18 CEST] <iive> start/stop timers [17:13:25 CEST] <DHE> BtbN: what motherboard do you have? [17:13:30 CEST] <BtbN> C6H [17:13:44 CEST] <DHE> okay thanks [17:16:18 CEST] <BtbN> iive, I don't think I see the patch you mean, which one is it? [17:16:40 CEST] <iive> "v3 Opus Pyramid Vector Quantization Search in x86 SIMD asm" [17:17:58 CEST] <iive> the timers are in the patch already. just run opus encoder, with something longer (1 hour) [17:18:49 CEST] <BtbN> the native opus encoder I assume? Cause I'm not sure I have the stuff needed for libopus [17:19:04 CEST] <iive> yes, native one. [17:19:32 CEST] <atomnuker> ffmpeg -f lavfi -i anoisesrc=r=48000 -t 01:00:00 -strict -2 -f opus -b:a 96k -f null - [17:19:43 CEST] <atomnuker> if you don't have an hour long file anywhere [17:20:38 CEST] <iive> -f opus? not -c:a ? [17:20:59 CEST] <DHE> since you have two -f parameters I think it should be -c:a [17:21:11 CEST] <atomnuker> iive: typo [18:11:33 CEST] <BtbN> iive, would you prefer an msvc or gcc 6.3.0 build? [18:12:25 CEST] <iive> well.. whatever is easier for you. it's assembly so it should not matter. [18:12:40 CEST] <BtbN> it's both the same [18:13:22 CEST] <iive> let it me msvc, since that is the least tested. There might be some problem. [18:13:30 CEST] <iive> btw, apply just the first patch. [18:15:55 CEST] <BtbN> iive, so just this: https://patchwork.ffmpeg.org/patch/4170/ [18:16:27 CEST] <iive> no, that's the second one. [18:16:51 CEST] <BtbN> hm, other ones didn't make it to patchwork it seems [18:17:40 CEST] <iive> yeh... ops [18:17:54 CEST] <BtbN> https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=276 is it one of those? [18:17:56 CEST] <iive> i guess it assumes one patch per mail. [18:18:29 CEST] <iive> these are older. [18:18:42 CEST] <iive> v3 leads to same patch you pasted above. [18:19:59 CEST] <BtbN> I think I found the right patch now [18:21:30 CEST] <BtbN> visual studio wants to update first [18:22:06 CEST] <iive> git update, or make distclean , update? [18:23:46 CEST] <BtbN> Update Itself. i.e. download 1.2GB of stuff [18:24:15 CEST] <BtbN> And there are supposedly compiler bugfixes in there. So I want to do that first [18:25:05 CEST] <iive> go for it [18:28:19 CEST] <atomnuker> iive: post results of the distortion for approx 2 [18:41:56 CEST] <iive> here on in mail? [18:44:57 CEST] <atomnuker> here [18:46:01 CEST] <iive> time=02:05:16.60 runs = 16777216 Distortion1 = 8516666.366404 Distortion2 = 8516668.727460 [18:48:18 CEST] <iive> that sample is from youtube, aac (lc) audio. [18:50:56 CEST] <atomnuker> wow, that's acceptable [18:58:01 CEST] <BtbN> iive, seems to be working. Set it to 10 hours of noise, will post results soon [18:58:23 CEST] <iive> BtbN: i kind of do prefer to test with real sample. [18:58:43 CEST] <BtbN> I don't have any sample of acceptable size. [18:58:47 CEST] <iive> and I'd like more tests. [18:58:52 CEST] <iive> no movies? [18:59:13 CEST] <BtbN> Could give it a game of thrones episode [18:59:39 CEST] <iive> that's fine. [19:01:19 CEST] <BtbN> iive, https://bpaste.net/show/7a1b50df389e [19:02:02 CEST] <iive> BtbN: could you run it a few times. at least 3. [19:02:51 CEST] <iive> also, with few different options. e.g. "-cpuflags 0 " to bench the C version. [19:06:18 CEST] <BtbN> https://bpaste.net/show/15451804a04d [19:10:16 CEST] <iive> WoW, the C version is 61909 cycles.... is that with optimizations enabled? [19:12:05 CEST] <iive> would you do a few more runs, with -cpuflags -avx2 , then -cpuflags -avx-avx2 and -cpuflags -sse4.2-avx-avx2 [19:13:02 CEST] <BtbN> I can do that later, busy for a couple hours now [19:13:12 CEST] <iive> no problem :D [20:11:03 CEST] <KGB> [13FFV1] 15michaelni closed pull request #68: Make Quantization descriptions more coherent (06master...06QuantizationTables) 02https://git.io/vH23k [20:21:24 CEST] <LongChair> wm4 : yes correct [20:23:14 CEST] <LongChair> is that an issue ? [20:24:09 CEST] <wm4> LongChair: well at least it should be limited to 4 then [20:24:15 CEST] <wm4> instead of NUM_POINTERS [20:26:44 CEST] <LongChair> yeah i think 4 layers with each 4 offsets / pitches would cover pretty much anything [20:27:50 CEST] <LongChair> but would be easier imho to use that way from rendrring side [20:28:05 CEST] <LongChair> rendering* [20:31:19 CEST] <LongChair> wm4 : do you think that could be ok ? [20:32:29 CEST] <wm4> yeah, can you make a complete header? [20:32:41 CEST] <wm4> or maybe you already did [20:33:23 CEST] <LongChair> not a full one yet, but i can do one in the morning ( not home yet) [20:36:30 CEST] <wm4> jkqxz: also ^ [21:39:28 CEST] <durandal_170> atomnuker: are you near finishing something? [21:40:39 CEST] <atomnuker> the opus encoder psychoacoustic system [21:41:13 CEST] <atomnuker> after 3 months of not figuring out how to continue I figured it out a few days ago [21:42:44 CEST] <iive> this sounds like a good news :D [21:43:36 CEST] <cone-279> ffmpeg 03Kostya Shishkov 07master:06a66e7d9496: avcodec/imc: cast float to int prior to comparing with int variable [21:49:20 CEST] <durandal_170> atomnuker: isnt that just theory, need to be implemented first [21:51:01 CEST] <atomnuker> no, its research [21:51:24 CEST] <atomnuker> you can't figure out if its going to work unless you write it at the same time and test it, one unit at a time [22:09:51 CEST] <Compn> j-b : does videolan get on sorbs blocklists [22:10:00 CEST] <Compn> ffmpeg got stuck on there again [22:10:22 CEST] <Compn> i remember it was a pain in the ass to get off last time [22:19:28 CEST] <Compn> actually... [22:19:33 CEST] <Compn> our mail server isnt listed ? [22:21:09 CEST] <Compn> was it listed for a day and then not ? [22:21:13 CEST] <Compn> then delisted i mean [22:23:15 CEST] <Tarmik> Hi! [22:23:20 CEST] <Compn> heello [22:23:48 CEST] <Tarmik> I'm Tarmo Pikaro, the one who tried to modify your ffmpeg wiki pages [22:24:05 CEST] <Compn> the wiki page on http://trac.ffmpeg.org ? [22:24:14 CEST] <Tarmik> yes. [22:24:47 CEST] <Tarmik> But it looks like Michael Niedermayer reverted my changes. [22:25:18 CEST] <JEEB> post the actual page and the changes you did and you might get some related replies [22:25:29 CEST] <Compn> what page were you modifying ? [22:25:38 CEST] <Tarmik> https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC2?version=4 [22:25:50 CEST] <Tarmik> initially it looked like this. [22:25:52 CEST] <nevcairiel> as michael has already pointed out in the email, you are not posting a compilation guide at all [22:26:03 CEST] <iive> the spammer [22:26:04 CEST] <nevcairiel> so dont try to hide it in that area [22:26:10 CEST] <iive> who advertises his own vlc2 [22:26:30 CEST] <Tarmik> ffmpeg is actualy a project in vlc solution [22:26:40 CEST] <nevcairiel> we have a specific section that links to othjer projects using ffmpeg [22:26:51 CEST] <Compn> j-b : you should see Tarmik's "vlc2" project on sourceforge > https://sourceforge.net/projects/vlc2/ [22:26:54 CEST] <Tarmik> ffmpeg also has it's own solution, but I suspect that it's not fully functional in my svn repository. [22:28:40 CEST] <durandal_170> i do not communicate with spammers [22:28:46 CEST] <Compn> Tarmik : the compilation guide is for ffmpeg compilation, not "vlc2" compilation guides. [22:28:51 CEST] <Compn> Tarmik : so we will not accept this [22:29:39 CEST] <Tarmik> Ok, let me check if ffmpeg solution is still working / can be brought up to date... [22:31:30 CEST] <nevcairiel> Anything t hat relies on a third-party fork of ffmpeg is not a "compilation guide" [22:31:43 CEST] <Compn> Tarmik : it doesnt matter if your project compiles ffmpeg. we're only using our own guide [22:32:11 CEST] <nevcairiel> People looking to build ffmpeg don't want to build some fork of vlc that just happens to include ffmpeg [22:32:14 CEST] <wm4> Tarmik: moreover, your approach is stupid, and I don't want the ffmpeg wiki to spread stupid ideas [22:33:44 CEST] <iive> Tarmik: You do understand, that the page where you plugged your project, is about compiling FFmpeg current sources. Your project is not supposed to keep minute-accurate version of ffmpeg, right? [22:33:50 CEST] <Tarmik> What you mean by stupid ? :) [22:34:31 CEST] <durandal_170> ignorant [22:34:57 CEST] <iive> durandal_170: assume that he might not be aware why the thing he has done is bad. [22:35:42 CEST] <Tarmik> You're right in that sense - but this is one approach of porting (using syncProj tool) - maybe some will find it useful to make similar port. [22:35:44 CEST] <durandal_170> guilty until proven innocent [22:35:54 CEST] <wm4> Tarmik: from what I understand you're replacing the projects' native build systems with MSVC [22:36:07 CEST] <nevcairiel> one hing might've been that his page was deleted the last time he tried to add it a couple weeks ago [22:36:13 CEST] <nevcairiel> hint* [22:36:31 CEST] <Compn> (this is pretty good troll, to catch so many developers) [22:38:03 CEST] <Tarmik> I'm working on vlc / and then will continue to iptv, so not so intrested in bringing ffmpeg Visual studio projects / solutions up to date, but I think my approach might be useful to someone else. I've could add to wiki page that this svn contains old version of ffmpeg and not officially supported by ffmpeg development team. [22:38:33 CEST] <rcombs> hmm, I don't have access to the delete-page feature in trac [22:38:50 CEST] <iive> Tarmik: there are vlc developers here too. [22:38:52 CEST] <nevcairiel> Having something entirely out of date on there is even worse then something stupid, so you might as well not [22:39:13 CEST] <wm4> Tarmik: there are instructions for building ffmpeg with msvc [22:39:22 CEST] <nevcairiel> the wiki isnt a collection of "maybe useful" hints, its supposed to contain actually useful and uptodate information [22:39:31 CEST] <iive> Tarmik: however from what i've seen, I have no idea what methods you have used or refer to. [22:39:49 CEST] <nevcairiel> people that need hints can hopefully use google :) [22:40:06 CEST] <iive> Tarmik: you are not describing tools and a process that could compile ffmpeg sources. [22:42:08 CEST] <Tarmik> never mind. instructions on wiki page is not ideal target anyway. Can survive without it. :-) [22:42:33 CEST] <iive> from my point of view [22:42:52 CEST] <Tarmik> I've made ffmpeg to compile under x86 and arm, and I must admit it's extremly complex to compile. [22:42:52 CEST] <iive> you are just trying to link your small personal project from a more popular one [22:43:37 CEST] <Tarmik> I'm going into iptv direction, and vlc and ffmpeg are just a stones on the way. [22:43:41 CEST] <wm4> Tarmik: if you do it your way, yes [22:43:43 CEST] <iive> well, we'll be glad to read how you've done it, step by step. [22:44:09 CEST] <iive> and we'd probably accept some pathes, if changes are needed. [22:44:19 CEST] <Tarmik> ok, let me describe a little bit, may be you can give me some hints how to handle it better ?! [22:44:51 CEST] <durandal_170> 0. stop spamming trac [22:45:19 CEST] <Tarmik> 0. Ok, will not touch it anymore. :-) [22:46:16 CEST] <Tarmik> First of all - I want to get rid of configure as a separate tool. So currently I have launched two configure commands and created two .h files and included them as such into project - FYI: [22:46:18 CEST] <Tarmik> https://sourceforge.net/p/vlc2/code/HEAD/tree/extlibs/ffmpeg/config.h [22:46:23 CEST] <Tarmik> https://sourceforge.net/p/vlc2/code/HEAD/tree/extlibs/ffmpeg/config_android… [22:46:51 CEST] <Tarmik> https://sourceforge.net/p/vlc2/code/HEAD/tree/extlibs/ffmpeg/config_windows… [22:47:06 CEST] <rcombs> Tarmik: yeah, no [22:47:10 CEST] <rcombs> configure is going to be a thing [22:47:22 CEST] <rcombs> if you can't handle a configuration step in your build process then something is wrong [22:47:32 CEST] <Tarmik> Currently x86 (Windows native) and ARM (Android) are those two platforms which I'm compiling for. [22:47:42 CEST] <rcombs> (not even your build process, your _dependency_'s build process) [22:48:01 CEST] <Compn> Tarmik : good luck! [22:48:03 CEST] <rcombs> on another note, how does x262 compare with lavc's mpeg2enc these days? [22:48:17 CEST] <nevcairiel> man i havent heard of x262 for ages [22:48:21 CEST] <nevcairiel> is that still under development? [22:48:26 CEST] <rcombs> shipping a config.h is not supported by anything [22:49:03 CEST] <Tarmik> My idea is to start from major OS's / major compilers / major debuggers, and me completely ignorant to smaller processors, environments, etc... [22:49:48 CEST] <JEEB> rcombs: I don't think x262 changed at all during the last N years? [22:49:53 CEST] <Tarmik> And I think configure is very clumsy system, and not fully error tolerant. [22:50:28 CEST] <rcombs> Tarmik: well you haven't proposed a useful replacement for it [22:50:35 CEST] <rcombs> and neither has anybody else [22:50:46 CEST] <JEEB> Tarmik: just look at how nevcairiel handles FFmpeg compilation within his MSVC project... [22:50:54 CEST] <rcombs> (there are other options but they're all more work to switch to than it'd be worth for this project) [22:51:00 CEST] <JEEB> or mpc-hc [22:51:12 CEST] <Tarmik> Most complex was to configure assembly compilation - https://sourceforge.net/p/vlc2/code/HEAD/tree/helpers.cs [22:51:18 CEST] <rcombs> (and provide very little benefit over the existing functional build system) [22:51:19 CEST] <JEEB> I mean, building FFmpeg from MSVS is a solved problem :| [22:51:22 CEST] <Tarmik> See ffmpeg_asmFiles. [22:51:50 CEST] <rcombs> ...wow that's a mess [22:52:01 CEST] <rcombs> protip: don't attempt to bring random libraries into your favorite IDE [22:52:20 CEST] <rcombs> that's what's known in the biz as a "bad idea" [22:52:36 CEST] <Tarmik> syncProj is my own tool, visual studio project generator. ( https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj… ) [22:52:39 CEST] <rcombs> unless you're using your IDE's "call external build system" feature (no idea if MSVC has this) [22:52:47 CEST] <JEEB> it has, it's called "script it" [22:52:49 CEST] <Tarmik> C# script is used for generating projects. [22:52:53 CEST] <JEEB> as in, call the shell [22:53:05 CEST] <JEEB> then sanity check that you got return code zero with some other stuff [22:53:28 CEST] <rcombs> but any sane ffmpeg build is going to involve configure and make [22:54:39 CEST] <nevcairiel> rcombs: yeah you can setup all sorts of manual build steps in msvc, it would be no problem to invoke configure and make [22:54:43 CEST] <rcombs> JEEB: re: x262, that doesn't answer which is better [22:55:08 CEST] <JEEB> you said "these days" and I noted that it hasn't changed compared to the "these days" a few years back [22:55:14 CEST] <JEEB> and IIRC for interlacism it was worse off at least? [22:55:25 CEST] <Tarmik> I have done portable code previously, and I know the hell of configure, make, gdb, ddd, and other tools - I'm not sure if Visual studio handles Android debugging better, but I intend to find out. [22:55:50 CEST] <JEEB> lavc encoding is thus likely better but configuring it is most likely a biatch [22:55:53 CEST] <rcombs> I'm not entirely sure _why_ people want to build ffmpeg with MSVC (as much as people try to avoid it, gcc-style inline asm is a thing) [22:55:54 CEST] <Tarmik> Currently I'm stuck on rather funny problems - but they relate to device side: https://social.msdn.microsoft.com/Forums/en-US/e0ac0261-f3da-4067-aba1-3117… [22:56:10 CEST] <rcombs> why the hell would you want to build for _android_ in MSVC [22:56:30 CEST] <wm4> <Tarmik> Most complex was to configure assembly compilation - https://sourceforge.net/p/vlc2/code/HEAD/tree/helpers.cs [22:56:35 CEST] <wm4> that's some fucking comedy [22:56:44 CEST] <wm4> are you sure you're not a troll [22:56:45 CEST] <nevcairiel> rcombs: because msvc is a neat GUI and actually has support for NDK builds? :) [22:56:45 CEST] <Tarmik> Just trying if Visual studio will work for my own needs currently. :) [22:56:59 CEST] <Tarmik> I've heard other people are using QT Creator for debugging. [22:57:09 CEST] <Tarmik> but it's not better than Visual studio. [22:57:12 CEST] <rcombs> nevcairiel: oh, so it's ultimately just shelling out to gcc or clang? [22:57:31 CEST] <durandal_170> wm4: you should use eclipse [22:57:34 CEST] <JEEB> yea, I think 2017 at least has support for "lunix development" [22:57:40 CEST] <JEEB> or "android development" [22:57:44 CEST] <rcombs> I don't care what GUI you use, but trying to get Android to interact with MS's compiler sounds insane [22:57:48 CEST] <Compn> rcombs : yep, per wm4's link : [22:57:49 CEST] <Compn> Message = "Assembling " + file, [22:57:49 CEST] <Compn> Command = @"nasm.exe -f win32 -d OBJ_FORMAT_win32 -i ia32/ " + file + " -o " + objFile, [22:58:09 CEST] <nevcairiel> rcombs: probably, whatever ndk needs. it can also do much more arcane things, like invoke gcc over a ssh shell, and then debug that binary with gdb over the ssh shell ... and offer you the full GUI debugging experience in the process [22:58:32 CEST] <JEEB> yup [22:58:59 CEST] <nevcairiel> they've really made it work for far more then their own compiler [22:59:09 CEST] <rcombs> alright, that sounds fine, still insane to cram third-party libs into its build system though [23:01:05 CEST] <BBB> doesnt libvpx have an opensource tool for creating visual studion solution (.sln) files from Makefiles? [23:01:20 CEST] <BBB> (i.e. one that does not rely on c# or strange things) [23:01:59 CEST] <nevcairiel> it wouldnt be that hard, still have to run configure first tho [23:02:03 CEST] <wm4> clearly ffmpeg should switch to cmake so your favorite build files can be generated [23:02:06 CEST] <Tarmik> cmake, premake5. [23:02:09 CEST] <BBB> msys isnt that bad to install [23:02:16 CEST] <Tarmik> both based on C++. [23:02:20 CEST] <wm4> (and that was sarcasm of course) [23:02:33 CEST] <BBB> wm4: understood ;) [23:02:58 CEST] <Tarmik> https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj… [23:03:33 CEST] <BBB> Tarmik: I think for most of us, what we just witnessed here is something like woa. I dont think you understand what problem our build files are trying to solve and why they are the way they are, and so proposing alternatives (or documenting alternatives, for heavens sake) is not appropriate at this point [23:04:10 CEST] <BBB> Tarmik: in order to document or suggest improvements, you need to fully (totally, 100%, without exception) understand the processes that we have, and (for improving specifically) probably have a pretty broad overview of where the rest of the ecosystem sits also [23:04:13 CEST] <wm4> BBB: it's basically a culture clash, between sane people and IDE people [23:04:27 CEST] <BBB> I use IDEs [23:04:45 CEST] <BBB> but people with IDE and CLI experience know how to integrate one in the other [23:04:46 CEST] <wm4> ok, IDE-only-people [23:04:49 CEST] <BBB> right [23:05:04 CEST] <BBB> thats what I meant: hes IDE-only, he needs to elevate to IDE+CLI before he can understand any of our build stuff [23:05:19 CEST] <BBB> and only after that can you start suggesting improvements or documenting it [23:05:58 CEST] <Tarmik> I would say it's impossible for me to fully understand what is happening in ffmpeg compilation process, I have tried to guess some of compilation options, and it's not good. [23:06:14 CEST] <BBB> how do you know its not good if you dont understand it? [23:06:18 CEST] <Tarmik> it's relatively heavy project set. [23:08:44 CEST] <Tarmik> I understand probably basics of how configure works, but full understanding is probably something that I'm missing at the moment. :) [23:08:49 CEST] <wm4> how can you not understand this, but go through all this shit to reproduce the build system on a bunch of platforms? [23:09:33 CEST] <rcombs> by stripping out all the important parts and just finding the list of files to throw at a compiler and linker [23:09:43 CEST] <rcombs> well, I suppose those are also important [23:10:53 CEST] <Tarmik> you're right - for example in Android I have disabled quite many source codes enabled in windows. But this is something I see as interation - I'll fix into proper condition android platform later on. [23:11:34 CEST] <Tarmik> #define's which resides in config*.h files are extreemtly expensive to configure, debug and fix into right direction. [23:11:52 CEST] <wm4> Tarmik: how would you do it [23:11:58 CEST] <Tarmik> I would prefer to delete config*.h files completely, but it will take time to make it happen. [23:12:29 CEST] <Tarmik> make all defines as close to places which uses them. [23:12:29 CEST] <BtbN> iive, the C version is just MSVC default settings. I guess it optimizes, but for generic amd64 [23:12:59 CEST] <Tarmik> expensive = time consuming. [23:13:34 CEST] <wm4> Tarmik: you can't do that [23:13:39 CEST] <rcombs> Tarmik: &and how would you define them, then? [23:13:49 CEST] <iive> BtbN: usually the first run is the slowest, and then each run it gets faster and faster. here the first run is 40k cycles and it ends up on avarage of 60k cycles. That's.... wrong. [23:13:50 CEST] <wm4> whatever you'd come up with it would be incorrect, broken, and not work somewhere [23:14:12 CEST] <Tarmik> I first tried to analyze bit deeper what each define does, but then I've noticed that there are huge list of them. [23:14:47 CEST] <Tarmik> For example "SWS_MAX_FILTER_SIZE" define - instead of making it as define it should be implemented as run-time configurable parameter. [23:15:11 CEST] <Tarmik> and same rule could be applied to most of define's out there. [23:15:15 CEST] <wm4> that's one of the only cases where I might agree [23:15:19 CEST] <wm4> but, no [23:15:40 CEST] <rcombs> uh [23:15:44 CEST] <rcombs> it's used in a bunch of inline asm [23:16:13 CEST] <iive> BtbN: i mean, with more runs it gets better branch prediction and keeps important things in cache. [23:16:15 CEST] <wm4> but inline asm is Wrong [23:16:29 CEST] <rcombs> well then it'd be used in a bunch of nasm [23:16:34 CEST] <durandal_170> sws is mostly wrong [23:16:35 CEST] <wm4> and libswscale things rarely have a good justification [23:17:24 CEST] <wm4> and making it a configure parameter is ridiculous anyway [23:17:40 CEST] <rcombs> I guess you could probably change all that to take a parameter, but there's a decent chance you'd take a perf hit by spending a register [23:17:50 CEST] <rcombs> and potentially needing more spills on 32-bit x86 [23:18:18 CEST] <BBB> the whole reason its a define is so you dont need to do it at runtime [23:18:34 CEST] <BBB> and its a variable so its self-defining [23:18:39 CEST] <Tarmik> CPU specific defines indeed needs to be preconfigured somehow, this is something I'll try to investigate later on how to configure. I would say that projects could target to lead cpu / platforms (like x86, x64, armv7 / armv8), but any variation on hardware / cpu wise could try to go into run-time not compile time configuration. But these are just brief ideas. Needs to be analyzed deeper. [23:18:44 CEST] <BBB> as opposed to why is there a magic value 64 in various places in the code??" [23:19:05 CEST] <BBB> anyway [23:19:05 CEST] <rcombs> >but any variation on hardware / cpu wise could try to go into run-time not compile time configuration [23:19:06 CEST] <rcombs> what the fuck [23:19:10 CEST] <BBB> I agree with what others said [23:19:13 CEST] <BBB> this is a solved problem [23:19:17 CEST] <BBB> why are we discussing this? [23:19:20 CEST] <rcombs> what does this even mean [23:19:33 CEST] <BBB> Tarmik: if youre interested in how it works, ask questions; dont reimplement stuff that is fully solved and finished, thats silly [23:19:39 CEST] <wm4> also the reason for configurable sws filter size has been invalidated by now (sws can do multiple scale passes now) [23:19:42 CEST] <BBB> youre basically wasting your time [23:20:07 CEST] <wm4> indeed [23:20:13 CEST] <wm4> and also misleads others [23:20:26 CEST] <wm4> especially if you put it in the wiki [23:20:37 CEST] <wm4> and then we might have to deal with a whole army of Tarmiks [23:20:54 CEST] <wm4> who think ffmpeg should have MSVC project files etc. [23:21:00 CEST] <rcombs> everything in config.h is there for a reason [23:21:31 CEST] <rcombs> largely either because it's hardware/OS/compiler/etc-dependent, or because it depends on which dependency libraries are available (and which versions of them) [23:21:35 CEST] <rcombs> and no determining those things at runtime does not make sense, even in cases where it'd be possible to do so [23:21:47 CEST] <rcombs> why would you think that's a good idea, how does that even sound vaguely good-idea-like [23:22:23 CEST] <wm4> we already have runtime dispatch for things where it makes sense [23:22:26 CEST] <Tarmik> Currently any modification in config.h file means recompilation of whole project. Takes time to compile. [23:22:33 CEST] <wm4> like switching between SSE and AVX impls on x86 [23:22:52 CEST] <wm4> Tarmik: because you're guessing the config.h contents [23:22:57 CEST] <wm4> which you should not [23:23:04 CEST] <wm4> configure writes this file, automatically [23:23:29 CEST] <rcombs> generally people don't modify config.h much [23:23:29 CEST] <rcombs> if you need to build with multiple configurations, create multiple out-of-tree build dirs [23:23:53 CEST] <Tarmik> btw - can configure be deployed as a one standalone executable, like it's with nasm.exe or yasm.exe ? [23:24:05 CEST] <Tarmik> or syncProj.exe ? [23:24:49 CEST] <rcombs> it's a shell script [23:25:21 CEST] <rcombs> you can run it like a binary [23:25:50 CEST] <Tarmik> For assembly files I've just added yasm.exe as executable which is launched: https://sourceforge.net/p/vlc2/code/HEAD/tree/extlibs/ffmpeg/ [23:26:25 CEST] <wm4> jesus christ [23:26:43 CEST] <wm4> a build system is not a build environment [23:27:34 CEST] <Tarmik> I like "all-in-one" kind of project. If I'll make fixes in vlc or ffmpeg, I can then track down later what modifications I did and on what source code. [23:27:46 CEST] Action: rcombs headtilts [23:28:09 CEST] <rcombs> oh, you're advocating for everything in one repo [23:28:20 CEST] <iive> rcombs: avoid shart angles... [23:28:28 CEST] <rcombs> that's a whole different can of worms and also no [23:28:29 CEST] <BBB> doesnt vlc have that already? [23:28:31 CEST] <iive> sharp... [23:28:34 CEST] <BBB> what is that called again [23:29:20 CEST] <BBB> contrib [23:29:47 CEST] <Tarmik> contrib = extlibs in vlc2. [23:29:58 CEST] <Tarmik> only included as source codes. [23:30:51 CEST] <wm4> having a meta build system is ok, but you do _not_ mess with the projects' build system [23:31:01 CEST] <BBB> gstreamer did that for a while [23:31:03 CEST] <BBB> :-p [23:31:07 CEST] <BBB> in fact, I believe I wrote that [23:31:12 CEST] <wm4> anyway you're allowed to shoot yourself into the foot as much as you like, but stay away from the ffmpeg wiki [23:31:17 CEST] <BBB> makes me totally appreciate this situation right now :D [23:31:36 CEST] <Tarmik> Anyway, syncProj, vlc2 are just my own free time projects, I don't intent to sell them to anyone if you're not buying it. :-) [23:33:15 CEST] <Tarmik> I still haven't tried vlc in Android environment, because my wife & children are using my devices, so don't have test Android device yet. :) [23:33:38 CEST] <Tarmik> But I sense problems anyway. [23:34:21 CEST] <Tarmik> it took me a while to collect x86/debug windows, but android goes in other direction in quite many ways. [23:34:21 CEST] <rcombs> ya think [23:34:53 CEST] <rcombs> hmmm, it's almost like building your whole system around a single architecture was ill-advised [23:35:37 CEST] <Tarmik> Which single architecture you don't like ? [23:36:56 CEST] <rcombs> it's not the architecture itself, it's how you did a bunch of work to set up a build system that only targets x86 [23:37:15 CEST] <rcombs> x86 MSVC, in particular [23:37:26 CEST] <rcombs> so no shit it's gonna be a pain to get it to work with ARM gcc/clang [23:37:29 CEST] <Tarmik> I can compile also ARM, but unfortunately cannot yet test it. [23:37:50 CEST] <Tarmik> with gcc [23:37:54 CEST] <rcombs> as opposed to the portable build system the project provides [23:37:55 CEST] <Tarmik> not clang [23:38:28 CEST] <Tarmik> my current target is only Visual studio, and this is major risk I think. [23:38:49 CEST] <Tarmik> no cmake, no QT creator, nothing else. [23:38:55 CEST] <Tarmik> no second IDE in that sense. [23:39:41 CEST] <rcombs> how about dependencies [23:39:59 CEST] <rcombs> or alternate compiler flags [23:40:01 CEST] <wm4> if your stupid IDE can't deal with external build systems maybe your IDE is trash [23:40:12 CEST] <rcombs> it can [23:40:19 CEST] <rcombs> or different sets of enabled components [23:40:27 CEST] <rcombs> or different licenses [23:41:16 CEST] <rcombs> or the 4 different architectures people commonly build for on android [23:41:43 CEST] <nevcairiel> msvc doesnt even need a project file to work anymore, you can just point it a folder of code and it has practically all its functionality - minus building, of course. but you can tell it to invoke make if you want to [23:42:15 CEST] <BBB> https://xkcd.com/927/ [23:42:24 CEST] <nevcairiel> (opening folders of code was really quite a neat addition for 2017) [23:42:47 CEST] <rcombs> or different NDK target versions (which expose different libc features) [23:42:47 CEST] <wm4> BBB: that comic is bogus [23:42:58 CEST] <nevcairiel> its kinda true tho [23:43:03 CEST] <BBB> of course it is, its a comic [23:43:04 CEST] <wm4> a new standard could have much better chances at making it [23:43:18 CEST] <nevcairiel> history tells us, that statement is bogus =p [23:43:37 CEST] <Tarmik> comic: ha ha ! it's so true. :-) [23:44:00 CEST] <rcombs> or when ffmpeg adds new components that your pre-built config.h doesn't account for [23:44:12 CEST] <wm4> the problem is not so much that a new standard is not good or popular, just that people will cling to old/bad standards [23:44:21 CEST] <wm4> just like COBOL is still in use [23:44:39 CEST] <wm4> that doesn't mean new languages after COBOL weren't a good idea [23:44:58 CEST] <durandal_170> whats wrong with cobol? [23:45:13 CEST] <nevcairiel> perhaps, but often times a new standard doesnt really manage to cover all the special cases, hence why its hard to replace everything - or if it tries to, it often becomes an untouchable mess [23:46:16 CEST] <wm4> of course there are many failures [23:46:16 CEST] <rcombs> wm4: yeah, the idea is just that a new standard can't expect to replace all existing tools in all use-cases [23:46:33 CEST] <rcombs> like, the new languages after COBOL replaced COBOL for some things, but there are still COBOL projects [23:46:42 CEST] <rcombs> (OK, almost everything) [23:46:49 CEST] <wm4> the implication of the comic seems to be that new standards are a bad idea and achieve nothing [23:46:55 CEST] <wm4> or is that just due to my pessimistic filter [23:46:57 CEST] <nevcairiel> programming languages are a bad example really [23:47:10 CEST] <nevcairiel> you dont just "replace" a language because re-writing huge codebases is not feasiable [23:47:29 CEST] <nevcairiel> people dont start a project anymore and say "lets use COBOL, its great at XXX" [23:47:38 CEST] <rcombs> nah, it's that new standards specifically aiming to replace all the existing ones are generally a fool's errand [23:47:39 CEST] <nevcairiel> but legacy COBOL shit just keeps existing for decades [23:47:53 CEST] <iive> it works, and we keep it working. [23:48:02 CEST] <iive> ;) [23:48:11 CEST] <rcombs> they can be useful, but they won't replace all the existing tools [23:48:11 CEST] <wm4> are video standards a better example [23:48:43 CEST] <RiCON> video standards serve to make new patents [23:48:47 CEST] <nevcairiel> kinda, although it tends to swing to the other extreme. [23:48:52 CEST] <Tarmik> I've wrote syncProj on C# because it provides API's to make it possible C# scripting. In C++ there for example exists projects like cling, but it's not so popular / well known. Also compiling it on windows takes a lot (at least when last time I've tried it 5 years ago). [23:49:07 CEST] <nevcairiel> old videos dont get typically converted just to replace their codec [23:49:25 CEST] <rcombs> maybe, since people are still using MPEG-2 [23:49:25 CEST] <rcombs> MPEG-2 audio, even [23:49:44 CEST] <rcombs> the comic itself lists some examples [23:49:46 CEST] <wm4> RiCON: like vp9? [23:49:49 CEST] <nevcairiel> however, new videos will often adapt new codecs more rapidly since the tech is very similar and offers bandwidth and therefor money saving [23:50:09 CEST] <rcombs> think of power outlets [23:50:23 CEST] <rcombs> so many countries have come up with their own instead of adopting an existing one [23:51:15 CEST] <nevcairiel> (audio is a bit on the odd side on upgrading, since the gains are so minimal) [23:51:29 CEST] <iive> not only power outlets, even power properties, 110V/220V 50Hz/60Hz [23:51:40 CEST] <rcombs> USB has taken over pretty much everywhere for DC charging, but there are still a bunch of other less-used ports, and USB has a whole bunch of variants [23:51:42 CEST] <nevcairiel> well at least there is only like two [23:51:49 CEST] <nevcairiel> and the important parts of the world use the riight one [23:51:57 CEST] <rcombs> nevcairiel: 100V vs 120V! [23:52:17 CEST] <rcombs> (usually that's close enough for device tolerances, but not always) [23:52:29 CEST] <nevcairiel> its just called 220v, in reality its more like 230-240 [23:52:59 CEST] <rcombs> yeah, and US is called 110 or 120 or 125 depending on who you ask [23:53:06 CEST] <rcombs> but Japan is actually 100 [23:53:29 CEST] <iive> i would have expected that japan would want to go with 360V [23:53:35 CEST] <rcombs> their grid is batshit crazy, though [23:53:45 CEST] <Tarmik> Anyway - I think I'll join this channel next time when I'll have problems with Android ffmpeg which I cannot solve on my own. Feel free to mail me (tapika(a)yahoo.com) if you have questions / comments / proposals. See you. :-) [23:54:15 CEST] <RiCON> Tarmik: i'd advise #ffmpeg instead [23:54:32 CEST] <Tarmik> Ah, ok. :) [23:54:44 CEST] <rcombs> is there an advantage to lower household voltages at all [23:55:00 CEST] <rcombs> my understanding is that 2XX is strictly safer in all ways [23:55:05 CEST] <nevcairiel> you might not die as much when you touch it [23:55:09 CEST] <rcombs> (less likely to kill you if you touch it, less likely to start a fire) [23:55:42 CEST] <iive> rcombs: to get the same power with lower voltage, you need more current (Ampers) [23:55:44 CEST] <rcombs> (because apparently 2XX is likely to cause your hand to jump back, whereas 1XX might cause muscle contraction -> grasping) [23:55:52 CEST] <iive> this means that power cables get hotter. [23:55:56 CEST] <rcombs> iive: yeah, thus lower voltages being a greater fire hazard [23:56:08 CEST] <nevcairiel> i dont know about such muscle things, but more voltage is strictly more dangerous [23:56:09 CEST] <rcombs> and/or requiring larger wire [23:56:20 CEST] <iive> however in case of short-circuit, lower voltage is going to deliver less current over your body. [23:56:24 CEST] <nevcairiel> same contact time, anyhow [23:57:30 CEST] <iive> yeh, also DC is much safer than AC [23:57:40 CEST] <iive> but AC is easier to transport. [23:57:52 CEST] <atomnuker> iive: you fucking wat? DC is safer? [23:58:02 CEST] <atomnuker> DC is scary as fuck and I'm not touching it [23:58:24 CEST] <atomnuker> above say 150 volts that is [23:58:48 CEST] <iive> now with solar power and personal energy storage DC might become more relevant for home appliance [23:59:31 CEST] <nevcairiel> we'll never get DC power outlets, if devices need DC power they'll need rectifiers [23:59:52 CEST] <iive> like PSU :D [00:00:00 CEST] --- Sun Jul 2 2017

1 0

ffmpeg.log.20170701
by burek 02 Jul '17

02 Jul '17

[01:07:26 CEST] <Hopper_> Hey all, anyone have a moment to troubleshoot my "Unable to find a suitable output format for [out]"? [01:09:36 CEST] <DHE> you probably have a syntax error in your commandline [01:10:01 CEST] <DHE> I assume [out] is a filter_complex pipeline element [01:10:09 CEST] <Hopper_> I'm SURE I do, just started on ffmpeg this morning. [01:10:26 CEST] <DHE> pastebin plz [01:11:01 CEST] <Hopper_> working on it, the device which is running the command is not wan connected. [01:12:28 CEST] <Hopper_> https://pastebin.com/e7Fuu0Gd [01:13:37 CEST] <DHE> after -filter:v you should have a space [01:14:08 CEST] <DHE> you've accidentally glued two parameters into one [01:14:35 CEST] <Hopper_> Good catch, thanks. [01:15:27 CEST] <Hopper_> Now it says "output with label 'out' does not exist in any defined filter graph, or was already used elsewhere." [01:16:14 CEST] <DHE> ah, yes. -filter:v should be -filter_complex [01:17:23 CEST] <Hopper_> Look at you! That's got it working now. [01:17:36 CEST] <Hopper_> Where do I put -threads 0 in here? [01:18:08 CEST] <DHE> that's usually the default. otherwise, it goes just before the output file typically [01:19:12 CEST] <Hopper_> Hm, I'm getting a heap of brown text telling me "Past duration 0.0numbers too large" [01:21:26 CEST] <DHE> test the output to see if it looks okay. it might not be a big deal, but make sure [01:22:07 CEST] <Hopper_> no video on the output, and vlc doesn't even show a timecode. [01:22:20 CEST] <Hopper_> But the file is growing in size. [01:23:24 CEST] <DHE> hmm... I suspect mepg-ts doesn't support mjpeg [01:23:45 CEST] <Hopper_> It works if it's a single data stream. [01:24:42 CEST] <Hopper_> DHE: I appreciate your help, but my work day is over. I'll be back on wed after the holiday, I hope you'll be around then. You've already been very helpful! [01:32:34 CEST] <DHE> plenty of other people here. I'm just at my keybaord and happen to have an idea what it might be [03:11:56 CEST] <kepstin> alexpigment: so, my industry friends got back to me - and, well, the answer is "it depends on the tv", some will only support 24+50 or 24+60 with different models per territory, others will support multiple frequencies. so, yeah :/ [07:38:38 CEST] <memphisw> /script load usercount.pl [10:44:55 CEST] <hiihiii> hello [10:45:36 CEST] <hiihiii> how do I use the ocr filter? I can't seem to find a way to output results to a file [10:46:19 CEST] <durandal_1707> hiihiii: with metadata filter [10:46:59 CEST] <durandal_1707> -vf ocr,metadata=print [10:48:43 CEST] <hiihiii> yes in the doc it says something about that filter "The filter exports recognized text as the frame metadata" but I didn't understand well [10:49:41 CEST] <durandal_1707> hiihiii: use command i gave you [10:50:12 CEST] <hiihiii> so it's -vf ocr,metadata=print:file=result.txt [10:50:20 CEST] <hiihiii> right? [10:50:25 CEST] <durandal_1707> yes [10:50:31 CEST] <hiihiii> ok thx [10:51:59 CEST] <hiihiii> how accurate is the recognition? my input is something like this "0000015 F2 0" [10:52:15 CEST] <hiihiii> each frame is just one line [10:52:48 CEST] <durandal_1707> hiihiii: depends how on many factors [10:54:29 CEST] <hiihiii> ocr's whitelist is the letters that I only want to catch [10:56:01 CEST] <hiihiii> how do I set that? -vf ocr=whitelist='0123456789ABCDEF',metadata=print:file=result.txt [10:57:43 CEST] <durandal_1707> yes, read docs [11:06:24 CEST] <thebombzen> hiihiii: remember that it uses tesseract for OCR so you need to have the appropriate tesseract language packs installed. I think English is bundled in with the windows zeranoe builds. on Linux make sure you install tesseract-data-eng or equivalent [11:08:19 CEST] <hiihiii> isn't English the default [11:13:46 CEST] <thebombzen> well on Arch, for example, it doesn't come packaged in with tesseract and you need to specifically install tesseract-data-eng [11:13:59 CEST] <thebombzen> on other systems, English might come bundled in [11:46:35 CEST] <hiihiii> ummm is there a windows build somewhere with tesseract? [18:14:13 CEST] <thoraxe> this may be a dumb question but i am playing with an rstp device that seems to have a borked audio stream. I don't really care about the audio, I'd be happy just to drop it [18:14:34 CEST] <thoraxe> trying to figure out the magic google search for dropping/ignoring audio in a stream [18:14:40 CEST] <DHE> -an [18:15:46 CEST] <thoraxe> ah, perfect [18:15:54 CEST] <thoraxe> now to figure out why youtube live doesn't think i'm actually sending it data [18:19:14 CEST] <ChocolateArmpits> Is there any way to control image compression for BMP files? [18:19:50 CEST] <kerio> bmp is not compressed [18:20:27 CEST] <kerio> oh wait, apparently it can be :o [18:21:14 CEST] <BtbN> it has some very basic compression [18:21:17 CEST] <BtbN> but why not just use png? [18:21:54 CEST] <ChocolateArmpits> bitmap stores image data as a simple array if there's no compression, png has filter information on every line start [18:22:48 CEST] <DHE> "ffmpeg -h encoder=bmp" does not indicate any options supported [18:24:30 CEST] <ChocolateArmpits> png makes use of compression_level argument to specify compression level, that however doesn't work for bmps [18:25:20 CEST] <BtbN> But why the need for bmp? [18:25:29 CEST] <BtbN> png is also lossless, but compresses way better [18:26:50 CEST] <ChocolateArmpits> I want to pack opus files into images and then read those using -skip_initial_bytes. As I said before, png has filter information on every line that kind of messes up playback somewhat [18:27:29 CEST] <thoraxe> well, i got twitch working [18:27:40 CEST] <thoraxe> youtube live doesn't think i'm streaming to it after a few moments [18:29:13 CEST] <BtbN> but why? oO [18:29:19 CEST] <BtbN> @opus in bmp [18:30:08 CEST] <ChocolateArmpits> cause there are places where anything but only a select few image formats are allowed to be posted [18:30:24 CEST] <ChocolateArmpits> and opus is really efficient for audio exchange [18:31:40 CEST] <BtbN> So you want to upload audio to an image board of some kind? It won't play anywhere though? [18:32:23 CEST] <ChocolateArmpits> well that's why using a backwards command line to seek to a specific part of the file will [18:32:46 CEST] <ChocolateArmpits> something like ffplay -skip_initial_bytes 46 -f ogg image.png [18:33:02 CEST] <ChocolateArmpits> actually that's how I do it atm with pngs [18:33:25 CEST] <ChocolateArmpits> though I'm not happy with filter info [18:34:17 CEST] <ChocolateArmpits> uncompressed pngs have each line start with 0x00 inserted, so on playback it's corrupted for a few samples on every line [18:34:51 CEST] <ChocolateArmpits> I can increase width, bit depth and channel count to offset the problem ,but it won't remove it completely [18:37:12 CEST] <kerio> can't you just append a rar to a jpeg [18:37:17 CEST] <kerio> like in the good ol times [19:57:26 CEST] <ChocolateArmpits> aww yes finally working. Bmps actually aren't compressed, I just didn't know they are written bottom up. Vflip solves this however :). [20:03:10 CEST] <furq> you could just use tif [20:06:37 CEST] <alexpigment> Hey guys, I'm making a music video playlist for a party we're throwing tonight. I've got a huge collection of DVD rips and stuff, but of course the volumes are all over the place. Does anyone have any advice on filters that would give a perceptually similar level of volume? [20:07:05 CEST] <alexpigment> I'm thinking about just converting everything to MKV, copying the video stream, and filtering the audio into PCM [20:08:31 CEST] <furq> you could use replaygain if your player supports it [20:08:49 CEST] <furq> i'm pretty sure mpv supports it now [20:11:26 CEST] <JEEB> ChocolateArmpits: the height can be negative as well as positive in BMPs [20:11:34 CEST] <JEEB> read the header and you'll know how to read them [20:16:23 CEST] <alexpigment> furq: replaygain would just be a simple normalizer, right? [20:17:06 CEST] <furq> it's not even that, it's just player auto-amplification to -6dB [20:17:41 CEST] <alexpigment> but there's no dynamic range compression to make the music sound like it's at the same level, right? [20:17:47 CEST] <furq> no [20:17:52 CEST] <furq> it's pretty much zero effort though [20:17:56 CEST] <alexpigment> Kodi supports it, which is what I'll be using, but I'm thinking I need to use compression [20:17:56 CEST] <furq> fb2k will do it [20:18:21 CEST] <alexpigment> does fb2k play videos yet? [20:18:27 CEST] <alexpigment> i thought it was just audio [20:18:35 CEST] <furq> i mean it'll add the replaygain tags to mkv [20:18:46 CEST] <alexpigment> gotcha [20:19:27 CEST] <furq> i'd have thought it would work well for music videos [20:20:17 CEST] <alexpigment> well, the problem is just that music is mixed very differently, so sometimes the snare drum is loud, and if you normalize, it'll base it on the peaks, but the average of the peaks and the valleys is what contributes to perceived volume [20:20:32 CEST] <furq> oh nvm i'm wrong it's not just peak normalisation [20:20:48 CEST] <alexpigment> oh cool [20:21:19 CEST] <alexpigment> (i probably could have just googled it when you suggested it :) ) [20:21:21 CEST] <alexpigment> sorry about that [20:21:21 CEST] <furq> it does just apply a straight amplitude gain though [20:21:24 CEST] <alexpigment> looking into it [20:21:55 CEST] <alexpigment> well, as long as it does it by doing a scientific analysis of the original perceived volume, it's not a huge deal [20:22:12 CEST] <alexpigment> i've got lots of headroom on my speakers, so volume spikes at the peaks are zero problem [20:22:23 CEST] <ChocolateArmpits> you could look into ebur128 filters if you have time [20:22:42 CEST] <furq> isn't that the same thing [20:22:49 CEST] <ChocolateArmpits> no [20:23:49 CEST] <alexpigment> I'll check out ebur128 in a bit [20:24:04 CEST] <alexpigment> furq: you mentioned adding replaygain to MKV files with foobar2k [20:24:21 CEST] <alexpigment> is it pretty straightforward to do that or are there any tricks I should know about [20:24:28 CEST] <furq> not really [20:25:05 CEST] <furq> your only real choice is "scan per-file track gain" or "scan selection as single album" [20:25:17 CEST] <furq> maybe the second one would be better if these are part of a compilation [20:26:00 CEST] <alexpigment> nah, it's a completely hand-picked video playlist [20:26:16 CEST] <alexpigment> around a hundred from my collection, so it's not going to be similar in volume [20:26:30 CEST] <alexpigment> anyway, i'll give it a shot. thanks for the heads up [22:25:33 CEST] <nicolas17> I managed to decode 1 (one) frame from a video \o/ [22:25:39 CEST] <JEEB> 'grats [22:25:41 CEST] <nicolas17> (with the API) [22:25:43 CEST] <JEEB> that's the first thing [22:25:51 CEST] <JEEB> (I did that in my matroska thumbnailer for windows) [22:25:51 CEST] <nicolas17> and output it to a ppm [22:26:03 CEST] <JEEB> in my case the output was a BMP structure because windows wanted one) [22:26:18 CEST] <JEEB> I also implemented custom IO since Windows would be giving the data through their IStream API [22:26:36 CEST] <nicolas17> hm the result is wrong [22:26:55 CEST] <nicolas17> looks like I'm getting all the red samples, then all green, then all blue [22:27:01 CEST] <nicolas17> while ppm expects r,g,b,r,g,b,r,g,b [22:28:08 CEST] <JEEB> sounds like you're either taking data as decoded or so [22:28:37 CEST] <JEEB> you should know what your decoded pictures are in (which PIX_FMT) [22:28:47 CEST] <nicolas17> well I'm getting YUV, so I'm converting it to AV_PIX_FMT_RGB24 with swscale [22:28:49 CEST] <JEEB> and then if you need to convert you can utilize various functionality) [22:28:56 CEST] <JEEB> oh, that should be not planar [22:29:02 CEST] <JEEB> unless you use the planar color space [22:29:08 CEST] <JEEB> (there's a specific planar RGB thing) [22:29:19 CEST] <JEEB> then you're handling the data after the conversion incorrectly I think? [22:29:37 CEST] <JEEB> check the pix_fmts on all places that they are what you expect [22:30:15 CEST] <nicolas17> okay I'm an idiot, I'm decoding into 'frame', using swscale to convert into another AVFrame called 'frameRGB', then passing 'frame' to my save_ppm function \o/ [22:30:23 CEST] <JEEB> :D [22:30:35 CEST] <nicolas17> so I guess this is the planar YUV I'm looking at? or whatever it is [22:30:40 CEST] <JEEB> yes [22:30:50 CEST] <JEEB> if the decoded image is planar YCbCr then that's what it is [22:32:19 CEST] <nicolas17> can I convert an AVPixelFormat to a string name? [22:32:29 CEST] <JEEB> yea [22:32:35 CEST] <JEEB> there was a utility function for it [22:32:39 CEST] <JEEB> which the command line apps are also using [22:32:41 CEST] <nicolas17> I'm digging through doxygen [22:33:59 CEST] <JEEB> av_get_pix_fmt_string [22:34:01 CEST] <JEEB> I think [22:34:15 CEST] <JEEB> in libavutil [22:35:28 CEST] <nicolas17> yeah so input is yuvj422p [22:37:01 CEST] <JEEB> so full range 4:2:2 YCbCr [22:40:38 CEST] <nicolas17> okay, I got a black image and a segfault, turned out sws_scale wasn't succeeding [22:40:50 CEST] <nicolas17> now it did (wrong arg) and I have a valid image \o/ [22:41:12 CEST] <nicolas17> and valgrind says I'm freeing everything I should [22:42:01 CEST] <nicolas17> it's a hundred lines of horror though [22:57:13 CEST] <nicolas17> JEEB: I'm decoding JPEGs with image2, and I need to access their EXIF data, does ffmpeg decode EXIF? [22:57:36 CEST] <nicolas17> otherwise, can I access the filename of the current frame so I can feed it into an EXIF library? [22:58:08 CEST] <JEEB> no idea about EXIF [22:58:20 CEST] <JEEB> you can check the libavformat/libavcodec demuxer related [22:58:23 CEST] <JEEB> (or decoder) [22:59:04 CEST] <durandal_170> iirc its available as frame metadata [22:59:25 CEST] <nicolas17> do I need to request that first? [22:59:30 CEST] <nicolas17> frame->metadata is NULL [23:00:01 CEST] <durandal_170> wasnt it tiff? [23:01:51 CEST] <nicolas17> nvm I'm an idiot again, I was looking at *frame with a debugger but I hadn't stepped past avcodec_receive_frame yet [23:03:42 CEST] <nicolas17> frame->metadata is an AVDictionary with all the EXIF tags :) [23:04:14 CEST] <durandal_170> \Ë/ [23:13:19 CEST] <nicolas17> why does uint8_t** -> const uint8_t* const* conversion give a warning? it's totally safe :/ [23:22:24 CEST] <thebombzen> nicolas17: Because if you cast char** to const char* const*, then any caller receiving the const char* const* pointer will assume that it's const [23:23:20 CEST] <thebombzen> suppose I have: char **x; inside a() and I cast it to (const char *const*) and pass that casted variable to b() [23:23:50 CEST] <rcombs> what's wrong with that [23:23:51 CEST] <durandal_170> too many indirections [23:23:56 CEST] <nicolas17> that doesn't let b do something it shouldn't [23:24:02 CEST] <thebombzen> well b() is going to assume that the pointer passed is const. However, a() could still modify it. [23:24:20 CEST] <thebombzen> b() isn't going to do something it shouldn't, but from b()'s perspective, a() can do something it shouldn't. [23:24:22 CEST] <rcombs> adding const never creates opportunities for invalid accesses [23:24:28 CEST] <rcombs> _removing_ const can [23:24:36 CEST] <nicolas17> thebombzen: that's true for single indirection too, if I have a char[42 [23:24:39 CEST] <nicolas17> argh keyboard [23:24:57 CEST] <thebombzen> It never creates opportunities, sure, but it creates extra assumptions or assurances that it really is const. [23:25:00 CEST] <nicolas17> thebombzen: that's true for single indirection too, if I have a char[42] and I pass it as a const char* to b(), I can still modify it, but I'm pretty sure that doesn't warn [23:25:15 CEST] <thebombzen> Pretty sure it does [23:25:39 CEST] <rcombs> it does not [23:25:41 CEST] <nicolas17> so passing a char[42] to strlen warns? [23:26:57 CEST] <kerio> nicolas17: http://c-faq.com/ansi/constmismatch.html actual reason [23:27:52 CEST] <thebombzen> so it seems, it does not warn. [23:27:57 CEST] <thebombzen> Goes to show how much I know about C. [23:31:10 CEST] <nicolas17> kerio: thanks, that explains the hole it would open [23:38:10 CEST] <marcurling> Hello, is there an auto-crop function to get rid/cut black stripes from letterbox films? [23:40:16 CEST] <kerio> cropdetect [23:48:05 CEST] <marcurling> ty kerio. Which tool would you recommend to set the (correct) Display aspect Ration to an anamorphosed movie? [00:00:00 CEST] --- Sun Jul 2 2017

1 0

ffmpeg-devel.log.20170630
by burek 01 Jul '17

01 Jul '17

[00:01:18 CEST] <kurosu> an example of what bitstream.h could look like (expiry 1H): https://pastebin.com/WfPyiLk1 [00:01:33 CEST] <Compn> durandal_1707 : what kind of food ? [00:03:20 CEST] <kurosu> good night [00:04:58 CEST] <wm4> iive: a bitstream reader call will access all the bitstream state through pointers, which could be aliased to other pointers, so the compiler has to reload them all the time [00:05:03 CEST] <wm4> which is probably slower [00:05:47 CEST] <wm4> which is why performance critical code either puts the reader state on the stack (so the compiler's optimizer can work better), or do explicit caching with those awful macros [00:12:37 CEST] <atomnuker> kurosu: if you're being choked by contracts preventing you from sharing you can always become an elvis presley [00:22:53 CEST] <iive> wm4: i see [00:28:09 CEST] <iive> wm4: however making a local copy is not enough, because the API requires getting pointer to the struct. You need to duplicate the api in order to use struct.member instead of struct->member. [00:29:06 CEST] <iive> unless the compiler is smart enough to figure it out on its own. [00:29:20 CEST] <wm4> duplicate the api? wat [00:30:45 CEST] <iive> nah, i still can't make sense of these aliasing rules. [00:31:09 CEST] <iive> it doesn't make sense for the compiler to assume the aliasing is always broken [00:31:32 CEST] <iive> simply because there is C primitive to signal when to assume that. [00:31:44 CEST] <iive> to signal when that is the case. [00:35:36 CEST] <iive> Let me say it this way. The compiler always assumes nothing else modifies the structure it is working with. [00:37:15 CEST] <iive> this is why it complains when you access strcutures with different type, because it breaks its assumption. [00:43:35 CEST] <iive> well, not always, but at -O2 [00:48:28 CEST] <wm4> well yes that's the reason why other high level languages can be much faster than C (Fortran is a popular example) [00:49:09 CEST] <wm4> compilers started doing strict aliasing rules for different types to help optimization (which broke code which ignored that rule) [00:49:23 CEST] <wm4> for for the same types, like int*, it's still a problem [00:49:28 CEST] <wm4> *but [01:32:12 CEST] <nevcairiel> atomnuker: sorry i was out, the new api defines two functions for the encoder, one to submit input and one to generate output, and you can control with return values which should be called next (ie. if you return EAGAIN from send_frame, you indicate that you are not accepting new input right now, and the user has to call receive_packet a bunch first to get encoded data out) [01:41:25 CEST] <atomnuker> ah, I didn't think about the return value of encode_frame [01:42:51 CEST] <atomnuker> wait, when does encode_frame get called, when the user submits frames, right? not when they request packets [01:43:17 CEST] <nevcairiel> there is no such thing as encode_frame [01:43:24 CEST] <atomnuker> I mean internally [01:43:50 CEST] <nevcairiel> there is send_frame which gives your encoder new frames, and receive_packet which gets encoded data out of the encoder [01:44:11 CEST] <atomnuker> yes, I know how the new api works [01:44:13 CEST] <nevcairiel> (the public APIs are named similar to those f unctions, with prefixes and whatnot) [03:04:07 CEST] <cone-838> ffmpeg 03Michael Niedermayer 07master:0b180d2066ed: fate: Add fate-copy-trac3074 [03:51:05 CEST] <cone-838> ffmpeg 03Michael Niedermayer 07master:60a45713e7bc: avcodec/interplayvideo: Check ff_get_buffer() for failure [05:38:07 CEST] <rcombs> kierank: until about 11:00 [08:37:31 CEST] <kurosu> atomnuker, there are 2 sides to your comment [08:38:44 CEST] <kurosu> legality-wise, it's one thing to hide from potential harassment a la foo86 (then maybe he signed an NDA to get specs), and to wilfully breach a contract [08:41:06 CEST] <kurosu> as for the pro-bono side, I prefer not to expand too much on it (a lot of people are doing a lot against it already), but people/companies are way too used to getting stuff for free/chump change (not that a bitstream reader matters to most anyway) [08:42:59 CEST] <kurosu> bye [10:12:52 CEST] <durandal_1707> michaelni: i want to add >8 bpp support to geq only if you are willing to relicense it to lgpl [12:39:35 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:ecc16d893dc0: avfilter/vf_geq: >8 bps support [12:52:41 CEST] <durandal_1707> michaelni: why are you so against relicensing? [13:50:26 CEST] <durandal_1707> michaelni: ok if you like to ignore me i gonna remove dupe prores stuff [13:53:01 CEST] <ubitux> you waited 1h [13:54:46 CEST] <durandal_1707> yes so i gonna push it in less than one hour [13:58:24 CEST] <J_Darnley> Argh! Why the hell isn't ffplay looping? [14:09:14 CEST] <iive> durandal_1707: what do you want relicensed? [14:29:45 CEST] <durandal_1707> iive: geq [14:30:23 CEST] <iive> isn't it lgpl already? [14:30:57 CEST] <wm4> 1 second of research shows "no" [14:31:19 CEST] <wm4> not sure why anyone would want this filter though [14:31:22 CEST] <wm4> using luajit is faster [14:33:14 CEST] <J_Darnley> atomnuker are you around? [14:33:16 CEST] <iive> it's from mplayer, i guess this is why. [14:34:14 CEST] <iive> I also don't see any request for relicensing on the maillist. [14:34:18 CEST] <atomnuker> J_Darnley: yep [14:39:50 CEST] <J_Darnley> Good. [14:40:53 CEST] <J_Darnley> In the decode_hq_slice function of diracdec.c I cannot tell where the dequant coeffs go. [14:41:14 CEST] <J_Darnley> They go into a buf in the SubBand struct [14:41:44 CEST] <J_Darnley> Does this move them around for te whole plane transform? [14:50:27 CEST] <atomnuker> J_Darnley: look for "uint8_t *buf = b1->ibuf + c->top * b1->stride + (c->left << (s->pshift + 1));" [14:50:39 CEST] <atomnuker> that's where coefficients go [15:44:42 CEST] <tdjones> atomnuker: Did you possibly have a chance to read the email that I had sent yesterday? I am wondering if you can help me figure out the proper codebooks to include for short windows [15:48:04 CEST] <atomnuker> tdjones: did you try the libvorbis ones? [15:52:40 CEST] <tdjones> The problem is that there are several sets of floor books available for 128-sample windows. The documentation for the codebook generator is nonexistant for the difference between each [15:54:18 CEST] <kierank> J_Darnley: possibly the coefficients are ordered wrong for slice based transform [15:54:30 CEST] <atomnuker> tdjones: give one a try to see if it works fine [15:55:12 CEST] <atomnuker> they've probably been optimized for a particular set of samples by a machine [16:43:44 CEST] <cone-163> ffmpeg 03Max Weber 07master:9e392c6ece8d: libavformat/avformat.h: Move docs inside of #if [16:43:44 CEST] <cone-163> ffmpeg 03Michael Niedermayer 07master:de54a37c1dfa: avcodec/hevc_ps: Fix integer overflow with beta/tc offsets [16:47:13 CEST] <cone-163> ffmpeg 03James Almer 07master:ac8ad8d0981b: x86/sbrdsp: sign extend start and end gprs in ff_sbr_hf_gen_sse [17:05:31 CEST] <durandal_1707> iive: why would it need to be on ml? [17:07:17 CEST] <iive> all development is done on the maillist [17:10:27 CEST] <durandal_1707> iive: like security commits [17:12:03 CEST] <durandal_1707> michaelni: your security commit broke als decoder, do you have sample that caused 18f94df8af0? [17:12:41 CEST] <durandal_1707> i run thing under valgrind and it didnt report anything [17:13:57 CEST] <durandal_1707> so i will revert that incorrect commit if i do not get response soon [17:18:49 CEST] <iive> durandal_1707: security is done in private to protect users while fix is been worked on. The case with licensing is quite the opposite [17:20:25 CEST] <durandal_1707> iive: see, you said developement is done on ml [17:21:48 CEST] <iive> every rule has its exceptions. [17:22:09 CEST] <kierank> durandal_1707: just put iive on ignore, it's easier that way [17:23:14 CEST] <durandal_1707> iive: and you have power to tell me when something should be done on ml and when not [17:23:51 CEST] <iive> i'm not giving orders [17:24:41 CEST] <iive> but you are behving unreasonable and I'm trying to understand why [17:24:58 CEST] <durandal_1707> license issues can and should be first told on irc and later on ml [17:25:12 CEST] <iive> why? [17:25:31 CEST] <durandal_1707> exp for sole author of one file [17:26:09 CEST] <iive> well, are you sure he is the sole author of the file? Since it's been in MPlayer, a number of people might have small fixes in there. [17:26:55 CEST] <durandal_1707> thats why ask him first and rest later [17:54:30 CEST] <KGB> [13FFV1] 15dericed opened pull request #73: update to version 03 (06master...06update-to-version-03) 02https://git.io/vQBV4 [18:11:32 CEST] <iive> durandal_1707: well, michael has always preferred email communication. and if you want to ask him personally, maybe ask him in private. [18:20:27 CEST] <durandal_1707> iive: whats so hard telling: no, no way, yes, never and so on? [18:25:34 CEST] <RiCON> durandal_1707: could you check if changing to require_pkg_config "vorbisenc vorbis" fixes your config error? [18:25:44 CEST] <RiCON> to see if ogg is also needed or not [18:27:32 CEST] <atomnuker> durandal_1707: just ask thilo for samples privately, surely he'll give 'em [18:29:33 CEST] <iive> durandal_1707: you didn't get answer? from the fragment I saw I kind of assumed you already got rejection.... [18:30:59 CEST] <durandal_1707> RiCON: still same, something is fishy here [18:33:28 CEST] <RiCON> yeah, nevermind, check_pkg_config doesn't work with multiple .pc [18:33:54 CEST] <RiCON> patch is probably dropped as vorbisenc.pc only requires vorbis and ogg for --static [18:45:28 CEST] <durandal_1707> iive: no, its just you [19:18:18 CEST] <cone-163> ffmpeg 03wm4 07master:ff2d21a58c9c: hevcdec: properly export some side data with frame threading [19:51:03 CEST] <RiCON> durandal_1707: this should work, but it looks a bit uglier than before http://sprunge.us/gYiS [20:13:31 CEST] <J_Darnley> This idwt DSP is insanely laid out [20:14:28 CEST] <atomnuker> yup [20:14:51 CEST] <atomnuker> the forward transforms are nice though [20:15:33 CEST] <J_Darnley> This is nice? I thought the encoder which I failed to write SIMD for was better. [20:17:40 CEST] <atomnuker> well, yeah, the forward transforms are on the encoder side [20:18:28 CEST] <atomnuker> and they're nice because they're not split like the decoder's transforms [20:18:29 CEST] <J_Darnley> That's forwards? [20:18:32 CEST] <atomnuker> yep [20:20:12 CEST] Action: J_Darnley hates this [20:21:02 CEST] <J_Darnley> Why do these contexts hold frame properties? Why are they not function arguments? [20:21:36 CEST] <atomnuker> what did they hold? bit depth? [20:21:45 CEST] <J_Darnley> width, height [20:30:37 CEST] <kierank> Just use haar, it's simppe [20:43:44 CEST] <J_Darnley> Simple my arse. Its all buried behind layers of abstraction. [20:44:07 CEST] <J_Darnley> Not to mention "which haar?" there's two of them. Then there's two functions for H and V [20:47:12 CEST] <durandal_1707> decoder? [20:47:26 CEST] <J_Darnley> dirac/vc2 [20:51:06 CEST] <durandal_1707> why encoder is not using frame threads? [21:08:42 CEST] <atomnuker> durandal_1707: dunno, never bothered to make it [21:08:53 CEST] <atomnuker> if you get it running and its a few lines just push it [21:44:44 CEST] <durandal_1707> atomnuker: have you filled gsoc report? [21:46:43 CEST] <atomnuker> yep [21:46:43 CEST] <kierank> J_Darnley: it's a separable transform [21:46:53 CEST] <kierank> And there is a variant with a shift and one withour [21:47:29 CEST] <atomnuker> (the non-shifted one is practically useless) [21:48:27 CEST] <durandal_1707> this is just arithmetic operations [22:10:57 CEST] <atomnuker> durandal_1707: am I doing something wrong or is the apad filter not working [22:11:25 CEST] <atomnuker> -af apad=pad_len=480000 doesn't pad 10 seconds, it does nothing [22:36:17 CEST] <durandal_1707> atomnuker: give full command [22:37:11 CEST] <wm4> michaelni: ok to push my hevc commit to release branches? (or do you plan on doing that) [22:59:51 CEST] <atomnuker> durandal_1707: ffmpeg -i test.wav -t 00:00:02 -af apad=480000 -y t2.wav [23:00:11 CEST] <atomnuker> test.wav is an hour btw [23:05:03 CEST] <durandal_1707> atomnuker: i dont think you can mix -t and -af [23:05:12 CEST] <durandal_1707> use atrim filter [23:32:03 CEST] <michaelni> wm4, which commit ? i can backport it if you want and assuming it cleanly applies [23:33:17 CEST] <wm4> ff2d21a58c9c4797ea2d1c4ded09c797abc5a39f [23:33:41 CEST] <wm4> for older releases it'll require removing sei fields that were not supported yet at the time [23:40:39 CEST] <michaelni> wm4, do you want to backport it ? iam ok if you just push them [23:41:42 CEST] <wm4> ok I'll do that later [23:41:50 CEST] <wm4> which releases are still active? [23:42:00 CEST] <wm4> and are micro version bumps ok? [23:53:59 CEST] <michaelni> wm4, the ones listed on the main download page are still active, micro bumps are only ok if the release branch has a seperate minor version from master, the most recent ones should older did not [23:54:30 CEST] <wm4> ok [00:00:00 CEST] --- Sat Jul 1 2017

1 0

ffmpeg.log.20170630
by burek 01 Jul '17

01 Jul '17

[00:13:58 CEST] <alexpigment> Is VP8 just really slow, or do you need to specify a number of threads to optimize the speed? [00:14:18 CEST] <sfan5> both [00:14:48 CEST] <alexpigment> well, is there a way to safely specify a number of threads that fail or perform poorly on a system with less cores? [00:14:50 CEST] <atomnuker> won't help, libvpx is single threaded unless you tile (and reduce quality) [00:14:56 CEST] <alexpigment> ah [00:15:01 CEST] <alexpigment> well, that solves that :) [00:15:30 CEST] <alexpigment> thanks for the info [00:18:03 CEST] <Asuran> try -threads 16 [00:18:16 CEST] <Asuran> but after you use -c:v libvpx or what it is [00:19:37 CEST] <Asuran> and dont use more then -threads 16 [00:22:35 CEST] <TD-Linux> alexpigment, also you can set the encoder speed with -speed [00:22:39 CEST] <TD-Linux> higher number = faster [00:23:33 CEST] <alexpigment> if I use -threads 16, is there a downside to using that on, say, a dual-core processor [00:23:46 CEST] <alexpigment> also, if I use -speed, does it reduce the quality? [00:24:06 CEST] <alexpigment> i mean I assume it does in the same way the -preset options work for x264 [00:33:24 CEST] <furq> i don't think libvpx supports any multithreading for vp8 [00:33:34 CEST] <furq> tile-columns and row-mt are vp9 only [00:34:11 CEST] <alexpigment> ok, i'll put it on my list tomorrow to look into this further [00:34:15 CEST] <alexpigment> thanks for the suggestions and info guys [01:01:01 CEST] <Chimaera> good evening - I have an issue compiling ffmpeg that I was hoping someone could help with [01:04:13 CEST] <Chimaera> I'm compiling on raspbian jessie, based on this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu mainly in order to add x.265 and libfdk_aac support [01:04:57 CEST] <Chimaera> the libraries compile fine, with the exception of needing to build x.265 for arm-linux instead of linux [01:05:59 CEST] <Chimaera> the issue comes with running the configure script for ffmpeg itself: I get "ERROR: x265 not found using pkg-config" and a look in ffbuild/config.log shows "In file included from /tmp/ffconf.QcxrG88q/test.c:1:0: [01:06:03 CEST] <Chimaera> /home/pi/ffmpeg_build/include/x265.h:29:18: fatal error: cstdio: No such file or directory #include <cstdio> [01:08:06 CEST] <furq> there is really no reason to have libx265 on a raspberry pi [01:09:47 CEST] <Chimaera> furq: I have a use-case that needs it [01:10:20 CEST] <iive> encoding is slow on PC, on arm it would be much slower. [01:10:32 CEST] <iive> you don't need libx265 for decoding. [01:12:29 CEST] <iive> on the problem... if you are compiling on rpi itself, why do you need to specify cross-compile targets? [01:13:00 CEST] <iive> one would expect that cstdio would be in a system path [01:17:00 CEST] <Chimaera> I'm transcoding and if it's slow that's fine [01:17:23 CEST] <Chimaera> on the compile I'm just working with the default scripts that come with the source packages [01:18:04 CEST] <iive> sorry i'm of no use. [01:18:32 CEST] <iive> maybe somebody will know. keep around. [01:18:40 CEST] <Chimaera> that's fine :) thanks for responding anyway [01:18:40 CEST] <Chimaera> *nod* [01:18:56 CEST] <iive> you are most likely missing some -I/usr/*/include/ [01:19:26 CEST] <Chimaera> I got this to work a while back on a first gen pi but my notes on that are somewhat cryptic at this point [01:19:36 CEST] <iive> see if compilation of x265 have produced pkg-config file, it's probably libx265.pc [01:20:14 CEST] <iive> it should have the proper includes. [01:21:18 CEST] <iive> x265.pc is the one on my system [01:22:03 CEST] <Chimaera> yeah, all the compiled files are there for x265 [01:22:36 CEST] <iive> you can copy the x265.pc file manually to a location where ffmpeg configure could find it. [01:22:46 CEST] <c_14> just export PKG_CONFIG_PATH [01:23:02 CEST] <c_14> are you building statically? [01:23:11 CEST] <c_14> then you'll need --extra-pkg-config-flags=--static or somethnig [01:23:35 CEST] <c_14> check if the output of pkg-config --libs --cflags x265 seems sane [01:29:09 CEST] <Chimaera> c_14: that's all there in the configure invocation for ffmpeg [01:29:41 CEST] <c_14> no clue, can you upload the first and last 50 lines of your config.log to a pastebin service? [01:39:08 CEST] <Chimaera> c_14: http://skynet.ie/~dobrien/ffmpeg_config.txt [01:42:27 CEST] <c_14> how did you install x265? [01:47:35 CEST] <Chimaera> per instructions here: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [01:48:00 CEST] <Chimaera> with the exception that I built from the x265/build/arm-linux [01:53:42 CEST] <c_14> that should work [01:53:50 CEST] <c_14> no clue, sorry [01:54:20 CEST] <Chimaera> ok, thanks for looking :) [02:15:30 CEST] <utack> can i interest someone in a video where ffmpeg color conversion seems to go wrong? or is that expected, when not using zscale and to be ignore? [02:16:23 CEST] <utack> oh well i better not do that...might even be the play messing it up. not sure [02:16:37 CEST] <Asuran> which codec? [02:17:18 CEST] <Asuran> Chimaera, get archlinux or some repo with more updated ffmpeg for ubuntu [02:18:16 CEST] <utack> left=source, right=after ffmpeg scaling and libx264 encoding https://i.imgur.com/7nZdrjm.jpg [02:18:48 CEST] <utack> i am not even sure, the colors on the left look wrong actually, maybe it is the play and ffmpeg is doing the right thing [02:18:55 CEST] <utack> player [02:19:09 CEST] <Asuran> Chimaera, https://bitbucket.org/multicoreware/x265/issues/125/x265-not-found-using-pk… if i dont get it wrong static compile fixes it? did you static compiled it? [02:19:43 CEST] <Asuran> i read recently a warning about yuv color conversion to blame to x265 [02:19:49 CEST] <Asuran> maybe its same, try other codec [02:22:00 CEST] <furq> utack: if you're not using zscale, i think you need the colorspace filter for correct bt.2020 to bt.709 conversion [02:22:14 CEST] <utack> oh okay. manually add it in there? [02:22:19 CEST] <utack> thanks, i will look into it [02:23:01 CEST] <furq> or you could just leave it as bt.2020 [02:23:09 CEST] <furq> iirc -vf colorspace=bt2020 will do that [02:24:35 CEST] <utack> pretty weird choice for the input material i must say, but i guess i can leave it yes [02:24:49 CEST] <utack> colorspace filter worked [02:24:51 CEST] <utack> thanks [02:25:31 CEST] <utack> especially since phone uses 709 for non 4k material [02:25:41 CEST] <furq> it's weird that it's using that for 8-bit yuv [02:26:00 CEST] <furq> i don't know shit about colourspaces but i thought you needed 10bpp for bt.2020 [02:26:12 CEST] <furq> or 10bps rather [02:34:01 CEST] <utack> huh, i just checked what the players on the phone think of it. https://i.imgur.com/Nc28qtV.jpg [02:34:14 CEST] <utack> if the screenshot can be trusted, not the same thing as mpv [02:35:32 CEST] <utack> mpv on phone however shows the red'ish tint again [09:26:00 CEST] <luc4> Hello! Anyone who knows if ffmpeg supports armv8 cortex-a53 build? [15:12:39 CEST] <JC_Yang> I need some suggestions on int64 to AVRational conversion, is there any supported methods to do so? [15:59:22 CEST] <DHE> JC_Yang: it's just a struct with 2 fields. although I'd be worried since they're not 64-bit fields. [15:59:27 CEST] <DHE> JC_Yang: what are you doing exactly? [16:01:27 CEST] <alexpigment> when encoding in VP8, does anyone know if there's a way to make -threads automatically set to the number of real CPUs minus 1? [16:01:51 CEST] <JEEB> yes, if you add a patch for that [16:01:56 CEST] <JC_Yang> my brain was frozen, I've found my way out, thank u. What I need is to multiply a pts to a time base, I do it with pts * timebase.num / timebase.den now... it's simple [16:02:07 CEST] <JEEB> and yea IIRC the default value libavcodec passes there will just mean "1 thread" in libvpx [16:02:22 CEST] <JEEB> kind of surprising (or maybe not) that no-one fixed that ever :P [16:02:25 CEST] <alexpigment> yeah, it definitely only uses 1 thread by default [16:02:39 CEST] <alexpigment> but if you set threads too high, the system stops responding [16:02:44 CEST] <JEEB> libavcodec/libvpx*.c I guess :P [16:02:53 CEST] <alexpigment> i was hoping there was an easy way to set it automatically [16:03:01 CEST] <alexpigment> anyway, i'll look into it. thanks JEEB [16:03:02 CEST] <JEEB> yes, patch the libvpx wrapper :D [16:03:40 CEST] <alexpigment> <-- not a developer, but I'll see what I can do. perhaps I can look at x264 and see what -threads 0 does and try to simulate that [16:03:50 CEST] <alexpigment> *with -threads 0, i mean [16:04:04 CEST] <alexpigment> glah, too early to type or read. need coffee :) [16:04:05 CEST] <JEEB> I think libx264's auto value matches libavcodec's or so [16:04:12 CEST] <JEEB> so "it just works" [16:04:19 CEST] <JEEB> I think default was either 0 or -1 [16:04:33 CEST] <JEEB> libvpx just happens to interpret the value otherwise than all the other encoders :D [16:04:49 CEST] <alexpigment> that sounds about right [16:06:11 CEST] <JEEB> libavcodec/libvpxenc.c it seems [16:06:35 CEST] <JEEB> you can see what the wrappper passes through if you enable -v debug it seems [16:06:53 CEST] <JEEB> as I can see logging like g_threads: xxxx [16:06:55 CEST] <JC_Yang> I just encountered weird link errors, tons of undefined references when link to ffmpeg static libs, I simply can't spot the bug, any suggestions? [16:07:19 CEST] <alexpigment> yeah, i'm seeing cfg->g_threads, [16:07:25 CEST] <alexpigment> i have no idea what to do with it though [16:07:47 CEST] <JEEB> wait why is it setting the threads after dump_enc_cfg [16:07:48 CEST] <JEEB> ?! [16:07:56 CEST] <JEEB> enccfg.g_threads = avctx->thread_count; [16:08:04 CEST] <JEEB> this is *after* dump_enc_cfg(avctx, &enccfg); [16:08:09 CEST] <alexpigment> oh yeah, i'm seeing that now [16:08:21 CEST] <JEEB> and the thing logging things is the dump_enc_cfg [16:08:28 CEST] Action: JEEB scratches his head [16:08:43 CEST] <JEEB> it does the thing, but yunno :D [16:08:48 CEST] <JEEB> you logged the parameters [16:08:53 CEST] <JEEB> and *then* you set things? [16:08:54 CEST] <JEEB> :D [16:09:07 CEST] <alexpigment> to be fair, -threads [int] does do something [16:09:11 CEST] <JEEB> yes [16:09:16 CEST] <alexpigment> so it's not useless if that's what you're implying [16:09:19 CEST] <JEEB> but it probably wouldn't modify the logging [16:09:34 CEST] <JEEB> no I just see the dump_enc_cfg being called before the values are set [16:09:43 CEST] <JEEB> thus you do not set the threads in the -v debug output [16:09:44 CEST] <JEEB> I think [16:09:48 CEST] <JEEB> unless some magick is happening [16:12:36 CEST] <JEEB> I wonder if libavcodec or libavutils already has code to duplicate the auto thread stuff [16:12:54 CEST] <JEEB> or if libvpx has its own value for "auto" [16:12:57 CEST] <alexpigment> well, I know that -threads 0 does nothing to improve speed [16:13:03 CEST] <alexpigment> in the command line [16:13:07 CEST] <JEEB> yes, because zero isn't auto in libvpx [16:13:16 CEST] <alexpigment> you think -1 might be auto [16:13:17 CEST] <alexpigment> ? [16:13:33 CEST] <alexpigment> nope [16:13:56 CEST] <JEEB> no idea [16:14:02 CEST] <JEEB> you'd have to ask #vp8 or so [16:14:10 CEST] <alexpigment> k [16:14:10 CEST] <JEEB> which IIRC is the libvpx dev channel [16:14:25 CEST] <alexpigment> i'll go and bug those guys then :) [16:14:58 CEST] <holgersson> Hi! Do you know what a typical video codec for .avi files for mobile DVD players is? I tried mpeg2 and 4 and h264 so far, but all players complain they cant play the video. [16:15:03 CEST] <JEEB> I see some code for counting a thread count internally in pthread_frame.c [16:15:48 CEST] <JEEB> holgersson: there's no standard for that. you probably have more luck with creating mp4 files with H.264 and AAC (level 3, main profile - LC AAC) and testing that out [16:16:05 CEST] <JEEB> -level 3.0 -profile:v main I think with -libx264 [16:16:09 CEST] <JEEB> *-c:v libx264 [16:16:23 CEST] <JEEB> of course older things just don't support AVC/H.264 [16:16:25 CEST] <holgersson> JEEB: Thanks, Ill try. However, many players say they can play AVI. Whatever this means :D [16:16:30 CEST] <JEEB> it's a container [16:16:36 CEST] <JEEB> in other words it means absolutely nothing [16:16:42 CEST] <JEEB> container is something you put streams into [16:16:57 CEST] <JEEB> so you have a video stream and an audio stream, for example [16:16:58 CEST] <holgersson> I know, but most containers have typical defaults, lets take ogv [16:17:15 CEST] <JEEB> well ogv is an OGG specific thing :D although they try to say that they support other things as well [16:17:21 CEST] <alexpigment> don't most DVD players play DivX/XviD? [16:17:34 CEST] <JEEB> alexpigment: yes but let's not go there, finding parameters that work is surprisingly hard [16:17:47 CEST] <JC_Yang> why so many undefined references? any suggestions? [16:17:50 CEST] <JEEB> at least with AVC/H.264 if you find the profile and level [16:17:56 CEST] <JEEB> you're pretty golden [16:18:03 CEST] <alexpigment> eh, i doubt it. -c:v xvid 640x[whatever] -c:a mp3 [16:18:15 CEST] <holgersson> alexpigment: Ill try that first, thanks [16:18:17 CEST] <JEEB> I ain't supporting that :D [16:18:27 CEST] <JEEB> also it's libxvid and liblamemp3 [16:18:29 CEST] <JEEB> I think [16:18:34 CEST] <alexpigment> oh right ;) [16:18:37 CEST] <holgersson> JEEB: Im sure one HW Ill test is too old for h264 [16:18:42 CEST] <alexpigment> can you tell i haven't used those in a while? [16:18:47 CEST] <JEEB> holgersson: my condolences [16:19:15 CEST] <alexpigment> holgersson: my two cents, try xvid+mp3 inside an avi with a frame size no bigger than 640x480 [16:19:22 CEST] <JEEB> the "specs" for streams with MPEG-4 Part 2 (which is what the libavcodec mpeg4 encoder and the libxvid encoder encode) are really bad [16:19:37 CEST] <JEEB> with AVC/H.264 it gets more clear [16:19:38 CEST] <holgersson> Ò Ill try this, and tel you how it went ;) [16:19:45 CEST] <JEEB> you have a profile, which is "features used" [16:19:59 CEST] <JEEB> and then you have a level, which is "decoder requires <this> much memory to decode this stream" [16:20:03 CEST] <alexpigment> JEEB: have you seen many DVD players that support H.264/AAC? I've never seen one [16:20:09 CEST] <alexpigment> seems like a bad place to start [16:20:21 CEST] <JEEB> unfortunately I'm really out of that thing [16:20:25 CEST] <JEEB> not my finesse :D [16:20:38 CEST] <JEEB> I don't want to touch devices that can't do AVC/H.264 [16:20:43 CEST] <alexpigment> back in the early 2000s, DivX/XviD support was almost ubiquitous [16:20:48 CEST] <JEEB> I know, unfortunately [16:20:56 CEST] <JEEB> unfortunately because it was never really standardized like AVC/H.264 [16:21:07 CEST] <JEEB> as in, there was a standard but various features out of the ASP profile just weren't supported [16:22:13 CEST] <alexpigment> i haven't done any testing on this, but it seemed to play any downloaded XviD movie rips of the time ;) [16:22:25 CEST] <alexpigment> if that file was 700Mb, the file would play [16:22:36 CEST] <JEEB> yea encoder features were really stripped in most cases :D [16:22:41 CEST] <alexpigment> i don't doubt it [16:22:54 CEST] <JEEB> so there were "best practices" I guess [16:23:02 CEST] <JEEB> if you wanted to support those plastic toys [16:23:29 CEST] <alexpigment> yeah, I think the ripping groups had guidelines. the quality was crap, of course [16:23:52 CEST] <JEEB> that's something you can never fix tho, they're fighting for who gets the thing out first :P [16:24:23 CEST] <JEEB> later with x264-based rules they just standardized on certain CRF value ranges and "preset has to be slower than X" [16:24:51 CEST] <alexpigment> easy enough [16:25:04 CEST] <iive> x264 was really well polished [16:25:08 CEST] <alexpigment> -tune film, -crf 20, -preset medium = good to go [16:25:34 CEST] <alexpigment> although I guess I personally use CRF 18 for everything [16:25:43 CEST] <alexpigment> and I encode in interlaced a lot [16:25:47 CEST] <JEEB> for me it defines by content and resolution [16:25:56 CEST] <JEEB> for example 720p animation being 19.5 for some reason in veryslow [16:26:00 CEST] <JEEB> :V [16:26:14 CEST] <alexpigment> sounds fine to me [16:26:26 CEST] <alexpigment> animation compresses like crazy [16:26:28 CEST] <JEEB> yup [16:26:44 CEST] <alexpigment> you might as well bump the CRF down (and the preset down if you have the time) [16:26:55 CEST] <alexpigment> veryslow is usually too slow for my taste though [16:27:15 CEST] <iive> a lot of x264 developer were anime fans too :D [16:27:16 CEST] <JEEB> the speed is plenty fast nowadays :D [16:27:32 CEST] <iive> 's [16:27:43 CEST] <alexpigment> i suppose so. i just stick with medium because i'm old and stubborn [16:27:45 CEST] <JEEB> I wish libx265 would be worth the time I'd need to utilize with it [16:28:04 CEST] <JEEB> alexpigment: well it doesn't really remove the quality as long as you poke the CRF [16:28:07 CEST] <alexpigment> i have a sneaking suspicion that x265 isn't going to catch on anytime soon in th emainstream [16:28:27 CEST] <JEEB> they just haven't gotten their coding tools optimzied :P [16:28:28 CEST] <alexpigment> JEEB: yeah, that's why I go for CRF 18 (or sometimes 16) [16:28:40 CEST] <JEEB> I mean, people have disabled >16x16 CTUs [16:28:45 CEST] <JEEB> and gotten better visual results [16:28:51 CEST] <JEEB> same for some other tools [16:28:56 CEST] <JEEB> which in theory should be useful [16:29:23 CEST] <JEEB> a lot of the new stuff is optimized for PSNR I guess [16:29:35 CEST] <JEEB> which means less visible artifacts but more blur etc [16:29:47 CEST] <alexpigment> yeah that's true [16:29:49 CEST] <alexpigment> :( [16:30:29 CEST] <alexpigment> I rip a lot of music videos from TV (I collect music videos, which I guess is weird), and even though my cable company compresses the hell out the signal, it's still better than, say, youtube [16:30:59 CEST] <alexpigment> if not only because the macroblocks from mpeg-2 are more pleasing than the soft (but also macroblocky) look of those YouTube MPEG-4 encodes [16:31:22 CEST] <alexpigment> which I think speaks to your point about the PSNR optimization [16:31:42 CEST] <JEEB> well 'tube has its own things related to how they optimize [16:31:51 CEST] <JEEB> for youtube quality was really never a thing they valued [16:31:57 CEST] <alexpigment> that is very true [16:32:09 CEST] <alexpigment> frame rates were never valued either, sadly [16:32:15 CEST] <JEEB> if they could get something out faster while not having too much artifacts that would be herped and derped at by the general public they'd do that [16:32:41 CEST] <alexpigment> I just don't get why there isn't a 480p60 / 576p50 option [16:32:58 CEST] <alexpigment> considering the majority of broadcast history would fit into those two camps once deinterlaced properly [16:34:00 CEST] <alexpigment> so you either lose half of the motion at 480p30, OR you get bad frame cadence because they simply went from 480i30 > 480p30 [16:35:08 CEST] <iive> hum.... i've been quite happy with youtube h264 encodes. [16:35:12 CEST] <alexpigment> some days I wish my eyes/brain weren't so sensitive to quality issues, but whatever. I find YouTube nearly unwatchable [16:35:33 CEST] <iive> on the other side, h265 encodes of MeGusta are simply attrocious [16:35:55 CEST] <iive> 720p is as blurry as upscaled SDTV [16:35:56 CEST] <alexpigment> not familiar with MeGusta [16:36:31 CEST] <alexpigment> iive: anyway, YouTube is wayyy worse than something like Vimeo [16:37:19 CEST] <alexpigment> and of course, Blu-ray makes YouTube look like a complete worthless joke [16:37:49 CEST] <iive> are you sure the video you don't like are h264? because youtube/google like to push their vp9 stuff. [16:37:56 CEST] <alexpigment> positive [16:38:26 CEST] <JEEB> `youtube-dl -F "URL"` [16:38:32 CEST] <JEEB> can let you do proper comparisons [16:38:50 CEST] <iive> yep :) [16:39:59 CEST] <iive> also, I think i've heard that youtube do a quick & dirty encode and then if video is on high demand, do a better quality . [16:39:59 CEST] <alexpigment> yeah, I usually download the source for music videos which I can't get elsewhere [16:40:24 CEST] <holgersson> JEEB, alexpigment: "-map 0:0 -map 0:1 -c:v libxvid -c:a mp3 test.avi" works =) [16:40:32 CEST] <alexpigment> nice [16:40:34 CEST] <JEEB> 'grats [16:40:44 CEST] <holgersson> Its really ugly compared to the source, but thats just fine tuning [16:40:57 CEST] <alexpigment> yeah you need to set a bitrate of course [16:41:02 CEST] <holgersson> Last time I tried mpeg4 encoder which didnt work [16:41:04 CEST] <JEEB> you can just lower the quantizer or do 2pass bit rate based encoding [16:41:04 CEST] <alexpigment> or a quality factor I guess [16:41:15 CEST] <JEEB> holgersson: probably just up to the parameters :D [16:41:20 CEST] <JEEB> alexpigment: ughhh it's not *quality* [16:41:22 CEST] <JEEB> it's quantizer [16:41:48 CEST] <alexpigment> JEEB: apologies, I get the two mixed up [16:42:19 CEST] <holgersson> However -- thanks you two, you saved someones present :D [16:42:51 CEST] <JEEB> holgersson: I don't remember the exact range of sane values for libxvid, but try -q:v 4 or so? [16:43:09 CEST] <JEEB> raise the number for higher compression, lower for more bits used [16:43:33 CEST] <alexpigment> JEEB: this is going to be on DVD media presumably, so isn't -q:v probably less than ideal? [16:43:47 CEST] <alexpigment> i'd worry about the bitrate spiking over 10Mbps [16:44:04 CEST] <JEEB> right [16:44:30 CEST] <alexpigment> from my xvid days back in the day, I recall that good bitrates were between 2Mbps and 4Mbps [16:44:37 CEST] <alexpigment> assuming space isn't an issue [16:45:06 CEST] <alexpigment> (for DVD resolution content) [16:48:21 CEST] <holgersson> I dont remember DVD resolution, but the source material came from an old video casette cam corder and got digitialised to 640x480, 1629 kb/s, 24.97 fps, 25 tbr, 24.97 tbn, 49.94 tbc and some pcm audio line. [16:49:24 CEST] <alexpigment> yeah, that's DVD resolution [16:49:28 CEST] <alexpigment> effectively [16:49:52 CEST] <alexpigment> 640x480 is the square pixel version [16:50:41 CEST] <alexpigment> do you happen to know if the source file is interlaced or progressive? [16:51:13 CEST] <alexpigment> i mean the tape itself is interlaced, but it seems to have been captured in a format that might not be interlaced [16:52:04 CEST] <alexpigment> also, I just noticed the fps is 24.97. is that a typo or is it actually 24.97 rather than 29.97? [16:53:14 CEST] <holgersson> alexpigment: I copynpasted from ffmpegs output. [16:53:23 CEST] <alexpigment> weird [16:53:48 CEST] <holgersson> How can I check if its interlaced? [16:54:19 CEST] <alexpigment> I usually check that with Mediainfo [16:54:27 CEST] <alexpigment> lemme refresh myself on using ffprobe [16:56:24 CEST] <alexpigment> ffprobe -v error -show_streams [input file] [16:56:30 CEST] <alexpigment> look for the line "field order" [16:56:41 CEST] <alexpigment> this isn't 100% reliable, but it's reliable enough [16:57:12 CEST] <holgersson> alexpigment: The cam is not mine and someone (other) else converted the analog output with some digitalizer black box, and I dont know anything about this one. Neither am I sure that the file I have is *really* the naked output of that digitalizer box. [16:57:59 CEST] <alexpigment> yeah, the specs were a little weird with the frame rate, which is why I asked. I can't tell if it's meant to be NTSC or PAL or perhaps one of those hybrid variants [16:58:33 CEST] <alexpigment> it's like the opposite of PAL-M or something [16:59:00 CEST] <holgersson> I have no "field order" :D [16:59:25 CEST] <alexpigment> ok, well let's hope it's progressive :) [16:59:28 CEST] <holgersson> If it helps I - and the camera - are in/from Germany, and IIRC NTSC and PAL were a bit region specific. [17:00:00 CEST] <alexpigment> yeah, a german camera should be pal [17:00:17 CEST] <alexpigment> would I would be expecting a true source of 720x576 @ 25fps [17:01:00 CEST] <alexpigment> or if it were converted to square pixels, 768x576 or similar [17:02:08 CEST] <alexpigment> at any rate, I don't think most DVD players enforce any kind of standards on DivX/XviD, so you're probably fine [17:02:11 CEST] <holgersson> OK. Maybe the file I used as source is pre-converted and scaled to run on DVD players, just with the wrong codec. [17:02:47 CEST] <alexpigment> possibly [17:02:48 CEST] <holgersson> However, thats just speculation -- Ill just ask later today ;) [17:03:18 CEST] <alexpigment> no worries - I just wanted to make sure you wouldn't run into any quality or compatiblity issues while you're at it [17:03:33 CEST] <alexpigment> if it looks good to you, that's all that really matters [17:11:59 CEST] <Mandevil> Hello, can I reindex an AVI file? I tried ffmpeg -c copy, but it reindexes only half the source file, for some reason. [17:49:32 CEST] <newuser> Hi there, is there any GUI for the FFmpeg that allows concatenation of video clips without using the command line? [18:00:02 CEST] <Mandevil> Hm, funny using '-c:a -an' instead of '-c copy' made it work. [18:15:29 CEST] <kepstin> Mandevil: uh..? "-c:a -an" makes no sense, "-an" is not an audio codec. Did you just use "-an" by itself? [18:16:08 CEST] <kepstin> Mandevil: if that fixed the issue, then the problem is that your avi file probably has audio and video tracks which are different lengths, like the audio was half the length of the video [18:16:45 CEST] <kepstin> the behaviour of players when the audio runs out but video keeps going is... a bit unpredictable, but it's not unexpected that you wouldn't be able to seek to the later parts. [18:18:03 CEST] <kepstin> Mandevil: if you want to keep the audio track, try using "-af apad -shortest"; that'll extend the audio with silence, and make it the same length as the video track. This requires re-encoding the audio of course (can't use -c:a copy) [18:19:43 CEST] <Mandevil> kepstin: Sorry -c:v -an [18:20:30 CEST] <kepstin> "-c:v -an" doesn't make any sense either, "-an" isn't a video codec..., I assume you used "-c:v <something> -an" ? [18:20:49 CEST] <Mandevil> -an means "discard audio", as far as I know. [18:20:58 CEST] <nicolas17> yes, but -c:v is supposed to be followed by a codec [18:21:01 CEST] <Mandevil> At least that's what it does for me. [18:21:05 CEST] <kepstin> yes, but -c:v takes an argument, which is the codec name [18:21:14 CEST] <Mandevil> nicolas17: Sorry.... "-c:v copy -an" [18:21:23 CEST] <nicolas17> whole different thing :) [18:21:24 CEST] <Mandevil> Excuse, I'm just having slow day or something. [18:21:32 CEST] <kepstin> Mandevil: ok, my other comments above stand :) [18:21:57 CEST] <Mandevil> I don't really need the audio. [19:07:50 CEST] <ChocolateArmpits> If I use --disable-encoders and --enable-encoder=encoder does ffmpeg compile only the specified encoder ? [19:12:52 CEST] <JEEB> should be pretty quick to test :P but as far as I know many people use configuration parameters like that [19:13:06 CEST] <JEEB> the configure script will output enabled encoders afterwards [19:25:15 CEST] <tdr_> /nick tdr [19:54:39 CEST] <alphabitcity> Is it possible to use ffmpeg to draw a dynamic overlay on a video that changes color based on the time? e.g. the overlay is red in the morning and white in the evening [19:56:24 CEST] <alphabitcity> hm seems like there's an enable flag that can handle that. sorry/thx! [20:27:11 CEST] <DHE> ChocolateArmpits: basically yes. you can also specify multiple encoders with --enable-encoders=mpeg2video,libx264,libvpx etc. You can also use wildcards like --enable-encoders=pcm* [20:27:26 CEST] <ChocolateArmpits> cool [20:28:33 CEST] <DHE> and yes, I also use this feature EXTENSIVELY for a low profile build that only outputs in formats I need and only the filters I use [20:28:43 CEST] <DHE> (libavfilter is quite large if you don't restrict it like this) [21:29:06 CEST] <alphabitcity> Does anyone happen to know of a good tutorial/place to start for writing custom libav filters for ffmpeg? [21:30:43 CEST] <durandal_1707> alphabitcity: what filter you want to write? [21:31:19 CEST] <alphabitcity> @durandal_1707: need a filter that writes a 32x32 dynamic watermark to videos .. the watermark is based on the current timestamp [21:33:07 CEST] <durandal_1707> look at some docs in docs directory [21:33:34 CEST] <alphabitcity> ok, will look there..thank you! [21:33:37 CEST] <durandal_1707> if you need any help just ask on #ffmpeg-devel [21:50:13 CEST] <alexpigment> weird, I was doing some 4k H.264 encoding with QSV, and I noticed my system is bogged down pretty heavily [21:50:32 CEST] <alexpigment> someone was mentioning the other day that QSV has a software fallback [21:50:39 CEST] <alexpigment> does it just silently go into that mode? [21:55:18 CEST] <JEEB> alexpigment: I wouldn't be surprised if it did [21:55:41 CEST] <JEEB> I mean, nvidia's driver wouldn't tell you it was doing SW VC1 decoding with GTX 9600 either [21:58:48 CEST] <alexpigment> yeah, i think this happens when I do 4k; there's a message about partial HW acceleration [21:58:58 CEST] <alexpigment> which, frankly, is way slower than x264 [22:04:05 CEST] <kepstin> on linux, I *think* the vaapi interface to qsv doesn't support any of the sw or partial sw fallback modes, so it'll fail rather than use them. [22:04:15 CEST] <JodaZ> does anyone know if i can on demand segment encode content with ffmpeg? like generate compatible HLS/DASH segments individually, on demand - instead of a whole stream sequentially [22:04:33 CEST] <kepstin> I assume the intel media sdk library includes a whole set of software encoders/decoders. [22:06:28 CEST] <alexpigment> kepstin: I don't suppose you know of a way to force it to fail on Windows, do you? [22:10:22 CEST] <JodaZ> alexpigment, "DXVA Checker" might help you control it [22:10:36 CEST] <alexpigment> what do you mean "Control it" exactly? [22:10:39 CEST] <kepstin> it looks like the ffmpeg side could be changed to check for the 'partial acceleration' warning and fail in that case. [22:10:46 CEST] <kepstin> but that's about it [22:11:10 CEST] <JodaZ> alexpigment, i have used it to disable hardware accelerated video decoding before, DXVA is the windows api for that kinda stuff [22:11:22 CEST] <alexpigment> yeah, I guess I don't see the point of partial acceleration. it's slower and less efficient than x264 [22:11:33 CEST] <alexpigment> I've familiar with DXVA [22:11:53 CEST] <kepstin> JodaZ: we're talking about encoding, not decoding, and using qsv via hardware-specific libraries, not a generic interface like dxva [22:11:56 CEST] <alexpigment> I just didn't know if you were implying that you could use DXVA checker to prevent Intel from falling back to its software encoder [22:12:10 CEST] <furq> JodaZ: i don't think you can do that [22:12:20 CEST] <furq> you can pregenerate the chunks and generate a manifest for a subset on demand [22:12:24 CEST] <furq> but only for webm dash afaik [22:12:41 CEST] <furq> !muxer webm_dash_manifest [22:12:41 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#webm_005fdash_005fmanifest [22:13:18 CEST] <kepstin> JodaZ: are you thinking of something like generating the m3u8 playlist in advance, then having each individual .ts file generated the first time it's requested? [22:13:28 CEST] <JodaZ> kepstin, exactly [22:13:40 CEST] <kepstin> JodaZ: sure, it's possible in theory, but you'd be writing a custom app to do it using ffmpeg libraries. [22:14:31 CEST] <kepstin> and you'd have to use really fast/low latency encoder settings to make playback actually work smoothly [22:17:25 CEST] <ttpure> hey guys. I have a 6k movie (6240x2700). is there any way i can split it into two movies efficiently, where each movie has half of the screen size (3120x2700) ? [22:18:17 CEST] <ttpure> i don't want to crop twice. seems a waste [22:18:17 CEST] <JodaZ> furq, is chunk_start_index the relevant option to select the subset or how does it work? [22:43:05 CEST] <kepstin> ttpure: I don't really see how there's any way to avoid cropping twice, at least when using ffmpeg. You can do that all in a single ffmpeg command to save from decoding the video twice, though. [22:44:10 CEST] <ttpure> i thought so too [22:44:47 CEST] <ttpure> but if there was a filter that when reading each frames put them into two outputs, that would be awesome [22:45:52 CEST] <holgersson> alexpigment: Hi again, just for the record: these videos I asked earlier came are natively from this converter box. [22:46:56 CEST] <alexpigment> holgersson: gotcha. I guess it's either not PAL-friendly or just isn't following specs in general [22:46:57 CEST] <kepstin> ttpure: you mean https://www.ffmpeg.org/ffmpeg-filters.html#split_002c-asplit ? [22:46:58 CEST] <kepstin> :) [22:47:34 CEST] <alexpigment> holgersson: but again, if it looks good to you, it doesn't matter too much. I've come to learn that when something looks "wrong" to me, it usually looks fine for 99% of other people [22:47:53 CEST] <kepstin> ttpure: hmm, I'd have to check, but I think split actually shares buffers by reference between both frames, and crop doesn't actually modify the buffer (it only adjust pointers& values in the avframe), so that should be fairly efficient. [22:49:03 CEST] <holgersson> alexpigment: Well, the physical source is that old that even *there* are already glitches -.- But whatever, the conversion doesnt seem to decrease the quality much more (just increase the file size, as h264 is quite efficient.. *sigh*). [22:49:25 CEST] <holgersson> alexpigment: And yes, if it works its fine. [22:50:07 CEST] <ttpure> kepstin: that would make it great! [22:52:41 CEST] <alexpigment> guys, correct me if I'm totally off base in this assumption: aren't most (all?) HDTVs these days inherently "NTSC" (60Hz)? [22:53:36 CEST] <alexpigment> In other words, aren't "PAL" HDTVs just NTSC TVs with some extra hardware to convert 25/50fps videos to play better at 60hz? [22:53:38 CEST] <kepstin> alexpigment: depends a lot on the underlying panel, but I would expect they're normally using scalers and multisync panels which could run at either 60Hz (or a multiple) or 50Hz (or a multiple) [22:54:22 CEST] <kepstin> many better tvs also have proper 24Hz modes, too [22:54:37 CEST] <alexpigment> kepstin: well, I guess to ask my question more directly: if I have a 1080p60 video, can I be reasonably certain that any PAL HDTV that can play a 1080p50 video can also play that 1080p60 video without issue (if not perfectly)? [22:55:15 CEST] <alexpigment> I'm implying that the video player is in the TV, of course [22:55:57 CEST] <Asuran> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio "For AAC-LC: libfdk_aac > aac NOTE: as of 2017 this is no longer necessarily the case. The built in aac encoder is quite good." how good is it? [22:56:00 CEST] <kepstin> alexpigment: pretty much any TV nowadays will accept either 50Hz or 60Hz signals without issue, and play both correctly. As for using a player built-in to the tv rather than one connected via hdmi... uh...? who knows. [22:56:07 CEST] <The_8472> alexpigment, most likely. [22:56:28 CEST] <alexpigment> OK, thanks guys [22:56:36 CEST] <The_8472> if the player is meant to play random video files you could find on the web they could be of any framerate, so it has to deal with that situation [22:56:42 CEST] <ChocolateArmpits> Asuran, good for anything above 128kbps [22:56:55 CEST] <Asuran> ok thx [22:57:04 CEST] <ChocolateArmpits> anything lower and you should really consider something better, like libfdk [22:57:24 CEST] <Asuran> i wonder why -strict experimental doesnt seem to add the ability to use opus in mp4? compared to the mp4 register thingy opus is format accepted? [22:57:37 CEST] <alexpigment> The_8472: that's a good point. I guess I wanted to know if my assumption is correct that a 1080p60 video will appear more smooth on a PAL HDTV than a 1080p50 video [22:57:49 CEST] <furq> Asuran: it's not implemented yet [22:57:59 CEST] <alexpigment> The_8472: but as far as actual compatibility, your point is pretty spot on [22:58:01 CEST] <Asuran> thx then [22:58:04 CEST] <furq> or if it is, your ffmpeg is too old [22:58:29 CEST] <The_8472> alexpigment, you said "(if not perfectly)", which made it sound more like a compatibility than a quality question. [22:58:40 CEST] <furq> yeah, your ffmpeg is too old [22:58:42 CEST] <furq> it works here [22:58:48 CEST] <kepstin> alexpigment: I suspect it really varies based on the tv manufacturer. They might run the built-in player at a fixed 60Hz mode, or a 120Hz mode, or have it vary... [23:01:22 CEST] <kepstin> and someone might have forgotten to turn off the high-framerate thing on the tv, and it'll ruin everything with motion interpolation ;) [23:02:03 CEST] <Asuran> furq, its 3.3.2 [23:02:11 CEST] <furq> weird [23:02:15 CEST] <furq> i'm on 3.3 and it works here [23:02:30 CEST] <furq> oh nvm i'm an idiot [23:02:55 CEST] <furq> pro tip: smptebars is not an audio source [23:05:21 CEST] <Asuran> furq, -c:v libx265 -preset slow -crf 24 acceptable? [23:05:37 CEST] <furq> shrug [23:05:39 CEST] <furq> i've never used x265 [23:05:52 CEST] <Asuran> i tend now cuz vp9 lacks of smp [23:06:06 CEST] <Asuran> i hope av1 will do it better [23:06:14 CEST] <alexpigment> The_8472: I just meant play at true 1080p60 rather than some sort of interpolated mode to fit in at 50hz on a PAL tv [23:06:43 CEST] <alexpigment> kepstin: you might be right [23:06:54 CEST] <kepstin> alexpigment: the thing you have to remember is that the actual internal scaling & panel hardware is basically the same worldwide for modern tvs; they might have region specific analogue connectors or tuners, but that's pretty much it. [23:07:05 CEST] <alexpigment> right, that was my thought [23:07:10 CEST] <The_8472> alexpigment, that depends on your TV. check the spec sheet whether its panel supports more than refresh rate. [23:07:54 CEST] <alexpigment> The_8472: *my* tv is NTSC, and I don't have access to any PAL TVs for testing. I just have some anecdotal evidence that my theory is correct [23:09:35 CEST] <The_8472> alexpigment, there is no universal law that forces all tvs to act the same way. some can switch display framerates, some must interpolate to a fixed framerate. [23:11:44 CEST] <alexpigment> The_8472: i agree with that. the latter scenario is what I'm wondering about. do all PAL TVs that *don't* switch just internally operate at 60hz and do frame interpolation to handle PAL content correctly? [23:13:00 CEST] <kepstin> I'd hope not, given how awful frame motion interpolation looks in general [23:13:06 CEST] <holgersson> alexpigment: I get way more image artefacts in the converted avi containers, even with -q:v 1 (originally tried with -q:v3, which seems more than OK). [23:13:12 CEST] <The_8472> alexpigment, you mean 50Hz? [23:13:29 CEST] <kepstin> I wouldn't be surprised if some just run the panel at a higher fixed rate and just have timing jitter. [23:14:21 CEST] <alexpigment> The_8472: no, I'm wondering if PAL TVs that don't switch natively just run at 60Hz and have some sort of hardware to handle the PAL content in some sort of semi-intelligent way (or perhaps the TV just ends up sucking, even) [23:14:43 CEST] <The_8472> alexpigment, why would you call it a PAL tv if it runs at 60Hz instead of 50? [23:15:20 CEST] <alexpigment> The_8472: well, it would have a PAL tuner and possibly some sort of PAL frame interpolation hardware in it too [23:15:31 CEST] <alexpigment> but I would still call it a PAL TV [23:16:42 CEST] <The_8472> well, that would be crazy. of course some shitty product like that might exist. but no, normally you would not expect that kind of thing [23:17:09 CEST] <The_8472> of course we can play the "how bad could implementations possibly get and still somewhat work" game all day [23:17:46 CEST] <alexpigment> the other game we could play is "how bad does judder have to be before someone cares", and we can play that game easily at any of our parents' houses [23:18:16 CEST] <alexpigment> people are just not that discerning [23:18:48 CEST] <alexpigment> I mean I watch telecined content all the time on my 60hz TV and it doesn't even bother me, really. I realize 50>60 is worse in theory, but still [23:19:15 CEST] <The_8472> i'm just saying your questions are too broad. the product space is large. [23:19:25 CEST] <alexpigment> Yeah, I realize this [23:19:26 CEST] <The_8472> some do the right thing, some don't. [23:19:38 CEST] <alexpigment> I was just hoping someone knew the dirty truth about HDTVs [23:20:17 CEST] Action: kepstin has some ... contacts in the tv industry who've been to hdmi plugfests [23:20:39 CEST] <kepstin> but that's just from the hdmi interface side, I know nothing about the actual panels :) [23:21:01 CEST] <alexpigment> kepstin: well if you're ever having a drink with one of those friends, it may be worth asking them :) [23:21:24 CEST] <kepstin> all I know about the hdmi side is that getting the stuff certified is such a pain that they do the minimal no. of hardware implementations - just one chip for all regions, rather then multiple variations. [23:21:32 CEST] <alexpigment> "industry friend, is it true that all PAL TVs are just NTSC TVs in disguise?" ;) [23:21:56 CEST] <alexpigment> well, HDMI is a lot easier to do that I'd image [23:21:59 CEST] <alexpigment> *imagine [23:22:11 CEST] <kepstin> but the hdmi interface can run at many different clock rates, and whether the scaler and panel actually run at the same rate... ? :/ [23:22:20 CEST] <alexpigment> you just have to make sure it delivers the top tier feed you're spec'd for [23:22:36 CEST] <alexpigment> I suppose so [23:23:11 CEST] <alexpigment> I don't know how much the HDMI interface actually cares about different signals. I'll have to take your word for it [23:46:16 CEST] <Chimaera> Asuran: I have finally solved my compile issue - instead of manually compiling the x265 library, I downloaded and manually installed the .deb for libx265-dev from jessie-backports [23:46:35 CEST] <Asuran> Chimaera, ok [23:46:53 CEST] <Asuran> Chimaera, good choice i guess cuz compile yourself implies problems on distro not less times [23:47:21 CEST] <Asuran> and you can downlad pkg src and compile from this yourself with custom options [23:48:25 CEST] <Chimaera> I just need to document this for next time [23:53:44 CEST] <JodaZ> Chimaera, grab a static build ;) [23:55:20 CEST] <Chimaera> JodaZ: where's the fun in that? ;) [23:59:22 CEST] <JodaZ> the fun is in it working every time [00:00:00 CEST] --- Sat Jul 1 2017

1 0