[FFmpeg-devel-irc] IRC log for 2010-04-16

[irc at mansr.com]

[00:21:02] <CIA-81> ffmpeg: ramiro * r22888 /trunk/ (libavformat/rtsp.c cmdutils.c):
[00:21:02] <CIA-81> ffmpeg: AVERROR(FF_NETERROR(x)) -> FF_NETERROR(x)
[00:21:02] <CIA-81> ffmpeg: FF_NETERROR is implicitly an AVERROR.
[01:57:05] <roozhou> hi, when will you guys fix ETIMEDOUT undeclared bug in rtsp.c under win32?
[02:24:53] <Compn> roozhou : probably when you enter bugreport on http://roundup.ffmpeg.org
[02:25:00] <Compn> or paste me enough info so i can create report
[02:25:12] <Compn> fate should have picked up on it actually...
[02:26:28] <roozhou> here: http://ffmpeg.arrozcru.org/autobuilds/
[02:26:40] <roozhou> see the build log
[02:30:02] <Compn> thats for 22884
[02:30:24] <Compn> fate says 22888 is working
[02:30:32] <Compn> http://fate.multimedia.cx/index-v3.php
[02:31:35] <Compn> [14:38] <CIA-81> ffmpeg: rbultje * r22887 /trunk/libavformat/ (rtsp.c network.h):
[02:31:36] <Compn> [14:38] <CIA-81> ffmpeg: Fix compile error on cygwin where ETIME is missing (because it's a WSA error).
[02:32:01] <Compn> roozhou : maybe you need to svn update ?
[02:33:31] <roozhou> great
[06:24:50] <Tjoppen> we have a student doing a video related master thesis in our office. any suggestions what he should pick for his in-depth theoretical study? I suspect MPEG-1 video wouldn't be too bad
[06:26:00] <wbs> I guess it depends _very_ much on exactly what he's doing, "video related" could be just about anything
[06:26:17] <astrange> how long is it supposed to be? mpeg-1 is extremely simple
[06:26:50] <Tjoppen> well, it's not simple to a newbie. I don't think the average CS student even knows how JPEG works
[06:27:11] <Dark_Shikari> MASTER THESIS?
[06:27:27] <Dark_Shikari> er.... doing something mpeg-1 related for a master thesis? is this a joke?
[06:27:47] <Tjoppen> no. that's why I'm asking
[06:27:50] <Dark_Shikari> ffs, even when I wrote a toy memory allocator in a one-off lab assignment for a mid-level CS class I tried to do something mildly interesting
[06:28:27] <Dark_Shikari> for a master thesis I would recommend implementing a new feature in x264 or something similarly difficult.
[06:28:34] <Tjoppen> the thing is this is just a minor part of the thesis, if I understand correctly
[06:28:36] <Dark_Shikari> Anything less than a Google Summer of Code project for a masters' thesis is a joke.
[06:28:40] <Dark_Shikari> ah
[06:28:42] <Dark_Shikari> should have said that then.
[06:28:47] <Tjoppen> yeah :o
[06:28:47] <Dark_Shikari> What exactly is it for?
[06:29:53] <Tjoppen> not sure how much I can reveal, but it's for one of the systems we're developing. he's already done the main work is done, but seems to need some theory to complement it
[06:30:07] <Tjoppen> s/is done//
[06:30:31] <Tjoppen> to prime the reader I guess would be a good explaination
[06:30:38] <Dark_Shikari> prime what reader
[06:30:56] <Tjoppen> of the thesis. via a theory section
[06:31:09] <Dark_Shikari> how can you expect people to advise you about something you can't talk about?
[06:31:17] <Tjoppen> heh
[06:31:22] <Tjoppen> fair enough
[06:40:36] <peloverde> So the spec says not to run ipd/opd at all when the enable_ipdopd flag is zero but the reference decoder seems to run it anyway, FML
[06:40:54] <Dark_Shikari> that looks like a mixed up ipod
[06:41:14] <peloverde> google thinks so too, it drives me mad to no end
[06:41:31] <wbs> peloverde: btw, regarding AAC, I recently studied it a bit, and was horrified about the (undefined number of) priming samples showing up in the output
[06:41:49] <peloverde> wbs, those samples are not undefined
[06:42:01] <peloverde> TDAC initializes to zero
[06:42:08] <wbs> but different encoders produce different amount of them?
[06:42:38] <Yuvi> using '+' works wonders to combat google's helpfulness
[06:42:39] <peloverde> editlists should be used to compensate for encoder delay
[06:43:21] <wbs> ok, ffmpeg (with faac) doesn't seem to use that at least
[06:43:44] <wbs> as a constructed example, I repeatedly encoded an mp4 file with aac into another file with the same format
[06:43:51] <wbs> after a few rounds, the a/v sync was way off
[06:44:05] <wbs> (did this with quite low sampling rate, to make the effect much larger)
[06:44:25] <peloverde> the encoder needs to set editlists
[06:44:48] <peloverde> There is no way to know what the encoder delay is without them
[06:44:53] <wbs> exactly
[06:45:28] <peloverde> Apparently it is discussed in detail in 14496-24 but I don't have that one
[06:46:50] <Dark_Shikari> any idea why this http://pastebin.org/153329 would cause this http://pastebin.org/153328 ?
[06:46:54] <Dark_Shikari> (GCC ICEs ftw)
[06:47:11] <Yuvi> "+m"(M64()) ?
[06:47:13] <wbs> ok.. is there any point in filing a roundup case about it, to remind that it should be handled in some way?
[06:47:22] <Dark_Shikari> Yuvi: it was the [i], just figured it out
[06:47:25] <Dark_Shikari> mvc[i] caused it to ICE
[06:47:47] <Dark_Shikari> recursive dependency
[06:48:21] <peloverde> I don't have the write specs to do anything on that, and I'm not paying 200 CHF for a 15 page pdf
[06:49:04] <peloverde> Also I think google is trolling me http://i.imgur.com/upnzs.png
[06:49:20] <wbs> haha
[06:49:44] <peloverde> s/write/right/
[06:50:03] <pJok> peloverde, http://www.pdfqueen.com/html/aHR0cDovL3dlYnN0b3JlLmllYy5jaC9wcmV2aWV3L2luZm9faXNvaWVjMTQ0OTYtMTJ7ZWQzLjB9ZW4ucGRm ?
[06:50:19] <peloverde> pJok, that's -12
[06:50:22] <peloverde> I need -24
[06:50:25] <pJok> gah
[06:50:26] <pJok> that was only the 12
[06:50:33] <Yuvi> no encoder as of 2008 outputed ipd/opd?
[06:51:12] <astrange> Dark_Shikari: does a "new" gcc do that?
[06:51:32] <peloverde> Yuvi, no idea
[06:51:43] <astrange> it would be a gcc ice-on-invalid bug
[06:52:30] <Dark_Shikari> astrange: that was 3.4
[06:52:38] <Dark_Shikari> let me try 4.3.4
[06:53:05] <Yuvi> peloverde: first result of http://www.google.com/search?&q=%2Bipd+%2Bopd+%2Baac claims so, second implies that there's only a single sample that uses them in existence
[06:53:47] <Dark_Shikari> astrange: nah, fixed.  in fact, it compiles now
[06:53:48] <Dark_Shikari> lol
[06:55:11] <peloverde> Yuvi, I decoder is not Level 5 con formant without IPD/OPD support, it doesn't matter that no one uses it now
[06:56:00] <peloverde> remember when thunselda started using uncoded 4MV, etc. and all sorts of stuff started coming up as broken in fftheora?
[07:19:47] <peloverde> that said, since there is conflict, I think i will err on the side of what computationally simpler
[08:01:28] <KotH> salve ffmpeg! morituri te salutat!
[08:14:20] <Dark_Shikari> oh wow, I stumbled across that old inline asm bug report on gcc
[08:14:32] <Dark_Shikari> where the devs claimed that register-allocation was turing-hard
[08:14:37] <Dark_Shikari> er, halting-problem-hard
[08:36:58] <KotH> hmm?
[08:37:16] <KotH> register allocation might be an NP complete problem, but then, you dont have millions of registers
[08:40:31] <Dark_Shikari> yeah, x86 has 7
[08:40:36] <Dark_Shikari> but nevermind that, they claimed it was halting-problem hard
[08:40:46] <Dark_Shikari> merbzt: was it you who told me how to use ccc-analyzer?
[08:40:55] <Dark_Shikari> when I compiled llvm/clang it didn't come with ccc-analyzer...
[08:43:08] <astrange> it's a perl script in http://checker.minormatter.com/checker-240.tar.bz2
[08:43:48] <Dark_Shikari> ah
[08:44:45] <astrange> it's also practically useless for c but you can try it every so often
[08:44:54] <Dark_Shikari> er.... merbzt I think ran it on ffmpeg
[08:44:57] <Dark_Shikari> and got like 400+ results
[08:45:01] <Dark_Shikari> many of which were real bugs
[08:45:07] <Dark_Shikari> And I don't see it in that tar.gz
[08:45:14] <Dark_Shikari> I see a binary compile of a half year old version of clang
[08:45:30] <Dark_Shikari> oh, libexec
[08:46:26] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/ most of these aren't real bugs
[08:46:37] <Dark_Shikari> well just ignore the dead stores
[08:46:40] <Dark_Shikari> those are always useless
[08:46:50] <astrange> if i turned on experimental analyses it'd warn whenever a function called malloc() and returned the result
[08:46:58] <astrange> and on any cast to av_alias, i think
[08:47:03] <astrange> but those are experimental at least
[08:49:45] <Dark_Shikari> damn, it's pretty slow.
[08:50:22] <Dark_Shikari> like, taking 10 seconds for single functions slow
[08:50:45] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/report-XkkEMF.html#EndPath well... that one's valid
[08:50:56] <KotH> Dark_Shikari: hmm.. what is the difference between NP complete and halting problem hard for someone who isnt CS savy?
[08:51:17] <Dark_Shikari> KotH: NP complete means that we think it can probably only be solved in exponential time with respect to the size of the input
[08:51:24] <Dark_Shikari> more specifically
[08:51:33] <Dark_Shikari> if you have a polynomial-time algorithm for ANY np-complete algorithm
[08:51:38] <astrange> np can be checked polynomial and maybe only solved optimally in exponential
[08:51:43] <Dark_Shikari> you can use that to solve _any other_ NP-complete problem.
[08:51:52] <astrange> halting problem is unsolvable in finite time for some input
[08:52:06] <Dark_Shikari> and yeah, that.
[08:52:17] <KotH> hmm... WTF?
[08:52:24] <Dark_Shikari> to which
[08:52:48] <Dark_Shikari> in short, P is Easy, NP is Hard, halting is Impossible
[08:52:49] <astrange> i think that guy was just mad that people kept reporting RA bugs
[08:53:11] <astrange> that was before 4.4 had a new ra so at that point the last two or three projects to write one had failed
[08:53:55] <KotH> yes, but still, claiming something as impossible to solve isnt going to help you
[08:54:04] <Dark_Shikari> KotH: sure it does
[08:54:08] <Dark_Shikari> if you know that X is impossible
[08:54:15] <Dark_Shikari> and solving Y means you could solve X
[08:54:18] <Dark_Shikari> that means solving Y is impossible
[08:54:22] <Dark_Shikari> Equally, with NP-completeness
[08:54:24] <Dark_Shikari> if you know X is hard
[08:54:28] <Dark_Shikari> and you can prove Y is at least as hard as solving X
[08:54:31] <Dark_Shikari> then Y is hard too.
[08:54:58] <Dark_Shikari> That's what NP-completeness is all about: X is hard, and if I could solve Y easily, I could also solve X easily.  So Y is probably hard too.
[08:56:42] <KotH> Dark_Shikari: yes, from a theoretical point of view. but if you are dealing with users, then telling them that the problem is so hard you cannot solve it, doesnt help
[08:56:52] <Dark_Shikari> Sure it does.
[08:56:55] <KotH> Dark_Shikari: even if it's true (which isnt in this case)
[08:56:57] <Dark_Shikari> Your boss says he wants an optimal solution for X
[08:57:07] <Dark_Shikari> you tell him it's NP-complete, thus practically not possible, so you will have to use an approximation instead.
[08:57:33] <KotH> juup
[08:57:45] <Dark_Shikari> approximation algorithms for Hard Problems is also a big domain of complexity theory
[08:57:51] <Dark_Shikari> proving that a given algorithm will always get within some factor of optimal
[08:58:07] <Dark_Shikari> some problems are really "easy" in that regard
[08:58:14] <Dark_Shikari> for example, suppose you have two hard disks and a bunch of files
[08:58:26] <Dark_Shikari> and you want to maximize the number of files that you can fit on the disks (the rest will go on tape backup)
[08:58:52] <Dark_Shikari> So you sort the files by increasing size.  Start at the smallest, stick them all on disk one.  Then when disk one fills up, stick the rest on disk two, in order of increasing size as per before.
[08:59:01] <Dark_Shikari> You're guaranteed to get within one file of optimal.
[08:59:20] <Dark_Shikari> Even though the actual problem is NP-complete.
[08:59:42] <Dark_Shikari> so optimal takes exponential time, one-less-than-optimal costs one sort.
[09:00:53] <merbzt> Dark_Shikari: yes it was me
[09:01:01] <Dark_Shikari> no problem, got it working now
[09:01:05] <merbzt> you need to compile llvm with clang
[09:01:05] <Dark_Shikari> it's slooooooooowly going
[09:01:22] <merbzt> you need to compile in release mode
[09:01:28] <merbzt> but it is slow anyway
[09:05:12] <scaphilo> question: how would i find the forward motion vector for a specific mb in motion_val: here? motion_val[0][mb_xy][0 and 1] but mb_xy-address of a pixel or of a macroblock?
[09:05:24] <scaphilo> http://dpaste.com/184460/
[09:06:15] <scaphilo> it looks as if its grid is pixel but thats a bit strange for me
[09:06:25] <Dark_Shikari> probably the address of a partition
[09:06:33] <Dark_Shikari> for mpeg-2 it'd probably be per-mb
[09:06:37] <Dark_Shikari> for mpeg-4, probably per 8x8
[09:06:42] <Dark_Shikari> for h264, probably per 4x4
[09:07:04] <scaphilo> so i have to find out how its stored in mpeg2
[09:07:16] <scaphilo> that could be different
[09:07:26] <scaphilo> ill check that
[09:07:29] <Dark_Shikari> merbzt: so where does it put the results?
[09:20:08] <scaphilo> Well this explains why i dont find any motion vectors in my motion val. Do i have to set this manually or is there a way to set it in command line?        if(s->current_picture.motion_val[0] && !s->encoding){ //note motion_val is normally NULL unless we want to extract the MVs
[09:38:15] <peloverde> wbs, there is already a bug open about the aac delay
[09:38:31] <wbs> peloverde: yeah, saw that one
[09:39:02] <wbs> I was actually mostly interested in knowing how it is supposed to be signalled
[09:39:44] <wbs> for a streaming case (like rtp or something similar) where one can't really add edit lists or something such; would it be sensible to offset the packet timestamps with the encoder delay?
[09:40:08] <wbs> so if the first encoder input data would have timestamp 0, the first output packet would get a timestamp of -delay?
[09:50:02] <scaphilo> question by the way: With which tool do you develop c apps in linux? eclipse is crap
[09:50:12] <Dark_Shikari> vim
[09:52:42] <KotH> scaphilo: lol
[09:52:45] <scaphilo> not really? that takes 100 times longer to dev something i mean you can do so with object oriented languages but not with c
[09:53:10] <KotH> scaphilo: forget everyhting you learned about programming you heard at HSR or from people "programming" on windows
[09:53:16] <scaphilo> Dark_shikari nano is better by the way ;-)
[09:53:18] <KotH> scaphilo: they are all lagging about 20 years behind the times
[09:53:53] <elenril> lolnano
[09:54:02] <scaphilo> its better than vi
[09:54:13] <Dark_Shikari> vi != vim
[09:54:15] <KotH> it's better than sun's vi.. taht for sure ;)
[09:54:18] <Dark_Shikari> also, merbzt, thanks, already found two bugs.
[09:54:42] <elenril> what D_S said, +vi has some neat features ;)
[09:55:25] <scaphilo> am your kidding me you dont code with vim are you?
[09:55:58] * wbs codes with vim
[09:56:13] * elenril writes pretty much everything in vim
[09:56:35] * Dark_Shikari mostly uses notepad++, but uses vim whenever he's on unix
[09:57:04] * peloverde codes exclusively in vim
[09:57:54] <peloverde> I hear some others around here use emacs
[09:58:34] <scaphilo> am ... but ... c ? you have to jump arrount the code. Does vim support this references or what?
[09:58:43] <scaphilo> from one file to an other
[09:59:05] <Dark_Shikari> ctags
[09:59:42] <wbs> scaphilo: just open a few xterms with a vim session in each, and use / for searching within the current file
[10:00:34] <peloverde> I use grep to find the relevant file then open it as a new buffer
[10:00:37] <scaphilo> perhpas i have to test vim as well ... i never expected that :-)
[10:01:04] <scaphilo> thats so strange
[10:01:15] <Dark_Shikari> welcome to the world of development on every OS except windows
[10:02:08] <scaphilo> early days eclipse was a good way to do that
[10:02:24] <astrange> i use the xcode organizer window + ack for searching, terminal editors don't quite do it for me
[10:02:28] <scaphilo> but currently i develop pyhton and java with a texteditor
[10:02:29] <astrange> ctags would be faster than ack, though
[10:04:02] <scaphilo> thank you for this info, ill have to check out this kind of developing c
[10:04:40] <wbs> why wouldn't you have to "jump around" just as much when developing in some "object-oriented language"?
[10:05:20] <Dark_Shikari> in fact I would think you would have to jump aroudn more ...
[10:05:27] <Dark_Shikari> since everything is divided into five gajillion classes
[10:05:39] <scaphilo> just because you always know where you find the function your looking for
[10:06:28] <scaphilo> in c i never no where i have to look for it
[10:06:37] <Dark_Shikari> that sounds like a case of knowing the code vs not knowing the code
[10:06:39] <Dark_Shikari> nothing to do with the language
[10:08:52] <scaphilo> its a bit of both i think. but if you really code nicely with an oo language its easier to revers engineer
[10:09:32] <scaphilo> anyway i was just wondering how your developing in c. i cant change the language its the most efficient
[10:09:42] <wbs> no, then you haven't seen the cases in OOP where you split up everything into interfaces and stubs and never know where the actual implementation is
[10:09:52] <Dark_Shikari> wbs: with multiple inheritance, of course
[10:10:04] <Dark_Shikari> and of course, you have that great pattern where you have one class per interface
[10:10:11] <Dark_Shikari> which is really fun!
[10:10:29] <scaphilo> well i dont prefer java
[10:10:37] <scaphilo> python doesnt have this problems
[10:10:38] <astrange> i tried to find the code in audacity that draws the waveform display and gave up eventually
[10:10:47] <Dark_Shikari> python isn't an OO language
[10:10:50] <Dark_Shikari> it's a multi-paradigm language
[10:11:22] <astrange> except for the paradigms the maintainers claim not to understand
[10:11:23] <Dark_Shikari> if you're boring, stupid, and like java, you can write tons of OO code in it.
[10:11:27] <Dark_Shikari> lol
[10:11:38] <astrange> like tail calls
[10:12:03] <elenril> wbs: that's even more fun in C
[10:12:10] <elenril> *cough*wine*cough*
[10:12:30] <Dark_Shikari> closures in C are fun
[10:15:23] <scaphilo> this is fun: define private public :-D
[10:15:57] <KotH> scaphilo: ever worked in a comercial enviroment?
[10:16:10] <KotH> scaphilo: ie, programming or reading code written by "professionals"?
[10:16:21] <scaphilo> no
[10:16:38] <KotH> be glad... be very glad...
[10:17:17] <wbs> peloverde: any comment on the aac/timestamps issues in streaming, as I mentioned a few screens up?
[10:17:20] <KotH> even mplayers code as it was 10y ago,was very clean and well structured to what can be seen in software companies
[10:17:41] <KotH> and it doesnt matter whether it's c, c++, java or pascal...
[10:18:01] <peloverde> wbs, no idea i don't do streaming, I would look at the relevant RFCs
[10:18:11] <scaphilo> oh you mean this microsoft code? thats bader than ugly
[10:18:29] <KotH> i think, worst i've ever seen was an implementation of a ring buffer in c. there were at least 15 bugs (thinkos) within less than 100 loc
[10:18:41] <Dark_Shikari> the daily wtf has worse.
[10:18:43] <Dark_Shikari> Always.
[10:18:57] <Dark_Shikari> http://thedailywtf.com/Articles/The-Doubleton-Patten.aspx from the other day is a fun one
[10:19:03] <KotH> and that whole shit worked only, because the ring buffer dropped a byte once in a while
[10:19:06] <Dark_Shikari> http://thedailywtf.com/Articles/The-Doubleton-Patten.aspx is brilliant
[10:19:34] <KotH> Dark_Shikari: tdwtf is a collection what can be seen worldwide... that's a much larger sampling base than i have :)
[10:20:04] <Dark_Shikari> indeed
[10:20:17] <Dark_Shikari> er, oops
[10:20:22] <Dark_Shikari> the second link was supposesd to be http://thedailywtf.com/Articles/Check-Digit-Check.aspx
[10:20:36] <Dark_Shikari> That page is why we should ban ctrl-V from use by new programmers.
[10:22:14] <scaphilo> very mice
[10:22:17] <scaphilo> nice
[10:32:00] <Kovensky> <@wbs> scaphilo: just open a few xterms with a vim session in each <-- pfft xterms, use gnu screen :>
[10:32:17] <Kovensky> or emacs buffers :>
[10:33:30] <jai> astrange: http://code.google.com/p/audacity/source/browse/audacity-src/trunk/src/FreqWindow.cpp isn't it?
[10:34:07] * elenril throws http://vimdoc.sourceforge.net/htmldoc/windows.html#windows at Kovensky 
[10:36:05] <elenril> hmm, picking individual lines/hunks to commit in git gui is nice
[10:36:23] <Kovensky> desyou
[10:36:25] <peloverde> I prefer git add -p
[10:36:36] <peloverde> though as long as you are using git I don't really care :)
[10:36:47] <elenril> o_0
[10:37:11] <elenril> yeah, i was just doing to say i'd prefer doing it vim
[10:37:15] <Kovensky> git add -p doesn't seem to have line accuracy, though I only read the short description
[10:37:16] * elenril should rtfm more often
[10:38:02] * Kovensky goes to college :V
[10:38:06] <peloverde> 'e' puts it in line by line mode
[10:38:38] <elenril> this is awesome
[10:38:53] <elenril> why are people still using svn? </troll>
[10:42:20] <jai> because svn has revision numbers </lame-retort>
[10:53:01] <pJok> ffmpeg should use cvs </lame-troll>
[12:22:22] <CIA-81> ffmpeg: conrad * r22889 /trunk/libavformat/ (oggdec.c oggdec.h): oggdec: Remove write-only variable
[12:22:23] <CIA-81> ffmpeg: conrad * r22890 /trunk/libavformat/oggdec.c: oggdec: Fix duration calculation if the last page in a file has no granule
[12:22:24] <CIA-81> ffmpeg: conrad * r22891 /trunk/libavformat/oggdec.c: oggdec: Move warning about missing granule to the correct place
[12:22:24] <CIA-81> ffmpeg: conrad * r22892 /trunk/libavcodec/vp3.c: vp3: Remove internal debug statement
[12:22:25] <CIA-81> ffmpeg: conrad * r22893 /trunk/libavcodec/vp3.c:
[12:22:25] <CIA-81> ffmpeg: vp3: More buffer length checks
[12:22:25] <CIA-81> ffmpeg: .5% slower to fix some crashes on invalid streams
[14:16:26] <BBB> superdump: ping, how's marcelo's qualification task going?
[14:17:45] <superdump> he contacted me asking a few questions, i saw it late at night a couple of nights ago and only responded when i remembered last night
[14:17:57] <superdump> i haven't seen anything more code-wise yet though
[14:18:08] <superdump> we'll see
[14:19:02] <BBB> can you ask him to be on irc?
[14:19:12] <BBB> it'd be useful to be able to discuss with him and see how good he really is
[14:19:34] <BBB> as in: does he understand C? does he get ffmpeg? does he understand how you'd write a decoder, basics? can he read specs? etc.
[14:52:29] <superdump> BBB: true
[14:52:49] <superdump> i don't know that he'll/i'll have time for that before the deadline though :/
[14:53:02] <BBB> for the qualtask, you mean?
[14:53:03] <BBB> that's true
[14:53:08] <BBB> that's why I want at least a feel of his skills
[14:53:20] <BBB> I did it lastyear, just sit with the student on IRC for a night discussing his qualtask
[14:53:37] <BBB> was very enlightening
[14:55:27] <wbs> BBB: in a positive or negative way? :-)
[14:55:40] <BBB> unfortunately that was in a negative way
[14:56:11] <wbs> ok, but it's at least good to be enlightened about such things as early as possible
[14:58:30] <BBB> exactly
[20:17:15] <bcoudurier> hi guys
[20:17:39] <BBB> hello bcoudurier
[20:17:50] <BBB> do you know anything about mchinen's qualtask for gsoc?
[20:18:00] <bcoudurier> sure
[20:21:05] <BBB> how's he progressing?
[20:31:15] <bcoudurier> not much yet
[20:37:12] <CIA-81> ffmpeg: mstorsjo * r22894 /trunk/libavformat/mov.c:
[20:37:13] <CIA-81> ffmpeg: Parse strf mov atoms
[20:37:13] <CIA-81> ffmpeg: This fixes roundup issue 1270.
[20:42:50] <wbs> hooray, my first attempt at meddling with mov containers \o/
[20:43:02] <BBB> \o/
[20:43:13] <BBB> on to RE'ing codecs!
[20:43:29] <BBB> before you know, you'll be messing with fuzzy SSE3 code that nobody including you understands
[20:45:29] <wbs> yeah, RE'ing codecs (or generally implementing stuff that has got proper specs) would be really interesting, too
[20:45:41] <wbs> let's see when I get a bad enough itch that I try to scratch :-)
[20:49:50] <saintd3v> BBB: black magic :O
[20:50:07] <BBB> isn't most of ffmpeg black magic?
[20:53:43] <wbs> BBB: btw, do you know someone who knows rtp/aac in intimate detail?
[20:53:55] <BBB> luca abeni
[20:53:56] <wbs> (I'm wondering about a thing that I didn't find any answer to in the RFCs)
[20:54:19] <BBB> luca abeni is our rtp god
[20:54:34] <BBB> but you can always try and maybe one of us knows
[20:55:03] <Kovensky> isn't luca lu_zero
[20:55:10] <BBB> that's luca barbato
[20:55:39] <wbs> ok - I discussed this thing with peloverde earlier today... in AAC, the encoder inserts some undefined number of samples at the start of the stream (that the decoder actually outputs)
[20:56:08] <wbs> to get back to proper sync, the number of extra samples need to be communicated out of band in some way, and these should ideally be dropped before returning them to the user
[20:56:37] <wbs> for mp4, this can be done with edit lists, but if doing a rtp stream with aac audio, how is this delay communicated?
[20:57:07] <BBB> aha
[20:57:13] <BBB> I would expect the SDP to contain that information
[20:57:38] <BBB> not sure where exactly, though...
[20:57:43] <wbs> one guess is that one should offset the timestamps by the number of inserted samples, so that the decoded stream seems to start n samples earlier than it actually does, so that the first user-inputted sample lands at the correct timestamp
[20:57:51] <wbs> yeah, that was my guess too, but didn't find anything such
[20:58:59] <BBB> hm, ok, so I guess ask luca abeni then
[20:59:30] <wbs> ok, will do :_)
[21:03:22] <Kovensky> <@BBB> that's luca barbato <-- well... he IS luca :>
[21:03:26] <Kovensky> just the wrong luca =p
[21:03:31] <BBB> indeed
[21:03:55] <wbs> good thing that both of them work with rtsp/rtp, too ;P
[21:04:15] * Kovensky wonders if one is a fork() of the other
[22:59:49] <CIA-81> ffmpeg: bcoudurier * r22895 /trunk/ffmpeg.c:
[22:59:49] <CIA-81> ffmpeg: Take ticks per frame into account when warning about difference between
[22:59:49] <CIA-81> ffmpeg: container and codec frame rate.
[23:00:53] <Kovensky> what is "ticks per frame"?
[23:01:24] <Kovensky> the length of a CFR stream's frame in time_base units?
[23:48:52] <ramiro> in case anyone is interes in microsoft's smooth streaming whatever for silverlight: http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=1&t=1371
[23:50:36] <ramiro> there's some code that the user in the forum says could be made lgpl, even though the original code uses creative commons for noncommercial use (which i believe might not be compliant to the lgpl)