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

[burek]

[00:04] <Daemon404> ubitux or saste, i this valid: select='(gte(pts\,0)+lte(pts\,17000))*(gte(pts\,17100)+lte(pts\,18400))*(gte(pts\,19700)+lte(pts\,21400))*(gte(pts\,24500)+lte(pts\,37000))*(gte(pts\,43500)+lte(pts\,45500))*(gte(pts\,52700)+lte(pts\,8824600))'
[00:05] <Daemon404> i.e. im using it to cut out bits of it
[00:05] <saste> Daemon404, ugly
[00:05] <cone-939> ffmpeg.git 03Hendrik Leppkes 07release/1.0:9b481654e151: h264: fix parsing of old lossless profile (profile_idc == 144)
[00:05] <Daemon404> yes
[00:06] <Daemon404> got a better way?
[00:06] <Daemon404> woops i mixed up my * and +
[00:07] <saste> Daemon404, what's the equivalent in VS?
[00:07] <Daemon404> easier to shwo i navs
[00:07] <Daemon404> e.g.
[00:07] <Daemon404> trim(0,100)+trim(200,300)
[00:08] <Daemon404> includes frames 0-100,200-300
[00:08] <Daemon404> 101-199 = gone
[00:08] <Daemon404> (im obviosuly using pts tho)
[00:13] <Daemon404> heh
[00:13] <Daemon404>  -vf select='(gte(pts\,0)*lte(pts\,17000))+(gte(pts\,17100)*lte(pts\,18400))+(gte(pts\,19700)*lte(pts\,21400))+(gte(pts\,24500)*lte(pts\,37000))+(gte(pts\,43500)*lte(pts\,45500))+(gte(pts\,52700)*lte(pts\,8824600))'
[00:13] <Daemon404> literally did nothing
[00:21] <Daemon404> grrrrrrrrrr
[00:22] <Daemon404> can it not group or something?
[00:23] <Daemon404> are extra paren ignore?
[00:29] Action: Daemon404 prods saste 
[00:30] <saste> Daemon404, ?
[00:30] <Daemon404> [19:13] <@Daemon404>  -vf
[00:30] <Daemon404> select='(gte(pts\,0)*lte(pts\,17000))+(gte(pts\,17100)*lte(pts\,18400))+(gte(pts\,19700)*lte(pts\,21400))+(gte(pts\,24500)*lte(pts\,37000))+(gte(pts\,43500)*lte(pts\,45500))+(gte(pts\,52700)*lte(pts\,8824600))'
[00:30] <saste> sox memory killed my desktop
[00:30] <Daemon404> [19:13] <@Daemon404> literally did nothing
[00:30] <Daemon404> [19:15]  -!- saste [~saste___ at dynamic-adsl-78-15-199-166.clienti.tiscali.it] has quit [Read error: No route to host]
[00:30] <Daemon404> [19:18]  -!- smarter__ is now known as smarter
[00:30] <Daemon404> [19:21] <@Daemon404> grrrrrrrrrr
[00:30] <Daemon404> [19:21]  -!- jrmuizel [~jrmuizel at 66.207.208.98] has quit [Remote host closed the connection]
[00:30] <Daemon404> [19:22] <@Daemon404> can it not group or something?
[00:30] <Daemon404> [19:23] <@Daemon404> are extra paren ignore?
[00:31] <Daemon404> theres gotta be some error im making
[00:34] <saste> Daemon404, -loglevel debug
[00:34] <saste> good debugging
[00:34] <Daemon404> i never know what respects that
[00:37] <llogan> damn i'm slow at this GSoC stuff. even a sentence takes me ages.
[00:38] <saste> llogan, no need for perfection
[00:38] <saste> we have still 10 days to improve it
[00:38] <Daemon404> saste, it seems that it is indeed dropping frames
[00:38] <Daemon404> er
[00:38] <Daemon404> or well
[00:38] <llogan> we have still 10 days to procrastinate
[00:39] <Daemon404> select is 0 for some
[00:39] <Daemon404> but then
[00:39] <Daemon404> why is teh in and out teh same # of frames
[00:39] <Daemon404> if some frames are 0
[00:39] <Daemon404> :|
[00:39] <Daemon404> that makes no sense
[00:40] <llogan> saste: i dealt with the new app quesiton order/structure
[00:42] <Daemon404> derekb at verona:~/cj$ grep "select:0" *log | wc -l
[00:42] <Daemon404> 177
[00:42] <Daemon404> derekb at verona:~/cj$ ffprobe -show_streams mele.mov 2>&1 | grep nb_frames | head -1
[00:42] <Daemon404> nb_frames=88246
[00:42] <Daemon404> derekb at verona:~/cj$ ffprobe -show_streams a.avi 2>&1 | grep nb_frames | head -1
[00:42] <Daemon404> nb_frames=88246
[00:42] <Daemon404> ^ makes no sense
[00:42] <Daemon404> mele.mov = in, a.avi = out
[00:42] <Daemon404> *log = debug log
[00:45] <saste> Daemon404, are you dupping frames with ffmpeg?
[00:45] <Daemon404> ffmpeg -loglevel debug -copyts -i mele.mov -an -vf select='\(gte(pts\,0)*lte(pts\,17000)\)+\(gte(pts\,17100)*lte(pts\,18400)\)+\(gte(pts\,19700)*lte(pts\,21400)\)+\(gte(pts\,24500)*lte(pts\,37000)\)+\(gte(pts\,43500)*lte(pts\,45500)\)+\(gte(pts\,52700)*lte(pts\,8824600)\)',scale=320:240 a.avi
[00:45] <Daemon404> my exact cmd line
[00:46] <saste> a.avi
[00:46] <Daemon404> ?
[00:46] <saste> AVI requires frame duplication in case of missing timestamps
[00:46] <saste> it expects a continuous stream
[00:47] <saste> try with MOV or a saner container
[00:47] <Daemon404> how would i trim out those sections
[00:47] <Daemon404> and keep the framerate
[00:47] <Daemon404> i.e. fix the pts post trim
[00:47] <Daemon404> so its simpyl shorter
[00:48] <saste> try another container
[00:48] <Daemon404> thats not a real answer
[00:48] <Daemon404> for something this is EASILY  possible in in avs or vs
[00:48] <Daemon404> while keeping it vfw
[00:48] <Daemon404> vfr*
[00:48] <Daemon404> "how do i trim out chunks and make it shorter" will inherently keep something CFR
[00:48] <Daemon404> and is a super-common use case...
[00:53] <Daemon404> maybe setpts...
[00:58] <Daemon404> actually thats not so cool :|
[01:01] Action: Daemon404 shrugs
[01:01] <Daemon404> i never imagined trimming would be so hard
[01:02] <saste> Daemon404, why don't you just use vs
[01:02] <saste> lavfi is not supposed to be used
[01:02] <Daemon404> im not set to change to vs yet
[01:02] <Daemon404> Risk (TM) etc
[01:06] <Daemon404> why on earth is setpts='N*TB' not working :|
[01:07] <Daemon404> derp, its N/TB
[01:08] Action: Daemon404 was thinking of timescale
[01:09] <Daemon404> e no...
[01:09] <Compn> whaaaaaaaa
[01:09] <cone-939> ffmpeg.git 03Carl Eugen Hoyos 07master:ac9b056ddbef: Do not fail in get_buffer_internal() if pix_fmt planes == 0.
[01:09] <Compn> Daemon404 : any chance you'll tell elenril that you want TIVTC filter ported from avisynth ?
[01:09] <Compn> or is someone working on that here already
[01:09] <Compn> hmm
[01:10] <Daemon404> ubitux has it done
[01:10] <Daemon404> and ported for vs youtube
[01:10] <Daemon404> vs port did all the heavy lifting
[01:10] <Compn> oh wow
[01:10] <saste> Compn, still waiting for --enable-monolithic-tools-doc feedback
[01:10] <Compn> saste : thank you for working on that :)
[01:10] <ubitux> yeah i'm somehow done for the fieldmatching, but i still need to figure out some stuff
[01:11] <Compn> you got a sample of its output? i can take a look (cant build right now)
[01:11] <ubitux> also doc, test, etc
[01:11] <ubitux> and... decimate.
[01:11] <Compn> saste: you got a sample of monolithic output? i can take a look (cant build right now)
[01:11] <saste> Compn, no
[01:11] <saste> but really you don't need a great imagination for that
[01:12] <saste> ubitux, Cannot select sample rate for the link between filters Parsed_anullsrc_0 and Parsed_sox_1.
[01:12] <saste> ^^ any ideas?
[01:12] <Compn> saste : iirc you are docs devel, feel free to merge it :P
[01:13] <Compn> waiting around for reviews ... so boring 
[01:13] <ubitux> saste: like that without more information i can't tell
[01:13] <Compn> i guess i cant fix docs generation on the website tho
[01:13] <Compn> so have to wait for michaelni
[01:13] <saste> ubitux: ffplay -f lavfi "anullsrc=r=22100,sox=synth 10 sine 1"
[01:14] <saste> sox should accept all samplerates, so don't know what's wrong there
[01:16] <saste> ffplay -f lavfi "anullsrc=r=22100" 
[01:16] <saste> oh...
[01:16] <Compn> libox .... :)
[01:17] <ubitux> saste: no idea...
[01:17] <saste> ubitux, it's a problem with anullsrc
[01:18] <saste> it's broken since age
[01:18] <saste> we should probably test add a fate test for it...
[01:20] <ubitux> saste: http://lucy.pkh.me/ffmpeg-coverage/ffmpeg/libavfilter/index.html :)
[01:21] <ubitux> Daemon404: so you were able to get something with the select and setpts?
[01:24] <Daemon404> only for CFR content
[01:24] <Daemon404> setpts doesnt have access to enough info post-frame-drop
[01:24] <Daemon404> to handle vfr
[01:24] <Daemon404> in this case
[01:24] <ubitux> why don't you use n?
[01:25] <Daemon404> that doesnt properly handle timebases, and VFR content.
[01:28] <saste> Source filters and filters with more than one input must set config_props() callbacks on all outputs
[01:28] <saste> ubitux, do you remember why?
[01:32] <ubitux> nope :p
[01:41] <ubitux> Daemon404: just added locally between() to eval
[01:41] <ubitux> i know it doesn't really help your current problem
[01:41] <ubitux> but it should at least make your expression simpler
[01:42] <ubitux> so the "trim(100,200)" would be "not(between(n,100,200))" or something like that
[01:46] <Daemon404> heh
[01:46] <Daemon404> certainly less ugly
[01:49] <saste> anullsrc filter_frame() is weird
[01:49] <saste> why the frame is copied and then freed?
[01:54] <ubitux> saste: that looks pointless indeed
[01:54] <ubitux> also actually
[01:54] <saste> ubitux, what happens if one of the operands is NAN
[01:54] <ubitux> isn't this leaking?
[01:54] <saste> ubitux, what?
[01:54] <ubitux> samplesref=ff_get_audio_buffer()
[01:55] <ubitux> you don't need to clone it
[01:55] <ubitux> oh and wait no, no leak
[01:55] <ubitux> but the clone & free could be dropped right
[01:55] <ubitux> saste: between() is supposed to fail if ` 3 params
[01:56] <ubitux> that was just a test
[01:56] <saste> ubitux, between(1, 0/0, NaN)
[01:56] <ubitux> oh that
[01:56] <ubitux> well... undefined behaviour
[01:56] <ubitux> just like the other functions
[01:57] <saste> -> sleep
[01:57] <ubitux> :)
[01:57] <saste> tomorrow i'll send an updated version of sox
[01:57] <ubitux> 'night
[01:58] <ubitux> Daemon404: about the cfr/vfr thing, it reminds me issues when dealing with images
[01:58] <ubitux> where i needed to use -vsync
[02:00] <ubitux> https://ffmpeg.org/trac/ffmpeg/ticket/1644
[02:00] <ubitux> this one ^
[02:01] <highgod> Hi, I read the latest ffmpeg git code and find that there are so many changes than the pervious version.So should I re-merge the dxva2 code to this version and submit it? Thanks
[02:01] <ubitux> highgod: i guess so
[02:01] <highgod> also I want to ask a question, the get-buffer and release buffer seems not use any more
[02:02] <ubitux> yes, this changed completely recently
[02:02] <highgod> so is there any reference documents or explanations? my patch use the get_buffer and release_buffer
[02:02] <highgod> it crush now,hehe
[02:02] <highgod> Thanks
[02:04] <ubitux> you can look at 759001c5 for some kind of reference
[02:12] <highgod> sorry,hehe,you mean git version?
[02:12] <highgod> @buitux
[02:12] <ubitux> git show 759001c5 in the git repository yes
[02:21] <highgod> OK,thanks
[02:57] <highgod> Hi, should I use get_buffer2 to instead get_buffer? how can I use release buffer?
[03:16] <michaelni> highgod, with the new buffers theres a reference count and a user specified destruct function is called when all references are unreferenced
[03:22] <michaelni> highgod, a simple decoder would generally call ff_get_buffer() and release_buffer() would just get called once all references are unreferenced
[03:26] <highgod> michaelni:I speecified a function to release dxva2 surface, and set the value to release_buffer,but it did not be called.So where should I place the function?
[03:30] <michaelni> highgod, do you have a link to the patch ?
[03:30] <michaelni> so i can take a look 
[03:34] <highgod> michaelni:should I send the patch to you?
[03:35] <highgod> for h264, it has worked,but for vc1 wmv3 mpeg2,doesn't
[03:42] <michaelni> release_buffer() should get called when all references are unreferenced, if it never gets called then theers something wrong
[04:14] <cone-939> ffmpeg.git 03Michael Niedermayer 07release/0.11:faeb2b3e6989: rmdec: flush audio packet on seeking
[04:14] <cone-939> ffmpeg.git 03Michael Niedermayer 07release/0.11:2f76f544436e: MAINTAINERS: update for 1.2
[04:14] <cone-939> ffmpeg.git 03Michael Niedermayer 07release/0.11:3e63dea5f2eb: MAINTAINERS: mention that people are welcome to pick up and maintain older releases
[04:14] <cone-939> ffmpeg.git 03Michael Niedermayer 07release/0.11:a3ff859a4664: update the current year
[04:14] <cone-939> ffmpeg.git 03Michael Niedermayer 07release/0.11:aba32d84630c: update for 0.11.3
[04:36] <cone-939> ffmpeg.git 03Carl Eugen Hoyos 07fatal: ambiguous argument 'refs/tags/n0.11.3': unknown revision or path not in the working tree.
[04:36] <cone-939> Use '--' to separate paths from revisions
[04:36] <cone-939> refs/tags/n0.11.3:HEAD: Do not fail in get_buffer_internal() if pix_fmt planes == 0.
[04:57] <BBB> michaelni: can you move the webp functions in their own decode_webp_frame function, which calls vp8_decode_frame()?
[04:57] <BBB> michaelni: such as to not clobber plain vp8 decoding with this functionality
[04:58] <BBB> michaelni: ideally this webp_decode_frame function could then also go in its own file, e.g. webpdec.c, and be compiled out in chrome for smaller binaries
[04:58] <BBB> michaelni: currently not a big thing, but once alpha support goes in, it'll make quite a difference
[04:58] <BBB> not to mention rgb support etc.
[05:00] Action: Compn complains about chrome is too bloated already
[05:00] Action: Compn afk
[05:20] <Daemon404> you use win2k
[05:20] <Daemon404> none of your opinions are valid
[05:21] <relaxed> and opera
[06:32] <highgod> ff_MPV_frame_start crushed when I use dxva2 to decode vc1
[06:54] <highgod> ff_mpeg_ref_picture crushed
[09:13] <nevcairiel> highgod: i think your tree is out of date, update to the latest git master, i fixed the problem in mpegvideo
[09:47] <ubitux> mmh there is something weird in blend filter
[09:49] <ubitux> http://b.pkh.me/0001-lavfi-blend-always-peek-the-first-frame-of-each-queu.patch
[09:49] <ubitux> doesn't this make more sense?
[09:53] <ubitux> i guess i'll submit to the ml
[09:56] <ubitux> btw, it's very funny how the request_frame/filter_frame calls can be completely out of sync
[09:59] <ubitux> "split[a][b]; [a]hue[h]; [h][b]blend" vs "split[a][b]; [a]hue[h]; [b][h]blend"; in the first case, the first call to filter_frame() is the top one (request_frame was called once and requested the top one)
[10:00] <ubitux> but in the second case, the first call to filter_frame is the bottom one
[10:00] <ubitux> even though request_frame was called once and requested the top one
[10:00] <ubitux> this is black magic to me
[10:07] <saste> ubitux, blend lacks any synchronization mechanism
[10:07] <saste> it just assumed top and bottom have the same timestamps, which is not the case very often
[10:08] <ubitux> yes it can only perform a 1:1
[10:08] <ubitux> but the code is currently wrong
[10:08] <ubitux> it waits for 1 frame in top
[10:08] <ubitux> and 2 frames in bottom
[10:11] <highgod> +nevcairiel:sorry, I didn't see your message. I will update and re-merge, thanks
[10:14] <cone-294> ffmpeg.git 03Clément BSsch 07master:77f60f001113: lavu/eval: add between() function.
[10:24] <saste> highgod, i'm reviewing your lavu patch
[10:24] <saste> it starts to look good
[10:25] <saste> it's taking time because i'm quite busy, and sometimes i lack the force to review a 1klines patch at the end of the day
[10:25] <JamJams> Ermmm is this the right place to ask for advice about implementing a switch via a patch?
[10:26] <ubitux> a switch via a patch?
[10:26] <saste> a patch via a switch?
[10:26] <JamJams> A new command line option*
[10:26] <saste> a swatch via a pitch?
[10:27] <JamJams> *Shrugs*
[10:27] <ubitux> sure, here is the place
[10:29] <JamJams> Ah, well... I'm in a bit of an odd situation I have to encode a file as it's still being written there for I can't define a stop frame before hand as it wont exist at that stage, so I was wondering would it be possible to have ffmpeg check a text-file as it's encoding frames and if the content of that text-file becomes a frame number it will stop encoding then?
[10:30] <JamJams> I know it could be done, but I'm just wondering if it's something that's easy to implment... With the current scope of things.
[10:30] <av500> maybe send a signal?
[10:31] <JamJams> Signal to kill the process? That wouldn't be frame accurate though.
[10:32] <ubitux> i wonder how you will be able to be frame accurate anyway
[10:32] <ubitux> since you may have a lot of delay all over your system if you're watching a file
[10:33] <av500> not a signal to kill
[10:33] <av500> one of the non killing ones
[10:33] <JamJams> Mmm
[10:34] <av500> also
[10:34] <JamJams> It's a unique problem...
[10:34] <av500> are you watching the inout file?
[10:34] <av500> or creating it?
[10:34] <av500> if you need to stop at frame N, then stop wirting the input file
[10:35] <av500> then send signal
[10:35] <JamJams> The input file is being written by something else out of my control
[10:35] <av500> so how do you know the frame number?
[10:35] <av500> to stop at?
[10:36] <JamJams> The input file gets opened in an application I wrote that follows it displays the frames and the frame number.
[10:36] <av500> well, so pass the data through to ffmpeg
[10:36] <av500> then you can count frames and stop
[10:37] <av500> since you read the whole file anyway
[10:37] <JamJams> But I'm encoding as the file is being written
[10:37] <av500> so?
[10:38] <JamJams> How do you tell ffmpeg to stop encoding at frame number x after you've already started it, is my issue.
[10:38] <av500> you dont
[10:38] <av500> you just stop sending data to it
[10:38] <av500> and send a stop signal
[10:38] <av500> file -> your app -> ffmpeg
[10:38] <av500> your app decided to stop eventually
[10:38] <JamJams> Hmmm
[10:38] <av500> and stops ffmpeg
[10:39] <av500> instead of: file -> your app -> magic && file -> ffmpeg <- magic
[10:39] <av500> you could also write a filter
[10:39] <av500> that passes frames via your app
[10:39] <av500> so your app can count them
[10:40] <av500> and eventually block/stop
[10:40] <JamJams> Yeah
[10:40] <av500> sound better than magic text file to me
[10:40] <av500> +s
[10:40] <highgod> @saste:thanks, I learnt a lot during fix the patch,hehe
[10:41] <JamJams> Harder to implement though
[10:43] <JamJams> Perhaps if I read the input with ffplay or something
[10:45] <av500> but you are reading the file already
[10:45] <av500> so just write out what you are readinfg
[10:48] <JamJams> I'm using a libary to render and read the file, unfortunately.
[10:58] <JamJams> If I was to go about it the text-file way, where would be the best place for me to slip that in would you say?
[12:59] <cone-294> ffmpeg.git 03Diego Biurrun 07master:72ad96c8544c: doc/developer: Clarify symbol naming prefixes section.
[12:59] <cone-294> ffmpeg.git 03Diego Biurrun 07master:2e2ec667416d: configure: Enable hwaccels without external dependencies by default.
[12:59] <cone-294> ffmpeg.git 03Michael Niedermayer 07master:abbc34c372db: Merge remote-tracking branch 'qatar/master'
[13:06] <cone-294> ffmpeg.git 03Carl Eugen Hoyos 07master:d98a5318fdbc: Fix compilation with --disable-mmx.
[13:25] <cone-294> ffmpeg.git 03Diego Biurrun 07release/1.2:90f1aa38b666: configure: Enable hwaccels without external dependencies by default.
[13:27] <xander`> Hi all!
[13:30] <xander`> Are there plans in ffmpeg to support VdpVideoSurfaceGetBitsYCbCr to provide full filtering with GPU decode?
[13:33] <xander`> Google can find only old posts related to this with no new info
[13:35] <xander`> GetBits used to be a CPU performance hog, but I don't know if that's still the case.
[13:41] <Compn> hmmm
[13:41] <cehoyos> xander`: Do you know that it was slow? If yes, why should peformance be improved now?
[13:41] <Compn> i dont believe anyone is working on filtering with vdpau, but cehoyos knows vdpau :)
[13:41] <Compn> uau also does i think
[13:41] <xander`> Compn: That's who I was trying to reach!
[13:42] <xander`> cehoyos: http://www.nvnews.net/vbulletin/showthread.php?t=129848
[13:44] <xander`> Old posts from 2009, but Steven Warren says it'll `limit performance', while the OP found out `I used VdpVideoSurfaceGetBitsYCbCr function to get yv12 image from the video surface, but the cpu usage was quit high, even higher than ffmpeg software decoder.'
[13:44] <cehoyos> xander`: To the extend that this was ever true, I would be extremely surprised if this is different now.
[13:45] <xander`> That's what I was wondering. NV's 310 series drivers claim better vdpau performance,
[13:45] <cehoyos> I suggest you test yourself (there was a tool called qvdpautest or similar)
[13:46] <iive> most likely the video decoding is organized in some other format like macrobock hm12 or something. The conversion to yv12 is done by pure C function.
[13:46] <xander`> I tested my GTS 450 with 295.20 drivers on Ubuntu 11.10 with qvdpautest and GetBits gets a solid 1208.98 M/s
[13:46] <cehoyos> And with a newer driver?
[13:47] <xander`> 304 series does not work on Ubuntu 11.10, and 310 isn't available, but that's beside the point.
[13:47] <cone-294> ffmpeg.git 03Carl Eugen Hoyos 07master:e0e8c20559d1: Fix compilation with --disable-everything --enable-parser=h264.
[13:47] <Compn> xander` : am curious, what filters you want to use with vdpau?
[13:47] <xander`> I think 1208
[13:48] <xander`> ... M/s is quite fast for any video
[13:48] <Compn> because there are special vdpau filters i think, deblock or deint ...
[13:49] <xander`> Compn: The interface to vdpau filters is clumsy and not exposed in MPlayer.
[13:49] <xander`> Compn: They have to be configured at invocation time
[13:51] <xander`> Compn: Also, use of generic filters enables film grain (for HD), post-processing (for old CIF/qCIF MPEG1 vids), and a lot of stuff only currently available in software decoding.
[13:51] <Compn> i admit to not having used them :)
[13:51] <Compn> ah i forgot people use vdpau for playing mpeg2 and xvid
[13:51] <Compn> does it work for mpeg1?
[13:52] <xander`> Compn: Watching old low-res videos without postproc is painful on big screens.
[13:52] <Compn> why use vdpau for lowres vids ?
[13:52] <xander`> Compn: Yes it works for MPEG1
[13:52] <xander`> Compn: There is no way in mplayer to switch decoders based on resolution of videos.
[13:52] <Compn> anyways, i just like asking questions. you can go back to working on vdpau filtering support now :)
[13:53] <xander`> Compn: If, eg in SMplayer I enable VDPAU, it uses it for ALL videos.
[13:54] <xander`> I currently use different MPlayer profiles named like vdpau-hw-prog, vdpau-sw, etc., but this is not convenient for a front-end at all
[13:54] <Compn> do you have hd res mpeg4asp files ?
[13:54] <xander`> cehoyos: Should 1208 M/s be a bottleneck?
[13:54] <Compn> yeah, the only thing i can think of is a script that runs and checks resolution before passing options to mplayer ...
[13:55] <xander`> Compn: I have exactly such a script (called tvmplayer.sh) running for my TV-OUT.
[13:55] <Compn> :)
[13:55] <Compn> mr smarty
[13:56] <xander`> Compn: Very bad solution. Doesn't work properly for ISO dumps (DVD/BD) at all.
[13:58] <xander`> So I'm developing a very simple and inefficient VDPAU hw decoder that will take H.264 bitstream, decode it with VDPAU, GetBits back the results, and possibly write them in yuv4mpeg format for further piping.
[13:58] <xander`> I thought it better to check if ffmpeg didn't have something like this planned already...
[14:00] <xander`> This will give a good estimate to the speed this can be done at.
[14:00] <saste> Compn, ping on docu patches, also maybe you have ideas about how to integrate it with the webserver
[14:00] <saste> no hurry i'll be back tonight
[14:01] <xander`> The vdpau docs claim VdpDecoder needs `all NALs with nal_unit_type of 1 or 5'.
[14:02] <xander`> Since I'm not using ffmpeg at all for this (too complex for me to wrap my head around), I have to implement a bitstream parser. :-(
[14:03] <nevcairiel> the problem is that you then also need to implement re-ordering and reference management, which in h264 is really qiuite complex, so use avcodec already
[14:03] <xander`> VDPAU Experts: Can VdpDecoder simply be passed ALL NALU's, including tye 7, 8,etc?
[14:04] <xander`> Can VdpDecoder decode a complete AnnexB bitstream?
[14:04] <Compn> >talks about lowres mpeg1 ... >creating modified h264 decoder
[14:04] <Compn> hehe
[14:04] <cehoyos> xander`: You don't have to care about this, if you really want to work on such a filter, write me an email please (Carl Eugen Hoyos)
[14:05] <cehoyos> bye
[14:06] <Compn> xander` : i think carl means he may work on it if you give him the details in a mail.
[14:06] <xander`> Compn: Film-grain & company are used on HD/FullHD stuff. Only postproc is for lowres stuff.
[14:06] <Compn> hes not on irc that much...
[14:06] <Compn> carl is also an mplayer devel 
[14:06] <Compn> makes sense
[14:07] <Compn> i forgot blurays have been denoising films
[14:07] <xander`> Compn: The blur on recent releases if getting to ridiculous levels.
[14:07] <xander`> if->is
[14:08] <Compn> i've heard people are looking for the hdtv rips of films
[14:08] <Compn> that aired on hdnet and other hd channels. years before bluray came out 
[14:09] <nevcairiel> i've seen BDs with excessive amounts of film grain or mosquito noise, no sign of bluring =p
[14:09] <Compn> before they had a chance to color correct and do those nasty things 
[14:09] <divVerent> Blur-ay?
[14:09] <xander`> Where should I email Carl? On mplayer-devel?
[14:10] <Compn> his private mail
[14:10] <Compn> one sec
[14:10] <xander`> nevcairiel: Yup. Those also. Gaussian blur is for them. Wait... another filter (one VDPAU has, fortunately)
[14:12] <xander`> Compn: Thanks!
[14:13] <xander`> Bye all!
[14:45] <kierank> Compn: those can be found in the right places
[14:46] <Compn> yes, but i think they are somewhat rare
[15:25] <cone-294> ffmpeg.git 03Michael Niedermayer 07master:c0ff2aaa4933: img2: WebP support
[15:25] <cone-294> ffmpeg.git 03Michael Niedermayer 07master:076c1c956c55: vp8: WebP decoding support
[18:12] <cone-294> ffmpeg.git 03Michael Niedermayer 07master:ac75e0c75524: matroskadec: switch to av_assert
[18:12] <cone-294> ffmpeg.git 03Michael Niedermayer 07master:428e9dafab81: h263dec: switch to av_assert()
[18:22] <ubitux> __gb__: isn't the hwaccel task a bit too much?
[18:49] <ubitux> is it me or the -profile parsing is somehow broken?
[18:50] <ubitux> it looks like it's doing some eval to it
[18:56] <ubitux> ./ffmpeg -lavfi testsrc=d=5 -c:v prores -profile:v apch -f null -  is it me or this usage is wrong?
[19:01] <ubitux> ok it seems you need to specify the profile id
[19:01] <ubitux> i wonder if this is a bug...
[19:25] <ubitux> michaelni: isn't our prores decoder supposed to mark the decoded frame as key frames?
[19:26] <ubitux> (and set them as i-frame)
[19:27] <nevcairiel> if i had to guess, it previously did that on one frame in its context and re-used this, but it was re-written to not use context-frames anymore, and that code was not moved appropriately
[19:28] <ubitux> there is a user not being able to seek properly in the output prores files
[19:28] <ubitux> i think that might be related
[19:28] <nevcairiel> http://git.1f0.de/gitweb?p=ffmpeg.git;a=blobdiff;f=libavcodec/proresdec2.c;h=b7aef36d238b330fd1b3763c15872b08ec339062;hp=4634e704e2df020bcedb75262a9d63808a920a2b;hb=80e9e63c946660304fc65fa8141ccfdbe4d196d1;hpb=2e7bc9c2a1f138d305f111bb07d8b70e494584a8;js=1
[19:29] <nevcairiel> i was right ^
[19:29] <nevcairiel> it got lost in merging
[19:30] <nevcairiel> oh i used my repo to link it, but anyway :P
[19:38] <ubitux> would be nice to restore it i guess
[19:38] <ubitux> that looks relatively necessary
[20:46] <ubitux> Daemon404: do you see any denoising or related filter in lavfi that could help improve the ivtc accuracy?
[20:48] <Daemon404> why on EARTH would you denoise before ivtc?
[20:48] <Daemon404> thats a terrible idea
[20:48] <ubitux> to make the ivtc more accurate
[20:49] <ubitux> that seems to be the purpose of clip2
[20:49] <Daemon404> i explained what clip2 was
[20:49] <Daemon404> and it does nto make it "more accurate"
[20:49] <ubitux> yes but after a talk with Myrsloik it seems you were wrong
[20:49] <ubitux> or i misunderstood
[20:49] <Daemon404> probably latter.
[20:49] <ubitux> here is the idea: split [a][clean]; [a] sharpenorwhatever [pp]; [pp][clean] fieldmatch=order=1:ppsrc=1, yadif=deint=interlaced, decimate
[20:50] <ubitux> you use a postprocessed input for the combed metrics
[20:50] <Daemon404> you do realize denoising before ivtc will completely fuck ivtc right?
[20:50] <ubitux> then you pick from the clean/untouched source for the fields (clip2)
[20:50] <Daemon404> esp. for non-field away denoisers
[20:50] <Daemon404> aware*
[20:50] <ubitux> well denoising or whatever i don't know
[20:50] <ubitux> that is my question
[20:50] <ubitux> what kind of filter could improve ivtc accuracy
[20:50] <Daemon404> YOU DONT FILTER PRE-IVTC
[20:51] <Daemon404> the ONLY time you do that is to provide a deint clip
[20:51] <Daemon404> for clip2
[20:51] <ubitux> no, a deint clip2 wont do what you want
[20:51] <Daemon404> are you retarded
[20:51] <Daemon404> seriosu question.
[20:51] <ubitux> if you specify a deint clip2 it will pick all the frames from it
[20:52] <Daemon404> yes
[20:52] <ubitux> frames/fields
[20:52] <Daemon404> but you generate that clip from a pre-ivtc source
[20:52] <Daemon404> and you DO NOT filter pre-ivtc with a denoiser
[20:52] <Daemon404> or anything else
[20:52] <Daemon404> its goddamn common sense
[20:52] <Daemon404> (ok n exception: cross-luminane or cross-chroma artefact removal)
[20:53] <ubitux> using a deinterlaced source for clip2 will make no sense afaict
[20:53] <Daemon404> ......................
[20:53] <Daemon404> yes it does
[20:53] <Daemon404> you deint with nnedi or yadif
[20:53] <Daemon404> and you pull frames from it
[20:53] <ubitux> this should be post fm
[20:53] <ubitux> not pre-fm
[20:53] <Daemon404> maybe you should read the 9000 threads on how tfm workso n doom9
[20:54] <Daemon404> and the thousands of people using clip2
[20:54] <ubitux> and only on the combed frames the fm wasn't able to process
[20:54] <Daemon404> ... yes you swap out frames after FM obviously
[20:54] <Daemon404> but you DO provide a deint clip
[20:54] <Daemon404> to supply those frames
[20:54] <Daemon404> its not fucking rocket science
[20:55] <ubitux> there is a misunderstanding somewhere
[20:55] <Daemon404> i think lavfi has damaged your brain
[20:55] <Daemon404> example in avs:
[20:55] <Daemon404> input = soesourcefiler("herp.ts")
[20:56] <Daemon404> deint = nnedi3(..., input)
[20:56] <Daemon404> finalclip = tfm(input, clip2=deint)
[20:56] <Daemon404> it will run fm on in input
[20:56] <Daemon404> and any shitty frames
[20:56] <Daemon404> it will replac with frames from deit
[20:56] <Daemon404> before returnign a clip
[20:57] <Daemon404> typos aside.
[20:57] <ubitux> with vivtc at least, all the frame/fields will be picked from clip2 (and clean herp.ts will be used for combed metrics)
[20:57] <ubitux> are you ok with that? ^
[20:58] <Daemon404> >all the frame/fields will be picked from clip2
[20:58] <Daemon404> this is incorrect
[20:58] <ubitux> look at the code then
[20:58] <Daemon404> only frames where MI > MIC
[20:58] <ubitux> nope
[20:58] <Daemon404> if the code does that
[20:58] <Daemon404> it is wrong
[20:58] <Daemon404> ad myrsoik fucked up
[20:58] <ubitux> no it's just a misunderstanding of the purpose of clip2
[20:58] <Daemon404> When using PP > 1 this parameter may be used to specify a clip to take deinterlaced frames from instead of using one of TFM's inbuilt deinterlacing methods.
[20:58] <Daemon404> pp is only applied when MI > MIC
[20:59] <ubitux> because the deint will be post vfm, only on the frame flagged with the combed meta
[20:59] <ubitux> there is no PP in vivtc
[20:59] <ubitux> so the purpose of clip2 might not be the same as in tfm
[20:59] <ubitux> the purpose of the 2nd clip, at least in the case of vivtc
[20:59] <ubitux> is to be able to alter the combed frame matching algo
[21:00] <ubitux> basically you preproc your input so the combed frame are better detected
[21:00] <ubitux> and then it picks frames from the clip2 (the untouched sources) to reconstruct the fields/frames
[21:00] <ubitux> and then after all of this
[21:00] <Daemon404> thats somethign entirely different than tfm
[21:00] <ubitux> you deint with yadif/needi/whatever
[21:00] <ubitux> on the frames flagged as combed
[21:00] <Daemon404> [16:00] <@Daemon404> thats somethign entirely different than tfm <--
[21:00] <ubitux> yes, right
[21:01] <ubitux> so, then
[21:01] <ubitux> now that we seem to agree
[21:01] <Daemon404> and Myrsloik is bad person for changing teh behavior of a setting
[21:01] <Daemon404> with the same name
[21:01] <ubitux> do you see any filter able to increase the combed frame accuracy?
[21:01] <Daemon404> no.
[21:01] <ubitux> ok, thanks.
[21:01] <Daemon404> i cant think of when you would ever want to either
[21:01] <ubitux> dunno
[21:01] <ubitux> maybe some sharp contrast or anything
[21:02] <Daemon404> the filter absolutely hs to be field aware
[21:02] <Daemon404> otherwise its n insanely bad idea
[21:03] <ubitux> the idea is just to have a pre proc filter to enlight those fields to increase the matching
[21:03] <ubitux> imo it makes perfect sense, even if it doesn't match tfm original design
[21:03] <Daemon404> liek i said
[21:03] <Daemon404> it has to be field aware
[21:03] <Daemon404> you cant tread telecined material as full frames
[21:03] <Daemon404> that will screw ivtc hard
[21:04] <Daemon404> the other problem is
[21:04] <ubitux> yeah well you can find some filters working on line basis
[21:04] <Daemon404> processing fields separately 
[21:04] <Daemon404> could lead to worse matches
[21:04] <Daemon404> by creating more difference
[21:04] <Daemon404> very easily
[21:04] <ubitux> maybe it can be useful in some scenarios; the clip2 thing is not the default
[21:04] <ubitux> i was just wondering about how to make use of it
[21:04] <Daemon404> im gonna have to talk to myrs about name reuse
[21:04] <Daemon404> of clip2
[21:05] <Daemon404> evil etc
[21:05] <ubitux> if you could talk about that here (or a channel where i am) so i can benefit from it, that would be welcome ;)
[21:06] <Daemon404> 14:51 <@Myrsloik> I haven't tested the clip2 stuff at all
[21:06] <Daemon404> 14:52 <@Myrsloik> the rest I guess work
[21:06] <Daemon404> greppig lgs hsowed this
[21:06] <Daemon404> lulz
[21:06] <ubitux> i talked with him yesterday
[21:06] <ubitux> he did actually test it
[21:06] <ubitux> and it works in my port
[21:06] <Daemon404> with what
[21:06] <Daemon404> im not awar of ay safe filters to use
[21:07] <ubitux> well i mean it does the behaviour i'm expecting from it
[21:07] <Daemon404> yes
[21:07] <Daemon404> what might be perfectly acceptable
[21:07] <Daemon404> (maybe)
[21:07] <Daemon404> is like
[21:07] <Daemon404> clip = input.separatefields()
[21:07] <Daemon404> clip = clip.denoise()
[21:07] <Daemon404> clip = clip.weave()
[21:07] <Daemon404> and use that as clip2
[21:08] <Daemon404> or it could be a horrible idea.
[21:08] <ubitux> right
[21:08] <ubitux> i guess that's the idea then
[21:08] <Daemon404> id  think deblocking would be more useful
[21:09] <Daemon404> but separating fields will scew up any macroblock base deblocker
[21:10] <kierank> depends if the blocking is at the frame or field elvel
[21:10] <ubitux> Daemon404: so with the lavfi madness you like so much, a complete potential workflow will look like:
[21:10] <ubitux> -vf 'split [ppme][clean]; [ppme]  separatefields, denoise, joinfields [pp]; [pp][b] fieldmatch=order=ttf:ppsrc=1, yadif=deint=interlaced, decimate'
[21:11] <ubitux> (of course there are some other fiters to write here)
[21:11] <Daemon404> kierank, true
[21:11] <ubitux> -vf 'split [ppme][clean]; [ppme]  separatefields, denoise, joinfields [pp]; [pp][clean] fieldmatch=order=ttf:ppsrc=1, yadif=deint=interlaced, decimate'
[21:11] <ubitux> sorry
[21:11] <Daemon404> the mroe common useclse is only 1 input to fm
[21:12] <Daemon404> im assuming thats still possible
[21:12] <ubitux> yes sure
[21:12] <ubitux> ppsrc=1 was here to enable the clip2 thing
[21:12] <ubitux> and fieldmatch is marking the frames it wasn't able to decomb as interlaced, so yadif can deinterlace what's left
[21:13] <ubitux> and in the example above, the denoise preproc is used to increase the combed frame accuracy
[21:13] <ubitux> does that make any sense and looks correct to you?
[21:15] <ubitux> the main difference here with vivtc
[21:15] <ubitux> is that instead of using "_Combed" metadata to notify about non-matching fields out of tfm
[21:15] <ubitux> the frames are marked as interlaced or not
[21:15] <ubitux> and yadif re-use that
[21:17] <ubitux> Daemon404: opinion?
[21:17] Action: ubitux starts porting decimate now
[21:18] Action: ubitux wonders how to call it
[21:18] <ubitux> any idea for the decimate filter port? (since we already have a decimate filter)
[21:19] <Daemon404> ubitux, i guess thats OK
[21:19] <ubitux> cool ok
[21:19] <Daemon404> as long as its well documente
[21:19] <Daemon404> d
[21:19] <ubitux> yes sure it will
[21:19] <ubitux> well i guess lavfi didn't damage my brain that much.
[21:19] <ubitux> anyway, for the decimate filter... suggestion? ffdecimate? decimate2? smartannhilation?
[21:21] <ubitux> thesaurus proposes me "commit genocide"
[21:21] <ubitux> -vf fieldmatch,commitgenocide
[21:21] <ubitux> yay, sounds perfect
[21:21] <ubitux> "reduce" maybe
[21:21] <ubitux> dupdrop?
[21:26] <Daemon404> dupdrop is incredibly misleading
[21:26] <Daemon404> it is not deduping
[21:26] <Daemon404> it's decimating
[21:27] <Daemon404> theyre two distinctly different things
[21:28] <ubitux> so just like me you prefer commitgenocide?
[21:39] <ubitux> btw, i wonder if the matching modes in vivtc are really doing what was originally expected
[21:39] <ubitux> i guess i'll discuss it with Myrsloik 
[21:44] <ubitux> cehoyos: hey.
[21:44] <ubitux> cehoyos: so one instance with all the --disable-xxx?
[21:44] <ubitux> don't we have a --disable-x86 or something?
[21:49] <cehoyos> I wonder what --disable-x86 would do?
[21:49] <cehoyos> There is --disable-asm and it gets tested by several fate instances
[21:49] <cehoyos> But no test for --disable-mmx ;-(
[21:50] <ubitux> the --disable list you provided me
[21:50] <ubitux> isn't it equivalent to --disable-asm?
[21:51] <nevcairiel> i fail to see the significance of a disable-mmx build, its hardly real-world relevant anymore =P
[21:54] <Daemon404> considering it's all decided at runtime
[21:54] <Daemon404> it is literally useless
[21:56] <cehoyos> ubitux: Testing all flags together: yes - what I mean is one compilation test for every configure option.
[21:56] <ubitux> cehoyos: oh well that's gonna be a bit too much
[21:56] <ubitux> it takes quite a while now to run all the instances
[21:57] <ubitux> i'd better avoid an extra large addition of instances
[21:57] <cehoyos> In this case: Only --disable-mmx please
[21:57] <ubitux> otherwise we'll need to wait even longer
[21:57] <ubitux> ok
[21:57] <cehoyos> Merci!
[21:58] <ubitux> your welcome
[21:58] <ubitux> cehoyos: added, will be in the next loop
[22:14] <cone-19> ffmpeg.git 03Carl Eugen Hoyos 07master:1ed10bd89cc5: Fix typo in dvvideo decoder dependencies.
[22:19] <ubitux> mmh i guess we could do the denoise with something like field,hqdn3d,tinterlace
[22:19] <ubitux> but the field reconstruction looks weird
[22:23] <Daemon404> shouldnt clip2 only e used in metrics calculation
[22:23] <Daemon404> using it for output seems... weird
[22:24] <ubitux> yes, i found that a bit counter intuitive too
[22:24] <ubitux> i guess it made the code simpler
[22:25] <ubitux> i can change that easily though
[22:25] <Daemon404> also hqdn3d is likely to nuke it
[22:25] <Daemon404> on default settings
[22:25] <ubitux> yeah but i don't have another denoise filter in mind :p
[22:25] <Daemon404> should i link removegrain.cpp? :)
[22:25] <ubitux> :D
[22:26] <ubitux> why don't you port it instead?
[22:26] <Daemon404> because i dont want to RE a bunch of SIMD
[22:26] <ubitux> i hope to be done with fieldmatch and decimate in a few days; then i'll start on the eedi3 thing
[22:26] <Daemon404> eh
[22:26] <ubitux> unless someone wants to do it
[22:26] <Daemon404> i have an eedi port from baptiste somewhere
[22:26] <Daemon404> might be eedi2 tho
[22:26] <ubitux> oh?
[22:26] <nodame> Doesn't it have C versions of everything?
[22:27] <Daemon404> nodame, no
[22:27] <ubitux> nodame: it will be easy to enable asm on some parts later
[22:27] <Daemon404> http://chromashift.org/RemoveGrain.cpp
[22:27] <Daemon404> ^ no
[22:27] <ubitux> oh, that.
[22:28] <ubitux> if anyone wants to port eedi3, that would be extremely welcome
[22:28] <ubitux> because i really have some other stuff to care of :p
[22:28] <ubitux> i need to get back to subtitles asap
[22:28] <ubitux> meh saste and paul aren't here
[22:28] <ubitux> i can't motivate them :(
[22:29] Action: ubitux still has no name for the decimate port
[22:30] <Daemon404> whats wrong with vfm+vdecimate
[22:31] <ubitux> it's better to change the name since i'm doing some changes to it
[22:31] <Daemon404> heh
[22:31] <ubitux> not only internals, but exported options or such
[22:32] <ubitux> so it sounds legit to use another name to avoid the confusion
[22:33] <Daemon404> vfm-ng
[22:34] <ubitux> that sounds a bit pretencious :)
[22:34] <Daemon404> ng stands for Never Give (Up)
[22:34] <ubitux> haha
[22:35] <ubitux> and anyway, the fm filter name is not a proble
[22:35] <ubitux> problem
[22:35] <ubitux> i can just name it "fieldmatch"
[22:35] <ubitux> the problem is decimate, since we already have a filter of that name
[22:35] <ubitux> (and i really don't feel like trying to inject the port into it)
[22:36] <Daemon404> i wonder how many poor souls will use fieldmatch,decimate
[22:36] <nodame> Drop the old one and call it an upgrade.
[22:36] <nodame> (Is it?)
[22:36] <Daemon404> nodame, its tdecimate
[22:36] <Daemon404> so yes
[22:37] <nodame> Yeah, I just don't know the old one.
[22:37] <Daemon404> mplayer's.
[22:37] <ubitux> you don't want to know about it
[22:37] <ubitux> but i feel bad for stefano doing the port recently
[22:38] <ubitux> of course, one solution is to rename the current decimate filter into mpdecimate and use the decimate
[22:38] <ubitux> and make some versions bumping 
[22:38] <ubitux> would ppl prefer it that way?
[22:38] <Daemon404> that seaons reasonable
[22:38] <ubitux> ok, let's do that
[22:39] Action: ubitux feels a bit bad for not using the commitgenocide filter name
[22:39] <Daemon404> port hm3kd
[22:39] <Daemon404> and call it that
[22:40] <ubitux> refocus filter?
[22:41] <Daemon404> it was ported as a troll to avs
[22:41] <ubitux> oh wait
[22:41] <Daemon404> http://chromashift.org/img/hm3kd.png
[22:41] <ubitux> nice
[22:41] <Daemon404> several minutes per frame back on my old athlon xp
[22:41] <Daemon404> or was ir an hr
[23:03] <cone-19> ffmpeg.git 03Michael Niedermayer 07master:cdbf8409ef59: x86/h264_qpel: switch to av_assert
[23:03] <cone-19> ffmpeg.git 03Michael Niedermayer 07master:b3e9f266e8f8: x86/mpegvideo: switch to av_assert
[23:07] <ubitux> Daemon404: btw, the between() was pushed in eval, if you're interested
[23:08] <Daemon404> k
[23:12] <ubitux> michaelni: WebP addition could potentially be part of the Changelog
[23:12] <cone-19> ffmpeg.git 03Clément BSsch 07master:859f7da543bf: lavc/prores: restore pict_type and key_frame setting.
[23:12] <cone-19> ffmpeg.git 03Clément BSsch 07master:89b4e758d3d0: lavfi/blend: always peek the first frame of each queue.
[23:14] <gnafu> Daemon404: I read that as "urr-a-hurr".
[23:20] <ubitux> hey saste 
[23:20] <cone-19> ffmpeg.git 03Michael Niedermayer 07master:dda04a589938: Changelog: add WebP
[23:20] <ubitux> saste: wouldn't you be motivated to port http://code.google.com/p/vapoursynth/source/browse/trunk/src/filters/eedi3/eedi3.c ?
[23:21] <ubitux> !
[23:21] <ubitux> i guess this is a no
[23:35] <ubitux> Daemon404: btw, at least for decimate, TDecimate seems to have the same semantic for clip2
[23:36] <ubitux>      clip2 -
[23:36] <ubitux>         Allows specification of a second clip from which to take frames. Metric calculation
[23:36] <ubitux>         and decimation are still done on the input clip, but the frames that tdecimate
[23:36] <ubitux>         returns are from clip2.  
[23:36] <ubitux> at least according to the doc
[23:43] <saste> ubitux, sure looks interesting
[23:43] <ubitux> i propose you start now then
[23:44] <saste> ubitux, why??
[23:45] <ubitux> because i want it obviously
[23:45] <ubitux> and thus it shall remains on top of your todo list
[23:45] <saste> ubitux, there is only one reliable way to get things done
[23:45] <saste> use a whip
[23:45] <saste> or do it yourself
[23:46] <saste> whip doesn't work over internet, so you have only the second option
[23:46] <saste> seriously, i'm trying to finish stuff(TM)
[23:46] <ubitux> i like the whip idea; can you spare me some effort and buy it to use it yourself?
[23:46] <saste> so at least i want to kill sox before going on with more stuff
[23:46] <ubitux> oh right the sox thing
[23:46] <ubitux> ok :)
[23:46] <saste> and i have also some nasty bugs to kill
[23:47] <ubitux> Daemon404: it's funny that decimate supports > 8 bits but ivtc doesn't
[23:47] <ubitux> s/ivtc/vfm/
[23:48] <ubitux> mmh or maybe with the clip2 thing it could be supported... :)
[23:48] <ubitux> the main input being 8-bit but the field copy could be from the clean 10+ bits source
[23:48] <ubitux> mmh.
[23:54] <saste> Compn, Daemon404, ping on --enable-monolithic-tool-docs
[23:54] <saste> llogan, news on gsoc?
[23:59] <llogan> saste: i haven't done anything since i submitted my revisions to the application to the ML. i'm busy dealing with building permits today.
[23:59] <saste> llogan, allright
[23:59] <saste> i plan to send the application tomorrow
[00:00] --- Sat Mar 23 2013