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

[irc at mansr.com]

[00:03:22] <lu_zero> so it should be replaced completely
[00:03:40] <Dark_Shikari> No
[00:03:59] <Dark_Shikari> It does the right thing except for the reference frame handling
[00:04:00] <Dark_Shikari> which is wrong
[00:04:38] <lu_zero> the patch of 8-10hours ago tried to dup the frame but it segfaulted iirc
[00:05:01] <Dark_Shikari> Yes
[00:05:04] <Dark_Shikari> I gave up on that
[00:05:11] <Dark_Shikari> because ffmpeg's buffer handling doesn't understand the concept of duplicate frames
[00:05:18] <Dark_Shikari> that's why I posted a new patch above
[00:07:14] <lu_zero> adding a flag for it so it wouldn't free all the fields isn't a viable option?
[00:07:55] <Dark_Shikari> that isn't the problem
[00:08:04] <Dark_Shikari> TONS of stuff breaks if you have two reference frames in the list with the same pointer
[00:08:07] <Dark_Shikari> ENORMOUS amounts of stuff.
[00:08:16] <Dark_Shikari> I fixed the patch I posted 10 hours ago to not free -- it still breaks
[00:08:21] <Dark_Shikari> it just breaks 50 frames later in the video
[00:08:26] <Dark_Shikari> where it starts loading the wrong frames
[00:08:39] <lu_zero> =\
[00:08:47] <Dark_Shikari> So I just hacked it
[00:10:00] <lu_zero> how? doing a deepcopy?
[00:10:28] <Dark_Shikari> Just copying the pixels
[00:10:32] <Dark_Shikari> read the patch
[00:10:35] <Dark_Shikari> it's 10 bloody lines
[00:11:40] <lu_zero> I thought that is the minimal one and that first you did a full deepcopy of the thing =P
[00:12:50] <Dark_Shikari> No, I didn't do a full deepcopy ever
[00:14:09] <lu_zero> ok..
[00:22:59] <Dark_Shikari> oh btw, mru
[00:23:08] <Dark_Shikari> I talked to the boost dev who goes to my school about that symbol
[00:23:17] <Dark_Shikari> Spirit is a library in boost that generates recursive-descent parsers on compile time
[00:23:31] <Dark_Shikari> the concept is sound and perfectly reasonable, but in C++, the only way to do that is to encode the recursive-descent parser as a type
[00:23:34] <Dark_Shikari> Which it does.
[00:23:44] <Dark_Shikari> Users are... "highly" encouraged to strip such function symbols.
[00:33:16] <CIA-63> ffmpeg: stefano * r25165 /trunk/ (7 files in 3 dirs):
[00:33:16] <CIA-63> ffmpeg: Add frei0r filter.
[00:33:16] <CIA-63> ffmpeg: See thread:
[00:33:16] <CIA-63> ffmpeg: Subject: [FFmpeg-devel] [POC] frei0r wrapper
[00:33:16] <CIA-63> ffmpeg: Date: Tue, 24 Aug 2010 21:37:32 +0200
[00:52:44] <CIA-63> ffmpeg: stefano * r25166 /trunk/ (4 files in 2 dirs):
[00:52:44] <CIA-63> ffmpeg: Deprecate av_opt_show() in favor of a new function av_opt_show2(),
[00:52:44] <CIA-63> ffmpeg: which allows to specify only a subset of all the options to show.
[00:52:44] <CIA-63> ffmpeg: stefano * r25167 /trunk/ffplay.c: Make ffplay -h show the settable AVOptions.
[00:55:50] <CIA-63> ffmpeg: stefano * r25168 /trunk/doc/APIchanges: Update doc/APIchanges after the last API changes.
[05:44:04] <KotH> hoi zäme
[06:34:42] <_av500_> ahoi
[06:44:47] <mru> morning
[06:45:51] <Tjoppen> morr
[06:45:52] <Tjoppen> n
[07:50:51] <merbzt> Armada 628
[07:51:04] <merbzt> is that a capable chip ?
[07:51:19] <merbzt> or is it like the tegra2 ?
[07:52:50] <mru> spin doctors are doing their job, I see
[07:53:01] <mru> it's just another dual-core arm
[07:53:41] <kshishkov> dual-dual-core ARM
[07:54:02] <merbzt> tri-core
[07:54:07] <mru> no, not tri
[07:54:07] <kshishkov> nah, 2+1
[07:54:10] <mru> dual + 1
[07:54:15] <kshishkov> those cores are not equal
[07:54:35] <Dark_Shikari> some cores are more equal than others
[07:54:47] <kshishkov> and IIUC they're intended as alternatives, not for simultaneous work
[07:55:20] * kshishkov also would like to point out that Marvell designed that wonderful chip for SheevaPlug
[08:35:33] <lu_zero> yawn
[09:01:38] <Tjoppen> I wonder why vlc expects libliveMedia.a to reside at /usr/lib/live/liveMedia/libliveMedia.a rather than just /usr/lib
[09:02:09] <thresh> because live555 is broken
[09:02:15] <thresh> and why do you ask here anyway
[09:02:24] <DonDiego> i was just about to say that :)
[09:02:31] <DonDiego> that it's broken..
[09:02:52] <Tjoppen> hm. maybe I should join all the other channels :)
[09:16:16] <CIA-63> ffmpeg: stefano * r25169 /trunk/libavfilter/vf_frei0r.c: Remove unnecessary av_strdup() and av_free().
[09:20:55] <cartman> ahoy!
[09:21:05] <mru> merhaba
[09:21:33] <cartman> damn
[09:21:35] <cartman> feels weird
[09:21:43] <cartman> mru: stop doing that :P
[09:21:53] <mru> doing what?
[09:22:00] <cartman> speaking Turkish
[09:22:05] <cartman> felt really weird :P
[09:22:31] * mru does not speak turkish
[09:22:46] <cartman> *write
[09:23:19] <mru> ^^ that is all the turkish I know
[09:23:28] <cartman> :>
[09:23:50] <spaam> mru: maybe KotH need to teach you some more ;)
[09:24:53] * mru doesn't need to learn turkish
[09:25:00] <mru> all my turkish friends speak english
[10:02:30] <Dark_Shikari> mru: where's a guide to running fate?
[10:02:37] <Dark_Shikari> that is, the set of tests on fate.mansr.com
[10:02:58] <mru> what do you want to do?
[10:03:07] <mru> just test a patch?
[10:03:16] <Dark_Shikari> a guy in #ffmpeg is having an issue even with all asm off
[10:03:18] <Dark_Shikari> with artifacting
[10:03:20] <Dark_Shikari> I want him to run fate
[10:03:25] <Dark_Shikari> (he's on an apple device)
[10:03:38] <mru> "apple device"?
[10:03:44] <mru> arm based/
[10:03:45] <Dark_Shikari> iphone
[10:03:46] <Dark_Shikari> yes
[10:03:54] <Dark_Shikari> he's getting pink blocks in flv encoding
[10:04:06] <mru> it's very, very hard to run fate on iphone
[10:04:11] <Dark_Shikari> why is that?
[10:04:15] <mru> apple
[10:04:17] <Dark_Shikari> even if you jailbreak it?
[10:04:38] <mru> will it mount nfs and run sshd?
[10:04:43] <Dark_Shikari> dunno
[10:04:52] <mru> or something equivalent
[10:18:05] <mru> Dark_Shikari: which iphone model?
[10:18:17] <mru> and what os version?
[10:18:18] <Dark_Shikari> no idea
[10:18:19] <Dark_Shikari> #ffmpeg
[10:26:29] <saste> mru: hi
[10:26:41] <mru> hi saste
[10:26:49] <saste> mru: yes at least in theory it should be possible to build frei0r with MinGW/MSYS
[10:27:36] <saste> mru: not sure if strtok_r is supported there tho
[10:27:46] <saste> mru: I can check that...
[10:38:32] <cartman> wtf is frei0r
[10:38:51] <Dark_Shikari> correct, no strtok_r on mingw
[10:39:47] <mru> Dark_Shikari: no, but I bet there's no dlopen either
[10:40:05] <mru> or other thing frei0ia0i2lisw depends on
[10:40:50] <saste> cartman: http://frei0r.dyne.org/
[10:40:59] <cartman> dlopen users -> http://nelsonhaha.com/
[10:41:11] <saste> funny filters which make your ffmpeg look less serious
[10:41:20] <cartman> saste: thanx
[11:10:51] <cartman> oooh Michael is pissed off for real
[11:11:56] * cartman applies +empathy to the channel
[11:14:05] <mru> wtf is he smoking?
[11:14:56] <cartman> dunnow
[11:15:01] <cartman> the man needs a hug or something
[11:15:04] <mru> must be something potent
[11:15:12] <_av500_> so not the good turkish stuuf?
[11:15:35] <cartman> _av500_: we got great waterpipe
[11:17:01] <merbzt> cartman: mail subject ?
[11:17:16] <cartman> merbzt: [PATCH] move h264 loopfilter strength code to yasm
[12:26:12] <twnqx> is there a way to make ffprobe parse the whole file?
[12:27:15] <twnqx> these files claim to be video only
[12:27:23] <twnqx> and i don't believe ffprobe :X
[12:29:07] <kshishkov> does it contradict ffmpeg -i ?
[12:30:45] <twnqx> no...
[12:30:59] <kshishkov> or ffplay?
[12:31:07] <twnqx> sadly not
[12:31:17] <twnqx> but i still believe there must be audio somewhere
[12:31:24] <mru> BBB: before you spend too much time learning inline asm, know that it's neither intended nor suitable for blocks of more than a few instructions
[12:31:26] <twnqx> unless it's in these .afs file...
[12:31:34] <twnqx> -> Sega Dreamcast (Compressed Audio) by Sega of America, Inc.
[12:31:42] <BBB> mru: probably
[12:31:57] <twnqx> i was using inline ASM with borland pascal
[12:32:04] <BBB> mru: even so, it might be useful to learn - hey, maybe I can learn how to write better cabac code or so
[12:32:14] <twnqx> the gcc syntax is to braindamaged to even consider it, imho
[12:32:19] <mru> sure, there's no harm in learning how it works
[12:32:40] <BBB> what he asks for is nice in theory, but hard
[12:32:52] <BBB> it's easy to write braindead code in inline asm that performs like shit
[12:32:57] <BBB> just create a few too many variables
[12:32:59] <BBB> tadaa, done
[12:32:59] <mru> and the part about changing only the asm to yasm doesn't make sense
[12:33:07] <BBB> doing that in yasm is _incredibly difficult_
[12:33:15] <BBB> maybe that's why yasm performs so much better
[12:33:19] <BBB> writing shitty code is _hard_
[12:33:31] <mru> unknowingly writing shitty code is hard
[12:33:33] <BBB> writing optimal code is hard too, but generally you'll end up somewhere well better than the middle
[12:33:58] <BBB> any ideas on what to do then?
[12:34:28] <kshishkov> mru: really? Looks like it's most popular thing
[12:34:43] <mru> BBB: do about what?
[12:35:01] <BBB> shall I rewrite the yasm code to have all these in between variables? :-p
[12:35:10] <BBB> and then remove it to be my version?
[12:35:15] <BBB> that would be weird
[12:35:19] <mru> that would still be changing the c code
[12:35:29] <BBB> I think he doesn't necessarily mind
[12:35:37] <mru> it's almost like he thinks yasm and c can be mixed
[12:35:48] <BBB> I uderstand his frustration that the patches that move inline asm -> yasm are hard to review, because they're by no means 1:1 identical
[12:36:00] <BBB> that's just inherent to the whole issue at hand
[12:42:32] <kierank> wow michael signed an nda
[12:42:45] <kierank> or will do so
[12:42:58] <kshishkov> or just selfimposed one
[12:43:29] <BBB> merbanan: ping
[12:43:29] <kierank> maybe he's trying to negotiate the nda
[12:43:37] <kierank> that's why it took a year
[12:43:41] <mru> lame excuse
[12:45:10] <kshishkov> well, we don't know much about him anyway
[12:45:38] <mru> I know enough
[12:46:09] <kierank> what do you know
[12:46:37] <kshishkov> his personality, of course
[12:48:03] <cartman> kierank: which nda?
[12:48:27] <mru> cartman: the he's using as an excuse for not working
[12:48:42] <cartman> lol :>
[12:48:47] <mru> and if he's not working, then neither shall anybody else
[12:48:57] <cartman> nero?
[12:49:48] <Tjoppen> it seems dvbsub encapsulation in libav* is a bit of a mess. the encoder, decoder, parser, muxer and demuxer all have different ideas of how it should be done
[12:50:41] <Tjoppen> more specifically, the leading 20 00 bytes and the trailing FF byte
[12:58:11] <Tjoppen> in other words: RFC/PATCH time
[14:02:02] <CIA-63> ffmpeg: rbultje * r25170 /trunk/doc/optimization.txt:
[14:02:02] <CIA-63> ffmpeg: Update docs regarding writing optimizations:
[14:02:02] <CIA-63> ffmpeg: - mention clobber-marking of xmm registers,
[14:02:02] <CIA-63> ffmpeg: - some notes on external vs. inline asm, including tips on which to use for
[14:02:02] <CIA-63> ffmpeg:  what situation and to not rewrite+improve in the same patch (as with C code)
[14:02:03] <CIA-63> ffmpeg: - some more best-practice guidelines
[14:02:04] <CIA-63> ffmpeg: See "[PATCH] update doc/optimization.txt" thread on ML.
[14:06:35] <CIA-63> ffmpeg: rbultje * r25171 /trunk/libavcodec/x86/h264_idct.asm:
[14:06:35] <CIA-63> ffmpeg: Unroll loop in h264_idct_add8_sse2(). This means we can inline scan8[] in the
[14:06:35] <CIA-63> ffmpeg: code directly also and remove loop setup. 20% faster in function, 0.8% overall.
[14:06:35] <CIA-63> ffmpeg: See "[PATCH] unroll loop in h264_idct_add8_sse2()" thread on ML.
[14:07:47] <merbzt> BBB___: yes ?
[14:08:13] <CIA-63> ffmpeg: rbultje * r25172 /trunk/libavcodec/x86/h264_idct.asm:
[14:08:13] <CIA-63> ffmpeg: Unroll loop in h264_idct_add16intra_sse2(). Basically identical to r25171, this
[14:08:13] <CIA-63> ffmpeg: inlines scan8[] and removes loop setup. 15% faster, 0.4% overall.
[14:08:13] <CIA-63> ffmpeg: See "[PATCH] unroll loop in h264_idct_add8_sse2()" thread on ML.
[15:32:37] <CIA-63> ffmpeg: rbultje * r25173 /trunk/libavcodec/x86/h264dsp_mmx.c: Remove unused variable.
[15:37:53] <CIA-63> ffmpeg: michael * r25174 /trunk/ (4 files in 2 dirs): 2nd try to fix av_log() repeated detection
[15:40:04] <CIA-63> ffmpeg: michael * r25175 /trunk/ (ffplay.c ffmpeg.c): Enable AV_LOG_SKIP_REPEATED to maintain previous behavior.
[15:41:42] <CIA-63> ffmpeg: michael * r25176 /trunk/ffmpeg.c: Doxy consistency cosmetics
[16:19:05] <CIA-63> ffmpeg: michael * r25177 /trunk/libavutil/log.c: Cosmetic (rename detect_repeats to is_atty which matches the truth)
[16:19:06] <CIA-63> ffmpeg: michael * r25178 /trunk/libavutil/log.c: indent
[16:32:58] <CIA-63> ffmpeg: stefano * r25179 /trunk/cmdutils.c: Add missing existence checks in opt_default().
[16:36:34] <kierank> kshishkov: have you seen 5.1 variant of bink audio?
[16:37:40] <kierank> header is 1FCB
[16:40:31] <kshishkov> kierank: I'm not responsible for audio, please notify pross-au instead
[16:40:52] <kierank> ok
[18:05:13] <CIA-63> ffmpeg: mstorsjo * r25180 /trunk/libavformat/options.c:
[18:05:13] <CIA-63> ffmpeg: Add an AVOption max_delay for AVFormatContext->max_delay
[18:05:13] <CIA-63> ffmpeg: This can currently also be set via -muxdelay in ffmpeg for muxers,
[18:05:13] <CIA-63> ffmpeg: but not for demuxers (nor for demuxers in ffplay) - this patch
[18:05:13] <CIA-63> ffmpeg: allows it to be set in all those cases.
[19:35:55] <BBB___> why is yadif gpl?
[19:36:56] <mru> nobody knows
[19:37:14] <J_Darnley> Why wouldn't it be?  It is in mplayer
[19:37:34] <BBB___> put a gun to the head of whoever wrote it
[19:37:35] <mru> I don't care what licence it is
[19:37:38] <BBB___> and kindly ask to relicense it
[19:37:41] <Compn> probably diego didnt want to support lgpl in the source anymore
[19:37:47] <Compn> source/configure that is
[19:38:02] <Compn> no, nevermind, i'm thinking of something else
[19:42:58] <BBB___> mru: re:ML piece, no REALLY?!??!? :-p
[19:45:16] <mru> which part?
[19:45:31] <mru> time-wasting?
[19:46:06] <mru> I honestly don't see why you're entertaining this folly of his
[19:52:09] <cartman> BBB___: yadif is written by Michael himself afaik
[19:59:22] <BBB___> mru: maybe I learn from it...
[20:00:39] <BBB___> cartman: hm...
[20:00:50] <cartman> "We called him Tortoise because he taught us." ;=)
[20:02:32] <CIA-63> ffmpeg: stefano * r25181 /trunk/libavfilter/defaults.c: Add missing NULL checks, fix crash.
[20:26:44] <mru> BBB___: I prefer learning while doing something useful
[20:26:56] <mru> that way I might learn a useful skill
[20:32:13] <mru> I really fucking hate michael right now
[20:34:34] <Compn> you guys sure do got a lot of drama around
[20:42:08] <CIA-63> ffmpeg: stefano * r25182 /trunk/libavfilter/ (7 files): Add missing uses of NULL_IF_CONFIG_SMALL for the filters descriptions.
[20:42:59] <CIA-63> ffmpeg: mru * r25183 /trunk/libavcodec/vorbis_enc.c: vorbisenc: remove VLAs
[21:08:31] <Compn> anyone want to add a project to the list ?
[21:08:34] <Compn> http://sourceforge.net/projects/hypervideoconve/
[21:54:39] <bcoudurier> hi guys
[21:57:09] <bcoudurier> mru I saw you mentioning that the picture was copied twice in libavfilter, can you point me where ?
[22:00:51] <mru> bcoudurier: I was wrong
[22:01:11] <bcoudurier> ah
[22:01:24] <mru> but once is already more than it should be
[22:01:29] <bcoudurier> I know it's being copied once currently because direct rendering is not hooked up yet
[22:01:34] <bcoudurier> agree
[22:01:53] <bcoudurier> AVCodecContext->get_buffer need to get set to the first filter get_buffer function
[22:01:59] <bcoudurier> and no copy will be left
[23:15:05] <CIA-63> ffmpeg: stefano * r25184 /trunk/ (7 files in 4 dirs):
[23:15:05] <CIA-63> ffmpeg: Change the syntax of the crop filter from x:y:w:h to w:h:x:y.
[23:15:05] <CIA-63> ffmpeg: Slightly more intuitive and required by a pending changes for making
[23:15:05] <CIA-63> ffmpeg: the filter parametric.