[FFmpeg-devel-irc] IRC log for 2011-02-15

[irc at mansr.com]

[00:02:42] <CIA-38> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r77c330a046 ffmpeg/doc/APIchanges:
[00:02:42] <CIA-38> ffmpeg: APIchanges: update for 12c14cd
[00:02:42] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:03:05] <mru> Sean_McG: ever used Alpha systems?
[00:03:29] <Sean_McG> only when I worked at a hospital... and it ran OpenVMS *shudder*
[00:03:59] <Sean_McG> replaced an aging VAX
[00:16:17] <Sean_McG> I'll always love POWER/PPC, but after Apple abandoned it obviously my exposure has been basically zero since I don't own an RS/6000 or System/p
[00:16:42] <mru> any machine with an eieio instruction has to be good
[00:16:57] <Sean_McG> heheheh
[00:22:17] <roxfan> pfft eieio
[00:22:28] <Sean_McG> roxfan: HCF?
[00:22:28] <mru> best instruction ever
[00:22:46] <Sean_McG> Halt & Catch Fire, for the uninitiated
[00:22:47] <roxfan> what about sleep, doze, nap _and_ rvwinkle?
[02:53:26] <kierank> Compn: do you know if we have any samples with e-ac3 in ts
[02:53:42] <Jumpyshoes> BBB: want me to write avx asm for ffmpeg? i'd need to port the abstraction layer
[02:54:00] <Dark_Shikari> and by port you mean "cp"
[02:54:17] <Jumpyshoes> :D
[02:54:51] <bcoudurier> kierank, we do from the french tv channels :)
[02:58:15] <Compn> kierank : uhhhhhhh
[02:58:19] <Compn> whats e-ac3 usually in ?
[02:58:27] <Compn> m2ts ?
[02:58:28] <kierank> .ts or .m2ts
[02:58:46] <kierank> but i'm looking for hdtv samples
[02:58:47] <bcoudurier> kierank, aren't the ones in allsamples good ?
[02:58:59] <bcoudurier> or ask j-b he probably has some
[02:59:08] <bcoudurier> justin for sure I think
[02:59:20] <Compn> kierank : no clue, the ones in allsamples are the only ones i know of
[02:59:22] <Compn> :(
[02:59:42] <Compn> theres also a bunch of .ts in incoming probably
[02:59:42] <kierank> maybe i should go on a day trip and capture some eac3 ;)
[02:59:45] <Compn> no one cleans it out
[03:00:23] <Jumpyshoes> BBB: if you ping me later, it might be better to do it in #x264dev since i actually read the backlog for that channel
[03:01:20] <bcoudurier> kierank, search in vlc forum
[03:01:35] <kierank> that's a good point
[03:01:41] <bcoudurier> french tvs were using eac3 spectral
[03:01:51] <bcoudurier> and that caused some bug reports
[03:07:34] <kierank> yay found one
[03:17:27] <Sean_McG> OK, looking at this VP8 AltiVec thing my first gripe is with the use of macros in vp8dsp_altivec.c
[03:17:54] <Sean_McG> wondering why it couldn't have been written as an inline function
[03:37:57] <kierank> ruggles: why do you use bsid of 8 in the ac3 encoder?
[03:39:02] <kierank> afaik nobody uses 8 any more
[03:39:05] <kierank> everybody uses 6
[05:44:30] <CIA-38> ffmpeg: Young Han Lee <cpumaker at gmail.com> master * read15f1dc1 ffmpeg/libavcodec/ (aac.h aacdec.c aacdectab.h mpeg4audio.h):
[05:44:31] <CIA-38> ffmpeg: aacdec: Implement LTP support.
[05:44:31] <CIA-38> ffmpeg: Ported from gsoc svn.
[05:45:47] <saintdev> \o/
[05:47:35] * pJok prods saintdev to fix ffaacenc
[05:47:56] <saintdev> eek, now elenril has got you at it as well
[05:48:00] * Sean_McG cheers too
[05:48:20] <pJok> it needs fixing
[05:48:25] <pJok> and people keep saying you can fix it :P
[05:49:00] <Sean_McG> I think I'd like to take a crack at fixing these VP8 AltiVec problems, unless someone else is already looking at it?
[05:50:08] <pJok> saintdev, and fix mpeg1 layer 2 audio while you're at it
[05:50:17] <saintdev> yeah right
[05:50:27] <saintdev> i have absolutely no use for that
[05:52:40] <pJok> saintdev, was worth a try :P
[07:44:04] <cartman> moin
[07:46:02] <Flameeyes> hi cartman
[08:00:23] <siretart> morning
[08:00:33] <thresh> moroning
[08:00:36] <siretart> what do you think about: http://mpeg.chiariglione.org/meetings/daegu11/daegu_press.htm?
[08:03:06] <cartman> lo Flameeyes
[08:03:54] <Flameeyes> siretart: uhm given the guy's address is in Turin I'd ask lu_zero when he wakes up :)
[08:04:30] * av500 lols at the fact that MPEG does not own mpeg.org
[08:04:57] <peloverde> MVC in TS, just what I always wanted
[08:04:59] <siretart> yeah, that's indeed hilarious
[08:06:00] <saintdev> av500: they're video guys, not internets guys. =P
[08:06:35] <av500> what happens if chiariglione steps down as mpeg BDFL?
[08:09:31] <astrange> they all move to IETF?
[08:10:25] <peloverde> they put me in charge
[08:11:06] <siretart> I espc. like this part: "...MPEG will issue a call for proposals on video compression technology at the end of its upcoming meeting in March 2011 that is expected to lead to a standard falling under ISO/IEC “Type-1 licensing”, i.e. intended to be “royalty free”."
[08:11:46] <siretart> seems like a great opportunity for the free software community
[08:12:39] <Flameeyes> I wonder if we can go lobby in Geneve, or Turin :P
[08:12:48] <av500> siretart: you mean the free codec community
[08:13:04] <av500> or is ffmpeg not free sw?
[08:13:43] <siretart> av500: I consider ffmpeg as part of the free software community, but of course, you're right, ffmpeg of course included
[08:13:59] <Flameeyes> av500: depends who you ask; gnu probably finds ffmpeg evil!
[08:14:15] <Flameeyes> we dare provide users with support for codecs that are used out there!
[08:14:29] <siretart> do we care about their opinion on us?
[08:14:34] <av500> siretart: it was my lame attempt to troll you into making some patent remark :)
[08:14:50] <siretart> av500: ok. your attempt has failed then ;-)
[08:15:26] <Flameeyes> siretart: I don't :D
[08:16:15] <Flameeyes> I'm an happy GNU (emacs) user but that doesn't mean I have to subscribe to everything that passes for a good idea in their minds ;)
[08:16:50] <siretart> Flameeyes: ah, btw, it might very well be possible that we could arrange ipv6 to midas soon. seems that things look much better with squeeze, so it might work after we've upgraded the host.
[08:17:31] <Flameeyes> siretart: good to hear! let me know even if you need a guinea pig to get it tested
[08:18:13] <siretart> Flameeyes: sure. but first I'd prefer to experiment with (other) internal hosts first before doing that to customer hosts
[08:19:24] <Flameeyes> of course :) — btw if you're looking at general fixes and improvements, would you mind taking a look at entropy as well? it seems like the vservers end up with very feeble entropy (and no way to inject more even with stuff like timer_entropyd), can be bad for https afaict
[08:20:18] <siretart> oh, interesting. I should add that to the collectd monitoring then. thanks for the hint
[08:21:19] <Flameeyes> np — for my boxes here I ended up getting the entropykey that I read wonders of on planet debian ;)
[08:22:36] * kshishkov is a bit proud of http://satwcomic.com/art/nuclear-power.jpg
[08:23:46] <Flameeyes> lol
[08:24:25] <vipw> why is the french guy wearing a swedish shirt?
[08:24:46] <kshishkov> what France has to do with that?
[08:25:03] <av500> they have the most non working nucular power plants
[08:25:24] <kshishkov> and Ukraine hold the record for peak nuclear plant productivity indeed
[08:25:41] <thresh> who needs plants when one can have weaponry
[08:25:53] <vipw> most nuclear power in the world is either france(per capita or as pct of total) or usa (watt capacity)
[08:26:20] <superdump> perhaps they meant in scandinavia
[08:26:36] <kshishkov> thresh: most of Soviet nuclear weapons ended as nuclear fuel for US plants
[08:27:08] <vipw> i have the most nuclear power in the whole scandinavia!! kneel before zod!
[08:27:09] <kshishkov> superdump: would you like it labeled for furniture instead?
[08:27:40] * pJok makes kshishkov fix mpeg1 layer 2 audio instead
[08:28:00] <Flameeyes> if somebody didn't guess that already, trying to draw UML diagrams with a mouse having a faulty left button is no fun. at all.
[08:28:31] <av500> Flameeyes: you can make window swap the buttons
[08:28:33] <av500> +s
[08:28:49] <vipw> wbs: i found a fairly complete (but very ugly) implementation of http-live-streaming in boxee
[08:28:51] <kshishkov> pJok: do you want me to adapt ffaacenc for producing layer2?
[08:28:52] <Flameeyes> av500: osx and it's bothersome to swap them as well :P
[08:29:35] <vipw> but it includes encryption support as well as adaptive bandwidth switching
[08:29:42] <pJok> kshishkov, dunno, i just wish people would stop wanting layer 2 audio for broadcasting...
[08:30:06] <pJok> kshishkov, they always demand peak perfect audio, which ffmpeg isn't able to produce
[08:30:10] <wbs> vipw: mmkay
[08:31:13] <kshishkov> pJok: I may look at it eventually
[08:32:16] <pJok> kshishkov, last time i fixed it by sending them what they'd encode to anyways for broadcast... but now there are someone else wanting it again... what is it with broadcasters and 50mbit mpeg2 iframe only and compressed audio?
[08:32:33] * pJok would rather deliver everything in IMX30
[08:33:28] <vipw> does anything in libavformat support adaptive bandwidth?
[08:34:05] <kshishkov> ffaacenc classic? It had not so reliable bitrate control
[08:34:33] <wbs> vipw: not automatically adaptive, but both realrtsp and our applehttp stuff can choose which bandwidth variant to use by setting the discard flags on the different avstreams
[08:34:42] <vipw> with http it's trivial to measure how long it takes to download an X-second segment, and adapt from that
[08:35:08] <wbs> vipw: except that it requires the download not to be waiting outside of library anywhere
[08:35:47] <vipw> i don't think i follow you
[08:36:19] <wbs> since the user calls av_read_frame(), which internally calls url_read() on the urlprotocol, which does the http reading
[08:36:29] <Flameeyes> vipw: it's hard to account for the latency between libavformat and the connection itself, if I read wbs right
[08:36:35] <av500> can we have this channel without voice and play ffmpeg-devel-karaoke?
[08:36:50] <wbs> if the user calls av_read_frame() immediately again and doesn't do anything else inbetween, you'd get a fairly ok estimate of the bandwidth
[08:37:21] <wbs> but if you decode frames or think you've already buffered enough data and don't read more data yet, you won't measure what the connection actually is capable of
[08:37:52] <wbs> e.g. ffplay only buffers up to a certain amount, then it waits until the playing consumes some data before fetching more
[08:38:06] <vipw> oh, i thought that individual segments were downloaded full-throttle
[08:38:13] <av500> that buffer could be used with high/low water mark to select streams
[08:38:43] <av500> hmm
[08:39:00] <wbs> vipw: that wouldn't be feasible in a non-threaded setup I think
[08:39:11] <wbs> or perhaps it would be
[08:40:33] <Flameeyes> don't think it would be..
[08:40:33] <j-b> kierank?
[09:04:34] <siretart> DonDiego: Flameeyes: FYI: the transition from ffmpeg 0.5 -> 0.6 in debian has started. progress is tracked here: http://release.debian.org/transitions/ffmpeg.html
[09:06:16] <cartman> no way
[09:06:47] <av500> lu_zero: wbs: http://www.mail-archive.com/live-devel%40lists.live555.com/msg02258.html
[09:06:54] <spaam> so next year debian going to have -mt ;D
[09:06:54] <av500> ever heard of that issue?
[09:07:52] <wbs> av500: yes, I've seen youtube rtsp servers not supporting tcp
[09:08:10] <av500> wbs: and the "udp hole punch"?
[09:08:28] <av500> to make it work behind a firewall
[09:08:31] <wbs> av500: we do that since last year, patch by yours truly
[09:09:27] * av500 <3 wbs
[09:11:05] <cartman> http://nokiaplanc.com/ heheh
[09:11:37] <av500> nice
[09:15:10] <cartman> my fate is not green
[09:15:12] <cartman> damn you all
[09:15:46] <saintdev> cartman: lol
[09:16:27] <Flameeyes> cartman: build failure? :D
[09:16:39] <cartman> Flameeyes: nah VP8 tests failing with clang 2.9 trunk :(
[09:16:44] <cartman> optimizationfail
[09:16:57] <Flameeyes> isn't that an old one?
[09:17:04] <cartman> yeah 4 days old
[09:17:05] <cartman> :P
[09:17:19] <Dark_Shikari> lol clang
[09:17:27] <cartman> Dark_Shikari: you bastard
[09:17:36] <Dark_Shikari> not my fault clang sucks `-`
[09:17:56] * cartman needs a green fate so in case of a compile failure he can bisect clang
[09:19:26] <kshishkov> make!
[09:19:54] <cartman> s/k/t/
[09:20:01] <pJok> make.believe?
[09:20:14] <kshishkov> cartman: for Peter - yes, for you - make it
[09:20:28] <cartman> kshishkov: dual birds with one stone
[09:21:59] <Flameeyes> cartman: are the birds parallel at least?
[09:22:09] <cartman> maybe :P
[09:23:23] <kshishkov> Flameeyes: and fast as unladen African swallows
[09:24:02] <spaam> wbs: yo. do you have any rtp streams? :)
[09:24:04] <pross-au> Chaps
[09:24:14] <wbs> spaam: a few
[09:24:25] <cartman> spaam: wbs streams kitten pr0n 24/7
[09:24:29] * Flameeyes got UML models of RTP streams >_<
[09:24:31] <cartman> its all meowwww all night long
[09:24:32] <spaam> cartman: Nice
[09:24:36] <wbs> Flameeyes: :-)
[09:24:48] <spaam> wbs: can you share some of them? :)
[09:24:52] <Flameeyes> wbs: I'm basically rewriting lscube.. in UML =_=
[09:24:56] <spaam> wbs: if they are over utp :)
[09:25:16] <Flameeyes> spaam: what if they are in fiber?
[09:25:24] <wbs> spaam: rtsp://albin.abo.fi:7070/sample_100kbit.mp4
[09:25:46] <wbs> spaam: is both udp or tcp depending on what the client requests
[09:26:03] <kshishkov> pross-au: I read an article about constant M$ failure with storage technologies. It mentioned their attempts on structured file system (OLE crap for example), you are working on another one (aka WTF^HV)
[09:26:13] <spaam> wbs: ok :) how do i get it as udp with ffmpeg? :)  ?protocol=udp ?
[09:26:23] <cartman> [aac @ 0x101014a00] RTP: PT=61: bad cseq d30e expected=f1df
[09:26:23] <cartman> [mpeg4 @ 0x101010000] RTP: PT=60: bad cseq 02c7 expected=39bd
[09:26:24] <cartman> nice
[09:26:24] <spaam> Flameeyes: too bad for me.
[09:26:25] <cartman> :D
[09:27:09] <wbs> spaam: ffplay <url> should try both udp, and if you don't get any packets, it should fall back to tcp after a while
[09:27:12] <Flameeyes> spaam: ya know, twisted pair doesn't work well on long distance ;)
[09:28:16] <spaam> Flameeyes: damn it! ;S then you need to get the stream to malmö
[09:28:30] <spaam> wbs: cool :)
[09:30:37] <kshishkov> spaam: no problem, Mediterranean -> Atlantic Ocean -> Northern Sea
[09:33:34] <spaam> wbs: got rtsp from it ;S
[09:35:22] <spaam> oh
[09:37:06] <spaam> didnt work..
[09:37:12] <wbs> spaam: rtsp, which sets up two rtp/udp sessions, yes
[09:38:58] <spaam> mm..
[09:39:36] <spaam> i got something that should not be rtp and so i need to fix it : )
[09:42:53] * pJok drags a fiber to spaam 
[09:44:35] <av500> http://webm.googlecode.com/files/Realtime_VP8_2-9-2011.pdf
[09:45:35] <KotH> grüezi
[09:46:52] <kshishkov> shalom
[09:48:02] <spaam> pJok: yay ;D  then we have another isp at the office ,D  now we have comhem and telia :D
[09:49:23] <kshishkov> spaam: so each computer has its own ISP?
[09:50:00] <spaam> kshishkov: no.. two computers have one isp.. all the others have the other one :)
[09:50:49] <spaam> the first two  we use for srs bizniz. like play games, watch weird .cn p2p video..
[09:53:21] <kshishkov> "weird .ch" is like "crazy Norrlander", totally redundant
[09:54:16] <kshishkov> err, "weird .cn" too
[10:13:44] <pross-au> kshishkov: i wonder what comes after wtv..
[10:14:15] <av500> wbs: any idea why tcp.c would suddenly report: Failed to resolve hostname www....: Name or service not known
[10:15:18] <wbs> av500: hmmm, no idea... sometimes on some OSes, a failure is cached instead of retried (in many different applications)
[10:16:27] <av500> its strange, same address works with curl
[10:16:32] <av500> but not from tcp.c
[10:16:50] <av500> and tools like ping or traceroute are able to resolve it as well
[10:18:40] <saintdev> pross-au: wtw ?
[10:19:27] <pross-au> wtv: television disk-streaming format found in Windows Vista/7
[10:19:47] <saintdev> so "wtw" would be next
[10:19:56] <saintdev> then wtx
[10:19:58] <saintdev> =P
[10:20:01] <pross-au> Ah
[10:20:28] <kshishkov> or wpv for Windows Phone
[10:20:46] <saintdev> 'p' doesn't come after 't'
[10:20:58] <saintdev> well it does, but not directly after it
[10:21:07] <kshishkov> is M$ known for logic?
[10:21:22] <saintdev> erm..
[10:21:25] * saintdev is tired
[10:21:28] <wbs> av500: hmm, weird
[10:21:50] <kshishkov> saintdev: why, you haven't produced anything for ffaacenc, have you?
[10:21:53] <pross-au> C'mon, its 2011, we're no longer restricted to three character filenames.
[10:22:09] <kshishkov> it's tradition, mate
[10:22:19] <pross-au> then it should be in uppercase TOO
[10:22:43] <kshishkov> internally they probably are - it's case-insensitive anyway
[10:22:49] <saintdev> filename.ext NO EXCEPTIONS
[10:22:59] <kshishkov> prn
[10:23:05] <pross-au> PRN$
[10:23:14] <pross-au> or was the dollar in front, i forget
[10:23:32] <saintdev> longfi~1.ext
[10:24:52] <kshishkov> or extension.notsoshortfilename for libavseq devs
[10:25:22] <saintdev> they hate DOS
[10:25:50] <kshishkov> nope
[10:26:03] <kshishkov> only M$ DOS, PC DOS and DR DOS
[10:26:12] <kshishkov> AmigaDOS was fine for them
[10:26:39] <saintdev> yeah, but who uses that. 99% of the world used MS
[10:27:12] * kshishkov points to USA aka Unique Shoppers at Apple
[10:42:09] <superdump> av500: any idea who authored that pdf? it wasn't BBB was it?
[10:42:17] <superdump> ah no
[10:42:19] <superdump> january 2010
[11:38:39] <av500> wbs: found it, getaddrinfo() has issues in a chroot
[11:46:01] <wbs> av500: oh, that's interesting, any references to that issue?
[11:48:47] <av500> yes
[11:49:22] <wbs> ah, found some info
[11:50:48] <av500> yes, needed 2 more libs copied
[11:59:25] <av500> wbs: btw, playing m.youtube stuff give me a lot of video errors. vlc has way less
[11:59:48] <wbs> av500: hmm, any sample url?
[11:59:54] <av500> sure
[12:00:02] <av500>  "rtsp://v3.cache3.c.youtube.com/CjYLENy73wIaLQmVlK-fWDADMRMYESARFEIJbXYtZ29vZ2xlSARSBXdhdGNoYO3siuDDx5qtTQw=/0/0/0/video.3gp"
[12:00:18] <j-b> wbs: did you manage to extort money?
[12:00:35] <av500> wbs: but sound is OK
[12:01:00] <wbs> j-b: working on it, got a mail today that they should be ok with it
[12:01:22] <j-b> nice
[12:01:38] <av500> j-b: where can I extort money too?
[12:01:56] <cartman> your bank account
[12:02:09] <wbs> av500: try adding -max_delay 100000 to the ffplay command line, then it's almost warning free for me
[12:03:07] <j-b> av500: vlc-devel@
[12:03:46] <lu_zero> av500: iirc that is udp only
[12:03:53] <av500> lu_zero: yes
[12:04:04] <lu_zero> and we do still are decode loop driven
[12:04:13] <lu_zero> so we will miss frames
[12:04:18] <av500> meaning?
[12:04:30] <lu_zero> you can be network loop driven
[12:04:58] <lu_zero> so your loop ticks every time you have something from the network
[12:05:04] <lu_zero> or you can be decode loop driven
[12:05:22] <lu_zero> so you move forward once you need more to decode
[12:05:37] <av500> lu_zero: actually I am busrting
[12:05:40] <av500> bursting
[12:05:45] <av500> I have a big buffer for packetsd
[12:05:49] <lu_zero> uh?
[12:06:13] <av500> lu_zero: the system still assumes the data might come from a hdd
[12:06:21] <av500> which needs to sleep most of the time
[12:06:50] <lu_zero> looks like I'm missing something
[12:06:58] <lu_zero> which is the system?
[12:07:03] <av500> my system
[12:07:06] <av500> I use lavf for rtsp
[12:07:08] <lu_zero> ok...
[12:07:09] <av500> I try to
[12:07:13] <av500> ffplay is just for testing
[12:07:27] <lu_zero> and your problem is that the udp proto is unsuitable
[12:07:38] <lu_zero> tcp I bet works fine =P
[12:07:38] <av500> so, what is -max_delay xx in the lavf api?
[12:07:46] <av500> lu_zero: nope, there is no tcp here
[12:07:49] <av500> its udp only
[12:08:02] <lu_zero> =\
[12:08:07] <wbs> av500: AVFormatContext->max_delay
[12:08:52] <av500> yup
[12:08:54] <av500> thx :)
[12:09:04] <av500> lets try to set that
[12:10:17] <wbs> hmm, weirdly enough, the packets do seem to arrive in order, so that shouldn't help much, but it apparently seems to make the buffering behaviour work better for ffplay at least ;P
[12:13:54] <wbs> no, there sure is some jitter. not much, but a little, and setting max_delay reorders packets for those cases, working exactly as intended \o/
[12:14:35] <wbs> av500: nice video btw ;P
[12:14:55] <av500> wbs: it was a random click on that m.utub size
[12:14:57] <av500> site
[12:15:18] <av500> wbs: did you build one by now?
[12:15:37] <wbs> av500: build a what?
[12:18:53] <lu_zero> youtube?
[12:19:20] <cartman> http://i.imgur.com/M52mw.png LOL
[12:21:34] <av500> wbs: well, that love ring
[12:21:51] <wbs> av500: aah, not yet
[12:22:50] <kshishkov> cartman: well, seems the book found its reader
[12:23:26] <cartman> kshishkov: absolutely
[12:25:40] <lu_zero> uh
[12:25:48] <av500> wbs: setting that does nothing in my app :(
[12:26:26] <wbs> av500: hmm, how old lavf do you use? I think that was added in october/november sometime
[12:26:27] * lu_zero wonders what will happen now, Berlusconi got http://www.bbc.co.uk/news/world-europe-12083491
[12:27:24] <av500> wbs: I see it in rtsp.c
[12:27:34] <Flameeyes> lu_zero: they'll just make another Lodo Al Nano
[12:28:37] <wbs> av500: hmm, can you add debugging in rtsp to see that it actually is nonzero, to make sure it was set and initialized at the right place and not overwritten?
[12:28:43] <av500> sure
[12:28:48] <thresh> Nano stuff is reserved by mr Medvedev nowadays
[12:29:36] <kshishkov> Flameeyes: but it's interesting how many open crimes he can commit
[12:29:47] <cartman> and still be president
[12:29:53] <kshishkov> thresh: Чубайса забыл!
[12:30:01] <kshishkov> cartman: of course
[12:30:15] <cartman> http://nokiaplanx.com/ btw.
[12:30:41] <av500> Flameeyes: lu_zero: but after all the crimes, only after the 17y sex thing your people go to the streets?
[12:30:52] <av500> the rest was ok, or what?
[12:31:04] <Flameeyes> av500: actually it's not the first time people reach the street
[12:31:09] <kshishkov> cartman: http://www.msqt.org
[12:31:22] <Flameeyes> the problem is... we have no opposition, so ...
[12:31:48] <cartman> kshishkov: yeah saw that one, cute
[12:32:01] <Flameeyes> cartman: no, qute! :P
[12:32:09] <cartman> hehhe :P
[12:32:26] <thresh> cartman: lol
[12:32:31] <thresh> they're fast
[12:32:40] <cartman> heheh
[12:32:43] <thresh> I was thinking 'I wonder when there would be nokiapland site'
[12:32:51] <cartman> :D
[12:33:32] <Flameeyes> nokiaplane was the best though :P
[12:34:12] <jannau> nokia plan f fails on mouse over
[12:34:15] <cartman> heheh
[12:34:33] <jannau> nsfw
[12:34:46] <cartman> jannau: too late
[12:34:48] <cartman> fsck
[12:35:56] <av500> wbs: its 100000 all the time
[12:36:02] <av500> lets put more
[12:37:40] <lu_zero> av500: many times people got in the streets
[12:37:57] <lu_zero> but before the media tried to ignore the protest
[12:38:18] <Flameeyes> lu_zero: speaking about people and going places, did our coworkers reach the office? :P
[12:38:22] <lu_zero> even if you get 1/10 of the people of a city in a square protesting
[12:38:38] <lu_zero> Flameeyes: good question, today we are supposed to be at topix
[12:39:11] * lu_zero is home due a strange chain of events started by his sister...
[12:39:37] <lu_zero> j0sh: poing
[12:40:05] <Flameeyes> lu_zero: why strange chains of events _always_ involve your sister?
[12:41:04] <lu_zero> Flameeyes: because she's my sister?
[12:41:15] <Flameeyes> yeah that's enough of a reason I guess
[12:41:29] <Compn> was she protesting lu_zero ?
[12:41:41] <Compn> i heard on the radio people were protesting in italy
[12:41:46] <lu_zero> Compn: she's studying in the countryside
[12:41:51] <DonDiego> Flameeyes: does xine use pkgconfig?
[12:41:55] <Flameeyes> DonDiego: it does
[12:41:55] <Compn> are you finally going to get rid of berluscioni ?
[12:41:58] <DonDiego> for ffmpeg i mean
[12:42:11] <lu_zero> Compn: actively trying since 15years ago
[12:42:17] <lu_zero> now apparently more people got aware
[12:42:26] <Compn> yeah but is this the one that will sink him? its hard to tell from here
[12:43:14] <lu_zero> Compn: the main issue with berlusconi is his grasp on the media
[12:43:36] <kshishkov> i.e. he either owns or sues the media
[12:43:40] <Flameeyes> and the media having a grasp on the average Mario Rossi
[12:43:46] <wbs> av500: if you have that enabled, you should at least get warnings about missed packets and/or too old packets received
[12:43:48] <Compn> yep, thats a problem when he owns all of the state-tv channels
[12:44:11] <av500> wbs: hmm, nope
[12:44:13] <wbs> av500: but if you do read in bursts, you might well get dropped packets.. for udp, the code should ideally be waiting in poll()/read() all the time
[12:44:19] <kshishkov> Flameeyes: maybe you should just call hil il Duce and forget about it
[12:44:23] <kshishkov> *him
[12:44:33] <Flameeyes> kshishkov: I wish...
[12:44:55] <lu_zero> we'll see anyway
[12:45:13] <kshishkov> wanna get Ukrainian guy instead?
[12:45:20] <wbs> av500: you could add debugging code in rtpdec.c, around lines 705-710, that prints what seq and diff are, there you should easily see what's going on
[12:45:30] <cartman> I'll have a spare Turkish one for you lu_zero & Flameeyes
[12:45:35] <Compn> kshishkov : what happened to the guy that was poisioned and his face went all blaoted ?
[12:45:36] <cartman> Berlusconi replacement, 1:1 :P
[12:45:39] <Compn> bloated*
[12:45:55] <kshishkov> cartman: your country seems to have run out of Ataturks
[12:46:01] <cartman> kshishkov: long ago
[12:46:32] <kshishkov> Compn: he's not a president since 2008 IIRC
[12:46:36] <Compn> cartman : going to be protests in turkey like tunisa/egypt? :P
[12:46:53] <Compn> my friend was trying to guess the next country...
[12:46:56] <cartman> Compn: nope, I think not.
[12:46:59] <av500> Compn: there is a queue, they are late :)
[12:47:08] <Compn> haha
[12:47:15] <cartman> only students protest here
[12:47:50] <Flameeyes> cartman: they solved that in italy
[12:47:59] <Flameeyes> there is no reason for people to _be_ student, with the kind of universities we have
[12:48:08] <cartman> Flameeyes: lol
[12:48:18] <cartman> they beat the hell out of them here
[12:48:26] <cartman> one uni. student lost her baby
[12:49:16] <av500> what kind of uni is that?
[12:49:29] <cartman> The Life Universityâ„¢
[12:49:43] <kshishkov> Flameeyes: there's absolutely no reason to be student in .ua Especially since they'll get more money not working by speciality and nobody believes diplomas much either
[12:50:05] * Flameeyes decided not to go to uni after two weeks, been working since then
[12:50:13] <cartman> Flameeyes: better than me
[12:50:20] <cartman> I stopped after 2 years :P
[12:50:31] <kshishkov> I stopped after 8 years
[12:50:40] <cartman> kshishkov: with a diploma my friend ;)
[12:50:44] <Flameeyes> got lucky, my ex-professor from high school proposed me a job immediately
[12:50:58] <cartman> finding a job is never hard
[12:51:07] <cartman> finding smart people to work with, is hard :p
[12:51:17] * kshishkov waits for av500 to say something about döner stalls
[12:51:26] <Flameeyes> cartman: yeah it was with my teacher so it wasn't bad
[12:51:28] <av500> cartman: you are on 0800-FIXMYSUSE soon, right?
[12:51:41] <Flameeyes> translated Ian Sommerville's "Software Engineering" book
[12:51:43] <cartman> av500: they say software engineer too, right :)
[12:52:08] <cartman> av500: 0800-FIXMYSUSE is in India
[12:52:32] <av500> so you are outsourced already?
[12:52:55] <cartman> heheh
[12:53:01] <cartman> stop dreaming ;)
[12:53:33] <kshishkov> av500: wanna get code from India written by Turks?
[13:23:00] * kshishkov finds http://en.wikipedia.org/wiki/Sweden_Solar_System funny
[13:24:30] <spaam> :)
[13:28:06] <Kovensky> kshishkov: I don't know why but http://en.wikipedia.org/wiki/Sweden_Solar_System is blocked in my college
[13:28:10] <Kovensky> lol
[13:28:53] <kshishkov> Kovensky: obviously stupid college
[13:29:09] <Kovensky> found out
[13:29:14] <Kovensky> they did block the "Sweden" word
[13:29:21] <Kovensky> and not even a substring of it
[13:29:30] <av500> sweden = porn
[13:30:23] <Dark_Shikari> we have a new meme!
[13:30:29] <Dark_Shikari> http://www.nokiaplanb.com/ started it...
[13:30:34] <Dark_Shikari> then we got http://www.nokiaplanc.com/
[13:30:36] <Dark_Shikari> then we got http://www.nokiapland.com/
[13:30:37] <Dark_Shikari> then we got http://www.nokiaplane.com/
[13:30:45] <av500> you are late
[13:30:46] <JEEB> lawl
[13:30:50] <Dark_Shikari> They keep adding more!
[13:30:53] <spaam> Dark_Shikari: look at planx!
[13:30:56] <thresh> and you are late
[13:30:56] <Dark_Shikari> "nokiaplane.com" is literal
[13:31:06] <Dark_Shikari> Yup, planx is the best~
[13:31:10] <av500> Dark_Shikari: pls tell new stuffz
[13:31:11] <spaam> http://nokiaplanx.com/ ;D
[13:31:14] <spaam> :D
[13:31:28] <spaam> http://nokiaplana.com/
[13:31:38] <Dark_Shikari> .... lol?
[13:31:45] <kshishkov> nokiaplanms?
[13:31:47] <Dark_Shikari> oh god I lol'd
[13:31:51] <Dark_Shikari> that is brilliant.
[13:31:57] <cartman> heheh
[13:34:18] <spaam> http://www.nokiaplan9.com/
[13:35:12] <thresh> plana is nice indeed
[13:35:22] <thresh> too bad nokiaplant is squatted
[13:35:35] <av500> we need a nokia plan webring NOW!
[13:35:44] <thresh> av500: http://nokiaplans.com/
[13:35:50] <cartman> LOL
[13:35:52] <spaam> :DDDD
[13:36:02] <av500> thats not a ring
[13:36:15] <spaam> av500: FiX iT
[13:36:20] <cartman> Plan G is boring
[13:37:14] <av500> looooool: ...Attend Ubuntu meetings, talk to Shuttleworth....
[13:38:02] <Kovensky> plan g is an actual good plan instead of a joke =p
[13:38:18] <Kovensky> plan h has the wrong page title :D
[13:38:20] <av500> Kovensky: plan g is the actual plan that got nokia into that mess
[13:38:38] <Kovensky> av500: then they executed it wrong? o_O
[13:38:45] <Kovensky> though I don't actually know what the mess is :>
[13:38:46] <av500> no
[13:38:59] * Kovensky never cared about cellphones
[13:39:01] <av500> they executed it and now they have to hire elop
[13:39:02] <cartman> Nokia 3310 the unbreakable phone
[13:42:19] <av500> http://nokiaplank.com/
[13:42:53] <mru> this plank is made for walking...
[13:43:00] <cartman> hit elop with that
[13:43:06] <spaam> http://nokiaplanz.com/
[13:44:08] <av500> mru: go get plan54 for us
[13:44:28] <mru> got content?
[13:44:49] <av500> not really
[13:45:00] <mru> alias it to 26-26-54?
[13:45:05] <av500> who cares, lets buy adwords
[13:45:08] <cartman> mru: I used to only buy Sony VAIO laptops, they are pretty good
[13:45:20] <mru> cartman: good but expensive
[13:45:22] <av500> cartman: that is not called "ridiculing"
[13:45:24] <mru> and quirky bios
[13:45:24] <cartman> true
[13:45:34] <cartman> you can patch the acpi table
[13:45:50] <mru> good thing ivan dimkovic has the same model
[13:45:55] <cartman> hahah
[13:46:07] <spaam> mru: Here at work we only have Thinkpad and macbook :)
[13:46:10] <kshishkov> and he patched the bios IIRC
[13:46:14] <mru> exactly
[13:46:39] * cartman patches his ooooold VAIO to enable VT
[13:46:47] <spaam> who is this ivan dimkovic ?
[13:46:57] <cartman> spaam: the man that brought you AAC encoding
[13:47:38] <spaam> cartman: why dont we have it in FFmpeg?
[13:48:04] <cartman> spaam: eh because he doesn't do open source :P
[13:48:10] <mru> spaam: I've asked kshishkov to kidnap ivan and make him work on ffaacenc, but he refuses
[13:48:18] <cartman> he was working for Nero last time I checked
[13:48:22] <av500> he is
[13:48:24] <mru> sort of
[13:48:32] <av500> he tried to sell nero to me
[13:48:33] <spaam> kshishkov: come on. .do it.. i can buy you some trocadero and julmust!
[13:48:41] <cartman> av500: crap suite?
[13:48:45] <cartman> 1GB cd burner
[13:48:54] <av500> kshishkov: you dont need to kidnap him, just corner him
[13:48:56] <mru> spaam: kidnapping your boss (-ish) probably isn't good for your career
[13:49:05] <twnqx> av500: i just opened a dbox2 and looked at the chips... is that hte source of your nick?
[13:49:05] <mru> av500: same thing with kshishkov
[13:49:23] <av500> twnqx: er, nope
[13:49:31] <twnqx> no avia500 asic? :P
[13:49:42] <cartman> twnqx: there is Archos AV500
[13:49:50] <twnqx> ah...
[13:50:12] <av500> twnqx: http://reviews.cnet.co.uk/i/c/rv/e/dvdplayers/archos/av500/200x150_1.jpg
[13:50:28] <spaam> mru: maybe kshishkov can get the source and just share it to us? ;D
[13:51:02] <kshishkov> it's C++ I think
[13:51:25] <cartman> thats a start
[13:51:34] <cartman> leak 1 line of code everyday
[13:51:39] <cartman> ++i; here is one
[13:51:43] <av500> and apply C-- to it
[13:51:55] <mru> av500: that would be --C
[13:52:03] <mru> got to balance the operators
[13:52:11] <kshishkov> --(C++)
[13:52:18] <av500> cartman: here: "     encode_aac(ctx, foo);"
[13:52:18] <mru> not an lvalue
[13:52:34] <cartman> av500: foo, no way
[13:52:34] <mru> spaam: the source is not pretty at all
[13:52:35] <kshishkov> mru: see, it's not possible!
[13:52:54] <spaam> mru: but we can make it
[13:53:03] <mru> a++-++b is valid c
[13:53:10] <av500> mru: but you did leave a beagleboard plugged to the corporate network when you left there, right?
[13:53:40] <kshishkov> av500: it's got reused
[13:53:57] <kshishkov> av500: but he left me there
[13:54:34] <av500> kshishkov: no, the *other* one under the raised floor....
[13:55:03] <mru> kshishkov: remember that eth adaptor that went missing?
[13:55:27] <kshishkov> av500: nope, we don't even have case with shotgun for extreme situations
[13:55:33] <kshishkov> mru: not at all
[13:55:33] <cartman> are they still using CVS though? *ducks*
[13:55:42] <mru> elif was searching all over for it
[13:55:50] <cartman> sounds Turkish
[13:55:57] <mru> what?
[13:56:07] <mru> cvs?
[13:56:15] <kshishkov> can't people name their child for C preprocessor directive?
[13:56:17] <cartman> the modern vcs
[13:59:48] <cartman> kshishkov: Elif is a Turkish girl name
[14:00:02] <mru> this one is french, or so she says
[14:00:09] <cartman> lying
[14:00:11] <cartman> :p
[14:00:17] <mru> she looks more french than turkish
[14:00:21] <cartman> actually
[14:00:26] <cartman> its roots are Arabic
[14:00:37] <cartman> Elif is the "A" of Arab alphabet
[14:00:42] <kshishkov> cartman: is Endif also a Turkish name?
[14:00:49] <cartman> kshishkov: sadly no
[14:01:00] <mru> ifdef?
[14:01:07] <cartman> only Elif :P
[14:01:15] <av500> gosub?
[14:01:27] <mru> elsie is a swedish name
[14:01:32] <mru> off by one...
[14:01:34] <cartman> so close
[14:01:34] <cartman> :D
[14:01:54] <av500> elsie always picks the *other* guy
[14:03:11] <kshishkov> av500: be thankful for what you got
[14:03:40] <cartman> Will you guys attend LinuxTag?
[14:03:44] <mru> kshishkov: have you met his wife? I have...
[14:03:51] <mru> cartman: I hope so
[14:04:03] <cartman> nice then we can meet finally \o/
[14:04:05] <kshishkov> mru: she's somewhere on pictures in his Flikr
[14:04:39] <cartman> I didn't met av500's wife but his kids are lovely
[14:04:48] <kshishkov> cartman: the most important is for you to meet av500
[14:04:50] <mru> I've only met two of them
[14:05:02] <mru> and both of av500 of course
[14:05:09] <cartman> kshishkov: he might kill me unlike I bring köfte
[14:05:09] <av500> mru: early in the morning too :)
[14:05:21] <av500> cartman: I kill you just like that
[14:05:21] <mru> av500: indeed
[14:05:27] <cartman> av500: wow
[14:05:32] <cartman> don't sit on me
[14:05:34] <cartman> please
[14:05:34] <cartman> :P
[14:05:48] <mru> cartman: sit? you mean breathe
[14:05:52] * av500 sings "the P K K too my cartman away"
[14:05:59] <cartman> LOL
[14:06:11] <cartman> soon I'll be immune to the P-word
[14:06:29] <av500> cartman: I will find words monitored by BND
[14:06:39] <cartman> BND?
[14:06:42] <kshishkov> av500: you look a bit young here - http://www.flickr.com/photos/av500/4999167638/
[14:06:45] <av500> they have a concern about the P people too
[14:07:06] <cartman> av500: what BND :)
[14:07:25] <av500> cartman: the germany CIA wannabee
[14:07:40] <cartman> it was a good idea to buy VPN from USA then
[14:08:05] <av500> from the CIA?
[14:08:25] <cartman> they possibly don't care about the Pee
[14:08:58] <av500> dont pee in their teepee
[14:09:21] <cartman> do they wiretap IRC in *.de?
[14:09:46] <av500> no need, I send them logs
[14:09:51] <cartman> av500: good idea
[14:10:09] <cartman> I'll sure mention you as my secret supporter
[14:10:37] <av500> cartman: the BND gets most of its intelligence from wikileaks
[14:10:45] <cartman> lol
[14:12:11] <cartman> at least I'll be able to listen last.fm there
[14:12:22] <cartman> only Spotify is missing and thats because of andoma somehow :p
[14:16:35] <CIA-38> ffmpeg: Maksym Veremeyenko <verem at m1stereo.tv> master * rd06497f316 ffmpeg/libavformat/nsvdec.c:
[14:16:35] <CIA-38> ffmpeg: fix nsvdec.c compilation if DEBUG defined
[14:16:35] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[14:23:18] <mru> wtf @ Compn on ML
[14:24:19] <spaam> where? :)
[14:24:30] * cartman sighs
[14:24:37] <mru> "2 weeks review time is standard operating procedure"
[14:24:49] <mru> except for certain induhviduals, apparently
[14:25:00] <cartman> back in the Lord Vader days
[14:25:03] <av500> but only after a "request for review" has been filed
[14:25:14] <mru> in triplicate
[14:25:27] <av500> and the review review committee has approved it
[14:26:34] <mru> j-b: ping
[14:26:53] <kshishkov> mru: s/except//, the rest reviews in a few days
[14:27:34] <mru> kshishkov: I meant that one person seems to be exempt from review entirely
[14:27:59] <elenril> people are still reading those?
[14:28:19] <j-b> mru: pong
[14:28:20] <kshishkov> mru: I thought you meant time it takes for dev to review incoming patch, but you're right
[14:28:33] <mru> j-b: what's your interest in the vbv patch?
[14:29:41] <j-b> mru: cmassiot is an oldie of VLC, and he has a new ts muxer for VLC, that can 'allegedly', create CBR ts, which is useful in many broadcast situations. Hence, interesting for my $day_job
[14:29:53] <mru> I see
[14:30:01] <mru> so you approve the patch?
[14:30:08] <j-b> I don't care
[14:30:15] <j-b> I just want a solution
[14:30:21] <mru> you do care, but not at that level of detail
[14:30:22] <j-b> the best
[14:30:49] <j-b> I'd like that, in the next 3 months, there is a solution.
[14:31:06] <mru> I can push it in 3 seconds...
[14:31:07] <kshishkov> j-b: next you'll ask for interlaced VC-1
[14:32:00] <j-b> mru: well, I certainly don't want something bad in FFmpeg.
[14:32:17] <mru> I think the patch is fine
[14:32:24] <j-b> see https://github.com/cmassiot/vlc-broadcast/commits/master
[14:32:49] <mru> and I assume it's good enough for christophe
[14:33:11] <j-b> mru: but to be honest, I am also interested in getting cmassiot back in the vlc dev community, as a political side
[14:33:25] <j-b> yes, I am evil©®
[14:33:32] <mru> !french
[14:33:54] <mru> <Hector4212> French are evil! ©
[14:33:59] <j-b> but I'll ask Chris to add a libavcodec/options.c something
[14:34:04] <mru> nevermind
[14:34:07] <mru> that's not needed
[14:34:17] <mru> it's a read-only field for the application
[14:34:27] <mru> adding to options.c would expose it on the command line
[14:34:36] <mru> and that would be weird to say the least
[14:35:43] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * r9806fbd535 ffmpeg/libavcodec/binkaudio.c:
[14:35:43] <CIA-38> ffmpeg: binkaudio: fix channel count check
[14:35:43] <CIA-38> ffmpeg: Perform validity check on AVFormatContext.channels instead of
[14:35:43] <CIA-38> ffmpeg: uninitialised field.
[14:35:43] <CIA-38> ffmpeg: This fixes issue 2001.
[14:35:44] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:35:50] <CIA-38> ffmpeg: Peter Ross <pross at xvid.org> master * r71f88b1f38 ffmpeg/libavcodec/binkaudio.c:
[14:35:50] <CIA-38> ffmpeg: binkaudio: remove unused copy of AVCodecContext*
[14:35:50] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:35:55] <CIA-38> ffmpeg: Christophe Massiot <massiot at via.ecp.fr> master * r55bad0c602 ffmpeg/libavcodec/ (avcodec.h mpegvideo_enc.c):
[14:35:55] <CIA-38> ffmpeg: Pass VBV delay to the calling application via ctx
[14:35:55] <CIA-38> ffmpeg: VBV delay is useful for T-STD compliance in some TS muxers. It is
[14:35:55] <CIA-38> ffmpeg: certainly possible to retrieve it by parsing the output of FFmpeg, but
[14:35:55] <CIA-38> ffmpeg: getting it from the context makes it simpler and less error-prone.
[14:35:56] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:35:57] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r8ed4cc65a1 ffmpeg/doc/APIchanges:
[14:35:57] <CIA-38> ffmpeg: APIchanges: update for 55bad0c: vbv_delay
[14:35:58] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:36:15] <kshishkov> j-b: there you are
[14:36:40] <elenril> so what's up with lavcore
[14:36:52] <kshishkov> merge it back!
[14:37:13] <siretart> ++
[14:37:26] <elenril> i mean...what are you waiting for?
[14:38:41] * Compn charges his fflames-laser
[14:39:11] <j-b> I thought it was ffdrama
[14:42:53] <lu_zero> j-b: both flavours available
[14:43:03] <lu_zero> one is bitter the other is spicy
[14:45:57] <av500> wbs: lu_zero: i find it strange that the behaviour of rtsp depends on the timing of the client
[14:46:24] <wbs> av500: that's the problem with UDP and the top-down architecture of lavf
[14:46:29] <av500> and even setting max_delay=1 for ffplay makes a huge difference
[14:46:46] <mru> architecture?
[14:46:49] <wbs> av500: the issue with max_delay on/off is that it enables a different codepath
[14:46:52] <mru> you mean house of cards
[14:46:55] <av500> ah
[14:47:10] <av500> so why does it not work from my client :(
[14:47:30] <wbs> av500: I'd love to have it set to a non-zero value by default, but since it's a general AVFormatContext field used for other things, too..
[14:48:27] <Dark_Shikari> http://nokiaplanp.com/
[14:48:38] <Dark_Shikari> http://nokiaplant.com/
[14:48:44] <Dark_Shikari> http://nokiaplanz.com/
[14:48:47] <lu_zero> wbs: uhmm
[14:48:49] <Dark_Shikari> http://nokiaplan5.com/
[14:48:51] <Dark_Shikari> I love these
[14:49:23] <bilboed-tp> you could have just linked nokiaplans.com
[14:49:27] <bilboed-tp> which links them all :)
[14:49:33] <j-b> and the 'x' one, that autogenerates
[14:52:14] * Compn vomits at all of the fixed width websites
[15:05:01] <lu_zero> Compn: are you in bad faith or you missed the other thread completely?
[15:05:25] * elenril guesses Compn just feels like trolling
[15:07:50] <mru> that's not helpful
[15:15:01] <av500> wbs: \\\ooo///
[15:15:22] <av500> wbs: turns out, getting max_delay into AVFormatContext is not so easy
[15:15:37] <wbs> av500: told you so ;P
[15:17:30] <av500> wbs: preallocing the context is not enough, one also has to provide params that says so
[15:17:35] <av500> gee
[15:32:56] <CIA-38> ffmpeg: Reinhard Tartler <siretart at tauware.de> master * r737eb5976f ffmpeg/ (120 files in 9 dirs): (log message trimmed)
[15:32:56] <CIA-38> ffmpeg: Merge libavcore into libavutil
[15:32:56] <CIA-38> ffmpeg: It is pretty hopeless that other considerable projects will adopt
[15:32:56] <CIA-38> ffmpeg: libavutil alone in other projects. Projects that need small footprint
[15:32:56] <CIA-38> ffmpeg: are better off with more specialized libraries such as gnulib or rather
[15:32:57] <CIA-38> ffmpeg: just copy the necessary parts that they need. With this in mind, nobody
[15:32:58] <CIA-38> ffmpeg: is helped by having libavutil and libavcore split. In order to ease
[15:33:37] <BBB> \o/
[15:33:54] <kshishkov> I, for one, welcome our less scattered FFmpeg
[15:33:57] <jannau> siretart: thanks
[15:34:56] <mru> \\\\\\\oooooo///////
[15:34:57] <av500> deleadered and delibraried
[15:35:02] <mru> //
[15:37:08] <JEEB> heh, I kind of wondered what libavcore was going to do in the end >_>
[15:37:22] <siretart> in case someone asks, this is the 'packaging maintenance' overhead for libavcore: http://bazaar.launchpad.net/~siretart/ffmpeg/packaging-trunk/revision/15
[15:37:29] <siretart> (just reverse the changes)
[15:40:19] <cartman> http://www.nunomonteiro.org/how-the-british-view-other-countries
[15:43:18] <mru> "Koreans are not Chinese." <-- and _certainly_ not japanese
[15:43:38] <kshishkov> mru: and Koreans invented everything long before Chinese!
[15:43:52] <JEEB> oh boy, mru -- don't step into that minefield of KOR-JPN >_>
[15:44:02] <cartman> mru: ah you are a brit!
[15:44:03] <JEEB> I don't even want to understand that beehive
[15:44:19] <mru> JEEB: it's not that complicated really
[15:44:32] <mru> china and japan have fought many wars -- in korea
[15:44:42] <mru> thus the koreans rather dislike both of them
[15:44:53] <mru> and of course they have a national pride
[15:45:05] <kshishkov> mru: Korea was Japanese colony till 1946
[15:45:13] <kshishkov> that's enough
[15:45:29] <mru> that too
[16:00:32] <Compn> lu_zero : which thread? the original review thread ?
[16:02:03] <lu_zero> exactly.
[16:03:45] <DonDiego> \o/
[16:03:55] <DonDiego> libavutil may now reign supreme :-)
[16:04:22] <KotH> ?
[16:04:30] <Compn> lu_zero : my point was that 'over my dead body' was used instead of 'here is whats wrong with the patch, copied from the earlier thread'
[16:04:56] <Compn> or even 'look at earlier thread xxxx'
[16:05:06] <mru> Compn: I've repeated the reasons why that is wrong on average once a month for the last 5 years
[16:05:25] <lu_zero> Compn: given is the same guy that discussed the issue before
[16:06:58] <Compn> why not say that on the list then ?
[16:06:58] <Compn> heh
[16:07:34] <Compn> sorry, i didnt see previous threads
[16:07:39] <Compn> my bad
[16:08:53] <lu_zero> I'd like to have the hypocrisy claim retracted please.
[16:09:39] <mru> Compn: 'over my dead body' was a stupid thing to say
[16:10:09] <KotH> mru: next time, use "over your dead body" instead ;-)
[16:10:49] <lu_zero> KotH: don't joke =P
[16:10:53] <spaam> ;P
[16:11:03] <spaam> funny KotH is not funny..
[16:11:04] <spaam> ;P
[16:11:20] <mru> joking about the death of others is rarely a good idea
[16:11:29] <mru> unless you know them very well
[16:11:37] <kshishkov> depends on society
[16:11:46] <mru> safer never to do it
[16:11:53] <kshishkov> indeed
[16:11:57] <mru> especially in an open forum
[16:12:36] <Compn> it may be illegal in some countries :p
[16:13:00] <kshishkov> Compn: in USA but not anywhere else
[16:19:03] <av500> kshishkov: nope, in usa you are not allow to say: "over your naked body"
[16:19:09] <av500> dead is fine
[16:19:51] <kshishkov> av500: that can be considered as a death threat and will induce a lawsuit
[16:23:21] <mru> expressing a wish to see someone naked can be almost as offensive as wishing to see them dead
[16:40:10] <KotH> well, if she's cute...?
[16:47:10] <mru> KotH: of course there are a number of people I'd _like_ to see naked...
[16:48:42] <KotH> mru: ask those girls whether they'd join a trip to sweden, then go to a sauna with them :)
[16:48:55] <mru> :)
[16:49:01] <mru> and yes, they are all girls
[16:49:10] <BBB> KotH: if you ask sandra bullock, she might say "no", which is kind of devastating
[16:49:48] <KotH> BBB: i dont mind... bullock is not really my type :)
[16:49:59] <KotH> mru: i'd be surprised if it would be otherwise ;-)
[16:50:55] <mru> KotH: I guess you'd know by now if it were
[16:51:26] <KotH> mru: yeah.. i know too many things about too many people...
[17:02:20] <av500> BBB: bullock is of german origin, depending where from she might sauna
[17:03:42] <av500> mru: nothing beats the look on the faces of the brits that shared a sauna with my coworker and his wife when they were in the UK
[17:03:58] <av500> they considered it "mixed"
[17:04:22] <av500> it was a new concept to the natives
[17:14:48] <siretart> av500: IIRC bullock has franconian heritage, but I may be wrong
[17:15:04] <mru> who cares about her anyway?
[17:19:19] <av500> siretart: nope
[17:19:52] <av500> "...She sang in the operas children's choir at the Staatstheater Nürnberg.[9]..."
[17:20:40] <siretart> which is the most important city in franconia :-)
[17:21:01] <av500> pah
[17:21:11] * av500 must need more coffee
[17:21:15] <av500> lots of
[17:21:18] <siretart> http://en.wikipedia.org/wiki/Franconia
[17:21:20] <siretart> :-)
[17:21:31] <av500> Franggen
[17:24:29] <pJok> http://www.blogcdn.com/www.engadget.com/media/2011/02/amd-apu-2011-02-15-600.jpg
[17:24:36] <pJok> AMD has humor
[17:29:47] * lu_zero never tried a swedish sauna
[17:30:05] <lu_zero> how is that different from a japanese one?
[17:38:53] <CIA-38> ffmpeg: Max Shakhmetov <shakhmetov.max at gmail.com> master * r9ac2085dbf ffmpeg/libavformat/os_support.c:
[17:38:53] <CIA-38> ffmpeg: os_support: fix poll() implementation
[17:38:53] <CIA-38> ffmpeg: Our poll implementation does not iterate over the pollfd array properly
[17:38:53] <CIA-38> ffmpeg: while setting the revents.
[17:38:53] <CIA-38> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[20:47:05] <mru> I filed one gcc bug and one armcc bug this week, any bets on which one gets fixed first?
[20:48:32] <_av500__> clang?
[20:48:59] <mru> none by me, don't know if someone else reported the vp8 problem
[20:51:57] <mru> speaking of bugs, http://blog.regehr.org/archives/383
[20:52:03] <mru> that guy actually seems sensible
[21:02:52] <Flameeyes> mru: likely armcc
[21:05:10] <mru> the last few bugs similar to this one took them ~50 days
[21:05:40] <Flameeyes> mru: I think I still have gcc bugs open after years
[21:05:53] <Flameeyes> and I _definitely_ still have sunstudio bugs open after years
[21:08:02] <Tjoppen_> speaking of bugs, how old are the oldest open ffbugs on roundup?
[21:08:17] <mru> nobody knows
[21:08:33] <mru> the system time has wrapped around since then
[21:08:51] <jannau> lol: from lkml http://keithcu.com/wordpress/?p=1691
[21:10:42] <spaam> höhöhö
[21:10:54] <jannau> totally incomprehensible, if I had to guess he wants the kernel reimplemted in python so that all userspace code can be converted to python
[21:11:08] <mru> who is he?
[21:11:25] <jannau> some insane person
[21:12:13] <elenril> tl;dr
[21:12:49] <jannau> ignoring that scipy uses Fortran and C libs for most of it math functions
[21:14:33] <jannau> Employment: "1993 – 2005 Software Design Engineer, Microsoft Corporation. Shipped code in Tools, Consumer, Office, Windows, Window CE, Mobile, Research, and MSN."
[21:15:03] <mru> so _that_ is the explanation for windows ME
[21:19:39] <{V}> elenril, "too long; did read" ? :)
[21:21:56] <Tjoppen_> oh, he means garbage collection
[21:22:21] <mru> probably, it self-collected before I could finish it
[21:30:17] <BBB> wbs: can you look at https://roundup.ffmpeg.org/issue2612 ? looks like a user problem to me, but I'm not sure
[21:32:21] <Flameeyes> mru: well it is in target for the garbage
[21:42:45] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r50d7140441 ffmpeg/ (3 files in 3 dirs):
[21:42:46] <CIA-15> ffmpeg: ac3enc: change default floor code to 7.
[21:42:46] <CIA-15> ffmpeg: This is to match the value in every (E-)AC-3 file from commercial sources.
[21:42:46] <CIA-15> ffmpeg: It has a negligible effect on audio quality.
[21:42:46] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:01:17] <mru> does anyone else think an option to make ffmpeg not print _any_ general chatter would be nice?
[22:02:48] <Jumpyshoes> BBB: can i have a patch that sets HAVE_AVX if yasm can assemble it?
[22:03:03] <mru> it's a two-liner
[22:03:21] <mru> Jumpyshoes: give an example of an avx instruction
[22:03:57] <Jumpyshoes> vpaddw xmm0, xmm0, xmm0
[22:05:46] <mru> http://pastie.org/1568244
[22:05:48] <mru> untested
[22:06:12] <Jumpyshoes> okay,  thanks
[22:07:58] <BBB> Jumpyshoes: mru is our local configure overlord
[22:08:34] <Jumpyshoes> BBB: i see, i'll post a patch shortly with an avx function for testing
[22:09:03] <BBB> Jumpyshoes: I'm writing vc1 stuff, see lots of potential for avx functions here :)
[22:09:34] <Jumpyshoes> anything with a mova :)
[22:09:51] <mru> BBB: need 32-bit much?
[22:10:48] <Jumpyshoes> oh, i also need to set the AV_CPU_FLAG
[22:11:03] <kurosu> were vc1 f/iDCT ever committed ?
[22:11:41] <BBB> mru: haven't tested yet, you told me I didn't need it
[22:11:56] <mru> I wrote a neon one w/o and it seems to work
[22:12:00] <BBB> kurosu: no, the functions sucked, I'm rewriting that now
[22:12:06] <kurosu> :p
[22:12:13] <mru> the specs suggested 16 bits would be enough
[22:12:21] <BBB> mru: also I'm gonna break your optimizations
[22:12:26] <mru> huh?
[22:12:32] <mru> which ones?
[22:12:34] <BBB> mru: I'm transposing the idct coefficients
[22:12:39] <mru> vp8?
[22:12:40] <BBB> mru: so the asm will need modifications
[22:12:42] <BBB> mru: no, vc1
[22:12:53] <mru> there is no neon vc1 in ffmpeg
[22:12:59] <mru> this was for a client
[22:13:02] <BBB> right
[22:13:11] <BBB> I'm just saying you need to fix them if you want to re-sell it
[22:13:12] <BBB> :-p
[22:14:17] <kurosu> the subpel interpolation functions for vc1 are indeed written for old cpus; as usual ssse3 will also improve that
[22:14:54] <mru> that interpolation is dreadful
[22:15:19] <kurosu> the way it is implemented ?
[22:16:33] <mru> the spec
[22:16:36] <mru> it's annoying to implement
[22:16:46] <mru> not quite as annoying as mpeg4-2 qpel of course
[22:19:23] <kurosu> i remember part of the non-spec compliance in ffmpeg was that the order (vertical followed by horizontal and vice versa) mattered, so, yes
[22:19:46] <kurosu> (talking only about my own limited view of the spec)
[22:20:10] <kurosu> s/mattered/was wrong
[22:20:11] <mru> vc1 is less wtf than vp8 though
[22:20:53] <kurosu> i've seen strange stuff indeed in various commits in ffmpeg
[22:21:13] <kurosu> this 129 or 127 padding iirc...
[22:21:30] <mru> (x + 63) >> 7 and such
[22:21:35] <mru> any sane person does +64
[22:21:48] <mru> cpus have an instruction that
[22:21:53] <mru> +for
[22:22:06] <mru> and they're not consistent
[22:22:29] <mru> even in the same function, they use different rounding modes
[22:22:33] <kurosu> people developping codecs in such fields hardly have any idea of what a cpu can do efficiently or not
[22:22:41] <mru> that's the problem
[22:22:51] <mru> h264 is actually nice to optimise
[22:23:14] <kurosu> maybe more with neon, which i don't know
[22:23:21] <mru> it never overflows into 17 bits and such silly things
[22:23:36] <mru> almost everything fits in 16 bits
[22:23:49] <kurosu> but for instance the strength computation for the loop filter is rather troublesome
[22:23:51] <mru> I don't remember if it ever needs more
[22:25:15] <kurosu> BBB: so what are you doing with vc1 dsp functions? rewriting them to yasm? adding sseX versions with X>1 ?
[22:25:31] <dalias> hi
[22:25:36] <BBB> kurosu: writing idct from scratch, really
[22:25:47] <BBB> kurosu: I'm profiling and going top-down
[22:25:51] <mru> hi dalias, long time no see
[22:25:55] <dalias> yes
[22:26:07] <dalias> been working on my own project, finally released :)
[22:26:15] <mru> what project is that?
[22:26:31] <dalias> libc, now called musl
[22:26:48] <mru> got a web page?
[22:26:54] <mru> how complete is it?
[22:26:57] <DonDiego> you seem to be happy about musl's release :)
[22:26:58] <kurosu> BBB: there may be potential also with subpel as it's mmx, but indeed the idct is much needed
[22:27:26] <dalias> mru, yeah, http://www.etalabs.net/musl/
[22:27:28] * mru did vc1 subpel in neon with no intermediate storage
[22:27:52] <dalias> the faq and comparison pages there answer how complete it is fairly well
[22:28:02] <BBB> kurosu: almost done with the 8x8
[22:28:20] <mru> why the name musl?
[22:28:24] <j-b> Can someone explain "The logical unit" from AVOption2 ? can it be anything?
[22:29:00] <mru> j-b: heh, that's a bit weird
[22:29:07] <dalias> mru, also in the faq :)
[22:29:10] <mru> it's for supporting symbolic names as arguments to some flags
[22:29:51] * j-b scratches his head
[22:30:15] <j-b> so far I have, "{"vbv-delay", NULL, 0, FF_OPT_TYPE_INT64, 0, 0, INT64_MAX, V|E, "27MHz_timestamp"},
[22:30:28] <mru> that's wrong
[22:30:45] <mru> the last field should be null
[22:31:07] <j-b> then NULL it is
[22:31:10] <mru> and before we add this, we should add a flag to mark things as "read-only"
[22:31:20] <mru> so they don't become command line params
[22:31:28] <mru> setting this from the command line makes no sense
[22:31:43] <j-b> it has exactly no sense, indeed
[22:31:57] <j-b> but I said: "I will make a patch tonight", so I make a patch tonight.
[22:32:03] <mru> setting such fields with av_set_foo() should also be impossible
[22:32:11] <j-b> clearly
[22:32:21] <mru> I'd just add an AV_OPT_FLAG_READONLY
[22:33:14] <lu_zero> dalias: uhm
[22:33:20] <lu_zero> which allocator do you use?
[22:33:41] <mru> lu_zero: there's a faq for that
[22:35:06] <j-b> michaelni: here should be the patch http://pastebin.com/RihwBQs3
[22:35:39] <mru> j-b: a brief comment in the second field might be nice
[22:35:53] <bcoudurier> why do you need an avoption for this ?
[22:36:07] <mru> you don't
[22:36:15] <mru> or else I'd have insisted on it
[22:36:32] <dalias> lu_zero, my own
[22:36:51] <bcoudurier> so why does j-b want to add it ?
[22:36:51] <j-b> bcoudurier: I believe we don't either. But learning I am
[22:37:04] <j-b> bcoudurier: I don't want to. I said I would do a patch for it
[22:37:08] <mru> bcoudurier: michael wants it
[22:37:11] <j-b> so, a patch I do.
[22:37:28] <bcoudurier> this is useless for fields not settable externally
[22:37:38] <bcoudurier> we'd better not add them
[22:37:48] <j-b> adding AV_OPT_FLAG_READONLY is easy, what to do with it, is different ;)
[22:37:52] <bcoudurier> and remove the wrongly added ones
[22:37:54] <bcoudurier> IMHO
[22:38:15] <mru> bcoudurier: I agree
[22:39:30] <lu_zero> dalias: dl variant... I see, did you have a look at nedmalloc?
[22:40:50] <lu_zero> or tlsf
[22:41:00] <mru> lu_zero: nih :)
[22:41:21] <dalias> lu_zero, the claims on the page were ridiculous enough that i didn't bother :)
[22:41:22] <mru> dalias: what pthread interfaces are missing?
[22:41:28] <lu_zero> mru: trying new allocators is always useful
[22:41:43] <mru> lu_zero: I've done my share of malloc testing
[22:41:55] <lu_zero> dalias: well beating windows is easy
[22:41:55] <mru> even convinced management to switch
[22:42:08] <lu_zero> tlsf seems interesting
[22:42:15] <lu_zero> mru: switch from what to what?
[22:42:23] <mru> homebrew to dl
[22:42:38] <lu_zero> dalias: I'm getting you some audience now
[22:43:04] <dalias> mru, most attributes for condition vars and rwlocks, robust and process-shared mutexes, priority scheduling
[22:43:54] <lu_zero> dalias: http://rtportal.upv.es/rtmalloc/ if you are still up to play with the concept
[22:44:02] <mru> dalias: nothing terribly important then
[22:44:19] <mru> dalias: did you once say threads were unnecessary?
[22:44:31] <dalias> mru, imo most of the missing stuff is only needed for people who want premature microoptimization :)
[22:44:33] <mru> or is my memory playing tricks on me?
[22:44:36] <dalias> yes i did
[22:44:48] <mru> what made you change your mind?
[22:44:59] <dalias> 2 things i guess
[22:45:15] <dalias> one, i decided since thye're a mandatory part of modern posix i should implement them whether i like them or not
[22:45:17] <mru> I'll be the first to agree threading is abused far too much
[22:45:27] <dalias> and two, i discovered that i could make them insanely efficient
[22:46:02] <dalias> my thread creating and joining, without any cacheing hacks like glibc does, is roughly the same speed, and as cheap as a couple io syscalls
[22:46:25] <mru> nice
[22:46:40] <dalias> and using threads doesn't even pull in malloc if you don't otherwise use it
[22:46:44] <mru> of course, if thread creation is a performance issue, the app is horribly misdesigned
[22:47:09] <dalias> i would say the same about if malloc is a performance issue :)
[22:47:14] <mru> +1
[22:47:19] <dalias> but plenty of ppl think it is..... :/
[22:47:25] <mru> and memcpy
[22:48:03] <dalias> actually my fav thing about my malloc is that it can return memory to the os from anywhere in the heap, not just the top
[22:48:14] <mru> depends on the os I guess
[22:48:38] <dalias> at present it does not reduce the commit charge, just the dirty count
[22:48:58] <dalias> but i could make it reduce the commit charge too with a little more complexity and time cost
[22:49:05] <lu_zero> dalias: is your allocator usable as is?
[22:49:09] <dalias> yeah
[22:49:18] * lu_zero as a certain exa implementation that could try new tricks...
[22:49:22] <mru> btw, do you know what all that code in glibc actually does?
[22:49:22] <lu_zero> has
[22:49:29] <dalias> but it would take some _minor_ work to rip it out and use it independently
[22:49:36] <mru> the posix spec isn't _that_ big...
[22:49:39] <dalias> mru, :)
[22:49:43] <mru> and most of it is syscall wrappers
[22:50:06] <dalias> the biggest bloat components in glibc are stdio and locale
[22:50:17] <dalias> stdio is implemented as C++ iostream, written in C
[22:50:33] <dalias> they actually make it have compatible struct layout in C with the C++ class
[22:50:59] <lu_zero> why that?
[22:51:00] <dalias> and thus it's way more complex than it needs to be
[22:51:14] <dalias> because they like C++ i guess.... ;-)
[22:51:34] <lu_zero> the only reason I could think is to make C++ slightly faster
[22:51:44] <dalias> it probably does do that
[22:51:48] <mru> c++ needs to die
[22:51:53] <mru> the sooner, the better
[22:52:34] <lu_zero> mru: well we might have lost Qt as side effect of nokia->ms
[22:52:56] <mru> heh
[22:53:13] <lu_zero> what else is making C++ more useful than annoying?
[22:53:24] <j-b> lu_zero: the internal infos I have are not saying that
[22:53:37] <lu_zero> j-b: which plan now?
[22:53:42] <lu_zero> B or Z ?
[22:53:46] <j-b> lu_zero: except UI and strings management? nothing. C++ is annoying
[22:54:02] <j-b> C++ has things that let you bazooka your foot
[22:54:15] <j-b> and C++ lets you write unmaintainable code
[22:54:23] <dalias> the lack of good gui tools in C is what makes C++ attractive to ppl, imo
[22:54:28] <mru> c++ makes writing bad code _really_ easy
[22:54:31] <lu_zero> any language beside python does
[22:54:31] <dalias> :)
[22:54:38] <lu_zero> dalias: check evas/elementary
[22:54:45] <mru> bad code can be written in any language
[22:54:56] <j-b> dalias: and string management
[22:55:03] <lu_zero> the comment before was referred to j-b's one
[22:55:13] <dalias> string management in C is a lot easier than ppl give credit for
[22:55:21] <mru> +1
[22:55:27] <dalias> it's just that ppl wantto apply broken, inefficient string processing idioms from script languages to C
[22:55:38] <dalias> concatenation is *NOT* a sane string processing idiom
[22:55:47] <lu_zero> dalias: was about to ask that
[22:55:53] <j-b> lu_zero: yes, and at work I force python and a subset of C++ using Qt
[22:56:03] <mru> concatenation is very rarely what you really want to do
[22:56:06] <lu_zero> j-b: ^^;
[22:56:07] <dalias> it leads to O(n^2) time, even *without* the null-terminated/C-string issue
[22:56:12] <lu_zero> pyside or the other monster?
[22:56:13] <dalias> due to reallocation
[22:56:31] <lu_zero> dalias: what would you do?
[22:56:36] <dalias> snprintf
[22:56:42] <lu_zero> ...
[22:56:43] <dalias> and build the string all in one step
[22:56:44] <j-b> a UI has a lot of string manipulations, asprintf and concatnateion
[22:56:58] <dalias> asprintf is fine too
[22:57:18] <lu_zero> asprintf doesn't look that light
[22:57:19] <michaelni> bcoudurier, j-b, we want the AVOption because if fork1 appends field guessed_pts to AVCodecContext and fork2 doesnt but then appends fieldX then both are ABI incompatible unless you access through av_set/get* that is AVOptions
[22:57:51] <j-b> lu_zero: it isn't light
[22:57:57] <dalias> it sure can be
[22:58:07] <dalias> asprintf+all deps is <10k in musl
[22:58:15] <lu_zero> michaelni: and obviously you want guessed_pts even if what code should live better in avutils...
[22:58:23] <lu_zero> s/what/that/
[22:58:43] <j-b> dalias: for simple programming and when people don't need perfs for strings, concatenation is nice. str* are a mess for those cases
[22:58:46] <michaelni> lu_zero, maybe, maybe not, my point is we wont always agree i fear even if we agree now
[22:58:46] <mru> if you don't need the formatting facilities, a few strlen, strcpy, and some pointer maths will do the trick
[22:59:48] <lu_zero> mru: wrapping them in nicer abstraction is usually what happens then
[22:59:53] <michaelni> and it costs very little to add a line per field to the AVOption table...
[23:00:00] <dalias> mru, yeah and instead of a 1-time cost of snprintf&deps, you have 5 or 6 function calls to strlen, memcpy, etc. every time you build a string :)
[23:00:18] <dalias> sure you could make your own wrapper and abstraction
[23:00:19] <michaelni> j-b, about the patch, the flags would cause it to be outputted in the help output i think
[23:00:33] <j-b> michaelni: ok, so what should I do?
[23:02:23] <michaelni> #define new flag in libavutil/opt.h, use that and omit such flaged fields from show_help_options() output
[23:02:40] <michaelni> should be 4 lines of code or so
[23:02:50] <mru> and have av_set_*() reject it too
[23:03:12] <michaelni> mru, i dont understand ?
[23:03:15] <j-b> 4 lines of code in FFmpeg is way more difficult :)
[23:03:31] <mru> michaelni: it makes no sense to set that field through av_set_string and friends
[23:03:37] <michaelni> yes
[23:03:49] <michaelni> but other (future) fields for them it can make sense
[23:03:54] * lu_zero notices that the whole thing growing
[23:04:20] <mru> I was suggesting a "readonly" flag
[23:04:28] <mru> meaning the library user should only read the field
[23:04:35] <mru> that fits the semantics of this one
[23:04:37] <michaelni> mru thats a good idea as well
[23:04:57] <michaelni> what i was thinking of was more a "internal_for_abi" flag
[23:05:18] <mru> the vbv delay field should be read by the user, just not written
[23:05:31] <mru> internal things don't belong in public structs at all
[23:06:04] <michaelni> ok, bad name then ...
[23:07:16] <michaelni> maybe "non_user_field/option" but it doesnt sound terrible great either
[23:07:42] <mru> for now readonly fits the need and makes general sense
[23:08:22] <mru> that would apply to all existing "set by lavc" fields too
[23:09:35] <michaelni> yes, but many are "set by user" on the other side (encoder vs decoder)
[23:10:02] <michaelni> its maybe just encoder status output stuff ...
[23:11:29] <DonDiego> gnite
[23:14:22] <dalias> lu_zero, i almost wonder if nedmalloc is just SEO spam
[23:14:42] <dalias> it doesn't seem to do anything revolutionary
[23:16:39] <Dark_Shikari> http://nokiaplan0.com/
[23:19:17] <lu_zero> dalias: I hadn't tried it yet
[23:19:32] <saintdev> lol they added "Profit!" to the Plans page
[23:19:33] <lu_zero> tlsf seems sound
[23:22:09] <dalias> :)
[23:23:13] <kierank> ruggles: why do you use a bs_id of 8 when everyone else uses 6?
[23:23:22] <kierank> (sorry if you ended up answering this after i left)
[23:23:47] <ruggles> hi kierank. i saw the question but didn't answer because you were gone.
[23:24:34] <ruggles> 6 is for alternative bitstream syntax, which we don't support yet.
[23:24:39] <ruggles> it would still work, but not needed.
[23:25:09] <kierank> it's only that little metadata section right, replacing timecode with other options?
[23:25:48] <ruggles> yes. and using bsid 6 is part of my AVOptions patch, which i still have to revise before resubmitting.
[23:25:53] <kierank> ah
[23:26:07] <ruggles> since that patch will allow writing that little extra metadata
[23:29:31] <dalias> lu_zero, you know anyone who might could do an arm port of musl?
[23:29:53] <mru> are you paying? :)
[23:30:13] <dalias> its basically just implementing 4 or 5 asm functions and getting all the bits and syscall header stuff right
[23:30:19] <dalias> haha
[23:30:39] <mru> how much work do you estimate it is?
[23:31:38] <dalias> a few hours unless you get stuck debugging something that doesn't want to work :)
[23:31:58] <mru> hmm, I might look into it if nobody beats me to it
[23:34:53] <j-b> something like that  http://pastebin.com/8jjPKtDa then?
[23:40:56] <mru> j-b: av_set_string3() needs the same check
[23:41:40] <lu_zero> dalias: is there something that could be used as template?
[23:41:41] <j-b> mru: of course, all of them
[23:41:50] <j-b> mru: but is it something like that that is needed?
[23:41:56] <dalias> the i386 or x86_64 versions of the asm :)
[23:41:59] <mru> j-b: yes
[23:42:14] <mru> j-b: I think set_number2 and set_string3 cover all paths
[23:42:21] <lu_zero> where are them?
[23:42:27] <mru> dalias: no gitweb?
[23:42:35] <dalias> find -name i386
[23:42:50] <dalias> mru, not yet, will do soon.
[23:43:00] <dalias> i just started learning git a few days ago
[23:43:09] <michaelni> j-b, (ignoring set_string*), this implements what mans suggested though this is solving a slightly different problem
[23:43:23] <j-b> michaelni: oh?
[23:43:32] <michaelni> i mean we have a fork/ABI issue and not a someone writes in read only fields issue
[23:43:45] <mru> this solves both problems
[23:44:01] <michaelni> it only solves the ABI issue for read only fields
[23:44:12] <mru> the field we're talking about _is_ readonly
[23:44:21] <mru> and there's currently no way of saying so
[23:44:22] <michaelni> yes, by coincidence
[23:44:38] <lu_zero> michaelni: better a good solution than no solution I think ^^
[23:44:43] <j-b> michaelni: I have 2 patches, one on libavcodec/options.c adding the vbv_ thingie. One on libavutil/opt.* about readonly thingiie
[23:44:56] <mru> this adds a way of describing the semantics of the field, _and_ provides an abi-safe way to access the field
[23:44:59] <lu_zero> dalias: the atomic ops couldn't be lifted?
[23:45:46] <michaelni> lu_zero, mru  will will still need a flag for read/write fields ...
[23:45:52] <mru> read/write avoption access to non-commandline fields can be addresssed when we require it
[23:46:23] <j-b> http://pastebin.com/qtfMT25H and http://pastebin.com/6EtUGwHv
[23:46:29] <michaelni> ohh well, why easy when one can solve it complexly and obfusacted
[23:46:39] <mru> you call this obfuscated???
[23:46:59] <lu_zero> calm mru
[23:47:00] <mru> I've rarely seen a simpler patch, and it perfectly describes the field semantics
[23:47:01] <Compn> lu_zero : you know the vote is just to give everyone commit access right ?
[23:47:03] <michaelni> j-b, V|E looks bad
[23:47:12] * Compn reads log
[23:47:40] <j-b> michaelni: then back to the docs I am :)
[23:47:41] <michaelni> mru, it solves only half the ABI issue, namely only for readonly fields
[23:47:49] <michaelni> j-b, you need the new flag in there
[23:48:05] <michaelni> that readonly flag
[23:48:33] <mru> maybe should have A as well, on the off-chance some audio encoder would want to use it
[23:49:24] <j-b> A|V|AV_OPT_FLAG_READONLY then?
[23:49:36] <j-b> michaelni: indeed, makes sense
[23:49:39] <michaelni> and E IIRC
[23:49:47] <michaelni> encooder that is
[23:49:53] <mru> of course E
[23:50:14] <j-b> http://pastebin.com/BVXFG9Cs
[23:50:31] <michaelni> LGTM
[23:50:44] <mru> perhaps the comment could be less verbose
[23:51:26] <michaelni> ahh bikeshedimg ...
[23:51:39] <j-b> if I actually knew what vbv-delay was, I could help :)
[23:51:50] <mru> reading the spec now...
[23:52:19] <kierank> it's the amount of time that should be spent buffering before the decoding of the first frame
[23:52:21] <j-b> For constant bitrate operation, the vbv_delay 14is used to set the initial occupancy of the decoder's buffer at the start of play so that the decoder's buffer does not overflow or underflow. The vbv_delay measures the time needed to fill the VBV buffer from an initially empty state at the bitrate, R, to the correct level immediately before the current picture is removed from the buffer.
[23:53:18] <michaelni> j-b, thats better then whats in the patch ;)
[23:53:35] <Sean_McG> wow... epic commits lately
[23:53:49] <kierank> michaelni: I have done that sports karaoke thing before
[23:53:59] <j-b> michaelni: a bit long, ain't it?
[23:54:06] <michaelni> j-b, :)))
[23:54:43] <j-b> and I still have 0 understanding of what that means, but well. I'll read the doc another day
[23:55:04] <iive> j-b: i think i may have an idea.
[23:55:45] * michaelni thinks its the time to wait when you start before playback starts aka buffer fill time
[23:55:47] <iive> j-b: wanna hear it now?
[23:55:53] <j-b> iive: sure
[23:56:01] <mru> what michaelni said
[23:56:29] <mru> for realvideo the value is infinity
[23:56:40] <j-b> "get the 'buffer fill time' in periods of 27Mhz clock" for the help then?
[23:56:54] <mru> I'd drop the "get the"
[23:56:54] <kierank> j-b: that implies the whole buffer is being filled which is not necessarily true
[23:56:55] <iive> j-b: ok. first case. you want to start playing something. you must take it from the buffer, but the buffer is completely empty.
[23:57:00] <Dark_Shikari> listing the buffer fill time is impossible for VFR video
[23:57:03] <Dark_Shikari> because you don't know future timestamps
[23:57:12] <Dark_Shikari> you can list the number of BITS you need to fill, iirc.
[23:57:23] <Dark_Shikari> (referring to _decoding_ and reading HRD data, here)
[23:57:34] <j-b> iive: yes
[23:57:34] <Dark_Shikari> ... though that could be converted to time.
[23:57:36] <iive> j-b: so you have to pre-buffer some data, before you want to start playback.
[23:58:20] <j-b> kierank: indeed. Better idea for wording?
[23:58:31] <iive> j-b: then, you remove packets from it, as you play them.
[23:58:57] <iive> if you remove them too fast, it would underflow...
[23:58:58] <kierank> j-b: initial buffer fill time
[23:59:19] <mru> sounds good
[23:59:26] <michaelni> yes
[23:59:54] <j-b> http://pastebin.com/Y2J9DBge then