[FFmpeg-devel-irc] IRC log for 2011-03-01

Wed Mar 2 01:00:23 CET 2011

[02:52:12] <hyc> anybody used the movie and overlay filters recently? I can't seem to get it to work with a transparent background
[02:52:40] <hyc> always get opaque black. wondering if the gif or png decoder is losing the alpha info
[02:52:52] <hyc> or if the movie or overlay filter is ignoring the alpha
[02:53:16] <BBB> I've heard that happens with indexed pngs on the ML
[02:53:55] <hyc> ok, I'll try RGB instead
[02:55:38] <hyc> thanks BBB, that does the trick
[03:00:10] <BBB> it's still a bug
[03:00:13] <BBB> anyway :)
[03:00:33] <hyc> yeah. it actually butchers it completely for indexed PNG
[03:01:00] <hyc> thebackground is the right size, the foreground is squashed to like 1/8th the true width
[05:17:04] <kierank> astrange: ping
[05:18:31] <astrange> here
[05:20:01] <kierank> are you familiar with get_buffer and similar?
[05:20:47] <astrange> more than nothing, but i haven't written my own that didn't just call back into avcodec
[05:21:13] <kierank> any idea what's wrong with: http://pastebin.com/Q05nP9VC
[05:31:19] <kierank> spaam: https://github.com/BastyCDGS
[05:32:04] * Sean_McG sighs, 00:30 already -- where does the time go?!
[05:41:53] <peloverde> saintdev: ping
[05:42:44] <astrange> kierank: i think you're missing the loop at the bottom of ffplay.c input_get_buffer()
[05:43:41] <kierank> i see
[05:43:43] <kierank> will try
[05:43:45] <kierank> thanks
[05:53:22] <kierank> astrange: still segfaults
[05:56:31] <Sean_McG> does it by any chance segfault at the memset()?
[05:57:28] <Sean_McG> also, can you valgrind it?
[05:57:52] <kierank> oh it doesn't segfault. it complains about a free actually
[05:58:21] <Sean_McG> ah... free()-ing something that is NULL?
[05:58:32] <kierank> well valgrind complains throughout h264 decoding
[05:58:34] <kierank> like crazy
[05:58:41] <kierank> then it crashes at av_freep
[05:59:37] <Sean_McG> you multithreaded? some kinda double-free()?
[06:00:08] <kierank> it's a threaded app yes but everything stays in one thread
[06:05:48] <kierank> I might try the avfilter get buffer
[06:06:05] <kierank> damn vm has crashed
[06:06:30] <Sean_McG> ensured everything is properly re-entrant?
[06:07:37] <kierank> i believe so
[06:10:53] <saintdev> peloverde: pong
[06:40:38] <kierank> wow there's a guy called mans on breakfast news and they pronounced his name correctly
[06:44:19] <saintdev> what, it doesn't rhyme with hands?
[06:44:21] * saintdev ducks
[07:23:06] <KotH> hoi zäme
[07:29:09] <j0sh> are the swscale-test supposed to be identical across configurations? (say, with and without mmx disabled)
[07:29:27] <j0sh> swscale-test results*
[07:41:09] <kierank> jb_CeBIT: anything good?
[07:45:30] <jb_CeBIT> no idea
[07:45:44] <peloverde> really compelling (and long) starcraft vlog for those who partake: http://www.youtube.com/watch?v=NJztfsXKcPQ
[07:51:56] <spaam> peloverde: that episode is really nice
[07:58:33] <Tjoppen> I do watch day9 every now and then, but I hadn't seen that one
[08:01:39] <Tjoppen> coffee time
[08:07:50] <spaam> Tjoppen: see it.. one of the best :)
[08:10:35] <kierank> spaam: our colleague basty is still updating his repo
[08:11:07] <spaam> kierank: Nice
[08:11:27] <spaam> maybe we can get avseq into ffmpeg after the summer
[08:11:51] <kierank> avseq needs another round of gsoc
[08:12:07] <spaam> yeah
[08:12:12] <kierank> top priority
[08:13:04] <Tjoppen> I think my sarcasm detector needs calibrating
[08:53:09] <kierank> hmmm it segfaults in h264 now so I guess that's better than a double free
[08:56:10] <av500> triple free ftw
[09:10:46] <lu_zero> yawn?
[09:11:59] <av500> sure
[09:26:07] <kierank> michaelni: can you help me figure out why this get_buffers implementation is broken http://pastebin.com/Q05nP9VC
[09:49:16] <michaelni> kierank, look at mplayer/trunk/libmpcodecs/vd_ffmpeg.c for a working impl. or elaborate on brokwn and i could try to look at it when i have time (not now)
[09:49:55] <wbs> michaelni: would you care to look at the aviobuf fill_buffer() bugfix I posted two days ago? I'd value your opinion on it
[09:50:03] <kierank> michaelni: h264 decoding writes over the end of the buffer in MPV_frame_end amongst many places
[09:50:09] <kierank> michaelni: thanks, didn't think of mplayer
[09:50:25] <michaelni> kierank, allocate more bytes at the end?
[09:51:33] <kierank> tried that. still crashed
[09:52:17] <michaelni> kierank, why now?
[09:53:19] <kierank> valgrind's still running
[09:53:27] <michaelni> wbs, ill try to look over it later today
[09:53:31] <wbs> michaelni: ok, thanks
[09:53:38] <michaelni> no prob
[09:53:56] <kierank> still manages to write over the end somehow
[09:54:16] <kierank> as well as loads of other h264 "Conditional jump or move depends on uninitialised value(s)"
[09:55:15] <Kovensky> 06:49.35 MisterHatt: Kuukunen: I'm against GM as I dont trust it
[09:55:19] <Kovensky> 06:50.15 Kuukunen: because after eating GM food, the meat you eat might have GENES in it o_o
[09:57:10] <kshishkov> Kovensky: exactly
[10:01:01] <michaelni> kierank, your code is definitly wrong if CODEC_FLAG_EMU_EDGE is not set
[10:01:18] <kierank> yeah that's not a problem
[10:01:30] <kierank> my ffmpeg is only compiled in with emu_edge codecs
[10:02:08] <michaelni> so what is w/h and the allocated w/h and where it writes over the end and what is linesize?
[10:04:58] <kierank> original: w: 720 h: 576     allocated: w: 752 h: 610
[10:06:03] <kierank> linesizes: 0: 752 1: 384 2: 384 3: 0
[10:12:08] <michaelni> kierank, do all decoders crash or just h264?
[10:12:53] <kierank> only tested h264 so far. will try an mpeg-2 sample
[10:13:38] <kierank> mpeg-2 works fine
[10:13:40] <kierank> only h264 broken
[10:14:13] <kierank> interesting...
[10:14:14] <michaelni> progressive ? PAFF ? MBAFF?
[10:16:10] <michaelni> also try to allocate alot more, like 3 times what should be neede maybe the picture when you see it will give you a hint
[10:16:45] <kierank> PAFF = fail (720x576), progressive = fail (1280x720), mbaff = fail (1920x1080)
[10:16:56] <kierank> lemme find some mpeg-2 4:2:2 just to try that
[10:17:36] <iive> kierank: valgrind can log the errors to file, then you can skip it much faster
[10:20:39] <kierank> mpeg-2 422 works so it's just an h264 issue so far
[10:21:18] <michaelni> and just to be sure check that you have CODEC_FLAG_EMU_EDGE set
[10:22:42] <michaelni> and that things like lowres are not set
[10:25:38] <kierank> oh wait, crap emu_edge is off for mpeg2/h264. I meant I'm only using dr1 codecs
[10:29:02] <kierank> ...aand all works fine now
[10:29:06] <kierank> Thanks a lot michaelni
[10:29:56] <michaelni> no prob :)
[10:29:58] <spaam> :)
[10:30:22] <michaelni> ill need to do some work now ...
[10:30:45] <michaelni> s/ill/i/
[10:38:38] <vipw> wbs: fwiw, android uses httplive:// instead of applehttp://
[10:40:09] <wbs> vipw: hmm, okay
[11:28:26] <DonDiego> mru: would there be any reason to prefer 'git archive' over just rolling a tarball with plain tar?
[11:28:55] <wbs> DonDiego: git archive is at least "cleaner" in that it won't accidentally grab other files laying in the same directory, and won't include .git
[11:29:22] <DonDiego> i'm working from a clean clone...
[11:30:00] <wbs> then it probably mostly differs in avoiding the .git directory, and won't have to write all the files to the FS before tarring them
[11:30:02] <DonDiego> but git archive could be useful to generate the tarball without git metadata....
[11:30:02] <av500> still has .git
[11:34:38] <mru> git archive includes a comment in the tar/zip identifying the rev it was built from
[11:34:50] <mru> not important, but could be handy
[11:35:03] <DonDiego> i'm putting that in the VERSION file
[11:35:15] <DonDiego> btw, right now i use
[11:35:29] <DonDiego> $(cat ffmpeg/.git/refs/heads/master)
[11:35:31] <DonDiego> for that
[11:35:40] <mru> why?
[11:35:43] <Flameeyes> git describe
[11:35:45] <mru> run version.sh
[11:35:59] <Kovensky> git describe always prefers tags Flameeyes
[11:36:06] <Flameeyes> and is that bad?
[11:36:11] <Kovensky> ofc
[11:36:17] <Flameeyes> why would it be?
[11:36:28] <mru> if you run version.sh you'll get exactly the same string as a straight build would
[11:36:35] <mru> that has to be what you want
[11:36:41] <Kovensky> because then you'll get 0.6.2M-githash
[11:36:44] <Kovensky> or sth like that
[11:36:48] <Kovensky> depending on what is the latest annotated tag
[11:37:00] <mru> that's usually a good thing
[11:38:26] <Flameeyes> especially since I'd expect tags not to be set over master, but over branches, most of the time
[11:38:43] <Flameeyes> so you'd have 0.6-$hash on master, and 0.6.2-$hash on branch
[11:39:22] <Kovensky> if there is no tag set on master, git describe doesn't work
[11:42:46] <mru> --always
[11:42:59] <mru> stop speculating and just run version.sh already
[11:44:15] <DonDiego> shall i just use the output of version.sh unmodified?
[11:44:46] <DonDiego> i.e. 'git-00ba041' or similar instead of 'git-snapshot-00ba041' or whatever?
[11:45:31] <mru> yes
[11:45:48] <mru> why should the build ID differ based on how the sources were obtained?
[11:57:56] <wbs> mru: btw, where does git archive include the version number?
[11:58:09] <DonDiego> VERSION
[11:58:15] <DonDiego> version.sh looks for that file
[11:58:46] <wbs> yes, but what is set and where in order for git archive to produce it?
[11:59:06] <DonDiego> no git archive involved
[11:59:20] <mru> wbs: nothing at the moment
[11:59:26] <wbs> I meant this:
[11:59:26] <wbs> 13:34 <mru> git archive includes a comment in the tar/zip identifying the rev  it was built from
[11:59:42] <mru> wbs: it uses some comment field
[11:59:47] <wbs> oh, ok
[11:59:51] <DonDiego> ah, ok, sorry, misundestood you..
[12:00:09] <mru> but git archive can be made to put info in a real file too
[12:08:23] <DonDiego> ok, tarball generation script done...
[12:20:23] <DonDiego> git snapshot: 35M, source snapshot: 3.9M
[12:23:07] <pross-au> 3.9M, for 12 years of work. Niice
[12:23:45] <mru> it's 23M uncompressed
[12:23:53] <mru> tar
[12:24:20] <pross-au> I am thinking more about entropy
[12:24:41] <mru> it does compress well
[12:25:02] <pross-au> Small is beautiful
[12:27:44] <kshishkov> pross-au: how're Z cutscenes doing, mate?
[12:28:47] <pross-au> They're doing funny
[12:28:54] <pross-au> Zero progress
[12:29:00] <pross-au> Demuxer works
[12:29:10] <pross-au> Just need to finish jvdec
[12:29:54] <kshishkov> what's that?
[12:30:41] <pross-au> JV dec is the Bitmap Brothers Z Video Decoder
[12:32:29] <pross-au> (Jonathon's Video i suspect
[12:35:53] <pross-au> I'll return to JV, maybe after i polish up the bayer patch
[12:36:09] <kshishkov> good luck on them all
[12:36:30] <pross-au> Dont need luck
[12:36:31] <pross-au> Need time
[12:36:39] <pross-au> Its in short supply
[12:37:07] <kshishkov> you tell me
[12:53:32] <spaam> pJok: ska du pÃ¥ OSD ?
[12:53:51] <spaam> http://opensourcedays.org
[12:55:37] <pJok> spaam, japp
[12:55:50] <spaam> pJok: nice
[12:56:22] <spaam> funderar pÃ¥ att besÃ¶ka det  ocksÃ¥ :)
[12:56:32] <pJok> bra idÃ©
[12:56:36] <spaam> date?
[12:56:48] <pJok> lÃ¶rdag
[12:57:05] <spaam> amen nu tÃ¤nkte jag inte pÃ¥ det datum.. ;P
[12:57:10] <pJok> ah :P
[12:57:19] <pJok> mÃ¶tes i malmÃ¶?
[12:57:41] <spaam> pjta varfÃ¶r inte. mÃ¥ste ju Ã¤ndÃ¥ byta tÃ¥g hÃ¤r sÃ¥ :)
[12:57:51] <pJok> hehe
[14:23:28] * thresh has fun decyphering http://lists.maemo.org/pipermail/maemo-developers/2011-March/028202.html
[14:24:06] <av500> thresh: russian hacker trying to unlock a N900?
[14:24:43] * elenril thinks his hovercraft is full of eels
[14:25:01] <kshishkov> elenril: you're not Hungarian, you can't use this phrase
[14:25:26] <elenril> racism!
[14:25:28] <kshishkov> av500: sounds more like Russian hacker trying to disguise his N900 in wireless network
[14:25:36] <mru> this is the first time I've seen a mac address referred to as cynical
[14:25:47] <av500> kshishkov: he is not hungarian since his nick is not pwszElenril
[14:25:58] <thresh> mru: probably because he thinks there should be a PC address instead or something
[14:26:46] <kshishkov> mru: in Russia even MAC addresses may be cynical about their owners
[14:27:16] <av500> PU:TI:N0:WN:SY:0U
[14:27:39] <kshishkov> that's only for Presidential iPad
[14:27:57] <av500> oops, so I picked the wrong MAC here
[14:28:20] <mru> now that we're off-topic, does anyone know a way to coerce the name of the dynamic linker out of gcc?
[14:28:39] <kshishkov> ln -s ?
[14:28:46] <av500> s/ld/../
[14:28:47] <mru> that is, the value it passes to ld -dynamic-linker
[14:29:08] <mru> usually something like /lib/ld.so
[14:29:17] <kshishkov> gcc -dumpspecs
[14:29:17] <thresh> -dumpspecs?
[14:29:39] <av500> %{muclibc:%{mglibc:%e-mglibc and -muclibc used together}/lib/ld-uClibc.so.0;:/lib/ld-linux.so.2}
[14:30:01] <mru> yes, I know that
[14:30:10] <mru> but I'd rather not try to parse that mess
[14:30:40] <kshishkov> grep it then
[14:31:14] <mru> look, I can think of all the obvious ways myself
[14:31:31] <mru> I was hoping someone knew a secret option similar to -print-libgcc-name
[14:32:00] <mru> s/name/file-name/
[14:34:42] <av500> gcc -print-prog-name=ld
[14:34:52] <mru> that prints the static link editor
[15:04:41] <spaam> kierank: "sound reproduction with a voice soundchip"... maybe we need to tell him about avseq
[15:33:07] <BBB> kshishkov: I'll debug against the ref decoder... I'm just doing this for fun btw, I know vc1 is unused :)
[15:33:17] <BBB> so obviously any feature from vc1 is therefore also unused
[15:44:27] <kshishkov> BBB: well, some baseline features are used
[15:44:57] <kshishkov> BBB: but some of them I've seen only in reference files (and maybe that's for good)
[15:45:25] <kshishkov> like luma/chroma scaling - which should be done only for output but not for reference copy
[15:45:46] <kshishkov> BBB: and unfortunately interlaced mode was used
[15:48:24] <kshishkov> BBB: and I had to fix some issues at your GSoC'11 page
[15:52:44] <BBB> kshishkov: ok, thanks
[15:58:21] * elenril summons reviews
[15:58:44] <kshishkov> * elenril fails as both summoner and stabber
[15:58:45] * av500 reviews summons
[15:58:57] <av500> REJECTED
[16:00:08] <elenril> you're all lazy and evil
[16:00:24] * elenril goes to rewrite ffmpeg in php
[16:00:25] <av500> that sums it up nicely
[16:01:10] * kshishkov makes sure elenril's PHP is implemented in Java
[16:21:08] <lu_zero> using a ruby virtual machine?
[16:21:21] <av500> written in lua?
[16:23:05] <kshishkov> with lua interpreter in hardware BASIC
[16:23:34] <gnafu> As long as it runs on my TI-83, I'm happy.
[16:23:44] <BBB> elenril: sorry, I thought I said they were ok?
[16:48:05] <BBB> anyone have ideas for GSoC2k11?
[16:48:15] <BBB> preferrably with proposed mentors, that being all of you
[16:48:47] <CIA-15> ffmpeg: Alexander Strange <astrange at ithinksw.com> master * rad9791e12b ffmpeg/libavcodec/pthread.c:
[16:48:47] <CIA-15> ffmpeg: pthreads: Fix bug introduced with thread_safe_callbacks
[16:48:47] <CIA-15> ffmpeg: For intra codecs, ff_thread_finish_setup() is called before decoding starts
[16:48:47] <CIA-15> ffmpeg: automatically. However, get_buffer can only be used before it's called, so
[16:48:47] <CIA-15> ffmpeg: adding this requirement broke frame threading for them. Fixed by moving the
[16:48:48] <CIA-15> ffmpeg: call until after get_buffer is finished.
[16:48:49] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[16:48:53] <CIA-15> ffmpeg: Alexander Strange <astrange at ithinksw.com> master * r76d8846c4e ffmpeg/libavcodec/huffyuv.c:
[16:48:53] <CIA-15> ffmpeg: huffyuv: Add multithreading support
[16:48:53] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[16:50:26] <av500> BBB: libavseq2
[16:53:39] <BBB> kshishkov: is http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2011#Support_missing_features_from_VC-1_standard OK with you?
[16:54:02] <BBB> kurosu: do you want to help mentor the optimizations for vc1dec also?
[16:56:08] <elenril> no h264?
[16:56:14] <elenril> as for gsoc -- playlists?
[16:56:49] <av500> libavmetadata
[16:57:18] <spaam> BBB: what about avseq? :D
[16:58:24] <av500> [17:50:26] <av500> BBB: libavseq2
[16:58:46] <spaam> av500++
[16:59:08] <spaam> av500: after that we can have libavseq-ng
[16:59:15] <BBB> hm...
[16:59:16] <BBB> no
[16:59:18] <BBB> :)
[16:59:37] <elenril> BBB: if they're ok, maybe you could commit them ;)
[16:59:54] <BBB> elenril: would you like to mentor a gsoc task?
[16:59:54] <elenril> also i still didn't see any comments on avio_get_str
[16:59:59] <BBB> after all you are our top committer
[17:00:02] <elenril> lol
[17:00:24] <elenril> that only means i know basics of sed ;)
[17:02:12] <elenril> i'd rather try studenting, but i'll be busy with my diploma work during the summer
[17:06:00] <BBB> astrange: would you like to help mentor students into adding -mt support to more decoders (e.g. vp8)? or be a student yourself and merge -mt?
[17:06:43] <merbzt> elenril: we could slot you a not so time demanding task
[17:07:09] <elenril> BBB: there's so much left to merge?
[17:07:09] <BBB> or, rather, figure out your own task - what would you like to work on that you think you can finish over a summer?
[17:07:22] <BBB> elenril: not really, but some decoders aren't -mt yet after the merge
[17:07:28] <BBB> some of them are nice to -mt for PR purposes
[17:07:30] <BBB> e.g. vp8
[17:09:58] <elenril> when is the deadline for student applications?
[17:11:18] <BBB> hasn't opened yet
[17:11:45] <BBB> march 28-april 8
[17:12:05] <elenril> good
[17:12:57] <BBB> I have your url_fseek->avio_seek patch queued
[17:13:15] <BBB> the other one replaced url_fskip() with url_fseek(SEEK_CUR), right?
[17:13:29] <BBB> you sure you don't want a macro? I think mru preferred a macro
[17:13:53] <mru> I don't mind either way
[17:14:28] <BBB> ok, I'll queue that also then
[17:16:17] <BBB> the line that mru pointed out there needs a change though
[17:16:21] <BBB> it adds a needless < 0
[17:16:28] <BBB> can you re-post the patch, elenril ?
[17:17:00] <BBB> or alternatively I can fix it myself
[17:17:34] <elenril> ?
[17:17:51] <BBB> see [FFmpeg-devel] [PATCH 2/3] lavf: replace all uses of url_fskip with avio_seek
[17:17:58] <elenril> changed version should be equivalent to old code
[17:18:37] <elenril> url_fskip returns 0 on success, < 0 on error
[17:18:49] <BBB> in a for loop, you change for(;;url_fskip){.. into for(;;avio_seek(SEEK_CUR < 0) { ..
[17:18:59] <BBB> it's the increment part of the for loop, not the conditional part of the for-loop
[17:19:03] <BBB> the <0 isn't useful
[17:19:05] <elenril> so the for() would terminate after first successful skip
[17:19:18] <BBB> for(start;condition;increment){
[17:19:18] <elenril> seek() returns new offset on success, <0 on error
[17:19:29] <BBB> the increment part return code is not checked
[17:19:36] <elenril> ok, i should learn to read
[17:19:39] <BBB> for(i=0;i<count;i++){..
[17:27:20] <BBB> elenril: all queued
[17:27:24] <BBB> will run fate and commit
[17:27:29] <BBB> did you have more patches than those 3?
[17:27:51] <elenril> avio_get_str
[17:28:19] <BBB> oh right
[17:28:57] <BBB> doesn't apply
[17:29:00] <BBB> needs a rebase likely
[17:30:12] <BBB> elenril: just hold on before rebasing it until I've at least pushed the other 3 patches
[17:31:33] <elenril> i'll rebase it
[17:32:15] <elenril> no conflicts here
[17:32:29] <BBB> because I didn't push the other 3 yet
[17:32:32] <BBB> pushed now
[17:32:40] <elenril> i rebased against those
[17:32:45] <BBB> hm
[17:32:46] <BBB> weird
[17:32:49] <BBB> it doesn't apply for me
[17:32:51] <BBB> let me try again
[17:32:52] <elenril> git magic
[17:32:58] <BBB> can you resend anyway?
[17:33:04] <mru> BBB: how are you applying?
[17:33:13] <BBB> git am -s < emailbox
[17:33:19] <mru> try git am -3 -s
[17:33:24] <BBB> what is -3?
[17:33:27] <BBB> n/m
[17:33:28] <mru> 3-way merge
[17:33:29] <BBB> I'll --help it
[17:34:02] <elenril> done
[17:34:05] <BBB> ty
[17:36:17] * elenril kicks CIA-15 
[17:36:37] <BBB> I don't see your patch yet either
[17:36:39] <elenril> did it die?
[17:36:48] <BBB> maybe it's busy
[17:36:55] <CIA-15> ow
[17:43:45] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r6b4aa5dac8 ffmpeg/libavformat/ (90 files):
[17:43:45] <CIA-15> ffmpeg: avio: avio_ prefix for url_fseek
[17:43:45] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[17:43:45] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * re356fc57a2 ffmpeg/libavformat/ (62 files):
[17:43:46] <CIA-15> ffmpeg: lavf: replace all uses of url_fskip with avio_seek
[17:43:46] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[17:43:47] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r0300db8ad7 ffmpeg/libavformat/ (avio.h aviobuf.c):
[17:43:47] <CIA-15> ffmpeg: avio: deprecate url_fskip
[17:43:48] <CIA-15> ffmpeg: avio_seek should be used instead
[17:43:48] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[17:45:01] * elenril kicks obscure sw written in fortran
[17:46:08] <av500> obscure sw written in fortran waits for elenril to wither away
[17:46:48] <av500> then has drink with obscure sw written in cobol
[19:40:36] <vcs> hi, im developing a new demuxer for libavformat and seem to have run into a bug... this the right channel to ask about?
[19:43:37] <vcs> anyways... Sometimes when I use url_fseek in my demuxer (with valid position in the file, verified), i keep getting "Assertion failed: s->buf_ptr == s->buf_end, file libavformat/aviobuf.c, line 314" the values from the assertation: PTR: 30f076e END: 30f1878 END-PTR: 110a. any idea what i could be doing wrong? seems to only happen when i use url_fseek. Here is a full backtrace (the violating function being fill_buffer in aviobuf.c): http://pastebin.com/
[19:44:13] <BBB> vcs: yes, this is the right channel
[19:44:30] <gnafu> vcs: Your message was cut off after pastebin.com/.
[19:44:37] <vcs>  http://pastebin.com/CzUiwfAH
[19:45:53] <gnafu> vcs: Thanks.
[19:46:57] <vcs> im going to keep going through the aviobuf to try and see if i can figure this out, but if you have seen this before/know anything about that section of the code any help would be appreciated
[19:49:21] <vcs> I guess I should note I am cross compiling on linux for windows, but the BT makes that obvious :)
[20:01:07] <BBB> vcs: could we see your demuxer?
[20:02:00] <vcs> sure, it is open source after all... give me a sec
[20:07:39] <BBB> iive: stop trolling please
[20:08:20] <BBB> iive: I have never revoked anyone's commit access and I have never told anyone not to review anything. in fact, I highly recommend everyone to review and I continues ask michael and baptiste to review the stuff they consider "theirs"
[20:08:23] <vcs> http://pastebin.com/QwCPYciP
[20:08:25] <BBB> iive: what you're saying is insulting
[20:08:32] <BBB> vcs: will have a look
[20:09:19] <vcs> thanks, basically im just trying to get video playback working (which is just mpeg4) so audio stuff is not initialzed yet
[20:10:32] <vcs> problem happens at line 222 (i had not put the GPL header on it yet)
[20:11:01] * gnafu looks at the ML archives to figure out what the heck BBB is talking about...
[20:12:06] <BBB> can't directly see whaht's wrong with it
[20:12:11] * BBB looks again
[20:12:33] <iive> BBB: I think I mentioned roots. I expect this to be their response of this situation.
[20:12:47] <Compn> BBB : does michael have commit rights to ffmpeg.org homepage repo ?
[20:13:00] <vcs> BBB: I will try to compile and run on linux and see if I get the same results
[20:13:02] <iive> and michael did post his patch and it got accepted by carl. Diego have not posted his "similar" patch yet.
[20:13:15] <vcs> thanks for the look though, is much appreciated
[20:13:30] <Compn> iive : BBB says that doesnt matter since diego was 'working' on it first
[20:13:50] <iive> by reverting the patch you "de-facto" took away the right of carl to review and commit.
[20:14:08] <av500> Compn: iive: do you think, the situation improves by these "commit speed" games?
[20:14:14] <iive> and I expect roots to counter this "loophole" very soon.
[20:14:28] <iive> av500: is there something wrong in the patch itself?
[20:14:48] <av500> iive: the current issues FFmpeg has are not "technical"
[20:15:18] <Compn> av500 : do you think there is a problem with such patch made by a main developer of ffmpeg ?
[20:16:08] <Compn> av500 : is diego here or is he busy with work ? i dont remember his current status but for a while he didnt have time for the project...
[20:16:15] <Compn> to respond to the speed question of yours
[20:16:55] <Compn> its not even a controversial patch
[20:18:15] <astrange> BBB: i'm already employed fulltime so i don't meet the student requirements. mentoring looks possible. i'll check
[20:18:28] <astrange> fulltime during the summer, i mean
[20:19:32] <iive> BBB: but let's be constructive. Who can review michael's patch. Can you review it and apply it, so the matter could be quickly resolved?
[20:19:38] <hd987> BBB: You do realize by saying things like "we can probably put a link to Michael's repo"  and  "Looks good to me [... ]  As Michael said, it might be nice to be able to point [...], but let that not hold up this initial patch."  you serve nothing other than to feed the confrontational nature of things?  I mean how much harder would it have been to be fair and say "hey ok let's post them both and give them equal foot
[20:19:39] <hd987> ing"
[20:20:06] <Compn> hd987 : well , he reverted michael's patch because we think diego has a patch that does that
[20:20:27] <Compn> hd987 : 'why not just apply the second hunk later?'...
[20:20:53] <iive> I think diego patch already got committed, but it is about git.ffmpeg.org, not git.videolan.org
[20:21:10] <Compn> iive : we are talking about svn://mphq/ffmpeg.org
[20:21:15] <Compn> for homepage
[20:21:31] <iive> for the links to snapshots
[20:21:42] <Compn> are in the homepage repo
[20:21:44] <Compn> ?
[20:21:51] <iive> links are.
[20:22:04] <hd987> Compn: my point is that people are aware the other repo exists, even so much as point it out in communications, but then relegate it to "later"
[20:22:26] <Compn> hd987 : ah
[20:22:56] <hd987> thus, it just feeds the confrontational nature of things...
[20:22:59] <Compn> hd987 : yeah, its annoying to be sure
[20:23:03] <Compn> iive : oh, i see
[20:23:21] <Compn> i dont care about the patch so much so but i want to know if michael can edit ffmpeg.org repo
[20:23:30] <Compn> maybe mru knows
[20:23:48] <iive> no he can't
[20:24:15] <Compn> or if roots changed michaelni's access, did they send him a note at all?
[20:24:20] <iive> i guess roots removed him after he changed the repo link in the middle of the flamewars.
[20:24:32] <iive> (without sending patch first).
[20:24:45] <mru> michaelni's access was revoked after he defaced the page once
[20:24:54] <mru> he noticed as he tried to do it again
[20:24:56] <Compn> ah yes, i had bugged mru to fix it for a week
[20:25:23] <mru> I suggest adding snapshot links to the repo table
[20:25:55] <Compn> michaelni : did anyone tell you that your access was 'revoked' ?
[20:26:21] <Compn> so you guys threw out the policy then, i'm assuming ?
[20:30:46] * Compn frustrated
[20:38:25] <michaelni> Compn, noone told me
[20:40:34] <Compn> shitty way to run a server that is
[20:40:47] <michaelni> and mru, adding a link to the source code repository is not "defacing"
[20:43:05] <lu_zero> yawn
[20:43:24] <lu_zero> you insult people, you get some results...
[20:43:51] <lu_zero> still polite discussion might lead to more interesting results
[20:43:58] <lu_zero> but it's just my opinion
[20:44:00] <lu_zero> btw
[20:44:03] <lu_zero> oink
[20:44:16] <michaelni> lu_zero, where did i insult anyone?
[20:44:35] <lu_zero> michaelni: I explained you before
[20:44:39] <michaelni> btw, lu_zero your yawn & oink are insulting
[20:44:47] <lu_zero> I'm tired
[20:44:54] <michaelni> me too
[20:45:08] <lu_zero> so yawning should be allowed
[20:45:19] <lu_zero> regarding oink
[20:45:31] <michaelni> its allowed just odd timing
[20:45:32] <lu_zero> well it's a swine reference.
[20:45:41] * lu_zero just got home
[20:45:49] <michaelni> well you noticed the From != michael
[20:45:57] <michaelni> on that mail
[20:46:12] <michaelni> with that "swine"
[20:46:20] <lu_zero> yes, the oink was not referred to you =)
[20:46:44] <lu_zero> I was thinking about using it as generic greetings to the other swines =P
[20:46:49] <lu_zero> that said
[20:47:20] <michaelni> ahh, who do you mean by "other swines"?
[20:47:37] <lu_zero> reference to the carl email
[20:47:56] <mru> nÃ¶ff said, let it rest
[20:49:39] <thresh> oh more fun in fflandia
[20:49:59] <thresh> seriously guys, you need to gather together and share a couple of beers
[20:50:13] <mru> a bunch of us did at fosdem
[20:50:17] <mru> some refused to come
[20:51:02] <spaam> thresh++
[20:52:29] <thresh> mru: I obviously mean two opposing sides, not the only one
[20:52:39] <lu_zero> thresh: we tried our best
[20:52:54] <lu_zero> the next step might be gather in vienna
[20:52:59] <mru> thresh: we had beer with the gstreamer guys
[20:53:07] * lu_zero would bring some troll beers
[20:53:13] <thresh> mru: wow, and no one was injured?!
[20:53:19] <lu_zero> thresh: nope
[20:53:26] <mru> turns out they were actually quite nice
[20:53:45] <ubitux> when they were lying on the floor with shard everywhere?
[20:53:53] * lu_zero knew already
[20:53:56] <lu_zero> ubitux: nope
[20:54:11] <lu_zero> that reminds me two things
[20:54:14] <lu_zero> bilboed: poing
[20:56:23] <vcs> hmmm.. seems the assert problem is occuring when the buffer size is at max (len is equal to IO_BUFFER_SIZE) when using url_fseek when it calls fill_buffer.. seems icreasing the buffer it only delays the problem till that many bytes later.. should i be doing another call to clear the buffer before i perform a url_fseek in my demuxer?
[21:00:01] <lu_zero> which demuxer?
[21:00:15] <av500> http://pastebin.com/QwCPYciP
[21:02:54] <vcs> its a new one i am writing for a video format used by a company that does public safety video recording. code is GPL of course but im not sure how useful it will be to anyone :)
[21:04:32] <vcs> basically my question is is there something special i need to do to clear the existing buffer before a url_fseek/get_buffer call
[21:05:20] <BBB> astrange: that would be cool
[21:05:38] <vcs> because I seem to be triggering the assert at line 315 in aviobuf.c
[21:05:39] <BBB> vcs: I don't think so, the code looks fine on a first look, was gone for a bit, let me look again
[21:06:05] <vcs> BBB: i did a step by step walkthrough of the call to fill_buffer
[21:06:35] <vcs> well hmm, i have confused myself now
[21:07:24] <BBB> astrange: if you can come up iwth a good task description for a gsoc2011 project for a student that involves ffmpeg-mt, please post it to me or put it on multimediawiki and we'll get it up
[21:07:45] <BBB> astrange: also, don't worry about it being -mt only, you can combine things like slice+frame-based vp8 multithreading in the same task
[21:07:55] <BBB> astrange: but totally up to you
[21:12:55] <kshishkov> BBB: I'm against those VC-1 features - they are rather small and completely unimportant since no known real file uses them
[21:13:08] <kshishkov> BBB: except for NEON opts of course
[21:13:37] <kshishkov> BBB: interlaced VC-1 samples are at least known to exist
[21:13:55] <av500> yes, came across one today
[21:14:00] * mru has seen many at kshishkov's office
[21:14:05] <av500> in my sample collection, didnt know I had one
[21:14:35] <kshishkov> mru: you got them all and left nothing for me
[21:17:58] <BBB> kshishkov: what if I mentor the other features?
[21:18:20] <BBB> kshishkov: ffmpeg's main purpose is to contain obscure video format features that nobody ever heard of, isn't it?
[21:18:34] <kshishkov> BBB: but only if they are used
[21:18:42] <BBB> I have one sample where they are used!!!
[21:19:21] <kshishkov> reference samples don't count
[21:19:28] <BBB> oh :(
[21:19:46] <kshishkov> work on missing H.264 features instead
[21:20:01] <spaam> BBB: "ffmpeg's main purpose is to contain obscure video format features that nobody ever heard of"  .... why remove sonic codec then? ;P
[21:20:13] <BBB> same reason I guess, no samples
[21:20:23] <BBB> but I have no real opinion on sonic, I've never heard of it
[21:20:39] <av500> BBB: its a very fast hedgehog
[21:20:52] <kshishkov> av500: and it owns DivX
[21:20:53] <BBB> my lab publishes papers on sonic hedgehog, the protein
[21:21:33] <av500> see, its everywhere
[21:23:11] <kshishkov> nevertheless, unsupported existing codecs outside lab environment are FFmpeg's prey
[21:23:52] <iive> define unsupported.
[21:24:12] <Dark_Shikari> Well, hmm
[21:24:17] <Dark_Shikari> if we have Sonic, we could write an extension to it
[21:24:19] <Dark_Shikari> called Tails.
[21:24:38] <BBB> Dark_Shikari: you want to mentor a student for gsoc this year?
[21:24:44] <Dark_Shikari> I'm going to be mentoring for x264
[21:24:53] <BBB> I know
[21:24:53] <Dark_Shikari> ... 'course, we'll need projects to mentor...
[21:25:00] <BBB> but you could mentor ffmpeg also :-p
[21:25:16] <Dark_Shikari> I could, if you have something interesting enough
[21:25:37] <thresh> Dark_Shikari: going to be an admin for standalone application?
[21:25:38] <lu_zero> Dark_Shikari: I was wondering if you'd be interested in mentoring celt
[21:25:48] <Dark_Shikari> no way
[21:25:51] <thresh> not sure jb is going to do admin work this year
[21:25:51] <Dark_Shikari> I don't know enough about audio
[21:25:57] <lu_zero> ah
[21:26:01] <Dark_Shikari> thresh: j-b isn't??
[21:26:11] <Dark_Shikari> wait, then who is apping for videolan?
[21:26:12] <BBB> oh
[21:26:12] <thresh> you better ask him, but that's an impression I had
[21:26:15] <BBB> kshishkov: https://roundup.ffmpeg.org/issue1477
[21:26:21] <BBB> kshishkov: it's used for rtp/vc1
[21:26:37] <BBB> kshishkov: so it _is_ used :)
[21:27:11] <BBB> kshishkov: can I add RTP/VC1 support to that list also? might even be a good qualification task
[21:27:21] <BBB> (just payload depacktizing, not actual proper decoding)
[21:27:25] <kshishkov> BBB: that's not a valid proof, it's probably slight bitstream change
[21:27:26] <Dark_Shikari> interlaced vc-1 should be a gsoc project
[21:27:37] <BBB> Dark_Shikari: it is
[21:27:45] <BBB> kshishkov: ?
[21:27:54] <Dark_Shikari> you should add optimization gsoc tasks
[21:28:03] <Dark_Shikari> like to write things like vc-1 asm, etc
[21:28:09] <Dark_Shikari> Imagine if you had done this for google code-in
[21:28:16] <Dark_Shikari> you'd have 5000 new asm functions by now
[21:28:17] <BBB> Dark_Shikari: I'm working on that, trying to find proper mentors is a task
[21:28:23] <kshishkov> BBB: it's completely wrong in decoding IIRC
[21:28:31] <Dark_Shikari> I can help mentor asm
[21:28:37] <BBB> cool
[21:28:49] <kshishkov> but slices support is one day of work for student at most
[21:28:50] <BBB> kshishkov: I'd like to keep the tasks, I'll mentor these parts, if you're ok with that
[21:28:56] <kshishkov> scling is similar
[21:29:13] <BBB> kshishkov: and I'll work on it anyway, so I might fix it myself before gsoc starts
[21:29:17] <BBB> then we don't have to care at all
[21:29:21] <kshishkov> BBB: mentor whatever you like, I'm too busy+lazy to get off your share
[21:29:38] <BBB> kshishkov: will you mentor vc1 interlaced if there's a student?
[21:30:14] <kshishkov> BBB: yep, but not officially
[21:30:25] <av500> only over pm?
[21:30:35] <kshishkov> or IRC
[21:30:43] <BBB> kshishkov: ok
[21:32:14] <kshishkov> anyway, time to sleep. VC-1 related questions will be ignored for next 11 hours
[21:32:27] <BBB> Dark_Shikari: proposals for optimizations? one I had in mind is to speed up dct coeff reading (like mans did for the neon code) and implement edge extension after reference frame reading for faster MC in subsequent frames in the vp8 decoder (similar to how I implemented ff_emulated_edge_mc simd)
[21:32:30] <spaam> "Christophe Gisquet" who is that?
[21:32:33] <BBB> kshishkov: love you too
[21:32:39] <BBB> spaam: he wrote the existing vc1 asm
[21:32:42] <Dark_Shikari> BBB: Write asm for shit
[21:32:44] <BBB> spaam: he agreed to mentor
[21:32:49] <spaam> BBB: ok :)
[21:32:51] <BBB> Dark_Shikari: oh right got it
[21:32:56] <BBB> Dark_Shikari: h264 asm ideas maybe?
[21:33:18] <Dark_Shikari> h264 is the last thing that needs asm
[21:33:22] <Dark_Shikari> though someone could help irock out
[21:33:36] <BBB> what needs asm according to you then?
[21:33:45] <BBB> swscale? :-p
[21:33:51] * BBB gives lu_zero the ;ppl
[21:33:53] <BBB> look*
[21:34:18] <lu_zero> BBB: swscale needs to be de-asmified first =P
[21:35:02] <spaam> lu_zero: what are you waiting for? :D
[21:35:27] <Dark_Shikari> BBB: 10-bit h264, vc1, porting all of x264's encoding asm, etc
[21:37:29] <spaam> Dark_Shikari: 10bit h264., there was a dude in #x264 working on that?
[21:37:41] <Dark_Shikari> yes, irock
[21:37:43] <Dark_Shikari> he has working decoding in ffmpeg
[21:37:48] <Dark_Shikari> challenge will be getting it merged
[21:37:53] <Dark_Shikari> but it's done and bit-exact iirc
[21:37:58] <Dark_Shikari> there are ffdshow builds with it iirc
[21:38:23] <mru> submit, review, commit
[21:38:27] <mru> what's the holdup?
[21:38:33] <Dark_Shikari> making 8-bit and 10-bit work in the same build
[21:38:39] <Dark_Shikari> templating the entire decoder
[21:38:46] <Dark_Shikari> in a way that doesn't piss everyone off and look horribly ugly
[21:39:08] <mru> so it's not done
[21:39:18] <Dark_Shikari> I never said it was `-`
[21:39:28] <mru> 21:37 <@Dark_Shikari> but it's done
[21:39:54] <Dark_Shikari> well, it's done as in it decodes correctly `-`
[21:39:55] <spaam> so tamplate some stuff and remove it from other things....
[21:41:43] <BBB> Dark_Shikari: yeah, I thought we agreed you'd have to template the decoder... anyway, I'm sure irock knows how to do this
[21:42:35] <j0sh> h264 is becoming the new swscale
[21:43:03] <j0sh> templates flying everywhere
[21:43:04] <BBB> j0sh: no, there's at least >1 person that thinks he knows how it works
[21:43:05] <BBB> :-p
[21:43:11] <j0sh> heh
[21:44:08] <BBB> Dark_Shikari: are x264 people ok with that under lgpl?
[21:44:09] <spaam> BBB: so who knows swscale? lu_zero ?
[21:44:14] <Dark_Shikari> what is "that"
[21:44:20] <BBB> Dark_Shikari: C code, ASM code
[21:44:25] <Dark_Shikari> what c code
[21:44:31] <BBB> ASM code then
[21:44:36] <Dark_Shikari> which asm code
[21:44:42] <BBB> the one that irock is porting
[21:44:47] <Dark_Shikari> he hasn't touched any asm yet
[21:44:48] <BBB> or writing
[21:45:17] <BBB> is irock a college student?
[21:45:31] <Dark_Shikari> I think so
[21:45:44] <BBB> can we sign him up for gsoc?
[21:45:54] <BBB> you could mentor him
[21:46:14] <BBB> .o(***magic***)
[21:46:16] <Dark_Shikari> he was a student last year
[21:46:26] <astrange> 16:42 < j0sh> h264 is becoming the new swscale <- someone write libhwscale
[21:46:59] <BBB> btw, astrange, what's next re: your -mt merging? I just applied your huffyuv patch, am looking forward to the next patchset </nudge> :p
[21:48:52] <astrange> mpeg1 is the next thing to merge
[21:48:58] * beastd wonders why Carl Eugen's commit was offending but secretly overtaking the project wasn't
[21:49:34] <astrange> few more small bugs first. i found a vp3 sample that deadlocks :/
[21:53:18] <BBB> astrange: if you need me to help debugging, let me know, I'd love to get a better handle on that code anyway so debugging it is useful for me :)
[21:56:24] <astrange> helgrinding...
[22:00:28] <astrange> ==47941== Thread #5: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion ==47941==    by 0x1003B6D76: frame_worker_thread (pthread.c:289)
[22:00:44] <mru> ouch
[22:01:02] <astrange> http://people.xiph.org/~maikmerten/youtube/fred-K170-V465.ogv
[22:01:03] <Dark_Shikari> helgrind doesn't support condition variables so isn't it kinda useless?
[22:01:30] <astrange> it detects deadlocks if you run with --error-limit=no
[22:01:35] <mru> Dark_Shikari: correctly analysing the associated mutexes should be enough
[22:02:15] <mru> condition variables in themselves are very hard to abuse
[22:06:30] <rukhsana> Hi
[22:06:53] <BBB> astrange: hah, indeed
[22:07:27] <wbs> BBB: care to push the aviobuf-patch that michaelni ok'd?
[22:07:44] <iive> astrange: I have that in the config file :)
[22:08:12] <iive> astrange: i also have something to increase the backtrace depth and log the output to file
[22:08:30] <wbs> vcs: what ffmpeg version are you working on? there's no assertion that looks even remotely like the one you're trigging in my aviobuf.c
[22:08:50] <superdump> astrange: i'm sure you get asked every five minutes but, what is left to be merged from ffmpeg-mt?
[22:08:56] <vcs> 0.6.1
[22:09:03] <michaelni> wbs, push to videolan :)
[22:09:21] <wbs> vcs: try the latest from git, that sounds like some bug that might have been fixed at some point
[22:09:27] <Dark_Shikari> 0.6.1 is ancient
[22:09:29] <Dark_Shikari> I told you to update
[22:09:33] <wbs> michaelni: that's of course an option :-)
[22:09:47] <vcs> oh shit, my bad. I was building on windows so I just used the version from the tutorial.
[22:09:50] <BBB> I can push in a bit
[22:09:50] * vcs slaps himself
[22:10:20] <vcs> I feel dumb, but I think you guys just have saved me alot of time :)
[22:10:30] <lu_zero> vcs: ^^
[22:10:35] <lu_zero> hi rukhsana
[22:11:01] <rukhsana> I am working on JPEG 2000
[22:11:09] <rukhsana> I am still studying
[22:11:18] <rukhsana> to understand the code
[22:12:07] <vcs> so should I use the main repository? I know there are no guarantees, but should it be stable enough to develop with?
[22:12:11] <Dark_Shikari> yes
[22:12:31] <wbs> vcs: the latest git version should mostly be more stable than the releases
[22:12:50] <wbs> except for when there's some large regression, but such are most often fixed within a day or so
[22:12:58] <astrange> superdump: mpeg*
[22:13:00] <mru> and fate will tell
[22:15:03] <BBB> astrange: and h264
[22:15:18] <astrange> that's mpeg4 part 10
[22:22:06] <BBB> astrange: the problem is probably that the first frame is not an i-frame
[22:22:20] <BBB> so it waits on progress on the ref frame which does not exist
[22:22:30] <BBB> note how without threads the first frame is green
[22:22:53] <BBB> astrange: discard all non-i-frames before the first i-frame and you should be ok
[22:23:12] <mru> green is gorgeous
[22:23:26] <BBB> green means "inexperienced" in dutch
[22:23:30] <BBB> amongst other things
[22:23:48] <astrange> if there's no ref AVFrame, there shouldn't be anything calling cond_wait though
[22:24:01] <BBB> it is really waiting :)
[22:24:15] <BBB> maybe it creates an empty ref frame that is never called report_prorgress() on?
[22:24:16] <astrange> h264 does generate fake ref AVFrames, but i don't remember seeing it in vp3. some printf tracing should find it
[22:25:00] <BBB> if you trace the ff_thread_{report,await}_progress() calls, you'll see both hang on the first wait
[22:25:05] <BBB> and progress is never reporter
[22:25:07] <BBB> s/r/d
[22:25:47] <mru> if an empty ref is created, shouldn't it be reported as complete immediately?
[22:26:35] <BBB> probably
[22:26:36] <BBB> but it isn't
[22:27:27] <astrange> ah it converts the p frame to i when it prints the not a keyframe warning
[22:27:34] <astrange> it's probably to do with that
[22:34:19] <BBB> shouldn't we just discard the frame instead of attempting to decode it?
[22:34:31] <BBB> I guess some of the data might be correct
[22:34:34] <BBB> most won't be though
[22:34:45] <jannau>  
[22:35:35] <iive> for h264 there is mode where no keyframe are issued. the image is supposed to be completely recovered after X frames (where X is written in the bitstream by the encoder).
[22:35:58] <astrange> vp3 doesn't use error resilience
[22:36:03] <Dark_Shikari> that isn't exactly how it works
[22:36:08] <Dark_Shikari> it's supposed to be recovered when frame num == some value
[22:36:10] <Dark_Shikari> not after n frames
[22:36:14] <Dark_Shikari> this is not EXACTLY the same thing.
[22:36:22] <astrange> if it did, you would see the recoverable data and the rest would be something better than bright green
[22:37:08] <Jumpyshoes> Dark_Shikari: so can  you have like frame 1, 50, 150, 255, etc as fully recovered frames?
[22:37:17] <Dark_Shikari> it works like this
[22:37:18] <iive> Dark_Shikari: not sure I see the difference.
[22:37:20] <Dark_Shikari> current framenum = X
[22:37:31] <Dark_Shikari> recovery_frame_cnt = Y
[22:37:38] <Dark_Shikari> framenum when things are recovered = (X+Y)%(max frame num)
[22:37:45] <Dark_Shikari> iive: b-frames don't increment framenum usually
[22:38:14] <mru> BBB: a P (or B) frame might have all or many blocks intra coded
[22:38:34] <BBB> mru: true, good point (I'm not familiar with vp3 though)
[22:38:49] <iive> Dark_Shikari: details....
[22:38:50] <BBB> anyway, I'm sure astrange will soon post a patch :-p
[22:39:02] <mru> me neither, but I assume it has an intra MB mode
[22:39:49] * BBB wonders whether to apply elenril's patch as-is or integrate reimar's changes
[22:42:14] <BBB> Dark_Shikari: can you discuss with irock if he wants to participate as a student integrating his 10-bit h264 changes into ffmpeg?
[22:42:20] <BBB> or irock ^^
[22:42:29] <Dark_Shikari> whenever he wakes up here really
[22:44:32] <BBB> what else would be a useful/fun gsoc task with a mentor
[22:45:19] <BBB> michaelni: want to mentor a student again this year?
[23:28:47] <peloverde_at_wor> anyone know a good tool to view SEIs?
[23:30:47] <mru> hexdump
[23:31:34] <mru> or whip up a parser
[23:31:36] <mru> can't be too hard
[23:32:23] <vcs> if get_buffer is now depricated, what replaced it?
[23:32:27] <vcs> in the devel branch
[23:32:44] <mru> avio_read
[23:32:48] <vcs> ahh, thanks
[23:50:41] <Sean_McG> hmmm... wondering why gsm-ms is failing on kostylev's sparc64-linux box -- does Debian's gcc typically produce 32 or 64 bit binaries by default (with no -m32/-m64)?
[23:53:54] <Sean_McG> I know older gcc's had a zero/sign-extension behaviour difference on SPARC
[23:54:04] <Sean_McG> but I don't think that's it
[23:55:04] <mru> that's just a bug
[23:55:10] <mru> it used to show up on ppc too
[23:55:14] <mru> same gcc version
[23:55:33] <DonDiego> gnite
[23:57:39] <Sean_McG> ah, so not worth investigating further then
[23:58:42] <mru> 4.2 isn't maintained iirc
[23:58:52] <Sean_McG> aye, earliest is 4.3
[23:59:02] <mru> then there's little point
[23:59:54] <mru> it's curious though that it passes on openbsd