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

[burek]

[00:32:21 CET] <ubitux> jamrial: damn, wtf is going on
[00:32:25 CET] <ubitux> no system error
[00:32:52 CET] <ubitux> jamrial: no system error though
[00:33:11 CET] <ubitux> like, no disk problem
[00:41:10 CET] <ubitux> i'll take a look maybe tmr
[00:52:35 CET] <ubitux> jamrial: i'm trashing the ccache cache for now, and upgrading rsync (maybe a sync failure of some sort)
[00:52:44 CET] <ubitux> anyway, thx for notifying
[02:00:27 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ?  I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ?
[02:00:38 CET] <prelude2004c> i have been for weeks looking for an answer .. can anyone help me with it ?
[02:05:21 CET] <J_Darnley> I guess nobody knows
[02:19:39 CET] <prelude2004c2> somebody knows.. and i get it's something simple :(
[09:31:16 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:b966a403dd80: avcodec/utils: fix AVPacket lifetime in seek_frame_generic
[10:19:07 CET] <cone-160> ffmpeg 03Kip Warner 07master:cc4c24208159: avresample: Mark avresample_buffer() as pointer to const
[10:19:08 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:d1262262de84: Merge commit 'cc4c24208159200b7aff5b5c313903c7f23fa345'
[10:21:00 CET] <cone-160> ffmpeg 03Stefan Pöschel 07master:dbce017913ce: mpegtsenc: add flag to embed an AC-3 ES the DVB way
[10:21:01 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:40231a58a0d8: Merge commit 'dbce017913ce04966021a2f72e4f8fae5b4b7190'
[10:25:49 CET] <cone-160> ffmpeg 03Janne Grunau 07master:50078c1c8070: libavutil: move FFALIGN macro from common.h to macros.h
[10:25:50 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:4cf66a81932a: Merge commit '50078c1c8070dd8d1c329e8117ff30ec72489039'
[10:33:22 CET] <cone-160> ffmpeg 03Janne Grunau 07master:64034849dad8: arm64: add cycle counter support
[10:33:23 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:af2e6f32156e: Merge commit '64034849dad8410bedbe1def4c533490fb85cc4a'
[10:46:37 CET] <cone-160> ffmpeg 03Janne Grunau 07master:5dfe4edad639: x86_64: int32_to_float_fmul_scalar sign extend integer length
[10:46:38 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:00e91d06767a: Merge commit '5dfe4edad63971d669ae456b0bc40ef9364cca80'
[11:06:34 CET] <cone-160> ffmpeg 03Janne Grunau 07master:e2710e790c09: arm: add a cpu flag for the VFPv2 vector mode
[11:06:35 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:e754c8e8caa7: Merge commit 'e2710e790c09e49e86baa58c6063af0097cc8cb0'
[11:10:50 CET] <nevcairiel> i hope all this arm stuff works, i have no way to test it :)
[11:11:00 CET] <cone-160> ffmpeg 03Janne Grunau 07master:c33c1fa8af2b: arm64: convert dcadsp neon asm from arm
[11:11:01 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:de3a33784cb7: Merge commit 'c33c1fa8af2b2e82418a06901b6ad17b3d61b73e'
[11:15:08 CET] <cone-160> ffmpeg 03Janne Grunau 07master:705f5e5e155f: arm64: port synth_filter_float_neon from arm
[11:15:09 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:10e075c13846: Merge commit '705f5e5e155f6f280a360af220fc5b30cfcee702'
[11:21:30 CET] <cone-160> ffmpeg 03Janne Grunau 07master:a0fc780a2093: arm64: int32_to_float_fmul neon asm
[11:21:31 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:e97e2588ca74: Merge commit 'a0fc780a2093784e8664f88205ee1b215e109cee'
[11:22:01 CET] <cone-160> ffmpeg 03Janne Grunau 07master:90b1b9350c0a: arm: add ff_int32_to_float_fmul_array8_neon
[11:22:02 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:e23c3a13e330: Merge commit '90b1b9350c0a97c4065ae9054b83e57f48a0de1f'
[11:22:15 CET] <cone-160> ffmpeg 03Andreas Cadhalpun 07master:17776638c392: opus: Fix typo causing overflow in silk_stabilize_lsf
[11:22:16 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:92ebe35d571e: Merge commit '17776638c392d104975aba169e17b186490e1d5e'
[11:22:26 CET] <cone-160> ffmpeg 03Andreas Cadhalpun 07master:5ea59b1f424f: exr: fix out of bounds read in get_code
[11:22:27 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:e40b33a9d79c: Merge commit '5ea59b1f424f0efc7805d837e6fdb80561fb0f3a'
[11:22:42 CET] <cone-160> ffmpeg 03Janne Grunau 07master:cc29d96d5a37: arm64: fix inverted register order in transpose_4x4H
[11:22:43 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:f00e12e630da: Merge commit 'cc29d96d5a379dbcf2649947d884c202c2a52767'
[11:53:45 CET] <durandal_1707> nevcairiel: finished with merges?
[11:53:51 CET] <nevcairiel> no
[11:54:30 CET] <nevcairiel> but i'm going to get some food after the next one if you want to push something
[11:55:53 CET] <cone-160> ffmpeg 03Janne Grunau 07master:711781d7a171: x86: checkasm: check for or handle missing cleanup after MMX instructions
[11:55:54 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:69ead86027d0: Merge commit '711781d7a1714ea4eb0217eb1ba04811978c43d1'
[11:55:56 CET] <nevcairiel> there
[12:01:14 CET] <j-b> atomnuker: all your code is done from scratch (for Daala)?
[12:19:30 CET] <cone-160> ffmpeg 03Andreas Cadhalpun 07master:c112be25f782: oggparsedaala: reject too large gpshift
[12:19:31 CET] <cone-160> ffmpeg 03Andreas Cadhalpun 07master:753930bc7300: doc: make apidoc output independent of SRC_PATH
[12:36:16 CET] <cone-160> ffmpeg 03Janne Grunau 07master:9d218d573f80: checkasm: add float comparison util functions
[12:36:17 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:0c7ade547ad8: Merge commit '9d218d573f8088c606d873e80df572582e6773ef'
[12:41:13 CET] <cone-160> ffmpeg 03Janne Grunau 07master:e71b747e9dc5: checkasm: add tests for dcadsp
[12:41:14 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:d882c0b9f9f1: Merge commit 'e71b747e9dc56cb84f8a06ec8214d5f3bd98bb6d'
[12:45:46 CET] <cone-160> ffmpeg 03Janne Grunau 07master:568a4323fbde: checkasm: add synth_filter test
[12:45:47 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:eb50a3d4409d: Merge commit '568a4323fbde03665b2b23a98068d02b39121812'
[12:50:55 CET] <cone-160> ffmpeg 03Janne Grunau 07master:489e6add4478: checkasm: add fmtconvert tests
[12:50:56 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:f299d8d9f283: Merge commit '489e6add4478b0f5717dbf644234c6f3a3baf02c'
[12:55:47 CET] <cone-160> ffmpeg 03Alexandra Hájková 07master:85990140e730: dca: Add math helpers.
[12:55:48 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:a51c2fcdc15d: Merge commit '85990140e7302d1e7fcc9fc0eea316178c19fe03'
[13:09:10 CET] <cone-160> ffmpeg 03Alexandra Hájková 07master:aebf07075f42: dca: change the core to work with integer coefficients.
[13:09:11 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:af1238f863fd: Merge commit 'aebf07075f4244caf591a3af71e5872fe314e87b'
[13:18:01 CET] <cone-160> ffmpeg 03Alexandra Hájková 07master:2008f7605490: dca: remove unused decode_hf function and quant_d tables
[13:18:02 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:d03da3e24020: Merge commit '2008f76054906e9ff6bf744800af0e5a5bfe61be'
[13:19:57 CET] <cone-160> ffmpeg 03Diego Biurrun 07master:5049f6b77289: rtpdec_jpeg: Coalesce redundant error checks
[13:19:58 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:8a04ddeb4704: Merge commit '5049f6b772891cdf4030a9d572362efc8f7ae97f'
[13:23:12 CET] <cone-160> ffmpeg 03Diego Biurrun 07master:69a68593ce56: Remove stray line breaks from avpriv_{report_missing_feature|request_samples}
[13:23:13 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:95a2b883e36d: Merge commit '69a68593ce5684409c3c4dd9a901bfd8b16925b1'
[13:26:23 CET] <cone-160> ffmpeg 03Janne Grunau 07master:f4f27e4cf101: x86: zero extend the 32-bit length in int32_to_float_fmul_scalar implicitly
[13:26:24 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:a9cd11b21295: Merge commit 'f4f27e4cf1013c55b2c7df359ce8d58ee922662c'
[13:27:06 CET] <cone-160> ffmpeg 03Janne Grunau 07master:f0f54117c8f2: checkasm: x86: post commit review fixes
[13:27:07 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:0eefc758e23e: Merge commit 'f0f54117c8f206e8045d301c2eb975b26e9f263d'
[13:28:07 CET] <cone-160> ffmpeg 03Janne Grunau 07master:8563f9887194: x86: use emms after ff_int32_to_float_fmul_scalar_sse
[13:28:08 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:2214207d0481: Merge commit '8563f9887194b07c972c3475d6b51592d77f73f7'
[15:27:21 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ?  I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ?
[17:12:43 CET] <ubitux> h264 decoder doesn't compile anymore with -DTRACE
[17:57:23 CET] <cone-553> ffmpeg 03Alexandra Hájková 07master:40d949677335: dca: use defines for subband related constants
[17:57:24 CET] <cone-553> ffmpeg 03Hendrik Leppkes 07master:7fe77aa62ea2: Merge commit '40d949677335a564f769823f4afdb7e7a3da8d6b'
[18:52:53 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:8bcd1997eadb: avfilter/vf_zoompan: do not free frame we pushed to lavfi
[18:53:47 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:7f7a9dd78227: avfilter/avf_showspectrum: store win_size in private context and calculate it only once
[18:53:48 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:72280d1c6caa: avfilter: add showspectrumpic filter
[18:53:49 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:9b06e7befaa7: avfilter/avf_showspectrum: add fiery color map
[18:53:50 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:d35c029cbf3a: avfilter/avf_showspectrum: fix null pointer dereference if allocation fails
[18:53:51 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:2b172cb6256f: avfilter/avf_showspectrum: make some helper functions
[18:53:52 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:af018d802d5f: avfilter/avf_showspectrum: add 4th and 5th root scaler
[19:03:07 CET] <BtbN> Great, just noticed that decoding vp8 via vaapi uses more CPU than plain lavc decoding on the CPU.
[19:03:18 CET] <BtbN> Or whatever gst uses for it
[19:04:10 CET] <Daemon404> A+
[19:06:26 CET] <rcombs> is it one of those "hybrid" decoders
[19:06:33 CET] <BtbN> Nope
[19:06:47 CET] <BtbN> Well, at least it's in the main intel driver, can't tell how it's implemented
[19:07:08 CET] <rcombs> I thought there were hybrid decoders in the main intel driver
[19:07:32 CET] <BtbN> iirc they are all(?) in a second driver, which it chainloads
[19:07:52 CET] <rcombs> oh
[19:07:54 CET] <rcombs> well that then
[19:10:15 CET] <cone-553> ffmpeg 03Hendrik Leppkes 07master:51da00e24cb0: dca: adjust decoding of the XBR extension for integer core decoding
[19:10:16 CET] <cone-553> ffmpeg 03Hendrik Leppkes 07master:b95cba7b3c82: avcodec/dca: remove unused float quant table
[19:10:17 CET] <cone-553> ffmpeg 03Hendrik Leppkes 07master:957667d19854: avutil/cpu: add missing entry for vfp_vm to av_parse_cpu_caps
[19:26:20 CET] <atomnuker> BBB_: RFCv5 is on the ML, all should be fine with it now
[19:26:58 CET] <BBB_> famous last words
[19:27:41 CET] <BBB_> BtbN: well, vp8 decoding is ridiculousy trivial :D
[19:28:17 CET] <BtbN> filling the VAAPI input surface is propably more cpu intensive than decoding it...
[19:28:29 CET] <nevcairiel> BBB_: i merged some checkasm changes today which check if a mmx function issues emms, and it complained that plenty vp9 functions should be using emms .. so i told it that its intentional  that it doesnt to fix  fate .. but I would feel better if you could confirm that for me :)
[19:28:34 CET] <fritsch> why did I expect something like that again BtbN 
[19:28:35 CET] <fritsch> hehe
[19:28:53 CET] <BBB_> uhm
[19:28:53 CET] <BBB_> wait
[19:28:58 CET] <BBB_> nevcairiel: why would anything ever call emms?
[19:29:05 CET] <nevcairiel> why wouldnt it
[19:29:18 CET] <nevcairiel> how is checkasm to know if your code uses float after mmx
[19:29:19 CET] <BBB_> nevcairiel: all video decoders in lavc* rely on the fact that we call emms at the end of avcodec_decode_videoN()
[19:29:30 CET] <BBB_> doing emms per function adds crazy unnecessary overhead
[19:29:36 CET] <BtbN> Well, it still doesn't use much, it's like 5% CPU usage when decoding it to a fake sink with gst.
[19:29:44 CET] <BBB_> I dont think we have any video decoders that use float internally
[19:29:47 CET] <BtbN> But decoding with lavc is less than 2%
[19:29:52 CET] <nevcairiel> then telling it that its ok this way was right =p
[19:29:52 CET] <BBB_> at least none that rely on integer simd
[19:29:53 CET] <BBB_> so ...
[19:29:57 CET] <BBB_> I think the assumption is ok
[19:30:10 CET] <BBB_> but youll have to add that assumption to all video decoder simd functions in checkasm
[19:30:15 CET] <BBB_> hevc, h264, etc.
[19:30:27 CET] <nevcairiel> the merge added it for h264, we dont have hevc checkasm
[19:30:31 CET] <jamrial> atomnuker: i'm not sure about the experimental flag. it's not like with encoders where we risk creating bad files that will forever haunt us
[19:30:32 CET] <BBB_> are there ever cases where the simd should call emms itself?
[19:30:37 CET] <jamrial> atomnuker: as long as it doesn't crash with valid (and invalid) input, even if the codec in question is not finalized it should be fine
[19:30:44 CET] <nevcairiel> some very generic simd functions, i suppose
[19:30:52 CET] <BBB_> nevcairiel: Id say that any video codec can have that assumption, if checkasm knows media types
[19:30:53 CET] <nevcairiel> stuff used for audio
[19:30:57 CET] <BBB_> (I guess it doesnt)
[19:31:12 CET] <jamrial> most players will not use a decoder that requires the experimental flag
[19:31:24 CET] <BBB> nevcairiel: but when generic stuff is used for video, we should still not call emms
[19:31:30 CET] <BBB> i.e. caller, not callee, should issue emms
[19:31:33 CET] <BBB> if you see what I mean
[19:31:38 CET] <BBB> the emms check seems bogus to me TBH
[19:31:40 CET] <BBB> but what do I know
[19:31:42 CET] <nevcairiel> that seems painfully easy to forget
[19:32:05 CET] <nevcairiel> really just screw mmx if you ask me, but shrug
[19:32:11 CET] <BBB> that too
[19:32:29 CET] <nevcairiel> i was surprised to see vp9 even had any
[19:32:57 CET] <jamrial> Gramner was planning on getting rid of mmx code from x264 since it looks like Intel may be about to deprecate the set
[19:33:01 CET] <BBB> well, stuff that acts on 8 pixels&
[19:33:16 CET] <nevcairiel> its doubtful they could ever actually remove mmx
[19:33:18 CET] <jamrial> seeing how it's slower on Skylake on purpose than previous cpus
[19:33:22 CET] <BBB> and mmx is still quite widely used
[19:33:24 CET] <nevcairiel> it would break everything
[19:34:28 CET] <atomnuker> jamrial: yeah, haven't done much fuzzing on the decoder yet, but it won't crash with the old/broken files I've tried
[19:35:48 CET] <atomnuker> AFL will find something, but it's ALF, it always does
[19:36:10 CET] <cone-553> ffmpeg 03Michael Niedermayer 07master:a30238621dd0: doc/encoders: Fix application name
[19:36:11 CET] <cone-553> ffmpeg 03Michael Niedermayer 07master:cccb0ffccc37: avcodec/put_bits: Always check buffer end before writing
[19:39:09 CET] <rcombs> what would "removing MMX" entail
[19:39:42 CET] <rcombs> isn't a bunch of the SSE stuff basically extensions of MMX instructions to 128 bits
[19:39:46 CET] <nevcairiel> they probably removed some execution hardware on skylake to save die space, thats why its s lightly slower
[19:39:48 CET] <Gramner> i don't thunk i'm going to get rid of mmx
[19:39:55 CET] <jamrial> freeing opcodes, maybe. also simpler die?
[19:40:02 CET] <Gramner> but maybe replace some functions that use instructions that are slow
[19:40:46 CET] <nevcairiel> if data sets are too small its probably not  going to like using sse instead, huh
[19:41:24 CET] <J_Darnley> movq/movd into xmm isn't that bad is it?
[19:43:10 CET] <nevcairiel> rcombs: the big difference with sse is that it uses its own dedicated registers, while mmx shares its registers with the fpu
[19:43:22 CET] <Gramner> nevcairiel: jannau's checkasm emms patch should only check if emms is used in functions that specify that they should issue emms
[19:43:39 CET] <Gramner> so you might have botched the merge
[19:43:50 CET] <nevcairiel> the implementation is the other way around however
[19:44:00 CET] <nevcairiel> it specifically checks that on every function unless told otherwise
[19:44:55 CET] <rcombs> oh huh, so the instructions have the same mnemonics but are actually totally different?
[19:45:02 CET] <Gramner> doesn't it only check for emms in functions that use declare_new_emms()?
[19:45:26 CET] <nevcairiel> if that would be true, then simply merging shouldnt have caused the old vp9 tests to start saysing "didnt issue emms"?
[19:45:46 CET] <nevcairiel> because they all did :d
[19:46:23 CET] <Gramner> the merge commit itself did that
[19:46:30 CET] <Gramner> https://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=tests/checkasm/vp9dsp.c;h=931f7882b5b317482298c7e58f1e5216f8c78d54;hp=c1e13764e20a5de3267d5c5d3e2a8b1cb5390256;hb=69ead86027d04e8f1dacd7b63eb936f62a8e0c6a;hpb=f00e12e630da2b82dac42eb54ad9aa91d800aacd
[19:46:43 CET] <nevcairiel> apparently the reason for this is that it would otherwise prevent testing floating point code
[19:47:00 CET] <nevcairiel> well yes, i added those
[19:47:04 CET] <nevcairiel> without those changes, it fails
[19:47:33 CET] <Gramner> huh, that's interesting. what failed?
[19:47:55 CET] <nevcairiel> all the vp9 tests in those blocks
[19:47:55 CET] <Gramner> I don't think that patch should change the behavior of old stuff
[19:48:00 CET] <nevcairiel> but it did
[19:48:21 CET] <Gramner> then there's probably a bug somewhere
[19:48:42 CET] <nevcairiel> same reason the h264 pred tests got the call changed to declare_func_emms
[19:49:04 CET] <nevcairiel> those functions clearly dont issue an emms
[19:50:38 CET] <Gramner> oh, I think the code is backwards
[19:52:33 CET] <Gramner> I'll poke jannau about it
[20:04:36 CET] <cone-553> ffmpeg 03Andreas Cadhalpun 07master:2e752c7de9df: ffmdec: change type of state and id to unsigned
[20:29:21 CET] <cone-553> ffmpeg 03James Almer 07master:78129978f02f: configure: bump copyright year to 2016
[20:29:25 CET] <jamrial> :D
[20:31:59 CET] <durandal_1707> nooooo!!!
[20:50:27 CET] <atomnuker> durandal_1707: would it be possible to add a scale to showspectrumpic?
[20:50:57 CET] <atomnuker> (e.g. duration in seconds vs amplitude in db)
[21:10:07 CET] <durandal_1707> atomnuker: as one in sox default?
[21:11:57 CET] <durandal_1707> the legend
[21:12:54 CET] <atomnuker> yeah
[21:13:58 CET] <atomnuker> I'm not sure what functions are available to draw text, but you could probably get away by using ff_draw_pc_font (fixed scale)
[21:22:44 CET] <durandal_1707> the font is bit bigger for my taste, perhaps using sox font is better looking imho
[21:25:07 CET] <atomnuker> well, that's what I know is currently in FFmpeg and doesn't require any dependency
[21:25:41 CET] <durandal_1707> yes, font is in lavu
[21:27:43 CET] <cone-553> ffmpeg 03Paul B Mahol 07release/2.7:784506c2b5c6: avfilter/vf_zoompan: do not free frame we pushed to lavfi
[21:27:44 CET] <cone-553> ffmpeg 03Paul B Mahol 07release/2.8:6a1bf98b3af1: avfilter/vf_zoompan: do not free frame we pushed to lavfi
[23:21:23 CET] <durandal_1707> This is gonna hurt
[23:22:24 CET] <kierank> durandal_1707: what is?
[23:25:04 CET] <durandal_1707> kierank: doing text/legend for showspectrumpic
[23:25:47 CET] <atomnuker> yeah, it will
[23:26:04 CET] <atomnuker> extreme resolutions tend to do that
[23:26:40 CET] <atomnuker> you can't expect proper labels when users can input something like 10000x10
[23:28:37 CET] <j-b> m
[23:29:55 CET] <ubitux> nice ffplay with sdl2
[23:45:16 CET] <durandal_1707> does it use opengl?
[00:00:00 CET] --- Sun Jan  3 2016