[FFmpeg-devel-irc] IRC log for 2010-07-31

[irc at mansr.com]

[00:03:06] <Tjoppen> vp8 encoder in the works?
[00:03:35] <mru> if only for the troll factor
[00:03:56] <Tjoppen> hehe
[00:06:04] <Dark_Shikari> Tjoppen: as a runtime option
[00:06:08] <Dark_Shikari> which creates extra drama
[00:06:13] <Dark_Shikari> then you have to install x264 to install x264-vp8 ;)
[00:06:33] <Tjoppen> interesting
[00:06:37] <kierank> i approve of trolling as a reason to create x264-vp8
[00:07:27] <Tjoppen> btw, are there any dsp utils for say ssim in ffmpeg? or is taht only in x264 (as far as I understand..)?
[00:07:57] <Tjoppen> I did a quick look found moslty the usual sum-of-square-diffs
[00:08:13] <Dark_Shikari> no
[00:08:29] <Dark_Shikari> Actually, you know, this'd be pretty funny
[00:08:33] <Dark_Shikari> if ffmpeg is the only decent vp8 decoder
[00:08:38] <Dark_Shikari> and x264 is the only decent encoder
[00:08:42] <Dark_Shikari> It'll be like we're back at square one.
[00:16:21] <peloverde> So youtube will use it while not contributing back even bug reports?
[00:16:57] <Dark_Shikari> probably.
[00:22:36] <Tjoppen> some friday entertainment: I wrote a cinepak encoder
[00:23:26] <Tjoppen> well, actually a while back. works, but I'm unsure how well :)
[00:44:26] <bcoudurier> who's working on that ?
[02:28:13] <Compn> Dark_Shikari : should make an rv40 encoder :P
[02:28:14] <Compn> eheh
[04:33:56] <saintdev> wtf, correcting window decision makes pre-echo worse??
[04:52:37] <saintdev> lol, nero completely misjudges the attack, but still has less pre-echo than we do
[04:53:11] <peloverde> Because they have TNS
[04:53:26] <Dark_Shikari> what's TNS do for transients?
[04:53:30] * saintdev shakes fist at TNS
[04:53:45] <peloverde> Read the section on TNS of this paper: http://mp3-tech.org/programmer/docs/Temporal%20Noise%20Shaping%20Quantization%20and%20Coding%20Methods%20in%20Perceptual%20Audio%20Coding%20-%20A%20Tutorial%20Introduction.pdf
[04:54:38] <peloverde> It runs a forward predictor on frequency domain data to push the noise around in the time domain
[04:55:36] <peloverde> I have 13818-7/3GPP TNS coded but apparently that actually makes it worse (or so I've been told)
[04:56:05] <saintdev> anything 3gpp scares me :P
[04:56:28] <peloverde> 3GPP largely was a huge step up over 13818-7
[04:57:07] <saintdev> peloverde: i started looking at itunes window grouping, they do some pretty crazy-awesome grouping
[04:58:01] <peloverde> well they hired dolby to rewrite big chunks of their encoder
[04:58:56] <saintdev> yes, and they did a very good job. even before they had VBR, they still out-performed VBR encoders
[04:59:46] <bcoudurier> dolby's encoder is pretty good
[05:00:43] <saintdev> peloverde: what do you think about a leading/trailing scheme, putting the block before, attack block, and block after each in their own group?
[05:01:41] <peloverde> Will that actually significantly help, I though most pre-echos were less than 128 samples
[05:03:13] <saintdev> dunno, but it's the only idea i've come up with so far that seems better than 3gpp's
[05:03:35] <saintdev> itunes seems to do something _similar_ _sometimes_
[05:04:03] <saintdev> however their metrics are different, so it makes judging this kind of hard
[05:06:12] <peloverde> If you can test and verify something to be better, then by all means go for it, but it seems unlikely that 3GPP grouping will be that detrimental while TNS is missing/off
[05:06:38] <saintdev> then again itunes does things that absolutely baffle me. like a grouping of 5 3
[05:07:04] <peloverde> That could be reasonable
[05:07:06] <Dark_Shikari> are there _any_ AAC stream analyzers?
[05:07:09] <Dark_Shikari> that actually show this kind of stuff?
[05:07:15] <peloverde> no
[05:07:18] <Dark_Shikari> every one I've seen that claims to... doesn't
[05:07:20] <peloverde> I've spent a long long time looking
[05:07:21] <saintdev> the reference encoder
[05:07:28] <saintdev> *decoder
[05:07:28] <peloverde> The reference doecder will output it
[05:07:29] <Dark_Shikari> did you write one using lavc?
[05:07:32] <Dark_Shikari> ah
[05:08:00] <peloverde> I have some tools in numpy that graph some things from reference decoders debug output
[05:08:07] <peloverde> But they don't handle this
[05:08:30] <saintdev> wish there was something like MP3X, or even better a plugin for sonic visualiser would be killer
[05:08:46] <peloverde> If the attack is in window 5, and 5-8 have similar statistics, then 5 3 is perfectly valid grouping
[05:09:28] <saintdev> or is it maybe just trying to optimize for the "no-attack" case
[05:09:57] <peloverde> If it's no-attack then it should be one group, no?
[05:10:06] <saintdev> theoretically
[05:10:42] <saintdev> see and that is where 3gpp recommends 3 3 2, which i think is...wrong
[05:12:17] <peloverde> If your main pre-echo problem is <128 samples, all the fancy grouping in the world isn't going to help you
[05:12:24] <saintdev> sure
[05:12:49] <Dark_Shikari> peloverde: that's why it would be really nice to have an audio format with slightly non-power-of-2 sizes
[05:13:18] <Dark_Shikari> so that you could arrange combinations of windows over long periods of time to exactly match where the attacks happen
[05:13:34] <peloverde> TNS is rumored to solve the problem fine
[05:13:36] <saintdev> Dark_Shikari: or like vorbis where any power of 2 between 64 and 8192 are valid
[05:13:42] <peloverde> AAC-LD doesn't even use blockswitching
[05:13:42] <Dark_Shikari> saintdev: You can only use two of them
[05:13:50] <Dark_Shikari> If you could use any combination of them, you could do INSANE things imo
[05:13:58] <peloverde> because it adds an extra frame of delay
[05:14:04] <Dark_Shikari> you could do a massive viterbi lookahead
[05:14:06] <Dark_Shikari> peloverde: well duh
[05:14:18] <Dark_Shikari> AAC-LD is useless though, iirc CELT beats the crap out of it
[05:14:24] <saintdev> Dark_Shikari: oh, didn't know that. so vorbis has to pick 2 sizes to use for the entire bitstream
[05:14:30] <peloverde> CELT is about 5 years younger
[05:14:32] <Dark_Shikari> saintdev: yes.  it's to limit the number of windowing weights
[05:14:50] <Dark_Shikari> since number of window combinations you have to handle is O(N^2)
[05:15:15] <Dark_Shikari> it would be bad for mobile devices/etc if they had to keep track of 500 different iwndows
[05:15:38] <Dark_Shikari> peloverde: which is one reason it's better =p
[05:15:52] <peloverde> I agree it's better
[05:15:56] <peloverde> but good TNS supposedly handles pre-echo just fine
[05:17:13] <peloverde> but the good LC encoders seem to use both
[05:17:14] <Dark_Shikari> then let's implement TNS ;)
[05:17:41] <saintdev> Dark_Shikari: let's get rid of the spectral hole creator first
[05:17:43] <peloverde> I have TNS, I don't have the formulae the good encoders use for when to implement TNS
[05:18:38] <peloverde> I haven't seen holes at reasonable bitrate in a while (except for a few temporal holes related to window grouping)
[05:18:51] <peloverde> supposedly turning on TNS *hurts* faac
[05:19:22] <kshishkov> Nero != FAAC though
[05:19:43] <peloverde> I never said it was
[05:21:09] <peloverde> But I need good criteria of when to use TNS and filter selection
[05:21:23] <peloverde> 3GPP TNS is 13818-7 TNS is faac TNS
[05:21:40] <peloverde> faac TNS is *stolen* from the reference encoder
[05:21:48] <peloverde> It is one of the reasons faac is nonfree
[05:25:24] <saintdev> hmm, i'm starting to think nero's attack detection kind of sucks
[05:27:13] <peloverde> Ivan never wrote much about attack detection
[05:27:29] <Dark_Shikari> maybe look at CELT's attack detection
[05:27:32] <peloverde> IIRC
[05:28:28] <saintdev> Dark_Shikari: thanks, i'll have a look. although lame's seems to be working pretty well
[05:28:31] <peloverde> I think LAME's is ok
[05:29:00] <peloverde> What saintdev showed me can't be improved by better attack detection or grouping
[05:29:05] <peloverde> but at this point I'm mostly looking to wash my hands of AAC anyway
[05:29:12] <peloverde> so do whatever you think sounds good
[05:29:29] <Dark_Shikari> It's good to look at as much as possible
[05:29:40] <saintdev> agreed
[05:30:20] <saintdev> haven't yet dug into vorbis'
[05:30:26] <peloverde> Look everywhere for ideas but don't spen too long focusing on any one particular feature, keep hammering away at the worst offender
[05:30:59] <Dark_Shikari> try stealing vorbis's energy preservation shit
[05:31:06] <peloverde> I think LAME attack detection is fine, fixing two or three corner cases isn't going to help overall quality much
[05:31:08] <peloverde> exactly
[05:32:03] <peloverde> also for CBR LAME uses a TLS variant
[05:33:58] <bcoudurier> Dark_Shikari, do you play 2v2 at sc2 ?
[05:35:33] <Dark_Shikari> bcoudurier: not really, but I could.
[05:47:15] <votz> bcoudurier: what race do you play?
[05:49:38] <bcoudurier> terran
[05:49:54] <bcoudurier> if you wanna play Im in :>
[05:50:50] <votz> bcoudurier: absolutely :) give me a few. im playing some tef2 w/ another friend atm
[05:51:10] <bcoudurier> all righty
[06:00:21] <votz> bcoudurier: gonna go grab a glass of milk and a sandwich, then we can roll
[06:00:35] <votz> Dark_Shikari: in for 3s?
[06:01:44] <bcoudurier> ok
[06:05:13] <Dark_Shikari> 3v3?
[06:12:39] <votz> bcoudurier: fooded, time to roll
[06:12:59] <bcoudurier> great
[06:13:48] <Dark_Shikari> you want to do 3v3?
[06:13:55] <Dark_Shikari> or what
[06:14:24] <bcoudurier> if you are up to yeah
[06:14:40] <Dark_Shikari> sure one moment
[06:15:04] <Dark_Shikari> oh, there's a patch
[06:18:42] <Dark_Shikari> votz / bcoudurier : username so I can add you?
[07:45:47] <wbs> saintdev: how much of the work on the aac encoder is unmerged from trunk at the moment, btw? or is it mostly research in understanding what you should do?
[07:52:08] <lu_zero> 01:54 <@BBB> Dark_Shikari: let's start that tomorrow
[07:52:15] <lu_zero> May I play as well?
[07:52:32] <lu_zero> I want to learn x268 as well
[08:27:07] <mru> morning
[08:46:47] <_av500_> has broken?
[08:50:57] <KotH> zoi zäme
[08:52:29] <CIA-92> ffmpeg: mru * r24614 /trunk/configure: configure: set subarch for ARM
[09:06:58] <lu_zero> yawn
[09:10:42] <KotH> grüezi lu_zero
[09:10:54] <lu_zero> what's that?
[09:11:20] <KotH> lu_zero: about that roundup ssl thingy: is there anything i have to do?
[09:12:05] <lu_zero> I'm not exactly sure what michael wants
[09:12:29] <KotH> eh.. better than me. i have not even a clue what it is all about ^^'
[09:13:10] <lu_zero> his concern is about mim attacks
[09:42:04] <wbs> jenk: btw, you may want to update the readme for your rtsp server to mention that you want to use -re with ffmpeg when feeding data
[09:44:39] <mt> Hi
[09:45:23] <mt> Does this count as -near- bit-exact ? stddev:    9.34 PSNR: 76.92 bytes: 17973248/ 17973248
[09:45:41] <mru> no
[09:45:59] <mru> and you're using an old tiny_psnr
[09:48:27] <mt> I'll update and retest, but when you're comparing fixed vs floating point implementations, is it possible to get 0.0 stddev and 999 PSNR ?
[09:49:26] <mru> that psnr is lower than many lossy compressions
[10:06:46] <mt> So if I used ffmpeg to convert a wav file to say wma and back again to wav, and compared both wav files I would get a higher psnr ?
[10:08:11] <mru> maybe not wma
[10:10:08] <mt> ok regardless of being bit-exact, what's the minimum psnr for a fixed point implementation to be good ?
[10:11:41] <jenk>     right
[10:11:48] <jenk> thanks wbs
[10:11:48] <mru> what codec is this?
[10:11:56] <mt> mru: wmapro
[10:12:15] <mru> hmm, so no conformance tests available
[10:12:36] <mru> see what aac requires of a conforming implementation
[10:20:05] <ods15> mru, know git?
[10:20:37] <ods15> i did an octopus merge, and it failed halfway, so i fixed it.. now how do i continue the merge?
[10:22:17] <astrange> commit and that will be the merge commit
[10:22:36] <astrange> if it failed too early for that to work i don't know, it's not documented as doing that though
[10:22:48] <astrange> and i suppose there's git mergetool
[10:24:11] <ods15> it didn't even create MERGE_HEAD so i think if i'll commit it won't be a merge... i'll try
[10:26:30] <ods15> no, it's not marked as merge... ok, i'll just resolve this separately
[11:13:13] <mru> it's usually better to avoid octopus merges
[11:22:10] <lu_zero> even if the name is funny
[11:26:32] <KotH> better than hydra merge
[11:30:49] <lu_zero> that is problematic
[11:31:13] <lu_zero> either you cut all the heads or you have to keep all of them around
[13:40:29] <lu_zero> mru: poing
[13:40:46] <lu_zero> got the reply from the trolls
[13:41:15] <lu_zero> 1100 bottles 7e/bottle each bottle 3/4l
[13:42:27] <lu_zero> for the custom brew/label, otherwise he will sell us directly if we reach the 12x6 bottles at least
[13:42:49] <mru> what exactly does a custom brew entail?
[13:45:43] <_av500_> all the leftovers from past years...
[13:46:50] <Tjoppen> 75 cl bottles? way too big imo
[13:48:34] <lu_zero> he will prepare a beer with a specific recipe, custom labels and such
[13:49:00] <lu_zero> Tjoppen: that's the usual standard for such beers ^^;
[13:50:48] <lu_zero> if we have the paypal/checkout account ready we might start with a beer raise
[13:51:47] <lu_zero> otherwise I'd ask brewdog and delirium for a quotation but I have no clue which would be the answer
[14:51:48] <CIA-92> ffmpeg: vitor * r24615 /trunk/libavcodec/ (4 files in 2 dirs): Convert deinterlacing MMX code to YASM
[14:56:32] <kierank> blame the person who wrote the patch
[14:56:40] <kierank> whoops wrong channel
[14:59:47] <mru> applies here too
[15:46:22] <CIA-92> ffmpeg: stefano * r24616 /trunk/ (5 files in 2 dirs): Add protocols.texi.
[15:48:40] <mru> how can "add protocols.texi" change 5 files?
[15:50:20] <spaam> maybe he like to add protocols.texi into the other texi files.
[16:03:58] <jai> its %included at a bunch of places too
[16:04:09] <mru> yeah, I figured
[16:18:44] <CIA-92> ffmpeg: vitor * r24617 /trunk/libavcodec/imgconvert.c: Fix compilation with --disable-yasm. 10l to me.
[16:21:36] <CIA-92> ffmpeg: vitor * r24618 /trunk/libavcodec/x86/mmx.h: Remove x86/mmx.h. It is not used anymore and has been deprecated for years.
[16:21:56] <mru> \o/
[16:21:59] <BBB> \o/
[16:22:07] <BBB> everyone owes vitor1001 a beer now
[16:22:08] <Vitor1001> :D
[16:23:04] <Vitor1001> BTW, congrats mru for making your fate system the now official one :)
[16:23:31] <mru> we still need to migrate all the other systems
[16:23:58] <Vitor1001> mru: That does not really depend on you
[16:24:36] <Vitor1001> mru: And I like the failometer ;)
[16:25:08] <Vitor1001> mru: Maybe adding a number besides it so it is very noticiable if it changes?
[16:26:48] <BBB> Dark_Shikari: is inc x faster/shorter/smaller than add x, 1?
[16:26:53] <BBB> or is it identical in any practical way?
[16:27:15] <mru> stupid non-orthogonal instruction set
[16:27:44] <mru> BBB: I suspect inc is better
[16:27:51] <mru> since it's a small opcode
[16:28:01] <mru> doesn't need to code the immediate
[16:28:07] <Honoome> if it's still like the 8086 depends on the register as well
[16:28:29] <mru> add eax, 1 probably codes a full 32 bits for the 1
[16:28:47] * Honoome is still surprised that the high school course that had to teach him about 8086 asm never noted that ALU operations on ax were faster
[16:29:10] <mru> whaaat?
[16:29:23] <Honoome> but they also got the register order wrong, so...
[16:29:35] <Honoome> mru: 8086 has special opcodes for operations on ax
[16:29:35] <Vitor1001> BBB: I found in the internet the following: http://ffmpeg.pastebin.com/JTkh9RM0
[16:29:41] <Honoome> I mean the _original_ 8086
[16:30:36] <mru> ugh
[16:31:01] <Vitor1001> BBB: The small number of INC instructions on libavcodec/x86/ corroborates that
[16:31:34] <Honoome> so add ax, 1234 and add bx, 1234 are/were encoded in completely different way
[16:31:53] <BBB> Vitor1001: we don't read CF after
[16:31:57] <BBB> so it shouldn't affect dependency
[16:32:21] <Vitor1001> BBB: But an extra uop is not a good idea in general
[16:33:09] <Vitor1001> BBB: Maybe it stall also it if you write the CF flag after
[16:33:19] <BBB> right
[16:33:24] <BBB> ok, then I won't suggest changing it
[16:33:35] <BBB> we and our weird nano-optimizations
[16:33:47] <twnqx> it should recognize that the flag is not evaluated by the next instruction...
[16:34:03] <BBB> twnqx: only for OOE
[16:34:08] <BBB> so it'd be slower on atom etc.
[16:34:14] <BBB> (or so)
[16:34:15] <twnqx> mh true
[16:34:29] <mru> even in-order cpus can track dependencies
[16:34:41] <mru> they just never look more than one instruction ahead
[16:35:03] <BBB> I don't know enough about any of this
[16:38:15] <CIA-92> ffmpeg: jbr * r24619 /trunk/libavcodec/flacenc.c: Estimate frame size during encoding.
[16:47:11] <CIA-92> ffmpeg: stefano * r24620 /trunk/libavcodec/ (imgconvert.h imgconvert.c utils.c):
[16:47:11] <CIA-92> ffmpeg: Use av_fill_image_pointers/linesizes in place of ff_fill_pointer/linesize,
[16:47:11] <CIA-92> ffmpeg: and drop the the ff_ variants at the next major bump.
[16:47:11] <CIA-92> ffmpeg: jbr * r24621 /trunk/libavcodec/flacenc.c: Remove duplicate code by adding a flag for encoding in verbatim mode.
[16:51:17] <CIA-92> ffmpeg: jbr * r24622 /trunk/libavcodec/flacenc.c: Remove unneeded wrapper function.
[16:54:00] <CIA-92> ffmpeg: mru * r24623 /trunk/tests/fate-run.sh: fate: translate exit status to signal name
[17:07:03] <CIA-92> ffmpeg: jbr * r24624 /trunk/libavcodec/flacenc.c:
[17:07:03] <CIA-92> ffmpeg: Combine calc_rice_params_fixed() and calc_rice_params_lpc() into a single
[17:07:03] <CIA-92> ffmpeg: function.
[17:08:12] <CIA-92> ffmpeg: jbr * r24625 /trunk/libavcodec/flacenc.c: cosmetics: line wrap and vertical alignment
[17:24:19] <CIA-92> ffmpeg: jbr * r24626 /trunk/libavcodec/flacenc.c: Simplify fallback to verbatim mode encoding.
[17:28:27] <Dark_Shikari> BBB: inc is smaller
[17:28:50] <Dark_Shikari> it also doesn't set all flags
[17:28:58] <Dark_Shikari> the latter potentially being a negative in certain cases
[17:29:00] <Dark_Shikari> (flag merging)
[18:39:13] <kierank> is there a page that shows all the various channel orders which are in existence?
[18:40:08] <Dark_Shikari> list all permutations of.... =p
[18:48:58] <Kovensky> lol
[18:49:42] <CIA-92> ffmpeg: jbr * r24627 /trunk/libavcodec/flacenc.c: 10l: fix bit count for frame header
[18:57:08] <mru> gcc 4.5.1 released
[19:10:31] <spaam> mru: anything new ? :)
[19:10:37] <peloverde> meh, I don't use gcc anymoe
[19:10:45] <peloverde> *anymore
[19:10:56] <mru> what do you use?
[19:11:00] <peloverde> clang
[19:11:27] <spaam> too cool for gcc?
[19:11:42] <mmu_man> hcc ?
[19:11:58] <mmu_man> hppcc :)
[19:12:03] <mmu_man> the Hand, Paper and Pencil Compiler Collection
[19:12:12] <spaam> haha
[19:14:37] <Compn> kierank : no i dont think so
[19:14:50] <Compn> kierank : we should make a general list tho
[19:14:54] <Compn> on ze wiki
[19:15:00] <kierank> ya, that's what i was thinking too
[19:16:12] <Kovensky> <@peloverde> clang <-- did it stop miscompiling lavc and start generating useful debug info?
[19:16:18] <mru> peloverde: I tracked down the aac crashes on mips
[19:16:32] <mru> Kovensky: see fate for ffmpeg status
[19:16:43] <Kovensky> you added clang to fate?
[19:16:44] <mru> it passes on x86_64
[19:16:55] <mru> Kovensky: no, I added fate to ffmpeg
[19:16:59] <mru> http://fate.ffmpeg.org/
[19:17:09] <kierank> Compn: http://wiki.multimedia.cx/index.php?title=Channel_order
[19:17:15] <Kovensky> does it try compiling ffmpeg with clang? :P
[19:17:26] <Kovensky> oh yes, it does
[19:17:57] <Kovensky> does clang generate useful debug info now? 2.7 at least generates bogus info which makes it useless for debugging
[19:18:18] <mru> don't know, I don't debug
[19:18:39] <Kovensky> the bugs run away from you? :)
[19:18:51] <mru> peloverde: the aac crash is a combination of shitty fpu and missing kernel emulation
[19:18:52] * Kovensky pictures mru waving his shotgun at the bugs
[19:19:01] <peloverde>  clang works fine on x86_64
[19:19:07] <mru> apparently the loongson fpu can't do a fused madd with denormal inputs
[19:19:47] <mru> peloverde: adding -mno-fused-madd makes it work
[19:20:11] <peloverde> Where in the decoder was this happening?
[19:20:30] <mru> mdct
[19:20:59] <peloverde> hmmm, that kind of sucks
[19:21:07] <mru> -1.0365109066634699e-38
[19:21:37] <mru> for all I know that number was produced by a bug in the first place
[19:21:43] <mru> or low-precision fpu
[19:22:00] <mru> cheap chinese knockoffs...
[19:24:54] <peloverde> what about AVR? it seems to fail on some of the same streams?
[19:25:02] <mru> shitty softfloat implementatino
[19:25:14] <mru> it's known to be buggy as hell
[19:25:53] <peloverde> ok
[19:26:40] <peloverde> Well thanks for looking at that
[19:26:49] <mru> so do you think I should add the flag?
[19:28:02] <peloverde> What are the performance implications?
[19:28:26] <peloverde> Only AAC seems to fail, I don't want to unfairly penalize WMA and Vorbis
[19:28:27] <mru> it makes it _correct_
[19:28:43] <mru> only 3 of the aac streams fail too
[19:28:55] <mru> it's probably rather random what triggers those values
[19:29:30] <peloverde> so you think it's plausible that WMA and Vorbis streams could also trigger this?
[19:29:44] <mru> I don't see why not
[19:30:27] <peloverde> Then you probably should add the flag
[19:31:04] <peloverde> Shouldn't GCC not even generate code like that without sloppy math flags?
[19:31:22] <mru> there's nothing sloppy about it
[19:32:11] <peloverde> Is the C not legal?
[19:32:21] <mru> what do you mean?
[19:32:25] <mru> a += b * c
[19:32:30] <peloverde> I mean that the decoder is crashing
[19:33:24] <peloverde> The instruction seems to only implment a += b * c for a certain subset of a, b, and c
[19:35:47] <mru> at least on the loongson
[20:18:48] <CIA-92> ffmpeg: jbr * r24628 /trunk/libavcodec/flacenc.c: Reduce number of input parameters to find_subblock_rice_params().
[20:19:59] <CIA-92> ffmpeg: jbr * r24629 /trunk/libavcodec/flacenc.c: cosmetics: rename find_subblock_rice_params() to find_subframe_rice_params()
[20:21:22] <peloverde> Lots of FLAC cleanup lately
[20:24:27] <verb3k> I was told ffmpeg's FLAC encoder can lose precision with very long sources, is that still true?
[20:24:59] <mru> what does that even mean?
[20:25:30] <verb3k> Audio gets out of sync.
[20:25:39] <mru> eh?
[20:25:52] <mru> flac is a single audio stream
[20:25:57] <mru> out of sync with what?
[20:26:00] <verb3k> if it is to be coupled with video
[20:28:19] <verb3k> mru, if you encode say a long movie, and want to encode with ffmpeg's FLAC, it will not maintain be in perfect sync (that's what I was told, didn't even test)
[20:28:29] <verb3k> encode the audio*
[20:28:58] <mru> are you suggesting it isn't lossless?
[20:29:35] <verb3k> ask whoever said that in the first place (his name is twinx or some similar spelling, sorry :D)
[20:33:02] <CIA-92> ffmpeg: jbr * r24630 /trunk/libavcodec/flacenc.c:
[20:33:02] <CIA-92> ffmpeg: Calculate an exact frame size before writing. Now the buffer size requirements
[20:33:02] <CIA-92> ffmpeg: can be known exactly, so larger frame sizes can be safely encoded without buffer
[20:33:02] <CIA-92> ffmpeg: overwrite.
[20:38:55] <Kovensky> verb3k: twnqx
[20:39:08] <Kovensky> mru: IIUC he's suggesting there's timestamp fun
[20:50:16] <saintd3v> wbs: at the moment i'm just working on the psy model. I've got LAME window decision ported over, and working. still needs some tuning, though.
[20:51:01] <saintd3v> wbs: i've started porting over lame analysis, but that's quite a way from working still.
[20:53:27] <CIA-92> ffmpeg: jbr * r24631 /trunk/libavcodec/flacenc.c: Change max_framesize for small final frame.
[20:56:15] <Kovensky> saintd3v: writing ffmp3enc?
[20:56:48] <saintd3v> Kovensky: hoping to improve ffaacenc
[20:57:04] <Kovensky> oic
[20:58:24] <saintd3v> also teaching myself about aac and psychoacoustics in the process :)
[20:58:58] <cartman> how is ffmeg aac decoding these days?
[20:59:32] <mru> ffaacing awful
[20:59:58] <saintd3v> mru: lol, i had a whole responce typed out, but that wins by far
[21:00:19] <saintd3v> also, especially bad if you want more than one channel
[21:00:32] <Kovensky> uh
[21:00:43] <Kovensky> I think he meant to ask about the decoder, not the encoder :)
[21:01:01] <saintd3v> aye, that he did :O
[21:01:08] <mru> cartman: oh, you said decoder
[21:01:09] <mru> it's swell
[21:01:16] <cartman> yeah
[21:01:19] <saintd3v> mru: i missed it also
[21:01:22] <cartman> good to hear :D
[21:01:29] <mru> ffaacing awesome
[21:01:47] * cartman got his cant-sync-video-yet-and-no-audio decoder working on Mac
[21:01:48] <cartman> :D
[21:02:01] <saintd3v> cartman: yes the decoder is faster than faad, and also supports PS and SBR thanks to peloverde
[21:02:18] <cartman> saintd3v: oh nice to hear :)
[21:02:39] <saintd3v> i think it supports Main profile also, but nobody uses that
[21:02:58] <peloverde> hulu does sometimes
[21:03:17] <saintd3v> o.O
[21:03:18] <peloverde> http://samples.mplayerhq.hu/A-codecs/AAC/hulu-aac-main.flv
[21:03:45] <cartman> peloverde: anything iTunes can do but ffmpeg can't ? decoding wise
[21:04:02] <peloverde> I don't know what iTunes can do
[21:04:25] <cartman> thats interesting ;)
[21:04:35] <saintd3v> i wonder if itunes can even decode main, or if it's LC/HE only?
[21:04:40] <peloverde> my guess would be no
[21:04:49] <peloverde> it might do main
[21:05:52] * cartman does a grep die_license_disabled configure
[21:05:54] <peloverde> adobe flash does main
[21:06:02] <cartman> hooray, LGPL only misses AMR decoding
[21:10:38] <CIA-92> ffmpeg: jbr * r24632 /trunk/libavcodec/flacenc.c: Simplify verbatim mode fallback by checking the frame size before writing.
[21:14:08] <CIA-92> ffmpeg: jbr * r24632 /trunk/libavcodec/flacenc.c: Simplify verbatim mode fallback by checking the frame size before writing.
[21:14:09] <CIA-92> ffmpeg: siretart * r24633 /branches/0.6/Changelog: update changelog for upcoming 0.6.1 point release
[21:14:53] <CIA-92> ffmpeg: jbr * r24634 /trunk/libavcodec/flacenc.c: cosmetics: rename output_* to write_*
[21:15:21] <siretart> anything else to add for 0.6.1?
[21:17:54] <cartman> opencore license is not GPL, why would ffmpeg require GPL for it?
[21:18:23] <mru> it is apache which isn't compatible with lgpl
[21:19:43] <cartman> mru: argh
[21:20:14] <siretart> cartman: the resulting libavcodec.so would be redistributable under GPLv3 only. So you cannot distribute GPLv2 only applications against such a combination
[21:20:47] <cartman> siretart: true and GPLv3 means no commercial linking
[21:20:48] <kierank> who wrote amr?
[21:20:57] <kierank> s/amr/opencore-amr
[21:21:04] <cartman> PacketVideo guys
[21:21:09] <cartman> seems to be be acquired by Google
[21:21:20] <cartman> for Android
[21:21:24] <kierank> oh them
[21:24:15] <cartman> I hate licensing crap :)
[21:24:24] <mru> everybody does
[21:24:27] <mru> except rms
[21:24:51] <j0sh> jenk, i keep getting 405s after ANNOUNCE
[21:25:07] <jenk> okay
[21:25:11] <jenk> what if you restart it?
[21:25:15] <jenk> maybe its not unmounting properly
[21:25:33] <j0sh> same
[21:25:42] <jenk> that is odd
[21:26:24] <jenk> are you sure you are announcing to the right port?
[21:26:31] <jenk> the source port not the client port
[21:26:37] <j0sh> 554
[21:26:44] <jenk> 554 is for streaming clients
[21:27:00] <jenk> you need to ANNOUNCE to 5545
[21:27:36] <j0sh> that worked, thanks
[21:27:55] <jenk> np, let me know how it goes
[21:27:59] <jenk> i want to get it more stable
[21:42:20] <bcoudurier> hi guys
[21:56:26] <CIA-92> ffmpeg: siretart * r24635 /branches/0.6/RELEASE: update release notes for the upcoming 0.6.1 point release
[21:57:05] <CIA-92> ffmpeg: siretart * r24636 /branches/0.6/Changelog: clarify addition of VP80 fourcc code
[22:03:24] <j0sh> jenk, how did you test? ffplay/ffmpeg/etc can't open the stream, and i get a gray screen with vlc
[22:03:38] <jenk> i was testing with vlc and i could see some video
[22:03:47] <j0sh> hmm
[22:03:53] <jenk> but it had lots of PTS errors
[22:04:04] <jenk> i want to figure out why
[22:05:48] <jenk> it mostly works though
[22:05:58] <BBB> j0sh: want to work on adding rtp support for latm/mpeg4aac?
[22:06:34] <j0sh> latm?
[22:08:24] <j0sh> a quick googling (most of which are ffmpeg hits) show it's an aac variant with some special syntax
[22:08:56] <kierank> we're going to have 2 latm demuxers?
[22:10:40] <BBB> no, this is rtp
[22:10:52] <BBB> j0sh: yeah, it's a cracked-up version of aac
[22:11:47] <j0sh> BBB, any docs for latm in rtp? might just need to tweak the existing aac rtp code a bit
[22:12:19] <BBB> there's a rfc
[22:12:44] <BBB> http://www.rfc-editor.org/rfc/rfc3016.txt
[22:13:11] <j0sh> alright cool i'l read through it
[22:14:19] <kierank> if latm is latm the demuxer should be shared, no?
[22:15:50] <wbs> you can link with opencore-amr under LGPLv3 too (afaik), not only GPLv3
[22:15:59] <wbs> it's v2 vs v3, not GPL vs LGPL
[22:16:36] <CIA-92> libswscale: ramiro * r31879 /trunk/libswscale/swscale-test.c: swscale-test: merge declaration and initialization
[22:16:51] <CIA-92> ffmpeg: banan * r24637 /trunk/libavcodec/dca.c:
[22:16:51] <CIA-92> ffmpeg: dca: fix dynrange coefficient in xch
[22:16:51] <CIA-92> ffmpeg: Patch by Nick Brereton
[22:16:58] <BBB> j0sh: btw discuss with martin/luca a little and make sure they're ok with this
[22:17:48] <wbs> regarding latm/aac in rtp... I don't know it enough to say whether it's just a minor 1 hour thing to fix, or if it's majorly complicated and needs to share code with the generic latm demuxer
[22:18:03] <BBB> didn't I paste a link a few days ago?
[22:18:06] <wbs> since it probably just is one single aac stream it may be a bit simpler, but I don't know
[22:18:08] <BBB> apple uses it, hence my interest
[22:18:14] <BBB> (quicktime streaming server, that is)
[22:18:39] <wbs> most quicktime/aac/rtp samples I've seen haven't been latm, but it does support/use that, too
[22:19:05] <wbs> j0sh: but in general, feel free to have a look at it, but if it seems complicated, I'd rather say we'd wait for the general latm support and reuse parts from that
[22:19:43] <j0sh> i'm confused, what does latm demuxing have anything to do with rtp
[22:19:52] <j0sh> or is it not finished yet?
[22:20:00] <wbs> yes, it isn't finished yet, janneg is working on it
[22:20:10] <BBB> rtsp://qt-ar.as34763.net/ar32.sdp
[22:20:11] <wbs> and latm in general is a container format that can contain one or more aac streams, afaik
[22:20:13] <j0sh> ah gotcha
[22:20:26] <wbs> so if we'd support it fully in general, it may be a bit trickier than it sounds
[22:21:24] <wbs> anyway, I'm off to bed now, talk to you later
[22:22:19] <BBB> bye
[22:23:03] <j0sh> alright
[22:23:06] <j0sh> 'night
[22:24:12] <BBB> you can always clean up my very messy x-pn-wmt patch :-p
[22:24:20] <BBB> that's about the ugliest hack I've ever done
[22:24:26] <BBB> I'm surprised it doesn't crash in random places
[22:24:49] <BBB> j0sh: what are you currently working on?
[22:24:59] <BBB> have you tested vp8 against gst or something?
[22:26:07] <peloverde> janneg said he almost done with the LATM demuxer, that may be helpful
[22:26:24] <peloverde> sorry, wbs already mentioned it
[22:26:50] <peloverde> BBB: if you do plan on doing x264-vp8, I'd be glad to help
[22:27:08] <BBB> omg everyone knows already
[22:27:09] <BBB> :-p
[22:28:28] <j0sh> BBB, still trying to figure out where those phantom packets in vp8 are coming from
[22:28:38] <peloverde> well you've been talking about it for a few days now :)
[22:29:01] <j0sh> haven't tested against gst yet
[22:29:48] <BBB> j0sh: ok... let me know if you get stuck (or let martin/luca know) and we'll try to help more actively
[22:30:05] <BBB> peloverde: I'll probably start next week, I'm waiting for my new laptop to arrive
[22:30:14] <BBB> my old one is going to die in my hands right here
[22:30:14] <BBB> I'm waiting for it to die
[22:30:19] <peloverde> ok
[22:30:21] <BBB> it makes weird noises
[22:30:21] <BBB> cracks etc.
[22:30:35] <peloverde> Also, great work so far j0sh
[22:31:38] * BBB agrees
[22:31:57] <BBB> especially the http tunneling was a long-missed feature
[22:31:59] <BBB> but
[22:32:02] <j0sh> thanks
[22:32:15] <BBB>  any depacketizer brings us closer to vlc-adoption ;)
[22:32:29] <j0sh> speaking of which, i still need to clean up my vlc patch
[22:32:49] <j0sh> is there interest in mplayer integration also?
[22:33:01] <merbanan> BBB: vp8 vs x264 comparison ?
[22:33:22] <BBB> merbanan: no
[22:33:32] <BBB> merbanan: integrate vp8 bit stream output support in x264
[22:33:38] <BBB> (and then compare and conquer)
[22:34:06] <merbanan> lol
[22:34:20] <merbanan> that is friggin awesome
[22:47:15] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/Z6F5E79e
[22:47:21] <BBB> Dark_Shikari: word-writing in simple filter, quite a bit faster
[22:47:28] <BBB> especially on sse4
[23:08:48] <BBB> it's amazing that pextrd is slower than movd+psrldq...
[23:08:57] <BBB> who would've though
[23:14:12] <CIA-92> ffmpeg: rbultje * r24638 /trunk/libavcodec/x86/ (vp8dsp.asm vp8dsp-init.c):
[23:14:12] <CIA-92> ffmpeg: Use word-writing instead of dword-writing (with two cached but otherwise
[23:14:12] <CIA-92> ffmpeg: unchanged bytes) in the horizontal simple loopfilter. This makes the filter
[23:14:12] <CIA-92> ffmpeg: quite a bit faster in itself (~30 cycles less on Core1), probably mostly
[23:14:12] <CIA-92> ffmpeg: because we don't need a complex 4x4 transpose, but only a simple byte
[23:14:13] <CIA-92> ffmpeg: interleave. Also allows using pextrw on SSE4, which speeds up even more
[23:14:14] <CIA-92> ffmpeg: (e.g. 25% faster on Core i7).
[23:15:57] <BBB> Dark_Shikari: can you look at http://ffmpeg.pastebin.com/fvNCcjR5 and tell me why you think it's slower? it's less instructions, should be faster (on sse4), but it's not :(
[23:36:09] <_skal_paris_> BBB: hmm.. vp8.c:826 token_prob = probs[vp8_coeff_band[++i]][0]
[23:36:26] <_skal_paris_> BBB: i think you're accessing vp8_coeff_band[16] when i==16
[23:37:12] <peloverde> siretart: libswscale-dev from motumedia ppa on lucid does not seem to be installable
[23:37:34] * _skal_paris_ <- yawn. tired. sleep.
[23:39:31] <peloverde> It seems to depend on libswscale-extra-1 which doesn't exist