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

[irc at mansr.com]

[00:00:21] <lu_zero> hi
[00:00:24] <lu_zero> I'm back home
[00:00:36] <Compn> wb
[00:00:48] <iive> lu_zero: i hope you had changed your irc client.
[00:00:55] <Compn> lol
[00:08:54] <CIA-17> ffmpeg: michael * r21681 /trunk/libavcodec/ (h264.c h264_direct.c): Set x264_build so that checks are simpler.
[00:13:30] <lu_zero> iive: changed?
[00:14:25] <iive> bitchx is not maintained and there are known exploits.
[00:14:46] <iive> you were quitting few days ago with message "excess flood"
[00:17:17] <lu_zero> I have irssi here
[00:17:27] <lu_zero> yet I'm missing bx
[00:21:16] <iive> well, fork and maintain it, if you like it. Just make sure you won't be exploited.
[00:23:21] <Compn> lu_zero : anyone have any interesting comments or questions at fosdem ?
[00:23:22] <Compn> hehe
[00:30:54] * lu_zero is currently sleeping more or less
[00:33:13] <Compn> oh sorry :)
[00:40:33] <iive> lu_zero: you'd better make it more soon, than make it less later.
[00:44:03] <CIA-17> ffmpeg: michael * r21682 /trunk/libavcodec/ (h263dec.c mpeg4videodec.c): Change xvid/divx/lavc build variables to be consistent to x264_build.
[02:10:19] <CIA-17> ffmpeg: michael * r21683 /trunk/libavcodec/h264_direct.c:
[02:10:19] <CIA-17> ffmpeg: Replace call to pred_motion() in direct spatial mv pred by code
[02:10:19] <CIA-17> ffmpeg: and simplify cases that cannot happen away.
[02:10:19] <CIA-17> ffmpeg: 8 cpu cycles faster
[02:11:49] <CIA-17> ffmpeg: michael * r21684 /trunk/libavcodec/h264_direct.c: Remove incorrect fixme, i see no case that is missing.
[03:23:19] <CIA-17> ffmpeg: michael * r21685 /trunk/libavcodec/h264_direct.c:
[03:23:19] <CIA-17> ffmpeg: Branchless calculation of ref_offset.
[03:23:19] <CIA-17> ffmpeg: 7 cpu cycles faster.
[04:25:48] <CIA-17> ffmpeg: michael * r21686 /trunk/libavcodec/h264.h:
[04:25:48] <CIA-17> ffmpeg: Remove an apparently unneeded && !FRAME_MBAFF.
[04:25:48] <CIA-17> ffmpeg: This should speed the affected cases (MBAFF temporal direct MBs) up.
[05:06:23] <astrange> Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption
[05:06:32] <astrange> i guess clang analyzer can't run on ffmpeg anymore
[05:07:09] <Dark_Shikari> lol
[06:17:16] <jai> kierank: ping
[06:53:58] <benoit-> good morning
[06:55:11] <jai> bonjour
[06:56:02] <kshishkov> god morgon
[07:12:56] <kshishkov> wow, now PayPal loves Indians almost as much as Ukrainians
[07:13:03] <astrange> http://github.com/chattama/ffmpeg-s60/
[07:56:05] <andoma> morning
[07:56:08] <andoma> superdump: ?
[07:56:11] <kshishkov> god morgon
[07:56:16] <superdump> god morgon
[07:56:20] <andoma> :)
[07:56:37] <superdump> andoma: did you see my queries?
[07:56:39] <andoma> yeah
[07:57:15] <andoma> btw, can i remove the files? :)
[07:58:25] <superdump> yes
[07:58:35] <andoma> okei
[09:04:59] <CIA-17> ffmpeg: benoit * r21687 /trunk/ffmpeg.c:
[09:04:59] <CIA-17> ffmpeg: Stop reading input file when -t option value is reached.
[09:04:59] <CIA-17> ffmpeg: Patch by Wolfram Gloger wmglo (chez) dent med uni (minus) muenchen de
[09:29:40] <siretart> hi!
[09:30:08] <Dark_Shikari> so, siretart, given the discussion earlier
[09:30:13] <Dark_Shikari> what's the best solution?
[09:30:24] <Dark_Shikari> oh, I guess you were away so you missed the logs
[09:30:37] <siretart> Dark_Shikari: I don't have the backlog available, and I fell immediately to bed yesterday
[09:30:58] <siretart> I guess you are referring on how to handle libx264.c for ffmpeg 0.5.1?
[09:31:20] <Dark_Shikari> http://pastebin.com/m10fe0819
[09:31:38] <siretart> .o( referring to? - hmm. oh my english ...)
[09:32:28] <kshishkov> siretart: yes, German as native language may spoil any other language skills
[09:32:31] <twnqx> i thought the discussion went more along the lines of "the 0.5 branch is old, doesn't receive updates e.g. codecs, doesn't receive bugfixes except for security things, don't use it"? :P
[09:32:37] <siretart> kshishkov: I fear so.
[09:32:39] <twnqx> kshishkov: it does :(
[09:33:16] <DonDiego> twnqx: i'm sure there was all sorts of discussion, the question is whether or not the discussion is relevant
[09:33:31] <siretart> Dark_Shikari: I don't think it is necessary to support each and every version in between since the release of ffmpeg 0.5. However not supporting the x264 version that 0.5 did support would be an undesireable regression
[09:33:31] <DonDiego> i'm the release manager for the 0.5 branch with siretart as second in command
[09:33:44] <siretart> oh, hi DonDiego :-)
[09:34:03] <Dark_Shikari> siretart: so you're fine with forcing everyone to use "latest git x264, OR 0.5 x264?"
[09:34:07] <twnqx> DonDiego: i see. well, if you think it's worth your time, i won't stop you.
[09:34:19] <DonDiego> i think it is
[09:34:38] <siretart> Dark_Shikari: replace 'latest git x264' with 'latest x264 as of $today' with a clear definition of today, and I think that would sound fine
[09:35:04] <Dark_Shikari> That sounds like a great idea
[09:35:06] <siretart> the point is to avoid regressions for users
[09:35:10] <Dark_Shikari> yet anoter way to force people to upgrade!
[09:35:43] <twnqx> i wouldn't consider "hey, i can compress better" or "hey, i can play those blurays i couldn't before" a regression. but that's just me.
[09:35:47] <siretart> ffmpeg 0.5 requires x264 API 67 AFAIUI
[09:36:11] <Dark_Shikari> ok, I guess I'll go do that tomorrow then
[09:36:21] <siretart> if fmpeg 0.5 works with *both* API v67 and 85 (or whatever you consider recent enough), that would work for me
[09:36:43] <Dark_Shikari> ok
[09:42:57] <DonDiego> ping luca b about this please
[09:43:07] <DonDiego> they have a x264 version in gentoo
[09:43:13] <DonDiego> that is not compatible with 0.5
[09:43:27] <siretart> DonDiego: I talked with him about that saturday night
[09:43:45] <DonDiego> ok, then you are already taking it into account, good
[09:44:02] <siretart> DonDiego: in the 'stable' 'branch', they already moved away from 0.5 to a newer snapshot exactly because of x264 requiring a newer ffmpeg
[09:44:22] <siretart> which is now a bit unfortunate, but I think we can avoid that in future
[09:45:58] <siretart> bilboed-pi: around? I hear that you care for gst-ffmpeg? Is that information correct?
[09:46:13] <bilboed-pi> I'm the maintainer of gst-ffmpeg, so yes :)
[09:46:23] <siretart> bilboed-pi: ah excellent.
[09:46:39] <siretart> bilboed-pi: AFAIUI gst-ffmpeg currently tracks the 0.5 branch of ffmpeg. is that still the case?
[09:46:42] <bilboed-pi> siretart, why do I have this feeling I know you from somewhere ?
[09:46:51] <bilboed-pi> siretart, no, trunk gst-ffmpeg has switched to a more recent checkout
[09:47:11] <siretart> bilboed-pi: I maintain the debian&ubuntu package, and now joined ffmpeg to help out with releases
[09:47:28] <siretart> bilboed-pi: can you please elaborate why you moved to a more recent revision?
[09:47:46] <Dark_Shikari> because people like wmapro support and bugfixes ? ;)
[09:47:51] <bilboed-pi> siretart, due to lack of ffmpeg releases basically
[09:48:28] <siretart> bilboed-pi: well, the plan is to have a 12 month release cycle. is that too slow for gst-ffmpeg needs?
[09:48:55] * Kovensky thinks that is too slow for ffmpeg's development pace
[09:48:56] <bilboed-pi> siretart, count the average number of commits per day to ffmpeg, multiply by 365, then think
[09:49:31] <bilboed-pi> and yes, I'd much prefer a 3month release cycle of ffmpeg.. but hey... what can I do about it :(
[09:49:36] <superdump> 6 months? 4 months? 3 months?
[09:49:57] <bilboed-pi> 6 months was the initial idea iirc
[09:50:02] <siretart> bilboed-pi: well, I see the picture of a distribution perspective. there it is undesireable to have gst-ffmpeg to build against a private ffmpeg copy, and having the internal copy going out of sync with the system ffmpeg has provoked lots of crashes in the past
[09:50:10] <bilboed-pi> siretart, it's not a private copy
[09:50:19] <bilboed-pi> siretart, it's a specified unmodified upstream svn revision
[09:50:21] <Dark_Shikari> 3 months sounds good to me
[09:50:30] <Dark_Shikari> with a one week feature freeze before release
[09:50:32] <bilboed-pi> s/specified/specific/
[09:50:33] <siretart> bilboed-pi: which from a distro perspective, is an internal/private copy
[09:51:07] <siretart> Dark_Shikari: 3 months is way too fast for a) distros, b) what we can bring up manpower for
[09:51:15] <bilboed-pi> err... no, 3 months is fine
[09:51:30] <Dark_Shikari> siretart: x264 does a 1 week release cycle generally
[09:51:34] <bilboed-pi> Dark_Shikari, eheheh :)
[09:51:42] <bilboed-pi> Dark_Shikari, you're no longer releasing at every commit ? :)
[09:51:48] <Dark_Shikari> we release at every weekly commit spree
[09:51:55] <superdump> commits come in lumps
[09:51:58] <bilboed-pi> right
[09:52:00] <siretart> Dark_Shikari: which is ridiculus from a distro perspective. it seems to work for you, though...
[09:52:03] <Dark_Shikari> no other commits are made except for critical fixes/regression tests
[09:52:17] <Dark_Shikari> siretart: the distro can pick any particular "release" and use it.
[09:52:22] <siretart> Dark_Shikari: you also have to consider that distro releases tend to be much longer around than we care for
[09:52:42] <Dark_Shikari> I mean, conceptually, think about ffmpeg
[09:52:45] <superdump> i don't think keeping up with weekly x264 is necessary for a main distro repo
[09:52:51] <siretart> releases are syncronisation points. if we make too many, then they are pointless for coordination
[09:52:53] <Dark_Shikari> in practice, it doesn't matter which version is made the "release"
[09:52:56] <superdump> that's more a ppa type-thing
[09:52:57] <Dark_Shikari> superdump: of course.
[09:53:02] <Dark_Shikari> I don't intend anyone to update every week
[09:53:11] <Dark_Shikari> I intend people to pick a week, and make that their release
[09:53:12] <bilboed-pi> Dark_Shikari, give or take regressions, but yes
[09:53:27] <bilboed-pi> Dark_Shikari, the tricky part is figuring out regressions when making releases.
[09:53:34] <Dark_Shikari> the point being that how often a distro chooses to release shouldn't have any relation to how often an application is released
[09:53:41] <Dark_Shikari> it should have to do with the distro's practices
[09:53:43] <Dark_Shikari> and nothing else
[09:54:01] <superdump> Dark_Shikari: i often see that one week a bunch of new features come in and then the next week fixes for those features land where mistakes were made
[09:54:08] <Dark_Shikari> This is true
[09:54:15] <DonDiego> i've come to think that x264 is what gives us the reputation of breaking api often..
[09:54:18] <superdump> for a distribution it would be better to freeze features and make sure things are fixed
[09:54:19] <siretart> bilboed-pi: which release of gst-ffmpeg moved away from ffmpeg 0.5?
[09:54:30] <Dark_Shikari> DonDiego: the people who complain about breaking api are calling apps
[09:54:32] <Dark_Shikari> not people compiling things
[09:54:41] <bilboed-pi> siretart, trunk
[09:54:44] <Dark_Shikari> and almost all the complaints are likely due to two things
[09:54:46] <bilboed-pi> siretart, i.e. the upcoming one
[09:54:48] <Dark_Shikari> 1) the really big break a while back
[09:54:53] <Dark_Shikari> 2) the option name changes, oh god the option name changes
[09:54:57] <Dark_Shikari> ffmpeg is far worse than x264 at that
[09:55:03] <siretart> bilboed-pi: when is it scheduled for release?
[09:55:11] <bilboed-pi> siretart, within a few weeks (a month max)
[09:55:20] <jai> kierank: ping ^ 2
[09:55:37] <siretart> bilboed-pi: okay. then you should note that we intend to branch 0.6 in that time frame
[09:55:52] <jai> was the policy decided for 0.6?
[09:55:56] <bilboed-pi> siretart, then we'll update it when that happens, not before
[09:55:56] <Dark_Shikari> what?  0.6 is already coming?
[09:56:01] <jai> superdump: ^
[09:56:02] <bilboed-pi> also, this is news for me
[09:56:08] <siretart> bilboed-pi: that sounds great
[09:56:08] <twnqx> <siretart> Dark_Shikari: which is ridiculus from a distro perspective. it seems to work for you, though... <-- the reason is simple. x264 adds relevant features or bugfixes in regular intervals.
[09:56:22] <twnqx> which are way below 3month cycles
[09:56:30] <siretart> twnqx: true. but they won't be included in distro releases
[09:56:33] <bilboed-pi> siretart, but I don't want us to detect 12 months of regressions at once
[09:56:44] <bilboed-pi> siretart, which is why we've currently updated to a more recent checkout
[09:56:55] <twnqx> siretart: that's why i use gentoo. my system ffmpeg is svn, updates weekly, my system x264/mplayer/many others as well.
[09:57:16] <bilboed-pi> twnqx, afaik, the gst-ffmpeg ebuild doesn't use the system ffmpeg
[09:57:27] <siretart> bilboed-pi: experimenting with an updated trunk to spot regression is of course necessary. I'd like to avoid having distros package gst-ffmpeg that come with an internal copy of avcodec
[09:57:32] <twnqx> neither does mplayer. i couldn't make the switch to ffmpeg-mt as system lib yet :(
[09:58:05] <siretart> twnqx: that's more a '-snapshot' package. this is of course fully ligitimate, but not what I'm talking about
[09:58:13] <jai> twnqx: write your won ebuild ;)
[09:58:16] <jai> *own
[09:58:27] <Dark_Shikari> well there needs to be a balance somewhere
[09:58:29] <twnqx> jai: i do have one, but the API changes break everything :P
[09:58:32] <Dark_Shikari> 1) you need people on recent versions to catch regressions
[09:58:41] <siretart> jai: as for 0.6, we intend to get 0.5.1 out of the door RSN, and then start working on 0.6
[09:58:42] <Dark_Shikari> 2) but you want most people to not deal with regresions
[09:58:49] <jai> twnqx: thats ofcourse a problem till mt is merged into trunk
[09:59:00] <Dark_Shikari> :/ mt
[09:59:31] <jai> siretart: ah, i'm more "concerned" about 0.6 because 0.5.x isnt something where things can be improved/changed
[09:59:54] <kshishkov> jai: it will be merged before Duke Nukem Forever is revived and finished ;)
[10:00:05] <jai> kshishkov: hehe :)
[10:00:20] <siretart> bilboed-pi: I'd really appreciate it if you would ping me before you release the next gst-ffmpeg release, so that we can discuss the 0.6 'situation' and status again. would that work for you?
[10:00:49] <Dark_Shikari> it's like dll hell all over again
[10:00:58] <siretart> jai: I have a couple of approved patches for 0.5.1, which I'll work on committing this week.
[10:00:58] <bilboed-pi> siretart, you could start testing the current gst-ffmpeg trunk
[10:01:11] <twnqx> Dark_Shikari: in certain ways, yes, sadly
[10:01:15] <Dark_Shikari> except worse
[10:01:16] <bilboed-pi> siretart, otherwise we do pre-releases 1-2 weeks before releases
[10:01:18] <Dark_Shikari> because dll hell was the _solution_
[10:01:23] <bilboed-pi> siretart, which is common to all gstreamer modules
[10:01:30] <jai> siretart: so did you get the whole bugfixes issue sorted out
[10:01:35] <siretart> bilboed-pi: okay, in that case, please inform me about such a pre-release, ok?
[10:02:05] <bilboed-pi> siretart, I'm pretty sure slomo updates the debian gst-ffmpeg package within hours of pre-releases
[10:02:08] <siretart> jai: yes, DonDiego and I went through 'my' distro packages and figured out what is acceptable for 0.5 and what not
[10:02:32] <twnqx> Dark_Shikari: the problem also is a difference in user expectation, with people like me wanting to have the latest features and accepting the occasional bug, while others put stability first and don't care about features
[10:02:33] <jai> siretart: could this criteri[on|a] be made public please?
[10:02:50] <Dark_Shikari> twnqx: well yes.  for the latter, we have debian stable
[10:03:01] <siretart> bilboed-pi: I'd be pretty disappointed of him if he decided to not use the system ffmpeg packages anymore for gst-ffmpeg.
[10:03:02] <Dark_Shikari> where "stability" means "unchanging" as opposed to "not broken"
[10:03:02] <jai> i understand you are "The Release Guys" but we would love to know as well
[10:03:10] <jai> :)
[10:04:18] <siretart> jai: well, the general plan is to include everything that helps distro packages. we want distros to use the release branch and not have them carry tons of regression fixes around
[10:04:22] <kshishkov> jai: in this case they are "the distro guys"
[10:04:40] <siretart> jai: which means that regression fixes are qualified (almost) automatically
[10:05:14] <siretart> jai: as for feature backports, that is to be decided on a case-by-case basis. we need to do a risk estimation for regression potential
[10:05:22] <siretart> jai: does this help?
[10:05:22] <Dark_Shikari> and effort requirement
[10:05:26] <Dark_Shikari> backporting new features is harder
[10:05:43] <pross-au> Dark_Shikari: git solves that for us
[10:05:44] <pross-au> :D
[10:05:49] <Dark_Shikari> no, it's still more work
[10:06:00] <siretart> Dark_Shikari: depends on the feature. the/your libx264.c backport seems to me a less risky one than e.g. the proposed wmapro backport I have on the table
[10:06:04] <jai> siretart: yes, thats why i didnt mention anything about new features (decoders|demuxers|...). i meant going over closed roundup issues and commiting those changes to the branch
[10:06:40] <Dark_Shikari> siretart: yes, by features I meant things in ffmpeg
[10:06:49] <Dark_Shikari> if you wanted me to, say, backport _new x264 features_
[10:06:53] <Dark_Shikari> to an old x264 revision
[10:06:56] <Dark_Shikari> that would be equally hard
[10:06:57] <siretart> jai: let's say, I'd be happy to review and consider nomination for changes targeted at 0.5 :-)
[10:06:58] <Dark_Shikari> if not harder than wmapro
[10:07:09] <siretart> Dark_Shikari: agreed
[10:07:11] <Dark_Shikari> so, siretart, it's been nearly a year
[10:07:14] <Dark_Shikari> why are we focusing on 0.5?
[10:07:18] <Dark_Shikari> isn't it better to get 0.6 out?
[10:07:26] <Dark_Shikari> why do we need to backport to stone age releases?
[10:07:36] <twnqx> actually, do you use "3 month" or "3 months" in english?
[10:07:45] <Dark_Shikari> twnqx: depends on context
[10:07:50] <jai> siretart: excellent, and how would you like this to work? should we just reply to a specific commit on cvslog indicating this
[10:07:51] <twnqx> oh
[10:07:56] <siretart> Dark_Shikari: a) it's not stone-age, it is not even 12 months old. b) I'm not going to go for 0.6 for the next debian&ubuntu release
[10:08:06] <jai> siretart: or separate thread on devel
[10:08:12] <Dark_Shikari> siretart: do you have firefox 3.5 in the latest ubuntu?
[10:08:24] <Dark_Shikari> If so, why?  It's much newer than ffmpeg 0.5.
[10:08:26] <siretart> jai: I think a new thread on devel prefixed with [PATCH][0.5] would work best for me
[10:08:38] <twnqx> siretart: an x264 is stoneold not by age, but by features. anything before mb-tree should be considered stone-age.
[10:08:42] <jai> siretart: cool
[10:08:55] <jai> twnqx: +1
[10:08:58] <Dark_Shikari> why is there such an inconsistent application of rules?
[10:09:03] <bilboed-pi> siretart, the problem is that we (gst/gst-ffmpeg developers) can't offer any support if you build gst-ffmpeg with a different checkout than the one we specify
[10:09:04] <Dark_Shikari> things like firefox get updated instantly
[10:09:08] <bilboed-pi> siretart, for obvious reasons
[10:09:17] <Dark_Shikari> and yet ffmpeg stays a year old
[10:09:39] <siretart> Dark_Shikari: please don't compare the firefox package to the ffmpeg package
[10:09:51] <siretart> Dark_Shikari: AFAIUI canonical pays full time developers to care for the package
[10:09:57] <jai> thats tied to fanboi count
[10:10:06] <jai> and aggressiveness
[10:10:10] <siretart> Dark_Shikari: we could reconsider such decisions if we had more manpower
[10:10:17] <Dark_Shikari> and yet firefox is still buggy and slow
[10:10:26] <siretart> but currently I think we need to stay realistic
[10:10:33] <Dark_Shikari> stay realistic: treat all the packages the same way
[10:10:36] <twnqx> more so than any ffmpeg/x264 i've encountered so far, living on the edge :P
[10:10:43] <siretart> Dark_Shikari: that's not realistic in my book
[10:11:00] <Dark_Shikari> what isn't realistic about it?
[10:11:11] <twnqx> Dark_Shikari: in siretard's defense, apps are not always upgraded to svn head
[10:11:16] <Dark_Shikari> twnqx: yes, I said 0.6
[10:11:17] <Dark_Shikari> not svn head
[10:11:22] <siretart> bilboed-pi: I fully understand that. But I just ask you to also understand the distro perspective. you see, I'm actively trying to work out a solution that works for everyone
[10:11:28] <Dark_Shikari> i.e. "Focus on latest release, not on backporting to old releases"
[10:11:48] <siretart> bilboed-pi: and I consider gst-ffmpeg one of the most important downstreams of ffmpeg
[10:11:55] * bilboed-pi waits for flames
[10:12:03] * twnqx considers aegisub more important
[10:12:12] * jai considers ffdshow more important
[10:12:13] <superdump> never heard of aegisub
[10:12:14] * jai hides
[10:12:19] <bilboed-pi> jai, :)
[10:12:43] <Dark_Shikari> siretart: another issue that I notice is that you do releases based on time, rather than based on features
[10:12:48] * twnqx doesn't have gstreamer installed 
[10:12:52] <Dark_Shikari> for example, VLC 1.0.5 was released primarily because of the ffmpeg h264 decoding improvements
[10:12:54] <twnqx> what does one use it for?
[10:12:58] <Dark_Shikari> This was useful enough for most users that they made an entire release for it
[10:13:13] <jai> twnqx: to build pipelines
[10:13:19] <siretart> Dark_Shikari: different projects have different release models and therefore different release cycles. there is no 'one size fits all' model nor approach
[10:13:25] <Dark_Shikari> of course there isn't
[10:13:28] <Dark_Shikari> but there's certainly _wrong_ models
[10:13:31] <Dark_Shikari> and _wrong_ approaches
[10:13:45] <Dark_Shikari> updates should be pushed when there is a benefit users will gain from them
[10:13:51] <Dark_Shikari> not when a clock ticks the right number of times
[10:13:52] <siretart> depends on the project, but in general, I tend to agree
[10:13:55] <CIA-17> ffmpeg: conrad * r21688 /trunk/libavformat/ (oggdec.c oggdec.h):
[10:13:55] <CIA-17> ffmpeg: Fix playback with invalid files that don't set the continuation flag for
[10:13:55] <CIA-17> ffmpeg: pages that continue packets started in prior pages.
[10:13:55] <CIA-17> ffmpeg: Fixes issue1248
[10:14:20] <siretart> Dark_Shikari: I think we agree on the very next steps, I'd like to start working on them. ok?
[10:14:35] <Dark_Shikari> next steps: release 0.6, update to 0.6
[10:14:45] <siretart> yes, among other things
[10:15:05] <superdump> as siretart has said, 0.6 won't go into the lucid release - right?
[10:15:25] <siretart> superdump: I don't have the ressources to push that, so yes
[10:15:50] <siretart> superdump: I plan on working an automatically updated -snapshot package for lucid though
[10:15:52] <superdump> which means lucid will be using an ffmpeg that is over a year old
[10:16:05] <Dark_Shikari> yup, just like debian all over again
[10:16:08] <Dark_Shikari> and like mplayer rc2 (lol)
[10:16:13] <Dark_Shikari> This is why I disagreed with the 0.5 release
[10:16:17] <siretart> Dark_Shikari: debian ships mplayer rc3 ;-)
[10:16:22] <Dark_Shikari> it gives distros an excuse to use outdated, broken software
[10:16:36] <Dark_Shikari> if 0.5 didn't exist, a newer ffmpeg would be used by ubuntu.
[10:16:44] <twnqx> lol
[10:16:55] <siretart> Dark_Shikari: I understand that you are asking distros to not ship ffmpeg, x264 and mplayer at all. Thanks for your support
[10:17:08] <jai> lol
[10:17:08] <Dark_Shikari> siretart: but they've been doing quite a good job for a while
[10:17:11] <Dark_Shikari> at least, good distros have
[10:17:13] <twnqx> why are you so fixed on RELEASES?
[10:17:20] <Dark_Shikari> x264 doesn't have releases, yet you ship it
[10:17:22] <twnqx> just ship a working svn checkout, done
[10:17:28] <Dark_Shikari> mplayer doesn't have releases
[10:17:30] <Dark_Shikari> yet it gets shipped
[10:17:34] <Dark_Shikari> ffmpeg didn't have releases for years
[10:17:36] <Dark_Shikari> yet it got shipped
[10:17:39] <Dark_Shikari> And then ffmpeg came out with a release
[10:17:42] <Dark_Shikari> AND YOU STOPPED SHIPPING
[10:17:47] <Dark_Shikari> notice a pattern?
[10:18:02] <jai> it called a "sync point" iirc
[10:18:05] <siretart> Dark_Shikari: but still you complain that distro release come with horribly outdated packages
[10:18:15] <twnqx> uh
[10:18:27] <siretart> Dark_Shikari: I'm working on limiting the number of versions of horribly outdated packages
[10:18:32] <twnqx> he is just saying that the horribly old version is BECAUSE OF the 0.5 release
[10:18:43] <twnqx> and wouldn't happen if there was no release
[10:18:46] <Dark_Shikari> yes, before 0.5, ubuntu did not ship 0.49
[10:18:52] <Dark_Shikari> because 0.49 was Horribly Outdated
[10:19:00] <siretart> has anyone looked at other distros? e.g. what version of ffmpeg is shipped by say, openbsd or opencsw (solaris)?
[10:19:01] <superdump> 0.4.9* methinks
[10:19:06] <Dark_Shikari> siretart: gentoo has a pretty sane system
[10:19:20] <twnqx> gentoo uses svn 20373 as stable
[10:19:32] <thresh> gentooo doesnt care about packages being rebuildable in a whole distro
[10:19:39] <twnqx> they doo
[10:19:39] <siretart> Dark_Shikari: I discussed the situation with luca yesterday
[10:19:41] <twnqx> do*
[10:19:44] <twnqx> at least within stable.
[10:19:44] <Dark_Shikari> it's actually rather sad that gentoo has the most reliable media backend package-wise
[10:19:47] <siretart> anyway, I need to get back to work now
[10:20:04] <siretart> if there is something pressing, please query or ping me, or better, mail it to ffmpeg-devel@
[10:20:12] <Dark_Shikari> then again, this kind of thing is what fuels the anti-binary-distros flames
[10:20:23] <Dark_Shikari> ancient packages, release obsession
[10:20:37] <DonDiego> siretart: what about the wiki page?
[10:21:06] <twnqx> having a version you can compile your apps against has some valid point, that's why the never ffmpeg versions are hardmasked on gentoo
[10:21:12] <twnqx> newer*
[10:21:39] <siretart> DonDiego: yes, I'll work on that. either tonight or tomorrow
[10:22:46] <jai> siretart: to avoid any duplication, do you already have a patchset which proposed?
[10:22:50] <jai> for the next version that is
[10:23:04] <superdump> Dark_Shikari: well, i use a number of ppas to get more current packages of things i want
[10:23:14] <jai> because i'd like the theora and vorbis related fixes go in
[10:23:15] <superdump> but, maybe average joe wouldn't do that
[10:23:22] <superdump> or wouldn't know to do that
[10:23:30] <siretart> jai: it is published on git.debian.org, look for the ffmpeg branch, in the debian/patches/security subdirectory
[10:23:45] <siretart> jai: almost all patches there are approved, with 2 exceptions that are not marked
[10:23:50] <jai> siretart: right, k
[10:23:55] <superdump> so while snapshots would be a nice supplement, using year old ffmpeg is too old really
[10:24:11] <jai> siretart: maybe this can be maintained on something closer to home later
[10:24:22] <jai> on mphq for example
[10:24:35] <siretart> jai: probably
[10:25:15] <twnqx> superdump: there are "compile yourself" docs for debian all over the web, there must be thousands of users being forced to do that anyway
[10:25:23] <siretart> superdump: the main use I envision for distro packages is to have something application can be linked against. ideally, users will install -snapshot packages over them and have additional functionality for existing applciation instantly
[10:25:58] <Dark_Shikari> siretart: in that case wouldn't it be sensible to have two versions of ffmpeg?
[10:26:04] <Dark_Shikari> or better said
[10:26:11] <Dark_Shikari> one version of ffmpeg, one, stable version of libav*
[10:26:26] <Dark_Shikari> of course this gets tricky for applications like gst that just wrap ffmpeg
[10:27:02] <bilboed-pi> Dark_Shikari, having the various libav* separated would be nice tbh
[10:27:17] <siretart> Dark_Shikari: yes, I intend to have 2 packages: one called 'ffmpeg' the other one 'ffmpeg-snaphsot'. the latter is not for distro releases at all but only for add-on repos to replace the distro ones
[10:27:19] <bilboed-pi> (side effect would be spotting the numerous cross-depencies)
[10:27:30] <siretart> anyway, lunchtime.now
[10:48:59] <jez9999> does ffmpeg redefine things like 'struct sockaddr_storage' from its original POSIX definition?
[10:54:28] <pross-au> jez9999: NO
[10:55:56] <jez9999> then what's struct sockaddr_storage doing in network.h?
[11:27:57] <jai> i havent looked, but i'm sure its #ifdef'd out for systems which have it
[11:30:34] <jez9999> in the form of #if !HAVE_STRUCT_SOCKADDR_STORAGE
[11:30:46] <DonDiego> yes, so?
[11:30:50] <jez9999> HAVE_STRUCT_SOCKADDR_STORAGE is something that i can't find anywhere, seems to be ffmpeg-specific or something
[11:30:58] <DonDiego> configure sets it
[11:31:13] <jez9999> point is, i'm getting a build error about redefinition of 'struct sockaddr_storage'
[11:31:38] <DonDiego> in network.h?
[11:31:41] <jez9999> yep
[11:32:48] <DonDiego> wait
[11:32:55] <jez9999> if i remove the include for network.h it says it hasn't been defined.  heh.
[11:32:57] <DonDiego> what business do you have with network.h?
[11:33:08] <DonDiego> that's an internal ffmpeg header
[11:33:12] <jez9999> passing a network address into the libavformat api.
[11:33:30] <DonDiego> that header should not be necessary
[11:33:40] <jez9999> how else do i store a sock addr?
[11:33:56] <DonDiego> sockaddr_storage is a standard POSIX thing
[11:34:07] <jez9999> yeah, but i thought the point about network.h was that ...
[11:34:09] <jez9999> hmm
[11:34:24] <jez9999> so you're not defining it for the purpose of making it non-POSIX.
[11:34:27] <jez9999> that's a problem
[11:34:47] <jez9999> i kinda need it to be non-POSIX if it's gonna be added to the libavformat API
[11:35:16] <DonDiego> i just see that it's not posix
[11:35:42] <DonDiego> netinet/in.h on my system
[11:35:56] <DonDiego> use that header
[11:36:20] <jez9999> sure, but that *is* posix
[11:36:53] <DonDiego> no, socket.h actually
[11:37:39] <jez9999> that's system-specific
[11:37:44] <DonDiego> that's the header you need
[11:38:23] <jez9999> you can pass system-specific stuff into the ffmpeg API?
[11:38:50] <DonDiego> you still have not told us what you are doing
[11:39:03] <DonDiego> (except for messing with libavformat internals, which you should not)
[11:39:18] <jez9999> why not?  i need to add fundamentally new functionality. :-)
[11:39:22] <pross-au> jez9999: we discussed this last week mate
[11:39:26] <jez9999> yep
[11:39:37] <jez9999> i'm allowing a network address to be passed into ffmpeg as a member of AVFormatContext
[11:39:58] <DonDiego> well, ok, then you guys who know the context take it from here
[11:41:35] <jez9999> this is a mess.  ffmpeg does use sockaddr_storage internally, but not in the API
[11:41:47] <jez9999> and because it's a POSIX thing, it includes its own definition for it just in case
[11:41:56] <jez9999> the system doesn't have POSIX support
[11:42:09] <jez9999> however i need to turn it into a public struct... and use it in the public API
[11:42:15] <mru> you can't do that
[11:42:24] <mru> I've told you why before
[11:43:03] <jez9999> because it's a posix struct?
[11:43:28] <mru> the api must be plain C
[11:43:31] <mru> no extensions
[11:43:44] <jez9999> which is why im wanting to use the version defined in ffmpeg itself
[11:43:57] <pross-au> jez9999: use void*, as we discussed last week
[11:43:59] <mru> that doesn't work
[11:45:05] <pross-au> { void *address_list; int nb_addresses; int sizeof_sockaddr; }
[11:47:07] <jez9999> and then both the calling code and ffmpeg use the POSIX sockaddr_storage?
[11:48:05] <mru> you'd better pray they do
[11:48:34] <jez9999> yeah...... you can't guarantee that the calling code will pass in the right structure
[11:48:45] <jez9999> that's an acceptable risk in the public api?
[11:51:57] <jez9999> in fact, how do you even specify what structure should be passed in?
[11:52:03] <jez9999> it's not posix, it's not defined in ffmpeg itself
[11:53:27] <pross-au> i think its acceptable. sa_family is always a char.
[11:53:36] <pross-au> ** for the bulk of platforms **
[11:54:08] <mru> what makes you think there will even be an sa_family on all platforms?
[11:55:09] <pross-au> show me a platform that doesnt have sa_family..
[11:55:30] <mru> there are all sorts of weird tcp/ip implementations
[11:55:42] <pross-au> example
[11:55:55] <pross-au> strawman arguments have no place here
[11:55:58] <jez9999> pross-au: but isn't sa_family defined inside the posix-specific sockaddr?
[11:56:11] <jez9999> which means you've got posix-specific stuff in the api
[11:56:12] <pross-au> jez9999: yes, and its the first byte
[11:56:18] <mru> various embedded stuff
[11:56:50] <jez9999> pross-au: so.... you're saying to rely on posix functionality for this feature, but make sure it will complie no matter what by using a void*
[11:57:01] <jez9999> however on platforms where it wouldnt compile, this functionality would be unusable too
[11:58:01] <pross-au> thats what i said
[11:58:07] <jez9999> (where it wouldn't have compiled if you actually put sockaddr in AVFormatContext)
[11:58:15] <jez9999> ok
[11:58:20] <pross-au> you're already using posix functionailty. char *filename; <-- what the hell is that?? :D
[11:58:37] <jez9999> and just for future reference, was there a way for me to know that network.h was an internal and not an API header?
[11:58:46] <jez9999> or is it something you 'just need to know'? :-)
[11:58:48] <pross-au> the syntax of the filename is operating system dependant.
[11:59:01] <pross-au> so why is sockaddr any different?
[12:00:03] <mru> pross-au: I have never so much as heard of a system where filenames are not null-terminated strings
[12:00:12] <mru> although on windows they are sometimes utf16-encoded
[12:00:18] <mru> we've had some trouble with that
[12:00:39] <pross-au> mru: ive never heard of a tcp/ip implementation that doesnt use sa_family
[12:01:05] <mru> network stuff is much more diverse
[12:01:09] <pross-au> filename or sockaddr, they are just a buffer you pass to the operating system
[12:01:23] <mru> I've certainly seen tcp implementations with incompatible address structs
[12:01:32] <mru> I don't remember if they all had sa_family or not
[12:01:42] <mru> but the exact name is irrelevant
[12:01:55] <mru> sometimes it's a byte, sometimes 16 bits
[12:02:03] <pross-au> mru: fair point
[12:02:46] <pross-au> given that your passing the filename to fopen() or whatever. then the same rules could apply to bind() or recvfrom()
[12:03:26] <pross-au> i.e. Rule: FFmpeg will pass this onto the operating system.
[12:03:54] <pross-au> we're not unpacking sockaddr_storage
[12:04:47] <mru> I was under the impression this address was to be examined by lavf
[12:05:34] <mru> the portable way to represent an IPv4 address is ascii a.b.c.d notation
[12:07:37] <jez9999> needn't be an ipv4
[12:07:38] <jez9999> :-)
[12:07:47] <jez9999> and just for reference guys, was there a way for me to know that network.h was an internal and not an API header?
[12:08:17] <mru> that it's not installed by make install
[12:10:41] <jez9999> any convenient list of what is installed by make install?
[12:10:44] <jez9999> in one place?
[12:10:50] <mru> the makefile
[12:11:47] <DonDiego> mru: how hard would it be to have FATE track the 0.5 branch for a little while?
[12:11:48] <pross-au> Sockaddr <-> ASCII representations should be performed by the sockets library, not FFmpeg.
[12:12:17] <DonDiego> or possibly in addition to trunk?
[12:12:21] <DonDiego> or should i ask mike?
[12:14:44] <jez9999> mru: that was kind of my point, there's a bunch of files constituting the makefile
[12:16:15] <DonDiego> run 'make -n install'
[12:16:57] <DonDiego> ok, i'm out, cu
[12:17:04] <jez9999> bye
[13:03:44] * _av500_ is in ADL2010 with ffmpeg FOSDEM tshirt
[13:06:16] <CIA-17> ffmpeg: michael * r21689 /trunk/libavcodec/h264_direct.c:
[13:06:16] <CIA-17> ffmpeg: Detect equal 4x4 blocks in spatial direct MBs.
[13:06:16] <CIA-17> ffmpeg: 19 cycles slower MV generation
[13:06:16] <CIA-17> ffmpeg: 575 cycles faster MC
[13:13:23] <twnqx> uh, ffmpeg is building a h264 encoder of its own?
[13:13:32] <mru> no
[13:13:34] <kshishkov> no
[13:13:40] <twnqx> mh
[13:14:47] <andoma> no
[13:15:02] <_av500_> no
[13:15:05] <Compn> no
[13:15:22] <elenril> yes!
[13:15:24] * elenril runs
[13:15:24] <kshishkov> you can try to fork x264 and rewrite it for FFmpeg (preferaby LGPL) though
[13:15:50] <Compn>    U.S. Department of Defense              LPC-10 2400 bps Voice Coder                   Release 1.0                   October 1993
[13:16:13] <Compn> lots of speech codecs from the 90s to be implemented :)
[13:16:21] <mru> :-)
[13:17:04] * Compn collects some samples and decoders and puts it on small tasks page
[13:18:11] <twnqx> so for my understanding of the last commit, the decoder has do generate motion vectors?
[13:18:42] <kshishkov> for prediction or something
[13:18:48] <andoma> twnqx: from the coded bitstream yes
[13:19:02] <twnqx> oh
[13:20:01] <Compn>    This packet contains the C source for a mixed-radix FFT routine.
[13:20:06] <Compn>   NOTE : This is copyrighted material, NOT public domain. See below.
[13:20:06] <Compn> bah
[13:20:27] <mru> ?
[13:20:42] <Compn>    Non-commercial use of the source code is free.
[13:21:09] <Compn> strange license
[13:21:20] <Compn> ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/analysis/
[13:22:03] <kshishkov> Compn: when I was young I collected those, DoD LPC-10 is very famous
[13:27:18] <Compn> still have the samples somewhere ? if so, upload them ?
[13:27:22] <Compn> 2.4 kbps MELP Proposed Federal Standard speech coder
[13:27:47] <kshishkov> samples were in reference implementation package
[13:27:57] <kshishkov> male/female voice or something
[14:43:39] <justlooking_> hmm given that 10 Jan 17:42	"Diego Biurrun said:How about making 2010 the year of performance improvements?" Michael Niedermayer replyed "Prerequesite to that would be keeping h264 discussions where the only person
[14:43:40] <justlooking_> who works on our decoder (yeah thats me) sees them Its really sad, how often do i have to repeat that i cannot do all the work
[14:43:40] <justlooking_> alone. Now if people refuse to send cleanly split patches, could they at least
[14:43:40] <justlooking_> _please_ keep their h264 discussions on ffmpeg-dev!" is 3 months fine grained enough, and as 	Michael requested it, when will ffmpeg be updated to take generic $todays=NOW  x264cli command line arguments directly.
[14:43:57] <justlooking_> http://thread.gmane.org/gmane.comp.video.ffmpeg.cvs/26814
[14:45:48] <Compn> justlooking_ : erm, whats your point ?
[14:46:06] <Compn> or your question, i got lost
[14:47:24] <superdump> i don't think michael has ever requested ffmpeg being able to accept x264 cli options
[14:47:41] <superdump> not directly
[14:48:04] <superdump> but maybe justlooking_ meant just having all api options that are relevant being visible
[14:48:14] <superdump> and alterable
[14:50:15] <justlooking_> 	Michael's updating h.264 a lot and has commited to speed improvements and yes it seems all available x264 options should be available to ffmpeg as soon as is possible, however that make be done, perhaps 	Michael can do that?
[14:50:47] <merbzt> perhaps you can do it ?
[14:51:10] * kshishkov wonders if it's blasphemy to prepend MN name with unprintable characters
[14:51:20] <mru> kshishkov: those are tabs
[14:51:44] <elenril> aren't tabs forbidden on irc? ;)
[14:51:55] <mru> only on #ffmpeg-svn
[14:51:59] <merbzt> the better business bureau
[14:52:11] <superdump> lo BBB_
[14:52:15] <BBB_> hello
[14:52:32] <superdump> justlooking_: i wouldn't want michael to spend his time on such relatively trivial tasks
[14:52:39] <justlooking_> its in the log bot  nowm i cant change it.
[14:53:02] <elenril> can anyone with access to git.ffmpeg.org make a git-svn mirror for nut?
[14:53:04] <BBB> there's #ffmpeg-svn?
[14:53:10] <kshishkov> BBB: you better hide, that "RTP filtering" guy is after you
[14:53:13] <BBB> any more #ffmpeg-channels I should know about?
[14:53:19] <BBB> kshishkov, that's ok
[14:53:20] <kshishkov> BBB: it's ML
[14:53:25] <BBB> oh, ok
[14:53:44] * BBB just had his honeymoon vacation
[14:54:11] <superdump> when did you get married?
[14:54:16] * BBB will take care of google money today
[14:54:26] <kshishkov> superdump: it's in his blog
[14:54:32] <BBB> actually it is
[14:54:36] <BBB> august last year
[14:54:40] <kshishkov> BBB: what, all of Google money?
[14:54:41] <BBB> but never had a honeymoon
[14:54:46] <BBB> kshishkov, the 2009 one
[14:54:51] <superdump> well, belated congratulations
[14:54:53] <BBB> the 2008 one is in process, we're 11 months past deadline
[14:55:04] <BBB> so I have to jump through some hoops
[14:55:04] <merbzt> :)
[14:55:11] <BBB> but I think it'll work
[14:55:17] <BBB> leslie is very nice
[14:55:33] <BBB> I guess we're not the only project that is... horrible at planning this kind of stuff
[14:55:43] <BBB> let's get 2010 rolling
[14:55:49] <mru> +t
[14:55:49] <BBB> did everyone advertise it on his blog?
[14:56:20] <mru> BBB: do we have bank accounts now?
[14:56:21] <merbzt> #join #openwrt
[14:56:39] <kshishkov> merbzt: advertised for GSoC
[14:57:18] <merbzt> ok ?
[14:57:31] <BBB> mru: yes
[14:58:01] <mru> BBB: good, let's fill 'em up!
[14:58:17] <merbzt> BBB: both eu and us ?
[14:58:25] <BBB> us only for now
[14:58:36] <BBB> I think reimar might be working on the eu, but that'll take another while
[14:58:39] <BBB> it's in progress
[14:58:48] <kshishkov> BBB: he does
[14:58:58] <kshishkov> BBB: in the best part of Europe actually
[14:59:08] <BBB> if anyone can help quickly setting up a FREE FREE FREE (no monthly charge) account, that'd be very helpful
[14:59:09] <kshishkov> although some Turks may disagree
[14:59:14] <BBB> sve is ok
[14:59:23] <BBB> (reimar is sve, right?)
[14:59:27] <kshishkov> yes
[14:59:28] <mru> yes
[15:00:10] <kshishkov> well, I have some free accounts but good luck _putting_ money to them or withdrawing later
[15:00:57] <BBB> being able to take money off of it would be a nice bonus
[15:01:32] <kshishkov> yep
[15:01:44] <kshishkov> it's hard to withgraw money here
[15:01:52] <kshishkov> only Hrivnias
[15:02:41] * BBB goes catch up with some work
[15:05:47] <superdump> whereabouts in sweden is reimar?
[15:06:03] <kshishkov> Lund
[15:09:53] <pJok> must kill reimar....
[15:10:06] <pJok> (its about 20 minutes south of where i live)
[15:10:38] <mru> whatever did reimar do to you?
[15:10:45] <pJok> nothing :)
[15:11:05] <pJok> i just had to say it, since he's so close
[15:11:16] <pJok> i better be going back to doing actual work again
[15:12:35] <mru> yes, or else reimar might come for you
[15:25:15] <_av500_> mru: back?
[15:25:20] <mru> airport
[15:25:22] <_av500_> ah
[15:25:25] <_av500_> with the cat?
[15:25:39] <mru> no
[15:26:04] <mru> the cat is on a later flight
[15:26:24] <jez9999> hum
[15:27:00] <jez9999> pross-au recommended I pass { void *address_list; int nb_addresses; int sizeof_sockaddr; } into the libavformat API
[15:27:08] <jez9999> to pass a list of sockaddr's in
[15:27:21] <jez9999> i'm using the first 2, but why would he suggest I pass in sizeof_sockaddr?
[15:27:23] <mru> I still don't see why you want/need to do that
[15:27:32] <jez9999> well assuming there were a valid reason
[15:27:32] <jez9999> :-)
[15:27:38] <mru> pass addresses, that is
[15:27:54] <mru> if you must pass addresses, you obviously must also pass the size
[15:28:17] <jez9999> why?  the idea is to rely on the system defining things like sockaddr_storage for us
[15:28:34] <jez9999> so the calling code and ffmpeg both just assume address_list is an array of sockaddr_storage
[15:28:51] <mru> many systems don't provide such a thing
[15:29:01] <jez9999> yep, and this mechanism isnt going to work on such systems
[15:29:08] <jez9999> (actually i bet most are posix-compliant)
[15:29:08] <mru> many systems provide no networking at all as part of the system itself
[15:29:16] <jez9999> so be it.
[15:29:27] <jez9999> what about on poxis-compliant systems?
[15:29:29] <mru> so if you want networking you need bring your own lib
[15:29:58] <jez9999> yeah but im having to assume posix compliance here
[15:29:59] <mru> ffmpeg's networking code could be easily extended to run on top of any reasonable tcp stack
[15:30:10] <jez9999> easily?
[15:30:47] <mru> assuming it has the usual set of socket/connect/send/recv functions
[15:31:04] <jez9999> they're posix.
[15:31:29] <mru> if you're doing tcp they are the natural way to do it
[15:31:43] <mru> the exact format of an address varies, however
[15:31:57] <mru> that's why there are functions for translating ascii strings into addresses
[15:32:15] <mru> ideally the app using lavf shouldn't need to care what networking lib is used
[15:32:35] <jez9999> sigh
[15:32:41] <jez9999> why did that guy recommend a void* list then
[15:35:04] <_av500_> mru: gee, bb ml wants to know about the vw
[15:35:31] <jez9999> if the code is to be compliant with non-POSIX systems, doesnt that mean more complex code in ffmpeg?
[15:35:45] <jez9999> like preprocessor defs to check what kind of system it is and perform different behaviour?
[15:35:46] <mru> _av500_: most of it is in OE
[15:35:53] <_av500_> yes
[15:36:08] <_av500_> ill write up a page with a few pics etc and put links to the relevant stuff
[15:36:20] <mru> jez9999: we support only posix systems _now_
[15:36:34] <_av500_> perfect op to make my 1st blog post
[15:36:41] <mru> if/when someone wants to use ffmpeg on some obscure tcp stack, there should be nothing stopping that
[15:36:48] <_av500_> (if I remember the pwd..)
[15:36:55] <jez9999> mru: what?  i'm confused.
[15:37:10] <jez9999> i thought the whole point was that you supported non-posix systems
[15:37:16] <jez9999> thats why you cant put posix stuff in the api
[15:37:29] <mru> exactly
[15:37:40] <jez9999> so why did you say you support only posix systems
[15:37:45] <mru> and if it's not posix, how is the calling app supposed to figure out the format of an address
[15:37:55] <mru> jez9999: the code inside lavf only works with posix for now
[15:38:06] <mru> because nobody has had the need to run it elsewhere
[15:38:39] <jez9999> so... it's ok to add more code that only works with posix
[15:38:52] <mru> not what you're thinking of
[15:39:09] <mru> that exposes non-portable data structures through the api
[15:39:27] <mru> void * or not, the contents are system-specific
[15:39:36] <jez9999> i dont get why posix defines that you have to have some data structure, but then leaves it to you to determine the format
[15:39:37] <jez9999> :-)
[15:39:46] <jez9999> why didnt they just say "represent it this way, damnit"
[15:40:42] <mru> the tcp spec only defines the wire protocol
[15:40:54] <mru> not the memory representation
[15:41:03] <jez9999> posix isnt the tcp spec
[15:41:22] <mru> I know that
[15:41:38] <mru> the posix socket api is transport-independent
[15:42:28] <jez9999> so it tells you to define sockaddr 'in some way'
[15:42:46] <mru> gtg go catch my flight
[15:42:47] <mru> back later
[15:43:19] <BBB> jez9999, if that were the case, ipv6 would never have happened
[15:43:36] <jez9999> so it tells you how to define sockaddr
[15:43:58] <BBB> not to mention the possibility of having something else as tcp/ip, e.g. novell's thingy(?) or microsoft's netbeui(?)
[15:44:22] <BBB> I'm not saying those are good ideas, I'm just saying that the api allows all of that in a single one
[15:46:09] <jez9999> BBB: if what were the case?
[15:46:20] <jez9999> you mean a fixed representation
[15:46:23] <BBB> yes
[15:46:39] <BBB> look, the callback is not going to be part of the ffmpeg api
[15:46:43] <BBB> I told you that, michael did
[15:46:46] <BBB> luca also, I think
[15:46:51] <BBB> stop thinking of that
[15:46:53] <BBB> it's bad api
[15:46:55] <BBB> it won
[15:46:57] <BBB> t happen
[15:47:07] <jez9999> this isn't a callback, this is passing addresses in
[15:47:18] <BBB> won't happen either
[15:47:22] <BBB> it doesn't address the issue
[15:47:29] <jez9999> pun intended
[15:47:34] <BBB> :)
[15:47:42] <_av500_> :)
[15:47:44] <BBB> I want something that does not require the application to do something
[15:47:57] <BBB> I want rtsp.c and rtpdec.c to handle it internally
[15:48:02] <BBB> I explained in the bug report how to do that
[15:48:07] <BBB> it's a little bit more difficult to code
[15:48:12] <jez9999> we've discussed this.  sdp does not provide a surefire mechanism for specifying the ssrc
[15:48:16] <BBB> but it address the issue much more beautifully
[15:48:29] <BBB> I want ssrc collission detection
[15:48:35] <jez9999> and what then?
[15:48:39] <jez9999> so you've detected a collision
[15:48:41] <BBB> then rtsp can - for my part - export it as two streams
[15:48:42] <jez9999> how does it resolve it
[15:48:50] <jez9999> 2 streams.......
[15:49:04] <jez9999> you've opened 1 stream
[15:49:11] <BBB> the source - according to the spec - is responsible for new ssrc setup once a collission within a session has been detected
[15:49:17] <jez9999> via av_open_input_file
[15:49:20] <BBB> you open one session (av_open_*())
[15:49:33] <BBB> a file/session can have multiple streams (ctx->streams, AVStream)
[15:49:56] <BBB> just like an avi can have one video and one audio stream
[15:50:01] <BBB> or an english and a french soundtrack
[15:50:08] <BBB> or subtitles in different languages
[15:50:15] <BBB> or a dvd can have lpcm + mp2 music
[15:50:46] <jez9999> it would have to be added dynamically
[15:50:50] <BBB> but whatever representation, I want rtsp to do the collision handling and detection
[15:50:55] <BBB> yes, dynamic stream adding is supported
[15:51:00] <BBB> in fact, rtsp already uses it
[15:51:02] <BBB> (see rdt.c)
[15:51:22] <jez9999> btw you shouldnt refer to it as rtsp
[15:51:22] <jez9999> :-)
[15:51:45] <BBB> well, you know what I mean
[15:51:51] <BBB> rdt is at a same level as rtp
[15:51:56] <BBB> called by rtsp/sdp
[15:51:59] <BBB> so you'll get the idea
[15:53:10] <jez9999> so the calling code gets 2 streams
[15:53:17] <jez9999> how does it know which to discard?
[15:53:53] <BBB> one solution might be to provide two streams
[15:54:05] <BBB> the other is to add logic to rtp so it simply rejects one
[15:54:13] <BBB> either way collission detection is the first step
[15:55:55] <jez9999> im presuming that the solution is that ffmpeg provide 2 streams
[15:56:00] <jez9999> how does the calling code know which to discard?
[15:56:45] <BBB> it depends what the streams are
[15:57:14] <jez9999> ?
[15:59:07] <jez9999> howso?
[15:59:21] <BBB> you're telling me the streams are from different cameras right?
[15:59:39] <BBB> so then they're different content, i.e. one must be rejected
[15:59:49] <jez9999> yep
[16:00:02] <BBB> if they were the same camera or different angles, i.e. it's intended and they represent same content, then you'd want 2 streams
[16:00:28] <BBB> so for this particular case, once the ssrc collision is handled, you want to reject one
[16:00:36] <BBB> the logic for which one to reject can be discussed
[16:01:58] <jez9999> very short discussion
[16:02:03] <jez9999> base it on source IP
[16:02:28] <BBB> the simplest would be to open the file as file.sdp?source_ip=ip.ip.ip.ip
[16:02:29] <BBB> or host
[16:03:02] <BBB> then you don't need all that creepy stuff that you just said about void * address, int num_addresses; struct size; I_get_scared_by_this;
[16:03:43] <BBB> but that can only be done if the ssrc collision has been handled
[16:03:57] <BBB> before that, the source data from ips can be intended, as luca abeni explained in the issue tracker entry
[16:04:29] <jez9999> "the source data from ips can be intended"?
[16:04:31] <lu_zero> hi
[16:04:35] <jez9999> hello
[16:05:19] <lu_zero> how's going?
[16:05:25] * lu_zero now is in Geneve
[16:05:35] <jez9999> snowing here
[16:05:36] <jez9999> :-)
[16:06:33] <BBB> the fact that data is coming in from several (different) source ips can be intended
[16:06:43] <BBB> we want to continue handling that correctly
[16:07:25] <jez9999> if a source ip is specified in the url, then why do you need to worry about collision detection?
[16:07:36] <jez9999> you're asking to limit it to the specified IP(s) anyway
[16:09:52] <jez9999> in fact it would be misleading to decode and return a stream of data from a different address
[16:10:33] <BBB> at the very least you're not asking me to put a source ip in AVPacket anymore
[16:10:34] <BBB> :)
[16:10:34] <lu_zero> still I'm missing if the rtpdec does filter by ssrc or not
[16:10:45] * BBB notices progress
[16:10:50] <jez9999> :-)
[16:10:54] <lu_zero> the problem is better defined now
[16:11:03] <jez9999> i don't believe it does at the moment, lu_zero
[16:11:21] <jez9999> it has nothing to go on... no ssrc is provided to it
[16:12:01] <lu_zero> ok, that should implemented nonetheless
[16:12:12] <jez9999> that's a different feature though
[16:12:40] <BBB> for rtsp, it's needed, since the ssrc is known
[16:12:45] <BBB> sdp is kinda of more problematic
[16:12:48] <jez9999> i dont do rtsp
[16:12:51] <BBB> I know
[16:12:51] <jez9999> :-)
[16:13:01] <BBB> I'm just supporting lu_zero's case that we should implement it
[16:14:16] <jez9999> well that's a separate discussion as it's a separate feature
[16:14:35] <jez9999> so what about with regards to specifying source address?
[16:15:02] <jez9999> you're talking about limiting it to an IP address.  one of the nice things about using sockaddr_storage was that it (theoretically) supports any network address
[16:15:47] <BBB> udp also goes over ip addresses
[16:15:51] <BBB> so does tcp
[16:15:56] <jez9999> it can do
[16:15:56] <BBB> so I don't see where you're going
[16:16:02] <lu_zero> hmm
[16:17:04] <jez9999> unix domain sockets?
[16:17:08] <BBB> to specify the ssrc (or source ip) if you're opening a sdp is ok with me
[16:17:15] <BBB> unix domain sockets don't do udp
[16:17:18] <BBB> they also don't do tcp
[16:17:19] <lu_zero> jez9999: that's a feature I want to implement
[16:17:36] <lu_zero> BBB: but is _quite_ nice to have unix sockets supported
[16:17:54] <lu_zero> (loopback drops udp)
[16:18:35] <BBB> you really want that?
[16:18:39] <BBB> hmk then
[16:19:25] <BBB> anyway, any argument in public api using that is not ok
[16:19:30] <BBB> I want it as part of the uri, if anything
[16:19:39] <BBB> since for rtsp, it's implicity in the uri / data stream
[16:19:51] <BBB> it's logical that for sdp, you'd include it as part of the uri (optionally)
[16:20:17] <BBB> filename.sdp?ssrc=X or filename.sdp?srcip=X.Y.Z.z
[16:20:32] <jez9999> BBB: http://pastebin.com/m1e941c78
[16:20:45] <jez9999> 2 of 37 are IP ;-)
[16:20:58] <BBB> yes
[16:20:59] <lu_zero> ^^;
[16:21:07] <BBB> which of those support rtp?
[16:21:27] <jez9999> any which is connectionless, theoretically
[16:21:38] <jez9999> erm
[16:21:39] <lu_zero> rtp is over dccp, sctp, udp, tcp, rtsp, http,
[16:21:42] <jez9999> what am i talking about, they all arer
[16:21:56] <lu_zero> at least I know implementations of that
[16:22:05] <BBB> tcp is ip, i.e. inet or inet6
[16:22:08] <BBB> http is also
[16:22:36] <jez9999> theoretically you could put RTP over any of those socket types i'd guess
[16:22:57] <lu_zero> yup
[16:23:43] <BBB> why don't we do it this way: you go discuss with michael an api that allows all of those be supported as part of your api proposal
[16:24:00] <CIA-17> ffmpeg: michael * r21690 /trunk/libavcodec/h264_direct.c:
[16:24:00] <CIA-17> ffmpeg: Detect spatial direct MBs partitioned smaller than 16x16 that can be partitioned
[16:24:00] <CIA-17> ffmpeg: as 16x16 (except ones changing interlacing relative to the colocated MB).
[16:24:00] <CIA-17> ffmpeg: 20 cycles slower during MV generation
[16:24:00] <CIA-17> ffmpeg: 175 cycles faster during MC
[16:24:07] <BBB> once you're done with him rejecting you, we'll talk again about the simple filename.sdp?source=string api that I suggest
[16:24:31] <BBB> we can word it such that in theory string can be a nonip thing
[16:24:40] <BBB> that way everyone is happy
[16:26:00] <jez9999> source=ipv4:1.2.3.4
[16:26:01] <jez9999> ?
[16:27:29] <BBB> anything that getaddrinfo() supports is fine with me
[16:28:47] <BBB> (don't forget that rtp/rtsp/sdp use getaddrinfo() practically everywhere to figure out this kind of stuff)
[16:30:31] <jez9999> ?sourceaddr=x
[16:30:34] <lu_zero> brb
[16:30:42] <jez9999> where x is a string dropped straight into getaddrinfo()
[16:33:54] <BBB> source, sourceaddr, sourceip
[16:33:57] <BBB> you get what I mean
[16:34:05] <BBB> I don't mind much what you prefer to call it
[16:34:24] <BBB> as long as it's documented what it is
[16:41:49] <jez999> BBB: what about specifying multiple source addresses?
[16:55:13] <kierank> [14:52] <@merbzt> the better business bureau --> I always thought it was big buck bunny
[17:00:16] <Compn> where is the wishlist again ?
[17:00:23] <Compn> it was on the wiki... is it now in roundup ? or svn ?
[17:05:59] <elenril> J_Darnley: btw does your patch add support for writing ogg metadata too
[17:06:03] <elenril> or just raw flac?
[17:24:11] * BBB curses as google sends him openoffice template files
[17:24:23] <BBB> the one thing that is worse than receiving MS Office files, is receiving OpenOffice files
[17:24:24] <kshishkov> wanna get .docx instead?
[17:24:29] <BBB> YES
[17:24:35] <BBB> I happen to have MS Office installed
[17:24:44] <kshishkov> the latest?
[17:24:51] <BBB> I'm not gonna download a 2TB software package that is slow, crippled and bloated
[17:24:59] <BBB> 2007, I think
[17:25:03] <BBB> should be relatively new
[17:25:08] <BBB> free from uni :)
[17:25:09] <kshishkov> and you happen to have MS Office installed?
[17:26:31] <kshishkov> have you tried AbiWord instead?
[17:26:50] <CIA-17> ffmpeg: michael * r21691 /trunk/libavcodec/h264_direct.c:
[17:26:50] <CIA-17> ffmpeg: Set partitioning to 16x16 for spatial direct MBs with mixed interlacing.
[17:26:50] <CIA-17> ffmpeg: 11cylcles slower MV generation
[17:26:50] <CIA-17> ffmpeg: 98cycles faster MC
[17:27:00] <BBB> I could install kword
[17:27:04] <BBB> or nword
[17:27:05] <BBB> or bword
[17:27:07] <BBB> or lword
[17:27:11] <BBB> or curseword
[17:27:15] <BBB> but I want a frigging pdf
[17:27:15] <kshishkov> [a-z]word
[17:27:35] <ohsix> abiword :>
[17:27:36] <BBB> can anyone here convert the ods to pdf (or doc) for me?
[17:27:53] <kshishkov> yes, never trust a format that connot be read by <2 opensource implementations
[17:28:23] <kierank> [17:27] <@BBB> can anyone here convert the ods to pdf (or doc) for me? --> yes
[17:28:37] <BBB> great! where do I email it?
[17:29:23] <kshishkov> BBB: can't you open it with GoogleDocs online?
[17:30:07] <J_Darnley> elenril: at present, just raw flac.  but see an older email of mine which has another patch which adds tags for ogg-flac and ogg-speex
[17:30:10] <BBB> gmail has no "view" button for this
[17:36:29] <BBB> googledocs worked
[17:36:31] <BBB> yay
[17:43:36] <elenril> J_Darnley: cool
[17:43:45] * elenril summons jruggles from depths of hell
[17:45:33] <kshishkov> North Carolina is not "depths of hell" I think
[17:45:37] <kshishkov> try different location
[17:45:45] <elenril> depends on who you ask
[17:46:45] <Compn> BBB : i agree, i'd love to see a 2mb doc/odf viewer
[17:46:50] <Compn> or smaller :)
[17:47:12] * Compn looks at all his word for windows 2.0 documents and then looks at openoffice.org cant open them
[17:47:39] <Compn> course, i dont think new office can open them either, but its been a hwile since i tried
[17:47:58] <kshishkov> elenril: ask me then
[17:48:49] <elenril> heh
[17:48:53] <elenril> that's cheating
[17:49:21] <_av500_> kshishkov: btw, did you vote for the right guy?
[17:49:24] <elenril> btw election over yet?
[17:49:30] <_av500_> elenril: I think so
[17:49:35] <kshishkov> it is
[17:49:41] <_av500_> now they haggle over how much it was tweaked
[17:50:04] <elenril> what a surprise
[17:50:11] <kshishkov> _av500_: between two evils 'tis not worth to choose
[17:50:48] <kshishkov> so I didn't
[17:52:43] * elenril wonders why would anybody want to be a president of ua
[17:52:52] <elenril> there's still things to steal?
[17:53:05] <kshishkov> yes
[17:53:10] <kshishkov> land
[18:03:48] * pJok has a suggestion for ffmpeg...
[18:04:00] <pJok> adopt a codec
[18:05:06] <_av500_> theora!
[18:05:09] * _av500_ hides
[18:05:11] * _av500_ hides deeper
[18:06:13] * mru digs
[18:06:27] <elenril> we already have snow
[18:06:29] <BBB> you're dead meat dude
[18:06:57] <_av500_> I survived 2 days next to mru, should do fine
[18:07:02] <_av500_> (days, not nights!)
[18:07:23] <kshishkov> _av500_: I survived with him around almost up to midnight
[18:08:04] <_av500_> and at midnight he ran away, leaving a shoe?
[18:08:41] <kshishkov> nah, it was me lurching away actually
[18:29:41] <kierank> What could the "29DF" mean in this timecode: http://dl.dropbox.com/u/2701213/Dolby%20E/timecode.png
[18:30:35] <kshishkov> the same in hex?
[18:31:22] <kshishkov> you know, like in AC3
[18:31:54] <kierank> didn't know ac3 had builtin timecodes
[18:32:25] <kshishkov> there is - two 14-bit timecodes for date and time
[18:32:34] <kshishkov> summon jruggles for details ;)
[18:33:09] <kierank> there's supposedly full 80-bit timecodes in dolby e but they seem to have mungified it somehow
[18:34:19] <kshishkov> IIRC, in AC3 there are special bits to tell what parts of timecode are present
[18:42:05] <kierank> ah the DF means "drop frame"
[18:49:02] <CIA-17> ffmpeg: rbultje * r21692 /trunk/libavformat/ (os_support.c network.h):
[18:49:02] <CIA-17> ffmpeg: Implement gai_strerror() for systems lacking such functionality. Patch
[18:49:02] <CIA-17> ffmpeg: by KO Myung-Hung <komh challion net>.
[18:49:51] <BBB> oops, misspelled name - fixed
[18:50:45] <kshishkov> bad knowledge of Korean?
[18:54:40] <Dark_Shikari> just yell "zerg rush" really loudly while covering your eyes
[18:54:43] <Dark_Shikari> you'll pass for a korean just fine
[18:54:59] <kshishkov> ke ke ke
[19:13:44] <BBB> j-b: ping
[19:13:54] <BBB> oh shit
[19:13:57] <BBB> j-b_Venice, ping
[19:21:58] <kshishkov> BBB: in your mail you have not explained why you still accept marriage proposals
[19:36:33] <mru> kshishkov: http://imagebin.ca/view/x6Tdu5C.html
[19:38:17] <kshishkov> mru: send a sixpack to RAD Software
[19:38:24] <BBB> what is the svnroot of ffmpeg.org?
[19:38:31] <_av500_> mru: it is clear where your emphasis was in this shot...
[19:38:37] <BBB> kshishkov, in some cultures it's ok to marry multiple times
[19:38:39] <BBB> even at the same time
[19:39:37] <kshishkov> BBB: yes, but usually it boils to whether your wives don't mind
[19:39:47] <_av500_> they have a say?
[19:40:03] <mru> not in those cultures
[19:40:23] <BBB> I was about to say
[19:40:30] <kierank> you have to treat them equally iirc
[19:40:51] <kshishkov> swell, more wives = more mothers-in-law
[19:40:52] <BBB> the wives, respectively to each other, yes
[19:40:59] <BBB> however, that's only on paper
[19:41:19] <BBB> I can always claim that in my world, a valentine's dinner has the same value as a slap in the face
[19:41:20] <BBB> or so
[19:41:40] <BBB> I still need the svnroot for ffmpeg.org
[19:41:41] <BBB> :)
[19:41:53] <BBB> oh, it's ffmpeg.org
[19:41:54] <BBB> d'oh
[19:42:04] <kshishkov> svn.ffmpeg.org/ffmpeg.org/trunk or something
[19:44:59] <BBB> yes, thanks
[20:03:24] <BBB> how do I update the website?
[20:03:34] <BBB> am I supposed to upload something somewhere?
[20:03:48] <kshishkov> no, commit is enough
[20:26:27] <CIA-17> ffmpeg: reimar * r21693 /trunk/libavformat/oggdec.c:
[20:26:27] <CIA-17> ffmpeg: Make sure the header value used to avoid repeating headers on seeking to the
[20:26:27] <CIA-17> ffmpeg: start and to avoid initializing codecs with missing headers is set for all streams.
[20:26:27] <CIA-17> ffmpeg: Fixes issue 1723.
[21:23:21] <KotH> grüezi
[21:23:26] <KotH> elenril: ask mru
[21:23:33] <KotH> elenril: and i wasnt in hell, but it was nearly as cold
[21:24:01] <elenril> hey BofH
[21:24:07] <elenril> colder than in chocolateland?
[21:24:38] <mru> ask me about what?
[21:25:31] <elenril> git mirror for nut
[21:26:33] <mru> someone working on nut?!?!?
[21:27:38] <KotH> http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2010/02/07#stt_gnu_ifunc
[21:27:50] <KotH> mru: must be nuts
[21:28:37] * elenril tries to hack nut sometimes for the lulz
[21:37:31] * elenril rotfls at FFmpeg/libavcodec H.264 output inferiorto QuickTime thread
[21:41:03] <mru> where?
[21:41:04] <mru> user?
[21:41:21] <elenril> http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2010-February/024043.html
[21:45:42] <BBB> I don't see the difference (?)
[21:45:50] <BBB> QT is just darker
[21:46:02] <BBB> I don't see a clear decrease in quality
[21:46:07] <mru> they look different
[21:46:14] <mru> but it's hard to call one or the other better
[21:46:25] <astrange> probably ffmpeg is using the sd colorspace
[21:46:48] <astrange> qt assumes hd if the input is large enough, and i think it does some kind of unhelpful gamma conversion
[22:10:22] <BBB> the delta shows that in his example (http://tomvision.blogspot.com/2010/01/i-think-i-found-flaw-in.html the tire), the only real difference that cannot be attributed to rounding is the region just above the tire
[22:10:30] <BBB> this is more nisy in qt than in lavc
[22:10:33] <BBB> noisy*
[22:10:48] <BBB> this explains the lesser compressibility in qt than in avc
[22:10:53] <BBB> other than that, the two are identicl
[22:13:25] <kierank> what resolution was that beagleboard videowall?
[22:18:09] <mru> the monitors are 1280x1024
[22:18:29] <mru> the videos were 1920x800 scaled up to the full size
[22:20:41] <saratoga> how does one build fft-test in ffmpeg?  i can't seem to find a makefile for it
[22:22:20] <mru> make libavcodec/fft-test
[22:23:48] <saratoga> do I need to have already built ffmpeg in the same directory?
[22:23:58] <DonDiego> just try the command
[22:24:08] <saratoga> i have and it does not work, hence the question ;)
[22:24:25] <DonDiego> your ffmpeg tree needs to be configured
[22:24:39] <saratoga> it is
[22:24:53] <DonDiego> then it should work
[22:25:54] <mru> works here
[22:28:29] <saratoga> trying a new folder fixed it, probably just some makefile weirdness on my system
[22:33:53] <saratoga> do I need to do make bin or make install to actually get the binary?
[22:34:57] <mru> of course not
[22:35:01] <saratoga> ah nevermind it ends up in libavcodec not the build dir
[22:35:44] <mru> where else?
[22:36:10] <mru> the target you give make is typically a filename
[22:40:31] <saratoga> my usual project has a policy against doing builds in the source tree, so i wasn't expecting that
[22:41:15] <mru> so don't do it there
[22:41:40] <mru> if you run make in the source tree you get output in the source tree
[22:41:50] <mru> run configure and make elsewhere, output goes elsewhere