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

[irc at mansr.com]

[00:57:22] <CIA-63> ffmpeg: bcoudurier * r25202 /trunk/libavfilter/vf_yadif.c:
[00:57:23] <CIA-63> ffmpeg: In yadif filter, use current frame when previous is missing,
[00:57:23] <CIA-63> ffmpeg: better results for the first frame
[01:57:46] <CIA-63> ffmpeg: michael * r25203 /trunk/ (4 files in 3 dirs): Fix rv20 encoding so the binary decoder can decode it.
[01:57:58] <Dark_Shikari> oh wow.
[01:58:03] <Dark_Shikari> I did not see that coming.
[01:58:11] <Dark_Shikari> troll-driven development succeeds again
[02:24:18] <Compn> how is that troll?
[02:24:39] <Compn> carl reported an rv20 bug
[02:24:49] <Compn> michael fixed it
[02:25:38] <Dark_Shikari> trolling == making rv20 experimental
[02:25:42] <Dark_Shikari> solution == fixing it
[02:27:03] <Compn> ah, true i suppose
[02:28:54] <Compn> i dont see any changes to the muxer
[02:29:02] <Compn> so i'm guessing that the vcodec copy is still broken ;\
[05:18:21] <KotH> salve ffmpegians
[05:19:20] <johnf> mru: You about?
[05:22:13] <johnf> Maybe someone else can help. Not sure if I'm hitting an ffmpeg bug or not. I've got ffmpeg compiled for the an iphone app and am encoding video on the iphone. All working pretty well except I'm getting some pink blocks in the output
[06:36:32] <_av500_> hello ffolks
[06:40:02] <kshishkov> hello, little guy
[08:45:16] <mru> who broke fate this time?
[08:47:12] <johnf> mru: I did some more testing on the pink bits problem I was getting yesterday
[08:47:20] <Dark_Shikari> mru: test needs to be updated
[08:47:32] <johnf> If I configure with --disable-asm the pink bits go away
[08:47:48] <mru> Dark_Shikari: so it was michael
[08:48:31] <mru> johnf: can you reproduce it using the ffmpeg command line?
[08:48:33] <johnf> I tried disabling each of --disable-armv5te --disable-armv6 --disable-armvfp one at a time but none of them seems to make the pink bits disappear
[08:48:57] <johnf> mru: this is on the iphone. No command line just the app I'm writing
[08:49:17] <johnf> I'm guessing the next step is to manually disable all the different assembly bits to try and work out which one is breaking it
[08:49:47] <mru> yes please
[08:50:09] <mru> which encoder are you using?
[08:50:35] <johnf> mru: FLV but I also tried something else and it didn't seem to make a difference
[08:51:18] <Dark_Shikari> they all use mpegvideo
[08:51:23] <Dark_Shikari> so I suspect it's a core mpegvideo function
[08:51:33] <mru> not all
[08:51:42] <mru> e.g. qtrle
[08:53:52] <Dark_Shikari> ok, lossy ones.
[08:53:53] <Dark_Shikari> =p
[08:55:18] <mru> intra-only formats don't use much of mpegvideo either
[08:56:06] <kshishkov> mjpeg?
[08:56:14] <mru> and all the image formats
[08:58:43] <Dark_Shikari> jpeg still goes through mpegvideo
[08:58:56] <Dark_Shikari> but yeah, it doesn't use sad, etc
[08:58:58] <mru> it doesn't use ME
[08:59:45] <johnf> Any hints on the best place to start?
[08:59:58] <johnf> I'm going to disable all the asm and then manually turn buts back on
[09:00:43] <kshishkov> dct and add/put_pixels are most obvious things to check
[09:03:45] <CIA-63> ffmpeg: mru * r25204 /trunk/tests/ref/seek/rv20_rm: Update rv20 seek test reference
[09:06:39] <Dark_Shikari> kshishkov: its only in a few blocks
[09:06:43] <Dark_Shikari> so I would suspect it's related to mode decision
[09:07:47] <kshishkov> Dark_Shikari: I'm an engineer, I'm expected to give theoretical answers even without knowing background
[09:09:10] <CIA-63> ffmpeg: reimar * r25205 /trunk/libavcodec/x86/fft_mmx.asm:
[09:09:10] <CIA-63> ffmpeg: Split and then simplify address generation macro.
[09:09:10] <CIA-63> ffmpeg: Allows nasm to work for this code.
[09:16:27] <CIA-63> ffmpeg: reimar * r25206 /trunk/libavcodec/x86/h264_idct.asm: Add d suffix to movd target register to make it work with nasm.
[09:21:39] <johnf> Hmm turning bits of asm on and off is a bit tougher than I thought it would be. Has anyone done this before and can give me pointers?
[09:23:10] <mru> in libavcodec/arm/ there are some init functions assigning function pointers
[09:23:20] <johnf> yes I saw those
[09:23:26] <mru> just comment out the assignments to disable them
[09:23:36] <johnf> cool, was wondering if I could do that
[09:40:26] <johnf> OK I've narrowed it down to ff_put_pixels8_xy2_arm
[09:43:00] <johnf> mru: Should I just file a bug or is there something further I can do to debug it
[09:56:48] <mru> I can't see anything wrong with that function
[10:03:45] <johnf> Do you think the gas-preprocessor.pl could be having some sort of side affect?
[10:04:40] <johnf> mru: What should I do next?
[10:04:47] <mru> it's unlikely a bug there would only show up in that function
[10:05:21] <mru> are you saying it works if you disable just that one function?
[10:06:08] <johnf> Let me tripple check
[10:12:30] <johnf> mru: OK interesting I didn't notice it before
[10:12:40] <johnf> Just commenting out that function the pink blocks go away
[10:12:52] <johnf> But now I have what I would call translucent blocks
[10:13:18] <johnf> be back in an hour have to go out to dinner
[10:24:28] <mru> ah, it is the gas-preprocessor
[10:24:31] <mru> Yuvi: ping
[10:27:23] * cartman damn iPhoners
[11:10:34] <CIA-63> ffmpeg: stefano * r25207 /trunk/libavfilter/vf_yadif.c: Cosmetics: fix style nits.
[12:04:46] <mru> johnf: preprocessor fixed: http://github.com/mansr/gas-preprocessor
[12:04:58] <mru> not thoroughly tested though
[12:26:16] <johnf> mru: That's awesome. Works perfectly now!!
[12:26:24] <johnf> Thanks!
[12:27:34] <mru> thanks for taking the time to find the broken function
[12:27:44] <mru> that was most helpful
[12:27:54] <Dark_Shikari> mru: what was the error in gas preprocessor?
[12:27:59] <Dark_Shikari> I probably should backport this to x264's copy
[12:28:04] <johnf> mru: I don't suppose you are going to OVC or FOMS?
[12:28:10] <mru> Dark_Shikari: see above
[12:28:18] <mru> johnf: afraid not
[12:28:25] <Dark_Shikari> you didn't explain it above
[12:28:35] <mru> look at the damn commit
[12:28:39] <Dark_Shikari> oh
[12:28:49] <Dark_Shikari> tricky
[12:29:05] <johnf> mru: shame, would have gotten my partner to buy you a suitable alchoholic beverage  :)
[12:29:14] <mru> hehe
[12:32:10] <mru> another happy customer :-)
[12:47:34] <mru> KotH: what's going on, you were out for 40 minutes?
[12:48:24] <KotH> accidentally unplugged my router when moving stuff around
[13:55:28] <CIA-63> ffmpeg: kostya * r25208 /trunk/libavcodec/ (vc1.c vc1.h): RES_SM in WMV3 is really two flags, so split it in decoder
[13:57:39] <CIA-63> ffmpeg: kostya * r25209 /trunk/ (4 files in 2 dirs): Make WMV3 decoder attempt to decode WMVP as well
[13:58:22] <kshishkov> if you see BBB, please show this commit to him and ask him to reencode it with xvp8
[13:59:15] <Dark_Shikari> lol
[13:59:17] <lu_zero> uh?
[13:59:58] <kshishkov> lu_zero: well, somehow he mentions WMVP after I ask him about xvp8
[14:00:13] <Dark_Shikari> good, good, troll-driven development
[14:00:24] <mmu_man> ;)
[14:00:51] <Dark_Shikari> kshishkov: wait, does this mean we have WVP2 support?
[14:00:57] <Dark_Shikari> oh.  WMVP9.
[14:00:59] <Dark_Shikari> er, WMVP.
[14:01:01] <Dark_Shikari> damn.
[14:01:12] <kshishkov> WVP2 seems to differ a bit
[14:01:18] <Dark_Shikari> what exactly is WVP2?
[14:01:35] <kshishkov> the same thing - slideshow encoded in WMV9
[14:01:48] <Dark_Shikari> so how close are you to supporting that? =p
[14:02:03] <kshishkov> dunno
[14:02:12] <Dark_Shikari> It's the Most Wanted Codec
[14:02:27] <kshishkov> preferably dead
[14:22:29] <lu_zero> is that ugly?
[14:22:40] <lu_zero> rv40 level?
[14:23:08] <kshishkov> no, it's totally different codec
[14:23:47] <kshishkov> at least in WMVP it's still images and affine transform (with 3x3 matrix) plus fading
[14:24:10] <kshishkov> I suspect there is something similar in WVP2 plus additional bells and whistles
[14:24:45] <lu_zero> I see
[14:25:56] <Compn> kshishkov : did you see there is another screen codec? :P
[14:26:14] <Compn> but i've only seen one sample for it so far
[14:26:20] <CIA-63> ffmpeg: michael * r25210 /trunk/ (15 files in 4 dirs): Move AVOptions from libavcodec to libavutil
[14:26:27] <kshishkov> Compn: have you REd exising ones?
[14:26:31] <Compn> no
[14:26:48] <Compn> ffmpeg seems to like native screen codecs so far
[14:27:07] * Compn still waiting for vivo :P
[14:27:19] <kshishkov> what's the name of that screen codec anyway?
[14:27:48] <Compn> expression encoder screen codec or so
[14:27:55] <Compn> fourcc MTS2
[14:28:20] * kshishkov waits for expletive expressions encoder screen codec
[14:28:55] <Compn> err
[14:29:06] <Compn> maybe i was thinking MSA1
[14:29:07] <Compn> http://samples.mplayerhq.hu/V-codecs/MSA1.wmv
[14:29:20] <Compn> yeah msa1 , not expression, my bad
[14:29:33] <Compn> MS ATC screen decoder 1
[14:30:53] * Compn got lost in wmv codecs
[14:32:58] <Compn> kshishkov : so what are you working on now? aside from wvp2
[14:38:11] <kshishkov> Compn: dunno
[14:47:53] <CIA-63> ffmpeg: mstorsjo * r25211 /trunk/libavcodec/avcodec.h: Bump minor version for the addition of the G.722 encoder
[15:26:54] <kshishkov> Compn: the only thing I can say about MSA1 now is that it employs YUV ITU-R variant
[15:31:47] <felipec> mru: is uxth always needed between a ldrh and a rev16?
[15:32:17] <mru> never
[15:32:26] <mru> gcc thinks so
[15:32:38] <mru> ldrh zero-extends
[15:32:51] <mru> uxth also zero-extends
[15:33:52] <felipec> that's what I thought... then AV_RB16 can be optimized
[15:34:09] <mru> you mean gcc can be optimised
[15:34:14] <mru> that wouldn't be news
[15:36:44] <felipec> yeah, AV_RB16 can be optimized further for gcc
[15:36:53] <mru> I'm not so sure
[15:37:04] <mru> it's hard to stop gcc fucking up
[15:37:12] <mru> I'm not putting any uxth in there
[15:37:14] <mru> gcc does that
[17:55:47] <CIA-63> libswscale: ramiro * r32360 /trunk/libswscale/utils.c: swscale: use full chroma input for point scaler
[18:00:11] <cartman> x86/fft_mmx.asm:49: warning: section flags ignored on section redeclaration
[18:00:14] <cartman> x86/fft_mmx.asm:74: warning: section flags ignored on section redeclaration
[18:00:17] <cartman> possibly for BBB
[18:01:06] <mru> better than libavfilter/x86/yadif.c:222: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
[18:03:14] <cartman> mru: thats so 32bit of you
[18:03:44] <kshishkov> cartman: that's so GCC for you
[18:03:51] <cartman> kshishkov: clang
[18:03:52] <cartman> ;>
[18:03:59] <cartman> but possibly gas yes
[18:04:24] <cartman> I wrote my first inline asm btw \o/
[18:04:30] <cartman> wonder if the hell is frozen :P
[18:05:01] <kshishkov> of course not
[18:05:06] <cartman> :/
[18:07:00] <mru> that's gcc on osx
[18:07:02] <mru> 32-bit
[18:07:22] <kshishkov> that can be GCC anywhere on 32-bit
[18:07:27] <cartman> yup
[18:07:36] * cartman spills some registers
[18:07:37] <kshishkov> (32-bit x86 only)
[19:08:53] <Compn> kshishkov : do we have samples for fourcc WMVR / WMVB ?
[19:09:07] <Compn> or were those from a spec ?
[19:09:19] * Compn reading vc-1 wiki page
[19:09:24] <kshishkov> from driver IIRC
[19:10:08] <kshishkov> and I don't think there'll be problems decoding those anyway
[19:10:39] <Compn> ah
[19:10:51] * Compn trying to compile list of known codecs stored in wmv
[19:11:40] <kshishkov> it's easy. Two words: M$ crap
[19:12:28] <Compn> haha
[19:15:08] <Compn> oh that expression codec was a screen codec too.
[19:15:15] * Compn wonders where he put the sample
[19:17:04] * kshishkov thinks it's easier and a bit better to finish Indeo family. Now to find someone to do that
[19:17:45] <cartman> find-indeo-coder.py
[19:18:08] * kshishkov does not believe in Python
[19:18:21] * cartman belives in f00d
[19:18:40] * kshishkov just knows food exists
[19:19:07] <mru> kshishkov: you look like you've seen some...
[19:19:58] <kshishkov> mru: yes, I admit that I had close encounter with food
[19:20:12] <mru> and the food lost
[19:20:14] * elenril labels kshishkov as a heretic
[19:20:14] * Compn eats a bell pepper
[19:20:18] <kshishkov> and it didn't survive it it some cases, yes
[19:34:42] <CIA-63> libswscale: michael * r32368 /trunk/libswscale/ (swscale.h utils.c):
[19:34:43] <CIA-63> libswscale: Split alloc and init of context so that parameters can be set in the context
[19:34:43] <CIA-63> libswscale: instead of requireing being passed through function parameters. This also
[19:34:43] <CIA-63> libswscale: makes sws work with AVOptions.
[19:35:48] <Dark_Shikari> whoa.  is that an api change?
[19:36:06] <mru> one would hope he left a compat wrapper
[19:36:37] <cartman> ah so current sws howtos became obsolute once agaib
[19:36:42] <cartman> s/b/n
[19:37:37] <mru> yes, there is a wrapper
[19:38:29] <mru> this is one (small) step towards swscale sanity
[19:38:36] <mru> do not complain about it
[19:38:49] <Dark_Shikari> lol
[19:38:50] <Dark_Shikari> +1
[19:40:17] <cartman> that will be another ifdef sir
[19:42:13] <lu_zero> \o/
[19:55:36] <Dark_Shikari> wow.  we really trolled michael into making swscale better.
[19:55:46] <Dark_Shikari> another commit went in as well
[19:56:06] <Dark_Shikari> I guess when we say "we're reimplenting X in x264, because swscale doesn't do X", he starts getting annoyed
[19:56:10] <mru> it has a long way to go
[19:56:13] <Dark_Shikari> oh yes
[19:56:23] <Dark_Shikari> And I wonder how long it'll be until he implements a dither algorithm that isn't ordered dither
[19:56:30] <mru> like the insane ifdef hell around the asm
[19:56:35] <Dark_Shikari> we used error diffusion in x264's
[19:56:50] <cartman> He doesn't want an ffmpeg work, thats it
[19:56:55] <mru> ordered dithering is almost uglier than none at all
[19:58:07] <lu_zero> Dark_Shikari: would you donate it to swscale? ^^
[19:58:48] <Dark_Shikari> lu_zero: it's trivial and a dozen lines
[20:00:54] <lu_zero> Dark_Shikari: and that would make michael either accept it or write yet another that he likes
[20:07:14] * lu_zero waits get his mailbox back...
[20:22:06] <mru> hmm, something's weird with nasm
[20:37:34] <cartman> mru: yes dylib
[20:38:06] <lu_zero> wbs: could you please resend me the reorder patchset?
[20:39:16] <wbs> lu_zero: sure
[20:40:37] <DonDiego> yasm question: is config.asm required/essential?
[20:40:54] <DonDiego> mplayer's configure does not create it, but compilation seems to work fine..
[20:40:54] <mru> of course
[20:40:58] <mru> it wouldn't be there otherwise
[20:40:58] * lu_zero had to wipe his mailbox
[20:41:16] <DonDiego> i wonder how mplayer ever compiled yasm then..
[20:41:27] <mru> it's a rather new addition
[20:42:22] <mru> BBB requested it
[20:42:29] <mru> not sure what it's used for
[20:42:56] <mru> it sets the ARCH_ macros of course
[20:43:13] <mru> iirc BBB wanted to use some other config flags for something
[20:43:20] <mru> doesn't look like he got round to it yet
[20:44:42] <DonDiego> so no part is used (yet)?
[20:44:53] <mru> the ARCH_ macros are
[20:45:00] <DonDiego> ah, ok
[20:45:13] <DonDiego> more stuff i need to port to mplayer..
[20:45:15] <mru> they were duplicated somewhere else before
[20:45:21] <DonDiego> *sigh*, this has to end..
[20:45:26] * DonDiego is working on it..
[20:45:48] <mru> you could stop trying to replicate half of the ffmpeg build system and use the real thing directly
[20:45:58] <DonDiego> this is what i'm working on
[20:46:03] <mru> good
[20:46:05] <mru> for you
[20:46:29] <DonDiego> if i don't finish this soon i will surely go insane..
[20:49:14] <CIA-63> libswscale: michael * r32369 /trunk/libswscale/options.c: Make the avoptions list of sws more complete.
[20:49:14] <CIA-63> libswscale: ramiro * r32370 /trunk/libswscale/swscale.h: fix typos and grammar
[20:50:27] <lu_zero> DonDiego: need an hand on that?
[20:53:39] <DonDiego> as many as you can give me..
[20:54:05] <DonDiego> but actually, right now i think we would only step on each other's toes
[20:54:24] <DonDiego> lu_zero: how about finishing the libmpeg2 stuff?
[20:54:38] <DonDiego> that would be a welcome thing in mplayer and nobody else will do it :)
[20:55:00] <mru> > as many as you can give me..
[20:55:05] <mru> you need a hindu god
[20:55:55] <lu_zero> DonDiego: the libmpeg2 stuff...
[20:56:20] <lu_zero> finish in the good way -> (expose the quant bits from ffmpeg)
[20:56:34] <DonDiego> you mean from libmpeg2?
[20:56:51] <lu_zero> or finish in the dirty way (make our copy the new libmpeg2 release)
[20:57:00] <mru> hehe
[20:57:17] <DonDiego> choose your poison..
[20:57:20] <lu_zero> since from what we discussed to do postproc we need those value
[20:57:22] <lu_zero> s
[20:57:40] <lu_zero> and there isn't a nicer interface for them
[20:57:48] <pJok> what? swscale is getting fixed?
[20:57:48] <DonDiego> somebody just needs to sit down and do it
[20:58:05] <lu_zero> still I'd like to know better what's needed and how's used
[20:58:14] <DonDiego> lu_zero: i see nobody except you step forward..
[20:59:21] * lu_zero chopped ffmpeg configure few times to see what could be reused with ease
[21:02:14] <CIA-63> ffmpeg: mru * r25212 /trunk/libavutil/arm/intreadwrite.h:
[21:02:14] <CIA-63> ffmpeg: ARM: change return type of AV_RN16() to unsigned
[21:02:14] <CIA-63> ffmpeg: This prevents gcc inserting useless UXTH instructions, at least
[21:02:14] <CIA-63> ffmpeg: in some cases.
[21:02:14] <CIA-63> ffmpeg: mru * r25213 /trunk/configure: configure: detect nasm vs yasm and set flags correspondingly
[21:05:01] <DonDiego> lu_zero: i'm currently whittling mplayer's configure into shape by simplifying all tests as far as possible
[21:05:25] <DonDiego> i want all the hidden knowledge there to become explicit
[21:06:06] <DonDiego> some checks are unnecessarily complex, others are complex for a good reason, the latter should be explicit about it, the former should be simplified
[21:07:24] <Kovensky> some are overly simple
[21:07:40] <Kovensky> I remember seeing a few checks that only checked for headers but didn't check for linking of functions
[21:08:10] <Kovensky> so it could approve some random library that has headers present but no libraries or the libraries are of the wrong architecture / system
[21:16:00] <DonDiego> i think it's ok to be optimistic until we stumble over a broken system that does not work with these assumptions
[21:18:49] <Kovensky> which is very easy to find on multilib systems
[21:18:53] <Kovensky> or cross-compiling ones
[21:20:01] <mru> especially ones with deceptive pkgconfigs
[21:20:32] <DonDiego> as i said, i'm open to fixes as soon as such systems appear
[21:20:46] <DonDiego> but i don't see mplayer's configure failing left and right..
[21:21:21] * Kovensky has a bunch of workarounds by using --enable/disable-libWhatever and --extra-libs
[21:21:24] <DonDiego> btw, anybody seen monty's video podcast?
[21:21:42] <spaam> url?
[21:21:48] <DonDiego> Kovensky: patches welcome..
[21:22:42] <mru> DonDiego: how full of lies is it?
[21:24:02] <DonDiego> it's good, go watch it..
[21:24:13] <DonDiego> it's just about the basics
[21:24:19] <DonDiego> but it's well-explained
[21:24:35] <mru> I know the basics
[21:24:38] <DonDiego> supposedly it's the first in a series
[21:24:44] <spaam> Monty aka michael widenius ?
[21:24:49] <DonDiego> no
[21:24:56] <mru> not that monty
[21:24:58] <mru> nor python
[21:25:14] <spaam> ok :)
[21:25:16] <DonDiego> michael 'monty' montgomery
[21:25:19] <spaam> DonDiego: url for it ?
[21:25:21] <DonDiego> xiphmont
[21:26:04] * Kovensky should watch monty python stuff
[21:26:21] <DonDiego> http://xiph.org/video/vid1.shtml
[21:26:59] <DonDiego> mru: still i guess you can appreciate the quality or approachability of an explanation..
[21:27:27] <mru> if it doesn't teach me anything, I'd be wasting my time
[21:27:42] <mru> I hate videos
[21:29:01] <DonDiego> the video part is used very well to teach the concepts
[21:29:14] <DonDiego> maybe you are curious to see what monty looks like..
[21:29:21] <mru> I've seen pictures
[21:29:30] <DonDiego> anyway, back to work..
[21:30:42] <lu_zero> wbs: why !first_queue_time in @@ -1817,6 +1820,22 @@ static int rtsp_fetch_packet(AVFormatContext *s, AVPacket *pkt)
[21:32:34] <wbs> lu_zero: since first_queue_time is initialized to 0.. I guess that part could be skipped if using INT64_MAX or something instead
[21:36:59] <CIA-63> ffmpeg: stefano * r25214 /trunk/ (7 files in 3 dirs):
[21:36:59] <CIA-63> ffmpeg: Port MPlayer blackframe filter.
[21:36:59] <CIA-63> ffmpeg: See thread:
[21:36:59] <CIA-63> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Port MPlayer blackframe filter.
[21:36:59] <CIA-63> ffmpeg: Date: Sun, 26 Sep 2010 01:10:40 +0200
[21:37:07] <lu_zero> interesting
[21:37:41] <DonDiego> lu_zero: do you think you will be able to get to libmpeg2 some time soon?
[21:37:54] <lu_zero> uhmmm
[21:38:08] <lu_zero> as soon within a month, probably
[21:38:52] <DonDiego> cool :)
[21:39:42] <lu_zero> IFF I survive ^^;
[21:40:07] * lu_zero watched some bits of the webm video of the lesson
[21:40:26] <lu_zero> I must say that the handwritten slides are great
[21:42:35] <lu_zero> wbs: maybe queue_time != first_queue_time && queue_time - first_queue_time < 0
[21:42:52] <DonDiego> lu_zero: yes, i agree, audio, video and the slides are used very well
[21:43:31] <lu_zero> DonDiego: those kind of stuff help spreading mindshare
[21:43:40] <lu_zero> we _should_ to that as well =P
[21:43:40] <DonDiego> totally
[21:43:51] <DonDiego> ah, we should do so many things..
[21:44:00] <DonDiego> we seem to get stuck on hacking code..
[21:44:19] * lu_zero imagines mru with a troll dress teaching asm
[21:44:34] <wbs> lu_zero: uhm, that wouldn't work if one stream doesn't have  any queue at all (returning queue_time = 0, and first_queue_time already is set)
[21:45:22] <lu_zero> ok
[21:45:56] <lu_zero> I'm not exactly happy with memmove btw
[21:46:32] <wbs> well, it isn't much data, it's just the "metadata", the actual payload data is behind pointers
[21:47:20] <wbs> sure it could be a linked list, too..
[21:50:35] <lu_zero> I wonder if we could also spare the memcpy
[21:51:31] <wbs> that requires changes at quite many levels, it's a local buffer owned by the rtsp level (and reused on each received packet)
[21:51:47] <wbs> so you can't just fix it by handing over ownership of the pointer to rtpdec
[21:55:02] <bruceber> Sorry to interrupt, but if anyone familiar with multithreading of libavformat would mind checking out my recent question in #ffmpeg it would be greatly appreciated!
[21:56:51] <lu_zero> bruceber: did you have a look at ffmpeg-mt?
[22:38:35] <astrange> doesn't touch libavformat
[22:38:40] <CIA-63> ffmpeg: mru * r25215 /trunk/libavfilter/vf_yadif.c: yadif: remove unnecessary #include
[23:31:11] <lu_zero> astrange: ah