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

[irc at mansr.com]

[00:00:19] <ohsix> or wait, i take that back; i updated from karmic -> lucid since i last went there, flash is the same though
[00:00:32] <bcoudurier> janneg, we don't have experimental decoders anyway
[00:00:46] <lu_zero> ohsix: flash might still crash, but I'm more and more convinced that's partly fault of the plugin interface
[00:00:52] <hyc> ohsix: interesting. Hulu had new encryption mechs enabled, which aren't present in the 64 bit flash plugin
[00:01:14] <hyc> this would mean they've lowered their security settings back to pre-Flash 10.0.22
[00:01:32] <ohsix> lu_zero: mebbe, but when i say never i meannever :O (old java plugin? not so much)
[00:01:43] <Kovensky> <@DonDiego> http://www.osnews.com/story/23346/Nero_Files_Antitrust_Case_Against_MPEG-LA <-- I like his neutral, professional tone
[00:02:01] <ohsix> hyc: oh, FMS stuff? i think i read about that; file signing or something and an extra challenge
[00:02:06] * lu_zero is still trying to figure out how to make the vlc plugin not crash
[00:02:16] <hyc> ohsix: or you just got lucky - Hulu used to be exclusvely on Akamai, now they're also using Level3 and Limelight CDNs
[00:02:40] <hyc> which one you get at any particular time seems random, and they're all at different revisions of FMS
[00:02:49] <ohsix> i'll see if i'm still lucky later
[00:03:57] <ohsix> now that i think of it the applet signing thing might have been iplayer :O
[00:04:32] <kierank> hyc: bbc is the same
[00:04:35] <bcoudurier> hehe
[00:04:41] <janneg> bcoudurier: yes. should I repost a patch without the avcodec_find_decoder changes or can you just commit without it
[00:05:36] <hyc> Hulu turned on SWF verification a while back, but then they turned it off again
[00:06:12] <hyc> they probably figured out it wasn't worth the additional load on their servers
[00:06:57] <ohsix> it seems silly; i cant imagine managing supporting multiple viewers, which obviously includes multiple versions of the same viewers that might be around :[
[00:07:46] <hyc> it was probably keeping a grunt employed for a few months, to stay on top of all those versions they were kicking out
[00:21:08] <hyc> wbs, bcoudurier: ok, fixing cur_dts for H264 in libavformat fixed get_packet_send_clock() for me
[00:23:04] <DonDiego> gnite
[00:23:56] <hyc> what a coincidentally relevant exit msg...
[00:36:16] <bcoudurier> humm ohsix, you smoking good pot
[00:36:24] <bcoudurier> 64bit doesn't play here
[01:20:18] <CIA-93> ffmpeg: cehoyos * r23303 /trunk/ (7 files in 3 dirs):
[01:20:18] <CIA-93> ffmpeg: VP8 decoding via libvpx.
[01:20:18] <CIA-93> ffmpeg: Patch by James Zern for Google, Inc., jzern google com
[01:37:10] <hyc> bcoudurier: you can always use this instead http://forum.xda-developers.com/showpost.php?p=6495551&postcount=8
[01:53:21] <bcoudurier> janneg, are you still there ?
[02:35:24] <janneg> bcoudurier: yes, can't sleep
[02:57:28] <hyc> kinda funny how everyone's making a big deal about Android 2.2 being able to stream from Hulu
[02:57:46] <hyc> and then having Hulu block it again a few hours later
[02:58:17] <astrange> whoops, spent way too much time looking at a bug in mt that turned out to be on mainline too
[02:58:34] <astrange> too bad i still can't figure out the cause, it's in avfilter dr1 somewhere
[03:20:43] <CIA-93> ffmpeg: conrad * r23304 /trunk/libavcodec/vp3.c:
[03:20:43] <CIA-93> ffmpeg: theora: Don't read an excess bit for maximum length long bit runs if the run
[03:20:43] <CIA-93> ffmpeg: exactly ends the remaining blocks.
[03:21:07] <Dark_Shikari> does that need backporting?
[03:21:42] <Yuvi> yep, siretart ^
[03:22:27] <Yuvi> I think diego is reporting SDL bugs to me again...
[03:25:05] <Yuvi> now, to make the decoder bitexact to libtheora: the put_no_rnd_pixels mmx2 functions need to be fixed
[03:26:38] <Dark_Shikari> it has errors that accumulate?  that sucks
[03:27:11] <Yuvi> I've yet to find anywhere it accumulates enough to be visible, even with 500 frame gop which noone uses for theora
[03:27:16] <Yuvi> but it should be fixed
[03:27:37] <Yuvi> hope michael doesn't require me to bench on the PII/PIII he wrote these for...
[03:27:53] <Dark_Shikari> are you going to be able to get rid of the branch in mc?
[03:28:02] <Dark_Shikari> also do we have w16 motion compensation yet (sse)?
[03:28:12] <Yuvi> eventually and no
[03:29:10] <Yuvi> do kinda wish I could rewrite dsputil_template* in yasm to get width sse for free...
[03:29:21] <Dark_Shikari> use yasm ;)
[03:30:00] <Yuvi> doubt michael will accept that given that everything uses those functions
[03:37:18] <astrange> i have a pIII but i don't think we're actively benchmarking on those anymore
[04:05:25] <astrange> https://twitter.com/rentzsch/status/14669859679 oops?
[04:20:48] <astrange> siretart: could you backport r22730 to the branches it's not in? i thought it was there, but apparently not...
[05:36:33] <Tjoppen> morning
[05:46:51] <_av500_> morning
[05:49:56] <pJok> goda morgonar, kshishkov :)
[05:58:12] <benoit-> good morning
[06:12:41] <jai> hmm
[06:12:46] <jai> "libwebm - a library for creating and parsing WebM container files"
[06:12:50] <jai> is there such a thing?
[06:13:24] <elenril> renamed libmatroska?
[06:14:46] <bcoudurier> google doesn't find anything
[06:15:21] <jai> http://www.webmproject.org/code/repository-layout/
[06:15:27] <jai> ^ found that here
[06:22:24] <astrange> http://i.imgur.com/vvNtU.png how can an intra-only MB decode differently with threads on...
[06:22:35] <astrange> well, at least there's not many stages involved, i can just add asserts
[06:24:32] <Dark_Shikari> astrange: loopfilter?
[06:24:42] <astrange> turned it off
[06:27:04] <astrange> guess: h->mb isn't cleared. forgot what does that
[06:29:53] <astrange> need a better code browser too, so i can open arbitrary files more than once. maybe i should figure out emacs
[06:30:22] <Yuvi> you can do that in textmate, as long as you don't need them in the same window
[06:30:36] * elenril wonders how to open urls from irssi without using mouse
[06:31:12] <superdump> morning
[06:31:30] <Dark_Shikari> is uint8_t (*x[2])[2][4][4] an array of two pointers to uint8_t [2][4][4]s?
[06:31:34] <Dark_Shikari> I hate cdecl
[06:32:02] <Yuvi> why? just use random types instead of stdint.h
[06:32:15] <Dark_Shikari> ?
[06:32:26] <Dark_Shikari> how does that fix problems with scary arrays of pointers to arrays of arrays
[06:32:26] <Yuvi> and yeah
[06:32:47] <astrange> http://cdecl.org/
[06:32:54] <Yuvi> oh, I though you were talkgin about cdecl.org
[06:33:11] <superdump> Dark_Shikari: what you said would make sense
[06:36:02] <astrange> yeah, h->mb needs to be zeroed the first time a decode thread runs. can't believe that lasted until now
[06:37:59] <astrange> so 1 day for 1 line fix and i found 2-3 bugs in mainline along the way. that's about average
[06:43:40] <superdump> astrange: how is ffmpeg-mt going?
[06:44:31] <KotH> y0!
[06:45:06] <elenril> sup dawg
[06:51:35] <astrange> todo got shorter. a day or two and i'm sure i can send a patch that will play theora
[06:52:53] <superdump> cool
[06:53:10] <superdump> are you receiving any funding to eventually push it towards a merge into trunk
[06:53:12] <superdump> ?
[07:00:13] * KotH sends astrange some swiss chocolate
[07:00:17] <KotH> superdump: yes he does ;)
[07:00:42] <superdump> i was the one who tipped him off about it (they were going to pay me)
[07:01:55] <CIA-93> ffmpeg: kostya * r23305 /trunk/libavformat/rtmpproto.c:
[07:01:56] <CIA-93> ffmpeg: 24l trocadero: RTMP reader forgot to shift high byte of timestamp to its
[07:01:56] <CIA-93> ffmpeg: proper position
[07:01:56] <CIA-93> ffmpeg: Patch by trueice (his gmail account is obvious)
[07:02:50] <kshishkov> pJok: goda morgnar men det är min ADSL har reset klockan åtta
[07:07:30] <_av500_> adsl reset your klock?
[07:08:16] <superdump> :)
[07:08:17] <kshishkov> it resets at around eight o'clock CET
[07:08:36] <kshishkov> you should learn Swedish, this is FFmpeg development channel after all
[07:08:49] <superdump> :)
[07:10:17] <siretart> astrange: hrmpf. you mean for 0.5? 0.6 certainly has that patch.
[07:10:44] <siretart> astrange: anyway, I'll put it on my list, the patch does not backport cleanly. I'm currently at work
[07:11:57] <_av500_> kshishkov: reset it once at e.g. 3am, i guess it has a 24h timer...
[07:13:19] <kshishkov> _av500_: why should I do resets at all? It's ISP that does it at that time no matter when I reset it manually
[07:13:57] <astrange> siretart: k. x86-64 works without it, i think that's the most common platform already
[07:15:16] <_av500_> kshishkov: to move the reset time to a more convenient hour (in case you care)
[07:15:50] <kshishkov> _av500_: told you, I've tried it several times with no luck
[07:16:02] <_av500_> ah ok
[07:16:40] <_av500_> get e decent isp
[07:16:43] <_av500_> a
[07:17:07] <kshishkov> got one but it's not in Ukraine :P
[07:17:44] <wbs> wouldn't that normally be a bonus? :-)
[07:20:09] <kshishkov> wbs: of course, but until I get proper setup here, I'd use my EEE left at Ukraine for running irssi
[07:22:37] * _av500_ has a local isp with fixed ip and no daily reset
[07:22:46] <kshishkov> same here
[07:22:51] <kshishkov> (I think)
[07:27:12] <CIA-93> ffmpeg: mstorsjo * r23306 /trunk/doc/general.texi: Fix VP8 listing in general.texi
[08:15:47] <lu_zero> good morning
[08:16:09] <kshishkov> hej
[08:59:06] <CIA-93> ffmpeg: cehoyos * r23307 /trunk/libavcodec/libvpxdec.c: Headers for libvpx are installed into vpx subdirectory.
[09:00:47] <siretart> okay, now that libvpx support is in, does anyone know what is the status for webm support in avformat?
[09:01:59] <superdump> there was another thread on the ml iirc
[09:02:31] <siretart> I read that as 'pending'
[09:02:49] <j-b> why move to vpx/ ?
[09:03:18] <siretart> j-b: it was claimed that libvpx's Makefile would install the headers to /usr/include/vpx
[09:03:50] <astrange> demux is in, i think encode and mux are pending?
[09:04:21] <j-b> siretart: weird, I didn't saw that
[09:04:21] <kshishkov> seems so
[09:04:40] <jai> muxing is pending
[09:05:03] <j-b> siretart: I don't really care as far as it doesn't change every 2 days :D
[09:05:24] <jai> carl didnt update configure btw
[09:06:10] <wbs> jai: I pinged him about that on cvslog
[09:06:35] <jai> wbs: ah, ok
[09:22:49] <CIA-93> ffmpeg: mstorsjo * r23308 /trunk/configure: Look for libvpx headers in the vpx subdirectory in configure, too
[09:47:40] <lu_zero> wbs: ping2
[09:47:49] <wbs> lu_zero: pong1
[09:47:55] <wbs> lu_zero: tested it right now
[09:49:04] <wbs> lu_zero: DSS was initially configured with 1000 max connections, then it crashed when reaching the max... when I set it a bit lower it worked quite well
[09:49:12] <lu_zero> [8633885.510229] DarwinStreaming[3871]: segfault at 8ae1040 ip 0000000008106a99 sp 00000000f74c3ed0 error 6 in DarwinStreamingServer[8048000+fe000]
[09:49:16] <lu_zero> eh...
[09:49:36] <lu_zero> and also seems to leak
[09:49:38] <wbs> feng also crashes if I set the max connections to 1000 there
[09:50:14] <wbs> yes, it's not all that pretty.. I've fixed some valgrind warnings in dss in http://github.com/mstorsjo/dss at least
[09:51:46] <wbs> lu_zero: this is the crash I got with feng: http://pastebin.org/278296
[09:52:17] <lu_zero> current master?
[09:52:31] <wbs> quite recent at least, not exactly todays master
[09:52:41] <wbs> and with libnetembryo 0.1.1 if that matters
[09:54:25] <lu_zero> I'll try to reproduce it
[09:54:27] <lu_zero> that's new
[09:54:59] <wbs> a wild guess is that it's out of file descriptors, normally a process is limited to 1024 unless you lift the ulimit
[09:56:23] <lu_zero> uhm
[09:56:25] <lu_zero> right
[09:56:36] <lu_zero> I did not address that yet
[09:57:02] <lu_zero> what happens if you raise the limit?
[09:58:07] <wbs> I'll try
[09:59:17] <wbs> hmmm, it ran for a while, then it crashed in some other way
[09:59:25] <wbs> outputting too much data to fit in my terminal scrollback ;P
[10:00:20] <lu_zero> please fetch the latest one
[10:00:41] <lu_zero> so far diego is killing his local network first before killing feng ^^;
[10:00:57] <wbs> I'm just running this over loopback :-)
[10:01:27] <lu_zero> you must have quite a cpu =)
[10:02:02] <wbs> it's a quad xeon :-)
[10:03:49] <lu_zero> I see
[10:04:50] <wbs> still crashing http://pastebin.org/278334
[10:06:09] <lu_zero> interesting
[10:06:19] <lu_zero> can you reproduce it in some way?
[10:06:39] <lu_zero> if yes please fill a bug, I couldn't find a reliable way to cause it
[10:07:45] <wbs> got the same crash at the same place in the next run, too
[10:08:26] <lu_zero> great =)
[10:10:49] <lu_zero> give me a report =)
[10:11:09] <wbs> done
[10:12:08] <lu_zero> thank you
[10:14:33] <wbs> since updating it to the latest version, it doesn't crash if the max file descriptor limit is at 1024 as normal, but it hangs instead, not able to serve new clients
[10:14:37] <wbs> I'll file a separate bug for that
[10:18:46] <lu_zero> thank you
[10:29:48] <lu_zero> do you have valgrind handy?
[10:36:39] <CIA-93> ffmpeg: cehoyos * r23309 /trunk/libavformat/riff.c: Samsung uses SIPP as FourCC for MPEG-4 ASP.
[10:51:16] <_av500_> lol: https://review.source.android.com/#patch,sidebyside,14699,1,libc/memset.c
[10:51:33] <_av500_> never mind the byte access
[10:52:23] <spaam> _av500_: do you ever set it do something else then 0? ;)
[10:52:27] <kshishkov> the question is how they found out the bug
[10:56:14] <janneg> libavcodec/4xm.c:    memset(up, -1, sizeof(up));
[10:56:41] <_av500_> so thex want to add 4xm to android...
[10:56:49] <spaam> haha
[10:56:50] <_av500_> whatever that is,,,
[10:57:21] <janneg> and aac and ac3
[10:57:45] <_av500_> aac they have
[10:57:58] <_av500_> ac3 they will never have
[10:58:14] <mru> nor dts
[10:58:21] <mru> because the omap3 isn't certified for dts
[10:58:21] <janneg> libavcodec/anm.c:            memset(*dst, pixel, striplen);
[10:58:28] <janneg> whatever that is
[10:58:56] <janneg> cavs uses non-0 memsets too
[10:59:58] <wbs> lu_zero: I'll give it a try
[11:03:20] <mru> http://carlodaffara.conecta.it/?p=420
[11:09:58] <astrange> get_buffer uses memset 0x80
[11:15:49] <Kovensky> "It is also true that x264 beats the hell on current VP8 encoders (and basically every other encoder in the market); despite this, in a previous assessment Dark Shiraki performed a comparison of anime (cartoon) encoding and found that VP7 was better than Apple’s own H264 encode – not really that bad."
[11:15:57] <Kovensky> I like how he says that beating Apple's encoder is something to brag about
[11:16:28] <mru> the real question is whether he has any qualifications whatsoever to comment on patent issues
[11:17:41] <Compn> no, he does not
[11:17:54] <Compn> patent lawyers also do not if you think about it
[11:17:57] <Kovensky> next time people will say beating Bink or Indeo is a good thing
[11:17:59] <Compn> most anything is patented
[11:18:09] <Kovensky> in b4 talking about patents is patented
[11:18:20] * pJok patent trolls ffmpeg
[11:19:15] <jai> "Dark Shiraki"?
[11:20:03] <janneg> http://fosspatents.blogspot.com/2010/05/webm-vp8-safe-and-royalty-free.html
[11:28:06] <KotH> --
[11:28:08] <KotH> Google's refusal to indemnify (let alone to hold harmless) calls into question that Google is really certain that there's no potential problem with patents
[11:28:11] <KotH> --
[11:28:44] * KotH wonders how anyone can have such a twisted logic
[11:29:38] <elenril> >certain >patents
[11:30:10] <KotH> even if it wouldnt be about patents
[11:30:38] <KotH> because they do not A, it means B, where as A and B have no connection what so ever
[11:42:53] <lu_zero> ^^
[12:14:29] <Evgeny> hi. how to use random mechanism in ffmpeg? thanks
[12:26:59] <jai> random mechanism?
[12:27:06] <jai> do you mean the prng?
[12:27:15] <jai> Evgeny: ^
[12:28:07] <janneg> KotH: posters are here
[12:30:36] <lu_zero> mru: ping
[12:31:13] <mru> pong
[12:31:26] <lu_zero> regarding libvpx build system
[12:32:24] <lu_zero> I'm tempted to start factor some components of ffmpeg's configure so they could be properly shared across project that might like to use it
[12:32:55] <lu_zero> are you against, strongly against or you'd kill me if I try that?
[12:32:58] <lu_zero> ^^
[12:33:06] <mru> I don't have time to review it now
[12:33:57] <lu_zero> it would take some time for me as well, just wanted to know if you think could be useful or you'd hate it
[12:34:46] <mru> there are some things I'd like to do first
[12:34:54] <mru> but I simply don't have time for that right now
[12:35:10] <lu_zero> I see =|
[12:37:55] <Evgeny> <@jal> i mean that i need something like rand() function.
[12:38:37] <Evgeny> now i use av_lfg_init - its send me the same values
[12:38:42] <Evgeny> in every start
[12:51:39] <iive> mru: would you be so kind to add mmst protocol as depending on network?
[12:52:21] <mru> patches welcome
[12:52:36] <iive> it's one line, and i can commit it myself.
[12:53:11] <mru> not until you post a patch
[12:53:57] <iive> you are mainteiner. maintin it yourself.
[12:54:28] <mru> I am maintainer, I approve patches
[12:55:21] <kshishkov> i.e. too lazy to do it by yourself and not too lazy to give control to somebody else
[12:56:33] <Compn> heh
[12:56:45] <Compn> it would be funny if only it werent so pathetic ;\
[13:03:38] <CIA-93> ffmpeg: mru * r23310 /trunk/configure: mmst_protocol depends on network
[13:09:21] <iive> you should have waited for the patch... i suspect that t in mmst  stands for tcp, and that makes it depend on tcp_protocol.... sorry
[13:09:46] <mru> you're never happy, are you
[13:13:00] <Evgeny> i mean av_lfg_get
[13:13:13] <Evgeny> FFMPEG doesn't let me use rand function
[13:13:24] <Evgeny> and forces to use this one
[13:13:32] <Evgeny> but it returns same value every time
[13:13:53] <kshishkov> iive: I think all those network protocols depend on TCP or UDP
[13:14:15] <kshishkov> and mmsT may stand for "tunneling" i.e. with HTTP if you meant that
[13:14:54] <lu_zero> Evgeny: there isn't something to seed it?
[13:15:07] <Evgeny> @lu_zero: i can use time
[13:15:17] <Evgeny> but even then multithreaded
[13:15:28] <kshishkov> or av_get_random_seed()
[13:15:30] <iive> the mail thread says " [patch]MMS protocol over TCP"
[13:15:41] <Evgeny> has a chance of causing same result
[13:16:10] <lu_zero> av_lfg_init(&random_state, av_get_random_seed());
[13:16:25] <kshishkov> same story with _any_ random number - if you don't specify different seed on init you won't get different random number sequences
[13:16:27] <iive> no, i'm wrong.
[13:16:41] <iive> it selects, tcp... not depending on it.
[13:17:06] <kshishkov> why should it?
[13:17:23] <kshishkov> it should use url_open() and it will fail if protocol is not enabled
[13:18:19] <Evgeny> @lu_zero: any idea which header this defined?
[13:18:35] <iive> i'm talking about configure and enabling stuff for compilation.
[13:19:07] <Evgeny> it's actually called now ff_random_get_seed()
[13:19:40] <Evgeny> thanks anyway! :)
[13:19:43] <wbs> no, actually it's called av_get_random_seed()
[13:19:55] <Evgeny> @wbs: I have last week svn
[13:20:06] <Evgeny> and I don't see there anywhere av_get_random_seed()
[13:20:08] <wbs> Evgeny: yes, and it was changed two days ago
[13:20:31] <kshishkov> ff_ version is still there until next major version change though
[13:20:46] <Evgeny> heh :)
[13:21:02] <wbs> yes, but the prototype is removed from the headers, so you shouldn't be using it for now code, only for binary compatibility with old libraries
[13:22:00] * lu_zero is pondering about playing with the network protocols today
[13:22:21] <wbs> lu_zero: do you think the Content-Base patch for ffserver is ok?
[13:22:31] * kshishkov tells lu_zero it's feasible and even works on YouTube
[13:24:00] <lu_zero> kshishkov: what's feasible?
[13:24:08] <lu_zero> wbs: seems correct
[13:24:18] <wbs> lu_zero: great, thanks
[13:24:24] <lu_zero> hi BBB___
[13:26:12] <kshishkov> lu_zero: playing with network protocols, of course. There are some players supporting RTP and such
[13:26:29] <lu_zero> kshishkov: I was thinking about adding dccp and sctp
[13:27:23] <BBB> better
[13:27:59] <kshishkov> lu_zero: dccp is for playing anime straight from IRC bots, right?
[13:28:37] <Evgeny> another question
[13:28:48] <Evgeny> is there any utlity to get random string built-in in ffmpeg?
[13:28:58] <kshishkov> nope, why?
[13:29:07] <lu_zero> kshishkov: nope =)
[13:29:21] <Evgeny> @kshishkov: wondered if i need to write of my own, or there is something ready
[13:29:23] <merbzt> http://www.geeks3d.com/public/jegx/200808/keyboard-for-real-coder.jpg
[13:29:23] <lu_zero> sctp and dccp are some relatively new protocols like tcp and udp
[13:29:50] <wbs> lu_zero: which means in practice the whole internet will drop such packets? ;-)
[13:30:02] <wbs> or do they run on top of udp?
[13:30:11] <lu_zero> wbs: so far feng serves through sctp w/out any issue
[13:30:14] <lu_zero> they are on top ip
[13:30:22] <wbs> ok
[13:30:40] <kshishkov> merbzt: laaaame, you know that programs should be input with flips, not keyboards
[13:30:44] <wbs> at least some ipv6-in-ipv4-tunnels may be dropped in some situations, depending on how paranoid the routers are
[13:31:26] <lu_zero> in that case rtp-rtsp-http-tcp-ip totem could do
[13:31:27] <lu_zero> =P
[13:31:43] <wbs> :-)
[13:32:01] <lu_zero> and that reminds that another proto we need is tls
[13:32:06] <lu_zero> reminds me
[13:32:25] <kshishkov> what we are missing?
[13:32:38] <lu_zero> kshishkov: for what?
[13:32:43] <kshishkov> for TLS
[13:32:47] <lu_zero> uhmm
[13:32:58] <lu_zero> using the bits we already have?
[13:33:08] <kshishkov> of course! I sthere any other way?
[13:33:12] <kshishkov> *Is there
[13:33:38] <lu_zero> kshishkov: if you are willing to do this way...
[13:33:54] <kshishkov> no, but I may provide some missing bits
[13:35:41] * lu_zero should have a look on the tls spec
[13:35:56] <lu_zero> I'd rather use openssl and be lazy
[13:36:41] <lu_zero> x509 is too boring
[13:36:43] * kshishkov would rather have fftls and tie rtmpdump closer to lav
[13:36:51] <kshishkov> tell that to KotH
[13:36:53] <lu_zero> kshishkov: I see ^^;
[13:37:25] <hyc> how many times does that wheel need to be reinvented?
[13:37:35] <hyc> polarssl is pretty good too
[13:37:54] <hyc> compact, no kitchen sink features
[13:38:21] <kshishkov> hyc: you haven't seen that BC comic about inventing wheels, have you?
[13:38:31] <lu_zero> http://www.ietf.org/rfc/rfc2246.txt
[13:38:47] <pJok> kshishkov, ffOS?
[13:38:51] <lu_zero> hyc: why polarssl and not gnutls or openssl?
[13:38:57] <kshishkov> pJok: on ffCPU
[13:39:19] <kshishkov> lu_zero: because other implementations use rectangular coordinates
[13:39:30] <hyc> lu_zero: I like OpenSSL too, of course. I've written a few bits of it. But it's large, and sometimes a pain to port to embedded machines.
[13:39:53] <hyc> I've also written a few bits of gnutls, but only under duress. gnutls is quite poor quality code.
[13:39:54] <lu_zero> kshishkov: you got flameeyes to bite you somehow?
[13:40:10] <hyc> polarssl is very small, written specifically for embedded systems
[13:40:10] <lu_zero> hyc: so you'd like to have a smaller ssl implementation
[13:40:13] <kshishkov> lu_zero: not at all, why?
[13:40:20] <lu_zero> polarssl is gpl2
[13:40:31] <lu_zero> kshishkov: same kind of humor
[13:40:36] <lu_zero> http://www.polarssl.org/source_code that is useful
[13:40:58] <hyc> librtmp supports all 3 of those anyway
[13:41:01] <kshishkov> lu_zero: I mostly specialize on dark humour
[13:41:11] <hyc> but I'm now using polarssl exclusively for my Windows builds of rtmpdump
[13:43:15] <lu_zero> kshishkov: the polarssl page has a nice breakup of the various components
[13:43:28] <kshishkov> Windows. Small embedded systems. Hmm, makes sense
[13:43:35] <lu_zero> brb
[13:43:51] <hyc> kshishkov: it was expedient. rtmpdump is gpl, polarssl is gpl.
[13:43:55] <BBB> wbs: ffserver patch seems ok to me, wait for baptiste to ok it
[13:44:04] <hyc> it would be a licensing problem for me to ship rtmpdump+openssl
[13:44:15] <hyc> gnutls is gpl too of course, but it sucks
[13:44:39] <wbs> hyc: isn't gnutls lgpl?
[13:44:44] <hyc> whatever
[13:44:52] <hyc> either way, I would never use it voluntarily
[13:45:09] <wbs> in commercial setups, the difference between lgpl and gpl is quite important ;P
[13:45:25] <wbs> BBB: yeah, I'll wait and see if he has anything to say on it
[13:45:41] <Compn> ugh openssl license ;\
[13:46:15] * Compn reminds himself to not make static builds in the future
[13:48:56] <hyc> wbs: I recognize that commercial environments frown on GPL. most of the people doing the frowning are dumbasses.
[13:49:42] <BBB> what country is that?
[13:49:50] <BBB> nowadays many corporate environments do use gpl
[13:49:53] <BBB> I see it all around me
[13:50:02] <BBB> and I'm not even consulting
[13:50:11] <BBB> (US)
[13:50:14] <wbs> hyc: it isn't about frowning on it, but you can't ship binaries linking in such code
[13:50:31] <wbs> unless you gpl the whole thing of course
[13:50:37] <hyc> wbs: of course you can. you simply have to make it clear to customers that source code is available.
[13:51:11] <wbs> hyc: yes, code to the whole application, not just the originally gpl part
[13:51:11] <Tjoppen> unless you have to deal with proprietary libraries at the same time
[13:51:19] <hyc> and IMO, GPL'ing the whole thing is the correcy thing to do.
[13:51:42] <hyc> if you're getting benefit from my GPL code, then you owe some reciprocation
[13:53:14] <hyc> more to the point, you owe society in general...
[13:53:56] <hyc> proprietary libraries == theft, theft from the public domain, etc...
[13:54:10] <wbs> yes, and in the cases where that's not an option, commercial entities tend to stay away from gpl
[13:54:33] <hyc> everybody who ever created some proprietary IP was educated with the benefit of the public domain
[13:54:50] <wbs> and I have no problem giving back the actual changes done to the original library, as with lgpl
[13:55:20] <hyc> for them to turn around and ransom their creations back to society is just piracy
[13:56:04] <kshishkov> hyc: some of proprietary libraries != theft, that's just act of mercy. Look at original VP3 code
[13:56:12] <hyc> lol
[13:57:03] <hyc> kshishkov: we learn even more from mistakes than from successes. even crap code should be open to scrutiny. moreso.
[13:58:32] <lu_zero> eh eh
[14:00:04] <Tjoppen> if you're in a position to impose such things on the companies providing proprietary libraries to you that would be. that isn't usually the case though
[14:00:15] <Tjoppen> *be nice
[14:00:56] <hyc> Tjoppen: well, the thing to do is to make the proprietary code irrelevant
[14:01:10] <hyc> write a a better library and open source it
[14:01:33] <Tjoppen> yeah, the customer isn't going to pay for that
[14:01:44] <Tjoppen> sadly
[14:01:56] <hyc> if that's the only factor that drives your business decisions, you have problems.
[14:02:25] <hyc> No customer would have ever paid for the thousands of hours we spent refactoring OpenLDAP between 2000-2003.
[14:02:48] <hyc> but the fact is the code base is now the fastest in the world, and we have customers migrating to us all the time now.
[14:03:49] <hyc> 2 years ago Microsoft AD had 85% of the directory market, OpenLDAP had 10%. Today M$ has 70%, OpenLDAP has 22%.
[14:04:29] <Tjoppen> OpenLDAP isn't GPL though, unless I'm mistaken
[14:04:44] <hyc> you have to make a decision "we're going to fix this code because it's the right thing to do" regardless of whether any current customers ask for it.
[14:05:31] <hyc> No, it's OpenLDAP License, BSD-derivative
[14:05:31] <Tjoppen> eventually it'll probably come to developing libraries of one's own
[14:05:46] <Tjoppen> either to get around the proprietary libs, or the gpl ones
[14:06:38] <hyc> Still the point remains - create in the open, and make the closed stuff irrelevant
[14:07:20] <Tjoppen> sure, but what are you going to do until the free library is good enough to replace the old one?
[14:07:34] <hyc> suffer for a while I guess.
[14:07:36] <Tjoppen> code I guess :o
[14:07:38] <hyc> we had no choice...
[14:07:41] <hyc> exactly
[14:08:46] <hyc> there's no instant gratification, everything takes work
[14:09:34] <hyc> rtmpdump is the same way. Adobe has locked-down platforms. until we put in sufficient time to decipher all of the locks, we're dead in the water.
[14:10:09] <hyc> but eventually it all unfolds, and now rtmpdump provides all the functionality on any platform, while Adobe still has only their handful of supported systems
[14:12:21] <hyc> and in comparison, the free solution now uses 100x less CPU than Adobe's...
[14:13:40] <hyc> seems like the only benefit of proprietary code is to hide poor craftmanship
[14:14:04] <kshishkov> that's what I've said
[14:24:42] <CIA-93> ffmpeg: michael * r23311 /trunk/libavcodec/golomb.c:
[14:24:42] <CIA-93> ffmpeg: Correct golomb vlc decoding tables.
[14:24:42] <CIA-93> ffmpeg: Fixes issue 1930
[14:25:44] <kierank> yay
[14:34:13] <BBB> lu_zero: thanks for the email
[14:35:00] <lu_zero> BBB: I wrote about it long ago in the private ml but had no replies ^^;
[14:35:10] <BBB> I probably forgot to read it
[14:38:48] <hyc> I'm guessing that a patch to make av_parser_init() take an AVCodecContext instead of a codec_id won't fly
[14:38:50] <hyc>  ?
[14:41:30] <BBB> you could add a av_parser_init2()
[14:41:39] <BBB> if there's a good reason
[14:42:08] <hyc> the actual parsers' init functions would also need to change, to make it worth the effort
[14:42:22] <hyc> instead of just parser_init(AVCodecParserContext)
[14:42:34] <hyc> would also want to pass the AVCodecContext there
[14:43:20] <hyc> seems like there are quite a few parsers...
[14:44:01] <hyc> and apparently aside from h264, none of them need this, otherwise this API would have been changed before now
[14:44:09] <hyc> hmm...
[14:45:17] <hyc> I dunno. it seems like the most obvious fix to me but maybe someone else will have a better idea
[14:48:20] <BBB> is this b/c of the extradaat?
[14:48:26] <hyc> right
[14:48:36] <BBB> I mean, I'm not against it but I'm not a maintainer of that code either so I can't help you much ;)
[14:49:05] <BBB> submit a patch
[14:49:13] <BBB> I think it's ok, just don't change any existing symbols
[14:49:20] <hyc> it would be a big patch, to update all the existing parsers
[14:49:21] <BBB> add new symbols instead, so API/ABI doesn't change incompatibly
[14:49:27] <BBB> why update all of them?
[14:49:33] <BBB> parser_init() wouldn't change
[14:49:38] <BBB> you'd add a parser_init2()
[14:49:42] <hyc> oh
[14:49:45] <BBB> and update h264parse accordingly
[14:49:47] <hyc> hmmm
[14:49:48] <BBB> otherwise it's an ABI change
[14:49:57] <hyc> ok
[14:50:02] <BBB> and add a fallback that aclls parse_init() if init2() is NULL
[14:50:11] <hyc> right
[14:50:20] <BBB> and av_parse_init() should call av_parse_init2(bla, NULL) or so
[14:50:24] <BBB> you know what I mean :)
[14:50:29] <hyc> right
[14:50:48] <hyc> well, I need to look at it some more, see if this can be fixed without any new APIs
[14:50:49] <BBB> don't forget to deprecate av_parse_init()
[14:50:54] <BBB> ok
[14:51:24] <hyc> deprecate it? I'll insult it and its mother. :P
[14:51:47] <BBB> woohoo
[15:01:04] <Tjoppen> BBB: did you see my simple web server thing on the ML? should suffice to test the patch
[15:01:18] <BBB> yes
[15:01:22] <BBB> I should look at it :)
[15:01:26] <BBB> keep kicking me
[15:01:29] <Tjoppen> :)
[15:01:30] <BBB> I'll do it eventually, really
[15:01:38] * BBB puts on todo list
[15:02:37] <Tjoppen> ok. back to wrestling SMPTE 12M timecodes
[15:03:21] <Tjoppen> I've managed to parse their 8-byte representation into useful sequential AVRational-ish time codes
[15:03:41] <Tjoppen> accounting for drop frames and the like. it's magic
[15:04:19] <_av500_> drop frames
[15:04:22] <_av500_> nice
[15:04:29] <kierank> eugh drop frames
[15:04:53] <_av500_> wasnt there an epic discussion about that some while ago?
[15:05:32] <Tjoppen> they're an abomination. in fact, NTSC is an abomination
[15:05:46] <Tjoppen> </work>
[15:06:19] <Tjoppen> <pizza_buffet_and_beer>
[15:08:56] <BBB> want_pizza1
[15:14:38] <lu_zero> BBB: should I send it through dcc?
[15:16:40] <BBB> sure
[15:16:49] <BBB> homemade?
[15:17:24] <lu_zero> anybody knows a sane and fast way to know how many fd are allocated from within  program?
[15:17:45] <lu_zero> (opening /proc/self/fd or similar isn't that good)
[15:18:14] <lu_zero> BBB: I know how to make that but there are way better source for pizza
[15:18:45] <lu_zero> (btw a multimedia conference in italy would be interesting to organize)
[15:19:12] <wbs> lu_zero: don't know if it's easily accessible from within the program; if you look at the number of the latest opened socket, you might get a clue, but once you start closing old ones, it won't help you
[15:19:27] <lu_zero> that is the annoying part ^^;
[15:19:34] <jai> lu_zero: of course :)
[15:20:15] <_av500_> lu_zero: with spaghetti code sessions?
[15:20:19] * _av500_ hides
[15:20:25] <wbs> doh
[15:20:29] <lu_zero> tortellini code sessions
[15:20:45] <lu_zero> we do OOP in ffmpeg =P
[15:21:01] <jai> i can finally get that monica bellucci autograph i wanted...
[15:21:21] <lu_zero> (the filling is obviously inline assembly)
[15:40:25] <CIA-93> ffmpeg: rbultje * r23312 /trunk/libavformat/rmdec.c:
[15:40:25] <CIA-93> ffmpeg: We're using generic tag-to-ID functions, so specific codec_id assignments
[15:40:25] <CIA-93> ffmpeg: are no longer necessary. Patch by Zhou Zongyi <zhouzy AT os pku edu cn>.
[17:03:03] <hyc> well if it's any consolation, totem SEGVs for me on the mkv in issue 1831
[17:03:42] <hyc> the OP said totem worked and vlc/mplayer crashed
[17:05:16] <kshishkov> totem worked? on anything? he's lying!
[17:05:39] <hyc> lol
[17:07:21] * Compn wishes xine/vlc/mplayer would share more samples n bugreports
[17:10:00] <bilboed-pi> hyc, totem using gstreamer git works fine though
[17:10:16] <bilboed-pi> fine => no video
[17:20:54] <hyc> going to feed it into the reference decoder and see what it says
[17:34:18] * peloverde seems to have broken his git-svn setup and can't seem to reclone
[17:42:00] <peloverde> Is there some sort of git-am for svn?
[17:58:11] <kierank> is there going to be a 0.5.2 announcement on ffmpeg.org?
[18:02:11] <siretart> kierank: there is already?
[18:02:26] <siretart> kierank: first point in the NEWS section
[18:02:59] <kierank> hmmm seems there's something caching it
[18:03:03] <kierank> it's appeared now
[18:21:53] <CIA-93> ffmpeg: siretart * r23313 /branches/ (5 files in 4 dirs):
[18:21:53] <CIA-93> ffmpeg: matroskadec: Support webm doctype
[18:21:53] <CIA-93> ffmpeg: Patch by James Zern <jzern at google>
[18:21:53] <CIA-93> ffmpeg: backport r23245 by conrad
[18:22:51] <CIA-93> ffmpeg: siretart * r23314 /branches/ (0.6 0.6/libavformat/matroskadec.c):
[18:22:51] <CIA-93> ffmpeg: matroskadec: Allow unknown EBML doctype
[18:22:51] <CIA-93> ffmpeg: backport r23246 by conrad
[18:23:29] <CIA-93> ffmpeg: siretart * r23315 /branches/ (0.6/libavformat/matroskaenc.c 0.6):
[18:23:29] <CIA-93> ffmpeg: matroskaenc: Don't write track timecode scale
[18:23:29] <CIA-93> ffmpeg: It's not required for mkv and unsupported in webm
[18:23:29] <CIA-93> ffmpeg: backport r23247 by conrad
[18:25:05] <CIA-93> ffmpeg: alexc * r23316 /trunk/libavcodec/aaccoder.c: aacenc: Factor out find_min_book so it can be used by multiple coefficient coders.
[18:29:06] <CIA-93> ffmpeg: alexc * r23317 /trunk/libavcodec/aaccoder.c:
[18:29:06] <CIA-93> ffmpeg: aacenc: Only trellis over a column of 61 scalefactors (reduced from 256).
[18:29:06] <CIA-93> ffmpeg: This still provides plenty of dynamic range, makes every move legal, and greatly reduces the search space.
[18:32:47] <CIA-93> ffmpeg: alexc * r23318 /trunk/libavcodec/aaccoder.c:
[18:32:47] <CIA-93> ffmpeg: aacenc: Trellis over scalefactors using an estimated codebook rather than every codebook.
[18:32:47] <CIA-93> ffmpeg: The minimal codebook to encode the band without clipping is used (as is done in the TLS).
[18:33:31] <saintdev> :O
[18:33:50] <CIA-93> ffmpeg: alexc * r23319 /trunk/libavcodec/aaccoder.c: Remove useless costly inf checks from the trellis scalefactor search.
[18:34:29] <CIA-93> ffmpeg: siretart * r23320 /branches/ (6 files in 4 dirs):
[18:34:29] <CIA-93> ffmpeg: Update regression tests after removing track timecode scale from mkvenc
[18:34:29] <CIA-93> ffmpeg: backport r23248 by conrad
[18:35:11] <CIA-93> ffmpeg: siretart * r23321 /branches/ (0.6 0.6/libavcodec/avcodec.h):
[18:35:11] <CIA-93> ffmpeg: Document CODEC_FLAG_EMU_EDGE and avcodec_align_dimensions interaction.
[18:35:11] <CIA-93> ffmpeg: backport r23258 by reimar
[18:35:53] <CIA-93> ffmpeg: alexc * r23322 /trunk/libavcodec/aaccoder.c: aacenc: Split find_max_val() from find_min_book() to eliminate duplicate searches.
[18:38:00] <saintdev> \o/ less sucky aacenc
[18:38:28] <peloverde> Actually that is all improvement to code that is turned off
[18:38:50] <peloverde> but it does makes the trellis search operate at a usable speed
[18:46:00] <janneg> bcoudurier: hi
[18:46:19] <saintdev> reverse onjoin, haha
[18:46:37] <bcoudurier> hi
[18:47:43] <janneg> bcoudurier: you've pinged me yesterday
[18:55:27] <bcoudurier> indeed, but I can't remember why now
[18:56:45] <janneg> maybe experimental decoders/encoders?
[19:01:00] <Tjoppen> hm. I wonder if I could convince my employer and our client to let me go to that convention coming up
[19:09:47] <_av500_> tattoo convention?
[19:12:24] <Tjoppen> no?
[19:14:18] <CIA-93> ffmpeg: mstorsjo * r23323 /trunk/libavcodec/api-example.c:
[19:14:18] <CIA-93> ffmpeg: api-example: Try to avoid decoding incomplete frames
[19:14:18] <CIA-93> ffmpeg: Use a larger input audio buffer, refill it when it has less than 4 KB data
[19:14:18] <CIA-93> ffmpeg: left.
[19:17:06] <CIA-93> ffmpeg: mstorsjo * r23324 /trunk/libavcodec/api-example.c: Cosmetics: reindent after the previous commit
[19:18:21] <wbs> bcoudurier: ok to add the Content-Base header in RTSP replies from ffserver? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100525/5fb50d9a/attachment.patch
[19:21:40] <bcoudurier> yes
[19:23:50] <wbs> thanks
[19:24:09] <CIA-93> ffmpeg: mstorsjo * r23325 /trunk/ffserver.c:
[19:24:09] <CIA-93> ffmpeg: ffserver: Send a Content-Base header in the reply to RTSP DESCRIBE requests
[19:24:09] <CIA-93> ffmpeg: This is needed for QuickTime Player to be able to connect properly.
[19:24:42] <hyc> wbs: hmm, bypassing that initial av_seek_frame() in ffserver also seems to work, without the libavformat/utils.c patch
[19:25:24] <hyc> if (stream_pos && c->fmt_in->iformat->read_seek)
[19:25:24] <wbs> hyc: hmm, interesting
[19:25:49] <hyc> of course, I don't know what that does if we actually provide a seek position
[20:43:42] <twnqx> uau: what was necessary again to get -af lavcac3enc? :X
[20:46:39] <spaam> uau is not here twnqx ;)
[20:48:26] <twnqx> that doesn't solve my problem
[20:48:40] <spaam> )
[20:56:56] <CIA-93> ffmpeg: siretart * r23326 /branches/ (0.6 0.6/ffplay.c):
[20:56:56] <CIA-93> ffmpeg: FFplay : Avoid manipulating NULL data pointers so that future checks
[20:56:56] <CIA-93> ffmpeg: remain valid. This fixes segfaults for those cases where data copy to
[20:56:56] <CIA-93> ffmpeg: this invalid pointer is attempted.
[20:56:56] <CIA-93> ffmpeg: backport r23264 by jai_menon
[20:57:33] <CIA-93> ffmpeg: siretart * r23327 /branches/ (0.6 0.6/ffplay.c):
[20:57:33] <CIA-93> ffmpeg: Cosmetics : re-indent after last commit.
[20:57:33] <CIA-93> ffmpeg: backport r23265 by jai_menon
[21:00:52] <merbanan> siretart: can you backport my aea demuxer patches ?
[21:03:01] <siretart> merbanan: that's r23272 & r23273, right?
[21:03:07] <merbanan> yes
[21:03:19] <siretart> already scheduled
[21:08:18] <merbanan> tnx
[21:22:46] <spaam> dylanza: hard to chose? stay or not to stay? ;)
[21:23:04] <_av500_> stay
[21:23:12] <_av500_> no, dont
[21:23:37] <BBB> so google chrome uses ffmpeg for html5 right?
[21:23:44] <thresh> yes
[21:23:47] <dylanza> ah, sorry - was cleaning quassel logs. it doesnt make it easy
[21:23:58] <BBB> awesome, I'm actually using ffmpeg now :-p
[21:24:25] <spaam> BBB: didnt you use ffmpeg before? :P
[21:24:46] <BBB> well, I use it, but it's fun to know that the software you use everyday uses it also
[21:24:47] <mru> everybody uses ffmpeg
[21:25:15] <BBB> unfortunately, it doesn't do vp8
[21:25:21] <spaam> BBB: never heard of vlc? :P
[21:25:41] <BBB> vlc is a media player, it requires media
[21:25:46] <BBB> I hardly watch videos except for youtube
[21:25:53] <BBB> I watch dvds on my dvd player from sony
[21:26:02] <BBB> and itunes doesn't use ffmpeg :(
[21:26:26] <wbs> BBB: with perian, I guess you can get itunes to use ffmpeg ;P
[21:26:44] <mru> BBB: youtube uses ffmpeg
[21:26:50] <BBB> that's true
[21:28:08] <Yuvi> interesting, -Werror=missing-prototypes doesn't seem to be included in -Wall -Werror
[21:28:38] <mru> probably because -Wall doesn't include it
[21:29:24] <Yuvi> yeah, just strange because if it was, this broken system header probably would've been found sooner
[21:29:36] <mru> which system?
[21:29:43] <Yuvi> emmintrin.h on apple gcc 4.2
[21:30:07] <mru> why would you want to use that?
[21:30:12] <Yuvi> I don't
[21:30:31] <Yuvi> but including most any of apple's frameworks winds up including it
[21:30:38] <DonDiego> Yuvi: wanna fix that theora crash? ;)
[21:30:47] <Yuvi> DonDiego: do you have symbols?
[21:30:56] <DonDiego> let me fire up my desktop and try with ffplay_g..
[21:31:03] <DonDiego> give me 5 mins
[21:31:26] <mru> so don't use apple's frameworks
[21:42:27] <BBB> Yuvi: I haven't much looked at vp8 so far, and you've been very active in it, could I be helpful at all there?
[21:43:03] <mru> we need a native decoder
[21:43:09] <Dark_Shikari> just take vp6 and rewrite a few things
[21:45:09] <mru> vp5678.c?
[21:45:35] <Dark_Shikari> lol
[21:45:58] <hyc> vpn.c :P
[21:46:08] <hyc> but then people will mistake it for networking...
[21:47:11] <Dark_Shikari> vpx.c
[21:47:12] <Dark_Shikari> ;)
[21:48:51] <saintdev> gah, beat me to it
[21:49:25] <_av500_> on2/google beast you all to it
[21:49:31] <_av500_> lol beat
[21:52:18] <CIA-93> ffmpeg: michael * r23328 /trunk/libavcodec/h264_ps.c:
[21:52:19] <CIA-93> ffmpeg: Check for VUI overeading and reset num_reoder_frames.
[21:52:19] <CIA-93> ffmpeg: This helps the video from issue1831
[21:53:02] <DonDiego> mru:  what's the best way to disable the vorbis encoder, but allow it to be enabled explicitly in configure?
[21:53:16] <DonDiego> i don' t see an obvious way
[21:53:46] <BBB> CONFIG_EXPERIMENTAL?
[21:53:47] <DonDiego> i can place a 'disable vorbis_encoder' in the right spot, but then there will be no possibility to override it
[21:54:01] <mru> that's hackish
[21:54:04] <Dark_Shikari> why not make it like snow
[21:54:06] <Dark_Shikari> require -vstrict -2
[21:54:08] <DonDiego> BBB: that's on trunk..
[21:54:26] <mru> vorbis_encoder_deps=experimental would do it
[21:54:36] <mru> and add experimental to CONFIG_LIST
[21:54:46] <DonDiego> but that's only on trunk, right?
[21:55:05] <mru> that's CODEC_CAP_EXPERIMENTAL
[21:55:12] <mru> and that's probably enough
[21:55:17] <mru> no need to disable in configure
[21:55:44] <DonDiego> is that available on the 0.6 branch or is that janneg's recent code?
[21:56:29] <mru> it hasn't been committed yet afaik
[21:57:41] <DonDiego> hrmpf
[21:59:29] <DonDiego> i need something quick and dirty that works on the branch :)
[22:00:24] <DonDiego> i promised the xiph folks to disable the vorbis encoder (by default) and it does make sense to do so..
[22:02:27] <mru> ping janneg's patch first
[22:02:35] <mru> if no response by tomorrow we'll think of something
[22:03:24] <janneg> DonDiego: the right spot for "disable vorbis_encoder" would be immediately after "enable $ARCH_EXT_LIST"
[22:03:38] <DonDiego> janneg: i found that place already :)
[22:03:58] <DonDiego> although, admittedly, my knowledge of configure is getting a little rusty..
[22:04:22] <DonDiego> janneg: ping your patch please, say that i want it for 0.6..
[22:04:59] <DonDiego> Yuvi: you have mail, i redid the valgrind trace with ffplay_g (although this is the older system valgrind version)
[22:05:00] <janneg> DonDiego: my patch doesn't help against ffmpeg -acodec vorbis
[22:05:27] <DonDiego> hmm
[22:05:43] <DonDiego> then we need something else i guess
[22:08:59] <bcoudurier> I agree
[22:09:09] <bcoudurier> I'd say do on trunk as well
[22:09:17] <bcoudurier> disable vorbis encoder in configure by default
[22:09:18] <mru> disabling it still won't make -acodec vorbis do the right thing
[22:09:30] <bcoudurier> no, but people cannot do -acodec vorbis _at all_
[22:09:46] <bcoudurier> so they will search for methos
[22:09:49] <bcoudurier> methods
[22:10:06] <mru> janneg: could your patch be extended to refuse the experimental codecs unless some extra flag is provided?
[22:10:10] <bcoudurier> and hopefully find -acodec libvorbis
[22:10:21] <bcoudurier> and we also could print a warning
[22:10:39] <bcoudurier> "you typed vorbis, you might want to use libvorbis instead"
[22:10:54] <DonDiego> something should indeed happen on that front
[22:11:17] <DonDiego> however, if we cannot make up our minds what...
[22:11:28] <peloverde> who is maintainer?
[22:11:32] <DonDiego> maybe svn rm vorbisenc.c :)
[22:11:42] <mru> I suggested that years ago
[22:11:52] <DonDiego> peloverde: nobody, that's why the code is so crappy..
[22:12:05] <peloverde> who committed it?
[22:12:09] <bcoudurier> oded did
[22:12:25] <bcoudurier> well we also have aac encoder ;)
[22:12:45] <DonDiego> but the aac encoder is moving forward - slowly, but moving
[22:12:56] <DonDiego> the vorbis encoder is moving nowhere slow
[22:12:58] <bcoudurier> well we should stay modest on this one
[22:13:17] <bcoudurier> and avoid doing 2 weights 2 measures
[22:13:42] <DonDiego> ?
[22:13:48] <DonDiego> was that french?
[22:13:50] <DonDiego> :)
[22:13:52] <bcoudurier> yes
[22:13:53] <bcoudurier> :)
[22:14:03] <DonDiego> translation please :)
[22:14:04] <bcoudurier> doing the idomatic corresponding hehe
[22:14:06] <bcoudurier> dunno
[22:14:11] <bcoudurier> idiomatic
[22:14:16] <bcoudurier> I sucks :(
[22:14:17] <peloverde> AVCodec.name to "ffvorbis" will that work?
[22:14:34] <bcoudurier> anyway, aac encoder will also be tagged as "experimental"
[22:14:50] <bcoudurier> I'd say just disable by default the vorbis encoder
[22:15:23] <bcoudurier> then if you want to easily workaround, just translate "vorbis" to "libvorbis"
[22:15:41] <bcoudurier> in opt_codec_name or something
[22:15:47] <janneg> bcoudurier: patch for encoders only sent
[22:15:49] <bcoudurier> hackish but simple
[22:16:18] <DonDiego> i think a plain
[22:16:24] <DonDiego> disable vorbis_encoder
[22:16:33] <DonDiego> in configure will be the best solution for the branch
[22:16:53] <bcoudurier> janneg, did you send the smae patch ? :>
[22:17:01] <bcoudurier> in trunk as well
[22:17:03] <DonDiego> that encoder should *not* be used in production
[22:17:19] <DonDiego> if you want to do development on it, trunk is the right place anyway
[22:17:28] <bcoudurier> but like mru said, it won't make "-acodec vorbis" use libvorbis
[22:17:29] <DonDiego> mru: any quick alternative solutions?
[22:17:32] <janneg> mru: not easily, avcodec_find_encoder only has a codec id as parameter
[22:17:43] <DonDiego> bcoudurier: -acodec vorbis will fail
[22:17:48] <bcoudurier> yes
[22:17:51] <DonDiego> and people will have to learn about libvorbis
[22:17:53] <bcoudurier> that's what I said
[22:17:57] <DonDiego> ah, ok :)
[22:18:16] <bcoudurier> mru, are you ok with this ?
[22:18:18] <DonDiego> you're as smart as me then
[22:18:23] <DonDiego> only - quicker..
[22:18:24] <DonDiego> :)
[22:18:24] <bcoudurier> lol
[22:18:27] <mru> ok with what?
[22:18:34] <bcoudurier> disable vorbis by default
[22:18:45] <mru> depends on how it's done
[22:18:45] <bcoudurier> on trunk and on the branch
[22:18:49] <bcoudurier> in configure
[22:18:53] <mru> depends on how it's done
[22:19:12] <janneg> I have patch for ffmpeg to fail if a codec is experimental and strict > -2
[22:19:19] <mru> that should do it
[22:19:41] <DonDiego> that sure is cleaner, but it's not yet available
[22:19:46] <DonDiego> i want something *now*
[22:19:49] <mru> what about the avcodec_find_{en,de}coder_by_name functions?
[22:20:02] <mru> DonDiego: you can wait one more day
[22:20:13] <DonDiego> i guess..
[22:20:20] <DonDiego> Yuvi: seen my mail?
[22:20:54] <bcoudurier> IMHO there is nothing to change in decode_by_name
[22:21:00] <mru> no, there's not
[22:21:03] <mru> of course not
[22:21:12] <mru> just make it fail w/o right -strict
[22:21:14] <mru> or whatever
[22:21:21] <bcoudurier> you'd have to pass -strict
[22:21:30] <bcoudurier> this is awkward
[22:21:40] <mru> janneg: will you send the patch?
[22:23:30] <bcoudurier> btw how the auto pthreads topic ended ?
[22:23:47] <mru> in a bikeshed
[22:23:56] <mru> I'll now lock the door and toss the key
[22:24:11] <bcoudurier> humm it seems that we all agreed to autodetect it, no ?
[22:24:48] <bcoudurier> last mail in the thread is 04/19 from you, and you said ok
[22:32:16] <DonDiego> please move that stuff forward finally
[22:32:25] <DonDiego> another idea for vorbis:
[22:32:41] <DonDiego> we could just disable the avcodec declaration in vorbisenc.c
[22:32:50] <DonDiego> then the code will still get compile-tested
[22:32:56] <DonDiego> but encoding will not work..
[22:36:09] <janneg> bcoudurier: yes, sorry forgot to commit
[22:36:24] <janneg> mru: of course, was distracted
[22:37:42] <DonDiego> so..
[22:37:52] <janneg> it compiles
[22:38:02] <DonDiego> shall i open a thread on -devel about the vorbis encoder?
[22:47:42] <BBB> DonDiego: yes
[22:47:46] <janneg> DonDiego, mru: patch sent
[22:54:29] <CIA-93> ffmpeg: cehoyos * r23329 /trunk/libavcodec/vorbis_enc.c:
[22:54:29] <CIA-93> ffmpeg: Do not invert samples when encoding Vorbis.
[22:54:29] <CIA-93> ffmpeg: Patch by Frank Barchard, fbarchard google
[22:56:03] <CIA-93> ffmpeg: aurel * r23330 /trunk/libavformat/matroskadec.c: matroskadec: avoid potential crash after r23169
[23:11:43] <mru> DonDiego: see r19149 and r19290
[23:15:10] <DonDiego> oh, i faintly remember that..
[23:15:29] <DonDiego> that would be an ok solution as well
[23:15:49] <DonDiego> but on the branch disabling in configure is better i think
[23:16:06] <mru> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/91490
[23:16:19] <mru> I find your reversal of opinion curious
[23:16:20] <DonDiego> otherwise configure lists it in the list of enabled encoders
[23:16:21] <mru> but welcome
[23:16:35] <DonDiego> umm, no, it will not
[23:17:10] <mru> full thread: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/90998
[23:17:30] <DonDiego> my comment there goes in a somewhat different direction
[23:19:20] <DonDiego> oh, ivan is active in that thread..
[23:19:37] <DonDiego> no wonder it did not produce the intended results ;)
[23:22:07] <mru> lol CODEC_CRAPABILITY
[23:26:17] <CIA-93> ffmpeg: alexc * r23331 /trunk/libavcodec/aaccoder.c: Fix declaration after statement
[23:27:44] <saintdev> aacenc is feeling so loved today
[23:29:13] <peloverde> That's more loving ancient compilers than aacenc
[23:29:39] <Dark_Shikari> s/ancient/microsoft
[23:30:08] <janneg> and gcc 2.95
[23:30:50] <mru> that reminds me, I need to file a bug for armcc
[23:31:52] <mru> it fails on some c99 stuff in gcc mode
[23:31:56] <peloverde> Did we ever come up with a good solution about multi-level const arrays? they choke out all other warnings for me
[23:32:09] <mru> ignore michael and fix the code?
[23:44:29] <peloverde> some of the other warnings gcc 2.95 spits out makes me wonder if aacenc works on 2.95 at all
[23:44:41] <mru> like?
[23:46:10] <peloverde> It seems to find void* aritmetic where there is none
[23:46:25] <mru> ?
[23:47:00] <DonDiego> Yuvi: ping
[23:47:12] <peloverde> aaccoder.c:346
[23:47:22] <peloverde> "memset(sce->zeroes + win*16 + start, !stackcb[i], count);"
[23:47:41] <peloverde> uint8_t zeroes[128];
[23:48:22] <peloverde> (win and start are both int)
[23:48:22] <mru> is memset a macro that expands to something interesting?
[23:48:40] <peloverde> I don't know, gcc-2.95 does not support my architecture
[23:49:00] <peloverde> and I don't have access to said fate machine
[23:49:01] <mru> I managed to shoehord a 2.95 build on my ppc machine
[23:49:10] <mru> *horn
[23:49:58] <peloverde> Can fate give me preprocessed source or anything else useful?
[23:50:19] <mru> note the /usr/include/bits/string2.h:454: warning: pointer of type `void *' used in arithmetic
[23:50:58] <DonDiego> mru: gcc 2.95 totally sucks on ppc..
[23:51:17] <peloverde> Looks like libc is broken?
[23:51:20] <mru> I didn't intend to actually use it
[23:51:30] <mru> gcc 2.95 totally sucks everywhere
[23:51:38] <Dark_Shikari> s/2.95//
[23:51:49] <mru> 4.3 sucks a hell of a lot less
[23:52:01] <mru> 4.4 sucks about 25% more than 4.3
[23:52:13] <mru> 4.5 about 25% less than 4.4
[23:52:37] <Dark_Shikari> lol
[23:54:08] <saintdev> hmm, odd number gcc theory?
[23:54:22] <mru> do the maths
[23:54:27] <mru> 4.5 is still worse than 4.3
[23:54:50] <saintdev> oh wait that's 4.4
[23:55:06] <saintdev> yeah, for some reason i read 4.3 for both :p
[23:55:06] <mru> 3.4 was ok though
[23:55:09] <mru> at the time
[23:55:13] <Dark_Shikari> 3.4 is still ok
[23:55:19] <mru> 4.3 is better
[23:55:21] <Dark_Shikari> it's still less buggy than 4.x a lot of the time
[23:55:27] <mru> different bugs
[23:55:29] <Dark_Shikari> True.
[23:55:37] <mru> old code probably avoids them