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

[burek]

[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