[FFmpeg-devel-irc] IRC log for 2010-05-19

[irc at mansr.com]

[00:07:01] <Kovensky> astrange: isn't jfs waiting on your comments; or did you already sent them to he and he's lazy/busy/stuck
[00:07:04] <Kovensky> send*
[01:18:59] <astrange> i sent them
[01:19:07] <astrange> he says he'll update it tomorrow or so
[04:15:51] <peloverde_> Could the first two frames in a stream having the same dts be related to the first frame being a "no frame!"?
[04:47:28] <hyc> grumble... OK, I sent an FLV file to ffserver, and saved the transcoded data from its feed.ffm
[04:47:49] <hyc> then I ran ffmpeg on that, -vcodec copy / -acodec copy to a new FLV file
[04:48:06] <hyc> the live feed played fine over rtsp with ffserver
[04:48:30] <hyc> but still, trying to play the new FLV over rtsp fails with all kinds of garbage
[04:49:31] <hyc> and I've fixed the sdp_write_media_attribute() to send the sps/pps for the FLV case, and wireshark shows that this is now identical to the live streaming case
[05:03:11] <hyc> playing audio-only from a file works
[05:04:02] <hyc> so it's only H264 video causing trouble
[05:30:06] <peloverde> Why does it make sense to set stream start_time based solely on the first audio packet when the vcodec is h.264 and pts is missing?
[05:48:50] <hyc> ok. rtpenc_h264.c only knows how to handle H264 NALs that start with the 3 byte startcode
[05:49:00] <hyc> it doesn't know anything about AVC1
[05:49:25] <av500> teach it :)
[05:49:45] <hyc> trying to...
[05:50:17] <hyc> unfortunately it seems that AVC1 NALs start with the NALU length, but the size of that length is not constant
[05:50:35] <hyc> gotta see how avcodec/h264.c determines the length
[05:50:40] <av500> it is given in the extradata
[05:50:51] <av500> nal_unit_length or so
[05:51:02] <hyc> so it's constant for the entire stream?
[05:51:08] <av500> I thinkl so
[05:51:16] <hyc> I don't think rtpenc_h264 has access to the extradata
[05:51:16] <av500> I read it once
[05:51:23] <hyc> but will dig into that
[05:51:33] <hyc> thx for the pointer
[06:18:18] <hyc> av500; success!
[06:26:59] <wbs> mru: don't think I've ever heard about a krongädda before, actually
[06:27:20] <wbs> mru: but on the other hand, it's over 10 years since I was fishing the normal kind of gädda last time, too
[06:30:08] <superdump> morning
[06:40:46] <benoit-1> hej superdump
[06:43:29] <peloverde> Is there an obvious reason why H.264 remuxed by ffmpeg would crash MPC and make Haali Splitter refuse to see the video track?
[06:47:42] <CIA-7> ffmpeg: benoit * r23170 /trunk/libavcodec/ivi_common.h:
[06:47:42] <CIA-7> ffmpeg: Fix signedness of q_delta field of the IVIMbInfo.
[06:47:42] <CIA-7> ffmpeg: Patch by Maxim max_pole () gmx * de
[06:47:58] <hyc> peloverde: remuxed to what container?
[06:48:05] <peloverde> mp4
[06:48:20] <hyc> mebbe it's tripping over the same H264 vs AVC1 variant nonsens that I was just struggling with
[06:49:07] <peloverde> That is possible I suppose
[06:50:37] <peloverde> There was a "no frame!" at the beginning but the source (ASF) file plays fine in WMP and MPC
[07:04:55] <kshishkov> benoit-1: thanks
[07:32:09] <peloverde> hyc: looks like you were at least partially right
[07:32:45] <hyc> wow, that's pretty good for me on this channel ;)
[07:34:19] <wbs> hyc: btw, your sdp/rtp/h264 patch has some reindenting in rtpenc_h264.c
[07:34:56] <wbs> other than that, I let the ones knowledgeable on h264 bitstream formats comment on what to do in this case
[07:35:23] <peloverde> now I get to play the, how do I put the mov demuxer in atom tree mode game again (I really should write it down)
[07:35:35] <hyc> wbs: yes, I couldn't decide whether to fix all the indenting or to leave it for a separate commit
[07:35:52] <hyc> that stuff is easy, it seemed more important to have a readable patch for now
[07:36:36] <wbs> yeah, but it still is easier to see that the original code is unmodified in the !is_avc if fork if you don't change its indentation, even if it is just 10 lines
[07:36:43] <hyc> well, now I know why there's an endless stream of "non-existing PPS referenced" messages
[07:37:07] <hyc> the parser is using its own H264Context, separate from the one that was created for the AVCodecContext.
[07:37:25] <hyc> only the AVCodecContext has teh extradata that was parsed by the decoder_init
[07:38:06] <wbs> which parser is this, one i ffserver?
[07:38:12] <hyc> loosely-coupled systems with isolated APIs only work when they're actually coupled .....
[07:38:20] <hyc> this is libavcodec/h264_parser.c
[07:41:07] <peloverde> The strange part is that there is an avcC atom here, it's just getting lost in the shuffle
[07:41:26] <wbs> yes, but the missing extradata from the parser, where is that parser instantiated? or does the parser never read extradata at all?
[07:41:34] <hyc> never
[07:41:43] <wbs> oh, goodie
[07:41:44] <hyc> av_parser_init() only takes a codec_id
[07:41:56] <hyc> this API is really f#cked
[07:42:04] <peloverde> Is stts supposed to have 1000s of entries?
[07:42:10] <wbs> so whenever the h264 parser is used with h264 that has extradata, one will get those errors
[07:42:15] <hyc> yep
[07:42:38] <hyc> (was answering wbs. dunno answer to peloverde)
[07:43:29] * peloverde dusts of -12, -14, and -15
[07:43:40] <peloverde> s/of/off/
[07:44:37] <wbs> peloverde: possibly, if not all samples have equal duration
[07:45:04] <peloverde> I have a terrible feeling that this stream is being treated as VFR
[07:45:26] <hyc> the parsers are always called with both an AVCodecParserContext and AVCodecContext argument. perhaps should just change h264_parser to only look at the avcodeccontext
[07:46:42] <Yuvi> Last time I tried h264 to mp4 there were +-1 timestamp rounding errors from somewhere
[07:47:14] <wbs> haha, wtf.. that youtube rtsp url that had non-monotone packet ordering, is suddenly sending all the packets properly ordered again ;P
[07:49:58] <hyc> great.... bug on their end?
[07:50:18] <peloverde> Yuvi: Is there a good way to deal with +/-1 timestamp issues?
[07:50:28] <wbs> it's google, nobody will know if it's a bug or if it's intentional "tweaking" ;P
[07:52:42] <Yuvi> peloverde: Dunno, fix the raw h264 demuxer? Iirc they were due to the multiple timebases it sets up
[07:53:38] <peloverde> This file is coming in from the asf demuxer :/
[07:54:13] <Yuvi> Doesn't asf usually use 1/1000 timebases?
[07:54:27] <Yuvi> Which would also explain it
[07:59:15] <CIA-7> ffmpeg: siretart * r23171 /branches/ (57 files in 9 dirs):
[07:59:15] <CIA-7> ffmpeg: mov: Read nero chapters
[07:59:15] <CIA-7> ffmpeg: backport r23020 by conrad
[08:02:07] <elenril> o_0 57 files?
[08:02:55] <CIA-7> ffmpeg: siretart * r23172 /branches/ (0.6/libavformat/movenc.c 0.6):
[08:02:55] <CIA-7> ffmpeg: movenc: Swap positions of mov_write_header and mov_write_packet
[08:02:55] <CIA-7> ffmpeg: backport r23021 by conrad
[08:02:55] <CIA-7> ffmpeg: siretart * r23173 /branches/ (0.6/libavformat/movenc.c 0.6):
[08:02:55] <CIA-7> ffmpeg: movenc: Write QuickTime chapters
[08:02:56] <CIA-7> ffmpeg: backport r23022 by conrad
[08:02:59] <peloverde> roozhou seems to have some patches for this stuff? has he submitted them?
[08:03:15] <kshishkov> you haven't seen FATE specs committed to SVN, have you?
[08:04:05] <KotH> grüezi wohl
[08:04:13] <CIA-7> ffmpeg: siretart * r23174 /branches/ (4 files in 2 dirs):
[08:04:13] <CIA-7> ffmpeg: Make av_strerror() return -1 even in the case when av_strerror_r() is
[08:04:13] <CIA-7> ffmpeg: not defined.
[08:04:13] <CIA-7> ffmpeg: This allows applications to check if av_strerror() cannot provide a
[08:04:13] <CIA-7> ffmpeg: meaningful representation for the provided error code, without having
[08:04:14] <CIA-7> ffmpeg: to actually check the filled string.
[08:04:15] <CIA-7> ffmpeg: backport r23031 by stefano
[08:04:15] <CIA-7> ffmpeg: siretart * r23175 /branches/ (0.6 0.6/cmdutils.c):
[08:04:16] <CIA-7> ffmpeg: Make print_error() use strerror() in case av_strerror() fails.
[08:04:16] <CIA-7> ffmpeg: Should provide a meaningful error message for systems which do not
[08:04:17] <CIA-7> ffmpeg: support strerror_r().
[08:04:17] <CIA-7> ffmpeg: Fix roundup issue #1894.
[08:04:18] <CIA-7> ffmpeg: backport r23032 by stefano
[08:04:52] <CIA-7> ffmpeg: siretart * r23176 /branches/ (0.6 0.6/cmdutils.c):
[08:04:52] <CIA-7> ffmpeg: Simplify print_error(), directly use av_strerror()/strerror() for
[08:04:52] <CIA-7> ffmpeg: printing the error code associated to FF_NETERROR(EPROTONOSUPPORT).
[08:04:52] <CIA-7> ffmpeg: backport r23033 by stefano
[08:05:28] <CIA-7> ffmpeg: siretart * r23177 /branches/ (0.6 0.6/cmdutils.c):
[08:05:28] <CIA-7> ffmpeg: Reindent after the last commit.
[08:05:28] <CIA-7> ffmpeg: backport r23034 by stefano
[08:06:49] <siretart> ok. seems my backport script indeed works :-)
[08:08:50] <wbs> siretart: would you be interested in backporting 23160 - 23165, too? you could perhaps want to wait a few days with that, though, since it hit svn yesterday
[08:09:27] <wbs> on a distro-installed ffmpeg package, that's an end-user feature that makes ffmpeg replace MP4Box for the one feature I've been using it for
[08:10:47] <siretart> wbs: thanks for the hint, scheduled for review&backporting
[08:11:41] <siretart> technically, I'm "ticking" (flagging) backport candidates in my ffmpeg-cvs mailbox. my backport script presents me the log message and the diff, so I can review, compile and test in place
[08:11:50] <wbs> ah, nice. :-)
[08:12:08] <siretart> if you know more revisions to backport, just tell me on irc or on the mailing list
[08:13:04] <CIA-7> ffmpeg: mstorsjo * r23178 /trunk/Changelog: Add a changelog entry for the RTP hinting in the mov muxer
[08:14:02] <CIA-7> ffmpeg: mstorsjo * r23179 /trunk/libavformat/avformat.h: Late bump of the minor version, for the addition of AVFMT_FLAG_RTP_HINT
[08:16:38] <siretart> btw, sorry for the delay of 0.6, I've already told diego that I got terribly distracted by real life issues. I'm trying to catch up this week and finally get it out by this week end (though, no promises!)
[08:17:14] <CIA-7> ffmpeg: mstorsjo * r23180 /trunk/doc/APIchanges: Add an APIchanges note regarding the new rtp hinting flag
[08:17:23] <siretart> the fact that mplayer doesn't compiled against a shared libswscale from ffmpeg 0.6 is annoying, though.
[08:17:44] <wbs> woohoo, 100th commit with my own svn account \o/
[08:18:02] <siretart> congrats
[08:18:03] <siretart> :)
[08:18:19] <wbs> thanks :-)
[08:18:30] <hyc> wbs: fixed the non-existing PPS bug...
[08:18:35] <twnqx> siretart: the fact that mplayer can't play pgssub is FAR FAR FAR more annoying
[08:19:04] <twnqx> and uau doesn't want to give me his existing patches so i can't wotk on that :(
[08:19:51] <siretart> twnqx: I guess he publishes a git repo with the patches, no?
[08:19:59] <twnqx> those aren't in a repo yet
[08:20:05] <siretart> great :/
[08:20:18] <twnqx> i'll bug him again some time :)
[08:20:28] <spaam> dont you like uau sometime? :P
[08:20:34] <twnqx> oh, i do
[08:20:44] <twnqx> alone for the fact that his mplayer builds against ffmpeg-mt
[08:21:24] <twnqx> yet need to figure out why my last build refused to play bluray pcm audio...
[08:21:36] <twnqx> i know it did before :P
[08:21:42] <hyc> I'm pretty happy that his mplayer builds with librtmp ...
[08:25:24] <Tjoppen> if bultje ok's my http patch, would that be something that goes into 0.6?
[08:30:01] <kshishkov> wbs: it's what you actually commit that counts
[08:30:31] <wbs> kshishkov: true, but most of my commits have actually been new features, that at least I'm interested myself ;P
[08:31:56] <kshishkov> the best kind!
[08:32:19] * kshishkov hopes he also has made 100 useful commits so far
[08:32:51] <wbs> your commits, however many or few they are, are probably way more useful to a much larger audience, than mine. :-)
[08:36:46] <peloverde_> most of my 294 commits replace a library that works just fine
[08:37:00] <peloverde_> asf->264->mp4 works fine, hmmm
[08:38:58] <peloverde_> oh, because it totally blew away my fps
[08:59:23] <hyc> wbs: unfortunately my avcodec patch only works for ffplay, not mplayer
[08:59:53] <hyc> if mplayer is using libnemesi or liveMedia then the wrong AVCodecContext handles are present
[09:07:15] <av500> hyc: I was just asking myself whether a bitstream filter has access to extradata at all?
[09:07:32] <av500> (while sitting in a dentists chair - me, not the bitstream filter)
[09:08:11] <wbs> av500: the h264 mp4 to annex b bitstream filter sure does something with extradata
[09:08:19] <av500> ok
[09:08:26] <hyc> av500: you can IRC from a dentist's chair? talk about self control...
[09:08:35] <wbs> but I don't know if it actually is allowed to change extradata, or just change packet data as it flows through
[09:08:37] <av500> hyc: :)
[09:08:39] <kshishkov> av500, are you trying to ask questions in extreme environment?
[09:09:18] <av500> i figure dentist to ffmpeg-devel is two of the most extreme environs, no?
[09:09:25] <hyc> lol
[09:09:40] <hyc> anyway yes, looking at the mp4toannexb code, it can be done
[09:09:57] <hyc> but that's parsing the extradata yet another time, and keeping yet another private copy of the result
[09:10:52] <av500> (but dentist is luckily over...)
[09:11:08] <hyc> and every packet sent thru does an alloc_and_copy. I think it's pretty gross...
[09:11:26] <hyc> which I suppose also applies to dentist visits ;)
[09:12:06] <av500> can you spell root canal....
[09:12:14] <hyc> auuuuugggghhhh
[09:12:19] <hyc> I think it's something like that
[09:13:56] <hyc> wbs: heisenbug - by observing it too closely, you sent it back into hiding...
[09:14:06] <hyc> (rtp pkt ordering...)
[09:14:12] <wbs> yeah, probably
[09:14:19] <wbs> or someone from google is reading the mailing list :-)
[09:14:28] <hyc> heh
[09:47:22] <CIA-7> ffmpeg: mstorsjo * r23181 /trunk/libavformat/rtsp.c:
[09:47:22] <CIA-7> ffmpeg: Fix a crash when opening WMS RTSP streams
[09:47:22] <CIA-7> ffmpeg: Fixes issue 1948
[09:49:50] <Kovensky> <peloverde_> asf->264->mp4 works fine, hmmm <-- yea, weird, isn't it :)
[09:50:07] * Kovensky probably missed something
[09:51:14] <wbs> siretart: you probably want to pick 23181 to 0.6, too, since it fixes a crash
[09:52:39] <siretart> wbs: excellent. that would have qualified even for a point release :-)
[09:53:04] <wbs> :-)
[09:53:15] <thresh> moo siretart. any plans on having decent ffmpeg on debian, say, sid? :)
[09:53:18] <wbs> it's not relevant for 0.5 though, it's new code we added a few weeks ago
[09:53:24] <thresh> decent == supporting h264 in vaapi ;-)
[09:53:30] <siretart> thresh: after squeeze release, sure
[09:55:21] <siretart> thresh: if you insisted on pushing ffmpeg 0.6 into squeeze, I would have to ask you to verify to not break existing applications in squeeze. fixing mplayer (which is based on the rc3 branch) would be a good start ;-)
[09:55:51] <thresh> siretart: naaah, I'd rather had 0.6 packages for experimental ;)
[09:56:02] <siretart> thresh: already uploaded
[09:56:08] <thresh> oh
[09:56:10] <thresh> :-)
[09:56:20] <siretart> still not accepted, though
[09:56:43] <thresh> so I have to poke someone to upload libva and vdpau-video
[09:56:52] <thresh> then, I could use debian
[09:57:29] <siretart> are these two already packaged and tested? If they were in the pkg-multimedia team git, I would take a look.
[09:58:21] <thresh> siretart: http://bugs.debian.org/569635 IIRC
[09:59:11] <siretart> oh right, I knew I had seen it before. ok, the ball is indeed in my camp
[09:59:20] <siretart> you'd need both packages?
[09:59:22] <thresh> and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569641
[09:59:36] <thresh> siretart: yes, the second one is needed to support nvidia cards
[09:59:50] <thresh> IIRC there is a support for fglrx as well by means of a separate project
[10:00:24] <siretart> thresh: I build them, if you would test them for me, I'd sign and upload them. deal?;-)
[10:00:32] <thresh> siretart: sure!
[10:00:37] <siretart> i386 or amd64?
[10:00:41] <thresh> amd64
[10:01:14] <thresh> ah, here it is, xvba-video: http://www.splitted-desktop.com/~gbeauchesne/xvba-video/
[10:01:31] * Kovensky wonders why is that not merged so far
[10:01:34] <Kovensky> that branch is over a year old
[10:02:15] * Kovensky pokes __gb__ 
[10:02:35] <thresh> siretart: we could probably also talk in #d-m at oftc ;-)
[10:02:52] <siretart> thresh: sure
[10:07:55] <siretart> thresh:  http://siretart.tauware.de/~siretart/upload-queue/ - libva is already there, vdpau-video is still building
[10:08:19] <siretart> oh, vdpau-video fails to build because of missing libva-dev :/
[10:38:11] <spaam> siretart: are those packages going into some kind of repo? :)
[10:39:31] <siretart> spaam: yes. in git repos on git.debian.org, pkg-multimedia namespace
[10:40:12] <spaam> siretart: so it will hit unstable in the summer ? :)
[10:40:46] <siretart> spaam: depends on a number of factors
[10:41:40] <spaam> siretart: like?
[10:42:43] <siretart> packages being tested, me finding time to review& upload, ftp-masters to accept,  etc.
[10:43:17] <spaam> ah ok.  :)
[10:44:02] <__gb__> hi KotH
[10:45:00] <__gb__> humm, no, sorry Kovensky :)
[10:46:27] <spaam> siretart: going to test it later when vdpau thing is done :)
[10:47:27] <thresh> ;)
[10:47:36] <janneg> fuck. the highest german court paved the way for software patents
[10:51:56] <siretart> janneg: link?
[10:52:06] <janneg> siretart: www.heise.de/newsticker/meldung/Bundesgerichtshof-ebnet-Weg-fuer-Softwarepatente-1003190.html
[10:53:03] <janneg> they reversed a decision of the - already lax on software patents - patent office and patent court
[10:54:23] <siretart> that's seems indeed very bad news :-(
[10:55:32] <av500> dont despair, just add them to the list of people that go 1st against the wall when revolution comes..
[10:56:11] <thresh> ..right after the journalists.
[11:00:17] <siretart> thresh: spaam: http://siretart.tauware.de/~siretart/upload-queue/ - now contains upload candidates for libva and vdpau-video. please give me feedback; if they work for you, I'll upload to unstable
[11:00:27] <metiu_> hi, I've got ffmpeg streaming on rtp which stops for a while (30s)
[11:00:36] <thresh> siretart: \o/ will do.
[11:00:43] <metiu_> i strace()d it to a read(/dev/random, 6)
[11:00:59] <metiu_> does it need such randomness?
[11:01:07] <metiu_> (git HEAD btw)
[11:04:11] <spaam> siretart: only i386..  i have amd64 :)
[11:07:33] <thresh> yeah, vdpau-video is i386 only there :(
[11:10:02] <siretart> d'oh - now pushed. reload
[11:10:41] <spaam> nice
[11:12:54] <__gb__> thresh, IIRC it works on my amd64 system, what is the problem?
[11:13:26] <thresh> __gb__: I was referring to siretart's built packages
[11:13:32] <thresh> __gb__: and it also works on amd64 for me ;)
[11:14:29] <__gb__> ah ok :) btw, I noticed his packages are quite old (vdpau-video 0.6.3 vs. 0.6.9)
[11:15:02] <thresh> yeah, shouldnt be too hard to update though.
[11:15:17] <thresh> should libva also be updated?
[11:20:33] * KotH pokes __gb__
[11:20:36] <KotH> ;)
[11:22:22] <__gb__> thresh, probably, I have not checked what version he used
[11:23:03] <thresh> 1.0.1
[11:37:09] <spaam> siretart: works great with latest vlc-git-head and latest ffmpeg.  i get around 40% cpu usage drop :)
[11:39:11] <CIA-7> ffmpeg: siretart * r23182 /branches/ (0.6/libavcodec/aaccoder.c 0.6):
[11:39:12] <CIA-7> ffmpeg: Make the faac inspired quantizer search make sense for a slightly narrower definition of "make sense."
[11:39:12] <CIA-7> ffmpeg: backport r23035 by alexc
[11:39:12] <CIA-7> ffmpeg: siretart * r23183 /branches/ (0.6 0.6/libavcodec/aacenc.c):
[11:39:12] <CIA-7> ffmpeg: Error out when too many bits per frame are requested.
[11:39:12] <CIA-7> ffmpeg: backport r23036 by alexc
[11:39:49] <CIA-7> ffmpeg: siretart * r23184 /branches/ (0.6/libavcodec/aaccoder.c 0.6):
[11:39:49] <CIA-7> ffmpeg: 10l: store the result of clipping added in r23035
[11:39:49] <CIA-7> ffmpeg: backport r23037 by alexc
[11:41:22] <siretart> spaam: what did you test exactly? vdpau-video or just libva?
[11:44:48] <spaam> siretart: what i did was recompile ffmpeg, vlc .  then deactivated "accelerated video output" in perferences in vlc..  open my avril 1080p video..  watched the video and top..  then activete acceleration  and did the same thing :)
[11:45:36] <CIA-7> ffmpeg: siretart * r23185 /branches/ (0.6/libavformat/asfdec.c 0.6):
[11:45:36] <CIA-7> ffmpeg: Favor chunk size over hitting the correct position after reading the chunk size in asf.
[11:45:36] <CIA-7> ffmpeg: Fixes issue1923
[11:45:36] <CIA-7> ffmpeg: backport r23040 by michael
[11:47:26] <siretart> spaam: using 'my' packages, that is?
[11:47:28] <CIA-7> ffmpeg: siretart * r23186 /branches/ (0.6/cmdutils.h 0.6):
[11:47:28] <CIA-7> ffmpeg: Document cmdutils.c:print_error().
[11:47:28] <CIA-7> ffmpeg: backport r23051 by stefano
[11:47:37] <spaam> siretart: yes :)
[11:47:44] <siretart> okay, that works for me :-)
[11:48:31] <lu_zero> siretart: I just noticed git notes
[11:49:02] <siretart> lu_zero: sorry?
[11:49:08] <lu_zero> with that the obnoxious "edit/redact commit messages" requirement is fulfillable =)
[11:49:33] <janneg> english report of the german court ruling re sw patents http://fosspatents.blogspot.com/2010/05/german-high-court-declares-all-software.html
[11:50:30] * lu_zero was idling reading git release notes
[11:52:34] <siretart> spaam: okay, package uploaded
[11:52:54] <lu_zero> btw good day ^^
[12:47:31] <hyc> ok, simple fix for ffserver's I/O loop, no more CPU hogging
[13:30:26] <CIA-7> ffmpeg: siretart * r23187 /branches/ (0.6 0.6/libavcodec/avcodec.h):
[13:30:26] <CIA-7> ffmpeg: Another try for fixing/improving decode_video documentation.
[13:30:26] <CIA-7> ffmpeg: backport r23057 by reimar
[13:31:20] <CIA-7> ffmpeg: siretart * r23188 /branches/ (0.6 0.6/configure):
[13:31:20] <CIA-7> ffmpeg: Remove hardcoded-tables hack for IA-64: with latest binutils that now actually
[13:31:20] <CIA-7> ffmpeg: causes linking errors instead of avoiding them.
[13:31:20] <CIA-7> ffmpeg: backport r23058 by reimar
[13:44:25] <CIA-7> ffmpeg: siretart * r23189 /branches/ (0.6 0.6/cmdutils.c):
[13:44:25] <CIA-7> ffmpeg: Fix build with swscale disabled
[13:44:25] <CIA-7> ffmpeg: backport r23062 by mru
[13:50:49] <siretart> hm. since when does 'make test' *require* libswscale?
[13:50:57] <mru> since a long, long time
[13:51:36] <siretart> k
[13:52:14] <mru> the "ffmpeg" executable requires it
[13:52:31] <mru> you can disable it if you only need e.g. lavc
[13:52:45] <CIA-7> ffmpeg: siretart * r23190 /branches/ (0.6/tools/qt-faststart.c 0.6):
[13:52:45] <CIA-7> ffmpeg: qt-faststart: Avoid leaking memory if encountering a file with double ftyp atoms
[13:52:45] <CIA-7> ffmpeg: backport r23065 by mstorsjo
[14:02:43] <av500> ha, finally: http://cdrecord.berlios.de/private/R-3.0.html
[14:03:15] <kshishkov> and close in time to new IJG version
[14:04:02] <twnqx> :X i failed to write a dvdiso to a bd-rw recently
[14:04:52] <mru> I've had my fun with schilling
[14:07:20] <mru> I'm a bit disappointed the ijg guy doesn't read my blog...
[14:08:41] <KotH> av500: omg... the intro contains more buzzwords than our sales uses in any offer he writes
[14:11:26] <kshishkov> KotH: time to fire your sales rep?
[14:11:43] <mru> KotH: shame you missed that epic flamewar at linuxtag a few years ago
[14:12:24] <KotH> kshishkov: nah.. he's cool
[14:12:31] <KotH> kshishkov: killed 3 people with his bare hands
[14:12:33] <Compn> mru : are you going to put some news entry up on ffmpeg.org about coming to see you guys at linuxtag?
[14:12:49] <KotH> mru: i'm quite sure i'll miss something again this year :)
[14:13:58] <mru> Compn: I guess I should
[14:15:20] <siretart> mru: the flamewar went on at the last two cebit exhibitions
[14:15:25] <av500> mru: can you re-enact it?
[14:15:40] <mru> av500: I could try if I find him again
[14:15:46] <mru> he's easily baited
[14:16:12] <mru> siretart: schilling trolls cebit too?
[14:17:15] <siretart> mru: so I was told. with legal tricks, threats and everything.
[14:19:13] <mru> my "discussion" with him was mostly about why IDE drives shouldn't be addressed with scsi triplets, why using buffer-underrun recovery is better than burning a coaster, and why Linux can't be expected to retain old bugs for the sake of one application relying on them
[14:20:17] <twnqx> but ide drives are just scsi drives to the kernel... these days
[14:20:22] <twnqx> he was just ahead of his time!
[14:20:32] <mru> yes, but they don't have bus/target/lun addresses
[14:20:48] <mru> they have /dev/sdX names
[14:20:57] <twnqx> ah, that's what you're refering to
[14:20:58] <twnqx> right
[14:21:12] <twnqx> though you can i think use bus/target/lun
[14:23:43] <av500> mru: but where do the luns end up in /dev/sdX
[14:24:31] <mru> av500: different X
[14:24:55] <twnqx> hm
[14:24:59] <mru> of course most devices have only one lun
[14:25:04] <twnqx> wasn't the case for the only device i ever had with luns :X
[14:25:19] * av500 once had 18 luns to manage
[14:25:25] <twnqx> ... 18?
[14:25:47] <mru> I've never seen a CD drive with more than one
[14:25:54] <twnqx> i... did
[14:25:59] <twnqx> it was a scsi cd changer, though
[14:26:05] <av500> 3x teac CD-C68E ... http://www.dansdata.com/changer.htm
[14:26:05] <mru> explains it
[14:26:09] <av500> and it was IDE
[14:28:25] <thresh> siretart: being a noob in debian, is there a way to use your http://.../upload-queue as a source dir for apt?
[14:29:26] <twnqx> wow, BD-Rs dropped to 1.80€
[14:35:44] <mru> 25G?
[14:36:15] <twnqx> yeah
[14:36:56] <twnqx> and that's verbatim, not noname
[14:37:14] <mru> cheaper than flash at least
[14:37:53] <twnqx> yeah
[14:38:08] <twnqx> i wonder if they'll reach parity with HDDs
[14:38:41] <mru> optical discs have one distinct advantage over HDDs
[14:38:45] <mru> you can mail them easily
[14:39:01] <mru> or store them in dense stacks
[14:39:21] <mru> although not more dense than hdd
[14:39:54] <twnqx> i wonder if they have longer shelf life than hdds
[14:40:39] <mru> before or after burning?
[14:41:39] <kshishkov> well, one of the cheapest brands here meant "a hope" when translated
[14:41:52] <twnqx> after, and hdds filled :P
[14:43:33] <mru> kshishkov: in the same spirit as naming a famous soviet newspaper "truth"?
[14:44:51] <kshishkov> mru: no, original name was "Esperanza" and most people didn't get it here
[14:45:59] <KotH> well..not everyone is as lingofil as ffmpeg developers
[14:46:15] <siretart> thresh: no, but I'd suggest you issue a 'dget http://.../$package.changes', which downloads all files referenced from that changes file
[14:52:52] <KotH> kshishkov: apropos weird names
[14:53:12] <KotH> kshishkov: there is a japanese restaurant here, that calls itself "sukebe"
[14:53:59] <KotH> kshishkov: the owner has been asked in an interview once, what the name means, his answer was literaly "don't know, something asian... but it sounds cool"
[14:54:18] <mru> does it mean anything?
[14:54:51] <KotH> perverted old man
[14:54:57] <mru> lol
[14:55:03] <mru> is the place any good?
[14:55:12] <KotH> dont know
[14:55:24] <KotH> i refuse to enter an japanese restaurant where the owner isnt japanese
[14:55:31] <mru> good policy
[14:55:34] <KotH> or at least the staff
[14:55:37] <kshishkov> KotH: well, and the famous Chinese Restaurant called "Translation server error"
[14:55:47] <av500> KotH: or at least the food?
[14:55:58] <kshishkov> also good policy is to avoid restaurants with menus translated into Russian
[14:56:07] <mru> the nationality of the owner doesn't really matter as long as the chefs are genuine
[14:56:09] <KotH> av500: doesnt matter whether the food is japanese or not, if the staff isnt japanese it wont taste good
[14:56:50] <kshishkov> av500: it's like audiophile thing - it won't sound good on speakers from wrong company
[14:57:00] <KotH> lol
[14:57:21] <KotH> kshishkov: if you make it to zh once, i'll shwo you around some japanese restaurants
[14:57:25] <mru> last time I was at one of the better indian restaurants here the waitress was romanian
[14:57:27] <av500> kshishkov: I think mru even insists of a specific md5sum implementation to "listen" to audio
[14:57:27] <hyc> hey, don't make me pull out my spectrographic analysis of taste bud excitation
[14:58:01] <kshishkov> sounds _very_ related to speech codecs :P
[14:58:15] <KotH> kshishkov: or ask ivan to get you good and bad japanese food
[14:58:55] <mru> KotH: you know ivan?
[14:59:11] <KotH> mru: depends on which ivan you mean
[14:59:37] <av500> aacivan?
[15:01:05] <mru> I know of only one ivan easily associated with kshishkov and japanese
[15:01:29] <KotH> and which one would that be?
[15:01:35] <kshishkov> mru: there are two Ivans here, one is AAC creator indeed
[15:01:47] <kshishkov> *AAC encoder
[15:02:07] <mru> kshishkov: yes, but only one of them has a japanese wife afaik
[15:02:57] <kshishkov> that's another Ivan then, the one you've spoken to
[15:03:07] <mru> I've spoken to both
[15:03:15] <KotH> mru: then it's the right ivan :)
[15:03:17] <kshishkov> KotH also should know him
[15:03:22] <KotH> "know"
[15:03:43] <KotH> all i know about him is that he has a japanese wife, his bank account number and that he got me a dvd box
[15:03:52] <KotH> oh.. and the company he works for
[15:04:28] <av500> I hope it was not home videos...
[15:05:10] <KotH> nope
[15:05:53] <KotH> it was a tv series, nearly as old as i am
[15:06:15] <kshishkov> 50% chance it to be "Hyper Police"
[15:06:35] <KotH> lol
[15:06:47] <KotH> i'm older than Dark_Shikari :-)
[15:07:02] <thresh> not a valid point, almost everyone are :P
[15:07:10] <KotH> hehe
[15:07:19] <KotH> kshishkov: but how come you think it's hp?
[15:07:21] <spaam> how old are Dark_Shikari ? :) 22? :)
[15:07:36] <KotH> are?
[15:07:41] <kshishkov> KotH: that's your favourite anime
[15:07:41] <KotH> are they multiple entities?
[15:07:46] <KotH> kshishkov: rotfl...
[15:07:51] <spaam> KotH: .. is :P
[15:08:01] <KotH> kshishkov: it's one of the funny ones.. and a good namespace :)
[15:08:16] <KotH> kshishkov: but HP is an end 90s anime
[15:08:44] <av500> KotH: i have the dvd box of this: http://en.wikipedia.org/wiki/Ulysses_31 might match your age better
[15:09:08] <kshishkov> av500: go to #mplayerdev
[15:09:27] <av500> but its french, not japanese :)
[15:09:31] <KotH> av500: oh...
[15:09:36] <KotH> av500: damn!
[15:09:41] <KotH> av500: i'm looking for that one
[15:09:56] <kshishkov> anyway, continue without me
[15:10:06] <av500> how can we?
[15:10:18] <twnqx> hyper police...
[15:10:38] <av500> well, its french-japanese, but the DVDs I have are only french iirc
[15:12:00] <KotH> pah!
[15:12:07] * KotH throws a zagor hammer at av500 
[15:12:17] <av500> ah, now we are talking
[15:12:30] <av500> alan ford anybody?
[15:17:28] <KotH> nope
[15:17:40] <KotH> too old and not enough japanese for my taste
[15:17:56] * av500 is old
[15:18:06] * av500 not enough japanese
[15:18:10] * KotH knows
[15:18:22] <KotH> you arent exactly my taste either
[15:18:38] <mru> you tasted?
[15:18:54] <av500> I deny everything
[15:19:15] <KotH> mru: dont ask inapropriate questions
[15:20:42] <thresh> mru: I see a check_ldflags for -Wl,-Bsymbolic. In which case it actually goes in a link line?
[15:21:20] <mru> if the linker accepts the flag, it gets used
[15:23:29] <thresh> thx, weird
[15:26:51] <mru> what's weird?
[15:29:36] <thresh> nevermind, me stupid again
[15:41:33] <peloverde_> first googleIO keynote in 20 minutes
[15:42:03] <mru> wake me when it's over
[15:42:36] <mru> keynote = pretentious prick telling everybody how great he is
[15:49:35] <JEEBsv> Pretty much
[16:02:34] <janneg> http://code.google.com/p/webm/downloads/detail?name=mplayer-vp8-encdec-support-r1.tar.bz2&can=2&q=
[16:03:17] <peloverde_> Anybody want to start reviewing the patches? ;)
[16:04:39] <av500> so, it will be MKV
[16:07:29] <janneg> just patches to add libvpx support
[16:07:41] <av500> grah
[16:08:19] <av500> but kudos for not using pkgconfig!
[16:08:36] <Dark_Shikari> so guys, in one hour I'm going to need to borrow you all for a bit
[16:08:45] <av500> :)
[16:08:47] <Dark_Shikari> I have my in-depth vp8 analysis ready
[16:08:52] <Dark_Shikari> I will need /., reddit, etc, etc submissions
[16:08:55] <av500> lol. I was download #6 on that website
[16:09:00] <Dark_Shikari> I am free to release it in exactly one hour
[16:09:12] <av500> Dark_Shikari: I dont care about reddit, when will there be native ffmpeg support?
[16:09:18] <twnqx> lol
[16:09:24] <Dark_Shikari> av500: hopefully never, it's not very good
[16:09:42] <janneg> and bloating avcodeccontext with >10 parameter
[16:10:04] <av500> ->number_of_golden_frames_per_foo_bar?
[16:10:06] <peloverde_> It's got to be better than VP3
[16:10:16] <Dark_Shikari> ok, so yes, it's better than vp3
[16:10:24] <av500> its +5 better
[16:10:25] <Dark_Shikari> Really though it's not that different from vp6
[16:10:29] <janneg> av500: I was downloader nr 5
[16:10:30] <peloverde_> we have a vp3 decoder
[16:10:31] <Dark_Shikari> it's vp6, with more sections of the h264 spec copy-pasted
[16:10:36] <Dark_Shikari> LARGE sections
[16:10:37] <KotH> Dark_Shikari: huh?
[16:10:39] <KotH> that bad?
[16:10:47] <Dark_Shikari> They copied h264 intra prediction verbatim
[16:10:51] <peloverde_> that will be fun for the mpeg-la
[16:10:53] <Dark_Shikari> "oh and it's totally patent free"
[16:10:58] <Dark_Shikari> they copied h264 intra pred
[16:11:10] <Dark_Shikari> the h264 hierarchical tranform (16 4x4 dct + 4x4 hadamard)
[16:11:20] <Dark_Shikari> now they did make minor changes, but imo nothing enough to avoid patents
[16:11:30] <Dark_Shikari> they copied both i16x16, i4x4, _and_ chroma intra pred
[16:12:08] <KotH> wow.. the freetards will like to hear that
[16:12:14] <Dark_Shikari> the arithmetic coder looks almost exactly like cabac without a transition or range_lps_ table, but that's probably enough of a difference.
[16:12:26] <Dark_Shikari> they still forgot to have delta quant.
[16:13:53] <av500> webm, wtf?
[16:14:02] <av500> +  if (str == NULL || (strcmp (str, "matroska") && strcmp (str, "webm")) || version > 2)
[16:14:17] <Dark_Shikari> Yes, they're trying to fragment web multimedia even more
[16:14:24] <av500> \o/
[16:14:30] <janneg> av500: www.webmproject.org/
[16:14:33] <mru> av500: rebranding aka poor man's nih
[16:15:20] <av500> janneg: wtf, the blog is pwd protecrted?
[16:15:34] <Yuvi> ugh, they're copying the whole brand RIFF something else and call it new?
[16:16:07] <mru> Yuvi: it's innovation, 21st-century-style
[16:17:06] <janneg> av500: maybe not yet officially open
[16:17:14] <thresh> so .webm is some sort of a container?
[16:17:17] <av500> Dark_Shikari: the license grant you rights for all "google" patents
[16:17:20] <KotH> who's behind webm?
[16:17:23] <av500> thresh: it is mkv
[16:17:26] <mru> KotH: google
[16:17:28] <thresh> lol
[16:17:38] <spaam> why do they have html code in  libavcodec/libvpxenc.c  file? ;S
[16:17:44] <KotH> rotfl.. i expected better from them
[16:17:49] <av500> thresh: hence the above + line from mplayer mkv demuxer
[16:18:10] <Dark_Shikari> av500: I know
[16:18:37] <av500> "WebM and the codecs it supports (VP8 video and Vorbis audio) require no royalty payments of any kind..."
[16:18:38] <peloverde_> somebody needs to teach them about ordered patches
[16:18:39] <thresh> av500: niiiice.
[16:18:59] <av500> then they link to the license that mentions gg patents only, nice trickery
[16:19:46] <Yuvi> they really don't like #including headers that include code disabled by configure
[16:20:19] <mru> I'm assuming the patches are total rubbish and won't bother looking
[16:20:41] <j-b> ramiro: ping
[16:21:06] <j-b> thresh: patches against vlc are soon to be commited
[16:21:25] <janneg> webm announcement no live in the keynote
[16:21:29] <janneg> +w
[16:22:03] <av500> err, is the libvpx in the code drop?
[16:22:16] * mru closes ears
[16:22:20] <janneg> git://review.webmproject.org/g/libvpx.git
[16:22:23] <Yuvi> "best in class codec for realtime streaming" heh
[16:22:29] <thresh> j-b: vlc + vp8? niice.
[16:22:37] <mru> yes, best in the class defined as exactly this
[16:22:40] <av500> wemb = vp8 + vorbis
[16:22:53] <j-b> thresh: why do you think vlc 1.1 was delayed...
[16:23:02] <av500> j-b: and the actual lib?
[16:23:07] <j-b> av500: it is a mess
[16:23:14] <j-b> av500: impossible to crosscompile
[16:23:19] <av500> of course it is a mess, but where is it?
[16:23:33] <j-b> patches against ffmpeg are a bit weird
[16:23:34] <janneg> av500: git pull git://review.webmproject.org/g/libvpx.git
[16:23:48] <av500> gee, that is what just finished :)
[16:24:03] <thresh> j-b: because you are lazy
[16:24:06] <thresh> :)
[16:24:13] <j-b> thresh: not news :)
[16:24:23] <janneg> av500: or not "fatal: The remote end hung up unexpectedly"
[16:24:30] <av500> janneg: right
[16:25:01] <j-b> http://code.google.com/p/webm/downloads/list
[16:25:35] <spaam> new rev on the patches ;D
[16:25:45] <spaam> 13min ago
[16:25:46] <janneg> code.google.com/p/webm/downloads/detail?name=libvpx-0.9.0.tar.bz2&can=2&q=
[16:25:50] <thresh> they probably listen to us here :o
[16:26:06] <peloverde_> they updated the mplayer tarball chrome://downloads/home/alex/Downloads/mplayer-vp8-encdec-support-r2.tar.bz2
[16:26:16] <j-b> I am just not sure about the "Copyright (c) 2010, Google, Inc. All right reserved"
[16:26:52] <Yuvi> max_cluster_size = 500*1024*1024; <- that seems kinda excessive
[16:27:21] <j-b> and the following license... but well
[16:29:00] <spaam> in r2 they have presets support ;D
[16:29:08] <spaam> ffmpeg-only/ffpresets-libvpx.diff
[16:31:43] <Dark_Shikari> http://news.ycombinator.com/item?id=1361442 upvote me
[16:31:59] <av500> done
[16:32:09] <peloverde_> sorry I don't participate in social news for the stupid
[16:32:17] <ramiro> j-b: ping
[16:32:19] <ramiro> oops, pong
[16:32:49] <av500> just on #beagle: [18:30] <killring> anyone know if/how well the bb can hardware assist vp8 decode?
[16:33:14] <j-b> ramiro: if you had just the time to see how this libvpx can be Xcompiled, that would be cool
[16:33:16] <Yuvi> kinda wish they didn't do cvs style one file patches, there's a reason noone it anymore...
[16:33:43] <peloverde_> at least ordered patches would be a huge win
[16:34:22] <peloverde_> thanks were just given to theora, ick
[16:35:16] <av500> Dark_Shikari: .webm as well?
[16:35:37] <av500> whats the mime type?
[16:35:45] <ramiro> what is libvpx?
[16:36:12] <av500> the vp8 coded
[16:36:36] <ramiro> so google has open sourced it?
[16:36:55] <ramiro> and the solution to all earthly problems has finally arrived?
[16:36:57] <av500> they says so
[16:37:10] <av500> yes, your bus will be less crowded tomorrow
[16:37:40] <av500> lol, the ffmpeg WEBM_DEMUXER does not support "V_QUICKTIME"
[16:37:42] <ramiro> where's the fsf letter taking full credit for this?
[16:38:04] <mru> and the xiph one doing same
[16:38:10] <peloverde_> Google pretty much just gave all the credit to xiph ?!
[16:38:15] <av500> and al gore?
[16:38:35] <mru> peloverde_: WTF?
[16:38:40] <Yuvi> http://pastie.org/967897 <- should I just push this?
[16:38:49] <peloverde_> they called the theora developers visionaries
[16:38:58] <Yuvi> the rest needs a bit of work
[16:39:05] <av500> Yuvi: I am just pushing that for my player :)
[16:39:20] <peloverde_> and before mentioning that reference hardware is in the work they thanked vorbis/theora and only vorbis/theora
[16:39:26] <j-b> ramiro: :)
[16:39:34] <j-b> ramiro: but their configure is a mess
[16:39:53] <av500> j-b: its a decoder, what kind of fancy configure will it need?
[16:40:13] <j-b> av500: I don't know, the possiblity to CrossCompile?
[16:40:23] <j-b> to win32 and win64, I mean
[16:40:25] <Yuvi> add_cflags -DHAVE_STDINT_H
[16:41:03] <mru> peloverde_: visionaries like this one? http://www.apenotmonkey.com/2010/05/10/god-within/
[16:42:30] <mru> Yuvi: I wouldn't bother crediting google with that
[16:42:33] <BBB> spyfeng: hi :)
[16:42:55] <mru> Yuvi: certainly not as they give credit to xiph
[16:43:31] <BBB> oh cool, google posted vp8?
[16:43:35] <BBB> do we decode it? :)
[16:43:54] <spaam> Dark_Shikari: you like to use that SVT file to compare thing ;)
[16:44:54] <av500> mru: TI vp8 announce in 30min from here: http://e2e.ti.com/blogs_/b/mobile_momentum/default.aspx
[16:45:25] * mru refuses to look
[16:45:37] <j-b> you are a geek, you cannot resists
[16:45:39] <j-b> -s
[16:45:54] <peloverde_> It's just irritating how on webmproject.org it's ffmpeg all over the place, but in their keynote they can't shut up about how great xiph is without a single ffmpeg mention
[16:46:42] <av500> j-b: I will just copy it here line by line :)
[16:47:08] <av500> peloverde_: so xiph wrote vp8 by taking vp3 and adding h264, right?
[16:47:31] <j-b> peloverde_: PR vs real world
[16:49:50] <Yuvi> mru: eh, don't feel like changing it
[16:50:07] <Dark_Shikari> av500: vp6
[16:50:35] <j-b> aren't they a bit optimist about the patents?
[16:50:56] <Dark_Shikari> ridiculously so
[16:51:05] <CIA-7> ffmpeg: conrad * r23191 /trunk/libavcodec/avcodec.h:
[16:51:05] <CIA-7> ffmpeg: Add VP8 CODEC_ID
[16:51:05] <CIA-7> ffmpeg: Patch by Google
[16:51:05] <CIA-7> ffmpeg: conrad * r23192 /trunk/libavformat/matroska.c:
[16:51:05] <CIA-7> ffmpeg: matroska: Add V_VP8
[16:51:05] <CIA-7> ffmpeg: Patch by Google
[16:51:06] <CIA-7> ffmpeg: conrad * r23193 /trunk/libavformat/riff.c:
[16:51:06] <CIA-7> ffmpeg: Add VP80 fourcc
[16:51:07] <CIA-7> ffmpeg: Patch by Google
[16:54:04] <av500> so, everybody agrees that the new web is all about glossy magazines?
[16:54:21] <av500> aapl thinks so, gg does too... /sigh
[16:54:39] <mru> is the clusterfuck over yet?
[16:54:51] <peloverde_> I think they are done with codec stuff
[16:55:15] <janneg> no, sports illustrated talking now
[16:55:30] <av500> swimsuit issue?
[16:55:43] <av500> it wont be on the ipad, so goog has the edge :)
[16:55:50] <peloverde_> does SI cover starcraft yet?
[16:55:50] * janneg is not listening
[16:55:51] <mru> sports illustrated is obviously a euphemism for playboy
[16:56:26] <av500> janneg: but why did they get william shatner to present it?
[16:56:35] <av500> or who is that old guy?
[16:56:57] <peloverde_> blol at lebron
[16:57:07] <peloverde_> the man can't deliver under pressure
[16:58:12] <janneg> av500: not watching either
[17:00:34] <av500> +        // Start a new cluster when we get a key frame
[17:01:12] <Yuvi> not strictly required but probably a good idea, esp for streaming
[17:02:01] <Yuvi> I guess the audio packet delay stuff is related to that, but I think strict interleaving is better
[17:04:28] <ramiro> j-b: I'll try later today
[17:05:41] <j-b> ramiro: \o/
[17:07:21] <ramiro> I have a report to turn in in a couple of hours and I haven't started. we've had 1 month to do it...
[17:07:33] <ramiro> procrasti-fucking-nation...
[17:07:56] <av500> just get it from wikipedia
[17:08:37] * mru used to quite enjoy catching students cheating
[17:12:07] <peloverde_> I think it's time to close this keynote, get some caffeine, and get back to dealing with this asf+h.264 mess
[17:13:14] <ramiro> av500: nah, I don't cheat... I frequently fail exams though, but I don't cheat.
[17:14:28] <av500> ramiro: I did not expect it being on wikipedia, what is it about?
[17:17:03] <Tjoppen> interesting analysis of VP8
[17:18:11] <ramiro> av500: lab report about (probably badly translated) regulation and yield of an autotransformer
[17:18:28] <ramiro> the worst part is that I seem to have misplaced the data we collected
[17:18:51] <ramiro> and we had to turn in a copy of the data so the teacher could make sure we didn't make up numbers.
[17:18:58] <ramiro> now he has a copy and I don't =)
[17:22:59] <KotH> ramiro: [FAIL] ? :)
[17:24:07] <ramiro> KotH: =D
[17:24:20] <av500> ok, my player plays .webm files
[17:26:31] <Dashiva> That was quick
[17:26:40] <av500> well, it falls back to audio only :)
[17:26:48] <hyc> cheater
[17:26:57] <mru> av500: my demux?
[17:27:13] <av500> mru: I thought you did not want to hear about it? :)
[17:28:11] <av500> mru: http://mru.pastebin.com/iqsK7TcP
[17:31:09] <mru> thanks, but I doubt I'll be needing it anytime soon
[17:32:15] <av500> hmm, libvpx has arm/neon support
[17:32:27] <j-b> av500: my vlc does the same :)
[17:32:32] <mru> av500: yes, I know
[17:32:43] <mru> not very well-written though
[17:32:56] <mru> but not totally atrocious either
[17:33:05] <av500> mru: I assumed that since you are still in old europe :)
[17:33:16] <av500> and not in the new world
[17:33:33] <mru> what has that got to do with anything?
[17:42:05] <Compn> One of the most unexpected supporters is Adobe, whose CTO Kebin Lynch said that his company is really excited about the new codec. Adobe will use VP8 for Flash and, Lynch said that it will help to dristribute VP8 “to a billion people within a year.”
[17:42:07] <Compn> oh
[17:42:16] <Compn> so its collusion to destroy h264's hold on the market
[17:42:17] <Compn> i see
[17:44:15] <Compn> or to force h264 to make web video free, either way
[17:46:18] <Yuvi> ugh, the libvpx configure script hard-codes OS X versions
[17:46:18] <Yuvi> and
[17:46:25] <Yuvi> doesn't recognize 10.6
[17:46:27] <j-b> :)
[17:46:35] <mchinen> anyone want to explain to me what keyframe flags (for AVIndexEntry) mean for audio?
[17:46:48] <j-b> 18:39 < j-b> ramiro: but their configure is a mess
[17:47:02] <mchinen> as in AVINDEX_KEYFRAME
[17:47:21] <mchinen> *i mean for audio files like mp3
[17:47:34] <Yuvi> or is it that *and* I have to tell it that I'm on OS X
[17:47:52] <av500> mchinen: they are all keyframes?
[17:48:31] <mchinen> av500: okay, that's what I was hoping, thx
[17:53:47] <Yuvi> 'make install' only results in configure rerunning wtf
[17:54:17] <av500> hmm, I just compiled it for armv7/neon, wasnt that hard...
[17:54:30] <Yuvi> did you install it too?
[17:54:41] <Yuvi> cause it compiles with an explicit --target
[17:54:41] <CIA-7> libswscale: lorenm * r31180 /trunk/libswscale/x86/yuv2rgb_template2.c:
[17:54:41] <CIA-7> libswscale: 40% faster yuv420 to rgb24 mmx.
[17:54:41] <CIA-7> libswscale: It is now faster than the old gpl version on conroe.
[17:54:41] <CIA-7> libswscale: lorenm * r31181 /trunk/libswscale/x86/ (yuv2rgb_mmx.c yuv2rgb_template2.c):
[17:54:41] <CIA-7> libswscale: 13% faster yuv420 to rgb15 mmx.
[17:54:41] <CIA-7> libswscale: It is now faster than the old gpl version on conroe.
[17:54:43] <av500> I have no code yet that would use it
[17:54:44] <Yuvi> just doesn't install for me
[17:54:54] <av500> define "install"
[17:55:04] <Yuvi> move stuff to /usr/local/lib and include
[17:55:17] <av500> ah, that is custom here anyway
[17:55:33] <av500> I could add it to buildroot I guess...
[18:02:34] <peloverde_> Where does the extradata get built when playing raw h264? i've looked in both the demuxer and the parser
[18:03:01] <Yuvi> does it? I thought that was only done by the muxer
[18:03:33] <peloverde_> ffplay and ffprobe both report extradata being present (but is_avc being false)
[18:03:49] <peloverde_> the muxer expects some sort of extradata presence
[18:04:44] <peloverde_> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavformat/movenc.c;h=440c98ad26bc70bb6790c857e0725906cbc383f8;hb=HEAD#l1899
[18:06:07] <Yuvi> guess, so, dunno then
[18:10:37] <peloverde_> I guess it's printf time!
[18:13:27] * Yuvi gives up and installs it manually
[18:22:19] <ramiro> oh, alex is back...
[18:23:10] <peloverde_> for anyone who his the logs on google, it comes from avf/utils.c through the parser
[18:27:57] <spaam> peloverde_: printf debugging? D;
[18:30:42] <ramiro> the greatest form of debugging
[18:31:15] <peloverde_> ramiro, for a moment I wondered where I had gone, then I checked my e-mail :)
[18:33:38] <j-b> Where is Diego when I need license reviewing? :D ^^
[18:37:58] <drv> the webm site has some horrible fixed-width layout that doesn't fit in my browser...
[18:38:16] <drv> seems like a web site about web standards would know how to build a decent web site
[18:41:25] <j-b> drv: it is ridiculously broken on resizing with small screens
[18:41:32] <BBB> maybe alex works for google now :-p
[18:48:47] <mru> http://zencoder.com/encoder-blog/2010/05/19/vp8-webm-and-html5-video/
[18:48:53] <mru> any idea who wrote that?
[18:57:04] <peloverde_> does it make sense for h264_split() to return zero when the whole packet is sps/pps?
[18:58:30] <hyc> so is it a stupid question to ask about vp8 in an FLV container?
[18:58:45] <Dark_Shikari> lol
[18:59:09] * janneg is still wondering what an open source codec is? libavcodec/* doesn't seem to qualify
[18:59:24] <kierank> hyc: vp8 over rtmp ;)
[18:59:32] <hyc> ;)
[18:59:48] <hyc> well come on, vp6 and all its earlier relatives are there ;)
[18:59:53] <kierank> also do you plan to reverse engineer that flash p2p thing?
[19:00:07] <hyc> the rtmfp stuff? I hadn't planned to, no
[19:00:31] <kierank> there's no good reason to do so; just adobe trolling
[19:00:35] <hyc> it would probably be too nauseating
[19:01:58] <hyc> I can only stomach working with so much crappy design in one lifetime...
[19:03:12] <peloverde_> at least wikistupedia will be happy they can finally do vorbis in flash...
[19:03:51] <kierank> anything is better than that java player
[19:16:47] <bcoudurier> hi guys
[19:17:50] <astrange> should've woken up earlier, i missed the excitement
[19:19:14] <Dark_Shikari> I've had >10k hits in 2.5 hours
[19:20:20] <elenril> \o/
[19:20:28] <elenril> let the drama begin
[19:22:21] <janneg> av500: blog is now public
[19:24:11] <astrange> did it come with a vp7 decoder?
[19:25:02] <Yuvi> no, but apparently there are enough references that it'll probably be about as easy to RE from vp8 as vp5 was from vp6
[19:35:14] <BBB> maybe someone could ask google nicely
[19:35:19] <BBB> we now have someone posting patches
[19:36:04] <kierank> sshhh BBB, vp7 is their secret codec
[19:36:46] <BBB> hm?
[19:36:48] <mru> the code has comment blocks with /* vp7 version */ etc
[19:37:14] <BBB> that's useful
[19:37:22] <BBB> maybe we should try it with vp7 input
[19:37:26] <mru> probably doesn't cover all the differences
[19:37:34] <BBB> although admittedly our vc1 decoder crashed when feeding it wvp2 input
[19:50:13] <astrange> Yuvi: shouldn't adding CODEC_ID_VP8 be a minor version increase
[19:52:28] <bcoudurier> yup
[20:13:48] <Yuvi> oops, fixed
[20:14:46] <CIA-7> ffmpeg: conrad * r23194 /trunk/libavcodec/avcodec.h: Bump minor version for CODEC_ID_VP8
[20:19:33] <CIA-7> ffmpeg: alexc * r23195 /trunk/libavcodec/aac.c: Make aac_decode_frame() consume zero padding at the end of a packet.
[20:19:34] <CIA-7> ffmpeg: alexc * r23196 /trunk/libavcodec/ (allcodecs.c Makefile chomp_bsf.c): Add a chomp BSF to consume zero padding at the end of a packet.
[20:20:14] <BBB> if xiph is so into this "webm" thing, then how come it doesn't use ogg?
[20:20:56] <iive> they are not.
[20:21:42] <ohsix> BBB: that sort of thing doesn't seem like it would actually be some sort of contention
[20:21:47] <iive> but this vp8 codec needs developers and people who would improve it, and x264 devs are not going to jump on the task. So google needs to "pay" xiph for their services.
[20:22:15] <BBB> right, but wouldn't xiph people scream out loud that ogg is better than matroska?
[20:22:29] <iive> i mean, to encourage them, give them some PR boost and stuff like that.
[20:22:39] <ohsix> why would they?
[20:23:01] <ohsix> seems you might be projecting a little with all the anti- that goes around ;]
[20:23:13] <iive> well, it is not. And they know it. And google knows it. But sometimes you just need somebody to tell that the king is naked.
[20:23:21] <BBB> ohsix: just an innocent bystander
[20:23:34] <BBB> ohsix: anyway, vp8 could be cool, let's see if it makes the one-year hallmark
[20:24:21] <iive> and the webm could be used in both directions. google could extend that format without asking the original mkv developers, while also not shaming xiph PR.
[20:24:39] <ohsix> some things just have merit and they don't always need some rabid character at the wheel, just a rational one
[20:24:40] <BBB> I guess
[20:24:58] <BBB> yuvi: you have a final patch for matroskadec yet? ;)
[20:25:05] <bcoudurier> Yuvi, I sent the ogg muxer patch
[20:25:06] <BBB> I might look into the actual decoder lib and see how complex it is
[20:25:14] <bcoudurier> could you please have a quick look ? that would be great
[20:25:33] <iive> BBB: i guess you've read DS blog?
[20:25:59] <_av500_> i guess xiph is secretly happy that somebody else took the drop ogg decision...
[20:26:15] <_av500_> now they can go mkv and say it was gg that did it...
[20:26:25] <ohsix> you could just ask him instead of speculating
[20:26:46] <_av500_> btw, is theora offially dead as of today?
[20:27:23] <iive> _av500_: more likely there will be theora2 and it would take some years.
[20:28:03] <_av500_> based on vp8?
[20:28:08] <bcoudurier> I don't like MKV :(
[20:28:14] <iive> of course.
[20:28:17] <janneg> don't think so, vp8 has first to prove not to be patent encumbered
[20:28:20] <Dark_Shikari> but but its not mkv
[20:28:21] <Dark_Shikari> it's webm
[20:28:26] <Dark_Shikari> webm webm webm webm webm!
[20:28:29] <bcoudurier> how do they pack audio ?
[20:28:32] <iive> web mkv
[20:28:35] <_av500_> tight
[20:28:36] <bcoudurier> same cluster crap ?
[20:29:00] <j-b> what is the use of bumping LIBAVCODEC_VERSION_MINOR but not resetting MICRO?
[20:29:01] <bcoudurier> btw Yuvi what timebase does the lavf muxer use ?
[20:29:01] * mru decides to troll nvidia with vp8
[20:29:05] <Dark_Shikari> mru: oh god
[20:29:14] <bcoudurier> j-b that's a mistake
[20:29:21] <bcoudurier> it happens frequently :>
[20:29:24] <mru> I've been trolling the tegra forums for a while
[20:29:27] <mru> no reaction
[20:29:28] <j-b> bcoudurier: it is your fault then :D
[20:29:33] <j-b> bcoudurier: bjr, d'ailleurs
[20:30:11] <_av500_> mru:
[20:30:14] <_av500_> #tegra?
[20:30:24] <mru> that exists?
[20:30:34] <_av500_> dunno, im asking you?
[20:30:40] <janneg> no
[20:30:45] <mru> doesn't seem so
[20:30:50] <mru> I meant the web thing
[20:30:55] <janneg> neither does #tegra2
[20:30:55] <_av500_> or the web forums?
[20:31:52] <BBB> iive: ds? schleef?
[20:31:56] <BBB> iive: does he have a blog?
[20:32:00] <_av500_> yes
[20:32:38] <_av500_> he had that half optimized theora for c64x iirc
[20:32:39] <iive> BBB: ds= Dark_Shikari
[20:32:46] <BBB> oh, yeah I read that
[20:33:09] <janneg> mru: maybe they want to add vp8 only to their graphic chips
[20:33:57] <_av500_> mru: they can do vp8 easily on the arm....err wait, no neon :)
[20:34:11] <mru> yes, that's the troll
[20:34:45] <BBB> is anyone looking at that codec lib already?
[20:34:53] <_av500_> i looked a bit
[20:35:00] <_av500_> it compiled
[20:35:47] <janneg> their git repo is still not cloneable
[20:35:55] <BBB> christ that code is a mess
[20:36:05] <BBB> millions of header files already
[20:36:07] <_av500_> janneg: worked for me
[20:36:08] <BBB> who would do that :(
[20:36:16] <mru> idiots would
[20:36:19] <mru> idiots abound
[20:36:36] <_av500_> janneg: i compile the git stuff
[20:36:41] <_av500_> +d
[20:36:41] <janneg> _av500_: git://review.webmproject.org/libvpx.git ?
[20:36:43] <BBB> but I'm not an idiot, I think
[20:36:45] <BBB> maybe I am
[20:36:52] <BBB> everyone else is crazy except me, I'm an airplane
[20:36:53] <mru> BBB: no, not you
[20:36:57] <_av500_> janneg: dunno, was at work
[20:37:12] <_av500_> but sounds like the one
[20:37:53] <_av500_> janneg: works here too
[20:38:01] <mru> I don't think anyone from nvidia follows those forums
[20:38:13] <ohsix> forums are for parking people
[20:38:15] <mru> they didn't even reply when I suggested using omap4 instead
[20:38:32] <mru> there are some old replies from nvidia people
[20:39:00] <thresh> it even compiled cleanly on osx
[20:39:07] <astrange> oh, a resizing library
[20:39:08] <mru> but yes, forums are the internet equivalent of being placed on hold with phone support
[20:39:30] <ohsix> more like getting thrown in the drunk tank while you sober up ;]
[20:39:38] <astrange> a very strange one
[20:40:00] <_av500_> mru: more like writing to a message wall in a deserted shopping mall
[20:40:31] <mru> only the spiders will read it
[20:41:19] <_av500_> mru: gg heard you, they provide decode_to_md5 in their example code :)
[20:42:10] <janneg> sloccount counts "php:          35742 (29.70%)" wtf?
[20:42:18] <Yuvi> BBB: in a sec, I'm actually compiling it now
[20:42:20] <Yuvi> bcoudurier: sure
[20:42:29] <Yuvi> bcoudurier: 1/1000
[20:43:06] <bcoudurier> shit
[20:43:11] <bcoudurier> can't we use a more decent one ? :>
[20:43:34] <Yuvi> the problem is that the numerator is fixed at 1e9
[20:43:39] <Yuvi> err denominator
[20:43:46] <Yuvi> you can write whatever for the numerator
[20:45:03] <janneg> syntax highlighting for the documentation
[20:45:15] <_av500_> what?
[20:45:28] <bcoudurier>         // ms precision is the de-facto standard timescale for mkv files
[20:45:28] <bcoudurier>         av_set_pts_info(st, 64, 1, 1000);
[20:45:29] <bcoudurier> rofl
[20:45:57] <Yuvi> x264 does some math to decide a better one I think?
[20:46:14] <bcoudurier> best one for audio is 1/sample rate
[20:46:28] <BBB> bcoudurier: I'm quite sure the mkv demuxer doesn't do that?
[20:46:31] <BBB> their webm one does?
[20:46:35] <BBB> that's crazy
[20:46:39] <Yuvi> BBB: muxer
[20:46:50] <BBB> doesn't the user set the timescale for muxer?
[20:46:53] <Yuvi> bcoudurier: too bad you can't represent those exactly with x/1e9
[20:46:55] * BBB confused
[20:46:57] <janneg> _av500_: examples/includes/geshi/ 29kloc php
[20:47:03] <bcoudurier> Yuvi, yes, that's why mkv sucks
[20:47:53] <Yuvi> BBB: the issue is that mkv uses a weird way of specifying its one timebase for the file and most common timebases aren't exactly representably
[20:47:56] <Yuvi> representable
[20:48:17] <Yuvi> so I just chose 1/1000 always since that's what everyone else uses
[20:49:21] <CIA-7> ffmpeg: bcoudurier * r23197 /trunk/libavcodec/libx264.c: fix x264 encoding when delay is > number of input frames
[20:49:30] <bcoudurier> but that is really bad for 23.98
[20:49:37] <bcoudurier> and bad for audio as well
[20:49:54] <bcoudurier> 1000000 should be better at least
[20:50:37] <mru> people with the attention span of a US commercial interval simply don't understand problems like clock drift
[20:52:21] <Yuvi> bcoudurier: yeah, I want to think about the cluster+block implications in a bit, afk for a few
[20:52:53] <bcoudurier> Yuvi, can you please look at the ogg muxer patch as well ?
[20:53:01] <bcoudurier> that would be nice to fix this once and for all :>
[21:06:43] <mru> and here's the statement where the fsf takes credit for everything
[21:06:47] <mru> http://www.fsf.org/news/free-software-foundation-statement-on-webm-and-vp8
[21:07:38] <Dark_Shikari> mru: lolo
[21:08:41] <_av500_> ...users can show support for this new technology by joining our PlayOgg mailing list...
[21:08:49] <_av500_> playogg? err?
[21:09:07] <bcoudurier> how does chrome support vp8 ?
[21:13:11] <Yuvi> probably with the patches they're sending us
[21:13:57] <saintd3v> so has anyone checked if mkv in a video tag actually works in current chrome releases, or not?
[21:14:27] <janneg> bcoudurier: chrome with vp8 support will be released next week
[21:14:39] <_av500_> saintd3v: it works in todays opera :)
[21:14:45] <saintd3v> erm sorry 'WebM' :/
[21:15:20] <saintd3v> _av500_: know of any sites that have an example of a video tag with matroska?
[21:17:39] <Yuvi> whoops, I sent the exact same patch and claimed it was fixed
[21:17:55] <mru> was the "new" one approved?
[21:18:14] <_av500_> saintd3v: labs.opera.com has some
[21:18:35] <_av500_> i downloaded some .wemb from there
[21:45:47] <mchinen> are there any known cases where the timebase might be less than the sample rate for audio files?
[21:51:27] <bcoudurier> depends on the file format
[21:51:32] <mchinen> i guess this happens when we have audio/video and fixed video framerate too..
[21:53:44] <mchinen> so how would you feel to also have a seek by sample seek function for accurate audio seeking?
[21:55:00] <mchinen> or a different, probably better option is to return info about the start sample of the decoded audio
[21:55:15] <mchinen> i don't think that's in there now, is it?
[21:58:44] <bcoudurier> well you have to seek at a frame
[22:00:05] <mchinen> yes, for this reason i think its better to have the client be able to see what the start sample is
[22:00:21] <mchinen> *of the decoded frame
[22:03:18] <bcoudurier> it's a matter of timestmaps conversion
[22:05:47] <mchinen> but if the samplerate is greater than the timebase, you won't be able to specify exact samples since it is an int
[22:07:17] <bcoudurier> I see, well I guess that driven by the users
[22:07:22] <bcoudurier> do they want that ?
[22:07:43] <mchinen> at least for audio editors this is useful
[22:07:52] <mchinen> for playback i don't think anyone cares
[22:09:03] <mchinen> i also saw a few mails on the user list asking about this
[22:16:52] <Yuvi> Dark_Shikari: btw, lavf's mkv muxer supports streaming
[22:16:58] <Dark_Shikari> it does?
[22:17:05] <Yuvi> yes, I fixed that a while back
[22:17:07] <Dark_Shikari> oh nice
[22:30:16] <mru> hmm... is the vp8 source code licence gpl compatible?
[22:31:13] <BBB> poor diego
[22:31:36] <BBB> mru: given that collabora worked together with them, it surely is
[22:31:39] <BBB> gstreamer is lgpl after all
[22:31:44] <Dark_Shikari> it's bsd
[22:31:49] <Dark_Shikari> oh wait
[22:31:51] <Dark_Shikari> you mean the patent license
[22:31:53] <mru> yeah
[22:31:57] <Dark_Shikari> actually... probably not
[22:32:04] <mru> the bit about losing the licence if you sue
[22:32:20] <mru> that doesn't look very gpl-compatible
[22:32:27] <Dark_Shikari> let's put it under --enable-nonfree then
[22:33:09] <peloverde_> blol
[22:33:12] <j-b> BBB: poor diego? why ?
[22:33:30] <Kovensky> <@mru> hmm... is the vp8 source code licence gpl compatible? <-- BSD
[22:33:46] <Kovensky> oh, that thing
[22:33:51] <mru> I thought it was bsd + patent stuff
[22:33:53] <kierank> didn't they say they could license it as lgpl
[22:34:13] <drv> i thought they meant lgpl the lib wrapper part for ffmpeg
[22:34:17] <drv> not the actual library
[22:34:21] <Kovensky> how did they stuff VP8 in matroska anyway, use the V_VFW_FOURCC tag? D:
[22:34:26] <kierank> oh i see
[22:34:55] <mru> V_VP8 apparently
[22:35:09] <Kovensky> ._.
[22:35:26] <Kovensky> I thought they'd do something like V_ON2_GOOGLE_VP8 because why not
[22:35:40] <Kovensky> free advertising!
[22:35:52] * Kovensky wonders how big of a flop will webm be
[22:36:12] * Kovensky still lols @ no b-frames, no aq and code-as-spec
[22:36:31] <BBB> j-b: he's flaming google on the ml
[22:36:50] <j-b> BBB: he is right
[22:36:54] <Kovensky> o, fflames, where
[22:37:08] <j-b> BBB: Google or not, the library is a mess
[22:37:15] <BBB> I'm going through it
[22:37:40] <peloverde_> diego has a point, they have a 0-day list of 30+ commercial partners, there's no reason why they couldn't have gotten these patches pre-approved weeks ago
[22:37:47] <Yuvi> I like how there's an install target, but it doesn't do anything
[22:38:11] <_skal_> Kovensky: there's AQ
[22:38:14] <_skal_> oops
[22:38:17] <_skal_> wrong win
[22:38:19] <BBB> I only need vpx_codec/ right?
[22:38:24] <j-b> no
[22:38:26] <BBB> the rest seems crap and old stuff for vp8
[22:38:36] <BBB> what does the ffpatch use?
[22:38:53] <Yuvi> http://pastie.org/968513 <- I think almost all of these are needed
[22:39:03] <Yuvi> vp8e.h maybe not
[22:39:08] <BBB> oh you need vp8x.h also
[22:39:10] <BBB> blegh
[22:39:13] <j-b> you need vpx_codec and vp8
[22:39:15] <BBB> that's a big sourcetree
[22:39:20] <BBB> darnit
[22:39:25] <BBB> what is vpx_codec/ and what is vp8?
[22:39:26] <j-b> cp vp8/*.h and vpx_codec/*.h
[22:39:35] <BBB> I want to look what the decoder does
[22:39:39] <BBB> maybe rewrite it ;)
[22:39:57] <Yuvi> rewriting it is a given ;)
[22:41:54] <BBB> well this is better than re'ing a binary without comments
[22:41:58] <BBB> at least you can see waht it does
[22:45:53] <CIA-7> ffmpeg: michael * r23198 /trunk/libavutil/ (log.c log.h): av_default_item_name() so Simply AVClasses need 1 function less.
[22:47:35] <BBB> I think the patent license is pretty standard
[22:48:31] <mru> yes, but is it gpl-compatible?
[22:48:44] <BBB> I'm asking our experts ;)
[22:48:45] <mru> being incompatible with the gpl is also pretty standard
[22:51:34] <CIA-7> ffmpeg: michael * r23199 /trunk/libavutil/ (log.h avutil.h):
[22:51:34] <CIA-7> ffmpeg: Make it possible for a log context to keep track of its parent context.
[22:51:34] <CIA-7> ffmpeg: This is usefull to keep track and display relations where things are a
[22:51:34] <CIA-7> ffmpeg: bit more complex (like AVProtocols or demuxers used by demuxers and such)
[22:52:30] <CIA-7> ffmpeg: michael * r23200 /trunk/libavutil/log.c: Print parent log context too, if available.
[22:56:22] <CIA-7> ffmpeg: michael * r23201 /trunk/libavcodec/ (opt.c eval.c eval.h ratecontrol.c):
[22:56:22] <CIA-7> ffmpeg: Change eval API to take parent log context and log level offset.
[22:56:22] <CIA-7> ffmpeg: this is based on stefanos work, especially all bugs are his fault ;)
[22:59:38] <BBB> uhm... so the whole of vpx_codec/* appears to be a very complex, big huge wrapper around something that has so many layers that I lost track already?
[22:59:43] <BBB> what a waste
[22:59:50] <BBB> I suppose vp8/ is the implementation then?
[22:59:54] <j-b> BBB: probably for VP3, VP6 and VP7
[23:00:01] <j-b> and they aren't in the release spec
[23:00:10] <j-b> so, only vp8/ should be interesting
[23:00:20] <BBB> darnit, vpx_codec/ was smaller so I started there
[23:00:24] <ohsix> BBB: are you using gnu global or lxr/mxr to look around or something? they can be really handy (global is really fast at generating indexes and html too)
[23:00:26] <BBB> ok, vp8/ then
[23:00:35] <Yuvi> yeah, sounds similar to the vp3 dump
[23:00:40] <Yuvi> except more organized
[23:00:42] <BBB> gnulxrmxr?
[23:00:43] <BBB> wtf?
[23:00:47] <BBB> no I use xcode
[23:00:59] <BBB> it's kinda crappy but it can search
[23:01:10] <ohsix> http://www.gnu.org/software/global/
[23:01:13] <BBB> I'll look at mxrlxr later :)
[23:01:48] <ohsix> well, heh; lxr is the thing, mxr is mozillas modification of the original, but they're just source browsers; global is probably easier for a one-off
[23:01:53] <astrange> i use textmate, it's probably a little better than xcode but neither have indexing
[23:02:28] <ohsix> its _really nice_ to fly around stuff; even if its html in a browser and it has to be generated :]
[23:02:50] <BBB> xcode will do for now, I'm just looking :)
[23:03:38] <Dark_Shikari> http://daringfireball.net/linked/2010/05/19/vp8-funny
[23:03:39] <Dark_Shikari> LOL
[23:06:50] <mru> he'd be funnier if he weren't such a hypocrit and fanboy
[23:07:18] <Dark_Shikari> who, christopher blizzard or daringfireball?
[23:07:22] <mru> gruber
[23:07:23] <Dark_Shikari> the former is funny _because_ he's a hypocrit :)
[23:07:57] <BBB> blizzard?
[23:08:10] <BBB> you ever believed a word of that bastard who says "ffmpeg is illegal"?
[23:08:36] <BBB> he actually tried to convince the mozilla foundation that they shouldn't use ffmpeg because our sources are illegal and might lead to patent infringement in otherwise patent-free codecs
[23:08:48] <BBB> as if the implementation would suddenly make theora violate patents
[23:09:04] <mru> it could
[23:09:09] <mru> ever heard of "essential patents"
[23:09:14] <mru> vs non-essential ones
[23:09:30] <BBB> two feature-par decoders will violate the same patent
[23:09:36] <BBB> *patents
[23:09:45] <mru> not necessarily
[23:09:50] <BBB> ?
[23:09:53] <mru> one might use some patented trick to run faster
[23:10:00] <mru> or whatever
[23:10:04] <janneg> or slower
[23:10:21] <peloverde> or upsidedown!
[23:10:23] <Yuvi> like (a-b)^a or whatever you do to put the sign back branchless
[23:10:31] <mru> yeah, such things
[23:10:46] <BBB> aaron says the patent-clause is potentially not gplv2-compatible, but might be gplv3-compatible and will get back to me tomorrow
[23:10:57] <BBB> anyone wanna wack them on the ml? :)
[23:11:01] <Dark_Shikari> who's aaron, sflc?
[23:11:04] <BBB> sflc
[23:11:28] <BBB> gplv3 contains a similar clause although it has a grace period, unlike google's patent recovation clause
[23:11:54] <BBB> gplv2 does not allow revocation like that, but it's not 100% sure if that extends to patents or just software itself
[23:11:58] <BBB> so he'll look into it ;)
[23:12:06] <mru> unless it's a strict subset of the gpl, it's not compatible
[23:12:27] <BBB> ok, so go whack the patch :)
[23:12:55] <mru> there's also specific talk about patents in the gpl, remember
[23:13:03] <mru> and this time that clause is relevant
[23:13:07] <BBB> right
[23:13:17] <mru> because google owns both the patent and the copyright
[23:13:18] <BBB> because google owns them
[23:13:23] <BBB> good point
[23:13:36] <mru> so is that patent licence compatible with what the gpl requires?
[23:13:43] <mru> I somehow doubt that
[23:14:27] <BBB> so probably no, I guess
[23:14:43] <BBB> I'm gonna go home btw, but feel free to send this as a response to the ml :)
[23:17:35] <astrange> raising
[23:20:57] <drv> i like how one of the posters on DS's blog post says webm will be like PNG "in that that either you support it or you don't"
[23:21:06] <drv> i hope he doesn't mean like PNG - some features missing in IE for a long time ;)
[23:21:48] <Kovensky> so how's the diego vs google fflame going
[23:21:57] <bcoudurier> rofl
[23:22:32] <mru> I see some fantastic trolling opportunities for linuxtag
[23:23:11] <Kovensky> IE already played the H.264 card
[23:23:16] <Kovensky> I doubt they'll jump the WebM bandwagon
[23:23:32] <Kovensky> same for Safari
[23:23:49] <mru> http://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx
[23:24:06] <Dark_Shikari> they're supporting whatever system codecs you have installed support
[23:24:13] <Dark_Shikari> in practice this means whatever microsoft wants
[23:24:30] <astrange> safari supports system codecs too
[23:24:50] <astrange> i'm willing to support libvpx in perian when all their patches get merged
[23:25:05] <bcoudurier> mru, is uint8_t one byte or can be more than one ?
[23:25:11] <astrange> one byte
[23:25:32] <Kovensky> mru: hmm
[23:25:35] <mru> on a system with 8-bit bytes
[23:25:42] <Kovensky> so they're doing exactly what mozilla says is evil :D
[23:25:42] <bcoudurier> wtf is yadif having sizeof(uint8_t) code
[23:25:51] <mru> posix requries 8-bit bytes
[23:25:55] <mru> C does not
[23:25:59] <Kovensky> bcoudurier: too much copypasta?
[23:26:14] <Kovensky> mru: well, C does require "sizeof(uint8_t)" to be 1
[23:26:20] <mru> no
[23:26:22] <Kovensky> it is 8 bits wide after all
[23:26:25] <astrange> malloc(x * sizeof(uint8_t)) makes sense
[23:26:26] <mru> C requires sizeof(char) == 1
[23:26:27] <Kovensky> o_O
[23:26:36] * Kovensky loses trust in stdint.h
[23:26:46] <astrange> if it's next to another kind of malloc, or if you want to extend support to 16 bit pixels
[23:26:50] <mru> there is no requirement that int8_t == char
[23:26:56] <bcoudurier> well
[23:27:05] <bcoudurier> you just supported sizeof(char)
[23:27:47] <Kovensky> <@mru> there is no requirement that int8_t == char <-- but isn't there a requirement that int8_t be 8 bits wide? same for int16_t being 16 bits wide, int32_t, etc
[23:27:49] <mru> non-8-bit char systems are rare and painful though
[23:27:53] <bcoudurier> for malloc I'm always for p = malloc(sizeof(*p))
[23:28:02] <mru> +1
[23:28:15] <Dark_Shikari> +1