[00:11] <Daemon404> michaelni, can you clarify ea535ed50d1b8d751e2d194a987295ab38daf1a2? [00:12] <michaelni> Daemon404, i dont remember ATM thats a year ago ... [00:12] <michaelni> but [00:12] <michaelni> as we are already speaking [00:12] <michaelni> what is with postproc ? [00:13] <Daemon404> libav people want it out of their repo and separate, and i thought writing a script to do so would be interesting [00:13] <michaelni> sofar ok [00:14] <Daemon404> not much more to it than that... [00:14] <michaelni> some chance it can be merged with ffmpegs ? [00:14] <michaelni> so there is just 1 postproc ? [00:14] <Daemon404> michaelni, thats why im asking.. im backporting all the ffmpeg-only commits to the standalone postproc [00:15] <Daemon404> the one i linked is the last one [00:15] <michaelni> well, i already merged everything in my repo a year ago :) [00:15] <Daemon404> well they should be identical now [00:16] <Daemon404> only without the merge meta-commits [00:16] <Daemon404> (i did a diff on the commit logs) [00:16] <michaelni> good [00:17] <nevcairiel> do a diff on the code, and you'll know if they are identical. ;) [00:17] <ubitux> Daemon404: i think that commit could be squashed with the one just after (84fb4e9df737c856cca7767016110fc74bee56cb) [00:17] <ubitux> which explains a bit what's wrong [00:17] <michaelni> ubitux, iam not a friend of history rewriting [00:17] <Daemon404> nor am i [00:18] <ubitux> i didn't meant to actually do the squash [00:18] <ubitux> but they are related [00:18] <Daemon404> i only do it if i havent made somethign public yet [00:18] <michaelni> such squashing would contradict in a confusing way any discussion that happened for example ... [00:19] <ubitux> i don't have much opinion on writing/rewriting the history, just pointing out some clues [00:20] <Daemon404> man i dont know how i survived withouy git before.. [00:21] <michaelni> Daemon404, placebos ... [00:21] <Daemon404> michaelni, ? [00:21] <michaelni> https://en.wikipedia.org/wiki/Placebo [00:22] <ubitux> Daemon404: the workflows were pretty different, so problems were not the same [00:22] <ubitux> and thus, most of the solutions git solve are related to the new way of working with vcs [00:22] <ubitux> s/solutions/problems/ [00:22] <ubitux> i guess © :) [00:22] <Daemon404> ubitux, most problems git solves are due to it beign distrobuted, yes [00:23] <Daemon404> and its lovely branching [00:23] Action: gnafu prefers things that are disco-buted. [00:23] Action: gnafu gets down and funky. [00:25] <michaelni> Daemon404, when you are done with postproc, can we move it to a place i have write access to? [00:26] <michaelni> because id like to maintain it [00:26] <Compn> did you see j-b's repo ? [00:26] <Daemon404> michaelni, http://git.videolan.org/?p=libpostproc.git;a=shortlog [00:26] <Daemon404> j-b clone my repo there [00:26] <Compn> [03:16] <j-b> Compn: http://git.videolan.org/?p=libpostproc.git;a=shortlog [00:26] <j-b> and michaelni already has write access to it... [00:27] <j-b> what do you think? That I am lazy? [00:27] <j-b> oh, alright, I am lazy, but I did it :) [00:27] <Daemon404> michaelni, all i have left to do is -properly- strip down configure, and also figure out how the hell to handle this version stuff [00:27] <Daemon404> i.e. the +100 [00:28] <michaelni> Daemon404, can you fix the comiter & commit dates too ? [00:29] <michaelni> its all 2 days ago ;) [00:29] <Daemon404> the commit dates are fine [00:30] <Daemon404> the push dates are obviously 2 days ago [00:30] <michaelni> http://git.videolan.org/?p=libpostproc.git;a=commit;h=29f1f61a4a74c08070eb14... [00:31] <michaelni> commiter and date looks unlikely relative to author and date [00:31] <michaelni> 2008 vs 2012 [00:31] <michaelni> also "From original Libav commit:" <-- this is unneeded [00:31] <Daemon404> authorMichael Niedermayer <michaelni@gmx.at> [00:31] <Daemon404> Thu, 10 Jan 2008 06:05:12 -0500 (11:05 +0000) [00:31] <Daemon404> ^ looks right to me [00:31] <michaelni> yes [00:32] <michaelni> but it was also commited in 2008 [00:32] <Daemon404> "comitter" refers to the push date [00:32] <Daemon404> and it WAS pushed in 2012 [00:32] <Daemon404> to the new repo [00:32] <Daemon404> git will likely throw a shitfit if i try and alter push dates [00:32] <michaelni> theres no push date [00:33] <Daemon404> commit date IS the push date. [00:33] <Daemon404> or well, when it was applied to my standaloen rpeo [00:33] <michaelni> "git commit" time is the commit time [00:33] <Daemon404> repo* [00:33] <Daemon404> the time that teh author comitted it is under the top date [00:33] <Daemon404> the second date is when i applied it to mine [00:33] <Daemon404> which is correct and shouldnt be changed [00:34] <michaelni> thats not correctly converted then [00:34] <Daemon404> why exactly should the date i put it in my repo say the date you put it in ffmpeg? [00:34] <Daemon404> that doesnt make any sense. [00:34] <michaelni> look at ffmpeg or libav [00:34] <michaelni> git log --pretty=fuller [00:34] <Daemon404> the info on when it was originally coded is there. [00:35] <Daemon404> there's a reason git has 2 dates. [00:35] <Compn> Daemon404 : so you can pull older versions of ffmpeg and have it work ? [00:35] <Compn> due to correct git dates ? [00:35] Action: Compn guessing [00:35] <Daemon404> Compn, that doesnt make any sense [00:35] <michaelni> In the real history these commits where commited long ago [00:36] <Daemon404> yes but this is in a new repo [00:36] <Daemon404> those dates MUST be relative to this repo [00:36] <Daemon404> the original coding date is in-tact too [00:36] <Daemon404> so i fail to see the problem [00:36] <michaelni> the problem is it looks unprofessional [00:37] <michaelni> like someone not knowing git making this convertion [00:37] <Daemon404> youre complainign about irrelavant data [00:37] <Daemon404> in a way that doesnt make any sense [00:37] <Daemon404> i dont think you really understand the point of that 2nd date yourself. [00:38] <Daemon404> the "commit date" is the date i applied that patch to my own repo. [00:38] <Daemon404> and it is accurate. [00:38] <michaelni> yes [00:38] <michaelni> but it was not your repo [00:38] <michaelni> you are rewriting history [00:38] <Daemon404> it IS my repo [00:38] <Daemon404> i did git init . [00:38] <Daemon404> and created a new repo [00:38] <Daemon404> and imported all the patches [00:39] <Daemon404> the only history being lost is the date you originally pushed it [00:39] <Daemon404> and thats not even useful [00:41] <michaelni> you should read: http://lwn.net/Articles/328438/ [00:41] <michaelni> its from linus [00:43] <Daemon404> michaelni, that contains nothing about push dates. in fact, it seems to solely concern author history. [00:43] <Daemon404> i.e. the first date listed [00:43] <michaelni> the commit messages are changed too [00:43] <michaelni> "From original Libav commit:" [00:43] <Daemon404> i took that idea from git-svn [00:43] <Daemon404> and how it didi t [00:44] <michaelni> see git filter-branch [00:44] <Daemon404> git filter-franch is a massive massive pain in the ass to use tbh [00:45] <Daemon404> i dotn really see a massive issue here, but if youre gonna bikeshed over it [00:45] <Daemon404> ill just change it [00:45] <Daemon404> and make a new repo [00:45] <Daemon404> rather than argue [00:45] <michaelni> please do, and i volunteer to help [00:45] <michaelni> if you want my help [00:45] <Daemon404> i do know how to use filter-branch yes [00:46] <Daemon404> it's just a ugly ugly command :P [00:46] <Daemon404> with nested commands [00:46] <michaelni> ive not used it yet, but i know it should result in something cleaner [00:46] <Daemon404> yeah [00:46] <michaelni> unchanged commit messages [00:46] <michaelni> unchanged commit dates [00:46] <Compn> or you could keep postproc in ffmpeg and skip this extra repo stuff :P [00:46] <Daemon404> the changed commit messages were solely my doing [00:47] <michaelni> its ok to add the original hash as reference but iam a bit alergic to the libav advertisement [00:48] <michaelni> libav hasnt written or maintained this code [00:48] <Daemon404> i just use their repo as the base for it because theyre the ones who wanted it [00:52] <michaelni> ok, so we agree, you redo it with unchanged commits, put it in videolan and we have one libpostproc and a happy world ? [00:53] <Daemon404> indeed [00:54] <gnafu> \o/ [00:54] <michaelni> \o/ [00:58] Action: Compn asks dumb question on list, expects dumb answer [00:59] <Daemon404> now to wait a bunch of time with filter-branch runs [00:59] <durandal_1707> Compn: why you do not ask here [00:59] <Daemon404> this thing is SLOW [00:59] <Compn> durandal_1707 : because i also crossposted to other list [00:59] <michaelni> we can surely give you a dumber awnser than any list [01:00] <Compn> michaelni : btw , a note about ffv1 having (whichever colorspace(s) were added) and being worked on in the changelog would be nice :) [01:00] <Compn> i know a few people were interested in ffv1 development [01:00] <durandal_1707> Compn: interested in what? [01:01] <Compn> in using ffv1 as an intermediate format [01:01] <Compn> users i mean [01:01] <Daemon404> Compn, nobody uses ffv1 [01:01] <Daemon404> it is FAR too slow [01:01] <Compn> isnt it faster than huff ? [01:01] <Daemon404> LOL [01:01] <Daemon404> no [01:01] <durandal_1707> Daemon404: than nobody use x264 lossless too [01:01] <Daemon404> x264 lossless is faster [01:01] <Daemon404> <_< [01:02] <Daemon404> for all intents and puroses [01:02] <Daemon404> purposes* [01:02] <durandal_1707> Daemon404: you are not making any sense [01:02] <Daemon404> how so? [01:03] <Daemon404> nobody uses ffv1 because it is incredibly slow; x264 is not as slow [01:04] <Compn> Daemon404 : we await your patches to include x264 into ffmpeg ;P [01:04] <Compn> ehe [01:04] Action: Compn trolling now [01:04] <Daemon404> ;p [01:08] <durandal_1707> Daemon404: there are two coders in ffv1 [01:08] <Daemon404> theyre both slow compared to e.g. huffy [01:08] <Daemon404> and the one that is less slow really doesnt compress better anywya [01:12] <Daemon404> michaelni, git filter-branch -f --index-filter 'git ls-files -s | grep $'\t'libpostproc\/.*$ | GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info && mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE || true' --prune-empty -- --all [01:12] <Daemon404> yup. nice and ugly. [01:16] <j-b> michaelni: you don't happen to have some Dirac 10bits sample? [01:17] <bcoudurier> I use ffv1 [01:17] <bcoudurier> it compresses better than x264 lossless [01:17] <Compn> compression.ru site does lossless video codec comparasions [01:18] <Compn> or did one in the past anyways [01:18] <Daemon404> bcoudurier, for what? archiving? [01:18] <Daemon404> not useful for much else [01:18] <bcoudurier> yes and mezz files sometimes [01:18] <durandal_1707> Daemon404: for intermediate x264 is not realtime anyway [01:18] <Daemon404> bcoudurier, Marc FD has drafted me to code his new lossless codec [01:18] <Daemon404> which supposed has huffy speeds + ffv1 comrpession [01:19] <Daemon404> (needs SSSE3 though) [01:19] <bcoudurier> that's nice [01:19] <Compn> erm, why not just work on another open source one ? [01:19] <Daemon404> Compn, it's being coded into libavcodec. [01:19] <durandal_1707> Compn: FFV2 - FFV9 [01:19] <Daemon404> as well as a qtx/vfw [01:22] <Compn> i mean like lagarith was leading in 2007 :P [01:22] <Compn> http://www.compression.ru/video/codec_comparison/lossless_codecs_2007_en.htm... [01:22] <Daemon404> lagarith was always crap [01:22] <Daemon404> slow and error-prone [01:22] <Daemon404> for practical use i mean [01:22] <durandal_1707> use floating point [01:22] <Daemon404> yes it does. leads to awesome random errors [01:22] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r9430c232e8 10ffmpeg/ffserver.c: [01:22] <CIA-40> ffmpeg: ffserver: fix program reference [01:22] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [01:23] <CIA-40> ffmpeg: 03Paul B Mahol 07master * re39487efe3 10ffmpeg/doc/general.texi: [01:23] <CIA-40> ffmpeg: doc: ffv1 is not experimental any more [01:23] <CIA-40> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [01:23] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [01:23] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r5cd8afee99 10ffmpeg/libavcodec/diracdec.c: [01:23] <CIA-40> ffmpeg: diracdec: Check for negative quants which would cause out of array reads. [01:23] <CIA-40> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind [01:23] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [01:23] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r0065080320 10ffmpeg/libavcodec/proresdec2.c: [01:23] <CIA-40> ffmpeg: proresdec: Fix read via negative index in a global array. [01:23] <CIA-40> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind [01:23] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [01:23] <Compn> Daemon404 : but ok, :) [01:23] <Daemon404> also lagarith's code is terrible [01:23] <Daemon404> kb and kb or msvc intrinsics [01:23] <durandal_1707> I think I will stick with uncompressed formats for a while [01:23] <Daemon404> of* [01:24] <Compn> no on lossless wavelet? [01:24] <Compn> :P [01:24] <michaelni> j-b, i dont think i do, sorry [01:24] <Daemon404> lol wavelets [01:25] <michaelni> or at least iam not aware of having one ... [01:27] <Compn> j-b : we dont have many dirac samples iirc [01:27] <Compn> j-b : carl has been collecting a bunch of samples tho, he may . [01:28] <Daemon404> i must ask tho [01:28] <Daemon404> who actually uses dirac? [01:28] <Daemon404> and why? [01:29] <durandal_1707> who can not pay for H.264 [01:29] <Daemon404> vp8 > dirac [01:30] <durandal_1707> vp8 is full of patents [01:30] <Daemon404> not legally so, yet [01:30] <Daemon404> and so is dirac [01:30] <Daemon404> :) [01:30] <Daemon404> any non-trivial code is full of patents [01:30] <Daemon404> its near-impossible to write code that doesnt violate someone's patent [01:39] <Daemon404> michaelni, looks liek filter-branch is gonna take like an hr to run... [01:39] Action: Daemon404 goes to make food [01:39] <michaelni> j-b, ask anuradha, i guess she either has a sample or knows someone who does or can make one [01:41] <durandal_1707> can i get bigger mthp sample? [01:57] <Daemon404> i cant believe how slow this is... [01:57] <durandal_1707> git is slow [01:58] <Daemon404> yet faster than anything else [02:00] <durandal_1707> Daemon404: there are faster but use more space [02:00] <Daemon404> like? [02:00] <durandal_1707> i forget name [02:01] <Daemon404> i hope you dont mean bzr or hg [02:01] <Daemon404> cause theyre most certainly are not [02:46] <CIA-40> ffmpeg: 03Alex Converse 07master * rc0bc7bd1e7 10ffmpeg/libavformat/swfdec.c: swfdec: Simplify sample rate calculation. [02:46] <CIA-40> ffmpeg: 03Janne Grunau 07master * re67e3a3f4a 10ffmpeg/ (3 files in 3 dirs): [02:46] <CIA-40> ffmpeg: fate-golomb: extend golomb-test to get_ue_golomb_long() [02:46] <CIA-40> ffmpeg: get_ue_golomb_long() is only tested for values up to 2^15 - 2 since [02:46] <CIA-40> ffmpeg: we can not write larger values. [02:46] <CIA-40> ffmpeg: Silence the test on success and return a non-zero value on error. [02:46] <CIA-40> ffmpeg: Use an heap scratch buffer instead of large stack buffer. [02:46] <CIA-40> ffmpeg: Remove unneeded includes. [02:46] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r635bcfccd4 10ffmpeg/libavformat/dv.c: (log message trimmed) [02:46] <CIA-40> ffmpeg: dv: check stype [02:46] Last message repeated 1 time(s). [02:46] <CIA-40> ffmpeg: Fixes part1 of CVE-2011-3929 [02:46] <CIA-40> ffmpeg: Possibly fixes part of CVE-2011-3936 [02:46] <CIA-40> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind [02:46] <CIA-40> ffmpeg: Reviewed-by: Roman Shaposhnik <roman@shaposhnik.org> [02:46] <CIA-40> ffmpeg: 03Alex Converse 07master * r2d1c0dea5f 10ffmpeg/libavformat/dv.c: [02:46] <CIA-40> ffmpeg: dv: Fix small stack overread related to CVE-2011-3929 and CVE-2011-3936. [02:46] <CIA-40> ffmpeg: Found with asan. [02:46] <Daemon404> blech, that wasnt teh right git filter-branch [02:46] <CIA-40> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind [02:46] <CIA-40> ffmpeg: Signed-off-by: Alex Converse <alex.converse@gmail.com> [02:46] <CIA-40> ffmpeg: 03Mans Rullgard 07master * r034b03e7a0 10ffmpeg/libavcodec/ac3dsp.c: [02:46] <CIA-40> ffmpeg: ac3: Do not read past the end of ff_ac3_band_start_tab. [02:46] <CIA-40> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind [02:46] <CIA-40> ffmpeg: Signed-off-by: Alex Converse <alex.converse@gmail.com> [02:46] <CIA-40> ffmpeg: 03Janne Grunau 07master * rcb0b284381 10ffmpeg/libavcodec/zmbv.c: zmbv: check av_realloc() return values and avoid memleaks on ENOMEM [02:46] <CIA-40> ffmpeg: 03Paul B Mahol 07master * rd4eeadcbbf 10ffmpeg/libavcodec/truespeech.c: [02:46] <CIA-40> ffmpeg: truespeech: align buffer [02:46] <CIA-40> ffmpeg: DSPContext.bswap_buf() requires aligned output [03:07] <durandal_1707> rgb24 is failing for pixfmts_copy [03:09] <durandal_1707> michaelni: what that test actually do? [03:35] <michaelni> copy should do nothing, just pass the data through [03:35] <durandal_1707> why it have changed then [03:42] <michaelni> where did it change ? [03:43] <durandal_1707> http://fate.ffmpeg.org/report.cgi?time=20120202011422&slot=powerpc-linux-gnu-gcc-4.4.5 [03:44] <michaelni> the ppc box overheats sometimes AFAIK [03:45] <michaelni> ill wager a bet it will be green on the next run [03:45] <durandal_1707> we will see :) [05:39] <CIA-40> ffmpeg: 03Paul B Mahol 07master * rb8b77abe92 10ffmpeg/libavcodec/allcodecs.c: [05:39] <CIA-40> ffmpeg: cosmetics: realign vertically [05:39] <CIA-40> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [05:39] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [05:39] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r6462d28dcc 10ffmpeg/libavcodec/apedec.c: [05:39] <CIA-40> ffmpeg: apedec: Fix alignment and fate. [05:39] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [05:40] <durandal_1707> michaelni: that ape fix is going to be pretty slow [05:42] <durandal_1707> it should use av_fast_malloc(), possible fix is on Libav ml waiting review [05:48] <michaelni> i made no attempt to make it fast, just fix the code so it _works_ until someone writes a better fix ... [14:02] <CIA-40> ffmpeg: 03Carl Eugen Hoyos 07master * rde05e41bfc 10ffmpeg/libavdevice/x11grab.c: [14:02] <CIA-40> ffmpeg: Use the correct pix_fmt for 32bit x11grab. [14:02] <CIA-40> ffmpeg: Remove adding a constant value to each pixel to make it opaque. [14:06] <ubitux> i'm going to push the new timecode api today [14:07] <ubitux> and all the patches of the patchset [14:07] <ubitux> unless someone has something to say about it [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rb18ebcbe83 10ffmpeg/tests/ (6 files in 2 dirs): timecode: add write regressions tests. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * r0eaa123b34 10ffmpeg/ (5 files in 2 dirs): lavu: add public timecode API. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * r11e5d3b9cf 10ffmpeg/libavformat/dv.c: dv: use new public timecode API. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * r77971609de 10ffmpeg/libavformat/ (isom.h mov.c): mov: honor tmcd flags while extracting timecode meta. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rdc386a5e3c 10ffmpeg/ffprobe.c: ffprobe: use av_mpegtc_to_timecode_string(). [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rf65600d519 10ffmpeg/ (doc/filters.texi libavfilter/vf_drawtext.c): drawtext: use new public timecode API. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rd8804905eb 10ffmpeg/libavcodec/ (mpeg12enc.c mpegvideo.h): mpeg12enc: use new public timecode API. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * re2407556f1 10ffmpeg/libavformat/gxfenc.c: gxfenc: use new public timecode API. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rc79eddaff1 10ffmpeg/ (6 files in 3 dirs): [14:41] <CIA-40> ffmpeg: lavfi/aconvert: use libswresample. [14:41] <CIA-40> ffmpeg: This commit also drops the planar parameter; you now need to use the 'p' [14:41] <CIA-40> ffmpeg: suffix in order to request a planar sample format. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * re96be8409f 10ffmpeg/ (configure libavfilter/Makefile libavfilter/af_aresample.c): lavfi/aresample: use libswresample. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * r9f0b0db0d3 10ffmpeg/libavfilter/af_aformat.c: [14:41] <CIA-40> ffmpeg: lavfi/aformat: use do..while(0) form for macro. [14:41] <CIA-40> ffmpeg: This avoids some empty statements. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rbf6e83a8e8 10ffmpeg/libavformat/mxfenc.c: mxfenc: use new public timecode API. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rd055c3286c 10ffmpeg/doc/ (ffmpeg.texi filters.texi): doc: document amerge filter as an alternative for the -map_channel limitation. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * r85c66793d7 10ffmpeg/libavfilter/af_pan.c: [14:41] <CIA-40> ffmpeg: lavfi/pan: copy ref props after filtering samples. [14:41] <CIA-40> ffmpeg: At least PTS needs to be copied to avoid breaking options such as -t in [14:41] <CIA-40> ffmpeg: ffmpeg. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rd50a4c4a5b 10ffmpeg/libavfilter/af_amerge.c: [14:41] <CIA-40> ffmpeg: lavfi/amerge: copy ref props after filtering samples. [14:41] <CIA-40> ffmpeg: This fixes various issues with ffmpeg -ss and -t. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rbd10f01aa8 10ffmpeg/libavformat/mov.c: mov: use new public timecode API. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * red67dac093 10ffmpeg/libavcodec/mpeg12.c: mpeg12: use av_mpegtc_to_timecode_string(). [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * rb90d79ec1f 10ffmpeg/libavcodec/ (timecode.c timecode.h): timecode: drop lavc timecode on next bump. [14:41] <CIA-40> ffmpeg: 03Clément BSsch 07master * r6f55156234 10ffmpeg/libavformat/dvenc.c: dvenc: use new public timecode API. [18:46] <CIA-40> ffmpeg: 03Carl Eugen Hoyos 07master * raf0f8c09cc 10ffmpeg/libavformat/isom.c: [18:46] <CIA-40> ffmpeg: Cosmentics: Fix AVUI comment. [18:46] <CIA-40> ffmpeg: The codec contains no alpha information but deinterleaved interlaced video. [18:46] <CIA-40> ffmpeg: Found by Maksym Veremeyenko. [19:30] <durandal_1707> is ffv1-img supposed to be extension for image encoded with FFV1 ? [19:33] <Compn> where do you see ffv1-img ? [19:34] <durandal_1707> in img2 muxer [19:34] <durandal_1707> actually in img_tags [19:35] <durandal_1707> it could be only raw format, because ffv1 does not store dimensions [19:38] <Compn> could be, good question tho, i dunno [19:38] <Compn> michaelni knows [19:39] <durandal_1707> but nothing generate such files (automaticaly with mentioned tag), but support for decoding does exist [19:42] <durandal_1707> look at 03cfe134ca7b07edfdcfa269ac12da52aa363cc3 [19:42] <durandal_1707> with this its possible to encode&decode any video codec to individual (1 file per frame) files [20:06] <Daemon404> i see that OS/2 guy is still sending in fixes for long-dead things [20:06] <Daemon404> like aout [20:11] <durandal_1707> aout is not dead [20:11] <funman> KO is crazy [20:12] <Daemon404> durandal_1707, what uses it? [20:13] <durandal_1707> Daemon404: my sick relative [20:13] <Daemon404> durandal_1707, what? [20:13] <Daemon404> i was asking why it isn't dead [20:13] <Daemon404> i cant think of anythign even remotely prominent that uses it [20:13] <durandal_1707> because some apparently still use it [20:13] <Daemon404> for all intents and purposes it is [20:14] <Daemon404> except for that oen dude who is sitll using os/2 [20:14] <Daemon404> (aka kO) [20:14] <durandal_1707> Daemon404: ask that guy, he will have best answer [20:14] <Daemon404> i dont expect someone who thinks os/2 is still alive to be grounded i nreality [20:14] <Daemon404> but i see you wish to argue semantics [20:14] <Daemon404> for all practical use... it is dead. [20:15] <Daemon404> a few crazies using it does nto make it alive. [20:15] <durandal_1707> aout is dead, long live aout [20:15] <Daemon404> i cant tell if youre trolling or just being really anal about teh use of teh word [20:16] <durandal_1707> stop beating dead horse [20:16] <Daemon404> i have no idea what youre on about now [20:16] <durandal_1707> i mean, just ignore it [20:16] <Daemon404> you havent communicated a single thign clearly. [20:18] <durandal_1707> there are people who still use old aout legacy code [20:18] <durandal_1707> for whatever reason [20:18] <Daemon404> [14:14] <+Daemon404> for all practical use... it is dead. [20:18] <Daemon404> im saying in general it is dead except for a few crazies. [20:19] <Daemon404> im sure there's still someone, somewhere using a VAX system too. [20:37] <cbsrobot> somebody in possesion of 12 bit yuv files ? [20:38] <Daemon404> cbsrobot, no but they're trivial to make... [20:39] <Daemon404> tho if ffmpeg doesnt hav a 12-bit yuv colorspace then maybe a tad more annoying [20:39] <Daemon404> (given an e.g. 16-bit rgb input) [20:41] <cbsrobot> I was wondering if it is a useful addition, but I didn't find any codec that uses it ... [20:41] <cbsrobot> maybe prores4444 ? [20:44] <CIA-40> ffmpeg: 03Clément BSsch 07master * r8c48652ff0 10ffmpeg/libavcodec/dct-test.c: dct-test: remove odivx_idct_c dead prototype. [20:46] <cbsrobot> it seems the arri alexa uses 12 bit prores 4444 - anybody a sample ? [20:46] <cbsrobot> hmm - but is it rgb or yuv ... ? [20:46] <Daemon404> prores is always yuv afaik [20:53] <cbsrobot> http://documentation.apple.com/en/finalcutpro/professionalformatsandworkflow... [20:53] <cbsrobot> yuv and rgb - it seems [20:54] <nevcairiel> maybe that means input or something? All encodings i know of are yuv [20:55] <cbsrobot> http://documentation.apple.com/en/finalcutpro/professionalformatsandworkflow... [20:55] <cbsrobot> The R, G, and B channels are lightly compressed, with an emphasis on being perceptually indistinguishable from the original material. [20:55] <cbsrobot> lol [20:55] <nevcairiel> hm maybe they just encode the color planes as if its yuv, who knows [20:56] <Daemon404> well prores is kidna just a modified mjpeg... [20:56] <Daemon404> so... [20:58] <bcoudurier> I'm not sure prores supports rgb [20:58] <bcoudurier> it probably gets converted to yuv444 [21:01] <cbsrobot> bcoudurier: does it support 12 bit ? [21:01] <nevcairiel> I thought it always was 10bit [21:01] <cbsrobot> some say the alexa outputs 12bit (soon) ... [21:04] <nevcairiel> According to some white paper i found, the 4:4:4:4 mode can work with 12-bit image data and 16-bit alpha [21:08] <nevcairiel> Although its not really all that clear if it really encodes the 12-bit or just "supports image sources up to 12 bits" as the paper claims <.< [21:41] <gnafu> "< cbsrobot> The R, G, and B channels are lightly compressed, with an emphasis on being perceptually indistinguishable from the original material." <-- Sounds like a menu item in a fancy French restaurant. [21:57] <CIA-40> ffmpeg: 03Paul B Mahol 07master * r9b9bf5ab73 10ffmpeg/libavcodec/ffv1.c: [21:57] <CIA-40> ffmpeg: ffv1: cosmetics: indentation [21:57] <CIA-40> ffmpeg: Signed-off-by: Paul B Mahol <onemda@gmail.com> [21:57] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [21:57] <CIA-40> ffmpeg: 03KO Myung-Hun 07master * rc853124fb0 10ffmpeg/libavcodec/x86/pngdsp.asm: [21:57] <CIA-40> ffmpeg: Use SECTION_TEXT instead of section .text for the compatibility [21:57] <CIA-40> ffmpeg: aout does not support 'align='. [21:57] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [22:57] <j-b> Daemon404: pingie [22:57] <Daemon404> hi [22:58] <j-b> Daemon404: update on the libpostproc repo? [22:59] <Daemon404> git was taking so long to run filter-branch i fell asleep last night [22:59] <Daemon404> and ive been at uni all day today... [23:00] <Daemon404> eta tomorrow for all intents and purposes [23:01] <j-b> Daemon404: I was just wondering, no pressure. [23:01] <j-b> and I can give you write access on git.v.o if you ever care. [23:03] <Daemon404> nah i can use github [00:00] --- Fri Feb 3 2012