[FFmpeg-devel-irc] IRC log for 2011-02-22

[irc at mansr.com]

[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 at 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 at mansr.com>
[00:19:49] <CIA-15> ffmpeg: Alex Converse <alex.converse at 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 at 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 at 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 at 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.html