[FFmpeg-devel-irc] IRC log for 2010-04-13

[irc at mansr.com]

[00:03:33] <Kovensky> <@Vitor1001> Kovensky: My point is that in a first time, it would be better to suppose your filtering framework can ignore these problematic cases... <-- I see
[00:04:19] <Kovensky> <@Vitor1001> Am I the only one bothered about the effort duplication between ffmpeg and x264? <-- ffmpeg has too many conflicts with libx264; but I don't wish to take part in that flamewar
[00:04:27] <Kovensky> <SmkMnstr> what about about openmax <-- what's openmax anyway
[00:04:55] <Vitor1001> Kovensky: Which conflicts?
[00:06:15] <Kovensky> IIRC the biggest annoyance is ffmpeg not supporting per-codec defaults, and having obscure / maybe overcomplicated ways to specify common options; but I guess you better ask D_S about those or see ffmpeg-devel logs
[00:06:43] <Vitor1001> I don't see how is this related with libavfilter...
[00:07:25] <Kovensky> well, the project is just to "support audio encoding in x264", but since there might be resampling / remixing needs, I decided to make it a full audio filtering system ._.
[00:08:10] <peloverde> is resampling still super bugged in ffmpeg?
[00:09:45] <Kovensky> I wrote a fair bit of code that worked with x264's lavf and ffms demuxers and the flv muxer, but I'm having to scrape it because my design was all wrong :P
[00:10:15] <mru> that's motivation to get it right next time :-)
[00:10:21] <Kovensky> indeed :)
[00:10:42] <Vitor1001> Kovensky: It's normal. Getting the design right is hard.
[00:10:44] <Kovensky> the biggest mistake I guess is that I made it work by pushing data, instead of pulling =p
[00:10:54] <Vitor1001> hmmm
[00:11:03] <Kovensky> the code also had o9k asserts and special cases q_q
[00:11:35] <Vitor1001> I'm not sure there is an enormous advantage between pushing/pulling
[00:12:29] <Kovensky> well, when you pull, you only do the minimum work required, and it moves most of the complexity to the muxer
[00:12:49] * mru has a curious case where adding a 'volatile' makes the code _faster_
[00:13:36] <Kovensky> lolgcc?
[00:14:26] <mru> a value needs to be moved from a float reg to an integer reg on cortex-a8
[00:14:28] <mru> that's slow
[00:15:07] <mru> making the variable volatile forces gcc to store it in memory and load it with a normal integer load instruction
[00:15:15] <mru> and there's a bunch of code between
[00:15:23] <mru> so the delay is masked
[00:15:48] <mru> without the volatile it does a slow register transfer just before it needs the value
[00:19:53] <Vitor1001> <Kovensky> well, when you pull, you only do the minimum work required, and it moves most of the complexity to the muxer
[00:20:06] <Vitor1001> Yes, but feeding it with data is tricky
[00:49:40] <CIA-81> ffmpeg: mru * r22867 /trunk/libavcodec/arm/Makefile: 10l: fix build on non-NEON ARM
[01:20:47] <CIA-81> ffmpeg: vitor * r22868 /trunk/libavformat/vqf.c: Use a suitable timebase in VQF demuxer
[01:21:25] <Kovensky> <@Vitor1001> Yes, but feeding it with data is tricky <-- as for pushing, I have run into several queue management problems
[01:22:06] <Kovensky> what to do when you can't push a packet to the next filter because a queue is too big? block? that'd force every filter to run on its own thread; fail? what about data that you already consumed?
[01:22:55] <Kovensky> also, when using --frames and the audio was from an external source, way more packets were decoded than actually needed
[01:22:59] <Vitor1001> This problem remains. For the "delay=1h" filter, for ex.
[01:23:08] <astrange> why is the queue a limited size?
[01:23:48] <Vitor1001> astrange: If anything needs hundreds of MBs of buffering, its a bug.
[01:23:48] <Kovensky> because an unlimited queue could grow too large?
[01:25:01] <Kovensky> http://github.com/Kovensky/x264-audio/compare/audio...audio_mess#files_bucket <-- this was my failed attempt at getting it to work on push mode before discarding everything and starting work on pull
[01:25:52] <Kovensky> that code compiles and runs, but produces incorrect output, and I couldn't figure out exactly why (dumping raw packets right after the encoder gave correct results on the dump, but it all borked on the muxed file)
[01:26:11] <Kovensky> the a/v sync and timestamp ordering code was also pretty hackish >_>
[01:26:21] <Vitor1001> I didn't really mean you should use push
[01:26:29] <Kovensky> moving that to muxers will make it a lot easier to do proper interleaving
[01:26:49] <Vitor1001> I only mean that sometimes the filter framework will want to get more audio data  than what has been decoded
[01:27:19] <Vitor1001> I'm not sure you can always just keep on demuxing until you get enough audio data
[01:27:31] <Vitor1001> what will you do with the video frames in the meantime?
[01:28:15] <Kovensky> that'd be a negative af_delay I guess, and yes, I tried thinking about it and it wasn't pretty :S
[01:28:35] <Kovensky> it's easy to do on regular files (just open another AVFormatContext and use that for audio), but on pipes...
[01:28:52] <Vitor1001> Kovensky: Yes, some buffering will be needed.
[01:29:27] <Vitor1001> While "delay=1h" is something completely useless and hard to implement, "delay=1s" is useful (for broken sync files) and should be doable...
[01:31:02] <Kovensky> yes
[01:32:05] <Kovensky> another thing I had completely forgotten but this delay filter discussion reminded me of: files that do specify the audio delay
[01:32:10] <Kovensky> I'd have to copy that delay
[01:33:38] <Vitor1001> That's not audio filtering job.
[01:33:51] <Vitor1001> This is also true if you are not doing any filtering whatsoever
[01:33:56] <Vitor1001> this is demuxer's job.
[01:36:15] <Kovensky> I see
[05:03:51] * peloverde loves how there is a major special case in the PS spec not covered by the conformance suite
[05:04:50] <Dark_Shikari> hey, there are profiles of h264 that aren't fully implemented in the reference decoder
[05:05:56] <peloverde> There are sample rates missing from the AAC conformance suite
[05:06:51] <peloverde> When I asked their response was: why would you want to use 7350 Hz? My response: I don't know but you put it in the spec and mandated it for this profile
[05:07:03] <saintd3v> lol
[05:08:22] <Dark_Shikari> I asked about 4:2:0 lossless
[05:08:25] <Dark_Shikari> which JM still can't decode
[05:09:49] * kshishkov wonders when people start to discuss the greatest piece of news about new open codec
[05:10:18] <Dark_Shikari> welcome to 2 months ago
[05:10:27] <Dark_Shikari> it was also discussed here only a few hours ago
[05:10:47] <kshishkov> fine, checked
[05:12:01] <kshishkov> and can 420 lossless H.264 be decoded with lavc?
[05:12:32] <Dark_Shikari> yes
[05:12:54] <kshishkov> then why not slow down lavc decoder by tenfold and call it the reference one?
[05:13:08] <Dark_Shikari> lol
[05:16:19] <saintd3v> fork("folding at home.exe");
[05:17:24] <kshishkov> IIRC that's used in x264 --placebo mode
[05:17:55] <saintd3v> DS hasn't comitted it yet :/
[06:00:41] <Tjoppen> http://newteevee.com/2010/04/12/google-to-open-source-vp8-for-html5-video/ (via slashdot)
[06:00:56] <kshishkov> not a news here
[06:01:26] <KotH> hoi zäme
[06:01:29] <peloverde> a) we've discussed that twice already today
[06:01:38] <peloverde> b) VP8 is still vapor ware at the moment
[06:01:45] <Dark_Shikari> c) it's still 2 month old news
[06:01:54] <Tjoppen> aw
[06:01:55] <peloverde> c) read the ./ comments if you want a laugh
[06:02:13] <Dark_Shikari> d) I'll bet $100 it still loses to x264 in SSIM ;)
[06:02:16] <Tjoppen> I do. breakfast laughs are the best
[06:04:10] <kshishkov> reminds me of "Blizzard disclosed when it's going to announce Diablo 2 release date" news
[06:05:03] <kshishkov> s/Diablo/Starcraft/
[06:05:36] <Dark_Shikari> lol
[06:05:46] <Dark_Shikari> "blizzard announces the date of its announcement of the date of the starcraft 2 release"
[06:05:51] <peloverde> StarCraft 2 isn't vaporware though, I've seen it in the wild
[06:05:55] <Dark_Shikari> I have it installed >_>
[06:06:02] <peloverde> I can't say the same thing about VP8
[06:06:43] <kshishkov> BTW, what happened with On2 custom codec aptly names "AVC" ?
[06:12:44] <superdump> if you're talking about the /. vp8 article... i guess i'm going to join the skeptical club
[06:12:50] <superdump> there's no reference at all
[06:12:56] <superdump> 'multiple sources' - like who?
[06:13:29] <kshishkov> rumours
[06:13:32] <superdump> i hear from multiple sources that i'm going to shit out a vp8 codec implementation tomorrow morning
[06:13:39] <jai> lol
[06:13:40] <Dark_Shikari> mru: ping
[06:14:34] <kshishkov> reminds me that we had Rar 3 long before it was released - somebody changed version in Rar 2 and added a virus to it
[06:14:56] <superdump> starcraft 2 is real
[06:15:08] <Dark_Shikari> speaking of which, anyone want to play a game?
[06:15:12] <superdump> Dark_Shikari: i saw that news article about the big scandal
[06:15:20] <Dark_Shikari> I need someone who sucks as much as I do
[06:15:21] <Dark_Shikari> superdump: which one
[06:15:41] <superdump> the e-sports starcraft game fixing
[06:15:46] <kshishkov> Dark_Shikari: in you case it will be either StarTouhou 2 or TouhouCraft 2 of which I own none
[06:15:49] <Dark_Shikari> wait, what?
[06:15:56] <Dark_Shikari> kshishkov: That would be awesome
[06:15:59] <Dark_Shikari> starcraft + danmaku!
[06:16:11] <Dark_Shikari> And all the units would be replaced with little girls
[06:16:27] <superdump> Dark_Shikari: http://games.slashdot.org/story/10/04/13/0359232/StarCraft-Cheating-Scandal-Rocks-Korea?from=rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+Slashdot/slashdot+(Slashdot)
[06:16:35] <kshishkov> good luck finding third species
[06:16:37] <peloverde> "If IE doesn't support it [vp8], that might just be the nail in the coffin."
[06:16:45] <superdump> hahaha
[06:16:51] <peloverde> does slashdot have lead in it's water supply?
[06:17:11] <superdump> well, i think getting IE and Safari to support anything other than h.264 now would be hard anyway
[06:17:21] <superdump> but that's because IE is lazy
[06:17:22] <Dark_Shikari> superdump: oh shit
[06:17:22] <Dark_Shikari> wow
[06:17:26] <Dark_Shikari> savior?  dammmmn
[06:17:33] <Dark_Shikari> kshishkov: easy
[06:17:34] <superdump> and Safari is tied to h.264
[06:17:35] <Dark_Shikari> Humans == Terran
[06:17:42] <Dark_Shikari> Youkai == Protoss
[06:17:47] <Dark_Shikari> and third.... er....
[06:17:54] <kshishkov> Zergs
[06:17:56] <Dark_Shikari> lol
[06:18:00] <Yuvi> fairies?
[06:18:04] <superdump> tentacle porn things
[06:18:06] <Dark_Shikari> fairies do sorta zerg-swarm
[06:18:10] <Dark_Shikari> But they're not exactly a credible threat
[06:19:33] <kshishkov> you can grab stratagus engine and hack something with it
[06:19:43] <Dark_Shikari> well we already have Touhou Fortress 2
[06:20:37] <Dark_Shikari> http://i228.photobucket.com/albums/ee218/zeldagamer501/ayass5.jpg
[06:20:38] <astrange> safari supports theora on my computer
[06:20:53] <Dark_Shikari> astrange: perian
[06:20:57] <Yuvi> how many people install xiphqt?
[06:21:01] <astrange> dunno
[06:21:12] <astrange> just need to make the install really user-friendly
[06:21:13] <kshishkov> I did
[06:30:18] <Dark_Shikari> hmm
[06:30:32] <Dark_Shikari> CP128( h->mb.cache.mv[l][i8], h->mb.mv[l][top_4x4] );
[06:30:35] <Dark_Shikari> #define CP128(dst,src) M128(dst) = M128(src)
[06:30:37] <Dark_Shikari> #define M128(src) (((x264_uint128_t*)(src))->i)
[06:30:42] <Dark_Shikari> typedef union { x264_uint128_t i; uint64_t a[2]; uint32_t b[4]; uint16_t c[8]; uint8_t d[16]; } MAY_ALIAS x264_union128_t;
[06:30:45] <Dark_Shikari> typedef struct { uint64_t i[2]; } x264_uint128_t;
[06:30:46] <Dark_Shikari> astrange: why is this invalid?
[06:30:53] <Dark_Shikari> "incompatible types in assignment"
[06:32:07] <astrange> you can't assign arrays to each other
[06:32:14] <Dark_Shikari> But I'm not
[06:32:18] <Dark_Shikari> I'm assigning structs to each other
[06:32:27] <Dark_Shikari> the structs just happen to contain an array.
[06:32:36] <astrange> (((x264_uint128_t*)(src))->i) isn't a uint64_t[2]?
[06:33:00] <Dark_Shikari> no, it's a x264_uint128_t
[06:33:02] <kshishkov> it should cast to union, not int then
[06:33:05] <astrange> m128 should be union128
[06:33:06] <astrange> not uint128
[06:33:10] <Dark_Shikari> oh duhhh
[06:33:42] <Dark_Shikari> now it fails on M128(x) = 0; cases (there are no cases of assigning constants to M128 other than zero)
[06:33:46] <Dark_Shikari> Should it be {0,0}?
[06:35:25] <astrange> (__m128i){} or (uint64_t[]){} should work
[06:36:26] <Dark_Shikari> so I need to do
[06:36:31] <Dark_Shikari> M128(x) = M128_CONST(y)
[06:36:44] <Dark_Shikari> where #define M128_CONST(x) (uint64_t[]){x} ?
[06:37:05] <astrange> {x,x}
[06:37:15] <Dark_Shikari> still won't work
[06:37:28] <Dark_Shikari> using (uint64_t[]){0,0}
[06:37:30] <astrange> oh
[06:37:44] <astrange> i guess that's assigning arrays...
[06:38:11] <Dark_Shikari> would it work if we made the struct have two values?
[06:38:12] <Dark_Shikari> i.e. a and b
[06:38:13] <astrange> (struct {uint64_t i[2]})({{x,x}}) can you do that? (does it generate anything vaguely sane?)
[06:38:14] <Dark_Shikari> instead of [2]
[06:38:25] <astrange> yeah
[06:38:53] <Dark_Shikari> = {0,0} doesn't work for the a,b example
[06:40:26] <astrange> it has to be casted
[06:40:55] <astrange> you could compile stuff through clang if you can get a build without too much trouble, it'll give somewhat clearer errors
[06:41:55] <Dark_Shikari> how do I cast it?
[06:41:58] <Dark_Shikari> (uint64_t){0,0}?
[06:42:09] <astrange> (struct something with two values)
[06:43:01] <Dark_Shikari> your #define M128_ZERO (struct {uint64_t i[2]})({{0,0}}) definitely doesn't work
[06:43:18] <Dark_Shikari> even if I add the missing semicolon
[06:43:22] <Dark_Shikari> I mean, it just outright parse errors
[06:43:56] <CIA-81> ffmpeg: gb * r22869 /trunk/libavcodec/vaapi_h264.c:
[06:43:56] <CIA-81> ffmpeg: [VA-API] Fix long-term reference frames addition to the DPB.
[06:43:56] <CIA-81> ffmpeg: This fixes MR2_MW_A/MR2_TANDBERG_E on Intel Ironlake and NVIDIA HW.
[06:44:27] <astrange> probably because of missing ;
[06:44:35] <Dark_Shikari> Got it.
[06:44:39] <Dark_Shikari> #define M128_ZERO ((x264_uint128_t){{0,0}})
[06:44:40] <astrange> but that was the same thing as (x264_uint128_t) anyway
[06:44:42] <astrange> yeah
[06:44:51] <Dark_Shikari> it was the extra () borking it
[06:45:04] <astrange> if it's just 0 then {} is the same as {{{{{0,...}...}
[06:55:48] <Dark_Shikari> astrange: what's the difference between __m128i and __m128?
[06:56:53] <astrange> __m128 is a float vector
[06:56:58] <Dark_Shikari> float's fine
[06:57:31] <Dark_Shikari> #define M128_CONST(x) ((__m128){{x,x}})
[06:57:33] <Dark_Shikari> that doesn't work
[06:57:36] <Dark_Shikari> do I have to do {x,x,x,x} or what?
[06:59:19] <astrange> yeah since it's 4x float
[07:00:03] <Dark_Shikari> #define M128_CONST(x) ((__m128){{x,x,x,x}}) still doesn't work
[07:00:09] <astrange> only one {}
[07:00:17] <Dark_Shikari> ah k
[07:00:23] <astrange> see _mm_set1_epi32 / _mm_set_epi32 in emmintrin.h
[07:00:42] <Dark_Shikari> Holy shit it did the code intelligently
[07:00:58] <Dark_Shikari> on gcc 3.4 even
[07:01:21] <Dark_Shikari> wait, nevermind that.  it reloads the pointers off the stack after every single xmm store.
[07:01:22] <astrange> it's not bad when there's no register pressure
[07:01:44] <Dark_Shikari> I think that it thinks the store can alias the stack (?!)
[07:01:48] <Dark_Shikari> I guess that's the MAY_ALIAS doing its magic...
[07:02:11] <Dark_Shikari> nah, dumb without the may_alias too.
[07:02:20] <astrange> __m128 is may_alias
[07:02:29] <Dark_Shikari> ahhh.
[07:03:11] <Dark_Shikari> now time to rewrite all the cache functions then
[07:03:30] <Dark_Shikari> woot, taking that into account nicely cut the code by a factor of 3.
[07:08:22] <av500> OMG, VP8 OPEN SOURCE!!!11!
[07:08:24] * av500 hides
[07:08:48] <elenril> x264 is doomed
[07:09:02] <kshishkov> well, that slashdot article should also add " FFmpeg devs facepalm"
[07:09:35] <av500> m(
[07:12:10] <jai> isnt there a site which interviews "FFmpeg devs", maybe they'll cover the news
[07:12:34] <kshishkov> I fear there isn't
[07:13:15] <jai> hmm, i dont remember the name, they covered the 0.5 release as well
[07:13:22] <kierank> phoronix?
[07:13:27] <av500> jai: http://weeklyworldnews.com/ ?
[07:13:32] <jai> ha, yeah i think it was that
[07:13:42] <jai> phoronix
[07:13:48] <jai> av500: lol
[07:14:09] <saintd3v> moronix?
[07:14:36] <kierank> I see what you did there...
[07:19:25] <superdump> does anyone here have any documentation of wma profiles/levels? if such things exist
[07:19:38] <av500> hmm
[07:19:55] <kshishkov> wma profiles?
[07:19:58] <kshishkov> unlikely
[07:20:08] <av500> superdump: let me check
[07:20:16] <superdump> thanks
[07:20:19] <kshishkov> but if such thing exists it will be coded in bitstream - like in vc-1
[07:26:43] <CIA-81> ffmpeg: benoit * r22870 /trunk/libavformat/utils.c:
[07:26:43] <CIA-81> ffmpeg: Do not probe when the format is known.
[07:26:43] <CIA-81> ffmpeg: Patch by Jean-Daniel Dupas devlists shadowlab org
[08:11:48] <merbzt> superdump: I have it in my head
[08:11:58] <merbzt> what do you want  to know ?
[08:14:26] <pJok> multiple sources in internet 'news': news sites quoting each other...
[08:15:51] <kshishkov> yep, reminds me of several cases when some lie from Wikipedia was reprinted elsewhere, deleted in wiki and then restored with reference to that source
[08:15:59] <superdump> pJok: news sites claiming truth from other news sites' speculations as to what might be a good thing?
[08:16:06] <superdump> lol
[08:16:43] <pJok> superdump, that is how the internet news business works...
[08:17:45] <kshishkov> whole internet is tied togetherby copypasting
[08:17:57] <av500> and tubes
[08:18:10] <av500> and Al Gore
[08:18:39] <kshishkov> pr0n for some people
[08:19:04] <kierank> its hillarious how murdoch got beaten by copy and paste
[08:19:11] <pJok> stories might 'start' or 'originate' on a speculative blog, then being picked up by a less legit news site as 'news' and quoted so many times over and over that more legit sites start picking up on the 'story' and suddenly you have your multiple sources that just started out as a rant on a blog
[08:19:21] <peloverde> Is there a list of AAC patents floating around?
[08:19:31] <kierank> peloverde: on the via licensing website
[08:19:50] <peloverde> I can't find an enumerated list there, just a list of patent owners
[08:21:19] <peloverde> I'm particularly interested in mpeg 2 AAC http://www.vialicensing.com/licensing/MPEG2AAC_Licensors.cfm
[08:21:45] <kshishkov> what about the list art the end of standard?
[08:21:59] <kshishkov> like Appendix I or something
[08:22:11] <peloverde> Again just the list of companies
[08:22:13] <av500> that might be "informative" only
[08:25:31] * kshishkov wonders why he always remembers Michael Palin in certain MPFC sketch after hearing "MPEG LA"
[08:26:28] <av500> peloverde: I'm trying to get it
[08:26:35] <peloverde> thanks
[08:27:10] <andoma> kshishkov: why do you think (Y)luma is not a good name for grey?
[08:27:23] <andoma> we seem to use it at other places in pixfmt.h and pixdesc.c
[08:27:40] <kshishkov> I don't think "ya" is not a good name for pixfmt
[08:28:04] <kshishkov> because in 50% of cases it means "yet another" and is not descriptive enough
[08:28:22] <av500> ya bro!
[08:28:27] <kshishkov> Y400A is better ;)
[08:28:38] <kshishkov> and technically correct too
[08:29:00] <andoma> ok, sounds good :)
[08:32:07] <kshishkov> andoma: even here it shows better approach to name selection - http://sl.se/templates/Page.aspx?id=1633
[08:34:35] <andoma> :)
[08:36:41] <kshishkov> also since it says "Pontus: Namnet är troligtvis av grekiskt ursprung och betyder ’hav’." and your last name is "Ö-man" you may end with grandchildren called "Vik", "Alv" and "Skärgården"
[08:40:26] <andoma> heh, I've never heard anyone with a lastname of 'skärgården' though :)
[08:41:21] <kshishkov> you have many other last names of marine origin
[08:44:04] <andoma> kshishkov: lastnames starting with 'sjö' is not unheard of
[08:44:35] <kshishkov> andoma: ask wbs
[08:45:11] <kshishkov> and I suspect that names ending with -ström also have something to do with water
[08:46:45] <kshishkov> but the easiest thing is to seek for somebody named Persson
[08:48:13] <Tjoppen> in roundup, if I suspect something is more serious than previously suspected, should I create a new issue for that and add the previous one as dependent?
[08:48:39] <kshishkov> maybe a new comment to that issue is enough
[08:49:09] <Tjoppen> https://roundup.ffmpeg.org/issue1695 , but sufficiently high bitrate even causes a segfault
[08:50:12] <Tjoppen> ok, fair enough. I should perhaps bump it to "important" though?
[08:50:13] <kshishkov> that's probably a different issue
[08:50:41] <Tjoppen> yeah, that's what I'm kind of suspecting. it's similar, and I can trigger issue1695 as well
[08:51:21] <kshishkov> it should be renamed to "AAC bitrate handling sucks"
[08:51:37] <kshishkov> and it's dependent on "AAC encoder totally sucks"
[08:53:26] <Dark_Shikari> float *x = (float*)&v4; float f4 = *x;
[08:53:33] <Dark_Shikari> Where do I put the may_alias here to shut gcc the fuck up?
[08:53:36] <Dark_Shikari> or is there a better way to do it
[08:54:12] <kshishkov> why intermediate?
[08:54:43] <Dark_Shikari> Doesn't have to be.
[08:55:40] <jai> shouldnt that be float *x?
[08:56:50] <Dark_Shikari> I guess I need a union here
[08:56:55] <scaphilo> does anyone know what the mb_threshold and me_threshold is for? in the MpegEncContext? http://dpaste.com/183185/
[08:57:07] <Dark_Shikari> try reading the code
[08:57:51] <Tjoppen> I went with the create-a-new-issue approach: https://roundup.ffmpeg.org/issue1877
[08:59:56] <scaphilo> Dark_shikari i tried if for hours but i dont understand the idea of it do you know? i just know that it has to do something with copying the motion vectors and macroblock types from the decoder to the encoder
[09:01:22] <Dark_Shikari> er, no, it doesn't
[09:01:26] <Dark_Shikari> at least I highly doubt it
[09:01:40] <Dark_Shikari> common/macroblock.c:17: error: unable to find a register to spill in class `SSE_
[09:01:43] <Dark_Shikari> REGS'
[09:01:46] <Dark_Shikari> what the fuck?
[09:02:02] <kshishkov> hello from gcc reg allocator
[09:02:57] <Dark_Shikari> I'm not even allocating registers!
[09:02:59] <Dark_Shikari> I'm using one at a time!
[09:03:02] <Dark_Shikari> via intrinsics!
[09:03:12] <merbzt> poor Dark_Shikari
[09:03:16] <kshishkov> and maybe gcc uses all of them for math?
[09:03:24] <Dark_Shikari> no, it doesn't
[09:03:40] <Dark_Shikari> also, it only started doing that once I fixed aliasing and used unions instead
[09:04:13] <merbzt> :)
[09:04:21] <kshishkov> gcc -S on the last working version?
[09:04:41] <merbzt> "my arm hurt when I do this" " don't do it then"
[09:05:09] <peloverde> <kshishkov> it should be renamed to "AAC bitrate handling sucks", it's almost encoder time again
[09:05:22] <Dark_Shikari> does that mean you'll make it not suck?
[09:05:26] <kshishkov> merbzt: yep, that's our local medical service
[09:05:53] <Dark_Shikari> well, it works in gcc 4
[09:05:57] <Dark_Shikari> should we break gcc 3.4 ? :)
[09:06:01] <kshishkov> Dark_Shikari: yes, that's his intent
[09:06:11] * Dark_Shikari looks
[09:06:26] * Dark_Shikari sees that gcc didn't generate vector instructions when using gcc4
[09:06:28] * Dark_Shikari HEADDESKS
[09:06:38] <peloverde> That's my goal
[09:08:46] <scaphilo> Dark_Shikari: certainly it has to do something with that. The copy_picture_attributes() in mpegvideo_enc.c copies the motion_val and mb_type veriable from the decoder picture to the encoder picture only when the me_threshold is set
[09:08:54] <pJok> Dark_Shikari, just start on ffcc ;)
[09:09:55] <kshishkov> scaphilo: it may be used in motion estimation to search from reference frame motion vectors with some threshold
[09:10:34] <kshishkov> and we may need fflibc as well
[09:10:57] <Dark_Shikari> scaphilo: see motion_est.c
[09:10:58] * peloverde curses ipd/opd for forcing me to rewrite PS mixing interpolation
[09:13:01] <av500> ipod?
[09:13:10] <scaphilo> thx for help
[09:13:42] <kshishkov> av500: no, probably some obscure variables used for parametric stereo
[09:17:08] <kshishkov> as you may know, AAC-HE extensions are fully well-documented and easy to understand and any kid may reimplement decoder from those
[09:17:27] * KotH didnt know that kshishkov is a kid
[09:18:50] <kshishkov> KotH: how did you infer that conclusion?
[09:19:51] <KotH> by extrapolation
[09:21:21] <kshishkov> go fix your extrapolator
[09:21:48] <kshishkov> I got a passport so I'm not a kid anymore *sigh*
[09:23:45] <KotH> ah.. then you can go to .se now!
[09:24:17] <kshishkov> I got _wrong_ passport for that
[09:27:20] <peloverde> ipd/opd is the phase control for PS mixing
[09:29:08] <peloverde> Implementing an AAC decoder is a fun task, I highly recommend it to anyone who has the patience and loves incorrect/misleading documentation
[09:29:42] * kshishkov looks at superdump
[09:30:06] <superdump> precis
[09:38:19] <pJok> who needs documentation?
[09:48:38] <Tjoppen> hah, nice. just found a XML schema describing the structure of MXF, including all DMS-1 metadata
[09:51:28] <mru> Dark_Shikari: pong
[09:55:44] <Dark_Shikari> mru: meh, long past.  was just going to ask general questions about using gcc intrinsics for simple stuff like copying
[09:55:49] <Dark_Shikari> and I've encountered all their shittiness already
[09:56:03] <mru> gcc intrinsics are _always_ shit
[09:56:05] <Dark_Shikari> like the gcc register allocator failing
[09:56:11] <Dark_Shikari> I haven't seen _that_ one fail before
[09:56:16] <Dark_Shikari> Not with intrinsics, that is
[09:56:38] <mru> I've seen one single intrinsic spit out a dozen extra loads and stores
[09:56:40] <Dark_Shikari> bonus points: it failed on a set of code that used only one register.
[09:56:53] <Dark_Shikari> mru: on x86 it actually works if you massage it right
[09:56:54] <Dark_Shikari> which is the intend
[09:56:57] <Dark_Shikari> *intent
[09:57:05] <mru> easier to write it in asm
[09:57:07] <Dark_Shikari> No it isn't
[09:57:15] <Dark_Shikari> Not for, say, CP128()
[09:57:22] <Dark_Shikari> or M128()
[09:57:25] <Dark_Shikari> and other type-pun macros
[09:57:27] <mru> that's what, two instructions?
[09:57:33] <Dark_Shikari> M128() = 0
[09:57:39] <mru> pxor, stor
[09:57:40] <mru> e
[09:57:40] <Dark_Shikari> Do you do a new xor for every store?
[09:57:58] <Dark_Shikari> what if you have four M128() = 0s?
[09:58:08] <mru> do you think gcc is clever enough to keep a zero around?
[09:58:11] <Dark_Shikari> It does.
[09:58:25] <Dark_Shikari> I'm on gcc 3.4 and it did everything properly.
[09:58:44] <Dark_Shikari> the single complaint I have is that SPLAT 32 -> 128 did 2x unpacklps
[09:58:47] <Dark_Shikari> instead of shufps
[09:58:55] <Dark_Shikari> Oh, and of course the register allocator failure.
[09:59:33] <Dark_Shikari> oh, the other thing I found, which you may want to consider in your code (not related specifically to intrinsics)
[09:59:50] <Dark_Shikari> suppose you have some codec context h, and some dynamically allocated data x in h.
[10:00:04] <Dark_Shikari> Suppose you also have some aliasing-avoidance macro like x264 and ffmpeg has.
[10:00:18] <Dark_Shikari> And you do CP32( h->x[some expression], blah ) for various "expression" values.
[10:00:25] <Dark_Shikari> gcc will recalculate the address in full every single time.
[10:00:30] <Dark_Shikari> because "x" could have been overwritten.
[10:00:41] <Dark_Shikari> It will do the same for CP32( blah, h->x[some expression] ) too.
[10:00:46] <mru> so use a local variable
[10:00:48] <Dark_Shikari> I did
[10:00:56] <Dark_Shikari> It's just something I found a lot of code doing
[10:01:00] <Dark_Shikari> and is a huge optimization potential
[10:01:00] <mru> gcc hates complicated expressions
[10:01:07] <mru> especially repeating ones
[10:01:11] <Dark_Shikari> lol
[10:01:19] <Dark_Shikari> it isn't the expressions though
[10:01:23] <Dark_Shikari> it's the pointer "x"
[10:01:24] <mru> not in this case
[10:01:29] <mru> but in general
[10:01:57] <mru> we had one case on the list where splitting an expression using a few temps _halved_ the amount of code generated
[10:02:38] <hyc> makes me wonder how gcc 2.0 would treat some of this code
[10:02:50] <mru> otoh, sometimes using a temp makes things slower too
[10:02:58] <mru> I had one of those cases yesterday
[10:02:59] <hyc> we did a lot of work on CSE way back when
[10:03:19] <Dark_Shikari> "temps making things slower or faster" are rarely gcc sucking
[10:03:27] <mru> how not?
[10:03:30] <Dark_Shikari> but rather you can use temps to convince gcc to do something different
[10:03:33] <Dark_Shikari> something which may be worse or better
[10:03:51] <mru> gcc should abstract the temps away and do the right thing in both cases
[10:03:58] <hyc> indeed
[10:04:00] <Dark_Shikari> sure, in a perfect world
[10:04:04] <mru> but it doesn't
[10:04:07] <mru> so gcc sucks
[10:04:08] <Dark_Shikari> humans are always smarter than compilers
[10:04:10] <hyc> it used to
[10:04:15] <Dark_Shikari> temps allow humans to give the compiler hints
[10:04:22] <mru> I'm just glad it doesn't abstract them away and do the _wrong_ thing in all cases
[10:05:04] <Kovensky> I've heard that whenever there's a good and a bad way to do some optimization, gcc almost always prefers the bad =p
[10:06:17] <hyc> there may be truth in that. gcc -Os often runs faster.
[10:06:33] <Dark_Shikari> only on extremely large applications
[10:06:34] <hyc> loop-unrolling vs I$ tradeoffs...
[10:06:47] <Dark_Shikari> Or in cases where loop unrolling/inlining is outright broken
[10:06:54] <mru> gcc is a bit too eager to unroll and inline
[10:07:02] <Dark_Shikari> depends on the arch
[10:08:46] <Kovensky> -vomit-frame-pointer \o/
[10:09:18] <mru> loop unrolling is good for two things: 1) reducing branching overhead, and 2) improving instruction scheduling
[10:09:28] <Dark_Shikari> 2) is useless on x86
[10:09:36] <mru> and gcc can't do it anyway
[10:10:09] <mru> on a modern cpu, branches take one cycle
[10:10:17] <Dark_Shikari> one?  often zero
[10:10:21] <mru> or that
[10:10:29] <hyc> x86 is impossible, unless you target a single chip family
[10:10:34] <mru> in a long-running loop they'll be perfectly predicted
[10:10:37] <hyc> model/revision..
[10:10:38] <Dark_Shikari> hyc: not really
[10:10:46] <Dark_Shikari> instruction scheduling is done by the cpu on OOE chips
[10:10:57] <Dark_Shikari> explicit instruction scheduling actually hurts performance
[10:11:06] <mru> cortex-a8 takes 2 mispreds before it adjusts
[10:11:23] <mru> Dark_Shikari: only to an extent
[10:11:29] <Dark_Shikari> mru: in my testing it does on x86
[10:11:41] <mru> then your testing was within that extent
[10:11:47] <Dark_Shikari> obviously it's a limited extent
[10:11:48] <DonDiego> Yuvi: you around and awake?
[10:11:56] <Dark_Shikari> the point is in general it's a waste of time
[10:12:04] <Dark_Shikari> or, better said
[10:12:08] <Dark_Shikari> it's useful _if you consider OOE_
[10:12:09] <mru> how long is the reorder queue on i7?
[10:12:14] <Dark_Shikari> which usually means very very long-range reordering
[10:12:20] <Dark_Shikari> i.e. in order to compensate for the queue limits
[10:12:25] <Dark_Shikari> I think it's like 50 instructions.
[10:12:42] <hyc> fetch is only 16 or 32 bytes tho
[10:12:49] <hyc> it makes a difference...
[10:13:04] <mru> if you fill the queue with dependent instructions or instructions all for the same exec unit, you lose
[10:13:09] <Dark_Shikari> mru: of course
[10:13:13] <mru> you have to keep a good mix
[10:13:15] <Dark_Shikari> that's not an ordering issue
[10:13:18] <Dark_Shikari> that's an instruction _choice_ issue
[10:13:27] <Dark_Shikari> Which is a huuuuge issue on x86.
[10:13:28] <mru> it's ordering too
[10:13:43] <mru> suppose you need to do a bunch of loads, some calculations, and a bunch of stores of the results
[10:13:55] <mru> interleaving the loads and the calculations helps
[10:14:00] <Dark_Shikari> not in my experience
[10:14:02] <hyc> yes, instruction choice is what makes "optimal" x8 impossible
[10:14:04] <Dark_Shikari> I've tried that in dozens of places
[10:14:07] <hyc> x86
[10:14:16] <Dark_Shikari> hyc: for GPR ops, instruction choice is pretty easy
[10:14:20] <Dark_Shikari> most cpus except p4 are similar
[10:14:23] <mru> in that case all your loads and at least some of the processing must have fit in the queue at once
[10:14:30] <Dark_Shikari> for SSE ops, they're already so different in throughput it doesn't matter
[10:14:54] * av500 imagines gcc vomit a frame pointer
[10:15:52] <CIA-81> ffmpeg: mru * r22871 /trunk/libavcodec/dca.c:
[10:15:53] <CIA-81> ffmpeg: DCA: optimise dca_subsubframe()
[10:15:53] <CIA-81> ffmpeg: 8% faster overall on Cortex-A8.
[10:15:53] <CIA-81> ffmpeg: mru * r22872 /trunk/libavcodec/dca.c: DCA: indent
[10:16:14] <Dark_Shikari> so, mru, is this another secret contract?
[10:17:18] <av500> Dark_Shikari: I guess he got a bluray boxed set of eastenders
[10:17:27] <mru> lol
[10:17:47] <Dark_Shikari> seriously though
[10:17:49] <Dark_Shikari> stop being so mum =p
[10:17:54] <av500> Dark_Shikari: yes
[10:18:20] <hyc> a blur-ray disc player? or a set-top box
[10:18:58] <mru> av500: yes what?
[10:19:01] <mru> you want to know too?
[10:19:14] <av500> yes, it is secret
[10:19:34] <av500> Dark_Shikari: I confirm it is a secret contract :)
[10:20:23] <kierank> it's a black contract
[10:20:31] <av500> black money!
[10:20:43] <av500> and black helicopters
[10:20:54] <kierank> don't forget vans
[10:22:11] <av500> sunglasses
[10:22:41] <hyc> mail
[10:30:31] <hyc> gray alpha? I'm surprised they didn't call it gray-Z
[10:30:41] <mru> gralpha
[10:30:56] <hyc> whatever happened to z-buffers
[10:35:11] <hyc> what does it even mean, render-wise. grayscale plus alpha means what?
[10:35:20] <hyc> just extra intensity bits
[10:35:41] <mru> it means exactly what it seems
[10:35:41] <av500> well, just one alpha channel added
[10:36:07] <av500> same as RGB vs RGB-A
[10:36:09] <mru> same as argb with r=g=b
[10:40:50] <hyc> yeah ok
[10:41:24] <hyc> gets confusing to think about what opaque means sometimes
[10:41:41] <hyc> transparent black.
[10:42:26] <mru> that just means you haven't done it enough
[10:42:42] <twnqx`> transparent aluminium?
[10:42:48] <hyc> probably true. not recently anyway.
[10:42:57] <mru> twnqx`: not invented yet
[10:43:15] <twnqx`> :(
[10:43:23] <mru> and that was a rubbish film too
[10:43:29] <hyc> the last time I did serious graphics coding, "True Color" meant 16 bit RGB(A)
[10:46:01] <kshishkov> hyc: man, you're old. It's called "HiColor" in my times
[10:46:22] <kshishkov> though on WinCE-based PDAs it's "the only color you can get"
[10:46:28] <hyc> lol
[10:48:14] <hyc> And "blitter" was the hot buzzword of the age
[10:48:31] <kshishkov> indeed
[10:48:38] <mru> blitters are nice
[10:49:00] * kshishkov searches his harddrive for "svga.bgi" and finds none
[10:49:01] <hyc> yes, but not talked about much these days. nobody focuses on 2D
[10:49:03] <mru> when you know how to use them
[10:49:20] <mru> look inside any current set top box
[10:49:24] <mru> blitters all the way
[10:49:38] <kshishkov> I saw a lot of blitters in Truemotion 1-VP3 code
[10:49:43] <hyc> I just get pissed off watching the Linux X11 work
[10:49:56] <hyc> everyone working on 3D shaders, whoop-de-doo
[10:50:03] <Dark_Shikari> draw_horiz_band is a blitter
[10:50:13] <mru> xorg is being driven into the ground, fast
[10:50:21] <mru> Dark_Shikari: I'm talking about hardware
[10:50:30] <Dark_Shikari> mru: xorg has been driven into the ground for 30 years
[10:50:33] <Dark_Shikari> ok, well just X
[10:50:35] <hyc> you still can't play full 1920x1080 H264 cleanly, but look, you can play the latest clone of the FPS 3D shooter
[10:50:36] <mru> no
[10:50:46] <mru> it was fine before the xfree86/xorg schism
[10:51:30] <kshishkov> hyc: maybe that's the reason many players keep OpenGL output driver
[10:51:40] <DonDiego> why is xorg being driven into the ground?
[10:51:40] <mru> great work, throwing out the best developers
[10:51:53] <mru> DonDiego: if only I knew...
[10:51:57] <DonDiego> it does look healthy ever since they separated from xfree86..
[10:52:06] <mru> about as healthy as a leper
[10:52:18] <hyc> gets a lot of attention at least
[10:52:18] <mru> xfree86 _worked_
[10:52:32] <mru> now I can't even find a combination of versions that builds
[10:52:35] <mru> let alone runs
[10:52:42] <mru> well, I have something installed
[10:52:54] <mru> from time to time, gentoo wants to update some component or other
[10:53:59] <hyc> I'm pretty pissed off that I never got hardware video codec acceleration for my video card between the time when it was the latest and greatest and the time it became unsupported/obsolete
[10:54:05] <mru> and more often than not, it fails to build
[10:54:18] <mru> so I just freeze the version at something that works
[10:54:48] <kshishkov> mru: just get some old shiffy videocard
[10:54:49] <hyc> I guess I should be happy about the shift to kernel modesetting
[10:54:52] <kshishkov> *shitty
[10:55:03] <hyc> that measn other windowing systems can leverage the work now
[10:55:16] <hyc> without having to just reimplement the entire X11 userspace
[10:55:21] <kshishkov> what systems?
[10:55:23] <mru> kshishkov: I use nvidia cards with binary drivers
[10:55:36] <hyc> time to dust off the MGR source tree again
[10:55:36] <kshishkov> Plan9 windowing system?
[10:55:54] <hyc> is the Plan9 code available somewhere?
[10:55:58] <kshishkov> mru: yes, that's the constant source of PITA
[10:56:04] <hyc> as I recall that was the successor to MGR
[10:56:04] <kshishkov> of course
[10:56:49] <kshishkov> hyc: http://plan9.bell-labs.com/plan9/
[10:56:57] <hyc> ah, 8-1/2
[10:57:14] <mru> kshishkov: I've had zero problems with the nvidia drivers
[10:57:47] <mru> it's always libXthis not liking some version libXThatProto
[10:58:00] <mru> and that in turn failing something else
[10:58:18] <mru> they split it into far too many pieces
[10:58:38] <mru> oh, and the input drivers don't work properly anymore
[10:58:54] <mru> I used to be able to hotplug mice and keyboards
[10:59:09] <mru> then they broke that
[10:59:17] <mru> then they broke the non-standard keys
[10:59:22] <mru> then they broke standard keys
[10:59:32] <hyc> hah. they "improved" it by making it depend on HAL
[10:59:34] <ohsix> that all sounds like gentoo problems :>
[10:59:40] <hyc> which they're now killing...
[10:59:54] <mru> every time I start X a few keys are misbehaving
[11:00:00] <kshishkov> hyc: _now_ that sounds like M$ Windows
[11:00:03] <mru> things like left or down arrow not repeating
[11:00:11] <mru> or a shift/control key not working
[11:00:46] <mru> poking it with xmodmap or xset get them back
[11:00:48] <mru> but it's annoying
[12:36:40] <kierank> http://www.telegraph.co.uk/technology/7572285/Music-to-the-ears-of-audiophiles.html
[12:39:22] <av500> nah, true audiophiles know that 24bit is 50% more digital(=bad, evil) than 16 bit...
[12:39:30] <mru> lol
[13:33:07] * kierank wonders what ubuntu did with MAP_ANONYMOUS
[13:33:45] <merbzt> include sys/mem.h or something
[13:33:52] <merbzt> grep for it in the includes
[13:33:52] <kierank> doesn't exist
[13:34:02] <kierank> looks like they removed it
[13:34:51] <merbzt> #include <sys/mman.h> ?
[13:35:01] <mru> it's not a standard thing anyway
[13:35:10] <kierank> it's not in sys/mman.h
[13:35:13] <twnqx`> try MAP_ANON only?
[13:35:14] <merbzt> :/
[13:35:29] <kierank> let's see what happens if I define it manually
[13:35:29] <twnqx`> wait, that one is deprecated
[13:35:50] <merbzt> didn't work when I tried :/
[13:36:05] <kierank> seems to work
[13:36:13] <kierank> the sections are mapped correctly too
[13:36:20] <merbzt> sure ?
[13:36:21] <twnqx`> which would mean...
[13:36:22] <merbzt> ok cool
[13:36:33] <twnqx`> it's behind #ifdef __USE_MISC
[13:37:02] <twnqx`> (bits/mmap.h, included my sys/mmap.h)
[13:37:02] <merbzt> yeah that was the solution
[13:38:36] <twnqx`> #if defined _BSD_SOURCE || defined _SVID_SOURCE
[13:38:36] <twnqx`> # define __USE_MISC     1
[13:38:36] <twnqx`> #endif
[13:39:30] <kierank> where are you quoting from?
[13:39:34] <twnqx`> features.h
[13:40:07] <twnqx`> _GNU_SOURCE also activates it, gcc -ansi seems to (by default) deactivate those features
[13:40:26] <twnqx`> the documentation at the beginning of that file seems pretty extensive
[13:40:59] <kierank> ah yes it explains all
[14:19:40] <BBB> http://newteevee.com/2010/04/12/google-to-open-source-vp8-for-html5-video/ <- that makes no sense, where's the ffmpeg decoder implementation?
[14:20:18] <mru> right there with the rest of the vapour
[14:20:55] <BBB> I suppose so... :)
[14:20:58] <dgt84> bah let's at least wait for something more than a rumor to spread this stuff around... that article has no sources and is horribly written
[14:21:19] <BBB> I hear the same thing from my sources...
[14:21:42] <dgt84> That they are going to "open source VP8"? that doesn't even make sense...
[14:21:54] * BBB loves how NYTimes always quotes sources as "... who preferred to remain anonymous for fear of their lives ..." or something similar
[14:22:20] <dgt84> We need an irrevocable, royalty-free patent license with proper specs for VP8 to really even be useful
[14:22:28] <BBB> opensource is a misnomer, but the expectation is that they will freely release it under royalty-free terms
[14:23:02] <av500> BBB: yes, ppl mix that up a lot today
[14:23:13] <BBB> anyway... it's interesting, that's all I wanted to say
[14:23:29] <mru> BBB: I doubt those spreading the rumours are even capable of expecting the right thing
[14:23:42] <dgt84> Yeah, I agree (I read the story last night) and am hopeful, but until we get some concrete evidence this is happening I wouldn't get my hopes up too much
[14:24:26] <BBB> mru: who is spreading which rumour?
[14:24:33] <mru> freetards
[14:24:36] <mru> vp8 rumours
[14:24:37] <BBB> oh... right
[14:24:46] <BBB> I thought you had something against specific sources
[14:24:55] <BBB> but yeah, freetards say the same and they are problematic noise here
[14:25:02] <BBB> unfortunate...
[14:25:02] <dgt84> Even if they do the above then there is still the huge hurdle of getting people to use it over H.264, which has a damn good open source encoder, hardware decoders in everything nowadays, etc
[14:25:30] <BBB> dgt84: well, I suppose android would support it
[14:25:37] <BBB> that's a whole load of phones in the US
[14:25:48] <mru> android multimedia support isn't even a joke
[14:25:49] <av500> they all do h264 too
[14:25:57] <av500> BBB: ^^^^
[14:26:02] <BBB> yeah
[14:26:04] <BBB> I know
[14:26:06] <BBB> and they should
[14:28:45] <superdump> ___gb___: ping?
[14:28:48] <BBB> does mplayer wrap the qcelp encoder dll/quicktimething?
[14:28:55] <BBB> any mplayer user/dev know that?
[14:29:13] <merbzt> BBB: no only decoder api
[14:29:22] <BBB> damnit
[14:29:25] <merbzt> soundconvert() something
[14:30:01] <BBB> maybe I should buy quicktimepro
[14:30:05] <CIA-81> ffmpeg: mru * r22873 /trunk/tests/ref/fate/vqf-demux: FATE: update vqf-demux checksum
[14:30:20] <superdump> BBB: maybe android would support it, but the underlying hardware DSPs...
[14:30:22] <jai> BBB: did you ask Compn
[14:30:36] <BBB> jai: no, is he involved in that?
[14:30:45] <merbzt> BBB: http://www.qctconnect.com/products/purevoice_downloads.html
[14:30:54] <jai> BBB: he might have access to qtpro
[14:30:54] <BBB> superdump: that's what david schleef would do ;)
[14:30:59] <BBB> jai: aha
[14:31:01] <BBB> Compn: ping
[14:31:35] <merbzt> BBB: you might need to write a demuxer for it
[14:31:43] <BBB> lol: "Qualcomm: v2.0 for Mac OS 7.x - 9.x**" "**NOTE: Support for newer Mac operating systems is not planned."
[14:32:11] <merbzt> BBB: is that good enough ?
[14:32:23] <BBB> should work, I'll try it in wine
[14:32:38] <merbzt> ahh, no linux :/
[14:33:19] <merbzt> install a virtual machine
[14:33:26] <merbzt> linux is useful some times
[14:33:43] <scaphilo> very often
[14:33:45] <BBB> I need a new mac, not enough HD space
[14:33:56] <merbzt> oh hello merbanan, nice to see you here
[14:34:27] * kshishkov detects a bit of schizophrenia on merbzt
[14:34:47] <BBB> yeah, or my sarcasmeter isn't functioning
[14:35:28] <BBB> merbzt: thanks for the link ;)
[14:35:43] <merbzt> sugerdady got what you need
[14:36:32] <BBB> uhm... ... ... ...
[14:36:35] * BBB decides not to reply
[14:37:08] <merbzt> but you jsut did
[14:37:26] <merbzt> we need to massage the SoC apps also
[14:37:45] <BBB> should I mark the jmf one as ineligible?
[14:37:48] <BBB> it's really crappy
[14:38:00] <merbzt> and decide what project we should run
[14:38:07] <av500> BBB: swap yourself in as "student"
[14:38:09] <merbzt> yeah I think so
[14:38:31] <merbzt> he clearly doesn't even know what we want to do
[14:38:55] <BBB> ok, I removed it
[14:39:24] <BBB> ok, so we have 9 students, 10 proposals now
[14:39:40] <BBB> and only 3 finished qualification tasks
[14:39:57] <merbzt> have you contacted all ?
[14:39:59] <kshishkov> that's better than gsoc 2006 ;)
[14:40:16] <superdump> i told marcelo he had until the 19th at the latest to finish his qualification task
[14:40:32] <BBB> superdump: are you interacting with him?
[14:40:40] <BBB> it'd be better if we had daily interaction with the students
[14:41:08] <kshishkov> at least we haven't heard from the guy who wanted to do vc-1, less mentor work for me
[14:41:11] <superdump> it would be, yes
[14:41:21] <superdump> but i'm not currently
[14:43:02] <merbzt> BBB: anyway, I think we should respond that they should sign up on the soc list and do the qualification task so we can find a suitable soc project for them
[14:43:26] <merbzt> but now, evening snack
[14:43:55] * kshishkov remembers svensk mat and sighs
[15:05:32] <Compn> whurt?
[15:05:45] <merbzt> need brains ...
[15:05:48] <merbzt> er samples
[15:05:50] <kshishkov> nuthin'
[15:07:10] <Compn> BBB : its easier to register qt to qtpro for educational purposes...
[15:07:38] <Compn> mencoder does not support encoding qtaudio for some reason
[15:07:45] <Compn> mencoder does have -ovc qtvideo
[15:07:53] <Compn> i wonder how hard it would be to hack up -oac qtaudio
[15:08:44] <BBB> it's ok
[15:08:50] <BBB> I downloaded the purevoice encoder and it appears to work
[15:08:56] <BBB> now to get ffmpeg to read these files
[15:09:00] <BBB> doesn't appear to be as easy ;)
[15:09:55] <kshishkov> encode silence and find out frame formatting from that
[15:10:13] <BBB> it's RIFF, but not wave
[15:10:16] <BBB> we have a demuxer
[15:10:19] <BBB> but it doesn't appear to work
[15:11:25] <rtconner> anyone have any examples of taking a stream of data from a camera and making it into video?
[15:12:22] * BBB thinks it's the reference decoder messing up
[15:12:24] <BBB> let's try again
[15:14:34] <kierank> rtconner --> #ffmpeg
[15:16:03] <BBB> jai: could you please send a proposal to ffmpeg-devel@ about your project? I think it'd be interesting and we'd want it discussed before soc
[15:19:14] <kshishkov> BTW, does anyone remember anything about releasing FFmpeg 0.6 ?
[15:21:04] <BBB> diego
[15:21:06] <BBB> ah, now it works
[15:21:12] <BBB> too bad the reference decoder won't work in my tess
[15:21:14] <BBB> ohwell
[15:21:32] <BBB> </lazy>
[15:24:36] <ohsix> astrange: there?
[15:40:12] <BBB> anyone here have time for a listening test (see my email to ffmpeg-devel@) in smaller form?
[15:40:16] <BBB> it's only 3 small wav files
[15:58:12] <dgt84_> BBB, that's a tough test... 2 and 3 sound better than 1 to me
[16:02:16] <kierank> http://www.editshare.com/index.php?option=com_wrapper&Itemid=208
[16:04:09] <kshishkov> anything useful for FFmpeg?
[16:05:25] <kierank> probably some RED things and maybe some loose ends with dpx if there are any
[16:06:04] <kshishkov> no dolby-e mastering ;)
[16:06:25] <kierank> that app's for movies, dolby e is for tv broadcasts
[16:08:33] <kshishkov> too bad they don't have formats from the biggest rival
[16:09:00] <kierank> rival to whom?
[16:09:34] <kshishkov> in movie editing field
[16:09:44] <BBB> dgt84_: please email the list, any reason you think 1 is worse?
[16:10:11] <BBB> dgt84_: and did you also compare it with the qualcomm-output.wav?
[16:10:47] <kierank> kshishkov: dpx, exr and what else?
[16:11:29] <kshishkov> kierank: mov
[16:12:34] <kierank> I presume you are talking about the fruit-based codecs
[16:12:45] <kshishkov> of course
[16:13:07] <kshishkov> prores and AIC are often requested to support
[16:16:07] <dgt84_> BBB, emailed, and yeah the qualcomm output sounds like 2 and 3 to me
[16:21:36] <BBB> dgt84_: thanks
[17:01:31] <merbanan> um ? what is the name of our foundation and website ?
[17:01:57] <kshishkov> ffmtech.org?
[17:02:50] <kshishkov> yes, looks like our website :)
[17:03:04] <av500> not much of a website :)
[17:05:04] <jai> BBB: okay, i'
[17:05:07] <jai> err
[17:05:22] <jai> BBB: okay, i'll come with some text and send a mail
[17:05:54] <BBB> thanks
[17:06:17] <BBB> yes, I'm waiting for koth to install a CMS but he's busy or something
[17:06:48] <dgt84_> also seems to be quite a few releases behind for the web server (latest is lighty 1.4.26 afaik)
[17:07:07] <mru> why do we need a cms?
[17:07:13] <jai> cms? isnt that overkill :)
[17:07:23] <av500> isnt that en vogue?
[17:07:25] <kshishkov> because somebody is too lazy to commit to svn with pages
[17:07:28] <mru> whoever makes the website can run whatever he wants locally and export flat html
[17:08:53] <kshishkov> M$ Frontpage?
[17:09:09] <mru> he wouldn't want that
[17:09:13] <jai> Dreamweaver? with html5 support ;)
[17:09:14] <av500> Netscape Navigator Composer?
[17:10:15] <mru> 3.04 gold ftw
[17:10:23] <av500> yup
[17:10:44] <av500> ok, we settled that then :)
[17:12:36] <jai> and here you go http://sillydog.org/narchive/full123.php
[17:12:38] <jai> av500: ^
[17:14:21] <av500> "...With audio and video support, providing users with an integrated solution that extended the multimedia and communications capabilities of their desktops...."
[17:14:30] <av500> sounds like a winner to me
[17:15:41] <merbanan> you only need 6mb to run it also
[17:16:04] <jai> do the linux binaries even work?
[17:16:56] <merbanan> no :/ or they shouldn't
[17:17:07] <merbanan> libc issues should occur
[17:17:09] <av500> jai: I doubt it
[17:17:16] <av500> but I trust the win ones will
[17:17:26] <mru> the links are dead
[17:17:34] <av500> good riddance
[17:17:34] <merbanan> the vqf sdk didn't work
[17:17:50] <mru> I have some old netscape on an irix machine...
[17:17:51] <merbanan> though it was old c++ code
[17:18:32] <jai> yeah, thought as much
[17:30:52] <rtconner> kshishkov is there an irc for using the avcodec api? #ffmep seems to be just for using it command line
[17:31:06] <rtconner> #ffmpeg
[17:33:26] <kshishkov> personally I don't know
[17:34:03] <rtconner> (i thought that was this room :blush:)
[17:34:11] * mru thought #ffmpeg was for converting stuff to flv
[17:34:40] <relaxed> rtconner: maybe https://lists.mplayerhq.hu/mailman/listinfo/libav-user/
[18:15:05] <Kovensky> I remember this "Kurso de Esperanto" program, some abandoned freeware program
[18:15:09] <Kovensky> it has windows and linux builds
[18:15:18] <Kovensky> the latest linux build IIRC is for debian woody
[18:16:44] <elenril> Yuvi: where do matroska specs say that tags must be uppercase?
[18:22:00] <Kovensky> o_O
[18:22:13] <Kovensky> I remember reading a bit of matroska specs and I don't remember that detail
[18:22:19] <Kovensky> if anything they'd be CamelCase ._.
[18:23:14] <elenril> no, the "official" tags are uppercase
[18:23:27] <elenril> but nothing says that this applies to all tags
[18:26:07] <jai> elenril: "The TagName should always be written in all capital letters and contain no space."
[18:26:54] <elenril> oh, thanks
[18:27:01] * elenril was searching for uppercase
[18:27:22] <Kovensky> meh
[18:27:23] <elenril> except it's retarded
[18:27:25] * Kovensky needs to read more
[18:27:29] <Kovensky> elenril: indeed
[18:27:46] <elenril> what does uppercase mean for the moon language?
[18:27:58] <elenril> or are keys limited to latin1?
[18:28:05] <Kovensky> writing in all katakana? =p
[18:28:14] <Kovensky> but I don't think tag names are in moon
[18:28:15] <mru> afaik only latin and cyrillic have upper/lower case
[18:28:28] <kshishkov> georgian too
[18:28:37] <mru> what does that look like?
[18:28:37] <kshishkov> greek
[18:28:42] <mru> ah, greek of course
[18:28:45] <mru> how could I forget that
[18:29:16] <mru> the point remains, most scripts don't have it
[18:29:41] * BBB kicks stupid IRC client
[18:29:53] <elenril> use irssi =p
[18:31:05] <Kovensky> Colloquy... never heard about that ._.
[18:31:10] <kshishkov> mru: I don't think Matroska creators cared about other languages
[18:31:17] <mru> Kovensky: iphone irc client
[18:31:19] <kshishkov> Kovensky: it's for MacOSX
[18:31:28] <kshishkov> desktop too
[18:31:40] <Kovensky> kshishkov: I think they did, since all text in it is (afaik) utf-8
[18:31:43] <elenril> kshishkov: more like they forgot to use that thing in their heads
[18:31:47] <mru> there were a lot of things matroska creators didn't care about
[18:31:54] <Kovensky> maybe "all capital letters" can be ignored for scripts that don't have capital letters? =p
[18:32:17] <kshishkov> elenril: eyes or brain?
[18:32:30] <kshishkov> of course it can
[18:32:37] <elenril> Kovensky: or maybe we can check what haali's splitter does ;)
[18:32:59] <Kovensky> elenril: you're willing to reverse engineer Haali code? =p
[18:33:12] <Kovensky> well, can't be worse than gabest code
[18:33:18] <jai> contrive a sample and see what haali's code does
[18:33:38] <elenril> or i could apt-get source mkvmerge
[18:33:45] <jai> ..or that
[18:33:46] <Kovensky> that's mosu code =p
[18:33:57] <mru> haali's code is not pretty, but I've seen worse
[18:34:04] <jai> mlvtoolnix is quite readable
[18:34:06] <Kovensky> (also, mkvmerge's tag handling was p. bad last time I checked)
[18:34:16] <jai> haali releases code?
[18:34:28] <Kovensky> jai: his matroska parser, used in ffms2
[18:34:40] <jai> hmm
[18:35:07] <Kovensky> <@mru> haali's code is not pretty, but I've seen worse <-- where, tdwtf? :>
[18:35:37] <kshishkov> Kovensky: almost any enterprise code is extremely ugly
[18:36:32] <Kovensky> tdwtf then ._.
[18:36:44] <Kovensky> at least almost everything that ends up there is enterprise code =p
[18:37:20] <kshishkov> enterprise = written in big corporations (usually by Indians/Chinese/Hungarians)
[18:37:46] <Kovensky> lol hungary
[18:38:04] <Kovensky> why have I never heard about anything from hungary other than hungarian notation and Dalriada
[18:38:18] <Kovensky> oh, and gabest
[18:38:20] <kierank> and hippos
[18:38:22] <kshishkov> and the first thing was invented by M$ programmer!
[18:38:22] <jai> and the hungarian demoscene groups
[18:38:58] <Kovensky> there are hippos in hungary? o_O
[18:39:02] <kshishkov> and MPlayer creator
[18:39:07] <Kovensky> oh, arpi
[18:43:02] <thresh> lol @ ubuntu, apache, java: https://blogs.apache.org/infra/entry/apache_org_04_09_2010
[18:45:37] <Kovensky> "This specific URL redirected back to the Apache instance of JIRA, at a special URL containing a cross site scripting (XSS) attack. The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administators clicked on the link. This compromised their sessions, including their JIRA administrator rights." <-- lrn2noscript :P
[18:47:05] <kshishkov> long live Bobby Tables too!
[18:47:17] <Kovensky> :3
[18:49:38] <elenril> hmm, mkvmerge happily muxes tags in japanese
[18:50:27] <jai> do those work with lavf?
[18:50:32] <kshishkov> try lowercase
[18:50:52] <elenril> jai: ofc
[18:50:54] <jai> k
[18:51:47] <Kovensky> <+elenril> hmm, mkvmerge happily muxes tags in japanese <-- as in tags with japanese values or japanese names
[18:52:06] <dgt84_> Anyone know how a libavfilter filter would work with several reference frames into the future of the current frame? I.E. how can it store X frames, then start outputting data? It's not obvious from the API
[18:52:33] <elenril> Kovensky: both
[18:52:39] <elenril> kshishkov: those remain lowercase
[18:53:22] <kshishkov> fine
[19:10:14] <Yuvi> DonDiego: pong
[20:49:28] <j-b> ramiro ?
[20:49:29] <j-b> libavcodec/adxdec.c:1: warning: -fPIC ignored for target (all code is position independent)
[20:50:27] <drv> is that mingw-w64? i get that too, probably needs some additional configure trickery
[20:50:35] <drv> but it seems to work other than that
[20:50:39] <j-b> drv: yes mingw-w64
[20:53:14] <mru> fix the compiler to shut up that warning
[20:54:05] <BBB> m...
[20:54:10] <BBB> we've been assigned 10 slots
[20:54:13] <BBB> but we only have 9 students
[20:54:18] <BBB> that's a little problematic
[20:54:27] <_av500_> BBB: beagle will gladly take one
[20:54:45] <saintdev> auction one off :P
[20:55:41] <_av500_> BBB: i guess you would love a BB :)
[20:58:06] <mru> to play BBB on
[20:58:28] <_av500_> BBB playing BBB on BB
[20:58:34] <Dark_Shikari> But can you play the BBB blu-ray we're about to release?
[20:59:12] <mru> maybe with the beagle xm we're about to release
[20:59:17] <mru> no, doubtful
[20:59:23] <mru> but the next one will play it
[20:59:53] <peloverde> how is vlc/x264 doing?
[20:59:56] <peloverde> do they need extra?
[21:00:00] <Dark_Shikari> we got 15
[21:00:06] <Dark_Shikari> Probably more than we need.
[21:00:14] <Dark_Shikari> 48 apps, 15 slots
[21:00:15] <mru> is it allowed to trade slots?
[21:00:18] <Dark_Shikari> Yes iirc
[21:06:45] <j-b> we will give slots back
[21:32:47] <peloverde> It's a shame, perhaps next year we need to find a way to market ourselves better
[21:34:43] <_av500_> next year, there will be so many VP8 related projects :)
[21:39:54] <Dark_Shikari> lol right =p
[21:41:47] * mru cynically suspects the number of successful projects will be roughly the same this year as in previous years
[21:42:02] <mru> roughly = 0.5
[21:42:11] <DonDiego> Yuvi: ping timeout
[21:43:03] <DonDiego> BBB: the application deadline has passed, so it's not possible to generate some new students out of thin air?
[21:43:10] <DonDiego> Yuvi: ping timeout
[21:43:12] <BBB> no, unfortunately
[21:43:16] <BBB> that'd be a good idea
[21:43:28] <saintdev> DonDiego: you must be having routing issues to Yuvi
[21:43:53] <BBB> we tried to market but I don't think it made much of a difference
[21:43:54] <BBB> ...
[21:43:55] <BBB> :-/
[21:43:55] <DonDiego> Yuvi: around? awake?
[21:44:34] <DonDiego> i don't think past years were too good a marketing
[21:44:50] <DonDiego> but i'll shut up before i get misquoted out of context again
[21:45:12] * DonDiego has a mail drafted to the soc-mentors list somewhere..
[21:50:25] <DonDiego> can somebody confirm that my h.264 patch is safe to commit?
[21:50:44] <mru> should be
[21:50:53] <DonDiego> moving the static function fill_filter_caches() from h264.h to h264.c..
[21:51:03] <mru> the only change was a reversed comparison and conditional jump
[21:51:11] <mru> why it did that mystifies me
[21:51:20] <mru> but it shouldn't matter
[21:51:47] <DonDiego> what are those instructions?
[21:51:59] <DonDiego> cmpl, ja, jb
[21:54:02] <drv> ja is jump if above, jb below (both unsigned)
[21:54:34] <drv> and cmpl is just comparison
[21:55:38] <Yuvi> DonDiego: back
[21:55:50] <DonDiego> ok, then it's identical, just reversed
[21:55:59] <DonDiego> gcc was rolling the dice..
[21:56:07] <DonDiego> i'll commit
[21:56:08] <hyc> heh
[21:56:25] <hyc> hey DonDiego, while you're here - how about committing my librtmp logging patch?
[21:56:33] <drv> more like a magic 8 ball, sometimes you just get "try again later" ;)
[21:56:35] <hyc> I doubt anyone else on the mailing list cares
[21:56:49] <DonDiego> hyc: ffmpeg? mplayer?
[21:56:56] <hyc> ffmpeg
[21:57:00] <hyc> lemme dig up the post
[21:57:28] <hyc> https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086629.html
[21:57:31] <DonDiego> geez, did we run out of patch monkeys already?
[21:57:51] <hyc> nobody has replied, I could ping the list again if that's better
[21:57:53] <DonDiego> more than 20 lazy-ass ops around here..
[21:58:06] <DonDiego> hyc: btw, are you identified?
[21:58:17] <hyc> but it's obviously code that only I care about
[21:58:21] <hyc> eh? identified?
[21:58:29] <mru> I'm not lazy, I just don't care :-)
[21:58:56] <DonDiego> hyc: identified to nickserv
[21:59:02] <hyc> should be
[22:04:31] <DonDiego> hyc: you're the author of that file, right?
[22:06:17] <hyc> Diego: right
[22:06:47] <DonDiego> i'll commit it in a moment if you suggest a good commit message
[22:08:54] <hyc> umm. "Plug librtmp logging into av_log." ?
[22:09:42] <CIA-81> ffmpeg: diego * r22874 /trunk/libavformat/librtmp.c: whitespace cosmetics
[22:10:07] <DonDiego> hyc: nit: space after switch
[22:10:12] <hyc> ok
[22:10:38] <DonDiego> next nit: place system headers before local ones
[22:11:53] <hyc> so: switch (level) {
[22:12:14] <CIA-81> ffmpeg: diego * r22875 /trunk/libavformat/librtmp.c:
[22:12:14] <CIA-81> ffmpeg: Plug librtmp logging into av_log.
[22:12:14] <CIA-81> ffmpeg: patch by Howard Chu, hyc highlandsun com
[22:12:18] <DonDiego> yes
[22:13:58] <hyc> Thanks for that
[22:15:37] <BBB> switch(level) { is also ok right?
[22:15:54] <DonDiego> nope
[22:15:58] <hyc> that's what it was
[22:16:05] <BBB> oh
[22:16:08] <DonDiego> K&R says: space after keyword
[22:16:19] <DonDiego> between keyword and '('
[22:16:24] <BBB> function_call(x, y, z); has no space?
[22:16:29] <DonDiego> yes
[22:16:32] <drv> that's not a keyword :)
[22:16:43] <CIA-81> ffmpeg: diego * r22876 /trunk/libavcodec/ (h264.c h264.h):
[22:16:43] <CIA-81> ffmpeg: Move static function fill_filter_caches() from h264.h to h264.c.
[22:16:44] <CIA-81> ffmpeg: The function is only used within that file, so it makes sense to place
[22:16:44] <CIA-81> ffmpeg: it ther. This fixes many warnings of the type:
[22:16:44] <CIA-81> ffmpeg: h264.h:1170: warning: ?fill_filter_caches? defined but not used
[22:16:54] <DonDiego> this fixes at least a dozen warnings
[22:17:15] <DonDiego> hyc: anything else i can do for you? :)
[22:17:23] <drv> i wish gcc wouldn't try to use those silly fancy quotes
[22:18:18] <mru> what locale have you set?
[22:18:39] <drv> utf8 something, i guess
[22:18:43] * DonDiego waits in vain for the cheers
[22:18:45] <hyc> DonDiego: that's plenty for now, thanks. just waiting for Michael to make a decision on https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086805.html
[22:20:07] <hyc> he already gave the OK for the main patch https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086785.html
[22:20:18] <hyc> but it's still broken until the error code discrepancy is fixed
[22:20:55] <DonDiego> i think we can quickly move you through the ranks and make you a committer if you are interested in staying around for the long haul
[22:21:36] <DonDiego> you're a pretty senior dev already..
[22:21:47] <hyc> that's hard to say. I would not have expected to, but in fact I find I've had local SVNs since 2007 so apparently I have long term itnerest and just didn't know it :P
[22:21:49] <BBB> DonDiego: can you apply http://archives.free.net.ph/message/20100406.133102.59b83dec.el.html?
[22:22:14] <BBB> or http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/107400, same
[22:22:20] <BBB> actually, maybe I should do it
[22:22:24] <Kovensky> <@drv> i wish gcc wouldn't try to use those silly fancy quotes <@mru> what locale have you set? <@drv> utf8 something, i guess <-- it'd use `these retarded quotes instead'
[22:22:26] <BBB> I think ramiro wanted me to change something
[22:22:39] <Kovensky> (if you were in a latin-1 locale, that is)
[22:22:46] <drv> yeah, `' quotes are almost worst
[22:22:57] <drv> but at least they don't get mangled by utf-8 unaware software
[22:22:58] <mru> better than the utf8 ones
[22:24:17] <Kovensky> move gcc to "real-gcc", make gcc do $(real-gcc "$@" | perl -pe"s/'\`/\"/g")
[22:24:28] <hyc> ugh
[22:24:39] <hyc> weren't we just talking about how much inserting perl slows down the compile?
[22:24:40] <Kovensky> it gets rid of the silly quotes :P
[22:24:47] <hyc> no wait, that was #mplayerdev
[22:24:48] <Kovensky> add the UTF-8 ones to the s/// list~
[22:24:54] <Kovensky> hyc: o rly
[22:25:03] <mru> tr is probably faster than perl
[22:25:09] <hyc> yep
[22:25:11] <Kovensky> mru: true, but you'd need multiple trs
[22:25:14] <mru> no
[22:25:21] <Kovensky> tr can do multiple replaces?
[22:25:26] <mru> of course
[22:25:31] <hyc> yes list1 -> list2
[22:25:59] <Kovensky> oic
[22:26:00] <hyc> it's a poor man's clone of the IBM 360 TRT instruction
[22:26:08] <mru> in this case, simply put multiple ' in the second list
[22:26:28] <DonDiego> BBB: why should i apply some ff_neterrno patch that you sent?
[22:26:46] <BBB> I'm lazy and have no time
[22:27:00] <BBB> but it's ok I'll do it
[22:27:05] <BBB> but it'll have to wait for another day or so :(
[22:41:53] <DonDiego> Yuvi: re: ogg and theora - what's the status?
[22:42:12] <saintdev> peloverde: ping
[22:42:19] <peloverde> pong
[22:42:37] <saintdev> i don't have my logs, but why were you saying not to use psnr for audio?
[22:42:52] <saintdev> s/i don't have/it's not in/
[22:44:03] <peloverde> not using psnr for audio to do what?
[22:44:39] <peloverde> judge an encoder? verify a decoder?
[22:44:49] <saintdev> judge an encoder
[22:45:17] <peloverde> because the psymodel completely fucks PSNR
[22:45:21] <saintdev> i know why psnr in general is a bad idea, but there was something specific to audio you stated that made it extra bad
[22:45:40] <saintdev> well yeah, psy will do that :P
[22:45:54] <saintdev> is it just that audio encoders use more psyopts than video encoders generally?
[22:46:46] <peloverde> you wouldn't want to run an audio encoder with a psymodel off except for testing purposes or at extremely high bitrates
[22:47:12] <peloverde> there are other metrics that take the psymodel into account that can be used to numerically estimate quality
[22:47:16] <peloverde> like NMR
[22:47:18] <Kovensky> IIRC the only reason vorbis is better than the other current encoders is because of better psy optimization
[22:47:34] <Kovensky> (I'm not sure if it's better than neroaac, but last time I checked it was better than everything)
[22:47:43] <Kovensky> vorbis as in aotuv's libvorbis
[22:49:02] <peloverde> At SBR bitrates it doens't hold up to nero
[22:49:24] <peloverde> At mid and high bitrates last I saw they are tied
[22:51:35] <DonDiego> peloverde: btw, aacsbr.c spits out a lot of warnings..
[22:51:51] <peloverde> DonDiego, see the discussion during patch review
[22:52:08] <peloverde> It's the multilevel array const cast issue
[22:53:02] <CIA-81> ffmpeg: diego * r22877 /trunk/libavcodec/error_resilience.c: Add rectangle.h #include for fill_rectangle().
[23:06:59] <DonDiego> Yuvi: ping
[23:07:11] <DonDiego> geez, we have a knack for missing each other on irc..
[23:20:16] <iive> peloverde: should i understand the above as a sign that the aac encoder is progressing well?
[23:20:51] <iive> and that maybe after it is complete the ff vorbis enc may get magically a lot better than now.
[23:21:03] <peloverde> Not really, I'm still finishing PS
[23:23:11] <CIA-81> ffmpeg: stefano * r22878 /trunk/libavfilter/avfiltergraph.c:
[23:23:11] <CIA-81> ffmpeg: Make avfilter_graph_add_filter() returns AVERROR(ENOMEM) in case of
[23:23:11] <CIA-81> ffmpeg: failed reallocation, rather than just -1.
[23:25:15] <CIA-81> ffmpeg: stefano * r22879 /trunk/libavcodec/utils.c: Factorize code in get_bit_rate().
[23:28:51] <DonDiego> ok, i'm off to bed..
[23:42:39] <CIA-81> ffmpeg: stefano * r22880 /trunk/ffprobe.c:
[23:42:39] <CIA-81> ffmpeg: Fix computation of the display aspect ratio.
[23:42:39] <CIA-81> ffmpeg: Previously ffprobe was wrongly outputting the sample aspect ratio as
[23:42:39] <CIA-81> ffmpeg: display aspect ratio.
[23:42:39] <CIA-81> ffmpeg: Patch by Robert Kr?ger $(echo k-r-u-e-g-e-r at s-i-g-n-a-l-7.d-e | sed s/-//g).