[00:45] <durandal11707> michaelni: how complicated would be adding packed yuva444? (YUVAYUVAYUVA....) [00:46] <ubitux> llogan: fun idea, but don't ask me to do it [00:47] <ubitux> durandal11707: you can hardsub bitmap subs, there is hack in ffmpeg to inject bitmaps into frames for overlay iirc [00:47] <ubitux> it's even documented [00:47] <durandal11707> ubitux: nicolas already told me hours ago [00:48] <ubitux> time is a bitch [00:53] <durandal11707> haha [01:20] <BBB> ubitux: is uvpred done? [01:20] <ubitux> wasn't it already? [01:21] <BBB> you said you'd make a small adjustment (remove duplicae off_u/v and stride_u/v [01:21] <BBB> ) [01:21] <BBB> otherwise it's done yes [01:34] <ubitux> fuck [01:34] <ubitux> my [01:34] <ubitux> isp [01:34] <ubitux> BBB: what message from me did you get? [01:38] <ubitux> BBB: no changes from last time; the only differing thing is that i pass 2x the offset (and you said linesize[1]==linesize[2]) [01:38] <ubitux> but im not sure about those assumptions [01:38] <ubitux> i dont think that hurts currently [01:38] <michaelni> durandal11707, dunno, see comits that added other packed yuv formats [01:39] <durandal11707> michaelni: considering how planar is hard, packed is harder [01:47] <BBB> ubitux: yes, that, and off_uv being passed twice [01:48] <BBB> ubitux: off_u and off_v are always the same (and they are; y/uv can be different, but u and v are always the same) [01:48] <BBB> ubitux: but we can ignore if you feel strongly and then just take as-is so we can finish off (i.e. I'll enable inter frame fate tests and we can start working on simd/mt) [01:49] <BBB> ubitux: because I think we're finished feature-wise now [01:58] <durandal11707> saste: pushed that probe thing? [01:58] <BBB> member:ubitux: yes, that, and off_uv being passed twice [01:58] <BBB> member:ubitux: off_u and off_v are always the same (and they are; y/uv can be different, but u and v are always the same) [01:58] <BBB> member:ubitux: but we can ignore if you feel strongly and then just take as-is so we can finish off (i.e. I'll enable inter frame fate tests and we can start working on simd/mt) [01:58] <BBB> ubitux: because I think we're finished feature-wise now [01:58] <BBB> ubitux: c/p from a few minutes ago [01:59] <ubitux> i'm ok for off_[uv] [01:59] <BBB> ok, so let's leave the stride in-place, I'll cherry-pick and then enable fate tests [01:59] <BBB> ffvp9 done \o/ [02:01] <ubitux> not really for ref linesizes [02:01] <ubitux> will fix in a moment, if my isp allows me [02:01] <ubitux> BBB: done, pushed [02:01] <ubitux> BBB: btw, did you see the decode error with the sample i pasted? [02:03] <ubitux> done, and broken \o/ [02:03] <ubitux> BBB: try ./ffplay -noframedrop -ss 29 ~/out.webm [02:04] <BBB> omg [02:04] <ubitux> also, i don't know if it's a problem with the encode [02:05] <ubitux> but there are some kind of freezes [02:05] <BBB> can vpxdec decode it? [02:05] <ubitux> i didn't look at all :) [02:05] <ubitux> there are various issues with that sample [02:05] <ubitux> but it might be related to libvpx as well [02:05] <BBB> it seems to decode fine to me [02:06] <cone-912> ffmpeg.git 03Michael Niedermayer 07master:259292f9d484: avcodec/mpegvideo: Dont incorrectly warn about missing keyframes [02:06] <BBB> (w/o your patch) [02:06] <ubitux> huh? [02:08] <ubitux> that reminds me i need to open a ticket for the ffplay lag after a seek [02:09] <BBB> yes libvpx and ffmpeg produce same output to me [02:09] <BBB> ffplay has issues, tha may be a problem [02:09] <BBB> but ffmpeg works [02:09] <BBB> no idea what that means or anything [02:09] <ubitux> in ffplay between 30-40 sec i get a buggy output [02:10] <ubitux> crazy blocks all over [02:10] <ubitux> like a complete mess [02:10] <durandal11707> what if you use non-ffplay ? [02:11] <ubitux> it's the same [02:11] <ubitux> http://ubitux.fr/pub/pics/_ffpv9-ffplay-etv.jpg [02:11] <ubitux> reproducible with ffmpeg [02:13] <ubitux> ./ffmpeg -ss 29 -i ~/out.webm -y out.y4m && ./ffplay out.y4m [02:17] <ubitux> the decode with libvpx is ok [02:33] <ubitux> BBB: cant reproduce? [02:53] <BBB> ubitux: checking [02:53] <BBB> oh yes I can [02:54] <BBB> ok looks like an actual bug [02:54] <BBB> that's cool [02:54] <durandal11707> *not [02:55] <durandal11707> why whenever i type make: doc/fate.txt is 'rebuild'? [02:56] <ubitux> BBB: it happens again at the end btw [02:56] <ubitux> BBB: what do you want me to work on tomorrow? [02:56] <ubitux> "cleanups"? [02:56] <BBB> simd, mt, other optimizations? [02:56] <BBB> cleanups is fine also [02:56] <ubitux> well, it's the end of the month [02:57] <ubitux> i'm starting my new job on monday [02:57] <durandal11707> but is pure c bitexact? [02:57] <BBB> durandal11707: there's some small bugs, I'm working them out, but the dsp code is bitexact yes [02:57] <ubitux> i dont mind focusing on one or two mt function though [02:57] <BBB> mt isn't function, mt is the whole thing [02:57] <BBB> frame-mt, that is [02:57] <ubitux> i meant simd sorry [02:57] <BBB> if you look at ffvp8, it's quite trivial to see how to do it [02:57] <BBB> ok [02:57] <ubitux> brain is off [02:57] <BBB> :) [02:58] <ubitux> fuck it's 3 am [02:58] <ubitux> i need my 12 hours sleep [02:58] <BBB> ok [02:58] <BBB> gnite [02:58] <ubitux> 'nite [03:40] <durandal11707> filter that takes 699kb in source code [03:43] <durandal11707> and its nearest neighbor 2-4 scaler [05:29] <cone-253> ffmpeg.git 03Michael Niedermayer 07master:20b965a1a43a: avcodec/ffv1dec: check global header version [05:29] <cone-253> ffmpeg.git 03Michael Niedermayer 07master:547d690d6760: ffv1dec: check that global parameters dont change in version 0/1 [05:39] <BBB> ubitux: pushed your commit (sorry took a while) [07:00] <BBB> ubitux: and yes I can reproduce the issue now, will fix (fixed another minor issue also, causing some artifacts around the borders) [09:35] <kurosu_> BBB: how is that vp9 decoder going? feature complete, or you are avoiding implementing some kind of unusual tool? (ie do you know what is the spec coverage) [09:37] <BBB> kurosu_: mostly there, small bugs here and there, some related to odd implementation details in libvpx that I obviously have to follow [09:38] <BBB> kurosu_: I'm avoiding resolution changing support ATM, maybe will do that later, but for now that's not a priority [09:38] <BBB> kurosu_: then again I'm not 100% sure if that's part of profile 0 or not :) [09:38] <BBB> I believe it is [09:38] <BBB> kurosu_: and obviously no simd/mt/anything yet, so it's somewhat slow [09:39] <kurosu_> I didn't find the openhevc implementation terribly sexy; hopefully ffvp9 has a better start in that domain [09:40] <BBB> what's openhevc? [09:40] <BBB> is that "ffhevc"? [09:40] <kurosu_> resolution changing? ie, you code some frames at eg half resolution? reminds me of mpeg4 reduced resolution, although I'm not sure where it belongs [09:40] <kurosu_> BBB: yes [09:40] <BBB> https://github.com/rbultje/ffmpeg/tree/vp9 [09:40] <BBB> ubitux is also working on it [09:41] <kurosu_> afaik, they developped in on their own inside of that French stuff then are now trying to push it on libav [09:41] <BBB> I thought smarter wrote it? [09:43] <kurosu_> wasn't that only the start of it ? actually I'm maybe imagining things and I don't actually know the connection [09:43] <kurosu_> afaik there's a French consortium trying to promote hevc through an "open" development, [09:43] <kurosu_> https://github.com/OpenHEVC [09:44] <BBB> they probably work together [09:44] <kurosu_> mostly a French university doing that work iirc [09:44] <BBB> I don't know [09:44] <kurosu_> I haven't quite followed either [09:45] <kurosu_> probably you can ask smarter I guess :D [09:45] <kurosu_> (if you wanted to know, not that I'm asking that you ask) [11:25] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/2.0:c7ee4bc016e5: ffv1dec: check that global parameters dont change in version 0/1 [11:40] <cone-303> ffmpeg.git 03Timothy Gu 07master:40b8350b57ad: doc/encoders: reformat libmp3lame doc [11:40] <cone-303> ffmpeg.git 03Timothy Gu 07master:e45e72f5f89e: doc/encoders: reformat and add some clarification in libtwolame doc [11:57] <cone-303> ffmpeg.git 03Diego Biurrun 07master:a6b650118543: ppc: cosmetics: Consistently format CPU flag detection invocations [11:57] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:09c94b57ca2c: Merge commit 'a6b650118543e1580e872896d8976042b7c32d01' [11:57] <cone-303> ffmpeg.git 03Sean McGovern 07master:01a82f1dc544: ppc: don't return a value from a function declared void [12:01] <smarter> kurosu_: so, https://github.com/OpenHEVC/libav is the latest version of the hevc decoder, based on what I did during the gsoc last year, improved by me and others (mostly people from IETR-INSA) [12:06] <cone-303> ffmpeg.git 03Diego Biurrun 07master:79aec43ce813: x86: Add and use more convenience macros to check CPU extension availability [12:06] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:f0a35623826e: Merge commit '79aec43ce813a3e270743ca64fa3f31fa43df80b' [12:48] <cone-303> ffmpeg.git 03Diego Biurrun 07master:6369ba3c9cc7: x86: avcodec: Use convenience macros to check for CPU flags [12:48] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:8be0e2bd43d9: Merge commit '6369ba3c9cc74becfaad2a8882dff3dd3e7ae3c0' [12:48] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:c1913064e38c: avcodec/x86/vp8dsp: Fix cpu flag checks so they work [12:48] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:7fb758cd8ed0: avcodec/x86/lpc: Fix cpu flag checks so they work [12:54] <BBB> ubitux: fixed [12:57] <ubitux> cool :) [12:58] <cone-303> ffmpeg.git 03Diego Biurrun 07master:e998b56362c7: x86: avcodec: Consistently structure CPU extension initialization [12:58] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:62a6052974d8: Merge commit 'e998b56362c711701b3daa34e7b956e7126336f4' [12:59] <durandal_1707> michaelni: why you merged "convenience macros" if they do not work? [13:05] <michaelni> durandal_1707, why do you assume that they do not work ? [13:06] <durandal_1707> because i read 7fb758cd8ed08e4a37f10e25003953d13c68b8cd commit log [13:08] <michaelni> "avcodec/x86/lpc: Fix cpu flag checks so they work" Fixes the cpu flag checks in x86/lpc, how does that imply that the macors defined outside x86/lpc and used in several other places, dont work ? [13:09] <durandal_1707> it doesn't [13:09] <durandal_1707> but why it got broken... [13:10] <durandal_1707> they appars to work in some but not all cases... [13:21] <cone-303> ffmpeg.git 03Sean McGovern 07master:f1f728cbe4e8: ppc: don't return a value from a function declared void [13:21] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:05507348afa1: Merge remote-tracking branch 'qatar/master' [13:29] <durandal_1707> ubitux: were you serious about porting hqx filters? This code takes more than 10k lines of code. [13:30] <ubitux> i'm pretty sure it can be refactored in a few lines [13:31] <ubitux> maybe with a lut or two [13:31] <ubitux> someone raised a better one btw [13:31] <ubitux> a shader based, but cant remember the name [13:31] <ubitux> iirc another 2 letters filter unwebsearchable [13:31] <durandal_1707> shader one could only be faster [13:32] <ubitux> the algo was different [13:32] <durandal_1707> also there is algo that probably generated this nonsense, but where it is ... [13:35] <durandal_1707> about refactoring: switch takes most of lines, but i doubt i can refactor this... [13:35] <ubitux> it's a long work [13:36] <ubitux> durandal_1707: "xBR is better" [13:36] <durandal_1707> xBR ? [13:37] <durandal_1707> i think right solution is self generating code [13:37] <ubitux> like 5xBR [13:37] <durandal_1707> i got what 5x means... [13:38] <ubitux> https://github.com/libretro/common-shaders/tree/master/xbr [13:38] <ubitux> btw... https://github.com/libretro/common-shaders/blob/master/hqx/hq4x.cg [13:43] <durandal_1707> ok that is much less lines, but how(if possible at all) can i convert this to c? [13:46] <durandal_1707> well i dunno what half4 means [13:47] <durandal_1707> perhaps half is 16 bit float... [13:47] <nevcairiel> half4 is a 16-bit float, and a vector of 4 [13:47] <durandal_1707> nice [13:48] <nevcairiel> half4x4 would be a matrix [13:51] <durandal_1707> if i do this in pure c it would be extremly slow? [14:15] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:b05cd1ea7e45: ffv1dec: Check bits_per_raw_sample and colorspace for equality in ver 0/1 headers [14:33] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:4f5454d20130: avcodec/mpegvideo: reduce log level for messages about allocating frames. [14:45] <cone-303> ffmpeg.git 03Paul B Mahol 07master:48cd1037f661: cmdutils: silence warning about incompatible pointer types [15:04] <durandal_1707> michaelni: if you not gonna push license patch, i will [15:10] <michaelni> if someone pushes it, please ommit: [15:10] <michaelni> > - * Copyright (c) 2007 The Libav Project [15:10] <michaelni> > + * Copyright (c) 2007 The FFmpeg Project [15:10] <durandal_1707> ? [15:10] <michaelni> libavformat/network.c [15:11] <durandal_1707> why? [15:11] <michaelni> because you are not the copyright holder of the file ? [15:13] <durandal_1707> but for other files in that patch its also correct [15:13] <durandal_1707> and for others you changed when merging [15:14] <durandal_1707> so i'm very confused [15:16] <durandal_1707> or this was joke... [16:33] <cone-303> ffmpeg.git 03Carl Eugen Hoyos 07master:8fe1fb41ac28: Fix compilation with --disable-mmx. [16:54] <BBB> ubitux: ok all fate tests (without emu-edge) pass now [16:55] <BBB> ubitux: with emu-edge still some issues, these are relatively easy to fix, will do that later [16:55] <BBB> ubitux: simd/mt time now [17:16] <durandal_1707> michaelni: so you changed mind about license patch? [17:17] <michaelni> ? [17:18] <durandal_1707> read log [17:18] <durandal_1707> michaelni: stop playing games with me [17:27] <iive> michaelni: about networks.c, I don't think that libav project existed at 2007... [17:29] <michaelni> iive, you are probably correct, but it doesnt really make a difference does it ? i mean except for the entertainment value the contradiction has [17:30] <michaelni> durandal_1707, i read the log and i dont really know what you talk about. If its about the patch, i dint say that i will apply it nor did i say i wont, iam nt stoping you from applying it nor anyone else [17:33] <durandal_1707> well there is always revert [17:33] <iive> if I understand correctly, all "This file is part" are OK, as they are not part of the copyright notice. [17:34] <iive> i mean, this file is part of ffmpeg and libav... so it is true either way. [17:35] <durandal_1707> what about: "the ffmpeg project" vs "The FFmpeg Project" [17:35] Action: durandal_1707 have nothing better to do [17:37] <iive> as for network.c it should probably contain 2 copyright notices, 2007-2013 FFMpeg and whatever the first and last modification 2011-2013 libav. [17:37] <durandal_1707> its not FFMpeg but FFmpeg [17:38] <iive> of course it is [17:38] <durandal_1707> and really changing that each time someone refactor code is pita [17:39] <iive> Then 2007 FFmpeg, 2011 Libav ? [17:39] <durandal_1707> no way, i will commit what I have [17:40] <iive> having wrong copyright notice is indeed high amusement value, but in legal trouble it could turn into nightmare. [17:40] <iive> then... 2013 FFmpeg, 2013 Libav ? i guess you have merged stuff in it this year. [17:41] <iive> in/if [17:41] <durandal_1707> so i need to update this for every file in repo (except ffmpeg only code) [17:48] <iive> most of the files seem to have the copyright assigned to the person who wrote them. not to a project [17:49] <durandal_1707> yes, this patch just changes This file is part of .... [17:49] <durandal_1707> ... is free software; ... distributed in hope, etc... [17:50] <iive> yes, so no issue. as the discussion also seems to agree. [17:50] <iive> michael said he won't commit it, but he won't oppose it. If i got it right. and today i don't get a lot of things right. [17:51] <durandal_1707> you are not alone [17:55] <cone-303> ffmpeg.git 03Thilo Borgmann 07master:d814a839ac11: Reinstate proper FFmpeg license for all files. [18:51] <durandal_1707> michaelni: i guess adding support for yuva/gbr(a) to snow is now trivial? [19:50] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:7b47d7f75e6f: avcodec/pngdec: Fix padded alloc code with threads [19:50] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:60fed98e6347: avcodec/pngdec: fix last_row_size type [20:24] <cone-303> ffmpeg.git 03Paul B Mahol 07master:ea3ce0085921: wnv1: remove unused avctx from codec private context [20:24] <cone-303> ffmpeg.git 03Paul B Mahol 07master:057dce5f21cd: kgv1dec: make decoder independent of sizeof(AVFrame) [20:24] <cone-303> ffmpeg.git 03Paul B Mahol 07master:c04268447627: kgv1dec: remove unused avctx from codec private context [21:43] <durandal_1707> why this again [21:45] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:5c504e4df7b4: vformat/subtitles: check av_copy_packets return code [21:45] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:6e1b1a27a403: avcodec/avpacket: Use av_free_packet() in error cleanups [22:49] <cone-303> ffmpeg.git 03Lukasz Marek 07master:0b46d6f3efa7: lavu/bprint: add append buffer function [23:23] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:86736f59d6a5: avcodec/pngdsp: fix (un)signed type in end comparission [23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/0.11:2d945ac68f7a: avcodec/pngdsp: fix (un)signed type in end comparission [23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/1.0:5bd2b24db399: avcodec/pngdsp: fix (un)signed type in end comparission [23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/1.1:a2e7fd406c5b: avcodec/pngdsp: fix (un)signed type in end comparission [23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/1.2:ddce97c7b0e4: avcodec/pngdsp: fix (un)signed type in end comparission [23:42] <cone-303> ffmpeg.git 03Michael Niedermayer 07release/2.0:a4522ae516b5: avcodec/pngdsp: fix (un)signed type in end comparission [23:47] <cone-303> ffmpeg.git 03Michael Niedermayer 07master:454a11a1c9c6: avcodec/dsputil: fix signedness in sizeof() comparissions [00:00] --- Sat Aug 31 2013