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

[burek]

[00:38:02 CET] <Daemon404> atomnuker, one reply from ganesh is directed at you
[00:38:08 CET] <Daemon404> in case you wish to answer
[01:07:30 CET] <kierank> llogan: it is on github now
[01:07:35 CET] <kierank> ah y ou said
[01:07:38 CET] <kierank> been there for a while
[01:46:29 CET] <kierank> wm4: I have many many lavfi misunderstandings
[02:11:21 CET] <kierank> wm4: so yeah I asked my lavfi questions
[02:11:24 CET] <kierank> I have no idea how you made it work
[02:20:37 CET] <llogan> durandal_170: using optipng on the PNG images for the wiki can reduce the size significantly
[04:07:32 CET] <cone-229> ffmpeg 03Thomas Mundt 07master:d0a9114f9911: avfilter/vf_bwdif: Add yadif base information to copyright header
[09:21:43 CET] <cone-229> ffmpeg 030smail Dönmez 07master:fa3eecf9ab6e: configure: Use lowercase includes/library names for schannel check.
[09:30:27 CET] <mateo`> seriously mats is starting to getting on my nerves
[09:43:12 CET] <wm4> mateo`: most people's nerves areaffected
[09:44:32 CET] <mateo`> i'm not even directly concerned but when i see how he responds to people ...
[09:47:08 CET] <wm4> kierank: well, my code has no problems with lots of buffering
[10:16:11 CET] <thardin> mats seems to need to learn to enhance his calm 
[10:16:36 CET] <nevcairiel> i wonder if mailman has a shadowban feature
[10:16:45 CET] <nevcairiel> just swallow his mails without telling him 
[10:17:39 CET] <thardin> that'd be an interesting feature
[10:19:50 CET] <ubitux> yeah the shadowban should is probably a good idea
[10:20:00 CET] <ubitux> he won't realize anytime soon anyway, he's mostly talking to himself
[10:25:12 CET] <petru> Hi there! My name is Petru and I am an undergraduate computer science student. I would like to apply to "Improve Selftest coverage" project
[10:26:54 CET] <petru> Now I am trying to understand how tests work and how to implement one. I have read this wiki: http://trac.ffmpeg.org/wiki/FATE/AddingATest but it isn't complete
[10:26:59 CET] <cehoyos> Hi, first step is to compile FFmpeg and run fate
[10:27:05 CET] <petru> I did
[10:27:33 CET] <cehoyos> How did you identify the part of code for which you want to add a test?
[10:28:00 CET] <petru> With #ifdef TEST
[10:28:11 CET] <cehoyos> No / I don't understand...
[10:28:37 CET] <cehoyos> You have to use your favorite profiling tool now to be able to know which part of FFmpeg source code is not covered by fate yet.
[10:29:02 CET] <ubitux> or just go to coverage.ffmpeg.org
[10:29:10 CET] <cehoyos> I may never have used it myself, but "gprof" is one example.
[10:29:16 CET] <cehoyos> Or you go the easy way;-)
[10:29:34 CET] <ubitux> you can generate that with gcov toolchain (see configure)
[10:29:44 CET] <petru> OK, thanks
[10:32:51 CET] <petru> But I would like to see how one test is implemented from start to end. For example "fate-imc" test that is from audio.mak. I don't find the code for this test
[10:33:44 CET] <ubitux> CMD = pcm
[10:33:51 CET] <ubitux> try git grep 'pcm()'
[10:34:09 CET] <nevcairiel> thats probably in regression-funcs.mak or whatever the filename was
[10:34:28 CET] <nevcairiel> regression-funcs.sh
[10:34:28 CET] <nevcairiel> :)
[10:34:36 CET] <petru> ahhhhh
[10:34:41 CET] <ubitux> fate-run.sh according to git grep
[10:34:44 CET] <petru> Thanks :)
[10:34:54 CET] <nevcairiel> ah yeah, fate-run.sh which  includes the regression funcs file
[10:35:18 CET] <nevcairiel> the fate system is a bit hard to navigate at first
[10:36:09 CET] <petru> for a newbie like me yes
[10:37:17 CET] <petru> thank you for your help :)
[10:44:27 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:0d4b8a2c163b: hls: read protocol options through the AVIOContext
[10:44:28 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:eae2d89bf715: hls: handle crypto in the protocol checks
[10:46:03 CET] <BtbN> So Mats says that he is uable to use git propperly, ad expects other people to do that work for him? oÒ
[10:46:32 CET] <BtbN> Ad why does my N key Not work for NoN-Capital N aNymore?
[10:57:28 CET] <nevcairiel> that is one crazy keyboard failure
[11:02:36 CET] <thardin> hm, what to do about that shitty mxf file
[11:02:51 CET] <nevcairiel> use the realmedia player "rm" on it
[11:02:54 CET] <nevcairiel> it can handle anything
[11:04:06 CET] <thardin> that's less optimal than my initial pass at a "solution". I think I'll have to interrogate the user a bit
[11:13:40 CET] <cehoyos> thardin: Are you talking about the ticket I tried to fix?
[11:15:25 CET] <thardin> yes. these things tend to need digging
[11:16:23 CET] <cehoyos> Is my analysis correct? Does the header specify another trac number than the actual frames?
[11:16:31 CET] <thardin> yes, as fas as I can tell
[11:16:43 CET] <cehoyos> Or is there another possibility to assign the frames to a track?
[11:17:13 CET] <thardin> no, you use the lower 4 bytes of the key in the SourceTrack (or MaterialTrack, I forget which)
[11:17:29 CET] <cehoyos> And what other information does the frame offer?
[11:17:37 CET] <thardin> and mxf is hairy enough as it is without incorporating hacks to mirror hacks in other decoders
[11:17:41 CET] <cehoyos> Does it say if it's audio or video? Or anything else?
[11:18:04 CET] <thardin> each edit unit has a header which tells you some things
[11:18:15 CET] <thardin> unless the file is clip-wrapped (opatom)
[11:18:19 CET] <cehoyos> Iiuc, the track is not only identified by a number but also an id, no?
[11:18:34 CET] <thardin> the ID is the number
[11:18:47 CET] <thardin> parts of the number is metadata
[11:19:16 CET] <thardin> like all audio tracks has one of the bytes being some predetermined value
[11:19:42 CET] <thardin> the truth is in the spec and/or the mxf book
[11:19:53 CET] <cehoyos> In MXFTrack, I see an ID, a number and a sequence_ref
[11:20:32 CET] <cehoyos> What is a sequence ref?
[11:21:18 CET] <thardin> hum-hum
[11:22:44 CET] <thardin> right, you use SourceTrackID to look up TrackNumber in SourcePackage
[11:23:01 CET] <thardin> basically the key is pair<SourcePackageID,SourceTrackID>
[11:24:02 CET] <thardin> plus LinkedTrackID in the EssenceDescriptor for figuring out the codec specific stuff like resolution, cropping information etc
[11:24:38 CET] <cehoyos> Is SourcePackage what I call the "frame"?
[11:24:44 CET] <thardin> anyway, what I'm getting at is we have to ask the user (who is likely a developer) why the file has incorrect TrackNumbers
[11:25:26 CET] <thardin> no. SourcePackage is more a.. it relates to a specific piece of essence
[11:25:37 CET] <thardin> MaterialPackage is the "meta"
[11:26:04 CET] <cehoyos> I don't think he is a developer: He says he wants to switch from Mainconcept to FFmpeg but the files do not work with FFmpeg...
[11:26:05 CET] <thardin> because mxf supports different "views" of the same piece of essence
[11:26:17 CET] <thardin> yes, but the files come from somewhere
[11:26:30 CET] <thardin> it's not some random file they found on the internet
[11:26:55 CET] <thardin> hence a better approach may be to figure out why the file is bad
[11:27:46 CET] <cehoyos> Does mxflib allow to extract a track?
[11:27:53 CET] <thardin> yes, you can use mxfsplit
[11:27:53 CET] <cehoyos> Did you try for the file in question?
[11:28:11 CET] <thardin> I didn't try mxfsplit on that specific file though
[11:29:05 CET] <cehoyos> I have mxfsplit 1.0.1, what should I do with it?
[11:29:32 CET] <thardin> run it on the file, see what it spits out
[11:30:04 CET] <thardin> it should create one file for each essence track (aka stream)
[11:30:51 CET] <cehoyos> It aborts because it wants it xml file
[11:30:59 CET] <thardin> you need to make install
[11:31:06 CET] <cehoyos> Do you remember how to point it to the file?
[11:31:10 CET] <thardin> I get the video in a file called _0002-G15010500.Stream
[11:31:14 CET] <cehoyos> I already managed once.
[11:31:24 CET] <cehoyos> So we are missing something?
[11:31:29 CET] <thardin> 15010500 is the track number in hex, or 352388352 in decimal
[11:32:27 CET] <cehoyos> So how does mxflib map the frames to this track number?
[11:32:30 CET] <thardin> whereas the header points out 15010800, meaning 352389120
[11:32:38 CET] <cehoyos> Ah, sorry.
[11:32:47 CET] <thardin> mxfsplit doesn't give a hoot about the header
[11:32:53 CET] <thardin> it just extract the essence
[11:33:00 CET] <thardin> extracts*
[11:33:20 CET] <thardin> for all it knows what the header points to might be in some other file
[11:33:30 CET] <thardin> which you figure out using your MAM
[11:33:45 CET] <thardin> think how .mov can point to external files
[11:34:05 CET] <thardin> except with MXF you don't have filename but PackageIDs
[11:35:11 CET] <thardin> so ffmpeg can never truly support MXF
[11:35:31 CET] <thardin> because you need a database and all kinds of stuff
[11:36:36 CET] <thardin> I'll have to write something on the ticket to try and coax some information out of the user
[11:36:53 CET] <thardin> no login info on this machine though, so later this evening I suppose
[11:37:20 CET] <cehoyos> I asked him something: https://trac.ffmpeg.org/ticket/5312#comment:7
[11:37:30 CET] <cehoyos> Should I add something?
[11:37:51 CET] <thardin> that'll do for now. I can elaborate on it later
[11:47:39 CET] <cone-229> ffmpeg 03Luca Barbato 07master:522ab0b9a929: indeo2data: K&R formatting cosmetics
[11:47:40 CET] <cone-229> ffmpeg 03Luca Barbato 07master:73f3c8f73edf: indeo2: Fix banding artefacts
[11:49:34 CET] <JEEB> thardin: kind of like matroska and segment UUIDs > PackageIDs
[11:51:15 CET] <thardin> hooray
[11:51:36 CET] <thardin> the way essence is wrapped in mxf is based on some other smpte standard. maybe SDI
[11:51:46 CET] <cehoyos> You mean you found something?
[11:52:13 CET] <thardin> no, just telling a bit of the history of the thing
[11:52:54 CET] <nevcairiel> michaelni: you really shouldn't enable his ramblings
[11:54:16 CET] <wm4> michaelni: why did you even do that
[11:54:25 CET] <wm4> why not drive forward the merge
[11:54:28 CET] <wm4> this is just bullshit
[11:54:38 CET] <wm4> also thanks for feeding the troll
[11:55:58 CET] <thardin> oh dear
[11:57:00 CET] <michaelni> if a developer doesnt know how to use git, i help him and explain how to do what he wanted to do (if i have time and all...)
[11:59:03 CET] <michaelni> i just pushed as i had to try it locally to check if my suggested commands work ...
[11:59:29 CET] <michaelni> would have been silly to try but then discard and not push the work
[12:02:04 CET] <ismail> michaelni: agreed, it was a nice change.
[12:16:39 CET] <wm4> michaelni, ismail: it certainly won't improve Mats' behavior, he just got what he wanted by writing lots of annoying posts
[12:16:51 CET] <wm4> instead of actually putting effort into it, or god forbid, learning some git
[12:17:07 CET] <wm4> or, you know, keeping our development model a bit more chaos-free
[12:17:18 CET] <wm4> (now we cherry-pick Libav commits and later merge them...?)
[12:17:25 CET] <ismail> thats also true "Mats" problem has to be dealt with on a grand scale
[12:18:35 CET] <kierank> wm4: write an open letter to Mats
[12:20:37 CET] <cehoyos> (now we cherry-pick Libav commits and later merge them...?) <- I am not saying I disagree with your point but I believe you miss how the merges work in this sentence...
[12:21:19 CET] <cehoyos> Or am I wrong? I don't know, sorry.
[12:22:40 CET] <ubitux> we'll have to have a merge commit in addition to the cherry-pick to keep track of everything merged
[12:22:58 CET] <ubitux> merge commit will be meta only / noop
[12:26:37 CET] <wm4> cehoyos: they'll end up twice in the git history
[12:26:57 CET] <ismail> ah like github's merge crap
[12:27:44 CET] <wm4> uh what, that's how merges fundamentally work
[12:27:45 CET] <cehoyos> When I backport regression fixes, it sometimes happens that I try to backport a patch that was already backported by somebody else, git does not error in such a case, it simply returns. I wondered if this would be a similar case.
[12:28:05 CET] <ismail> wm4: yeah I know but still ugly
[12:28:34 CET] <nevcairiel> if it doesnt conflict, the merge later on would just show up empty, but since this is a comination of two commits, one of those will likely conflict later in the merge and need manual fiddlery to fix
[12:29:06 CET] <wm4> well even if git gracefully ignores the changes on merge, the git history will still contain the commits twice
[12:29:51 CET] <ubitux> + a merge, so 3 commits
[12:30:15 CET] <cehoyos> wm4: Do you still have objections over the mkv patch?
[12:31:14 CET] <wm4> cehoyos: it doesn't look like a good idea, why not report it to MS instead
[12:31:35 CET] <cehoyos> Report what? That our muxer writes broken files that our demuxer accepts?
[12:31:36 CET] <cone-229> ffmpeg 03Matt Oliver 07master:109dfed7fc26: lavc/dxva2_h264: Fix incorrect assert statement.
[12:31:40 CET] <wm4> I'm thinking maybe lavf should write no bit depth value here
[12:31:43 CET] <nevcairiel> so i started to build chromium, its on a ssd with fast internet and a pretty fast cpu, I bet its still going to take hours =p
[12:31:54 CET] <cehoyos> Isn't it a required tag?
[12:33:15 CET] <wm4> cehoyos: where does it say this?
[12:33:21 CET] <wm4> also what does mkvmerge do here?
[12:33:36 CET] <cehoyos> It is not mandatory, but mkvmerge writes it, so I don't see why FFmpeg should not write it.
[12:34:06 CET] <nevcairiel> but whats to gain to write it, its not like decoders would need it
[12:34:19 CET] <wm4> well until now it wrote a wrong value? (or just what value does mkvmerge write here)
[12:34:23 CET] <cehoyos> I thought mkvmerge is the specification nowadays, no?
[12:34:33 CET] <cehoyos> Yes, we currently write a wrong value.
[12:35:24 CET] <cehoyos> If the patch made no difference (because we already wrote the right value), it couldn't fix the issue...
[12:36:42 CET] Action: kierank digests wm4's response
[12:36:51 CET] <nevcairiel> it would help if you actually had confirmation that the patch fixes the issue
[12:37:52 CET] <wm4> kierank: I'm not an expert on libavfilter, lavfi frame scheduling, or lavfi framesync though
[12:38:39 CET] <wm4> oh god github is killing some more vertical space
[12:38:42 CET] <cehoyos> nevcairiel: What additional confirmation do you need?
[12:38:43 CET] <kierank> lavfi is totally insane
[12:38:51 CET] <wm4> they now show a big header on diff views
[12:38:52 CET] <cehoyos> Sorry, I don't understand what you mean.
[12:39:21 CET] <wm4> nevcairiel: I think it was experimentally confirmed that wmp eats the files produced with the patch
[12:39:34 CET] <JEEB> kierank: oh yes it is
[12:39:55 CET] <kierank> I am genuinely considering just copying the filters into my code
[12:40:28 CET] <nevcairiel> cehoyos: personally i would use a slightly different patch, without hardcoding codec ids or the like, ie http://pastebin.com/SMx5eXNL
[12:40:35 CET] <kierank> "How many frames
[12:40:35 CET] <kierank> you have to feed is not defined, and is determined at runtime by the
[12:40:35 CET] <kierank> internal frame scheduling logic"
[12:40:39 CET] <kierank> what.the.fuck
[12:41:19 CET] <cehoyos> Apart from more braces imo, please push!
[12:41:25 CET] <wm4> kierank: that's just how it works
[12:41:48 CET] <kierank> variable latency is allowed?
[12:41:50 CET] <wm4> nevcairiel: uh that also seems questionable
[12:41:58 CET] <wm4> kierank: I don't see why not
[12:42:21 CET] <nevcairiel> wm4: how so, bits per raw sample should generally override the bits in the storage format (ie. sample format)
[12:42:52 CET] <wm4> nevcairiel: the code before that is of course worse
[12:43:14 CET] <wm4> I'd argue it shouldn't write the element at all if bits_per_raw_sample is not set
[12:43:33 CET] <wm4> the sample format can be pretty arbitrary
[12:43:40 CET] <nevcairiel> not sure its reliably set when its equal to the storage format
[12:43:43 CET] <wm4> there are fixed point and floating point encoders etc.
[12:45:44 CET] <nevcairiel> kierank: if you already have a 1:1 association between main and overlay frames, maybe you should just use drawutils to blend them, and not bother with lavfi
[12:45:58 CET] <wm4> drawutils isn't public
[12:46:23 CET] <kierank> yes that's the problem with lavfi as far as I can tell
[12:46:25 CET] <kierank> one true api
[12:46:27 CET] <nevcairiel> i suppose that is why i wrote my own frame blender back then
[12:47:14 CET] <kierank> wm4: variable latency is insane
[12:47:25 CET] <kierank> I can understand in vfr-land it's normal
[12:47:29 CET] <nevcairiel> not sure you would actually get that when just using vf_overlay
[12:47:29 CET] <wm4> heh
[12:47:31 CET] <kierank> but in cfr land I need fixed latencies
[12:48:12 CET] <nevcairiel> lavfi in general can make no guarantees, but sometimes a simple filtergraph just happens to work a certain way
[12:48:38 CET] <kierank> yes my simple scale filtergraph does what I want it to do
[12:48:42 CET] <wm4> kierank: all desktop media frameworks seem to work like this though
[12:48:55 CET] <wm4> and vf_overlay is a bit of a problem because of sparse vs. non-sparse
[12:48:59 CET] <wm4> I guess
[12:49:17 CET] <nevcairiel> 20 minutes in, its still cloning the chromium git repository
[12:49:20 CET] <wm4> actually, I haven't made sure that's what happens in your case, so my entire mail might be misdirected
[12:49:21 CET] Action: nevcairiel goes watch a movie
[12:59:04 CET] <kierank> I guess I could send a dummy subtitle per video frame
[13:03:47 CET] <nevcairiel> wm4: so should i push the bits_per_raw_sample mkv patch then? It definitely writes better values than before. And we can argue later about not writing any values in some circumstances later ;)
[13:03:57 CET] <wm4> uh ok
[13:04:06 CET] <wm4> it's certainly better than checking codec IDs directlx
[13:04:09 CET] <wm4> *directly
[13:04:14 CET] <nevcairiel> indeed
[13:04:21 CET] <wm4> it's still kind of lazy
[13:05:03 CET] <nevcairiel> personally i wouldnt write any values for compressed formats at all (unless they are crazy and need it), but thats just me
[13:05:11 CET] <nevcairiel> would probably break a bunch of things
[13:05:33 CET] <wm4> and I'd still prefer if MS were forced to fix their bug
[13:06:31 CET] <nevcairiel> i suppose it uses the value to check decoding support of the stream, if we were to do that, we would also just tell them to write proper values into their files =p
[13:07:45 CET] <nevcairiel> anyway can re-work this entire thing another time, accounting for bits_per_raw is a clear improvement either way, so
[13:07:50 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:c43d4858119e: matroskaenc: set the actual PCM bitdepth in the header
[13:08:10 CET] <wm4> another time == never
[13:14:57 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:c198295dedd5: dxva2_h264: fix size alignment asserts
[13:39:23 CET] <kierank> ubitux: is there a way of outputting bitmap subtitles to a file
[13:40:46 CET] <kierank> Stream #0:2 -> #0:0 (dvb_teletext (libzvbi_teletextdec) -> ? (?))
[13:40:50 CET] <kierank> kinda useless
[13:45:06 CET] <ubitux> kierank: with the cli i don't think so
[13:45:16 CET] <ubitux> i did a code a while ago with the api for that
[13:45:21 CET] <ubitux> that's relatively trivial
[13:45:22 CET] <kierank> ok
[14:01:43 CET] <cehoyos> -vcodec copy -map 0 -f rawvideo?
[14:01:54 CET] <cehoyos> Sorry: -scodec copy -map 0 -f rawvideo?
[14:04:21 CET] <ubitux> you can probably overlay them on a surface and save the stream too
[14:04:34 CET] <ubitux> but not sure how exactly you want to output them
[14:04:41 CET] <kierank> as like bmp files
[14:04:56 CET] <kierank> but no big deal I guess
[14:05:01 CET] <ubitux> right, but, as in "one picture for every different rectangle"?
[14:05:50 CET] <ubitux> if you have a subtitle that appears for 5 seconds, do you want 5 seconds of the same bitmap, or just a single small picture of the size of the rectangle
[14:21:54 CET] <kierank> single picture per sub
[14:26:08 CET] <JEEB> was there any parameters that could be given to lavf which could be useful when reading files that are still being written to?
[14:26:57 CET] <nevcairiel> dont think so, its not very good with such cases
[14:27:01 CET] <JEEB> ok
[14:27:18 CET] <JEEB> so I'll need to implement something to have it check the file size updates with a timeout
[14:28:18 CET] <JEEB> ffmpeg's -re is an example of something that could go horribly wrong, for example :) [dvb subs with timestamp coming from 14 hours in the future and then ffmpeg.c trying to be 'realtime' with that]
[14:40:49 CET] <Daemon404> mats is reallty getting obnoxious...
[14:40:53 CET] <Daemon404> even more so
[14:58:49 CET] <rcombs> I didn't know that was possible
[15:01:27 CET] <Compn> we should encourage it to see the upper limits
[15:01:39 CET] <Compn> from a scientific point of view.
[15:17:14 CET] <nevcairiel> how do i make configure check for a presence of a define?
[15:17:24 CET] <nevcairiel> i couldnt find an example
[15:17:53 CET] <Daemon404> #ifndef SOMEDEF
[15:17:54 CET] <Daemon404> asdgadgadgadfgsfghxgxfgb
[15:17:55 CET] <Daemon404> #endif
[15:18:04 CET] <nevcairiel> that doesnt sound very good
[15:18:39 CET] <Daemon404> look at x264 or x265 for checking the value of a define
[15:18:42 CET] <Daemon404> im sure this can be similar
[15:19:22 CET] <nevcairiel> check_cpp_condition apparently
[15:21:07 CET] <ubitux> nevcairiel: cpp_condition doesn't work?
[15:21:43 CET] <ubitux> nevcairiel: check_cpp_condition bla.h "defined(bla)"
[15:21:45 CET] <ubitux> ?
[15:22:47 CET] <nevcairiel> i'm trying this now
[15:26:46 CET] <nevcairiel> my system is kinda busy linking chromium though, 7gb linker memory use and climbing =p
[15:28:22 CET] <Daemon404> you got chromium to build?
[15:28:34 CET] <nevcairiel> apparently
[15:28:37 CET] <Daemon404> last time i tried, i got their build system in some state where it just *would not* configure and build properly
[15:28:38 CET] <nevcairiel> its been linking for like half an hour
[15:28:44 CET] <Daemon404> even removing it entirely, left stuff
[15:28:46 CET] <wm4> why are you building it at all
[15:28:48 CET] <Daemon404> i think it modified the registry
[15:28:58 CET] <nevcairiel> technically i'm building CEF
[15:29:12 CET] <nevcairiel> i need one with h264 decoding enabled
[15:29:15 CET] <Daemon404> cef?
[15:29:30 CET] <wm4> https://en.wikipedia.org/wiki/Chromium_Embedded_Framework ?
[15:29:36 CET] <nevcairiel> chromium embedded framework, ie. a wrapper around chromium to make it easier to use it in your app
[15:29:55 CET] <wm4> sounds very useful
[15:30:25 CET] <nevcairiel> all the binary distributions come without h264 decoding because muh licensing
[15:31:38 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:7d9e064cc13c: configure: check for SEC_I_CONTEXT_EXPIRED before enabling SChannel
[15:33:15 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07release/3.0:ee7c347935c0: configure: check for SEC_I_CONTEXT_EXPIRED before enabling SChannel
[15:33:24 CET] <Daemon404> O_o
[15:41:55 CET] <nevcairiel> o_O
[15:42:23 CET] <Daemon404> oh good. sliced h264 decoding produces wrong results on this file, with no errrors
[15:42:32 CET] <Daemon404> i only see warnings on loglevel debug
[15:42:32 CET] <ubitux> building chromium is the new hype thing?
[15:42:46 CET] <nevcairiel> i dont do it for fun, mind you
[15:42:56 CET] <wm4> didn't you know, all software converges towards chromium
[15:42:57 CET] <nevcairiel> its $work
[15:43:21 CET] <Daemon404> wm4, guis are written in js now
[15:43:24 CET] <wm4> (actually, towards the browser, but we all know chromium is the only actual browser)
[15:43:38 CET] <wm4> Daemon404: you don't need to tell me
[15:45:42 CET] <nevcairiel> i wonder how long this linking will take
[15:45:46 CET] <nevcairiel> i should watch another movie
[15:46:11 CET] <Daemon404> nevcairiel, PGO?
[15:46:17 CET] <nevcairiel> no clue
[15:46:21 CET] <nevcairiel> i just ran this automated script
[15:46:30 CET] <nevcairiel> LTCG in any case
[15:46:36 CET] <Daemon404> oic
[15:46:47 CET] <Daemon404> yeah. at MS, they have entire farms just for LTCG
[15:46:49 CET] <Daemon404> it's slow.
[15:48:29 CET] <wm4> building Qt (including chromium) takes only 2 hours or so here
[15:48:52 CET] <nevcairiel> doesnt qt use "just" webkit?
[15:49:00 CET] <Daemon404> i have never successfully built and used qt on windows, wm4
[15:49:07 CET] <Daemon404> itll build. my app will build.
[15:49:07 CET] <Daemon404> BAM
[15:49:09 CET] <Daemon404> runtime errror
[15:49:12 CET] <Daemon404> some shitty dialogue box.
[15:49:22 CET] <nevcairiel> i build Qt on windows fine, but without the web parts, since i dont need those
[15:49:24 CET] <wm4> nevcairiel: it provides both (qtwebengine is the chromium one)
[15:49:39 CET] <wm4> qtwebkit is deprecated
[15:49:40 CET] <nevcairiel> i see
[15:49:54 CET] <nevcairiel> i told this one to create a fully optimized build
[15:49:57 CET] <nevcairiel> maybe that was a mistake
[15:50:21 CET] <Daemon404> sigh refactors
[15:50:29 CET] <Daemon404> even git blame -M -w doesnt work
[15:50:44 CET] <wm4> at least this kind of software enables https://xkcd.com/303/
[15:51:12 CET] <nevcairiel> Daemon404: i just got used to using the web git interface for that and manually going through parents
[15:51:25 CET] <Daemon404> nevcairiel, me too
[15:51:56 CET] <wm4> I find gitk is pretty good at traversing history
[15:53:39 CET] <Daemon404> currently waiting for github to stop freezing my brwoser
[15:53:52 CET] <nevcairiel> this is why i mirror got git-web
[15:53:58 CET] <nevcairiel> fucking github interface is the worst
[15:54:08 CET] <Daemon404> ... what the hell github
[15:54:10 CET] <wm4> github doesn't allow you to search commit history
[15:54:14 CET] <Daemon404> i click on the commit in git blame view
[15:54:16 CET] <durandal_170> github rocks!
[15:54:21 CET] <Daemon404> and the diff *does not* add or mvoe that line
[15:54:24 CET] <Daemon404> wtf?
[15:55:01 CET] <Daemon404> it dos in git show
[15:55:08 CET] <Daemon404> so github is silently removing parts of large diffs
[15:55:10 CET] <Daemon404> not even a warning
[15:55:43 CET] <durandal_170> also ffmpeg-devel is fine here, learn to use spam filter
[15:56:25 CET] <Compn> plonk file ? :P
[15:58:06 CET] <Daemon404> currently gone through 3 refactoring and cosmetic commits, still not at original addition of line
[15:58:34 CET] <Daemon404> 4 now. a refactoring from svn times.
[15:58:49 CET] <wm4> so, does it really work on windows if e.g. libavcodec calls av_malloc, and then libavformat calls av_free on the same memory?
[15:59:10 CET] <Daemon404> ... wtf does this?
[15:59:13 CET] <Daemon404> that sounds so wrong
[15:59:25 CET] <wm4> probably nothing, it's just an example
[15:59:40 CET] <Daemon404> .... sigh
[15:59:40 CET] <wm4> I want to know if all libs implicitly share libavutil's heap
[15:59:40 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/commit/26b86e47c010029d7ca7c7264f710c240d85339a
[15:59:44 CET] <Daemon404> original commit
[15:59:46 CET] <Daemon404> 0 info
[15:59:48 CET] <Daemon404> "fixes <filenames>"
[15:59:58 CET] <wm4> that's more info than usual!
[16:00:27 CET] <nevcairiel> it tells you that it adds support for non-sequential frame nums
[16:01:24 CET] <Daemon404> it doesnt say why it happens, and how the fix works
[16:01:27 CET] <Daemon404> because it doesnt work.
[16:01:46 CET] Action: Daemon404 has files it prodices wrong output on, and also doesnt know why its nto a warning, but a debug log
[16:01:49 CET] <nevcairiel> those conformance samples pass fate, so it must work =p
[16:02:08 CET] <Daemon404> thats only true if we verified the output hash against JM
[16:02:12 CET] <nevcairiel> and gaps in themself are not necessarily forbidden
[16:02:36 CET] <Daemon404> in my case, im getting slices of other frames stiched together
[16:02:49 CET] <kierank> does fate even test sliced threads
[16:02:49 CET] <Daemon404> quicktime / vlc seem to play it right though
[16:03:01 CET] <nevcairiel> vlc doesnt have its own decoder
[16:03:02 CET] <Daemon404> the latter is kind confusing
[16:03:14 CET] <Daemon404> nevcairiel, it may not use some threading type or feature ffmpeg.c does
[16:03:32 CET] <durandal_170> slice threading?
[16:03:51 CET] <Daemon404> nevcairiel, or it could be vlc using libav :P
[16:03:53 CET] Action: Daemon404 hides
[16:04:19 CET] <nevcairiel> try to play some kind of vp9 file, if it works its not libav =p
[16:04:38 CET] <durandal_170> can you share one short sample?
[16:04:52 CET] <Daemon404> durandal_170, i need to get permission from the user
[16:04:55 CET] <nevcairiel> does it only break with threading then?
[16:05:00 CET] <Daemon404> nevcairiel, not sure
[16:05:01 CET] <Daemon404> lets try.
[16:05:48 CET] <Daemon404> [h264 @ 0x749aa0] no picture ooo
[16:05:50 CET] <Daemon404> i also like this
[16:06:04 CET] Action: Daemon404 likes to think it is an adventure time reference
[16:06:23 CET] <nevcairiel> ooo stands for out of order
[16:06:36 CET] <Daemon404> ah
[16:08:03 CET] <nevcairiel> hm still linking
[16:08:07 CET] <nevcairiel> i should have timed this
[16:08:56 CET] <Daemon404> nevcairiel, yes
[16:09:01 CET] <Daemon404> diff thread count = diff hash
[16:09:05 CET] <Daemon404> so it;s broken
[16:09:16 CET] <nevcairiel> but fine in single?
[16:09:26 CET] <Daemon404> need to verify output
[16:09:29 CET] <Daemon404> i just checked it differs
[16:13:28 CET] <nevcairiel> where the hell do people get such odd h264 encodes anyway
[16:13:28 CET] <Daemon404> 1 thread looks correct. N threads output is nondeterministic.
[16:13:34 CET] <Daemon404> so we have a bug.
[16:13:52 CET] <Daemon404> nevcairiel, this is made by microsoft's h264 encoder
[16:14:00 CET] <nevcairiel> microsoft has a encoder?
[16:14:08 CET] <Daemon404> [h264 @ 0x18abe80] user data:"Microsoft H.264 Encoder V1.0 for Windows"
[16:14:41 CET] <nevcairiel> i guess they do
[16:15:33 CET] <Daemon404> odd as in "has slices" ? :P
[16:15:46 CET] <nevcairiel> every bluray has slices, and those decode just fine
[16:15:55 CET] <kierank> not many people use slice threading
[16:15:58 CET] <kierank> so i'd beg to differ
[16:16:08 CET] <Daemon404> does ffmpeg.c use it?
[16:16:10 CET] <kierank> most of the dozen or so h264 crashes I found were in slice threads
[16:16:15 CET] <kierank> only if you force it
[16:16:19 CET] <nevcairiel> Daemon404: not unless you specifically tell it to
[16:16:28 CET] <nevcairiel> otherwise it uses frame threading
[16:16:29 CET] <Daemon404> ffmpeg -threads 1 -loglevel debug -i a.mp4 a.avi
[16:16:34 CET] <Daemon404> im using a bare bones cli command
[16:16:37 CET] <Daemon404> its reproducible
[16:16:45 CET] <nevcairiel> i think -thread_type slice or something
[16:17:00 CET] <Daemon404> dare i try helgrind
[16:17:00 CET] <nevcairiel> default is frame+slice, where frame is favored
[16:17:08 CET] <Daemon404> or will i be killed by spurious warnings
[16:17:30 CET] <nevcairiel> if you can get permission to share the sample, that would probably be helpful
[16:17:47 CET] <Daemon404> yeah but >timezones
[16:17:53 CET] <Daemon404> response wont be quick
[16:20:09 CET] <Daemon404> looks like even if i force frame threads, it is broken
[16:20:45 CET] <Daemon404> forcing slice threads = correct output
[16:20:48 CET] <Daemon404> so its a frame threading bug
[16:21:04 CET] <Daemon404> (much to the shock of kierank)
[16:21:30 CET] <kierank> interesting
[16:21:49 CET] <kierank> does it actually use slice threading
[16:21:58 CET] <kierank> i.e does it warn about deblock between slice
[16:22:44 CET] <Daemon404> i dont see anything about that
[16:22:45 CET] <Daemon404> so maybe not
[16:22:56 CET] <Daemon404> also, with threads = 1, all the 'ooo' debug logs go away
[16:23:06 CET] <Daemon404> (still dont know why its only debug)
[16:23:34 CET] <kierank> might be a demuxer bug
[16:23:37 CET] <kierank> avi and all that
[16:23:44 CET] <Daemon404> it's mp4
[16:23:47 CET] <kierank> oh
[16:27:22 CET] <wm4> just why, why in the fuck is ffmpeg full of functions that are >300 lines
[16:27:33 CET] <kierank> because neckbeards
[16:27:55 CET] <wm4> what does that even have to do with neckbeards
[16:29:28 CET] <Daemon404> enterprise pointy haired people are just as likely to write them
[16:29:40 CET] <atomnuker> punks?
[16:30:02 CET] <Daemon404> no, it's a dilvery refernce
[16:30:30 CET] <Daemon404> ==17375== ERROR SUMMARY: 25859 errors from 1000 contexts (suppressed: 2254 from 75)
[16:30:33 CET] <Daemon404> after 1 frame
[16:30:37 CET] <Daemon404> i think helgrind isnt gonna work
[16:34:21 CET] <darkapex> atomnuker: Can I pm you the draft of my GSoC proposal for input?
[16:35:10 CET] <atomnuker> darkapex: sure
[16:35:27 CET] <Daemon404> ... is this thread "teach mats how to git"
[16:36:08 CET] <nevcairiel> this thread got its last response hours ago, are you still reading it? =p
[16:36:36 CET] <Daemon404> im slow
[16:44:25 CET] <wm4> I project every new mail on my retina in realtime as it's fetched from the server
[16:44:57 CET] <durandal_170> what?
[16:45:30 CET] <kierank> google inbox kids
[16:46:03 CET] <durandal_170> google tech?
[16:49:19 CET] <wm4> so, when can we drop XP support
[16:50:24 CET] <Daemon404> context?
[16:50:31 CET] <wm4> no context
[16:50:41 CET] <Daemon404> o ok
[16:51:11 CET] <wm4> just that I spent some hours debugging a crash caused by thw w32pthreads.h XP hack (but not sure if it applies to ffmpeg without our custom hacks)
[16:51:40 CET] <Daemon404> ... xp in a vm?
[16:51:45 CET] <wm4> no, win10
[16:51:53 CET] <wm4> the problem was that pthread_cond_wait checked for the cond_wait variable, which was not initialized and set to NULL
[16:51:56 CET] <Daemon404> why is xp code even being run then
[16:52:06 CET] <wm4> because the containing source file never created a cond var (but got them from another file)
[16:52:22 CET] <kierank> that reminds me to check all the cond_waits for spurious wakeups
[16:52:48 CET] <wm4> (creating a cond var calls w32thread_init)
[16:58:51 CET] <wm4> so, source file A creates a cond var, passes it to source file B, which calls pthread_cond_wait -> crash!
[16:59:21 CET] <wm4> unless _WIN32_WINNT >= 0x0600
[17:01:54 CET] <Daemon404> i would just compile with that and say "vista+ only kthx"
[17:02:09 CET] <wm4> I'm trying to find out how to set this without breaking everything
[17:03:54 CET] <nevcairiel> wm4: wouldnt it crash anyway if you call pthread_cond_wait without a valid condition variable
[17:04:04 CET] <wm4> nevcairiel: the cond var is valid
[17:04:12 CET] <wm4> it's been initialized in another file
[17:04:24 CET] <nevcairiel> "file"?
[17:04:30 CET] <wm4> source file, .c
[17:04:45 CET] <nevcairiel> the init should be process global
[17:04:53 CET] <nevcairiel> shouldnt it
[17:05:19 CET] <wm4> no, because these things use static var in a header
[17:05:26 CET] <nevcairiel> oh right, its a header
[17:05:30 CET] <wm4> to avoid having to link a source file in each sub lib for it
[17:07:46 CET] <nevcairiel> if you use a custom hacked version anyway, you might as well convert it into a c file for your project
[17:07:59 CET] <wm4> lol no
[17:08:17 CET] <nevcairiel> wouldnt be very hard, just remove a bunch of static's
[17:10:30 CET] Action: Daemon404 would rather rm xp
[17:15:15 CET] <JEEB> hmm
[17:15:46 CET] <JEEB> I wonder if some sort of still-being-written files would work if I would do `if(ret == 0) return AVERROR(EAGAIN);`
[17:15:59 CET] <JEEB> since the reading mechanism seems to have some five-retries thing
[17:16:11 CET] <JEEB> as well as some timeout thing
[17:16:21 CET] <BBB> lol helgrind
[17:16:31 CET] <Daemon404> BBB, it was useless yes
[17:16:32 CET] <Daemon404> howrve
[17:16:37 CET] <BBB> howrve?
[17:16:41 CET] <Daemon404> however*
[17:16:43 CET] <JEEB> however in Daelang
[17:16:49 CET] <Daemon404> i dont now too many better ways to debug complex races
[17:17:00 CET] <Daemon404> "staring at the code really hard" is pretty crap
[17:17:04 CET] <BBB> how often does it reproduce?
[17:17:11 CET] <Daemon404> every time
[17:17:12 CET] <BBB> 1 in 10 times? 1 in 1000? 1 in 1M?
[17:17:22 CET] <Daemon404> output hash changes every time with >1 thread
[17:17:29 CET] <Daemon404> and is never correct
[17:17:31 CET] <BBB> always to the same value?
[17:17:34 CET] <BBB> ah ok
[17:17:34 CET] <Daemon404> no
[17:17:38 CET] <Daemon404> it is nondeterministic
[17:17:39 CET] <BBB> what codec?
[17:17:49 CET] <Daemon404> h264 with frame threads
[17:17:57 CET] <BBB> send me file Ill look
[17:18:09 CET] <Daemon404> waiting on users' permission atm
[17:18:19 CET] <BBB> Im not promising anything but Ill at least try
[17:18:45 CET] <Daemon404> ill send once they OK it
[17:18:50 CET] <Daemon404> i'd open a bug on trac, but... carl.
[17:22:53 CET] <wm4> should mingw really define struct pollfd?
[17:24:30 CET] <ubitux> Daemon404: yes, helgrind/drd/tsan will give you GB of logs, that's what i'm uploading daily to fate (sorry i'm late to the party)
[17:24:55 CET] <ubitux> which makes me wonder what happen to the google guy who was working on it
[17:25:18 CET] <nevcairiel> we probably scared him off
[17:26:03 CET] <jamrial> wm4: dunno, but i always wondered why it defines pollfd.fd as unsigned while our compat fallback is int
[17:26:36 CET] <wm4> jamrial: maybe because the mingw guys are insane? I'm fairly sure the MS headers don't define that struct at all
[17:26:59 CET] <jamrial> it generates "libavformat/os_support.c:284:23: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]" warnings when you use it
[17:27:15 CET] <Daemon404> isnt it int on linux too
[17:27:50 CET] <jamrial> wm4: https://msdn.microsoft.com/en-us/library/windows/desktop/ms740094%28v=vs.85%29.aspx
[17:28:14 CET] <wm4> oh, lol
[17:28:20 CET] <wm4> MS are the insane ones then
[17:28:27 CET] <jamrial> looks like fd should be int, meaning mingw-w64 is wrong
[17:28:34 CET] <Daemon404> fd is int literally everywhere
[17:28:36 CET] <Daemon404> except mingw
[17:28:39 CET] <wm4> MS incompetence is so amazing
[17:28:42 CET] <Daemon404> (according to google)
[17:28:55 CET] <wm4> they're defining a function for compat with POSIX
[17:29:02 CET] <wm4> except it has a different name and semantics
[17:29:11 CET] <wm4> but they still define a POSIX type name for it
[17:29:33 CET] <wm4> the one who did this must have been on some bad drugs
[17:29:42 CET] <Daemon404> [16:29] <+wm4> but they still define a POSIX type name for it <-- uh they do?
[17:29:47 CET] <Daemon404> i dont recall ms defining poll()
[17:29:56 CET] <wm4> https://msdn.microsoft.com/en-us/library/windows/desktop/ms740094%28v=vs.85%29.aspx
[17:30:05 CET] <wm4> typedef struct pollfd
[17:30:16 CET] <Daemon404> ohlol
[17:30:23 CET] <jamrial> they don't define poll() but WSAPoll() instead
[17:30:34 CET] <wm4> just insane
[17:31:00 CET] <jamrial> which was intended to behave the same as poll(), except that for some bug it doesn't
[17:31:39 CET] <wm4> defining struct pollfd kills any source compat wrapper you could have
[17:31:45 CET] <wm4> I wonder how cygwin is dealing with that
[17:32:31 CET] <Daemon404> #define pollfd someshit
[17:32:36 CET] <Daemon404> #include <msheader.h>
[17:32:40 CET] <Daemon404> #undef pollfd
[17:32:42 CET] Action: Daemon404 runs
[17:33:16 CET] <wm4> if you control everything that includes windows.h
[17:34:33 CET] <wm4> anyway, can't find a nice way to force the Vista+-only code in w32pthreads.h
[17:35:10 CET] <Daemon404> you cant build with the nt define?
[17:35:49 CET] <wm4> --extra-cflags=-D_WINNT...?
[17:35:57 CET] <Daemon404> yeah
[17:36:08 CET] <nevcairiel> that should work, yes
[17:36:15 CET] <wm4> right, this could lead to the configure checks not fucking it up
[17:36:37 CET] <Daemon404> and uh
[17:36:37 CET] <Daemon404> so
[17:36:40 CET] <Daemon404> why isnt this default?
[17:36:45 CET] <wm4> because XP?
[17:36:47 CET] <jamrial> because xp
[17:36:50 CET] <Daemon404> so...
[17:36:59 CET] <Daemon404> people who want to support a dead os should be the non-default
[17:37:01 CET] <Daemon404> not everyone else
[17:37:09 CET] <Daemon404> so: same question.
[17:37:10 CET] <jamrial> the msvc checks even *force* xp by default, unless extra-cflags says otherwise
[17:37:19 CET] <wm4> we don't define _WINNT anywhere
[17:37:22 CET] Action: Daemon404 sighs
[17:37:24 CET] <wm4> and mingw defaults to something older
[17:37:29 CET] <Daemon404> jamrial, that seems so silly
[17:37:30 CET] <jamrial> wm4: we do for dxva
[17:37:41 CET] <wm4> yeah, with hacks
[17:38:15 CET] <nevcairiel> Daemon404: it really makes no difference when running on a newer windows, i dont get why there is always such a big huff about that, the compat code exists either way
[17:38:24 CET] <wm4> #if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0602
[17:38:24 CET] <wm4> #undef _WIN32_WINNT
[17:38:24 CET] <wm4> #define _WIN32_WINNT 0x0602
[17:38:24 CET] <wm4> #endif
[17:45:41 CET] <ubitux> michaelni: in the hscale, can we overread filter?
[17:47:27 CET] <ubitux> same question for src
[18:06:32 CET] <t4nk263> hello
[18:06:41 CET] <t4nk263> are there any known crashes with calling av_strdup
[18:07:52 CET] <t4nk263> namely, when trying to call avformat_open_input, with the url:  http://195.245.168.21/antena3 
[18:08:00 CET] <t4nk263> on 32 bit machines, it would crash
[18:36:58 CET] <jamrial> has anyone seen Andreas lately? it's been almost a month and a half since his last email
[18:38:46 CET] <Daemon404> jamrial, maybe he got tired of arguing constantly
[18:39:54 CET] <jamrial> in the end we reverted the thread change he requested
[18:41:44 CET] <wm4> what thread change?
[18:42:13 CET] <Daemon404> hwaccel
[18:43:00 CET] <Daemon404> anyway, i expect hell show up with some hacks the next time some crappt debian package is unhappy
[18:45:05 CET] <wm4> right
[18:45:45 CET] <wm4> jamrial: it's been since that since he updated the debian ffmpeg packages too
[18:45:53 CET] <nevcairiel> did they at least update ffmpeg in debian/ubuntu to 3.0 then?
[18:46:46 CET] <wm4> no
[18:46:48 CET] <wm4> 2.8.6
[18:47:51 CET] <jamrial> 3.0 seems to be in "experimental"
[18:48:42 CET] <jamrial> wm4: yeah, that's why i was wondering if anyone has seen him. but then again, there hasn't been a new 2.8 point release in a while
[18:54:13 CET] <michaelni> ubitux, from what i remember without checking the code, src probably before the last line up to linesize, filter is allocated by us so one could overallocate if its not good enough 
[19:03:34 CET] <cehoyos> nevcairiel: I didn't test but would have expected a "disable feature" in your patch (while I believe the "enable feature" was and is unnecessary)
[19:08:43 CET] <nevcairiel> cehoyos: and why would that be, its not enabled unless explicitly called
[19:10:55 CET] <nevcairiel> in any case the logic didnt change, it just added a new condition
[19:24:37 CET] <cehoyos> nevcairiel: What does "grep schannel config.h" show with the patch?
[19:25:28 CET] <nevcairiel> config.h doesnt change, it just avoids enabling it when its not supported on some old systems
[19:25:41 CET] <cehoyos> Neither the zlib, nor the lzma nor the bzlib check contain "enable feature"
[19:26:05 CET] <cehoyos> My question is: What does the grep command show on these old systems?
[19:26:21 CET] <nevcairiel> it showed 1, now it should show 0
[19:26:37 CET] <nevcairiel> like i said, the logic didnt change today, it just added a new condition
[19:26:42 CET] <nevcairiel> anyway, i have to leave now
[19:26:59 CET] <cehoyos> Or to say it differently: What happens if you comment the "#define SEC_I_CONTEXT_EXPIRED" out?
[19:27:39 CET] <nevcairiel> it will never get enabled, so it remains 0
[19:28:40 CET] <cehoyos> If it remains 0 how can it ever be enabled / how can the disable schannel || check ever be true?
[19:28:55 CET] <nevcairiel> there is a difference between disabled and not enabled
[19:29:01 CET] <nevcairiel> in any case, it works today
[19:29:07 CET] <nevcairiel> really have to leave now, bbl
[19:29:12 CET] <cehoyos> Ok, thanks
[19:30:12 CET] <cehoyos> The three-way meaning that is used for xcb only makes sense if it fails for --enable-feature (which it does for xvb) but this doesn't seem implemented.
[19:52:54 CET] <cone-229> ffmpeg 03Michael Niedermayer 07master:50ef7361cb5f: avcodec/resample: Remove disabled and faulty code
[19:56:01 CET] <wm4> so if I tell someone not to use ffserver, what should I tell them to use instead
[19:58:53 CET] <cone-229> ffmpeg 03Benjamin Steffes 07master:06267afe1cec: Fix detelecine filter for patterns like 3444 or 33333334.
[20:01:24 CET] <JEEB> wm4: depends on what exactly they want to do. for most of the HTTP-streaming-wanting folk there's nginx-rtmp (which seems to have NIH'd a HLS and DASH muxer)
[20:01:59 CET] <wm4> <sh4rm4^bnc> i'd like to test mini's ffv1 codec for LAN streaming, but ffserver doesnt seem to support that..
[20:02:07 CET] <JEEB> pffft
[20:02:31 CET] <JEEB> I think ffmpeg could listen in http now too
[20:02:37 CET] <JEEB> so I guess ffv1 in matroska for that? :P
[20:02:41 CET] <JEEB> no idea wtf would support that
[20:02:49 CET] <JEEB> other than lavf or vlc or so
[20:12:49 CET] <kierank> Ahahaha streaming ffv1
[20:12:53 CET] <kierank> Good luck with that
[20:13:59 CET] <Compn> who calls michael mini ?
[20:14:23 CET] <Compn> very strange naming scheme that is applied to no one else
[20:14:30 CET] <iive> libav parrots
[20:19:04 CET] <Daemon404> ive never seen that guy around libav, so it seems very doubtful
[20:19:40 CET] <wm4> it's all a conspiracy
[20:20:35 CET] <Daemon404> michael can't melt steal beams!
[20:20:45 CET] <Daemon404> steel*
[20:20:48 CET] <Daemon404> damn i screwed up.
[20:21:04 CET] <wm4> freudian slip that you want to steal all ffmpeg work!
[20:23:49 CET] <llogan> stupid scanner only saves images as badly compressed JPG...
[20:25:29 CET] <ethe> atomnuker: may I PM you (about AAC/audio programming) quick?
[20:26:16 CET] <Compn> i'm sure michaelni could melt steel beams, just not with jet fuel ...
[20:27:54 CET] <Daemon404> lol
[20:31:18 CET] <rcombs> I called him that for a while before he informed me he doesn't like it
[20:31:23 CET] <rcombs> no idea where I picked it up from
[20:44:58 CET] <atomnuker> ethe: sure
[20:50:00 CET] <llogan> rcombs: choose first two characters from any first+last name and they are all look dumb.
[20:50:48 CET] <rcombs> BaOb
[20:50:54 CET] <rcombs> DoTr
[20:51:05 CET] <rcombs> TeCr
[20:51:13 CET] <rcombs> BeSa
[20:51:19 CET] <rcombs> yeah, nothing great here
[21:02:42 CET] <wm4> does anyone have a patch to add DXVA_PicParams_VP9 to mingw?
[21:03:56 CET] <wm4> or maybe I shouldn't bother
[21:15:34 CET] <jamrial> wm4: nevcairiel's lavfilters fork of ffmpeg
[21:15:55 CET] <jamrial> wm4: http://git.1f0.de/gitweb?p=ffmpeg.git;a=commitdiff;h=47edd2355f941a2429c572649ec546e76c3d2c9c
[21:16:10 CET] <nevcairiel> i just copy pasted the MS header
[21:16:15 CET] <nevcairiel> the mingw people dont like that for license
[21:16:27 CET] <wm4> oh, going to steal that
[21:16:38 CET] <wm4> what license implications does this have?
[21:17:16 CET] <nevcairiel> (more specifically, i copy pasted the struct from the MS headers, they dont have a separate file for it)
[00:00:00 CET] --- Thu Mar 17 2016