[00:10:42] <BBB> kurosu: ping, what was the avg workaround? [00:11:03] <BBB> Dark_Shikari: or maybe you know, is there a quick way to get (a+b)>>1 without losing the 17th bit? [00:11:27] <mru> if you have an avg instruction, sure [00:11:39] <BBB> avg is (a+b+1)>>1 [00:11:50] <BBB> want (a+b)>>1 and (a-b)>>1 [00:11:52] <mru> right, x86 is stupid and has only one of them [00:12:53] <Yuvi> (a+b)>>1 == ~(~a+~b+1)>>1 [00:13:45] <Yuvi> dunno (a-b)>>1 off the top of my head [00:16:41] <CIA-15> ffmpeg: Tony Strauss <tony@animoto.com> master * r6c065f0acd ffmpeg/libavformat/mpegtsenc.c: [00:16:41] <CIA-15> ffmpeg: mpegtsenc: use correct PES stream_id for AAC [00:16:41] <CIA-15> ffmpeg: This adds the AAC codec to the list of audio codecs that results [00:16:41] <CIA-15> ffmpeg: in a PES stream_id of 0xc0 (audio stream). [00:16:41] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans@mansr.com> [00:19:49] <CIA-15> ffmpeg: Alex Converse <alex.converse@gmail.com> master * r203df50d10 ffmpeg/version.sh: Remove old VCSs from version.sh [00:22:34] <Dark_Shikari> BBB: ask pengvado ,he knows this stuff [00:22:48] <Dark_Shikari> or check the "SIMD without SIMD" post on michael's blog [00:23:03] <mru> when will intel come to their senses and add non-rounding avg? [00:24:49] <iive> i though they already have round [00:25:19] <mru> yes, but not non-rounding [00:28:03] <peloverde> Is it just me or is patchwork stuck? http://git.ffmpeg.org/?p=ffmpeg.git;a=shortlog [00:42:20] <CIA-15> ffmpeg: Young Han Lee <cpumaker@gmail.com> master * re22910b21a ffmpeg/libavcodec/ (aac.h aacdec.c): [00:42:20] <CIA-15> ffmpeg: aacdec: Reduce the size of buf_mdct. [00:42:20] <CIA-15> ffmpeg: It was doubled in size for the LTP implementation. This brings it back [00:42:20] <CIA-15> ffmpeg: down to its original size. [01:06:36] <BBB> Yuvi: thanks [01:17:58] <BBB> next question, how do I ~ in x86 simd? [01:18:06] <BBB> I know pandn, but there's no pnot [01:18:40] <Dark_Shikari> not is just a xor with all 1s [01:18:51] <Dark_Shikari> all 1s can be gotten via pcmpeqb xmm0, xmm0 [01:22:12] <Compn> BBB : btw i think maintainers is a good file in case someone wants to work on said file and maybe needs some help with it [01:22:28] <Compn> but if all those names correspond with copyrights in the files , then its probably duplicate [01:22:48] <BBB> Dark_Shikari: ah ok [01:23:26] <Compn> BBB : and if you frame the discussion like that i'm sure more people would understand. since i think maintainers was around before Diego fixed all the license and copyright headers ;) [01:25:46] <BBB> Dark_Shikari: lots of extra instructions though :( [01:25:55] <BBB> I'll see what I can prevent by doing various things [01:26:23] <Dark_Shikari> fuck mmx [01:26:45] <BBB> pengvado: any ideas on a quick way to accomplish (a-b+1)>>1 without losing the 17thbit? ideally without having to do xor mm, and then psub mm, b followed by pavgw [01:26:58] <Dark_Shikari> are a and b int16_t or uint16_t? [01:27:05] <BBB> int16_t vector [01:27:18] <BBB> oh wait was pavgw unsigned? [01:27:24] <Dark_Shikari> yes [01:27:37] * BBB curses [01:27:39] <Dark_Shikari> (a-b+1)>>1 can be signed, there's your problem [01:27:41] <Dark_Shikari> the output can be 17-bit! [01:27:49] <Dark_Shikari> i.e. 16 bits + 1 sign bit [01:27:59] <BBB> yes [01:28:01] <Dark_Shikari> i.e. (0-65535+1)>>1 [01:28:24] <Dark_Shikari> =-32767 ... oh wait [01:28:25] <Dark_Shikari> it fits. [01:28:38] <BBB> (-65536-65535+1)>>1 [01:28:39] <BBB> ? [01:28:41] <BBB> well anyway [01:28:44] <Dark_Shikari> You said [01:28:45] <Dark_Shikari> your inputs [01:28:46] <Dark_Shikari> are unsigned [01:28:52] <Dark_Shikari> -65536 isn't an int16_t or uint16_t [01:29:01] <BBB> the inputs are signed [01:29:03] <BBB> everything is signed [01:29:14] <Dark_Shikari> But you said pavgw... [01:29:19] <BBB> I know, I'm stupid [01:29:26] <BBB> I have a problem here [01:29:32] <BBB> I'm stupid _and_ it doesn't fit [01:29:45] <Dark_Shikari> -65536 is not an int16_t [01:29:48] <BBB> true [03:02:06] <BBB> mru: ping, so I'd really like to see how you did this, because I'm going through the spec and I can't figure out how to do it; regardless of instructions, the range of numbers from 12-bit input (8.1.3.9) gets to 18 bit for the first part already, then >>3 = 16 bit, and then up to 23 bit for the second part (right before the >>= 7, which makes it 16 again) 23 bit never fits in a word, no matter how fantastic your instruction set is at rounding o [03:02:06] <BBB> non-rounding [03:02:46] <Yuvi> neon has (a-b)>>1, (a+b)>>1, (a+b+1)>>1 on signed and unsigned 8 to 32 bit values [03:03:01] <Yuvi> oh 23 bits [03:03:08] <BBB> he said he wrote it in words, I wonder if he wrote it in dwords [03:03:48] <Yuvi> well, output range beyond 9 bits signed doesn't matter [03:04:04] <Yuvi> since you're adding + saturating to 8 bits unsigned [03:05:26] <BBB> if you do a lot minis a lot, the outcome in the scale [0,255] depends on how much a lot each of the two operands was :-p [03:05:33] <BBB> minis=minus [03:05:52] <BBB> if one is 1000 and the other is 1500, then the outcome is 0 [03:05:56] <BBB> inverse the outcome is 255 [03:05:56] <Yuvi> aren't you adding to 8 bits unsigned? [03:06:13] <Yuvi> or is there more to vc1? [03:06:29] <BBB> it's not an add [03:06:31] <BBB> it's a put [03:06:35] <BBB> (mostly) [04:53:40] <saintdev> peloverde: any suggestions for another name for the "constant part" of the pe calculation? [04:54:13] <peloverde> not off the top of my head [04:55:14] <saintdev> i can't think of a good one, and calling it "constant" is very non-descriptive :( [05:18:48] <peloverde> fixed [05:25:01] <peloverde> as in fixed vs variable [05:28:03] <saintdev> band->fixed band->fixed_part band->pe_fixed [05:28:06] <saintdev> hmm, not sure i like those any better, lol [05:29:45] <saintdev> but it's shorter, lol [05:36:11] <peloverde> i think band->pe_fixed is okayish [05:37:45] <saintdev> yeah i thought so also, but then i realized it also was the worst because it could also mean the 'corrected' pe [05:38:08] <saintdev> stupid english ambiguity [05:38:26] <peloverde> band->pe_nonvolatile [05:38:34] <peloverde> lol [05:39:00] <saintdev> lol [05:39:34] <dalias> is this a flag? [05:41:56] <saintdev> dalias: no, it's the constant pre-calculated part of the pe calculations [06:12:28] <saintdev> peloverde: band->pe_static [06:15:19] <peloverde> that might be confused with noise substitution or some other nonsense [06:15:27] <peloverde> band->pe_const? [06:16:03] <saintdev> that's what i have now, lol [06:16:08] * saintdev stabs english [06:18:02] <dalias> :) [06:35:24] <thresh> moroning [06:35:57] <kshishkov> whew, the things are as usual again [06:36:16] * kshishkov is undecided about morning though [06:37:35] <thresh> what do you expect on a friday anyway [06:40:26] <kierank> erm [06:44:53] <kshishkov> thresh: here it's tuesday already [06:46:58] <thresh> kshishkov: but tomorrow's a holiday here [06:47:06] <thresh> so that automatically turns tuesday to a friday [06:49:09] <thresh> а каждую пятницу я в говно и далее по тексту [06:49:51] <kierank> is there any generic "syncword search" code in ffmpeg? [06:50:05] <kierank> or does each codec do it by itself [07:10:42] <kurosu> BBB: specs (s421m.pdf) says contents after first pass (whether vertical or horizontal) must be within [-4096;4095] ("signed 12bits range"), and that's after the >>3, so the specs guarantee that intermediates fits within the intended 16bits range [07:12:23] <kurosu> hum, but for 2nd pass, it says range [-512;511]... that doesn't fit [07:12:52] <kurosu> however, that's an idct, why would it output that range in the end? [07:13:30] <kurosu> that's a residual, it should at worst be within [-255; 255] [07:14:04] <kurosu> anything below outside doesn't matter as it will get truncated when going back from residual to pixel domain [07:14:14] <kurosu> s/below// [07:15:39] <kurosu> however, the guarantees provided by this spec are a bit dubious... how do they do that at the encoder? clamp the intermediates after each pass of the fdct ? [07:17:56] <kurosu> (oh my, so many grammar errors, i guess i should have waited for my coffee) [07:21:28] <kurosu> I agree with Yuvi about last pass output [07:22:44] <kurosu> I'm looking at Annex A, section 1 and the range for E and R matrices [07:25:14] <kurosu> if we read pessimistically it, the limitations about range for E and R could only mean that, whatever the result of a pass, it gets clamped before being output to either E and R [07:25:56] <kurosu> that doesn't help us, as there's wraparound when you do your 16bits SIMD arithmetics [07:32:04] <Yuvi> add/sub can be saturated but mul can't in SSE [07:32:33] <Yuvi> it does help because if you assume 10bit signed output, t1-t8 can be saturated to 16 bits signed in the second stage [07:33:23] <Yuvi> regardless of whether the encoder really guarantees 12-bit signed input to the second stage [07:35:57] <mccoffein> good morning [07:36:10] <kierank> hello [07:37:21] <cartman> moin [07:44:20] <Yuvi> or actually, BBB was right, if you have e.g. (32896-32768+1)>>7 then saturating them to 32767 before that is wrong... [07:48:10] <Yuvi> still, even [-4096,4095] into the 2nd pass means for 19 bit intermediates, at which point it's possibly faster to just pmaddw to 32 bits and not worry about it [07:50:46] <siretart> god moroning! [07:53:17] <andoma> hello [08:45:39] <cartman> https://twitter.com/#!/djrbliss/status/38238822072451072 [08:45:40] <cartman> uh oh [08:46:15] <spaam> höhö [08:46:37] <kierank> someone tweet back using the official ffmpeg account: "yeah we know. what's the big deal?" [08:48:17] <kshishkov> "breaking Mozilla's FFmpeg - impossible" [08:50:36] <superdump> i wonder who djrbliss is anyway [08:50:43] <superdump> dan rosenberg... [08:50:44] <superdump> hmmm [08:50:48] <cartman> superdump: some 0day guy [08:51:06] <superdump> ah, ok [08:51:15] <kshishkov> superdump: why should you care? [08:51:56] <superdump> curiosity [09:39:42] <kshishkov> mate! [09:39:52] <kshishkov> where are Bink-d samples? [09:39:53] <pross-au> comrade! [09:40:14] <pross-au> Good question. Can you lobby Vag to tell us where they are! [09:41:27] <kshishkov> I suspect they just don't exist at all [09:41:55] <pross-au> He's got a keen eye for these things [09:42:50] <kshishkov> well, I think it will be easy to add once samples and decoder appear [09:43:10] <pross-au> Yep [09:44:08] <pross-au> One can isolate it roughly [09:44:22] <pross-au> HOMM3 was released ~1999 [09:44:39] <pross-au> Diablo2 middle of 2000 [09:44:50] <pross-au> Somewhere between there [09:45:05] <kshishkov> VAG said that it was supposed to appear in MM7 or so [09:45:27] <spaam> kshishkov: do you have bink-c samples? [09:45:45] <kshishkov> spaam: I'm not sure if even RAD has them [09:45:52] <pross-au> Haha [09:48:13] <kshishkov> pross-au: BTW, can you look at http://shishkov.homeunix.net/0001-SMUSH-decoder-v0-and-1.patch and say why it has issues with some codec-37 files? [09:48:19] <kshishkov> pross-au: like http://samples.mplayerhq.hu/game-formats/la-san/dig/pigout.san [09:50:53] <pross-au> Okay. Give me a day or so [09:50:59] <kshishkov> take two [12:24:03] <CIA-15> ffmpeg: Benjamin Larsson <benjamin@southpole.se> master * r8f935b9271 ffmpeg/libavformat/isom.c: [12:24:03] <CIA-15> ffmpeg: Add more AVC Intra FOURCCs [12:24:03] <CIA-15> ffmpeg: Also change the comments a bit since the FOURCCs aren't specific to Flip4Mac [12:24:03] <CIA-15> ffmpeg: and different ones are used for 720 versus 1080 lines. [12:24:03] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [12:34:29] <Compn> ugggggg fourcc [12:36:11] <spaam> :D [12:36:16] <spaam> Fix it Compn ! [12:38:14] <kshishkov> spaam: it's not that, he's envious for not reporting them in first place [12:39:38] <spaam> kshishkov: haha [12:39:48] <spaam> Compn: where is that commit for mplayer? [12:39:48] <Compn> i mean ugh as in why is flip4mac putting h264 in avi ? [12:40:07] <spaam> why not? [12:40:15] <Tjoppen> Compn: mov actually [12:40:16] <JEEBsv_> because it likes the perverseness of it? [12:40:26] <Compn> Tjoppen : then its an isom tag not a fourcc [12:40:34] <Compn> er not a riff tag [12:40:36] <Compn> isom.c [12:40:42] <Tjoppen> tomato, tomahto [12:40:56] <Compn> well bcourdier hates it when you commit isoms to riff list ... [12:41:59] <Tjoppen> r8f935b9271 ffmpeg/libavformat/isom.c [12:42:14] <mru> for good reason [12:42:22] <Compn> doh [12:42:30] <cartman> fo(u)r CCs [12:42:33] * Compn cant read :) [12:42:52] <Compn> well then its not avi [12:42:59] <Compn> but why are they making more tags ? :P [12:43:12] <mru> because they can [12:43:16] <Compn> of course [12:45:30] <Tjoppen> baptiste supplied me with more by running strings on quicktime IIRC [12:45:42] <Tjoppen> but we don't have samples for those [12:46:01] <Tjoppen> like 10-20 of 'em [12:46:09] <Compn> using qt_tools would probably be easier... [12:46:20] <Compn> anyways if you have a list, share it and i'll keep my eyes open for them ;) [12:46:39] <Tjoppen> of course, this is nothing compared to MXF and its massive lists of ULs [12:47:15] <kshishkov> Tjoppen: just list all five invalid UL's and use codec autodetection otherwise ;) [12:47:47] <Tjoppen> uhm.. ah, right. some codecs have probe functions in lavf :p [12:52:01] <Tjoppen> which reminds me: there is still no way to probe pictures [12:52:23] <Tjoppen> although that might change in a week or two [13:08:20] <mccoffein> hy [13:34:09] <Tjoppen> why is ticks_per_frame required any more? can't the mpeg2video and h264 decoder just set time_base correecctly or am I missing something? [13:34:21] <mru> lol @ omx asm code [13:34:38] <mru> first they define a bunch of aliases for various registers [13:34:53] <mru> then every time they use one, they name the real register in a comment alongside [13:35:45] <kshishkov> probably it was company policy to use aliases but devs kept forgetting which register they were using [13:36:32] <mru> having many names for each one only makes things confusing imo [13:36:55] <Flameeyes> mru: company policy and usefulness in the same phrase would be an oxymoron [13:37:03] <thresh> oh god now hpux cc fcuked up the .d files [13:37:18] <thresh> every .d now contains "you have a demo, pay us bucks" [13:37:30] <mru> thresh: you might want to add specific rules for that compiler [13:37:41] <thresh> mru: sure [13:37:48] <kshishkov> mru: no need, compiler has added them already [13:37:59] <thresh> true, but somehow gmake chokes on those :( [13:38:25] <thresh> well actually it worked before that compiler started to whine about being a demo [13:38:33] <kshishkov> of course - just propose Stallman's creation to pay for something and you'll get the same reaction [13:40:03] <Flameeyes> kshishkov: you shouldn't be a developer if you want to make money! go work as a chaffeur intead! </stallman-troll-mode> [13:43:37] <wbs> mru: who's omx implementation is written in asm? [13:43:56] <mru> something from ARM [13:57:09] <Flameeyes> does it make me a bad developer if I fill in a technical document of UML diagrams to make it feel "beefier"? [13:57:26] <mru> yes [13:57:26] <kshishkov> yes [13:58:35] <Flameeyes> sigh :'( [14:23:32] <{V}> print it out single sided on cardboard, that should help making it feel beefier [14:23:53] <bilboed-tp> or print it on meat directly [14:24:22] <kshishkov> documentation el vaco? [14:28:58] <pJok> documentation el maco? [14:30:50] <kshishkov> nej, nötdokument [14:31:38] <bilboed-tp> we'd need a meating to figure out what to call it [14:32:37] <kshishkov> well, the cows with pigment forming printed pages on their sides would form the beefiest document ever [14:47:10] <pJok> kshishkov, nöttdokument? [14:47:46] <kshishkov> nötköttdokument (he wanted to make it fully beefed) [14:47:55] <pJok> ah yes [14:49:49] <uau> elenril: i think some of the scheduled deprecated API drops are too aggressive for a bump now [14:50:00] <uau> for example AVSampleFormat was only added a couple of months ago [14:50:23] <uau> yet SampleFormat is scheduled to be already dropped at the next libavcodec version bump [14:50:31] <mru> it's a trivial change in source code [14:50:42] <uau> that's not the point [14:50:56] <uau> the issue is not how easy it is to switch from one to the other [14:51:09] <mru> deprecations requiring actual work in the apps should have a longer cycle [14:51:15] <uau> but rather whether you can already depend on the new version being available everywhere that matters, and how hard it is to support both [14:51:23] <mru> for a simple search and replace a couple of months is plenty [14:51:39] <uau> you're viewing it from the wrong angle [14:51:51] <mru> of course I am [14:51:56] <mru> I'm talking with you [14:52:02] <mru> and therefore I am by definition wrong [14:52:05] <uau> sure it would be very easy for me to replace every use of SampleFormat in mplayer2 with AVSampleFormat [14:52:26] <kshishkov> uau: then please do it in advance [14:52:28] <uau> but that'd needlessly break it with new libavcodec versions [14:53:09] <uau> and as AVSampleFormat has only been added so recently you can't rely on it being available [14:54:43] <uau> kshishkov: do it in advance how? add version-specific defines in the code to automatically switch depending on libavcodec version? [14:55:06] <kshishkov> nope, rename it to AVSampleFormat [14:55:24] <uau> then compilation will break with all distro versions [14:56:33] <kshishkov> well, FFmpeg is not Debian you know [14:57:38] <uau> IMO it'd be a lot more reasonable to do a release with the new API first, then after that has been out for some time drop the deprecated version [15:04:32] <uau> so the issue is not just how easy/hard it is to switch from the old version to the new - what also matters is how easy it is to write one version of code that can be compiled against _either_ ffmpeg version without changes during a transition period when different versions will be in use [15:04:46] <uau> and if there is a major API/ABI bump then there will be such a transition period [15:41:55] <Flameeyes> uau: we agree that the _ABI_ bump needs to be done before release though? [15:42:35] <uau> yes [15:43:21] <Flameeyes> k then we're on the same page here [16:27:55] * elenril wonders what are people talking about on the ml [16:28:20] <_av500_> fflames? [16:28:34] <elenril> uau: the incompatibilities that were introduced recently can be postponed until the next big bump [16:29:07] <j-b> 'morning [16:29:11] <elenril> i'm not writing all those avio wrappers just to drop them after two weeks [16:30:02] <uau> elenril: well just make sure that's actually done for the already "scheduled" drops, like SampleFormat (AVSampleFormat added in november) [16:40:51] <elenril> bleh, new clang fails with --disable-optimizations [17:02:07] <mru> meh, who cares about that? [17:20:10] <Flameeyes> let me guess, there is no free to access posix specification? [17:33:19] <elenril> BBB: ping [17:33:32] <BBB> elenril: pong [17:33:48] <elenril> you busy? [17:33:51] <elenril> renames are waiting [17:33:56] <BBB> today is bad day [17:34:00] <BBB> I can try tonight [17:34:15] <elenril> ok, i'll do something else for now [17:34:24] <BBB> I don't like put_tag, but I'll take it for now since it's private [17:35:02] <BBB> fopen/close is probably fine [17:35:05] <BBB> didn't look at that one yet tbh [17:36:14] <elenril> i'm wondering what to do with av_url_read_seek [17:36:29] <elenril> not sure why is it even needed and why is it public [17:37:21] <wbs> elenril: it's needed to request a seek for e.g. rtmp [17:37:42] <wbs> which is visible to the demuxer as a flv bytestream, but is a seeking-capable protocol in itself [17:38:42] <elenril> can't it be done more automagically on the avformatcontext level? [17:39:26] <wbs> not really [17:40:11] <wbs> think of it as a magic file that produces an flv stream that you can play back, but you can also request it to seek to a certain point (given in seconds) [17:40:40] <wbs> ah, well, it perhaps can be lavf-internal yes, but still needs to be exposed to the demuxers in the URLContext layer [17:40:41] <uau> Flameeyes: there's a lot of posix stuff on opengroup.org at least (you didn't tell what exactly you were looking for) [17:42:15] <elenril> wbs: well my naive view would be that a client app calls seek(avformatcontext, timestamp) and lavf detects by itself that the URLProtocol supports this kind of magic and does TheRightThing [17:42:49] <wbs> elenril: yes, the user app in itself doesn't need to do it [17:43:08] <wbs> elenril: except if you for some reason use URLContext directly (but was that api going to be private for now?) [17:43:19] <wbs> elenril: it's all handled within the demuxers [17:44:33] <BBB> elenril: I'm all with you [17:44:38] <BBB> elenril: imo it should have been internal only [17:44:40] <in3xes> what is this? http://www.ffmpeg.org/doxygen/trunk/avformat_8h-source.html#l00239 [17:44:46] <BBB> elenril: e.g. mms can do that sort of stuff also [17:44:54] <elenril> well URLContext should be public [17:45:00] <elenril> so apps can write their own protocols [17:45:09] <elenril> err i mean URLProtocol [17:45:12] <BBB> elenril: but that rtmp guy was all over the place and insisted that this was the ONLY WAY___ and therefore it was to be or else hell and doom [17:45:34] <BBB> oh yeah did I mention I don't like that librtmp guy? [17:48:15] <Kovensky> you did, just now, at least :) [17:48:30] <Flameeyes> uau: was looking to point exactly at the specifications of posix mq :/ mq_overview only lists "conforming to POSIX.1-2001" [17:51:14] <mru> Flameeyes: http://pubs.opengroup.org/onlinepubs/9699919799/ [17:52:47] <Flameeyes> mru: is that the actual text or just a reference? 'cause the only stuff I've seen seem to be nothing more than the Np man pages :/ and it reaaaly makes me doubt of lu_zero's sanity if that's the only definition of mq [17:53:34] <mru> that's the full spec [17:53:49] <Flameeyes> okay I officially doubt of lu_zero's sanity now =_= [17:53:50] <Flameeyes> thanks mru! [17:54:44] <elenril> who's the librtmp guy? [17:54:52] <merbzt> hyc [17:55:00] <mru> he can be annoying [17:55:49] <merbzt> maybe not hyc then [17:57:56] <BBB> mru: any more comments on the FF_NETERROR patch? [18:00:50] <mru> fine with me [18:11:09] <in3xes> What is "AVProbeData" ? how should it be used ? [18:20:23] <BBB> in3xes: used to probe the filetype [18:20:32] <BBB> in3xes: load the first few bytes of a file in AVProbeData [18:20:48] <BBB> it'll tell you what type of file the data likely came from [18:24:28] <in3xes> Okay [18:57:47] <elenril> what's up with people decoupling bump and breaking compatibility [18:59:44] <mru> if you can't find a bikeshed, build one [18:59:52] <elenril> uau: major bump is by definition equivalent with breaking compatibility [19:00:01] <elenril> or did i misunderstand your mail? [19:00:29] <mru> whatever you say, uau will generally disagree [19:00:51] <mru> try it some time, a few days after he's said something, present it as your own idea and watch him pick holes on it [19:00:54] <mru> *in [19:04:31] <Flameeyes> elenril: you can bump and break the ABI, but keep a compatible API... [19:04:42] <Flameeyes> which is most likely the desired situation for 0.7 [19:05:16] <uau> elenril: the basic problem that needs addressing here is that not every distro/user will switch ffmpeg version at the same exact moment [19:05:42] <uau> thus it's a problem if updating your application to work with the new ffmpeg version necessarily breaks it with the old one [19:05:46] <elenril> Flameeyes: i think we want to break both now [19:05:54] <elenril> for things that were deprecated for a long time [19:06:06] <Flameeyes> elenril: for the things that were deprecated on 0.6, please go on :) [19:06:22] <Flameeyes> it's for the "new" stuff (i.e. stuff that wasn't deprecated at the ti me 0.6 was released) that I'd suggest keeping compatibility [19:06:27] <Flameeyes> at least source-level compatibility [19:06:34] <elenril> yeah, i think everybody agrees [19:09:14] <uau> elenril: so decoupling the bump and dropping old api is not so much a goal in itself; rather the goal is to only drop old API after a release containing the old API has been out for some time [19:09:37] <uau> and for other reasons it's desirable to do a bump _before_ release [19:09:43] <uau> does that answer your question? [19:09:52] <elenril> this was the idea since the beginning [19:09:59] <elenril> i don't understand where's the problem [19:10:07] <uau> s/release containing old API/release containing new API/ [19:10:45] <Flameeyes> elenril: I think the problem was BBB bringing up the "before or after?" question [19:11:05] <uau> elenril: well there's still stuff like "#define FF_API_OLD_SAMPLE_FMT (LIBAVCODEC_VERSION_MAJOR < 53)" in the sources [19:12:40] <uau> so current state of the sources at least doesn't yet match that "idea since the beginning" [19:12:57] <elenril> current state of the sources doesn't match many things [19:13:18] <elenril> those things should be fixed before bumping [19:14:37] <uau> elenril: and i don't think that there has been a widespread understanding/consensus that those would be changed before the bump [19:19:31] <elenril> sierra vmd audio? [19:19:33] <elenril> what's that? [19:21:32] <Kovensky> probably some 90s game codec [22:42:04] <ruggles> kshishkov: ping [23:21:37] <ubitux> bcoudurier: i expected http://roundup.ffmpeg.org/issue2246 with a few mp4 (from the same series) / Måns and Uoti have discussed the issue; do you need the irc log? could you have a look on it? [23:27:39] <ubitux> almost everything is said here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel-irc/2011-February/000260.ht...