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

[burek]

[00:01] <wm4> looking at the code, maybe not
[00:01] <pross-au> wm4: do they still forbid mp3?
[00:01] <wm4> pross-au: no idea if that's a thing of the past
[00:02] <wm4> Timothy_Gu: so I suppose you don't really need to, but checking it anyway might be better style
[00:03] <Timothy_Gu> I am asking because there are _tons_ of unchecked avio_tell() calls in matroskadec.c
[00:04] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:2a85826e5753: avcodec/vp9: Use av_malloc_array()
[00:04] <cone-798> ffmpeg.git 03Christophe Gisquet 07master:6ee7681723a4: huffyuvenc: write last odd sample
[00:04] <cone-798> ffmpeg.git 03Christophe Gisquet 07master:f75baa6c9b17: huffyuvdec: decode the last odd sample
[00:04] <kepstin-laptop> pross-au: as of fedora 20, they still don't include mp3 decoding.
[00:04] <Timothy_Gu> pross-au: at least we have Fluendo now
[00:06] <wm4> Timothy_Gu: then maybe it would be better to adjust the documentation to say it never fails
[00:07] <Timothy_Gu> Does it not?
[00:07] <Timothy_Gu> Well this was my original question: does avio_tell() ever makes avio_seek() fail?
[00:07] <Timothy_Gu> *make
[00:08] <beastd> I would rather say. Think what would happen if it fails -- what would the code of the mkv demuxer do?
[00:08] <beastd> Especially if it returns either error or position
[00:10] <Timothy_Gu> ... do weird stuff and not demux properly?
[00:10] <beastd> Might be OK to ignore errors, but only if you can say the code will still behave safe in that case.
[00:12] <Timothy_Gu> For example, http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/matroskadec.c;h=83c1b3dbe0306539aa4aef118af49665172c413f;hb=HEAD#l2103 passes a potential negative value into resync()
[00:12] <Timothy_Gu> which uses the value in avio_seek(), and seek backwards instead of forwards
[00:13] <Timothy_Gu> And all kinds of weird problems may appear
[00:31] <beastd> Timothy_Gu: that could possibly checked inside the internal matroska_resync . also other cases are just for error messages (though i am not sure they are treated as unsigned for error output). you could also write a mail to ffmpeg-devel and ask if others have better ideas how to proceed. i would examine each instance, categorize and then do fixes if needed
[00:32] <Timothy_Gu> Thanks! I am a little bit short on time right now, but I will do what you suggested once I find time.
[00:33] Action: beastd too
[00:34] <beastd> Will go to sleep soon.
[00:39] <cone-798> ffmpeg.git 03Alexander Strasser 07master:db85d11d9d88: libavformat/ftp: Do not leak memory in routine ftp_features
[01:20] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:e96109f93ce9: ffplay: use av_malloc_array()
[01:20] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:1f7e6c07130c: doc/snow: remove possibly wrong todo item
[01:49] Action: cbsrobot_ wonders what is so patentable in this "Dreamworks Lossy Compression"
[01:50] <cbsrobot_> https://github.com/openexr/openexr/blob/master/OpenEXR/IlmImf/ImfDwaCompressor.cpp
[01:50] <cbsrobot_> looks like just another jpeg implementation
[01:55] <Daemon404> of course
[01:55] <Daemon404> it is patented after all
[01:55] <Daemon404> of course it is not novel.
[01:56] Action: llogan prefers lena over flower
[01:58] <wm4> so who will implement native openexr in ffmpeg?
[01:59] <Daemon404> exr.c is a thing
[01:59] <Daemon404> just needs the mode
[02:00] <Daemon404> im impressed how large this file is
[02:00] <Daemon404> for what it does...
[02:12] <wm4> lol no more lena
[02:17] <Daemon404> wtf is even patented in this
[02:22] <llogan> the 1970's
[02:22] <Daemon404> my only guess its its dumb ad-hoc quant method
[02:22] <Daemon404> is*
[02:26] <Timothy_Gu> Seems like Andreas forgot my copyright...
[02:29] <michaelni> llogan, if you dont lie flower.pnm, suggest another image
[02:29] <michaelni> maybe bikeshed.pnm ;)
[02:30] <llogan> who knows...maybe i'll actually take a photo of a bikeshed
[02:30] <wm4> but what color will the shed have
[02:30] <wm4> *should
[02:34] <michaelni> Timothy_Gu, where did he forget it ? in git or that patch ? anything i can fix ?
[02:35] <Timothy_Gu> In debian/copyright
[02:35] <michaelni> ahh ok, i cant help with that i think
[02:35] <Timothy_Gu> Is Lena still alive?
[02:36] <michaelni> dunno, she was a few years ago though AFAIK
[02:52] <cone-798> ffmpeg.git 03ThomasVolkert 07master:96b2ba68c4ae: avformat/rtpdec: support for HEVC/H.265 RTP payload format (draft v6) depacketizing
[03:46] <jamrial> michaelni: what libvpx version do you have? VP9E_SET_AQ_MODE is available in 1.3.0, the first one with vp9 en/decoder
[04:26] <rcombs> anyone around who can tweak fflogger? It's not zero-padding color codes to 2 digits, so names that start with [0-9A-Fa-f] throw off coloring
[04:27] <llogan> that's burek but he's MIA
[04:27] <rcombs> and a name starting with ",2" or something (which would be pretty weird, but not unheard of) would probably screw up the background color as well
[04:27] <llogan> burek021 at gmail
[04:27] <rcombs> alright, I'll mail him
[04:27] <llogan> thanks.
[04:28] <llogan> also, i don't think you need to cc yourself to your own bug reports. i think it will automatically email you any updates
[04:28] <rcombs> I'm not sure, as it varies between trackers; there was a checkbox to CC myself, so I clicked it
[04:28] <llogan> no big deal. just letting you know.
[04:29] <rcombs> figured it wouldn't be there if it wasn't necessary
[04:29] <rcombs> yeah, gotcha
[04:29] <llogan> burkes builds have been halted since 16 july. asked him twice if he could resume them. no reply, so once relaxed starts providing 32 bit builds i'll update downloads
[04:30] <rcombs> 01,00hmm, is this default or not
[04:30] <rcombs> nope
[04:36] <rcombs> well, I won't hold my breath for a response, but sent
[04:49] <michaelni> jamrial, iam not sure but ive a source tree for v1.2.0-4277-gc73e441 here so maybe that
[04:53] <jamrial> ah, a git snapshot. makes sense there's stuff missing
[04:53] <jamrial> we should probably update the configure check, then. make it check for VP9E_SET_AQ_MODE instead of VP9E_SET_SVC
[05:53] <cone-798> ffmpeg.git 03James Almer 07master:c2c56d54ee90: configure: update libvpx_vp9_encoder check
[09:23] <ubitux> michaelni: 
[09:23] <ubitux> Applying: tests: switch to a test image that is under public domain
[09:23] <ubitux> fatal: corrupt patch at line 3322
[09:30] <ubitux> michaelni: could you make flower.pnm available somewhere?
[10:27] <saste> how can I know which metadata fields are supported in a given format?
[10:28] <saste> unsupported fields are simply ignored at the moment
[10:48] <ubitux> saste: wm4 asked something similar yesterday
[10:48] <ubitux> currently we store random tags in a given format from metadata even though they sometimes don't make sense
[10:48] <ubitux> are you talking about that?
[10:49] <saste> ubitux, and my answer is, there is no automatic way
[10:49] <saste> ubitux, yes more or less
[10:51] <saste> also I'm discovering that sometimes output metadata is silently discarded
[11:10] <michaelni> ubitux, http://ffmpeg.org/~michael/flower.pnm
[11:10] <ubitux> thx
[11:11] <ubitux> cool ok
[11:29] <nevcairiel> lena is not free to use? everyone uses it, we even used it in university :p
[11:32] <ubitux> not "DFSG-free" apparently
[11:33] <nevcairiel> they wouldnt accept free beer in a pub if it doesn't come with a written letter that you relinquish all rights to it
[11:33] <ubitux> it seems to be potentially problematic for debian
[11:34] <nevcairiel> apparently so
[12:24] <cone-840> ffmpeg.git 03Diego Biurrun 07master:ab56fabe6294: vfwcap: Add fallback define for HWND_MESSAGE
[12:24] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:d5ee74e57d44: Merge commit 'ab56fabe6294524e99815451ad01e4ff50c6d734'
[12:34] <pross-au> a flower?
[12:36] Action: ubitux sends https://www.youtube.com/watch?v=AULG4MoYxQk to pross-au with love
[12:48] <J_Darnley> > vfwcap: Add fallback define for HWND_MESSAGE
[12:48] <J_Darnley> > Some obsolete versions of the MinGW32 runtime (<4.0.0) lack the definition.
[12:48] <J_Darnley> Wasn't that the point of dropping the fallback?
[12:49] <nevcairiel> he didnt expect it to actually break anything :p
[13:06] <cone-840> ffmpeg.git 03Luca Barbato 07master:a4d3c2003594: vc1: Fix the skip condition
[13:06] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:ba650ea11825: Merge commit 'a4d3c20035946cbc1509aec2dc28d51c2a2f9a8e'
[13:32] <Eftekhari> hi
[13:34] <Eftekhari> i have ffserver, when feed is larger than 2 GB, if ffmpeg that feed the ffserver exit, re executing the ffmpeg to feed the server not working, with the error :  Error reading write index from feed file '/tmp/feed1.ffm': Resource temporarily unavailable
[14:13] <cone-840> ffmpeg.git 03Luca Barbato 07master:4e9e6fa99f3f: mpeg: Write H264 streams at offset 2
[14:14] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:cf0e8e7ad488: Merge commit '4e9e6fa99f3ff83cedbf6c378d62065ae419a3b9'
[14:47] <durandal_1707> doesnt libav use lena?
[14:51] <nevcairiel> Probably, its been part of fate for ages
[14:55] <michaelni> Eftekhari, ask reynaldo / wait till he is here
[15:30] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:85f0bde4f07d: avcodec/snowenc: remove out-commented assert
[15:30] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:bf16872feca8: avformat/nsvdec: fix out-commented asserts so the function names exist
[15:30] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:46ad2c4aeddf: avformat/utils: remove assert that tests the same condition as the if() directly above
[15:42] <ubitux> lol blackberry mail
[15:46] <nevcairiel> Fun
[15:48] <Daemon404> what is this ridiculous lena removal patch?
[15:49] <Daemon404> oh. debian.
[15:49] <Daemon404> fuck them.
[15:49] Action: Daemon404 sighs at freetards
[15:52] <nevcairiel> They are the best kind of people
[15:57] <Daemon404> let's not use Lena, the standard test image, because IT IS NOT FREE ENOUGH
[15:57] <ubitux> let's hide it in a xor-ed .c 
[15:57] <ubitux> and generate it on the fly
[15:57] <Daemon404> it seems beyond stupid to change the regression testing image for DFSG...
[15:57] <Daemon404> users dont get that
[15:57] <Daemon404> and the debian daemons have no internet
[15:57] <Daemon404> so...
[15:57] <Daemon404> (a run with just asynth/vsynth is kinda dumb)
[16:00] <ubitux> i guess our packager is getting bored after a few months waiting for the ftp-masters to get the shit done
[16:00] <nevcairiel> Yeah its not even distributed by debian
[16:00] <nevcairiel> Whz do they care again
[16:00] <nevcairiel> Why*
[16:01] <ubitux> it's only present in the sources but they do actually distribute the sources
[16:01] <Daemon404> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758442
[16:01] <Daemon404> freetards gonna freetard
[16:01] <Daemon404> it is utterly inconsequential
[16:01] <nevcairiel> We should tell them that there is hundreds of patents on the things avcodec implements
[16:01] <nevcairiel> See the chaos ensue
[18:48] <Daemon404> ugh
[18:48] <Daemon404> i see we dont use pkg-config for e.g. vorbis either
[18:48] <Daemon404> sigh.
[18:58] <ubitux> wanna try to switch to?
[18:58] <ubitux> ;)
[18:58] <ubitux> i'm fighting for months to get it for libx264
[19:05] <Daemon404> ubitux, i dont feel like dealing with an autistic person
[19:20] <Daemon404> man i feel silly
[19:20] Action: Daemon404 uses -c:v libxvid
[19:47] <llogan> Daemon404: why libxvid?
[19:50] <Daemon404> reasons
[19:50] Action: llogan leaves to have more engaging discussion with a wall
[20:06] <wm4> so I guess this API mailing list idea failed... because of Libav
[20:07] <Daemon404> of course
[20:08] <llogan> maybe the formatting of the message was not correct
[20:15] <cone-840> ffmpeg.git 03Hii 07master:604c4eab2bf6: libx264: fix -b_qfactor and -chromaoffset
[20:25] <jamrial> wm4: what did you expect? they know they control the api as long as ffmpeg tries to be compatible because debian. why would they play ball unless they are forced to?
[20:29] <kierank> wm4: of course because nobody talked to libav about it...
[20:30] <kierank> which was my exact point
[20:30] <kierank> the other day
[20:30] <kierank> jamrial: they control the api because ffmpeg merges from libav
[20:30] <kierank> not because of debian
[20:31] <wm4> kierank: I mentioned it on irc, but nobody cared
[20:31] <kierank> because it is an ffmpeg initaitve
[20:32] <kierank> my point to ubitux is you have to do these things as a joint initiative
[20:32] <wm4> but Libav was always blaming ffmpeg for not making a step towards cooperation
[20:32] <kierank> which is would ideally be a result of a face to face conversation
[20:32] <kierank> wm4: libav is blaming micahel
[20:32] <kierank> which is largely true
[20:33] <wm4> in this case ubitux just made a suggestion, how else would he even start a "joint initiative"?
[20:33] <wm4> but Libav remained silent
[20:33] <kierank> by turning up in a neutral environment (vdd) and proposing it
[20:33] <kierank> ubitux was saying MLs are the best place for these things etc
[20:36] <wm4> and this is your proof that it doesn't work?
[20:39] <kierank> the opposite
[20:39] <cone-840> ffmpeg.git 03ThomasVolkert 07master:e15824e75b55: avformat/rtpdec_h261: Fix sanity checks
[20:39] <kierank> ubitux was saying all the issues could be solved on the ML and not face-to-face
[20:39] <kierank> and he said what kinds of things could be discussed face to face
[20:39] <kierank> i proposed an api mailing list
[20:39] <kierank> he said he's send an email
[20:39] <kierank> he'd*
[20:39] <kierank> and he did and libav ignored it as expected
[20:41] <llogan> and what did we learn here? never try.
[20:41] <wm4> and you're claiming it magically works better in the real world
[20:41] <j-b> ,agic
[20:41] <wm4> the same where Diego's appearance could apparently silence the whole table (lol)
[20:42] <j-b> wm4: tbh, being face to face improves communication.
[20:42] <j-b> wm4: so, when do we start our fork?
[20:42] <wm4> fork of what?
[20:42] <j-b> ffmpeg :)
[20:43] <wm4> yes you should totally fork it!
[20:43] <kierank> I hope you say both ffmpeg and libav and avconv are deprecated
[20:43] <j-b> kierank: ah, that's sure.
[20:43] <j-b> kierank: I would remove a lot of things.
[20:43] <wm4> like what?
[20:43] <llogan> kierank: and "no longer developed anymore"
[20:43] <kierank> like what?
[20:44] <j-b> libavfilter, libavresmaple, libpostporc, libwsresample, libwscale
[20:44] <j-b> for a start
[20:44] <kierank> lol
[20:44] <wm4> but not libavdevice?
[20:44] <j-b> then, ffmpeg, ffserver, ffprobe and the rest
[20:45] <kierank> j-b: not libavformat?
[20:45] <j-b> wm4: it seems too tangled with libavformat
[20:45] <j-b> kierank: idem
[20:45] <wm4> and the removed stuff will actually end up in separate repos, right?
[20:45] <j-b> so, a core repo with libavcode+liavformat+libavutil
[20:45] <j-b> wm4: yes.
[20:45] <wm4> sounds sensible
[20:45] <j-b> wm4: so, the tools will not violate the internal symbols
[20:46] <j-b> and libav/ffmpeg developers will finally eat their own shit about APIs
[20:46] <wm4> one small problem is that you actually need all repos from the start, because the FATE depends on all the things
[20:46] <j-b> and have ffmpeg and ffplay to work with 2 or 3 versions of libavcodec and libavfilter
[20:46] <wm4> oooh you're cruel
[20:46] <nevcairiel> I think the .v files are pretty much empty by now, at the very least
[20:47] <wm4> that would force the devs to actually care about compat
[20:47] <j-b> wm4: so? it's not hard to split. and use subfilter.
[20:47] <j-b> oh, and tools also would split.
[20:47] <nevcairiel> But it also means they can't use any new APIs, which is not very good for innovation
[20:47] <j-b> Bullshit.
[20:47] <j-b> it's called ifdef
[20:48] <cone-840> ffmpeg.git 03Diego Biurrun 07master:4c8bd8ddb049: os_support: Adjust an outdated #endif comment
[20:48] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:7206221d563e: Merge commit '4c8bd8ddb049950347a5018fecbca7ee25d48c44'
[20:48] <j-b> and you should know that "innovation" is a bullshit word.
[20:48] <nevcairiel> If you want half the thing not working with some old version, sure. :p
[20:48] <j-b> half the things?
[20:48] <j-b> exageration much?
[20:49] <j-b> we manage to compile VLC with lavc HEAD and a version from debian stable.
[20:49] <wm4> what j-b suggests sounds pretty much how things ideally should be
[20:49] <j-b> without too much hassle
[20:49] <j-b> AND, we compile against 3 forks
[20:50] <j-b> so please, no "innovation blabla" BS, to hide laziness and go on abusing symbols.
[20:50] <iive> 4
[20:50] <nevcairiel> There is 3 forks now?
[20:50] <iive> ffmb
[20:50] <j-b> and sorry, for once, I'm not smooth.
[20:50] <j-b> iive: 4?
[20:50] <wm4> and of course half a dozen of open or closed projects with their own changes
[20:51] <j-b> yeah
[20:51] <nevcairiel> Those mostly don't go revising API much
[20:51] <iive> bcourdier have its own fork. gpl probably still uses the original api.
[20:52] <iive> imho, if libav wanted ffmpeg to stop merging, they should relicense it as GPL only.
[20:52] <j-b> and, as I said, one maintainer for each submodule.
[20:52] <j-b> iive: they don't wnat ffmpeg to stop merging, they just ignore and not care about ffmpeg.
[20:53] <iive> and please steamline the api. no more than 4 function. open, close, decode, encode.
[20:53] <cone-840> ffmpeg.git 03Gabriel Dume 07master:56a721f02027: doc: fix a typo
[20:53] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:ffa90d99fd89: Merge commit '56a721f020273d69daa8dcb0d99e42a43a0a0d4d'
[20:54] <nevcairiel> I always have to grin when they talk about an issue long solved in FFmpeg but it would never even occur to them to check
[20:54] <j-b> nevcairiel: indeed.
[20:54] <j-b> nevcairiel: however, usually their fixes are better.
[20:54] <wm4> j-b: how to make sure that the fork won't fall into obscurity from the start?
[20:54] <wm4> it's hard to force others to their luck
[20:54] <j-b> I have more security issues on FFmpeg than libav, for example
[20:54] <iive> wm4: simply, by replaceing both libav and ffmpeg in debian!
[20:55] <j-b> wm4: that's the hard part :)
[20:55] <wm4> and who will do the grindwork of cherry-picking patches from ffmpeg/libav (and distributing them over 6 repos ro so)
[20:55] <wm4> *or
[20:55] <j-b> someone paid fulltime
[20:55] <iive> you can ask michael :P
[20:56] <j-b> I already said that at the time of the move to git
[20:56] <j-b> and at the time of the split
[20:56] <j-b> so, it has not changed.
[20:56] <nevcairiel> That doesn't sound like a fun job, merging stuff for a living
[20:56] <JEEB> I at one point wanted to fix a thing in the MXF (?) demuxer or so, and of course wanted to have it fixed in both, so I decided to first update it into libav and then it would flow into FFmpeg. Then I noticed that FFmpeg had widely updated that stuff. And then I learned that the backport would most probably be nope'd, so I just gave up
[20:57] <JEEB> lörs laeraed
[20:57] <j-b> JEEB: use VLC and the BBC demuxer
[20:57] <j-b> nevcairiel: Linus does it.
[20:57] <JEEB> probably a good idea
[20:57] <JEEB> but at this point I don't even care
[20:57] <JEEB> I will at some point finish my earthsoft dv rewrite
[20:57] <wm4> j-b: actually, if you find such a person who wants to play maintainer for such a large project, you can just ask him to take over ffmpeg maintainership
[20:57] <j-b> until then, more hentai playback on VLC! :D
[20:57] <JEEB> (welcome to me saying this since 2013 or so)
[20:58] <nevcairiel> j-b: he also has frequent outbursts at devs to balance himself
[20:58] <j-b> nevcairiel: of course, but he does it correctly, with justice.
[20:58] <wm4> and then we'll see if michaelni's offer is real
[20:58] <j-b> wm4: as soon as I get 500k¬ per year more
[20:58] <j-b> I'd hire 2.
[21:03] <nevcairiel> Hrm why does vaapi need to link against something, vdpau doesn't. :( this makes distributing binaries more annoying
[21:05] <wm4> because there are major vaapi api calls in the decoder
[21:06] <nevcairiel> I wonder if libva is at least installed on most distros
[21:06] <wm4> probably
[21:06] <nevcairiel> My Debian seemed to have it on a fresh install
[21:07] <wm4> even the emulation wrappers are often installed (like vdpau libva backend)
[21:07] <nevcairiel> Well I'll discuss it with a colleague
[21:08] <nevcairiel> I would prefer to start with vdpau myself, but we sell some hardware with an Intel GPU, so that's high on the priority list
[21:09] <wm4> there's also a wrapper that emulates vdpau via libva
[21:09] <wm4> and opengl
[21:10] <nevcairiel> Do such wrappers work?
[21:10] <nevcairiel> And work well?
[21:10] <wm4> you'll have to see for yourself
[21:11] <wm4> they probably incur quite some overhead
[21:12] <ubitux> <+kierank> ubitux was saying all the issues could be solved on the ML and not face-to-face // no, i'm defending the point that if they can't communicate with ML, face-to-face will not solve anything
[21:13] <kierank> ubitux: it's the other way round altogther
[21:13] <kierank> that's my point
[21:13] <ubitux> they're hiding behind this "they are autistic and can't talk face to face so we won't talk virtually"
[21:14] <ubitux> and we are saying if they can't talk virtually then there is no point in trying to communicate with a worth medium (at least that's my opinion)
[21:14] <kierank> no they just can ignore your emails
[21:14] <kierank> whereas face to face they can;t
[21:14] <ubitux> if they want to ignore the mails then they don't want to communicate
[21:14] <ubitux> then there is no way i'm going to force them
[21:14] <ubitux> or play their game irl
[21:24] <wm4> IRL you just can turn it into a fist-fight!!!1
[21:52] <cone-840> ffmpeg.git 03Gabriel Dume 07master:0a024268261d: libxvid: K&R formatting cosmetics
[21:52] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:9c41b59423bb: Merge commit '0a024268261d05ccdcf7e03c85fb78d22037a464'
[22:08] <cone-840> ffmpeg.git 03Vittorio Giovara 07master:e87f5e4e5f2e: h264: fully check cropping amount from sps
[22:08] <cone-840> ffmpeg.git 03Michael Niedermayer 07master:570397c73115: Merge commit 'e87f5e4e5f2e2e36b0b7826d708cda7049877af0'
[22:22] <jamrial> michaelni: did Thomas Volkert ever send the hevc rtp patch to the ml?
[22:22] <jamrial> can't find it, and wanted to point him to http://fate.ffmpeg.org/log.cgi?time=20140826140938&log=compile&slot=x86_64-archlinux-gcc-ddebug
[22:35] <michaelni> jamrial, dunno, there was a pull request on github
[23:09] <llogan> i always forget about those
[23:11] <wm4> so there are things that are reviewed (by some) and pushed, which never make it through the ML?
[23:12] <llogan> https://github.com/FFmpeg/FFmpeg/pulls
[00:00] --- Wed Aug 27 2014