[Ffmpeg-devel-irc] ffmpeg-devel.log.20130610

burek burek021 at gmail.com
Tue Jun 11 02:05:02 CEST 2013


[00:39] <durandal_1707> got almost working wavpack encoder
[02:54] <ubitux> http://boallen.com/assets/images/randbitmap_computer.png  php rand() 
[02:54] <ubitux> i hope the prng in our noise filter is not as bad :)
[02:56] <durandal_1707> it _is_ bad
[02:58] <ubitux> :)
[03:03] <cone-266> ffmpeg.git 03Michael Niedermayer 07master:b04bbe6b8695: swresample/rematrix_template: Fix integer overflow in mix6to2
[03:03] <cone-266> ffmpeg.git 03Michael Niedermayer 07master:d62030ffcaf1: swresample/rematrix_template: Fix integer overflow in mix8to2
[03:12] <Compn> durandal_1707 : what other languages do you speak ?
[03:27] <durandal_1707> Compn: klingonian, pfhor, sph't and c
[03:41] <cone-266> ffmpeg.git 03Michael Niedermayer 07master:0047da071ed1: swscale/swscale_unscaled: add ()
[03:48] <Compn> ehe
[05:29] <BBB> smarter: ping?
[10:32] <cone-595> ffmpeg.git 03Stephen Hutchinson 07master:8ed6c13fe3d7: libutvideo: Add ULH0 and ULH2 decoding when using version 13.0.1
[10:32] <cone-595> ffmpeg.git 03Stephen Hutchinson 07master:3f54547709c2: utvideo: Add ULH0 and ULH2 decoding to the native decoder.
[10:38] <j-b> good morning
[10:39] <av500> j-b: bonjour
[10:39] <cone-595> ffmpeg.git 03Yusuke Nakamura 07master:b441fdeb1557: utvideodec: Support ULH0 and ULH2 formats.
[10:39] <cone-595> ffmpeg.git 03Yusuke Nakamura 07master:2578f1efd64f: riff: Support ULH0 and ULH2 fourccs.
[10:39] <cone-595> ffmpeg.git 03Michael Niedermayer 07master:42b8296f3637: Merge commit '2578f1efd64f4efc30114c328d1eff9030429e59'
[10:41] <michaelni> j-b, average morning
[10:44] <saste> ubitux: what's going on with spp?
[10:47] <cone-595> ffmpeg.git 03Yusuke Nakamura 07master:252ee3d39b89: utvideodec: Set colorspace by codec_tag.
[10:47] <cone-595> ffmpeg.git 03Michael Niedermayer 07master:990860736328: Merge remote-tracking branch 'qatar/master'
[12:38] <smarter> BBB: pong
[13:13] <ubitux> saste: what do you mean what's going on?
[13:13] <saste> ubitux, i mean if there is any progress
[13:14] <ubitux> isn't it done? :)
[13:14] <ubitux> i will take some time to honor your review but it should not take a long time
[13:15] <ubitux> i'm mostly waiting for review from michaelni typically, since he's the author of the filter, and seems to be a user as well :)
[13:15] <saste> ubitux, ok
[13:26] <microchip_> ubitux: when can we expect spp ?
[13:27] Action: microchip_ needs it to deblock shitty youtube vids
[13:27] <ubitux> feel free to try it out and raise problems so it can be upstreamed faster
[13:27] <microchip_> ok
[13:28] <ubitux> microchip_: also, it seems people wants some comparison with the other pp filters, so that would be extremely welcome
[13:29] <microchip_> ubitux: yeah i read it on ML. I don't have much experience with the other deblockers
[13:29] <microchip_> but i can test :)
[13:29] <saste> microchip_, what's the problem with mp=spp?
[13:30] <microchip_> saste: nothing, just like a native implementation :)
[13:30] <saste> it is a port, the filter is already available by using mp=spp
[13:30] <ubitux> saste: native doesn't have qp from codecs
[13:42] <ubitux> saste: sorry, mp=spp doesn't have qp from codecs
[13:42] <ubitux> spp does
[14:54] <Paranoialmaniac> michaelni: utvideo doesn't consider color primaries. only matrix coefficients
[16:12] <cone-511> ffmpeg.git 03Michael Niedermayer 07master:e473f7e6595d: (lib)utvideodec: remove setting of color_primaries
[16:12] <michaelni> Paranoialmaniac, fixed, thanks!
[16:23] <Paranoialmaniac> lol @ the commit message > Thanks-to: Paranoialmaniac  I'm already in a past commit as MP4_maniac
[16:27] <cone-511> ffmpeg.git 03Carl Eugen Hoyos 07master:e9df8f7725cf: Accept incomplete http cookies without domain.
[16:27] <cone-511> ffmpeg.git 03Michael Niedermayer 07master:d5caf10c4f09: Merge remote-tracking branch 'cehoyos/master'
[16:49] <iive> Paranoialmaniac: register a nick and use it consistently :P
[16:51] <Daemon404> or just credit him with his real name
[16:51] <Daemon404> as he's in teh git history under that
[17:41] <cone-511> ffmpeg.git 03Michael Niedermayer 07master:8e887ca1fe6c: jpeg2000dec: Check bpno in decode_cblk()
[22:07] <cone-511> ffmpeg.git 03Michael Niedermayer 07master:d3e89f2641ba: vf_sab: Fix memleak
[23:02] <Daemon404> er
[23:02] <Daemon404> michaelni / someone
[23:02] <Daemon404> is it expected that the cfr vsync algo will produce different results rocess with whole file vs file in 3 chunks
[23:02] <Daemon404> the total # of dropped frames ends up different
[23:17] <Compn> Daemon404 : with only one thread ?
[23:17] <Compn> is multiple threads binary identical ?  i never remember...
[23:17] <Daemon404> ... teh vsync algo is not multithreaded
[23:17] <Daemon404> afaik
[23:17] <michaelni> Daemon404, i would expect that it can give different results, with different starttime
[23:18] <Compn> well i mean decoder / encoder threads might be mixing 
[23:18] <Daemon404> michaelni, there's no sane way to chunk it up then
[23:18] <Daemon404> i assume
[23:18] <Daemon404> ?
[23:18] <Compn> split up a job and have it be binary identical, you mean
[23:18] <Daemon404> yes
[23:19] <Daemon404> farmes 1-N, N+1-end
[23:19] <Daemon404> for exable
[23:19] <Daemon404> er example
[23:19] <Daemon404> TYPOS AHOY
[23:19] <michaelni> the CFR code could likely be modified to behave nicer to such use case
[23:20] <Daemon404> michaelni, i dont want to introduce unnecessary hacks/complexity
[23:20] <Daemon404> to satisfy such an eccentric use case
[23:29] <BBB-work_> smarter, pokey
[23:30] <smarter>  hi BBB-work_
[23:30] <BBB-work_> hah
[00:00] --- Tue Jun 11 2013


More information about the Ffmpeg-devel-irc mailing list