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

[irc at mansr.com]

[01:57:13] <peloverde> Using C++ in GCC is OK http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html
[01:57:49] <kierank> "Is there anyone who would like to volunteer to develop the C++ coding
[01:57:49] <kierank> standards?
[01:57:55] <kierank> ---> mru should do this
[06:48:23] <peloverde> And another MP3 patent bites the dust... :) (US 5214678)
[06:53:10] <superdump> how many left? :)
[06:53:26] <peloverde> http://wiki.multimedia.cx/index.php?title=MP3_Patents
[06:53:31] <superdump> peloverde: oh, and what do you think of what i said in that aac channel order thread?
[06:53:36] <Tjoppen> \o/
[06:55:03] <superdump> so we have to wait until 2018 until it's patent free?
[06:55:05] <superdump> :)
[06:55:10] <Tjoppen> wait.. how can there be patents from 2000?
[06:55:18] <peloverde> MPEG 2.5
[06:55:19] <Dark_Shikari> Tjoppen: that's why mpeg-la is being sued
[06:55:26] <peloverde> LSF
[06:55:30] <Tjoppen> I see
[06:56:20] <peloverde> superdump, I mostly agree, I'll send out a full answer tomorrow
[06:56:37] <superdump> righto
[06:57:06] <peloverde> what we really need is [type][tag][count]
[06:57:15] <superdump> mmm
[06:57:29] <peloverde> because different tags are allowed to occur in any order, which is a retarded feature but is required
[06:57:35] <superdump> mmm
[06:57:50] <peloverde> al17_* specificly tests that
[06:58:19] <Tjoppen> wait.. the standard was published in 1992, so almost all of those shouldn't be valid?
[06:58:19] <superdump> i think that will be the most versatile, if an extension of the spec
[06:58:38] <superdump> we could support more channels that the spec :B
[06:58:40] <peloverde> OTOH we could assume that files with broken tags don't use that feature
[06:59:04] <superdump> that's basically what i was suggesting
[06:59:30] <superdump> the tags become irrelevant if multiple syntax elements are using the same tag
[06:59:37] <superdump> (of the same type)
[07:00:09] <superdump> maybe the tag information is still of some use
[07:00:29] <superdump> but it would only be for hacking around buggy encoders
[07:01:33] <peloverde> I like that approach but it unnecesarily modal
[07:02:28] <peloverde> I think we could just bucket hash or autoincrement taggs
[07:03:25] <peloverde> e.g. if we've already seen SCE[0] this frame then it becomes SCE[1]
[07:04:19] <peloverde> I'm also interested in incompatible tag concatentation which apparently occasionally happens in the broadcast world
[07:13:47] <superdump> peloverde: mmm, i don't think we can do anything much with the channel ordering though can we? unless the syntax elements are in the correct order to correspond with the default channel configuration details
[07:13:57] <superdump> but i don't think that would necessarily be reliable
[07:14:06] <superdump> i agree with the autoincrementing of tags though
[07:14:25] <superdump> seems like the simplest way, if the most naive :)
[07:27:38] <peloverde> Why did NeXT sign the FSF copyright assignment for ObjC? Legend states the ObjC front end is part of GCC because the GPL forced NeXT to release the code that they wanted to keep closed.
[07:28:25] <KotH> salut
[07:28:39] <kshishkov> umm, because FSF always wants inconvenient stuff like VP8 to be released?
[07:30:50] <peloverde> yes, but how was NeXT forced to sign the FSF copyright assignment necessary to get ObjC merged into FSF gcc?
[07:31:56] <kshishkov> could be the stage when they Jobs didn't care about NeXT anymore
[07:32:15] * kshishkov knows only one good app for NeXT - original Doom
[08:01:26] <astrange> i think they violated the GPL and fsf settled with them to sign the copyright assignment
[08:05:42] <hyc> I got a lot of mileage out of a NeXT cube as a cross-compiler for my Atari ST stuff
[08:06:23] <hyc> made building a minix image from scratch a lot more pleasant than the alternative...
[08:29:08] <pJok> kshishkov, i'd say good morning, but its not a good morning
[08:35:35] <av500> <adjective> morning
[08:35:57] <pJok> av500, too easy... since its not morning anymore
[08:36:15] <av500> <adjective> <time of day>
[08:36:55] * pJok tips av500 over
[08:43:14] <kshishkov> pJok: en dalig morgon?
[08:48:52] <spaam> kshishkov: maybe time to get a keyboard with a swedish layout :)
[08:49:17] <kshishkov> spaam: I thought about that, but they won't understand me at work
[08:49:37] <kshishkov> and it's not that usable for programming
[08:50:10] * kshishkov har tysk tastatur
[08:50:23] <spaam> ok :)
[08:52:51] <superdump> mmm, my main distaste for swedish layouts is the (to me) strange location of '/' and so on
[08:53:04] <superdump> kshishkov: when do you start the new job?
[08:53:26] <kshishkov> superdump: what new job?
[08:53:43] <superdump> on your blog, you said you have a new job
[08:53:52] <superdump> in germany
[08:53:58] <kshishkov> and same distaste here - and I use semicolons quite often when programming in C
[08:54:38] <kshishkov> superdump: have != simply offered. So the time is -6 weeks or so
[08:55:06] <superdump> so you're already doing it?
[08:55:11] <kshishkov> of course
[08:55:16] <superdump> ok, then how is it going?
[08:55:26] <kshishkov> quite fine
[08:55:46] <superdump> good
[08:56:03] <kshishkov> yes, that was a good choice even in retrospective
[08:56:08] <wbs> coding on swedish layout keyboards is a bit awkward yes, but it's bearable once one has gotten used to it
[08:56:33] <kshishkov> superdump: the company is so good that they even invited Mans for a day
[08:56:36] <KotH> is it better or worse than german layouts?
[08:56:41] <wbs> it's quite a bit difference between mac and pc layouts for swedish too, braces and brackets are placed quite differently
[08:57:18] <kshishkov> KotH: better - it's qwerty
[08:57:34] <KotH> lol
[08:57:52] <superdump> probably better than french azerty
[08:57:56] <superdump> that's just nuts
[08:58:11] <KotH> you've never seen the old turkish layout
[08:58:14] <KotH> that's insane
[08:58:34] <superdump> iirc azerty has a lot of keys with non-shift/shift inverted
[08:59:09] <spaam> KotH: so now we know why you are like you are.... :P
[08:59:53] <KotH> spaam: right, i havent kicked you today
[09:00:27] <spaam> KotH: cute;)
[09:02:38] <hyc> hmmm. hulu is only providing 640x360 650kbps now, no more 1Mbps 720x400. I wonder if they're going to hold back their highest rez for paying subscribers
[09:06:13] <lu_zero> eh eh
[09:08:33] <lu_zero> wbs: we could plan the weekly backlog of j0sh_
[09:11:25] <wbs> lu_zero: yeah, that'd be a good idea
[09:12:29] <lu_zero> wbs: email?
[09:12:36] <lu_zero> or right here?
[09:12:36] <wbs> sure
[09:12:47] <wbs> irc works fine too
[09:13:10] <lu_zero> right now our main topic is http-tunnelling
[09:14:55] <wbs> yeah.. what other major and minor tasks do we have?
[09:15:17] <wbs> untangling the rtpdec stuff as much as possible from rtsp.c is at least one of them, i think
[09:15:25] <wbs> the format specific stuff that is
[09:15:55] <lu_zero> I had a list somewhere...
[09:17:23] <wbs> the soc wiki page has some, too: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010#Improve_RTSP.2FRTP_layer
[09:17:52] <lu_zero> that one as well http://socghop.appspot.com/gsoc/student_proposal/comment/google/gsoc2010/j0sh/t126992848896
[09:19:58] <lu_zero> we could abuse the wiki
[09:20:31] <wbs> hmm, I'd better get a wiki account
[09:24:28] <wbs> do you btw have any clue about the mpeg2ts/rtp stuff? restructuring the rtpdec stuff without actually being able to test that part may be a bit risky
[09:26:12] <lu_zero> mpeg2ts/rtp is an abomination I don't like that much
[09:26:37] <lu_zero> it should be converted to a chained demuxer
[09:28:49] <wbs> yeah
[09:29:01] <wbs> but doing any kind of restructuring without samples is quite hard
[09:29:46] <j-b> Any news on the vpx licensing side?
[09:33:39] <lu_zero> we have the spec ^^;
[09:34:07] <janneg> diego backported the non-free change to 0.6 and today is memorial day in the US
[09:36:19] <janneg> I don't think google will fix the license soon. probably takes a few weeks
[09:55:37] <pentanol> or may be here someone knows or may point me what happens in those few looks liek private ioctls during opening V4L1 interface? http://codepad.org/NpPBdigf
[10:12:45] <KotH> pentanol: it might be easier if you'd had a question that is a bit more specific
[10:12:57] <KotH> pentanol: i think you understand as much as we do what's happening there
[10:13:13] <mru> av500: ping
[10:13:17] <KotH> pentanol: (ie opening device, sending ioctls, mmaping, sending more ioctls, etc pp)
[10:14:27] <av500> pong
[10:14:53] <pentanol> KotH, ok, but I've tried it with ffmpeg, put where width and height and rate
[10:15:25] <mru> av500: we need a transport plan
[10:15:30] <mru> any ideas?
[10:15:54] <pentanol> KotH  and then ffmpeg said v4l: colour=0 hue=0 brightness=0 constrast=0 whiteness=0 \n  [video4linux @ 0x423d10]VIDIOCMCAPTURE: Invalid argument
[10:17:15] <av500> mru: i can be 9:37 in berlin spandau on wednesday
[10:17:28] <av500> or somebody else takes it a day earlier
[10:17:42] <mru> I guess that will have to do if nobody else steps up
[10:18:09] <pentanol> also I tries change sequence ioctls a bit, in trace which I give and in video4linux.c from lavd it in different sequence
[10:18:09] <mru> kshishkov: when/how are you travelling to berlin?
[10:21:26] <kshishkov> mru: night train on night before/after LinuxTag
[10:23:43] <KotH> pentanol: i think you want to read 1) the code that initilizes v4l, 2) read on how v4l works
[10:24:12] <av500> KotH: "works" can be debated
[10:26:04] <kshishkov> KotH: s/works/supposed to work when it was not deprecated/
[10:35:00] <thresh> http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html uh oh
[10:35:50] <kshishkov> why not go straight for the Lisp?
[10:36:20] <pross-au> so the world will really end in 2012
[10:36:34] <kshishkov> gcc world as we know it
[10:37:20] * kshishkov thinks they should use Boost as well - it will only slightly increase their codebase and slightly increases compile time
[10:38:03] <pross-au> thats okay the BSD guys are writing pcc
[10:38:25] <jai> bsd guys wanted to switch to clang+llvm right?
[10:40:41] <pross-au> that too
[10:40:56] <Andrius> jai, freebsd, yes: http://lists.freebsd.org/pipermail/freebsd-current/2010-May/017440.html
[10:41:05] <thresh> well, now they can easily go gcc way
[10:41:12] <thresh> it'll be the same, C++ everywhere
[10:41:35] <mru> well, expect no bugfixes or other improvements to gcc for the next 10 years
[10:41:47] <mru> they'll all be masturbating over c++
[10:42:20] <mru> av500: the video wall has a single power lead, right?
[10:42:38] <kshishkov> mru: why? C++ should introduce a good deal of bugs to fix
[10:42:50] <mru> :-)
[10:42:51] <av500> mru: yes
[10:43:12] <av500> ill also get longer hdmi cables, the 1m are too short I think
[10:43:18] <av500> 2m now...
[10:43:31] <av500> and I'll try to make the power cable mess behave a bit more
[10:43:33] <pross-au> so will a ffmpeg c++ decision be forthcoming lol
[10:44:08] * av500 wants // comments NOW!
[10:44:16] <mru> pross-au: it's already been made
[10:44:24] <mru> pross-au: the decision is a resounding NO
[10:44:29] <kshishkov> and a good one too!
[10:44:29] <mru> av500: we already have that
[10:44:44] * av500 wants to declare vars left and right NOW :)
[10:45:08] <pross-au> operator overloading so filter chains can be built in one line
[10:45:57] <jai> template metaprogramming for libsws
[10:46:07] <av500> same for audioconvert
[10:46:22] <av500> codecs can be float and int at the same time!
[10:46:59] <pross-au> the current c templates work just fine
[10:47:44] <pross-au> i hate c++ as much as the next person
[10:47:48] <kshishkov> av500: "float and int at the same time" - for quantum CPUs only
[10:48:15] <av500> kshishkov: just define a new datatype float_int
[10:48:26] <CIA-55> ffmpeg: pross * r23392 /trunk/libavformat/au.c: Prevent au_read_packet() looping endlessly when .au file contains unsupported codec type.
[10:48:33] <kshishkov> pross-au: yer cobber ain't a FFmpeg dev, mate!
[10:48:53] <pross-au> why bother writing codecs. declare the format in prolog and let the computer figure out the rest.
[10:49:07] <pross-au> haha
[10:49:58] <kshishkov> I suspect you'll need to write bitstream to Prolog code generator for resolving it into audio data
[10:51:17] <jai> peter seibel did that with lisp and id3 tags iirc
[10:51:20] <pross-au> in which case C++ sound pathetically low-level
[10:52:10] <mru> has prolog ever been used for anything more complex than hello world?
[10:52:19] <pross-au> yes
[10:52:34] <mru> count to 10?
[10:53:00] <pross-au> i think you need to add the 'practical' word into that hypothesis mru
[10:53:20] <mru> ok, so has it been used for anything practical?
[10:53:22] <kshishkov> mru: it's good for solving those logical puzzles
[10:53:32] <mru> where's the fun in that?
[10:53:38] <pross-au> i recall writing such a puzzle solver in prolog
[10:53:49] <mru> logic constraint solving isn't hard
[10:54:21] <mru> be it "the guy in the red house smokes cigars" or the sudoku variety
[10:55:17] <mru> it's just linear algebra of sorts
[10:55:37] <av500> mru: your hotel?
[10:55:50] <mru> av500: what of it?
[10:55:54] * kshishkov remembered programming compretitions he took part at - all of them were for math knowledge or combinatorics, nothing even remotely real-world
[10:55:55] <av500> which one is it?
[10:56:00] <mru> ivbergs
[10:56:16] <pross-au> kshishkov: did the same
[10:56:28] <mru> I've looked at programming competition problems
[10:56:33] <mru> they're not programming problems
[10:56:33] <av500> mru: there are several?
[10:56:39] <mru> they're maths/logic puzzles
[10:56:50] <mru> av500: neue kantstrasse
[10:58:20] <av500> k
[10:59:58] <av500> what do you pay per day?
[11:00:24] <mru> 70 iirc
[11:00:31] <mru> probably overpriced
[11:00:48] <mru> but I couldn't find anything better closer than schönefeld
[11:02:50] <av500> hm
[13:07:42] <CIA-55> ffmpeg: siretart * r23393 /branches/ (0.5 0.5/configure):
[13:07:42] <CIA-55> ffmpeg: configure: improve temp file creation and cleanup
[13:07:42] <CIA-55> ffmpeg: backport r17752 by mru
[14:20:54] <siretart> hrmpf. writing mails sucks lots of time :/
[14:21:08] <kshishkov> so is talking on IRC
[14:21:15] <mru> but irc is more fun
[14:22:44] <jai> wow, so ffmpeg-LTS eh
[14:23:12] <kshishkov> make FFmpeg EE first
[14:27:49] <KotH> lts?
[14:27:50] <KotH> ee?
[14:28:13] <kshishkov> lts = long term shame or support
[14:28:23] <kshishkov> ee = exitprise edition
[14:29:11] <spaam> KotH: didnt you see ubuntu 10.04 lts ? ;D
[14:29:16] <av500> dont we have to give it cute animal names too?
[14:30:11] <kshishkov> cute?
[14:30:39] <siretart> I need to point out here that I did *NOT* suggest the name ffmpeg-LTS
[14:31:00] * KotH promote ffmpeg-lts as suggested by siretart 
[14:31:31] <siretart> :/
[14:31:56] <kshishkov> siretart: you can rename 0.4.9pre1 to LTS though
[14:32:14] <siretart> kshishkov: why me?
[14:32:18] <kshishkov> and we prefer STS where first letter stands for "shortest"
[14:32:31] <kshishkov> siretart: you're maintainy guy, that's why
[14:32:37] <siretart> I don't care about 0.4.9pre1. at all.
[14:33:11] <jai> siretart: dont worry, you can always point them to the logs for attribution
[14:33:12] <kshishkov> nobody did
[14:33:37] <kshishkov> siretart: that was probably the longest supported FFmpeg release though
[14:34:35] <siretart> I wasn't aware that 0.4.9pre1 got post release updates
[14:34:47] <jai> it did not
[14:35:02] <jai> infact, i clearly remember people being against that idea
[14:35:38] <siretart> so why do you say it was "the longest supported FFmpeg release" if it wasn't updated at all?
[14:35:56] <jai> 20:01      kshishkov@| and we prefer STS where first letter stands for "shortest"
[14:35:59] <jai> siretart: ^
[14:36:10] <siretart> nonsense
[14:37:48] <kshishkov> siretart: it was included in distros for long time, sometimes as more fresh SVN checkout
[14:38:01] <kshishkov> 'twas a long road to 0.5.0
[14:38:35] <siretart> yeah, I've seen references in opencsw and bsd ports
[16:01:14] <TheFluff> 12:35:00 <+thresh> http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html uh oh
[16:01:17] <TheFluff> this is comedy gold
[16:01:26] <TheFluff> Using multiple
[16:01:26] <TheFluff> inheritance, templates (other than when using the C++ standard library,
[16:01:26] <TheFluff> e.g. std::list<X>), or exceptions also seems overly aggressive to me.
[16:01:26] <TheFluff> We should use features that are relatively easy for C programmers to
[16:01:26] <TheFluff> understand and relatively hard for new C++ programmers to misuse.  (For
[16:01:29] <TheFluff> example, I think constructors and destructors are pretty easy and hard
[16:01:31] <TheFluff> to misuse.)
[16:01:34] <TheFluff> using constructors without using exceptions?
[16:01:37] <TheFluff> oh you poor fools
[16:05:13] <ln-> in practice a lot of projects do that.
[16:05:39] <TheFluff> the c++ standard library does it, in fact
[16:05:53] <TheFluff> like ifstream and ofstream don't report failing constructors with exceptions
[16:07:06] <lu_zero> a fork would be interesting
[16:07:48] * lu_zero will push to move to clang and llvm maybe they will be stabler in the short window
[16:09:53] <BBB> lu_zero: you really need 2 channels?
[16:10:02] <BBB> what hideous creature came up with that as a spec?
[16:10:11] <BBB> must be horrible to implement a server and have session management
[16:10:49] <Tjoppen> std::*stream not throwing exceptions is quite wtf
[16:11:12] <Tjoppen> having to insert if(foo) everywhere gets old fast
[16:11:23] <lu_zero> that thread is interesting
[16:11:40] <ln-> Tjoppen: backwards-compatibility
[16:11:48] <Tjoppen> also: requiring a C++ compiler to compile a C compiler?
[16:12:03] <j0sh_> BBB: isnt RTSP somewhat stateful anyway?
[16:12:08] <BBB> this if #ffmpeg-devel right?
[16:12:10] <lu_zero> it is
[16:12:18] * BBB is confused by the c++ discussion
[16:12:26] <lu_zero> BBB: we hate gcc and c++
[16:12:30] <TheFluff> it's not because because of backwards compatibility
[16:12:33] <BBB> rue
[16:12:38] <lu_zero> newsflash -> gcc will use c++
[16:12:39] <TheFluff> it's because c++ exceptions are ???
[16:12:48] <TheFluff> http://yosefk.com/c++fqa/exceptions.html
[16:12:56] <lu_zero> ffcc will appear shortly
[16:13:22] <lu_zero> probably only supporting arm and amd64
[16:13:31] <lu_zero> anyway
[16:13:34] <lu_zero> Honoome: poing!
[16:14:27] <BBB> I'm so glad I don't have to compile gcc myself
[16:14:47] <peloverde> llvm is much more plesent to build
[16:15:02] <peloverde> It doesn't seem to rerun autoconf 3 dozen times
[16:15:47] <Honoome> lu_zero: pong?
[16:19:16] <lu_zero> BBB: has questions about http-tunnel
[16:19:22] <lu_zero> and j0sh_ might as well
[16:19:23] <j0sh_> BBB: do you want to reply-all to the gsoc start email?
[16:19:47] <BBB> j0sh_: reply to ffmpeg-soc, if possible
[16:20:07] <BBB> that way we actually use the mailinglist
[16:20:13] <j0sh_> alrght
[16:20:15] <lu_zero> btw j0sh_ is also interested in getting the extension you were planning in ffmpeg as well
[16:20:24] <BBB> otherwise I created that silly gmail filter for nothing :)
[16:21:07] <Honoome> j0sh_: fire up the questions then ;) I guess it's easier to talk about the extension later
[16:21:38] <BBB> who do we ask for ffmpeg-soc repo access?
[16:22:06] <j0sh_>  Honoome: rtsp replies are all done on GET while requests are done on POST?
[16:22:12] <Honoome> yep
[16:22:20] <Honoome> and the requests are base64-encoded
[16:22:20] <lu_zero> hi beandog
[16:22:26] <BBB> who was on the steering commitee that did this?
[16:22:31] <Honoome> [while responses are not]
[16:22:33] <BBB> and can I get his address so I can shoot him?
[16:22:37] <j0sh_> lol
[16:22:50] <Honoome> BBB: it's apple's own stuff… be glad they documented it at all…
[16:22:57] <av500> mru: I'm booked
[16:23:11] <lu_zero> BBB: you were referring to C++ in gcc or what?
[16:23:13] * BBB gets a shotgun and books tickets to cupertino
[16:23:18] <j0sh_>  docs aren't super clear, i didn't realize the get/post situation
[16:23:34] <Honoome> j0sh_: yeah the original docs from Apple is almost unreadable :/
[16:23:38] <Honoome> http://docs.lscube.org/rtsp.xhtml#rtsp.http-tunneling isn't much better but at least give an idea
[16:23:39] <BBB> lu_zero: no, the double-connection for rtsp-http
[16:23:41] <beandog> lu_zero: lo
[16:23:41] <BBB> lu_zero: :)
[16:24:00] <BBB> mru: can students email you for a soc repo access?
[16:24:09] <wbs> BBB: well, I find it bearable. with one infinite-sized GET request and one infinite sized POST, you effectively get a bidirectional socket
[16:24:22] <wbs> BBB: and the x-sessioncookie header for tying them together...
[16:24:31] <Honoome> wbs: _if_ the proxy allows you to do that
[16:24:32] <BBB> bearable is an interesting term
[16:24:42] <wbs> Honoome: true
[16:24:43] <BBB> I wonder what ffmpeg would look like if all code in it was of "bearable" quality
[16:24:51] <j0sh_>  Honoome: is all rtp interleaved in rtsp?
[16:24:57] <Honoome> unfortunately that's a) broken by caching proxies such as polipo b) broken by application-level firewall
[16:25:12] <Honoome> j0sh_: yup, the rtp requests are sent down the GET
[16:25:33] <Honoome> after the headers, the GET connection is mapped 1:1 with standard RTSP output
[16:25:36] <wbs> Honoome: all such proxies are evil anyway ;P
[16:25:55] <j0sh_>  Honoome: got it
[16:26:26] <Honoome> unless my possible extension is taken into consideration ;) as then you'd be getting base64-encoded responses as well :P
[16:26:44] <j0sh_> rtp isn't base64encoded, but rtsp replies are?
[16:26:47] <Honoome> http://blog.flameeyes.eu/2009/10/24/apple-s-http-tunnel-and-new-http-streaming this is where I wrote down some notes about that
[16:27:10] <Honoome> j0sh_: replies are never encoded as it is… my proposed extension is to (optionally) base64-encode rtsp replies, but not rtp
[16:27:24] <Honoome> by creating a special $0 interleaved channel (feng already starts counting from 1)
[16:28:14] <j0sh_> ah yes, you mentioned replies werent encoded earlier, missed that
[16:28:15] <j0sh_> ok
[16:29:23] <Honoome> j0sh_: if you wish I can give you a wireshark-sniffed session of a quicktime http-tunnel streaming
[16:29:32] <Honoome> [but it's a bit rough, never filtered out the crap :/]
[16:30:29] <j0sh_> sure, i have yet been able to get past sending the base64 OPTIONS request
[16:32:25] <Honoome> I'll upload it on my server, willt ake a while since it's 34MB bzip2-compressed ^^;;
[16:32:58] <j0sh_>  Honoome: heh, thanks!
[16:51:48] <lu_zero> =)
[16:52:10] <lu_zero> hyc: do you have experience with the adobe media encoder?
[16:58:25] <hyc> nope
[16:58:39] <hyc> anything special about it?
[17:01:28] <lu_zero> curious about it
[17:02:01] <lu_zero> some people would consider replacing everything but this
[17:02:09] <lu_zero> so I'm wondering how good it is
[17:02:46] <hyc> mebbe Dark_Shikari has an opinion of it
[17:04:07] <lu_zero> Dark_Shikari: poing
[17:04:33] <hyc> ffmpeg is a pretty nearly complete media suite now
[17:04:53] <Dark_Shikari> lu_zero: pong
[17:05:07] <hyc> add an rtmp listener to ffserver and it's got most of the streaming side covered
[17:15:53] <lu_zero> Dark_Shikari: had experience with the adobe media live encoder?
[17:16:02] <lu_zero> rtmp listener?
[17:16:30] <lu_zero> hyc: ffserver doesn't scale at all so you have a next to perfect testbed
[17:17:04] <Dark_Shikari> No, I don't want to touch that pile of shit
[17:17:08] <hyc> doesn't scale? well, it's single-threaded, so yeah, it's a bit limited
[17:17:09] <Dark_Shikari> seriously it's the worst encoder in the entire world
[17:17:14] <Dark_Shikari> I've seen it lose to x264 at about 8 times the bitrate
[17:17:29] <Dark_Shikari> it loses to its own VP6 encoder at 3 times the bitrate
[17:18:29] <lu_zero> uhmm
[17:18:31] <lu_zero> interesting
[17:19:28] <Dark_Shikari> The best part is how every keyframe, the quality drops to zero
[17:19:32] <Dark_Shikari> because its ratecontrol is broken
[17:19:41] <Dark_Shikari> so the video flashes into blurriness every 3 seconds
[17:19:57] <Dark_Shikari> You'd be better off with Theora than that pile of ass.
[17:20:03] <av500> Dark_Shikari: about vp8 alt-ref as a replacement for b-frames, wouldnt that need to transmit an awful lot of non-displayed alt-ref frames?
[17:20:12] <Dark_Shikari> Yeah =p
[17:20:28] <av500> like every 3rd frame for IBBP...
[17:20:44] <Yuvi> you could have the future P frame be all-skip referencing the alt-ref
[17:20:51] <Yuvi> but that still doesn't get you bime
[17:21:08] <av500> Yuvi: ah, it can do that...
[17:21:21] <av500> so there would be not much overhead
[17:21:35] <lu_zero> the altref golden frame is interesting if you consider it as a fec
[17:21:50] <Dark_Shikari> not really
[17:21:53] <Dark_Shikari> there are better ways to do fec
[17:22:03] <lu_zero> out of box?
[17:22:04] <Dark_Shikari> and that doesn't even work for a number of reasons
[17:22:04] <Dark_Shikari> like
[17:22:14] <Dark_Shikari> "the arithmetic coder will fail until the next keyframe if even one frame is lost"
[17:22:41] <lu_zero> how so?
[17:22:46] <av500> Dark_Shikari: also, about the golden frame e.g being just the unchanging background, yes, it can be that, but what encoder will figure that out?
[17:23:37] <BBB> the encoder just tries it, right?
[17:23:58] <Dark_Shikari> No
[17:24:05] <Dark_Shikari> It just refreshes the golden frame about twice a second
[17:28:40] <av500> thats what existing libvpx does?
[17:30:44] <Dark_Shikari> yes
[17:31:38] <av500> and altref? does it create these?
[17:32:29] <Dark_Shikari> Not by default
[17:34:09] <Honoome> j0sh_: I sent you via pm the URL of the sniffing log ;)
[17:35:26] <j0sh_> awesome
[17:45:28] <jai> siretart: the "less successfull" part was a bit uncalled for ;)
[17:45:36] <jai> -l
[17:47:12] <lu_zero> hyc: librtmp/rtmpdump does act as receiving rtmp server?
[17:53:28] <siretart> jai: I'm referring to distros you most likely never heard of
[17:56:15] <hyc> lu_zero: not completely
[17:56:38] <hyc> rtmpsrv only answers the first few requests, to log what the client sent.
[17:56:44] <hyc> it never actually serves any data.
[17:57:09] <hyc> but that's because I didn't feel like writing all of the backend necessary for a server
[17:57:31] <hyc> since ffserver already provides the backend, I could easily take the frontend from my rtmpsrv and add it
[17:58:37] <hyc> also, i never finished implementing server-side rtmpt support, so that remains...
[17:58:47] <j0sh_> wbs: can we use github as a defacto soc repo?
[17:59:57] <wbs> j0sh_: if there are no formal problems with it, it would be much easier compared to maintaining patches in svn
[17:59:58] <BBB> the disadvantage is that we won't be able to review commits
[18:00:10] <BBB> but git does have some advantages
[18:00:23] <j0sh_> BBB: tied to the ffmpeg-soc ML, you mean?
[18:00:25] <jai> github can send commits to the ML
[18:00:41] <BBB> if we can configure github to send emails to ffmpeg-soc, that'd be great
[18:00:48] <jai> that's possible
[18:00:50] <j0sh_> i will look into that
[18:00:52] <BBB> not that I insist on that, but I do think it's generally useful
[18:01:42] <jai> j0sh_: the email service hook does what you need
[18:05:02] <wbs> with git, you can work in many modes, though... either you branch off from main when you start working, and then work incrementally on that branch, and send diff master..branch as a patch and get it applied
[18:05:28] <wbs> or you could keep one branch as the patch series that you're suggesting to be applied, and rebase/rewrite this according to review feedback
[18:05:52] <wbs> then the commit mails would be the full commits each time, with the modifications made
[18:07:22] <lu_zero> j0sh_: add us to your git then
[18:07:42] <j0sh_> lu_zero: creating it now
[18:07:53] <wbs> for smaller features, I usually go for the second approach, for bigger stuff I usually start off with the former, and then create a second branch that recreates that state with new commits in the way I intend to submit them
[18:07:54] <j0sh_> never used github before, this was a good time as any to start :)
[18:08:03] <lu_zero> I have already an autosynced tree in gitorious
[18:08:31] <lu_zero> btw
[18:08:53] <j0sh_> wbs: i am still getting the hang of git, i really like the staging/index area though so i can do my changes incrementally and have a clean diff
[18:09:48] <j0sh_> that reminds me, how is soc-svn kept in sync with trunk?
[18:09:59] <lu_zero> isn't
[18:10:20] <lu_zero> at least automatically
[18:17:56] <wbs> BBB: where would a good place be to keep a list of j0shs tasks? somewhere on the wiki?
[18:18:07] <BBB> multimediawiki?
[18:18:16] <wbs> yeah
[18:18:21] <BBB> a document on github is fine also
[18:19:10] <wbs> here, http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010#Improve_RTSP.2FRTP_layer, we've already got most of it, but is it ok to e.g. check things off of that list when they're done, and add new ones as we find new stuff to do?
[18:21:51] <BBB> I suppose
[18:22:00] <BBB> if josh is ok with that ;)
[18:22:20] <BBB> but I'd make a new page, this is really his soc project, it's not a soc proposal anymore
[18:22:36] <BBB> and then add a "progress" link on the main page
[18:23:35] <j0sh_> sounds good to me
[18:30:05] <j0sh_> i wonder if github needs to be subscribed to the ffmpeg-soc ML
[18:30:47] <j0sh_> or how does that work? tried testing git's email hook, not showing up
[18:34:34] <wbs> j0sh_: the sender address needs to be subscribed, and what's the sender address in those mail hooks?
[18:36:38] <j0sh_> noreply at github.com, looks like
[18:40:17] <j0sh_> can an admin force a subscribe? iirc we have to confirm subscription, which that address isn't going to do
[18:46:17] <BBB> ask whoever is in charge of the ML according to the archives
[18:46:23] <BBB> might be benjamin, mike or so
[18:46:42] <BBB> admins can force subscribe, yes
[18:46:50] <BBB> probably want nomail option also
[18:46:54] <BBB> so they receive only, no sendto
[18:47:04] <BBB> i.e. ml doesn't send to github, only github sends to ml
[18:47:09] <j0sh_> alright
[18:47:58] <BBB> yeah, merbanan/merbzt (benjamin) runs the list
[18:48:00] <BBB> so ask him
[18:52:09] <wbs> j0sh_: can you configure the mails per branch, too? otherwise, all other commits from the main repo that you push there will be mailed to -soc, too
[18:52:48] <j0sh_> wbs: hmmm, the mail options are pretty limited, it just asks for an email address
[18:53:12] <wbs> ok.. so we'll see how it works out in practice then
[18:53:19] <j0sh_> it doesn't autosync at least
[18:53:52] <wbs> no, of course it doesn't. that's your personal repo where you can store whatever you want, however old or new version
[18:54:05] * BBB goes home
[18:54:13] <BBB> enjoy figuring out github ;)
[18:54:14] * lu_zero is back
[18:54:18] <BBB> I hope I can see patches tomorrow
[18:54:21] <BBB> :-p
[18:55:21] <j0sh_> every time i want to sync, i'll just turn off email or something
[18:55:38] <lu_zero> j0sh_: make more than one branch
[18:56:20] <lu_zero> like an experiments one in which you keep hacks and tries
[18:56:28] <j0sh_> lu_zero: ok
[18:56:45] <lu_zero> so you can scrap it everytime you need that
[18:57:33] <lu_zero> (and enjoy git rebase -i and/or git merge --squash)
[18:57:51] * j0sh_ reads git help pages
[19:29:18] <wbs> j0sh_, lu_zero: I set up a separate wiki page for the project, http://wiki.multimedia.cx/index.php?title=Improve_RTSP/RTP_layer
[19:30:08] <wbs> I'm going to add a few other minor tasks there, too; untangling aac/mpeg4 from rtsp.c as mentioned before
[19:30:17] <j0sh_> alright cool
[19:30:34] <wbs> and also adding RTP packetizers for the formats that we have depacketizers for, to keep it balanced
[19:31:13] <j0sh_> theora/vorbis are a couple i can think of
[19:31:48] <wbs> yeah
[19:37:29] <wbs> j0sh_: you got a wireshark capture of http tunneling, btw, or do you want another one?
[19:37:56] <j0sh_> Honoome sent me one, thanks tho
[19:38:40] <wbs> ok
[19:43:55] <_av500_> a
[19:44:02] <wbs> b
[19:44:18] <av500> :)
[19:59:50] <dezodorant> definitely something wrong with mp3 probing
[20:00:05] <dezodorant> and good evening everyone )
[20:00:50] <dezodorant> need help with this issue https://roundup.ffmpeg.org/issue1954
[20:01:22] <dezodorant> cannot git-bissect it, working revision is a little bit far from current
[20:01:43] <av500> is rounddown?
[20:01:51] <av500> ah no
[20:02:03] <elenril> just lolslow
[20:03:16] <dezodorant> as usual, but problem is serious, i have compare decoders behavior and only lav fail
[20:04:22] <pengvado> why does distance from current matter?
[20:04:37] <dezodorant> swscale
[20:04:52] <wbs> can you name one working revision?
[20:05:02] <dezodorant> it`s impossible to synchronies lav and swscale
[20:05:15] <dezodorant> ubuntu build )
[20:05:25] <dezodorant> and 0.5.2
[20:06:00] <pengvado> http://pastebin.com/Kq5xdBeA <-- here's a script, compatible with `git bisect run`, which works across swscale updates
[20:06:26] <pengvado> you'll need to update the actual test part of the script, of course
[20:06:57] <dezodorant> nice
[20:07:00] <dezodorant> i`ll try
[20:07:02] <av500> pengvado: that could be in tools?
[20:10:16] <Honoome> I want to cry =_=
[20:10:44] <Honoome> Wireshark seems not to be helpful to inspect SCTP traffic =_=
[20:11:07] <wbs> what, a protocol that wireshark doesn't support? impossible :-)
[20:11:36] <Honoome> wbs: it reports the DATA chunks as DATA… but does not inspect them further
[20:11:40] <Honoome> so it doesn't find RTSP-in-SCTP
[20:12:04] <wbs> ah
[20:13:35] <wbs> well usually wireshark doesn't recognize RTP in UDP either, unless it did see and recognize the setup conversation
[20:14:30] <Honoome> true but it doesn't _go_ to inspect RTSP-in-SCTP so it cannot identify any other protocol down to that
[20:16:01] <ramiro> http://gcc.gnu.org/ml/gcc/2010-05/msg00763.html "we are in danger to get slowly degrading compiler." <-- oh, they finally noticed?
[20:19:04] <peloverde> At least C++ has reasonable rules for const casts
[20:19:21] <Honoome> hah;
[20:19:26] <Honoome> like people actually cared…
[20:20:21] <peloverde> The huge number of const warnings C spits out mask the actual important warnings
[20:21:00] <Honoome> and yet people are still going on to just use (char*) casts rather than fixing underlying issues most of the time
[20:21:43] <peloverde> that's not the warning I'm talking about
[20:22:32] <Honoome> I was talking about the important warnings-became-errors lately
[20:23:07] <Honoome> sincerely, I still feel C++ is embryonal because every minor GCC update ends up with a huge mess of packages that fail to build because they did something wrong before, but it was still accepted
[20:23:41] <Honoome> e.g. with 4.5, with a class Bar in namespace Foo you can no longer do Foo::Bar b = Foo::Bar::Bar(...); because that's calling the constructor directly…
[20:24:04] <Honoome> I'm pretty sure I was told that was the wrong syntax in high school already… why was it accepted _at all_ before?
[20:25:29] <peloverde> http://pastebin.ca/1875025 drives me crazy
[20:26:24] <Honoome> guuh okay that one I remember now… yeah it's a mess especially to get people to mark the bloody tables constant!
[20:26:50] <peloverde> It super sucks if you have optional hardocded tables
[20:27:50] <Honoome> like ffmpeg has ^^
[20:27:53] * Honoome whistles
[20:29:48] <peloverde> indeed
[20:30:35] <pengvado> av500: if you want to modularize it and document it, ok. I'm not motivated to do anything more to that script.
[20:31:02] * Honoome is having accept() throwing ENOSUPP on a SCTP socket… doesn't look right
[20:46:39] <DonDiego> hi
[20:46:46] <DonDiego> anybody seen janneg around today?
[20:46:54] <DonDiego> when are you guys arriving for linuxtag?
[20:50:04] <merbanan> thursday
[20:53:39] <av500> wednesday morning
[20:56:18] <siretart> DonDiego:
[20:57:01] <siretart> DonDiego: he was around here about 12h ago
[20:58:13] <DonDiego> Yuvi: will you apply the theora bitexactness thing?
[20:58:23] <DonDiego> i have gregory maxwell complaining at me...
[21:02:01] <Honoome> does anybody here have a known-working sctp setup?
[21:29:14] <dezodorant> aaa eee. pengvado thanks for idea, i found that fxxxing commit
[21:29:17] <dezodorant> [988fbb31456dd3dbdf1ea42bbba664bd8eff9a09] Rewrite mp3 parser. New code is much simpler and does not drop stuff at random.
[21:33:19] <peloverde> It's funny how fedora is willing to ship non-LGPL compatible code linked to LGPL code... http://blogs.gnome.org/otte/2010/05/31/youtube-out-of-the-box/
[21:34:28] <Dark_Shikari> BUT ITS FREEEEEEEEEEEE
[21:34:39] <Honoome> Dark_Shikari: oh shut up, I was going to say that line myself!
[21:35:01] <siretart> peloverde: well, technically, they don't
[21:35:03] * Honoome is glad they didn't use Ogg…
[21:35:03] <Dark_Shikari> YOU'RE NOT FREE ENOUGH
[21:35:33] <j-b> peloverde: blog about it
[21:35:38] <peloverde> siretart, what do you mean "they don't?"
[21:36:55] <siretart> peloverde: the code is not dynamically linked but loaded via dlopen. so strictly speaking, the violation happens at runtime on the users system
[21:37:21] <Dark_Shikari> That's not an excuse
[21:37:28] <Dark_Shikari> remember clisp and readline?
[21:37:29] <Dark_Shikari> Yeah.
[21:37:56] <peloverde> DS is right
[21:38:14] <Honoome> violation only happens if FSF feels like it does, I guess
[21:38:34] <siretart> btw, for comparison: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583758
[21:42:42] <CIA-55> ffmpeg: diego * r23394 /trunk/LICENSE: Add a short note about libvpx.
[21:44:36] <peloverde> Even if libgstvpx is relicensed to BSD, don't we still have the clisp situation higher up the food chain?
[21:45:58] <twnqx> i thought that situation only occurs with "does not work (meaningful) without"?
[21:48:37] <peloverde> with that definition of "does not work meaningfully without" we could dlopen a decent AAC encoder, no?
[21:50:42] <CIA-55> ffmpeg: siretart * r23395 /branches/ (0.6 0.6/LICENSE):
[21:50:42] <CIA-55> ffmpeg: Add a short note about libvpx.
[21:50:42] <CIA-55> ffmpeg: backport r23394 by diego
[21:50:47] <Honoome> peloverde: only if Google were to acquire Nero/ahead
[21:51:29] <peloverde> These rules don't seem to be contently applied
[21:52:55] <j-b> Fedora and Novell people are refusing all FFmpeg code (and refuse to package VLC until we split our packages...) but are always fine to listen to the license mess GST has
[21:53:49] <Dark_Shikari> good thing nobody uses fedora for desktop linux anyways
[21:53:57] <peloverde> Sometimes I wonder if it would have been better to spend all the money used on vp8 and theora to fight software patents
[21:54:04] <Dark_Shikari> just host a fedora package on the videolan official site
[21:54:05] <Dark_Shikari> to spite them
[21:54:05] <j-b> Dark_Shikari: linus does
[21:54:22] <peloverde> I'm looking for a non-ubuntu alternative
[21:54:28] <Dark_Shikari> arch
[21:54:29] <Dark_Shikari> gentoo
[21:54:33] <j-b> peloverde: Arch
[21:54:56] <saintdev> arch broke for me within 3 days....and most of my other installs are gentoo
[21:55:06] <Dark_Shikari> so the gentoo installs broke in 2 hours?
[21:55:35] <saintdev> only times my gentoo installs have broken is when i've done something stupid
[21:55:39] <j-b> debian/sid
[21:55:56] <twnqx> i have a sid in my c64
[21:56:47] <saintdev> ie: forgetting to compile root fs driver in the kernel, then attempting to boot it
[21:57:09] <Honoome> saintdev: what about blindly updating the system and then forget to run the cleanup tasks? :P
[21:57:32] <saintdev> i don't blindly update
[21:57:41] <saintdev> that's just asking for trouble
[21:58:14] <peloverde> debian/sid is a non-starter for me, last I checked they linked chromium to system ffmpeg
[21:58:15] <Honoome> that's about 80% of the problems people encounter with Gentoo :/
[21:58:41] <peloverde> vanilla ffmpeg has lots of crashers that don't exist in th chromium hardened version
[22:00:37] <peloverde> I like the idea of ubuntu but so much stuff breaks every release, and filing bugs against the beta doesn't seem to help
[22:01:15] <Dark_Shikari> yup, latest ubuntu is still broken completely in vmware
[22:01:19] <Dark_Shikari> it's impossible to make it even work
[22:01:29] <Dark_Shikari> I had to roll back via a VM wipe
[22:01:45] <Dark_Shikari> And the bug had been reported weeks before release.
[22:01:55] <Dark_Shikari> The solution involved typing a variety of commands once logged in.
[22:02:00] <Dark_Shikari> This doesn't help, since the bug is that the KEYBOARD IS BROKEN
[22:02:09] <peloverde> I'm more concerned about stuff like zzuf just disappearing, and vim spamming the console, and wish not playing nice with compiz
[22:02:21] <CIA-55> ffmpeg: bcoudurier * r23396 /trunk/libavcodec/h264.c: Pass codec pixel format list to get_format, if present, fix vdpau decoding
[22:02:29] <kierank> use virtualbox instead?
[22:02:42] <Dark_Shikari> iirc there were people reporting the same with vbox
[22:02:44] <Dark_Shikari> and other vm systems
[22:04:18] * Honoome just loves ubuntu… their gnome rdp server fails to work with gentoo's (and fedora's) gnome rdp client
[22:20:10] <DonDiego> janneg: try leaving and reentering the channel..
[22:24:22] <DonDiego> there you go :)
[22:24:33] <DonDiego> ok, make your first commit..
[22:25:00] <janneg> make still runs
[22:32:01] <janneg> done
[22:32:42] <CIA-55> ffmpeg: janne * r23397 /trunk/ffmpeg.c: ffmpeg: fail if user selected codec is experimental and strict_std_compliance > experimental
[22:36:06] <CIA-55> ffmpeg: janne * r23398 /trunk/ffmpeg.c: ffmpeg: offer alternatives for experimental codecs if they exist
[22:45:27] <DonDiego> welcome aboard
[22:45:29] <DonDiego> ok, gnite