[FFmpeg-devel-irc] IRC log for 2010-03-29

[irc at mansr.com]

[00:25:59] <DonDiego> what kind of machine is that where libmpeg2 is faster?
[00:32:57] <astrange> core 2 x86-64 (http://lowendmac.com/macbookpro/15in-macbook-pro-june-2007.html)
[00:35:32] * peloverde is excited that a student is interested in BSAC
[00:35:54] <DonDiego> what was bsac again?
[00:36:41] <DonDiego> and what are you working on these days? parametric stereo in aac?
[00:37:56] <peloverde> BSAC is AAC with an alternate entropy/quantization scheme
[00:38:09] <peloverde> And yes I'm working on PS decoding ATM
[00:39:36] <peloverde> BSAC is mainly used in T-DMB IIRC
[00:39:44] * Kovensky notices that faac can't do sbr or ps
[00:40:53] * Dark_Shikari notes that ff aac is worse than adpcm
[00:41:14] <Dark_Shikari> and thus we shouldn't be talking much about faac.
[00:41:48] <peloverde> faac isn't distributable
[00:41:57] * Kovensky also notices that flv supports ADPCM but the spec doesn't bother saying which ADPCM
[00:42:22] <astrange> read the lavf demuxer to find out which one
[00:42:34] <Dark_Shikari> adpcm_swf
[00:49:10] <peloverde> Also for no purposes should ffaacenc be considered a useful AAC encoder, it got merged as an artifact of the retarded way our source repositories are set up
[00:49:53] <Dark_Shikari> then disable it
[00:50:13] <Dark_Shikari> by the way, if I, say, got a $20k bounty to make it useful
[00:50:16] <astrange> ffdca is 3x faster than libdta on a random file
[00:50:20] <Dark_Shikari> would you be able to make it happen?
[00:51:09] <Dark_Shikari> or kostya
[00:53:06] <peloverde> Dark_Shikari, I could make something happen, it largely depends on if changes actually needed to be merged or howmuch I could get away with under the general doctrine of maintainer's prerogative
[00:53:36] <Dark_Shikari> suppose it was "do whatever you want, I don't care, as long it gets into ffmpeg"
[00:55:41] <peloverde> hmmm
[00:55:55] <DonDiego> astrange: quick tests with http://samples.ffmpeg.org/MPEG2/dothack2.mpg indicate that ffmpeg2 is faster than libmpeg2 on my g4
[00:55:59] <Dark_Shikari> Not saying I can get this for you, but I suspect there are those who would want it.
[00:56:09] <Dark_Shikari> and I may or may not end up talking to one throughout the course of my other business.
[00:56:20] <Dark_Shikari> so I'd like to know what the situation is, so I could tell them
[00:57:14] <DonDiego> gnite
[00:59:48] <peloverde> I have too many doubts about my ability to complete such a project
[01:00:03] <Dark_Shikari> what about kostya?
[01:00:10] <Dark_Shikari> also, I just found a noncompliance issue in ffmpeg  h264
[01:00:25] <peloverde> I don't know, you would have to talk to him yourself
[01:00:39] <Dark_Shikari> yeah, I'll ping him when he's on
[01:01:36] <mru> Dark_Shikari: another one?
[01:02:55] <Dark_Shikari> another?  what other
[01:03:15] <mru> one of the conformance tests has been failing forever
[01:03:21] <mru> never looked into why
[01:03:39] <Dark_Shikari> this one is made with x264
[01:03:41] <iive> peloverde: even the longest trip starts with one small step. If you know what should be done, then ...
[01:03:42] <Dark_Shikari> so it cannot possibly be that evil
[01:04:06] <Dark_Shikari> also, is abs(td) >> 1 equal to abs(td/2)?
[01:04:27] <iive> td=-1?
[01:04:35] <Dark_Shikari> if not, ffh264 and x264 are both wrong
[01:04:38] <Dark_Shikari> (unrelated issue)
[01:04:51] <Dark_Shikari> abs(-1) >> 1 = 0
[01:05:00] <Dark_Shikari> abs( -1 / 2 ) = 0
[01:05:14] <iive> are you sure -1/2=-1 ?
[01:05:18] <mru> yes
[01:05:34] <iive> hum, no -1>>==-1
[01:05:44] <mru> yes
[01:05:58] <mru> >> is not equivalent to / for negative numbers
[01:05:59] <Dark_Shikari> also, I think implicit weightb is wrong for mbaff.
[01:07:02] <iive> (-1>>1)==-1
[01:07:06] <mru> yes
[01:07:12] <astrange> abs(x)>>1 == abs(x/2) except for INT_MIN
[01:07:32] * mru should have said no a while ago
[01:07:41] <mru> -1/2 == 0
[01:07:53] <Dark_Shikari> ok, INT_MIN will never occur in this case.
[01:08:01] <mru> INT_MIN is evil
[01:08:12] <Dark_Shikari> we're having this really really really weird issue in x264
[01:08:20] <Dark_Shikari> slices + weightb + interlaced generates non-compliant output
[01:08:32] <Dark_Shikari> remove any one of the three, and it works
[01:08:39] <Dark_Shikari> I cannot imagine wtf is going
[01:08:41] <Dark_Shikari> *going on
[01:08:43] <mru> did you verify the stream with JM?
[01:08:48] <Dark_Shikari> That's what I'm using.
[01:08:59] <mru> oh, sorry
[01:09:05] <Dark_Shikari> I wouldn't imagine testing with anything else
[01:09:06] <mru> I thought you were still talking about ffh264
[01:09:14] <iive> in what sense it is non-compliant?
[01:09:24] <Dark_Shikari> iive: cmp x264_output.yuv jm_output.yuv fails
[01:10:06] <iive> x264 have yuv output :O
[01:10:23] <Dark_Shikari> --dump-yuv
[01:10:40] <iive> these are the reference frames, i guess.
[01:10:43] <Dark_Shikari> yes.
[01:10:50] <Dark_Shikari> used for exactly this purpose.
[01:11:26] <iive> is ffh264 decode output closer to jm, to x264 or neither?
[01:11:59] <Dark_Shikari> ffh264's problem is separate and much worse
[01:12:06] <Dark_Shikari> I just decided to test it while I was at it
[01:13:07] <iive> Dark_Shikari: test x264 without asm, too.
[01:14:35] <Dark_Shikari> asm doesn't fix it.  but you know what does?  using 1 slice in B-frames only, and using slices in all other frames.
[01:15:16] <iive> Dark_Shikari: have you compared frames, to see where the error appears in the picture?
[01:15:42] <Dark_Shikari> well I _know_ basically where the problem is
[01:15:44] <Dark_Shikari> it's in bipred blocks
[01:15:56] <Dark_Shikari> because, somehow, slicing is having an effect on weightb
[01:16:01] <Dark_Shikari> when it obviously shouldn't.
[01:16:10] <Dark_Shikari> (or, equally, slicing is somehow having no effect on weightb, when it should)
[01:16:49] <iive> btw, have h264 got spacial scalability in the standard?
[01:17:04] <iive> last time i checked there was no such thing.
[01:17:17] <Dark_Shikari> yes.  svc
[01:17:24] <Dark_Shikari> went in 3 years ago
[01:19:50] <iive> have it been used somewhere?
[01:20:15] <iive> broadcast, bd, x264?
[01:20:22] <Dark_Shikari> google chat
[01:21:05] <osaft> svc was one of the questions in my exam, a few weeks ago
[01:21:43] <astrange> oh, the google chat installer for os x creates ~/Library/QuickTime owned by root and breaks anything that tries to install afterwards
[01:26:01] <kierank> iive: before 3d came along there were plans to do 1080p50 with dvb using svc
[01:26:32] <iive> kierank: they should have gone with the 50fps
[01:28:15] <kierank> 50fps won't sell new tv subscriptions though; 3d will
[01:28:23] <kierank> oh and physical tvs as well
[01:30:09] <BBB___> hi spyfeng
[01:33:20] <iive> kierank: you mean existing hdtv can play 50fps? they'd better do.
[01:33:44] <kierank> the "HD ready 1080p" sticker iirc has 1080p50/60 support
[01:33:49] <iive> but I have really big doubts about stereoscopic tv.
[01:34:12] <kierank> sky people say sport looks v. good in 3d but i've never seen that before so i can't comment
[01:35:36] <CIA-1> ffmpeg: darkshikari * r22714 /trunk/ffpresets/ (6 files):
[01:35:36] <CIA-1> ffmpeg: Update x264 presets in line with latest x264 changes.
[01:35:36] <CIA-1> ffmpeg: Patch by Lou Logan.
[01:43:01] <iive> kierank: there are too many people who complain by the glasses. and other alternatives are no better.
[01:43:21] <pasteeater> Dark_Shikari: thanks for applying.
[01:43:25] <kierank> the polarised glasses aren't too bad iive
[01:43:46] <kierank> and the 1080i side by side standard isn't nice either
[01:44:48] <iive> if you are lucky enough to get polarised one :) still you should be careful what you use for lightning in the room.
[01:45:21] <kierank> the tv manufacturers who are selling shutter glasses at $200 each are smoking crack
[01:47:23] <iive> i have no ground to deny that fact.
[01:49:36] <iive> n8 ppl.
[02:51:13] <CIA-1> ffmpeg: lorenm * r22715 /trunk/libavcodec/bitstream.c:
[02:51:13] <CIA-1> ffmpeg: optimize init_vlc().
[02:51:13] <CIA-1> ffmpeg: Reduce worst case time from O(N^2) to O(N*log(N)).
[02:51:13] <CIA-1> ffmpeg: Speedup average case by a factor of 10 in ffv2 (total decoding speed +4-25%),
[02:51:13] <CIA-1> ffmpeg: factor of 1.3 in ffvhuff (total +0.5%),
[02:51:14] <CIA-1> ffmpeg: factor of 1.8 in indeo5 (total +1%),
[02:51:14] <CIA-1> ffmpeg: factor of 1.1 in mjpeg (total +0.1%).
[02:51:15] <CIA-1> ffmpeg: lorenm * r22716 /trunk/libavcodec/bitstream.c: indent
[03:34:28] <Compn> oooo
[03:34:33] <Compn> optimizing
[03:42:30] <peloverde> Does anyone have any advice on how to section off part of a project as a qual task?
[03:42:41] <Dark_Shikari> what project?
[03:42:42] <Dark_Shikari> bsac?
[03:43:07] <peloverde> yeah, bsac
[03:43:28] <Dark_Shikari> ideas, knowing NOTHING about bsac:
[03:43:33] <Dark_Shikari> 1) write the arithmetic coder
[03:44:07] <Dark_Shikari> 2) write whatever the core residual coder is (the eqivalent of decode_residual in h264)
[03:44:40] <Compn> is the bsac spec all there ?
[03:44:45] <Compn> i mean, nothing to reverse engineer ?
[03:44:58] <Compn> and the spec is mostly readable ?
[03:45:31] <peloverde> it's all there and mostly readable (it's mixed with a lot of irrelvent crap, kind of like ASP)
[03:46:11] <Compn> i'd say splitting the spec up would be a good half-qual task
[03:46:21] <Compn> at least it would prove if said student can read a spec ;)
[03:46:54] <Compn> i guess one cant really code a postfilter before the decoder is created
[03:47:19] <Compn> maybe a qual task would be to implement another aac subtype ?
[03:47:28] <Compn> which maybe simpler than bsac or whatnot
[03:48:47] <Compn> optimize some part of the aac decoder ?
[03:57:44] <Dark_Shikari> Compn: imo the qual task should represent part of the final task
[03:57:49] <Dark_Shikari> so the student feels he has accomplished part of his goal
[03:58:47] <peloverde> agreed
[03:59:03] <Dark_Shikari> also, IMO a qual task should be 1-3 days' work
[03:59:25] <Dark_Shikari> with the expectation that if the student completes it to a reasonable level of satisfaction, he is almost guaranteed the spot.
[04:05:14] <Compn> thats a good idea
[04:05:28] <Compn> whos going to split all those slots into qual tasks? :)
[04:05:44] <Dark_Shikari> the people responsible for each project
[04:20:56] <peloverde> Does arithmetic scalefactor/noise/intensity decoding seem reasonable?
[04:23:55] <Dark_Shikari> could you do it in 5 hours?
[04:27:11] <peloverde> If we said for the base layer, then yeah I think so
[04:28:06] <Dark_Shikari> then make that a task.
[04:28:13] <Dark_Shikari> and do it fast, deadline is approaching
[04:31:48] <peloverde> ok
[05:25:29] <thresh> mourning
[06:09:37] <_av500_> moaning
[06:09:57] <kshishkov> keinen guten morgen?
[06:10:33] <_av500_> i try to stick with the channel spirit
[06:10:55] <kshishkov> exorcise it instead
[06:13:38] <kshishkov> and for rants I do something like http://codecs.multimedia.cx/?p=272
[06:25:40] <superdump> morning
[06:30:51] <kshishkov> morrow
[07:47:24] <KotH> grüezi
[07:47:57] * elenril throws EENCODING at KotH 
[07:49:15] * KotH catches it and calls ~elenril()
[07:49:46] <astrange> http://pastebin.com/us39NDTJ per-codec defaults proposal
[07:50:09] <elenril> KotH: have you been writing in forbidden languages?
[07:50:44] <Dark_Shikari> astrange: the good: it fixes
[07:50:46] <Dark_Shikari> *fixes ffmpeg
[07:50:50] <Dark_Shikari> the bad: it doesn't fix other lavc apps
[07:50:55] <astrange> yeah
[07:51:11] <Dark_Shikari> But it's a possible solution for now.
[08:02:35] <KotH> elenril: i've been investigating new languages
[08:05:03] <superdump> astrange: what about -fpre?
[08:07:12] <astrange> hmm
[08:07:19] <Dark_Shikari> and what about windows?
[08:07:21] <astrange> fpre needs to be read after the defaults
[08:08:00] <astrange> what about windows?
[08:08:09] <Dark_Shikari> the fact that it doesn't have a /usr/share
[08:08:14] <Dark_Shikari> and thus won't load defaults automatically
[08:10:37] <astrange> if you just distribute an ffmpeg.exe it won't work, yeah
[08:10:44] <Dark_Shikari> not just that
[08:10:47] <Dark_Shikari> there is no way to autoload on windows
[08:10:59] <Dark_Shikari> afaik.
[08:11:22] <astrange>  you can search argv[0]+/ffpresets/
[08:11:35] <Dark_Shikari> does it do that?
[08:14:01] <astrange> no
[08:14:18] <astrange> the distributor could also set --datadir in configure and it'll look there, if that's possible
[08:20:43] <pengvado> argv[0] is a path on windows?
[08:21:13] <astrange> it would be nice if it was
[08:21:26] <kshishkov> argv[0] is program name as it was executed
[08:22:04] <astrange> pretend that was dirname(argv[0])
[08:24:03] <pengvado> not the point. argv[0] is whatever the user typed. if the program was invoked by the name of "ffmpeg", letting the shell search through $PATH, then argv[0] will contain "ffmpeg" and no directories.
[08:30:33] <astrange> problems: there should be defaults for muxers too, something wrong will happen if you put vcodec= in a video codec default
[08:31:16] <kshishkov> why? that would mean "you really don't want to use that codec"
[08:35:26] <Dark_Shikari> we have muxer defaults
[08:35:38] <Dark_Shikari> flv is mp3 for example
[08:35:46] <Dark_Shikari> or adpcm if no lame
[08:44:01] <saintd3v> ffaac 8-)
[08:44:53] <jai> if you are compressing pink noise, then yeah ;)
[08:45:16] <saintd3v> even then i would think it would fail horribly :P
[08:46:08] <kshishkov> no, that reminds me of a joke - "haircut machine for everybody! But all heads are different. Only before the first shave with it"
[08:47:05] <kshishkov> so you can reliably encode everything into pink noise with ffaacenc ;)
[08:48:48] <astrange> the default for mp4 is ffaac
[08:48:52] <astrange> it has valgrind warnings :/
[08:49:21] <saintd3v> why not mp3?
[08:50:05] <jai> the policy is native > external lib iirc
[08:51:14] <astrange> quicktime can't play mp3-in-mp4
[08:51:22] <astrange> and there isn't an mp3 encoder by default
[08:51:52] <kshishkov> can someone integrate Lame into FFmpeg? It's about right time
[08:52:11] <jai> seriously?
[08:52:15] <kshishkov> yes
[08:52:56] <superdump> i very much doubt that will happen
[08:53:02] <jai> if at all possible, that would still require trimming of the code
[08:53:09] <superdump> we could do it, but why bother
[08:53:23] <jai> converting the existing lame codebase to use fflibs
[08:54:31] <astrange> iirc helix is competitive with lame and much smaller
[08:55:13] <kshishkov> helix as "opensourcey project from Buffering Inc."?
[08:55:31] <astrange> yes
[08:55:47] <astrange> that doesn't mean integrate helix, but it means you can write a competitive encoder if you really feel like it
[08:57:48] <saintd3v> how about we all just work on making ffaac not suck?
[08:57:53] <jai> of course, but with lame around the motivation to do that is really low :)
[08:58:22] <saintd3v> rm -rf /lamedir
[08:58:32] <saintd3v> oops, well, onto ffaac
[08:58:38] <jai> alex is working on ffaacenc
[08:58:49] <saintd3v> yes i know
[08:59:30] <jai> also, other than "output sucks" are there any known bugs ?
[08:59:52] <jai> it does write a valid bitstream right?
[09:01:28] <kshishkov> it should
[11:40:42] <KotH> twnqx: ?
[12:54:08] <DonDiego> hrm
[12:54:15] <DonDiego> yuvi hasn't been online in ages..
[12:54:26] <CIA-1> ffmpeg: jai_menon * r22717 /trunk/libavcodec/tta.c: Cosmetics : add a space after ",".
[12:54:59] <kshishkov> last time you said that he shourly appeared and went offline again
[12:55:33] <kshishkov> *shortly
[12:59:31] * DonDiego conjures up yuvi again
[13:03:09] * KotH always knew that DonDiego is into black magic
[13:04:27] <justlooking_> argv[0] is a path on windows ? http://msdn.microsoft.com/en-us/library/aa364963(VS.85).aspx  http://www.google.co.uk/search?rlz=1C1CHMZ_en-GBGB340GB355&sourceid=chrome&ie=UTF-8&q=argv[0]+is+a+path+on+windows
[14:26:20] <nfl> Hi, could someone please apply my YOP patch?
[14:33:29] <nfl> superdump: well, could you recommend a qual task for me?
[14:33:54] <superdump> did you write a decoder for YOP?
[14:33:59] <superdump> what is that format like?
[14:34:18] <nfl> yes, decoder + demuxer
[14:35:48] <nfl> I didn't exactly write it though, modified an existing patch
[14:36:47] <superdump> ah, ok
[14:36:55] <superdump> what modifications did you have to make?
[14:37:41] <nfl> implemented seeking, changed o/p format from rgb24 to pal8, other minor corrections
[14:38:27] <merbzt> superdump: we could add g729 and g723.1 soc tasks also
[14:38:52] <superdump> merbzt: yup, sure
[14:39:40] <superdump> if we add those, nfl could maybe write a frame parser for one of those instead of amr-wb
[14:39:53] <merbzt> yes
[14:40:02] <merbzt> there is a g729 patch though
[14:40:12] <merbzt> and samples are scarse for g723.1
[14:40:43] <superdump> mmm
[14:40:53] <superdump> any reference code for g723.1?
[14:40:58] <merbzt> I have
[14:41:11] <merbzt> the IPP should be better though
[14:41:19] <merbzt> it has encoder for it
[14:41:23] <merbzt> me thinks
[14:55:08] <nfl> sorry abt that, i got cut off
[14:55:25] <nfl> merbzt: so can i have a look at the reference code?
[14:55:38] <merbzt> nfl: look at the IPP code
[14:55:48] <merbzt> I don't have the ref code at hand
[14:56:13] <nfl> IPP?
[14:56:34] <merbzt> http://software.intel.com/en-us/intel-ipp/
[14:57:08] <nfl> merbzt: thanks
[15:10:37] <BBB> you guys will write more speech decoders?
[15:10:40] <BBB> that's a good idea
[15:11:10] <merbzt> actually we need g723.1 and g729 encoders also
[15:11:18] <merbzt> to be feture complete
[15:11:26] <merbzt> *feature
[15:11:37] <pJok> how about a better ffaacenc? ;)
[15:11:39] <BBB> let's start with decoders :)
[15:12:02] <mru> aacenc is much more useful that speech decoders imo
[15:15:15] <BBB> then someone needs to add aacenc-related tasks to the wiki for gsoc
[15:15:16] <BBB> nobody did
[15:15:37] <mru> there's one problem: aacenc is way too big for gsoc
[15:20:49] <kshishkov> mru: you could've said that _two_ years ago
[15:21:31] <mru> I didn't know that then
[15:22:50] <kshishkov> well, three years ago some people didn't suspect that REing RV40 would take more time than till GSoC start
[15:23:24] <merbzt> hahaha, you are so gullible kostya :)
[15:24:12] <kshishkov> indeed
[15:24:18] <kshishkov> yet sometimes it works
[15:24:34] * kshishkov is not going to say anything about WVP2
[15:24:47] <merbzt> huhuhu
[15:24:57] * pJok coughs
[15:25:03] <pJok> D*CK
[15:26:31] <pJok> worth a shot
[15:26:39] <kshishkov> en and?
[15:26:43] <pJok> jau
[15:26:49] <kshishkov> eller gammel On2?
[15:27:08] <pJok> my first duck was TM2 afair
[15:27:15] <pJok> from FFVII
[15:27:51] <merbzt> gammal
[15:27:55] <pJok> i also made my first proper RE of a format and my first c++ program in borland c++ builder
[15:28:08] <pJok> the format i RE'd was the packed files
[15:28:17] <pJok> and i made a winzip like unpacker for it
[15:28:24] <kshishkov> merbzt: sounds like some cryptographer's name
[15:29:38] <merbzt> that's gamal
[15:29:56] <kshishkov> pJok: my blog started with an attempt to understand On2 TM2 decoder source
[15:30:48] <kierank> was the source code that bad?
[15:30:53] <pJok> kshishkov, i wasn't that advanced back then
[15:31:05] <pJok> now i just read source and puke if its unreadable ;)
[15:31:06] <kshishkov> kierank: of course
[15:33:26] <pJok> funny that i didn't turn out to be a programmer
[15:34:50] <kshishkov> I was not that advanced when C++ Builder was released
[15:35:03] <pJok> i was doing most my things in visual basic
[15:35:06] <pJok> and quickbasic
[15:35:19] <pJok> in fact, i started out doing my concept code in quickbasic and ported it to c++
[15:35:28] <kshishkov> that's the reason you've not turned into programmer
[15:35:34] <pJok> well
[15:35:42] <pJok> probably
[15:35:54] <pJok> that and i couldn't be bothered with actually doing useful stuff
[15:38:35] * kshishkov has not written any useful decoder so far
[16:16:38] <nfl> merbzt: by g729, you meant the existing g729 decoder is to be extended for the unimplemented extensions?
[16:17:31] <jai> first it should be reviewed and committed
[16:19:02] <nfl> then what is lavc/g729dec.c ?
[16:24:17] <jai> parts which were reviewed and committed
[16:25:17] <kshishkov> yes, we happen to have some of unfinished stuff in lav*
[16:27:12] <jai> also, for future reference, we support `ffmpeg -codecs` :)
[16:27:13] <av500> unffinished
[16:27:18] <nfl> ah, i see that it's not compiled
[16:29:01] <jai> av500: lavc/h264enc.c comes to mind
[16:29:12] <av500> x264?
[16:29:47] <jai> no, the the sucky one
[16:30:10] <av500> jai: no, i mean why do h264enc when there is x264?
[16:30:39] <jai> av500: i don't see the point, but that doesn't stop people from posting patches :)
[16:31:00] <av500> it is a patch magnet :)
[16:39:59] <BBB> av500: license?
[16:40:09] <BBB> x264 is gpl
[16:40:10] <mru> isn't open source great?
[16:40:13] <BBB> some people dislike license
[16:40:23] <BBB> it's like catholics and protestants killing each other in ireland
[16:40:26] <BBB> they did it for years
[16:40:28] <j0sh> BBB, did you want me to combine the theora->xiph renaming and vorbis import?
[16:40:45] <BBB> j0sh: I want you to start with svn cp fileold filenew
[16:40:52] <BBB> j0sh: from then on, small patches is good
[16:41:24] <BBB> you could separate the renaming and vorbis import
[16:41:31] <BBB> whichever you think is better
[16:41:36] <j0sh> BBB, lol ok... the changes overlap a bit so it's kind of tricky, i have to play with the diffs manually
[16:42:05] <av500> mru: btw, brookie turned out as expected :)
[16:42:06] <j0sh> i learned git for this, but didnt realize the huge patches from it were a problem
[16:42:27] <twnqx> it's a review issue
[16:43:26] <BBB> OH
[16:43:30] <BBB> it's public
[16:43:33] <BBB> guys, check mozilla
[16:43:38] <BBB> they did something cool for a change
[16:43:43] <mru> "never experienced a halting problem" .... rotfl
[16:43:48] <BBB> http://www.0xdeadbeef.com/weblog/wp-content/uploads/2010/03/mcscreen.png
[16:44:14] <mru> BBB: they can't even spell ffmpeg
[16:44:22] <astrange> what's with the completely wrong window size?
[16:44:23] <BBB> who gives a damn?
[16:44:25] <BBB> they attribute?
[16:44:31] <BBB> that's better than anything they've done so far
[16:45:33] <av500> mru: right, that made my morning
[16:47:13] <mru> what about a meta-halting problem? is it possible to determine if it's possible to determine if a given program will halt?
[16:47:41] <kshishkov> now how can we convince certain video hosting site to acknowledge using of FFmpeg?
[16:47:57] <mru> we could troll them like we did mediacoder :-)
[16:47:58] <kshishkov> mru: M$ Windows 95 is the solution - it will
[16:48:12] <mru> randomly insert a watermark if we detect, somehow, that we're running on their systems
[16:48:37] <av500> mru: make lav* phone home for a start
[16:48:57] <av500> s /home/china(
[16:49:17] <mru> of course the yt people might be competent enough to remove any such nasties
[16:49:37] <av500> I trust you to make it totally unobvious :)
[16:49:50] <av500> e.g. write tcp stack in neon
[16:50:01] <av500> err, sse2
[16:50:39] <mru> some people say I did a good job making intreadwrite.h impenetrable...
[16:50:54] <mru> that file is a bit of a macro hell
[16:51:11] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/NiceJobBreakingItHero
[16:51:30] <superdump> BBB: what's public?
[16:52:37] <kshishkov> mru: that's because they haven't tries understanding IOCCC winning programs
[16:52:40] <kshishkov> suckers!
[16:52:42] <BBB> superdump: http://www.0xdeadbeef.com/weblog/wp-content/uploads/2010/03/mcscreen.png
[16:53:00] <superdump> what's that got to do with mozilla? is miro a mozilla project?
[16:53:08] <BBB> mozilla paid for it
[16:53:12] <BBB> I don't know if they own it
[16:53:13] <mru> I like the #include </dev/console> one
[16:53:26] <BBB> and mozilla is heavily promoting it now
[16:53:47] <astrange> miro ships perian on os x
[16:53:54] <astrange> they were their own project, though
[16:54:00] <astrange> with some silly name like "democracy"
[16:56:53] <superdump> yes
[16:56:57] <superdump> democracyplayer
[16:57:32] <kshishkov> idiotic name
[16:57:54] <superdump> democratic name
[16:58:03] <superdump> i think they ended up thinking it was idiotic too
[16:58:06] <superdump> so they changed it
[16:58:07] <superdump> or blah
[16:58:22] <kshishkov> you know, here "democratizer" is a semi-official name for truncheon
[16:58:53] <superdump> heh
[16:58:57] * superdump -> out
[16:59:05] <superdump> hej då
[16:59:10] <kshishkov> hej hej
[17:34:28] <nfl> jai: can i pm you?
[17:36:57] <CIA-1> ffmpeg: rbultje * r22718 /trunk/libavformat/rtsp.c:
[17:36:57] <CIA-1> ffmpeg: Add a timeout to the select() call. Patch by Sam Gerstein <sgerstein bluefinlab
[17:36:57] <CIA-1> ffmpeg: com>.
[17:37:54] <CIA-1> ffmpeg: rbultje * r22719 /trunk/libavcodec/wmaprodec.c: Simplify interleaving code.
[17:45:04] <bofh__> I was reading over the list of Google SoC projects and one thing jumped out at me: both lavf audio work and rewriting the audio conversion code require the rewriting of a resampling layer. Why not use libsamplerate/Secret Rabbit Code? License issues? Writing a resampling layer is *hard*, as long as all you want is something that does basic conversion then a simple interpolation algorithm using a bandlimited Kaiser window will work ...
[17:45:11] <bofh__> ... quite well, aliasing is minimal even when doing nasty conversions like 44.1kHz<->48kHz, etc. However, if you want to get rid of the small amount of ringing/aliasing from this, this is *hard*. Various methods exist, anything from complex wavelet analysis to using digital forms of analog polyphase filter banks (aka the Julius O. Smith III method), these are hard to implement, even harder to get perfectly, right, and hence given ...
[17:45:17] <bofh__> ... the existence of a library that already does so and does so quite well, I wonder why this isn't being used.
[17:46:27] <Compn> what license and language is libsamplerate ?
[17:46:30] <kshishkov> we don't like external dependencies, especially on not so standard libraries
[17:48:29] <Dark_Shikari> aka NIH
[17:48:33] <Dark_Shikari> NIH syndrome
[17:48:50] * bofh__ snickers
[17:48:59] <bofh__> Compn: 1 sec.
[17:49:27] <mru> afaik libsamplerate lets you choose either fast and crap or slow and crap
[17:50:43] <Compn> lol
[17:51:30] <av500> mru: crappyness should be determined easily
[17:52:51] <astrange> lavc has a resampler already
[17:53:00] <astrange> ...two actually, i forget which one is actually used
[17:53:22] <astrange> it's not as good as ssrc but probably is as good as anything else
[17:53:49] <bofh__> sigh, FSF syndrome. It's GPL, and thus probably will cause issues.
[17:53:54] <bofh__> astrange: that's the other thing I noted :V
[17:54:11] <bofh__> I'm willing to bet it's just bandlimited Kaiser interpolation, that's very simple and quite good.
[17:54:22] <Dark_Shikari> I love the ffmpeg resampler for one reason
[17:54:27] <Dark_Shikari> it has CONFIG_AUDIOPHILE_KIDDY_MODE
[17:54:31] <mru> I remember michael improving the resampler massively a couple of years ago
[17:54:32] <bofh__> ROFL.
[17:54:35] <bofh__> What does that do?
[17:54:42] <bofh__> I must know.
[17:54:44] <Dark_Shikari> uses a ridiculous amount of extra precision internally at the cost of speed
[17:55:05] <bofh__> That is hilarious.
[17:55:12] <bofh__> Whoever did that deserves an award.
[17:55:28] <Dark_Shikari> michael iirc ;)_
[17:55:31] <mru> of course
[17:56:04] <mru> someone complained it was bad, slow, or both
[17:56:08] <mru> so michael rewrote it
[17:56:12] <Dark_Shikari> and he added a KIDDY_MODE
[17:56:15] <mru> yep
[17:56:21] <Dark_Shikari> it only took a couple of lines of ifdefs
[17:56:40] <BBB> bofh__: why would we use an external resampler if we already have one?
[17:56:50] <bofh__> Anyway, now that rambling is done, more interesting things can be talked about, like implementing DTS or BSAC AAC. DTS, specifically.
[17:56:52] <Dark_Shikari> 'cause it's better
[17:57:01] <BBB> Dark_Shikari: prove it
[17:57:06] <bofh__> BBB: it was just a thought based off reading their wikipedia page.
[17:57:12] <bofh__> s/their/your/
[17:57:16] <Compn> bofh__ : mplayer had its own old resample code, but it was ditched for the lavc resampler
[17:57:20] <Dark_Shikari> it's the same issue with the RTMPE issue
[17:57:23] <Compn> i wonder if vlc / xine have resampler either
[17:57:28] <Dark_Shikari> BBB: I'm not saying it is, I'm saying that would be the reason to ditch it
[17:57:34] <BBB> ah, ok
[17:57:35] <Dark_Shikari> like the whole thing with librtmp
[17:57:37] <BBB> well yeah
[17:57:42] <BBB> I thought that was shit
[17:57:46] <bofh__> What exactly happened with librtmp?
[17:57:53] <BBB> 5 yrs from now I have to get a student to integrate librtmp into ffmpeg
[17:58:08] <Compn> 5 years from now we hope rtmp will be gone
[17:58:14] <BBB> because the maintainer is too god damn stupid to see that 5 years from now, he won't work on it anymore and nobody else will either
[17:58:16] <Compn> and adobe with them
[17:58:25] <BBB> Compn: we want to keep supporting old formats
[17:58:31] <BBB> why else do we have support for game formats?
[17:58:34] <Dark_Shikari> Compn: hahahahahha you wish
[17:58:43] <kshishkov> BBB: the maintainer hears ;)
[17:58:45] <Compn> old formats yes, but not old streaming servers ?
[17:58:55] <mru> vlc definitely has a resampler
[17:58:58] <Compn> e.g. there is no vdo:// support :P
[17:58:59] <BBB> kshishkov: not you, hyc
[17:59:07] <mru> and it uses it even when it shouldn't
[17:59:25] <Compn> mru : at least it doesnt get stuck in some infinite resample loop :)
[17:59:27] <av500> now where did I see that before...
[17:59:39] * av500 says arts and hides
[18:00:21] <bofh__> Speaking of useless formats, who the fuck uses Realaudio Lossless?
[18:00:32] <bofh__> Let me rephrase that. Who the fuck still uses Realaudio.
[18:00:33] <Compn> Dark_Shikari : btw some website auto-downloaded a pdf to me yesterday, i'm guessing its a virus :D
[18:00:55] <Compn> javascript + pdf + adobe = fail
[18:00:57] <bofh__> No, let me rephrase that again. Realnetworks hasn't gone bankrupt yet with everyone stopping the use of their shit formats yet?
[18:01:11] <av500> bofh__: realvideo and audio has several hundred million users
[18:01:14] <kshishkov> unfortunately, no
[18:01:17] <Compn> bofh__ : they signed contracts with mlb and some other big sites to host videos
[18:01:29] <Compn> they arent going anywhere anytime soon
[18:01:41] <bofh__> wait, they haven't gone bankrupt as a company yet? could have sworn.
[18:01:52] <bofh__> Disappointing.
[18:02:07] <av500> bofh__: 90% of chinese p2p content is rv/ra
[18:02:38] <Compn> anyone know where the chinese bit torrent sites went? bt.ydy left me and now i'm a bit lost ...
[18:02:40] <kshishkov> av500: do they pay for it?
[18:02:47] <av500> kshishkov: for p2p?
[18:03:00] <av500> as in pay2play?
[18:03:13] <Compn> chinese vod sites might pay real for an encoder license
[18:03:20] <Dark_Shikari> doubt it
[18:03:24] <av500> Compn: they dont use real
[18:03:34] <Compn> most use wmv...
[18:03:45] <av500> yes, commercial use of rv in china is none
[18:03:47] <bofh__> Poked through resample2.c, it's a Kaiser window dealie with some filter bank stuff tacked on loosely, which is what I expected.
[18:03:55] <bofh__> Also, audiophile_kiddy_mode is hilarious.
[18:03:57] <av500> I saw a survey, it was really only p2p
[18:04:31] <BBB> bofh__: please do something useful or go away
[18:04:32] <janneg> libsamplerate is almost as large as libavcodec
[18:04:36] <BBB> you're annoying me
[18:04:53] <Compn> BBB : hehe, you seem on edge about stuff...
[18:05:01] <janneg> it ships a 8.8M large table
[18:05:03] <kshishkov> BBB: and lame nickname too ;)
[18:05:23] <BBB> Compn: nah, I get annoyed when my window keeps blinking for no apparent good reason
[18:05:55] * av500 must not ask janneg how BBB is doing
[18:06:49] <av500> lol, from the rv survey in china: "RM is dominant for user shared content Efficiency of format is clearly recognized"
[18:06:56] <mru> tables bigger than 1/2 L1$ are usually a very bad idea
[18:07:26] <janneg> av500: no reason to ask. there is a nice status page update regularly
[18:07:48] <kshishkov> mru: L1 on ARM or on Intel chips?
[18:07:57] <bofh__> BBB: alright, I could understand making that comment if I was spamming up the channel, but apparently conversation is forbidden here? Anyway, if you want me to be on-topic, I was asking about the task of implementing the DTS Encoder and if there is anything specific about it I should know before I apply, etc.
[18:08:09] <mru> kshishkov: whatever you're running on
[18:08:15] <mru> L1 doesn't actually differ that much
[18:08:18] <bofh__> And got no reply above. So. Yeah.
[18:08:36] <kshishkov> you've not asked it clearly
[18:08:46] <BBB> bofh__: then wait for someone to reply, don't bullshit on about libsamplerate or how your personal dislike for real or other shit like that
[18:09:02] <BBB> that has nothing to do with ffmpeg development
[18:09:10] <kshishkov> merbzt cares most about DTS encoder
[18:09:26] <bofh__> BBB: see comment about conversation being forbidden/etc (I am going to assume the answer is "yes", fwiw)
[18:09:27] <kshishkov> he also has some working version for it
[18:09:34] <BBB> bofh__: for you, yes
[18:09:52] <bofh__> BBB: noted.
[18:10:07] <Compn> bofh__ : mostly its a 'familiarize yourself with the code (decoder)' and read the specs, submit an application, ask the mentor which qualification task you should work on, and get starterd...
[18:10:25] <Compn> any other question?
[18:10:38] <janneg> mru: it's only 1.3M compiled. 340.000 floats
[18:10:56] <mru> that's still several times bigger than many an L2
[18:11:06] <Dark_Shikari> BBB: we are quite allowed to bitch about real
[18:11:12] <Dark_Shikari> that is a long-loved pasttime of ffmpeg developers
[18:11:28] <bofh__> Compn: was wondering if there were any qualification tasks (for instance, the comment about RTSP/RSP mentions one)
[18:11:32] <Dark_Shikari> in fact, so is bitching about _everything_, up to and including our own code
[18:11:42] <kshishkov> mru: any good solution to reduce/move space needed for static VLCs?
[18:11:56] <Dark_Shikari> "static VLCs"?
[18:12:00] <Dark_Shikari> you mean binary space, or runtime space?
[18:12:10] <kshishkov> runtime
[18:12:21] <kshishkov> for binary it's all bss or something
[18:12:23] <mru> INIT_VLC_STATIC?
[18:12:27] <Dark_Shikari> ok, no better way then
[18:12:41] <Dark_Shikari> if you meant binary space, you can use gradient prediction/etc to compress huffman tables
[18:12:51] <kshishkov> mru: INIT_VLC_NEW_STATIC
[18:12:52] <Compn> bofh__ : i think ffmpeg is trying a new approach this year, we are trying to make the qual task  a small part from the SoC project, or at least related... so if you want to work on DTS encoder, the qual task would be to implement some small part of the encoder , you'd have to ask the mentor for that what he thinks the best qual task is
[18:13:03] <Dark_Shikari> yeah, what Compn said
[18:13:05] <mru> Dark_Shikari: or like zlib, huffman compress the huffman tables
[18:13:06] <Dark_Shikari> ffmpeg is copying x264 ;)
[18:13:32] <bofh__> Gotcha, and I assume for that it's a case of wait around for merbzt most likely.
[18:13:37] <Compn> yes
[18:13:45] <kshishkov> Dark_Shikari: usually before x264 gets there :P
[18:13:50] <av500> bofh__: feel free to look at the code in the meantime :)
[18:13:58] <bofh__> Okay, that is everything, will do.
[18:14:04] <Compn> Dark_Shikari : have you put h264 in rm yet? :P
[18:14:18] <bofh__> BBB: is idling forbidden as well? or can I do that without being bitched at? :P
[18:14:37] <kshishkov> Compn: he can do that only as RV5 ;)
[18:14:44] <Compn> bofh__ : BBB is an active devel, so you probably shouldnt bug him too much...
[18:15:08] <kshishkov> bofh__: yes, contribute and earn some respect and then you can have all idle talk you like
[18:15:24] <Dark_Shikari> bofh__: ignore BBB
[18:15:31] <Dark_Shikari> he's in a bad mood obviously
[18:15:34] <kshishkov> Compn: for some reason RM{VB} accepts only RealVideo for video codecs
[18:15:39] <Dark_Shikari> but yes, contribute some
[18:15:50] * BBB is a bit moody today, yes
[18:15:53] <Dark_Shikari> kshishkov: yeah, I can't possibly figure out why
[18:15:56] <Dark_Shikari> ;)
[18:15:58] * jai hands BBB a beer
[18:16:03] * BBB gets runk
[18:16:08] <BBB> nope, still moody
[18:16:10] * av500 hands BBB a real beer
[18:16:13] <Compn> kshishkov : i'm still trying to locate more old samples , i thought there was some other things that fit into rm
[18:16:18] <bofh__> Compn/Dark_Shishkov: I'm just teasing, my apologies to BBB if it got aggravating. kshishkov: that is the plan.
[18:16:21] <Compn> at least there was BHIV , which was rv20 ?
[18:16:22] * mru laughs in swedish at BBB's typo
[18:16:31] <kshishkov> av500: give him a glass of pot vodka
[18:16:39] <av500> I leave that to you
[18:17:04] <kshishkov> av500: I don't even touch alcoholic drinks let alone drugs
[18:17:43] <mru> most drugs are quite harmless to touch
[18:17:52] <mru> you have to smoke them or so before they have an effect
[18:18:44] <kshishkov> same for corked beer bottles yet I still won't touch them
[18:23:09] <jai> bofh__: for dtsenc, the qual task was to port the float qmf and fix lfe generation iirc
[18:23:20] <jai> bofh__: check the wiki, details should be there
[18:24:23] <Dark_Shikari> mru: you will love this
[18:24:25] <Dark_Shikari> http://theory.cs.uni-bonn.de/~ignatios/white%20space%2098.pdf
[18:24:36] <Dark_Shikari> Stroustrup on adding the feature to the next C++ standard to allow overloading of the whitespace operator
[18:24:53] <kshishkov> there is whitespace operator?
[18:24:57] <Dark_Shikari> the space.
[18:25:06] <Dark_Shikari> this lets you write Haskell in C++ ;)
[18:25:14] <kshishkov> or Python?
[18:25:20] <Dark_Shikari> myfunc a b c + yourfunc d e
[18:25:43] <av500> Dark_Shikari: hint: April 1,1998
[18:25:46] <jai> ugh
[18:25:54] <Dark_Shikari> av500: oh I know
[18:26:10] <kshishkov> I knew Danes were crazy
[18:26:20] <mru> he's norwegian
[18:26:31] <kshishkov> nope
[18:26:40] <kshishkov> born in Continental Denmark
[18:27:08] <pJok> kshishkov, they are crazy... just look at me
[18:27:15] * pJok is born in continental denmark
[18:27:25] <av500> that crazy norwegian dane!
[18:27:26] <kshishkov> BTW, do you know that some French architect is responsible for panel buildings (like in Miljonprogrammet)?
[18:27:45] <kshishkov> pJok: he is from Aarhus IIRC
[18:28:05] <pJok> i grew up at the border, so im about as danish as i am german
[18:28:08] <mru> hmm, don't know where I got the idea he was norwegian
[18:28:19] <kshishkov> and remember your guy from Odense? Who wrote _very_ creepy fairy tales?
[18:28:30] <pJok> hehe
[18:28:35] <kshishkov> or Danish philosophers?
[18:28:42] <pJok> Niels Bohr
[18:28:52] <pJok> H.C. Ørsted
[18:29:00] <kshishkov> that one was good
[18:29:19] <kshishkov> could not keep his wires straight though
[18:34:15] <ramiro> how do I make gdb break whenever a certain memory address is written to?
[18:34:32] <BBB> watch
[18:34:43] <mru> and pray
[18:34:43] <BBB> watch 0x1345 or watch struct->member
[18:35:25] <ramiro> hmm, will that work with rip stuff too?
[18:47:19] <Dark_Shikari> hmm.
[18:47:44] <Dark_Shikari> I have a static array that's used in a given c file all over--but only with constant indices
[18:47:50] <Dark_Shikari> however, i'ts still present in the output .o file
[18:47:55] <Dark_Shikari> 1) will the linker remove it since it isn't referenced?
[18:48:01] <Dark_Shikari> 2) why is it still there?
[18:48:14] <av500> er, used or not?
[18:48:26] <Dark_Shikari> it's not used because it's only accessed via constant indicex
[18:48:28] <Dark_Shikari> *indices
[18:48:31] <av500> "that's used" or "isn't referenced"
[18:48:45] <Dark_Shikari> thus every access will be simplified to no longer be a reference
[18:49:37] <janneg> pJok: Tønder, Tinglev, Bov or Sønderborg?
[18:50:47] * janneg grew up around Nibøl and went to a dansk børnehave
[18:53:20] <mru> Dark_Shikari: did you verify that there really are no references left?
[18:54:04] <Dark_Shikari> I grepped every reference to the array in the code
[18:54:51] <Dark_Shikari> it's static const too
[18:54:55] <mru> you could put the table in a separate section and link with --gc-sections
[18:54:56] <pJok> janneg, bov
[18:54:57] <Dark_Shikari> then again this is gcc 3.4, who knows
[18:55:05] <mru> if gcc is too stupid to remove it by itself
[18:55:11] <pJok> i went to the german kindergarten in padborg
[18:55:26] <Dark_Shikari> btw, I'm using nm to check for it
[18:55:29] <Dark_Shikari> I assume that's the right way
[18:55:45] <mru> "german kindergarten" sounds like it should be a euphemism for something nasty... don't know why
[18:55:56] <mru> at least it wasn't a catholic kindergarten
[18:56:30] <mru> Dark_Shikari: no, nm won't tell you about references within the same object file
[18:56:39] <mru> nm only prints the symbol table
[18:56:58] * av500 survived german kindergarten
[18:57:07] <Dark_Shikari> mru: but if it's not referenced and optimized away
[18:57:11] <Dark_Shikari> it shouldn't be in the symbol table, right?
[18:57:14] <mru> right
[18:57:21] <Dark_Shikari> so obviously we know it wasn't optimized away
[18:57:22] <janneg> kindergarten of the german minority in sønderjylland
[18:57:46] <mru> Dark_Shikari: yes, but you can't use nm to look for actual references to it
[18:58:02] <Dark_Shikari> of course
[18:58:06] <Dark_Shikari> I used grep for that
[18:59:03] <mru> grep for what in what?
[18:59:14] <Dark_Shikari> references to the table in the C code
[18:59:39] <mru> yeah, but how did you check that gcc optimises them into constant expressions?
[18:59:51] <Dark_Shikari> it's array[VALUE], where VALUE is a fucking enum
[18:59:57] <Dark_Shikari> every single instance is that.
[18:59:58] <mru> I get that
[19:00:04] <Dark_Shikari> if it cannot optimize that into constant expressions it fails even worse
[19:00:15] <mru> so did you check that?
[19:00:23] <Dark_Shikari> how am I supposed to check that, psychic powers?
[19:00:24] <mru> this is gcc ffs
[19:00:29] <mru> gcc -S
[19:00:32] <av500> objdump?
[19:00:39] <mru> or check the relocation table
[19:00:51] <mru> or forcibly remove it and see if it still links
[19:01:04] <mru> objcopy can help with that
[19:01:30] <Dark_Shikari> mru: it optimizes all references away
[19:01:33] <Dark_Shikari> but doesn't remove the table
[19:01:35] <Dark_Shikari> according to -s
[19:01:48] * av500 is not surprised
[19:01:53] <Dark_Shikari> also, it aligns a table of bytes to a 32-byte boundary
[19:01:58] <Dark_Shikari> for no fucking reason
[19:02:28] <mru> gcc aligns everything bigger than some undocumented size to an arbitrary, undocumented alignment
[19:02:37] <mru> and it varies by architecture
[19:03:01] <mru> the threshold is usually ~32 bytes
[19:03:08] <Dark_Shikari> this is a 17-byte array
[19:03:09] <Dark_Shikari> it aligns it to 32
[19:03:18] <Dark_Shikari> oh it gets worse
[19:03:20] <Dark_Shikari> I reduced the array to 9 bytes
[19:03:22] <Dark_Shikari> it STILL ALIGNS TO 32
[19:03:37] <mru> what type is the array?
[19:03:40] <Dark_Shikari> uint8_t
[19:03:57] <mru> maybe the threshold is as low as 8 bytes...
[19:04:58] <Dark_Shikari> nope
[19:05:01] <Dark_Shikari> at 7 bytes it still aligns to 32.
[19:05:29] <Dark_Shikari> hmm.  better stated, it doesn't align it to 32, it aligns the end of it to 32
[19:05:32] <Dark_Shikari> i.e. padding before the next array
[19:05:57] <Dark_Shikari> still stupid.  ugh.
[19:05:58] <mru> so it's aligning whatever comes after
[19:06:07] <mru> what comes after it?
[19:06:13] <Dark_Shikari> which is also a small array of uint16_ts
[19:06:50] <Dark_Shikari> gcc obviously isn't even trying to pack the arrays in an efficient way
[19:18:40] <CIA-1> ffmpeg: reimar * r22720 /trunk/libavformat/rtsp.c: Some spelling fixes.
[19:26:16] <BBB> j0sh: thanks for the patch, looks a lot better, will review in a bit if nobody beats me to it
[19:27:49] <j0sh> BBB, np
[19:28:30] <BBB> btw google student thing is open, it seems
[19:29:06] <j0sh> yep, first day is today... need to do my application
[19:29:51] <j0sh> is there any student interest in playlist support? i was looking at adaptive http streaming from apple, i think that'd be a cool feature to have clientside but needs playlist support
[19:30:08] <jai> smooth streaming?
[19:30:27] <BBB> I think there was a sudent doing it last year
[19:30:30] <BBB> didn't really go great
[19:30:32] <elenril> there was a playlist patch last summer
[19:30:40] <BBB> there was a lot of discussion on how to do playlists
[19:30:48] <BBB> which sort of blinded the actual hacking
[19:30:48] <elenril> anybody knows why it wasn't applied?
[19:31:00] <j0sh> jai, im not sure, its used on the iphone: http://tools.ietf.org/id/draft-pantos-http-live-streaming-01.txt
[19:31:03] <BBB> elenril: disagreement on how i ought to be done :(
[19:31:44] <j0sh> apparently apple is demanding large iphone app vendors to implement it
[19:31:48] <jai> j0sh: right
[19:31:51] <elenril> iirc the thread ended with the student sending patch that was supposed to fix all the issues
[19:31:54] <elenril> and then silence
[19:32:03] <jai> thats unfortunate :/
[19:32:17] <jai> whatever happened to the student?
[19:59:07] <BBB> j0sh: silly question, but you tested it right?
[19:59:17] <BBB> j0sh: if so, all patches ok, I'll apply in a bit unless someone beats me to it
[19:59:33] <BBB> don't forget svn rm rtpdec_vorbis.[ch]
[20:01:56] <j0sh> BBB, tested it with video, yeah
[20:02:00] <BBB> audio also?
[20:02:02] <BBB> :)
[20:02:35] <j0sh> audio, kinda -- the samples that work, seem to encode fine
[20:02:43] <j0sh> but a larger issue is, i am stone deaf :)
[20:03:46] <BBB> oh right, that makes audio testing problematic...
[20:03:51] <BBB> hmm... need to find a solution to that
[20:03:55] <BBB> I guess I could test it
[20:03:55] <j0sh> heh yeah
[20:04:14] <j0sh> does ffplay produce a spectrograph
[20:04:19] <BBB> if you use -an
[20:04:25] <BBB> er...
[20:04:25] <BBB> -vn
[20:05:56] <j0sh> i did crcs, md5sum for audio, they match before-and-after the patch, but i dont know if it works in the first place
[20:07:22] <j0sh> as of now i cant ffplay audio-only tracks, my system's sound is busted (realized it yesterday; but thats probably been the case for years now)
[20:07:40] <j0sh> tried fixing it yesterday, no luck so far, but i'll keep working on it
[20:11:44] <BBB> if md5s match, you're fine
[20:11:47] <BBB> I'll commit in a bit
[20:11:51] <BBB> taking a phone call first...
[20:11:53] <BBB> brb
[20:25:26] <j0sh> BBB, gotta go to class. lmk if there are problems with the patches
[20:27:43] <BBB> ok
[20:59:08] <CIA-1> ffmpeg: reimar * r22721 /trunk/libavcodec/dv.c: Fix indentation.
[21:02:39] <CIA-1> ffmpeg: reimar * r22722 /trunk/doc/tablegen.txt: Add some documentation about the table generation code.
[21:17:54] <lu_zero> wbs: the lscube bugzilla is rejecting your attachments?
[21:18:28] <wbs> lu_zero: hmmmm, either that, or I'm missing something :-)
[21:19:09] <wbs> ah, I have to add descriptions to the attachments, otherwise it will drop them silently ;
[21:19:12] <wbs> ;P
[21:19:27] <wbs> if attaching them separately later, it actually says so
[21:19:36] <lu_zero> uhm...
[21:19:40] <lu_zero> annoying =_=
[21:20:41] <lu_zero> let me look at the patches before I'm going to sleep...
[21:21:19] * jai tried that yesterday, didn't work out so well :)
[21:21:45] <wbs> lu_zero: there you go, now the attachments should be there
[21:21:50] <lu_zero> found them
[21:22:11] <wbs> #3 and #6 should be straightforward, #5 is an ugly proof of concept that I don't suggest you apply as is
[21:22:18] <wbs> and #7 is a slightly bigger one
[21:28:41] * Rathann hunts for peloverde or superdump
[21:33:22] <pasteeater> Dark_Shikari: should I make the psy tuning just like a preset?  libx264-tune_animation.ffpreset?
[21:33:29] <CIA-1> ffmpeg: reimar * r22723 /trunk/libavcodec/ (4 files):
[21:33:30] <CIA-1> ffmpeg: Include appropriate header in table generators instead of using a dummy
[21:33:30] <CIA-1> ffmpeg: av_cold define.
[21:33:37] * BBB decides he really hates qcelp
[21:34:33] <Rathann> [Frostii]_Summer_Wars_[720p][9B12BBFA]-ffplay-desync-clip.mkv in mphq/incoming can someone confirm the desync?
[21:34:37] <BBB> did anyone ever get that reference code to run/work?
[21:37:48] <mru> Rathann: there's nothing to reference sync to in that clip
[21:38:25] * lu_zero is still reading
[21:38:32] <Rathann> mru: meaning?
[21:38:46] <Rathann> mplayer plays it fine...
[21:38:52] <mru> as does ffplay
[21:39:06] <mru> there's nothing in the video I can tie to any particular sounds
[21:39:21] <mru> it could be a second off and I wouldn't notice
[21:39:56] <Rathann> there's speech and subtitles
[21:40:14] <Rathann> though I guess ffplay doesn't render them
[21:40:29] <mru> and how would you tell if subtitles are out of sync?
[21:40:56] <mru> a few hundred ms this way or that is impossible to tell whether it's an error or intentional
[21:41:17] <Rathann> well, the problem is that in ffplay the audio plays as if in slow motion
[21:41:49] <Rathann> and speech is distorted beyond recognition because of that
[21:42:22] <mru> not here
[21:42:33] <mru> I don't speak japanese
[21:42:45] <mru> but if I did, I'd have no trouble listening to that
[21:43:00] <mru> and the rate sounds correct for a woman's voice
[21:43:17] <Rathann> hmm so maybe it's not distorted for you, strange
[21:43:30] <mru> sbr?
[21:43:38] <Rathann> dunno, checking
[21:44:20] <Kovensky> o, a Rathann
[21:45:44] <Rathann> how can I tell if it's sbr?
[21:48:24] <Rathann> if I extract it with mkvextract it says ADTS
[21:48:56] <Rathann> $ file audio.aac
[21:48:57] <Rathann> audio.aac: MPEG ADTS, AAC, v4 LC, 48 kHz, surround + LFE
[21:49:10] <mru> sbr is insidious like that
[21:49:30] <mru> it lurks unseen until it suddenly jumps out and doubles the sampling rate
[21:49:50] <mru> but if the adts header says 48kHz it's probably not using sbr
[21:49:56] <Dark_Shikari> pasteeater: just call it "animation"
[21:51:12] <Rathann> mru: mkvinfo says the video stream is almost twice as long as audio stream, maybe ffplay trips over that? but still if it doesn't for you then I'm a bit confused
[21:52:09] <Rathann> ffmpeg says: Seems stream 0 codec frame rate differs from container frame rate: 47.95 (48000/1001) -> 23.98 (24000/1001)
[21:52:19] <pasteeater> Dark_Shikari: not sure how to implement: --ref {Double if >1 else 1}
[21:52:50] <Dark_Shikari> oh.  that's a problem
[21:52:53] <Dark_Shikari> you can't implement that
[21:53:06] <Dark_Shikari> not without multiplying presets * tunes
[21:53:21] <pasteeater> same goes for --bframes {+2}
[21:53:40] <pasteeater> everything else looks fine
[21:53:48] <Dark_Shikari> yeah
[21:54:05] <pasteeater> maybe animation will have to wait for now
[21:55:42] <pasteeater> you mean to just name the tune as "animation"?  no .ffpreset or anything?  duh...
[21:58:18] <Dark_Shikari> well no
[21:58:22] <Dark_Shikari> I mean libx264-animation.ffpreset
[21:58:26] <Dark_Shikari> not tune_animation
[22:04:28] <pasteeater> hmm...i think new users might confuse that with a preset if it isn't labeled differently somehow.
[22:05:11] <Dark_Shikari> dunno then
[22:06:17] <pasteeater> But if there can be no arrangement, then we are at an impasse.
[22:06:22] <pasteeater> I'm afraid so -- I can't compete with you physically. And you're no match for my brains.
[22:06:45] * Dark_Shikari detects princess bride
[22:08:26] <lu_zero> wbs: how did you produce those patches?
[22:08:40] <lu_zero> git-am is complaining about lacking a field
[22:10:06] <mru> git-am needs more than a plain diff
[22:10:11] <mru> try git apply
[22:10:40] <Kovensky> git am eats git format-patch output IIRC
[22:14:45] <lu_zero> mru: it isn't a plain diff
[22:15:17] <lu_zero> http://bugs.lscube.org/attachment.cgi?id=1
[22:15:41] * lu_zero wanted to spare time and avoid rewriting =_=
[22:16:31] <mru> that looks like "git show" output
[22:16:34] <mru> not git format-patch
[22:17:05] <janneg> git am is short for git apply mailbox
[22:17:11] <mru> git git apply also fail?
[22:17:18] <mru> *does
[22:17:49] <CIA-1> ffmpeg: stefano * r22724 /trunk/ (9 files in 3 dirs):
[22:17:50] <CIA-1> ffmpeg: Implement YOP demuxer and video decoder.
[22:17:50] <CIA-1> ffmpeg: Patch by Mohamed Naufal gmailify(naufal11).
[22:18:50] <lu_zero> git am would parse it correctly splitting the msg and such
[22:19:10] <lu_zero> but it complains about them lacking a Email: line
[22:19:12] <mru> yes, but it's missing some fields for that
[22:19:31] * lu_zero is tempted to hack git am and live happy =_=
[22:24:34] <DonDiego> http://git.videolan.org/?p=vlc.git;a=commit;h=c26c8d737f83c80493541627abf6cef3bc4f60de
[22:24:53] <DonDiego> "
[22:24:55] <DonDiego> Workarounded SSA payload modifications done by mkv avformat demuxer."
[22:30:07] <CIA-1> ffmpeg: stefano * r22725 /trunk/libavformat/avio.h: Document url_exist().
[22:40:07] <Dark_Shikari> is there a standardized linux way of getting the page size?
[22:41:07] <Rathann> sysconf(SOMETHING), maybe?
[22:41:27] <Rathann> yup
[22:41:37] <Rathann> sysconf(_SC_PAGESIZE)
[22:41:49] <Rathann> and I think it's even POSIX
[22:41:54] <Dark_Shikari> yeah
[22:49:04] <Dark_Shikari>        sleep()  makes  the  calling  process  sleep until seconds seconds have
[22:49:08] <Dark_Shikari>        elapsed or a signal arrives which is not ignored.
[22:49:10] <Dark_Shikari> Does this mean "calling process" or "calling thread"?
[22:52:47] <astrange> thread
[22:53:38] <mru> why do you need to know the page size?
[22:54:11] <Dark_Shikari> nvm, turned out I didn't
[22:54:18] <mru> yeah, you rarely do
[22:54:18] <Dark_Shikari> madvise takes a length, not a number of pages or whatever
[22:57:17] <Dark_Shikari> random question: suppose I am spawning threads which I know will exit on their own
[22:57:21] <Dark_Shikari> can I overwrite their handle while they're still running?
[22:57:26] <Dark_Shikari> i.e. the handle only used for my own access of the thread?
[22:57:31] <Dark_Shikari> or does it contain other important data I shouldn't mess with
[22:57:40] <Dark_Shikari> *is the handle
[23:01:09] <mru> are these "detached" threads?
[23:01:50] <mru> all threads must be either explicitly pthread_join()'d or detached
[23:01:54] <mru> otherwise you leak memory
[23:02:04] <mru> and if you detach them, how do you know when they're done?
[23:02:14] <Dark_Shikari> when they return
[23:02:21] <mru> return?
[23:02:24] <mru> threads don't return
[23:02:28] <Dark_Shikari> pthread_create spawns a single function
[23:02:33] <Dark_Shikari> the function does something, then hits a return statement
[23:02:33] <mru> yes
[23:02:34] <Dark_Shikari> what happens then?
[23:02:40] <mru> then the thread dies
[23:02:47] <Dark_Shikari> then we're fine then, right?
[23:02:54] <mru> and if it wasn't detached you can call pthread_join and fetch the return value
[23:03:00] <Dark_Shikari> But what if I don't?
[23:03:11] <mru> if you don't call pthread_join you leak memory
[23:03:29] <mru> or detach
[23:03:56] <mru> so back to the question, if you don't pthread_join, how do you know when the thread has finished?
[23:04:09] <Dark_Shikari> I don't care when it finished
[23:04:18] <Dark_Shikari> all I care is that I spawned threads and they did things
[23:04:24] <mru> what's to stop you creating more threads than the system can handle?
[23:04:32] <Dark_Shikari> zombies don't get cleaned up automatically?
[23:04:40] <mru> of course not
[23:04:50] <mru> you couldn't fetch the return value if they did
[23:04:56] <mru> but you can detach them
[23:04:58] <Dark_Shikari> You can fetch the return value of processes with waitpid
[23:05:00] <mru> then they'll auto-clean
[23:05:02] <Dark_Shikari> And they get cleaned up automatically
[23:05:13] <mru> yes, processes are zombies until you wait() for them
[23:05:24] <Dark_Shikari> But the OS will clean them up automatically
[23:05:26] <Dark_Shikari> Just a while later.
[23:05:34] <mru> pthread_join() is to threads what waitpid() is to processes
[23:05:44] <Dark_Shikari> So in other words, you don't have to join them.
[23:05:45] <mru> the OS never cleans up zombies
[23:05:47] <Dark_Shikari> Yes it does
[23:05:59] <Dark_Shikari> even the bloody toy OS we're working with in OSs class does
[23:06:05] <mru> when a process dies, any zombie children are reparented to init, which will reap them after a while
[23:06:20] <mru> the kernel doesn't do anything
[23:06:46] <Dark_Shikari> I'm pretty sure if the kernel runs into resource issues it will reap zombies.
[23:06:51] <mru> nope
[23:06:54] <mru> it's not allowed ot
[23:06:54] <mru> to
[23:07:05] <mru> it can't know you're not about to call wait()
[23:07:43] <mru> it has to hold on to the exit status until something asks for it
[23:07:45] <Dark_Shikari> waitpid isn't required to keep the return values around forever
[23:07:52] <mru> yes it is
[23:07:58] <Dark_Shikari> not beyond when the pid is reused
[23:08:00] <mru> the OS has to keep it around until wait() is called
[23:08:17] <mru> the pid isn't reused until the zombie is reaped
[23:08:28] <mru> try running ps
[23:08:36] <mru> after creating some zombies
[23:08:46] <mru> zombies have a pid just like any other process
[23:09:08] <Dark_Shikari> so how does one detach a thread then?
[23:09:12] <mru> pthread_detach()
[23:09:23] <mru> but using that is usually sign that you're doing something wrong
[23:09:26] <Dark_Shikari> can I call it right after a pthread_create?
[23:09:38] <mru> after you check the return value yes
[23:09:45] <mru> you can also do it from the new thread
[23:09:50] <mru> pthread_detach(pthread_self())
[23:10:01] <Dark_Shikari> oh, you can call it on yourself?  hah
[23:10:33] <mru> of course a detached thread can't be joined
[23:17:26] <mru> http://www.betanews.com/article/MPEG-LA-wins-major-MPEG2-settlement-from-AlcatelLucent/1269898704
[23:17:36] <Dark_Shikari> already?
[23:17:55] <mru> looks like mpeg-la are the good guys this time
[23:18:11] <Dark_Shikari> ?
[23:19:14] <mru> A-L were suing left, right, and centre over patents that mpeg-la, apparently, are now forcing into the mpeg2 pool
[23:19:59] <mru> although both sides seem to be claiming they're close to winning there
[23:20:08] <mru> as usual in such lawsuits
[23:20:51] <Dark_Shikari> ah
[23:21:35] <mru> if the patents are forced into the pool, they can't charge extra for them
[23:22:08] <mru> now substitute theora for mpeg2
[23:22:13] <mru> who's gonna help you now?
[23:22:24] <kierank> doesn't that mean the mpeg-2 licensing price will increase? otherwise existing holders would get less
[23:22:35] <mru> maybe
[23:22:51] <mru> but almost certainly much less than what AL were suing for
[23:26:02] <nfl> saste: the changelog hasn't been updated for YOP
[23:27:39] <saste> nfl: true I forgot that
[23:28:05] <saste> nfl: give me some time and i'll do
[23:30:10] <nfl> saste: sure ;)
[23:34:58] <CIA-1> ffmpeg: stefano * r22726 /trunk/Changelog: Add missing entry for the YOP demuxer and video decoder addition.