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

[burek]

[00:38:27 CEST] <kierank> anyone an aes member?
[05:57:01 CEST] <cone-942> ffmpeg 03Timothy Gu 07master:fd2cde02346c: Doxygen: Re-enable JAVADOC_AUTOBRIEF
[10:46:14 CEST] <l3eta> So I have a question relating to a bug that is on ArchLinuxARM - Veryon. I'm not sure if it's just firefox or if it's ffmpeg itself. 
[10:46:45 CEST] <l3eta> Veyron*
[12:04:14 CEST] <jya> a quick one. what are the parser useful for? I've found that for decoding vp9 , the vp9 parser was required (but had different requirement between LibAV and FFmpeg)... Looking at extracting the flac decoder with our copy of ffmpeg, and was wondering if the flac parser was required.
[12:04:31 CEST] <jya> We don't use ffmpeg for demuxing, so we manually create the AVPacket ourselves
[12:27:24 CEST] <michaelni> jya, it depends on the demuxer if the parser is required, for vp9 it would be best to talk to BBB(ronald) he seems not here atm
[12:28:35 CEST] <nevcairiel> many parsers split or combine frames into an appropriate size for decoders to handle, ie. the vp9 parser splits superframe into the individual frames within the superframe so the decoder gets single frames to handle
[12:28:48 CEST] <nevcairiel> it can then also depend on the container how its stored in there
[12:30:34 CEST] <nevcairiel> avformat should use parsers automatically, but if you have your own demuxing, you might need to replicate the rules that control if a parser is being used or not depending on the container format
[12:45:30 CEST] <rcombs> also sometimes reports info (like sampling rate, channel count, etc) that's not always in the container, without needing to invoke the full decoder
[13:00:35 CEST] <jya> nevcairiel: ok... right now we pass the frames coming from our demuxer into the parser (currently only used for vp9) and then to avcodec
[13:01:14 CEST] <jya> i can't recall now which vp9 decoder required the parser, if it was the LibAV one or FFmpeg
[13:01:20 CEST] <nevcairiel> ours does
[13:01:30 CEST] <nevcairiel> the libav vp9 decoder is quite behind on features
[13:01:41 CEST] <nevcairiel> they ported an initial version once but didnt port any of the improvements
[13:02:06 CEST] <jya> yeah, we have a video where the vp9 decoder will return an error if the data isn't first truncated
[13:02:20 CEST] <jya> it doesn't seem to create move the pointer to the data, just the size
[13:03:07 CEST] <jya> (that one http://people.mozilla.org/~jyavenard/tests/mse_webm/youtube-error.html)
[13:03:43 CEST] <jya> the size of the flac parser is small, so I'll just extract that too
[13:03:55 CEST] <jya> and not worry about it
[13:04:52 CEST] <nevcairiel> parsers are generally not "huge", except maybe for h264/hevc or such where simply parsing the bitstream can get complicated already
[13:04:57 CEST] <jya> michaelni: for the asan failure we reported earlier, the issue is in the parser. it returns a size greater than the data it was being fed
[13:05:44 CEST] <jya> nevcairiel: we've never used the h264 parser, never noticed an issue. We've always found the data as found directly into the mp4. no filtering / parsing of any kind
[13:05:56 CEST] <nevcairiel> mp4 doesnt need it, generally
[13:05:59 CEST] <nevcairiel> but mpegts would
[13:07:03 CEST] <michaelni> BBB ^
[13:08:11 CEST] <michaelni> the vp9 parser currently expects that if it got a lets say 5k frame and consumed 1k that it next would get 4k or more data, if that is not true it could output sizes too big i think
[13:08:20 CEST] <michaelni> i dont know if that is the issue
[13:10:00 CEST] <jya> michaelni: if it uses the sizes found in the stream itself with no validation, that would definitely be an issue
[13:10:16 CEST] <BBB> the libav vp9 decoder has no parser
[13:10:21 CEST] <BBB> but it also has no frame MT
[13:10:25 CEST] <BBB> (which requires the parser)
[13:11:01 CEST] <BBB> jya: the vp9 parser validates all sizes against the input buffer, from what I remember, but feel free to look at the parser code, its tiny so should be easy to validate
[13:11:44 CEST] <jya> BBB: i didn't look into the bug, right now we've simply added a quick check that if the size coming out of the parser is greater than the input, to simply error
[13:12:01 CEST] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9_parser.c;h=2e9235e6570ff690a4401285044d106526be6285;hb=HEAD
[13:12:05 CEST] <jya> hoping that won't cause regression (like if the buffer was buffering data)
[13:12:06 CEST] <BBB> full parser code is there
[13:12:15 CEST] <nevcairiel> the parser can in fact buffer data across multiple frames
[13:12:22 CEST] <nevcairiel> so it can give you more output then it consumed input
[13:12:55 CEST] <BBB> not the vp9 one
[13:13:05 CEST] <BBB> the vp9 parser only splits
[13:13:11 CEST] <nevcairiel> but in general
[13:13:49 CEST] <BBB> jya: check the line 111-133
[13:14:02 CEST] <BBB> jya: thats the splitting
[13:14:41 CEST] <BBB> jya: it checks against remaining size etc., so I think it should be safe?
[13:15:16 CEST] <nevcairiel> meh gitweb is broken, if you try to view the log of an individual file it shows all merge commits that didnt even affect that file
[13:15:28 CEST] <nevcairiel> i somehow remember having that before and i fixed it somehow in my own install of it
[13:16:22 CEST] <BBB> michaelni: I think you could actually just do an exact size check
[13:16:46 CEST] <BBB> michaelni: so if input size on iter 0 was N and out was M, then we could assert that the next call (iter 1) has input size N-M
[13:16:49 CEST] <jya> BBB: an overflow then maybe
[13:18:25 CEST] <BBB> michaelni: so if n_frames > 0 assert(sum(s->size[0..n_frames-1]) == size)
[13:19:18 CEST] <BBB> michaelni: and you can change s->size[n] to be s->Size[n - 1] + actual_size to make that easier and then just calculate sum(s->size[..] as s->size[n_frames - 1] but maybe thats too fancy
[13:19:41 CEST] <BBB> (plus that would actually have overflow opportunities, whereas current code should be safe afaics)
[13:20:07 CEST] <michaelni> BBB does the API actually require the packet size not to change ?
[13:20:49 CEST] <BBB> I dont know
[13:20:56 CEST] <BBB> thats how we use it in ffmpeg.c
[13:21:08 CEST] <BBB> you want to reset the parser state if size != sum(s->size[..])?
[13:21:16 CEST] <BBB> (with a warning/error in console of course)
[13:21:30 CEST] <michaelni> i dont know, you are the author of the parser
[13:21:44 CEST] <BBB> with API you mean av_parser API right?
[13:21:50 CEST] <michaelni> yes
[13:22:10 CEST] <BBB> I think its fine to reset state if n_frames > 0 && size != sum(s->size[0..n_frames-1])
[13:22:17 CEST] <BBB> that may be easiest
[13:26:23 CEST] <michaelni> if the parser is run with some fifo then it could be size > sum
[13:32:44 CEST] <BBB> vp9 does not support that though
[13:32:55 CEST] <BBB> vp9 can only come from known packet sizes
[13:33:00 CEST] <BBB> which are in the container
[13:33:08 CEST] <BBB> the parser does nothing more than split
[13:41:20 CEST] <jya> michaelni: shouldn't an error being returned preferred?
[13:43:55 CEST] <michaelni> BBB the != check breaks fate
[13:44:11 CEST] <BBB> Ill check
[13:45:01 CEST] <michaelni> BBB my patch atm: http://pastebin.com/VrJFXn2K
[13:45:10 CEST] <michaelni> failure in fate-matroska-remux
[13:45:11 CEST] <BBB> we dont include the superframe index in s->size
[13:45:13 CEST] <BBB> let me add that
[13:47:37 CEST] <michaelni> jya, i dont know, there isnt much a parser can do and its not supposed to loose data
[13:48:43 CEST] <michaelni> the error would only be known when the next size mismatching frame comes in, that next frame doesnt neccessarily have an error
[13:49:03 CEST] <jya> BTW, IRC may not be that appropriate to discuss such problem
[13:49:54 CEST] <nevcairiel> whats wrong with irc?
[13:52:04 CEST] <BBB> michaelni: http://pastebin.com/RK9bRJCx
[13:53:00 CEST] <BBB> michaelni: the superframe is like this: [[frame 1] [frame 2] [frame 3] [superframe index]]
[13:53:13 CEST] <BBB> superframe index is marker size1 size2 size3 marker
[13:53:23 CEST] <BBB> and marker tells you how many sizes/frames there are
[13:53:35 CEST] <BBB> so adding superframe index size fixes your patch
[13:53:46 CEST] <BBB> passes fate-matroska-remux fate-vp9 here
[13:56:31 CEST] <nevcairiel> it seems to read the size array backwards, from 3 to 1, right? does it store them that way in the superframe index or did it swap them somewhere that i missed?
[13:57:22 CEST] <nevcairiel> oh it reads the entire thing backwards, doesnt it
[13:57:53 CEST] <michaelni> BBB, patch LGTM and passes full fate here
[13:58:40 CEST] <jya> michaelni: can't you get an overflow on the size_sum += s->size[i]; data if it's coming from outside ? (and as such, potentially rubbish)
[13:59:19 CEST] <jya> though would likely fail the != test
[14:00:21 CEST] <michaelni> jya it should have been checked before its set, but BBB is the author of this not me, he should know better
[14:01:38 CEST] <nevcairiel> s->size is checked during reading that it doesnt exceed the packet size, so to get such a high value to cause an overflow you would also need a very huge packet from the start
[14:02:21 CEST] <michaelni> the input packets size must fit in an int though so this should not be possible
[14:02:35 CEST] <nevcairiel> right, it should not overflow an int if the size fits into an int
[14:03:27 CEST] <Bitterblue> Is it safe to call avcodec_decode_subtitle2 from multiple threads with the same AVCodecContext?
[14:03:38 CEST] <nevcairiel> not at the same time
[14:03:51 CEST] <nevcairiel> you can switch threads if you want, but you cant call it simultaneously from different ones
[14:04:05 CEST] <BBB> nevcairiel: it prevents memmoves
[14:04:21 CEST] <BBB> nevcairiel: if you read forward, you have to memmove the remaining items from n to n-1 after every turn
[14:04:22 CEST] <nevcairiel> BBB: yeah just took me a moment to figure out how these things are filled
[14:04:49 CEST] <nevcairiel> patch should be fine then
[14:05:15 CEST] <nevcairiel> although to trigger this issue someone would have to call the parser wrong, its not something that seems like it would come from bad input, or?
[14:05:28 CEST] <nevcairiel> well maybe if the superframe index contains crap data
[14:05:42 CEST] <nevcairiel> but it would just randomly slice the frame, not overread inside the parser or something
[14:07:23 CEST] <Bitterblue> Aha. Would that explain why sometimes I'm getting AVSubtitles with rects[0].data[0]=NULL? Otherwise the AVSubtitle looks valid.
[14:07:27 CEST] <jya> nevcairiel: the parser no.. but the decoder being called later would
[14:07:44 CEST] <nevcairiel> jya: if it crashes on bad input then thats another bug to file
[14:07:58 CEST] <nevcairiel> and something BBB would probably interested in
[14:08:03 CEST] <nevcairiel> +be
[14:08:10 CEST] <jya> it doesn't crash, ASAN shows out of bound memory access
[14:11:06 CEST] <michaelni> BBB, nevcairiel should i push the patch with ronalds fixes ? or post to ML or wait ?
[14:11:17 CEST] <nevcairiel> ML is always safer
[14:13:09 CEST] <jya> michaelni: we can ask for the patch to be verified first
[14:26:11 CEST] <BBB> conceptually speaking
[14:26:19 CEST] <BBB> I think the reason mozilla is affected by this but ffmpeg.c is not
[14:26:31 CEST] <BBB> is that mozilla likely calls parser/decoder together
[14:26:35 CEST] <BBB> where demuxer is separate
[14:26:43 CEST] <BBB> whereas we merge parser/demuxer stages
[14:26:46 CEST] <BBB> and decoder is called separate
[14:27:00 CEST] <BBB> on error, you discard remaining input
[14:27:23 CEST] <BBB> so the parser is then called with a new packet from the demuxer which might be smaller than the cached size internally from the previous (now discarded) packet
[14:27:32 CEST] <BBB> ffmpeg.c never does that, neither does chrome
[14:27:49 CEST] <BBB> because the demuxer/parser live together and decoder acts separately
[14:28:03 CEST] <BBB> jya: is that about correct?
[14:28:44 CEST] <jya> that is correct. the parser is combined with the decoder
[14:29:14 CEST] <jya> we use nestegg as demuxer
[14:29:35 CEST] <BBB> michaelni: ok so I think that explains everything then
[14:30:09 CEST] <BBB> michaelni: Id post patch to ML for comments for a few hours, but you have approval to commit already from me so feel free to commit when you feel its been out long enough for other people to comment on or whatever
[14:31:32 CEST] <michaelni> BBB patch sent
[14:31:47 CEST] <jya> can you make sure it makes it to 3.1?
[14:32:13 CEST] <michaelni> yes ill backport it
[14:32:23 CEST] <michaelni> please someone hit me with a stick if i forget
[16:30:10 CEST] <BBB> jya: with michaels/my patch, you dont need to reset the parser
[16:30:23 CEST] <BBB> jya: I know we do that, but you dont have to, its not strictly required
[16:30:47 CEST] <jya> that's with the vp9 parser, what about others?
[16:31:10 CEST] <jya> may as well do it, it's cheap enough... but thanks for letting me know, then I know it doesn't need to be uplifted
[16:31:23 CEST] <jya> (mozilla slang for backported)
[16:40:02 CEST] <BBB> jya: its cheap, thats true
[16:40:09 CEST] <BBB> jya: as for other parsers, I dont know :)
[17:10:13 CEST] <michaelni> BBB are the frames following a decoder error useless till the next "packet" ? if not it would make sense to pass them to the decoder even after an error
[17:10:43 CEST] <BBB> theyre useless
[17:10:50 CEST] <michaelni> ok
[17:10:51 CEST] <BBB> with ffvp9 at least
[17:11:41 CEST] <michaelni> for other codecs they could contain decodable information
[17:19:44 CEST] <BBB> michaelni: they are decodable
[17:19:57 CEST] <BBB> michaelni: but they are by definition not keyframes, and you need keyframes to reset the references
[17:20:12 CEST] <BBB> michaelni: look, I think its easier if mozilla would keepinputting the existing frame into the decoder
[17:20:18 CEST] <BBB> but this is fine also
[17:20:22 CEST] <BBB> in practice it makes no difference
[17:20:33 CEST] <michaelni> sure, ok
[17:21:18 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:77b0f3f26d33: avcodec/vp9_parser: Check the input frame sizes for being consistent
[17:56:58 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07release/3.1:e4eab67a0aed: avcodec/h264_parser: Set sps/pps_ref
[17:56:59 CEST] <cone-764> ffmpeg 03Sasi Inguva 07release/3.1:7c01fa962e7f: libx264: Increase x264 opts character limit to 4096
[17:57:00 CEST] <cone-764> ffmpeg 03Kacper MichajBow 07release/3.1:caf32880fdf9: libavutil/opt: Small bugfix in example.
[17:57:01 CEST] <cone-764> ffmpeg 03Kacper MichajBow 07release/3.1:87d5146fb7b9: libavformat/rtpdec_asf: zero initialize the AVIOContext struct
[17:57:02 CEST] <cone-764> ffmpeg 03Xinzheng Zhang 07release/3.1:88e3e6b94305: avformat/flvdec: splitting add_keyframes_index() out from parse_keyframes_index()
[17:57:03 CEST] <cone-764> ffmpeg 03Xinzheng Zhang 07release/3.1:b4922daeadd2: avformat/flvdec: parse keyframe before a\v stream was created add_keyframes_index() when stream created or keyframe parsed
[17:57:04 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07release/3.1:8f6a95a103b4: avcodec/vp9_parser: Check the input frame sizes for being consistent
[18:19:25 CEST] <jamrial> michaelni: could you test https://github.com/jamrial/FFmpeg/commits/master? merged the next four commits from libav
[18:20:13 CEST] <jamrial> they are kinda trivial and fate passes here, but just to be sure
[18:46:02 CEST] <bp0> looking at AVOption, there are flags AV_OPT_FLAG_EXPORT and AV_OPT_FLAG_READONLY, is it possible to get the value of such options in a fate test?
[19:08:33 CEST] <michaelni> jamrial, seems working fine
[19:08:55 CEST] <jamrial> michaelni: ok, thanks!
[19:09:26 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:f638b67e5790: h264: move the parameter set definitions to a new header file
[19:09:27 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:70b1dcef2d85: h264: tighten the valid range for ref_frame_count
[19:09:28 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:b24dafe10572: lavc: drop unnecessary h264dec.h includes
[19:09:29 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:1cf2f3d334f5: h264_sei: drop an unnecessary h264dec.h include
[19:09:30 CEST] <cone-764> ffmpeg 03James Almer 07master:8c7932884d09: Merge commit 'f638b67e5790735f34620bf82025c9b9d6fc7216'
[19:09:31 CEST] <cone-764> ffmpeg 03James Almer 07master:9ee1f0336563: Merge commit '70b1dcef2d859ae6b3e21d61de928c3dd0cf1aa4'
[19:09:32 CEST] <cone-764> ffmpeg 03James Almer 07master:7c8bf2dc2ba0: Merge commit 'b24dafe10572254ff0decc18b0d7c3d3707d5a29'
[19:09:33 CEST] <cone-764> ffmpeg 03James Almer 07master:4c121ad5466a: Merge commit '1cf2f3d334f52849aae2be868bad1e5fa5f59aa0'
[19:28:12 CEST] <bp0> michaelni, is there some problem with the other 5 patches in the hdcd set?
[19:41:35 CEST] <michaelni> bp0, not that i know
[19:42:14 CEST] <bp0> can they be applied then?
[19:44:40 CEST] <bp0> or perhaps will they be applied, or would you apply them please, whichever is the most deferential and not demanding version of that question
[19:56:24 CEST] <michaelni> bp0, it seems "[FFmpeg-devel] [PATCH 6/7] af_hdcd: Process stereo channels together, fix #5727" does not apply after the other patches
[19:58:03 CEST] <bp0> well that is weird, they were all made in a separate branch, without any other changes between. how does that happen?
[19:58:16 CEST] <bp0> I will look into it, I guess
[20:01:52 CEST] <cone-764> ffmpeg 03Burt P 07master:bbf0b4fa88a3: MAINTAINERS: Add myself for af_hdcd
[20:01:53 CEST] <cone-764> ffmpeg 03Burt P 07master:6517177d975b: af_hdcd: Improve error detection logging
[20:01:54 CEST] <cone-764> ffmpeg 03Burt P 07master:b90d0ab4be3d: af_hdcd: add force_pe filter option
[20:01:55 CEST] <cone-764> ffmpeg 03Burt P 07master:12759cc0345c: af_hdcd: Move code detect/check into own function
[20:30:47 CEST] <bp0> michaelni, I figured out the catch, it is very minor, can I just give you a diff to apply before the patch, or does it need to be a whole git commit?
[20:31:38 CEST] <michaelni> bp0 please give me a proper git patch or git branch to cherry pick from
[20:42:45 CEST] <bp0> ok, I will
[20:56:45 CEST] <bp0> michaelni, so I can send a small commit that should be applied before the other patch, and that will work?
[21:00:05 CEST] <michaelni> bp0, is it supposed to be applied as 2 commits /patches ?
[21:00:24 CEST] <michaelni> if yes then send otherwise they should be stashed into one
[21:00:25 CEST] <bp0> yeah, it would have to be applied, then apply the patch that failed
[21:00:42 CEST] <bp0> and it should not fail
[21:01:26 CEST] <michaelni> bp0, the question i had/meant was is it intended to be 2 commits ? aka is that how it should be split ?
[21:01:57 CEST] <michaelni> or do you want to update the patch and have just 1 commit ?
[21:02:42 CEST] <michaelni> its very easy with git to update and change things
[21:02:56 CEST] <bp0> I... don't know. What is best?
[21:03:09 CEST] <bp0> I'm pretty much at the edge of my git capabilities with this solution
[21:04:00 CEST] <michaelni> bp0, i am not talking about git :) i mean the change should it be split in 2 or 1 
[21:04:21 CEST] <bp0> oh, I think one might be better
[21:04:51 CEST] <bp0> it is the position of some {} that fails to patch, nothing really so important
[21:05:27 CEST] <bp0> the new pre-patch just fixes those curly bracket positions so that the original patch will work
[21:05:42 CEST] <michaelni> ahh
[21:06:28 CEST] <michaelni> do you have that problematic patch locally in some branch ?
[21:06:43 CEST] <michaelni> or you are on a clean master with nothing ?
[21:07:13 CEST] <bp0> yeah, I do have it in a branch
[21:08:02 CEST] <michaelni> so if you are on master, try a git cherry-pick [here goes the hash from that commit you want to rebase]
[21:08:41 CEST] <michaelni> git log [that branch where the commit is] shows the hashes (the long ugly hexadecimal numbers)
[21:11:04 CEST] <michaelni> "git cherry-pick "  will likely give a trivial conflcit and explain how to solve it
[21:11:10 CEST] <bp0> alright, so it failed again, but now.. there will be conflict markers or something?
[21:11:19 CEST] <michaelni> there should be
[21:15:49 CEST] <bp0> ok, so then I've got a new version of that commit, and I can send it to the ML as a v2? or what do I have now?
[21:17:22 CEST] <michaelni> yes you can send it as v2
[21:17:54 CEST] <michaelni> same way as you did previously should work
[21:22:26 CEST] <bp0> ok, if using git send-email without --compose, can I still change the subject to [PATCH v2] somehow? --subject="" didn't do it
[21:26:29 CEST] <bp0> hmm, even using --compose and just not writing a message, then subject reverts to [PATCH]
[21:27:33 CEST] <jamrial> bp0: just use git format-patch and edit the subject in the resulting file
[21:27:41 CEST] <jamrial> then git send-email that file
[21:27:59 CEST] <wbs> --subject-prefix="PATCHv2" should do it
[21:29:06 CEST] <bp0> wbs, very good, thank you
[21:29:10 CEST] <bp0> thank you too jamrial 
[21:29:15 CEST] <bp0> and, of course, michaelni 
[21:30:48 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:5c2fb561d94f: h264: add H264_ prefix to the NAL unit types
[21:30:49 CEST] <cone-764> ffmpeg 03James Almer 07master:f41048f6ec56: Merge commit '5c2fb561d94fc51d76ab21d6f7cc5b6cc3aa599c'
[21:37:21 CEST] <Fyr> Here's something I ought to say.
[21:37:27 CEST] <Fyr> I hate FFMPEG.
[21:37:40 CEST] <Fyr> I hate it with every inch of my body.
[21:37:50 CEST] <Fyr> if all its developers died painfully, the world would be a better place.
[21:37:57 CEST] <Fyr> I accurse you! Die painfully!
[22:04:46 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:8281cd5cb805: h264_cabac: drop an always true condition
[22:04:47 CEST] <cone-764> ffmpeg 03James Almer 07master:fd4eb56528e1: Merge commit '8281cd5cb80582d668ce0848e0e035b383f161f6'
[22:35:11 CEST] <Compn> lol that was an interesting comment
[22:36:40 CEST] <Loriker> nothing productive
[22:38:59 CEST] <Compn> http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2015-November/003217.html
[22:39:03 CEST] <Compn> guy was asking about flac decode
[22:39:04 CEST] <Compn> :D
[23:41:36 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:bc7f42685146: h264: drop tests whether the codec id is AV_CODEC_ID_H264
[23:41:37 CEST] <cone-764> ffmpeg 03James Almer 07master:517dd04f6df3: Merge commit 'bc7f4268514624e1286ea76d27a89a56b4ee18e1'
[23:43:15 CEST] <Timothy_Gu> jamrial: is there a script available for merging?
[23:49:12 CEST] <jamrial> Timothy_Gu: ubitux sent a patch with one and some relevant documentation a few weeks ago
[00:00:00 CEST] --- Tue Aug  2 2016