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

[irc at mansr.com]

[00:34:54] <CIA-90> ffmpeg: mru * r21952 /trunk/libavcodec/arm/ (mdct_neon.S dsputil_armv6.S): ARM: add missing preserve8 directives
[00:34:55] <CIA-90> ffmpeg: mru * r21953 /trunk/libavutil/arm/bswap.h:
[00:34:56] <CIA-90> ffmpeg: ARM: change argument/return type of bswap_16() to unsigned 32-bit
[00:34:56] <CIA-90> ffmpeg: This avoids unnecessary masking otherwise added by the compilers.
[00:34:56] <CIA-90> ffmpeg: mru * r21954 /trunk/configure:
[00:34:56] <CIA-90> ffmpeg: Revert "Suppress icc warnings about unknown attributes"
[00:34:56] <CIA-90> ffmpeg: This reverts r21884. Apparently people want those warnings.
[00:34:57] <CIA-90> ffmpeg: michael * r21955 /trunk/libavformat/avc.c: Attempt to fix the completely random values returned by ff_avc_find_startcode().
[02:57:28] <ramiro> how should I deal with a timestamp discontinuity in an audio grabbing device?
[02:57:43] <mru> what's the source of the timestamps?
[02:58:09] <mru> and why is it discontinuous?
[02:58:09] <ramiro> there are no timestamps. =(
[02:58:37] <mru> if they don't exist, how can they be discontinuous?
[02:58:39] <ramiro> it's the windows waveform api. we give the api x buffers so it may record sound in them.
[02:58:53] <ramiro> if all is going right, we get the buffers back one by one, and the data is continuous
[02:59:12] <ramiro> but if the buffers fill up, we lose data.
[02:59:36] <ramiro> when we get a new buffer, there's no way to tell its timestamp, how much it differed from the last buffer.
[02:59:37] <mru> do you know how much data you lost?
[03:01:35] <ramiro> I was thinking of getting system time every time the data is lost. but that way ffmpeg is garbling up the sound. I'd expect the exact amount of delay between one and the other as silence, but that's now what I get...
[03:01:44] <ramiro> that's not
[03:02:15] <mru> using system time is generally not a good idea
[03:02:31] <mru> do you get any indication how much you lost?
[03:02:39] <mru> or just that something was lost?
[03:02:55] <ramiro> no, there's no indication on how much was lost. not even an indication that something was lost.
[03:03:25] <ramiro> but if we are holding all buffers, it's sure to be data loss.
[03:03:27] <mru> then the best you can do is probably to pretend it doesn't happen
[03:03:28] <Dark_Shikari> mru: does ARM have population count?
[03:03:35] <mru> Dark_Shikari: no
[03:04:15] <mru> there's a neon vector population count
[03:04:31] <ramiro> there is one function to get the time and number of bytes spent recording, but that function must not be called from the callback, so it's kind of useless.
[03:04:38] <mru> works only on 8-bit elements
[03:05:27] <mru> Dark_Shikari: why do you ask?
[03:06:28] <Dark_Shikari> random discussion on some other channel, wondering which archs had one
[03:06:35] <Dark_Shikari> seems ultrasparc, alpha, cray did
[03:07:02] <mru> blackfin has
[03:07:19] <ohsix> doesn't v6 have a popcnt?
[03:07:40] <mru> armv6?
[03:08:09] <ohsix> ya
[03:08:18] <mru> v5 has clz
[03:08:26] <mru> I don't see a popcount anywhere
[03:08:30] <ohsix> ah that might have been what i was thinking of
[03:15:01] <RTFM_FTW> a number of GPUs (i.e. anything D3D11 compliant for example) offer a "population count" instruction (or something equivalent) as well
[03:37:29] <ShadowJK> does v6 have clz?
[03:37:43] <mru> yes
[03:37:46] <mru> v5 and later
[03:40:42] <mru> nothing has been removed
[03:40:49] <mru> swp has been deprecated
[03:41:13] <mru> in favour of new, better instructions
[04:33:18] <ramiro> is there a way to instruct ffmpeg to output each channel to a different file?
[04:33:43] <mru> don't think so
[04:34:10] <ramiro> hmm, is there at least a way to specify that I only want one audio channel? (and not by resampling, by ignoring the others)
[04:39:34] <peloverde> both of those would be useful
[04:40:59] <pentanol> hello, looks weird, but here... static int rtmp_open(URLContext *s, const char *uri, int flags) uri pointer not used
[04:57:12] <peloverde> Did people see the january 2010 zzuf report?
[05:08:37] <troy_s> Can anyone in here tell me how to dump a still image frame from an x264 stream using rec709 instead of the implied 601?
[05:08:55] <troy_s> I've tried -colorspace 4, but it still seems to be trunking the output.
[05:12:13] <astrange> does the zzuf report include backtraces or just the files?
[05:12:25] <troy_s> (as in the 16-235 crunch. That is what I seek to avoid and bring everything into 0-255 if at all possible)
[05:14:00] <astrange> it sounds like a problem with the input, with no colorspace conversion it won't clip anything
[05:14:38] <troy_s> astrange: Not the case.
[05:14:46] <troy_s> astrange: I believe it is a well documented issue with swscale
[05:15:14] <troy_s> astrange: In that it, in short, thrusts 601 on output (not so much 601 but more the 16-235 clamp)
[05:15:58] <astrange> you can try yuvj420p, i guess. don't know if swscale implements that
[05:16:00] <troy_s> astrange: I am pretty sure Dark_Shikari and Yuvi know the issue, but I am curious if there is a way for me to get a full 0-255 still image from it in some lossless format. I'd be elated if that were the case.
[05:16:14] <troy_s> astrange: Sorry... explain please?
[05:16:49] <pentanol> hm, I should do mux\demux stream if i needed proxying rtsp stream to rtmp?
[05:17:20] <astrange> try using -pixfmt yuvj420p for input and output. but now that i think about it, that probably can't be controlled from the cli either
[05:17:55] <Yuvi> it can for raw yuv
[05:18:06] <astrange> pix_fmt too
[05:18:33] <troy_s> Yuvi: Sorry... idiot here.. Is there a way to pull full 0-255 out of the file then?
[05:19:08] <pentanol> u.e. I need convert AVFormatContext or ByteIOContext to URLContext?
[05:19:28] <Yuvi> out to what? rgb or yuv? (yuv should just work unless some conversion is involved, but it might not be marked as such)
[05:20:26] <troy_s> Yuvi: As in assuming I have an x264 MOV here with 0-255 defined, can I pull a still frame out of it (say PNG) with that full 0-255?
[05:20:41] <troy_s> Yuvi: So yeah, YUV starting point.
[05:21:28] <troy_s> Yuvi: Because I tried -colorspace 4 -i in.mp4 out.png and (probably my fault) spit out a PNG (after complaining) that is still 16-235 clamped.
[05:23:03] <pentanol> copying ByteIOContext *pb; to void *priv_data; should be okay?
[05:23:12] <pentanol> and work properly?
[05:23:21] <troy_s> Yuvi: (And thank you for your time)
[05:25:36] <pentanol> anyone?
[05:26:49] <Yuvi> troy_s: try http://pastebin.ca/1805431 I think
[05:27:11] <troy_s> Yuvi: Wow.
[05:27:16] <troy_s> Yuvi: Is that in SVN?
[05:28:31] <Yuvi> no, it didn't really work for rgb -> yuv for colorspace, and I didn't look into whether swscale had support for that
[05:28:56] <troy_s> Yuvi: So going from YUV to RGB (x264 to PNG in this case) can work?
[05:29:46] <Yuvi> as long as you used --fullrange (or add --color_range 2 to ffmpeg)
[05:30:09] <troy_s> Yuvi: So I need to add that patch before it will work?
[05:30:14] <Yuvi> yeah, I
[05:30:21] <troy_s> Yuvi: Or can I svn up and have it without breaking my SVN?
[05:30:31] <Yuvi> 'll ping the thread to see if it's okay to half-fix the issue ignoring rgb -> yuv
[05:30:57] <troy_s> Yuvi: You rock Yuvi thank you immensely. I'd love to see some sort of workaround hack in SVN.
[05:32:51] <troy_s> Yuvi: I don't suppose RGB to YUV is easily tackled without tackling the larger issue of colourspace agnostic manipulations?
[05:33:27] <troy_s> Yuvi: Because in essence here we are dealing with colourspace conversion, which would imply that ffmpeg is working in a platonic colorspace and bumping out to a known paradigm, no?
[05:35:06] <Yuvi> there's no internal ffmpeg colorspace, it doesn't change from the source unless doing an rgb <-> yuv conversion
[05:35:34] <Yuvi> or range if going from 0-255 <-> 16-235
[05:35:39] <troy_s> Yuvi: Right... which then I guess implies a colorspace, correct?
[05:36:15] <troy_s> Yuvi: So I guess the follow up question is - is there a REC709 implementation that also clamps 16-235?
[05:36:18] <Yuvi> yes, and it'll be tagged wrong (or untagged) most of the time
[05:36:43] <Yuvi> rec709 and 16-235 are orthogonal
[05:36:55] <troy_s> Yuvi: Hrm... I tried patch -p0 < patch and it gagged. Did I miss something completely obvious?
[05:37:00] <Yuvi> -p1
[05:37:07] <troy_s> Yuvi: Grok.
[05:48:40] <troy_s> Yuvi: Is it possible that CONFIG_BINK_DECODER isn't defined?
[05:49:43] <elenril> make clean?
[05:50:28] <troy_s> elenril: Tried it. Grepp'd and didn't see it pop up other than in that file.
[05:50:45] <troy_s> elenril: Reverted to 20 revisions prior and it seems fine.
[06:32:51] <pentanol> kshishkov there?
[06:32:58] <kshishkov> no, here
[06:33:15] <jai> *slow clap*
[06:33:15] <jai> ;)
[06:33:41] <kshishkov> jai: you people clap with with single hand
[06:33:48] <jai> O_O
[06:34:17] <kshishkov> yes, and then ask everybody else how it sounds
[06:36:43] <pentanol> I guess you may point me with mux\demuxing stream which comes from rtsp to rtmp...
[06:37:08] <kshishkov> you need to recode it
[06:39:22] <pentanol> hm, right, then rtmp accept only URLContext, also there... void *priv_data; should be data? or where?
[06:40:02] <kshishkov> priv_data is private data used only by protocol handler
[06:42:31] <pentanol> rtmp_write(URLContext *h, uint8_t *buf < there? buf must be for payload?
[06:43:00] <kshishkov> no, RTMP protocol accepts only FLV
[06:45:02] <pentanol> anyway some where should be buffer asigned for paylosd data, where it's?
[06:45:13] <pentanol> assigned*
[06:46:12] <kshishkov> it's not protocol worry - you feed it FLV data, it publishes it to server
[06:52:46] <benoit-> good morning
[06:53:38] <Dark_Shikari> kshishkov: er, but doesn't the rtmp server demux the flv file?
[06:53:42] <Dark_Shikari> and present it in RTMP format?
[06:54:25] <kshishkov> yes, and FFmpeg client does the same
[06:54:36] <kshishkov> when publishing to RTMP server
[06:54:52] <Dark_Shikari> yeah, but if we had an RTMP server
[06:54:56] <Dark_Shikari> it could take input from anything in ffmpeg right?
[06:55:37] <kshishkov> RTMP is tied to FLV and its codecs
[06:56:20] <Dark_Shikari> it's tied to its codecs yes
[06:56:25] <Dark_Shikari> but why couldn't ffmpeg turn an mp4 into rtmp?
[06:57:07] <kshishkov> theoretically it can
[06:57:46] <kshishkov> RTMP server should accept simple audio and video streams and mux them itself
[07:13:33] <pJok> mornings
[07:13:47] <kshishkov> goda morgnar
[07:14:20] <pJok> kshishkov, be glad you are not in stockholm and need to get to work today
[07:15:57] <kshishkov> oh yeah,  you don't know what goes here
[07:17:42] <pJok> they promise about half  a meter of snow
[07:17:50] <pJok> in southern sweden
[07:18:01] <kshishkov> ours is accumulated
[07:18:24] <kshishkov> so we have both mountains of snow, ice and water
[07:18:51] <pJok> fun
[07:18:59] <pJok> sounds like snow hell
[07:19:08] <kshishkov> sounds like Ukraine
[07:19:57] <kshishkov> and local street cleaning services were hired from Africa - they don't know what to do with snow and officially declared that it will melt in spring so no problem
[07:20:41] <pJok> awesome
[07:21:45] <kshishkov> yes
[07:22:09] <pJok> and thats quite far away to hire cleaning services from...
[07:22:41] <kshishkov> well, they look like Russians but judging from the way they think...
[07:23:39] <kshishkov> I've heard some roofs are collapsing because of snow as well
[07:23:49] <KotH> moin
[07:24:07] <kshishkov> gruss dich
[07:25:34] <_av500_> dobro jutro
[07:25:46] <pJok> yeah, quite a lot of roofs in sweden have collapsed
[07:25:47] <kshishkov> I hope it's so for you
[07:26:10] <kshishkov> pJok: and we _didn't_ have heavy snowfalls here
[07:27:22] <pJok> most of the heavy snow was in middle sweden
[07:27:37] <_av500_> middle earth?
[07:27:40] <pJok> yes
[07:27:48] <pJok> midgard
[07:27:54] <pJok> which is in ängelholm
[07:28:08] <pJok> along with valhalla
[07:28:21] * _av500_ knows sweden from blue/yellow stores
[07:28:37] * kshishkov blev på Valhallavägen
[07:30:03] * kshishkov blev på alla fyra svenska landsdelar också
[07:30:29] <pJok> :)
[07:33:22] <superdump> does anyone have 11172-2?
[07:34:01] <_av500_> 11170?
[07:34:13] <kshishkov> ISO 11170
[07:35:18] <superdump> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22411
[07:35:26] <superdump> so i don't mean that?
[07:35:53] <superdump> i think i do
[07:35:58] <jai> superdump: http://www.neuron2.net/library/mpeg1/
[07:36:02] <jai> thats mpeg1
[07:36:03] <superdump> 11170 is about hydraulics
[07:36:21] <superdump> thanks jai
[07:36:23] <jai> np
[07:36:26] <_av500_> superdump: so excuse  lame joke
[07:36:31] <astrange> btw the graphs in those files don't render in word for mac
[07:36:33] <astrange> i have some pdfs
[07:37:57] <jai> abiword seems to do them fine iirc
[08:58:24] <pentanol> pokes kshishkov , if I haven't rtsp in Enabled protocols list, it's means I forgot live555 linking? but rtmp there...
[09:23:25] <jonwil> hi
[09:24:12] <jonwil> I have some video clips in Bink format that have some small issues when played back with the new Bink decoder. What should I do with these files?
[09:24:33] * Dark_Shikari pings kshishkov 
[09:28:55] <pross-au> Hey Mr Wilson
[09:31:51] <jonwil> hi
[09:33:10] <jonwil> 2010 is only just begun and already FFMPEG  has added a couple new codecs/formats :)
[09:33:26] <jonwil> maybe 2010 will be the year that some much-wanted codecs enter FFMPEG
[09:33:34] <pross-au> Like what?
[09:33:38] <pross-au> EALayer3?
[09:33:56] <pross-au> VP7?
[09:34:04] <Dark_Shikari> WVP2
[09:34:07] <jai> VP8 ftw
[09:34:08] <Dark_Shikari> is the most wanted imo
[09:34:20] <Dark_Shikari> wm speech was big, but that's in now
[09:34:24] <Dark_Shikari> SBR is very big and wanted
[09:34:28] <pross-au> mp3pro
[09:34:31] <Dark_Shikari> Dolby E will be very nice to get
[09:34:35] <jai> lol mp3pro
[09:35:10] <pross-au> jai: we need that for completeness
[09:35:28] <jonwil> EALayer3 is my #1 most wanted IMO
[09:35:31] <jai> pross-au: we can bug Vitor for that :)
[09:36:11] <Dark_Shikari> we have twinvq
[09:36:14] <Dark_Shikari> which was even more useless than mp3pro
[09:36:26] <jonwil> what is wvp2?
[09:36:36] <Dark_Shikari> it's the most common video format that we don't have
[09:36:45] <Dark_Shikari> according to a few tens of millions of videos logged while I was at facebook
[09:36:55] <pross-au> video camera?
[09:36:58] <Dark_Shikari> it's a Windows Media format that has embedded info about slideshow stuff, etc
[09:37:05] <Dark_Shikari> Windows Media Screen Video 2 or whatnot
[09:37:13] <Dark_Shikari> it's used by Windows Movie Maker afaik
[09:37:17] <jonwil> ok
[09:37:28] <jonwil> Do we have the codec that MSN uses to send webcam data?
[09:38:09] <jai> yep. its called mimic or sth
[09:38:24] <Dark_Shikari> lol, mimic
[09:38:34] <jonwil> Webcam support in 3rd party MSN clients would be nice :P
[09:38:53] <jonwil> I am surprised that no-one bothers to support voice/video in 3rd party clients
[09:39:17] <jai> surely they welcome patches
[09:39:37] <merbzt> jai: can you play sitar like this guy http://www.youtube.com/watch?v=erLZ-zW9Ti4 ?
[09:40:50] <jai> merbzt: not really, though i can play a bunch of beatles' songs ')
[09:41:08] <merbzt> awesome :)
[09:41:35] <jai> also, indian instruments are usually more expensive here
[09:47:30] <pross-au> somebody mention bink benchmarking yesterday. how does it fair?
[09:48:02] <CIA-90> ffmpeg: cehoyos * r21956 /trunk/libavcodec/Makefile: Fix compilation for --enable-version3 --enable-libopencore_amrwb (only).
[09:48:51] * Dark_Shikari mentioned it
[09:50:20] <Dark_Shikari> hmm.  shit.  I need to sign extend values in an simd reg.
[09:50:31] <Dark_Shikari> I have X 0 Y 0 (words)
[09:50:41] <Dark_Shikari> and I need to turn this into X Y (doublewords, 32-bit)
[09:50:47] <Dark_Shikari> but X and Y can be signed
[09:50:55] <Dark_Shikari> so the 0s need to become -1s if necessar
[09:50:56] <Dark_Shikari> *necessary
[09:50:58] <Dark_Shikari> what's a good way to do that
[09:51:24] <Dark_Shikari> hmm, or I could use packusdw, which is sse4 only
[09:51:49] <Dark_Shikari> ... but I'm using mmx.
[09:51:50] <Dark_Shikari> no packusdw.
[09:57:19] <kshishkov> why have some people mentioned Bink?
[09:57:19] <jonwil> ok, so what do I do with these bink videos that have problems in ffmpeg?
[09:57:36] <kshishkov> report to me and I'll work on that
[09:57:36] <Dark_Shikari> send them to kshishkov
[10:00:04] <KotH> send me chocolate
[10:00:13] <KotH> swiss chocolate
[10:00:28] <kshishkov> and Emmenthal?
[10:02:18] <elenril> morning people
[10:03:02] <jonwil> where do I send this bik file kshishkov?
[10:03:55] <Kovensky> morning elenril
[10:04:08] <Kovensky> KotH: would be easier if we were in .ch
[10:04:14] <Kovensky> (which obviously means .chocolate)
[10:04:58] <merbzt> jonwil: mplayer samples archive
[10:05:40] <elenril> so the usual question -- anybody wants to apply a few patches for me?
[10:06:29] <jonwil> mplayer samples archive is where?
[10:06:30] <elenril> or even better -- anybody wants to give me commit rights? ;)
[10:07:12] <merbzt> I'll say yes to that
[10:07:20] <jonwil> also, is there any kind of size limits on samples?
[10:07:37] <merbzt> 10mb ish should be ok
[10:08:00] <Kovensky> the preference is that they should be just small enough to replicate the problem
[10:08:14] <jonwil> well I have 3 that all show the problem, one is 3.26mb
[10:08:19] <jonwil> one is 27.9mb
[10:08:23] <jonwil> and one is 32.1mb
[10:08:38] <jonwil> As far as I know other than this one problem with playing the first few frames too fast, they play just fine
[10:09:06] <jonwil> I cant see any artifacts vs playing them in the rad game tools player
[10:09:15] <jonwil> should I upload the 3.26mb one then?
[10:09:32] <merbzt> upload them all
[10:09:43] <Kovensky> yea, they're not scary like 10GB samples :)
[10:10:05] <pross-au> hardly a 'sample'
[10:10:17] <Kovensky> indeed\
[10:10:24] <jonwil> where do I upload them then?
[10:10:33] <merbzt> samples.mplayerhq.hu
[10:10:36] <Kovensky> incoming.mplayerhq.hu/samples IIRC
[10:10:42] <Kovensky> or was it samples.mplayerhq.hu/incoming? =p
[10:10:45] <Kovensky> ftp://
[10:10:51] <pross-au> jonwil: go to ffmpeg.org and READ the BUG REPORTS page...
[10:11:10] <jonwil> ok, will read that
[10:11:18] <pross-au> Kovensky: upload IIRC
[10:13:42] <pross-au> kshishkov: i have some problematic files too
[10:14:34] <KotH> Kovensky: it's not my fault that you dont live in chocolate country
[10:15:15] <Kovensky> KotH: :(
[10:15:31] <KotH> Kovensky: jump into the next train and come here
[10:15:31] <jonwil> Definatly good job to everyone involved in cracking Bink
[10:15:47] <Kovensky> >train
[10:15:54] <Kovensky> :D
[10:16:02] <jonwil> Just make sure all the work is legally clean so that Rad Game Tools cant sue you :P
[10:16:16] <KotH> and if they sue us?
[10:16:24] <pross-au> [binkvideo @ 0x95c2e60]Unknown block type 10 :D
[10:16:52] <KotH> i have yet to see one company who actually sues us
[10:17:00] <KotH> many have threatened us
[10:17:03] <KotH> none sued
[10:17:13] <jonwil> true
[10:17:19] <jonwil> but RGT makes money off their codec
[10:17:39] <KotH> so does On2 or any of the others
[10:17:41] <_av500_> sue who?
[10:17:47] <elenril> KotH
[10:17:50] <pross-au> stop speculating jonwil. focus your energy on something positive
[10:17:57] <elenril> he's the most evil here
[10:17:59] <jonwil> :)
[10:18:02] <_av500_> sue the svn server...
[10:18:07] <Dark_Shikari> jonwil: so does everyone
[10:18:08] * KotH kicks elenril for his lazyness
[10:18:27] <Dark_Shikari> the only possible lawsuit RGT could put out is a patent lawsuit
[10:18:32] <Dark_Shikari> and I don't recall that RGT is a patentmonger
[10:19:05] <KotH> beside, it would be very difficult to sue based on a software patent in a country that does not recognize software patents
[10:19:06] <merbzt> we can always fallback on interoperability
[10:19:16] <Dark_Shikari> nobody has ever sued ffmpeg over an RE'd codec
[10:19:25] <Dark_Shikari> Real has threatened anyone who _used_ ffmpeg
[10:19:27] <Dark_Shikari> but they won't sue
[10:19:33] <Dark_Shikari> because they know they can't, no legal basis
[10:19:37] <_av500_> no sense to sue source code, you sue the users...
[10:19:40] <jonwil> my wishes for FFMPEG in 2010 would be support for EALAYER3 (en and decode) and encode support for the VP6 video with EA ADPCM audio .vp6 files of Red Alert 3
[10:19:43] <Dark_Shikari> can't sue users, I mean
[10:20:03] <Dark_Shikari> jonwil: why the hell would we want vp6 encode support?
[10:20:05] <Dark_Shikari> it's a dead format
[10:20:22] <jonwil> The reason its usefull is that Red Alert 3 uses it for video clips
[10:20:26] <_av500_> vp3 + vp6 = vp9!!!
[10:20:31] <jonwil> so being able to encode new video clips for RA3 mods would be nice
[10:20:35] <Dark_Shikari> use on2's encoder
[10:20:36] <CIA-90> ffmpeg: michael * r21957 /trunk/libavformat/utils.c:
[10:20:36] <CIA-90> ffmpeg: Make sure a set r_frame_rate is not overriden by a guess.
[10:20:36] <CIA-90> ffmpeg: Also make sure we dont waste time in this case with collecting timestamps.
[10:20:48] <merbzt> jonwil: you can encode to vp6 via the vfw encoder
[10:21:08] <jonwil> hmmm I guess so, that doesnt help with the audio though
[10:21:16] <Kovensky> my wish for ffmpeg in 2010 is alpha channel support in ffvhuff and ffv1 =p
[10:22:24] <jez9999> Hmm, can I get this straight: in order for ffmpeg not to complain "Compiler did not align stack variables. Libavcodec has been miscompiled", you need a bleeding-edge version of gcc.  Yet, you still support gcc 2.95?
[10:22:42] <jonwil> what platform?
[10:22:51] <jez9999> Windows
[10:22:56] <Dark_Shikari> jez9999: --disable-sse
[10:23:03] <Dark_Shikari> gcc 2.9.5 is "supported"
[10:23:06] <Dark_Shikari> and 4.2 is hardly "Bleeding edge"
[10:23:10] <Dark_Shikari> I mean, 6 years old is not really bleeding edge
[10:23:15] <pross-au> vp6 encoder...
[10:23:19] <jez9999> hmm cusiour how MSYS doesnt come with it
[10:23:23] <jez9999> *curious
[10:23:26] <Dark_Shikari> what?  msys has gcc 4.4
[10:23:38] <Dark_Shikari> unless you're using some insane ancient version
[10:23:42] <jez9999> for some reason i have 3.4.5
[10:23:48] <jez9999> and i only downloaded it recently
[10:23:48] <Kovensky> Dark_Shikari: "official" MSYS probably comes with lolold stuff
[10:23:48] <jez9999> weird
[10:24:03] <Dark_Shikari> I don't know anyone who uses 3.4 on msys
[10:24:07] <Dark_Shikari> I use 3.4 on cygwin due to :lazy:
[10:24:26] <jez9999> 'gcc version 3.4.5 (mingw-vista special r3)
[10:25:12] <Dark_Shikari> welcome to 7 years ago
[10:25:59] <merbzt> jez9999: it should be safe to run a 3.4 compiled ffmpeg, it should not crash might just run abit slower
[10:26:10] <Dark_Shikari> merbzt: wrong
[10:26:21] <jez9999> i dont get how i managed to download that old version in the last week :-)
[10:26:23] <Dark_Shikari> movdqa on unaligned data -> CRASH
[10:26:29] <Dark_Shikari> jez9999: old releases
[10:27:31] <merbzt> Dark_Shikari: I know but I haven't seen a bugreport regarding that for ages
[10:27:53] <merbzt> most buffers are moved to the heap
[10:28:06] <jez9999> "Latest official release of GCC from the MinGW project is GCC 3.4.5. "
[10:28:08] <jez9999> heh
[10:28:10] <jez9999> that might explain it
[10:28:26] <Dark_Shikari> jez9999: it's called a dead projects
[10:28:31] <Dark_Shikari> *project
[10:28:34] <Dark_Shikari> sometimes you have to update away from the dead project
[10:28:51] <jez9999> what, gcc 3.4.5 or msys?
[10:29:25] * jai uses tdm's builds for windows testing
[10:29:42] <Kovensky> and you don't really need mingw gcc anyway
[10:29:49] <Kovensky> almost everything from them has been merged back upstream
[10:30:07] <jai> some people dont want to waste time building gcc
[10:30:18] <Dark_Shikari> msys
[10:30:28] <jai> in this case, there are decent precompiled binaries available
[10:30:41] <jez9999> i had no idea msys was a dead project
[10:30:47] <Dark_Shikari> well, anything still stuck on gcc 3.4
[10:30:49] <jez9999> people still recommend it for windows builds
[10:30:50] <Dark_Shikari> is a dead project
[10:30:52] <Dark_Shikari> whether they claim so or not
[10:30:53] <Dark_Shikari> ;)
[10:30:56] <jonwil> will be interesting to see what Google does with On2 VP8 now that they own it.
[10:31:07] <Dark_Shikari> jonwil: probably nothing.  I'm guessing they bought on2 for some patent leverage
[10:31:14] <jai> eh, msys is just an environment
[10:31:20] <Dark_Shikari> and yeah, that
[10:31:26] <Dark_Shikari> you can update the gcc separate of the environment
[10:31:27] <merbzt> Dark_Shikari: and the engineers
[10:31:29] <jai> i assume you are complaining about mingw's default gcc
[10:31:31] <Dark_Shikari> merbzt: that too
[10:31:33] <jez9999> yup
[10:31:43] <jez9999> i need an independent build of gcc?
[10:31:57] <jai> either use "technology previews" from mingw or tdm's builds
[10:32:22] <jonwil> some people have said that it makes sense for Google to open up VP8 as a replacement for H.264 so that they no longer need to buy H.264 licenses for YouTube and Chrome
[10:32:34] <Dark_Shikari> jonwil: not useful
[10:32:34] <jez9999> gnu.org recommends using Cygwin or MinGW
[10:32:41] <Dark_Shikari> mobile devices
[10:32:44] <Dark_Shikari> iphone, etc
[10:32:58] <Dark_Shikari> youtube wants to have a single global video formats that works on everything
[10:33:01] <Dark_Shikari> *format
[10:33:10] <Dark_Shikari> also, they don't pay a cent for youtube
[10:33:28] <Dark_Shikari> and for chrome, the price of licenses is cheaper than the price of the disks to store the duplicate copies of every single video
[10:33:47] <Dark_Shikari> and "some people" aren't saying that, "FSF" is saying it . Don't talk like Fox News.
[10:34:02] <jonwil> its not just FSF, others have speculated the same
[10:34:03] <pross-au> who cares about open-source VP8, i want the dll first
[10:34:07] <jonwil> but yeah I see the point
[10:34:12] <Dark_Shikari> FSF and their mouthpieces, ok
[10:34:27] <Dark_Shikari> Now, I would not be totally shocked if they _did_
[10:34:42] <Dark_Shikari> but I highly doubt they will try to switch youtube over
[10:34:45] <Dark_Shikari> too expensive
[10:35:12] <Dark_Shikari> then again, google is known for starting "wars" with every company on earth
[10:35:26] <Dark_Shikari> and putting their fingers in everyone's pies
[10:35:29] <Dark_Shikari> so who knows.
[10:35:29] <jonwil> another point someone raised is that they may open it and get support for it in browsers in case the MPEGLA threatens per-view fees for H.264
[10:35:42] <Dark_Shikari> well, h264 is free until 2016 at a minimum
[10:35:44] <Dark_Shikari> so that's quite far off atm
[10:36:27] <pross-au> h265 will be out by then
[10:36:31] <Dark_Shikari> lol
[10:36:44] <pross-au> the hype will be out, at least
[10:37:36] <jonwil> I wonder if we will ever see the world adopt a "free" (as in free of patents) video codec for mainstream web use
[10:37:50] <Dark_Shikari> VP8 is sure as hell not free
[10:38:03] <jonwil> not now it aint
[10:38:07] <Dark_Shikari> no, it won't be ever
[10:38:12] <Dark_Shikari> Remember when microsoft released WMV9 as VC-1?  They claimed it was royalty-free etc etc
[10:38:19] <Dark_Shikari> 3 months later, a dozen companies pop up claiming patents on it
[10:38:24] <Dark_Shikari> 3 months later, there's a VC-1 equivalent of MPEG-LA
[10:38:27] <jonwil> true
[10:38:32] <Dark_Shikari> This shit happens every time.
[10:38:33] <jonwil> that never occurred to me
[10:38:47] <jonwil> thats why we need to keep fighting to see software patents gone
[10:38:51] <Dark_Shikari> exactly
[10:38:57] <Dark_Shikari> you cannot solve the problem by creating "patent-free formats"
[10:39:00] <jonwil> ok, uploaded the samples that show the problem in ffmpeg
[10:39:02] <Dark_Shikari> you can only solve it by eliminating patents wholesale
[10:39:04] <jonwil> what do I do now?
[10:39:06] <Dark_Shikari> or at least software patents
[10:39:57] <jonwil> also, if this happened for VC-1 how come no-one challenged Vorbis with patents to shut that down?
[10:41:28] <Dark_Shikari> 1) audio is less patent-covered than video
[10:41:29] <pross-au> jonwil: next step is to ship a carton of Swan Lager to the ukraine, then wait for the patch to be applied.
[10:41:31] <Dark_Shikari> 2) almost nobody cares about vorbis
[10:41:49] <Dark_Shikari> last I heard there were still rumors of submarine patents on vorbis
[10:42:10] <Dark_Shikari> also, the difference is probably also in who's involved
[10:42:13] <pross-au> Dark_Shikari: didnt know subs dived that low
[10:42:14] <Dark_Shikari> i.e. microsoft releases vc-1
[10:42:27] <Dark_Shikari> everyone knows microsoft has money
[10:42:33] <jonwil> yeah, MS and Google are good targets
[10:42:34] <Dark_Shikari> so they tell microsoft "we have patents on your stuff"
[10:42:39] <jonwil> XIPH are not
[10:42:42] <Dark_Shikari> but who are you going to sue with vorbis?  xiph obviously not
[10:42:44] <Dark_Shikari> you'd sue the users
[10:42:49] <Dark_Shikari> and you'd have them sign an NDA that says they can't tell anyone they were sued
[10:43:04] <Dark_Shikari> There's currently a DVD patent troll going around suing every single DVD maker
[10:43:10] <Dark_Shikari> charging $20 per unit for license fees or something
[10:43:19] <Dark_Shikari> they sue one at a time, and after the settlement, they require that you don't talk about it
[10:43:37] <Kovensky> lol?
[10:43:48] <Dark_Shikari> this prevents people from banding together to oppose them
[10:43:57] <jonwil> ok, so if patents are so evil, how do we actually get change (or at least the kind of change that eliminates patent trolls and bunk patents whilst allowing the legit patents)
[10:44:23] <Dark_Shikari> 1) move to france
[10:44:25] * Dark_Shikari runs
[10:44:25] <Kovensky> who gets to decide whether the patent is a troll, bunk or a real one
[10:44:32] <Kovensky> Dark_Shikari: lolfrance
[10:44:40] <Dark_Shikari> the EU patent rules say that patents on "computer programs" are prohibited
[10:44:50] <Dark_Shikari> so 1) move away from the US 2) ??? 3) profit
[10:44:56] <jonwil> for "bunk" you tighten the rules that grant patents
[10:45:00] <Dark_Shikari> note this doesn't cover hardware implementations
[10:45:06] <Dark_Shikari> getting rid of software patents won't get rid of video coding patents
[10:45:10] <Kovensky> though indeed, the only reason we have the patent shitstorm is because of eagleland
[10:45:14] <Dark_Shikari> but you can certainly get rid of patents on software implementations
[10:45:34] <jonwil> so that the definition of whats patentable goes back to what it was in the pre-electronics age
[10:46:17] * Kovensky still saddens when he remembers that nobody makes true force feedback joysticks anymore because some random company claims patents on it
[10:46:24] <jonwil> Any patents on mathematical algorithms (implemented in software or hardware) should be prohibited IMO
[10:46:46] <Dark_Shikari> hardware implementation patents are less of an issue though
[10:46:52] <Dark_Shikari> if you're making an ASIC, you can generally afford to pay license fees
[10:47:09] <jonwil> I will file a FFMPEG bug report for the bink bug
[10:47:11] <jonwil> is that the best thing to do?
[10:47:14] <Dark_Shikari> yes
[10:47:33] <jonwil> ok
[10:49:58] <Kovensky> Dark_Shikari: Fridge Logic time: how do you know about the DVD patent troll if all victims are required to not talk about it
[10:50:41] <Dark_Shikari> someone who violated the rules obviously
[10:53:18] <Kovensky> Dark_Shikari: and why would that stop the hipothetical vorbis victims then
[10:55:46] <Dark_Shikari> generally people don't talk about it publicly at least
[10:55:47] <Dark_Shikari> maybe in private
[10:55:52] <Dark_Shikari> and anyways, I doubt there's a troll going around for vorbis
[10:55:58] <Dark_Shikari> we _would_ probably hear about it eventually
[10:56:03] <jonwil> ok, bug report created :)
[10:56:54] <_av500_> m$ uses vorbis and they have nice wma patents that prolly cover vorbis too
[10:57:11] <jonwil> where does Microsoft use Vorbis?
[10:57:26] <_av500_> some games i think
[10:57:47] <Dark_Shikari> probably not games they make, just ones they publish
[10:57:58] <merbzt> halo uses vorbis
[10:58:05] <Dark_Shikari> heh
[10:58:08] <Dark_Shikari> bungie is pretty independent though.
[10:58:26] <Kovensky> they used to make games for macos before moving to the xbox ._.
[10:58:28] <_av500_> well, m$ would have told em not to use  it
[10:58:54] <_av500_> if they feared patents...
[10:59:08] <_av500_> but as i believe they have the patents :)
[11:00:36] <Dark_Shikari> :)
[11:01:34] <_av500_> wma and vorbis fft foo seem similar and m$ has patents
[11:01:44] <jonwil> anyhow, YAY for Bink Video in FFMPEG
[11:02:14] <jonwil> my wish is that I had the skills to help with EALayer3 :(
[11:02:18] <kshishkov> jonwil: I'm downloading samples, will look at them in several minutes
[11:02:20] <jonwil> or any codec for that matter
[11:02:23] <jonwil> ok, great
[11:02:40] <Dark_Shikari> my real question is why anyone would want to make videos for something as crappy as red alert 3
[11:02:43] * Dark_Shikari ducks
[11:02:48] <jonwil> lol
[11:02:55] <jonwil> there are some good mods for C&C3/RA3
[11:03:04] <jonwil> the best of which is Mid-East Crisis 2
[11:03:11] <jonwil> which is good enough to be a standalone game in its own right
[11:03:14] <Dark_Shikari> EA games: because the only way to get anything good out of the games is to mod them to be less shit.
[11:03:28] <Dark_Shikari> and so the mods need cutscenes?
[11:03:40] <jonwil> not necessarily cutscenes
[11:03:40] <kshishkov> yes
[11:03:45] <jonwil> but intro movies and other things
[11:03:58] <kshishkov> FMV is FMV by any other name
[11:04:08] <jonwil> Also btw I see what might be artifacts in R_L08.bik
[11:04:13] <jonwil> but I dont know if those are FFMPEG bugs
[11:04:17] <jonwil> or present in the source video
[11:04:24] <jonwil> mostly around the mouths of various people talking
[11:05:08] <kshishkov> if they are like several wrong dots on non-straight edges then it's likely to be FFmpeg artifact
[11:05:24] <jonwil> dont know
[11:05:27] <jonwil> you can take a look anyway
[11:05:35] <jonwil> and see if you see anything that could be a FFMPEG issue :)
[11:06:06] <kshishkov> jonwil: there's an official player, you know
[11:06:13] <jonwil> yes I did use that
[11:06:20] <jonwil> but the artifacts were small and it was hard to tell
[11:08:43] <kshishkov> jonwil: is it yours - R_Intro and ea_ww ?
[11:08:44] <jez9999> ugh!
[11:09:03] <jez9999> tdm's mingw builds fuck apache ant!
[11:09:17] <jez9999> Malformed \uxxxx encoding, it's not converting windows backslashes in the path
[11:09:20] <jez9999> stupid thing
[11:09:27] <jonwil> R_Intro and EA_WW are from a mod I am involved with
[11:09:58] <kshishkov> they seem to play fine here
[11:10:45] <jonwil> wierd then
[11:10:50] <jonwil> maybe something is wrong with my build?
[11:11:42] <pross-au> SDL?
[11:11:59] <jonwil> using the latest SDL from the SDL homepage
[11:12:08] <jonwil> also, this time issue happens if I convert with ffmpeg
[11:12:16] <jonwil> as well as if I play
[11:12:22] <pross-au> latest isnt always the greatest (except for ffmpeg)
[11:12:50] <jonwil> since the problem happens even if I convert, it cant be SDL at fault
[11:13:24] <pross-au> what are you playing it backw ith?
[11:13:29] <jez9999> Why would the official MinGW convert Windows path separators to /, but tdm's builds not do so?
[11:13:56] <jai> jez9999: look at the build configuration for tdm builds
[11:14:19] <jez9999> build configuration?  i'm installing it using a setup
[11:14:36] <jai> jez9999: i meant the gcc build configuration
[11:15:02] <kshishkov> yep, verified - plays fine on x86 too
[11:15:04] <jez9999> what am i looking for?
[11:16:52] <jonwil> Lets see if the built at http://ffmpeg.arrozcru.org/autobuilds/ can play it properly
[11:17:16] <jez9999> jai: what am i looking for?
[11:18:00] <jonwil> nope, those build also fail
[11:18:18] <kshishkov> what message?
[11:18:30] <jonwil> no message
[11:18:45] <jonwil> what I see when I play the video clip is that the first few frames of the video play faster than the rest of the video
[11:18:57] <jonwil> when the official player plays them all at the slower speed
[11:20:01] <jonwil> Going to see if 21957 helps
[11:20:12] <jonwil> that one isn't in the prebuilt binary
[11:21:28] <kshishkov> can be demuxer problem
[11:22:18] <kshishkov> or player - try newest MPlayer build as well
[11:22:36] <jonwil> the problem happens whether I use ffplay
[11:22:40] <jonwil> or whether I convert with ffmpeg
[11:24:23] <jonwil> can anyone else confirm if they are or arent seeing the problem I see?
[11:24:31] <kshishkov> still, good chance it may be demuxer then
[11:24:48] <pross-au> Ye
[11:24:51] <pross-au> Yep
[11:24:57] <jonwil> so you see it also?
[11:25:16] <pross-au> No i am working on the dct audio regression
[11:25:26] <jonwil> ok
[11:25:29] <pross-au> (binkaudio_dct)
[11:27:24] <jai> jez9999: http://www.tdragon.net/recentgcc/devel.php
[11:27:37] <jai> jez9999: "Includes a patch which corrects backslash usage in header paths and fixes path problems when debugging."
[11:28:15] <jez9999> seems to be a problem with apache Ant
[11:28:36] <jez9999> the official msys gives me a /home/xyz style path for pwd
[11:28:47] <jez9999> the tdm command prompt gives me a windows path
[11:28:50] <jez9999> like C:\...
[11:28:56] <jez9999> that fucks up the build
[11:28:58] <jai> i misinterpreted your question then
[11:29:19] <jai> use msys with tdm then
[11:30:17] <jez9999> erm
[11:30:26] <jez9999> i see
[11:34:04] <jonwil> so how do I find out more about why these files wont play/convert properly?
[11:34:19] <jonwil> Or should I wait and let the guys who know what they are doing do something about it? :P
[11:35:04] <jonwil> Although waiting for the binkaudio_dct issue to be fixed would help too
[11:35:11] <jonwil> since these videos all use binkaudio_dct :P
[11:35:27] <jai> jonwil: send pross-au some beer
[11:35:48] <jonwil> lol, I have no money to do that :P
[11:36:03] <jai> heh
[11:36:14] <kshishkov> send him a rabbit then ;)
[11:36:24] <jai> lolbunnies?
[11:36:25] <jonwil> blame the economic crisis for the lack of jobs in my neck of the woods
[11:43:00] <mru> kshishkov: where did those ape neon patches of yours go?
[11:43:10] <kshishkov> nowhere
[11:43:30] <mru> where's the latest version?
[11:43:48] <kshishkov> http://shishkov.homeunix.net/int_neon.patch
[11:48:33] <mru> kshishkov: mind if I do some minor fixups and commit?
[11:49:23] <kshishkov> not at all!
[11:54:27] <mru> kshishkov: q4-q7 are callee-saved
[11:54:59] <kshishkov> oh
[11:55:50] <mru> I'm fixing it
[11:55:58] <mru> and a couple of other minor things
[11:57:37] * kshishkov begins to like MIPS approach more
[11:58:03] <mru> which?
[11:58:14] <kshishkov> for saving registers
[11:58:33] <mru> mips also has mixed caller- and callee-saved regs
[11:58:38] <mru> which is how it should be
[11:59:26] <Dark_Shikari> oh wow, I figured out why firefox was crashing every 3 days
[11:59:32] <Dark_Shikari> it hit 2GB of memory usage and OOM'd
[11:59:37] <mru> made by mozilla?
[12:00:13] <mru> my firefox is only at 366M at the moment
[12:00:30] * kshishkov is on the box with 512 MB RAM
[12:14:29] * elenril facepalms
[12:15:09] <elenril> Codec Name Length: Specifies the number of Unicode characters stored in the Codec Name field.
[12:15:23] <elenril> can this be any more braindead?
[12:15:42] <kshishkov> yes
[12:15:58] * elenril somehow doubts it
[12:16:07] <kshishkov> for example, using fixed size
[12:16:23] <KotH> kshishkov: actually, that would be more intelligent
[12:16:28] * elenril agrees
[12:16:44] <kshishkov> this reminds me of Pascal-style strings
[12:16:45] <mru> fixed size?
[12:16:54] <mru> oh
[12:16:54] <kshishkov> yes, like DOS names
[12:17:04] <mru> my mind was still on registers
[12:18:23] <kshishkov> hmm, "FSF urges Google to free future Theora 2"?
[12:18:30] <mru> lol
[12:18:51] <KotH> kshishkov: sauce?
[12:19:00] <Dark_Shikari> lol vp8
[12:19:03] <mru> is this the mother of all clusterfucks or what?
[12:19:06] <kshishkov> KotH: /.
[12:19:07] <KotH> kshishkov: and BP style strings are not that bad
[12:20:35] <mru> there we go
[12:21:08] <elenril> how do tell how many characters are there anyway
[12:21:14] <mru> count them
[12:21:18] <elenril> do we have a unicode-aware strlen?
[12:21:22] <CIA-90> ffmpeg: mru * r21958 /trunk/libavcodec/ (arm/dsputil_init_neon.c arm/int_neon.S Makefile):
[12:21:22] <CIA-90> ffmpeg: ARM: NEON scalarproduct_int16 and scalarproduct_and_madd_int16
[12:21:22] <CIA-90> ffmpeg: Patch by Kostya, minor fixes by me.
[12:21:24] <CIA-90> ffmpeg: kostya * r21959 /trunk/libavcodec/bink.c:
[12:21:24] <CIA-90> ffmpeg: Correct bundle lengths calculation for small Bink files.
[12:21:24] <CIA-90> ffmpeg: This fixes issue 1764.
[12:29:41] <CIA-90> ffmpeg: stefano * r21960 /trunk/cmdutils.c:
[12:29:41] <CIA-90> ffmpeg: Make opt_default() print an error message and exit if the option
[12:29:41] <CIA-90> ffmpeg: supplied is not recognized.
[12:29:43] <mru> hmm, I don't see anything actually calling scalarproduct_int16
[12:30:30] <mru> in ape decoder
[12:30:58] <mru> the only 2 calls are in acelp_pitch_delay.c
[12:31:59] <mru> ah, r20739
[12:36:01] <CIA-90> ffmpeg: kostya * r21961 /trunk/libavcodec/bink.c:
[12:36:01] <CIA-90> ffmpeg: Make Bink decoder to stop decoding planes after all bits are used.
[12:36:01] <CIA-90> ffmpeg: This prevents crashes during decoding grayscale Bink files like
[12:36:01] <CIA-90> ffmpeg: samples from Impossible Creatures game demo.
[12:36:35] <jonwil> good to see more progress on bink :)
[12:36:46] <jonwil> I need to find more things with bink video in them and see what happens...
[12:40:00] <mru> from gcc documentation: "Unfortunately, I have forgotten why this was so, and I don't know whether it is still true."
[12:40:07] <Dark_Shikari> on what topic
[12:40:16] <mru> machine descriptions
[12:40:25] <mru> "may also be a need to support fixed point `movm' instructions in and out of floating point registers."
[12:40:39] <kshishkov> jonwil: list of games using Bink is available
[12:41:00] <jonwil> I need to look through my own collection for bik files
[12:41:09] <jonwil> I cant even remember half of what I own
[12:42:53] <Dark_Shikari> kshishkov: it's about 5000 miles long
[12:44:18] <kshishkov> Dark_Shikari: first entry are for 1C games which are in Russian, so you won't see them
[12:44:35] <jonwil> ok, Diablo II bink files play just fine
[12:45:00] <Dark_Shikari> kshishkov: it breaks hard on civilization 4 movies
[12:45:07] <Dark_Shikari> like, seriously hard
[12:45:31] <Dark_Shikari> on the 2K intro movie, it goes too fast at the start, then goes slow to catch up with itself, then locks up at the end of the video (ffplay)
[12:45:42] <Dark_Shikari> the intro goes all weird
[12:45:44] <kshishkov> ok, ask jonwil to fix it
[12:45:53] <jonwil> lol, why ask me?
[12:46:01] <jonwil> I know nothing about Bink or Bink codecs
[12:46:14] <Dark_Shikari> for that matter, ffplay is just crashing all ovefr
[12:46:20] <Dark_Shikari> I wonder if this is an unrelated issue
[12:46:33] <kshishkov> samplesarewelcome
[12:46:33] <Dark_Shikari> yeah, if I click on the playback window in ffplay, it locks up
[12:46:40] * kshishkov has stopped on Civ II
[12:46:51] <kshishkov> ah, that's seeking issue - ask Peter
[12:47:10] <Dark_Shikari> why would clicking on it cause it to seke?
[12:47:12] <Dark_Shikari> *seek
[12:47:37] <kshishkov> that's known FFplay feature
[12:47:40] <kshishkov> documented too
[12:47:52] <Dark_Shikari> lol
[12:48:05] <Dark_Shikari> uploading the 2K intro sequence
[12:48:16] <Dark_Shikari> beyond locking up at the end and the speed issue, it works fine
[12:48:20] <Dark_Shikari> no artifact
[12:50:58] <Dark_Shikari> kshishkov: http://www.mediafire.com/?bg2m12ihjnm
[12:51:02] <Dark_Shikari> 2K intro from Civilization 4
[12:51:06] <Dark_Shikari> now to test on some other files.
[12:51:54] <Dark_Shikari> everything locks up at the end of the file in ffplay.
[12:52:10] <jonwil> yes I noticed the same thing on my clips
[12:52:15] <jonwil> the lockup at end of file
[12:52:25] <jonwil> I got one game that uses BINK only to play some startup logos (wierd)
[12:52:31] <Dark_Shikari> oh, I should try Starcraft
[12:52:56] <Dark_Shikari> yeah, everything has the lock up at end + speed issue
[12:53:17] <Dark_Shikari> oh wait, starcraft uses smacker, not bink
[12:53:17] <jonwil> tried with C&C Renegade, Diablo II and some logo movies from Tron 2.0
[12:53:24] <Dark_Shikari> is there a smacker decoder?
[12:53:34] <jonwil> and so far nothing has crashed
[12:55:11] <kshishkov> Dark_Shikari: you could have sent those two kilobytes more easily
[12:55:25] <Dark_Shikari> two kilobytes?
[12:55:27] <Dark_Shikari> it's 3 megabytes
[12:55:34] <kshishkov> you said 2K
[12:55:38] <Dark_Shikari> ....
[12:55:42] <Dark_Shikari> it's the intro for 2K Games
[12:55:42] <Dark_Shikari> lol
[12:56:04] <Dark_Shikari> tested Medieval Total War: works
[12:56:09] <Dark_Shikari> tested Psychonauts: works
[12:56:14] <kshishkov> Dark_Shikari: guess who implemented Smacker decoder for FFmpeg ;)
[12:56:20] <Dark_Shikari> (all of the same problems as mentioned before, but no new ones)
[12:56:27] <kshishkov> but I've not REd it completely
[12:57:24] <Dark_Shikari> Mass Effect: works but no audio.  I'm guessing there's just no audio in the file and they handle it separately
[12:57:56] <kshishkov> FFplay prints streams available
[12:58:25] <Dark_Shikari> how
[12:58:33] <jonwil> hmmm, I wonder if this copy of Riven has Bink video
[12:58:40] <jonwil> oh wait no, thats QuickTime :P
[12:58:43] <Dark_Shikari> ffplay -h prints nothing
[12:58:47] <Dark_Shikari> "ffplay" prints nothing
[12:58:54] <Dark_Shikari> ffplay filename shows the video, but prints nothing
[12:59:17] <kshishkov> old FFplay? Current ones print the same info as FFmpeg
[12:59:24] <Dark_Shikari> more like ffplay is broken on windows
[13:00:00] <twnqx> is the "sed s/author/artist/g" patch for mov/m4a already in? :X
[13:00:01] <Dark_Shikari> Modern Warfare 2: works
[13:00:03] <kshishkov> ah, std{out,err} do not work well with windows and SDL
[13:00:32] <Dark_Shikari> Borderlands: works
[13:00:40] <Dark_Shikari> Dragon Age: works
[13:01:36] <Dark_Shikari> lol @ games using bik for still images
[13:01:59] <kshishkov> or for music like Tony Hawk Sakter
[13:03:10] <Dark_Shikari> Jade Empire: works
[13:03:24] <Dark_Shikari> Left 4 Dead: works
[13:03:26] <Dark_Shikari> Team Fortress 2: Works
[13:07:04] <jonwil> slowly working down my pile of "games that may have bik files" :)
[13:07:20] <jonwil> enter the matrix and RCT dont have them
[13:07:23] <Dark_Shikari> I just grepped my entire drive
[13:07:31] <mru> don't they usually sport a bink logo on the cover if they use it?
[13:07:37] <kshishkov> they do
[13:07:46] <kshishkov> (unless it's pirate release)
[13:07:49] <mru> I have a pile of bluray games
[13:07:55] <mru> unfortunately I can't read the discs
[13:07:59] <twnqx> magic: the gathering online has bink files iirc
[13:08:13] <twnqx> haven't started it for years though
[13:10:47] <Dark_Shikari> Neverwinter Nights: works
[13:12:52] <Dark_Shikari> damn, that game had a cool intro
[13:13:14] <KotH> Dark_Shikari: put it online itno our samples collection :)
[13:13:24] <Dark_Shikari> I have so many fucking biks it's not funny
[13:13:32] <Dark_Shikari> if I did that with all of them there'd be like 10 gigs
[13:13:34] * kshishkov has only Icewind Dale intro
[13:13:36] <jonwil> ok, Red Alert 2 works
[13:13:38] <Dark_Shikari> it doesn't compress very well you know
[13:13:49] <kshishkov> with Bink or with x264?
[13:13:50] <KotH> Dark_Shikari: i dont mind an additional 10g of samples, if they are well sorted ;)
[13:13:55] <Dark_Shikari> kshishkov: with bink
[13:14:06] <Dark_Shikari> KotH: my upload is 50KBps
[13:14:21] <Dark_Shikari> and last I recall people were complaining about incoming running out of disk space
[13:14:33] <KotH> Dark_Shikari: well.. i can solve taht issue :)
[13:14:39] <kshishkov> Dark_Shikari: it won't be in incoming
[13:14:45] <kshishkov> for long at least
[13:14:46] <Dark_Shikari> oh I have a better idea
[13:14:51] <Dark_Shikari> I'm going to grep the entire Mudd network for bik files
[13:15:00] <KotH> mudd?
[13:15:03] <Dark_Shikari> my college
[13:15:10] <Dark_Shikari> we have a network search engine that searches samba shares
[13:15:16] <KotH> lol
[13:15:22] <KotH> talk about privacy :)
[13:15:33] <kshishkov> "shares"
[13:15:50] <mru> he didn't say "hacks into machines and indexes private data"
[13:15:51] <Dark_Shikari> KotH: you choose what you share
[13:15:58] <Dark_Shikari> it's intended for movies, music, games, etc
[13:16:19] <_av500_> mru: just the public exams.doc are enough usually
[13:16:25] <kshishkov> mru: not so advanced search engine ;)
[13:17:01] <jonwil> RA2 definatly works
[13:17:09] <Dark_Shikari> Splinter Cell: works great
[13:17:29] <jonwil> and has no bink logo on the disk FYI
[13:17:57] <Dark_Shikari> "Shadow Wars"
[13:18:00] <Dark_Shikari> works great
[13:18:17] <Dark_Shikari> ... or not
[13:18:21] <Dark_Shikari> oh wow, instant crash on the main intro
[13:19:06] <Dark_Shikari> yup, found a crash in bink!
[13:19:29] <jonwil> Dungeon Siege has binkw32.dll
[13:19:34] <jonwil> but I cant find out how to get at the bink files
[13:19:42] <Dark_Shikari> kshishkov: two bugs for you, in one file!
[13:20:08] <Dark_Shikari> Bug 1: [binkvideo @ 00d988a0]DC value went out of bounds: -54566 --> CRASHHHH
[13:20:16] <jonwil> aha, movies must be on the other disk :P
[13:20:17] <kshishkov> jonwil: could be in some archives like Heroes of Might and Magic III
[13:20:25] <Dark_Shikari> It's a bink file from an actual game, so I would suspect the file is valid
[13:20:33] <Dark_Shikari> Bug 2: [binkaudio_dct @ 010d8c50]reported data size (480) does not match output data si
[13:20:33] <kshishkov> it may
[13:20:37] <Dark_Shikari> ze (7680)
[13:20:45] <kshishkov> that's standard, ignore it
[13:20:57] <Dark_Shikari> fix it
[13:20:57] <Dark_Shikari> =p
[13:21:07] <jonwil> nope, nothing there, bink must be in resource files I cant get at
[13:21:07] <Dark_Shikari> anyways, uploading the file
[13:21:09] <kshishkov> that's audio, so ask Peter
[13:21:17] <kshishkov> waiting for it
[13:21:21] <Dark_Shikari> kshishkov: forward it to him for me, you're the bink guy
[13:21:27] <Dark_Shikari> I'm the "spend time grepping servers" guy
[13:22:35] <_av500_> grep me a steak sandwich
[13:22:50] <mru> you forgot to sudo
[13:22:57] <Dark_Shikari> heh, wow, Cantor server just shared his whole hard disk
[13:23:10] <kshishkov> that's logical :)
[13:23:18] <_av500_> mru: im always logged in as root, no?
[13:23:37] <kshishkov> _av500_: only if you are silly sysadmin
[13:23:38] <mru> yes of course, no ubuntu there
[13:23:52] <mru> kshishkov: didn't you read xkcd today?
[13:23:54] <Dark_Shikari> Halo works
[13:24:00] <kshishkov> mru: of course I did
[13:24:06] <jonwil> so thats Halo 1 on PC?
[13:24:08] <Dark_Shikari> yes
[13:24:18] <jonwil> <removes from list of games to check>
[13:24:21] <kshishkov> Dark_Shikari: make Halo your performance test samples
[13:24:31] <Dark_Shikari> Age of Empires 3: works
[13:24:37] <Dark_Shikari> wait a minute
[13:24:38] <Dark_Shikari> the audio sounds weird
[13:24:46] <Dark_Shikari> I'm going to have to check this against the official player
[13:24:53] <Dark_Shikari> I doubt they used low quality bink audio in such a modern game
[13:25:11] <kshishkov> Peter is hunting that bug
[13:25:20] <Dark_Shikari> kshishkov: http://www.mediafire.com/?zzwztmmyyyx here's your crash test sample
[13:27:51] <kshishkov> Halo 3 Binks are 1280x960, should be good for testing performance
[13:28:49] <Dark_Shikari> ok, I have a sample with audio issues
[13:29:36] <Dark_Shikari> I'll leave it up to you to forward these on
[13:29:41] <Dark_Shikari> uploading the first 5M bytes of this one, since it's long
[13:30:38] * mru keeps thinking it would be nice with a cpu allowing on the fly code generation
[13:30:50] <Dark_Shikari> ?
[13:31:04] <kshishkov> i.e. running JVM HotSpot :P
[13:31:05] <mru> basically a mechanism to feed the result of an instruction directly into the front of the pipeline
[13:31:26] <Dark_Shikari> kshishkov: http://www.mediafire.com/?zz3znmzfwwf
[13:31:28] <Dark_Shikari> audio issues sample
[13:31:39] <jonwil> ok, got another video that crashes ffplay right up
[13:32:36] <Dark_Shikari> Rise of Legends: works
[13:32:41] <Dark_Shikari> Max Payne 2: works
[13:32:50] <jonwil> should I upload this video to samples?
[13:33:04] <kshishkov> yes
[13:33:24] * elenril wonders where did we get a wma2 encoder
[13:33:25] <Dark_Shikari> Sins of a Solar Empire: works
[13:33:44] <jonwil> Uploading stccmenu.bik to /incoming now
[13:34:07] <jonwil> crashes ffplay on startup
[13:34:13] <jonwil> official rad player plays it fine
[13:34:17] <kshishkov> elenril: it's virtually the same as wma1
[13:34:23] <Dark_Shikari> Titan Quest: works well, but audio is fucked up as before
[13:34:41] <elenril> kshishkov: and where did we get a wma1 encoder? :)
[13:34:52] <kshishkov> elenril: some Michael wrote it
[13:34:56] <jonwil> EA Sports V8 Challenge seems to work except that one video
[13:34:59] <elenril> o_0
[13:35:16] <Dark_Shikari> Assassin's Creed: works
[13:35:55] <jonwil> ok, Moto GP 2 works (seems they have .vid files that are really renamed bik files)
[13:36:12] <jonwil> seems not to have any audio
[13:36:15] <Dark_Shikari> Call of Duty: works
[13:36:16] <jonwil> no audio stream
[13:37:19] <Dark_Shikari> Fallout 3: works
[13:38:54] <Dark_Shikari> Sid Meier's Pirates: works
[13:39:19] <jonwil> EA Sports F1 2001 works
[13:39:53] <jonwil> did someone say they tested the Tony Hawk games?
[13:40:27] <kshishkov> no, but we have samples at MPHQ
[13:40:35] <jonwil> from which games?
[13:40:52] <kshishkov> thps4
[13:41:00] <jonwil> ok, I have a copy of THPS3 here
[13:41:02] <jonwil> which I will test
[13:41:15] <Dark_Shikari> Black and White 2: works, with audio issue
[13:44:13] <Dark_Shikari> Homeworld: works
[13:45:39] <Dark_Shikari> Arcanum: works
[13:46:23] <Dark_Shikari> Need for Speed SHIFT: works
[13:46:31] <Dark_Shikari> kshishkov: got any results from that crash test?
[13:46:45] <kshishkov> none useful results so far
[13:47:23] <Dark_Shikari> got it to crash at least?
[13:47:30] <kshishkov> of course :)
[13:48:45] <Dark_Shikari> Gears of War: works
[13:49:07] <jonwil> C&C: Generals works
[13:51:29] <jonwil> 6 games left in my pile to test
[13:52:21] <CIA-90> ffmpeg: kostya * r21962 /trunk/libavcodec/ (indeo5.c ivi_common.h ivi_common.c):
[13:52:21] <CIA-90> ffmpeg: Macroblock and block Huffman code sets are to be used by both Indeo 4 and
[13:52:21] <CIA-90> ffmpeg: Indeo 5, so make them global and move their initialization to the common place
[13:52:21] <CIA-90> ffmpeg: as well. And fix static VLC initialization, as ff_ivi_create_huff_from_desc()
[13:52:21] <CIA-90> ffmpeg: used old way to do so.
[13:53:02] <Dark_Shikari> Galatic Civilizations 2: works
[13:54:26] <Dark_Shikari> Rainbow 6 Vegas: works
[13:55:04] <Dark_Shikari> Prometheus: works
[13:55:25] <Dark_Shikari> The Ball UDK Demo: works
[13:55:53] <Dark_Shikari> Guitar Hero III: works
[13:55:54] <jonwil> 3 games left
[13:56:03] <Dark_Shikari> did I mention there's a lot of games on this network
[13:56:23] <kshishkov> no
[13:56:36] <kshishkov> but since that's college network, it should be obvious
[13:57:30] <Dark_Shikari> rhetorical question
[13:57:31] <Dark_Shikari> also
[13:57:35] <Dark_Shikari> Got another crash + error sample for you
[13:57:38] <Dark_Shikari> plays fine in the official player
[13:57:42] <Dark_Shikari> from Guitar Hero III
[13:58:07] <Dark_Shikari> different error though
[13:58:14] <Dark_Shikari> [binkvideo @ 00f388a0]Too many block type values
[13:58:22] <Dark_Shikari> might be a different variation of bink
[13:59:18] <jonwil> ok, thats it for "games I can find that have bink files"
[13:59:46] <Dark_Shikari> kshishkov: http://www.mediafire.com/?mdm0y3kdmmz
[13:59:47] <Dark_Shikari> crash sample.
[14:01:01] <kshishkov> ok, got it
[14:01:32] <KotH> kshishkov: make a dir in incoming where you collect bink samples
[14:01:40] <KotH> kshishkov: if you need more space, let me know
[14:01:59] <KotH> kshishkov: also let me know when you've collected a few so i can move them to the correct place
[14:02:03] <kshishkov> KotH: meh, I'm on par with Dark_Shikari on upload speed
[14:03:44] * jonwil is out of bink files to test
[14:06:00] <KotH> kshishkov: who cares about speed?
[14:06:27] <KotH> i dont mind if it takes a week
[14:07:29] <kshishkov> for now it's mostly the same variation
[14:09:01] <Dark_Shikari> kshishkov: I got a ton of failure here, from GH3, some seem to fail in different ways
[14:09:05] <Dark_Shikari> invalid block type, etc, etc
[14:09:13] <Dark_Shikari> they all work fine with the regular player
[14:09:52] <kshishkov> _that_ sounds as a new BIKi flavour
[14:10:03] <Dark_Shikari> But GH3 is not that new a game
[14:10:04] <Dark_Shikari> dunno
[14:10:14] <Dark_Shikari> also, they all lock up ffplay
[14:10:20] <Dark_Shikari> i.e. it goes to background and doesn't terminate
[14:10:27] <Dark_Shikari> so you can end up with 20 ffplays running
[14:10:41] <kshishkov> not running :S
[14:11:54] <Dark_Shikari> http://www.mediafire.com/?iljotzz3nii
[14:11:58] <Dark_Shikari> here's a 7z file of a bunch of broken files
[14:12:17] <Dark_Shikari> have fun
[14:12:26] <kshishkov> thanks
[14:13:09] <kshishkov> I suspect they have an additional size field for the first chroma plane
[14:13:17] <kshishkov> and that's flag-based
[14:14:17] <Dark_Shikari> this a suspicion from the past or what?
[14:14:51] <kshishkov> no, it's new coming from looking at prelude_1.bik first frame
[14:16:19] <Dark_Shikari> Ah
[14:16:40] <Dark_Shikari> btw, I'm "just started" in terms of number of videos
[14:17:06] <Dark_Shikari> not even 20% through the list
[14:17:46] <J_Darnley> Dark_Shikari: was the audio problem you got a sort-of pulsating sound?
[14:19:11] <Dark_Shikari> yes
[14:19:48] <J_Darnley> Right, should I provide the file (BF1942 Intro) that gives me that too?
[14:20:02] <kshishkov> nah, too many of them
[14:20:25] <J_Darnley> Okay, later perhaps, if it isn't fixed
[14:20:35] * kshishkov wonders why nobody heard a problem with audio before recent Bink video decoder addition
[14:20:53] <J_Darnley> I didn't bother trying it until today
[14:21:20] <J_Darnley> I already got what I needed with the the official tools
[14:21:34] <kshishkov> why now then?
[14:21:44] <Dark_Shikari> because now we have video
[14:21:47] <J_Darnley> Because the video commit reminded me
[14:22:15] <kshishkov> of the fact that official tools exist?
[14:22:42] <J_Darnley> No, that ffmpeg was getting (had) bink support
[14:23:28] <J_Darnley> I've had that video as a lossless-x264/flac/mkv file for ages
[14:25:21] <Dark_Shikari> well kshishkov, I'm going to grab some sleep
[14:25:27] <Dark_Shikari> when I wake up I expect at least one of those samples fixed! ;)
[14:25:46] <kshishkov> probably it will require alpha plane support, dunno
[14:25:52] <kshishkov> but I'll try
[14:26:23] <kshishkov> お休み
[14:27:44] <elenril> moonspeak? in my #ffmpeg-devel ?
[14:27:53] <kshishkov> where else?
[14:32:30] <KotH> jo, wo süscht?
[14:33:33] * elenril throws http://en.wikipedia.org/wiki/UTF-8 at KotH 
[14:45:17] * KotH throws some http://en.wikipedia.org/wiki/Ebcdic at elenril 
[14:45:58] * kshishkov throws http://en.wikipedia.org/wiki/Cuneiform at them both
[14:46:09] <BBB> kshishkov, you should RE VP8, quick! :-p
[14:46:21] <kshishkov> BBB: let's leave it to Mike, OK?
[14:47:06] <elenril> KotH: utf-16 is fine too
[14:47:18] * elenril now knows how to read and write it thanks to m$
[14:48:08] <BBB> kshishkov, you mean so it'll be finished in 3011?
[14:48:10] * kshishkov can write a lot of things
[14:48:27] <BBB> kshishkov, or you men that adobe will somehow find a reason to finance it, because it's advantageous to them somehow?
[14:48:36] <kshishkov> BBB: no, I mean if he don't write spec for it, Xiph won't adopt it
[14:48:47] <BBB> xiph is relevant why exactly?
[14:48:52] <BBB> xiph is like MS
[14:48:54] <BBB> they take a standard
[14:48:57] <BBB> modify it incompatibly
[14:49:00] <kshishkov> VP8 may become Theora 2
[14:49:01] <BBB> and publish it as their own
[14:49:18] <BBB> and tell everyone that WE DID IT WE ARE AWESOME WE ARE PERFECT WE DID IT ALL BY OURSELVES!!! 111 222
[14:50:18] <elenril> BBB: want to apply a few patches for me? ;)
[14:50:47] <elenril> btw who do i need to bug to get a svn account?
[14:51:02] <kshishkov> DonDiego
[14:52:16] * elenril summons DonDiego from depths of he^w Germany
[14:52:17] * KotH throws a http://en.wikipedia.org/wiki/Cruciform_%28Hyperion_Cantos%29 at kshishkov 
[14:54:54] * janneg thinks that throwing classical lexika like Britannici or Brockhaus has more impact
[14:55:22] <kshishkov> Nordiska Familjebok
[15:00:43] <CIA-90> ffmpeg: kostya * r21963 /trunk/libavcodec/bink.c: Make Bink decoder able to skip alpha plane
[15:04:26] <BBB> elenril, but anyway, tell me which patches and I can apply
[15:04:35] <BBB> elenril, and send dondiego an email
[15:04:49] <elenril> BBB: nut metadata conv table
[15:05:58] <merbzt> elenril: I have a asf patch you can look at
[15:06:00] <elenril> and 4 patches in 'asfenc: fix extended content header', mail on Sun, 21 Feb 2010 15:54:40 +0100
[15:06:33] <elenril> merbzt: what patch?
[15:07:57] <merbzt> w8 and I'll dig it up for you
[15:08:44] <BBB> elenril, ok, will look
[15:09:16] <elenril> thanks
[15:11:02] <merbzt> elenril: http://pastebin.ca/1805785
[15:11:19] <merbzt> this is needed for wmapro over spdif
[15:12:04] <merbzt> is it related to the metadata work you do ?
[15:12:33] <elenril> don't think so
[15:13:03] <elenril> revision 11824 o_0
[15:13:33] <elenril> where did you get it/why isn't it applied?
[15:14:20] <BBB> might be from last year's soc
[15:14:20] <BBB> :)
[15:14:27] <merbzt> not needed for anything yet
[15:14:55] <merbzt> this need to go from the asf container to the spdif container
[15:15:11] <merbzt> or asf demuxer to spdif muxer
[15:15:32] <merbzt> not sure how to transport it
[15:15:47] <merbzt> dolby e needs something like this also
[15:16:04] <elenril> well i don't know a thing about spdif :)
[15:16:14] <merbzt> you don't need to
[15:16:33] <merbzt> this is just metadata from one container to another
[15:16:46] <BBB> putting it in extradata is terrible
[15:16:52] <BBB> you should put it in ... metadata! :)
[15:17:21] <elenril> lol
[15:18:45] <jez9999> BBB: looks like Michael is being ultra-anal over file.c, eh?
[15:19:13] <jez9999> good job i'm building my own version so fuck his retardedness
[15:20:01] <merbzt> BBB: do we have that framework ?
[15:21:11] <BBB> merbzt, now we do, yes
[15:21:16] <BBB> merbzt, AVMetadata
[15:21:19] <BBB> merbzt, \o/
[15:21:23] <merbzt> yey
[15:21:24] <BBB> last year we didn't
[15:21:29] <BBB> or so
[15:21:31] <BBB> maybe we did
[15:21:46] <BBB> jez9999, this is his regular self, he's OK with it I just need to convince him
[15:22:00] <merbzt> do we have some demuxer that ses it ?
[15:22:06] <merbzt> *uses
[15:22:09] <BBB> jez9999, I've worked with Michael for a while, so I think I have a good idea of how it works
[15:22:17] <BBB> merbzt, uses the metadata framework? or something else?
[15:22:25] <merbzt> uses the metadata framework
[15:22:37] <BBB> ID3 demuxer uses it pretty well
[15:22:47] <merbzt> ok
[15:22:50] <BBB> it supports "any" tag, and for some it uses the id3 tag if it doesn't recognize it
[15:22:57] <BBB> like TYER, apparently ("year")
[15:22:57] <jai> most demuxers do right
[15:22:57] <jai> ?
[15:23:01] <BBB> I think so
[15:23:16] <BBB> but me no expert so I might be wrong
[15:23:25] <BBB> btw did mike file the application for this year's soc?
[15:23:40] <merbzt> not that I know of
[15:24:14] <elenril> asf now handles metadata quite well too :)
[15:24:56] <BBB> oh that's march
[15:24:57] <BBB> n/m
[15:25:03] <elenril> BBB: yes, TYER is supposed to be year
[15:25:18] * elenril should fix this soon
[15:25:57] <BBB> get a svn account first
[15:26:01] <BBB> I love this work by the way
[15:27:14] * elenril goes to school, bbl
[15:27:53] <kshishkov> why not to kindergarden?
[15:28:20] <jez9999> BBB: if/when the query string patch gets in, do you admin the rtsp.c and rtpproto.c files?
[15:28:25] <jez9999> s/admin/maintain/
[15:28:29] <BBB> me and luca
[15:28:35] <BBB> and yes that'll be easier
[15:28:44] <jez9999> ok, well i will then start an issue for my patch there
[15:28:48] <BBB> don't despair, I told you I'd help find a solution to your problem
[15:28:49] <jez9999> which is working already, im using my own build
[15:28:54] <BBB> and I did :)
[15:29:34] <jez9999> well, i could've used the 'add to avformatcontext' trick with my own build...
[15:32:16] <BBB> believe me, I maintained a heavily modified ffmpeg for years
[15:32:18] <BBB> (gst-ffmpeg)
[15:32:20] <BBB> and it's a pain
[15:32:24] <BBB> you want to kill yourself in the end
[15:32:26] <BBB> it's not worth it
[15:32:35] <BBB> better work with upstream
[15:32:50] <kshishkov> nah, my local copy is better ;)
[15:47:46] <CIA-90> ffmpeg: mstorsjo * r21964 /trunk/libavformat/ (rtsp.c rtsp.h): Create AVFormatContext objects as private transport for output RTSP sessions
[15:48:00] <kshishkov> yay, he got an account!
[15:50:48] <andoma> swedish guy isn't he?
[15:51:02] <kshishkov> nej
[15:51:10] <kshishkov> han är finsk
[15:51:17] <BBB> go martin!
[15:51:28] <BBB> he's not on irc is he?
[15:51:50] <andoma> kshishkov: ah
[15:52:37] <kshishkov> andoma: it depends on whether you believe in Österland or not
[15:53:20] <mru> finland is just the intersection of sweden and russia
[15:53:36] <kshishkov> hell no!
[15:54:20] <kshishkov> it's a mix of Swedes and Sami on the same land
[15:54:51] <mru> no, that's Lappland
[15:55:01] <kshishkov> Finland as well
[15:55:47] <kshishkov> it looks like a piece of Sweden too, not as a dung heap
[15:57:18] <CIA-90> ffmpeg: mstorsjo * r21965 /trunk/libavformat/rtsp.c:
[15:57:19] <CIA-90> ffmpeg: Add a function rtsp_setup_output_streams for announcing the SDP
[15:57:19] <CIA-90> ffmpeg: and setting up the internal RTSPStream data structures when using
[15:57:19] <CIA-90> ffmpeg: the RTSP code in muxer mode.
[15:58:44] <CIA-90> ffmpeg: mstorsjo * r21966 /trunk/libavformat/rtsp.c: Don't follow RTSP redirects when used as a muxer
[16:12:27] <CIA-90> ffmpeg: mstorsjo * r21967 /trunk/libavformat/rtsp.c: Cosmetics: reindent after applying patches
[16:39:33] <kierank> anybody knowledgable about kbd windows?
[16:41:30] <kshishkov> jruggles but good luck catching him
[16:41:37] <kshishkov> what do you want to know though?
[16:42:12] <kierank> how the ffmpeg implementation works
[16:42:30] <kierank> and whether it can do non symmetrical windows
[16:43:03] <kshishkov> libavcodec/mdct.c ff_kbd_window_init()
[16:43:28] <kshishkov> and what do you mean "non symmetrical"?
[16:44:20] <kierank> Basically what happens is you mix for example the first half of KBD(64, 3.2) and the second half of KBD(64, 3.0)
[16:44:52] <kshishkov> ah
[16:45:12] <kshishkov> looks like you need to generate two windows and merge them
[16:46:13] <kierank> ff_kbd_window_init only does the first half, right?
[16:46:44] <kshishkov> yes
[16:47:29] <kierank> so I guess I could put it in a temporary buffer and reverse it
[16:47:39] <kshishkov> not reverse
[16:48:00] <kshishkov> just add in reverse order to the first generated half window
[16:49:07] <kierank> ok
[16:49:08] <kierank> thanks
[16:50:19] <kshishkov> FFmpeg can benefit from supporting another codec or two after all...
[16:51:02] <_av500_> preserve the environment, use less codecs
[16:51:24] <kierank> someone will make a "green codec" soon
[16:51:43] <kierank> there's already a "green browser" in that microsoft browser selection page
[16:52:03] <kshishkov> telnet ;)
[17:42:52] <elenril> can somebody produce a char that requires surrogate pairs to encode in utf16?
[17:43:03] * elenril doesn't want to wait half an hour for ff to start
[17:43:52] <kshishkov> copypaste from wikipedia?
[17:48:59] <elenril> hmm, so according to m$ "number of Unicode characters" actually means length in bytes / 2
[17:51:09] <iive> elenril: no rounding?
[17:54:11] <Kovensky> iive: there is never an odd byte count in well-formed utf16
[17:54:14] <elenril> iive: it's utf-16
[17:55:10] <BBB> crafted streams can always contain any number of bytes
[17:55:31] <iive> just kidding.
[17:56:01] <iive> BBB: it needs 2 bytes for \0 too.
[17:57:04] <kshishkov> it's a definitely \0 then ;)
[17:58:21] <elenril> 0/
[17:59:25] <kshishkov> that's for Danish/Norwegians or people who can't cross zero themselves
[18:00:12] <iive> "\0"
[18:12:44] <Dark_Shikari> kshishkov: any progress?
[18:13:44] <kshishkov> yes and no
[18:14:38] <kshishkov> look at r21963
[18:17:45] <Dark_Shikari> why not decode the alpha plane?
[18:19:33] <kshishkov> why do we need it?
[18:19:50] <kshishkov> in future it can be decoded though
[18:20:10] <kshishkov> BTW, all those Guitar Hero Binks are decoded fine with alpha
[18:20:25] <kshishkov> (maybe except for the sound)
[18:20:52] <Dark_Shikari> why don't we need it?
[18:21:01] <Dark_Shikari> people wanting to use lavc as a replacement for bink will want alpha support
[18:21:18] <kshishkov> ah, ok then
[18:22:04] <Dark_Shikari> lavc should be a fully functional replacement for crappy proprietary software
[18:22:08] <Dark_Shikari> in the general case
[18:22:45] <kshishkov> and for some of opensource too
[18:22:53] * kshishkov looks at Xiph projects
[20:15:44] <Vitor1001> mru: You there?
[20:15:58] <mru> pong
[20:16:18] <Vitor1001> Could you test a command in your PPC box?
[20:16:34] <Vitor1001> (I'm not asking for a account if I can't reproduce the bug I'm tracking)
[20:16:44] <mru> you can have an account anyway
[20:16:59] <Vitor1001> ok, I send you the passwd GPG encrypted?
[20:17:11] <mru> send ssh public key and username
[20:18:05] <Vitor1001> weird, I don't find your key fingerprint in MAINTAINERS file...
[20:18:29] <mru> no need for encryption
[20:18:40] <mru> that's the point of public keys
[20:19:53] <Vitor1001> ow, I was lousy
[20:20:00] <Vitor1001> I'm sending now the public key file
[20:20:47] <Vitor1001> done
[20:22:08] <mru> ok, try ssh saracen.mansr.com
[20:22:23] <Vitor1001> works, thanks!
[20:23:01] <mru> usual devtools are installed
[20:23:07] <mru> shout if you need more
[20:23:41] <mru> samples archive in /misc/samples/mphq
[20:23:49] <Vitor1001> ok, thanks!
[20:27:39] <Kovensky> http://blogs.msdn.com/oldnewthing/archive/2010/02/18/9965469.aspx <-- what, so you expect people to use PROPER hungarian notation, and derive the bug from that? D:
[20:30:41] <Kovensky> <@TheFluff> if you put a bottle of beer outside in this weather it'll freeze solid in less than half an hour
[20:30:45] <Kovensky> <@TheFluff> I know because I've tried
[20:30:47] <Kovensky> <@TheFluff> I didn't think it'd go quite that fast :|
[20:30:50] <Kovensky> <@TheFluff> i just wanted a cold beer
[20:30:53] <Kovensky> lol
[20:45:48] <Yuvi> ru_maxrss appears to be in bytes rather than kilobytes on OS X contrary to the documentation
[20:47:56] <mru> go apple!
[20:48:11] <Yuvi> it's hidden with -D_POSIX_SOURCE anyway
[21:21:21] <CIA-32> ffmpeg: mstorsjo * r21970 /trunk/libavformat/rtsp.c:
[21:21:21] <CIA-32> ffmpeg: Free metadata in chained RTP muxers in the RTSP muxer
[21:21:21] <CIA-32> ffmpeg: This fixes a minor memory leak
[21:22:43] <peloverde> Can I expect a value preserving promotion when comparing uint8_t to int32_t?
[21:23:36] <BBB> you mean will it compare as 8bit or 32bit?
[21:23:53] <peloverde> I mean will it compare as unsigned or as signed?
[21:24:37] <BBB> signed, I'd guess?
[21:24:45] <peloverde> That's what I thought to
[21:24:54] <peloverde> But that's not what i'm seeing
[21:25:20] <BBB> I was about to make a gcc-joke but then I figured that was cruel and unnice
[21:25:23] <BBB> maybe I was wrong
[21:25:51] <peloverde> I'm starting to confuse myself here, maybe that isn't even my problem
[21:25:51] <mru> if the full range of the type fits in signed int, it will be promoted to that
[21:26:13] <mru> so uint8_t will be converted to int
[21:29:09] <CIA-32> ffmpeg: mstorsjo * r21971 /trunk/ (8 files in 3 dirs): Add an RTSP muxer
[21:34:19] <janneg> bah, no luck rendering the second part of the first Big Buck Bunny scene with only 4G
[21:45:22] <_av500_>  dman
[21:50:23] <janneg> the second scene rendered fine though
[21:52:37] <mru> what resolution are you rendering?
[21:54:06] <janneg> 2700x1440
[21:54:29] <mru> how did you arrive at that number?
[21:55:47] <janneg> 900x720 * 6
[21:56:04] <mru> but 900?
[21:56:38] <mru> oh, I see
[21:56:45] <janneg> 5:4
[21:57:48] <janneg> http://www.jannau.net/peach_2700x1440/ has all png I've rendered so far
[22:00:23] <_av500_> janneg: buy more ram
[22:01:46] <kierank> I thought mru was doing it as well?
[22:02:24] <mru> nah, I'll do the bits janneg can't manage
[22:06:09] <CIA-32> ffmpeg: michael * r21972 /trunk/libavformat/utils.c:
[22:06:09] <CIA-32> ffmpeg: Make sure mp1/mp2 get their frame_size set.
[22:06:09] <CIA-32> ffmpeg: Fixes issue1696
[22:07:43] <janneg> _av500_: RAM is so expensive ATM
[22:14:19] <superdump> it is?
[22:15:57] <DonDiego> ld: duplicate symbol _rtsp_connect in libavformat/libavformat.a(rtsp.o) and stre
[22:15:58] <DonDiego> am/librtsp/rtsp.o
[22:16:15] <DonDiego> for once I think a compilation failure is not mplayer's fault
[22:16:34] <DonDiego> something should either be static or have a proper prefix
[22:16:45] <DonDiego> and somebody missed this during a review..
[22:18:11] <DonDiego> missing ff_ prefix AFAICT
[22:18:25] <mru> just add it
[22:18:57] <BBB> did you make clean?
[22:19:32] <DonDiego> BBB: make clean does not rename symbols
[22:19:46] <BBB> I know, but rtsp_connect() duplicate symbol
[22:19:48] <BBB> confuses me
[22:19:57] <BBB> anyway, sorry about the ff_ prefix, yes I missed that
[22:20:03] <DonDiego> what's there to confuse you?
[22:20:05] <BBB> can you bring it up on the mailinglist?
[22:20:11] <DonDiego> there is another lib with the same symbol
[22:20:23] <DonDiego> object file rather than lib
[22:20:28] <DonDiego> but it's the same thing
[22:20:30] <BBB> ooooh
[22:20:32] <BBB> librtsp
[22:20:33] <BBB> now I get it
[22:20:36] <BBB> that sucks
[22:20:44] <BBB> we should tell them to rename the symbol :-p
[22:20:44] <DonDiego> no, ffmpeg sucks
[22:20:47] <BBB> yes I know
[22:21:04] <DonDiego> everything in libavformat/rtsp.h should have an ff_ prefix
[22:21:11] <BBB> again, sorry, I missed the ff_ prefix, please bring it up on the mailinglist
[22:21:14] <BBB> I'll cook up a patch
[22:21:16] <DonDiego> you're the maintainer, so go ahead and fix it
[22:21:23] <DonDiego> i'm not following the ml
[22:21:41] <DonDiego> this friendly reminder should be all you need :)
[22:22:48] <CIA-32> ffmpeg: reimar * r21973 /trunk/ (configure doc/ffmpeg-doc.texi ffmpeg.c): Make -benchmark also print the maximum memory usage if possible.
[22:40:21] <astrange> http://pastebin.com/m70da91e4 current-ish global symbols
[22:52:09] <astrange> is anyone reading coverity lately?
[22:52:36] <mru> is it alive?
[22:52:47] <mru> I thought it was dead since 2007
[22:53:05] <mru> I emailed them several times and got no reply
[22:53:13] <peloverde> I've been looking into metafuzz lately
[22:54:11] <astrange> the page is up but they don't list the versions they scanned
[22:55:00] <mru> they ran ffmpeg twice
[22:55:05] <mru> both times in july 2007
[22:55:19] <mru> sorry, one was june 2007
[22:56:03] <mru> hmm, mplayer seems to be running
[22:58:42] <peloverde> I hate that all these people running automated crap looking for exploits seem to use mplayer instead of ffmpeg
[22:59:28] <Dark_Shikari> peloverde: I'm about to post a massive, massive tl;dr blog post on vp8 and flash
[22:59:34] <Dark_Shikari> so you can get up in arms again
[23:00:53] <mru> well, in this case ffmpeg is a subset of mplayer
[23:01:01] <mru> so most of what we want is there
[23:01:40] <peloverde> mpalyers demuxers and third party libraries wind up masking a lot of ffmpeg
[23:01:53] <mru> this is static analysis
[23:01:56] <astrange> static analysis of mplayer is fine
[23:02:00] <mru> all code is checked
[23:02:09] <astrange> well, except i'd rather check --disable-asm
[23:02:24] <jermy> I'm just trying to work out if a bug is real at the moment (can't find any bugreports) - If anybody has a moment, could they try encoding stereo audio with a one channel muted using libvorbis.
[23:02:26] <peloverde> that makes sense, but i've been looking more at fuzzing stuff lately
[23:02:40] <peloverde> there are fewer false positives popping out of fuzzers
[23:03:14] <jermy> (I've got one at http://jeremy.publication.org.uk/a.orig.wav.gz, but perhaps there's something odd with the audio I'm giving it)
[23:12:06] <peloverde> Dark_Shikari, I don't see what you think would make me angry in that post
[23:12:21] <jermy> (Oops - Actually, I mean the built-in -acodec vorbis)
[23:13:36] <Dark_Shikari> peloverde: I was kidding
[23:13:37] <Dark_Shikari> lol
[23:13:53] <Yuvi> Dark_Shikari: google has at least two non-hd versions of most videos, one 360p mp4 and one 480p h.264 in flv
[23:14:41] <Dark_Shikari> isn't the 360p the old flv?
[23:14:49] <Dark_Shikari> Either way, they're still not using high profile are they?
[23:14:51] <Yuvi> no, it's h.264 as well
[23:15:00] <Dark_Shikari> last time I downloaded there was no high profile stream
[23:15:04] <Dark_Shikari> except in HD
[23:15:06] <Yuvi> (it's the one used for <video>)
[23:15:19] <Dark_Shikari> er, actually
[23:15:23] <Dark_Shikari> fmt=18 gives me the 480p version
[23:15:34] <peloverde> speaking of <video> chrome needs a real scaler yesterday
[23:16:02] <Yuvi> get them to pay michael to relicense swscale asm under lgpl ;)
[23:16:16] <peloverde> I think a lot of people don't realize that's an option
[23:16:46] <peloverde> Just like that colorspace conversion article
[23:17:12] <Dark_Shikari> upvote my HN post http://news.ycombinator.com/item?id=1144014
[23:17:28] <peloverde> I don't do social news anymore. It got me too stressed out.
[23:17:55] <Dark_Shikari> HN is pretty good
[23:17:58] <Dark_Shikari> it's much less retarded than reddit.
[23:18:03] <Dark_Shikari> They're not full-freetard.
[23:18:26] <astrange> posted to reddit out of curiosity
[23:18:54] <Dark_Shikari> >_>
[23:19:13] <peloverde> I also don't understand reddit's whole subreddit thing
[23:19:15] <astrange> btw safari's <video> is quite good
[23:19:31] <peloverde> There were always theora articles in the linux subreddit, what does theora have to do with linux?
[23:19:32] <astrange> but i wish they'd added a format whitelist, you can embed mkv/wmv into it
[23:19:45] <astrange> and i don't consider my own code in perian to be internet-ready
[23:20:18] <peloverde> Google did some voodoo to make their ffmpeg not conflict with totem plugin
[23:20:40] <peloverde> it kind of scares me that people would run such a plugin
[23:21:11] <Yuvi> fmt=18 gives you 480p h.264 in mp4 or flv?
[23:21:14] <astrange> hmm, i guess it's probably sandboxed actually
[23:21:43] <Dark_Shikari> Yuvi: no idea
[23:21:48] <Dark_Shikari> it just gives me 480p
[23:22:37] <Yuvi> actually, the "360p" mp4 for this random vid is 480x270
[23:22:50] <Yuvi> I don't think youtube serves h.263 anymore
[23:23:13] <Yuvi> unless it was uploaded pre-2006 or 7
[23:24:08] <Dark_Shikari> Interesting
[23:24:09] <Dark_Shikari> I'm not surprised.
[23:26:16] <Dark_Shikari> oh btw, feel free to poke holes in the post so I can fix them
[23:26:58] <Yuvi> is there an easy way to check the profile?
[23:27:13] <Honoome> astrange: I actually was able to nastily crash perian a couple of times before, with rtsp streams through feng ^^;;
[23:27:57] <Dark_Shikari> Yuvi: download it
[23:27:58] <Dark_Shikari> open in streameye
[23:28:18] <Yuvi> streameye completely failed at installing under win7
[23:28:24] <Dark_Shikari> worked fine here
[23:28:26] <Yuvi> and I lost my older VMs
[23:28:27] <Dark_Shikari> well, then again, I use an older version
[23:28:31] <Dark_Shikari> streameye STUDIO fails horribly
[23:29:26] <astrange> i copied the folder from an xp backup
[23:29:34] <astrange> never bothered reinstalling to get it in a menu
[23:29:48] <Dark_Shikari> you can find the trial version on various websites not theirs
[23:29:50] <Dark_Shikari> i.e. the old one
[23:30:05] <astrange> Honoome: if you have crash logs from 1.2 i'll take them
[23:31:13] <Honoome> astrange: nah it should probably have been 1.1 last time I crashed it… but if I'll get any in the future I'll remember to drop a line ;)
[23:32:52] <Dark_Shikari> astrange: it's still baseline
[23:32:56] <Dark_Shikari> used a video from dec 2009
[23:37:26] <Yuvi> Dark_Shikari: turns out it's faster to upload them and have you look at what youtube gives me than to boot my vm http://www.mediafire.com/?yjgyy4ewiij
[23:38:40] <Dark_Shikari> Yuvi: I already looked
[23:38:45] <Dark_Shikari> but I can check those too
[23:40:11] <Dark_Shikari> 360p: Baseline 2.1
[23:40:33] <Dark_Shikari> 480p: Main 3.1 (wat)
[23:41:19] <mru> Dark_Shikari: s/adobe/macromedia/
[23:41:49] <Dark_Shikari> oh yeah.  let me fix that
[23:42:09] <astrange> you could mention dirac, i suppose
[23:42:18] <astrange> i read another article just now that claimed it was suitable for HD web video
[23:42:22] <Dark_Shikari> It should be.
[23:42:38] <peloverde> Wasn't Dirac (more-or-less) abandoned
[23:43:02] <Dark_Shikari> added.
[23:43:05] <Dark_Shikari> no, it's still in development
[23:44:16] <peloverde> There has been no new news on diracvideo.org for a year
[23:45:46] <astrange> http://diracvideo.org/git?p=schroedinger.git;a=summary
[23:45:52] <peloverde> ahh
[23:46:08] <Dark_Shikari> there's been no news on x264.com for a year at least too ;)
[23:46:35] <mru> bbc dropped dirac development
[23:46:36] <peloverde> I assumed that's because everybody goes to x264.nl
[23:46:42] <mru> because h264 was cheaper
[23:46:52] <peloverde> mru, that's what i'm thinking of
[23:47:02] <Dark_Shikari> they use it internally, iirc
[23:47:02] <Yuvi> supposedly anu has a current contract with them to do schroedinger work
[23:47:04] <Dark_Shikari> as an intermediate format
[23:47:16] <mru> that was the intent
[23:47:19] <mru> but they don't
[23:47:29] <kierank> they do
[23:47:35] <kierank> they use it on the bbc raman network sometimes
[23:47:46] <kierank> for point to point hd
[23:47:53] <mru> hmm, guess my sources are unreliable
[23:48:09] <kierank> and they sold devices to a few other people
[23:48:21] <mru> either way, it was never intended to be a distribution format
[23:48:23] <kierank> though by no means a success
[23:48:47] <kierank> there was meant to be some distribution format because they split it up into Dirac and Dirac Pro
[23:48:57] <kierank> the latter went somewhere but the former didn't
[23:49:24] <mru> because licensing h264 was cheaper than developing a new codec
[23:50:18] <kierank> they didn't plan to use it within the lifetime of h264
[23:50:30] <kierank> it was meant to be the next generation
[23:55:17] <justlooking> im pritty sure the bbc call it DIRAC PRO and they have hardware for it too http://www.bbc.co.uk/rd/projects/dirac/diracpro.shtml
[23:55:52] <Yuvi> also, from what I've done with dirac it starts falling apart at a higher bitrate than theora, even for HD
[23:57:38] <kierank> i heard dirac pro was why the beijing olympics didn't look to good on bbc
[23:57:42] <kierank> too*