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

[irc at mansr.com]

[00:57:53] <danielk22> How does everyone using MPEG as a base make sure there are no user_data collisions? Is there a registry? (I'm trying to clean up the MythTV CEA-608/708 caption decoding so it can be submitted upstream to ffmpeg).
[00:59:07] <danielk22> We're interpreting user data beginning with 0x05,0x02 as CEA-608 captions, but I can't find the spec for it.
[01:11:28] <bcoudurier> hi guys
[01:12:37] <Dark_Shikari> hi bcoudurier's onjoin script
[01:15:49] <DonDiego> http://lwn.net/SubscriberLink/382478/b5466c64dc29a115/
[01:15:57] <DonDiego> mru: reactions to your blog post about ogg
[01:28:05] <Kovensky> "Neither the popular MP4 nor Matroska container formats are well-suited for streaming (particularly live streaming)" <-- wat
[01:28:32] <Kovensky> what about mp4 fragments, and matroska works perfectly fine without an index
[01:30:51] <peloverde> Can ogg even do silverlight style "smooth streaming"?
[01:31:15] <Kovensky> "(for example, Matroska only recently added support for interleaving frames from different tracks)" <-- what
[01:31:54] <Dark_Shikari> Kovensky: hit him
[01:33:02] <Kovensky> I'm still trying to understand that comment, did he mean that matroska was a completely non-interleaved container format?
[01:33:57] <DonDiego> i have a feeling that almost nothing from that article is correct..
[01:34:00] <Kovensky> it's just too baffling (and if I understood correctly blatantly wrong) >_>
[02:09:19] <DonDiego> bcoudurier: btw, since the topic comes up repeatedly, what was the reason you never wanted to work on the overhead issue in the ogg muxer?
[02:09:50] <bcoudurier> did I say that ?
[02:10:27] <Dark_Shikari> DonDiego: respond with an article about how the author is an idiot? =p
[02:10:49] <DonDiego> the author is not an idiot
[02:11:04] <DonDiego> i think he just made an attempt to write a balanced summary
[02:11:28] <DonDiego> however, when the issue is not balanced, the middle ground is not always the correct position
[02:11:47] <DonDiego> bcoudurier: i remember some comments from you about the subject
[02:11:51] <bcoudurier> I've spent some time adapting a patch from david, but I did not finalize it
[02:12:16] <DonDiego> would it reduce muxing overhead?
[02:12:35] <DonDiego> monty keeps complaining
[02:12:46] <bcoudurier> yes, definitely
[02:12:59] <Dark_Shikari> DonDiego: well, if he's so horribly wrong
[02:13:03] <Dark_Shikari> he clearly has no idea what he's talking about
[02:13:14] <Dark_Shikari> which doesn't make him an idiot, but writing about a topic when you don't know what you're talking about _does_ make you an idiot.
[02:13:19] * Compn has evil thoughts of doubling ogg overhead
[02:13:53] <DonDiego> and then he goes on to turn the argument around by claiming that it's ffmpeg's fault and that ogg does not, in fact, have high overhead
[02:14:18] <DonDiego> bcoudurier: what about finishing that patch then?
[02:14:29] <DonDiego> it would be awesome for 0.6 :)
[02:14:40] <DonDiego> this reminds me..
[02:14:47] <DonDiego> yuvi has gone AWOL
[02:14:48] <bcoudurier> mp4 overhead is independant of interleaving
[02:15:09] <DonDiego> and his work blocks the 0.6 release
[02:15:32] <bcoudurier> I have better things to do currently unfortunately
[02:15:35] <DonDiego> Dark_Shikari: do you know if some of the ogg/theora/vorbis crashers you found might be exploitable?
[02:15:42] <bcoudurier> but this is certainly welcome
[02:15:48] <DonDiego> that's a pity
[02:15:57] <Dark_Shikari> last thing I had, yuvi was investigating
[02:16:03] <Dark_Shikari> :/
[02:16:22] <DonDiego> bcoudurier: remember, it's ffmpeg 0.6 "works with HTML 5" :)
[02:16:32] <bcoudurier> DonDiego, besides you have to limit the packing to have good seeking accuracy
[02:16:59] <bcoudurier> I don't remember ogg being part of html 5
[02:17:17] <bcoudurier> besides I'm not sure it's a good idea to go further on that road
[02:17:25] <kierank> through xiph blinkers ogg IS html5
[02:17:33] <Dark_Shikari> hmm.  I agree.
[02:17:35] <peloverde> Do we have a plan for 0.6? there is always a feature around the corner
[02:17:49] <Dark_Shikari> if anything, html5 is mp4
[02:17:56] <Dark_Shikari> given microsoft's announcement
[02:18:01] <bcoudurier> I think we should let the philosophers fight
[02:18:05] <DonDiego> bcoudurier: html 5 is both for the moment
[02:18:19] <DonDiego> that's the point of the release
[02:18:22] <Dark_Shikari> not really, html5 is canvas and all that
[02:18:24] <Dark_Shikari> nobody uses <video>
[02:18:26] <Kovensky> html5 is neither, until somebody picks one
[02:18:32] <DonDiego> we have top-notch support for both codecs
[02:18:55] <Kovensky> s/somebody/everybody/
[02:19:04] <bcoudurier> and many other :)
[02:19:16] <DonDiego> peloverde: we appear to have security bugs open, we cannot release with that :(
[02:19:22] <Dark_Shikari> what security bugs
[02:19:53] <peloverde> we always have "security" bugs open if you blindly call any crasher a security bug
[02:20:35] <Kovensky> how to crash ffmpeg: ffmpeg -i input.mkv -vcodec copy -acodec copy output
[02:20:43] <DonDiego> i'm not blindly calling a crasher a security bug
[02:20:44] <Kovensky> ok, it's not a crash, it's a "clean exit", but it's supposed to work :v
[02:20:59] <peloverde> What's the bug number?
[02:21:01] <Kovensky> (assuming the mkv has h264 video)
[02:21:07] <DonDiego> there is no bug number
[02:21:21] <DonDiego> umm, maybe there is
[02:21:39] <DonDiego> it was Dark_Shikari discovering some bugs with a fuzzer
[02:21:50] <DonDiego> and yuvi wanting to investigate
[02:21:55] <Dark_Shikari> I don't think I found any security bugs
[02:21:58] <Dark_Shikari> except possibly one in mkv
[02:21:59] <Dark_Shikari> which was fixed
[02:22:04] <Dark_Shikari> but I can't be sure
[02:22:09] <DonDiego> and a comment "uh, oh, this might be exploitable"
[02:22:09] <Dark_Shikari> but seriously:
[02:22:18] <Dark_Shikari> 1) there are tons of bugs in ffmpeg.
[02:22:19] <DonDiego> and that's why i'm asking..
[02:22:20] <Dark_Shikari> 2) tons crash ffmpeg.
[02:22:23] <Dark_Shikari> 3) a lot are security holes
[02:22:31] <Dark_Shikari> 4) we cannot get rid of all of them any time soon
[02:22:39] <Dark_Shikari> 5) anyone who wants to write an exploit for ffmpeg _or_ libtheora probably can.
[02:22:56] <Dark_Shikari> .... and this isn't a problem with ffmpeg per se
[02:22:59] <Dark_Shikari> Quicktime, for example, is even worse
[02:23:05] <Dark_Shikari> it has holes up the wazoo
[02:23:09] <DonDiego> all points conceded
[02:23:10] <Dark_Shikari> a friend of mine made it crash with about two bytes of input data
[02:23:15] <Dark_Shikari> potentially exploitably too
[02:23:23] <peloverde> There are a huge number of crashers not worth dealing with just because of the padding situation
[02:23:33] <Dark_Shikari> and yeah that
[02:23:42] <Kovensky> what padding situation?
[02:23:56] <bcoudurier> I don't understand the padding situation
[02:24:03] <DonDiego> but it's all slightly besides the point
[02:24:11] <bcoudurier> there should be a mode when it's being checked
[02:24:47] <DonDiego> what do you make of a comment "uh, oh, this might be exploitable, will check + fix" and then going AWOL?
[02:25:39] <Kovensky> he was kidnapped by a cracker that doesn't want the exploit to be fixed
[02:25:40] * Kovensky ducks
[02:25:53] <Dark_Shikari> anyways don't let me or yuvi block release.
[02:26:17] <bcoudurier> definitely
[02:27:07] <DonDiego> well, now you have said that it's likely not exploitable
[02:27:17] <peloverde> The padding situation is currently that on many codecs, ever read must be checked in to prevent segfaults
[02:27:29] <bcoudurier> how is that possible ?
[02:27:40] <DonDiego> i remembered a slightly different statement, so put yourself in my shoes
[02:27:55] <peloverde> we only use 8 bytes of input buffer padding
[02:28:15] <Dark_Shikari> ideally it should be codec-specific
[02:28:18] <peloverde> and most of that is for the bitstream reader itself
[02:29:20] <Kovensky> <@Dark_Shikari> ideally it should be codec-specific <-- that would prevent allocating buffers on stack
[02:29:24] <Kovensky> but I guess that's for the best ._.
[02:30:07] <bcoudurier> I don't remember so many problems related to padding before
[02:30:08] <peloverde> Kovensky: alloca
[02:30:11] <bcoudurier> suddently it's a big dea
[02:30:34] <peloverde> bcoudurier, a bunch of crashers were found with fuzzing tools
[02:30:55] <bcoudurier> AFAIK zzuff found a bunch as well
[02:31:07] <bcoudurier> and increasing padding was never considered
[02:31:21] <peloverde> those ones were fixed manually
[02:31:39] <peloverde> then a new batch cropped up, that can't be fixed without very invasive buffer checking
[02:31:40] <bcoudurier> or are you saying that aac is specific on this matter ?
[02:31:46] <peloverde> no, not just aac
[02:31:56] <bcoudurier> interesting
[02:32:12] <Kovensky> <@peloverde> Kovensky: alloca <-- oh, completely forgot about that func
[02:32:48] <bcoudurier> what codecs are particularly vulnerable
[02:32:54] <bcoudurier> or is it implementation related
[02:34:47] <peloverde> I would argue that for most codecs something could be generated at sufficient bitrate, particularly when VLCs are decoded in a speed critical inner loop
[02:35:17] <Dark_Shikari> measure the maximum size of a maliciously constructed block
[02:35:21] <Dark_Shikari> double it to make sure.
[02:35:30] <peloverde> indeed
[02:35:50] <peloverde> find the basic block size unit where checking is reasonable
[02:36:19] <peloverde> Then find the maximum size that block could be maliciously sized
[02:36:21] <bcoudurier> we are talking about audio right ?
[02:36:35] <peloverde> no, not just audio
[02:36:58] <peloverde> It seems perfectly reasonable that we could make crashes like these for video
[02:37:28] <bcoudurier> it seems mpeg2 decoder checks every dct coeefs
[02:37:43] <bcoudurier> I wonder how can this _ever_ crash
[02:39:08] <peloverde> that's because current buffering is designed around mpeg2
[02:39:27] <bcoudurier> here comes the design excuse ;)
[02:39:59] <peloverde> I've been told checking per-coef in AAC is unreasonable
[02:40:27] <bcoudurier> I don't know and you are the best to tell
[02:40:27] <peloverde> there is a fairly large family of codecs structured similarly to aac
[02:40:43] <bcoudurier> vorbis ?
[02:42:05] <peloverde> vorbis, wma
[02:43:49] <peloverde> we probably could get some speed gains out of mpeg2 if we checked at the block level and not the coef level
[02:44:11] <bcoudurier> well block index > 63 and boom
[02:45:35] <bcoudurier> anyway
[02:45:44] <bcoudurier> the code shouldn't fail padding or not
[02:46:00] <bcoudurier> I mean I'm pretty sure people using the libs don't know about padding :)
[02:46:24] <peloverde> then they risk crashing on valid streams
[02:46:29] <ohsix> or if they'll run out of "free frames" :>
[02:46:33] <peloverde> when the bitstream reader repopulates
[02:46:56] <bcoudurier> at the end of the frame you mean ?
[02:47:08] * Kovensky suggests making the max frame size define already include padding and having a real max frame size define with the old max frame size value
[02:47:28] <bcoudurier> we are talking about the input here
[02:47:41] <Kovensky> (or not making a "real max frame size" and instead subtract the padding define)
[02:48:14] * Kovensky was talking about library users
[02:48:21] <bcoudurier> I'd say add checks and fix the crash, a crash is worst than slowdown
[02:48:34] <bcoudurier> different subject ?
[02:48:44] <Kovensky> not very different, but yes
[02:48:52] <bcoudurier> input is kind of different
[02:48:53] <Kovensky> it's in response to <@bcoudurier> I mean I'm pretty sure people using the libs don't know about padding :)
[02:48:56] <Kovensky> =p
[02:49:06] <bcoudurier> that is not really padding, it's allocating
[02:49:10] <peloverde> or we could add a small amount of padding and have neither a crash nor a slowdown
[02:49:21] <bcoudurier> that is in every demuxer you must allocate more than needed
[02:49:35] <bcoudurier> if the demuxer does not, then you must realloc what it gives you
[02:49:55] <peloverde> we have a define for padding size
[02:49:59] <bcoudurier> I personally find that annoying, so I guess some users do as well
[02:50:08] <peloverde> it should be used when allocating buffers
[02:50:19] <bcoudurier> it's like the DECLARE_ALIGNED for audio output buffer
[02:50:24] <peloverde> when it's not used the user is breaking the API and all bets are off
[02:50:33] <bcoudurier> hopefully this will be changed when audio decoders use get_buffer
[02:50:56] <bcoudurier> yes
[02:51:02] <bcoudurier> I just find the API annoying
[02:51:07] <DonDiego> gnite
[02:51:20] <bcoudurier> does quicktime have padding constraints as well ?
[02:51:26] * Kovensky sleeps too
[02:51:30] <bcoudurier> gnite DonDiego
[02:51:37] <peloverde> av_malloc(size+FF_INPUT_BUFFER_PADDING_SIZE) is hardly annoying
[02:52:11] <peloverde> looking at mpeg2 I'm sure I can generate oob reads
[02:52:18] <bcoudurier> I'm more talking about people using other demuxers
[02:52:41] <peloverde> libavcodec is a lowlevel API, and the padding thing is documented
[02:52:54] <bcoudurier> yes
[02:53:06] <bcoudurier> I'm just telling you that it _is_ annoying to me
[02:53:26] <peloverde> then make a malloc macro
[02:53:29] <bcoudurier> and I'm not asking to change the API
[02:53:44] <bcoudurier> how clever
[02:53:46] <peloverde> and increasing the size shouldn't make it any more annoying than it already is
[02:54:33] <peloverde> unless you mean there are fewer cases where you can "get away with" abusing the API
[02:54:58] <bcoudurier> I say that small overread should not crash
[02:55:10] <bcoudurier> page is yours after all
[02:55:11] <peloverde> I agree
[02:55:24] <astrange> quicktime doesn't have anything about padding in the api
[02:55:31] <bcoudurier> see
[02:55:33] <astrange> if you need it you need to memcpy the input
[02:55:42] <bcoudurier> I find that better for the user
[02:55:43] <peloverde> I don't think we should be making design decisions based on what quicktime does
[02:55:58] <peloverde> (unless we are talking about apple codecs)
[02:56:00] <astrange> that quicktime api hasn't changed since 1990 though
[02:56:07] <bcoudurier> defintely not, but it gives you an idea about how other people do
[02:56:15] <peloverde> QtKit existed in 1990 ?
[02:56:28] <bcoudurier> besides I know for sure that many SDK does not require it either
[02:56:54] <peloverde> I'm guessing that those are vulnerable to buffer bugs
[02:57:04] <peloverde> or do wastful reallocs internally
[02:57:04] <bcoudurier> probably
[02:57:29] <bcoudurier> in short I believe the padding is not really an issue
[02:57:44] <bcoudurier> add checks, and we should be fine :)
[02:58:14] <peloverde> I've been told more than once that such checks would not be acceptable
[02:58:22] <peloverde> And I don't like them either
[02:59:11] <astrange> i'm about to write the quicktime bug report asking for padding so i don't have to memcpy
[03:03:24] <bcoudurier> you can code safe also
[03:04:14] <bcoudurier> peloverde, so no checks and no padding increase ? that looks like a dead end to me
[03:04:29] <peloverde> yes that is a dead end
[03:04:38] <peloverde> that is the current situation
[03:07:53] <bcoudurier> what's the plan then ?
[03:12:51] <peloverde> there is no plan
[03:13:44] <bcoudurier> how would you like to fix that ? be able to specify the padding size per codec ?
[03:21:24] <peloverde> that would seem sufficient
[03:21:36] <peloverde> (also I'm seeing illegal reads in mpeg-2)
[03:28:39] <bcoudurier> I guess adding .padding to AVCodec should be easy to do
[03:29:53] <bcoudurier> I'm off
[03:29:59] <bcoudurier> bye
[04:47:55] <peloverde> PS files decoding properly! what has the world come to!
[04:51:27] <pJok> peloverde, xiph being considered actual coders? ;)
[05:05:31] <jai> peloverde: nice
[05:05:35] <jai> peloverde++
[05:14:00] <peloverde> hmm... when the spec is ready literally, heirarchical backwards compatible PS seems impossible
[05:16:58] <saintd3v> peloverde: \o/
[05:25:21] <jai> ok superdump is here, lets do this one more time
[05:25:44] <jai> peloverde: nice work on PS support
[05:25:56] <superdump> :)
[05:26:05] <peloverde> it's not all done yet, i have the minimal case working
[05:26:14] <superdump> \o/
[05:26:16] <peloverde> but it means that I can work incrementally from this point forward
[05:26:33] <peloverde> which psychological is far better
[05:27:08] <superdump> i dunno
[05:27:21] <superdump> it's a psychological boost to get something working
[05:28:41] <peloverde> I always find writing big chunks of non-verifiable code frustrating
[05:28:49] <peloverde> and misunderstands propagate
[05:37:26] <thresh> morning
[05:37:32] <thresh> yeaah i did it right
[05:39:07] <jai> thresh: whoa
[06:05:23] <CIA-1> ffmpeg: alexc * r22816 /trunk/libavcodec/mpeg4audio.c:
[06:05:23] <CIA-1> ffmpeg: Fix ext_object_type.
[06:05:23] <CIA-1> ffmpeg: In the case of explicit non-backwards compible PS, the extension object
[06:05:23] <CIA-1> ffmpeg: type should be set to SBR. See 14496-3:2009 (fourth edition).
[06:05:23] <CIA-1> ffmpeg: alexc * r22817 /trunk/libavcodec/mpeg4audio.c: Use get_bits_left() in the sync extension check.
[06:05:24] <CIA-1> ffmpeg: alexc * r22818 /trunk/libavcodec/ (mpeg4audio.h mpeg4audio.c): Add support for PS sync extensions.
[06:09:26] <Dark_Shikari> wait holy shit, ps is already done?
[06:09:41] <kshishkov> no, those are only preparations
[06:09:44] <Dark_Shikari> ah
[06:10:06] <kshishkov> (but PS is already devised by those in corresponding comittee)
[06:12:03] <kshishkov> looks like the future of audio is SAOL-like - encode 8kHz mono sound and enhance it to 48kHz 5.1 with flags and parameters (and no real coded frequencies)
[06:13:23] <kshishkov> I'd call it "VP3 way", can't say why though
[06:14:20] <kierank> What's silly is trying to save bitrate by using he-aac for 5.1 in dvb-t2. save a few hundred kilobits/s yet use a crappy h.264 encoder nonetheless
[06:15:15] <kshishkov> it's an interesting paradox - audio takes less bits but is harder to compress
[06:16:05] <kierank> he-aac was deliberately pushed into the national standards because there's money to be made with stb licensing
[06:16:35] <kierank> but in my opinion the sbr ruins the sound anyway
[06:16:45] <merbzt1> well something better then layer2 was needed
[06:16:59] <merbzt1> but using sbr might not be to wise
[06:17:01] <kshishkov> and layer2 is better than layer3 IMO
[06:17:09] <kierank> aac at 256kbps or the like imo
[06:17:25] <kierank> svt is quite good though; ac3 at 640kbps
[06:17:48] <merbzt1> I guess at 5.1 also
[06:18:57] <Dark_Shikari> imo celt has the right approach for dealing with HF
[06:19:11] <Dark_Shikari> the energy-preserving VQ is just perfect
[06:19:17] <merbzt1> elaborate
[06:19:31] <kshishkov> cons: it will be in Ogg container
[06:19:34] <Dark_Shikari> 1) explicitly code the energy for each band
[06:19:40] <Dark_Shikari> (predicted based on the last packet's energy)
[06:19:45] <Dark_Shikari> normally costs 0-1 bits per band
[06:19:58] <Dark_Shikari> 2) the quantizer is a VQ calculated on the fly _such that_ energy  is preserved
[06:20:08] <Dark_Shikari> so no matter how you quantize the band, energy is conserved
[06:20:12] <Dark_Shikari> even if you quantize to zero
[06:20:22] <Dark_Shikari> this results in coding HF bands taking near-zero bits
[06:20:28] <Dark_Shikari> yet still sounding good
[06:20:53] <Dark_Shikari> basically it's the best of both worlds: you get the HE-AACness without _actually_ lowpassing it to 22khz
[06:21:03] <Dark_Shikari> so if there is real HF detail, you can code it
[06:21:35] <merbzt1> anyway VQ is awesome
[06:21:50] <Dark_Shikari> and yes that.
[06:22:11] <kshishkov> merbzt1: some video codecs authors have discovered that long time ago
[06:24:39] <Dark_Shikari> but unlike a normal VQ
[06:24:41] <Dark_Shikari> it's calculated on the fly
[06:24:48] <Dark_Shikari> i.e. if you actually made it into a table it'd contain a billion plus elements
[06:25:01] <Dark_Shikari> so it effectively searches a table that doesn't actually exist in full
[06:25:05] <superdump> so how does it work?
[06:25:10] <Dark_Shikari> there's a paper on it somewhere
[06:25:12] <Dark_Shikari> and a presentation
[06:25:28] <superdump> and what bit rates is celt intended for?
[06:25:41] <superdump> very low voice i'm guessing
[06:25:43] <Dark_Shikari> no
[06:25:46] <Dark_Shikari> stereo at ~64kbps per channel
[06:25:57] <Dark_Shikari> the main schtick is that it has extraordinarily small packet sizes
[06:26:00] <Dark_Shikari> and is hard-CBR
[06:26:07] <Dark_Shikari> so you can get 5ms latency
[06:26:19] <Dark_Shikari> http://www.celt-codec.org/presentations/ covers some of the math
[06:26:34] <Dark_Shikari> at least the xiph guys know how to do audio.
[06:26:49] <kshishkov> superdump: just think if channel supplied number of possible elements and decoder generated codes for all tuples (0..N-1; 0..N-1; ...)
[06:27:18] <Dark_Shikari> it's like a 50-dimensional VQ
[06:27:26] <kshishkov> Dark_Shikari: actually all Xiph guys did is Vorbis, everything else is acquired
[06:27:43] <Dark_Shikari> they're doing celt =p
[06:27:51] <Dark_Shikari> speex isn't that good.  silk beats the shit out of it
[06:28:06] <Dark_Shikari> largely because silk is an independently-developed Celt-alike
[06:28:12] <Dark_Shikari> except designed more for speech than music
[06:28:24] <CIA-1> ffmpeg: alexc * r22819 /trunk/libavcodec/aacsbr.c:
[06:28:24] <CIA-1> ffmpeg: Print an error and skip PS when PS is found but explicitly found but
[06:28:24] <CIA-1> ffmpeg: signaled to be absent.
[06:28:25] <CIA-1> ffmpeg: alexc * r22820 /trunk/libavcodec/aacsbr.c: Reindent read_sbr_extension.
[06:30:51] <superdump> there's low delay aac
[06:30:58] <superdump> not sure how low delay it is though
[06:31:06] <Dark_Shikari> not nearly that low
[06:31:14] <superdump> probably not
[06:31:14] <kshishkov> lossless AAC too
[06:31:17] <Dark_Shikari> celt does packet sizes down to like 128 samples
[06:31:29] <Dark_Shikari> at 256-sample packet size + 128kbps + stereo it's transparent to source for me
[06:31:37] <Dark_Shikari> which is really impressive, in large part because of transients
[06:31:46] <Dark_Shikari> hard CBR + small packet size + transients == AGHHHHHHH
[06:34:08] <andoma> do I sense a faint smell of AAC-PS?
[06:34:29] <kshishkov> not only you
[06:36:11] <peloverde> Is CELT bitstream frozen yet?
[06:36:17] <kshishkov> nope
[06:37:27] <peloverde> Then it seems like bad news that debian/ubuntu are packaging it
[06:39:05] <andoma> Dark_Shikari: does periodic intra refresh in h264 rely on a specific profile, or is it just a way of how MB types and frames are arranged?
[06:44:30] <Dark_Shikari> latter
[06:44:34] <Dark_Shikari> peloverde: lol, that's ridiculous
[06:44:37] <Dark_Shikari> they're changing the bitstream every week
[06:49:22] <Dark_Shikari> someone should whine to siretart about that
[06:59:28] <siretart> about what?
[07:01:33] <kshishkov> about including experimental software with unstable bitstream format into distributions
[07:01:39] <Dark_Shikari> Celt is apparently in ubuntu
[07:01:43] <Dark_Shikari> the bitstream format changes EVERY WEEK
[07:01:53] <Dark_Shikari> by the time the distro ships it already won't even do anything
[07:19:22] <Tjoppen> git svn clone seems to take quite some time. useful though
[07:27:38] <superdump> Dark_Shikari: quite an interesting video that
[07:28:05] <kshishkov> indeed
[07:31:45] <kierank> does seeking work in that video?
[07:32:03] <Dark_Shikari> it's ogg, what do you think the answer is ;)
[07:32:21] <kierank> lol it's garbled in srware iron
[07:33:27] <kierank> hmm works in firefox thogh
[07:33:30] <kierank> though*
[07:34:13] <kshishkov> so what? I think we can forget about Firefox in several years
[07:34:41] <kierank> half-working implementations are annoying
[07:36:52] <kshishkov> still better than no implementation
[07:50:03] <merbzt1> Tjoppen: you can clone from git.mansr.com
[07:50:34] <Tjoppen> ok. I'll try that
[07:51:26] <merbzt1> accoarding to peloverde dcommit works from that tree
[07:51:43] <peloverde> yes it does
[07:52:12] <Tjoppen> merbzt1: what's the full URI?
[07:53:00] <Tjoppen> oh, wait. /ffmpeg probably
[07:53:21] <Tjoppen> there we go
[07:53:41] <peloverde> git://git.mansr.com/ffmpeg
[07:54:15] <Tjoppen> yeah, git: seems a lot faster than http
[07:54:35] <peloverde> then do "git svn init -T svn://svn.mplayerhq.hu/ffmpeg"
[07:54:52] <peloverde> then "git update-ref refs/remotes/trunk origin/master"
[07:55:32] <wbs> what's the difference between mru's git-svn repo compared to the one on git.ffmpeg.org, that allows this to be done?
[07:56:01] <Tjoppen> the one on ffmpeg.org is read-only
[07:56:42] <wbs> ahem.. in which sense? you can't push to mru's repo either
[07:57:06] <Tjoppen> hm. good question
[07:57:20] <Tjoppen> maybe git.ffmpeg.org could be set up to automagically use git-svn somehow?
[07:57:32] <wbs> git.ffmpeg.org _USES_ git-svn
[07:57:55] <wbs> I'd like to know what's different in its setup that makes it impossible to do that trick on clones from that one
[07:58:13] <astrange> the svn url included in the commit message is different
[07:58:25] <peloverde> The svn url must match exactly
[07:58:38] <wbs> aah, I see
[07:58:43] <peloverde> git.ffmpeg.org was cloned with a file:/// url
[07:59:47] * peloverde shakes fist at valgrind
[08:00:27] <kshishkov> peloverde: non-linux OS is a best way against valgrind
[08:01:37] <av500> rpm -e valgrind works as well
[08:01:37] <peloverde> linux is the only OS I have that valgrind supports
[08:02:03] <kshishkov> av500: not on debian/ubuntu/slackware
[08:02:09] <kshishkov> peloverde: exactly
[08:02:19] <peloverde> I want to know WHY it thinks this value is uninitialized (and I tried --track-origins=yes)
[08:03:50] <peloverde> my problem is that valgrind is usually smarter than I, and I'm going to have to track down the same bug in gdb sooner or later if I don't fix it now
[08:04:31] <kshishkov> it prints line where value is used
[08:04:48] <kshishkov> so you can try matching its initialisation with access
[08:05:00] <peloverde> yes and all the values on that line seem properly initialized
[08:05:02] <kshishkov> i.e. if all indices are the same/whatever
[08:05:31] <peloverde> It tracks it backwards to a stack allocation at the top of the function, but doesn't tell me which one
[08:05:55] <astrange> it should be able to read debuginfo and give a line number
[08:06:18] <astrange> it could give more but the --read-var-info implementation never seemed to do anything for me
[08:06:40] <KotH> moin girls
[08:07:07] <kshishkov> KotH: wrong place for girls
[08:07:40] <KotH> well, i know of at least one confirmed girl who was in this channel
[08:07:45] <KotH> there ought to be more :)
[08:07:58] <kshishkov> one fluctuation is not a proof
[08:08:08] <twnqx> measuring error.
[08:08:18] <KotH> ^^'
[08:09:01] <KotH> Lasciate ogni speranza, voi ch'entrate!
[08:09:41] <kshishkov> Swiss Italian?
[08:10:33] <KotH> nope, italian italian
[08:14:24] <Tjoppen> time to commit my seek patch. ran tests for good measure, which still pass
[08:14:42] <Tjoppen> or rather, probe patch. I'll commit the seek patch later
[08:15:17] <kshishkov> whatever
[08:18:44] <pJok> Morgon, kshishkov
[08:19:00] <av500> gm
[08:20:06] <kshishkov> god morgon, pJok
[08:20:44] <pJok> Inte god idag ;)
[08:21:41] <pJok> Waiting at a hospital
[08:21:50] <kshishkov> oh
[08:21:59] <kshishkov> nothing serious I hope
[08:22:37] * kshishkov usuallly does not have enough health to go to local hospitals
[08:22:40] <pJok> Only minor surgery tomorrow, today is just preparation
[08:23:18] <kshishkov> good luck anyway
[08:24:08] <siretart> kshishkov: so you propose to remove x264 from ubuntu?
[08:25:08] <kshishkov> siretart: x264 produces into _stable_ bitstream format
[08:25:30] <kshishkov> CELT produces something that can't be decoded with any different version of CELT
[08:25:59] <siretart> what is celt?
[08:26:21] <kshishkov> siretart: next decent audio codec from Xiph
[08:26:29] <ohsix> except for 0.7.0 and 0.7.1
[08:26:55] <superdump> Version 0.7.1 has been released, with improvements to the packet loss concealment (PLC). It is the first release not to break bit-stream compatibility with the previous release (0.7.0). But I promise not to do it again, the next CELT release will likely break compatibility once again.
[08:27:14] <superdump> :)
[08:27:14] <pJok> What? Anything decent from xhiph? Unpossible
[08:27:59] <pJok> Xiph*
[08:28:02] <kshishkov> pJok: Vorbis is not bad per se
[08:28:17] <siretart> kshishkov: oh, you're talking about the 'celt' source package. that's taken unmodified from debian, and I hardly can take responsibility of all debian packages.
[08:28:33] <Dark_Shikari> superdump: they already broke it in trunk ;)
[08:28:38] <kshishkov> siretart: of course, we blame you only for multimedia packages
[08:28:38] <Dark_Shikari> twice.
[08:29:08] <siretart> kshishkov: I'd suggest to whine to 'submit at bugs.debian.org'
[08:29:19] <pJok> Who needs compliant bitstreams anyways...
[08:29:34] <siretart> kshishkov: I see. I haven't worked with ron so far
[08:30:16] <kshishkov> somehow Vorbis is the only good thing from Xiph so far
[08:31:04] <pJok> Shame it is in a silly container
[08:31:07] <peloverde> cdparanoia, flac?
[08:31:12] <Dark_Shikari> flac isn't from xiph
[08:31:15] <Dark_Shikari> clet is good though
[08:31:17] <Dark_Shikari> *celt
[08:31:27] <peloverde> flac is xiph now
[08:31:36] <ohsix> its actually the speex guy
[08:32:27] <kshishkov> peloverde: cdparanoia is good but it has nothing to do with the rest of Xiph business
[08:32:48] <Dark_Shikari> peloverde: it isn't as if it got better after it was adopted by xiph
[08:32:55] <Dark_Shikari> ffmpeg's encoder and decoder are still better
[08:33:18] <kshishkov> Dark_Shikari: but we got Flac-in-Ogg then!
[08:33:27] <peloverde> <Dark_Shikari> peloverde: it isn't as if it got better after it was adopted by xiph <-- you could say the same thing about theora ;)
[08:34:47] <Dark_Shikari> Oh, but it did
[08:34:51] <Dark_Shikari> have you SEEN On2's VP3 encoder?
[08:34:56] <Dark_Shikari> it was hilariously awful
[08:35:01] <Dark_Shikari> the dct and idct didn't even match
[08:35:29] <av500> nitpicker! :)
[08:35:36] <Dark_Shikari> woohoo, just wrote my first multipass optimizing compiler
[08:35:51] <Dark_Shikari> ... for a toy language. but hey
[08:36:20] <av500> ffcc ftw!
[08:36:25] <superdump> make toys
[08:36:54] <Dark_Shikari> it took like a couple hours
[08:36:58] <Dark_Shikari> haskell is \o/
[08:37:02] <pJok> Ffos
[08:38:54] <ohsix> class http://wiki.xiph.org/MailOgging
[08:40:13] <peloverde> Let's start a campaign asking apple to support H.264 and AAC on the iPod...
[08:40:23] <pJok>   wonder when ffmpeg will come with its own compiler
[08:41:02] <kshishkov> pJok: eventually it should
[08:41:16] <kshishkov> GCC is already shows tendency on turning into Java
[08:41:59] <pJok> Slow, big and bulky?
[08:42:05] <kshishkov> that too
[08:42:37] <kshishkov> I mostly mean treating programmer as an idiot who does not know what he writes and needs constant guiding
[08:42:51] <pJok> Is clang worth anything?
[08:43:03] <kshishkov> not yet
[08:43:33] <bilboed-pi> apart for static analysis
[08:43:50] <kshishkov> not suitable for that too (yet)
[08:44:17] <bilboed-pi> the static analysis in 2.7 (to be released RSN) is way better than 2.6
[08:44:28] <bilboed-pi> actually does checks *across* functions
[08:44:37] * av500 lols at http://wiki.xiph.org/MailOgging
[08:45:06] <kshishkov> "char *ptr = ctx->smth; ptr[0] = 42;" results in "dead assignment" in clang. Next!
[08:45:49] <pJok> But it is dead!
[08:46:15] <pJok> GCC killed it
[08:46:38] <peloverde> Sometimes I like having dead assignments
[08:46:41] <kshishkov> well, GCC tries to get to the level of useless warnings, true
[08:47:38] <kshishkov> like in lavc/dca.c is warns about too high array index while in reality it's always in bounds
[08:48:03] <ohsix> wgat about space rays
[08:48:10] <pJok> "Warning: Programmer knows what he is doing. Turning on annoyance mode"
[08:48:10] <kshishkov> or that famous warning in liavc/vc1.c
[08:48:23] <Dark_Shikari> -Wshadow should always be enabled imo
[08:48:27] <Dark_Shikari> it catches real bugs
[08:49:00] <kshishkov> -Wthedarkness
[08:49:14] <ohsix> are you threatened/imasculated by a compiler? heh
[08:50:00] <KotH> -Whomelandsecuirty
[08:50:21] <kshishkov> well, if C compiler tell me you can't use logical and bitwise operands in the same expression not turning it into Lisp then you can throw that garbage compiler away
[08:50:33] <pJok> -Wparanoid
[08:50:42] <kshishkov> KotH: -Wsecuritytheatre
[08:52:08] * KotH wonders, whether the architects of homeland security got their ideas from b5's nightwatch
[08:53:36] <pJok> I know britain got their security manual from 1984
[08:53:40] <pross-au> -Wtsa
[08:53:49] <pross-au> it's all for show
[08:54:05] <kshishkov> -Wbushrangers
[08:54:33] <pross-au> that option has been deprecated kshishkov
[08:55:09] <kshishkov> good for you
[08:55:37] <pross-au> it's now -Wmr-plod
[08:55:55] * kshishkov fails to sing "who'll do a-waltzing matilda with gcc"
[08:56:17] <pross-au> hmm
[08:56:29] <pross-au> been practicing for the citizenship test?
[08:56:47] <kshishkov> nope
[08:57:04] <pross-au> i believe those sort of questions are on it
[08:58:49] <kshishkov> "who you should shot at first sight: a) sheep b) crocodiles c) rabbits d) pooftas"
[08:59:09] <pross-au> all of the above
[08:59:18] <kshishkov> and politics!
[09:00:54] <kshishkov> I heard your country is the only one where prime minister goes to jail right after he's elected
[09:01:11] <kshishkov> (there are many countries where they should do so, including Ukraine)
[09:03:19] <CIA-1> ffmpeg: thardin * r22821 /trunk/libavformat/ (aviobuf.c utils.c avio.h): Reusing the probe buffer to rewind the ByteIOContext in ff_probe_input_buffer() instead of seeking back to the start of the file. Once exhausted, the size of the buffer is reduced.
[09:04:28] <Tjoppen> there we go
[09:05:13] <kshishkov> yay
[09:07:20] <wbs> Tjoppen: grattis. :-)
[09:08:53] <KotH> wbs: it's not gratis, there is always an implied and hidden cost ;)
[09:09:06] <kshishkov> KotH: learn Swedish
[09:10:42] * KotH knows was grattis measn
[09:11:04] <kshishkov> and what does it mean?
[09:11:23] <KotH> equivalent to tack :)
[09:11:33] <kshishkov> no, "congratulations"
[09:11:41] <KotH> oh.. ok
[09:11:43] <wbs> (con)grat(ti)s ;P
[09:11:48] * KotH corrects his memory
[09:13:07] * Tjoppen recommends "mastering swedish"
[09:14:18] <superdump> Tjoppen: is that a book or...?
[09:14:21] <Tjoppen> ah, found it: http://www.youtube.com/watch?v=66fULfwb2X4
[09:14:39] <superdump> ah
[09:14:41] <superdump> yeha
[09:14:47] <superdump> merbzt1 pointed me to that
[09:16:04] <KotH> Tjoppen: i'm not into learning swedish.. at least not yet
[09:16:16] <KotH> Tjoppen: first i'd like to master japanese before starting another lang
[09:17:15] <superdump> KotH: this is more for amusement than learning anything
[09:17:17] <superdump> http://www.slayradio.org/mastering_swedish.php
[09:17:21] <superdump> full set are there
[09:24:12] <Tjoppen> now I'll just commit that skip-by-discarding patch and a whole heap of formats can be piped to ffmpeg/ffplay
[09:24:47] <superdump> woot
[09:24:49] <superdump> nice
[09:25:13] <Tjoppen> or more precisely, I'm replacing the "skip no more than 64 KiB" check with "skip, but don't SEEK_END unless forced"
[09:26:18] <KotH> apropos languages, does anyone know a good introductory book on linguistics?
[09:32:00] <Dark_Shikari> KotH: "master japanese before starting another lang"
[09:32:04] <Dark_Shikari> guess you'll never be starting another lang then
[09:33:59] <KotH> Dark_Shikari: depends on the definition of "master" :)
[09:34:20] <Dark_Shikari> do you know enough to read books, etc?
[09:35:25] <KotH> not yet
[09:36:27] <Dark_Shikari> then you have a long way to go ;)
[09:36:38] <KotH> exactly :)
[09:37:44] <KotH> hmm... another question, this times about c:
[09:37:56] <Dark_Shikari> yeah, c> japanese ;)
[09:38:04] <Dark_Shikari> easier to tokenize
[09:38:05] <KotH> i have an constant array of a struct
[09:38:37] <KotH> now i need indices into this array and i'd like them to be some meaningful constants/macros
[09:38:49] <KotH> any idea how i can achieve that?
[09:39:04] <KotH> oh yes, it should be defined at compile time
[09:40:23] <KotH> i'd like to have the indices coupled to the array, so if anyone changes the order in the array, that the indices imediatly reflect that, w/o manual editing of the indice values
[09:48:23] <CIA-1> ffmpeg: thardin * r22822 /trunk/libavformat/aviobuf.c: Seeking forward in non-seekable media by discarding data, regardless of how far to seek. Won't SEEK_END unless forced though.
[09:55:39] <Tjoppen> makes AVI, MXF, DV, MOV etc. work on stdin
[09:56:25] <kshishkov> Dark_Shikari: I've started learning Swedish after I knew some bits of Japanese language and I hope to master it eventually
[09:56:41] <wbs> Tjoppen: don't forget to reply with "applied" on the appropriate threads on the ML, btw, when you're done applying
[09:56:44] <kshishkov> preferably in native speakers environment
[09:57:27] <av500> kshishkov: master japanese in sweden?
[09:58:03] <KotH> where else would you go to master japanese?
[09:58:27] <kshishkov> I've met one foreighner in Stockholm who specially went to Sweden to learn Japanese
[09:58:28] <av500> neuschwanstein?
[09:59:39] <kshishkov> av500: last summer I saw and heard Japanese at every tourist attraction or airport - including Boryspil
[10:04:25] <kshishkov> speaking of tourist attractions, http://www.phoronix.com/vr.php?view=14747
[10:07:59] <av500> is it me or doth that phoronix nix load?
[10:09:05] <av500> ah, now it does
[10:10:29] <kshishkov> slashdotted
[10:12:29] <av500> eew
[10:12:56] <av500> and you did not link to the sushi article?
[10:13:47] <superdump> kshishkov: i read the phoronix thing about chernobyl and another account of a motorcyclist who was riding through there taking photos
[10:13:50] <superdump> interesting stuff
[10:24:52] <kshishkov> Ukraine is famous for its places
[10:25:01] <kshishkov> Chernobyl is known worldwide
[10:25:49] <kshishkov> Swedes try not to know about Poltava where the pinpoint battle Great Northen War was held
[10:26:12] <kshishkov> Polish people think of Kharkov usually in the same context as Katyn
[10:27:05] <kshishkov> Yalta with its conference was not very pleasant to some Baltic states
[13:55:27] <nfl> a decoder with CODEC_CAP_SUBFRAMES set should check whether the packet has enough data, right?
[13:55:46] <BBB> it should always do that
[13:55:47] <kshishkov> any decodr should
[13:55:57] <BBB> CODEC_CAP_SUBFRAMES means the input can contain multiple decodable units
[13:56:05] <BBB> so the input could be 100 bytes, but the decoder only consumes 10
[13:56:18] <BBB> and then the caller should call the decoder again with the remaining 90 bytes in the next round
[13:56:18] <nfl> is this why a parser is more desirable?
[13:56:33] <BBB> no, a parser is just a different way to achieve the same thing
[13:56:40] <BBB> but for speech codecs, a parser makes little sense imo
[13:56:49] <BBB> so we tend to use CODEC_CAP_SUBFRAMES for all speech decoders
[13:57:09] <kshishkov> and parser sucks when decoder actually consumes 73 bits instead of 10 bytes
[13:57:39] <nfl> ok
[13:57:55] <BBB> oh right that was another reason
[13:58:01] <BBB> so a parser wouldn't work anyway
[13:58:25] <av500> why not?
[13:58:30] * BBB should still write a generic bit-caching mechanism for all wma decoders
[13:58:43] <BBB> av500: how would the parser tell the decoder that the frame starts at bit 3 of byte 3?
[13:58:48] <BBB> instead of bit 0
[13:59:03] <av500> the parser would shift the bits of course
[13:59:13] <BBB> kills performance
[13:59:14] <BBB> bad idea
[13:59:17] <av500> maybe
[13:59:25] <BBB> it's suboptimal and therefore incorrect
[13:59:26] <av500> but it would be a parser for that bitstream format
[13:59:36] <BBB> but we don't want it anyway ;)
[13:59:43] <av500> thats another thing :)
[13:59:52] <BBB> fair enough
[14:01:17] <nfl> btw, is merbzt1 the real merbzt?
[14:01:47] <mru> no, that's his evil twin
[14:02:31] <nfl> riite! :)
[14:03:52] <merbzt1> I'm the real mccoy
[14:04:19] <mru> prove it
[14:04:42] <merbzt2> now who's the real one?
[14:04:45] <superdump> would the real merbzt1 please stand up
[14:05:21] <BBB> nfl: what would you rather work on, g723.1 or amr-wb?
[14:09:58] <nfl> my first preference would be g723.1 now that i've worked bit on it. (plus the spec is much shorter ;) ). but wouldn't mind amr-wb either since i'm a bit familiar with it too.
[14:10:10] <nfl> *a bit
[14:10:32] <jai> nfl: btw, good luck for gsoc
[14:10:55] <nfl> jai, all thanks to you :)
[14:12:28] <BBB> nfl: well, I think from our perspective (purely speaking for myself here), amr-wb might be more attractive because it is far better-known
[14:13:14] <jai> we still can't drop libopencore though
[14:13:31] <jai> but there is always another gsoc so meh
[14:13:43] <merbzt1> for g723.1 you would need to implement an encoder also
[14:13:46] <superdump> but if people wanted just decoding, they could maybe drop opencore
[14:14:03] <superdump> if float is acceptable
[14:14:15] <wbs> now that you guys are relatively familiar with those codes - how much work is an amr-nb encoder?
[14:14:20] <wbs> codecs, even
[14:14:36] <BBB> we don't want an amr-nb encoder, I think
[14:14:41] <BBB> we want a "generic speech coding system"
[14:14:46] <BBB> and then an amr-nb bitstream maker
[14:15:01] <BBB> so that plugging in a wb/anything encoder is a piece of cake
[14:15:23] <jai> sounds like a lot of work :)
[14:15:23] <BBB> just like acelp_*/celp_*.[ch] are mostly generic speech coding functions
[14:15:29] <BBB> a good encoder is a lot of work
[14:15:54] <jai> of course, but we already use this "approach" for flac and alac
[14:16:31] <jai> that reminds me, the alac encoder doesnt output 24 bps yet
[14:18:10] * nfl is thinking...
[14:19:54] <BBB> we still need more students by the way
[14:20:01] <BBB> we don't have all that many so far
[14:20:13] <jai> lol
[14:20:21] <av500> #beagle is overflowing with students
[14:20:32] <av500> but from what I have seen, you dont want them :)
[14:20:35] <jai> if last year's trends hold up, then you should get quite a lot towards the end
[14:21:05] <jai> av500: sir can i haz beaglborde gsoc
[14:21:43] <av500> jai: how do you knwo?
[14:21:46] <BBB> jai: you sure you don't want to do a soc project this year?
[14:22:19] <BBB> bilboed-pi: how's your applications?
[14:22:21] <av500> jai: the "sir" is mandatory, yes :)
[14:22:41] <bilboed-pi> BBB, low tbh (both in gstreamer and wine)
[14:22:48] <jai> av500: of course, we wouldn't get anywhere without the overt politeness :)
[14:22:52] <superdump> bilboed-pi: how many for gst now?
[14:23:06] <superdump> we have one more than the other day, though we knew about this person anyway
[14:23:29] <jai> BBB: would have loved to, but i can live without the flames ;)
[14:23:39] <BBB> hmm...
[14:23:42] <bilboed-pi> superdump, 8 so far
[14:23:55] <jai> but with people like nfl, you needn't worry :)
[14:24:13] <av500> all new ffgsoc, 100% fflame free...
[14:24:19] <nfl> jai, hey!
[14:24:20] <bilboed-pi> BBB, GNOME has quite a few... but they're like 20 times the same proposal ... of very poor quality
[14:24:22] <BBB> jai: you should really consider applying, I mean, assuming you have time and so on
[14:24:27] <jai> BBB: anyone show up for the dts encoder?
[14:24:32] <BBB> jai: not that I know
[14:24:45] <jai> oh
[14:25:14] <jai> bilboed-pi: same goes for gentoo
[14:25:23] <bilboed-pi> jai, :(
[14:25:38] <jai> infact people who don't know that gentoo is a source-based distro have sent in applications
[14:25:38] <bilboed-pi> jai, and from echoes, GNU also has very few proposals
[14:25:45] <bilboed-pi> jai, ROFL :)
[14:31:20] <BBB> jai: again, consider, we have many places left right now... otherwise I will have to resign as admin to be a student
[14:31:31] <bilboed-pi> ahahaha :)
[14:31:35] <kshishkov> BBB: do it!
[14:31:38] <bilboed-pi> that would be fun though
[14:31:41] <jai> BBB: do it!!
[14:31:43] <jai> srsly
[14:31:45] <BBB> it'd be kind of weird, because I handle the payment also ;)
[14:31:51] <BBB> maybe they won't notice
[14:31:56] <jai> yes, less overhead ;)\
[14:32:11] <kshishkov> you can use one inflatable Mike dummy for payment handling ;)
[14:32:19] <jai> BBB: so slots have been allocated already?
[14:32:20] <superdump> BBB: didn't you register as project admin though?
[14:32:26] <BBB> superdump: I can resign
[14:32:30] <superdump> mmm
[14:32:36] <BBB> or make a fake ID under my student email addy
[14:32:38] <BBB> or so
[14:32:40] <BBB> hmm...
[14:32:43] <wbs> agh, how to convince people that creating headers for sending over the wire using bitfield structs isn't really the way to go - especially not if they're trying to fill out fields using if (htonl(foo) == foo) do something; else do something else...
[14:32:54] <jai> wbs: fflames ;)
[14:33:00] <BBB> wbs: just say "patch rejected, don't do that"
[14:33:03] <superdump> BBB: you have to have some google account to apply i think, not sure though
[14:33:13] <BBB> wbs: when I saw that I just didn't know what to say
[14:33:21] <jai> superdump: he can always create a throwaway account
[14:33:25] * av500 is still a student, will not apply though
[14:33:28] <wbs> BBB: heh :-)
[14:33:38] <BBB> av500: apply, apply!
[14:33:49] <jai> i personally would have very high expectations from a BBB driven "RTSP layer improvements" or somesuch ;)
[14:33:49] <wbs> it took me quite a while to figure out wtf the htonl(off) >> 8 was meant to do
[14:34:08] * kshishkov is not a student anymore, so he'll do stuff for free (as usual)
[14:34:22] <BBB> I don't think htonl(off)>>8 does anything predictable
[14:34:32] <BBB> as in, arch-independent
[14:34:34] <BBB> does it?
[14:34:40] <wbs> nope
[14:34:43] <jai> no
[14:34:56] <BBB> maybe he meant htonl(off>>8)
[14:35:07] <wbs> nope, that actually does the right thing on little-endian
[14:35:15] <wbs> albeit obfuscated beyond recognition
[14:35:21] <BBB> or he meant ntohl(off)>>8?
[14:35:29] <mru> htonl == ntohl
[14:35:34] <BBB> I know
[14:35:47] <BBB> but you distinguish so you know which variables are network-ordered and which are host-ordered
[14:35:58] <BBB> otherwise your code becomes completely ununderstandable
[14:36:11] <wbs> it byte flips the value off to big endian, but since it's a 32-bit value in "opposite endian" that he's going to store into a 24 bit bitfield, he shifts it 8 bits right, so that it fits perfectly ;P
[14:36:45] <wbs> AV_WB24 would be all too easy. ;P
[14:36:45] <BBB> just reject the patch ;) it didn't use dynamic payloader handlers anyway
[14:39:12] <jai> BBB: again on the topic of gsoc, which are the "high priority" tasks right now?
[14:39:35] <kshishkov> the ones with students ;)
[14:39:55] <Tjoppen> is there a good field in AVStream to/from which to get an estimate for the number of packets that will be muxed/demuxed? nb_frames works well for video, but for audio less so
[14:40:42] <Tjoppen> I've managed to have the MOV muxer write the moov tag before the mdat tag, but it needs an estimate for the number of packets in each stream. atm I'm just using nb_frames, but that seems a bit ugly
[14:40:50] <jai> kshishkov: i meant what would be the "zomg must have in 0.6" tasks :)
[14:41:53] <av500> Tjoppen: estimate and then padding?
[14:42:59] <Tjoppen> I can generate an OK estimate from the demuxer's nb_frames by dividing with AVCodecContext::frame_size (unless PCM). also, I automagically get some extra padding because I estimate the size of the moov tag in the most pessimistic manner
[14:43:20] <merbzt1> Tjoppen: Baptiste will shred you :)
[14:43:34] <jai> Tjoppen: why does this sound like something qtfaststart does :)
[14:43:41] <Tjoppen> indeed :)
[14:44:03] <av500> Tjoppen: your estimate must be very pessimistic, otherwise you can end up with having to rewrite the whole file at the end
[14:44:27] <av500> well, you can always declare the front moov as skip and append one :)
[14:44:40] <Tjoppen> well, I just write the moov tag to the end in that case, and make the one at the start a skip tag
[14:44:47] <av500> :)
[14:44:59] <av500> jai: because qtfaststart reads the whole file
[14:45:09] <kshishkov> jai: LATM, we have added everything else from the list
[14:45:10] <av500> so it knows how much is needed for the moov, no?
[14:45:23] <Tjoppen> I've tested it with > 4 GiB files, in which case the estimate is fairly accurate
[14:45:54] <av500> Tjoppen: with all supported codecs?
[14:46:23] <Tjoppen> it passes the regression tests, but then again I haven't made ffmpeg.c make use of this
[14:48:29] <Tjoppen> with a small piece of code that flushes the moov tag periodically one can even play a file that is being written, which is useful when importing to final cut pro
[14:49:16] <jai> kshishkov: hmm, latm sounds doable
[14:49:42] <Tjoppen> I think I'll post it as an RFC on the list. the patch I just posted is fairly benign though
[14:51:22] * KotH blames DonDiego 
[14:51:51] <BBB> jai: anything you like, I'd love wvp2 but it's a lot of work
[14:52:00] <BBB> there's easier tasks also, depends on what you're looking for
[14:56:47] <DonDiego> http://lwn.net/SubscriberLink/382478/5ba427f93097f8da/
[15:02:50] <KotH> this is becomming a full blown battle
[15:04:55] <av500> but we cannot call it a "war", due to insurance reasons!
[15:05:31] <DonDiego> as i predicted, this is not about just technical arguments
[15:05:42] <mru> it never was
[15:05:46] <mru> it's about freeeeedom
[15:05:55] <mru> freedom to do as "they" say
[15:06:05] <DonDiego> no, and painting it that way will not help
[15:06:26] <DonDiego> do you guys have lwn.net accounts?
[15:06:30] <mru> no
[15:06:37] <mru> it's impossible to argue with freetards
[15:06:43] <DonDiego> time to create one? :)
[15:06:58] <DonDiego> this is not about the freetards
[15:07:06] <mru> what then?
[15:07:07] <DonDiego> it's about the neutral bystanders
[15:07:23] <av500> think about the children!
[15:17:02] <jai> also, isn't mru's name spelt wrong
[15:17:13] <mru> close enough
[15:17:46] <mru> it's actually the official spelling in some places
[15:17:57] <twnqx> what's wrong exactly with the above article?
[15:18:23] <mru> apart from the misunderstandings and lies, not much
[15:18:25] <DonDiego> yeah, let's start making a list and put it into the comments :)
[15:21:21] <av500> "...but Xiph should immediately improve/change Ogg for, breaking millions of hardware decoders..."
[15:21:29] * av500 wonders what these are
[15:21:42] * mru never saw one
[15:21:55] <av500> I think he refers to mp3 players playing vorbis
[15:22:09] <av500> xiph can keep ogg for vorbis
[15:22:43] <av500> but I saw no PMP yet that plays theora
[15:23:03] <mru> not even yours?
[15:23:12] <av500> nope
[15:23:18] <av500> no customer demand :)
[15:23:36] <av500> customers want us to play H264HP and DTS or AC3
[15:23:38] <kshishkov> av500: then monty hasn't got your mail address ;)
[15:23:45] <av500> no, he is nto a customer
[15:24:40] <av500> we added vorbis some time ago because people asked for it
[15:24:54] <DonDiego> vorbis in ogg?
[15:24:58] <av500> yep
[15:25:08] <DonDiego> do you support mkv?
[15:25:10] <av500> yes
[15:25:16] <av500> vorbis in that one too :)
[15:26:27] <av500> but as there is no theora decoder for the DSP, I never bothered to even think about suppoting it
[15:27:16] <av500> hint to xiph/mozilla: take your $5million that you dont want to pay to MPEGLA and use it to write DSP codecs
[15:28:25] * kshishkov thinks about Mozilla DSp for decoding Theora
[15:28:41] <kshishkov> will it take 5A and occasionally explode?
[15:28:47] <av500> kshishkov: no
[15:28:55] <av500> it just needs to be DONE
[15:29:00] <jai> Tjoppen: do you have other patches for the mov muxer as well?
[15:29:23] <av500> kshishkov: there was this gsco project to do it -> fail
[15:29:29] <DonDiego> i think they're working on that..
[15:29:30] <av500> there was neuros doing it -> fail
[15:29:41] <kshishkov> why?
[15:29:42] <av500> DonDiego: well, how long will it take? the time is now
[15:29:59] <av500> show the world that theora is there on e.g. omap3
[15:30:04] <kshishkov> C-to-silicon compilers can't take Xiph code?
[15:30:31] <av500> kshishkov: I am not talking about hw decoders
[15:31:10] <av500> where are the xiph patches to android to support ogg/theora?
[15:31:19] <bilboed-pi> errr... http://www.schleef.org/blog/2009/11/11/theora-on-ti-c64x-dsp-and-omap3/
[15:31:44] <av500> "...he Theora decoder plays 640×360 24fps at slightly more than 100% speed on average..."
[15:31:46] <mru> is that the one that's slower than plain c on arm?
[15:32:41] <bilboed-pi> the difference being : he actually did something, you're just rambling :P
[15:32:54] <bilboed-pi> and that was 6 months ago
[15:33:09] <av500> yes, and what happened since then? why did they not followed up with funding?
[15:33:14] <av500> I am not rambling
[15:33:14] <mru> look, I don't give a rat's arse about theora
[15:33:21] <mru> I'm doing other things
[15:33:39] <DonDiego> please, this used to be about ogg..
[15:33:47] <DonDiego> maintain the topic
[15:33:53] <av500> jaja
[15:33:55] <bilboed-pi> :)
[15:34:02] <av500> ogg sucks!
[15:34:05] <av500> better?
[15:37:11] <kshishkov> av500: ogg sucks better than what?
[15:44:36] <janneg> ms vacuum cleaner
[15:48:06] <danielk22> Is there a preferred way to flip bit order in a byte in ffmpeg (i.e. macro,lookup table,function) ?
[15:48:27] <kshishkov> out[i] = ff_reverse[in[i]
[15:48:38] <mru> we should wrap that in an asm-able macro
[15:48:51] <danielk22> kshishkov: thx
[15:49:41] <kshishkov> mru: and on what arch it will give any benefit?
[15:49:53] <mru> arm for starters
[15:49:59] <mru> anything with a bitrev instruction
[15:50:19] <kshishkov> I understand that and ask for specific examples
[15:50:41] <mru> well, arm is one
[15:50:44] <mru> most DSPs have it too
[15:51:23] <kshishkov> do we support any DSPs but Blackfin?
[15:51:29] <mru> we want to
[15:52:38] <kshishkov> is that possible without major efforts?
[15:53:03] <mru> it's certainly possible with acceptable efforts
[15:53:14] <kshishkov> C64+?
[15:53:22] <mru> comes to mind
[15:53:22] <av500> efforts
[15:53:35] <av500> blackfin runs linux on the dsp itself
[15:53:47] <mru> unfortunately gcc for blackfin sucks
[15:53:52] <mru> probably more even than ogg
[15:53:57] <kshishkov> s/for blackfin/
[15:54:07] <av500>  /
[15:54:15] <mru> gcc blackfin suckage is in a class of its own
[15:54:28] <mru> seriously
[15:54:41] <mru> arm at same cpu speed runs ffmpeg several times faster than bfin
[15:54:46] <mru> the instruction set isn't that bad
[15:55:25] <DonDiego> i'm at work, any good music suggestions for hacking?
[15:55:36] <av500> silence works for me
[15:55:41] <mru> guns n' roses
[15:55:50] <kshishkov> John Cage's 4'33"
[15:57:28] * kshishkov usually listens at whatever at hand
[15:57:54] <jai> brown noise
[15:59:10] <jai> BBB: ping
[16:01:56] <danielk22> kshishkov: looks like it is av_reverse..
[16:02:09] <BBB> jai: pong
[16:02:40] <kshishkov> danielk22: yes, IIRC it's been renamed recently. But you found it anyway
[16:08:17] <jai> peloverde: ping
[16:28:30] <DonDiego> btw, have you seen monty's response to the lwn article?
[16:33:21] <av500> Im still trying to compile the files he linked to :)
[16:49:37] <DonDiego> av500: ?
[16:51:25] <av500> http://lwn.net/Articles/382603/
[16:51:44] <av500> this one? it has links to .c files, no?
[16:54:12] <DonDiego> you're seriously trying to compile that tarkin stuff?
[16:54:20] <av500> no :)
[19:05:06] <merbanan> saste: -> superdump and accept the invite
[19:05:17] <merbanan> I've got the power also
[19:42:55] <bcoudurier> hi guys
[19:43:11] <_av500_> Dark_Shikari: ping
[19:47:00] <BBB> bcoudurier: thanks for the email
[19:49:48] <bcoudurier> BBB, you're welcome, thanks for pushing this through
[19:55:38] <Dark_Shikari> _av500_: pong
[19:56:15] <_av500_> Dark_Shikari: about mpeg2 to mpeg4 transcoding
[19:56:39] <_av500_> in compressed domain, i heard several times that it does not work
[19:57:01] <_av500_> but did ppl try to use the MVs as hints for the encoder MV search?
[19:57:06] <Dark_Shikari> mpeg2->mpeg4 works
[19:57:09] <Dark_Shikari> mpeg2->H264 doesn't work
[19:57:19] <_av500_> ah
[19:57:37] <bcoudurier> wasn't there a paper about this ?
[19:58:09] <mru> for some values of work
[19:58:20] <mru> mpeg4 has many more mv modes than mpeg2
[19:58:27] <Dark_Shikari> mru: you don't have to use them
[19:58:36] <mru> no, but they might give better compression
[19:58:44] <Dark_Shikari> yes, but if you're doing comrpessed-domain transcoding
[19:58:44] <mru> I suspect that's why they added them
[19:58:48] <Dark_Shikari> you already don't give a shit about compression
[19:59:03] <mru> why would anyone do compressed-domain transcoding?
[19:59:12] <_av500_> speed?
[19:59:13] <mru> the only reason I can think of is to write an academic paper about it
[19:59:28] <Dark_Shikari> a target device that handles X but not Y?
[19:59:30] <Dark_Shikari> Y -> X
[19:59:52] <mru> how often do you see a device that does mepg4 but not mpeg2?
[19:59:56] <mru> the opposite is common
[20:00:12] <superdump> ipod?
[20:00:13] <mru> but you can't transcode in that direction
[20:00:14] <_av500_> Dark_Shikari: assume i downscale, would the downscaled MVs help the enc?
[20:00:30] <Dark_Shikari> not really that much
[20:00:43] <Dark_Shikari> at fast settings, more time is spent in qpel refine than in fullpel ME
[20:00:46] <Dark_Shikari> at least in x264
[20:00:47] <_av500_> in order to limit the search space?
[20:01:01] <_av500_> ah ok
[20:01:55] <_av500_> mru: we were talking over lunch to do some transcoding on the omap3
[20:02:31] <_av500_> decode on arm, encode on dsp
[20:03:36] <_av500_> hence the idea of reusing the MVs for downscaled transcoding
[20:05:19] <Dark_Shikari> here's x264 on low-latency superfast encoding settings.  no idea how their encoder compares
[20:05:22] <Dark_Shikari> http://pastebin.org/141858
[20:05:30] <Dark_Shikari> consider where the time is spent.
[20:15:52] <dgt84> Can someone explain how asm functions are used in libavcodec/dsputil.c? It seems there is e.g. vsad16_c defined there then vsad16_mmx and vsad16_mmx2 defined in the x86 folder. Is there a way to call one but have it set the best option at compile time magically? Is that what it does when making ffmpeg?
[20:17:20] <superdump> function pointers...
[20:20:52] <dgt84> superdump, sure, but how do I go about using them to have the correct function chosen at compile time for those particular functions? I don't know the internals of libavcodec all that well...
[20:21:10] <_av500_> configure script
[20:34:15] <BBB> dgt84: you init a dspcontext
[20:34:39] <BBB> dgt84: that gives you a struct with filled-in optimal function pointers to whichever vsadXX*() is best for your cpu
[20:34:51] <BBB> then you call ctx->vsadXX*()
[20:34:53] <BBB> and you're done
[20:35:29] <dgt84> BBB, thanks, I was just reading that in the code, but it seems to also need an AVCodecContext to be setup, going to see how easy that is
[20:35:59] <mru> that's only used for flags
[20:36:06] <mru> and the codec id in a couple of cases
[20:36:16] <mru> those should really be fixed
[20:42:49] <dgt84> Thanks guys, I have it working nicely. Those MMX/SSE instructions are considerably faster for block comparisons
[20:43:25] <Dark_Shikari> what are you using them for
[20:43:27] <mru> no kidding
[20:45:10] <Dark_Shikari> "considerably faster" is a tad of an understatement
[20:46:20] <Dark_Shikari> theory says 21.33x faster for SAD block comparisons on aligned data
[20:46:26] <Dark_Shikari> benchmark says 21.35x faster.
[20:46:57] <dgt84> Just messing around. I wrote a libavfilter for deshake/depan/stabilize and wanted to see the difference that some assembly could make in the speed of it. Now I can deshake a live video feed from my camera which is neat, but something isn't quite right with the way I'm using the dsputil functions, gotta fix that.
[20:47:14] <Dark_Shikari> isn't that just a global motion estimation problem?
[20:47:24] <Dark_Shikari> it sounds like the best way to do that is to use hierarchical motion estimation
[20:47:53] <dgt84> I have one of those crappy handheld cams that fit in your pocket and was hoping to stabilize them a bit. I'm a complete n00b when it comes to encoding and motion estimation, been trying to read a bit and messing around on my own.
[20:48:05] <Dark_Shikari> so here's the simple way
[20:48:15] <dgt84> I have it working in my filter nicely, it's just slow and I'm doing exhaustive searches FTL
[20:48:18] <Dark_Shikari> 1) Let there be a function that downscales the image by a factor of 2 (and pads the edges accordingly)
[20:48:32] <Dark_Shikari> Let's call this function Image DownSize( Image i );
[20:48:41] <Dark_Shikari> takes an image, returns an image downscaled by 2 and padded to mod16 in both directions.
[20:49:23] <Dark_Shikari> 2) Run this on the image repeatedly, storing the result each time.  So you have 1x (original), 2x downscaled, 4x downscaled, etc.
[20:49:38] <Dark_Shikari> 3) Do this until you have a very low res one on the bottom.  Say, 64x64.
[20:49:55] <Dark_Shikari> 4) Perform a dead-simple diamond motion estimation, using the entire frame as your block size.
[20:50:16] <Dark_Shikari> subpel is highly recommended.
[20:50:36] <Dark_Shikari> 5) Double the length of the MV in the horizontal and vertical directions.  Go to the next-lowest-resolution version.  Repeat, except start at the MV from the previous one (doubled, as mentioned).
[20:50:40] <dgt84> Won't downscaling the image a few times take a while?
[20:50:45] <Dark_Shikari> 6) Repeat until you reach the full res version.
[20:50:49] <Dark_Shikari> 7) You're done.
[20:50:57] <Dark_Shikari> only the first downscaling step is slow
[20:51:01] <Dark_Shikari> each one is 4 times faster than the previous
[20:51:11] <Dark_Shikari> and "slow"... not really
[20:53:13] <Dark_Shikari> the downscale can be a REALLY fast downscale, like x264's
[20:53:31] <Dark_Shikari> which has the amusing property of being like 25x faster in asm than C (40x on altivec)
[20:53:45] <dgt84> Right now my algorithm is: split image into blocks, discard low contrast blocks, do full motion search by x pixels in any direction on rest with SAD block comparison, figure out which mv is most common and the most likely global mv, shift image
[20:54:11] <Dark_Shikari> probably best to just search the whole image.  though you could cheat and ignore low complexity blocks in my method too
[20:54:17] <Dark_Shikari> though the way I'd skip is by checking their SAD
[20:54:23] <Dark_Shikari> and checking against some threshold
[20:54:35] <Dark_Shikari> probably a threshold based on the overall sad of the frame
[20:54:55] <dgt84> yeah I wasn't sure what to make the threshold and tried several values but it's tough to get it working nicely on all samples
[20:55:08] <Dark_Shikari> this is why you use hierarchical estimation
[20:55:10] <dgt84> The contrast threshold I do now seems to work okay
[20:55:26] <iive> Dark_Shikari: x264 uses multiple downscaling ?
[20:55:32] <dgt84> Do you think your method would be faster and/or more accurate?
[20:56:06] <Dark_Shikari> iive: no
[20:56:13] <Dark_Shikari> dgt84: more accurate definitely
[20:56:13] <iive> only once?
[20:56:22] <Dark_Shikari> faster, not sure but you won't need anything more than diamond search
[20:56:23] <Dark_Shikari> no exhaustive
[20:56:25] <Dark_Shikari> iive: for lookahead
[20:56:38] <Dark_Shikari> it's also not a "real" downscale: it outputs 4 planes, for "hpel"
[20:56:46] <Dark_Shikari> i.e. given:
[20:57:20] <iive> that's more like upscale
[20:57:23] <Dark_Shikari> it does both
[20:57:30] <Dark_Shikari> FX XFX XF
[20:57:40] <Dark_Shikari> X X X X X
[20:57:51] <Dark_Shikari> FX XFX XF
[20:57:53] <iive> the middle pixel is downscaled version...
[20:58:00] <Dark_Shikari> "F" are source pixels
[20:58:10] <Dark_Shikari> or wait, that's wrong too
[20:58:26] <Dark_Shikari> the formula is easier to post.
[20:58:33] <iive> don't i got the idea
[20:58:44] <Dark_Shikari> the formula is actually sorta important to see _why
[20:58:58] <Dark_Shikari> #define FILTER(a,b,c,d) ((((a+b+1)>>1)+((c+d+1)>>1)+1)>>1) dst0[x] = FILTER(src0[2*x  ], src1[2*x  ], src0[2*x+1], src1[2*x+1]); dsth[x] = FILTER(src0[2*x+1], src1[2*x+1], src0[2*x+2], src1[2*x+2]); dstv[x] = FILTER(src1[2*x  ], src2[2*x  ], src1[2*x+1], src2[2*x+1]); dstc[x] = FILTER(src1[2*x+1], src2[2*x+1], src1[2*x+2], src2[2*x+2]);
[20:59:04] <Dark_Shikari> lol line breaks disappeared.
[20:59:10] <Dark_Shikari> anyways, the idea is that it only requires "pavg"
[20:59:20] <Dark_Shikari> every single operation is (x + y + 1)>>1
[20:59:40] <Dark_Shikari> and you can use it for hierarchical search
[20:59:49] <Dark_Shikari> you run it on source, giving you Lowres plane + hpel
[20:59:54] <Dark_Shikari> you run it on lowres, giving you ultra-lowres + hpel
[20:59:55] <Dark_Shikari> etc
[21:00:05] <Dark_Shikari> the hpel is useful for, well, subpel search.
[21:01:44] <dgt84> Dark_Shikari, thanks for the tips I'll try and read up a bit more on this stuff and put it into my todo to try and figure out how to go about implementing it
[21:02:12] <Dark_Shikari> see http://wiki.videolan.org/SoC_x264_2010#GPU_Motion_Estimation_2
[21:02:20] <Dark_Shikari> your algorithm would be the same except that the whole frame has only one MV
[21:02:24] <Dark_Shikari> no blocks.
[21:37:43] * peloverde pulls hair at the response to crbug.com/39969
[21:39:50] <Dark_Shikari> it's frank barchard
[21:39:53] <Dark_Shikari> he is a COMPLETE moron
[21:40:08] <Dark_Shikari> every time he's on irc he has demonstrated that he knows absolutely nothing about multimedia or software development
[21:40:19] <Dark_Shikari> I have no idea how the fuck he got google to hire him
[21:40:41] <Dark_Shikari> he is one of those people who is not merely ignorant, but also a _fool_
[21:43:45] <peloverde> In this case the problem appears to be the ubuntu packager
[21:55:49] <mchinen> Hi, is Baptiste around?
[21:56:42] <Dark_Shikari> bcoudurier: ^
[21:59:02] <bcoudurier> yes
[23:41:48] <pengvado> Dark_Shikari: I'd describe x264's algorithm as a lowpass, not a downscale
[23:43:13] <pengvado> you can then subsample the lowpassed image, or not
[23:59:45] <mfg> what is dts and pts in a stream?