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

[burek]

[00:06] <michaelni> smarter, dunno, but it seems a bit premature to do such (possibly not so trivial) optimizations
[00:07] <smarter> yeah, just wondering :)
[00:11] <jojva> No idea about my question ? ^^
[00:13] <BBB-work> smarter, there isn't? I thought there was...
[00:13] <BBB-work> anyway
[00:13] <smarter> there's get_cabac_bypass_sign
[00:13] <BBB-work> don't worry about optimizing hevc for now
[00:13] <BBB-work> make it work and easy to read
[00:13] <BBB-work> we'll make it fast later
[00:14] <BBB-work> jojva, we use the same input buffer and simply offset the buffer by stride and then set buf_stride *= 2 to write alternate lines
[00:14] <BBB-work> offset buffer by stride = for second field
[00:14] <BBB-work> smarter, libavcodec/x86/cabac.h:static av_always_inline int get_cabac_bypass_sign_x86(CABACContext *c, int val)
[00:15] <BBB-work> smarter, that one?
[00:15] <smarter> yes
[00:15] <BBB-work> so it is optimized :)
[00:15] <smarter> sorry, I meant get_cabac_bypass_sign is optimized, but not get_cabac_bypass
[00:16] <BBB-work> oh I see
[00:16] <BBB-work> probably because it's virtually unused yes
[00:16] <BBB-work> or well, more generally, there's not a big performance impact, whereas there is code maintenance and development cost
[00:16] <BBB-work> so it may just not be worth it in the big picture
[00:16] <BBB-work> I guess
[00:16] <BBB-work> if you ask michaelni, maybe he'll write you one, I hear he loves gcc inline assembly
[00:16] <Skyler_> get_cabac_bypass_sign is the one that actually matters -- it's used in residual coding and mvds , iirc?
[00:17] <Skyler_> of course this changes in hevc
[00:17] <smarter> yes, there's a lot of bypass-coded symbols, to "increase throughput"
[00:19] <Skyler_> I imagine get_bypass would be quite similar to bypass_sign
[00:42] <ubitux> saste: did you get your mail issue fixed btw?
[00:42] <ubitux> (the long delay thing)
[00:42] <saste> ubitux, yes
[00:42] <saste> it was a weird issue related to fetchids/fetchmail
[00:43] <saste> so I can't blame gmail for that
[00:43] <saste> now mailbox delivery is almost immediate :)
[00:44] <ubitux> :)
[01:04] <ubitux> michaelni: 
[01:04] <ubitux> libavutil/frame.c:51:5: warning: qscale_table is deprecated (declared at libavutil/frame.h:183) [-Wdeprecated-declarations]
[01:04] <ubitux> libavutil/frame.c:52:5: warning: qstride is deprecated (declared at libavutil/frame.h:188) [-Wdeprecated-declarations]
[01:04] <ubitux> libavutil/frame.c:53:5: warning: qscale_type is deprecated (declared at libavutil/frame.h:191) [-Wdeprecated-declarations]
[01:04] <ubitux> are these warnings still valid?
[01:06] <saste> btw what the plan for the deprecated "reference" field?
[01:07] <ubitux> we removed the usage in all the codecs
[01:07] <ubitux> it's not set anymore
[01:33] <saste> ubitux, i can backup-mentor the inverse telecine gsoc task if Daemon404 is not available for that
[01:34] <ubitux> i will likely remove it
[01:34] <saste> are you going to do it yourself?
[01:34] <ubitux> Derek said it's trivial and a 2-3 days work, so i took the challenge...
[01:34] <saste> ok
[01:34] <ubitux> of course it will take me at least two weeks
[01:34] <ubitux> but well.
[01:35] <saste> for the subtitles task, nicolas would be a better backup-mentor than me, let's see if we can convince him
[01:36] <ubitux> i'm almost tempted to make the subtitles thing the integration within libavfilter
[01:36] <saste> too bad we don't have a mentor for the glplay task, but maybe marton could be interested
[02:40] <michaelni> mateo`, Tjoppen do you have time to review a small patch "0306 17:37 Jason Livingsto (3.3K) [FFmpeg-devel] [PATCH] lavf/mxfdec.c: fix MXF essence body offsets when only 1 body partition" ?
[02:54] <cone-426> ffmpeg.git 03Giorgio Vazzana 07master:bcd3eb3e7a8e: lavd/v4l2: silence libv4l2 logging
[04:35] <cone-426> ffmpeg.git 03Compn 07master:7d15cd4f4a4c: changelog: add support for Monkey's Audio versions from 3.93
[04:39] <Compn> my commits are still fast foward
[04:39] <Compn> forgot what that meant / if it was important
[07:42] <wm4> is there anything known about runtime CPU detection being broken on OSX?
[11:16] <wm4> nice edit war
[11:18] <wm4> this looks like a pretty bad idea: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013#glplay
[11:18] <wm4> MPlayer uses ARB shaders which are deprecated technology
[11:18] <wm4> it introduces complexity
[11:18] <wm4> it would be better to use swscale, and output the video as RGB
[11:19] <durandal_1707> hmm? how MPlayer outputs with gl?
[11:19] <wm4> using assembly shaders
[11:20] <wm4> stuff from the 90ies
[11:20] <durandal_1707> for what?
[11:20] <wm4> yuv conversion?
[11:20] <durandal_1707> wtf
[11:20] <wm4> ?
[11:20] <durandal_1707> if that make sense colorspace conversion using shaders should be in swscale, no?
[11:21] <pigoz> doesn't sw stand for software though?
[11:22] <wm4> durandal_1707: well yes, you could use opengl in swscale internally, but that would be a big mess
[11:22] <durandal_1707> sw stands for Simply Wonderful
[11:23] <wm4> durandal_1707: in fact, a similar mess is being added to libavfilter (OpenCL)
[11:23] <durandal_1707> and what should be done instead?
[11:24] <wm4> keep things simple and robust?
[11:27] <durandal_1707> hmm there should be coverages for showspectrum/showwaves
[11:27] <pigoz> 2368 causes vda breakage as well?
[11:29] <durandal_1707> this is about autodetection at build not about working after build
[11:31] <nevcairiel> the code isnt actually broken, it just requires you to pass --enable-vdpau or --enable-dxva2 now, while before this wasnt required and auto-detected
[11:32] <durandal_1707> lol, mplayer thread on ha
[11:41] <cbsrobot_> wm4: what's wrong with osx cpu detection ?
[11:55] <wm4> cbsrobot_: it seems not to work (crashes on computers without AVX) - but I don't have OSX to test
[13:34] <xlinkz0> Where does the pb name come from in here : AVFormatContext :: pb ?
[13:43] <cone-359> ffmpeg.git 03Reimar Döffinger 07master:23426987fa20: mpeg12: reduce hwaccel-related code duplication.
[13:43] <cone-359> ffmpeg.git 03Reimar Döffinger 07master:c3c3bc7ff6b2: Make ff_win32_open more robust.
[13:43] <cone-359> ffmpeg.git 03Reimar Döffinger 07master:5301aed9aeb9: vc1testenc: give muxer same name as demuxer
[13:43] <cone-359> ffmpeg.git 03Reimar Döffinger 07master:e4e4add0e3ba: Add raw VC-1 muxer to match demuxer.
[13:44] <durandal_1707> xlinkz0: depends on code
[13:45] <xlinkz0> well it's from libavf
[13:45] <xlinkz0> http://ffmpeg.org/doxygen/trunk/structAVFormatContext.html#a1e7324262b6b78522e52064daaa7bc87
[13:45] <durandal_1707> it it is AVIOContext
[13:45] <durandal_1707> usually in lavf
[13:45] <xlinkz0> yeah but why is it named 'pb' , i mean what's the logic in that name?
[13:46] <xlinkz0> is it just random?
[13:46] <durandal_1707> dunno, loss of inspiration
[13:46] <xlinkz0> nice
[13:52] <Tjoppen> xlinkz0: it used to be called PutByteContext, or something like that
[13:52] <Tjoppen> hence pb
[13:52] <xlinkz0> thanks
[13:58] <xlinkz0> I don't seem to find anything in ffmpeg.c or ffplay.c about AVClass or av_class , can I assume i don't need to understand this part in order to use the API ?
[14:01] <durandal_1707> i have wip jelly-fish meter trans media filter and i get different output when using asplit
[14:02] <durandal_1707> with asplit some pixels are white when they should actually be black
[14:18] <cone-359> ffmpeg.git 03Xi Wang 07master:eba1ff31304e: atrac3: avoid oversized shifting in decode_bytes()
[14:18] <cone-359> ffmpeg.git 03Xi Wang 07master:8425d693eefb: flacdec: simplify bounds checking in flac_probe()
[14:18] <cone-359> ffmpeg.git 03Xi Wang 07master:ca6c3f2c53be: lzo: fix overflow checking in copy_backptr()
[14:18] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:aef816f957ee: Merge commit 'ca6c3f2c53be70aa3c38e8f1292809db89ea1ba6'
[14:31] <durandal_1707> how should i name filter that acts as stereo/phase scope?
[14:32] <durandal_1707> i plan to add multichannel support to which would than be like jelly-fish meter
[14:32] <durandal_1707> but that is obviously trademark
[14:56] <durandal_1707> does max/min_samples still works?
[14:57] <durandal_1707> it is bad idea for each filter to have own fifo logic
[15:22] <ubitux> durandal_1707: i'm going to send a patch for this in a moment
[15:22] <ubitux> it's broken in some situations
[15:48] <cone-359> ffmpeg.git 03Anton Khirnov 07master:aa3c77998404: lavf: sanity check size in av_get/append_packet().
[15:48] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:e066fb54cb6f: Merge commit 'aa3c77998404cc32233cb76e961ca27db8565459'
[15:52] <durandal_1707> how you set default for RATIONAL in opt table?
[15:56] <cone-359> ffmpeg.git 03Anton Khirnov 07master:556aab8f11b0: lavfi: use designated initializers in avfilter_class
[15:56] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:18369967a56d: Merge commit '556aab8f11b045a21182eee32413aa78d5c8539b'
[16:07] <cone-359> ffmpeg.git 03Clément BSsch 07master:3b2b636a2ad5: lavfi: add perms and aperms filters.
[16:07] <cone-359> ffmpeg.git 03Clément BSsch 07master:8a0187e43d22: fate: test both direct and indirect paths in hqdn3d and gradfun.
[16:15] <cone-359> ffmpeg.git 03Anton Khirnov 07master:42c7c61ab258: avfiltergraph: replace AVFilterGraph.filter_count with nb_filters
[16:15] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:ecade984ac3c: Merge commit '42c7c61ab25809620b8c8809b3da73e25f5bbaaf'
[16:18] <cone-359> ffmpeg.git 03Clément BSsch 07master:9f1667ab647c: fate: test both direct and indirect paths in hue filter.
[16:24] <cone-359> ffmpeg.git 03Clément BSsch 07master:e1b1092755ba: fate: test both direct and indirect paths in delogo filter.
[16:32] <ubitux> haiku doesn't like h264_qpel
[16:32] <cone-359> ffmpeg.git 03Anton Khirnov 07master:dd74e3ef339e: avfiltergraph: use sizeof(var) instead of sizeof(type)
[16:32] <cone-359> ffmpeg.git 03Anton Khirnov 07master:ef4d34aa7ee7: filters.texi: restore mistakenly removed section name for noformat
[16:32] <cone-359> ffmpeg.git 03Anton Khirnov 07master:9676b9a2cdc4: AVOption: remove an unused function parameter.
[16:32] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:b64077bebe1f: Merge commit '9676b9a2cdc4a90611188fc48d8d388e427997c5'
[16:34] <ubitux> seems there are also all kind of crashes in h264 tests (dragonegg ones)
[16:39] <durandal_1707> using AV_OPT_TYPE_RATIONAL is broken
[16:40] <durandal_1707> denominator is some negative number, when it should be 1
[16:42] <ubitux> random fail detected with vp8-test-vector-010 and threads=8
[16:43] <ubitux> seems there are a bunch of things to fix currently :p
[16:43] <nevcairiel> did you expect otherwise? :)
[16:44] <ubitux> not really :p
[16:44] <cone-359> ffmpeg.git 03Anton Khirnov 07master:4d67ff8e8e3f: AVOptions: fix using named constants with child contexts.
[16:44] <cone-359> ffmpeg.git 03Anton Khirnov 07master:e4a7b2177d14: vf_showinfo: remove its useless init function
[16:44] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:7fff5781b6a9: Merge commit 'e4a7b2177d14678ae240edcabaacfe2b14619b7b'
[16:51] <ubitux> durandal_1707: see [PATCH 2/3] lavfi/buffersink: loop until the sink fifo get filled.
[16:51] <ubitux> (the min/max samples thing)
[16:58] <cone-359> ffmpeg.git 03Anton Khirnov 07master:f4281f457194: asrc_anullsrc: do not set samplerate and channel layout explicitly
[16:58] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:afb3fb335265: Merge commit 'f4281f457194a6a4489fbd7423e2ab2e13c6d4d9'
[17:01] <durandal_1707> wtf something is corrupting my filter private data
[17:01] <durandal_1707> evil thing is evil
[17:02] <durandal_1707> and that happens with initialization
[17:03] <cone-359> ffmpeg.git 03Anton Khirnov 07master:c2b9bd97f549: asrc_anullsrc: return EOF, not -1
[17:03] <cone-359> ffmpeg.git 03Anton Khirnov 07master:4750b05d67fd: af_join: do not leak input frames.
[17:03] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:946cbf04ee95: Merge remote-tracking branch 'qatar/master'
[17:12] <durandal_1707> huh, config_props for inlink is called before init()
[17:12] <ubitux> i doubt it
[17:13] <durandal_1707> i added log
[17:13] <durandal_1707> one in config_props have big negative .den, one in filter_frame is fine
[17:15] <ubitux> init
[17:15] <ubitux> config input
[17:15] <ubitux> seems to be in correct order here.
[17:15] <durandal_1707> where i'm supposed to change max/min_samples?
[17:16] <ubitux> config input is a good place
[17:16] <ubitux> iirc i had problems doing it in query_formats
[17:16] <durandal_1707> i'm doing it in config_input
[17:16] <ubitux> (most likely because of auto inserted filters breaking the links)
[17:16] <ubitux> durandal_1707: and it doesn't work?
[17:17] <durandal_1707> hmm, ffplay inserts some crop crap for whatever reason
[17:17] <ubitux> durandal_1707: did you check patch 1 & 2 from the 3-patch patchet i recently sent?
[17:17] <durandal_1707> ubitux: i doubt that resolves this
[17:17] <ubitux> i don't know what's your problem
[17:17] <ubitux> it's just an example of usage of that min max samples thing
[17:18] <ubitux> which you can compare against
[17:18] <durandal_1707> i have error in config_input - value that is supposed to be set is not
[17:19] <durandal_1707> and if i change order in my priv ctx i get different results
[17:20] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:07d4f557e505: append_packet_chunked: Remove unused initialization.
[17:20] <cone-359> ffmpeg.git 03Hendrik Leppkes 07master:a77f45370368: lavfi/avcodec: deprecate remainders of the avcodec glue code
[17:21] <durandal_1707> you can try it in jfmeter branch
[17:22] <cone-359> ffmpeg.git 03Nicolas George 07master:639a9e21a63a: ffmpeg_opt: add OPT_INPUT to -fix_sub_duration and -canvas_size.
[17:39] <durandal_1707> i recompiled, and numbers are some big numbers
[17:43] <durandal_1707> different input, now everything is 0
[17:52] <durandal_1707> if i add ctx to log it shows: [auto-inserted resampler 0 @ 0x29809440]
[17:52] <durandal_1707> or amovie, for another file
[17:53] <durandal_1707> so i'm using wrong ctx, hence wrong private data
[17:53] <durandal_1707> but why this happens?
[18:04] <ubitux> missing AVClass?
[19:02] <wm4> on the mailing list, Nicolas George says that -f lavfi -i graph is less efficient than -filter_complex
[19:02] <wm4> how so?
[19:02] <nevcairiel> respond on the list and ask?
[19:02] <wm4> if it's about passing the image, this should be efficient now, or could be made efficient
[19:02] <wm4> no I'm afraid someone will bite me
[19:03] <wm4> for asking too many dumb questions
[19:11] <durandal_1707> ubitux: AVClass is present
[19:16] <durandal_1707> can someone enlight me why nicolas posted asinesrc filter?
[19:19] <ubitux> durandal_1707: i think it was motivated by bitexactness, to replace audiogen stuff maybe
[19:21] <durandal_1707> audiogen?
[19:21] <Daemon404> for fate maybe?
[19:21] <Daemon404> it's a bad idea to rely on lavfi for that though.
[19:22] <durandal_1707> for what?
[19:22] <Daemon404> asynth tests
[19:22] <Daemon404> it uses generated audi
[19:22] <Daemon404> o
[19:22] <ubitux> durandal_1707: ask the guy, i may be wrong
[19:23] <Daemon404> well
[19:23] <Daemon404> you could use a sine generator for like
[19:23] <Daemon404> smpte bars
[19:23] <Daemon404> they require such audio
[19:29] <durandal_1707> there is aevalsrc
[19:42] <durandal_1707> if i see this: .88 A-V:  0.000 fd=1176 aq=    0KB vq= 1758KB sq=    0B f=0/0
[19:43] <durandal_1707> and fd is increasing steadily and fast, it starts to eats all of memory
[19:45] <durandal_1707> why showwaves define MAX_INT16 when there is INT16_MAX?
[20:21] <durandal_1707> ffplay -f lavfi -i "aevalsrc=sin(220*PI*t) : cos(220*PI*t),asplit [a] [out0],[a]jfmeter=s=800x600 [out1]"
[20:24] <ubitux> durandal_1707: github branch up-to-date?
[20:24] <durandal_1707> yes
[20:25] <durandal_1707> it's trivial, i plan to add some other stuff too, when i find how to make multichannel stuff
[20:55] <cone-359> ffmpeg.git 03Carl Eugen Hoyos 07master:75c7e4583f4f: Do not (re-)set libx264 parameter b_tff if interlaced encoding was not requested.
[22:02] <wm4> I don't understand what's the use case for 16 bit yadif
[22:03] <Compnn> idiot 16bit interlacing? :P
[22:03] Action: Compnn makes funny
[22:03] <durandal_1707> you dont have 16 bit interlaced files, poor you
[22:05] <wm4> what about 14 bit interlaced files
[22:05] <wm4> Daemon404 would get a seizure
[22:05] <durandal_1707> you think there is no such files?
[22:08] <wm4> I'm just a bit skeptic of the output quality
[22:09] <Daemon404> i have 10-bit interlaced files
[22:09] <Daemon404> i wrote my own plugin to apply field matches
[22:09] <Daemon404> and i get thise after i convrt it to 8-bit to collect metrics
[22:09] <Daemon404> no good deint tho
[22:10] <nevcairiel> why would 10-bit yadif be worse than 8-bit yadif
[22:12] <durandal_1707> there is no good deinterlacer for 10bits on whole planet?
[22:14] <wm4> I thought if you want 10 bit (super extra quality), you wouldn't want to use a relatively bad deinterlacer like yadif
[22:14] <wm4> not to say that yadif is bad
[22:14] <wm4> I just wonder why that person puts effort into extending color depth
[22:15] <durandal_1707> you just sad it is relatively bad thus bad
[22:15] <durandal_1707> is there good deinterlacer in lavfi?
[22:15] <J_Darnley> wm4: I was doing it (mostly) as a learning exercise
[22:15] <wm4> there are really good ones in avisynth, I suppose
[22:16] <durandal_1707> port them
[22:16] <wm4> J_Darnley: oh, ok
[22:17] <wm4> durandal_1707: I think vdpau's deinterlacer is quite good
[22:17] <wm4> but dunno
[22:19] <michaelni> J_Darnley, contributors get voice in ffmpeg-devel :)
[22:21] <durandal_1707> i added bunch of them but they somehow get lost, so i stoped bothering to reapply them when i find that they do not care at all to register
[22:21] <durandal_1707> or they remove it once i'm not logged like wm4
[22:22] <wm4> wut
[22:24] <wm4> what did I ever contribute
[22:24] <nevcairiel> noise
[22:24] <nevcairiel> :D
[22:24] <wm4> I don't think that counts
[22:25] <durandal_1707> anonymous one i found really important fix
[22:25] <nevcairiel> anyhow, i think yadif is acceptable quality for real-time deinterlacing, the really good ones in avisynth are too slow for realtime playback
[22:25] <wm4> durandal_1707: you mean that libmpcodecs sed party? ew
[22:25] <durandal_1707> yes
[22:27] <durandal_1707> but adding really good one is useful in scenario like one time reencoding and playing multiple times
[22:27] <wm4> nevcairiel: I agree, I just had this association of high bit depth with semi-professional use
[22:27] <durandal_1707> or is it really impossilbe to write real time good deinterlacer today?
[22:28] <Daemon404> nevcairiel, nnedi can do realtime on newer cpus
[22:28] <Daemon404> but yeah.
[22:28] <nevcairiel> the GPUs deinterlacers are also pretty good, better than yadif, but not as good as the best you can get in other software, but hard to use =p
[22:29] <Daemon404> also not available everywhere
[22:29] <wm4> nevcairiel: hard to use?
[22:29] <nevcairiel> well it requires some effort to interface with the gpu
[22:29] <wm4> seems relatively simple on vdpau (you just get a mess with frame handling)
[22:30] <nevcairiel> Daemon404: QTGMC is based on nnedi isn't it? last i heard it can barely do 720p processing in realtime
[22:30] <Daemon404> nevcairiel, its far more than nnedi
[22:30] <Daemon404> it has mocomp etc
[22:30] <Daemon404> mocomp = slow
[22:30] <nevcairiel> nnedi alone is just a scaler, i thought
[22:30] <Daemon404> yea
[22:30] <nevcairiel> no temporal, just spatial interpolation
[22:31] <Daemon404> thats qhat qtgmc does
[22:31] <Daemon404> what*
[22:31] <nevcairiel> i would think some temporal influence can help
[22:31] <Daemon404> nevcairiel, qtgmc almost runs natively on linux
[22:31] <Daemon404> one of the big things holding it uo is a port of
[22:31] <Daemon404> http://chromashift.org/RemoveGrain.cpp
[22:31] <Daemon404> :>
[22:31] <wm4> ow
[22:33] <nevcairiel> gotta love avisynth plugins
[22:33] <nevcairiel> msvc inline assembly deluxe
[22:33] <Daemon404> yea
[22:33] <nevcairiel> i also dont understand why people prefix everyline with __asm
[22:33] <nevcairiel> you can make blocks, you know
[22:33] <Daemon404> i blame the fact that theyre EEs
[22:33] <Daemon404> <_<
[22:34] <wm4> so, uh, aren't QTGMC and RemoveGrain separate plugins? how does QTGMC use it?
[22:34] <Daemon404> QTGMC is a script
[22:34] <nevcairiel> QTGMC is basically a script that combines different avisynth plugins to do its job
[22:35] <Daemon404> it uses many plugins
[22:35] <Daemon404> someone even ported it to vapoursynth
[22:35] <Daemon404> but it relies on va[oursynths avisynth plugin loaded for a few
[22:35] <wm4> ok, I've been wondering if vapoursynth could be used without scripting, but this confirms it can not (in practice)
[22:35] <Daemon404> it can
[22:35] <Daemon404> but the reason it has scirptes like ths
[22:35] <wm4> but then you can't use QTGMC
[22:36] <Daemon404> is lso what makes it great
[22:36] <Daemon404> aka letting people easily write useful things
[22:36] <Daemon404> without C
[22:36] <wm4> what about -filter_complex
[22:36] <Daemon404> thats one reason avisynth has prospered
[22:36] Action: wm4 runs
[22:36] <Daemon404> hahahaha
[22:36] <Daemon404> ha.
[22:36] <nevcairiel> thats also some kind of script
[22:36] <nevcairiel> just ugly and terrible syntax
[22:37] <wm4> the annoying thing about vapoursynth is that it apparently uses cython, and the scripting API is somehow separate from the "stable" VS API
[22:37] <Daemon404> it has luajit bindings too
[22:37] <Daemon404> if you dont like pyhton
[22:37] <nevcairiel> i dont think anything about VS is truely stable yet
[22:37] <Daemon404> nevcairiel, well its mroe stable than lavfi
[22:37] <wm4> Daemon404: then you'd have to port QTGMC to Lua
[22:37] <Daemon404> and it has ABI stability
[22:37] <Daemon404> wm4, trivial
[22:38] <Daemon404> i think the unix world will hate VS anyway
[22:38] <Daemon404> since you can use it without an in-depth knowledge of C
[22:38] <Daemon404> and POSIX
[22:38] <nevcairiel> but python is big with hipsters
[22:38] <Daemon404> hipsters are bsd man
[22:38] <Daemon404> darwin~
[22:38] <Daemon404> ro
[22:39] <Daemon404> s/unix/linux/ above
[22:39] <Daemon404> makes more sense that way
[22:39] <wm4> I see: https://github.com/tgoyne/luasynth
[22:39] <wm4> which was basically abandoned before it really started
[22:39] <nevcairiel> i was just wondering what counts as unix these days
[22:39] <Daemon404> wm4, abonded how?
[22:39] <Daemon404> it works entirely
[22:40] <wm4> a bunch of commits in 2 days, then a week later another 3 commits, then nothing
[22:40] <Daemon404> and
[22:40] <Daemon404> ?
[22:41] <wm4> and the README: " It is currently a hacked together mess which was mostly created in a single sitting with very little thought, and will probably change a lot in the future if it continues to be developed."
[22:41] <Daemon404> oh you could actuallyl ook at its code
[22:41] <Daemon404> and try it
[22:41] <wm4> in any case, a nice proof of concept
[22:41] <Daemon404> or*
[22:41] <Daemon404> rather than make random judgements based on 0 info
[22:41] <Daemon404> anyway, imho
[22:41] <Daemon404> any filter framewor with 0 scripting
[22:41] <Daemon404> is shit.
[22:41] <nevcairiel> the hacked together messes usually have a much longer lifetime then "designed" software. :P
[22:42] <nevcairiel> anyhow
[22:42] <wm4> worse is better etc.
[22:42] Action: nevcairiel goes back to converting his demuxing to tep
[22:42] <Daemon404> heh
[22:42] <Daemon404> man i love using libav* libs
[22:43] <Daemon404> i have to constantly rewrite my code
[22:43] <Daemon404> over and over
[22:43] <Daemon404> due to api changes
[22:43] <wm4> it's more fun this way
[22:43] <nevcairiel> i don't mind it, helps me to find reasons to refactor and cleanup
[22:43] <wm4> don't forget the frequent sed sessions due to useless cosmetic changes to identifier naming
[22:43] <nevcairiel> plus i don't live in linux-shared-library hell with hundreds of versions that people want to use
[22:43] <Daemon404> i only care about master
[22:43] <nevcairiel> and people called it dll-hell on windows
[22:44] Action: nevcairiel giggles
[22:44] <wm4> yeah, you just have to deal with random mingw breakages ;D
[22:44] <Daemon404> nevcairiel, ld.so is lulz
[22:44] <Daemon404> indeed
[22:44] <Daemon404> hell even libc is lulz on *nix
[22:44] <nevcairiel> the 2.0 release branch of mingw has been pretty reliable for me
[22:44] <nevcairiel> i stopped using trunk because of the random breakages
[22:44] <Daemon404> 95% 3r party binaries for *nix ship their own versions of every lib they need
[22:44] <Daemon404> and use rpath
[22:44] <Daemon404> :>
[22:45] <nevcairiel> i wonder if i should risk gcc 4.8 :P
[22:45] <Daemon404> no
[22:45] <Daemon404> it still miscompiles tons of stuff
[22:46] <Daemon404> oh wow
[22:46] <Daemon404> 4.8 is out
[22:46] <Daemon404> lets see how much the release is broken
[22:46] <nevcairiel> i didnt just make a random comment
[22:46] <nevcairiel> it was released today i think
[22:46] <Daemon404> time to start the satanic ritual of compiling a cross canadian gcc
[22:47] <wm4> Daemon404: all things considered, libav* is still pretty awesome, or you wouldn't actually see yourself forced to use it
[22:47] <nevcairiel> i usually skip the .0 gcc versions
[22:47] <Daemon404> it's the only option
[22:48] <Daemon404> that doesnt mean its api and constant chanegs are "awesome"
[22:48] <Daemon404> or that it's api isnt way too goddamn low level
[22:49] <nevcairiel> lol, gcc4.8 supports intel broadwell, they are up in the future :p
[22:49] <wm4> there are many weird things in its API, but it's actually quite simple
[22:49] <iive> you know where most of api breakage comes from 
[22:49] <Daemon404> wm4, its not so simple when tehre are so many pitfalls
[22:50] <wm4> the kind of bad thing is that theres no understanding among ff/l. devs that these weird things are bad
[22:50] <wm4> and you get just read the docs, patch welcome, etc.
[22:50] <Daemon404> because the peopel who design teh apis
[22:50] <nevcairiel> iive: not doing any api changes is also no solution, there is many things that really need cleaning or enhancement
[22:50] <Daemon404> DONT USE THEM
[22:50] <Daemon404> or have implicit knowledge of its inner workings
[22:51] <nevcairiel> haha, i like this, gcc has its own cpu runtime detection now, ... if (__builtin_cpu_supports("ssse3")) { ... } .. :d
[22:51] <nevcairiel> i should read these things more often
[22:52] <Daemon404> more unportable code!
[22:52] <Daemon404> go!
[22:52] <nevcairiel> a nice feature is that you can have several functions with the same name, with a special attribute, and gcc then decides which to run based on cpu features available
[22:52] <nevcairiel> its a neat feature at least :P
[22:52] <Daemon404> neat
[22:52] <Daemon404> but locks you into gcc
[22:53] <wm4> Daemon404: what's better, unportable code due to gcc intrinsics, or deadly shit code due to attempts at custom CPU detection
[22:53] <nevcairiel> "Windows MinGW-w64 targets (*-w64-mingw*) require at least r5437 from the Mingw-w64 trunk."
[22:53] <nevcairiel> interesting
[22:53] <iive> nevcairiel: it would have been good if at least half of the api breakage had any real improvements :|
[22:53] <Daemon404> well the most recent api breakage had massive improvements
[22:53] <Daemon404> at least.
[22:53] <nevcairiel> indeed
[22:54] <wm4> and that one was actually backwards compatible
[22:54] <nevcairiel> for the most part anyway
[22:54] <Daemon404> oh nevcairiel 
[22:54] <Daemon404> did we finally nuke #define CodecID
[22:54] <Daemon404> with TEP
[22:54] <nevcairiel> yes
[22:54] <Daemon404> \\o/
[22:54] <wm4> nevcairiel: weren't these bugs
[22:54] <durandal_1707> and still nobody posted results on phoronix
[22:54] <Daemon404> lol phoronix
[22:55] <Daemon404> that site is so useless
[22:55] <wm4> Daemon404: it's very lucrative
[22:55] <nevcairiel> wm4: i suppose you can call them that, didnt get fixed yet at least (some of them anyway)
[22:55] <durandal_1707> i mean nobody cares if performance droped with recent evil mess
[22:55] <Daemon404> wm4, indeed
[22:55] <Daemon404> durandal_1707, a slight perf degredation is worth it for refcounted frames
[22:55] <Daemon404> people can shut teh fuck up with microopts
[22:55] <nevcairiel> performance didnt go down for me
[22:56] <Daemon404> or that too
[22:56] <nevcairiel> in fact, because of tep, i made stuff like 20% faster because i can now use proper multithreading
[22:56] Action: Daemon404 brb food
[22:56] <nevcairiel> decoding on one thread and processing on another, without worrying about the frames going invalid
[22:56] <wm4> nice
[22:57] <nevcairiel> granted, its not that big for already multi-threaded codecs like h264
[23:02] <nevcairiel> what, why did my boxes not build stuff
[23:07] <nevcairiel> great, one job was stuck <.<
[23:07] <Daemon404> nevcairiel, my favourite is when i re-enable the crash dialogue to o soem debugging
[23:07] <Daemon404> and forget ti disable it
[23:07] <Daemon404> and fate stalls on crash
[23:08] <nevcairiel> soemtimes it manages to leave the .lock file in the dir, and when that happens it always quits there and doesnt run the other jobs
[23:08] <nevcairiel> silly thing
[23:08] <Daemon404> that too
[23:08] <nevcairiel> i bet its this broken mingw-make crash
[23:08] <Daemon404> happens to me on linux too
[23:29] <cone-359> ffmpeg.git 03James Darnley 07master:17e7b495013d: yadif: x86 assembly for 16-bit samples
[23:29] <cone-359> ffmpeg.git 03James Darnley 07master:0a5814c9ba23: yadif: x86 assembly for 9 to 14-bit samples
[23:29] <cone-359> ffmpeg.git 03James Darnley 07master:7976d92dacc1: yadif: cosmetic indentation from previous commits
[23:29] <cone-359> ffmpeg.git 03James Darnley 07master:1d3b14cac2f0: yadif: remove repeated check on width
[23:29] <cone-359> ffmpeg.git 03James Darnley 07master:c9a51c29fc9d: yadif: remove an 'm' from the LOAD macro definition
[23:50] <cone-359> ffmpeg.git 03Clément BSsch 07master:8d84e90c9bf1: lavfi/delogo: 10l forgotten trailing NULL in shorthand.
[23:53] <cone-359> ffmpeg.git 03Hendrik Leppkes 07master:d8dccf69ff2d: lavfi: let gcc realign the stack on public graph driving functions
[00:00] --- Sun Mar 17 2013