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

[burek]

[00:06:26 CEST] <cone-554> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:d8a04d916b24: ffserver: formating
[00:06:27 CEST] <cone-554> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:683f57354deb: ffserver: drop unneeded else branching
[00:06:28 CEST] <cone-554> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:758c7a5cbc30: ffserver: drop unneeded else branching
[00:06:29 CEST] <cone-554> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:6504047f8286: ffserver: drop unneeded else branching
[01:45:20 CEST] <cone-554> ffmpeg 03Michael Niedermayer 07master:1c495b0bf690: avcodec/jpeg2000: Move gainb handling into the quantization code
[02:15:31 CEST] <cone-554> ffmpeg 03Michael Niedermayer 07master:69f7ccef8e12: avcodec/jpeg2000dwt: Move K/X constants to header
[02:15:32 CEST] <cone-554> ffmpeg 03Michael Niedermayer 07master:6c7b1597c779: avcodec/jpeg2000: Move H band scaling from wavelet into quantization code
[02:36:34 CEST] <cone-554> ffmpeg 03Michael Niedermayer 07master:b1fdf81c6eed: avcodec/jpeg2000dwt: use 32x32->64 multiplies in the 9/7i DWT
[03:17:21 CEST] <cone-554> ffmpeg 03Michael Niedermayer 07master:4e926fb969ac: avcodec/jpeg2000: Move L band scaling from the 9/7f wavelet to quantization stage
[04:52:43 CEST] <BBB> so for ivf encoding, it writes s->streams[]->duration at the write_header phase, but this element is typically AV_NOPTS_VALUE (st->duration = 0) e.g. when were reading a webm file and converting to ivf
[04:52:53 CEST] <BBB> what would be the recommended way to create an actual duration out of it?
[04:53:20 CEST] <BBB> if I just keep track of timestamps in write_packet and add a write_trailer, it works, is that the best way?
[04:53:26 CEST] <BBB> (it seems kind of hacky)
[04:55:39 CEST] <BBB> (like in http://pastebin.com/x83X5JYe)
[12:45:48 CEST] <cone-309> ffmpeg 03Luca Barbato 07master:61dc9d647c66: udp: Fix local_port management
[12:45:49 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:8fb672b50ae3: Merge commit '61dc9d647c6664e11674d9a10fdde29987d6acda'
[13:22:51 CEST] <cone-309> ffmpeg 03Mariusz SzczepaDczyk 07master:80e18bb4868a: lavf/avio: Extend API with avio_move() and avio_delete()
[13:22:52 CEST] <cone-309> ffmpeg 03Mariusz SzczepaDczyk 07master:824a82d1b8c6: lavf/file: implement move and delete callbacks
[14:14:24 CEST] <Daemon404> i propose we add a GUI toolkit to libav*
[14:14:32 CEST] <Daemon404> suppose you are writing a player.
[14:14:51 CEST] <Daemon404> or perhaps an implementation of the X protocol.
[14:14:51 CEST] <j-b> that's a great idea.
[14:16:54 CEST] <Compn> sure
[14:17:25 CEST] <Compn> i think we should talk to downstreams and see what they want from us , videolan seems to complain a lot but i dont see bug reports or a wiki explaining what they want.
[14:17:28 CEST] Action: Compn looks at j-b
[14:17:33 CEST] <thardin_> I seem to recall kostya having written an RE report on some obscuring video format, concluding that it's basically X (but Win32 calls instead)
[14:17:42 CEST] <Daemon404> thardin_, well we have xface.
[14:17:52 CEST] <Daemon404> thardin_, you are thinkinf of GDI calls
[14:18:35 CEST] <thardin_> I suppose
[14:18:44 CEST] <Compn> i wonder how many gdi calls we would need to emulate to get that one codec working
[14:19:09 CEST] <thardin_> you could probably use wine for it
[14:19:13 CEST] <Compn> i know "all of them" but ... how big would it be from win95 really?
[14:19:15 CEST] <Compn> maybe.
[14:19:25 CEST] <thardin_> might just have been a win3.1 thing
[14:26:50 CEST] <__gb__> PICT opcodes are also interesting (QuickDraw IIRC)
[14:42:46 CEST] <BBB> is libavformat/hevc.c a half-copy of libavcodec/hevc_ps.c?
[14:43:09 CEST] <nevcairiel> a bad one at that
[14:43:18 CEST] <BBB> it has complete pps/vps/sps parsing routines in it
[14:43:21 CEST] <BBB> why does it exist?
[14:44:35 CEST] <nevcairiel> iirc its used to build the extradata for mp4
[14:45:12 CEST] <nevcairiel> because the mp4 people thought its a good idea to duplicate half of the sps/pps/vps values into their own struct, and then include the full sps/pps/vps in addition to that :p
[14:50:01 CEST] <BBB> of course!
[14:52:39 CEST] <wm4> reminds me of matroska (just with other codecs)
[14:53:38 CEST] <nevcairiel> matroska rarely invents their own thing
[14:53:45 CEST] <nevcairiel> they usually copy the idea from someone else
[15:07:23 CEST] <_[-T-]> hi
[15:07:50 CEST] <_[-T-]> is there any dev that participated to the QSV implementation around ?
[15:21:30 CEST] <ubitux> no one is going to stop the incoming c++ header madness on the other side?
[15:21:54 CEST] <BtbN> hm?
[15:22:03 CEST] <ubitux> trying to put extern "C"
[15:22:42 CEST] <Daemon404> ...
[15:22:42 CEST] <Daemon404> where
[15:22:42 CEST] <BtbN> don't see a problem with it in public headers, as long as it's in the propper ifdefs
[15:22:44 CEST] <ubitux> Daemon404: libav irc
[15:22:53 CEST] <Daemon404> i argue it should be in eh including program
[15:22:56 CEST] <Daemon404> the*
[15:23:00 CEST] <ubitux> we don't support c++
[15:23:07 CEST] <thardin_> that thing strikes me as an mru-ism
[15:23:09 CEST] <ubitux> and we even use specific c construct in our headers
[15:23:17 CEST] <BBB> I think weve typically suggested c++ projects to use extern C { around their av* header includes
[15:23:25 CEST] <BBB> and that works fine
[15:23:25 CEST] <ubitux> yes
[15:23:43 CEST] <BBB> oh you mean libav will do that?
[15:23:45 CEST] <BBB> good for them
[15:23:48 CEST] <BBB> let them do it
[15:23:55 CEST] <BBB> I mean, if thats the best value they can add to the project
[15:23:58 CEST] <BBB> weve come a long way
[15:24:00 CEST] <ubitux> well i don't know if they're going to, but someone is starting to suggest patches
[15:24:02 CEST] <BBB> congrats guys
[15:27:01 CEST] <wm4> well, I sure hope they won't accept an incomplete patch
[15:27:08 CEST] <wm4> (extern C for some headers but not all)
[15:30:51 CEST] <Daemon404> g 56
[15:32:21 CEST] <ubitux> michaelni: has dilaroga write access to the git?
[15:32:34 CEST] <ubitux> i haz english
[15:40:03 CEST] <BBB> michaelni: at some point you added code to h264 so that if you seek in a file (in e.g. ffplay), it skips until the next keyframe; do you remember what commit that was? Id like to recreate that in hevc
[15:49:58 CEST] <nevcairiel> that is quite a bunch of commits working together, the initial implementation had a bunch of issues
[16:36:49 CEST] <__gb__> hi nevcairiel, have you noticed any regression in dxva2/h264 on master with interlaced streams?
[16:37:01 CEST] <nevcairiel> no
[16:37:26 CEST] <nevcairiel> If i had, I would've fixed it
[16:37:32 CEST] <nevcairiel> not like anyone else cares about h264
[16:37:39 CEST] <nevcairiel> eh dxva2
[16:37:40 CEST] <__gb__> the conformance streams in question are not in fate-test
[16:37:46 CEST] <nevcairiel> i shouldn't be doing 10 things at the sme time
[16:39:33 CEST] <__gb__> bisect'ed to d8151a7
[16:39:36 CEST] <wm4> michaelni: your libswresample fix is faulty... now it remembers the state from the first config call, and when closing and reopening it doesn't re-decide
[16:40:43 CEST] <__gb__> and reproducible with libav (a12d318) 
[16:41:26 CEST] <nevcairiel> maybe it only affects ancient intel devices which use the long slice syntax?
[16:41:42 CEST] <nevcairiel> or on which hardware are you testing?
[16:41:52 CEST] <__gb__> ivybridge :)
[16:42:19 CEST] <__gb__> but with vaapi and that one hasn't changed
[16:42:23 CEST] <nevcairiel> that should use the short slices syntax, so thats not it
[16:42:39 CEST] <__gb__> turns out the "reference" fields is not correctly propagated, i.e. it's stuck to "frame"
[16:42:51 CEST] <__gb__> nevcairiel, no short-syntax decode in vaapi
[16:42:56 CEST] <nevcairiel> ah
[16:43:01 CEST] <nevcairiel> silly vaapi
[16:43:08 CEST] <__gb__> well, not in the open source driver
[16:43:14 CEST] <__gb__> in practice, this yields nothing
[16:43:26 CEST] <__gb__> I mean short vs. long in terms of power & performance
[16:44:06 CEST] <nevcairiel> for dxva2, in the past it was just terribly annoying to support the long syntax version for intel only, while nvidia and amd never needed it .. but luckily that is in the past
[16:44:23 CEST] <nevcairiel> anyhow, can you share the conformance sample that fails? 
[16:44:25 CEST] <__gb__> i.e. you still have to parse slice level headers in both cases for ref frames management
[16:45:23 CEST] <__gb__> SP1_BT_A, FM1_FT_E, FM2_SVA_C, FM1_BT_B and sp2_bt_b
[16:47:20 CEST] <wm4> michaelni: and libavresample probably has the same issue
[16:48:52 CEST] <__gb__> nevcairiel, oh, there are many more -- just completed the full run with & without the hashes I mentioned
[16:49:23 CEST] <__gb__> i.e. 41 new failures
[16:49:35 CEST] <nevcairiel> the ones you listed are documented on some wiki page as not supported
[16:50:18 CEST] <nevcairiel> ie. FM* is FMO which we apparentlky dont do
[16:50:30 CEST] <__gb__> extended -> main for some, anyway, will copy the list
[16:51:01 CEST] <__gb__> cavlc_mot_fld0_full_B for one
[16:52:51 CEST] <wm4> michaelni: I'll work it around... apparently reusing a resample context after closing it is not sane
[16:53:30 CEST] <__gb__> pastebin.com/VqVXYN1L
[16:54:02 CEST] <nevcairiel> let me build a fresh ffmpeg and i'll run the fate tests with hwaccel
[16:54:36 CEST] <__gb__> (don't care about BA3_SVA_C [possible driver issue] and CVFI1_Sony_D [usual crop issue])
[16:54:41 CEST] <__gb__> thanks
[16:55:05 CEST] <nevcairiel> i didnt hear anything from my users though, they usually find such things quickly
[16:56:02 CEST] <nevcairiel> looking at vaapi code, it looks like fill_vaapi_pic might be the problem
[16:56:10 CEST] <nevcairiel> it only gets passed the full H264Frame, not the ref-list entry
[16:56:18 CEST] <nevcairiel> so the ->reference field it works on might be the wrong one
[16:56:41 CEST] <nevcairiel> H264Picture, not frame
[16:57:45 CEST] <nevcairiel> so make that function take H264Ref instead, and deref to ref->parent wherever needed
[16:58:24 CEST] <__gb__> iirc, that was changed to H264Ref, let me check again
[16:59:15 CEST] <nevcairiel> looks like h264 might have the same problem, but nothing uses the long form decoding anymore, so noone noticed
[16:59:46 CEST] <__gb__> you don't use H264Ref in dxva2 either
[17:00:07 CEST] <__gb__> will probably work on a fix tomorrow, or use 2.6 in the interim
[17:00:47 CEST] <__gb__> (unless you beat me on that)
[17:00:53 CEST] <nevcairiel> i cant test vaapi
[17:01:16 CEST] <nevcairiel> so unless dxva2 in short slice syntax also fails
[17:01:30 CEST] <nevcairiel> (and on nvidia at that, dont have a intel gpu handy right now)
[17:02:59 CEST] <nevcairiel> fate-h264-conformance-cavlc_mot_fld0_full_b works at least
[18:08:06 CEST] <michaelni> wm4 how can i reproduce the swr issue ?
[18:08:37 CEST] <michaelni> ubitux, i think no
[18:09:31 CEST] <wm4> michaelni: allocate a swresample context, open it with s16 5.1 as input and output formats, close it, open it again this time with stereo/float as output format
[18:09:34 CEST] <michaelni> BBB, dont remember but like nevcairiel said it was several commits, there where some fixes for keyframe less streams
[18:21:34 CEST] <michaelni> wm4, the issue is soxr specific or happens without soxr ?
[18:22:38 CEST] <wm4> michaelni: not soxr specific... it's because internal_sample_fmt is set to a value other than AV_SAMPLE_FMT_NONE, which disables the format selection logic
[18:22:53 CEST] <michaelni> ok, thx now i understand
[18:23:31 CEST] <wm4> (I've already worked it around, there are probably more issues like this lingering since this doesn't ever get tested)
[18:35:34 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:0dd2790df50e: swresample/swresample: Clear delayed_samples_fixup in clear_context()
[18:35:35 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:d4325b2fea9e: swr: Remember previously set int_sample_format from user
[18:40:47 CEST] <rcombs> durandal_1707: any idea what a REGN chunk might be?
[18:42:12 CEST] <durandal_1707> first time heard
[18:45:23 CEST] <rcombs> it's in a few Splatoon files and a couple Fire Emblem ones
[18:45:39 CEST] <rcombs> one of the Splatoon ones doesn't have the loop flag set, but I'm pretty sure it loops in-game
[18:46:16 CEST] <rcombs> and it also has 0x0C in the presumed-to-be-padding byte between the channel count and the sampling rate
[18:47:25 CEST] <rcombs> 3104 bytes of& something or other
[18:47:29 CEST] <rcombs> it's mostly 0x00s
[19:07:52 CEST] <Daemon404> jamrial, fyi we have been complaining about the "filesystem" api since long before it was even a gsoc proposal
[19:07:56 CEST] <Daemon404> it is always swiftly ignored
[19:08:08 CEST] <Daemon404> something akin to "debbit downers nto welcome"
[19:08:17 CEST] <Daemon404> or *one* guy saying "well *I* find it useful"
[19:08:30 CEST] <jamrial> ah, then that's a different story, yeah
[19:09:26 CEST] <Daemon404> as for gsoc, it may be to save face if not enough students were accepted
[19:09:27 CEST] <Daemon404> i dunno.
[19:09:32 CEST] <kierank> Daemon404: ...
[19:09:40 CEST] <Daemon404> kierank, ?
[19:09:49 CEST] <kierank> the whole filesystem bullshit
[19:09:54 CEST] <Daemon404> yes
[19:09:57 CEST] <Daemon404> it's fucktarded
[19:10:00 CEST] <Daemon404> it has been sicne day 1
[19:10:04 CEST] <Daemon404> many have complained sicne day 1
[19:10:08 CEST] <Daemon404> and every subsequent time
[19:10:11 CEST] <Daemon404> it's all useless
[19:10:13 CEST] <Daemon404> it chugs ahead anywya.
[19:11:09 CEST] <Daemon404> ffmpeg also has this terrible habbit of the following process:
[19:11:12 CEST] <Daemon404> 1) terrible idea is sent
[19:11:14 CEST] <Daemon404> 2) it is rejected
[19:11:22 CEST] <Daemon404> 3) it is sent again in a few months
[19:11:28 CEST] <Daemon404> 4) pushed, because dissenting parties didnt see it
[19:12:10 CEST] <Daemon404> 1 and 2 may be repeated ad nauseum
[19:13:43 CEST] <cone-309> ffmpeg 03Tobias Rapp 07master:2abdc6f477a3: fate: add some tests for ffv1 level 3 with 8/10/16 bps
[19:14:47 CEST] <jamrial> in that case philipl's suggestion to use review tools like reviewboard or gerrit may come in handy
[19:14:54 CEST] <jamrial> to make sure unwanted additions don't sneak by :p
[19:15:37 CEST] <Daemon404> i doubt it helps
[19:15:43 CEST] <BtbN> i hate gerrit, not because of code review, but because it's gerrit.
[19:15:49 CEST] <Daemon404> usually the response to dissent is "BUT IT'S A FEATURE"
[19:15:53 CEST] <BtbN> ReviewBoard seems better to me
[19:15:58 CEST] <Daemon404> and it gets added ti teh avgarbagedump
[19:17:57 CEST] <philipl> I know that it's disruptive if you're used to an email centric workflow, but when we first switched after years of the usual email thing, it was a real improvement.
[19:18:14 CEST] <philipl> Your workflow needs to change but it doesn't make you less productive.
[19:18:59 CEST] <Daemon404> philipl, you wont find any support unless the thing has a cli or mail interface
[19:19:08 CEST] <Daemon404> many here are used to ML + mutt
[19:19:10 CEST] <Daemon404> for patches
[19:19:19 CEST] <Daemon404> web ui wont go down well
[19:19:26 CEST] <Daemon404> my 2 cents
[19:19:31 CEST] <Daemon404> i could be wrong
[19:19:43 CEST] <philipl> Daemon404: No doubt, but honestly if the majority of developers don't want to change, then there's no point pushing hard for it.
[19:19:50 CEST] <wm4> Daemon404: well, I did see it, but I was already accused of trolling often enough
[19:19:59 CEST] <Daemon404> wm4, yes that pisses me off
[19:20:04 CEST] <Daemon404> commenting on a bad design or feature
[19:20:07 CEST] <Daemon404> is "trolling"
[19:20:14 CEST] <Daemon404> it's called a bloody review
[19:20:19 CEST] <Daemon404> you review design and ideas
[19:20:21 CEST] <Daemon404> not just code.
[19:20:24 CEST] <Compn> philipl : well, we can always try using reviewboard and see if any of us like it :P
[19:20:36 CEST] <philipl> reviewboard lets you reply to reviews by email if you really want, and there's a review request management cli but it probably won't satisfy you.
[19:20:37 CEST] Action: Compn doing the 'lets try it' thing Daemon404 hates
[19:20:46 CEST] <philipl> Yes, we can always just have it there and have people choose to use it or not.
[19:20:57 CEST] <durandal_1707> rcombs: are you gonna send patch about last packet with noise?
[19:21:01 CEST] <Compn> as long as someone volunteers to admin it :P
[19:21:12 CEST] <Daemon404> philipl, michaelni is the one you will have to convince
[19:21:16 CEST] <Daemon404> he does the bulk of reviews
[19:21:18 CEST] <Daemon404> and pushes
[19:21:24 CEST] <philipl> I'm willing to admin it if we do it.
[19:21:27 CEST] <philipl> Daemon404: agreed.
[19:22:04 CEST] <philipl> Right now, I'm suffering enough with my GSoC student that I sometimes feel its worth it just to set it up and if it's only him and me, I still win.
[19:22:08 CEST] <Daemon404> i dont think ive used a review system that handles patch sets, inline comments, and multiple patchste revisions, dropping patches from a series
[19:22:11 CEST] <Daemon404> etc
[19:22:14 CEST] <Daemon404> not all of them, i mean
[19:22:15 CEST] <Daemon404> maybe 1.
[19:22:28 CEST] <Daemon404> usually they fail in at least 1 respect
[19:22:36 CEST] <Compn> wonder what linus uses
[19:22:39 CEST] Action: Compn runs
[19:22:40 CEST] <philipl> Daemon404: reviewboard doesn't do patch sets as a first class entity.
[19:22:46 CEST] <Daemon404> linus uses alpine and a mailing list c
[19:22:47 CEST] <Daemon404> Compn, 
[19:22:48 CEST] <philipl> He does email + Mutt, to be sure.
[19:22:50 CEST] <Daemon404> similar to michaelni.
[19:23:10 CEST] <durandal_1707> fork it
[19:23:13 CEST] <philipl> I'm surprised you guys are so tolerant of attachment patches, given this.
[19:23:23 CEST] <philipl> They make reviews very tedious.
[19:23:26 CEST] <Daemon404> philipl, if a mimetype is set right, clients inline them
[19:23:44 CEST] <Compn> attachments can be made to display as text no matter what 
[19:23:49 CEST] <Compn> mime type.
[19:23:55 CEST] <philipl> Yes, they can, but then I hit reply and the patch isn't quoted :-)
[19:24:03 CEST] <Daemon404> my client does
[19:24:04 CEST] <Daemon404> i set it to.
[19:24:18 CEST] <Compn> what client are you using philipl ?
[19:24:27 CEST] <philipl> Claws.
[19:24:54 CEST] <Compn> i'm using claws too, or maybe slypheed fork
[19:25:20 CEST] <philipl> Maybe there's something I can turn on - right now I copy/paste-as-quoted the patch when I reply.
[19:25:24 CEST] <philipl> Not the end of the world, of course.
[19:25:46 CEST] <Daemon404> if it's inlined in your client
[19:25:52 CEST] <Daemon404> right click -> select all -> hit reply
[19:26:02 CEST] <Compn> highlighting/selecting makes it go in reply too
[19:26:16 CEST] <philipl> Ah - I never thought to do that from the attachment view, maybe it works there.
[19:26:39 CEST] <Compn> but then you lose comments sometimes :P
[19:26:40 CEST] <Compn> ehe
[19:26:45 CEST] <philipl> True.
[19:27:02 CEST] <Compn> bah who needs those?! code only! :) ehe
[19:27:29 CEST] <philipl> nevcairiel: Will you look at my vdpau/hevc change?
[19:27:50 CEST] <philipl> It's not very interesting if you believe me about the runtime behaviour, but someone needs to look at it.
[19:29:40 CEST] <philipl> As for reviewboard, I'll get an installation up and running so people can look at it. If nothing else, I'll make my student use it. :-)
[19:30:24 CEST] <wm4> who's the student?
[19:30:29 CEST] <philipl> Niklesh
[19:33:22 CEST] <Daemon404> philipl, what problems are you having
[19:33:36 CEST] <Daemon404> IME student problems are usually "student cannot follow instructions"
[19:33:40 CEST] <Daemon404> and doesnt apply changes
[19:47:39 CEST] <rcombs> durandal_1707: yes
[20:02:04 CEST] <philipl> Daemon404: He's not doing anything wrong but I hate going back and forth between the patch and the codebase. Reviewboard lets you expand the diff to show the full file
[20:24:35 CEST] <Compn> philipl : you havent memorized the code yet? :P
[20:24:41 CEST] <Compn> ehe
[20:25:03 CEST] Action: Compn runs diff in his head
[20:42:48 CEST] <cone-309> ffmpeg 03Shivraj Patil 07master:f6276842f38d: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for block functions
[20:56:18 CEST] <cone-309> ffmpeg 03Luca Barbato 07master:2ecfd451649c: Implement Snappy decompression
[20:56:19 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:9e5b0f070b69: Merge commit '2ecfd451649c7a08cb633635df98e59f7c6e2140'
[21:07:31 CEST] <durandal_1707> what is point of texture codecs, to use in games?
[21:08:17 CEST] <cone-309> ffmpeg 03Vittorio Giovara 07master:8337e0c57345: Introduce a TextureDSP module
[21:08:18 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:d1dc22dddd79: Merge commit '8337e0c57345f24cf6471220e5f8a0ea21b7c1d0'
[21:32:01 CEST] <jamrial> michaelni: the j2k-dwt test seems to fail on several fate clients
[21:33:47 CEST] <jamrial> it crashes on msvc, and fails on some linux, freebsd, os2 and mingw32 clients
[21:36:12 CEST] <jamrial> seems to be always on x86_32, save for msvc where it just crashes regardless of arch
[22:31:36 CEST] <cone-309> ffmpeg 03Vittorio Giovara 07master:c0b105756f61: txd: Use the TextureDSP module for decoding
[22:31:37 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:a5b2b22d9a45: Merge commit 'c0b105756f61d253bdabcc2bb49453a2557e7c3b'
[22:31:38 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:4df3cf90bf7a: swscale/rgb2rgb_template: Disable shuffle_bytes_2103_c on big endian
[23:05:07 CEST] <cone-309> ffmpeg 03Vittorio Giovara 07master:7ca3e5203f13: Hap decoder and encoder
[23:05:08 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:55219a78c7d0: Merge commit '7ca3e5203f133eb41a0b5c3a1d753a7427ba72e7'
[23:20:42 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:19dc1ed4ada3: avcodec/jpeg2000dwt: Use a tighter check threshold for the 9/7f DWT test
[23:20:43 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:8428e2c5f37e: avcodec/jpeg2000dwt: Print 1 digit less in the 9/7f DWT test
[23:20:44 CEST] <cone-309> ffmpeg 03Michael Niedermayer 07master:f067ee57c95d: avcodec/jpeg2000dwt: Move large arrays used in the test code away from the stack
[23:21:06 CEST] <michaelni> jamrial, fate j2kdwt issues maybe fixed
[23:32:19 CEST] Action: Daemon404 sits back and waits for his forty lashes
[23:39:35 CEST] <wm4> so uh can't we give this guy a more sensible task?
[23:39:48 CEST] <nevcairiel> probably not
[23:40:11 CEST] <Daemon404> no
[23:40:18 CEST] <Daemon404> once it has been accepted by google, it cannot change
[23:40:28 CEST] <wm4> I mean, all technical issues aside, it's not like I want to kick him out just because
[23:40:29 CEST] <Daemon404> don't worry, i'll be written off as an asshole/troll
[23:40:31 CEST] <Daemon404> life will go on
[23:40:34 CEST] <Daemon404> the API will be pushed
[23:40:57 CEST] <Daemon404> wm4, on the contrary, i feel bad for teh student
[23:41:19 CEST] <wm4> (also didn't the mentor say bye?)
[23:41:26 CEST] <Daemon404> lukasz?
[23:41:31 CEST] <wm4> yeah
[23:41:31 CEST] <JEEBsv> yeah, he probably didn't know what kind of crapola he ended up grabbing
[23:41:39 CEST] <Daemon404> ... but it was his damn API for his sole use
[23:41:43 CEST] <Daemon404> and he up and left?
[23:41:47 CEST] <nevcairiel> why does it always feel like that arguments founded in actual logic just don't change anything, but if some non-developer wants to stop a patch that adds pkg-config support, it'll never ever get in? =P
[23:42:17 CEST] <wm4> it's like democracy
[23:42:37 CEST] <nevcairiel> democracy doesnt work for the goverment, who ever though its a good idea here? :p
[23:42:42 CEST] <Daemon404> nevcairiel, https://www.youtube.com/watch?v=ilcRS5eUpwk
[23:42:44 CEST] <Daemon404> i get this feeling
[23:42:45 CEST] <Daemon404> a lot.
[23:43:14 CEST] <wm4> Daemon404: he basically said he thought the community (us) was full of shit
[23:43:26 CEST] <Daemon404> ....
[23:43:37 CEST] <Daemon404> because we didnt want his awesome API?
[23:43:41 CEST] <JEEBsv> nîn
[23:43:48 CEST] <wm4> yes
[23:44:10 CEST] <wm4> (I wonder if anyone is using the libavdevice opengl support he left there...)
[23:44:55 CEST] <nevcairiel> Hey I used that code as a bit of inspiration when working on some other opengl stuff
[23:45:17 CEST] <Daemon404> you know
[23:45:27 CEST] <Daemon404> i thought i should sell all my stuff
[23:45:30 CEST] <Daemon404> and my house
[23:45:34 CEST] <Daemon404> and become a hermit
[23:45:39 CEST] <Daemon404> i'd be so much happier
[23:45:43 CEST] <nevcairiel> hermits need stuff
[23:46:04 CEST] <Daemon404> sure, i can collect bits of string, and dog corpses
[23:46:11 CEST] <Daemon404> i'd still feel more sane than i do on ffmpeg-devel
[23:46:12 CEST] <wm4> becoming a hermit sounds good... libavdevice/hermitdec.c?
[23:46:15 CEST] <nevcairiel> who is the mentor of that student now anyway
[23:46:19 CEST] <Daemon404> nevcairiel, lukasz.
[23:46:21 CEST] <Daemon404> who left.
[23:46:24 CEST] <nevcairiel> i thought he left
[23:46:28 CEST] <Daemon404> :D
[23:46:36 CEST] <nevcairiel> then he obviously isnt doing it anymore
[23:46:46 CEST] <jamrial> wow, his last email was from that youtube-dl patch
[23:46:46 CEST] <wm4> so this whole situation is a bit strange
[23:46:48 CEST] <jamrial> it really made him quit
[23:47:09 CEST] <Daemon404> jamrial, that thread... lol
[23:47:13 CEST] <Daemon404> that whole threads was nuts
[23:47:25 CEST] <wm4> man, all these issues are because people want to coerce stuff into the existing libav*s
[23:47:38 CEST] <Daemon404> stop being downer, MAN
[23:47:42 CEST] <Daemon404> what are you, a NARK?
[23:47:50 CEST] <Daemon404> er, NARC
[23:47:52 CEST] <jamrial> the patch didn't make it in, so now you can't say that everything gets pushed even if people are against it :p
[23:48:05 CEST] <Daemon404> jamrial, and it only cause one person to quite
[23:48:07 CEST] <Daemon404> quit*
[23:48:09 CEST] <Daemon404> to keep it out
[23:48:14 CEST] <nevcairiel> its the same thing everytime, they want their own live to be as easy as possible, so shoving stuff into the library they already use is a cheap way out
[23:48:23 CEST] <wm4> crazy if you think about it
[23:48:38 CEST] <wm4> well, if ffmpeg were gstreamer, it'd be fine
[23:48:47 CEST] <wm4> because gstreamer can have plugins for all kinds of stufddf
[23:48:53 CEST] <wm4> but ffmpeg is not gstreamer
[23:48:59 CEST] <Daemon404> yet
[23:49:24 CEST] <wm4> and even if you regret that ffmpeg is not gstreamner, you can't just change it by using a muxer interface as video output API and shit
[23:50:19 CEST] <nevcairiel> isnt the entire point of avdevice to use muxer/demuxer as hardware interfaces
[23:50:29 CEST] <nevcairiel> in that context it even makes a bit of sense
[23:50:58 CEST] <wm4> to me it seems like it's a cheap hack for dealing with ffmpeg.c being monolithic
[23:51:20 CEST] <nevcairiel> probably, but then everything in avdevice falls into that category
[23:51:30 CEST] <nevcairiel> not only the opengl out
[23:51:35 CEST] <wm4> of course
[23:51:45 CEST] <wm4> libavdevice is insane
[23:52:23 CEST] <nevcairiel> the demuxing parts just happen to work somewhat, and people wanted audio and video capture
[23:52:36 CEST] <wm4> the new place to dump everything is libavfilter, but at least that makes slightly more sense
[23:52:55 CEST] <wm4> yeah, but it should have been in ffmpeg.c or a separate API
[23:53:07 CEST] <wm4> I'm not arguing against ffmpeg.c being able to capture video
[23:53:19 CEST] <wm4> I'm just some sort of API cleanness troll
[23:53:44 CEST] <Daemon404> stop trying to actually design things
[23:53:45 CEST] <Daemon404> its trolling
[23:53:46 CEST] <nevcairiel> didnt libav want to merge avdevice into avformat some time ago
[23:53:53 CEST] <Daemon404> i didnt think so
[23:54:17 CEST] <nevcairiel> because its essentially just muxers and demuxers being the prime reasoning
[23:54:47 CEST] <wm4> I think that discussion was more about stopping pretending that lavd and lavf are separate libs
[23:54:57 CEST] <wm4> (lavd uses lavf internals)
[23:55:12 CEST] <nevcairiel> it has to,  cant build demuxers without it
[23:57:45 CEST] <Daemon404> wm4, im trying to think
[23:57:50 CEST] <Daemon404> like
[23:57:52 CEST] <Daemon404> gsoc.
[23:57:58 CEST] <Daemon404> we cant have him work on somethign else
[23:58:00 CEST] <Daemon404> that'd get us banned.
[23:58:04 CEST] <Daemon404> so wat do
[23:58:09 CEST] <Daemon404> i feel bad for the guy.
[23:58:38 CEST] <nevcairiel> whats his proper task description anyway
[23:59:34 CEST] <Daemon404> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015
[23:59:37 CEST] <Daemon404> i cant actually find it
[23:59:50 CEST] <llogan> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015#Browsingcontentontheserver
[00:00:00 CEST] --- Tue Jun 23 2015