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

[burek]

[00:57] <ubitux> BBB: rounding with pmulhrsw done, working on eob
[00:57] <BBB> cool
[00:57] <ubitux> i'll probably go to sleep soon though
[00:57] <BBB> ok
[00:57] <BBB> you understand the eob thing is not for the memset, but for the actual whole idct, right?
[00:57] <ubitux> yeah sure
[00:57] <BBB> ok
[00:58] <ubitux> speaking of this
[00:58] <BBB> just to be sure ;)
[00:58] <ubitux> is there some other behaviour about that memset?
[00:58] <ubitux> i mean, is there other special cases or checking for eob for the memset is enough?
[01:00] <ubitux> i think i'll go to sleep.
[01:00] <BBB> checking for eob should be enough
[01:00] <ubitux> ok
[01:00] <BBB> (for smaller memsets)
[01:00] <BBB> e.g. if eob == 1, movd [block], zeroreg is enough
[01:00] <BBB> if eob <= 3, movd [block], zeroreg and movd [block+idctsize*2], zeroreg is enough
[01:00] <BBB> etc.
[01:01] <ubitux> is libvpx doing those optim?
[01:07] <BBB> ubitux: to a lesser extend, I think
[01:07] <BBB> ubitux: you can check, I believe they do dc-only and full 4x4
[01:07] <BBB> they don't do a half 4x4
[01:08] <ubitux> ok
[01:08] <BBB> I don't know if it's worth it, maybe I'm stupid and it isn't
[01:08] <ubitux> btw, just made the "(a*x + b*y + round) >> shift
[01:08] <BBB> but when I measured it, it was a situation that happened relatively often
[01:08] <ubitux> ..." macro
[01:08] <BBB> ah good
[01:08] <ubitux> 2x at once
[01:08] <BBB> I'll compare it to mine ;)
[01:08] <BBB> mine does 2x also :-p
[01:08] <ubitux> it was previously doing only one
[01:09] <ubitux> but i'm guessing it can be faster with the // ?
[01:09] <ubitux> anyway, it's still in https://github.com/ubitux/FFmpeg/compare/vp9-asm
[01:10] <BBB> / is c/c++/java only
[01:10] <BBB> //
[01:10] <BBB> but for assembly, ; may help, right
[01:11] <ubitux> ._.
[01:11] <ubitux> i mean in parallel
[01:11] <ubitux> :p
[01:11] <ubitux> my brain is off, i don't get jokes anymore
[01:12] <BBB> no you're right this is faster
[01:12] <BBB> it decreases latency effect
[01:12] <BBB> loren/jason usually refer to it as "pairing"
[01:12] <ubitux> ok :)
[01:13] <BBB> rest looks good, nice work... some stuff can be improved later for use in 8x8 or avx or xmm or whatnot, but this is a good start
[01:14] <ubitux> i'm undecided about the macro
[01:14] <ubitux> so it's inconsistent right now :p
[01:14] <BBB> line 133-134 movd, not movq
[01:14] <ubitux> ah, right
[01:15] <ubitux> semantic of "mova" is "movq aligned"? (i'm using it for registers)
[01:15] <BBB> sort of
[01:15] <ubitux> (it seems to generate a movq anyway)
[01:15] <BBB> mova = movq for mmx
[01:15] <BBB> mova = movdqa doe xmm
[01:15] <BBB> doe=for
[01:15] <BBB> mova is one of those macro things to share code between xmm/mmx/ymm
[01:15] <BBB> e.g. VP9_MULSUMSUB
[01:16] <BBB> but it's ok for now, I wouldn't worry too much about it
[01:16] <ubitux> ok
[01:16] <BBB> if it works, it's fine, and we'll update it as we work on it for 8x8/16x16/32x32/etc
[01:17] <BBB> right now it's mmx only so it's ok
[01:17] <ubitux> it seems to work yes
[01:17] <ubitux> :p
[01:17] <BBB> I mean there's some other things also, like constants being mmx-sized and aligned (instead of xmm), naming being slightly generic ("round", "t2" and "t3") but that's all fine, we can modify that later
[01:17] <BBB> pw_2048 is better than pd_round already
[01:18] <BBB> I care mostly that the code works, esp. for assembly
[01:18] <BBB> and this works
[01:18] <BBB> so it's fine
[01:18] <BBB> the vp8 code wasn't perfect either
[01:18] <BBB> but it was quite good
[01:19] <ubitux> i'll write the eob case and send for review
[01:19] <ubitux> or maybe you want to wait for the whole code at once?
[01:41] <BBB> ubitux: up to you, either way is fine (because either way it'll be a speedup)
[02:34] <cone-769> ffmpeg.git 03Michael Niedermayer 07master:f3d0642d35fa: avutil/utils: check that size_t is unsigned
[02:34] <cone-769> ffmpeg.git 03Michael Niedermayer 07master:1e5271a9fd6d: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[09:22] <cone-911> ffmpeg.git 03Stefano Sabatini 07master:d61617a52349: lavu/parseutils: add av_get_known_color_name()
[09:22] <cone-911> ffmpeg.git 03Stefano Sabatini 07master:4e268285aaff: cmdutils: add -colors option
[10:01] <cone-911> ffmpeg.git 03Anton Khirnov 07master:346e09638cc1: avcodec/error_resilience check error_concealment, not err_recognition.
[10:01] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:3b56f665b1cd: avcodec/flacdec: also do crc check when er compliant is set
[10:29] <cone-911> ffmpeg.git 03Guillaume Martres 07master:7b0f61a93604: FATE: update HEVC tests
[11:18] <michaelni> mraulet, smarter, should i update hevc* to the latest patch from anton?
[11:18] <michaelni> it seems anton didnt include all changes from openhevc/hevc_upstream
[11:19] <mraulet> I have to
[11:19] <mraulet> I am checking the sequences with one patch
[11:19] <mraulet> it seems to not fail
[11:19] <mraulet> the bugs on trac
[11:21] <michaelni> ok so i will wait for you to update openhevc/hevc_upstream and then cherry pick all new changes from there
[11:21] <michaelni> thanks!
[11:21] <mraulet> opnhevc/ffmpeg/master
[11:21] <mraulet> *openhevc
[11:22] <mraulet> when is the release?
[11:25] <michaelni> i was considering to do it today but i still need to test a few things and if there are issues it could be delayed 
[11:26] <michaelni> today night at the earliest
[11:26] <michaelni> if some issues than could be in a few days
[11:31] <michaelni> also i can wait if you / hevc needs more time 
[11:45] <cone-911> ffmpeg.git 03Anton Khirnov 07master:83d96e9a19ba: Changelog: add entry for HEVC support.
[11:45] <cone-911> ffmpeg.git 03Yusuke Nakamura 07master:f7f88018393b: hevc: Search start code in decode_nal_units().
[11:45] <cone-911> ffmpeg.git 03Yusuke Nakamura 07master:afa93d198aaf: hevc_parser: Set pict_type, key_frame and output_picture_number.
[11:45] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:10386710fd8e: Merge commit 'afa93d198aaf2cc661c4df6d4095cd030265d30a'
[12:08] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:09ef98f1ae3c: avcodec/hevcpred_template: Fix integer overflows
[12:18] <cone-911> ffmpeg.git 03Timothy Gu 07master:21f22908c6ae: MAINTAINERS: add my name for Launchpad
[12:27] <ubitux> BBB: eob seems to never be 0
[12:27] <ubitux> also, it seems to be relatively high sometimes
[12:27] <ubitux> last, it seems some completely zero blocks have eob != 1
[12:27] <ubitux> is all of this expected?
[12:34] <ubitux> http://lists.libav.org/pipermail/libav-devel/2013-October/052388.html "refactor the code" :')
[12:36] <nevcairiel> thats the new name for mixing cosmetics and functional changes
[12:37] <ubitux> K&R isn't hype anymore
[12:43] <ubitux> and again, those random line breaks make the code completely unreadable
[12:43] <ubitux> i still didn't find were are the functionnal changes after staring at the diff for 5 minutes
[12:44] <ubitux> but well, 2.7k lines of diff.
[12:44] <ubitux> well, it's certainly just a joke
[12:44] Action: ubitux moves on
[12:45] <cone-911> ffmpeg.git 03Stefano Sabatini 07master:d3aa04b1500f: doc/protocols/rtp: apply misc fixes
[12:46] <ubitux> BBB: anyway, i find this a bit curious: http://pastie.org/8434352
[13:02] <cone-911> ffmpeg.git 03Timothy Gu 07master:43041a7b4aa2: doc/encoders: add libshine doc
[13:09] <saste> ubitux, how's going the web job?
[13:12] <saste> do we have the equivalent of splitplanes/components?
[13:12] <ubitux> not started, scheduled for end of next month
[13:12] <saste> ubitux, ok
[13:12] <kierank> nevcairiel: 80 chars is pointless
[13:12] <saste> i'll probably add a goodies section if i find the right inspiration
[13:13] <ubitux> hehe
[13:13] <BBB> ubitux: what is a complete zero block?
[13:13] <saste> ubitux, PHP or JS is fine?
[13:13] <saste> uh my grammar is particularly bad today
[13:13] <ubitux> BBB: see the pastie; block[0..16] = 0x0000
[13:14] <ubitux> saste: i think it will just be static 
[13:14] <BBB> how do you print them?
[13:14] <saste> ubitux, boring :(
[13:15] <ubitux> BBB: http://pastie.org/8434401
[13:15] <ubitux> on etv.webm
[13:15] <saste> git co -b lavfi-reconfiguration
[13:15] <saste> let's see if i manage to do something about that...
[13:15] <ubitux> saste: yay :)
[13:16] <BBB> ubitux: what clip?
[13:16] <ubitux> etv.webm
[13:16] <ubitux> do you still have it
[13:16] <ubitux> ?
[13:16] <BBB> etv?
[13:16] <BBB> not sure...
[13:16] <BBB> weird
[13:16] <BBB> I don't think that should happen
[13:16] <ubitux> enter the void
[13:17] <ubitux> the 1080p sample i sent you a while ago
[13:17] <BBB> hm...
[13:17] <BBB> right
[13:17] <ubitux> which i generated with your libvpx example
[13:17] <BBB> ok so it shouldn't happen
[13:17] <BBB> not sure why it does
[13:21] <ubitux> BBB: http://lucy.pkh.me/samples/vp9/
[13:22] <BBB> ty
[13:22] <BBB> still not sure how that could happen
[13:23] <ubitux> bug/inefficiency in the encoder?
[13:26] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:0aba920d617d: avcodec/tiff: Fix use of uninitialized off variable
[13:26] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:d5ad4e4a2f12: avcodec/tiff: remove TIFF_LONG special case
[13:26] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:46143d255589: avcodec/tiff: factorize offset init code
[13:27] <saste> who remembers why we don't have AVFilterLink.type?
[13:28] <BBB> ubitux: no, you can not encode an eob without a non-zero coeff before it
[13:28] <BBB> ubitux: so this is physically impossible :-)
[13:28] <BBB> ubitux: so I'm very curious what's going on
[13:29] <BBB> ubitux: it's certainly possible to code 16 zeros, but eob is halfway the block so that's not what's going on either
[13:29] <BBB> or maybe the eob value is broken...
[13:29] <BBB> it worked for 32x32 though
[13:38] <ubitux> saste: so, what's this @xref{} ?
[13:38] <ubitux> (cross reference?)
[13:38] <saste> ubitux, where?
[13:39] <ubitux> the patch you just applied
[13:39] <ubitux> + at xref{libshine} for a fixed-point MP3 encoder, although with a lower quality.
[13:40] <saste> it should be @ref
[13:52] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:7eda2e524b8e: avcodec/vc1_parser: check ff_vc1_parse_frame_header*() return value
[13:52] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:2c7c2a53b942: vcodec/vc1dec: remove dead code
[13:59] <BBB> oh I think I got it
[13:59] <BBB> funny
[14:01] <BBB> ubitux: nice bug
[14:01] <BBB> ubitux: (my bug, not yours)
[14:01] <ubitux> maybe we should have some code in the C reference to use that eob
[14:08] <BBB> ok fixed
[14:09] <BBB> ubitux: maybe... I'd rather just write fast simd and ignore the c
[14:09] <BBB> anyway, bug fixed
[14:09] <BBB> will send a patch
[14:13] <BBB> patch sent
[14:16] <wm4> what's the policy for API additions in ffmpeg?
[14:17] <kierank> wm4: you can do it if libav doesn't have it
[14:17] <kierank> </troll>
[14:19] <ubitux> BBB: yeah but when writing simd it's cool to have a reference; imagine someone wants to write arm simd, it might be better to use C as reference than intel one
[14:26] <ubitux> BBB: and so, why the eob has "invalid" value when skip is defined? it's the previous block decode value?
[14:31] <BBB> ubitux: right, it's not written to if skip=1
[14:31] <ubitux> BBB: can you push?
[14:33] <BBB> to where?
[14:34] <ubitux> upstream?
[14:34] <BBB> I don't know if my ssh key still works, I generally let michael push, much easier
[14:35] <michaelni> you key should work but if you prefer i can push, i just need to know what to push
[14:35] <michaelni> youR
[14:49] <ubitux> [FFmpeg-devel] [PATCH] vp9: skip itxfm_add if the whole block has no coefficients.
[14:49] <ubitux> this one ^
[14:52] <ubitux> BBB: what about changing the code in inter_reconn as well?
[14:58] <ubitux> michaelni: maybe too fast :p
[15:01] <BBB> ubitux: not necessary
[15:01] <BBB> ubitux: the whole block is under if (!b->skip)
[15:01] <BBB> ubitux: you wrote it :)
[15:01] <ubitux> ah :))
[15:03] <cone-911> ffmpeg.git 03Benedict Endemann 07master:696aa74b1ab3: lavfi/overlay: correct small error in intersection detection
[15:07] <saste> ubitux, what's the problem with xref?
[15:08] <cone-911> ffmpeg.git 03Ronald S. Bultje 07master:cd86eb265f36: avcodec/x86/videodsp: fix a bug in a %if statement where we used '%%' instead of '&&'.
[15:08] <cone-911> ffmpeg.git 03Ronald S. Bultje 07master:960490c0b20d: avcodec/x86/videodsp: Small speedups in ff_emulated_edge_mc x86 SIMD.
[15:08] <cone-911> ffmpeg.git 03Ronald S. Bultje 07master:efc5a54cab8a: vp9: skip itxfm_add if the whole block has no coefficients.
[15:20] <ubitux> saste: i don't know, i'm wondering what it is
[15:29] <saste> ubitux, silly, texi2pod doesn't generate it
[15:30] <saste> that's why we removed them at some point
[15:32] <cone-911> ffmpeg.git 03Stefano Sabatini 07master:5b53dd0803ba: doc/encoders: replace @xref with @ref command
[15:33] <ubitux> memset(s->counts.coef, 0, sizeof(s->counts.coef) + sizeof(s->counts.eob));
[15:33] <ubitux> yay.
[15:33] <ubitux> :)
[15:34] <nevcairiel> i'm no expert, but that looks funky
[15:34] <BBB> that looks broken :)
[15:35] <BBB> I guess it works b/c eob is right after coef?
[15:35] <ubitux> yes
[15:35] <BBB> (not as guaranteed by the c standard; just b/c of luck)
[15:35] <BBB> yeah we should probably split that
[16:13] <ubitux> BBB: if eob=4, the 4th value could be anywhere in block[2, 5 or 8]?
[16:13] <ubitux> (zigzag placement always?)
[16:13] <BBB> see vp9_default_scan_4x4
[16:14] <BBB> 0,1,4,5
[16:14] <BBB> so apparently eob=4 is still ok
[16:14] <BBB> I didn't see that before
[16:15] <ubitux> it's always following that scan?
[16:15] <ubitux> i can't be in the situation where it's a col scan?
[16:15] <ubitux> the col scan will only happen with idct+iadst i suppose?
[16:16] <ubitux> col/row scale with idct+iadst/iadst+idct?
[16:16] <ubitux> scan*
[16:16] <ubitux> or that's totally unrelated?
[17:09] <BBB> ubitux: row/col scan is adst/dct or dct/adst
[17:09] <BBB> ubitux: dctx2 is always default scan
[17:10] <ubitux> ok
[17:10] <ubitux> i'm done with the dc only, i think
[17:10] <BBB> cool
[17:10] <BBB> will you do 2x2 also?
[17:11] <ubitux> probably
[17:25] <ubitux> BBB: is it ok to have multiple RET?
[17:26] <ubitux> or it's somehow doing macro magics?
[17:29] <ubitux> BBB: i pushed the dc-only one
[17:29] <ubitux> https://github.com/ubitux/FFmpeg/compare/vp9-asm#diff-f5653acbc04f21d22eaa6bfd4954e66eR157
[17:33] <BBB> multiple RET is fine
[17:34] <ubitux> ok
[17:34] <BBB> ubitux: having movq m1/2/3, m0 is kind of ugly; maybe have VP9_STORE take the input registers
[17:34] <ubitux> oh good idea
[17:34] <BBB> and movq            m0, [blockq] -> movd, not movq
[17:34] <ubitux> arh :D
[17:34] <BBB> or maybe pinsrw
[17:35] <BBB> movd is fine I think
[17:39] <BBB> oh it's pextrw, not pinsrw, anyway, movd is fine
[17:52] <ubitux> BBB: does "pairing" works with 4? :p
[17:52] <ubitux> or i should interleave 2 by 2?
[17:54] <BBB> I don't think 4 has any additional advantage over 2, usually
[17:55] <BBB> if you have enough registers, no reason to not do it
[17:55] <BBB> but it's totally up to you
[18:09] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:4307026243c0: avformat/utils: make "first_dts not matching first dts in the queue" message more informative
[18:09] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:d9bc251d3978: ffmpeg_filter: Fix non jpeg yuv in jpeg support
[18:17] <ubitux> BBB: m0 dup removed
[18:17] <ubitux> branch up-to-date
[18:17] <ubitux> looking at the 2x2 now
[18:20] <ubitux> so, <= 4?
[18:21] <ubitux> 0, 1, 4, 5 is the 2x2 top left block, should be good
[18:36] <BBB> ubitux: exactly
[18:40] <durandal_1707> michaelni: i assume maxsize in ffv1 enc is supposed to measure raw size of uncompressed video
[18:41] <durandal_1707> if that is true, calculation is not correct for many pixel formats
[18:42] <durandal_1707> i think there is/should be function from lavu that can calculate this
[18:56] <ubitux> BBB: will this 2x2 really time saving?
[18:56] <BBB> I think it should
[18:56] <BBB> most importantly because you can do pmulhrswx2 for each 1d idct, instead of pmulhrsw + the long vp9_pmulsumsub thingy
[18:57] <ubitux> mmh
[18:57] <ubitux> ok
[18:58] <BBB> it's not as much a win as dc-only, but that's because dc is a very special case
[18:58] <ubitux> we're gonna get a huge load of asm just for this 4x4
[18:58] <ubitux> i wonder how big the other are gonna be :))
[18:58] <BBB> check the binary size of x86/vp9dsp.o versus the c version
[18:58] <ubitux> also, i suppose we'll have to do the adst combination as well
[18:58] <BBB> (do it, for fun, in vp8)
[18:59] <ubitux> yeah, a bit smaller :)
[18:59] <ubitux> -rw-r--r-- 1 ubitux ubitux 34K Oct 27 18:59 libavcodec/vp8dsp.o
[18:59] <ubitux> -rw-r--r-- 1 ubitux ubitux 29K Oct 27 18:59 libavcodec/x86/vp8dsp.o
[18:59] <ubitux> (stripped)
[18:59] <BBB> my point is, it's not 10x as big
[18:59] <BBB> even though e have mmx, mmx2, sse2, ssse3, sse4
[18:59] <BBB> here, we only do ssse3
[18:59] <BBB> so it's fine
[19:00] <ubitux> yeah ok :)
[19:03] <ubitux> not sure i'll get done with 2x2 tonight
[19:03] <ubitux> :(
[19:58] <cone-911> ffmpeg.git 03Paul B Mahol 07master:292902ea9ff1: avfilter: add mergeplanes filter
[19:58] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.10:c08127c5e692: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.11:b89e5b138f01: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.7:1049328cf013: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.8:115efdefc5f4: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.9:b6f5a54fddeb: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/1.0:65daa390f87f: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/1.1:4c17e20ff05a: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/1.2:93d720b040bf: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/2.0:f51483491749: avformat/utils: do not override pts in h264 when they are provided from the demuxer
[20:07] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:2ef1e62c8dcf: correct the AVOption documentation for AV_EF_CAREFUL
[20:07] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:fc7be7ddf3de: avcodec/avcodec.h: Add documentation for the AV_EF_* defifines
[20:10] <ubitux> defifines
[20:10] <ubitux> is that cute defines?
[20:10] <durandal_1707> fail
[20:11] <ubitux> cool to see doc though :)
[20:11] Action: wm4 wonders when ffmpeg will fix its terrible build system
[20:11] <durandal_1707> with something like waf?
[20:11] <ubitux> :D
[20:11] <ubitux> wm4: still refering to the sdl?
[20:12] <ubitux> or something else?
[20:12] <nevcairiel> there are no good build systems :p
[20:12] <ubitux> btw, isn't the recently added rpath problematic after make install?
[20:13] <ubitux> like, leaking some random path in installed binaries
[20:13] <wm4> ubitux: if an update removes or adds a file, the build will mysteriously fail, unless you run make clean before
[20:13] <ubitux> ah the dependency thing
[20:14] <ubitux> i'm a bit annoyed about that thing yes
[20:14] <ubitux> wm4: for adding a file it's normal
[20:14] <ubitux> and you don't need to make clean
[20:14] <ubitux> when removing it's problematic
[20:14] <ubitux> because the file reference exists in the dependency files
[20:15] <wm4> anyway, "it randomly fails and after make clean it works"
[20:15] <ubitux> (and somehow they're not updated properly after a configure?)
[20:15] <cone-911> ffmpeg.git 03Derek Buitenhuis 07master:6ef30976e00a: timefilter: Handle memory allocation failure
[20:15] <cone-911> ffmpeg.git 03Derek Buitenhuis 07master:52aed19307ee: avfiltergraph: Properly handle memory allocation failure
[20:15] <cone-911> ffmpeg.git 03Derek Buitenhuis 07master:d206fd996bda: avio: Check for memory allocation failure of private data
[20:19] <wm4> amazing, 1e5271a9fd fixed some ever-broken ts samples
[20:48] <ubitux> BBB: afaict you can skip do the pmulhrsw x2 only for the first 1d idct
[20:48] <ubitux> because second one has values for the whole 2x4 values of the block
[20:49] <ubitux> oh mmh wait
[20:49] <ubitux> yeah sorry forget it you're right
[20:50] <ubitux> 'forgot the transpose :)
[20:54] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/2.0:1fa7ad2e20db: ffmpeg_filter: Fix non jpeg yuv in jpeg support
[20:58] <BBB> ubitux: lol :) indeed
[20:59] <ubitux> yeah well i hope to get done with this in a few days
[20:59] <BBB> ubitux: the gains for the larger (e.g. 16x16) are bigger
[20:59] <BBB> because imagine you're doing 8 coeffs per iteration
[20:59] <BBB> e.g. 8x16
[20:59] <BBB> that means you have to loop twice
[20:59] <BBB> per 1d
[20:59] <BBB> right?
[20:59] <BBB> if you do a 8x8 topleft only, you don't have to loop
[20:59] <BBB> you only do that one iteration
[21:00] <BBB> (that only goes for the first 1d, but still)
[21:00] <BBB> so more gains yay
[21:00] <ubitux> yeah ok :)
[21:00] <ubitux> gtg
[21:00] <ubitux> cya, and thx for the help :)
[21:01] <BBB> bye
[21:25] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:2886d6cbb71b: avcodec/takdec: also do crc check when er compliant is set
[21:25] <cone-911> ffmpeg.git 03Anton Khirnov 07master:c7027ce9eac0: avcodec/options_table: disable CRC checking by default
[21:25] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:b1348eb68b43: avcodec/options_table: set err_detect to careful by default
[21:29] <cone-911> ffmpeg.git 03Paul B Mahol 07master:75b2bbe21d93: libavfilter/vf_noise: relicense to LGPL
[22:10] <cone-911> ffmpeg.git 03Lukasz Marek 07master:e5b3b75669fc: lavd/pulse_audio_enc: fix timestamp calculation
[22:10] <cone-911> ffmpeg.git 03Lukasz Marek 07master:4fb3aa491b47: lavd:pulse_audio_enc: fix array compared against 0
[22:10] <cone-911> ffmpeg.git 03Lukasz Marek 07master:7f5e75eea940: lavd/pulse_audio_enc: more stream validation restrictive
[22:10] <cone-911> ffmpeg.git 03Lukasz Marek 07master:b04af34600d0: lavd/fbdev_enc: more stream validation restrictive
[22:36] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:e797bd9dc771: Revert "avcodec/options_table: set err_detect to careful by default"
[22:36] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:69d39cb90c24: Revert "avcodec/options_table: disable CRC checking by default"
[22:36] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:758b6d39f685: avcodec/hevc: calculate checksum only if AV_EF_EXPLODE is set
[22:52] <cone-911> ffmpeg.git 03Lukasz Marek 07master:b387a24cb4ad: lavd/fbdev_enc: remove unused variables
[23:14] <cone-911> ffmpeg.git 03Marton Balint 07master:dbe6f9f2c233: lavc: add support for CODEC_CAP_DELAY in subtitles
[00:00] --- Mon Oct 28 2013