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

[burek]

[14:01:03 CEST] <cone-819> ffmpeg 03Gyan Doshi 07master:daf38d0753a2: doc/formats: get fflags values up-to-date
[16:42:36 CEST] <jdarnley> WTF?!  Does the hflip filter actually mirror the picture or just set some metadata?
[16:43:11 CEST] <jdarnley> I encode 2 files of yuvtestsrc, one with hflip and one without.
[16:43:52 CEST] <jdarnley> When I decode them I see bugs at the left for the normal one and at the right for the hflip one.
[16:47:33 CEST] <ubitux> isn't it making negative linesizes or something?
[16:48:07 CEST] <jdarnley> For vflip, maybe, but that won't work for hflip
[16:48:52 CEST] <jdarnley> But eitherway that shouldn't be evident in the encoded file.
[17:59:13 CEST] <durandal_1707> jdarnley: how to reproduce?
[18:00:35 CEST] <jdarnley> By using the code I'm currently working on.  Not about anything in master.
[18:58:42 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:8176799f31b2: avformat/mov: Only set pkt->duration to non negative values
[18:58:42 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:16d8b13b3b26: fftools/ffmpeg: Fallback to duration if sample rate is unavailable
[18:58:42 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:28d33c252eca: ffmpeg: assert that audio packet duration in process_input_packet() is non negative
[19:07:18 CEST] <BBB> yeah lets switch our completely custom nobody-knows-how-it-works build system to something else that Ive never heard of
[19:09:35 CEST] <nevcairiel> that doesnt sound like a good argument, the only thign everyone knows is autotools and you definitely dont want that
[19:10:16 CEST] <j-b> BBB: sorry, but you are incorrect.
[19:10:21 CEST] <j-b> BBB: meson is great.
[19:10:24 CEST] <j-b> BBB: and trendy.
[19:10:26 CEST] <j-b> BBB: and sane.
[19:10:34 CEST] <nevcairiel> trendy is an argument to avoid it, in my book
[19:10:35 CEST] <nevcairiel> :D
[19:10:35 CEST] <j-b> BBB: systemd moved to it. Gnome moved to it
[19:10:43 CEST] <j-b> BBB: vlc is moving to it
[19:10:48 CEST] <nevcairiel> (also systemd is a good counter-argument against everything)
[19:10:56 CEST] <j-b> BBB: it knows what cross-compilation is
[19:11:05 CEST] <j-b> BBB: it tries to NOT be turing-complet
[19:11:12 CEST] <j-b> BBB: it can create msvc and xcode project
[19:11:16 CEST] <BBB> I dont know what any of these things mean
[19:11:19 CEST] <j-b> BBB: it uses ninja and therefore is fast.
[19:11:22 CEST] <BBB> all I know is Ive never heard of it
[19:11:33 CEST] <BBB> Ive heard of autoshit and cmake
[19:11:42 CEST] <j-b> BBB: well, expect almost everyone using autoshit to move to that.
[19:11:49 CEST] <durandal_1707> yes, meson is great
[19:12:05 CEST] <BBB> maybe Im not the target audience, but a simple meson allows you to do this using this, and with cmake itd look like that and autoshit nufsaid would be helpful
[19:12:08 CEST] <j-b> It's the first time I see a new buildsystem that I don't dismiss in 5 minutes
[19:12:21 CEST] <nevcairiel> cmake is mostly targeted at C++
[19:12:28 CEST] <j-b> BBB: you are an old Gnome guy. you are targetted.
[19:12:30 CEST] <nevcairiel> with C you get to do so many things yourself
[19:12:44 CEST] <BBB> if gnome moved to it, it cant be horrible
[19:12:49 CEST] <BBB> although they did some pretty horrid stuff
[19:12:59 CEST] <j-b> seriously, it is sane.
[19:13:02 CEST] <BBB> ok
[19:13:12 CEST] <BBB> is there a beginners guide?
[19:13:25 CEST] <nevcairiel> i'm for everything that is actually faster in configuring then the remaining build process itself
[19:13:36 CEST] <nevcairiel> seriously, running configure is slower for me now then compiling the code afterwards
[19:13:36 CEST] <j-b> it is faster
[19:13:43 CEST] <j-b> and caches correctly
[19:13:53 CEST] <j-b> and can run without bash, on Windows
[19:14:02 CEST] <nevcairiel> what was it, python?
[19:14:07 CEST] <j-b> yes
[19:14:31 CEST] <j-b> BBB: http://mesonbuild.com/Tutorial.html
[19:14:51 CEST] <j-b> nevcairiel: so, for windows, you need a python3 install and pip
[19:14:57 CEST] <j-b> then, pip install meson ninja
[19:15:08 CEST] <kierank> python3 :(
[19:15:40 CEST] <j-b> you prefer npm?
[19:15:52 CEST] <JEEB> kierank: even 14.04 has py3
[19:16:02 CEST] <kierank> I prefer python2
[19:17:12 CEST] <j-b> I don't mind the difference
[19:17:28 CEST] <JEEB> ^
[19:17:30 CEST] <nevcairiel> I don't even know the big difference anymore
[19:17:54 CEST] <nevcairiel> Except that they for some reason keep 2.7 alive still
[19:21:28 CEST] <Mathieu_Du> there's a countdown clock for it iirc
[19:21:42 CEST] <Mathieu_Du> https://pythonclock.org/
[19:57:37 CEST] <jdarnley> Configure/make replacements are a never ending source of fun and dissapointment.
[20:04:02 CEST] <iive> there has been some incompatibility in py3, so a lot of existing code needed 2.7 . but that has been long ago.
[20:04:58 CEST] <January> oh im late for the meson discussion
[20:05:43 CEST] <iive> it's never late
[20:08:53 CEST] <January> I think the thing I didn't say in my email was that it's not like it has to be an instant overhaul we could add it as an experimental build system alongside the old one
[20:10:12 CEST] <j-b> And you'll have to.
[20:10:21 CEST] <j-b> This is going to be long, to support all the cases.
[20:10:25 CEST] <j-b> and meson is still young
[20:10:38 CEST] <j-b> We found issues with macos and mingw, just yesterday
[20:12:05 CEST] <January> j-b: of course, I guess 'could' was the wrong word :D Well, let's see what people say on the ML anyway
[20:13:04 CEST] <j-b> January: sure.
[20:13:33 CEST] Action: Mathieu_Du curious if anybody actually tried to build the port already
[20:13:35 CEST] <BtbN> My MX150 does not have any de/encoding capabilities :(
[20:13:44 CEST] <Mathieu_Du> I know January did :)
[20:13:48 CEST] <BtbN> So I'll have to deal with QSV
[20:14:03 CEST] <jdarnley> Not yet.  I don't have time.  Plus I rather like my assembly.
[20:14:07 CEST] <j-b> wut? mx150 does not have PureVideo?
[20:14:13 CEST] <BtbN> Nope
[20:14:15 CEST] <BtbN> not at all
[20:14:19 CEST] <BtbN> GP108 just doesn't
[20:14:20 CEST] <j-b> o_O
[20:14:37 CEST] <BtbN> It's intended to be put into Laptops, which are always Optimus. So video de/encoding is the job of the Intel GPU
[20:15:14 CEST] <BtbN> The stupid thing about it is: If you run something on the Nvidia "High Performance" GPU, it suddenly loses all ability to hwaccel video playback
[20:15:29 CEST] <BtbN> should have at least left the decoder in...
[22:28:49 CEST] <michaelni> kierank, you need to fill out the evaluation for your gsoc student. All the admins are receiving "urgent" warning emails from google about this.
[22:29:01 CEST] <kierank> I have until tomorrow
[22:29:05 CEST] <michaelni> yes
[22:29:13 CEST] <kierank> so there is no issue
[22:34:36 CEST] <michaelni> no, but if something prevents you from filling it out, it might become narrow for one of the admins to do it before the deadline
[22:48:10 CEST] <kierank> well it is my holidays today
[23:50:56 CEST] <atomnuker> BBB: ffs did you even spend a minute to check out the repos or are you like our close-minded friend nic george here?
[23:51:11 CEST] <BBB> :(
[23:51:12 CEST] <atomnuker> the idea isn't to replace build systems
[23:51:29 CEST] <atomnuker> its to add a new one and still support the custom configure script
[23:51:42 CEST] <nevcairiel> maintaining  two in parallel  only has downsides though
[23:51:48 CEST] <BBB> I know that, I specifically mentioned cmake
[23:52:17 CEST] <BBB> (which libaom uses as configure replacement, right?)
[23:52:25 CEST] <atomnuker> its like mentioning the nuke at a radiation cancer treatment summit
[23:52:49 CEST] <BBB> Im sorry I offended you
[23:52:56 CEST] <atomnuker> no, you didn't
[23:53:25 CEST] <atomnuker> libaom did indeed switch to cmake and its just as awful as you might think it is
[23:54:11 CEST] <atomnuker> maintaining 2 build systems is okay though, we can add a test comparing their outputs
[23:54:48 CEST] <atomnuker> in theory they should match provided there are no differences in what they were compiled with
[23:55:19 CEST] <BtbN> We could indeed just re-write configure in something faster. Like, C.
[23:55:23 CEST] <atomnuker> and I don't mind meson support lagging behind, its not hard to add support
[23:55:31 CEST] <atomnuker> I wouldn't mind that either tbh
[23:55:43 CEST] <nevcairiel> and what configures the C compiler for configure.c?
[23:55:43 CEST] <nevcairiel> :D
[23:56:00 CEST] <BtbN> dependency-less C that can be built with a trivial Makefile
[23:56:19 CEST] <nevcairiel> with all the different compilers we support?
[23:56:43 CEST] <BtbN> Yeah, it will get a mess quickly
[23:56:50 CEST] <BBB> you also need to compile bash to run configure
[23:56:59 CEST] <BBB> who set up the compiler for that?
[23:57:01 CEST] <nevcairiel> bash comes pre-compiled :p
[23:57:11 CEST] <BBB> for your system maybe; I USE GENTOO!!!
[23:57:20 CEST] <BBB> (I dont :-p)
[23:57:21 CEST] <nevcairiel> that has magic to set itself up
[23:58:37 CEST] <BtbN> a python script or something would probably be more practical, but a build system in C would be kinda neat, but probably not overly practical
[23:59:08 CEST] <atomnuker> a python script would be just as slow probably, maybe slower
[23:59:20 CEST] <nevcairiel> the problem with a compiled build system is that you basically need a build system to build it =p
[23:59:30 CEST] <BtbN> it wouldn't need to fork thousands of times for the most trivial operations
[23:59:32 CEST] <nevcairiel> bash so so freaking slow because of all the forking
[23:59:40 CEST] <nevcairiel> any actual scripting language would be much faster
[23:59:54 CEST] <Mathieu_Du> Not that anyone asked, but my humble opinion is that if the meson port were to be merged in, it should be with the eventual goal of making it the single build system, a lengthy transition period would be mandatory, but maintaining two build systems for ever indeed seems sub optimal to me :)
[00:00:00 CEST] --- Fri Jun 15 2018