[01:32] <cehoyos> durandal_1707: Ticket opened [01:37] <kierank> heh zip file isn't annoying [01:38] <cehoyos> zip file isn't annoying? [01:39] <kierank> that hobbit trailer is a zip file [01:39] <cehoyos> Afair, I uploaded a h264 file, didn't I? [01:39] <kierank> oh bleh [01:39] <cehoyos> (The reference decoder doesn't work well with zip files here.) [01:47] <ubitux> it's incredible our swf demuxer works "so well" [01:48] <ubitux> the basis of the format is to have a dictionnary for the different content element, and a display list [01:48] <ubitux> and our demuxer just display and play every image and sounds it finds [01:49] <ubitux> [declare an element image of type jpeg] = "yay let's play that jpeg video stream!" [01:50] <ubitux> problem is, i think the correct way to handle this is to decode & reconstruct the frames within the demuxer and outputs rawvideo data all the time [01:51] <cehoyos> ubitux: Ticket #2564 ? [01:52] <ubitux> well, swf support is pretty bad generally speaking, for various reason [01:52] <ubitux> we "support" maybe 10% of the tags [01:52] <ubitux> and the general logic is flawed [01:56] <ubitux> btw, should we make the pictures from mp3 as attachment? [01:56] <ubitux> (mp3 or whatever formats with covers) [02:26] <iive> ubitux: I hope you don't want to implement flashplayer into the demuxer :P [02:28] <Compn> is our swf demuxer secure ? [02:28] <Compn> anything adobe is insecure :D [02:33] <ubitux> iive: actually, i do ;) [02:34] <iive> ubitux: how is it going to decode video? [02:35] <ubitux> "videos" are just successive jpegs or rawvideo frames [02:35] <iive> no flv video in swf? good. [02:36] <ubitux> well, actually you can have some vp6 packets [02:37] <ubitux> i'd like to have the demuxer declare all kind of video, audio and attachment, and make a main audio and a main video stream as rawvideo/pcm [02:47] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:53ec1c811e41: j2k: merge cosmetics and non functional changes from jpeg2000 [02:49] <ubitux> michaelni: you're doing a lot of cosmetics commit lately ;) [02:52] <michaelni> yes :( [03:28] <ubitux> yay mcdeint [08:59] <cone-719> ffmpeg.git 03Kostya Shishkov 07master:0418cbf08195: fix scalarproduct_and_madd_int16_altivec() for orders > 16 [08:59] <cone-719> ffmpeg.git 03Martin Storsjö 07master:be7952b5c3ac: arm: Only output eabi attributes if building for ELF [08:59] <cone-719> ffmpeg.git 03Michael Niedermayer 07master:b7c6d1ed9064: Merge remote-tracking branch 'qatar/master' [09:37] <cone-719> ffmpeg.git 03Xidorn Quan 07master:ffd7fd79441f: avcodec/vda_h264: use av_buffer to manage buffers [09:37] <cone-719> ffmpeg.git 03Xidorn Quan 07master:499b82f60461: avcodec/vda_h264_dec: fix a memory leak [09:37] <cone-719> ffmpeg.git 03Michael Niedermayer 07master:1c711b6ecd53: Merge remote-tracking branch 'dilaroga/master' [10:34] <frankly> pCodecCtx->channels sometimes returns 1 instead of 2 for the same audio stream. What can be the reason for that? [12:49] <durandal_1707> lol: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2013-May/014547.html [12:50] <av500> truth is in the eye of the beholder [12:53] <kierank> that thread will end well [12:57] <ubitux> "Plus [12:57] <ubitux> they steal from libav without attribution." [12:57] <ubitux> i wonder where that comes from [12:57] <durandal_1707> yes we do [12:57] <ubitux> it's about ffmpeg stealing from libav [12:58] <ubitux> unless it's a typo [12:58] <av500> you are kanging the code [12:58] <ubitux> the merge are the most conservative way of keeping attribution so far afaict [13:12] <Compn> ubitux : i dont think your blog post makes it clear just how much attribution loss is made [13:12] <Compn> :P [13:12] <ubitux> maybe that's because i don't see any attribution loss on our side [13:13] <Compn> i mean on libav [13:13] <Compn> when they cherry carls commits [13:13] <ubitux> that wasn't the point defended by the guy [13:13] <ubitux> that's why i'm wondering what this is about [13:13] <Compn> i know, i was bringing up an unrelated example [13:13] <Compn> er an unrelated topic [13:13] <Compn> that guys email is kind of silly :P [13:14] <Compn> too much hyperbole to parse [13:25] <saste> is mcdeint used in real world? [13:26] <durandal_1707> nobody uses that, everybody uses vapour/avisynth [13:35] <microchip_> durandal_1707: i use mcdeint :) [13:35] <durandal_1707> how much? [13:35] <microchip_> durandal_1707: not much [13:36] <microchip_> only every now and then when i deal with interlaced files [13:39] <ubitux> funman: i see some (one?) ffmpeg-subtitles related patch from you on vlc-devel, so since you're now the subtitles expert (and j-b is not here) i have a question [13:39] <ubitux> funman: is vlc using the matroska demuxer for subtitles? [13:40] <av500> for MKV subs? [13:40] <ubitux> if so, did you see that ffmpeg is going to output verbatim ass packet now? (and not the constructed ass lines) [13:40] <ubitux> av500: yup [13:40] <av500> I'd guess so [13:41] <ubitux> it would be nice to consider adding the codec id ASS so it doesn't break badly when removed (next lavf major bump) [14:01] <saste> microchip_, what is mcdeint good for, compared to the other deinterlacers? [14:03] <microchip_> saste: i find it produces better result than yadif alone [14:08] <microchip_> saste: sometimes i see (not sure if this is correct english) jagged edges with yadif alone... if i throw mcdeint in the game, these disappear [14:08] <saste> microchip_, do you mean you put them in sequence? [14:08] <saste> like yadif,mcdeint? [14:09] <microchip_> yes [14:09] <microchip_> yadif=1,mcdeint [14:13] <ubitux> ah saste i forgot [14:13] <ubitux> what about timeline? [14:13] <saste> in mcdeint? [14:13] <ubitux> mcdeint might be applied only to a few frames [14:13] <ubitux> yes [14:13] <saste> yes i'll try it [14:13] <ubitux> (could be used to just random fix yadif artefacts) [14:13] <ubitux> instead of processing the whole video [14:14] <saste> or i'll leave it to a further patch, since i prefer to avoid mixing port with additional feats [14:14] <saste> unless it's effortless [14:14] <ubitux> if you need _INTERNAL leave it to another patch [14:14] <ubitux> but GENERIC might be possible from a quick look [14:15] <iive> saste: http://guru.multimedia.cx/deinterlacing-filters/ [14:29] <durandal_1707> iive: that link have comments that are just spam [14:35] <durandal_1707> so anybody going to port phase filter? [14:44] <durandal_1707> actually is there point in porting it? [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:c63e4e65698f: lavfi/idet: remove request_frame hack [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:4f8e4b8a54ad: lavfi/tinterlace: remove request frame hack [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:ed1c83508ec9: lavfi/trim: remove request frame hack [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:68def27124ae: lavfi/interlace: remove request frame hack [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:11cdf9671f8c: lavfi/trim: make use of AVFILTER_DEFINE_CLASS [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:d349704eef1b: lavfi/interlace: make use of AVFILTER_DEFINE_CLASS [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:622c9774376a: lavfi/hqdn3d: make use of AVFILTER_DEFINE_CLASS [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:5fe5bde60a88: lavfi/join: make use of AVFILTER_DEFINE_CLASS [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:e457f2cf1ff1: lavfi/setpts: make use of AVFILTER_DEFINE_CLASS [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:6008b5abbb17: lavfi/format: make use of AVFILTER_DEFINE_CLASS [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:beda41886ead: lavfi/channelmap: make use of AVFILTER_DEFINE_CLASS [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:229d5bfdc805: lavfi/frei0r: make use of AVFILTER_DEFINE_CLASS [14:44] <cone-561> ffmpeg.git 03Paul B Mahol 07master:a1873f35f83d: lavfi/ocv: make use of AVFILTER_DEFINE_CLASS [14:45] <ubitux> :) [14:46] <durandal_1707> 12k commits still to go... [15:21] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:3300b5f6ce84: j2k/jpeg2000 headers: Cblk/Prec cleanup & merge [15:21] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:9fd23baa7417: j2k: merge precinct init code from jpeg2000 [15:22] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:cbaa0871c224: j2kenc: switch to cblk in prec [15:22] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:369422db0c6d: j2kdec: merge cblk restructuring from jpeg2000 [15:22] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:5161c62595d6: j2k: fix band coord [15:22] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:14652c080dc3: j2k/jpeg2000: restructure cblk coord [15:22] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:2c5a5c5a623d: j2kdec: cdxy != 1 does not work, print an error [15:22] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:81ccc31f75e0: j2kdec: merge decode_tile cblk handling from jpeg2000 [15:22] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:a05db52c12f0: j2k: remove cblk from band [15:25] <durandal_1707> michaelni: you gonna work on missing/unimplemented stuf in decoder? [15:25] <BuxiNess> michaelni, \o/ [15:33] <michaelni> durandal_1707, yes probably [15:37] <durandal_1707> are any of decoders bitexact? [15:37] <durandal_1707> (exp for lossless) [15:39] <BuxiNess> durandal_1707, yes for lossy case DWT97 and MCT in bitexact [15:41] <durandal_1707> but lossless? [15:41] <BuxiNess> no, lossy case [15:42] <BuxiNess> lossless , is bitexact, but not tested AFAIK [15:42] <durandal_1707> how lossles can be bitexact if it was never tested.... [15:44] <BuxiNess> as lossless in implemented in fixed point [15:50] <saste> do we have an equivalent of tfields? [15:50] <durandal_1707> what does tfields do? [15:53] <saste> durandal_1707, Temporal field separation - split fields into frames, doubling the output framerate. [15:53] <saste> i'm looking for mode 1: 1: Interpolate missing lines. (The algorithm used might not be so good.) [15:53] <durandal_1707> separefields does that [15:54] <durandal_1707> *separatefields [15:56] <saste> no separatefields does no interpolation [15:56] <saste> indeed it halves the height [15:58] <durandal_1707> so that filter interpolates lines if fields are missing, i find such feature useless [15:59] <saste> regarding mcdeint: It needs one field per frame as input and must thus be used together with tfields=1 or yadif=1/3 or equivalent. [15:59] <saste> thus can it be used alone to deinterlace two fields in one frame video? [15:59] <saste> or should be only be used in combination with yadif? [16:00] <saste> and does it make if this is the case? [16:00] <durandal_1707> why tfields is not in libmpcodecs? [16:01] <durandal_1707> i think it come later... [16:02] <saste> on the other hand: ffplay -video_size cif ~/s/foreman_cif.yuv -vf tinterlace=interleave_top,mp=mcdeint [16:03] <saste> so either the documentation is misleading, or it is wrong [16:03] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:8c2e201c4f3a: j2k/jpeg2000: drop xi/yi0/1 from Jpeg2000Prec [16:03] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:c2e942099ac8: j2k: drop cblknx/y from Jpeg2000Band [16:04] <funman> ubitux: for mkv we use our own libmatroska demux [16:04] <funman> and the mkv guy is typx :) [16:04] <saste> tfields => r9515 | rfelker | 2003-03-01 06:35:09 +0100 (Sat, 01 Mar 2003) | 2 lines [16:04] <ubitux> funman: ok [16:05] <ubitux> funman: so far only the matroska demuxer will output AV_CODEC_ID_ASS, so you might not need to adapt any code [16:05] <funman> for subtitles i would guess jb is more knowledgeable [16:05] <saste> michaelni, why is tfields not in libmpcodecs? [16:05] <ubitux> didn't we remove it? [16:06] <saste> ubitux, no [16:06] <saste> anyway de/interlacing is boring to deatch [16:06] <ubitux> yup [16:06] <saste> so much time i wasted on it [16:07] <ubitux> saste: tfields is in the "Unsupported filters" list in vf_mp [16:08] <saste> yes, why? [16:08] <ubitux> madness maybe [16:08] <ubitux> ETOOCOMPLEX wrapper i would guess [16:09] <durandal_1707> i looked at code and its trivial and boring [16:10] <durandal_1707> but have some strange buffering code, so it was probably disabled because: it did not compile at all, was actually tested and crashed [17:13] <saste> well it's weird [17:14] <saste> my mcdeint produces the same luma, but differs on chroma planes [17:14] <ubitux> because FF_CEIL_RSHIFT() maybe? [17:14] <saste> no i checked that [17:15] <ubitux> you're changing mcdeint->frame data and linesize [17:15] <ubitux> are you sure it's ok? [17:15] <ubitux> from a buffer ref count PoV [17:33] <saste> ubitux, no but i managed to simplify it getting rid of mcdeint->frame [17:36] <ubitux> saste: btw, do you want me to send a new version of the hald clut patchset? [17:36] <saste> ubitux, no, just i'm still a bit confused about it [17:37] <saste> can you reply to my question [17:37] <ubitux> about the level power? [17:37] <saste> ? [17:37] <saste> yes [17:37] <ubitux> i'll reply yes [17:49] <microchip_> saste: in mcdeint, which param is tff and which bff? is 0 = tff or is 1 = tff ? mplayer doc doesn't mention that [17:49] Action: microchip_ always uses 0 for tff but isn't sure if it's correct [17:49] <saste> microchip_, should be the same as in yadif [17:49] <microchip_> ok [17:49] <saste> also -1 (default value) is not documented as well [17:49] <microchip_> yeah [17:50] <saste> i'm going to look at that [17:51] <saste> microchip_, what values of qp do you use? [17:51] <microchip_> saste: 10... so mcdeint=1:0:10 [17:51] <saste> so basically you always use a yadif,mcdeint combo? [17:52] <microchip_> yes [17:52] <microchip_> never used mcdeint without yadif [18:50] <durandal_1707> why is align_put_bits unsupported on le? is it just not done, or ? [19:04] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:9a18395b92f0: j2k/jpeg2000: merge a few whitespaces [19:04] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:1b5cb6c00a17: j2k/jpeg2000: Partially merge quantization code [19:04] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:243cc38d944b: j2k: change fixed point of stepsize to 16.16 [19:04] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:ee189701a6f7: j2kenc: Allow encoding with the 9/7 wavelet [19:39] <durandal11707> looks like anton lost interest on lavfi [19:40] <ubitux> let's hope he has interest up to integrate frame threading, because i don't feel like doing it :p [19:41] <ubitux> durandal11707: and i doubt that's true :) [19:56] <Compn> ubitux : why remove the codec id ass on next bump ? [19:56] <Compn> i mean , no backwards compat ? [19:57] <Compn> or are we not doing backwards compat anymore ? i dont remember the vote :P [19:58] <Compn> i mean i dont care what happens. but i want to know which one we are doing in the future so i dont complain about feature/api changes in the future. [20:05] <Daemon404> [13:56] <@Compn> ubitux : why remove the codec id ass on next bump ? [20:05] <Daemon404> [13:56] <@Compn> i mean , no backwards compat ? [20:05] <Daemon404> i think you fail to understand what a bump means [20:05] <Daemon404> thats the entire point. [20:06] <ubitux> Compn: the point is to move to the new codec id [20:06] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:1bbb46ff7126: j2k_dwt: fix scaling of 9/7 dwt [20:06] <ubitux> i could keep backward compat by not doing anything, but the point is to actually make the matroska demuxer output proper ass [20:06] <ubitux> currently, we keep backward compat, next bump will change the behaviour because that behaviour change is what we want [20:07] <ubitux> (because that's the correct thing to do) [20:36] <Compn> oh ok :P [20:38] <Compn> vlc having a tiff again [20:39] <Daemon404> hey now [20:39] <Daemon404> at least there's no death threats ... this time [20:40] <durandal11707> Compn: it was removed? [20:40] <Compn> durandal11707 : what now ? [20:40] <Compn> the ass thing happens on the next bump [20:43] <cone-561> ffmpeg.git 03Clément BSsch 07master:3cec29cf5981: lavfi: add haldclutsrc filter. [20:43] <cone-561> ffmpeg.git 03Clément BSsch 07master:43286028906a: lavfi: add dual input helpers. [20:43] <cone-561> ffmpeg.git 03Clément BSsch 07master:158d96e3f0ab: lavfi: add haldclut filter. [20:43] <cone-561> ffmpeg.git 03Clément BSsch 07master:ae5738248a9e: lavfi/lut3d: move lut3d init to its definition scope. [20:43] <cone-561> ffmpeg.git 03Clément BSsch 07master:92a2d12a7103: lavfi/overlay: remove do_blend forward declaration. [20:49] <durandal11707> michaelni: does j2kenc finally writes valid subsampled yuvs, there was obvious bug that it caused to be disabled [20:53] <cone-561> ffmpeg.git 03Clément BSsch 07master:160ea26560c4: lavfi/haldclutsrc: 10l remove size options. [20:56] <durandal11707> but you wanted to add nice chicks on right side.... [20:57] <Daemon404> nice chicks, eh? ;) [20:59] <ubitux> durandal11707: you can. [20:59] <ubitux> :) [20:59] <ubitux> with pad [20:59] <ubitux> durandal11707: problem with padding withing haldclutsrc is that there is some color padding issue [20:59] <ubitux> and i didn't want to play with that [20:59] <ubitux> anyway, see the documentation for adding the nice color bars chicks on the right side [21:00] <ubitux> i provided an example [21:03] <ubitux> i just feel like i've done something almost useful for once [21:04] <ubitux> i definitely need to write something more exotic [21:06] <Daemon404> wow we have a haiku instance? [21:06] <ubitux> it's been a while now [21:06] <ubitux> Daemon404: btw, any huge complain on lavfi remaining, except api-wise? [21:07] <Daemon404> that it is a giant monolithic lib [21:07] <Daemon404> P [21:07] <Daemon404> :P [21:07] <ubitux> is that a problem in practice? [21:09] <Daemon404> having to recompile every time you want t use a new filter, and completely alienating 3rd party filters (which may want to be a bit mroe agile than review allows) [21:09] <Daemon404> is pretty shit for an end user [21:09] <Daemon404> especially one who just wants to work with video, and not be a dev [21:10] <nevcairiel> for the first issue, just build it with all the filters [21:10] <Daemon404> is also disallows proprietry filters [21:10] <ubitux> you think that, with the packaging and distribution model we follow, it will make sense to allow our users to download .dll and .so for filters? [21:10] <Daemon404> well ffmpeg's packaging and distribution model is... [21:10] <Daemon404> "fuck you" [21:10] <Daemon404> "arbitrary!" [21:10] <Daemon404> et [21:10] <ubitux> not really [21:10] <nevcairiel> the second i understand, registering external components in any part of ffmpeg is just impossible these days [21:10] <Daemon404> NIH [21:11] <Daemon404> and disallowing closed source filters is pretty bad for any imaging framework [21:11] <Daemon404> hinders adoption bigtime [21:11] <ubitux> maybe they should make their filter builtin in ffmpeg ;) [21:11] <Daemon404> not possible [21:12] <Daemon404> liense violation [21:12] <Daemon404> license* [21:12] <ubitux> anton will break the api every 3 month anyway so the filter will have to be rebased [21:12] <ubitux> better for them to have it builtin [21:12] <Daemon404> well thats another complaint :P [21:12] <ubitux> Daemon404: builtin & upstream i mean [21:12] <Daemon404> i have clsoed source avs filters i use from 10+ years ago [21:12] <Daemon404> THAT STILL WORK [21:12] <ubitux> anyway, foss vs evil debate [21:13] <ubitux> Daemon404: ok, let's move the api & monolithic decision aside [21:13] <ubitux> anything else? :p [21:13] <Compn> ubitux : is it hard to make 3rd party wrapper for daemon? [21:13] <Compn> i mean runtime filters [21:13] <Compn> for the windows weenies [21:13] <Daemon404> it doesnt gel too well with teh current design [21:13] <Daemon404> iirc [21:13] <Compn> should be no problem [21:13] <Compn> take all of 300 lines of code [21:13] <ubitux> Compn: it will break everytime we change the api [21:14] <Daemon404> its useless without abi compat [21:14] <Daemon404> yes [21:14] <ubitux> we have to wait for a stable framework [21:14] <Compn> k [21:14] <Daemon404> ubitux, lemme think for a sec [21:14] <ubitux> Compn: we still have large "design" issue to solve before freezing the api IMO [21:14] <ubitux> lavfi is fairly young [21:14] <ubitux> typically we can't really seek [21:15] <ubitux> we don't have yet frame threading [21:15] <ubitux> and we really don't allow scripting [21:15] <ubitux> also, the api itself for users is not really that easy to deal with [21:15] <Daemon404> [15:14] <@ubitux> lavfi is fairly young [21:15] <Daemon404> i may note [21:15] <Daemon404> vapoursynth has abi compat [21:15] <Daemon404> and is much younger [21:15] <Daemon404> and has a stable and mature core [21:16] <ubitux> anyway, the more filters we add, the more we can see what kind of api changes we need [21:16] <ubitux> what is the common redundancy in filters, or models [21:16] <Daemon404> ubitux, the only thing that come to midn right now [21:16] <Daemon404> is what i mentioned in the otehr channel [21:16] <Daemon404> [14:50] <@Daemon404> also confusing: -vf filter=option=value [21:16] <Daemon404> [14:50] <@Daemon404> reuse of - [21:16] <Daemon404> [14:50] <@Daemon404> = [21:17] <ubitux> should we allow another char? :p [21:17] <ubitux> like '|' ? [21:17] <ubitux> -vf filter|option=foo:bar=bla ? [21:17] <ubitux> :p [21:17] <Daemon404> yeah im sure using the pipe char is a GREAT idea [21:17] <Daemon404> shells love that [21:18] <ubitux> ;) [21:18] <ubitux> name your favorite character [21:18] <ubitux> or suggest something [21:18] <ubitux> (is that really a problem?..) [21:18] <Daemon404> its not easy to read [21:18] <Daemon404> i always have to write it as foo='opt=blah' [21:18] <Daemon404> in my scripts [21:19] <ubitux> i was expecting more something like ENOFILTERFORXXX [21:19] <Daemon404> lots of taht [21:19] <Daemon404> but thats not a framework issue [21:19] <Daemon404> now is it? [21:19] <ubitux> my question wasn't really about the framework itself [21:19] <ubitux> more like what do you miss from it [21:20] <Daemon404> the main thing everyone misses when they leave avs is QTGMC [21:20] <ubitux> (yeah i know you don't miss anything, but let's play the game) [21:20] <Daemon404> but thats not relevant [21:20] <Daemon404> becaue that requires porting removegrain.cpp [21:20] <Daemon404> and youve seen that file [21:20] <ubitux> :DD [21:20] <ubitux> we have yadif and soon mcdeint ;) [21:20] <Daemon404> nnedi3 would be nice [21:20] <ubitux> yes i still have it in my tabs [21:21] <ubitux> i could port it... [21:21] <Daemon404> the other thing [21:21] <Daemon404> which even vapoursynth lacks [21:21] <microchip_> ubitux: do it! :D [21:21] <Daemon404> is a good mv filter [21:21] <Daemon404> for criptiing against or using [21:21] <Daemon404> i.e. mvtools [21:21] <Daemon404> also a horrible codebase. [21:21] <Daemon404> basically for mocomp [21:22] <ubitux> mmh [21:22] <ubitux> that's likely a large work, but ok [21:22] <Daemon404> hence vs doesn teven have it [21:22] <Daemon404> and its not as relevant for lavfi [21:22] <Daemon404> since users arent gonna be witin big scrpts that rely on MVs and edge masks [21:22] <Daemon404> like they do for AVS [21:23] <Daemon404> use case isnt the same. [21:23] <ubitux> okay [21:23] <ubitux> microchip_: i'll likely port spp first [21:23] <ubitux> i started, i need to get it done [21:24] <microchip_> ubitux: do that too :D, i often need a deblocker [21:24] <Daemon404> i actually used to use fast spp in avs [21:24] <Daemon404> long time ago [21:24] <ubitux> don't be ashamed [21:24] <ubitux> it's a nice filter [21:24] <Daemon404> its mostly been replaced by scripts like funkydeblock [21:24] <Daemon404> and stuff [21:24] <ubitux> more effective? [21:24] <Daemon404> depends on source [21:25] <Daemon404> mostly i wouldnt even block much nowadays [21:25] <Daemon404> since it ruins detail [21:25] <Daemon404> detail > blocks [21:25] <ubitux> you need a depixeler [21:25] <ubitux> deverysmallblocks [21:25] <ubitux> anyway, ok [21:26] <Daemon404> doesnt even make sense WRT macroblocks [21:26] <Daemon404> :P [21:26] <ubitux> :) [21:26] <Daemon404> i still have been meaning to try dctdnoiz [21:26] <ubitux> please do [21:26] <Daemon404> i wonder if it will really be too powerful liek a lot of FFT based denoisers [21:26] <Daemon404> thats my worry [21:27] <ubitux> too powerful?, just reduce the sigma :p [21:27] <ubitux> also you can put an expression [21:27] <Daemon404> its always a game of trying it 40 times for each source [21:27] <ubitux> if you can come up with a good one [21:27] <Daemon404> with varying exprs and sigmas [21:27] <Daemon404> and with dfttest and fft3dfilter.. sigma2 [21:27] <Daemon404> and sigma3 [21:27] <Daemon404> so many variables~ [21:28] <Daemon404> it might actually be useful for derainbowing or dotcrawl removal if tuend properly. [21:28] <Daemon404> maybe. [21:28] <ubitux> if you can find some cool formula to use with dctdnoiz, feel free to share them so i add them to the doc [21:29] <Daemon404> doubt i will [21:29] <Daemon404> that sort of maths generally eludes me [21:29] <Daemon404> without lots of concentration [21:29] <microchip_> from my brief testing, dctdnoiz makes ffmpeg use only a single thread [21:29] <Daemon404> the filter is single threaded [21:29] <Daemon404> so yeah [21:29] <microchip_> yeah [21:31] <ubitux> single threaded, and slow! [21:31] <ubitux> 1 minute and 10 seconds on my PC to process a single frame :(( [21:54] <funman> how can I control (enable/disable) multithreaded encoding with ffmpeg cmdline ? [21:54] <Daemon404> -threads [21:54] <funman> ffmpeg -h long | grep thr only returns threshold [21:55] <funman> thanks [21:55] <Daemon404> and it matters where you put threads [21:55] <Daemon404> before -i = decoder threads [21:55] <Daemon404> avfter -i = encoder threads [21:55] <Daemon404> iirc [21:55] <Daemon404> after* [21:55] <durandal11707> funman: ffmpeg -h full [21:56] <ubitux> doesn't this trigger a terminal explosion? [21:56] <Daemon404> man ffmpeg [21:56] <funman> hm well -thread_type 1 or 0 works fine for encoding to png [21:56] <ubitux> Daemon404: man ffmpeg is small :) [21:56] <ubitux> Daemon404: we (saste) split the doc, remember? [21:56] <Daemon404> ffmpeg-all? [21:56] <ubitux> yeah that one is a bit hugez [21:56] <ubitux> but we didn't want it in the first place [22:01] <cone-561> ffmpeg.git 03Michael Niedermayer 07master:d4a466134264: j2k/jpeg2000: merge j2k & jpeg2000 dwts, drop j2k dwt [22:31] <wm4> so what exactly _is_ analyzeduration? [22:32] <wm4> there seem to be various "bad" effects setting it to a low value, but what exactly can happens seems to be in the dark [22:32] <ubitux> michaelni: j2k merge done? :o [22:32] <wm4> the default values is rather high though, and adds a lot of latency if you want to stream stuff from http [22:32] <cehoyos> There are three samples in a mail on mplayer-users, do you remember them? [22:33] <cehoyos> (j2k) [22:33] <cehoyos> http://thread.gmane.org/gmane.comp.video.mplayer.user/69771 [22:34] <wm4> so _what_ exactly are users supposed to do to get low latency? [22:48] <durandal11707> nobody tested my 2 patches for noise slice threading :( [22:51] <michaelni> ubitux, no j2k dwt is done [22:54] <durandal11707> funman: 1 is thread frame, 0 is auto which may be frame too, 2 are slice threads [23:54] <saste> ubitux: cool bro :) [23:54] <ubitux> you like it? :) [23:55] <saste> this moves color tweaking to the next level [23:55] <ubitux> yup [00:00] --- Tue May 28 2013