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

[irc at mansr.com]

[00:00:16] <mru> if speed matters you should use asm
[00:00:27] <Dark_Shikari> we only have inline asm on x86 atm
[00:00:47] <mru> sometimes inline asm is the best solution
[00:01:17] <Dark_Shikari> hmm. michael's idea seems to hurt in x264.
[00:02:02] <Dark_Shikari> in fact, michael's idea would hurt in ffmpeg if ffmpeg had inline SIMD like x264 did
[00:02:05] <Dark_Shikari> for that code
[00:02:11] <Dark_Shikari> we use simd for the following
[00:02:12] <Dark_Shikari> MIN(((x+28)*2184)>>16,2) = (x>2) + (x>32)
[00:02:20] <Dark_Shikari> on two values at once
[00:02:28] <Dark_Shikari> left side is simd, right side is C
[00:10:25] <astrange> the snowll regression test works with gcc-svn now. used to break with an aliasing bug
[00:10:37] <astrange> i think gcc fixed that and not av_alias, though
[00:15:40] <mru> r21876: http://fate.multimedia.cx/index.php?build_record=183656
[00:15:55] <mru> r21882: http://fate.multimedia.cx/index.php?build_record=183753
[00:16:02] <mru> same compiler
[00:18:28] <Dark_Shikari> toldyaso
[00:18:34] <mru> also http://fate.multimedia.cx/index.php?build_record=183523 and http://fate.multimedia.cx/index.php?build_record=183617
[00:19:06] <mru> or are you saying mike just happened to update the compiler between those commits *and* forgot to update the description in fate?
[00:20:16] <astrange> oh, did you use it in copy_block?
[00:20:36] <mru> I added the aliasing stuff to all the AV_RW and AV_COPY macros
[00:20:50] <mru> so anything that uses those might have been affected
[00:34:06] <astrange> oh, i thought copy_block wasn't using AV_RN, but it seems like it is, so that was it then
[00:36:38] <Dark_Shikari> is there seriously no mmx multiply bytes instruction? :/
[00:38:46] <Kovensky> <&jfs> still the best constant name in vsfilter:
[00:38:46] <Kovensky> <&jfs> static const __int64 _00ff00ff00ff00ff = 0x00ff00ff00ff00ffi64;
[00:39:22] <Dark_Shikari> awesomes.
[00:45:15] <Dark_Shikari> my god
[00:45:29] <Dark_Shikari> a customer with... wait for it... svn 7760
[00:45:34] <Dark_Shikari> reporting a problem with mp4 muxing
[00:45:48] <mru> that's x264 I hope
[00:46:08] <Dark_Shikari> ffmpeg
[00:46:16] <astrange> only 3 years old
[00:46:17] <mru> ffmpeg 7760?!?!?!?
[00:47:18] <mru> 1406 files changed, 312398 insertions(+), 159653 deletions(-)
[00:47:27] <Dark_Shikari> lol
[00:47:36] <mru> that's like... everything
[00:49:31] <mru> on movenc.c: 963 insertions(+), 544 deletions(-)
[02:38:00] <CIA-90> ffmpeg: michael * r21888 /trunk/libavcodec/h264_cabac.c: Get rid of a local variable, 10 cpu cycles faster.
[03:11:18] <CIA-90> ffmpeg: michael * r21889 /trunk/libavcodec/h264_cabac.c: get rid of an if() 1 cpu cycle faster.
[03:11:41] <mru> lol
[03:13:08] <BBB> he's trying really hard
[03:13:10] <BBB> that's good
[03:13:29] <BBB> how do I resolve timestamps for audio encoding?
[03:13:49] <BBB> e.g. I call av_encode_audio(), where do I store the input data timestamp and how do I read it out once it gets returned?
[03:14:30] <mru> you close your eyes and wave your hands around a lot
[03:16:00] <BBB> why don't we change the function prototype to take a AVPacket, like av_encode_video17()?
[03:16:18] <astrange> isn't encoding video wrong too?
[03:16:27] <mru> that's scheduled for avcodec_encode_audio42()
[03:16:42] <astrange> you have to check avctx->returned_packet.pts afterwards instead of it returning something with a reordered_opaque
[03:16:54] <Dark_Shikari> good thing we don't have audio b-frames yet
[03:17:04] <mru> why is that?
[03:17:57] <BBB> astrange, well, yes, maybe, but at least for video there is coded_frame->pts, which is better than nothing
[03:18:05] <BBB> AAC encoding caches several audio frames
[03:18:31] <BBB> so I need to know how many hands to wave, and how long
[03:18:35] <BBB> and whether to close 1 eye or 2
[03:20:54] <CIA-90> ffmpeg: mru * r21890 /trunk/libavutil/ (intreadwrite.h tomi tomi/intreadwrite.h): TOMI: 16- and 32-bit intreadwrite functions
[03:21:50] <Dark_Shikari> TOMI?
[03:22:01] <mru> a new cpu
[03:22:39] <Dark_Shikari> by who, for what?
[03:22:42] <Dark_Shikari> what class of cpu?
[03:24:52] <mru> see patent US 2007/0192568 A1
[03:25:00] <Dark_Shikari> I know, but who is actually making it?
[03:25:19] <mru> Russell Fish
[03:25:27] <Dark_Shikari> 4-bit access to registers?
[03:25:34] <Dark_Shikari> I mean who is MAKING it
[03:25:35] <Dark_Shikari> i.e. fabbing it
[03:25:53] <mru> it doesn't exist in silicon yet
[03:26:06] <Dark_Shikari> why are we committing stuff for a chip that doesn't exist in silicon?
[03:26:14] <mru> $$$
[03:26:22] <Dark_Shikari> wait, is he paying you?
[03:26:25] <mru> yes
[03:26:27] <Dark_Shikari> .... lol
[03:26:39] <Dark_Shikari> paying you to optimize for a chip that doesn't exist yet
[03:26:48] <Dark_Shikari> with a patent application that looks like a restatement of the past 20 years of chip design
[03:26:53] <mru> his problem, not mine
[03:27:02] <Dark_Shikari> I know, I just find it hilarious
[03:27:34] <Dark_Shikari> so, how much are you getting for this? and what else is involved?
[03:27:36] <Dark_Shikari> simd?
[03:27:57] * Dark_Shikari doesn't see simd in that chip
[03:28:44] <Dark_Shikari> does the chip even exist in _simulation_ yet?
[03:28:49] <mru> yes
[03:28:51] <Dark_Shikari> or it just a vague design doc
[03:28:56] <mru> I have a simulator
[03:29:32] <mru> there are more docs available that I can't show you
[03:30:18] <mru> that code I committed doesn't reveal anything that isn't in the patent document
[03:30:32] <Dark_Shikari> is there simd?
[03:30:49] <Dark_Shikari> also, as it happens, I know another developer who is developing for a mystery chip under mysterious circumstances
[03:30:52] <Dark_Shikari> I wonder if it's the same one
[03:31:07] <mru> anyone I'd know?
[03:38:49] <ohsix> tomi-vac! this fish guy sounds a bit off too; more power to you
[03:39:34] <ohsix> claims to have invented email too?
[03:39:44] <Dark_Shikari> lol
[03:40:43] <ohsix> http://www.dallasobserver.com/2007-11-15/news/crazy-fish-story/print
[03:41:22] <Dark_Shikari> lol, he's nuts
[03:44:06] <astrange> how did they fit something that long in the paper?
[03:46:27] <ohsix> papers have pretty small print
[04:07:48] <kierank> that guy is brilliant
[05:31:49] <Yuvi> mru: idct_row4_pld_neon <- isn't the data from MC already in L1 cache?
[05:32:10] <Yuvi> or is there a penalty for L2 miss on store?
[06:31:35] <elenril> http://games.slashdot.org/story/10/02/19/008216/Switzerland-Pursues-Violent-Games-Ban wait, what?
[06:35:47] <astrange> ramiro: http://ffmpeg.arrozcru.org/wiki/images/d/dd/Ffmpeg_r15966_static_pthreads.diff what happens without the atexit()?
[06:58:03] <elenril> and some HD videos encoded in AVC or h.264 formats. << lol at slashdot
[06:58:39] <kshishkov> you mean "you netbook can play 1080i H.264 with CoreAVC"?
[06:58:45] <elenril> yes
[06:58:53] <elenril> morning btw
[06:59:00] <kshishkov> morning
[06:59:13] <kshishkov> as one of CoreAVC developers may say "bollocks"
[06:59:52] <pJok> mornings
[06:59:59] <kshishkov> goda morgnar
[07:00:12] <thresh> moroning
[07:00:15] <av500> guten morgen
[07:00:22] <benoit-> ditto
[07:00:42] <CIA-90> ffmpeg: kostya * r21891 /trunk/libavformat/Makefile:
[07:00:42] <CIA-90> ffmpeg: WavPack demuxer supports ID3v1 tags, so don't forget id3v1.o dependency for it
[07:00:42] <CIA-90> ffmpeg: in Makefile
[07:01:36] * elenril wonders if he should add id3v2 reading for everything
[07:01:47] <av500> you have id3 in asf covered?
[07:01:56] <elenril> no
[07:01:59] <kshishkov> no, I'd like ID3 _removed_ from everything
[07:02:05] <elenril> it was threatening my sanity
[07:02:16] <elenril> (at least what's left of it)
[07:02:27] <kshishkov> having ID3 tags before actual file data is idiotic too
[07:03:39] <elenril> how would you design a metadata format usable for all/most containers?
[07:04:13] <kshishkov> as a text block
[07:04:25] <elenril> placed where?
[07:04:41] <kshishkov> in "metadata" chunk supported by format
[07:05:24] <av500> well, id3v2 in asf is stored at a proper place
[07:05:39] <elenril> is it even standardised?
[07:06:06] <elenril> asf specs don't mention id3 at all
[07:06:17] <av500> elenril: as usual, not std, but used widely
[07:06:24] <elenril> orly
[07:06:48] <av500> iirc musicmatch jukebox did it that way
[07:08:32] <kshishkov> it could be somebody's hack for WMA
[07:09:05] <elenril> well if everybody does it like that file i saw yesterday
[07:09:17] <elenril> then we're better off not supporting it
[07:09:35] <av500> elenril: url?
[07:10:44] <elenril> http://filebin.ca/skhpks/error_while_opening2.wma
[07:11:01] <elenril> basically it has normal asf tags intermixed with id3 tags
[07:11:31] <elenril> id3 tags have ID3/tagname in utf-16 as a key
[07:11:53] <elenril> and an array of [TAG, VALUE] in utf8 as value
[07:12:20] <kshishkov> so it's probably a hack for some MP3 player
[07:13:55] <av500> elenril: http://msdn.microsoft.com/en-us/library/dd743220(VS.85).aspx
[07:14:11] <av500> "..If you want to use the ID3 tags as attributes rather than using the standard attribute names, add the prefix "ID3/" to the tag name..."
[07:14:30] * av500 must add that since he now has a sample file...
[07:15:04] <elenril> that doesn't excuse the way they are stored
[07:17:16] <av500> elenril: yes, you are right, this is crazy
[07:27:45] <elenril> anyone knows how metadata in mov works?
[07:28:01] <Yuvi> which scheme?
[07:28:27] <elenril> scheme?
[07:28:54] <Yuvi> itunes, quicktime, and base isom defined a third that noone uses outside of 3gp (not 3gp2)
[07:29:08] * elenril facepalms
[07:29:54] <elenril> are specs for those available somewhere?
[07:31:21] <Yuvi> you can get 3gp from somewhere, itunes isn't really documented (the QT 7.0 headers promised it was coming... in 2006), the quicktime might be documented somewhere
[07:31:54] <superdump> there's a publically available qtff.pdf that might have some info in it
[07:31:55] <elenril> also it seems mov demuxer doesn't export everything
[07:32:09] <elenril> i wonder if there's any reason for that
[07:32:10] <superdump> http://developer.apple.com/documentation/quicktime/QTFF/qtff.pdf
[07:32:33] <Yuvi> mm, apple broke that link
[07:32:49] <superdump> they did?
[07:33:06] <superdump> they did
[07:33:08] <superdump> hrm
[07:36:08] <astrange> http://multimedia.cx/mirror/qtff-2007-09-04.pdf
[07:36:12] <Yuvi> http://www.mediafire.com/?ggzzomtmxey because I don't feel like searching developer.apple.com
[07:36:24] <Yuvi> that works too
[07:36:57] <Yuvi> look for "user data"
[07:37:06] <superdump> http://developer.apple.com/mac/library/documentation/QuickTime/QTFF/QTFFPreface/qtffPreface.html
[07:37:49] <superdump> there's a pdf button in the top-right
[07:37:57] <superdump> if you click on that you can download the current pdf
[07:38:31] <Dark_Shikari> hmm, mpeg-2 has a fullpel mode?
[07:47:28] <av500> err, gg opening vp8 next week is that speculation or real news?
[07:50:02] <Dark_Shikari> gg?
[07:50:11] <Dark_Shikari> that sounds like crazy speculation from slashdot
[07:51:21] <av500> GooGle
[07:51:25] <KotH> moin boys
[07:52:34] <benoit-> salut KotH
[07:52:58] <av500> 'jour
[08:07:57] <CIA-90> ffmpeg: thilo.borgmann * r21892 /trunk/libavcodec/alsdec.c: Do sequential bit reading outside of []-operators.
[08:18:42] <astrange> http://www.bluishcoder.co.nz/2010/02/19/comparing-colour-space-conversion-libraries.html
[08:22:43] <kshishkov> sounds a bit suspicious
[08:23:16] <Dark_Shikari> swscale is not very fast
[08:23:19] <Dark_Shikari> it only has mmx
[08:23:31] <superdump> astrange: i'd post that to the ml
[08:23:45] <Dark_Shikari> but the gap is too large.  probably different resizing methods being used.
[08:23:56] <Yuvi> maybe no --enable-gpl?
[08:24:01] <Dark_Shikari> oof.  that could be it
[08:24:06] <Dark_Shikari> probably should comment about that
[08:24:16] <astrange> i'll post it somewhere else if he does what i already commented
[08:24:42] <Dark_Shikari> should probably make a note there about the GPL bit though...
[08:25:24] <astrange> which parts of sws are GPL still?
[08:25:32] <Dark_Shikari> the asm!
[08:25:32] <Yuvi> all x86 asm, I think that's it
[08:25:33] <Dark_Shikari> lol
[08:25:36] <astrange> ah
[08:25:39] <av500> doesnt X have like hardware yuv overlays?
[08:25:47] <astrange> i thought it was just yuv<>rgb, then i could replace http://trac.perian.org/browser/trunk/ColorConversions.c with it
[08:26:09] <Dark_Shikari> av500: this is mozilla, doing things right is against their code of conduct
[08:26:21] <av500> Dark_Shikari: ah
[08:26:52] <bilboed> or maybe it's time to relicense the GPL parts of libswscale
[08:26:57] <Yuvi> can you even blend hardware yuv overlays with web pages?
[08:27:07] <astrange> you can do rendering in GL
[08:27:08] <Yuvi> except via shaders of course
[08:27:12] <av500> Yuvi: probably not
[08:27:16] <Dark_Shikari> Yuvi: most of the time you don't have to
[08:27:23] <CIA-90> ffmpeg: thilo.borgmann * r21893 /trunk/libavcodec/Makefile: Add the dependency for mpeg4audio.o of the ALS decoder.
[08:28:22] <Dark_Shikari> of course, mozilla would never use anything GPL
[08:28:28] <Dark_Shikari> even LGPL seems to be against their credo
[08:28:41] <bilboed> oh right, mozilla
[08:35:19] <astrange> theora uses jpeg chroma siting?
[08:35:24] <astrange> i guess mpeg1 did too
[08:36:39] <Yuvi> h.263 too actually
[08:38:39] <kshishkov> everything else with old swscale as well ;)
[08:42:51] <Dark_Shikari> astrange: wait, C1x?
[08:43:19] <Dark_Shikari> oh wow.  they are actually doing it.
[08:46:13] <KotH> what's so astonishing about that?
[08:48:07] <superdump> Dark_Shikari: you have a post on your blog about orc don't you?
[08:48:12] <superdump> i'm struggling to find it
[08:48:37] <superdump> the in-page search doesn't find it it seems
[08:53:15] <andoma> hm, does anyone know where I can find matrixes for converting various colorspaces to RGB ?
[08:53:30] <kshishkov> almost everywhere
[08:53:52] <andoma> my google fu must be bad
[08:54:31] <kshishkov> http://www.fourcc.org/fccyvrgb.php
[08:54:54] <kshishkov> http://en.wikipedia.org/wiki/YUV
[08:56:01] <andoma> right, thanks
[09:01:08] <Dark_Shikari> superdump: no I don't
[09:01:14] <superdump> hmm
[09:01:16] <superdump> weird
[09:01:25] <superdump> i remember reading an article about someone bashing orc a while ago
[09:01:37] <superdump> mru: was it you then? did you write an article about orc?
[09:02:15] <Dark_Shikari> I don't know enough to write about it
[09:02:23] <Dark_Shikari> all I know is that it's probably the best platform-generic simd method
[09:02:31] <Dark_Shikari> which isn't hard, considering the only other one I know is gcc vector types
[09:04:14] <pengvado> gcc vector types. which define only the operations +-*~|&^
[09:05:18] <superdump> apparently the framewave (amd) yuvtorgb uses sse2 and is multi-threaded
[09:05:58] <Dark_Shikari> pengvado: and even then don't usually do them very well
[09:06:05] <superdump> it seems like most of their stuff does
[09:06:06] <superdump> http://framewave.sourceforge.net/Manual/fw_function_020_0060_00070.html#fw_function_020_0060_00070
[09:07:52] <Dark_Shikari> lol @ inability to specify bt.601 vs 709
[09:08:00] <Dark_Shikari> sure swscale sucks too but we knew that
[09:09:35] <kshishkov> patchiswelcome
[09:42:34] <iive> Dark_Shikari: did you happen to find the swap for abs of 2 short values in int register?
[09:42:37] <iive> swar
[09:43:40] <Dark_Shikari> ended up being better to do it a different way that didn't require that
[09:43:42] <Dark_Shikari> but I'm still curious
[09:44:11] <kshishkov> what about usual sources?
[09:45:36] <Dark_Shikari> ?
[09:45:56] <kshishkov> aggregate.org, TAoCP, HAKMEM
[09:46:22] <Dark_Shikari> very little swar on most of those
[09:47:39] <iive> i was trying to do something with the abs forumula a=(a^mask)-mask; the tricky part is getting the mask
[09:48:11] <Dark_Shikari> yeah
[09:48:15] <Dark_Shikari> that's the problem
[09:48:34] <kshishkov> ((val & 0x8080) >> 7) * 0xFF
[09:48:59] <iive> multiply instead of if :)
[09:49:27] <Dark_Shikari> kshishkov: heh.  probably slower than 2xabs that way
[09:49:32] <Dark_Shikari> you'd need 4 elements to make it worth it.
[09:50:06] <kshishkov> TAoCP contains totally branchless sorting algorithm. The only catch it's O(n^3)
[12:37:31] * twnqx wonders if itunes can import flac...
[12:37:44] <kshishkov> probably not
[12:37:52] <av500> it likes ALAC more
[12:38:22] <twnqx> i have a choice of (tta and ape with cue) or flac
[12:38:23] <twnqx> :S
[12:38:43] * av500 wonders what happened to MP3 files.....
[12:39:02] <twnqx> they died the death of "too low quality, and we have the disk space now"
[12:39:11] * Kovensky foobar2000 (v1.0): Soilwork [2003 Figure Number Five #03] Figure Number Five [0:18/3:12] 192kbps MP3 CBR <-- unfortunately not dead enough yet
[12:40:33] <av500> twnqx: disk space is for raw YUV! :)
[12:40:40] <Kovensky> y4m \o/
[12:40:51] * twnqx uses lossless h.264 for that purpose
[12:42:16] <Honoome> twnqx: convert from flac to alac :)
[12:42:16] <Honoome> and in the mean time, fix the map_meta_data for me :D
[12:42:25] <twnqx> Oo
[12:42:44] <twnqx> i didn't even know about ALAC's existance...
[12:43:00] <Honoome> twnqx: it's the Apple Lossless Audio Codec… performs about the same as FLAC afaics
[12:43:12] <Honoome> but uses m4a as container format rather than flac's braindamaged one so can't be too bad :D
[12:43:13] <mru> it's 90% the same codec as flac
[12:43:32] <mru> same basic algorithms
[12:43:50] <mru> a few minor differences and different bitstream syntax
[12:44:25] <Honoome> but a saner container (and saying that mp4 is saner than something else is to say a lot)
[12:44:39] * Honoome has all his lossless content in ALAC for interoperability
[12:45:07] * Kovensky has almost all of his lossless content in wavpack
[12:45:16] <mru> raw flac is pretty hellish to deal with
[12:45:30] <kshishkov> try MP3 then :P
[12:45:42] <twnqx> can ipods play alac?
[12:45:43] <Honoome> Kovensky: I used to have that, but WavPack is a bit far-fetched for most users :(
[12:45:49] <Honoome> twnqx: yup
[12:45:59] * twnqx is sold on converting
[12:46:26] * twnqx wonders if audacious can play alac, though
[12:46:49] <Honoome> -map_meta_data works with a twist: current ffmpeg does not set the author/artist mapping correctly :P and the culprit just fled! ;)
[12:47:01] <twnqx> :S
[12:47:10] <twnqx> so i have to find something else to convert, thanks for the hint
[12:47:12] <Honoome> which reminds me I have to find how to fix that so I can convert the rest of my magnatune downloads
[12:47:41] <Honoome> twnqx: just use an older version of ffmpeg if you don't want to fix it … or to get elenril to fix it… or wait for me to find the time to fix it…
[12:47:45] <twnqx> so who's wrong, the flac reader or the alac writer?
[12:47:55] <Honoome> the mov/mp4 muxer
[12:48:07] <twnqx> uh.
[12:48:20] <twnqx> how old do i have to use? :P
[12:48:33] * elenril blames Kovensky for everything
[12:48:52] <elenril> and people who wrote mov specs
[12:49:09] * Kovensky redirects blame to movax
[12:49:55] <Honoome> twnqx: 20601 worked fine
[12:50:06] <Honoome> 21602 had that bug
[12:50:18] <Honoome> elenril might know the exact revision that broke it ;)
[12:50:25] * twnqx has 21013 on disk
[12:50:31] <elenril> its' not a bug, it's a feature
[12:50:37] <twnqx> :S
[12:51:12] <Honoome> elenril: is it just a matter of sed -i -e 's:"author":"artist":' in the movenc.c file? :)
[12:51:22] <elenril> yes
[12:51:32] <Honoome> ghaaaa :P
[12:51:47] * elenril wanted to write a proper metadata conv table for mov
[12:51:54] <elenril> but it turned out to be :effort:
[12:52:08] <Kovensky> everything is :effort:
[12:52:12] <Kovensky> it's one of the rules of the universe
[12:52:22] <elenril> yeah, exactly
[12:52:40] <elenril> it's called principle of least :effort:
[12:52:41] * Honoome sends the patch to the list, sure that people will kill him for that :D
[12:53:03] <elenril> http://en.wikipedia.org/wiki/Principle_of_least_action
[12:53:20] <twnqx> test it first :P
[12:54:21] <Honoome> twnqx: right :D
[12:56:22] <merbzt> elenril: did baptiste nix the changes ?
[12:58:05] <twnqx>  mov_write_string_metadata(s, pb, "\251ART", "author"   , 1); <- sounds reasonable to change to artist...
[12:58:30] <elenril> merbzt: did baptiste what?
[12:58:41] <kshishkov> vetoed
[12:58:45] <twnqx> elenril: why is ART in capitals, while all other tags are lovercase?
[12:58:45] <kshishkov> draw a line
[12:58:48] <twnqx> powercase*
[12:58:57] <kshishkov> send them pining to the fjords
[12:59:08] <elenril> no, michael suddenly changed author->artist overnight
[12:59:17] <merbzt> :)
[12:59:19] <elenril> and i forgot to adapt in a few places
[12:59:41] <twnqx> he... changed that in one place only? wtf
[12:59:41] <merbzt> please mista fix it
[12:59:43] <elenril> twnqx: don't ask me, i don't know why is metadata in mov so braindead
[13:00:10] <av500> elenril: to fit the overall scheme of mov
[13:00:18] <elenril> sounds reasonable
[13:01:12] <av500> what I dont understand is why it is kept in one place and not spread all over the file with some other atoms to tell you where to find it
[13:02:04] <elenril> it's not?
[13:17:51] <Honoome> elenril: uhm, may I ask you one thing because I'm definitely not into the metadata code myself? :) is there already a mapper between author→artist for _reading_ metadata?
[13:18:26] <elenril> in what? mov?
[13:18:34] <Honoome> in av_metadata_set()
[13:18:53] <elenril> not sure what you mean
[13:19:13] <elenril> the demuxers are supposed to export metadata exactly as they are stored in the file
[13:19:34] <Honoome> libavformat/mov.c:109:    case MKTAG(0xa9,'A','R','T'): key = "author";    break;
[13:19:38] <elenril> if the calling app wants to convert them into some other format, it calls av_metadata_conv
[13:19:42] <Honoome> this is why I asked about it :)
[13:20:02] <Honoome> and it seems like there are a couple of other places that use "author" still
[13:20:08] <elenril> yeah, i know
[13:20:22] <elenril> it's wrong, i just forgot about them
[13:20:42] <Honoome> so they should all be updated to use artist? I might as well do that instead of just limiting to movenc.c :)
[13:21:00] <Honoome> and I asked because libavformat/metadata_compat.c seems to be mapping author→artist
[13:21:18] <elenril> don't look at metadata_compat ;)
[13:21:39] <Honoome> ooookay :)
[13:21:54] <elenril> and yeah, most of those should be changed to 'artist'
[13:22:24] <twnqx> can you push a fix like... today? :X
[13:24:50] <elenril> sure, right after i figure out why is my ca invalid
[13:26:29] <Honoome> twnqx: fwiw 21586 is the last one that will work correctly until it's all fixed :P
[13:26:32] <Honoome> I'll send a patch soonish
[13:32:40] <Honoome> mail sent :)
[13:32:47] <twnqx> still busy PRODUCING the flacs...
[13:32:58] <twnqx> fighting with character sets
[13:33:09] <twnqx> e.g. this one... it's *rage*
[13:33:16] <twnqx> cat in a unicode enabled shell show kanji
[13:33:18] <Honoome> err producing from what? :)
[13:33:21] <twnqx> .tta
[13:33:28] <twnqx> occasionally .ape
[13:33:33] <Honoome> ah cued?
[13:33:37] <twnqx> yes
[13:33:55] <twnqx> maybe u16....
[13:34:29] <Honoome> twnqx: check what “locale” says :P and what the shell is set to :)
[13:34:40] <twnqx> ... utf
[13:35:13] <twnqx> R.cue: UTF-8 Unicode (with BOM) text
[13:35:17] <twnqx> hmmmmmmmm
[13:36:39] <twnqx> so what happens...
[13:37:56] <Honoome> elenril: I sent the patch to -devel ;)
[13:38:22] * elenril reading
[13:38:50] <elenril> asf changes are wrong
[13:39:22] <elenril> it already has a conv table mapping author to artist
[13:40:24] <twnqx> why would that be right?
[13:40:29] <twnqx> they could actually differ :X
[13:40:35] <Honoome> elenril: ah… I missed that one
[13:41:32] <Honoome> elenril: asfdec or asfenc? because afaics asfenc only gets author
[13:41:37] <elenril> both
[13:41:51] <elenril> asfdec exports author
[13:41:53] <Honoome> so tell me the magic of the conversion table?
[13:42:01] <elenril> av_metadata_conv then converts it to artist
[13:42:26] <elenril> for muxing, you set artist, av_metadata_conv converts it to author
[13:42:37] <elenril> asfenc writes author
[13:42:46] <Honoome> aaah I see it now, sorry
[13:45:10] <mru> wtf is G2M3?
[13:45:13] <Honoome> elenril: new version
[13:45:28] <kshishkov> mru: MPEG-4 variation with new fourcc?
[13:45:38] <Honoome> mru: http://wiki.multimedia.cx/index.php?title=G2M3
[13:46:18] <mru> screen capture codec?
[13:46:21] <kshishkov> Honoome: MultiMedia Wiki is write-only ;)
[13:46:27] <kshishkov> video chat rather
[13:46:32] <Honoome> kshishkov: hahaha :)
[13:47:07] <mru> someone's offering an undisclosed amount of money for support in ffmpeg
[13:47:11] <av500> mru: is that the required codec for TOMI?
[13:47:55] <Honoome> TOMI?
[13:48:00] <kshishkov> what does TOMI stand for?
[13:48:24] <kshishkov> (it's obvious to be some embedded arch CPU)
[14:06:30] <CIA-90> ffmpeg: kostya * r21894 /trunk/libavcodec/wavpack.c:
[14:06:30] <CIA-90> ffmpeg: Since WavPack chunk can contain more samples than FFmpeg is guaranteed to
[14:06:30] <CIA-90> ffmpeg: hold, decode it in several iterations outputting as many samples as possible.
[14:07:08] <CIA-90> ffmpeg: kostya * r21895 /trunk/libavcodec/wavpack.c: cosmetics: reindent after last commit
[14:47:25] <jez9999> BBB: hello
[14:47:51] <av500> mru: so how long did 1 frame take?
[14:48:38] <mru> about 6 minutes
[14:48:50] <mru> 1920x1080
[14:49:50] <av500> so 10s/per day
[14:50:13] <kshishkov> sounds fine even for hand-drawn animation
[14:50:43] <av500> 60days for BBB
[14:50:58] <av500> but that is only 1080p....
[14:51:47] <av500> kshishkov: we should animate an xkcd story, that can be drawn fast
[14:52:24] <BBB> jez9999, hi
[14:52:46] <BBB> av500, did you figure out the asf caption thing?
[14:53:02] <av500> no, not yet
[14:53:16] <av500> but I guess I need to 1st tell the server to send it to me...
[14:53:32] <jez9999> BBB: checkin of the patch for issue 1740? :-)
[14:53:41] <BBB> jez9999, will check
[14:57:00] <BBB> astrange, can I bug you with aac encoding bugs?
[14:57:40] <merbzt> regarding the G2M3 codec
[14:57:52] <BBB> what's that codec anyway?
[14:57:53] <merbzt> If you are using a Mac, download the Windows Media Components to view recorded meetings
[14:58:03] <merbzt> http://www.microsoft.com/downloads/details.aspx?FamilyId=915D874D-D747-4180-A400-5F06B1B5E559&displaylang=en
[14:59:26] <merbzt> I have a hard time thinking that Flip4Mac would support it unless it is vc1 with some tricks
[15:00:10] <merbzt> so does we have samples ?
[15:02:33] <BBB> compn says yes
[15:02:37] <Compn> whas
[15:03:00] <Compn> v-codecs/g2m3
[15:03:35] <Compn> uncommon_video_codecs_final.txt
[15:03:40] <Compn> also lists a ton of them merbzt
[15:04:16] <merbzt> is the name g2m.dll ?
[15:04:56] <Compn> g2m.dll is in samples/drivers32/nwe/
[15:04:58] <Compn> new*
[15:05:17] <Compn> er G2M.dll
[15:05:28] * Compn runs afk
[15:20:38] <kshishkov> wow, G2M decoder is larger than both samples using it
[15:21:04] <av500> maybe it has them both stored inside?
[15:22:58] <merbzt> the decoder mentions inflate and rtp
[15:23:05] <kshishkov> and fft
[15:23:33] <merbzt> and aes
[15:23:44] <kshishkov> and JPEG!
[15:23:48] <kierank> so how do I map one avpacket to multiple streams?
[15:24:11] <av500> map?
[15:24:47] <merbzt> g729
[15:24:54] <kierank> map isn't the right word here but I couldn't think of a better one. Basically I need the AVPacket to be available to multiple streams
[15:26:24] <av500> duplicate it?
[15:26:34] <kshishkov> merbzt: g722 and g723 as well
[15:27:03] <merbzt> kierank: I think you need to copy it
[15:27:08] <kshishkov> merbzt: and amrwb and iLBC. Is that parody of FFmpeg?
[15:27:12] <kierank> av500: is that possible when read_packet passes a pointer to one avpacket?
[15:27:29] <av500> err
[15:27:37] <av500> kshishkov: maybe it IS ffmpeg?
[15:27:40] <merbzt> kshishkov: I think it is a complete sip client with the codecs
[15:27:49] <merbzt> GIPS also :)
[15:28:28] <kshishkov> indeed
[15:28:36] <Honoome> av500: it just statically links in libavcodec :P
[15:28:44] <kshishkov> hmm, it mentions MSS2 and WMV3
[15:30:05] <merbzt> kshishkov: can you try and see what happens with a sample ?
[15:30:14] <merbzt> if it is feed though the wmv3 decoder ?
[15:30:46] <kshishkov> it does not look like one and has own 14-byte header
[15:31:15] <merbzt> hmm
[15:31:20] <merbzt> VP71
[15:31:25] <justlooking> mru, apparently they do a simple  cross platform blender farm called loki http://loki-render.berlios.de/index.php/docs/22-using-the-master and you can do tiled rendering if you prefer,should spped things up if you happen to have a few PC onthe LAN.
[15:31:30] <kshishkov> yuck!
[15:32:06] <mru> ram could be an issue
[15:32:16] <mru> none of my other machines have >4GB
[15:32:29] <mru> and some have only 2
[15:32:56] <av500> "...Rendering a small part of an image uses less memory. Useful if you don't have enough system memory for rendering the entire image. Note however that if you're trying to render high-resolution/complex images on 32-bit systems, you may still run into problems even with tile rendering...."
[15:33:00] <mru> wonder how long it would take to render if I let the c2q churn away undisturbed
[15:33:14] <janneg> justlooking: distributing scenes or frames is probably easier
[15:33:34] <av500> janneg: but if we really want 6x1080p. slicing it per 1080p bit might make sense
[15:34:19] <mru> the wall is 6x1280x1024
[15:34:32] <av500> mru: but we can only decode 6-x1280x720
[15:34:46] <mru> even smaller
[15:34:53] <janneg> the commandline renderer was successful at 1080p, but still no luck at 3840x2048
[15:35:41] <mru> maybe I'll beat the c2q into shape again...
[15:35:42] <av500> so, 3840x1440
[15:35:42] <janneg> doesn't that just depend on the video codec?
[15:36:16] <av500> janneg: I guess raw YUV would be OK :)
[15:36:33] <mru> av500: not enough storage bandwidth
[15:36:34] <janneg> I was more thinking about mpeg2
[15:36:43] <mru> too high bitrate
[15:37:09] <mru> high-res mpeg2 gets constrained by vlc decoding after a while
[15:38:25] <kierank> how about making ffmpeg call read_frame multiple times but not moving the file pointer forward until the last stream is read?
[15:39:22] <kierank> s/read_frame/read_packet
[15:39:47] <av500> kierank: ?
[15:41:16] <kierank> av500: it's because dolby e has a weird structure in that one "stream" as viewed by the container actually contains multiple separate streams
[15:42:07] <kierank> but as I see it read_packet is designed only for reading one stream into one avpacket
[15:42:09] <kshishkov> merbzt: whole G2M3 frame is 'G2M3' sig and some chunks pasted together.
[15:46:07] <superdump> Dark_Shikari: ping?
[15:46:56] <superdump> Dark_Shikari: how many 1080p streams can one encode with good quality in real time on an i7?
[15:47:35] <av500> kierank: I guess you volunteer to implement demuxer chaining... :)
[15:50:38] <jez9999> BBB: not seeing any progress on issue 1740 :-)
[15:55:18] <BBB> jez9999, patience is a virtue
[15:55:36] <janneg> rendering at 2720x1440 was succesfull with 4G
[15:55:43] <merbzt> http://www.youtube.com/watch?v=EljaGpogiws
[15:57:15] <merbzt> kshishkov: anyway, I think it is a MSSC then
[15:57:31] <kshishkov> what's that?
[15:57:42] <merbzt> M$ Screen Codec
[15:57:51] <merbzt> forgot the 4cc
[15:57:53] * kshishkov does not know a thing about it
[15:59:04] <justlooking> superdump,  "#videolan 17:37 <Dark_Shikari> x264 on "ultrafast" is 100 times faster than on "placebo ... Dark_Shikari> ultrafast is generally overkill ....Dark_Shikari> don't use it, its compression is awful ...Dark_Shikari> it _can_ get realtime 1080p on one core... Dark_Shikari> but you'd be insane to do it =p " so i guess you might get away with useing fast or faster! for 4 streams.
[15:59:13] <merbzt> kshishkov: http://support.gotomeeting.com/ics/support/default.asp?deptID=5641
[15:59:22] <merbzt> look at the preferences text
[16:02:05] <merbzt> the codec is something from the wmp9 suit
[16:02:35] <kshishkov> from what I see it's either converts it to wmv9 or uses something own
[16:03:32] <kshishkov> that's why it says wmv only for Mac
[16:04:01] <merbzt> hmm
[16:04:12] <merbzt> but the prefe
[16:04:35] <merbzt> preferences image said that with wmp9 you didn't need any codec
[16:04:47] <kshishkov> yes, but it converts then
[16:05:42] <merbzt> MSS2
[16:05:48] <merbzt> that's what I think it is
[16:10:36] <kshishkov> unlikely - I'm pretty sure it won't play on Mac either
[16:12:16] <merbzt> kshishkov: I think we should bicker about this for the rest of the evening, that would be good use of the time
[16:12:46] * kshishkov is upgrading Flip4Mac to test
[16:13:04] <merbzt> ahhh, you even has a mac to test with cool
[16:13:25] <kshishkov> my primary workhorse - MacMini with PowerPC
[16:14:33] <av500> kshishkov: I didnt know they ship all the obsolete tech to .ua
[16:15:17] <kshishkov> av500: where does it end then? But I've bought it when Apple hasn't even thought about Intel CPUs
[16:15:44] <av500> kshishkov: I thought they ship it to japan as landfill
[16:15:50] <kshishkov> it was a few months before I got CVS writing access on FFmpeg actually
[16:17:56] <kshishkov> av500: nah, otherwise KotH would have disguised himself as IBM PCjr
[16:27:12] <CIA-90> ffmpeg: rbultje * r21896 /trunk/libavformat/ (rtsp.c rtsp.h):
[16:27:12] <CIA-90> ffmpeg: Rename RTSP_STATE_PLAYING to _STREAMING, since that better covers the
[16:27:12] <CIA-90> ffmpeg: future use of the rtsp* codebase for RTSP muxing.
[16:27:12] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>.
[16:46:26] <av500> BBB: http://pastebin.ca/1802786
[16:46:50] <av500> thats what I get in the caption stream
[16:49:51] <ramiro> astrange: for static ffmpeg.exe, I think nothing... It's probably similar to not calling WSACleanup(). btw I'm using this patch for pthreads-win32 now http://ffmpeg.pastebin.com/m5c6f5164 . This way it links both with mingw and msvc.
[16:50:12] <BBB> jez9999, almost there with your patch
[16:56:27] <BBB> av500, that looks about right
[16:56:54] <BBB> av500, now, is there anything in the stream header that allows us to assign a codecid to this stream? I mean anything?
[16:57:14] <BBB> right now it's CODEC_TYPE_DATA with CODEC_ID_NONE
[16:57:17] <BBB> which isn't useful
[16:57:33] <BBB> I want it to be CODEC_TYPE_SUBTITLE With CODEC_ID_SPECIALTEXTFORMAT
[16:57:33] <BBB> or so
[16:58:52] <av500> :)
[16:59:06] <av500> yes, I just asked my self the same thing in my own asf/mms handler :)
[17:05:38] <ramiro> can anyone help me understand juan gonzales' second response to the thread here: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/dm3x/f/100/p/35397/123612.aspx#123612
[17:07:05] <mru> he's saying the low-level functionality is exposed by vicplib but the TI codecs implemented on top of that are available as binaries only
[17:07:06] <ramiro> there must be a way to call the optimized hardware directly for the codec-specific optimized functions. or are there no such functions? (vicplib only contains generic math optimizations)
[17:07:56] <av500> ramiro: ?
[17:08:05] <av500> he says no source code for the codecs
[17:08:27] <av500> although the codecs mostly use the hw accell, they do not provide the source
[17:08:36] <ramiro> ah, ok... I just don't think that's what I asked =)
[17:08:42] <av500> but you could use the hw accells to make your own codecs
[17:09:27] <av500> but what do you mean with: "From the current vicplib I don't see any codec-specific optimization."
[17:09:43] <ramiro> in lavc we have a bunch of h264 specific optimizations for example
[17:12:16] <av500> ramiro: right, I never looked deeply into the viclib
[17:12:44] <av500> could well be that ti did just a token effort there and did not include any of the highly specific stuff
[17:14:21] <av500> ramiro: and yes, TI engineers are very skilled in not answering your questions
[17:18:10] <CIA-90> ffmpeg: stefang * r21897 /trunk/libavcodec/ (indeo5data.h indeo5.c): remove ivi5_scans8x8[0], it duplicates ff_zigzag_direct
[17:18:21] <Honoome> av500: hahaha that's quote-worthy! :D
[17:20:32] <Rathann|work> Honoome: there's a quote collection page on the wiki, feel free to contribute
[17:21:57] <ramiro> I wonder what TI means by "natural C".
[17:22:35] <av500> organic C
[17:23:48] <CIA-90> ffmpeg: vitor * r21898 /trunk/libavcodec/Makefile: Add missing dependency of TwinVQ
[17:27:23] <CIA-90> ffmpeg: rbultje * r21899 /trunk/libavformat/rtsp.h:
[17:27:23] <CIA-90> ffmpeg: Remove stale function declaration.
[17:27:23] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>.
[18:32:50] <Compn> mru : does your ppc box have osx on it ?
[18:33:05] <mru> no
[19:15:18] <BBB> peloverde, are you interested in aac encoder bugs?
[19:15:51] <kshishkov> on the contrary, he is interested in bugfree encoder
[19:16:07] <BBB> I could hand him bugs, he could then fix 'em
[19:16:12] <BBB> ..
[19:16:13] <BBB> profit!
[19:16:47] <peloverde> kind of, i have plans for the AAC encoder but they involve some degree of re-architecting
[19:17:09] <kshishkov> you are in charge of it anyway
[19:17:55] <peloverde> I am, but its on the back burner at the moment
[19:18:33] <kshishkov> indeed
[19:19:01] * kshishkov is trying to sneak a codec into FFmpeg instead of improving AAC encoder too
[19:19:47] <peloverde> In my defense HE-AAC dec has been on the wishlist for a while
[19:20:10] <peloverde> plus there was well defined money on the table
[19:21:21] <kshishkov> nobody care[sd] about Bink
[19:21:41] <kshishkov> still, somebody has to RE those codecs
[19:22:24] <peloverde> the RDFT for bink wound up being useful in SBR
[19:22:33] <Dark_Shikari> I'm just surprised the price for HE-AAC was so low
[19:22:42] <Dark_Shikari> by comparison there's probably at least $20k on the table for MBAFF support in x264
[19:22:47] <Dark_Shikari> and you could scrounge up more pretty easily
[19:23:04] <kshishkov> someone should optimize it too - Bink audio decoder is usually thrice CPU-hungry as Bink video
[19:23:41] <peloverde> The bulk of it was already written when i started on it
[19:24:01] <kshishkov> IIRC Rob also got something for it
[19:25:06] <peloverde> also it's essentially re-writing something under a more liberal license
[19:25:28] <kshishkov> heh
[19:25:37] <peloverde> Most people who need HE-AAC can use FAAD under the GPL or buy a commercial license
[19:25:46] <BBB> peloverde, ok, so basically I gather from that that it's interesting, but no thanks?
[19:25:57] <Dark_Shikari> well, faad sucks
[19:26:07] <BBB> all external libs suck
[19:26:09] <kshishkov> BBB: interesting but not now
[19:26:09] * BBB winks @ x264
[19:26:15] <Dark_Shikari> btw, we have the x264 contribution agreements almost done
[19:26:16] <BBB> kshishkov, got it
[19:26:17] <Dark_Shikari> got almost all the rights
[19:26:21] <peloverde> BBB: It'd be nice to see them but there are no guarantees on a timeframe for fixing them
[19:26:27] <Dark_Shikari> so if we get sales going soon... maybe we could fund some aac improvements ;)
[19:26:30] <BBB> http://www.wired.com/images_blogs/underwire/2010/02/googlesauron.png
[19:26:46] <peloverde> I wouldn't spend a lot of time doign fancy bugreports but if you know the gist of something it'd be good to see
[19:27:00] <BBB> nah, don't want to distract you too much
[19:27:02] <BBB> I'd feel bad about it
[19:27:12] <BBB> particularly because I'm not doing anything useful right now
[19:27:37] <peloverde> If you want to make yourself useful write an SSE RDFT :)
[19:27:37] <kshishkov> work on multirate RM ;)
[19:28:21] * BBB cries
[19:28:36] <BBB> I thought if I go into NGO-related stuff, I'd get rich and famous without any effort
[19:29:20] <kshishkov> yes, just wait
[19:29:47] * kshishkov could live without fame
[19:45:21] <iive> BBB: if you want to get rich without any effort, make your own bank
[19:55:18] <peloverde> I'd rather get rich working on FFmpeg
[19:56:21] <peloverde> BBB: were these any of the patents you had been told about? http://www.0xdeadbeef.com/weblog/2010/02/some-additional-information-about-theora-and-patents/
[20:00:20] <Compn> kshishkov : did you get a chance to play disc golf in sweden? http://www.youtube.com/watch?v=nhxqHH6_2c0
[20:00:47] <kshishkov> Compn: I'm not into sports completely
[20:03:22] <Compn> ah but this sport you can play by yourself ...
[20:05:06] <kshishkov> there are more interesting things to do in Sweden
[20:05:57] <pJok> kshishkov, like look at swedish girls? ;)
[20:06:38] <BBB> peloverde, is that diego's thing?
[20:06:52] <peloverde> Yeah, I just realized that
[20:07:07] <BBB> peloverde, anyway, that's work-in-progress
[20:07:26] <BBB> hopefully soon know more
[20:07:36] <kshishkov> pJok: for we it's merely walking around. Swedish beauty is not limited to girls only. There's also scenery and architecture.
[20:07:47] <pJok> true
[20:07:53] <peloverde> I've never really understood the dates thing, when they bring out their list of MPEG patents they have stuff hat was filed well after the standard was published
[20:08:05] <pJok> i should know, i live in a city older than many countries
[20:08:48] <pJok> in two years they are celebrating the 600th year of Landskrona
[20:09:07] <pJok> or was it three..
[20:09:15] <pJok> i think it was three actually
[20:09:43] <kshishkov> here it was 350 years several years ago
[20:10:04] <pJok> Helsingborg is even older
[20:10:57] <kshishkov> my sources told me it's also better than Helsingor
[20:11:04] <pJok> it is
[20:11:33] <pJok> the only thing Helsingør is good for is cheaper liquor
[20:11:55] <pJok> but the economics has put an end to that as well
[20:20:32] <CIA-90> ffmpeg: vitor * r21900 /trunk/libavformat/dsicin.c: Fix memory leak for truncated frames
[20:21:06] <CIA-90> ffmpeg: vitor * r21901 /trunk/libavformat/xa.c: Fix memory leak for truncated frames
[20:43:59] <CIA-90> ffmpeg: stefang * r21902 /trunk/libavcodec/ (wmadata.h wma.h wmaenc.c Makefile wmadec.c): remove a Huffman table from WMA which also exists in AAC
[20:45:56] <janneg> http://www.jannau.net/01_intro_01c.mkv first second of BBB in 2700x1440 for the videowall
[20:49:08] <peloverde> hmm... the video isn't intelligible on my version of mpc
[20:50:37] <janneg> doesn't play here either, xv overlay is limited to 2048x2048
[20:50:38] <peloverde> VLC doesn't seem to like it either
[20:51:10] <janneg> I probably should upload the pngs
[20:51:21] <peloverde> that would be nice
[20:51:47] <Compn> can gl/gl2 handle it ?
[20:51:51] <BBB> janneg? me?
[20:51:57] * Compn doesnt remember gl max limit
[20:52:00] <CIA-90> ffmpeg: daniel * r21903 /trunk/libavcodec/binkaudio.c: Fix compilation of binkaudio_rdft when dct is disabled
[20:54:19] <janneg> http://www.jannau.net/peach_2700x1440/
[20:54:26] <_av500_> janneg: i have patched ffmeg for larger than 2048...
[20:54:42] <janneg> BBB: no, sorry. Big Buck Bunny or peach
[20:55:27] <_av500_> BBB: we also take video of you in 6x720p
[20:56:03] <_av500_> janneg: wh 2700?
[20:56:06] <_av500_> y
[20:56:13] <Kovensky> Compn: IIRC gl depends on texture size limit; gl2 uses multiple textures
[20:56:17] <janneg> Compn: -vo gl displays at least something, hard to say if it plays the video
[20:56:57] <Compn> janneg : you probably need -vo gl:yuv=4 (with a modern video card)
[20:57:31] <janneg> _av500_: 1440 / 2 / 4 *
[20:57:33] <janneg>  5 *
[20:57:45] <janneg> _av500_: 1440 / 2 / 4 * 5 * 3 = 2700
[20:57:56] <Compn> or latest svn mplayer might do autodetection, i forget now
[20:58:15] <_av500_> janneg: it is 4:5?
[20:59:57] <janneg> it's 15:8 which should be the aspect of the videowall, assuming the single displays are 5:4
[21:00:58] <_av500_> right
[21:02:20] * _av500_ was confused
[21:02:38] <_av500_> so, how long for 1s?
[21:08:08] <janneg> 3 and a half hours real time on a core2duo 2GHZ, but the scene has low complexity
[21:08:38] <CIA-90> ffmpeg: daniel * r21904 /trunk/libavcodec/Makefile: Declare CAF demuxer dependency on mpegaudio
[21:08:43] <Dark_Shikari> how much memory did that need?
[21:09:49] <janneg> scene 02 of the intro needs 20 minutes per frame on my phenom II quad 3GHz
[21:10:36] <Kovensky> my computer can't render BBB, it would hit thermal shutdown before finishing a second :(
[21:10:45] <janneg> Dark_Shikari: it wasn't oom-ed with 4G
[21:11:13] <_av500_> janneg: i have a spare quad8800 here that is not used at all
[21:11:28] <_av500_> and i7 can render at nights
[21:12:07] <janneg> the commandline rendered has apparently better memory management
[21:13:35] <CIA-90> ffmpeg: daniel * r21905 /trunk/libavformat/Makefile: AEA demuxer requires raw.o for pcm_read_seek
[21:14:37] <janneg> _av500_: get the production files http://download.blender.org/peach/bigbuckbunny_production.torrent and install blender
[21:15:38] <janneg> we need a way to coordinate who is rendering which scenes. I claim the intro
[21:16:39] <peloverde> Do they not have any ultra high res reference renderings?
[21:17:43] <peloverde> Also I see a few licensed Dolby E products so a spec must exist somewhere
[21:21:20] * BBB goes crazy with all xchat pings on his screen
[21:21:26] <BBB> can't they name that video something else?
[21:21:49] <BBB> like CCC or so... or DDD
[21:21:51] <CIA-90> ffmpeg: daniel * r21906 /trunk/libavcodec/Makefile: Declare WMV1 decoder dependencies
[21:22:00] <janneg> we could try to use the code name "peach"
[21:22:07] <iive> BBB: i thought you took your nick from it.
[21:22:44] <janneg> OTOH BBB has tab completion
[21:22:51] <janneg> ;)
[21:23:41] <iive> isn't it about rabbit?
[21:34:57] <BBB> av500, so did you get anything from that stream?
[21:35:17] <Kovensky> so, what do you guys intend to do with BBB
[21:35:36] <BBB> they want to cut me in pieces, then encode me with theora so I get all garbled up
[21:35:39] <CIA-90> ffmpeg: daniel * r21907 /trunk/libavcodec/Makefile: msmpeg4v* encoders depend on h263dec
[21:35:40] <BBB> or so
[21:37:45] <Kovensky> BBB: D:
[21:48:17] <kierank> <@peloverde> Also I see a few licensed Dolby E products so a spec must exist somewhere --> For many tens of thousands of dollars yes and with onerous licensing conditions
[21:50:33] <kierank> I believe the licence forces you to use DRM on your decoder
[21:53:36] <peloverde> once a spec is out there, you are going to start to find shoddy third party implementations with debugging symbols left on and whatnot
[21:54:30] <Kovensky> one has to wonder if they don't do it on purpose
[21:58:03] <kierank> They seem to be very selective about it. There are only 2 software decoders in existence afaik
[21:58:43] <kierank> both with the same drm
[21:58:48] <peloverde> There are probably 3 or 4
[21:58:55] <peloverde> the two third part ones
[21:59:10] <kierank> there are ts analyzers that support it but i don't think they are full decoders
[21:59:15] <kierank> third part?
[21:59:22] <peloverde> *third party
[21:59:32] <peloverde> and from what i understand when I was at 999 Brannan they should have at least two internal codebases
[22:00:13] <kierank> because people from BBC i spoke to a while ago were looking for a software decoder but they said they could only find the two i know of
[22:01:11] <peloverde> I think maybe we should skip dolby e and get a head start on dolby f
[22:04:40] <kierank> wow there's an ac-2
[22:10:53] <CIA-90> ffmpeg: kostya * r21908 /trunk/libavformat/bink.c: Make Bink demuxer skip all zero audio tracks, not only the first one
[22:14:08] <CIA-90> ffmpeg: kostya * r21909 /trunk/libavformat/Makefile: WavPack demuxer also depends on APE tag parser
[22:20:02] <kierank> hmmm so there is a native dolby e decoder: http://www.dolby.com/professional/products/broadcast/test-and-measurement/dolby-media-meter.html
[22:24:46] <CIA-90> ffmpeg: kostya * r21910 /trunk/libavcodec/apedec.c: 16l trocadero: don't forget to free frame data buffer in APE decoder
[22:49:06] <elenril> nice, silent hill 2 videos now look ok
[22:52:24] <_av500_> BBB: no, not yet, as u said 1st thing is to try to find out when this data is captions at all...
[22:54:48] <jez9999> BBB: see patch9 to issue 1740.
[22:55:01] <iive> there is something fishy in these commits.
[22:56:19] <iive> kostya never stays that late at night
[23:02:05] <BBB> jez9999, commented
[23:02:23] <BBB> _av500_, right... so will you work on that? so I know where to focus my efforts :)
[23:06:21] <_av500_> not sure i will have time these days
[23:06:37] <_av500_> but are there many streamslike that?
[23:11:10] <CIA-90> ffmpeg: rbultje * r21911 /trunk/libavformat/rtsp.c:
[23:11:10] <CIA-90> ffmpeg: Make rtsp_close_streams() take a AVFormatContext instead of a RTSPState
[23:11:10] <CIA-90> ffmpeg: argument, so we can use AVFormatContext->* here in the future.
[23:11:10] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>.
[23:12:49] <CIA-90> ffmpeg: rbultje * r21912 /trunk/libavformat/rtsp.c:
[23:12:49] <CIA-90> ffmpeg: Use mode=receive instead of mode=play if in RTSP muxer (instead of demuxer)
[23:12:49] <CIA-90> ffmpeg: mode.
[23:12:49] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>.
[23:14:13] <CIA-90> ffmpeg: rbultje * r21913 /trunk/libavformat/rtsp.c:
[23:14:13] <CIA-90> ffmpeg: Only send out NAT-punching RTP/RTCP packets when we're in demuxer mode, i.e.
[23:14:13] <CIA-90> ffmpeg: don't send them when acting as a RTSP muxer.
[23:14:13] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>.
[23:22:37] <CIA-90> ffmpeg: rbultje * r21914 /trunk/libavformat/rtsp.c:
[23:22:37] <CIA-90> ffmpeg: Split out input-specific parts of rtsp_read_header() into its own, new,
[23:22:37] <CIA-90> ffmpeg: function (rtsp_setup_input_streams()), as preparation for the upcoming
[23:22:37] <CIA-90> ffmpeg: RTSP muxer.
[23:22:37] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>.
[23:24:31] <CIA-90> ffmpeg: rbultje * r21915 /trunk/libavformat/rtsp.c:
[23:24:31] <CIA-90> ffmpeg: Split rtsp_read_header() into two functions, so that the main part (now also
[23:24:31] <CIA-90> ffmpeg: known as rtsp_connect()) can be used in the RTSP muxer.
[23:24:31] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>.