[FFmpeg-devel-irc] IRC log for 2010-08-11

[irc at mansr.com]

[00:15:05] <Dark_Shikari> mru: ping
[02:07:11] <Dark_Shikari> lu_zero: is your cortex machine hooked up for profiling?
[02:07:14] <Dark_Shikari> I'd like to profile a patch of mine
[03:13:53] <siretart> Dark_Shikari: I don't see the problem here, can you elaborate please?
[03:21:16] <Dark_Shikari> siretart: --disable-encoder=...
[03:22:10] <siretart> Dark_Shikari: oh darn, I skrewed up a merge from debian. will fix that in the next upload, thanks for notifying me
[03:22:58] <Dark_Shikari> I thought debian stopped stripping?
[03:23:51] <siretart> yes, but this package is based on an earlier version
[03:24:07] <siretart> as said, next upload will fix that
[03:24:22] <saintdev> kshishkov: what would be the simplest way to get constant 'quality' in aac?
[03:25:05] <saintdev> i'm thinking similar to constant quantizer in h264. would setting the scalefactors directly to all the same value accomplish this?
[04:08:43] <astrange> constant quantizer in h264 isn't that great
[04:08:48] <astrange> look at what lame -V does
[04:09:37] <saintdev> astrange: yeah i know, but i don't want to go through all that yet ;)
[04:13:18] <Dark_Shikari> astrange: yes, but it's simple
[04:18:13] <Compn> http://stanleyadair.com/files/She_Don_T_Know_That_I_m_16_48K_Master.dsf
[04:18:17] <Compn> whats this dsf format
[04:18:27] <Compn> looks like some kind of audio
[04:18:38] <Compn> 'file' reports 'data'
[05:03:47] <kshishkov> saintdev: yes, it should do the trick
[05:05:45] <_skal_zZzZZzz_> Yuvi? Dark? http://pastebin.org/469245
[05:06:42] <Dark_Shikari> oh, it's too large?
[05:06:48] <Dark_Shikari> yeah, looks like it.
[05:06:51] <Dark_Shikari> looks fine to me
[05:07:35] <_skal_zZzZZzz_> yeah, got dazed and confused by the naming
[05:07:39] <astrange> s->mb_width * 4 -> s->mb_width*4
[05:07:53] <astrange> not much of an insightful comment there, oh well
[05:07:56] <_skal_zZzZZzz_> ok
[05:08:49] <_skal_zZzZZzz_> astrange: where? the top comment is just a pastebin thing
[05:08:59] <astrange> i meant mine
[05:09:18] <_skal_zZzZZzz_> ooh :)
[05:15:03] <_skal_purple_> actually, with this patch, b4_stride is no longer used
[05:15:22] <_skal_purple_> and comment at 238 is obsolete
[05:16:22] <_skal_purple_> -> for next patch
[05:16:46] <astrange> is it worth storing mb_stride?
[05:16:51] <_skal_purple_> not sure even
[05:17:05] <_skal_purple_> segmentation_map uses mb_stride where mb_width would be enough, e.g.
[05:18:08] <_skal_purple_> and i'm not sure about macroblocks_base. That's a ... hmm... creative layout here
[05:19:02] <Dark_Shikari> you can reduce the size by about 1/3 if you guarantee that any given element in the topleft MB will not be overwritten until the current MB has used it
[05:19:14] <Dark_Shikari> i.e. have current MB and topleft MB share space
[05:19:20] <_skal_purple_> yep, by swapping at the last minute
[05:19:22] <Dark_Shikari> I'm not sure if that lets us keep the neighbor guarantees though
[05:19:31] <Dark_Shikari> because the beauty of the structure is twofold:
[05:19:40] <Dark_Shikari> 1) eliminates edge checks for each mb
[05:19:47] <Dark_Shikari> 2) is O(sqrt(num mbs)) in size
[05:19:56] <Dark_Shikari> well, O(width+height) really
[05:20:07] <Dark_Shikari> and 3) is trivial to address
[05:20:16] <Dark_Shikari> so it gets the best of both worlds, a ringbuffer and a full-frame buffer
[05:20:23] <Dark_Shikari> any improvement must keep these three attributes
[05:21:07] <_skal_purple_> Dark: one could cache left and top-left separately too
[05:21:12] <_skal_purple_> and be O(width)
[05:21:19] <_skal_purple_> but with extra copies here and there
[05:21:54] <_skal_purple_> and more difficult addressing
[05:22:08] <_skal_purple_> can't do the mb[-1] and mb[2] things
[05:22:10] <Dark_Shikari> yes, that loses 3)
[05:22:19] <Dark_Shikari> and results in extra copies
[05:25:17] <CIA-93> ffmpeg: skal * r24758 /trunk/libavcodec/vp8.c: fix over-allocation. confused b4_stride with mb_width.
[05:26:18] <_skal_purple_> now fate'ing http://pastebin.org/469334
[05:28:44] <_skal_purple_> err..http://pastebin.org/469338
[05:29:41] <_skal_purple_> filter_strength[] is one too many too i'd say
[05:33:57] <_skal_purple_> ... and mb_stride is now mainly used for the mb_xy passed to prefetch_motion()
[05:34:03] <_skal_purple_> through mb_xy
[05:43:20] <Dark_Shikari> then fix those
[05:43:59] <Dark_Shikari> _skal_purple_: that's actually a bug
[05:44:06] <Dark_Shikari> it should be the actual number of the MBs
[05:44:09] <Dark_Shikari> I had blindly assumed stride == width
[05:44:12] <Dark_Shikari> because that's what it is in x264
[05:44:15] <Dark_Shikari> so you should fix that too
[05:44:19] <Dark_Shikari> mb_xy should be width * y + x
[05:46:29] <_skal_purple_> sending patch
[05:48:53] <Dark_Shikari> send?  just commit it really
[05:50:19] <_skal_purple_> i like it when someone watch over my silly-self shoulder
[05:51:30] <_skal_purple_> ok, so what about http://pastebin.org/469432 ?
[05:56:05] <Dark_Shikari> make mb_stride into a local variable in the init function
[05:56:17] <Dark_Shikari> is macroblocks_base too large now?
[05:58:15] <_skal_purple_> maybe by 1 yes
[05:58:21] <_skal_purple_> but i'm unsure
[06:01:12] <Dark_Shikari> check it
[06:01:14] <Dark_Shikari> add a printf and see
[06:01:18] <Dark_Shikari> i.e. to see the last one that's accessed
[06:02:24] <_skal_purple_> k
[06:03:04] <_skal_purple_> note that we already  memset(s->macroblocks, 0, (s->mb_width + s->mb_height*2)*sizeof(*s->macroblocks)) only
[06:03:11] <_skal_purple_> that's ahint
[06:05:09] <Dark_Shikari> do remember we +1 it
[06:05:16] <Dark_Shikari> to keep the left one available
[06:05:20] <Dark_Shikari> which is zeroed at start and never zeroed again
[06:05:24] <_skal_purple_> yep
[06:06:09] <Dark_Shikari> so printf to see the last one that's accessed, etc
[06:19:00] <saintdev> kshishkov: what is the purpose of the psypreprocess ?
[06:19:21] <kshishkov> saintdev: making signal better for processing
[06:19:32] <kshishkov> it included lowpass filtering
[06:20:08] <Dark_Shikari> why not lowpass later?
[06:20:13] <Dark_Shikari> by performing a cutoff on the bands after fdct?
[06:20:26] <Dark_Shikari> oh, the psypreprocess happens after fdct, but before quant
[06:20:36] <saintdev> no
[06:20:51] <saintdev> it happens before anything
[06:21:49] <_skal_purple_> Dark: in decode_splitmvs(), i added:     if (top_mb >= s->macroblocks_base + (s->mb_width+s->mb_height*2+2)) abort();
[06:22:05] <_skal_purple_> Dark: FATE is ok and parkjoy.ivf decodes fine
[06:22:15] <Dark_Shikari> _skal_purple_: subtract 1 until it fails
[06:22:19] <kshishkov> filtered signal is better to encode than original with discarding bands
[06:22:29] <Dark_Shikari> saintdev: that's silly
[06:22:32] <Dark_Shikari> that means you do double fdcts
[06:22:33] <Dark_Shikari> for no reason
[06:22:39] <Dark_Shikari> why not lowpass after the fdct
[06:22:45] <saintdev> Dark_Shikari: no, it uses an iir filter
[06:22:48] <kshishkov> signal quality is better
[06:22:51] <_skal_purple_> Dark: now, could it just be that there's simply no SPLIMV block on the rightmost blocks, out of luck??
[06:22:59] <_skal_purple_> will try subtracting one by one
[06:23:57] <kshishkov> Dark_Shikari: hasn't your mother told you that performing frequency manipulations with FDCT'ed audio is nasty?
[06:26:08] <Dark_Shikari> kshishkov: fdct is just an fft
[06:26:18] <kshishkov> mangled FFT
[06:26:27] <Dark_Shikari> _skal_purple_: that's why I said to printf regardless of the block type
[06:45:14] <Dark_Shikari> _skal_: tl;dr make _sure_ the array is the right size, then commit
[06:45:34] <_skal_purple_> k
[06:45:49] <_skal_purple_> seems we only need width + 2*height + 1
[06:46:12] <_skal_purple_> will check
[06:46:27] <Dark_Shikari> off by one errors are evil
[06:46:41] <_skal_purple_> definitely
[06:47:10] <_skal_purple_> valgrind to the rescue
[07:16:39] <KotH> salut
[07:18:14] <elenril> салют
[07:18:38] <Tjoppen> morrn
[07:18:57] <kshishkov> god morgon
[07:23:47] <cartman> moroning guys
[07:24:03] <kshishkov> say that to thresh only
[07:24:26] * elenril knows a few tropes about this
[07:24:43] * kshishkov is not surprised
[07:25:54] <KotH> elenril: what's the percentage of all tropes that you know by heart?
[07:26:56] <elenril> KotH: http://tvtropes.org/pmwiki/pmwiki.php/Main/YouDoNOTWantToKnow
[07:27:44] <KotH> actually, i do
[07:28:45] * elenril has no idea
[07:29:30] <mru> morning
[07:33:24] <KotH> greetings mru! may the power of the arm be with you!
[07:34:05] * kshishkov thought that StrongARM was a bit out of fashion
[07:36:43] <CIA-93> ffmpeg: lucabe * r24759 /trunk/libavdevice/v4l2.c:
[07:36:43] <CIA-93> ffmpeg: Add a mapping for the V4L2_PIX_FMT_NV12 format to PIX_FMT_NV12 for
[07:36:44] <CIA-93> ffmpeg: video4linux2 devices. This is used by Sensoray Model 2253 cards.
[07:36:44] <CIA-93> ffmpeg: Patch by Pete Eberlein (pete AT sensoray DOT com)
[07:43:34] <KotH> kshishkov: as EAV once said: "starke männer sind nie passé"
[08:06:15] <lu_zero> Dark_Shikari: oprofile or something different?
[08:06:37] <Dark_Shikari> lu_zero: yes
[08:07:13] <_skal_purple_> Dark: final clean-up patch http://pastebin.org/470004 . I'll submit later today unless someone find it b0rk3d
[08:09:46] <lu_zero> let me rebuild a kernel
[08:11:46] <Dark_Shikari> _skal_purple_: looks good to me
[08:12:00] <Dark_Shikari> actually, can you get rid of line 90?
[08:12:09] <Dark_Shikari> just pass s->segmentation_map + mb_xy
[08:12:12] <Dark_Shikari> since the variable is only used in one place
[08:13:03] <_skal_purple_> k
[08:19:07] <wbs> jenk: I fixed a few issues on the rtsp server... I pushed them to http://github.com/mstorsjo/rtsp-server so you can take a look at the changes
[08:19:32] <wbs> jenk: some of them are quite clean and can probably be cherry-picked right away, but some of them probably are a bit ugly
[08:24:15] <lu_zero> [5~[6~
[08:24:52] <elenril> [7~[8~
[08:25:26] <saintdev> [9~[10~
[08:25:50] <_skal_purple_> [b~[c~
[08:26:56] <kshishkov> [0~[-1~
[08:28:29] <CIA-93> ffmpeg: skal * r24760 /trunk/libavcodec/vp8.c:
[08:28:29] <CIA-93> ffmpeg: remove b4_stride/mb_stride.
[08:28:29] <CIA-93> ffmpeg: correct mb_xy to use mb_width.
[08:28:29] <CIA-93> ffmpeg: tighten allocations.
[08:28:29] <CIA-93> ffmpeg: reduce the number of zeroing.
[08:28:44] <elenril> c-c-combo breaker
[08:29:09] <_skal_purple_> c-IA
[08:34:36] <lu_zero> Dark_Shikari: almost ready
[08:50:20] <Tjoppen> bah, VC-1 has me stumped
[08:51:02] <spaam> why?
[08:51:16] <Tjoppen> I can remux existing files and WMP will play them, but my own encodings don't work in WMP no matter what I do
[08:51:37] <Tjoppen> using mainconcept to encode, which I assume is working correctly
[08:52:37] <Tjoppen> the only thing left to try is using their ASF muxer in the sample encoder program isntead of writing a raw stream
[08:53:07] <elenril> tried asf analyzer or whatever that m$ tool is called?
[08:53:30] <Tjoppen> yeah. doesn't help much. not yet anyway
[08:53:34] <elenril> it helped me find a bug in ffmpeg's asf muxer once
[08:53:50] <Tjoppen> it doesn't like lavf's output very much
[08:54:10] <Tjoppen> muxing in AVI didn't improve things either
[08:54:37] <elenril> orly. worked for me last time i tried
[08:55:25] * elenril needs RAM badly
[08:55:53] <KotH> oh.. you're on RAM?
[08:56:03] <KotH> quite a bad addiction, imho
[08:56:03] <Tjoppen> one thing I suspect is that I'm getting the extradata the wrong way. hard to know with that retarded callback-based poorly documented API
[08:56:55] <elenril> KotH: yeah, never enough of it
[08:57:46] <kshishkov> KotH: no OS has ever evaded it :(
[08:57:47] <KotH> use CPU instead, the many pins give a much better effect
[08:58:11] <KotH> kshishkov: CP/M
[08:59:00] <astrange> http://pastebin.com/MP6n82Zz huh, the times for mt decoding 4:4:4 theora are really bad
[08:59:40] <KotH> astrange: how is it compared to normal ffmpeg?
[08:59:47] <astrange> 1 thread is the same as normal
[09:00:36] <astrange> the extra code is ~20 lines in the hot area but it must be adding way too much overhead. that or i need to look at spinlocks
[09:01:09] <Dark_Shikari> why would 4:4:4 be worse than 4:2:0?
[09:01:22] <Dark_Shikari> you don't need spinlocks
[09:01:26] <Dark_Shikari> coreavc and x264 don't use them
[09:02:23] <kshishkov> KotH: unlikely. 64kb is not enough even for Bill Gates
[09:03:39] <astrange> the wait is per-chroma superblock and there are more chroma superblocks
[09:04:24] <Dark_Shikari> it seems to me more likely that there's a bug
[09:04:39] <astrange> yes i think it's misplaced and doing a lot of duplicate lookups
[09:06:54] <astrange> iirc the hilbert coding made it hard to figure out if it was doing duplicate work, i think yuvi suggested something that i then forgot to do
[09:07:34] <Dark_Shikari> why woudl hilbert coding matter?
[09:07:39] <Dark_Shikari> hilbert coding is only within each superblock
[09:07:52] <Dark_Shikari> you do the check per superblock
[09:09:19] <Dark_Shikari> since mvs in theora are limited to 16 pixels, just assume the worst case per superblock
[09:09:22] <Dark_Shikari> done
[09:14:46] <CIA-93> ffmpeg: stefano * r24761 /trunk/libavformat/avformat.h:
[09:14:46] <CIA-93> ffmpeg: Add empty newlines between function descriptions and @params, improve
[09:14:46] <CIA-93> ffmpeg: readability.
[09:14:46] <CIA-93> ffmpeg: stefano * r24762 /trunk/libavformat/avformat.h: Nit: fix weird spacing.
[09:19:28] <astrange> it's actually per block, not per superblock, because the decoder stores mvs per fragment (== block) and it still has to look at that to see which ref frame it's using
[09:19:49] <astrange> in either case it's still weird that 4 threads has so much less system time. i'll try another os
[09:20:16] <astrange> using 16 instead of looking up the mv is certainly less code though
[09:20:45] <Dark_Shikari> that means you only need one check per _row_
[09:20:48] <Dark_Shikari> er, per superblock row
[09:22:58] <astrange> yeah, that won't save syscall overhead though. it already does an unlocked test to see if the ref has already finished that part
[09:23:22] <Dark_Shikari> why would there be a syscall?
[09:23:30] <Dark_Shikari> there's only a syscall if you have to actually wait
[09:23:31] <astrange> pthread_cond_wait is a syscall
[09:23:38] <Dark_Shikari> you don't make the syscall unless you have to wait
[09:24:11] <astrange> my profile isn't showing enough overheard in this to indicate it's just from my side
[09:24:26] <Dark_Shikari> or, better said
[09:24:29] <Dark_Shikari> if you're making the syscall when you don't have to
[09:24:31] <Dark_Shikari> you're doing it wrong
[09:24:35] <astrange> anyway i can't really say what's happening until i try a different os
[09:24:41] <Dark_Shikari> for example
[09:24:44] <Dark_Shikari> Here's what x264 does:
[09:24:46] <Dark_Shikari> void x264_frame_cond_wait( x264_frame_t *frame, int i_lines_completed )
[09:24:46] <Dark_Shikari> {
[09:24:46] <Dark_Shikari>     x264_pthread_mutex_lock( &frame->mutex );
[09:24:46] <Dark_Shikari>     while( frame->i_lines_completed < i_lines_completed )
[09:24:48] <Dark_Shikari>         x264_pthread_cond_wait( &frame->cv, &frame->mutex );
[09:24:51] <Dark_Shikari>     x264_pthread_mutex_unlock( &frame->mutex );
[09:24:53] <Dark_Shikari> }
[09:24:53] <astrange> it does not syscall until it has to
[09:24:56] <Dark_Shikari> note: it does not cond wait unless it INTENDS TO WAIT.
[09:25:08] <saste> hi all
[09:25:24] <Dark_Shikari> does your function look like that?
[09:25:25] <astrange> actually it returns before locking the mutex too
[09:25:31] <saste> how can I access upload.ffmpeg.org?
[09:25:32] <Dark_Shikari> ah.  hmm, maybe we should try that
[09:25:54] <lu_zero> Dark_Shikari: >>> Recording dev-util/oprofile in "world" favorites file...
[09:25:59] <lu_zero> oprofile available
[09:26:02] <astrange> it should be safe unless you reuse frame->i_lines_completed before later threads finish
[09:26:27] <Dark_Shikari> lu_zero: ok, moment
[09:28:33] <Dark_Shikari> http://www.x264.nl/developers/Dark_Shikari/h264_decode.tar
[09:28:39] <Dark_Shikari> contains two things
[09:28:42] <Dark_Shikari> 1) patch
[09:28:44] <Dark_Shikari> 2) test file
[09:28:57] <Dark_Shikari> most important thing I want: oprofile with patch
[09:29:03] <Dark_Shikari> would be cool too: benchmarks with and without patch
[09:29:09] <Dark_Shikari> would be cool too: oprofile without patch
[09:29:28] <Dark_Shikari> would be cool too: md5sum with and without patch (just to make sure I didn't fuck up ARM)
[09:29:36] <Dark_Shikari> I can do this myself if you give me ssh
[09:33:31] <kshishkov> s/you/mru/
[09:37:40] <Dark_Shikari> what the patch does: up to 30-35%+ faster h264 decoding.
[09:37:44] <Dark_Shikari> not yet measured on arm.
[09:39:02] <lu_zero> Dark_Shikari: do you have a public ip?
[09:39:45] <Dark_Shikari> you want to ip-lock it?
[09:39:54] <lu_zero> since that box isn't exactly accessible from outside I can let you access it using reverse ssh
[09:40:07] <Dark_Shikari> 70.181.124.141 apparently.
[09:40:12] <Dark_Shikari> May or may not be dynamic.
[09:41:53] <lu_zero> user/pass?
[09:42:03] <Dark_Shikari> er.... what?
[09:42:07] <Dark_Shikari> user/pass to what?
[09:42:30] <lu_zero> reverse ssh works this way
[09:42:33] <KotH> to your bank account, what else? :)
[09:42:39] <lu_zero> I connect to your public host using
[09:42:41] <lu_zero> ssh -L 22:localhost:2222 70.181.124.141
[09:42:42] <Dark_Shikari> er.... I'm on bloody windows
[09:42:44] <Dark_Shikari> I don't run ssh
[09:43:03] <lu_zero> meh
[09:43:13] <lu_zero> let's jump two places then ^^
[09:43:14] <Dark_Shikari> I thought I ssh'd into that box a while ago somehow?
[09:44:32] * KotH hands lu_zero one of his public ips
[09:46:04] <lu_zero> KotH: =)
[09:46:28] <lu_zero> give me your public key ^^
[09:46:36] <lu_zero> bridge done
[09:46:56] <saintdev> i'll take your private key :P
[09:47:30] <lu_zero> saintdev: =P
[09:58:25] <Tjoppen> kshishkov: how much do you know about the vc1 extradata format?
[09:58:28] <Dark_Shikari> mru: so what's the standard arm configure line?
[09:58:33] <Dark_Shikari> it's not configuring with neon by default
[09:58:36] <Dark_Shikari> --cpu=cortext-a8 and that's it?
[09:58:43] <Dark_Shikari> cortex-a8 that is
[09:58:51] <Tjoppen> I just got the bastard to work. the fix: prepend one 0x25 byte
[09:59:33] <Tjoppen> the lavc parser thing skips it, but wmp appearently requires it
[10:00:34] <Tjoppen> lunch, but do leave a comment
[10:00:38] <Dark_Shikari> NEON enabled              no
[10:00:39] <Dark_Shikari> wtf?
[10:00:44] <Dark_Shikari> with --cpu=cortex-a8
[10:03:36] <janneg> Dark_Shikari: you probably need --extra-cflags='-mfpu=neon -mfloat-abi=softfp'
[10:03:45] <janneg> depending on the ssystem
[10:05:21] <kshishkov> Tjoppen: it's for VC-1 extradata in ASF indeed. Dunno what it is though
[11:06:05] <Tjoppen> kshishkov: ok. time to read the spec then
[11:06:27] <Tjoppen> luckily I have most of the SMPTE specs
[11:06:32] <kshishkov> Tjoppen: it's unlikely you'll find it there
[11:06:42] <kshishkov> it's specific to WMV9/WVC1
[11:06:46] <kshishkov> not ASF or VC-1
[11:06:53] <Tjoppen> :(
[11:06:57] <CIA-93> ffmpeg: stefano * r24763 /trunk/ (10 files in 2 dirs):
[11:06:58] <CIA-93> ffmpeg: Separate video specific BufferRef properties into VideoProps.
[11:06:58] <CIA-93> ffmpeg: Define a new struct AVFilterBufferRefVideoProps and add a type field
[11:06:58] <CIA-93> ffmpeg: to AVFilterBufferRef.
[11:06:58] <CIA-93> ffmpeg: Video specific properties in AVFilterBufferRefVideoProps are now
[11:06:58] <CIA-93> ffmpeg: referred to by *video pointer in AVFilterBufferRef.
[11:06:59] <CIA-93> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram smeenaks->ucsd.edu.
[11:07:09] <Tjoppen> hack it is then
[11:07:20] <kshishkov> yes!
[11:11:16] <CIA-93> ffmpeg: stefano * r24764 /trunk/doc/APIchanges: Add APIchanges entry after AVFilterBufferRef changes in r24763.
[11:16:16] <Tjoppen> kshishkov: would that be something that belongs in the asf muxer?
[11:16:22] <Tjoppen> or on my end?
[11:16:40] <Tjoppen> this also applies to avi btw
[11:19:21] <Tjoppen> right, ff_put_bmp_header()
[11:45:44] <CIA-93> ffmpeg: stefano * r24765 /trunk/ (7 files in 3 dirs):
[11:45:44] <CIA-93> ffmpeg: Change avfilter_open() signature, from:
[11:45:44] <CIA-93> ffmpeg: AVFilterContext *avfilter_open(AVFilter *filter, const char *inst_name);
[11:45:44] <CIA-93> ffmpeg: to:
[11:45:44] <CIA-93> ffmpeg: int avfilter_open(AVFilterContext **filter_ctx, AVFilter *filter, const char *inst_name);
[11:45:44] <CIA-93> ffmpeg: This way it is possible to propagate an error code telling the reason
[11:45:45] <CIA-93> ffmpeg: of the failure.
[11:50:02] <CIA-93> ffmpeg: stefano * r24766 /trunk/doc/APIchanges: Add APIchanges entry after avfilter_open() change in r24765.
[11:50:35] <CIA-93> ffmpeg: stefano * r24767 /trunk/doc/APIchanges: Fix typo.
[12:14:20] <Dark_Shikari> before my patch: http://pastebin.org/471132
[12:14:24] <Dark_Shikari> after: http://pastebin.org/471133
[12:14:36] <Dark_Shikari> fun challenge: figure out what happened to ff_put_h264_chroma_mc8_neon.
[12:16:00] <KotH> it went bonkers?
[12:19:02] <kshishkov> it's not called?
[12:20:42] <Dark_Shikari> yeah, but the question is how I avoided calling it ;)
[12:21:20] <kierank> you somehow managed to do it with luma?
[12:21:36] <Dark_Shikari> Slightly right.
[12:22:55] <Dark_Shikari> hint: if your MVs are fullpel only, this means your chroma MVs are hpel at most
[12:23:01] <Dark_Shikari> bilinear hpel... hmm, where have seen that before.
[12:23:07] <kshishkov> mpeg-2?
[12:23:17] <Dark_Shikari> 62        0.6212  ffmpeg_g                 ff_put_pixels8_xy2_neon
[12:23:17] <Dark_Shikari> 61        0.6112  ffmpeg_g                 ff_put_pixels8_x2_neon
[12:23:17] <Dark_Shikari> 54        0.5410  ffmpeg_g                 ff_put_pixels8_y2_neon
[12:23:20] <Dark_Shikari> indeed ;)
[12:24:08] <kshishkov> so with halving MVs you halve MPEG-number as well ?
[12:30:09] <Dark_Shikari> kshishkov: lol
[12:30:15] <Dark_Shikari> hahaha
[12:30:51] <kshishkov> but replacing calls with something simpler by definition is very nice trick indeed
[12:31:03] <Dark_Shikari> and yet it's bit-exact.
[12:31:20] <Dark_Shikari> and yet like 4-5x faster.
[12:31:32] <KotH> overall or just that function?
[12:32:03] <Dark_Shikari> that function
[12:32:08] <Dark_Shikari> overall, 37% faster on ARM, 28% on x86
[12:32:14] <Dark_Shikari> (from all my changes total)
[12:32:22] <Dark_Shikari> Probably more when the memcpy/etc are removed
[12:32:27] <KotH> cool
[12:32:28] <Dark_Shikari> as those aren't part of the decoder, but rather part of ffmpeg
[12:32:46] * KotH makes a note to give Dark_Shikari some chocolate when he comes to LT
[12:33:08] <kshishkov> KotH: it's more probable for you to come to LT than him
[12:33:28] <kierank> are there any good events happing in september/october?
[12:33:34] <Dark_Shikari> correction
[12:33:36] <KotH> kshishkov: given that i've a probability near to 100%, i'd say that is not so bad
[12:33:36] <Dark_Shikari> 49% faster
[12:33:37] <kierank> happening*
[12:34:09] <KotH> how about a ad hoc ffcon in vienna early sept?
[12:34:18] <kshishkov> KotH: nope, I haven't spotted you in OGP crew this LT.
[12:34:25] <janneg> KotH: it's more like 0%
[12:34:31] <KotH> ^^'
[12:34:40] <kierank> how expensive is vienna?
[12:34:40] <janneg> for the two last years
[12:34:49] <kshishkov> KotH: in Wien? hosted by MN? Good!
[12:34:55] <KotH> janneg: you've a biased sampling base
[12:35:22] <KotH> kshishkov: i'd be glad if MN would apear, it would be a wonder if he'd host it
[12:35:58] <kierank> a security detail will need to be organised
[12:36:03] <kierank> for michael
[12:36:07] * KotH has to see whether he can free up a weekend and go to vienna
[12:36:28] <KotH> but currently, all i can do is to stay awake
[12:38:48] * kierank would like to visit vienna
[12:39:20] <Dark_Shikari> kierank: lol
[12:39:54] * kshishkov would like to visit Vienna but he'd be fine with Wien too
[12:42:35] <kshishkov> from all capitals I've seen so far I dislike only Oslo and Berlin
[12:43:13] <kierank> what is bad about those capitals kshishkov
[12:44:06] <kshishkov> Oslo has bad taste in architecture, lot of garbage on main streets and very wobbly paving
[12:45:05] <kshishkov> Berlin looks like Kiev (which I also dislike but it serves for different country than .ua)
[12:45:47] <kshishkov> and I wonder why they use midgets on traffic lights
[12:47:21] <kierank> midgets?
[12:47:47] <kshishkov> http://en.wikipedia.org/wiki/File:Ampelmann.svg
[12:48:03] <kshishkov> and http://en.wikipedia.org/wiki/File:Ampelmaenner.jpg
[12:48:12] <kierank> we have that on pedestrian crossings
[12:48:42] <kshishkov> in the same form?
[12:49:24] <kierank> no, a bit different
[12:51:08] <kshishkov> same story with "road crossing" signs in Oslo - it's definitely drunk man crossing the road
[12:51:20] <KotH> kshishkov: if you dislike berlin, never go to brussles
[12:51:52] <kshishkov> KotH: I suspect as much yet I should go there once in lifetime
[12:52:45] <kshishkov> http://codecs.multimedia.cx/wp-content/uploads/2010/03/sign.jpg
[12:53:27] <kierank> reminds me of this: http://www.abbeyroad.com/visit/
[12:53:50] <KotH> kshishkov: swiss?
[12:54:04] <kshishkov> KotH: Norwegian
[12:54:48] <KotH> kshishkov: a typical view of brussels: http://hardwarebug.org/files/img_3085.jpg
[12:55:26] <kshishkov> KotH: thanks, if I ever get Ukraine-sick, I'd go either there or to Paris
[12:55:52] * KotH wonders if he could find that spot again
[12:56:04] <kshishkov> just follow your nose :)
[12:56:05] * KotH should have written its coordinates somewhere
[12:56:08] <KotH> :-)
[12:56:15] <KotH> we found it that way :)
[12:56:35] <kierank> reminds me when i went to a shopping arcade in geneva
[12:56:38] <kierank> looked a bit like that
[12:56:51] <kshishkov> Basle was rather nice though
[12:57:27] <kshishkov> KotH: my university had canteens placed next (or opposite) to toilets, so you can always find both by smell
[13:00:37] * cartman strikes Belgium off the countries-to-work-in list
[13:01:13] * kshishkov tries to remember what Douglas Adams said about Belgium
[13:01:31] <kshishkov> cartman: it's for cushy Euro-governmental jobs anyway
[13:01:58] <cartman> yeah pay is not good too
[13:02:39] * kshishkov wants to be payed in SEK though
[13:04:17] * cartman accepts any valid currency
[13:04:29] <kshishkov> MTL?
[13:04:41] <kshishkov> (aka millons of Turkish Liras)
[13:05:19] <cartman> we striked 6 zeros out of the money now
[13:07:17] <kierank> that's a sure fire way to solve inflation
[13:07:25] <kshishkov> nope
[13:07:36] <kshishkov> it's just a way to save few zeroes
[13:07:46] <cartman> saves you some bytes
[13:07:57] <KotH> cartman: brussels is as expensive as zürich, but not as nice
[13:08:15] <KotH> cartman: and their chocolate is worse then german's
[13:08:34] <cartman> lol
[13:08:40] <cartman> belgium chocolate is fine
[13:08:50] <KotH> bäh.. you've no taste!
[13:09:57] <kshishkov> cartman: I thought you'd mention local brand. Or does Turkey produce chewing gum only?
[13:10:23] <cartman> kshishkov: we export Swiss chocolate here
[13:10:28] <cartman> import*
[13:10:30] <cartman> rather ;)
[13:10:41] <KotH> kshishkov: turkish chocolate tastes exactly the same as japanese chocolate
[13:10:49] <kshishkov> cartman: I think you do both :P
[13:10:54] <KotH> cartman: a friend in .jp even found "bonibon" there!
[13:11:02] <kshishkov> KotH: Japanese chocolate is not that bad
[13:11:05] <cartman> KotH: lol
[13:11:10] <cartman> bonibon is cool for sure
[13:11:17] <KotH> juup
[13:11:44] <KotH> kshishkov: you've no tast either... but that's expected from someone who grew up with cacao surogates
[13:12:13] <cartman> I like Guylian
[13:13:27] <kshishkov> KotH: I have. And guess what country was "the best friend" to most countries where cocoa is grown?
[13:15:45] <kshishkov> KotH: and unlike you I don't have obsession about chocolate. Cheeses are different thing though.
[13:15:49] <KotH> kshishkov: .ru? ;)
[13:16:00] <KotH> kshishkov: no good cheese in .be either
[13:17:05] <KotH> kshishkov: if you like different kinds of cheese, i can recomend going to .tr
[13:17:11] <kshishkov> KotH: there are less good cheeses in .ru than holes in Gruyere
[13:17:21] <KotH> kshishkov: taste as good as southern french or swiss cheese, but a lot more variety
[13:17:22] <kshishkov> and I like Swedish chesses
[13:17:26] <kshishkov> *cheeses
[13:17:59] <kshishkov> and I'd rather go to Berling again for pleasure than to Turkey
[13:19:08] <thresh> isnt Germany a Turkish colony anyway?
[13:19:17] <kshishkov> thresh: it is
[13:49:59] <pJok> kshishkov, most swedish cheeses are danish ;)
[13:50:51] <Tjoppen> there's västerbottenost at least
[13:54:44] <spaam> and kshishkov likes that one ;;)
[13:56:17] <KotH> somehow it sounds like appenzell cheese
[13:56:37] * KotH will bring some to LT next year... and his gas mask
[13:57:01] <spaam> time to bring surströming also? ;)
[14:02:28] <lu_zero> surströming ?
[14:03:26] <spaam> http://en.wikipedia.org/wiki/Surstr%C3%B6mming
[14:03:31] <pJok> the EU thinks surströmning should be illegal
[14:04:03] <Tjoppen> has more to do with the dioxin in the baltic sea IIRC
[14:04:08] <spaam> some ppl think that it smells to much ;S
[14:07:16] <lu_zero> you shouldn't open it under water anyway?
[14:08:20] <Tjoppen> usually you open it some distance away, and try not to get your clothes sprayed
[14:12:04] <KotH> "which explains why the dish is often eaten outdoors"
[14:12:06] <KotH> wtf?
[14:12:32] <lu_zero> KotH: the smell is _quite_ strong
[14:12:58] <KotH> it'd rather say, that the smell is toxic, from what i read
[14:13:06] <spaam> haha noo
[14:14:14] <lu_zero> garum apparently would be interesting
[14:14:17] <KotH> i've eating quite my share of smelly stuff, but none of it was ever considered unsafe to be eaten indoors
[14:14:18] <lu_zero> as well
[14:14:37] <Tjoppen> KotH: not unless you want your house to smell like surströmming for the rest of the year
[14:15:24] <Tjoppen> an opened can be smelled across an entire block, if not further
[14:15:45] <KotH> wtf..
[14:16:01] <KotH> take a can with you to next LT and we'll try to open it somewhere
[14:16:50] * KotH will watch from a point at least 10km away, in the opposite direction of the wind
[14:17:32] <Tjoppen> classic school prank is to place an open can in the ventilation inlet
[14:17:37] <KotH> lol
[14:19:44] <CIA-93> ffmpeg: stefano * r24768 /trunk/libavcodec/ (avcodec.h imgconvert.c):
[14:19:45] <CIA-93> ffmpeg: Add av_picture_data_copy() and reimplement av_picture_copy() as a
[14:19:45] <CIA-93> ffmpeg: wrapper of it.
[14:19:45] <CIA-93> ffmpeg: The new function is more generic, and does not depend on the
[14:19:45] <CIA-93> ffmpeg: definition of the AVPicture struct.
[14:19:45] <CIA-93> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram s + "meenakshisundaram".substr(0, 7) + "@ucsd.edu".
[14:23:07] <CIA-93> ffmpeg: stefano * r24769 /trunk/doc/APIchanges: Add APIchanges entry after av_picture_data_copy() addition.
[14:23:21] <lu_zero> j0sh: poing
[14:35:54] <merbzt> Dark_Shikari: for x264 is intel or amd better ?
[14:39:07] <CIA-93> ffmpeg: stefano * r24770 /trunk/libavformat/avformat.h:
[14:39:08] <CIA-93> ffmpeg: Fix reference to a wrong parameter name in the metadata API functions
[14:39:08] <CIA-93> ffmpeg: doxies.
[14:39:08] <CIA-93> ffmpeg: stefano * r24771 /trunk/libavformat/avformat.h:
[14:39:08] <CIA-93> ffmpeg: Add documentation for the pm parameter of the av_metadata_set*
[14:39:08] <CIA-93> ffmpeg: functions.
[14:44:15] <lu_zero> merbzt: which intel and which amd?
[14:48:24] <merbzt> the cheapest way to encode 40 channels
[14:50:32] <CIA-93> ffmpeg: stefano * r24772 /trunk/doc/ffmpeg-doc.texi:
[14:50:32] <CIA-93> ffmpeg: Extend and clarify documentation for -ac ffmpeg option.
[14:50:32] <CIA-93> ffmpeg: Fix roundup issue #2061.
[14:52:23] <lu_zero> merbzt: do you have a mean to try an i7 vs an opteron?
[14:53:37] <lu_zero> the opterons are usually cheaper
[14:53:45] <twnqx> i7 920 wins against 2 2354
[14:53:50] <twnqx> 4 8354 beat the i7.
[14:54:07] <lu_zero> twnqx: what's that number?
[14:54:18] <kshishkov> model
[14:54:21] <twnqx> Opteron 2354 / Opteron 8354
[14:54:59] <twnqx> but the quad quadcore opteron doesn't win by as much as you'd expect, at some point threading doesn't max the 16 cores
[14:55:44] <lu_zero> 40 channels means that you don't care much
[14:56:02] <twnqx> and the opterons are old, they don't have all the sse extensions
[14:59:58] <lu_zero> there are newer opterons =P
[15:02:35] <Honoome> but none has sse4.{1,2}... rather have sse4{a,b}
[15:14:27] <BBB___> merbzt: intel, because that's what he develops on ;)
[15:16:20] <merbzt> true
[15:22:05] <lu_zero> still you want to optimize for (cost+electricity cost)/encoder-time ?
[15:26:36] <CIA-93> ffmpeg: stefano * r24773 /trunk/ (4 files in 2 dirs):
[15:26:37] <CIA-93> ffmpeg: Resize data and linesize in AVFilterBufferRef to 8.
[15:26:37] <CIA-93> ffmpeg: This is required to make AVFilterBufferRef able to contain also audio
[15:26:37] <CIA-93> ffmpeg: data, required by audio filtering integration.
[15:26:37] <CIA-93> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram smeen?ks at ucsd.ed?.
[15:30:28] <CIA-93> ffmpeg: stefano * r24774 /trunk/doc/APIchanges: Add APIchanges entry for the AVFilterBufferRef changes in r24773.
[15:39:41] <CIA-93> ffmpeg: stefano * r24775 /trunk/libavfilter/avfilter.c:
[15:39:42] <CIA-93> ffmpeg: Set type on buffer in get_video_buffer().
[15:39:42] <CIA-93> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram reverse("skaneems") + "@ucsd.edu".
[16:01:02] <BBB> how do I know if my build is 32- or 64-bit?
[16:01:08] <wbs> on os x?
[16:01:15] <wbs> file <binary> will tell you at least
[16:01:34] <BBB> oh cool
[16:01:35] <BBB> it is
[16:02:53] <J_Darnley> It must be either 32 or 64 bit
[16:03:08] <wbs> J_Darnley: not on os x, it can be both ;P
[16:03:21] <J_Darnley> qubits huh?
[16:04:03] <wbs> fat binaries
[16:21:11] <BBB> does our matroska muxer support streaming output?
[16:21:14] <BBB> it doesn't right?
[16:21:32] <BBB> "ffmpeg: Mach-O 64-bit executable x86_64" <- \o/
[16:21:43] <jai> BBB: it does iirc
[16:21:48] <BBB> really?
[16:21:57] <BBB> there's a thread on libav-user saying it doesn't work
[16:22:01] <jai> hmm
[16:22:08] <BBB> who wrote the muxer?
[16:22:14] <jai> Yuvi
[16:22:52] <jenk> hy
[16:23:09] <CIA-93> ffmpeg: stefano * r24776 /trunk/libavfilter/avfilter.h:
[16:23:09] <CIA-93> ffmpeg: Apply misc cosmetics: add empty newlines for separating function
[16:23:09] <CIA-93> ffmpeg: declarations and fix weird indent.
[16:24:51] <BBB> Yuvi: do you know more about http-streambility of matroska-muxer-content?
[16:24:52] <jenk> wbs:
[16:24:55] <jenk> im looking at these commits
[16:26:35] <wbs> jenk: mmh?
[16:27:25] <jenk> added an RTCP listener? ha
[16:27:37] <wbs> yeah, that one is not pretty, but made it work at least
[16:27:42] <wbs> you already listen on the RTCP port
[16:27:46] <jenk> http://github.com/mstorsjo/rtsp-server/commit/a494abcc05280575cdf5d5315de6437b9b52e205
[16:28:00] <jenk> oh nvm i see
[16:28:10] <lu_zero> BBB: depends
[16:28:41] <lu_zero> BBB: the matroska produced da ffmpeg have 2 headers set
[16:28:48] <lu_zero> one at the end
[16:29:10] <wbs> jenk: yeah, that one doesn't have anything with rtcp to do.. if you're on a machine with multiple public IPs, say A and B, and you're listening on 0.0.0.0
[16:29:15] <jenk> yeah
[16:29:19] <jenk> http://github.com/mstorsjo/rtsp-server/commit/f70763ceb45dc0513f5c6c54d90059f663754d3e looks sketch tho
[16:29:25] <lu_zero> you can look at mkv_write_header,
[16:29:31] <jenk> line 107
[16:29:36] <wbs> jenk: if a client connects to IP B, it wants get the packets back from IP B too, not suddenly from IP A
[16:29:36] <jai> BBB: looking at http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=9acbdf2236b i guess it cannot
[16:29:45] <lu_zero> wbs: same issue as with feng?
[16:29:48] <wbs> lu_zero: yeah
[16:29:51] <jenk> wait, you are binding to one port and connecting to another?
[16:29:56] <jenk> this is a litle confusing
[16:30:17] <wbs> yes, it first binds to the one on the local machine, chosen with next_rtp_start_port
[16:30:31] <jenk> does the RTCP listener ever get cleaned up?
[16:30:32] <wbs> then connects to the destination port that the client supplied
[16:30:52] <wbs> don't know, the auto cleanup doesn't seem to work on my system
[16:31:16] <wbs> without that bind, the packets to the client gets sent from any local port
[16:31:32] <wbs> and the client doesn't know from where to expect them (and valgrind can't follow the rtp packets properly)
[16:31:36] <wbs> uh, wireshark, not valgrind ;P
[16:32:13] <jenk> ok
[16:32:21] <wbs> and you already listen on RTCP packets in your code originally
[16:32:35] <jenk> well, need to get the socket shutdowns to work
[16:32:35] <wbs> you just don't open any port for sending them (and send them back on the RTP port instead of on the RTCP port)
[16:32:38] <jenk> i think that may be broken
[16:32:43] <jenk> i'm gonna pull your changes
[16:32:50] * lu_zero heads home again
[16:32:54] <jenk> yeah
[16:33:08] <jenk> should the RTCP packets be passed though? im not sure what to do with them
[16:33:28] <wbs> but the way of determining which socket to send on (looking at the value of byte 1) is ugly, instead you should do it depending on which port the packet was received on
[16:33:37] <wbs> yeah, they should be passed through, they're essential for syncing the streams
[16:33:40] <BBB> jai: that commit should make it work then ?
[16:33:45] <BBB> or is that not in trunk yet?
[16:33:50] <lu_zero> wbs: btw the way to produce hinted file with ffmpeg had been documented?
[16:33:55] <jenk> but what if a few people are sending different RTCP data, will that fuck it up?
[16:34:09] <lu_zero> jenk: uh?
[16:34:10] <jenk> you should be able to compare sockets i think
[16:34:20] <wbs> jenk: in RTP, all streams timestamps start at a random offset, then you sync them together using the RTCP timestamps
[16:34:23] <lu_zero> each client will send different info
[16:34:32] <wbs> jenk: this only forwards RTCP from broadcaster to the clients watching
[16:34:38] <lu_zero> wbs: rtcp/rtp-info/other-means
[16:34:52] <jenk> okay
[16:34:57] <wbs> lu_zero: yeah, that can be done too, but a rtsp server that bounces streams like this _should_ forward the RTCP sender reports
[16:35:02] <jenk> i know zero about RTCP
[16:35:12] <wbs> jenk: the RTCP packets from the clients watching aren't sent anywhere
[16:35:18] <lu_zero> wbs: that's something feng is lacking completely
[16:35:20] <jenk> i thought it was for clients to report stuff
[16:35:36] <wbs> lu_zero: yeah, and jenk has written a complete rtsp server in perl in just a few lines, that has that feature (and only that feature..)
[16:35:41] <wbs> jenk: it's for both
[16:35:52] <jenk> wbs: http://github.com/revmischa/rtsp-server/commits/master
[16:36:04] <jenk> pulled
[16:36:19] <wbs> jenk: if you have a peer-to-peer RTP session, both communicate with each other using that
[16:36:33] <jenk> well it thinks its peer to peer
[16:36:36] <wbs> jenk: the sender sends sender reports, saying that RTP timestamp X corresponds to real time NTP time Y
[16:36:37] <lu_zero> wbs: I'll copy him =P
[16:36:50] <jenk> oh i c
[16:36:56] <jenk> neato
[16:37:04] <jenk> what happens if the clocks are off?
[16:37:14] <wbs> jenk: but the peer will reply with a receiver report, saying that "i've gotten x bytes from you so far"
[16:37:16] <jenk> or is it relative
[16:37:20] <lu_zero> (actually the origin of this was because other developers weren't that keen on implementing that and thus we got flux to replace that in a pretty nonstandard way...)
[16:37:25] <lu_zero> well
[16:37:27] <lu_zero> shame on me
[16:37:41] <jenk> lu_zero: http://github.com/revmischa/rtsp-server
[16:37:54] <wbs> so in a peer-to-peer RTP session, the sender actually can notice that the peer isn't getting all data, and lower the bitrate of the stream or whatever :-)
[16:38:06] <jenk> yeah
[16:38:08] <wbs> but for a broacast stream to many receivers, you can't really do that
[16:38:20] <wbs> so all the RTCP data from the upstream source should be forwarded to the listening clients
[16:38:23] <jenk> right, that's whta i was wondering
[16:38:26] <jenk> makes sense
[16:38:38] <wbs> but whatever RTCP data the clients are sending back to the server (which is their peer) is simply ignored
[16:39:00] <wbs> if you don't want to do anything more fancy with it, but simply dropping it is good enough at the current level of functionality at least
[16:39:07] <lu_zero> jenk: I had a look before hopefully I'll make an ebuild for gentoo once it's deem releasable ^^
[16:39:07] <wbs> don't know if DSS does anything with it
[16:39:17] <jenk> gentoo lol
[16:39:36] <jenk> lu_zero: just need to get socket cleanups working right
[16:39:42] <lu_zero> jenk: =)
[16:39:52] <jenk> people still use gentoo? why?
[16:40:18] <wbs> jenk: and regarding the NTP times, the clocks don't really need to be in sync, they just need to be in sync for all streams within the video
[16:40:36] <wbs> so as long as audio and video is sent from the same machine, only their relative values matter
[16:40:49] <jenk> ok
[16:40:51] <wbs> but as with everything in RTP, it's specced so it can be used in many environments...
[16:41:05] <wbs> imagine a IP-networked microphone and video camera, both sending out RTP packets themselves
[16:41:30] <wbs> then they just need to be synced with NTP, and you're able to sync the two streams together at the receiver
[16:42:00] <wbs> so you can add and remove new media to the same "presentation" as you go, as long as all the sending equipment is NTP synced among each  other
[16:42:26] <wbs> lu_zero: regarding hinting, don't think i've documented it anywhere, but it's simply -fflags rtphint when using any mov/mp4/3gp muxer
[16:42:28] <jenk> if i was to make a client for this server, i'd need to periodically send out a udp packet on the port i'm expecting data on right? like once every 30 seconds?
[16:42:52] <jenk> so that the firewall will do "stateful" udp?
[16:42:58] <wbs> don't know actually
[16:43:07] <wbs> in libavformat we just send a packet at upstart
[16:43:19] <jenk> cuz otherwise its impossible to receive udp packets behind a firewall
[16:43:24] <wbs> and it has worked well enough for me, but on the other hand, i've just been doing simple testing :-)
[16:43:31] <lu_zero> jenk: and udp works and does not
[16:43:34] <wbs> not really any actual longterm use
[16:43:36] <jenk> i read that some routers need a packet once a minute
[16:43:45] <jenk> lu_zero: depends on the router though right?
[16:43:46] <wbs> it's all up to the router implementer :-)
[16:44:22] <wbs> for some it may be enough that the session is initialized with a packet from you at the start, then only packets coming from the other end, with those packets keeping the firewall rule alive
[16:44:29] <lu_zero> jenk: seq-packet protocols might work better or not depending on the actual router
[16:44:36] <lu_zero> (dccp and sctp to name)
[20:19:40] <Dark_Shikari> merbzt: i7 > phenom yes.  but phenom is pretty fast
[21:10:47] <merbanan> ok
[21:35:06] <Dark_Shikari> someone please approve my email to ffmpeg-devel
[21:35:12] <Dark_Shikari> it got moderated because my patch is too large
[21:35:13] <Dark_Shikari> lol
[21:35:41] <Kovensky> lol
[21:43:22] <spaam> Dark_Shikari: did you have ascii art in the patch?
[22:10:41] <Yuvi> BBB: It should work, but I've only tested pipe output
[22:28:26] <CIA-93> ffmpeg: rbultje * r24777 /trunk/libavformat/mmst.c: Use FFALIGN() in mmst.c where appropriate. Noticed by Benoit Fouet.
[22:43:02] <J_Darnley> Is there a good reason why -maxrate and -minrate are video only options?
[22:43:48] <Dark_Shikari> because CBR audio is usually hard-CBR and most encoders don't support anything more versatile
[22:44:16] <J_Darnley> But then why set min and max rates in libvorbis when they are always zero?
[22:44:41] <J_Darnley> Infact, libvorbis is the only audio encoder to use them
[22:44:48] <CIA-93> ffmpeg: rbultje * r24778 /trunk/libavformat/mmst.c:
[22:44:48] <CIA-93> ffmpeg: Extract fields that are to be shared between MMST/MMSH into a common struct,
[22:44:48] <CIA-93> ffmpeg: MMSContext. The other MMST-specific members go into MMSTContext.
[22:44:48] <CIA-93> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[22:44:50] <BBB> wbs: did you commit rtpdec_latm/mp4a?
[22:44:57] <Dark_Shikari> they can be set via the api
[22:45:50] <J_Darnley> Is it only ffmpeg with this limit then?
[22:49:50] <Dark_Shikari> yes
[22:49:59] <Dark_Shikari> you can set them in the avcodeccontext
[22:51:54] <CIA-93> ffmpeg: rbultje * r24779 /trunk/libavformat/ (Makefile mmst.c):
[22:51:55] <CIA-93> ffmpeg: Move functions and structs shared between MMSH and MMST into their own file,
[22:51:55] <CIA-93> ffmpeg: mms.c. Patch by Zhentan Feng <spyfeng gmail com>.
[23:46:01] <CIA-93> ffmpeg: rbultje * r24780 /trunk/libavformat/mms.c: Add missing mms.c from r24779.