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

[burek]

[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=29f1f61a4a74c08070eb14de90d8cb25b993faea
[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 at 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.html
[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 at 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 at gmail.com>
[01:23] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at 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 at 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 at 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 at 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 at 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 at gmail.com>
[05:39] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at 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/professionalformatsandworkflows/index.html#chapter=10%26section=4%26hash=apple_ref:doc:uid:TempBookID-ReplacedWhenAssociatingWithMessierRevision-XDC1-SW19
[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/professionalformatsandworkflows/index.html#chapter=10%26section=2%26tasks=true
[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 at gmail.com>
[21:57] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at 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 at 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