[FFmpeg-devel-irc] IRC log for 2010-07-16

[irc at mansr.com]

[00:00:01] <Dark_Shikari> oh
[00:00:03] <Dark_Shikari> you forgot top left
[00:00:06] <Dark_Shikari> that's why it breaks.
[00:00:08] <Yuvi> ah!
[00:00:19] <Dark_Shikari> fyi, if you commit that, I have a patch that requires that.
[00:00:27] <Dark_Shikari> so we can get double the fun.
[00:03:34] <Yuvi> how does h264.c save tl?
[00:06:14] <Dark_Shikari> the way x264 does it is that it does the backup per-row
[00:06:32] <Dark_Shikari> i.e. one big memcpy (well, three) at the end of encoding a row
[00:20:51] <Dark_Shikari> Yuvi: got it to work?
[00:25:38] <Yuvi> Dark_Shikari: not quite, think I'm not handling the 129 on the left right
[00:52:27] <pengvado> Dark_Shikari: nv12 patch changed that, it now does backup per mb.
[01:49:06] <Compn> Google Spent $100 Million Defending YouTube Against Viacom
[01:49:07] <Compn> wow
[01:54:33] <saintdev> peloverde: could the bark averaging because of the overlap?
[02:25:37] <Dark_Shikari> pengvado: ah, ok
[02:45:53] <saintdev> actually that doesn't make sense :/
[02:52:33] <Dark_Shikari> Yuvi: http://pastebin.org/398567
[02:52:35] <Dark_Shikari> here's my patch
[02:58:25] <Yuvi> looks good to me once I figure out why border saving isn't working for the simple lf...
[02:58:48] <Dark_Shikari> btw, where's the part where it adapts strength based on whether the block is coded or not?
[02:58:52] <Dark_Shikari> I can't find it
[02:58:57] <Dark_Shikari> also, how often do those ifs trigger in the filter strength function?
[02:59:00] <Dark_Shikari> i.e. which parts are common?
[02:59:06] <Dark_Shikari> also, how much of that can we precalculate?
[02:59:25] <Yuvi> it doesn't adapt based on coded or not, being coded only influences whether the lf is run at all
[02:59:56] <Yuvi> don't have any stats on the if()s other than sharpness is rare
[03:00:20] <Yuvi> and level is generally 10-25 or so
[03:01:21] <Dark_Shikari> but where is the coded thing run?
[03:01:24] <Dark_Shikari> I don't see that check
[03:01:35] <Yuvi> if (!mb->skip ...
[03:01:49] <Yuvi> mb borders are always filtered
[03:02:12] <Dark_Shikari> so we still have to calculate the limit even if it's skipped.
[03:02:13] <Dark_Shikari> ok
[03:02:19] <Dark_Shikari> s->lf_delta.enabled
[03:02:22] <Dark_Shikari> is that usually on?
[03:02:31] <Dark_Shikari> because if it isn't, filter_level is constant frame-wide
[03:02:53] <Yuvi> iirc yes
[03:02:55] <Dark_Shikari> ok
[03:03:03] <Dark_Shikari> if (mb->ref_frame == VP56_FRAME_CURRENT) {
[03:03:05] <Dark_Shikari> seems unnecessary
[03:03:09] <Dark_Shikari> in filter_level_for_mb
[03:03:18] <Dark_Shikari> the ref_frame check period seems unnecessary
[03:03:49] <Dark_Shikari> it seems like we could convert this to
[03:03:54] <Yuvi> hm
[03:03:59] <Dark_Shikari> filter_level = array[segment][ref][mode]
[03:04:11] <Dark_Shikari> ane eliminate all the logic above "interior_limit = filter_level"
[03:04:23] <Dark_Shikari> similarly, hev_thresh can be made into a lut
[03:04:30] <Dark_Shikari> a quantized lut of some sort
[03:07:08] <Yuvi> a [4][2][9] array sounds reasonable
[03:11:03] <Yuvi> I know libvpx has at least a 63*16 table for filter level, can't remember exactly what they do
[03:19:07] <saintdev> peloverde: ping
[03:30:28] * Yuvi stabs the 127/129 non-pixels in vp8
[04:14:54] <Yuvi> Dark_Shikari: http://pastie.org/1046739
[04:14:55] <Yuvi> I kept the 3 memcpy since removing them meant more code per-mb
[04:19:46] <Yuvi> I think I'll try to implement edge emu now, maybe really get rid of them
[06:10:31] <astrange> if you're going to use int simple... try av_always_inline instead of inline
[06:38:15] <av500> m0rn1ng
[06:40:34] <mru> moroning
[06:45:55] <Dark_Shikari> Yuvi: if it works, feel free to commit really
[07:17:55] <KotH> moin
[07:18:25] <kshishkov> gruess dich
[07:20:53] <Yuvi> added av_always_inline, got rid of those 3 memset, and committed
[07:21:22] <CIA-99> ffmpeg: conrad * r24251 /trunk/libavcodec/vp8.c: vp8: Check for malloc failure
[07:21:23] <CIA-99> ffmpeg: conrad * r24252 /trunk/libavcodec/vp8.c:
[07:21:23] <CIA-99> ffmpeg: vp8: Save mb border needed for intra prediction so that loop filter can run
[07:21:23] <CIA-99> ffmpeg: immediately after a mb row is decoded
[07:21:43] <Dark_Shikari> Yuvi: want to merge my changes as well?
[07:22:21] <Yuvi> sure
[07:22:31] <Yuvi> paste it again? lost my scrollback
[07:26:09] <Dark_Shikari> 10:52 <@Dark_Shikari> Yuvi: http://pastebin.org/398567
[07:26:09] <Dark_Shikari> 10:52 <@Dark_Shikari> here's my patch
[07:26:14] <Dark_Shikari> 11:03 <@Dark_Shikari> if (mb->ref_frame == VP56_FRAME_CURRENT) {
[07:26:14] <Dark_Shikari> 11:03 <@Dark_Shikari> seems unnecessary
[07:26:22] <Dark_Shikari> 11:03 <@Dark_Shikari> it seems like we could convert this to
[07:26:22] <Dark_Shikari> 11:03 <@Yuvi> hm
[07:26:22] <Dark_Shikari> 11:03 <@Dark_Shikari> filter_level = array[segment][ref][mode]
[07:26:22] <Dark_Shikari> 11:04 <@Dark_Shikari> ane eliminate all the logic above "interior_limit = filter_level"
[07:26:28] <Dark_Shikari> there's the relevant info
[07:42:23] <Dark_Shikari> Yuvi: btw, does this mean we can dump the !emulated_edge requirement?
[07:42:34] <Yuvi> not yet, working on that too
[07:43:13] <Dark_Shikari> imo should feel free to commit whatever you want to vp8.c that doesn't break it, at this point we're the only maintainers so we don't really need ML discussion for most stuff
[07:44:06] <mru> Dark_Shikari: but isn't !emu faster?
[07:44:14] <Dark_Shikari> mru: it breaks direct rendering
[07:44:21] <mru> only with stupid apps
[07:44:32] <Dark_Shikari> opengl textures don't allow arbitrary stride
[07:44:40] <mru> so don't use arbitrary stride
[07:44:51] <Dark_Shikari> You can't pad the edges if the stride isn't arbitrary.
[07:44:51] <Yuvi> Dark_Shikari: um, they do
[07:44:52] <mru> pad it up to whatever
[07:45:01] <Dark_Shikari> Yuvi: our opengl guy kept telling us that you can't.
[07:45:13] <mru> surely opengl allows padded lines
[07:45:16] <Dark_Shikari> that calls like ReadPixels only wrote to a buffer, not an arbitrary stride buffer
[07:45:25] <Dark_Shikari> is the opposite of that (write pixels, I guess?) more flexible?
[07:45:27] <Yuvi> I distinctly remember experimenting with weird strides with opengl
[07:45:34] <mru> if it requires more alignment than lavc, that's fine
[07:45:38] <mru> just give it that
[07:45:44] <Dark_Shikari> iirc, it didn't use any alignment at all
[07:45:46] <Dark_Shikari> just the width
[07:45:54] <mru> I can't believe it's that stupid
[07:45:55] <Dark_Shikari> whatever, I'm probablyw rong.
[07:45:55] <Dark_Shikari> Anyways
[07:46:02] <Dark_Shikari> There are two right ways to do it
[07:46:06] <Dark_Shikari> 1) emulate edges, don't pad
[07:46:09] <Dark_Shikari> 2) pad, don't emulate edges
[07:46:13] <Dark_Shikari> currently, we emulate edges AND pad.
[07:46:15] <Dark_Shikari> This is retarded.
[07:46:17] <mru> yeah
[07:49:36] <kshishkov> why emulate edges at all? There's usually not enough of them for MC anyway
[07:50:35] <Yuvi> ah, glTexImage2D does indeed not take a stride, but it's trivial to map the texture to discard excess stride
[07:51:21] <Yuvi> or setting GL_UNPACK_ROW_LENGTH works too
[07:51:47] <Yuvi> Dark_Shikari: so tell your opengl guy to look into GL_UNPACK_ROW_LENGTH
[07:53:23] <Dark_Shikari> does it work for the reverse?
[07:53:31] <Dark_Shikari> _writing_ pixel data to a strided buffer?
[07:53:44] <astrange> http://developer.apple.com/mac/library/samplecode/TextureUpload/Introduction/Intro.html read that if you haven't
[07:53:57] <Dark_Shikari> this is moreso texture download than upload
[07:54:02] <Yuvi> should
[07:54:08] <av500> does it explain the iphone 4 antenna issue?
[07:54:27] <Yuvi> astrange: unfortunately noone but apple implements those extensions
[07:55:22] <wbs> Yuvi: texture_rectangle_ext/arb is quite widely available
[07:55:43] <Yuvi> wbs: I meant texture range and client store
[07:56:00] <wbs> ah, yes, those are a different matter
[07:59:35] <kshishkov> av500: there is an explanation - "you're not cool enough to use it"
[08:00:09] <av500> no, you are holding it wrong!
[08:02:42] <Yuvi> hm, should I be lazy and reuse put_pixels or copy it and use a smaller stride
[08:03:30] <_troll_> no temp buffers with full stride please
[08:03:33] <_troll_> if it can be avoided
[08:04:12] <Dark_Shikari> what do you need put pixels for?
[08:04:40] <Yuvi> Dark_Shikari: for edge emu + intra pred, I'm predicting into a temp buffer then copying to the actual frame
[08:04:58] <Yuvi> for the top/left row only ofc
[08:05:28] <Dark_Shikari> what does h264 do?
[08:05:42] <Yuvi> not predict from pixels outside the frame afaik
[08:06:19] <Yuvi> so it complains about an invalid bitstream and uses some other mode
[08:08:21] <Dark_Shikari> ah yeah, you're right
[08:08:35] <Dark_Shikari> it's ironic that vp8's "simplification" makes it harder and more complicated
[08:09:44] <_troll_> they simplified the spec, not the implementation
[08:09:54] <Yuvi> it's simpler for them
[08:10:04] <Yuvi> they always intra pred to a temp buffer
[08:10:06] <_troll_> which is odd, considering those are one and the same
[08:11:02] <Dark_Shikari> I do agree that eliminating the need to check intra pred modes is a good thing
[08:11:34] <Yuvi> except you still have to check DC on the edge
[08:11:48] <Yuvi> ...but not for 4x4
[08:12:24] <Dark_Shikari> that's retarded
[08:12:36] <Dark_Shikari> well, actually, it makes sense really compression-wise
[08:12:38] <Dark_Shikari> but it kinda goes against the point.
[08:13:22] <Yuvi> I kinda want to know why 127/129 and not just 128
[08:13:45] <Dark_Shikari> to be different from h264
[08:14:37] <Yuvi> h264 only uses that for the first block though, which vp8 winds up doing too if it uses DC (which the encoder does)
[08:16:03] <Yuvi> copy_pixels sounds like a good name for a put_pixels with 2 strides?
[08:17:07] <Dark_Shikari> sounds good
[08:20:59] <_troll_> a lot of things in dsputil should have had 2 strides
[08:21:29] <Dark_Shikari> _troll_: agreed
[08:21:54] <Dark_Shikari> the real problem with ffmpeg dsp functions is that so many things share them
[08:21:58] <Dark_Shikari> I mean, obviously there's no solution
[08:22:07] <Dark_Shikari> but e.g. in x264, if a function would be better with another arg
[08:22:10] <Dark_Shikari> we can just add it and bam
[08:22:35] <_troll_> we can theoretically do that in ffmpeg too
[08:22:41] <_troll_> but it's a huge undertaking
[08:22:51] <_troll_> and will never leave the bikeshed
[08:24:09] <Dark_Shikari> Exactly
[08:24:16] <Dark_Shikari> that's pengvado's main reason for why x264 isn't part of ffmpeg
[08:24:26] <Dark_Shikari> if you share code among 10 different en/decoders, it's harder to change anything
[08:24:36] <Dark_Shikari> changing x264 to use nv12 was hard enough, imagine changing ffmpeg to use nv12.
[08:25:30] <astrange> well changing a decoder would be harder anyway
[08:25:55] <Dark_Shikari> why's that?
[08:25:57] <Dark_Shikari> encoders are more complicated
[08:26:39] <astrange> you're outputting the yv12/nv12 and don't want to convert it or break clients that don't know about the new one
[08:26:50] <kshishkov> Dark_Shikari: please train on ZMBV codec to use NV12
[08:27:17] <Dark_Shikari> astrange: deinterleave it for legacy clients
[08:28:11] <Dark_Shikari> but yeah, trickier
[08:35:53] <pJok> god morgon kshishkov :)
[08:36:39] <av500> kshishkov: your train overview is lacking
[08:38:14] <_troll_> speaking which, the berlin s-bahn runs pretty far from the city
[08:38:23] <_troll_> all the way to spandau as av500 can tell you
[08:38:34] <_troll_> and potsdam
[08:38:35] <av500> well, not at the times when I needed it...
[08:38:56] <av500> but that's what S-Bahns do in general
[08:39:13] <av500> running pretty far
[08:40:07] <_troll_> the stockholm "tunnelbana" also runs rather far, and above ground too
[08:41:53] <pJok> as does the copenhafen metro for quite a long way outside the city center
[08:41:59] <av500> http://www.forgotten-ny.com/SUBWAYS/9thavel/9Ave.html
[08:42:02] <pJok> copenagen*
[08:42:31] <pJok> and the s-train lines all run above ground exceppt for one station
[08:44:07] <_troll_> the stockholm equivalent of s-bahn runs further though
[08:44:21] <_troll_> and now they're building a tunnel for it under the city
[08:44:33] <pJok> yeah, T-banan covvers quite a big area
[08:45:09] <_troll_> and it has the best trains of any underground system I've tried
[08:45:28] <pJok> didn't get to try them when i was actually in stockholm
[08:45:35] <pJok> i do like the metro trains in copenhagen
[08:45:42] <pJok> since they are driverless
[08:45:56] <_troll_> the trains were all replaced starting in the mid 90s
[08:46:26] <_troll_> the best bit is they run almost silently
[08:46:32] <_troll_> you can actually talk inside them
[08:46:39] <_troll_> not shout
[08:46:39] <pJok> the only older trains in the copenhagen area are the regional trains rolling stock from the 60s
[08:47:10] <pJok> X2000 is crap
[08:47:27] <_troll_> I'd say it's pretty good
[08:47:36] <Yuvi> hm, vp8's mc functions take 2 strides
[08:47:37] <pJok> inside tthey look like SJ's old waggons
[08:47:55] <_troll_> I don't mind them
[08:48:03] <Yuvi> there are too many functions that do put_pixels with different arguments already :/
[08:48:07] <_troll_> it's not as fast as tgv perhaps
[08:48:23] <_troll_> though I've never been on the tgv
[08:48:25] <_troll_> only the korean clone
[08:48:27] <pJok> nothing in sweden is as fast as tgv/agv
[08:48:35] <av500> I havte TGV seats
[08:48:37] <av500> hate
[08:48:38] <pJok> its just a s boring as denmark
[08:48:44] <av500> ICE are much better
[08:48:55] <pJok> at least sweden has decided to use 250km+ trains
[08:48:57] <av500> (in 1st class)
[08:49:04] <pJok> denmark says that 180 is more than enough for anyone
[08:49:10] <_troll_> av500: the swedish trains don't melt in hot weather
[08:49:24] <av500> yep
[08:49:29] <pJok> mru, and they don't die from snow... well, a bit
[08:49:38] <_troll_> x2000 usually runs
[08:49:51] <pJok> they ran out of X2000 trains this winteer
[08:49:57] <pJok> that was not fun
[08:49:58] <av500> pJok: http://ahoipolloi.blogger.de/stories/1663338/
[08:50:10] <pJok> since they also ran out of öresundståg
[08:50:48] <pJok> av500, noone likes DB ;)
[08:51:22] <av500> they will be DubaiBahn soon.... good riddacne
[08:51:37] <pJok> i still don't understand why i can buy a tickeet to berlin that costs the same as a ticket home from work
[08:51:51] <_troll_> av500: their website is mostly ok
[08:51:55] <av500> yes
[08:51:58] <av500> well
[08:52:03] <_troll_> it's much better for looking up swedish trains than the swedish website
[08:52:04] <pJok> plane vs train that is
[08:52:28] <av500> _troll_: they revambed it a bit
[08:52:30] <av500> p
[08:52:31] <pJok> mru, SJ's site sucks... DB's site is also better for looking up danish trains
[08:52:34] <_troll_> pJok: because the ICE is the train equivalent of the concorde
[08:52:38] <pJok> or at least, it used to be
[08:52:39] <av500> and the android app is cool
[08:52:52] * kshishkov thinks his post was rather good as an unitented troll
[08:52:58] <av500> we all know what becaome of the concorde...
[08:53:12] <av500> it also had heat issues
[08:53:12] <pJok> #ffmpeg-trains
[08:53:14] <pJok> ;)
[08:53:16] * _troll_ saw one standing at heathrow in june
[08:53:29] <kshishkov> pJok: actually, it was easier to me to use SJ site for buying tickets than DB
[08:53:36] <_troll_> av500: yes, the passengers were full of hot air
[08:53:42] <av500> http://mentalfloss.cachefly.net/wp-content/uploads/2009/03/ACCIDENT.jpg
[08:53:53] <pJok> kshishkov, funny... i
[08:53:56] <av500> AC overload I guess
[08:54:18] <pJok> i'd expect them both to be equally annoying because of all the ways you can select a ticket
[08:55:20] <kshishkov> Db site is just more confusing
[08:55:28] <pJok> kshishkov, i hope never to have to buy my SJ ticket on tradera though...
[08:57:03] <kshishkov> pJok: at least it was rather mildly amusing buying ticket Copenhagen->Stockholm at DB in Munich
[08:57:19] <pJok> were they confused?
[08:57:24] <kshishkov> not at all
[08:58:42] <pJok> at least, if you are two people, its cheaper and faster to take the car from copenhagen to hamburg than the train and still cheaper than the plane
[08:59:08] * kshishkov is rather not fit for cars
[08:59:31] <pJok> even when having to buy a green "umwelt zone" thingie for my car
[09:00:24] * kshishkov still prefers trains unless in Ukraine
[09:00:31] <twnqx> pJok: depends on the gar and your driving habits :P
[09:00:35] <twnqx> car*
[09:00:49] <pJok> i do find it mildly amusing that i could have said pretty much anything to the person i bought that thing from... they didn't even look at the car or the registration papers, only wanted the license plate so they could print a strip to put on it
[09:01:12] <pJok> twnqx, my car does 10l/100km... and 193km/h on the top
[09:01:42] <twnqx> see... my average is 16, and more like 25 @250
[09:01:54] <_troll_> germans...
[09:02:13] <pJok> the 10l/100km is @~150
[09:02:48] <pJok> but it still cheaper than taking the train if you are two people
[09:03:32] <av500> only because you already pay for the car anyway
[09:04:00] <pJok> my car did cost 295eur ;)
[09:04:14] * kshishkov would like Sweden to have Europabanan
[09:04:15] <thresh> .65 EUR for litre of gas here, so it almost always cheaper to travel by car in Russia
[09:04:17] <pJok> insurance on it is more expensive
[09:04:50] <thresh> and 0.5 EUR for litre of diesel fuel...
[09:04:52] * pJok would like all of scandinavia to have europabahn
[09:04:57] <kshishkov> thresh: lack of proper public transport helps
[09:05:42] <thresh> i was quite amazed on the queue lines on RU-EST border. they all went to Russia just to full their tanks..
[09:06:16] <kshishkov> pJok: that sounds German. But proper (i.e. without electricity standard change in some quirky place) railroad from Sweden to the rest of Europe would be good.
[09:06:49] <pJok> kshishkov, it would... but denmark is too stubborn and german can't be arsed
[09:06:56] <pJok> sweden on the other hand...
[09:07:20] <_troll_> the trains seem switch power systems quite ok when going to denmark
[09:07:30] <pJok> mru, it works
[09:07:36] * pJok uses it every day
[09:07:39] <pJok> as does the freight trains
[09:08:34] <kshishkov> especially diesel ones
[09:08:51] <pJok> denmark is still buying diesel trains because they haven't electrified the main lines
[09:09:04] <_troll_> swedish trains are nuclear-powered, right?
[09:09:06] <pJok> and because they are still buying diesel trains, they wont electrify the rest of the main lines
[09:09:13] <pJok> they are
[09:09:37] <kshishkov> catch-22 in action
[09:09:41] <pJok> yeah
[09:09:47] <pJok> it was the same problem 20 years ago
[09:09:54] <av500> not 22ys?
[09:10:00] <pJok> probably
[09:10:29] <_troll_> swedish railways are almost entirely electrified
[09:10:35] <pJok> of course
[09:10:40] <pJok> sweden has nucelar power
[09:10:47] <CIA-99> ffmpeg: vitor * r24253 /trunk/tests/fate2.mak: Add AC3 regtests
[09:10:57] <_troll_> there are few obscure lines without electricity
[09:11:02] <pJok> and their trains have that "bra miljöval" bird logo on them
[09:11:03] <_troll_> inlandsbanan for example
[09:11:44] <pJok> well
[09:11:45] <kshishkov> pJok: Ukraine has world-famous nuclear power, so what?
[09:12:08] <kshishkov> pJok: and locos from Czech and USSR older than you
[09:12:10] <_troll_> kshishkov: you're doing your best to make the trains famous too
[09:12:11] <pJok> kshishkov, but they aren't giving it away... and the russians cut off their gas every time they start to argue over the price
[09:12:39] <kshishkov> _troll_: if you ever see Rc6 model, please buy one for me
[09:13:06] <_troll_> RC6 is a good one
[09:14:00] <pJok> kshishkov, should be available in any swedish model train shop
[09:14:11] <kshishkov> pJok: an address, please
[09:14:17] <_troll_> stockholm
[09:14:28] <kshishkov> more details, please
[09:14:35] <pJok> hehe
[09:14:54] <_troll_> stockholm is a small city
[09:14:58] <_troll_> no need for more detail
[09:14:58] * kshishkov has looked only in Gävle for some reason
[09:15:39] <pJok> Gefle? the only thing happening there is a goat gets burned every year
[09:16:10] <kshishkov> _troll_: well, should I start with Skärholmen and Rinkeby and leave Norrmalm and Gamla Stan till the end?
[09:16:35] <_troll_> africa and the middle east are not in stockholm
[09:16:36] <kshishkov> pJok: http://sv.wikipedia.org/wiki/Sveriges_j%C3%A4rnv%C3%A4gsmuseum
[09:20:09] <pJok> kshishkov, funny enough, i've passed by the one in ängelholm quite a few times, but i've never been there
[09:20:50] <kshishkov> pJok: I'm shocked. Probably you've never visited Danish one as well?
[09:21:01] <pJok> the one in Odense?
[09:21:08] <pJok> negative
[09:21:11] <kshishkov> don't remember where
[09:21:23] <kshishkov> ans isn't Odense known for some pervert?
[09:21:25] <pJok> i have, however visited sporvejsmuseet outside roskilde
[09:21:40] <pJok> yeah, that H.C. Andersen guy with the little mermaid
[09:22:09] * kshishkov is proud to omit seeing it in Copenhagen
[09:24:58] <CIA-99> ffmpeg: vitor * r24254 /trunk/tests/fate2.mak: Add EAC3 regtests
[09:25:07] <pJok> how big is the one in Gävle?
[09:25:15] <pJok> the one in Ängelholm doesn't look very big
[09:25:21] <_troll_> we really need to get mike to run those new tests
[09:25:33] <_troll_> or more realistically, set up a new fate system
[09:25:48] <pJok> mru, go go go
[09:25:56] * pJok goes to find the bikeshed paint
[09:26:10] <_troll_> no need for that
[09:26:23] <_troll_> I do whatever I want with the tests
[09:26:58] <_troll_> at some point, I just started doing stuff without asking, and nobody complained...
[09:27:16] <pJok> people are afraid of you ;)
[09:27:19] <kshishkov> pJok: one standard steam train depot with exposition, another one for repairs and stuff, station house and small  park
[09:27:41] <kshishkov> pJok: nonsense - I'm not afraid of him, even now
[09:28:15] <_troll_> that's only because the shotgun isn't allowed in the office
[09:28:24] <kshishkov> or on planes
[09:28:28] <pJok> hehe
[09:28:42] <_troll_> you have no idea what it's possible to bring on a plane
[09:28:44] <pJok> how far do you actually sit from each other? same office?
[09:29:15] <kshishkov> _troll_: neither does airport security, so they forbid everything
[09:29:31] <kshishkov> pJok: yes, almost in a hand reach
[09:29:44] <_troll_> kshishkov: so don't bring it through security
[09:30:01] <pJok> kshishkov, friend of mine had a bottle of water with him when we went to gran canaria... i don't think they had the machine turned on that day since noone complained about it
[09:30:37] <_troll_> I've had toothpaste etc packed normally many times without anyone saying anything
[09:30:46] <pJok> its stupid
[09:30:51] <_troll_> they found a bottle of water I'd forgotten about once
[09:31:02] * kshishkov remembers the smallest airport he's ever been to - you have to do a lot of security stuff by yourself there
[09:31:03] <pJok> security circus of the policians
[09:31:38] <kshishkov> pJok: it's called "CYA"
[09:31:42] <_troll_> I reckon it's quite easy to sneak something in with some goods delivery
[09:33:39] <kshishkov> guess why Ukrainian airports have such service as packing your baggage into plastic wrapping?
[09:34:13] <pJok> do they pack your lunch as well? ;)
[09:34:52] <_troll_> in soviet russia, the lunch packs you
[09:35:45] <kshishkov> it's done to prevent tampering with your baggage - when I flew to homeland a year ago, my bag went rummaged through
[09:36:00] <av500> _troll_: in soviet russia lunch hunts in packs
[09:36:20] <CIA-99> ffmpeg: vitor * r24255 /trunk/tests/fate2.mak: Add ATRAC1 regtest
[09:36:25] <pJok> at least it means that if your luggage is lost, its lost with a lot of other peoples luggage
[09:37:23] <kshishkov> pJok: yes, had that wonderful experience too. With Danish branch of SAS
[09:38:19] <pJok> fun
[09:38:25] * pJok is waiting for SAS to finally die
[09:38:40] <Honoome> serial attached scsi?
[09:38:54] <pJok> scandinavian airline service
[09:38:56] <kshishkov> Scandinavian Air (dis)Service
[09:39:04] <pJok> or lack there of...
[09:39:10] <av500> I thought SAS makes u die....
[09:39:16] <pJok> thats SARS
[09:39:28] <_troll_> svenskt allt sammen, no?
[09:39:32] <av500> http://en.wikipedia.org/wiki/Special_Air_Service
[09:39:58] <_troll_> yes, that airline is, er..., "special"
[09:40:29] <kshishkov> _troll_: and again, their HQ is in Denmark which is rather suspicious
[09:42:40] <CIA-99> ffmpeg: vitor * r24256 /trunk/tests/fate2.mak: ATRAC3 regtests
[09:59:09] <CIA-99> ffmpeg: vitor * r24257 /trunk/tests/ (ref/fate/gsm fate2.mak): Add MS-GSM regtest
[10:07:29] <CIA-99> ffmpeg: vitor * r24258 /trunk/tests/ (ref/fate/msmpeg4v1 fate2.mak): Add msmpeg4v1 regtest
[10:09:17] <_troll_> Vitor1001: we already test msmpeg4
[10:09:17] <CIA-99> ffmpeg: vitor * r24259 /trunk/configure: Nit: fix alphabetical order
[10:09:31] <Vitor1001> -
[10:09:39] <Vitor1001> _troll_: :p
[10:09:48] <Vitor1001> Where? We encode for it?
[10:09:50] <_troll_> yes
[10:10:31] <Vitor1001> msmpeg4 == msmpeg4v1?
[10:10:36] <_troll_> yes
[10:11:12] <Vitor1001> why do we have redundant identifiers?
[10:11:39] <_troll_> we don't
[10:12:04] <Dark_Shikari> we have always been at war with eurasia
[10:12:08] <Dark_Shikari> also, webm/matroska
[10:12:32] <av500> mkv,webm ftw
[10:12:50] <Dark_Shikari> COMMAS OMG PANIC
[10:13:11] <_troll_> sorry, I thought it would break more than it did
[10:13:28] <_troll_> and had baptiste stayed out of the fray it would have been fine
[10:13:39] <av500> thou art forgiven
[10:13:41] <_troll_> but he never passes up a chance to go up against me
[10:14:48] <Vitor1001> _troll_: According to libavcodec/msmpeg4.c,  msmpeg4 == msmpeg4v3...
[10:14:58] <kshishkov> _troll_: he once played a game of kicking with Dark_Shikari, so he treats you rather nice
[10:15:06] <_troll_> yes, but the msmpeg4 _test_ tests v1
[10:16:01] <Vitor1001> _troll_: Ok, I'll trust you in this one...
[10:16:25] <_troll_> hold on
[10:19:33] <_troll_> there's an inconsistency
[10:19:45] <_troll_> the msmpeg4 test does indeed test v3
[10:19:48] <_troll_> the deps are wrong
[10:19:51] <_troll_> probably my fault
[10:20:11] <CIA-99> ffmpeg: vitor * r24260 /trunk/tests/ (ref/fate/msmpeg4v1 fate2.mak): (log message trimmed)
[10:20:11] <CIA-99> ffmpeg: Revert r24258:
[10:20:11] <CIA-99> ffmpeg: Log:
[10:20:11] <CIA-99> ffmpeg: Add msmpeg4v1 regtest
[10:20:11] <CIA-99> ffmpeg: Added:
[10:20:12] <CIA-99> ffmpeg:  trunk/tests/ref/fate/msmpeg4v1
[10:20:12] <CIA-99> ffmpeg: Modified:
[10:20:23] <_troll_> but it's still better to add an encode/decode test
[10:27:43] <_troll_> hmm, this is ungood
[10:31:00] <_troll_> the encoder seems broken
[10:37:17] <av500> _troll_: wrt msmpeg4, I found it annoying that its CODEC_ID_MSMPEG4V3, but the codec is msmpeg4 only
[10:37:29] <_troll_> yes, I found that too just now
[10:40:27] <CIA-99> ffmpeg: mru * r24261 /trunk/configure: Fix dependencies for msmpeg4v3 regression test
[10:45:15] <av500> http://ffmpeg.pastebin.com/pgCU1UUq
[10:47:28] <kshishkov> av500: s/wmv1/msmpeg4v4/, s/wmv2/msmpeg4v5/ too
[10:47:54] <_troll_> av500: now _that_ could break apps relying on the name...
[10:49:47] <av500> yes
[10:50:15] <av500> but its totally annoying that you have to configure using "msmpeg4v3" to get -codecs spit out "msmpeg4"
[10:50:43] <av500> kshishkov: and H265 is H261V42
[10:51:20] <_troll_> av500: agreed
[10:51:32] <av500> cant configure at least accept msmpeg4?
[10:51:56] <_troll_> configure pulls the list from allcodecs.c
[10:52:18] <kshishkov> av500: it's "H.261v3/H.26L/AVC/H.264/MPEG4p10/..." - as a single codec ID
[10:54:23] <Dark_Shikari> >h261v3
[10:54:24] <Dark_Shikari> lol
[10:57:36] <Vitor1001> _troll_: Can you revert my revert?
[11:00:15] <_troll_> ideally we should fix the encoder
[11:00:53] <kshishkov> Vitor1001: and then MN will his revert of your revert and leave you both without commit rights for abusing SVN
[11:01:03] <Vitor1001> lol
[11:01:19] <_troll_> I can't look at the encoder now
[11:01:24] <Vitor1001> Well, if I revert myself again it is not a revert-war, no?
[11:01:34] <_troll_> Vitor1001: leave it for now
[11:01:39] <_troll_> I'll have a look at the encoder tonight
[11:01:42] <Vitor1001> ok
[11:01:49] <_troll_> hopefully it's something simple to fix
[11:01:55] <kshishkov> Vitor1001: no, it's called "schizophrenia"
[11:02:11] <Vitor1001> kshishkov: Does we have a policy against that?
[11:02:12] <Vitor1001> ;)
[11:02:24] <_troll_> some of our personalities do
[11:12:39] <J_Darnley> make
[11:12:42] <J_Darnley> oops
[12:14:42] <spaam> J_Darnley: fail :P
[12:33:02] <CIA-99> ffmpeg: vitor * r24262 /trunk/tests/fate2.mak: Vorbis regtests
[12:38:01] <CIA-99> ffmpeg: mru * r24263 /trunk/tests/ref/fate/vc1: fate: update vc1 reference
[13:03:38] <CIA-99> ffmpeg: pross * r24264 /trunk/libavcodec/pcm.c: Use designated initialisers for pcm codec struct
[13:10:24] <kshishkov> congratulations to you and your ... structure, pross-au
[13:12:03] <pross-au> Cheers
[13:12:13] <pross-au> Now where's my, sorry, our GIFT.
[13:12:16] <av500> may it have many offspring
[13:12:33] <pross-au> pcm is ugly
[13:12:44] <kshishkov> like ea_layer3_decoder struct
[13:12:59] <pross-au> ahhh
[13:13:34] <pross-au> Must revisit that someday. Maybe 2012
[13:16:18] <kshishkov> I'll produce BINKb decoder by then
[13:16:47] <pross-au> Careful now. Dont write cheques you can't honour
[13:17:17] * kshishkov somehow grew in land without cheques
[13:18:02] <kierank> what did you have instead?
[13:18:15] <pross-au> Ciao kostya
[13:18:18] <av500> queues
[13:18:31] * mru has never written a cheque
[13:18:43] <mru> cash and credit cards work fine
[13:19:09] <av500> cheques were cool
[13:19:26] <mru> sure, they were a neat invention back in the day
[13:19:43] <av500> and for c2c transactions, you could not use credit cards
[13:19:43] <mru> but they were surpassed by 24h cash machines and plastic cards
[13:19:44] <kierank> paying in cheques is very annoying
[13:19:57] <kshishkov> kierank: hard cash, we called it "wooden" for some reason
[13:20:20] <kierank> you've got to fill out the paying in form. then fill out the form on the envelope and give it in to the teller or god forbid try and get one of those cash depost machines to work
[13:20:37] <av500> one form here only
[13:21:08] <kierank> unsuprisingly your country is known for its efficiency
[13:21:22] <av500> well, no form now, as no more cheques
[13:21:46] <av500> and they try hard to get rid of all income to people, so all the spending questions will be solved....
[13:22:41] <kshishkov> kierank: and it's very religious - people pray before trying to withdraw money from ATM
[13:23:51] <mru> in soviet russia, atm withdraws you
[13:25:04] <mru> that happens elsewhere too: http://www.theregister.co.uk/2007/03/16/carnivore_atm/
[13:25:09] <kshishkov> even I had my money ate by ATM ones
[13:25:15] <kshishkov> s/ate/eaten/
[13:25:29] <mru> you're not supposed to put money in the machine
[13:26:03] <kshishkov> no, it was supposed to give them to me, but it printed receipt, withdrew them from my account and that's all
[13:26:12] <kshishkov> no monetary output
[13:26:15] <av500> mru: so, soon it will say on US ATMs: "there will not be more money if you stick your hand in deeper""
[13:26:29] <av500> kshishkov: highly efficinet
[13:26:31] <av500> ent
[13:27:06] <mru> like on the vending machines: rocking machine will not result in free product
[13:27:17] <av500> no, only on you crushed by machine
[13:28:03] <kshishkov> but not you
[13:28:22] <av500> what machine?...
[13:30:54] <Honoome> mru: I can put money in my bank's ATM :P
[13:31:11] <mru> sure, but can you get it back out?
[13:31:13] <Honoome> [the fact that the money laundry regulations don't allow me to do that anymore is a different problem]
[13:31:32] <Honoome> mru: yah it's listed in realtime on my account's balance ;)
[13:31:36] <mru> I've solved that problem
[13:31:42] <kshishkov> av500: I'm pretty sure you can withstand a falling vending machine
[13:31:51] <mru> I put money in the pockets when I take my clothes to the laundry
[13:32:17] <mru> <insert OADS joke here>
[13:32:19] <kshishkov> to stelthly launder your money?
[13:44:16] <av500> sometimes I hate my job... pDst = ( OMX_U8 * ) ( &( ( ( H264SplitLcmlQInputParam * ) pUAlgInBufParam )->sIttAlgContext ) );
[13:46:47] <mru> eeew
[13:47:35] <av500> yeah, I ran outside and asked a coworker to incenerate the hard drice
[13:47:40] <av500> drive
[13:47:56] <av500> my vision is almost back
[14:07:37] <wbs> BBB: SPACE_CHARS are defined in rtpdec.h now (josh suggested to move them back there since nobody else were using them from internal.h) - do you prefer the version I posted then, or should I move SPACE_CHARS back to internal.h?
[14:08:07] <BBB> hm...
[14:08:10] <av500> #define SPACE " "?
[14:08:15] <BBB> I suppose you could move it to internal.h
[14:08:23] <BBB> av500: \n\r\t
[14:08:25] <mru> av500: no, (" ")
[14:08:30] <mru> or better ( " " )
[14:08:31] <av500> ' '
[14:08:38] <wbs> BBB: ok, will do
[14:09:26] <av500> (,,;,,;,,)
[14:09:57] <mru> for?
[14:10:10] <av500> wasnt that chtulu?
[14:13:42] <CIA-99> ffmpeg: mstorsjo * r24265 /trunk/libavformat/ (rtpdec.h rtpdec_mpeg4.c internal.h):
[14:13:43] <CIA-99> ffmpeg: Move SPACE_CHARS back to libavformat/internal.h
[14:13:43] <CIA-99> ffmpeg: It will be used by other parts of lavf now. This reverts svn rev 23846.
[14:14:15] <mru> should it not include vertical tab and form feed too?
[14:14:34] <mru> and what about bell? is that considered whitespace?
[14:14:49] <BBB> blah
[14:15:02] <BBB> if we don't move it to internal.h everyone will complai about duplication
[14:15:46] <BBB> I think a static inline void skip_spaces(char **ptr) { *ptr += strspn(*ptr, SPACE_CHARS); } would be nice
[14:15:54] <BBB> but that's just me
[14:16:03] <av500> ^G
[14:16:22] <wbs> BBB: yes, that would be very useful for all the protocol code
[14:16:29] <CIA-99> ffmpeg: mstorsjo * r24266 /trunk/libavformat/http.c: http: Log a warning when receiving an error code
[14:16:48] <BBB> I should've brought that up with the original patches, but it's ok for now I guess
[14:16:55] <BBB> maybe later
[14:17:20] * BBB is a little confused with doing all kind of random stuff
[14:33:38] <av500> geee: http://www.matroska.org/technical/specs/tagging/index.html#targettypes
[14:34:04] <BBB> Vitor1001: I'm quickly reading that thread, what does truncf do?
[14:34:29] <Vitor1001> truncation to integer.
[14:34:32] <Vitor1001> I think.
[14:34:33] <mru> BBB: http://www.opengroup.org/onlinepubs/009695399/functions/truncf.html
[14:34:57] <BBB> so it's like round?
[14:35:00] <mru> no
[14:35:05] <mru> it rounds towards zero
[14:35:10] <BBB> I said like
[14:35:14] <BBB> so that's useless
[14:35:26] <mru> round goes to nearest
[14:36:21] <mru> av500: I think the polite word is "over-engineered"
[14:36:59] <av500> yes
[14:37:36] <Vitor1001> BBB: rounding (to any side) will never work to hide floating-point differences.
[14:37:56] <mru> of course not
[14:37:56] <Vitor1001> The only way I see is to convert a couple of vectors to fixed-point.
[14:37:59] <BBB> the amrnb thread said this removed the problem ;)
[14:38:16] <BBB> I was very confused by that
[14:38:17] <BBB> I still am
[14:38:27] <elenril> mru: no, the polite word would be "still better than ogg"
[14:38:32] <Vitor1001> BBB: Well, removed, not much. It still differs considerably from the reference.
[14:38:38] <av500> mru: https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/0a0ab854d66b75f8#
[14:38:48] <av500> lhomme will be back!
[14:39:23] <Vitor1001> BBB: Compare your 2.5 stddev with the enormous value he was getting. In that sense, it "removed" the problem...
[14:40:13] <mru> hi DonDiego
[14:42:00] <BBB> Vitor1001: right
[14:42:05] <BBB> Vitor1001: I guess 2.5 isn't bad at all
[14:42:17] <BBB> I mean, it's bad of course, but since it's gradual buildup of random noise variation, it's ok
[14:42:23] <jai> well lavf does support tags, just that the demuxer prefixes targettypes to the metadata value
[14:42:50] <elenril> lavf doesn't support muxing
[14:43:22] <jai> ah, yes
[14:43:35] <elenril> (yet)
[14:43:41] * elenril should finish the patch for that
[14:43:59] <jai> "I can not get meta-data for webm video file." <= i thought he meant demuxing
[14:44:22] <jai> elenril: with target types ?
[14:45:44] <elenril> no
[14:48:00] <elenril> i fail to see the point of those, they mess up conversion etc
[14:48:30] <av500> well, we just add title_10, title_20, title_30.....
[14:54:20] <Vitor1001> BBB: 2.5 isn't bad, it is just unpractical for regression testing...
[14:54:42] <BBB> also maxdiff>90
[14:54:48] <BBB> suggests something weird is going on
[14:54:54] <BBB> can you both send me the pcm output?
[14:54:59] <BBB> so I can see what's so different?
[14:55:01] <Vitor1001> Sure
[14:55:11] <Vitor1001> You don't have an account?
[14:55:18] <BBB> where?
[14:55:21] <BBB> (probably not)
[14:55:33] <Vitor1001> In mru's PPC box
[14:55:36] <BBB> no
[14:56:04] <Vitor1001> You can just ask him
[14:56:08] <jai> elenril: you could just allow remuxing of targettype 50 and drop the rest
[14:57:32] <jai> tbh though i dont see the point either
[14:58:10] <Vitor1001> BBB: sent
[14:58:35] <elenril> jai: ?
[14:58:46] <elenril> you mean not export any other metadata?
[14:59:14] <jai> elenril: yeah, when the output is anything other than mkv
[14:59:46] <jai> is there any other issue you see with conversion?
[15:00:15] <elenril> what? the demuxer doesn't know anything about output
[15:02:26] <jai> umm, yeah. i was referring to targettype handling in the muxer
[15:02:32] <BBB> Vitor1001: ty
[15:03:33] <elenril> nah, i'd rather not write it at all
[15:03:38] <jai> av500: seeking in mod files would be tough
[15:03:42] <elenril> it's not mandatory and nobody uses it anyway
[15:03:53] <jai> true
[15:04:59] <jai> and pointless to because of the latency
[15:05:01] <jai> *too
[15:09:55] <jai> of course we could always implement bass/modplug style inaccurate seeking
[15:11:11] <av500> jai: why cant you seek? a sequencer usually has quite a good idea about time, no?
[15:11:29] <Vitor1001> jai: Do you have any idea why SIPR in vlc sounds worse than in ffplay?
[15:11:58] <mru> because everything is better with ff
[15:12:07] <jai> av500: the instruments used tend to change based on the pattern, so skipping a bunch without having interpreted the earlier ones screws up the state
[15:12:13] <KotH> mru: ffsalt?
[15:12:21] <mru> ffchocolate
[15:12:29] <KotH> hmm...
[15:12:31] <KotH> good idea
[15:12:39] <jai> av500: well, you could seek, its just very unreliable and tends to suck
[15:12:46] <KotH> i'll ask whether sprüngli will sponsor some ffchocolate for next LT
[15:13:04] <jai> Vitor1001: didnt know that, could you point me to a sample?
[15:13:17] <Vitor1001> just a min
[15:16:10] <Vitor1001> jai: Weird, I cannot reproduce it anymore.
[15:16:14] <Vitor1001> jai: But test http://samples.mplayerhq.hu//real/AC-sipr/intro.rm
[15:17:14] * Vitor1001 can only run VLC on wine...
[15:18:14] <mru> not beer?
[15:18:29] <jai> Vitor1001: sounds same as ffplay's audio output here
[15:18:43] <jai> Vitor1001: are you using pulseaudio or something by any chance
[15:18:58] <Vitor1001> jai: Ok, fine, should be my setup...
[15:19:16] <Vitor1001> Never got to compile VLC using my non-installed ffmpeg tree...
[15:20:33] <twice11> would it be possible to create one AVPacket per tick (IIRC typically 6 ticks/row)?
[15:21:39] <Vitor1001> twice11: Don't some sample formats has commands to go to the n-th row or something?
[15:24:44] <av500> mru: you need to runtime detect neon
[15:24:44] <twice11> Mod even has some loop command.
[15:24:55] <mru> av500: how?
[15:25:07] <twice11> That would be decoded in the mod->BSS part, as I see it.
[15:25:12] <av500> no idea, but otherwise ubuntu will drop ffmpeg neon
[15:25:20] <jai> Vitor1001: yeah
[15:25:20] <mru> their problem, not mine
[15:25:26] <mru> but do you have a reference?
[15:25:41] <av500> ask koen
[15:26:09] <mru> is this loic's doing?
[15:26:23] <av500> loic?
[15:26:26] <av500> our CFO?
[15:26:28] <Vitor1001> twice11: That kind of things that make it kind of pointless to break a file in several packets.
[15:26:30] <mru> ubuntu arm guy
[15:26:47] <mru> loic minier
[15:26:53] <av500> dunoo
[15:27:36] <twice11> Vitor1001: You decode the file into ticks (and expand the loops). The per-tick-info is then stateless and perfectly seekable, even with absolute time.
[15:28:28] <jai> whoa, isnt that waaay too much overhead?
[15:28:44] <Vitor1001> twice11: To expand the loop one has to practically decode, no? Besides, it would make a lot of information loss in transcoding...
[15:29:03] <jai> once the new seeking api is in place, you could just do what dumb does
[15:29:58] <DonDiego> what do you guys think of the -Wcast-qual warning?
[15:30:34] <mru> DonDiego: it would be good, if it weren't for a few situations where no amount of const will avoid the warnings
[15:30:40] <mru> double pointers come to mind
[15:31:00] <mru> and implementations of strstr() and friends
[15:31:44] <DonDiego> i
[15:31:56] <DonDiego> 'm tasked with removing some warnings from HIPL
[15:32:03] <DonDiego> and they are all caused by that option
[15:32:11] <mru> so you're going to drop the flag?
[15:32:17] <mru> sounds wrong without a thorough investigation
[15:32:26] <mru> usually the fix is to add const where it belongs
[15:32:31] <DonDiego> i remembered that there was some discussion about dropping the flag on -devel
[15:32:31] <av500> http://hipl.org/
[15:32:44] <jai> mru: not a fan of tracked music eh :)
[15:32:49] <DonDiego> http://infrahip.net/
[15:33:30] <DonDiego> can i trust the fix to be ok if adding a const kills the warning?
[15:34:17] <mru> make sure it doesn't pop up elsewhere instead
[15:34:26] <mru> const warnings can be very hard to kill
[15:39:09] <twice11> If adding a const does not provoke new warnings or errors, the fix is OK (except in C++ maybe where different overloads might be chosen depending on constness).
[15:39:43] <mru> overlords...
[15:39:56] <twice11> Adding casts to silence warnings might be dangerous and hide problems.
[15:39:59] <mru> <swedish>konstigt</swedish>
[15:40:17] <mru> twice11: I _never_ suggested adding casts
[15:40:41] <twice11> OTOH, there are too many libraries with missing consts in their interfaces where adding casts is needed :(
[15:40:51] <mru> if I start doing that, I count on you lot to take me to the doctor
[15:40:54] <twice11> mru: I did not mean to suggest you did.
[15:41:14] <av500> mru: not just shoot you?
[15:42:03] <mru> that may be the only cure...
[15:42:07] <KotH> mru: we should take you to the doctor anyways ;)
[15:42:15] <kshishkov> mru, have no worry. Almost everything is curable withh shovel
[15:42:23] <mru> KotH: there aren't any left who will see me
[15:42:47] <KotH> mru: you mean i should study medicin?
[15:43:13] <DonDiego> what was the result of the discussion on -devel?
[15:43:22] <DonDiego> will the warning stay or be removed?
[15:43:33] <mru> DonDiego: probably that there are many colours of bikesheds
[15:44:10] <kshishkov> mru: only Faluroda for true bikesheds
[15:44:13] <KotH> mru: superposition of bikeshed colours?
[15:44:34] <kshishkov> KotH: you know what you get when you mix all colours
[15:44:47] <av500> ugly
[15:45:02] <KotH> kshishkov: yes: an ugly brownish colour
[15:45:13] <kshishkov> KotH: or greenish
[15:45:45] <kshishkov> that's why I stick to traditional colour of sheds in the country of heavy bike users
[15:46:28] * KotH doesnt know what colour the sheds in china are
[15:46:44] <kshishkov> who cares about China?
[15:46:56] <KotH> they are heavy bike users
[15:47:08] <mru> they use heavy bikes?
[15:47:15] <kshishkov> I mean Nordic countries
[15:47:17] <av500> they have no bikesheds
[15:48:52] <kshishkov> cyckelbod
[15:50:10] <mru> cykel
[15:50:20] <mru> or sykkel in .no
[15:50:36] <kshishkov> I thought that word means simply "bicycle"
[15:50:38] <kierank> [16:46] <@kshishkov> who cares about China? --> red of course
[15:51:43] <kshishkov> kierank: one of popular mottos in West Ukraine is "communist should be hanged on tree branch"
[16:51:46] <CIA-99> ffmpeg: vitor * r24267 /trunk/libavcodec/imc.c: Make Intel Music Coder output SAMPLE_FMT_FLT
[16:52:14] <mru> Vitor1001: does this break the fate test?
[16:52:49] <Vitor1001> mru: Of course not. It _fixes_ the fate test when using float_to_int16_c.
[16:53:18] <mru> I mean on the machines where it was already working
[16:53:29] <mru> maybe working is the wrong word
[16:53:32] <mru> does the output change?
[16:53:47] <Vitor1001> I know. No, that was how I tested to see if I didn't screwed up my patch ;)
[16:54:56] <Vitor1001> mru: BTW, I've written Mike about enabling fate2 in the fate machines and was simply ignored :p
[16:55:03] <mru> I know
[16:55:34] <Vitor1001> do you? I mean again, in pvt.
[16:56:06] <mru> your mail to the list a week ago got no response
[16:56:12] <Vitor1001> yes
[16:56:13] <mru> didn't know you'd mailed him again
[16:56:42] <Vitor1001> Maybe we should just convince fate machine admins to run "make -k test fate2" instead of just "make -k test"...
[16:57:02] <mru> or make test include fate2...
[16:57:05] <mru> no convincing required
[16:57:23] <Vitor1001> It will fail for most people who don't pass the samples path to configure...
[16:57:54] <Vitor1001> And "make test" should include both fate1 and fate2...
[16:58:05] <Vitor1001> (if it were to include anything)
[16:58:13] <mru> yeah
[16:59:05] <Vitor1001> Does "make fate2" pass in all your jungle of exotic hardware?
[16:59:29] <mru> haven't tested them all
[17:00:19] <Vitor1001> I ran each test in my notebook and your ppc box, but only that...
[17:01:35] <Vitor1001> But I'm happy it has already spotted a bug
[17:01:38] <mru> testing on the beagle now
[17:01:43] <Vitor1001> Nice!
[17:02:24] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/FEG1Z3qZ good idea or bad idea? it makes the integration of the size==8 one (a little code is available for that on top, so you can see what I have in mind) easier
[17:02:51] <BBB> and saves a regular reg on x86-64 8-)
[17:03:46] <mru> vorbis-18 fails with maxdiff=2
[17:03:57] <Vitor1001> :p
[17:04:18] <mru> the neon float to int rounds negative values slightly differently
[17:04:22] <mru> that's probably the reason
[17:04:39] <Vitor1001> mru: I see... Maybe we could just add fuzz=2 to this test...
[17:04:47] <Vitor1001> And the rest pass?
[17:04:52] <mru> rest pass
[17:04:54] <Vitor1001> cool
[17:04:58] <mru> ask the vorbis maintainer
[17:05:10] <mru> who's that anyway? yuvi?
[17:06:39] <mru> peloverde might have an opinion
[17:06:49] <peloverde> about?
[17:06:51] <Vitor1001> Ok. I'll post an open question to the list.
[17:06:53] <mru> peloverde: fate-vorbis-18 has maxdiff 2 on arm
[17:07:10] <peloverde> 2 seems reasonable
[17:07:53] <mru> so you think setting fuzz=2 is ok?
[17:08:36] <Vitor1001> mru: MAINTAINERS list mike for vorbis...
[17:08:54] <Vitor1001> ... who is not really active these days.
[17:09:03] <peloverde> I think Yuvi is the defacto maintainer
[17:09:15] <mru> mike? not here
[17:09:26] <peloverde> anyway pretty much all of AAC seems to require fuzz=2
[17:09:37] <mru> my file says denes balatoni and yuvi
[17:09:49] <peloverde> and they are fairly similar formats
[17:09:51] <Vitor1001> mru: nevermind, saw it wrong
[17:09:57] <mru> yeah, next line has mike
[17:10:29] <peloverde> Are any of these tests going to make it into real fate anytime soon?
[17:10:43] <mru> don't hold your breath
[17:10:47] <DonDiego> experience with mike says no
[17:11:00] <mru> so let's build a new fate
[17:11:12] <DonDiego> as i've been saying, we need to build the community fate to replace mike's proprietary one
[17:11:24] <DonDiego> the 'make fate' target is a good start
[17:11:33] <DonDiego> everybody can basically run fate locally now
[17:11:51] * kshishkov prefers providing reasons for new cases to fate instead
[17:11:55] <Vitor1001> peloverde: we can put in a few boxes by asking their admin to replace "make test" by "make test fate2"
[17:12:16] <mru> there's a problem with that
[17:12:32] <mru> mike's script only logs the last few lines of output
[17:12:45] <mru> so it might not be possible to see what failed
[17:12:59] <mru> and lumping them all together isn't nice either
[17:13:09] <mru> therefore, let's make something new and better
[17:13:13] <Vitor1001> Of course.
[17:13:43] <kierank> mru: i thought you don't do web ;)
[17:13:55] <mru> I don't
[17:14:01] <mru> I'm leaving that part to you
[17:14:34] <Vitor1001> Be sure to use google, MSN and yahoo scripts for providing flamewar amusement in -devel.
[17:14:39] <kshishkov> it's totally different app anyway
[17:15:06] <lu_zero> yawn?
[17:15:09] <Honoome> hi lu
[17:15:10] <kshishkov> and <script language="Lisp"> tags
[17:15:13] <lu_zero> hi
[17:15:19] <lu_zero> please...
[17:15:44] <lu_zero> not use something that crazy...
[17:15:53] <Honoome> kshishkov: don't give crazy ideas to luca
[17:15:55] <mru> arm asm?
[17:15:59] <Honoome> he's known to getting them throguh
[17:16:07] <lu_zero> mru: that's good
[17:16:17] <mru> not for web scripts
[17:16:17] <kshishkov> Honoome: good luck dealing with HTML5 comittee
[17:16:22] <lu_zero> btw why arm asm uses % instead of @
[17:16:33] <mru> instead of?
[17:16:37] <mru> in what context?
[17:16:39] <lu_zero> my current idea for html5 is adding rtsp for video
[17:16:39] <kshishkov> for comments
[17:16:44] <lu_zero> mru: progbits
[17:16:44] <peloverde> fate-imc is failing on my system
[17:16:53] <lu_zero> I had icu fail on arm because of that
[17:16:53] <mru> lu_zero: because @ is comment
[17:17:04] <peloverde> nevermind, i see it is being discussed
[17:17:08] <Vitor1001> peloverde: Did you update it?
[17:17:38] <Vitor1001> peloverde: It should work fine after r24267
[17:18:06] <mchinen> are there any gotchas for the file end conditions when writing parsers?
[17:18:33] <kshishkov> no
[17:19:14] <mchinen> trying to do a flac one but i get some memory bashing bugs in ff_combine_frame that I'm trying to sort out with valgrind
[17:20:49] <mru> kshishkov: you said anything can be cured with a shovel...
[17:21:14] <kshishkov> mru: rather anybody's illness
[17:22:21] <kshishkov> and Soviet army shovel sounds cooler than Swiss army knife
[17:22:27] <peloverde> Vitor1001: you are correct
[17:22:33] <mchinen> hope it doesn't drive me to that point.
[17:23:04] <lu_zero> kshishkov: you had a shovel with multiple tools embedded inside?
[17:23:15] * lu_zero still wonders at the american spork
[17:23:41] <mru> http://xkcd.com/419/
[17:23:49] <kshishkov> lu_zero: no, but there are too many uses for ordinary shovel anyway
[17:25:33] <lu_zero> yes
[17:25:49] <lu_zero> like hacking woods
[17:27:02] <lu_zero> interesting fact
[17:27:16] <kshishkov> well, current Ukrainian infantry equipment includes _two_ shovels
[17:27:52] <lu_zero> youtube h264 high res takes more to decode than vp8
[17:29:09] <Honoome> with ffvp8?
[17:29:25] <lu_zero> yes
[17:29:29] <lu_zero> on the imx
[17:29:50] <lu_zero> so there is something strange
[17:30:02] <Honoome> like the whole system?
[17:30:12] <Honoome> -mfpu=no? :P
[17:30:24] <lu_zero> -mfpu=neon you mean?
[17:30:36] <Honoome> ah you did rebuild all of it then?
[17:30:39] <kshishkov> FPU is useful with H.264 indeed
[17:30:56] <mru> fpu is a bit of a misnomer here
[17:33:12] <lu_zero> Honoome: not exactly
[17:33:30] <lu_zero> apparently the image and the "sdk" were desynced...
[17:33:35] <Honoome> lu_zero: you know that if you didn't rebuild, say, glibc, you're going to use integer-only libm? :P
[17:33:56] <lu_zero> Honoome: I do know =P
[17:34:04] <Honoome> did you rebuild glibc?
[17:34:36] <lu_zero> cat /var/db/pkg/sys-libs/glibc-2.11.2/CFLAGS
[17:34:36] <lu_zero> -march=armv7-a -mtune=cortex-a8 -mfpu=neon -pipe -O2 -fno-strict-aliasing
[17:34:41] <lu_zero> no I checked the flags
[17:36:12] <BBB> Vitor1001: how feasible is it to check the stdev < X instead of maxdif < X for amr && wmavoice?
[17:36:27] <BBB> (I haven't checked the files yet, but it's an alternative solution that will catch obvious bugs)
[17:38:38] <mru> lu_zero: you forgot -mfloat-abi=softfp
[17:38:45] <mru> or =hard as your case may be
[17:41:52] <lu_zero> mru: I didn't, the guy that made the image did
[17:42:04] <lu_zero> mru: what's the difference between them btw?
[17:42:07] <mru> in that case you forgot to make your own
[17:42:19] <mru> softfp uses softfloat calling convention
[17:42:20] <lu_zero> mru: I'm supposed just to evaluate it
[17:42:26] <mru> hard passes float parameters in vfp registers
[17:42:30] <mru> which is much more efficient
[17:43:25] <lu_zero> noticed
[17:43:26] <lu_zero> uhmm
[17:46:59] <DonDiego> ah, the ugliness..
[17:47:12] <DonDiego> two casts in a row like: (foo *) (void *)
[17:47:14] <mru> ?
[17:47:16] <mru> oh
[17:47:20] <DonDiego> the joys of working on hipl..
[17:47:36] <mru> why do you do it?
[17:47:43] <DonDiego> s/you/they/
[17:47:57] <DonDiego> probably didn't know better, noticed that it worked..
[17:48:01] <mru> you work on it
[17:48:02] <mru> why?
[17:48:22] <DonDiego> i get paid to do it, the people are nice, i may get to do a thesis..
[17:48:42] <DonDiego> i assume it's safe to remove the void* cast?
[17:48:57] <mru> I get paid (probably much more) to write fun assembler code...
[17:49:23] <DonDiego> :)
[17:49:31] <DonDiego> s/probably//
[17:49:35] <lu_zero> DonDiego: check
[17:49:45] <lu_zero> if gcc screams about aliasing you know why it was there
[17:52:56] <DonDiego> are aliasing warnings part of -Wall and -Wextra?
[17:53:08] <mru> should be -Wall
[17:53:14] <mru> they are in whatever ffmpeg uses
[17:53:40] <mru> they are more elaborate (and more numerous) with more recent gcc versions
[17:53:53] <peloverde> DonDiego: Is the mplayer build system broken?
[17:55:25] <Honoome> -Wstrict-aliasing should be in -Wall
[17:55:32] <Honoome> -Wstrict-aliasing=2 _may_ be in -Wextra
[17:58:48] <DonDiego> peloverde: not that i know of
[17:58:59] <DonDiego> i have fixed all the bugs i was told about
[18:00:43] <peloverde> DonDiego: Whenever I try to configure I get "Error: MPlayer will not compile without libavutil in the source tree." at the bottom and "sed: can't read libavcodec/allcodecs.c: No such file or directory" at the top
[18:01:02] <peloverde> SVN checkout from ~5 minutes ago
[18:04:02] <DonDiego> what options do you pass to configure?
[18:04:08] <DonDiego> and what system are you on?
[18:04:18] <peloverde> http://pastebin.ca/1901914
[18:04:20] <peloverde> amd64
[18:04:33] <DonDiego> also, this is offtopic here - i'll gladly help you, but move it to #mplayerdev or privmsg, whatever you prefer
[18:04:54] <peloverde> I tried on #mplayer and no one was useful
[18:05:16] <DonDiego> oh, i see - you are trying to build out-of-tree, this is not supported
[18:05:30] <peloverde> So it is broken
[18:05:36] <DonDiego> it's on the wishlist, but not particularly high up on my todo list
[18:06:08] <DonDiego> if you consider that a requirement for nonbrokenness, then yes, by your definition of broken, it is broken
[18:07:18] <mru> how can anyone _not_ do out of tree builds?
[18:07:53] * DonDiego never felt so constrained without it..
[18:08:02] <DonDiego> it's a matter of habit i guess
[18:08:28] <peloverde> It never even occurred to me to try an intree build
[18:08:42] <peloverde> That how outmoded the concept is
[18:08:55] <mru> building the same source in a dozen different configurations is often handy
[18:09:08] <mru> and make distclean turns into rm -r *
[18:09:13] <peloverde> agreed
[18:09:15] <mru> much more reliable
[18:09:38] <peloverde> I don't even cross compile and I keep 5 or 6 ffmpeg build directories
[18:09:52] <Honoome> ++ on out-of-tree
[18:09:58] <DonDiego> for a long time it never occurred to me to build out-of-tree
[18:10:06] <peloverde> clag, gcc, no asm, x86_32 (I guess that is technically cross)
[18:10:13] <DonDiego> and judging from the people i know it's an alien concept to most devs
[18:10:17] <mru> DonDiego is the old in-tree, svn etc mindset
[18:10:23] <DonDiego> lol :)
[18:10:44] <peloverde> I guess I am also kind of hating on MPlayer because of the WebM thing
[18:11:19] <mru> mplayer devs always expect special treatment
[18:12:03] <DonDiego> geez, calm down already
[18:12:19] <DonDiego> mplayer has always been the first ffmpeg user
[18:12:38] <mru> that doesn't give it the right to abuse non-api functions
[18:12:57] <DonDiego> and it's a very recent development that no longer 80% of ffmpeg devs are not also mplayer devs
[18:13:18] <DonDiego> it shows how ffmpeg can be abused and that should be considered
[18:13:25] <DonDiego> if mplayer does it, others will follow
[18:13:34] <peloverde> You say it's very recent but it has been the case for the 2 years I have been around
[18:13:45] <peloverde> aka 20% of FFmpeg's history
[18:14:56] <mru> it's a long time since any other mplayer devs than DonDiego and reimar were active in ffmpeg
[18:15:26] <mru> and I've been around longer than DonDiego
[18:15:34] <DonDiego> you are among the 20%
[18:15:45] <DonDiego> peloverde: you are a newcomer..
[18:15:55] <kshishkov> so am I
[18:16:02] <peloverde> 20% ago is not recent history
[18:16:28] <DonDiego> oh, come on..
[18:16:40] <microchip_> mru: Carl is active, no?
[18:17:33] <mru> he doesn't do any coding
[18:20:01] <kshishkov> mru: exclude Diego then
[18:22:39] <peloverde> Also the past 2 years makes up 40% of ffmpeg commits
[18:30:11] <CIA-99> ffmpeg: rbultje * r24268 /trunk/libavcodec/x86/vp8dsp.asm:
[18:30:11] <CIA-99> ffmpeg: Change return statement, the REP_RET is a mistake since the else case (x86-64,
[18:30:12] <CIA-99> ffmpeg: sse2) doesn't actually loop, so REP_RET isn't necessary.
[18:33:25] <mru> mplayer is like ntsc and interlacing
[18:33:35] <mru> an ugly hack once necessary
[18:33:48] <mru> now lingering around due only to inertia
[18:36:47] <Compn> so what replaced mplayer mru ?
[18:36:59] <mru> a lot of people seem to use vlc
[18:37:08] <Compn> what do you use ?
[18:37:09] <kshishkov> Compn: and what replaced NTSC?
[18:37:14] <mru> kshishkov: hdtv
[18:37:23] <Compn> interlaced ntsc hdtv kshishkov
[18:37:29] <kshishkov> is it ubiquous?
[18:37:43] <Compn> under the atsc standard :P
[18:37:44] <DonDiego> vlc on the command line sucks
[18:37:48] <mru> I guess nothing is sufficiently better to kill it off completely
[18:37:50] <Compn> vlc ... sucks :P
[18:37:57] <mru> both mplayer and ntsc
[18:38:15] <mru> Compn: I don't use vlc
[18:38:16] <kshishkov> add VLC to that list just in case
[18:38:47] * kshishkov somehow is better with German project than with French
[18:39:14] * Compn kidding of course, vlc has more features than mplayer
[18:40:22] <Compn> huh
[18:40:25] <Compn> gives me an idea
[18:40:28] <peloverde> In a lot of ways VLC seems to be moving in the right direction
[18:40:40] <Compn> how much code to make mplayer output a stream using ffmpeg's network code
[18:41:28] <Compn> vlc also has more output messages than mplayer
[18:41:41] <peloverde> the LGPL libvlc relicense, etc, compare how much traffic VLC got at FOSDEM compared to the combined FFmpeg/MPlayer stand
[18:42:18] <Compn> how much more did they get ?
[18:42:30] <kshishkov> peloverde: you'd see how much traffic got LinuxTag MPlayer stand
[18:42:38] <mru> lol
[18:42:41] <mru> mplayer
[18:42:55] <kshishkov> mru: unlike OGP it was manned too
[18:43:02] <mru> true
[18:43:18] <mru> but they had only a single, small poster
[18:43:26] <mru> ffmpeg had The Beast
[18:43:36] <peloverde> Compn: It seemed like at least a factor of 4 or 5, and a good chunk of our traffic was OGP
[18:43:49] <peloverde> Also, we have been added: http://www.webmproject.org/about/supporters/
[18:44:37] <Compn> ugh
[18:44:40] <Compn> right next to flash logo
[18:44:50] <kierank> and near java
[18:44:51] <Compn> ah its alphabetical
[18:46:11] <BBB> peloverde: you forget that vlc is an end user tool
[18:46:16] <BBB> peloverde: ffmpeg is a developer's tool
[18:46:23] <BBB> they attract different audiences
[18:46:24] <peloverde> BBB: Mplayer is an enduser tool
[18:46:31] <BBB> no
[18:46:35] <BBB> mplayer is a hack, as mru just said
[18:46:46] <peloverde> A hack that claims to be an end user tool
[18:46:55] <BBB> vlc _is_ an end user tool :-p
[18:47:13] <BBB> it's like freetards _claim_ to be relevant, whereas google _is_ relevant
[18:47:22] <BBB> that's why theora sucked ass and vp8 might actually have a slight chance
[18:47:26] <peloverde> VLC is what MPlayer should be
[18:47:31] <BBB> probably, yes
[18:47:57] <peloverde> Also, I still think we could do some work to raise our profile hence my mini PR blitz (WebM, firefogg, etc)
[18:48:21] <BBB> yes, indeed
[18:48:24] <BBB> I totally agree
[18:49:04] <jai> why does vls "suck" on the command line?
[18:49:07] <jai> *vlc
[18:49:38] <mru> because it's got a vacuum
[18:49:43] <mru> as opposed to being full of hot air
[18:49:56] <jai> ic
[18:49:58] <jai> :)
[18:50:09] <kierank> seeking is still broken
[18:50:24] <kierank> with h.264 and ts/mkv I think
[18:50:31] <Compn> jai : have you tried it on the command line ?
[18:50:49] <jai> Compn: i use it exlusively with the cli
[18:51:27] <jai> then again, personal taste
[18:51:52] <jai> kierank: are you aware of any ticket for that?
[18:52:18] <Compn> jai : so you are saying that mru should report bugs instead of complaining about vlc's cli suckage ?
[18:52:23] <Compn> :)
[18:52:35] <mru> when did I complain about vlc?
[18:52:38] <jai> 00:07:51     @DonDiego | vlc on the command line sucks
[18:52:51] <jai> mru: not you :)
[18:52:54] <Vitor1001> <BBB> Vitor1001: how feasible is it to check the stdev < X instead of maxdif < X for amr && wmavoice?
[18:52:55] <Compn> oops
[18:52:57] <Vitor1001> Pretty easy
[18:52:58] <Compn> my bad
[18:53:10] <jai> Compn: if its a simple UX issue, i'm sure we could fix it
[18:53:28] <BBB> Vitor1001: maybe we should do that, at least for now, with a requirement that stdev<=3 or so
[18:53:54] <jai> sucks being a broad term, i'm sure j-b and others would appreciate any feedback
[18:54:28] <jai> hm, michael never ok'd the memleak stuff
[18:55:02] <Vitor1001> BBB: ok, I will have a look at it
[18:55:14] <BBB> cool
[18:59:39] <DonDiego> bye
[18:59:57] <j-b> vlc suck :D
[19:00:18] <Compn> nooo, its good. dont listen to us chickens
[19:00:39] <j-b> no, it sucks. But so far, most other stuff suck even more :D
[19:01:00] <j-b> and the cool thing about sucking hard, is that there is fucking lots of place for improvement :)
[19:01:02] <Compn> the truth of the universe
[19:01:14] <Compn> it sucks, but everything else sucks more
[19:01:23] <j-b> not everything :)
[19:01:38] <j-b> I switched from mplayer to vlc just a few months ago
[19:05:51] <Honoome> if we're doing the player-that-sucks-a-lot competition, xine wins by default
[19:06:26] <j-b> Honoome: what about ogle?
[19:06:35] <Honoome> was that ever generic?
[19:06:39] <cartman> ogle rocks
[19:06:41] <cartman> ;)
[19:06:42] <j-b> no idea :D
[19:06:53] <mru> ogle was a dvd player
[19:07:03] <mru> it actually did menus correctly
[19:07:09] <cartman> yup
[19:07:17] <cartman> it was ahead of its time for DVDs :)
[19:07:20] <j-b> mru: btw, vlc's avcodec module works really great on iPad
[19:07:56] <j-b> mru: thanks a lot ;)
[19:08:15] <cartman> now enable gpu decoding for MacOSX
[19:08:17] <cartman> ;=
[19:08:21] <cartman> s/=/p
[19:08:35] <j-b> well, the patch is there, but well
[19:08:53] <cartman> now Mac maintainer still ?
[19:08:57] <cartman> s/now/no
[19:09:10] <j-b> cartman: people will work on it, soonish
[19:09:17] <cartman> neato :)
[19:09:29] <cartman> first thing to install on a Mac is vlc
[19:09:35] <cartman> and then compile ffmpeg ;)
[19:09:37] <j-b> I can't tell more... I need to fight FSF about the iPad
[19:09:46] <mru> ?
[19:09:51] <cartman> fight Apple first
[19:09:55] <cartman> for the AppStore :P
[19:09:59] <j-b> and then, I'll see about the Mac thing
[19:10:11] <j-b> cartman: we'll do soonish
[19:10:12] <mru> what does the fsf have to do with anything?
[19:10:21] <Honoome> mru: if vlc has any fsf-owned code on the ipad it'll have to abide to gpl-2 when distributed
[19:10:27] <mru> but does it?
[19:10:28] <Honoome> and the app store does not allow you to fully abide to gpl-2
[19:10:40] <j-b> vlc is gplv2+
[19:10:43] <mru> so?
[19:10:50] <mru> does the fsf own copyright?
[19:10:57] <j-b> fsf interpretation of the GPL is that this isn't ok
[19:11:10] <j-b> mru: no, but some devs trust them
[19:11:15] <Honoome> most other people settle for the "the way that's more practical" of allowing the sources to be available
[19:11:17] <mru> shoot those devs
[19:11:23] <mru> and replace their code
[19:11:25] <kierank> there's a copy of vlc (pay) on the app store iirc
[19:11:39] <Honoome> without having to actually deny themselves availability on the appstore
[19:11:39] <j-b> well, libvlc is being relicensed anyway
[19:11:58] <Honoome> mru: that's why we call them freetards, no?
[19:12:19] * Honoome still think that some software is better than no software
[19:13:33] <Dark_Shikari> btw
[19:13:44] <Dark_Shikari> Bugmaster is finding a lot of swscale bugs relating to register sizes and such
[19:13:51] <Dark_Shikari> now that x264 uses swscale on win64
[19:14:02] <Dark_Shikari> lots of users are reporting crashes
[19:14:10] <Dark_Shikari> so.... lots of bugfixes may be coming in that way.
[19:15:54] <Vitor1001> BBB: http://ffmpeg.pastebin.com/wvLSxNty
[19:16:29] <mru> Vitor1001: let me clean that up
[19:20:00] <Vitor1001> mru: I was expecting it ;)
[19:24:33] <spaam> Dark_Shikari: bugmaster?
[19:25:58] <Dark_Shikari> russian x264 dev
[19:28:49] <BBB> Vitor1001: awesome
[19:29:09] <peloverde> mru: tcvp.sourceforge.net and trac.inprovinde.com/tcvp are down, is it ok to change the link to http://git.mansr.com/?p=tcvp
[19:29:16] <mru> sure
[19:29:27] <mru> and thanks
[19:29:37] <BBB> Dark_Shikari: ping re my patch
[19:29:44] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/FEG1Z3qZ
[19:30:00] <BBB> Dark_Shikari: is that ok? makes implementing chroma inner loopfilter ultra-simple
[19:30:50] <Dark_Shikari> sure
[19:34:44] <BBB> it also saves one reg on x86-64 8-)
[19:34:47] <BBB> (had to say that)
[19:39:00] <CIA-99> ffmpeg: rbultje * r24269 /trunk/libavcodec/x86/vp8dsp.asm:
[19:39:00] <CIA-99> ffmpeg: Give x86 r%d registers names, this will simplify implementation of the chroma
[19:39:00] <CIA-99> ffmpeg: inner loopfilter, and it also allows us to save one register on x86-64/sse2.
[19:43:22] <CIA-99> ffmpeg: rbultje * r24270 /trunk/libavcodec/x86/vp8dsp.asm: Remove duplicate define.
[19:44:50] <BBB> Dark_Shikari: can I do %if bla == x && blo == y in a macro?
[19:45:41] <Dark_Shikari> yes
[19:46:57] <BBB> shit I hate my text editor
[19:55:13] <CIA-99> ffmpeg: rbultje * r24271 /trunk/libavcodec/x86/vp8dsp.asm: Revert 24270, it contained some stuff that shouldn't have been in there.
[19:55:13] <CIA-99> ffmpeg: rbultje * r24272 /trunk/libavcodec/x86/vp8dsp.asm: Remove duplicate define.
[19:56:59] <Honoome> mru: I guess the only solution to the deprecated warnings is getting rid of the code iirc the problem was in the declaration themselves, that gcc counts as usage, and are _always_ emitted once including the header
[19:58:58] <mru> there's not many of those
[19:59:16] <mru> there are some for AVPaletteControl stuff
[20:03:35] <CIA-99> ffmpeg: alexc * r24273 /trunk/libavcodec/aaccoder.c: aacenc: Template quantize_and_encode_band_cost().
[20:15:58] <BBB> Dark_Shikari: this was too easy ;) it already works
[20:16:14] <BBB> wanna see the patch (mmx/mmx2 only for now, sse2 requires actual code :-p)
[20:16:40] <Dark_Shikari> sure
[20:17:30] <peloverde> stupid C question, I feel like I'm missing a const here but I don't know where it goes: http://pastebin.ca/1901993
[20:17:32] <BBB> http://ffmpeg.pastebin.com/D8ihT70h
[20:18:06] <peloverde> Specfically the pointers in quantize_and_encode_band_cost_arr should never be over written
[20:18:11] <BBB> peloverde: static const float ...?
[20:18:27] <peloverde> nope, that changes the return type of the functions
[20:19:02] <pengvado> static float (*const quantize_and_encode_band_cost_arr[])(
[20:19:48] <peloverde> thanks
[20:22:45] <Dark_Shikari> BBB: you should give it a better name
[20:22:47] <Dark_Shikari> it's no longer filter8 imo
[20:22:49] <Dark_Shikari> maybe filteruv?
[20:22:53] <Dark_Shikari> and filter16 should be filtery
[20:23:01] <Dark_Shikari> anyways, awesome
[20:27:47] <BBB> filter16y/filter8uv?
[20:28:29] <BBB> it acts on cols/rows of 16/8wide/high
[20:28:45] <BBB> uv just happens to take 2 :)
[20:29:47] <CIA-99> ffmpeg: alexc * r24274 /trunk/libavcodec/aaccoder.c: 10l: Add a missing const.
[20:30:27] <Dark_Shikari> BBB: dunno, whatever you want I guess
[20:30:35] <Dark_Shikari> mru: ok, I have some rage for you.
[20:30:39] <Dark_Shikari> some massive, massive rage.
[20:30:47] <mru> I don't need that
[20:30:51] <mru> but go on
[20:31:08] <Dark_Shikari> Matroska says that AR should be coded as pixel units (i.e. display resolution), not an AR.  This is kinda stupid, but it's not so awful.
[20:31:17] <Dark_Shikari> Haali did it wrong in his muxer in x264, as did some other software.
[20:31:24] <mru> of course it's stupid
[20:31:28] <Dark_Shikari> now that a Corecodec guy is making a validator
[20:31:31] <Dark_Shikari> they're going around and fixing stuff.
[20:31:34] <Dark_Shikari> So, now for the rage-inducing part.
[20:31:35] <mru> what does it even mean?
[20:31:55] <Dark_Shikari> He says there's an easy solution for the AR problem
[20:32:03] <Dark_Shikari> Just add another unit type in the spec and tell the muxer to use that instead!
[20:32:07] <Dark_Shikari> Bam, problem solved!
[20:32:11] <Dark_Shikari> (a unit type == normal AR units)
[20:32:11] <mru> aspect ratio should be specified either as pixel aspect ratio or display aspect ratio _in physical size_
[20:32:20] <Dark_Shikari> yes that's what I mean
[20:32:22] <Dark_Shikari> e.g.
[20:32:24] <mru> what happens if you have non-square pixels
[20:32:24] <Dark_Shikari> "1920:1080" is the AR
[20:32:25] <bcoudurier> hey guys
[20:32:30] <Dark_Shikari> thats what I mean by pixel units
[20:32:36] <mru> specifying DAR in pixels makes no sense
[20:32:37] <Dark_Shikari> "1920:1080" means "display the video as 1920x1080"
[20:32:40] <Dark_Shikari> anyways
[20:32:44] <Dark_Shikari> the rage-inducing part
[20:32:45] <bcoudurier> is int array[5] = {} non standard ?
[20:32:50] <Dark_Shikari> "let's just change the spec!"
[20:33:01] <Dark_Shikari> bcoudurier: why {}?
[20:33:05] <bcoudurier> init to 0
[20:33:07] <mru> bcoudurier: I read the spec carefully, and it seems it's actually not
[20:33:10] <Dark_Shikari> use {0}
[20:33:28] <Dark_Shikari> mru: so in short, the corecodec solution to any mkv issue
[20:33:30] <Dark_Shikari> is to change the spec
[20:33:36] <bcoudurier> another mkv issue ?
[20:33:39] <bcoudurier> :)
[20:33:40] <mru> typically corporate
[20:33:58] <Dark_Shikari> and their excuse is "oh it's just a draft"
[20:34:04] <Dark_Shikari> so even in 2010, they're still changing the fucking spec
[20:34:08] <Dark_Shikari> even though the format is already in wide use
[20:34:12] <Dark_Shikari> it's like the microsoft word of video formats
[20:34:42] <mru> I can write a rant about it if you like...
[20:34:56] <Dark_Shikari> then there was the
[20:34:59] <Dark_Shikari> Block -> SimpleBlock thing
[20:35:03] <bcoudurier> what does C99 say ? That the initializer list cannot be empty ?
[20:35:09] <mru> the old way was bloody annoying
[20:35:11] <mru> bcoudurier: yes
[20:35:17] <bcoudurier> ok
[20:35:39] <mru> it's quite clear from the grammar spec in annex A
[20:35:43] <bcoudurier> told mkv wasn't a good idea
[20:35:46] <bcoudurier> told you
[20:36:14] <mru> at least mkv tried to solve an actual problem
[20:36:28] <mru> unfortunately they tried to solve too many problems
[20:36:33] <mru> without fully understanding them first
[20:36:52] <bcoudurier> the real problem was subtitles
[20:36:56] <bcoudurier> they indeed fixed it
[20:37:02] <mru> the real problem was AVI
[20:37:06] <mru> and they fixed that too
[20:37:15] <mru> but they had no fucking clue about container design
[20:37:26] <mru> like how to make it codec-agnostic
[20:37:35] <bcoudurier> well avi is still widely used
[20:37:41] <Yuvi> Dark_Shikari: it'd work if they redefined the meaning without the new element as "aspect ratio" since that's what all players treat it as anyway
[20:37:47] <bcoudurier> narutoverse do h264 in avi for example
[20:37:50] <mru> all the codecs supported in the first versions use completely different header syntax
[20:37:54] <mru> that must be parsed
[20:38:19] * elenril thinks  people releasing avi now should be shot
[20:38:31] <bcoudurier> avi has the most widespread support
[20:38:33] <mru> Yuvi: all players being broken is no excuse for making a broken format
[20:38:43] <bcoudurier> and avi has technically the most used code path
[20:38:57] <peloverde> Just register an official vorbis mapping for mp4 and be done with it :)
[20:38:58] <bcoudurier> since it's there since way more time than mkv
[20:38:58] <Yuvi> mru: no, but giving up and codifying what players do anyway doesn't seem so bad to me
[20:39:54] <elenril> => we should use old crappy formats because our fathers and grandfathers used them?
[20:40:19] <mru> these condoms were good enough for my father, they are good enough for me!!!
[20:41:29] <peloverde> people also need to stop releasing in xvid, just because it's SD content doesn't mean you have to use a Part2 codec
[20:41:55] <mru> people should stop being idiots
[20:43:10] <BBB> Yuvi: http://ffmpeg.pastebin.com/D8ihT70h ok for the vp8dsp.c/vp8.c part?
[20:43:29] <Yuvi> maybe_inline?
[20:43:40] <BBB> it's a macro argument
[20:44:17] <BBB> also, Dark_Shikari suggested I rename filter8/16 to filter16y or filtery and filter8uv or filteruv, what's your take on it?
[20:46:16] <peloverde> Should Audacity be added to projects? FFmpeg is an option plugin
[20:46:22] <peloverde> *optional plugin
[20:46:56] <Yuvi> does inlining help for C chroma?
[20:48:01] <Yuvi> OK otherwise
[20:50:15] <Yuvi> and imo filter_luma / filter_chroma
[20:50:52] <mru> BBB: have you noticed vp8 fate tests are failing on anything using the yasm code?
[20:55:29] <lu_zero> uhm?
[20:56:00] <mru> http://fate.multimedia.cx/index.php?build_record=263514
[21:23:49] <BBB> I use the yasm code?
[21:24:17] <BBB> weird
[21:24:34] <BBB> which commit broke it?
[21:25:01] <mru> don't know
[21:25:04] <mru> something today
[21:25:54] <BBB> 24270 broke, 24267 is ok
[21:26:10] <BBB> hm...
[21:26:12] <BBB> wth
[21:27:25] <BBB> I suppose 64-bit only then?
[21:27:37] <BBB> x86_32 / linux uses yasm, right?
[21:27:39] <BBB> that one works fine
[21:27:48] <BBB> apparently I broke x86-64 with one of my patches
[21:28:07] <g0th> hi
[21:29:16] <mru> fix it
[21:29:20] <BBB> working on it...
[21:29:26] <g0th> I am the owner of a motorola milestone running android (2.1). There is now an application available by the name "Rock player" which seems to be using ffmpeg code. They charge money to get the advertisement free version. At first glance I dont see any source code on their website. I am not sure: Is this legal?
[21:30:15] <g0th> If it is not I hope someone will write them an email...
[21:31:36] <lu_zero>   g0th please fill all the details on roundup
[21:32:35] <g0th> can someone please tell me what roundup is?
[21:32:50] <g0th> I suppose bugtracker
[21:33:03] <g0th> hmm it counts as a bug?
[21:33:08] <mru> roundup.ffmpeg.org
[21:33:13] <g0th> I am not even sure if it is illegal.
[21:33:14] <g0th> ok thanks
[21:33:20] <mru> we know of rock player already
[21:33:30] <mru> and yes, they use ffmpeg
[21:33:37] <mru> illegally
[21:33:44] <g0th> did you write them?
[21:33:54] <mru> not me personally
[21:33:59] <mru> I don't know if someone else did
[21:34:45] <g0th> ok this is kind of my request: Can someone from this project write them please and pursue legal actions if they dont change anything?
[21:35:16] <mru> they're in china, nothing we can do
[21:35:29] <mru> we can try to get the app pulled from the market
[21:35:31] <g0th> reject their inclusion in appstore
[21:35:41] <g0th> yes
[21:35:50] <g0th> this would force them to change it
[21:36:22] <CIA-99> ffmpeg: rbultje * r24275 /trunk/libavcodec/x86/vp8dsp.asm: Attempt to fix x86-64 testsuite on fate.
[21:36:25] <g0th> If I were them I would just release the source code and still charge for the software
[21:36:33] <Dark_Shikari> oh, you broke x86_64?
[21:36:36] <Dark_Shikari> gj BBB ;)
[21:36:51] <BBB> wonderful right?
[21:36:56] <BBB> should be fixed now
[21:38:00] <Honoome> BBB: http://tvtropes.org/pmwiki/pmwiki.php/Main/NiceJobBreakingItHero :P
[21:45:28] * BBB awaits fate's verdict
[21:46:46] <mru> passes here
[21:46:49] <mru> thanks
[21:48:24] <twice11> Vitor1001: You were worried about the "loop expansion" I suggested for MOD data.
[21:48:43] <Dark_Shikari> BBB: so, we have chroma now.  mbedge next?
[21:48:52] <BBB> no I'm doing sse2 chroma first
[21:48:54] <twice11> If you want to have manageable complexity of the BSS, you can't represent every format pecularity in the BSS.
[21:48:55] <Dark_Shikari> oh ok
[21:48:56] <BBB> otherwise the whole thing is pointless
[21:48:59] <Dark_Shikari> didn't know you did sse2 already
[21:49:02] <Dark_Shikari> er, didn't do
[21:49:08] <BBB> it requires actual code ;)
[21:49:20] <BBB> (for the vertical filter)
[21:49:29] <Dark_Shikari> btw, for vertical
[21:49:32] <Dark_Shikari> movq / movhps
[21:49:34] <Dark_Shikari> are your gods
[21:49:43] <BBB> I was going to look for those :-p
[21:49:48] <BBB> thanks ;)
[21:49:54] <BBB> that's indeed the only code I need
[21:50:20] <twice11> So as far as I can imagine, you either have the BSS being tailored to one tracker format or you loose information on the round-trip tracker->BSS->tracker.
[21:50:29] <Dark_Shikari> or more exactly
[21:50:30] <Dark_Shikari> movh/movhps
[21:50:52] <BBB> movh sounds about right, yeah
[21:53:07] <Vitor1001> twice11: At least, I don't want to degrade information in the conversion tracker->BSS->player
[21:53:56] <twice11> This wouldn't prevent expanding loops on tracker->BSS, as far as I can see.
[21:54:37] <twice11> And I consider loop expansion to be part of the format specific processing (e.g. MOD provides an quite unknown "repeat reverse" instruction)
[21:57:24] <Vitor1001> Something to think about
[21:57:32] <Vitor1001> Well, I'm going to sleep now
[21:57:35] <Vitor1001> bye
[21:57:58] <twice11> Vitor1001: good night
[22:15:26] <BBB> fate is fixed?
[22:15:29] <BBB> at least for stuff I broke
[22:15:39] <_av500_> fate is inevitable
[22:15:41] <mru> now please fix the rest
[22:16:11] <BBB> I fixed it!
[22:16:16] <BBB> what else is there to fix?
[22:16:26] <mru> the other fate errors :-)
[22:16:39] <BBB> not my fault :-p
[22:16:52] <BBB> they shouldn't create so many weird cpu-related devices
[22:16:59] <mru> that's not a prerequisite for fixing it
[22:17:16] <mru> cpu-related devices?
[22:17:58] <Dark_Shikari> I really like michael's approach to the mod question
[22:18:13] <Dark_Shikari> mod is a compressed PCM sound format
[22:18:20] <Dark_Shikari> using a matching-pursuits coding method.
[22:18:59] <BBB> mru: "thingy that looks like a cpu"
[22:19:07] <BBB> like sparc, or x86-64
[22:19:09] <mru> like x86?
[22:19:18] <BBB> I own a x86, so it's a cpu
[22:19:19] <kierank> "dont forget that we would like to be able to store mod in avi/mp4/nut" --> that doesn't sound good
[22:19:34] <mru> but can we store it in a bikeshed?
[22:19:47] <BBB> let's rename nut to bikeshed
[22:19:52] <twice11> we need a mod->bike converter.
[22:21:01] <_av500_> we need a shedalizer
[22:21:20] <twice11> I don't think you really want to store "MOD" in avi/mp4/nut, but some kind of sequenced music might make a lot of sense.
[22:22:47] <twice11> The inevitable question is how to store the quite big "decompression context" data in the containers. For sequenced music, the whole sample data of the different "instruments" are static context.
[22:23:12] <_av500_> extradta
[22:23:26] <twice11> I mean in the file, not in memory.
[22:24:14] <twice11> For wav I know that there is some kind of codec specific additional data, but I don't know whether programs are prepared to handle megabytes in there.
[22:24:45] <_av500_> we can always store it in an id3tag like mp3 lossless...
[22:24:49] <mru> if they want to play that kind of audio, they'd better
[22:25:15] <mru> mp3 lossless? wav in id3 tag or what?
[22:25:23] <_av500_> yes
[22:25:31] <mru> people do that?
[22:25:32] <_av500_> wav-mp3 in id3tag
[22:25:40] <_av500_> thomson proposed it
[22:26:05] <_av500_> my mp3 parser handles it
[22:26:09] * BBB kicks his sse2 H chroma inner filter b/c it doesn't work
[22:26:13] <_av500_> it ignores it successfully
[22:26:21] <kierank> isn't mp3pro in id3 tags?
[22:26:42] <_av500_> no
[22:26:51] <_av500_> pro is in private data
[22:27:03] <_av500_> user data
[22:27:10] <mru> ancillary data?
[22:27:17] <_av500_> yes
[22:27:21] <mru> bit bucket!
[22:27:31] <_av500_> frame lenght - bits used
[22:28:15] <_av500_> but since length is limited, they could not store the lossless residual there
[23:20:58] <CIA-99> ffmpeg: bcoudurier * r24276 /trunk/libavformat/oggenc.c: In ogg muxer, free dyn allocated buffer, fix memleak
[23:20:59] <CIA-99> ffmpeg: mstorsjo * r24277 /trunk/libavformat/ (aviobuf.c avio.h): url_fskip: Return an error code if the url_fseek failed
[23:31:28] <pjay_> hi all !
[23:31:50] <pjay_> anyone knows about mmst.c ? i'm having problems with it, trying to debug it.
[23:32:23] <CIA-99> ffmpeg: mstorsjo * r24278 /trunk/ (doc/APIchanges libavformat/avformat.h): Bump minor and add APIchanges entry for url_fskip return value change.
[23:32:48] <kierank> pjay_, ask BBB when he returns
[23:33:31] <pjay_> kierank thanks for the tip.