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

[irc at mansr.com]

[00:36:21] <CIA-17> ffmpeg: michael * r21620 /trunk/libavformat/avidec.c:
[00:36:21] <CIA-17> ffmpeg: Only set duration for streams where it is likely correct.
[00:36:21] <CIA-17> ffmpeg: Fixes issue1120
[02:28:09] <Compn> whoa
[02:29:40] <mru> ?
[02:44:00] <Compn> nevermind, i was looking at something incorrectly
[03:24:04] <Dark_Shikari> apparently if you set the MMX2 flag, but not the MMX flag, when using swscale
[03:24:07] <Dark_Shikari> it can give broken output
[03:29:04] <aclarke_> Dark_Shikari what's a good proof-of-concept option for me to expose in libx264 specific options in the patch I'm working on?
[03:29:30] <Dark_Shikari> anything not currently in libx264.c
[03:29:31] <Dark_Shikari> intra-refresh
[03:29:32] <aclarke_> i can set up any AVOption-type value to be available at the init(..) call time.
[03:29:32] <Dark_Shikari> slice-max-size
[03:29:37] <Dark_Shikari> slice-max-mbs
[03:29:38] <Dark_Shikari> slices
[03:29:40] <aclarke_> k; I'll take those
[03:29:42] <aclarke_> thx
[03:29:54] <aclarke_> any one a personal favorite?
[03:30:43] <Dark_Shikari> aq-strength
[03:30:45] <Dark_Shikari> psy-rd
[03:30:56] <Dark_Shikari> oh, psy-rd is a special case.  it requires a weird syntax
[03:31:00] <Dark_Shikari> --psy-rd A:B
[04:41:32] <CIA-17> ffmpeg: michael * r21621 /trunk/libavcodec/mpegvideo_parser.c: (log message trimmed)
[04:41:32] <CIA-17> ffmpeg: Revert
[04:41:32] <CIA-17> ffmpeg:  r12684 | michael | 2008-04-04 02:43:34 +0200 (Fri, 04 Apr 2008) | 2 lines
[04:41:32] <CIA-17> ffmpeg:  Disable the split function. This should end the mpeg1/2 global header issues.
[04:41:32] <CIA-17> ffmpeg: The split function is essential for -ss to work
[04:41:33] <CIA-17> ffmpeg: Fixes issue1226
[04:41:34] <CIA-17> ffmpeg: If this breaks something please tell me, also if someoen remembers what problem
[05:15:02] <astrange> mm, where's unsolo
[06:37:00] <astrange> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/ i was expecting more files...
[06:37:13] <elenril> J_Darnley: what happened to your patch for writing vorbiscomment to flac?
[06:41:50] <Dark_Shikari> astrange: ?
[06:41:52] <Dark_Shikari> it's paginated
[06:43:15] <astrange> oh, i have viewvc banner blindness from the cvs branch menu always being there
[07:11:53] <benoit-> moin
[07:16:22] <kshishkov> bonjour
[07:35:56] <KotH> salut
[07:36:04] <kshishkov> hej
[07:45:05] <benoit-> KotH: Guten Morgen
[07:52:53] <andoma> Dark_Shikari: what does x264 use to write mkv files? libmkv (seems it spawned from the x264 dev), or is it just code embedded in the x264 repo?
[07:53:25] <kierank> it uses haali's muxer
[07:54:47] <kierank> which is in the main x264 repo
[07:54:53] <andoma> ah, i see
[07:55:03] <andoma> thanks
[07:56:56] <kshishkov> andoma: kan ukrainsk man få ett erbete i Sverige?
[07:57:44] <andoma> kshishkov: vet inte riktigt hur det funkar
[07:57:54] <andoma> kshishkov: hade ni varit med i EU hade det nog varit lättare
[07:58:36] <saintdev> andoma: the x264 was written by haali, libmkv is based off of it for HandBrake.
[07:58:53] <kshishkov> andoma: naturligtvis
[08:12:45] <kierank> kshishkov: when you wrote vc-1 did you RE it or use the spec?
[08:13:00] <jai> probably the reference code
[08:13:21] <kshishkov> there was both standard draft and reference decoder available
[08:13:23] <jai> the spec out there in the wild is too old, good for an overview though
[08:13:34] <Dark_Shikari> andoma: it's a very simple mkv muxer
[08:13:36] <siretart`> morning
[08:13:39] <Dark_Shikari> it could probably use indexing support
[08:13:40] <jai> hello siretart`
[08:13:47] <siretart`> hi jai
[08:18:14] <jai> superdump: i'm still confused as to what exactly we hope to achieve with a release :)
[08:18:34] <superdump> jai: hopefully a sync point for distributions
[08:18:44] <superdump> so they don't use <random svn checkout>
[08:19:38] <jai> superdump: so more like milestones rather than stable api maintained releases
[08:20:12] <superdump> unless we can manage to find someone willing to maintain them
[08:20:16] * superdump looks at siretart`
[08:20:28] <jai> i feel this just leads to people maintaining their own custom patches on top of the tarball
[08:20:53] <kshishkov> jai: that's true for any opensource project
[08:20:58] <jai> also, maybe there can be a more open discussion this time around regarding the policy itself
[08:21:10] <kshishkov> at least we don't release too often
[08:21:19] <jai> kshishkov: in this case, these patches can be backported to the branch so all distros benefit
[08:22:42] <jai> but at the outset, atleast for 0.5, there was a clear statement from diego that no functionality/bugfix patches would be inegrated
[08:22:48] <jai> *integrated
[08:23:03] <superdump> that was his choice as release manager
[08:23:24] <superdump> maybe if you get baptiste to be release manager this time, things will be different
[08:23:32] <jai> superdump: fair enough, so maybe more voices this time around
[08:23:52] <jai> roles/titles aside, thats the point i wanted to make
[08:25:06] <superdump> last time diego took a stand and did it his way because otherwise we would have sat talking about it again and not got anything done
[08:25:22] <superdump> siretart`: what did you think of the last release? any comments?
[08:25:50] * siretart` reads backlog
[08:25:57] <superdump> j-b: do you have any comments about the 0.5 release or don't you care because you track head or something?
[08:26:06] <andoma> i've relied on the 0.5 release for quite some time for one of my projects. works very good for me. prior to 0.5 there was always something that broke when something changed in ffmpeg
[08:26:27] <siretart`> superdump: oh, you are asking for a retospective of the 0.5 release?
[08:26:32] <superdump> yes
[08:26:58] <siretart`> I think it was a great idea, and I'm really glad that it happened. let me explain why
[08:27:13] <siretart`> before, the debian package shipped snapshot of more-or-less random dates
[08:27:21] <superdump> andoma: you mean certain things change in the api and you have to adapt to them if you track head, but rather if you can stick to a release version there's nothing to change for you?
[08:27:33] <siretart`> I started to look at other distros like gentoo to see what snapshot dates they use
[08:27:43] <siretart`> but it is impossible to find a proper sync point
[08:27:57] <andoma> superdump: exactly
[08:28:03] <siretart`> moreover, I was heavily bitten by crash reports of gnome users, they mainly use gst-ffmpeg
[08:28:16] <jai> andoma: thats awesome, but i'm sure you would benefit quite a bit more if you could occasionally get a few bugfixes now and then
[08:28:26] <siretart`> with the 0.5 release, gst-ffmpeg switched to that branch, so their copy and the system ffmpeg finally went in sync
[08:28:31] <jai> andoma: without having to worry about api changes
[08:28:37] <siretart`> and crashes went instantly away
[08:28:48] <superdump> andoma: so it moves the burden of maintenance from being an ongoing thing to being a do it once and move on until the next release thing
[08:29:18] <superdump> siretart`: interesting to know
[08:29:32] <siretart`> as for maintenance, well, I'd of course would have preferred more active maintenance on 0.5, but as it didn't really happen (diego was too busy), I accumulated lots of patches for the distro package
[08:29:36] <superdump> i'll have to talk to bilboed when he gets back
[08:29:46] <siretart`> now that diego granted me svn access and indicated interest in merging them, I'm upstreaming them now
[08:30:21] <superdump> another thing with a sync point for distros is that maintenance can be distributed i guess
[08:30:28] <superdump> is there much in the way of patch sharing?
[08:30:36] <siretart`> that was the intent, but didn't really happen
[08:30:53] <siretart`> I plan to create a wiki page on the multimedia wiki that lists the various distro and 3rd party packages
[08:30:55] <andoma> but franky, for that particular project i mostly rely on FFmpeg's mkv muxer... that's why i asked around about a library that does just mkv muxing earlier..
[08:30:56] <superdump> and do you know if other distros are still using 0.5 or are now using a more current snapshot?
[08:30:57] <KotH> siretart`: do you need/want anything from .ch?
[08:31:10] <KotH> siretart`: now is the last chance to let me know :)
[08:31:36] <siretart`> KotH: how much are cheap swiss knives with usb pendrives?
[08:32:05] <siretart`> superdump: TBH, I don't really know. that's what I intent to learn in that wiki page
[08:32:08] <superdump> andoma: what about the official matroska libs? or there is a libmkv that some guys at handbrake made i think
[08:32:25] <siretart`> superdump: as in: write to various distro and 3rd party package maintainers to fill in missing information
[08:32:39] <superdump> siretart`: sounds like a good plan
[08:32:47] <andoma> superdump: the official libs seems c++ish
[08:32:48] <siretart`> mike gave me the wiki account yesterday, so I can finally start working on that
[08:32:54] <andoma> superdump: so i stoped looked at them
[08:32:58] <superdump> andoma: right, i think they are
[08:33:01] <superdump> ok
[08:34:02] <superdump> siretart`: maybe if maintenance burden is shifted downstream and a sync point is provided by us, then patches can come back upstream (even if they're complete crap and we have to solve the issue in a different way...)
[08:34:25] <superdump> i don't know if that's better or not though
[08:34:50] <j-b> superdump: I do not care. I use HEAD for WIndows and Mac, and I couldn't care less about Linux's mess
[08:34:51] <superdump> i would think downstream noise is the best way to know what's wrong in the release version though
[08:35:04] <superdump> j-b: fair enough
[08:35:16] <superdump> j-b: thanks for your input :))
[08:35:26] <siretart`> superdump: I didn't say that publicy yet, but I my agenda for a potential 0.6 release includes these points
[08:36:00] <KotH> siretart`: uhm..
[08:36:08] <superdump> i think that might be a good approach
[08:36:14] <KotH> siretart`: i think they are somewhere between 50 and 100 chf
[08:36:20] <jai> superdump: imho its a better idea to leave backporting to people who understand the diffs/fixes
[08:36:49] <superdump> it seems fairly clear that very few/none of us want to continue maintaining an old branch with any significant effort
[08:36:57] <KotH> siretart`: do you want one?
[08:37:13] <jai> superdump: we could ask on the ML one last time ;)
[08:37:22] <jai> superdump: but before that the policy must be made clear
[08:37:40] <superdump> jai: i was thinking that leveraging downstream for identification of issues and maybe submission of (poor?) patches back upstream, that would reduce the workload a bit
[08:37:40] <KotH> siretart`: and there are no cheap swiss army knives ;-)
[08:37:47] <jai> superdump: because last time around, it was made pretty clear that only security relevant fixes would go in
[08:38:03] <superdump> jai: and then we can review patches and apply or fix issues 'properly'
[08:38:05] <jai> superdump: which confuses me atleast.
[08:38:11] <superdump> backport whatever is necessary
[08:38:23] <jai> superdump: sure
[08:38:24] <superdump> and then make point releases
[08:38:25] <siretart`> KotH: if it doesn't cause you too much trouble, I'd love to have one! my current pendrive on my keyring broke, and it is always handy to have a rescue system on your key :-)
[08:38:36] <jai> superdump: we do have decent commit log messages which describe the intent
[08:38:55] <siretart`> I assume that the swiss knives are more protected than these "ultraportable" pendrives
[08:39:11] <jai> superdump: so i assume the next release wont have disclaimers like - "no bugfixes evah"
[08:39:28] <siretart`> jai: how about the policy "best efford"?
[08:39:37] <superdump> depends on the decided policy and/or the release manager
[08:39:59] <siretart`> -d+t
[08:40:05] <jai> siretart`: i'm okay with that, as long as it is made clear at the beginning
[08:40:28] <KotH> siretart`: ok, i'll try to find one... i hope they have some at the train staition (wont have time for much more)
[08:40:33] <jai> contradicting statements are something we should avoid
[08:40:40] <superdump> like i said, last time diego decided he was going to be release manager, no one strongly objected, he said he was going to do it his way so we could at least get one release out the door and then we could improve things afterwards
[08:40:56] <siretart`> KotH: if not, it's really not that important
[08:41:15] <superdump> originally me and baptiste wanted a second release within 3-6 months
[08:41:18] <superdump> diego said 6
[08:41:24] <superdump> it never happened
[08:41:26] <superdump> :)
[08:41:49] <superdump> but if we want to get another one out within a year of the last one, we need to get going _now_
[08:41:55] <superdump> we're probably going to overshoot
[08:41:58] <jai> superdump: we can make it happen - just write a mail saying you wish to get 0.6 work started
[08:42:13] <siretart`> will you two be at fosdem?
[08:43:28] <siretart`> I take the silence as 'no'. :-)
[08:43:38] <andoma> i wanted to go
[08:44:05] <jai> siretart`: sorry, would love to but the the logistics of it seem to fail me ;)
[08:44:11] <jai> siretart`: though i'm mostly on irc
[08:45:02] <siretart`> I guess the 0.6 release will be an important topic this weekend. perhaps it would be best to not rush decision on a 0.6 release before fosdem
[08:46:17] <jai> siretart`: sure
[08:51:56] <superdump> siretart`: no, sorry
[08:52:43] <superdump> siretart`: you could maybe discuss it at fosdem, but maybe people there will not be those interested in managing a release
[08:52:50] <superdump> i think diego is going though
[08:54:00] <siretart`> hm, I actually didn't wan't to say it publicy yet, but perhaps I should anyway
[08:54:14] <siretart`> I'm strongly considering nominating myself as release manager for the 0.6 release
[08:54:31] <siretart`> I will stay in the same hostel as diego this weekend and will use the time to discuss this with him
[08:55:19] <kshishkov> bring a big stick
[08:56:32] <siretart`> who? me?
[08:56:36] <siretart`> or for me? ;-)
[08:57:09] <kshishkov> you, for convincing when there are no more technical arguments
[09:00:45] <jai> hm
[09:02:42] <superdump> jai, siretart` : mail sent
[09:03:10] <jai> superdump: excellent :)
[09:16:03] <kierank> yes
[09:16:07] <kierank> whoops
[09:20:49] <siretart`> superdump: thanks for the mail
[09:21:05] <superdump> no problem
[09:21:31] <merbzt> there are stuff that we should w8 for before we do a new release
[09:21:42] <superdump> i think if you're willing to do that extra work of keeping on top of downstream (it seems you're at least interested) then maybe we could do that
[09:22:05] <superdump> merbzt: it'd be nice for michael to 'finish' his h.264 commit spree
[09:22:23] <siretart`> I'd love to see ffprobe and amr merged for 0.6
[09:22:26] <superdump> merbzt: but what else? things almost ready to land like amr-nb, wmavoice and such?
[09:22:41] <kshishkov> Indeo 5
[09:22:46] <merbzt> wmavoice, amr, bink, indeo 5
[09:22:58] <superdump> by all means we can make a feature blocker list
[09:23:00] <superdump> :)
[09:23:05] <merbzt> he-aac
[09:23:11] <siretart`> too bad that roundup doesn't allow 'targetting' bugs to a past or upcoming release…
[09:23:21] <superdump> it would be nice to get he aac in, yes
[09:24:01] <merbzt> pending als stuff also
[09:24:09] <pross-au> superdump: also makes sense to do releases BEFORE northern hemisphere summer (gsoc work)
[09:24:22] <superdump> pross-au: that was my thinking too
[09:25:04] <superdump> merbzt: please respond to the mail with such a feature hit list :)
[09:25:22] <merbzt> we should start a wiki page to collect what we want in the next release
[09:25:33] <kshishkov> pross-au: in our case it's "default summer time", too few Australian FFmpeg devs here
[09:26:21] <pross-au> your definition of summer hardly passes for spring here
[09:27:03] <kshishkov> huh? "hot and nasty weather" is your spring?
[09:27:53] * kshishkov was lucky to spend the worst part of Ukrainian summer far away
[09:27:58] <pross-au> it was last year
[09:29:28] <kshishkov> it's still was a miracle finding time to finish RTMP client while being in Stockholm
[09:56:30] <superdump> kshishkov: why? because you liked walking around in stockholm so much?
[09:57:07] <CIA-17> ffmpeg: pross * r21622 /trunk/ (6 files in 3 dirs): IFF PBM/ILBM bitmap decoder
[09:58:11] <CIA-17> ffmpeg: pross * r21623 /trunk/libavformat/iff.c: Extend IFF demuxer to parse PBM/ILBM bitmap chunks
[09:59:06] <CIA-17> ffmpeg: pross * r21624 /trunk/libavformat/iff.c: Indentation cleanup
[10:00:26] <superdump> merbzt: maybe we can edit http://wiki.multimedia.cx/index.php?title=FFmpeg_Release_Plan
[10:03:06] <merbzt> superdump: fixed
[10:03:13] <superdump> merbzt: the things that need doing section at least :)
[10:03:33] <superdump> :)
[10:05:45] <superdump> merbzt: i moved it to the things that need doing section
[10:05:53] <pross-au> dont we already have an API-ABI changelog?
[10:06:24] <superdump> i've changed that to 'update'
[10:07:27] <pross-au> superdump: its already up to date
[10:07:35] <superdump> really?
[10:08:17] <superdump> changed to
[10:08:19] <superdump> Make sure API/ABI changelog is up-to-date
[10:08:21] <superdump> :)
[10:08:45] <pross-au> Ok.
[10:11:26] <superdump> i guess libavfilter is still a way off...?
[10:13:32] <siretart`> superdump: the debian package for 0.5 already shipped libavfilter0. I don't think any application used it yet, though
[10:13:50] <superdump> i'm not sure how usable it is yet
[10:13:58] <predat> Hello, Avid release an update to his codec (2.1) and i can't decode DNxHD185 with ffmpeg now -> segmentation fault
[10:14:03] <superdump> some stuff has been in trunk for a long time, but no integration
[10:14:08] <siretart`> superdump: what should be considered however is if you/we want to bump SONAME of  libavcodec/libavformat for 0.6
[10:14:26] <superdump> predat: http://ffmpeg.org/bugreports.html
[10:16:33] <mru> morning
[10:18:46] <superdump> morning mru
[10:22:15] <predat> thank you superdump
[10:22:35] <superdump> predat: i expect baptiste will look at that at some point
[10:23:30] <predat> he send a mail on the user list yesterday
[10:25:54] <kshishkov> superdump: why else?
[10:26:22] <kierank> Are there any formats where the container sees one stream but in fact there are multiple streams disguised as one stream?
[10:26:28] <superdump> kshishkov: it's covered in snow at the moment
[10:26:36] <superdump> and the water froze
[10:27:17] <kshishkov> well, here it's water in basins formed by ice walls on every street
[10:27:37] <kshishkov> and it's slippery as a road to Ukraine
[10:28:28] <kshishkov> (not that anyone has tried to clean streets in a weeks)
[10:28:54] <kshishkov> and temperature swings from -25 to +5 it's even more fun
[10:33:01] <superdump> sounds fun :)
[10:33:31] <kshishkov> yeah
[10:34:29] <kshishkov> in April I was out of Kharkov for two weeks and it still managed to get worse in that time
[10:45:34] <peloverde> mru, http://www.embeddedgurus.net/stack-overflow/2010/02/is-gcc-good-compiler.html
[10:45:47] <mru> read it just now
[10:46:01] <mru> I'll have to write a response
[10:46:19] <mru> that guy has some good points
[10:46:24] <mru> but often he's plain wrong
[10:46:55] <mru> cf his "C tips" series
[10:50:00] <mru> I'll have to have a look at that iar compiler
[10:50:15] <av500> so high paid consultants use expensive compilers and lowly paid ones use cheap gcc....
[10:50:40] <mru> being highly paid doesn't mean you're right
[10:50:48] <kierank> lol
[10:50:53] <av500> no, he who pays you thinks you are :)
[10:51:15] * mru glances at his clients
[10:51:28] <kshishkov> av500: he who pays thinks _he_ is
[10:51:53] <av500> the client is always right!
[10:52:24] <kshishkov> in certain bounds
[10:55:21] <kshishkov> the trouble with commercial compilers is that you usually can't run them on what you like
[10:57:44] <av500> no, it runs nicely on the AVR that thos guys loves to develop on....
[10:57:51] <av500> thos->this
[11:32:11] <pross-au> peloverde: one could use the same argument with operating systems (free, cheap, expensive, very expensive).
[11:32:52] <peloverde> Funny because it is 100x easier to develope FFmpeg with free Linux than with expensive windows
[11:33:19] <av500> peloverde: you would think differently if you were paid $$$$$ :)
[11:33:30] <pross-au> peloverde: microsoft gcc compiles FFmpeg out of the box
[11:33:34] <av500> suddenly using windows would make it so much better
[11:33:39] <kshishkov> are there firms dedicated solely to compiler tech support and not being their devs?
[11:34:07] <av500> kshishkov: and they binary patch the compilers if they find a problem?
[11:34:47] * kshishkov remembers about CodeSourcery
[11:34:52] <mru> my advice is to stay well clear of any product that has a dedicated third-party support industry built around it
[11:35:21] <peloverde> Well there goes automobiles...
[11:35:41] <av500> and relationships
[11:35:47] <pross-au> LOL
[11:35:56] <kshishkov> and Linux
[11:36:07] <av500> thats a relationship
[11:36:18] <pross-au> theres heap of third party FFmpeg stuff no?
[11:36:21] <kshishkov> and computers (except maybe from Apple)
[11:36:42] <mru> av500: what? there's a number I can call for help with my gf?
[11:36:54] <pross-au> ffmpeg2theora
[11:36:55] <mru> (no, I don't have a gf)
[11:36:59] <av500> it was in the paperwork that came with her
[11:37:20] <kshishkov> mru: psychoanalysts
[11:37:31] <mru> av500: I'm not _that_ desperate
[11:37:36] <pross-au> mru: when you do, be sure to cough up for the extended warranty option
[11:37:43] <mru> I know a psychologist...
[11:38:41] <kshishkov> psychologist is a person who tells what's wrong with your head, psychoanalyst just hears your blabbery about personal issues
[11:39:08] <av500> nothing is wrong with MY head, it is all the others'
[11:39:21] <mru> kshishkov: I've never asked her to do either
[11:39:24] <mru> nor will I
[11:40:47] <kshishkov> fine with me
[11:41:30] <kshishkov> but you should admit there _is_ a whole industry built around resolving personal issues for money
[11:43:00] <pross-au> kshishkov: is there an app for that?
[11:43:15] <kshishkov> pross-au: emacs, alt-m elisa
[11:44:17] <pross-au> SBAITSO2.EXE
[11:44:19] <mru> it's m-x doctor
[11:45:17] * kshishkov does not have "meta" key on any of his keyboards. Must be too new.
[11:45:41] <mru> meta is old as the hills
[11:45:55] <pross-au> shift+':'
[11:46:22] * mru has all of Escape, Meta, Alt, Control, Shift
[11:46:36] <mru> and hyper and mode-switch too
[11:47:02] <kshishkov> Das Keyboard oder Symbolics?
[11:47:11] <mru> das keyboard
[11:47:22] <mru> lets me make up my own names for keys ;-)
[11:50:31] <pross-au> Replace 'F1' with 'Mans'
[11:50:51] <merbzt> MÃ¥ns
[11:50:57] <av500> pross-au: F1 holds "/nick _troll_"
[11:51:18] <pross-au> merbzt: 7-bit terminal here
[11:52:09] <merbzt> I can lend you an extra bit
[11:53:29] <pross-au> *i* am the 7-bit terminal
[11:53:46] * kshishkov kan ge ä, å och ö
[11:54:47] * mru has ü too
[11:54:49] <mru> just in case
[11:55:01] <av500> ü is important
[11:55:05] <merbzt> Müns ?
[11:55:06] <mru> and in uppercaser Ü
[11:55:08] * kshishkov has a bit of Cyrillic too
[11:55:29] <mru> I don't need cyrillic
[11:55:38] <mru> don't know any of those languages
[11:55:55] <mru> the fragments I know are read-only
[11:55:59] <kshishkov> you own a dictionary for one of them
[11:56:25] <kshishkov> my fragments are usually are write-only
[12:00:30] * kshishkov thinks maybe it's worth to learn Korean as well
[12:01:54] <mru> korean is hard
[12:01:59] <mru> script is easy
[12:02:04] <mru> language is hard
[12:02:43] <kshishkov> harder than German or Russian?
[12:03:48] <mru> much harder than german
[12:04:07] <mru> they inflect verbs in 14 ways depending on politeness level
[12:05:01] <kshishkov> that's nothing, how much exceptions for conjugating rules are there?
[12:05:20] <mru> I've no idea
[12:05:38] <mru> they also have grammatical constructs that don't exist in western languages
[12:05:58] <kshishkov> there is similar situation with Japanese, but there are only two irregular verbs
[12:06:03] <mru> a western sentence has subject, verb, and zero or more objects
[12:06:11] <mru> korean has a special inflection for the topic
[12:06:28] <kshishkov> and in Russian (and to lesser extent German) there are almost no _regular_ forms
[12:06:35] <mru> which is applied in addition to subject/object inflections
[12:07:06] <mru> and that's just about all I know about korean
[12:07:28] <kshishkov> what about Russian?
[12:07:39] <mru> I know the script
[12:07:42] <mru> and a few words
[12:07:47] <mru> forgot most of the grammar
[12:07:53] <kshishkov> any impression left?
[12:08:19] <mru> it was complicated
[12:10:06] <kshishkov> well, for example Russian verb "to get victory" does not have future single 1st person form but all other are there
[12:15:23] <peloverde> English+Spanish has served me pretty well in the western hemisphere
[12:15:49] <kshishkov> it was English+Swedish for me
[12:16:25] <mru> my spanish friends keep saying I should learn it
[12:17:23] <kshishkov> peloverde: I suspect you've not been to France
[12:17:36] <peloverde> I have not
[12:17:58] <peloverde> I also make a habit of avoiding Quebec, Haiti, and Brazil
[12:18:40] <kshishkov> why Quebec?
[12:18:55] <peloverde> I don't speak French
[12:19:04] <av500> Quabac?
[12:20:13] <mru> quack?
[12:20:50] <kshishkov> que?
[12:21:00] <av500> bec!
[12:25:42] <Compn> the canadians and youpers pronounce it 'kebek'
[12:26:03] <Compn> ... i think
[12:27:15] <peloverde> That's how my buddy who went to McGill pronounces it
[12:29:33] * mru heads for the airport
[12:29:42] <mru> 2h to "takeoff"
[12:29:57] <kshishkov> where to?
[12:30:30] <Compn> 'off to save the world'
[12:30:42] <av500> not dominate it?
[12:30:52] <Compn> well you cant dominate a world thats been destroyed
[12:54:07] <kierank> hmmm trying to make a decoder without a spec is like an online treasure hunt
[12:54:38] <av500> kierank: but you are lucky, you at least have an encoder :)
[12:54:47] <kierank> yeah that's true
[12:54:59] <kierank> except only 1 day left on the trial
[12:55:31] <kshishkov> kierank: it's a wrong place to complain
[12:55:41] <kierank> not complaining
[12:55:55] <kierank> the treasure hunt is quite interesting when you find some random document that helps you
[12:56:03] <mru> kierank: so hack the protection
[12:56:19] <kierank> it has some ring0 kernel crap
[12:56:42] <mru> everything can be hacked
[12:56:51] <kierank> and a driver on the system that BSODs when you try and mess with it
[12:57:04] <kierank> someone else is working on cracking the anti-debug stuff
[12:57:22] <kierank> who's done iLok before
[13:01:35] <jai> done as in reversed?
[13:01:42] <kierank> yes
[13:02:58] <Compn> what codec are you working on ?
[13:03:06] <kierank> Dolby E
[13:03:39] * av500 has only Dolby B amd C on his tapedeck
[13:04:12] <kshishkov> kierank: google seems to know
[13:04:45] <kierank> you mean that tutorial on that cracking site?
[13:04:59] <kierank> didn't work...
[13:05:15] <kshishkov> could not find DEBUG?
[13:06:00] <kierank> link m,e
[13:06:08] <kierank> dunno what you're talking about
[13:06:56] <kshishkov> anyway, what does IDA say?
[13:07:23] <kierank> program shuts down as soon as you open it in ida
[13:07:36] <twnqx> Oo
[13:07:48] <twnqx> wait, you can run programs in ida these days?
[13:07:51] <kshishkov> and opening on box without that shit running?
[13:08:05] <jai> twnqx: yep
[13:08:16] <kierank> kshishkov, what shit?
[13:08:17] <jai> it has debugging support since quite some time
[13:08:21] <jai> userspace that is
[13:08:26] <twnqx> wow. i never used that...
[13:08:41] <kshishkov> kierank: simply copy driver to another machine and disassemble it in IDA
[13:08:50] <jai> well, with ollydbg around you dont need to ...
[13:08:59] <twnqx> but last time i used IDA i gave up on what i intended to do when i recognized RSA encryption :P
[13:09:39] <jai> twnqx: as in parts of the binary were encrypted ?
[13:11:10] <twnqx> no, keyfiles
[13:17:17] * mru wants a pc with jtag
[13:17:25] <twnqx> Oo
[13:17:37] <kshishkov> mru: build one
[13:17:47] <twnqx> you want to jtag into your... what?
[13:17:54] <kshishkov> i7
[13:17:59] <twnqx> hm
[13:18:04] <mru> av500: when will you fix the android?
[13:18:26] <mru> had to reboot it twice to revive bt
[13:18:29] <twnqx> does the i7 even have a jtag interface? and is intel giving out the specs?
[13:19:06] <jai> kierank: http://www.tuts4you.com/download.php?view.2778
[13:19:10] <av500> mru: u on 1.6?
[13:19:24] <av500> 1.7.xx?
[13:19:41] <av500> bt tethering is in constant improvement mode atm
[13:20:34] <kierank> jai: tried that one
[13:22:13] <superdump> av500: bt? mru: the android?
[13:24:47] <merbzt> kierank: could you unpack the binary ?
[13:25:35] <av500> superdump: android running on an Archos A5, using bluetooth tethering to a mobile phone
[13:25:48] <superdump> and what is it being used for?
[13:26:16] <av500> I guess for irc chatting on mru's side :)
[13:26:37] <superdump> hehe
[13:29:28] <kierank> [13:24] <@merbzt> kierank: could you unpack the binary ? --> nope
[13:30:12] <superdump> brb
[13:30:13] <mru> av500: 1.7.33
[14:54:03] <CIA-17> ffmpeg: michael * r21625 /trunk/ffmpeg.c: Alternative solution for the mpegvideo_split + mov problem.
[15:05:02] <ramiro> interesting... this product claims they use ffmpeg: http://www.samsung.com/us/consumer/tv-video/blu-ray/blu-ray-players/BD-P1600/XAA/index.idx?pagetype=prd_detail&tab=support
[15:05:47] <ramiro> it's also 57% off =)
[15:10:00] <CIA-17> ffmpeg: michael * r21626 /trunk/ (tests/ref/lavf/ffm ffmpeg.c):
[15:10:00] <CIA-17> ffmpeg: Correct opts calulation in ffmpeg.c.
[15:10:00] <CIA-17> ffmpeg: This correct the stop point for demuxing with -vcodec copy and -t as well as
[15:10:00] <CIA-17> ffmpeg: packet interleaving. (we already diddrop packets but kept demuxing them
[15:10:00] <CIA-17> ffmpeg: for too long due to opts being wrong)
[15:10:00] <CIA-17> ffmpeg: the change to ffm is due to 2 packets with timestamp 0 being stored
[15:10:01] <CIA-17> ffmpeg: in different order.
[15:19:34] <kshishkov> ramiro: maybe it uses FFmpeg solely for decoding interlaced VC-1 on Blu-Ray :P
[15:20:10] <CIA-17> ffmpeg: michael * r21627 /trunk/ffplay.c:
[15:20:10] <CIA-17> ffmpeg: The convertion between bit and byte is 8 not 60.
[15:20:10] <CIA-17> ffmpeg: Fixes wrong cursor key seek distances.
[15:24:28] <janneg> time to use the metri^Wbinary system for time
[15:37:40] <drv> yay, kega video decoder working
[15:38:33] <kshishkov> yep, Compn verified that before adding that DLL entry to codecs.conf, didn't he?
[15:38:34] <ramiro> kshishkov: I'm downloading the firmware update right now. I'm still looking for offer for sources
[15:39:16] <ramiro> I wonder how it's possible to update it
[15:39:19] <drv> had to re-RE some of the details ;)
[15:39:29] <ramiro> oh, we don't use gplv3, they don't need to make us update it =/
[15:39:33] <kshishkov> drv: for example?
[15:39:56] <drv> the one code references the previous frame, not the current one
[15:40:07] <drv> and the offset for that type can wrap around
[15:40:10] <drv> updated wiki page :P
[15:40:18] <kshishkov> thanks
[15:40:34] <drv> also output looks too dark, but i'm not sure if that is a swscale problem or my eyes are broken or what
[15:40:35] <kshishkov> for the only sequence I had it made no difference
[15:40:45] <drv> i made myself a nice capture of the Zero Wing opening ;)
[15:41:03] <kshishkov> with AYB?
[15:41:06] <drv> yep
[15:43:02] * kshishkov should RE a codec
[15:44:31] <ramiro> ok, I sent an e-mail to samsung asking for sources...
[15:45:11] <superdump> i was getting the user manual to see what they're using it for
[15:45:15] <superdump> or to have a guess
[15:45:20] <superdump> do they have some medi@ thing?
[15:45:31] <superdump> i guess it'll be some upnp/dlna player
[15:45:38] <superdump> s/player/client/
[15:47:14] <drv> aha, it's RGB555, not 565
[15:47:25] <superdump> ramiro: > Hey Rob
[15:47:27] <superdump> >
[15:47:30] <superdump> oops
[15:47:37] <superdump> ramiro: http://is.gd/7CBYj
[15:47:41] <superdump> that one too
[15:55:19] <ramiro> superdump: do you know what they use ffmpeg for?
[15:55:30] <ramiro> they have some youtube downloader thingy...
[15:55:51] <ramiro> great, the store that had it 57% off is offline...
[15:59:02] <ramiro> I'm curious as to what I can access with the ethernet port.
[15:59:23] <ramiro> only those subscription-based services, or is it possible to access your home network and player whatever is there?
[16:02:33] <Honoome> ramiro: they might have “DLNA” support (UPnP/AV streaming)
[16:03:42] <mru> ugh
[16:03:48] <ramiro> what's that?
[16:04:00] <ramiro> it seems the characters you used got mangled in xchat here..
[16:04:27] <ramiro> I can se "a with a litte hat" "box" "box" DLNA "a with a little hat" "box" "box"
[16:04:40] <drv> "smart" quotes ;)
[16:04:51] <peloverde> X-Chat defaults to the MIRC character set
[16:06:05] <ohsix> mirc doesn't have a character set, irc just has a weird one :> (but is 8 bit clean) those were multibyte characters
[16:06:11] <ramiro> apparently there's a "character set translation" where you have to pick a file, but I don't know what that is.
[16:06:34] <drv> irssi at least can autodetect most of the time
[16:07:38] <ohsix> utf8 if its sane; but different languages stick with old encodings so you typically have to pick by channel if you're talking in arabic or whatever
[16:08:20] <ohsix> this persists even though most ircds have been 8 bit clean for like 15 years; basically because mirc does it the piss poor way
[16:29:54] <peloverde> Time to head to the Airport. I'll see whomever at FOSDEM!
[16:53:50] <verb3k> Can anyone with a rough forecast of future ffmpeg development tell me whether the developers are interested in implementing frame-accurate seeking/trimming? I asked in the development mailing list but got no reply
[16:56:43] <av500> patches welcome, no?
[16:57:17] <kshishkov> yep, developer laziness overcomes everything!
[16:58:15] <verb3k> I just wanted to know what the core developers think about it, there is already ffmpeg-fas
[16:59:58] <kshishkov> well, nobody objects against accurate seeking, patch is welcome
[17:04:44] <verb3k> is there a reason why ffmpeg-fas isn't welcome?
[17:05:15] <kshishkov> because we have't heard of it
[17:05:22] <elenril> o/ people
[17:05:44] <verb3k> http://github.com/lbrandy/ffmpeg-fas
[17:06:08] <kshishkov> if a clean patch is sent, it will be reviewed and you'll get detailed awnser
[17:28:11] <elenril> http://yro.slashdot.org/story/10/02/03/1528242/MPEG-LA-Extends-H264-Royalty-Free-Period << hahahaha
[17:28:33] <kshishkov> not funny to Firefox folks
[17:28:48] <elenril> seems hilarious to me
[17:29:23] * elenril hopes somebody will port vimperator to chrome soon so he can switch
[17:33:01] <jai> elenril: if you are switching just for webkit, then maybe uzbl
[17:33:18] <jai> though the name is probably misleading ;)
[17:33:43] * elenril heard chrome is omgfast
[17:33:50] <kshishkov> how a bunch of meaningless letters mislead?
[17:34:08] <kshishkov> s/mislead/can be misleading/
[17:34:59] <elenril> hmm, looks nice
[17:35:02] <drv> uzbl -> "usable" in theory
[17:35:04] <elenril> jai: are you using it?
[17:35:06] <drv> though it looks anything but
[17:35:29] <jai> elenril: briefly, yeah
[17:35:44] <jai> elenril: i still use it with webkit nightlies
[17:36:02] <elenril> hmm, a package in debian
[17:36:04] * elenril installs
[17:36:24] <kshishkov> drv: that looks like Hebrew where th wrt vwls nl fr chldrn
[17:36:32] <jai> drv: requires some tinkering, and some more time "integrating" with your WM
[17:36:48] * elenril doesn'd mind some tinkering
[17:37:08] * elenril uses fvwm, aka 'script your own window manager', so yeah
[17:37:10] <jai> elenril: cool, might as well give it a try :)
[17:38:27] <kshishkov> drv: BTW, why don't you output data to RGB555NE?
[17:38:53] * elenril wonders why is nobody reviewing bink decoder
[17:38:56] <Compn> ugh
[17:38:57] <drv> wouldn't it have to be flipped in decoder then?
[17:39:07] <Compn> remind me to remove 'kega video' from small tasks page later
[17:39:13] <drv> RGB555 endian swapping is not clean and easy ;)
[17:39:18] <Compn> if drv didnt already do it :D
[17:39:26] <drv> i didn't yet, feel free
[17:39:54] <kshishkov> drv: if you read pixels explicitly as 16-bit word, they will be stored in native endianness
[17:40:24] <drv> hmm, i think you are probably right, there will be some endianness issues here anyway that i didn't think through...
[17:40:36] <drv> someday i should get a BE machine ;)
[17:40:40] <kshishkov> elenril: not much serious reviews in last weeks :(
[17:41:01] <kshishkov> drv: you can always ask for account on mru's Mac
[17:41:13] <elenril> kshishkov: just commit it and see what happens :)
[17:41:38] <kshishkov> elenril: no, you commit
[17:41:51] * elenril can't
[17:42:14] * kshishkov also can't - we have rules after all
[17:42:22] <drv> i had a qemu MIPS or something that was BE for a while, but it was painfully slow
[17:44:17] * kshishkov has real MIPS bit it's LE :(
[17:44:36] <kshishkov> damn those firmware creators - it could be set into BE mode instead
[17:46:24] * kshishkov wants anothe BE machine to play with
[17:46:48] <J_Darnley> elenril: you were asking about my flac-tag patch...
[17:51:43] <elenril> J_Darnley: so?
[17:51:53] <elenril> everybody forgot about it?
[17:52:01] <J_Darnley> It seems
[17:52:20] <kshishkov> even tried to ping it again?
[17:52:42] <J_Darnley> No, I've updated the patch so I'll send another mail
[17:52:44] * elenril 's experience tells him to bitch about his patches every few days on the ml _and_ irc
[17:53:34] <kshishkov> elenril: depends on maintainer
[17:56:04] <jez9999> BBB is usually here by now
[17:56:12] <jez9999> anyone know where he is?
[18:03:54] <kshishkov> there may be slight chance he's also travelling to FOSDEM
[18:14:05] <elenril> btw who is still against git?
[18:15:49] <Dark_Shikari> I think I have to give some credit to xiph for once.
[18:15:54] <Dark_Shikari> H.264 is free for another 5 years
[18:15:58] <av500> :)
[18:15:58] <Dark_Shikari> thanks xiph!
[18:16:00] <kshishkov> elenril: libswscale is
[18:16:09] <elenril> lol
[18:16:13] <elenril> kshishkov: what?
[18:16:26] <kshishkov> really - libswscale and Diego
[18:16:35] <av500> and in 5ys we will have H265 vs ...... still theora
[18:16:38] <elenril> how does swscale affect anything?
[18:16:47] * thresh had put libswscale as a submodule in git and just does not care
[18:17:10] <kshishkov> it's in external repo for now and we haven't agreed on a way to merge it in for git yet
[18:17:25] <elenril> with git merge? :)
[18:17:41] <kshishkov> and Diego does not like the fact it's impossible to correct commit message for siple tpyos
[18:18:07] <kshishkov> which is a good point too
[18:18:08] <elenril> we can do it like kernel people
[18:18:32] <kshishkov> make big companies pay core devs? I like that idea
[18:18:51] <jai> lol
[18:19:07] <elenril> he'll take care of the official tree and will merge other devs' stuff
[18:19:31] <elenril> since he's probably the only one who cares about typos so much
[18:19:45] <jai> elenril: ;)
[18:19:58] <jai> "tree sheriff"?
[18:20:12] <kshishkov> that will bottleneck development
[18:20:25] <jai> elenril: or we could just push to a designated master
[18:20:38] <elenril> kshishkov: how?
[18:20:53] <jai> single point of failure?
[18:20:57] <jai> elenril: ^
[18:21:07] <kshishkov> yes - look at the review process
[18:21:23] <elenril> meh, everybody can just pick where to pull from
[18:22:41] <kshishkov> too many repos
[18:23:00] <elenril> what's wrong with that?
[18:23:15] <elenril> many people have their own repos anyway
[18:23:33] <kshishkov> too forky
[18:24:04] * elenril still doesn't see what is wrong with that
[18:24:36] <elenril> so yeah, we'll have ten million branches on once server
[18:25:07] <elenril> now they exist anyway, just on other servers/people's computers etc
[18:26:19] <kshishkov> I just don't like an idea of somebody else between me and and repo
[18:26:35] <kshishkov> he can't be online 24/365
[18:27:40] <jai> indeed
[18:28:03] <elenril> then we'll have to live with tyops
[18:28:30] <thresh> nothing bad with those
[18:28:54] <thresh> later you can even arrange the 'most tyoped developer of the year' award
[18:28:54] <iive> kshishkov: even if he can be, there are years with 366 days!
[18:28:55] <elenril> michael's commits are full of those anyway and nobody does anything with that
[18:30:02] <kshishkov> wrong
[18:31:40] <jai> elenril: wait till diego comes back, there will be a propedit sled
[18:32:16] * elenril somehow doubts that
[18:32:28] <elenril> not that fixing them makes any sense
[18:32:59] <jai> i personally dont care, error correction kicks in
[18:34:03] <kshishkov> jai: some messages are incomprehensible, even Diego has committed one of those
[18:35:34] <jai> kshishkov: heh, we all slip sometimes
[18:42:17] <mru> so svn has "better" commit messages while git has better commits
[18:42:24] <mru> very tough choice that...
[18:44:15] <mru> besides, I tend to write better commit messages with git
[18:44:17] <kshishkov> too bad we can't get that propedit feature to git
[18:45:01] <elenril> you can always do a rebase :)
[18:45:23] <mru> it fucks up everybody's cloned trees
[18:45:31] <elenril> hence the :)
[18:46:06] <Honoome> mru: I tend to agree… actually I tend to *read* the commit messages (and thus write my own) while half the time I just use oneliners in cvs/svn ^^;;
[18:46:51] <mru> part of it is because git encourages you to commit to your tree and git-send-email the patch
[18:47:06] <mru> then the commit message has to contain the motivation for the path
[18:47:47] <Honoome> and the other hart is that git log -p has an usable speed compared to svn log :P
[18:47:55] <mru> that too
[18:48:03] <mru> and there's git log --grep
[18:48:09] <mru> and log -S
[18:48:19] <Dark_Shikari> yeah, svn is dog slow
[18:48:32] * elenril recently discovered than svn log connects to the server
[18:48:38] <mru> of course it does
[18:48:46] <mru> svn only stores the current revision locally
[18:48:52] <elenril> i thought it keeps at least the log locally
[18:48:56] <mru> and manages to do so using more space than an entire git history
[18:49:00] <Honoome> rotfl
[18:49:14] <elenril> it's more retarted than i thought
[18:49:35] <Honoome> mru: don't forget the size of an hg forest :| I haven't tried named branches but last time it was ludicrous
[18:49:53] <mru> everything I've heard about hg sounds ludicrous
[18:49:58] <mru> writing it in python for starters
[18:50:02] * thresh remembers arch
[18:50:10] <Honoome> mru: still better than bzr…
[18:50:17] <Dark_Shikari> oh god.
[18:50:20] <jai> bzr is pure crap
[18:50:22] <Honoome> Dark_Shikari: yeah?
[18:50:22] <Dark_Shikari> a guy is trying to realtime SD encoding with x264 ...
[18:50:26] <Dark_Shikari> ... on a Geode 500mhz
[18:50:30] <Dark_Shikari> fuck that thing is slower than a Cortex
[18:50:30] <mru> lol
[18:50:32] <elenril> lol
[18:50:39] <elenril> what's wrong with bzr?
[18:50:44] * elenril doesn't know anything about it
[18:50:45] <Dark_Shikari> elenril: it's slow as hell
[18:50:53] <Dark_Shikari> http://whygitisbetterthanx.com/
[18:51:02] <Dark_Shikari> git and hg are the only good dcvss
[18:51:41] <mru> I haven't used hg much
[18:51:53] <mru> but git makes everything else look like a bad joke
[18:51:53] <Honoome> I have for xine
[18:52:05] <Honoome> not bad, actually
[18:52:22] <Honoome> but dealing with multiple branches is space-consuming
[18:52:41] <mru> as bad as svn?
[18:52:47] <mru> and how good is it at merging?
[18:52:55] <Honoome> merging is nice
[18:53:17] <Honoome> but at least last I used it lacked named branches (went in “recently”)
[18:53:25] <Honoome> so you basically had one cloned repository per branch…
[18:53:44] <mru> like bitkeeper
[18:54:04] <Honoome> I just *love* the git branch command
[18:54:36] <mru> there's a reason I have 30-40 branches in my ffmpeg git
[18:55:22] <jai> http://whybzrisbetterthanx.github.com/
[18:55:35] <Honoome> jai: rotfl
[18:56:11] <jez9999> hey
[18:56:14] <jez9999> anyone know where BBB is?
[18:56:25] <mru> new york I think
[18:56:37] <elenril> lol
[19:04:14] <jez9999> yeah but why not on irc
[19:04:15] <jez9999> :-)
[19:04:49] <mru> maybe they don't have that in new york
[19:56:36] <CIA-17> ffmpeg: stefano * r21628 /trunk/ffmpeg.c:
[19:56:36] <CIA-17> ffmpeg: Make opt_frame_pix_fmt() call show_pix_fmts() if the provided option
[19:56:36] <CIA-17> ffmpeg: is "list".
[21:34:21] <CIA-17> ffmpeg: michael * r21629 /trunk/ffplay.c:
[21:34:21] <CIA-17> ffmpeg: Move is->frame_timer init from start to flush_pkt handling so it is also
[21:34:21] <CIA-17> ffmpeg: done on seeking. This fixes the bug where after reaching the end and waiting
[21:34:21] <CIA-17> ffmpeg: a few seconds seeking back to the begin messes up AV sync and playback speed.
[21:45:12] <_av500_> mru: looks like stefan has a full car :(
[22:51:11] <_av500_> Dark_Shikari: spawn labs?
[22:51:35] <Dark_Shikari> ?
[22:52:22] <_av500_> they remote your video console over the internet
[22:52:28] <_av500_> like onlive
[22:52:59] <_av500_> i thought you were involved :)
[22:53:11] <Dark_Shikari> no
[22:53:28] <_av500_> like that intrarefresh stuff
[22:53:32] <iive> _av500_: i've been hearing this for over a year.
[22:53:38] <Dark_Shikari> _av500_: different company
[22:53:43] <iive> have they made at least convinsing demo?
[22:54:05] <_av500_> iive: no idea
[22:54:11] <Dark_Shikari> dunno, the company I'm working with has
[22:54:11] <_av500_> just saw it on eng
[22:54:15] <Dark_Shikari> I've played Call of Duty in my browser
[22:54:17] <Dark_Shikari> works pretty well
[22:54:22] <_av500_> Dark_Shikari: known?
[22:56:15] <_av500_> http://news.creativecow.net/story/861515  looks like no x264 :(
[22:56:40] <jez9999> anyone know of any good channels for people who hack assembly code? ;-)
[22:57:00] <Dark_Shikari> #x264dev ? ;)
[22:57:19] <iive> this one is good start, the one DS point maybe too
[23:06:48] <CIA-17> ffmpeg: michael * r21630 /trunk/libavformat/utils.c:
[23:06:48] <CIA-17> ffmpeg: Try to open decoders in av_find_stream_info() even if no packets for the
[23:06:48] <CIA-17> ffmpeg: stream are found.
[23:06:48] <CIA-17> ffmpeg: Fixes issue1385
[23:11:08] <CIA-17> ffmpeg: stefano * r21631 /trunk/libavfilter/vf_crop.c:
[23:11:08] <CIA-17> ffmpeg: Use pixel format descriptors for checking if the input format is
[23:11:08] <CIA-17> ffmpeg: paletted. Simpler and more robust.
[23:15:34] <Dark_Shikari> oh kostya would love this
[23:16:31] <Dark_Shikari> http://forum.doom9.org/showthread.php?p=1108393
[23:16:41] <Dark_Shikari> "The VLC tables are not in the specs, and can not be reverse-engineered from binary code"
[23:16:49] <twnqx> lol
[23:18:32] <Kovensky> the public header libavutil/pixdesc.h is broken
[23:19:28] <Kovensky> there's one avcodec deprecated function that got moved there (avcodec_get_pix_fmt -> av_get_pix_fmt)
[23:19:44] <Kovensky> more specifically, it depends on intreadwrite.h ._.
[23:20:20] <Kovensky> (and avutil.h doesn't include pixdesc.h it for some reason)
[23:25:56] <saste> yes intreadwrite.h is not public
[23:26:05] <saste> how do I miss this?
[23:26:49] <saste> would be possible to export that also?
[23:34:57] <CIA-17> ffmpeg: michael * r21632 /trunk/ffplay.c:
[23:34:57] <CIA-17> ffmpeg: Clean after togling wave.
[23:34:57] <CIA-17> ffmpeg: Fixes issue1180.
[23:54:05] <Kovensky> saste: does pixdesc.h really need those inline functions? can't they be moved to some .c file in lavutil?
[23:55:53] * Kovensky rages @ cygwin
[23:55:55] <Kovensky> y so slow q_q
[23:56:08] <Kovensky> takes like 10 minutes to run ffmpeg's configure script