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

[burek]

[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/libavcodec/x86/utvideodsp.asm
[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