Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2010

1 participants
31 discussions

IRC log for 2010-02-28
by irc＠mansr.com 01 Mar '10

01 Mar '10

[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.

1 0