[FFmpeg-devel-irc] IRC log for 2010-05-24

[irc at mansr.com]

[00:00:06] <mru> there's nothing mmx-specific about it
[00:00:29] <bcoudurier> ok
[00:17:30] <bcoudurier> mru it's entangled :/
[00:17:39] <bcoudurier> mm_support is also present for arm
[00:17:56] <bcoudurier> and the MM_ are defined in avcodec.h
[00:40:38] <DonDiego> siretart: you wanted me to read through the changelog or something?
[00:40:46] <DonDiego> release notes..
[00:44:53] <CIA-93> ffmpeg: conrad * r23280 /trunk/libavutil/rational.c:
[00:44:53] <CIA-93> ffmpeg: Convert NaN to 0/0 in av_d2q
[00:44:53] <CIA-93> ffmpeg: This fixes aspect ratio calculation for encoding from files with 0/0 stored,
[00:44:53] <CIA-93> ffmpeg: common with ogg/theora
[01:03:03] <DonDiego> Yuvi: 0.6 material?
[01:03:37] <Yuvi> I think so, it's a regression I accidentally introduced (maybe after the 0.6 branch?)
[01:04:02] <DonDiego> please doublecheck, thx
[01:04:29] <Yuvi> r22898, so just before
[01:04:43] <DonDiego> then please merge it
[01:05:17] <Yuvi> hm, I don't have a svn checkout
[01:07:10] <Yuvi> svn merge -r 23279:23280 ?
[01:07:40] <DonDiego> no
[01:08:04] <DonDiego> svn merge -c 23280 ^/trunk
[01:08:37] <DonDiego> nm, i can do it
[01:08:42] <DonDiego> but my machine compiles slowly..
[01:17:20] <bcoudurier> what's still missing for vp8 integration ?
[01:21:10] <astrange> libvpx decode
[01:21:19] <DonDiego> libvpx encode
[01:22:01] <bcoudurier> how does the decoder patch look ?
[01:22:16] <DonDiego> getting better afaict
[01:34:28] <CIA-93> ffmpeg: diego * r23281 /branches/0.6/ (6 files in 2 dirs): Ignore generated files in the libswscale directory.
[02:10:29] <CIA-93> ffmpeg: diego * r23282 /branches/ (0.6/libavformat/oggdec.c 0.6):
[02:10:29] <CIA-93> ffmpeg: Enable AVFMT_GENERIC_INDEX for Ogg demuxer. This avoids the many
[02:10:29] <CIA-93> ffmpeg: seeks needed for binary search when seeking to a previously seen
[02:10:29] <CIA-93> ffmpeg: location.
[02:10:29] <CIA-93> ffmpeg: backport r23279 by reimar
[02:19:09] <DonDiego> Yuvi: about your last commit message..
[02:19:37] <DonDiego> if you start with "this", then your phrasing is automatically bad
[02:20:01] <Yuvi> how so?
[02:20:11] <DonDiego> "this sentence tells you that commit messages should be direct."
[02:20:15] <DonDiego> compare with
[02:20:29] <DonDiego> "commit messages should be direct
[02:20:31] <DonDiego> "
[02:20:36] <DonDiego> see the difference?
[02:20:49] <DonDiego> you are already telling it, no need to tell that you are telling it
[02:21:18] <Yuvi> yes, but with that sentence without the "this" there's no subject for the sentence
[02:21:58] <Yuvi> err, with the sentence in my commit
[02:22:20] <Yuvi> with yours, the subject changes
[02:22:30] <DonDiego> s/this fixes/fix/
[02:22:34] <DonDiego> and you're done
[02:22:48] <DonDiego> shorter even
[02:23:09] <DonDiego> technical prose is very much like code - perfect when you cannot take anything away
[02:24:44] <DonDiego> also, you could end sentences in periods.
[02:25:04] <DonDiego> umm
[02:25:06] <DonDiego> geez
[02:25:11] <DonDiego> sorry
[02:25:38] <DonDiego> i pasted your log message into my editor without the first line
[02:25:50] <DonDiego> Yuvi: forget everything i said
[02:26:09] <DonDiego> it's 4:30am here and my eyes are falling shut..
[02:26:20] <Yuvi> heh, no worries
[02:26:27] <Yuvi> I could be more consistent with using periods
[02:27:14] <DonDiego> if in doubt, follow the rules of proper english
[02:28:37] <CIA-93> ffmpeg: diego * r23283 /branches/ (0.6 0.6/libavutil/rational.c):
[02:28:37] <CIA-93> ffmpeg: Convert NaN to 0/0 in av_d2q
[02:28:37] <CIA-93> ffmpeg: This fixes aspect ratio calculation for encoding from files with 0/0 stored,
[02:28:37] <CIA-93> ffmpeg: common with ogg/theora
[02:28:37] <CIA-93> ffmpeg: backport r23280 by conrad
[02:36:55] <Yuvi> mkvalidator spews errors for all of the mkvtoolnix files I've tried, hmmm
[06:46:26] <wbs> morning
[06:51:06] <bcoudurier> morning
[07:21:44] <_av500_> morning
[07:27:50] <KotH> salve
[08:59:12] <CIA-93> ffmpeg: conrad * r23284 /trunk/ (3 files in 3 dirs):
[08:59:12] <CIA-93> ffmpeg: matroskaenc: Write codec time base as default duration for video tracks.
[08:59:12] <CIA-93> ffmpeg: This isn't exactly semantically equivalent, but the field has already been
[08:59:12] <CIA-93> ffmpeg: long abused to mean this, and writing it helps in determining a decent cfr
[08:59:12] <CIA-93> ffmpeg: time base when transcoding from a mkv where the video codec stores none (VP8).
[10:12:11] <CIA-93> ffmpeg: cehoyos * r23285 /trunk/libavcodec/audioconvert.h:
[10:12:11] <CIA-93> ffmpeg: Fix documentation of av_audio_convert.
[10:12:11] <CIA-93> ffmpeg: Patch by Cyril Russo, stage D nexvision A laposte net
[10:59:38] <dezodorant> why probing doesn`t skip id3?
[11:00:22] <Evgeny> hi! when i added new protocol i add new  field in Makefile. Field like this OBJS-$(CONFIG_RTSPHTTP_PROTOCOL). should i add something somewhere else?
[11:00:25] <Evgeny> thanks!
[11:00:31] <dezodorant> i mean not excluded from probing_size ?
[11:01:42] <jai> dezodorant: ?
[11:01:58] <jai> its skipped properly
[11:02:05] <dezodorant> id3 tag with album art may be as big as probing size
[11:02:27] <jai> so
[11:02:28] <jai> ?
[11:02:34] <dezodorant> one moment
[11:03:00] <dezodorant> http://pastebin.org/273986
[11:03:20] <dezodorant> and with stripped tags
[11:03:38] <dezodorant> http://pastebin.org/273992
[11:08:13] <dezodorant> probably id3 tag should be excluded from probing procedure ? or not ?
[11:13:12] <dezodorant> jai: what do you think about it ?
[11:16:11] <jai> dezodorant: please paste the entire output from ffmpeg -loglevel debug  -i <file>
[11:17:53] <dezodorant> 1st http://pastebin.org/274032 original
[11:17:53] <dezodorant> 2nd http://pastebin.org/274033 stripped
[11:37:24] <lu_zero> wbs: poing
[11:37:33] <wbs> lu_zero: pong
[11:43:57] <lu_zero> wbs: could you give me a tutorial on dss?
[11:44:16] <wbs> sure
[11:44:29] <lu_zero> I wanted to compare the behavior between feng and dss on certain kind of loads
[11:46:40] <wbs> sure... what part do you want a tutorial of? setting it up?
[11:46:49] <lu_zero> basically
[11:47:12] <lu_zero> which is the file to edit in order to get it to listen to 0.0.0.0
[11:47:29] <wbs> I think it listens on all interfaces by default
[11:51:50] <lu_zero> nope
[11:51:59] <lu_zero> it listen to localhost and only that
[11:54:39] <wbs> hmmm, netstat -l -p on one machine reports that it listens on *:rtsp
[11:55:28] <wbs> lu_zero: check /etc/streaming/streamingserver.xml, look for bind_ip_addr
[11:55:34] <wbs> it's set to simply "0" in my case
[11:59:19] <DonDiego> Yuvi: you around?
[11:59:52] <lu_zero> wbs: the dss is up on lscube.org
[12:00:03] <lu_zero> it has the usual sample files there
[12:00:30] <mru> lu_zero: are you coming to linuxtag?
[12:00:41] <lu_zero> I'm hoping to
[12:00:48] <mru> then why haven't you said so?
[12:00:48] <DonDiego> Yuvi: http://samples.mplayerhq.hu/V-codecs/Theora/theora_testsuite/320x240.skeleton%2bcmml.ogv
[12:01:04] <DonDiego> Yuvi: this sample spouts a lot of warnings about
[12:01:08] <mru> you can't expect me to guess who might be coming
[12:01:10] <DonDiego> [ogg @ 0x8b38400]Page at 252669 is missing granule
[12:01:28] <lu_zero> because it's not 100% sure yet =|
[12:01:45] <mru> you could still say that
[12:01:56] <mru> this is not just you
[12:02:00] <mru> it's everybody
[12:02:07] <lu_zero> sorry =\
[12:02:38] <mru> so far only janneg has committed to help with booth setup
[12:02:42] <mru> I find that disappointing
[12:03:35] <lu_zero> If I manage to be there I should be available to help, the problem is that I'm not sure I'll be there yet ^^;
[12:04:26] <DonDiego> http://samples.mplayerhq.hu/V-codecs/Theora/theora_testsuite/ducks_take_off_444_720p25.ogg
[12:04:29] <DonDiego> *** glibc detected *** ./ffplay: munmap_chunk(): invalid pointer: 0xb460a020 ***
[12:04:32] <DonDiego> ouch
[12:04:38] <mru> valgrind it
[12:05:18] <DonDiego> can somebody reproduce?
[12:05:32] <DonDiego> i've never used valgrind before, quick pointers?
[12:07:26] <siretart> wow. ffmpeg ACCEPTED for debian.
[12:07:33] <siretart> experimental, that is
[12:07:54] <KotH> \o/
[12:08:04] <DonDiego> elaborate..
[12:08:18] <KotH> DonDiego: there is a tutorial in the documentation, iirc
[12:09:03] <mru> DonDiego: seriously?
[12:09:10] <mru> what rock do you live under?
[12:09:21] <mru> hint: valgrind program args...
[12:09:41] <jai> valgrind --leak-check=full <ffmpeg command line> is a start
[12:10:58] <hyc> for a crash like this you don't need leak checking
[12:11:52] <lu_zero> valgrind --db-attach=yes might also be useful
[12:12:04] <DonDiego> vex x86->IR: unhandled instruction bytes: 0xF 0xE 0x90 0xE9  0B f=0/0
[12:12:04] <DonDiego> ==13182== valgrind: Unrecognised instruction at address 0x8498DBD.
[12:12:07] <DonDiego> bah
[12:12:18] <DonDiego> valgrind sigill?
[12:12:19] <mru> old valgrind?
[12:12:38] <DonDiego> valgrind-3.3.1-Debian
[12:12:57] <lu_zero> my ffmpeg doesn't crash
[12:13:17] <hyc> 3.3.1 is pretty ancient
[12:13:18] <mru> DonDiego: never use debian versions of anything that matters
[12:13:45] <DonDiego> i usually cannot be bothered to use non-distro versions of most stuff
[12:13:48] <mru> debian, the best in museum-grade software
[12:13:58] <mru> so use a real distro
[12:14:14] <DonDiego> i *like* museum-grade software
[12:14:28] <DonDiego> do you usually worry what ls and groff you are using?
[12:14:39] <jai> hyc: yeah, i didnt see the backlog
[12:14:54] <mru> DonDiego: you'd be surprised
[12:15:08] <lu_zero> groff, yes
[12:15:11] <lu_zero> ls no
[12:15:13] <mru> I always feel crippled when forced to use debian machines
[12:15:37] <hyc> they're not as bad as rhel, but I agree
[12:16:59] <lu_zero> hyc: my most unsettling experience was with centos
[12:17:13] <lu_zero> broken apr while developing a module for apache
[12:17:13] <BastyCDGS> mru, what's the problem with debian?
[12:17:18] <siretart> DonDiego: valgrind is effectively a virtual machine that translates x86 opcodes to a special bytecode that allows sophisticated analysis
[12:17:27] <mru> BastyCDGS: as I said, museum-grade
[12:17:35] <lu_zero> worked perfectly on our systems and not on the production ones...
[12:17:51] <siretart> DonDiego: maybe older versions of valgrind have problems with special amd k6 opcodes?
[12:17:54] <lu_zero> apr_stat was broken ...
[12:18:00] <mru> siretart: yes, they did
[12:18:09] <mru> 3dnow stuff was added rather late
[12:18:25] <DonDiego> i'll see if i can be bothered to upgrade
[12:18:50] <DonDiego> mmu_screen: nice to see your beos patches coming along so well!
[12:19:26] <BastyCDGS> dondiego give ubuntu 10.04 a try, it's based on debian
[12:19:49] <siretart> DonDiego: or try a copy of ffmpeg without k6 3dnow opcodes for your copy of valgrind
[12:19:54] <DonDiego> if i cannot be bothered to install new versions of dev tools, do you think i can be bothered to switch distros?
[12:20:01] <siretart> or use a chroot with newer dev tools
[12:20:03] <lu_zero> that might be the faster route
[12:20:19] <DonDiego> i'm forced to use 10.4 at work - horrible..
[12:20:22] <lu_zero> DonDiego: gentoo-prefix works on debian, not just macosx =P
[12:20:35] <mru> DonDiego: if you cannot be bothered to install usable tools, why do you call yourself a developer?
[12:20:44] <DonDiego> i don't
[12:21:06] <DonDiego> nobody else calls me a dev after all
[12:22:32] <BastyCDGS> dondiego, then try 8.04 that's what I'm working with, too right now and it works without problems for me with ffmpeg
[12:22:47] <DonDiego> i must be speaking chinese
[12:23:19] <lu_zero> BastyCDGS: he loves _his_ debian
[12:23:22] <DonDiego> me no change distro in 5+ years past
[12:23:28] <DonDiego> me no change distro in 50+ years future
[12:23:50] <DonDiego> lu_zero: no, i love spending my time on something else
[12:24:08] <lu_zero> DonDiego: you might just update debian
[12:24:09] <BastyCDGS> well if you not want to change distro, try building valgrind etc. from git?
[12:24:13] <lu_zero> 3.5.0 is there
[12:24:16] <BastyCDGS> or add a backport repository
[12:24:23] <DonDiego> i track stable releases
[12:24:56] <DonDiego> i tried getting bazaar from backports, that did not work so well..
[12:26:09] <BastyCDGS> maybe you can get the source from your debian's valgrind version and add the 3dnow patch manually there and recompile?
[12:27:14] <ramiro> maybe someone can give him ssh access somewhere where this is all taken care of?
[12:27:33] <DonDiego> i'm sure you guys all mean well and it's appreciated and all
[12:27:34] <BastyCDGS> I can give you one and mru probably as well
[12:27:59] * BastyCDGS got one ssh from mru for testing on big endian
[12:28:00] <DonDiego> but really the day has a short few 24h only and i should be spending them on something else..
[12:28:28] <lu_zero> anyway
[12:28:37] <lu_zero> the sample doesn't trigger anything here
[12:28:41] <lu_zero> it's just black
[12:28:52] <DonDiego> it should show some ducks in a ond
[12:28:54] <DonDiego> pong
[12:28:55] <DonDiego> pond
[12:28:58] <lu_zero> I should probably rebuild my ffmpeg and check with the tip
[12:31:02] <DonDiego> bye
[12:31:04] <Vitor1001> DonDiego: Valgrind works fine installed localed as non-root.
[12:31:35] <mru> don't you guys get it? he _wants_ the petrified version
[12:32:31] <BastyCDGS> dondiego, what's wrong with doing this via ssh?
[12:32:35] <DonDiego> i like vintage software to go along with my vintage hardware
[12:32:44] <mru> ffplay doesn't run so well over ssh
[12:33:01] <CIA-93> ffmpeg: cehoyos * r23286 /trunk/libavformat/mpeg.c:
[12:33:02] <CIA-93> ffmpeg: Skip pes payload during probing to avoid start code emulation.
[12:33:02] <CIA-93> ffmpeg: Patch by Janne Grunau, janne-ffmpeg jannau net
[12:33:08] <DonDiego> BastyCDGS: that a) i cannot be bothered b) it likely will not work c) i don't have time
[12:34:16] <BastyCDGS> well if you don't have time it's probably the best to just turn off 3dnow with ffmpeg's configure so your valgrind won't crash anymore
[12:34:31] <BastyCDGS> at least until you have some time to adress that issue
[12:37:49] <ramiro> Vitor1001: hey, I have a question regarding the theory behind the fir filter in mlp, and you seem to know this stuff quite well.
[12:37:50] <Vitor1001> mru: The way I get it, is that he doesn't like modifing his distro. I don't like it either, that's why 99% of the time I use "valgrind ffmpeg_g" and in 1% I do "~/ffmpeg/valgrind-svn/vg-in-place ffmpeg_g"
[12:38:16] <mru> and I run gentoo
[12:38:30] <Vitor1001> ramiro: You can try, but I never took the time to really read the theory of that
[12:38:39] <Vitor1001> I don't think I can be of very big help
[12:38:43] <BastyCDGS> gentoo is a distro I'ld like to test, too.
[12:39:02] <mru> it doesn't work on amiga
[12:39:31] <BastyCDGS> linux works on amiga if you have a 68k with MMU
[12:39:36] <BastyCDGS> but I wasn't talking of amiga ;)
[12:39:43] <lu_zero> mru: I wonder if somebody didn't do
[12:39:50] <lu_zero> we have a 68k port...
[12:39:51] <ramiro> Vitor1001: the fir does something like y[n] = y[n-1] * coeff[1] + y[n-2] * coeff[2] ... + y[n-m] * coeff[m] + x[n]. my teacher says that, theoretically, to be classified as a FIR, it should only use x[n-<something>], and not y[n-<something>]
[12:40:16] <ramiro> by using y[n-<something>], it is an IIR
[12:40:16] <mru> lu_zero: building a distro on a ~50MHz 68k doesn't sound like much fun
[12:41:06] <lu_zero> mru: crossdev and cross-emerge are a boon ^^;
[12:41:15] <Vitor1001> ramiro: I remember having stumbled upon that once
[12:41:30] <BastyCDGS> mru, it really won't be fun ;)
[12:41:39] <lu_zero> tested with the curreng ffmpeg btw
[12:41:42] <BastyCDGS> I never used linux on amiga, though
[12:41:48] <lu_zero> no double free nor crash
[12:42:13] <Vitor1001> ramiro: just a min
[12:43:46] <BastyCDGS> http://linuxonamiga.org/
[12:46:14] <Vitor1001> ramiro: All this make me think about the thread: "[PATCH] allow different input/output buffers for DC	filter"
[12:46:26] <Vitor1001> But I'm not 100% sure it is related
[12:46:42] <janneg> DonDiego: not reproduceable with branches/0.6 r23283 on core2
[12:47:47] <merbzt1>  I might be able to test on a geode
[12:47:57] <BastyCDGS> http://aminet.net/package/gfx/conv/ffmpeg-svnr22669-m68k.lha
[12:48:01] <merbzt1> should match what diego has
[12:48:46] <ramiro> Vitor1001: thanks, I'll check
[12:49:16] <Vitor1001> ramiro: If it is indeed related, don't forget asking Ronald how he didn't needed it after all.
[12:49:28] <janneg> does the k6 have mmx? I can test on phenom with sse* disabled
[12:50:02] <DonDiego> yes, it has mmx, 3dnow and 3dnowext (it's a k6-3+
[12:50:04] <DonDiego> )
[12:50:32] <pross-au> u have a III+, nice
[12:55:58] <ramiro> Vitor1001: hm, I don't think so. I'll ask ronald later, but he's said in the past that he doesn't quite understand the theory...
[12:56:21] <superdump> ramiro: i'm pretty sure what you said above is correct
[12:57:01] <ramiro> superdump: so mlp uses incorrect names?
[12:57:16] <superdump> http://rob.opendot.cl/index.php/2007/09/05/filtering-out-the-crap/
[12:57:20] <superdump> i wrote that from wikipedia
[12:57:24] <superdump> basically
[12:57:44] <lu_zero> wbs: is the dss on lscube.org reachable for you?
[12:58:32] <wbs> lu_zero: yeah, it seems to work just fine, I played a sample from there a few minutes ago
[12:58:46] <lu_zero> uhmm
[12:59:09] <lu_zero> which one?
[12:59:36] <wbs> sample_50kbit.3gp
[13:00:05] <superdump> ramiro: if mlp uses >1 output coefficients then it's using an iir i think
[13:00:11] * lu_zero wonders why the h264_100kbit didn't work
[13:01:07] <superdump> ramiro: actually, i see what you typed now. what are the x[] and y[] arrays precisely?
[13:01:47] <ramiro> superdump: it has one thing it calls the fir filters (which is the one I said above), and another one it calls the iir filter, which I'm not sure why but it does some weird & mask with the msb from the result of the sum.
[13:01:49] <superdump> it looks like you're using y[] as your input samples and x[] as your output
[13:02:13] <wbs> lu_zero: it seems to work just fine for me, but the .mov versions don't work with ffmpeg, only the .mp4 ones
[13:02:13] <superdump> and only one x[] is used, the x[n-0]
[13:02:20] <superdump> so it does indeed look like an fir
[13:02:36] <janneg> DonDiego: are you sure about 3dnow ext? ggc manual mentions it only for athlon
[13:02:42] <lu_zero> ok
[13:02:49] <DonDiego> janneg: yes
[13:02:51] <ramiro> superdump: x[n] are the residuals read from the bitstream, y[n] are the output samples, and the input to the coeffs to the next y[n+1]
[13:03:00] <ramiro> for iir it's different
[13:03:35] <DonDiego> janneg: gcc manual is wrong, new gccs also put mmx2 in my binaries with -march=native and then i get sigill
[13:04:18] <ramiro> superdump: hm, so it's an fir if it's interpreted the other way around, as in x[n] = y[n] - y[n-1] * coeff[1] ...
[13:04:54] <ramiro> I'm not sure if that makes sense. anyways I have to go to class now, I'll read more on this later
[13:06:24] <superdump> mmm, i see what you mean
[13:06:25] <janneg> ./configure --enable-gpl --cpu=k6-3 --disable-sse --disable-ssse3 works fine, but still generates 64bit code. can't build 32bit since the system doesn't have 32bit libs
[13:06:39] <superdump> it uses one input value and multiple output values
[13:06:48] <superdump> so it's like an opposite of the fir
[13:08:27] <merbzt1> fir the output is just based on the input and fixed coeffs
[13:08:52] <merbzt1> iir the output is based on the input, fixed coeffs and the previous output
[13:09:57] <mru> which is pretty obvious
[13:10:20] <mru> if output only depends on input, the output of an impulse will eventually die out
[13:10:36] <mru> hence finite impulse response
[13:10:56] <mru> if old output values also contribute, the impulse response can keep itself going indefinitely
[13:11:13] <superdump> so it's an iir
[13:12:43] <merbzt1> mru ftw
[13:13:04] <mru> what's an ftw filter?
[13:13:13] <merbzt1> even though he needs a hug from time to time ;)
[13:13:19] <merbzt1> for the win
[13:13:32] <merbzt1> not related to filtering
[13:13:33] <mru> I know what ftw means
[13:13:52] <merbzt1> good for you
[13:14:15] <superdump> forward thinking wins
[13:14:44] <mru> not finite transform window?
[13:15:27] <merbzt1> well there are many types of filers
[13:15:45] <merbzt1> some could be named ftw filter
[13:15:52] <merbzt1> if not we could invent one
[13:17:26] <merbzt1> 1 hit in google
[13:17:47] <merbzt1> from 83
[13:17:57] <merbzt1> guess it's not that much used
[13:18:18] <merbzt1> ie we can invent something and use it
[13:18:27] <Tjoppen> odd. get_buffer() fails on EOF (EPIPE) on file protocol even though I check url_feof() before reading. ftell() reveals it is actually at EOF
[13:19:43] <mru> we'll also need the inverse, the wtf filter
[13:20:00] <merbzt1> \o/
[13:20:30] <mru> btw merbzt1, do you know yet if you'll make it to linuxtag?
[13:20:40] <merbzt1> nope :/ not yet
[13:20:48] <merbzt1> pending
[13:22:13] <mru> let me know if I should send my team of persuaders somewhere
[13:24:15] <Tjoppen> ah, it relies on figuring out get_buffer() returned <= 0 the previous call. fair enough I guess
[13:36:23] <dezodorant> jai: u here?
[13:52:47] <DonDiego> Yuvi: your assistance required
[13:53:04] <DonDiego> gregory maxwell has thrown the gauntlet..
[13:53:09] <mru> link?
[13:53:20] <DonDiego> http://people.xiph.org/~greg/cb/cb_60_ffmpeg.png
[13:54:25] <mru> and what's that supposed to be?
[13:54:29] <thresh> looks like 'life' game
[13:56:37] <DonDiego> http://people.xiph.org/~greg/cb/controlled-60.ogv
[13:56:47] <DonDiego> ffplay doing this sample
[13:57:08] <DonDiego> i get a crash again..
[13:57:19] <DonDiego> maybe i shall have to update valgrind after all..
[13:57:23] <DonDiego> can anybody reproduce?
[14:00:39] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/controlled-60.ogv
[14:00:48] <DonDiego> i put the sample in the usual spot
[14:01:03] <mru> what's gregory claiming this time?
[14:01:22] <DonDiego> that libtheora is faster than fftheora..
[14:01:34] <mru> how did he measure?
[14:01:48] <mru> bet he included some expensive colourspace conversion for ff but not lib
[14:02:06] <kshishkov> mru: measure? You posted that link to Dilbert strip - "pull numbers out of your..."
[14:02:27] <DonDiego> http://myrandomnode.dyndns.org:8080/~gmaxwell/theora/implementations.png
[14:02:29] <DonDiego> http://myrandomnode.dyndns.org:8080/~gmaxwell/theora/implementations2.png
[14:03:40] <mru> hardare? configure flags?
[14:03:46] <mru> that's not very specific
[14:04:17] <DonDiego> http://people.xiph.org/~greg/cb/
[14:04:26] <DonDiego> shall i forward you the mail?
[14:04:31] <janneg> strange spike for libtheora at 2600kbps
[14:04:54] <mru> DonDiego: is he harassing you in private mail?
[14:05:07] <DonDiego> no, foms list
[14:05:19] <DonDiego> r
[14:06:44] <DonDiego> they complain about the vorbis encoder as well
[14:06:52] <DonDiego> rightly so
[14:07:07] <DonDiego> i guess we could just disable it on the release branch
[14:07:59] <wbs> DonDiego: there's a patch in discussion that would prefer external libraries over knowingly experimental encoders, if that one's accepted I guess it's more conforming just to pick that one
[14:08:19] <janneg> or wait for my experimental codec caps being committed
[14:08:28] <wbs> that's the one I meant
[14:09:16] * janneg still has to finish the fix for ffmpeg -acodec vorbis
[14:10:05] <Compn> DonDiego : btw i meant to check ogg vorbis and oggds/ogm files with -demuxer lavf , not just theora :)
[14:10:48] <DonDiego> go for it :)
[14:11:09] <DonDiego> i'm fine with any solution
[14:11:23] <DonDiego> but the vorbis encoder has been a sticking point for too long
[14:11:32] <BBB> does anyone oppose if we commit the vp8 libvpx-based decoder while we work on our internal one?
[14:12:11] <Compn> BBB : no, its useful to have reference to test internal one
[14:12:12] <mru> only if the patch is clean
[14:12:21] <BBB> clean the patch
[14:13:11] <BastyCDGS> hi BBB :)
[14:13:30] <BastyCDGS> nice to see you, quite a long time since our last meeting ;)
[14:13:40] <BBB> you had exams, I had a meeting, I guess ;)
[14:13:44] * BBB was off for a few days also
[14:13:56] <BastyCDGS> yes exactly
[14:13:58] <merbzt1> where is my student ....
[14:15:55] <BBB> ah, gsoc starts today?
[14:15:57] <BBB> where is my student
[14:16:12] <BBB> I guess he did quite well in his qualification already
[14:16:17] <Compn> shouldnt you guys have schedules in place already? :P
[14:16:26] <BBB> my schedule is simple: finish asap
[14:16:28] <Compn> like be on irc from x-y each day
[14:16:29] <Compn> :P
[14:16:43] <kshishkov> where is my WVP2 decoder?
[14:16:45] <mru> be on irc 0-24
[14:16:58] <BastyCDGS> yes GSoC starts today, that's why I did upload the UAE stuff yesterday to upload.ffmpeg.org for testing tucomposer and also posted a mail for MOD implentation ;)
[14:16:59] <BBB> kshishkov: vp8 is more important imo
[14:17:01] <Compn> kshishkov : did you work on indeo at all ?
[14:17:09] <BBB> hey ai
[14:17:11] <BBB> oops
[14:17:11] <BastyCDGS> hi jai
[14:17:12] <BBB> jai
[14:17:15] <Compn> michael wants comments from indeo devels, but i dont remember who works on that file
[14:17:32] <kshishkov> Compn: I've sent the reply to that
[14:17:42] <Compn> oh good :)
[14:17:42] <jai> ohai BBB, BastyCDGS
[14:17:47] <Compn> indeo3 > alan smithee
[14:17:48] <Compn> hmmmmm
[14:18:06] <kshishkov> he's on Wikipedia
[14:18:19] <kshishkov> quite a famous guy in Hollywood
[14:18:50] <Compn> yes i saw his movie 'burn hollywood burn'
[14:20:33] <BastyCDGS> BBB just read and replied to the IFF patch
[14:20:38] <CIA-93> ffmpeg: jai_menon * r23287 /trunk/ffplay.c: FFplay : Implement custom reget_buffer for the input filter.
[14:20:41] <BastyCDGS> should I really change this?
[14:21:01] <BBB> I'll look later, I can't help much yet
[14:21:21] <BastyCDGS> btw, I just found another solution: make it uint8_t as you said buf do a if ((int) value >= 0)
[14:21:42] <BBB> we're trying to get rid of ugly casts
[14:21:46] <BBB> not add them :)
[14:23:18] <dezodorant> jai: so back to probing: is it right behavior or not ?
[14:23:40] <DonDiego> http://samples.ffmpeg.org/V-codecs/Theora/controlled-60.ogv
[14:23:49] <DonDiego> can somebody quickly run this through ffplay?
[14:24:21] * Compn downloads latest ffplay
[14:25:00] <BastyCDGS> BBB, I will change it only if you really want me to do this
[14:25:16] <hyc> I got a single image
[14:25:23] <hyc> DonDiego: what is the expected output?
[14:26:39] <kierank> hehe ffmpeg can't handle an sps_id of 31 it seems
[14:27:11] <BBB> BastyCDGS: I will check later today
[14:27:30] <jai> dezodorant: do you have a sample i could look at?
[14:27:39] <dezodorant> yes
[14:27:46] <BastyCDGS> BBB, if you haven't noticed yet, I just fixed the enabled-avfilter crash with IFF decoder ;)
[14:28:05] <jai> dezodorant: please upload to incoming
[14:29:57] <dezodorant> mb http://myau.su/29cec1bf-59f5-11df-9ebd-000423b32792 fine too ?
[14:30:54] <janneg> dezodorant: plays fine
[14:30:59] <janneg> DonDiego: ^^^
[14:31:06] <DonDiego> hmm
[14:31:08] <DonDiego> cpu?
[14:31:16] <DonDiego> trunk or release?
[14:31:29] <janneg> hyc: video of a controlled burning of a wodden house
[14:31:35] <janneg> trunk
[14:31:55] <hyc> janneg: yeah, after I downloaded it completely it played
[14:31:59] <DonDiego> revision?
[14:32:03] <hyc> it didn't stop by itself though, at the end of the video
[14:32:12] <janneg> DonDiego: core2 and 0.6 plays it fine too
[14:32:15] <hyc> before I just tried to play it off the URL
[14:32:32] <hyc> I'm on -r23210
[14:32:32] <janneg> r23286
[14:32:45] <DonDiego> hyc: ffplay does not exit
[14:32:47] <jai> dezodorant: ok, thx
[14:33:01] <hyc> DonDiego: right, didn't exit
[14:33:16] <dezodorant> probably i need a little bit more help
[14:33:24] <dezodorant> https://roundup.ffmpeg.org/issue1954
[14:33:40] <dezodorant> i need direction where to serach
[14:37:01] <elenril> dezodorant: use git bisect?
[14:38:08] <dezodorant> it`s in avformat or avcodec ?
[14:38:17] <dezodorant> probing in format
[14:38:35] <jai> per container probe functions are in lavf
[14:38:37] <elenril> probing is done in lavf
[14:39:06] <elenril> it's a read_probe function in AVInputFormat struct
[14:39:15] <janneg> DonDiego: that's by design, use -autoexit
[14:39:21] <dezodorant> and how about packet parsing ?
[14:42:05] <dezodorant> as far as i can see mp3 packet parsing in avcodec but i cannot find where we deciding to use packet or discard
[14:51:46] <kierank> so...anybody interested in fixing get_ue_golomb_31 ? ;)
[14:53:54] <lu_zero> wbs: could you please test run_a_lot_of_clients (in feng contrib) agains your dss setup and against a feng with the same content?
[14:54:15] <lu_zero> some numbers might be 100 10 or 10 100
[14:54:55] <lu_zero> (remember to issue a killall ffmpeg after since I still forgot to cleanup properly =p)
[15:05:05] <mru> kierank: what's the problem with it?
[15:06:11] <kierank> it's broken. It causes files with an sps_id of 31 to not decode.
[15:06:31] <kierank> when you replace it with the normal get_ue_golomb everything works normally
[15:06:53] <kierank> this bug: http://roundup.ffmpeg.org/issue1930
[15:10:37] <DonDiego> bye
[15:46:50] <jai> dezodorant: btw, for now you can use a bigger probesize to workaround the problem
[15:47:36] <dezodorant> i`m stripping tags as a workaround) anyway i`m filling them from db
[15:47:49] <jai> you dont need to do that
[15:48:19] <jai> in your script/whatever just add a -probesize 10000000
[15:48:25] <jai> before -i
[15:48:40] <dezodorant> it`s handmade app
[15:49:18] <jai> i'd be interested in knowing why this is a regression though
[15:52:20] <janneg> jai: several probing functions got stricter last year
[15:55:03] <dezodorant> jai: i haven`t found any specs about mp3 packets, so maybe it`s not a regression.
[15:58:25] <ramiro> superdump, merbzt1: so both filters in mlp (what it calls fir and iir) are actually iir?
[15:59:01] <BBB> fir is inverse iir
[15:59:02] <BBB> basically
[15:59:10] <mru> iir has feedback, fir doesn't
[16:00:42] <ramiro> take a look at the code in lavc/mlpdsp.c, both use result to update their buffers
[16:00:45] <jai> janneg: yes, but that wouldn't lead to this
[16:01:43] <jai> dezodorant: the problem here is just that the second id3 tag is too big
[16:01:46] <ramiro> iir ends up being residual - accum&~mask, I have no idea why that is. (the lsb from mask being subtracted)
[16:02:06] <dezodorant> jai: i`m talking about other issue
[16:02:13] <dezodorant> https://roundup.ffmpeg.org/issue1954
[16:02:17] <dezodorant> this one
[16:02:22] <BBB> ramiro: look at celp_zero_synthesis_filter and celp_synthesis_filter
[16:02:28] <jai> dezodorant: you are skotopes?
[16:02:31] <BBB> ramiro: most likely iir is synthesis ad fir is zero
[16:02:32] <dezodorant> yes
[16:02:42] <jai> dezodorant: oh, i remember you around here :)
[16:03:00] <dezodorant> my nick is catched by someone else
[16:03:11] <dezodorant> so i got new name ;(
[16:03:14] <ramiro> msg nickserv ghost?
[16:03:20] <jai> dezodorant: heh, you should've /register'd
[16:04:45] <dezodorant> now i am
[16:04:57] <ramiro> dezodorant: skotopes last seen 36 weeks ago. ask a freenode admin to unregister that guy and take his place
[16:05:03] <ramiro> that's how I got my nick =)
[16:05:15] <mru> ramiro: I thought it was your name
[16:05:21] <ramiro> lol
[16:05:23] <BastyCDGS> one question, what's wrong with this patch from ami_stuff?
[16:05:24] <BastyCDGS> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073638.html
[16:05:38] <ramiro> mru: apparently I'm not the only ramiro on freenode
[16:05:39] <mru> it's from ami_stuff
[16:05:43] <mru> that's usually a bad sign
[16:06:10] <BastyCDGS> why? what's wrong with him?
[16:06:20] <mru> his patches are usually no good
[16:06:32] <dezodorant> ramiro: i`m like all other sysadmins is a little bit lasy for this
[16:06:55] <ramiro> dezodorant: it takes 5 minutes...
[16:07:37] <BastyCDGS> I just noticed that he does a #define MULH MULH what's the sense of this?
[16:08:04] <mru> the real problem is that his patches are untested and untestable
[16:08:40] <BastyCDGS> I can test them but reading his asm code shows me that his MUL64 isn't optimal
[16:08:48] <mru> I expected as much
[16:09:06] <mru> how would you test though?
[16:09:06] <BastyCDGS> I did one MUL64 for TuComposer which is less half of the size
[16:09:15] <BastyCDGS> UAE ;)
[16:09:28] <mru> no gcc version is able to build ffmpeg for m68k
[16:09:47] <mru> I tried all that would even build themselves once
[16:09:51] <mru> half failed to build
[16:09:52] <BastyCDGS> the latest ffmpeg for m68k is built with gcc-4.5
[16:09:54] <mru> the rest failed on ffmpeg
[16:09:58] <BastyCDGS> as published on aminet
[16:10:24] <BastyCDGS> but he changed some stuff in the original FFmpeg code
[16:10:32] <mru> besides, we don't care about emulators
[16:11:15] <BastyCDGS> btw, I meant this one (it's not a direct download link):
[16:11:16] <BastyCDGS> http://aminet.net/package/gfx/conv/ffmpeg-svnr22669-m68k.lha
[16:11:27] <BastyCDGS> it leads to an info page describing the package
[16:12:42] <BastyCDGS> I also can test it on my native amiga if you wish
[16:13:00] <BastyCDGS> but true amiga support is something I want to do after GSoC has finished
[16:13:16] <mru> oh lord, have mercy
[16:13:53] <kierank> lol
[16:15:44] <BastyCDGS> mru, I see you're the greatest amiga fan I ever seen *gg*
[16:22:35] <BastyCDGS> mru, ami_stuff should at least use a function pointer which sets to correct MULU64 if it's a 68060 or not
[16:22:56] <mru> no function pointers there
[16:23:23] <BastyCDGS> I mean such stuff like you do with x86 optimizations, pointer which uses either 3dnow, mmx, sse2, sse3 etc.
[16:23:39] <mru> the mul64 and related functions must be inlined
[16:23:52] <BastyCDGS> oh ok then it's a bad idea
[16:24:20] <BastyCDGS> then he should do sth. #if ARCH_MC68060 or sth. like that
[16:24:50] <mru> why did they remove the 64-bit multiply in 68060?
[16:25:24] <BastyCDGS> that was a decision I understand as much as you probably do => null
[16:25:35] <BastyCDGS> maybe the circuit designer had drunk to much beer?
[16:26:23] <BastyCDGS> it's not only 64-bit multiply but also 64/32->32 division
[16:26:36] <mru> division is much less important
[16:37:07] <BastyCDGS> yes of course just wanted to mention this for sake of completeness
[16:43:06] <CIA-93> ffmpeg: jai_menon * r23288 /trunk/libavformat/utils.c:
[16:43:06] <CIA-93> ffmpeg: Display a more descriptive log message when probe buffer limit is
[16:43:06] <CIA-93> ffmpeg: reached.
[16:56:05] <BBB> andoma, mru: if you care, please reply to BastyCDGS's mailinglist thread about mod support
[16:56:14] <BBB> some comments would be appreciated ;)
[16:56:16] <hyc> they removed instructions whenever profiling commercial apps showed they were unused
[16:57:06] <hyc> and presumably they needed to simplify something else
[17:00:10] <_av500_> ############################################################
[17:01:57] * _av500_ wrestles netbook from little son's hands
[17:03:50] <Vitor1001> BastyCDGS: Just a question about TUComposer (yes, I'm too lazy to read the source):
[17:03:51] <hyc> oh, I thought you were just providing comments...
[17:04:47] <Vitor1001> does it converts all the possible formats to some internal format that it them tries to actually convert to raw audio or every "decoder" does it on its own?
[17:05:53] <BastyCDGS> viktor, yes it converts them to an interal format and then always playbacks this internal format to raw audio
[17:06:46] <Vitor1001> Hmmm, have you considered adding a new AVMediaType?
[17:07:19] <Vitor1001> I mean, we don't have a libavcodec_video and a libavcodec_audio, so I wonder why sampling formats should have its own.
[17:07:43] <Vitor1001> ITOH, maybe putting the code than converts the internal format to raw audio might fit in libavsomething...
[17:09:27] <BastyCDGS> the internal format is also used for stuff like pattern display etc.
[17:09:43] <BastyCDGS> but AVMediaType sounds interesting too.
[17:11:52] <Vitor1001> Doing a pattern display in libavcompose look a good idea too.
[17:12:28] <Vitor1001> What will be a PITA is that changing the fields of the internal format will break the API
[17:12:34] <BastyCDGS> do you know OpenCubicPlayer?
[17:12:57] <Vitor1001> How much typically the internal format changes when adding support for a new format?
[17:13:15] <Vitor1001> I know practically nothing about sampling formats :(
[17:13:24] <Vitor1001> I just read your msg ;)
[17:14:05] <BastyCDGS> it won't be much anymore and it can be added with backward compatibility, I have a reserved field for this which is set to 0
[17:14:18] <BastyCDGS> so if we add new features the code simply checks if that's non 0 and uses it
[17:14:20] <Vitor1001> brb
[17:26:07] <jai> i used to use ocp on dos
[17:26:51] <_av500_> BastyCDGS: do we really expect new tracker formats?
[17:27:18] <BastyCDGS> jai, cp has a really nice output, right?
[17:27:44] <BastyCDGS> av500, more likely than not
[17:28:38] <jai> BastyCDGS: yep
[17:29:01] <jai> hmm, i think ryg used to work on ocp
[17:29:21] <jai> kb too
[17:29:30] <BastyCDGS> did you like CP 1.7 more than the newer 2.x for DOS too?
[17:31:41] <jai> yeah, but bugfixes went to the 2.6 branch iirc so i switched
[17:31:58] <BastyCDGS> wuerfel mode ;)
[17:32:48] <jai> i dont even remember clearly, i think that was in early 98 or something
[17:32:57] <jai> BastyCDGS: heh
[17:33:30] <BastyCDGS> the animated dice with cp1.7
[17:41:03] <wbs> hyc: btw, tip of the day for easier review, when starting new threads, don't start them as replies to a previous thread by just changing the subject; my mail client groups those messages within the old thread
[17:41:22] <wbs> hyc: (it took me quite a while to dig up the patch that you said shouldn't be controversial)
[17:46:40] <hyc> wbs: hm, ok. I figured replying would keep everything in a single thread.
[17:46:52] <hyc> and all of these patches are closely related
[17:47:38] <wbs> hyc: yeah, but when there are numeruous patches, some applied and some not, at different places in the threads, it quickly gets hard to keep track of
[17:47:58] <wbs> I'm looking at the cleanup patch now at least
[17:48:06] <hyc> ok
[17:48:51] <wbs> lu_zero: I'll try it in a while, ping me later if I haven't gotten back to you on it
[17:50:18] <CIA-93> ffmpeg: reimar * r23289 /trunk/libavformat/ (md5enc.c Makefile allformats.c): Add -f framemd5 muxer similar to framecrc.
[18:15:40] <Vitor1001> BastyCDGS: where is the TuComposer sourcecode?
[18:16:04] <BastyCDGS> either grab the UAE files on upload.ffmpeg.org
[18:16:06] <BastyCDGS> AMIGA subdir
[18:16:35] <BastyCDGS> or from my site: http://forum.cdgs-crew.com/viewforum.php?f=11
[18:16:44] <Vitor1001> Amiga.7z?
[18:16:55] <BastyCDGS> the whole sub dir
[18:17:06] <BastyCDGS> WB39.7z, ROMS.7z and AMIGA.7z are essential
[18:17:17] <Vitor1001> Ok, but the C files?
[18:17:29] <BastyCDGS> are in WB39.7z or on the site
[18:18:01] <hyc> wbs: does this reply make sense to you? https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088962.html
[18:18:10] <BastyCDGS> if you want to use UAE also get ffmpeg-.uaerc (for linux) or the FFmpegWinUAE.uae (WinUAE)
[18:18:27] <BastyCDGS> you just have then to adjust the path stuff in the config files and can go on
[18:18:49] <wbs> hyc: don't know h264 well enough to comment on that
[18:19:10] <hyc> I tried to look at the mkv demux but didn't see anything relevant
[18:23:54] <hyc> likewise in the mov demux
[18:35:58] <Vitor1001> BastyCDGS: Does TuComposer decodes the whole file to a TuComposerTrackData before playing?
[18:36:30] <BastyCDGS> To a TuComposerModule structure which contains the track data
[18:36:42] <BastyCDGS> like I wrote yesterday evening on FFmpeg (the 7 points)
[18:36:46] <Vitor1001> It is never too big?
[18:37:03] <BastyCDGS> I tested with 2 KB mods up to 30 MB IT modules w/o problems
[18:37:18] <mru> there's always a bigger input file
[18:37:32] <BastyCDGS> I allocate memory dynamically there ;)
[18:37:48] <mru> if I have 2GB of ram an the input file is 10GB?
[18:37:59] <BastyCDGS> Out of Memory...
[18:38:06] <mru> fail
[18:38:07] <BastyCDGS> tucomposer checks mem allocation result for NULL
[18:38:13] <mru> wow, impressive
[18:39:01] <BastyCDGS> I made some thoughts of partially loading modules into memory
[18:39:02] <Vitor1001> Now someone will find a way to create a 10GB MOD just to prove a point ;)
[18:39:08] <BastyCDGS> but there's no implementation of it yet
[18:39:21] <mru> Vitor1001: not necessary
[18:39:22] <BastyCDGS> TCM files can't be larger than 4 GB
[18:39:26] <mru> it only runs on amiga anyway
[18:39:27] <BastyCDGS> like any IFF/RIFF file
[18:39:30] <mru> and they don't have that much ram
[18:39:36] <mru> 1GB should be more than enough to kill it
[18:39:43] <Vitor1001> mru: Doesn't ffmpeg does more or less the same with images?
[18:39:57] <Vitor1001> I mean, what if we feed it a 20GB image?
[18:40:09] <mru> Vitor1001: well, it's a assumed you have enough memory to hold one frame
[18:40:16] <mru> and reference frames when needed
[18:40:28] <BastyCDGS> btw, standard protracker modules can't be even that big, there are 31 samples maximum with 64KB size of each
[18:40:37] <mru> ffmpeg was never designed to work on single, insanely large images
[18:40:38] <BastyCDGS> so 31*64 KB + pattern data (which is limitted to 255*1KB)
[18:40:56] <mru> what if I want to make a file with a playtime of 10 years?
[18:41:05] <BastyCDGS> using loop commands
[18:41:13] <mru> without loops
[18:41:25] <mru> suppose I connect it to the midi feed from my friend's studio
[18:41:30] <BastyCDGS> set speed to 255 and bpm to 32
[18:41:39] <mru> no, no... I want full quality
[18:41:43] <BastyCDGS> with TuComposer you can do it
[18:41:49] <BastyCDGS> just not with the original MOD format
[18:41:53] <mru> not if it keeps everything in ram
[18:41:56] <BastyCDGS> IT/XM should be fine too
[18:41:57] <mru> there is always a limit
[18:42:46] <BastyCDGS> yes of course
[18:43:05] <mru> unless you design it not to load everything into ram
[18:43:21] <mru> loading all samples upfront is probably reasonable
[18:43:32] <mru> but not the actual note data
[18:43:42] <mru> that needs to be read and interpreted as you go
[18:44:04] <BastyCDGS> samples are far bigger than note data so it would make more sense to load the samples from disc
[18:44:08] <BastyCDGS> and keep the notes im RAM
[18:44:17] <Vitor1001> I was thinking that if you go with the AVMediaType design, you can work in parallel with implementing the formats (and making commands like "ffmpeg -i my_song.s3m my_song.xm" work) and implementing the library that will be able to play it.
[18:44:18] <mru> not if the note data is _really_ long
[18:45:35] <mru> may I express my deep doubt over the success of such a project?
[18:45:36] <BastyCDGS> one note per channel is usually 4-8 bytes long (1 byte: octave/note, 1 byte cmd byte, 1 byte data byte and 1 byte vol cmd byte)
[18:45:52] <mru> multiply that by a few billion then
[18:46:14] <BastyCDGS> let's say you have 64 channels
[18:46:32] <BastyCDGS> 4*64 = 256 bytes per row
[18:46:45] <mru> suppose for sake of argument one note = one byte
[18:46:51] <mru> if your file has one note played per second
[18:47:30] * elenril wonders if there's something like pulseaudio that doesn't suck
[18:47:43] <mru> elenril: suck is the very definition of pulseaudio
[18:47:51] <mru> so being like it without sucking is not possible
[18:48:05] <BBB> I don't quite understand what's wrong with exposing it as a mod-codec as a default audio codec
[18:48:09] <mru> anyway, you'd still reach a few GB after a few decades
[18:48:32] <mru> and realistically you'd need much more memory per note
[18:48:41] <mru> and notes are far more frequent
[18:48:55] <elenril> mru: s/like pulseaudio/something with more features than alsa/
[18:49:06] <Vitor1001> BBB: You mean making outputting SAMPLE_FMT_COMPOSER?
[18:49:07] * mru wants less features, not more
[18:49:11] <BBB> Vitor1001: exactly!
[18:49:23] <BastyCDGS> SAMPLE_FMT_COMPOSER sounds really neat :)
[18:49:25] <BBB> Vitor1001: somehow you're way too bright
[18:49:31] <Vitor1001> lol
[18:49:32] <mru> composer is a bad name
[18:49:37] <elenril> mru: alsa fails horribly at dynamic config
[18:49:41] <BBB> SAMPLE_FMT_MOD is what I would call it
[18:49:45] <mru> elenril: so configure it statically
[18:49:46] <BBB> but you probably already understand what I mean
[18:49:49] <elenril> i.e. an external soundcard
[18:49:52] <BBB> it allows copying from one to another mod
[18:49:57] <BBB> and allows decoding to wave
[18:49:58] <BastyCDGS> what about SAMPLE_FMT_MULTICHANNEL
[18:50:03] <mru> eh what?
[18:50:08] <ohsix> elenril: do you have something in mind? /j #pulseaudio
[18:50:15] <BBB> BastyCDGS: what is that?
[18:50:20] <Kovensky> hm, is (0 > NaN) true or NaN
[18:50:26] <mru> false
[18:50:35] <mru> any comparison to nan is false
[18:50:35] <BastyCDGS> oh just because modules usually use lots of channels
[18:50:42] <mru> so?
[18:50:44] <BBB> BastyCDGS: it's still mod :)
[18:50:46] <Kovensky> ok
[18:50:48] <BBB> SAMPLE_FMT_MOD makes sense
[18:50:54] <BBB> or SAMPLE_FMT_COMPOSER
[18:50:58] <BBB> whatever, give it a cute name
[18:51:04] <BastyCDGS> I'ld prefer SAMPLE_FMT_COMPOSER
[18:51:05] <mru> KITTEN?
[18:51:14] <BBB> mru: awesome
[18:51:20] <BastyCDGS> we could add support MID support later too
[18:51:23] <BBB> kitty is better
[18:51:26] <BBB> SAMPLE_FMT_KITTY
[18:51:27] <BastyCDGS> like opencubicplayer does
[18:51:36] <BastyCDGS> it can also play .MID files using MOD engine
[18:52:09] <BBB> so you need a demuxer/decoder (dmx can be "raw"-style)
[18:52:21] <BBB> the decoder "converts" from mod format to an internal composer-representation
[18:52:27] <BBB> and an audioconvert-style extensions converts that to wave
[18:52:33] <BBB> and voila, we can play mod :)
[18:52:46] <BBB> ffplay.c wouldn't even have to be modified
[18:53:36] <BBB> and yes, midi support could be "designed in" as well
[18:53:52] <_av500_> BBB: what is pts dts for a packet of notes?
[18:54:04] * Kovensky abuses undef as an integer NaN
[18:54:08] <BBB> for all I care we start assining it AV_NO_PTS
[18:54:34] <BastyCDGS> and if a mod format gets an encoder it just takes the internal composer-representation to do this ;)
[18:54:35] <BastyCDGS> grewa
[18:54:40] <_av500_> but what u get out of a decorder is assumed timeable
[18:54:46] <BastyCDGS> BBB, TuComposer has MIDI support designed in
[18:54:47] <BBB> let's not bikeshed until a simple implementation exists :)
[18:54:48] <Vitor1001> BBB: The problem imho of outputting audio is that
[18:54:48] <Vitor1001> 1) all the audio AVContext fields with be somewhat meaningless (bit_rate, sample_rate, etc). channels might be the exception.
[18:54:48] <Vitor1001> 2) the allocation will be probably made by the decoder
[18:54:51] <BastyCDGS> samples can have MIDI channel etc.
[18:55:10] <BBB> Vitor1001: I think that describes 95% of our audio codecs
[18:55:36] <BBB> Vitor1001: for each, only a small subset of AVCodecCtx fields are used/filled in
[18:56:00] <BastyCDGS> bits_per_sample could be used for number of channels in the internal mod
[18:56:03] <Vitor1001> All the players need a sample_rate, even if the demuxer sets it
[18:56:06] <BastyCDGS> channels is output of mixer
[18:56:36] <Vitor1001> The fields are also there for video and will be there for AVMEDIA_COMPOSER.
[18:56:50] <Vitor1001> What change is what client application might expect to do with it.
[18:56:55] <BastyCDGS> one thing to note, .MID playback using a MOD engine requires sth. like GUS patches
[18:57:35] <Vitor1001> But I agree, changing the audio convert framework to accept SAMPLE_FMT_COMPOSER will make everything work automagically...
[18:58:12] <BBB> we might want to "extend" sample_rate a bit, so you can set it to whatever-you-please and the decoder may override it (always does, except for mod)
[18:58:22] <BBB> or maybe request_samplerate, like we have request_channel_mask
[18:58:23] <BastyCDGS> maybe we don't have to do this
[18:58:34] <BastyCDGS> just add an extra field which is only used if SAMPLE_FMT_COMPOSER is set
[18:59:00] <BastyCDGS> field could be point to AVComposer structure which is similar to TuComposer library base
[18:59:22] <BastyCDGS> (according to the 7 points)
[18:59:48] <BastyCDGS> AVComposer contains a player handler and a pointer to the module data
[18:59:58] <BBB> BastyCDGS: do you think you can write A) an audioconvert.c extensions that converts SAMPlE_FMT_COMPOSER to float/s16/u8, B) a raw demuxer that forwards mod packets to an audio decoder, and C) a set of mod decoders in libavcodec/mod(*).c that decodes file data into SAMPLE_FMT_COMPOSER, which yopu may then define relatively freely?
[19:00:41] <BBB> and then write it in such a way that it works in ffplay.c without modifications to ffplay.c
[19:00:48] <BastyCDGS> A) is the mixing engine, right?
[19:00:49] <BBB> (bonus points for that)
[19:00:53] <BBB> yes
[19:01:24] <BastyCDGS> using TuComposer's one, it's 99,9% platform independent
[19:01:45] <BastyCDGS> that should be straight forward
[19:01:54] <Vitor1001> BastyCDGS: Adding a pointer to AVCompose struct to AVCodecContext is hackish. It would be better then to make the decoders output in the "void *data" field this pointer.
[19:01:55] <BastyCDGS> but it would be nice if the user can choose between different mixing engines
[19:01:59] <BastyCDGS> like TuComposer can do too
[19:02:20] <BastyCDGS> i.e. one "low-quality" one for real-time playback and one high-quality with all oversampling, interpolation, click-removal, etc. stuff for writing to HDD
[19:02:28] <BastyCDGS> maybe also integer/FPU ones
[19:03:01] <BastyCDGS> AVComposer should be part of the public API
[19:03:03] <BBB> the user doesn't choose a "mixing engine"
[19:03:07] <BBB> he chooses a "quality" then
[19:03:09] <BastyCDGS> it should be possible to write a tracker with it
[19:03:10] <BBB> or whatever the difference is
[19:03:20] <BBB> the tracker would be an internal implementation detail
[19:03:22] <BastyCDGS> I meant quality ;)
[19:03:23] <Vitor1001> BastyCDGS: The point of "choosing different engines" should work the same way as choosing different scaler algos with swscaler
[19:03:28] <Vitor1001> with flags
[19:03:29] <BastyCDGS> yes
[19:03:43] <BBB> I agree the user should never "see" the AVComposer
[19:03:57] <BBB> just like the user never sees the MP3DecodeContext
[19:04:00] <BBB> it sees an AVCodecContext
[19:04:03] <BBB> nothing else
[19:04:20] <BastyCDGS> so tracker writers have to use public API functions
[19:04:28] <BastyCDGS> which write in the AVComposer stuff
[19:04:46] <Vitor1001> The AVComposer should be visible for a caller app.
[19:06:14] <CIA-93> ffmpeg: mstorsjo * r23290 /trunk/ffserver.c:
[19:06:15] <CIA-93> ffmpeg: ffserver: Plug some memory leaks
[19:06:15] <CIA-93> ffmpeg: Patch by Howard Chu, hyc at highlandsun dot com
[19:07:07] <BastyCDGS> BBB
[19:07:16] <BastyCDGS> B) are mod/s3m/xm/it loader
[19:07:24] <BastyCDGS> which convert into internal composer representation
[19:07:33] <BastyCDGS> or encoders convert from internal composer representation
[19:07:39] <BastyCDGS> then forward to the decoder
[19:08:16] <Vitor1001> I'd say this is C)
[19:08:29] <Vitor1001> B) is just a do-nothing wrapper like the image2 demuxer.
[19:08:41] <BastyCDGS> I thought C is the playback engine
[19:08:53] <BastyCDGS> the playback engine interprets notes etc.
[19:09:01] <BastyCDGS> and fills the mixer A) with it
[19:09:44] <Vitor1001> I'd put that on A) too...
[19:09:45] <BastyCDGS> hey saste
[19:09:51] <BastyCDGS> just noticed you got here, fine :)
[19:11:03] <saste> hi basty reading your mail now...
[19:12:27] <BastyCDGS> viktor1001 you mean the wrapper is there we can change/switch mod engines later or sth. like that
[19:12:36] <BastyCDGS> or what's the reason of the do-nothing wrapper?
[19:12:44] <wbs> BastyCDGS: his name is vitor, btw.
[19:12:55] <CIA-93> ffmpeg: mstorsjo * r23291 /trunk/ffserver.c:
[19:12:55] <CIA-93> ffmpeg: ffserver: Fix another memory leak
[19:12:55] <CIA-93> ffmpeg: Don't allocate st->codec, it will be overwritten by the memcpy a few
[19:12:55] <CIA-93> ffmpeg: lines further down.
[19:12:55] <CIA-93> ffmpeg: Fix by Howard Chu, hyc at highlandsun dot com
[19:12:56] <BastyCDGS> oops sorry
[19:12:59] <Vitor1001> BastyCDGS: The wrapper is just there because there is not much point in separating a demuxer/decoder for a mod file
[19:13:06] <Vitor1001> in the same way of a jpeg file
[19:13:38] <jai> also, use the tab key luke...
[19:13:43] <Vitor1001> The file should be fed to the decoder directly.
[19:14:13] <Vitor1001> And the decoder will transform the coded data in some internal representation.
[19:15:01] <Vitor1001> As an internal representation I mean something format independent and part of the public api
[19:15:14] <jai> has it been decided where the renderer will live?
[19:15:29] <Vitor1001> And doing something with this internal representation do not belong to libavcodec.
[19:16:45] <BastyCDGS> yes I meant it that way, too that internal representation is part of public API
[19:17:27] <wbs> hyc: regarding the strchr vs memchr fix; are you sure it should check c->buffer_end? as far as I understand the code that calls rtsp_parse_request there, it only has data between c->buffer and c->buffer_ptr, not necessarily up to c->buffer_end?
[19:17:38] <Vitor1001> Since libavcodec should only do the decoding, all that belongs in it is outputting this internal representation
[19:18:34] <BastyCDGS> so the demuxer just probes if it's valid MOD/S3M/XM/IT/whatever will be add and forwards then in read_header to the decoder?
[19:19:18] <BBB> read_header does nothing
[19:19:26] <BBB> read_packet just reads the file
[19:19:32] <BBB> and forwards directly to decoder
[19:19:34] <BBB> (I think)
[19:19:57] <BastyCDGS> read_header could check if the module header isn't corrupt
[19:20:08] <BastyCDGS> so that read_packet can ensure that it's okay
[19:20:12] <hyc> wbs: possible. the point is that before, strchr was searching past buffer_end
[19:20:40] <BastyCDGS> but when I think about your approach, BBB
[19:20:47] <BastyCDGS> it's the same way TuComposer does it, too
[19:20:56] <wbs> hyc: yeah, I know. just wanted to see that once we fix it, we actually fix it correctly and not just something not-really-all-that-correct either
[19:20:58] <BastyCDGS> there's only a IdentifyModule (which is av_probe) and LoadModule
[19:21:03] <BastyCDGS> (which would be read_packet)
[19:21:16] <Vitor1001> "(09:18:34 PM) BastyCDGS: so the demuxer just probes if it's valid MOD/S3M/XM/IT/whatever will be add and forwards then in read_header to the decoder?"
[19:21:17] <Vitor1001> yes
[19:22:04] <hyc> wbs: looks like you're right. should be buffer_ptr
[19:22:07] <Vitor1001> But forward it to the _right_ decoder, by setting the right codec_id.
[19:24:19] <BastyCDGS> I think I will start with porting the header files from TuComposer...
[19:24:22] <CIA-93> ffmpeg: mstorsjo * r23292 /trunk/ffserver.c:
[19:24:22] <CIA-93> ffmpeg: ffserver: Fix an out of bounds read
[19:24:22] <CIA-93> ffmpeg: Fix by Howard Chu, hyc at highlandsun dot com
[19:24:24] <BastyCDGS> module.h, song.h etc.
[19:24:35] <BastyCDGS> to make it FFmpeg look&feel
[19:24:43] <BastyCDGS> make comments doxygen friendly
[19:24:48] <BastyCDGS> convert ULONG => uint32_t etc.
[19:25:01] <BastyCDGS> and lowercase struct / element names etc.
[19:25:13] <BastyCDGS> use 4 space indentation (tucomposer uses 2 space up to now)
[19:25:34] <BastyCDGS> this also includes remove stuff which isn't needed anymore because it's already in ffmpeg
[19:25:37] <Vitor1001> BastyCDGS: Yes, the first thing would be getting the AVComposer structure done and reviewed
[19:25:59] <BastyCDGS> where I should put the header files anyway?
[19:26:06] <BastyCDGS> lavf or lavc or lavu?
[19:26:32] <Vitor1001> lavc, it is the only one who will need it.
[19:26:57] <BastyCDGS> I will prefix them with tuc_ ok?
[19:27:01] <BastyCDGS> tuc => the united composer
[19:27:07] <BastyCDGS> one for all - all for one ;)
[19:27:24] <BastyCDGS> thus => tucomposer/module.h => libavcodec/tuc_mod.h
[19:27:28] <BastyCDGS> tuc_module.h
[19:27:31] <Vitor1001> How many types will be needed?
[19:27:32] <BastyCDGS> what do yout think?
[19:27:35] <Vitor1001> I mean public ones?
[19:27:46] <BastyCDGS> module.h, song.h, position.h, track.s, instr.h, sample.h, synth.h
[19:27:49] <BastyCDGS> all of these are public
[19:27:58] <Vitor1001> and they all need to be?
[19:28:14] <BastyCDGS> these are the 7 points from the mail
[19:29:06] <BastyCDGS> depends if we want to allow people to access there directly...we can make them private too. but then we have kind of getters/setters
[19:29:07] <Vitor1001> Ok, but is it just 7 types?
[19:29:21] <Vitor1001> No, no OO here ;)
[19:29:40] <jai> avcomposer factory? ;)
[19:30:17] <BastyCDGS> 7 dwarfes and a target ELF...lol
[19:30:43] <BastyCDGS> these 7 types are the module itself
[19:30:51] <BastyCDGS> tucomposer has a player.h for the playback engine
[19:31:02] <BastyCDGS> which will also be used by FFplay for pattern display etc.
[19:31:29] <BastyCDGS> and it has a external/mixer.h which is the mixing engine structure
[19:31:36] <BastyCDGS> but maybe we can add that into player.h, too?
[19:33:28] <Vitor1001> I was wondering if one should do an avcompose.h with all the 7 types.
[19:33:38] <Vitor1001> And that's pretty much all that will be public.
[19:33:51] <Vitor1001> But in anyway, I think this is the right place to start.
[19:34:06] <hyc> wbs: thanks again
[19:34:14] <Vitor1001> And I suggest you send it to the ML as soon as you have done it.
[19:34:35] <Vitor1001> Since it will be public API, people will want to review it well before it is set on stone
[19:35:00] <BastyCDGS> of course we can join them all in one, but it will be a very big file ;)
[19:35:29] <BastyCDGS> 62 external.h
[19:35:29] <BastyCDGS>   1104 instr.h
[19:35:29] <BastyCDGS>    209 module.h
[19:35:29] <BastyCDGS>    782 player.h
[19:35:29] <BastyCDGS>    230 position.h
[19:35:29] <BastyCDGS>    339 sample.h
[19:35:29] <BastyCDGS>    391 song.h
[19:35:30] <BastyCDGS>    924 synth.h
[19:35:30] <BastyCDGS>    566 track.h
[19:35:31] <BastyCDGS>    330 tucomposer.h
[19:35:31] <BastyCDGS>   4937 total
[19:35:47] <BastyCDGS> even if we can shorten them a lot it will still be around 2-3k lines I guess
[19:36:27] <BastyCDGS> I think that amount of lines it a bit overkill for a single header file
[19:37:07] <BastyCDGS> I wasn't counting the stuff in the external/ sub dir but that shouldn't be as much
[19:37:07] <Vitor1001> Well, it is mostly enums
[19:37:29] <BastyCDGS> maybe we do 3 files?
[19:37:36] <BastyCDGS> one avcomposer.h (tucomposer.h)
[19:37:44] <BastyCDGS> one module.h (contains module.h, song.h, etc.)
[19:37:52] <BastyCDGS> and one player.h (contains player.h and external/mixer.h)
[19:38:09] <Vitor1001> player.h should be public?
[19:38:25] <BastyCDGS> in fact all when you don't want getter/setters for each single element in the struct ;)
[19:38:56] <wbs> DonDiego: btw, regarding that ogv video that you had problems with... do you still get crashes if you add -noframedrop?
[19:39:30] <BastyCDGS> module.h is public because tracker writers have to change the values of the modules if the user in the GUI changes module name etc.
[19:39:33] <Vitor1001> Oh, I see. "player.h" makes me think of a player interface, not something the decoder would output
[19:39:44] <BastyCDGS> player.h is the playback engine
[19:40:04] <BastyCDGS> i.e. it takes the notes from the internal representation, calculates final frequency/volume/panning etc. for the mixer
[19:40:13] <DonDiego> wbs: with ffplay?
[19:40:25] <BastyCDGS> so after call to DoPlayerIRQ in TuComposer the mixer can directly output the mixing engine stuff to PCM
[19:40:29] <Vitor1001> Is it needed to convert mod to xm?
[19:40:35] <BastyCDGS> yes, too
[19:40:53] <BastyCDGS> but also for mod to PCM
[19:41:12] <Vitor1001> MOD to XM should be completely different than mod to pcm
[19:41:13] <BastyCDGS> for converting from module to module the module.h stuff is needed, too.
[19:41:44] <Vitor1001> everything needed to convert mod <-> xm should be in libavcodec/
[19:42:19] <BastyCDGS> depends on how well you want to make the converters, if you want do dumb and naive note 2 note conversation without deep analysis player.h isn't needed for mod<->xm
[19:42:21] <Vitor1001> everything that is needed to convert mod -> pcm but not mod -> xm should _not_ be in libavcodec/
[19:42:34] <BastyCDGS> but for a in deep analysis (this incldues playtime calculation and seek offsets)
[19:43:05] <BastyCDGS> you need player.h
[19:43:37] <Vitor1001> ok, so as far as I understand player.h should not be in libavcodec/
[19:43:55] <BastyCDGS> oh lavc is ok I think
[19:43:57] <BastyCDGS> why you think not?
[19:44:12] <Vitor1001> it has nothing to do with decoding (in the strict sense of "turning the input to something universal")
[19:44:51] <BastyCDGS> well input is internal composer representation
[19:44:53] <BastyCDGS> output is PCM
[19:45:01] <BastyCDGS> ok not direct
[19:45:09] <BastyCDGS> output is SAMPLE_FMT_COMPOSER (mixing engine)
[19:45:09] <wbs> DonDiego: yeah
[19:45:18] <BastyCDGS> and that does the actual PCM conversation
[19:45:18] <Vitor1001> No. Input is XM. After decoding internal composer representation.
[19:45:24] <BastyCDGS> which can be mp3/ogg vorbis/etc.
[19:45:57] <DonDiego> wbs: with -noframedrop i see some frames before the crash
[19:46:05] <wbs> DonDiego: hmm, ok
[19:46:31] <BastyCDGS> 1. load module (convert to internal composer representation)
[19:46:45] <BastyCDGS> 2. for each tick call DoPlayerIRQ (playback engine which fills mixing engine fields)
[19:47:21] <BastyCDGS> 3. mixing engine mixes multichannel samples to stereo/mono/5:1/etc. and that is outputted
[19:47:27] <BastyCDGS> that's the steps for normal playback
[19:47:41] <Vitor1001> And why 2) and 3) is needed for mod <-> xm?
[19:48:35] <BastyCDGS> for mod <=> xm you won't need it, but for xm <=> it you will
[19:48:35] <BastyCDGS> to get the virtual NNA channels to host channels
[19:48:56] <BastyCDGS> but only if you want a smart converter
[19:49:16] <BastyCDGS> consider another example, which explains it better:
[19:49:40] <BastyCDGS> imagine you have a image format which doesn't support truecolor, but you want to convert a truecolor image to this target format
[19:50:12] <BastyCDGS> a dumb decoder would simply write wrong pixel-data into the target format, a smart converter instead would convert the source image to 8bpp or sth. like that before
[19:50:43] <BastyCDGS> for the xm<=>it example:
[19:50:57] <BastyCDGS> instrument #1 NNA set to continue, pattern data:
[19:51:05] <BastyCDGS> C-6 01 ...
[19:51:10] <BastyCDGS> D#6 01 ...
[19:51:19] <BastyCDGS> if you convert that naive to xm it's wrong
[19:51:36] <BastyCDGS> because D#6 would cut C-6 (XM doesn't support NNA continue)
[19:51:53] <BastyCDGS> (it plays 2 independant channels, xm would play one)
[19:52:01] <BastyCDGS> so in xm that would have look like:
[19:52:27] <BastyCDGS> ch. #1          ch #2
[19:52:27] <BastyCDGS> C-6 01 ...      ... .. ...
[19:52:27] <BastyCDGS> ... ... ...         D#6 01 ...
[19:52:39] <BastyCDGS> that would be a smart converter ;)
[19:53:41] <BastyCDGS> DoPlayerIRQ calculates the NNA stuff and assigns target channels
[19:54:05] <BastyCDGS> so the xm writer can just take the DoPlayerIRQ output and sees that these are actually 2 channels: output XM sounds the same as the original IT ;)
[19:54:36] <Vitor10011> BastyCDGS: Sorry, my laptop decided it was out of battery when it was not :p
[19:54:45] <BastyCDGS> damn I typed so much
[19:55:06] <jai> BastyCDGS: pastebin
[19:55:09] * jai goes
[19:56:42] <Vitor10011> mru: Any live irc-logs?
[20:00:10] <CIA-93> ffmpeg: mstorsjo * r23293 /trunk/ffserver.c:
[20:00:10] <CIA-93> ffmpeg: ffserver: Fix extradata handling
[20:00:10] <CIA-93> ffmpeg: Patch by Howard Chu, hyc at highlandsun dot com
[20:01:53] <Vitor10011> BastyCDGS: About your example with palette -> truecolor jpeg, what ffmpeg would do will be
[20:01:53] <Vitor10011> 1) lavc outputs paletted data
[20:01:53] <Vitor10011> 2) swscaler (that is not part of lavc!) converts it to truecolor
[20:01:53] <Vitor10011> 3) ffmpeg.c sends truecolor frame to lavc jpeg encoder
[20:02:42] <BastyCDGS> we need some similar approach for converting mods between themselves
[20:02:53] <BastyCDGS> at least if we want a converter that really deserves its name ;)
[20:04:02] <Vitor10011> Hmm... What if you had a different intermediate format?
[20:04:20] <BastyCDGS> what you mean exactly by this?
[20:04:37] <Vitor10011> One where you could just pass that struct as read from mod directly to xm encoder without "playing"
[20:05:11] <BastyCDGS> then you would have to write different converters for each possible combination of input/output I doubt
[20:05:39] <Vitor10011> Hmm, in your example, what does NNA stands for?
[20:05:39] <BastyCDGS> or do you mean mod => internal comp. represenation => xm encoder?
[20:05:45] <BastyCDGS> New Note Action...
[20:05:56] <Vitor10011> I mean "mod => internal comp. represenation => xm encoder", yes.
[20:05:59] <BastyCDGS> it tells the tracker what happens with the previous note when it's played on the same channel
[20:06:12] <Vitor10011> For some ultra-smart internal representation that would do the magic...
[20:06:12] <BastyCDGS> NNA cut => kill previous note
[20:06:24] <BastyCDGS> NNA fade => fade-out previous note, play new note on new channel
[20:06:32] <BastyCDGS> NNA off => key-off noe, play new on new ch
[20:06:38] <Vitor10011> So if the internal format did not support NNA it could still represent any input?
[20:06:41] <BastyCDGS> NNA cont => don't do anything with old note, play new on new ch
[20:06:44] <BastyCDGS> XM only knows NNA cut
[20:06:53] <BastyCDGS> S3M/MOD too
[20:07:22] <BastyCDGS> tucomposer has an additional NNA mode
[20:07:36] <BastyCDGS> NNA synth => calls synth sound assembler which handles old note => new note on new channel
[20:08:00] <BastyCDGS> NNA synth gives you assembly language level control of what happens with old note
[20:08:43] <Vitor10011> But besides NNA synth
[20:08:53] <CIA-93> ffmpeg: mstorsjo * r23294 /trunk/ffserver.c:
[20:08:53] <CIA-93> ffmpeg: ffserver: Fix streaming with more than one stream
[20:08:53] <CIA-93> ffmpeg: Fix by Howard Chu, hyc at highlandsun dot com
[20:08:53] <Vitor10011> NNA cut can be represented without NNA, no?
[20:09:25] <BastyCDGS> NNAs are just an example where you need smart conversation, it's just the most audible one
[20:10:04] <mru> Vitor10011: no, sorry
[20:10:10] <BastyCDGS> I want a approach like GCC does with optimization, an intermediate which is then converted to the best target arch asm code
[20:10:13] <Vitor10011> mru: no problem
[20:10:44] <Vitor10011> BastyCDGS: yes, that would be ideal
[20:11:27] <hyc> wbs: nice, looks like only the timestamp patch is remaining
[20:11:52] <BastyCDGS> this would have FFmpeg the best mod converter in the universe ;) :)
[20:12:01] <BastyCDGS> all other mod converters I know of do it the dumb way
[20:12:02] <Vitor10011> BastyCDGS: The next best would be (for "XM -> MOD")
[20:12:02] <Vitor10011> 1) XM -> XM decoder -> internal representation (in lavc)
[20:12:02] <Vitor10011> 2) internal representation -> internal representation simplified for MOD (in libavcompose)
[20:12:02] <Vitor10011> 3) internal representation -> MOD (in lavc)
[20:12:43] <mru> having the "best mod player in the world" is a bit like having the best steam engine in the world
[20:13:03] <BastyCDGS> s/player/converter ;)
[20:13:09] <BastyCDGS> ok best player, too. :D
[20:13:13] <wbs> hyc: that one, the CHECK_CODEC(codec_id) fix, then one on rewriting the ffm header, and the h264/rtp stuff
[20:13:17] <mru> analogy still stands
[20:13:36] <hyc> wbs: ah yes
[20:13:42] <wbs> hyc: it took me a while to crawl the mail thread, pick out the unapplied parts, check them in as local commits in git here to get some kind of overview of them
[20:13:59] <wbs> and of course I ran into some new issues of my own while looking at this, too ;P
[20:14:11] <hyc> I'll bet...
[20:14:12] <BastyCDGS> yes internal representation is simplified just because MOD is simpler than XM and XM is simpler than IT
[20:14:15] <Vitor10011> BastyCDGS: In step 2), you could maybe just pass a list of supported features of MOD to whatever function you are calling
[20:14:16] <BastyCDGS> e.g. NNA would always be cut
[20:14:47] <hyc> I sprinkled a bunch of new ifdef's in ffserver as well, to build my stripped down Android binary
[20:14:50] <BastyCDGS> the MOD/S3M/XM could also just check if there's an instrument having NNA != cut and if so use smart mode, otherwise naive
[20:14:59] <BastyCDGS> i.e. convert pattern by pattern/instrument by instrument
[20:15:25] <hyc> but I don't think I'll be posting those, it's pretty unlikely to be of interest to anyone else
[20:17:18] <Vitor10011> BastyCDGS: So do you understand why in my way of seeing things I think player.h should not be in lavc?
[20:17:31] <BastyCDGS> as said, vitor, my approach for smart conversation would be do an internal playback (but instead recording the PCM to /dev/dsp or file etc.) it just uses the mixer structure to decide how to fill the notes in the target module format.
[20:18:28] <Vitor10011> yes, but it would be in step 2), no?
[20:18:29] <BastyCDGS> BTW, I did that once to rip a game tune from amiga (by catching write to hardware audio registers) and use that to create MOD structure :)
[20:19:15] <BastyCDGS> the code for this btw, is also in the WB39.7z ;)
[20:19:39] <BastyCDGS> Work:Sources/Asm/GianaPlay.s
[20:20:22] <hyc> wbs: the CHECK_CODEC(codec) is obviously wrong, ccf->codec and ccs->codec are always NULL
[20:20:29] * Vitor10011 is still downloading ;)
[20:21:24] <Vitor10011> My point is that if you are doing the internal playback in step 2, its code should not be in lavc, but somewhere else.
[20:21:59] <BastyCDGS> but where?
[20:22:12] <Vitor10011> libavcompose? ;)
[20:22:36] <BastyCDGS> that's what I prefer anyway ;)
[20:22:52] <BastyCDGS> but mru will probably thumb up ;)
[20:22:54] <BastyCDGS> right, mru? ;)
[20:23:05] <BastyCDGS> and not only him
[20:23:11] <mru> I think we should all be realistic
[20:23:54] <ohsix> but when its pulseaudio all bets are off
[20:24:08] <elenril> bcoudurier: can you review vorbiscomment writing for vorbis in ogg please?
[20:24:17] <Vitor10011> mru: What do you mean precisely?
[20:25:22] <mru> well, the tucomposer code is in no way whatsoever fit for inclusion in ffmpeg
[20:25:29] <CIA-93> ffmpeg: mstorsjo * r23295 /trunk/ffserver.c:
[20:25:29] <CIA-93> ffmpeg: ffserver: Fix one of the codec parameter checks
[20:25:29] <CIA-93> ffmpeg: This is probably what was originally intended; the codec pointers are all NULL.
[20:25:29] <CIA-93> ffmpeg: Fix by Howard Chu, hyc at highlandsun dot com
[20:25:36] <mru> hell, half of it is m68k asm with no corresponding c code
[20:25:42] <BastyCDGS> ???
[20:25:46] <BastyCDGS> half?
[20:26:01] <BastyCDGS> everything except MOD/S3M/XM/IT loader is C
[20:26:26] <BastyCDGS> and these are pretty small
[20:26:43] <BastyCDGS> if you mean DoPlayerIRQ and the mixer...well these are also available as C
[20:26:54] <BastyCDGS> so what's your problem?
[20:28:05] <Vitor10011> mru: I find realistic doing
[20:28:05] <Vitor10011> 1) Getting the internal composer representation reviewed
[20:28:05] <Vitor10011> 2) Getting the MOD/S3M/XM/IT decoder commited
[20:28:05] <Vitor10011> 3) Start discussing where put the code to actually play the internal representation
[20:28:05] <Vitor10011> 4) Getting it done and reviewed
[20:28:06] <Vitor10011> 5) Start discussing what to do to conversion
[20:28:09] <BastyCDGS> btw, the loaders have to be rewritten anyway even if they would be available as C code
[20:28:19] <BastyCDGS> since ffmpeg has it's own bitstream / bytestream stuff
[20:28:51] <Vitor10011> 2) and 3) can be done in parallel
[20:29:21] <mru> when I poked around the code I had trouble finding anything but function stubs in the c code
[20:29:26] <mru> and what code I found was full of hack
[20:29:51] <BastyCDGS> where you have been looking?
[20:30:01] <BastyCDGS> can you give some examples, please?
[20:30:50] <mru> in the zip file you linked a few weeks ago
[20:30:58] <BastyCDGS> that is clear, be more precise, please
[20:31:05] <mru> I don't remember the filenames
[20:31:48] <BastyCDGS> do you mean that huge header file which contains the public API?
[20:31:55] <BastyCDGS> that are wrappers for amiga OS library style calls
[20:31:59] <BastyCDGS> they aren't needed in ffmpeg anyway
[20:32:16] <BastyCDGS> this is because amiga os library expect parameters in registers not on stack
[20:32:31] <mru> I was looking for mixing functions
[20:32:33] <mru> and such
[20:32:43] <mru> the files with names suggesting they might contain it had only stubs
[20:32:50] <mru> I looked no further
[20:32:58] <mru> the code is clearly not tidy
[20:33:49] <ohsix> needs more adjectives
[20:33:50] <BastyCDGS> mixer is Internal/InternalLQMix.c
[20:34:02] <mru> I deleted it
[20:34:26] <mru> and I'm not particularly interested anyway
[20:34:38] <mru> you're just hogging the channel so I have nothing else to troll about
[20:35:12] <elenril> you can always troll gstreamer
[20:35:21] <DonDiego> i'm disappointed
[20:35:26] <ohsix> or pulse
[20:35:31] <BastyCDGS> dondiego, why?
[20:35:36] <DonDiego> i just compiled valgrind from source
[20:35:50] <DonDiego> and version 3.5.0 still complains about unknown instructions..
[20:36:00] <mru> I think they accept patches
[20:36:03] <ohsix> 3dnow? :P
[20:36:04] <drv> what's missing, SSE stuff?
[20:36:04] <CIA-93> ffmpeg: stefano * r23296 /trunk/libavformat/riff.c: (log message trimmed)
[20:36:04] <CIA-93> ffmpeg: Add missing codec id <-> codec tag entries:
[20:36:04] <CIA-93> ffmpeg: CODEC_ID_RAWVIDEO <-> Y41B
[20:36:04] <CIA-93> ffmpeg: CODEC_ID_RAWVIDEO <-> Y42B
[20:36:04] <CIA-93> ffmpeg: CODEC_ID_RAWVIDEO <-> YUV9
[20:36:05] <CIA-93> ffmpeg: CODEC_ID_RAWVIDEO <-> YVU9
[20:36:05] <CIA-93> ffmpeg: These codec tags are listed in fourcc.org, and are already listed in
[20:36:12] <mru> ohsix: yes, 3dnow
[20:36:31] <drv> 3dtenyearsago
[20:36:33] <BastyCDGS> dondiego, what assembler it uses to assemble?
[20:36:35] <wbs> hyc: I'm not totally sure about the timestamp fix though
[20:36:38] <ohsix> its a bygone era; you might have to do that sort of thing yourself heh
[20:36:40] <BastyCDGS> maybe you have to update the assembler, too.
[20:37:12] <mru> BastyCDGS: do you know what valgrind is?
[20:37:23] <BastyCDGS> something like enforcer on amiga
[20:37:30] <mru> I've no idea what that is
[20:37:47] <mru> but here's a hint: find out what stuff is before having opinions on it
[20:37:51] <mru> you look less of a fool then
[20:38:08] <BastyCDGS> I know it's a debugger
[20:38:19] <mru> and I know it's not
[20:38:20] <drv> it's more of a cpu emulator with some debugging tools on top
[20:38:28] <mru> it's a checker, not a debugger
[20:38:58] <BastyCDGS> checking for stuff like memory overwriting ;)
[20:39:00] <hyc> wbs: possibly i had unreliable input data
[20:39:07] <BastyCDGS> and that's what enforcer is on amiga
[20:39:17] <hyc> I've been testing exclusively with RTMP input streams
[20:39:52] <Vitor10011> BastyCDGS: You said it was a lot of trouble getting MOD/S3M/XM/IT to work
[20:39:57] <CIA-93> ffmpeg: stefano * r23297 /trunk/ (3 files in 3 dirs):
[20:39:57] <CIA-93> ffmpeg: Add libavfilter 1-input - 1-output regression test, corresponding to the
[20:39:57] <CIA-93> ffmpeg: target regtest-lavfi_pix_fmts.
[20:39:57] <CIA-93> ffmpeg: The lavfi_pix_fmts test is disabled, this because there are
[20:39:57] <CIA-93> ffmpeg: many tests which are failing, and there are still some output files
[20:39:58] <CIA-93> ffmpeg: which cannot be played by NUT/ffplay.
[20:40:03] <Vitor10011> BastyCDGS: Was the work in the loader or elsewhere?
[20:40:11] <BastyCDGS> to get it work perfectly and handle all that undocumented stuff, basic support was easy
[20:40:27] <BastyCDGS> partially loader / most stuff playback engine
[20:40:34] <DonDiego> siretart: what stops us from making a 0.5.2 point release?
[20:40:50] <DonDiego> a few patches have accumulated
[20:41:12] <Vitor10011> Isn't the playback engine something whose behaviour is very well defined as a function of the internal representation?
[20:41:24] <BBB> Vitor10011: I am ok with all of it, but I'd prefer if we assume from the beginning that the "SAMPLE_FMT_COMPOSER" stuff will be convertable with audioconvert.c
[20:41:31] <bcoudu> wait
[20:41:34] <BBB> Vitor10011: that way most applications won't need anything to play it
[20:41:35] <BastyCDGS> it should be, but the documentation of S3M/XM is awful regarding this
[20:41:38] <bcoudu> is theora using jpeg range ?
[20:41:39] <BBB> Vitor10011: other than that I love your plan
[20:42:05] <bcoudu> die !
[20:42:11] <BBB> and I agree with mru that tucomp code needs major review before it's fit for inclusion into ffmpeg, so let's do this small pieces at a time
[20:42:25] <Vitor10011> BBB: Great. Anyway, we'll have a lot of time to discuss it while the internal representation is reviewed.
[20:42:27] <BastyCDGS> BBB, I also said this...it has to be refactored a lot etc. ;)
[20:42:29] <siretart> DonDiego: I'd say nothing
[20:42:35] <BBB> excellent then
[20:42:38] <DonDiego> go for it then?
[20:42:47] <BBB> BastyCDGS: you have ten mentors, it seems, you should feel very lucky ;)
[20:42:54] <bcoudurier> what's tucomp ?
[20:42:54] <BastyCDGS> but it's simply not true that only half of the stuff is C and the rest asm
[20:43:03] <BBB> most soc students in other projects (not ffmpeg) don't ever interact with their mentor
[20:43:16] <BBB> bcoudurier: BastyCDGS's mod player
[20:43:22] <bcoudurier> humm is yuvi around ?
[20:43:59] <BastyCDGS> BBB, small correction: tracker
[20:44:04] <BastyCDGS> although there's no GUI for it yet
[20:44:06] <BBB> uh yes
[20:44:09] <BBB> well look I'm an idiot
[20:44:15] <BBB> for me anything that plays sound is a sound player
[20:44:22] <BastyCDGS> no you aren't, because practically it's usable only as a player right now
[20:44:27] <BastyCDGS> so we both are right ;)
[20:45:27] <BastyCDGS> but I would like to know from mru what he meant with full of hacks
[20:45:49] <wbs> BastyCDGS: trust me, you will notice when you try to get the code thrugh the review
[20:46:26] <BastyCDGS> well if you give me some hints I can fix some issues straight away when I refactor it
[20:46:38] <mru> ok then: all of it
[20:47:31] <BastyCDGS> that's like when got asked where I life, and I reply with: somewhere on earth
[20:47:40] <BastyCDGS> that's as helpful as your reply
[20:48:01] <mru> I didn't see any code I wouldn't want replaced
[20:48:45] <BastyCDGS> I mean actual code, not that refactor stuff (i.e. ULONG => uint32_t, etc.) that's clear
[20:48:58] <BastyCDGS> I mean when all the refactoring is done, what's then there to be replaced
[20:51:02] <BBB> you shouldn't use arch-specific size-specifiers unless there's a good reason
[20:51:12] <BBB> for example, a palette holding RGB32 data should probably be a uint32_t
[20:51:16] <BBB> but a size parameter should not
[20:51:19] <BBB> it should be int
[20:51:23] <BBB> it's a counter, nothing more
[20:51:35] <BBB> when I looked, everything was ulong/uword/etc.
[20:51:40] <BBB> that's not good
[20:51:45] <BastyCDGS> that's part of refactoring
[20:51:51] <BBB> but more generally, just put it's in ffmpeg, as vitor suggested
[20:51:54] <BBB> and then let's review it
[20:51:57] <BastyCDGS> please note it is (was) an amiga OS library
[20:51:58] <BBB> it's more practical than all of this
[20:51:59] <BBB> :)
[20:52:06] <BastyCDGS> and there you have to use ULONG etc.
[20:52:08] <BastyCDGS> always
[20:52:09] <DonDiego> ok, valgrind cooperates with a --disable-amd3dnow build
[20:52:12] <BastyCDGS> ok not intern as a counter that rights
[20:52:22] <DonDiego> but it's taking very long and hogging the cpu
[20:52:32] <DonDiego> is it supposed to exit on its own?
[20:52:32] <mru> 21:52 < BastyCDGS> and there you have to use ULONG etc. <-- nonsense
[20:52:40] <mru> every compiler lets you use int etc
[20:52:59] <BastyCDGS> yes, but on amiga, some compilers threat int as 16-bit, some as 32-bit
[20:53:02] <BastyCDGS> so shared library will break
[20:53:27] <BastyCDGS> read the Amiga ROM reference manual regarding this
[20:54:04] <BastyCDGS> practically all functions in tucomposer that weren't static were part of the shared library
[20:54:31] <mru> INT_MAX: Minimum Acceptable Value: 2 147 483 647
[20:54:34] <mru> in posix
[20:54:38] <mru> and that's what we target
[20:54:52] <BastyCDGS> yes and as already said, I have to refactor it
[20:55:14] <mru> then there's the wild casting
[20:55:15] <BastyCDGS> maybe I misexpressed a bit, I of course didn't mean a dumb convert of each ULONG => uint32_t
[20:55:16] <BastyCDGS> ;)
[20:55:57] <BastyCDGS> all the casting has effects there
[20:56:17] <BastyCDGS> I can tell this because during that time I added casting afterwards when it wasn't necessary
[20:56:18] <mru> a cast with effects is wrong
[20:56:24] <BastyCDGS> and each cast that remained there changed output
[20:56:27] <mru> and a cast without effects is useless
[20:56:29] <mru> and therefor wrong
[20:56:35] <mru> ergo, casts are wrong
[20:56:51] <ohsix> reductio ad absurdium
[20:57:13] <mru> there are a few rare cases where casts are needed
[20:57:14] <BastyCDGS> ok then I supply a patch now will removes every cast in ffmpeg :D :P
[20:57:24] <mru> and these should usually be buried under a few layers of macros
[20:58:28] <BBB> about that
[20:58:37] <BBB> can we please get rid of the useless consts and unsigneds everywhere?
[20:58:38] <hyc> DonDiego: valgrind exits when the slave program exits
[20:58:41] <BBB> they confuse me a lot
[20:59:00] <BastyCDGS> casts?
[20:59:06] <DonDiego> hyc: what when it does not?
[20:59:30] <hyc> then just Ctrl-C or kill -INT
[21:00:40] <mru> DonDiego: what are you running?
[21:00:42] <DonDiego> http://pastebin.org/275990
[21:00:52] <DonDiego> this is the valgrind output
[21:01:09] <BastyCDGS> BBB, what's your problem with const?
[21:01:16] <BastyCDGS> I mean what confuses you?
[21:01:20] <BBB> most of them don't do anything
[21:01:27] <BBB> we shouldn't use qualifiers that do nothing
[21:01:31] <DonDiego> mru: i'm running ffplay
[21:01:38] <mru> ffplay doesn't exit on its own
[21:01:41] <mru> press q in the window
[21:02:16] <BBB> a const in the API can be incredibly useful, because it's a promise we won't touch the data
[21:02:17] <DonDiego> it crashed
[21:02:25] <DonDiego> it does exit when it crashes
[21:02:26] <BBB> e.g. decode(const uint8_t *data, int size);
[21:02:41] <BBB> any other use of const is usually unnecessary
[21:02:46] <BastyCDGS> BBB, I use it internally also for remembering me that I shouldn't fiddle around with the initially assigned value after it without side-effects
[21:02:50] <BastyCDGS> that's useful, right?
[21:02:55] <mru> valgrind sometimes changes the behaviour on invalid memory accesses
[21:03:10] <mru> and sdl has a habit of sticking around if unusual things happen
[21:03:11] <BastyCDGS> mru, ha I said it's like enforcer ;)
[21:03:13] <BBB> BastyCDGS: if a programmer doesn't know what his data means (or that he shouldn't fiddle with it), then his code is likely hacky
[21:03:20] <wbs> bcoudurier: can you give an ok on http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100525/34f38fd2/attachment.patch? it's a quite minimal and trivial patch
[21:03:22] <mru> BastyCDGS: I suggest you tone down a bit
[21:03:40] <BBB> BastyCDGS: no const will ever fix hacky code
[21:04:05] <DonDiego> anyway, will yuvi or anybody be able to do something with that valgrind output i posted?
[21:04:06] <BastyCDGS> mru, what have I said wrong?
[21:04:10] <BBB> BastyCDGS: I suggest you compile each time you use const with and without const, and see if the asm changed. if it didn't, it wasn't necessary
[21:04:26] <ohsix> ^ wtf
[21:04:29] <BastyCDGS> BBB, I don't use const mainly for assembly change but as a hint for myself
[21:04:33] * BBB puts a boxing ball between BastyCDGS and mru
[21:05:25] <hyc> wbs: does that patch make my pts patch go away?
[21:05:28] <BastyCDGS> mru, I just said that valgrind is like enforcer...right? and enforcer does check for illegal memory accesses (which are part of debugging) and that's why I assign stuff like valgrind/enforcer to debuggers also
[21:05:42] <mru> BastyCDGS: and you keep going on and on and on about it
[21:05:57] <wbs> hyc: yes, with that one, your patch is unnecessary
[21:06:06] <hyc> cool
[21:06:10] <hyc> I'll give it a shot
[21:06:50] <wbs> hyc: but that should be the last unapplied bit of your patches touching ffserver.c
[21:07:06] <wbs> so I think it's nearing some kind of almost-usable state soon ;P
[21:07:09] <BBB> BastyCDGS: get going, this is your gsoc chance, show us you can do this :)
[21:07:20] <DonDiego> BastyCDGS: mans is trying to make you cut down on the idle chatter a bit - it would indeed be appreciated, no hard feelings and don't take offense
[21:07:21] <BBB> BastyCDGS: want a summary of all this on the mailinglist?
[21:07:29] <mru> I looked up enforcer and it's nothing like valgrind
[21:07:32] <hyc> wbs: yes, looks like it. still have the rtp-level stuff to sort thru
[21:07:47] <BBB> did josh start coding, wbs?
[21:07:48] <BastyCDGS> BBB, a summary would be really appreciated, yes :)
[21:07:53] <BBB> BastyCDGS: good, coming up
[21:07:54] <hyc> wbs: does the suggestion about bitstream filters make sense to you?
[21:08:08] <mru> all it does is provide page-level protection similar to what the OS should already do
[21:08:14] <hyc> or should we jsut be thinking about a couple utility functions that can be used in each place
[21:08:27] <wbs> hyc: I think it makes sense, but I'm not at all familiar with bitstream filters
[21:08:41] <wbs> hyc: neither am I familiar with h264 formats at that level
[21:08:53] <wbs> BBB: haven't heard from him, lu_zero is his mentor formally afaik
[21:08:59] <hyc> wbs: me neither, no idea how we would get ffserver to configure them.
[21:09:06] <BBB> wbs: yes but you're online more than lu_zero ;)
[21:09:25] <wbs> BBB: :-)
[21:10:03] <hyc> valgrind is a virtual machine, which happens to have loadable modules that can assist in different debugging tasks
[21:10:11] <hyc> enforcer is more like electricfence
[21:10:20] <hyc> single-purpose tools...
[21:10:38] <BastyCDGS> but both enforce and valgrind check for illegal memory accesses
[21:10:45] <wbs> hyc: but that's a generally very desired thing; it's needed if you want to do stream copy of h264 from one container assuming one format to another, which has only been solved with (more or less) hacks up to now, afaik
[21:10:46] <DonDiego> GEEEZZZ
[21:10:54] <mru> BastyCDGS: you obviously don't know what valgrind is
[21:10:55] <BastyCDGS> that's what I meant with sth. like (not equal)
[21:11:00] <DonDiego> stop trolling about tools already
[21:11:05] <mru> you probably don't know what a virtual memory operating system is either
[21:11:20] <DonDiego> i'm trying to debug a crash here..
[21:11:44] <peloverde> wbs, AAC has the same problems :(
[21:11:52] <wbs> peloverde: yeah, that too
[21:12:23] <BastyCDGS> mru, but what you meant then as you said that valgrind changes behaviour on illegal mem access...doesn't that imply it checks for these?
[21:12:29] <peloverde> Wasn't there some sort of auto BSF negotiation patch floating around?
[21:12:36] <wbs> hyc: it would be very beneficial to fork that discussion off to a separate thread, and see if you get a proper solution explained to you, so that you or someone else can implement it :-)
[21:12:37] <mru> BastyCDGS: just fucking go and read about it
[21:13:12] <bcoudurier> wbs, this is wrong
[21:13:42] <wbs> bcoudurier: ok, so how is it supposed to work, then?
[21:14:05] <wbs> bcoudurier: with the current state of things, cur_pts can have values in two totally different ranges
[21:14:35] <bcoudurier> cur_pts is dts
[21:15:06] <bcoudurier> btw start_time should be changed to first_dts
[21:15:26] <bcoudurier> find out why
[21:15:36] <bcoudurier> but assigning it always to 0 is definetely wrong
[21:16:02] <hyc> bcoudurier: did you already read the context here? https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/089280.html
[21:16:20] <wbs> the first packet seems to pass that code before start_time is initialized
[21:17:15] <DonDiego> siretart: what do we need for the 0.5.2 release?
[21:17:45] <DonDiego> changelog update, VERSION bump, tarballs, homepage entry, anything i forget?
[21:18:17] <bcoudurier> yes
[21:20:01] <bcoudurier> current code logic seems right to me
[21:20:13] <bcoudurier> get_packet_send_clock
[21:20:17] <wbs> but what should cur_pts be set to, if start_time isn't initialized?
[21:20:25] <DonDiego> janneg: is your "prefer libs" patch committed?
[21:21:25] <bcoudurier> this is a problem
[21:21:32] <bcoudurier> find out why it is not initialized
[21:21:34] <bcoudurier> and fix that
[21:21:53] <wbs> or did you mean that I should use c->first_pts instead of ist->start_time there?
[21:21:59] <bcoudurier> otherwise set start_time to the first value you get
[21:22:07] <bcoudurier> next values should be fine
[21:22:16] <bcoudurier> first_dst
[21:22:19] <bcoudurier> dts
[21:22:19] <hyc> bcoudurier: it's not that simple
[21:22:29] <hyc> in the case I saw, the first packets had absolute timestamps
[21:22:32] <siretart> DonDiego: we need a release checklist :-)
[21:22:34] <hyc> subsequent had only relative
[21:22:45] <bcoudurier> this is wrong
[21:22:47] <bcoudurier> a bug
[21:22:56] <bcoudurier> fix the bug
[21:23:25] <DonDiego> siretart: yeah, i guess :)
[21:23:56] <hyc> bcoudurier: so what is the expected content? all relative?
[21:23:59] <hyc> or all absolute ?
[21:24:18] <bcoudurier> pkt.dts is absolute
[21:24:28] <siretart> DonDiego: otherwise, I think that's about it.
[21:25:03] <DonDiego> ok, let's start, who does what?
[21:25:06] <hyc> bcoudurier: ok, that should give me an idea what to look for, thanks
[21:30:17] <janneg> DonDiego: I don't think so
[21:31:34] <DonDiego> siretart: i've been getting a lot of prodding that the native vorbis encoder should be disabled somehow on the branch
[21:33:03] <siretart> DonDiego: in 0.5 or 0.6 or both?
[21:33:26] <DonDiego> 0.6 is what matters most
[21:33:42] <DonDiego> in 0.5 i don't think we should fiddle with defaults anymore
[21:33:47] <DonDiego> that's set
[21:33:54] <DonDiego> no surprises
[21:34:00] <siretart> hm. who did propose that?
[21:34:06] <DonDiego> propose what?
[21:34:16] <siretart> to disable the native vorbis encoder?
[21:34:29] <DonDiego> i hear it from all sides
[21:34:44] <DonDiego> baptiste, alex converse, janne and today all the xiph people
[21:34:54] <siretart> okay, that convinces me :-)
[21:35:33] <siretart> do we already have a patch for that?
[21:35:45] <DonDiego> janneg is working on one
[21:35:56] <DonDiego> otherwise i can just disable the vorbis encoder in configure
[21:36:06] <DonDiego> so that it does not get compiled by default
[21:36:18] <hyc> bcoudurier: then it sounds like this is wrong: c->cur_pts -= av_rescale_q(ist->start_time, ist->time_base, AV_TIME_BASE_Q);
[21:36:39] <hyc> why isn't it using c->first_pts instead?
[21:38:46] <janneg> DonDiego: if you want to release soon disabling it in configure is probably the easiest solution for the branch
[21:38:49] <wbs> I was about to suggest that, too
[21:40:16] <wbs> using c->first_pts that is
[21:42:44] <CIA-93> ffmpeg: diego * r23298 /branches/0.5/Changelog: Update Changelog for 0.5.2 release.
[21:43:24] <spaam> why release 0.5.2 when you guys are going to release 0.6 ?
[21:45:58] <bcoudurier> ist->start_time is the first pts of the stream
[21:46:05] <DonDiego> oh, a release troll..
[21:46:11] <wbs> bcoudurier: start_time only gets initialized after the second packet, for reasons deep within libavformat
[21:46:21] <bcoudurier> that's a bug
[21:46:35] <bcoudurier> DonDiego, where ? :>
[21:46:39] <siretart> spaam: because there are still people that use 0.5 and we are willing to do the release
[21:46:50] * DonDiego points his finger at spaam ..
[21:46:56] <bcoudurier> arf
[21:46:58] <DonDiego> :)
[21:48:25] <spaam> DonDiego: i like you too.
[21:48:29] <spaam> siretart: ok :)
[21:49:07] * DonDiego pets spaam 
[21:49:12] <DonDiego> hey, no hard feelings :)
[21:49:17] <spaam> its ok :)
[21:49:43] <DonDiego> the regulars *do* troll me about maintaining the 0.5 branch..
[21:49:51] <spaam> DonDiego: you are not like KotH ;) he like to kick me ;S
[21:49:53] <DonDiego> siretart: any suggestions for the release notes?
[21:51:23] <wbs> bcoudurier: do you think this would be an acceptable patch? http://albin.abo.fi/~mstorsjo/0001-Make-sure-cur_dts-is-initialized-before-calling-upda.patch
[21:51:57] <wbs> I guess such things need to go through michael anyway, so I'll post it to the mailing list
[21:52:18] <KotH> spaam: rotfl
[21:52:49] <spaam> KotH: you cant deny that
[21:53:04] <KotH> can someone give me op? i have to kick spaam
[21:53:25] <KotH> DonDiego: thanks
[21:53:35] <spaam> KotH: <3
[21:53:40] <siretart> DonDiego: this is a maintenance only release. distributors and system integrators are encouraged to update and share their vendor patches against this branch. something like that
[21:54:06] <DonDiego> i mean for the RELEASE file
[21:54:24] <BBB> feature add is MINOR or MICRO update?
[21:54:40] <DonDiego> if you have ideas, go for it, i'm a bit tired and not creative right now..
[21:56:10] <CIA-93> ffmpeg: diego * r23299 /branches/0.5/VERSION: Bump version number for 0.5.2 release.
[21:57:03] <siretart> BBB: depends. if it involves new public symbols or enum changes, minor. otherwise, micro
[21:57:26] <BBB> it's a new protocol
[21:57:30] <BBB> others update minor
[21:57:33] <BBB> I'll updat minor
[21:58:20] <siretart> yes, that sounds right.
[21:58:41] <siretart> DonDiego: as for RELEASE file, I think that's fine. my text is more something for the website
[21:58:58] <DonDiego> i used it for RELEASE :)
[21:59:09] <DonDiego> i just committed it
[21:59:18] <DonDiego> feel free to change it any way you see fit..
[21:59:38] <CIA-93> ffmpeg: diego * r23300 /branches/0.5/RELEASE: release notes for 0.5.2
[22:00:31] <CIA-93> ffmpeg: rbultje * r23301 /trunk/ (6 files in 3 dirs): MMS-over-TCP protocol support. Patch by Zhentan Feng <spyfeng gmail com>.
[22:01:32] <kierank> nice mms over tcp
[22:01:33] <siretart> DonDiego: yea, I think it's good
[22:03:43] <DonDiego> ok, what did we forget then?
[22:03:50] <siretart> heh
[22:07:32] <BBB> kierank: mms-http (the most-used one) is coming
[22:07:39] <KotH> night girls
[22:07:40] <BBB> then we can kill libmms
[22:08:07] <kierank> I remember spending ages when I had dialup trying to save those mms streams because the 33.6kbps ones looked like crap
[22:08:31] <hyc> wbs, bcoudurier: no, something is still wrong. c->cur_pts is an absolute stamp, get_packet_send_clock() returns an absolute time
[22:08:39] <hyc> get_server_clock() retur5ns a relative time
[22:09:01] <hyc> so that comparison will always result in "it's not time to send a pkt yet"
[22:09:40] <BBB> kierank: don't trash it yet... we don't do bitrate negotiation yet
[22:09:45] <BBB> kierank: we will, but not yet now
[22:12:00] <kierank> I'm talking about problems getting mms to work 10-15 years ago ;)
[22:12:14] <bcoudurier> yes it is
[22:15:31] <BBB> kierank: oh, I'm affraid I might not be able to help with that ;)
[22:17:23] <bcoudurier> get_server_clock return the time passed since ...
[22:17:40] <bcoudurier> c->cur_pts is the dts of the packet and that is absolute
[22:18:01] <hyc> correct
[22:18:20] <hyc> and get_packet_send_clock basically jsut returns c->cur_pts
[22:18:35] <hyc> so you cannot compare the result of get_packet_send_clock() to get_server_clock())
[22:20:08] <bcoudurier> you can
[22:20:17] <bcoudurier> it's absolute in the _file_
[22:20:42] <bcoudurier> like for mp4 it will be 0, 1, 2, 3, 4, 5 in frame counter at 25, 0, 0.04, 0.08 etc ...
[22:20:50] <bcoudurier> for mpeg dts/pts never start at 0
[22:20:57] <bcoudurier> so you substract start_time
[22:21:02] <bcoudurier> st->start_time
[22:21:11] <bcoudurier> that's the way I understand it
[22:21:12] <hyc> hmmmmm
[22:21:19] <hyc> I just saw something
[22:21:33] <hyc> there are two streams since there is audio+video
[22:21:45] <hyc> onely one of them had ist->start_time initialized properly
[22:22:27] <hyc> which kind of makes sense - if you only init it on the first packet in a stream
[22:22:45] <hyc> the "first packet" can only belong to one stream. the other stream never gets init'd.
[22:24:19] <hyc> so whose responsibility is it to initialize start_time ?
[22:24:29] <mru> the big bang
[22:24:46] <hyc> this is a live feed, so ffmdec?
[22:26:07] <bcoudurier> avformat
[22:27:45] <hyc> gaahh... //We skip H264 currently because ...
[22:28:00] <hyc> so the video stream is not hitting any of this init code because it's H264
[22:44:25] <DonDiego> release done..
[22:44:27] <DonDiego> \o/
[22:46:38] <spaam> \o/
[22:46:44] <Dark_Shikari> 0.6?
[22:48:10] <DonDiego> no, 0.5.2
[22:48:18] <DonDiego> a quick point releae
[23:06:44] <DonDiego> bcoudurier: you around?
[23:08:51] <bcoudurier> yes
[23:11:18] <DonDiego> monty has a bug report for your ogg muxer
[23:12:11] <DonDiego> i'll cc you on the reply
[23:13:48] <bcoudurier> ah cool
[23:14:54] <bcoudurier> nope
[23:14:56] <bcoudurier> file is valid
[23:16:58] <ohsix> as reported by oggz-validate?
[23:17:09] <bcoudurier> yes
[23:17:28] <bcoudurier> but ok
[23:17:32] <bcoudurier> let's be friendly :)
[23:17:48] <DonDiego> just answer the mail and keep the list in the cc
[23:18:02] <ohsix> does he not post to the ml?
[23:18:58] <lu_zero> where is the email?
[23:19:25] <DonDiego> foms mailing list
[23:19:27] <DonDiego> private
[23:20:21] <mru> what's the "bug"? it beats his muxer?
[23:21:06] <bcoudurier> the serial number crap
[23:21:12] <mru> what of it?
[23:21:21] <bcoudurier> I use stream index
[23:21:25] <bcoudurier> 0, 1, 2, 3,
[23:21:26] <mru> seems sane enough
[23:21:31] <mru> he wants it "random" I guess
[23:21:34] <DonDiego> "It is still not setting serial numbers on Ogg streams.  This should be fixed."
[23:21:36] <bcoudurier> yes
[23:21:38] <bcoudurier> he wants random
[23:21:50] <Dark_Shikari> why
[23:21:57] <mru> while (random() != any_of_the_other_numbers)
[23:22:00] <ohsix> you cant just append them if the numbers are serial :]
[23:22:02] <bcoudurier> yes
[23:22:03] <janneg> "0, 1, 2, 3," looks perfectly random to me
[23:22:09] <mru> ohsix: you'd still have to check them
[23:22:14] <mru> and potentially rewrite
[23:22:19] <mru> so there's no difference
[23:22:33] <ohsix> potentially to always renders the entire thing moot
[23:22:38] <Dark_Shikari> janneg: http://webs.bcp.org/sites/amathurin/images/Dilbert(Random).jpg
[23:22:43] <mru> I really, really hate it when people make the idiotic assumption that random implies globally unique
[23:22:49] <Dark_Shikari> That's the problem with randomness
[23:22:49] <mru> or even locally unique
[23:22:52] <Dark_Shikari> You can never be sure ;)
[23:23:03] <lu_zero> wbs: poing2
[23:23:04] <ohsix> its not unique, just unlikely; its like a hash but it doesn't chain when theres a collision
[23:23:15] <mru> if anyone thinks of a plan to detard xiph, let me know
[23:23:16] <janneg> Dark_Shikari: http://xkcd.com/221/
[23:23:18] <Dark_Shikari> ohsix: similarly, assuming that hashes don't collide is rather bad
[23:23:24] <Dark_Shikari> CCP did that with EVE Online's filesystem
[23:23:31] <Dark_Shikari> then one day, about 5 years after release
[23:23:33] <Dark_Shikari> they added one file
[23:23:35] <ohsix> you don't assume, the space is large
[23:23:35] <Dark_Shikari> and the entire game broke
[23:23:43] <Dark_Shikari> There had been a hash collision.
[23:24:04] <Dark_Shikari> ohsix: there's a great paper about how assuming that hashes don't collide is stupid, even for a filesystem using 128-bit hashes
[23:24:15] <mru> random numbers are hard to predict, but there is _no_ promise of uniqueness
[23:24:21] <janneg> Dark_Shikari: 32 bit hash?
[23:24:28] <ohsix> Dark_Shikari: it doesn't matter, you misconstrue the intent
[23:24:29] <mru> you just don't know _which_ two random numbers will collide
[23:24:29] <bcoudurier> yes I have to check them now
[23:24:36] <bcoudurier> fuck I'm lazy
[23:24:44] <DonDiego> tsk, tsk
[23:24:50] <DonDiego> you lazy lout you!
[23:25:01] <Dark_Shikari> janneg: CCP's, yes
[23:25:02] <ohsix> and it doesn't matter if you assume or not if theres no collision; you merely assure it with the way its muxed by ffmpeg
[23:25:15] <mru> assuming 128-bit hashes rarely collide is fine, provided you have a (potentially expensive) way of dealing with it
[23:25:25] <ohsix> and its antithetical to the intent behind the numbers
[23:25:26] <mru> but in this case there is no difference at all
[23:25:33] <mru> ohsix: the intent is retarded
[23:25:40] <mru> you still have to check them
[23:25:42] <ohsix> thats a difference of opinion
[23:25:53] <ohsix> you do, but you're changing the likelyhood
[23:25:55] <mru> and if they collide, you must be ready to rewrite them
[23:26:14] <mru> so the code is _exactly the same_
[23:26:50] <BastyCDGS> dark_shikari, I'm interested reading the paper regarding assumption of non-hash collisions is stupid
[23:26:51] <ohsix> but in practice it is not; you change unlikely to likely and opt for the expensive operation, the files as they are have a stigma of expensive operations
[23:27:15] <mru> the hardest part is parsing them to check for collisions
[23:27:19] <Dark_Shikari> I _think_ it's
[23:27:21] <Dark_Shikari> An analysis of compare-by-hash
[23:27:21] <mru> and you're not escaping that
[23:27:22] <Dark_Shikari> V. Henson
[23:27:25] <Dark_Shikari> from USENIX
[23:27:33] <mru> the operation as a whole is io-bound anyway
[23:27:37] <Dark_Shikari> BastyCDGS: ^
[23:27:38] <DonDiego> http://www.osnews.com/story/23346/Nero_Files_Antitrust_Case_Against_MPEG-LA
[23:27:49] <Dark_Shikari> DonDiego: welcome to a few days ago =p
[23:28:02] <ohsix> regardless; you know the intent of the number from the person who created the format
[23:28:10] <mru> Dark_Shikari: and the lawsuit is from january
[23:28:15] <Dark_Shikari> mru: And yeah, that
[23:28:16] <janneg> DonDiego: "
[23:28:18] <BastyCDGS> thanks seems be the right
[23:28:27] <mru> ohsix: I know the person who created the format is an idiot
[23:28:35] <mru> so whatever his intent, it's irrelevant
[23:28:43] <ohsix> don't get distracted, you know the intent of the number
[23:28:47] <mru> besides, consecutive numbering is valid
[23:28:53] <janneg> DonDiego: money quote "absolute power corupted MPEG LA absolutely"
[23:28:57] <mru> libogg will happily do it btw
[23:29:22] <mru> ohsix: unless the intent was to annoy the hell out of everybody, I really don't know
[23:29:34] <mru> that seems to be just about all that idiot is capable of
[23:29:48] <ohsix> the intent for them to rarely have collisions and putting files together is a cheap operation
[23:30:06] <mru> it's a false sense of fuzzy and warm
[23:30:16] <BastyCDGS> if someone else wants to read it:
[23:30:16] <mru> but watch out, this kitten has claws
[23:30:19] <BastyCDGS> http://valerieaurora.org/review/hash/index.html
[23:30:21] <ohsix> it saves work
[23:30:25] <mru> does not
[23:30:39] <mru> you still have to write all the code to handle a collision
[23:30:43] <ohsix> you're assuring that it doesn't by generating all worst case files
[23:30:53] <janneg> iirc monty claimed that the intent is to somehow prevent serial clashes on single bit errors
[23:31:00] <mru> besides, did anyone _ever_ have a need to concatenate two ogg files?
[23:31:05] <ohsix> you don't avoid not writing code to handle collisions, you make it extremely unlikely that it need be done
[23:31:26] <ohsix> does that change anything?
[23:31:26] <mru> janneg: in that he has a very twisted idea of error resilience
[23:31:47] <DonDiego> janneg: yeah, that quote is great
[23:31:47] <mru> ohsix: the work is writing the code, not running it
[23:31:53] <janneg> random() is a very poor method since it is not very good at it
[23:32:11] <ohsix> heh
[23:32:29] <janneg> DonDiego: but nothing that I would have expected in in serious law doc
[23:32:43] <mru> anyway, if he's complaining about it, why did he allow it in the spec?
[23:33:34] <ohsix> thats a red herring
[23:33:41] <mru> nope
[23:33:42] * lu_zero still wonders why discussing at lenght about it
[23:33:42] <ohsix> you know the intent and the method
[23:33:45] <mru> the spec is everything
[23:33:52] <lu_zero> 1 2 3 4 5 is a perfectly valid random sequence
[23:33:57] <ohsix> yep, the very definition of a red herring; with regard to the "bug"
[23:34:19] <mru> given the spec, the code is flawless, and he had better shut up
[23:34:50] <janneg> how should the serial handled in stream with 2^32 streams?
[23:34:57] <mru> if resiliency were the goal, the spec should've required something like no two numbers differing by a single bit only
[23:35:23] <janneg> s/stream/files/
[23:35:42] <mru> I doubt they think that big
[23:36:03] <mru> and such a file is rather unlikely anyway
[23:36:09] <lu_zero> if their idea was to provide a cheap way to "stream" through http using netcat
[23:36:21] <mru> lu_zero: in that case they still busted it
[23:36:37] <lu_zero> in many different ways =P
[23:36:42] <mru> they can't possibly require that all ogg files ever created have unique IDs
[23:37:01] <ohsix> "if", you know you can read about it http://people.xiph.org/~xiphmont/lj-pseudocut/o-response-1.html
[23:37:03] <mru> unless they didn't envision a very widespread adoption
[23:37:16] <mru> ohsix: is that supposed to be funny?
[23:37:33] <janneg> yes, but if uniquess is their goal why not using 16bit serials and a 16 bit hash of it
[23:37:51] <mru> retards?
[23:38:25] <CIA-93> ffmpeg: bcoudurier * r23302 /trunk/libavformat/oggenc.c: In ogg muxer, use random serial number of each ogg streams
[23:38:46] <ohsix> i think the point on the elementary stream numbers is prophetic
[23:39:00] <lu_zero> hmm
[23:39:09] <bcoudurier> I need yuvi for the upper limits blah blah
[23:39:11] <mru> I think it's pathetic
[23:39:13] <Dark_Shikari> mru: I think you're missing the point wrt abiding by stupid specs
[23:39:20] <Dark_Shikari> If the spec says something retarded
[23:39:23] <Dark_Shikari> the best thing is to obey it
[23:39:25] <bcoudurier> I don't maintain vorbis/theora wrappers
[23:39:27] <Dark_Shikari> because that means if something breaks as a result
[23:39:30] <Dark_Shikari> You can blame someone else.
[23:39:31] <mru> Dark_Shikari: we _are_ obeying the spec
[23:39:38] <mru> it's the idiot who's claiming we're not
[23:39:45] <Dark_Shikari> in this case, the spec is xiphmont's head
[23:39:55] * mru shoots monty
[23:39:57] <mru> not anymore
[23:40:02] <lu_zero> it's leaking now
[23:40:05] <lu_zero> even worse
[23:40:09] <Dark_Shikari> haha
[23:40:11] <janneg> Dark_Shikari: that doesn't scale
[23:40:17] <Dark_Shikari> janneg: sure it does
[23:40:34] * lu_zero meanwhile tries to decode Michael suggestion about the reordering in rtp
[23:41:02] <bcoudurier> janneg,
[23:41:08] <bcoudurier> your patch is ok for encoding
[23:41:16] <Dark_Shikari> <pengvado> are there any devices that support 25 mbit high profile (L4.0), but don't support 25mbit main profile (L4.1) ?
[23:41:19] <bcoudurier> it should be applied
[23:41:19] <Dark_Shikari> <Dark_Shikari> no idea, but its easier to blanket-apply the rule to everything than to special-case
[23:41:23] <Dark_Shikari> <Dark_Shikari> you can never go wrong by abiding by the spec, since if someone breaks the spec you can just blame them instead
[23:41:26] <Dark_Shikari> <pengvado> fair enough. I'll allow the patch on the premise of passing the blame.
[23:41:29] <Dark_Shikari> there's the relevant quote :)
[23:41:30] <ohsix> you're just generating worst case degenerate files in all cases with respect to the elementary stream number
[23:41:47] <mru> ohsix: I don't fucking care
[23:42:00] <mru> there is no difference in any relevant use-case
[23:42:03] <mru> and the code is simpler
[23:42:28] <ohsix> your use cases don't involve using ogg at all so what is that supposed to mean?
[23:42:47] <janneg> bcoudurier: I'm not so sure, I'm looking atm at ffmpeg.c and it seems to use avcodec_find_encoder_by_name to get a codec id and uses it later to open the codec
[23:43:08] <bcoudurier> what ?
[23:43:21] <bcoudurier> there is no codec name by default
[23:43:31] <bcoudurier> anyway I need to reboot, brb
[23:49:09] <janneg> bcoudurier: no, it doesn't. I've missed the "output_codecs[nb_ocodecs] = codec;"
[23:49:25] <janneg> codec is the result of avcodec_find_encoder_by_name
[23:49:53] <bcoudurier> so ?
[23:49:56] <janneg> bcoudurier: why do you think it should not be added for decoders?
[23:50:16] <bcoudurier> because av_find_stream_info will have side effects
[23:50:53] <janneg> I don't think we have currently an experimental decoder and I don't expect any
[23:51:51] <janneg> for new decoder development it has the same side effect as the alphabetical order of decoders in allcodecs.c
[23:52:11] <peloverde> ffaacdec is less feature complete than libfaad2 but is also faster and less buggy
[23:52:31] <mru> peloverde: what's the holdup with PS?
[23:53:00] <peloverde> It's being reviewed now, see ffmpeg-devel and ongoing changes in git
[23:53:12] <mru> is anything else missing?
[23:53:24] <peloverde> Even then we are still missing ER and the features no one uses
[23:53:31] <peloverde> (LTP, SSR)
[23:53:38] <Dark_Shikari> wait I thought we had LTP?
[23:53:45] <mru> so nothing that matters then
[23:53:52] <peloverde> Apparently there us LTP in the soc branch
[23:53:56] <mru> and nobody will be sad if we drop libfaad support?
[23:54:21] <peloverde> I thought main didn't matter until I saw it in use in hulu
[23:54:32] <peloverde> LTP is trivial
[23:54:48] <peloverde> LD requires ER syntax and is apparently used in some applications
[23:54:48] <janneg> anyone writing a new decoder is free to omit CODEC_CAP_EXPERIMENTAL while he is writing it and should be able to disable the non experimental codec through configure if needed
[23:55:27] <lu_zero> hmm
[23:55:48] <janneg> bcoudurier: I think inconsistent behaviour for avcodec_find_decoder|encoder is bad
[23:55:54] <ohsix> hey speaking of hulu, its working on x86_64 (w/64bit flash) again
[23:56:10] <peloverde> is make ever going to update 64-bit flash?
[23:56:21] <peloverde> or has it been abandoned?
[23:56:25] <peloverde> s/make/Mike/
[23:56:37] <bcoudurier> it's _different_
[23:57:07] <bcoudurier> there is no problem in being _different_
[23:57:13] <janneg> bcoudurier: I would prefer to to add a comment to #define CODEC_CAP_EXPERIMENTAL that marking decoders as exprimental can have unintended side effect for example in av_find_stream_info
[23:58:16] <ohsix> peloverde: dunno but i'm pretty darn happy with the one thats available, its still updated unter the "alpha" or "beta" or whatever moniker they use for it, but it hadn't been for like 4months last time i checked
[23:58:39] <ohsix> for calling it alpha its pretty solid; but i've never had flash crash anything :[
[23:58:43] <hyc> ohsix: you mean you updated your 64 bit flash plugin? or hulu changed something?
[23:58:59] <ohsix> hyc: software unchanged, hulu must have done something