[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-... wait, what? [06:35:47] <astrange> ramiro: http://ffmpeg.arrozcru.org/wiki/images/d/dd/Ffmpeg_r15966_static_pthreads.di... what happens without the atexit()? [06:58:03] <elenril> and some HD videos encoded in AVC or h.264 formats. << lol@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/QTFFPref... [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-li... [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_f... [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/... [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-t... [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/do... [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>.