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

[burek]

[00:48] <llogan> i'm surprised that there was any response at all
[01:09] <cone-123> ffmpeg.git 03Vittorio Giovara 07master:4d686fb721b4: matroskaenc: convert avstream stereo3d side data during encoding
[01:09] <cone-123> ffmpeg.git 03Michael Niedermayer 07master:39cd9fdbf802: Merge commit '4d686fb721b485ebbc4c7779d927d876c1e630f7'
[01:09] <Compn> cant say we didnt try
[01:19] <cone-123> ffmpeg.git 03Diego Biurrun 07master:9e8bbe7d4d1d: license: Mention that vf_interlace is GPL, not LGPL
[01:19] <cone-123> ffmpeg.git 03Michael Niedermayer 07master:7771daaea7d5: Merge commit '9e8bbe7d4d1dcd5fec491dbfbb98ed2038a7bed5'
[01:39] <cone-123> ffmpeg.git 03Michael Niedermayer 07master:37520a91ace8: avformat: drop redundant MATROSKA_VIDEO_STEREO_MODE_COUNT identifier
[01:39] <cone-123> ffmpeg.git 03Michael Niedermayer 07master:22652dc2b8d6: avcodec/avcodec: fix missing doxygen comment marker
[04:29] <cone-123> ffmpeg.git 03Vignesh Venkatasubramanian 07master:4c9204783ad2: fate: Add basic tests for WebM Dash Manifest
[05:58] <pross-au> cehoyos: why label #3898 as 'fails to play broken file'
[07:35] <ubitux> kierank: no one mentioned 2011 yet
[07:57] <ubitux> Compn: the fact that concat is seemingly simpler in mencoder is not the reason people stick with it
[07:57] <ubitux> Compn: the lack of some features might be
[08:15] <wm4> ubitux: "seemingly"?
[08:58] <ubitux> wm4: replace with "limited and"
[08:58] <plepere> good morning all
[09:50] <Guest61930> hi, i am using ffmpeg to get Hardware encodded H264 video. i am using this in such way " ffmpeg -f v4l2 -i /dev/video0 -map 0 -c:v copy -an -b:v 64k out.mkv. The output video format is undf and it is availble with overshooted bitrate upto 144Mbps app. can any one help me out get the Hardware encoded H264 video? 
[10:18] <plepere> Guest61930, try asking in #ffmpeg
[10:54] <ubitux> oh ffs koda asking for meeting irl as if it will make any difference
[12:40] <cone-881> ffmpeg.git 03Paul B Mahol 07master:be3d8073ed83: avcodec/wavpack: increase WV_MAX_SAMPLES
[12:47] <wm4> wow pgs looks pretty simple
[12:52] <ubitux> wm4: you mean "sup"? :P
[12:52] <wm4> yes
[12:52] <ubitux> yes, less insane than vobsub
[12:52] <ubitux> at least you don't need another index
[12:53] <ubitux> but you can have only one stream afaict
[12:53] <ubitux> it's almost a raw muxer
[12:54] <Compn> dont worry, i'm sure sony made it insane in some ways :P
[13:10] <cone-881> ffmpeg.git 03Michael Niedermayer 07master:5ce98e774eea: fate/vpx: make webm dash manifest tests depend on the WEBM_DASH_MANIFEST demuxer
[13:10] <cone-881> ffmpeg.git 03Michael Niedermayer 07master:72732f2dddab: avformat/webmdashenc: use av_strlcpy() and allocate enough space
[13:13] <Compn> ubitux breaking out the logic arguments :D
[13:13] <Compn> re mailing list discussions
[13:44] <ubitux> wm4: i know diego didn't keep ffmpeg in cc, but please make sure you keep both ml when replying
[13:44] <wm4> didn't pay attention to that
[13:44] <ubitux> yep, i know :)
[13:45] <ubitux> that mail was targetted @ libav anyway
[13:51] <wm4> btw. what does Libav use instead of lena.pnm?
[13:51] <ubitux> Libav debian package has the issue
[13:51] <ubitux> it was just not raised
[13:53] <wm4> hurr
[13:57] <ubitux> i can't find the mail of the guy @ http://blog.ricbit.com/2009/11/lena-e-ilena.html
[13:57] <ubitux> can anyone confirm?
[13:57] <ubitux> i'll probably contact directly http://www.ilafox.com/2010/04/contato.html to get a "raw" version otherwise
[14:03] <ubitux> wm4: it seems you're making some friends&
[14:14] <cone-881> ffmpeg.git 03Peter Ross 07master:9b8eedd736ea: avformat/wtvdec: seek over broken chunks
[14:33] <kierank> i like the way libav people stop ccing ffmpeg-devel
[14:33] <kierank> well diego
[14:34] <ubitux> kierank: might not be malice, really
[14:35] <wm4> it's good that you try to interpret it not in that way
[14:38] <wm4> what's the best way to create a lavfi filter graph with an optional additional output pad?
[14:38] <wm4> i.e. I don't know whether the graph will have that output or not
[14:45] <__gb__> ubitux, michaelni: have you considered using one of those images from fotolia for a lena replacement? that used to be free but I am not so sure nowadays
[14:45] <ubitux> i'd personally like to keep a lena.pnm file, because we might have a few references
[14:46] <ubitux> like typically in the bug tracker
[14:46] <ubitux> also, it has a special symbolic
[14:46] <ubitux> that's why i liked the idea of using the "free version of lena" from the blog post
[14:46] <__gb__> yes, but if the fotolia conditions are ok, there could be some girly face in there, isn't it?
[14:47] <ubitux> i don't know fotolia
[14:48] <__gb__> or someone could find lena of today and ask for shooting her :)
[14:49] <__gb__> shooting, as in "take a photo" of course, hey
[14:49] <ubitux> https://www.flickr.com/search/?text=lena&sort=relevance&license=4%2C5
[14:49] <durandal_1707> why not make selfie...
[14:50] <ubitux> there are tons of possibilities really
[14:52] <__gb__> but the difficulty is to find something with the same characteristics, or having debian just decide on the way they prefer?
[14:52] <ubitux> decide on something
[14:52] <ubitux> there are various prosposal
[15:04] <Daemon404> btw, asm dudes (BBB, ubitux, jamarial (not here)), bugmaster posted a useful patch fo x86inc you may want to sync once pushed
[15:04] <Daemon404> it detects instructions used in the wrong cpu level
[15:04] <Daemon404> e.g. mmx2 in mmx
[15:04] <ubitux> ooh
[15:04] <ubitux> i saw that discussion, wasn't kurosu talking about that?
[15:04] <Daemon404> maybe
[15:05] <Daemon404> i just saw a patch materialize yesterday
[15:05] <ubitux> it sounds pretty cool
[15:05] <ubitux> Daemon404: url?
[15:05] <plepere> oh, great news !
[15:05] <Daemon404> [19:09] < BugMaster> fionag: Gramner: http://privatepaste.com/d30aa7a940 patches can squashed together
[15:05] <Daemon404> CAUTION: unmerged and unreviewed
[15:05] <Daemon404> so dont go pushing it to ffmpeg ;)
[15:06] <ubitux> would be nice to make it possible to error out
[15:07] <ubitux> instead of just warn
[15:07] <Daemon404> should be easy enough
[15:07] <Daemon404> you should tell bugmaster / fionag
[15:07] <nevcairiel> Warnings help enough really, since the developer will see it
[15:07] <ubitux> i'm assuming it might not be reliable enough so it's kept as warning
[15:07] <Daemon404> nevcairiel, not in the wasteland of ffmpeg warnings
[15:07] <Daemon404> ubitux, maybe
[15:07] <ubitux> but yeah really, cool stuff
[15:08] <ubitux> i wonder if it will detect issues :)
[15:08] <Daemon404> my money is on yes
[15:08] <nevcairiel> Probably some sse2 in SSE, not like anyone really tests sse-only hardware anymore
[15:09] <ubitux> we have such box afaik but it probably doesn't cover every asm ofc
[15:10] <Daemon404> nevcairiel, i used to have an atom
[15:10] <Daemon404> which didnt even have sse
[15:10] <Daemon404> clang couldnt even build for it
[15:10] <Daemon404> :D
[15:10] <Daemon404> er
[15:10] <Daemon404> nto atom
[15:10] <Daemon404> geode
[15:21] <J_D> I tested that patch from bugmaster on ffmpeg here and it built without issue
[15:22] <J_D> and I think the commit message is slightly wrong
[15:23] <J_D> it uses the %error feature of the preprocessor
[15:23] <Daemon404> ah
[15:23] <J_D> Perhaps I should test it to make sure it is a fatal error
[15:29] <J_D> Oh it isn't
[15:30] <J_D> Why the eck is it called %error then?
[15:30] <J_D> *heck
[15:31] <Daemon404> hell if i know
[15:31] <nevcairiel> It should be
[15:32] <nevcairiel> Although they may have %fatal if it isn't
[15:33] <nevcairiel> At least nasm has thay
[15:33] <nevcairiel> that*
[15:36] <J_Darnley> No it does not have %fatal
[15:38] <J_Darnley> The comments about using %error in the yasm docs are then just inaccurate.
[15:38] <J_Darnley> "any user who fails to understand the way your code is supposed to be assembled will be quickly warned of their mistake, rather than having to wait until the program crashes"
[15:39] <J_Darnley> Not so much in this case
[15:39] <J_Darnley> It will be assembled just fine until you run into an illegal instruction.
[15:39] <J_Darnley> ... during execution
[15:40] <J_Darnley> Anyway.  The patch is definitely useful for people adding or porting code
[15:53] <saste> anybody willing to review the avstring/utf8 decoding patch?
[15:53] <saste> otherwise i'll probably push it in a day
[15:58] <kierank> 2:05 PM <"Daemon404> CAUTION: unmerged and unreviewed
[15:58] <kierank> 2:05 PM <"Daemon404> so dont go pushing it to ffmpeg ;)
[15:58] <kierank> LOL
[15:58] <J_Darnley> If I knew anything about text encoding I might.  Sorry.
[16:11] <nevcairiel> J_Darnley: the documentation does say warned, not fail
[16:11] <nevcairiel> In any case, developers should read their warnings ;)
[16:12] <nevcairiel> Easy enough to grep through a build log now to check too
[16:15] <J_Darnley> ffmpeg doesn't produce any new warning when using the patch.
[16:44] <ubitux> why Diego doesn't want to update the message with "The ffmpeg program has been deprecated *in the Libav project*"?
[16:44] <ubitux> :(
[16:48] <wm4> it's funny because this message actually is the biggest reason why users hate Libav and think it's malicious
[16:48] <wm4> debian users, I mean
[17:04] <ubitux> haha, he really doesn't want to say "deprecated in the Libav project" and is trying to move it to the next sentence
[17:06] <ubitux> kierank: thx
[17:11] <iive> ubitux: it kind of sounds like "FFmpeg have deprecated the Libav project" :) one does not want to cause such confusion :P
[17:11] <Daemon404> g 31
[17:11] <Daemon404> woops
[17:12] Action: ubitux increments the Daemon404 irc fail counter
[17:12] <Daemon404> :D
[17:15] <ubitux> [~]- grep -iE 'Daemon404> (g )?[0-9]+$' .irssi/irclogs/2014/freenode-\#ffmpeg-devel.log|wc -l
[17:15] <ubitux> 12
[17:15] <ubitux> so there is now 12 fails this year on this channel
[17:15] <Daemon404> thats inaccurate
[17:15] <ubitux> ah?
[17:15] <Daemon404> sometimes i type / N
[17:15] <Daemon404> so it ends up with just a num
[17:16] <ubitux> yes, i handle that
[17:16] <ubitux> http://pastie.org/pastes/9513188/text
[17:16] <wm4> ubitux stalks ffmpeg devs!
[17:16] <ubitux> how evil
[17:16] <Daemon404> ah
[17:16] <ubitux> i'm stealing what they say
[17:17] <Daemon404> maybe it's secretly a code
[17:17] <ubitux> Daemon404: 22 times in #libav-devel btw
[17:17] <ubitux> this year only too
[17:17] <ubitux> you seem to like the 42 window
[17:17] <Daemon404> darkhold too
[17:17] <Daemon404> 42 is my work irc window.
[17:18] <ubitux> how suitable
[17:18] <Daemon404> it just happened to work out that way
[17:18] <Daemon404> happy coincidence
[17:18] <ubitux> 16 on the only darkhold chan i'm on
[17:19] <ubitux> so on a limited scope of 3 channels, you're doing about 100 fails a year
[17:20] <ubitux> (a bit less)
[17:21] <iive> - is that sickle and hammer? aka USSR national emblem.
[17:21] <ubitux> yes
[17:21] <iive> you are evil!
[17:22] <Daemon404> lol
[17:22] <ubitux> it becomes   (and change color) when the command fails nowadays
[17:22] <Daemon404> look at my orgs on github
[17:22] <Daemon404> one is CCCP
[17:22] <Daemon404> with sickle/hammer
[17:22] <Daemon404> ;)
[17:27] <iive> ;)
[17:29] Action: J_Darnley should get some interesting unicode chars in his terminal
[18:10] <Compnn> panasonic using our samples to test its apps :)
[18:18] <kierank> Compnn: which app?
[18:18] <Compnn> "I'm in charge of testing for Mobile Apps that test multiple codec types."
[18:19] <Compnn> no idea
[18:59] <cone-449> ffmpeg.git 03Reimar Döffinger 07master:be4aac302b0c: patcheck: check for pointer arrays that are not const.
[18:59] <cone-449> ffmpeg.git 03Reimar Döffinger 07master:d9e2aceb7f1c: Add missing "const" all over the place.
[19:06] <Compnn> ubitux : and a new troll emerges on deb-dev
[19:06] <Compnn> sigh
[19:08] <Compnn> well yesterday
[19:08] Action: Compnn catches up
[19:19] <wm4> link?
[19:19] <wm4> not following that flame
[19:20] <Compn> https://lists.debian.org/debian-devel/2014/08/msg00914.html
[19:20] <wm4> ah
[19:21] <Compn> it continues over 3 or more mails
[19:21] <Compn> https://lists.debian.org/debian-devel/2014/08/msg00916.html
[19:22] <Compn> carl still continues to upset libav.
[19:22] <wm4> the first mail is constructive and brings up important issues (although there are worse problems that need to be solved before that)
[19:23] <wm4> and the second mail you link, meh.
[19:23] <Compn> i'm curious what an ffmpeg tree sans merges would look like
[19:23] <Compn> no soc code. no ffmpeg-mt code...
[19:23] <wm4> merges are ok, but the libav merges are insane
[19:23] <Compn> back to svn days i'd assume.
[19:23] <wm4> git wasn'T made for that
[19:24] <Compn> i dont think there are any objections to squashing merged code history like that
[19:24] <Compn> although it would probably take a long long time to compress...
[19:26] <nevcairiel> Carl should probably be forbidden to talk in the name of the project, that would make a bunch of people happier. :P
[19:27] <Compn> there is no one that talks in the name of ffmpeg except michael really
[19:27] <Compn> reimar , maybe other roots
[19:27] <Compn> and mostly michael talks for himself
[19:27] <Compn> any talking carl is doing is for himself as well
[19:27] <nevcairiel> Then forbidden to talk at all
[19:27] <Compn> lol
[19:27] <Compn> ffmpeg is not a project that controls its voluntary developers :P
[19:27] <Compn> imo
[19:28] <Compn> you've seen michael's posts, when he wants a change (bug bounties) he asks on list if other devels agree
[19:28] <wm4> the thing is that Libav folks think CE is talking in the name of ffmpeg
[19:28] Action: Compn gives up explaining
[19:29] <wm4> and since nobody stops him, maybe they're right...
[19:29] <Compn> well, you try explain to libav that carl speaks only for himself
[19:29] <Compn> good luck...
[19:29] <Compn> there isnt much censorship here in ffmpeg-land
[19:29] <Compn> i'm glad the project believes in free speech and not banning developers :)
[19:31] <wm4> in general, I'd say if the projects are merged, the source tree should probably start out with Libav, and then all ffmpeg changes should be carefully added back
[19:32] <wm4> of course that'd be a lot of work
[19:32] <kierank> they won't be merged
[19:32] <nevcairiel> Sounds like a fun project for a year
[19:32] <Compn> whos going to test all of those changes though ?
[19:32] <wm4> for some thing it'd be trivial (simple decoders/demuxers), for some almost impossible (changes to mpegvideo and stuff like this)
[19:33] <nevcairiel> And every single change reviewed on a ML? :D
[19:33] <nevcairiel> It'll take two years
[19:33] <wm4> ok I'm giving up the thought.... it's all fucked up
[19:34] <Compn> but keep thinking. always good to keep coming up with ideas 
[19:34] <Compn> the better an idea, the more people will agree.
[19:34] <Compn> cant we go into git history and delete all empty merges ?
[19:34] <nevcairiel> Not counting new stuff at all, I don't know how big a diff would be even. A lot of changes get reimplemented or ported eventually
[19:34] <Compn> i know git wasnt 'built for that' but git is open source and we are open source developers...
[19:35] <Compn> nevcairiel : someone posted a ffmpeg v libav diff a while back.
[19:35] <Compn> or maybe someone even keeps it up to date, forgot the url
[19:35] <kepstin-laptop> rewriting history in git is really annoying, since it changes all the commit hashes
[19:35] <Compn> maybe ubitux has it
[19:35] <wm4> nevcairiel: my idea was that most common code is actually relatively small compared to the total size of the code
[19:35] <wm4> e.g. utils.c is very central, but also just a few kloc
[19:35] <Compn> kepstin-laptop : so theres no way to save the hashes and delete the crap ?
[19:35] <kepstin-laptop> the hashes are calculated from the contents of the git repo, so changing the git repo changes the hashes
[19:36] <kepstin-laptop> i like the merges, they preserve commit authorship and commiter info, including commit dates, and allow you to look up libav git hashes in the ffmpeg repo.
[19:36] <wm4> anyway, there's no way Libav folks will give up their "clean" git history (even though the start of it is full of cvs and svn crap)
[19:37] <Compn> i didnt realize that was a breaker problem
[19:37] <Compn> maybe we could come up with a list of problems that need to be sorted out
[19:37] <kepstin-laptop> it's not like it actually causes any issues with git; even fancy stuff like bisect will work properly.
[19:37] <nevcairiel> Well have to be a bit careful when bisecting though
[19:38] <nevcairiel> When you go into their tree, ffmpeg binary vanishes
[19:38] <Compn> wm4 : what about just starting today as ffmpeg git day one (as-in, zero history at all) , and then no one looks at the old git tree? :P
[19:39] <wm4> Compn: that would be a problem
[19:39] <Compn> bah
[19:39] <nevcairiel> That's terrible
[19:39] <kepstin-laptop> huh, forgot about that :)
[19:40] <kepstin-laptop> in most cases you could just hop over to the nearest ffmpeg merge, but in some cases, the issue might be in the middle of a series of commits in libav.
[19:40] <nevcairiel> We have a script that simply skips revisions that don't have the binary. So in the end you would just end on the merge and not the proper commit
[19:40] <nevcairiel> But merges contain mostly only one commit these days, so that's not a problem
[19:41] <iive> https://lists.debian.org/debian-devel/2014/08/msg00918.html  Lovely reply by debian developer :)
[19:41] <gnafu> fflibav-ng
[19:42] <iive> gnafu: put 2 somewhere :)
[19:42] <Compn> again , while i dont speak for ffmpeg, nor would i want to censor anyone. i suggest ffmpeg devs please do not flame on debian-devel list 
[19:43] <gnafu> iive: f2libav-ng (where "f2" in the logo is stylized like F²).
[19:44] <J_Darnley> I was very impressed with the work done to migrate ffmpeg to git.  Then I started hating all the merge commits that appeared.
[19:44] <iive> gnafu:  purrrrfect
[19:45] <J_Darnley> "ng"?
[19:45] <gnafu> Next Generation
[19:45] <gnafu> It used to be a common addition to the name of a fork.
[19:45] <J_Darnley> :)
[19:46] <iive> startrek-ng
[19:47] <nevcairiel> Technically that was tng
[19:47] <kepstin-laptop> in the musicbrainz project, we rewrote our tagger program as a "next generation" version, and named the new one "picard" :)
[19:48] <gnafu> OOOOOOOOOOoooooooooooohhhhhhhhhhhhhhhhh.
[19:48] <gnafu> kepstin-laptop: I never put that together, but that's awesome XD.
[19:48] <iive> LoL
[19:54] <cbsrobot> I didn't bisect too often, but imho the atmoic merge commits are the way to go if you need to merge
[19:54] <nevcairiel> It just makes the history soooo ugly ;)
[19:59] <Compn> maybe we should make a new channel for talking about ffmpeg/libav
[20:00] <Compn> and leave this one to technical discussions only :P
[20:00] <Compn> or maybe just take all the ffmpeg/libav stuff to #libav :P
[20:00] <Compn> er #libav-devel
[20:00] <durandal_1707> too much weed recently?
[20:01] <Compn> i did eat too much the other day and felt woozy for 24 hours durandal_1707. but no i'm good now
[20:01] <Compn> just seems like we go on never ending bikesheds here 
[20:01] <Compn> sometimes :P
[20:05] <ubitux> < wm4> in general, I'd say if the projects are merged, the source tree should probably start out with Libav, and then all ffmpeg changes should be carefully added back // or maybe you could git log from 3 years ago and try to review it and fix accordingly, it will be faster and less error prone
[20:05] <ubitux> because some merges actually fixed some merged input
[20:06] <durandal_1707> libav can do that already
[20:06] <wm4> my idea was mostly like: take a diff between ffmpeg and libav, then split that diff into lots of patches (but of course that would lose most of authorship info etc.)
[20:07] <ubitux> wm4: erm, you know there are like 100.000 more lines of code?
[20:07] <wm4> most of them are in cleanly separate, like individual filters or demuxers etc.
[20:08] <wm4> +files
[20:08] <Compn> thats still 2+ years of patches to review
[20:08] <ubitux> 3+ years
[20:08] <ubitux> that won't happen, really
[20:08] <wm4> anyway, it's either that, or accept the ffmpeg history
[20:08] <wm4> and the latter won't happen
[20:08] <Compn> or delete all history :P
[20:08] <ubitux> there is no way the whole FFmpeg can be reconstructed completely from this
[20:09] <ubitux> and it's an insane waste of time
[20:09] <ubitux> IMO
[20:09] <Compn> +1
[20:09] <ubitux> try it, i'm pretty you'll abandon after maybe 10-15 patches
[20:09] <ubitux> +sure
[20:09] <ubitux> out of thousands
[20:09] <wm4> :)
[20:10] <iive> is there anything of substance that is in libav but not in ffmpeg?
[20:10] <wm4> iive: cleaner code
[20:10] <durandal_1707> different xbm decoder
[20:10] <ubitux> (but with more bugs on common parts?)
[20:10] <wm4> ubitux: yes
[20:10] <wm4> probably
[20:11] <ubitux> what's the point of "cleaner code" then
[20:11] <durandal_1707> K&R
[20:11] <ubitux> except faping over git history :p
[20:11] <iive> LoL
[20:11] <durandal_1707> rotfl
[20:11] <wm4> ?
[20:11] <Compn> faping = masturbating
[20:12] <wm4> ask Daemon404 what he thinks of mini's merge commits
[20:13] <ubitux> arg again an interview about "code quality" in FFmpeg
[20:13] <durandal_1707> what should i reply?
[20:14] <ubitux> "go look at Libav, code is prettier"
[20:14] <ubitux> i might answer him this week end
[20:15] <wm4> of course both look like shit (if you look at the dark corners)
[20:16] <wm4> (like with any software)
[20:16] <ubitux> yes but it's the fault of FFmpeg
[20:16] <ubitux> Libav is cleaning up all this mess fortunately
[20:16] <Compn> i blame that gerald launtau guy :P
[20:16] <Compn> ehe
[20:22] <iive> well, what they claim might not be what they actually do.
[20:22] Action: Compn thinks about printing up tshirts 'carl eugen has a posse'
[20:23] <ubitux> iive: i hope you understand that was irony :p
[20:23] <iive> well, pow law 
[20:26] <iive> btw, I thought of explaining why carl uses the strongest words against them, given that all involved parties are now ffmpeg developers. But imho, it is kind of disproportional response.
[20:47] <ubitux> the main problem is not that he's right or wrong, the problem is that showing off such hostility really doesn't help FFmpeg at all
[20:47] <ubitux> but i guess he's aware of that and just think that by principle he must say this
[20:48] <ubitux> his answers are used against the project, that's the unfortunate part
[21:06] <iive> ubitux: i can turn that around, but it would involve opening old wounds. And IMHO, the fact that 2 people pointed to the same email, just comes to show that there are not that many and diverse insults.
[21:07] <wm4> are you still talking about carl?
[21:07] <iive> yes
[21:08] <wm4> he uses hate speech against libav all the time
[21:08] <ubitux> on every occasion yes
[21:08] <iive> i know.
[21:31] <iive> actions speak more than words.
[23:16] <kierank> Daemon404: http://hwcdn.net/j9t9v3v5/cds/ffmpeg.tar.gz
[23:16] <kierank> another elemental dump
[23:16] <Daemon404> whats different
[23:16] <kierank> see your email
[23:17] <kierank> it's basically an acknowledgement that the first dump they sent me was bullshit
[23:17] <Daemon404> theyre still full of shit
[23:17] <Daemon404> as seen in your reply
[23:21] <kierank> I still don't see the mxf patches
[23:21] <wm4> is this communication public somewhere?
[23:21] <kierank> not yet
[23:22] <kierank> jesse is the cto
[23:34] <kierank> i see nothing mxf related in the dump
[23:35] <kierank> +//donn 
[23:35] <kierank> +//patch for sar issues with avci-50 being backwards (3:4):
[23:35] <kierank> hahahah
[23:35] <kierank> this is the avc intra
[00:00] --- Sat Aug 30 2014