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

[burek]

[00:19:42 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:9a8034b8bc1d: doc/demuxers: Document enable_drefs and use_absolute_path
[00:19:43 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:8e32d014322e: avformat/concat: Check protocol prefix
[00:19:44 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:15cc98a0f38a: avformat/libquvi: Set default demuxer and protocol limitations
[00:22:56 CET] <kierank> libquvi
[00:23:01 CET] <kierank> ...
[00:26:37 CET] <atomnuker> I can't even remember when its development stopped
[00:27:06 CET] <rcombs> mpv replaced it with youtube-dl
[00:27:09 CET] <rcombs> things are better now
[00:27:50 CET] <kierank> I'm sending a patch to remove that
[00:28:19 CET] <wm4> the developer of libquvi simply disappeared (it's a bit scary)
[00:28:50 CET] <J_Darnley> The web streaming cabal whacked him!
[00:36:40 CET] <BBB> he probably got hired by some big company
[00:59:37 CET] <Plorkyeran> didn't he go insane and try to relicense to agpl first or something?
[01:27:39 CET] <J_Darnley> What happened with alldevices and msvc fate clients?
[01:32:03 CET] <nevcairiel> hm who knows
[01:32:58 CET] <nevcairiel> probably the makefile patch from andreas
[01:35:32 CET] <BBB> jya: poke
[01:35:49 CET] <BBB> probably off for the weekend...
[01:35:50 CET] <BBB> hmm...
[01:47:08 CET] <kierank> hopefully I'll get some support for this piece of crap getting removed
[01:48:38 CET] <atomnuker> with that description?
[01:49:28 CET] <kierank> well lets see if certain people (tm) can behave like adults
[01:50:50 CET] <atomnuker> with that description? even I'm not sure what to say
[01:51:07 CET] <kierank> it's a removal what do you want me to say
[01:51:19 CET] <atomnuker> see the libstagefright message
[01:51:45 CET] <kierank> it's notably so easy to add crap to ffmpeg
[01:51:47 CET] <kierank> but so hard to remove crap
[01:53:03 CET] <atomnuker> less than 5 minutes to write a proper commit message is hard?
[01:53:40 CET] <atomnuker> it doesn't even have to be completely true just as long as it's somewhat not-false
[01:54:37 CET] <kierank> ah yes let's discuss silly things instead of the actual content
[01:54:49 CET] <kierank> classic ffmpeg diversionary tactic
[01:54:59 CET] <kierank> what colour is your bikeshed
[01:57:25 CET] <atomnuker> okay, someone opens up the commit log and sees "libquvi removed" with the commit message "$subj"
[01:58:17 CET] <atomnuker> and before that is a nicely explained bugfix
[01:59:18 CET] <atomnuker> what are they going to think?
[01:59:51 CET] <atomnuker> one thing they'd do is they'd read the author's name and do some associations
[02:00:28 CET] <jamrial> atomnuker: "libquvi is a dead project and hasn't worked on its supported sites for months"
[02:00:43 CET] <jamrial> that should be enough as a commit message
[02:00:50 CET] <atomnuker> another thing is they'd just do what you do - just assume the project's developers are so lazy they couldn't even write up a proper commit message
[02:01:07 CET] <atomnuker> there, see, a nice coherent, to the point sentence
[02:04:17 CET] <kierank> atomnuker: your idol carl does exactly this
[02:08:03 CET] <jamrial> can we not start a flamewar out of something as stupid as a commit message?
[02:08:47 CET] <TD-Linux> the bikeshed should be ON FIRE
[02:10:10 CET] <atomnuker> I blame the "FFmpeg is shit" meme
[02:12:59 CET] <atomnuker> making it worse "because why should I, it's shit" and then continuing to complain is what gets me
[02:18:45 CET] <kierank> yes but  you fuel the bigger problems by splitting hairs
[02:19:04 CET] <kierank> because it adds noise to whole development process and trying to get stuff done
[02:19:16 CET] <kierank> jamrial did exactly what was necessary
[02:19:18 CET] <kierank> it will be fixed
[02:19:18 CET] <kierank> that's iot
[02:19:37 CET] Action: J_Darnley shouldn't be enjoying this
[02:19:54 CET] <BBB> so uhm, if all msvc builds are broken
[02:19:57 CET] <BBB> maybe revert that patch?
[02:20:45 CET] <nevcairiel> probably only out of tree builds, but thats the only thing fate tests
[02:21:02 CET] <jamrial> we could give Andreas some time to see if he can fix it
[02:23:18 CET] <kierank> Any idea what could be causing these weird RGB halos?
[02:23:23 CET] <kierank> https://usercontent.irccloud-cdn.com/file/fDNvLZ0m/
[02:23:35 CET] <kierank> right is what appears to be a sane looking yuv422p file
[02:23:39 CET] <kierank> left is the rgb version
[02:23:44 CET] <J_Darnley> Weird Al looking extra weird!
[02:24:06 CET] Action: J_Darnley needs to stop shit posting
[02:27:31 CET] <jya> BBB: yes?
[02:32:16 CET] <atomnuker> kierank: looks like an overflow
[02:32:54 CET] <kierank> yes ofc
[02:33:03 CET] <TD-Linux> a busted resampling filter?
[02:33:55 CET] <TD-Linux> though luma looks broken too
[02:36:40 CET] <kierank> atomnuker: no top posting =p
[02:36:53 CET] <kierank> it's low bitrate
[02:36:59 CET] <kierank> so luma might need to look like that I dunno
[02:42:27 CET] <cone-711> ffmpeg 03Michael Niedermayer 07master:f502583663eb: avcodec/mpeg4videoenc: Use 64bit for time variables
[02:49:54 CET] <TD-Linux> kierank, oh that's before and after compression too?
[02:50:00 CET] <kierank> no
[02:50:02 CET] <kierank> the same source
[02:50:08 CET] <kierank> one with yuv decoding which works
[02:50:11 CET] <kierank> other is rgb which doesn't
[03:08:06 CET] <BBB> jya: sent email instead :)
[04:11:47 CET] <kierank> do we have a 12-bit gbrp
[04:23:24 CET] <jamrial> looks like we do
[04:23:40 CET] <jamrial> at least in pixfmt.h
[04:23:54 CET] <jamrial> avutil
[04:24:01 CET] <jamrial> no idea about swscale
[04:24:35 CET] <jamrial> a quick grep says yes
[04:29:23 CET] <kierank> ooh that makes it look quite good
[04:29:53 CET] <kierank> https://usercontent.irccloud-cdn.com/file/f0s8GpmM/
[04:29:55 CET] <kierank> wtf that weird border is I have no idea
[04:38:35 CET] <kierank> looks like I have to add a GBRAP12
[04:40:35 CET] <jamrial> ^looks like that ticket has a hint to solve Andreas' problem :p
[04:44:59 CET] <kierank> ffplay shows different artefacts  to other players
[10:28:23 CET] <wm4> nevcairiel: you said there's a hack that somehow serializes hwaccel access on mt to a degree?
[10:54:29 CET] <wm4> also, can someone send a patch to remote the old vdpau decoder?
[10:54:47 CET] <durandal_1707> but carl
[12:02:17 CET] <nevcairiel> wm4: it does that today yes, by only allowing one thread to execute at a time, but that only serializes inside avcodec, as soon as avcodec_decode_video returns the next thread runs, so while its internally serizalized, its still in parallel to whatever your user code does, which is where the problems come from
[12:20:51 CET] <nevcairiel> so now he runs out of arguments and just threatens to push it anyway?
[12:23:10 CET] <wm4> would the compromise be allowing MT only for some codecs? (vaapi or vdpau, whatever he uses and which he judged as probabilistically working)
[12:24:46 CET] <wbs> do I understand it correctly that it theoretically can work for dxva as well, if the caller does some complicated locking (as vlc apparently does)?
[12:24:50 CET] <nevcairiel> that doesnt really solve the underlying issues and still requires someone to refactor the vp9 hwaccel since we have a vaapi for that
[12:24:57 CET] <nevcairiel> wbs: yes
[12:25:18 CET] <nevcairiel> but its really kinda complex  so not something anyone should be doing
[12:25:24 CET] <wbs> well vlc apparently wants to
[12:25:28 CET] <wbs> why not let them, then?
[12:25:45 CET] <wbs> something like a "I really know what I'm doing" flag or so
[12:25:46 CET] <nevcairiel> because it requires us to make sure it keeps working
[12:26:24 CET] <wbs> sure
[12:26:34 CET] <wbs> just wanted to check that, so I know what to think of all the discussion, I won't be taking part
[12:27:50 CET] <wm4> nevcairiel: so can dxva really not read back while the surface is in use as reference picture?
[12:28:08 CET] <nevcairiel> its the other way around, it cannot use it as a reference if its locked for readback
[12:28:13 CET] <nevcairiel> but only on some drivers, not all
[12:29:42 CET] <wm4> how inconvenient, could lead to random corruption when taking screenshots and using direct rendering (at least the way I'd implement it)
[12:57:13 CET] <nevcairiel> i only ever lock them on the same thread as the decoding runs to avoid that, if i use direct rendering they get passed to the video renderer as-is which processes them into rgb before any such thing as screenshotting
[12:59:40 CET] <wm4> maybe this could be solved by copying the surface to another surface? although that might not be wanted during normal decoding, as it might make it slower
[13:00:15 CET] <nevcairiel> you could probably avoid this particular problem by doing that, yes
[13:00:47 CET] <wm4> but it would be slower? (I'm thinking that this copy could also take care of copying it to system ram, so maybe it would not matter?)
[13:01:11 CET] <wm4> or you could leave the second surface locked, and use its memory directly (again assuming it's in system ram)
[13:01:30 CET] <nevcairiel> would probably end up slower, depends how much free memory bandwidth your gpu has
[13:02:37 CET] <nevcairiel> cant say I have ever done this, so..
[13:03:05 CET] <davnik> Hello, I am trying to remove the watermark from a video using the --delogo option
[13:03:16 CET] <davnik> http://snag.gy/B5BUv.jpg
[13:03:27 CET] <davnik> Could anyone please give me the proper coordinates to use here?
[13:03:57 CET] <wm4> davnik: wrong channel
[13:04:34 CET] <davnik> wm4, I posted on #ffmpeg no response ;-)
[13:06:17 CET] <wm4> then wait there
[13:06:29 CET] <wm4> this is a development channel
[13:09:53 CET] <BBB> kierank: yes, we support up to 14bpp in swscale (was needed for >8bpp h264 support in fate)
[13:10:18 CET] <BBB> kierank: since fate tests by md5 and the endianness needed to be standardized for fate to test >8pp stuff
[13:10:34 CET] <kierank> BBB: it looks funny though in ffplay
[13:10:48 CET] <kierank> In other viewers it looks better
[13:11:09 CET] <BBB> its possible some conversions are a little questionable
[13:11:10 CET] <kierank> I blame swscale
[13:11:17 CET] <BBB> thats reasonable
[13:11:25 CET] <kierank> Only RGB looks weird
[13:11:42 CET] <BBB> I believe the >8bpp support in swscale uses intermediates that scale up to 14bpp to fit the complete inside width internally
[13:11:49 CET] <BBB> I forgot how it works exactly
[13:11:54 CET] <BBB> so 14bpp may overflow
[13:11:57 CET] <BBB> sometimes
[13:19:07 CET] <wm4> what looks weird?
[13:19:37 CET] <JEEB> depending on the format, you might be able to use the zscale filter instead of swscale
[13:19:53 CET] <JEEB> which uses the zimg scaler/colorspace conversion library
[13:21:39 CET] <durandal_1707> shame swscale is not rewriten and added float pixel format
[13:24:55 CET] <kierank> I don't actually need to scale - I just need to add a comment saying don't use ffplay to debug this decoder
[13:25:23 CET] <nevcairiel> figuring out why its broken would still be useful though
[13:26:05 CET] <ubitux> ffplay = sdl broken yuv, no?
[13:26:50 CET] <wm4> also forces libswscale
[13:32:49 CET] <Daemon404> output to rgb via vf_zscale?
[13:32:50 CET] Action: Daemon404 runs
[13:35:58 CET] <cone-684> ffmpeg 03Hendrik Leppkes 07master:406f30072e4e: dxva2_h264: fix reference field marking in long slice struct
[13:37:18 CET] <wm4> nevcairiel: so, how about that dxva hevc10 support?
[13:54:49 CET] <nevcairiel> I thought again about just skipping any flag or such to enable it, since that just feels ugly, but I already see someone yelling at me for breaking vlc again =p
[13:55:48 CET] <wm4> lol
[13:56:05 CET] <wm4> vlc seem to have pretty advanced dxva support
[13:56:10 CET] <wm4> for supporting windows store I guess
[13:56:13 CET] <nevcairiel> not really
[13:56:24 CET] <nevcairiel> its profile checks are adequate at best
[13:57:19 CET] <nevcairiel> although it would probably not break from enabling hevc10 since it seems to check for that specifically
[13:58:44 CET] <wm4> ah I see, they still have their old d3d9 code around
[13:59:31 CET] <nevcairiel> interestingly,  microsoft updated the vp9 dxva spec to allow profile 2 decoding as well (420 10-bit)
[13:59:42 CET] <wm4> (actually no idea how that vlc code works now...)
[14:01:03 CET] <wm4> anyway... either we potentially "break" API users, or we add a new private option
[14:01:09 CET] <wm4> we just have to make a choice
[14:02:14 CET] <nevcairiel> private options on the "host" codec seem like a rather terrible choice
[14:02:29 CET] <nevcairiel> personally I would add a flag to the dxva_context, but alas it doesnt have an allocation function, sooo...
[14:02:50 CET] <nevcairiel> should probably add that for the next bump
[14:06:56 CET] <wm4> also an option: add a new function, that sets an internal flag somewhere
[14:07:12 CET] <wm4> meh I'd just "break" it
[14:07:40 CET] <wm4> if the hevc standard would add new 8 bit profiles they'd also break, so what
[14:09:08 CET] <nevcairiel> speaking about profiles, for some reason our hevc decoder doesnt list any of the new profiles
[14:09:11 CET] <nevcairiel> i should add those
[14:09:47 CET] <wm4> which new profiles?
[14:10:20 CET] <nevcairiel> version 2
[14:10:24 CET] <nevcairiel> https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Version_2_profiles
[14:10:46 CET] <wm4> urgh multiview
[14:11:38 CET] <Compn> is that 3d or angles ?
[14:11:59 CET] <wm4> "The Screen-Extended Main profile allows for a bit depth of 8-bits per sample with support for 4:0:0 and 4:2:0 chroma sampling."
[14:12:11 CET] <wm4> this one sounds like a new yuv420p profile
[14:13:04 CET] <nevcairiel> ah profiles in hevc are all kinds of confusing
[14:13:19 CET] <nevcairiel> the version 2 profiles set profile = 4 and indicate their features in extra bits
[14:13:59 CET] <nevcairiel> and there is profile = 5 for "high througput" profiles, ie 444 16 intra
[14:14:28 CET] <BBB> kierank: can you give me a file and a ffplay commandline to reproduce?
[14:14:39 CET] <BBB> kierank: I can assist in fixing the bug regardless of whether you care
[14:14:55 CET] <kierank> have to get the cfhd decoder in first
[14:14:57 CET] <kierank> and working
[14:19:02 CET] <BBB> ok
[14:19:04 CET] <BBB> let me know
[14:28:42 CET] <kierank> very likely the cause
[14:28:43 CET] <kierank> [auto-inserted scaler 0 @ 0x7fac980024c0] w:640 h:608 fmt:gbrp12le sar:0/1 -> w:640 h:608 fmt:yuv420p sar:0/1 flags:0x4
[14:29:12 CET] <wm4> mpv can render this format directly with vo_opengl (but don't ask me if it's correct)
[14:29:14 CET] <nevcairiel> the new sdl2 ffplay should be able to make saner choices
[14:29:24 CET] <nevcairiel> at least render to rgb32 instead of yuv420
[14:30:06 CET] <kierank> I tried implementing gbr12 in a yuv viewer but it looks different
[14:30:11 CET] <kierank> so I wonder if that conversion is getting botched
[14:30:16 CET] <kierank> and the material isn't gbr
[14:30:35 CET] <wm4> did you make sure the upper bits are zero?
[14:31:27 CET] <kierank> no
[14:31:30 CET] <kierank> might have to
[14:31:50 CET] <kierank> the difference is much better in the yuv viewer but the planes are in the wrong order
[14:31:56 CET] <kierank> not sure what permutation gives you the right picture
[14:48:30 CET] <kierank> one of the viewers is wrong and I have no idea why
[14:49:24 CET] Action: kierank tries imagej
[14:53:45 CET] <kierank> starting to think it's a hardware issue
[14:57:45 CET] <kierank> only one that looks right in the viewer is GRB
[14:58:01 CET] <kierank> but then i flip the planes in the decoder to GBR and the viewer isn't happy
[14:58:04 CET] <kierank> ffplay looks ok though
[17:46:05 CET] <durandal_170> vapoursynth filters never check malloc return value
[17:49:22 CET] <wm4> aren't most of them written in C++
[17:53:12 CET] <Daemon404> wm4, no
[17:53:16 CET] <Daemon404> most i see are c
[17:53:19 CET] <Daemon404> durandal_170, which ones?
[17:53:26 CET] <Daemon404> if theyre ported from avisynth, i am not surprise.d
[17:53:36 CET] <wm4> ah, lol
[17:54:52 CET] <durandal_170> vs_aligned_malloc
[17:57:45 CET] <Daemon404> durandal_170, i dont follow
[17:57:50 CET] <Daemon404> it's just a malloc wrapper
[17:57:55 CET] <Daemon404> its up to teh caller to check
[17:58:40 CET] <durandal_170> yes, and nnedi3 never check it
[17:58:50 CET] <Daemon404> nnedi3 is a port from avisynth
[17:58:50 CET] <Daemon404> so
[17:58:53 CET] <Daemon404> [16:53] <@Daemon404> if theyre ported from avisynth, i am not surprise.d
[17:58:58 CET] <Daemon404> avisynth code is horrible
[18:00:02 CET] <durandal_170> Looking how fast I can port random filter, fast and ugly way
[18:28:24 CET] <vincentdumont> Hello everyone! I am seeking to help the open source ffmpeg community. I would be glad to contribute to this wonderful project so feel free to visit my website (www.vincentdumont.com) in order to have more information about me. Thank you in advance!
[18:33:32 CET] <kierank> What are you interested in doing?
[18:39:52 CET] <vincentdumont> I can work on C or C++ level
[18:40:50 CET] <vincentdumont> But I would also be interested in web development 
[18:41:04 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:7fc944df1583: fate/ffmpeg: Fix colorkey test failure without samples
[18:41:05 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:d8637853795e: avfilter/vf_convolution: Use av_clip_uint8()
[18:43:28 CET] <Daemon404> vincentdumont, you should pick a thing to work on or figure out which bits you'd enjoy working on. (when in doubt, there is the bug tracker, i suppose.)
[18:45:22 CET] <Compn> we need a list of stuff to work on :P
[18:45:33 CET] <Compn> we keep getting volunteers
[18:45:45 CET] <Daemon404> the wiki / small tasks lists is probably sorta kinda maybe useful
[18:45:47 CET] <Compn> j-b : how does videolan organize new contributors ?
[18:45:58 CET] <Compn> Daemon404 : you guys hate on those wiki pages all the time ! :P
[18:46:06 CET] <Daemon404> Compn, thats not on our wiki
[18:46:09 CET] <Daemon404> it's multimediawiki
[18:46:13 CET] <Daemon404> i hate on our wiki ;)
[18:46:58 CET] <Daemon404> ... last updated may 2014
[18:47:02 CET] <Daemon404> mayeb not as useful.
[18:47:05 CET] <vincentdumont> Okay I am going to search for a good list of bugs then, thank you for your time!
[18:47:40 CET] <Compn> Daemon404 : unfortunately i think everyone kind of abandoned multimediawiki
[18:47:51 CET] <Compn> scorched earth...
[18:49:28 CET] <kierank> you could also try fuzzing a simple codec
[18:49:32 CET] <kierank> that's a nice way to understand things
[18:49:39 CET] <Daemon404> do we have a guide for that
[18:49:43 CET] <Daemon404> i was sure we did.
[18:50:36 CET] <kierank> libav does
[18:52:57 CET] <fritsch> libav also enables frame threading ....
[18:52:59 CET] <fritsch> not an argument :-)
[20:23:48 CET] <jkqxz> wm4:  The codec/profile problem isn't sensibly fixable.  We want FATE to work, and some of those streams declare unhelpful profiles (most obviously H.264 extended) but work anyway with a technically-incompatible profile (there, H.264 main).  Hence I kept the dubious fallback, though I removed the default promotion.
[20:26:32 CET] <wm4> jkqxz: then there should be an option to override it, and the FATE tests should add it (also, since when do we test hwaccel with FATE?)
[20:27:09 CET] <nevcairiel> not automatically, but you can run it manually
[20:27:11 CET] <nevcairiel> its kinda helpful
[20:28:07 CET] <J_Darnley> durandal_170: doesn't nnedi need some or other training data?
[20:28:55 CET] <wm4> nevcairiel: does this mean the other hwaccels don't check profiles properly?
[20:28:57 CET] <durandal_170> J_Darnley: yes, you give it as arg to filter
[20:29:04 CET] <J_Darnley> ah
[20:30:20 CET] <Daemon404> that makes it pretty useless
[20:30:24 CET] <Daemon404> if you have to supply your own
[20:30:31 CET] <Daemon404> needi's selling point is its specific trauining data
[20:30:34 CET] <Daemon404> nnedi*
[20:30:46 CET] <Daemon404> no otehr set will ever be use.d
[20:30:49 CET] <Daemon404> (loltypos)
[20:31:27 CET] <nevcairiel> wm4: like how, hwaccels dont check profiles, heck the majority of them dont even want to know what the profile is, the hwaccels just give it the data they ask for, its the user apps responsiblity to chekc
[20:32:29 CET] <durandal_170> Daemon404: distributing data with ffmpeg is pointless
[20:32:30 CET] Action: J_Darnley wonders if someone will complain about not checking the return of fclose.
[20:32:45 CET] <Daemon404> durandal_170, its point is to make it actually usable
[20:32:53 CET] <Daemon404> id say thats a pretty big point.
[20:32:54 CET] <wm4> nevcairiel: yes but in this case ffmpeg.c is the app?
[20:33:08 CET] <durandal_170> > /dev/null
[20:33:10 CET] <nevcairiel> ffmpeg_dxva2.c checks the profile for h264 at least
[20:33:27 CET] <wm4> Daemon404: the problem with it is that the data is so huge
[20:33:34 CET] <J_Darnley> Tut tut!  Using "long" in this day and age.
[20:34:03 CET] <Daemon404> wm4, yes but then you end up with users wondering a) why the hell it does nothing or b) confused as hell c) askign where to even get the data
[20:34:04 CET] <wm4> although mpv's nnedi support uses a subset, so it's only 158KB
[20:34:11 CET] <wm4> (still that's a hard increase in binary size)
[20:34:14 CET] <durandal_170> it is fast and fury port
[20:34:48 CET] <J_Darnley> And that was a fast review.
[20:35:18 CET] <Daemon404> this is just yet another inherent problem of the "giant monolithic filyter library" approach
[20:35:29 CET] <wm4> Daemon404: definitely
[20:35:30 CET] <Daemon404> cant increase size with useful things! my precious mb!
[20:35:31 CET] <jkqxz> Heh, extent of profile checking in ffmpeg_dxva2.c: "if (s->codec_id == AV_CODEC_ID_H264 && (s->profile & ~FF_PROFILE_H264_CONSTRAINED) > FF_PROFILE_H264_HIGH) { fail; }".  Am I a naughty person if I copy that?
[20:35:48 CET] <wm4> but, ffmpeg and defining APIs that don't need ABI changes a month after...
[20:36:04 CET] <Timothy_Gu> jkqxz: are the incorrect results observable for libva's reference decoder as well?
[20:36:14 CET] <wm4> jkqxz: I guess there's no problem with that if it works
[20:36:31 CET] <Daemon404> wm4, ... i just went to google my lavfi email
[20:36:34 CET] <Daemon404> its 4 years old now
[20:36:36 CET] <Daemon404> hot damn.
[20:36:42 CET] <wm4> heh
[20:36:51 CET] <wm4> I remember that mail
[20:37:23 CET] <nevcairiel> jkqxz: technically you would probably want to blacklist baseline as well, but you know the deal with baseline, so
[20:38:47 CET] <Timothy_Gu> jkqxz: also we usually type a space after `if`, `while`, and other keywords
[20:38:53 CET] <jkqxz> Timothy_Gu:  Don't know.  I thought of trying that, but it needs some set of otherwise-useless code written to test.  I was rather hoping for a hint around what is interesting about cvfc1_sony_c and others.
[20:38:56 CET] <durandal_170> Daemon404: enjoying yourself?
[20:38:59 CET] <Daemon404> ...?
[20:39:34 CET] <durandal_170> googleing own mails?
[20:40:06 CET] <Daemon404> sure why not. all the poitns from 4 years ago are still relevant to lavfi today.
[20:40:28 CET] <Daemon404> although now i would add a few more to the list.
[20:40:29 CET] <durandal_170> they are not
[20:40:30 CET] <Timothy_Gu> jkqxz: ah. Cool then
[20:40:37 CET] <Daemon404> durandal_170, i can only disagree,
[20:40:45 CET] <wm4> jkqxz: anyway, I'll try to review tomorrow
[20:40:51 CET] <jkqxz> Timothy_Gu:  Then you are all crazy people.  (Habits of a lifetime.  I can fix it with sed if you care strongly.)
[20:41:43 CET] <durandal_170> Daemon404: what would you add?
[20:42:11 CET] <Daemon404> durandal_170, the first that comes to mind is the way it pushes/pulls frames
[20:42:16 CET] <Daemon404> e.g. going fro ma very very low fps to a higher one
[20:42:18 CET] <Daemon404> buffers a LOT
[20:42:20 CET] <Daemon404> and uses a lot of memory
[20:42:24 CET] <Daemon404> causes OOM kills sometimes
[20:42:36 CET] <Daemon404> so point: buffering problems.
[20:44:17 CET] <wm4> wasn't there a lot done on frame scheduling
[20:44:28 CET] <durandal_170> Daemon404: huh, what buffers? Specific filter?
[20:44:41 CET] <Daemon404> wm4, we still regularily get OOM kills in prod
[20:44:48 CET] <Daemon404> durandal_170, vf_fps
[20:46:01 CET] <durandal_170> hmm, it just clones or drops frames, it shouldn't allocs so much memory
[20:46:25 CET] <Timothy_Gu> jkqxz: lol you can do whatever you feel like. I (nor most of us) have strong opinions on it anyway
[20:46:45 CET] <Daemon404> durandal_170, i think it has something to do with the way it's used in ffmpeg.c, but i am not sure
[20:47:29 CET] <Daemon404> [output stream 0:0 @ 0x7f9c68d00900] 1000000 buffers queued in output stream 0:0, something may be wrong.
[20:47:33 CET] <Daemon404> this kind of stuff is always in the logs
[20:47:52 CET] <durandal_170> Daemon404: what fps args you used?
[20:48:46 CET] <Daemon404> i dont have any on my at this very moment...
[20:48:53 CET] <Daemon404> but it generally happens when you have stuff like
[20:48:59 CET] <Daemon404> 10 seconds of 25 fps content with some intro
[20:49:04 CET] <Daemon404> then 1-2 hours of a single, static frame after
[20:49:12 CET] <Daemon404> VFR, of course.
[20:49:21 CET] <Daemon404> so that last 1-2 frames is some incredibly low fps.
[20:49:55 CET] <Daemon404> durandal_170, i assume you missed my response
[20:50:22 CET] <durandal_1707> I lost you at stuff like
[20:50:38 CET] <Daemon404> [19:48] <@Daemon404> 10 seconds of 25 fps content with some intro
[20:50:38 CET] <Daemon404> [19:49] <@Daemon404> then 1-2 hours of a single, static frame after
[20:50:39 CET] <Daemon404> [19:49] <@Daemon404> VFR, of course.
[20:50:39 CET] <Daemon404> [19:49] <@Daemon404> so that last 1-2 frames is some incredibly low fps.
[20:51:00 CET] <Daemon404> it's unfortunately common for seminars and talks
[20:54:22 CET] <Daemon404> pfff
[20:54:42 CET] <JEEB> cool connection
[20:54:44 CET] <durandal_1707> so fps filter should make it cfr
[20:54:55 CET] <Daemon404> yes
[20:55:12 CET] <Daemon404> but then it has to duplicate that final static frame a bazillion times
[20:56:27 CET] <durandal_1707> but it keeps buffering it but never allowing buffersink to pick it
[20:56:55 CET] <Daemon404> i am not familiar enough with the internals of lavfi to say if thats correct or not
[20:57:04 CET] <Daemon404> i just know the end result is an OOM kill
[20:58:11 CET] <durandal_1707> something similar happens with zoompan
[21:13:00 CET] <jamrial> looks like the out-of-tree patch also broke hardcoded tables builds
[21:13:50 CET] <cone-684> ffmpeg 03Michael Niedermayer 07master:0be4377333d8: fate/cabac: replace uninitialized bytes by random bytes
[21:24:01 CET] <BBB> so is that patch being reverted?
[21:30:48 CET] <jamrial> Andreas fixed checkasm, but msvc is still broken. so yeah, it should be reverted until a solution is found
[21:42:05 CET] <jamrial> meant to say checkheaders
[21:50:11 CET] <cone-684> ffmpeg 03Andreas Cadhalpun 07master:f503022ce56a: build: fix make checkheaders in out-of-tree builds
[21:52:43 CET] <BBB> especially because it sounds, from the discussion so far, that the whole point of the patch (making in/out tree bitexact) is fundamentally not possible with msvc
[21:53:24 CET] <BBB> so at least well need a conditional pre-patch makefile codepath for msvc, and that probably means a full revert for simplicity purposes
[22:21:18 CET] <J_Darnley> Is using MSVC through Cygwin supported?
[22:21:27 CET] <J_Darnley> If so that patch would fail.
[22:21:40 CET] <J_Darnley> Cygwin's pwd doesn't have -W
[22:22:38 CET] <J_Darnley> Maybe I should put that in an email.
[22:22:54 CET] <Daemon404> J_Darnley, neither does freebsd's/
[22:23:06 CET] <Daemon404> http://pubs.opengroup.org/onlinepubs/009696899/utilities/pwd.html
[22:23:09 CET] <Daemon404> neither does POSIX.
[22:23:10 CET] <J_Darnley> Can you use MSVC there?
[22:23:24 CET] <J_Darnley> I assume its a feature of msys
[22:23:24 CET] <Daemon404> i dont know, i have no context :D
[22:25:34 CET] <cone-684> ffmpeg 03Charlie Arnold 07master:22ee0a576faf: build: fix msvc build
[22:26:53 CET] <Daemon404> .... it was pushed anyway?
[22:26:57 CET] <Daemon404> holy crap that is a hack
[22:27:37 CET] <BtbN> Welp, that means it's broken for me now.
[22:27:50 CET] <BtbN> msvc via cygwin is how I usualy build
[22:27:54 CET] <Daemon404> a few people do
[22:27:57 CET] <J_Darnley> Ah.
[22:28:20 CET] <drv> pwd -W is a msys-only thing
[22:28:31 CET] <drv> we could pile on more hacks by detecting cygwin and using cygpath, but that seems like a bad plan
[22:28:43 CET] <J_Darnley> heh
[22:29:22 CET] <J_Darnley> BtbN: you should check just incase I didn't understand the logic correctly
[22:29:27 CET] <Daemon404> its incredinly wrong to make environment decisions based on TARGET toolcgain
[22:29:30 CET] <Daemon404> on so many levels
[22:30:25 CET] <drv> it's not even too far-fetched to imagine MSVC cross compile via wine
[22:30:37 CET] <drv> (with a native linux shell)
[22:31:10 CET] <BBB> did we just pile 3 levels of hacks on top of something that is nice-to-have at best?
[22:31:15 CET] <BBB> please someone take charge of this :(
[22:31:16 CET] <Daemon404> drv, all of libav's fate instances do that
[22:31:18 CET] <Daemon404> BBB, yes
[22:31:31 CET] <Daemon404> i think having the 'feature' at all si not worth it.
[22:32:12 CET] <BtbN> What about $(pwd -W 2>/dev/null || cygpath -w -a . 2>/dev/null || pwd)
[22:32:17 CET] <BtbN> when we're making ugly hacks anyway
[22:32:32 CET] <BBB> wine cl.exe
[22:32:41 CET] <BBB> lets just revrt that patch?
[22:32:45 CET] <BBB> all of them, that is
[22:32:57 CET] <BtbN> What exactly are they even trying to fix?
[22:33:07 CET] <BBB> my boss at hedge fund used to say hacky hack hack when we did stpid stuff like that
[22:33:13 CET] <BBB> so Id like to introduce that here
[22:33:15 CET] <BBB> hacky hack hack
[22:33:18 CET] <J_Darnley> The new patches: building on msys
[22:33:39 CET] <J_Darnley> The first problem patch: bitexact building out of tree
[22:33:56 CET] <BBB> I know
[22:34:10 CET] <J_Darnley> (that was bot BtbN)
[22:34:15 CET] <J_Darnley> *for
[22:34:57 CET] <BBB> oh sorry
[22:34:59 CET] <J_Darnley> Oh another new patch was for check-headers
[22:35:12 CET] <J_Darnley> *fixing check-headers
[22:35:37 CET] <Daemon404> and i replied to teh  wrong mail
[22:35:47 CET] <Daemon404> i didnt notice my MUA didnt select it
[22:35:50 CET] Action: Daemon404 A+ stuent
[22:35:53 CET] <Daemon404> student, even.
[22:37:40 CET] <drv> oh yeah, the OS/2 guy showed up in this other thread, totally forgot about that
[22:52:09 CET] <BBB> Im starting to feel that the arguments that come out of andreas are identical to these coming out of ganesh, and they dont make me happy
[22:52:24 CET] <BBB> theyre just about arguing, having the last word and not about moving a situation forward to an actual solution
[22:53:51 CET] <Daemon404> you must be new to debianland
[22:54:16 CET] <jamrial> andreas is the debian guy, right? i can see now why he's insisting on the mt vlc issue
[22:54:54 CET] <Daemon404> yes he is
[22:55:17 CET] <Daemon404> most of his stuff seems to me like "what is the least amount of effort i can put into makign my packages happy"
[22:55:29 CET] <jamrial> why isn't he poking the vlc side of things instead?
[22:55:33 CET] <BtbN> it seems strange to me that videolan/vlc refuses to fix something that is known to be broken, and instead so this weird stuff that's happening right now
[22:55:42 CET] <jamrial> isn't every other libavcodec based player working fine after this mt change?
[22:55:49 CET] Action: Daemon404 has 10 foot pole about vlc/hwaccel
[22:56:11 CET] <Daemon404> jamrial, path of least resistance to making packages happy.
[22:56:11 CET] <BtbN> No other (major?) player uses frame threading with hwaccell i'd guess
[22:57:05 CET] <BtbN> But I don't get why they don't just fix that. What's so hard about that? Or is it realy about the fallback to sw decode, which would also just use one thread then?
[22:57:43 CET] Action: Daemon404 keeps his 10-foot pole out
[23:00:37 CET] <durandal_1707> Daemon404: have more to add from list?
[23:01:22 CET] <Daemon404> durandal_1707, ill think on it.
[23:10:12 CET] <wm4> I wonder why this andreas guy doesn't just go argue with courmisch
[23:10:19 CET] <wm4> I'm sure they'd have a lot of fun together
[23:10:40 CET] <Daemon404> i already answered that
[23:50:22 CET] <nevcairiel> ... why do patches get pushed after 5 minutes
[23:50:27 CET] <nevcairiel> this msvc thing is broken as fuck
[23:52:15 CET] <wm4> were they OK'ed?
[23:52:22 CET] <nevcairiel> not by anyone but himself
[23:52:31 CET] <nevcairiel> and even then it should be left on the ML for a period of time
[23:52:43 CET] <wm4> that's not ok then
[23:54:56 CET] <nevcairiel> we should just push a revert of everything of this crap
[23:58:09 CET] <ubitux> send a patch, wm4 ack it, and 5min later you push it
[23:58:35 CET] <ubitux> introducing the pair revert wars 
[23:59:42 CET] <BtbN> This should never have been pushed in the first place, so reverting it sounds like the apropriate thing to do.
[23:59:52 CET] <BtbN> There were numerous concerns about it
[00:00:00 CET] --- Sun Jan 24 2016