[FFmpeg-devel-irc] IRC log for 2010-02-25

[irc at mansr.com]

[00:05:55] <CIA-92> ffmpeg: stefano * r22045 /trunk/ffprobe.c:
[00:05:55] <CIA-92> ffmpeg: Cosmetics: replace "filename" to "arg" for the name of the argument of
[00:05:55] <CIA-92> ffmpeg: opt_input_file(). More consistent and more clear, as "filename" can be
[00:05:55] <CIA-92> ffmpeg: easily confused with the global "input_filename".
[00:07:40] <janneg> 2G DDR2 modules, but I'm primarily annoyed that I haven't bought some 9 months ago
[00:08:04] <janneg> or at least replaced the broken one
[00:17:33] <CIA-92> ffmpeg: stefano * r22046 /trunk/ffprobe.c:
[00:17:34] <CIA-92> ffmpeg: 10l: add prefix "TAG:" to the metadata tags key showed for each stream.
[00:17:34] <CIA-92> ffmpeg: This is consistent with the metadata displaying in show_format() and
[00:17:34] <CIA-92> ffmpeg: with the documentation.
[00:27:34] <janneg> hmm, I'm looking at a script for tile rendering
[01:09:18] <janneg> I render only a quarted of the image and memory consumption hasn't decreased much and rendering seems to be as slow as before
[01:10:38] <Dark_Shikari> I would doubt memory consumption would go down much with tile rendering
[01:10:41] <Dark_Shikari> you still have to consider the whole scene
[01:14:53] <Kovensky> http://www.codinghorror.com/blog/2008/11/is-email-efail.html
[01:15:42] <Kovensky> and yes, memory consumption won't go down; you're only skipping the rendering of off-camera objects but they're still there
[01:20:09] <janneg> rendering objects will obviously consume memory too
[01:20:40] <iive> janneg: can you explain this a little bit more
[01:21:12] <mru> I reckon most of the memory is used for the scene representation
[01:21:22] <mru> most of the cpu time is probably spent in rendering though
[01:22:05] <iive> so, even if you render 320x200, you'd still need that amount of ram.
[01:23:41] <janneg> if I interpret the memory usage stats and stage descriptions correctly the scene representation is usually around 1-1.5G
[02:11:45] <mru> I finally figured out why gcc is silly about registers
[02:11:58] <mru> there's a file in the gcc source called rtlanal.c
[02:18:30] <DonDiego> ##something##-not-a-lawyer
[02:19:14] <mru> rtl = register transfer language
[02:19:38] <mru> it's what the machine descriptions are written in
[02:22:39] <DonDiego> btw
[02:23:06] <DonDiego> i managed to troll the xiph folks on their home turf..
[02:23:12] <DonDiego> didn't even want to..
[02:23:15] <DonDiego> :)
[02:23:24] <mru> how?
[02:24:26] <DonDiego> http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/
[02:24:36] <DonDiego> i called ogg deeply flawed
[02:25:04] <DonDiego> i could use some help dispelling the myths they keep spreading..
[02:28:53] <Dark_Shikari> use mru's post
[02:29:09] <mru> it's not all-encompassing
[02:29:17] <Yuvi> he thinks codec-specific timestamps are a feature
[02:29:17] <mru> only talks about timestamps
[02:29:17] <Yuvi> not
[02:29:47] <Yuvi> i.e. that everything mru points out are good things
[02:30:02] <mru> lol
[02:30:13] <DonDiego> i already used mru's post
[02:30:24] <DonDiego> we really have a problem here
[02:30:27] <mru> I need to write a new one
[02:30:33] <DonDiego> they should not be left with the last word
[02:30:46] <mru> but writing a good, scathing post takes time
[02:31:00] <DonDiego> we need to be way more visible with good technical criticism
[02:31:30] <Yuvi> I really should start a blog / get a domain, but I can't think of a good name
[02:31:30] <DonDiego> "The third big thing Diego (and the mplayer community in general) hate is the intentional, conscious decision to allow a codec to define how to parse granule positions for that codec’s stream. Granpos parsing thus requires a call into the codec."
[02:31:47] <DonDiego> "The practical consequence: When an Ogg file contains a stream for which a user doesn’t have the codec installed…. they can’t decode the stream! *gasp* Wait… how is that different from any other system?"
[02:32:06] <mru> have I mentioned that I dislike the silly names they give everything?
[02:32:10] <mru> "granule" wtf?
[02:32:19] <mru> "sample" please
[02:32:27] <DonDiego> am i deeply mistaken or does this prohibit remuxing?
[02:32:41] <Yuvi> with other containers, you either don't have to add *any* code to the demuxer to handle nearly any new codecs, (avi, nut, mov) or very little (mkv, mpg, mp4)
[02:33:02] <DonDiego> Yuvi: ask mike for a blog on multimedia.cx
[02:34:08] <DonDiego> Yuvi: also, your work is very important: it's a much better to be able to say "yes, we hate the stuff, but of course we have top-notch support nonetheless"
[02:35:50] <mru> monty is on edge, nice work DonDiego
[02:36:04] <DonDiego> haha :)
[02:36:14] <DonDiego> as i said, please back me up
[02:36:38] <DonDiego> we need to show that it's not just for the sake of trolling
[02:38:23] <peloverde> DonDiego, There are patents on the MP4 container
[02:38:32] <mru> that's just crazy
[02:38:41] <mru> it's apple quicktime ffs
[02:38:42] <peloverde> but my guess is that they are on fancy new (read unnecessary) features
[02:38:44] <DonDiego> apparently, but i didn't know that
[02:38:47] <mru> old as the hills
[02:38:53] <peloverde> MOV itself is old as dirt and
[02:39:22] <mru> the -14 format really has everything you need
[02:39:31] <mru> and it's quite simple too
[02:39:55] <peloverde> I would define something simple on top of -12
[02:40:13] <mru> simpler than -14?
[02:40:22] <peloverde> yes
[02:40:25] <peloverde> -14 is a superset of -12
[02:40:33] <Dark_Shikari> DonDiego: the point is that they're looking from a completely different perspective
[02:40:35] <mru> I know
[02:40:38] <Dark_Shikari> they're acting as if developers don't matter
[02:40:42] <mru> but -12 lacks a few bits
[02:41:05] <peloverde> -12 lacks a few bits, but that crowd is going to piss and moan that -14 costs a few CHF
[02:41:18] <DonDiego> Dark_Shikari: good point, yes, but false of course
[02:41:31] <peloverde> anything missing can be re-adapted from qtff which is also free
[02:41:40] <Dark_Shikari> just use mkv
[02:41:42] <Dark_Shikari> seriously
[02:41:44] <Dark_Shikari> it's already free
[02:41:46] <Dark_Shikari> it's more popular than ogg
[02:41:49] <Dark_Shikari> it's better than ogg in every way
[02:41:56] <mru> mkv is a bit over-complicated
[02:41:58] <peloverde> yes mkv is also acceptable
[02:42:03] <Dark_Shikari> mru: but xiph love overcomplicated
[02:42:05] <mru> but it's not utterly horrible like ogg
[02:42:08] <DonDiego> mkv is supported in a lot of hardware
[02:42:09] <peloverde> for dev purposes I kind of like mov
[02:42:13] <Dark_Shikari> and mkv also has buzzword compliance
[02:42:14] <Dark_Shikari> XML!
[02:42:30] <mru> even though it has fuck all to do with xml
[02:42:44] <peloverde> mov is basically human readable
[02:43:14] <CIA-92> ffmpeg: michael * r22047 /trunk/libavcodec/ (h264.c h264.h): Keep mvd_table values of only 2 mb rows.
[02:43:27] <peloverde> either way, mov or isom i don't really care
[02:44:36] <Dark_Shikari> we need to pick something already free, already widely used, and promote it
[02:44:39] <Dark_Shikari> let's make it mkv.
[02:44:58] <peloverde> If you are trying to build consensus (which it doesn't seem like they are) choosing a mov/isom derivative might get a few points of approval from apple
[02:45:08] <Dark_Shikari> Nobody will agree on a new container format.
[02:45:12] <kierank> and it works in flash
[02:45:26] <Dark_Shikari> The purpose of this promotion is to step on Xiph
[02:45:31] <DonDiego> oh, mike is posting..
[02:45:35] <Dark_Shikari> it doesn't have to be something apple would like
[02:45:43] <Dark_Shikari> it has to be something better than what xiph offers
[02:46:03] <Yuvi> wonder how much stuff nut works in (heh)
[02:46:14] <Yuvi> probably not gstreamer
[02:46:16] <Dark_Shikari> so seriously, someone make a post outlining all the reasons that ogg sucks
[02:46:22] <Dark_Shikari> and tell people to use mkv
[02:46:26] <Dark_Shikari> because it's more widely used, more widely supported
[02:46:28] <Dark_Shikari> and better
[02:46:40] <Dark_Shikari> and free.
[02:47:07] <saintdev> <Dark_Shikari> XML! <-- EBML!
[02:47:30] <saintdev> *ML, it must be good...
[02:48:15] <saintdev> Dark_Shikari: your blog seems to get a lot of attention ;)
[02:48:25] <Dark_Shikari> I'm not enough of an expert to write about why ogg sucks.
[02:49:27] <astrange> mkv doesn't need faststarting so it's probably easier to use than mov
[02:50:00] <Dark_Shikari> it also has commercial support (unlike ogg)
[02:50:07] <Dark_Shikari> i.e. you can get support from corecodec
[02:52:02] <DonDiego> mru: you do notice that everyone is looking at you, don't you?
[02:52:04] <DonDiego> :)
[02:52:45] <saintd3v> and like a car-crash, i can't look away
[02:52:49] <saintd3v> :p
[02:53:39] <astrange> hmm, mkvmerging a random ogg (3m long vorbis track) made it a little smaller
[02:53:52] <astrange> wonder if it takes less disk reads to do a random seek
[02:54:13] <Yuvi> yeah, ogg has the highest overhead of any container other than .ts
[02:55:08] <mru> but unlike ts the overhead doesn't bring any advantages
[03:03:58] <DonDiego> monty claims otherwise
[03:04:09] <mru> well, he would...
[03:04:42] <DonDiego> well, we need to set him straight
[03:04:59] <DonDiego> i already did for the infamous youtube comparison from gregory maxwell
[03:05:37] <Dark_Shikari> DonDiego: you'd actually be slightly surprised at the situation
[03:05:47] <Dark_Shikari> apparently the theora devs are very worried because people are dubbing them liars and cheats
[03:06:06] <Dark_Shikari> in large part due to the legions of idiots who follow xiph
[03:06:22] <DonDiego> yeah
[03:06:28] <DonDiego> the devs know the limitations
[03:06:31] <mru> but they _are_ liars and cheats
[03:06:33] <Dark_Shikari> and they want people to stop posting about how theora will beat h264
[03:06:44] <Dark_Shikari> of course it's partially their fault...
[03:06:55] <Dark_Shikari> the point being that lies catch up with people
[03:09:30] <DonDiego> who told you that?
[03:09:59] <peloverde> Ask them if they are willing to renounce and reject lying supporter Mozilla?
[03:10:59] <DonDiego> what?
[03:11:23] <Dark_Shikari> who told what
[03:11:33] <peloverde> mozilla has gotten caught with their hand in the bad comparison cookie jar multiple times
[03:11:49] <Dark_Shikari> they don't seem to be willing to do it
[03:11:55] <Dark_Shikari> which means I think people will rightfully blame them for it
[03:14:32] <DonDiego> you guys are talking in riddles right now..
[03:14:43] <peloverde> I also wish someone would ask Mozilla if their former high profile developers Hyatt, Hixie, and Goodger want to "Hurt the web"
[03:15:05] <peloverde> I wish someone would take their retarded frame to its logical conclusion
[03:15:06] <ohsix> i'm hurting the web right now
[03:16:09] <Dark_Shikari> DonDiego: a theora dev told me to bonk on the head anyone who claimed that theora was nearly as good, as good, or better than h264
[03:16:13] <Dark_Shikari> because it made them look like liars
[03:16:58] <DonDiego> peloverde: where are these guys now?
[03:17:17] <DonDiego> well, i talked to a webkit dev at fosdem
[03:17:46] <DonDiego> alp toker
[03:17:55] <peloverde> alp was pretty cool
[03:17:58] <DonDiego> he ported webkit to firefox
[03:18:16] <DonDiego> i.e. firefox with webkit as rendering engine
[03:18:20] <mru> and theora to mono
[03:18:24] <peloverde> Hixie and goodger are at google
[03:18:36] <peloverde> hyatt is at apple
[03:18:42] <DonDiego> i.e. faster and more standards-compliant rendering
[03:18:47] <DonDiego> all firefox extensions
[03:18:49] <DonDiego> perfect
[03:19:18] <peloverde> well i'm sure there are a few extensions that depend on -moz CSS attributes
[03:19:33] <DonDiego> mru: yeah, but that was "just for kicks" as he said, no particular reason or political agenda
[03:19:33] <kierank> DonDiego, can you download that?
[03:19:48] <kierank> it would be firefox without being sluggish as hell
[03:20:03] <ohsix> anyone seriously and critically assessing this stuff will know all they need to know after they commit their own time; theres really nothing that needs to be constantly and doggedly defended, overstating your case is bad
[03:20:10] <peloverde> some of firefox's issues are from the way they use SQLite
[03:20:11] <DonDiego> no, he was paranoid to release it, fearing a backlash from the firefox people :-(
[03:20:40] <DonDiego> ohsix: i agree, but our case is not sufficiently stated
[03:20:52] <DonDiego> we need to be more visible with our technical arguments
[03:21:10] <DonDiego> we should explain *once* why ogg is bad and not on a mailing list
[03:21:49] <ohsix> anyone thats actually doing a technical review will find information wherever it is
[03:21:58] <Dark_Shikari> ok, so mru
[03:22:00] <Dark_Shikari> 1) write the blog post
[03:22:08] <Dark_Shikari> 2) put a huge disclaimer at the top for idiots explaining what ogg is and isn't
[03:22:11] <Dark_Shikari> i.e. ogg is not vorbis
[03:22:12] <Dark_Shikari> ogg is not theora
[03:22:13] <Dark_Shikari> ogg is ogg
[03:23:18] <ohsix> peloverde: are you referring to sqlites use of fdatasync or ?
[03:23:38] <peloverde> I'm referring to the fsync issue
[03:24:03] <ohsix> ic, i thought they sorted that ages ago when they finally admitted it was real
[03:24:06] <Yuvi> btw, I'll have a blog up at blog.yuvie.net soon, maybe I'll do a post on ogg problems
[03:24:40] <peloverde> They made it better, but I'm pretty sure it's not all fixed
[03:25:05] <peloverde> Last I checked firefox performed a lot worse than chromium for me when the disk was under load
[03:25:23] <ohsix> hm, keen, only problem i've had with ff on lunix is that theres no nanojit for x86_64 in release builds yet
[03:27:53] <DonDiego> Yuvi: do that..
[03:28:11] <DonDiego> Yuvi: also, how is your theora branch coming along?
[03:28:52] <Yuvi> I wanted mike's comments on reworking the coeff decode, that's the most significant change I'm making and most further ones depend on it
[03:29:01] <Yuvi> so I'll ping that later
[03:29:22] <DonDiego> ping mike in private, iirc he does not follow the lists much
[03:31:38] <astrange> i have to rewrite the vp3 patch in -mt, so
[03:31:49] <astrange> i'd rather not merge until you commit that, otherwise i have to do it again again
[03:34:12] <Dark_Shikari> yeah, the sooner that commit goes in the better
[03:34:18] <Dark_Shikari> once the trees are fully merged I can start trying some optimizations
[03:34:50] <astrange> that's merging the other way, not ready for that yet
[03:35:11] <astrange> but i blew away most of the cosmetic stuff in the todo last week, so now i'm working on the important stuff
[03:35:37] <Dark_Shikari> I meant for yuvi
[03:38:52] <DonDiego> Yuvi: i think you should ask mike if he is ok with you taking over vp3/theora maintenance
[03:38:57] <Dark_Shikari> agreed.
[03:39:10] <DonDiego> my guess is that he will be ok with it
[03:41:07] <DonDiego> Yuvi: another thing: have you compared performance with the binary vp3 decoder?
[03:41:25] <DonDiego> i tested waaaay back and the vp3 binary used to be considerably faster
[03:41:36] <DonDiego> but this was years ago...
[03:47:11] <ohsix> why are wavelets a deadend?
[03:48:01] <Yuvi> DonDiego: nope, it might be faster on ppc only because it has more altivec, but even then I'd be surprised
[03:48:17] <Yuvi> I've heard libtheora was significantly faster
[03:50:33] <DonDiego> i tested on x86 back then
[03:50:43] <DonDiego> there is no ppc binary for vp3 iirc
[03:50:59] <Yuvi> guess it was only a quicktime component
[03:54:40] <ohsix> re: this vp8 thing and the ensuing comments; arguments from authority are weak on their face, and that other guy has sober and rational in spades
[03:56:46] <peloverde> who is making the argument from authority?
[03:59:54] <pengvado> ohsix: because wavelets make everything else harder. if the transform doesn't have well-defined edges, then you don't have places at which to switch coding modes.
[04:00:28] <Dark_Shikari> ohsix: a few reasons
[04:00:33] <Dark_Shikari> 1) nobody has found a good way to do intra coding
[04:00:38] <Dark_Shikari> 2) nobody has found a good way to do variable partition size
[04:00:44] <Dark_Shikari> 3) nobody has found a good way to make the transform's artifacts not look like shit
[04:00:50] <Dark_Shikari> 4) nobody has found a good way to do spatial adaptive quantization
[04:01:34] <mru> 1-4) nobody has found a way to make it work
[04:01:43] <pengvado> actually, I don't think there's anything hard about spatial adaptive quantization in wavelets.
[04:01:50] <Dark_Shikari> how would you do it?
[04:01:57] <Dark_Shikari> how would you assign a differnet quantizer to each 8x8 block
[04:02:00] <Dark_Shikari> if the wavelets were 128x128?
[04:02:45] <pengvado> each wavelet coef has a position and a radius. if it's smaller than 8x8, take the qp from the one colocated block. if larger, take the average of all blocks it overlaps.
[04:03:37] <Dark_Shikari> hmm.  that could work.
[04:03:43] <Dark_Shikari> weighted average, even better
[04:04:11] <ohsix> pengvado: ah, thanks
[04:04:25] <Dark_Shikari> ok, so 1-3), but not 4).
[04:04:29] <ohsix> i was thinking of other uses than basic codec principle stuff
[04:05:00] <pengvado> what other uses?
[04:05:01] <ohsix> and cheers in explaining it in terms of wavelet properties that are relevant ;]
[04:05:30] <pengvado> overcomplete wavelets for denoising?
[04:05:46] <ohsix> motion estimation? dunno; multiresolution stuff for coder parameters
[04:06:02] <Dark_Shikari> wavelets don't help you for multiresolution
[04:06:11] <Dark_Shikari> only in intra coding, not in inter coding
[04:09:27] <ohsix> this is all under the premise that "the multimedia commumity" considers wavelets a "dead end" ;]
[04:11:56] <peloverde> Even in audio and still images wavelets have largely failed to deliver
[04:12:25] <CIA-92> ffmpeg: michael * r22048 /trunk/libavcodec/ (h264.c h264.h):
[04:12:25] <CIA-92> ffmpeg: Cut the size of mvd_table by yet another factor of 2.
[04:12:25] <CIA-92> ffmpeg: The code read/write code itself was 1 cycle faster, overall its
[04:12:25] <CIA-92> ffmpeg: likely more due to cache effects
[04:13:14] <ohsix> but its not a foregone conclusion; that could change at any point in the future
[04:14:57] <ohsix> anyways i'd just like to see the arguments to be more cogent if theres always going to be a rallying cry when some new blog posts comes out; i feel bad for some of these statements, i know some aren't from english speakers, or people subject to some concerns of the other commenters, but an argument from authority is always a fallacy
[04:16:11] <peloverde> It could change in the future but historically people have proposed wavelet based solutions as saviors over and over again only to fall flat
[04:16:50] <peloverde> At this point wavelets-as-a-magical technique has lost any credibility and wavelet based solutions need to stand on their own merits
[04:17:20] <mru> the wavelet craze caught on after fractal compression had gone nowhere
[04:17:23] <ohsix> and the people that may chime in to support someone they trust in experience here or withing the project; the "support" undermines any argument they could make, at least in support for another post; these other entities dont have the same trust & experience to these same people, the arguments have to be clean and technical
[04:19:55] <pengvado> I agree with "the multimedia commumity considers wavelets a dead end", to a sufficient extent that when I flatly declare wavelets to be not worthwhile, I expect to only occasionally find people who are both interested in the technical details and not already know why wavelets suck.
[04:20:28] <ohsix> hey fractal compression could make a comeback
[04:20:30] <peloverde> then wavelet proponents need to make a "clean and technical argument" why a their new wavelet based codec will be more successful than conventional codecs, and if they just repeat the same argument as their forebears they need to explain why they will cross whatever hurdles their forebears failed to do so, until then wavelets will remain a buzzword that failed to deliver
[04:20:53] <ohsix> yea they do need to make the argument
[04:21:32] <pengvado> "even in audio"? what reason is there to expect wavelets to be any more appropriate to audio?
[04:21:54] <ohsix> you can do doppler really easy and cheap with wavelets in simulations
[04:21:57] <mru> fractal compression seemed fine, until it was discovered that the test image they were using was one of the mandelbrot set
[04:22:21] <ohsix> along with other generation thingies that are well to do with multiresolution source samples
[04:22:43] <peloverde> pengvado, T/F flexibility is one the biggest problems in hard to code audio samples
[04:23:23] <peloverde> sharp attacks are basically very specific localization in time
[04:23:29] <ohsix> one project i read the paper to used wavelets and vibrational modes to generate close to physically accurate sounds for virtual objects being struck/sounded in arbitrary configuration
[04:24:45] <peloverde> So if you implement them say the way the AAC TF model does with the EIGHT_SHORT_SEQUENCE, diving up your frame into smaller windows, you wind up smearing everything else in frequency
[04:25:51] <peloverde> In addition we aren't coding noisy residuals or doing intra prediction
[04:26:50] <ohsix> oh boy i was reading pengvado and peloverde as the same person
[04:27:31] <pengvado> oh, what's the status of prediction in audio coding? blue-sky research? everyone's given up? or what
[04:27:53] <ohsix> pengvado: some readers might not even know what he's hinting at when he mentions wavelets, and might derail the thread _into_ that wavelet discussion
[04:28:24] <peloverde> AAC introduced a main predictor that was a disaster for a variety of spec specific reasons
[04:28:31] <peloverde> like mandatory use of half floats
[04:28:47] <peloverde> or mandatory emulation of half floats
[04:29:28] <peloverde> and in general it was very computationally intensive even with full floats
[04:30:05] <peloverde> so it was more efficient just to not use it and dump more effort into a good scalefactor search
[04:30:20] <ohsix> someone with a fetish for wavelets might do something interesting in the future with them; but you can pretty much write them off until they're appropriate, not even worth mentioning in that context imo
[04:30:53] <peloverde> MPEG-4 introduced another predictor (the LTP) which was much simpler
[04:31:30] <peloverde> I don't know what that one didn't take off, presumably it wasn't worthwhile as well
[04:31:50] <peloverde> main predictor breaks frame accurate seeking, I presume LTP does as well
[04:31:55] <peloverde> (I haven't touched LTP at all)
[04:32:15] <peloverde> (At some point I plan on implementing it for libfaad2 compatibility)
[04:32:37] <ohsix> i'm learning things, thanks chaps; this beats the blog post pileon any day
[04:33:03] <peloverde> SBR also breaks frame accurate seeking but in a way that degrades nicely
[04:33:16] <peloverde> In many ways SBR is actually an INTRA predictor
[04:33:36] <peloverde> you are coding the HF in terms of the LF
[04:34:12] <Yuvi> > interleave is a fairly recent feature in MKV
[04:34:19] <Yuvi> there was such a thing as non-interleaved mkv?
[04:35:05] <ohsix> you can just put stuff in arbitrary chunks, no?
[04:35:06] <peloverde> I don't know what's going on in USAC these days
[04:35:19] <ohsix> thats how fonts and stuff are embedded in mkv
[04:35:20] <peloverde> I'd really like to see the current WD to see what they are up to
[04:35:29] <Yuvi> ohsix: those don't have timestamps
[04:35:36] <peloverde> things should be settling down by now
[04:36:05] <ohsix> ah
[04:37:16] <peloverde> In general USAC is a bit of a frankenstein codec the way MPEG-4 Audio with Scalability was envisioned except even more closely coupled so I wonder if their will be any sane subprofiles
[04:39:18] <Dark_Shikari> ohsix: there's no real bias against wavelets; if someone proposed a reasonable way to solve any of wavelet coding's main problems, I think people would be very interested
[04:39:49] <Dark_Shikari> people are biased against solutions that _don't_ claim to solve any of these
[04:40:00] <Yuvi> then again, some people still think tarkin is the next-gen xiph codec
[04:40:11] <Dark_Shikari> lol tarkin
[04:41:11] <ohsix> i didn't mean to suggest bias; just appropriateness when you're trying to plead a technical case
[04:42:04] <Dark_Shikari> I think there's significant benefit to be had in some of the MC ideas that have come from wavelet research
[04:42:09] <Dark_Shikari> obmc/grid MC
[04:42:23] <Dark_Shikari> and ds's idea, of arbitrary motion vector partitions
[04:42:36] <Dark_Shikari> where you start with the whole frame, and split it into arbitrary rectangles step by step
[04:42:42] <Dark_Shikari> allowing partitions to start and end on any boundary
[04:50:47] <Dark_Shikari> since michael is reading the irc
[04:50:53] <Dark_Shikari> thanks for that idea you just committed.  I'm porting it to x264.
[04:53:13] <Dark_Shikari> hmm I wonder if it's possible to port his ringbuffer model for cabac mvds...
[04:56:43] <peloverde> that reminds me that there is some circular buffer stuff in SBR that I've been putting off
[05:05:04] <pengvado> course it is. nnz too.
[05:15:16] <Dark_Shikari> would need one per thread for sliced threads
[05:15:20] <Dark_Shikari> like intra border backup
[07:02:27] <Yuvi> hm, it seems like only aurel's mkv demuxers can handle unknown cluster sizes...
[07:03:28] <kshishkov> excuse it for being robust
[07:07:46] <Yuvi> http://userpages.umbc.edu/~dconrad1/streamed.mkv <- does that play for anyone outside of ffplay or mplayer?
[07:10:05] <astrange> not in perian, mkvinfo, divx 7 player, coreplayer
[07:10:11] <Dark_Shikari> haali?
[07:10:33] <astrange> the last two hung so maybe they'll wake up
[07:32:18] <KotH> moin
[07:33:41] <astrange> never did wake up
[07:34:02] <kshishkov> never in your life?
[07:35:40] <Yuvi> not surprising, guess I'll just write one block per cluster
[07:35:46] <Dark_Shikari> Yuvi: what are you writing?
[07:36:08] <Yuvi> Dark_Shikari: making lavf's matroska muxer work better when streaming / piping
[07:36:12] <Dark_Shikari> ah.
[07:36:21] <Dark_Shikari> maybe you can write index support for x264's afterwards? ;)
[07:36:27] <Dark_Shikari> or wait, Haali said he had that half done
[07:36:55] <Yuvi> (since one of ogg's "strengths" is streaming)
[07:37:07] <Dark_Shikari> lol
[07:37:17] <Dark_Shikari> yeah, mkv _should_ work fine streaming
[07:37:21] <Dark_Shikari> but a lot of existing implementations don't :/
[07:37:40] <Yuvi> like, all of them
[07:37:43] <Dark_Shikari> Yeah
[07:38:21] <astrange> mkvinfo thinks it has |+ (Unknown element: DummyElement; ID: 0xff size: 4152553056)
[07:38:33] <Yuvi> yeah, dunno why
[07:39:04] <Yuvi> it's valid, the only difference there between a non-streamed is that it uses the special unknown size
[07:39:57] <Yuvi> which mkvinfo recognizes for the segment...
[07:40:22] <Yuvi> vlc and gstreamer don't work (no surprise on the latter)
[07:41:26] <Dark_Shikari> fix ffmpeg, fix vlc
[07:41:31] <Dark_Shikari> then bitch at gstreamer for not supporting it
[07:41:36] <Dark_Shikari> ;)
[07:41:56] <Yuvi> didn't work with haali either I think
[07:42:07] <Yuvi> ffmpeg already works fine
[07:43:01] <Dark_Shikari> yell at haali
[08:14:11] <siretart`> morning
[08:20:04] <siretart`> ramiro: I've seen your request on -cvlslog, I'm still thinking about it
[08:20:15] <siretart`> request for comment
[08:25:49] <av500> Yuvi: it plays fine here :)
[09:10:26] <CIA-92> ffmpeg: benoit * r22049 /trunk/libavformat/asf.c:
[09:10:26] <CIA-92> ffmpeg: asf: add more entries to metadata conv table.
[09:10:27] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail com
[09:11:29] <CIA-92> ffmpeg: benoit * r22050 /trunk/libavformat/asf.c:
[09:11:29] <CIA-92> ffmpeg: asf: indent.
[09:11:29] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail com
[09:44:05] <twnqx> i wonder if it's a good idea to map author to artist... what happens if you actually *mean* author?
[09:45:01] <Dark_Shikari> and what about album artist vs song artist?
[09:45:19] <Dark_Shikari> I have hundreds if not thousands of songs where album artist != song artist
[09:45:45] <twnqx> dunno, id3v2 can handle that
[09:46:07] <elenril> twnqx: there is no generic tag named author
[09:46:28] <twnqx> but there should be!
[09:46:43] <elenril> send patches
[09:46:47] <twnqx> heh
[09:46:50] * elenril doesn't see much point in having it
[09:46:53] <twnqx> only if you fix mp4/mov
[09:46:55] <elenril> Dark_Shikari: what about it?
[09:47:14] <elenril> we have both album_artist and artist
[09:47:50] <Dark_Shikari> oh, we do?  guess that works.
[09:47:55] <av500> Dark_Shikari: there is "WM/AlbumArtist" and "Author" in asf
[09:47:58] <Dark_Shikari> good for comiket stuff.
[09:49:10] <av500> elenril: btw, WM/TrackNumber is 1 based, WM/Track is 0 based :)
[09:49:22] <av500> do we handle that?
[09:49:31] <elenril> should we?
[09:50:29] <av500> I think so, Track 1 is could come out as 0 or 1 if not
[09:51:40] <av500> btw, could CIA-92 output clickable links into the SVN/GIT here?
[09:52:12] <Dark_Shikari> svn web interface is down
[09:52:20] <av500> git is up
[09:52:53] <elenril> av500: send patches ;)
[09:53:01] <av500> elenril: :)
[09:53:11] * elenril already wasted too much time on asf
[09:53:16] <av500> I might, I also have asf chapters rotting here
[09:53:38] <elenril> asf supports chapters?
[09:53:51] <elenril> funny i'm just adding chapters copying to ffmpeg
[09:54:20] <av500> elenril: well, they call it markers, but in principle the same, you get a time and a name
[09:54:36] <av500> I will clean up the patch...
[09:54:45] <elenril> twnqx: btw in what situation would it make sense to have an 'author' and 'artist' tags
[10:00:04] <twnqx> audio books, maybe
[10:00:21] * elenril <3 how git can automagically detect patches applied upstream and skip them when rebasing
[10:00:34] <twnqx> operas, where the actors are as important
[10:06:20] * elenril would rather use performer/writer tags in these cases
[10:12:11] <Dark_Shikari> siretart`: we picked a god-damn good revision didn't we.  I just found yet another regression.... in r1449.
[10:13:34] <twnqx> :S
[10:27:07] * KotH thinks that more scientific publications should be written in german
[10:28:23] <av500> auf jeden Fall!
[10:29:01] * elenril thinks german is evil
[10:29:42] * av500 performs 3v1l l4ugh
[10:32:16] <KotH> Grundlagen der kombinatorischen Logik. American Journal of Mathematics
[10:32:22] <KotH> somehow, i like the sound of that :)
[11:03:15] <kshishkov> KotH: you had the time when most scientific publications were in German - before WWI
[11:17:42] <KotH> kshishkov: before ww2 actually
[11:17:47] <KotH> kshishkov: and some time after it too
[11:18:06] <kshishkov> I doubt it a bit
[11:18:06] <av500> I guess a lot of rocket science papers in german after ww2 :)
[11:18:16] <av500> (for internal use only)
[11:18:44] <kshishkov> av500: nah, rocket scientists were divided between USA and USSR
[11:18:49] <KotH> math papers were written mostly in german until 50s
[11:19:03] <av500> kshishkov: thats what I meant actually :)
[11:21:39] * KotH wonders whether one should start a journal that is written in iotic
[11:22:17] <kshishkov> with the shortest Greek letter only?
[11:23:54] <KotH> en.wikipedia.org/wiki/Iotic
[11:24:33] <kshishkov> Sindarin is more traditional
[11:27:48] <KotH> but can you discuss the relativity theory in sindarin?
[11:28:08] <kshishkov> merbzt: vet du hur många kostar bananer i Sverige?
[11:28:26] <kshishkov> can you discuss it any other language than math?
[11:28:48] * kshishkov thinks German language is good only for philosophical discussions
[11:43:06] <siretart`> Dark_Shikari: :-)
[12:14:46] <lu_zero> hi
[12:15:05] <lu_zero> roundup is being moved to wsgi
[12:15:21] <lu_zero> hopefully that should make it faster
[12:37:31] <siretart`> hi Diego!
[12:45:56] <elenril> when adding new options to ffmpeg.c i only have to document it in doc/ffmpeg.1, right?
[12:46:35] <siretart`> if you expect users to find them, that might be a good idea
[12:52:24] <CIA-92> ffmpeg: michael * r22051 /trunk/libavcodec/h264.h: unroll tiny and trivial loop. Same speed but clearer.
[13:08:42] <lu_zero> sigh
[13:08:51] <lu_zero> ok, I give up =_=
[13:09:04] <lu_zero> wsgi+roundup -> KaBoom
[13:09:31] <lu_zero> it's too underdocumented to have it working w/out trying with a from scratch test
[13:28:16] <KotH> wgsi?
[13:28:41] <kshishkov> wery shaky gateway interface, I suppose
[13:29:40] <phaidros> hi
[13:30:19] <kshishkov> KotH: why this channel topic cantains nothing about ignoring greetings?
[13:30:28] <phaidros> :D
[13:31:01] <phaidros> just wanted to ask if ffmpeg has any fixed point audio encoders aboard
[13:31:43] <phaidros> (asked before in #ffmpeg, but I believe here is the way better place to ask taht)
[13:31:53] <kshishkov> yes, aLaw/uLaw
[13:32:29] <kshishkov> and G.726
[13:32:41] <phaidros> kshishkov: are they suitable for music?
[13:33:05] <kshishkov> not very much
[13:33:13] <av500> adpcm?
[13:33:44] <kshishkov> ADPCM does not use floats in any representation
[13:34:21] <phaidros> hm, looking for any possiblity to make live streaming possible from a non-fpu plattform
[13:34:42] <Kovensky> libtremor?
[13:34:54] <kshishkov> Kovensky: it's for decoding only IIRC
[13:35:09] <Kovensky> ic
[13:35:15] <Kovensky> I thought they ported the whole thing
[13:35:50] <kshishkov> xiph.org mainpage: "Tremor: Fixed-point decoder"
[13:35:53] <phaidros> ack
[13:36:02] <phaidros> just cralwed through there ..
[13:36:10] <phaidros> well, there is a codec from xiph - celt - which is fixed point, but stll very much in development
[13:36:23] <Kovensky> celt is also optimized for voice
[13:36:28] <Kovensky> so it won't work for music
[13:36:28] <phaidros> irks
[13:36:47] <phaidros> darn. so, no way for doin such a thing?
[13:36:57] <kshishkov> sonic may work
[13:37:13] <Kovensky> wavpack? :)
[13:37:31] <kshishkov> that too
[13:37:38] <phaidros> ok, I'll give it a shot
[13:38:01] <av500> phaidros: IMA adpcm gives you 1:4 compression at almost 0 cpu
[13:38:03] <phaidros> so, basically, I could encode it on the device, deliver it to ffserver and there re-encode?
[13:38:18] <phaidros> av500: kay, so I'll try that first :)
[13:38:25] <av500> if you can live with ~300kbit/s audio, it is not bad
[13:38:47] <phaidros> fair enouhg for almost all state of the art internet use cases
[13:38:56] <Kovensky> wavpack OTOH is the slowest audio compressor I've touched... but I use it on highest settings lol
[13:39:50] <kshishkov> Kovensky: that means you've touched nothing else, I think. Flac compressor is pretty slow IMO. And APE...
[13:40:09] <Kovensky> reference flac encoder is p. fast, even on highest
[13:40:15] <Kovensky> ffmpeg with -use-lpc 8 however is SLOOOOW
[13:40:43] <lu_zero> ok
[13:40:46] <Kovensky> and I never used ape ._.
[13:40:53] <lu_zero> roundup had been fixed and updated
[13:40:55] <kshishkov> but better than official Flac encoder nevertheless
[13:41:10] <lu_zero> please try it a bit and report back if something isn't working as should
[13:41:13] <kshishkov> lu_zero: you forgot to say for which time
[13:41:19] <Kovensky> I have got higher bitrates with -compression_level 12 -use_lpc 8 than with just -compression_level 12
[13:41:31] <lu_zero> kshishkov: which time?
[13:41:52] <kshishkov> lu_zero: like "roundup had been fixed and updated for the fifth time"
[13:42:19] <kshishkov> Not found: roundup/ffmpeg/
[13:44:23] <lu_zero> kshishkov: switched to be saner...
[13:44:29] <lu_zero> roundup.ffmpeg.org
[13:44:36] <lu_zero> now I'll put a redirect
[13:49:11] <lu_zero> kshishkov: I added a redirect
[13:49:23] <lu_zero> so older urls will be still valid
[13:49:30] <kshishkov> seems to be slow but works
[13:49:30] <kshishkov> thanks, I'm too lazy to update bookmark
[13:49:41] <lu_zero> please test that as well
[13:49:43] <lu_zero> ^^
[13:50:37] * lu_zero checks who is messing up with the server 
[13:50:48] <kshishkov> lol, it redirects to ffmpeg.roundup.org
[13:51:36] <kshishkov> lu_zero: in my experience it's usually women and janitors who mess with servers
[13:54:13] <lu_zero> meh
[13:54:27] <Compn> what? no managers ?
[13:54:42] <Compn> 'if we turn this off at night, we can save money!'
[13:55:04] <lu_zero> fixing the typo...
[13:55:28] <kshishkov> no, it's usually janitors "_everything_ should be turned off at night"
[13:55:53] <kshishkov> managers issue a policy which can be ignored
[13:57:18] <phaidros> av500: which of the adpcm variants do you think is ok ?
[13:57:28] <av500> we use 4bit IMA adpcm
[13:57:36] <phaidros> k
[13:57:39] <lu_zero> seems working
[13:57:41] <kshishkov> almost everybody uses it
[13:57:58] <phaidros> ok
[13:58:07] <kshishkov> lu_zero: yes, it seems so
[13:58:11] <phaidros> this one then: adpcm_ima_dk4
[13:58:58] <kshishkov> lu_zero: except that it inserts second slash in URL after host name
[13:59:14] <kshishkov> phaidros: it's nonstandard
[13:59:45] <phaidros> kshishkov: puh, ok, still got to get familiar with ffmpeg, never used it before *duck*
[14:00:13] <kshishkov> phaidros: funny you mention that, it's Duck ADPCM actually
[14:00:24] <phaidros> :D
[14:01:19] <kshishkov> use adpcm_ima_wav
[14:01:29] <phaidros> ok
[14:01:39] * kshishkov still has to fix that issue with adpcm_ima_qt
[14:03:08] <phaidros> phew, your man page is huge.
[14:03:20] <kshishkov> good
[14:03:28] <CIA-92> ffmpeg: michael * r22052 /trunk/libavcodec/ (h264.c h264.h):
[14:03:28] <CIA-92> ffmpeg: Store intra4x4_pred_mode per row only.
[14:03:28] <CIA-92> ffmpeg: about 5 cpu cycles slower in the local code but should be overall faster
[14:03:28] <CIA-92> ffmpeg: due to reduced cache use. (my sample though has too few intra4x4 blocks
[14:03:28] <CIA-92> ffmpeg: for this to be meassureable easily either way)
[14:03:44] <phaidros> no clue, how to find quickly the comand line to capture from line-in and stream to remote server .. it'll take some time :)
[14:04:00] <kshishkov> ask at #ffmpeg
[14:07:28] <lu_zero> kshishkov: ok
[14:24:00] <phaidros> hm, where do I find out which settings a certain codec accepts? eg. adpcm_ima_wav which bandwidths etc ..
[14:24:51] <av500> bandwidth?
[14:24:55] <kshishkov> it's fixed
[14:25:06] <av500> it is a fixed 1:4 reduction
[14:25:16] <av500> a 4bit codec, so 16bit gets encoded to 4bits
[14:25:50] <phaidros> ok
[14:27:06] <CIA-92> ffmpeg: michael * r22053 /trunk/libavcodec/ (h264.c h264.h):
[14:27:06] <CIA-92> ffmpeg: Reorder intra4x4_pred_mode so that we can read/write 4 values at once.
[14:27:06] <CIA-92> ffmpeg: 3-7 cpu cycles faster
[14:29:45] <janneg> memtest86 with more than 4G is annoying, is there a memtest86_64?
[14:29:54] <kshishkov> could be
[14:30:42] <kshishkov> memtest86+ for example
[14:31:41] <av500> janneg: hmm my q8800 box has only 4g too :(
[14:32:26] <janneg> av500: my phenom has now 6G
[14:32:31] <kshishkov> my four boxes have 3G
[14:32:37] <kshishkov> total
[14:33:19] <janneg> I guess that means kshishkov can't help rendering Big Bug Bunny
[14:33:39] <av500> janneg: the qvga version maybe
[14:33:57] * kshishkov can dedicate his SheevaPlug for that when he's not transcoding h264 to something less CPU-hungry
[14:34:05] <Kovensky> rendering it smaller doesn't save much ram, it saves a lot of cpu though
[14:34:10] <av500> kshishkov: to libaa?
[14:34:37] <kshishkov> av500: mpeg2
[14:35:25] <BBB> lol @ libaa
[14:35:27] <janneg> fuck, errors
[14:36:04] <kshishkov> BBB: if you make TMV encoder, it'll become reality
[14:38:35] <janneg> Kovensky: yes, the tiled renderer failed also with OOM
[14:41:41] <ramiro> siretart`: ok, thanks for letting me know. it seemed to me all release-related discussion was going to /dev/null.
[14:43:34] <BBB> kshishkov, no
[14:43:39] <BBB> kshishkov, I'd rather do VP8 or so
[14:43:46] <BBB> at least then I learn something useful and fundable
[14:43:54] <kshishkov> I doubt so
[14:44:06] <kshishkov> and VQ is pretty powerful stuff
[14:44:39] <siretart`> ramiro: no, they are not. I am just increadibly busy this week, but fortunately, my paper deadline was extended by two weeks. this means I was able to finish testing the libx264 patch and therefore committed it
[14:45:16] <siretart`> ramiro: currently I have a debian bug reopened with a number of security issues that I need to verify, then I think the RELEASENUMBER thing is the last blocker for 0.5.1
[14:47:18] <BBB> ramiro, shall I handle conceiva?
[14:54:42] <mru> Yuvi: your mkv file works fine on the archos tablet
[14:54:57] <av500> mru: yes :)
[14:55:22] <CIA-92> ffmpeg: michael * r22054 /trunk/libavcodec/h264.h: Simplify intra4x4_pred_mode_cache init.
[15:04:41] <janneg> memtest86+ is indeed faster but still not native 64bit. at least the new memory seems to be fine
[15:13:17] <BBB> dondiego: any opinions on what to do with conceiva? do you agree with carl eugen?
[15:28:46] <CIA-92> ffmpeg: michael * r22055 /trunk/libavcodec/h264.h:
[15:28:46] <CIA-92> ffmpeg: Store data in direct_table interleaved.
[15:28:46] <CIA-92> ffmpeg: seems 20cpu cycles faster
[15:30:01] <CIA-92> ffmpeg: michael * r22056 /trunk/libavcodec/h264.c: Dont allocate direct_table 8 times too large.
[15:31:12] <DonDiego> BBB: looks *very* suspicious
[15:31:26] <DonDiego> i haven't followed the details
[15:31:49] <DonDiego> we could give them the benefit of the doubt and ask them what they were thinking
[15:32:05] <DonDiego> but it might well be just a case to hand over to the lawyers..
[15:34:38] <DonDiego> maybe ping them one more time and give them the benefit of the doubt
[15:45:29] <BBB> ok
[15:45:31] <BBB> I'll try it then
[15:45:44] <mru> Yuvi: and now my mkv demux handles that file too
[15:46:10] <mru> I hadn't bothered to add simpleblock before
[15:46:19] <mru> about time I did though, those files are getting common
[15:47:21] <DonDiego> "your" demux?
[15:47:23] <DonDiego> tcvp?
[15:47:28] <mru> yes
[15:47:39] <mru> archos uses that demux btw
[15:48:00] <DonDiego> go figure..
[15:48:01] <mru> av500 added the 2 lines for simpleblock himself
[15:48:01] * KotH senses some evil influence at archos
[15:48:13] <av500> mru: I did
[15:48:22] <DonDiego> mru: ogg blog post pending :)
[15:48:28] <mru> I didn't realise it was _that_ easy to do
[15:48:29] <av500> and I even offered you patches
[15:49:02] <mru> you wanted things in return
[15:49:13] <av500> it compiling, yes
[15:49:28] <mru> it does compile, after a fashion
[15:49:40] <av500> I dont follow fashions
[15:50:04] <mru> neither do I anymore
[15:50:13] <mru> the makefiles need rewriting
[15:50:27] <mru> fortunately that's mostly a matter of rewriting the script that writes them
[15:53:04] <av500> whatever you like, if it results in a configure file in the end
[15:53:20] <KotH> apropos configure file, what about ffconf?
[15:53:26] <mru> it's related
[15:53:44] <av500> KotH: before we do ffcc?
[15:54:01] * KotH wouldnt mind an ffcc
[15:54:22] <av500> we need it for ffcpu....
[15:54:22] * KotH wonders whether mn could be pestered enough to start it
[15:54:39] <KotH> ffcpu is more difficult, because that would require ffhdl too
[15:54:54] <av500> and ffphysics
[15:55:08] <mru> phphysics?
[15:55:10] <KotH> ffphysics is easy, just c&p from the next textbook ;)
[15:55:36] <kshishkov> just show me local opensource semiconductor fab
[15:55:48] <av500> fffab
[15:56:20] <kshishkov> ok, just tell me when I can move to FFearth in FFuniverse
[15:58:18] <KotH> kshishkov: you dont want an oss fab
[15:58:25] <av500> no, you have to stay in ogg/country, I am sorry
[15:58:40] <KotH> kshishkov: even if all OSS fanatics chipped in, it would be way too expensive
[15:58:57] <KotH> and you'd need people who are engineering types, not religious, to get it working
[16:00:42] <kshishkov> well, if can choose from Theora-style fab and FFmpeg-style fab you know what I choose ;)
[16:01:33] <mru> gates arranged in hilbert order?
[16:01:56] * kshishkov prefers dragon curve x 4
[16:18:59] <janneg> has anyone started working on broadcom crystal hd decoder support?
[16:19:14] <kshishkov> talking or developing?
[16:19:34] <av500> talking to pets and plant ok, but to chips?
[16:19:38] <janneg> developing. talking is cheap
[16:20:02] <kshishkov> av500: what is bus for?
[16:20:35] <janneg> electro shocks
[16:20:54] <av500> bus?
[16:21:07] <kshishkov> PCI, 1-wire, whatever
[16:23:03] <janneg> memory seems to be okay now after reseting BIOS settings
[16:25:45] <ramiro> BBB: yes, thank you.
[16:32:23] <DonDiego> ramiro: about conceiva_
[16:32:23] <DonDiego> ?
[16:32:32] <mru> deceiva...
[16:32:48] <Compn> janneg : doubt it, someone offered some money for such a thing on -devel
[16:33:00] <Compn> so if anyone wanted to take that job, he/she should reply to that message
[16:39:12] <CIA-92> ffmpeg: benoit * r22057 /trunk/libavformat/asfdec.c:
[16:39:12] <CIA-92> ffmpeg: asfdec: don't strip the "WM/" prefix, this should be done during conversion.
[16:39:12] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas gmail com
[16:40:26] <BBB> benoit-, can you apply his other 2 also?
[16:40:32] <BBB> (thanks!)
[16:44:15] <benoit-> BBB: I'm in the process of doing it
[16:46:53] <BBB> benoit-, thanks!
[16:47:20] <BBB> (otherwise he'd ask me to do it later today :) )
[16:48:30] <benoit-> :)
[16:48:50] <kshishkov> you can ignore this like all others did
[16:51:20] <CIA-92> ffmpeg: benoit * r22058 /trunk/libavformat/asfenc.c:
[16:51:20] <CIA-92> ffmpeg: asfenc: simplify writing of comment header.
[16:51:20] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas gmail com
[16:54:42] <benoit-> kshishkov: when I can, I prefer when there are not a hundred approved patches lying around
[16:55:14] * mru just wishes michael would unbreak the build
[16:57:42] <av500> mru: I just had an excoworker ask me to help unbreak it :)
[17:00:52] <CIA-92> ffmpeg: benoit * r22059 /trunk/libavformat/asfenc.c:
[17:00:52] <CIA-92> ffmpeg: asfenc: write tags in proper UTF-16.
[17:00:52] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas gmail com
[17:16:29] <ramiro> Yuvi: http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=8&t=1299
[17:16:39] <ramiro> Yuvi: I don't know if it makes any sense. Just reporting.
[17:38:13] <mru> http://pastebin.ca/1810424
[17:39:13] <av500> mru: nice
[17:39:20] <av500> saves you all the base13 stuff
[17:45:47] <janneg> 42
[18:35:09] <_av500_> janneg: lol @ the eye scene :)
[18:37:04] <_av500_> is there a reason ff is capped at 2kx2k?
[18:37:33] <_av500_> that's so 00s
[18:37:59] <mru> who's capped?
[18:38:11] <janneg> xv with my intel GMA3100 is capped to 2k^2
[18:38:25] <kshishkov> overlays are always capped
[18:38:27] <mru> my nvidia seems a bit unhappy too
[18:38:52] <_av500_> mru: swScaler: Compile-time maximum width is 2048 change VOF/VOFW and recompile
[18:38:56] <kshishkov> BTW, what's with internal swscale buffer limiting width to some constant?
[18:38:57] <janneg> -vo gl2 works
[18:39:23] <mru> _av500_: there's a compile-time limit for performance reasons
[18:39:42] <mru> increasing it also slows things down, at least on some systems
[18:39:48] <mru> and >2k is kinda rare
[18:39:50] <CIA-92> ffmpeg: michael * r22060 /trunk/libavcodec/svq3.c:
[18:39:50] <CIA-92> ffmpeg: fix compilation, sorry ive not checked cvslog for a while :(((
[18:39:50] <CIA-92> ffmpeg: svq3 decoder does not work yet though but i didnt want to keep compilation
[18:39:50] <CIA-92> ffmpeg: broken longer
[18:39:53] <kshishkov> since it's swscaler there are also legacy problems
[18:40:12] <kshishkov> mru: for movies only, that's why FFmpeg is not ImageMagick replacement yet
[18:42:38] <CIA-92> ffmpeg: michael * r22061 /trunk/libavcodec/svq3.c:
[18:42:38] <CIA-92> ffmpeg: svq3 now in working condition, at least vissually, ill let fate tell us
[18:42:38] <CIA-92> ffmpeg: if the checksums match
[18:44:05] <mru> kshishkov: true
[18:44:54] <kshishkov> could be good to have some fallback solution for huge images
[18:44:54] * Dark_Shikari points to coreavc's 2048 compile-time limit
[18:45:15] <kshishkov> BTW, 4x4 Binks can't be scaled too
[18:46:17] <Dark_Shikari> lol
[18:46:34] <kshishkov> you can try it
[18:47:22] <kshishkov> http://samples.mplayerhq.hu/game-formats/bink/thps4/Snd0a3a2ad4.dee
[18:49:45] <elenril> o_0 so many patches applied and i didn't have to do anything
[18:50:16] <kshishkov> try doing something bigger next time
[18:50:23] <elenril> :effort:
[18:50:37] <elenril> and i'd have to know c/how to program for that
[18:50:42] * kshishkov has started with REing simple decoders
[18:51:22] <janneg> elenril: the time machine is already finished?
[18:54:41] <kshishkov> machine for extending time should be ebough
[19:07:56] <phaidros> kshishkov: I prefer pausing time
[19:10:43] * kshishkov has lost his time remote controller
[19:15:09] <BBB> elenril, during my first programming, I kept wondering why sprintf(); did take a variable number of arguments but gtk_button_set_label() did not... point being, programming can be learned
[19:15:31] <BBB> I kept trying to compile gtk_button_set_label(button, "%s", some_argument);
[19:15:36] <BBB> it did not work :-(
[19:17:12] * kshishkov had his first programming under DOS
[19:21:41] <phaidros> av500: streaming kindof with adpcm_ima_wav runs, gets served ass ogg on ffserver, but no data coming through
[19:22:52] <phaidros> does anything here look suspicious? ffmpeg -f alsa -ar 16000 -ac 2  -i hw:0,0 -acodec adpcm_ima_wav http://some.host:8090/feed1.ffm
[19:23:45] <kshishkov> maybe it expects some video too?
[19:23:58] * kshishkov does not know ffserver
[19:37:54] <Yuvi> mru: av500: nice
[19:38:15] <Yuvi> turns out vlc will work if you add a fake cluster of size 0 at the beginning
[19:38:15] <Yuvi> but
[19:38:21] <Yuvi> that doesn't fix anything else
[19:38:47] <Yuvi> ramiro: vlc and mplayer really need to learn to seek in indexless files :/
[19:38:48] <Yuvi> I'll fix that though
[19:39:48] <CIA-92> ffmpeg: stefano * r22062 /trunk/doc/faq.texi: Replace not anymore valid syntax "-title X" with "-metadata title=X".
[19:40:05] <mru> Yuvi: I didn't try seeking
[19:40:42] <Yuvi> I don't expect seeking to work with unknown cluster sizes
[19:41:01] <Yuvi> that'd require a linear scan from where you are
[19:51:36] <DonDiego> j-b: what does vlc use for vorbis decoding?
[19:51:48] <DonDiego> j-b: ffvorbis is faster than libvorbis..
[19:52:06] <j-b> it has both
[19:52:26] <DonDiego> what is the preferred one?
[19:52:32] <j-b> but I believe libvorbis is still the prefered one
[19:52:59] <j-b> confirmed
[19:53:17] <j-b> but more and more packager are not packaging the vorbis module anymore
[19:54:50] <DonDiego> what about switching to ffvorbis?
[19:54:51] <DonDiego> :)
[19:54:56] <DonDiego> as i said, it's faster..
[19:55:15] <mru> and not xiph-encumbered
[19:55:25] <DonDiego> haha :)
[19:55:27] <j-b> well, what is clear, is that it won't happen now, before 1.1
[19:55:37] <DonDiego> oh, no hurry
[19:55:42] <j-b> but it will come
[19:55:43] <DonDiego> but what do you think about the idea?
[19:55:50] <kshishkov> VLC 1.1 or FFmpeg 1.1?
[19:55:54] <CIA-92> ffmpeg: stefano * r22063 /trunk/ (doc/libavfilter.texi libavfilter/Makefile tools/graph2dot.c):
[19:55:54] <CIA-92> ffmpeg: Add the graph2dot tools and document it.
[19:55:54] <CIA-92> ffmpeg: Also link avfiltergraph.o and graphparser.o against libavfilter, as it
[19:55:54] <CIA-92> ffmpeg: uses them.
[19:56:10] <j-b> especially since fenrir fixed a few issues in the avcodec module for vorbis/theora
[19:56:14] <j-b> lately
[19:56:17] <mru> kshishkov: 1.1 is when we've conquered the moon too
[19:56:22] <j-b> kshishkov: VLC 1.1.0 is in feature freeze
[19:56:56] <j-b> the thing is I am not so sure about vorbis 5.1 and 7.1 in both decoders
[19:57:12] <DonDiego> do you have samples?
[19:57:33] <peloverde> I thought superdump took care of taht for ffvorbis
[19:58:05] <j-b> problem is not ffvorbis, it is likely to be our module calling ffvorbis
[19:58:13] <j-b> that might screw the audio channels
[19:58:45] <Yuvi> didn't they change the spec as to the channel mapping?
[19:58:53] <Compn> downsampling ?
[19:59:23] <j-b> Yuvi: yeah, but I didn't follow it
[19:59:41] <j-b> mru: the problem is not really vorbis. Problem is ogg and theora
[19:59:49] <Yuvi> hehe
[19:59:57] <mru> vorbis is also full of flaws
[20:00:31] <peloverde> vorbis's flaws (at least the ones i know of) are largely fixable with a few minor changes, a vorbis 1.1 if you will
[20:00:38] <ohsix> lets not forget x86's flaws, we need to start at the root fo the problem and throw it all out
[20:01:42] <mru> peloverde: yes, they're mostly fixable
[20:01:51] <ohsix> then again, leakage increases with smaller geometry transistors; you dont have leakage problems with abacusii'
[20:03:00] <Yuvi> grr I hate trying to figure out which of the dozen gstreamer packages has the module I'm looking for randomly shoved in
[20:03:06] <j-b> mru: like all codecs
[20:03:24] <j-b> mru: but vorbis has less flaws than ogg, if I could compare
[20:04:05] <ohsix> Yuvi: huhu and they move around too :>
[20:05:04] <mru> the silliest thing in vorbis is that it can't be correctly decoded if not stored in ogg
[20:05:20] <Yuvi> this is only the third time I've tried, and I wasn't convinced I found the right module the first two times
[20:05:37] <Yuvi> (after looking through several thousand lines of boilerplate)
[20:06:02] <peloverde> mru: What about vorbis in mkv?
[20:06:13] <ohsix> theres a toplevel file that says whats in each but i dont remember what it was
[20:06:26] <peloverde> or are you saying it's not real vorbis because the screw with the header packets?
[20:06:57] <mru> peloverde: nothing in the vorbis setup data tells how many samples to discard from the start of the first frame
[20:07:22] <peloverde> shouldn't that be container specific data anyway
[20:07:23] <mru> you're supposed to divine that by comparing the number of actual output samples with the end timestamp from the ogg container
[20:07:39] <mru> so you can't output a single sample until you've decoded the entire first page actually
[20:08:06] <peloverde> I see that more as an ogg flaw than a vorbis flaw
[20:08:20] <mru> huh?
[20:08:22] <mru> it's both
[20:08:32] <peloverde> For AAC the codec doesn't tell you how many samples to discard, you are suppsoed to get it from the contaienr editlist
[20:08:40] <mru> a piece of required informatino is not specified by the codec
[20:08:53] <mru> then aac as the same flaw
[20:09:07] <ohsix> required for what; doing something a certain way? its different but it doesn't mean its wrong
[20:09:46] <mru> any codec with incomplete setup data is broken imo
[20:10:36] <peloverde> It seems simpler for the container to specify a consistent way to do it for all codecs than for each codec to come up with it's own scheme
[20:10:52] <ohsix> their deal is like; they split something thats normally in one layer into 3, like how stuff can be put in mpeg-ts being split into 2 layers; so the same junk can be used in several use cases while at least the 3 layers are the same
[20:11:41] <ohsix> raw bitstreams for some scenarios will be completely useless; they're supposed to have the other thing on top for that usage
[20:12:35] <peloverde> In the context of AAC you can't even playback a raw bitstream without sending side information to the decoder manually
[20:12:42] <mru> having a setup blob to be communicated out of band is fine
[20:12:58] <mru> relying on external framing is fine too
[20:13:19] <mru> anything beyond that is questionable
[20:13:46] <ohsix> its just my understanding; i'm indifferent, it makes some assumptions that you can nearly never hold for commercial bits you might want to include in the container, but it also assumes all the open bits can be available
[20:14:03] <peloverde> I think relaying on external editlists is fine as well
[20:14:11] <mru> I don't
[20:14:16] <mru> few containers have them
[20:14:18] <ohsix> its viral in some sense that you need to care that vorbis is in a basic stream :>
[20:14:38] <ohsix> don't those help with editing stuff in the containers?
[20:15:15] <ohsix> like for vorbis you can cleanly put partial pages into a stream, which are really whole pages, but the edit point can cross them partially
[20:18:24] <ohsix> it seems to me they might be trying to solve too many problems at once, but it also keeps you from picking possibly something proprietary "for purpose" for some specific usage scenario that their same project doesn't cover
[20:18:56] <ohsix> like it might all be well and good to use these native formats until you need to stream it to the web; then you have to pick something outside & suited for that
[20:20:27] <ohsix> mpeg does the same sort of thing except they have tons of standards and will fill behind or offer something else to cover the parts missing when something new comes out, and the other guys basically had to bootstrap themselves somehow
[20:21:30] <mru> the mpeg video codecs are entirely self-contained
[20:21:59] <ohsix> yea but for different usage scenarios you stay in their ecosystem
[20:22:10] <mru> I don't get your point
[20:22:15] <mru> or even that you have one
[20:22:37] <ohsix> any sort of usable alternate solution would have to have some complete ecosystem to draw from for any solution, instead of going to another one (mpeg) to furnish their use-case
[20:23:00] <mru> I don't understand what you're trying to say
[20:23:15] <mru> vorbis and aac rely on an obscure container field to be decoded correctly
[20:23:41] <DonDiego> maybe we should create that vorbis 1.1 :)
[20:23:47] <peloverde> Editlists are hardly obscure
[20:24:04] <mru> they are obscure if a minority of containers have them
[20:24:06] <DonDiego> trolling at its perfection :)
[20:24:17] <mru> and they're needlessly complicated for the job
[20:24:31] <mru> a single small integer is all you need to specify
[20:24:41] <peloverde> Two small integers
[20:24:51] <mru> two?
[20:25:15] <peloverde> extra samples at the begining and extra samples at the end
[20:25:24] <mru> ok then
[20:25:25] <mru> two
[20:25:29] <mru> hardly a big deal
[20:25:34] <mru> edit lists are much more complicated
[20:25:53] <ohsix> i'm just trying to elaborate on why they do things differently; they needed to provide their own ecosystetm with a least cost approach, and that makes the thing more complex than it needs to be to account for every case, but they dont have the luxury of having other bits to bring in _for_ every possible use case, and i'm talking about ogg, not vorbis in particular
[20:26:14] <mru> ohsix: you are not making any sense whatsoever
[20:26:15] <peloverde> because things like chapers may also dump you mid frame?
[20:26:19] <DonDiego> there was no need for them to invent their own container
[20:26:38] <DonDiego> there were plenty of general-purpose ones around
[20:26:52] <peloverde> What does the ogg approach solve that they couldn't have done with the mov approach or the mkv approach?
[20:26:58] <ohsix> DonDiego: yea there was, they needed to create an alternate and feasible ecosystem
[20:27:24] <mru> DonDiego: do you understand what he's blathering about?
[20:27:39] <ohsix> some people dont think you can just pick the best bits from wherever they're available; there are technical and legal reasons that might be involved
[20:27:48] <DonDiego> not for containers
[20:28:07] <DonDiego> legal issues exist for codecs
[20:28:17] <Yuvi> DonDiego: unfortunately, back when vorbis was first created, the only general-purpose containers were avi and mov
[20:28:24] <DonDiego> but for containers the motivation was NIH, nothing more, nothing less
[20:28:26] <ohsix> so what do you have if you have all the codecs and stuff free; but then you shove it into a container of someone elses purview?
[20:28:33] <Yuvi> the former can't handle vorbis at all
[20:28:33] <DonDiego> so?
[20:28:42] <DonDiego> ohsix: yes
[20:29:06] <Yuvi> the latter won't ever have a complete parser outside of classic quicktime
[20:29:12] <DonDiego> you also store it on filesystems you did not write
[20:29:19] <ohsix> that doesn't sit right; you should be able to do things within their ecosystem and without proprietary bits
[20:29:32] <DonDiego> and stream it over protocols you don't control
[20:29:50] <Dark_Shikari> duh, we need an ogg filesystem
[20:29:53] <DonDiego> there is nothing proprietary about avi or mov or other containers
[20:29:59] <Dark_Shikari> great idea.  we'll have no index, of course
[20:30:07] <Dark_Shikari> you'll have to binary search the disk to find any file
[20:30:14] <Yuvi> Dark_Shikari: they were talking about adding a gzipped index
[20:30:17] <Dark_Shikari> Yuvi: yeah I know
[20:30:25] <Dark_Shikari> they were also talking about Tarkin
[20:30:31] <Yuvi> hehe
[20:30:31] <Dark_Shikari> xiph likes to talk about things.
[20:30:42] <Yuvi> and multithreading libtheora!
[20:30:46] <BBB> Dark_Shikari, I saw a "discussion" on mozillazine, was that you?
[20:30:56] <Dark_Shikari> I don't post there
[20:31:07] <ohsix> you are leaving the ecosystem if you are looking for a 3rd party container format; you should be able to do that, fine. but the internal bits in the ecosystem should still exist
[20:31:21] <peloverde> And now that mov is 20 years old, why do they stick with ogg?
[20:31:27] <DonDiego> you also use a third-party compiler
[20:31:28] <Dark_Shikari> BBB: I assume you saw my blawg though
[20:31:46] <BBB> let me see
[20:31:51] <ohsix> DonDiego: you aren't trolling a blog post here :<
[20:31:51] <DonDiego> there is no need to reinvent existing wheels (badly)
[20:32:04] <DonDiego> you are the troll
[20:32:17] <Dark_Shikari> BBB: it got linked on HN, reddit, daring fireball, and a few dozen more
[20:32:21] <ohsix> DonDiego: the compiler is not part of the usage of the software,  it is not part of the "media" ecosystem, the problems the software purports to solve
[20:32:34] <ohsix> DonDiego: you are mistaken, you keep bringing up strawmen arguments
[20:32:41] <DonDiego> ogg does not solve any problem at all
[20:33:01] <DonDiego> and i'm not bringing up any straw men (feel free to point them out)
[20:33:01] <ohsix> ogg is something in their ecosystem; for their formats to be in; that solves their problem
[20:33:01] <peloverde> ohsix: simply what was the problem that ogg solved that mov did not?
[20:33:03] <Dark_Shikari> ohsix: why is the container part of the usage of the software, but the protocl is not?
[20:33:06] <Dark_Shikari> *protocol
[20:33:08] <Dark_Shikari> explain.
[20:33:20] <BBB> Dark_Shikari, I never read any of those
[20:33:23] <DonDiego> there is no need to create an ecosystem
[20:33:23] <BBB> but interesting read
[20:33:28] * BBB should make a planet FFmpeg
[20:33:30] <DonDiego> there is a need to create free codecs
[20:33:35] <ohsix> DonDiego: strawmen: 12:31 <@DonDiego:#ffmpeg-devel> you also use a third-party compiler
[20:33:37] <peloverde> ohsix: They also didn't invent PCM but they have no problem with that in their ecosystem
[20:33:54] <peloverde> they didn't invent FLAC but they welcomed that into their ecosystem
[20:33:55] <Yuvi> peloverde: branding!
[20:33:57] <DonDiego> those codecs can go in whatever container
[20:34:09] <ohsix> btw, the point of the starwman is to argue over the strawman, and that is exactly what is occuring with these kinds of digressions
[20:34:15] <Dark_Shikari> ohsix: you have yet to answer my question
[20:34:21] <peloverde> or mine?
[20:34:23] <Dark_Shikari> Why is the container part of the ecosystem, but the protocol is not?
[20:34:28] <ohsix> DonDiego: there is a need to create a reasonable and alternate ecosystem
[20:34:32] <Dark_Shikari> Why are PCM and FLAC allowed in their ecosystem?
[20:34:35] <Dark_Shikari> They didn't make them.
[20:34:43] <ohsix> you might say theres no point to the exercise at all if there isn't
[20:34:46] <DonDiego> alternative containers are reasonable
[20:34:48] <Dark_Shikari> If you cannot answer these questions, we will assume you are trolling.
[20:34:55] <DonDiego> so there is no need to recreate them
[20:35:03] <Yuvi> did they settle on a way to put pcm in ogg? I thought that was left as an incomplete draft
[20:35:11] <DonDiego> i fully understand the need to write vorbis and theora
[20:35:35] <DonDiego> unlike what other people claim i *never* questioned it
[20:35:52] <mru> Dark_Shikari: flac has an obnoxious raw format so that was acceptable to them
[20:35:55] <Dark_Shikari> mru: lol
[20:36:03] <peloverde> I agree vorbis serves a need, theora serves a need... poorly
[20:36:04] <DonDiego> of course you will want to have free sw implementations for containers
[20:36:11] <DonDiego> but these already existed
[20:36:33] <ohsix> Dark_Shikari/peloverde: you guys aren't trolling, DonDiego does this on the blog posts and threads and its counterproductive; its not even a discussion that should be had or have any energy wasted on, and he does so unconvincingly and in a manner that undermines whatever point he might have
[20:36:45] <Dark_Shikari> ohsix: But you still haven't answered our questions.
[20:36:54] <Dark_Shikari> I don't care about diego
[20:36:58] <Dark_Shikari> You haven't answered our questions.
[20:37:02] <Dark_Shikari> You're dodging them.
[20:37:26] <DonDiego> ohsix: which blog posts and threads?
[20:37:36] <ohsix> no, i'm simply talking to one person, you cant insert yoursel finto a conversation and just demand things if you want to be taken seriously
[20:37:51] <Dark_Shikari> um
[20:37:51] <mru> dude, this is irc...
[20:37:52] <Dark_Shikari> this is IRC
[20:37:54] <Dark_Shikari> lol
[20:38:00] <Dark_Shikari> "talking to one person"  "IRC channel"
[20:38:04] <DonDiego> lol
[20:38:07] <Dark_Shikari> If you want to talk to one person, feel free to take it to a PM
[20:38:08] <ohsix> peloverde: poorly or not its a separate conversation :>
[20:38:10] <DonDiego> ok, i'll ask the questions then
[20:38:10] <Dark_Shikari> Do you want to talk to one person?
[20:38:27] <Dark_Shikari> I could evacuate you from this channel then ;)
[20:38:32] <DonDiego> ohsix: what is in ogg that is not available elsewhere?
[20:38:35] <Dark_Shikari> then you could talk directly to one person ;)
[20:39:04] <ohsix> as to peloverde asking about MOV, it was besides my own point about the alternate software ecosystem, so it as factually offtopic (though apparently i'm not making my point well)
[20:39:33] <ohsix> a dogpile is not an effective rhetorical tool btw, if you had points; they are lost on me
[20:39:37] <DonDiego> there is no need to create a complete alternate universe
[20:39:40] <ohsix> and probably any unbiased reader
[20:39:54] <ohsix> DonDiego: that is an opinion
[20:40:07] <DonDiego> lol
[20:40:07] <ohsix> which i actually agree with
[20:40:20] <DonDiego> what was your point again then?
[20:40:25] <BBB> it's NIH... we all suffer from it
[20:40:25] <ohsix> but that is not the rationale behind having an alternate ecosystem, which also has merit
[20:40:26] <BBB> so do they
[20:40:28] <BBB> let's leave it
[20:40:48] <DonDiego> and which blog posts and threads do you refer to?
[20:41:05] <ohsix> DonDiego: you have no interest in understanding whatever point i could have possibly been making for the last half hour; asking me to repeat it is a strawman, my "posts" as it were are still there
[20:41:24] <DonDiego> i have interest in understanding
[20:41:29] <DonDiego> however, you do not answer questions
[20:41:43] <DonDiego> how do you expect anybody to understand this way?
[20:42:01] <ohsix> again, you essentially haven't asked an on topic question that i have not addressed according to the point i was trying to make originally
[20:42:09] <DonDiego> also, i'm not asking you to repeat: i'm asking for specifics
[20:42:30] <DonDiego> let me see...
[20:42:40] <iive> ohsix: you have addressed the question, but diego haven't understood it. try again.
[20:42:44] <ohsix> i want you to be more effective in trying to express your viewpoints; the only reason i _care_ is that you spend a lot of time just flaming people
[20:42:46] <DonDiego> 21:40 <@DonDiego> and which blog posts and threads do you refer to?
[20:43:09] <ohsix> for the sake of argument, all of them; you know that is another logical fallacy right
[20:43:29] <DonDiego> no, i want to know what you have read and what you are referring to
[20:43:37] <DonDiego> why can't you answer a simple question?
[20:43:58] <DonDiego> i want you to be more effective in getting whatever point you have across
[20:44:05] <DonDiego> so far you are failing miserably
[20:44:24] <DonDiego> i'm still talking to you because i'm interested to hear those points
[20:44:43] <ohsix> the way you may have asked that is "why dont you answer my questions in the manner i want you to", i'm being extremely clear what i'm trying to address with the way you are communicating _right now_
[20:45:04] <ohsix> you are badgering me and trying to force your point by mass of force
[20:45:10] <DonDiego> nonsense
[20:45:20] <ohsix> "why aren't you answering my questions" is the only real question you have
[20:45:29] <Yuvi> anyone know when microsoft first released asf?
[20:45:36] <DonDiego> i repeat: what threads and blog posts?
[20:45:55] <DonDiego> you refuse to give any details
[20:46:01] <Dark_Shikari> OK, let's have a summary here.  Ogg was useful at the time because neither AVI or MOV could stream.  DonDiego is being way overzealous.  ohsix is being an utter jackass troll as usual and completely ignoring every question he can't answer.  Both people should be kicked for a short period of time to cool down.
[20:46:05] <ohsix> point of fact; had i answered any question you would have missed it; and imo, you have already; so at least to this one unbiased observer your rhetorical style has failed to convince
[20:46:30] <DonDiego> do you think any person will accept a criticism of the type "you are behaving wrongly, change" without any further details?
[20:46:36] <ohsix> i'm not hot man, let me say again that i'm just worried that the way DonDiego communicates undermines his own cause and points
[20:46:45] <Dark_Shikari> ohsix: and the way you communicate doesn't?
[20:46:52] <Dark_Shikari> seriously, holy shit, you come off as a jackass with every phrase
[20:46:56] <Dark_Shikari> you attack your opponent's method of arguing
[20:47:01] <Dark_Shikari> instead of attacking his actual point
[20:47:01] <ohsix> i'm being extremely clear
[20:47:10] <Dark_Shikari> you don't answer any questions anybody asks of you
[20:47:14] <Dark_Shikari> you are a waste of air.
[20:47:15] <DonDiego> i disagree, you are not clear
[20:47:24] <DonDiego> i'm tryint to understand you and i fail
[20:47:26] <Dark_Shikari> But I think this has gone on too long.
[20:47:30] <Dark_Shikari> both of you need a break.
[20:47:39] <ohsix> you have a point there; except i am answering questions, but with the reams of comments you are expecting me to field; and with nobody giving my comments even due consideration, you have to agree that its tough to keep up
[20:48:03] <DonDiego> stop complaining, get back on topic
[20:48:19] <ohsix> i'm actually assessing everything people have to say, but inbetween the time a question is posed and an answer is expected is less than 2 lines, or i'm "not answering questions"
[20:48:24] <DonDiego> if you want to change my style you will have to be more specific
[20:48:40] <Dark_Shikari> can you two take this to a PM?
[20:48:45] <DonDiego> we have heard you
[20:48:46] <DonDiego> stop complaining, get back on topic
[20:48:49] <ohsix> i'm being extremely _pedantic_ in every manner which your rhetorical style falls flat to an unbiased observer
[20:49:30] <DonDiego> well, that settles it
[20:49:37] <Dark_Shikari> I think you should have been kicked too.
[20:49:39] <Dark_Shikari> you are not helping.
[20:49:59] <DonDiego> i was trying to stay on topic
[20:50:10] <DonDiego> and not flaming him harder than any of you
[20:50:10] <Dark_Shikari> staying on topic would be /ignore ing ohsix
[20:50:23] <DonDiego> you are right there
[20:50:43] <DonDiego> but everybody else would have earned a kick that way..
[20:50:56] <mru> I was talking about the aac and vorbis needing unusual container features, when he started blathering about ecosystems
[20:51:09] <DonDiego> right
[20:51:31] <mru> I wasn't even talking about ogg
[20:51:46] <iive> is this ohsix from xiph ?
[20:52:15] <Dark_Shikari> it's like that south park episode
[20:52:18] <Dark_Shikari> "this is what xiph actually believes"
[20:52:50] <mru> we should commission them do an episode
[21:08:15] <Compn> oh i missed flamewar
[21:09:38] <mru> not a good one
[21:10:38] <Dark_Shikari> let's start a good one then
[21:10:43] <Dark_Shikari> MKV is better than MP4.  Start now.,
[21:13:24] <mru> an mkv demuxer is actually easier to write
[21:13:36] <mru> but it could have been better
[21:15:21] <elenril> Dark_Shikari: is mp4 superior to mkv in anything?
[21:15:55] <Kovensky> the only benefit I see in mp4 is that it has broader hardware support, but that's an implementation artifact, not a design advantage
[21:15:58] <Compn> someone suggested to use mov up there any no one called him on it ?
[21:16:27] <Compn> peloverde said that heh
[21:16:58] <peloverde> I said that because mov was well established when vorbis was first publically released
[21:17:28] <peloverde> mkv didn't exist until the end of 2002
[21:17:29] <mru> mov is horrible
[21:17:40] <mru> mp4 is the non-horrible core of mov
[21:17:58] <Yuvi> elenril: mp4 has precise timestamps, mkv forces a single timebase for the entire file and you can't accurately represent most timebases in mkv's scheme anyway
[21:18:21] <Compn> arguing containers isnt very productive anyways
[21:18:29] <mru> and don't forget the 3 different ways of packing frames in a block
[21:18:30] <Compn> how did you guys let michael break svn ? :P
[21:18:46] <Compn> shouldnt fate send svn breakages to -devel ?
[21:18:53] <Compn> was that a requested feature or did we ignore that ?
[21:19:19] <Compn> 'danger' 'danger' 'svn is broken! in rXXXXX'
[21:19:47] <Kovensky> danger, will robinson!
[21:19:53] <Kovensky> er, michael!
[21:20:46] <Kovensky> Yuvi: mkv supports nanosecond timing
[21:21:03] <mru> Kovensky: so?
[21:21:11] <Kovensky> ... dunno
[21:21:26] <mru> if my timebase is 1000000+1/3 ns, that still won't do it
[21:21:36] <Yuvi> Kovensky: it doesn't support a timebase of say 1001/30000
[21:21:57] <mru> supporting arbitrary fractions is easy
[21:21:59] <BBB> all mkv movies that I've seen are rips from another source
[21:22:01] <mru> and covers everything
[21:22:04] <BBB> be that mp4, dvd or something else
[21:22:10] <mru> I've never seen 10*pi fps
[21:22:20] <BBB> mkv will never be superior if its source suffers from all these deficits that it's said to try to fix
[21:22:38] <BBB> </flame>
[21:23:06] <mru> mkv, like so many other things, aims too high
[21:23:11] <mru> it's trying to be all at once
[21:23:38] <mru> it should at least define common subsets
[21:24:13] <mru> so you know which parts can safely be skipped in an implementation
[21:24:47] <mru> and if possible make files play back sensibly when fancy features are ignored
[21:24:56] <mru> not the case with chapters for instance
[21:25:05] <mru> since they can be specify a non-linear playback sequence
[21:25:08] <mru> for no good reason
[21:25:26] <Kovensky> there is a good reason: because we can
[21:25:28] * Kovensky ducks
[21:25:44] <_av500_> mru: Yuvi: no we do not seek in mkv if no index
[21:26:01] <Kovensky> o_O
[21:26:49] <_av500_> as we come from deep embedded with little mem and a small window into a large file on a possibly slow mass storage device
[21:27:01] <_av500_> so, no index, no seek
[21:28:13] <CIA-92> libswscale: stefano * r30729 /trunk/libswscale/yuv2rgb.c: Apply consistency nit.
[21:28:13] <CIA-92> libswscale: stefano * r30730 /trunk/libswscale/utils.c: Remove pointless empty line.
[21:28:20] <_av500_> wrt flame, wasnt ogg all about having 0.002% overhead?
[21:28:53] <Yuvi> nah, it has more overhead than anything other than ts
[21:29:07] <Yuvi> nut was about lowest possible overhead though
[21:29:11] <Yuvi> partly
[21:30:01] <_av500_> lowest overhead: mandate fixed sized a and v frames and strict 1:1 interleaving :)
[21:30:08] <Dark_Shikari> that's high overhead
[21:30:10] <Dark_Shikari> it requires padding
[21:30:17] <Dark_Shikari> it just moves the overhead.
[21:30:27] <_av500_> the container comes clean :)
[21:31:02] <_av500_> crossbreed raw YUV and WAV/PCM :)
[21:31:29] <iive> nut doesn't mandate fixed size a/v frames.
[21:31:39] <_av500_> iive: no, that was my proposal :)
[21:32:04] <iive> anyway, mp4 subtitle support is kind of troublesome.
[21:32:11] <iive> mkv is better at that.
[21:33:05] <mru> iive: there's nothing in mp4 that makes subtitles inherently hard
[21:33:32] <iive> mkv supports external segments. many think of this as disadvantage.
[21:33:58] <mru> it's a whole new can of worms
[21:34:09] <mru> and mp4 can do such nonsense too
[21:34:13] * _av500_ does not support that and has yet to hear a complaint
[21:34:42] <iive> _av500_: just  join #mplayer.
[21:34:53] <_av500_> :)
[21:35:15] <elenril> iive: it's worse than that
[21:35:25] <elenril> matroska has three different kinds of linking
[21:35:50] <Yuvi> external segments are a bit easier to support in mp4/mov because the main file indexes everything, you only need to treat the additional files as different data sources
[21:35:55] <elenril> everybody uses ordered chapters, but still...
[21:36:02] <mru> matroska's motto: there are 3 ways to do it
[21:36:25] * _av500_ likes the "broken index, divide all by 10000000" ones
[21:36:38] <iive> mru: tell me more about the subtitles. formats etc.
[21:36:40] <mru> Yuvi: yeah, external files are just instead of mdat blocks
[21:36:54] <iive> btw, does mp4 support fourcc or llong codec descriptions?
[21:41:43] <iive> _av500_: btw, about the fixed size frames... ogg already does that!
[21:42:34] <janneg> libcrystalhd is ugly and C++
[21:42:52] <mru> is that from bcm?
[21:43:07] <mru> bcm can't write software
[21:43:21] <mru> and they use visual sourcesafe
[21:43:31] <_av500_> mru: add marvell, nxp, ti...
[21:43:32] <janneg> yes
[21:43:48] <mru> _av500_: very few hw companies can do sw
[21:43:57] <mru> intel are actually good at it
[21:44:06] <mru> and they can do good hardware too
[21:44:24] <_av500_> they will rule the pc business then one day...
[21:44:38] <mru> x86 instruction set aside, their cpus are pretty damn good
[21:44:42] <janneg> CamelCase of more than 7 words make my eyes bleed
[21:44:51] <mru> of course the best bits were stolen from DEC
[21:44:58] <_av500_> CamelCaseCaravan
[21:45:25] <mru> do you know where CamelCaseCameFrom?
[21:45:38] <_av500_> hell?
[21:46:47] <_av500_> NoIDontKnowWhereItCameFromButIWishItWentBackThere
[21:47:25] <Kovensky> CamelCaseIsActuallyConsideredGoodStyleInPopAndCuteLanguagesLikeJava
[21:47:33] <drv> from_somebody_without_underscore_keys?
[21:47:51] <_av500_> pwzstrAndTookStupidHungarianWithIt
[21:48:29] <Kovensky> _av500_: pwsz*
[21:48:42] <Kovensky> actually, lpwsz
[21:48:46] <_av500_> Kovensky: I got carried away...
[21:48:51] <Kovensky> :)
[21:49:28] <_av500_> pwszZeroTerminatedWideStringPointer ftw
[21:49:34] <Kovensky> I still facepalm when I remember Chen saying "How do I know he didn't double-null-terminate that string? Because his variable is pszVar, not pszzVar."
[21:49:55] <mru> apparently some old xerox machine had no _ on the keyboard so people were forced to invent workarounds
[21:50:08] <_av500_> double null for extra safety?
[21:50:12] <mru> becausecamelcaseisstilleasiertoreadthannothing
[21:50:21] <Dark_Shikari> Kovensky: Cheeeeeeeeeeeeeeeeeeeeeeeeeen!
[21:50:24] <Kovensky> _av500_: no, cheap way to get string arrays
[21:50:28] <Kovensky> Dark_Shikari: oh you
[21:50:40] <_av500_> pszzzzzzzzzzzzEmptyString?
[21:50:43] <Kovensky> _av500_: string1\0string2\0string3\0\0
[21:50:54] * _av500_ cries
[21:50:59] <mru> that's not a string array, that's a string list
[21:51:12] <mru> and not unreasonable in some situations
[21:51:28] <_av500_> Kovensky: without tripple null, how do you fit edit lists and externals?
[21:51:39] <mru> 2d arrays
[21:52:05] <mru> s00\0s01\0\0s10\0s11\0\0\0
[21:52:39] * _av500_ writes xml to n-null terminated string converter
[21:53:02] <Kovensky> .k _av500_ no: xml
[21:53:09] <Kovensky> :>
[21:53:41] * _av500_ writes ogg to n-null terminated string converter~
[21:53:47] <Kovensky> D:
[21:53:58] * Kovensky throws eggs at _av500_
[21:54:04] <Kovensky> egg > ogg
[21:54:08] * mru writes xml2ogg xslt
[21:54:24] <_av500_> Kovensky: for what definition of >?
[21:54:27] * Kovensky 's head asplodes
[21:54:56] <Kovensky> _av500_: test -gt
[21:55:11] * _av500_ proposes punycode for metadata tags instead
[21:55:43] <_av500_> artist: Bjrk-lol
[21:56:03] <Kovensky> wat
[21:56:19] <_av500_> artist: Mns-ftw
[22:09:26] <saste> are you guys using git for committing stuff to ffmpeg?
[22:09:37] <saste> my working copy is getting messier and messier every day
[22:09:49] <saste> and I feel the need to start to work with branches
[22:10:00] <mru> many of us use git
[22:10:00] <saste> the last time I did and attempt with git I gave up
[22:10:07] <mru> git svn clone svn://...
[22:10:22] <mru> it'll take a while to clone but then you'll love it
[22:10:27] <saste> because I failed to find some way to work with stack of patches
[22:10:39] <saste> yep I already did that :-)
[22:11:02] <saste> well I mean it is safe enough to *commit* using git2svn and what is it ...
[22:11:05] <saste> I suppose so
[22:11:21] <mru> sure
[22:11:36] <saste> I'm pretty used to how quilt works
[22:11:44] <mru> just prepare the commits you want to send in a branch and git svn dcommit
[22:11:56] <saste> ok
[22:12:13] <saste> what about guilt / st-git
[22:12:18] <mru> never used
[22:12:23] <mru> git branches work fine for me
[22:12:49] <DonDiego> saste: you should register your nick
[22:13:37] <mru> he did
[22:13:42] <mru> he just hasn't identified
[22:14:26] <mru> and you should use irssi, not xchat :-)
[22:14:26] <saste> give me some mintue...
[22:14:47] <mru> does xchat support sign-on scripts?
[22:15:08] <saste> the first I tried ... I was tempted to irc from emacs but then my emacs session is messed up enough
[22:15:29] <saste> mru: maybe
[22:15:46] <mru> there are a few emacs irc clients
[22:15:55] <saste> but as you know i'm quite an irc newbee and not very motivated into mastering it (no time)
[22:15:56] <Rathann> mru: yes it does
[22:17:00] <Rathann> mru: put "LOAD -e path/yourscript" (path is relative to $HOME) in connect command
[22:17:44] <Rathann> but if you just want to identify with nickserv, it has direct support for that too
[22:18:19] <mru> Rathann: I don't care about xchat, saste seems to be using it
[22:18:39] <Rathann> saste: ^
[22:22:19] <saste> Rathann: thanks I'll try that later
[22:23:03] <peloverde> Dark_Shikari, is psyrd on by default?
[22:23:26] <Dark_Shikari> yes
[22:23:33] <Dark_Shikari> as are a lot of other psy things
[22:24:01] <peloverde> Just curious because I was lookign at this comparison: http://keyj.s2000.ws/?p=356
[22:24:19] <Dark_Shikari> some stupid psnr thing?
[22:24:45] <peloverde> SSIM
[22:24:57] <Dark_Shikari> x264 should use --tune ssim for that
[22:25:03] <peloverde> I agree
[22:25:19] <peloverde> but even so, x264 still manages to destroy everything
[22:25:36] <astrange> the ffmpeg2/4 encodes are missing chroma me
[22:25:40] <mru> how'd they manage to push theora so high?
[22:25:49] <mru> it should be much closer to mpeg2
[22:25:53] <Dark_Shikari> mru: they added AQ
[22:26:10] <Dark_Shikari> AQ is like magic for SSIM
[22:26:12] <astrange> and scplx_mask, though that was never really effective
[22:26:44] <mru> lavc mpeg2 encoder can do really well if you tune it right
[22:26:52] <mru> and very, very poorly with bad (aka default) settings
[22:27:03] <Dark_Shikari> mru: it doesn't have vaq
[22:28:20] <Yuvi> I wonder how they managed to get dirac to be faster than x264 at any preset faster than placebo
[22:28:48] <Yuvi> even using schro
[22:28:52] <astrange> lavc mpeg2 has really bad blocking...
[22:29:02] <peloverde> yeah
[22:29:02] <Dark_Shikari> lavc mpeg2 just sort of sucks
[22:29:06] <Dark_Shikari> no psy optimizations
[22:29:43] <peloverde> How does QuEnc compare to lavc mpeg-2 these days?
[22:29:51] <Dark_Shikari> hcenc is the best iirc
[22:29:56] <peloverde> yes
[22:30:02] <peloverde> but quenc is a fork of lavc
[22:30:03] <Dark_Shikari> it's written in fortran
[22:30:08] <Dark_Shikari> (lol)
[22:30:54] <mru> whatever the likes of bbc use is pretty good
[22:31:04] <Dark_Shikari> >bbc
[22:31:05] <Dark_Shikari> >good
[22:31:07] <Dark_Shikari> have you SEEN their TV lately?
[22:31:13] <mru> no
[22:31:37] <mru> I've only watched the odd program on iplayer
[22:31:43] <mru> and that's a different story entirely
[22:32:17] <mru> but works and is easier than hunting stuff down on tpb
[22:32:35] <Yuvi> trellis 2 I guess
[23:07:26] <kierank> back in the mpeg-2 sd days anything involving scrolling graphics lead to massive blocks
[23:08:31] <mru> shouldn't simple scrolling be _trivial_ to code?
[23:08:38] <mru> if MVs are long enough
[23:08:54] <mru> i.e. theora is out
[23:08:59] <kierank> lol
[23:10:38] <Yuvi> as long as they move a multiple of subpel I guess
[23:11:00] <mru> how would they *not* do that?
[23:25:56] <iive> mru: bruteforce ME
[23:27:09] <mru> unless an idiot made the animation, motion would be in integral pixels
[23:27:32] <mru> anything else would look horrible
[23:28:43] <CIA-92> ffmpeg: mru * r22064 /trunk/common.mak:
[23:28:43] <CIA-92> ffmpeg: Disable suffix rules
[23:28:43] <CIA-92> ffmpeg: Most of the make builtin rules, which we do not need, are suffix rules,
[23:28:44] <CIA-92> ffmpeg: and we use only new-style pattern rules. Disabling suffix rules saves
[23:28:44] <CIA-92> ffmpeg: some time when building on slow systems.
[23:28:50] <iive> in these days, animation was made on film, like everything else.
[23:29:26] <mru> I thought he was talking about scrolling stock tickers and the like
[23:29:38] <mru> computer-rendered all the way
[23:31:03] <iive> graphics
[23:31:37] <mru> if it's on a raster display, it's graphics
[23:31:47] <mru> as opposed to a text-only display
[23:32:17] <iive> well, sharp edges and big uniform areas are hard for some algorithms.that relay on gradual improvement when getting closer to correct values.
[23:33:21] <mru> if there's an exact match for MC to work on there shouldn't be many problems
[23:33:30] <mru> as long as you spend enough bits on the keyframes
[23:34:03] <iive> it would be problem is how to find the exact match
[23:34:19] <mru> oh god, is this the day of idiots on this channel?
[23:35:28] <ohsix> i presume you mean me; thanks again
[23:35:32] <mru> Dark_Shikari: btw, speaking of AQ... has anyone experimented with using multiple quant matrixes and switching per MB?
[23:35:35] <iive> do you know how ME works?
[23:35:35] <ohsix> classy :)
[23:36:05] <iive> ohsix: btw, what is the url od diego's blog?
[23:36:11] <iive> od/of
[23:36:20] <mru> he doesn't have one afaik
[23:36:23] <ohsix> no idea, didn't know he had one
[23:36:34] <mru> the troll was talking about comments on other blogs
[23:37:20] <ohsix> who? what
[23:37:37] <ohsix> i'm getting the distinct feeling of passive aggressive behavior where even aggressive behavior isn't warranted
[23:37:58] <mru> ohsix: you accused DonDiego of trolling in blog comments
[23:38:01] <Dark_Shikari> mru: scrolling text is a bitch for algorithms without qpel
[23:38:13] <mru> ohsix: you refused to provide a reference
[23:38:28] <mru> Dark_Shikari: even with full-pel scrolling?
[23:38:37] <Dark_Shikari> That rarely happens
[23:38:47] <Dark_Shikari> most scrolling is not fullpel
[23:38:48] <ohsix> mru: i did not, thanks for knowing all the facts before casting aspersions yo
[23:39:03] <ohsix> if you have anything thats not a personal attack i'll still look at it as such
[23:39:58] <mru> 20:36 < ohsix> Dark_Shikari/peloverde: you guys aren't trolling, DonDiego does this on the blog posts and threads and its counterproductive
[23:40:02] <mru> so there
[23:40:30] <ohsix> yea
[23:40:40] <ohsix> you still dont know whats going on; so drop it please
[23:40:45] <Dark_Shikari> mru: with quant matrix per qp: theora supports that
[23:40:49] <ohsix> i understand that you might not like me personally, but that is off topic
[23:40:51] <Dark_Shikari> every QP has a custom quant matrix
[23:40:54] <Dark_Shikari> that's how QPs are _defined_
[23:41:00] <Dark_Shikari> so the quantizer scaling is arbitrary
[23:41:03] <mru> ohsix: you're a big, fat, lying troll, that's what's going on
[23:41:23] <Dark_Shikari> however, IMO, in the general case, CQMs are not very useful because most of their effect (if not more) can be performed via rounding differently
[23:42:09] <mru> oh, I thought the qp values were just scaling the same matrix differently or something
[23:42:59] <mru> I haven't looked at those things in detail since before ffh264 supported cqm
[23:43:26] <DonDiego> mru: leave ohsix be, we've had enough for tonight
[23:43:42] <mru> mpeg2 certainly has only one matrix each for intra and inter frames
[23:44:20] <mru> begone
[23:44:29] <Dark_Shikari> mru: it differs between theora and h264
[23:44:32] <Dark_Shikari> in theora, every QP defines a CQM
[23:44:37] <Dark_Shikari> in h264, every QP scales the CQM
[23:44:46] <mru> oh, so I wasn't entirely mistaken...
[23:44:47] <Dark_Shikari> thus theora is more flexible--but since it only allows 3 QPs per frame, it sorta sucks imo
[23:44:54] <mru> yeah
[23:45:00] <Dark_Shikari> if the two were combined, it woudl be very powerful
[23:45:03] <Dark_Shikari> well, if someone had an idea of what to do with it
[23:45:14] <mru> that's what I meant
[23:45:32] <CIA-92> ffmpeg: michael * r22065 /trunk/libavcodec/ (6 files):
[23:45:32] <CIA-92> ffmpeg: Get rid of mb2b8_xy and b8_stride, change arrays organized based on b8_stride to
[23:45:32] <CIA-92> ffmpeg: ones based on mb_stride in h264.
[23:45:32] <CIA-92> ffmpeg: about 20 cpu cycles faster overall per MB
[23:46:17] <iive> actually 2, inter/intra luma/chroma, indeed, not per qp
[23:46:27] <Dark_Shikari> and one per chroma plane
[23:46:30] <Dark_Shikari> you can differ between U and V iirc
[23:46:38] <iive> mpeg2 i mean.