[00:15] <cone-907> ffmpeg.git 03Loren Merritt 07master:b7d0d10a1d54: x86inc: Speed up assembling with Yasm [00:15] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:17e7048d30e5: Merge commit 'b7d0d10a1d54073501b728dbe166a32e2b7b26f1' [00:40] <Rodeo> cbsrobot: erm, pong [02:22] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:7cf8918b0df7: avcodec/huffyuv: update years in copyright [02:22] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:6369766f015f: avcodec/huffyuv: support gbrp9/10/12/14 [08:24] <Keestu> i m building ffmpeg in ubuntu 12.04, and First i built yasm-1.2.0, and tring to build x264, and for which i get the error ""No working C compiler found."". To refer the yasm-1.2.0 library i have used --extra-cflags, and --extra-ldflags options. [08:26] <JEEB> yasm is not a library, it's a binary that's needed [08:26] <JEEB> or well, it could also have a library but that's not needed [08:27] <JEEB> you only need to be able to call yasm --version and get the 1.2.0 one [08:27] <JEEB> as for the no working c compiler thing, check config.log :P [08:28] <Keestu> JEEB, thanks. yasm 1.1.0.2352 is installed version, but x264 requiers minimum of 1.2.0 of yasm. [08:29] <Keestu> hence wanted to refer to manually built yasm. :) [08:29] <Keestu> i still can do make install into system path, but i don't want to do that. :) [08:32] <JEEB> 1) configure yasm to some --prefix (for example --prefix=/home/myusername/ownapps/ ) 2) build 3) make install to copy the things to their places 4) export PATH=/your/prefix/bin:${PATH} [08:32] <JEEB> this should lead you to be able to call the new yasm with just yasm [08:33] <JEEB> if you don't want it to be in the PATH at all then I'm afraid you'll have to have some extra fun with that :P [08:33] <JEEB> setting the PATH in a single terminal in my opinion is nothing bad, though [08:34] <Keestu> JEEB, that means x264 only expects the binary of yasm not the dev library ? [08:34] <JEEB> yes [08:34] <JEEB> only the actual assembler is needed [08:35] <Keestu> I got the below error: Found yasm 1.1.0.2352 [08:35] <Keestu> Minimum version is yasm-1.2.0 [08:35] <JEEB> yes [08:35] <JEEB> because the assembler is too old [08:36] <Keestu> hence i used --extra-cflags, and --extra-ldflags to point to the 'prefix' location, where in i got the error no working c compiler found. [08:36] <JEEB> it most probably would tell you it needs libsomething if it wanted the library [08:36] <Keestu> JEEB, true, i set to PATH to prefixed bin directory of yasm. [08:37] <Keestu> Looks like it need libyasm.a file. [08:37] <JEEB> no... it should not [08:37] <JEEB> and in many cases that doesn't change the actual currently used yasm, if you do `which yasm` you should see which yasm is getting picked up :P [08:37] <JEEB> (in that case you might have to set the PATH in bashrc or something and open a new terminal) [08:45] <Keestu> JEEB, oops. shame on me. it works now i did PATH=$PATH:<mypath> rather than PATH=<MYPATH>:PATH :). [08:45] <Keestu> :) [08:46] <Keestu> thanks JEEB. [09:53] <kierank> "This is useful if you need only to read a video/samples buffer, without to fetch it" ? [10:33] <Keestu> dear all, how can i map ffpmeg error code with message ? for example return error code of avformat_open_input,? Kindly suggest. [11:13] <Rodeo> cbsrobot: pong #2, if you're around [12:40] <cbsrobot> Rodeo: still around ? [12:40] <Rodeo> yes [12:41] <cbsrobot> about the fdk_aac channel layout [12:41] <cbsrobot> see: http://pastebin.com/XpNVDCJQ [12:42] <cbsrobot> does that seem correct to you ? [12:42] <cbsrobot> I guess 7.1 is really MODE_7_1_REAR_SURROUND [12:42] <cbsrobot> but MODE_1_2_2_2_1 / MODE_7_1_FRONT_CENTER seem to be 7.1wide [12:43] <Rodeo> I would say so, except for consistency [12:43] <Rodeo> look at 5.0 and 5.1, they already use back channels, not sides [12:43] <cbsrobot> I compared channel_layout from ffmeg with: https://github.com/mstorsjo/fdk-aac/commit/fa3eba16446cc8f2f5e2dfc20d86a49db... [12:43] <j-b> don't use 7.1 :) [12:45] <Rodeo> either is fine though, but MODE_7_1_REAR_SURROUND should definitely be 7.1, not wide or wide back [12:45] <Rodeo> also, did you see my comment about MODE_1_2_2_2_1 vs. MODE_7_1_FRONT_CENTER? [12:49] <cbsrobot> sure, but how to deal with it ? [12:51] <Rodeo> make a choice [12:52] <Rodeo> i.e. do you want to use the official AAC channel config 7, or do you want channel_config = 0 and write a PCE on purpose [12:53] <nevcairiel> the official 7.1 channel config is stupid, it has two sets of front speakers, instead of the more common front, surround, back model [12:55] <cbsrobot> I have no specific requirement [12:56] <cbsrobot> I don't own a 7.1 setup - I just needed to test some 7.1 files with a soundcard [12:57] <Rodeo> nevcairiel: that's not the point, we're talking about only one layout [12:57] <Rodeo> but two ways to indicate it, one using a channel_config defined in the spec., vs using a PCE (can't remember what it means just now, but basically it describes the layout instead of using a predefined config) [12:58] <Rodeo> Program Config Element, maybe [13:08] <cbsrobot> so a new private option could be added instead of a new channel_layout [13:19] <Rodeo> not sure how that would work, TBH [13:26] <cbsrobot> where can I find information about pce ? [13:34] <av500> ask peloverde [13:36] <cone-319> ffmpeg.git 03Lukasz Marek 07master:9d087ab5ef15: ffplay: remove redundant prototype [14:01] <Rodeo> cbsrobot: AAC spec would me my first guess [14:28] <cone-319> ffmpeg.git 03Rainer Hochecker 07master:bceeccc648ba: dxva2: bump maximum number of slieces for mpeg2 [15:49] <cone-319> ffmpeg.git 03Martin Storsjö 07release/1.2:89c917fcd92c: rtpdec_asf: Copy the need_parsing field from the chained demuxer [15:49] <cone-319> ffmpeg.git 03Martin Storsjö 07release/2.1:d0e0329e9d3d: rtpdec_asf: Copy the need_parsing field from the chained demuxer [16:20] <cone-319> ffmpeg.git 03Carl Eugen Hoyos 07master:05e5bb6107b9: Fix decoding of some 8 < bpc < 16 signed j2k samples with libopenjpeg. [19:10] <kurosu_> BBB / ubitux: regarding vp9 loop filter: I guess there are different filters of different lengths. What are these lengths ? [19:11] <ubitux> 2,4,6,14 [19:13] <kurosu_> ubitux: 14 !? that must be a pain... Did you have to implement some kind of transpose or is it limited to 8xN blocks ? [19:14] <ubitux> there is a 16x16 transpose [19:15] <ubitux> filter6() and filter14() are actually pretty fun to write [19:15] <kurosu_> ubitux: from vp9dsp.c it seems the filter size is decided per border, right? if such is the case, do you think it would be possible to use a transpose smaller than 16x16? already done maybe? [19:15] <ubitux> filter2/4 are same as vp8 and honestly that was fucking painful because of the weird signess all over [19:15] <kurosu_> I guess you are calling twice this function for 32xN partitions [19:15] <ubitux> i don't really know about the caller [19:16] <kurosu_> actually the dsp function works on chunk of 8 pixels, so I do have my reply [19:18] <ubitux> mmh i think i'll push the simplifications before adding 88... [19:19] <kurosu_> BBB: do you know the gain of this 14taps filter over a 6-long one ? [19:19] <ubitux> kurosu_: https://github.com/ubitux/FFmpeg/blob/vp9-simd/libavcodec/x86/vp9lpf.asm#L59... [19:19] <ubitux> filter14() ^ [19:19] <ubitux> it's basically just the FILTER_{INIT,UPDATE} [19:20] <ubitux> the tricky part is the re-use of registers [19:20] <kurosu_> ubitux: do you know how long your asm implementation of filter14 and filter6 are taking respectively ? [19:20] <ubitux> mmh [19:22] <ubitux> full block is ~3000 decicycles, without filter14 it's about ~1900 decicycles [19:22] <ubitux> feel free to bench :p [19:22] <kurosu_> I'm just trying to figure the complexity vs gain tradeoff here, which might not be the best [19:23] <kurosu_> ubitux: it's been so long since my last pull, don't think I will any time soon [20:30] <llogan> beastd: can you take a look at https://trac.ffmpeg.org/ticket/3352 [20:31] <beastd> llogan: ah. i am having a look. [20:38] <llogan> i wish roger would proof read first... [22:04] <ubitux> BBB: ping [22:05] <ubitux> BBB: so i did the transpose differently: https://github.com/ubitux/FFmpeg/commit/4d126ce878b1a33455de9b38397473168bc7... [22:06] <ubitux> it's basically a 8x8 transpose, but it's working on full width (16 instead of 8) [22:06] <ubitux> i don't have less instructions though [22:06] <ubitux> what did i miss? :p [22:11] <Skyler_> that looks like a nice solution [22:12] <ubitux> it doesn't look better though [22:12] <ubitux> it's probably slower actually but i didn't bench [22:15] <ubitux> well i guess i'll start pushing the beginning of the patchset meanwhile [22:15] <llogan> now everyone can watch me flail around with regex shenanigans [22:16] Action: llogan starts playing "Yackety Sax" [22:17] <ubitux> llogan: https://pbs.twimg.com/media/Be72GYUCYAAM7Vq.png:large ? [22:19] <llogan> ubitux: one clue is simply ".*" [22:20] <llogan> you'll make a soduku player cry [22:22] <nevcairiel> there is way too many stars in that thing! [22:43] <cone-319> ffmpeg.git 03Clément BSsch 07master:5d144086cc55: x86/vp9lpf: faster P7..Q7 accesses. [22:43] <cone-319> ffmpeg.git 03Clément BSsch 07master:315b4775adf8: x86/vp9lpf: refactor v/h using common macros for P7 to Q7. [22:43] <cone-319> ffmpeg.git 03Clément BSsch 07master:822385d77598: x86/vp9lpf: add a preload system in FILTER_UPDATE. [23:06] <ubitux> heh, strangely it's a bit faster [23:06] <ubitux> i guess i'll go for this [23:07] <ubitux> ah my bad, it's slower, switched the 2 results [23:08] <ubitux> (2738 -> 2808) [23:13] <ubitux> BBB: i'll push https://github.com/ubitux/FFmpeg/commit/699b25ce73514da89c0b168347eeecf5d38a... soon [23:14] <ubitux> https://github.com/ubitux/FFmpeg/commit/c156d99c16fa1b39f8c88ba038bbd14df16c... make it a bit slower [23:44] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:a38842120add: avcodec/libfdk-aacenc: change MODE_7_1_REAR_SURROUND to map to AV_CH_LAYOUT_7POINT1 [23:44] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:673ce8e46ae2: avcodec/libfdk-aacenc: change MODE_7_1_FRONT_CENTER to map to AV_CH_LAYOUT_7POINT1_WIDE_BACK [00:00] --- Tue Jan 28 2014