[Ffmpeg-devel-irc] ffmpeg-devel.log.20170701

[burek]

[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.h
[22:46:51 CEST] <Tarmik> https://sourceforge.net/p/vlc2/code/HEAD/tree/extlibs/ffmpeg/config_windows.h
[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/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit )
[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-3117ea361a07/run-demo-test-application-on-samsung-galaxy-s6-runas-could-not-set-capabilities-operation-not?forum=vcgeneral
[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/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rClyknBj5zHU/edit#heading=h.qm9m5e7jipnj
[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 at 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