[FFmpeg-devel-irc] IRC log for 2010-05-05

[irc at mansr.com]

[00:00:04] <mru> alloca is every bit as dangerous as VLAs
[00:00:10] <mru> in fact, it _is_ VLAs
[00:00:16] <mru> calloc is malloc+memset
[00:04:16] <Dark_Shikari> you should never be mallocing more than a constant number of times
[00:04:29] <Dark_Shikari> If you have a set of data that's variable-size based on whenever the function is called, keep a scratch buffer
[00:04:41] <Dark_Shikari> If you don't know the max size of the scratch buffer in advance, realloc (doubling size each time) if necessary
[00:04:46] <Dark_Shikari> it's still a constant number of malloc calls.
[00:06:39] <Dark_Shikari> for example, x264 has a big scratch buffer that's used by 5 different parts of the program.  not at the same time obviously.
[00:06:55] <Dark_Shikari> This gets you the advantage of alloca (cache coherence: they share the same scratch space)
[00:07:00] <Dark_Shikari> without the shittiness of alloca
[00:09:08] <BBB> hmk...
[00:09:11] * BBB goes home to sleep
[00:09:12] <BBB> tired
[00:09:25] <BBB> oh, and I won the prize for best talk in my school just now! \o/
[00:09:31] <BBB> time to celebrate
[00:09:33] <BBB> bye :)
[00:22:29] <mru> Dark_Shikari: and you know the size of that buffer
[00:22:35] <mru> you don't know the size of your stack
[00:22:59] <Dark_Shikari> mru: that was my point exactly
[00:23:04] <mru> the stack is possibly the most dangerous invention in the history of computing
[00:23:13] <Dark_Shikari> Now, personally, I think alloca _should_ be fine
[00:23:18] <Dark_Shikari> in that, if systems weren't shit
[00:23:19] <Dark_Shikari> it would be fine
[00:23:25] <Dark_Shikari> the two practical reasons it sucks being:
[00:23:35] <Dark_Shikari> er, ok, 3 practical reasons
[00:23:55] <Dark_Shikari> 1) on systems with crappy address spaces (too small), the stack is often not given enough space.  Or the system just sucks and won't grow the stack beyond like 2MB.
[00:23:57] <astrange> -fstack-protector is default on some systems now, isn't it?
[00:24:09] <astrange> doesn't solve the problem of an actual stack overflow crash though
[00:24:09] <Dark_Shikari> 2) I don't think it has a defined failure mode
[00:24:24] <Dark_Shikari> 3) gcc sucks, and fomit-frame-pointer doesn't work in functions using alloca.
[00:24:47] <astrange> also, you could av_fast_malloc a static buffer. iirc init_vlc doesn't have to be thread safe
[00:25:34] <Dark_Shikari> static writable buffers are kinda evil
[00:26:18] <Dark_Shikari> hmm.  how does linux handle growing the stack?
[00:26:35] <mru> page fault, swipe new page from system, map it in
[00:26:44] <Dark_Shikari> yes, but how does it guarantee a page fault?
[00:26:50] <Dark_Shikari> suppose you have 2mb of guard pages
[00:26:53] <Dark_Shikari> and your stack usage is 3mb
[00:26:54] <Dark_Shikari> what happens?
[00:27:12] <Dark_Shikari> on windows, in functions with large stack usage, it calls a function at the start that touches each page that it's about to use for the stack
[00:27:23] <Dark_Shikari> and thus it'll page fault if it goes beyond the currently allocated stack size
[00:27:30] <Dark_Shikari> and windows will allocate more pages for the stack
[00:27:50] <Dark_Shikari> I don't think linux has such a loop, so it's not guaranteed to be able to tell the OS how many pages it needs.
[00:27:57] <Dark_Shikari> so I'm curious what it does instead.
[00:28:12] <Dark_Shikari> ("just dies if the stack allocation is too large" is a perfectly valid, albeit stupid, answer)
[00:29:04] <mru> that's not really a windows vs linux thing
[00:29:09] <astrange> pretty sure it just dies
[00:29:22] <Dark_Shikari> mru: I know for a fact linux must do something different
[00:29:31] <Dark_Shikari> the windows ABI _requires_ you call that function if the stack usage > X, for some X I don't recall
[00:29:34] <mru> the kernel doesn't give a shit
[00:29:48] <astrange> os x x86-64 has a 56MB stack guard before the main thread, but it doesn't use it to extend it, and secondary threads only get 4kb stack guards
[00:29:51] <Dark_Shikari> So you're saying it just dies?
[00:29:51] <astrange> which is weird
[00:29:53] <mru> it's easy to write a function in windows that doesn't call that thing
[00:30:04] <Dark_Shikari> mru: then you've violated ABI, and your program crashes
[00:30:15] <Dark_Shikari> the point is, windows has a mechanism for automatically growing the stack.  as far as I can tell linux doesn't
[00:30:19] <mru> just like on linux, you _could_ explicitly touch every page
[00:30:30] <Dark_Shikari> but that doesn't help if you if the kernel isn't aware of it
[00:30:41] <Dark_Shikari> from astrange's description, it sounds like the stack is statically allocated in terms of virtual address space
[00:31:02] <Dark_Shikari> i.e. "you have this much address space for the stack.  we'll allocate the physical pages on demand.  if you run out of virtual address space, we'll kill your program."
[00:31:11] <mru> historically the unix virtual address space looked like this:
[00:31:38] <mru> |text|rodata|data|bss|heap    brk>             <stack      top|
[00:32:06] <mru> the heap grew linearly upward and the stack downward
[00:32:08] <Dark_Shikari> so in theory there should be no limitations on stack usage
[00:32:15] <mru> if they met in the middle, you died
[00:32:15] <Dark_Shikari> other than (heap + stack) < some max
[00:32:27] <Dark_Shikari> But I imagine that if you allocate, say, 200MB on the stack
[00:32:29] <Dark_Shikari> even if you have 2GB free
[00:32:31] <Dark_Shikari> it'll segfault
[00:32:35] <mru> try it
[00:32:38] <Dark_Shikari> because it won't know that you're trying to allocate a page on the stack
[00:32:44] <Dark_Shikari> It'll think it's just a random invalid pointer
[00:32:49] <Dark_Shikari> and segfault
[00:32:50] <mru> there may well be some heuristic to kill such behaviour
[00:32:57] <Dark_Shikari> ok, I'll try it
[00:33:17] <mru> allocating more than 1k per frame is stupid anyway
[00:33:25] <Dark_Shikari> well you need 4k
[00:33:26] <mru> even that is a lot
[00:33:27] <Dark_Shikari> a page ;)
[00:33:42] <mru> I've worked on systems where stack was 2k per process
[00:33:53] <mru> except for the rare ones that needed 4k
[00:35:14] <Dark_Shikari> it segfaults with 200MB allocated
[00:35:24] <Dark_Shikari> segfaults with 20MB
[00:35:32] <Dark_Shikari> works with 2MB
[00:35:57] <Dark_Shikari> it dies with about 8MB or above.
[00:36:15] <Dark_Shikari> You know, this really bugs me.  Because this is an x86_64 system and it should have all the address space in the fucking world to work with.
[00:36:41] <Dark_Shikari> I mean, sure, you shouldn't _do_ that, but it's not like the OS doesn't have the resources to handle it right.
[00:37:49] <mru> well, if you have a 4TB hole below the stack, at some point you'll have to assume a pointer has gone wild
[00:38:00] <Dark_Shikari> well 4tb is one thing
[00:38:03] <Dark_Shikari> 8mb is another =p
[00:39:02] <Dark_Shikari> interesting.  Windows has a max of 1MB by default, but you can set it in the linker.
[00:39:32] <Dark_Shikari> it has two values you can set: initially committed size and maximum size.
[00:39:37] <Dark_Shikari> which sorta makes sense.
[00:40:12] <mru> http://www.opengroup.org/onlinepubs/009695399/functions/setrlimit.html
[00:40:18] <mru> RLIMIT_STACK
[00:40:30] <mru> ulimit -s in the shell
[00:40:33] <Dark_Shikari> oh cool
[00:51:28] <astrange> In function 'skip_bits': warning: variable 're_cache' set but not used [-Wunused-but-set-variable]
[00:51:30] <astrange> so it is
[00:54:23] <astrange> huh, is that being emitted after optimization? if so it should be suppressed in macros
[00:54:58] <pengvado> astrange: init_vlc has to be as threadsafe as any other single-threaded piece of a codec. iirc libavcodec as a whole wants to be reentrant, right?
[00:56:39] <pengvado> Dark_Shikari: well, you could check %rsp whenever anything segfaults. though at some point you have to assume that something clobbered the stack pointer rather than that it actually allocated 4tb.
[00:57:00] <astrange> yeah, avcodec_open is explicitly not reentrant but the rest is
[00:57:35] <astrange> it would have to be thread-local which is annoying to use unfortunately
[01:00:18] <mru> pengvado: it's perfectly normal to pass addresses on the stack as pointers to other functions
[01:00:26] <mru> then the access wouldn't be through the stack pointer
[01:01:12] <astrange> i saw a valgrind tool that could track origins of pointers pointers but it bitrotted
[01:01:51] <pengvado> I didn't say anything about how the address was generated. rather, compare the address that segfaulted against the current value of the stack pointer.
[01:17:14] <mru> why does the current value of the stack pointer matter?
[01:17:34] <mru> there's a certain amount of virtual address space reserved for the stack
[01:17:41] <mru> stay within, and you're good
[01:20:49] <pengvado> so the no storing of data below the stack pointer (or below the redzone, if there is one) is entirely due to it getting clobbered by exception handlers, not memory allocation?
[01:22:44] <mru> yes
[01:26:25] <mru> ok, I don't know for sure that linux doesn't compare to the stack pointer on page fault
[01:26:59] <mru> but doing that would have little benefit, if any
[01:43:07] <Dark_Shikari> mru: ping
[01:43:39] <mru> pong
[01:43:51] <Dark_Shikari> so, I found out why their decoding was too slow
[01:43:57] <Dark_Shikari> YUV->RGB conversion in software, no asm
[01:44:02] <mru> hehe
[01:44:03] <Dark_Shikari> since swscale has no neon
[01:44:09] <Dark_Shikari> So, suppose they're not able to get access to the hardware for this
[01:44:17] <Dark_Shikari> How fast do you think you could do YV12->RGB32?
[01:44:24] <mru> *FAST*
[01:44:25] <Dark_Shikari> compared to C
[01:44:31] <Dark_Shikari> like, 5x-10x faster?
[01:44:40] <mru> 5x at least
[01:44:52] <Dark_Shikari> and how much work would it be?  i.e. what would you charge
[01:45:02] <Dark_Shikari> and could you add it to swscale?
[01:46:17] <astrange> iphone os 4.0 supports opencl
[01:46:39] <astrange> or so i'm told by an unreliable blog post, anyway
[01:46:43] <ohsix> peloverde: have you tried 10.04 yet?
[01:52:11] <RTFM_FTW> LOL you do NOT need OpenCL to blit from YUV <-> RGB :P
[01:52:20] <RTFM_FTW> complete overkill IMHO
[01:52:32] <Dark_Shikari> astrange: and yet it doesn't give you access to native conversion apis?
[01:52:35] <RTFM_FTW> specifically on a < iPhone, iPod Touch, iPad >
[01:53:01] <RTFM_FTW> you can do this sort of thing trivially through existing 3D APIs if its necessary
[01:53:02] <astrange> what's a native conversion api?
[01:53:06] <astrange> opengl works fine, yeah
[01:53:12] <Dark_Shikari> oh, you can, from appspace?
[01:53:14] <Dark_Shikari> that'll work then
[01:53:40] <RTFM_FTW> and ultimately OGL is likely how they are doing it (in a number of cases)...
[01:53:59] <RTFM_FTW> since the HW block isn't viable for everything :)
[01:54:06] <RTFM_FTW> *isn't necessarily
[01:54:15] <astrange> it would be interesting if libswscale had a libhwscale for that
[01:54:46] <astrange> as long as enough maintainers own programmable gpus
[01:55:07] <RTFM_FTW> in any case doing HW YUV -> RGB even in ES1 is significantly faster than through a SW path... 6x or more on average
[01:55:12] <RTFM_FTW> is what I've found
[01:55:30] <Dark_Shikari> would you have to use a shader to do the conversion?
[01:55:38] <Dark_Shikari> or can it do it on ipad natively?
[01:55:39] <RTFM_FTW> ES2 is likely better... OTOH you are killing the CPU with useless work in EITHER case
[01:55:58] <RTFM_FTW> anything capable of supporting ES2 can use the programmable fragment pipeline for this
[01:56:14] <RTFM_FTW> ES1 is fixed function so the work is slightly more challenging
[01:56:18] <RTFM_FTW> but its still quite possible
[01:56:36] <RTFM_FTW> I did both
[02:00:09] <Compn> libvo has lots of hw rgb scaling
[02:00:20] <Compn> opengl shaders ...
[02:00:29] <Compn> maybe d3d but i dunno...
[02:01:43] <RTFM_FTW> doing it in either API is pretty trivial
[02:11:47] <ohsix> RTFM_FTW: is a subset of quartz extreme available?
[02:12:32] <RTFM_FTW> QE has nothing to do with this on iPhone
[02:12:40] <mru> wtf, facebook popped up an error message in spanish
[02:12:42] <RTFM_FTW> i.e. its entirely irrelevant
[02:13:09] <ohsix> no doubt; just wondering if its available, they use it for a lot of stuff on osx
[02:13:35] <RTFM_FTW> in any case on iPhone etc. one has access to < ES1 and / or ES2 > through a dedicated 3D (i.e. MBX, SGX) path
[02:13:54] <RTFM_FTW> and with this one also has indirect access to a dedicated (HW) video decode pipeline
[02:14:04] <RTFM_FTW> which supports MP4 and H.264
[02:14:13] <RTFM_FTW> for anything else you are in SW land
[02:14:37] <RTFM_FTW> in any case QE just implies the use of GL for compositing
[02:15:29] <RTFM_FTW> on the desktop this means that the QE accelerated system has a HW renderer with support for GL_APPLE_client_storage, GL_APPLE_texture_range, GL_APPLE_ycbcr_422 and GL_EXT_texture_rectangle
[02:15:39] <ohsix> i know what gl can do; it was more of an aside, i haven't seen anything confirming or denying quartz composer could be used for stuff
[02:16:06] <RTFM_FTW> a very small subset of those (the last one) is currently available on iPhone
[02:16:31] <RTFM_FTW> QC doesn't exist on iPhone as far as clients are concerned
[02:16:42] <RTFM_FTW> and it wouldn't be used for this anyway
[02:16:59] <kierank> i wonder if the native h.264 interface will support the crazy number of slices Dark_Shikari is using
[02:17:04] <ohsix> i know, and i know what you can do with gl too; don't need to convince me :D
[02:17:17] <RTFM_FTW> on the desktop one also has access to GL_APPLE_rgb_422
[02:17:45] <RTFM_FTW> which gives you a direct (4:2:2) texture interface w/o server side YUV -> RGB color-space conversion
[02:18:06] <RTFM_FTW> since in a number of cases the server side color-space conversion isn't necessarily adequate
[02:24:12] <ohsix> nod
[02:25:06] <ohsix> a "hwscale" library would be kind of tricky if you actually needed readbacks
[02:26:44] <mru> depends on the hardware
[02:26:53] <mru> I've used hardware where it was very simple
[02:27:05] <mru> shared memory of course
[02:27:29] <ohsix> its about being worth it in terms of time in flight; it can get really expensive
[02:27:30] <astrange> opengl 2.0 has pixel buffers
[02:27:30] <astrange> *2.1
[02:27:48] <astrange> it does depend on the system bus but modern pcs can certainly handle it
[02:27:54] <mru> when your cpu is a 300MHz MIPS almost anything is worth it
[02:28:39] <ohsix> theres probably a local framebuffer on something like that
[02:28:51] <mru> shared memory
[02:28:54] <mru> all of it
[02:30:33] <RTFM_FTW> reading the FB is *always* going to be a losing proposition
[02:30:38] <RTFM_FTW> WRT performance
[02:30:49] <mru> look, there is no FB on this system I'm talking about
[02:30:53] <mru> it's all the same dram chip
[02:31:06] <RTFM_FTW> the best suggestion is to structure your algorithm(s) such that you don't have to do this
[02:31:08] <ohsix> i knowl but its not typical
[02:31:17] <mru> it's very typical of embedded systems
[02:31:26] <RTFM_FTW> if you are looking to target any GPU accelerated system
[02:31:37] <mru> like an omap3
[02:31:42] <RTFM_FTW> like anything
[02:31:49] <mru> arm and gpu share the same memory there
[02:32:01] <mru> and the display driver is quite separate
[02:32:12] <RTFM_FTW> even SoC suck ass when it comes to this particular feature
[02:32:15] <mru> also using the same ram of course
[02:32:26] <RTFM_FTW> and they suck ass not necessarily due to where the DRAM interface happens to be :P
[02:32:37] <ohsix> even with local memory, gpu regions are usually set uncached and readbacks still suck
[02:32:44] <mru> dedicated graphics memory is often better when you don't need readback
[02:32:58] <mru> only lazy people do that
[02:33:03] <RTFM_FTW> having to flush context state in order to read from FB memory isn't a cheap operation
[02:33:16] <RTFM_FTW> no matter *how* the memory interface is structured
[02:33:29] <ohsix> its cheaper with pbo's and fences though
[02:33:52] <RTFM_FTW> its only cheaper if you can interleave additional client side work with that operation
[02:33:56] <mru> cache flushes aren't *that* expensive
[02:34:00] <mru> if done right
[02:34:00] <RTFM_FTW> if you cannot then its not any cheaper
[02:34:11] <ohsix> nod; thats what fences let you do
[02:34:40] <RTFM_FTW> and that is entirely algorithm dependent
[02:34:48] <ohsix> mru: its more like a wait until fifo empty operation where almost everything is async
[02:35:07] <RTFM_FTW> WRT cache flushing being cheap that really depends upon the processor in question
[02:35:33] <ohsix> with fences though; you can query if your marker has made it out instead of implicit flush
[02:35:44] <RTFM_FTW> yup
[02:36:22] <mru> sometimes setting caches to write-through works best
[02:36:32] <RTFM_FTW> but as I said above this is still entirely algorithm dependent...
[02:36:44] <mru> if most writes are missing the cache anyway
[02:36:52] <RTFM_FTW> (concerning the efficiency of PBO etc.)
[02:37:08] <RTFM_FTW> that also BTW doesn't exist in ES :P
[02:37:49] <ohsix> its way too classy for ES :D
[02:38:13] <mru> generally speaking, sending a job off to another processing unit is worth it if the cost of communication is less than the cost of doing it yourself
[05:34:09] <KotH> god mordor!
[05:35:48] <elenril> morning
[06:00:07] <pJok> god morgon kshishkov :)
[06:00:47] <Dark_Shikari> kshishkov: see advice given earlier on yuv2rgb
[06:00:49] <Dark_Shikari> by pengvado
[06:07:23] <pJok> KotH, kshishkov simply walks into mordor!
[06:29:11] <peloverde> <insert obligatory comment about post-communist Ukraine being like Mordor>
[06:30:58] <Dark_Shikari> no, no, no
[06:31:22] <wbs> RTFM_FTW: btw, care to describe how you do yuv->rgb using ES1?
[06:31:36] <Dark_Shikari> russia == mordor (putin is sauron)
[06:32:24] <ohsix> you could snag it from gstreamers gl renderer :]
[06:38:04] <wbs> ohsix: I've actually looked at it, and it doesn't seem to support ES1
[06:38:29] <ohsix> if it has a fixed pipeline one its just a manner of moving some stuff around
[06:40:27] <ohsix> moblin has some stuff too
[06:43:02] <_av500_> bonjour mes enfants
[06:50:04] <astrange> matrix multiply can be done in es1.1 using glTexEnv
[06:50:07] <astrange> see http://developer.apple.com/iphone/library/samplecode/GLImageProcessing/Listings/Imaging_c.html hue()
[06:50:50] <ohsix> is imaging not optional with ES?
[06:51:41] <ohsix> i guess if its the iphone, and its right there; it doesn't matter
[06:52:29] <astrange> yeah
[06:52:40] <wbs> ah, I see, sneaky to do it in multiple passes. :-)
[06:53:12] <astrange> don't know how to do it in es1.0. maybe GL_MODULATE + additive blend + a lot of passes but it wouldn't be very accurate
[06:59:52] <siretart> buna diminaca
[07:19:19] <kshishkov> Dark_Shikari: ok, I'll try to implement it. Loongson has MMX too :)
[08:42:01] <CIA-7> ffmpeg: conrad * r23020 /trunk/libavformat/mov.c: mov: Read nero chapters
[08:42:01] <CIA-7> ffmpeg: conrad * r23021 /trunk/libavformat/movenc.c: movenc: Swap positions of mov_write_header and mov_write_packet
[08:42:02] <CIA-7> ffmpeg: conrad * r23022 /trunk/libavformat/movenc.c: movenc: Write QuickTime chapters
[09:39:50] <BastyCDGS> is there a nice macro for creating a grayscale RGB8 color value, i.e. FFGRAY(0xAB) will decode to 0xFFABABAB?
[09:40:21] <kshishkov> nope, *0x010101 | 0xFF000000 would do
[09:40:49] <BastyCDGS> I did this, but find this ugly:
[09:40:50] <BastyCDGS> const uint32_t gray_col = (i * 255 / count) & 0xFF;
[09:40:51] <BastyCDGS>                 pal[i] = 0xFF000000 | gray_col | (gray_col << 8) | (gray_col << 16);
[09:41:29] <wbs> #define GRAY(x) (0xff000000 | (x) | ((x) << 8) | ((x) << 16)
[09:41:33] <kshishkov>  well, 0xFF000000 | (gray_col * 0x010101) is a bit more compact
[09:41:52] <wbs> no need to have the framework define it for you if it isn't something that's universally useful
[09:42:02] <kshishkov> I don't think we had the need for such macro
[09:42:27] <_av500_> we wants colors, not grayscales
[09:42:55] <kshishkov> and if we want grayscales we output it as grayscale format
[09:42:58] <BastyCDGS> the thing is that if the IFF ILBM has no color map the standard defines to assume a default grayscale palette according to the formula above...
[09:44:34] <Kovensky> astrange: that sample you gave me yesterday doesn't build with suncc (cc -S test.c)
[09:45:10] <Kovensky> astrange: http://pastebin.org/202902
[09:45:24] <astrange> try -D__restrict=
[09:45:38] <astrange> + -fast, i think that's suncc -O3
[09:46:04] <BastyCDGS> well should I use PIX_FMT_GRAY8 instead then?
[09:47:01] <BastyCDGS> and just write the gray color index one time instead using the GRAY macro as above?
[09:48:03] <kshishkov> hmm, you have scaled grayscale palette
[09:48:37] <kshishkov> what values can that "count" variable take?
[09:49:13] <BastyCDGS> always a power of 2, i.e. 1 << bps (bps always <= 8)
[09:49:19] <BastyCDGS> bps = number of bitplanes
[09:49:29] <Kovensky> astrange: http://pastebin.org/202922 <-- cc -S test.c -fast -native -D__restrict=
[09:49:32] <kshishkov> ah
[09:49:51] <kshishkov> looks like you'll need to create that palette then
[09:49:57] <kshishkov> or scale output
[09:52:07] <astrange> wtf? even if it unrolls that loop all the way it doesn't need a huge stack like that
[09:54:21] <Kovensky> lol
[09:55:05] <astrange> the other small functions look like a generic function that was ported without using any special architecture features
[09:55:12] <astrange> (no sbb, no rorw(!))
[09:55:17] <astrange> *generic compiler
[09:55:31] <astrange> and unrolling a loop is useless on x86 anyway
[11:30:37] <mru> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[11:31:45] <mru> gcc 4.5 fails to build on arm, ppc, alpha, ...
[12:46:47] <freakabcd_> hi all
[12:47:43] <freakabcd_> is avpicture_get_size(PIX_FMT_RGBA, sx, sy) supposed to return a value of sx*sy*4 ?
[12:48:05] <kshishkov> strewth, no!
[12:48:28] * twnqx wonders what other value freakabcd_ would have expected
[12:48:32] <freakabcd_> kshishkov, was answer for me? i see no one called strewth here
[12:48:47] <freakabcd_> twnqx, it returns a different value :(
[12:49:06] <freakabcd_> eg: anim->x=320, anim->y=240, avipicture_get_size()=77824
[12:49:06] <kshishkov> freakabcd_: by golly, that answer was for you
[12:49:25] <twnqx> is it talk like a fisherman day?
[12:50:53] <kshishkov> have you read the comment in avcodec.h ?
[12:51:46] <freakabcd> lol, ok.. makes sense. returns 0 on success, -ve otherwise
[12:51:52] <freakabcd> wait no..
[12:51:55] <freakabcd> wrong function.
[12:52:12] <kshishkov> it's linesize * height
[12:52:26] <kshishkov> and linesize > width
[12:52:40] <twnqx> the number is too small. by a factor of 4.
[12:53:03] <twnqx> you have to multiply by bpp yourself, iirc
[12:53:13] <kshishkov> nope
[12:53:27] <freakabcd> twnqx, no it is not bpp
[12:53:37] <twnqx> but 77824 would suffice for one byte per pixel, which is not quite RGBA-ish
[12:54:14] <kshishkov> and with height like 240 you'd also get picture size divisible by ten
[12:54:17] <mru> rgba2222 :-)
[12:54:19] <twnqx> (unless you have 2 bits each for R, G, B, A)
[12:54:20] <twnqx> :D
[12:55:05] <kshishkov> mru: feel not free to add it to swscaler
[12:55:46] <freakabcd> ok, i don;t understand linesize
[12:56:15] <freakabcd> whats the definition of a 'line', sorry i'm new to ffmpeg (and video encofing/decoding, etc.)
[12:56:26] <kshishkov> one line of pixels
[12:56:34] <Tjoppen> linesize ~ stride
[12:56:38] <kshishkov> linesize is its length in bytes
[12:57:13] <kshishkov> and usually line size is made to be multiple of 16 or so
[12:57:42] <twnqx> kshishkov: then i don't get why he gets 77824 for avpicture_get_size(PIX_FMT_RGBA, 320, 240)
[12:58:11] <kshishkov> twnqx: neither do I
[12:58:25] <twnqx> good ;) (or not so much, but...)
[12:58:43] <freakabcd> yes, i don;t understand it.. i tried various multipliers to find some way to explain the difference in size but was unable to do so
[12:59:10] <freakabcd> another example: anim->x=720, anim->y=480, avipicture_get_size()=346624
[12:59:11] <Tjoppen> maybe it added a palette?
[12:59:22] <Tjoppen> (77824-1024)/240 = 320
[12:59:24] <twnqx> what is anim?
[12:59:36] <mru> well, you're all wrong
[12:59:45] <mru> because it returns 307200
[12:59:58] <kshishkov> only if you use it correctly
[13:00:01] <mru> which is 320*240*4
[13:00:04] <mru> kshishkov: :-)
[13:00:23] <twnqx> freakabcd: feel free to pastebin your code, not just a fragment
[13:00:24] <freakabcd> twnqx, a var of a different struct
[13:00:33] <freakabcd> twnqx, https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/imbuf/intern/anim.c
[13:00:34] <freakabcd> :D
[13:01:20] <twnqx> why do people use https for crap like that if they don't have valid certs...
[13:01:22] <freakabcd> its the blender code.. i'm trying to figure out why blender barfed saying FFmpeg changed alloc scheme
[13:01:24] <twnqx> not opening it.
[13:01:52] <mru> twnqx: probably becase getting a cert signed by a trusted authority costs $$$
[13:02:05] <twnqx> then don't use https
[13:02:06] <mru> we also use self-signed certs
[13:02:07] <elenril> >trusted
[13:02:09] <elenril> by whom?
[13:02:15] <twnqx> by my browser.
[13:02:38] <freakabcd> i dunno what the issue is what 'temporarily' accepting a cert for the blender svn repo
[13:02:41] <twnqx> freakabcd: might you by chance have multiple ffmpeg versions installed?
[13:02:44] <elenril> which is more secure how?
[13:02:47] <mru> a self-signed cert is as good as any for securing the link
[13:02:47] <freakabcd> twnqx, no
[13:02:55] <freakabcd> i have only latest
[13:03:19] <twnqx> mru: yes, but it requires loads of clicks and just uselessly encrypts a... OSS source code.
[13:03:33] <mru> twnqx: yes, in this case it's useless
[13:03:48] <mru> but sometimes passwords are sent over the link
[13:03:57] <mru> and then you'd rather have it encrypted
[13:04:17] <twnqx> yeah, for my own stuff i just imported my ca cert
[13:04:35] <twnqx> but self-signed certs are meaningless
[13:04:43] <mru> no they're not
[13:04:55] <twnqx> if someone can tap your link they usually can as well do mitm on your transaction
[13:04:57] <mru> there are other ways you could verify the signature
[13:05:02] <mru> like calling up the site admin
[13:05:05] <mru> if you know him
[13:08:53] <kshishkov> they should implement that on sourceforge
[13:10:42] <RTFM_FTW> astrange you don't need many passes for YUV -> RGB
[13:11:04] <RTFM_FTW> and you have support for DOT3 (through the FF texture environment) in ES1
[13:13:42] <freakabcd> bloody hell!! you were right.. the ubuntu guys left some libs in /usr/lib/i686/cmov
[13:13:43] <freakabcd> grr..
[13:14:02] <freakabcd> and i thoguth uninstalling the packages would have removed the files completely..
[13:14:09] <twnqx> > ubuntu
[13:14:10] <wbs> RTFM_FTW: but doesn't dot3 set the same value for all rgb components? how do you do do all of them in one pass?
[13:14:17] <freakabcd> removed those so files by hand and now it is perfect :D
[13:14:31] <twnqx> grats
[13:14:41] <freakabcd> good thing i decided to check with ldd which libs blender was dynamically linked to
[13:14:53] <mru> wasn't symbol versioning supposed to fix this?
[13:15:15] <twnqx> he's using ubuntu
[13:15:20] <twnqx> prolly means he's on 0.5
[13:15:33] <twnqx> versioning was newer, right?
[13:15:34] <mru> oh, wait... he's not linking against the libs whose headers he's using
[13:15:43] <thresh> symbol versioning doesnt fix the situation where you link with a library which is in its turn linked to some older library and you have some newer one
[13:15:49] <thresh> that, too
[13:15:59] <freakabcd> mru, i dunno what was happening.. for some reason ld was assuming the so files in /usr/lib/i686/cmov had higher (load)priority than the ones in /usr/lib
[13:16:27] <freakabcd> and the ones in /usr/lib were the ones from git and had the right symlinks and all
[13:17:15] <freakabcd> all i did was simply delete the so files from that other dir and everything was normal
[13:52:12] <Tjoppen> odd. the mov demuxer doesn't support "url " tags in the dref tags - only alis tags
[13:52:36] <kshishkov> maybe it was for security?
[13:53:04] <Tjoppen> "url " is just a normal URI.. and it does the security stuff in another place
[13:53:36] <kshishkov> randomly downloading stuff from elsewhere is not very secure
[13:53:48] <Tjoppen> ah, right
[13:54:42] <Tjoppen> one generally wants relative URIs anyway, which is what alis is for (sort of)
[14:23:59] <twnqx> audacious Commando.sid
[14:23:59] <twnqx> Format detected only with low score of 1, misdetection possible!
[14:23:59] <twnqx> [aac @ 0x19b3790]channel element 2.8 is not allocated
[14:24:03] <twnqx> >_>
[14:24:24] <kshishkov> so it detected audio!
[14:25:06] * twnqx demands .sid support in ffmpeg
[14:25:54] * twnqx reinstalls audacious-plugins with dedicated sid support
[14:26:23] <kshishkov> patchiswelcome
[14:26:50] <twnqx> increasing dependies is welcome? :P
[14:27:11] <kshishkov> and probably we'll get proper chiptunez support some day
[14:27:35] <kshishkov> no, no more external dependencies (except for other apps on FFmpeg)
[14:27:54] <twnqx> no going to copy&paste libsidplay into ffmpeg.
[15:38:37] <BastyCDGS> hi jai
[15:39:02] <BastyCDGS> I think I got it with extradata and backwards compatibility
[15:39:37] <BastyCDGS> the new decoder now detects if it's an old iff demuxer and behaves the old way then
[15:48:01] <BBB> I still think it's bad habit
[15:48:08] <BBB> what if you need to add new fields?
[15:48:28] <BBB> can you try using other AVCodecContext fields, or alternatively making it a single int32_t, and using it as a "flags" field?
[15:49:27] <BBB> and don't worry about alignment
[15:49:30] <BBB> the compiler will do that for you
[15:49:36] <BBB> please don't do things the compiler knows better than you
[15:49:50] <kshishkov> err, wrong channel?
[15:50:10] <mru> seems on-topic to me
[15:50:35] <kshishkov> "please don't do things the compiler knows better than you" - seems too rare for FFmpeg
[15:50:41] <BBB> haha :)
[15:50:48] <BBB> how's multirate support in .rm going?
[15:51:39] <mru> kshishkov: it's still true
[15:51:50] <mru> compilers get a few things right
[15:54:51] <BBB> particularly since any fixed alignment only works for a limited number of archs
[15:55:04] <BBB> "works" being "makes it better"
[16:01:04] <kshishkov> BBB: well, everything is stalled for now
[16:01:11] <BBB> :(
[16:01:29] <BBB> I wish I could help you move country in some way
[16:01:33] <kshishkov> and the worst part is that it seems my Gdium can't connect to WiFi anymore
[16:01:59] <kshishkov> BBB: thanks, but I'll stay here in Germany for a while
[16:02:13] <BBB> oh you're in a better country already
[16:02:15] <BBB> that's good
[16:02:19] <BBB> still not great, but good
[16:02:23] <BBB> how long are you there for?
[16:03:03] <kshishkov> dunno
[16:04:55] <BastyCDGS> BBB, oh just read it now
[16:05:23] <BastyCDGS> it's just have you read the critics from Martin on ml?
[16:05:40] <BastyCDGS> the extradata stuff should be backwards compatible
[16:08:11] <BastyCDGS> what is void *opaque?
[16:08:22] <BastyCDGS> can I use this instead of extradata?
[16:08:37] <BastyCDGS> hmm, docs say private data for user...
[16:09:52] <BastyCDGS> btw, seeing this I'ld like to add: #define FF_BUG_ADOBE       32768
[16:09:52] <BastyCDGS> the thing is that adobe photoshop writes wrong byterun1 encoded IFF files...
[16:10:15] <BastyCDGS> instead of handling -128 as noop it does a data decode...
[16:10:23] <BastyCDGS> (encode)
[16:17:39] <BastyCDGS> BBB, the new fields issue I added a comment to iff.h how to handle this (didn't create a patch yet for it):
[16:17:40] <BastyCDGS> /**
[16:17:40] <BastyCDGS>  * IFF extra context. This structure is appended to actual palette data.
[16:17:40] <BastyCDGS>  * Data is always stored in big-endian format.
[16:17:40] <BastyCDGS>  *
[16:17:40] <BastyCDGS>  * If you add new data here, please add a identifier tag != 0 before it
[16:17:40] <BastyCDGS>  * and check for the existence of identifier before accessing the new data.
[16:17:41] <BastyCDGS>  */
[16:18:51] <BastyCDGS> the structure itself is always memset'd to 0 bytes before doing anything else with it
[16:18:56] <BastyCDGS> so that should work fine.
[16:26:38] <BBB> you're using only 1 bit per four bytes
[16:26:42] <BBB> why not a flags field?
[16:26:46] <BBB> at least that's expendable
[16:27:37] <BastyCDGS> well I did in the first patch but Martin recommended to make them all byte only to avoid compiler aligning data structures
[16:28:07] <BastyCDGS> or do you mean byte flag fields?
[16:28:16] <BBB> I mean a flags field in which you store all bits
[16:28:17] <BBB> not just one
[16:29:29] <BastyCDGS> the thing is that transparency now starts on 4 byte boundary, if I remove ex->ehb and ex->ham it will start on 3 byte boundary
[16:29:39] <BastyCDGS> transparency is uint16_t
[16:30:08] <BastyCDGS> reading this will slow down if it starts on an odd address, so I either do a flags uint8_t and a uint8_t pad
[16:30:30] <BastyCDGS> or I do a uint8_t[2] and have AV_RB16 it...
[16:31:37] <BastyCDGS> masking and compression aren't bit flags
[16:31:50] <BastyCDGS> and transparency also isn't
[16:34:22] <BastyCDGS> or wait...what about this?
[16:34:38] <BastyCDGS> doing 2 flags? one uint8_t named palette_flags (for EHB)
[16:34:49] <BastyCDGS> and one uint8_t decode_flags (for HAM)
[16:35:02] <BastyCDGS> or bitmap_flags?
[16:40:32] <BBB> like I said, compilers do alignment for you
[16:40:33] <BBB> don't worry
[16:40:44] <BBB> compilers are really quite good at some things
[16:40:57] <BastyCDGS> yes but the problem is that it shouldn't align in extradata
[16:41:07] <BastyCDGS> just see Martin's comment in ml on that
[16:41:23] <BastyCDGS> it should be possible that a libavcodec on a totally different machine can also handle extradata
[16:41:27] <BBB> then add it to the end
[16:41:31] <BBB> the pallete data is aligned
[16:41:33] <BBB> first palette
[16:41:35] <BBB> then flags
[16:41:37] <BBB> instead of inverse
[16:47:19] <BastyCDGS> it's already at the end ;)
[17:04:45] <BBB> so how is it not aligned then?
[17:04:50] <BBB> add one int32_t
[17:05:17] <CIA-7> ffmpeg: cehoyos * r23023 /trunk/libavcodec/iff.c:
[17:05:17] <CIA-7> ffmpeg: Align plane size to word-boundary.
[17:05:17] <CIA-7> ffmpeg: Patch by Sebastian Vater, cdgs D basty A googlemail
[17:09:33] <BastyCDGS> BBB, you're misunderstanding me
[17:09:53] <BastyCDGS> the data structures in between should never be aligned by the compiler as in #pragma pack(1)
[17:14:42] <mru> warning: unknown pragma "pack(1)"
[17:15:14] <BastyCDGS> yes that's why I'm not using it but instead just use uint8_t
[17:15:31] <mru> because I don't know what it means?
[17:16:14] <BastyCDGS> it tells any compiler supporting it to pad all elements in a structure to 1-byte (i.e. turn off any padding)
[17:16:24] <mru> wrong
[17:16:29] <mru> in some compilers it might mean that
[17:16:42] <BastyCDGS> as said, any compiler supporting it ;)
[17:16:47] <mru> another compiler supporting something by that name might do something different entirely
[17:16:48] <Dark_Shikari> you'd use __attribute__((packed)) in gcc
[17:17:13] <BastyCDGS> do we have macros for this to do this platform independent?
[17:17:27] <mru> we don't do it
[17:17:37] <mru> it's always wrong to do it
[17:17:44] <BastyCDGS> so then it's the best way as I did it, just use uint8_t's?
[17:17:59] <mru> no, that's also wrong
[17:18:14] <Dark_Shikari> I can imagine it being useful to pack a struct in some cases
[17:18:18] <mru> you should never, ever rely on the precise layout of a struct
[17:18:20] <Dark_Shikari> but... in 99% of cases, there's a better way to do it
[17:18:23] <Dark_Shikari> well that's a given
[17:18:29] <Dark_Shikari> NEVER EVER assume a precise struct layout
[17:18:32] <Dark_Shikari> unless you're pengvado
[17:18:33] <BastyCDGS> should I remove the struct completely and do a #define OFFSET_BLABLA 0 etc.?
[17:18:44] <Dark_Shikari> BastyCDGS: if you need to know specific offsets, offsetof()
[17:18:48] <mru> I don't know what you're trying to do
[17:19:01] <mru> Dark_Shikari: that's solving the wrong problem
[17:19:08] <BastyCDGS> the thing is that the offsets have to be the same on ALL platforms/architectures ffmpeg supports/will support
[17:19:09] <Dark_Shikari> mru: well I don't know what his problem is =p
[17:19:22] <Dark_Shikari> BastyCDGS: why?
[17:19:23] <mru> I think he's trying to read/write a fixed-format data blob
[17:19:31] <Dark_Shikari> in that case you use the bitstream reading/writing functions
[17:19:32] <Dark_Shikari> hurr
[17:19:36] <BastyCDGS> sharing extradata
[17:19:40] <mru> or bytestream if everything is byte-aligned
[17:19:46] <Dark_Shikari> mru: off-topic, are there any real systems where NULL is not zero?
[17:19:55] <mru> never seen one
[17:19:57] <Dark_Shikari> Since we pretty much assume it is, and TECHNICALLY C doesn't require it
[17:20:03] <BastyCDGS> just read the reply to my patch from Martin
[17:20:05] * Dark_Shikari makes note to add it to x264's "standards.txt"
[17:20:16] <mru> Dark_Shikari: depends on what mean too
[17:20:43] <mru> a literal 0 in a pointer context is always a null pointer
[17:20:56] <BastyCDGS> the post at around 12:30 UTC from him
[17:20:56] <mru> and a null pointer always tests as false in an if() statement etc
[17:21:01] <Dark_Shikari> really?
[17:21:03] <mru> yes
[17:21:05] <mru> that's required
[17:21:17] <Dark_Shikari> so you're saying
[17:21:17] <mru> however, the bit pattern of a null pointer need not be all zeros
[17:21:19] <Dark_Shikari> if( pointer )
[17:21:23] <Dark_Shikari> is required to give the same results as
[17:21:25] <Dark_Shikari> if( pointer == NULL )
[17:21:26] <mru> yes
[17:21:34] <Dark_Shikari> hmm.  I don't recall the spec saying that.
[17:21:40] <mru> let me find it
[17:21:51] <Dark_Shikari> er, I mean if (!pointer)
[17:21:51] <Dark_Shikari> obviously
[17:22:14] <mru> yeah
[17:22:17] <mru> obviously
[17:22:21] <mru> didn't even see that typo
[17:22:33] <mru> section 6.3.2.3
[17:22:38] <BastyCDGS> well is there practically even any compiler doing NULL != 0 as int value?
[17:22:54] <Dark_Shikari> mru: c99?
[17:22:57] <mru> yes
[17:24:30] <Dark_Shikari> oh, so 0 HAS to be null
[17:24:32] <Dark_Shikari> there can be other values
[17:24:40] <Dark_Shikari> but pointers assigned a value of zero are also null?
[17:24:48] <mru> 0 converted to a pointer must give a null pointer
[17:24:51] <mru> not the other way around
[17:24:51] <Dark_Shikari> ah k
[17:25:00] <Dark_Shikari> and a null pointer converted to an integer must give zero?
[17:25:14] <mru> I don't think that's required
[17:25:23] <Dark_Shikari> but then those two ifs I gave above aren't equivalent
[17:25:29] <mru> the spec talks only about integer constant expressions
[17:28:02] <CIA-7> ffmpeg: cehoyos * r23024 /trunk/libavformat/iff.c:
[17:28:02] <CIA-7> ffmpeg: Parse IFF metadata.
[17:28:02] <CIA-7> ffmpeg: Patch by Sebastian Vater, cdgs D basty A googlemail
[17:30:59] <BBB> I remember some gstreamer asf demuxer bug
[17:31:07] <BBB> because someone had written it relying on padding in structs
[17:31:10] <mru> also, "the first substatement is executed if the expression compares unequal to 0"
[17:31:15] <BBB> he was basically doing read(fd, struct, sizeof(struct));
[17:31:17] <BBB> and it didn't work
[17:31:19] <BBB> :-p
[17:32:17] <mru> that's heresy
[17:36:05] <BBB> let me find the commit
[17:36:13] <BBB> I'm sure you'd remove my commit rights if you knew it was me
[17:42:20] <BastyCDGS> well, when we were young and juvenile we did all do such kind of errors ;)
[17:42:27] <BastyCDGS> no thing to worry about, BBB :)
[17:43:00] <Kovensky> ffms's index file format is just a memory dump of a struct
[17:43:07] <Kovensky> same for gcc's pch format, or so I heard
[17:43:38] <mru> if the file will only ever be used by the same app on the same machine, that's ok
[17:44:03] <BastyCDGS> yes mru and this was the problem I ran into with extradata ;)
[17:44:15] <BastyCDGS> it should be transferable between different machines
[17:44:36] <mru> so use the most suitable serialising tools we have
[17:44:46] <mru> bytestream.h and get/put_bits.h
[17:44:47] <TheFluff> the index files are not exactly supposed to be distributed
[17:44:51] <Kovensky> if C had reflection one could write a struct (de|)serializer :)
[17:45:03] <mru> but then it would cease to be c
[17:45:09] <Kovensky> indeed
[17:47:29] <mru> I once made a system where both structs and [de]serialising code were generated from a separate description
[17:47:41] <mru> many such systems exist
[17:48:22] <Kovensky> make each struct a linked list of key/value pairs? :)
[17:48:56] <mru> the same tool that spits out struct defs can spit out code to deal with them
[17:49:06] <Kovensky> struct generic_struct { char *key; void *value; intptr_t valuelen; struct generic_struct *next; };
[17:49:09] * Kovensky runs
[17:50:47] <Kovensky> mru: that'd be easy to make in perl + yaml
[17:52:00] <mru> oh, there's some lovely perl code in there
[17:52:21] <Kovensky> <3
[17:52:24] <mru> /event\s+(\w+)\s*((\w+%([IiUufcsp](\[(.*?)\])?)\s*)*)/
[17:52:40] <mru> ^^ there's a sample
[17:53:14] * mru tries to remember wtf that does
[17:53:38] <mru> not the regex, but the text it matches
[17:53:54] <Kovensky> \w+\s*\w+ is not really deterministic ._.
[17:54:03] <Kovensky> well, it may be, but it's weird anyway
[17:54:18] <mru> + and * are greedy
[17:54:39] <Kovensky> so "aaaaaaaa" would be grouped as "aaaaaaa" and "a"?
[17:54:51] <mru> probably
[17:54:57] <mru> and that's probably a bug in the code
[17:55:01] <mru> not that it ever mattered
[17:55:49] <Kovensky> I think both those \s* are wrong, but if it worked, it worked
[17:56:00] <mru> in fact, I'm running code generated by it right now
[17:56:20] <mru> there's only one \s*
[17:56:23] <mru> the other one is +
[17:56:36] <Kovensky> no, there's a \s* near the end
[17:56:41] <mru> right
[17:56:49] <BastyCDGS> hoyos asked me if there's an OK from a maintainer for applying the heavy optimize patch for decodeplane8...
[17:57:16] <Kovensky> talking about optimize, my audio stuff sure puts a lot of heap pressure...
[17:57:18] * peloverde thinks he's going to have to completely replace the AAC channel configuration scheme
[17:57:50] * peloverde facepalm
[17:58:06] * Kovensky pats pentanol
[17:58:08] <Kovensky> durf
[17:58:10] <Kovensky> peloverde*
[17:58:14] * Kovensky slaps irssi
[18:08:36] * twnqx slaps Kovensky 
[18:12:02] <BBB> http://webcvs.freedesktop.org/gstreamer/gst-plugins/gst/asfdemux/asfheaders.h?hideattic=0&view=diff&r1=1.2&r2=1.3
[18:12:05] <BBB> there we go :)
[18:12:07] <BBB> that was the commit
[18:12:38] * BBB awaits mru to flame him
[18:13:01] <BastyCDGS> hey could someone add me to the list of assignable to bug in roundup.ffmpeg.org?
[18:13:07] <BastyCDGS> want to assign me to the IFF stuff
[18:13:34] <kierank> oh lawd cvs
[18:15:07] <BBB> http://webcvs.freedesktop.org/gstreamer/gst-plugins/gst/asfdemux/gstasfdemux.c?annotate=1.4.4.1&hideattic=0 <- line 975 actually uses it for I/O
[18:24:33] <jai> BastyCDGS: just attach your patches to the report
[18:24:57] <BastyCDGS> also the ones which are already on git now?
[18:25:36] <jai> i meant any patches which fix said issues
[18:30:49] <BastyCDGS> https://roundup.ffmpeg.org/issue1727
[18:41:28] <BastyCDGS> I also was able to reproduce https://roundup.ffmpeg.org/issue1895
[18:41:28] <BastyCDGS> on x86_64 and x86_32
[18:41:51] <BastyCDGS> so I tagged this from new to open/reproduced
[18:54:39] <peloverde> Implicit PS works, it's hideous but it works
[18:55:01] <_av500_> and it switches from mono to stereo?
[18:56:17] <peloverde> If there is SBR it always decodes mono as stereo
[18:56:34] <_av500_> ok
[18:56:35] <_av500_> ok/win 10
[18:57:27] <JEEBsv> hmm, not sure if this is the right place to ask, but are there any spec pdfs for mpeg transport streams?
[18:57:41] <_av500_> the specs
[18:57:52] <janneg> 13138-1
[18:58:39] <JEEBsv> thanks, will see if I can find that one on the 'webs :3
[18:59:20] <janneg> err 13818-1
[18:59:46] <JEEBsv> yeah, that first one got me some swimming aids ^^;
[18:59:57] <_av500_> it is a kind of transport
[19:00:06] <_av500_> in streams
[19:00:55] <JEEBsv> I kind of thought about reading on it, since it's currently the one format where quite many apps stumble
[19:01:12] <mru> it's a good read
[19:01:18] <_av500_> ?
[19:01:24] <mru> 13818-1
[19:01:31] <BastyCDGS> guys I did mark this one https://roundup.ffmpeg.org/issue1427 as duplicate
[19:01:34] <BastyCDGS> and closed it
[19:01:35] <_av500_> damn, i lag like hell
[19:03:56] <janneg> JEEBsv: which apps? reading or writing?
[19:06:06] <JEEBsv> janneg: well, let's just say "many" for frame-exact seeking etc. I'm not sure if ffmpeg itself is bad at it, but ffms2 and mplayer do fail gorgeously with ts files from time to time. I'm just interested to learn about the spec myself, so that I migh some day help people write better software. As for writing, I know that kierank is making a muxer at least.
[19:06:59] <mru> frame-exact seeking in ts is impossible w/o pre-parsing the file or on the fly index building
[19:07:22] <_av500_> or a lot of seek() ops
[19:08:06] <BastyCDGS> stupid_seek() => takes one random offset in the file and trys to decode if wrong frame choose another random offset and do the same until...:D
[19:08:29] <JEEBsv> mru: yeah, I know that :)
[19:08:54] <BastyCDGS> will deliver a patch now *gg*
[19:08:57] <mru> that's called monkeyseek
[19:09:07] <mru> there's also monkeysort
[19:09:14] <BastyCDGS> stupidsort yes ;)
[19:09:22] <BastyCDGS> that's what I was thinking off ;)
[19:12:12] * JEEBsv kills some trees with 13818-1
[19:15:04] <mru> hmm, ps reports ffmpeg using 102% cpu on a single-core system
[19:15:13] <mru> rock on, ffmpeg!
[19:15:38] <JEEBsv> now to get ARIB stuff for on the Japanese transport stream stuff too >_>
[19:16:10] <BastyCDGS> so you applied my monkeyseek patch? :D
[19:17:24] * elenril wonders what is up with seeking in flac
[19:17:41] * _av500_ seeks in flac happily
[19:17:49] <elenril> not with lavf
[19:17:55] <BastyCDGS> btw, does ffmpeg support flac's > 4GB?
[19:17:58] <mru> if you need to seek, the film/song isn't good enough
[19:18:06] <BastyCDGS> or at least > 2GB?
[19:18:12] <jai> elenril: is there a bugreport?
[19:18:31] <elenril> dunno, Justin said it was on his todo list
[19:18:31] <BastyCDGS> mru, depends I have flac files in 24bit/96kHz which are over 7h
[19:18:38] <BastyCDGS> it's a DJ remix I did some years ago
[19:19:12] <BastyCDGS> btw I meant encoding flacs > 2/4 GB
[19:19:26] <mru> why would you have such a file?
[19:19:27] <BastyCDGS> with the normal cmd line tool I was only able to do this via raw pipe
[19:19:30] <mru> why not split it?
[19:20:17] <BastyCDGS> because it should also be shared as one file and should be considered as one track
[19:20:22] <jai> elenril: do you have a sample?
[19:20:31] <elenril> jai: of what?
[19:20:46] <jai> elenril: flac where seeking breaks
[19:20:50] <elenril> all of them
[19:21:03] <elenril> seekin is just not implemented
[19:21:09] <BastyCDGS> -rw-r-----  1 basty users 2963173677 2005-12-07 10:32 DJ Sets - Basty - Flower Of Life @ Home (XXL MerKaBah RMX).flac
[19:21:11] <mru> if it really should be considered one track, you should obviously listen to it from beginning to end
[19:21:16] <mru> otherwise it's not a single track
[19:21:45] <BastyCDGS> I usually do ;)
[19:21:49] <jai> elenril: uh, yeah, sorry
[19:21:50] <ohsix> thats usually what you patronize a dj for
[19:21:57] <BastyCDGS> but sometimes I also want to listen to parts of it (highlights etc.)
[19:22:28] <jai> elenril: i should've realized this was about raw flac
[19:22:30] <jai> hmm
[19:22:36] <_av500_> elenril: i just seek by bitrate and file size
[19:22:42] <_av500_> nobody ever complained
[19:22:51] <_av500_> but that is not pc in ffmpeg i think
[19:23:06] <elenril> _av500_: send patches!
[19:23:21] <_av500_> hmm
[19:23:46] <_av500_> need to port my stuff to lavf
[19:24:21] <BastyCDGS> I would also be glad on some infos for seeking (what ways are supposed to be to do this in ffmpeg etc.)
[19:24:32] <BastyCDGS> I'll need this for mod de/encoder later and also for IFF-ANIM ;)
[19:26:54] <BastyCDGS> btw, mod handling should be done in a way it either can decode to PCM or sth. alike that or to a ffmpeg mod structure which can then used by another mod encoder to convert the file
[19:27:36] <jai> yes
[19:28:52] <BastyCDGS> I suggest libavmodule as a name for ffmpeg mod structure ;)
[19:30:08] <jai> :S
[19:30:22] <Dark_Shikari> libavlibrary
[19:30:29] <jai> i don't think it needs to be a separate lib
[19:30:41] <Dark_Shikari> libavflame
[19:30:46] <Dark_Shikari> produces mailing list flames for ffmpeg-devel
[19:30:53] <BastyCDGS> lol
[19:31:08] <ohsix> a bike shed that paints itself
[19:31:14] <BastyCDGS> jai, but it probably would then maintain better
[19:31:20] <jai> BastyCDGS: why?
[19:31:23] <BastyCDGS> mod is really pretty different than usual sound/image stuff
[19:31:44] <jai> maybe, but that alone isn't a good enough reason
[19:31:46] <Dark_Shikari> ohsix: libavbikeshed
[19:32:01] <BastyCDGS> I mean it also for the tracker stuff itself, i.e. convert from mod to mod, mod to PCM will of course be as normal as it is avformat/avcodec
[19:32:27] <jai> also, you should dump all your design notes/whatever on the ML sooner rather than later, michael will surley have some comments
[19:33:03] <jai> *surely
[19:33:42] <BastyCDGS> maybe it's very good possible without a new libavmodule or sth. like that
[19:33:54] <jai> i'd suggest that
[19:34:04] <jai> of course, not my call :)
[19:34:26] <elenril> so where's libavcc
[19:34:52] <ohsix> libavdrcorcdspcc
[19:35:07] <mru> isn't a mod file just a bunch of samples and instructions on how to combine them?
[19:35:17] <jai> yes
[19:35:25] <BastyCDGS> the very original mod format from amiga was ;)
[19:35:39] <jai> even the later ones i'd say
[19:35:47] <BastyCDGS> but newer trackers have complete synth sound handling stuff (like OPL2/3)
[19:35:47] <jai> they just got more "exotic"
[19:35:50] <_av500_> libavjustabunchofsamples
[19:36:26] <mru> should still fit nicely into the audio decoder api
[19:36:46] <mru> encoded data in, pcm samples out
[19:37:02] <BastyCDGS> that's the one part, but I want it also to convert from mod to mod
[19:37:10] <BastyCDGS> e.g. xm to it or vice versa
[19:37:38] <BastyCDGS> maybe even PCM to it (could just create a set of pattern/orderlist/samples with a tick interval when to play next PCM sample
[19:37:43] <jai> libavformat/[mod|xm|s3m].c -> AVPattern
[19:38:00] <jai> AVPattern -> renderer -> pcm samples
[19:38:23] <jai> and muxers could work similarly from the internal representation
[19:39:02] <jai> and extend this basic design for those "exotic" trackers you mention :)
[19:39:39] <BastyCDGS> here you find some millions of mod for testing for later :)
[19:39:39] <BastyCDGS> http://modarchive.org/
[19:39:58] <BastyCDGS> there are still some 20 mods added per day
[19:40:18] <jai> i still have an old drive with my mod collection
[19:41:18] <jai> that being said, i still wonder why we want to replicate libmodplug...
[19:41:56] <BastyCDGS> modplug doesn't handle mods really well
[19:42:07] <Compn> i've heard that only timidity handles mods
[19:42:09] <jai> so fix it :)
[19:42:10] <Compn> properly
[19:42:23] <BastyCDGS> most players don't, still until today mods are only guaranteed to play 100% correctly with the original program creating it
[19:42:43] <BastyCDGS> but I fixed these issues in TuComposer already...
[19:43:06] <jai> yeah, fixing libmodplug seems like a better approach to me
[19:43:19] <Compn> ffmpeg hates external libs tho :P
[19:43:20] <BastyCDGS> I probably spent way over 1000+ hours just to figure out how they should really be played, adding workaround flags etc.
[19:43:34] <jai> Compn: sure, but for fringe formats...
[19:43:45] <Compn> especially for fringe formats
[19:43:49] <Compn> e.g. bink :P
[19:43:57] <Compn> kshishkov loves bink
[19:44:02] <BastyCDGS> I won't fix modplug, I have gsoc'ed here for ffmpeg doing mod stuff ;)
[19:44:09] <jai> yes, and that just means that we would be duplicating all that effort across multiple codebases
[19:44:26] <jai> good reasoning ;)
[19:44:28] <Compn> actually , i think there are more mods/midis than a lot of codecs ffmpeg has support for
[19:44:35] <jai> anyway, not my call
[19:44:35] <BastyCDGS> not really, just integrate TuComposer and 99,9% of the work is already done
[19:44:36] <jai> so meh
[19:44:58] <BastyCDGS> this will basically change TuComposer to apply ffmpeg's style guide
[19:45:06] <BastyCDGS> change names of functions and data structures mostly
[19:45:24] <BastyCDGS> also some very rare amiga only stuff has to be replaced (but it's not really much)
[19:49:48] <BastyCDGS> that's also why I'ld prefer sth. like libavmodule, it would have the same approach as TuComposer itself (it's a lib, too.)
[19:50:39] <wbs> remember that ffmpeg and libav* isn't a dumping ground for various third party code, to be accepted, it should be properly adapted
[19:53:08] <BBB> isn't modplug also c++?
[19:53:09] <jai> i reiterate, i dont see the need for a separate lib
[19:53:22] <jai> all this can be cleanly rolled into the current framework
[19:53:22] <BBB> and yes of course it shouldn't be a separate lib
[19:53:32] <BBB> did I mention I threw up when librtmp support was added to avf?
[19:53:45] <jai> BBB: lol
[19:54:02] <jai> BBB: yes the code is c++
[19:54:23] <jai> BBB: also, hi :)
[19:55:09] <BastyCDGS> well an libavmodule library would have the benefit that it can easily be enabled/disabled with configure --disalbe-avmodule or sth. like that
[19:55:37] <BastyCDGS> also don't underestimate that, it will become pretty big for proper support for all formats
[19:55:49] <BastyCDGS> expect some 400k of stripped O3 binary code
[19:56:15] <wbs> individual decoders/encoders already can be disabled/enabled through configure
[19:56:17] <jai> BastyCDGS: that could be achieved without a separate lib
[19:56:27] <saste> hi all
[19:56:48] <BastyCDGS> btw, I did a test build of TuComposer using DJGPP some years ago which resulted even in 900k (twice the double than m68k amiga) and I replaced all amigaos calls with stubs
[19:56:53] <BBB> yeah the separate lib idea is silly
[19:56:53] <BastyCDGS> hey saste, how are u?
[19:57:03] <saste> is there some technical reason for which a libavmodule would be better than a libplugmod extension?
[19:57:06] <BBB> good decoders should be in lavc
[19:57:15] <jai> saste: libmodplug?
[19:57:22] <BastyCDGS> modplug isn't good at module decoding
[19:57:26] <BBB> and again, I want to throw up when seeing ext libs being developed
[19:57:29] <BBB> because THEY WILL DIE
[19:57:29] <BastyCDGS> it fails esp. with it
[19:57:38] <BBB> and then we have to reimplement them in lavf/c anyway
[19:57:43] <BBB> better do it right from the start
[19:57:52] <BBB> point in case: libmms
[19:57:58] <BBB> still makes me throw up nowadays
[19:58:13] <BBB> and I feel bad for the SoC student that has to reimplement something that we already did ages ago
[19:58:17] <saste> well in the case of librtmp... internal support was not that good for various reasons
[19:58:26] <BBB> all of these reasons could be fixed
[19:58:36] <saste> also it depends on the activity/ support state of the library being "plugged"
[19:58:40] <jai> yes
[19:58:40] <BastyCDGS> well if we can do all this stuff what TuComposer can do without doing a new libav...why not?
[19:58:41] <BBB> but the developer is lazy, incompetent, uneducated and thinks he's smarter than "us"
[19:58:46] <BBB> did I mention arrogant?
[19:58:51] <jai> and libmodplug _is_ maintained last i checked
[19:59:02] <jai> if it has bugs, those should be fixed upstream
[20:00:15] <saste> yes the problem is that we don't want to duplicate effort when possible... but this has to be checked case by case
[20:00:23] <jai> of course
[20:01:24] <BastyCDGS> also libmodplug is decoding only
[20:01:28] <BastyCDGS> i want to both
[20:01:37] <BastyCDGS> to have both in ffmpeg
[20:01:40] <saste> of course
[20:01:40] <BastyCDGS> encoding/decoding
[20:01:55] <BastyCDGS> and it's really a bad library, even worse if it's in C++
[20:02:14] <BBB> well look regardless of whether you do modplug or tucomp or something else
[20:02:19] <BBB> I think it shouldn't be a separate lib
[20:02:26] <BBB> it should be in ffmpeg, and can be done rightly so
[20:02:38] <BBB> a lot of functionality can always be shared with other subsystems in lavf
[20:02:51] <BBB> just think about the amount of code wasted on efficient byte I/O
[20:03:20] <ramiro> BBB: you have to agree that it can be rather annoying to get something integrated into FFmpeg.
[20:03:49] <BastyCDGS> BBB, I just want to do this anyway, share as much as possible with ffmpeg code
[20:03:50] <jai> BastyCDGS: the api is C
[20:05:56] <BastyCDGS> yes placed in a bunches of extern "C" stuff which is then internally converted to class stuff
[20:06:15] <BastyCDGS> all wasting time, and all the issues with C++ itself
[20:06:20] <jai> to a person writing a wrapper, that shouldnt make any difference
[20:06:47] <BastyCDGS> yes but it still doesn't solve the internal issues like GetFoo!Qkuao18 not found. terminating!
[20:06:53] <jai> ?
[20:06:57] <jai> i dont follow
[20:07:02] <BastyCDGS> just because two different compilers use the same object file
[20:07:10] <BastyCDGS> name mangling of C++ functions
[20:07:26] <wbs> that doesn't matter as long as all the c++ is inside of the library and just expose C functions as external interface
[20:07:32] <jai> how does that matter at all?
[20:07:41] <wbs> as long as you don't try to compile half of their library with one compiler and half of it with another one
[20:07:51] <wbs> doesn't matter the least for users of the library
[20:08:27] <BastyCDGS> wbs, I'ld be glad if you were right, but even the user sees this...had this often enough with C++ stuff
[20:08:40] <BastyCDGS> sometimes it's just enough to add a new repository where the new program version is x.y.z+3
[20:09:36] <wbs> and if the external interface is pure C, in which way would that be possible?
[20:09:41] <BastyCDGS> with linux shared libs usually go to in /usr/lib
[20:09:41] <BastyCDGS> if they're C++ and you use a new G++ your app will break
[20:10:25] <wbs> what part of "the external interface is pure C" don't you undestand?
[20:10:52] <BastyCDGS> I'm not talking about the external interface
[20:11:27] <BastyCDGS> I'm talking about general problems with C++ libs
[20:11:54] <wbs> yes, but that's a problem that doesn't exist in the case we were discussing
[20:12:42] <ramiro> btw what's up with all those iff optimizations? is it this codec?: http://wiki.multimedia.cx/index.php?title=IFF
[20:12:50] <BastyCDGS> besides this, libmikmod is forked multiple times already
[20:12:52] <jai> yep
[20:13:04] <BastyCDGS> because mikmod and modplug are such bad
[20:13:11] <ramiro> is it still used that much?
[20:13:21] <jai> i prefer the libmodplug api, the libmikmod api sucks
[20:13:25] <BastyCDGS> schismtracker uses a totally patched again of libmikit (which is a fork of libmikmod)
[20:13:29] <jai> ramiro: not really
[20:14:23] <jai> don't get me wrong, i'm all for a unified native module playback engine within ffmpeg, i just want you to factor in the maintenance costs involved here
[20:14:39] <BastyCDGS> and even still, schism plays IT modules very non-conforming
[20:14:53] <BastyCDGS> that's the reason I still prefer original IT from 1998 in dosbox
[20:15:11] <jai> not to mention convincing application devs to move over to the new zomg-awsome implementation
[20:15:56] <BastyCDGS> jai, I have almost all ready which we need for it ;)
[20:16:08] <BastyCDGS> we don't have to rewrite a mod engine from scratch
[20:16:27] <BastyCDGS> I already done it all the last 12 years ;)
[20:16:48] <BastyCDGS> we just have to adjust TuComposer to be flawlessly integrate in ffmpeg but that's not really very much
[20:16:59] <jai> good :)
[20:17:31] <BastyCDGS> it's mainly stuff like ULONG => uint32_t, UWORD => uint16_t etc.
[20:17:52] <jai> ugh, why use those types to begin with
[20:17:53] <BastyCDGS> and make TuComposer's public functions like tcmAllocModule sth. like ff_mod_alloc or sth. like that
[20:17:59] <jai> mikmod used those all over the place too
[20:18:02] <BastyCDGS> amiga native types ;)
[20:18:17] <jai> k
[20:18:24] <BastyCDGS> declared in <exec/types.h>
[20:18:43] <BastyCDGS> short question
[20:18:46] <jai> the closest thing to an amiga i have is a copy of winuae ;)
[20:18:57] <BastyCDGS> ffmpeg has support for threading semaphores etc. already very good we'll need this
[20:19:13] <BastyCDGS> have we support for platform independent dlopen, too?
[20:19:42] <BastyCDGS> platform audio device in/output is already present...
[20:20:48] <BastyCDGS> ffmpeg also has be/le stuff bitstream reading very good
[20:20:48] <jai> there's a dlfcn-win32 or sth
[20:20:52] <jai> ramiro should know
[20:20:57] <jai> but that would be a dependency
[20:21:12] <BastyCDGS> so the platform dependent stuff currently existing in TuComposer can easily be transferred to ffmpeg too
[20:21:54] <ramiro> we'd need this discussion on ffmpeg-devel
[20:22:09] <ramiro> I'm not sure everyone wants shared loadable modules. we just did the opposite with libavfilter.
[20:22:17] <ramiro> vhooks were loadable, lavfilter isn't
[20:22:40] <BastyCDGS> well TuComposer uses these for mod/s3m/xm/it support, internally it just handles IFF-TCM1
[20:22:41] <jai> i'm not sure about the usecase BastyCDGS intended, just saying...
[20:23:01] <jai> it uses dlopen?
[20:23:11] <ramiro> wikipedia doesn't know what TuComposer is, so neither do I.
[20:23:13] <BastyCDGS> you can even copy a new plugable module format while it's running thanks to file system notification it will detect it and load
[20:23:29] <jai> BastyCDGS: i dont think we need that flexibility
[20:23:51] <jai> statically compiled route is better
[20:24:22] <BastyCDGS> ramiro: http://forum.cdgs-crew.com/viewforum.php?f=11
[20:24:36] <BastyCDGS> that would be even easier, jai ;)
[20:26:32] <BastyCDGS> this public function API would be required in ffmpeg
[20:26:32] <BastyCDGS> http://forum.cdgs-crew.com/viewtopic.php?t=13
[20:26:52] <BastyCDGS> some of them are redundant now (since already present in ffmpeg)
[20:27:52] <kierank> Will changing number of streams on the fly work properly using the libavcodec api?
[20:29:10] <BastyCDGS> also read the IFF-TCM specs for becoming an idea what a module must have for data structures:
[20:29:10] <BastyCDGS> http://forum.cdgs-crew.com/viewtopic.php?t=7
[21:03:36] <CIA-7> ffmpeg: conrad * r23025 /trunk/libavcodec/libschroedingerenc.c: schroenc: Don't touch gop_structure by default, it should be left adaptive
[21:03:37] <CIA-7> ffmpeg: conrad * r23026 /trunk/libavcodec/libschroedingerenc.c: schroenc: Use constant quality for constant quality, not noise threshold
[21:03:37] <CIA-7> ffmpeg: conrad * r23027 /trunk/libavcodec/libschroedingerenc.c: schroenc: Set keyframe interval
[21:03:38] <CIA-7> ffmpeg: conrad * r23028 /trunk/libavcodec/libschroedingerenc.c: schroenc: Set open-gop
[21:04:15] <Dark_Shikari> \o/
[21:04:40] <saintd3v> schro, eek
[21:05:08] <Dark_Shikari> so now all I have to do to get sane defaults is -coder 1, Yuvi ?
[21:05:27] <Yuvi> nope, just set the gop to something other than 12
[21:05:36] <Dark_Shikari> And that, yeah
[21:05:39] <Yuvi> -coder 0 only has any effect on -g 0
[21:05:41] <Dark_Shikari> Ah
[21:05:50] <Dark_Shikari> there's no VLC mode for non-lossless
[21:05:51] <Dark_Shikari> ?
[21:06:00] <Yuvi> no vlc for non-intra
[21:06:06] <Dark_Shikari> ah
[21:11:52] * mru curses nvidia
[21:12:04] <Yuvi> the lack of neon?
[21:12:14] <mru> the lack of sense
[21:29:14] <BBB> ramiro: agreed
[21:29:19] <BBB> ramiro: we all go through that though :)
[21:37:15] <ramiro> well some people don't want to. they find it easier to keep their own projects
[21:38:49] <CIA-7> ffmpeg: conrad * r23029 /trunk/libavcodec/libschroedingerenc.c: schroenc: Use AV_RB32
[21:38:50] <CIA-7> ffmpeg: conrad * r23030 /trunk/libavcodec/libschroedingerenc.c: schroenc: Set colorspace info
[21:45:46] <CIA-7> ffmpeg: stefano * r23031 /trunk/libavutil/ (avutil.h error.c error.h):
[21:45:46] <CIA-7> ffmpeg: Make av_strerror() return -1 even in the case when av_strerror_r() is
[21:45:46] <CIA-7> ffmpeg: not defined.
[21:45:46] <CIA-7> ffmpeg: This allows applications to check if av_strerror() cannot provide a
[21:45:46] <CIA-7> ffmpeg: meaningful representation for the provided error code, without having
[21:45:47] <CIA-7> ffmpeg: to actually check the filled string.
[21:45:48] <CIA-7> ffmpeg: stefano * r23032 /trunk/cmdutils.c:
[21:45:48] <CIA-7> ffmpeg: Make print_error() use strerror() in case av_strerror() fails.
[21:45:49] <CIA-7> ffmpeg: Should provide a meaningful error message for systems which do not
[21:45:49] <CIA-7> ffmpeg: support strerror_r().
[21:45:50] <CIA-7> ffmpeg: Fix roundup issue #1894.
[21:45:50] <CIA-7> ffmpeg: stefano * r23033 /trunk/cmdutils.c:
[21:45:51] <CIA-7> ffmpeg: Simplify print_error(), directly use av_strerror()/strerror() for
[21:45:51] <CIA-7> ffmpeg: printing the error code associated to FF_NETERROR(EPROTONOSUPPORT).
[21:45:52] <CIA-7> ffmpeg: stefano * r23034 /trunk/cmdutils.c: Reindent after the last commit.
[22:01:22] <Dark_Shikari> woohooo
[22:01:26] <Dark_Shikari> muxing of raw h264 -> mkv is broken in ffmpeg
[22:01:32] <Dark_Shikari> wonder how long that's been true
[22:02:53] <peloverde> is that really that much of a surprise?
[22:03:02] <Dark_Shikari> furthermore, when it breaks, it makes files that crash haali's splitter's thumbnail generator
[22:03:12] <Dark_Shikari> thus crashing windows explorer
[22:03:48] <peloverde> haali shouldn't crash, and windows should run thumbnailers out of process
[22:04:31] <Dark_Shikari> and my ass should defecate unicorns
[22:05:16] <Dark_Shikari> yay, ffmpeg locks up when extracting an image from an mkv file
[22:06:21] <Dark_Shikari> yup, ffmpeg locks up when attempting to decode dirac video files.
[22:06:49] <Dark_Shikari> hmm, I guess I can get around it by sending it through y4m first
[22:08:59] <Dark_Shikari> woohoo, it locks up when you ctrl-C it
[22:09:05] <Dark_Shikari> (probably the same issue)
[22:12:46] <BastyCDGS> so I'll goto bed now, wish you all a good night and wonderful dreams, see ya soon ;)
[22:29:10] <Dark_Shikari> http://comparescreenshots.slicx.com/comparison/54356
[22:29:14] <Dark_Shikari> loooooooooooool
[22:30:12] <_av500_> dirac is so much smoother
[22:30:46] <mru> same bitrate?
[22:31:22] <_av500_> dirac has a wavelength, no?
[22:31:23] <Dark_Shikari> yes
[22:31:28] <Dark_Shikari> actually x264 was a bit lower
[22:31:38] <Dark_Shikari> I used constant quality in dirac (after yuvi fixed the ffmpeg interface to not be broken as fuck)
[22:31:45] <Dark_Shikari> and then picked the same bitrate and 2-pass'd it in x264
[22:31:47] <Dark_Shikari> same gop size
[22:31:51] <Dark_Shikari> otherwise, defaults
[22:54:40] <Dark_Shikari> oh.  and ffmpeg ignores theora's pixel offset
[22:54:44] <Dark_Shikari> this is probably bad.
[22:55:59] <Dark_Shikari> breaks non-mod16 decoding
[23:03:58] <Dark_Shikari> mru: and http://mirror05.x264.nl/Dark/theora_parkjoy.png
[23:05:45] <janneg> Dark_Shikari: you're cheating!!1!!eleven!!1one! the dirac picture is much smaller ;)
[23:05:56] <janneg> compressed pngs?
[23:06:07] <Dark_Shikari> yes
[23:06:15] <Dark_Shikari> pngs?  compressed?  oh my, unheard of
[23:06:34] <Dark_Shikari> (pngout'd)
[23:06:54] <ramiro> pngcrush'd too?
[23:06:57] <Dark_Shikari> pngout is better
[23:08:00] <BBB> holy shit that dirac one looks like shit
[23:08:17] <Dark_Shikari> then you haven't looked at the theora one yet
[23:08:37] <BBB> comparable to the dirac one?
[23:08:47] <BBB> mouseover is better to compare
[23:08:49] <BBB> pretty :)
[23:56:54] <bcoudurier> hi guys
[23:56:56] <ramiro> Dark_Shikari: are you on ffmpeg-user? http://article.gmane.org/gmane.comp.video.ffmpeg.user/26343
[23:57:04] <Dark_Shikari> I don't read ffmpeg-user
[23:57:32] <Dark_Shikari> but clearly he has no idea what he's doing
[23:57:40] <Dark_Shikari> feel free to correct him
[23:58:03] <Dark_Shikari> meh, I'll do that