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

[burek]

[00:18:54 CET] <kierank> michaelni: why is GBRAP16 not mentioned in libavcodec/utils.c?
[00:32:38 CET] <michaelni> likely forgotten
[00:36:27 CET] <kierank> ...
[00:37:55 CET] <kierank> michaelni: same question as to why there's no to_a function for gbrap16 in swscale?
[00:42:28 CET] <BBB> I belive in general we dont have 16bpp output, just input, in swscale
[00:43:29 CET] <kierank> BBB: should have said in libswscale/input.c
[00:43:52 CET] <BBB> oh ok
[00:47:34 CET] <wm4> BBB: uh, there's 16 bit yuv output
[00:48:07 CET] <BBB> really? oh, ok, I stand corrected then
[01:02:09 CET] <andrey_utkin> i have posted a kind of survey about email tools to LKML, I'd like to know opinion of FFmpeg developers, too: http://marc.info/?l=linux-kernel&m=145480282311605&w=2
[01:02:35 CET] <andrey_utkin> how do you look at posting this on ffmpeg-devel, while it is 100% offtopic?
[01:04:32 CET] <andrey_utkin> and where else I could ask to get replies relevant to my personal issues with email?
[01:04:54 CET] <J_Darnley> I am satisfied with my combination of gmail and thunderbird
[01:05:13 CET] <J_Darnley> but then ffmpeg-devel is the busiest list I'm on
[01:06:03 CET] <Gramner> I'm not subscribed to the lkml but I can imagine the volume there being _slightly_ larger than ffmpeg-devel
[01:06:07 CET] <J_Darnley> If you are not already using gmail's filters, you should use them to filter mail by list
[01:06:32 CET] <andrey_utkin> yep I love how gmail got maillists filtering
[01:06:39 CET] <J_Darnley> In Gmail's terms: apply label and skip inbox
[01:06:48 CET] <andrey_utkin> but see about git-send-email in my posting
[01:07:08 CET] <J_Darnley> I'm afraid I abuse my ISP's smtp server for that
[01:08:50 CET] <andrey_utkin> and you never had issues as you read email on gmail and sending patches NOT from gmail? well, i guess it's possible, just may confuse your peers, they'd need to recognize that your two email addresses belong to same identity
[01:08:50 CET] <J_Darnley> Sorry I wasn't very helpful
[01:08:54 CET] <Gramner> I'm using gmail with a custom domain, works decently enough
[01:10:46 CET] <J_Darnley> Well I don't send email with a "From:" address of telenet.be.  I just lie and say gmail.com.  I duid use the verb "abuse"
[01:10:57 CET] <J_Darnley> *did
[01:11:29 CET] Action: J_Darnley wonder what his gitconfig says
[01:12:11 CET] <J_Darnley> No authentication at all
[01:13:18 CET] <andrey_utkin> haha
[01:13:46 CET] <Gramner> sounds legit
[01:14:05 CET] <cone-678> ffmpeg 03Michael Niedermayer 07master:2272ab0e84de: avformat/mp3enc: Assert that the header we assembled is valid
[01:14:06 CET] <cone-678> ffmpeg 03Michael Niedermayer 07master:9ee4c89348c5: avcodec/utils: Add AV_PIX_FMT_GBRAP16?E to avcodec_align_dimensions2()
[01:14:18 CET] <andrey_utkin> but at some moment some maillist servers could begin to require DKIM and such. Or your provider could fix that hole (god forbid)
[01:15:03 CET] <J_Darnley> Sure.  I don't know what I would do when that happens.
[01:15:53 CET] <Gramner> doesn't dkim/spf fail hard with mailing lists?
[01:16:07 CET] <BBB> andrey_utkin: I use gmail, and git send-email works for me
[01:16:28 CET] <Gramner> since the mailing list will resend the message from a different server while sitll claiming to be from the original sender
[01:16:29 CET] <BBB> andrey_utkin: I wouldnt say its great, but at least it can split basic threads
[01:19:38 CET] <Gramner> I guess you could add the ML mailserver to the SPF list of approved hosts if you have your own domain, but that would be very annoying to keep up to date with several MLs
[01:25:46 CET] <ubitux> Gramner: it's about 10 times larger iirc
[01:26:06 CET] <Gramner> only 10?
[01:26:13 CET] <andrey_utkin> Gramner: i believe DKIM signature will be added on SMTP server where sender's mailbox resides. DKIM signature is done over just selected headers, so relaying and adding more headers doesn't invalidate the signature
[01:26:50 CET] <ubitux> Gramner: 5 to 10 last time i checked, but ff dev is like 1k to 2k mails per month, so&
[01:27:52 CET] <Gramner> andrey_utkin: last time i tried enabling dkim/spf on my domain my ML posts got spam flagged (normal direct emails worked correctly)
[01:29:30 CET] <ubitux> Gramner: last five months, ff:2310,1927,1660,2698,1699 - lklm:7225,5112,6899,4533,2203
[01:29:36 CET] <Gramner> apparently there's some X-Original-Authentication-Results header related to that
[01:33:00 CET] <Gramner> ubitux: oh, not that overwhelming then
[01:33:12 CET] <andrey_utkin> ... and lkml is just one of many maillists related to kernel. there are more - linux-media, linux-arm-kernel, netdev, driverdev.linuxdriverproject.org...
[01:38:01 CET] <andrey_utkin> J_Darnley: regarding filtering maillists out of inbox, do you have threads that mention you in recipients in your inbox? I don't and it's a problem for me :( Any advise?
[01:39:07 CET] <J_Darnley> No.  They get "labeled and skip inbox".  In thunderbird they appear in a different folder
[01:39:55 CET] <J_Darnley> Unless someone emails me directly and then the email doesn't get a List-Id header
[01:40:09 CET] <J_Darnley> Cc can do that
[01:40:27 CET] <J_Darnley> so I don't usually Cc myself
[01:41:20 CET] <andrey_utkin> it's a problem because I occasionally there are threads which are sent to maillist + CC to me (at once) because I am maintainer of something. So my reaction is expected, but I miss that completely because the letter skips inbox
[01:41:48 CET] <andrey_utkin> CC to maintainers at once with posting to maillists is common on LKML
[01:41:56 CET] <J_Darnley> Ah.  I can't say what happens in that regard.
[01:42:24 CET] <andrey_utkin> I can - it still skips inbox :)
[01:43:00 CET] <andrey_utkin> maybe some additional filtering rule may fix that
[01:43:23 CET] <J_Darnley> Do you want me to login and check exactly what my rules are?
[01:43:26 CET] <andrey_utkin> but may break everything else if applied in generic way
[01:43:31 CET] <andrey_utkin> no
[01:44:01 CET] <andrey_utkin> just was curious to know if you know this issue and have solved it in a good way
[01:44:35 CET] <J_Darnley> Sorry, I don't.
[01:44:35 CET] <andrey_utkin> i guess your rules are what gmail itself suggests - it suggests to filter basing on List-Id
[01:44:51 CET] <andrey_utkin> np, thanks to all of you for your keen feedback
[02:04:32 CET] <kierank> hmm i need some premiere pro cineform samples
[02:34:40 CET] <andrey_utkin> so far, I've got two replies from mutt-ers, one of them being Greg KH, who recommended "to take a week or two to learn mutt".
[08:59:40 CET] <nevcairiel> andrey_utkin: i have no problems with gmail and send-email, no delays whatsoever, so maybe its on your end : D
[09:26:13 CET] <andrey_utkin> nevcairiel: i have evidence that I'm not the only one experiencing it
[09:26:26 CET] <andrey_utkin> https://lkml.org/lkml/2016/1/3/148
[09:26:59 CET] <nevcairiel> might be some other common component, like sendmail which I think git uses?
[11:39:49 CET] <durandal11707> Daemon404: are you using fieldhint?
[12:52:52 CET] <cone-761> ffmpeg 03Paul B Mahol 07master:f5c3f85eb25c: avfilter: add swaprect filter
[13:08:57 CET] <Daemon404> durandal_1707, ?
[13:10:09 CET] <durandal_1707> Daemon404: the avs/vs filter
[13:12:05 CET] <Daemon404> i used the avs one quite heavily, but i have not had to perform ivtc in quite some time
[13:12:13 CET] <Daemon404> years even
[13:14:11 CET] <durandal_1707> i'm wondering about this ovr file which is used by fieldhint, in reality are fields really so far way, even by 42 frames in past of future?
[13:17:24 CET] <Daemon404> that sounds a bit funny, but the ovr file is useful for when it gets the pattern wrong
[13:17:37 CET] <Daemon404> i always used it for manually adjusting field match errors
[13:17:48 CET] <Daemon404> it's a heuristic after all.
[13:18:44 CET] <durandal_1707> lavfi doesn't really have support for picking random frame from stream
[13:19:55 CET] <Daemon404> it can keep a count im sure...
[13:19:59 CET] <Daemon404> in order to consume such a file
[13:20:14 CET] <Daemon404> but yes lavfi is not very good at anything but streaming.
[13:21:00 CET] <Daemon404> im not sure an ovr file could work at all without some sort of frame number info
[15:52:06 CET] <cone-761> ffmpeg 03Clément BSsch 07master:6c0318c4ba8e: lavfi/fieldmatch: fix fields copy when plane height is odd
[16:28:55 CET] <ubitux> wm4: it makes me wonder, should i actually reset the readorder on flush at all? 
[16:29:32 CET] <ubitux> like, you don't need it, but in most cases, assuming the user flushes the ass context, does it even need to have a reset counter to zero?
[16:29:34 CET] <wm4> ubitux: that's a good question, I don't know in what other scenarios it could be needed
[16:30:09 CET] <wm4> actually, _if_ the user flushes the ass_track, then resetting to zero would be better
[16:30:19 CET] <wm4> because libass uses a bitmap to check for readorder duplicates
[16:30:24 CET] <wm4> it's all fucked up
[16:30:39 CET] <ubitux> a bitmap?
[16:30:58 CET] <ubitux> it's doing a crc on the rendered sub and compare them? :D
[16:31:46 CET] <wm4> no, the ReadOrder value is used as index into a bitmap
[16:32:29 CET] <wm4> since ReadOrder values normally start at 0 or 1 and don't skip numbers, it's the most efficient way to do it
[16:34:52 CET] <ubitux> ok so we don't want that readorder to grow too much
[16:35:16 CET] <ubitux> and there is no notion of "first readorder occured [post seek]"
[16:35:35 CET] <wm4> I guess I don't mind much if your change will pick either behavior and makes it not configurable
[16:35:59 CET] <wm4> I've also added an API function to libass that completely disables the ReadOrder check
[16:36:18 CET] <ubitux> i'm just wondering about what solution to follow
[16:37:17 CET] <wm4> for my own purposes, not resetting ReadOrder would be most useful for now, but I'm not sure at all about the general API user
[16:37:23 CET] <ubitux> one solution would be to add a packet side data, and let the demuxer set that readorder
[16:37:31 CET] <wm4> (or what I'll do in future in mpv too)
[16:37:47 CET] <ubitux> so the decoder could read it back and use it in the dialogue
[16:38:02 CET] <ubitux> that could would work with at least all standalone subtitles demuxers
[16:38:43 CET] <ubitux> as well as any demuxer supporting ass (where we can simply read the readorder and flag the packet with that info)
[16:39:13 CET] <ubitux> ...but it won't work with many other, like, what's happening for text subtitles from ogg or whatever
[16:39:33 CET] <wm4> what about ogg?
[16:39:36 CET] <ubitux> so i actually need to something about the case where the readorder really is unknown
[16:39:42 CET] <wm4> oh
[16:39:43 CET] <ubitux> i picked ogg but could be any
[16:42:00 CET] <wm4> maybe you could provide API to set ReadOrder explicitly (and the "decoder" would increment it after every packet)
[16:42:40 CET] <wm4> and then make keeping ReadOrder after flush the default (not sure if sane?)
[16:42:54 CET] <ubitux> a start_readorder avoption in the decoder?
[16:43:53 CET] <ubitux> (and avcodec_flush_buffers would av_opt_set_int(d,"start_readorder",0,0) which you can override yourself after calling it?)
[16:44:23 CET] <ubitux> (or simply a flag to not call it yeah)
[16:45:24 CET] <wm4> can avoptions be set after a decoder was opened?
[16:45:55 CET] <ubitux> i guess so
[16:46:52 CET] <kierank> I believe yes
[17:02:15 CET] <wm4> you could argue that if someone encodes multiple segments from a source file, that seeking should not reset the readorder, but let it increment normally
[17:02:25 CET] <wm4> (OTOH that doesn't work for codec copy anyway)
[17:14:06 CET] <kierank> any ideas where I can find premiere pro cineform rgba 444 12-bit samples?
[17:26:06 CET] <durandal_1707> kierank: buy it
[17:26:23 CET] <kierank> lol no
[17:27:29 CET] <kierank> durandal_1707: it's not a bug for mpeg2video to produce samples out of rage
[17:27:32 CET] <kierank> range
[17:27:39 CET] <kierank> this is the entire point of having limited range
[17:27:44 CET] <kierank> to allow for things to go over and under a bit
[17:27:48 CET] <kierank> instead of clipping
[17:28:15 CET] <durandal_1707> but than its not broadcast safe
[17:28:29 CET] <durandal_1707> rage even
[17:28:30 CET] <kierank> yes so you clip at your output device
[17:28:32 CET] <kierank> or whatever
[17:28:41 CET] <kierank> but actually a little bit of overshoot is allowed
[17:28:46 CET] <kierank> since it's not analogue any more
[17:29:16 CET] <durandal_1707> its not overshot, there are pixels with 255 values and nothing inbetween
[17:32:28 CET] <kierank> ?
[17:37:00 CET] <durandal_1707> what's not clear?
[17:52:14 CET] <wm4> everything
[18:11:03 CET] <cone-761> ffmpeg 03Timothy Gu 07master:6cdde20beb98: dirac_dwt: Don't pass information in context as arguments
[18:11:04 CET] <cone-761> ffmpeg 03Timothy Gu 07master:58ded09bd14e: dirac_dwt: Rename init2 to init
[18:11:05 CET] <cone-761> ffmpeg 03Timothy Gu 07master:e04912c0b673: diracdec: Split DWTPlane struct from Plane
[18:11:06 CET] <cone-761> ffmpeg 03Timothy Gu 07master:671761d71367: diracdec: Pass DWTPlane to dwt init
[18:15:14 CET] <cone-761> ffmpeg 03Timothy Gu 07master:32fed702b8a4: libvpxenc: Allow setting tune parameter
[18:19:59 CET] <cone-761> ffmpeg 03Timothy Gu 07master:59ebf32bca7e: huffyuvencdsp: Undefine "i" macro after each use
[18:26:29 CET] <cone-761> ffmpeg 03Timothy Gu 07master:0bcffc792424: diractab: Fix header guard name
[18:45:45 CET] <durandal_1707> ubitux: i dont think 8bit videos have enough dynamic so that this eurealian magnification can work
[18:46:13 CET] <ubitux> afaik it does
[18:47:17 CET] <durandal_1707> i dont see single difference with tblend in changes of color
[18:47:48 CET] <durandal_1707> but i dont have static videos of someone's part of body
[18:50:26 CET] <Daemon404> do you have a phone? and a face?
[18:50:51 CET] <ubitux> durandal_1707: i remember a demo where a guy implemented it live with its webcam
[18:52:51 CET] <durandal_1707> Daemon404: too much noise
[18:53:35 CET] <ubitux> durandal_1707: https://www.youtube.com/watch?v=lZSTceTXjP4 with video source linked
[18:56:23 CET] <ubitux> durandal_1707: actually, http://people.csail.mit.edu/mrub/evm/#code look for "data" below
[18:56:28 CET] <ubitux> "source"
[18:56:55 CET] <ubitux> many video sources here
[19:21:09 CET] <durandal_1707> ubitux: only with this hand source sample its obvious when neckless move together with hand
[19:50:35 CET] <cone-761> ffmpeg 03Paul B Mahol 07master:ba618bde7f13: avfilter/vf_blend: add multiply128 mode
[19:55:48 CET] <durandal_1707> ubitux: how much far away fields may be from one another with telecine material?
[19:56:53 CET] <ubitux> just 1?
[19:57:49 CET] <kierank> hahahah with ffmpeg you can't actually demux an mpegts determinisitcally
[19:57:59 CET] <kierank> because it does probing and orders the streams as it sees them
[19:59:05 CET] <durandal_1707> kierank: fix it
[19:59:16 CET] <kierank> not possible because I'm sure it will break broken samples
[19:59:19 CET] <JEEB> lol
[19:59:35 CET] <wm4> kierank: what do you mean by this
[19:59:36 CET] <kierank> the ffmpeg(tm) way is to have broken samples work ahead of 99% of usual things
[19:59:41 CET] <JEEB> yeah, i thimk I've seen the results of that
[19:59:46 CET] <kierank> wm4: if you have a video track with say 3 audio tracks
[19:59:49 CET] <JEEB> @ mpegts
[19:59:55 CET] <kierank> it'll order them by stream-id as it finds data
[19:59:55 CET] <ubitux> honor a strict compliance flag
[19:59:58 CET] <durandal_1707> kierank: ignore broken samples, I will back up you, I have body guards
[19:59:59 CET] <kierank> not as how they are ordered
[20:00:10 CET] <JEEB> ye
[20:00:26 CET] <wm4> even if you order them as they come, wouldn't it depend when you start grabbing the infinite source stream?
[20:00:45 CET] <kierank> no because it's listed in the PMT how you should order tehm
[20:00:53 CET] <JEEB> yup
[20:00:54 CET] <wm4> ok
[20:01:04 CET] <kierank> but I guess ffmpeg wants to play files without PMT so it breaks everything to get those things to work
[20:01:12 CET] <wm4> I don't understand how the sorting influences determinism though
[20:01:42 CET] <kierank> -c:a:0 refers to a different track
[20:01:55 CET] <kierank> depending on the packet which happens to arrive
[20:02:03 CET] <kierank> so most likely it's the highest bitrate audio
[20:02:12 CET] <kierank> so if it's eng, fra, ger
[20:02:18 CET] <kierank> sometimes you get 0:fra, eng, ger
[20:02:23 CET] <kierank> or sometimes 1:eng, fra, ger
[20:02:25 CET] <kierank> or whatever
[20:02:28 CET] <BtbN> maybe a second syntax, so you can explicitly specify you want pmt index 0?
[20:02:30 CET] <wm4> that's why you should select them by their id, not index
[20:04:05 CET] <JEEB> i think there also was a syntax for languagew
[20:07:55 CET] <kierank> how do you select ffmpeg stream by pid
[20:09:21 CET] <kierank> looks like on rtp streams you can't :(
[20:40:33 CET] <cone-761> ffmpeg 03James Almer 07master:be22bd32fe43: x86/cpu: set avxslow cpuflag on btver2 CPUs
[21:37:35 CET] <durandal_1707> michaelni: are you swscale maintainer?
[21:55:20 CET] <durandal_1707> few MB script of only null filters
[22:28:54 CET] <michaelni> durandal_1707, i try to review and test patches to swscale
[22:30:02 CET] <durandal_1707> michaelni: the color range stuff is incorrectly exposed, so getting rid of J formats is impossible
[22:35:04 CET] <michaelni> can you elaborate abut the problem ?
[22:35:46 CET] <durandal_1707> michaelni: the color_range/matrix/colorspace etc are not handled by lavfi
[22:36:21 CET] <durandal_1707> so even if frame have it set they are ignored by everything
[22:38:15 CET] <michaelni> lavfi uses pix_fmts for choosing where to insert convert not range, IIRC yes
[22:38:21 CET] <durandal_1707> this is good candidate for gsoc, stuff nobody wants to work on
[22:38:34 CET] <michaelni> i wont mentor this
[22:38:51 CET] <Daemon404> "stuff nobody wants to work on" is a great candidate for gsoc?
[22:38:55 CET] <Daemon404> no wonder the studenst all leave after.
[22:39:05 CET] <kierank> yes that's the problem
[22:39:08 CET] <durandal_1707> i already know you are not gointg to mentor anything IIRC
[22:39:12 CET] <kierank> the gsoc page needs an rm -rf 
[22:39:16 CET] <kierank> and a restart with fresh new ideas
[22:39:20 CET] <michaelni> i am happy to mentor clear, self contained well deliniated work not fix & redesign apis
[22:39:54 CET] <Daemon404> +1
[22:40:15 CET] <durandal_1707> than swscale will bitrot
[22:40:40 CET] <kierank> good
[22:41:03 CET] <Daemon404> stuff that requires a lot of thought into design is a bad choice for a student
[22:41:14 CET] <Daemon404> thats how we ended up with some bad apis before
[22:43:30 CET] <nevcairiel> yeah one should have a bit of experience to tackle core problems like API design
[22:49:35 CET] <durandal_1707> if I add color range/color space negotiation to lavfi, will it be rejected because libav is missing it?
[22:49:53 CET] <Daemon404> ask wm4, he is basically the only user
[22:49:59 CET] <Daemon404> that uses both
[22:50:15 CET] <Daemon404> libav / ffmpeg's lavfi that is
[22:50:20 CET] <cone-761> ffmpeg 03Paul B Mahol 07master:6bdeac24e07e: avfilter/af_aformat: remove deprecated syntax from options description
[22:51:21 CET] <jamrial|2> kierank: a bunch of the gsoc 2015 projects are already done and commited, so it's not like the 2016 one would end up being the same
[22:51:44 CET] <Daemon404> jamrial|2, and look how many of the students stuck around
[22:51:55 CET] <nevcairiel> still a majority of those listed there have been listed for 5+ years and are just annoying things noone else wants to do
[22:52:09 CET] <jamrial> true
[22:52:09 CET] <durandal_1707> Daemon404: there is user that have 3MB script, no it is not vapoursynth
[22:52:24 CET] <Daemon404> durandal_1707, it must be generated
[22:52:32 CET] <Daemon404> writing 3mb by hand is insane
[22:53:22 CET] <durandal_1707> its some drawbox usage, wonder what exactly
[22:55:54 CET] <jamrial> Daemon404: atomnuker stuck around. one out of three or four isn't that bad
[22:56:41 CET] <Daemon404> i think it's a record ;)
[23:01:02 CET] <durandal_1707> whats about daala and dirac, why they are still not comitted?
[23:07:45 CET] <atomnuker> no one's fully okayed the dirac encoder
[23:08:28 CET] <durandal_1707> atomnuker: isn't patch missing file?
[23:08:55 CET] <atomnuker> one of the patches to split the tables from the decoder, yes
[23:09:07 CET] <atomnuker> but I did send a V2 which fixed that patch
[23:12:49 CET] <durandal_1707> atomnuker: i dont see it, link?
[23:15:57 CET] <atomnuker> durandal_1707: actually I forgot I pushed the V2 of that patch after michael LGTM'd it
[23:16:12 CET] <atomnuker> so all that's left is the patch to add the encoder itself
[23:17:04 CET] <atomnuker> which J_Darnley pointed out was find except that it was best to use ptrdiff_t for the strides, which I did change
[23:22:42 CET] <atomnuker> speaking of which, J_Darnley, durandal_1707, I've sent a v3 of that patch to the ML
[23:24:49 CET] <atomnuker> as for the Daala stuff, that might just into an effort to make an overengineered image format by me and whoever else's up to it
[23:25:04 CET] <durandal_1707> you always shall vertically align AVCodec entries
[23:25:24 CET] <jamrial> atomnuker: why are you calling it vc2 when the decoder is already called dirac?
[23:25:48 CET] <atomnuker> VC-2 is a subset of Dirac
[23:26:56 CET] <atomnuker> unless someone feels like extending the encoder with dirac only features (well, the only thing missing from VC-2 that's in dirac are P and B frames), then VC-2 seems more appropriate
[23:27:36 CET] <atomnuker> (believe me, if anyone saw what the decoder does with P and B frames he'd probably run away screaming)
[23:29:09 CET] <atomnuker> durandal_1707: what did you mean by that? AVCodec ff_vc2_encoder isn't aligned, but I can fix it when I'm merging it
[23:30:47 CET] <omerjerk> hey I was looking at this code - https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/utils.c#L2216
[23:31:19 CET] <omerjerk> Where would I find the implementation of read_seek for a particular format ?
[23:33:02 CET] <durandal_1707> omerjerk: in the format source code
[23:33:33 CET] <durandal_1707> atomnuker: bunch of whitespaces to make it look nice
[23:34:13 CET] <omerjerk> I did have a look here - https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroska.c
[23:35:03 CET] <omerjerk> but couldn't find it. 
[23:36:08 CET] <cone-761> ffmpeg 03Michael Niedermayer 07master:e7786959cc34: avfilter/vaf_spectrumsynth: Move "break" up
[23:36:42 CET] <durandal_1707> omerjerk: matroskadec.c
[23:37:22 CET] <omerjerk> oh. okay. makes sense. I should have thought of it. 
[23:37:43 CET] <omerjerk> thanks.
[23:39:07 CET] <durandal_1707> Daemon404: lol, you must see this script, 'enable' spam
[23:43:34 CET] <durandal_1707> this issue would be solved with luascript filter, only single filter would be in graph
[23:45:03 CET] <durandal_1707> but better fix is to provide file for single filter to read params for each frame
[23:46:04 CET] <durandal_1707> or more general filtergraph for each frame as single line in file
[23:46:18 CET] <durandal_1707> for script filter idea
[23:49:41 CET] <Timothy_Gu> jkqxz: what're your plans for VAAPI after the libav patches get merged?
[23:50:53 CET] <Timothy_Gu> btw, FATE contains a grand total of 656245 runs for ~1000 different slots
[23:53:00 CET] <Daemon404> durandal_1707, sounds a bit insane, yes...
[00:00:00 CET] --- Mon Feb  8 2016