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

[burek]

[01:53] <cone-758> ffmpeg.git 03Luca Barbato 07master:cd975d5658a1: hevc: Spin the mv_mpv_mode calls in a stand alone function
[01:53] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:148506c965dd: Merge commit 'cd975d5658a1cbe99939df75db59d5ae9fbcb4e0'
[02:18] <cone-758> ffmpeg.git 03TOYAMA Shin-ichi 07master:e01acd868b01: doc/decoders.texi: typo in description for option ifo_palette
[02:18] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:230aeee94c27: doc: fix the the typos
[02:22] <kierank> can vaapi just be used for general decoding (i.e not rendering)
[02:28] <wm4> kierank: yes
[02:29] <wm4> in fact, the rendering part of vaapi is a joke
[02:29] <wm4> so you're better off using decoding only
[02:29] <kierank> https://gitorious.org/hwdecode-demos appears to be rendering only
[02:32] <wm4> don't know, but reading back from the vaapi surfaces is possible
[02:40] <Zeranoe> llogan: Thank you for answering so many questions on the Zeranoe forum. I really appreciate it.
[03:45] <cone-758> ffmpeg.git 03Mark Reid 07master:08d81d0a01e4: libavformat/mxfdec.c: export source package uids and names as metadata
[05:44] <Zeranoe> Looks like there is an error with DeckLink support using the latest FFmpeg and DeckLink SDK 'libavdevice/decklink_common.cpp:61:42: error: 'char* dup_wchar_to_utf8(wchar_t*)' was declared 'extern' and later 'static' [-fpermissive]'
[05:54] <Zeranoe> Full error: http://paste.ubuntu.com/9164142/
[07:53] <lookatmeyou> anyone help! I compile using this command: g++ deco.c -o deco -D__STDC_CONSTANT_MACROS -lavdevice -lavformat -lavfilter -lavcodec -lswresample -lswscale -lavutil
[07:53] <lookatmeyou> but got lots of undefined reference error
[07:53] <lookatmeyou> for example, deco.c:(.text+0x6a): undefined reference to `avcodec_find_encoder(AVCodecID)'
[07:54] <lookatmeyou> I have already installed ffmpeg libs in /usr/local/lib
[07:58] <wm4> forgotten extern C?
[08:02] <lookatmeyou> I don't quite understand what you mean
[08:02] <lookatmeyou> http://paste.ubuntu.com/9166377/
[08:03] <lookatmeyou> this is my codes
[08:05] <wm4> use gcc not g++
[08:08] <lookatmeyou> it works, thank you very much
[10:00] <lookatmeyou> Anyone help, when I run a program I got this error
[10:00] <lookatmeyou> me at ubuntu:~/codec$ ./deco
[10:00] <lookatmeyou> H264 Codec not found
[10:01] <lookatmeyou> But I've already installed x264 on my machine
[10:02] <lookatmeyou> And the ffmpeg example runs OK
[10:02] <lookatmeyou> root at ubuntu:~/ffmpeg-2.4.3/doc/examples# ./decoding_encoding h264
[10:02] <lookatmeyou> Encode video file test.h264
[10:04] <lookatmeyou> http://paste.ubuntu.com/9168165/, this is my codes
[10:16] <lookatmeyou> anyone please help
[10:20] <rcombs> didn't build libavcodec with --enable-libx264?
[10:21] <rcombs> also, didn't call av_register_all
[10:22] <lookatmeyou> I build ffmpeg 2.4.3 with ./configure --enable-libx264 --enable-gpl --enable-shared
[10:22] <lookatmeyou> let me try av_register_all
[10:24] <lookatmeyou> thank you, it's av_register_all.
[13:19] <cone-26> ffmpeg.git 03James Almer 07master:14b9302f5f44: lavf/apngdec: properly skip currently unsupported in-stream tags
[13:28] <cone-26> ffmpeg.git 03Matthew Oliver 07master:3bedd72a9ec9: lavf: fix apngdec under msvc.
[14:07] <cone-26> ffmpeg.git 03Reimar Döffinger 07master:79be253635fc: mxfdec: minor simplification.
[14:07] <cone-26> ffmpeg.git 03Reimar Döffinger 07master:c2c27e9e51c9: indeo2: move variable declarations into blocks using them.
[14:07] <cone-26> ffmpeg.git 03Reimar Döffinger 07master:478c61ccb2be: h264_i386: Optimize decode_significance_8x8_x86 for 64 bit.
[14:07] <cone-26> ffmpeg.git 03Reimar Döffinger 07master:33fc1ccb4910: h264_mb: Use smaller data type for refs in await_references.
[14:07] <kierank> is there a variable shift instruction
[14:10] <kierank> shifting left is easy but right is much harder
[14:18] <kurosu> pmulhw with proper multiplicand ?
[14:18] <kurosu> which might be obtained from a table using phufb ?
[14:19] <kurosu> never tried, but might be doable for 16 bits values
[14:19] <kurosu> for 8bits, I don't think so
[14:20] <lookatmeyou> help! When I decode a h264 video using avcodec_decode_video2, I got this error http://paste.ubuntu.com/9172231/
[14:21] <lookatmeyou> This is the avcodec_decode_video2 output.
[14:22] <lookatmeyou> What's that mean?
[14:22] <kierank> kurosu: how do you shift right with pmulhw
[14:22] <kurosu> kierank, you shift left and truncate the 16 MSBs ;)
[14:23] <kierank> ah
[14:23] <kurosu> of the 32 bit result
[14:23] <kurosu> but I think for some values you wouldn't get the proper result
[14:23] <kurosu> pmullw is s16xs16
[14:23] <kurosu> I think there might be a variation with u16, not sure
[14:24] <kurosu> also, maybe bmi (as in the amd insn set) has somthing
[14:25] <kierank> I am considering writing v210enc simd
[14:26] <cone-26> ffmpeg.git 03Michael Niedermayer 07master:0b9a9e0e2ccd: avcodec/libspeexdec: make array const
[14:27] <kurosu> yeah, I had figured it was about some peculiar unpacking
[14:28] <kierank> I'm not sure it's possible to just invert the unpack
[14:28] <kurosu> probably not worth it, but you might want to shift only the parts that are constant shift, mask the result and gather it (not sure it works)
[14:29] <kurosu> oh, bmi seems to be only about gprs anyway
[14:32] <kierank> I guess I could shuffle and shift 3 times each
[15:24] <kierank> how does one produce a SIMD output when using bytestream2_init_writer
[15:29] <AlfredWangHanWuD> hello guys
[15:41] <AlfredWangHanWuD> after using ffmpeg feed a ffm...the player only can not play the complete video stream
[15:42] <AlfredWangHanWuD> any one know the reason
[15:56] <cone-26> ffmpeg.git 03Benoit Fouet 07master:90c9b494052e: ffplay: fix mem leak when opening input or parsing options fail.
[16:37] <Gramner> kierank: pmulhrsw can be (ab)used for right shifting individual elements by different amounts. i did that when I wrote x264's v210 asm
[16:38] <kierank> Gramner: i see
[17:31] <kurosu> pmulhrsw does rounding, but it's obviously doable if you managed to
[17:31] <kurosu> on the other hand, that probably means it's just a sign-off away from being in ffmpeg then (if that was the intent)
[17:37] <kierank> kurosu: Gramner did the opposite of what i wanted  to do
[17:37] <kierank> he did v210 -> nv20
[17:37] <kierank> I want yuv422p10 -> v210
[17:37] <kurosu> ok
[17:42] <Compn> when will we get the "one true colorspace" to end them all? :P
[17:42] <kierank> I think I can make it work but it'll be embarassingly bad
[17:42] <Compn> when hardware, codecs, players all get together and pick one space / packing / byte and just get on with it. no more converting
[17:43] <kierank> yeah good luck with tha
[17:43] <Compn> "v210 is good enough for everyone" :P
[17:43] <Compn> ehe
[17:43] <kierank> it pretty much is in the yuv domain
[19:02] <cone-26> ffmpeg.git 03Michael Niedermayer 07master:8e6a44cfc5ec: avdevice/iec61883: Use av_freep(), avoid leaving stale pointers in memory
[19:02] <cone-26> ffmpeg.git 03Michael Niedermayer 07master:7df2981f04dc: avfilter/avf_concat: Use av_freep(), avoid leaving stale pointers in memory
[19:02] <cone-26> ffmpeg.git 03Michael Niedermayer 07master:9146a476003c: avfilter/graphparser: Use av_freep(), avoid leaving stale pointers in memory
[19:07] <cone-26> ffmpeg.git 03Reimar Döffinger 07master:8437cc72060f: ffv1dec: Avoid unnecessarily large stack usage and copies.
[19:10] <jamrial> can someone using msvc 2012 check what is wrong with the ebur128 filter? it's been broken there since forever
[19:10] <ubitux> it's a known bug
[19:10] <jamrial> it works in msvc 2013, so it's probably something related to the c99 converter
[19:10] <jamrial> Ah, i see
[19:10] <ubitux> nevcairiel reported it
[19:10] <ubitux> and it was fixed in recent versions
[19:11] <nevcairiel> its a compiler bug
[19:11] <nevcairiel> msvc 2012 has an issue with some sse2 float things
[19:11] <nevcairiel> they fixed it in 2013, but they are not going to fix 2012
[19:12] <JEEBcz> ye
[19:45] <cone-26> ffmpeg.git 03Michael Niedermayer 07master:2f6550bb9a8d: avcodec/mjpegdec: fix pixfmtid 0x14111100
[19:46] <Compn> oh yeah vp6f is flipped 
[19:46] <Compn> i remember mplayer bug on that i think
[20:33] <kierank> ignore the patch i sent
[20:33] <kierank> it's broke
[20:52] <kierank> how do you OR two xmm registers in x86 asm?
[20:53] <J_Darnley> Is there not por?
[20:54] <kierank> I don't believe so
[20:54] <Gramner> por for integers or orps for floats
[20:55] <kierank> oh there is a POR
[20:55] <J_Darnley> Yeah.  POR is listed in Intel's docs
[20:55] <kierank> it's just a pita to grep in the manual
[20:56] <b_jonas> kierank: it may help to read the intel and the amd manuals together. they're organized differently, so they partially complement each otehr.
[20:57] <cone-26> ffmpeg.git 03Michael Niedermayer 07master:4327088da355: avcodec/x86/lossless_audiodsp: support len %16 == 8 in scalarproduct_and_madd_int16()
[20:57] <cone-26> ffmpeg.git 03Michael Niedermayer 07master:ce6141259bb9: avcodec/wmalosslessdec: support 24bit lossless
[21:00] <kierank> how do I use movhlps in x264asm?
[21:00] <Gramner> what do you mean?
[21:01] <Gramner> there's nothing special about that instruction
[21:01] <kierank> yasm moans about it
[21:01] <kierank> movlhps m1, [r3+r4]
[21:01] <Gramner> are you using ymm registers?
[21:01] <Gramner> it's only valud for xmm
[21:01] <Gramner> valid*
[21:02] <Gramner> so use xmN in that case
[21:02] <Gramner> also movhlps with memory arg is not valud
[21:02] <kierank> oh
[21:03] <Gramner> you probably want movq
[21:03] <Gramner> oh, movLH. movhps then
[21:03] <J_Darnley> (x86 has too many move instructions)
[21:04] <Gramner> yeah, I don't like the whole int/float split
[21:09] <kurosu> michaelni, regarding scalarproduct_and_madd_int16, does an order&8 mean order <= 8?
[21:09] <kurosu> otherwise, I kind of remember we decided to padd the buffer with 0 in another case
[21:10] <kurosu> order <= 8 (for real files, not for the format) means mmxext only is fine, otherwise ...
[21:10] <kierank> hmmm soo close
[21:10] <kierank> my luma is right but my chroma is wrong
[21:11] <michaelni> kurosu, the fie has order == 8 and the sse* code did definitly not work for it
[21:11] <michaelni> fiLe
[21:11] <Gramner> kierank: can you post your code?
[21:11] <kierank> http://pastie.org/private/htp6vzpwhnkiekveqtna3a
[21:12] <kierank> probably the pshufb indices are broken
[21:12] <kurosu> michaelni, at this point, what happens if eg order=24? it would fail/crash?
[21:12] <michaelni> it should use the mmx code, also theres a bug in my code ill push a fix in a moment
[21:13] <kierank> packing is here: https://developer.apple.com/library/mac/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG8-V210__4_2_2_COMPRESSION_TYPE
[21:15] <kierank> seems that Cr is broken badly
[21:17] <cone-26> ffmpeg.git 03Michael Niedermayer 07master:d3512a0e8926: avcodec/x86/lossless_audiodsp: fix fallback code for 32bit
[21:18] <Gramner> kierank: don't you mean to load from r1 and r2, not r2 and r3?
[21:18] <kierank> lol
[21:18] <kierank> yeah
[21:18] <kierank> thanks
[21:18] <ubitux> please use named argument...
[21:18] <ubitux> that really helps readability
[21:19] <kierank> I don't know how to use those
[21:19] <kierank> is there any documentation?
[21:19] <ubitux> in the x264 header
[21:19] <Gramner> http://git.videolan.org/?p=x264.git;a=blob;f=common/x86/x86inc.asm;hb=HEAD#l98
[21:19] <Gramner> documentation
[21:19] <michaelni> kurosu, if theres some fixable problem with the padding and you think its better then iam happy to revert the fallback
[21:21] <kurosu> michaelni, not really, I just misread the code and so was really trying to avoid what it did
[21:21] <kurosu> I don't think I'll provide anything better in the foreseeable future
[21:24] <kierank> ubitux: 
[21:24] <kierank> cglobal v210_planar_pack, 5, 5, 4, y, u, v, dst, width
[21:24] <kierank> libavcodec/x86/v210enc.asm:43: error: undefined symbol `width' (first use)
[21:24] <kierank> That's probably why I never used named args
[21:24] <ubitux> use with widthq or something
[21:24] <kierank> am I being stupid
[21:25] <ubitux> you need a suffix for usage
[21:25] <ubitux> like r2 ’ r2q
[21:25] <ubitux> width ’ widthd probably in your case
[21:25] <ubitux> assuming that's int
[21:25] <kierank> I've done movsxdifnidn r4, r4d though before
[21:25] <jamrial> instead of using movsxdifnidn, make width ptrdiff_t
[21:26] <ubitux> kierank: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/x86/pixelutils.asm;h=7522f24a42de84ef84d939af58f97272380c2efc;hb=HEAD#l110
[21:26] <ubitux> here are some simple examples
[21:27] <ubitux> (without any local variables but it's not much more complicated)
[21:27] <kierank> thanks
[21:28] <kurosu> use <arg>m also when the ABI doesn't pass the argument in a gpr but on the stack (long arg list usually)
[21:29] <kurosu> and, should the case arise, try avoiding using float parameters in your dsp prototype, the ABIs became wildly more protracted to handle
[21:31] <kierank> could well be an avconv bug but the pictures look the same but avconv only decodes 7/12 frames
[21:31] <kierank> who knows why...
[21:56] <ubitux> kierank: forgot a file?
[21:57] <ubitux> libavcodec/x86/v210enc_init.c or something
[21:57] <kierank> ubitux: ah true
[21:57] <kierank> and the asm itself...
[21:57] <ubitux> :)
[21:57] <ubitux> change HAVE_MMX while at it
[21:57] <ubitux> (with ARCH_X86)
[21:58] <kierank> too late
[21:58] <kierank> but changed locally
[21:58] <ubitux> (and coding style in v210_planar_pack_c but libav will surely point it out)
[21:59] <kierank> what about the style
[21:59] <ubitux> ( style )
[22:00] <kierank> ah
[22:00] <ubitux> r0+2*widthq  forgot to change one here
[22:00] <ubitux> anyway, that's all for meaningless review
[22:15] <kierank> ubitux: thx
[23:02] <kurosu> kierank, could you add the result of {START,STOP}_TIMER
[23:10] <kierank> kurosu: I need to find a file long enough to be significant
[23:11] <kurosu> true, and that's probably only me that wants that
[23:12] <kierank> I had the problem when benchmarking it myself
[23:14] <jamrial> it doesn't need to be too long to get at least a vague idea of how much faster it is
[23:16] Action: kierank downloads a file from Daemon404
[23:16] <cone-26> ffmpeg.git 03Matthew Oliver 07master:293fee4bc235: libavcodec/tiff: Fix static linking of lzma with msvc.
[23:17] <kurosu> hum, that's like raw ? you can probably append it to itself several times or the like
[23:29] <kierank> kurosu: 
[23:29] <kierank> C: 132635884 UNITS in test, 512 runs, 0 skips
[23:30] <kierank> 65324749 UNITS in test, 512 runs, 0 skips
[23:30] <kierank> asm
[23:31] <kierank> on Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz
[23:31] <jamrial> what are you using? odd that it used UNITS instead of decicycles
[23:32] <jamrial> msvc?
[23:32] <kierank> linux x64
[23:32] <kierank> using avconv btw
[23:33] <kurosu> kierank, ok, approximately halved
[23:33] <kurosu> I'm wondering if unrolling+interleaving twice would help
[23:34] <jamrial> ah yeah, timer.h in libav always uses "UNITS" it seems
[23:55] <kierank> kurosu: about 3 times faster on sandy bridge
[23:56] <kurosu> kierank, well that's unexpected
[23:56] <kurosu> does that still pass fate ?
[23:56] <kurosu> or whatever benchmark you set for yourself
[23:56] <kierank> don't think there is a fate test
[23:56] <kierank> since it's an encoder
[23:57] <kierank> 3 times faster asm compared to c i mean
[23:57] <kurosu> ah ok
[23:57] <ubitux> saste: signalstats provides this info
[23:57] <ubitux> saste: i'm actually working on making it faster right now btw
[23:57] <ubitux> might be useful to show it visually though..
[23:58] <kurosu> kierank, still 2/3 of the original asm, that sounds good (though on the high range of the gain I had expected)
[23:58] <ubitux> saste: could you add GRAY16 support?
[23:58] <kurosu> (I had expected at most, no gain could also have happened)
[23:59] <saste> ubitux, sure
[23:59] <kierank> kurosu: i'm not 100% sure it's bitexact
[23:59] <saste> ubitux, there is any way to use signalstat to show the computed values?
[23:59] <ubitux> saste: probably not yeah...
[23:59] <saste> the idea of tdiff is that it can be used to monitor things changing (e.g. for surveillance systems)
[00:00] --- Sun Nov 23 2014