[FFmpeg-devel-irc] IRC log for 2010-09-25

[irc at mansr.com]

[01:19:33] <CIA-63> ffmpeg: stefano * r25185 /trunk/ (5 files in 4 dirs): Make the crop filters accept parametric expressions.
[01:32:51] <CIA-63> ffmpeg: stefano * r25186 /trunk/cmdutils.c:
[01:32:51] <CIA-63> ffmpeg: Add more missing checks in opt_default(), prevent a crash if
[01:32:51] <CIA-63> ffmpeg: avcodec_opts[0] or avformat_opts is not set.
[01:32:51] <CIA-63> ffmpeg: stefano * r25187 /trunk/ (ffprobe.c Changelog): Make ffprobe able to set AVFormatContext options.
[01:57:51] <CIA-63> ffmpeg: stefano * r25188 /trunk/ (5 files in 2 dirs):
[01:57:51] <CIA-63> ffmpeg: Add asrc_anullsrc - null audio source.
[01:57:51] <CIA-63> ffmpeg: Based on a patch by "S.N. Hemanth Meenakshisundaram" smeenaks!ucsd!edu.
[01:57:51] <CIA-63> ffmpeg: stefano * r25189 /trunk/ (5 files in 2 dirs):
[01:57:52] <CIA-63> ffmpeg: Add asink_anullsink - null audio sink.
[01:57:52] <CIA-63> ffmpeg: Patch by "S.N. Hemanth Meenakshisundaram" /smeenaks/ucsd/edu.
[05:49:40] <ohsix> anyone know a nit about lattice wave digital filters
[05:56:30] <_av500_> hmm
[06:02:04] <bcoudurier> hey folks
[06:08:13] <_av500_> ohsix: http://focus.ti.com/lit/an/slaa331/slaa331.pdf
[06:12:05] <ohsix> oh nice; the article i was reading that used them probably derived the stuff from that; the project was also on an msp430
[06:15:33] <KotH> <accent type=asuka>guten morgen!</accent>
[07:03:31] <bcoudurier> hey KotH
[07:12:04] <Dark_Shikari> whoa.  michael approved my hacky patch
[07:12:12] <Dark_Shikari> (with being changed to use av_image_copy)
[07:13:36] <elenril> yaifications, troll-driven development!
[07:21:45] <Dark_Shikari> mru: NICE trolling
[07:21:46] <Dark_Shikari> lmao
[08:18:27] <lu_zero> bcoudurier: still there is the problem with multiple output ^^;
[08:20:19] * lu_zero needs a faster mail client =_=
[08:25:26] <lu_zero> hi saste
[08:26:34] <saste> hi
[08:45:38] <CIA-63> ffmpeg: reimar * r25190 /trunk/libavcodec/rawdec.c:
[08:45:38] <CIA-63> ffmpeg: rawdec: ensure that there is always a valid palette for formats that
[08:45:38] <CIA-63> ffmpeg: should have one like gray8 etc.
[08:49:39] <ohsix> http://wiki.xiph.org/File:Dmpfg_006.jpg huhuuh
[09:02:00] <Dark_Shikari> mru: <3 your email on fate
[09:02:11] <Dark_Shikari> only just saw it, since it was bumped
[09:58:55] <CIA-63> ffmpeg: stefano * r25191 /trunk/doc/filters.texi: Slightly clarify expression in for the anullsrc source documentation.
[10:17:08] <CIA-63> ffmpeg: stefano * r25192 /trunk/doc/protocols.texi:
[10:17:09] <CIA-63> ffmpeg: Document udp protocol.
[10:17:09] <CIA-63> ffmpeg: Based on a patch by Aviad Rozenhek aviadr1 @ reverse(moc.liamg).
[10:22:21] <elenril> o_0 ffmpeg compiled with clang is ~10% faster
[10:22:27] * elenril wonders if he's doing something wrong
[10:23:03] <mru> like using gcc?
[10:23:20] <elenril> but srsly - 10%
[10:23:28] <kshishkov> there was similar case with icc - it just miscompiled ffmpeg though
[10:23:42] <mru> elenril: 10% faster when doing what?
[10:23:47] <elenril> decoding h264
[10:23:48] <Dark_Shikari> crashing
[10:23:54] <Dark_Shikari> isn't icc broken on h264 decode?
[10:24:07] <mru> no
[10:24:19] <mru> I've seen gcc regress 25% from one version to the next
[10:24:27] <mru> Dark_Shikari: fate says icc is fine with h264
[10:25:02] <Dark_Shikari> it was broken a while back
[10:25:06] <Dark_Shikari> when mike did his last compiler comparison
[10:25:12] <mru> that was 2 e
[10:25:14] <mru> years ago
[10:25:33] <mru> now it fails atrac3 on 32-bit and sipr on 64-bit
[10:26:20] * elenril tries gcc 4.3
[10:26:33] <mru> what were you using?
[10:26:39] <mru> 4.4 is pure shit
[10:26:46] <elenril> 4.4.5
[10:26:55] <mru> that's probably why ubuntu ships it
[10:27:07] <mru> 4.4.5?
[10:27:10] <mru> there is no such version
[10:27:22] <elenril> gcc -v says
[10:27:28] <elenril> gcc version 4.4.5 20100728 (prerelease) (Debian 4.4.4-8)
[10:27:40] <elenril> whatever that means
[10:27:50] <mru> it means debian changed the version
[10:28:38] <kshishkov> official gcc 2.96 FTW
[10:29:06] <cartman> king of the miscompilers
[10:30:18] <kshishkov> and IIRC it was just a hack from RedHat for supporting Itanic with breaking some other things
[10:30:32] <mru> s/some/all/
[10:30:57] <kshishkov> well, it could print version
[10:31:55] <cartman> that was about it :>
[10:32:16] <elenril> hm, you're right, 4.3 is as fast as clang
[10:32:44] <mru> 4.5 is better than 4.4 too
[10:32:47] <mru> about like 4.3
[10:33:24] <kshishkov> and 4.6 is expected to achieve new level of suckyness
[10:34:11] <mru> gcc major/minor versions must have odd parity
[10:34:14] <mru> 2.95 was good
[10:34:16] <Dark_Shikari> Oh, true
[10:34:17] <mru> 3.4 was good
[10:34:25] <Dark_Shikari> Yeah, the parity of 4.6 is wrong
[10:34:25] <mru> 4.3 is good
[10:34:35] <mru> 4.1 wasn't all that great
[10:34:45] <Dark_Shikari> yeah, but every few versions following a major bump always suck
[10:34:52] <mru> but minor <3 always sucks too
[10:35:12] <cartman> 4.2 was buggy
[10:35:17] <Dark_Shikari> gcc is buggy
[10:35:35] <cartman> buggy as in miscompiling should-be-obviously-tested stuff
[10:35:45] <mru> 4.3 too
[10:35:46] <cartman> it even miscompiled kernel at some point
[10:35:58] <elenril> Dark_Shikari: http://m.xkcd.com/703/
[10:44:56] <saste> hi
[10:45:09] <saste> where can I find a mapping between MPlayer IMGFMT and PIX_FMT?
[10:45:25] <saste> I need it because I'm trying to port a linmpcodecs filter
[10:47:00] <kshishkov> it's somewhere in mplayer sources obviously
[10:47:16] <kshishkov> and names are similar anyway
[10:47:58] <saste> IMGFMT_I420?
[10:48:08] <saste> I suppose the I stands for Interlaced right?
[10:48:31] <iive> no
[10:49:03] <Dark_Shikari> I420 is YV12 with swapped u/v planes
[10:49:23] <saste> I already grepped the sources for some mapping and I can't find a file defining them like e.g. in pixfmt.h
[10:49:46] <kshishkov> that should hint you of general MPlayer code quality
[10:50:01] <saste> YV12 = NV12 ?
[10:50:10] * iive facepalms
[10:50:20] <kshishkov> nope
[10:50:28] <kshishkov> YV12 = YUV420
[10:50:41] <kshishkov> NV12 is separate format
[10:50:57] <kshishkov> read mplayer/docs/tech/colorspace.txt first
[10:51:04] <saste> kshishkov: thanks
[10:54:07] <mru> they're both 4:2:0
[10:54:22] <kshishkov> format = packing as well
[10:54:23] <mru> nv12 has interleaved u and v pixels
[10:54:46] <mru> 4:2:0 says nothing about memory layout
[10:54:51] <mru> only subsampling
[10:55:20] <kshishkov> yes, but it's usually implied
[10:55:52] <mru> not when I'm speaking
[10:56:07] <kshishkov> yes, you're master to your words
[10:56:25] <mru> if I say yv12, I mean a planar 420 format
[10:56:36] <mru> if I say nv12, I mean a semiplanar one
[10:57:05] <mru> if I say 420 I mean an unspecified format with subsampled u/v
[10:57:05] <kshishkov> and you don't say yuyv ever
[10:57:18] <mru> if I did, it would be obvious what I meant
[11:00:31] <iive> saste: try with "pixfmt2imgfmt"
[11:01:06] <kshishkov> mru: at least MPlayer did good job with swapping RGB and BGR definitions
[11:02:16] <mru> mplayer did the usual mistake of trying to shoehorn everything into a "fourcc" system
[11:02:23] <iive> kshishkov: i think that the file you pointed above, explains that mplayer uses same definition as opengl, that is kind of "standard".
[11:03:59] <kshishkov> mru: well, you know its history
[11:04:11] <mru> it started life as an avi player
[11:04:19] <mru> everything else was duct-taped on later
[11:04:33] <mru> and somewhere along the way, they ran out of tape
[11:04:38] <kshishkov> wasn't it avi player with duct-taped mpeg player?
[13:43:09] <CIA-63> ffmpeg: stefano * r25193 /trunk/libavfilter/vf_crop.c:
[13:43:09] <CIA-63> ffmpeg: Fix memleak introduced in:
[13:43:09] <CIA-63> ffmpeg:  r25185 | stefano | 2010-09-25 03:18:43 +0200 (Sat, 25 Sep 2010) | 1 line
[13:43:09] <CIA-63> ffmpeg:  Make the crop filters accept parametric expressions.
[13:54:23] <CIA-63> ffmpeg: stefano * r25194 /trunk/libavfilter/vf_crop.c:
[13:54:23] <CIA-63> ffmpeg: Prefix enum var_name symbols with VAR_, to avoid conflicts with already
[13:54:23] <CIA-63> ffmpeg: defined symbols, in particular should fix compilation in DOS.
[13:55:06] <mru> I can't but wonder if there's really anyone using ffmpeg on dos
[13:59:51] <_av500_> i wonder that for 50% of the supported archs
[14:00:41] <_av500_> and compilers
[14:00:41] <mru> we got a bug report on blackfin once
[14:01:20] <_av500_> i bet there are more blackfin than dos users
[14:01:38] <kierank> iirc there are more vlc users on windows 95 than on linux so there must be quite a few ffmpeg dos users
[14:02:25] <_av500_> kierank: for vlc, not a surprise
[14:02:25] <spaam> source?
[14:02:34] <mru> there is an advantage to testing on obscure systems even if nobody uses them
[14:02:41] <_av500_> mru: agreed
[14:02:52] <_av500_> it forces you to keep code clean
[14:03:09] <mru> bugs have often shown up first on something strange
[14:03:13] <mru> like sparc/bsd
[14:03:42] <_av500_> bsd = bug special detector?
[14:04:54] <mru> supporting weird things also provides some leverage when we insist that some system is broken
[14:14:05] * Compn grumbles something about at least being able to see the fourcc/isom/riff tags all in one file instead of spread out in 20 different demuxers
[14:14:36] <mru> the tags are format-specific
[14:14:47] <mru> they belong in each (de)muxer
[14:14:47] <Compn> i know
[14:15:06] <Compn> i'm just grumbling
[14:16:27] <Compn> maybe at the next con, ffmpeg should ask if anyone uses dos / win95
[14:16:28] <Compn> ehe
[14:23:42] <kierank> does ffmpeg build on gnu hurd?
[14:24:06] <mru> does gnu hurd?
[14:24:15] <kierank> dunno, ask rms
[14:25:11] <mru> if you look at the systems we support, you'll see that they are all real system that have or have had widespread use
[14:25:27] <mru> we don't really try to support vapourware
[14:38:50] <CIA-63> ffmpeg: banan * r25195 /trunk/libavcodec/imgconvert.c:
[14:38:50] <CIA-63> ffmpeg: Support deinterlacing of YUVJ422P in old deinterlacer.
[14:38:50] <CIA-63> ffmpeg: Patch by Maksym Veremeyenko verem at m1stereo tv.
[15:25:24] <pJok> mru, HURD is too old to be vapourware...
[15:25:43] <mru> vapour gone, only vacuum left?
[15:26:04] <pJok> yes
[15:46:41] <lu_zero> mru: I think ffmpeg builds just fine on hurd
[15:47:10] <lu_zero> (and probably we could add a minix)
[15:47:21] <lu_zero> the question might be _which_ hurd
[15:47:58] <lu_zero> since last time I tried to boot it I guess it got rewrote 3-4 times
[15:48:50] <pJok> lu_zero, debian gnu/hurd might be a good choice? gentoo dropped their hurd development at least...
[15:49:26] <lu_zero> pJok: eh...
[15:49:40] * lu_zero wanted a gentoo/minix
[15:49:41] * kshishkov waits for Duke Nukem Forever port to Hurd
[15:49:52] <lu_zero> kshishkov: so ... 10 years?
[15:50:08] <pJok> kshishkov, sadly Duke Nukem Forever actually seems to have a proper release schedule now...
[15:50:13] <kshishkov> lu_zero: 10 years from _any_ point in time
[15:50:30] <pJok> kshishkov, so just like the 30 years that fusion power is away from us?
[15:50:30] <lu_zero> kshishkov: =)
[15:50:43] <kshishkov> lu_zero: do you want gentoo/dos with your gentoo/minix?
[15:50:56] <lu_zero> kshishkov: already there I'm afraid...
[15:51:17] * kshishkov does not consider Minix to be proper OS (since it's for educational purposes only)
[15:51:24] <lu_zero> kshishkov: ehm
[15:51:28] <lu_zero> BAD student
[15:51:41] <lu_zero> minix3 apparently is a general purpose os
[15:51:51] <lu_zero> and got LOTS of founds from EU
[15:56:05] <lu_zero> at least that's what I got by listening to the author ^^
[15:56:33] <lu_zero> wbs: you around?
[16:00:29] <mru> govt/eu funded _and_ educational... no way that can be good
[16:01:02] <mru> btw gentoo is pretty much kernel-agnostic
[16:14:01] <kshishkov> hmm, looks like that Minix3 is still something not intended for real life
[16:14:19] <mru> of course not
[16:14:21] <mru> linux is
[16:14:27] <mru> and that's why tanenbaum is so angry
[16:16:38] <kshishkov> still? after almost 20 years?
[16:16:52] <mru> maybe he calmed down
[16:19:22] * kshishkov tries to imagine FFmpeg with microkernel architecture
[16:21:08] <pJok> ffOS?
[16:21:53] <pJok> chances of that happening is still greater than HURD being a useable OS
[16:22:27] <kshishkov> GNU is Not Usable
[16:22:54] <kierank> [17:00] <@mru> govt/eu funded _and_ educational... no way that can be good --> like p2p-next
[16:34:59] <lu_zero> p2p-next?
[16:35:20] <lu_zero> kshishkov: btw why microkernel?
[16:36:19] <kshishkov> lu_zero: looks like microkernel and ability to restart drivers are the main hype points of minix3, so I wonder what would happen to FFmpeg if it was designed that way
[16:36:46] * iive looks at gstreamer
[16:39:31] <lu_zero> kshishkov: the hype point were about being really small and with almost no bug in the foundation
[16:39:46] <lu_zero> (embedded/industrial usage)
[16:40:09] * kshishkov wonders why industry prefers QMX instead
[16:40:12] <kshishkov> *QNX
[16:40:19] <mru> because it works
[16:40:27] <lu_zero> kshishkov: because exists since ages
[16:40:28] <kshishkov> lame excuse IMO
[16:40:57] <kshishkov> lu_zero: would you use ITS or Multics?
[16:44:35] <CIA-63> ffmpeg: michael * r25196 /trunk/ (8 files in 4 dirs):
[16:44:35] <CIA-63> ffmpeg: yadif filter, based on stefanos port of my yadif from mplayer.
[16:44:35] <CIA-63> ffmpeg: Compared to stefanos, 2 frame output works with ffplay.
[16:47:35] <mru> fuck
[16:47:40] <mru> now I have to fix that mess
[16:47:59] <kshishkov> nope, just complain
[16:48:06] <mru> no point
[16:48:11] <mru> nobody else will fix it
[16:50:10] <kshishkov> "FIXME change API to not require this red tape"
[16:50:14] <kshishkov> sounds ominous
[16:50:49] <mru> where?
[16:51:01] <kshishkov> libavfilter/vf_yadif.c
[16:55:07] <J_Darnley> Wow, look at how red fate is now.
[16:55:11] <CIA-63> ffmpeg: michael * r25197 /trunk/libavfilter/vf_yadif.c: Fix 0 vs 1 porting bug from mplayer.
[17:04:21] <CIA-63> ffmpeg: stefano * r25198 /trunk/ (libavfilter/avfilter.h Changelog): Bump lavfi minor and add Changelog notice after yadif addition.
[17:10:08] <CIA-63> ffmpeg: michael * r25199 /trunk/libavfilter/Makefile: Stefanos port was missing DIRS variable in the Makefile for the newly added x86
[17:10:29] <merbanan> well fate works
[17:10:39] <mru> good job michael
[17:10:49] <mru> this is why I insist on reviewing things
[17:11:36] <mru> and that fix is wrong too
[17:12:26] * cartman ponders running fate
[17:14:27] <CIA-63> ffmpeg: mru * r25200 /trunk/configure: Create libavfilter/$arch when building outside source tree
[17:15:26] <cartman> lol lol lol
[17:15:35] <cartman> thedailywtf adobe screenshot is coming
[17:18:42] <cartman> http://img210.imageshack.us/img210/1396/screenshot20100925at816.png
[17:18:46] <cartman> lamest thing ever
[17:18:47] <saste> DonDiego: website documentation is not updated since 26 August 2010
[17:23:08] <kshishkov> cartman: actually that should be aproblem only on Linux. Looks like they really hate it
[17:23:29] <cartman> kshishkov: indeed, I had to manually format to get case-sensitive HFS+
[17:27:41] <jannau> mru: how do you refresh the ffmpeg git tree on git.mansr.com? cronjob or something triggered by commit?
[17:28:00] <mru> triggered by commit email
[17:30:43] <kshishkov> mru: will make still create dependency in libavfilter/x86 even for ppc/arm/other non-x86?
[17:31:02] <mru> eh?
[17:31:23] <kshishkov> I mean that DIRS addition by michael
[17:31:59] <mru> that's only used in make clean
[17:34:06] <jannau> thanks, http://git.jannau.net/git/FFmpeg.swscale/ will be updated every 30 until I have time to reroute emails to that server
[17:34:56] <lu_zero> uhm
[17:35:12] <lu_zero> do we have a container for raw audio and raw video?
[17:35:50] * lu_zero tried nut with strange results, but possibly the bug is somewhere else
[17:35:58] <mru> nut is strange
[17:36:27] <lu_zero> mov pukes with a segfault uhmmm
[17:37:21] <kshishkov> acute apple poisoning?
[18:25:20] <felipec> are other bitstream readers really used?
[18:26:07] <kshishkov> because rectangle
[18:26:56] <kshishkov> please tell me more about the one bitstream reader everyone presumably uses
[18:28:30] <_av500_> lu_zero: .avi :)
[18:33:37] <kshishkov> _av500_: that's still not a reason not to support nut+Snow in Archos players
[18:34:00] <_av500_> kshishkov: right, will enable it
[18:34:15] <_av500_> i have a wrapper layer for lavf anyway
[18:34:54] <_av500_> kshishkov: what is the IP situation on our favorite codec?
[18:35:18] <kshishkov> _av500_: the same as on other codecs - nobody cares
[18:36:41] <_av500_> sadly, ppl care, there is a court in marshall texas to prove it :(
[18:38:16] <kshishkov> _av500_: well, that court will accept any patent
[18:39:20] <lu_zero> _av500_: snow <- if dirac is ok so is snow
[18:40:28] <lu_zero> curiously avi doesn't misbehave as mov
[18:40:38] <lu_zero> still I'm doing something wrong
[19:30:29] <felipec> why does the bitstream reader do things like: unsigned index = s->index; index++; s->index = index;
[19:31:02] <mru> where does it do that?
[19:32:06] <felipec> mru: get_bits1 for example
[19:32:19] <mru> do you have a problem with that?
[19:33:06] <felipec> mru: no, I was just wondering if it was convenience or some ninja compiler trick
[19:33:26] <mru> that's what you get after macro expansion, right?
[19:33:27] <roxfan> what type is s->index?
[19:33:39] <mru> roxfan: int or unsigned int
[19:34:46] <mru> copying struct fields into local variables can improve performance
[19:35:03] <mru> if you don't, the compiler assumes the bit buffer might overlap the struct
[19:35:18] <mru> which forces it to reread stuff
[19:35:26] <mru> aliasing is so much fun
[20:01:07] <lu_zero> ok
[20:01:17] <lu_zero> output-example looks wrong.
[20:02:37] <mru> no really?
[20:05:54] <lu_zero> mru: =P
[20:06:24] * kshishkov prepares to cite lu_zero
[20:06:29] <kshishkov> *yawn*
[20:06:38] <kshishkov> g'night everyone
[20:06:45] <lu_zero> good night kshishkov  =)
[22:29:35] <kierank> i wonder if ffmpeg builds on pocket pc; then i could put my phone on fate
[23:28:26] <CIA-63> ffmpeg: stefano * r25201 /trunk/ (11 files in 3 dirs):
[23:28:26] <CIA-63> ffmpeg: Replace deprecated CODEC_TYPE_AUDIO and CODEC_TYPE_VIDEO with the
[23:28:26] <CIA-63> ffmpeg: corresponding AVMEDIA_TYPE_* symbols.