[FFmpeg-devel-irc] IRC log for 2010-02-28

[irc at mansr.com]

[01:44:36] <CIA-92> ffmpeg: cehoyos * r22096 /trunk/libavformat/apetag.c: Include apetag.h which contains the prototype for ff_ape_parse_tag().
[01:52:02] <CIA-92> ffmpeg: cehoyos * r22097 /trunk/libavformat/mov.c: Make mp4_read_descr static: It is only used inside libavformat/mov.c.
[02:05:24] <CIA-92> ffmpeg: cehoyos * r22098 /trunk/libavformat/avc.c: Include avc.h from avc.c: It contains several prototypes.
[02:33:07] <CIA-92> ffmpeg: cehoyos * r22099 /trunk/libavutil/sha.c: Include sha1.h from sha.c: It contains several prototypes.
[02:42:10] <CIA-92> ffmpeg: cehoyos * r22100 /trunk/libavcodec/mpeg4video_parser.c: Include mpeg4video.h: Needed for declaration of ff_mpeg4_decode_picture_header.
[02:45:28] <CIA-92> ffmpeg: cehoyos * r22101 /trunk/libavcodec/h263_parser.c:
[02:45:28] <CIA-92> ffmpeg: Include h263_parser.h: It contains the prototype for
[02:45:28] <CIA-92> ffmpeg: ff_h263_find_frame_end().
[02:54:26] <pentanol> which func I should use for start playing rtsp stream? ff_rtsp_read_reply or rtsp_read_reply
[02:55:38] <pentanol> oops ff_rtsp_read_reply vs rtsp_read_play ?
[02:56:29] <pentanol> while compilation my app I've got (.text+0x125): undefined reference to `rtsp_read_play'
[02:56:59] <pentanol> and here, really nothing about it readelf -a /usr/local/ffmpeg-dev/lib/libavformat.so.52.54.0 | grep -i rtsp_read_play
[03:03:16] <CIA-92> ffmpeg: cehoyos * r22102 /trunk/libavcodec/vp3.c: Remove declaration of unused variables.
[03:27:08] <CIA-92> libswscale: cehoyos * r30787 /trunk/libswscale/utils.c: Make sws_dcVec static: It is only used inside libswscale/utils.c.
[03:28:02] <CIA-92> ffmpeg: cehoyos * r22103 /trunk/libavcodec/mpegaudiodecheader.c:
[03:28:02] <CIA-92> ffmpeg: Include mpegaudiodecheader.h: It contains the prototype for
[03:28:02] <CIA-92> ffmpeg: ff_mpegaudio_decode_header().
[03:40:01] <CIA-92> ffmpeg: cehoyos * r22104 /trunk/libavcodec/atrac.c:
[03:40:01] <CIA-92> ffmpeg: Include atrac.h: It contains the prototypes for atrac_generate_tables()
[03:40:01] <CIA-92> ffmpeg: and atrac_iqmf().
[03:42:48] <CIA-92> ffmpeg: cehoyos * r22105 /trunk/libavcodec/msrledec.c: Include msrledec.h: It contains the prototype for ff_msrle_decode().
[03:53:03] <CIA-92> ffmpeg: cehoyos * r22106 /trunk/libavcodec/imgconvert.c:
[03:53:03] <CIA-92> ffmpeg: Include internal.h and imgconvert.h, they contain the prototypes for the
[03:53:03] <CIA-92> ffmpeg: following functions:
[03:53:03] <CIA-92> ffmpeg: ff_is_hwaccel_pix_fmt(), ff_set_systematic_pal(), ff_fill_linesize(),
[03:53:03] <CIA-92> ffmpeg: ff_fill_pointer(), ff_get_plane_bytewidth()
[04:00:08] <CIA-92> ffmpeg: cehoyos * r22107 /trunk/libavformat/rtpproto.c:
[04:00:08] <CIA-92> ffmpeg: Include rtpdec.h, it contains prototypes for the following functions:
[04:00:08] <CIA-92> ffmpeg: rtp_set_remote_url(), rtp_get_local_port(), rtp_get_file_handles()
[04:50:00] <peloverde> Is it legal to use pshufd with floating point code?
[04:50:30] <mru> x87 float?
[04:50:47] <peloverde> sse float
[04:50:55] <mru> can't see why not
[04:51:48] <peloverde> It seems odd that some shuffling instructions are ostensibly for int32 and others are for float
[04:51:59] <mru> why would anything care?
[04:52:12] <mru> if it uses the same registers, what's the difference?
[04:52:30] <mru> then again, it's intel
[04:52:35] <Yuvi> it doesn't whatsoever before nehalem
[04:52:53] <Yuvi> then using the sse float loads for integers became slower
[04:53:07] <Yuvi> don't think anything else changed
[04:53:26] <mru> I've noticed on cortex-a8 that switching between integer and float pipelines has a penalty
[04:53:40] <mru> probably due to forwarding paths not crossing over
[04:54:22] <mru> so an integer instruction takes a full 6 cycles before the result available to a float instruction
[05:12:25] <Dark_Shikari> peloverde: and even on i7 the penalty is 2 clocks
[05:12:30] <Dark_Shikari> and it's often absorbed by ooe
[05:31:01] <Dark_Shikari> btw
[05:31:11] <Dark_Shikari> anyone who wants to work on ffmpeg's error concealment may have work
[05:31:22] <Dark_Shikari> there are some _SERIOUS_ issues with current error concealment with lost slices
[05:31:40] <Dark_Shikari> you could have a completely blue screen and error concealment would throw black and purple blocks all over it
[05:31:54] <Dark_Shikari> I have a company that cares a _lot_ about this and would pay good money for a patch that significantly improves this
[05:32:07] <Dark_Shikari> (for h264)
[05:33:14] <astrange> soc project to improve error concealment can go next to improve ratecontrol
[05:33:57] <Dark_Shikari> yeah, but this is a project that real money could go behind ;)
[05:34:01] <Dark_Shikari> and I don't think it's a soc project
[05:34:05] <Dark_Shikari> that sounds like a weekend project to me
[05:34:14] <Dark_Shikari> I'm guessing most of the problems are due to actual _bugs_.
[05:37:09] <astrange> probably
[05:37:39] * Dark_Shikari sees if he can get a number
[05:38:05] <mru> Dark_Shikari: 7
[05:38:10] <Dark_Shikari> lol
[05:41:04] <Dark_Shikari> ok, so they're apparently not sure what it's worth
[05:41:12] <Dark_Shikari> but they're throwing out an offer of $1500 to see if anyone's interested
[05:41:29] <Dark_Shikari> to "fix the problem of error concealment causing random blocking in static areas of the frame on slice losses"
[05:43:34] <Dark_Shikari> and they can probably be pushed higher, depending on how much work it actually is
[05:44:13] <Dark_Shikari> in general, if anyone is interested in h264 decoding opts, error concealment, parallelism, low-latency features, and other stuff, contact me, I can get you money
[05:47:30] <Dark_Shikari> bonus points: anyone who lives near LA and wants a job with a small, well-funded startup working on ultra-low-latency video streaming with x264, ffmpeg, swscale, red5, and other such tools... ping as well.
[06:06:13] <pentanol> any one?
[06:06:34] <pentanol> which function I should you to start rtsp playing?
[06:07:07] <pentanol> apparently, it doesn't here...  readelf -a /usr/local/ffmpeg-dev/lib/libavformat.so.52.54.0 | grep -i rtsp_read_play
[06:13:16] <j0sh> trying to optimize h264 direct prediction from this email (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083177.html)
[06:13:36] <j0sh> so i have this for 16x8 blocks so far: http://pastie.org/846482
[06:13:53] <j0sh> it plays fine, but the CRCs are off, not sure what i could be missing
[06:14:11] <j0sh> can someone take a look and lmk if its something obvious?
[06:14:19] <astrange> check the mv stuff in h264.c hl_motion and see if any of it differs
[06:14:27] <j0sh> alright
[06:40:12] <pentanol> wbs BBB I guess you guys may help me?
[07:04:31] <j0sh> there's not much mv stuff in hl_motion, most of it is mc-related
[07:04:54] <j0sh> but what is there seems close enough to what i have
[07:05:16] <astrange> it's the only thing that reads mvs
[07:06:01] <j0sh> hm
[07:06:35] <j0sh> it looks like mvs are already in mv_cache at that point
[07:06:55] <j0sh> whereas in the h264 dpred, it's copying into mv_cache
[07:08:15] <j0sh> i think i just dont understand how the list ref data structures are laid out
[07:13:50] <j0sh> is there anything i can look at during runtime to help debug this? i'm not sure what the problem is, so i dont know what to look for
[08:41:42] <peloverde> So I'm running into a situation where my code is only working with a debug print left on. Are my (FFTComplex*) casts possibly illeagal puns? Have I done something even stupider? http://ffmpeg.pastebin.com/98M10VXB
[08:42:58] <Dark_Shikari> um....
[08:43:02] <Dark_Shikari> you have float code.
[08:43:11] <Dark_Shikari> your SSE inline asm doesn't declare its clobbers
[08:43:13] <kshishkov> and why it's not all aligned?
[08:43:13] <Dark_Shikari> of COURSE it won't wor
[08:43:14] <Dark_Shikari> *work
[08:43:32] <peloverde> do I need to declare clobbers on all the xmms?
[08:43:57] <astrange> all the ones used yeah
[08:44:52] <Dark_Shikari> this means it will only compile with -msse
[08:45:12] <peloverde> The other functions in fft_sse don't seem to declare clobbers on the xmm regs
[08:45:18] <Dark_Shikari> luck
[08:45:21] <Dark_Shikari> also, less mixing of float and sse
[08:46:22] <peloverde> that fixed it, thanks
[08:59:50] <pengvado> the functions in fft_sse don't so any float math outside the asm blocks
[09:00:43] <Dark_Shikari> yeah, that.
[09:54:49] <wbs> pentanol: you're not supposed to call rtsp_read_play directly, call av_read_play() on the avformatcontext instead
[10:01:12] <pentanol> it should be after rtsp_read_header() ?
[10:20:55] <wbs> yes
[10:21:33] <wbs> which you shouldn't call directly either, you should do av_open_input_stream
[11:00:14] <CIA-92> ffmpeg: reimar * r22108 /trunk/tests/seek_test.c:
[11:00:14] <CIA-92> ffmpeg: Fix some memory leaks in seek_test test program:
[11:00:14] <CIA-92> ffmpeg: - do not allocate context twice
[11:00:14] <CIA-92> ffmpeg: - close the input file before exiting
[11:04:05] <CIA-92> ffmpeg: mstorsjo * r22109 /trunk/libavformat/ (15 files): Rename RTP depacketizer files from rtp_* to rtpdec_*
[11:10:43] <pentanol> may I use av_guess_format for network?
[11:11:35] <pentanol> I should do that in first time and then  av_open_input_stream then av_read_play ?
[11:15:37] <wbs> I guess so. but I guess all that is offtopic in this channel anyway
[11:19:10] <CIA-92> ffmpeg: reimar * r22110 /trunk/tests/seek_test.c: Free packets read in seek_test.
[14:04:09] * mru has an evil idea
[14:04:21] <kshishkov> donate it to M$
[14:04:52] <mru> do they care about crafting unseekable ogg files?
[14:05:05] <kshishkov> of course not
[14:05:52] <mru> the idea is to insert fake page headers that look just like real ones
[14:06:19] <mru> but completely mask all the real content
[14:06:27] <mru> should be trivial to do
[14:07:25] * kshishkov first asks why
[14:07:34] <mru> to be evil
[14:07:51] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/ForTheEvulz
[14:08:00] <kshishkov> mru: join Xiph foundation then
[14:09:05] <kshishkov> elenril: http://en.wikipedia.org/wiki/Tatra_(company)#War_years
[14:09:43] <elenril> lol
[14:10:29] <elenril> <usual patch question>
[14:10:57] <kshishkov> <usual patch answer silence>
[14:11:37] <elenril> lol
[14:11:40] <kierank> oh lord dolby's decided to change the mdct
[14:11:50] <elenril> maybe iive wants to apply a patch for me :)
[14:12:04] <iive> ?
[14:12:10] <kshishkov> elenrin: no since XvMC has no metadata
[14:12:18] <elenril> ah, right
[14:12:38] <kshishkov> kierank: ? Or do they just use different MDCT for E?
[14:12:56] <kierank> for E
[14:16:27] <kshishkov> that happens. IIRC we had the same thing with ATRAC
[14:59:19] <mru> anyone have info on overhead of mkv and mp4?
[14:59:27] * mru is too lazy to do the maths himself
[14:59:53] <Kovensky> I have no information other than "it's smaller than avi"
[15:01:50] <mru> are you sure about that?
[15:01:52] <mru> avi is pretty low
[15:02:14] <kshishkov> 8 bytes per chunk not counting index
[15:02:46] <mru> and mkv is 6-21 bytes per chunk not counting index
[15:03:02] <mru> according to specs
[15:03:06] * mru didn't verify
[15:03:10] <kshishkov> and for mp4 is was 0 + index IIRC
[15:03:25] <mru> yes, but you must have the index
[15:03:38] <kshishkov> obligatory index
[15:03:53] <mru> you can't find the packets otherwise
[15:04:10] <kshishkov> only with parser
[15:04:21] <mru> not even then in all cases
[15:04:23] <kshishkov> still, that should be the lowest overhead ;)
[15:04:31] <mru> depends on size of index
[15:04:36] <mru> but it's not a lot
[15:19:32] <mru> for constant frame rate and frames <64k in size you can get away with 2-3 bytes per packet average overhead
[15:21:27] <kshishkov> we also have NUT ;)
[15:30:14] <elenril> yeah, nut doesn't write index at all so it's smallest
[15:30:40] <iive> there is more than one nut implementation.
[15:34:30] <elenril> yes and nobody uses either of them ;)
[15:45:46] <Kovensky> iive: libnut is only used by nutmerge and the first thing it does is scream 4 lines of warning at you saying it generates invalid files
[16:13:39] <siretart> DonDiego: around? did any problems arise with 0.5.1?
[16:41:09] <CIA-92> ffmpeg: michael * r22111 /trunk/libavformat/mp3.c:
[16:41:09] <CIA-92> ffmpeg: Many mp3s seem to contain padding after id3 tags that is not considered in the
[16:41:09] <CIA-92> ffmpeg: tag size. Skip this to make the format probing quicker.
[17:22:38] <saste> hi all
[17:23:17] <saste> is it possible to *push* changes to the SVN repo from a git working copy
[17:23:33] <saste> I mean with some command like git push ...
[17:23:45] <saste> and then have the corresponding commit(s) committed to the SVN repo?
[17:24:17] <kshishkov> it solely depends on git server I think
[17:25:01] <janneg> saste: git svn --help
[17:25:07] <saste> I don't know because i never tried but I see many devs are using git at least for their local copies
[17:25:17] <janneg> if you have a correctly configure git svn repo
[17:25:25] <janneg> git svn dcommit will do it
[17:26:09] <saste> janneg: thanks
[17:26:29] <saste> hopefully i won't forget this time ;-)
[18:31:58] <elenril> o_0 michael has an mp3 encoder?
[18:32:11] <kshishkov> he might ;)
[18:32:18] <iive> ?
[18:32:25] * kshishkov has also a copy of LAME lying somewhere
[18:32:43] <elenril> iive: see his latest mail on ml
[18:33:59] <elenril> internal mp3 encoder would be nice, i hate rebuilding just because i forgot --enable-libmp3lame ;)
[18:34:23] <CIA-92> ffmpeg: cehoyos * r22112 /trunk/libavcodec/h264.c:
[18:34:23] <CIA-92> ffmpeg: Process picture aspect ratio changes in H.264.
[18:34:23] <CIA-92> ffmpeg: This fixes playback of such streams with ffplay (but does not affect
[18:34:23] <CIA-92> ffmpeg: current ffmpeg).
[18:34:23] <CIA-92> ffmpeg: Patch by Janusz Krzysztofik, jkrzyszt A tis D icnet D pl
[18:35:57] <elenril> what other format we care about supports chapters?
[18:36:04] <iive> well somebody making audio encoders that are actually good (e.g. and use psymodels) would be good.
[18:36:11] * iive looks at kshishkov 
[18:36:32] * kshishkov returns an innocent look to iive
[18:37:07] <kshishkov> well, after Alex deals with SBR he can start improving AAC encoder again
[18:38:00] <CIA-92> ffmpeg: cehoyos * r22113 /trunk/libavformat/utils.c:
[18:38:00] <CIA-92> ffmpeg: Print chapter info in dump_format().
[18:38:00] <CIA-92> ffmpeg: Patch by Anton Khirnov, wyskas gmail
[18:39:16] <kshishkov> well, I'd like to learn some things about practical approach to ratecontrol and overall bit allocation
[18:39:38] <kshishkov> maybe I should resurrect my MSVideo1 encoder and play with it
[18:40:16] <iive> :) ratecontrol have always been black magic for me, especially if you don't have fixed huffman codesize
[18:41:54] <kshishkov> try writing an H.261 encoder or two ;)
[18:51:50] <CIA-92> ffmpeg: cehoyos * r22114 /trunk/libavcodec/audioconvert.c: Make function get_channel_name() static: It is only used in audioconvert.c.
[18:57:13] <elenril> did that h264 patch just break decoding?
[18:57:37] <kshishkov> ask fate
[18:58:09] <elenril> it seems it wasn't hit yet
[18:58:42] <CIA-92> ffmpeg: cehoyos * r22115 /trunk/libavcodec/libxvidff.c:
[18:58:43] <CIA-92> ffmpeg: Make the following functions static (and remove ff_), they are only used
[18:58:43] <CIA-92> ffmpeg: inside libxvidff.c:
[18:58:44] <CIA-92> ffmpeg: ff_xvid_encode_init(), ff_xvid_encode_frame(), ff_xvid_encode_close()
[19:02:06] <elenril> http://fate.multimedia.cx/index.php?build_record=191408 yaaay
[19:04:30] <CIA-92> ffmpeg: cehoyos * r22116 /trunk/libavcodec/utils.c: Include libxvid_internal.h: It contains the prototype for av_tempfile().
[19:06:43] <CIA-92> ffmpeg: cehoyos * r22117 /trunk/libavcodec/utils.c:
[19:06:43] <CIA-92> ffmpeg: Make av_get_bit_rate() static and remove av_, the function is only used
[19:06:43] <CIA-92> ffmpeg: inside libavcodec/utils.c.
[19:16:23] <_av500_> gm
[19:16:33] <kshishkov> gn
[19:16:53] <_av500_> sleep well
[19:16:57] <janneg> gm
[19:17:13] <_av500_> hi
[19:24:08] <janneg> KotH's render machine is working nice, already 70 frames rendered. the intro should be complete with all frames rendered in 2 days or so
[19:31:08] <twnqx> Oo
[19:31:25] <thresh> janneg: what's your rendering machine?
[19:31:56] <janneg> phenom 2 x4 3 GHz with 6G RAM
[19:59:16] <CIA-92> ffmpeg: cehoyos * r22118 /trunk/libavcodec/resample2.c: Make av_build_filter static (and remove av_): It is not used outside resample2.c.
[20:41:51] <DonDiego> http://hardwarebug.org/2010/02/10/1080p-video-on-beagle/#comment-558
[20:41:54] <DonDiego> rotfl
[20:42:03] <DonDiego> siretart: still around?
[20:42:13] <DonDiego> i was afk for a long time
[20:49:31] <CIA-92> ffmpeg: vitor * r22119 /trunk/libavutil/ (tree.h tree.c):
[20:49:31] <CIA-92> ffmpeg: Implement av_tree_destroy_free_elem() to destroy a tree and free all the
[20:49:31] <CIA-92> ffmpeg: values stored on it.
[20:49:54] <elenril> w00t, chapter demuxing for nut is broken an nobody noticed!
[20:50:12] <CIA-92> ffmpeg: vitor * r22120 /trunk/libavformat/ (nutenc.c nutdec.c): Plug some memory leaks in NUT muxer and demuxer
[20:50:36] <Dark_Shikari> >nut
[20:50:38] <Dark_Shikari> >nobody noticed
[20:50:40] <Dark_Shikari> sounds about right
[20:51:31] <elenril> this is going to change. one day nut shall rule the world
[20:51:48] <elenril> <evil laugh here>
[20:51:56] <twnqx> your nuts.
[20:52:01] <twnqx> err
[20:52:04] <twnqx> you're nuts.
[20:52:12] <lu_zero> elenril: only IF enough applications will start using it
[20:52:42] <lu_zero> and having at least the ffmpeg and mplayer implementation interoperable would be nice...
[20:52:57] <Kovensky> being at least able to mux anything in nut would be nice
[20:53:07] <elenril> wait, what?
[20:53:16] <Kovensky> `ffmpeg -i file.mkv -vcodec copy -acodec copy file.nut` # <-- I consider nut unusable until this works :P
[20:53:17] <elenril> mplayer uses lavf for nut demuxing
[20:53:33] <Kovensky> (with h264 ofc)
[20:53:39] <elenril> Kovensky: err actually this isn't a nut bug
[20:53:46] <Kovensky> I know
[20:53:52] <Kovensky> I'm just redirecting the blame to the whole thing
[20:53:54] <Kovensky> lol
[20:54:18] <elenril> now that this channel is logged maybe someone will fix it
[20:54:39] * Kovensky wonders if michael actually reads this
[20:54:50] <elenril> he does
[21:21:01] <elenril> wow, git send-email is nice
[21:21:39] <elenril> didn't expect it to be so convenient
[21:32:33] <Kovensky> lol
[21:33:30] <siretart> DonDiego: yes?
[21:33:51] <DonDiego> lol, i pinged you by sms this instant :)
[21:33:57] <DonDiego> 0.5.1?
[21:34:18] <siretart> sure!
[21:34:30] <DonDiego> ok, let's roll then
[21:34:47] <DonDiego> i need to make a phone call, then i have time, bbiab
[21:49:20] <DonDiego> k
[21:49:51] <DonDiego> so.. - what remains on the todo?
[21:50:19] <av500_at> world domination
[21:50:56] <DonDiego> we're approaching the 60% mark :)
[21:51:28] <av500_at> im covering .at atm
[21:51:54] <Kovensky> what's .at
[21:51:55] <Kovensky> sausageland?
[21:52:27] <av500_at> mountains with some snow
[21:53:39] <astrange> is r20497 on the branch?
[21:53:45] <astrange> i have trouble building darwin i386 with that
[21:57:01] <DonDiego> http://www.mplayerhq.hu/design7/donations.html#michael
[21:57:17] <DonDiego> somebody please donate that stuff to michael, should be cheap..
[21:57:43] <siretart> DonDiego: I'm currently extending the RELEASE notes
[21:58:02] <DonDiego> astrange: no, it's not
[21:58:03] <siretart> DonDiego: we should mention symbol versioning and the libx264 backport
[21:58:14] <DonDiego> you mean the changelog?
[21:59:13] <DonDiego> scratch that comment, i forgot about the RELEASE file
[21:59:13] <astrange> ok
[21:59:25] <astrange> and i might have a g4 powerbook adapter, don't know the model numbers
[21:59:47] <DonDiego> cool
[21:59:55] <DonDiego> can you look up the model number?
[22:03:16] <siretart> DonDiego: http://paste.debian.net/61882/
[22:03:32] <astrange> a1021
[22:03:47] <astrange> i have the powerbook too but the gpu died, might as well recycle it
[22:04:51] <DonDiego> my gpu is having issues as well..
[22:05:41] <siretart> DonDiego: perhaps this can be used for the website as well
[22:05:42] <DonDiego> does the powerbook work at all?
[22:06:27] <DonDiego> i'm thinking that the security fixes could just be mentioned in the changelog
[22:06:40] <DonDiego> i was about to add a short list to the changelog..
[22:08:17] <siretart> hm, would work for me as well
[22:08:40] <siretart> but the symbol versioning and libx264 stuff should really appear on the website
[22:08:54] <DonDiego> oh yes of course
[22:09:07] <DonDiego> let me quickly commit the changelog updates
[22:09:15] <astrange> i have two, one boots but dies after a day or two, the other has a dead hd but is fine otherwise
[22:09:27] <astrange> oh, three, that one works but i'm using it
[22:09:45] <astrange> hmm that makes six laptops in this room. why is electronics recycling only once a year?
[22:10:00] <DonDiego> lol
[22:10:22] <DonDiego> what powerbooks are they?
[22:15:13] <astrange> 1.5ghz/15" and 867mhz/12"
[22:15:39] <astrange> the second being the repairable one
[22:16:02] <DonDiego> the one with the dead hdd?
[22:16:25] <astrange> yeah
[22:16:27] <DonDiego> i mean the 867mhz/12" has the dead hdd?
[22:17:10] <DonDiego> also, what do you mean by "dies after a day or two"? that you have to turn it off every once in a while?
[22:23:15] <CIA-92> ffmpeg: diego * r22121 /branches/0.5/Changelog: Mention security fixes in the changelog.
[22:25:13] <astrange> the display breaks up and it doesn't respond anymore. i can't remember if ssh worked
[22:29:27] <siretart> DonDiego: do you need anything from me? ... I'd need to get up tomorrow early :/
[22:32:09] <CIA-92> ffmpeg: reimar * r22122 /trunk/libavformat/os_support.c:
[22:32:09] <CIA-92> ffmpeg: Make our getaddrinfo implementation initialize "struct addrinfo" return
[22:32:09] <CIA-92> ffmpeg: value to NULL on errors.
[22:33:58] <DonDiego> siretart: do you have time for the release tomorrow?
[22:34:12] <CIA-92> ffmpeg: reimar * r22123 /trunk/libavformat/udp.c:
[22:34:12] <CIA-92> ffmpeg: Explicitly set struct addrinfo to NULL if getaddrinfo failed instead of
[22:34:12] <CIA-92> ffmpeg: assuming getaddrinfo will have done this.
[22:35:16] <siretart> DonDiego: what steps are left?
[22:37:18] <DonDiego> very little
[22:37:38] <DonDiego> webpage entry, release file, rolling the tarballs
[22:37:43] <DonDiego> tagging the tree
[22:37:59] <DonDiego> signing the tarballs
[22:38:09] <DonDiego> that's it i think
[22:38:22] <DonDiego> did i forget something?
[22:39:07] <siretart> ok. let's use my notes for RELEASE as webpage entries
[22:39:32] <DonDiego> i have a half-written web page entry
[22:39:44] <DonDiego> anyway, if you want to go to bed we can do this tomorrow
[22:39:52] <DonDiego> i have time during the day
[22:40:28] <DonDiego> but friends are coming over at the evening
[22:40:34] <DonDiego> my birthday is on tuesday :)
[22:41:15] <siretart> I think you can also just release it today, and I'll sign the tarball tomorrow. how about that?
[22:41:45] <DonDiego> dunno, i'm rather sleepy myself now..
[22:41:58] <astrange> it's also time to release perian so i think i'll arbitrarily freeze the ffmpeg external to what i checked out this morning
[22:42:02] <DonDiego> might as well go to bed and do this when i'm more awake
[22:42:25] <DonDiego> astrange: do you use ffmpeg releases for perian?
[22:43:09] <astrange> current trunk, we had regular releases before 0.5 came out
[22:43:38] <astrange> the supported formats are limited atm so it's possible to test them all, and i want to ship michael's h264 opts
[22:44:01] <DonDiego> i was asking because 0.6 is slated to be released RSN
[22:44:19] <DonDiego> siretart: so do you have time for release stuff tomorrow?
[22:44:35] <siretart> DonDiego: I think so, yes
[22:45:23] <siretart> I should be avaiable most of the time today, but some student might require assistance at some times
[22:46:59] <DonDiego> fine, then let's do it tomorrow
[22:47:10] * DonDiego yawns
[22:47:26] <siretart> same here. see you tomorrow then!
[22:48:45] <DonDiego> cu
[23:55:15] <CIA-92> ffmpeg: michael * r22124 /trunk/libavcodec/ (h264_cavlc.c h264_cabac.c): Remove some unneeded fill_rectangle() for 16x16 blocks.