[FFmpeg-devel-irc] IRC log for 2010-03-22

[irc at mansr.com]

[00:29:20] <mru> http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.RequestSpecificProcessorFactoryFactory.html
[00:35:48] <peloverde> I always hated those Java APIs, multilevel factories belong in the special olympics
[06:54:55] <thresh> moroning, fellow ffmpeg developers.
[06:55:04] <thresh> kshishkov: does it remind you of anything? http://cheezpictureisunrelated.files.wordpress.com/2010/03/129135911163621543.jpg
[06:55:06] <kshishkov> morning, road worker
[06:55:49] <kshishkov> yes, it's from series "guess country by picture"
[06:56:00] <thresh> exactly
[06:58:45] * av500 wonders what mathematical functions describes the full length of the chair back
[06:59:23] <kshishkov> in Russia chair is used to describe math functions
[06:59:35] <av500> kshishkov: come on, it cannot be too bad, he has chalk at least
[06:59:46] <av500> y=chair(x)
[07:00:21] <av500> and there are lights on in the room
[07:01:15] <kshishkov> av500: yes, but I remember that sometimes students had to get chalk somewhere
[07:02:18] <kshishkov> sometimes stealing or borrowing it from the next room
[07:02:47] <av500> borrow? you bring back a fine white powder?
[07:02:48] <kshishkov> and light was not permanent either (this being .ua, not .ru)
[07:03:19] <kshishkov> no, "borrow" in local sense - you ask if you can borrow it and never return anything
[07:04:15] <av500> ah
[07:37:53] <KotH> o_0
[07:38:01] <KotH> kshishkov: 5th world country?
[07:38:16] <kshishkov> 3rd world!
[07:43:35] <KotH> can't be. uk is already a 3rd world country and they dont have such probs ;)
[07:44:13] <kshishkov> what about sixties there?
[07:48:35] <KotH> dunnno.. i'm not that old
[07:49:41] <kshishkov> I'm not good with history but I heard they had quite similar conditions around there
[07:49:54] <kshishkov> (including borrowing from IMF)
[07:51:18] <KotH> well.. .ch had famines, just 100y ago...
[07:51:40] <KotH> but thanks to the germans, we're now one of the richest countries in the world :)
[07:52:46] <kshishkov> I heard it was true for Sweden 150 years ago too\
[08:23:30] <nfl> jai: ?
[08:25:45] <wbs> Yuvi: you're familiar with xiph stuff, right? care to take a look at the av_xiphlacing doxy patch on the ML?
[08:28:29] <siretart`> morning
[11:49:25] <pross-au> OT: okay it only took 55 minutes for open office to open my 5MB Word 2003 spreadsheet file
[11:50:18] <twnqx> Oo
[11:51:48] <merbzt> open source roxx
[11:52:31] <kshishkov> strewth! It's Java-based a bit so your <4GB RAM boxes are no good
[11:52:57] * kshishkov tries to avoid running OOo on MacMini with 512MB at all
[11:53:02] <pross-au> actuallys thats true kshishkov . the xml processing (this was an XML word 2003 file) is done in java
[11:54:28] * kshishkov remembers trying to import small 50-page table into oowrite
[11:59:21] <Compn> is that why google docs will not import any .docx over 900kb ?
[11:59:37] * Compn has 5mb .docx and nothing to read it
[12:00:16] <kshishkov> IIRC there was docs to odf converter at SF
[12:00:31] <kshishkov> 20mb in size or something
[12:00:37] <kshishkov> written by the very M$ too
[12:00:52] <thresh> speaking of which, 32630 admin     16   0 13.7G  13G 6252 S  0.0 93.9   3:45.73 php
[12:01:03] <thresh> nice, aint it?
[12:02:48] <kshishkov> ain't nice indeed
[12:03:06] <kshishkov> was that "PHP with all crap" installation?
[12:08:23] <pross-au> kshishkov: it just attempted to autosave
[12:08:29] <pross-au> that god for xkill
[12:09:02] <kshishkov> kill -9 is usually good too
[12:09:05] <thresh> kshishkov: rather 'developer with crap instead of brains'
[12:10:09] <kshishkov> thresh, I don't suspect you of doing Java programming otherwise it would be pretty normal memory consumption for you.
[12:10:23] <thresh> it isnt nice at all
[12:10:39] <thresh> and not really normal, though that machine has 32G ram
[12:10:43] <kshishkov> nothing that sudo kill -9 can't  fix
[12:11:01] <kshishkov> Parkinson's Law in action
[12:11:01] <thresh> nah, that VPS was specially crafter for that project
[12:11:09] <thresh> crafted
[12:11:48] <thresh> managers think it's cheaper to buy a new server for EUR 20k each year than to rewrite it
[12:12:14] <twnqx> 20k in developer salaries + side costs... would that be enough for a rewrite?
[12:12:25] <kshishkov> yes, someone needs to create an environment for memory hogs
[12:12:49] <twnqx> that's like one senior guy, 4 month
[12:13:34] <thresh> that would be more than enough
[12:13:46] <kshishkov> since this is not Moscow nor Russia nor Kiev,  20K EUR would be enough for 2 devs annual salary. Or 20 PHP monkeys
[12:13:57] <pross-au> 20 PHP monkeys!!
[12:14:17] <thresh> kshishkov: it is Moscow
[12:14:41] <thresh> we're like ~10km away from it, so the salaries are +- Moscow ones
[12:15:02] <kshishkov> ah, then about half a year of salary at most
[12:15:19] <thresh> yep
[13:03:27] <bubu74> hi all
[13:03:35] <bubu74> there is someone
[13:03:37] <av500> no
[13:04:21] <bubu74> thnks
[13:05:55] <jai> lol
[13:07:15] <av500> or was I too unfffriendly?
[13:07:46] <kshishkov> you've not kicked him at least
[13:07:58] <thresh> so that was ultra friendly
[13:31:02] <BBB> kshishkov: are you currently actively working on that wvp2 dll?
[13:34:22] <wbs> BBB: ping on http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-March/085070.html :-)
[13:34:39] <BBB> ugh, I'm behind on reviewing patches again? :)
[13:35:10] <wbs> that depends on your definition of 'soon' :-)
[13:40:55] <BBB> I forgot :)
[13:43:44] * BBB should review all other patches also
[13:43:45] <BBB> ...
[13:54:34] <lu_zero> mru: ping
[13:55:18] <mru> pong
[13:55:38] <lu_zero> I read more stuff about the ogg-apologists
[13:55:52] <lu_zero> "ogg made for streaming" seems the new excuse
[13:56:11] <mru> but it fails at that too
[13:56:11] <av500> it is perfect
[13:56:21] <lu_zero> what I wonder is
[13:56:28] <av500> that makes the whole "use ogg for yuotube" fail
[13:56:32] <lu_zero> what the they would mean for "streaming"
[13:56:37] <av500> since yuotube is not about "streaming"
[13:56:42] <lu_zero> youtube uses already rtp for streaming
[13:56:49] <lu_zero> thus they fail horribly
[13:57:17] * lu_zero should make ffmpeg work with that btw...
[13:57:21] <lu_zero> but
[13:57:51] <wbs> lu_zero: what would be required to support that?
[13:58:17] <lu_zero> wbs amr and h263-2000 format support apparently
[13:58:45] <wbs> lu_zero: I added support for those formats not too long ago :-)
[13:58:52] <lu_zero> uhm
[13:59:01] <lu_zero> then why it isn't working here?
[13:59:31] <wbs> no idea, haven't tested it against youtube, but normal 3gp files served over rtsp work fine at least
[13:59:54] <lu_zero> btw I'm about to make ffmpeg reject message with bogus or missing cseq
[13:59:56] <av500> lu_zero: I was refering to useing ogg for html5 video
[14:00:29] <lu_zero> do you have opinions about that?
[14:00:54] <lu_zero> av500: that isn't streaming at least IMHO
[14:00:55] <lu_zero> ^^
[14:01:00] <j0sh> lu_zero, can you look over my xiphlacing doxy patch?
[14:01:13] <av500> exactly, so if ogg is for streaming, it is NOT for html5 video, no?
[14:01:21] <lu_zero> j0sh: tell me where to look
[14:01:25] <lu_zero> ogg isn't for streaming
[14:01:32] <j0sh> lu_zero, in the theora depayloader ML thread
[14:01:38] <av500> [14:55] <lu_zero> "ogg made for streaming" seems the new excuse
[14:02:00] <lu_zero> j0sh: the exact subject?
[14:02:01] <wbs> lu_zero: being more strict with cseq sounds ok to me
[14:02:33] <lu_zero> wbs: do you have a list of public testcase server btw?
[14:02:38] <j0sh> lu_zero, http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-March/085441.html
[14:02:45] <wbs> lu_zero: nope
[14:03:14] <j0sh> wbs, thanks for all the reviews, i never would've caught half those issues
[14:03:24] <lu_zero> check ffmpeg -i rtsp://rtsp2.youtube.com/CjcLENy73wIaLgkCo6RfCuxKFhMYDSANFEIQdGVzdC1kb21pbml0eS0wMUgGUglwbGF5bGlzdHMM/0/0/0/video.3gp
[14:04:13] <lu_zero> j0sh: please give me a link
[14:05:39] <j0sh> lu_zero, http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100322/144175df/attachment-0001.bin
[14:05:59] <lu_zero> thank you
[14:06:46] <lu_zero> j0sh: seems ok
[14:06:58] <wbs> lu_zero: hmm, seems to fail in following the redirect, looking into it...
[14:07:02] <lu_zero> still I'm sorry I couldn't even find the thread =_=
[14:07:11] <lu_zero> it seems to follow the redirect
[14:07:31] <lu_zero> now I'm noticing that here seems to fail because it just uses udp
[14:08:01] <lu_zero> (and here I'm beside a stupid adsl modem+router)
[14:12:49] <av500> mru: I guess you saw that: http://www.osnews.com/story/23018/Ogg_Objections_Problems_with_the_Container_Format
[14:12:55] <wbs> lu_zero: I've messed up redirects in some refactoring recently, that's easy to fix... but then the amr depacketizer doesn't like the fmtp being "a=fmtp:99 octet-align", since it would want octet-align=1
[14:13:06] <mru> av500: yes, saw that
[14:14:15] <wbs> lu_zero: ... but except for that, it seems to work
[14:14:53] <lu_zero> wbs: I see
[14:15:37] <wbs> lu_zero: generally, are such fmtp lines correct at all? the rfc only mentions explicitly octet-align=0/1
[14:20:27] <justlooking> i take it its not supposed to do this rtsp://rtsp2.youtube.com/CjcLENy73wIaLgkCo6RfCuxKFhMYDSANFEIQdGVzdC1kb21pbml0eS0wMUgGUglwbGF5bGlzdHMM/0/0/0/video.3gp: Error while parsing header
[14:23:27] <justlooking> that error is with the curent http://ffmpeg.arrozcru.org/autobuilds/ and your supplyed line above lu_zero
[14:25:04] <lu_zero> wbs: you were saying?
[14:25:06] <lu_zero> ^^
[14:27:09] <CIA-24> ffmpeg: michael * r22629 /trunk/libavcodec/ffv1.c: Remove the word "experimental"
[14:27:14] <lu_zero> about octet-align seems a quirk indeed
[14:29:38] <wbs> lu_zero: posted both patches required for successful playing of the url to the ML
[14:33:04] <lu_zero> commented before it get swamped in the mailbox
[14:33:12] <BBB> wbs: patch ok from me too
[14:33:18] <BBB> (fw)
[14:33:22] <BBB> does youtube work then?
[14:36:07] <wbs> BBB: yes, with those both patches, the link above does work for me
[14:36:32] <BBB> apply apply apply
[14:36:35] <BBB> uhm
[14:36:57] <lu_zero> BBB: question for you
[14:37:01] <BBB> ok
[14:37:02] <lu_zero> I'm going to check cseq
[14:37:06] <BBB> ok
[14:37:08] <lu_zero> should I warn or should I reject
[14:37:09] <lu_zero> ?
[14:37:15] <BBB> please add reordering first
[14:37:25] <BBB> if possible
[14:37:27] <lu_zero> reordering on rtsp?
[14:37:32] <lu_zero> or rtp?
[14:37:42] <BBB> cseq is pkt sequence number, no?
[14:37:50] <BBB> that's rtp, yes
[14:37:57] <lu_zero> cseq as the sequence number in rtsp ^^
[14:38:09] <BBB> rtsp has a sequence number? :)
[14:38:11] <lu_zero> our current parser is quite lax
[14:38:12] <lu_zero> yes
[14:38:39] <BBB> do we currently parse it?
[14:38:42] <lu_zero> yes
[14:38:52] <BBB> grep cseq rtsp.c gives me nothing
[14:38:59] <lu_zero> uh?
[14:39:23] <lu_zero> rt->seq
[14:39:24] <lu_zero>     } else if (av_stristart(p, "CSeq:", &p)) {
[14:39:24] <lu_zero>     snprintf(buf1, sizeof(buf1), "CSeq: %d\r\n", rt->seq);
[14:39:31] <BBB> grep -i
[14:39:33] <BBB> aha
[14:39:37] <lu_zero> that one
[14:40:11] <BBB> does it fix a bug?
[14:40:56] <BBB> I think warning is better, and then update the cseq accordingly anyway
[14:41:17] <BBB> that way we can test how good/bad it is before making it reject
[14:41:20] <lu_zero> BBB: so if cseq is missing or not updated overwrite it and warn
[14:41:29] <BBB> yes
[14:41:35] <BBB> say we go from 1120 to 1122
[14:41:37] <BBB> update it anyway
[14:41:38] <BBB> and warn
[14:41:46] <BBB> because likely we'll go to 1123, 1124 afterwards
[14:42:25] <BBB> I want to see if it triggers before I say "reject it"
[14:42:29] <BBB> I agree reject would be nice
[14:42:36] <BBB> once we've tested it with warn for a short while
[14:42:45] <BBB> to make sure it doesn't do crazy stuff with some servers
[14:42:47] <BBB> you never know
[14:43:42] <CIA-24> ffmpeg: mstorsjo * r22630 /trunk/libavformat/rtsp.c:
[14:43:42] <CIA-24> ffmpeg: Use the caller's RTSPMessageHeader in rtsp_setup_input_streams
[14:43:42] <CIA-24> ffmpeg: Currently, the caller doesn't get the status_code and location for rediects,
[14:43:42] <CIA-24> ffmpeg: since rtsp_setup_input_streams uses a copy of RTSPMessageHeader of its own.
[14:45:19] <CIA-24> ffmpeg: mstorsjo * r22631 /trunk/libavformat/rtpdec_amr.c: Interpret valueless attributes in AMR ftmp lines as being 1
[14:48:08] <lu_zero> BBB: let me see if it works
[14:58:42] <CIA-24> ffmpeg: mstorsjo * r22632 /trunk/libavcodec/avcodec.h:
[14:58:42] <CIA-24> ffmpeg: Add doxygen docs for av_xiphlacing
[14:58:42] <CIA-24> ffmpeg: Patch by Josh Allmann (joshua allmann gmail com)
[14:58:56] <wbs> j0sh: congrats on getting your first(?) patch applied. :-)
[15:00:20] <j0sh> haha it was my first patch, thanks!
[15:05:03] <CIA-24> ffmpeg: michael * r22633 /trunk/libavcodec/ffv1.c:
[15:05:03] <CIA-24> ffmpeg: Throw out last experimental warning that was printed for colorspaces with more than
[15:05:03] <CIA-24> ffmpeg: 8 bits per component. This does no good except scaring users away.
[15:07:58] <CIA-24> ffmpeg: mstorsjo * r22634 /trunk/libavformat/ (rtsp.c rtspenc.c): Add support for TCP as lower transport in the RTSP muxer
[15:07:59] <CIA-24> ffmpeg: mstorsjo * r22635 /trunk/libavformat/rtsp.c: Reindent
[15:10:19] <lu_zero> BBB: as we parse the lines we don't have a way to know when the cseq is missing w/out doing something quite ugly
[15:11:29] <lu_zero> (e.g set the rt->seq to -1 and see if it got changed later)
[15:14:20] <BBB> that's not so ugly
[15:14:29] <BBB> in fact, I'd consider it the right thing
[15:14:39] <BBB> why don't we fill out reply->seq instead of rt->seq?
[15:14:53] <BBB> oh, we do
[15:14:59] <BBB> so, simply init it to -1
[15:15:04] <BBB> if unset, abort()
[15:15:16] <BBB> if set, compare to rt->remote_seq
[15:15:17] <BBB> right?
[15:15:34] <BBB> rt->seq is ours, reply->seq is "them"
[15:15:46] <av500> is there a way to tell configure to run again with the same options as last time? Or am I missing something?
[15:15:58] <mru> make config
[15:16:11] <lu_zero> let me reread
[15:16:14] <av500> thx
[15:16:18] <wbs> j0sh: almost there, now. :-)
[15:16:19] * lu_zero is doing two things at the same time
[15:16:22] * av500 missed something :)
[15:16:37] <lu_zero> in one I'm trying to figure out how to prepare a stupid ui
[15:16:42] <wbs> av500: make config is the best thing since sliced bread. :-)
[15:16:44] <lu_zero> the other to check rt->seq
[15:17:06] <lu_zero> BBB: you are right =_=
[15:17:32] <mru> you can also copy&paste the configure flags from the ffmpeg banner
[15:17:37] <mru> it's all properly quoted
[15:17:49] <mru> useful if you don't have the build tree around
[15:18:06] <av500> right
[15:18:10] <j0sh> wbs, yup, recompiling/testing (caus the doxy patch touched avcodec.h, heh)
[15:18:32] <wbs> j0sh: great - is there any public test url that I could try it out on btw?
[15:18:44] <BBB> lu_zero's website has a test one
[15:18:48] <j0sh> i just used a local instance of feng and gst-rtsp
[15:19:32] <lu_zero> media.lscube.org should have one
[15:19:46] <lu_zero> j0sh: do they work the same way?
[15:20:07] <j0sh> wbs, rtsp://media.lscube.org:554/tests/rms_profumo_1.ogv
[15:20:27] <j0sh> lu_zero, i havent tried that url yet, testing now...
[15:20:55] <j0sh> wait, what do you mean by work the same way?
[15:20:59] <j0sh> both have theora payloaders
[15:21:13] <BBB> j0sh: whether the two are compatible
[15:21:15] <BBB> they should be
[15:21:18] <BBB> both based on the same spec
[15:21:26] <av500> rtsp://media.lscube.org:554/tests/rms_profumo_1.ogv: Error while parsing header
[15:21:43] <lu_zero> j0sh: media.lscube.org uses feng so if your local feng is working
[15:21:51] <lu_zero> then media should as well
[15:21:54] <j0sh> yeah both seem to work, although the streams they send are different... gst-rtsp will use multiple frames per rtp packet, feng doesnt
[15:22:56] <j0sh> but TBH i'm not 100% sure if the frame concatenation code really works, i dont know if vp3.c will detect multiple frames per avpacket
[15:23:11] <lu_zero> ffplay decodes something?
[15:23:16] <j0sh> yeah it does
[15:23:51] <wbs> j0sh: uhm, that rtsp url gives 404
[15:24:08] <j0sh> wbs, yeah i just noticed too (ffplay decodes fine locally)
[15:24:10] <BBB> which reminds me that our RTSP error reporting is seriously poor
[15:24:20] <lu_zero> checking the location now...
[15:24:36] <lu_zero> seems somebody _re_moved them instead moving them =_=
[15:24:54] <lu_zero> BBB: our network error reporting is poor
[15:24:55] <j0sh> lu_zero, feng likes to segfault after playing a few theora videos
[15:25:03] <BBB> that too
[15:25:07] <lu_zero> j0sh: please fill a bug
[15:25:08] <wbs> BBB: isn't requiring the user to fire up wireshark to find out the actual error acceptable? ;P
[15:25:33] <lu_zero> bugs.lscube.org
[15:25:46] <j0sh> lu_zero, will do... need to narrow down a reproducible test case first :)
[15:25:47] <lu_zero> that code hadn't been touched in years^^;
[15:25:51] <lu_zero> thank you =)
[15:28:32] <BBB> good work btw
[15:28:42] <BBB> another depayloader :)
[15:29:07] <av500> libavdepayload?
[15:29:27] <BBB> nah
[15:29:36] <BBB> libavformat_open("rtsp://"); is enough
[15:30:05] <j0sh> if anything we need a ffbeautifycode tool... i never realized my patch had so many spacing inconsistencies, heh
[15:31:30] <lu_zero> j0sh: I have 3 lines in vim to do that
[15:31:59] <lu_zero> and git usually tell you most of the issues in its default color diff
[15:32:12] <j0sh> time to ditch svn then
[15:32:38] <lu_zero> j0sh: I'd put a SoC just to do that...
[15:32:39] <ramiro> Kovensky: have you ever tried mplayer with mingw-w64?
[15:34:20] <j0sh> thats half the reason i havent done the common-code refactoring with vorbis yet -- i have too many changed files for this patch, can't do something like svn --exclude
[15:34:46] * mru recommends using git
[15:34:48] <lu_zero> =|
[15:35:10] <mru> it's impossible to work on several things at the same time with svn
[15:35:11] * BBB tried git and failed
[15:35:15] <mru> try harder
[15:35:16] <lu_zero> mru: nobody merged swscale and ffmpeg...
[15:35:26] <BBB> quilt works in a completely broken but ok'ish way
[15:35:32] <mru> lu_zero: I can do it in git
[15:35:40] <mru> I found an easy enough way
[15:35:51] <mru> which wasn't possible last time I looked at it
[15:35:55] <lu_zero> BBB: fetch from the vlc wiki the git config for svn users
[15:36:00] <lu_zero> oh
[15:36:04] <lu_zero> which one
[15:36:36] <mru> the problem now is that michael and diego are dead set against git
[15:37:31] <jai> :/
[15:37:54] <jai> how do they get any work done with svn
[15:38:07] <mru> beats me
[15:38:20] <Compn> why hasnt anyone modified git to allow typo fixing in comments? :P
[15:38:21] <jai> then again, michael doesn't really do the whole patch workflow :)
[15:38:22] <lu_zero> michael shouldn't
[15:38:36] <mru> Compn: it's possible, it just rewrites the entire history afterwards
[15:38:39] <lu_zero> his only constraint is to get the tree merged
[15:38:42] <Compn> ah
[15:38:56] <mru> lu_zero: michael insists on "svn cp"
[15:38:59] <mru> git doesn't have that
[15:39:06] <mru> nevermind git tracks copies much better
[15:39:08] <lu_zero> what's svn cp?
[15:39:21] <mru> svn's broken copy tracking
[15:39:27] <Compn> copies a file and all its history to a new file
[15:39:28] <av500> it does not track
[15:39:32] <Compn> then you chop the file down
[15:39:33] <av500> it just copies
[15:39:43] <mru> av500: that's why it's broken
[15:39:53] <lu_zero> used to do selective history overwrite or to move stuff away?
[15:39:55] <av500> it works as a copy
[15:39:57] <mru> git manages to ferret out the precise origin of every line
[15:40:14] <av500> mru: agreed
[15:40:15] <mru> even when pieces from multiple files are pulled together
[15:40:25] <mru> svn doesn't even begin to do that
[15:40:29] <av500> no
[15:40:35] <Compn> lu_zero : move stuff from one file to another mostly
[15:40:45] <Compn> like splitting svq1 and mpeg4 decoder or so
[15:40:53] <mru> nor does svn handle code moving around within a file
[15:41:43] <lu_zero> uhm
[15:41:58] <lu_zero> interesting
[15:42:01] <mru> it just shows the lines as deleted in one place and added in another
[15:42:10] <mru> git detects blocks of lines moving within a file
[15:42:25] <mru> if you haven't tried "git gui blame" yet, do it
[15:46:29] <j0sh> wbs, patch sent! *high five*
[15:54:23] <elenril> in the last git vs svn flame it didn't seem like michael was dead set against git
[15:54:53] <av500> that leaves doego? :)
[15:54:57] <av500> diego
[15:55:25] * twnqx understands that
[15:55:31] <twnqx> git is hard to understand.
[15:55:49] <lu_zero> twnqx: git isn't harder to understand than svn
[15:55:54] <lu_zero> if you start from git
[15:55:58] <lu_zero> or mercurial
[15:56:04] <elenril> git is just different
[15:56:04] <lu_zero> instead of cvs
[15:56:07] <elenril> and _awesome_
[15:56:43] <lu_zero> still
[15:56:46] <twnqx> what is really pissing me off about git
[15:56:59] <twnqx> is that it stores all the stuiff that belongs on the server on my local harddisk.
[15:57:12] <mru> that's what makes it so awesome
[15:57:16] <av500> ack
[15:57:18] <mru> it's not a server-client thing
[15:57:20] <jai> +1
[15:57:24] <av500> slow server connection sucks
[15:57:29] <twnqx> yeah, it's really awesome to download 1GB useless codes to get 100MB of source
[15:57:35] <av500> once!
[15:57:39] <mru> and the entire git history is smaller than one svn checkout
[15:57:46] <lu_zero> twnqx: overall git storing the whole history takes less space than svn taking just twice your sources...
[15:57:52] <twnqx> still GREAT if you just want the source and have a 30kb/s umts link
[15:58:06] <mru> git is more bandwidth-efficient than svn
[15:58:12] <siretart> git doesn't support changelog editing, which is used quite a lot in ffmpeg
[15:58:19] <twnqx> svn with "give me THAT revision, and compress it?"
[15:58:36] <elenril> git can do that too iirc
[15:58:38] <lu_zero> siretart: you mean commit message editing?
[15:58:46] <elenril> not that i've ever needed it
[15:58:51] <siretart> lu_zero: sorry. yes, I mean that
[15:59:19] <mru> and how the ffmpeg svn repo ends up containing 46k files is beyond me
[15:59:32] <lu_zero> mru: uh?
[15:59:38] <lu_zero> how so?
[15:59:40] <siretart> elenril: not without breaking every existing clone of the affected revisions
[15:59:57] <elenril> siretart: i was talking about shallow checkout
[16:00:06] <siretart> elenril: oh, I see.
[16:00:29] <lu_zero> siretart: the best way to to do such thing is having a separate branch for lint
[16:00:53] <siretart> still, I'd love to see libswscale moved to ffmpeg, which would be a necessary before moving to git anyway
[16:01:11] <siretart> lu_zero: lint?
[16:01:20] <mru> commit message editing is used _only_ by diego
[16:01:29] <elenril> anyway, commit message editing is used so much in ffmpeg _because_ svn allows it
[16:01:33] <mru> the fact that he does that a lot is irrelevant
[16:01:53] <mru> most of the edits are just adding/removing punctuation anyway
[16:01:55] <lu_zero> siretart: you keep a/many scratch branches
[16:02:30] <lu_zero> have a pull request and in that phase you rewrite the commit messages/history and other fine fixes
[16:03:18] <lu_zero> so you keep the pull tree as clean as possible when you have public work tree
[16:03:37] <siretart> mru: that is not necessarily right. I see lots of svn:log changes by stefano, mstorjo, michael, kostya, lorenm. I could to some statistics on that, but from skimming over the list, I wouldn't say that diego leads that list
[16:03:52] <lu_zero> but I consider that bordering perfectionism
[16:04:10] <mru> they only do it because diego tells them to
[16:04:20] <mru> or because they fear he will
[16:04:43] <lu_zero> anyway you might abuse git push -f and git checkout origin
[16:04:50] <lu_zero> and archive more or less the same result
[16:04:58] <lu_zero> but is a _bit_ ugly
[16:05:17] <mru> editing history breaks every last clone out there
[16:05:21] <mru> you don't want that
[16:05:52] <siretart> how does git-svn deal with edited changelogs? does it update already imported revisions?
[16:05:59] <mru> no
[16:12:31] <mru> that would break any clones or branches you might have
[16:14:40] <lu_zero> siretart: keep in mind that commit message in svn are optional metadata
[16:15:08] <lu_zero> I'm not sure that those changes were tracked
[16:15:18] <siretart> lu_zero: I'm not arguing technically, but how ffmpeg *uses* svn.
[16:15:35] <siretart> lu_zero: technically, I'm convinced that git is superior to svn in many ways, no need to convince me of that
[16:16:42] <iive> i thought that every git commit gets assigned unique uuid or something. in that case the text message could be relevant only if the uuid is derived from it.
[16:16:56] <mru> so what's more important, fairly pointless message editing or actually usable branching etc?
[16:17:15] <mru> iive: the commit hash includes the message
[16:17:59] <av500> mru: that just means you have to try harder to come up with a better commit msg :)
[16:18:15] <siretart> mru: looking at the frequency of editing svn logs, I fear that for ffmpeg, the former seems more important
[16:18:36] <mru> to one dev
[16:18:38] <lu_zero> we could put aspell as pre merge requirement in the server....
[16:18:44] <mru> one who does very little actual development no less
[16:19:20] <mru> you're going about this the wrong way
[16:19:34] <mru> you're looking only at what we'd lose by ditching svn
[16:19:36] <siretart> you could try disabling that in svn for a few weeks and see who other than diego complains
[16:19:38] <mru> not at what we'd gain
[16:19:52] <mru> diego would kill me
[16:19:54] <siretart> that feature is disabled by default anyway, after all
[16:20:01] <elenril> or we could switch to git and see who complains ;)
[16:20:25] <mru> switching to git isn't a trivial task
[16:20:52] <mru> I'll need to make the repo read-only for a couple of days
[16:20:58] <iive> btw, in git it is easier to revert the commit, so to satisfy diego he could revert the commit and demand new with proper message, could he?
[16:21:00] <mru> merge it all together and manually clean out some mess
[16:21:11] <siretart> I'd say get rid of the svn:external and place a copy of libswscale in svn first, and see what flamewars that causes
[16:21:14] <mru> then set up an authentication system, obtain ssh keys from all devs etc, etc
[16:21:23] <mru> siretart: very, very bad idea
[16:21:55] <siretart> iive: reverting a commit in git is to create a revert commit. so you get 3 commits instead of 1 fixed one. plus 2 for any additional iteration
[16:21:57] <mru> it will make checking out an old version impossible
[16:22:15] <siretart> why? isn't svn:external a versioned property?
[16:22:19] <mru> no
[16:22:24] <mru> don't think so at least
[16:22:30] <mru> versioning isn't the svn way
[16:23:14] <lu_zero> siretart: svn:props aren't tracked I'm afraid
[16:23:32] <siretart> lu_zero: depends. some are, some are not
[16:24:43] <siretart> AFAIUI at least. and after reading the svn book, I fear mru is right, and svn:external isn't
[16:25:40] <mru> if it weren't for that, we'd have put the current rev of libsws in ffmpeg long ago
[16:25:55] <mru> and simply let history progress from there
[16:26:28] <mru> the old history would of course still be in the mplayer repo
[16:26:42] <siretart> so you propose to convert to git with libswscale commits woven in?
[16:26:57] <mru> if we ever go git, that's what I'll do
[16:27:11] <mru> but it's needs manual intervention
[16:27:14] <mru> the svn history isn't clean
[16:27:21] <CIA-24> ffmpeg: mstorsjo * r22636 /trunk/ (6 files in 2 dirs):
[16:27:21] <CIA-24> ffmpeg: RTP depacketization of Theora
[16:27:21] <CIA-24> ffmpeg: Patch by Josh Allmann (joshua allmann gmail com)
[16:28:49] <lu_zero> j0sh: congratulations =)
[16:28:59] <mru> he's earned it
[16:29:07] <j0sh> thanks! (what does voice do?)
[16:29:11] <mru> nothing
[16:29:13] <j0sh> lol
[16:29:25] <BBB> congrats
[16:29:26] <lu_zero> when ops feel the case the could +m the channel
[16:29:36] <wbs> j0sh: gives you lot of chicks and street cred ;P
[16:29:37] <lu_zero> but it's basically a nag-target
[16:29:42] <BBB> j0sh: voice gives you a blinking yellow dot, which is a sign of awesomeness
[16:29:56] <av500> my dot is green
[16:30:02] <lu_zero> so people will message you if nobody replies
[16:30:15] <BBB> lol @ street cred
[16:31:04] <j0sh> haha sweet
[16:32:14] <BBB> and feel free to start working on your soc proposal, yours is a little more complicated than that of others because you'll probably be working on multiple smaller tasks
[16:32:16] <j0sh> wbs, i ran the patch through tools/patcheck... nothing came up, where was the trailing whitespace? i noticed some in rtpdec.c but that was already there
[16:32:20] <BBB> so feel free to post it for discussion
[16:32:32] <j0sh> BBB, will do
[16:32:48] <BBB> grep \ $ libavformat/*.c
[16:32:50] <mru> there is no trailing whitespace anywhere in ffmpeg
[16:32:51] <BBB> reveals nothing
[16:32:59] <BBB> so no trailing whitespace
[16:33:04] <mru> we cleaned it all out
[16:33:04] <BBB> and svn commit would blow up if you did, I think
[16:33:06] <wbs> j0sh: somewhere in a multiline av_log() iirc
[16:33:11] <mru> and made it impossible to add new
[16:33:43] * mru wonders what trailing whitespace does in python
[16:33:52] <BBB> Vitor1001: I promise I'll look at the dct/dst, but a bit swamped, so might not be today
[16:34:58] <lu_zero> mru: should do nothing
[16:35:37] <mru> yeah, I know... just taking frivolous stabs at python
[16:35:52] * elenril has an autocmd in vim that highlights all trailing whitespace green
[16:36:15] <elenril> thus making it impossible to miss
[16:36:51] * mru rejoices at his ld_preload hack defeating the broken licence checker in armcc
[16:37:14] <lu_zero> pff
[16:37:47] <mru> every once in a while it would fail, complaining that the system clock had been set back
[16:38:10] <mru> playing some tricks with gettimeofday fixed that
[16:41:11] <av500> so now gettimeofday() returns it time in 1ns incrmenents each time?
[16:42:10] <mru> actually I only added a small delay to each call
[16:43:12] <mru> I have a valid licence so I don't need defeat that part
[16:43:21] <mru> although I'm sure it would be easy if I tried
[16:43:28] <av500> I guess so
[16:43:38] <mru> they use flexlm
[16:43:43] <mru> it's well-known how it works
[16:44:04] <mru> not as easy to break as the ibm xlc protection of course
[16:44:09] <mru> that one's laughable
[16:44:10] <av500> still I miss a hackled matlab, most hacks seem to use licence keys
[16:44:33] <mru> I used to have a matlab licence for some then-current version
[16:44:40] <av500> same here
[16:44:43] <mru> playing tricks with time syscalls made it last forever
[16:51:00] <Vitor1001> BBB: sure, no problem
[16:51:12] <Vitor1001> BBB: Just I forgot to tell you two details:
[16:51:29] <Vitor1001> 1. You should init the dct with half the size you are using now
[16:51:47] <Vitor1001> 2. The ugly 1 element shift will remain :(
[16:54:01] <Vitor1001> that means a memmove() will be needed to preserve the alignment :p
[16:54:47] <BBB> ok
[16:55:34] <BBB> I don't quite know what I should replace what code with
[16:55:37] <BBB> but I'll figure it out
[16:55:50] <BBB> and doesn't the dct->dst take care of the shift?
[16:55:56] <BBB> I thought that was the idea, at least
[16:58:17] <Vitor1001> No, it is hard to get away with the shift :(
[16:58:23] <Vitor1001> It does get away with the mirroring
[16:58:29] <Vitor1001> redundant data is ugly
[16:58:46] <Vitor1001> mirroring + RDFT == DCT
[16:59:16] <Vitor1001> iRDFT of that + ignoring half of the data == DST
[17:09:05] <thomasshirley> Hello folks
[17:09:37] <thomasshirley> I was just wondering, if FFMpeg have any plans to support the Broadcom Crystal HD Card for decoding?
[17:10:41] <kierank> iirc __gb__ is working on it
[17:12:23] <thomasshirley> Thanks :)
[17:12:56] <thomasshirley> Are there any development blogs for FFMpeg?
[17:14:07] <av500> thomasshirley: see also: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/104147/focus=104292
[17:16:58] <thomasshirley> av500: Thank you.
[17:17:09] <thomasshirley> I was poking around the bug tracker to see if I could find anything, to no avail
[17:50:17] <Dark_Shikari> my fucking god the h264 encoder patch is awful
[17:50:20] <Dark_Shikari> it uses static buffers
[17:50:27] <Dark_Shikari> declarations of values 3000 lines away from where they are used
[17:50:34] <Dark_Shikari> massively unrolled functions via 5 levels of nested macros
[17:50:40] <Dark_Shikari> for things that should be asm'd
[17:50:47] <Dark_Shikari> hardcoded versions of existing lavc parameters
[17:50:57] <Dark_Shikari> internal overridden versions of lavc parameters
[17:51:10] <Dark_Shikari> thousands of lines of duplicated existing lavc code
[17:51:59] <av500> so you mean it wont be acked right away? :)
[17:52:02] <iive> is that some new patch?
[17:52:14] <kshishkov> probably it's old H.264 encoder from Takis
[17:52:49] <Dark_Shikari> I haven't even gotten to the actual encoder while reviewing it and its garbage
[17:53:13] <kshishkov> yes, sounds familiar
[18:11:06] <mru> av500: I updated my blog with a photo of the nexus display
[18:12:31] <kshishkov> would Nokia 1110 qualify as smartphone?
[18:12:58] <BBB> does it have a touchscreen?
[18:13:01] <BBB> can it play video?
[18:13:10] <BBB> do people gasp "wow" when they see it?
[18:13:17] <kshishkov> no, because it's smart
[18:13:21] <BBB> if 2 or more of these answer "yes", then "yes"
[18:13:42] <kshishkov> but people sometimes gasp at my 64MB USB Flash drive
[18:14:13] <mru> "New inverted black and white display with amber backlight"
[18:14:16] <drv> at least better than those knockoff 4GB or whatever drives that are really smaller but with broken FAT :)
[18:15:14] <kshishkov> mru: the only downside is when I was in Finland it was hard to tell whose phone is ringing
[18:17:37] <kshishkov> BBB:  about your question - I don't really work on anything right now
[18:29:18] * elenril lols at h264enc
[18:29:40] <elenril> x264 is DOOMed
[18:30:04] <BBB> kshishkov: so I think I have some parts of the decoding functions specific to wvp2/wmvp data discovered
[18:30:13] <BBB> kshishkov: might not be a big thing but anyway :)
[18:31:09] <kshishkov> yes, there was at least prite header reading function
[18:31:16] <kshishkov> *sprite
[18:31:36] <kshishkov> and something for affine transform IIRC
[18:33:54] <Dark_Shikari> there, I submitted a whole patch review of the h264 encoder
[18:34:14] <Dark_Shikari> it's possibly the single worst encoder patch I've ever seen submitted
[18:34:17] <kshishkov> worst. patch. ever. ?
[18:34:25] <Dark_Shikari> I've seen worse patches I think
[18:34:27] <Dark_Shikari> but not worse new encoders
[18:34:44] <BBB> kshishkov: well, so in that decoder struct (the one of size 0x2430), 0x28 is is_wvp2
[18:35:00] <BBB> and function calls under the 0x28h conditional trace to the same function group as those of the sprite error decoding msgs
[18:35:05] <Dark_Shikari> BBB: woot, wvp2 :)
[18:35:06] <BBB> that's about as far as I got
[18:35:39] <BBB> I still have to try and actually have the wmv3 decoder understand wmvp/wvp2, so I can look at the remainder of the unparsed data and see where this all fits in
[18:36:03] <kshishkov> ok, good luck
[18:36:12] <astrange> Dark_Shikari: who did you send it to?
[18:36:20] <kshishkov> I'll try to help
[18:38:06] <Dark_Shikari> what, did I accidentally forget to reply all?
[18:38:14] <Dark_Shikari> no, I replied all
[18:38:20] <mru> I'm reading it
[18:38:33] * kshishkov has done reading it
[18:38:59] <astrange> hmm. my email is broken since 10am
[18:41:27] <BBB> kshishkov: I was hoping you'd mentor it for GSoC
[18:42:02] <kshishkov> unlikely and I'm not a good mentor anyway
[18:42:30] <BBB> wbs: cool!
[18:42:35] <BBB> wbs: will review (yes really)
[18:42:38] <wbs> BBB: :-)
[18:42:40] <BBB> kshishkov: it's not like I am
[18:42:52] <BBB> kshishkov: you'll need multiple mentors for RE tasks, imo
[18:42:56] <BBB> kshishkov: you'd be a good co-mentor
[18:52:28] <Dark_Shikari> so, mru, which is worse
[18:52:32] <Dark_Shikari> h264 encoder or vorbis encoder
[18:53:11] <kierank> what about mp2 encoder?
[18:53:12] <kshishkov> just compile and test
[18:53:31] <Dark_Shikari> the mp2 encoder was written by michael iirc
[18:53:33] <Dark_Shikari> so it can't be that bad
[18:54:34] <mru> mp2 encoder isn't the greatest but usually good enough
[18:54:49] <elenril> wtf, running ff on a remote computer just opens a new window for a running ff on _this_ one
[18:55:00] <elenril> is that supposed to be a feature
[18:55:20] <mru> how's our wma encoder btw?
[18:55:20] <kshishkov> of remote shell client
[18:55:24] <Dark_Shikari> the h264 encoder seems to go by the logic that more code == better
[18:55:30] <kshishkov> written by MN
[18:55:35] <Dark_Shikari> aka paste paste paste paste patse
[18:56:20] <mru> elenril: firefox uses X messages to tell a running one to open a new window
[18:56:57] <mru> and fails miserably if you have multiple displays
[18:57:13] * elenril facepalms
[18:57:40] <elenril> oh well, ff sucks. nothing new here
[18:59:04] * elenril wishes there was a good browser
[18:59:15] <kshishkov> lynx!
[18:59:45] <elenril> obvious troll is obvious =p
[19:01:00] <Dark_Shikari> internet explorer
[19:01:02] <Dark_Shikari> ;)
[19:01:36] <kshishkov> ie5 ?
[19:01:45] <elenril> yeah, right
[19:01:57] <kierank> ie2
[19:02:02] <Dark_Shikari> netscape
[19:02:22] <kierank> elenril: try dillo
[19:02:27] <elenril> at least it didn't require so much ram
[19:02:31] <kierank> that was probably the most pleasing browser i ever used
[19:02:43] <kierank> when ssl and cookies weren't needed
[19:02:45] <Dark_Shikari> it required less ram because Yahoo wasn't a 1.5 megabyte site
[19:02:46] <Dark_Shikari> filled with css and javascript and flash
[19:03:03] <ShadowJK> 1.5M sounds low
[19:03:23] * ShadowJK has seen 5meg .js files part of banner ads
[19:05:46] <wbs> j0sh: btw, how did you do the tests with gst-rtsp?
[19:06:38] <j0sh> wbs, i just compiled it and ran the test-ogg example
[19:07:15] <wbs> ah, it's a completely separate project - that explains why I didn't see it in any repo
[19:08:13] <j0sh> wbs, yeah, iirc, it took me a while to track down too... sorry about that
[19:08:36] <j0sh> i couldnt figure out the gstreamer commands so this was easier
[19:09:46] <j0sh> commented out the audio command though since that was giving me trouble, should be one line in the test-ogg main function
[19:10:12] <j0sh> in g_strdup_printf, that is
[19:10:35] <wbs> j0sh: ah, so this is more or less at the proof of concept stage yet, right?
[19:10:56] <j0sh> what is? the gst-rtsp server? yeah, i think so
[19:10:58] <wbs> gst-rtsp that is
[19:12:43] <j0sh> wbs, but you can still use its theora packetizer with plain gstreamer, i think. its just that the fmtp is really convoluted since xiph also encodes the setup info in the sdp
[19:13:23] <wbs> j0sh: yeah, but using plain packetizers usually is quite painful to set up compared to wrapping in the sdp and everything in rtsp
[19:13:56] <wbs> lu_zero: btw, does feng support sending to the server (as in what the rtsp muxer in lavf does)?
[19:14:33] <j0sh> wbs, the theora draft makes a remark about the possibility of the (fmtp) setup info being fragmented beyond the MTU since there is so much data, does ffmpeg rtsp handle that?
[19:14:42] <astrange> oops, ithinksw.com expired. wonder when the guy who owns it will get out of bed
[19:15:37] <wbs> j0sh: yeah, I think so, as long as it fits in the statically sized buffers along the way
[19:17:29] <sander> Does anyone know a semi-generic way of parsing error messages from ffmpeg?
[19:17:58] <mru> using eyes
[19:18:20] <sander> I'm going to write an opensource ffmpeg wrapper..
[19:18:35] <sander> *on my way doing so*
[19:18:52] <sander> So I need to parse it with a script.
[19:18:54] <Dark_Shikari> aren't there already a few dozen of those?
[19:19:05] <mru> s/dozen/thousand/
[19:19:08] <sander> Dark_Shikari, is it.. :-D
[19:19:11] <Dark_Shikari> (though if you're looking to make something that Automatically Does The Right Thing for, say, a web video site, that would be VERY WELCOME)
[19:19:15] <sander> any good ones?
[19:19:15] <Dark_Shikari> because there is none that doesn't suck for that
[19:19:29] <Dark_Shikari> and I have even written up specs for them
[19:20:47] <sander> We're going to write a generic tool to encode video's uploaded from ftp/webdav/php.. with a php admin interface.
[19:21:08] <sander> Dark_Shikari, cool. Can I get those specs? :-)
[19:21:23] <Dark_Shikari> then I can send you my 15 minute spec
[19:21:43] <Dark_Shikari> email?
[19:21:43] <jai> hmm, anyone here have access to itu specs? possibly at work etc...
[19:21:52] <Dark_Shikari> jai: many are free.  which one do you want?
[19:21:55] <peloverde> which spec?
[19:22:02] <jai> Dark_Shikari: jpeg xr conformance vectors
[19:22:27] <Dark_Shikari> also, sander, note that I worked on a significant part of facebook's system for doing exactly this
[19:22:38] <Dark_Shikari> theirs was quite fancy
[19:22:39] <jai> T.832 to be precise
[19:22:49] <sander> Dark_Shikari, nice! :-)
[19:22:53] <jai> i have a pre-pub copy
[19:23:17] <jai> and FCD of the test vectors, but wanted to see if anything changed since
[19:23:35] <peloverde> http://www.itu.int/net/itu-t/sigdb/speimage/ImageForm-s.aspx?val=10100834
[19:23:57] <peloverde> whoops that's T.834
[19:23:57] <BBB> too ... many ... patches
[19:24:06] <sander> I whould also love to get some ffmpeg wrapper, to be able to parse error logs in a good way(thats the main part which is missing to my ffmpeg integration.
[19:24:57] <peloverde> jai,  T.832 seems to be actual JPEG XR and not conformance
[19:25:16] <sander> Dark_Shikari, pm.
[19:25:20] <jai> peloverde: yep, core coding specification
[19:25:43] <jai> peloverde: i already got the test suite from http://ftp3.itu.int/pub/t/testsignal/SpeImage/T834/v2010_01/ btw
[19:25:52] <Dark_Shikari> sander: already sent it
[19:26:03] <peloverde> so you need the core coding specification not the conformance vectors?
[19:26:17] <kierank> [19:22] <@jai> hmm, anyone here have access to itu specs? possibly at work etc... --> yes
[19:26:50] <peloverde> <Dark_Shikari> jai: many are free.  which one do you want? <jai> Dark_Shikari: jpeg xr conformance vectors
[19:26:54] <jai> peloverde: yeah, and if the vectors have since been updated then those as well
[19:27:07] <sander> I was thinking about detecing errors like: Unknown error, Unsupported audio codec, Unsupported video codec, This video cannot be encoded in this format, Wrong settings for audio, Wrong settings for video, Cannot retrieve info from this video, Not a video file, Unsupported video container, The audio can’t be resampled,
[19:27:22] <Dark_Shikari> and "Segmentation Fault"
[19:27:23] * Dark_Shikari runs
[19:27:41] <sander> ..But I guess it can be simplified abit..
[19:28:38] <sander> I guess I can check the lenght of the output video, to determine of the video was encoded properly..
[19:28:58] <sander> But if sound isn't working.. Then the lenght might still be correct.
[19:29:12] <sander> By length, I mean time in seconds.
[19:29:18] <Dark_Shikari> there are plenty of issues you can't detect, like a/v desync
[19:29:29] <Dark_Shikari> well, you could try.  that might be possible if you have the original file
[19:29:33] <Dark_Shikari> and a player that plays it correctly
[19:32:10] <sander> Dark_Shikari, my approach is to create a command eg. "ffmpeg-batch".. which takes a bunch of dirs and or files.. and searches for config files with ffmpeg parameters in the directory(s)..
[19:32:38] <sander> ..and encodes each files based upon that/those config files.
[19:35:03] <sander> Dark_Shikari, I already have a python script to find the resolution which should be the best multiplum of 16, and not higher than x/y.
[19:35:57] <astrange> x264 doesn't need to encode to multiples of 16
[19:36:24] <astrange> nor does ffmpeg really (the penalty is a bit worse but it's still not bad)
[19:37:09] <sander> I'm thinking about supporting many diffrent formats which is known to work for diffrent devices.
[19:40:05] <justlooking> http://en.wikipedia.org/wiki/List_of_common_resolutions
[19:48:57] <_av500_>  
[19:51:02] * elenril agrees with _av500_ 
[20:19:39] <CIA-24> ffmpeg: michael * r22637 /trunk/libavformat/img2.c: Dont senselessly fail on rawvideo that isnt 3 files per frame.
[20:27:40] <Kovensky> <@ramiro> Kovensky: have you ever tried mplayer with mingw-w64? <-- last time I tried I got stuck on compiling on several places
[20:27:50] <Kovensky> mostly because mplayer's configure didn't notice my triplet was mingw at all >_>
[20:28:04] <Kovensky> x86_64-w64-mingw32
[20:45:16] <lu_zero> BBB: I got another strange situation about networking ^^
[20:54:35] <BBB> ok
[20:54:37] <BBB> ask :)
[20:58:09] <sander> justlooking, Do you have a list of formats and they're coresponding ffmpeg parameters?
[21:01:34] <ramiro> sander: do you have any work done on dshow input?
[21:05:06] <sander> ramiro, I've never used dshow
[21:07:08] <sander> astrange, The python script also tried to keep the diffrence between with/hight when scaling down a video.
[21:13:24] <CIA-24> ffmpeg: michael * r22638 /trunk/libavcodec/ffv1.c:
[21:13:24] <CIA-24> ffmpeg: Disallow VLC coding with more than 8 bits as there are several bugs
[21:13:24] <CIA-24> ffmpeg: in that code that could lead to broken files.
[21:13:24] <CIA-24> ffmpeg: AC coding is unaffected.
[21:13:42] <Dark_Shikari> \o/
[21:15:43] <ramiro> sander: hmm, I think I've mistaken you for sancode =)
[21:17:03] <sander> Dark_Shikari, is it any point in setting the aspect ratio when width/height is set?
[21:18:17] <Dark_Shikari> to force it to 1:1 PAR
[21:18:44] <sander> Dark_Shikari, why force it to 1:1 PAR?..
[21:19:37] <Dark_Shikari> because you already calculated the size making that assumption
[21:19:41] <Dark_Shikari> and for web video you generally want 1:1 PAR
[21:21:15] <sander> I think I want to keep the aspect ratio as original video.. so the video wont be strethed
[21:21:26] <Dark_Shikari> er
[21:21:30] <Dark_Shikari> where did I ever say you would stretch the video?
[21:21:34] <Dark_Shikari> I said PAR, not DAR
[21:21:40] <Dark_Shikari> DAR is of course the same
[21:21:57] <sander> Sorry. i'm not that familar with those terms, i'll read up on it.
[21:22:06] <Dark_Shikari> pixel aspect ratio
[21:22:09] <Dark_Shikari> display aspect ratio
[21:24:25] <sander> So because pixels dont have same hight as width.. an DAR of 4:3 will have PAR of 1?
[21:24:54] <sander> ..That might be wrong to day..
[21:25:04] <Dark_Shikari> DAR of 4:3 may or may not have PAR of 1:1
[21:33:21] <sander> justlooking, Think i'll limit it to popular formats.. maybe 10-20 diffrent ones.
[21:59:29] <CIA-24> ffmpeg: jbr * r22639 /trunk/libavformat/ (flacenc.c Makefile flacenc.h):
[21:59:29] <CIA-24> ffmpeg: Move ff_flac_write_header() to flacenc.h, which removes the Matroska muxer's
[21:59:29] <CIA-24> ffmpeg: dependency on flacenc.o and fixes the unnecessary dependency on vorbiscomment.o.
[22:58:41] <Compn> Dark_Shikari : you reviewed the h264 encoder to look for optimizations ? hehe
[22:58:54] <Compn> good review tho
[23:06:18] <Dark_Shikari> optimizations? hahahahahahahahahaha
[23:06:36] * mru thinks he was just looking for a laugh
[23:35:10] <mru> http://daringfireball.net/2010/03/gif_h264_patents