[FFmpeg-devel-irc] IRC log for 2011-02-09

[irc at mansr.com]

[00:00:44] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * rf7f8120fb9 ffmpeg/libavcodec/libx264.c:
[00:00:44] <CIA-38> ffmpeg: Fix broken vbv_buffer_init handling in libx264.c
[00:00:44] <CIA-38> ffmpeg: Due to being pants-on-head retarded, libavcodec defaults this to zero, which
[00:00:44] <CIA-38> ffmpeg: results in broken output. This didn't affect ffmpeg.c, which sets it itself,
[00:00:44] <CIA-38> ffmpeg: but caused problems for other calling apps using VBV.
[00:00:54] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * r62457f9052 ffmpeg/libavcodec/vp8.c:
[00:00:54] <CIA-38> ffmpeg: VP8: idct_mb optimizations
[00:00:54] <CIA-38> ffmpeg: Currently uses AV_RL32 instead of AV_RL32A, as the latter doesn't exist yet.
[00:00:57] <CIA-38> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * rc7ac200d15 ffmpeg/ (27 files in 2 dirs):
[00:00:57] <CIA-38> ffmpeg: Update qmin/qmax values for libx264 presets
[00:00:57] <CIA-38> ffmpeg: Also allow qmin/qmax to go up to 69 (the current max value for libx264). This
[00:00:57] <CIA-38> ffmpeg: will have to increase when we add 9/10-bit support.
[00:17:04] <drv> BBB: yes, i'm working on a windows fate box on and off, possibly this weekend will have time to get it fully up and running
[00:23:28] <Flameeyes> nice nice nice.. ffmpeg is totally LFS-safe
[00:30:28] <Orphis> Any idea on how I could override the TARGET_PATH variable at the configure level ? It doesn't seem to be used anywhere but in fate
[00:31:00] <mru> --target-path
[00:31:56] <Orphis> Fair enough
[00:32:35] <Orphis> Why did I only grep target_path ?! Humpf ^^
[00:33:11] <Orphis> Why will be running great with that I guess
[00:54:28] <Orphis> Yeah, I've got the right configure now that's able to run Fate well !
[01:11:07] <mmu> didn't have to change it for Haiku :p
[01:19:30] <Orphis> Haiku doesn't have mixed path like cygwin / windows :P
[01:19:46] <mmu> no it's a sane OS :p
[01:41:01] <BBB> drv: ok, the bug is fixed
[01:42:45] <drv> cool, will test soon
[01:46:12] <Orphis> cat workdir/compile.log : install: missing file or operand
[01:46:32] <Orphis> Why why why is cygwin making everything so difficult ?!
[01:57:59] <BBB> drv, Orphis: PS thanks for trying to set up windows fate boxes, very much appreciated
[01:58:45] <Orphis> drv: Oh, you're trying to set up a windows fate box too ?
[02:01:44] <drv> if you are putting one together, that is even better (less work for me ;)
[02:01:58] <drv> i have a win64 VM, but it is not fully set up yet
[02:02:30] <Orphis> Did you manage to configure and run fate tests manually yet ?
[02:02:57] <drv> not yet, i have been cross-compiling with a linux machine, and cygwin ssh on the test machine is not cooperating
[02:03:12] <Orphis> What's the problem ,
[02:03:41] <Orphis> cygwin ssh was easy enough to configure
[02:03:56] <Orphis> Run ssh-host-config
[02:04:22] <drv> it works fine with password, but key-based auth seems to have permission problems
[02:04:27] <Orphis> Then: net user username password /add /yes
[02:04:35] <drv> (i can't access network shares)
[02:04:54] <Orphis> And mkpasswd -l -u username >> /etc/passwd
[02:05:03] <Orphis> Wouldn't scp work ?
[02:05:44] <Orphis> And key based auth works fine for me and BBB
[02:07:43] <Orphis> And I've scp-ed the public keys too, so you should try that
[02:55:50] <Orphis> Yay, I think the fate.sh script is now running fine !
[03:40:40] <Orphis> I'll setup the crontab tomorrow for my fate
[06:08:28] <elenril> what a delightfully dull night
[06:08:37] <elenril> no drama, no reviews, no -mt
[06:13:36] <astrange> i feel ill. should go away tomorrow
[06:14:15] <siretart> astrange: get well soon!
[06:46:50] <elenril> _av500_: ping
[06:49:22] <benoit-> moin
[06:53:11] <_av500_> elenril: pong
[06:53:53] <thresh> moroning
[06:54:46] <elenril> _av500_: you said you'd add chapter muxing for asf
[06:54:59] <_av500_> elenril: yes, its on hold :(
[06:55:07] <elenril> and iirc then you ran into some problems with negative timestamps
[06:55:11] <_av500_> yes
[06:55:14] <elenril> i wonder what problems
[06:55:29] <_av500_> ill tell you later, need to feed kids
[06:55:30] <elenril> aren't all timestamps in asf unsigned?
[06:55:36] <elenril> ok
[07:49:20] <cartman> moin
[07:49:55] <spaam> God morgon
[07:59:03] <elenril> wow, there's a rfc draft for asf
[08:03:55] <KotH> salut
[08:04:44] <elenril> おはよう
[08:05:29] <spaam> elenril: going to read it tonight?
[08:05:59] <elenril> spaam: nah, it's the same as the m$ specs
[08:06:11] <spaam> elenril: super duper good?
[08:06:12] <elenril> just older version
[08:06:28] <elenril> kinda funny actually
[08:08:56] <elenril> and makes their "no open source implementations" licence even less valid if that's even possible
[08:10:04] <spaam> hehe
[08:17:05] <siretart> hmm. seems that I slowly start to win over git send-email...
[08:17:40] <kshishkov> good
[08:19:40] <spaam> kshishkov: how does it go with bink-b? :)
[08:20:02] <kshishkov> spaam: nagging Peter about it time from time
[08:23:42] <pross-au> its working
[08:24:04] <spaam> \o/
[08:24:12] <pross-au> will spend some time on the idct tonight
[08:24:16] <spaam> pross-au: did you get it bitexact?
[08:24:48] <pross-au> yes its bit exact, but only on x86, and only using __asm()
[08:26:46] <pross-au> , and float.
[08:31:12] <kshishkov> I don't think that is extremely important
[09:07:33] <mmu> http://fate.ffmpeg.org/x86_32-haiku-gcc-4.4.4 \o/
[09:11:46] <av500> mmu: :)
[09:11:56] <mmu> ;)
[09:12:01] <saintdev> and it's even green o.O
[09:12:07] <spaam> wooow
[09:12:43] <spaam> mmu: is there a 64bit version of haiku?
[09:16:26] <lu_zero> mmu: great!
[09:18:27] <mmu> spaam: no, the port is just started
[09:20:05] <elenril> do we have a function that can do 'find 137th video stream'?
[09:27:10] <av500> not in avi :)
[09:27:54] <pross-au> thats a lot of v.streams
[09:41:01] <j-b> so, vbv-delay, in ms, 90kHz, 27Mhz or in double?
[09:44:21] <Tjoppen> why not simply in the codec's time base?
[09:44:33] <Tjoppen> whatever it might be
[09:53:18] <lu_zero> AVRational?
[09:53:30] <lu_zero> AVRational_long?
[09:54:14] <Tjoppen> AVRational64 might be useful
[09:54:50] <lu_zero> let's discuss it
[09:54:59] <pross-au> lu_zero: make it a template AVRational(t)
[09:55:05] <Tjoppen> isn't there already a fractional struct though?
[09:55:12] <lu_zero> pross-au: I was thinking about that
[09:55:15] <Tjoppen> that is, a + b/c
[09:55:23] <Tjoppen> for pts stuff
[09:55:31] <pross-au> (i was joking)
[09:55:42] <lu_zero> pross-au: you can do templating in C
[09:56:00] <pross-au> i know that :)
[09:56:10] <lu_zero> even if sometimes things gets a bit extreme and convoluted (swscale HI!)
[09:56:20] * elenril kicks ffmpeg.c
[09:56:25] <elenril> why are mappings so obscure
[09:56:46] <lu_zero> elenril: please document them better if you could
[09:57:04] * Flameeyes stares at lu_zero
[09:57:08] <elenril> i would if i actually understood how it works ;)
[09:57:26] <lu_zero> Flameeyes: oui?
[09:57:35] <Flameeyes> lu_zero: see skype
[09:57:48] <lu_zero> uhm
[09:59:02] <iive> Tjoppen: I think it was removed few years ago.
[10:03:27] <elenril> can wmp select between video tracks?
[10:10:58] <av500> doubt it
[10:11:05] <av500> do you have a sample?
[10:11:20] <elenril> there's one on samples
[10:12:02] <elenril> wmp in xp can read it, but i don't see any option to switch streams
[10:12:11] <av500> i dont think there is one
[10:12:56] <elenril> what an awesome piece of software
[10:13:19] <elenril> it also rejects multivideo ASFs created by asfenc
[10:13:19] <av500> it was made for awesome users
[10:13:33] <elenril> but maybe i'm just failing ffmpeg commandline syntax
[10:13:34] <av500> elenril: wmp rejects a lot of stuff muxed by asfenc
[10:13:42] <av500> even std 1v 1a tracks
[10:14:05] <elenril> samples! bugreports!
[10:14:07] <av500> and the asf verifier tool barfs on every asf muxed by asfenc
[10:14:13] <av500> elenril: yes, will do
[10:14:57] <elenril> oh crap
[10:15:08] * elenril just accidentally whole file
[10:15:14] * elenril <3 reflog
[10:16:26] <elenril> and the asf verifier tool barfs on every asf muxed by asfenc << i thought i fixed that
[10:16:42] <elenril> and it wasn't on every file, just wmv videos
[10:16:54] <elenril> unless you mean some other asf verifier
[10:18:06] <elenril> ok, my asf branch is getting kinda long
[10:18:28] <elenril> i'd appreciate it if somebody commented on more patches than just the first one ;)
[10:26:45] * av500 goes to find some whitespace nit
[10:30:00] <j-b> kshishkov: waow, I didn't realize you had so much code!
[10:30:45] <av500> j-b: tables
[10:30:53] <av500> kshishkov: waow, I didn't realize you had so much tables
[10:31:19] <av500> j-b: still trolling the swamp?
[10:31:51] <j-b> yes, the fights again MPEG-Dash people was fun
[10:31:54] <j-b> yesterday night
[10:32:17] <av500> dash?
[10:32:32] <j-b> dash
[10:33:00] <av500> ah, dash
[10:33:48] <j-b> adaptive streaming
[10:34:04] <av500> yes
[10:34:07] * Kovensky never realized people cared about asf
[10:34:32] <iive> Kovensky: microsoft still uses .wmv
[10:34:38] <Kovensky> most of the time when I see video in asf is because the uploader is going "look ma! no codecs!"
[10:34:43] <KotH> kshishkov: i've still quite a few asf files
[10:35:21] <av500> lot of porn in asf
[10:35:36] <av500> KotH: didnt mean you :)
[10:35:46] <Kovensky> iive: well, adobe still supports sorenson spark (and you can still find videos encoded in it) but do people care about it? :)
[10:35:55] <KotH> av500: nah.. people know that i have lots of anime in asf :)
[10:35:57] <elenril> Kovensky: hey, asf is still bettern than ogg
[10:36:02] <av500> for sure
[10:36:07] <av500> asf is in fact quite nice
[10:36:10] <elenril> NO
[10:36:14] <Kovensky> the real challenge is finding what *isn't* better than ogg
[10:36:27] <av500> elenril: compared to mov, you can stream it :)
[10:36:38] <elenril> av500: ok, compared to mov asf seems rather nice
[10:36:46] <iive> Kovensky: support != use
[10:36:49] <elenril> at least its specs are of manageable size
[10:36:56] <av500> and adding a codec can be done somewhat generically
[10:36:56] <j-b> and compared to nut?
[10:37:11] <av500> unlike mov and mkv where each codec is "mapped" somehow
[10:37:39] * elenril wonders why does reading index break when it's called from read_header()
[10:38:10] <av500> because the index is at the end?
[10:38:56] <elenril> so?
[10:39:06] <elenril> there's no diffrence, you seek anyway
[10:39:31] <av500> Machete don't seek
[10:39:33] <elenril> now the index is read when you seek for the first time
[10:39:57] <Kovensky> 07:37.12 av500: unlike mov and mkv where each codec is "mapped" somehow <-- making maps for matroska seems trivial though
[10:40:13] <av500> Kovensky: unless it is RealAudio
[10:40:26] <Kovensky> matroska has some overcomplicated mappings for some codecs
[10:40:39] <av500> Kovensky: or unless it is WMV compat mode where PTS becomes DTS
[10:40:48] <Kovensky> lol
[10:40:56] <Kovensky> there's also V_MS/VFW/FOURCC!
[10:41:07] <av500> yes, thats what I meant
[10:41:19] * Kovensky has seen H.264 muxed in VFW mode ;_;
[10:41:30] <av500> maybe it came from an asf file :)
[10:41:40] <av500> maybe one can mux asf into mkv
[10:42:09] <Kovensky> not really, mkvmerge *still* muxes ASP as VFW unless you use --engage secret_undocumented_flag_here
[10:42:13] <av500> elenril: what about http streaming, do you really want to delay playing the stream be reading the index from read_header?
[10:42:39] <Kovensky> think of the poor dialup users!
[10:42:47] * Kovensky looks at dalias over at #mplayerdev
[10:42:47] <av500> and their children
[10:43:08] <av500> in fact, they should have many children, all that idle time...
[10:43:17] <Kovensky> lol
[10:43:36] <elenril> av500: it's only done when !url_is_streamed
[10:43:37] * Kovensky remembers when he used dialup back on 2000~2004
[10:43:40] <av500> see countries with no dialup at all...
[10:43:42] <Kovensky> had to wait until sundays!
[10:43:45] <av500> elenril: ok then
[10:47:53] <av500> j-b: so, what came out of this?
[10:51:03] <j-b> av500: dash-webm!
[10:52:21] <av500> daweb
[11:06:50] <pross-au> Even though i call fesetround(FE_TONEAREST) before hand, gcc prefixes all my float operations with fstcw 0x1200 (trucate to zero rounding method)
[11:07:48] <kshishkov> BTW how much quality degrades with non-bitexact IDCT?
[11:08:04] <pross-au> not much
[11:08:22] <pross-au> i need to calculate it
[11:09:36] <pross-au> is there a way to invoke ffmpeg to calculate, say, the maximum luma difference of two frames ?
[11:09:56] <kshishkov> not directly IIRC
[11:10:11] <pross-au> idct isn't used that frequently, in my samples
[11:10:19] <pross-au> so drift isnt a huge issue
[11:11:44] <merbzt> ok, where is that code one can set so the container pts/dts can be trusted ?
[11:12:49] <merbzt> right now when ffmpeg knows the stream codec is h264 the pts/dts disappear, if it doesn't they are correct
[11:13:50] <pross-au> merbzt: libavformat/utils.c tb_unreliable() ?
[11:17:03] * cartman abuses jni
[11:18:01] <av500> cartman: best is to use jni to call c code that then calls java code
[11:18:32] <av500> it's called garbage correction
[11:18:37] <cartman> lol :)
[11:22:00] <elenril> av500: you promised me a review! =p
[11:22:01] <Dark_Shikari> garbage collection is very simple
[11:22:03] <Dark_Shikari> rm *.java
[11:22:07] <Dark_Shikari> garbage collected
[11:25:09] <kshishkov> Dark_Shikari: proper Java garbage collection should remove JVM as well
[11:33:05] <av500> elenril: there, I did :)
[11:33:10] <av500> the rest is LGTM :)=
[11:36:56] <elenril> haha
[11:37:01] <elenril> somebody go apply it then =p
[11:48:42] <Kovensky> 08:22.08 Dark_Shikari: garbage collected <-- find / \( -iname '*.java' -o -iname '*.class' -o -iname '*.jar' \) -delete
[11:52:51] <kshishkov> Kovensky: find / -name Oracle -exec nuke {} \;
[12:01:05] <spaam> kshishkov: maybe you should commit avseq.. then you can be the number one on git blame! :D
[12:03:28] <pross-au> waits patiently for the .exe demuxer/decoder
[12:05:16] <cartman> kshishkov: finally bink-b
[12:05:20] <cartman> pross-au++
[12:05:24] <spaam> cant be true
[12:05:31] <cartman> we are saved
[12:05:34] <spaam> omg there it is!
[12:05:42] <spaam> pross-au: gj :D
[12:05:47] <cartman> LGTM
[12:05:48] <kshishkov> pross-au: I'll review it
[12:06:47] <pross-au> kshishkov: note that it uses your idct, there are some artifacts due to DCTELEM clipping
[12:07:23] * mru thinks we should replace DCTELEM with int16_t
[12:07:30] <mru> all the asm depends on it being that anyway
[12:08:31] <spaam> mru: patch welcome ;)
[12:09:01] <pross-au> for the bink variants we need more precision (well thats the hypothosis)
[12:09:21] <mru> the it can't use the same type
[12:09:39] <Dark_Shikari> mru: irock's 10-bit h264 decoding will require 32-bit dctelem
[12:10:06] <mru> and that will require all new asm
[12:10:09] <Dark_Shikari> Yes.
[12:10:16] <Dark_Shikari> asm is already written.
[12:10:17] <mru> and the old asm will still be used for 8-bit
[12:10:20] <Dark_Shikari> Yes, of course.
[12:10:28] <mru> so the point stands
[12:10:38] <mru> we can never change DCTELEM as it is used now
[12:10:44] <mru> so the indirection is pointless
[12:11:03] <Dark_Shikari> Eh?
[12:11:19] <mru> there's a typedef int16_t DCTELEM; somewhere
[12:11:24] <Dark_Shikari> Sure, in the asm, it'll obviously be int16_t or similar.
[12:11:25] <mru> change that and everything breaks
[12:11:44] <Dark_Shikari> x264 has dctcoef and pixel types instead of int16_t and uint8_t
[12:11:55] <Dark_Shikari> of course that's because we actually intended it to work that way
[12:12:09] <Dark_Shikari> I don't know why DCTELEM has to be all caps though.
[12:12:13] <Dark_Shikari> bugs me, for some reason.
[12:12:13] <mru> for templating C versions it works of course
[12:12:30] <av500> typedef short DCTELEM;
[12:12:35] * Dark_Shikari punts av
[12:12:36] <mru> even worse
[12:12:50] <mru> all-caps typedefs remind me of windows
[12:12:53] <mru> ULONG
[12:12:57] <pross-au> AVDCTELEM(16)
[12:13:18] <cartman> kierank: x262?!
[12:13:22] <av500> Dark_Shikari: I just stated facts
[12:13:48] <kierank> cartman: ?
[12:14:02] <cartman> kierank: seen on github under your nick
[12:14:08] <kierank> ya
[12:14:19] <spaam> cartman: do you stalk kierank ?!
[12:14:25] <cartman> spaam: of course
[12:14:28] <kierank> spaam: another one
[12:14:42] <cartman> kierank: just wondering wtf it is :)
[12:14:46] <spaam> kierank: how many stalkers do you have? only cartman ? :)
[12:15:36] <kierank> spaam: you
[12:15:45] <spaam> kierank: me? pfff
[12:15:48] <cartman> lol
[12:16:13] <spaam> stupid bittorrent encrypted things ;SSS
[12:16:30] <cartman> stupid slow VPN
[12:16:37] <spaam> why cant they all use the same stuff so it will be easier for me ? :P
[12:21:34] <DonDiego> pross-au: why all the casting in binkb_read_bundle()?
[12:21:55] <spaam> DonDiego: 2slow
[12:22:00] <kshishkov> DonDiego: buffer is uint8_t but it can be interpreted as int8_t and int16_t too
[12:22:15] <DonDiego> couldn't you avoid it if you declared *dst as uint8_t?
[12:23:05] <kshishkov> ?
[12:23:32] <wbs> kshishkov: woulnd't that kind of pointer casting break on big-endian?
[12:23:59] <kshishkov> wbs: it shouldn't - it's written natively
[12:24:16] <wbs> kshishkov: ah, sneaky bastards
[12:26:22] <kshishkov> well, the proper solution would be to rewrite it in C++ creating template Bundle class with instances operating on uint8_t, int8_t and int16_t
[12:26:27] <kshishkov> or maybe not
[12:31:55] <merbzt> av500: what is more likely, you rigging the raffle or me winning the panda by pure luck ?
[12:33:02] <av500> merbzt: I did not rig it
[12:33:06] <kshishkov> av500: you being lucky. Otherwise I'd get it (even if I didn't put an application there).
[12:33:15] <kshishkov> err, to Ben
[12:33:28] <av500> all i did was to tell omar to pick a business card because on day 2 it was all business cards
[12:33:51] <mru> and you knew merbzt had left a business card
[12:33:55] <mru> so you rigged it
[12:34:03] <merbzt> av500: I'm just asking a hypothetical question
[12:34:16] <kshishkov> BTW, have they fixed the memory slowness problem there?
[12:34:17] <merbzt> I did not ask if you rigged it or not
[12:34:19] <av500> i "rigged" the fact that there was one winner for each day
[12:34:36] <merbzt> ;)
[12:34:44] <mru> kshishkov: next silicon rev should help to some extent
[12:34:55] <mru> kshishkov: and the omap4440 should be even better
[12:35:13] <av500> mru: by the amount of work they put into a speed bin, yes :)
[12:35:41] <mru> it has a newer A9 core
[12:35:52] <spaam> Anyone know about what bitrates youtube uses for 360p, 480p, 720p  +
[12:35:53] <spaam> ?
[12:35:58] <mru> and reworked interconntects between the a9 and sdrc
[12:36:09] <kshishkov> mru: and OMAP5 should be even better but ElefantBoard is to be designed yet :(
[12:36:46] <cartman> uhm OMAP4 widespread yet?
[12:37:02] <av500> cartman: all over my office, so yes
[12:37:14] <cartman> av500: nice point of view, send over one
[12:37:33] <cartman> in exchange I'll send köfte
[12:37:40] <av500> not sure I am allowed to export to you
[12:37:42] <kshishkov> cartman: only after you get Archos tablet with discount from him
[12:37:50] <cartman> kshishkov: bah
[12:37:59] <cartman> av500: You could if I am in *.de?
[12:38:17] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * re4e234fad7 ffmpeg/libavformat/ (asf.h asfdec.c):
[12:38:17] <CIA-38> ffmpeg: asf: make ff_guidcmp inline and move it to asf.h
[12:38:17] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:38:26] <kshishkov> cartman: I'm the first in queue
[12:38:27] <av500> cartman: go order a pandaboard like everybody else
[12:38:37] <cartman> av500: too expensive
[12:38:41] <cartman> kshishkov: heheh :)
[12:39:02] <kshishkov> av500: I was going to steal it at FOSDEM like everybody else
[12:39:19] <av500> kshishkov: you succeeded not
[12:39:29] <kshishkov> av500: iKnow
[12:39:46] <cartman> av500: did you load Android on them?
[12:42:44] <av500> cartman: no time to port it yet
[12:43:02] <av500> i put them on flickr like the rest
[12:43:45] <cartman> av500: oh Android doesn't work on OMAP4 yet? Or some drivers lacking?
[12:43:57] <av500> cartman: it was a joke
[12:44:09] <cartman> bah
[12:46:13] <cartman> Don't joke when I'm working :P
[12:46:32] <av500> so I can joke always
[12:46:54] <cartman> mostly
[13:13:55] <Orphis_> Great, cron on cygwin is finally working, I guess I can now add some lines in my crontab to make the reports for win64
[13:14:42] <mru> Orphis_: send me your ssh public key when you're ready to start submitting
[13:17:35] <Orphis_> I'll send it by mail in a few minutes
[13:43:34] <DonDiego> btw, trivia of note: gabu is also the only person to ever have been banned from xine-devel...
[13:46:04] <kshishkov> so he had interest beside MPlayer...
[13:46:21] <DonDiego> the funny thing was that these were the words günter bartsch (xine project founder) used to greet gabu at linuxtag back in the days (2004?)
[13:46:39] <DonDiego> he had interest in flaming, not necessarily restricted to mplayer
[13:48:01] <DonDiego> funny was also the reaction - goofy (günter) is about 200m tall while gabu's eye level barely reached his navel :-)
[13:48:30] <KotH> DonDiego: lt 2003
[13:48:31] <spaam> s/200m/200cm/ ?
[13:49:25] <KotH> spaam: no, really 200m
[13:49:34] <KotH> günther is a giant!
[13:49:42] <spaam> KotH: Nice!
[13:50:24] <DonDiego> he is really tall, dunno how much, but surely 2,xx meters
[13:50:40] * KotH would have said 1.9 or so...
[13:50:56] <DonDiego> well, gabu was standing next to him ;)
[13:51:02] <KotH> gabu was rather small :)
[13:51:28] <DonDiego> anyway, his nickname is fitting, he is tall and thin and … goofy - not meant in a negative way...
[13:52:28] <kshishkov> and a dog?
[14:02:18] <pJok> kshishkov, i see a bink-b patch
[14:02:32] <kshishkov> pJok: yes, so?
[14:03:28] <pJok> kshishkov, finally?
[14:03:29] <pJok> :)
[14:03:46] <DonDiego> offtopic: does anybody have some experience with git-svn and local commits that disappear after you push some but not all of them to the svn server?
[14:03:55] <av500> DonDiego: as i read it, he is also baned from wiki.hu for life: http://hu.wikipedia.org/wiki/Wikipédia:Szerkesztők_szankcionálása/Gabucino
[14:03:59] <DonDiego> *highly* annoying...
[14:04:44] <kshishkov> av500: you can read it?
[14:04:53] <av500> google can
[14:06:10] <kshishkov> DonDiego: can you hint him to troll VLC so he can earn another ban for his collection?
[14:07:26] <DonDiego> lol
[14:07:30] <pJok> kshishkov, aren't they french?
[14:07:34] <bilboed-tp> DonDiego, keep a separate branch that git-svn won't touch
[14:07:42] <kshishkov> pJok: oui, messeur
[14:07:47] <bilboed-tp> DonDiego, and do all your work there
[14:08:00] <pJok> kshishkov, that should give him a ban much faster than anywhere else then
[14:24:14] <av500> http://www.slideshare.net/ranjithsiji/ffmpeg-tools
[14:24:54] <cartman> 502 Bad Gateway
[14:24:56] <cartman> nice slides
[14:25:10] <kshishkov> av500: the name brings fear into my soul
[14:25:20] <DonDiego> av500: where did you find out about that ban?
[14:25:45] <av500> DonDiego: I must not reveal my methods, but they involve a tiny startup in mountain view
[14:26:01] <av500> they develop self driving cars
[14:26:19] <kshishkov> and sponsor BB development too
[14:26:33] <kierank> av500: that pic is not michaelni
[14:26:38] <cartman> Everything is tiny compared to av500
[14:26:55] <av500> kierank: i did not make the slides, but yes
[14:27:11] <av500> its a dr michaelni from berlin
[14:27:39] <av500> the copy paste indian did not google hard enough
[14:27:52] <kshishkov> av500: do you have real MN photo?
[14:30:35] <av500> the fabrice pic is also wrong btw
[14:30:58] <av500> but i guess to indian we all look the same
[14:31:02] <av500> jai: no offence
[14:33:10] <kshishkov> av500: you and me - definitely
[14:33:24] * cartman has no picture of kshishkov either
[14:33:32] <av500> cartman: in my flickr
[14:33:38] <cartman> aha
[14:33:44] <av500> cartman: the one you "friended"
[14:33:51] <av500> but I will not post on your wall
[14:33:51] <cartman> lol
[14:33:58] <cartman> like me, poke me
[14:34:57] <av500>  /unfriend
[14:34:59] <av500> oops
[14:35:22] <cartman> :P
[14:35:33] <kshishkov> av500: http://www.flickr.com/photos/av500/5304197100/ <- probably the nicest piece of hardware you've ever photographed
[14:35:42] <cartman> soon we might be neighbours
[14:35:48] <cartman> who knows :P
[14:35:53] * av500 digs deeper
[14:36:00] <av500> kshishkov: you want it?
[14:36:08] <av500> its going on ebay soon
[14:36:19] <av500> and it has the upgrade, so its a palm V in fact
[14:36:37] * kshishkov is very tempted but must resist it
[14:36:42] <kierank> I had a palm vx
[14:36:49] <kierank> but it got smashed on a plane
[14:36:53] <av500> kshishkov: I have a V too and a tungsten
[14:37:07] <av500> kierank: how did the plane smash the palm?
[14:37:09] <cartman> av500: somewhere here, http://www.flickr.com/photos/av500/4767125825/ ?
[14:37:58] <av500> nope
[14:38:02] <kierank> av500: dunno, put it in a bag in the overhead locker i guess and the flight attendant forced the locker shut
[14:38:09] <av500> ah
[14:38:58] <cartman> av500: what size is he?
[14:39:09] <av500> 3xl
[14:39:33] <kshishkov> av500: and you?
[14:39:46] <kierank> who is the guy second from the right
[14:39:53] <av500> mchinen
[14:40:01] <av500> ah no
[14:40:04] <av500> wrong pic
[14:40:17] <kshishkov> kierank: sitting/standing?
[14:40:18] <av500> standing on the right is stefan
[14:40:27] <kierank> standing
[14:40:31] <kshishkov> aka Chinese Stefan
[14:40:32] <kierank> who's below
[14:40:35] <av500> janne, mru, diego, stefan, $random_xbmc
[14:41:20] <cartman> av500: you should learn to tag
[14:41:32] <av500> cartman: :effort:
[14:41:33] <spaam> use facebook for it!
[14:41:48] <av500> i barely mange to upload unless its one click from the phone
[14:41:49] <kshishkov> av500: but tagging is a popular children' game
[14:42:06] <cartman> teach your kids to do it
[14:42:13] <av500> and google should know who these faces belong to anyway....
[14:42:15] <thresh> yeah, flickr always wants my yahoo account, and I remember no such thing
[14:42:22] <DonDiego> doh, it seems that gabucino has also become an jew hater and holocaust denier ...
[14:42:24] <DonDiego> http://www.subsim.com/radioroom/showthread.php?t=159374&page=2
[14:42:28] <cartman> thresh: they now work with Google accounts
[14:42:55] <DonDiego> to even think that there were people complaining about his ban...
[14:43:01] * DonDiego shakes his head
[14:43:50] <thresh> is denying holocaust bad?
[14:43:56] <cartman> "There is no need for you to get personal, don't do that."
[14:43:57] <cartman> :D
[14:44:12] <kshishkov> DonDiego: rule #something - there are always few people on Internet thinking the same as you
[14:44:31] <kshishkov> thresh: well, it's a crime in some places
[14:44:44] <cartman> in .de most notably
[14:44:47] <twnqx> and there's most often the vast majority of "don't care"
[14:45:05] <cartman> now I know how what to blame av500 on
[14:45:30] <DonDiego> thresh: trying to troll or what?
[14:45:51] <thresh> DonDiego: no.
[14:46:09] <av500> godwin now!
[14:46:17] <av500> kshishkov: trains please
[14:47:04] <DonDiego> yes, it is bad and a clear sign that the person that utters such shit is not one i want to have to deal with in any way
[14:47:37] * thresh reads wiki on that
[14:49:02] <kshishkov> av500: Belgium is a kingdom and Belgian trains suck royally
[14:49:18] <cartman> Good thing is you can deny God's existence
[14:50:26] <bilboed-tp> kshishkov, whereas in Monaco they only suck in principle ?
[14:50:32] <kshishkov> av500: they should replace benches in regional trains into wooden ones and then they'll be even worse than Ukrainian
[14:50:53] <DonDiego> thresh: you dunno what the holocaust is?
[14:50:59] <cartman> kshishkov's never ending rambling :)
[14:51:02] <thresh> DonDiego: Of course I do know what that is
[14:51:14] <thresh> DonDiego: I don't know why people would want to deny it though
[14:51:18] <kshishkov> bilboed-tp: I'm not sure they have them at all
[14:51:26] <thresh> and that's what I'm following up on now
[14:51:40] <cartman> why would you care to deny it
[14:52:48] <kshishkov> cartman: as always - to make somebody look better than he really is
[14:56:23] <kshishkov> like some people telling lies about trains coming on time
[14:56:34] <cartman> lol
[14:57:52] <cartman> kshishkov: I suggest the Turkish way: http://4.bp.blogspot.com/_zUw28h3Phqk/TGMBTvBcJEI/AAAAAAAAAIY/ziPbdmGVFcg/s1600/metrob%C3%BCs+it.jpg
[14:58:10] <av500> cartman: u could have gotten out and helped
[14:58:18] <cartman> av500: no way
[14:58:23] <kshishkov> cartman: what's special about it?
[14:58:43] <av500> kshishkov: nobody with a whip driving the people
[14:58:53] <av500> so it will be late
[14:59:11] <cartman> we could push trains too
[14:59:15] <cartman> human > horse power
[15:03:40] * cartman does a late FATE
[15:04:03] * kshishkov is proud of that contribution to FFmpeg
[15:04:51] * cartman is abusing ffmpeg as compiler regression tool and it works fine
[15:05:16] <kshishkov> cartman: you can't - FFmpeg is compiler regression tool
[15:05:33] <cartman> I never abuse it as an encoder then
[15:06:08] <kshishkov> of course
[15:06:27] <kshishkov> except that you can accidentally abuse it as AAC encoder
[15:06:33] <cartman> heheh
[15:06:49] <cartman> av500: wondering, do you guys have "lahmacun" over in *.de?
[15:06:58] <av500> sure
[15:07:05] <av500> at least they call it that
[15:07:10] <cartman> good :>
[15:08:05] <cartman> nice, my compiler warnings are halved now
[15:08:44] <av500> used a smaller font?
[15:09:03] <cartman> did a > /dev/null
[15:09:03] <spaam> höhhö
[15:18:02] * Compn wonders where all the flames went
[15:18:42] <ubitux> someone made a clear cease-fire recently
[15:19:19] <ubitux> so he may have calm down things a bit, which is quiet pleasant :)
[15:19:42] <cartman> http://notalwaysright.com/byte-off-more-than-you-can-chew/2372
[15:20:42] <elenril> Compn: you miss the flames?
[15:21:19] <cartman> elenril: its cold in here
[15:36:36] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * rc2bd7578af ffmpeg/doc/APIchanges: Add missing git revision hask.
[15:36:38] <CIA-38> ffmpeg: Alexander Strange <astrange at ithinksw.com> master * r37b00b47cb ffmpeg/ (11 files in 5 dirs):
[15:36:38] <CIA-38> ffmpeg: Frame-based multithreading framework using pthreads
[15:36:38] <CIA-38> ffmpeg: See doc/multithreading.txt for details on use in codecs.
[15:36:38] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[15:36:44] <BBB> astrange: \o/
[15:36:46] <kshishkov> hask?
[15:36:47] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * rf2146944fc ffmpeg/doc/APIchanges: Add missing git rev hash.
[15:36:48] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r8e8cc52be3 ffmpeg/doc/APIchanges: Add missing git rev hash.
[15:36:51] <CIA-38> ffmpeg: Alexander Strange <astrange at ithinksw.com> master * rc0b102ca03 ffmpeg/ (8 files in 3 dirs): (log message trimmed)
[15:36:51] <CIA-38> ffmpeg: Deprecate avcodec_thread_init()
[15:36:51] <CIA-38> ffmpeg: As a side effect of the last commit, avcodec_open() now calls it automatically,
[15:36:51] <CIA-38> ffmpeg: so there is no longer any need for clients to call it.
[15:36:51] <CIA-38> ffmpeg: Instead they should set AVCodecContext.thread_count.
[15:36:51] <CIA-38> ffmpeg: avcodec_thread_free() is deprecated, and will be removed from avcodec.h at the
[15:36:52] <CIA-38> ffmpeg: next MAJOR libavcodec bump.
[15:36:53] <CIA-38> ffmpeg: Alexander Strange <astrange at ithinksw.com> master * rd23845f311 ffmpeg/libavcodec/vp3.c: (log message trimmed)
[15:36:53] <CIA-38> ffmpeg: vp3: Frame-based multithreading support
[15:36:53] <CIA-38> ffmpeg: Decode times for big_buck_bunny_720p_stereo:
[15:36:54] <CIA-38> ffmpeg: 1 thread:
[15:36:54] <CIA-38> ffmpeg: real 1m14.227s
[15:36:55] <CIA-38> ffmpeg: user 1m13.104s
[15:36:55] <CIA-38> ffmpeg: sys 0m1.108s
[15:37:39] <Kovensky> 37b00b47cb <-- \o/
[15:38:42] <elenril> \\o//
[15:38:54] <av500> \\\ooo///
[15:38:57] <Kovensky> \\\\\o/////
[15:39:05] * Kovensky should resume ika musume
[15:39:06] <BBB> omg an octopus
[15:39:17] <kshishkov> \\\\\\\\\\\(;,;)///////////
[15:39:36] <elenril> BBB: wtf is with all the Add missing git revision hash
[15:39:41] <Kovensky> BBB: well, the reference is to a squid, actually ;)
[15:40:05] <av500> finally I can watch all my theora content 40% faster
[15:40:09] <cartman> ha
[15:40:11] <cartman> yay
[15:40:30] <DonDiego> omg
[15:40:36] <DonDiego> i cannot believe it...
[15:40:40] <cartman> now add threading support to h264
[15:40:49] <elenril> DonDiego: h264 is not in yet
[15:40:59] <av500> who needs h264
[15:41:11] <av500> when we have free codecs
[15:41:12] <cartman> I need H265 please
[15:41:20] <av500> cartman: here: "+1"
[15:41:44] <kierank> av500: http://www.youtube.com/watch?v=PZF5wpntXsk
[15:41:50] * kshishkov gives cartman VP9 instead
[15:42:05] <Kovensky> http://4.bp.blogspot.com/_7ktzqvLUg1U/TN1jith-XNI/AAAAAAAABvc/RKVFL6MW9zk/s1600/ika_musume.jpg <-- this
[15:42:32] <av500> Kovensky: where is the octopus?
[15:42:49] <Kovensky> that is japan's version of a squid
[15:43:09] <siretart> yay @-mt! :-)
[15:43:17] <JEEB> woah
[15:43:20] <JEEB> -mt is in?
[15:43:25] <av500> oui
[15:43:26] <JEEB> WRRYYYYYYY
[15:43:29] <bilboed-tp> w00t
[15:43:33] * JEEB goes rebuild some stuff
[15:43:35] <siretart> JEEB: check backlog 10 minutes ago
[15:43:39] <JEEB> yeah
[15:43:54] <JEEB> I see it :) Just was waiting for "Oh, it's not the full thing" etc.
[15:43:56] * cartman FATEs
[15:43:57] <kshishkov> Kovensky: "ika" is rather a cuttlefish
[15:45:07] <JEEB> oh well, I guess I'll wait some more for H.264
[15:45:20] * Kovensky wonders what's a cuttlefish
[15:45:47] <Kovensky> though I guess I shouldn't look too deep into japanese fish names since that's one thing they certainly were thorough with kanji
[15:46:41] <elenril> lol
[15:47:13] <JEEB> ika as the overall word covers both cuttlefish and lots of squids
[15:47:21] <JEEB> it isn't really set in stone
[15:47:22] <JEEB> http://ja.wikipedia.org/wiki/%E3%82%A4%E3%82%AB
[15:48:07] <JEEB> see the "分類" part
[15:49:51] <elenril> BBB: what's missing for h264 parts?
[15:50:02] <elenril> only review from more people?
[15:50:17] <cartman> FATE looks green, nice
[15:54:36] <BBB> elenril: he didn't submit it yet
[15:54:52] <BBB> cartman: I did a lot of fate checking with these patches ;)
[15:55:00] <BBB> I don't think fate will break all that much
[15:55:03] <cartman> BBB: good to know! :)
[15:55:47] <DonDiego> mru: qnx compilation just died...
[15:55:58] <DonDiego> CC	libavcodec/snow.o
[15:55:58] <DonDiego> /misc/fate/work/quadra/src/libavcodec/snow.c: In function 'encode_frame':
[15:55:58] <DonDiego> /misc/fate/work/quadra/src/libavcodec/snow.c:3974: internal compiler error: in add_insn_before, at emit-rtl.c:3698
[15:55:58] <DonDiego> Please submit a full bug report,
[15:55:58] <DonDiego> with preprocessed source if appropriate.
[15:55:59] <DonDiego> See <http://www.qnx.com> for instructions.
[15:55:59] <DonDiego> make: *** [libavcodec/snow.o] Error 1
[15:56:09] <mru> DonDiego: I can read
[15:56:28] <mru> probably just a fluke crash
[15:56:38] <DonDiego> one more ICE that ffmpeg triggered...
[15:56:44] <mru> or bad ram
[15:56:48] <mru> it's an ancient machine
[15:57:13] <kshishkov> DonDiego: ICE? Not Thalys?
[15:57:23] <mru> the ram is from 2005 or older
[15:59:10] <av500> stupid question, how do I edit one git commit? commit something else and merge them togoether?
[15:59:27] <av500> aka a typo
[15:59:30] <av500> e.g.
[15:59:35] <kierank> git reset --soft HEAD~1
[15:59:45] <av500> what does that do?
[15:59:57] <kierank> undoes the commit
[16:00:03] <av500> but keeps my changes?
[16:00:04] <kshishkov> git rebase -i
[16:00:06] <ubitux> there is simpler
[16:00:27] <ubitux> git rebase -i HEAD~2, and you transform your typo fix into a fixup commit
[16:01:00] <Kovensky> av500: git commit --amend
[16:01:21] <cartman> amend will only work for the last commit
[16:01:24] <Kovensky> av500: --amend will merge anything you `git add`ed with the HEAD commit and open $VISUAL to edit the commit message
[16:01:37] <Kovensky> cartman: that's what he asked how to do =p
[16:01:46] <ubitux> btw, if someone has a way to simplify this: git commit -a -m fixup; git rebase -i HEAD~2 (+transformation into a fixup commit)
[16:01:49] <ubitux> i'm interested
[16:01:51] <av500> Kovensky: no, also a non last commit
[16:02:06] <Kovensky> for non-last? then only a rebase can do
[16:02:32] <av500> well, what do you do if your post a series of commits and get remarks?
[16:02:46] <ubitux> git rebase -i :p
[16:02:49] <Kovensky> you don't have to commit then merge btw, if you set the commit on the interactive rebase to 'e', you can edit however you want, git add, git commit, then git rebase --continue
[16:03:05] <Kovensky> at least IIRC that's how rebase works =p
[16:04:15] <ubitux> av500: http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2011-January/067416.html ← i explained quickly how to hack with the rebase here
[16:04:25] <Kovensky> av500: personally I'd do each patch on a topic branch, edit whatever you want, then at submit time merge to master, rebase squashing every commit
[16:04:48] <Kovensky> idk if that's the best method though
[16:05:06] * kshishkov fixups instead of squashing quite often
[16:05:30] <av500> Kovensky: and if patched depends on each other?
[16:05:33] <av500> patches
[16:05:36] <Kovensky> I think the *right* way is for the release manager to pull the topic branch from your personal repo and merge to master
[16:06:21] <av500> Kovensky: yes, but atm, ppl post to -devel
[16:06:35] <Kovensky> av500: depending on how you develop, then you either use tags or two topic branches
[16:06:50] <Kovensky> the second topic branch branching from the HEAD of the dependent topic branch instead of branching from master
[16:06:59] <av500> ah
[16:07:01] <av500> gee
[16:07:39] <Kovensky> those are (probably) the "right" ways though, you can do sth else if you feel better =p
[16:08:08] <av500> I will do it like svn, use 2 trees and beyondcompare :)
[16:09:03] <cartman> av500: pffff use diff -urN
[16:26:11] * av500 sent his 1st git patch
[16:26:24] <cartman> av500: congrats.
[16:26:26] <cartman> LGTM
[16:26:55] <av500> :)
[16:27:24] * av500 runs ffmpeg thru indent and sends that as 2nd patch
[16:27:53] <cartman> mru will kill you :P
[16:29:54] <spaam> av500: nice patch.
[16:40:25] <merbzt> can you get interlacing info from parsing the h264 headers ?
[16:41:23] <Kovensky> wouldn't that be interlacism
[16:41:25] <av500> merbzt: fun, I need that for mpeg2 right now :)
[16:41:28] <mru> not enough to be reliable
[16:41:34] <mru> h264 interlacing is 10x worse than mpeg2
[16:41:54] <av500> as it can be per macro block?
[16:42:08] <Kovensky> yes
[16:42:08] <mru> that's only part of it
[16:42:09] <Kovensky> MBAFF
[16:42:29] <horlicks> lies mbaff is lovely
[16:42:36] <horlicks> :p
[16:42:54] <merbzt> I just need to know if it is MBAFF or not
[16:43:44] <av500> given an mpeg2 "frame", how do I tell if its frame or a field?
[16:44:13] <mru> mpeg2 is easy
[16:44:28] <mru> there are about 3 or 4 flags that matter
[16:44:49] <mru> if sequence header has progressive_sequnce set, no frames are interlaced
[16:45:18] <elenril> wow, a patch from av500
[16:45:26] <mru> if not, each frame can be coded as progressive, interlaced frame picture, or two field pictures
[16:45:28] <elenril> and -mt is merged
[16:45:32] <mru> picture header will tell which
[16:45:34] * elenril checks temperature in hell
[16:45:35] <merbzt> elenril: bring out the champagne !!!
[16:46:29] <merbzt> mru: would be nice if avcodec context had and interlacing mode flag
[16:46:33] <av500> elenril: I have sent patches before :)
[16:46:40] <elenril> i know
[16:48:04] <merbzt> mru: that is my next thing I will nag about until someone implements it :)
[17:00:09] <kierank> merbzt: how do you plan to flag fake-interlaced encoded video?
[17:00:17] <kierank> at the header level you don't know what it's going to be
[17:00:41] <mru> there are two kinds of fake
[17:00:56] <mru> actually interlaced images coded as progressive
[17:01:07] <mru> and progressive images coded interlaced
[17:01:14] <mru> the latter has two forms
[17:01:32] <mru> really coded interlaced and progressive with repeat_first_field set
[17:01:35] <kierank> yeah i was referring to x264's "fake-interlaced" mode, which is frame mode PAFF
[17:01:49] <merbzt> I just need to know if it is MBAFF or not
[17:02:00] <mru> don't forget the SEI repeat messages either
[17:02:09] <av500> mru: found the flag, it was already in my code...
[17:02:46] <kierank> merbzt: there's a mbaff flag
[17:03:03] <merbzt> k, that sounds easy enough to use
[17:05:03] <Orphis> Yay, my first report : http://fate.ffmpeg.org/x86_64-mingw-w64-gcc-4.5/20110209165835
[17:05:16] <av500> No tests were run
[17:05:36] <kierank> x86_64-w64-mingw32-gcc: vfork: Resource temporarily unavailable
[17:05:38] <Orphis> Yes, someone broke compilation, it was working a few revisions before
[17:05:46] <av500> -mt?
[17:05:52] <Orphis> I guess so
[17:05:53] <mru> yes
[17:06:00] <mru> it broke systems w/o pthreads
[17:06:03] <Orphis> And that resource temporarily available is strange
[17:06:15] <Orphis> Why can't it be reliable ?!
[17:06:27] <mru> reliably unavailable?
[17:07:00] <lu_zero> vfork?
[17:07:30] <Orphis> cygwin is failing sometimes for no obvious reason (other than it's a ugly hack)
[17:07:52] <lu_zero> I always had problems with msys
[17:08:07] <lu_zero> cygwin more or less works nicely
[17:08:29] <lu_zero> (for the small purposes I had)
[17:08:55] <lu_zero> I never checked how it worked ^^;
[17:17:05] <Orphis> mru: Would it cause a problem if I run fate.sh again and submit the results if there has been no change to the git since the last submission ?
[17:17:20] <mru> no
[17:17:32] <mru> don't run it more than once per second though
[17:17:58] <mru> that's not supported
[17:18:04] <Orphis> Don't worry, cygwin makes it too slow to do that :p
[17:18:21] <Orphis> I'd like to rerun it so the real compilation error is shown
[17:18:37] <mru> the 32-bit build shows the real error
[17:18:58] <Orphis> I've had a different one, which is related but well
[17:19:35] <Orphis> I can wait for the next commit anyway
[18:02:31] <Orphis> There seems to be a conflict between some driver and cygwin... Great, let's remove the driver and check if it's now working
[18:18:56] <BBB> Orphis: awesome! I guess it's not reliable yet, but that'll come
[18:23:57] <CIA-38> ffmpeg: Vladimir Pantelic <vladoman at gmail.com> master * rf4c79d1e0b ffmpeg/libavformat/mpegts.c:
[18:23:57] <CIA-38> ffmpeg: mpegts: remove unused macro MAX_SCAN_PACKETS
[18:23:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:24:25] <av500> \o/
[18:25:07] <Orphis> BBB: There's a known problem with a webcam service that injects a DLL in every process, so I've stoped that service
[18:25:17] <av500> wtf?
[18:25:22] <thresh> wow, a patch by av500
[18:25:34] <BBB> it removes code, that doesn't count :-p
[18:25:38] <av500> :(
[18:25:41] <thresh> I have useless patches too, to enable HPUX compilation
[18:25:49] <mru> thresh: send 'em in
[18:25:55] <av500> thresh: it was more a git test
[18:26:07] <elenril> BBB: removing code is the best kind of patches
[18:26:11] * elenril loves removing code
[18:26:14] <thresh> mru: ok
[18:28:21] <av500> elenril: /me too
[18:28:27] <av500> less code = less bugs
[18:34:02] <av500> hmm, mpeg2 stream with each field separate, why is the 2nd field of each I frame marked as P?
[18:36:45] <mru> does it contain predicted blocks?
[18:37:03] <mru> iirc the second field is allowed to predict from the first
[18:38:25] <av500> ah right
[18:38:42] <av500> didnt thiunk of that
[18:38:47] <av500> so its "legal"
[18:40:28] <Orphis> Finally, compilation went as far as it could ! I hope no more problem will arise...
[18:41:42] <BBB> Orphis: my impression is that it just randomly fails b/c cygwin isn't very stable :-p
[18:41:53] <BBB> oh I should get colloguy-iphone
[18:42:10] <av500> BBB: ?
[18:43:10] <Orphis> I've read scary things about cygwin... like it could run out of available PID
[18:43:54] <Orphis> But most of the time, it's due to some service or antivirus or bloatware doing stuff in the backgroudn and hijacking the processes
[18:45:17] <Orphis> By the way BBB, do you want me to install nasm too or yasm will be enough ?
[18:47:44] <wbs> BBB, lu_zero: Care to review the "udp: Enable address reuse by default for multicast" patch I sent the other day?
[18:55:55] <BBB> Orphis: either one
[18:56:14] <BBB> wbs: I was hoping lu_zero would review; I'll review it in a bit :)
[18:56:54] <BBB> oh yeah I looked at it, a little ugly but I guess it's ok
[18:57:00] <BBB> wbs: can it be done in a less ugly way?
[18:57:20] <wbs> BBB: no, it's necessary to keep corner case behaviour
[18:57:28] <BBB> ok then it's fine
[18:58:14] <BBB> (I looked at it earlier and that's what I figured, but I wasn't sure, so was hoping lu_zero would know better)
[18:58:19] <BBB> I'll queue it later today
[18:58:44] <wbs> great, thanks :-)
[19:12:27] * elenril tries some patch review
[19:16:54] <kshishkov> av500: http://codecs.multimedia.cx/?p=323
[19:17:57] <elenril> that's what av500 looks like?
[19:18:20] <kierank> elenril: the stuff of nightmares
[19:18:23] <kshishkov> T-shirt may give a hint
[19:18:30] <mru> elenril: yes, and note the laptop for scale
[19:18:35] <mru> iirc that's a 15"
[19:19:29] <elenril> lol
[19:25:43] <kshishkov> okay, fixed
[19:28:44] <Dark_Shikari> mru: Gaikai is interested in someone who knows their shit regarding ARM, mobile devices, and set top boxes.  i.e. someone who could, say, write a native media player app that isn't crap, knows network code, etc.  Also note: probably doesn't include iShit.
[19:28:50] <Dark_Shikari> Do you know anyone who might be interested?
[19:28:53] <Dark_Shikari> (NB: probably fulltime)
[19:47:20] <mru> Dark_Shikari: permanent position?
[19:47:33] <Dark_Shikari> Indefinite, at least.  i.e. a real job.
[19:47:41] <Dark_Shikari> I figure you would know more people in this space than anyone else I know.
[19:48:42] <mru> btw, developing 3rd-party apps always sucks, regardless of the device
[19:48:51] <mru> some suck more of course
[19:49:00] <kshishkov> develop wrapper instead!
[19:49:18] <mru> but it's always the same story
[19:49:39] <kierank> maybe that arm guy who wrote mlp might be interested
[19:50:01] <mru> can't access $proper_way because the platform owner deliberatly (apple) or through incompetence locks you out
[19:51:12] <Dark_Shikari> I know
[19:51:15] <Dark_Shikari> part of the intention is:
[19:51:18] <Dark_Shikari> 1) Develop 3rd party app
[19:51:23] <Dark_Shikari> 2) Show to platform owner
[19:51:32] <Dark_Shikari> 3) Platform owner is OMG THIS IS FUCKING SWEET how can we get this working for real
[19:51:37] <Dark_Shikari> 4) Give us API access!
[19:51:48] <Dark_Shikari> So far we've been very, very successful in doing this in most cases.
[19:52:09] <Dark_Shikari> It's just that "knows networking", "knows video", and "knows performance" is a rare combination.
[19:52:59] <wbs> Dark_Shikari: successful as in dealing non-SDK apis with apple?
[19:53:14] <wbs> ah, you explicitly said it wasn't iShit
[19:53:52] <Dark_Shikari> we already have someone who does ishit
[19:57:34] <BBB> iShit is fun :-p
[19:57:55] <kierank> mru: or doesn't understand how to access $proper_way themselves
[19:58:17] <mru> kierank: that's the incompetent ones
[19:58:39] <BBB> astrange: ping
[19:59:01] <kshishkov> kierank: proper engineer can always make something plausible up (c) mru
[20:13:11] <mru> BBB: ping
[20:20:56] * elenril wonders where did all the people promising review and cake go
[20:21:16] <mru> the cake is under review
[20:21:34] <elenril> is that what we're callint it now?
[20:23:04] <mru> elenril: what do you want reviewed?
[20:23:43] <elenril> everything!
[20:23:47] <elenril> the rest of asf stuff
[20:23:51] <elenril> avio renames
[20:24:14] <elenril> avformat moves (though those probably should wait until the merge)
[20:24:22] <kshishkov> but no game codecs - nobody obviously has an experience to review them
[20:28:06] <BBB> mru: pong
[20:28:31] <BBB> elenril: will review asf, I will
[20:28:42] <mru> BBB: mt build fixes on ml
[20:28:50] <BBB> oh, for !pthread?
[20:28:53] <mru> BBB: I was going to ask you something about that but figured it out
[20:30:33] <astrange> mru's patch is ok
[20:31:27] <astrange> there's a definition of ff_thread_init with !HAVE_THREADS higher up, so it could define an empty ff_thread_free there, but it'd be somewhat pointless
[20:31:56] <mru> I thought of that too, but it seemed unnecessary
[20:34:49] <BBB> elenril: "[PATCH 07/10] asfdec: deobfuscate reading video properties size" actually changes behaviour, is that intended?
[20:36:21] <BBB> elenril: and the rest appears to have to be resent largely, so I'll wait for you to resend them
[20:38:02] <elenril> BBB: what do you mean?
[20:38:13] <BBB> you're reading two values, called size and sizeX
[20:38:17] <BBB> later size is used
[20:38:25] <BBB> then you remove reading size and replace it by a skip
[20:38:28] <BBB> and just read sizeX
[20:38:32] <BBB> and now you use sizeX later on
[20:38:35] <BBB> but that's not the same
[20:38:41] <BBB> because size != sizeX
[20:39:35] <elenril> -                size= sizeX;
[20:39:47] <BBB> oh, that _is_ obfuscated
[20:39:51] <BBB> wtf :)
[20:40:11] <mru> that should prove the usefulness of the patch
[20:41:00] <BBB> mru: did you push "[PATCH] lavf: make ff_guidcmp inline and move it to asf.h"?
[20:41:10] <elenril> so i'll just dump the whole branch again
[20:41:20] <elenril> BBB: yes, he did
[20:41:37] <mru> yes
[20:41:38] <elenril> ...or maybe not all of it
[20:41:44] <elenril> TheWorldIsNotReady
[20:42:47] <BBB> I've got 2/10 queued, I think
[20:42:54] <BBB> I'll push it, makes your life easier
[20:43:35] <BBB> pushed
[20:43:37] <BBB> anything else?
[20:43:40] <elenril> great
[20:43:43] <BBB> will await your next patchset
[20:43:45] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * r2cfa2d9258 ffmpeg/libavcodec/utils.c:
[20:43:45] <CIA-38> ffmpeg: check sample_fmt in avcodec_open
[20:43:45] <CIA-38> ffmpeg: check AVCodecContext->sample_fmt against AVCodec->sample_fmts[] to ensure
[20:43:45] <CIA-38> ffmpeg: that the encoder supports the specified sample format. Error out if it doesn't.
[20:43:45] <CIA-38> ffmpeg: Previously, it would continue and output garbage. Fixes issue 2587.
[20:43:47] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r4bc328a2bd ffmpeg/libavformat/ (asf.h asfdec.c asfenc.c):
[20:43:47] <CIA-38> ffmpeg: asf: split ASFContext into muxer and demuxer parts.
[20:43:47] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[20:43:53] * elenril resolves conflicts
[20:44:03] <BBB> oh I had another one queued
[20:46:07] <elenril> and yeah, i wanted to rename them too, but that's yet another huge and boring patch
[20:46:31] <BBB> I'm sure cleaning up asfdec is much more exciting
[20:46:55] <elenril> it's quite fun
[20:48:32] * BBB awaits next mailbomb
[20:51:31] <BBB> elenril: what was the verdict on the put_/get_*() rename?
[20:51:39] <BBB> elenril: I thought I OK'ed it, did it get committed?
[20:51:54] <BBB> (sorry if I didn't, I wanted to push -mt first)
[20:53:07] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r9a77a92c2b ffmpeg/libavcodec/utils.c:
[20:53:07] <CIA-38> ffmpeg: Fix build with threading disabled
[20:53:07] <CIA-38> ffmpeg: The avcodec_thread_free() compatibility wrapper calls ff_thread_free(),
[20:53:07] <CIA-38> ffmpeg: which is not defined when threading is disabled. Make this call
[20:53:08] <CIA-38> ffmpeg: conditional.
[20:53:08] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:53:17] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * raef669cdfd ffmpeg/libavcodec/w32thread.c:
[20:53:17] <CIA-38> ffmpeg: w32thread: add missing #include thread.h
[20:53:17] <CIA-38> ffmpeg: This should fix building with win32 threads.
[20:53:17] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:53:23] <BBB> I wonder why he signs off on his own patches
[20:53:33] <BBB> mru: should I do that too? ^^
[20:53:56] <kshishkov> BBB: should be good for bookkeeping
[20:54:22] <mru> that's what they do in kernelspace
[20:54:29] <elenril> BBB: Flameeyes suggested making the deprecated functions inline
[20:55:02] <elenril> or was it the new ones
[20:55:12] * elenril doesn't understand this magic very well
[20:55:28] <BBB> that's a bad idea
[20:55:39] <BBB> old apps are already compiled
[20:55:46] <BBB> they expect a _symbol_ there, not just the api
[20:55:53] <BBB> if the symbol isn't there, they will still not load
[20:56:10] <BBB> besides, since when do we care about the performance of apps that haven't recompiled against a new ffmpeg?
[20:56:21] * elenril sends some spam
[20:56:21] <BBB> I don't expect a ffmpeg of 2006 to perform as well as ffmpeg of 2011
[20:56:22] <BBB> right?
[20:56:31] <BBB> please bump that thread
[20:56:32] <BBB> :-p
[20:56:36] <wbs> BBB: did you mean to push the udp multicast reuse patch? you can add a "Signed-off-by: Martin Storsjö <martin at martin.st>" too, to that one
[20:56:43] <elenril> BBB: he suggested having both
[20:57:31] <elenril> i was hoping somebody who really understands how this binary stuff works would comment
[20:59:04] <_av500_> kshishkov: nice
[21:01:12] <kshishkov> _av500_: iKnow
[21:44:10] * elenril sleep(8h);
[21:44:33] <mru> EINTR
[21:45:58] <elenril> i expect to see all the patches reviewed by tomorrow morning ;)
[21:58:18] <Dark_Shikari> mru: av_clip_c isn't being inlined in vp8.c
[21:58:24] <Dark_Shikari> can we just force-inline everything in avutil common.h?
[22:08:08] <mru> probably
[22:14:12] <mru> I'd do a quick sanity check though
[22:23:09] <Dark_Shikari> av_always_inline doesn't seem to be defined in avutil
[22:23:09] <Dark_Shikari> wtf?
[22:23:25] <mru> attributes.h
[22:25:38] <Dark_Shikari> oh, it isn't included in some places...
[22:27:17] <therealgalen> i heard somebody was working on 10-bit h.264 playback... is this anything vaguely usable? is there a link to the patch?
[22:27:18] <therealgalen> 	
[22:28:27] <kierank> therealgalen: https://github.com/irock/FFmpeg
[22:29:35] <mru> Dark_Shikari: common.h includes it
[22:32:33] <therealgalen> kierank: any idea if it is vaguely usable?
[22:33:02] <kierank> no idea
[22:34:29] <Jumpyshoes> define usable
[22:39:10] <Dark_Shikari> Jumpyshoes: you need to help him on it!
[22:40:05] <Jumpyshoes> i'm not sure what else he needs to do... seeing as he fixed the issue he mentioned before
[22:45:14] <j-b> http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/video-media-player-application-of-the-year-855923/ <= notice that ffplay got one vote :D
[22:52:20] <Tjoppen> vote ffplay up! :)
[23:07:24] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r569ff02168 ffmpeg/libavformat/asfdec.c:
[23:07:24] <CIA-38> ffmpeg: asfdec: remove some write-only values from the context
[23:07:24] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>