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

[burek]

[00:11] <llogan> what did roger do this time?
[00:12] <Daemon404> dunno
[00:12] <Daemon404> but i bet he was framed
[00:13] <llogan> qatari spies!
[00:13] <llogan> (praise muhammed)
[00:13] <CIA-56> ffmpeg: 03Marton Balint 07master * rbd14d845e9 10ffmpeg/ffplay.c: 
[00:13] <CIA-56> ffmpeg: ffplay: factor display rectangle calculation to its own function
[00:13] <CIA-56> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[00:13] <CIA-56> ffmpeg: 03Marton Balint 07master * r255c7bb183 10ffmpeg/ffplay.c: 
[00:13] <CIA-56> ffmpeg: ffplay: make initial window size calculation based on aspect ratio
[00:13] <CIA-56> ffmpeg: Fixes ticket #291.
[00:13] <CIA-56> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[00:13] <CIA-56> ffmpeg: 03Marton Balint 07master * r81f26d6990 10ffmpeg/ffplay.c: 
[00:13] <CIA-56> ffmpeg: ffplay: ensure that pictq_prev_picture never fills the picture queue
[00:13] <CIA-56> ffmpeg: It was theoretically possible for pictq_prev_picture to fill the picture queue
[00:13] <CIA-56> ffmpeg: which may have caused problems when a write to the queue was still in progress.
[00:13] <CIA-56> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[00:13] <CIA-56> ffmpeg: 03Marton Balint 07master * r99b01e458c 10ffmpeg/ffplay.c: 
[00:13] <CIA-56> ffmpeg: ffplay: simplify picture allocation
[00:13] <CIA-56> ffmpeg: This also makes sure the aspect ratio of the picture is set before allocating
[00:13] <CIA-56> ffmpeg: the picture, this way video_open can calculate with the correct aspect ratio
[00:13] <CIA-56> ffmpeg: even for the first frame.
[00:13] <CIA-56> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[00:47] <gnafu> Daemon404: Ha!  I just got that.
[00:55] <Daemon404> :P
[01:55] <llogan> Daemon404: did you ever compile the list of differences between libnut and ffmpeg's nut implementations?
[01:56] <llogan> because i was wondering the same thing not too long ago. not that i did anything about it because i am an information leech.
[05:26] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r23e9e5c7d9 10ffmpeg/libavformat/rtmpproto.c: 
[05:26] <CIA-56> ffmpeg: rtmpproto: reorder some expressions to fix compilation with clang without optimizations
[05:26] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:26] <CIA-56> ffmpeg: 03Derek Buitenhuis 07master * r0c5fe2f0da 10ffmpeg/libavutil/bprint.c: 
[05:26] <CIA-56> ffmpeg: FATE/bprint: Convert a VLA to a normal array
[05:26] <CIA-56> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[05:26] <CIA-56> ffmpeg: Reviewed-by: Nicolas George <nicolas.george at normalesup.org>
[05:26] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[08:46] <Tjoppen> ooh, what fun. no fftools/avtools handle MOVs with EDLs correctly
[08:48] <Compn> is old bug
[08:48] <Compn> but for serious, mov edl is so horrible it should just be forgotton
[08:49] <Tjoppen> it seems fairly straightforward to me. ffmpeg needs at least the ability to cut frame-accurately
[08:49] <Compn> sure
[08:49] <Compn> and edl/playlist would be nice
[08:49] <Compn> transcode has frame accuracy
[08:49] <Compn> you should bug saste to make the -vf framestep filter able to seek to a frame
[08:49] <Tjoppen> seeking doesn't, unless that changed recently. you only get the nearest I/IDR-frame
[08:50] <Compn> well framestep doesnt seek but decodes in order until it hits the frame number
[08:50] <Compn> at least in mplayer...
[08:51] <Tjoppen> interesting.. of course, decoding a MOV file with several EDL entries is going to be fun
[08:51] <Tjoppen> it wouldn't be too hard with some kind of random access filter
[08:52] <Compn> a filter that accepts edl could work
[08:52] <Compn> but probably you want to make sure its acceptable api wise by michael/saste
[08:52] <Tjoppen> I see
[08:53] <Compn> what software supports mov edl ?
[08:53] <Compn> final cut pro ?
[08:53] <Tjoppen> fcp, qt
[08:53] <Compn> quicktime
[08:53] <Compn> big list :)
[08:53] <Tjoppen> it is if one of your clients use either of them
[08:54] <Compn> true true
[08:54] <Compn> cant you use qt-tools to output a finished edl version of the file ?
[08:54] <Tjoppen> dunno. never heard of that
[08:54] <Compn> basically, command line quicktime 
[08:55] <Tjoppen> ah. I presume it'd be possible to transcode such files to normal files then
[08:55] <Compn> err
[08:55] <Compn> http://www.3am.pair.com/QTCoffee.html
[08:55] <Compn> QTCoffee 1.2.5 is a set of command-line Mac OS X utilities for manipulating QuickTime movies and other QuickTime readable media (AVIs, MPEGs, as well as audio files such as MP3s and AACs). Features include:
[08:55] <Compn> quite possibly
[08:56] <Tjoppen> since it can play it correctly it should be able to transcode
[08:56] <Tjoppen> here's a wtf: fcp doesn't use the qt library
[08:56] <Compn> right, thats what i meant
[08:56] <Compn> use the quicktime stuff to get rid of the edl requirement :P
[08:56] <Tjoppen> I just might
[08:56] <Compn> quicktime code is so old, fcp decided not to use it :P
[08:56] <Compn> or something, probably
[08:58] <Tjoppen> more fun: MXF with EDLs
[08:58] <Tjoppen> I've yet to run into them, but it's possible. they can be nested too
[08:58] <Tjoppen> most likely. but it does result in files playing fine in qt not working in fcp
[09:07] <cbsrobot-> Tjoppen: you may try ffmbc
[09:08] <cbsrobot-> there are some subtile differences between the two mov demuxers
[09:08] <cbsrobot-> sometimes it can handle it, sometimes it crashes :-D
[09:08] <Tjoppen> yep, I know of it
[10:42] <Tjoppen> speaking of EDL stuff, mov.c messes with timestamps when elst is set. it shifts everything backward, which seems kinda.. dumb
[11:22] <vivienschilis> Hi, does someone know where  (which source file) handles the "default stream mapping"?
[11:27] <vivienschilis> Oh I found it
[13:07] <michaelni> Tjoppen, TimNich, please review: [FFmpeg-devel] [PATCH] mxfdec: set audio packet pts
[13:11] <Tjoppen> I think I re-tested that and it messed up timestamps pretty bad
[13:35] <mateo`> hi
[13:36] <mateo`> about the mxfdec patch, i wasn't able to work it since last time (was on vacations)
[13:39] <mateo`> i think values from t->ptses should not be used for audio packets since this reorder only apply for video frames (b-frames and p-frames) but i'm not sure about that :(
[14:07] <Tjoppen> mateo`: correct
[14:26] <Tjoppen> mateo`: it might be possible to simply change stream time base to the samplerate
[14:27] <Tjoppen> the problem stems from ntsc not having constant number of samples per frame
[14:31] <mateo`> sure but since all audio samples from a packet is synchronised with one frame (both from same edit unit). It might be possible to synchronise a/v just by setting audio pkt pts with video pkt pts value. I'm new to pts/dts stuff so maybe i am wrong&
[14:34] <Tjoppen> no you cannot. audio isn't reordered
[14:40] <mateo`> I meant video pkt pts takes its value from t->ptes (reorder), and the audio pkt pts takes its value from the current edit unit value
[14:45] <Tjoppen> the problem is ntsc audio frames are 1601 or 1602 samples, which doesn't round nicely when stream->time_base = 1001/30000
[14:45] <Tjoppen> leading to duration = 0 and chaos
[14:47] <Tjoppen> letting stream->time_base = sample_rate solves this. however, computing which edit unit a seek needs to go to or computing the exakt dts of an audio packet becomes problematic
[14:58] <mateo`> Tjoppen: ok, anyway setting the audio pkt pts as i suggested seems to improve the playback of NTSC files
[15:02] <Tjoppen> ugh. it's wrong
[15:07] <mateo`> :(
[15:09] <Tjoppen> general idea for proper solution: switch to using sample_rate for time_base, count samples rather than relying on EditUnit (due to the aforementioned rounding issue)
[15:09] <Tjoppen> meaning extrapolate dts/pts. also, make sure this extrapolation works properly after a seek
[15:09] <Tjoppen> I might have time to work on something like that later this week
[15:15] <mateo`> I'll try to work on it too since i want to figure out where the rounding issues appear in the code.
[17:17] <mateo`> Tjoppen: works way better by using 1/48000 as timebase and using sample count for the pts value.
[17:19] <Tjoppen> \o/
[17:19] <mateo`> the last problem is making this work with seeking, héhé
[17:19] <Tjoppen> yeah, you won't get the same value if you seek to an edit unit as if you demux to it
[17:20] <Tjoppen> unless you make assumptions about the muxer, which is possible in this case (look at the 1602,1601,1602,1601,1602 pattern in mxfenc.c)
[17:20] <Tjoppen> for general files it can be off by a couple of samples. not much to do about that though - MXF sucks
[17:21] <mateo`> i need to recompute the number of samples according to the current edit unit in case of seeking
[17:21] <av500> wouldnt it be off by at most 1 sample?
[17:22] <mateo`> yes
[17:44] <Tjoppen> correct
[17:47] <av500> so whats the big deal? :)
[17:52] <Tjoppen> it's incorrect
[20:05] <saste> the flvenc muxer doesn't preserve input timestamps (cuts the initial offset off)
[20:06] <saste> the behavior seems related to the recent changes by justin
[20:06] <saste> should I create a ticket for that?
[20:06] <saste> or is it supposed to be a "feature"?
[20:10] <michaelni> in what situation does the user want to preserve the offset ?
[20:12] <saste> michaelni, I'm remuxing a file and I need to preserve the original timestamp information
[20:13] <saste> get to go
[20:16] Action: michaelni still wonders why you need to preserve it ...
[20:16] <michaelni> in what case does it make a difference ?
[21:08] <Daemon404> nevcairiel, did you ever poke that crash i sent you further?
[21:08] <Daemon404> im kind of baffled
[21:09] <nevcairiel> i would put up some breakpoint and manually run the test
[21:09] <Daemon404> no idea where id drop one in :P
[21:10] <Daemon404> hardly anything left in ffmpeg to fix for msvc...
[21:10] <Daemon404> that crash, the va_copy bikesheddign on libav's ML
[21:10] <Daemon404> ffprobe
[21:10] <Daemon404> cant think of much else
[21:11] <nevcairiel> get compiling working, and i'll look into the crash =p
[21:11] <nevcairiel> (working = in git)
[21:11] <Daemon404> you only need to add one line to config.h
[21:11] <Daemon404> and compiling works
[21:11] <Daemon404> :P
[21:11] <nevcairiel> oh well, maybe another day
[21:11] <nevcairiel> tomorrow is cinema day, not at home in the evening
[21:11] <Daemon404> oh and remove that cruft from bprint
[21:11] <Daemon404> lul
[21:11] <nevcairiel> and today its already late
[21:12] <nevcairiel> also, i really should be working on lav again <.<
[21:12] <Daemon404> on the plus side
[21:12] <Daemon404> i brought my mac mini to work today
[21:12] <Daemon404> so i can ste up fate
[21:13] <nevcairiel> my ultrabook is at work, and i can remote desktop into my fate server
[21:13] <Daemon404> well its more that i do not have room in my apt
[21:13] <Daemon404> to set it up
[21:30] <nevcairiel> isnt a mac mini rather small? =P
[21:30] <Daemon404> nevcairiel, i mean to wire up up to the router
[21:32] <nevcairiel> ooh MS finally released vs2012 express
[21:32] Action: nevcairiel goes to setup a test env
[21:32] <Daemon404> is the pro ver out yet
[21:32] <Daemon404> i.e. on msdnaa
[21:32] <nevcairiel> no idea
[21:32] <JEEB> Daemon404, it should be
[21:32] Action: Daemon404 checks his msdn thingy
[21:32] <nevcairiel> the commercial image has been out for a while
[21:32] <Daemon404> :o
[21:32] <JEEB> I already saw it during august
[21:33] <Daemon404> cool
[21:33] <Daemon404> time to upgrade
[21:33] <nevcairiel> too bad i'm no student anymore
[21:33] <Daemon404> nevcairiel, i am, technically
[21:33] <Daemon404> until may
[21:33] <Daemon404> "student"
[21:33] <nevcairiel> i havent been for 2 years now
[21:33] <nevcairiel> not like i couldnt afford buying vs2012 pro
[21:33] <nevcairiel> still annoying :P
[21:33] <Daemon404> i can get vs pro free anyway
[21:34] <JEEB> the only derp is that msdnaa (lol dreamspark premium) has all the rc versions there still
[21:34] <JEEB> so you have to scroll through them
[21:34] <JEEB> and then finally get to the final version
[21:35] <Daemon404> lul
[21:35] <Daemon404> hmm
[21:36] <Daemon404> whats the name of that server/client thign that allows sharing kb/mouse over multipel boxes and oses
[21:36] <nevcairiel> vs2012 official launch was just today, so cut them some slack :P
[21:36] <nevcairiel> Daemon404: synergy?
[21:36] <Daemon404> yes
[21:36] <Daemon404> that one
[21:36] <ohsix> mango lassi :>
[21:38] Action: Daemon404 had one at lunch today
[21:40] <nevcairiel> oh my, they made the installer in metro design
[21:41] <JEEB> yup
[21:41] <JEEB> half of vs'12 is metro, half is old
[21:42] <nevcairiel> i saw the screenshots of the UI design after they revised it, it didnt look too bad after they went a bit back on the metro
[21:42] <JEEB> yeah
[21:42] <JEEB> and you can registry hack the SCREAMING MENUS out
[21:46] <ohsix> it's nice the menus are still nonsense & theres a ton of them though!
[22:05] <nevcairiel> my sse2 intrinsics in lav make the 2012 compiler crash :(
[22:08] <kierank> what do you intrinsics do?
[22:08] <nevcairiel> yuv 2 rgb in this case
[22:10] <kierank> oh wow you must really not like sws
[22:10] <nevcairiel> no, i do not
[22:11] <nevcairiel> either its way too slow or way too crappy quality
[22:11] <nevcairiel> there was no good middleground for yuv2rgb in it
[22:15] <nevcairiel> maybe i should get off my ass and convert it to yasm
[22:15] <nevcairiel> if i can ever figure out how to properly do that
[22:15] <Daemon404> ehe
[22:15] <Daemon404> id be appreciative
[22:15] <Daemon404> allows reuse :P
[22:15] <nevcairiel> although, i cheat for extra performance
[22:16] <nevcairiel> i have loads of C code, and the big function with the intrinsics is __forceinline
[22:16] <nevcairiel> adding the call overhead there is quite a loss of performance
[22:16] <Daemon404> how often does it get called
[22:16] <nevcairiel> once for every 8 pixels
[22:17] <nevcairiel> :D
[22:17] <Daemon404> woah
[22:17] <Daemon404> why not just write the loop in asm
[22:17] <nevcairiel> because i'm lazy, and using intrinsics allows you to avoid just that without any big performance penality? :P
[22:18] <Daemon404> and then you get
[22:18] <Daemon404> [16:05] < nevcairiel> my sse2 intrinsics in lav make the 2012 compiler crash 
[22:18] <nevcairiel> (its also not that simple, it has special cases for being on the first line, and on the left/right borders of the image because of chroma subsampling)
[22:19] <nevcairiel> i really kinda like the function the way it is
[22:19] <nevcairiel> the actual conversion is branchless because of excessive template usage
[22:19] <nevcairiel> making it really quite fast :)
[22:20] <nevcairiel> and it nicely multithreads too
[22:20] <nevcairiel> oh well i'm in no hurry to switch to 2012
[22:21] <Daemon404> do you do full chroma interpolation?
[22:21] <Daemon404> like a good boy?
[22:21] <nevcairiel> bilinear
[22:21] <Daemon404> bad boy.
[22:21] <nevcairiel> what interpolation do you consider full? :P
[22:21] <Daemon404> that is full
[22:22] <Daemon404> just a shitty interpolation algo
[22:22] <nevcairiel> i really cba to write bicubic or any of its variants for the odd case when people want to have rgb output from the decoder
[22:23] <Daemon404> lol
[22:23] <Daemon404> many renderers have crap colorspace conversion
[22:23] <nevcairiel> bilinear looks ok
[22:23] <Daemon404> ;p
[22:23] <nevcairiel> its a clear 200% scaling, which makes it so super easy
[22:24] <nevcairiel> doubling pixels is just ideal for bilinear :)
[22:24] <Daemon404> clearly you should use nnedi
[22:24] <Daemon404> :troll"
[22:24] <nevcairiel> If you make it fast enough for real time playback, i will!
[22:24] <nevcairiel> ;)
[22:24] <Daemon404> lol
[22:25] <Daemon404> huh
[22:26] <Daemon404> ffmpeg no longer outputs the libx264 report at the end of encoding?
[22:26] <Daemon404> D:
[22:26] <Daemon404> how the heck am i supposed to get my obtained bitrate
[22:26] <nevcairiel> i think someone decided to move it to another log level
[22:26] <Daemon404> -____________________-
[22:26] <nevcairiel> if that was pushed yet
[22:26] Action: Daemon404 blames ubitux
[22:27] <ubitux> meh
[22:27] <ubitux> what did i broke again?
[22:27] <Daemon404> [16:26] <@Daemon404> ffmpeg no longer outputs the libx264 report at the end of encoding?
[22:27] <Daemon404> not you likely
[22:27] <Daemon404> but you may know
[22:27] <ubitux> ah, ask saste
[22:27] <ubitux> it's a recent change in loglevel
[22:27] <Daemon404> he ran off
[22:27] <ubitux> 911519caec2346fc7728bca9840ffc000e866161
[22:28] <Daemon404> now i need to figure out how to set that
[22:28] <ubitux> -v verbose ?
[22:28] <Daemon404> -        [X264_LOG_INFO]    = AV_LOG_INFO,
[22:28] <Daemon404> +        [X264_LOG_INFO]    = AV_LOG_VERBOSE,
[22:28] <Daemon404> looks looks so retarded
[22:28] <Daemon404> >INFO
[22:28] <Daemon404> >is not actually INFO
[22:28] <ubitux> :)
[22:29] <Daemon404> the problem with that is
[22:29] <ubitux> i don't mind a revert, but either is fine with me
[22:29] <nevcairiel> i thought the commit looked wrong, but i refrained from commenting since i dont use encoders
[22:29] <Daemon404> it shits a bunch of other stuff in my log
[22:29] <Daemon404> that i dont want to see
[22:29] <Daemon404> and a lot of people parse its output
[22:30] <ubitux> if you want to revert, you should hurry
[22:30] <ubitux> there is a release incoming
[22:30] Action: Daemon404 thinks ffmpeg and libav releases are a joke
[22:30] <Daemon404> and thus i do not are
[22:30] <Daemon404> care*
[22:31] <ubitux> :)
[22:31] <ubitux> the problem is that distro are based on these releases
[22:31] <ubitux> and user use them for a long time
[22:31] <Daemon404> but i expect if i send a revert patch to the ML
[22:31] <Daemon404> ill get bikeshedding
[22:31] <ubitux> "heee it doesn't work with ffmpeg 0.5-SVN-1932"
[22:32] <ubitux> Daemon404: not from me, and there is no much ppl bikeshedding for such thing
[22:32] <Daemon404> i perosnally parse that libx264 output btw LO
[22:32] <Daemon404> :P
[22:32] <Daemon404> since if oyu output to /dev/null for pass 1
[22:32] <llogan> i've only seen 1 distro (Arch) use git head, and that was only for a short time.
[22:32] <Daemon404> frame=11984 fps= 61 q=23.0 size=       0kB time=00:08:15.36 bitrate=   0.0kbits/s
[22:32] <Daemon404> not exactly useful
[22:33] <ubitux> llogan: yeah they use the releases now
[22:33] <Daemon404> eh
[22:33] <Daemon404> arch users should be used to broken things
[22:33] <llogan> that's why it is more interesting
[22:33] <ubitux> i'm used to get things working in arch personally
[22:33] <ubitux> in comparison to a lot of other distro
[22:34] <Daemon404> debain unstable has been good to me
[22:34] <Daemon404> arch is strictly a ricer distro
[22:34] <Daemon404> gentoo wannabes
[22:35] <ubitux> imo debian is unusable unless you use sid
[22:35] <ubitux> and when you do, it's always broken
[22:35] <Daemon404> ive been using sid for 3 or 4 years
[22:35] <Daemon404> 0 breakage
[22:35] <ubitux> i'm using it everyday since 2-3 years
[22:35] <ubitux> and it's always broken
[22:35] <Daemon404> in which way?
[22:35] <ubitux> (at work, so not much fancy stuff)
[22:36] <ubitux> mmh like upgrades breaking everything
[22:36] <ubitux> trashing the boot
[22:36] <llogan> -encoders and such should be alphabetical
[22:36] <Daemon404> ubitux, never ever happened to me
[22:38] <kierank> i have had ubuntu trash my system once
[22:39] <ubitux> at every major upgrade?
[22:39] <ohsix> i've never had anything happen without hitting enter
[22:39] <llogan> kierank: what happen!!!
[22:39] <Daemon404> ubuntu never trashes during upgrades
[22:40] <kierank> it did once
[22:40] <Daemon404> only if you try to upgarde nonlinearlyly
[22:40] <kierank> nope using the wizards
[22:40] <kierank> on the gui
[22:40] <kierank> and it just trashed the packages 
[22:40] <kierank> so i'm always very nervous
[22:40] <ohsix> or don't remove ppa's
[22:41] <ohsix> there are manual kludges in the upgrade packages that can make a mess if you upgrade that way :\
[22:41] <Daemon404> never remove unity
[22:41] <Daemon404> i learned this
[22:41] <Daemon404> it breaks stuff and meta-packages
[22:41] <Daemon404> and nonsense
[22:43] Action: michaelni also wasnt happy about the x264 log level change ...
[22:44] <llogan> let's make a fork
[22:44] <Daemon404> with one patch rebased
[22:49] <michaelni> ping me when the fork is up so i can merge it
[22:50] <llogan> we first have to bikeshed the name.
[22:50] <j-b> w264
[22:50] <nevcairiel> clearly, it has to be libff
[22:50] <nevcairiel> ffav?
[22:51] <cbsrobot-> lets make it simple and call it "fork".
[22:51] <llogan> yemen
[22:53] <Daemon404> no no no, these are all to easy to understand
[22:53] <Daemon404> libffmpeg, or libsw
[22:53] <Daemon404> oh im sorry,
[22:53] <Daemon404> Libffmpeg, or Libsw
[22:53] Action: Daemon404 runs
[22:58] <Skyler_> libffcodec
[23:02] <ubitux> saste: Daemon404 was summoning you
[23:02] <saste> i'm here
[23:03] <ubitux> he'd like to revert 911519caec2346fc7728bca9840ffc000e866161
[23:03] Action: Daemon404 gathers michaelni would too
[23:03] <saste> so the question is, why?
[23:04] <Daemon404> because there is e.g. no way to get the used bitrate fro ma first pass without it
[23:04] <Daemon404> many people rely on parsing it
[23:04] <Daemon404> and do not want to shit a bunch of stuff from -v verbose into their logs
[23:04] <Daemon404> and really
[23:04] <Daemon404> -        [X264_LOG_INFO]    = AV_LOG_INFO,
[23:04] <Daemon404> +        [X264_LOG_INFO]    = AV_LOG_VERBOSE,
[23:04] <Daemon404> ^ this just looks dumb even ;)
[23:04] <Daemon404> ifn ois not info, you know.
[23:05] <saste> dumb? did you read the log
[23:05] <Daemon404> i did
[23:05] <Daemon404> and i disagree.
[23:05] <ubitux> saste: revert it, and send a patch to x264 to move the info to X264_LOG_VERBOSE :D
[23:05] <saste> now i don't really mind so feel free to revert it
[23:05] <saste> I just find silly that libx264 has to spam the log with all that silly details
[23:05] <Skyler_> --verbose prints information per-frame, it's a lot more verbose than info
[23:05] <saste> that really don't belong to the INFO level
[23:06] <saste> if the information is useful for parsing, that should be a codec option
[23:06] <saste> and yes
[23:06] <saste> overall we need a more fine-tuned system for setting the log levels
[23:06] <Daemon404> i cant revert anyway ;)
[23:06] Action: Daemon404 hath no push access
[23:06] <ohsix> levels are for jerks when you mix a bunch of libraries together
[23:06] <saste> for example i may be interested into debugging a codec, and don't get annoyed by other random spamlog
[23:06] <ohsix> channels and levels are where it's at
[23:07] <saste> Daemon404, send a patch
[23:07] <Daemon404> saste, i can
[23:07] <Daemon404> i prefer to talk on irc though
[23:07] <Daemon404> instead of drawn out bikeshedding on MLs
[23:07] <Daemon404> or people who only use email (ahem)
[23:08] <saste> Daemon404, if michaelni is fine with it i won't object
[23:08] <saste> just one thing
[23:08] <ohsix> there are people on mailing lists that think they're being useful contributors just by participating in distraction threads :D
[23:08] <saste> state in the log why it is required (the exact use case)
[23:08] <ohsix> (eg. usually me, so i stay off mailing lists unless i really have work to do)
[23:08] <Daemon404> ohsix, are those anything like distraction boobs?
[23:08] <Daemon404> they sound much less fun
[23:09] <Daemon404> saste, of course
[23:09] <llogan> ohsix: Parkinson's Law
[23:09] <ohsix> it would be cool if there was some computermachine metric that would tell you how likely a thread or a message would be a waste of time
[23:09] <ohsix> need to use graylisting and mark people i think :D can't be content based
[23:10] <ohsix> though, i bet you could weed out messages that don't include part of the original post (patch) pretty workably
[23:10] <saste> ohsix, universities and research labs are full of people which are measuring exactly that
[23:10] <Daemon404> best way would be to 'teach' it
[23:10] <saste> with very poor results so far
[23:10] <Daemon404> by markign each email you think is shit
[23:11] <saste> ffmpeg-devel is quite clean, there is a good signal/noise ratio imho
[23:12] <Daemon404> not always
[23:12] <Daemon404> but usually.
[00:00] --- Thu Sep 13 2012