Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2010

1 participants
29 discussions

IRC log for 2010-05-18
by irc＠mansr.com 19 May '10

19 May '10

[00:01:36] <Kovensky> Dark_Shikari: that on2 stuff you said you were reading is about vp7? [00:01:42] <Kovensky> or did they release vp8 already? [00:01:47] <Dark_Shikari> vp8 [00:01:54] <Dark_Shikari> no they didn't release [00:01:56] <Dark_Shikari> I'm just that cool [00:02:04] <Kovensky> hah [00:02:12] <Kovensky> cheater ;P [00:02:20] <Dark_Shikari> 5000 words written so far. [00:02:23] <Dark_Shikari> enjoy your analysis on wednesday. [00:02:29] <mru> Kovensky: NDA isn't cheating [00:02:53] <Kovensky> mru: well, he *is* getting access to it before everyone else... =p [00:02:55] <Dark_Shikari> I would say I have their spec, but "spec" is being too nice. [00:03:05] <mru> Kovensky: untrue, I have it too... [00:03:29] <Kovensky> meh [00:03:38] <Kovensky> you have access to it before The Internets [00:03:45] <Dark_Shikari> so do a lot of people [00:04:11] * Kovensky wonders what they want with this NDA [00:04:21] <mru> non-disclosure [00:04:24] <Dark_Shikari> they want to be able to make drama when they release it obviously [00:04:25] <Kovensky> well ofc [00:04:30] <Kovensky> but what do they profit from that [00:04:35] <mru> attention [00:04:38] <Dark_Shikari> +1000 [00:04:54] <Kovensky> negative attention? ._. [00:04:59] <Dark_Shikari> no such thing [00:05:04] <Dark_Shikari> don't be impatient, only two days and you can learn yourself how shitty it is. [00:05:12] <mru> that's what they'd get if they let Dark_Shikari publish his comments before they start beating the drum [00:05:19] <Dark_Shikari> And yeah, that [00:05:34] <Kovensky> oh, it's out on wednesday [00:05:35] <mru> now they've worked up a nice hype [00:05:37] <Kovensky> makes sense [00:05:55] <Kovensky> I wonder how many freetards will praise it [00:06:06] <Dark_Shikari> I suspect not as many as you think [00:06:10] <mru> hehe [00:06:12] <Dark_Shikari> especially after reading my blog post. [00:06:17] <Dark_Shikari> And not because of compression or quality. [00:06:19] <mru> Dark_Shikari: freetards don't trust us [00:06:34] <Dark_Shikari> mru: maybe, but I think they are worried about patents. [00:06:41] <Dark_Shikari> Way too much, perhaps [00:06:43] <mru> only the ones they believe in [00:06:44] <Dark_Shikari> but they are. [00:06:44] <Kovensky> "yeah yeah he develops x264 he's just being defensive about his precious" [00:07:16] <Dark_Shikari> I didn't get any of those comments on my previous vp8-related post ;) [00:07:33] * Kovensky wonders if search ars would yield those comments [00:07:36] <Kovensky> +ing [00:07:39] <Dark_Shikari> well probably [00:07:42] <Dark_Shikari> you search enough /. clones [00:07:44] <Dark_Shikari> and you get /. comments [00:07:49] <Kovensky> lol [00:07:53] <Kovensky> true that [00:10:44] * mru likes it when neon code is shorter than C version [00:11:03] <kierank> [00:55] <@bcoudurier> then their encoder is utter crap --> my point was that for CBS the encoder between CBS--->affilliate is bad so the encoder from affiliate-->OTA/Cable doesn't stand a chance. [00:11:05] <Dark_Shikari> in lines of code or total asm? [00:11:10] <mru> lines of code [00:11:15] <lu_zero> mru: isn't that expected? =P [00:11:23] <Dark_Shikari> yeah, lines of code is rather nice =p [00:11:24] <mru> uncompiled C [00:11:48] <mru> sometimes the optimised code is much larger than compiled C [00:11:51] <mru> depends on what it does [00:11:52] <bcoudurier> OTA is ok [00:11:55] <bcoudurier> cable is crap [00:11:59] <mru> and on how insanely you optimise it [00:12:26] <Dark_Shikari> I prefer optimized code that's much smaller [00:12:34] <Dark_Shikari> like x264's CABAC, whose core 3 functions now fit in under 256 bytes [00:12:41] <mru> sometimes you have to unroll more to get optimal scheduling [00:12:43] <Dark_Shikari> previously each one was > 256 bytes, thanks to gcc [00:12:52] <Dark_Shikari> now they all fit in less than the size of 1. [00:13:27] <mru> if making it longer saves more than the cost of a cache miss, that's what you do [00:13:36] <Dark_Shikari> well of course [00:13:44] <Dark_Shikari> and the relative values of icache vs dcache [00:13:56] <mru> extreme case: neon float2int16 [00:14:06] <Dark_Shikari> the nice thing about x86 is that with its powerful OOE, you can generally get away with really really small code [00:14:14] <Dark_Shikari> which is really useful on intel chips with small L1 [00:14:29] <Dark_Shikari> additionally, you can often abuse memory arguments to get even smaller code [00:14:39] <mru> depends on the instruction latency [00:14:42] <Dark_Shikari> sub [mem], 2 is much smaller than load/sub/store [00:14:48] <Dark_Shikari> and in many cases--actually faster. [00:15:01] <mru> if you instructions have 5 cycles latency but you have less than 5 insns per iteration, you need to unroll [00:15:14] <Dark_Shikari> there aren't any 5 cycle latency instructions on x86 [00:15:16] <Dark_Shikari> not that anyone uses [00:15:19] <Dark_Shikari> unless you count atom or some shit [00:15:24] <mru> not even floating-point? [00:15:30] <Dark_Shikari> fpu multiply is 4 I think [00:15:31] <mru> I mean result latency [00:15:34] <mru> not issue rate [00:15:37] <Dark_Shikari> yes [00:15:41] <Dark_Shikari> issue rate is almost always 1 per cycle [00:15:46] <Dark_Shikari> or 2 or 3 [00:16:03] <mru> it can only be >1 if there are no dependencies [00:16:30] <Dark_Shikari> of course. [00:16:39] <Dark_Shikari> fpu add: 3/1 [00:16:41] <Dark_Shikari> fpu mul: 4/1 [00:16:48] <mru> although a very short loop could fit several iterations in the reorder queue [00:16:49] <Dark_Shikari> double-precision multiply is 5/1 [00:16:53] <Dark_Shikari> so yeah, there is one instruction that's latency 5 [00:16:57] <Dark_Shikari> but why the hell would you use double [00:17:12] <Dark_Shikari> also the complex instructions (e.g. sqrt) are slower but that's a given. [00:21:08] <Kovensky> OT: <Chandalen> http://fukung.net/v/28922/3de7b9e3e3c6e4f1dbc6ef5e0169b7b2.gif <~neo2sonic> oh, a snowflake. ahah... oh, mor------------- [00:22:14] <mru> looks like a boring block of flats in a swedish suburb [01:46:42] <thick_mcrunfast> Where can I find a description of the mpeg 2 TS stream format? [01:47:46] <thick_mcrunfast> That was embarrassing. [01:55:06] <Compn> thick_mcrunfast : might be on the wiki [02:01:52] <Compn> thick_mcrunfast : http://wiki.multimedia.cx/ [02:02:02] <thick_mcrunfast> Compn: Ah, thank you [02:02:50] <Compn> http://wiki.multimedia.cx/index.php?title=MPEG-2_Transport_Stream [03:28:31] <saintd3v> peloverde: i opened up the ff-aac output in baudline, what causes the giant holes? [03:29:28] <peloverde> I thought I fixed most of the holes [03:29:37] <peloverde> are you using r23136 or newer [03:29:53] <saintd3v> just did a git clone today [03:30:24] <peloverde> hmm... [03:30:39] <peloverde> what encoding parameters? mono or stereo? [03:31:03] <saintd3v> it's not as bad as when the cutoff was there, but just curious [03:31:32] <saintd3v> ffmpeg -i test.wav -acodec aac -ab 160k -f mp4 test.mp4 [03:31:37] <saintd3v> stereo [03:31:49] <peloverde> In the past holes were caused by the codebook selector using information from the wrong frame [03:32:26] <peloverde> I've been stereo, mid/side is probably buggy [03:32:43] <peloverde> do you get holes for mono? [03:32:57] <saintd3v> dunno, haven't tried it [03:34:32] <saintd3v> peloverde: http://imgur.com/HmRPE.jpg [03:37:13] <saintd3v> would that be the same issue? [03:38:54] <peloverde> same issue as? [03:39:26] <saintd3v> codebook using the wrong information? [03:39:57] <peloverde> It could be [03:40:25] <saintd3v> ok :) was just curious [03:40:45] <peloverde> I'd have to verify that those are 0HCB and what's causing them to be [03:41:41] <peloverde> previously the psymodel was giving mask ratios for the previous frames causing disaster whenever there was window switching [04:33:38] <peloverde> If I have a container that sets a packet size to a fixed value then places a frame in the packet then zero pads the rest of the packet, what's the best way to deal with that? [05:18:44] <Yuvi> is libopenjpeg really #include <openjpeg.h> not <openjpeg/openjpeg.h>? [05:18:44] <Yuvi> I'm not sure one way or another given their install system put it in /openjpeg [05:19:22] <Dark_Shikari> I think they might have changed it [05:34:15] <peloverde> Fresh install of VC++ Express 2010 and I get a non-descript FileNotFound exception on launch, how are these people still in business? [05:35:36] <Dark_Shikari> peloverde: http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx [05:53:05] <Tjoppen> classic wtf :) [06:01:55] <elenril> is aacenc still supposed to sound like shit at 320kbps? [06:03:16] <Tjoppen> dunno.. it's been poked at recently so I haven't had time to test, but I've gotten good results with 256 kbps [06:03:44] <Tjoppen> when it doesn't SIGSEGV of course :o [06:09:41] <superdump> morning [06:36:49] <thresh> moroning [06:39:46] <av500> what thresh said [07:04:08] <KotH> ohayou gozaimasu! [07:04:30] <wbs> gomorgon [07:04:42] <merbzt1> tere homikost [07:35:37] <thresh> __gb__: could I suggest libva build-depends on libgl-dev (that is provided by nvidia-glx-dev and libgl1-mesa-dev on my sid system), and not only on libgl1-mesa-dev ? [09:57:47] <scaphilo> has anyone an idea why i get the following error after calling ffmpeg with the following options: ffmpg_nios -i myownprotocol:filename -f mpeg4 myownprotocol:filename [09:58:10] <KotH> scaphilo: wrong channel [09:58:15] <KotH> scaphilo: try #ffmpeg instead [09:58:30] <scaphilo> am i built my own protocol [09:58:41] <scaphilo> thats wy i ask here sorry [09:58:55] <KotH> oh.. then give more info :) [09:59:30] <scaphilo> Unable for find a suitable output format for myownprotocol:filename [09:59:47] <scaphilo> it refers to the -i file not the ouptut file [09:59:52] <scaphilo> or better protocol [10:00:07] <scaphilo> wait its not good described ill have to rewrite that [10:00:27] <scaphilo> ffmpg_nios -i myownprotocol:filename.mpeg -f mpeg4 myownprotocol:filename.mp4 [10:00:34] <scaphilo> Unable for find a suitable output format for myownprotocol:filename.mpeg [10:00:58] <scaphilo> thats strange i would suspect that i get the same error with myownprotocol:filename.mp4 [10:03:04] <merbzt1> scaphilo: try asking on libav-users [10:03:50] <scaphilo> oh thx [10:05:36] <hyc> anyone interested in patches for ffserver to also serve rtmp ? [10:06:05] <wbs> hyc: if ffserver actually works, I guess that would be interesting [10:06:17] <merbzt1> hyc: bring em on [10:06:19] <hyc> it would work, if my patches got committed [10:06:40] <wbs> one problem with ffserver generally is that it totally abuses the libav* interfaces and uses lots of non-public stuff from libavformat [10:07:00] <hyc> I think it'd be worth doing, but I still must admit to a degree of frustration getting any of my contributions in [10:07:35] <wbs> hyc: I'm still waiting for review of stuff i made in mid-april ;P [10:08:00] <wbs> but for the rest of your ffserver patches, they need the attention of someone more knowledgeable on ffserver, can't help you on that [10:08:06] <hyc> so just par for the course huh [10:08:07] <av500> hyc: come on, just implement that new seeking api and the rest is easy peasy... :) [10:08:29] * hyc coughs ... [10:08:48] <merbzt1> baptiste is the current maintainer for ffserver [10:09:22] <hyc> apparently he's not spending any attention on it right nwo [10:09:26] <hyc> (now) [10:09:38] <hyc> we were all in IRC together a few hours ago and he didn't mention ffserver at all [10:11:12] <hyc> (19:30:23) bcoudurier: mru, what bandwidth is dvb-t ? [10:11:53] <merbzt1> well we all need more hours during the day [10:13:10] <hyc> yeah [10:19:19] <Compnn> hyc : we dont want to continue rtmp spreading, why put streaming in ffserver? :P [10:20:08] <hyc> Compn: I'm actually considering dropping the rtmpdump command and just using ffmpeg [10:20:51] <hyc> but the idea about ffserver is just because I googled "rtmp rtsp" and there appear to be more queries about going from rtsp to rtmp than vice versa [10:21:06] <Compn> ah [10:21:11] <hyc> which I must admit is frankly, quite odd [10:21:36] <hyc> rtsp is an IETF standard. I think it's better to go from rtmp to rtsp [10:21:53] <Compn> combining rtmpdumps features into ffmpeg and sticking with ffmpeg would be an interesting idea, as long as you dont get frustrated with ffmpeg review process :P [10:21:55] <hyc> which we now can do, in a nlucky way [10:22:14] <hyc> yeah, that's teh sticky part. I find this project quite annoying. [10:22:24] <hyc> I only stick with it because the code is obviously useful [10:23:06] <hyc> it only took a couple days to get my rtmp patches into libcurl [10:23:37] <hyc> but libcurl isn't the proper vehicle for rtmp protocol. to really take advantage of it you need audio/video/media support. [10:23:38] <Compn> thats neat, i remember curl had a seriously old patch for rtmp but it was never applied... [10:23:49] <hyc> ffmpeg is really the place to do this work [10:24:34] <Compn> i wonder if people would have to fork ffmpeg minus the encryption stuff (similar to flvstreamer ) [10:24:41] <Compn> if that was done [10:25:05] <Compn> people/distros [10:25:06] <hyc> that seems pretty unlikely. ffmpeg already has its own rc4 implementation [10:25:14] <hyc> nobody gives that a 2nd thought [10:25:34] <Compn> it doesnt have the ... secret code ... 'genuine adobe 001' or whathaveyou :P [10:25:52] <hyc> ohhhhh, the super secret master key..... :P [10:26:11] <hyc> you can't copyright a key [10:26:27] <hyc> there's no legal standing to stop anyone distributing it [10:26:45] <hyc> you can only copyright works of significant creative value [10:26:45] <Compn> tell that to the bluray (aasc?)lawyers [10:27:28] <hyc> I think the bluray story was more than the key, it was about the algorithm wasn't it? [10:27:37] <hyc> I don't remember the details [10:27:39] <Compn> no, it was just the key [10:27:53] <Compn> a string of numbers/letters [10:28:17] <Compn> but i dont think there was a lawsuit yet, i think they abandoned such a venture after the number was spread across them internets [10:29:20] <Compn> the guy in charge was interviewed and sounded like he actually understood what happened even [10:29:53] <Compn> http://en.wikipedia.org/wiki/AACS_encryption_key_controversy [10:30:50] <hyc> thx, was looking for that... [10:38:12] <hyc> illegal numbers, yeah right. nobody owns numbers. I hope they take this to court. when they lose, they can pay triple damages for racketeering. [10:38:59] <hyc> I wonder what those bytes do as 6502 opcodes. for all we know it's a useful instruction stream on some microprocessor out there. [10:39:27] <hyc> go back far enough and you might be able to sue them for violating your own copyright on this piece of vital program code ;) [10:41:41] <Compn> the mpaa spews fourth an amazing amount of crap lawsuits each year :( [10:47:10] <Compn> oh [10:47:27] <Compn> so rtmp stuff goes into ffmpeg, then rtmpsuck just calls ffmpeg ? [10:47:59] <Compn> could work. [10:48:14] <hyc> just thinking out loud [10:49:15] <mru> KotH: you're coming to linuxtag? [10:54:45] <hyc> wbs: re: the ffserver patches, why was the c= patch so easy to get in, but the rest are waiting? they're all trivially small, and the current code is obviously incorrect. [10:55:38] <hyc> nobody has gotten anything useful out of ffserver rtsp in years, it doesn't take a rocket scientist to see that... [10:56:20] <wbs> hyc: I guess it's all up to psychology, what motivates people to read the patches or not - since luca a ok'd it, baptiste just had to add that he didn't have any further objections [10:56:24] <Compn> not many people work / care about ffserver last i remember [10:56:35] <hyc> http://www.mail-archive.com/ffserver-user@mplayerhq.hu/maillist.html [10:56:41] <hyc> Compn: apparently that's true [10:57:09] <hyc> questions about ffserver rtsp simply go unanswered [10:57:23] * Compn laughs at browser being called a spambot by mail-archive.com [10:57:42] <Compn> ahh http referrer, my arch nemesis [10:58:22] <hyc> 2009/05/01 RTSP streaming using ffserver - no answer [10:58:44] <Compn> maybe if someone offered to maintain ffserver .... [10:59:09] <hyc> 2009/10/26 is rtsp output currently broken? - no answer [10:59:41] <hyc> heh. effectively I *am* maintaining it. but not effectively, because I can't actually commit any of the required fixes. :P [10:59:59] <Compn> cant you? heh [11:00:23] <Compn> svn access used to be linked , but maybe that was changed [11:00:37] <Compn> after the uau thing... [11:00:42] <hyc> I think I tried a test commit in the mplayer svn, couldn't do it [11:00:49] <Compn> ah, then probably not [11:01:15] <Compn> wbs has commit access tho [11:01:20] <hyc> and there's not much point in doing a commit without permission anyway [11:01:30] <hyc> would just get other people pissed off [11:01:53] <Compn> of course, i didnt mean to suggest that [11:02:30] <wbs> Compn: yeah, but i'd like to get some ack on the patches by someone a little bit more familiar with ffserver than me (i've hardly even looked at it) [11:02:55] <Compn> ffmpeg has some strict rules. [11:03:02] <wbs> once they're ok'd I sure can volunteer to commit them ;P [11:03:02] <hyc> sure it does [11:03:18] <hyc> regardless, I spent the better part of 2 days in quality time with gdb and wireshark [11:03:22] <Compn> it has to be reviewed, tested, pass regression tests, and ok'd by maintainer [11:03:32] <hyc> it's obvious the code was completely broken before [11:03:38] <hyc> and it is also obvious that it now works [11:03:39] <Compn> probably some valgrind and benchmarks just to be sure :) [11:03:53] <hyc> yes, some valgrind time too. you know me too well. :P [11:04:14] <Compn> i meant a ton of stuff in ffmpeg goes thru valgrind , but ok :) [11:04:46] <Compn> hyc : you using ffserver rtsp for your phone ? [11:04:51] <hyc> I'm not a novice programmer, I know when code is wrong and when it's right. and I take the steps necessary to prove it. ;) [11:04:55] <hyc> yep [11:05:07] <hyc> works like a charm now [11:05:32] <Compn> i think i'm waiting before cell phone data rate prices go down before i try any of that [11:05:57] <hyc> ah, the t-mobile google phone plan is unlimited data and text [11:06:16] <hyc> but the t-mobile network is ... spotty [11:06:38] <hyc> I did most of the testing on my home wifi, and then tried on t-mobile 3G after I had everything working [11:07:16] <Compn> i was just curious what people use rtsp for anymore :P [11:07:23] <ohsix> more like their affiliation; they lease [11:07:31] * Compn goes afk [11:07:42] <wbs> Compn: all mobile phones except microsoft and apple support that for video streaming [11:07:54] <hyc> I've decided to write a hulu-to-rtsp web page. navigate the hulu web site in one subframe, then click a link in the parent page to stream whatever is in the hulu frame. [11:08:19] <hyc> I think it will be just a few lines of javascript to manage that... [11:11:27] <hyc> maybe I should plug in the get-flash-videos script instead, then I can stream just about anything [11:12:26] <hyc> one downside is that rtsp is UDP and lossy. Most of the stuff you'd want to view out there is plain ol' http. [11:12:30] <Compn> tmobile has some lame clip site that mocks hulu dont they? [11:12:38] * Compn seems to remember something about verizon having a site [11:12:42] <hyc> no idea. [11:13:03] <hyc> I recall trying to run rtmpdump from my phone using their 3G and being blocked [11:14:40] <hyc> so ideally I would have the CGI on my web server fetch the video and then make it available using TCP to my phone. [11:15:04] <hyc> and then run ffserver on my phone to reframe it as rtsp for the local media apps to play [11:15:10] <hyc> talk about kludgy [11:15:31] <wbs> hyc: rtsp can do tcp-interleaved packet transport, too [11:15:39] <hyc> yes but my phone can't [11:15:43] <wbs> don't know how to request that in the on-device media players though [11:15:53] <hyc> apparently that's not implemented in the opencore code [11:16:13] <hyc> I have the full android source code too, but the opencore stuff is all crappy C++ code [11:16:39] <hyc> taking the route I've gone so far is much faster than figuring out how to connect librtmp into their framework [11:17:04] <hyc> kinda pathetic [11:17:07] <CIA-7> ffmpeg: mstorsjo * r23154 /trunk/ffserver.c: [11:17:07] <CIA-7> ffmpeg: ffserver: Write proper GMT date/times in Date headers [11:17:07] <CIA-7> ffmpeg: Patch by Howard Chu, hyc at highlandsun dot com [11:17:19] <wbs> there you go, one down ;P [11:17:23] <hyc> woohoo, thanks wbs ;) [11:17:51] <hyc> of course, that only fixes a bug that only people using wireshark will ever see. :D [11:18:14] <wbs> yeah, but nevertheless, one patch less in the review queue, once the almight maintainer decides to take a look :-) [11:18:39] <hyc> yep. (And considering how much I was using wireshark, that bug annoyed the piss out of me. ;) [11:19:29] <hyc> anyway, taking this route produces a solution (however kludgy) that works for any phone. [11:19:50] <hyc> adding librtmp to the android source will only help people willing to burn new firmwares on their phones [11:20:01] <KotH> mru: according to current planning, no [11:20:14] <wbs> yeah, and you get the option to downscale the video to get a version suitable just for the environment you're in [11:20:15] <KotH> mru: unless i've lots of luck [11:20:25] <KotH> mru: i send the posters to janneg this morning [11:20:27] <Compn> hyc : so , of course dumb question, ffplay cant handle playing on your phone because of a lack of hardware dsp decoder support? thats why you need the local programs [11:20:35] <KotH> mru: but i take a t-shirt anways :) [11:21:12] <hyc> Compn: I think it's more than that, you can't easily run native code in combination with the android UI [11:21:16] <hyc> it has to be java [11:21:33] <mru> there's the NDK [11:21:45] <wbs> mru: which is for building JNI components only [11:21:49] <hyc> yeah, but that's still a low-level thing [11:21:50] <wbs> officially at least [11:22:00] <hyc> you still have to paste a java front end on anything you write [11:22:12] <mru> yes, but you can run native code [11:22:12] <wbs> you interface with the platform solely through java, but can accelerate your app with algorithms in native code [11:22:40] <mru> so you could write a thin java launcher and do everything else in native [11:22:47] <hyc> right [11:22:59] <wbs> in principle, you actually can do UI through opengl in native code [11:23:40] <wbs> so ffplay with gl es output, and piping the audio over JNI to the java side for playback, could work [11:24:03] <hyc> I guess you could actually use libav to just grab the data and feed it to the android video api [11:24:14] <hyc> haven't looked into that at all [11:24:51] <wbs> if working with custom roms and not only the official api, that's a possibility, too - i don't think there's any such apis that would be usable in the official sdk [11:24:58] <hyc> haven't coded anything serious in java in 6-7 years either. the last thing I wrote in java just fork/exec'd a c program. [11:25:52] <hyc> I downloaded the newest Sdk but haven't looked inside yet [11:26:10] <hyc> just recently flashed cyanogen's eclair onto my g1 [11:27:40] <hyc> so I can test the newest APIs. but not really interested in being a java dev... [11:38:15] <Compn> a quick kludge is faster than a java wrapper anyways :P [11:39:36] <hyc> yep ;) [11:39:50] <wbs> hyc: when using ffserver, the ffmpeg process that feeds ffserver with data does the actual transcoding, and ffserver just relays the packets without {de,en}coding it, right? [11:40:34] <hyc> right [11:40:38] <wbs> ok [11:40:44] <hyc> but there's a catch [11:40:56] <hyc> the codec parameters are defined in the ffserver config [11:41:10] <hyc> they get written into the feed ffm file [11:41:33] <hyc> ffmpeg first does an http get on this file, and then does an http post with the transcoded stream [11:41:50] <wbs> is this all in lavf/ffm* or something? [11:42:01] <hyc> yes [11:42:18] <wbs> can you choose an encoder using a name, if there's multiple ones implementing the same format? [11:42:23] <hyc> nope [11:42:32] <hyc> it only stores the numeric codec ID in the ffm header [11:42:37] <wbs> ok [11:42:54] <hyc> also the ffm header is incomplete, compared to all of the possible config settings [11:43:33] <hyc> I mentioned this here several hours ago - it can be a problem, because ffserver actually generates the global header data that gets transmitted to an rtsp client [11:43:45] <hyc> but ffmpeg generates the stream data [11:43:57] <hyc> and ffmpeg's settings will be incomplete relative to ffserver's config [11:44:17] <wbs> yeah, that's the thing I was about to comment on - doing it that way feels like a hack [11:44:32] <wbs> since you can't really be sure that the extradata generated matches the one that ffmpeg would create [11:44:38] <hyc> exactly [11:44:49] <wbs> also, you leak the opened encoder in that patch [11:45:13] <hyc> well... it's hard to call it a leak, since that handle is open anyway for the life of the process [11:45:30] <hyc> it needs to be present [11:45:37] <hyc> if you close it the extradata will eb freed. [11:45:57] <wbs> well, if not sooner, it should be freed on exit [11:45:58] <CIA-7> ffmpeg: mstorsjo * r23155 /trunk/ffserver.c: [11:45:58] <CIA-7> ffmpeg: ffserver: Don't set me_method unconditionally [11:45:58] <CIA-7> ffmpeg: Patch by Howard Chu, hyc at highlandsun dot com [11:46:38] <hyc> hm. I assumed that closing the avcodecontext would do that. [11:46:56] <hyc> ooo, you're making me do another svn up. cool. ;) [11:47:14] <CIA-7> ffmpeg: mstorsjo * r23156 /trunk/ffserver.c: Cosmetics: reindent [11:47:50] <wbs> yeah, closing it should be enough [11:48:08] <wbs> is that done by the /* close each frame parser */ clause? [11:48:56] <hyc> hm I don't think so, that's per-connection [11:49:05] <hyc> the leak you're talking about is a global/master [11:49:23] <wbs> yeah, but that's the only avcodec_close I find in the file [11:49:48] <hyc> ok, then lemme take a closer look [11:50:05] <wbs> ok [11:50:13] <wbs> ideally would be to actually get the correct extradata from ffmpeg [11:50:31] <hyc> yes, I agree [11:51:07] <wbs> don't have any more time to spare, to dive into this at the moment, but at least some of the really obvious ones got commited ;P [11:51:11] <hyc> valgrind agrees with you, the codec is leaked [11:51:18] <hyc> thanks [11:51:27] <hyc> I'll plug the leak and repost [11:51:39] <wbs> ok [11:52:12] <hyc> I was thinking the other alternative was to add more fields to the ffm header [11:52:19] <wbs> I guess it would be good with a big fat todo/fixme note saying that the correct extradata should be fetched from ffmpeg, and a small explanation on why this isn't the case at the moment [11:52:35] <wbs> ah, so that's the reason why the correct extradata isn't used? that's way, way much better then [11:53:03] <hyc> yes, put the complete set of settings in so that it's possible for ffmpeg to generate the same result as ffserver expected [11:53:36] <hyc> your way is quicker ;) [11:53:49] <wbs> ah, but can't you send the actual extradata that was produced, through ffmpeg to ffserver? [11:54:03] <hyc> yes, in fact it is sent already, and ffserver discards it [11:54:21] <hyc> so like I said, your suggestion should be fast to implement [11:54:47] <wbs> ok, how much work would it be to actually use that instead of discarding it and making up new extradata which may or may not match the actual one? [11:55:06] <hyc> but ultimately i think it's not the correct thing to do. presumably the person configuring ffserver knows exactly what they want. [11:55:13] <hyc> ffmpeg needs to be faithful to that... [11:55:23] <wbs> yes, but extradata must match the actual data [11:55:32] <wbs> not the intended config [11:55:50] <hyc> right. so the proper fix is to make the actual data match the config. [11:56:35] <wbs> IMO the better solution would be to make sure the actual extradata that the real encoder that encodes the data produced [11:56:57] <wbs> otherwise you're just trying to patch things together, trying to produce a copy that hopefully matches [11:57:09] <hyc> ultimately I agree with you that the correct extradat must be used [11:57:31] <hyc> but ideally, what ffmpeg produces should be exactly what was configured in ffserver.conf [11:58:02] <wbs> if they're built with the exact same version, linking to the exact same version of libx264 etc [11:58:24] <hyc> yeah... ideal world. [11:59:00] <wbs> so preserving the correct copy of extradata would be robust, then as a secondary improvement one can try to make sure that all the correct parameters actually are passed from ffserver to ffmpeg [11:59:11] <hyc> ok [12:00:28] <hyc> I would feel more comfortable about this if it were possible to augment the settings ffmpeg gets from ffserver using the ffmpeg commandline [12:00:45] <hyc> but in my testing, ffmpeg's commandline settings were completely overridden [12:20:12] <hyc> hmmmmm. ffserver actually has no clean shutdown handler anywhere [12:20:55] <hyc> it doesn't trap sigint or sighup or any of the other usual suspects [12:21:02] <hyc> and it has no quit command [12:21:15] <hyc> so there is no way to make it clean itself up [12:21:22] <wbs> oh, great [12:25:54] <hyc> it's really not worth worrying about [12:26:14] <wbs> is there any global cleanup code at all in ffserver.c? [12:26:20] <hyc> nope, not a bit of it [12:26:36] <hyc> there's another leak too, the poll_table used in http_server's event loop [12:26:37] <wbs> ok, then I guess it's ok to leak global stuff as you like [12:26:55] <hyc> yeah, it's not something that grows over time [12:43:54] <mru> janneg: ping [12:46:29] <hyc> wbs: I'm wrong, ffserver keeps a copy of the extradata that ffmpeg sends. but it's not getting stashed in the right place. [12:46:59] <hyc> so I may be able to get rid of my extra avcodec_open, if I can figure out which stream structure it really belongs in [12:47:21] <wbs> ok, that's good news [13:07:39] <pentanol> hello, if I've got stream without duration, should I avoid dts then? [13:07:52] <mru> uh? [13:08:26] <pentanol> in source I receiver stream Duration: N/A, start: 0.000000, bitrate: N/A [13:08:54] <pentanol> duration doesn't exist because it's infinity stream form camera [13:09:17] <janneg> mru: pong [13:10:06] <mru> janneg: is mythtv registered for linuxtag or do you need a pass from us? [13:10:25] <pentanol> or, probablt in next:-9223372036854775808 dts:-9223372036854775808 off:0 0 dts such as unsigned value [13:10:37] <pentanol> probably* [13:12:04] <janneg> mru: mythtv is not registered. too few people for booth duty [13:12:33] <mru> ok, adding you to our list then [13:13:48] <pentanol> dts computed from stream duration? [13:14:10] <mru> uh? [13:14:45] <pentanol> what from dts computed?) [13:15:05] <janneg> thanks. Do you know how much wall space the booth has? I would guess there's not enough for the beast and my LCD [13:15:28] <mru> http://www.linuxtag.org/2010/dl/projects2010/Hall7.2b-14May.jpg [13:15:41] <mru> I don't know how final that floorplan is [13:15:58] <mru> but it looks like we have 5m of wall there [13:15:59] <mru> to share [13:17:26] <Kovensky> did you guys finish with rbultje [13:17:27] <Kovensky> er, BBB [13:18:31] <av500> mru: we need more monitors :) [13:19:25] <mru> we have janneg's 32" (?) LCD [13:19:33] <janneg> yeah, seen the floorplan, I wasn't sure if we have 2 or 3 open edges [13:19:37] <janneg> 37" [13:19:41] <mru> right [13:20:35] <pentanol> put ctrl and turn scroll ;) [13:20:43] <janneg> av500: I expect vlc and xbmc to bring some [13:20:51] <av500> janneg: I meant for the wall :) [13:21:02] <av500> mru: TI booth is in throwing distance [13:21:16] <mru> yep [13:21:22] <mru> so we can steal their beagles [13:21:26] <twnqx> TVs... so old :\ [13:22:24] <av500> mru: that is not enough to calm my anger... [13:22:42] <twnqx> Oo [13:22:44] <twnqx> oO [13:22:53] <twnqx> part delivery problems? :> [13:22:55] <mru> you're angry with TI? [13:23:35] <av500> twnqx: that too [13:23:58] <twnqx> friend of mine has some parts on backorder with delivery set for august... [13:24:51] <av500> no, they hurry to get our parts in time [13:32:37] <pentanol> hm, I tries playing few rtsp stream, one from youtube and another from my camera, youtube works sell, but with camera I've got [h264 @ 0x95be570]non-existing PPS referenced [13:33:29] <pentanol> also I tries different rates on the camera, looks like in demuxer everything well also, but it won't playing from my camera [13:35:24] <pentanol> also in demuxed I found oddly thing such as 32 -1 , why not just 31? [13:36:34] <mru> wow, only one build failure on FATE [13:38:52] <pentanol> lets fill it:) [14:03:31] <hyc> wbs: ok, posted the revised patch without extra avcodec_open()s [14:03:53] <hyc> and now plugging a lot of per-session leaks. fun fun fun. [14:15:03] <merbzt> hyc: MrNaz is a ffserver user, if you need something tested he might be able to help [14:17:31] <hyc> thanks merbzt [14:18:00] <hyc> MrNaz, have you looked at any of the ffserver patches I've posted? [14:49:14] <hyc> wbs: valgrind now reports 0 lost bytes... [15:09:27] <hyc> I find it hard to believe that *anybody* has been an ffserver user up till now [15:09:50] <hyc> this code is strewn with bugs. [15:59:53] <peloverde> The direct show SDK used to come with some ASF tools, do those tools (or modern equivalents) still exist? I can't find them in the "Windows SDK" [16:01:04] * av500 has then on his pc [16:01:57] <av500> peloverde: ping me if you cant find them [16:24:42] <kshishkov> BBB: please look at that patch from Chinese guy on removing redundant code from RM demuxer [16:32:28] <BBB> you already reviewed it [16:32:31] <BBB> patch is fine with me [16:39:41] <peloverde> I found a modern replacement but it is source only and requires ATL :( [16:41:59] <peloverde> (ATL not being supported by VC Express) [16:49:03] <BBB> kshishkov: apply it plaese? :) [16:53:05] <Compn> peloverde : all i remember is that microsoft threatened virtualdub to remove asf support. did they change since then? i dunno. [16:53:31] <Compn> peloverde : maybe you want the 'windows media sdk' ? [16:54:00] <Compn> http://msdn.microsoft.com/en-us/library/dd757738(VS.85).aspx [16:54:03] <_av500_> peloverde: ATL? [17:03:35] <janneg> are all patch monkeys on vacation? I'm waiting for two ok-ed patches to get committed [17:04:42] * janneg wonders how many reviewed patches get lost [17:07:22] <pJok> quite a lot probably [17:09:07] <janneg> I guess using patchwork is not an option for natsuki since it depends on django [17:10:27] <peloverde> ATL is a windows template library, 'windows media SDK' doesn't install on windows 7 but I need their mpeg-4 stack which only comes with windows 7 [17:14:45] <kierank> Have you looked at the DirectX sdk peloverde? ASF could be part of directshow [17:15:10] <peloverde> kierank: that stuff is all super deprecated [17:15:35] <_av500_> peloverde: what asf bits do you need? [17:15:41] <_av500_> their demo src code? [17:16:26] <peloverde> I want to see how their tools remux AAC from ASF to MP4 [17:16:35] <_av500_> ah [17:16:39] <peloverde> This tool seems perefect http://blogs.msdn.com/mf/archive/2009/12/02/mfsimpleencode.aspx [17:17:00] <_av500_> the ones i have prolly dont do that at all [17:17:44] <peloverde> yeah have have the old tools in a milk carton with an ASF T-shirt, that was a fun promotion [17:19:23] <peloverde> The old tools *might* be capable of remuxing it to something but ideally I'd like to use a mediafoundation tool [17:22:33] <peloverde> This demo seems to build :) http://blogs.msdn.com/mf/archive/2009/12/16/mfcopy.aspx [17:29:06] <CIA-7> ffmpeg: bcoudurier * r23157 /trunk/libavformat/mpegts.c: [17:29:06] <CIA-7> ffmpeg: In ts demuxer, output pes packet as soon as they are complete. [17:29:06] <CIA-7> ffmpeg: This is needed for subtitles where packets are infrequent. [17:29:06] <CIA-7> ffmpeg: Patch by Janne Grunau, janne-ffmpeg at jannau dot net. [17:36:53] <janneg> thanks bcoudurier [17:40:57] <mt> BBB: fwiw, samples_per_frame in wma pro isn't per channel. (And there was nothing wrong with *data_size, my brain was just playing tricks on me I guess :) ) [17:42:53] <BBB> ok, great :) [17:43:17] <BBB> janneg: ping me later today and I might be able to apply for you [17:43:22] <BBB> give me some time for now [17:44:47] <janneg> BBB: no hurry, I was going to ping on the ml anyway [19:17:31] <CIA-7> ffmpeg: cehoyos * r23158 /trunk/ (4 files in 2 dirs): [19:17:31] <CIA-7> ffmpeg: Factorize some code into the new function ff_toupper4(). [19:17:31] <CIA-7> ffmpeg: Patch by Francesco Lavra, francescolavra interfree it [19:22:26] <peloverde> Do people have thoughts on the "best" way to handle \0 padded audio packets? [19:23:01] <peloverde> The situation is pretty common with AAC in ASF [19:23:21] <peloverde> And Quicktime will the equivalent MP4s [19:24:21] <CIA-7> ffmpeg: cehoyos * r23159 /trunk/libavformat/utils.c: [19:24:21] <CIA-7> ffmpeg: Validate AVCodecTag vs CodecID. [19:24:21] <CIA-7> ffmpeg: Patch by Francesco Lavra, francescolavra interfree it [19:24:50] <peloverde> I was thinking a "chomp" BSF might be the best approach [19:25:09] <_av500_> how does it know what to chomp? [19:25:49] <bcoudurier> hi guys [19:26:00] <peloverde> chomp a string of zero bytes from the end of the packet until content is hit [19:26:48] <_av500_> and content can never have a 0? [19:27:12] <peloverde> An aac frame ends with 0b111 \bytealign [19:28:39] <_av500_> ic [19:29:25] <wbs> if a decoder is available, it can return how many bytes it consumed, too, but that's a bit out of place in demuxers [19:30:54] <peloverde> An ADIF parser could also solve this, but an ADIF parser is basically a full decode and we don't have an ADIF parser [19:33:52] <CIA-7> ffmpeg: mstorsjo * r23160 /trunk/libavformat/ (sdp.c internal.h): [19:33:52] <CIA-7> ffmpeg: Make ff_sdp_write_media a lavf-internal function [19:33:52] <CIA-7> ffmpeg: This is in preparation for RTP hinting in the MOV muxer, where [19:33:52] <CIA-7> ffmpeg: it needs to be able to create SDP fragments for each media stream. [19:34:36] <_av500_> adif? [19:34:47] <_av500_> adif is just a header, no? [19:35:11] <CIA-7> ffmpeg: mstorsjo * r23161 /trunk/libavformat/ (options.c avformat.h): Add a flag for enabling RTP hinting [19:35:17] <wbs> _av500_: you might be thinking of ADTS... I think ;P [19:35:31] <hyc> wbs: since you're tweaking sdp right now.... [19:35:41] <_av500_> no, adts is like mp3 framing [19:35:49] <_av500_> one header per frame [19:36:48] <hyc> one of the problems I found with ffserver streaming an flv file is that extradata2psets() doesn't recognize the extradata read from the flv file [19:37:06] <hyc> the extradata doesn't start with the start sequence [19:37:14] <peloverde> ADIF is an ASC like header with followed by concatenated RDBs [19:37:18] <peloverde> no framing [19:37:30] <hyc> of course ff_h264_decode_init() still handles it just fine [19:37:38] <wbs> hyc: ok.. no idea about that, I don't know the h264 details too well [19:38:01] <hyc> i was just in the midst of writing a patch for this when I saw your commit come across [19:38:10] <wbs> ah [19:38:16] <wbs> I'm just applying a month old code ;P [19:38:24] <hyc> i don't know the details too well either, so it's been a slow process [19:39:34] <CIA-7> ffmpeg: mstorsjo * r23162 /trunk/libavformat/ (movenc.c movenc.h): Move the mov muxer structures to a separate header [19:40:06] <_av500_> peloverde: you have a sample of aac/h264 in asf somewhere? [19:40:47] <hyc> if you look at libavcodec/h264.c ff_h264_decode_init() you see two cases. one where the extradata starts with the synch code, and one where it starts with 0x01. [19:41:07] <CIA-7> ffmpeg: mstorsjo * r23163 /trunk/libavformat/ (movenc.c movenc.h): Make mov_write_packet non-static, add ff_ prefix [19:41:32] <hyc> for the latter case it sets this flag h->is_avc=1 [19:41:41] <hyc> for the start-sequence case it sets it to 0 [19:41:56] <hyc> of course I have no idea of the significance of any of this... [19:42:41] <_av500_> hyc: 2 ways of storing the extradata [19:43:01] <wbs> I think it alters the format of the actual data packets, too [19:43:19] <peloverde> _av500_: I have a sample, I'm not sure if I can redistribute it [19:43:19] <wbs> and when packetizing h264 into RTP, it probably assumes either one of the formats [19:43:48] <hyc> well, I'm going to take a stab at stuffing something in here and seeing if ffplay likes it [19:43:51] <wbs> it _may_ be possible to alter it from one to another through some bitstream filter [19:43:54] <wbs> iirc [19:44:04] <hyc> the start sequence is omitted anyway in the sdp header [19:44:58] <_av500_> wbs: right, different way to store payload as well [19:45:03] <wbs> yes, but you may probably want to check what rtpenc_h264.c does, too - "fixing" the SDP in this case probably isn't enough [19:45:20] <wbs> there's some h264 annex b bitstream filter, it may (or may not) be what you need [19:48:17] <CIA-7> ffmpeg: mstorsjo * r23164 /trunk/libavformat/ (movenc.c movenchint.c Makefile movenc.h): Add initial support for RTP hinting in the mov muxer [19:49:20] <CIA-7> ffmpeg: mstorsjo * r23165 /trunk/libavformat/ (movenchint.c movenc.h): Use a heuristic for describing the RTP packets using sample data [19:53:34] <peloverde> _av500_: h264_aac_zeropad.asf in /incoming [19:57:51] <_av500_> peloverde: i guess i am unworthy of downloading from there... [20:18:22] <janneg> bcoudurier: thanks and sorry for the tabs. caused by quickly extending the comment with vim [20:19:10] <bcoudurier> annoying :) [20:19:31] <mru> M-x untabify ftw [20:20:01] <peloverde> :set et:retab [20:20:49] <drv> to quote the eloquent avcoder: "Dear: The patch is full of TAB" [20:21:15] * mru likes that quote [20:21:18] <mru> is it on the wiki? [20:21:21] <drv> probably not [20:21:37] <peloverde> file a bug against the wiki :) [20:22:39] <drv> https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/059550.html [20:23:24] <drv> it always makes me think of the soda [20:23:33] <drv> but i don't know if they even have tab elsewhere [20:28:30] <mru> you mean the diet coke in a different-coloured can? [20:28:48] <mru> haven't seen that one in a long time [20:29:05] <drv> they still make it, just not very common [20:29:05] <mru> maybe they don't have it here [20:29:09] <drv> and rather disgusting taste :) [20:29:23] <mru> diet coke by any other name is still diet coke [20:29:52] <mru> not as disgusting as vanilla coke though [20:36:34] <janneg> mru: and then there's Diet Vanilla Coke (http://whyjointhenavy.wordpress.com/2010/02/20/list-of-coca-cola-flavors/) [20:37:04] <Dark_Shikari> nothing beats pepsi ice cucumber [20:37:56] <kierank> nothing beats irn bru [20:38:47] * mru is reminded of some of the more obscure "festis" flavours [20:38:51] <mru> like "cactus lime" [20:39:18] <wbs> cactus lime festis is quite good [20:39:52] <mru> some KTH students invented a few others in Blandaren or another similar-spirited publication [20:40:00] <mru> one of the best: gädda mango [20:40:06] <wbs> haha [20:40:25] <mru> that's a large fish [20:40:38] <mru> don't know the english name [20:42:06] <wbs> northern pike [20:42:32] <mru> and what's english for krongädda? [20:43:12] <mru> as if they existed [20:43:50] <janneg> Crown pike [20:43:57] <mru> yes, that's what google says [20:45:02] <mru> and it is indeed the literal translation [20:45:28] <mru> but I'd be surprised if anyone understood it [20:49:56] <janneg> 442 google results and the top ones don't look related [20:51:11] <mru> the only first-page hit of relevance refers to the swedish term [20:54:21] <kierank> whoops [20:54:28] <mru> nice quit message [20:54:39] <janneg> swedish wikipedia page has no other language links, and I don't know if there's a german translation [20:56:54] <ramiro> hm, asf_read_pts() uses variable length arrays... do we have many such functions in ffmpeg? [20:57:15] <mru> wbs: do you have them in finland or it is a purely swedish thing? [20:57:37] <mru> ramiro: I'm on a slow crusade against them [20:59:09] <ramiro> linking on x86_64-w64-mingw32 with some bogus libraries gave me undefined errors for __chkstk() on a bunch of functions. [20:59:24] <ramiro> that was the first one I checked and it had vla [20:59:35] <mru> that's a win32 abi thing [20:59:49] <mru> any function using more than a page of stack has to call it [21:00:18] <mru> and since a vla might be any size, I guess it gets called there too [21:00:38] <mru> what runtime were you linking against? [21:03:00] <ramiro> mingw-w64-crt [21:03:14] <janneg> mru: one good aspect of C++. VLA are not in the spec. not that it prevents g++ from supporting them but clang++ doesn't [21:03:17] <ramiro> the default one, -lmsvcrt I guess [21:03:41] <mru> janneg: but c++ has exceptions, which are every bit as bad [21:05:08] <janneg> not trying to claim that missing VLA makes C++ bearable [21:06:46] <mru> we are all doomed: http://gcc.gnu.org/wiki/gcc-in-cxx [21:09:13] <drv> well, it can barely be worse than the existing "C" source [21:09:27] <mru> that's the problem [21:09:54] <mru> if you take C code as found in gcc and convert it to C++, you'll end up with something truly disgusting [21:10:40] <janneg> lol "C++ is a standardized, well known, popular language." as reason for migrating to c++ [21:11:05] <mru> that page is the most dense collection of lies I've seen since I read xiph.org [21:11:07] <drv> they already have their own garbage collector/allocator thing [21:22:20] <CIA-7> ffmpeg: conrad * r23166 /trunk/libavformat/matroskadec.c: [21:22:20] <CIA-7> ffmpeg: matroskadec: Use av_freep in ebml_read_ascii [21:22:20] <CIA-7> ffmpeg: Based on a Chromium patch [21:22:20] <CIA-7> ffmpeg: conrad * r23167 /trunk/libavformat/matroskadec.c: [21:22:20] <CIA-7> ffmpeg: matroskadec: Ensure time_scale is nonzero, fixes divide-by-zero if the file [21:22:21] <CIA-7> ffmpeg: has 0 written [21:22:22] <CIA-7> ffmpeg: Based on a Chromium patch [21:22:22] <CIA-7> ffmpeg: conrad * r23168 /trunk/libavformat/matroskadec.c: [21:22:23] <CIA-7> ffmpeg: matroskadec: Fix buffer overread in matroska_ebmlnum_uint [21:22:23] <CIA-7> ffmpeg: Based on a Chromium patch [21:22:24] <CIA-7> ffmpeg: conrad * r23169 /trunk/libavformat/matroskadec.c: [21:22:24] <CIA-7> ffmpeg: matroskadec: Free ebml binary buffer on error [21:22:25] <CIA-7> ffmpeg: Based on a Chromium patch [22:09:32] <hyc> hmm. I dunno if there's any way to configure ffserver to insert a bitstream filter [22:57:12] <Compn> whats chromium doing with mkv input hmmmmm [22:57:24] <Compn> general purpose html5? [22:57:30] <Compn> not just h264+mp4 ? [22:59:17] <Dark_Shikari> it seems someone else spotted it too =p [22:59:58] <kierank> i wonder if they could make subtitles work too [23:00:10] <Dark_Shikari> sure, around the time that pigs fly [23:23:56] <astrange> ask hixie [23:24:38] <astrange> his current idea for html5 subtitles is srt + some extra styling, the aegisub people are trying to finish an ass successor so it can be submitted instead

1 0

IRC log for 2010-05-17
by irc＠mansr.com 18 May '10

18 May '10

[06:08:45] <benoit-> good morning ! [06:12:04] <j-b> 'morning [06:12:10] <av500> 'jour [06:15:13] <thresh> mourning [06:17:37] <superdump> mornin [06:49:34] <hyc> anyone know what goes into the H264 extradata? [06:49:53] <hyc> still trying to figure out the difference between a program served by DSS vs one served by ffserver [06:50:09] <merbzt1> SPS ? [06:50:19] <wbs> SPS and PPS, yes [06:50:20] <hyc> the only significant difference in the SDP is this [06:50:48] <hyc> sprop-parameter-sets=Z0LAFZpyA8EdCAAAAwAIAAADAYB4sXJA,aM4yyA== [06:50:52] <hyc> G1 rejects that [06:51:06] <hyc> sprop-parameter-sets=Z0LAFZpyA8Ef1gIgAAADACAAAAYB4sXJ,aM4yyA== [06:51:11] <hyc> G1 accepts that. [06:51:49] <hyc> but as near as I can tell, I have the identical vcodec options passed to ffmpeg in both cases [06:52:14] <hyc> the working case is produced by ffmpeg feeding to DSS over rtsp [06:52:30] <hyc> the non-working case is ffmpeg feeding to ffserver / ffm [06:53:11] <hyc> feeding to DSS: [06:53:14] <merbzt1> is the SDP string BASE64 encoded ? [06:53:27] <hyc> looks like it, yes [06:54:07] <hyc> ./ffmpeg -i test.flv -vcodec libx264 -b 300000 -vpre default -vpre baseline -s 480x270 -acodec copy -re -f rtsp rtsp://localhost/test.sdp [06:54:20] <hyc> that works [06:55:18] <Dark_Shikari> if you want CBR, you probably want maxrate/bufsize too. [06:55:21] <hyc> ./ffmpeg -i test.flv -threads 0 http://192.168.1.25:8090/feed1.ffm [06:55:40] <hyc> this obviously depends on the settings in ffserver.conf [06:55:54] <hyc> I copied in all of the vpre settings so it should be identical [06:55:56] <hyc> and yet it's not [06:56:45] <hyc> ffserver was using CBR by default, and that still didn't work [07:05:06] <hyc> so how do I correlate this encoded SPS back to the x264 encoder settings? [07:09:18] <Dark_Shikari> hyc: you're better off looking at the SEI [07:09:26] <Dark_Shikari> Which ffmpeg conveniently prints for you on stderr. [07:10:12] <hyc> Dark_Shikari: I've been looking but I thought they were identical already [07:10:18] <hyc> lemme pastebin... [07:11:41] <hyc> here's the working invocation http://hyc.pastebin.com/C8qgN8cE [07:13:35] <hyc> here's the non-working ... http://hyc.pastebin.com/RR7pK635 [07:14:21] <Dark_Shikari> wtf is with that ratetol [07:14:49] <hyc> dunno, ffmpeg and ffserver provide it by default [07:15:01] <Dark_Shikari> you mean that you forgot to set it correctly [07:15:02] <Dark_Shikari> also neither has vbv set [07:15:17] <hyc> I've been pecking at it to get ffserver to match the ffmpeg output [07:15:31] <hyc> ffserver had vbv set by default, I turned it off to make the output match up [07:15:49] <hyc> ffserver also defaulted to cbr [07:16:42] <hyc> but none of that made a difference, the G1 still quits as soon as it reads the sdp [07:17:36] <hyc> (and it works fine with audio-only) [07:18:21] <Dark_Shikari> >defaulted to cbr [07:18:23] <Dark_Shikari> it says "abr" here [07:18:28] <Dark_Shikari> and yes this is probably not related to your problem [07:18:40] <hyc> right, I #if'd out that code in ffserver so that it would use abr [07:18:58] <hyc> this is several iterations from where it started... [07:24:02] <hyc> so, any suggestions on how to approach this? [07:25:17] <Dark_Shikari> sounds like a protocol/muxer issue [07:28:21] <pJok> mornings :) [07:34:17] <KotH> a wonderfull good morning everyone! [07:34:24] <thresh> :( [07:34:31] <kshishkov> goda morgnar, pJok [07:34:43] * KotH gives thresh some swiss chocolate [07:34:44] <kshishkov> KotH: looks like you're wrong again [07:34:56] <thresh> KotH: not a big fan :) [07:35:01] <KotH> kshishkov: no problem that a bit of swiss chocolate cannot solve! :) [07:35:16] <thresh> really tough weekend + almost no sleep for two days [07:35:34] <Dark_Shikari> speaking of sleep, I should take a few hours nap before finishing packing [07:35:51] <Dark_Shikari> spent all of today reading on2 code, it wears out the mind. [07:36:52] <kshishkov> KotH: try diabetes or allergy [07:37:01] <Dark_Shikari> and worse, on2 specs [07:37:10] <kshishkov> Dark_Shikari: why would you do that? [07:37:29] <av500> VP9!!!! [07:37:39] <hyc> lol [07:38:10] <hyc> kinda how I feel after all this beating on ffserver [07:38:16] <KotH> kshishkov: the people i know who've diabetes, always carry a bar of chocolate with them :) [07:38:18] <Dark_Shikari> kshishkov: so I can beat the shit out of it in a detailed blog post on wednesday [07:39:01] <KotH> kshishkov: and as for allergy... i've never hread that anyone has a chocolate allergy [07:39:29] <wbs> KotH: my girlfriend is allergic to chocolate [07:39:39] <KotH> wbs: huh? [07:40:57] <KotH> wbs: poor girl... [07:41:27] <wbs> KotH: not the "deadly if eaten" kind of allergy, though, it just makes her itch a bit [07:41:36] <wbs> just as does peppers and onion and a few other vegetables [07:41:44] <wbs> a bit of antihistamines and everything's fine again [07:41:44] <kshishkov> garlic? [07:42:08] <av500> in swiss chocoloate? [07:42:09] <wbs> kshishkov: hmm, don't remember about that, but perhaps yes [07:42:28] <kshishkov> wbs: silver? holy sulphuric acid? [07:42:49] <pJok> goda morgonar, kshishkov :) [07:42:57] <KotH> wbs: you sure it's an allergy to chocolate and not to nuts? [07:42:58] <kshishkov> av500: if not in Swiss chocolate then in Japanese one for sure [07:42:58] <hyc> a girl I grew up with was allergic to chocolate. she ate a piece of chocolate cake and vomited a few minutes later. nasty... [07:43:15] <av500> nice end to a romantic diner... [07:43:46] <wbs> KotH: nuts is a problem too, but I think the raw cocoa has the same effect, too [07:44:17] <KotH> hmm.. strange [07:44:21] <KotH> first time i hear that [07:44:32] <KotH> hyc: you sure it's not some psychosomatic form of bullemia? ;) [07:45:12] <wbs> kshishkov: no problems with silver as far as I know :-) [07:45:52] <hyc> no idea, this is 30-some years ago, that wasn't trendy then [07:47:02] <kshishkov> wbs: fine. Although your Fazer chocolate is rather good. [07:47:50] <wbs> kshishkov: yeah, fazer's blue is fantastic. :-) [07:49:47] <spaam> so this is the new chocolate channel? :D [07:51:16] <spaam> blame KotH for that .. [07:51:43] <KotH> spaam: trying to get the blame to other people? [07:52:19] <spaam> yes. [07:52:31] <spaam> but i was right :) [07:53:48] * KotH kicks spaam [07:53:51] <KotH> no, you're not [07:54:16] <spaam> dont kick me! [07:54:43] <spaam> its always you when someone speak about chocolate.. [07:54:52] <spaam> you live in .ch :P [08:00:06] <KotH> ofc, i know why i live here [08:00:33] <av500> KotH: speaking of chocolate... [08:01:27] * KotH knows [08:01:38] * KotH has not forgotten about it [08:01:41] <av500> :) [08:01:53] <KotH> i just didnt had time to go to the good shops yet [08:01:55] <KotH> :-( [08:03:01] <spaam> poor thing. :( [08:06:04] * kshishkov now lives in little Switzerland too [08:09:52] <kshishkov> it's so Swiss that in the nearest supermarket people say "Salaam aleikum" [08:16:18] <av500> kshishkov: you met KotH in your supermarket? [08:16:48] <spaam> av500: do you think KotH working there? :D [08:18:20] <kshishkov> av500: no, but I can recognize that name like "Abdul Kerim" is Swiss when I see one [09:54:49] <CIA-7> ffmpeg: benoit * r23150 /trunk/libavcodec/raw.c: Fix typo ('B', 'O', 'W', '1') => ('B', '0', 'W', '1') [10:39:35] <hyc> Well, I have ffserver working with my G1 now [10:39:46] <hyc> but I have to figure out which of a bunch of changes was responsible... [10:48:18] <Tjoppen> no Bultje here atm it seems. I'd ask him to review my updated HTTP patch [10:48:43] <kshishkov> Tjoppen, he usually appears here at 14-15 CET [10:48:57] <Tjoppen> ah, ok [11:22:48] <av500> ...(a)tataelxsi.co.in why am I not surprised.... [11:23:12] <kshishkov> why should you? [11:29:46] <jai> :) [11:33:59] <wbs> hyc: the SDP/ffserver hack you posted... [11:34:57] <wbs> hyc: can you solve it within ffserver instead? e.g. something like this: http://pastebin.org/243967 [11:36:29] <wbs> hyc: the sdp generator can emit the c= line at a few different places, and your patch would make it emit that line redundantly/erroneously at some places [11:41:10] <hyc> wbs: hmmm.... I'll take a look [11:42:37] <hyc> your patch isn't quite right. we just need an IP address, not an rtp URL [11:43:55] <hyc> ohhhhh [11:43:57] <hyc> I see. [11:44:16] <hyc> you pass in the URL and avf_sdp_create puts an address there [11:44:21] <wbs> exactly [11:44:33] <hyc> ok, lemme try that [11:44:51] <hyc> can't we put the actual interface address of the incoming connection? [11:44:58] <hyc> this is the server's address, right? [11:45:23] <wbs> yes, but this should be the remote peer's address iirc [11:45:58] <hyc> the rfc language takes several re-reads to understand that point [11:46:14] <hyc> or I'm just tired from staring at this for the past 20 hours [11:48:21] <hyc> hmm. rtsp_cmd_describe already uses getsockname to get the local address [11:49:11] <hyc> ok this should be easy then [11:49:35] <wbs> nevertheless - SDP is used for describing RTP sessions in general - when RTSP is used for setting it all up, the destination address is implied in that, and the server usually just sets 0.0.0.0 there [11:50:29] <hyc> so you think 0.0.0.0 is still fine? [11:50:50] <hyc> easy enough to call inet_ntoa here, just like for the multicast addr [11:51:05] <wbs> 0.0.0.0 should be fine for unicast, yes [11:51:10] <hyc> ok [11:54:54] <hyc> yeah, that works fine [11:55:17] <hyc> should I followup my email or should you? [11:55:35] <wbs> ok, great, that has a much higher chance of getting accepted :-) [11:55:56] <wbs> did you do the same modification as I showed on pastebin, or were there any modifications? i didn't even test compile it [11:56:07] <wbs> but I can post a follow-up now at least [11:56:08] <hyc> exactly what you pasted [11:57:39] <wbs> ok, I'll post that to the list then [11:57:53] <hyc> cool [11:59:02] <hyc> it's still not all perfect. mplayer shows an endless stream of "non-existing PPS referenced" when playing a/v [11:59:29] <hyc> ffplay logs that too, but not as annoyingly [11:59:46] <wbs> yeah, I think I've seen that in all cases of h264/rtp [12:00:40] <hyc> hm, ok [12:01:01] <hyc> well, it's all streaming nicely to my phone, and that's all that I cared about ;) [12:01:06] <wbs> :-) [12:02:14] <Compn> there was a patch for that pps thing i thought ? [12:02:28] <hyc> really? is it recent? perhaps I need to svn up [12:02:49] <wbs> no, I still get those warnings with the latest stuff [12:02:55] <hyc> ffserver is still a pig though, eating 100% CPU [12:03:10] <hyc> that's one really nasty input loop.... [12:04:00] <hyc> I might try disabling chunked encoding and see if that lightens the load. is there any paraticular benefit to chunked encoding here? [12:04:10] <merbzt1> ffserver ACL is buggy also [12:04:16] <merbzt1> feel free to fix [12:27:37] <hyc> all of it is buggy... [12:27:56] <hyc> plenty to fix, not much time though [12:28:23] <hyc> speaking of which, on its RTSP/HTTP headers it responds with the date/time in localtime but with a GMT designation [12:28:30] <hyc> pretty silly [12:35:37] <hyc> wbs: thanks again for all your help [12:36:17] <wbs> hyc: no problem, it's more or less the same things I've fought lately :-) [12:37:40] <hyc> yeah well it's always easier when you know someone else has hit the problems. then it's not just you being a dummy... ;) [13:27:43] <BBB> wbs: for patch #1, is it possible to position rtp_parse_packet_internal() above rtp_parse_packet()? that way, you don't need the ugly fw function declaration [13:28:08] <wbs> BBB: yes, fully possible, but the diff is much smaller that way. I'll change it that way if you prefer that [13:28:23] <BBB> diff size for cosmetic patches isn't all that important to me... [13:28:32] <BBB> as long as they're just cosmetic :) [13:29:22] <wbs> yeah, but since it's both split + move, it's a bit harder to see whether anything was changed in the move or not... since the function preamble and the variable declarations are changed anyway [13:29:38] <wbs> and for the noreorder thing, yes, that can be passed as a parameter, too [13:29:51] <BBB> I'm nitpicking there ... [13:29:59] <BBB> I'm reviewing patch #2 right now, that's the actual patch [13:30:04] <BBB> I like most of it [13:30:24] <BBB> can you document the 4 variables in a doxy block, and then each individually? [13:30:42] <BBB> like /** stuff for packet reordering\n@{*/ [13:30:54] <BBB> and then /**@} */ at the end [13:31:01] <wbs> do you have any opinion on the thing that luca a pointed out - how to pass the desire from the user not to have any reordering, or to specify a max queue length? [13:31:07] <BBB> and then document each variable that you added to rtp.h [13:31:19] <wbs> ah, that's a good idea, too. I'm not that familiar with advanced doxygen syntax :-) [13:31:32] <BBB> wbs: I think that is a similar issue as things like passing tcp/udp as a preference [13:31:50] <BBB> we don't really do that, we should, keep that in mind while designing it but I don't have a clear answer on how it should be done [13:31:57] <wbs> ok [13:32:03] <BBB> I think we need an AVOptions passed to demuxers for demux-specific options [13:32:06] <BBB> like tcp, udp, etc. [13:32:12] <BBB> and then integration of that in ffmpeg.c/ffplay.c [13:32:15] <BBB> but that's a lot of work [13:32:20] <BBB> I don't want to require you to do that for this [13:32:52] <wbs> so as long as the max queue length is dynamic in the external interface of rtpdec, the rest is another problem to solve [13:33:20] <BBB> add a max as a variable, or as a define (for now) [13:33:26] <BBB> make sure it doesn't grow to infinity [13:33:29] <BBB> then it's fine, yes [13:34:26] <wbs> ok [13:34:40] <wbs> thanks for the input, I'll probably fix those things later today [13:35:37] <BBB> ok [13:35:39] <wbs> as a side note, ffplay is notoriously bad at playing rtsp stuff; -noframedrop usually is required, and since it sometimes waits quite long between av_read_frame() calls, it may easily drop packets when using UDP [13:35:45] <BBB> if you're interested I can lay out this whole demux-specific options [13:35:53] <BBB> it's a big FIXME and I'm trying to motivate people (or myself) to do it [13:36:08] <BBB> ffplay always worked fine for me... [13:36:10] <BBB> not sure what's wrong [13:36:14] <BBB> we might want to look into that [13:36:20] <BBB> maybe it's related to all the timestamp fixings lately [13:36:23] <BBB> they might've broken things [13:36:36] <wbs> no, things were broken both before and after that [13:37:01] <wbs> the frame dropping introduced in march (iirc) has some problems in some cases, I think luca a ran into it with v4l devices, too [13:37:40] <wbs> I guess it's common to all realtime sources [13:41:53] <BBB> hm... [13:42:02] <BBB> I haven't looked lately but don't remember that form last year [13:42:05] <BBB> let's look into that [13:42:07] <BBB> I'll give it a go also [13:42:13] <BBB> demuxing should be flawless [13:42:22] <wbs> yes, the demuxing works just fine [13:42:41] <wbs> the frame dropping was added quite only a few months ago [13:43:14] <wbs> either when starting a rtsp stream, or after seeking, things may either work well, or start stuttering, or stop completely [13:44:15] <wbs> the timestamps of the returned packets are correct, but if they are returned slightly too late (e.g. blocking a second before the first packet), ffplay notices that it's processing a packet with timestamp 0, while it should be at play time around (e.g.) 1 second [13:44:44] <wbs> so it notices that it's behind and drops the frame in order to get back up to speed [13:44:58] <wbs> but since the source is a realtime source, you can't advance faster by skipping frames [13:57:54] <BBB> wbs: right... we need to work on fixing that [14:07:48] <BBB> wbs: is prev_ret to distinguish handling of internal parsers returning versus you returning 1 because of multiple packets in-queue? [14:08:09] <wbs> BBB: yeah, exactly [14:08:22] <BBB> because if that's the case, I think A) it should be documented, B) it should check that it's != 0, but that it's == 1 [14:08:29] <BBB> you're forgetting the < 0 return case [14:08:46] <wbs> ah, yeah [14:09:08] <BBB> also, the rv | has_more_packets(); handling isn't right [14:09:17] <BBB> it should use ||, not | [14:09:29] <BBB> i.e. if rv = 1 or -1 or anything < 0, it should return just that [14:09:36] <BBB> it should only return 0/1 for more packets if rv == 0 [14:09:59] <wbs> hmm, that works too - currently, if rv is either 1 or -1, | 1 doesn't do anything [14:10:09] <wbs> but using || probably is neater [14:12:02] <BBB> I'm affraid if you return anything else <0, it might confuse the error code [14:12:10] <BBB> if it's even and we have packets left, |1 will make it odd [14:12:13] <BBB> so it changes the errno [14:12:17] <wbs> true [14:12:54] <BBB> enqueue_packet() laeks memory if we're dropping the last packet [14:13:53] <BBB> can you document what the intended handling is in case we actually really lost a packet? [14:14:12] <BBB> should we wait forever until it comes in? should we just go with whatever we have and drop if it comes in later? [14:14:16] <BBB> is there code handling this? [14:14:22] <wbs> hmm, i don't see how it could leak anything [14:14:28] <BBB> if queue_len = 10 [14:14:38] <BBB> and I insert in position 5 [14:14:47] <BBB> I move 6-10 to 7-10 and drop old#10/new#11 [14:15:04] <wbs> no, the queue will never get that full [14:15:18] <wbs> since after enquing one packet, we consume the first one if the packet became full [14:15:20] <BBB> oh I see the code after enqueue_packet() always empties it if it's full [14:15:33] <BBB> ok that's good [14:15:50] <wbs> and if we totally miss a packet, the queue will fill up [14:15:53] <BBB> can you assert that queue_len < MAX_QUEUE_LEN in enqueue_packet? [14:15:59] <BBB> just to make clear that's the intended behaviour [14:15:59] <wbs> sure [14:16:20] <wbs> and if we actually receive the missed packet sometimes later, we ignore it [14:16:28] <BBB> looks pretty good then [14:16:34] <wbs> that way, we get just one discontinuity instead of 3 [14:16:37] <BBB> yes [14:17:17] <BBB> ok, can you please document that a little bit clearer (in enqueue_packet, refer to rtp_parse_packet(), and in rtp_parse_packet() that code block, document it in actual works for the people with a short memory like me) [14:17:42] <BBB> and I think then it should be fine [14:18:00] <wbs> great, thanks! [14:18:12] <wbs> I'll go through this later tonight, hopefully, and resend it then [14:18:22] <BBB> ok, take your time, thanks for this patch, another long-awaited one [14:25:24] <Tjoppen> BBB: did you get a chance to look at my revised HTTP patches? [14:26:20] <BBB> a little, but not completely [14:26:26] <BBB> I'll try to re-look today [14:26:27] <BBB> sorry :( [14:27:48] <Tjoppen> np :) [14:31:40] <BBB> heya spyfeng [14:31:50] <Tjoppen> ooh, NetBeans 6.8 can create new projects from CMakeLists.txt files [14:31:51] <BBB> did michael already ok your mms-tcp patch? [14:33:10] <kshishkov> BBB, have you worked on supporting different interleavers for RM? [14:34:51] <BBB> no [14:35:01] <kshishkov> we may need it [14:35:19] <av500> we need RM? [14:36:07] <kshishkov> yep, for completeness sake [14:36:50] <kshishkov> and if you ask that question then Archos is not popular in China [14:37:59] <kierank> presumably chinese will use AVS in rm? [14:38:21] <kshishkov> only if Buffering Inc. will cripple it into RV5 [14:40:09] <av500> kshishkov: it is, but we do not encode, just play back :) [14:40:10] <kierank> rv5 will be a prototype of h.264 [14:40:15] <kierank> h.265* [14:40:43] <kshishkov> vice versa [14:41:00] <kshishkov> and it should have 1/5th pel MC [14:42:23] <Dark_Shikari> well, samsung+bbc has 1/12th pel [14:42:45] <kshishkov> we'll leave that for RV12 [14:46:16] <av500> kshishkov: why limit at 1/12, just use a "float", its all the rage these days... [14:46:40] <mru> floating pixels [14:47:01] <av500> mru: you recovered! [14:47:12] <kshishkov> av500: rv2 used 1/2 pel MC, rv3 used 1/3 pel MC, rv4 used 1/4 pel MC, guess the sequence [14:47:38] <mru> recovered? I've done nothing to recover from... [14:48:20] <av500> btw, you are missing #beagleboard-gsoc atm [14:48:41] <av500> (all hands meeting) [14:49:26] <mru> too many channels [14:49:33] <mru> can't keep track of it all [14:49:41] <av500> hire a secretary [14:50:07] <av500> one that prints out irc, brings it over to the pool for you to read.... [14:50:08] <kshishkov> and caddy body for shotguns [15:06:11] * BBB lols at Buffering Inc. [16:49:44] <BBB> Tjoppen: can you send me an actual test-case so I can test+fix it myself? I think this can be done simpler. ideally something I can test against apache or so, or ffserver or whatever you wish [16:52:27] <Tjoppen> hm. I'll look into it [16:53:28] <Tjoppen> I might have a bare bones microhttpd based thing lying aruond [16:56:01] <Tjoppen> actually, I think there's an example that comes with that library that'll do [16:57:11] <BBB> ok, I'll look into it again once I have the test then, thanks [17:24:30] <mchinen> Hey all, I'm Michael Chinen, doing the seeking api for gsoc 2010 [17:24:44] <mchinen> I never introduced myself before, tho i've chatted a bit [17:26:14] <mchinen> was thinking to discuss the design for the index table to be used with the new api [17:26:59] <mchinen> What's the best place to discuss? irc? ffmpeg-devel mlist? ffmpeg-soc list? [17:28:04] <wbs> irc is good, as long as there are some authoritive or otherwise knowledgeable discussion partners available :-) [17:28:46] <mchinen> aha. another thing is that I don't know whose irc nicks correspond to devs [17:29:07] <wbs> just use /whois, many have sensible realnames set [17:29:26] * mru is the troll [17:30:32] <mchinen> okay, thanks [17:31:29] <mchinen> i guess i'll just start asking when they don't have a real name in whois [17:33:22] <BBB> your mentor's nick is bcoudurier [17:33:29] <BBB> but he's in CA so he [17:33:29] <BBB> 's [17:33:32] <BBB> still asleep [17:33:48] <wbs> BBB: he replied to a mail on the ML 10 minutes ago actually [17:33:50] <mchinen> ah, yes. [17:33:56] <BBB> actually he did [17:34:01] <BBB> I guess he dislikes IRC today [17:34:35] <mchinen> maybe this project can help me to devlop such bad sleep patterns that it won't be an issue [17:35:05] <av500> bad sleep is guaranteed [17:35:10] <CIA-7> ffmpeg: mstorsjo * r23151 /trunk/ffserver.c: [17:35:10] <CIA-7> ffmpeg: ffserver: Make sure a destination URL is set when creating the SDP [17:35:10] <CIA-7> ffmpeg: Debugged by Howard Chu, hyc at highlandsun dot com. [17:37:36] <BBB> mchinen: your project is seeking, right? [17:37:49] <mchinen> BBB:yes [17:38:29] <mchinen> I've read through a bunch of the existing code so far [17:38:40] <BBB> was there ever general agreement on the direction that you'll be taking it into? [17:38:47] <BBB> I remember there being some disagreement about that in the past [17:38:57] <BBB> did you and your mentor discuss that, so that there's a clear plan? [17:39:20] <BBB> I mean, the worst possible thing that could happen is that soc starts, you start coding and all of a sudden we go like "wait that's not what we thought you'd do!" [17:39:29] <mchinen> Yeah, basically provide accurate seeking interface implemented on five or six popular formats [17:39:36] <BBB> ok [17:39:59] <mchinen> yes, this also one reason I thought to discuss publicly [17:42:53] <BBB> it's good you come in, now at least (almost) all soc students are on irc :) [17:44:01] <mchinen> ah, I didn't know the party had started [17:44:18] <mchinen> but yes, its good [17:44:49] <mchinen> i notice svn commits on ffmpeg-soc [17:44:55] <mchinen> what's this about? branches? [17:45:26] <wbs> BBB: hmm, btw, regarding the "return rv || has_next_packet(s);" that we discussed earlier - i'm not sure that does what you'd want [17:45:57] <wbs> BBB: if rv is e.g. -4, evaluating "rv || has_next_packet(s);" may return just 1, since the toplevel || is true [17:46:13] <wbs> instead of passing the original rv through as intended [17:46:33] <_troll_> s/may return/returns/ [17:47:09] <wbs> so to get the desired effect, we'd have to do "if (!rv) return has_next_packet(s); return rv;" [17:47:34] <wbs> or "return rv ? rv : has_next_packet(s);" [17:47:49] <_troll_> yes, either would do [17:48:35] <_troll_> in Perl you'd use the 'or' operator [17:58:19] <BBB> wbs: oh, right [17:58:32] <BBB> wbs: well, but you see what I meant about | being wrong right? ;) [17:58:46] <BBB> || is wrong also, unfortunate that C doesn't have a good operator like that [17:59:01] <wbs> BBB: yeah, it can mess things up too, but would actually handle the cases -1, 0 and 1 properly [17:59:11] <BBB> but not -2 ;) [17:59:18] <wbs> nope :_) [18:00:45] <wbs> also, your comment on handling of prev_ret, the current if (!s->prev_ret) return rtp_parse_queued_packet(s, pkt); should be ok as far as I can see [18:01:02] <wbs> that is, only if the previous code returned exactly 0, we try to dequeue a packet [18:02:20] <wbs> I think you missed some negation in the thing you said earlier: [18:02:22] <wbs> 17:07 <BBB> wbs: is prev_ret to distinguish handling of internal parsers returning versus you returning 1 because of multiple packets in-queue? [18:02:25] <wbs> 17:08 <BBB> because if that's the case, I think A) it should be documented, B) it should check that it's != 0, but that it's == 1 [18:02:28] <wbs> 17:08 <BBB> you're forgetting the < 0 return case [18:11:04] <DonDiego> mmu_screen: so one C89 patch was enough to fix the beos port? [18:13:44] <bcoudurier> hi guys [18:13:50] <CIA-7> ffmpeg: bcoudurier * r23152 /trunk/libavformat/matroskadec.c: set avg frame rate in mkv demuxer [18:14:20] <bcoudurier> Dark_Shikari, can you retry the codec copy from mkv ? [18:18:47] <BBB> wbs: yeah, I think that's ok [18:18:54] <BBB> wbs: I missed that in the first few things I said [18:28:51] <Dark_Shikari> bcoudurier: ok [19:01:07] <lu_zero> hi [19:01:13] <lu_zero> what I'm missing today? [19:03:15] <wbs> lu_zero: do you have any idea of why one would want to intentionally send rtp packets out of order? [19:05:04] <lu_zero> want? [19:05:13] <lu_zero> might happen in one case [19:05:34] <lu_zero> producer -> bad network -> receiver -> server -> client [19:06:06] <lu_zero> the receiver tries its best but the bad network does misorder packets [19:06:50] <lu_zero> you might assume the client fares better if it gets all the packets even if they are misordered [19:07:30] <lu_zero> (and you have a reorder buffer there and you have it large enough to actually do the reorder) [19:08:22] <lu_zero> when you had this experience? [19:23:31] <wbs> lu_zero: I've got a youtube rtsp video that consequently sends packets out of order, almost as if it is intentionally [19:23:53] <wbs> lu_zero: doesn't seem to support tcp interleaving though, so I can't test whether it actually sends them in that order [19:34:29] <lu_zero> want me to check on my side to see if different networks get the packets in different order? [19:34:37] <wbs> sure [19:34:44] <wbs> rtsp://v4.cache7.c.youtube.com/CkYLENy73wIaPQlAxD6Aps4FuxMYEiASFEIJbXYtZ29v… [19:34:59] <elenril> bcoudurier: OMG did you just fix the most annonying bug in ffmpeg [19:35:52] <Dark_Shikari> WOOOOT [19:35:54] <Dark_Shikari> IT WORKS [19:35:57] <Dark_Shikari> THANK YOU SO MUCH bcoudurier [19:35:59] <Dark_Shikari> THANK YOU [19:36:02] <av500> st->avg_frame_rate = av_d2q(1000000000.0/track->default_duration, INT_MAX); ??? [19:36:27] <mru> does that fix -vcodec copy? [19:36:36] <bcoudurier> :) [19:37:03] <elenril> \\\o/// [19:37:21] <mru> and there was much rejoicing [19:37:50] <av500> err, so ffmpeg is all about pts and dts and VFR and then it needs an average frame rate to work? [19:38:22] <ramiro> what bug did that fix? [19:38:32] <mru> lavf seems to grow a new timebase/framerate every 6 months [19:39:03] <bcoudurier> we never had avg frame rate [19:39:18] <mru> eh? avg_frame_rate... [19:39:26] <lu_zero> uhmmmm [19:39:30] <bcoudurier> it's recent [19:39:46] <lu_zero> wbs: the 106 one? [19:39:46] <elenril> wait, system ffmpeg works too [19:40:21] <elenril> so it was fixed earlier [19:40:35] <mru> we have time_base, avg_frame_rate, and r_frame_rate in struct AVStream [19:40:44] <mru> and a few more variants made up on the fly [19:40:55] <wbs> lu_zero: no, 105.. I just watched that one [19:41:07] <wbs> lu_zero: since the format in 106 isn't supported [19:41:11] <bcoudurier> that's exact and they represent different things [19:42:05] * av500 just remuxed his 1st mkv into something else using ffmpeg.... [19:42:10] <lu_zero> wbs: uhm? [19:42:16] <lu_zero> 106 should be h264 [19:42:33] * lu_zero is messing up with wireshark [19:42:44] <wbs> 105 is h264 here, 106 is mp4a-latm [19:42:53] <wbs> but nevertheless, both are non-monotonic [19:43:04] <lu_zero> same here [19:43:17] <wbs> and quite systematically non-monotonic, not random in any way [19:44:19] <lu_zero> I should check what happens with the pvcore implementation [19:44:45] <av500> hmm, almost: [matroska @ 0x8b673b0]st:1 error, non monotone timestamps 13 >= 13 [19:45:10] <wbs> lu_zero: I think hyc said that it worked on android phones [19:47:27] <lu_zero> ffplay pukes, vlc+live555 uses lots of concealment, mplayer+nemesi uses lots of concealment as well [19:48:11] <av500> hmm, no, remuxing mkv still does not work, and where it worked, it was working before 23152... [19:48:27] <lu_zero> am I wrong or it doesn't handle seek? [19:49:34] <wbs> haven't checked seeking at all [19:51:41] <bcoudurier> av500 can you please share your file ? [19:52:05] <av500> I found one file where the fix helps [19:57:24] <lu_zero> ok, vlc seek is ok, libnemesi issue pauses with a range and that triggers badrequest... [19:57:56] <lu_zero> ffplay needs a *bit* of time to discover it can decode h264... [20:03:25] <av500> bcoudurier: it is uploading: /MPlayer/incoming/mkv_cannot_remux_for_bcoudurier/atlantis405-test.mkv [20:03:44] <bcoudurier> thanks [20:10:44] <av500> bcoudurier: I did: ffmpeg -i atlantis405-test.mkv -vcodec copy -an test.[mp4|mkv] [20:14:20] <bcoudurier> I have to wait until the script change the perms [20:14:23] <bcoudurier> ! [20:14:39] * av500 summons mru [20:17:21] * av500 feeds the _troll_ a cookie [20:18:04] <bcoudurier> great [20:18:06] <bcoudurier> thanks [20:20:28] <saintd3v> av500: please don't feed the _troll_ [20:20:33] <bcoudurier> well no default duration in your file [20:20:40] <bcoudurier> and the h264 stream has no time base [20:20:56] <mru> bcoudurier: perms fixed [20:21:16] <bcoudurier> yup, noticed, thanks [20:25:56] <kierank> so...did anybody get a chance to look at that h.264 decoding bug I reported [20:27:33] * mmu_screen slaps DonDiego [20:27:35] <mmu_screen> no [20:28:34] <mmu_screen> I've got an alternate workaround for those PRI* macros, but first I want to make sure the haiku part in configure works so I can commit the split patch [20:29:05] <mmu_screen> but the R1/alpha2 I installed seems crashprone :^) [20:29:16] <bcoudurier> av500, no luck with this file, it will work only if the file has num_reorder_frames set [20:31:30] * mru thought beos was non-existence-prone [20:33:53] * mmu_screen unmaps the stacks of mru and removes gdb [20:34:07] <mmu_screen> usually it works quite well :D [20:34:30] <lu_zero> beos is a nifty idea with a half decent implementation [20:34:45] <lu_zero> pity that didn't get enough support to improve [20:34:48] <mmu_screen> hopefully Haiku is much more decent [20:34:52] <mru> it can be as nifty as it likes, if it has no users it's still irrelevant [20:34:58] <mmu_screen> lu_zero: Haiku is opensource, you can send a patch :D [20:35:31] <lu_zero> mmu_screen: I try to not dabble with C++ ^^; [20:36:03] <mru> making the primary OS interface c++ was probably a big mistake [20:36:24] <lu_zero> I'm not proficient enough to try to write something sane and I have doubts anything sane could be done with the current tools/standard nonetheless... [20:36:39] <mmu_screen> tsssk [20:36:55] * lu_zero wonders if llvm will help or damage in that field [20:37:14] <lu_zero> their libc++ seems working properly [20:37:18] * mmu_screen delete mru; [20:37:30] <mmu_screen> lu_zero: I heard that clang now builds itself with c++ [20:37:39] <lu_zero> yup [20:37:54] <mru> mmu_screen: syntax error [20:38:03] <mmu_screen> the BeAPI is quite clean despite being C++ [20:38:13] <mru> that's an oxymoron [20:38:15] <lu_zero> I'm afraid of llvm since I'm afraid of everything written in C++ [20:38:17] <mmu_screen> no 10-lines templates like in Boost [20:38:21] <mru> and it doesn't matter how clean it is [20:38:23] <mmu_screen> pfff [20:38:28] <mru> forcing people to use c++ is a mistake [20:38:45] <lu_zero> mmu_screen: I know, beos is probably one of the first system I written something for [20:38:47] <mmu_screen> trying to do OO stuff in C isn't usually much better [20:38:50] * mmu_screen pets QEMU [20:38:59] * mmu_screen throws GTK away [20:39:11] * lu_zero looks at gobject [20:39:51] <mmu_screen> lu_zero: btw there are bindings being developped, there is a Qt port now (ok C++ too, and even uglier), there is GUI support for BePascal [20:40:29] <lu_zero> mmu_screen: I know haiku is getting more and more functional =) [20:40:32] <mru> keeping the base system interfaces in C is a good thing [20:40:34] <mmu_screen> I should write a macro for irssi since we already had this troll like 10 times [20:40:37] <mru> everything is based on C [20:41:01] <mmu_screen> lu_zero: the Kernel Kit is C only, drivers use a C interface (but can be written in C++) [20:41:11] <lu_zero> uh? [20:41:25] <lu_zero> really? [20:41:39] <lu_zero> I thought that the kernel was C++ as well [20:41:40] <mmu_screen> http://www.haiku-os.org/legacy-docs/bebook/TheKernelKit_ThreadsAndTeams.html [20:41:59] <mmu_screen> it has some blobs but the interfaces are plain C [20:42:13] <mmu_screen> anyway, shower [20:43:23] <mru> yes, clean those ugly thoughts from your mind [20:44:15] * mmu_screen has pictures of mru compromising himself with C++ [20:44:32] <mmu_screen> ugh, frightening [20:47:45] <lu_zero> mru would write embedded asm there as well =P [20:51:07] <mru> a decent system interface should be easy to call from asm, yes [21:39:45] <bcoudurier> anyone familiar with the png decoder ? [21:40:14] <hyc> aside from the sdp patch, what about the rest of the ffserver fixes I posted? [21:40:51] <wbs> hyc: perhaps a repost of them with thorough explanation of what the problems are and what you're fixing? or just a ping on those parts [21:41:31] <mru> bcoudurier: what about it? [21:42:04] <bcoudurier> it seems zlib frees a buffer that it shouldn't [21:42:09] <hyc> wbs: I thought I already posted clear explanations with each incremental email [21:42:24] <mru> bcoudurier: I'm not surprised if it does, but do you have more details? [21:42:24] <hyc> but I guess I can repost it all again... [21:42:26] <bcoudurier> but I'm not sure [21:42:33] <mru> valgrind doesn't complain [21:42:35] <bcoudurier> let me paste it in private [21:42:49] <mru> zlib is basically evil [21:43:24] <_av500_> bcoudurier: so the file can be played but not remuxed? [21:43:32] <bcoudurier> basically, yes [21:43:57] <_av500_> what is lost between playing it and bein able to mux it? [21:45:01] <bcoudurier> dts [21:45:07] <bcoudurier> nothing is lost [21:45:09] <bcoudurier> mkv misses dts [21:45:17] <_av500_> i know [21:45:39] <_av500_> so, what to remuxable mkv files have? [21:45:41] <bcoudurier> to compute dts, you need duration and pts and delay basically [21:45:53] <bcoudurier> or delay and cfr [21:46:18] <bcoudurier> only files that have the delay in extradata basically [21:46:39] <_av500_> in codec extradata for h264? [21:46:42] <bcoudurier> I thought that was very common for files encoded with x264 [21:46:48] <bcoudurier> Dark_Shikari ? [21:47:18] <_av500_> i thought all h264 was encoded with x264 by now :) [21:47:29] <bcoudurier> nah [21:47:46] <kierank> [22:45] <@bcoudurier> to compute dts, you need duration and pts and delay basically --> or you can use hrd sei messages if they are available [21:47:49] <bcoudurier> all dvdripping stuff surely :> [21:48:45] <bcoudurier> hrd sei are mostly used with TS AFAIK [21:48:51] <bcoudurier> TS has dts so no problem here [21:49:08] <kierank> yes, the dts of ts should be exactly the same as the hrd sei message [21:49:11] <bcoudurier> mkv is utterly crap because it only has pts [21:49:32] <_av500_> unless it had dts :) [21:49:56] <_av500_> in VFW muxing mode... [21:50:00] <bcoudurier> doh [21:50:06] <bcoudurier> ugly ugly ugly [21:50:11] <kierank> x264 should write num_reorder_frames [21:50:31] <_av500_> or out of order audio in "lets be a little be realvideo" mode [21:51:33] <bcoudurier> kierank, yup that's what I thought [21:53:36] <_av500_> but mkv provides some "back ref" values for reordered frames, no? [21:59:27] <_av500_> bcoudurier: "delay" so that you know how long to keep frames in a reorder buffer` [21:59:30] <_av500_> ? [21:59:50] <bcoudurier> so you know at which value dts start [22:00:08] <bcoudurier> usually for pts 0,1,2,3,4,5,6,7 [22:00:13] <bcoudurier> dts start at -delay [22:00:53] <hyc> wbs: reposted ... there are still a lot more problems with ffserver though [22:01:21] <hyc> the ffm interface omits a number of config options [22:01:47] <hyc> so the settings that ffmpeg actually uses are different from what was set in ffserver.conf [22:02:14] <hyc> trellis encoding is missing, sample_aspect_ratio is missing [22:03:14] <hyc> many others, and these affect e.g. x264. so the stream generated by ffmpeg doesn't agree with the sps/pps extradata that ffserver sends [22:03:29] <hyc> (that ffserver sends to the rtsp client) [22:04:59] <hyc> this might account for those endless "non-existing PPS" error messages. dunno yet. [22:06:21] <hyc> bcoudurier: is there any special steps needed for adding new fields to the ffm header? [22:07:59] <bcoudurier> nope [22:09:48] <hyc> ok, then I'll probably post a patch to push some more settings into there [22:12:10] <hyc> not worth the effort until the other ffserver fixes are committed though [22:21:15] <Dark_Shikari> next patch round [22:21:17] <Dark_Shikari> er [22:21:18] <Dark_Shikari> bcoudurier: ? [22:23:57] <hyc> btw, Dark_Shikari thanks for your help yesterday [22:24:06] <hyc> of course it turned out I was chasing a red herring... [22:24:38] * mru already has plenty of those in his trophy case [22:25:10] * hyc feeds them to his cats [22:26:27] * mru likes cats [22:26:59] <bcoudurier> <bcoudurier> I thought that was very common for files encoded with x264 [22:27:07] <bcoudurier> have num_reorder_frames [22:27:30] <Dark_Shikari> yes, all x264 files have num_reorder_frames [22:28:10] <bcoudurier> oh [22:28:19] <bcoudurier> av500 gaves me one without [22:28:50] <_av500_> i did not say it was x264 encoded [22:28:55] <bcoudurier> it is [22:29:01] <_av500_> ah [22:29:10] <bcoudurier> core 56 svn-680 [22:29:18] <bcoudurier> lol [22:29:35] <kierank> youtube uses a version from that era [22:29:44] <kierank> dunno if they upgraded it yet [22:29:54] <bcoudurier> that's from haali [22:30:29] <Dark_Shikari> going back to at least 2005 it seems to be set in x264 [22:30:56] <bcoudurier> rofl [22:31:10] <bcoudurier> the sceners used a 2 years old version [22:31:25] <bcoudurier> this episode was aired 26 october 2007 [22:31:39] <_av500_> bcoudurier: it might well be from then [22:32:22] <bcoudurier> anyway this files has no timing info [22:32:27] * mru has no respect for people who self-apply the term "scene" [22:32:35] <iive> _av500_: x264 from 2005 used to encode episode aired 2007 - 2 years old x264 [22:32:58] <_av500_> iive: yeah, math is rusty this late :) [22:33:10] <iive> _av500_: :) [22:34:01] <bcoudurier> yes, no vui in this file [22:34:07] <bcoudurier> so no luck [22:34:24] <mru> x264 has use vui for a very long time [22:34:58] <_av500_> vui is the noise it makes when it encodes really fast? [22:35:51] <mru> I remember writing actual code for that, so it must have been in early 2004 [22:36:03] <kierank> git blame says num_reorder_frames was written in march 2005 [22:36:24] <mru> the vui may have been extended later [22:36:44] <kierank> yes you wrote the vui in '04 [22:37:11] <kierank> your name produces a lot of console spam [22:40:11] <mru> I wrote some ratecontrol back then too [22:40:16] <mru> nothing left of it now :-( [22:40:28] <mru> it wasn't very good [22:40:36] <mru> but better than constant-qp [22:41:06] <kierank> you wrote ratecontroll [22:41:46] <mru> as I said, it wasn't very good [22:42:04] <kierank> never mind [22:42:43] <kierank> (mru didn't see what i did there) [22:43:06] <drv> ratecon-troll [22:44:59] <kierank> You could submit ffv2 to this if you can read past the buzzwords: http://tech.ebu.ch/news/amwa-and-ebu-issue-request-for-media-tec-26apr10 [22:50:32] <CIA-7> ffmpeg: stefano * r23153 /trunk/libavcodec/ (avcodec.h options.c): Add log_level_offset to AVCodecContext. [23:00:20] <Compn> mru : you should ask people on irc if they are going to linuxtag :P [23:02:25] <mru> I thought everybody here read the ML [23:02:45] <mru> but as you wish: [23:02:50] <mru> anyone going to linuxtag? [23:03:29] <BBB> not me [23:03:38] <BBB> I didn't want to spam the ml with "no" messages :) [23:03:58] <mru> you could still contribute some ideas [23:04:30] <BBB> ok [23:04:34] <BBB> what do you need exactly? [23:04:39] * BBB goes read ml [23:04:50] <mru> ideas for demos, posters, t-shirts, anything you can think of [23:05:01] <mru> and transport of a fairly heavy case from darmstadt to berlin [23:05:17] <mru> it's ok, it's too small to hold a corpse [23:05:33] <BBB> can it hold a mouse corpse? [23:05:37] <BBB> if so, big enough for me [23:05:44] <BBB> ("academic purposes") [23:05:52] <BBB> slogan: "ready for HTML5" [23:05:53] <mru> I didn't see any mice in _av500_'s office... [23:06:03] <BBB> is av500 a scientist? [23:06:04] <mru> we've already done "works with html5" [23:06:08] <BBB> oh :( [23:06:14] <mru> at fosdem [23:06:18] <BBB> oh right [23:06:31] <mru> I guess I'll reuse that tshirt one day [23:07:04] <BBB> how about a funny nag on that hulu-to-android script hyc wrote? [23:07:11] <mru> too obscure [23:07:14] * mru hasn't heard of it [23:07:24] <mru> hulu mostly isn't in europe [23:07:29] <BBB> oh... [23:07:34] <BBB> it's pretty big here, but that's useless the [23:07:40] <BBB> I guess you guys still watch tv, do you [23:07:41] <BBB> ? [23:07:49] <mru> rarely [23:07:55] <kierank> hulu quit the uk [23:08:10] * mru has been watching aac in md5 lately [23:08:22] <BBB> watching aac is quite impressive [23:08:44] <mru> it's faster and more accurate than listening to it [23:09:12] <BBB> diego has foundation money, he can send you money to rent a car to transport beast, for all I care [23:09:24] <mru> still need a driver [23:09:28] <BBB> I think that's a pretty fair way of "getting closer to our goal" [23:09:29] <mru> we have devs in that area [23:09:30] <BBB> you? [23:09:35] <mru> hopefully someone will be going [23:09:39] <BBB> I thought you were driving [23:09:48] <mru> from the UK? I don't think so [23:09:58] <BBB> right [23:09:59] <mru> and I don't have a car [23:10:18] <mru> that's one thing I like about europe [23:10:21] <mru> you don't need a car [23:10:34] <BBB> you're confused with the westcoast [23:10:45] <BBB> in NYC, if you have a car, you're an idiot [23:10:50] <mru> yeah, I guess you don't need one in NYC either [23:10:53] <BBB> :) [23:11:10] <BBB> ok, slogan [23:11:43] <BBB> "Can <i><b>your</b></i> browser play h.264?" [23:11:46] <bcoudurier> well in nyc I found subway very dirty [23:12:04] <mru> we've done html already [23:12:18] <mru> that would just look like a google advert [23:12:22] <bcoudurier> but that's probably my frog taste [23:12:29] <BBB> bcoudurier: no, it's dirty [23:12:37] <BBB> bcoudurier: but it's all we have :-/ [23:12:50] <mru> stockholm underground is probably the cleanest I've seen [23:12:53] <BBB> on the upside, we have amazing restaurants [23:12:59] <bcoudurier> in manhattan you can walk for sure [23:13:05] <mru> might be because the replaced all trains ~10 years ago [23:13:11] <bcoudurier> yes, amazing == cost you an arm [23:13:24] <BBB> hehe :) [23:13:27] <BBB> not really [23:13:44] <BBB> some of them are very cheap (under $10, some even under $6, per person for dinner) [23:13:48] <bcoudurier> well ok [23:13:58] <mru> BBB: taco bell isn't a restaurant [23:14:00] <BBB> don't expect jean george quality, but they're surprisingly good sometimes [23:14:06] <bcoudurier> mru, exacly :) [23:14:06] <BBB> baoguette [23:14:12] <BBB> is absolutely amazing [23:14:16] <BBB> and dirt-cheap [23:14:27] <BBB> </google ads> [23:14:28] <bcoudurier> I mean I found that a real problem in the us [23:14:43] * mru used to eat really cheaply on the west coast [23:14:44] <bcoudurier> you want something "decent", it will cost you at least $35 per person [23:14:47] <mru> company was paying... [23:15:32] <bcoudurier> the wine is very pricey [23:15:49] <bcoudurier> in paris I could eat for 20 euros [23:15:51] <mru> with a $40/dinner allowance you tend to not care [23:16:06] <mru> that was the good thing about that company [23:16:18] <bcoudurier> yup [23:16:26] <BBB> hm [23:16:29] <kierank> geneva is even worse [23:16:31] <BBB> my next idea was not so good [23:16:32] <BBB> http://www.googlefight.com/index.php?lang=en_GB&word1=%22ffmpeg+rocks%22&wo… [23:16:35] <BBB> aiiiii [23:16:36] <bcoudurier> haha [23:16:41] <hyc> there's always BBC iPlayer for you UK folks [23:16:48] <hyc> the same type of hack will work for that [23:17:08] <mru> I don't need a hack for iplayer [23:17:11] <mru> works fine on the ps3 [23:17:16] <hyc> in fact, my hulu scripts originated from the get_iplayer project [23:17:26] <mru> although I usually end up torrenting it anyway [23:17:32] <kierank> get_iplayer folded because bbc said drm > open source [23:17:42] <kierank> their loss [23:17:58] <hyc> well, that's the beauty of open source - the original author stopped but the project lives on [23:19:54] <kierank> the bigger issue was that about 10 years ago on satellite effectively put open source above drm when they got rid of videoguard. People are saying now it's back to square one for the internet [23:20:00] <kierank> bbc* effectively [23:20:35] <kierank> ofc there was a lot of money saved too [23:22:33] <mru> videoguard ain't cheap [23:22:40] <mru> and the code is very, very ugly [23:22:43] <iive> kierank: i've heard that internet "broadcast" is also lower quality than the dvb broadcast. [23:23:00] <kierank> only because the encoder sucks [23:23:07] <kierank> it's 1500kbps h.264 [23:23:08] <kierank> for sd [23:23:24] <mru> should be plenty [23:23:29] <kierank> yes but the encoder sucks [23:23:33] <kierank> blocks galore [23:23:33] <hyc> also the default players may not be choosing the highest rate stream for your particular session [23:23:56] <kierank> hyc: they have a thing where you can right click and see the bitrate [23:24:10] <kierank> they also don't use the flash "smooth-streaming" thing; they wrote their own [23:24:14] <bcoudurier> cable sucks hard [23:24:28] <bcoudurier> it's worse than OTA dtv [23:24:29] <hyc> yeah... but I prefer scripts like get_iplayer that just let you specify which stream to pull [23:24:52] <hyc> yeah, cable sucks [23:25:00] <mru> US cable and satellite tends to suck [23:25:05] <hyc> I haven't upgraded my cable subscription to digital [23:25:09] <mru> atsc is often much better [23:25:10] <hyc> there's no point... [23:25:24] <hyc> unfortunately I get no OTA signal where I live [23:25:35] <bcoudurier> you can see that easily if you watch BBT on CBS [23:25:48] <bcoudurier> the slate is _really_ blocky [23:25:48] <kierank> the problem with cbs is the distribution feed is shit as well [23:26:09] <kierank> so the problem is compounded [23:26:49] <kierank> dunno about fox but abc and nbc have something reasonable to start from [23:26:55] <hyc> I think commercial TV is all a loss anyway... was watching some old shows on Hulu, from back in the 70s. They had 52 minutes of program time per 1-hour show. [23:27:03] <hyc> today we're down to 42 minutes. the rest is commercials. [23:27:16] <Compn> heh [23:27:36] <Compn> atsc would be good, if only broadcasters could agree on widescreen/pillarbox nonsense [23:27:53] <kierank> my favourite is the halfway house widescreen/4:3 Compn [23:27:56] <Compn> maybe i just mean usa dtv... not atsc. [23:28:05] <kierank> it's like a stretchy time warp thing [23:28:17] <Compn> you mean widescreen stretched to 4/3 ? [23:28:28] <kierank> no, there's some weirder thing that some channels use [23:28:38] <hyc> that'd be like old cinemascope movies on 4:3 [23:28:39] <Compn> need a screenshot, but sounds horrible :P [23:28:41] <mru> the worst is the non-linear scaling some TVs use to scale 4/3 to 16/9 [23:28:52] <mru> never seen anything actually encoded like that [23:28:55] * Compn is still using super old tvs with converter boxes [23:29:09] <Compn> no reason to upgrade, nothing to watch on broadcast in years [23:29:13] <kierank> mru explained it better [23:29:34] <kierank> some tv channels in the us used that non-linear scaling thing once [23:29:37] <mru> they stretch the edges more than the centre [23:29:37] <hyc> I haven't watched live TV in years. just watch the S-video output of my laptop. [23:29:53] <bcoudurier> well, they should not get the distribution feed [23:29:58] <bcoudurier> when the OTA feed is good [23:29:59] <hyc> mru: I thought that approach was kinda clever really [23:29:59] <Compn> i need to pickup some cheap s-vdeo to rca cable/converter things ;\ [23:30:01] <mru> idiots don't notice that round objects turn elliptical as they move towards the edge [23:30:20] <kierank> bcoudurier: i'm talking about the distribution feed to the station [23:30:20] <mru> it's clever as idiot mode [23:30:21] <hyc> I think our Samsung big screen TVs offer that mode too [23:30:21] <Compn> oh i've seen those streches hahaha [23:30:23] <bcoudurier> mru, what bandwidth is dvb-t ? [23:30:30] <Compn> fish eye lense [23:30:33] <bcoudurier> kierank, yes I know [23:30:45] <mru> most widescreen TVs have that mode [23:30:51] <mru> bcoudurier: don't know [23:30:56] <mru> varies between countries [23:31:03] <bcoudurier> but AFAIK cable don't rewrite pictures anyway [23:31:16] <bcoudurier> so just get the ota feed and reencode it [23:31:26] <mru> the US cable market is so fucked up anything could happen there [23:31:46] <bcoudurier> I even see inverted fields [23:31:48] <Compn> ooh, maybe i should put up some donation requests for dvb-s stuff :D [23:31:48] <bcoudurier> on some ads [23:31:51] <bcoudurier> on tv [23:32:04] <Compn> probably no free- sattelite channels left [23:32:04] <mru> I've seen compositions where an insert had wrong field order [23:32:33] <kierank> those random channels towards the end of the epg are like that [23:32:37] <kierank> on sky [23:32:56] <kierank> everything wrong [23:32:59] * mru wouldn't let a sky box through his front door [23:33:00] <kierank> field order, chroma [23:33:07] * mru has seen the code they run [23:33:20] <kierank> yes but my CAM doesn't work any more [23:33:28] <kierank> so i'm stuck with it [23:33:39] <kierank> because of the new cards [23:33:54] <mru> yeah, they did a switch a few years back [23:34:27] <kierank> there was one 6 months ago as well [23:34:39] <mru> could be the same one still in progress [23:34:42] <mru> those things take time [23:34:59] <kierank> it's over now I think because the old card doesn't work [23:35:18] <mru> yeah, they send dual ECMs during the transition [23:35:24] <kierank> of course the newer generation of CAMs worked fine [23:35:28] <kierank> didn't need any updates or anything [23:35:33] <Compn> cam? [23:35:38] <kierank> conditional access module [23:35:45] <kierank> basically a smartcard reader [23:35:48] <Compn> ah [23:36:03] <kierank> they are grey market devices [23:36:14] <mru> the nds cards obviously don't follow standard protocol [23:36:27] <mru> electrically they're compatible with the iso smartcard spec [23:36:50] <kierank> there was a software cam that worked with the old cards [23:37:41] <mru> some broadcasters use(d) CI [23:37:45] <mru> those would work [23:37:49] <kierank> the germans [23:38:07] <mru> the US directv system is much more secure [23:38:29] <Kovensky> idea for whoever makes a panel at an OSS convention: bring a bikeshed with you, then put in the middle of the audience and tell them to paint it [23:38:41] <mru> Kovensky: lol [23:38:42] <kierank> nobody wants to pirate directv anyway [23:38:45] <kierank> looks like crap [23:38:47] <mru> yeah [23:38:49] <mru> awful [23:39:00] <kierank> though getting better i've been told now that they bought ateme encoders [23:39:11] <kierank> but still bitrates that are way too low [23:39:26] <mru> they started doing 1080p30 a while ago at least [23:39:42] <mru> when someone realised the decoders could in fact do it [23:39:53] <mru> which should've been no surprise [23:41:50] <kierank> hbo does it properly though with 1080p24, 1080p30 and 1080i60 [23:45:42] <kierank> [00:30] <kierank> bcoudurier: i'm talking about the distribution feed to the station --> wiki says I actually mean "affiliate" [23:54:26] <bcoudurier> yes [23:54:32] <bcoudurier> err [23:54:41] <bcoudurier> you mean local affiliate ? [23:54:51] <bcoudurier> I don't think cable gets the local affiliate feed [23:55:08] <bcoudurier> or maybe they do [23:55:15] <bcoudurier> then their encoder is utter crap [23:57:46] <Dark_Shikari> that's a given

1 0

IRC log for 2010-05-16
by irc＠mansr.com 17 May '10

17 May '10

[00:02:27] <peloverde> I was told that people would do LATM when I made a public PS repo [00:02:36] <peloverde> I have fufilled my side of the bargain [00:03:19] <peloverde> http://github.com/aconverse/ffmpeg-heaac/tree/ps_pub [06:20:52] <hyc> grumble... rtsp streaming was only working while my phone was on my wifi network [06:21:16] <hyc> when I switched to T-mobile 3G, it's not. apparently T-mobile blocks UDP or something [06:22:15] <hyc> and it doesn't look like Android supports RTSP with interleaved RTP [06:23:04] <hyc> so ... anyone got an rtsp relay? talk to the real rtsp server using tcp only, and talk to the localhost client using regular rtp/udp [07:57:24] <CIA-7> ffmpeg: stefano * r23144 /trunk/libavutil/pixfmt.h: Clarify description for the MONOWHITE and MONOBLACK pixel formats. [07:57:24] <CIA-7> ffmpeg: stefano * r23145 /trunk/ (libavformat/riff.c libavcodec/raw.c): [07:57:24] <CIA-7> ffmpeg: Add NV12 and NV21 AVI tags. [07:57:24] <CIA-7> ffmpeg: Both are listed in fourcc.org. [08:00:28] <wbs> hyc: hmmm, strange if udp doesn't work over cellular, that's part of the services that "should work" imo, unless the operatos wants to allow only certain stuff of course.. [08:01:50] <wbs> rtsp/udp is part of stuff that should work, that is [08:02:30] <wbs> or is your rtsp server behind NAT of some kind? [12:36:54] <Kovensky> mru: "planar" audio? o_O [12:37:41] <mru> separate arrays for each channel [12:37:59] <Kovensky> ic [13:13:49] <hyc> wbs: no, I've setup DSS on my linode and that's on a real IP address, no NAT [13:15:07] <hyc> but the phone on 3G is NATd [14:22:01] <wbs> hyc: hmm, ok.. the rtsp client on the phone should be able to punch NATs to get proper forwarding though [14:26:16] <hyc> hmmm. you're right. [14:26:26] <hyc> I just found this page with test audio streams, works. [14:26:33] <hyc> http://www.orban.com/products/streaming/opticodec-pc1010/eval/ [14:27:02] <hyc> so there must be something wrong with the program I'm trying to stream [14:28:22] <hyc> do you have a quick reference handy for allowed bit rates and such for 3GP streaming, perchance? [14:28:25] <hyc> still googling... [14:30:42] <wbs> i don't think that should be an issue, if it works over wifi it should work over 3g, too, as long as you've got enough bandwidth [14:31:48] <hyc> ok, lemme try a much lower bitrate... [14:32:23] <hyc> 128kbit AAC is fine at least [14:32:36] <wbs> hm, ok [14:35:36] <hyc> weird. one of my test streams that didn't work yesterday is OK now. [14:36:33] <wbs> weird [14:37:37] <wbs> http://pda.etsi.org/exchangefolder/ts_126234v090200p.pdf - this should be a reference of what's allowed within rtsp/3gpp, but I doubt that actually helps anything in this case [14:42:45] <hyc> thanks, will check it out anyway [14:43:14] <hyc> ok, so using the DSS sample files, the 50kbit 3gp worked and the 100kbit mp4 worked [14:43:26] <hyc> doesn't seem like the 100kbit h264 will work [14:46:15] <hyc> and the 300kbit mp4 didn't work either [14:47:06] <BastyCDGS> hey greetz to all [14:50:17] <hyc> wbs: have you examined those DSS sample files? [14:50:28] <hyc> the mp4s have 4 streams inside [14:50:42] <hyc> one audio, one video, two marked data / rtsp. you know what they are? [14:57:08] <hyc> oh those are the hint track,s never mind [15:13:18] <wbs> yeah [15:13:57] <wbs> and if you still is interested in producing such stuff for non-live viewing; create just a normal mp4/3gp file and run MP4Box -hint <file>, or use the movenc/rtphint patches I sent a few weeks ago, they allow creating such [15:14:01] <hyc> I see mpeg4ip and mp4box as two tools to do that [15:14:09] <hyc> ah ok [15:14:17] <hyc> I'm compiling mp4box now... [15:14:24] <wbs> with those patches, you can add -fflags rtphint when transcoding with ffmpeg to get it all at once [15:14:54] <hyc> that sounds great. will have to dig thru the archives to find the patch. [15:15:01] <hyc> patches aren't committed yet? [15:15:24] <wbs> no, baptiste did a first review in a few days after submitting it, but that was like 3 weeks ago [15:15:34] <wbs> he hasn't had time to review the updated version yet [15:16:07] <hyc> I see "[RFC] RTP hint tracks in the mov muxer" [15:16:29] <hyc> is there a reason this is only for the mov muxer? I guess the container format is irrelevant here [15:16:42] <wbs> it's the same for mov/3gp/mp4 [15:16:49] <wbs> the same muxer for all of them [15:17:36] <hyc> ah, ok [15:17:36] <wbs> the latest ones are in the thread [PATCH] Add RTP hinting to the mov muxer, a mail from 26th april [15:17:57] <hyc> ok, found that [15:30:40] <hyc> 500kbit hinted mp4 file played on 3G for a while then glitched and hung [16:09:21] <siretart> can someone please explain me the difference between palette8torgb16 and palette8torgb15 in libswscale? I'm trying to document them. [16:09:42] <Dark_Shikari> rgb16 is r5 g6 b5 iirc [16:09:47] <Dark_Shikari> and rgb5 is r5 g5 b5 [16:09:50] <Dark_Shikari> *rgb15 [16:10:45] <BastyCDGS> hi BBB [16:10:47] <siretart> Dark_Shikari: hm. and why is then the code identical? [16:10:52] <BBB> hello [16:10:56] <BBB> I'm still reviewing the ham patch [16:11:01] <Dark_Shikari> siretart: dunno [16:11:09] <BastyCDGS> BBB, I just made some changes to byterun decoder where you found the return value pity [16:11:28] <BastyCDGS> it now returns number of bytes consumed or an error if the byterun1 stream is malicious [16:12:05] <BBB> malicious? [16:12:06] <BBB> ok [16:12:08] <BBB> will look [16:12:11] <BBB> one thing at a time :) [16:12:52] <BastyCDGS> yes that was the case where the FFMIN and FFMIN3 were used previously, they simply cut the data [16:13:07] <BastyCDGS> but I think it's better to return AVERROR_INVALIDDATA if there's not enough space to decompress them [16:21:13] <BBB> I wonder how many consts you can put on a line without getting a syntax error, sometimes [16:21:24] <BBB> try, where appropriate, to not over-use const [16:21:28] <BBB> in many cases it makes no difference [16:21:48] <BBB> and we'll have to remove it again once we use ptrs to keep track of buffer location, e.g. const uint8_t * const buf [16:21:57] <BBB> you can't do val=*buf++; on that [16:22:25] <BastyCDGS> that's why I did const uint8_t *buf, [16:22:26] <BastyCDGS> ;) [16:23:14] <BastyCDGS> btw, the new decode_byterun is a bit faster I just noticed, 3.4k dezicycles as 4.3k it was before ;) [16:23:44] <BBB> excellent [16:23:52] <BBB> still lots of comments on the ham thing [16:23:59] <BBB> I'll have more later, but this should get you started [16:24:15] <BBB> gcc did really well on that macro of yours, I was surprised [16:24:33] <BastyCDGS> yes I playing around with approx 2-3 hours to get it optimal [16:24:58] <BastyCDGS> I will now separate the err thing [16:29:27] <BastyCDGS> so new function merge patch submitted to ML [16:29:53] <hyc> wbs: fyi http://forum.xda-developers.com/showpost.php?p=6495551&postcount=8 [16:30:28] <BBB> ok, will apply in a bit if it's ok [16:31:20] <wbs> BBB: thanks for the point on reordering only if !tcp, i'll try to get that included, too [16:31:55] <BBB> wbs: that's all I could think of for now, you have to admit the 10-item fixed-size cache was butt-ugly though [16:32:08] <BBB> but I see as proof-of-concept it was funny ;) [16:32:11] <wbs> BBB: yeah, it is. :-) [16:32:27] <wbs> and getting all that to work with editing code in ~3 places is quite ok :-) [16:32:27] <BBB> also make sure you don't leak the cache on exit [16:32:59] <wbs> yeah, forgot it this time when it was that kind of hack :-) [16:33:10] <BBB> that's ok :) [16:33:19] <BBB> hey, I do hacks like that too ;) [16:37:22] <wbs> hyc: nice writeup [16:37:36] <wbs> BBB: i've found the second user for the rtsp muxer - hyc :-) [16:38:25] <BBB> now if only hyc would start working on a rtmp muxer + demuxer inside lavf [16:40:05] <hyc> BBB eh? what else do you need? [16:41:35] <BastyCDGS> BBB, about transparency/masking in HAM patch where you suggest removal [16:41:42] <BastyCDGS> they're used for bumping error messages [16:42:00] <BastyCDGS> I could of course remove the local stuff but then I've to change code later at other points when I add them [16:44:49] <hyc> BBB: the rtmp protocol just transports flv, and there's already an flv mux/demux [16:44:49] <BBB> BastyCDGS: right, that's normally what we do [16:44:56] <BBB> you add it not pre-emptively, but when you start using it [16:45:08] <BBB> hyc: rtmp uses libZYX [16:45:12] <BBB> should be in lavf [16:46:02] <hyc> oh... not going to revisit that conversation. [16:47:07] <hyc> there are still going to be external dependencies, remember? DiffieHellman, at least. [16:47:23] <hyc> so it's a lot of work for really no gain [16:47:31] <hyc> and no overall change in the situation [16:50:20] <BBB> like you said, "not going to revisit" [16:53:07] <hyc> better to re-use good code than to rewrite it. I've now adapted librtmp to XBMC, ffmpeg, mplayer, and libcurl. [16:53:32] <hyc> If I had rewritten librtmp exclusively for ffmpeg it would have taken more time and gotten less coverage. [16:54:13] <wbs> hyc: btw, how much work would it be to add support to librtmp for doing generic method invocations for custom applications? [16:54:40] <wbs> that is, not just setting up video streaming, but calling custom server methods and getting the results [16:55:00] <hyc> wbs: dunno, will have to think about it. you need a way to specify the syntax of each request in AMF [16:55:13] <hyc> kinda like OpenLDAP's liblber for ASN.1 I suppose [16:55:40] <wbs> ok [16:56:08] <hyc> are you familiar with ASN.1 or AMF? [16:56:40] <wbs> just a tiny bit with AMF, it's some way of serializing generic objects of a few different classes, right? [16:56:56] <hyc> I guess you could say that [16:57:06] <wbs> if I need such support from librtmp I guess I can try to add it myself, I'm not sure yet if I'll need it or not [16:57:48] <hyc> librtmp only encodes 3-4 data types, but it decodes a couple dozen. [16:58:51] <hyc> ASN.1 has hierarchically nested data structures. Most software projects use dedicated IDL compilers to go from a structure definition to code. [16:59:36] <hyc> In OpenLDAP we just do stuff like ber_printf(ber, "{{IAAI}{B}}", ...) [16:59:45] <wbs> ah [17:00:48] <hyc> it's much more flexible since you can encode any structure you can conceive of on the fly, instead of having to know them all in advance... [17:01:08] <hyc> I would consider taking a similar approach for arbitrary RTMP requests [17:01:19] <wbs> sounds reasonable, yeah [17:01:31] <hyc> (we of course have ber_scanf to decode these things.) [17:09:40] <CIA-7> ffmpeg: stefano * r23146 /trunk/libavcodec/raw.c: Add missing rawvideo pixel formats to codec tags mappings for nut. [17:19:58] <mt> There's something that I don't understand about the wma decoder; what does it make data_size = 16k when all that was written into the output buffer is really 2k ? [17:24:46] <BBB> mt: data_size is in bytes? [17:24:58] <mt> BBB: Yes [17:25:14] <BBB> it works for ffplay, right? [17:26:14] <mt> I have tried ffmpeg_g not ffplay, and it worked [17:26:32] <mt> (ffmpeg_g -i foo.wma foo.wav) [17:27:23] <BBB> so what do you mean that only 2k was written? that 2048 bytes (for stereo, that's /int_16_t*2 = 512 samples) were written? [17:30:08] <mt> Sorry I meant 4k bytes .. [17:30:28] <mt> 1024 samples for stereo [17:31:28] <BBB> is this wmapro or wma1/2? [17:31:33] <mt> pro [17:31:41] <BBB> output=float, so that's 4bytes per sample [17:31:42] <BBB> not 2 [17:31:48] <BBB> 8 bytes because stereo [17:32:00] <BBB> so 1024 samples = 8182 bytes [17:32:04] <BBB> that explains one thing [17:32:14] <BBB> but why is it 16k? [17:32:34] * BBB doesn't know that last piece [17:33:19] <BBB> well it's probably something similar to that [17:33:56] <mt> Ah I convert the pcm samples to s16-bit btw .. (*data_size/2) [17:35:03] <BBB> so what's the bug? [17:35:05] <BBB> I'm confused [17:39:35] <mt> data_size is double the actual number of bytes. I didn't mean it was a bug btw, I might just be confused :) .. I don't know where this doubling comes from. [17:40:33] <mt> like that 16k vs 8k example. [17:51:04] <BBB> right [17:51:08] <BBB> I don't know exactly [17:51:09] <BBB> sorry :( [17:54:19] <BastyCDGS> BBB, one question [17:54:24] <BBB> si? [17:54:27] <BastyCDGS> Use av_mallocz(), memset(x, 0) or something to zero the remaining [17:54:27] <BastyCDGS> (unpaletted) entries, e.g. if extradata is too small. [17:54:39] <BBB> yes [17:54:43] <BastyCDGS> the thing is it's interleaved zeroes...i.e. zero, palette data, zero... [17:55:20] <mt> BBB: No problem.. Thanks anyways. :) [17:55:28] <BastyCDGS> the mask is always zero, but not the palette data so I just fill out the first count*2 entries with 0 [17:55:45] <BBB> BastyCDGS: the palette data is what I meant [17:55:51] <BBB> the palette data is read from the extradata [17:55:55] <BastyCDGS> I could of course let start the memset where anything is always zero but then i have to set mask to 0 by hand like grayscale part [17:56:04] <BBB> but what if count = 1<<bps is 256 and extradata is only 200? [17:56:08] <BBB> the last 56 would be uninitialized [17:56:12] <BBB> you need to zero them somehow [17:56:19] <BastyCDGS> yes that's what the memset does ;) [17:56:33] <BastyCDGS> it's * 2 because mask has to be zero, too [17:57:34] <BBB> oh there is a memset! [17:57:36] <BBB> now I get it [17:57:38] <BBB> nevermind [17:57:38] <BastyCDGS> about MASK_NONE, stefano just said I should use MASK_NONE instead of 0 and use a comment [17:57:42] <BBB> I didn't see that whole thing [17:58:32] <BBB> saste: did you say that? [17:58:37] <BBB> if he thinks so, then it's ok [17:58:44] <BBB> the others should still go -> iff.c [17:58:59] <BastyCDGS> that's why I was changing this again, actually ;) [18:01:30] <BastyCDGS> BBB: if ((screenmode & 0x800 /* Hold And Modify */) && iff->bpp <= 8) { [18:01:33] <BastyCDGS> is that ok? [18:01:54] <BastyCDGS> iff->flags = (screenmode & 0x80 /* Extra HalfBrite */) && iff->bpp <= 8 ? 1 : 0; [18:03:44] <BBB> too many () [18:03:48] <BBB> also 1:0 can be done as !! [18:04:01] <BBB> so !!(screenmode & 0x80 /* .. */ && bpp <= 8); [18:04:20] <BBB> otherwise it's ok, yes [18:05:27] <BastyCDGS> iff->flags = screenmode & 0x80 /* Extra HalfBrite */ && iff->bpp <= 8; [18:05:40] <BastyCDGS> !! is double inverse => remove [18:06:03] <BBB> oh right && takes care of that [18:06:14] <BBB> you need !! only for & [18:06:19] <BBB> !!(x & 0x80) [18:06:52] <BastyCDGS> do you think this one looks better? [18:06:52] <BastyCDGS> iff->flags = (screenmode & 0x80 /* Extra HalfBrite */) && iff->bpp <= 8; [18:07:07] <BBB> not really [18:07:11] <BBB> but no strong opinion [18:07:16] <BastyCDGS> so which one of these two should I take [18:08:59] <BastyCDGS> This number may change between frames. [18:09:03] <BastyCDGS> this is correct [18:09:31] <BastyCDGS> it can also send an empty structure (size == 2) in that case it means to the decoder, don't change anything this frame except the frame data itself [18:13:49] <BBB> 1 second [18:14:45] <CIA-7> ffmpeg: bcoudurier * r23147 /trunk/libavfilter/graphparser.c: use filter name when graph parser add filters [18:25:44] <mt> BBB: in wma pro, samples_per_frame == samples per frame _per channel_ ? [18:27:01] <BBB> mt: I didn't write that codec, but usually yes [18:29:11] <BBB> BastyCDGS: that wasn't immediately clear to me [18:29:17] <BBB> BastyCDGS: the comment should be clearer [18:29:24] <BBB> the number doesn't change [18:29:28] <BBB> it's always 9, if there's data [18:29:34] <BBB> but it can be 2 also if there's no data [18:30:17] <BastyCDGS> * This number may change between frames, e.g. the demuxer might [18:30:17] <BastyCDGS> * set it to smallest possible size of 2 to indicate that there's [18:30:17] <BastyCDGS> * no extradata changing in this frame. [18:30:39] <BastyCDGS> in fact it's always 9 in current version data, but future versions might add new fields [18:30:46] <BastyCDGS> in this case it can be larger [18:31:46] <BBB> something like that is ok [18:31:53] <BBB> also, I'd set it to size without the size field [18:31:59] <BBB> right now you have to check that size >= 2 [18:32:01] <BBB> else it's invalid [18:32:03] <BBB> that's silly [18:32:20] <BBB> and make sure to check that size <= pkt->size [18:32:24] <BBB> (if you didn't already) [18:32:46] <BastyCDGS> it does GET_EXTRA_SIZE and GET_PACKET_SIZE return <= 0 in this case [18:32:47] <BastyCDGS> ;) [18:33:05] <BastyCDGS> a size of 0 or 1 doesn't make any sense right? ;) [18:33:20] <BastyCDGS> because actual raw data and extra data would overlap then [18:33:26] <BBB> yes [18:33:31] <BBB> but you're not checking that that's not the case [18:33:35] <BastyCDGS> for now these values are illegal but maybe they might have a meaning in the future [18:33:45] <BBB> no, no, we don't work like that :) [18:33:50] <BastyCDGS> if (buf_size <= 1 || (int) GET_PACKET_SIZE(avpkt) <= 1) { [18:33:57] <BBB> we define things in a sensible way :) [18:33:58] <BastyCDGS> this does do both checks [18:34:16] <BBB> GET_PACKET_SIZE() is a little weird [18:34:22] <BBB> I think all that is overegineering [18:34:32] <BastyCDGS> why it's weird? [18:34:32] <BBB> it's not necessary to make macros for such simple stuff [18:34:35] <BBB> size=avpkt->size; [18:34:39] <BBB> size -= buffer_size; [18:34:46] <BBB> if size < 0 return error; [18:34:48] <BastyCDGS> I use this macro pretty often [18:34:49] <BBB> handle (data, size); [18:35:36] <BBB> again, up to you, I have no strong opinion (except that they shouldn't be in public header files), but I think it's overengineering [18:35:41] <BBB> generally leads to poor performance [18:35:58] <BBB> see glib's gobject :) [18:36:50] <BastyCDGS> well these macros are only used upon init or if data changes between frames [18:37:00] <BastyCDGS> not in actual decoding [18:37:52] <BastyCDGS> one other question about factorzing the decode_frame_ilbm & byterun1 [18:37:58] <BastyCDGS> do you mean I should put the start in a macro? [18:38:19] <BBB> I haven't looked into that in detail [18:38:24] <BBB> whichever you think is best, basically [18:38:30] <BBB> again, keep the macro for GET_...() [18:38:32] <BBB> if you want [18:38:43] <BBB> I personally don't consider it pretty, but it's your codec more than mine, so do as you please [18:39:04] <BBB> same for the factorizing, it's clear there's a lot of duplicate code, I think it can be factorized, you appear to agree (good!) [18:39:13] <BBB> how to do that best is now up to you :) [18:40:03] <hyc> I keep getting this complaint about AAC running ffserver. comes from sdp.c line 244 "AAC with no global headers is currently not supported" [18:40:19] <hyc> what is it expecting to see in codec->extradata ? [18:40:55] <hyc> this is using an ffm feed. why isn't ffmpeg sending what sdp wants? the codec->extradatasize is zero. [18:41:24] <BBB> during encoding, set AVCodecContext->flags &= GLOBAL_HEADERS; [18:41:33] <wbs> hyc: hmm, you're encoding aac in a ffmpeg process, sending it over to ffserver as ffm, and ffserver wants aac global headers? [18:41:46] <hyc> wbs: right [18:41:47] <BBB> might be a bug btw, send us a patch ;) [18:42:03] <wbs> the ffmpeg encoder would need to know that aac should have global headers then, which it checks from the global header flag of the selected muxer [18:42:04] <hyc> I'm sure it's a bug, but I don't know what it really wants here. [18:42:14] <BastyCDGS> +#define DECODE_FRAME_INIT \ [18:42:14] <BastyCDGS> + IffContext *s = avctx->priv_data; \ [18:42:14] <BastyCDGS> + const uint8_t *buf = GET_PACKET_DATA(avpkt); \ [18:42:37] <hyc> wbs: isn't ffm the muxer here? [18:42:51] <wbs> hyc: yeah, and I don't know that one, I guess it can do both with and without global headers [18:42:57] <BBB> BastyCDGS: that sounds like it'll be really ugly [18:43:06] <BBB> BastyCDGS: can you wrap the code in the middle into a common subfunction? [18:43:15] <wbs> it is mostly up to what ffserver wants to do with the data later, and ffmpeg doesn't really know if the ffserver target format wants global headers or not [18:43:28] <BastyCDGS> BBB, then it won't make any sense [18:43:31] <BBB> wbs: ffmpeg.c has some hack in it for ffserver output [18:43:44] <wbs> BBB: ah, I see [18:43:48] <wbs> then disregard me :-) [18:43:55] <hyc> BBB: where is this hack? [18:44:17] <hyc> if it depends on the target format, then should ffmpeg always send it? [18:44:19] <BastyCDGS> BBB, or should I move the define to the beginning? [18:46:43] <BBB> BastyCDGS: let me pastebin something for you [18:47:21] <wbs> hyc: not necessarily (exept that I don't know what ffserver does), for some output formats you don't want global headers enabled if the output format doesn't want that, since it may change the format of the raw data [18:47:50] <wbs> for aac, you get an adts stream if global headers aren't enabled, and raw aac if global headers are enabled [18:47:57] <wbs> hyc: oh btw, are you stream copying aac? [18:48:21] <BastyCDGS> BBB, btw: I meant it this way: [18:48:21] <hyc> wbs: ok. when ffmpeg starts talking to ffm, it first fetches the ffm definition from ffserver [18:48:21] <BastyCDGS> http://pastebin.org/241899 [18:48:33] <BBB> BastyCDGS: http://ffmpeg.pastebin.com/2Ens29yF [18:48:41] <BBB> that is the difference between ilbm/byterun1 decoding [18:49:06] <hyc> wbs: stream copying? I would like to, but I don't think I can. [18:49:19] <BBB> BastyCDGS: my view is, minus the cosmetic stuff which os obvious, you should put the planar-to-plane decoding for() loops under an if (ctx->codec_id == BYTERUN1) [18:49:25] <BBB> BastyCDGS: and then you have them merged [18:49:26] <BBB> no? [18:49:39] <hyc> that is, I don't know how to tell ffserver to just copy whatever ffmpeg's source stream verbatim [18:49:44] <BastyCDGS> both are different decoders [18:49:50] <wbs> hyc: hmm, ok [18:49:56] <BBB> I know :) [18:50:00] <hyc> there's no analogue to ffmpeg -acodec copy inside ffserver.conf, as far as I know [18:50:31] <BastyCDGS> BBB, but does this really fit in the HAM patch? [18:50:56] <BastyCDGS> can you just look at my pastebin and look how I solved that DECODE_FRAME_INIT stuff? [18:51:04] <hyc> wbs: and this may not even be possible, since a single ffm feed can be turned into many different types of streams. [18:51:24] <wbs> hyc: ah, ok [18:53:49] <hyc> hm... I guess in that case the ffm header must contain parameters for every target stream [18:54:37] <hyc> so probably it should attach whatever it was expected to stuff into the global headers into the ffm header, if any target stream wants it [19:02:10] <BBB> BastyCDGS: that's your ham patch [19:02:17] <BBB> what's DECODE_FRAME_INIT()? [19:02:43] <BastyCDGS> it just merges the 100% identical init stuff of decode_frame_ilbm & decode_frame_byterun1 [19:03:15] <BBB> oh boy [19:03:19] <BBB> no, that's hideous [19:03:21] <BBB> that's not ok [19:03:31] <BastyCDGS> how I should do it then? [19:03:38] <BBB> don't, for now :) [19:03:41] <BastyCDGS> ok [19:03:44] <BBB> but look at the diff I pastebin'ed [19:03:55] <BBB> basically the only difference is the plane decoding [19:04:02] <BBB> so put that under an if (codec_id == BYTERUN1) [19:04:04] <BBB> and you're done [19:04:09] <BBB> plus some smart pointers [19:05:22] <BBB> but later, we'll do ham first [19:05:25] <BBB> one thing at a time :) [19:05:43] <BastyCDGS> what's wrong with the DECODE_FRAME_INIT though? [19:07:35] <hyc> wbs: I'm suspicious of this, ffm encodes the codec_id but not the name. we have both aac.c and libfaac.c [19:07:50] <hyc> and I see libfaac.c checks for GLOBAL_HEADER but aac.c doesn't [19:08:45] <hyc> so it seems that no matter whether you specify libfaac in ffserver.conf, you still get aac instead. [19:08:57] <hyc> and aac isn't setting the global header stuff [19:09:31] <wbs> hyc: aah, that might be the reason [19:11:09] <hyc> I guess I should try --disable-encode=aac ? [19:11:29] <BBB> BastyCDGS: http://ffmpeg.pastebin.com/aZRSsYPL [19:11:32] <BBB> that's what I meant [19:11:35] <BBB> BastyCDGS: rough version [19:11:37] <wbs> hyc: yeah, that's a good idea [19:12:25] <BBB> ffserver can't transmit faac [19:12:28] <BBB> it can only transmit a codec_id [19:12:30] <BBB> which is AAC [19:12:37] <BBB> thus it uses the default aac encoder on the sending side [19:12:39] <BastyCDGS> BBB, I want to keep that if outside the loop at least...for speed reasons [19:12:49] <BastyCDGS> please note that a lot of code is inlined in the loop automatically [19:12:52] <hyc> yeah, that's what I just figured out. going to turn off aac and see if faac works [19:12:57] <BBB> BastyCDGS: I know that [19:13:10] <BBB> BastyCDGS: you could do it macrobased so the source is one function but it expands into two, just like now [19:13:20] <BBB> BastyCDGS: that way you get binary identical code from a single source function [19:13:34] <BBB> but you see that they're easy to merge, right? [19:13:35] <BastyCDGS> that's a much better idea, yes [19:13:42] <BBB> if it's not too ugly :) [19:14:06] <BastyCDGS> so maybe I do a DECODE_FRAME macro instead of DECODE_FRAME_INIT which covers both parts? [19:14:08] <BBB> try some stuff out, show me what you learned :) [19:14:21] <BBB> ? [19:15:02] <BastyCDGS> the DECODE_FRAME merges both code, it just takes a parameter if it's for byterun1 or raw [19:15:05] <BBB> #define decode_function(name) \ static int decode_frame_ ## name (bla bla bla) { bla bla reget buffer for loop return bytes; } [19:15:08] <BBB> decode_function(ilbm); [19:15:14] <BBB> decode_function(byterun1); [19:15:41] <BBB> if that's what you meant, then yes, but it should be purely cosmetic and result in binary identical code (if done correctly) [19:17:57] <BastyCDGS> ok [19:18:22] <BastyCDGS> just one question, saste recommended me in the HAM review that I change: [19:18:23] <BastyCDGS> if (avctx->reget_buffer(avctx, &s->frame) < 0){ [19:18:23] <BastyCDGS> av_log(avctx, AV_LOG_ERROR, "get_buffer() failed\n"); [19:18:23] <BastyCDGS> return -1; [19:18:23] <BastyCDGS> } [19:18:29] <BastyCDGS> to return err instead of -1 [19:18:37] <BastyCDGS> what do you think? separate patch or within HAM? [19:18:49] <BBB> always separate ptch [19:18:53] <BBB> it's completely unrelated to ham [19:24:39] <hyc> ah. using libfaac didn't work either. ffmpeg is writing an ffm header back to ffserver before it has even init'd the codec, so that info isn't available yet. [19:26:11] <BBB> BastyCDGS: oh right, as michael said, but_size implies that it's the size of "buf" (a variable), but it isn't, it's buf's size * 8, so give it a better name please [19:28:38] <BastyCDGS> new HAM patch submitted to ML [19:28:43] <BastyCDGS> will now do the functional merge patch [19:32:42] <hyc> nope, I was wrong about that. using libfaac, ffmpeg definitely sent the global header info [19:33:00] <hyc> but ffserver still didn't use it. wtf... [19:35:20] <BBB> BastyCDGS: where did saste say to keep MASK_NONE? [19:35:23] <BBB> I can't find that email [19:36:18] <BastyCDGS> 15 may 2010 21:52 UTC [19:36:25] <BBB> he said "use the macro if it's there" [19:36:39] <BBB> you should use unsigned masking = 0; // = no mask [19:36:40] <BastyCDGS> > + uint32_t screenmode = 0; [19:36:40] <BastyCDGS> > > + unsigned transparency = 0; [19:36:40] <BastyCDGS> > > + unsigned masking = 0; // MASK_NONE [19:36:40] <BastyCDGS> [19:36:40] <BastyCDGS> directly use the macro value [19:36:40] <BastyCDGS> [19:36:57] <BBB> well duh, the comment is an actual macro [19:37:01] <BBB> of course he'd say use the macro [19:37:08] <BBB> you should make the comment be useful :) [19:43:07] <Kovensky> [mp3 @ 004280b0]max_analyze_duration reached <-- isn't this equivalent to that MAX_READ_SIZE thing that was downgraded to verbose a while ago? [19:43:11] <Kovensky> shouldn't it go to verbose too? [19:44:56] <BastyCDGS> BBB, regarding to iff-function-merge.patch you said I should add the error checking later [19:45:42] <BastyCDGS> can I do the first patch with the uint8_t * return parameter then? [20:54:48] <BastyCDGS> hey saste :) [20:55:22] <saste> hi basty [21:04:03] <CIA-7> ffmpeg: cehoyos * r23148 /trunk/libavcodec/iff.c: [21:04:03] <CIA-7> ffmpeg: Factorize code into a single function. [21:04:03] <CIA-7> ffmpeg: Patch by Sebastian Vater, cdgs D basty A gmail [22:36:11] <DonDiego> gnite [23:01:15] <CIA-7> ffmpeg: stefano * r23149 /trunk/libavcodec/ (opt.c eval.c avcodec.h eval.h ratecontrol.c): [23:01:15] <CIA-7> ffmpeg: Change the order of parameters for ff_eval_expr() and [23:01:15] <CIA-7> ffmpeg: ff_parse_and_eval_expr(), place the names for constants/functions [23:01:15] <CIA-7> ffmpeg: before the corresponding values. [23:01:15] <CIA-7> ffmpeg: This looks more readable, as the user is expected to know the names [23:01:16] <CIA-7> ffmpeg: before the values. [23:15:21] <hyc> wbs: well, 2 problems down, 1 major one to go, ffserver rtsp is almost working now. [23:16:25] <hyc> there's also a minor problem that it busyloops on input, and spends a lot of time reading 1 byte at a time from the network. frightening... [23:16:54] <hyc> eats up 100% of a core on my laptop...

1 0

IRC log for 2010-05-15
by irc＠mansr.com 16 May '10

16 May '10

[01:06:15] <thick_mcrunfast> Just asked this in #ffmpeg, forgot about this channel: [01:06:22] <thick_mcrunfast> hey, trying to compile "segmenter", which is supposed to segment mpeg2ts into files ready for live streaming; unfortunately I can't seem to get it to compile [01:06:29] <thick_mcrunfast> Here's the log: http://paste.pocoo.org/show/214151/ [01:06:35] <thick_mcrunfast> Does this indicate which library I'm missing? [02:11:21] <Dark_Shikari> what's a simple formula to convert 0..63 64..127 -> 0..63 63..0 [02:11:26] <Dark_Shikari> in as few ops as possible [02:11:29] <Dark_Shikari> no branches [02:23:58] <pengvado> remember, we can renumber the states [02:24:21] <pengvado> 0..63 64..127 -> 0..63 0..63 works just as well [02:25:16] <pengvado> or 0..126 1..127 [02:34:09] <nefrir> min(x, 127-x) seems short [02:35:10] <nefrir> if it is for mmx [02:36:52] <Dark_Shikari> pengvado: oh... hmm, true [03:48:39] <hyc> gahh. ffserver always shows "AAC with no global headers is currently not supported." even though I have AVOptionAudio flags +global_header in my <stream> def [03:49:57] <hyc> can't get anything working with rtsp. has anyone tested it successfully recently? [03:50:08] <hyc> google doesn't show any success stories, only people with the same failures [09:20:42] <hyc> hmm, spent all this time screwing around with different container formats and ffserver, finally to realize this: http://code.google.com/p/android/issues/detail?id=1513 [09:20:52] <hyc> Android's rtsp client only supports mp4/3gpp container [12:34:25] <CIA-7> ffmpeg: stefano * r23142 /trunk/libavutil/pixfmt.h: [12:34:25] <CIA-7> ffmpeg: Clarify descriptions for RGB4, BGR4, NV12, NV21, [12:34:25] <CIA-7> ffmpeg: RGB48BE, and RGB48LE pixel formats. [13:00:20] <_av500_> hyc: why not just ask before :) [13:18:48] <hyc> that would have been too easy :P [13:19:52] <hyc> This kinda sucks, can't transcode flv to mp4 in realtime and stream the mp4 concurrently, because you need to add hint tracks after the transcode [13:20:52] <hyc> I was considering adding a URL reader to ffserver, so that it can take an rtmpe stream as input and push it out again as rtsp [13:21:05] <hyc> but it looks like ffserver just plain doesn't work [13:21:42] <hyc> now I'm looking at feng, which uses ffmpeg libraries [13:31:40] <hyc> hmmm. this test stream plays OK on my G1 phone, but not with mplayer or ffplay [13:31:43] <hyc> rtsp://v4.cache7.c.youtube.com/CkYLENy73wIaPQlAxD6Aps4FuxMYEiASFEIJbXYtZ29v… [13:32:04] <hyc> found from this page http://forums.fedoraforum.org/showthread.php?t=242205 [13:32:47] <hyc> ffplay sorta plays it but the video is corrupted [13:33:17] <_av500_> guess thats what utube mobile streams [13:35:08] <hyc> it must be a valid stream, if the phone plays it. but ffplay scrolls line after line of MV errors and other messages [13:35:44] <hyc> laptop and phone are on the same wifi network, so it's not a difference in routing / firewalls whatnot [14:16:36] <wbs> hyc: if you want to stream live rtsp stuff from an url, you can set up DSS, then do ffmpeg -i <inputurl> -f rtsp -vcodec mpeg4 -acodec libfaac rtsp://dss.server/name.sdp, and then you should be able to watch the rtsp url on the phone [14:17:37] <hyc> wbs: how does that work? how can the index stuff be generated on the fly? [14:18:19] <wbs> hyc: when streaming with DSS, there's two options. either you feed it a realtime stream over RTSP/RTP, and it just mirrors it out, that's what the commandline above does [14:18:56] <wbs> or you store it into a file, add RTP hinting, put the file in DSS's movie folder and let it serve it from there [14:19:02] <wbs> but that's not for the realtime/live case [14:19:08] <hyc> ok [14:19:41] <wbs> the RTSP muxer I added in february adds support for the live case, for offline stuff, you can either just mux it into a normal 3gp/mp4 and do MP4Box -hint <file>, or apply the movenc/rtphint patches I sent a few weeks ago [14:19:46] <wbs> ... and still is waiting for review of [14:19:52] <hyc> then that's not what I'm after. I want to grab an rtmp stream (flv H264) and send it out as rtsp (mp4 H264) [14:20:21] <wbs> you can do that with the ffmpeg commandline [14:20:34] <wbs> ffmpeg -i rtmp://whatever -f rtsp rtsp://dss/name.sdp [14:20:42] <hyc> but you can't do the hinting in realtime [14:20:54] <wbs> uh, you don't need hinting in that case [14:21:04] <hyc> you have to have the entire flv converted to mp4 first [14:21:08] <wbs> no, you don't [14:21:36] <wbs> it reads it, packet by packet, puts them in RTP packets and sends them over the network to the DSS server [14:21:46] <wbs> which then relays them to anybody connected to that URL at the moment [14:21:53] <hyc> hmmmm [14:22:00] <wbs> the "hinting" aka RTP packetization is done by the RTP muxer, aka lavf/rtpenc* [14:22:22] <wbs> hinting is only needed when serving archived content from file [14:22:27] <hyc> ok, well that's good news [14:26:06] <hyc> I was hoping to get more clever ... send an rtmp URL to ffserver in params tacked onto the rtsp URL [14:26:23] <hyc> so that it could do the fetch / transcode / serve all in one [14:26:48] <wbs> it might work, I don't really know ffserver at all [14:27:15] <hyc> ffserver appears to be mostly abandonware. [14:27:29] <hyc> lots of questions on the ffserver mailing list, no answers. [14:27:54] <wbs> yeah, if all of its features would work, it would at least be easier to evaluate _what_ it does, I'm not really sure I know, quite frankly [14:28:00] <hyc> http://www.mail-archive.com/ffserver-user@mplayerhq.hu/maillist.html [14:28:18] <hyc> yeah, it's puzzling to say the least. [14:28:29] <hyc> a lot of it is undocumented [14:28:52] <wbs> all the people i've talked with either say that it works automatically and does wonders, and other say that they didn't even figure out what it was supposed to do ;P [14:28:57] <hyc> most of the simple examples I tried didn't work [14:29:34] <hyc> even streaming from a file source over http was chunky / stuttered [14:30:16] <hyc> I read every email in that list archive, never found anything that helped [14:30:46] <hyc> perhaps it works best for live streaming from cameras [14:30:52] <hyc> dunno [14:31:40] <hyc> I couldn't even get it to serve an aac stream, it kept on complaining that global headers are required but were missing [14:31:58] <hyc> and no combination of "flags +global_header" would make that go away [14:49:26] <pross-au> OT: I love it how somebody has found a creative use for defective inter-frame refreshes: http://vimeo.com/3139412 [14:58:40] <Compn> lol fun stuff [16:32:00] <hyc> wbs: hm, my DSS seems to want a username and password before accepting a braodcast [16:55:25] <wbs> hyc: yeah, you set it up through a web ui at http://server:1220/ [16:55:45] <wbs> hyc: then use rtsp://username:password@dss/name.sdp as destination url [16:56:26] <wbs> hyc: if you run ffmpeg and DSS on the same machine, you can send to it without a password, if you use connect to it over localhost [17:05:32] <hyc> ok [17:05:43] <hyc> most of my attempts with ffmpeg just hang [17:05:54] <hyc> Could not write header for output [17:06:06] <wbs> hmm, weird.. the error reporting isn't exactly great [17:06:08] <hyc> twice I've seen it start encoding successfuly, out of 20 tries [17:06:25] <wbs> are you using a normal file as source, or a rtmp url? [17:06:33] <hyc> right now just a flv file [17:06:48] <wbs> if you use a normal file, you need to use -re, to feed the data in realtime pace instead of as fast as it can [17:07:00] <hyc> ok [17:07:20] <wbs> but other than that, it should work; can you wireshark it and see where it stops? [17:07:41] <hyc> damn, it started right up with that [17:08:22] <wbs> oh the irony ;P [17:08:27] <hyc> ;) [17:09:02] <wbs> but let's say there's room for improvement in the error reporting :-) [17:09:57] <hyc> indeed... [17:10:00] <hyc> ok going to try it again [17:11:49] <hyc> yeah, twice in a row, success [17:12:36] <wbs> great! [17:13:11] <wbs> you may want to use h263, mpeg4 or h264 as video codec, and amr or aac as audio codecs then.. don't know if it works with stream copy, but at least when you allow ffmpeg to transcode, it should work [17:13:11] <hyc> thanks for your help ;) [17:13:30] <hyc> yeah, using h264 [17:16:39] <BBB> error reporting is poor for rtsp/http [17:16:44] <BBB> I looked into that in the past [17:16:49] <BBB> but didn't really get anywhere practical yet [17:16:58] <BBB> but patches for that are greatly appreciated </hint> [17:17:16] <wbs> i usually just fire up wireshark instead of trying to look at ffmpeg log level options ;P [17:18:26] <hyc> heh [17:18:40] <hyc> wireshark tends to get directly to the heart of the matter [17:18:57] <wbs> yeah [17:19:23] <wbs> especially in stuff like rtsp which is complex to say the least, the error message reported by the application would probably not really tell the actual problem but just be misleading [17:19:32] <BBB> not true [17:19:39] <BBB> the error from the server generally helps [17:19:42] <BBB> 403 forbidden [17:19:43] <BBB> or whateer [17:19:52] <wbs> yeah, in those cases saying just that would be very helpful [17:19:52] <BBB> that would help a lot as a AV_LOG_ERROR msg [17:20:02] <BBB> a patch for that isn't very hard [17:20:23] <BBB> if (num != 400) av_log(..); [17:20:39] <wbs> but e.g. if trying to watch a stream with unsupported payload formats, it usually gets stuck for a long time when trying to detect the stream parameters [17:20:51] <BBB> I mean 200 [17:21:01] <hyc> hm yeah that would make a big difference [17:21:10] <BBB> anyway [17:21:16] <BBB> wbs: I kow that issue also [17:21:23] <BBB> in the past it motivated me to add support for new pyloads [17:21:26] <BBB> right now it's annoying [17:21:37] <BBB> where's our soc student josh btw? [17:21:59] <wbs> he's been here a few times since he did his qual task [17:22:13] <BBB> ok, good [17:35:35] <CIA-7> ffmpeg: stefano * r23143 /trunk/ffplay.c: [17:35:35] <CIA-7> ffmpeg: Avoid mixed declaration and code, fix C89 compatibility. [17:35:35] <CIA-7> ffmpeg: Patch by Fran?ois Revol revol free fr. [17:49:38] <mru> saste: mmu_man is a committer, he can apply his own patches [17:56:39] <merbanan> mru: how much slower is the arm float 2 int code ? [17:57:10] <mru> which code? [17:57:16] <mru> and slower than what? [17:58:14] <merbanan> I'll elaborate [17:58:29] <merbanan> I'm gonna switch the dca decoder to outputting float [17:58:36] <mru> pretty please, don't [17:58:53] <mru> you'll make it 3x slower on cortex-a8 [17:59:24] <merbanan> ok, what is missing on arm [17:59:30] <merbanan> to not make it 3x slower [17:59:31] <mru> s/arm// [17:59:44] <mru> audioconvert.c is awful [17:59:54] <merbanan> jolly good [18:00:01] <mru> no simd at all [18:00:08] <mru> and bad even for scalar code [18:00:20] <merbanan> so we need dsp accelerated interleavers [18:00:28] <mru> I am so tired of having this discussion [18:00:30] <merbanan> and float2int [18:00:41] <mru> we already have blazing fast float2int [18:00:45] <mru> in dsputil [18:00:46] <wbs> audioconvert isn't part of the external api, btw, so for applications using lavc directly, they have to go through av_resample (without doing any actual resampling) if one doesn't want to code the audio conversion separately [18:01:06] <mru> so we need to fix it up and make it public [18:01:11] <mru> BUT FIX IT FIRST [18:01:44] <mru> merbanan: can you at least leave the scaling in the dca decoder? [18:02:23] <mru> the existing fast float2int code needs input in +-32k range [18:02:37] <merbanan> mru: no [18:02:40] <mru> why? [18:02:43] <merbanan> just the c path [18:02:53] <mru> wrong [18:03:06] <mru> the C code needs +-1 with bias of 384 [18:03:06] <merbanan> hmm [18:03:40] <merbanan> ok ok [18:03:49] <mru> if you remove the scaling in the decoder you'll ruin thousands of lines of asm [18:04:28] <merbanan> for float2int ? [18:04:39] <mru> and in the decoder [18:04:39] <merbanan> or float2int16 [18:04:50] <mru> float2int16 [18:04:55] <mru> that's the only conversion we have [18:05:02] <merbanan> if you need scaling you do it last [18:05:31] <mru> the scaling is combined with the synth filter now [18:05:46] <merbanan> um, doesn't audioconvert use float2int if the codec outputs float ? [18:05:56] <mru> it uses lrintf and scalar mult [18:06:04] <mru> slower than anything you can imagine [18:06:12] <merbanan> but why :( [18:06:18] <mru> because I haven't had time to fix it [18:06:24] <mru> and everybody else refuses to see the problem [18:06:54] <mru> and before you ask, this code is used for real on cortex-a8 devices [18:06:57] <merbanan> float out from codecs are scaled to +-1 IIRC [18:07:06] <mru> gaaaaaaaaaaaahhhhhhhhhhhhh [18:08:07] <mru> did you pay attention to ANYTHING of what I said? [18:08:23] <merbanan> I read every line you write [18:08:30] <mru> that's not what I asked [18:08:33] <merbanan> I think you need a hug [18:08:36] <merbanan> :) [18:08:52] <mru> I need 48-hour days [18:09:35] <merbanan> I'll go and read some code, I just don't understand some things with the audio stuff [18:09:59] <mru> the neon float2int16 is insanely fast [18:10:08] <mru> it does interleaving and clipping [18:10:23] <mru> but it requires pre-scaled input [18:10:54] <merbanan> so is sse and 3dnow, ie fast [18:10:56] <mru> the old codecs, dca, ac3, vorbis, etc all scale internally [18:11:21] <mru> the new ones, wmapro and I forget what else, don't [18:11:38] <Dark_Shikari> could we make it so that float2int16 takes a parameter telling it how much to scale? [18:11:43] <Dark_Shikari> which is passed via the api from the decoder? [18:11:44] <mru> on cortex-a8 decoding wmapro to s16 spends OVER 50% of the time in audioconvert.c [18:11:48] <Dark_Shikari> thus kill 3 birds with one stone [18:11:50] <Dark_Shikari> or something [18:11:52] <mru> Dark_Shikari: no [18:11:55] <Dark_Shikari> why not? [18:12:07] <mru> it's cheaper to scale as part of another step [18:12:12] <Dark_Shikari> really? [18:12:22] <mru> some codecs do it simply by premultiplying some tables [18:12:22] <Dark_Shikari> you mean like during the idct? [18:12:24] <Dark_Shikari> ah [18:12:25] <mru> yes [18:12:30] <merbanan> you can do it in the transform for free [18:12:44] <Dark_Shikari> so what's the debate about [18:12:45] <mru> and the fast float2int16 asm already exists [18:12:47] <Dark_Shikari> why can't wmapro do that too? [18:12:49] <mru> I don't want to rewrite it [18:13:20] <mru> wmapro doesn't because a) the author was lazy, and b) there's API to request it in the first place [18:13:23] <merbanan> so the "new codec api" needs to be able to adjust the scalefactor [18:13:24] <mru> no api [18:13:28] <mru> yes [18:13:46] <Dark_Shikari> so audioconvert needs to handle scale factors, but only _some_ of the time? [18:13:47] <mru> we need to add scale and bias to AVCodecContext [18:13:52] <merbanan> add a scalefactor to avcodec ? [18:14:09] <merbanan> and let decode_audio3 populate it ? [18:14:27] <mru> there's a slight problem [18:14:28] <merbanan> AVCodecContext->scale_factor ? [18:14:46] <mru> the scale factor depends on the output format [18:14:55] <merbanan> sure [18:15:02] <mru> and on the specific implementation of any conversion functions used [18:15:10] <mru> so we have to [18:15:12] <merbanan> but all codecs should output their native format [18:15:16] <mru> 1. query codec output format [18:15:24] <mru> 2. set up conversion [18:15:36] <mru> 3. pass scale/bias from converter to decoder [18:15:51] <merbanan> bias can go go to hell [18:15:53] <merbanan> imo [18:15:58] <mru> there goes the fast C code [18:16:02] <merbanan> or maybe not [18:16:20] <mru> it really is a lot faster sometimes [18:16:51] <merbanan> planar buffers also [18:16:57] <mru> that too [18:17:03] <Dark_Shikari> the float C code crap with the bitmath can die [18:17:07] <Dark_Shikari> it's caused too much bikeshedding [18:17:15] <mru> fine, so kill the bias [18:17:18] <mru> I don't care [18:17:22] <Dark_Shikari> Also, IMO it's useless [18:17:34] <Dark_Shikari> because if you're processing float data -- you're going to be on a cpu with some half-decent fpu [18:17:40] <Dark_Shikari> obviously if you're not, you shouldn't be using float [18:18:24] <mru> indeed [18:18:53] <merbanan> oh, we need downmixing also [18:19:03] <mru> that's separate [18:19:07] <mru> but yes, we need it [18:19:19] <merbanan> hmmm, ok [18:19:20] <mru> it should also be possible to do in the decoder though [18:19:24] <mru> like ac3 and dca do [18:19:48] <merbanan> but we need generic routines [18:20:02] <mru> yes, for aac and vorbis [18:20:09] <mru> and whatever else can't downmix pre-transform [18:20:51] <saste> mru: I get *thousands* warnings of the kind - 'xxx' defined but not used - when compiling [18:21:06] <mru> saste: why are you telling me? [18:21:26] <saste> mru: because you're the configure/make guru :-) [18:21:42] <mru> I'm not the one writing unused code [18:21:50] <saste> mru: I wonder if I'm the only one affected by this... [18:21:57] <mru> did you use --enable-small ? [18:22:02] <saste> since I usually compile *without* optimizations [18:22:12] <saste> so I was trying to look at how to avoid that [18:22:18] <mru> why on earth do you do that? [18:22:41] <saste> uh... I don't remember it had something to do with some gcc bugs [18:22:54] <saste> I don't change my configure line since ages [18:23:00] <mru> maybe you should [18:24:52] <merbanan> omg :/ [18:25:13] * merbanan looked at audioconvert [18:25:32] <mru> good boy [18:25:49] <mru> now do you understand why I object? [18:26:27] <saste> mru: well indeed they disappeared... I suppose I'll enable optimizations since now [18:27:14] <merbanan> saste: use --disable-optimizations --enable-debug=3 --disable-mmx if you need to source level debug something [18:27:32] * mru has never needed that [18:27:58] * merbanan is a visual studio fanboy [18:28:15] * mru is a fan of writing correct code to begin with [18:28:31] <mru> or failing that, looking at the code until the error becomes obvious [18:29:37] <merbanan> sure that is no problem, but try maintaining 100k lines of code you didn't write yourself by just looking at it [18:30:02] <mru> so write it yourself [18:30:09] <saste> that's why I'd prefer to continue to compile without optimizations... [18:30:23] <mru> jokes aside, debuggers are only useful for looking at core dumps [18:30:31] <mru> stepping through code is a waste of time [18:30:43] <mru> adding a few printfs is much more efficient [18:31:02] <merbanan> well have you heard of globals ? [18:31:18] <mru> they're evil [18:31:30] <mru> the ones we have are mostly static or write-once [18:31:35] <merbanan> it was very much used in the code I maintain [18:31:49] <mru> not that I see the connexion with debuggers [18:34:02] <merbanan> well, you never know what thread modifies what member in the global structs so I prefer to use source level debuggers in that kind of area [18:34:36] <mru> I've occasionally used jtag debuggers for such things [18:34:40] <mru> on mmuless systems [18:35:02] <merbanan> what kind of scaling does the cortex need ? [18:35:14] <mru> same as all the other asm [18:35:21] <mru> -32k..32k [18:35:49] <merbanan> ok, if we drop the c bias we don't need any scaling [18:35:58] <mru> yes we do [18:36:14] <mru> "native" float range is -1..1 [18:36:22] <mru> that's what wmapro outputs [18:37:24] <merbanan> and that can be remuxed directly into compliant .wav ? [18:37:50] <mru> I've no idea [18:38:04] <mru> I've never owned anything that could handle float samples [18:39:18] <merbanan> I think we need to sort out what range/resolution and scale formats have [18:39:25] <merbanan> and what we need in ffmpeg [18:40:53] <merbanan> or what is commonly used in different containers etc [18:40:55] <mru> the wav spec says only "PCM audio in IEEE floating-point format" [18:41:17] <merbanan> how nice :/ [18:41:35] <mru> for format code 3 [18:42:23] <merbanan> I'd like to know how the formats all relate to each other [18:48:03] * _av500_ thanks mru for fighting his cause [18:54:20] <merbanan> if you treat int16 as Q1.15 then float at -1:1 make sense but what about int24 then ... [18:54:43] <merbanan> is it just Q1.23 ? [18:54:58] <mru> _av500_: everything is pointing towards an avcodec_decode_audio4() [18:55:18] <merbanan> and a 5 when we add downmixing :) [18:55:29] <mru> we already have that [18:55:32] <mru> in the api [18:55:46] <mru> it's the standalone downmixing that's missing [18:56:58] <merbanan> yes correct [18:57:16] <merbanan> but downmixing ac3 and dts isn't the same [18:57:23] <_av500_> mru: fine with me as long as i get to select the fixed point output somehow [18:57:27] <merbanan> they use different coeffs [18:57:44] <mru> ac3 and dts downmixing is defined by their specs [19:00:02] <Kovensky> CC libavcodec/aaccoder.o [19:00:02] <Kovensky> gcc: Internal error: Segmentation fault (program cc1) [19:00:02] <Kovensky> yay [19:00:11] <Kovensky> not reproducible though :/ [19:00:15] <mru> bad ram [19:00:15] <Kovensky> rerunning make worked [19:00:22] <Kovensky> hmm, maybe [19:00:25] <_av500_> compiling on XM? [19:00:38] <Kovensky> I'm getting some creepy kernel Oops when running wine apps too [19:00:38] <Kovensky> http://pastebin.org/240444 [19:01:46] <mru> bad ram [19:02:53] <Kovensky> oh well [19:02:57] * Kovensky installs memtest86 [19:03:16] <mru> too much overclocking? [19:03:36] <Kovensky> well, I did overclock my CPU, but only by 100MHz ._. [19:04:20] <Kovensky> the multiplier is locked, I can only mess with FSB freq, and increasing it too much makes the RAM not work [19:04:33] <mru> of course [19:04:33] <Kovensky> lol 1600MHz K8 CPU on PCCHIPS mobo [19:09:04] * Kovensky goes turn the overclocking down a notch or two and run memtest [19:18:07] <mru> there, flame started [19:20:49] <mru> I'm going out for a while, please don't do anything rash while I'm gone [19:21:04] <mru> that is, don't commit any float-audio stuff until I've had a look [19:22:28] <elenril> or you'll remove their commit rights? ;) [20:28:00] <Kovensky> yep, bad ram, errors on 0x2256bcc4 even @ stock clocks [20:36:49] <iive> Kovensky: time to buy something more expensive with heatsinks on it. [20:42:56] * Kovensky has $-150 [21:49:25] <hyc> wbs: thanks for your help. I've now got Hulu streaming to my G1 in realtime [21:49:57] <wbs> hyc: congrats! [21:50:35] <hyc> yeah it's pretty cool. someone else could take it and turn it into an app I suppose [21:50:52] <wbs> hyc: you may want to tweak the reflector_buffer_size_sec value in streamingserver.xml btw, the default of 10 is a bit high, you can adjust it down to 1, to get lower latency, if that's of interest [21:51:18] <hyc> i don't think it's a problem right now [21:51:23] <wbs> ok [21:51:34] <wbs> I guess this is the second user of the RTSP muxer, except me ;P [21:51:41] <hyc> lol [21:51:58] <wbs> i debugged the youtube rtsp url you sent btw [21:52:11] <hyc> rtmp and rtsp all at once [21:52:19] <hyc> oh yes? what did you find? [21:52:40] <wbs> well, the audio format isn't supported at all, so it not working is just to be expected, but the video track is quite problematic too [21:52:52] <wbs> it sends the video packets out of order for some strange reason [21:53:13] <wbs> not sure if that's in the original data on their servers, or just always reordered in transport [21:53:35] <wbs> the libavformat rtpdec code needs to buffer packets and reorder them to get it decoded sanely [21:53:38] <hyc> ah... well this is UDP after all [21:54:04] <wbs> yeah, but I have never seen any such problems before, so it may actually be reordered in that way at the sending end, for some strange reason [21:54:33] <wbs> I'm hoping for a good explanation from lu_zero, I'm writing a RFC on the issue now [21:55:43] <hyc> sounds like it'll be interesting. how is anyone supposed to know how many packets to buffer [21:57:16] <wbs> yeah [22:14:03] <kierank> oh dear mp4a-latm in rtsp...that's not going to end well :/ [23:35:33] <Kovensky> oh, so people will finally have "motivation" to make LATM work? =p [23:35:54] <iive> what is latm? [23:36:05] <Kovensky> some aac thing [23:36:14] <iive> oh. [23:36:14] <Kovensky> used by some obscure DVB and ISDB broadcasters

1 0

IRC log for 2010-05-14
by irc＠mansr.com 15 May '10

15 May '10

[05:54:07] <hyc> hmm, seems like something is wrong with the libx264-baseline.ffpreset file [05:54:34] <hyc> always gives "broken ffmpeg default settings detected" [05:54:41] <hyc> default and main still seem to work [05:54:49] <hyc> ipod320 and ipod640 also give the same error [05:56:34] <hyc> Dark_Shikari: any hints? [05:59:36] <wbs> hyc: baseline shouldn't be used as such on its own... first load e.g. default or hq or fast or any such, and then baseline or main on top of that, for selecting profile [05:59:47] <hyc> ohhhh [06:05:26] <hyc> okwbs: thanks [09:52:28] <nfl> hi is there an api call for reading from a ByteIOContext which won't advance buf_ptr? [09:54:54] <mru> read followed by seek back [09:57:48] <nfl> silly me [09:59:15] <nfl> that is ugly though [09:59:31] <mru> are you sure the reason you want this isn't ugly? [09:59:56] <nfl> pretty sure :) [10:03:03] <superdump> do you need to 'peek' some data for some reason? [10:03:35] * mru can't imagine a valid reason to do that [10:03:49] <nfl> superdump: yes, to read byte header for each frame in g723.1 [10:04:05] <nfl> umm, 2 bits of the 1st byte [10:05:04] <nfl> perhaps there's a better way? [10:06:51] <superdump> why do you need to peek it and not read it? [10:07:02] <superdump> get_bits () perhaps? [10:07:17] <mru> ByteIOContext... [10:08:02] <superdump> but why not use a get bits context? [10:08:28] <superdump> either use byte reading with masks and shifts or get bits [10:08:48] <mru> I guess he's reading from a file [10:08:59] <nfl> superdump: i'm calling get_packet in the demuxer with the size calculated from the 2 bits of the 1st byte of each frame [10:09:04] <mru> that's what ByteIOContext does [10:09:44] <mru> so read one byte, extract the 2 bits, then read the rest [10:10:18] <nfl> mru: the first byte needs to be in the packet too [10:10:28] <mru> so put it there [10:10:53] <nfl> get_buffer() ? [10:13:48] <nfl> ah got it now, thanks [10:14:25] <lu_zero> yawn [10:15:01] <lu_zero> good morning [11:48:58] <pengvado> I have a bunch of memory that is allocated but never used. i.e. top says VIRT >> RES. is there any easy way to find out which mallocs those are from? [11:54:00] <kshishkov> valgrind? [11:57:04] <nfl> merbanan: ping [11:59:24] <mt> when using the wma pro decoder, every frame within the packet is output on its own, unless it's ignored for some reason (like being the very first frame in the files or crossing the packet boundary), right ? [12:01:08] <kshishkov> seems so [12:35:37] <kierank> do people actually use wma pro? [12:36:42] <kshishkov> yes [12:37:16] <kshishkov> and please ask BBB if people use wma speech [12:37:46] <kierank> ah wikipedia says all the microsoft services use it [12:37:49] <kierank> (wma pro) [12:38:08] <kshishkov> people may use it too [12:53:46] <tetsuo--> what a coincidence, i was just talking to someone about wma audio [14:09:54] <reynaldo> hi guys [14:10:23] <mru> hi reynaldo [14:10:37] <reynaldo> howdy mru, long time no see [14:11:04] <reynaldo> we had a major earthquake around here a month or so ago, kind of a big deal [14:11:11] <mru> yeah, I know [14:11:18] <reynaldo> witha tsunami and all the bells and whistles [14:11:45] <reynaldo> anyway, things are slowly geting back to normal, so am I [14:12:08] <reynaldo> got a lot to catch on on -dev :| [14:15:36] <mru> try not to reignite any finished flame wars [14:16:45] <reynaldo> will keep that in mind. Guess you had a few :) [14:17:09] <thresh> is bank wire transfer a really secure payment? [14:17:11] <BBB> hey reynaldo, great to see you back [14:17:20] <thresh> OT, sorry :) [14:17:44] <BBB> wires are safe, yes [14:17:57] <mru> well, as safe as most alternatives [14:17:57] <reynaldo> BBB: hi there, thanks. [14:18:26] <thresh> hehe, well. need to pay some .eu-based company for a device. [14:18:33] <mru> brown bags with used, non-consecutive notes might be preferable in some cases [14:18:54] <reynaldo> thresh: secure? don't know. slow? hell yes [14:19:05] <BBB> expensive? hell yes [14:19:18] <mru> I can do a wire transfer within the UK for free and with immediate effect [14:19:18] <reynaldo> that too [14:19:19] <thresh> hmm [14:19:27] <mru> internationally it's rather grim [14:19:34] <reynaldo> mru: I guess he is talking about overseas transfers [14:19:36] <thresh> guess it all depends on a bank. [14:19:59] <thresh> not overseas, but russia - cztch. [14:20:04] <reynaldo> thats the main issue, with an international wire transfer it atually depends on at least two banks [14:20:08] <thresh> czech :) [14:20:13] <reynaldo> problems scale fast :) [14:20:50] <mru> thresh: can you use IBAN? [14:21:02] <thresh> what is it? [14:21:09] <mru> guess the answer is no then [14:21:16] <mru> international bank account number [14:21:39] <mru> international == eu, .ch + a few more european countries [14:21:43] <thresh> no idea if i has it. probably not.. [14:22:44] <thresh> i wonder how many % will my bank want [14:23:04] <mru> my bank charges a flat fee [14:23:10] <mru> + currency conversion commission [14:23:27] <mru> the recipient bank may also charge [14:23:56] <mru> it's usually cheaper to send money in your currency and let the recipient do the conversion [14:24:40] <thresh> i somehow doubt the companu would accept RUR [14:24:48] <thresh> company. [14:25:27] <mru> that's not the question [14:25:40] <mru> they're account will probably be held in euro [14:25:49] <mru> so anything going in will be converted [14:25:54] <thresh> think so, yeah [14:27:58] <mru> for some reason, banks often take less commission on incoming conversion than on outgoing [14:28:17] <mru> not that it really matters [14:28:24] <mru> you're talking about ~2% either way [14:28:49] <mru> then you'll have a flat fee on top of that [14:29:13] <mru> typically 10-20 euros or equivalent [14:30:03] <mru> when sending money, your bank will try to trick you into paying ~double fee with a promise that it will cover all fees on the receiving end [14:30:30] <mru> the reality is that the receiving fee is usually much smaller, if there is one at all [14:31:00] <mru> then again, if it's a lot of money, the difference is probably not huge [14:31:36] <mru> 10 euros this way or that on a 10k transfer isn't worth the time to worry about [14:59:31] <thresh> yeah, just checked my bank rates on that, it's 1 percent, so about 20 eur.. [15:51:45] <mmu_screen> plop [15:51:52] <mmu_screen> mru: btw, did you plan anything for RMLL ? [15:52:06] <mru> rmll? [15:52:38] <mmu_screen> http://rmll.info [15:52:56] <mmu_screen> I suppose it answers the question :) [15:53:14] <mru> oh, that [15:53:42] <mru> nothing planned [15:53:58] <DonDiego> mmu_screen: btw, we're now waiting *years* for you to clean up the beos bits in configure and elsewhere.. [15:54:22] <mmu_screen> yeah I know, been waiting for years to get mru not to veto my patches :D [15:54:28] <mmu_screen> quite busy atm [15:54:32] <DonDiego> nonsense [15:54:36] <mru> then I'll just delete the lot [15:54:47] <mmu_screen> tsss [15:54:49] <DonDiego> you keep claiming that and it's completely wrong [15:55:21] <DonDiego> you conveniently forget that i am configure maintainer as well [15:55:21] <mmu_screen> no it's not [15:55:29] <mmu_screen> anyway [15:55:36] <DonDiego> i have never seen any patches from you [15:55:40] <mmu_screen> yes but they touch other stuff as well [15:55:59] <mru> maybe that's the problem [15:56:03] <mmu_screen> anyway, I'll try to come up with another solution that doesn't hack in libavutil/internal.h [15:56:04] <DonDiego> the patches cannot have been vetoed because they never appeared [15:56:25] <mmu_screen> I don't have time to argue or dig gmane.net [15:57:08] <DonDiego> what's missing? [15:57:26] <DonDiego> apparently a new haiku version was just released... [15:57:27] <mmu_screen> all those PRI* and INT64_C crap [15:57:36] <DonDiego> what about them? [15:57:45] <DonDiego> it's standard posix stuff [15:57:48] <mmu_screen> BeOS doesn't have them defined [15:57:59] <mmu_screen> because it predates this POSIX version [15:58:16] <mru> that means your system is unsupported [15:58:16] <mmu_screen> Haiku should have them though I didn't check for all of them yet [15:58:33] <mmu_screen> that means you don't want your software to be portable :p [15:58:42] <DonDiego> bullshit [15:58:57] <DonDiego> it means you don't want your OS to support portable software [15:59:11] <DonDiego> how hard can it be to implement inttypes.h? [15:59:16] <DonDiego> *once* [15:59:37] <mmu_screen> I am *not* supposed to port my OS, but the application [15:59:41] <DonDiego> and then magically see dozens or hundreds of apps compile on your_os_of_choice [16:00:15] <DonDiego> you will never get anywhere with this attitude [16:00:25] <DonDiego> why port applications one by one [16:00:35] <DonDiego> when you can port them dozens or hundreds at a time? [16:00:48] <DonDiego> oh wait, you're not *supposed* to be sensible [16:00:55] <peloverde> making a stdint header will solve portability headaches for hundreds of apps [16:01:14] <DonDiego> better continue down the road to nowhere, because it's the_way_i_have_always_worked [16:02:04] <DonDiego> mmu_screen: you have *never* provided a single sane argument except "it's *supposed* to work that way" [16:02:15] <DonDiego> mmu_screen: what gives? [16:02:48] <DonDiego> mmu_screen: you're neither stupid, nor wearing your ass as hat, so ... - why? [16:02:58] <DonDiego> why, oh why? [16:02:59] <DonDiego> ... [16:03:15] <mmu_screen> ... [16:03:33] <DonDiego> and then you go mum [16:03:42] <Dark_Shikari> http://markwadestone.files.wordpress.com/2009/10/asshat4.jpg [16:03:44] <mru> he's a french beos user... can't get much worse :-) [16:03:49] <DonDiego> IOW you don't have any arguments [16:04:34] <DonDiego> also, creating portable headers is not without precedent.. [16:04:53] <DonDiego> notice that people have done it for mingw [16:05:17] <DonDiego> you could just copy that [16:05:23] * mmu_screen throws a pile of Minix 3 CDs at mru [16:05:28] <mmu_screen> (I do have them) [16:06:00] <mmu_screen> DonDiego: yes, but I hate having to do this [16:06:09] <DonDiego> hate what? [16:06:14] <DonDiego> make your platform usable? [16:06:19] <mmu_screen> bleh [16:06:35] <DonDiego> answer me, what is it that you hate? [16:06:51] <Dark_Shikari> babies. that's what he hates. [16:07:41] <DonDiego> i'm losing patience here because i've been pinging your ethereal patches for years now and all i ever hear is nonsense excuses [16:07:55] <mmu_screen> interestingly btw, libavutil/internal.h has a lot of #ifndef INT16_MIN [16:08:04] <mmu_screen> aren't those in POSIX either ? [16:08:09] <mru> I'll gladly remove those [16:08:23] <DonDiego> sometimes it's "evil trolls after my work", then it's "i absolutely want to go down the road of maximum pain" [16:08:40] <DonDiego> never anything sane [16:08:48] <DonDiego> plus: mru != DonDiego [16:10:19] <peloverde> I don't know it's a fascinating theory, sure i've seen you both in the same room but a master of cybernetics or holography could totally pull it off [16:10:49] <mmu_screen> sometimes it's "he's been trolling too much, he deserves this in return" [16:10:57] <mmu_screen> :^) [16:12:03] <DonDiego> another lame excuse [16:12:45] <DonDiego> excuses, pretexts, non-sequitur arguments [16:14:11] <Dark_Shikari> the worst way to spend one's time is to spend hours complaining about having to do something that takes 30 minutes [16:14:22] <DonDiego> well said [16:14:43] <Dark_Shikari> and seriously, inttypes? that's like not having log2 [16:14:50] <Dark_Shikari> eh, worse than not having log2 [16:14:55] <Dark_Shikari> that's like not having "for" [16:14:58] <DonDiego> mmu_screen: at least be honest and stop pretending that you maintain the beos port of ffmpeg.. [16:15:00] <Dark_Shikari> and saying "oh, but you can just use while" [16:15:04] <peloverde> "If you don't 'git push' today, your day was a waste of time" [16:15:22] <Dark_Shikari> peloverde: commit. pushes should be rare, after testing is done [16:17:01] <DonDiego> and then he went silent... [16:17:10] <mmu_screen> DonDiego: I do [16:17:37] <DonDiego> no, you do not [16:17:38] <mmu_screen> you're just not making my job easy... [16:17:50] <DonDiego> if you did, you would work, not flame and heckle [16:18:03] <DonDiego> quit filibustering and hit the keyboard [16:18:41] <DonDiego> i've tried to get you to continue countless times [16:18:45] <mmu_screen> which is what I'm doing when I'm "silent" [16:19:16] <mmu_screen> let's see if this builds... [16:20:17] <DonDiego> you've been silent for years and flamed in between, we're talking about getting a single app to compile [16:20:44] <DonDiego> nothing that should take you more than, say, an hour or two [16:21:19] <DonDiego> a day or two if you type with your nose, one character per minute [16:26:42] <mmu_screen> also depends on the compiler speed [16:26:43] <mmu_screen> ... [16:28:16] <DonDiego> stop talking nonsense, i work on the slowest dev machine in existence [16:28:30] <DonDiego> we're talking about 500mhz here [16:29:02] <mmu_screen> oh I can reinstall on my K6-2 350 if you want... [16:29:15] <mmu_screen> anyway, seems to be building so far [16:29:23] <mmu_screen> I'll make a patch tomorrow [16:29:27] <mmu_screen> gtg [16:30:28] <mmu_screen> btw, I think the split haiku case in configure was oked, I should probably commit that first [16:30:39] <spaam> DonDiego: time to buy a new one? :) [16:31:15] <mmu_screen> I can give him an ssh accound on my K6-2 :DDDD [16:31:41] <spaam> 350mhz? [16:31:52] <mmu_screen> I even have a powerpc mac clone around, probably slower [16:32:02] <mmu_screen> yup [16:32:15] <mmu_screen> parse error hmmm [16:32:23] <mmu_screen> before int [16:32:28] <mmu_screen> C89 I guess [16:33:15] <nfl> merbanan: ping [16:33:55] <mmu_screen> ok, all built [16:34:11] <mmu_screen> tomorrow I'll clean up the other changes I made to make sure they are required [16:34:14] <mmu_screen> and send a patch [16:34:15] <mmu_screen> bbl [16:34:24] <DonDiego> surprise me.. [16:34:42] <DonDiego> are you guys aware of anything that needs to go in 0.5.2? [16:35:19] <mmu_screen> DonDiego: it's even in iCal :D [16:35:23] <peloverde> what was the r# for the branch? [16:35:52] <peloverde> r23017? [16:37:40] <peloverde> Conrad's schroenc commits may be useful [16:40:55] <DonDiego> what did he do? [16:45:18] <peloverde> commits r23025-23030, things like set colorspace info, adaptive GOP by default, keyframe interval [16:46:22] <Dark_Shikari> and make the "constant quality" mode work properly [16:47:22] <DonDiego> Yuvi: you around? [16:50:05] <CIA-7> ffmpeg: alexc * r23132 /trunk/libavcodec/ (aacenc.c aacpsy.c): [16:50:05] <CIA-7> ffmpeg: aacenc: Fix psy logic. [16:50:05] <CIA-7> ffmpeg: Set band info before determining scalefactors. Use the look ahead for [16:50:05] <CIA-7> ffmpeg: windowing decision. [16:50:06] <CIA-7> ffmpeg: alexc * r23133 /trunk/libavcodec/aacenc.c: aacenc: Select the TLS (two-loop search) as the default scalefactor coder. [16:50:07] <CIA-7> ffmpeg: alexc * r23134 /trunk/libavcodec/aaccoder.c: aacenc: Use an estimated codebook for the TLS (two loop search). [16:50:08] <CIA-7> ffmpeg: alexc * r23135 /trunk/libavcodec/ (aaccoder.c aacenc.h): [16:50:08] <CIA-7> ffmpeg: aacenc: Use exact values when quantizing, not fuzzy values. [16:50:08] <CIA-7> ffmpeg: This requires us to code small escapes; we can't avoid it. [16:50:46] <CIA-7> ffmpeg: alexc * r23136 /trunk/libavcodec/aaccoder.c: aacenc: Add a rate only trellis for codebook selection for the TLS. [16:51:05] <peloverde> Dark_Shikari, ABR AAC at ~64k/channel should now suck significantly less [16:51:09] <Dark_Shikari> Awesome [16:51:12] <Dark_Shikari> comparison to FAAC? [16:51:20] <pJok> what? someoone fixed ffaacenc? [16:51:37] <peloverde> fixed is a relative term [16:51:54] <pJok> anything making it better than what it was is fixing [16:53:29] <peloverde> I haven't spent too much time comparing it to faac, I've mostly just been comparing it to it old self and using nero for cues about the "right way" to handle certain situations [16:54:24] <BBB> peloverde: \o/ [17:34:55] <Yuvi> DonDiego: pong [18:06:31] <DonDiego> Yuvi: are you libschro commits 0.5 branch matter? [18:07:51] <DonDiego> anyway, i gtg now, talk to you later or send me an email [18:07:53] <DonDiego> bye [18:28:46] <j-b> who is looking for a job around here, btw ? [18:29:07] <mru> what can you offer? [18:29:13] <mru> not that I have time for any more work atm [18:30:18] <j-b> not a contractor job, I believe [18:30:46] <mru> if you provide more details, you'll have better chance of someone picking it up [18:31:28] <j-b> I was just wondering if there were some people unemployed or soon-finishing-univ now around FFmpeg [18:43:21] <peloverde> j-b, there are but without any details you probably aren't going to attract a lot of attention [18:43:32] <Dark_Shikari> +1 [18:44:46] * BBB adds a metoo [18:45:32] <Dark_Shikari> oh, and on the topic of that h265 encoder test I was doing [18:45:38] <Dark_Shikari> apparently the Intel proposal is even slower [18:45:42] <Dark_Shikari> 500 times slower than the reference [18:46:15] <BBB> but is that intrinsic slowness or can it be optimized? [18:46:25] <BBB> as in, could intel release cpu extensions to alleviate that? [18:46:26] <Dark_Shikari> intrinsic. well, I mean, obviously if it used less stupidly slow algorithms [18:46:35] <BBB> that's the whole point [18:46:36] <Dark_Shikari> but given the stupidly slow algorithms they use, they're intrinsicly slow [18:46:39] <BBB> can the algo be optimized? [18:46:56] <Dark_Shikari> algos like samsung-bbc's "search every quantizer for every single permutation of hierarchical block types"? [18:47:02] <Dark_Shikari> sure, by NOT DOING THAT [18:49:08] <mru> aka use some heuristic [18:52:37] <CIA-7> ffmpeg: mstorsjo * r23137 /trunk/configure: Change inter-protocol dependencies from _deps to _select [18:56:48] <j-b> peloverde: If I could, I would. [19:07:57] <_av500_> mru: its a job doing stuff with things of course [19:12:53] <_av500_> Dark_Shikari: what about "try every possible valid bitstream sequence and select the one that happens to encode the wanted image with the least bits"? [19:13:46] <BBB> that's h267 [19:14:02] <_av500_> not h666? [19:14:21] <BBB> lands you straight in hell666 [19:14:31] <j-b> Dark_Shikari: so h265 is still faaaaaaar faaaaaaaaaar faaaaaaaaaaar away ? [19:14:47] <mru> a few years at least [19:14:58] <_av500_> j-b: no need for that "mkdir x265" now... [19:15:11] <Dark_Shikari> _av500_: better [19:15:14] <Dark_Shikari> try every possible program [19:15:21] <Dark_Shikari> and select the one which encodes the image with the fewest bits [19:15:34] * _av500_ order a million monkeys... [19:15:39] <Dark_Shikari> Put a cap on the runtime, of course, to make it merely EXPTIME as opposed to halting-problem-hard [19:15:40] <j-b> genetic algo [19:16:03] * _av500_ never experienced a halting problem.... [19:17:14] <mru> that was just too funny [19:17:41] <BBB> I can see how some fucked up implementation would use a macro instead of static inline [19:18:02] <BBB> and do result=MIN(program_a(), program_b(), program_c()); [19:22:53] <Dark_Shikari> that would still be EXPTIME [19:24:48] <BBB> only if any of the results generates that [19:24:53] <BBB> what if the results take finitely long? [19:25:04] <BBB> 1+1+2.5hrs then becomes 1+1+1+2.5hrs [19:25:08] <BBB> that's another 1 hour [19:25:09] <Dark_Shikari> it's still EXPTIME [19:25:14] <BBB> well yeah [19:25:17] <BBB> but more [19:25:25] <Dark_Shikari> running an EXPTIME program an exponential number of times is still EXPTIME [19:25:39] <BBB> I don't do math like that [19:25:44] <BBB> for me, math has numbers and logic in it [19:26:04] <Dark_Shikari> no, that isn't math [19:26:04] <mru> that's not maths, it's complexity theory [19:26:08] <Dark_Shikari> numbers are arithmetic, not math [19:26:10] <Dark_Shikari> =p [19:26:11] <BBB> I barf at statisticians that pride in their sigma and their mu [19:26:28] <Dark_Shikari> actually, that would have been 2-EXPTIME [19:26:32] <Dark_Shikari> running an EXPTIME program an exp number of times [19:26:43] <Dark_Shikari> interesting, EXPSPACE is a subset of 2-EXPTIME [19:34:19] <BBB> mru: there's still the outstanding question of whether FFMAX() is faster than a typed max() math function [19:34:29] <BBB> mru: which I admittedly failed to address properly [19:35:15] <mru> there's no inherent reason for any difference at all [19:35:45] <peloverde> sometimes you wind up with different generated code because of implicit float casts, but not in this case [19:36:15] <mru> are the values all float to begin with? [19:36:28] <Dark_Shikari> it would be nice to have a C-like language with haskell type semantics on compile-time [19:36:28] <peloverde> in this case they are [19:36:34] <Dark_Shikari> i.e. no actual difference in compiled asm [19:36:42] <Dark_Shikari> but the ability to have strong typing and smart typing [19:36:47] <Dark_Shikari> e.g. [19:37:05] <Dark_Shikari> type max( type x, type y ) [19:37:08] <mru> but I like to xor my floats with pointers... [19:37:12] <Dark_Shikari> which takes any x and y of the same type [19:37:17] <Dark_Shikari> and returns the same type [19:37:27] <Dark_Shikari> mru: it could be overridable type semantics [19:37:33] <Dark_Shikari> e.g. you can override the strong typing with explicit casts if youw ant. [19:37:35] <Dark_Shikari> *want [19:38:18] <Dark_Shikari> the really great thing about haskell type semantics is that they don't place any runtime requirements on, well, anything [19:38:22] <mru> bonus points if you can abuse low bits of pointers to hold some extra information [19:38:26] <Dark_Shikari> so they can be implemented entirely in a compiler [19:38:32] <Dark_Shikari> mru: then create a type for that [19:38:40] <Dark_Shikari> PointerWithExtraBits [19:38:53] <Dark_Shikari> make a function (always inlined, of course) that returns extra information from it [19:38:58] <Dark_Shikari> etc [19:39:06] <CIA-7> ffmpeg: alexc * r23138 /trunk/libavcodec/aaccoder.c: fmaxf -> FFMAX to fix pre-C99 systems [19:40:43] <BBB> I had to add that to the wiki quotes page [19:40:52] <peloverde> personally I find fmaxf more aesthetically pleasing ;-P [19:41:26] <BBB> a function has the pleasing side-effect of not calculating the argument twice [19:41:37] <BBB> FFMAX(x-y, z); calculates the minus twice [19:41:47] <BBB> I've always found it odd that it was a macro, not a static inline [19:42:02] <Dark_Shikari> static inline would require it being typed [19:42:06] <BBB> true [19:42:26] <BBB> no optimal solution out there I guess :( ohwell shall we recode ffmpeg in haskell then? [19:42:45] <Dark_Shikari> does C++0x have inferred types? [19:42:55] <Dark_Shikari> if so, borrow that one feature, ban the rest of the language [19:43:06] <Dark_Shikari> haskell has much better syntax than anything C++-derived though. [19:43:13] <Dark_Shikari> having to make classes to define types kinda sucks [19:43:51] <Orphis> Do someone has any recommandation to give when making a new demuxer format ? [19:44:43] <BBB> Orphis: use matroska? [19:45:16] <Orphis> Well adding a new demuxer to ffmpeg, sorry, not creating a brand new format [19:45:20] <Dark_Shikari> for what format [19:45:57] <Orphis> http://wiki.multimedia.cx/index.php?title=PSMF [19:46:42] <Dark_Shikari> that's just MPEG-PS [19:47:01] <Dark_Shikari> so any "demuxer" should probably be a thin wrapper around ps [19:48:53] <Orphis> Alright [20:22:25] <wbs> mru: i noticed that if_any config items can fail to be enabled if the if_any items are enabled after the main item is enabled [20:22:31] <wbs> that is, if I do e.g. --disable-demuxers --disable-muxers --enable-muxer=(whatever) that enables a demuxer implicitly through a _select, CONFIG_DEMUXERS doesn't get set [20:23:08] <wbs> this particular case can be fixed by shuffling the order that check_deps is done, but that doesn't feel like a sane solution [20:53:56] <dezodorant> hi [20:54:18] <dezodorant> broken build detected [20:54:31] <dezodorant> http://pastebin.org/237095 [21:16:05] <mru> in b4 the script [21:20:55] <bcoudurier> no script today [22:04:01] <hyc> the ffserver docs could use some fleshing out... is an ffm feed supposed to only contain raw audio/video? [22:04:30] <hyc> all the examples I've seen show ffmpeg reading from e.g. a camera and outputtting to the ffm [22:05:22] <hyc> I'm trying to grab an rtmpe stream and server it over rtsp [22:05:32] <CIA-7> ffmpeg: bcoudurier * r23139 /trunk/libavformat/utils.c: [22:05:32] <CIA-7> ffmpeg: Change MAX_READ_SIZE message during av_find_stream_info to DEBUG level. [22:05:32] <CIA-7> ffmpeg: It is not harmful and it scares too many users. [22:06:22] <hyc> the rtmpe stream is flv H.264MP 512x288. I need it transcoded to H.264BP 480x272. that usually isn't a problem [22:06:44] <hyc> but I don't know if I should do this on the ffmpeg input side, or in the ffserver config [22:07:52] <hyc> and I seem to be doing something wrong anyway, because I always get an error message "AAC with no global headers is currently not supported" [22:08:01] <hyc> that shows up when an rtsp client tries to connect [22:08:58] <hyc> (the audio track is aac) [22:10:44] <hyc> will ffserver take input from an arbitrary URL? if so I guess I could have it read the rtmpe URL instead of relaying thru ffmpeg first [22:48:31] <nefrir> hi, I am looking for someone that can explain a bit more the non reindent rule (when commiting) [22:48:37] <nefrir> when does it applies exactly ? [22:48:49] <Dark_Shikari> generally if it's more than a couple lines, don't [22:48:54] <nefrir> only for a bunch a lines untouched ? [22:48:57] <Dark_Shikari> i.e. if it's enough to make the patch unclear [22:49:08] <Dark_Shikari> if it's just a couple, you can wing it [22:49:43] <nefrir> http://pastebin.org/237249 vs http://pastebin.org/237251 [22:49:54] <nefrir> I think http://pastebin.org/237251 is better and should be ok [22:49:56] <nefrir> but ... [22:50:24] <Dark_Shikari> I like http://pastebin.org/237249 [22:50:43] <Dark_Shikari> but we should probably get feedback from someone who isn't me [22:50:47] <nefrir> mmh actually I messe up , it's the opposite I mean [22:51:02] <nefrir> k, will go with it [22:51:25] <nefrir> the thing is I reindent but also change the variable in it [22:51:40] <nefrir> so IMHO it can be commited at the same times but ... [22:52:11] <nefrir> (as I don't really understand the rationnal when commiting...) [22:56:43] <nefrir> non reindented is more like: http://pastebin.org/237278 [23:09:14] <CIA-7> ffmpeg: fenrir * r23140 /trunk/libavcodec/dxva2_h264.c: [23:09:14] <CIA-7> ffmpeg: Fixed h264 long term support with dxva2 AVHWAccel. [23:09:14] <CIA-7> ffmpeg: Based on a commit for vaapi(r22869). [23:10:01] <CIA-7> ffmpeg: fenrir * r23141 /trunk/libavcodec/dxva2_h264.c: Reindent after last commit on dxva2 h264 AVHWAccel. [23:14:09] <nefrir> mmh using dxva2/vaapi/vdpau is complex [23:14:23] <nefrir> they could have done the parsing themselves [23:21:24] <bcoudurier> nefrir, when the block to reindent is big [23:21:27] <bcoudurier> don't [23:21:54] <bcoudurier> like adding if () { many lines untouched } else { your code }

1 0

IRC log for 2010-05-13
by irc＠mansr.com 14 May '10

14 May '10

[02:57:12] <Dark_Shikari> mru: you know anything about gcc and linking? [02:57:29] <Dark_Shikari> we're getting some very bizarre behavior with loading from extern'd arrays [04:09:10] <saintd3v> peloverde: dud baudline work for what you needed? [04:09:39] <peloverde> It's working better than audacity for what I do [08:42:23] <thresh> 23095 broke libavcodec/mpegaudiodec.c compile for me, http://pastebin.com/nBVpdK2g [08:46:32] <thresh> i've got CONFIG_MPEGAUDIO_HP as 0 [08:48:07] <thresh> no idea though why i disabled it [08:53:31] <_av500_> isnt it floating? [09:00:58] <thresh> suppose assert is wrong there [09:01:00] <thresh> yes [09:01:24] <thresh> and also I use hardcoded tables, so it fails to find expval_table_float in mpegaudio_tables.h [09:01:30] <thresh> how do I update those tables? [09:06:34] <thresh> aha i need to update mpegaudio_tablegen [10:02:55] <CIA-7> ffmpeg: michael * r23105 /trunk/libavcodec/ (tableprint.c tableprint.h): Support writing 2d float arrays, patch by Michael Kostyle [10:03:24] <thresh> grr [10:03:37] <CIA-7> ffmpeg: michael * r23106 /trunk/libavcodec/mpegaudio_tablegen.c: Fix mpegaudio tablegen patch by Michael Kostyle [10:03:51] <thresh> grrr #2 [10:04:02] <thresh> i've just sent two mails like that :( [10:05:19] <CIA-7> ffmpeg: michael * r23107 /trunk/libavcodec/mpegaudiodec.c: Fix compilation with low precission mpeg audio decoding. [10:06:49] <janneg> thresh: read cvslog, patch was pending since yesterday [10:07:39] <thresh> yeah, seems like i missed it [10:07:41] <janneg> sorry that I didn't noticed this before [10:08:05] <thresh> n/p [10:29:53] <lu_zero_> hi [10:31:40] <lu_zero> hi [11:04:56] <_av500_> lo [11:17:02] <mru> Dark_Shikari: did you fix your linking problem? [11:18:32] <thresh> mru: if i need to conditionally check for a library and link libavdevice with it, what do I check for in configure? [11:18:59] <mru> what lib? [11:19:11] <thresh> you probably wouldnt answer me if you know ;-) [11:19:13] <thresh> libv4l2. [11:19:24] <mru> I'd rather we didn't touch that [11:19:37] <mru> it doesn't do anything we couldn't easily do [11:19:42] <mru> and it does it worse [11:19:43] <thresh> well, I don't want to add hacks to my package [11:20:02] <thresh> and I'm not really a guru in conversions, so I wouldnt even try to write one needed for my camera [11:20:15] <mru> what format does it output? [11:23:48] <thresh> let me check [11:23:55] <thresh> one of my users also have a problem like that [11:25:57] <thresh> i've got a similar camera to the one mentioned in https://roundup.ffmpeg.org/issue1816 [11:27:06] <mru> tl;dr [11:27:23] <mru> actually, I've read most of that thread [11:27:32] <mru> so which colour format is missing? [11:29:55] <thresh> let me ping the guy, I don't have needed kernel headers here [11:33:02] <CIA-7> ffmpeg: mru * r23108 /trunk/tests/fate.mak: FATE: change -vfilters to -vf [11:38:22] <thresh> mru: V4L2_PIX_FMT_SPCA561 [11:38:24] <thresh> for instance.. [11:38:33] <mru> doesn't mean much to me [11:38:37] <mru> what does it look like? [11:39:51] <DonDiego> everybody please help clean up incoming - it's full.. [11:40:12] <thresh> mru: it is some weird format that needs decompressing, says libv4l2 source. [11:40:32] <mru> libv4l is smoking crack [11:40:53] <mru> if it's a compressed format, we should write a decoder for it [11:41:18] <thresh> oh, here's even the relevant issue for S561, https://roundup.ffmpeg.org/issue1837 [11:42:19] <thresh> anyone's up for that? seems no. I'd rather had the working solution (even if it is a hack from your POV) [11:42:40] <mru> well, I don't have a camera [11:42:52] <mru> is it possible to dump a few raw frames from one? [11:46:21] <thresh> not at the moment, the guy's camera is at home [11:48:17] <thresh> so, regarding my question, where should I go? [11:51:22] <mru> home [11:52:10] <mru> if you can get a description of the format and some samples, implementing it properly shouldn't be hard [11:55:37] <thresh> what really matters is this is just the only one cam out of dozens with various formats [11:56:05] <mru> then we have more formats to implement [11:56:10] <mru> read the damn discussion you pointed at [11:56:48] <thresh> I already see a whole null of people who tried implementing (or asked about it) there [11:57:23] <mru> that just means that nobody so far cared enough about it [12:11:27] <mru> yay, firefox using 3.3GB ram [12:20:36] <spaam> Nice [12:26:47] <thresh> anyway, http://whoknowsmy.name/stuff/0001-libavdevice-v4l2-use-libv4l2-when-request… [12:26:52] <thresh> not sure about configure part though [12:29:08] <mru> I'm telling you, it's not going to happen [12:30:06] <thresh> i dont care really if it's in main ffmpeg tree [12:31:08] <mru> that hostname doesn't resolve [12:31:47] <CIA-7> ffmpeg: vitor * r23109 /trunk/tests/ (lavf-regression.sh lavfi-regression.sh): Replace "-vfilters" by "-vf" in regtests. Should fix regtest breakage. [12:32:04] <iive> maybe you should replace the host part with his name? [12:32:52] <thresh> fucking xname [12:34:24] <iive> e.g. i haven't heard of 1'st level domain ".name" [12:34:32] <mru> it exists [12:41:22] <Compn> saudia arabia's tld is strange [12:41:31] <Compn> the entire country name is the tld [12:41:47] <Compn> imagine typing www.ffmpeg.organization :P [12:42:00] <twnqx> .sa is strange? [12:42:41] <Compn> http://en.wikipedia.org/wiki/Internationalized_country_code_TLD [12:43:17] <thresh> yeah, .рф is also there, stupid stuff [12:43:35] <Compn> Although the word code is used, some of these ccTLDs are not really codes but full words. For example ???????? (as-sa'owdiya) is not an abbreviation of Saudi Arabia, but the full name of the country in Arabic. [12:43:44] <mru> http://www.iana.org/domains/root/db/ [12:44:16] <Compn> still waiting for .moon ... [12:44:28] <Compn> and .xxx [12:47:59] <Compn> bbl [12:51:31] <thresh> should be working now, seems like xname had troubles [13:05:49] <BastyCDGS> hi [13:09:16] <BastyCDGS> hi BBB :) [13:09:20] <BBB> hola [13:09:33] <BastyCDGS> how are u? [13:09:40] <BBB> sleepy [13:09:43] <BBB> need coffee :) [13:09:57] * BastyCDGS teleports a cup of coffee to BBB [13:10:03] <BastyCDGS> *BING* [13:13:52] <BastyCDGS> BBB, I wonder if there are problems with my patches pending for review [13:14:08] <BBB> no idea, I've been busy at work for two days [13:14:10] <BBB> so I didn't check [13:14:26] <BBB> I told you the patch with extradata_size > 0 to remove the "> 0", which you haven't done yet [13:14:31] <BBB> the other patches I haven't looked at yet [13:15:35] <BastyCDGS> BBB, should I write now count > 0 or just count? [13:16:14] <BBB> just count [13:16:21] <BBB> the shorter the code, the better [13:16:37] <BastyCDGS> ok will submit now [13:17:23] <BBB> I'll commit the decodeplane8() one -> do{..}while(..); [13:19:17] <CIA-7> ffmpeg: rbultje * r23110 /trunk/libavcodec/iff.c: [13:19:17] <CIA-7> ffmpeg: Move a while(..){..} -> do{..}while(..), slightly faster. [13:19:17] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>. [13:20:22] <BBB> ok that's in [13:20:24] <BBB> anything else? [13:20:39] <BBB> spyfeng: sorry I haven't been available too much, but good work, I think Michael is almost ok with your patch [13:20:49] <BBB> spyfeng: have you looked at mms-http already? [13:20:58] <BastyCDGS> the lavf/lavc palette splitting stuff [13:22:14] <BBB> uhm... let me see [13:22:36] <BBB> oh right I meant to ask why we would want to change CODEC_ID_RAW to CODEC_ID_IFF... [13:22:42] <BBB> could you test whether it's slower/faster? [13:22:48] <BBB> for that one image that you hae [13:22:51] <BBB> *have [13:28:16] <BastyCDGS> yes I will, I have to change this patch anyway after you applied the grayscale patch [13:33:31] <BastyCDGS> avpicture_fill(picture, buf, avctx->pix_fmt, avctx->width, avctx->height); [13:33:48] <BastyCDGS> this is what rawdec.c does [13:33:57] <BastyCDGS> so maybe I should use this, too? [13:34:37] <thresh> here's another link to patch I mentioned earlier, http://git.altlinux.org/people/thresh/packages/ffmpeg.git?p=ffmpeg.git;a=co… [13:37:58] <BBB> BastyCDGS: that's quite literally a memcpy [13:38:05] <BBB> BastyCDGS: just compare performance if you can [13:38:32] <BastyCDGS> well my patch does just a memcpy but one for each line instead of copying them all [13:38:39] <BBB> thresh: I'm sorry but I'm a little against that patch [13:38:45] <BastyCDGS> the thing is when masking support is added the code has to care of that [13:38:57] <BastyCDGS> as well as HAM [13:39:04] <thresh> BBB: as i've mentioned earlier, I don't care if it goes into main ffmpeg [13:39:23] <BBB> ok so this PBM can have masking or HAM? [13:39:40] <BBB> I didn't know that... [13:39:44] <BBB> I guess it's ok then [13:40:26] <BastyCDGS> yes it's the same as IFF-ILBM just that the pixels are saved in chunky format instead of planar format [13:40:35] <BBB> ok [13:40:45] <BastyCDGS> but I'll try with avpicture_fill(picture, buf, avctx->pix_fmt, avctx->width, avctx->height); right now [13:40:57] <BastyCDGS> since at moment it doesn't not make any sense for the line based loop [13:43:15] <BBB> right [13:43:21] <BBB> I just replied one more comment in the thread [13:43:27] <BBB> if you change the patch, I'll apply it [13:43:29] <BBB> looks good [13:55:57] <BastyCDGS> when I try it with one memcpy the lines don't align any more, i.e. the image totally looks distorted [13:57:00] <BastyCDGS> the two buffers have different width alignment [14:09:52] <BBB> hmm.... [14:10:00] <BastyCDGS> BBB, updated patch submitted [14:10:06] <BBB> BastyCDGS: ok, try avpicture_fill then [14:10:10] <BBB> did that work? [14:10:17] <BBB> or did you need the line-based approach? [14:10:28] <BastyCDGS> yes line-based approach is needed [14:10:47] <BBB> can avpicture_fill do that? [14:10:57] <BBB> hm, probably not [14:10:59] <BBB> hold on [14:11:29] <BBB> ok, got it [14:17:17] <BBB> can you also supply a patch to rename and privatize ff_cmap_..()? [14:17:23] <BBB> (for applying after this patch) [14:17:31] <BastyCDGS> I just tested it the old still does fine [14:18:24] <BastyCDGS> since it just touchs iff.h which the other doesn't and the lavc patch to iff.c is in complete different functions [14:18:32] <BBB> ah ok [14:18:34] <BBB> good [14:33:40] <BBB> BastyCDGS: so if there's extradata, it's a palette right? [14:33:43] <BBB> and else i's grayscale [14:33:52] <BastyCDGS> exactly [14:33:55] <BBB> avctx->pix_fmt = avctx->extradata_size ? PIX_FMT_GRAY8 : PIX_FMT_PAL8; [14:33:58] <BBB> isn't that wrong? [14:34:06] <BastyCDGS> no it isn't [14:34:42] <BastyCDGS> I decided not to use extradata at all for the HAM stuff the problem is that in IFF-ANIM compression etc. can change, masking and therefore such data has to be in AVPacket->data anyway [14:35:04] <BBB> ok [14:35:09] <BBB> but then the palette is in extradata [14:35:13] <BastyCDGS> so the if (count) won't harm anymore, too...it in fact can't happen anymore that count < 0 [14:35:25] <BastyCDGS> yes just only the palette it will stay that way [14:35:32] <BastyCDGS> or nothing if no CMAP chunk found [14:35:33] <BBB> so if extradata_size != 0 (which is the same as if exradaat_size), then we're a palette [14:35:37] <BBB> but you're setting it to gray8 [14:35:41] <BBB> and to pal8 otherwise [14:35:44] <BBB> it's the wrong way around [14:36:03] <BastyCDGS> the original demuxer just has extradata_size == 0 if no CMAP chunk found [14:36:18] <BastyCDGS> and only then the palette should be set to GRAY8 [14:36:30] <BastyCDGS> oh I see [14:36:37] * BBB waits [14:36:39] <BBB> ... [14:36:40] <BBB> ... [14:36:41] <BBB> ... [14:36:52] <BBB> + if ((avctx->pix_fmt == PIX_FMT_PAL8) || (avctx->pix_fmt == PIX_FMT_GRAY8)) { - also many brackets here, some can be removed [14:41:59] <BastyCDGS> submitted new patch to ML for HAM [14:43:50] <BastyCDGS> HAM? sorry [14:44:01] <BastyCDGS> grayscale [15:04:05] <BBB> ok, so this is settled now [15:04:12] <BBB> what reads gray_pal8[]? [15:04:24] <BBB> what worries me is that the palette becomes 1-byte instead of 4-bytes [15:04:29] <BBB> is all code changed to take that into account? [15:04:50] <BastyCDGS> exactly this: [15:04:51] <BastyCDGS> uint8_t *gray_pal = (uint8_t *) pal; [15:05:02] <BastyCDGS> pal is uint32_t [15:05:12] <BastyCDGS> (the function gets it as uint32_t [15:05:24] <BastyCDGS> but actually palette is 1-byte then [15:05:33] <BastyCDGS> so I'm writing it 1-byte instead of 4 [15:05:51] <BBB> is it used? [15:06:02] <BBB> I don't think GRAY8 expects a palette [15:06:03] <BBB> does it? [15:08:38] <BastyCDGS> I try this out [15:11:12] <BastyCDGS> you were right! [15:11:27] <BastyCDGS> palette data for GRAY8 is unnecessary :) [15:12:54] <BBB> maybe you want to use if(extradata_size) instead of if(count) then [15:13:17] <BBB> I wonder what the specs expect you to do if exradata_size is 1 or 2 [15:13:26] <BBB> (so not a full palette entry, where count=0, but cmap is clearly there) [15:13:33] <BBB> does it want b/w or does it want you to go all-black? [15:13:54] <BastyCDGS> I have removed the if (count) completely [15:14:55] <BastyCDGS> it does not say about any extradata not-divisable by 3 [15:15:37] <BastyCDGS> anyway for 1 or 2: [15:15:39] <BastyCDGS> count = FFMIN(avctx->extradata_size / 3, count); [15:15:51] <BastyCDGS> this is integer division rounding to zero [15:16:02] <BastyCDGS> i.e. it will skip uncompleted palette data [15:16:34] <BastyCDGS> remember to apply the palette underflow removal patch first [15:16:47] <BBB> at the bottom of decode_init [15:16:49] <BBB> add this: [15:16:51] <BBB> avctx->bits_per_coded_sample <= 8 [15:16:53] <BBB> make that [15:17:00] <BBB> avctx->bits_per_coded_sample <= 8 && avctx->extradata_size [15:17:07] <BBB> that way it only reads the palette for PAL8 [15:17:09] <BBB> not for GRAY8 [15:17:11] <BBB> and you're safe [15:19:22] <BastyCDGS> it has to call this function for HAM stuff later [15:19:31] <BastyCDGS> since it must initialize the palette if HAM or EHB [15:20:03] <BastyCDGS> for HAM we have to create a custom grayscale palette [15:20:22] <BBB> right [15:20:26] <BBB> but HAM doesn't output GRAY8 [15:20:31] <BBB> HAM outputs RGB32 or PAL8 [15:20:51] <BBB> so you can use that and change it to bps<=8&&pix_fmt!=GRAY8 then [15:21:01] <BBB> which accomplishes the same thing [15:22:03] <BastyCDGS> you mean I should initialize HAM grayscale palette data outside cmap_read_palette? [15:22:11] <BBB> no you can it inside [15:22:19] <BBB> but PIX_FMT != GRAY8 then [15:24:33] <BastyCDGS> the thing is that leaving the pix_fmt!=GRAY8 away is the same... [15:24:43] <BastyCDGS> because of FFMIN it is 0 then and the palette init isn't called at all [15:25:04] <BastyCDGS> it's just extra code for exactly the same result [15:25:49] <BBB> I don't want it to call the function [15:26:30] <BBB> (if it doesn't have to) [15:26:48] <BBB> because then we can enhance the function for the palette case, without having to worry that we might accidently break GRAY8 support [15:27:07] * BBB goes look for palette underflow patch [15:27:17] <BastyCDGS> can I change that in an extra patch [15:27:40] <BastyCDGS> because adding this right now makes it dependant on the ff_ removal patch of cmap_read_palette [15:28:36] <BBB> I can't find the palette underflow patch [15:28:41] <BBB> well... [15:28:47] <BBB> let's just say I'll apply this one right away if it's fine [15:28:56] <BBB> so I'd place this patch before the ff_cmap_ rename one [15:29:10] <BBB> the problem with that one is that it removes a function from our ABI [15:29:13] <BBB> want to make sure that's ok [15:29:30] <BastyCDGS> [PATCH] IFF: Handle palette underflows... [15:29:33] <DonDiego> did i just miss the discussion of the mp* float decoder or did michael really commit it out of the blue? [15:29:42] <BBB> he committed it out of the blue [15:29:43] <mru> yes, he did [15:29:47] <BastyCDGS> 9th may, 21:27 UTC [15:29:49] <mru> and botched it as usual [15:29:55] <DonDiego> :) [15:30:26] <mru> as in badly designed interface and numerous fate breakages [15:30:53] <DonDiego> hmm [15:30:59] <DonDiego> any speed tests? [15:31:14] <mru> soon [15:31:22] <mru> and it ain't pretty [15:31:33] <BBB> that bad? [15:31:35] <BBB> hm :( [15:31:41] <DonDiego> i'm looking through the diff right now, macros... [15:31:46] <DonDiego> is it slow? [15:31:47] <janneg> without hardware fp? [15:31:54] <mru> 4x slower on cortex-a8 [15:32:01] <mru> + audioconvert slowness [15:32:03] <DonDiego> x86? [15:32:11] <mru> I'm sure someone else will test that [15:32:14] <DonDiego> slower than what? [15:32:19] <mru> integer [15:32:21] <BBB> sorry that audioconvert is slow [15:32:35] <BBB> but please see that as a separate issue for now [15:32:38] <mru> it is [15:32:45] <mru> it's 4x slower *before* audioconvert [15:32:59] <mru> it's so slow audioconvert doesn't even look bad [15:34:02] <BBB> BastyCDGS: done [15:34:03] <BBB> BastyCDGS: next? [15:34:20] <BBB> I think I can start by removing the demuxer call to ff_cmap_read [15:34:29] <CIA-7> ffmpeg: rbultje * r23111 /trunk/libavcodec/iff.c: [15:34:29] <CIA-7> ffmpeg: Handle palette underflows, fill remaining space with black (zero) data. [15:34:29] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>. [15:34:49] <BBB> then after that let's get grayscale support in [15:34:51] <BBB> then ham [15:35:12] <BastyCDGS> ignore the HAM patch for now there has to change something [15:35:17] <BBB> ok [15:35:24] <BastyCDGS> grayscale now [15:36:12] <BastyCDGS> ok do the demuxer call now [15:37:29] <BBB> can't, it depends on the grayscale one I think [15:38:00] <BBB> let me see [15:38:43] <BBB> hm no, I'm wrong [15:38:43] <BBB> ok [15:38:45] <BastyCDGS> iff-palette-remove-avf.patch is ok [15:38:49] <BastyCDGS> to apply before grayscale [15:39:55] <BastyCDGS> and indent patch of course for it [15:40:36] <CIA-7> ffmpeg: rbultje * r23112 /trunk/ (libavcodec/iff.c libavformat/iff.c): [15:40:36] <CIA-7> ffmpeg: Move handling of paletted data to the IFF demuxer. This allows future [15:40:36] <CIA-7> ffmpeg: handling of things such as masking/EHB/HAM for this type of data. [15:40:36] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>. [15:42:17] <BBB> done [15:42:24] <BBB> now re-do the grayscale one [15:42:31] <BBB> then let's talk about the ham work [15:42:40] <BastyCDGS> yeah [15:42:40] <CIA-7> ffmpeg: rbultje * r23113 /trunk/ (libavcodec/iff.c libavformat/iff.c): [15:42:40] <CIA-7> ffmpeg: Reindent after r23112. [15:42:40] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>. [15:43:44] <BBB> good work :) [15:43:48] <BBB> brb [15:46:19] <BastyCDGS> I will do a build clean from latest git and test if everything still works until now safe is safe ;) [15:58:56] <BastyCDGS> BBB, is that layout ok? [15:58:57] <BastyCDGS> if ( (avctx->bits_per_coded_sample <= 8) && [15:58:57] <BastyCDGS> (avctx->pix_fmt != PIX_FMT_GRAY8) ) [15:58:57] <BastyCDGS> err = ff_cmap_read_palette(avctx, (uint32_t*)s->frame.data[1]); [16:00:25] <BastyCDGS> I added the parenthesis so the err = line is indented different than the statement belonging to if line [16:00:47] <BBB> too many brackets again :) [16:01:04] <BBB> but otherwise it's ok yes [16:01:38] <BastyCDGS> so I just remove the brackets around the &&'s and it's fine? [16:02:46] <BBB> basically ((..) && (..)) -> (.. && ..) [16:02:51] <BBB> and yes [16:03:02] <BBB> can you also look if av_picture_copy is useful as michael suggested? [16:03:05] <BBB> if not it's ok [16:03:20] <BBB> (i.e. you don't have to do anything, just reply saying "doesn't work because ...") [16:17:11] <BastyCDGS> BBB, uhm I just figured out that when I do not initialize the grayscale palette it's way too dark for some images [16:18:43] <BastyCDGS> one question does PAL_FMT_GRAY8 use the same graying method than (col_index * 255) >> bits_per_coded_sample? [16:19:27] <BastyCDGS> col_index is the image pixel value at x,y [16:22:51] <BastyCDGS> yes these two methods aren't compatible [16:22:56] <BastyCDGS> so we can't use PIX_FMT_GRAY8 [16:23:12] <BastyCDGS> we just have to initialize the custom grayscale palette to display the images according to IFF specs [16:24:06] <BBB> I think it depends on bits_per_coded_image [16:24:16] <BBB> GRAY8 assumes bps=8 [16:24:27] <BBB> if bps!=8, you can't use GRAY8 [16:24:32] <BBB> you have to use something else [16:25:04] <BastyCDGS> oh so I should just set to GRAY8 when bps == 8 [16:26:11] <KotH> moin boys [16:26:23] <mru> what about the girls? [16:26:41] <KotH> DonDiego: we're currently working on the 0.6 release notes, do you want to giv e any input? [16:26:50] <KotH> mru: rounding error [16:27:49] <CIA-7> ffmpeg: siretart * r23114 /branches/0.6/Changelog: update version string in changelog [16:28:06] <janneg> mru: only probetest needs HAVE_AV_CONFIG_H [16:28:56] <mru> are you sure? [16:29:26] <mru> hmm, someone must have fixed trasher [16:31:48] <CIA-7> ffmpeg: michael * r23115 /trunk/libavutil/ (internal.h attributes.h): [16:31:48] <CIA-7> ffmpeg: av_alias is an attribute and belongs to attributes.h [16:31:48] <CIA-7> ffmpeg: also attributes.h is public and external api and can thus not depend [16:31:48] <CIA-7> ffmpeg: on configure tested compiler support thus this part is removed. A [16:31:48] <CIA-7> ffmpeg: different solution must be found if this breaks for some compiler [16:31:48] <CIA-7> ffmpeg: which i hope it does not. [16:33:09] <CIA-7> ffmpeg: michael * r23116 /trunk/libavcodec/mathops.h: [16:33:09] <CIA-7> ffmpeg: Use standard C for implementing sign_extend() and zero_extend(). [16:33:09] <CIA-7> ffmpeg: This fixes compilation of probetest [16:34:56] <janneg> mru: yes, make alltools worked after fixing probetest but micheal fixed it [16:35:10] <mru> and broke other things in the process [16:38:06] <Dark_Shikari> mru: we had some weird cases with gcc using more complex instruction sequences to access extern arrays as opposed to static arrays... [16:38:09] <Dark_Shikari> ... with pic off [16:38:11] <CIA-7> ffmpeg: siretart * r23117 /branches/0.6/RELEASE: first draft of the release notes [16:38:26] <mru> Dark_Shikari: pic or no pic doesn't matter there [16:38:44] <Dark_Shikari> yes it does, because global arrays have to go through a layer of indirection [16:38:44] <siretart> DonDiego: KotH: ^^ [16:38:48] <Dark_Shikari> because it has to support dynamic reloading [16:38:54] <Dark_Shikari> hence visibility attributes [16:39:12] <mru> exactly, pic or not doesn't matter [16:39:21] <Dark_Shikari> but that's only in PIC, right? [16:39:24] <mru> no [16:39:34] <Dark_Shikari> Ah [16:39:38] <mru> pic is entirely orthogonal to symbol resolution [16:39:38] <Dark_Shikari> but then that's even weirder [16:39:53] <Dark_Shikari> because what I'm talking about only occurred in some .c files [16:39:58] <Dark_Shikari> sone .c files optimized correctly [16:40:00] <Dark_Shikari> others didn't [16:40:17] <mru> what was the difference? [16:40:23] <mru> did it do a GOT indirection? [16:40:40] <Dark_Shikari> http://pastebin.org/228417 [16:40:52] <Dark_Shikari> No indirection. [16:40:58] <Dark_Shikari> which makes it weirder. [16:41:20] <mru> %ebx holds the address of the array? [16:41:23] <BastyCDGS> BBB, I just test and if it's ok I'll submit the grayscale patch to ML [16:41:42] <Dark_Shikari> this is to do two loads from an array [16:41:52] <Dark_Shikari> ebx holds the index into the array [16:42:05] <mru> wtf? [16:42:09] <mru> what's the base address? [16:43:00] <mru> 32-bit immediate address? [16:43:14] <mru> and a textrel? [16:43:32] <Dark_Shikari> I think that particular example is obviously from x86_32 [16:43:34] <Dark_Shikari> with pic off [16:43:44] <Dark_Shikari> also, gcc 4.4 [16:43:57] <Dark_Shikari> Oh, and we found that prior to gcc 4.5, gcc was unable to optimize out constant accesses to static local arrays [16:44:03] <Dark_Shikari> *constant static [16:44:23] <mru> not surprising [16:44:51] <Dark_Shikari> also, more weirdness [16:44:52] <Dark_Shikari> see this patch [16:44:53] <Dark_Shikari> http://pastebin.org/pastebin.php?dl=228768 [16:44:59] <Dark_Shikari> important part is line 62-64 [16:45:14] <Dark_Shikari> This made the .so smaller, but made the executable file bigger [16:45:31] <Dark_Shikari> it makes no sense [16:45:52] <mru> check the sizes of different sections [16:46:03] <Dark_Shikari> I did [16:46:07] <mru> it could have make .text smaller and something else bigger [16:46:14] <mru> perhaps with padding somewhere [16:46:34] <mru> I've seen gnu tools create elf files hundreds of kilobytes larger than necessary [16:46:41] <Dark_Shikari> 14:20 < Dark_Shikari> hmm in patched, .text is 762152 and rodata is 57356 [16:46:41] <Dark_Shikari> 14:20 < Dark_Shikari> unptached, .text is 761896 and rodata is 57356 [16:46:51] <mru> what about .rel.* [16:46:59] <Dark_Shikari> how do those work? [16:47:05] <mru> those are the relocations [16:47:06] <Dark_Shikari> and which ones do you want? [16:47:10] <mru> did they change? [16:47:23] <Dark_Shikari> rela.dyn: 1080, rela.plt: 1800, data.rel: 2248 (unpatched) [16:47:31] <mru> but if .text got larger, that's weird [16:47:47] <Dark_Shikari> rela.dyn: 384, rela.plt: 1728, data.rel.ro: 2248 (patched) [16:47:56] <Dark_Shikari> so we saved 600 bytes on rela.dyn, but text got larger [16:48:42] <DonDiego> KotH: where are the release notes? [16:51:18] <mru> anyway, about that addressing [16:51:51] <Dark_Shikari> also, I'm looking for a tool that would allow me to measure the size of a program's working set [16:52:07] <Dark_Shikari> where "working set" means "how many unique cachelines it reads and writes to during a particular period of time" [16:52:07] <mru> can you show the machine code for those instructions? [16:52:23] <mru> tried cachegrind? [16:52:27] <Dark_Shikari> it doesn't really do that [16:52:34] <Dark_Shikari> I want to e.g. see how many cachelines x264 needs to encode one macroblock [16:52:45] <Dark_Shikari> it counts the number of refs, not the number of unique refs [16:53:15] <mru> patch it [16:53:19] <Dark_Shikari> lol [16:53:24] <Dark_Shikari> wonder how hard that would be... [16:53:32] <ohsix> you could do that with perf [16:53:40] <mru> it's a simulated cache model so it shouldn't be terribly hard [16:53:45] <Dark_Shikari> perf? [16:53:51] <mru> perf events don't tell you that [16:54:10] <mru> they can count number of memory accesses and number of hits/misses [16:54:34] <Dark_Shikari> I could do it if it tracked where memory accessed occurred [16:54:38] <Dark_Shikari> and gave me a list [16:54:41] <ohsix> they can do any event counter, like oprofile can; but it works differently [16:54:54] <mru> yes, but I've never heard of such a counter [16:55:11] <Dark_Shikari> you'd think cachegrind could dump memory accesses [16:55:26] <mru> you could probably patch it to do that [16:55:34] <Dark_Shikari> Yeah, probably [16:55:37] <Dark_Shikari> That sounds much easier [16:57:36] <mru> Dark_Shikari: but can you post the machine code for that array access? [16:57:51] <Dark_Shikari> I already did [16:57:56] <mru> no [16:57:58] <mru> you posted disasm [16:58:03] <mru> I want the raw insns [16:58:11] <Dark_Shikari> oh... I'd have to harass Gramner for that [16:58:15] <Dark_Shikari> and it went away in gcc 4.5, so... [16:58:18] <Dark_Shikari> oh wait, that wasn't what went away [16:58:22] <Dark_Shikari> the constant propagation issue went away [16:58:26] <Dark_Shikari> hmm, I'd have to ask him [16:58:30] <Dark_Shikari> I had issues replicating it on my system. [16:58:39] <mru> just the full objdump output for those lines [16:58:47] <Dark_Shikari> ok, asked [16:58:51] <mru> and the output of readelf -r on those files too [16:59:01] <Dark_Shikari> wait but that was objdump output [16:59:08] <mru> objdump -d [16:59:15] <mru> _including_ raw instruction bytes [16:59:18] <Dark_Shikari> ahhhh k [16:59:26] <mru> address: hex mnemonic [16:59:51] <mru> readelf -r prints the relocation table [17:16:51] <BastyCDGS> BBB, new grayscale patch submitted to ML [17:22:09] <BastyCDGS> oops posted it into the wrong thread, sorry [17:27:10] <mru> BastyCDGS: you don't need to tell us here about every mail you send to the ml [17:27:16] <kierank> lol [17:27:24] <Dark_Shikari> yay, now we're getting the x264 commercial license written [17:27:30] <BastyCDGS> lol ok you're right [17:27:35] <Dark_Shikari> this is particularly fun, it's like writing a commercial license without all the evil parts [17:28:01] <Dark_Shikari> well, fun until we see the bill, but hey... [17:31:53] <Gramner> mru: http://files.gramner.com/x264/ [17:32:36] <BBB> BastyCDGS: don't forget AVPicture == AVFrame [17:32:42] <BBB> decode_video() should have an AVFrame somewhere [17:32:50] <BBB> you can cast between the two where required [17:33:46] <BastyCDGS> ahh didn't know this thank [17:34:34] <BastyCDGS> but anyway as said I need it this way for masking support [17:39:39] <BastyCDGS> also only src parameter is AVPicture, the second one is raw data uint_8 * so I would have to add an extra structure anyway. [17:41:53] <BBB> memcpy() also takes a uint8_t* [17:42:14] <BBB> so instead of copying from buf to avpicture->data[0], you copy from buf to avpicture (period) [17:42:20] <BBB> right? [17:44:18] <BastyCDGS> yes [17:44:36] <BastyCDGS> but they're exactly in the correct order with memcpy ;) [17:46:01] <BastyCDGS> anyway, I will have to add some per line code when masking support will be added [17:53:20] <BBB> so masking is per-line? [17:53:27] <BBB> I mean, that might be a good reason to keep the code as-is [17:53:28] <mru> Gramner: where are the bad instructions? [17:53:31] <BBB> but then you need to reply that ;) [17:53:38] <BastyCDGS> yes per line [17:53:54] <BastyCDGS> that's why I'm saying it [17:53:54] <Gramner> in the middle of that function [17:55:43] <Gramner> starts at around line 250 i think [17:56:19] <mru> Gramner: which address is that? firefox doesn't number the lines [17:56:34] <Gramner> 7274 [17:58:17] <mru> can you please just say exactly which addresses are the interesting ones? [17:58:25] <mru> you apparently figured it out once already [17:59:12] <CIA-7> ffmpeg: michael * r23118 /trunk/libavcodec/mpegaudiodec.c: [17:59:12] <CIA-7> ffmpeg: Cast constants to float to avoid gcc converting to and from [17:59:12] <CIA-7> ffmpeg: float<->double in every operation. [17:59:57] <Gramner> 732e in static / 7346 in extern for example [18:07:31] <CIA-7> ffmpeg: michael * r23119 /trunk/libavcodec/mpegaudiodec.c: [18:07:31] <CIA-7> ffmpeg: 1.0 and the resulting exactly representable value must be marked as float as well, [18:07:31] <CIA-7> ffmpeg: gcc is hopelessly trash. [18:07:43] <Dark_Shikari> lol [18:08:17] <mru> adding -fsingle-precision-constant breaks lots of tests btw [18:08:34] <BastyCDGS> and there's still missing: [18:08:34] <BastyCDGS> # define FIXR_OLD(a) ((int)((a) * FRAC_ONE + 0.5)) [18:08:36] <BastyCDGS> => [18:08:37] <BastyCDGS> # define FIXR_OLD(a) ((int)((a) * FRAC_ONE + 0.5f)) [18:10:15] <Dark_Shikari> btw, all these problems still occur with -ffast-math right? [18:11:05] <mru> there is definitely code that isn't safe with that flag [18:11:16] <mru> anything that might generate a NaN is unsafe [18:12:33] <CIA-7> libswscale: ramiro * r31170 /trunk/libswscale/ (15 files in 6 dirs): (log message trimmed) [18:12:33] <CIA-7> libswscale: Revert r31153. It failed to build on: [18:12:33] <CIA-7> libswscale: x86_64 / Mac OS X gcc 4.0.1 [18:12:33] <CIA-7> libswscale: x86_64 / Linux icc (all) [18:12:33] <CIA-7> libswscale: x86_64 / Linux gcc 4.0.4 [18:12:34] <CIA-7> libswscale: x86_64 / OpenBSD gcc 3.3.5 [18:12:34] <CIA-7> libswscale: x86_64 / Linux suncc 5.10 [18:13:42] <mru> Gramner: in the static one, what is the address of the array being indexed? [18:14:20] <Dark_Shikari> hmm, I can't replicate michael's issue here [18:14:53] <Dark_Shikari> I'm not getting redundant double->float casts [18:15:25] <mru> anyway, if you look at the extern case, you'll see that the mov X, %esi has a textrel for x264_scan8_lut [18:16:00] <mru> the static one doesn't have a relocation at all there [18:16:04] <Dark_Shikari> why is that? [18:16:18] <mru> isn't that the array you're indexing? [18:16:35] <Dark_Shikari> why would the static one not have a relocation? it's still rodata [18:16:44] <BBB> I saw his problem [18:16:47] <BBB> might be gcc-specific [18:16:47] <mru> where does the value in %ebx come from? [18:16:55] <BBB> better to help gcc if there's any chance it might screw up [18:16:58] <BBB> if it can, it will [18:17:00] <BBB> apparently [18:18:29] * BBB notices that he's starting to bash gcc randomly [18:18:31] <BBB> <- bad [18:18:37] <mru> no, that's good [18:18:41] <mru> you're finally learning [18:19:44] <BBB> maybe it's because I'm finally learning how a compiler can do right and wrong [18:19:59] <BBB> previously all I knew was that this compiler compiled this magic language C into machine code that looked rather creepy [18:20:19] <janneg> gcc 4.5 needs probably -fexcess-precision=fast [18:20:48] <janneg> -std=c99 activates -fexcess-precision=standard [18:20:48] <mru> the 4.5 release notes had some warning about float being slower by default [18:20:55] <Dark_Shikari> ahhhhh [18:20:58] <Dark_Shikari> that might be it [18:21:05] <Dark_Shikari> actually that's something we should do in x264 [18:21:08] <Dark_Shikari> we just threw in std=c99 [18:21:12] <Dark_Shikari> ... then again, we use -ffast-math [18:21:13] * mru wouldn't touch 4.5 with a 10-foot pole just yet [18:21:19] <Dark_Shikari> does ffast-math imply excess-precision=fast? [18:21:25] <mru> rtfm [18:22:17] <janneg> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html [18:22:20] <mru> Gramner, Dark_Shikari: where does %ebx get set for those loads? [18:22:40] <Dark_Shikari> I don't know, ask Gramner [18:23:06] <Gramner> to be honest i'm not very knowledgeable about this sort of stuff, i only noticed that extra ops got inserted in some places for some reason [18:23:36] <mru> well, here's my theory [18:23:53] <mru> if the array is static, gcc knows its offset from .rodata [18:24:40] <mru> so if it already knows some address in .rodata it can just use that and tweak the offsets [18:24:58] <mru> if the array is extern, it has to fetch its address explicitly [18:25:11] <mru> since the final location is resolved at link-time [18:26:18] <Gramner> but why does that only happen in some files and not others? [18:26:55] <CIA-7> ffmpeg: stefano * r23120 /trunk/libavfilter/parseutils.c: Make av_parse_color() return AVERROR(EINVAL) rather than -1. [18:26:57] <CIA-7> ffmpeg: stefano * r23121 /trunk/libavfilter/vf_pad.c: [18:26:57] <CIA-7> ffmpeg: Make the init and config_filter callbacks of the pad filter return [18:26:57] <CIA-7> ffmpeg: AVERROR(EINVAL) rather than -1 in case of invalid parameters. [18:26:57] <CIA-7> ffmpeg: stefano * r23122 /trunk/libavfilter/vf_pad.c: [18:26:57] <CIA-7> ffmpeg: Remove the name of the file from the @file doxy, it is unnecessary and [18:26:57] <CIA-7> ffmpeg: inconsistent with the other files. [18:31:46] <bcoudurier> hi guys [18:31:50] <Dark_Shikari> hi bcoudurier's onjoin script [18:42:09] <CIA-7> ffmpeg: mru * r23123 /trunk/libavcodec/Makefile: Add mpegaudiodec_float.o dependency on tables header with hardcoded tables [18:51:11] <BastyCDGS> BBB, changing avctx->pix_fmt == PAL8 ? .. : .. will break it for HAM [18:51:18] <BastyCDGS> so the != GRAY8 check is better [19:01:17] <BBB> why? [19:01:32] <BBB> because ham uses rgb32 but does not a palette? [19:01:47] <BastyCDGS> yes but ham needs the palette data to decode [19:02:29] <BastyCDGS> I submitted fix vor inline function instead of macro though. [19:04:15] <BBB> got it [19:04:19] <BBB> ok, that part is fine then [19:04:22] <BBB> one other comments, see email [19:04:24] <BBB> then it's ok [19:12:27] <BastyCDGS> so fixed ;) [19:13:04] <wbs> bcoudurier: any objections to committing this one? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100502/cc11f… [19:14:20] <bcoudurier> nope, go ahead [19:14:32] <wbs> ok, good [19:14:33] <BastyCDGS> hi jai :) [19:14:59] <BBB> BastyCDGS: ok, this is good [19:15:03] <wbs> bcoudurier: this one, too? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100502/b6b29… [19:16:54] <CIA-7> ffmpeg: rbultje * r23124 /trunk/libavcodec/iff.c: Grayscale support. Patch by Sebastian Vater <cdgs basty googlemail com>. [19:18:09] <CIA-7> ffmpeg: mstorsjo * r23125 /trunk/tools/qt-faststart.c: qt-faststart: Use the error_out cleanup code path for all error returns [19:18:10] <CIA-7> ffmpeg: mstorsjo * r23126 /trunk/tools/qt-faststart.c: Cosmetics: reindent [19:18:47] <CIA-7> ffmpeg: mstorsjo * r23127 /trunk/tools/qt-faststart.c: Cosmetics: Initialize pointers with NULL instead of 0, for consistency [19:19:28] <CIA-7> ffmpeg: rbultje * r23128 /trunk/libavcodec/iff.c: Reindent after r23124. Patch by Sebastian Vater <cdgs basty googlemail com>. [19:19:36] <BBB> next [19:19:40] <BBB> where's the new ham patch? [19:20:44] <bcoudurier> wbs, well ok [19:22:39] <BastyCDGS> BBB, I think it's better to apply the make cmap_read_palette static and remove the public function [19:22:52] <wbs> bcoudurier: great, thanks [19:23:46] <CIA-7> ffmpeg: mstorsjo * r23129 /trunk/tools/qt-faststart.c: [19:23:47] <CIA-7> ffmpeg: qt-faststart: Abort scanning of the input file if a badly sized atom is encountered [19:23:47] <CIA-7> ffmpeg: If the atom size is 0, qt-faststart currently hangs forever while scanning [19:23:47] <CIA-7> ffmpeg: the file. [19:24:02] <BBB> BastyCDGS: can't, need to wait for distributor comments [19:24:05] <BBB> maybe reinhardt [19:24:20] <BBB> it's an ABI changen [19:24:24] <BBB> let that one be for now [19:24:30] <wbs> siretart: ping, on the "remove ff-prefixed function that lavf despite that uses currently" issue [19:25:01] <wbs> siretart: aka http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088457.html [19:27:36] <BastyCDGS> BBB, then let's discuss HAM now [19:29:20] <_av500_> yum [19:29:31] <BastyCDGS> hi saste :) [19:29:39] <mru> spanish or italian ham? [19:29:54] <spaam> spam! [19:30:04] <spaam> spam spam spam spam [19:30:17] <siretart> wbs: thanks for pinging me. I'm looking up the thread [19:31:38] <siretart> wbs: how likely is that function used outside of ffmpeg? e.g. does mplayer use it? [19:32:54] <BBB> BastyCDGS: submit latest patch please [19:32:56] <BBB> and we'll discuss [19:33:09] <BBB> siretart: ff_cmap()? [19:33:13] <BBB> only in libavf [19:33:18] <BBB> mplayer can't use it [19:33:22] <BBB> if it does, it's broken [19:36:24] <siretart> in that case I think it's safe to just drop it [19:38:05] <BastyCDGS> BBB, just submitted [19:39:01] <wbs> siretart: btw, in the preliminary 0.6 releasenotes, did you miss rtp depacketization of amr (which usually goes hand in hand with h263)? and the packetization of both formats from sometimes last year seems to be missing, too? [19:39:55] <siretart> wbs: probably. I take your comment that you feel that's noteworthy? in that case, please just add them, ok? [19:40:33] <wbs> siretart: ok, will do [19:41:44] <siretart> tahnks! [19:42:37] <wbs> done [19:43:26] <CIA-7> ffmpeg: mstorsjo * r23130 /branches/0.6/RELEASE: Mention that both packetizers and depacketizers of H.263 and AMR were added [19:43:27] <wbs> the combination rtsp + rtp/h263/amr gives the highlevel "decode mobile youtube videos" feature :-) [19:49:59] <BastyCDGS> well I think before actually doing the HAM stuff, we should discuss now how to do pass HAM, masking, compression, etc. from demuxer to decoder [19:50:29] <BastyCDGS> I think using AVPacket->data is the best way, since some of these values can change during IFF-ANIM frames [19:55:59] <siretart> wbs: pong on ""remove ff-prefixed function that lavf despite that uses currently" issue. [19:57:54] <wbs> siretart: ok, thanks :-) [19:59:23] <wbs> hmm, interestingly enough, if we first clean up more such stuff in lavf, it will actually be harder to notice which of the lavc-private functions actually are in use by older lavf-versions [20:00:01] <wbs> but despite that, I guess it's good to clean up such stuff from lavf, and add notes to those functions in lavc saying that they're in practice public [20:01:04] <BastyCDGS> I just added a dummy function for it [20:04:07] <BBB> BastyCDGS: try AVPacket->data without any obvious hacks and see if that works [20:04:10] <BBB> I'd like to see if that works [20:04:28] <wbs> FWIW, http://pastebin.org/231453 are the ff_ prefixed functions used by lavf [20:05:45] <BastyCDGS> do I have to transfer data in AVPacket with the bytestream functions, too? like I did with extradata? [20:05:58] * BBB throws peloverde some cookies [20:06:15] <peloverde> for? [20:06:20] <BBB> how do you read it in the demuxer again? [20:06:24] <BBB> is it part of the frame header? [20:06:35] <BBB> peloverde: flaming michael [20:07:10] * wbs throws a bunch of cookies at peloverde, too [20:07:18] <wbs> for working on very useful stuff :-) [20:08:36] <BBB> I wasn't trying to be negative [20:08:40] <BBB> I threw him cookies, not dirt [20:08:54] <wbs> I wasn't negative either [20:09:01] <BBB> ok :) [20:09:04] <siretart> wbs: you can look at the lavf files that #include non-public lavc headers... [20:13:21] <wbs> sure.. should I file roundup cases for each of them? I don't think I have the time to try to fix them [20:13:59] <BBB> send an email and ask maintainers to fix it [20:14:07] <BBB> after a week, file issue entries for the rest [20:14:12] <BBB> might save you a lot of time [20:26:36] <BastyCDGS> what is this in AVPacket? [20:26:36] <BastyCDGS> void *internal_buffer; [20:27:56] <BastyCDGS> or can I do such stuff with: [20:27:56] <BastyCDGS> int (*execute)(struct AVCodecContext *c, int (*func)(struct AVCodecContext *c2, void *arg), void *arg2, int *ret, int count, int size); [20:31:10] * BBB slaps BastyCDGS for thinking of random hacks [20:31:34] <BastyCDGS> I just want to know what these are for [20:31:39] <BBB> threading [20:31:56] <BastyCDGS> internal_buffer, too? [20:32:02] <BBB> not sure about that one [20:32:51] <BastyCDGS> void *AVPacket::priv what is this exactly for? [20:34:10] <mru> :: doesn't mean anything around here [20:34:53] <BastyCDGS> wanted just to mention that I meant AVPacket's priv [20:35:09] <BastyCDGS> for whom it's private [20:35:36] <BastyCDGS> can both demuxer and decoder access it? [20:36:02] <wbs> I don't think it's for such use, it's probably private to the one that has allocated an AVPacket [20:36:07] <BastyCDGS> so I can use it as extradata for the decoder from the demuxer [20:37:00] <wbs> no, absolutely not [20:37:26] <wbs> the decoder is not allowed to touch such data [20:38:54] <BastyCDGS> then AVPacket->data is the only one possibility [20:39:06] <BastyCDGS> so we have 2 possibilities here [20:39:10] <BastyCDGS> prepend or append [20:40:01] <BastyCDGS> prepend is problematic because it breaks compatibility between old + new decoder/demuxer [20:40:22] <BastyCDGS> so append ensures that an old decoder can still decode data from new demuxer [20:41:23] <wbs> is this still the same codec id as existing stuff? I know you suggested something that added like 10 new codec ids earlier, which was rejected [20:41:42] <wbs> but something like CODEC_ID_IFF_HAM or such, would that make sense? [20:42:28] <CIA-7> ffmpeg: cehoyos * r23131 /trunk/libavcodec/ac3dec.c: Fix compilation of AC3 decoder if E-AC3 decoder was disabled. [20:42:52] <BastyCDGS> or use codec_tag i.e. create a fourcc for HAM and masked planar? [20:43:19] <wbs> perhaps [20:45:52] <BastyCDGS> I'm just thinking at the most compatible way to indicate a new format style packet with extradata [20:46:25] <BastyCDGS> codec_tag is a bit problematic here, because the decoder only checks if it's ILBM and if not it always assumes PBM [20:47:04] <BastyCDGS> a different codec_id will probably better, but only one [20:48:45] <BastyCDGS> I have an idea, we add a new codec_id to: [20:48:45] <BastyCDGS> CODEC_ID_IFF_ILBM, [20:48:45] <BastyCDGS> CODEC_ID_IFF_BYTERUN1, [20:48:48] <BastyCDGS> avcodec.h [20:48:57] <BastyCDGS> CODEC_ID_IFF_NEW, [20:49:49] <BastyCDGS> which takes a well defined structure to AVPacket->data before the beginning of the actual data. [20:49:57] <mru> no [20:50:17] <BastyCDGS> what's the problem with it, mru? [20:50:37] <mru> codec id proliferation is bad [20:51:49] <thresh> mru: thanks [20:51:53] <BastyCDGS> so should I don't care about compatibility when appending extradata to AVPacket->data [20:52:07] <mru> what are you doing? [20:52:18] <mru> that sounds very wrong [20:52:54] <BastyCDGS> the stuff that was in extradata must go into AVPacket [20:53:00] <mru> why? [20:53:18] <BastyCDGS> because these values can change (esp. compression) during frames with IFF-ANIM [20:53:38] <BastyCDGS> michael told me that such stuff can't goto AVFrame etc. [20:53:46] <mru> how does iff-anim signal such changes? [20:54:10] <BastyCDGS> ANHD chunk for each frame [20:54:23] <BastyCDGS> but actual data is in DLTA chunk [20:54:28] <mru> and you're putting that in extradata now? [20:54:40] <BastyCDGS> that's what I wanted to do [20:54:48] <BastyCDGS> masking transparent color can also change each frame [20:55:03] <mru> but does the code currently in svn do that? [20:55:04] <BastyCDGS> the only one which doesn't was ehb/ham flag [20:55:52] <BastyCDGS> no it doesn't use either, except AVFrame->extradata for the palette lonely and AVPacket->data for the raw data from the BODY chunks [20:56:06] <mru> if you'd only be "breaking" something that doesn't work anyway, there's nothing to be concerned about [20:56:33] <wbs> BastyCDGS: the actual data for IFF-ANIM, would it use one of the existing codec ids, or would it use a new one? [20:56:42] <mru> there is no AVFrame.extradata [20:56:44] <mru> what did you mean? [20:57:01] <BastyCDGS> sorry did mean AVCodecContext [20:57:14] <wbs> if the actual data is totally different, you shouldn't be hijacking some old codec id for it [20:57:53] <BastyCDGS> wbs, that's why I had my idea above for using a new codec id [20:57:59] <BastyCDGS> und thus use a new one [20:58:08] <mru> but that should have a proper name and not a silly _NEW suffix [20:58:21] <wbs> like CODEC_ID_IFF_ANIM or something such? [20:58:23] <BastyCDGS> because I'm still thinking of a better name ;) [20:59:13] <BastyCDGS> codec ID anim should really indicate an IFF-ANIM stream [20:59:13] <wbs> when you declare a new codec id, it should be quite well-defined and not just some id that you choose to use for passing your data for that particular day [20:59:23] <BastyCDGS> not a HAM picture and/or masked picture [21:00:49] <wbs> is each frame in IFF-ANIM a full keyframe in one of the earlier normal still picture formats, or can they be some totally separate format, too? [21:01:05] <BastyCDGS> do you think it's acceptable that I call the CODEC_ID_IFF_ANIM codec for HAM6/masking pictures, too? [21:01:30] <BastyCDGS> yes they can be a totally separate format, too. [21:01:36] <mru> are still images a subset of anim? [21:01:36] <BastyCDGS> DLTA chunks [21:01:43] <BastyCDGS> yes [21:01:51] <BastyCDGS> at least the first chunk is normal IFF-ILBM [21:01:59] <BastyCDGS> the're can be as many as possible [21:02:01] <mru> so a still could be considered a single-frame anim? [21:02:29] <BastyCDGS> yes [21:02:36] <mru> then they should use the same codec id [21:02:57] <zorgy7> hi guys [21:03:13] <zorgy7> i want to have a start on the small tasks [21:03:14] <BBB> what you want is to use the PKT_FLAG_KEY in AVPacket->flags [21:03:22] <BBB> BastyCDGS: if it's set, it's a regular ILBM frame [21:03:23] <zorgy7> particularly the huffman one: http://guru.multimedia.cx/small-tasks-for-ffmpeg/ [21:03:32] <BBB> BastyCDGS: if it's not set, you're dealing with a DLTA chunk [21:03:48] <BBB> (and set it in the demuxer where appropriate [21:04:01] <wbs> BBB: i think he needs to pass a few more bits of info than that, since the raw data can be in a few different formats [21:04:05] <zorgy7> do I need to edit the mjpeg.c in libavcodec? [21:04:10] <mru> if we need to change the format of existing (extra)data, that's not a problem imo [21:04:29] <BBB> zorgy7: yes [21:04:30] <mru> the one user on the planet can surely cope with it [21:04:34] <BastyCDGS> didn't you mean if it's clear it's regular ILBM? [21:04:40] <BastyCDGS> and set is new DLTA, HAM6, etc. stuff? [21:04:46] <BBB> no [21:04:50] <BBB> DLTA means it's not a keyframe [21:05:01] <BBB> so PKT_FLAG_KEY, which indicates it's a keyframe, should not be set [21:05:02] <zorgy7> BBC: this function right? ff_mjpeg_build_huffman_codes [21:05:06] * mru assumes that's a contraction of delta [21:05:19] <BBB> right [21:05:28] <zorgy7> :) [21:05:29] <zorgy7> ty [21:05:30] <BBB> zorgy7: I think, although I'm not very familiar with the code [21:05:46] <wbs> mru: he needs to pass info about the format of each individual frame, though, since they can be in different formats, so extradata isn't useful for that [21:05:52] <zorgy7> okay np, I was just making sure im on the right track [21:06:00] <zorgy7> thanks for your advice :) [21:06:01] <BastyCDGS> wbs, yes exactly that [21:06:02] <mru> wbs: then don't put it in extradata [21:06:20] <BBB> AVPacket->flags is good for indicating that the frame is a keyframe [21:06:24] <mru> if current code is doing that, that's a bug [21:06:29] <BBB> anything else, like masking, ehb or so needs to be done differently [21:06:36] <BastyCDGS> no current code isn't doing that [21:06:38] <BBB> we can look at all of that on a case-by-case basis [21:06:49] <BastyCDGS> then let's start with masking [21:07:24] <wbs> so, would it make sense to wrap this in CODEC_ID_IFF_ANIM, add a few bytes prelude to each packets data that explains what kind of packet it actually is? [21:07:31] <BastyCDGS> masking differs that there's an extra plane per line which has to be skipped instead decoded [21:07:31] <mru> what's the problem with dumping the frame header and frame data in the packet data? [21:07:53] <mru> I don't see a need for a new codec id [21:08:22] <mru> if mismatched lavf and lavc fail, so be it [21:08:38] <BastyCDGS> so just don't care for backward compatibility? [21:08:46] <mru> there's probably no more than one user of this anyway [21:09:07] <wbs> true [21:09:40] <BastyCDGS> well if we break compatibility here, then we can cut off ff_cmap_read_palette as well... [21:09:49] <mru> if hypothetically inconveniencing one person reduces bloat and complexity on our part, I'd say it's worth it [21:10:04] <wbs> BastyCDGS: no, that's a slightly bigger issue [21:10:10] <mru> that could make linking fail [21:10:16] <mru> whether or not it's used [21:11:04] <BastyCDGS> then let's append format header stuff after the actual BODY data stuff with a length of additional data und the flags for ham, ehb, compression, etc. [21:11:27] <wbs> in that case, how do you know how long the body data is? [21:12:11] <BastyCDGS> s->planesize * avctx->height bytes [21:12:24] <wbs> even if it is some delta data? [21:12:58] <BastyCDGS> in that case we have a different pkt->flags [21:13:06] <BastyCDGS> PKT_FLAG_KEY [21:13:18] <wbs> yes, but do you know how long the body data is in that case, too? [21:13:45] <BastyCDGS> when we have some delta data we can take the number of already decompressed bytes and compare that to above [21:14:50] <BastyCDGS> well I see it's not a good idea [21:15:07] <wbs> my point is, if it isn't crystal clear exactly how long the body data is and where to look for the extra flags, I'd prefer prepending them [21:15:10] <BastyCDGS> only if you intend to always to decode the byterun stuff before then [21:15:28] <BastyCDGS> maybe that's just hell easier [21:15:31] <wbs> I wouldn't want a 5-if-statement block just to find out where to look for the flags [21:15:40] <BastyCDGS> lol ;) [21:16:00] <wbs> because that's the order you decode it anyway, first you check to see _what_ it is, then you proceed to actually decode the data when you know what format it is in [21:16:01] <BastyCDGS> prepend starts with number of bytes to skip from this to find actual data [21:16:28] <mru> is the header variable length? [21:16:45] <BastyCDGS> if we don't define a fixed one, yes? [21:16:56] <wbs> if you really need that flexibility, yes - if you just need a few bytes of flags/format numbers, a few bytes fixed header probably is simpler [21:17:11] <BastyCDGS> but so we can add newer variables and the old versions still finding correct position [21:17:36] <mru> why would we do that? [21:17:44] <mru> the format is petrified and will never change [21:17:47] <BastyCDGS> well prepending 16 bytes really sounds nice [21:17:58] <mru> why 16? [21:18:08] <BastyCDGS> should be enough for all times [21:18:14] <mru> wrong answer [21:19:10] <BastyCDGS> that's why I would prefer an actual size as uint32_t oder sth. [21:19:20] <BastyCDGS> or sth. like that [21:19:25] <mru> still wrong [21:19:34] <mru> and we understand german :-) [21:20:23] <BastyCDGS> but what do you think is the correct way then? [21:20:50] <mru> make it exactly as long as it needs to be [21:21:21] <BastyCDGS> and then if it has to be made longer someday all compatibility is broken again? [21:21:43] <wbs> yes, but the whole format you're dealing with is ancient and doesn't get any updates [21:21:53] <wbs> read through the specs, look for what you need to signal [21:23:24] <BastyCDGS> I really can't tell right now, since there are other IFF formats, like IFF ACBM, IFF DEEP, IFF 16SV etc. [21:23:36] <BastyCDGS> IFF TCM1 [21:23:56] <mru> then your first task is to find them all and check [21:24:27] <BastyCDGS> please note that IFF format is as extensible as RIFF [21:24:38] <BastyCDGS> in fact they're the same just that with big endian [21:24:54] <BastyCDGS> so there also can be new IFF formats from PowerPC/ARM users etc. [21:25:02] <mru> lol [21:25:18] <mru> that's about as likely as Latin growing a seventh case [21:25:40] <wbs> mru: that'd sure surprise you, wouldn't it? ;P [21:26:33] <mru> yeah, I think it would [21:26:46] <mru> the finns would probably handle it better [21:26:52] <mru> having 17 or something already [21:27:08] <wbs> yeah, finnish is a fantastic language ;P [21:27:47] <wbs> luckily, it follows the rules of the language quite well (compared to swedish which is mostly exceptions all the way)... the downside is that the amount of rules is insane ;P [21:27:52] <mru> spelling is consistent, got to give it that [21:28:29] <mru> swedish isn't so bad with exceptions [21:28:33] <BastyCDGS> well but what's the problem with having just a 4-byte long big endian length before actual packet data how long the prepended date is and that is [21:28:38] <BastyCDGS> so we never run in any problem [21:28:48] <mru> it's unnecessary complexity [21:29:09] <wbs> ooh, 4 bytes length, in case we'd need more than 16 KB of format metadata :-) [21:29:17] <wbs> eh, more than 64 KB [21:29:23] <mru> people have managed to describe latin in great detail, and the romans didn't leave any PDFs behind [21:29:40] <mru> now go read those docs [21:31:32] <BastyCDGS> well what about storing the athere's at least one to be reverse engineered [21:32:29] <BBB> where's the patch BastyCDGS ? [21:32:32] <BBB> I'm waiting for review :) [21:34:50] <BastyCDGS> btw, frame.data[0] is normal body data, frame.data[1] is palette if PAL8 [21:34:57] <BastyCDGS> what is frame.data[2] etc.? [21:35:04] <BBB> planar YUV [21:35:07] <BBB> data[0] is Y [21:35:10] <BBB> data[1] is U [21:35:12] <BBB> data[2] is V [21:35:33] <mru> data[3] is W [21:35:45] <BBB> SIGSEGV [21:35:52] <BBB> or, rather [21:35:55] * BBB throws an exception [21:36:03] <BastyCDGS> then the IFF demuxer/decoder currently uses Y for actual BODY chunk, U for palette data [21:36:04] <wbs> it can be A, in YUVA, too [21:36:16] <BBB> yeah [21:36:17] <mru> BBB: data[] has 4 elements [21:36:37] <BBB> BastyCDGS: a demuxer has no access to a AVFrame [21:36:43] <BastyCDGS> I want to use data[2] for storing the extradata stuff [21:36:44] <BBB> it spits out AVPackets [21:36:47] <BBB> completely differenty [21:36:57] <BBB> video decoders decode into AVFrames [21:37:11] <BastyCDGS> as I see the fif_read_packet sets data[0] to actual IFF BODY (graphics) data and data[1] to whole RGB palette bot doesn't do anything with data[2] [21:38:09] <mru> eh? AVPacket has only data, no data[] [21:38:16] <BastyCDGS> sorry not iff_read_packet [22:02:05] <wbs> bcoudurier: can you give an estimate on when you have time to review the movenc/rtphint stuff, btw? all the external stuff was ok'd by luca a and michael, so if you find something you don't like, I can try to fix it later, too [22:02:22] <wbs> and just commit it now, if you don't have time to review it another time, that is [22:21:39] <zorgy7> guys, is there a linked list in libavutil? [22:22:17] <BBB> don't think so [22:22:30] <BBB> if you want playutils, you could probably link against glib [22:22:40] <BBB> it has GList/GSList etc. [22:22:46] <Dark_Shikari> I'd just use an up-tree [22:23:01] <Dark_Shikari> aka single-allocation linked data structure [22:23:05] <Dark_Shikari> unless it has to be of unbounded size [22:28:46] <BastyCDGS> BBB, one question...is AVPacket->data filled already when decode_init is called? [22:29:10] <wbs> no, you don't have any AVPacket at that time yet [22:29:17] <wbs> the function doesn't get any such parameter [22:29:50] <BBB> AVPacket->data is unfilled when read_packet() is called, you allocate it with av_new_packet() [22:30:03] <BBB> AVPacket->data is filled when you call decode_frame() [22:30:13] <BBB> any other function does not take AVPacket as argument [22:32:14] <BastyCDGS> BTW, I want to implement DPaint color cycling at a alter point, then I have to move palette to AVPacket->data, too [22:32:18] <BastyCDGS> later [22:49:48] <zorgy7> ok [22:59:13] <zorgy7> is it okay to make my own heap structure in libavutil? [22:59:42] <zorgy7> or should it be placed in mjpeg? [23:07:36] <BBB> zorgy7: what kind of structure are you looking for? [23:07:47] <BBB> if it belongs to the mjpeg codec, it should likely be in the mjpeg.c file [23:08:34] <zorgy7> em [23:08:49] <zorgy7> a min-heap for the huffman algorithm

1 0

IRC log for 2010-05-12
by irc＠mansr.com 13 May '10

13 May '10

[01:48:04] <CIA-7> ffmpeg: bcoudurier * r23100 /trunk/ (doc/libavfilter.texi ffmpeg.c): rename -vfilters cli option to -vf [03:07:15] <peloverde> Anyone know any good audio waveform analyzers? audacity isn't giving me the granularity I need [03:49:19] <peloverde> sorry, stupid wm keeps crashing [05:18:38] <saintd3v> peloverde: baudline? [05:19:10] <saintd3v> i think it has a waveform view [05:19:38] <peloverde> i'll give it a look, thanks [05:35:37] <ramiro> building ffmpeg for windows on msys took 5m49s. building ffmpeg for windows on ubuntu running under virtualbox on the same machine took 5m20s. [05:36:29] <peloverde> msys is slow [05:36:47] <Dark_Shikari> s/msys/windows [05:36:53] <Dark_Shikari> the problem is fork is slow [05:40:33] <ramiro> I switched the configuration on my quad core. it used to be ubuntu running a few windows vboxes. now it's windows (2008r2) running one ubuntu vbox (for irssi, of course, the most important reason I keep this box =). [05:40:53] <Dark_Shikari> also, really, building ffmpeg only took 5 minutes on windows? [05:40:57] <Dark_Shikari> what version of windows? [05:41:05] <Dark_Shikari> it takes about that long to run _configure_ here [05:41:42] <ramiro> windows 2008 server r2 on a q6600 (make was not parallelized) [05:42:22] <ramiro> the fate tests will be down until I finish setting up the new toolchains. [05:47:51] * peloverde 1 - 0 spatial holes [05:48:09] <Dark_Shikari> does it still sound worse than faac at half the bitrate? [05:49:33] <peloverde> depends on the number of channels and if it is in constant quality mode or constant bitrate mode [05:49:42] <drv> configure takes ~1m to run on my c2d win7 x64 system with msys, and about half of that is the "Creating config.mak and config.h..." step [05:55:12] <Dark_Shikari> 3 minutes 52 seconds here [05:55:16] <Dark_Shikari> win7, cygwin 1.7 [05:55:30] <drv> cygwin redefines slow [05:55:40] <drv> (not that msys is a speed demon either) [05:56:45] <Dark_Shikari> cygwin was much faster on xp [05:56:51] <Dark_Shikari> something in the kernel must have made fork slower. [05:59:48] <peloverde> oh shit, psymodel bugs, or at least bugs in my understanding of the psymodel [06:02:35] <peloverde> it seems like masking theresholds are way too high in the remaining windows after an attack [06:02:51] <peloverde> sigh, I should really just be writing this down [06:09:55] <peloverde> I guess I hope that if I ramble about it enough someone will take interest and join in [06:36:28] * _av500_ joins in rambling [06:49:45] <KotH> salut mes amis [07:04:55] <Tjoppen> dags för morgonkaffe [07:08:17] * _av500_ wakes slowly [07:15:20] <KotH> Tjoppen: coffee is something you drink in the afternoon, not in the morning [07:15:33] <KotH> .o0(alles barbaren hier) [07:23:41] <merbzt1> http://www.google.com/patents?id=XYYHAAAAEBAJ&printsec=abstract&zoom=4&sour… [07:32:04] <Tjoppen> KotH: pff, the day starts with coffee, and continues with coffee. it also ends with coffee [07:33:16] <Tjoppen> merbzt1: wtf? also, lots of prior art [09:19:35] <Kovensky> merbzt1: I remember seeing that linked on cracked.com [11:07:30] <pentanol> peloverde about audio waveform analyzer, probably you're looking for oscilloscope? [13:26:42] <Tjoppen> is there a way to ensure AVPacket::dts gets set? [13:28:18] <Tjoppen> I'm getting audio packets without DTS from the MXF demuxer, which I find a bit odd [13:30:40] <j-b> good morning [13:33:29] <mru> morning j-b [13:34:53] <av500> j-b: gm [13:38:26] <j-b> Is '[mxf @ 0x831d880]MAX_READ_SIZE:5000000 reached [13:38:46] <j-b> Is '[mxf @ 0x831d880]MAX_READ_SIZE:5000000 reached' an issue, a warning, an error, or none of the above? [13:39:13] <Compn> good question [13:42:34] <mru> none of the above: it's a nuisance [13:44:38] <j-b> It is a bit annoying, yes [13:45:33] <j-b> I'll wait for master Coudurier to come, and 'll ask [13:52:33] <pentanol> hello, may be some one knows why after receiving rtsp stream I've got Duration: N/A, start: 0.000000, bitrate: N/A and also itn's palying [13:53:46] <Kovensky> j-b: he same happens with the mpegps demuxer [13:53:48] <Kovensky> the* [13:54:04] <Kovensky> Tjoppen: on audio, isn~t dts == pts: [13:54:09] <Kovensky> oh stupid br-abnt2 keyboard [13:54:33] <Tjoppen> yes. the odd part is that if demuxes everything fine, except for the last packet in each audio stream [13:54:58] <Tjoppen> I have MXF with one DVCPRO100 stream and four pcm_s24le streams [13:55:49] * Kovensky wonders why do the pcm_* decoders have framesize == samplesize [13:55:58] <Tjoppen> I'm actually patching the demuxer since it produces bogus values for pkt->ofs [13:56:32] <kierank> [14:54] <Kovensky> Tjoppen: on audio, isn~t dts == pts: --> huh [13:56:55] <kierank> which audio does dts != pts [13:57:10] <kierank> oh you are asking the question [13:57:16] <Kovensky> nah, he just said that DTS isn't being set [13:57:20] <Kovensky> what if PTS is? :> [13:57:38] <Kovensky> (which is weirder, ofc) [13:59:22] <Tjoppen> on, PTS isn't set either [13:59:30] <Tjoppen> I check for that first, and use DTS if no PTS is set [14:00:03] <Tjoppen> documentation of AVPacket says DTS can be AV_NOPTS_VALUE. I wonder for what reason though [14:00:34] <Kovensky> DTS is AV_NOPTS_VALUE on streams with B-frames, according to the edocs [14:02:55] <Tjoppen> but then PTS should be set. also, this is audio :o [14:03:24] <Tjoppen> maybe the mxf demuxer failing regtests has something to do with this [14:15:12] <Tjoppen> heh, backing up a bit makes the tests pass [14:15:26] <Tjoppen> however, my patch makes them fail because it makes the mxf demuxer output correct values for pkt->ofs :) [14:47:54] <Tjoppen> there we go. patch sumitted to list [14:55:42] <Tjoppen> getting bogus PTS and DTS makes no sense though [17:06:45] <CIA-7> ffmpeg: reimar * r23101 /trunk/libavcodec/utils.c: [17:06:45] <CIA-7> ffmpeg: Set coded_frame to NULL when closing a codec, since it might [17:06:45] <CIA-7> ffmpeg: be invalid after the codec is "gone". [18:16:09] <BastyCDGS> yippie, exams for today finished :) [18:16:12] <BastyCDGS> back @ home [18:54:06] <Tjoppen> BastyCDGS: party time in other words [18:54:19] <BastyCDGS> yes until sunday ;) [18:54:36] <thresh> partying is cool. [18:54:41] <BastyCDGS> monday next exam writing from 6-14 UTC [18:55:03] <BastyCDGS> got some beer for tonight ;) [18:55:40] <thresh> but, in Soviet Russia, the Party always find you. [18:55:49] <thresh> not the other way round :( [18:56:17] <BastyCDGS> oh here in liege are often spontaneous events [18:59:30] <BastyCDGS> had just one two weeks ago [19:00:39] <BastyCDGS> just got invited to disc throwing in the park and then they took me to a nice afternight party with excellent food and some funny people :) [19:01:15] * thresh usually have parties going on from Friday night till... well [19:01:37] <BastyCDGS> that's great! [19:01:47] <thresh> till you know when. I rarely last for more than Sat midnight though [19:02:18] <BastyCDGS> Sounds like me when going to goa festivals or goa parties in berlin ;) [19:03:21] <BastyCDGS> that's when I'm longer partying [19:03:23] <thresh> those are usually 'hey, let's go to that pub; and then to the other one; and then to a club; and then to someone's flat; ..." etc etc :-) [19:03:39] <thresh> not a big fan of trance music myself [19:03:59] <_av500_> thresh: always end with an irish pub, u know... [19:04:18] <BastyCDGS> what do you listen too? [19:04:51] * BastyCDGS is just listening to cafe del mar [19:05:18] <thresh> _av500_: yes. This is a good rule when brain decides what to do. Cant stand to go somewhere else when filled with irish spirit, though. [19:05:54] <thresh> BastyCDGS: something like stuff here: http://www.last.fm/user/thresh [19:11:53] <BastyCDGS> interesting to listen to, but I'm not in mood for that kind of music right now. I just want to calm down. [19:17:59] <Dark_Shikari> ffmpeg 0.5.1 is supposed to still have vhook, right? [19:18:44] <peloverde> I think [19:34:39] * peloverde sees that psy bands are computed after several processes that use them [19:34:45] * peloverde headdesk [19:46:59] <BastyCDGS> well guys I will have some sleep now, totally tired. Wish you all good night. [20:12:45] <janneg> does someone know if hddvd/evo uses non mpeg1/mpeg2 extensions pes packet headers? [20:21:00] <Dark_Shikari> revision 31153 in swscale broke things [20:21:10] <Dark_Shikari> http://pastie.org/957655 [20:21:22] <Dark_Shikari> ramiro: ping [20:33:41] <ramiro> Dark_Shikari: pong [20:35:13] <ramiro> I did you bisect to 31153? [20:35:47] <Dark_Shikari> ramiro: yes [20:35:50] <Dark_Shikari> well, I didn't, use in #ffmpeg did [20:36:41] <ramiro> I don't have time to look now, I'll just revert for the moment [20:38:23] <janneg> nevermind, it's just fake startcodes in private_stream_1's data [22:18:23] <CIA-7> ffmpeg: stefano * r23102 /trunk/libavformat/avformat.h: Doxygen av_codec_get_id() and av_codec_get_tag(). [22:38:54] <CIA-7> ffmpeg: lorenm * r23103 /trunk/libavcodec/bitstream.c: change a variable-length array to a malloc. [23:19:05] <CIA-7> ffmpeg: bcoudurier * r23104 /trunk/ffplay.c: rename -vfilters cli option to -vf in ffplay as well [23:44:10] <janneg> any patch monkeys around?

1 0

IRC log for 2010-05-11
by irc＠mansr.com 12 May '10

12 May '10

[00:03:40] <Dark_Shikari> Compn: what's wrong with facebook? [00:03:42] <Dark_Shikari> they use ffmpeg and x264 [00:20:29] <peloverde> well let's see... beacon, the like button all over the web, converting interests to page subscriptions to spam your news feed with commercial garbage [00:23:45] <CIA-7> ffmpeg: michael * r23083 /trunk/libavcodec/x86/mathops.h: Adding missing () to mathops.h. [01:45:42] <CIA-7> ffmpeg: ramiro * r23084 /trunk/libavcodec/mlpdec.c: [01:45:42] <CIA-7> ffmpeg: mlpdec: Allocate channel decoding parameters for each substream. Some file [01:45:42] <CIA-7> ffmpeg: was encountered with a channel range that overlapped the previous substreams, [01:45:42] <CIA-7> ffmpeg: and the code assumed no such overlap was possible. [01:45:42] <CIA-7> ffmpeg: Patch by Nick Brereton <nick at nbrereton dot net> [01:47:05] <CIA-7> ffmpeg: ramiro * r23085 /trunk/libavcodec/mlpdec.c: [01:47:05] <CIA-7> ffmpeg: mlpdec: Comment channel_params field in struct SubStream. [01:47:05] <CIA-7> ffmpeg: Patch by Nick Brereton <nick at nbrereton dot net> [02:27:06] <Orphis> Hi there ! [02:28:26] <Orphis> I'm currently using ffmpeg in my PSP emulator ( http://www.jpcsp.org ) to decode h264 video on the fly that appears in games [02:29:08] <Orphis> I'd like to use ffmpeg to also decode the atrac3plus channel that is often used... unfortunately, you don't support it yet [02:30:46] <Orphis> So I'd like to know if I can be of some help to implement atrac3plus decoding in ffmpeg, considering I know my way around programming and hacking [02:31:15] <ramiro> interesting, http://marchnetworks.com/ seems to have an internal wiki which helps people build libavcodec for windows. google sees no mention of ffmpeg nor libavcodec in any of their pages though. [02:32:04] <Orphis> I haven't found much information on the format other the one on your website/wikipedia, so I'd like to know how you would implement decoding for such a format. Do you only rely on reverse engineering of existing software or you you have some external documentation ? [02:32:18] <Dark_Shikari> I already answered that for you =p [02:32:46] <ramiro> didn't merbanan implement atrac3 or something? [02:32:54] <Orphis> Yes, but maybe someone would make a different or more complete answer then you did ;) [02:33:02] <Orphis> I'm interested in atrac3plus [02:47:05] <ramiro> Dark_Shikari: what strings should I look for to see if x264 was built into a dll? [02:50:41] <Dark_Shikari> er, x264? =p [02:52:28] <Dark_Shikari> if you give me a list I can check [02:52:40] <Dark_Shikari> but really you can just grep for help strings [02:57:33] <Compn> Dark_Shikari : yeah, i meant all the facebook buttons everywhere [02:57:48] <Dark_Shikari> at least they know how to encode video [02:58:28] <Compn> Orphis : sometimes there are specs if its a standard [02:58:45] <Compn> but since atrac3+ is sony minidisc? crap, i think there wont be specs for it [02:58:53] <Compn> Orphis : so reverse engineering it is... [02:59:11] <Orphis> It's not minidiscs, but well, it's as obscure as they are [02:59:18] <Orphis> Right [02:59:27] <Orphis> Time to dust off my IDA [02:59:55] <Dark_Shikari> but we have atrac3 [02:59:58] <Dark_Shikari> so adding the + can't be too bad [03:00:03] <Dark_Shikari> and in all probability its a ripoff of something open [03:00:13] <Dark_Shikari> so just figure out what it's a ripoff of and bam [03:00:24] <Compn> Orphis : you should contact maxpol (Maxim Poliakovski ) as he wrote that atrac3+ wiki info [03:00:36] <Compn> Orphis : he might have some work started already or know where to start :) [03:00:37] <Orphis> These info : http://wiki.multimedia.cx/index.php?title=ATRAC3plus ? [03:01:33] <Compn> yep that one, [03:01:42] <Compn> http://wiki.multimedia.cx/index.php?title=User:Maxpol [03:02:04] * Dark_Shikari likes the container format called "omg" [03:03:56] <Dark_Shikari> holy shit, unheard of [03:31:45] <ramiro> the x264 strings were from ffmpeg's h.264 decoder. [03:32:36] <ramiro> anyways, another violation -> roundup [04:41:50] <kierank> is /incoming still full? [05:47:58] <superdump> morning [05:54:11] <av500> gm [09:03:46] <CIA-7> libswscale: ramiro * r31153 /trunk/libswscale/ (6 files in 2 dirs): [09:03:46] <CIA-7> libswscale: Use int instead of long to pass width parameters in non-public functions. [09:03:46] <CIA-7> libswscale: long was being incorrectly used as an x86-sized register, both for 32 and 64 [09:03:46] <CIA-7> libswscale: bits, but this is not the case in win64. [10:28:16] <thresh> __gb__: do you have some repos with libva / vdpau-video for debian systems? (i've seen pkgs, sure) [10:30:53] <spaam> http://cgit.freedesktop.org/libva/ ? :) [10:32:09] <thresh> spaam: i mean repositories with built packages. [10:32:35] <spaam> ah ok :) [10:42:57] <__gb__> thresh, http://www.splitted-desktop.com/~gbeauchesne/libva/ and vdpau-video/ [10:43:04] <__gb__> it's built on an etch system though [10:43:26] <thresh> and those arent apt repos;) [10:46:35] <spaam> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569635 no update on that "bug" [10:46:48] <spaam> since 21feb. [10:49:01] <thresh> "we will discuss it and let you know if five years" [10:49:07] <thresh> s/if/in/ [10:51:49] <spaam> debian-multimedia has libva-dev [10:51:58] <thresh> debian-multimedia is evil. [10:52:17] <spaam> i know. but its a repo with that package ;) [12:00:50] <siretart> thresh: we are working on a high quality alternative to debian-multimedia called debimedia. that could be a place for such packages [12:01:06] <thresh> siretart: working as? [12:02:10] <siretart> thresh: well, the infrastructure is partly there, we have one mirror, and seriously lacking manpower to actually build and upload the packages [12:39:51] <bilboed> siretart, ping [12:44:41] <siretart> bilboed: yes? [12:44:56] <__gb__> thresh, hmm, right, I am only scp'ing the packages to there :) [12:45:12] <bilboed> siretart, do you have any ETA for the 0.6 release ? Saw the branch being created, but nothing since. [12:45:59] <siretart> bilboed: actually, I wanted to do the release this week, but due to unexpected family trouble this weekend, I'll probably be to busy to actually do so. [12:46:34] <bilboed> hope it's not too bad :( Anyway, will switch gst-ffmpeg git to that branch then [12:46:40] <siretart> bilboed: left work items for the release: write the release notes, commit interesting/important commits from last week trunk to 0.6, have release notes translated, create the tarball, announce, profit [12:47:18] <siretart> translations can probably be delivered after the release as well, but you get the idea [12:47:46] <siretart> if anyone wants to help, helping to draft the release notes would be awesome! [12:47:47] <superdump> there are some rumblings about the swscale code's maturity [12:47:57] <superdump> on the ml [12:48:04] <superdump> though nothing has come from it yet [12:48:31] <siretart> superdump: testsuite shows that it ain't that bad, and supposely, bilboed is using swscale from trunk, so it can't be *that* bad [12:48:43] <superdump> good point [12:48:45] <siretart> superdump: in case we see regressions, we will of course backport fixes for 0.6.1 [13:01:14] <merbzt1> we can start a release notes / pressrelease draft on the multimedia wiki [13:13:58] <siretart> merbzt1: excellent idea! [13:54:27] <astrange> mplayer -vo corevideo <a 1080p file> is crashing in swscale asm for me [13:57:35] <kshishkov> where exactly? [13:57:50] <BBB> astrange: I think padding was missing [13:57:55] <BBB> astrange: that was fixed by vitor yesterday [13:58:00] <BBB> so are you using a recent checkout? [13:58:31] <astrange> yes, but it happened yesterday [13:58:58] <BBB> hm... ok [13:59:02] <BBB> then nevermind me ;) [14:00:00] <scaphilo> anyone knows how i could add an external include path for the compiler with configure? [14:00:41] <BBB> CFLAGS="-I..." ./configure [14:00:57] <scaphilo> ah that easy :-) [14:00:59] <scaphilo> thx [14:01:20] <kshishkov> IIRC configure has --extra-flags argument for that too [14:03:41] <scaphilo> has anyone of you ever tried to compile ffmpeg with an auto generated make file from eclipse. Sorry for that :-) i ask because my embedded sdk for nios2 uses eclipse [14:04:07] <scaphilo> i dont know lirc, ill have to read thourgh [14:04:15] <merbzt1> scaphilo: FFmpeg needs it's own makefile [14:04:17] <av500> but ffmpeg has a makefile already, no? [14:04:21] <merbzt1> call it from eclipse [14:04:38] <scaphilo> thats what i do at the moment yes but its not nativ [14:04:50] <scaphilo> and my colleque is running it on windows [14:04:57] <kshishkov> eclipse is not native to FFmpeg, yes [14:05:10] <scaphilo> in cygwin it takes about 5min to run configure [14:05:18] <av500> so? [14:05:34] <merbzt1> don't run configure so often then [14:06:30] <scaphilo> anyway i do it as you said now. using the makefile built by configure [14:06:48] <astrange> http://pastebin.com/WamfC981 [14:10:22] <janneg> scaphilo: ffmpeg Makefiles are static and eclipse can't generate config.mak/config.h without reimplemtating most of configure [14:28:09] <scaphilo> CFLAGS ar now right but it doesnt find the h-files in this folder. Im a bit confused about that. could it be because i do cross compiling? is there an option for gcc which disables all -I? [14:45:20] <superdump> mru: did you see that mail from brendan quinn to work on http://ingex.sourceforge.net/? might be interesting for your perhaps? [14:46:10] <kierank> ingex is in c++ so that's mru out ;) [14:46:17] <superdump> ah [14:46:35] <kierank> he didn't say that. i'm just assuming [14:46:48] <kshishkov> he dislikes c++ [14:46:59] <merbzt1> maybe if can get a shotgun with the job [14:47:26] <kshishkov> yes, if you work at UAC [14:50:41] <CIA-7> ffmpeg: michael * r23086 /trunk/libavcodec/mpegaudiodec.c: Remove unused FRAC_RND() macro from mpegaudiodec.c. [15:01:05] <Tjoppen> mxf test seems to fail [15:01:30] <Tjoppen> rebasing and running tests again, but no mxf related files seem to have updated [15:08:45] <Tjoppen> false alarm [15:22:46] <astrange> http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.c-torture/compile/pr4406… it's almost like actually having a tester [15:44:36] <Tjoppen> woo! I figured out the AliasHandle tag well enough to get QuickTime to accept it (and not crash) [15:45:13] <Tjoppen> also, lavf doesn't handle it quite correct [15:58:55] <ramiro> is there some free (as in beer) icc? the web page I stumbled upon seems to mention only 30 day evaluation. [15:59:44] <CIA-7> ffmpeg: diego * r23087 /trunk/configure: [15:59:44] <CIA-7> ffmpeg: Add -ldl to libfaadbin_extralibs instead of libfaadbin_decoder_extralibs. [15:59:44] <CIA-7> ffmpeg: The latter does not exist and thus compilation fails. [15:59:44] <CIA-7> ffmpeg: patch by Janne Grunau, janne-ffmpeg jannau.net [15:59:54] <kshishkov> well, I've heard that beer is spoiled even more quickly [16:00:03] <merbzt1> ramiro: for linux there should be one [16:01:58] <kshishkov> or on TPB [16:03:23] <bilboed> ramiro, it won't expire if you take it for non-proprietary usage [16:04:17] <ramiro> probably this: Non-Commercial Software Download [16:04:36] <bilboed> it's the same download AFAIK, it's just that you get a different license file [16:05:09] <bilboed> if you think gcc spurts out a lot of warnings when compiling ffmpeg.... brace yourself for icc :) [16:05:20] <bilboed> it's the warning-o-tron 2000 [16:06:25] <Orphis> Anyone know how I can contact maxpol (Maxim Poliakovski) ? [16:06:34] <ramiro> great: "This site is temporarily unavailable due to a scheduled maintenance upgrade." [16:06:39] <kshishkov> by mail, I think [16:06:44] <Orphis> I haven't found any email address [16:07:11] <kshishkov> then you've searched badly [16:08:54] <kshishkov> what do you need from him anyway? [16:09:09] <ramiro> atrac3+ [16:09:53] <kshishkov> I happen to know that Maxim does not do it, I'd suggest asking merbzt for it [16:14:21] <Orphis> Yes, that's done, thank you [16:58:26] <mt> Is there something special that needs to be done when calling wma pro decoder's decode_packet ? I'm pretty sure I'm sending it the correct payloads (compared to ffmpeg's), but can't get it to work. (always returns 0 bytes written to output buffer) [17:02:12] <peloverde> I have a feeling that fixing some of those icc warnings will create more problems down the road [17:02:27] <peloverde> particuarly inregard to enum warnings [17:04:00] <peloverde> we've already been bitten by one such bug [17:15:05] <peloverde> see 20874/20879 [17:15:32] <CIA-7> ffmpeg: bcoudurier * r23088 /trunk/ffmpeg.c: cosmetics: filt_graph_all -> graph, like in ffplay.c [17:17:42] <CIA-7> ffmpeg: bcoudurier * r23089 /trunk/ffmpeg.c: simplify, reuse existing args variable [17:19:00] <CIA-7> ffmpeg: bcoudurier * r23090 /trunk/ffmpeg.c: cosmetics: indentation, whitespaces [17:21:19] <mru> hi guys [17:23:57] <CIA-7> ffmpeg: bcoudurier * r23091 /trunk/ffmpeg.c: rename curr_filter to last_filter, factorize filter declaration [17:25:58] <peloverde> did you steal bcoudurier's onjoin script and retrigger it to his commits? [17:26:05] <CIA-7> ffmpeg: bcoudurier * r23092 /trunk/ffmpeg.c: cosmetics, rename loop to frame_available [17:28:40] <bcoudurier> hi guys [17:36:14] <janneg> hi bcoudurier [17:38:00] <janneg> can you look at the latest the mpegts emit packets on completion patch and commit if it's ok now? [17:40:44] <CIA-7> ffmpeg: bcoudurier * r23093 /trunk/libavfilter/vf_pad.c: silence gcc warning about potential uninitialized usage [18:54:41] <CIA-7> ffmpeg: alexc * r23094 /trunk/libavcodec/aacenc.c: [18:54:41] <CIA-7> ffmpeg: Set cur_channel in the AAC encoder context where needed. [18:54:41] <CIA-7> ffmpeg: Most coder functions read it. Carting this around in the context may be [18:54:41] <CIA-7> ffmpeg: suboptimal; a refactor should be considered. [19:00:07] <peloverde> Is there a way in roundup to filter technical issues vs license issues? [19:00:53] <BBB> search for !gpl [19:01:10] <BBB> and yes it would be useful to have a major grouping type "license" versus "code" [19:01:26] <BBB> (and a third one for issues related to the tracket itself) [19:01:40] <BBB> ask lu_zero_ to do that [19:02:01] <peloverde> thanks [19:28:32] <wbs> bcoudurier: have you had time to look at the movenc/rtphint patches yet, or are they ok to apply when I fixed the stuff you mentioned the first round? [19:35:18] <bcoudurier> sorry, didn't have the time [19:36:17] <wbs> ok [19:37:06] <wbs> what about the qt-faststart stuff; moving all of the error handling to the "goto error" path shouldn't be controversial... and for 0-sized atoms, is break ok? [19:53:38] <CIA-7> ffmpeg: michael * r23095 /trunk/libavcodec/ (6 files): float based mp1/mp2/mp3 decoders. [19:54:09] <elenril> o_0 [19:55:09] <astrange> well, that solves that [19:55:51] <peloverde> anyone know where to find samples for listening tests? [19:57:51] <astrange> http://ff123.net/samples.html and somewherere in http://www.hydrogenaudio.org/forums/index.php?showforum=40 [19:58:16] <elenril> so now we can remove mp3lib from mplayer? [19:58:27] <peloverde> I looked at http://www.hydrogenaudio.org/forums/index.php?showforum=40 and i couldn't find samples [19:58:43] <peloverde> and searching for samples only yields sample rate discussion [19:59:10] <astrange> i meant something like http://www.hydrogenaudio.org/forums/index.php?showtopic=77584 [19:59:12] <peloverde> I feel like they used to have a sticky with samples [19:59:56] <peloverde> Also what's the copyyright status on that stuff? [20:04:57] <astrange> samples are supposed to be <= 30 sec [20:05:03] <astrange> but that's it [20:34:38] <CIA-7> ffmpeg: michael * r23096 /trunk/libavcodec/mpegaudiodec.c: Make lsf_sf_expand() 4 times faster. [21:11:45] <CIA-7> ffmpeg: michael * r23097 /trunk/libavcodec/mpegaudiodec.c: [21:11:45] <CIA-7> ffmpeg: Optimize decoding high freqs. [21:11:45] <CIA-7> ffmpeg: this is 10-20cpu cycles faster on duron (whole is about 50-60 cpu cylses) [21:11:45] <CIA-7> ffmpeg: I wonder why gcc isnt doing this on its own ... [21:21:24] <CIA-7> ffmpeg: michael * r23098 /trunk/libavcodec/mpegaudiodec.c: Factorize READ_FLIP_SIGN() optimization out [21:28:22] <peloverde> If TLS coder (with psytel inspired modifications) is better than the faac inspired coder at spectral holes but worse at pre-echo should I move to TLS now or try to fix pre-echo regressions first? [21:31:16] <peloverde> life was so much better before I started listening for pre-echo [21:32:46] <CIA-7> ffmpeg: michael * r23099 /trunk/libavcodec/mpegaudiodec.c: [21:32:46] <CIA-7> ffmpeg: Do the same sign flip optimization to the low freq decoder. [21:32:46] <CIA-7> ffmpeg: as with the high freq 10-20 cycles faster [21:44:15] <saintd3v> poor peloverde [22:04:55] <iive> peloverde: i wish I knew what you are talking about. All I understand is that is have something to do with audio encoders, probably aac. [22:05:06] <iive> is/it

1 0

IRC log for 2010-05-10
by irc＠mansr.com 11 May '10

11 May '10

[00:29:10] <CIA-7> ffmpeg: vitor * r23077 /trunk/libavfilter/defaults.c: [00:29:10] <CIA-7> ffmpeg: Alloc 16 extra bytes in libavfilter frames. Needed for MMX-optimized swscale. [00:29:10] <CIA-7> ffmpeg: Fix issue 1924. [06:18:20] <benoit-> mornings [06:19:15] <av500> gm [06:36:37] <wbs> morning [07:05:25] <superdump> morning [07:06:33] <wbs> superdump: what's the policy regarding reading reference code when doing a proper lgpl reimplementation? more specifically, amr [07:06:57] <wbs> i'm trying to get a grip on how the comfort noise/dtx/sid/whatever stuff really works, but the standard docs say like 10% of what the code actually does ;P [07:07:21] <Dark_Shikari> imo, feel free to read whatever you want, just put a large gap between reading and writing, so that your short term memory doesn't cover any of the code. [07:07:24] <Dark_Shikari> but I'm pretty liberal [07:07:42] <Dark_Shikari> and diego would probably disagree [07:08:04] <superdump> i suppose it's ideal if you've never looked at the code, then even if it resembles it, there's no way you could have known [07:08:21] <superdump> but reference code is for referencing so... [07:08:35] <superdump> not copy and pasting, but for understanding how stuff works [07:08:41] <superdump> and the amr specs are shite [07:08:49] <superdump> so you need the ref code to understand properly [07:09:02] <kshishkov> hmm, I'd argue [07:09:30] <kshishkov> usually you cannot make anything out of reference code [07:09:50] <CIA-7> ffmpeg: benoit * r23078 /trunk/libavcodec/h264_mp4toannexb_bsf.c: [07:09:50] <CIA-7> ffmpeg: Check NAL unit size to avoid reading past the buffer. [07:09:50] <CIA-7> ffmpeg: This fixes issue1907 [07:09:50] <CIA-7> ffmpeg: Patch by Thomas Devanneaux gmail(thomdev) [07:11:26] <superdump> well we're talking about amr, not 'usually' [07:11:28] <superdump> :) [07:12:04] <superdump> also, if they say that the code takes precedent over the spec in case of conflicts, you _have_ to look at the reference code [07:12:07] <superdump> and they do [07:12:32] <wbs> hah, great [07:12:35] <kshishkov> well, AMR spec was even less understandable than reference code IIRC [07:12:43] <superdump> right [07:13:10] <superdump> i didn't try to disseminate the comfort noise parts though [07:13:28] <kshishkov> who cares? It's the same stuff for all speech codecs [07:16:10] <superdump> mmm [07:18:20] <av500> mmm, is that irc comfort noise? [07:18:28] <kshishkov> yeth [07:18:45] <kshishkov> of of the kinds [07:18:48] <wbs> av500: although it isn't all that comforting at times ;P [07:18:49] <kshishkov> *one of [07:21:20] <kshishkov> wbs: not all of us have that comforting noise of Baltic sea waves [07:21:40] <wbs> true :-) [07:22:54] <av500> kshishkov: theres the rhine for you if you want :) [07:48:10] <ohsix> is there a lunixy tool to convert between subtitle types somewhere [07:52:36] <elenril> aegisub? [07:54:57] <ohsix> it includes commandline tools? [07:55:56] <elenril> don't think so [08:11:29] <KotH> ohsix: use perl, there isnt anything more unix to convert between text file formats [08:12:04] <ohsix> they aren't all text files [08:12:15] <kshishkov> KotH: awk! [08:12:44] <KotH> ohsix: that's why i said perl and not sed+awk [08:13:36] <KotH> kshishkov: awk alone is a bit awkward... you need at least sed to do anything reasonable with it [08:13:50] <kshishkov> KotH: worng [08:13:58] <kshishkov> yes, _that_ wrong [08:14:24] <kshishkov> I usually do that like /text-expr/{flag=1;} //{if(flag){do smth} flag=0;} [08:15:05] <kshishkov> that also saves a bit on grepping [08:15:47] <kshishkov> and it can manipluate fields [08:16:06] <kshishkov> but I use perl for a bit more complicated tasks anyway [08:17:08] <KotH> oh.. i do these kind of things in flex usually.. by far simpler than awk ;) [08:17:37] <kshishkov> "flex" as parser generator? [08:18:23] <KotH> exactkly, the swiss army knife :) [08:18:47] <mru> flex is nice, but not really a substitute for awk, sed, or perl [08:19:32] <kshishkov> KotH: in your case it's swiss army yatagan [08:29:20] <mru> fate was so nice and green... now look what someone's gone and done [08:30:10] <av500> isnt that the purpose of fate? to tell you somebody did something? [08:30:22] <mru> people should still be a little careful [08:31:02] <kshishkov> wow, http://fate.multimedia.cx/index.php?stderr=221920 [08:31:23] <mru> that's been there for ages [08:31:30] <mru> I don't know why mike doesn't fix it [08:32:49] <wbs> is there any history in fate to show which commit actually broke test X on machine Y? [08:33:18] <kshishkov> I wonder how http://fate.multimedia.cx/index.php?build_record=221921 got there [08:34:15] <mru> it's failing on most of my machines [08:34:21] <kshishkov> yes [09:10:18] <j-b> Diego? [09:24:33] <av500> mru: I have no idea why I needed that #if CONFIG_BSFS in the past... [09:33:50] <CIA-7> ffmpeg: mru * r23079 /trunk/Makefile: FATE: print friendly error for individual tests when SAMPLES unset [09:41:10] <funman> hi [09:41:34] <kshishkov> hI [09:41:52] <kshishkov> got any code to contribute? [09:42:11] <funman> not yet but i would like to work on it [09:42:34] <funman> i want to benchmark audio decoder [09:43:11] <funman> i see ffmpeg has a -benchmark option but i think ffmpeg is only used in conversion, not decoding-only? [09:43:56] <kshishkov> decoding is a process of converting packed data into unpacked form [09:44:09] <funman> developer doc mentions benchmarking but doesn't give examples [09:44:17] <funman> hm ok [09:44:35] <kshishkov> so try "ffmpeg -benchmark -i infile -f null -" [09:45:03] <kshishkov> add -vn/-an if needed [09:45:31] <funman> thanks [09:54:43] <funman> i'm looking at rockbox wma decoder, afaik mt & saratoga are too busy to contribute it back to FFmpeg [09:59:55] <j-b> salut funman [10:00:09] <funman> salut [10:11:12] <KotH> j-b: if you are looking for diego, dont look in #mplayer :) [10:11:31] <KotH> j-b: he's only on #mplayerdev and here [10:11:51] <av500> not in #punctuation? [10:12:28] <j-b> lol [10:12:34] <j-b> KotH: too bad, patch applied [10:15:46] <KotH> :) [10:23:31] <j-b> I hope I didn't mistake [10:42:55] <BastyCDGS> question, does somebody know if it is really portable to assume certain array element ordering, i.e. x[1024] == x[256][4]? [10:43:43] <mru> that's forbidden [10:44:07] <BastyCDGS> thanks, I'm doing the lut32 tables [10:44:08] <mru> the layout is defined, but you're not allowed to do out-of-bounds accesses [10:44:19] <BastyCDGS> I meant the layout [10:44:29] <mru> why do you care about the layout? [10:44:48] <BastyCDGS> I'm rearranging it a bit [10:44:52] <mru> so? [10:44:55] <Kovensky> optimilization? [10:45:01] <mru> memory layout still doesn't matter [10:45:02] <BastyCDGS> yes same for dp32 as for dp8 ;) [10:45:20] <av500> Kovensky: lol [10:45:20] <mru> as long as you access the arrays as they are declared, the compiler will take care of the rest [10:47:02] <BastyCDGS> does this still work if you mix 1D with 2D array access? [10:47:10] <mru> that's not allowed [10:47:20] <BastyCDGS> i.e. safe to assume [i][j] == i*256 + j? [10:47:23] <mru> no [10:47:26] <mru> well, it is [10:47:31] <mru> but you're still not allowed to do that [10:47:47] <BastyCDGS> ok, then I'll use 1D array [10:47:51] <mru> why? [10:49:03] <kshishkov> mru: s/why/what for/ [10:49:15] <mru> same question [10:49:27] <mru> and don't say it's faster [10:49:33] <BastyCDGS> to do sth. like this: [10:49:33] <BastyCDGS> http://pastebin.org/217296 [10:50:08] <mru> that won't work [10:50:22] <mru> AV_WN64A is a macro that might evalute the args more than once [10:50:37] <mru> it probably won't [10:50:50] <BastyCDGS> oh yes you're right, then I will put the ++ in the next line [10:51:11] <mru> but that's a separate issue [10:51:26] <mru> you're using a 2d array just fine there [10:52:24] <BastyCDGS> it's probably better to use + 1, + 2 than ++ here an there...right? [10:53:03] <mru> uh? [10:53:30] <BastyCDGS> isn't the compiler smart enough here? [10:53:36] <mru> to do what? [10:54:07] <BastyCDGS> to temporary store mask and simply increment by one for each [10:54:23] <BastyCDGS> hmm, anway it doesn't use inc instruction anyway but addl 1 [10:54:26] <mru> isn't that what your code does? [10:54:29] <BastyCDGS> so it shouldn't matter [10:54:46] <mru> and now you're micro-optimising again [10:54:47] <mru> stop it [10:54:49] <BastyCDGS> I mean when I use + 1 and + 2 instead those ++ parts (code looks simplier then) [10:54:57] <mru> not to me [10:55:16] <kierank> 11:54] <@mru> and now you're micro-optimising again --> more like pico-optimising [10:55:57] <mru> things like this are almost impossible to write optimally for all architectures anyway [10:55:58] <BastyCDGS> what's the problem when I've fun with it? [10:56:07] * av500 notices the fast do{...}while() pattern [10:56:09] <mru> if speed is that critical, you should write it all in asm [10:56:30] <mru> the problem is that you're wasting your time and ours [10:56:39] <BastyCDGS> well, I really thought of doing some asm versions of those but that's for later ;) [10:56:50] <mru> lol [10:58:10] <kierank> BastyCDGS: you need to look at things in perspective [10:59:25] <mru> it's a frickin amiga format ffs [10:59:53] <mru> speed is hardly relevant [11:00:01] * av500 makes note to buy even more beer [11:00:03] <mru> at least not the last 0.00001% [11:00:28] <BastyCDGS> http://pastebin.org/217327 [11:00:39] <KotH> av500: beer? [11:00:42] <mru> WASTE OF TIME [11:00:45] <KotH> av500: comming to lug-camp? [11:00:49] <mru> the paste, not the beer [11:00:55] <mru> beer is never a waste of time [11:00:59] <mru> unless it's french [11:01:00] <funman> speaking of micro-optimising, what is the point of r19669 ? [11:01:25] <mru> funman: to not have a stupid VLA [11:01:55] <funman> so mainly cosmetics? (nice looking code) [11:02:07] <mru> safer, more portable code [11:02:13] <BastyCDGS> besides this I'm doing here micro and macro opt in one time [11:02:27] <funman> ok [11:02:33] <mru> a vla can easily blow up your stack and there's nothing you can do about it [11:02:53] <mru> unless the compiler calls malloc, which is almost as bad [11:02:58] <mru> and slower [11:03:22] <mru> with gcc you lose one register and can't inline the function [11:04:52] <kshishkov> what, another one? [11:04:59] <mru> it requires a frame pointer [11:05:26] * kshishkov waits when GCC implements decent 1-register code compilation for x86 [11:06:15] <BastyCDGS> mru, by rearranging the tables I hope to get another speedup of 200% in dp32 [11:06:24] <BastyCDGS> the thing is they're accessed now more close [11:06:31] <mru> well, I can't deny you hope [11:06:44] <mru> how big is the table? [11:06:57] <BastyCDGS> 32*1024*8 [11:06:58] <pJok> kshishkov, you are also waiting for Ukraine to be part of the EU? which is most likely to happen first? ;) [11:07:08] <mru> that's a huge table [11:07:12] <mru> make it smaller [11:07:16] <mru> much smaller [11:07:26] <av500> pJok: you think it will cost more then greece? [11:07:40] <mru> a table that size will totally blow up your L1$ [11:07:59] <kierank> i don't think the eu will allow countries to fudge the economic restrictions any more ;) [11:08:08] <kierank> restrictions for entry that is [11:08:08] <kshishkov> pJok: GCC stuff, of course. Ukraine is actively maintaining status quo [11:08:10] <BastyCDGS> why, you're just accessing one of 1024*8 per plane i.e. per inner loop [11:08:23] <BastyCDGS> i.e. 8K per plane [11:08:36] <BastyCDGS> but of course it should be discussed if it's worth having a 256K table [11:08:44] <mru> but every image has all planes [11:08:50] <mru> so you need to load the entire table [11:08:57] <mru> it's not worth it [11:09:26] <pJok> av500, unlike greece i think that ukranians actually know how to do an honest days work [11:09:41] <mru> that table is big enough to blow L2 on many chips [11:09:46] <pJok> i laughed when i heard that the retirement age in greece was 50... [11:09:52] <mru> wtf? [11:09:57] <mru> 50, seriously? [11:10:00] <pJok> yeah [11:10:05] <pJok> no wonder they are going bankrupt [11:10:06] <mru> no wonder they're in trouble [11:10:42] <av500> its not 50 [11:11:29] <mru> BastyCDGS: can you make the table entries 32-bit instead? [11:11:42] <mru> read one byte at a time from the input [11:11:48] <pJok> av500, there was something about that on the news... and they said 50 [11:11:51] <mru> then shift, mask, and index twice [11:12:18] <mru> http://news.bbc.co.uk/1/hi/world/europe/8506142.stm [11:12:18] <pJok> not that i trust the news these days [11:12:26] <mru> "The socialist government said it wanted to increase the average retirement age from 61 to 63 by 2015." [11:12:30] <av500> pJok: http://aleksandreia.wordpress.com/2010/03/08/greek-retirement-age-and-more-… [11:12:35] <BastyCDGS> mru! [11:12:38] <BastyCDGS> I got it! [11:12:47] <BastyCDGS> speedup of 230% [11:12:53] <BastyCDGS> with Ooze [11:12:59] <mru> I don't trust your benchmarks [11:13:16] <BastyCDGS> from 45k to 22k [11:13:55] <mru> you need to measure the decoding time for the entire image, not one line [11:14:13] <pJok> av500, so noone really knows the retirement age in greece... [11:14:26] <av500> pJok: some ppl may retire at 58 -> all ppl retire at 58 -> 58 is in the 50ies -> all greek retire at 50.., [11:14:35] <av500> thats how news works these days [11:14:50] <mru> av500: and 58 was entirely made up to begin with [11:14:57] <av500> mru: yup [11:15:11] <mru> http://dilbert.com/fast/2010-05-05/ [11:16:45] <BastyCDGS> mru the speed calculation is averaged by 8192 runs that is quite accurate [11:16:59] <BastyCDGS> but a whole image test would be nice too [11:17:17] <kierank> do you know how much time that function takes in decoding an image BastyCDGS? [11:17:55] <BastyCDGS> the other stuff is just memcpy or byterun1 decoding of one line [11:18:00] <BastyCDGS> and a memset 0 of it before [11:20:17] <BastyCDGS> mru, I just was completely reading my mail I was comparing speed with current version not with my first optimization [11:20:30] <BastyCDGS> but still, from my first optimization its 30k [11:20:32] <BastyCDGS> now its 22k [11:21:00] <BastyCDGS> but the question is right, if that is worth a 256K table [11:22:10] <mru> do a 32-bit table [11:22:14] <mru> it may well be faster [11:22:42] <BastyCDGS> with 32-bit I have to >> 4 and &15 but it probably won't be much slower [11:22:46] <BastyCDGS> I'll just try [11:23:09] <mru> a shift and a mask is much faster than a cache miss [11:24:06] <BastyCDGS> yes [11:25:13] <mru> almost everything you thought you knew from the amiga is wrong on modern systems [11:27:58] <kshishkov> you should've started with VAX insted ;) [11:28:28] <BastyCDGS> mru, 18k with 32 bit [11:28:40] <BastyCDGS> but didn't add the shift & and stuff yet [11:28:47] <mru> eh? [11:28:55] <mru> benchmarking incorrect code is pointless [11:29:19] <BastyCDGS> I just replaced 64 bit stuff by 32 bit and duplicated AV calls [11:29:36] <BastyCDGS> and that shows that the 32-bit approach is faster [11:29:46] <mru> not necessarily [11:30:05] <mru> what machine are you running this on btw? [11:30:20] <BastyCDGS> AMD athlon XP 2100 [11:30:32] <mru> how much cache does that have? [11:31:26] <BastyCDGS> L1: 64K, L2: 256K [11:31:43] <KotH> that's a 5y old machine... [11:31:53] <mru> then you should see some difference [11:32:29] <KotH> BastyCDGS: and i thought, i had an old box at home :) [11:32:47] <BastyCDGS> KotH, the machine is just fine for me ;) [11:32:57] <BastyCDGS> what do you have? [11:33:55] <KotH> Athlon 64 3700 (2.2GHz) [11:36:49] <BastyCDGS> mru, when I add shifting and masking I get 30k [11:36:58] <BastyCDGS> sth. 29k as well [11:37:16] <mru> as I said, I don't trust your benchmarking method [11:39:05] <BastyCDGS> anway, why? just because the result doesn't fit your expectations? [11:39:17] <mru> because you're doing it wrong [11:40:20] <BastyCDGS> I'm benchmarking the stuff I'm changing [11:40:33] <mru> you think you are [11:41:26] <BastyCDGS> dp32 isn't inlined [11:41:27] <KotH> mru: you should tune down your tone a bit [11:41:36] <KotH> mru: you aren't helping your case talking like this [11:41:36] <BastyCDGS> if that's what you mean [11:41:46] <mru> that's not what I mean [11:42:00] <mru> you need to measure the full decoding time [11:42:25] <mru> that's especially important when dealing with cache effects [11:43:11] <BastyCDGS> but it does measure the full decoding...that's why it's called 8100 times [11:43:37] <mru> you're measuring individual lines [11:45:53] <BastyCDGS> mru, do we agree that the outer loops are neglictible to the inner loop? [11:46:06] <mru> that's not the issue [11:46:46] <mru> if the inner loop blows the L1$, something entirely innocent-looking might start taking significant amounts of time [11:47:52] <BastyCDGS> 8K per plane, therefore the cache gets full after 8 planes (if it's 64K), since L1 is used for different stuff too, I calc with 7 planes [11:48:05] <BastyCDGS> given a 24bpp image, the cache is 3-4x flushed [11:48:39] <BastyCDGS> and yes the measure detects that, the first runs are way over 100k [11:50:54] <mru> but you're not measuring the effects of chucking out everything that was in the cache before the loop [11:51:02] <KotH> BastyCDGS: you dont have a fully associative cache [11:51:40] <mru> wouldn't help if he did [11:52:03] <mru> with LRU replacement he'd still lose everything that was there [11:52:06] <KotH> BastyCDGS: you can only guesstimate what the cache behaviour is in simple programs... anything that is bigger is nearly impossible to know in advance [11:52:10] <kierank> this conversation is getting painful to watch [11:52:19] <mru> and random replacement is quite common too [11:52:21] <KotH> kierank: then dont watch [11:54:13] <BastyCDGS> mru, what do you think about creating the 256K table in decode_init with malloc and then filling it there? [11:54:30] <BastyCDGS> av_malloc of course ;) [11:54:32] <mru> that will obviously not make any difference [11:54:45] <BastyCDGS> I meant not because of speed but library size [11:54:54] <mru> separate discussion [11:55:32] <BastyCDGS> but maybe, filling it by hand will fill L2, too. so it might give a speed impact but hard to say which one [11:55:45] <KotH> kierank: if you want to watch something, i suggest you watch "kamen no maid guy" :) [11:55:47] <mru> go read about caches [11:55:55] <KotH> mru: uhmm.. [11:56:03] <KotH> mru: there are no good texts on cache behaviour [11:56:07] <BastyCDGS> writing values will fill the caches [11:56:17] <funman> BastyCDGS: there is a CONFIG_SMALL define already, perhaps you could use that [11:56:28] <mru> KotH: hmm, I don't recall reading much about them either... [11:56:28] <KotH> mru: not even H&P covers anything more recent than a P-II [11:56:44] <mru> nothing fundamental has changed since then [11:56:52] <KotH> nope [11:57:05] <BastyCDGS> the optimization manual I posted quite a time here has lots of text about cache opts [11:57:05] <KotH> just that we do not have a two level cache, but a three level [11:57:16] <mru> that's not a fundamental difference [11:57:24] <KotH> the delay difference between L1 and DRAM grow by one or two magnitudes [11:57:34] <BastyCDGS> http://www.agner.org/optimize/ [11:57:36] <mru> that's why L2 and even L3 are important now [11:58:15] <KotH> and cache behaviour has become a major bottleneck while in P-II times the CPU contributed to a larger portion of the processing time [11:58:38] <mru> the basic operating principles of the caches are still the same [11:58:45] <mru> fancy prefetchers aside [11:58:58] <KotH> IIRC H&P only mentiones caches, explains how they work, but does not discuss the impact of caches to programming and optimization [11:58:59] <BastyCDGS> funman, thank you for the advice regarding CONFIG_SMALL [11:59:15] <mru> BastyCDGS: leave that for later [11:59:54] <BastyCDGS> KotH the link I posted does cover impact of caches to programming, both asm and C/C++ [12:00:23] <mru> then there are three alternatives [12:00:29] <mru> 1) you are wrong and it doesn't [12:00:32] <mru> 2) you didn't read it [12:00:36] <mru> 3) you didn't understand it [12:02:06] <KotH> BastyCDGS: it hardly touches the issues around caches [12:02:18] <funman> Would you be interested by a piece of ARM asm code from rockbox for the flac decoder? [12:02:31] <KotH> BastyCDGS: it tells you things that were true (ok, still are) 10y ago.. today it's a lot more complex [12:02:35] <funman> it's slower than C, but it's assembly, so it's better right? [12:02:53] <BastyCDGS> KotH the optimization manual deals anything up to Core2Duo [12:02:55] <KotH> funman: give it to mru, he'll make it 3 times as fast [12:02:58] <KotH> ;) [12:03:14] <spaam> KotH: only 3 times? :O [12:03:32] <funman> it's armv4 so i'm not sure he's interested [12:03:42] <KotH> BastyCDGS: i just skimmed over optimizing_cpp.pdf... it doesnt explain anything of the more complex issues [12:03:59] <funman> http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libffmpegFLAC/arm.S?vie… [12:04:22] <mru> those docs are heavily focused on x86 stuff [12:04:25] <KotH> BastyCDGS: cache/memory behaviour is something really hard to predict and you have to think yourself trough a lot of cases to grasp what's going on [12:04:36] <mru> it sounds like you need to understand better how caches work in general [12:04:42] <KotH> BastyCDGS: it's not something that can be explained in a few pages of lengthy text like that [12:04:53] <mru> things like associativity and replacement policy [12:05:00] <KotH> BastyCDGS: at least not if it's so basic level like this one [12:05:25] <BastyCDGS> I didn't say it's full comprehensive and will explain all, but anyway it's a good lecture to start with [12:05:47] <funman> it replaces this loop: http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/flacdec.c;hb=HEAD#l389 [12:05:50] <BastyCDGS> I just said that it covers cache programming, not more not less [12:06:13] <KotH> s/cover/mention/ [12:06:21] <mru> funman: the bps > 16 one? [12:06:38] <KotH> BastyCDGS: do you own a copy of H&P ?$ [12:06:50] <BastyCDGS> no I don't [12:07:01] <funman> yes, although the condition in rockbox is different but i can't tell why [12:07:21] <KotH> BastyCDGS: get one [12:07:59] <BastyCDGS> btw, I should mention the speed of my RAM here too, not the processor only ;) [12:08:00] <KotH> BastyCDGS: it might sound stupid, but H&P covers all the basic stuff you need to know about most topics relevant in programming of fast code [12:08:04] <BastyCDGS> it's 333MHz DDR1 [12:08:06] <mru> funman: why the fuck do they care about bpp>16? [12:08:23] <BastyCDGS> mru, I use flacs with bpp > 16 ;) [12:08:32] <funman> what's wrong with that? [12:08:33] <mru> BastyCDGS: not on a hacked ipod [12:08:45] <KotH> BastyCDGS: sadly, H&P doesnt go much into multiprocessor systems [12:08:46] <mru> that said, gcc does some pretty grim things with the <=16 part too [12:09:00] <mru> but flac decoding is so blazingly fast I can't be bothered to dig into it [12:09:19] <BastyCDGS> KotH, do you have a PDF? [12:09:38] <kierank> lol [12:10:10] <KotH> BastyCDGS: no [12:10:19] <KotH> BastyCDGS: but i'm quite sure you can find one on the net [12:10:27] <KotH> BastyCDGS: though, this is a book worth to buy [12:10:37] <BastyCDGS> what's the full name of the book? [12:11:02] <funman> mru: if we only supported widespread files, we wouldn't have an atrac decoder! [12:11:23] <mru> funman: I didn't say not to support them at all [12:11:26] <KotH> BastyCDGS: computer architecture a quantitative approach [12:11:27] <kshishkov> funman: but it's a Sony! [12:11:42] <KotH> BastyCDGS: or The Hennesy And Patterson for short [12:11:47] <mru> but since the hw is incapable of reproducing >16 bits anyway, you might as well convert them before loading them on the ipod [12:12:58] <funman> depends 'the hw' [12:13:27] <funman> there are some rockboxed players which have a spdif output [12:13:30] <mru> show me a device capable of >16-bit output that's too slow to run that code [12:14:55] <funman> clearly speed isn't a problem here so i'm wondering why the asm was made here (perhaps just for the dev to have fun) [12:15:46] <mru> I looked at that code some time ago [12:16:06] <mru> I didn't manage to achive enough speedup to justify the asm [12:17:30] <BastyCDGS> funman, is CONFIG_SMALL intended for code size or memory size or both? [12:17:48] <mru> don't worry about config_small for now [12:18:00] <funman> hum i'm reading it wrong it replaces the 16bps loop only [12:18:07] <BastyCDGS> I ask because I want to know if I should use no 256K table at all when CONFIG_SMALL is used or differ between malloc and static const [12:18:17] <funman> but there's coldfire asm for the other one [12:18:28] <BastyCDGS> coldfire? nice...modern m68k ;) [12:18:45] <mru> I'm saying you should almost certainly not have a 256k table at all [12:19:29] <funman> BastyCDGS: code size is in memory anyway [12:19:36] <funman> -size [12:23:42] <funman> BastyCDGS: so it's for memory (code+data), not storage. If the table has the same size if you generate it at runtime or not, then just make it static (storage is cheap) [12:24:48] <BastyCDGS> mru, maybe you missed that, but in the 256k table the elements are usually accessed nearby, except when plane jumps [12:28:27] <kierank> Why does this function overwrite the register it's meant to be preserving on the stack: http://pastebin.org/217577 ? [12:28:47] <kierank> effectively overwrite the register that is [12:29:26] <mru> BastyCDGS: two words: replacement policy [12:38:42] <BastyCDGS> mru, good news for you, I dropped the 256k table [12:38:49] <BastyCDGS> and rearranged some stuff based on the old dp32 opt [12:38:53] <BastyCDGS> now I have 24k [12:39:09] <BastyCDGS> I think that's good enough to sacrify the 256k table (which just gets 22k) [12:41:01] <BastyCDGS> http://pastebin.org/217641 [12:41:48] <mru> but you're still not doing the benchmarks properly [12:42:57] <mru> and what's with the local array? [12:44:12] <BastyCDGS> do you think it's better to use the lut directly? [12:49:16] <mru> depends on why you did it like that [12:49:34] <mru> what does the table definition look like? [12:50:07] <BastyCDGS> const uint32_t *lut[4] = {plane32_lut[plane][0], [12:50:07] <BastyCDGS> plane32_lut[plane][1], [12:50:07] <BastyCDGS> plane32_lut[plane][2], [12:50:07] <BastyCDGS> plane32_lut[plane][3]}; [12:50:21] <mru> that's what you pasted, yes [12:50:30] <mru> not what I asked [12:50:48] <BastyCDGS> damn that's great! 17K [12:51:22] <mru> ? [12:52:04] <funman> 17K? that's cold [12:52:14] <BastyCDGS> http://pastebin.org/217681 [12:52:32] <BastyCDGS> changing this to this pastebin was a jump from 25k to 17k dezicycles [12:53:08] <av500> KotH: for unknown reasons my company decided to buy that book.... [12:53:21] <mru> BastyCDGS: what does the table definition look like? [12:53:39] <mru> you obviously changed it between those pastes [12:53:54] <mru> it's impossible for both of those to compile [12:53:57] <BastyCDGS> current: [12:53:58] <BastyCDGS> static const uint32_t plane32_lut[32][16*8] = { [12:54:30] <BastyCDGS> old: [12:54:30] <BastyCDGS> static const uint32_t plane32_lut[24][4][16] = { [12:54:50] <BastyCDGS> the 24 here was changed to 32 (just copied that from patch file) [12:55:16] <mru> why did 4 turn into 8? [12:55:47] <BastyCDGS> because the old code used get_bits(&gb,4); [12:56:55] <BastyCDGS> new table size is 16K [12:58:49] <BastyCDGS> lol, mru, I see my fault it's not necessary ;) [13:03:21] <KotH> av500: hmm? [13:03:31] <KotH> av500: H&P isnt much worth for a reference book [13:03:38] <av500> I did not care [13:03:40] <av500> it was cheap [13:04:43] <av500> and I did not order any books this month :) [13:11:16] <BastyCDGS> mru [13:11:19] <BastyCDGS> the final code: [13:11:19] <BastyCDGS> http://pastebin.org/217726 [13:11:21] <BastyCDGS> works [13:11:24] <BastyCDGS> 18k dezicycles [13:12:13] <BastyCDGS> sry this one: [13:12:13] <BastyCDGS> http://pastebin.org/217733 [13:12:42] * mru -> airport [13:13:16] <BastyCDGS> where you going to fly too? to the moon to watch the back side and check if gcc works then? :D [13:13:37] <BastyCDGS> do you see further possibilities for optimize? [13:17:52] <Tjoppen> won't that segfault on line 42 if *buf >= 8? [13:18:08] <Tjoppen> *43 [13:18:48] <BastyCDGS> the offset is 0-63 [13:19:23] <Tjoppen> .. ah, right [13:19:28] <BastyCDGS> since I'm shifting << 2 it's 0 <= 0x3C at maximum [13:19:42] <Tjoppen> I was looking at the size of the first dimension (32) [13:19:57] <BastyCDGS> I just tried it Ooze.iff decodes fine ;) [13:20:46] <Tjoppen> ah, and lowest two bits are always zero. fair enough [13:26:58] <BastyCDGS> patch submitted to ML [13:27:02] * mru @ airport [13:27:09] <av500> mru: no ash cloud? [13:27:10] <BastyCDGS> lol [13:27:48] <BastyCDGS> are you going to the monks, mru? was I that terrible? [13:28:04] <mru> FRA [13:28:23] <BastyCDGS> FRA? [13:28:25] <BastyCDGS> france? [13:28:48] <wbs> fÃ¶rsvarets radioanstalt? ;P [13:30:06] <kierank> could be frankfurt [13:30:21] <av500> its the right 3 letter code... [13:30:43] <BastyCDGS> in sports 3 letter code for france is FRA, too... [13:30:55] <av500> he flies, not runs [13:31:01] <funman> who would want to go to france? [13:31:36] <pJok> FRA logs everything in here [13:34:00] <mru> through security... [13:34:36] * kshishkov knows where mru is heading to [13:34:47] <BastyCDGS> and where? [13:34:55] <kshishkov> Frankfurt [13:35:06] <BastyCDGS> why? [13:37:33] <mru> BEEEEER!! [13:38:54] <Tjoppen> öl \o/ [13:39:05] <BastyCDGS> hint: Erdinger Hefeweizen ;) [13:39:37] <Tjoppen> weihenstephaner [13:40:00] <BBB> BastyCDGS: decodeplane32() looks good [13:40:31] <av500> BastyCDGS: erdinger??? you have no taste [13:40:45] <av500> erdinger is the heinken of hefes [13:41:15] <mru> ack [13:42:29] <BBB> BastyCDGS: unsigned/signed is irrelevant, we're reading from a bitstream and believe me, bitstreams have no concept of signed/unsigned [13:42:32] <BBB> they have concept of bits [13:42:33] <BastyCDGS> well I know of no german which doesn't like erdinger...it's one of the favorite beers there [13:42:38] <BBB> if the bits are invalid, they are invalid [13:42:40] <BastyCDGS> but remember there are different erdingers [13:42:47] <BBB> whether you print them in signed or unsigned, they're crap either way [13:42:56] <BBB> it's like a fourcc [13:43:00] <BBB> you can print it as a fourcc [13:43:09] <BBB> but if it's invalid, it's probably something like ^d%$x [13:43:12] <BBB> if you're lucky [13:43:48] <av500> BBB: hey, thats a valid one! :) [13:44:06] <BBB> ^d? [13:44:08] <BBB> no it isn't [13:44:16] <av500> yes, klingon war codec [13:44:30] <BBB> ah, of course [13:44:41] <BBB> I thought that was \t%$x [13:44:48] <av500> yes, the draft one [13:45:01] <BBB> god damn these stupid klingons and their unusual integer counting [13:45:07] <av500> what became klingox 3.11 [13:46:38] <Tjoppen> bah. lavf and libmicrohttpd are not on speaking terms [13:48:38] <BBB> mru: decodeplane32() optimization ok? [13:50:33] <BastyCDGS> BBB, fixed width & height using avcodec [13:50:37] <BastyCDGS> check_dim [13:50:44] <BBB> good :) [13:50:50] <BBB> what made you think it doesn't check <=0? [13:50:59] <BastyCDGS> because somebody yesterday told me so [13:51:12] <BBB> if it were, I'd asked you to patch avcodec_check_dims() :) [13:51:20] <BBB> because w=0/h=0 is obviously a bug [13:51:37] <BastyCDGS> maybe it was fixed in the meantime? [13:51:44] <mru> no [13:52:41] <BastyCDGS> I thought you are sitting in the plane right now? ;) [13:52:53] <wbs> BastyCDGS: if you don't do it already, subscribe to cvslog, or refresh the list of commits at git.ffmpeg.org, you'd know that nothing such was modified between yesterday and now [13:53:16] <BastyCDGS> wbs, I know but didn't check today right now [13:55:49] <Tjoppen> bah, nbgit doesn't do blame [13:56:22] <Tjoppen> otherwise quite a nice plugin (for netbeans) [13:56:35] <mru> eeeew [13:58:46] * BBB wonders what mru "ehw"s about [13:58:55] <av500> the food on the plane [13:59:05] <av500> shepherds pie [13:59:15] <BBB> ugh [13:59:29] <kshishkov> ploughman's lunch :) [13:59:32] <BBB> if you fly cathay, they give you a delicious instant noodle after you wake up [13:59:43] <BBB> it's said to be the reason why all asians fly cathay [14:00:20] <av500> cathay is not the nicest asian carrier [14:00:34] <kshishkov> BBB: maybe he just reacted like that when hearing certain J*v* IDE name [14:00:35] <kierank> singapore airlines is supposedly good [14:00:38] <av500> yup [14:01:17] <av500> and coop noodles are cheap [14:01:20] <av500> err cup [14:01:29] <kshishkov> Ukrainian International Airlines are not good [14:02:44] <kshishkov> they'll give you some snacks from local store if your flight lasts for more than two hours [14:04:23] <Tjoppen> netbeans isn't that bad. it's better at parsing C++ than MSVC for instance [14:05:00] <BBB> singapore airlines is good [14:05:06] <BBB> but doesn't fly the route I want [14:05:28] <BBB> malaysian airlines is terrible :-p [14:07:21] <kshishkov> Tjoppen: ok, you've convinced me. I'll try surstromming next [14:07:41] <BBB> av500: hahahahhahahhaha :) [14:07:57] <BBB> av500: I pay a good $25-$30 for the best noodle you've ever had here in new york [14:08:12] <BBB> they are so delicious, people pay $30 and stand in line (reservations not allowed) for >2hrs [14:08:17] <av500> thats not the ones you get on a cathay flight [14:08:22] <BBB> good noodles are priceless :) [14:08:30] <BBB> I've been told cathay's noodle is quite good [14:08:55] <av500> good compared to nothing on a 15h flight, yes [14:09:00] <mru> korean air is good [14:09:33] <mru> 3 meal choices even in economy [14:09:44] <BastyCDGS> BBB, fixed the space ;) [14:09:47] <av500> beef, fish and surprise [14:09:58] <BBB> hm, good, I can probably apply that patch and the minor dp8 one then [14:09:59] <av500> beef is gone after 3 rows :) [14:10:04] <BBB> mru: dp3 ok to apply also? [14:10:10] <BBB> I want to work on getting the ham patch in [14:10:16] <av500> tasty ham [14:10:51] <mru> BBB: probably ok, haven't seen the final patch [14:11:28] <BastyCDGS> I will continue with HAM on wednesday ok? I have to do some math stuff, in 2 days the exams are [14:11:36] <BBB> sure [14:11:36] <BastyCDGS> have to learn some stochastics and linear algebra [14:11:51] <BBB> this patch is ok, will apply later today [14:12:14] <BastyCDGS> but what I would do right now as a very last...grayscale stuff [14:13:11] <mru> learn that stuff well, you'll be needing it [14:14:02] <BastyCDGS> you think I'll better START_TIMER/STOP_TIMER stuff then? ;) [14:15:04] <BastyCDGS> BBB, what's with palette underflow patch it seems to be okay to, at least nobody complained right now ;) [14:15:24] <BBB> I'll look at it [14:15:33] <BBB> have to do actual work also ;) [14:17:58] <BastyCDGS> oh wait, I see a problem with dp32 patch [14:17:59] <BastyCDGS> endianess [14:19:00] <BBB> rofl :) [14:19:14] <BBB> I hope you test this stuff on both le and be [14:19:41] * mru points at saracen [14:19:44] <wbs> it may be a good treat not to be so triggerhappy [14:20:05] * mru onboard [14:20:15] * mru out [14:20:56] <kshishkov> trevlig resan [14:22:42] <Tjoppen> kshishkov: hehe [14:23:31] * Tjoppen goes back to staring at wireshark's dumps [14:29:27] <BastyCDGS> hmm the #define LUT32 has now a width of 82 lines [14:30:01] <kshishkov> that's height [14:30:23] <BastyCDGS> I changed them to endian awareness which makes the lines twice as long [14:30:32] <BastyCDGS> AV_LE2ME32C(1 << plane), AV_LE2ME32C(1 << plane), AV_LE2ME32C(1 << plane), AV_LE2ME32C(1 << plane), \ [14:36:21] <BastyCDGS> you're right I was looking at lines sorry [14:36:27] <BastyCDGS> columns is over 100 [14:37:00] <BBB> make a second macro [14:37:33] <BBB> #define LUT32LINE(a,b,c,d) \ AV_LE2ME32C(a), \ \n AV_LE2ME32C(b), \ \n [etc] [14:37:42] <BBB> and then use LUT32LINE(0, 0, 0, 0), \ [14:38:06] <BBB> then indenting remains consistent and each line only gros 11 characters [14:38:11] <BBB> grows [14:51:00] <BastyCDGS> 72 cols now BBB ;) [14:56:27] <BastyCDGS> uhh [14:56:37] <BastyCDGS> it's wrong with the AV_LE2ME32C on be [14:59:08] <BastyCDGS> and correct without on be/le ;) [14:59:18] <BastyCDGS> so the patch should be fine as submitted to ML [15:27:38] <BBB> ok [15:31:21] <BastyCDGS> grayscale patch is almost finished [15:31:23] <BastyCDGS> just one minute [15:33:49] <BastyCDGS> submitted [16:06:51] <Tjoppen> how.. interesting [16:07:43] <Tjoppen> instead of getting somethihng like "GET /foo/bar" in for the first header line in libmicrohttpd, when lavf connects, I get lines like "c2" [16:08:16] <Tjoppen> no wonder the seeks fail [16:30:18] <Tjoppen> hah, I think I figured it out [16:31:41] <Tjoppen> looks like I need to patch the http protocol handler.. when it seeks chunksize needs to be reset [16:32:18] <peloverde> http://www.embedded.com/columns/technicalinsights/224701206?cid=RSSfeed_emb… [17:01:52] <CIA-7> ffmpeg: rbultje * r23080 /trunk/libavcodec/iff.c: [17:01:53] <CIA-7> ffmpeg: Ensure that width and height are > 0. avcodec_open() itself only checks that [17:01:53] <CIA-7> ffmpeg: they are >= 0. [17:01:53] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>. [17:18:59] <CIA-7> ffmpeg: rbultje * r23081 /trunk/libavcodec/iff.c: [17:18:59] <CIA-7> ffmpeg: Optimize decodeplane32(). [17:18:59] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>. [18:21:39] * janneg slaps ramiro with the there-is-no-libfaadbin_decoder-trout [18:36:26] <BBB> maybe I'm just being unclear on the mailinglist [18:36:28] <BBB> hmm... [18:36:44] <BBB> can anyone confirm my replies are unclear in that grayscale/iff thread? [19:01:28] <ramiro> ./configure --disable-filters && make --> ffmpeg.c:1664: undefined reference to `av_vsrc_buffer_add_frame' [19:02:23] <ramiro> mru: ^^ [19:02:32] <ramiro> janneg: ? [19:05:43] <KotH> BBB: do i have to read your replies first, or can i just confirm it? ;) [19:14:21] <BBB> you lazy bugger :) [19:19:15] <_av500_> BBB: what did you say? [19:42:18] <janneg> ramiro: ./configure --enable-gpl --enable-libfaad --enable-libfaadbin --disable-ffserver misses -ldl in extralibs [20:08:53] <ramiro> janneg: oooh, I finally understand it =) I was the one to introduce that, right? [20:16:51] <janneg> ramiro: yes, three years ago, so I don't think it's an urgent problem [20:17:26] <janneg> ramiro: patch sent to ml [21:17:03] <CIA-7> ffmpeg: reimar * r23082 /trunk/libavcodec/x86/h264dsp_mmx.c: [21:17:03] <CIA-7> ffmpeg: Replace more "m" constraints with MANGLE to fix compilation issues [21:17:03] <CIA-7> ffmpeg: with x86_32 gcc 4.4.4 and -fPIC. [22:21:56] <peloverde> "Howcast found that for some of its video transcoding, the video quality produced by the open-source application FFmpeg wasn't up to snuff." ouch http://news.idg.no/cw/art.cfm?id=8373D6CF-1A64-6A71-CE7AABF6DAB260F5 [23:52:47] <Compn> peloverde : ehe, good article, but i've never heard of 'howcast' [23:54:39] <Compn> lol [23:54:46] <Compn> howcast using ... facebook for video hosting [23:56:04] <Compn> oops, no its not [23:56:06] <Compn> damn facebook crap [23:57:52] <Compn> http://media.howcast.com/system/videos/6/28/03/328.flv [23:57:58] <Compn> uses lame at least

1 0

IRC log for 2010-05-09
by irc＠mansr.com 10 May '10

10 May '10

[00:17:57] * Compn trolls on Dark_Shikari's blog [00:18:24] <CIA-7> libswscale: mru * r31142 /trunk/libswscale/bfin/internal_bfin.S: [00:18:24] <CIA-7> libswscale: blackfin: fix yuv422 to yuv420 conversion [00:18:24] <CIA-7> libswscale: The old code is correct only when stride = 2*width. [00:18:24] <CIA-7> libswscale: Patch by Ronaldo Moura <ronaldo d moura monity com br> [00:18:58] <mru> who's "louise"? [00:20:55] <Compn> ? [00:21:07] <mru> commenter on Dark_Shikari's blog [00:21:23] <mru> is that your trolling alias? [00:21:52] <Compn> no [00:22:00] <Dark_Shikari> he trolled a previous post posting tons of shit about vp8 was amazing [00:22:04] <Dark_Shikari> and google must have put their best engineers on it [00:22:05] <Dark_Shikari> etc etc [00:22:09] <Dark_Shikari> and the post wasn't even remotely related to vp8 [00:22:13] <Dark_Shikari> so I just deleted it all [00:22:44] <Compn> i wonder how high ffmpeg devel posts rank on vp8 news [00:23:05] <mru> ffmpeg devs are ignored at large [00:23:18] <mru> except when monty gets pissed [00:24:17] <mru> wtf is jmkta? [00:24:20] <mru> and hhi? [00:24:41] <Dark_Shikari> JM-KTA is the baseline test platform [00:24:43] <Dark_Shikari> used for comparison [00:24:51] <Dark_Shikari> it's a modified version of JM with various post-H.264 features added [00:28:03] <mru> Dark_Shikari: btw, your blog colour scheme isn't very nice [00:28:19] <Dark_Shikari> is the background not dark enough? [00:28:37] <mru> but don't worry, I totally restyled it with Stylish [00:28:55] <mru> black text, light background, serif font [00:29:18] <Dark_Shikari> that is called "burning my eyes" [00:29:36] <Dark_Shikari> white background == staring at a bright light [00:29:46] <mru> well, light blue on navy background isn't exactly friendly [00:29:57] <Dark_Shikari> it's extremely light gray on dark navy [00:29:59] <Dark_Shikari> aka white on black [00:30:13] <Dark_Shikari> oh, also, just noticed a rather silly UI bug with ffmpeg [00:30:17] <Dark_Shikari> if you try to open a file that doesn't exist [00:30:17] <Dark_Shikari> it says [00:30:18] <Dark_Shikari> Error number -2 occurred [00:30:21] <mru> well, I prefer black on light grey [00:30:30] <mru> hehe [00:31:28] <drv> mine says "no such file or directory" [00:31:32] <drv> are you on windows perhaps? [00:31:44] <Dark_Shikari> yes [00:31:52] <Dark_Shikari> mingw build [00:32:02] <drv> i think some of the error -> string stuff was changed to use strerror [00:32:09] <Dark_Shikari> and mingw's strerror sucks probably [00:32:10] <drv> which probably is a stub/missing on mingw [00:32:54] <mru> s/strerror// [00:33:06] <drv> heh [00:37:01] <drv> hm, actually the MS CRT implements strerror, so maybe there is something else going on [00:37:16] <drv> i don't think it has strerror_r, that's probably it [00:39:18] <drv> looks like they have their own incompatible "safe" strerror_s() [00:52:35] <drv> ... which, for some reason, is not declared in the w32api headers [04:55:09] <ramiro> drv: try using mingw-w64. I'm starting to use it even for my 32-bit builds. (there's a catch though, you have to pass --extra-cflags=-Dstrtor=__strtod). [07:27:44] <siretart> ramiro: did win64 work in ffmpeg 0.5? [07:53:15] <Dark_Shikari> it never worked [10:26:53] <BastyCDGS> mru, are u here? [10:27:16] <mru> I am always here, and everywhere else [10:27:20] <mru> I am the omnitroll [10:27:40] <BastyCDGS> I was just looking again on the source line you've been looking yesterday evening in TuComposer [10:28:24] <BastyCDGS> where you wondered about that UWORD cast [10:28:30] <mru> on second thoughts, that cast is safe [10:28:34] <mru> but unnecessary [10:28:42] <BastyCDGS> it's reading from a byte [10:28:45] <BastyCDGS> signed byte [10:28:55] <BastyCDGS> but sign extending wasn't necessary beause of << 8 [10:28:59] <mru> yes, due to the range of values involved it's safe [10:29:07] <mru> so why use signed byte? [10:29:10] <BastyCDGS> this cast skips creating an ext.w instruction [10:29:12] <mru> and not unsigned? [10:29:15] <BastyCDGS> because samples are signed ;) [10:29:26] <mru> doesn't matter [10:29:34] <mru> your manipulating the value as unsigned [10:29:40] <mru> you're [10:30:04] <BastyCDGS> yes in that case I do it and that's why I use the cast [10:30:09] <mru> what matters is not what it is, but what you do with it [10:30:11] <BastyCDGS> it really creates faster code here on m68k [10:30:27] <mru> faster than declaring the pointer of the right type to begin with? [10:31:10] <BastyCDGS> samples are mostly processed really as signed [10:31:25] <BastyCDGS> this routine was an exception where a small part of it is really faster with threating it at unsigned [10:31:51] <mru> so declare the pointer that way there [10:33:20] <BastyCDGS> btw, what have you meant with undefined behaviour you said you were opening a random file and saw it? [10:33:41] <mru> conversion from unsigned to signed is potentially undefined [10:33:59] <mru> but in this case the value is always in the defined range [10:35:51] <BastyCDGS> you mean you can't be sure if a compiler decides to strip to MAX_INT if you converted a too large int to uint? [10:36:26] <mru> the C standard says conversion to signed int from a value out of range is undefined [10:36:40] <Vitor1001> BastyCDGS: do you read -cvslogs ML? [10:37:08] <BastyCDGS> no I don't Vitor, why? [10:37:15] <mru> you should [10:37:27] <Vitor1001> http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2010-May/029380.html [10:39:12] <mru> I think I see the problem [10:39:17] <mru> --x instead of x-- [10:40:40] <mru> yep [10:41:09] <mru> btw, that for loop is bad style [10:41:10] <BastyCDGS> oh there are problems [10:41:18] <mru> sorry I missed that in the review [10:42:55] <BastyCDGS> I see there are missing 8 bytes at the end [10:43:14] <BastyCDGS> so it's the loop just counting one to less [10:43:29] <mru> that's very bad style [10:43:45] <mru> avoid side-effects in the test expression of a for loop [10:44:34] <BastyCDGS> I did it because I saw it's 200 cycles faster because it doesn't have to compare the pointer (i.e. wait for add) [10:44:49] <BastyCDGS> question is if we change to x-- if it's still faster then [10:45:00] <mru> oh lord... [10:45:01] <BastyCDGS> maybe it's better to increment x by one before start of loop [10:45:05] <mru> NO [10:45:12] <mru> it doesn't fucking matter [10:45:23] <mru> the compiler will do the right thing [10:45:33] <mru> this is one of the rare things compilers do right [10:46:17] <BastyCDGS> should I do a fix now? [10:46:26] <BastyCDGS> or are u already doing this? [10:46:30] <mru> I'm sending an email [10:50:35] <BastyCDGS> just read your while loop patch [10:50:42] <BastyCDGS> what about using do ... while instead? [10:50:47] <mru> why? [10:51:05] <mru> the compiler will do the very same thing [10:51:15] <mru> it will use a decrement-and-test instruction of some sort [10:51:22] <mru> assuming the cpu has one [10:51:50] <BastyCDGS> I meant the initial jump into the loop, at least for does it, it makes a jump at the end of for loop and checks if the condition is true [10:52:13] <mru> you should spend more time disassembling compiled code [10:52:17] <BastyCDGS> since pixel width is rounded to nearest word (i.e. is at least 2 bytes) it should be ok [10:52:45] <mru> that's irrelevant [10:53:08] <mru> while (x--) { } and do { } while (--x) are mostly equivalent [10:53:13] <mru> when the initial value is non-zero [10:54:53] <BastyCDGS> yes that's why it's relevant that I stated that it's at least 2 bytes (and can therefore not initially be zero) [10:55:15] <mru> at least one would be good enough [10:55:25] <mru> and a zero-width image is invalid [10:55:56] <mru> you need to stop thinking in these terms [10:56:02] <mru> branches are fast nowadays [10:56:09] <mru> we have branch prediction [10:56:32] <mru> and compilers are pretty good at transforming loop control expressions to be efficient [10:56:55] <mru> at least when the loop control variables are not used within the loop [10:57:09] <BastyCDGS> btw, what is 10l? [10:57:14] <BastyCDGS> lol? [10:57:17] <mru> 10 liters [10:57:22] <mru> of something you don't like [10:57:37] <mru> it's the punishment for a silly mistake [10:57:38] * kierank pretends not to like beer [10:57:50] <mru> kierank: it doesn't work if you pretend [10:58:04] <mru> kierank: btw, aren't you british? [10:58:41] <kierank> yes. you have basty a 10l of something he doesn't like so when i get mine i'll pretend not to like beer [10:58:44] <kierank> gave* [10:58:56] <BastyCDGS> :D [10:59:06] <mru> pretending not to like beer is impossible for a brit [10:59:30] <kierank> that is true [10:59:32] <mru> unless it's that ghastly french "beer" [10:59:38] <kierank> or fosters [10:59:46] <mru> but then those are not beer [11:00:01] <mru> so not liking those isn't not liking beer [11:31:12] <Kovensky> <@mru> this is one of the rare things compilers do right <-- I didn't know they did stuff right :o [11:57:30] <BastyCDGS> oh error [11:57:38] <BastyCDGS> when I configure --disable-avfilter --disable-swscale I get: [11:58:09] <BastyCDGS> on linking: /home/basty/src/ffmpeg/cmdutils.c:614: undefined reference to sws_isSupportedOutput [11:58:09] <BastyCDGS> and /home/basty/src/ffmpeg/cmdutils.c:614: undefined reference to sws_isSupportedInput [12:03:42] <BastyCDGS> after fixing it manually I noticed it also won't build ffplay anymore [12:04:55] <mru> of course [12:04:58] <mru> ffplay needs it [12:05:38] <CIA-7> ffmpeg: mru * r23062 /trunk/cmdutils.c: Fix build with swscale disabled [12:05:59] <BastyCDGS> btw, is avfilter now enabled by default? [12:06:08] <BastyCDGS> noticed this because iff crashes with avfilter enabled [12:06:20] <BastyCDGS> but that's unrelated to my changes (the very old IFF crashed, too) [12:13:05] <_av500_> mru: ill update the patch for the other 2 bits tomorrow.. [12:13:17] <mru> are they needed? [12:13:27] <mru> those functions are always built [12:13:57] <_av500_> i have them in my private tree [12:14:05] <BastyCDGS> mru, I just noticed that the IFF demuxer doesn't check that width & height are != 0 actually [12:14:13] <_av500_> at least the bsf one i had to add, it would not build [12:14:39] <mru> that's odd [12:14:56] <mru> av_bitstream_filter_next() is in bitstream_filter.c [12:15:02] <mru> and that's built unconditionally [12:15:09] <_av500_> hmm [12:15:11] <mru> well, not if avcodec is disabled [12:15:14] <mru> but then nothing is built [12:15:16] <_av500_> i can check again tomorrow [12:34:24] <BastyCDGS> updated HAM patch submitted to ml [12:34:39] <BastyCDGS> mru, it seems you have forgotten to commit the bugfix while patch to git [12:40:06] <mru> no, I didn't forget [12:41:13] <BastyCDGS> are you waiting for reviews? [13:40:05] <mru> it's not my file, so I'm supposed to send a patch first [13:40:17] <mru> if nobody replies I'll probably just commit it anyway [13:41:53] <BastyCDGS> I just can confirm that it works with your patch ;) [13:42:04] <mru> I already checked that [14:38:38] <ramiro> siretart: what Dark_Shikari said. it's not a regression, it never fully worked. [15:21:34] <BastyCDGS> has someone investigated why ffplay crashes with --enable-avfilter configure with IFF stuff? [15:23:51] <Vitor1001> BastyCDGS: open a roundup ticket [15:24:20] <BastyCDGS> it was opened already quite a long time [15:24:26] <BastyCDGS> and I confirmed it already [15:27:30] <Vitor1001> I see [15:47:25] <BastyCDGS> hi jai :) [15:48:13] <BastyCDGS> do you want me removing the unused variable or can I keep the patch as is? [15:49:39] <jai> hi [15:49:52] <jai> i'd suggest removing the unused variable [15:50:18] <BastyCDGS> it is used exactly one time [15:50:26] <BastyCDGS> it starts only to become unused with the HAM patch [15:50:40] <BastyCDGS> since I'm removing the CODEC_ID_RAWVIDEO stuff [15:51:04] <BastyCDGS> are there any reasons, why it's better to remove it completely? [15:53:17] <jai> i dont see the point of keeping it around only in one place [15:54:48] <BastyCDGS> won't using st making the code a bit smaller, too? [15:54:57] <BastyCDGS> or does the compiler recognize [15:55:11] <BastyCDGS> that it's used multiple times and do a local storage automatically? [16:03:25] <BastyCDGS> just checked it, using st instead of s->streams[0] makes the asm code 16 bytes shorter [16:05:35] <kierank> it's pretty minor [16:06:10] <BastyCDGS> yes of course, but the source code also gets smaller, that's why I ask I should do it the other way [16:07:06] <jai> use whatever people find more readable :) [16:07:20] <jai> i dont see this making any significant speed impact [16:08:01] <BastyCDGS> it wasn't meant to be a speed patch more a size patch ;) [16:08:25] <BastyCDGS> but hard to say what's really more readable here [16:08:33] <BastyCDGS> st or s->stream[0]? [16:08:50] <BastyCDGS> I could of course change variable name st to stream [16:10:09] <BastyCDGS> after all st is used in iff_read_header too [16:10:15] <BastyCDGS> so the code looks more consistent, too. [16:10:56] <kierank> then do what's best and stop bikeshedding ;) [16:11:38] <BastyCDGS> kierank, since the patch is already there, I'm just waiting if it's ok so or if you really want me doing another patch doing it the other way [16:12:04] <BastyCDGS> or change st to stream... [16:24:27] <mru> dammit, I'm committing the iff fix [16:25:08] <BastyCDGS> mru, what's the problem? [16:25:24] <CIA-7> ffmpeg: mru * r23063 /trunk/libavcodec/iff.c: [16:25:24] <CIA-7> ffmpeg: IFF: decode last 8 pixels per line [16:25:24] <CIA-7> ffmpeg: The decodeplane8() function processes one byte of input less than [16:25:24] <CIA-7> ffmpeg: it should. Also, the for loop has an unusual style with side-effects [16:25:24] <CIA-7> ffmpeg: in the controlling expression; replaced with a more intuitive while [16:25:24] <CIA-7> ffmpeg: loop. [16:25:25] <CIA-7> ffmpeg: 10l to Basty. [16:25:26] <mru> nobody with authority to approve it replied [16:25:50] <mru> but it's trivial enough so I committed it anyway [16:26:07] <BastyCDGS> yes I also have doubts that someone will complain ;) [16:26:19] <mru> never underestimate michael [16:28:49] <BastyCDGS> just updated removal of bps patch to be applied to your dp8 fix patch [17:06:26] <CIA-7> ffmpeg: mru * r23064 /trunk/tests/fate.mak: FATE: update idroq-video-encode command [17:19:52] <BastyCDGS> mru, replacing the while with do while resulted in a speedup [17:19:52] <BastyCDGS> your patch with while: [17:19:52] <BastyCDGS> 9188 dezicycles in decodeplane8, 4095 runs, 1 skips [17:19:52] <BastyCDGS> my test with do ... while: [17:19:52] <BastyCDGS> 9073 dezicycles in decodeplane8, 4090 runs, 6 skips [17:20:15] <mru> is that statistically significant? [17:20:56] <BastyCDGS> it's 1% ;) [17:21:01] <mru> is that statistically significant? [17:21:21] <mru> what is the standard deviation? [17:23:05] <wbs> BastyCDGS: make sure that even if all valid files have a width > 0, you don't loop infinitely or crash or something if you'd get a file with width==0 [17:24:40] <BastyCDGS> well since buf_size is signed now, I could just do a check >= 0 [17:28:15] <BastyCDGS> mru, lol [17:28:20] <BastyCDGS> I just looked at disasm [17:28:40] <BastyCDGS> the normal while patch from you changes this not to a sub but to add [17:29:12] <BastyCDGS> i.e. gcc "optimizes" the sub 1 to add 1 [17:29:18] <mru> does it use that to index the array in the loop? [17:29:51] <mru> that could eliminate two adds inside the loop [17:30:02] <mru> so even with an explicit cmp you still save one insn [17:30:14] <BastyCDGS> nope [17:31:06] <mru> pastebin [17:36:32] <BastyCDGS> should I pastebin both? [17:43:32] <BastyCDGS> http://pastebin.org/213959 [17:43:52] <mru> feel free to change to a do while [17:43:59] <mru> but then you have to check the width first [17:44:07] <mru> actually, you should do that regardless [17:44:28] <BastyCDGS> yes, btw, height isn't checked, too... [17:44:40] <mru> then you should fix that as well [17:44:50] <BastyCDGS> as 2 separate patches, right? ;) [17:45:08] <mru> checking width and height can be the same patch [17:45:43] <mru> hmm, your bits_per_coded_sample handling is weird too [17:45:45] <BastyCDGS> that's clear, I meant the do while as 2nd patch [17:45:59] <mru> or are any values allowed there? [17:46:01] <BastyCDGS> huh? what you mean exactly? [17:46:02] <mru> like 23 [17:46:06] <mru> or 13 [17:46:07] <BastyCDGS> yes [17:46:12] <mru> ok [17:46:21] <BastyCDGS> anything from 1 to 32 [17:47:20] <BastyCDGS> btw, I wanted to change that to a do while quite a long time, but totally forgotten this because of HAM stuff ;) [17:47:32] <CIA-7> ffmpeg: mstorsjo * r23065 /trunk/tools/qt-faststart.c: qt-faststart: Avoid leaking memory if encountering a file with double ftyp atoms [19:55:24] <peloverde> Do most people "doing video stuff on linux" have the fluendo codecs? http://www.youtube.com/watch?v=YoYL4R3Te2s#t=41m30s [19:56:19] <elenril> lolwut? [19:56:39] <mru> don't know if I count, but I don't [19:57:04] <mru> in fact, I don't know _anyone_ who has the fluendo stuff [19:57:22] <peloverde> me neither, it struck me as odd [20:00:38] <mru> clearly a crackpot [20:01:24] <elenril> more like amateur troll [20:01:39] <mru> not a very good troll [20:02:07] <mru> a good troll states undeniable truths in a very annoying way [20:02:14] <elenril> there aren't that many good trolls [20:02:25] * elenril wonders if that's a good thing [20:02:37] <mru> I think it might be [20:02:44] <mru> but damn, trolling can be fun... [20:03:05] <spaam> mru: time for _troll_ ? [20:03:28] <CIA-7> ffmpeg: stefano * r23066 /trunk/libavfilter/avfilter.h: [20:03:28] <CIA-7> ffmpeg: Bump lavfi minor after the addition of the fields interlaced and [20:03:28] <CIA-7> ffmpeg: top_field_first in AVFilterPicRef, done in r23044. [20:07:08] <BastyCDGS> hey BBB :) [20:07:39] * mru watches fate slowly turn green [20:07:49] <drv> seasick? ;P [20:08:19] <CIA-7> ffmpeg: stefano * r23067 /trunk/doc/APIchanges: [20:08:19] <CIA-7> ffmpeg: Add entry for AVFilterPicRef interlaced and top_field_first fields [20:08:19] <CIA-7> ffmpeg: addition. [20:08:21] <mru> better than yellow fever [20:08:21] <BastyCDGS> seems to be ;) [20:08:25] <BBB> hola [20:08:37] <BBB> sorry for breaking fate yesterday [20:08:56] <BastyCDGS> this can happen, no thing to worry about [20:09:04] <CIA-7> ffmpeg: rbultje * r23068 /trunk/libavcodec/iff.c: [20:09:04] <CIA-7> ffmpeg: Remove "bps" parameter to decodeplane8/32(), it's unused. [20:09:04] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>. [20:09:07] <peloverde> We need 4.5.0 on x86_*/linux [20:11:37] <CIA-7> ffmpeg: rbultje * r23069 /trunk/libavformat/iff.c: [20:11:37] <CIA-7> ffmpeg: Replace usage of s->streams[0]->* with st->*, which is shorter. [20:11:37] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs basty googlemail com>. [20:11:56] <BBB> jai: you have a point about "just removing the variable" though, but I think in this particular case I agree that using st-> is simpler, I hope that's ok with you [20:12:52] <BastyCDGS> not only it's simply it's also shorter asm codew [20:12:54] <BastyCDGS> 16 bytes [20:14:45] <BBB> right [20:14:59] <BBB> note how this is not an inner loop so it's really irrelevant, but anyway [20:15:03] <BBB> :) [20:15:07] <BBB> ok, so now on to ham again [20:15:14] <BBB> extradata really shouldn't be a multiple of 512 [20:15:17] <BastyCDGS> there will be more st's anyway when ANIM comes in ;) [20:15:21] <BBB> it's bad habit to allocate more than needed [20:15:41] <BBB> the compiler/system will do that for you, and will do a better job depending on pagesize etc. [20:16:03] <BBB> (the compiler will pad, and the system will align ti pagesize) [20:16:06] <BastyCDGS> so how many bytes I should allocate extra? 64? [20:17:17] <wbs> that's easier for you to say than for us, try to think about what other options there are in these formats that you may need to communicate [20:17:49] <BastyCDGS> well since I plan to support, IFF-ACBM, IFF-ANIM, IFF-DEEP, etc. it could increment pretty fast [20:17:55] <BastyCDGS> currently it's 256 bytes [20:17:57] <BastyCDGS> with 1 KB [20:18:28] <Vitor1001> BastyCDGS: fate still looks failing IFF on big-endian... [20:19:06] <BastyCDGS> vitor, the last time I checked it with be it worked [20:19:10] <BastyCDGS> what's failing exactly? [20:19:12] <BBB> is iff/anim still the same format though? [20:19:25] <BastyCDGS> IFF-ANIM has a normal IFF-ILBM chunk for the first frame [20:19:49] <BastyCDGS> the following frames are DLTA instead BODY [20:19:52] <Vitor1001> Check FATE... [20:19:54] <BastyCDGS> with the new compression techniques [20:20:23] <BastyCDGS> what patches from me were you checking? [20:20:33] <Vitor1001> For ex.: http://fate.multimedia.cx/index.php?test_result=56715528 [20:20:37] <BBB> all of them :) [20:21:17] <BastyCDGS> you were using --enable-avfilter [20:21:20] <BastyCDGS> IFF crashes [20:21:29] <BastyCDGS> but the task already has assigned to somebody else [20:21:47] <Vitor1001> works fine for me for ffmpeg (not ffplay) [20:21:56] <BastyCDGS> also I have no glue what the problem should be, I literally have 0% experience with libavfilter [20:29:22] <BastyCDGS> BBB, ffmpeg runs fine on m68k [20:29:29] <BastyCDGS> ami_stuff uses it on m68k amigaos [20:30:01] <mru> emulated iirc [20:30:28] <mru> but there's no reason ffmpeg shouldn't work on m64k [20:30:28] <BBB> yeah, that's not real [20:30:29] <mru> 8 [20:30:34] <BastyCDGS> and where's the difference? if it runs on uae it runs on native amiga, too. [20:30:41] <BBB> and it's especially no reason to align data [20:30:46] <mru> only if the emulation is perfect [20:30:55] * mru points at codesourcery and qemu [20:30:57] <BastyCDGS> the 68000 is the only CPU where I know that this happens 100% [20:31:03] <BastyCDGS> there might be other, newer ones [20:31:13] <mru> no emulator is perfect [20:31:19] <mru> at least no realtime usable one [20:31:39] <BastyCDGS> WinUAE is 99,9% regarding CPU emulation, 2.x versions are even cycle-exact [20:31:51] <mru> I don't care what you claim [20:32:05] <wbs> BastyCDGS: yes, but still, you're using bytestream functions, they take care of unaligned reads/writes for you [20:32:16] <mru> they probably emulate well enough that correct code runs properly [20:32:25] <BastyCDGS> as said, there are other reasons I can't make the palette smaller than 768 bytes [20:32:41] <BBB> how big is the palette? [20:32:45] <BBB> is it always 768 bytes? [20:32:51] <BBB> can it be 0, 256 or 768? [20:32:51] <BastyCDGS> mru, then less than 5% of all amiga software (esp. games and demos) wouldn't run [20:32:54] <BBB> can it be 33 bytes? [20:33:02] <_av500_> 42? [20:33:05] <BastyCDGS> it's 768 for 256 colors [20:33:11] <mru> are you saying less than 5% of amiga software is correctly written? [20:33:20] <mru> I knew it was bad, but _that_ bad... [20:33:24] <CIA-7> ffmpeg: mru * r23070 /trunk/libavutil/bswap.h: bswap: 10L add missing parens around macro args [20:33:24] <BastyCDGS> yes it can be anything from 0-768 with a multiple of 3 [20:33:37] <BBB> how free is this "number of colors"? [20:33:40] <wbs> BastyCDGS: for the cases where data_size is smaller than one would expect, doesn't it work if one simply pads the size up to 768? [20:33:46] <BBB> and how does the decoder know what the number of colors is? [20:33:49] <BastyCDGS> mru, I'm talking of demos and games [20:34:01] <mru> they still need to be correct [20:34:02] <BastyCDGS> why do you think 99% of the old demos won't run on 68020 anymore or OS2.0+ [20:34:19] <mru> as in not doing stupid stuff that would cause cpu exceptions [20:34:33] <BastyCDGS> BBB, by extradata_size [20:34:41] <BastyCDGS> it divides it by 3 to get number of palette entries in CMAP [20:35:23] <BastyCDGS> mru, some demos/games even rely that 68000 throws exception on unaligned access [20:35:37] <BastyCDGS> they use this to jump into supervisor mode [20:35:40] <BastyCDGS> stupid I know [20:35:52] <mru> that's what caught codesourcery [20:36:00] <mru> qemu didn't emulate unaligned traps correctly [20:36:30] <mru> if you're only trying to execute well-behaved code as fast as possible, that's perfectly reasonable too [20:36:30] <BastyCDGS> wbs, the problem here is that the old decoder must conform with new demuxer and vice versa [20:36:52] <wbs> BastyCDGS: yes, but what harm would it do if you feed a larger cmap to the older decoder? [20:37:01] <wbs> you will just get a slightly larger palette with extra black items at the end [20:37:16] <wbs> which shouldn't affect the decoding of an image that just uses the earlier palette entries? [20:37:34] <BastyCDGS> this won't work since the older decoder reads these entries from the file [20:37:45] <BastyCDGS> if the CMAP chunk is the very last one it will break (trying reading after EOF) [20:37:52] <wbs> no it doesn't read it from file [20:37:56] <wbs> it reads it from extradata [20:38:11] <BastyCDGS> oh yes sorry was mixing it up with the RAWVIDEO stuff [20:38:20] <wbs> if you have a new demuxer which reads a too short cmap, but nevertheless pads the palette to 768 bytes [20:39:16] <wbs> so can we agree that in the decoder, you don't need to know the actual amount of palette entries set, when the demuxer adds a full palette in extradata? [20:40:37] <BastyCDGS> I know that I tried a lot of stuff before doing it the way as I did now [20:40:51] <wbs> that doesn't make it the only way things could work [20:40:55] <BastyCDGS> everything else I tried broke here or there [20:41:02] <wbs> cause the current proposal still has a lot of flaws [20:41:32] <BastyCDGS> the thing is that the old decoder checks the size of extradata [20:41:40] <BastyCDGS> and throws a palette underflow [20:41:52] <BastyCDGS> but doesn't handle palette overflow [20:41:58] <wbs> no, but it doesn't have to handle it either! [20:42:09] <wbs> you just get a few extra palette entries that won't ever be used [20:42:13] <BastyCDGS> it has, I get segfault otherwise [20:43:03] <BastyCDGS> the filling remaining with black was one of the very first things I tried [20:43:46] <wbs> this particular sample, sabre.iff, does it use HAM, or should it be decodable with the current decoder if it didn't have too short cmap data? [20:43:50] <BastyCDGS> believe me, I'm not happy with the current hack either [20:44:07] <BBB> I don't get it [20:44:10] <BBB> can you have 4 colors? [20:44:11] <BBB> or 7? [20:44:12] <BastyCDGS> it doesn't use HAM...it just has a shorter color map [20:44:15] <BBB> or only 2^n? [20:44:36] <BastyCDGS> IFF specs say that if the CMAP chunk has less entries than 1 << bps it has to be considered black [20:44:47] <BastyCDGS> if no CMAP at all fill with greyscale indices [20:45:04] <BastyCDGS> but be careful, when using HAM the image can still be color [20:46:32] <wbs> BastyCDGS: ok, so if sabre.iff can be decoded with the current decoder, would this work? http://pastebin.org/214566 [20:47:01] <wbs> or something similar, padding the extradata with extra black entries in the demuxer [20:49:27] <BastyCDGS> yes that should work [20:49:42] <BastyCDGS> the thing is only that the avformat can be changed independently of avcodec [20:49:51] <BastyCDGS> and still have to be compatible [20:49:59] <wbs> ... yes, i frickin know that [20:50:05] <BastyCDGS> also your patch does evaluate the * 3 and the && each loop iteration [20:50:29] <wbs> stop micro-optimizing everything, we're discussing high-level stuff here [20:50:43] <wbs> the question was, does this work or not [20:51:10] <BastyCDGS> as long as new decoder and new demuxer are the same, yes... [20:52:04] <wbs> so, since this works, it should work if we'd just adjust the demuxer to set a larger extradata, too, to include the full nominal size of the cmap data, even if the actual data read from file doesn't populate all of it, right? [20:53:33] <BastyCDGS> this will segfault if new demuxer doing this will meet old decoder... [20:53:41] <BastyCDGS> as said, old decoder doesn't handle overflow :( [20:53:52] <BastyCDGS> the thing is you can write only up to 1 << bps [20:54:03] <BastyCDGS> palette entries anything after it will segfault [20:54:04] <wbs> how on earth would it segfault? could you please describe that to me [20:54:06] <wbs> or stop bullshitting [20:54:25] <BastyCDGS> because ffmpeg just allocates 1 << avctx->bits_per_coded_sample entries? [20:54:28] <wbs> yes [20:54:45] <BastyCDGS> so if bps == 6 there are 64 color entries allocated [20:54:53] <wbs> yes, and extradata happens to contain 256 color entries [20:54:55] <BastyCDGS> the old decoder with your new demuxer would try to write 256... [20:55:06] <wbs> no it wouldn't [20:55:15] <wbs> it would try to read 64 color entries out of 256 and just ignore the rest [20:56:20] <BastyCDGS> just opened an old version, you seem be right [20:56:38] <wbs> yes, as a matter of fact, I happen to be very right on that account [20:57:34] <wbs> so can we all agree that the demuxer is completely allowed to return a full 256 color palette, even if the file actually contained much fewer colors? [20:57:46] <wbs> and doing it that way would solve sabre.iff without touching the current decoder [20:58:13] <BastyCDGS> ahh now I understand, you just want to fix sabre... [20:58:39] <wbs> no, I want you to get a sane way of passing the new extradata between demuxer and decoder [20:58:50] <wbs> but to even be able to discuss that with you, you need to realize these things first [20:58:56] <wbs> so you won't get hang up on them later [20:59:40] <wbs> and if we can fix sabre.iff with a small <5 lines patch now, it is MUCH easier to relate on how the new demuxer/decoder should behave, if we don't change 15 things of behaviour at once, but just fix ONE ISSUE AT A TIME [21:01:24] <BastyCDGS> but I'ld like to replace: [21:01:24] <BastyCDGS> i < count && i*3 < avctx->extradata_size [21:01:24] <BastyCDGS> with: [21:01:24] <BastyCDGS> count = FFMIN(avctx->extradata_size / 3, count); [21:01:24] <BastyCDGS> and keep the for loop as it [21:01:45] <BastyCDGS> as is [21:02:10] <wbs> yes, that's micro-optimizing stuff, I don't care about that now [21:03:34] <BastyCDGS> and if no CMAP is there, we fill in the grayscale map from demuxer ;) [21:04:47] <BastyCDGS> so we can fix that, too, without touching the decoder, really neat! [21:09:53] <wbs> so, then the new extradata parameter passing stuff, would boil down to this: [21:09:56] <wbs> http://pastebin.org/214654 [21:10:45] <wbs> so, if the cmap extradata happens to be shorter than expected, we just extend it to the full nominal size, and then append the new parameters at the end [21:11:02] <BBB> I think that's a logical approach [21:11:23] <wbs> and the new decoder can likewise check if the extradata happens to be longer than what the nominal size would be, and then parse out the parameters from there [21:11:38] <BBB> I think that's the ideal approach [21:11:58] <BBB> and as long as we keep the order of parameters fixed (and documented), we don't need padding of, say, 20 bytes [21:12:05] <BBB> we can just allocate nominal size + 5 now [21:12:09] <BBB> and fill in the 5 etxra bytes [21:12:18] <wbs> exactly, then we don't need to preallocate anything extra at all [21:12:32] <BBB> alloc, followed by realloc, is ugly btw [21:12:36] <BBB> but let's not get into that for now :) [21:13:03] <wbs> yeah, you can fix that in another way later if you want to, but this kept the pseudocode patch small :-) [21:13:25] <BastyCDGS> agree...sorry I didn't understand from the very first time [21:13:44] <BastyCDGS> should I separate the decoder FFMIN patch for palette? [21:13:57] <BastyCDGS> and the always maximum alloc of 768? [21:14:07] <wbs> one theoretical problem, though; an old demuxer reading an oversized cmap, would be interpreted as new-format extra parameters [21:14:10] <BBB> not 768 [21:14:24] <BBB> 3<<bps, right? [21:14:30] <wbs> no, that was just a theoretical mind-exercise leading up to the example solution above [21:14:31] <BBB> or 3<<(bps-1) [21:14:42] <wbs> but yeah, if you want to, you can do it in such steps [21:15:20] <wbs> i quite frankly don't care, as long as you end up with a sensible solution [21:15:30] <BastyCDGS> wbs, you mean an old decoder, instead old demuxer, right? [21:15:39] <BastyCDGS> Martin cares about this... [21:15:46] <BBB> martin = wbs :) [21:15:59] <BastyCDGS> oh...didn't know that [21:16:03] <BBB> and he means new decoder + old demuxer reading an oversized cmap chunk [21:16:07] <wbs> yeah [21:16:20] <BBB> and yeah, that's a bug and we don't care since people should simply update their decoder [21:16:23] <BBB> as long as it doesn't crash [21:16:26] <wbs> but that falls into the category "malformed input" imo [21:16:32] <BBB> right [21:17:16] <wbs> as long as proper data is handled properly with mismatched lavf/lavc versions (but doesn't crash with malformed data either), I don't think it's that big an issue if handling of fringe cases is a bit spotty [21:18:13] <wbs> we wouldn't want to build some really horrible contraption just to take care of that [21:19:25] <BBB> not for fringe formats at least [21:19:38] <_av500_> ffringe [21:19:44] <BBB> :) [21:19:46] <wbs> haha [21:20:05] <BBB> ok, keep the patches coming BastyCDGS, it's looking better than before and we'll get it in in a bit [21:20:15] <BBB> I applied 2, will apply more (probably) tomorrow [21:21:29] <BastyCDGS> http://pastebin.org/214703 [21:21:30] * BBB goes work a little more [21:21:32] <BastyCDGS> this patch ok? [21:22:20] <wbs> i'd say so [21:22:30] <BastyCDGS> why? [21:22:57] <wbs> uh, please reread what I said [21:22:58] <BBB> it results in uninitialized pal[] entries if count<2^n [21:23:09] <BBB> is there code that initializes them to b/w later? [21:23:21] <BastyCDGS> isn't the palette av_mallocz'd? [21:23:38] <BBB> right, but they shouldn't be 0x00000000 [21:24:11] <BastyCDGS> they should be 0 [21:24:13] <wbs> i meant "yes, i think that is ok, but it'd be good to wait for a comment from someone else, too" [21:24:24] <BBB> they should be (0xff*i/(1<<bps))*0x01010101 [21:24:24] <BastyCDGS> only if no CMAP at all [21:24:46] <BBB> hm, that's counterintuitive [21:24:53] <BastyCDGS> it's the IFF standard sorry [21:24:57] <wbs> BBB: that's the case we discussed earlier, if the file happened to contain a too small palette (since the image doesn't use the full palette), leaving the rest of them to 0 is ok [21:25:00] <BBB> ok, then it's fine [21:25:12] <BBB> maybe add a comment of 1 line that says that [21:25:17] <BBB> so people reading the code see that too [21:25:22] <BastyCDGS> it's better to do greyscaling in a separate patch, right? [21:25:27] <BBB> yes [21:25:42] <wbs> one issue per patch, yes [21:25:42] <BBB> add a 1-line comment and then the patch is ok [21:25:54] <BBB> I'll be back in a bit [21:27:04] <BastyCDGS> http://pastebin.org/214716 [21:27:08] <BastyCDGS> so updated [21:29:09] <BastyCDGS> submitted to ml [21:32:43] <wbs> i'm off to bed now, but if you get the parameter passing rewritten in the way outlined above, I think most people will be very much more willing to accept it [21:33:05] <BastyCDGS> okey then good night and nice dreams ;) [21:33:07] <BastyCDGS> and thank you [21:33:16] <BastyCDGS> I'll go to bed soon, too... [21:35:20] <wbs> you're welcome [21:36:16] <BastyCDGS> thank you again :) [21:56:54] <j-b> ramiro: ping. Do you know somehting about an ebp issue when Xcompiling to Win32? [21:58:45] <BastyCDGS> j-b are you compiling with enable-pic? [21:59:18] <j-b> BastyCDGS: no. [21:59:24] <BastyCDGS> hmm strange... [21:59:38] <j-b> ffmpeg configure tells me that ebp is not usable [21:59:53] <mru> configure does not lie [22:00:32] <j-b> mru: :) but mingw is buggy => hence question to Mr. ramiro [22:08:27] <ramiro> j-b: what kind of ebp issue? [22:09:04] <j-b> ramiro: when using mingw32-gcc 4.4.2, ffmpeg configure tells me ebp is unusable [22:09:15] <j-b> http://vlc.pastebin.com/tJhdZ6pv [22:09:35] <j-b> the relevant part of config.err ^^ [22:09:41] <j-b> and http://vlc.pastebin.com/5cYS6iKF is the result. [22:10:00] <j-b> ramiro: since I am a bit stupid, I prefer to ask before I prepare my next package :) [22:10:50] <ramiro> I get that too, and I just checked that it was available on 4.2 [22:11:19] <ramiro> it's something gcc related, I don't really know what makes gcc decide bp can't be used. [22:12:18] <mru> phase of the moon most likely [22:13:43] <j-b> ramiro: ok, many thanks [22:13:59] <ramiro> I'd really like to know why though... [22:14:00] <j-b> mru: impossible, that would mean that they would be good days [22:14:33] <j-b> ramiro: well, i am preparing libavcodec package for VLC 1.1.0 release, so I would prefer to avoid making too many mistakes... [22:15:51] <ramiro> j-b: I understand [22:15:56] <mru> j-b: it does the right thing only when the back side of the moon is visible [22:15:58] <ramiro> btw what --cpu do you use for x86? [22:16:08] <ramiro> I mean 32-bit x86 [22:16:24] <BastyCDGS> mru, lol [22:16:41] <j-b> ramiro: --cpu=i686 - [22:16:47] <BastyCDGS> so I have to travel in space and run gcc there? :D [22:16:49] <mru> j-b: try playing some pink floyd while compiling [22:16:51] <ramiro> mru: I'm sure you must know the real reasons why gcc does that, could you please at least point us to the right direction? [22:16:57] <mru> dark side of the moon might be good enough [22:17:01] <BastyCDGS> mru, I love pink floyd :) [22:17:09] <j-b> ramiro: --enable-cross-compile --target-os=mingw32 --arch=x86 --enable-memalign-hack --cpu=i686 is the relevant part [22:17:23] <BastyCDGS> shine on you crazy gcc might also be a good song from pulse ;) [22:17:36] <j-b> mru: I _was_ actually listening to this album... Where are you ? Behind my shoulder? [22:18:03] <BastyCDGS> he's telepathic ;) [22:18:23] <j-b> ramiro: and using SVN from a few days ago [22:19:12] <ramiro> j-b: a few days ago?! are you kidding us?! do you really expect help from us by using such an ancient version? [22:19:15] <ramiro> =) [22:20:19] <BastyCDGS> no he just travelled faster than light to moon to check if it works when he sees back side...so he travelled to past time at the same time :D [22:20:20] <j-b> ramiro: =) I prefer to use not the last 72hours ones, usually, so I can see regression complaints on the mailing list [22:56:55] <CIA-7> ffmpeg: stefano * r23071 /trunk/libavformat/nutdec.c: [22:56:55] <CIA-7> ffmpeg: Make the nut demuxer issue a more meaningful error message if it [22:56:55] <CIA-7> ffmpeg: cannot recognize the provided codec tag. [22:56:55] <CIA-7> ffmpeg: stefano * r23072 /trunk/ (libavformat/riff.c libavcodec/raw.c): [22:56:55] <CIA-7> ffmpeg: Add support to the Y411 codec tag, corresponding to the rawvideo pixel [22:56:56] <CIA-7> ffmpeg: format uyyvyy411. [22:56:57] <CIA-7> ffmpeg: The codec tag is referenced in fourcc.org. [23:05:38] <CIA-7> ffmpeg: stefano * r23073 /trunk/libavcodec/raw.c: [23:05:38] <CIA-7> ffmpeg: Make the codec tags for the yuvjXXX pixel formats the same as the [23:05:38] <CIA-7> ffmpeg: corresponding ones for the yuvXXX pixel formats. [23:05:38] <CIA-7> ffmpeg: stefano * r23074 /trunk/libavcodec/raw.c: (log message trimmed) [23:05:38] <CIA-7> ffmpeg: Add missing nut-specific codec tags for rawvideo pixel formats. [23:05:39] <CIA-7> ffmpeg: Add codec tags for the formats: [23:05:40] <CIA-7> ffmpeg: [15]BGR Packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb), big-endian [NOT in AVI] [23:05:40] <CIA-7> ffmpeg: [15]RGB Packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb), big-endian [NOT in AVI] [23:05:41] <CIA-7> ffmpeg: [16]BGR Packed RGB 5:6:5, 16bpp, (msb) 5R 6G 5B(lsb), big-endian [NOT in AVI] [23:05:41] <CIA-7> ffmpeg: [16]RGB Packed BGR 5:6:5, 16bpp, (msb) 5B 6G 5R(lsb), big-endian [NOT in AVI] [23:05:50] <CIA-7> ffmpeg: stefano * r23075 /trunk/libavcodec/raw.c: (log message trimmed) [23:05:50] <CIA-7> ffmpeg: Reorder nut specific codec tags and add a comment for marking them as [23:05:50] <CIA-7> ffmpeg: such. [23:05:50] <CIA-7> ffmpeg: Also put the [3][0][0][0] codec tag, mapped to rgb565le, in a special [23:05:51] <CIA-7> ffmpeg: section. It needs to be specified *after* the nut RGB[16] codec tag, [23:05:51] <CIA-7> ffmpeg: otherwise it will be used by default when encoding normal non-flipped [23:06:18] <CIA-7> ffmpeg: rgb565le, and will be decoded like a flipped format (see [23:22:21] <CIA-7> ffmpeg: cehoyos * r23076 /trunk/libavformat/riff.c: [23:22:21] <CIA-7> ffmpeg: Add FourCC MJPG for CODEC_ID_JPEGLS. [23:22:21] <CIA-7> ffmpeg: Patch by Francesco Lavra, francescolavra interfree it

1 0