[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> +@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-f5653acbc04f21d22eaa6b... [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