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

[burek]

[00:00:08 CEST] <jkqxz> nevcairiel:  <http://sprunge.us/CfMV>
[00:05:54 CEST] <jya> just upgraded to ubuntu 17.10, that wasted space in the top bar is awful :(
[00:09:23 CEST] <nevcairiel> jkqxz: seems fine
[00:09:26 CEST] <cone-945> ffmpeg 03Jun Zhao 07master:f31478ba1472: lavc/vaapi_encode_h264: correct VUI max_dec_frame_buffering setting
[00:09:27 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:5b2c71bb94d7: cbs_mpeg2: Fix type for marker_bit reading
[00:09:28 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:79d666aa5751: cbs_mpeg2: Fix format specifier
[00:09:29 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:59b00ffea3c9: cbs_h264: Fix format specifier
[00:10:48 CEST] <jkqxz> I started the push before you said that, just :P
[00:10:56 CEST] <jkqxz> How long do I have to wait for more feedback?
[00:11:17 CEST] <cone-945> ffmpeg 03Alexandra Hájková 07master:0b9a237b2386: hevc: Add NEON 4x4 and 8x8 IDCT
[00:11:18 CEST] <cone-945> ffmpeg 03James Almer 07master:c0683dce89ec: Merge commit '0b9a237b2386ff84a6f99716bd58fa27a1b767e7'
[00:11:19 CEST] <nevcairiel> it seems to runquite regularly
[00:12:39 CEST] <jkqxz> Right, yeah, it does.
[00:15:21 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:1bd986ed4b0e: hwcontext: Move NONE to the be the first member of AVHWDeviceType
[00:15:22 CEST] <cone-945> ffmpeg 03James Almer 07master:4e9dc52a9703: Merge commit '1bd986ed4b0e95ded368a8eeb5c044853c090f9b'
[00:18:28 CEST] <cone-945> ffmpeg 03Diego Biurrun 07master:5a969f64b9cf: jack: Drop support for old (2012) JACK versions
[00:18:30 CEST] <cone-945> ffmpeg 03James Almer 07master:6821b693ecce: Merge commit '5a969f64b9cf40bad923c73b66c3031b0018e848'
[00:20:10 CEST] <cone-945> ffmpeg 03Felicia Lim 07master:c8c995bc1ddc: libopus: Add channel mapping 2 support in libopusdec
[00:20:11 CEST] <cone-945> ffmpeg 03Michael Niedermayer 07master:617f0c65e1ba: ffserver: Fix off by 1 error in path
[00:20:12 CEST] <cone-945> ffmpeg 03Michael Niedermayer 07master:431eccd61e15: tests/ffserver.regression.ref: update checksums to what ffserver currently produces
[00:20:13 CEST] <cone-945> ffmpeg 03Zhong Li 07master:7e294a1f09a2: fate: add a test for mpeg2 issue of ticket #6677
[00:28:13 CEST] <cone-945> ffmpeg 03Martin Storsjö 07master:fbc6f190a618: arm: Always build the hevcdsp_init_arm.c file
[00:28:14 CEST] <cone-945> ffmpeg 03Martin Storsjö 07master:e788ca05a796: hevcdec: Use LOCAL_ALIGNED_* for declaring local variables with alignment
[00:28:15 CEST] <cone-945> ffmpeg 03Anton Khirnov 07master:6a9e331d79f8: dcadec: remove extra indirection
[00:28:16 CEST] <cone-945> ffmpeg 03Diego Biurrun 07master:163cc67beb3e: takdec: Use ISO C printf conversion specifiers where appropriate
[00:28:17 CEST] <cone-945> ffmpeg 03Martin Storsjö 07master:26d9b60373bf: hevc: Avoid using LOCAL_ALIGNED for 4 byte alignment
[00:28:18 CEST] <cone-945> ffmpeg 03James Almer 07master:d289f3febda2: Merge commit '163cc67beb3ed28aeb500c9a09df47c8df613025'
[00:28:19 CEST] <cone-945> ffmpeg 03James Almer 07master:953d55f4439b: Merge commit '26d9b60373bf45bc4f91ff6815f5fa36764d4d7b'
[01:15:18 CEST] <atomnuker> is there any way to force ffprobe to output to stdout?
[01:15:33 CEST] <BBB> 2>&1 ?
[01:15:42 CEST] <atomnuker> doesn't work
[01:15:52 CEST] <atomnuker> the { and } are printed on stdout
[01:16:11 CEST] <JEEB> if you use one of the output modes that's not the default one those should output to stdout
[01:16:12 CEST] <atomnuker> so 2>&1 makes the first output being the ffprobe body output
[01:16:15 CEST] <JEEB> like -of json
[01:16:24 CEST] <atomnuker> and then it ptints out { and } on new lines
[01:16:33 CEST] <atomnuker> they don't
[01:16:37 CEST] <JEEB> really?
[01:16:42 CEST] <JEEB> I know the default outputs to stderr
[01:16:55 CEST] <atomnuker> ffprobe -of json file > /dev/null
[01:17:01 CEST] <atomnuker> prints out the body
[01:17:05 CEST] <atomnuker> but not the { and }
[01:17:09 CEST] <JEEB> huh
[01:17:12 CEST] <JEEB> that's weird
[01:17:22 CEST] <JEEB> and that really sounds like a boog
[01:18:05 CEST] <JEEB> I mean, why would you output incorrect JSON over stdout and then put the curly braces into stderr :D
[01:19:32 CEST] <atomnuker> who maintains ffprobe? michaelni 
[01:19:34 CEST] <atomnuker> ?
[01:25:50 CEST] <atomnuker> how is it even outputting to stderr, no references to stderr anywhere in ffprobe.c
[01:41:27 CEST] <michaelni> atomnuker,  MAINTAINERS: ffprobe.c                             Stefano Sabatini
[01:47:19 CEST] <N0rdell> I am looking for the best way to copy an decode context to an encode context.  Right now I use 'avcodec_parameters_to_context': but its incompletely initialized; reference frames are set in the encode context... b frames... etc
[01:47:44 CEST] <N0rdell> I would like to somehow use the sps/pps to initialize the encode context completly
[01:47:58 CEST] <N0rdell> I wrote code by hand to do this prior to the 3.1 send/receive api
[01:48:45 CEST] <N0rdell> 'reference frames are NOT set' I mean
[02:00:09 CEST] <jamrial> atomnuker: av_log?
[02:06:21 CEST] <BBB> N0rdell: use sps/pps from decoder to initialize encoder? that makes no sense? are you trying to do a streamcopy?
[02:11:45 CEST] <N0rdell> @BBB not quite.  I am changing the video and want it reencoded with the exact parameters
[02:12:29 CEST] <BBB> I dont think thats as straightforward as youd like it to be ;)
[02:13:05 CEST] <N0rdell> @BBB yeah... ;)  Like I said prior to 3.1 I had hand written code to do this... broken moving to 3.3
[06:43:51 CEST] <wbs> jkqxz: about djgpp; int isn't 16 bit there, I think our code wouldn't even nearly work properly with a 16 bit int. the warnings you've seen probably come from the fact that uint32_t is typedeffed to unsigned long instead of unsigned int, and int != long even though they are the same size
[10:15:18 CEST] <nevcairiel> jkqxz: it seems to have passed now, so that seems to have been it
[11:00:20 CEST] <jya> who is the maintainer of the ffvp8 decoder?
[11:00:24 CEST] <jya> BBB?
[12:58:59 CEST] <J_Darnley> Gramner: I recall you talking about commits for Nasm regarding AVX-512 some time ago.  Did they all get committed?  Did they make it into a released version yet?
[13:07:47 CEST] <wbs> J_Darnley: x264 requires nasm 2.13 these days, afaik everything needed should be there
[13:08:15 CEST] <J_Darnley> okay, thanks
[19:59:46 CEST] <ubitux> https://gopro.com/news/gopro-open-sources-the-cineform-codec
[20:03:12 CEST] <jamrial> nice
[20:03:37 CEST] <ubitux> just discovered that today, so don't ask me for details ENOIDEA
[20:03:45 CEST] <ubitux> i can probably ask some ppl around though
[20:03:52 CEST] <TD-Linux> also available under apache 2.0 which includes a patent grant
[20:07:08 CEST] <Compn> LOL
[20:07:18 CEST] <Compn> wait until someone re'd the damn thing
[20:07:22 CEST] <Compn> open source it next week
[20:08:31 CEST] <ubitux> don't we already have it RE'd in FFmpeg?
[20:08:44 CEST] <JEEB> yea
[20:08:45 CEST] <ubitux> (isn't what lavc/cfhd is?)
[20:08:50 CEST] <nevcairiel> we do, but support is a bit limited, so maybe that can be much improved now
[20:34:05 CEST] <kierank> ubitux: not fully
[20:34:20 CEST] <kierank> a few samples not supported
[20:35:27 CEST] <kierank> https://github.com/gopro/cineform-sdk/blob/master/Codec/temporal.c
[20:35:28 CEST] <kierank> blimey
[20:37:22 CEST] <nevcairiel> \o/ intrinsics
[20:37:45 CEST] <nevcairiel> using cpu dispatch macros from gcc,  never seen those in use
[20:45:14 CEST] <kylophone> Anyone already started on getting this into libavcodec?: http://cineform.blogspot.com/2017/10/cineform-goes-open-source.html
[20:45:35 CEST] <kylophone> I'm going to take a crack at it unless someone else has already started
[20:46:06 CEST] <ubitux> we were just discussing it
[20:46:10 CEST] <kierank> Well we already have most of it
[20:46:23 CEST] <kierank> Apart from the 3d transform and the film scan stuff
[20:46:46 CEST] <kierank> I can send you the samples which don't play if you want
[20:48:41 CEST] <kylophone> Yeah, please do: k at ylo.ph
[20:49:48 CEST] <kierank> They are not emailable iirc
[20:50:14 CEST] <kylophone> K, let me know
[20:50:26 CEST] <kylophone> I won't have time to look at it until later tonight anyway
[20:53:18 CEST] <kierank> I am in the French countryside with near-zero connectivity
[21:21:55 CEST] <Compn> does anyone think they opensourced the whole thing that decodes the old samples ?
[21:21:59 CEST] <Compn> or just the newer spec stuff ?
[21:53:25 CEST] <cone-215> ffmpeg 03Dale Curtis 07master:50e30d9bb71e: Don't use _tzcnt instrinics with clang for windows w/o BMI.
[21:53:26 CEST] <cone-215> ffmpeg 03Michael Niedermayer 07master:e6debcaaed22: tools/target_dec_fuzzer: Fix build after FF_INPUT_BUFFER_PADDING_SIZE was removed
[21:53:27 CEST] <cone-215> ffmpeg 03Michael Niedermayer 07master:c23209f63d51: tools/target_dec_fuzzer: Fix build after AV_CODEC_CAP_HWACCEL_VDPAU was removed
[21:53:28 CEST] <cone-215> ffmpeg 03Kaustubh Raste 07master:2aab7c2dfaca: avcodec/mips: Improve avc put mc 11, 31, 13 and 33 msa functions
[21:53:29 CEST] <cone-215> ffmpeg 03Kaustubh Raste 07master:ce0a52e9e929: avcodec/mips: Improve avc chroma copy and avg vert mc msa functions
[21:53:30 CEST] <cone-215> ffmpeg 03Kaustubh Raste 07master:736a48901fa0: avcodec/mips: Improve hevc bi weighted hv mc msa functions
[21:53:31 CEST] <cone-215> ffmpeg 03Mateusz 07master:50ce2960263d: swscale: use dithering in DITHER_COPY only if not set -sws_dither none
[22:02:06 CEST] <durandal_1707> Compn: they opensourced because of your mail you sent to them
[22:16:22 CEST] <TD-Linux> Compn, you know you could find out in seconds
[22:22:07 CEST] <doublya> Is vaapi_mjpeg decode being added to FFmpeg anytime soon?
[22:22:47 CEST] <JEEB> I don't think anyone really cares about it, so unlikely to happen by itself
[22:23:08 CEST] <JEEB> mostly because pretty much anything with VAAPI can decode JPEG very quickly
[22:23:16 CEST] <JEEB> VAAPI being limited to x86
[22:23:57 CEST] <JEEB> most likely a patch would not be declined, of course. but just saying that it's not seemingly a priority for anyone around
[22:25:10 CEST] <doublya> Thanks
[23:11:22 CEST] <Compn> To Decode
[23:11:22 CEST] <Compn> Reverse all the steps.
[23:11:23 CEST] <Compn> lol
[23:12:02 CEST] <durandal_1707> Compn: what ?  where ?
[23:15:01 CEST] <Compn> There are also older bitstream formats supported by the SDK, even a 3D wavelet (volumetric, not steroscopic) from 2003 which compressed two frames into one crazy wavelet. There are old tools for handling interlaced that are quite different than progressive image encoding.
[23:15:28 CEST] <Compn> durandal_1707 : https://gopro.github.io/cineform-sdk/
[23:16:57 CEST] <durandal_1707> doesnt it provide full source ?
[23:17:13 CEST] <Compn> that was my question
[23:17:19 CEST] <Compn> newer cineform or just cfhd only
[23:18:11 CEST] <Compn> i mean older cineform or cfhd only
[23:19:49 CEST] <Compn> but from the description it looks like all\
[23:22:04 CEST] <durandal_1707> Compn: learn to code,  its never late
[23:22:28 CEST] <Compn> i bought some books
[23:23:21 CEST] <Compn> its kind of hard looking at the code for this as well, since it reuses the same fourcc...
[23:29:25 CEST] <kierank> ubitux: dunno how realistic it is but, if you could publicly or privately get samples, would be useful
[23:29:49 CEST] <ubitux> what kind of samples are you looking for?
[23:30:42 CEST] <Compn> durandal_1707 : but i can look at case 3 and case 4: and case 5: or whatever and see the different code paths. even if i dont know how to code i can read it
[23:32:48 CEST] <ubitux> don't try to read too much, write
[23:33:14 CEST] <Compn> bonus question
[23:33:28 CEST] <ubitux> you can read maths all your life and never be able to do shit; unless you practice, you won't learn how to read
[23:33:28 CEST] <Compn> is the gopro code faster than ours, on the parts we reuse with other codecs i mean ?
[23:35:50 CEST] <Compn> how do the asm compare : )
[23:36:17 CEST] <kierank> ubitux: mainly ones which use the 3d transform
[23:36:43 CEST] <kierank> I think I only have one of those
[23:37:16 CEST] <ubitux> so maybe with the 360 files?
[23:37:41 CEST] <ubitux> 360°
[23:37:57 CEST] <ubitux> or that's unrelated?
[23:38:04 CEST] <Compn> unrelated iirc
[23:39:56 CEST] <ubitux> kierank: the repository seems to include an encoder
[23:40:15 CEST] <ubitux> can't you use it to generate samples with various settings?
[23:40:51 CEST] <kierank> it's not clear to me whether you can generate 3d wavelet files with that encoder
[23:40:55 CEST] <kierank> but i guess i can ask the author
[23:41:09 CEST] <kierank> IRL he told me it was a hack at the time so the files could work on slow HDDs
[23:42:42 CEST] <atomnuker> tarkin did it first
[00:00:00 CEST] --- Thu Oct 26 2017