[02:35] <cone-72> ffmpeg.git 03Martin Storsjö 07master:16381923fb7b: configure: Check whether MSVC requires using the C89-to-C99 converter [02:35] <cone-72> ffmpeg.git 03Michael Niedermayer 07master:a7663ad9cf74: Merge commit '16381923fb7b9087ce559fb1cd3594469ac6788b' [02:57] <cone-72> ffmpeg.git 03Diego Biurrun 07master:c7f7bfc9e3a3: Remove all Alpha architecture optimizations [02:57] <cone-72> ffmpeg.git 03Michael Niedermayer 07master:e25ed2608c96: Merge commit 'c7f7bfc9e3a3150ba72bc34366c13fb2210c66ac' [03:27] <cone-72> ffmpeg.git 03Diego Biurrun 07master:19e30a58fc8e: Deprecate obsolete XvMC hardware decoding support [03:27] <cone-72> ffmpeg.git 03Michael Niedermayer 07master:5231eecdafff: Merge remote-tracking branch 'qatar/master' [08:57] <cone-127> ffmpeg.git 03Kostya Shishkov 07master:bae14f38d992: mpegvideo: Fix swapping of UV planes for VCR2 [08:57] <cone-127> ffmpeg.git 03Diego Biurrun 07master:321514042534: mpeg12dec: Remove incomplete and wrong UV swapping code for VCR2 [08:57] <cone-127> ffmpeg.git 03Diego Biurrun 07master:33311af75d7f: fate: Add VCR2 test [09:53] <cone-127> ffmpeg.git 03Timothy Gu 07master:52955c412c60: doc/libavutil: add things from avutil.txt [09:53] <cone-127> ffmpeg.git 03Timothy Gu 07master:62923e9014ba: doc: remove avutil.txt [10:48] <HzD_Byte> hello ppl [10:57] <HzD_Byte> how can I submit a patch to the mailing-list? I'm not registered there. cehoyos wrote that I need to create a patch with git format-patch but I never sent patches with it [11:00] <av500> sign up to the mailing list [11:01] <av500> git format-patch [11:01] <av500> attach to emaiö [11:01] <av500> email [11:01] <av500> profit [11:02] <HzD_Byte> git format-patch does't produce any output :) do I need to specify any special options? [11:02] <ubitux> -1 [11:02] <HzD_Byte> ok [11:02] <HzD_Byte> thank you [12:18] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:9e5ef1c5c372: h264: Do not treat the initial frame special in handling of frame gaps [12:59] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:f3458a56c117: avcodec/vdpau: try to fix version macro use [13:07] <cone-127> ffmpeg.git 03Anton Khirnov 07master:ca22d1dea284: vdpau: add a convenience function for getting a decoder profile. [13:07] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:5f231d909f15: Merge commit 'ca22d1dea2842fca0422dd1d2bd09e7eb2c8f118' [13:14] <cone-127> ffmpeg.git 03Anton Khirnov 07master:728c4658563d: vdpau: add a constructor for AVVDPAUContext. [13:14] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:31c09b7663ac: Merge commit '728c4658563dc82115ade0f1679679eddb7be5ff' [13:24] <cone-127> ffmpeg.git 03Anton Khirnov 07master:8941971a8f2e: lavc: make error_rate a private option of mpegvideo encoders [13:24] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:b71e4d871745: Merge commit '8941971a8f2e24b9a84fe29f128d13ceb89c0a65' [13:50] <cone-127> ffmpeg.git 03Anton Khirnov 07master:b45c87083de6: lavc: schedule unused FF_QSCALE_TYPE_* for removal on next bump [13:50] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:d67d3e29779a: Merge commit 'b45c87083de67969c1598cfef41e7c947b137922' [14:02] <cone-127> ffmpeg.git 03Anton Khirnov 07master:b6094811f9fc: lavc: move MB_TYPE_* macros from avcodec.h to mpegvideo.h [14:02] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:dbfa4317f3f8: Merge commit 'b6094811f9fca66cdf853420696e96fdc3e4987a' [14:12] <plepere> ok, I need help for some very basic assembly [14:13] <plepere> tried to simplify my code more and more and I feel like I'm missing something essential [14:14] <plepere> I did the %include "libavutil/x86/x86util.asm" [14:14] <plepere> I'll do a simple pastebin [14:15] <plepere> http://pastebin.com/0kaVcTqY [14:16] <plepere> I removed the commented stuff, but this doesn't compile, the mov operation gives me an "invalid opcode" at compilation [14:17] <ubitux> missing ':' after the x and y declaration? [14:17] <ubitux> what's '?'? [14:17] <plepere> ? means that it's undefined [14:17] <ubitux> aren't you inverting src/dst btw? [14:18] <ubitux> ah, ok, get it [14:18] <plepere> isn't mov x,0 equivalent of x=0 ? [14:18] <nevcairiel> its more like 0=x [14:18] <ubitux> yeah i wasn't sure [14:18] <ubitux> plepere: it's fine yes [14:19] <nevcairiel> doesnt yasm use at&t syntax which has mov src, dst? [14:20] <ubitux> yasm uses intel [14:20] <ubitux> plepere: anyway, likely x: DW ... [14:21] <plepere> inverting the src and dest gives me the same error [14:21] <ubitux> it's fine [14:21] <ubitux> mov x, 0 is ok [14:22] <plepere> isn't name: for jumps ? [14:22] <ubitux> it's labels [14:22] <plepere> ok [14:22] <ubitux> here you want to label your dw [14:22] <ubitux> i guess [14:23] <plepere> yes [14:23] <plepere> well I'm doing this because I couldn't get to use basic eax registers [14:23] <nevcairiel> writing into a data element like this seems like a bad idea though, if you ask me :D [14:23] <plepere> using this guide for reference : http://www.cs.virginia.edu/~evans/cs216/guides/x86.html [14:24] <nevcairiel> did you read the guide to using the x264 asm thing? [14:24] <nevcairiel> well, kinda-guide [14:25] <plepere> I did cross that guide a while ago.... [14:25] <nevcairiel> https://wiki.videolan.org/X264_asm_intro/ [14:26] <plepere> ah ok, it wasn't that one I found [14:26] <nevcairiel> its slightly outdated by now [14:26] <nevcairiel> anyway the x264inc.asm abstracts a lot of the asm away from you [14:26] <nevcairiel> so instead of eax, edx, ecx, etc, you would simply use r0, r1, r2, r3,.... [14:27] <nevcairiel> or you can even give them names [14:27] <nevcairiel> variable names if you want, for code clarity :) [14:27] <plepere> but isn't r0,r1...etc used for incoming parameters ? [14:28] <plepere> I'll take a look at the x264 guide. It most likely has the answers to my questions. thanks a bunch ! [14:29] <nevcairiel> if you have 2 parameters to your function, r0 and r1 will be used for those, and you can of course use r2 and upwards for temporary storage [14:29] <nevcairiel> you need to tell the cglobal line how many registers you want [14:29] <nevcairiel> but the page all explains that [14:30] <plepere> that's what I read [14:31] <plepere> so basically, I have r0 to r15, m0 to m7 and xmm0 to xmm15 (for SSE only). am I still right [14:32] <nevcairiel> m0 maps to xmm0, if you specifically want mmx, its mm0 [14:32] <plepere> ok [14:32] Action: plepere takes notes [14:33] <nevcairiel> there are also quite a lot of comments in x86inc.asm, which might turn out helpful to understand some of the things cglobal does for you [14:33] <ubitux> looking at the other .asm in the code base is helpful [14:33] <ubitux> especially recent ones [14:33] <ubitux> or files with similar logic [14:34] <plepere> I have h264_chromamc.asm in a tab for reference. :) [14:34] <nevcairiel> h264 probably has quite a bit of similar functions then hevc needs :) [14:34] <plepere> nevcairiel, I have to do some testing, bu I think that the idct might be re-used almost entirely. [14:34] <plepere> *but [14:35] <plepere> h264 idct for hevc [14:35] <smarter> nop [14:36] <smarter> hevc has both DCTs and a 4x4 DST and the DCTs are not the same than in h264 [14:37] <plepere> but if it's only the coefficients that change between the 8x8 and 16x16... [14:37] <smarter> the tricks used in h264 to compute the transform faster are also different if I'm not mistaken [14:37] <plepere> ok ok [14:39] <plepere> I'll have to look into it anyway. [14:41] <smarter> plepere: if you're brave, there's a ton of x86 intrinsics for hevc here that could be converted to asm: https://github.com/OpenHEVC/FFmpeg/tree/hevc/libavcodec/x86 [14:41] <smarter> there's also hevc_deblock.asm that needs to be reviewed/tested and merged [14:41] <plepere> smarter, I did the intrinsics. :) [14:41] <plepere> I'm looking to convert them in asm. [14:41] <smarter> oh, I see [14:42] <smarter> nice! [14:43] <nevcairiel> that shouldnt be too impossible then [14:43] <plepere> nah. [14:43] <plepere> It's the first function that I need to do. Then it'll just be automatic [14:44] <ubitux> objdump the result, copy/paste in .asm, simplify, macrotize, abstract some stuff, done [14:44] <nevcairiel> lol [14:45] <nevcairiel> personally i do like intrinsics since they are so easy to use to quickly whip up some simd code, but i see the advantage of yasm code as well [14:46] <plepere> yeah, intrinsics are a really nice and fast way to optimize C. [14:46] <plepere> ubitux : that still needs a huge understanding of assembly structures and all, and I'll get that only by writing some. [14:46] <ubitux> assembly structures? [14:47] <plepere> coding conventions and so forth [14:47] <plepere> good practices etc... [14:51] <cone-127> ffmpeg.git 03Anton Khirnov 07master:aa2412298911: lavc: deprecate FF_MAX_B_FRAMES [14:51] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:9f32048dd196: Merge commit 'aa241229891173b0357eee04e6ca78f806cc9c0c' [14:51] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:2925571278bf: avcodec/mpegvideo_enc: Fix possibly exploitable security issue with -bf [14:54] <ubitux> FF_MAX_B_FRAMES ’ INT_MAX [14:54] <ubitux> isn't this a bit risky somehow? [14:56] <ubitux> i see various occurences of s->max_b_frames + N [14:57] <nevcairiel> is FF_MAX_B_FRAMES actually used anywhere? anton replaced its uses with a codec-specific MAX_B_FRAMES in places [14:58] <nevcairiel> mostly only mpegvideo_enc [14:59] <ubitux> i guess the only remaining relevant occurence is in ratecontrol then [15:00] <ubitux> libavcodec/ratecontrol.c: else if (i % (s->max_b_frames + 1)) [15:00] <ubitux> and libavcodec/libxavs.c [15:00] <ubitux> libavcodec/libxavs.c: x4->pts_buffer[ctx->frame_number % (ctx->max_b_frames+1)] = frame->pts; [15:01] <ubitux> not sure if the overflowed mod can cause problems [15:02] <ubitux> INT_MAX-<arbitrary-small-value> might be less risky [15:02] <ubitux> nevcairiel: and check the merge, it wasn't correctly sanitized [15:03] <nevcairiel> more importantly in libxavs it allocates max_b_frames+1*sizeof(*ptrsomething) [15:03] <ubitux> with braces? [15:03] <ubitux> :) [15:03] <nevcairiel> yes [15:03] <nevcairiel> i didnt bother to copy paste [15:04] <nevcairiel> all these encoders using max_b_frames should probably sanify the value to their local maximum [15:04] <nevcairiel> even INT_MAX-30 would still overflow the calculation above [15:04] <nevcairiel> luckily bad files cant trigger that, need bad cmdline :p [15:04] <ubitux> checking malloc should be enough [15:04] <nevcairiel> its checked at least [15:23] <cone-127> ffmpeg.git 03Anton Khirnov 07master:cce3e0a49f0d: Move av_fast_{m,re}alloc from lavc to lavu. [15:23] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:7c888ae746da: Merge commit 'cce3e0a49f0dd030262c28d9c53de0bd2fd909c4' [15:31] <cone-127> ffmpeg.git 03Diego Biurrun 07master:7b9780e7bf9d: mpeg12dec: Remove unused swap_uv member from Mpeg1Context [15:31] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:1ac4797d1998: Merge commit '7b9780e7bf9d86e3e4e9606a971bb2d0d718bac2' [15:35] <plepere> ok, another wuestion [15:35] <plepere> questions [15:36] <plepere> *question. [15:36] <plepere> do I need to do something to use rXd ? [15:37] <plepere> in assembly [15:37] <JEEB> at least with named variables I remember just adding d or q at the end of them [15:38] <JEEB> some code I never really finished https://github.com/jeeb/libav/blob/5f00119409f5e2020e74b8609736275b2098883c/... [15:38] <plepere> in h264_chromamc.asm add r4d, 8 is used [15:39] <plepere> but when I do pxor r2d,r2d I get a compiling error [15:40] <nevcairiel> pxor is for mm registers, isnt it [15:40] <plepere> AH YES [15:40] <plepere> oops caps [15:40] <JEEB> :) [15:41] <nevcairiel> a simple xor should work :) [15:41] <cone-127> ffmpeg.git 03Kostya Shishkov 07master:ddb839e92865: metasound: add missing modes [15:41] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:2cfdc2879a6c: Merge commit 'ddb839e9286594ff7a862a956402106fca7055c9' [15:41] <plepere> ok [15:42] <plepere> I need to seperate mm and r registers. [15:42] <plepere> different instructions for each of theù [15:42] <plepere> *them [15:43] <nevcairiel> some of the mov instructions work on both, but otherwise, yea [15:43] <plepere> compiling ! :D [15:44] <plepere> now I just need to point the function and cry because md5 checksums will show that what I did is wrong. [15:44] <JEEB> I know that feeling, and then you'll use some binary diff tool to see where and how it's going wrong :D [15:45] <plepere> I'm going from intrinsics to assembly, so it's going to be quite easier than directly from C. [15:46] <nevcairiel> just need to have a big lookup-list which intrinsic is which command :D [15:46] <ubitux> it's called objdump -d -Mintel [15:46] <nevcairiel> heh [15:47] <nevcairiel> many intrinsics really have it in their name [15:49] <plepere> yup. And I'm using the intel instrinsics guide which gives me the asm instruction for each intrinsic [15:49] <JEEB> was that the java applet? :D [15:49] <plepere> yes [15:50] <plepere> it's pretty well done. [15:50] <JEEB> yeah [15:55] <plepere> I really want to put my hands on a haswell processor. 256-bit registers... this will make 10-bit decoding so much easier ! [15:55] Action: nevcairiel got one [15:56] Action: JEEB is only on an ivy [15:56] <JEEB> also I hear x264's 10bit encoding could be made much faster as well [15:57] <nevcairiel> x264 got a bunch of avx2 improvements already [15:57] <nevcairiel> but i suppose 10-bit isnt the biggest focus [15:57] <JEEB> yeah [15:57] <plepere> you really need the hardware to support it. [15:58] <JEEB> prunedtree noted that there's still plenty of stuff to be done on that side, but it's mostly a case of lack of interest :) [15:58] <plepere> are TVs capable of rendering 10bit or is it 8bit ? [15:58] <nevcairiel> all broadcast content is usually still 8-bit, and hardware decoders are limited to that [15:58] <JEEB> yup [15:59] <nevcairiel> although if you send a raw YUV signal to a tv, they can usually accept up to 12-bit over HDMI [15:59] <plepere> and does it show 12-bit ? [16:01] <cone-127> ffmpeg.git 03Kostya Shishkov 07master:1afa8a7568ba: twinvq: support multiple frames per packet [16:01] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:a24aef5dfa51: Merge commit '1afa8a7568ba57ad0cd2923f6e641e10d32cded4' [16:02] <nevcairiel> most tvs have a 8-bit panel only, i guss [16:02] <nevcairiel> guess* [16:02] <nevcairiel> but 10-bit is also about smaller files [16:02] <nevcairiel> or can be anyway [16:03] <JEEB> and enables for better keeping of information that generally needs dithering or whatever [16:03] <plepere> I was told that 10bit is mostly used in medical fields because it's much more precise. [16:04] <plepere> how can 10-bit bring files smaller ? isn't it adding data compared to 8-bit ? [16:05] <Compn> need to get some medical device formats supported [16:05] <JEEB> if you think of uncompressed data or lossless compression, yes [16:05] <Compn> want to turn some mri images into video :) [16:05] <JEEB> but in case of lossy compression the extra precision helps [16:05] <JEEB> so you can actually encode similar quality with less bits [16:06] <nevcairiel> http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf [16:06] <plepere> thanks nevcairiel ! [16:06] <nevcairiel> not sure how much that still applies to hevc [16:07] <JEEB> it still does, to a lesser extent [16:07] <JEEB> since the amount of internal precision loss was lessened, but it still happens [16:08] <JEEB> for H.264 this was the case http://akuvian.org/src/x264/bitdepth_dataflow.png [16:10] <plepere> dammit. sorry to bother you AGAIN with my assembly, but for some reason, it won't find my function. (undefined reference) even though I have the right name in cgglobal and gave the procedure in the dsp_init [16:11] <nevcairiel> it would append a cpuid postfix to the name [16:12] <nevcairiel> if you use INIT_XMM sse2, it would postfix your function name with _sse2 [16:12] <plepere> ok thanks [16:12] <nevcairiel> and of course it puts ff_ in front [16:13] <plepere> thank you, be blessed [16:14] <plepere> aaaaaand the video is incorrect ! [16:14] <ubitux> am i the only one to expect various kind of "bitrate flashes" with vp8 (libvpx) encoding? [16:14] <JEEB> -f rawvideo and binary diff time? [16:15] <nevcairiel> first step is always to tripple check what your code does [16:15] <cone-127> ffmpeg.git 03Kostya Shishkov 07master:669fe505952f: twinvq: consume block_align+1 packets as full ones [16:15] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:726566704f32: Merge commit '669fe505952f3d8175b1ad6971033a8e8120523b' [16:15] <ubitux> like this: http://lucy.pkh.me/ncmpcpp.webm (check around 5 sec and 10 sec) [16:15] <JEEB> and yes, stepping through the asm in gdb / some other debugger is also good to do [16:16] <plepere> it's a tiny function, so I don't think it will take long. [16:18] <ubitux> this is the failed frame: http://b.pkh.me/vp8failframe.jpg [16:18] <ubitux> it's really weird :p [16:19] <ubitux> and the second one: http://b.pkh.me/vp8failframe2.jpg [16:20] <cone-127> ffmpeg.git 03Diego Biurrun 07master:ad1161799e09: mpeg12dec: Remove outdated UV swapping code for VCR2 [16:20] <cone-127> ffmpeg.git 03Michael Niedermayer 07master:54af7ce4cec0: Merge remote-tracking branch 'qatar/master' [16:26] <ubitux> can be reproduced with ./ffmpeg -loop 1 -i tests/lena.pnm -vf 'scale=2*iw:2*ih' -t 20 -y out.webm [16:26] <ubitux> frame at t=10s is broken [16:27] <ubitux> it's like it's trying to adjust some bitrate constraints or something [16:27] <ubitux> but it's still a little visible if you have -b:v 1M [16:27] <ubitux> (there is this kind of flash effect) [16:32] <ubitux> it happens at 5 sec too [16:32] <ubitux> it's regular [16:37] <ubitux> well i guess no one care about vp8 anyway [16:37] <ubitux> ...but still. [16:40] <plepere> sorry can't help you. :/ I'm still debugging my 20 lines of assembly code. [16:57] <ubitux> :) [17:38] <ac_slater> Hey guys, before I dig into libavcodec, I have some image data (raw BGR 8bit per channel) and I need to feed this to a RTSP server that can only accept elementary MP4 data (I think that means just the video without headers?). Any advice? [17:38] <ac_slater> nevermind. Asking on #ffmpeg instead [20:36] <cone-234> ffmpeg.git 03Marton Balint 07master:951d81900673: mxfdec: update current edit unit when seeking in mxf files without index tables [20:36] <cone-234> ffmpeg.git 03Michael Niedermayer 07master:0f969c00c6a3: Merge commit '951d819006730145255333749367c4ea722ffd9b' [20:54] <llogan> let me spam the channel with stupid trac comment mistakes [21:04] <llogan> mentalcase in #ffmpeg [21:05] <wm4> amazing what $100 can d [21:05] <wm4> o [21:11] <cone-234> ffmpeg.git 03Reimar Döffinger 07master:ecf442a58b09: lavf: improve support for AVC-Intra files. [21:11] <cone-234> ffmpeg.git 03Michael Niedermayer 07master:074bae745d9d: Merge commit 'ecf442a58b09bdb1dc1d2c3904b82ac5f79b2878' [21:22] <cone-234> ffmpeg.git 03Anton Khirnov 07master:9eda9d3322a6: h264: free the tables and uninitialize the context on flush [21:22] <cone-234> ffmpeg.git 03Michael Niedermayer 07master:9244a6809229: Merge remote-tracking branch 'qatar/master' [22:37] <j-b> smarter: mraulet: http://www.tomshardware.fr/articles/vlc-hevc-h265,1-46216.html [23:06] <smarter> j-b: fun [23:10] <j-b> so, 4k plays on a high-end i [23:10] <j-b> i7 [23:12] <nevcairiel> high bitrate is problematic even on a 4770 [23:13] <nevcairiel> got a clip from which can barely hit 20 fps [23:26] <ubitux> af05edc658f3af284a1af39c00a36aeff0adaa0d 728c4658563dc82115ade0f1679679eddb7be5ff [23:26] <ubitux> ll [23:26] <ubitux> lol [23:27] <ubitux> it was too much to call them the same name [23:27] <ubitux> srsly... [00:00] --- Fri Nov 15 2013