[FFmpeg-devel-irc] IRC log for 2011-03-08

[irc at mansr.com]

[11:03:09] * Terminating due to: TERM
[11:05:41] * /join #ffmpeg-devel ...
[11:05:45] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | Channel is logged.
[11:05:45] *** TOPICINFO: merbzt!~benjamin at m83-186-120-172.cust.tele2.se, 1295456661
[11:08:33] * Terminating due to: TERM
[11:10:53] * /join #ffmpeg-devel ...
[11:10:57] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | Channel is logged.
[11:10:57] *** TOPICINFO: merbzt!~benjamin at m83-186-120-172.cust.tele2.se, 1295456661
[11:31:21] <kshishkov> _av500_: have you sued them for infringement? http://moviebarcode.tumblr.com/
[12:19:32] <Tjoppen> oops, accidentally send ML replies directly to BBB instead of the list :)
[12:21:10] <kshishkov> that's what you get with those 'To: author\nCC: list' mails
[12:21:26] <mru> why did people start doing that suddenly?
[12:24:18] <Tjoppen> it only seems to happen with people using gmail
[13:02:01] <BBB> Tjoppen: sorry, seems gmail decided to make reply-to-all really reply-to-all on MLs, it didn't use to do that
[13:02:06] <BBB> anyway
[13:02:12] <Tjoppen> I see
[13:02:14] <BBB> elenril: make fate-lavf-bmp fails because of your second patch
[13:02:23] <BBB> Tjoppen: so all my mails get sent twice now
[13:02:36] <BBB> maybe this is their way of decreasing the amount of spam in statistics
[13:02:44] <BBB> after all, twice as much non-spam mail \o/
[13:03:13] <Tjoppen> lol
[13:03:39] <BBB> saintd3v: I'm gonna ask a really stupid question
[13:04:03] <BBB> saintd3v: does it make sense, and is it at all practically useful, to share psymodels between different audio encoders, e.g. ac3 and aac?
[13:05:28] <kshishkov> BBB: nope, they have different ways to allocate bits
[13:05:33] <BBB> Tjoppen: thanks for re-sending patches, I'll look at it
[13:05:42] <mru> hmm, go to SF apr 5-13 or not...
[13:07:01] <Tjoppen> hm, any good reason why vf_overlay.c:259 checks for RGB output when the filter only ever reports supporting YUV420P output in query_formats()?
[13:07:03] <BBB> mru: go :)
[13:07:07] <BBB> mru: I may be there that week
[13:07:46] <kshishkov> mru: who's paying for the flight?
[13:08:06] <mru> kshishkov: I probably have to pay that myself
[13:08:22] <kshishkov> mru: then the answer is close to "no"
[13:08:36] <mru> why?
[13:08:45] <mru> flight isn't that expensive
[13:08:52] <kshishkov> if you're not going to receive something extra nice there why go?
[13:09:33] <mru> visit the local ffdevs and others
[13:09:39] <mru> view the scenery
[13:09:45] <mru> all the usual reasons to go places
[13:09:53] <kshishkov> well, if you haven't seen it then go
[13:10:01] <BBB> there's like 4 ffdevs there that week
[13:10:11] <BBB> alex, mike, david and me (possibly)
[13:10:14] * kshishkov wants to cut Falukorv with morakniv in Orsa or Borlange
[13:10:19] <BBB> then there's baptiste and jason a little south
[13:10:27] <BBB> and possibly others
[13:10:32] <mru> kshishkov: orsa is probably the most boring place in all of europe
[13:10:34] <BBB> astrange: ping re: mpeg* -mt patches :-p
[13:10:49] <mru> borlänge is known mostly for its high crime rates
[13:10:52] <kshishkov> mru: try Ukraine then
[13:11:14] <mru> nobody goes to borlänge voluntarily
[13:12:00] * kshishkov has visited Skärholmen and Rinkeby so far, sees no reason not to visit Borlänge
[13:12:16] <mru> you do seek out the worst places...
[13:12:28] <mru> nobody visits those two places either
[13:12:51] <kshishkov> I've covered the other regions of Stockholm
[13:13:36] <mru> hell, why hesitate... I'll just go
[13:14:55] <iive> pay kshishkov's ticked and he will come with you.
[13:15:31] <iive> ticket.
[13:15:47] <mru> ok, done
[13:18:20] <kshishkov> iive: to USA? I'm third-world country citizen
[13:18:44] <iive> forth.
[13:19:10] <iive> i forgot...
[13:20:35] <iive> I thought that you are already EU citizen.
[13:20:49] <kshishkov> nope, it's not fast
[13:21:04] <kshishkov> especially since I don't consider marriage
[13:21:05] <mru> iive: he has a slave labour visa
[13:21:33] <kshishkov> mru: in Ukraine we use term "gastarbeiter"
[13:22:19] <iive> i've heard that word too. I've always thought it is german.
[13:22:28] <mru> it is
[13:23:01] <kshishkov> there are quite a few German words in Ukrainian language
[13:23:34] <pJok> in soviet ukraine, german words you?
[13:24:09] <kshishkov> pJok: IIRC that's called "jive"
[13:25:22] <kshishkov> pJok: also guess where Yakov Smirnoff was born
[13:39:46] <pJok> kshishkov, same place as Alexander Kalashnikoff?
[13:40:46] <kshishkov> pJok: who's that?
[13:43:57] <iive> kshishkov: I though he invented the vodka.
[13:46:13] <kshishkov> iive: actually it's mostly Mendeleev who gets (wrongly) blamed for that
[13:46:31] <iive> my bad.
[13:47:14] <mru> I thought vodka was thought to be the fifth element in russua
[13:47:17] <mru> russia
[13:49:19] <kshishkov> yes, so nobody was sober enough to record when it was created
[13:52:06] <kshishkov> but since Mendeleev wrote a thesis on spirits (including ethanol) and water compounds, he's credited for inventing Real Russian Vodka
[14:35:28] <Tjoppen> the overlay filter drops frames randomly
[14:36:33] <mru> probably the same old timestamp nonsense as usual
[14:37:10] <Tjoppen> I'm trying to write a crossfade filter to evaluate whether lavfi is any good. I based it off of vf_overlay, which seems to drop frames even if both inputs are PAL
[14:37:33] <mru> I told you it's nonsense
[14:38:31] <Tjoppen> so I see. why do the filters take over the program flow actually?
[14:39:06] <Tjoppen> it's fine for straight filters I guess, but for anything advanced it's just asking for trouble
[14:42:12] <kshishkov> wasn't causing more trouble our goal (FFmpeg EE and such)?
[14:42:57] <lu_zero> Tjoppen: remove the timestamp guessing code and see what's the result
[14:43:43] <mru> simple hack method: remove entire contents of compute_pkt_fields() and tb_unreliable()
[14:44:54] <kshishkov> why it's still in git.ffmpeg.org then?
[14:46:43] <lu_zero> hyc: you around?
[14:47:55] <kshishkov> lu_zero: you use wrong handshake
[14:50:09] <lu_zero> kshishkov: meanwhile I noticed again an interesting shortcoming of libavfilter...
[14:53:29] <lu_zero> if you try to transcode a file with multiple video stream
[14:53:59] <lu_zero> the output will have the same resolution set...
[14:54:12] <Tjoppen> I made compute_pkt_fields*() and tb_unreliable() return zero/do nothing
[14:54:21] <Tjoppen> then I overlayed a DV onto itself
[14:54:30] <lu_zero> Tjoppen: works or not?
[14:54:33] <kshishkov> lu_zero: also it doesn't support resolution change. Or palette change.
[14:54:41] <Tjoppen> using vsrc_movie. fun fact: the order of the inputs to the overlay filter matters
[14:54:52] <lu_zero> Tjoppen: known issue
[14:55:15] <Tjoppen> aah
[14:56:45] <Tjoppen> shouldn't the overlay filter poll the inputs or something like that? or multi-input filters in general
[14:57:39] <Tjoppen> this is the sort of thing I don't get with the current design - does it do proper flow control and how does it keep filters from starving?
[15:02:17] <lu_zero> no idea =|
[15:03:38] <Tjoppen> hence why I think filters shouldn't call eachother, but rather report whether they're starving and let some kind of "driver" call them
[15:04:24] <Tjoppen> bonus: no need for vf_fifo
[15:04:55] <lu_zero> Tjoppen: that would require a eventloop
[15:05:05] <lu_zero> and possibly a separate thread
[15:05:44] <Tjoppen> yes, of course. well, you wouldn't need extra threads
[15:05:55] * lu_zero notices that is also a problem shared with the network layer...
[15:06:13] <lu_zero> Tjoppen: eventloop migth do alone
[15:06:22] <Tjoppen> but you'd have to inspect the graph to see which filters can work, and flush them until you can put frames on the input pads furthest back
[15:07:11] <Tjoppen> yeah, the protocols share a similar problem. like http.c reading a writing in the same thread, which may cause trouble
[15:07:24] <Tjoppen> or rather, doing so without poll()
[15:07:40] <lu_zero> Tjoppen: or doing so overpolling =P
[15:07:51] <lu_zero> or doing so overpolling AND blocking
[15:08:35] <lu_zero> or doing so overpolling AND blocking AND causing desyncs ^^;
[15:08:44] <Tjoppen> \o/
[15:10:30] <kshishkov> insert vf_monkey
[15:10:50] <vladimir__> elenril: Regarding the issue with id3v2 frames, i've opened an issue #2650, and uploaded the sample file.
[15:10:59] <_av500_> thx
[15:11:06] <BBB> 2 vladimirs
[15:21:48] <lu_zero> sigh
[15:21:49] * BBB pokes astrange
[15:22:07] * lu_zero isn't exactly fond of touching libavfilter...
[15:22:16] <BBB> so ask saste to do it for you
[15:22:28] <lu_zero> and/or figure out why it breaks...
[15:22:53] <lu_zero> BBB: I asked to fix the scaling issue on the multiple outputs ...
[15:25:31] <lu_zero> sigh
[15:26:09] <lu_zero> we should really move to bugzilla...
[15:35:28] <kshishkov> lu_zero: NAGzilla which really bugs devs till they fix issue
[15:35:54] <lu_zero> kshishkov: a bugzilla plugin?
[15:40:28] <kshishkov> I just made it up, feel free to develop it in any form you like
[15:40:40] <kierank> irc bot
[15:41:01] <ffnagbot> kshishkov: do vc-1 interlaced
[15:41:18] * mru interlaces vc1 with bink
[15:41:20] <kierank> forgot bbb and xvp8
[15:41:51] * lu_zero swscales xvp8
[15:43:43] <kshishkov> kierank: unfortunately for you proper ffnagbot nick is owned by mru
[15:44:05] <kshishkov> mru: make a fine hash out of it (aka TS)
[15:44:20] <kierank> [15:44] Notice from NickServ: ffnagbot is not registered.
[15:44:46] <kierank> mru: watched the troll hunter yet?
[15:44:51] <mru> yeah
[15:44:54] <kshishkov> kierank: hint - look at nicks present here starting with "ff" and ending with 'bot'
[15:45:11] <kierank> the bit right at the end was hillarious
[16:18:11] <BBB> kshishkov: you could at the very least help make vc1 be spec-compliant for the implemented features
[16:18:18] <BBB> kshishkov: you know the code better than me, it'll take me forever
[16:27:33] <kshishkov> BBB: I'd help when I have time. But now I'm going afk till next morning (as usual)
[16:27:48] * BBB waves
[16:27:51] <kshishkov> BBB: it's just my life now - too little free time
[16:30:53] <BBB> you sound like you're in business
[16:30:59] <BBB> wasn't student life just so much better?
[16:31:02] <BBB> always have too much free time
[16:32:53] <gnafu> BBB: But wasn't that only because you procrastinated more?
[16:32:59] <gnafu> That's what I did -_-.
[16:37:34] <iive> BBB: are all I frames bitexact?
[16:37:56] <BBB> iive: up to some stage they are
[16:38:03] <BBB> iive: I'm working on it, give me some slack :)
[16:38:17] <BBB> I'm trying to go one sample at a time
[16:38:26] <BBB> this particular sample (no overlap filter), I/B are bitexact
[16:38:28] <BBB> P frames are npot
[16:39:31] <iive> i know how tedious making something bitexact is. you can have all the slack you want.
[16:40:36] <Silverion> 
[16:41:47] <iive> are there P-frames that are bitexact. are all MB affected?
[16:42:08] <Silverion> 
[16:43:31] <lu_zero> uhmm
[16:43:36] <lu_zero> stranger and stranger
[16:44:03] <lu_zero> libavfilter doesn't seem at fault
[16:57:20] <BBB> ruggles: re: your avcodec_decode_audio4() patch, should the contents of InternalBuffer be made a union such that it takes less memory?
[16:58:27] <ruggles> BBB: you mean audio params or video params?
[16:58:32] <BBB> yes
[16:58:44] <BBB> width/height versus samplerate/channels etc.
[16:59:03] <BBB> might be a lot of work, not sure if it's worth it... but it would save a few bytes of allocated memory
[16:59:53] <ruggles> i don't think it's worth the complexity. we don't do that for any other a/v structs do we?
[17:07:36] <lu_zero> I'd postpone it
[17:07:44] <lu_zero> add just a comment for the future
[17:07:48] <lu_zero> meanwhile
[17:07:59] * lu_zero stares at ffmpeg.c 
[17:16:33] <lu_zero> ugh
[17:16:37] <lu_zero> wonderful...
[17:16:59] <lu_zero> ffmpeg.c:3256-7
[17:17:10] <lu_zero> no wonder I get those...
[17:34:46] <ruggles> lu_zero: you mean   video_enc->width = frame_width; video_enc->height = frame_height; ?
[17:36:50] <lu_zero> yup...
[17:37:34] <lu_zero> it behaves in an unexpected way with more than a single stream per type
[18:36:18] <kierank> merbanan: weren't you working on 10-bit dnxhd?
[18:59:55] <ruggles> kierank: do you know if there is a way to use Pro Tools plug-ins without having Pro Tools?
[19:00:39] <kierank> ruggles: i have no idea
[19:02:02] <ruggles> ok. that ac3 encoder demo you pointed me to is a pro tools plug-in...
[19:02:45] <kierank> really
[19:02:58] <kierank> i thought you could also use the app standalone
[19:03:06] <_av500_> ruggles: ask kshishkov to RE it
[19:03:25] <kierank> dolby actually has a consistent api so i could tell you it right now
[19:03:35] <kierank> _av500_
[19:04:07] <in3xes> Where is the soc repo?
[19:04:28] <in3xes> All the links redirect to git.ffmpeg.org
[19:04:44] <ruggles> _av500_: i don't need it RE'd. i just need to do some black-box comparisons.
[19:05:21] <ruggles> kierank: System Requirements: Pro Tools HD/LE/M-Powered 7.0 and later
[19:06:25] <kierank> this one right ? http://www.neyrinck.com/en/products/dolby-digital
[19:07:15] <kierank> you can ask bcoudurier as well if you want
[19:09:45] <BBB> ruggles: nice quality improvement there in your patches btw
[19:10:16] <ruggles> BBB: thanks
[19:47:37] <BBB> kshishkov: ping again
[19:47:54] <mru> BBB: ja == jump if cf=0 && zf=0
[19:48:33] <BBB> I didn't know that sub set the carry flag for unsigneds
[19:48:37] <BBB> if it does, that's fine
[19:48:46] <BBB> I think kshishkov was drunk when he wrote the vc1 decoder
[19:48:55] <BBB> we should buy him more wodka so he can get drunk again and fix it
[19:49:11] <BBB> he inverted horizontal and vertical logic for the loopfilter and the edge checks
[19:49:18] <roxfan> sub sets the same flags as cmp
[19:49:44] <BBB> that is, for the v loop filter, the one basically between a top and a bottom block, he checks left/right, and for the h loop filter, the one filtering between a left and a right block, he checks top/bottom
[19:49:54] <mru> "The OF, SF, ZF, AF, PF, and CF flags are set according to the result."
[19:50:23] <roxfan> and it doesn't distinguish signed and unsigned numbers... that's why you have two sets of some j instructions
[19:50:47] <roxfan> like ja and jg
[19:52:35] <BBB> that's what I thought
[19:52:42] <BBB> but ruggles says he tested it and it didn't crash or hang
[19:52:47] <BBB> if he tested it and it worked, then it's fine
[19:52:59] <BBB> I only care that it works
[20:40:06] <saintdev> mru: "Is it impossible to align the thing it points to now?" <--Right now, it points to _nothing_, it's uninitalized.
[20:40:30] <mru> yeah, I realised that
[20:40:36] <mru> you said alignment first
[20:40:54] <saintdev> that's what i thought it was before i was able to look into it more
[20:41:45] <spaam> lu_zero: data suport patch?
[20:42:13] <spaam> support
[20:44:04] <saintdev> BBB: I don't know enough about other codecs to say yes/no. AAC and MP3 more than likely could, they're similar enough.
[20:44:26] <lu_zero> spaam: sent on the ml weeks ago
[20:44:33] <lu_zero> supports -dcodec copy
[20:44:38] <saintdev> from what I understand of ac3 from ruggles, it probably could, but i'm not sure
[20:46:36] <ruggles> saintdev: what was the question?
[20:46:53] <saintdev> <BBB> saintd3v: does it make sense, and is it at all practically useful, to share psymodels between different audio encoders, e.g. ac3 and aac?
[20:47:55] <ruggles> if the same model could work with different band structures, then yes
[20:48:21] <saintdev> what about block switching?
[20:49:32] <ruggles> possibly. if it is made generic enough. i.e. separate transient detection and window size decision
[20:51:17] <ruggles> generic transient detection would be helpful regardless.  e-ac-3 has a way for the encoder to essentially manually reduce transient pre-noise by specifying their location and a portion of the signal to copy over the pre-noise.
[20:54:09] <ruggles> our current ac3 encoder doesn't seem to be very sensitive to pre-echo though, probably due to the way exponents are coded. but when you throw in channel coupling it does get worse.
[20:54:11] <saintdev> hmm, so we may need to modify the API and separate those
[20:58:37] * elenril sees no patches applied today
[20:58:41] * elenril blames BBB 
[20:59:16] * _av500_ hums: "the BBB took my patches away..."
[21:01:04] <kierank> "my the BBB cried...I'm taking your patches and flying away. Now elenril can't have his meta today..."
[21:01:12] <kierank> bye bye
[21:01:38] <elenril> i didn't work on any meta for at least a week =p
[21:01:58] <kierank> don't ruin american pie
[21:27:48] <spaam> RFC: if i trying to make a protocol for gz and bz2 files.. (-i gz:file)... should i have both in same file archive.c  or sperate (gz.c and bz2.c) ?
[21:28:28] <kierank> why are you doing that spaam
[21:28:30] <_av500_> spaam: only for local files? or also -igz:http://...
[21:29:25] <kierank> spaam: why not working on libavsequencer
[21:29:26] <spaam> kierank: i need to code something other then my .py script..
[21:29:46] <spaam> _av500_: local files is the plan first
[21:30:05] <wbs> spaam: if they can share some code, it's better to keep them in the same file, if not, it doesn't really matter much if you split them or not, perhaps rather split them then
[21:30:18] <spaam> _av500_: maybe it wont be hard to fix -igz:http:// later.
[21:30:37] <spaam> wbs: ok :)
[21:30:49] <wbs> spaam: just make sure it uses an URLContext for reading the input, then it's easy to plug in whatever other urlprotocol there
[21:31:40] <spaam> ok. thanks for the tip :)
[21:39:27] * Flameeyes waits for libffrar
[22:00:05] <saintdev> Flameeyes: wouldn't that be libavrar..
[22:00:38] <Flameeyes> saintdev: libavchive?
[22:01:36] <saintdev> only on potatoes, tyvm
[22:04:33] * saintdev holds out for libavace
[22:04:35] <Flameeyes> guh?
[22:27:48] <lu_zero> yawn
[22:28:07] * lu_zero made a small stupid thing that should do something like
[22:28:25] <lu_zero> while ((err = av_read_frame(ic, &pkt)) >= 0) { av_interleaved_write_frame(oc, &pkt); av_free_packet(&pkt); }
[22:28:42] <lu_zero> I let the reader guess what happens
[22:30:42] <mru> crashes or loops forever
[22:31:35] <lu_zero> first is right
[22:31:39] <lu_zero> guess why
[22:31:50] <mru> humour me
[22:34:01] <lu_zero> SIGFPE in av_frac_add, called by compute_pkt_fields2 ...
[22:34:28] * lu_zero is checking that the time_bases are copied over and they are...
[22:34:47] * lu_zero murmurs something about compute_pkt_fields2 trying to be smart
[22:37:15] <lu_zero> and what's wonderful is that gdb is confused by it being inlined
[22:42:10] * lu_zero sets a denominator to the st->pts and wonders why ist has 0/0...
[22:46:34] <CIA-36> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r66e5b1df36 ffmpeg/ (64 files in 2 dirs):
[22:46:34] <CIA-36> ffmpeg: avio: deprecate url_feof
[22:46:34] <CIA-36> ffmpeg: AVIOContext.eof_reached should be used directly instead.
[22:46:34] <CIA-36> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[22:46:40] <CIA-36> ffmpeg: Nathan Caldwell <saintdev at gmail.com> master * r31ff9bd7b8 ffmpeg/libavcodec/ (aacenc.c aacenc.h):
[22:46:40] <CIA-36> ffmpeg: aacenc: Fix a segfault in search_for_quantizers
[22:46:40] <CIA-36> ffmpeg: This reverts the removal of scoefs from AACEncContext.
[22:46:40] <CIA-36> ffmpeg: It resulted in scoefs being a NULL pointer when
[22:46:40] <CIA-36> ffmpeg: search_for_quantizers() is called.
[22:46:40] <CIA-36> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[22:48:00] <lu_zero> works =P
[23:26:10] <mru> ruggles: ping
[23:26:24] <ruggles> mru: pong
[23:26:34] <mru> is there something wrong with your mul64 patch?
[23:26:40] <mru> looks good to me
[23:26:44] <ruggles> nothing wrong. just unnecessary.
[23:26:53] <mru> using mul64 is good
[23:27:05] <mru> gcc is too stupid to use the fast instructions on many cpus
[23:27:15] <mru> like arm
[23:27:53] <mru> gcc insists on doing it the hard way even though there's a single instruction that does it
[23:28:32] <ruggles> the range of the coefficients is [-32768,32767] so the 32-bit multiply is fine
[23:28:43] <mru> you're misunderstanding
[23:28:56] <mru> arm has an instruction for 32x32->64 mult
[23:29:00] <mru> gcc doesn't use it
[23:29:40] <mru> actually, you should be using MAC64 there
[23:29:46] <mru> arm has an instruction for that too
[23:29:47] <ruggles> ah, i see. even though it converts to 64-bit to add to the sum.
[23:30:32] <roxfan> mla is 32-bit if you don't need 64
[23:30:56] <mru> there's also smlalbb for 64 += 16x16->32
[23:32:10] <roxfan> hmm https://bugs.launchpad.net/gcc-linaro/+bug/643479
[23:34:18] * lu_zero messes up another bit with libaformat
[23:35:08] <ruggles> yes, MAC64() seems to be the better thing to do
[23:35:34] <mru> if those values are really 16-bit we should add a macro for that too
[23:35:45] <mru> int64 += int16*int16
[23:40:14] <ruggles> i've gone over it several times, and i'm pretty sure they can't be outside 16-bit range. if they are, the encoder will be wrong. that's one of the added asserts that i recently sent a patch for.
[23:42:43] <BBB> btw
[23:42:43] <BBB> http://chromium.googlecode.com/issues/attachment?aid=-109601759276715865&name=threadfps.jpg&token=db915ec3f3f15c11b57a7b637b3433e1&inline=1
[23:42:45] <BBB> auch
[23:42:55] <BBB> our vp8 decoder beats libvpx with 2 threads
[23:43:01] <BBB> that's quite awesome
[23:43:10] <lu_zero> ^^;
[23:43:12] <lu_zero> nice
[23:43:20] <BBB> *almost beats
[23:43:22] <BBB> anyway
[23:43:26] <BBB> should implement that
[23:43:29] <saintdev> lol
[23:44:18] <gnafu> BBB: Very nice.
[23:46:38] <gnafu> BBB: How long 'til you start at Google?  The 28th?
[23:46:55] * gnafu can hardly wait for an xvp8 release.
[23:47:15] <BBB> I start the 28th
[23:47:24] <lu_zero> Seems stream 0 codec frame rate differs from container frame rate: 29.98 (65535/2186) -> 29.97 (10000000/333667)
[23:47:27] <lu_zero> wonderful
[23:50:06] <iive> BBB: you are going to work at google?
[23:52:51] <gnafu> iive: Yep.  Workin' on xvp8 :-D.
[23:55:23] <Compn> i'm confuse
[23:55:39] <Compn> why google hiring you to fix up vp8 encoder when they have all on2 staff? :P
[23:57:52] <BBB> I guess they're hoping that I can complement their staff in some way
[23:59:48] <saintdev> complement, as-in: "That's so cute. Now go play outside while the adults work on xvp8."