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

[burek]

[00:00] <smarter> michaelni: wait, there's no need to rush this
[00:01] <iive> smarter: wait for what and how long?
[00:06] <smarter> wait until it's merged until libav, you're welcome to help if you think this is taking too long
[00:07] <mraulet> can I ask a question for those who participated to AVC/H.264? how was the code before it has been accepted by ffmpeg?
[00:08] <iive> smarter:  is there even a review process going on there?
[00:09] <mraulet> yes
[00:09] <iive> on the maillist?
[00:09] <mraulet> yes
[00:09] <iive> I don't see any comments. can you provide a link?
[00:12] <wm4> iive: libav.org
[00:12] <iive> e.g. http://lists.libav.org/pipermail/libav-devel/2013-October/051938.html
[00:13] <mraulet> http://patches.libav.org/patch/43132/
[00:13] <iive> I see patchsets and no comments or review at all.
[00:13] <smarter____> There's a TODO here: https://etherpad.mozilla.org/lKtGkT3W3b
[00:14] <mraulet> this is not the first round on libav
[00:14] <Paranoialmaniac> iive: http://lists.libav.org/pipermail/libav-devel/2013-August/049753.html
[00:14] <smarter____> and recently people have been contributing changes instead of commenting on the patch
[00:15] <iive> i think i've seen previous rounds on libav, with the same amount of comments (0)
[00:15] <smarter____> the first round a year ago did have some comments at least :)
[00:16] <iive> so either there is no discussion, or everything happens behind closed doors.
[00:17] <mraulet> irc
[00:17] <mraulet> is not so closed
[00:17] <iive> it is, because I cannot see the discussion.
[00:17] <iive> e.g. this channel is publicly logged
[00:18] <smarter____> So the problem is that libav-devel is not logged?
[00:20] <smarter____> people post their proposed changes to some public branch, like https://github.com/lu-zero/libav/commits/hevc_upstream
[00:20] <iive> look...
[00:21] <iive> you can do development however you like... in norad bunker if you feel like it.
[00:21] <iive> however for outside spectator the whole thing is solid wall.
[00:22] <iive> there is zero information when that thing would be merged in libav.
[00:22] <iive> there is zero information of the issues that should be resolved.
[00:22] <smarter____> "When it's done"
[00:22] <smarter____> there's a TODO I just posted
[00:22] <smarter____> I think you're exagerating, but I agree that the whole process could be better
[00:23] <iive> lim (when it's done)=infinite.
[00:23] <mraulet> and those split does not help
[00:23] <iive> libav is not done, ffmpeg is not done, x264 is not done... i guess xvid is done...
[00:24] <mraulet> in fact we are in between an uncomfortable position
[00:25] <mraulet> so you can take your own responsabiltty, the code is available btw
[00:25] <smarter____> iive: I'm not sure what your point is, do you want to help in some way?
[00:26] <iive> go on.
[00:26] <kierank> smarter____: personally I think you should let them commit it
[00:26] <kierank> even though their reasons are wrong
[00:26] <smarter____> kierank: I told them I was not opposed to it
[00:26] <kierank> ah
[00:26] <kierank> they'll get a ton of bug reports
[00:26] <iive> so... you would not give explicit permission, because this would put you in odds with the libav people who are working on the project
[00:27] <smarter____> libav people don't care
[00:27] <smarter____> afaik
[00:27] <iive> but you would be happy your code to be actually seen by the outside world.
[00:28] <mraulet> yes we would... and we would like both community use the same code base
[00:29] <iive> ffmpeg have no problem merging code.
[00:29] <smarter____> iive: I'm just saying, if it was my decision I wouldn't do it now. It's your decision so you can do whatever you want
[00:31] <iive> ffmpeg also have no problem merging work in progress.
[00:31] <michaelni> mraulet, about h264, the first version commited ( to svn back then IIRC) lacked many things and had bugs, i see multiple references b frames, multiple slices after the initial code in the log
[00:31] <michaelni> and i remember there where other decoders that where commited siilarly early
[00:32] <iive> i think that the first vc1 code was bitstream parser only... but it might have been h264 too..
[00:32] <michaelni> more likely vc1 probably
[00:32] <michaelni> and there where decoders that where commited with just intra support
[00:32] <michaelni> and inter added later
[00:33] <j-b> smarter____: come on, it's not your fault.
[00:33] <iive> and this was during the time when the ffmpeg review process was harder than a boxing match.
[00:33] <smarter____> j-b: what's not my fault? :)
[00:33] <mraulet> doing a great decoder ^^
[00:33] <j-b> smarter____: if it is not merged.
[00:33] <michaelni> and we even have some h263 variant that currently we can only decode intra frames of because its not known AFAIK how to decode the inter frames and its too rare format for anyone caring
[00:33] <j-b> smarter____: it's almost impossible to get anything merged anyway.
[00:34] <j-b> anything not trivial
[00:34] <j-b> JBr0ck29!
[00:34] <j-b> :)
[00:34] <j-b> An no, that's not my pass :)
[00:35] <j-b> smarter____: seriously, both projects are impossible to work with.
[00:35] <wm4> videolan fork of ffmpeg when?
[00:36] <j-b> wm4: lol
[00:36] <j-b> wm4: I hope you are not serious
[00:36] <michaelni> tell me the git url ill add it to our download page :)
[00:36] <wm4> j-b: half joking
[00:36] <mraulet> okay so this decoder supports all conformance tests from 8 to 10 bits
[00:36] <j-b> wm4: maintaining compatibility with 2 libavcodecs is already hard.
[00:37] <mraulet> ahah
[00:37] <j-b> wm4: 3 would be daunting
[00:37] <wm4> well, that wouldn't exactly be the point
[00:37] <Paranoialmaniac> btw, hevc is not finalized yet. michaelni, was h264 decoder commited at a draft?
[00:37] <mraulet> hevc is finalized
[00:38] <j-b> wm4: who would have the skillz to do that?
[00:38] <Paranoialmaniac> ? h264 is finalized
[00:38] <mraulet> transport of hevc is not
[00:38] <michaelni> when was h264 finalized ?
[00:38] <Paranoialmaniac> *h265
[00:38] <Paranoialmaniac> itu-t finalized h265
[00:38] <wm4> j-b: dunno, I thought vlc had manpower? I see many vlc devs around here
[00:38] <Paranoialmaniac> but iso/iec have not finalized hevc yet
[00:38] <mraulet> it has
[00:38] <j-b> wm4: lol. the 4 of us?
[00:39] <j-b> wm4: I see only one other deve here.
[00:39] <michaelni> h264 was commited "Fri Apr 4 14:42:28 2003"  according to git log dunno if that was final at that point or not
[00:39] <mraulet> 15 march 2003
[00:39] <mraulet> and HEVC is 15 march 2013
[00:39] <Paranoialmaniac> mraulet: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35424 hevc is still in FDIS
[00:40] <wm4> but seriously, since libav and ffmpeg will never ever merge again (unless hell freezes over), a third project could actually solve this mess
[00:40] <wm4> (or create an entirely new mess, oh well)
[00:40] <mraulet> FDIS means international standard at iso
[00:40] <mraulet> it has been accepted on march 15
[00:40] <iive> "The standardization of the first version of H.264/AVC was completed in May 2003." wikipedia
[00:41] <mraulet> I can send an email from MPEG boss and quoting him
[00:41] <iive> so h264 was definitely committed at draft stage.
[00:41] <mraulet> it seems so
[00:45] <j-b> wm4: http://xkcd.com/927/
[00:45] <wm4> I know, I know
[00:45] <wm4> ffmpeg vs. libav is like a chronic live-long disease
[00:46] Action: wm4 grumbles
[00:48] <mraulet> from my pov the decoder is quite stable and at least it is good that both libav and ffmpeg is working on the same patchsets
[00:51] <mraulet> L&. said "10 years because AVC was approved in Pattaya on 2003/03/14"
[00:52] <smarter____> I guess ISO standard != MPEG standard != ITU standard
[00:53] <mraulet> yep
[01:13] <smarter____> one thing I'm afraid of is that you'll starting accepting patches and start diverging. If you merge the decoder that means you maintain it and you should make an honest effort to get your changes in libav
[01:14] <smarter____> If you can do that, then I'm happy with it
[01:15] <smarter____> once again, this is my opinion, feel free to do whatever you want
[01:17] <iive> smarter____: would you accept changes from ffmpeg?
[01:18] <wm4> maybe a certain someone is right and ffmpeg just wants to claim to have a hevc decoder before Libav does
[01:18] <smarter____> iive: sure, why not?
[01:18] <michaelni> smarter____, if you and or mraulet would be maintainers of hevc in ffmpeg then you would have the last word on patches but you of course would need to review them on ffmpeg-devel and fix regressions if there ever are any reported to trak
[01:19] <michaelni> and if you maintain it then you could ensure that all changes stay in sync with libav
[01:19] <michaelni> if you make sure all things get into both projects
[01:21] <iive> wm4: imho, libav are not merging it, because they want to point that ffmpeg always merges low-quality, unfinished, work in progress code. 
[01:22] <BBB> saste: it's true
[01:22] <smarter____> there is no libav conspiracy, the goal as far as I know is to get the decoder in the next release
[01:23] <iive> is there some time frame for that?
[01:23] <smarter____> I don't know
[01:23] <smarter____> you seem to be eager to merge it. Great, but you should accept the maintainance burden them
[01:27] <michaelni> i dont mind to maintain the code, but iam baned of libav-devel and hated there, so this might not work out so well with keeping the 2 forks in sync
[01:28] <michaelni> so i think it would be better if a more neutral person did maintain it
[01:35] <smarter____> we might be able to work around the banning situation, I don't know
[01:36] <smarter____> I'd be happy to help with keeping things in sync, but not to assume the responsabilities of the maintainer
[01:36] <smarter____> anyway, I have stuff to do, bye
[01:37] <saste> good night
[01:38] <michaelni> saste, n8
[01:48] <cone-360> ffmpeg.git 03Michael Niedermayer 07master:1bf8fa75ee14: avcodec/x86/dsputil_init: fix cpu flag checks
[06:59] <Compn> that was an interesting hevc discussion
[07:00] <Compn> wm4 / j-b : i'm curious if you think splitting the devels has increased devel speed and decreased bikeshed/conflicts?
[07:01] <Compn> wm4 / j-b : or if you dont think that has changed, or wont change if projects are merged? or maybe just dont even care about that and only care about one codebase
[07:02] <Compn> i have a theory (which carl does not agree with) that the split has made things better in some respects
[07:05] <Compn> or maybe i'm just subtly trolling
[07:09] <JEEB> btw, I second smarter on that there's no "we're not merging hevc yet" conspiracy, elenril/koda/vmani have been working on getting it finalized quite a lot as far as I can see :V (merging changes, adding nalff support, general functional and visual prettification)
[07:09] <smarter> lu_zero too
[07:09] <JEEB> yeah
[07:10] <JEEB> also picture-based threading but I am not sure if that's gonna go in with the first review or not
[07:54] <ubitux> michaelni_: done, but i can't review api design alone; and i must say i didn't follow the teletext debate enough
[08:14] <michaelni_> ubitux, thanks
[08:16] <michaelni_> about API, maybe i dunno, iam not working on subtitles
[08:17] <ubitux> you're more familiar with the codec caps typically
[08:17] <michaelni_> s/maybe/maybe nicols/saste have comments/
[08:17] <ubitux> you might want to check if it's consistent with the way we deal with a & v
[08:25] <michaelni_> ubitux, sounds consistent
[09:23] <ubitux> lol @ 2 pass cosmetics
[09:33] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:ab8cbfe0dd77: avcodec/x86/dsputil_init: remove duplicated sse2 idct init
[09:33] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:c35d29a9c824: avcodec/x86/dsputil_init: move ff_idct_xvid_mmxext init
[09:45] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:708b32b6f72c: http: Check the auth string contents and not only the pointer
[09:45] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:0a6ce255ab49: Merge remote-tracking branch 'qatar/master'
[11:18] <kierank> Compn: the julian assange film name drops FFmpeg
[11:27] <Daemon404> wat
[11:27] <Daemon404> also i heard that fil is full of bs
[11:28] <Daemon404> film*
[11:30] <Daemon404> [06:09] < JEEB> btw, I second smarter on that there's no "we're not merging hevc yet"
[11:30] <Daemon404> ->
[11:30] <Daemon404> http://i.imgur.com/ePDZN6V.png
[11:47] <kierank> Daemon404: meh ffmpeg should just merge it
[11:47] <Daemon404> im merely making fun of the conspiracy theories
[11:47] <Daemon404> no comment on merging
[11:47] <kierank> yes clearly there is an undertone of libav conspiracy here
[11:48] <kierank> but who cares
[11:51] <Daemon404> im not too concerned either way
[11:51] <Daemon404> since there is no HEVC encoder whch isnt worse than x264.
[11:51] <kierank> yes but there is some content out there
[11:51] <kierank> not much admittedly
[11:51] <Daemon404> where?
[11:52] <kierank> on satellite
[11:52] <Daemon404> really?
[11:52] <Daemon404> wow.
[11:52] <kierank> yes
[11:52] <kierank> pre-encoded though
[11:52] <Daemon404> ah
[11:52] <Daemon404> probably MC
[11:52] <kierank> ateme i think
[11:52] <Daemon404> is ateme hw only now
[11:52] <Daemon404> isnt*
[11:52] <kierank> no ateme hevc is software
[11:53] <Daemon404> oic
[11:53] <kierank> imo they'd be pissing money away doing it in hardware
[11:53] <Daemon404> i see very little public info on this
[11:53] <Daemon404> other tan some tiny press releases
[11:53] <Daemon404> the usual "Contact us for the useful info"
[11:53] <kierank> ask the developer in #x265 if you want
[11:54] <kierank> :)
[11:54] <Daemon404> lul
[13:09] <mraulet> kierank: how do you know?
[13:10] <kierank> it's the one on eutelsat iirc
[13:16] <mraulet> hardware encoder?
[13:16] <mraulet> hmmm
[13:17] <mraulet> this is an offline 4K encoding
[13:17] <mraulet> could be HM
[13:18] <saste> how can i get a patch file from this: https://github.com/FFmpeg/FFmpeg/pull/38/files
[13:18] <saste> ?
[13:29] <michaelni_> you could checkout the git repo and use git show, dunno if theres a easier way
[13:30] <michaelni_> saste, https://github.com/FFmpeg/FFmpeg/pull/38.diff
[13:31] <michaelni_> saste or this https://github.com/FFmpeg/FFmpeg/pull/38.patch
[13:36] <saste> michaelni_, thanks
[13:38] <kierank> mraulet: no software and offline
[13:38] <kierank> could be hm
[14:31] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:a1b9004b768b: avcodec/jpeg2000dec: fix context consistency with too large lowres
[14:42] <cone-101> ffmpeg.git 03Paul B Mahol 07master:ccfb550b2c5d: fate: add pxr24 exr test
[14:42] <dol> guys can anyone please look at the problem that I described in detail here: http://forum.doom9.org/showthread.php?t=169036
[14:43] <dol> I could solve it by increasing the width information by 1 but I don't think that this is the right way to do
[14:43] <dol> so, could anyone explain me why I have this strange effect?
[14:46] <michaelni_> dol, does this only happen with SWS_FAST_BILINEAR ?
[14:46] <dol> I will check it with SWS_LANCZOS, just a moment
[14:49] <dol> michaelni_, no I have the same issue with SWS_LANCZOS as well
[14:49] <dol> it works without this effect if I set the width +1, but I dunno what is wrong
[14:50] <michaelni_> whats the width and height ? also i guess you are only converting colorspace no change in w/h ?
[14:51] <dol> michaelni_, width= 932  height=582
[14:51] <dol> and I dont do any scaling
[14:51] <kierank> stride probably
[14:51] <dol> +kierank, could you be more specific?
[14:52] <kierank> is your linesize allocated correctly
[14:52] <dol> +kierank, do you mean av_pic->linesize or fRGB->linesize?
[14:52] <kierank> both
[14:53] <dol> well, the first one comes from avcodec_decode_video2
[14:53] <dol> so it is filled there
[14:54] <dol> for the second one, I use avpicture_fill and tehre I specify width and height
[14:54] <dol> so I suppose it is filled there
[14:54] <dol> when I debug the code, I see that the fRGB->linesize[0] = 3728
[14:54] <dol> the rest is 0 
[14:56] <michaelni_> dol, also i assume this is the latest swscale from ffmpeg git ? (i mean not from 3 year old ffmpeg or so)
[14:57] <dol> michaelni_, it is very recent
[14:57] <dol> 1.1.2
[14:58] <ubitux> it's not at all then
[14:58] <michaelni_> can this be reproduced with command line ffmpeg ?
[14:59] <ubitux> dol: almost one year now
[14:59] <cone-101> ffmpeg.git 03Stefano Sabatini 07master:3b9f8e7cd919: lavf/segment: simplify segment_count update
[14:59] <cone-101> ffmpeg.git 03Billy Shambrook 07master:67e507e10e97: lavf/segment: log segments as they end to AV_LOG_VERBOSE
[14:59] <dol> well, I have another system where I use the recent check out and it is also there
[14:59] <dol> michaelni_, I tried it but couldn't reproduce
[15:03] <dol> but how come width+1 can solve the issue?
[15:03] <michaelni_> unscaled uses seperate codepathes in several cases, that could affect it
[15:04] <michaelni_> also not being a multiple of 2,4,8,.. can affect things but the failure would then be expected on the %2!=0 side
[15:05] <dol> michaelni_, yes but then I should have seen the same effect when I use command line
[15:05] <dol> of course there I used y4m but shouldn't be different i guess
[15:06] <michaelni_> i would first suggest that you try latest swscale
[15:06] <michaelni_> and you could put a printf in the sws init to see what exact parameters are used by ffmpeg over the comad line
[15:07] <michaelni_> including linesizes and flags
[15:19] <cone-101> ffmpeg.git 03Stefano Sabatini 07master:1120fd7852cb: lavf/segment: simplify logic and fix !=0 check on segment_end return value
[16:10] <Compn> kierank : lol! we need a clip now. 
[16:11] <Compn> i havent seen it, but i dont get why they need to even embellish the facts , the real story is exciting and crazy enough as-is...
[16:11] Action: kierank makes no comment
[16:14] <Compn> ah it doesnt have great movie scores
[16:14] <Compn> how unfortunate :P
[16:16] <Compn> oh thats why, its an adaptation of that guy who left 
[16:16] <Compn> er adaptation of that guys book
[16:46] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:51df6169091b: configure: Warn when inline asm is disabled for ICL
[16:48] <Compn> hehe
[16:48] <Compn> ffmpeg -i in.png out.png
[16:48] <Compn> 600k > 800k 
[16:48] <Compn> maybe i have to play with compression
[17:52] <cone-101> ffmpeg.git 03Derek Buitenhuis 07master:00aa24ffee91: tableprint: Fix use of a size_t print with MSVC
[17:52] <cone-101> ffmpeg.git 03Derek Buitenhuis 07master:008014b5e724: tablegen: Don't use cbrtf in host tools
[17:52] <cone-101> ffmpeg.git 03Derek Buitenhuis 07master:50867209930f: cos_tablegen: Don't use lrint
[17:52] <cone-101> ffmpeg.git 03Derek Buitenhuis 07master:e51692114354: mpegaudio_tablegen: Don't use llrint
[17:52] <Daemon404> 9 months later...
[17:53] <Daemon404> michaelni_, ^ you can ignore the libav versions of these (which differ) during merge
[17:54] <michaelni_> Daemon404, ok, lets hope i wont forget
[17:55] <Daemon404> theyre almost the same
[17:55] <Daemon404> so it will be a really obvious merge conflict
[18:37] <saste> michaelni_, for example, we allow pix_fmt to be set through an int, and so far nobody complained about a bugreport with aformat=42
[18:40] <michaelni_> thats unrelated, we didnt change the meaning or decimal formats
[18:42] <michaelni_> oF
[18:47] <wm4> lol mixing up user-facing option parsing and internal API usages
[18:56] <michaelni> saste, wm4, iam happy with any solution you two agree on
[19:08] <saste> michaelni, it's getting boring, i'll push my latest patch if noone is against
[19:08] <michaelni> +1
[19:08] <saste> more bikering about what should be deprecated can be done later (not by me)
[19:08] <michaelni> ill post a patch about that if i dont forget
[21:10] <michaelni> mraulet, smarter, did you after the standard vs draft discussion yesterday find a consensus ? iam asking as i really would like to have hevc support in ffmpeg 2.1 which we wil probably release soon
[21:12] <smarter> You're the one who decides to merge or not
[21:13] <JEEB> there are two samples still failing on PPC it seems
[21:13] <JEEB> but it seems like mraulet got that one of the last uninitialized memory accesses done after some valgrinding was done
[21:13] <smarter> If you merge it, I expect you to try very hard to not diverge, that's all
[21:14] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:59352a07d856: avcodec: improve precission for cbrtf() emulation
[21:16] <mraulet> michaelni_: can I have a request on you last commit related to hevc/h.265? I reallly would like the raw_parser to be HEVC
[21:16] <mraulet> then I will think :-)
[21:17] <mraulet> but yes I did fix some valgrind issues
[21:18] <mraulet> https://github.com/OpenHEVC/libav/commits/hevc_upstream
[21:19] <mraulet> when is the release?
[21:19] <michaelni> i was hoping within the next 1-2 weeks
[21:21] <mraulet> I have 2 yuv that I would like to get back
[21:22] <mraulet> I support smarter on his request
[21:27] <michaelni> I have no intent to diverge, but of course i will probably fix bugs if i run into any, and might even add a feature here or there if i find the time.
[21:27] <smarter> and as I said, I hope you'll make it easy to port these changes to libav
[21:32] <Compn> smarter : we need someone to mail patches from michael to libav list, since hes banned
[21:33] <smarter> it'd be nice if an ffmpeg dev could do that
[21:34] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:12cc3bf29ae4: avformat: rename a few more h.265 to HEVC
[21:34] <Compn> ffmpeg devs seem busy doing other things. but its always possible
[21:35] <Compn> maybe i could put a word out looking for a volunteer patch person to help with this
[21:36] <Compn> nah
[21:37] <JEEB> personally I'm fine with any help towards the development of the HEVC decoder :) If the PPC failures can get fixed, and then some general polish / fuzzing can be added, I'd almost say it'd be ready for prime time.
[21:38] <mraulet> good
[21:38] <michaelni> smarter, i dont think there will be that many patches, so you should be able to git fetch , cherry pick and send-email them yourself
[21:51] <smarter> If you could ensure your patches apply to the https://github.com/OpenHEVC/libav/commits/hevc_upstream branch, that would be satisfactory
[21:53] <mraulet> it sounds good to me too
[21:58] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:2a19fcc12311: avcodec/mpegaudio_tablegen: remove dead branch
[22:21] <michaelni> mraulet, smarter where can i find the samples for fate ?
[22:28] <JEEB> michaelni, http://wftp3.itu.int/av-arch/jctvc-site/bitstream_exchange/under_test/
[22:29] <JEEB> koda has poked people regarding if they can be provided elsewhere (FATE mirrors)
[22:37] <michaelni> JEEB, atm i first want to make sure the decoder passes the tests here locally
[22:38] <michaelni> and thx for the link
[22:41] <wm4> <Compn> smarter : we need someone to mail patches from michael to libav list, since hes banned <- oh god I'm dying
[22:41] <wm4> most retarded thing I've heard today
[22:44] <iive> well, i'm quite sure that there are libav developers who are well aware of the michaelni work in ffmpeg.
[22:45] <iive> given how much effort they spend writing their own alternatives of his fixes.
[23:53] <cone-770> ffmpeg.git 03Guillaume Martres 07master:c8dd048ab8cf: lavc: add a HEVC decoder.
[23:53] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:af980aa4f68e: lavc/hevc_ps: fix PIX_FMT enums
[23:53] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:f2dd45d06c60: lavc/hevc: mark decoder as experimental
[23:53] <cone-770> ffmpeg.git 03Mickaël Raulet 07master:93c1fe4de393: hevc: add ts demux support
[23:54] <michaelni> Paranoialmaniac, ok if i push the mkv & mov demux support too ?
[23:55] <smarter> michaelni: will you update the hevc decoder snapshot you pushed before releasing ffmpeg 2.1 with the fixes that are currently getting in?
[23:55] <michaelni> smarter, i intend to of course 
[23:55] <smarter> good :)
[23:55] <michaelni> and if i miss any fix, tell/ping me
[00:00] --- Wed Oct 16 2013