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

[burek]

[00:30:16 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:230c04e3f6d7: aiffdec: fix division by zero
[00:30:17 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:b3991ccd1170: astdec: fix division by zero
[00:30:18 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d4f64a0f545e: westwood_aud: prevent division by zero
[00:30:19 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d69dc10466e2: avformat: prevent triggering request_probe assert in ff_read_packet
[00:30:20 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:13f032abbb26: rsd: limit number of channels
[00:30:21 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:2c52b7498014: aiff: check block_align in aiff_read_packet
[00:30:22 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d77684b85305: dcstr: fix division by zero
[00:30:23 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:72f1701c92f7: cavsdec: unref frame before referencing again
[00:30:24 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:facf964d37ea: mpeg12dec: unref discarded picture from extradata
[00:30:25 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:5ede8a9d8c26: interplayacm: check for too large b
[00:30:26 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d6fbc7a2daf0: interplayacm: validate number of channels
[00:30:27 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:5a1433b19ab3: interplayacm: increase bitstream buffer size by AV_INPUT_BUFFER_PADDING_SIZE
[00:30:28 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:e3f671b10140: ppc: pixblockdsp: do unaligned block accesses correctly again
[00:30:29 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:cb0b8182448c: diracdec: check return code of get_buffer_with_edge
[00:30:30 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:1af13ea53930: lzf: update pointer p after realloc
[00:30:31 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:50d34cbf5ac8: mxfdec: fix NULL pointer dereference
[00:30:32 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:a40189348710: mpegaudio_parser: don't return AVERROR_PATCHWELCOME
[00:30:33 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:c19e9657049d: matroskadec: fix NULL pointer dereference in webm_dash_manifest_read_header
[00:30:34 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:e1c1cb4aa148: mpegts: prevent division by zero
[00:30:35 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:356e035773aa: icodec: fix leaking pkt on error
[00:30:36 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:6a7f0585ab19: icodec: add ico_read_close to fix leaking ico->images
[00:30:37 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:1499f65ad42a: escape124: reject codebook size 0
[00:30:38 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:727ec4acc471: proresdec_lgpl: explicitly check coff[3] against slice_data_size
[00:30:39 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:5c2e26275cb1: dvbsubdec: fix division by zero in compute_default_clut
[00:30:40 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:c35a140e7171: icodec: correctly check avio_read return value
[00:30:41 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:eaf79ac2d9c1: smvjpegdec: make sure cur_frame is not negative
[00:30:42 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:a5ba9eab44da: pnmdec: make sure v is capped by maxval
[00:30:43 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:52d8c1e474c3: filmstripdec: correctly check image dimensions
[00:30:44 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d000e66c4f2f: softfloat: handle -INT_MAX correctly
[00:30:45 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:89a22d3fbff3: libschroedingerdec: don't produce empty frames
[00:30:46 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:f70e9726dcad: libschroedingerdec: fix leaking of framewithpts
[00:30:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:71378e7937bd: exr: fix out-of-bounds read
[00:30:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:cb936d62664c: exr: reindent after previous commit
[00:30:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:b4f42e5c85f5: ffmdec: validate codec parameters
[00:30:50 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:315f1dea84a3: mxfdec: fix NULL pointer dereference in mxf_read_packet_old
[00:30:51 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:53e1493cb5a0: smacker: limit recursion depth of smacker_decode_bigtree
[00:30:52 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:e2de6f31c0db: rmdec: validate block alignment
[00:30:53 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:312757eb848b: sbgdec: prevent NULL pointer access
[00:30:54 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:9b506280dd9b: pgssubdec: only set w/h/linesize when allocating data
[00:30:55 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:d0f8741a5a29: flvdec: require need_context_update when changing codec id
[00:30:56 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:e70caba38480: libopusdec: default to stereo for invalid number of channels
[00:30:57 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:5d1502d4b68c: softfloat: decrease MIN_EXP to cover full float range
[00:30:58 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.1:072246993acb: mss2: only use error correction for matching block counts
[00:41:16 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:0009cf348aa8: avformat: prevent triggering request_probe assert in ff_read_packet
[00:41:17 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:1d439041ece0: cavsdec: unref frame before referencing again
[00:41:18 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:30d542d55ddb: mpeg12dec: unref discarded picture from extradata
[00:41:19 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:a1e6daeb1e92: interplayacm: check for too large b
[00:41:20 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:aa32d4152756: interplayacm: validate number of channels
[00:41:21 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:aca7f5f06077: interplayacm: increase bitstream buffer size by AV_INPUT_BUFFER_PADDING_SIZE
[00:41:22 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:087b77741526: ppc: pixblockdsp: do unaligned block accesses correctly again
[00:41:23 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:dcc8d2418aca: diracdec: check return code of get_buffer_with_edge
[00:41:24 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:ef2d91e9c337: lzf: update pointer p after realloc
[00:41:25 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e78d9f3f35e3: mxfdec: fix NULL pointer dereference
[00:41:26 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e6197a6ce986: mpegaudio_parser: don't return AVERROR_PATCHWELCOME
[00:41:27 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:5801482379cb: matroskadec: fix NULL pointer dereference in webm_dash_manifest_read_header
[00:41:28 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:3d82cebdd2bd: mpegts: prevent division by zero
[00:41:29 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:c3307f7e9e18: icodec: fix leaking pkt on error
[00:41:30 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:05e6606ba98a: icodec: add ico_read_close to fix leaking ico->images
[00:41:31 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e14cc2f1975b: escape124: reject codebook size 0
[00:41:32 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:416a8a06b977: proresdec_lgpl: explicitly check coff[3] against slice_data_size
[00:41:33 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:27888d13b8d3: dvbsubdec: fix division by zero in compute_default_clut
[00:41:34 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:3047b0a4a3e7: icodec: correctly check avio_read return value
[00:41:35 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:69673d02790f: smvjpegdec: make sure cur_frame is not negative
[00:41:36 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:b32c9941a21e: pnmdec: make sure v is capped by maxval
[00:41:37 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e93934e100d4: filmstripdec: correctly check image dimensions
[00:41:38 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:48496e4d4fad: softfloat: handle -INT_MAX correctly
[00:41:39 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:57665e04e22a: libschroedingerdec: don't produce empty frames
[00:41:40 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:4ffd5805af4a: libschroedingerdec: fix leaking of framewithpts
[00:41:41 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:1c282152c1c7: mxfdec: fix NULL pointer dereference in mxf_read_packet_old
[00:41:42 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:48d24cca1308: smacker: limit recursion depth of smacker_decode_bigtree
[00:41:43 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:80b85300ae0b: sbgdec: prevent NULL pointer access
[00:41:44 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:5d2f1ffef1f2: pgssubdec: only set w/h/linesize when allocating data
[00:41:45 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:dbad79248704: libopusdec: default to stereo for invalid number of channels
[00:41:46 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:88bf1d274962: softfloat: decrease MIN_EXP to cover full float range
[00:41:47 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:0496403c08ab: mss2: only use error correction for matching block counts
[00:41:48 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:45b18fbb9a77: rsd: limit number of channels
[00:41:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/3.0:e8ab2bd2ac85: dcstr: fix division by zero
[00:41:50 CET] <cone-780> ffmpeg 03Mark Harris 07release/3.0:9375a7d85e8b: avformat/icodec: Fix crash probing fuzzed file
[00:48:32 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:e14da0578c85: avformat: prevent triggering request_probe assert in ff_read_packet
[00:48:33 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:51ff17d6b993: cavsdec: unref frame before referencing again
[00:48:34 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:c5fb9df38aac: mpeg12dec: unref discarded picture from extradata
[00:48:35 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:a94f846e2dba: ppc: pixblockdsp: do unaligned block accesses correctly again
[00:48:36 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:0e8c44076d31: diracdec: check return code of get_buffer_with_edge
[00:48:37 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:0cc619e0d756: mxfdec: fix NULL pointer dereference
[00:48:38 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:f964046c58fb: mpegaudio_parser: don't return AVERROR_PATCHWELCOME
[00:48:39 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:3148d1c25f22: matroskadec: fix NULL pointer dereference in webm_dash_manifest_read_header
[00:48:40 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:b3ac458a5a20: mpegts: prevent division by zero
[00:48:41 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:dc821d42a2fd: escape124: reject codebook size 0
[00:48:42 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:5c55f9881ed0: proresdec_lgpl: explicitly check coff[3] against slice_data_size
[00:48:43 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:2260c0776ac6: dvbsubdec: fix division by zero in compute_default_clut
[00:48:44 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:8a56b31e7cd1: icodec: fix leaking pkt on error
[00:48:45 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:71fa32bbb747: icodec: correctly check avio_read return value
[00:48:46 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:f76947fd567f: smvjpegdec: make sure cur_frame is not negative
[00:48:47 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:0b948b1b8d10: pnmdec: make sure v is capped by maxval
[00:48:48 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:ccda73a711ba: softfloat: handle -INT_MAX correctly
[00:48:49 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:70ca4ce17a0a: libschroedingerdec: don't produce empty frames
[00:48:50 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:7552f6fc1bbb: libschroedingerdec: fix leaking of framewithpts
[00:48:51 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:8f27508f1cad: mxfdec: fix NULL pointer dereference in mxf_read_packet_old
[00:48:52 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:8a7b2fbf6f4d: smacker: limit recursion depth of smacker_decode_bigtree
[00:48:53 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:22cd4aa22116: sbgdec: prevent NULL pointer access
[00:48:54 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:56b120630fd2: libopusdec: default to stereo for invalid number of channels
[00:48:55 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:b45e112bbdcc: softfloat: decrease MIN_EXP to cover full float range
[00:48:56 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:028c87be95dd: mss2: only use error correction for matching block counts
[00:48:57 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:d8ec9e97b93e: filmstripdec: correctly check image dimensions
[00:48:58 CET] <cone-780> ffmpeg 03Andreas Cadhalpun 07release/2.8:970781f5f29d: Update Changelog
[01:50:59 CET] <Compn> https://en.wikipedia.org/wiki/Eggnog
[04:08:30 CET] <cone-849> ffmpeg 03Michael Niedermayer 07master:a06e84b56e93: avformat/utils: Fix type mismatch
[05:02:54 CET] <FishPencil> Can anyone point me in the direction of the code that handles decoding/playing hdmv_pgs subtitles (sup subtitles). They are found in blurays.
[05:18:51 CET] <Compn> FishPencil : 
[05:19:31 CET] <Compn> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/pgssubdec.c
[05:20:26 CET] <Compn> i think is what you want
[05:20:48 CET] <FishPencil> Yes, thank you
[05:24:18 CET] <FishPencil> I'm having a hard time finding an official specification for that format. Seems odd that the most popular bluray subtitle format is not documented
[05:42:37 CET] <kierank> FishPencil: iirc it's in the blu-ray spec
[05:42:39 CET] <kierank> which is not public
[06:25:19 CET] <Compn> FishPencil : we might be able to get you access to that spec
[06:25:21 CET] <Compn> if you need it
[06:29:21 CET] <FishPencil> Compn: Thanks, I'm getting by so far though.
[11:45:23 CET] <cone-894> ffmpeg 03Michael Niedermayer 07ffmpeg:HEAD: avformat/utils: Fix type mismatch
[11:46:15 CET] <cone-894> ffmpeg 03Paul B Mahol 07master:4719e563a423: avfilter/vf_zscale: export approximate gamma option and enable it by default
[11:47:41 CET] Action: michaelni looks at "<cone-894> ffmpeg Michael Niedermayer ffmpeg:HEAD: avformat/utils: Fix type mismatch" and wonders who and what  caused that
[11:48:58 CET] <BtbN> that's weird indeed
[11:51:46 CET] <michaelni> whoever did this: " * [new branch]      ffmpeg     -> origin/ffmpeg" <--- please dont do that and j-b please remove this branch
[11:54:47 CET] <durandal_1707> michaelni: i pushed to ffmpeg branch, stupid me
[11:54:59 CET] <durandal_1707> maybe that is
[11:55:56 CET] <michaelni> durandal_1707, if j-b doesnt remove it then please try to find another videolan root like thresh to get this cleaned
[11:59:31 CET] <durandal_1707> j-b, thresh: please remove ffmpeg branch from existence
[12:07:19 CET] <BtbN> can't it be removed remotely?
[12:13:38 CET] <durandal_1707> no, we are not alfa and omega of vlc
[13:05:35 CET] <nevcairiel> BtbN: destructive operations are forbidden, so no
[13:07:27 CET] <cone-894> ffmpeg 03Anton Khirnov 07master:6a4e24280dd7: configure: check for stdatomic.h
[14:18:45 CET] <cone-894> ffmpeg 03Michael Niedermayer 07master:bc9eb0467a52: Revert "ffserver: use AVStream.codecpar in open_input_stream()"
[14:18:46 CET] <cone-894> ffmpeg 03Michael Niedermayer 07master:9478bd87d463: ffserver: Remove extract_mpeg4_header()
[15:39:51 CET] <cone-894> ffmpeg 03Michael Niedermayer 07master:d9883ded3450: avcodec/me_cmp: Fix median_sad size
[17:08:46 CET] <nevcairiel> philipl: did you notice, they released video codec sdk 7.1
[17:11:04 CET] <nevcairiel> although it doesnt seem to include any new output formats
[17:11:53 CET] <BtbN> that's probably as pre-release as it gets
[17:13:17 CET] <nevcairiel> 7.1 changelog is pretty short, just some encoder optimizations
[17:13:26 CET] <nevcairiel> 8.0 is probably going to come with the next cuda release
[17:53:14 CET] <philipl> the feature matrix shows 10bit decoding.
[17:53:27 CET] <philipl> i will need to download and see the headers
[17:53:37 CET] <BtbN> still only NV12 in those
[17:53:50 CET] <philipl> feature matrix also shows vp8 10/12bit decoding. umm.....
[17:53:58 CET] <BtbN> well, decoding.
[17:54:04 CET] <BtbN> It can do that with only NV12 output
[17:54:49 CET] <philipl> vp8... not 9...
[18:04:43 CET] <philipl> They've added a cuvidInit(unsigned int flags) declarations with no docs and no flags.
[18:04:46 CET] <philipl> Hrm.
[18:10:59 CET] <BtbN> That's from their own dynloader, the function that loads the functions.
[18:11:07 CET] <BtbN> That's not new
[18:12:58 CET] <philipl> ah. ok.
[18:13:50 CET] <philipl> Then the only difference is some semi colons
[18:14:26 CET] <BtbN> yes, the headers seem unchanged
[18:14:40 CET] <BtbN> Maybe they forgot updating them...?
[18:15:41 CET] <philipl> A common problem, it seems.
[18:15:55 CET] <philipl> the programming guide wasn't updated and there is still no decode api reference.
[18:16:27 CET] <philipl> They've also redone their ffmpeg page. It now uses scale_npp in the examples and their multi-output stuff is a small section at the bottom.
[18:29:46 CET] <nevcairiel> the feature matrix showed 10bit and 12bit decoding before the update, they probably have the new woutput format in the 8.0 update which also gets high bitdepth encoding, or so they say
[18:39:45 CET] <philipl> I expect so.
[18:40:14 CET] <philipl> So this sdk update is basically pointless. They haven't documented or officially exposed most of the stuff that's in the new drivers.
[18:40:17 CET] <philipl> Why not just wait?
[18:42:00 CET] <nevcairiel> probably had it scheduled for a while
[18:42:03 CET] <nevcairiel> you know how these thigns go
[18:42:18 CET] <BtbN> it's even version 7.1.9
[18:57:02 CET] <philipl> Yeah. It's just amusing. Still, the web page feature matrix is better designed than the old one. That's a real improvement (modulo the strange claims about 10/12bit vp8)
[18:57:39 CET] <nevcairiel> maybe it works, the cuvid headers have vp8
[18:58:04 CET] <philipl> I wasn't aware 10/12 were defined for vp8.
[18:58:06 CET] <nevcairiel> although they probably meant vp9 and just missed the row
[18:58:22 CET] <philipl> That's what I hope. Certainly 10bit vp9 doesn't Just Work(tm) today.
[18:58:37 CET] <nevcairiel> 10-bit vp9 presumably needs a 1050
[18:58:52 CET] <nevcairiel> or 1050 Ti
[18:58:52 CET] <BtbN> oh great, that bullshitty situation again
[18:59:04 CET] <philipl> You know this? They rev'ed the decoder hardware again?
[18:59:24 CET] <nevcairiel> its not too special, 6 months older hardware gets a 6 month newer decoder
[18:59:29 CET] <philipl> or is that a cynical, but accurate, prediction?
[19:01:27 CET] <philipl> The linux driver readme, which is usually accurate about this stuff, lists the 1050 and 1050ti as using the same 'H' hardware as the other 10x0 parts.
[19:01:50 CET] <philipl> So I'll continue hoping the 10bit vp9 is in there somewhere.
[19:02:05 CET] <nevcairiel> all i know is that on the newest windows drivers, 10bit vp9 works on 1050, not any of the others
[19:02:09 CET] <nevcairiel> might be driver fluke
[19:02:13 CET] <philipl> ugh.
[19:02:16 CET] <nevcairiel> and appear next driver
[19:02:19 CET] <JEEB> \o/
[19:02:20 CET] <nevcairiel> or they typoed the linux readme
[19:02:26 CET] Action: JEEB just IYH'd himself a GTX 1080
[19:03:03 CET] <philipl> Hopefully it's lagging the driver. They put effort into this part of the readme. They document hardware revisions with features that aren't exposed in drivers.
[19:03:15 CET] <philipl> So I doubt they'd fudge it and call 1050 'H' if it's really 'I'
[19:03:32 CET] <nevcairiel> maybe the doc writer wasnt told
[19:03:40 CET] <philipl> but if that's what they did, then sad panda.
[19:04:09 CET] <philipl> when you say works in windows, do you mean with cuvid or dxva?
[19:04:14 CET] <nevcairiel> dxva
[19:04:19 CET] <nevcairiel> possibly cuvid as well, who knows
[19:04:27 CET] <nevcairiel> untested
[19:04:28 CET] <nevcairiel> :)
[19:04:38 CET] <philipl> Motivated enough to try it? It should all work correctly now.
[19:04:39 CET] <BtbN> you have a vp9 10 bit sample?
[19:04:44 CET] <JEEB> yeah, there's no real reason for CUVID nowadays
[19:04:45 CET] <philipl> any youtube hdr sample
[19:04:46 CET] <nevcairiel> i dont have a 1050 personally
[19:04:49 CET] <philipl> ah
[19:04:50 CET] <JEEB> DXVA2 works well enough
[19:05:22 CET] <philipl> JEEB: on windows :-)
[19:05:31 CET] <philipl> On linux, this is all we've got, given how vdpau is going nowhere.
[19:05:40 CET] <JEEB> yup
[19:07:29 CET] <fritsch> there is a chance for vdpau
[19:07:32 CET] <fritsch> a quite easy one
[19:07:42 CET] <fritsch> (besides the fact that it needs x11)
[19:08:06 CET] <fritsch> if ckoenig from amd or someone of us would add the 10 bit hevc variants
[19:08:13 CET] <fritsch> radeon could implement them first
[19:08:40 CET] <fritsch> problematic currently is the "interop" for presenting ... as it's 8 bit only and needs some internal driver logic to do the conversation
[19:08:46 CET] <philipl> fritsch: it would still require nvidia to put work into their own drivers.
[19:08:56 CET] <fritsch> the idea behind that is:
[19:08:59 CET] <fritsch> don't support nvidia :-)
[19:09:04 CET] <fritsch> just make vdpau great on radeon oss
[19:09:12 CET] <fritsch> they will do it themselves - I am quite sure
[19:09:32 CET] <fritsch> my experience from the past: force vendors to standards ... if not - you implement "yet another decoder"
[19:09:38 CET] <fritsch> especially on linux
[19:10:17 CET] <wm4> fritsch: at this point I'd rather have everything support libva
[19:10:36 CET] <fritsch> hehe - talk with ckoenig about vaapi
[19:10:39 CET] <philipl> wm4: that really is a sign of the apocalypse.
[19:10:46 CET] <fritsch> it's highly, highly tight to intel hw
[19:10:57 CET] <fritsch> for example mpeg-4 will never work on anything not intel
[19:11:17 CET] <BtbN> youtube-dl doesn't seem to be aware of the 10 bit formats
[19:11:22 CET] <BtbN> still get vp9 profile 0
[19:11:44 CET] <philipl> BtbN: youtube-dl -F tO01J-M3g0U
[19:11:48 CET] <philipl> see the vp9.2 entries
[19:12:01 CET] <philipl> Note you cannot let youtube-dl remux video+audio, it will drop the hdr metadata.
[19:12:06 CET] <nevcairiel> youtube-dlk works for me if you request the proper thing
[19:12:10 CET] <philipl> but the video stream has it
[19:12:48 CET] <BtbN> I should probably update it
[19:12:58 CET] <fritsch> wm4: and for libva no reply for the libdrm / mesa changes
[19:13:28 CET] <philipl> fritsch: I assume you continue to have no interest in cuvid support in kodi? With the dynamic loading approach, it could be done without introducing any external dependencies.
[19:13:51 CET] <fritsch> we don't have the manpower to maintain yet another decoder in kodi
[19:14:06 CET] <fritsch> if you send a PR it can be discussed obviously
[19:14:22 CET] <fritsch> we currently don't even have HW to finish vaapi 10 bit
[19:14:37 CET] <philipl> I've been contemplating it. Still trying to understand all the points you have to hook in
[19:14:39 CET] <fritsch> (render part), decoder is well done in ffmpeg
[19:14:49 CET] <philipl> each of the existing hwaccels is handled a bit differently from each other
[19:15:01 CET] <fritsch> for kodi the critical part is the rendering
[19:15:05 CET] <fritsch> "zero copy"
[19:15:06 CET] <fritsch> if possible
[19:15:14 CET] <fritsch> for vdpau we use glinterop
[19:15:23 CET] <fritsch> for vaapi we use drm / dma_buf / mesa
[19:15:29 CET] <fritsch> what would cuvid provide?
[19:15:35 CET] <philipl> It has its own glinterop
[19:15:39 CET] <philipl> I implemented it for mpv
[19:15:52 CET] <fritsch> how do you transfer the 10 bit surfaces?
[19:16:31 CET] <philipl> You get a P010 buffer in GPU memory from cuvid, then map your GL texture using interop and copy from one to the other.
[19:17:09 CET] <fritsch> can you link me to the code?
[19:17:50 CET] <philipl> https://github.com/mpv-player/mpv/blob/master/video/out/opengl/hwdec_cuda.c
[19:18:09 CET] <philipl> It's mostly surface bit depth transparent.
[19:18:38 CET] <BtbN> Just copy-back to system would be fine and trivial to implement
[19:18:53 CET] <fritsch> CUDA_MEMCPY2D <-
[19:18:55 CET] <philipl> As a first pass, yes.
[19:19:01 CET] <fritsch> that looks like a deep copy
[19:19:04 CET] <philipl> It is.
[19:19:09 CET] <fritsch> we don't want that :-)
[19:19:12 CET] <philipl> zero-copy is massively complicated
[19:19:21 CET] <BtbN> it's impossible to avoid one copy out of the mapped buffer
[19:19:33 CET] <philipl> Technically it's two copies today.
[19:19:44 CET] <fritsch> which hw supports cuvid?
[19:19:46 CET] <philipl> could be reduced to one but it's too much work and requires a new pix_fmt in avcodec
[19:19:46 CET] <fritsch> which nvidia?
[19:19:54 CET] <BtbN> all?
[19:19:59 CET] <philipl> all recent.
[19:20:01 CET] <philipl> kepler+
[19:20:12 CET] <BtbN> Everything that runs a recent driver
[19:20:14 CET] <fritsch> we still need to run on GT520 or higher
[19:20:20 CET] <fritsch> ION-2 would also be great
[19:20:28 CET] <philipl> vdpau covers those.
[19:20:30 CET] <fritsch> and i am quite sure ION-2 is not fast enough to do the copy
[19:20:40 CET] <fritsch> yeah - then we need to maintain yet another codec
[19:20:41 CET] <philipl> cuvid is only interesting if the hardware is new enough to have features outside the vdpau set
[19:20:48 CET] <philipl> yes. but you need that for radeon, right? :-P
[19:21:14 CET] <fritsch> in 2k16 with all the infrastructure available it feels wrong to support yet another blob
[19:21:23 CET] <fritsch> and gpu intensive copies
[19:21:37 CET] <BtbN> the copy is basically free
[19:22:13 CET] <nevcairiel> on-gpu copies are indeed rather cheap
[19:22:48 CET] <philipl> cheap enough that BtbN and nevcairiel think I'm crazy for doing all the work I did to demonstrate how to eliminate one of the copies.
[19:22:57 CET] <nevcairiel> indeed =p
[19:23:44 CET] <BtbN> For kodi it would be trivial to add basic support for cuvid decoding. Just treat it as software decoder with a diffrent name.
[19:24:20 CET] <fritsch> oki - if you want to implement that - we can discuss it on github
[19:24:22 CET] <BtbN> I don't think more is really possible anyway, as it needs CUDA SDK function
[19:25:02 CET] <philipl> BtbN: what do you mean 'more'? More than software decoding?
[19:25:25 CET] <philipl> dynlink works just fine for the interop stuff. I added that to mpv too
[19:25:28 CET] <philipl> Shouldn't need sdk
[19:25:47 CET] <philipl> Certainly on linux, I don't need sdk installed.
[19:25:57 CET] <BtbN> but you need function from CUDA
[19:26:02 CET] <BtbN> to map it to a texture and stuff
[19:26:08 CET] <BtbN> which is in the licensed header
[19:26:43 CET] <philipl> BtbN: yes. and just like the you did for the basic calls, they can be reverse-engineered from the docs
[19:27:01 CET] <fritsch> basically for vdpau (for the basics)
[19:27:07 CET] <fritsch> we need: two defines
[19:27:36 CET] <BtbN> cuvid does not work like vdpau. It's implemented as complete decoder, no hwaccel
[19:27:59 CET] <philipl> more like mediacodec than anything else.
[19:28:12 CET] <fritsch> mediacodec :-)
[19:28:22 CET] <fritsch> some of us think about using ffmpeg's mediacodec in the future
[19:29:48 CET] <philipl> probably a good idea now that it's actually functional.
[19:33:04 CET] <philipl> but yeah, to BtbN's point - even without interop, it makes a big difference. On my skylake i7 rig with mpv playing 10bit hevc: cuvid+interop: 25%, cuvid-only: 90%, software: 600% and too slow to actually play.
[19:33:42 CET] <JEEB> and with HEVC that's probably even bigger for sw
[19:33:50 CET] <JEEB> since the VP9 decoder has gotten quite a bit of love
[19:33:55 CET] <JEEB> as far as asm goes
[19:34:54 CET] <philipl> JEEB: indeed. a vp9 10bit sample is 250% for software decoding.
[19:35:33 CET] <fritsch> philipl: yes - I am well aware
[19:35:40 CET] <fritsch> we can better copy than decode
[19:35:59 CET] <wm4> fritsch: did you end up using ffmpeg's videotoolbox support?
[19:36:06 CET] <fritsch> yes
[19:36:13 CET] <fritsch> I think so at least
[19:36:17 CET] <fritsch> on ios afaik
[19:36:23 CET] <fritsch> let me have a look
[19:36:34 CET] <ubitux> you shouldn't use ffmpeg's VT support for iOS
[19:36:47 CET] <ubitux> it's not fast enough
[19:36:55 CET] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VTB.cpp
[19:37:05 CET] <ubitux> like, about half the performances you should expect from it
[19:38:46 CET] <fritsch> i am not really informed what they use on ios
[19:39:42 CET] <fritsch> but can't find anything else
[19:41:09 CET] <wm4> ubitux: isn't that because of async mode
[19:41:10 CET] <fritsch> we dropped our own baked one, yes
[19:41:13 CET] <fritsch> https://github.com/xbmc/xbmc/commit/ebefcd0c62689579b6c013e5d1b32f58cea23b37
[19:41:17 CET] <ubitux> wm4: yes that's the sole reason
[19:41:27 CET] <fritsch> and use ffmpeg's one - without many compliants
[19:41:45 CET] <wm4> ubitux: the painful thing is that the hwaccel impl. (probably) can't be made async...
[19:42:03 CET] <ubitux> yes i'm aware of the issue
[19:42:24 CET] <ubitux> alternative is to have packet reordering in a decoder
[19:42:30 CET] <fritsch> let me ask a dump question: is that a problem, when decoder and render are run in different threads?
[19:42:40 CET] <fritsch> for our use case
[19:43:18 CET] <ubitux> shouldn't be a problem with VT
[19:43:56 CET] <fritsch> as we really got no one complaining
[19:44:07 CET] <mateo`_> same for mediacodec
[19:44:14 CET] <ubitux> you can't decode 240 fps with ffmpeg's vt
[19:44:22 CET] <fritsch> we don't need that
[19:44:23 CET] <ubitux> not sure you can even hold 120 fps
[19:44:35 CET] <ubitux> well, the iphone supports it
[19:44:48 CET] <fritsch> yeah - see we are a video player
[19:44:58 CET] <fritsch> and render thread is driven by vblank
[19:45:21 CET] <fritsch> but yeah, the more the better of course :-)
[19:45:22 CET] <ubitux> if you want to play 240 fps in real time you have to drop ref frame
[19:45:39 CET] <wm4> fritsch: no, not a problem with different render threads
[19:45:52 CET] <wm4> but that the VT decoder operates most efficiently in async mode
[19:45:54 CET] <wm4> for whatever reason
[19:45:54 CET] <fritsch> ubitux: obviously clear - I just tried to make up a reason - why no one complained yet
[19:46:22 CET] <ubitux> if you capture a 240 fps footage with the iphone and can't play it back it's problematic
[19:46:30 CET] <wm4> and we use the hwaccel infrastructure with VT (for frame reordering basically), which can't be made async
[19:46:31 CET] <ubitux> play it back in real time that is
[19:46:34 CET] <ubitux> not slowmo
[19:46:40 CET] <fritsch> jep - I hear you
[19:46:53 CET] <fritsch> if I give the same guy a 300 fps footage
[19:46:59 CET] <fritsch> he also can't watch it :-)
[19:47:10 CET] <ubitux> except the iphone actually creates 240 fps footages
[19:47:28 CET] <fritsch> so you decode the 240 fps
[19:47:29 CET] <ubitux> so you're saying users can't watch videos they capture with the same device
[19:47:32 CET] <fritsch> and render 60 fps?
[19:47:39 CET] <fritsch> e.g. you skip quite intelligently?
[19:47:39 CET] <ubitux> you can't decode @ 240 fps
[19:47:47 CET] <ubitux> with ffmpeg's VT
[19:47:49 CET] <fritsch> jep
[19:48:01 CET] <ubitux> (unless you drop ref frame)
[19:48:01 CET] <fritsch> you can with the async code and so on
[19:48:25 CET] <fritsch> currently I have no problem stating, that kodi can only do 120 fps
[19:48:28 CET] <fritsch> with vtb
[19:49:11 CET] <wm4> so I wonder why vtb needs this async mode
[19:49:11 CET] <fritsch> we are happy for every ffmpeg hwaccel codec that allows us dropping on own hacks
[19:49:30 CET] <fritsch> as kodi is running out of devs :-(
[19:49:31 CET] <wm4> oh, another problem: deinterlacing
[19:49:46 CET] <fritsch> i think we support "render bob"
[19:49:52 CET] <fritsch> ugly :-)
[19:49:58 CET] <fritsch> but better than nothing
[19:50:10 CET] <wm4> heh
[19:50:22 CET] <fritsch> that's funny with mediacodec btw.
[19:50:29 CET] <wm4> vtb apparently does hw deint in the decoder
[19:50:30 CET] <fritsch> they don't even support interlace in any documentation
[19:50:32 CET] <wm4> which is hitler
[19:50:45 CET] <fritsch> ...
[19:51:06 CET] <ubitux> they do pixel format convert too
[19:51:25 CET] <wm4> oh I think rcombs found out how to determine the native VT pixfmt
[19:51:30 CET] <ubitux> (and scaling)
[19:51:34 CET] <wm4> have to ask him about that later
[19:51:44 CET] <ubitux> oh? that's interesting
[19:51:44 CET] <BtbN> cuvid also deinterlaces in the decoer.
[19:52:07 CET] <wm4> ubitux: especially because the ideal pixfmt changes with the hw
[19:52:17 CET] <wm4> older hw apparently prefers packed yuv
[19:52:19 CET] <ubitux> i'm and the footage i suppose
[19:52:39 CET] <wm4> I wonder if vtb will support 10 bit
[19:52:51 CET] <wm4> btw. why the fuck does apple not have its own consumer videocodec yet?
[19:52:54 CET] <nevcairiel> its always funny how apple manages to make everything special
[19:52:59 CET] <wm4> since they NIH everything anyway
[19:53:17 CET] <ubitux> they NIH *badly* everything
[19:54:14 CET] <philipl> BtbN: do you have coverity access?
[19:54:30 CET] <BtbN> Not that I'm aware of
[19:54:46 CET] <philipl> michaelni: can you add BtbN?
[19:54:59 CET] <BtbN> Isn't that in pretty bad shape at the moment anyway?
[19:55:02 CET] <philipl> There are a few warnings coming back for the cuda related parts
[19:55:17 CET] <philipl> It is, based on the email but the results are meaningful when a report does get generated.
[19:55:24 CET] <michaelni> BtbN, i need an emai addy to add IIRC
[19:55:39 CET] <BtbN> timo at rothenpieler.org
[19:55:58 CET] <philipl> michaelni: https://scan.coverity.com/travis_ci
[19:56:20 CET] <philipl> Maybe we can set up travis for ffmpeg and have that run coverity for us
[19:57:13 CET] <michaelni> BtbN, invite sent
[20:01:54 CET] <BtbN> It claims ctx in cuvid_transcode_init leaks its storage
[20:01:57 CET] <BtbN> but it doesn't.
[20:02:56 CET] <michaelni> 50-60% or so what coverity says is probably wrong
[20:03:16 CET] <philipl> BtbN: There is a path through there that leaks it. The question is whether you'd ever hit that path.
[20:03:34 CET] <philipl> line 99: it allocates ctx
[20:04:03 CET] <philipl> if ctx->hw_frames_ctx was not null, it would leak it.
[20:04:13 CET] <philipl> but if you allocated ctx, then hw_frames_ctx must be null
[20:04:18 CET] <philipl> I'm surprised it can't pick that up
[20:04:24 CET] <philipl> probably because of av_mallocz
[20:04:49 CET] <philipl> If it was using calloc, it would probably know
[20:05:36 CET] <philipl> There's probably a way to tell coverity what av_mallocz is.
[20:05:36 CET] <BtbN> it seems to be aware of that being an allocation function
[20:05:36 CET] <michaelni> maybe something needs to be added to tools/coverity.c (and the new file uploaded)
[20:05:55 CET] <philipl> yeah.
[20:05:58 CET] <philipl> for mallocz
[20:06:12 CET] <BtbN> ah, but it's not aware that stuff in ctx will allways be zero if it comes out of that branch
[20:06:22 CET] <BtbN> so it will allways be entered when it was allocated previously
[20:06:43 CET] <philipl> right.
[20:06:44 CET] <BtbN> yeah, it's going through a path that's impossible
[20:06:56 CET] <philipl> Let me update coverity.c
[20:07:15 CET] <BtbN> to tell it av_mallocz returns zero initialized stuff?
[20:07:26 CET] <philipl> yep
[20:07:47 CET] <philipl> and we probably should mark that av_free should be used to free this stuff.
[20:07:52 CET] <philipl> I've found examples.
[20:08:14 CET] <BtbN> The one in hwcontext_cuda seems right
[20:10:03 CET] <superware> hello, this defect https://trac.ffmpeg.org/ticket/5615 is quite old, although it's very easy to reproduce, any idea why it wasn't touched at all? :|
[20:12:25 CET] <nevcairiel> issues get fixed as someone is interested in working on them
[20:15:48 CET] <superware> yes well, anyone interested? :)
[20:40:51 CET] <superware> nevcairiel: can you please reproduce this? simply open a non-existing UDP input such as udp://127.0.0.1:8000 and avformat_open_input will hang...
[20:43:01 CET] <BtbN> well, it will wait for packets
[20:46:20 CET] <superware> BtbN: but it doesn't return even when interrupt_callback.callback returns 1..
[20:46:42 CET] <cone-713> ffmpeg 03Clément BSsch 07master:5d7be07a8b82: lavfi/f_ebur128: relicense to LGPL
[20:48:13 CET] <superware> "During blocking operations, callback is called with opaque as parameter. If the callback returns 1, the blocking operation will be aborted."
[20:49:22 CET] <BtbN> If it's stuck in system io without a defined timeout, nothing will get it out of that easily
[20:50:09 CET] <nevcairiel> superware: i am not interested in network stuff, so no
[20:51:11 CET] <superware> BtbN: well, a) interrupt_callback.callback IS being repeatedly called, b) you might have just described the bug source :)
[20:51:24 CET] <superware> nevcairiel: ok, thanks anyway
[20:53:17 CET] <kierank> you've got to use thread cancellation for that
[20:53:53 CET] <kierank> or better still nonblocking io
[20:54:52 CET] <superware> I have no idea what avformat_open_input is doing with "udp://127.0.0.1:8000"
[20:57:06 CET] <kierank> waiting for udp packets I guess
[20:58:08 CET] <superware> can you please take a look at why interrupt_callback.callback returning 1 doesn't abort it?
[20:58:23 CET] <kierank> no
[21:01:04 CET] <superware> oh well
[21:05:48 CET] <superware> thanks anyway, bye
[22:04:30 CET] <Chloe> philipl: travis on GH is great fun
[22:13:31 CET] <philipl> Chloe: is that actual fun or sarcastic fun?
[22:13:53 CET] <Chloe> I think it's actual fun, it works the most out of all the CIs.
[22:14:54 CET] <BtbN> it might be kind of annoying to setup all the dependencies on there every single time
[22:15:06 CET] <BtbN> specially as they run on quite outdated ubuntu versions
[22:15:29 CET] <Chloe> trusty isn't *that* old
[22:15:49 CET] <philipl> It's just part of the yaml file. There's a ppa that has all the dependencies in it.
[22:15:53 CET] <BtbN> oh, they finally arrived in 2014?
[22:15:59 CET] <philipl> Two weeks ago
[22:16:14 CET] <BtbN> Should have just gone for 16.04 right away
[22:16:21 CET] <philipl> anyway, it's worth a try. Keeping a hardware box alive for this is nuts in this day and age.
[22:16:41 CET] <philipl> BtbN: indeed. 2.5 years to update is nuts.
[22:17:12 CET] <BtbN> could also just run your own docker image on it
[22:17:35 CET] <philipl> yes, but I wouldn't do that if I could get their trusty container to work. Simpler and faster
[22:18:00 CET] <BtbN> docker is probably faster
[22:18:06 CET] <BtbN> it comes pre-installed and it's just a single command
[22:20:32 CET] <philipl> they are presumably using docker for their container build environment.
[22:20:55 CET] <philipl> dont want to nest or force the use of a vm to host the container.
[22:22:06 CET] <Chloe> philipl: they use docker by default, but you can ask for a VM
[22:22:57 CET] <BtbN> from my experience, the VMs run better and a lot faster
[22:23:03 CET] <BtbN> And you can then run your own docker container on it.
[22:25:32 CET] <Chloe> The docker configured & built FFmpeg in 3min50sec, which is pretty good IMO.
[22:25:41 CET] <Chloe> travis' docker*
[22:28:17 CET] <BtbN> it's about preparing all the dependencies it needs for the coverity run
[22:34:30 CET] <philipl> well, i'll try it out once i get access
[22:35:29 CET] <Chloe> you don't need access to try it out
[22:36:19 CET] <BtbN> well, you can only set it up with a fork
[22:39:01 CET] <philipl> yes, i can.
[22:39:05 CET] <Chloe> yeah, that's what I'm trying
[22:54:34 CET] <Chloe> philipl: which PPA are you looking at? https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media doesn't have many of the dependencies
[22:59:28 CET] <Timothy_Gu> michaelni: fatebeta/v3.2 seems to exist now...
[23:00:03 CET] <Chloe> philipl: don't worry. You wanted to do this first, I'll stop. If you want someone to have a look at it as well, I don't mind.
[23:00:04 CET] <michaelni> Timothy_Gu, yes, it seems no client tested 3.2
[23:00:20 CET] <Timothy_Gu> huh? http://fatebeta.ffmpeg.org/v3.2 shows a bunch of clients
[23:00:29 CET] <michaelni> yes, now
[23:00:34 CET] <Timothy_Gu> ok
[23:00:52 CET] <Timothy_Gu> Chloe: 3min50sec on sudo: false?
[23:01:05 CET] <Chloe> yeah
[23:01:25 CET] <philipl> Chloe: it's got a decent number. It's where I intend to start.
[23:01:48 CET] <Chloe> Timothy_Gu: I don't really have anything to compare it to other than my personal build times which are ~25min
[23:01:58 CET] <Chloe> (at best)
[23:02:03 CET] <Timothy_Gu> wasn't on IRC a few minutes ago but http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203491.html might be of interest
[23:02:22 CET] <Timothy_Gu> Chloe: ok that's better than I thought
[23:02:37 CET] <Timothy_Gu> see https://travis-ci.org/TimothyGu/FFmpeg/builds/114093334 which takes 18 min to build+run FATE
[23:02:49 CET] <Timothy_Gu> but that was 9 months ago
[23:03:09 CET] <philipl> Chloe: if you want to run with this, feel free.
[23:03:36 CET] <Timothy_Gu> but I think Docker on their Trusty platform is probably the best way to get out of the deps situation
[23:03:37 CET] <philipl> Timothy_Gu: the lack of pre-packaged dependencies is a concern but it's no worse than if you were not using travis. You have to deal with it anyway.
[23:03:47 CET] <Chloe> Timothy_Gu the full build time, with FATE + packaging/upload of sample cache was 9 mins
[23:04:02 CET] <Timothy_Gu> philipl: yeah, but then you only have to install it once as opposed to every single run
[23:04:10 CET] <Chloe> philipl: the alternative to to build everything from source
[23:04:28 CET] <Timothy_Gu> and plus there are multiple points of failure if you are installing the packages from source
[23:04:30 CET] <Chloe> sure it'd make build times massive, but if it's only going to be build twice a week then it doesn't matter
[23:04:31 CET] <philipl> Chloe: yeah, but if we can use packages, so much the better.
[23:04:49 CET] <philipl> Timothy_Gu: you could build a base docker image and use that, but then you have to maintain it.
[23:05:11 CET] <philipl> I'd rather just have the one script and do install/build of dependencies as necessary. As Chloe says - if it's infrequent, it doesn't matter.
[23:05:16 CET] <BtbN> Timothy_Gu, the problem is with some non-redistributable deps
[23:05:27 CET] <BtbN> I don't think it's possible to do that on such kind of public infrastructure.
[23:05:42 CET] <philipl> BtbN: depends on what they are. eg: cuda can be installed from canonical repositories.
[23:05:55 CET] <Chloe> someone has probably already made a docker image for building ffmpeg
[23:06:10 CET] <BtbN> not with _all_ deps
[23:06:28 CET] <philipl> and frankly, you need to decide what your goal is. coverity coverage without building all deps is still useful and you aren't getting windows coverage anyway.
[23:06:39 CET] <Chloe> BtbN: of course, but I mean there's no reason to start from scratch
[23:06:40 CET] <BtbN> why not?
[23:06:41 CET] <Timothy_Gu> philipl: I'd rather go with a Docker image as you can control the installation process easily
[23:06:47 CET] <philipl> There's no point paralysing yourself because you can't get 100% dep coverage
[23:06:59 CET] <BtbN> There are free Windows CI services.
[23:07:04 CET] <philipl> BtbN: travis has no windows offering
[23:07:10 CET] <Timothy_Gu> If you mean AppVeyor, it sucks
[23:07:11 CET] <philipl> I wouldn't want to use two CI services
[23:07:20 CET] <Chloe> Timothy_Gu: indeed, but it does work.
[23:07:28 CET] <BtbN> AppVeyor works fine for one of our projects at work
[23:07:58 CET] <Timothy_Gu> It's the amount of time you have to wait for a single build to start, only to see it failing because of some stupid dependency problem 2 minutes into the build
[23:08:08 CET] <Timothy_Gu> then you have to wait 30+ minutes for it to restart
[23:08:12 CET] <BtbN> you will have to use the non-docker travis infrastructure anyway, as you can't freely install packages on the docker based one.
[23:08:14 CET] <Chloe> Timothy_Gu: once you get that all fine though, it's alright
[23:08:21 CET] <BtbN> So you can just go for docker directly
[23:08:22 CET] <philipl> BtbN: you can.
[23:08:33 CET] <Chloe> philipl: they have to be whitelisted though
[23:08:33 CET] <BtbN> If the package you want happens to be on their witelist.
[23:08:41 CET] <Timothy_Gu> BtbN: You can install APT packages on sudo: false
[23:08:49 CET] <Timothy_Gu> they added it a few months ago
[23:08:53 CET] <BtbN> Only if they are whitelisted iirc
[23:08:53 CET] <Timothy_Gu> some "addons" thing
[23:09:05 CET] <Chloe> (only if they're whitelisted by travis)
[23:09:06 CET] <Timothy_Gu> Yeah, but their whitelist is pretty generoud IIRC
[23:09:11 CET] <Timothy_Gu> *generous
[23:09:15 CET] <Chloe> sure, but if you look at the backlog
[23:09:17 CET] <Chloe> lol.
[23:09:20 CET] <BtbN> Won't cover our exotic dependencies
[23:09:30 CET] <philipl> eh. I didn't realise the whitelist problem.
[23:09:31 CET] <BtbN> Like, CUDA for example, or zimg
[23:09:46 CET] <philipl> So sure, if you're stuck using a VM, then yes, run a yakkety container inside it
[23:09:53 CET] <BtbN> So just go for sudo: true, and prepare a Docker-Image elsewhere
[23:10:07 CET] <philipl> You can prepare the docker-image inline.
[23:10:30 CET] <BtbN> why would you do that? Can just have it pre-built on Docker Hub
[23:10:56 CET] <philipl> And then you have to ask how do I build and update the docker container.
[23:11:04 CET] <philipl> You need a separate set of build jobs for that
[23:11:07 CET] <jamrial> michaelni: looks like you accidentally created an "ffmpeg" branch on the repo
[23:11:12 CET] <BtbN> you push an updated Dockerfile to some repo
[23:11:14 CET] <Chloe> I have 0 experience with docker though so probably better if someone else did it
[23:11:26 CET] <BtbN> Docker Hub builds it for you then
[23:11:31 CET] <philipl> hrm.
[23:11:39 CET] <durandal_1707> jamrial: that was me 
[23:11:40 CET] <Chloe> jamrial: I dont think it was michaelni, and I think it was passed on to the videolan peeps to be removed.
[23:11:51 CET] <jamrial> oh, i see
[23:12:05 CET] <Chloe> you may want to chase that though, not sure if they saw it
[23:12:07 CET] <Timothy_Gu> Wait who's running the GitHub mirror except for me?
[23:12:14 CET] <Chloe> Timothy_Gu: no one
[23:12:34 CET] <Timothy_Gu> ...ok sometimes I see commits pushed by other people
[23:12:34 CET] <Chloe> oh, llougan and michaelni 
[23:12:35 CET] <jamrial> sorry. saw the latest commit from that branch was michaelni's so i assumed he pushed it by mistake
[23:13:05 CET] <Chloe> Timothy_Gu: could you close the PRs/issues on the gh mirror?
[23:13:22 CET] <Timothy_Gu> They keep popping up...
[23:13:35 CET] <Chloe> dont close #153 though
[23:14:20 CET] <Chloe> although you should probably lock it for good measure
[23:14:42 CET] <Chloe> I added a CONTRIBUTING.md a little while back, but there were still PRs even after it was added...
[23:15:25 CET] <Timothy_Gu> Exactly
[23:15:44 CET] <Timothy_Gu> We might need .github/PULL_REQUEST_TEMPLATE.md
[23:16:11 CET] <Timothy_Gu> Like https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/
[23:16:45 CET] <BtbN> that also won't stop people.
[23:17:38 CET] <Chloe> Timothy_Gu: if you're going to create a PULL_REQUEST_TEMPLATE.md then move CONTRIBUTING.md into the .github dir too
[23:19:02 CET] <Timothy_Gu> philipl: I guess we can start with an image that only contains packaged deps and go from there
[23:19:12 CET] <Timothy_Gu> did anyone volunteer?
[23:21:06 CET] <Timothy_Gu> We also need to migrate fate.ffmpeg.org to a new server as it still runs Precise ...
[23:22:24 CET] <Chloe> I can't docker, sorry.
[23:22:48 CET] <BtbN> It's just a shell script that installs stuff on whatever base system you like.
[23:22:58 CET] <philipl> Timothy_Gu: I can start putting together a Dockerfile
[23:23:07 CET] <Chloe> BtbN: I have no means of testing
[23:23:31 CET] <BtbN> Just install docker locally
[23:23:52 CET] <Chloe> which requires a VM, I can't run VMs.
[23:24:02 CET] <Timothy_Gu> there's docker for mac these days i think
[23:24:03 CET] <BtbN> They are not VMs, just containers.
[23:24:32 CET] <BtbN> There's Docker for any major OS
[23:24:47 CET] <Chloe> Timothy_Gu: which runs a VM
[23:25:58 CET] <Timothy_Gu> oh ok
[23:26:02 CET] <Chloe> BtbN: sure, but docker runs a VM to run the containers in. My hardware is too old to run VMs
[23:26:42 CET] <BtbN> At least on Linux it definitely does not do anything like that.
[23:26:48 CET] <JEEB> well that's what it actually is
[23:26:52 CET] <Timothy_Gu> BtbN: he uses a Mac I think
[23:27:05 CET] <JEEB> the "docker for !linux" stuff is basically a VM in which it then runs docker
[23:27:25 CET] <JEEB> because docker kind of bases on linux kernel stuff :P
[23:27:44 CET] <Timothy_Gu> and I would start doing something related to this but today is the last day of the Thanksgiving break so...
[23:27:47 CET] Action: JEEB has mostly poked systemd-nspawn out of the "container" things
[23:28:03 CET] <JEEB> (fancy name for chroot and namespaces)
[23:29:17 CET] <cone-713> ffmpeg 03Michael Niedermayer 07master:102f7d0ee62e: avformat/rmenc: Check framerate before storing
[23:29:18 CET] <cone-713> ffmpeg 03Michael Niedermayer 07master:55997d50431c: tests/ffserver.conf: Force bitexactness in the ffmpeg command
[23:35:10 CET] <philipl> there's no 'enable-all' type thing is there?
[23:35:54 CET] <nevcairiel> everthing is enabled by default, unless it requires external things
[23:36:07 CET] <philipl> to be sure
[23:47:34 CET] <cone-713> ffmpeg 03Andreas Cadhalpun 07master:801b5c18c7be: pngdec: check if previous frame exists instead of trusting sequence_number
[23:53:41 CET] <philipl> install 1042 packages. weee
[00:00:00 CET] --- Mon Nov 28 2016