Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
May 2017
- 1 participants
- 62 discussions
[02:42:21 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07master:64ea4d102a07: avcodec/mlpdec: Do not leave a invalid num_primitive_matrices in the context
[04:02:02 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:02c51f323255: avformat/http: Check for truncated buffers in http_connect()
[04:02:03 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:7272eb87df30: avcodec/wavpacl: Fix runtime error: left shift of negative value -1
[04:02:04 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:367222af32d6: avcodec/mpeg12dec: Fix runtime error: left shift of negative value
[04:02:05 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:00a81ed120e3: avcodec/pngdec: Check bit depth for validity
[04:02:06 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:34450a86c8f6: avcodec/srtdec: Fix signed integer overflow: 1811992524 * 384 cannot be represented in type 'int'
[04:02:07 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:5eea0562b992: avcodec/pictordec: Do not read more than nb_planes
[04:02:08 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:46828511c284: avcodec/rv34: Simplify and factor get_slice_offset() code
[04:02:09 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:68f7ebcd8d59: avcodec/mpegaudiodec_template: Correct return code on id3 tag discarding
[04:02:10 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:e28c0d488800: avcodec/vp56: Fix sign typo
[04:02:11 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:f7e3422a8f74: avcodec/pngdec: Fix runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
[04:02:12 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:18eb35995374: avcodec/amrwbdec: Fix 2 runtime errors: left shift of negative value -1
[04:02:13 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ae82d4f0fa9e: avcodec/vp56: Implement very basic error concealment
[04:02:14 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:2219045914db: avcodec/vp56: Clear dimensions in case of failure in the middle of a resolution change
[04:02:15 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:0b0f58d46289: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -1
[04:02:16 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:3b067c9edcc6: Add CHECK/SUINT code
[04:02:17 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:5c764f0625b4: avcodec/vp3dsp: Fix multiple signed integer overflow: 46341 * 47523 cannot be represented in type 'int'
[04:02:18 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:d19550189ff8: avcodec/vp56: Factorize vp56_render_mb() out
[04:02:19 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:b38272297247: avcodec/vp8: Check for bitsteam end in decode_mb_row_no_filter()
[04:02:20 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:94d1f07c3b05: avcodec/vp3: Do not return random positive values but the buf size
[04:02:21 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4e30560efc8b: avcodec/vp56: Require a correctly decoded frame before using vp56_conceal_mb()
[04:02:22 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:efa47b5c9982: avcodec/vp8: remove redundant check
[04:02:23 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:45abce9e05e6: avcodec/vp568: Check that there is enough data for ff_vp56_init_range_decoder()
[04:02:24 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:678dd7cf2095: avcodec/vp8: Check for the bitstream end per MB in decode_mb_row_no_filter()
[04:02:25 CEST] <cone-157> ffmpeg 03Thomas Guilbert 07release/2.8:b27bcc32c7ff: avcodec/vp8: Fix hang with slice threads
[04:02:26 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:f8769b1a702b: avcodec/vp56: Reset have_undamaged_frame on resolution changes
[04:02:27 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:b1817a23c2e5: avcodec/vp6: clear dimensions on failed resolution change in vp6_parse_header()
[04:02:28 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:554687bff65f: avcodec/eac3dec: Fix runtime error: left shift of negative value
[04:02:29 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:8f64abc5e2bc: avcodec/mjpegdec: Fix runtime error: left shift of negative value -507
[04:02:30 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:016a8e777213: avcodec/mpeg4videodec: Fix runtime error: shift exponent -2 is negative
[04:02:31 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:00870c248e3b: avcodec/h264_cabac: runtime error: signed integer overflow: 2147483647 + 14 cannot be represented in type 'int'
[04:02:32 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:12a4a93b4091: avcodec/rv40: Fix runtime error: left shift of negative value
[04:02:33 CEST] <thebombzen> wow okay. commit much?
[04:02:33 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:38e34f50158b: avcodec/ituh263dec: Fix runtime error: left shift of negative value -22
[04:02:34 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:bccc669fb16b: avcodec/mpeg4video: Fix runtime error: left shift of negative value
[04:02:35 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:a50259df791e: avcodec/mpeg4videodec: Check sprite_offset in addition to shifts
[04:02:36 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:e5c39ad0e900: avcodec/mpeg4videodec: Check the other 3 sprite points for intermediate overflows
[04:02:37 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:d782b0b2ada3: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -2
[04:02:38 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:5453ac597eb0: avcodec/eac3dec: Fix runtime error: left shift of negative value -3
[04:02:39 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:09e51a464cc1: avcodec/mpeg4videodec: Fix runtime error: left shift of negative value -2650
[04:02:40 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:e65462291e8a: avcodec/pictordec: Check plane value before doing value/mask computations
[04:02:41 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:b9cc73fafbf7: avcodec/h264_direct: Fix runtime error: left shift of negative value -14
[04:02:42 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:718c1433d980: avcodec/mjpegdec: Fix runtime error: left shift of negative value -511
[04:02:43 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:66d81c5926f6: avcodec/mpeg4videodec: Improve the overflow checks in mpeg4_decode_sprite_trajectory()
[04:02:44 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:1a8f1ae223a2: avcodec/adxdec: Fix runtime error: left shift of negative value -1
[04:02:45 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:8ca5f502ac3a: avcodec/h264_mvpred: Fix multiple runtime error: left shift of negative value
[04:02:46 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:c41ce74c8aa9: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -13
[04:02:47 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:5cb5e2550ea5: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 134527392 * 16 cannot be represented in type 'int'
[04:02:48 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:f31e43175cb8: avcodec/wavpack: Fix runtime error: left shift of negative value -2
[04:02:49 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4d4ce42f0b86: avcodec/wavpack: Fix runtime error: left shift of negative value -5
[04:02:50 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:bf37f12f40d3: avcodec/mjpegdec: Fix runtime error: left shift of negative value -127
[04:02:51 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:96cc855c1a82: avcodec/h264_mvpred: Fix runtime error: left shift of negative value -1
[04:02:52 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:e83d6c6819c7: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: -135088512 * 16 cannot be represented in type 'int'
[04:02:53 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4e2c1055a0a2: avcodec/amrwbdec: Fix runtime error: left shift of negative value -1
[04:02:54 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:36c314e76a53: avcodec/rv34: Fix runtime error: signed integer overflow: 36880 * 66288 cannot be represented in type 'int'
[04:02:55 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:922013c983e5: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int'
[04:02:56 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:b34ca8295dd8: avcodec/tiff: Check for multiple geo key directories
[04:02:57 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:17624e415636: avcodec/mpegaudiodec_template: Make l3_unscale() work with e=0
[04:02:58 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:26b2b2d052af: avcodec/tiff: Check stripsize strippos for overflow
[04:02:59 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:a2a028af6e6f: avcodec/vp56: Check avctx->error_concealment before enabling EC
[04:03:00 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:95594b9815e8: avcodec/tiff: Check geotag count for being non zero
[04:03:01 CEST] <cone-157> ffmpeg 03Philip Langdale 07release/2.8:9c7730417dec: avcodec/vdpau_hevc: Fix potential out-of-bounds write
[04:03:02 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:344e5de99390: avcodec/tiff: Perform multiply in tiff_unpack_lzma() as 64bit
[04:03:03 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:cbd00368567c: avfilter/avfiltergraph: Add assert to write down in machine readable form what is assumed about sample rates in swap_samplerates_on_filter()
[04:03:04 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:3fd8e79dc97a: avcodec/dvdsubdec: Fixes 2 runtime error: left shift of 170 by 24 places cannot be represented in type 'int'
[04:03:05 CEST] <cone-157> ffmpeg 03Derek Buitenhuis 07release/2.8:436f1d456273: avformat/webmdashenc: Require the 'adaptation_sets' option to be set
[04:03:06 CEST] <cone-157> ffmpeg 03Derek Buitenhuis 07release/2.8:77dd220385f2: avformat/webmdashenc: Validate the 'streams' adaptation sets parameter
[04:03:07 CEST] <cone-157> ffmpeg 03Martin Vignali 07release/2.8:d1b23e5c0c6c: libavcodec/exr : fix float to uint16 conversion for negative float value
[04:03:08 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:37f5bfaa2b0a: avcodec/mdec: Fix runtime error: left shift of negative value -127
[04:03:09 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:7f5c9250de0e: avcodec/vp3: Check remaining bits in unpack_dct_coeffs()
[04:03:10 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:97458a040f88: avcodec/indeo2: Check remaining bits in ir2_decode_plane()
[04:03:11 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:9d2939a79126: avcodec/svq3: Increase offsets to prevent integer overflows
[04:03:12 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:533999aaadc4: avcodec/h264_cavlc: Fix undefined behavior on qscale overflow
[04:03:13 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:0a391b738ecb: avcodec/msvideo1: Check buffer size before re-getting the frame
[04:03:14 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4ea21dd574a7: avcodec/pngdec: Use ff_set_dimensions()
[04:03:15 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:7dc7d706447d: libavcodec/mpeg4videodec: Convert sprite_offset to 64bit
[04:03:16 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:65bc41b857ac: avcodec/dvdsubdec: Fix runtime error: left shift of 242 by 24 places cannot be represented in type 'int'
[04:03:17 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:e45de9d2794a: avcodec/cavsdec: Fix undefined behavior from integer overflow
[04:03:18 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:7ab622408344: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'
[04:03:20 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:e9242134920a: avcodec/tiertexseqv: set the fixed dimenasions, do not depend on the demuxer doing so
[04:03:20 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:2197423ec96e: avcodec/wnv1: Fix runtime error: left shift of negative value -1
[04:03:21 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:a6e7636dac67: avcodec/dss_sp: Fix multiple left shift of negative value -466
[04:03:22 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:cacae0656fd4: avcodec/g722: Fix multiple runtime error: left shift of negative value -1
[04:03:23 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:3366d18c29a8: avcodec/cdxl: Fix signed integer overflow: 14243456 * 164 cannot be represented in type 'int'
[04:03:24 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:cd6c4082db76: avcodec/nellymoser: Fix multiple left shift of negative value -8591
[04:03:25 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:1e9fa7c69fdc: avcodec/dfa: Fix off by 1 error
[04:03:26 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:51b8a78851da: avcodec/mdec: Fix signed integer overflow: 28835400 * 83 cannot be represented in type 'int'
[04:03:27 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ddab43d3a89a: avcodec/aacsbr_template: Do not leave bs_num_env invalid
[04:03:29 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:5dec065a4d83: avutil/softfloat: Fix multiple runtime error: left shift of negative value -8
[04:03:29 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:acb589b12d9d: avcodec/snowdec: Check qbias
[04:03:30 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:00371aff3dcb: avcodec/mlpdec: Fix runtime error: left shift of negative value -22
[04:03:31 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ce0db291c63a: avcodec/fic: Fix multiple left shift of negative value -15
[04:03:32 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:54368ac9b370: avcodec/mimic: Fix runtime error: left shift of negative value -1
[04:03:33 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:1951a44d77d2: avcodec/dfa: Fix signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
[04:03:34 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ff27d173489c: avcodec/webp: Fix null pointer dereference
[04:03:35 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:b9289fad4b0b: avcodec/shorten: Check k in get_uint()
[04:03:36 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:afbe970534eb: avcodec/mss3: Change types in rac_get_model_sym() to match the types they are initialized from
[04:03:37 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:d68870a60605: avcodec/hq_hqa: Fix runtime error: left shift of negative value -207
[04:03:38 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:224ed78e7268: avutil/softfloat: Fix overflow in av_div_sf()
[04:03:39 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:191e0f7e2b88: avcodec/cdxl: Check format parameter
[04:03:40 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:5b56c2d83a33: avcodec/dds: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[04:03:41 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:906c9d08043d: avcodec/msmpeg4dec: Correct table depth
[04:03:42 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:833a759d408c: avcodec/svq3: Fix multiple runtime error: signed integer overflow: 44161 * 61694 cannot be represented in type 'int'
[04:03:43 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:91394cc4da15: avcodec/ivi_dsp: Fix multiple left shift of negative value -2
[04:03:44 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:d2dba39204f4: avcodec/targa_y216dec: Fix width type
[04:03:45 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:6856a8f0ad14: avcodec/mss34dsp: Fix multiple signed integer overflow
[04:03:46 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:c9cdea2a2409: avcodec/ra144: Fix runtime error: left shift of negative value -798
[04:03:47 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:fc99e4c9725c: avcodec/g726: Fix runtime error: left shift of negative value -2
[04:03:48 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:89b2c2493181: avcodec/eamad: Fix runtime error: signed integer overflow: 49674 * 49858 cannot be represented in type 'int'
[04:03:49 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:73e68fbe866a: avcodec/s302m: Fix left shift of 8 by 28 places cannot be represented in type 'int'
[04:03:50 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:39108a4724b0: avcodec/xwddec: Check bpp more completely
[04:03:51 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:2474b81eca27: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -12156865 cannot be represented in type 'int'
[04:03:52 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:1116de7ba78e: avcodec/ffv1dec: Fix copying planes of paletted formats
[04:03:53 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ff342d0587d6: avcodec/cdxl: Check format for BGR24
[04:03:54 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ab494a84dd27: avcodec/cavsdec: Check sym_factor
[04:03:55 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:6606445c85dc: avcodec/hqxdsp: Fix multiple runtime error: signed integer overflow: 248220 * 21407 cannot be represented in type 'int' in idct_col()
[04:03:56 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ea10865d780f: avcodec/vp8dsp: Fixes: runtime error: signed integer overflow: 1330143360 - -1023040530 cannot be represented in type 'int'
[04:03:57 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:e7d36d262ea9: avcodec/dvbsubdec: check region dimensions
[04:03:58 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:fbeb8c760cf5: avcodec/dss_sp: Fix multiple runtime error: signed integer overflow: -15699 * -164039 cannot be represented in type 'int'
[04:03:59 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:6db01ccde7ad: avcodec/bmvvideo: Fix runtime error: left shift of 137 by 24 places cannot be represented in type 'int'
[04:04:00 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:bd908055c8f7: avcodec/htmlsubtitles: Check for string truncation and return error
[04:04:01 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:2dcdf145f51e: avcodec/indeo2: Check for invalid VLCs
[04:04:02 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:db3d3ced152d: avcodec/takdec: Fix multiple runtime error: left shift of negative value -1
[04:04:03 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:5380abf7854f: avcodec/lagarith: Fix runtime error: left shift of negative value -1
[04:04:04 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:1c75d1b54b88: avcodec/lagarith: Check scale_factor
[04:04:05 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:43bdff201d60: avcodec/texturedsp: Fix runtime error: left shift of 218 by 24 places cannot be represented in type 'int'
[04:04:07 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4dacf6bc4ac2: avcodec/svq3: Fix multiple runtime error: signed integer overflow: -237341 * 24552 cannot be represented in type 'int'
[04:04:07 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:a98d82b13daf: avcodec/y41pdec: Fix width in input buffer size check
[04:04:08 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:7bbd92f69d12: avcodec/cavs: Check updated MV
[04:04:09 CEST] <cone-157> ffmpeg 03N^ 07release/2.8:37f59340bb56: avformat/wavdec: Check chunk_size
[04:04:10 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:507ed0ab526c: avcodec/dss_sp: Fix runtime error: signed integer overflow: 2147481189 + 4096 cannot be represented in type 'int'
[04:04:11 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:85d4892cb982: avcodec/eatqi: Fix runtime error: signed integer overflow: 4466147 * 1075 cannot be represented in type 'int'
[04:04:12 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:79905e0dffd6: avcodec/truemotion1: Fix multiple runtime error: left shift of negative value -1
[04:04:13 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:60bc8b628228: avfilter/vf_uspp: Fix currently unused input frame dimensions
[04:04:14 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:e7568a435270: avcodec/webp: Always set pix_fmt
[04:04:15 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:df84fb2304d8: avcodec/mpeg12dec: Fixes runtime error: division by zero
[04:04:17 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:1f8047adb8dc: avcodec/aacdec_fixed: Fix multiple shift exponent 33 is too large for 32-bit type 'int'
[04:04:18 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:680157adb272: avcodec/dvbsubdec: Check entry_id
[04:04:18 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:d6e7a96fc468: avcodec/cllc: Factor VLC_BITS/DEPTH out, do not use repeated literal numbers
[04:04:19 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:f05cd37d51df: avcodec/cllc: Check num_bits
[04:04:20 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:f2bdef4f2a18: avcodec/msmpeg4dec: Check for cbpy VLC errors
[04:04:22 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:53d5e655c762: avcodec/diracdec: Fix Assertion frame->buf[0] failed at libavcodec/decode.c:610
[04:04:23 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4ce0554daa10: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -17047030 cannot be represented in type 'int'
[04:04:23 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4ea880c55ea4: avcodec/texturedsp: Fix runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[04:04:24 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:dccd62dc8958: avcodec/avcodec: Limit the number of side data elements per packet
[04:04:26 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:b198bd75bf09: avcodec/vp8dsp: vp7_luma_dc_wht_c: Fix multiple runtime error: signed integer overflow: -1366381240 + -1262413604 cannot be represented in type 'int'
[04:04:27 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:cb45926aa934: avcodec/mlp: Fix multiple runtime error: left shift of negative value -1
[04:04:27 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:699ca0075a24: avcodec/aacsbr_template: Do not change bs_num_env before its checked
[04:04:28 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:c853966783b6: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1
[04:04:29 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:2ec60b919ffc: avcodec/webp: Add missing input padding
[04:04:31 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:0c92adda48c4: avcodec/ac3dec: Keep track of band structure
[04:04:32 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:6e46f19cc8b9: avcodec/mlpdec: Check that there is enough data for headers
[04:04:33 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4ed535d79b96: avcodec/svq3: Fix runtime error: signed integer overflow: 169 * 12717677 cannot be represented in type 'int'
[04:04:33 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:35ed8aa76f6a: avcodec/webp: Fix signedness in prefix_code check
[04:04:35 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:bfc153436263: avcodec/ffv1dec: Fix runtime error: signed integer overflow: 1550964438 + 1550964438 cannot be represented in type 'int'
[04:04:36 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:42f2cf159767: libswscale/tests/swscale: Fix uninitialized variables
[04:04:37 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:12f969bd2c57: avcodec/hqxdsp: Fix runtime error: signed integer overflow: -196264 * 11585 cannot be represented in type 'int'
[04:04:37 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:b17779fc14b7: avcodec/ac3dec: Fix: runtime error: index -1 out of bounds for type 'INTFLOAT [2]'
[04:04:39 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ab56c6483597: avcodec/mpeg4videodec: Clear sprite wraping on unsupported cases in VOP decode
[04:04:39 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:5b809f53c230: avcodec/dds: Fix runtime error: left shift of 210 by 24 places cannot be represented in type 'int'
[04:04:40 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:b3e3cdc0fd8b: avcodec/cllc: Check prefix
[04:04:41 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4ad139ba23d0: avcodec/webp: Factor update_canvas_size() out
[04:04:42 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ef94fb391ff6: avcodec/webp: Update canvas size in vp8_lossy_decode_frame() as in vp8_lossless_decode_frame()
[04:04:43 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:eca9c51090b2: avcodec/snowdec: Check width
[04:04:44 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:ec70017f9fc2: avcodec/flacdec: Return error code instead of 0 for failures
[04:04:46 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:53567e573bde: avcodec/opus_silk: Fix integer overflow and out of array read
[04:04:46 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:aa941e9aa9d5: avcodec/aacps: Fix undefined behavior
[04:04:47 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:a1778b8cdda7: avcodec/tiff: reset sampling[] if its invalid
[04:04:48 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:c90ad2b5ccd0: avcodec/svq3: Fix runtime error: left shift of negative value -6
[04:04:50 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:9dcd02a5a5d1: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int'
[04:04:50 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:28d7c43d0f7c: avcodec/hq_hqa: Fix: runtime error: signed integer overflow: -255 * 10180917 cannot be represented in type 'int'
[04:04:52 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:07ca48cecf3d: avcodec/takdec: Fix runtime error: left shift of negative value -42
[04:04:53 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:f5d0960872fe: avcodec/mlpdec: Fix runtime error: left shift of negative value -1
[04:04:53 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:209124a94428: avcodec/flicvideo: Check frame_size before decrementing
[04:04:54 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:f76c1554f639: avcodec/aacdec_template: Fix fixed point scale in decode_cce()
[04:04:55 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:afc0b559f6ac: avcodec/aacdec: Fix runtime error: signed integer overflow: 2147483520 + 255 cannot be represented in type 'int'
[04:04:57 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:9e62e1cded85: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int'
[04:04:58 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:346e2d16639c: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[04:04:58 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:1397c7f6160b: avcodec/fic: Fix multiple runtime error: signed integer overflow: 5793 * 419752 cannot be represented in type 'int'
[04:04:59 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:860ff3c44752: avcodec/mimic: Use ff_set_dimensions() to set the dimensions
[04:05:01 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:3ecff1b7e523: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 150 is too large for 32-bit type 'int'
[04:05:01 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07release/2.8:4117f19f2f59: avcodec/mlpdec: Do not leave a invalid num_primitive_matrices in the context
[05:02:25 CEST] <cone-157> ffmpeg 03James Almer 07release/2.8:4122e5fcb3b2: avcodec/options: factorize avcodec_copy_context() cleanup code
[05:02:26 CEST] <cone-157> ffmpeg 03James Almer 07release/2.8:1c302b606e0f: avcodec/options: do a more thorough clean up in avcodec_copy_context()
[05:02:27 CEST] <cone-157> ffmpeg 03Aaron Levinson 07release/2.8:0109a152a165: avformat/utils: free AVStream.codec properly in free_stream()
[05:02:28 CEST] <cone-157> ffmpeg 03James Almer 07release/2.8:870f1e3836c5: avformat/concatdec: fix the h264 annexb extradata check
[05:02:29 CEST] <cone-157> ffmpeg 03James Almer 07release/2.8:24d744cabe08: avcodec/hevc_sei: fix amount of bits skipped when reading picture timing SEI message
[10:54:51 CEST] <wm4> "I want time to comment."
[10:54:53 CEST] <wm4> man this fucking guy
[10:55:33 CEST] <wm4> so after throwing a fit about too much bikeshedding he's holding back the fix to bikeshed more about it later
[12:44:24 CEST] <cone-281> ffmpeg 03Paul B Mahol 07master:e8ae23db27bd: avfilter/af_sidechaincompress: change default makeup gain to 1
[12:59:54 CEST] <cone-281> ffmpeg 03Matthieu Bouron 07master:ab61b79b1c70: lavf/mov: make invalid m{d,v}hd time_scale default to 1 instead of erroring out
[16:31:04 CEST] <cone-281> ffmpeg 03Diego Biurrun 07master:6151e9128ce2: build: Detect blocks C language extension and add it as VDA dependency
[16:31:05 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:d1da0fc4b9b3: Merge commit '6151e9128ce2a84a443c82b78f5b5cb364ba2ab4'
[16:32:08 CEST] <cone-281> ffmpeg 03Diego Biurrun 07master:2bbb5abd8771: build: Map -Wall compiler flag to -W3 for MSVC and -Wextra to -W4
[16:32:09 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:068d91885ffd: Merge commit '2bbb5abd877104fa9bc342c521bb49bc1aad50ce'
[16:34:10 CEST] <cone-281> ffmpeg 03Anton Schubert 07master:1ae6cb7d6e4f: dashenc: fix ISO8601 UTC parsing
[16:34:11 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:93bf0480c2db: Merge commit '1ae6cb7d6e4fee30754a46bc91f40ff75ac4412a'
[16:40:52 CEST] <cone-281> ffmpeg 03Peter Große 07master:95f1004bdfdf: dashenc: add mandatory id to AdaptationSet and Period in manifest
[16:40:53 CEST] <cone-281> ffmpeg 03Anton Schubert 07master:3c2717e48dd8: dashenc: increase buffer time hint in the manifest
[16:40:54 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:77a20cff3628: Merge commit '95f1004bdfdf2d26c330c1d4b7c4ac9352d60b18'
[16:40:55 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:ba3adea9575c: Merge commit '3c2717e48dd8c5115f2be35c2afcabd8a1f67aee'
[16:41:25 CEST] <cone-281> ffmpeg 03Mark Thompson 07master:ca6ae3b77a7e: vaapi_encode: Add MPEG-2 support
[16:41:26 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:1ff55e12f729: Merge commit 'ca6ae3b77a7e6600e517723b90e57527a47809de'
[16:43:29 CEST] <cone-281> ffmpeg 03Luca Barbato 07master:11e225db31dc: rtmp: Account for bytes_read wraparound
[16:43:30 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:e78dc57888d1: Merge commit '11e225db31dcad57e2219ad8dfae2ac027af53d6'
[16:51:17 CEST] <cone-281> ffmpeg 03MichaB Górny 07master:784898220740: configure: Place all temporary files in one separate directory
[16:51:18 CEST] <cone-281> ffmpeg 03Diego Biurrun 07master:ba6a49e60bdd: configure: Clean up temporary files on interrupt
[16:51:19 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:091c9860559e: Merge commit '78489822074096e3ae0f3c3b70accace955086f6'
[16:51:20 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:a8ad127a63ab: Merge commit 'ba6a49e60bdd61b6d02c2b26daa01942c35f39cc'
[16:54:48 CEST] <cone-281> ffmpeg 03Peter Große 07master:1920382aa9f2: dashenc: add option to provide UTC timing source
[16:54:48 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:e815111367cb: Merge commit '1920382aa9f21d7ed1a3c2214990da8d2b067a92'
[16:56:21 CEST] <cone-281> ffmpeg 03Peter Große 07master:e519dcd937c7: dashenc: separate segments based on current segment duration
[16:56:22 CEST] <cone-281> ffmpeg 03Clément BSsch 07master:1a950f32abf3: Merge commit 'e519dcd937c7c98815ba9884867590e302272016'
[16:59:37 CEST] <ubitux> is PrzemysBaw Sobala on IRC?
[17:00:06 CEST] <durandal_1707> why?
[17:00:17 CEST] <ubitux> dashenc stuff to merge related to bitrate
[17:00:22 CEST] <ubitux> done differently in libav
[17:00:48 CEST] <durandal_1707> nobody is here
[17:57:43 CEST] <cone-281> ffmpeg 03Michael Niedermayer 07master:23868ad5cb9b: avcodec/g723_1dec: Clip after shift in estimate_sid_gain()
[18:14:30 CEST] <cone-281> ffmpeg 03Anton Khirnov 07master:02327d1237f1: decode: fix the code reducing cropping to preserve alignment
[18:17:52 CEST] <cone-281> ffmpeg 03James Almer 07master:f20161d89943: avcodec/decode: fix function name
[18:28:59 CEST] <cone-281> ffmpeg 03Muhammad Faiz 07master:fc3a03fcf9cd: avfilter: take_samples: do not directly return frame when samples are skipped
[18:49:48 CEST] <cone-281> ffmpeg 03Muhammad Faiz 07release/3.3:7fae0ea21daa: avfilter: take_samples: do not directly return frame when samples are skipped
[22:11:57 CEST] <michaelni> ubitux, 091c9860559e4d33179747c5d651bc9e31bd76eb breaks ./configure --tempprefix=/path/of/your/choice
[22:12:28 CEST] <michaelni> why was this not posted to the ML ?
[22:19:15 CEST] <nevcairiel> we went over this, its absolutely impractical and unrealistic to put every merge onto the ML
[22:19:24 CEST] <nevcairiel> you might as well stop doing them then
[22:33:17 CEST] <wm4> indeed, and it's a very strange request from someone who has been doing merges just by usually surprise-pushing them to master
[22:33:48 CEST] <wm4> and doing that this way for years
[22:34:01 CEST] <jamrial> lets drop it and fix the regression instead
[00:00:00 CEST] --- Sun May 21 2017
1
0
[01:40:48 CEST] <Golfgeo> Hi all! Got a question: Looking to x11grab my 1080 screen and transport it over a firewire connection to use on another machine. Have had some luck with huffyuv, yet am only getting between 3 and 8 frames per second in throughput... Piping the connection through nc on both systems. Has anyone had any luck with such a setup (where one has 400mbit/sec to play with); And any good pointers and tips in regards to getting good fps?
[01:42:35 CEST] <furq> you probably want something that compresses a bit better than huffyuv
[01:43:21 CEST] <furq> try ffvhuff, ffv1, x264 lossless, utvideo etc
[01:43:46 CEST] <Golfgeo> furq, I haven't calculated the required bitrates, but since huffyuv only uses some 70mbit/sec for those 8 fps I'
[01:43:52 CEST] <Golfgeo> one moment
[01:44:40 CEST] <furq> yeah that seems way too low
[01:44:45 CEST] <Golfgeo> ... for those 8fps I should have some headroom to use a lossless codec and am really looking "not to compress"
[01:45:17 CEST] <furq> are you sure it's 70mbit
[01:45:25 CEST] <Golfgeo> Yep
[01:45:32 CEST] <furq> what framerate
[01:45:38 CEST] <Golfgeo> 8 fps atm
[01:45:44 CEST] <furq> i mean what framerate are you capturing at
[01:46:04 CEST] <Golfgeo> 60 fps and 30 fps gives the same
[01:47:08 CEST] <furq> huffyuv is giving me 500mbit for a static image at 1080p60
[01:47:09 CEST] <Golfgeo> It seems to me that either x11grab can't grab the requested frames or that NC is bottlenecking (perhaps in concord with the system piping on both machines)
[01:47:25 CEST] <furq> so you might want to doublecheck that
[01:47:33 CEST] <furq> if you're getting throttled then i assume it's just going over 400mbit
[01:47:58 CEST] <Golfgeo> I see your point
[01:48:21 CEST] <furq> 1080p60 4:2:0 rawvideo is 1.5gbit, and huffyuv isn't very good
[01:48:37 CEST] <furq> and 4:4:4/rgb is twice that size if you're capturing either of those
[01:48:53 CEST] <Golfgeo> let me try something here
[01:49:17 CEST] <furq> also all those codecs i mentioned are lossless
[01:49:37 CEST] <furq> some of them do inter compression which will make a massive difference with mostly static content (e.g. most desktop capture)
[01:49:49 CEST] <furq> massive as in several orders of magnitude
[01:50:06 CEST] <Golfgeo> that's interesting
[01:51:28 CEST] <Golfgeo> Yes, something is weird here. 1 fps resulta in 18mbit/sec
[01:53:08 CEST] <klaxa> ffmpeg can use tcp itself, no need to pipe through nc on the server side (you could even use http if you wanted) just use: ffmpeg [whatever] -listen 1 tcp://0.0.0.0:1234
[01:53:47 CEST] <Golfgeo> klaxa, I "hack the problem up into pieces". That was the next thing to solve :)
[01:54:44 CEST] <Golfgeo> ffvhuff is giving me the same issue. But I like the rendering that's presented on the second computer! No weird collors and such :)
[01:54:52 CEST] <Golfgeo> *hacked
[01:56:24 CEST] <Golfgeo> ffv1 is 3.8 frames while requesting 5 fps
[01:57:53 CEST] <Golfgeo> Yea, I'm seeing CPU spikes. Loving the 16% load on a single core though!
[01:58:15 CEST] <Golfgeo> So, something is weird in the piping here!
[01:58:26 CEST] <Golfgeo> Thanks furq and klaxa! :D
[02:01:15 CEST] <Golfgeo> klaxa, looking into the listen option now ;) Thanks for the tip! :D
[02:01:54 CEST] <klaxa> :)
[02:16:02 CEST] <Golfgeo> yea, even with libschroedinger I'm getting low fps. Oh well, it's time to call it quites for today. Thanks for the tips, pointers and help! :D
[02:59:00 CEST] <VectorX> hi i want to combine a mp4 and a mp3 the resulting mp4 should be the longest length and what ever that is shorter should loop
[03:04:56 CEST] <zyme> if anyone's got a few minutes sometime, I have some newbie questions to ask, some might need to be directed eleswhere, but I guess to start with, I was inspired a couple years ago by a particular program (on a similar note I discovered it mentioned as a GPL violator on this webpage - trac.ffmpeg.org/ticket/4521 ) - so if anyones familar with that software,
[03:04:57 CEST] <zyme> I think ffmpeg seems to be the programs main source of "Magic" and if there was any way to help contribute to or if there's already an alternative out there.. nothing would make me happier as I feel like it's been the only option suitable for most my streaming hobbits...
[03:12:28 CEST] <zyme> mainly because it seems to be able to decode and stream to my Chromecast2 unsupported formats without transcoding into x264, I don't even think it's compressed at all, just decoded (on a PC) before streaming - something which nothing else seems capable of - and I've been all over googles sdk and support docs & for the most part that seems impossible or
[03:12:28 CEST] <zyme> rather unsupported..
[03:16:14 CEST] <zyme> is it maybe possible to format a decoded mpeg stream as x264 without performing any compression or loosing quality?
[03:20:19 CEST] <zyme> something akin to using the least options for encoding while leaving the bitrate as high as the source.
[03:22:00 CEST] <dystopia_> crf 0 / placebo
[03:25:02 CEST] <zyme> because if so then that brings me to a related question, I have a bunch of avi's that use xvid or x263 - I'd love to to "convert" to x264 but every video reencoding COTS program I've tried ends up needing a larger output file then the souce to maintain close to the original quality, even trying HVEC usually ends up aat the same bitrate at best if I don't
[03:25:02 CEST] <zyme> want to loose quality...
[03:25:25 CEST] <VectorX> hi how can i add https://launchpad.net/ubuntu/+source/ffmpeg to ubuntu so i get the latest version, its currently installed with apt-get and is 2.8
[03:25:37 CEST] <VectorX> 2.8.11-0ubuntu0.16.04.1
[03:26:42 CEST] <zyme> do they have a sourcecode tar.gz to run make config etc the good old fashioned way (usually theres a readme with a walkthrough)
[03:28:51 CEST] <VectorX> yeah
[03:29:15 CEST] <VectorX> i wanted to see if there was an automated way so everything was thru the package manager
[03:29:36 CEST] <VectorX> ill remove what i have and try that
[03:29:43 CEST] <VectorX> any idea about my other question
[03:29:49 CEST] <VectorX> i want to combine a mp4 and a mp3 the resulting mp4 should be the longest length and what ever that is shorter should loop
[03:30:55 CEST] <zyme> until I used mac's I never used pkg managers, they spoil you lol... I use to compile tarballs for everything because I used on slackware.. and track down all my own dependency's... I think ubuntu is debian based so hopefully it should conform to a non-proprietary file structure and be easily compliable.
[03:33:13 CEST] <thebombzen> Is it safe to turn on -ffast-math when building ffmpeg?
[04:01:27 CEST] <thebombzen> Oops, I dced. I'll ask again. Is it safe to compile ffmpeg with -ffast-math
[05:52:12 CEST] <zyme> thebombzen: if compiling doesn't give any warnings, and google doesn't come up with anything, then I would use trial and error, with os probably better than w/o unless you find a bug
[07:12:13 CEST] <Fyr> guys, does remuxing keep full information?
[07:12:42 CEST] <Fyr> i.e. I can remux 100 times from one container to another and the original information will be untouched?
[07:18:02 CEST] <grublet> Fyr: a container just stores the video and audio streams, changing containers won't alter the data
[07:18:14 CEST] <grublet> as long as you use -c:a copy -v:a copy
[07:18:34 CEST] <Fyr> grublet, so, it is completely safe to remux 100 times?
[07:18:35 CEST] <grublet> -c:a copy -c:v copy
[07:18:36 CEST] <grublet> i mean
[07:18:51 CEST] <grublet> yes
[07:20:19 CEST] <Fyr> grublet, could you also recommend a tool for editing channels? I need to add a 100 seconds of silence into an 5.1 AC-3 audio.
[07:20:39 CEST] <Fyr> Audacity shows a multiple channel audio as different tracks.
[07:21:20 CEST] <Fyr> I don't know how to edit them at once.
[07:21:25 CEST] <grublet> You can save them back as separate WAV files and use ffmpeg or something like sox to recombine them, assuming you know the correct channel order, which for 5.1
[07:21:29 CEST] <Fyr> I downmixed them to stereo.
[07:23:05 CEST] <Fyr> grublet, I have to add a silence into a many places. mostly, 0.6 s a place.
[07:23:19 CEST] <Fyr> i.e. about 300 places with silence.
[07:23:42 CEST] <grublet> I'm not sure what you would need to do that easily, in that case
[07:24:03 CEST] <grublet> Audacity should let you "select all" tracks if you press Ctrl+A
[07:24:16 CEST] <grublet> and then generate silence and it should go to the same place in all of them at once
[07:24:47 CEST] <Fyr> cool, thanks
[09:30:52 CEST] <kms_> how to set live record duration (not output file duration) with -filter:v "setpts=0.1*PTS"
[09:30:56 CEST] <kms_> ?
[09:31:59 CEST] <kms_> Duration of recording
[09:33:36 CEST] <teratorn> kms_: -t option?
[09:34:13 CEST] <kms_> This affects the final file and not the recording time
[09:34:51 CEST] <kms_> (i think)
[09:35:40 CEST] <teratorn> kms_: it can be used as an input option or an output option depending on where it appears on the command line
[09:36:06 CEST] <kms_> oh, ok..
[09:36:08 CEST] <teratorn> kms_: read the help/man page on it.. sounds to me like what you want
[09:46:52 CEST] <kms_> thnx
[11:34:38 CEST] <OzgrK> hi, i'd like to create a sine wave of 1000hz and continiously reduce the frequency with time until it is zero at the end of the stream, which is 16 hours. if frequency parameter would take t as timestamp variable for second, like hue filter, then it would be achieved with something like -f lavfi -i sine=frequency=1000-(t/57.6):sample_rate=44100:duration=57600 . but this does not work since frequency parameter does not accpet t varible. ho
[11:34:53 CEST] <OzgrK> frequency change with the stimestamp for sine filter? or is there another way to achieve this? thanks
[13:15:53 CEST] <durandal_1707> OzgrK: use aevalsrc filter
[13:38:41 CEST] <OzgrK> durandal_1707: thanks i will check that
[15:46:49 CEST] <durandal_1707> Fyr: you can use adelay filter to add silence at start of each or some channels
[15:47:14 CEST] <VectorX> i want to combine a mp4 and a m4a the resulting mp4 should be the longest length and what ever that is shorter should loop, how can i do that
[16:02:35 CEST] <ChocolateArmpits> VectorX, ffmpeg -stream_loop -1 -i input.mp4 -stream_loop -1 -i input.m4a -shortest -map 0:v -map 1:a output.mp4
[16:03:05 CEST] <ChocolateArmpits> oh wait
[16:03:10 CEST] <ChocolateArmpits> that won't wokr, it'll just loop
[16:03:31 CEST] <ChocolateArmpits> You're best bet is to first find out which of those is shorter, using something like ffprobe
[16:03:43 CEST] <ChocolateArmpits> and then to use -stream_loop -1 only on the shorter one
[16:48:51 CEST] <Yuliya> Hey
[17:22:22 CEST] <TheXzoron> https://zoronunderground.club/f/ffmpeg.txt
[17:22:37 CEST] <TheXzoron> I'm having audio desync issues with ffmpeg recording for some reason
[17:23:17 CEST] <TheXzoron> is there something special I have to do to record from pulse
[18:18:21 CEST] <VectorX> ChocolateArmpits ok, also is there a way to turn multiple process, ie, ffmpeg -i file.gif file.mp4 | ffmpeg -i file.mp4 .... sort of thing
[18:18:46 CEST] <ChocolateArmpits> VectorX, what do you mean turn multiple ?
[18:19:02 CEST] <VectorX> basically i want to convert a gif to mp4 then combine it with audio
[18:19:03 CEST] <ChocolateArmpits> Process in parallel ?
[18:19:12 CEST] <furq> you can do that in one process anyway
[18:19:20 CEST] <ChocolateArmpits> ^
[18:19:20 CEST] <VectorX> furq how is that
[18:19:29 CEST] <ChocolateArmpits> by not rendering to mp4
[18:19:30 CEST] <furq> -i file.gif -i audio.mp3 out.mp4
[18:19:45 CEST] <furq> probably also with -shortest so it doesn't loop forever
[18:20:08 CEST] <ChocolateArmpits> add -stream_loop -1 before the gif though, it's bound to be the shorter of the two
[18:20:24 CEST] <VectorX> yes
[18:20:38 CEST] <furq> you don't need that with a gif
[18:20:41 CEST] <furq> it defaults to -loop 0
[18:20:48 CEST] <VectorX> but i want the gif to loop to the audio or the other way around
[18:20:52 CEST] <furq> right
[18:21:11 CEST] <furq> -i file.gif -i file.mp3 -shortest out.mp4
[18:21:27 CEST] <furq> that's all
[18:21:33 CEST] <VectorX> with that the gif playes ones and stops
[18:21:40 CEST] <VectorX> once
[18:21:51 CEST] <furq> it shouldn't
[18:22:24 CEST] <furq> oh nvm i'm looking at the wrong section
[18:22:34 CEST] <furq> -ignore_loop 0 -i file.gif -i file.mp3 -shortest out.mp4
[18:24:31 CEST] <VectorX> that worked one way now i need to find a longer gif and shorter audio and try it
[18:30:35 CEST] <furq> it shouldn't make any difference
[18:30:50 CEST] <furq> -shortest will always use the audio length because the gif has infinite length
[18:31:04 CEST] <furq> it'll only break if you have a gif which is set to not automatically loop
[18:35:35 CEST] <VectorX> i got a longer gif and shorter audio, yeah as you said it takes the time of the audio
[18:36:40 CEST] <VectorX> the gif used was https://giphy.com/gifs/dad-skateboarding-skateboard-iDpzYEtoQKniU with a 3 second audio clip, and it stops in 3 seconds
[18:38:59 CEST] <ThugAim> Hey guys. So from a package i installed I have ffprobe, ffmpeg-10bit, ffmpeg and ffserver... do I need anything but ffmpeg installed?
[18:40:42 CEST] <ChocolateArmpits> ThugAim, what do you want to do?
[18:42:55 CEST] <arpu> hello how can i use VPX_VBR with libvpx vp9 ? (vpxenc i can set end-usage=0)
[18:43:33 CEST] <ThugAim> current goals is to join files from multiple directories listed in a text file and the other is to figure out how to do streaming
[18:45:14 CEST] <ChocolateArmpits> ThugAim, then ffmpeg is pretty much all you need, though I usually keep ffprobe for file analysis
[18:45:31 CEST] <arpu> found my options .... set -b:v make the trick usage vbr
[19:02:26 CEST] <hiihiii> hello. what's the best practice to normalize audio? I'm just using the volume filter not trying to do anything fancy.
[19:03:11 CEST] <ChocolateArmpits> hiihiii, best is to adjust the gain according to loudness
[19:04:35 CEST] <hiihiii> "volume=-6.0dB,volume=0.6" would work well but if, for some reason, ran it again on the output, the audio loses volume
[19:04:48 CEST] <hiihiii> so currently I'm just doing "volume=-6.0dB"
[19:05:07 CEST] <hiihiii> but not sure if that's even proper
[19:05:09 CEST] <ChocolateArmpits> hiihiii, why would you run the same filter on a filtered file again >
[19:05:42 CEST] <hiihiii> I don't really
[19:06:32 CEST] <hiihiii> but just in case I forget or figured that I messed up on something but do not have the original audio
[19:07:29 CEST] <hiihiii> I'm doing lossless conversions.
[19:09:49 CEST] <ChocolateArmpits> hiihiii, why not append something to the filename like "_filtered" and check for that ?
[19:11:24 CEST] <hiihiii> the extension serves that purpose
[19:12:02 CEST] <hiihiii> anyway, you said something about adjusting the gain. could you elaborate on that?
[19:12:21 CEST] <ChocolateArmpits> So how can you mess this up? To do it otherwise will require your script to have more stuff there
[19:13:18 CEST] <hiihiii> can we just forget about practical cases.
[19:13:45 CEST] <ChocolateArmpits> So use Sox --norm
[19:14:24 CEST] <hiihiii> "aresample=resampler=soxr,volume=-6.0dB" ???
[19:23:05 CEST] <ChocolateArmpits> hiihiii, No I mean use the Sox application instead of ffmpeg, it'll be easier than to do in ffmpeg
[19:23:20 CEST] <ChocolateArmpits> Sox has --norm parameter that normalizes to a particular level
[19:23:28 CEST] <ChocolateArmpits> with ffmpeg your script will balloon
[19:29:05 CEST] <hiihiii> ah ok
[19:29:31 CEST] <hiihiii> I actually don't mind it "balloon"
[19:36:46 CEST] <OzgrK> durandal_1707: thank you. i think i figured that out. may i also ask if you see any problem in the following command to continiously decrease frequency from 1000 to zero in 16 hours?
[19:36:48 CEST] <OzgrK> ffmpeg -f lavfi -i aevalsrc="sin((1000-t*0.0086805)*2*PI*t):s=48000:d=57600" -c:a libopus -b:a 128k sin1kto0in16h_128k.webm
[19:36:56 CEST] <OzgrK> where 0.0086805 is 1000 (base frequency) / 57600 (16hours in seconds) / 2 (not sure why honestly, because of completing sine waves full circle?)
[19:37:02 CEST] <OzgrK> and i had hard time to convince myself to divide to 2 at the end but otherwise the frequency starts to increase again after decreasing to zero in the middle of the total duration.
[19:37:20 CEST] <SneakySnake> Is there an option to speed up both the video and audio rate while keeping them in sync? I tried combining setpts and asetrate, but I can't figure out the magic ratio to keep the streams in sync.
[19:38:34 CEST] <furq> SneakySnake: -vf setpts=(123/456)*PTS -af atempo=456/123
[19:38:50 CEST] <SneakySnake> Hmm
[19:40:19 CEST] <SneakySnake> furq: This works for asetrate as well, right? I want to speed up both the tempo and pitch.
[19:41:12 CEST] <furq> yeah but it'd need to be 44100*(456/123)
[19:41:19 CEST] <furq> or whatever the original rate is
[19:41:22 CEST] <SneakySnake> Ah, right
[19:41:35 CEST] <furq> you might also want to use rubberband if you have a build with it
[19:41:44 CEST] <furq> iirc it's higher quality than atempo/asetrate
[19:42:01 CEST] <SneakySnake> I'll check out what ffmpeg makes of it first
[19:44:45 CEST] <ChocolateArmpits> hiihiii, well then use either loudnorm or ebur128 filter to get measured loudness and then adjust the gain using volume according to that. You can also use replaygain measurements
[19:45:07 CEST] <durandal_1707> ChocolateArmpits: why are you promoting sox here?
[19:45:40 CEST] <hiihiii> time for another rebuild
[19:46:25 CEST] <ChocolateArmpits> durandal_1707, ffmpeg doesn't have straightforward normalization ;)
[19:51:50 CEST] <SneakySnake> Gotta love streamable formats. My slow PC encodes the stream almost at the same rate as I can play it back in real time.
[19:58:34 CEST] <SneakySnake> lol
[19:58:40 CEST] <SneakySnake> my player caught up with ffmpeg
[20:05:50 CEST] <SneakySnake> furq: Many thanks! The streams are in perfect sync, and the audio quality sounds alright.
[20:07:34 CEST] <durandal_1707> ChocolateArmpits: its two pass process
[20:20:16 CEST] <furq> when did the "option mapping" stuff get added to https://www.ffmpeg.org/ffmpeg-codecs.html
[20:20:27 CEST] <furq> whoever added that: <3
[20:39:36 CEST] <relaxed> indeed! That is nice.
[22:18:08 CEST] <thor77> Hey, I'm using a Raspberry PI 2 (B) to relay a RTSP stream from an IP camera to nginx-rtmp with this command: "ffmpeg -i rtsp://x.x.x.x:xxxx/11 -vcodec copy -an -f flv rtmp://x.x.x.x/live/stream". If there's nothing moving in front of the camera everything works just fine, but as soon as I move the camera or there
[22:18:32 CEST] <thor77> 's a lot happening, i see "max delay reached. need to consume packet" and "RTP: missed 48 packets"
[22:18:46 CEST] <thor77> s/48/xx
[22:19:04 CEST] <thor77> is this a problem with the stream provided by the camera or is something a bottleneck on the rpi?
[23:05:11 CEST] <ShaneVideo> quick question, is there a flag to exit ffmpeg if a input video stream is missing, example "unspecified size". I am recording from an RTSP and sometimes the stream isn't ready when I try to capture. I want to exit instead of capturing a blank video
[23:13:36 CEST] <arpu> Detected librtmp style URL parameters, these aren't supported by the libavformat internal RTMP handler currently enabled. See the documentation for the correct way to pass parameters.
[23:13:42 CEST] <arpu> how can i set the timeout ?
[23:13:52 CEST] <arpu> input rtmp stream
[23:32:21 CEST] <ChocolateArmpits> ShaneVideo, did you try increasing analyzeduration or probesize ?
[23:32:53 CEST] <ShaneVideo> ChocolateArmpits I did, but same result, also what do they do?
[23:34:00 CEST] <ChocolateArmpits> they both are input options, analyzeduration tells how long to wait for the input to confirm format, probesize does the same but only with a specific amount of data
[23:34:33 CEST] <ShaneVideo> is there a way to have it exit if it doesn't confirm the format in the specified time
[23:34:40 CEST] <ShaneVideo> I want it to exit so I can restart the process
[23:34:58 CEST] <ChocolateArmpits> well you could try
[23:35:06 CEST] <ChocolateArmpits> inserting a video filter
[23:35:13 CEST] <ChocolateArmpits> or forcing a video codec
[23:35:26 CEST] <ChocolateArmpits> essentially add something that will come out in error
[23:35:39 CEST] <ChocolateArmpits> didn't see any specific option though
[23:35:44 CEST] <ShaneVideo> im doing a vcodec copy, would adding a filter or forcing a codec cause it to reencode?
[23:35:53 CEST] <ChocolateArmpits> yes
[23:36:24 CEST] <ChocolateArmpits> alternatively you can do -map 0:v
[23:36:31 CEST] <ChocolateArmpits> that should be compatible with -vcodec copy
[23:36:44 CEST] <ShaneVideo> ill try it! ty ChocolateArmpits
[23:36:46 CEST] <ChocolateArmpits> and will throw an error if there's no video stream present
[23:38:34 CEST] <ShaneVideo> that worked
[23:40:03 CEST] <ChocolateArmpits> np
[00:00:00 CEST] --- Sun May 21 2017
1
0
[00:13:23 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02 https://git.io/vHeyL
[00:13:23 CEST] <KGB> 13FFV1/06master 14ef51962 15Dave Rice: describe use of len in pseudo-code...
[00:35:54 CEST] <jkqxz> Um, what? Who has a posix_memalign() which doesn't work for that?
[00:56:44 CEST] <cone-357> ffmpeg 03James Almer 07master:1e8daf31e079: avcodec/hevc_parser: add missing call to ff_hevc_reset_sei()
[00:58:14 CEST] <jamrial> that fifo-muxer-tst test is failing randomly on every fate instance running with more than one thread
[10:51:30 CEST] <ubitux> > The null demuxer does not have a backing AVIOContext.
[10:51:35 CEST] <ubitux> what does this refer to?
[10:51:42 CEST] <ubitux> is it a typo for "null muxer"?
[10:51:53 CEST] <ubitux> i see no such thing as a null demuxer
[10:53:04 CEST] <ubitux> (refering to 44129e380)
[10:53:42 CEST] <ubitux> the diff looks related to an output so i'll assume it's the null muxer
[10:59:16 CEST] <wm4> yeah, must be a muxer
[10:59:41 CEST] <cone-280> ffmpeg 03Luca Barbato 07master:44129e38047b: avconv: Do not pass NULL to avio_tell
[10:59:42 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:313264ba2494: Merge commit '44129e38047b6a27291e487c2084894958c6f399'
[11:01:15 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:a895292f2734: mov: Convert to the new bitstream reader
[11:01:16 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:b1e7394ea042: rtp: Convert to the new bitstream reader
[11:01:17 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:4795e4f61f99: alac: Convert to the new bitstream reader
[11:01:18 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:aec4812cb3b3: Merge commit '4795e4f61f993940c5384044caff56cc15078698'
[11:02:49 CEST] <ubitux> who is responsible of the cuda code?
[11:02:58 CEST] <ubitux> next commit is related to nvenc (fb59f87ce72035b940c3f5045884098b9324e1b2)
[11:03:00 CEST] <wm4> BtbN or philipl
[11:03:25 CEST] <ubitux> it looks like we already handle that symbol but we don't use it
[11:03:37 CEST] <wm4> I bet we fixed that ourselves
[11:03:39 CEST] <BtbN> we use it a lot
[11:04:04 CEST] <ubitux> ah?
[11:04:09 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=be74ba648cf4063c9805ebe95e…
[11:04:13 CEST] <ubitux> i may not be grepping the proper symbol
[11:04:25 CEST] <BtbN> Seems to be the exact same commit I made myself
[11:04:35 CEST] <ubitux> oh
[11:04:39 CEST] <ubitux> it's because of "v2"
[11:05:00 CEST] <ubitux> any reason why it's not using v2?
[11:05:04 CEST] <BtbN> We are
[11:05:12 CEST] <BtbN> We already have that commit, so it's a noop
[11:05:16 CEST] <ubitux> ah
[11:05:18 CEST] <ubitux> ok ok
[11:05:25 CEST] <ubitux> do you have a hash to refer to?
[11:05:27 CEST] <BtbN> Well, not that commit, but I made the exact same change myself.
[11:05:31 CEST] <BtbN> The one I just linked
[11:05:50 CEST] <ubitux> ok
[11:05:52 CEST] <ubitux> thank you
[11:06:14 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/cuda/dynlink_loader.h…
[11:06:22 CEST] <BtbN> <- _v2 right there
[11:06:45 CEST] <ubitux> i see
[11:06:48 CEST] <ubitux> great, thanks!
[11:07:29 CEST] <cone-280> ffmpeg 03Luca Barbato 07master:fb59f87ce720: nvenc: Explicitly push the cuda context on encoding
[11:07:30 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:917853661f95: Merge commit 'fb59f87ce72035b940c3f5045884098b9324e1b2'
[11:08:16 CEST] <BtbN> I'm surprised libav didn't even have the PushCtx symbol before that
[11:08:22 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:54dcd2288546: als: Convert to the new bitstream reader
[11:08:23 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:545d14f06733: Merge commit '54dcd2288546e135986338107ea87db1fcedd633'
[11:09:51 CEST] <cone-280> ffmpeg 03Derek Buitenhuis 07master:00b775dda2b3: hevc: Mark as having threadsafe init
[11:09:52 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:426f5e66a6cb: Merge commit '00b775dda2b3f78ae60ff3278d3b3d6545883a83'
[11:15:02 CEST] <cone-280> ffmpeg 03Anton Khirnov 07master:296eff4d9dc5: zmbvenc: get rid of a global table
[11:15:03 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:52a4004d8b5f: Merge commit '296eff4d9dc53d441b672319524a051d04f4a8cf'
[11:18:41 CEST] <cone-280> ffmpeg 03Anton Khirnov 07master:b4a911c18996: mpegvideoenc: make a table const
[11:18:42 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:19bb2cade5c8: Merge commit 'b4a911c189962e563a09fb0efaf6fa9ab56263a4'
[11:18:43 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:584366a43657: lavc/mpegvideoenc: reformat inv_zigzag_direct16 so the zigzag pattern is visible
[11:20:17 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:4d49a4c55054: apedec: Convert to the new bitstream reader
[11:20:19 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:fd8de7f2d8c3: dxtory: Convert to the new bitstream reader
[11:20:19 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:e5630ce5b122: Merge commit 'fd8de7f2d8c31195d309247cb129c0ad787ef76e'
[11:22:13 CEST] <cone-280> ffmpeg 03Dave Yeo 07master:7ff018c1cb43: OS/2: Try to commit memory above 1GB
[11:22:14 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:42ed79a2294c: Merge commit '7ff018c1cb43a5fe5ee2049d325cdd785852067a'
[11:23:30 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:5c0e2b13eb79: swscale-test: const correctness for pointer variable
[11:23:31 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:5d986609ba47: Merge commit '5c0e2b13eb79b455b15355d64f7993b0f66ea9ec'
[11:24:57 CEST] <nevcairiel> BtbN: do you have any idea whats this v2 stuff is about anyway? did they slightly change the signature at some point?
[11:26:13 CEST] <BtbN> As they just #define the function name to the v2 on in the official headers, at least the signatur is identical
[11:26:23 CEST] <BtbN> I'd guess they changed some behaviour in an incompatible way
[11:28:51 CEST] <nevcairiel> some things in the headers change type defs based on __CUDA_API_VERSION defines, but that seems to be mostly about CUdeviceptr
[11:29:53 CEST] <nevcairiel> (which they made 64-bit on 64-bit systems, previously it was 32-bit everywhere, probably an oversight in early API development)
[11:31:06 CEST] <BtbN> Yeah, might actually be about the devptr size
[11:31:50 CEST] <BtbN> At least the first batch of _v2 within __CUDA_API_VERSION >= 3020
[11:31:58 CEST] <BtbN> are all memory management functions
[11:32:07 CEST] <BtbN> alloc/free/copy/array/tex
[11:51:59 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:b83aea73404f: des-test: Pass the proper types to av_des_*() functions
[11:52:00 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:6a3538bb233e: Merge commit 'b83aea73404f6f9314e72fe5d6238deaffa12b2c'
[11:53:39 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:6668bc80b5ee: mpc: Convert to the new bitstream reader
[11:53:40 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:e7f24c9ffc6a: wavpack: Convert to the new bitstream reader
[11:53:41 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:b061f298f7f2: truemotion2rt: Convert to the new bitstream reader
[11:53:42 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:2e0e150144d6: magicyuv: Convert to the new bitstream reader
[11:53:43 CEST] <cone-280> ffmpeg 03Alexandra Hájková 07master:381a4e31a6b8: tak: Convert to the new bitstream reader
[11:53:44 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:89d277af00f5: Merge commit '381a4e31a6b801a046e38b0e2b08fb61499157a7'
[11:58:09 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:bf38959a30ec: configure: Move optflags checks to a more sensible place
[11:58:10 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:f78f3df7e01c: Merge commit 'bf38959a30ecba4e4ee95d4f2a80ba7ece4f34be'
[12:00:47 CEST] <cone-280> ffmpeg 03Diego Biurrun 07master:9bf262f4c6e1: configure: Use proper compiler-specific speed flags for hostcc
[12:00:48 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:2fbeb42df358: Merge commit '9bf262f4c6e14f43f291cdb745ed372884ee2a7f'
[12:01:36 CEST] <cone-280> ffmpeg 03Luca Barbato 07master:562ef82d6a7f: fifo: Return the correct AVERROR value
[12:01:37 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:c909b77fe364: Merge commit '562ef82d6a7f96f6b9da1219a5aaf7d9d7056f1b'
[12:02:07 CEST] <cone-280> ffmpeg 03Martin Storsjö 07master:f96d07f4ec41: configure: Add quotes around a variable which might be empty
[12:02:08 CEST] <cone-280> ffmpeg 03Clément BSsch 07master:55b56a8d6a06: Merge commit 'f96d07f4ec4193fb5293d7ac8f1324aac3c3ea07'
[12:59:33 CEST] <JEEB> does anyone here have any recommendations on cameras for HDR video sample creation?
[13:15:17 CEST] <cone-280> ffmpeg 03Michael Niedermayer 07master:2ccd2c9003c7: avcodec/aacsbr_fixed: Fix multiple runtime error: left shift of negative value -407
[13:15:18 CEST] <cone-280> ffmpeg 03Michael Niedermayer 07master:3fb104f4476a: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 150 is too large for 32-bit type 'int'
[13:23:16 CEST] <kierank> JEEB: sony f65
[13:23:18 CEST] <kierank> but aint cheap
[13:23:24 CEST] <kierank> blackmagic if you are cheap
[13:24:17 CEST] <JEEB> alright. I was looking at a panasonic that's getting a HLG update in July
[13:24:41 CEST] <JEEB> but > buying without being able to assess
[13:32:51 CEST] <wm4> $65,000
[13:32:53 CEST] <wm4> woah
[13:33:20 CEST] <nevcairiel> its pro hardware
[13:33:28 CEST] <JEEB> yea
[13:33:45 CEST] <JEEB> the panasonic I was looking was like $2,500 with a lense
[13:34:44 CEST] <nevcairiel> (not to mention that its 60fps 8K)
[13:35:40 CEST] <JEEB> yea
[14:41:26 CEST] <durandal_1707> atomnuker: wrote that audio filter?
[14:44:30 CEST] <atomnuker> crap, its friday
[15:13:55 CEST] <durandal_1707> and tommorow is saturday
[15:14:28 CEST] <ubitux> https://www.youtube.com/watch?v=kfVsfOSbJY0
[15:14:55 CEST] <ubitux> jamrial: cool for raise major :)
[15:15:13 CEST] <jamrial> good ridance :p
[15:15:27 CEST] <nevcairiel> elenril has also made a patch for the cropping bug, maybe we can strike that line again soon from the file
[15:15:43 CEST] <jamrial> ubitux: i hate you for making me giving this thing a click
[15:16:02 CEST] <ubitux> ;)
[15:16:10 CEST] <durandal_1707> same
[15:17:55 CEST] <jamrial> nevcairiel: yeah, just tested it and it seems to work, so i'll cherry pick it and apply it alongside the skipped stuff once it's pushed to libav
[15:32:39 CEST] <cone-280> ffmpeg 03Muhammad Faiz 07master:162414cefee6: avfilter/graphparser: allow specifying filter@id as filter instance
[16:39:31 CEST] <DHE> are misaligned memory accesses grounds for being fixed in ffmpeg? I'm trying gcc's -fsanitize=... feature and it's showing some errors in a program
[16:41:49 CEST] <iive> DHE: unaligned sse access will segfault.
[16:42:19 CEST] <iive> DHE: however e.g. get_bits usues unaligned access specifically to avoid doble read and shift
[16:42:27 CEST] <DHE> no, just integer work
[16:42:43 CEST] <iive> sse2 has integer work.
[16:46:25 CEST] <DHE> oh, yeah that makes sense...
[16:52:32 CEST] <atomnuker> michaelni: got any idea why swr_get_out_samples(sws, 0) returns some number of samples but a call to swr_convert() doesn't actually reduce that count?
[16:53:04 CEST] <atomnuker> so the API user deadlocks if while (swr_get_out_samples(sws, 0) is used to flush sws
[16:53:55 CEST] <atomnuker> (it does decrement until it reaches something like 38 samples at which point it doesn't get any lower despite repeated calls to sws_convert)
[16:56:05 CEST] <kierank> use libspeexdsp
[16:56:06 CEST] Action: kierank runs
[16:58:16 CEST] <atomnuker> I think the issue is I gave it a non-null source (but 0 input samples)
[16:58:41 CEST] <atomnuker> if I use NULL the issue is swr_next_pts gives me junk
[16:58:53 CEST] <atomnuker> why are timestamps so fucking horrible retarded mess
[16:58:57 CEST] <atomnuker> they shouldn't exist
[16:59:29 CEST] <atomnuker> or at least they should be very stictly defined as current sample number
[17:01:32 CEST] <kierank> blame vfr
[17:01:49 CEST] <atomnuker> what the fuck, calling swr_get_out_samples after sws_convert with NULL, 0 increases
[17:02:37 CEST] <wm4> atomnuker: I think get_out_samples returns an upper bound
[17:03:02 CEST] <atomnuker> well crap, that makes sense
[17:03:02 CEST] <wm4> and swr_convert should at least filter 1 sample if get_out_samples > 0
[17:26:04 CEST] <atomnuker> also a thing which must die is our audio encoders taking non-planar formats as input
[17:27:18 CEST] <atomnuker> latency is irrelevant when you use frames, performance is irrelevant since only insane codecs with SIMD designed to encode non-planar samples are affected and it makes everything more difficult
[17:27:20 CEST] <kierank> most of them don't afaik
[17:27:28 CEST] <atomnuker> flac does, tta does, libopus does
[17:27:34 CEST] <kierank> lib*, sure
[17:27:38 CEST] <kierank> you can't do much there
[17:32:53 CEST] <BBB> DHE: it depends on what type if unaligned accesses
[17:33:29 CEST] <BBB> DHE: for vector, that should crash and be fixed. for scalar, I dont think we care much (see HAVE_FAST_UNALIGNED_*) since its valid on systems that use it
[17:33:38 CEST] <BBB> DHE: so -ENEEDMOREDETAIL :)
[17:34:10 CEST] <DHE> h2645_parse.c:56: if (!((~AV_RN64A(src + i) & // affected line, HAVE_FAST_UNALIGNED and HAVE_FAST_64BIT are true
[17:34:31 CEST] <DHE> and others, but this is representative
[17:35:33 CEST] <BtbN> Where does HAVE_FAST_UNALIGNED even come from?
[17:37:09 CEST] <DHE> it's in my config.h
[17:38:04 CEST] <DHE> fast_unaligned_if_any='aarch64 ppc x86'
[17:38:27 CEST] <DHE> so it sounds like gcc is being pedantic
[17:39:44 CEST] <jamrial> AV_RN* expect alignment
[17:40:55 CEST] <BBB> they expect alignment _or_ have_fast_unaligned
[17:41:04 CEST] <jamrial> no wait, that was AV_RN*A
[17:41:06 CEST] <BBB> they imply an aligned read
[17:41:20 CEST] <BBB> :)
[17:41:44 CEST] <BBB> DHE: given that FAST_UNALIGNED is true, I dont think its an issue and I Dont think we want to fix it, since theres a codepath for non-fast-unaligned also
[17:42:13 CEST] <BBB> DHE: its similar to simd optimizations; we all know SSE code doesnt work on arm yet we still allow it on supported systems because we know it works there
[17:42:35 CEST] <DHE> well, obviously. :)
[17:43:38 CEST] <DHE> so I'll just chalk this up as a gcc false positive
[17:43:45 CEST] <jamrial> or maybe that line should use AV_RN* then instead of AV_RN*A
[17:44:50 CEST] <BBB> jamrial: I dont think AV_RN*A implies the data is aligned, it implies the read is aligned
[17:45:07 CEST] <BBB> jamrial: that can be either because the data is aligned or because the system supports aligned reads from unaligned sources
[17:45:29 CEST] <BBB> jamrial: and here clearly the second is implied (and theres a code path if that condition is not true also)
[17:45:45 CEST] <nevcairiel> it definitely works either way
[17:45:57 CEST] <BBB> whether its worth it is a different question and could be argued either way
[17:46:02 CEST] <BBB> but hey, the code exists, so what do we care
[17:48:46 CEST] <jamrial> BBB: "The AV_[RW]NA macros access naturally aligned data in a type-safe way."
[17:48:50 CEST] <jamrial> so i guess that's what it assumes
[17:49:33 CEST] <BBB> that documentation is wrong :-p
[17:49:53 CEST] <jamrial> patch welcome :p
[17:50:03 CEST] <BBB> crap
[17:50:31 CEST] <nevcairiel> what it basically does is tell the compiler to access 32-bit like an 32-bit value, and such, which on some platforms (notably old arm) can expect proper alignment, but on x86 that should be fine anyway
[17:51:26 CEST] <BBB> see? nevcariel is an expert
[17:51:29 CEST] <BBB> he should send a patch instead
[17:51:33 CEST] <BBB> he much cleverer than me
[17:52:22 CEST] <nevcairiel> no clue how to describe that properly
[17:52:46 CEST] <nevcairiel> technically the statement is true, just that the natural alignment required on x86 is very low :p
[18:55:53 CEST] <philipl> BtbN: ordered myself a 1030
[18:56:17 CEST] <BtbN> Didn't see a real benefit compared to a 1050
[18:56:22 CEST] <BtbN> 30¬ cheaper, but meh
[18:59:49 CEST] <jamrial> power consumption maybe?
[19:01:40 CEST] <BtbN> they are both bus powered, and idle usage should be roughly identical
[19:05:28 CEST] <jamrial> BtbN: i see there's a fanless msi GT 1030, so that one should consume less than any 1050
[19:07:11 CEST] <BtbN> so far my 1050 hasn't been using its fans
[19:07:20 CEST] <nevcairiel> the max usage is definitely less, but you might as well not use it at 100% then =p
[19:09:06 CEST] <jamrial> i like how these are being sold as "e-sports GPUs"
[19:11:25 CEST] <nevcairiel> heh yeah they like to use that for low-end gpus
[19:18:08 CEST] <kierank> jamrial: it's like "sport" RAM
[19:18:39 CEST] <wm4> grrr so there was something almost like 1050 but without fans
[19:18:42 CEST] <wm4> would have loved that
[19:18:48 CEST] <wm4> next GPU is going to be AMD anyway, lol
[19:19:49 CEST] <jamrial> kierank: well, at least in this case it's an real label, since if all you're going to play is dota then they are indeed more than enough :p
[19:21:11 CEST] <nevcairiel> get trolled by hardware decoding so long, just buy the GPU where you might as well give up since it never works anyway? :D
[19:22:08 CEST] <jamrial> it works great, as long as you stick with h264 1080p :p
[19:22:24 CEST] <nevcairiel> i meant for the AMD choice :p
[19:22:52 CEST] <jamrial> i know, that's what i mean :p
[19:22:55 CEST] <nevcairiel> they managed to even screw up h264 decoding in their latest gen
[19:27:11 CEST] <kierank> i love trolling cheap hw h264 decoders
[19:27:39 CEST] Action: kierank throws High422 at the decoder
[19:27:52 CEST] <kierank> and remember that you can have 4:2:0 streams since profiles are meant to be a subset
[19:28:24 CEST] <nevcairiel> noone really does that
[19:28:43 CEST] <nevcairiel> and if its fully main/high compatible without using any new features, it would likely even work
[19:29:00 CEST] Action: kierank does it to troll people
[19:29:44 CEST] <BtbN> MY 1050 is crazy fast with nvenc
[19:30:00 CEST] <BtbN> Like, almost 900fps with 1080p
[19:42:48 CEST] <nevcairiel> the media chips are largely decoupled from the main gpu, so it runs similarly fast on all GPUs, and yeah its gotten really fast in recent generations
[19:43:14 CEST] <BtbN> 1050 (Ti) is even faster
[19:43:18 CEST] <BtbN> it's Pascal Gen. 2
[19:54:17 CEST] <wm4> I don't care for hw decoding, other than testing
[20:03:58 CEST] <kiloreux> I am trying to contribute to the project and would love if I could get any starting point guidance :D
[20:05:06 CEST] <JEEB> first step: build it!
[20:05:11 CEST] <jamrial> kiloreux: https://ffmpeg.org/developer.html#Contributing :)
[20:05:58 CEST] <kiloreux> I have actually already read that. I was looking more into a hint to familiarize myself with the codebase.
[20:06:16 CEST] <JEEB> depends on what you want to work on
[20:06:38 CEST] <JEEB> decoders? demuxers? filters? ffmpeg.c?
[20:07:03 CEST] <philipl> BtbN: so you got cuvid vp9 10bit verified on it?
[20:07:11 CEST] <BtbN> yes
[20:07:16 CEST] <BtbN> and 12bit
[20:07:21 CEST] <philipl> yay.
[20:07:36 CEST] <kiloreux> JEEB, which one of those needs most work? Or is the slowest?
[20:08:15 CEST] <kiloreux> I want to invest my time in something important for the project.
[20:08:36 CEST] <philipl> BtbN: I've got this super convoluted set up here because I insisted on using a mini-itx case. So I have a u.2 port as my only pcie expansion after the primary graphics card. So from there, it's a cable out to a breakout board that has a 4x slot on it and gets power from a sata power connector. I figure the 1030 is smaller and lighter and so less likely to fall over...
[20:09:29 CEST] <JEEB> kiloreux: haha. slowness usually means asm optimizations
[20:09:32 CEST] <jamrial> kiloreux: decoders can always use optimizations and missing features, like hevc
[20:09:39 CEST] <JEEB> which isn't usually easy
[20:10:00 CEST] <jamrial> some demuxers and muxers may be missing features
[20:10:20 CEST] <philipl> BtbN: and vp8 is not supported? The matrix implies it was in GP104 and then dropped forever.
[20:10:23 CEST] <JEEB> but yes, hevc is one of the slower ones
[20:10:33 CEST] <kiloreux> JEEB, I can try :) .
[20:10:37 CEST] <jamrial> mov/mp4, matroska, mpegts, all missing stuff to be feature complete
[20:10:45 CEST] <BtbN> I haven't actually tested that, but I think it's just fine?
[20:11:08 CEST] <kiloreux> jamrial, is there a way to know which stuff are "missing" from those?
[20:11:16 CEST] <JEEB> kiloreux: most people either miss something or find that something's broken
[20:11:28 CEST] <JEEB> and that's their first contribution
[20:11:59 CEST] <jamrial> reading the specs, looking at feature requests in the bug tracker, or TODO/FIXME comments in the code
[20:12:54 CEST] <kiloreux> jamrial, JEEB ,Thank you. How do you guys review pull requests?
[20:12:54 CEST] <jamrial> matroska is missing edit lists, mov/mp4 has that but it's kinda buggy, mpegts i think needed a couple fixes to properly handle opus
[20:13:02 CEST] <kiloreux> The process I mean.
[20:13:09 CEST] <jamrial> kiloreux: patches are sent to the mailing list, and reviewed there
[20:13:28 CEST] <kiloreux> Great. Thank you.
[20:16:30 CEST] <jamrial> kiloreux: basically, git send-email to send the patches, or the output created by git format-patch attached to the email
[21:16:36 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07master:7383a835e47c: avformat/aviobuf: Only downscale the buffer once it has been used
[21:16:36 CEST] <cone-157> ffmpeg 03Michael Niedermayer 07master:0cc6dd1b817b: avformat/id3v2: Use ffio_ensure_seekback() in id3v2_read_internal()
[00:00:00 CEST] --- Sat May 20 2017
1
0
[00:38:21 CEST] <JordiGH> How can I stitch together a bunch of jpgs losslessly? I'm trying to animate a fractal.
[00:38:44 CEST] <JordiGH> I don't want any smudging or artifacts. Every pixel counts. Every pixel is sacred.
[00:43:55 CEST] <JordiGH> Aha! https://video.stackexchange.com/questions/7903/how-to-losslessly-encode-a-j…
[01:08:56 CEST] <ThugAim> Hey guys, is there an activation issues with Gmail users?
[01:40:11 CEST] <ThugAim> mm got d/c so don't know if it was answered
[03:15:57 CEST] <maicod> Hi I demuxed a TS file and one of the streams is AC3 but doesn't play. Now windows MediaInfo says its PCM/Little Endian/AES3/2 Channel/48khz/20 bits depth. Is this file playable or convertable ? I've never seen it. Its not regular AC3
[03:19:44 CEST] <Trevor_> Hi, I have a tiff image file sequence I am trying to turn into an mp4, but I am getting "no such file or directory". Could it be because I installed ffmpeg on my C: drive and the tiff files are on a D: drive?
[03:21:46 CEST] <Trevor_> https://pastebin.com/XNauuzvY
[03:23:10 CEST] <maicod> Trevor: windows uses backslash in file paths
[03:23:48 CEST] <maicod> D:/BeginningIntro%%4d.tif should be D:\BeginningIntro%%4d.tif
[03:24:17 CEST] <Trevor_> thank you, I thought I already tried that. One sec :)
[03:24:30 CEST] <maicod> just something I immediately noticed
[03:26:41 CEST] <Trevor_> Using backslashes and %04d instead of %%4d I get this: https://pastebin.com/qd04KNPt
[03:27:12 CEST] <Trevor_> my file names have no spaces and start numbered "name0000.tif"
[03:27:59 CEST] <maicod> sorry that I don't know else what is wrong
[03:28:21 CEST] <Trevor_> would it be a problem because the files are on a different hard drive?
[03:29:08 CEST] <maicod> sorry got booted
[03:29:36 CEST] <Trevor_> would it be a problem because the files are on a different hard drive?
[03:29:47 CEST] <maicod> don't think so
[03:30:24 CEST] <maicod> could you changedir to that D:\ and then run the ffmpeg commandline with its full path ?
[03:31:06 CEST] <maicod> maybe that works
[03:31:08 CEST] <slalom> maicod: sounds like the stream in the TS is AES3-PCM and not AC3.. why do you think it's AC3?
[03:31:40 CEST] <maicod> slalom: tsDemuxer used that extention for the extracted file
[03:31:54 CEST] <Trevor_> I am a novice, let me say
[03:32:06 CEST] <maicod> trevor: we all are 'in a way' :)
[03:32:38 CEST] <maicod> trevor I lost the pastebin cause the freenode server d/c-ed on me
[03:32:52 CEST] <Trevor_> should I use %04d or %%4d? I saw both in my google searching
[03:33:00 CEST] <Trevor_> https://pastebin.com/qd04KNPt
[03:33:18 CEST] <maicod> Trevor: sorry I don't know either
[03:33:26 CEST] <maicod> I'll look at your pastebin
[03:33:58 CEST] <Trevor_> omg it's going
[03:34:04 CEST] <maicod> cool
[03:34:34 CEST] <maicod> did you change to D:\ and run ffmpeg from C:\Program Files\ffmpeg.exe (like that) ?
[03:35:01 CEST] <maicod> slalom: do you know how I can play or convert AES3-PCM ?
[03:35:12 CEST] <Trevor_> I typed ffmpeg -r 30 -i D:\BeginningIntro\BeginningIntro%04d.tif streamintro.mp4
[03:35:24 CEST] <maicod> cool !
[03:35:26 CEST] <Trevor_> it might have just been the forward slash lol
[03:35:34 CEST] <maicod> maybe
[03:35:38 CEST] <Trevor_> I wasn't using them before, I must have forgot to change it back
[03:35:53 CEST] <Trevor_> anyways, thank you very much person on the internet!! gl
[03:35:54 CEST] <maicod> good thing it works
[03:36:07 CEST] <maicod> no thanks :)
[03:41:15 CEST] <maicod> my TS stream contains a AES3-PCM track. Can that be played/converted ? So far all I get is white noise
[08:12:45 CEST] <stdint> I want to analysis encoded stream, showing the size of echo encoded frame
[08:13:16 CEST] <stdint> just showing the size of echo frame in a avc stream, and marked all its frame type, like I, P, B
[08:13:33 CEST] <stdint> could ffmpeg utils do that?
[11:48:09 CEST] <termos> i'm having issues transcoding aac audio and it seems to be related to this https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg.c#L840 based on this http://stackoverflow.com/questions/37239113/how-to-encode-audio-to-aac-with… is it something I need to take into account?
[13:02:48 CEST] <dannysmc95> Hi everyone, I have a question, I am currently trying to run this command: ffmpeg -f avfoundation -framerate 30 -i "0" -target pal-vcd ws://localhost:8082 to stream my mac's webcam to a socket, but I keep getting the following error: ws://localhost:8082: Protocol not found, I looked online and re-compiled with --enable-openssl flag, but still no use? Anyone know the problem?
[13:04:54 CEST] <dannysmc95> Also this command: ffmpeg -f avfoundation -framerate 30 -i "0" -b 0 ws://localhost:8081 doesn't work either, says: Unable to find a suitable output format for 'ws://localhost:8081' ws://localhost:8081: Invalid argument
[13:05:17 CEST] <BtbN> I'm not aware of ffmpeg being able to act as a websocket server.
[13:06:40 CEST] <dannysmc95> No it doesn't act as one it's able to stream to one
[13:06:44 CEST] <dannysmc95> BtbN: ^
[13:07:19 CEST] <dannysmc95> This thing here gives me a websocket relay: https://github.com/phoboslab/jsmpeg
[13:07:24 CEST] <BtbN> So you already have a ws server running on localhost:8081, waiting for a connection?
[13:07:36 CEST] <dannysmc95> BtbN: yes
[13:07:47 CEST] <BtbN> Then just use an propipate format via -f and hope for the best
[13:08:44 CEST] <dannysmc95> What do you mean by that? I thought what I was giving was usable? in the link above, that's what it says, but I have had to amend it to work with mac instead
[13:10:53 CEST] <zerodefect> At the moment, I'm transcoding a DV clip. I notice that DV field order is Bottom field. If I wan't to move that to Top field, what is the correct way to do that? I'm thinking that I may want to combine a DV clip and say MPEG2 clip together (different field orders). I've read a few snippets that some people will cater for this by transitioning each line of their decoded DV lower by 1 line
[13:10:53 CEST] <zerodefect> and leave black as the first line. Any suggestions on how this should be handled (or even if it needs to be handled specially)?
[13:15:42 CEST] <furq> !filter fieldorder @zerodefect
[13:15:42 CEST] <nfobot> zerodefect: http://ffmpeg.org/ffmpeg-filters.html#fieldorder
[13:16:01 CEST] <furq> dannysmc95: normally the output format is autodetected from the filename, but you're outputting to a url, so you need to provide one manually with -f
[13:16:09 CEST] <furq> e.g. -f mpegts or whatever it expects
[13:18:06 CEST] <zerodefect> nfobot: Thanks! I'll try this out.
[13:19:17 CEST] <dannysmc95> But I am doing -f avfoundation?
[13:19:20 CEST] <dannysmc95> for the mac webcam?
[13:19:43 CEST] <dannysmc95> furq: ^ Sorry maybe I am missing something but I see it like this:
[13:20:15 CEST] <dannysmc95> ffmpeg -f avfoundation -framerate 30 -i "0" is the configuration for the mac webcam?
[13:20:34 CEST] <furq> that's the input format
[13:20:37 CEST] <furq> you need an output format
[13:20:44 CEST] <dannysmc95> So I have to do another -f?
[13:20:47 CEST] <furq> yes
[13:20:52 CEST] <dannysmc95> Where abouts in the string?
[13:21:06 CEST] <furq> between -i "0" and ws://...
[13:21:31 CEST] <furq> assuming this even works at all which i have no idea about
[13:24:01 CEST] <dannysmc95> furq: IT WORKS!
[13:24:03 CEST] <dannysmc95> Thank you!
[13:24:12 CEST] <dannysmc95> This was the command in the end:
[13:45:48 CEST] <beaver545_> Hi, I'm having trouble encoding using h264_qsv, I setup using avcodec_find_encoder_by_name() and set up the CodecContext and open the encoder successfully with avcodec_open2(), however, when I send a frame to the encoder with avcodec_send_frame(), I get an exception thrown trying to execute the location 0x0
[13:46:27 CEST] <beaver545_> can anyone suggest what I'm missing as part of the setup for this to occur? When using x264 to encode, everything works fine.
[14:29:39 CEST] <dannysmc95> Hey, I was wondering when using this, I had issues with Safari (iOS) not playing audio? from a stream? Now I know this is a common issue, but is there any fixes for this?
[14:30:07 CEST] <dannysmc95> I've come to you for a collective answer from experienced people, if nothing from here I shall do some research
[14:32:38 CEST] <Guest25915> Hello, I'm trying to get ffmpeg libraries to work on android with Unity. Getting DllNotFoundException every time. After some research and testing, it seems like when a shared library has to import an other one (like libavcodec needs libavutil) the needed library fails to be imported successfuly. Any idea how to get it working ?
[14:48:10 CEST] <Guest25915> could it be libraries not loading in the correct order ? even if I doubt it's the problem
[15:15:54 CEST] <FishPencil> Does FFmpeg have an internal opus encoder now?
[15:16:22 CEST] <durandal_1707> yes
[15:16:38 CEST] <FishPencil> How is it used?
[15:17:23 CEST] <durandal_1707> like any other audio encoder
[15:18:27 CEST] <FishPencil> No additional configuration options are needed, and it can be used alongside a build with libopus included?
[15:20:01 CEST] <durandal_1707> yes, you just need to pick right encoder name
[15:20:30 CEST] <kerio> how does it compare?
[15:21:11 CEST] <durandal_1707> its better than native vorbis for sure
[15:22:23 CEST] <ackjewt__> Anyone knows if ffmpeg can add a timestamp (and possibly date) when outputting to stderr/stdout? e.g "[2017-05-19 10:10:10] Guessed Channel Layout for Input Stream #0.0 : hexadecagonal"
[16:11:00 CEST] <truexfan81> i need to know what was changed in the configure script recently, after doing a git pull today i can no longer compile ffmpeg in msys2 mingw64
[16:12:30 CEST] <truexfan81> i get this error even when i add --enable-cross-compile to my ./configure line as it suggests https://pastebin.com/tRWMqzCZ
[16:12:46 CEST] <DHE> I like to use: git log -p configure
[16:14:02 CEST] <truexfan81> all this was working perfectly until i did a git pull today, so i'd appreciate it if ffmpeg would fix whatever they broke
[16:15:18 CEST] <DHE> it helps if you could narrow it down
[16:16:22 CEST] <truexfan81> not sure how
[16:16:30 CEST] <truexfan81> i'm trying to compile git master
[16:16:54 CEST] <DHE> do you have the git versions that you originally ran? your 'git pull' command should begin with "Updating 1234567..abcdef" where those are the old and new versions
[16:18:12 CEST] <truexfan81> Updating f73ef3748e..162414cefe
[16:19:08 CEST] <furq> f73ef37 is from february
[16:19:17 CEST] <DHE> yep... bisecting will take longer than I thought
[16:19:30 CEST] <furq> so probably quite a lot of things have changed since then
[16:19:31 CEST] <truexfan81> which was the last time i had time to compile it
[16:19:38 CEST] <DHE> around 12 or 13 attempts required
[16:20:07 CEST] <DHE> truexfan81: so here's how it works. run: git bisect start ; git bisect good f73ef3748e ; git bisect bad 162414cefe
[16:20:36 CEST] <DHE> git checks out a version half way between the two and you build it. if it succeeds, you run `git bisect good` and if it won't build you run `git bisect bad`
[16:20:51 CEST] <DHE> it takes about 12 or 13 build attempts while it searches for the breaking point
[16:21:04 CEST] <furq> in the meantime, pastebin config.log
[16:21:10 CEST] <furq> and also don't use enable-cross-compile
[16:21:14 CEST] <truexfan81> Bisecting: 1261 revisions left to test after this (roughly 10 steps)
[16:21:15 CEST] <truexfan81> [5ce02f4c555a4ca03486bc8f59b52a78c5f9e961] Merge commit '47a795727f5433f5238a8a244cf181f61ea5af2c'
[16:21:39 CEST] <DHE> truexfan81: repeat until it's out of revisions to test and gives you a definitive answer
[16:21:46 CEST] <DHE> also yeah, the config.log it tells you about
[16:23:24 CEST] <truexfan81> i must be doing something woring cause revisions left to test is not getting smaller
[16:25:40 CEST] <truexfan81> config log https://pastebin.com/YkVNMikK
[16:26:03 CEST] <furq> ./configure: line 882: gcc: command not found
[16:26:13 CEST] <furq> i can't help but think this might be the problem
[16:27:13 CEST] <truexfan81> $ pacman -Ss gcc
[16:27:14 CEST] <truexfan81> mingw32/mingw-w64-i686-gcc 6.3.0-3 (mingw-w64-i686-toolchain) [installed]
[16:28:01 CEST] <truexfan81> perhaps the configure script just needs to know where to find it?
[16:28:16 CEST] <furq> can you run it from that prompt
[16:29:28 CEST] <truexfan81> furq: run which?
[16:29:33 CEST] <furq> gcc
[16:29:55 CEST] <truexfan81> lol command not found okie
[16:30:22 CEST] <furq> welcome to the wonderful world of msys
[16:30:34 CEST] <truexfan81> installing
[16:31:00 CEST] <truexfan81> it must have gotten removed when i removed something else
[16:31:08 CEST] <truexfan81> dep chains are fun
[17:11:22 CEST] <Guest25915> I have a libpostproc-52.so which is dependent of libutil-52.so, how can i setup libpostproc to look for libavutil-52.so and not libavutil.so.52.XX.XX.XX
[17:13:20 CEST] <BtbN> 52 is old, you sh ould update.
[17:13:34 CEST] <BtbN> And it will looks for libavutil.so.52, not the full version.
[17:13:39 CEST] <kepstin> Guest25915: and why (and how?) are you getting libraries with those names?
[17:13:53 CEST] <BtbN> Wild guess: Android. Does not support sonames.
[17:14:00 CEST] <Guest25915> I need to get ffmpeg libs to work on Android
[17:14:03 CEST] <BtbN> Most shitty linker I have ever seen.
[17:14:26 CEST] <Guest25915> I have the same problems with the newest version
[17:14:49 CEST] <Guest25915> every time a lib is called by an other on, Dllimport fails (on Unity3d)
[17:16:19 CEST] <BtbN> if you are really using version 52: Update it.
[17:16:23 CEST] <BtbN> That's a couple years old.
[17:16:52 CEST] <Guest25915> Ill give it a shot, but I have the same problem last time i tried with ffmpeg 3.3
[17:24:45 CEST] <kepstin> sure, but if you're solving the same problem, you might as well start with the newer library
[17:24:55 CEST] <Guest25915> wow it worked
[17:25:16 CEST] <Guest25915> thanks a lot, struggling with this for days
[19:02:32 CEST] <dannysmc95> Hey guys, is there a library that will allow me to do this command: ffmpeg -f avfoundation -framerate 30 -video_size 640x480 -pix_fmt uyvy422 -i "0:1" -f mpegts -codec:v mpeg1video -s 640x480 -b:v 1000k -bf 0 http://localhost:8081/<secret> but within nodejs, so I can parse the output etc?
[19:02:33 CEST] <__raven__> hi
[19:04:33 CEST] <__raven__> i am converting a pal (i25) to 50p with half vertical resolution using -filter_complex "[0]field=top[t];[0]field=bottom[b];[b][t]interleave" - do you know what the reverse option would be?
[19:08:35 CEST] <ChocolateArmpits> __raven__, look up tinterlace, it has several options there
[19:16:25 CEST] <__raven__> ChocolateArmpits: yes i think mode0 is the right one but i need to change the input field order
[19:16:52 CEST] <ChocolateArmpits> __raven__, you mean shift the fields ?
[19:16:59 CEST] <__raven__> ChocolateArmpits: yes
[19:17:00 CEST] <ChocolateArmpits> there's a "field" filter for that
[19:17:05 CEST] <ChocolateArmpits> wait
[19:17:07 CEST] <ChocolateArmpits> not that
[19:17:51 CEST] <ChocolateArmpits> fieldorder
[19:17:53 CEST] <ChocolateArmpits> that one
[19:22:50 CEST] <__raven__> sorry that was misleading. i need to change the INPUT order of the tinterlace
[19:26:24 CEST] <dannysmc95> Can anyone help: http://stackoverflow.com/questions/44075597/how-to-successfully-parse-the-o…
[19:27:16 CEST] <__raven__> ChocolateArmpits: or perhaps i dont and i need mode7 but i have no mode 7
[19:27:47 CEST] <c_14> dannysmc95: ffmpeg always logs on stderr, that's normal. as for output parsing it's not really meant to be parsed, it's not stable or anything
[19:27:58 CEST] <c_14> you can try the -progress callback
[19:28:05 CEST] <c_14> depending on what you want
[19:29:24 CEST] <dannysmc95> c_14: thanks for that, I just need the bitrate, size and fps
[19:29:57 CEST] <c_14> probably try -progress I think it has that. not sure anymore though
[19:30:38 CEST] <dannysmc95> Where do I put the flag? at the end?
[19:30:53 CEST] <dannysmc95> c_14: ^^ Just so I know where
[19:30:55 CEST] <c_14> before the output and after the input probably
[19:33:02 CEST] <dannysmc95> c_14: It seems to want me to post it to a URL? :/
[19:33:31 CEST] <dannysmc95> It says -progress url (global)
[19:33:58 CEST] <dannysmc95> And says it sends it to the url every second, but I don't really wish to be spamming a URL with updates? Is there anyway to catch it do you think?
[19:34:27 CEST] <c_14> you're in node, can't you just spawn a http listener?
[19:34:53 CEST] <dannysmc95> c_14: Hmmm that's not a bad idea, is a post request?
[19:35:18 CEST] <c_14> yeah
[19:35:22 CEST] <c_14> chunked post afair
[19:36:27 CEST] <dannysmc95> hmm okay, will have a go.
[19:38:01 CEST] <c_14> Oh, url doesn't need to be a url though. a file or pipe will work too
[19:38:38 CEST] <c_14> output looks like https://pb.c-14.de/t/kng.ROmJjN
[19:38:56 CEST] <dannysmc95> Can you give me an example sorry?
[19:38:58 CEST] <c_14> (bitrate and size aren't listed because I used the null output, it should be there for you)
[19:39:11 CEST] <c_14> ffmpeg -f lavfi -i testsrc -f null /dev/null -progress progress_file
[19:39:24 CEST] <c_14> you should also be able to use -progress pipe:fd or so
[19:39:37 CEST] <c_14> if you open a pipe in node beforehand
[19:39:47 CEST] <c_14> (or pipe to stdout, that should be open already)
[19:39:50 CEST] <__raven__> any way to achieve tinterlace=7 manually? i hav no mode 7 in this lib :/
[19:40:15 CEST] <dannysmc95> I am super nooby at nodejs, I am still learning it, how would I open a pipe for it to take the data?
[19:40:25 CEST] <dannysmc95> I am not very good with pipes and streams etc
[19:40:28 CEST] <dannysmc95> c_14: ^
[19:40:41 CEST] <c_14> dannysmc95: just use stdout for now, should work just fine (pipe:1)
[19:41:08 CEST] <dannysmc95> c_14: Sorry to be a pain, I am not sure what you mean?
[19:41:23 CEST] <dannysmc95> do I add -progress pipe:1
[19:41:26 CEST] <c_14> yes
[19:41:37 CEST] <c_14> then just use your stdout.on to process the output
[19:41:49 CEST] <dannysmc95> Will it always be pipe:1?
[19:41:53 CEST] <c_14> yes
[19:42:06 CEST] <dannysmc95> How come? as I am planning to add this to a larger program
[19:42:17 CEST] <c_14> because 1 is always stdout
[19:42:41 CEST] <dannysmc95> but what if there was another process running that was using stdout?
[19:42:51 CEST] <c_14> each process has its own stdout
[19:42:58 CEST] <c_14> and you're listening on the stdout from ffmpeg
[19:43:07 CEST] <dannysmc95> Ohhhhhh, I see, okay that makes sense
[19:43:11 CEST] <c_14> so even if your program is doing things with its stdout, ffmpegs will work fine
[19:43:47 CEST] <dannysmc95> c_14: I see thank you! So I think I should be able to split that via \n ?
[19:44:02 CEST] <c_14> yeah
[19:44:22 CEST] <c_14> each block should end with a progress=line, after that is a new block with updated values
[19:44:31 CEST] <c_14> *progress= line
[19:44:53 CEST] <dannysmc95> Ahh okay, I haven't been able to understand how buffers, and streams work yet. and yeah I see progress=continue
[19:48:39 CEST] <dannysmc95> Nice one c_14, thank you for this, has been a huge help, been so lost haha.
[19:49:00 CEST] <thebombzen> speaking of progress, is there a way to have ffmpeg output its stats in an easily parseable way (like JSON or flat or something)
[19:49:24 CEST] <thebombzen> or at least, more machine parseable than how it currently is
[19:52:31 CEST] <dannysmc95> thebombzen: I had help from c_14 and was able to get it to work
[19:52:42 CEST] <thebombzen> unrelated question
[19:52:44 CEST] <thebombzen> to yours
[19:52:48 CEST] <thebombzen> or rather inspirted by yours
[19:52:53 CEST] <thebombzen> inspired*
[19:53:03 CEST] <c_14> thebombzen: you mean what's output when it's finished encoding?
[19:53:53 CEST] <thebombzen> I mean the stats that are printed by -stats like this stuff: frame= 7134 fps=4454 q=20.1 Lsize= 7168kB time=00:04:45.32 bitrate= 205.8kbits/s speed= 178x
[19:54:30 CEST] <c_14> there isn't, but some of that is output by -progress
[19:56:29 CEST] <thebombzen> ah I see. it appears that I can do what I want with -progress pipe:2 -v error
[21:18:00 CEST] <__raven__> any idea?
[22:57:43 CEST] <durandal_1707> __raven__: doubleweave filter, just get new version
[23:12:13 CEST] <carrot> Hi folks. I read about -row-mt support on your website for libvpx-vp9 and tried to use it, but I'm getting "Unrecognized option 'row-mt'". Tried both 3.3.1 and HEAD (git-2017-05-19-0cc6dd1). This is the line I'm using: https://gist.github.com/CarrotCodes/f31dfe396e65691feeada535c7593d48 - works fine with tile-columns (which is was using previously) but I was getting abysmal performance
[23:12:27 CEST] <carrot> Entirely possible that I'm messing something simple up but not seeing it myself
[23:13:14 CEST] <DHE> it's also dependent on your version of VPX having the feature
[23:13:18 CEST] <DHE> which may be your problem
[23:14:39 CEST] <carrot> interesting, how might I find that? using macOS rather than Linux
[23:14:43 CEST] <kepstin> looks like you need libvps 1.6.2 or later, if using a release version
[23:14:49 CEST] <kepstin> libvpx*
[23:17:01 CEST] <kepstin> which given that there doesn't actually seem to be a 1.6.2 release yet, means that you have to use a git snapshot, i guess
[23:17:06 CEST] <carrot> aha, found a --HEAD option for libvpx so I'll try that
[23:17:58 CEST] <kepstin> (I personally use git snapshots of libvpx that correspond to whatever google included in the most recent chrome release; which is newer than the standalone libvpx releases)
[23:18:21 CEST] <carrot> yeah, seems like brew points to "https://chromium.googlesource.com/webm/libvpx"
[23:22:27 CEST] <carrot> that worked!
[23:22:35 CEST] <carrot> wow, it's considerably faster
[23:22:48 CEST] <carrot> struggled to get literally 1 fps with tile-columns previously
[23:22:52 CEST] <carrot> now cruising at 14
[23:23:17 CEST] <carrot> and it's actually using all my cores, so that's nice
[00:00:00 CEST] --- Sat May 20 2017
1
0
[00:01:55 CEST] <KGB> [13FFV1] 15michaelni closed pull request #62: describe pseudo-code (06master...06pseudo-code) 02 https://git.io/v9A0Q
[00:16:46 CEST] <jya> BBB: does ffvp9 supports profile 2 ?
[00:18:43 CEST] <KGB> [13FFV1] 15dericed opened pull request #63: update readme to link ietf versions of ffv1 (06master...06link-to-ietf-version) 02 https://git.io/v9p77
[00:21:46 CEST] <KGB> [13FFV1] 15dericed opened pull request #64: Fix typo in context (06master...06fix-typo-in-context) 02 https://git.io/v9p5O
[00:25:36 CEST] <nevcairiel> jya: it supports all profiles
[00:29:03 CEST] <KGB> [13FFV1] 15dericed opened pull request #65: describe use of len in pseudo-code (06master...06describe-len) 02 https://git.io/v9p5h
[00:29:52 CEST] <jya> nevcairiel: great to hear
[00:33:18 CEST] <jamrial> jya: you were working at mozilla, right?
[00:33:30 CEST] <jya> jamrial: still am
[00:34:58 CEST] <jamrial> jya: ever since commit 64ad44a381 vp9 in mp4 files created by ffmpeg don't play on firefox anymore. do you know if beta or the development build was already updated to support version 1 of the spec?
[00:37:32 CEST] <jamrial> version 0 (draft version, what we used to create and what firefox 53 supports) was deprecated and its usage is not recommended anymore
[00:37:56 CEST] <nevcairiel> i broke firefox? yay?
[00:37:57 CEST] <nevcairiel> :D
[00:38:26 CEST] <jamrial> you did! :D
[00:38:28 CEST] <nevcairiel> I do find it funny that this information is apparently crucial for playback
[00:38:33 CEST] <nevcairiel> our mov demuxer doesnt even read it at all
[00:38:48 CEST] <nevcairiel> all its information is informative, not required
[00:38:52 CEST] <jamrial> nevcairiel: probably the profile field
[00:41:02 CEST] <nevcairiel> interestingly I actually found that this needed updating when I was working on a way to convey extra stream information through DirectShow, so I stole the vpcC structure to send stream info in, and figured I might as well update movenc
[00:45:43 CEST] <jamrial> nevcairiel: firefox stable doesn't support 10bit files, so looking at the profile or bitdepth field in the vpcc atom is probably the fastest way to know if a file will play or not
[00:45:50 CEST] <nevcairiel> i guess
[00:46:09 CEST] <nevcairiel> thats kind of the same reason I wanted it, so I can check before I get the actual video stream if i shall use hardware decoding or software
[00:46:17 CEST] <nevcairiel> since switching after-the-fact is always a bit iffy
[00:49:37 CEST] <jya> jamrial: what commit id is that ffmpeg one?
[00:49:45 CEST] <jamrial> jya: yes
[00:50:36 CEST] <jamrial> it updates the muxer to the version 1 of the vp9 in mp4 spec
[00:56:26 CEST] <jya> jamrial: that commit adds two bytes to the vpcc box.
[00:56:31 CEST] <jya> I'll investigate
[00:56:49 CEST] <jya> do you have a file I can test?
[00:57:17 CEST] <nevcairiel> the specification of the box was changed, its now final and no longer a draft
[00:57:32 CEST] <nevcairiel> version f ield was incremented so applications can handle it sanely
[01:01:06 CEST] <jamrial> jya: just create any vp9 file with the mp4 muxer using git head. it will write the vpcc box using the version 1 of the spec
[01:01:23 CEST] <jamrial> https://github.com/webmproject/vp9-dash/blob/master/VPCodecISOMediaFileForm… the spec in question is stored here now
[01:01:44 CEST] <jamrial> i think it used to be in a doc file...
[01:02:46 CEST] <nevcairiel> one of these days I should teach movdec to read the HDR info, but alas I also don't have any files of that sort
[01:03:28 CEST] <jamrial> you mean the other two boxed defined in the spec?
[01:03:35 CEST] <nevcairiel> yeah
[01:03:37 CEST] <jamrial> i already wrote patches for both muxer and demuxer :p
[01:03:42 CEST] <nevcairiel> i see
[01:03:48 CEST] <jamrial> didn't send them yet. was waiting to remove the experimental tag
[01:03:56 CEST] <jamrial> when i found out firefox wasn't reading the files anymore
[01:04:50 CEST] <jya> jamrial: I created mozilla bug 1365787
[01:05:41 CEST] <jamrial> nevcairiel: https://www.youtube.com/watch?v=tO01J-M3g0U use youtube-dl to get the vp9 hrd version. it's webm with mastering metadata elements
[01:06:18 CEST] <nevcairiel> yeah webm i know
[01:06:23 CEST] <nevcairiel> but thats not mp4 :p
[01:06:36 CEST] <jamrial> but you can use that to remux using my patches :p
[01:06:41 CEST] <nevcairiel> that video is probably what everyone used to test
[01:07:42 CEST] <nevcairiel> the experiemental tag can probably indeed be removed now, the spec is pretty simple otherwise
[01:07:46 CEST] <jamrial> nevcairiel: https://github.com/jamrial/FFmpeg/tree/vp9_in_mp4
[01:08:13 CEST] <jya> box type 'vp_xx_'
[01:08:20 CEST] <jya> how do you manage that with mp4?
[01:08:22 CEST] <nevcairiel> if we wanted to, we could support vp8
[01:08:31 CEST] <nevcairiel> but not like anyone cares
[01:08:38 CEST] <jamrial> jya: cool, thanks
[01:09:03 CEST] <jya> or is that vpXX (vp08, vp09, vp10)
[01:09:16 CEST] <nevcairiel> its that
[01:09:25 CEST] <nevcairiel> the __ are part of the placeholder syntax
[01:09:31 CEST] <jamrial> wonder if vp10 will be used for av1
[01:09:51 CEST] <jya> i see... it's late here, better go to bed before I ask too many dumb questions
[01:10:16 CEST] <jya> we've just integrated av1 decoder in firefox fwiw (but only in webm of course)
[01:10:54 CEST] <nevcairiel> I see no point of doing that until the bitstream freezes, depending on what library version you build it plays only a small selection of files properly
[01:11:33 CEST] <jya> well, so long as the decoder version matches the encoder one, it plays :)
[01:11:58 CEST] <jya> more to do with being ready... resyncing is easy and can be easily uplifted. we just wanted to be ready
[01:12:09 CEST] <nevcairiel> supporting decoding today already just encourages idiots to start spreading files, and they'll be around for e ver and haunt us =p
[01:12:21 CEST] <kierank> yeah
[01:12:23 CEST] <kierank> i agree
[01:12:29 CEST] <kierank> you have to support all sorts of broken bitstreams
[01:12:31 CEST] <kierank> dangerous game
[01:13:26 CEST] <rillian> hi jya
[01:13:31 CEST] <nevcairiel> surprising noone send a libaom decoder for avcodec yet though
[01:13:52 CEST] <jamrial> nevcairiel: one was sent to libav long ago
[01:14:01 CEST] <jamrial> but onyly the codec id was committed
[01:14:12 CEST] <nevcairiel> yeah i saw the codec id
[01:14:32 CEST] Action: jya signing off
[01:14:37 CEST] <jamrial> later
[01:15:08 CEST] <nevcairiel> someone even added a riff tag for av1, do people really want avi to continue :(
[01:22:46 CEST] <Threads> death to avi !!
[01:30:00 CEST] <TD-Linux> it's still mostly the libvpx api
[01:30:05 CEST] <TD-Linux> would be good to get feedback on how to change the api
[01:53:16 CEST] <cone-050> ffmpeg 03James Almer 07master:5ff31babfccd: avformat/movenc: remove experimental check for VP9 streams
[01:53:25 CEST] <jamrial> nevcairiel: ^
[03:57:16 CEST] <cone-050> ffmpeg 03James Almer 07master:3e295e633c36: build: remove --enable-raise-major configure option
[03:58:00 CEST] <jamrial> ubitux: ^
[04:09:09 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07master:58ac7fb9c395: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int'
[04:09:10 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07master:25c81e4b737b: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[11:47:12 CEST] <wm4> nevcairiel: meh, I think your request is not unreasonable at all
[11:47:24 CEST] <wm4> seems to be a typical case of "I wrote this code and I'm not going to change it because"
[11:47:41 CEST] <wm4> but I'll keep out of the shitflinging
[12:44:38 CEST] <nevcairiel> and he wonders why noone likes him, two mails of actual concerns, and he just drops his shit and goes away crying
[12:57:20 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07release/3.0:f2afdab8e40a: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int'
[12:57:21 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07release/3.0:dac9ef7108ed: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[12:57:22 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07release/3.0:b33d01d8a253: Update for 3.0.8
[14:09:57 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07n3.0.8:HEAD: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8
[14:29:36 CEST] <durandal_1707> nevcairiel: i see no reason to have those functions check if frame is hw
[14:29:58 CEST] <durandal_1707> the functions should be simple
[14:33:35 CEST] <durandal_1707> michaelni: why rgb24 have 96 as alignment?
[14:40:19 CEST] <michaelni> durandal_1707, iam not 100% sure but i suspect this is due to using or the code having used width somewhere to achive the alignment, iam not sure theres anything that would break if tats chnaged
[14:42:16 CEST] <michaelni> code doing something to height*linesize/3 pixels would break but there is maybe no such code
[15:42:28 CEST] <nevcairiel> durandal_1707: like I said in one of the emails, it doesn't necessarily have to be that function, but somewhere in that generic functionality it has to check, or bad things happen
[15:46:59 CEST] <nevcairiel> but nicolas wasnt even interested in discussing the problem or potential solutions
[17:35:27 CEST] <tdjones> What is the best mechanism for concatenating frames from a bufferqueue for variable length packets? Should this be done in a similar way as the opus encoder creates its celt blocks?
[17:39:25 CEST] <arpu> hello does anyone understand this problem with webm cotainer https://github.com/google/shaka-packager/issues/172
[17:39:44 CEST] <arpu> tracks (unknown size)
[17:41:14 CEST] <atomnuker> tdjones: yes, just memcpy them together
[17:42:24 CEST] <alevinsn> nevcairiel: you there? what does vfwcap_defines represent in configure?
[17:44:37 CEST] <nevcairiel> its just a variable for a condition check
[17:45:41 CEST] <alevinsn> so, vfwcap_indev_deps depends on vfwcap_defines?
[17:53:42 CEST] <nevcairiel> thats what it says
[17:56:00 CEST] <alevinsn> regarding the line: vfwcap_indev_deps="vfw32 vfwcap_defines"
[17:56:23 CEST] <alevinsn> what does vfw32 represent? That's the name of the library--does a variable named vfw32 get indirectly defined
[17:56:38 CEST] <alevinsn> via the check_lib call?
[17:56:51 CEST] <nevcairiel> yeah check_lib sets it to available if the check succeeds
[17:57:10 CEST] <alevinsn> so, video for Windows support is essentially determined automatically
[17:57:21 CEST] <nevcairiel> pretty much
[17:57:33 CEST] <alevinsn> why is it done that way for VFW but not for decklink?
[17:57:45 CEST] <nevcairiel> because vfw is present on e very single windows system
[17:57:47 CEST] <nevcairiel> decklink is not.
[17:57:59 CEST] <alevinsn> well, after I installed the Windows 10 SDK
[17:58:07 CEST] <alevinsn> I noticed that it wasn't including vfw32.lib anymore
[17:58:13 CEST] <alevinsn> in the 10 directory
[17:58:20 CEST] <alevinsn> its only available in 8.1 as far as I can tell
[17:58:28 CEST] <nevcairiel> thats basically the general rule, if something depends on an external component, it doesnt get auto-enabled
[17:58:58 CEST] <alevinsn> nevcairiel: is that your experience with vfw32.lib?
[17:59:12 CEST] <nevcairiel> i have never used vfwcap and likely never will
[18:00:30 CEST] <alevinsn> well,I see for the msvc fate runs that you've done
[18:00:33 CEST] <alevinsn> you've setup
[18:00:44 CEST] <alevinsn> it is building vfwcap.o
[18:00:54 CEST] <alevinsn> which implies that it is finding vfw32.lib
[18:01:01 CEST] <nevcairiel> my 10sdk still has the lib, too
[18:01:14 CEST] <alevinsn> which Windows 10 SDK version are you using?
[18:01:24 CEST] <nevcairiel> 15063
[18:01:35 CEST] <nevcairiel> but i checked all 3 i have installed, and all have it
[18:01:56 CEST] <nevcairiel> which is 10586 and 14393 additionally
[18:02:13 CEST] <cone-357> ffmpeg 03Paul B Mahol 07master:5c9e12bc6d3e: doc/filters: add more ladspa examples
[18:03:29 CEST] <alevinsn> so odd, I see on one system, vfw32.lib is installed, but on the other, its not
[18:04:23 CEST] <alevinsn> on one of my systems, I mean
[18:08:07 CEST] <alevinsn> nevcairiel: when you installed the Windows 10 SDK, did you select everything to be installed?
[18:08:35 CEST] <alevinsn> I mean, all the components (performance SDK, etc)?
[18:10:03 CEST] <nevcairiel> nah, i selected whatever i thought made sense
[18:11:07 CEST] <nevcairiel> which is basically the desktop development workflow and a few extra packages
[18:11:13 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:d32ebce8fd79: avcodec/pixlet: Fix reading invalid numbers of bits
[18:11:14 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:a173f484b52e: avcodec/fic: Fix multiple runtime error: signed integer overflow: 5793 * 419752 cannot be represented in type 'int'
[18:11:15 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:e434840fd4b3: avcodec/mimic: Use ff_set_dimensions() to set the dimensions
[18:11:21 CEST] <alevinsn> which is what I did as well, so odd, I picked 64-bit and 32-bit, and it still didn't install vfw32.lib and a bunch of other files
[18:15:51 CEST] <alevinsn> ok, thanks for your help. I should have taken the time to better understand that stuff before I submitted the vfw configure patch.
[18:16:07 CEST] <durandal_1707> vfw?
[18:16:10 CEST] <nevcairiel> what exactly was the patch supposed to solve anyway?
[18:16:28 CEST] <nevcairiel> it doesnt seem to do anything much
[18:16:34 CEST] <alevinsn> well, one change was reasonable--if vfw indev is disabled
[18:16:38 CEST] <alevinsn> it wouldn't do the vfw checks
[18:16:42 CEST] <alevinsn> but, I also changed it to use require
[18:16:46 CEST] <alevinsn> instead of check_lib
[18:16:49 CEST] <alevinsn> and that part was wrong
[18:17:13 CEST] <nevcairiel> that extra condition while not technically wrong seems still a bit superflous
[18:17:54 CEST] <alevinsn> looking through configure, what is it about vfwcap_indev that causes it to be turned on by default
[18:18:07 CEST] <alevinsn> whereas decklink indev/outdev is turned off by default?
[18:18:32 CEST] <nevcairiel> components like an indev are always enabled by default, as long as their dependencies are available
[18:19:01 CEST] <alevinsn> even true for decklink?
[18:19:06 CEST] <nevcairiel> and vfwcap doesnt have much of a dependency
[18:19:18 CEST] <nevcairiel> but the decklink indev has a dependency that needs explicit enabling
[18:19:47 CEST] <alevinsn> ah, I get it
[18:21:07 CEST] <alevinsn> regarding if the vfwcap indev is specifically disabled, there isn't much point, but it might save a little time on configure
[18:21:11 CEST] <alevinsn> by not doing those checks, I guess
[18:21:17 CEST] <alevinsn> vfw32.lib is only needed for vfwcap
[18:21:25 CEST] <alevinsn> nothing else in ffmpeg uses vfw
[18:21:30 CEST] <nevcairiel> yeah not really something worth uglying up all the things for
[18:21:37 CEST] <nevcairiel> rather stay consistent with all other library checks
[18:22:11 CEST] <alevinsn> ok, I'll discard that patch--I had thought I was doing something useful, but it was just wrong
[18:22:50 CEST] <alevinsn> have to go, thanks, bye
[18:53:28 CEST] <JEEB> (32
[23:16:21 CEST] <cone-357> ffmpeg 03Paul B Mahol 07master:79bf4d1450c1: avfilter/af_sofalizer: avoid casting
[23:16:22 CEST] <cone-357> ffmpeg 03Paul B Mahol 07master:f5e5c531170f: avfilter/af_sofalizer: make lfe gain user configurable
[00:00:00 CEST] --- Fri May 19 2017
1
0
[00:00:05 CEST] <debianuser> cpu usage?
[00:00:28 CEST] <kms_> cpu is ok 50%
[00:01:27 CEST] <kms_> command is ffmpeg -f v4l2 -s 640x360 -r 5 -i /dev/video0 -f alsa -ac 1 -i hw:2,0 -c:v libx264 -preset ultrafast -acodec libmp3lame -ar 44100 -b:a 128k -ar 44100 -b:v 300k -g 10 -f flv rtmp://....
[00:14:13 CEST] <kms_> after time speed is slowdown speed=0.997x
[00:14:23 CEST] <kms_> and error is coming
[00:16:23 CEST] <kms_> but why after 20-30 sec speed is slowdown if cpu is ok
[00:34:34 CEST] <debianuser> kms_: Does it still happen if you, e.g. reduce encoded image size to 160x90? E.g. ffmpeg -f v4l2 -s 640x360 -r 5 -i /dev/video0 -f alsa -ac 1 -i hw:2,0 -vf scale=160:90 -c:v libx264 -preset ultrafast -acodec libmp3lame -ar 44100 -b:a 128k -ar 44100 -b:v 300k -g 10 -f flv rtmp://....
[00:35:44 CEST] <debianuser> (that should reduce cpu usage of x264 encoder, you're supposed to see like 10% usage)
[00:35:56 CEST] <debianuser> *10% cpu usage
[00:50:54 CEST] <kms_> hmm... on this computer i have same problem with -vf scale=160:90, but on more powerful computer i have no problem (speed is always 1x)
[00:54:13 CEST] <kms_> oh no
[00:54:31 CEST] <kms_> on powerful pc i try on builtin webcam
[00:54:51 CEST] <kms_> but on same webcam i have same error
[00:56:21 CEST] <debianuser> And CPU usage is rather low, like 10% CPU, right?
[00:58:29 CEST] <kms_> cpu 20%, on builtin webcam i have no error, but on usb webcam(s) i have this error
[01:04:48 CEST] <kms_> (go to reboot)
[01:13:21 CEST] <kms_> yes, this problem on different usb webcams
[01:13:33 CEST] <kms_> cpu 4%
[01:13:55 CEST] <kms_> but no problem on builtin webcam
[01:15:05 CEST] <kms_> oops
[01:15:31 CEST] <kms_> now error on builtin webcam
[01:16:15 CEST] <kms_> cpu 2-3 % it is strange
[01:19:00 CEST] <dystopia_> speed should be 1x
[01:19:17 CEST] <dystopia_> your encoding from a live source in real time, at a low resolution
[01:19:29 CEST] <dystopia_> so your never going to go faster than real time
[01:48:37 CEST] <debianuser> kms_: It could be your webcam provides samples with a little bit lower frame rate, e.g. 4.997 fps instead of 5 fps, then if ffmpeg syncs audio to video, it'd read audio from buffer slower than it gets filled, and you'll get overrun. That's just a guess, but if that's right - you need to switch ffmpeg to sync video to audio stream instead. And I don't know how to do that.
[01:48:47 CEST] <debianuser> Does anyone knows if ffmpeg uses video or audio as a base timeline? And if uses video - is possible to switch it to using audio as a base?
[02:16:10 CEST] <k1ngdom> Hello
[02:17:03 CEST] <k1ngdom> I am having issue with ffprobe and encrypted hls. i need to get the bitrate but ffprobe is always returning 0
[02:21:13 CEST] <k1ngdom> http://paste.ubuntu.com/24595934/
[03:16:11 CEST] <k1ngdom> anyone?
[05:54:57 CEST] <hurricanehrndz> anyone know if john's static built works with vaapi
[08:47:38 CEST] <mkozjak> hello. is there a way to use a hls aes encryption feature from libavformat in my own code which includes avformat.h somehow? is there a way to use hls_write_* methods from hlsenc.c from the outside somehow?
[08:55:35 CEST] <mkozjak> should i be using AVOutputFormat's struct methods?
[11:21:53 CEST] <teratorn> is there a way to *accurately* cut a section of video (from non-keyframe to non-keyframe) while using the copy codec for the middle part of video that presumably doesn't really need to be re-encoded?
[11:32:18 CEST] <Mavrik> teratorn, no.
[11:32:33 CEST] <Mavrik> How would that work? :)
[11:32:39 CEST] <teratorn> Mavrik: figured. but do you think it is theoretically possible?
[11:32:54 CEST] <Mavrik> Where would you get information for reconstructing frames before the first keyframe? :)
[11:33:17 CEST] <Mavrik> Maybe if you'd patch the encoder in a way that it would only reencode stuff before first keyframe.
[11:33:57 CEST] <teratorn> Mavrik: hmm well, those GOPs in the middle stand on their own don't they? so you would have to decode and reencode the frames from the starting seek point to the first GOP, and re-encode the frames from right after the last GOP until the ending cut point
[11:34:33 CEST] <Mavrik> Yes, that's what I meant.
[11:34:34 CEST] <Mavrik> :)
[11:39:37 CEST] <teratorn> heh, such selling points http://www.fame-ring.com/sk/accurate.frames.html
[11:40:16 CEST] <teratorn> maybe i'll get the chance to build a tool with ffmpeg that can do it :)
[12:21:31 CEST] <Wallboy> Anyone know would could cause scale2ref to have different results with the exact same ffmpeg command? I'm encoding a watermark over my video and I noticed the watermark was stretched, however after I ran the exact same ffmpeg command it came out non stretched and fine. What sort of ffmpeg voodoo could cause that?
[12:53:29 CEST] <durandal_1707> Wallboy: pastebin full command output
[12:59:50 CEST] <Wallboy> i already tossed the video that had the problem, i couldn't duplicate the error after trying to encode it 10 times they all came out fine. I had -v quiet on as well so couldn't see what happened
[13:01:02 CEST] <Wallboy> could fifo filters cause any issues?
[13:01:59 CEST] <durandal_1707> fifo just eat memory if bugs or missused
[13:04:16 CEST] <Wallboy> i have quite a long filter chain. can ffmpeg do each filter in slightly different order?
[13:08:15 CEST] <DHE> no. each filter will be deterministic. if threading is available it's one filter using threads for faster processing of a single frame but the overall pipeline process is unchanged
[13:14:25 CEST] <Wallboy> https://pastebin.com/KPTbKwmT this is the ffmpeg command. It's slightly different per video used as certain calculations for things are done before hand to figure out logo placement, audio padding, etc. anull/null are replaced with the correct filter if specified in my program
[13:25:00 CEST] <Wallboy> so when the logo was stretched something with the math of: "scale2ref=iw*0.5:(iw*0.5)*(351/1073)" must have been wrong. The logo was stretched about 25% more vertically
[13:25:54 CEST] <Wallboy> logo is 1073x351 w/h
[13:37:15 CEST] <Wallboy> i've heard of weird things happening when using odd numbers for resolutions. maybe it was a case of that
[13:38:09 CEST] <Wallboy> then again, in this case i don't see why since it's just used in an expression
[13:38:41 CEST] <zerodefect> I've written some sample code to decode a DV video clip and encode it to MPEG. The clip is that of a testcard. I notice that the colors on the output are slightly off from the original colors, but in the correct region...
[13:39:28 CEST] <zerodefect> I've checked the AVCodecContext and the AVFrame from the decoder and the color ranges are all unspecified. The documentation seems to imply that the decoder will set these values. Is that correct?
[13:39:29 CEST] <Wallboy> i'm no expert on that, but I believe that would happen when you switch yuv formats
[13:39:52 CEST] <zerodefect> Yeah, I'm pretty confident that the input clip is using ITU-R BT601-6 525
[13:40:10 CEST] <zerodefect> Sorry, ITU-R BT601-6 625 not 525
[13:41:07 CEST] <Wallboy> output shows the same?
[13:42:30 CEST] <zerodefect> Wallboy: Sorry can you clarify? Do you mean the encoded picture colors?
[13:42:58 CEST] <Wallboy> ya what format is the encode at after?
[13:44:16 CEST] <zerodefect> So I encode it to using a YUV422P with m2v encoder, but I don't explicitly set any of the colour ranges anywhere.
[13:44:41 CEST] <zerodefect> It's being wrapped in a .ts container
[13:49:54 CEST] <zerodefect> Is it common for the color properties not be set in the decoder?
[13:51:17 CEST] <Wallboy> https://ffmpeg.org/ffmpeg-all.html#colormatrix maybe that would help?
[13:53:17 CEST] <Wallboy> the colorspace filter below that seems of interest as well
[13:55:13 CEST] <zerodefects> (changed username). Thanks I'll dig a bit more. I have a few things I can try.
[13:56:51 CEST] <Wallboy> it might be a PC Levels vs TV Levels thing instead
[13:57:07 CEST] <Wallboy> color_range integer (decoding/encoding,video)
[13:57:07 CEST] <Wallboy> If used as input parameter, it serves as a hint to the decoder, which color_range the input has.
[14:05:31 CEST] <zerodefects> Ok. Thanks. I'll check that out
[14:21:02 CEST] <Tatsh> hey all
[14:21:10 CEST] <Tatsh> anyone figured out with alsa how to record 24-bit 96 KHz?
[14:21:45 CEST] <Tatsh> i'm trying to record from my card with pcm_s32le and then undoing that bit-depth so i can pass it to flac live (flac can't do 32)
[14:22:01 CEST] <Tatsh> when i use -f alsa -i hw:0,0 it always gives an input of pcm_s16le
[14:22:13 CEST] <Tatsh> i don't see a way to force the bit depth for this?
[14:22:18 CEST] <Tatsh> or format in general
[14:24:16 CEST] <Tatsh> hmm
[14:24:19 CEST] <Tatsh> -acodec before the -i
[14:26:24 CEST] <Tatsh> ffmpeg -f alsa -ar 96000 -acodec pcm_s32le -i hw:0,0
[14:26:34 CEST] <Tatsh> flac supports storing this format after all
[14:26:48 CEST] <Tatsh> cuts the size by 50% on default settings :)
[14:28:02 CEST] <Tatsh> actually, flac doesn't support 32-bit, but ffmpeg automatically converts
[14:28:08 CEST] <Tatsh> very good
[16:32:21 CEST] <maziar> hi every one
[16:35:25 CEST] <Guest57739> Hello, I am trying to use ffmpeg shared libraries in Unity since days using a c# wrapper to be able to decode raw h264 frames. It works great on Windows but I'm struggling for days to get it working on Android. What ever I try I always end up with a DllNotFoundException. Home made shared libraries (libTest.so) works great. Anyone here managed to do what I'm trying to do ?
[16:36:36 CEST] <Guest57739> the file -L command says that my lib is 32bits ARM EABIS shared library
[16:47:16 CEST] <kepstin> Guest57739: the issue is probably that one of the libraries which ffmpeg is linked to is missing. Run `ldd libavcodec.so` (or whichever library you're trying to load) and see if there's anything with 'not found' on the right side
[16:47:54 CEST] <Guest57739> in a shell you mean ?
[16:49:25 CEST] <Guest57739> I am not using the executable file, just trying to use the shared libraries in a Unity project
[16:49:54 CEST] <Guest57739> just tried 'ldd libavcodec.so' : 'not a dynamic executable'
[16:52:45 CEST] <mutowang> Could you share the Exception stack log?
[17:03:55 CEST] <Mavrik> Guest57739, you need to use ldd from the NDK for your architecture
[17:03:58 CEST] <Mavrik> not the system one.
[17:04:10 CEST] <Mavrik> or ndk-depends
[17:05:29 CEST] <Guest57739> ok i will try this in a moment, thanks
[17:07:13 CEST] <Guest57739> I have no ldd in toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/
[17:08:36 CEST] <Guest57739> I will give you the stack log in a moment
[17:09:39 CEST] <Mavrik> did you try ndk-depends?
[17:10:31 CEST] <kerio> what's the best way to encode a terminal screen with h264?
[17:10:40 CEST] <kerio> libx264 with `-tune stillimage`?
[17:13:43 CEST] <Guest57739> (I have all libs in a single folder) said missing libavutil.so. I renamed all my libs so <version> is not part of the name anymore
[17:13:52 CEST] <Guest57739> and now everything is found
[17:14:02 CEST] <Guest57739> I will try this in a moment on Unity
[17:14:12 CEST] <Guest57739> Thanks for the tip
[17:25:15 CEST] <thebombzen> kerio: the most important thing is to use yuv444p
[17:25:18 CEST] <thebombzen> and not yuv420p
[17:26:37 CEST] <Guest57739> I come back to you shortly, had to reinstall android studio; takes some time
[17:27:06 CEST] <thebombzen> kerio: when I record a terminal, in realtime I just do it losslessly. if you have an 8bit libx264, do -c libx264rgb -preset ultrafast -qp 0
[17:28:21 CEST] <thebombzen> when you want to recompress it, I use -pix_fmt yuv444p -c:v libx264 -preset:v veryslow -qp:v 0
[17:28:52 CEST] <thebombzen> You can actually record losslessly from the terminal without an enormous bitrate cause nearly everything is the same
[17:29:02 CEST] <thebombzen> inter prediction is also very easy
[17:30:17 CEST] <thebombzen> as for tuning, it doesn't really matter, but I think best tuning is --tune touhou
[17:30:34 CEST] <thebombzen> which is specifically designed to preserve boundaries hard boundaries accurately
[17:31:03 CEST] <thebombzen> although the tune doesn't really matter at higher qualities and bitrates
[17:47:33 CEST] <furq> kerio: stillimage is probably the best
[17:47:39 CEST] <furq> although the best way is to not encode it to a video at all
[17:51:59 CEST] <PlanC> I've just found out about ffmpeg's built-in download function which is really cool
[17:52:19 CEST] <Guest57739> I will come back to you tomorrow if I'm still facing issues with ffmpeg, but you helped me a lot. I'm reinstalling Android Studio made a mistake and have to do it again, what a waste of time
[17:52:36 CEST] <PlanC> ffmpeg -i https://website.com/video.mp4 output.webm
[17:52:45 CEST] <PlanC> which downloads the remote file and converts it to webm
[17:53:01 CEST] <PlanC> it's a really cool feature but I've found a huge issue which is bandwidth limitation
[17:53:25 CEST] <PlanC> is there any way to set a download speed limit to the downloads since it's eating up my whole line slowing everything on my PC down?
[17:53:59 CEST] <PlanC> for example: ffmpeg -i https://website.com/video.mp4 --max-download-speed-kb 100 output.webm
[17:54:06 CEST] <furq> not within ffmpeg
[17:54:09 CEST] <furq> https://github.com/mariusae/trickle
[17:54:13 CEST] <furq> you can use something like that
[17:54:28 CEST] <kepstin> PlanC: if that's a problem you have in general, you might want to look at getting a router which can so smart qos, fix the problem as close to the source as you can :/
[17:54:45 CEST] <furq> i was going to suggest qos but it's probably not going to help much if it's one https connection causing issues
[17:54:51 CEST] <PlanC> furq: I actually spent a ton of time with trickle yesterday
[17:54:59 CEST] <furq> presumably from the same ip as the traffic he wants prioritised
[17:55:08 CEST] <furq> unless qos is much smarter now than the last time i messed with it
[17:55:09 CEST] <PlanC> furq: the problem is that since ffmpeg talks to the kernel directly it doesn't work
[17:55:16 CEST] <kepstin> well, what you actually want is smart queue management
[17:55:29 CEST] <PlanC> furq: https://superuser.com/questions/701527/trickle-throttle-all-programs-works-…
[17:55:50 CEST] <PlanC> kepstin: that sounds really complicated, any more info on how I can do that?
[17:56:04 CEST] <furq> "talks to the kernel directly" is a bad way of putting that
[17:56:30 CEST] <kepstin> PlanC: if you have a router that supports the openwrt/lede project firmware, install it and follow https://lede-project.org/docs/howto/sqm :/
[17:56:50 CEST] <furq> that looks nicer than the dd-wrt/tomato stuff i've used
[17:56:58 CEST] <furq> that was years ago on an actual wrt54g though
[17:57:16 CEST] <PlanC> furq: direct system calls to the kernel would be a better term, but regardless what I'm trying to say is that trickle doesn't work with ffmpeg
[17:57:31 CEST] <kepstin> yeah, most of these firmware don't even support the wrt54g(l) anymore, because ram is too low or flash is too small :/
[17:57:39 CEST] <furq> it doesn't matter anyway
[17:57:57 CEST] <furq> i have 150mbit down and the wrt54g won't do more than ~30mbit on the wan port because the cpu is so slow
[17:58:25 CEST] <PlanC> furq: I don't have that luxury unfortunately so it matters to me lol
[17:58:40 CEST] <kepstin> PlanC: one option is to build a non-static copy of ffmpeg& then stuff that intercepts C library functions should work.
[17:58:50 CEST] <furq> yeah or use your distro ffmpeg
[17:58:57 CEST] <furq> assuming it has one which isn't useless
[17:59:07 CEST] <PlanC> kepstin: oh that might be a good solution
[18:01:02 CEST] <PlanC> kepstin: would it be enough to remove the "--static" pkg config flag when compiling to make it non-static?
[18:01:17 CEST] <furq> no
[18:01:20 CEST] <PlanC> kepstin: and perhaps adding --enable-shared (or doesn't that have anything to do with it)?
[18:01:26 CEST] <furq> enable-shared has nothing to do with it either
[18:01:37 CEST] <furq> you presumably have --extra-ldflags=-static
[18:01:41 CEST] <furq> get rid of that
[18:02:36 CEST] <PlanC> furq: this is what I'm using: https://trac.ffmpeg.org/wiki/CompilationGuide/Centos
[18:03:19 CEST] <PlanC> furq: ffmpeg only has --static when compiling
[18:03:31 CEST] <PlanC> furq: and libx264 has "--enable-static"
[18:04:24 CEST] <furq> weird
[18:04:51 CEST] <furq> what does `ldd /path/to/ffmpeg` return
[18:07:34 CEST] <PlanC> furq: https://pastebin.com/raw/d620fZ1y
[18:07:46 CEST] <furq> yeah that's linked against your system libc
[18:10:32 CEST] <MeXIst3nZ> If I convert an .mp3 to .wav and then to .mp3 again, it won't lose any quality compared to how it was in its initial .mp3 state, right?
[18:10:47 CEST] <furq> it absolutely will lose quality
[18:11:29 CEST] <MeXIst3nZ> MP3 => WAV is lossless, no? So WAV => MP3 should produce an identical file?
[18:11:36 CEST] <furq> no
[18:11:44 CEST] <MeXIst3nZ> I don't see why not.
[18:11:46 CEST] <R1CH> you're decoding already lossy source file
[18:11:53 CEST] <MeXIst3nZ> Yes?
[18:11:56 CEST] <furq> it's exactly the same as going mp3 to mp3
[18:12:00 CEST] <R1CH> just because you're storing that lossy data in a lossless file doesn't magically restore it
[18:12:02 CEST] <furq> you're encoding a different signal
[18:12:07 CEST] <furq> with a lossy encoder
[18:12:10 CEST] <furq> so you're going to lose more data
[18:12:36 CEST] <MeXIst3nZ> Since WAV has no compression at all, the contents of the WAV should "perfectly contain" the MP3, no?
[18:12:45 CEST] <furq> yes, that's not the part you're wrong about
[18:13:09 CEST] <furq> that's exactly what would happen if you encoded an mp3 to mp3
[18:13:15 CEST] <R1CH> encoding to mp3 will always degrade the input no matter what
[18:13:23 CEST] <furq> it would be decoded to pcm and then that decoded signal would be encoded to mp3
[18:13:33 CEST] <furq> the encoder doesn't magically know that the signal was already compressed
[18:17:43 CEST] <R1CH> is there anything obviously wrong with this new decode api code? https://pastebin.com/raw/rKLvdpZR
[18:17:55 CEST] <R1CH> d->pkt comes from av_read_frame calls
[18:18:45 CEST] <R1CH> everything seems to work fine but the video always comes out corrupted (eg http://i.imgur.com/hwIMMuF.png)
[18:20:19 CEST] <R1CH> the problem is only for certain videos too, but other ffmpeg based players (and ffplay) handle it perfectly
[18:22:14 CEST] <PlanC> furq: it definitely has to be linked to the system since trickle isn't working
[18:22:46 CEST] <PlanC> furq: I'll try to compile it without the --static and see if it helps
[18:23:44 CEST] <furq> if it's linked to libc.so then that won't make any difference
[18:23:50 CEST] <furq> something else is presumably causing the issue
[18:24:06 CEST] <furq> it's definitely not --enable-static, that has absolutely nothing to do with libc
[18:24:23 CEST] <PlanC> furq: no I mean the "--static" for ffmpeg
[18:24:31 CEST] <PlanC> PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib -ldl" --bindir="$HOME/bin" --pkg-config-flags="--static" --enable-gpl --enable-nonfree --enable-libfdk_aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --e
[18:24:31 CEST] <PlanC> nable-libx265
[18:24:31 CEST] <furq> is there such an option
[18:24:47 CEST] <furq> if you mean pkg-config-flags then i doubt that'll make any difference
[18:24:57 CEST] <furq> maybe ldd trickle and see if it's linked to the same libc
[18:25:16 CEST] <furq> i vaguely remember rpm distros handing 32/64 bit in some wonky way
[18:25:20 CEST] <furq> handling
[18:26:15 CEST] <BtbN> R1CH, I think the intended flow is you send input, and then get output in a loop until EAGAIN
[18:27:03 CEST] <BtbN> the new API does explicitly not require a de/encoder to output one onput per input
[18:27:09 CEST] <BtbN> *one output
[18:27:40 CEST] <BtbN> see https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/avcodec.h#L79
[18:27:41 CEST] <PlanC> furq: could all the "--disable-shared" be causing it?
[18:28:19 CEST] <MeXIst3nZ> How can FFMPEG be so much better than Adobe at saving JPEGs in maximum quality but with much smaller file size?
[18:28:46 CEST] <MeXIst3nZ> I saved a JPEG from Photoshop and it was > 4 MB. The same file, first saved as a PNG and then converted to JPEG with FFMPEG, was ~2 MB.
[18:29:02 CEST] <R1CH> BtbN, this is kind of in a loop, if got_frame isn't 1 then decode_packet is called with the next packet
[18:29:24 CEST] <R1CH> it's just abstracted a bit so we can use both old and new api for users who don't have a recent ffmpeg
[18:29:25 CEST] <BtbN> yeah, but in the case of multiple output per input, you'd accumulate more and more of a backlog
[18:30:20 CEST] <R1CH> we always try calling avcodec_receive_frame before sending more packets though, wouldn't that prevent it?
[18:30:39 CEST] <BtbN> it should, yeah
[18:31:43 CEST] <R1CH> i just can't figure out where the corruption is coming from
[18:32:46 CEST] <BtbN> you still have the same corruption with this?
[18:33:05 CEST] <R1CH> yup
[18:33:48 CEST] <R1CH> its unrelated to the avcodec_decode_video2 issue from yesterday which turned out to be fixed in a newer ffmpeg build
[18:34:14 CEST] <R1CH> but the corruption is persistent with yesterday's git head
[18:34:30 CEST] <R1CH> yet not present in ffplay..
[18:47:13 CEST] <PlanC> perhaps a better way would be to use wget since I then could use --limit-rate to control the download speeds
[18:47:16 CEST] <PlanC> http://stackoverflow.com/a/7137391
[18:47:51 CEST] <PlanC> the only problem is that I want to have two remote inputs
[18:48:25 CEST] <PlanC> for example: wget [URL1] | wget [URL2] | ffmpeg -i pipe:0 -i pipe:1 -vcodec mpeg4 -s qcif -f m4v -y output.flv
[18:48:31 CEST] <PlanC> anyone know how I could do this?
[18:54:15 CEST] <furq> you wouldn't be able to encode on the fly with mp4 anyway
[18:54:29 CEST] <furq> ffmpeg can only do that because it does a range request from the end to get the moov atom
[18:54:42 CEST] <furq> or rather, you wouldn't reliably be able to do that
[19:00:30 CEST] <PlanC> furq: oh no I just copied the example from stackoverflow
[19:00:53 CEST] <PlanC> furq: but is there a way to use 2 pipes with two wget requests running at the same time?
[19:01:38 CEST] <PlanC> I know that it's possible to do "wget -r http://link1.com/file1 & wget -r http://link2.com/file2 &" which would download "file1" and "file2" at the same time
[19:01:44 CEST] <PlanC> but how can I pipe the output to ffmpeg?
[19:03:18 CEST] <kepstin> PlanC: it gets complicated, you'd have to make use of some advanced shell redirect features. doable tho.
[19:04:14 CEST] <PlanC> kepstin: any tips that would get me started because I have no idea where to begin with this?
[19:04:16 CEST] <kepstin> if you're using a modern bash, you can probably do something like "ffmpeg -i <(wget -r http://example.com/whatever)"
[19:05:02 CEST] <kepstin> what that does is open the wget in a subshell with the output as a pipe, then it gets replaced with "/dev/fd/N" in the ffmpeg command line which makes ffmpeg read from that pipe
[19:07:51 CEST] <PlanC> kepstin: thanks I'll try that out now
[19:07:56 CEST] <kepstin> er, you'd need to use "ffmpeg -i <(wget -O - http://example.com/whatever)" so the wget outputs on stdout and sends to the pipe
[19:08:26 CEST] <PlanC> + the "-r" to make it simultaneous, right?
[19:08:45 CEST] <kepstin> no, the r isn't needed here; that's for recursive download of e.g. all linked files on a page
[19:09:18 CEST] <kepstin> which doesn't really make sense if you're downloading a single file?
[19:12:08 CEST] <kepstin> note that if you're using wget anyways, it has built in rate limiting, you can do e.g. "--limit=rate=1m" to limit it to 1MB/s
[19:13:23 CEST] <hlechner> Hey guys, speaking of ffmpeg thumbnail: to generate a mosaic/tile thumbnail from a video with the examples from ffmpeg website it consumes too much CPU and time to do it, a 16GB file can take several minutes (in a intel i7)
[19:13:31 CEST] <hlechner> But in other hand if I take different thumbnails (one thumbnail by command) using the respective time to '-ss' it work Instantly however in this case I need to create the mosaic/tile thumbnail after it using the different thumbanils generated.
[19:13:36 CEST] <hlechner> Anyone knows a 'clean'/better way to do that?
[19:15:02 CEST] <grublet> hlechner: you could probably use a script to pipe the screenshots to something like imagemagick, which has a command called "append" that can be used to make mosaics fairly easily
[19:16:21 CEST] <PlanC> kepstin: I just tried it out and it's working, thanks! :)
[19:16:31 CEST] <PlanC> kepstin: and it's one file indeed so no need for "-r"
[19:17:41 CEST] <PlanC> kepstin: the "--limit-rate" is indeed the benefit of using wget since trickle wasn't able to limit its speed
[19:18:07 CEST] <kepstin> hlechner: you can probably just do something like "-vf fps=0.1,tile" (using whatever tile options you like), to grab a frame from every 10s of the video. adjust the fps to taste
[19:18:32 CEST] <PlanC> kepstin: it is however for some strange reason giving the warning "Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)" when using wget
[19:19:09 CEST] <kepstin> hlechner: but yeah, that might in some cases be slower than seeking, if you use really large gaps between tiles, since it has to decode the entire video :/
[19:19:25 CEST] <hlechner> grublet: thanks, it seems a good option
[19:19:52 CEST] <hlechner> kesptin: yea, it is the problem that Im having, it is decoding all video :(
[19:20:41 CEST] <c_14> you can try -discard nokey
[19:20:58 CEST] <c_14> then it'll only use keyframes which will speed up seeking and decoding
[19:21:29 CEST] <c_14> that or -skip_frame nokey
[19:22:08 CEST] <c_14> ah, discard is demuxer and not supported by all. so skip_frame is prob. better
[19:24:45 CEST] <hlechner> I have tried with -skip_frame and nokey but it seems that on files too big like the 16GB that Im using it takes too long still
[19:26:39 CEST] <c_14> probably io?
[19:26:43 CEST] <c_14> how long is it taking?
[19:28:17 CEST] <hlechner> more than 10 minutes for sure. but Im running it inside a SSD. I shouldnt have problem here, especially its not a server but a desktop machine
[19:28:35 CEST] <c_14> 10 min seems too long
[19:28:39 CEST] <c_14> what's your command?
[19:30:40 CEST] <hlechner> here one (example): '-ss', distance ,'-skip_frame', 'nokey','-i', inPath ,'-f', 'image2','-vframes', count || 1,'-aspect', '4:3','-filter:vf', 'select=\'isnan(prev_selected_t)+gte(t-prev_selected_t\\,'+ distance +')\',' + 'scale=\'if(gt(a,4/3),128,-1)\':\'if(gt(a,4/3),-1,96)\',pad=w=128:h=97:x=(ow-iw)/2:y=(oh-ih)/2:color=black,tile=4x1','-y'
[19:31:24 CEST] <hlechner> this example runs on node.js (javascript) but I made most of my tests outside the node, just running from bash
[19:34:57 CEST] <hlechner> and here my command to generate just one frame: ffmpeg -ss start_time_here -i input_here -f image2 -vframes 1 -aspect 16:9 -filter:vf scale="'if(gt(a,16/9),174,-1)':'if(gt(a,16/9),-1,98)',pad=w=174:h=98:x=(ow-iw)/2:y=(oh-ih)/2:color=black" -y preview.jpeg
[19:36:09 CEST] <hlechner> The last command generate instantly, but I need to generate each thumb and after create a mosaic/tile
[19:36:27 CEST] <c_14> the select is probably taking too long
[19:38:12 CEST] <hlechner> I didn't found a better way to do that, It was taken from ffmpeg example
[19:38:35 CEST] <hlechner> here a different select (from ffmpeg examples too): "select=not(mod(n\,1000)),scale=128:-1,tile=2x2" but the result is just similar
[19:39:52 CEST] <c_14> you can try using the thumbnail filter, might be faster. Can't remember if I ever benched it
[19:45:44 CEST] <kepstin> nah, thumbnail filter does some complicated processing to pick a "representitive" frame, I'd imagine it could only be slower
[19:46:10 CEST] <furq> it buffers all the uncompressed frames as well
[19:46:18 CEST] <furq> so it's prone to running out of memory
[19:46:29 CEST] <c_14> it might be better to just run the command in several passes for each frame
[19:46:39 CEST] <c_14> if you know the separation you want anyway
[19:46:49 CEST] <mick27> Howdy folks, anyone running ffmpeg 3.3 + cuda 8 + aws P2 instances around here ?
[19:46:50 CEST] <furq> having tried to do this exact thing before, there's not really an easy answer
[19:47:03 CEST] <furq> it's either going to be slow, memory hungry or both
[19:48:09 CEST] <hlechner> Yea, ffprobe give some details to work and get variables, so I can "know" where to use the '-ss' to take the thumbnails.
[19:48:50 CEST] <kepstin> if you know the separation you want, and it's really big, then maybe do multiple inputs with a different seek on each, trim each input to 1 frame, concatenate them, feed to tile filter?
[19:49:19 CEST] <c_14> can you limit frames on input?
[19:49:31 CEST] <c_14> other than trying to specify a really small -t and hoping?
[19:50:10 CEST] <furq> i'd have thought multiple -ss would be slower than -skip_frame nokey -vf select
[19:50:15 CEST] <kepstin> no, but that would have to be a complex filter chain anyways, so just do a trim=end_frame=1 or whatever
[19:50:17 CEST] <furq> given that you have to seek from the start every time iirc
[19:50:18 CEST] <c_14> though I guess if you've done an ffprobe before you can know the exact duration of the frame you want and pick that
[19:50:37 CEST] <c_14> furq: sure, but you can seek using the index so you can skip a lot of frame processing
[19:50:46 CEST] <furq> the best solution for me was -skip_frame nokey -vf select,scale,thumbnail,tile
[19:50:48 CEST] <kepstin> furq: if the file seeking is indexed and the gap between desired frames really big, seeking can save decoding a lot of keyframes
[19:50:55 CEST] <furq> fair enough
[19:51:30 CEST] <kepstin> in particular if the source file used a really low keyframe interval, i guess :/
[19:51:45 CEST] <furq> yeah i was testing with an h264 mp4 iirc
[19:52:08 CEST] <furq> which i can imagine would tip the scales against ss
[19:52:50 CEST] <hlechner> Guys maybe my terrible english is the problem here, but what do you mean by "with different seek on each"? would be generating different thumbs?
[19:53:01 CEST] <furq> on which note, i started doing something like this with the api but got distracted by a dog with a puffy tail
[19:53:08 CEST] <furq> i should probably finish it
[19:53:10 CEST] <c_14> ffmpeg -ss seek1 -i input -ss seek2 -i input [..]
[19:54:34 CEST] <hlechner> I didnt try it seems really useful!! if I can use the same file as input and use the select as well seems perfectly
[19:54:49 CEST] <mick27> Howdy folks, anyone running ffmpeg 3.3 + cuda 8 + aws P2 instances around here ?
[19:55:18 CEST] <hlechner> I will test it here
[19:55:25 CEST] <c_14> hlechner: you'll have to use a select or trim on each of the inputs to grab only one frame and then use the concat filter to concat all those pads and then pass that to the tile filter
[19:57:02 CEST] <kepstin> don't use select, it won't generate an eof until it sees an eof from its source. use trim :)
[19:57:50 CEST] <kepstin> should be trim=end_frame=1 I think? Assuming frame numbers are 0 based.
[20:00:35 CEST] <hlechner> I don't know yet, I have never used trim, fortunately there is documentation on ffmpeg website
[20:00:51 CEST] <hlechner> I will take a further look there
[20:23:26 CEST] <ThugAim> Guys, on windows I wanna do batch conversion to libx264 mp4 from a text file will all the directories listed in there... how do I do that?
[20:23:43 CEST] <ThugAim> g'dafteroon btw.
[20:27:56 CEST] <ChocolateArmpits> ThugAim, if you use powershel you can do: gc text.txt|%{ gci $_ -file | %{ ffmpeg -i $_.fullname -vcodec libx264 -acodec aac "$($_.directoryname)\$($_.basename).mp4" } }
[20:28:33 CEST] <ChocolateArmpits> presuming the source file isn't mp4 originally
[20:30:27 CEST] <ChocolateArmpits> eh you make it shorter as: gc text.txt | gci -file |%{ ffmpeg -i $_.fullname -vcodec libx264 -acodec aac "$($_.directoryname)\$($_.basename).mp4" }
[20:33:20 CEST] <ThugAim> I'll do some testing. Is there a way using command prompt? I've got the .bat thing down with a directory and was trying to figure out how to get individual files from multiple directories in from a text file with the directories listed. brb after testing.
[20:39:53 CEST] <ChocolateArmpits> it's doable by running command output from a for loop but looks pretty nasty
[20:40:16 CEST] <ChocolateArmpits> imo powershell is more straightforward
[20:49:37 CEST] <zerodefects> Decoding a DV video and then encoding into m2v wrapped in ts. I notice that the encoded frame had some interesting artifacts which I had originally put down to difference in color primaries, but not I'm not so sure...
[20:49:55 CEST] <zerodefects> Decoded: http://imgur.com/a/V083K
[20:50:07 CEST] <zerodefects> Encoded: http://imgur.com/a/zgj4I
[20:51:05 CEST] <zerodefects> Unfortunately, none of the color characteristics are set in the AVCodecContext or AVFrame by the decoder, so I'm not too sure which primaries it's using.
[21:00:02 CEST] <kepstin> zerodefects: looks like a combination of not enough bitrate and maybe a simple deinterlacer to me
[21:00:30 CEST] <kepstin> but mostly not enough bitrate
[21:01:37 CEST] <zerodefects> Thanks for checking it out :) Interesting. My bitrate is at 800K. I'll try increasing that.
[21:02:06 CEST] <zerodefects> If I look at the yellow bar, I found it interesting how it shadows all the way to the bottom of the encoded pic.
[21:03:01 CEST] <kepstin> hmm. 800K is low, but for mpeg 2 I wouldn't think it's low enough to do that, at least on mostly static color bars :/
[21:03:16 CEST] <zerodefects> Yeah, that as my thinking.
[21:04:11 CEST] <zerodefects> Do you think the color primaries (YUV ranges) could be playing a part too?
[21:05:35 CEST] <zerodefects> Originally, I thought the clip was BT.601 625, but I see the clip has YUYV values of 0x0C which is outside the range of that color space (0x10 to 0xF0).
[21:10:22 CEST] <kepstin> if it's originally an analog capture, it's normal for values to overshoot the nominal range
[21:10:40 CEST] <kepstin> due to miscalibration or noise or whatever other reason
[21:12:42 CEST] <zerodefects> Would an AtoD not ensure that the values were correctly bounded though?
[21:13:15 CEST] <kepstin> well, it would have to clip the values, when the purpose of the range limit is to give headroom for overshoots like this...
[21:13:19 CEST] <kepstin> it's really not a problem
[21:13:44 CEST] <kepstin> if you need to, you can digitally clip the values (and they'll be clipped during playback by the player)
[21:13:49 CEST] <zerodefects> That makes sense
[21:13:58 CEST] <zerodefects> Oh ok
[21:15:19 CEST] <zerodefects> I'll keep digging. I must be doing something wrong with the encoder because the decoded picture looks fine. Thanks for looking.
[21:16:00 CEST] <furq> does anyone have any amazing insights about segmenting and rejoining mp3s without getting gaps
[21:17:59 CEST] <kepstin> furq: in theory if you break on frame boundaries within a file then rejoin, it should be fine, but concatenating arbitrary mp3s without gaps is impossible :/
[21:18:12 CEST] <furq> well i'm segmenting with ffmpeg
[21:18:51 CEST] <zerodefects> kepstin: One last question. Is it often the case that color characteristics are not set by the various decoders on the AVFrame and.or AVCodecContext? Is that considered a bug?
[21:18:58 CEST] <furq> i'm guessing it's not cutting on a frame boundary or something
[21:19:22 CEST] <kepstin> furq: with -c:a copy it should only be able to copy on frame boundaries, so that's confusing.
[21:19:30 CEST] <kepstin> zerodefects: I don't know :/
[21:19:39 CEST] <furq> it's somewhat non-obvious what i'm doing because it's not something that's useful
[21:19:56 CEST] <zerodefects> Ok. No worries. Thanks :)
[21:20:06 CEST] <furq> i'm writing a script that segments an audio file, encodes each part with mp3 an increasing number of times, then concats them
[21:20:14 CEST] <kepstin> that said, if you're remuxing mp3 with ffmpeg, the extra headers it adds might make concatenating the files back again troublesome
[21:20:14 CEST] <furq> like those images you get of jpeg generation loss
[21:20:43 CEST] <kepstin> furq: oh, well, each pass through the encoder will add a chunk of encoder delay, so yeah that's not gonna work
[21:20:51 CEST] <furq> well even the first two parts have a gap
[21:21:06 CEST] <kepstin> if you decode the result, concatenate the raw audio, then save to flac or something you can probably get it right
[21:21:15 CEST] <kepstin> assuming the decoder handles the delay/sample trim correctly
[21:21:32 CEST] <furq> so er
[21:21:38 CEST] <furq> concat the list of mp3s and save as pcm?
[21:21:50 CEST] <furq> or do you mean save each segment to pcm and concat those
[21:21:53 CEST] <kepstin> decode the mp3s individually to pcm, concat that
[21:22:02 CEST] <furq> i don't see how that'd make a difference but i'll try it anyway
[21:22:08 CEST] <furq> i'll try both, rather
[21:22:57 CEST] <kepstin> the encoder has a delay - it adds a bunch of samples to the start of the first frame which have to be thrown out when decoding. but if you concat at the mp3 level, it'll just play them in place. they're usually just silence
[21:23:07 CEST] <furq> ah
[21:23:15 CEST] <furq> would this affect other lossy codecs
[21:23:30 CEST] <kepstin> yes, affects basically all lossy audio codecs
[21:23:40 CEST] <furq> well i guess if this works then it won't matter
[21:25:02 CEST] <kepstin> the encoder puts some metadata (in the LAME-compatible "INFO" header) saying how many samples at the start/end of the file need to removed to get only the original audio back
[21:25:22 CEST] <kepstin> I think current versions of ffmpeg write that correctly, but for best results just use the lame cli :/
[21:25:45 CEST] <furq> that would make it much more annoying to make the script support other codecs
[21:27:21 CEST] <furq> i wonder if splitting to wav instead of mp3 would help
[21:28:24 CEST] <kepstin> taking the original file, decoding to pcm/wav, splitting that, then doing your re-encoding on the wav files would give the most accurate start/end times, yeah
[21:28:52 CEST] <kepstin> then you could re-encode those segments as many times as you like, and it *shouldn't* add or remove any samples if the encoders/decoders are working correctly.
[21:30:03 CEST] <furq> atm i'm going flac -> segment with -c mp3 -> encode -> concat with -c copy
[21:30:18 CEST] <furq> i just tried converting them all to wav and concating those, it seemed to help
[21:30:22 CEST] <furq> there's still a click but it's not as bad
[21:30:50 CEST] <furq> segmenting to wav made more sense, it just saves a couple of lines to not do that
[21:32:03 CEST] <kepstin> I'd do anything -> segment with pcm audio -> encode segments separately -> decode segments to pcm -> concat, encoding to anything
[21:32:14 CEST] <furq> yeah i'm doing that now
[21:32:28 CEST] <furq> it unsurprisingly takes a while to run
[21:32:37 CEST] <furq> i should really parallelise it
[21:33:27 CEST] <tezogmix> Hey all.
[21:34:15 CEST] <ThugAim> heya.
[21:35:21 CEST] <ThugAim> guys been failing at the bash only to realize i might have the list in the .txt file formated wrong.
[21:36:45 CEST] <tezogmix> I had a 1080p source mp4 that's ~3gb size, 59.94 fps @12.5kbps bitrate, was going to convert it to mp4 @ 29.97 at same resolution... i've been playing around between fast & veryfast presets + -crf 18 and -crf 16... anything else i can consider to keep the bitrate closer to the 12mb mark? it seems I lose ~3000-4000kbps on the conversion
[21:36:47 CEST] <dystopia_> what are you trying to do ThugAim
[21:37:11 CEST] <dystopia_> 12.5kbps :O
[21:37:16 CEST] <dystopia_> you mean mbps?
[21:37:38 CEST] <tezogmix> yes sorry :)
[21:37:44 CEST] <tezogmix> ffmpeg -r 60000/1001 -i inpute.mp4 -preset veryfast -crf 18 -r 30000/1001 -c:a copy output.mp4
[21:38:05 CEST] <tezogmix> so something like that is what i've started with and switched from fast and 16
[21:38:11 CEST] <ThugAim> dystopia_, I'm trying to batch convert multiple files from multiple directories listed in a text file to h.264 mp4
[21:38:15 CEST] <tezogmix> wondering what else i could try...
[21:38:42 CEST] <dystopia_> if your reducing the frame rate the bit rate will naturally drop
[21:39:50 CEST] <tezogmix> understood on that part dystopia_ was there any other string to adjust to the above? I wasn't sure...
[21:41:24 CEST] <tezogmix> the file output size isn't a major issue although, something in the same 3gb-range is ok
[21:44:43 CEST] <ThugAim> in the text file i have things listed like #Media for Friday
[21:44:44 CEST] <ThugAim> file "E:/Folder1/file.mpg"
[21:44:44 CEST] <ThugAim> file "E:/Folder2/file2.mxf"
[21:44:44 CEST] <ThugAim> file "E:/Folder3/file3.mxf"
[21:44:44 CEST] <ThugAim> file "E:/Folder4/file4.mov"
[21:46:14 CEST] <kepstin> tezogmix: if you actually want a specific bitrate, then do a 2-pass mode with that bitrate. If you're using crf, then just pick a value you like and note that the file size will be variable.
[21:47:44 CEST] <furq> kepstin: fwiw splitting to pcm made a big difference, joining to pcm also makes a big difference
[21:47:58 CEST] <furq> decoding each file to pcm before joining doesn't seem to make any difference if i also do the other two
[21:48:03 CEST] <maicod> does anyone know of a tool to check a x264/h264 file for frame errors and report those frame numbers ?
[21:48:15 CEST] <tezogmix> thanks for the addon to dystopia_ 's comment kepstin ... how much of a noticeable difference will there be between a crf 15 and crf 18?
[21:48:17 CEST] <furq> there's still a click at the join points but it's much better than it was
[21:48:20 CEST] <furq> there was an audible gap before
[21:48:33 CEST] <tezogmix> i know it's quite subjective
[21:49:26 CEST] <tezogmix> hey furq what's up, btw thanks also from before on the tips on converting from 4k to 1080... it worked out ok!
[21:49:26 CEST] <kepstin> tezogmix: depends a lot on the original source, but unless you're looking really close it's hard to tell the difference between any setting crf18 or better with veryslow, imo.
[21:51:07 CEST] <tezogmix> i see (no pun intended) kepstin -
[21:52:21 CEST] <kepstin> if you're doing multiple generations of encodes, using better than that can be useful to reduce generation loss
[21:53:10 CEST] <tezogmix> some content for example would be at the microscopic level (e.g. if you're looking at at a sample of moving cells under a microscope, so the extra details do helps)
[21:54:16 CEST] <ThugAim> I might just have to copy all the files to a folder and batch convert from there temporairly
[21:54:45 CEST] <kepstin> for medical/scientific stuff my impression was that you really want to avoid adding any compression artifacts which could distort the data, so yeah, reallly low crf or even lossless might be appropriate
[21:55:46 CEST] <kepstin> (note that crf is a decibel scale, more or less)
[21:55:46 CEST] <tezogmix> is it normal in those cases for the output to be double the size? i did a test before with a crf 12 and crf 14
[21:57:12 CEST] <kepstin> so a change of ~6 crf would double or half the file size, if I am remembering correctly
[21:57:14 CEST] <tezogmix> putting crf at 0 (lossless), and the file was way too large to the point i had to cancel it, but it was more of the tradeoff to compare different levels of dtails
[21:57:25 CEST] <tezogmix> ok that helps with perspective kepstin
[21:58:00 CEST] <tezogmix> so output files larger than the source file in that sense, is not then due to a poorly formatted command line
[21:58:03 CEST] <tezogmix> i take
[21:58:41 CEST] <kepstin> if you tell x264 to make output larger than the input, it will happilly try to find a way
[21:59:22 CEST] <kepstin> it has no idea what the compressed size of your input was anyways :)
[22:00:49 CEST] <tezogmix> i meant otherwise, i just thought it was an interesting observation to see the output bigger than input (video-tech isn't my field of expertise obviously hehe (medical student) and have been kind of appreciating ffmpeg over handbrake),
[22:03:06 CEST] <tezogmix> i'm looking to build a new pc in the summer... what kind of cpu-gpu specs should i be looking for (general consumer, not for commercial) that can handle ffmpeg at some of the more higher quality parameters without taxing the system? right now, i'm doing this on a i5 laptop, windows 7 with 8gb ram, 5400hdd
[22:03:45 CEST] <tezogmix> i think an ssd would help one aspect...
[22:04:59 CEST] <tezogmix> really left i suppose then between amd or an intel variant, i'm not sure how much the gpu would even play in this role... but right now, i can't even playback 4k content on the current machine.
[22:07:32 CEST] <kepstin> for general video playback, gpu can help because they often include a hardware decoder that can make up for the cpu being too slow to decode something
[22:08:15 CEST] <kepstin> but for encoding, particularly high quality stuff, software encoders are preferred. So that's just as many high performance cpu cores as possible :/
[22:08:22 CEST] <tezogmix> i'm not an active gamer but video playback/video capture-streaming would be more of my interest uses
[22:10:00 CEST] <kepstin> if you're doing screen capture/streaming of cpu-intensive applications, the gpu encoders can be useful because they take load off the cpu. Pretty much any modern nvidia gpu would work well for that use case, doesn't even have to be particularly high end.
[22:10:01 CEST] <tezogmix> any particular gpu-cpu recommendations to keep in mind so i can research more about those kepstin ?
[22:10:26 CEST] <furq> the new amd zen stuff is nice for encoding
[22:10:39 CEST] <kepstin> as far as cpu recommendations - if you're doing software encoding "as many high performance cores as you can get"
[22:10:44 CEST] <furq> because of that
[22:10:49 CEST] <kepstin> and yeah, zen is a pretty cheap way to do that :)
[22:10:50 CEST] <furq> 8 cores without the intel premium
[22:11:09 CEST] <tezogmix> ok cool furq and kepstin , i'll look into that...
[22:11:11 CEST] <furq> old intel server stuff is nice as well
[22:11:14 CEST] <furq> it's cheap but it uses a lot of power
[22:11:22 CEST] <furq> i wouldn't really use it for a general-purpose pc
[22:11:32 CEST] <tezogmix> available to general consumers? :) ah, i see furq
[22:11:43 CEST] <furq> well you can just get it on ebay
[22:12:11 CEST] <furq> every so often $bigcorp will buy a bunch of new servers and suddenly there'll be a new batch of haswell xeon board/cpus on ebay for very cheap
[22:12:25 CEST] <tezogmix> so not as applicable for me in that sense... but cool to know if ever i learn more and get one on the cheap to use solely as a standalone machine
[22:12:27 CEST] <kepstin> as sold it'll be hot and noisy :/ but it can be turned into an ok workstation with some creativity.
[22:12:35 CEST] <JEEB> furq: yea I'm waiting for the next wave
[22:12:36 CEST] <furq> generally the dual cpu stuff is incredibly cheap for how powerful they are
[22:12:46 CEST] <furq> but yeah you'll need to put extra effort in to make a serviceable pc out of them
[22:12:47 CEST] <JEEB> E5 2670v2 or something
[22:12:56 CEST] <JEEB> since the v1 was already <3
[22:13:25 CEST] Action: kepstin just got a ryzen 1700 box to play with, it's pretty impressive even at stock speeds.
[22:13:27 CEST] <tezogmix> what kind of price range are you all talking about the latter stuff to check on ebay
[22:13:30 CEST] <tezogmix> ?
[22:13:52 CEST] <JEEB> a first gen E5 2670 is around 70-90 bucks a pop
[22:13:58 CEST] <furq> https://0x0.st/gIf.wav
[22:14:03 CEST] <furq> here's some mp3 v4 generation loss for you
[22:14:06 CEST] <tezogmix> i know my local pc store sells a lot of dell and hp workstation desktops
[22:14:10 CEST] <furq> a new generation every four seconds
[22:14:14 CEST] <tezogmix> not sure of their cpu's
[22:14:31 CEST] <JEEB> kepstin: yea a dual cpu setup of ryzen would be cool too. esp. with the 16 core thing they're pushing out
[22:14:35 CEST] <kepstin> furq: one way to work around 'clicks' at boundaries might be to do overlapping segments, then trim them before concatenating.
[22:14:45 CEST] <furq> JEEB: aren't they calling the zen server cpus EPYC
[22:14:50 CEST] <furq> it's not worth the stigma of owning something called that
[22:15:03 CEST] <JEEB> I think it was THREADRIPPER
[22:15:05 CEST] <JEEB> or something
[22:15:11 CEST] <furq> that's the uarch isn't it
[22:15:15 CEST] <JEEB> could be :D
[22:15:17 CEST] <kepstin> furq: you could have at least flaced that :/
[22:15:20 CEST] <furq> i'm pretty sure they're branding them as EPYC
[22:15:22 CEST] <kepstin> it's kinda big ;)
[22:15:23 CEST] <furq> kepstin: oh yeah
[22:15:27 CEST] <furq> <--
[22:15:35 CEST] <furq> also it would play in the browser if i did that
[22:15:56 CEST] <kepstin> the consumer 16core ones are gonna be Ryzen THREADRIPPER, yeah
[22:16:05 CEST] <kepstin> but those aren't gonna support multi-cpu, apparently
[22:16:11 CEST] <JEEB> aww
[22:16:17 CEST] <JEEB> still, ECC works
[22:16:18 CEST] <JEEB> \o/
[22:16:36 CEST] <kepstin> if you get lucky and find a board that has it wired up and bios support :(
[22:16:43 CEST] <kepstin> the cpus have it, the boards are iffy
[22:16:46 CEST] <furq> yeah that's always been a pisser with amd boards
[22:16:47 CEST] <JEEB> well yea
[22:17:03 CEST] <furq> i was going to build an am1 system for my nas but it was impossible to get reliable information on which boards had ecc
[22:17:04 CEST] <JEEB> but at least there's results that when the sticks get strained there's actual error correction happening
[22:17:08 CEST] <JEEB> which is guy
[22:17:09 CEST] <JEEB> *gut
[22:17:47 CEST] <kepstin> I've seen confirmation that at least some ASUS and ASRock X370 boards have working ecc, I think the asus one even has some bios config options for scrubbing and whatnot
[22:18:06 CEST] <furq> http://vpaste.net/O4ZYF
[22:18:09 CEST] <furq> there's the script fwiw
[22:19:16 CEST] <furq> it's a shame the guy who didn't believe in generation loss left hours ago
[22:19:23 CEST] <furq> since that's the reason i thought this would be a good idea
[22:30:04 CEST] <james999> generation loss?
[22:50:20 CEST] <tezogmix> ok thanks all again for the chat and additional feedback... have a good weekend to come!
[23:44:36 CEST] <riataman> hey
[23:44:44 CEST] <durandal_170> hi
[23:44:55 CEST] <riataman> I'm trying to save a rtsp stream to segmented mp4 files
[23:45:01 CEST] <riataman> but those files don't worth in iOS
[23:45:18 CEST] <riataman> and are kind of funnny in chrome (desktop and mobile) like the slider acts very weird
[23:45:27 CEST] <riataman> they work very well in firefox
[23:45:41 CEST] <riataman> I'm using this line:
[23:45:44 CEST] <riataman> ffmpeg -loglevel error -i rtsp://192.168.1.74:5554/camera -c copy -an -map 0 -f segment -segment_time 60 -segment_format mp4 -strftime 1 /root/video-recordings/video-%Y%m%d-%H%M.mp4
[23:46:14 CEST] <riataman> I have tried a bunch of options like -segment_format_options movflags=+faststart
[23:46:22 CEST] <riataman> but nothing can make it play in iOS
[23:46:23 CEST] <riataman> any ideas?
[23:47:36 CEST] <riataman> I would love to avoid transcoding if possible
[00:00:00 CEST] --- Fri May 19 2017
1
0
[00:32:15 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:3d9cb583c8f0: avcodec/hq_hqa: Fix: runtime error: signed integer overflow: -255 * 10180917 cannot be represented in type 'int'
[01:38:18 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:99c4c76cfbc4: avcodec/takdec: Fix runtime error: left shift of negative value -42
[01:38:19 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:552adf1dd3a3: avcodec/mlpdec: Fix runtime error: left shift of negative value -1
[01:38:20 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:355e27e24dc8: avcodec/flicvideo: Check frame_size before decrementing
[02:39:52 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:0e87c07d87b4: avcodec/h264_cavlc: Fix runtime error: index -1 out of bounds for type 'VLC [6]'
[02:39:53 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:e11dcc35bb4d: avcodec/fmvc: Fix off by 1 error
[02:56:38 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d35159d3bba2: avcodec/hq_hqa: Fix: runtime error: signed integer overflow: -255 * 10180917 cannot be represented in type 'int'
[02:56:39 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a32a9bde993a: avcodec/takdec: Fix runtime error: left shift of negative value -42
[02:56:40 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:63cc52ed97f5: avcodec/mlpdec: Fix runtime error: left shift of negative value -1
[02:56:41 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:792f15c109cc: avcodec/flicvideo: Check frame_size before decrementing
[02:56:42 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9b9a620ce698: Update for 3.1.8
[04:25:20 CEST] <KGB> [13FFV1] 15dericed opened pull request #61: update to border section (06master...06border-section) 02 https://git.io/v9ABx
[04:42:20 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07n3.1.8:HEAD: avcodec/fmvc: Fix off by 1 error
[04:57:45 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02 https://git.io/v9A0K
[04:57:45 CEST] <KGB> 13FFV1/06master 141510141 15Dave Rice: update to border section...
[05:03:22 CEST] <KGB> [13FFV1] 15dericed opened pull request #62: describe pseudo-code (06master...06pseudo-code) 02 https://git.io/v9A0Q
[06:54:34 CEST] <cone-630> ffmpeg 03James Almer 07master:a441aa90e80e: MAINTAINERS: Remove Tomas Härdin from mxfdec.c
[14:19:22 CEST] <mateo`> michaelni: do you agree if I also backport the mdhd time_scale fix to the 3.3 branch (after it has reached master) ?
[14:27:27 CEST] <michaelni> mateo`, yes
[14:31:22 CEST] <j-b> BtbN: and another attack...
[14:31:56 CEST] <nevcairiel> someone has also been DDoSing the mpc-hc web services the last week or so, someone must not like oss media players
[14:32:13 CEST] <BtbN> Or someone is just stupid with their scripts
[14:32:26 CEST] <BtbN> If you are stupid on potent enough servers, you easily create a small DDoS
[14:32:37 CEST] <mateo`> michaelni: should i keep the fix only for the mdhd atoms (and not mvhd like the original patch did, it looks more sensible to me as it would also affects video tracks, and not just data track) ?
[14:32:46 CEST] <mateo`> I only encountered the issue with data track
[14:32:51 CEST] <nevcairiel> its easy enough to spot an attack from hundreds of o rigins then from a few =p
[14:46:50 CEST] <michaelni> mateo`, if its a different change than what was posted, please post again so people (and me) can retest
[14:47:15 CEST] <michaelni> i think it shouldnt be able to break anything though
[14:52:40 CEST] <mateo`> I'll submit a new version of the patch then
[16:08:54 CEST] <BBB> j-b: ping
[17:37:19 CEST] <j-b> BBB: pong?
[17:39:02 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07master:53a502206a9e: avcodec/aacdec_template: Fix fixed point scale in decode_cce()
[17:39:03 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07master:4bd869eb7c84: avcodec/rv34: Fix runtime error: signed integer overflow: 768 * 4126720 cannot be represented in type 'int'
[17:39:04 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07master:94d05ff15985: avcodec/aacdec: Fix runtime error: signed integer overflow: 2147483520 + 255 cannot be represented in type 'int'
[18:40:18 CEST] <BBB> j-b\: why the \ ?
[18:40:22 CEST] <BBB> j-b\: anyway
[18:40:47 CEST] <BBB> j-b\: are you doing the aom on videolan side? or someone else? and can I put feature requests there as related to the standaridzation process as opposed to the standard itself
[18:40:48 CEST] <BBB> ?
[18:41:01 CEST] <BBB> j-b\: since Im essentially part of videolan :-p
[18:41:51 CEST] <wm4> in what way are you a part of it?
[18:42:01 CEST] <BBB> videolan - ffmpeg - me
[18:42:03 CEST] <wm4> but please make them do sane thing
[18:42:15 CEST] <wm4> (I don't think ffmpeg is formally part of videolan, but ok)
[18:42:21 CEST] <BBB> I even submitted a patch to vlc directly one day
[18:42:32 CEST] <wm4> heh
[18:42:51 CEST] <wm4> that makes you a vlc developer, and part of videolan
[18:42:51 CEST] <BBB> I did! it got committed also
[18:44:32 CEST] <BBB> next I should figure out how to become an ios developer
[18:44:41 CEST] <BBB> all these job listings are looking for them, must be really hot
[18:44:54 CEST] <BBB> maybe I should write my own (i) phone operating system (os) -> ios?
[18:45:37 CEST] <wm4> (get sued by a fruit company)
[18:45:59 CEST] <wm4> a sane mobile OS would be nice though
[20:00:31 CEST] <ubitux> no one to look at the qsv commit from libav so merge can continue?
[20:00:36 CEST] <ubitux> i can't test this stuff :(
[20:00:48 CEST] <ubitux> it's been blocked for a few days already
[20:03:24 CEST] Action: JEEB doesn't have any of the related drivers installed
[20:07:54 CEST] <wm4> ubitux: I wasn't aware of that
[20:08:12 CEST] <wm4> I'd say just merge it, we can fix it later?
[20:08:31 CEST] <ubitux> doesn't merge cleanly
[20:08:48 CEST] <ubitux> qsvenc is different in various ways
[20:08:52 CEST] <ubitux> i can't blind it
[20:10:11 CEST] <wm4> does it affect encoder or decoder?
[20:13:28 CEST] <ubitux> encoder
[20:13:31 CEST] <ubitux> f8f7ad758d0e1f36915467567f4d75541d98c12f
[20:16:28 CEST] <jkqxz> Bleh, let me look at that.
[20:16:43 CEST] <jkqxz> I didn't realise qsv was blocking it.
[20:22:32 CEST] <cone-050> ffmpeg 03Paul B Mahol 07master:deaab31d61fd: avfilter: add audio crossfeed filter
[20:25:29 CEST] <Compn> guy at intel wants to make ffmpeg benchmarks
[20:25:38 CEST] <Compn> he sent a mail to projects@mphq
[20:25:49 CEST] <nevcairiel> tell him the right place to go =p
[20:25:55 CEST] <Compn> wheres that
[20:25:59 CEST] <nevcairiel> no idea
[20:26:04 CEST] <Compn> is mpchc still active ?
[20:26:10 CEST] <Compn> he also asking about that project
[20:26:19 CEST] <nevcairiel> kind of
[20:26:24 CEST] <nevcairiel> i maintain the decoders it uses
[20:26:32 CEST] <Compn> can i forward this mail to you then ?
[20:26:49 CEST] <Compn> wm4 might also be interested , running mpv as he does
[20:27:16 CEST] <cone-050> ffmpeg 03Luca Barbato 07master:f8f7ad758d0e: qsv: Set the correct range for la_depth
[20:27:17 CEST] <cone-050> ffmpeg 03Mark Thompson 07master:b7b02aebec77: Merge commit 'f8f7ad758d0e1f36915467567f4d75541d98c12f'
[20:27:53 CEST] <Compn> j-b\ : did you get intel mail as well ?
[20:28:44 CEST] <jkqxz> ubitux: There you go ^
[20:32:50 CEST] <ubitux> jkqxz: thx!
[20:35:11 CEST] <ubitux> i'll probably go back to merges tmr
[20:37:00 CEST] <Compn> anyone wants intel to benchmark their multimedia software and wants me to forward this intel guys email to them , speak up (and also send me what mail you want me to use)
[20:37:15 CEST] <Compn> probably for an intel v amd thing no doubt
[20:37:26 CEST] <Compn> ryzen?
[20:38:12 CEST] <nevcairiel> Compn: if they want to benchmark ffmpeg, they should do that, thats basically what all those players use anyway
[20:38:43 CEST] <JEEB> and those that don't usually just do HWdec anyways
[20:38:48 CEST] <JEEB> *HWdec only
[20:38:59 CEST] <peloverde> Was 53a502206 test with a *valid* file, it looks really suspicious
[20:39:36 CEST] <Compn> peloverde : its in a chain of commits by michael, in what looks like more fuzz samples
[20:40:14 CEST] <Compn> or possibly some other code analyzer
[20:41:47 CEST] <wm4> yeah, all he does these days is fixing fuzz samples
[20:42:04 CEST] <wm4> indeed the commit message says this
[20:43:06 CEST] <peloverde> I'm not asking if it fixes a fuzzed sample, I'm asking if a valid sample that exercises the same code path was tested to make sure there are no regresssions
[20:43:10 CEST] <Compn> nevcairiel : "I see that your website seems to be like its playing in the same field. It would be great if we can sync to see any synergy and explore the partnering opportunity."
[20:43:38 CEST] <Compn> peloverde : apologies, i misunderstood your question.
[20:43:39 CEST] <michaelni> peloverde, the code before the patch is really wrong
[20:44:11 CEST] <michaelni> peloverde, i tried testing it but i didnt find a sample quickly that excercised this
[20:44:27 CEST] <michaelni> fate doesnt test it sadly
[20:44:31 CEST] <wm4> well, fate should normally test most of a decoder? ....oh
[20:45:06 CEST] <peloverde> okay, there is a sample on mike's wiki that uses that feature
[20:45:29 CEST] <wm4> confirm that it decodes the same before and after that patch, add to fate?
[20:46:47 CEST] <michaelni> wm4 theres no way it decodes correctly before the patch if it uses this code path
[20:47:32 CEST] <michaelni> the numbers in the cce_scale_fixed table are large fixed point numbers and GET_GAIN or fixed point aac uses these as shift exponent
[20:47:49 CEST] <wm4> so what broke it before, if the sample was apparently known?
[20:48:00 CEST] <michaelni> i think it never worked
[20:48:16 CEST] <michaelni> this is about aac_fixed, floating point aac isnt affected
[20:48:33 CEST] <wm4> ah
[21:00:00 CEST] <jamrial> where are these fixed variants of aac/ac3/etc useful? arm?
[21:00:28 CEST] <atomnuker> mips
[21:00:39 CEST] <peloverde> IMG contributed AAC so presumably mips
[21:06:51 CEST] <atomnuker> ubitux: what was the issue with the pthread naming patch you made again?
[21:11:51 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:d5cdae9e357b: avformat/http: Check for truncated buffers in http_connect()
[21:11:52 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:5cfd259820fe: avcodec/wavpacl: Fix runtime error: left shift of negative value -1
[21:11:53 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:1f4f22eb0fb7: avcodec/mpeg12dec: Fix runtime error: left shift of negative value
[21:11:54 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:0465fc58e86b: avcodec/pngdec: Check bit depth for validity
[21:11:55 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:fe27d3f02f41: avcodec/srtdec: Fix signed integer overflow: 1811992524 * 384 cannot be represented in type 'int'
[21:11:56 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:783ba62dae86: avcodec/pictordec: Do not read more than nb_planes
[21:11:57 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:7aaac74f58ce: avcodec/rv34: Simplify and factor get_slice_offset() code
[21:11:58 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:90f7b5fd16a6: avcodec/mpegaudiodec_template: Correct return code on id3 tag discarding
[21:11:59 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:065440d96bf2: avcodec/vp56: Fix sign typo
[21:12:00 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:674cd62f07fa: avcodec/pngdec: Fix runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
[21:12:01 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:336a4c5f79a5: avcodec/amrwbdec: Fix 2 runtime errors: left shift of negative value -1
[21:12:02 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:3c8c0c0162d2: avcodec/vp56: Implement very basic error concealment
[21:12:03 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:f6908d087e6b: avcodec/vp56: Clear dimensions in case of failure in the middle of a resolution change
[21:12:04 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:095449d27289: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -1
[21:12:05 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:067bd9877f73: Add CHECK/SUINT code
[21:12:06 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:8b644b956347: avcodec/vp3dsp: Fix multiple signed integer overflow: 46341 * 47523 cannot be represented in type 'int'
[21:12:07 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:49130f414559: avcodec/vp56: Factorize vp56_render_mb() out
[21:12:08 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:5740278de27f: avcodec/vp8: Check for bitsteam end in decode_mb_row_no_filter()
[21:12:09 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:e11e2574c742: avcodec/vp3: Do not return random positive values but the buf size
[21:12:10 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:a38d6d36a8c7: avcodec/vp56: Require a correctly decoded frame before using vp56_conceal_mb()
[21:12:11 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:f4f5f69082ff: avcodec/vp8: remove redundant check
[21:12:12 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:9f225bbcabd5: avcodec/vp568: Check that there is enough data for ff_vp56_init_range_decoder()
[21:12:13 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:404fbd980b95: avcodec/vp8: Check for the bitstream end per MB in decode_mb_row_no_filter()
[21:12:14 CEST] <cone-050> ffmpeg 03Thomas Guilbert 07release/3.0:a132c3f3be50: avcodec/vp8: Fix hang with slice threads
[21:12:15 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:537b2b8ab512: avcodec/vp56: Reset have_undamaged_frame on resolution changes
[21:12:16 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:bb4ca14d13d1: avcodec/vp6: clear dimensions on failed resolution change in vp6_parse_header()
[21:12:17 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:9a891b843c20: avcodec/htmlsubtitles: Fix reading one byte beyond the array
[21:12:18 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:2fd1ab16d9fe: avcodec/eac3dec: Fix runtime error: left shift of negative value
[21:12:19 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:97bbd8e8d343: avcodec/mjpegdec: Fix runtime error: left shift of negative value -507
[21:12:20 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:a18c76cb783f: avcodec/mpeg4videodec: Fix runtime error: shift exponent -2 is negative
[21:12:21 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:37400a906859: avcodec/h264_cabac: runtime error: signed integer overflow: 2147483647 + 14 cannot be represented in type 'int'
[21:12:22 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:a9d1e7d3c85b: avcodec/rv40: Fix runtime error: left shift of negative value
[21:12:23 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:d6419e984f72: avcodec/ituh263dec: Fix runtime error: left shift of negative value -22
[21:12:24 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:99696ad046e5: avcodec/mpeg4video: Fix runtime error: left shift of negative value
[21:12:25 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c66899d5e430: avcodec/mpeg4videodec: Check sprite_offset in addition to shifts
[21:12:26 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:2e7621d615c5: avcodec/mpeg4videodec: Check the other 3 sprite points for intermediate overflows
[21:12:27 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:89ffe4e0e000: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -2
[21:12:28 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:6da1353a5aa3: avcodec/eac3dec: Fix runtime error: left shift of negative value -3
[21:12:29 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:5a4709e9e321: avcodec/mpeg4videodec: Fix runtime error: left shift of negative value -2650
[21:12:30 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:e8fb38f48cb6: avcodec/pictordec: Check plane value before doing value/mask computations
[21:12:31 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:250d2b402a0e: avcodec/h264_direct: Fix runtime error: left shift of negative value -14
[21:12:32 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:20c36f04b960: avcodec/mjpegdec: Fix runtime error: left shift of negative value -511
[21:12:33 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:ab92ed6365e6: avcodec/mpeg4videodec: Improve the overflow checks in mpeg4_decode_sprite_trajectory()
[21:12:34 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:a44c53f8d7e2: avcodec/adxdec: Fix runtime error: left shift of negative value -1
[21:12:35 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:868de78861cc: avcodec/h264_mvpred: Fix multiple runtime error: left shift of negative value
[21:12:36 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:f458d65bb42b: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -13
[21:12:37 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:b7239fec9d87: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 134527392 * 16 cannot be represented in type 'int'
[21:12:38 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:41beb7297fcc: avcodec/wavpack: Fix runtime error: left shift of negative value -2
[21:12:39 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:e4d5f9bf93b5: avcodec/wavpack: Fix runtime error: left shift of negative value -5
[21:12:40 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:8b4386ab8764: avcodec/mjpegdec: Fix runtime error: left shift of negative value -127
[21:12:41 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:625044336e6e: avcodec/h264_mvpred: Fix runtime error: left shift of negative value -1
[21:12:42 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:7b91d4f07bb6: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: -135088512 * 16 cannot be represented in type 'int'
[21:12:43 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:bb0baaf58002: avcodec/amrwbdec: Fix runtime error: left shift of negative value -1
[21:12:44 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:8df6363188bf: avcodec/rv34: Fix runtime error: signed integer overflow: 36880 * 66288 cannot be represented in type 'int'
[21:12:45 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:9ff9e3931b81: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int'
[21:12:46 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:5e69ec6c2f88: avcodec/tiff: Check for multiple geo key directories
[21:12:47 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:6a70c38e397b: avcodec/mpegaudiodec_template: Make l3_unscale() work with e=0
[21:12:48 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:72b968361b3d: avcodec/tiff: Check stripsize strippos for overflow
[21:12:49 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:fd5f35746112: avcodec/vp56: Check avctx->error_concealment before enabling EC
[21:12:50 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:f1e6c03739d4: avcodec/tiff: Check geotag count for being non zero
[21:12:51 CEST] <cone-050> ffmpeg 03Philip Langdale 07release/3.0:0a13449b2806: avcodec/vdpau_hevc: Fix potential out-of-bounds write
[21:12:52 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:cc4a13b8a7d8: avcodec/tiff: Perform multiply in tiff_unpack_lzma() as 64bit
[21:12:53 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:408242556c94: avfilter/avfiltergraph: Add assert to write down in machine readable form what is assumed about sample rates in swap_samplerates_on_filter()
[21:12:54 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:0cbd48a38b15: avfilter/af_sofalizer: Fix bad shift
[21:12:55 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:98f93f5272ea: avformat/oggparsedaala: Check duration for AV_NOPTS_VALUE
[21:12:56 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:ed0c3290f86d: avformat/oggparsedaala: Do not leave an invalid value in gpshift
[21:12:57 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:70e26e9c25d3: avcodec/dvdsubdec: Fixes 2 runtime error: left shift of 170 by 24 places cannot be represented in type 'int'
[21:12:58 CEST] <cone-050> ffmpeg 03Derek Buitenhuis 07release/3.0:351dc1f33a65: avformat/webmdashenc: Require the 'adaptation_sets' option to be set
[21:12:59 CEST] <cone-050> ffmpeg 03Derek Buitenhuis 07release/3.0:b1d5c2de2bbf: avformat/webmdashenc: Validate the 'streams' adaptation sets parameter
[21:13:00 CEST] <cone-050> ffmpeg 03Martin Vignali 07release/3.0:19a58a10fd62: libavcodec/exr : fix float to uint16 conversion for negative float value
[21:13:01 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:8bca0d765121: avcodec/x86/vc1dsp_init: Fix build failure with --disable-optimizations and clang
[21:13:02 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:b3328c069c47: avcodec/mdec: Fix runtime error: left shift of negative value -127
[21:13:03 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:345ae4e8dfc4: doc/developer: Add terse documentation of assumed C implementation defined behavior
[21:13:04 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:b2af4884a9ba: avcodec/vp3: Check remaining bits in unpack_dct_coeffs()
[21:13:05 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:53c2b8128195: avcodec/indeo2: Check remaining bits in ir2_decode_plane()
[21:13:06 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:6828048800a1: avcodec/svq3: Increase offsets to prevent integer overflows
[21:13:07 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:487ea209f851: avcodec/dcadsp: Fix runtime error: signed integer overflow
[21:13:08 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:4a6426d3cb36: avcodec/h264_cavlc: Fix undefined behavior on qscale overflow
[21:13:09 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:32f047ce5c7a: avcodec/msvideo1: Check buffer size before re-getting the frame
[21:13:10 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:79d027ae7ca8: avcodec/pngdec: Use ff_set_dimensions()
[21:13:11 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:d0ac194ea4cb: libavcodec/mpeg4videodec: Convert sprite_offset to 64bit
[21:13:12 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:27fbb554fcbf: avcodec/dvdsubdec: Fix runtime error: left shift of 242 by 24 places cannot be represented in type 'int'
[21:13:13 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:7d0830c546f5: avcodec/cavsdec: Fix undefined behavior from integer overflow
[21:13:14 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:2fe493ed72cb: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'
[21:13:15 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:8054b21f8d3e: avcodec/tiertexseqv: set the fixed dimenasions, do not depend on the demuxer doing so
[21:13:16 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:ca6277e1eeb0: avcodec/wnv1: Fix runtime error: left shift of negative value -1
[21:13:17 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c4ae78ef067f: avcodec/dss_sp: Fix multiple left shift of negative value -466
[21:13:18 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:add1e9c371f3: avcodec/g722: Fix multiple runtime error: left shift of negative value -1
[21:13:19 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:2871d8dbb57b: avcodec/cdxl: Fix signed integer overflow: 14243456 * 164 cannot be represented in type 'int'
[21:13:20 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:e488ad44aacf: avcodec/nellymoser: Fix multiple left shift of negative value -8591
[21:13:21 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c93df94fe30f: avcodec/dfa: Fix off by 1 error
[21:13:22 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:d0947505dc97: avcodec/mdec: Fix signed integer overflow: 28835400 * 83 cannot be represented in type 'int'
[21:13:23 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:4a58c5a3b9d5: avcodec/aacsbr_template: Do not leave bs_num_env invalid
[21:13:24 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:317c043316cd: avutil/softfloat: Fix multiple runtime error: left shift of negative value -8
[21:13:25 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:93702fd208c6: avcodec/snowdec: Check qbias
[21:13:26 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:1e034a9ffe53: avcodec/mlpdec: Fix runtime error: left shift of negative value -22
[21:13:27 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:903c4b2c3c89: avcodec/fic: Fix multiple left shift of negative value -15
[21:13:28 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c78e5a2cb41a: avcodec/mimic: Fix runtime error: left shift of negative value -1
[21:13:29 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:94a58e597b19: avcodec/g723_1: Fix multiple runtime error: left shift of negative value
[21:13:30 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:969689d7d7cf: avcodec/dfa: Fix signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
[21:13:31 CEST] <durandal_1707> SPAAAAAAMM
[21:13:31 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:65ec573358b3: avcodec/webp: Fix null pointer dereference
[21:13:32 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:9f4e2b15e0d8: avcodec/shorten: Check k in get_uint()
[21:13:33 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:6f57b9d7151d: avcodec/mss3: Change types in rac_get_model_sym() to match the types they are initialized from
[21:13:34 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:a5c7c22c66cc: avcodec/hq_hqa: Fix runtime error: left shift of negative value -207
[21:13:35 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c99e86556c0d: avutil/softfloat: Fix overflow in av_div_sf()
[21:13:36 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:05b8e57abaf7: avcodec/cdxl: Check format parameter
[21:13:37 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:daa9bca16b54: avcodec/dds: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[21:13:38 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:74f35b9d5ea0: avcodec/msmpeg4dec: Correct table depth
[21:13:39 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:0caf6fa51e69: avcodec/svq3: Fix multiple runtime error: signed integer overflow: 44161 * 61694 cannot be represented in type 'int'
[21:13:40 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:7465d229cb9c: avcodec/ivi_dsp: Fix multiple left shift of negative value -2
[21:13:41 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:2d8a3daddbe4: avcodec/texturedsp: Fix multiple runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[21:13:42 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:95700803f451: avcodec/targa_y216dec: Fix width type
[21:13:43 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:9371fef23cc6: avcodec/mss34dsp: Fix multiple signed integer overflow
[21:13:44 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c4371e8b2fba: avcodec/ra144: Fix runtime error: left shift of negative value -798
[21:13:45 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:87c1cff59891: avcodec/g726: Fix runtime error: left shift of negative value -2
[21:13:46 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:d93c75f037a8: avcodec/eamad: Fix runtime error: signed integer overflow: 49674 * 49858 cannot be represented in type 'int'
[21:13:48 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:d55d821b9e23: avcodec/s302m: Fix left shift of 8 by 28 places cannot be represented in type 'int'
[21:13:48 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:9320f86494bf: avcodec/xwddec: Check bpp more completely
[21:13:49 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:e4b1426e1bf9: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -12156865 cannot be represented in type 'int'
[21:13:50 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:51e493679836: avcodec/ffv1dec: Fix copying planes of paletted formats
[21:13:51 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:f903400a0bb5: avcodec/cdxl: Check format for BGR24
[21:13:52 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:6b334460defe: avcodec/cavsdec: Check sym_factor
[21:13:53 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:386767ecea4c: avcodec/hqxdsp: Fix multiple runtime error: signed integer overflow: 248220 * 21407 cannot be represented in type 'int' in idct_col()
[21:13:54 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:6c15025deeda: avcodec/vp8dsp: Fixes: runtime error: signed integer overflow: 1330143360 - -1023040530 cannot be represented in type 'int'
[21:13:55 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:6cb55a703245: avcodec/dvbsubdec: check region dimensions
[21:13:56 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:3724f36b09a4: avcodec/dss_sp: Fix multiple runtime error: signed integer overflow: -15699 * -164039 cannot be represented in type 'int'
[21:13:57 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:154c73b63eea: avcodec/bmvvideo: Fix runtime error: left shift of 137 by 24 places cannot be represented in type 'int'
[21:13:58 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:de5b23ead671: avcodec/htmlsubtitles: Check for string truncation and return error
[21:13:59 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c152707dc1a1: avcodec/g723_1dec: Fix several integer related cases of undefined behaviour
[21:14:00 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:bac7b595423e: avcodec/indeo2: Check for invalid VLCs
[21:14:01 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:0fed5947bd6c: avcodec/takdec: Fix multiple runtime error: left shift of negative value -1
[21:14:03 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c1a6521df8d2: avcodec/lagarith: Fix runtime error: left shift of negative value -1
[21:14:03 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:dfda82809ccd: avcodec/lagarith: Check scale_factor
[21:14:04 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:4800f38ffb43: avcodec/texturedsp: Fix runtime error: left shift of 218 by 24 places cannot be represented in type 'int'
[21:14:05 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:70cc62271bd4: avcodec/svq3: Fix multiple runtime error: signed integer overflow: -237341 * 24552 cannot be represented in type 'int'
[21:14:06 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:7956757d7dac: avcodec/y41pdec: Fix width in input buffer size check
[21:14:07 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:742ccace7c35: avcodec/cavs: Check updated MV
[21:14:08 CEST] <cone-050> ffmpeg 03N^ 07release/3.0:00e8a7adf4af: avformat/wavdec: Check chunk_size
[21:14:09 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:7b4d0a2402b0: avcodec/dss_sp: Fix runtime error: signed integer overflow: 2147481189 + 4096 cannot be represented in type 'int'
[21:14:10 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:743c419a59bb: avcodec/eatqi: Fix runtime error: signed integer overflow: 4466147 * 1075 cannot be represented in type 'int'
[21:14:11 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c0744d75497b: avcodec/truemotion1: Fix multiple runtime error: left shift of negative value -1
[21:14:12 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:3812e40894d5: avfilter/vf_uspp: Fix currently unused input frame dimensions
[21:14:13 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:ee1258155129: avcodec/webp: Always set pix_fmt
[21:14:14 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:3cb8d1f2c167: avcodec/mpeg12dec: Fixes runtime error: division by zero
[21:14:15 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:ddc77f1f1e90: avcodec/aacdec_fixed: Fix multiple shift exponent 33 is too large for 32-bit type 'int'
[21:14:17 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:47c6f1b6008b: avcodec/dvbsubdec: Check entry_id
[21:14:17 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:07e8da34fab1: avcodec/cllc: Factor VLC_BITS/DEPTH out, do not use repeated literal numbers
[21:14:18 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:d75f932e7741: avcodec/cllc: Check num_bits
[21:14:19 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:b8c80b9d2dca: avcodec/msmpeg4dec: Check for cbpy VLC errors
[21:14:20 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:a53182a71c07: avcodec/diracdec: Fix Assertion frame->buf[0] failed at libavcodec/decode.c:610
[21:14:21 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:188e015c7b4b: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -17047030 cannot be represented in type 'int'
[21:14:22 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:43965feca7d3: avcodec/g723_1dec: Fix runtime error: left shift of negative value -1
[21:14:23 CEST] <Threads> and the lord said let there be fixes for all..
[21:14:23 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:b2d2e5917475: avcodec/texturedsp: Fix runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[21:14:25 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:86a7a933fcb9: avcodec/avcodec: Limit the number of side data elements per packet
[21:14:25 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:d302803c3939: avcodec/vp8dsp: vp7_luma_dc_wht_c: Fix multiple runtime error: signed integer overflow: -1366381240 + -1262413604 cannot be represented in type 'int'
[21:14:26 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:4bc3ae5533f2: avcodec/mlp: Fix multiple runtime error: left shift of negative value -1
[21:14:27 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:03b8d285df97: avcodec/aacsbr_template: Do not change bs_num_env before its checked
[21:14:29 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:113bba3a2a1d: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1
[21:14:30 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:f8502c267f0d: avcodec/webp: Add missing input padding
[21:14:30 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c24bff130d61: avcodec/ac3dec: Keep track of band structure
[21:14:31 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:09ac75c47ca0: avcodec/mlpdec: Check that there is enough data for headers
[21:14:32 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:f857975bfd2c: avcodec/svq3: Fix runtime error: signed integer overflow: 169 * 12717677 cannot be represented in type 'int'
[21:14:33 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:e1fcdf1930a7: avcodec/webp: Fix signedness in prefix_code check
[21:14:34 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:52f4c9c31fd3: avcodec/ffv1dec: Fix runtime error: signed integer overflow: 1550964438 + 1550964438 cannot be represented in type 'int'
[21:14:35 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:4ffab6703b61: libswscale/tests/swscale: Fix uninitialized variables
[21:14:37 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:49109b0c6fba: avcodec/g723_1dec: Fix LCG type
[21:14:37 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:99cbee2a2f58: avcodec/hqxdsp: Fix runtime error: signed integer overflow: -196264 * 11585 cannot be represented in type 'int'
[21:14:38 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:e2fd01c28228: avcodec/ac3dec: Fix: runtime error: index -1 out of bounds for type 'INTFLOAT [2]'
[21:14:40 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:eeece50aa2f4: avcodec/mpeg4videodec: Clear sprite wraping on unsupported cases in VOP decode
[21:14:40 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:a359138fb3aa: avcodec/dds: Fix runtime error: left shift of 210 by 24 places cannot be represented in type 'int'
[21:14:42 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:0246760e9451: avcodec/rscc: Check pixel_size for overflow
[21:14:42 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:98dff828d8b9: avcodec/cllc: Check prefix
[21:14:43 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:edf7bd14a8bd: avcodec/webp: Factor update_canvas_size() out
[21:14:44 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:8198258d9ef8: avcodec/webp: Update canvas size in vp8_lossy_decode_frame() as in vp8_lossless_decode_frame()
[21:14:45 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:2790054dc266: avcodec/snowdec: Check width
[21:14:46 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c82ea252e3d3: avcodec/flacdec: Return error code instead of 0 for failures
[21:14:47 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:9cd39ab7d3d4: avcodec/opus_silk: Fix integer overflow and out of array read
[21:14:49 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:ec7206fdf801: avcodec/aacps: Fix undefined behavior
[21:14:49 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:55d320ddf850: avcodec/tiff: reset sampling[] if its invalid
[21:14:51 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:cd4674f608b6: avcodec/svq3: Fix runtime error: left shift of negative value -6
[21:14:51 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:e05148dfe6d2: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int'
[21:14:52 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:dcbebc931eb9: avcodec/hq_hqa: Fix: runtime error: signed integer overflow: -255 * 10180917 cannot be represented in type 'int'
[21:14:54 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:e79851f2e7cd: avcodec/takdec: Fix runtime error: left shift of negative value -42
[21:14:55 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:28f2341e2f26: avcodec/mlpdec: Fix runtime error: left shift of negative value -1
[21:14:56 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:c32237e94850: avcodec/flicvideo: Check frame_size before decrementing
[21:14:57 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:a1babbd4de4f: avcodec/aacdec_template: Fix fixed point scale in decode_cce()
[21:14:58 CEST] <cone-050> ffmpeg 03Michael Niedermayer 07release/3.0:a1627fe9283d: avcodec/aacdec: Fix runtime error: signed integer overflow: 2147483520 + 255 cannot be represented in type 'int'
[21:15:08 CEST] <jamrial> maybe the bot should only track/report commits pushed to master :p
[21:15:15 CEST] <durandal_1707> yes
[21:15:43 CEST] <BtbN> Or batch pushes, and give a summary link
[21:40:16 CEST] <peloverde> michaelni: On closer inspection with a CCE file, I believe your fix is correct for valid files
[21:40:37 CEST] <michaelni> :)
[21:40:42 CEST] <peloverde> (and the previous code was incorrect)
[22:04:32 CEST] <cone-050> ffmpeg 03James Almer 07release/3.0:cf44f0ae6a52: avcodec/options: factorize avcodec_copy_context() cleanup code
[22:04:33 CEST] <cone-050> ffmpeg 03James Almer 07release/3.0:676ba8eff86d: avcodec/options: do a more thorough clean up in avcodec_copy_context()
[22:04:34 CEST] <cone-050> ffmpeg 03Aaron Levinson 07release/3.0:c54a76bf714b: avformat/utils: free AVStream.codec properly in free_stream()
[22:04:35 CEST] <cone-050> ffmpeg 03James Almer 07release/3.0:30415662ef7a: avformat/concatdec: fix the h264 annexb extradata check
[22:04:36 CEST] <cone-050> ffmpeg 03James Almer 07release/3.0:abe2d4de9286: avcodec/hevc_sei: fix amount of bits skipped when reading picture timing SEI message
[22:07:17 CEST] <BBB> peloverde: do you know if there will be an aom conference later this year for the community?
[22:07:24 CEST] <BBB> peloverde: independent of demuxed/vdd/*
[22:07:48 CEST] <BBB> peloverde: or is that sort of stuff only open to aomembers?
[22:08:12 CEST] <nevcairiel> you should join with your encoder company :d
[22:08:57 CEST] <peloverde> BBB: I have no idea
[22:09:45 CEST] <BBB> nevcairiel: I have no lawyers and no money to pay them
[22:10:04 CEST] <BBB> nevcairiel: plus, what could I possibly contribute that they dont already have? google has 1000s of smart engineers
[22:10:40 CEST] <BBB> (to the standardization process or bitstream features, I mean)
[22:11:02 CEST] <peloverde> most of the meetings are HW companies moaning about line buffers, whenever I try to bring up things like this change lets codable coefs get way way bigger no one seems to care
[22:11:51 CEST] <nevcairiel> so, it'll be as buggy as vp9?
[22:11:52 CEST] <nevcairiel> :)
[22:13:00 CEST] <wm4> BBB: those 1000s don't seem to exactly add up
[22:13:41 CEST] <BBB> peloverde: can you bring up internally (Im trying to poke j-b also since videolan is in aom and Im in videolan :-p) that it would be nice if the conformance suite extended beyond samples produced by one encoder, and more generally have the conformance suite test _all_ (no most, or some) features that are part of the standard (to prevent multi-arf, skip-p/direct-reference and intraonly in vp9)?
[22:14:48 CEST] <nevcairiel> is there even a nyone working on another encoder yet? the entire alliance thing seems like everyone putting their eggs into the aomenc basket
[22:15:16 CEST] <nevcairiel> its not like vpx had a good precedence of alternate encoders
[22:17:05 CEST] <BBB> why would anyone admit that publicly :-p
[22:17:27 CEST] <nevcairiel> well they kinda have to if you want samples of them =p
[22:18:00 CEST] <BBB> maybe such encoder companies dont want to give out samples since they would provide (some) insight into the inner workings of their encoding algorithms
[22:18:14 CEST] <BBB> they just want to make sure that the features used by their encoders are tested in conformance samples :-p
[22:18:23 CEST] <BBB> just hypothetically speaking of course ;)
[22:25:02 CEST] <peloverde> I'm sure Argon will sell test samples that have great bitstream coverage
[22:26:16 CEST] <peloverde> It would be nice to have them freely but making these kinds of decisions is not what I work on
[22:38:33 CEST] <BBB> peloverde: for pay is fine, as long as theyre available on day #1
[22:38:47 CEST] <BBB> peloverde: argon streams were not available when vp9 was finished, so the first generation of hw support is broken :(
[22:39:00 CEST] <BBB> not broken, just & not supporting all things equally
[22:40:46 CEST] <jgirot> Hi! I have found a regression and would like to file a bug report, but I cannot register a new account on trac.ffmpeg.org
[23:01:56 CEST] <cone-050> ffmpeg 03Paul B Mahol 07master:6111ac73d990: avfilter/af_afade: fix fading very long durations
[00:00:00 CEST] --- Thu May 18 2017
1
0
[00:10:35 CEST] <Cracki> I have a video file with large gops and I'd like to know which frames are intra/keyframes (cheap to decode). how to get those? just a pointer in the right direction please
[00:10:37 CEST] <debianuser> sikilikis: Maybe your kernel was build without high-resolution timer? Can you check sleep times on your kernel? Copy to some pastebin the output of: for i in `seq -w 100`; do time sleep .$i; done
[00:10:43 CEST] <Cracki> talking about ffmpeg _api_
[01:01:02 CEST] <teratorn> Cracki: I'm thinking AVPacket::flags
[01:02:00 CEST] <Cracki> I'm now at pyav. the vid.demux(vid.streams.get()[0]) -> packets. packet.decode() -> frames. frame.key_frame is 0 or 1
[01:02:14 CEST] <Cracki> however I'd like to get htat info without decoding the actual frames, just looking at them. what do I do?
[01:02:28 CEST] <Cracki> I think the workflow is similar to original lavf apis
[01:03:07 CEST] <teratorn> Cracki: relevant, http://stackoverflow.com/questions/14044335/keyframe-is-not-a-keyframe-av-p…
[01:03:12 CEST] <Cracki> thx
[01:03:49 CEST] <Cracki> I just want to know what frame indices are cheap to seek to
[01:04:26 CEST] <Cracki> my problem: i might need to play "backwards", so jump ahead to a keyframe, decode from there into buffers, then work with those frames.
[01:05:18 CEST] <Cracki> currently I'm just seeking -1 or -NUM relative using OpenCV, which seeks exactly to that position, even if it means decoding some frames and discarding them
[01:06:00 CEST] <Cracki> I'd be ok with "inaccurate-mode" seeking, if it'll tell me where it actually ended up
[01:07:17 CEST] <Cracki> video codec is usually h.264, very likely small gops (size ~4 I think), but in .m2ts, so no stored index
[01:07:42 CEST] <Cracki> (on occasion, also larger gops, ~100-500 frames)
[01:13:27 CEST] <teratorn> Cracki: you're doing your seeking based on frame numbers not timestamps?
[01:13:56 CEST] <Cracki> I can assume the frames are at a constant rate
[01:14:04 CEST] <Cracki> however I'd be ok with timestamp-based seeking too
[01:14:43 CEST] <Cracki> I just don't want to seek _into_ a GOP, or if I have to, I'd like to keep/get the frames that had to be decoded up to that exact point
[01:14:52 CEST] <teratorn> Cracki: well, you can check the flags on AVPacket to see if it holds a keyframe. then seek to that pts
[01:15:32 CEST] <Cracki> hm ok. unfortunately PyAV packets don't have flags or any other representation of keyframicity
[01:16:20 CEST] <Cracki> I understand this is not the channel if I have problems with pyav :P
[01:32:27 CEST] <Cracki> thanks though for avpacket::flags, I suspect pyav just didn't expose that
[02:19:26 CEST] <Cracki> ah, if I seek in a M2TS file, it jumps to the nearest gop after the pts I gave
[02:23:09 CEST] <Cracki> seems I can't jump reliably *at* a gop, meaning seek to the pts the first decoded frame would have, instead jumps to the next gop?
[02:59:48 CEST] <hxla> Hello guys, I have a gopro video file, that has multiple data streams, and I want to copy the video, audio and one specific data stream, but I can't, I get an error that the codec is not supported (https://pastebin.com/ZxSinT0P)
[03:00:13 CEST] <hxla> how should I copy this stream to another video file?
[03:11:31 CEST] <cryptodechange> I've seen aq2 and aq3 in some mediainfo results, is there any info on what this does?
[03:13:59 CEST] <cryptodechange> compared to standard aq
[03:23:24 CEST] <furq> http://vpaste.net/D50k8
[03:32:05 CEST] <cryptodechange> Thanks for that, I also looked at the git
[03:32:22 CEST] <cryptodechange> so 3, in theory, should be the best option?
[03:32:45 CEST] <cryptodechange> for maintaining quality
[03:32:45 CEST] <furq> if 3 was the best option it'd be the default
[03:33:15 CEST] <furq> there are presumably some sources where 2 and 3 give a significant quality boost, but that's evidently not the general case
[03:34:17 CEST] <furq> also from what i'm reading, 2 and 3 are prone to causing haloing on some sources
[03:34:42 CEST] <cryptodechange> I suppose dark, grainy films would benefit from aq 3
[03:34:52 CEST] <furq> shrug
[03:35:08 CEST] <furq> at a low enough crf, none of these settings will make any difference
[03:36:03 CEST] <cryptodechange> using crf=16 and aq=1, I noticed a bit of ringing around the stars in the universal studios intro
[03:36:30 CEST] <cryptodechange> At least that's what I think I see, slightly more pixelated around the bright stars
[03:36:31 CEST] <cryptodechange> will try with aq=3
[03:36:40 CEST] <furq> if grainy stuff generally benefited from 3 then tune grain would probably use it
[03:36:58 CEST] <furq> all the tunings use 1 except for psnr and ssim
[03:37:03 CEST] <furq> and you can safely ignore what they're doing
[03:38:48 CEST] <cryptodechange> I think I'm getting a slightly higher bitrate with aq=3 too
[03:38:57 CEST] <furq> that sounds about right
[07:36:50 CEST] <blue_misfit> hey guys I'm doing chunked encoding into mp4 files and then joining the resulting chunks using the concat demuxer. This is usually fine, but some sources are producing VFR outputs. Indeed the first frame at the start of each chunk (other than the first chunk ) has a DTS that's 1536 units higher than the last frame, whereas all the rest have a DTS difference of 512
[07:37:55 CEST] <blue_misfit> any ideas why this is happening?
[10:31:00 CEST] <zerodefect> I understand that AVFrame has the ability to handle reference counting. I'm struggling a bit to understand it though. There doesn't seem to be a method to decrement the reference count by '1'. There is only av_frame_unref(..) which clears all the references.
[10:33:16 CEST] <Mavrik> Hmm, unref certanly should decrement count by 1
[10:33:17 CEST] <jkqxz> The reference counting is on the buffers which make up the frame, not the frame structure itself. An AVFrame structure contains one reference to each buffer making up the frame data, and there can be multiple AVFrames referring to the same buffers.
[10:33:53 CEST] <Mavrik> Mhm that - the AVFrame will get destroyed but the underlying buffer is shared with other AVFrames you get by calling av_frame_ref or whatsit
[10:33:54 CEST] <jkqxz> So av_frame_unref() decrements the reference count on the buffers in that frame, and then clears the AVFrame structure.
[10:36:26 CEST] <zerodefect> Ah ok. That makes sense. So I could create my own buffer and assign it to multiple AVFrames?
[10:39:14 CEST] <zerodefect> Just trying to grasp the relationship between buffers and frames.
[10:44:45 CEST] <jkqxz> Correct. (Where assignment to an AVFrame is via setting the next member of the buf[] array inside the AVFrame to the result of av_buffer_ref(), and the corresponding data element to the actual pointer.)
[10:45:41 CEST] <zerodefect_> Connection bummed out
[10:46:53 CEST] <jkqxz> "08:44 < jkqxz> Correct. (Where assignment to an AVFrame is via setting the next member of the buf[] array inside the AVFrame to the result of av_buffer_ref(), and the corresponding data element to the actual pointer.)"
[10:47:39 CEST] <zerodefect_> Ok. Understood. Thanks for your help
[11:58:23 CEST] <k_sze> I have a question not strictly related to ffmpeg, but I can't think of where else to ask. In libjpeg, what's the difference between jpeg_read_raw_data and jpeg_read_scanlines?
[11:59:12 CEST] <k_sze> I assume that people in this channel are more likely to also be knowledgeable about libjpeg.
[12:00:22 CEST] <BtbN> I'd guess one reads raw data to decode, and the other one reads lines of pixels to encode?
[12:09:00 CEST] <k_sze> BtbN: The thing is, I read the documentation here: http://refspecs.linuxfoundation.org/LSB_3.1.1/LSB-Desktop-generic/LSB-Deskt… and http://refspecs.linuxfoundation.org/LSB_3.1.1/LSB-Desktop-generic/LSB-Deskt…
[12:09:08 CEST] <k_sze> And I have a hard time understanding the difference.
[12:09:53 CEST] <k_sze> The way I see gstreamer use jpeg_read_raw_data makes me think that it's also already decoded.
[12:10:56 CEST] <BtbN> Yeah, they both seem to be for decoding, as the first parameter is a decompress_ptr
[12:11:32 CEST] <BtbN> from the looks of it, you might need both?
[12:11:37 CEST] <BtbN> read_raw_data: "shall return upto max_lines number of scanlines of raw downsampled data into the JSAMPIMAGE array argument"
[12:11:53 CEST] <k_sze> And I have no idea what they mean by "downsampled"
[12:11:54 CEST] <BtbN> And jpeg_read_scanlines seems to take that as an input
[12:13:07 CEST] <k_sze> BtbN: No, jpeg_read_raw_data is not needed for jpeg_read_scanlines.
[12:13:30 CEST] <k_sze> I have seen libraries use only jpeg_read_scanlines.
[12:17:54 CEST] <BtbN> Maybe it gives you yuv420 data, or whatever raw format the jpeg image had, instead of decoding to RGB
[12:19:29 CEST] <BtbN> yeah, looks like it
[12:19:30 CEST] <BtbN> "To obtain raw data output, set cinfo->raw_data_out = TRUE before jpeg_start_decompress() (it is set FALSE by jpeg_read_header()). Be sure to verify that the color space and sampling factors are ones you can handle. Then call jpeg_read_raw_data() in place of jpeg_read_scanlines(). The decompression process is otherwise the same as usual."
[12:21:33 CEST] <k_sze> BtbN: where did you find that?
[12:21:49 CEST] <BtbN> https://www4.cs.fau.de/Services/Doc/graphics/doc/jpeg/libjpeg.html
[12:42:31 CEST] <k_sze> Thanks.
[13:53:35 CEST] <eynix> Hi everyone
[13:54:50 CEST] <eynix> I'm working on something to create a video from an openGL scene images
[13:55:04 CEST] <eynix> using openCV
[13:55:43 CEST] <eynix> the final avi file has this error when I open it with vlc : "avi error: no key frame set for track 0"
[13:56:37 CEST] <eynix> I'm kind of stuck, any clue ?
[14:06:38 CEST] <BtbN> why would you use avi?
[14:06:53 CEST] <BtbN> And why do you need opencv for that?
[14:07:09 CEST] <DHE> indeed. AVI has been on the way out for a decade
[14:07:14 CEST] <eynix> BtbN: I'm very new to this image/video thing
[14:07:26 CEST] <eynix> openCV looks a lot simplier than ffmpeg
[14:07:41 CEST] <BtbN> OpenCV is something entirely different than ffmpeg
[14:07:43 CEST] <eynix> and the example I found showing the openCV capability was using avi
[14:14:11 CEST] <eynix> BtbN: since openCV uses ffmpeg I though maybe you could know this error
[14:14:48 CEST] <BtbN> Using ffmpeg via OpenCV can easily cause all kinds of confusin. Better ask the OpenCV people about their wrapper layer.
[14:15:03 CEST] <eynix> (they send me there :x)
[14:15:15 CEST] <eynix> np, i'll find what's going on
[14:17:32 CEST] <BtbN> Well, when the avi muxer is used correctly, it usually produces a working file
[15:10:54 CEST] <pedjaman> Hello everyone :) Is there a comparisson chart(s) of supported video encoders/formats regarding file size and speed of encoding? Thanks :)
[15:51:40 CEST] <dystopia_> speed of encoding is down to cpu and encoding settings
[15:51:46 CEST] <dystopia_> same deal for filesize
[15:51:59 CEST] <dystopia_> you can't really make such a comparison chart
[15:53:37 CEST] <hlechner> Hey guys, anyone knows why same ffmpeg command to generate video's thumbnail generate a slight different size image when using jpeg compared with png? (jpeg:172/96) (png:172/97)
[15:54:16 CEST] <pedjaman> thanks. SHouldn;t that be actually comparable if we take CPU and settings as cosntant?
[16:08:32 CEST] <anchvi> Hi
[16:08:53 CEST] <anchvi> How can i add multiple transitions to an image in the video?
[16:09:13 CEST] <anchvi> I want image to slide from left to right and after a while from right to left
[16:09:21 CEST] <anchvi> I know how to do these separately
[16:09:26 CEST] <anchvi> but not together
[16:22:36 CEST] <kepstin> hlechner: the jpeg is probably using subsampled chroma, which means the dimensions have to be a multiple of 2. png doesn't have that restriction.
[16:23:22 CEST] <kepstin> (since the pixel format has to be converted to non-subsampled rgb for the png image)
[16:23:50 CEST] <iive> that's only for yuv420, and partially for 422, jpeg support 444 too
[16:25:28 CEST] <hlechner> Thanks guys
[16:36:06 CEST] <roasted> Hi friends. Checking out some nvidia documentation for enabling cuda in ffmpeg. I see documentation regarding compiling ffmpeg for use with this, but got to wondering if anybody knows if this is already built into recent ffmpeg versions or if a PPA (Ubuntu) may exist that I'm not finding?
[16:58:12 CEST] <BtbN> roasted, you don't need to do anything to build ffmpeg with most nvidia features.
[16:58:33 CEST] <BtbN> Some features need the CUDA SDK and flag ffmpeg as nonfree, so you won't ever find binaries for those
[17:00:09 CEST] <roasted> BtbN: sounds good. I'm working with an OBS rig with a GTX 1070 running Ubuntu and proprietary drivers. I just didn't wnat to be missing out on any untapped resources. :D
[17:00:31 CEST] <BtbN> OBS can only use the features it had programmed into it anyway
[17:01:00 CEST] <roasted> Things run *really* good, but it's just... if the hardware is capable of more, why not open that door, ya know? That's all I was curious about.
[17:01:13 CEST] <roasted> I assumed from this documentation this was something additional that can be set up beyond the 'standard' ffmpeg.
[17:03:39 CEST] <kepstin> roasted: keep in mind that the benefit from using gpu is ... kinda minimal. there's a few filters that can use gpu compute, I think? and you can use the hardware encoder rather than software encoding, but the hardware encoder's only really useful for realtime encoding if your cpu is busy doing something else, since the quality's rather lower.
[17:04:17 CEST] <roasted> kepstin: we'll be recording + streaming at once. Based on what OBS devs said, on Linux as the target OS for OBS, Intel CPU/Nvidia GPU is the best combo, so I ran with that.
[17:04:33 CEST] <roasted> (this is for a morning announcement video broadcast system for a school)
[17:06:32 CEST] <kepstin> what kind of video sources are you using? cameras, screen capture? what else is running on the box?
[17:07:17 CEST] <kepstin> i'd probably consider foregoing the gpu and just doing all software encoding if you're not doing other cpu intensive stuff on the box.
[17:07:24 CEST] <roasted> this box is dedicated to OBS. It'll run two Logitech C920 cameras, whcih are 1080 30 FPS cams but I'll likely downscale that to 720p for the stream. It'll record + stream at once on the same box. Nothing else will run on this box. It leverages nginx/rtmp to broadcast an rtmp stream that clients (teachers) will tap into.
[17:07:36 CEST] <roasted> The only other thing it'll run is a public nginx share for downloading past announcements.
[17:08:26 CEST] <roasted> We already have the hardware, it's already built and OBS is installed. I just got to thinking if (IF) I could get more resources out of it via compiling ffmpeg with the -nv flag (if I recall, I think that's what it is) if I could boost it a bit. But keep in mind, the box runs really good as is. I'm just strictly curious since I wondered if there was untapped resources available here.
[17:08:56 CEST] <kepstin> if you hadn't already bought the hardware, i'd recommend not buying the gpu and spending the money on more cpu. As it is, it's kind of going to waste, imo.
[17:09:22 CEST] <roasted> According to OBS devs, there are some benefits to having Nvidia GPU pending you have the proprietary drivers installed. What exactly, I'm not sure.
[17:09:37 CEST] <roasted> But the box already has a kaby i7, so we have some good CPU power.
[17:10:14 CEST] <kepstin> if you have the proprietary drivers installed, then you can use the hardware encoder on the gpu. This is lower quality than software encoding, but its useful if you're doing screen capture of CPU intensive apps
[17:10:29 CEST] <kepstin> or find yourself otherwise cpu limited
[17:10:41 CEST] <roasted> I'll have to tinker around with it and see. This is all testing mode at the moment. This isn't meant to launch until August.
[17:10:53 CEST] <roasted> I just wanted to cross off this "ffmpeg T" while I was in planning mode.
[17:11:27 CEST] <Nacht> The camera's are to be used as PIP over what you stream, or as source ?
[17:11:48 CEST] <roasted> At the moment I just have them plugged in as v4l devices.
[17:11:53 CEST] <roasted> They lit right up and the stream worked fine.
[17:13:34 CEST] <kepstin> roasted: yeah, simply "enabling nvidia support" in ffmpeg won't magically make everything faster. It just means you have the option of using the hardware encoder instead of software encoder (software encoder is still default), and a couple of filters that you're probably not using might gain some gpu accelleration.
[17:13:50 CEST] <roasted> good to know.
[17:14:23 CEST] <roasted> truth be told I was kind of hoping to let it as-is, so this is good news (for me). But like I said, if there was some magical bonus to compiling ffmpeg in a way to better leverage the nvidia hardware, I wouldn't sneeze at it.
[17:14:29 CEST] <kepstin> but on the other hand, you probably have a decent rig for doing some gaming during downtime, so... :/
[17:14:42 CEST] <roasted> kepstin: ...ssshhhhh!
[17:14:57 CEST] <roasted> appreciate the insight guys. :)
[17:15:13 CEST] <kepstin> and you don't even need the nvidia gpu to do hardware encoding; the intel cpu has a hardware encoder on it too (I dunno if obs supports using it?)
[17:15:31 CEST] <roasted> I'm not sure.
[17:16:04 CEST] <roasted> It's a long story, but basically, video studio hasn't been upgraded in many years, wiring upgrade happening to building, current studio won't work, needed something else, enter OBS, OBS devs said Nvidia GPU can be a bonus, I ran with it.
[17:16:47 CEST] <roasted> I had a lot to do, check, plan in a short amount of time, so I wasn't in the business or position of taking chances or making guesses without further testing. And I needed hardware to *really* test, so...
[17:17:04 CEST] <dbpolito> Hello guys, does ffmpeg have support to Right-to-Left subtitles? I see it have a option called text_shaping for drawtext, but i don't see a way for doing it for subtitles... help? =)
[17:17:52 CEST] <kepstin> roasted: keep in mind that OBS is very commonly used for livestreaming screen capture of stuff like games or other cpu+gpu intensive applications, where having a decent gpu and hardware encoding are real benefits
[17:18:07 CEST] <roasted> definitely. I got that jist as I read into OBS more, for sure.
[17:18:40 CEST] <roasted> the video studio hadn't seen any love in years. I was given a budget and even with this rig I came in under half of the allotment to do everything I needed, so...
[17:18:49 CEST] <furq> dbpolito: i believe that works automatically if you built libass with fribidi
[17:18:54 CEST] <kepstin> dbpolito: I believe that the standard subtitle renderer used in ffmpeg (libass) should support rtl text just fine..? might depend on configure options on the external library.
[17:20:05 CEST] <dbpolito> huh, i'm currently using a .str file... do i need to use .ass instead? or it's possible to use libass with srt?
[17:20:13 CEST] <kepstin> roasted: think of it as investment in the future then, there might be some need that comes up later in the life of this hardware where having gpu and hardware encoding is useful :)
[17:20:26 CEST] <roasted> kepstin: for sure.
[17:21:47 CEST] <dbpolito> i'm currently using ffmpeg cli, installed from default ppa of ubuntu
[17:23:07 CEST] <kepstin> dbpolito: I'd expect it to work with srt, the same renderer is used for all text subtitle formats. I assume you're using the "subtitles" filter to do this?
[17:24:33 CEST] <dbpolito> kepstin: correct, something like: ffmpeg -i input.mp4 -vf "subtitles=input.srt" -strict -2 output.mp4
[17:24:59 CEST] <dbpolito> i add some forced_style too, but simple font size and color changes
[17:28:08 CEST] <dbpolito> i'm currently using: ffmpeg version 2.8.11-0ubuntu0.16.04.1, maybe it's because i'm using an old version
[17:31:09 CEST] <aster_> is this channel is appropriate for querying related to ffmpeg programming api instead of ffmpeg tools?
[17:32:56 CEST] <durandal_1707> yes it is
[17:34:05 CEST] <aster_> ok thanks
[17:39:38 CEST] <aster_> in Sws_context and in av_image_alloc, I'm using AV_PIX_FMT_YUV420P and SDL_CreateTexture uses SDL_PIXELFORMAT_YV12, but when I display picture it has greenish color, Where am i going wrong? Thanks
[17:47:51 CEST] <kepstin> aster_: I think ffmpeg's yuv420p and YV12 have the color planes swapped; you can probably fix it by just switching the U/V plane pointers between the two.
[17:52:22 CEST] <aster_> Sorry It''s my mistake, I mess up param in SDL_UpdateYUVTexture call, I corrected and its working. Thanks for your suggestion
[20:01:24 CEST] <OzgrK> hi, i am trying to create a 16 hour video by looping an online png image at wikimedia. encoding is so slow (starts fast but stablizes around 0.6fps) using http protocol for input. also it takes a while (sometimes a couple of minutes) to start encoding but i think it is fine since ffmpeg downloads the image first and my intenet connection is not stable... but when i downlaod the png file and use it locally with file protocol to encode, t
[20:01:54 CEST] <OzgrK> again but stablizes around 25-26fps approx). i am suspicious that ffmpeg tries to pull the png image from wikimedia website each time to loop it. i tried to use cache:URL and async:cache:http://host/resource options but not sure they are for this task and also not sure if i applied them righr in my command. is there a way to make ffmpeg download an image once using http protocol as input and cache it to use for -loop so that speed woul
[20:02:31 CEST] <OzgrK> the default behaviour and the cause of the very slow spped is something else? any help much appreciated outputs of both methods i mentioned above are at https://pastebin.com/Sv82x0Ey . i did quit the processes around points where the processing speed stabilizes
[20:08:02 CEST] <arvut> do I need to supply a videocodec when copying audiostream from a video?
[20:08:14 CEST] <arvut> or just -c:a copy?
[20:08:27 CEST] <dystopia_> copy is fine
[20:08:33 CEST] <dystopia_> -acodec copy also
[20:08:36 CEST] <dystopia_> both do the same thing
[20:08:50 CEST] <dystopia_> if you don't want video
[20:08:53 CEST] <dystopia_> do -vn
[20:09:00 CEST] <arvut> thanks
[20:09:05 CEST] <dystopia_> np
[20:09:36 CEST] <kepstin> OzgrK: is it an option for you to just download the image locally before doing anything else? Another thing to consider is using the loop filter rather than the loop input option, it might for your this.
[20:10:13 CEST] <arvut> dystopia_: so I could save it in the same container but without video then, the file is a .mp4
[20:10:37 CEST] <Threads> yes
[20:11:41 CEST] <dystopia_> you can do yeah but may as well save it as .mp2 .ac3 .aac or what ever it is
[20:13:01 CEST] <arvut> .aac actually
[20:13:13 CEST] <arvut> Output file #0 does not contain any stream
[20:13:27 CEST] <arvut> I can play it in mpv and it plays just fine
[20:14:18 CEST] <arvut> oh wait, forgot -i
[20:15:55 CEST] <arvut> weird, mixxx cannot play the .aac file but can play the .mp4 container containing same audio
[20:25:56 CEST] <kepstin> yeah, raw aac bitstreams are fairly unusual to see, I'd expect aac in mp4 (aka .m4a) would be better supported
[21:07:10 CEST] <alexpigment> does anyone know if ffmpeg 32-bit is large address aware (can utilize 4gb of memory on a non-32-bit OS) by default?
[21:07:14 CEST] <alexpigment> or does this still require a patch?
[21:08:52 CEST] <BtbN> why use a 32bit version on a 64 bit OS?
[21:17:59 CEST] <alexpigment> @BtbN, it's being called by a 32-bit application
[21:18:55 CEST] <alexpigment> rather than make two installations, it's easier to make one installation and just have ffmpeg large address aware
[21:19:15 CEST] <JEEB> alexpigment: if it's a subprocess then it doesn't really matter
[21:19:25 CEST] <JEEB> you can call a 64bit binary from a 32bit binary
[21:19:37 CEST] <alexpigment> JEEB, it's not about calling one from the other
[21:19:44 CEST] <JEEB> with libraries it gets less nice but it's still possible to do out of process
[21:19:47 CEST] <alexpigment> it's about making one installer for the application that works on 32-bit and 64-bit
[21:19:48 CEST] <JEEB> if you really want to
[21:20:12 CEST] <JEEB> alexpigment: just check if the OS is 32bit or 64bit? most installer systems let you do that
[21:20:30 CEST] <JEEB> and most likely your app will not die if the installer is ~10MiB bigger
[21:21:19 CEST] <alexpigment> i understand your logic, and i do appreciate it, but my ideal goal is dependent on whether ffmpeg 32-bit is large address aware by default or needs to be patched
[21:22:19 CEST] <JEEB> LARGEADDRESSAWARE gets set in some configurations
[21:22:33 CEST] <JEEB> but in any case, if you are running to 4GiB of RAM you are most likely going to run out of RAM soon
[21:22:55 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e81eca0ce59aa4973bc53ec064…
[21:23:27 CEST] <alexpigment> ok, so this is committed to the main branch at this point?
[21:23:34 CEST] <alexpigment> that's great to hear. thank you
[21:24:12 CEST] <alexpigment> i was reading a mailing list submission for a patch from sept 2010, but i didn't see any indication that it was going to get committed
[21:25:00 CEST] <JEEB> but yea, with 64bit binaries you also get a lot of other optimizations so in general it really doesn't make sense to try and run a 32bit binary there
[21:25:14 CEST] <alexpigment> JEEB: you'll just have to trust me on this one
[21:25:24 CEST] <kepstin> just the fact that the x86_64 abi has double as many registers can help in a lot of cases :/
[21:25:28 CEST] <JEEB> ^this
[21:25:45 CEST] <JEEB> and that people have stopped caring about trying to fit their hand-written optimizations to the lesser amount of registers
[21:26:09 CEST] <JEEB> so while things won't be getting slower, they most likely are not going to start getting faster
[21:26:28 CEST] <JEEB> (and in certain things there's already a pretty big gap)
[21:28:13 CEST] <alexpigment> i understand what you're saying. the installer is completely custom, and can't support putting in a different file based on the OS without modification. i'm currently using the path of least resistance
[21:28:36 CEST] <alexpigment> of course i agree that 64-bit is better and will try to push for that
[21:28:44 CEST] <JEEB> enjoy that
[21:31:19 CEST] <alexpigment> JEEB: i'm not a developer. but i do get a lot of traction by saying "this requires no developer time" :)
[21:31:46 CEST] <alexpigment> and i'm guessing that you, as a developer, probably cannot relate to that scenario at all
[21:33:24 CEST] <JEEB> depends on the situation
[21:33:42 CEST] <JEEB> if you can get something done without work that won't bite you in the long term that's all good
[21:34:11 CEST] <JEEB> my comments mostly come because there really are people who don't have such limitations and just don't know here every now and then :P
[21:34:40 CEST] <alexpigment> yep. this is a short term thing and is under limitations. the long term goal does not have such limitations and will be done "right"
[21:34:46 CEST] <JEEB> ooh
[21:34:50 CEST] <JEEB> the classic thing :D
[21:35:04 CEST] <JEEB> man, how many PoCs have ended up in production and maintained :P
[21:36:08 CEST] <alexpigment> i can assure you it won't. i've already built the 64-bit builds of FFMPEG for the next generation product which is not 32-bit
[21:36:52 CEST] <alexpigment> i'm effectively just trying to add some extra legs to an EOL product at the moment
[21:44:42 CEST] <OzgrK> kepstin: there is no problem with the downloaded local file but i need to input an online image. when i used the "filter" "loop" as -vf loop=loop=1440 instead of -loop 1, it producs just a single frame
[21:44:52 CEST] <OzgrK> my initial command was ffmpeg -loop 1 -i https://upload.wikimedia.org/wikipedia/commons/c/c4/PM5544_with_non-PAL_sig… -vf hue=h=t*360/57600 -t 57600 -pixel_format yuv420p -c:v libvpx-vp9 -lossless 1 testHttp1.webm
[21:45:55 CEST] <kepstin> OzgrK: why can't you replace "ffmpeg -loop 1 -i https://..." with "wget https:// && ffmpeg -loop 1 -i ..." ?
[21:47:04 CEST] <kepstin> that said, in order to use the loop filter, you need to set the size parameter, so e.g. "-vf loop=size=1:loop=-1" to loop a single frame forever
[21:47:13 CEST] <kepstin> by default the size is 0 so it does nothing
[21:50:17 CEST] <R1CH> is it normal for avcodec_decode_video2 to return a larger value than the input packet size if a complete frame wasn't decoded on a previous call?
[21:54:19 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/decode.c;h=fabdab…
[21:54:25 CEST] <BtbN> I'd say it's basically impossible?
[21:59:54 CEST] <R1CH> well that confuses things even further :|
[22:00:20 CEST] <BtbN> Which ffmpeg version?
[22:01:04 CEST] <R1CH> 57.61.100
[22:05:07 CEST] <JEEB> the library versions are rather unfortunate. I recommend either a git hash or the release version of the whole package if you're using a release branch
[22:05:48 CEST] <BtbN> cause decode_video2 is deprecated in the latest versions
[22:08:26 CEST] <R1CH> i saw, i think we are intentionally using this to keep compatibility with older installed ffmpeg packages
[22:08:48 CEST] <OzgrK> kepstin: i am trying to make it happen without using any other tool so wget option does not work for me but it just works fine, with same speed as file input when i use loop as "filter" as is in your sample! great. thanks. so what works is follows for my case is
[22:08:50 CEST] <OzgrK> ffmpeg -i https://upload.wikimedia.org/wikipedia/commons/c/c4/PM5544_with_non-PAL_sig… -vf loop=size=1:loop=-1,hue=h=t*360/57600 -t 57600 -pixel_format yuv420p -c:v libvpx-vp9 -lossless 1 testloop1.webm
[22:10:06 CEST] <OzgrK> speed is approx 25fps for 16 hour video but for a 2min video it is approx 16fps and for a 9 seconds of video it is much lower again... is this normal?
[22:11:23 CEST] <kepstin> OzgrK: the same video each time, just with different options for '-t' on the output to change the lenght?
[22:11:54 CEST] <OzgrK> yess and for 57600 in hue=h=t*360/57600
[22:12:27 CEST] <kepstin> there's a fair amount of work that has to be done once at startup with many video codecs, and also the time needed to download the frame off the web is included in that
[22:12:33 CEST] <OzgrK> i want a full hue circle change over the total duration of the video
[22:12:56 CEST] <kepstin> so if you take the long time for the first frame and the short time for each frame after that, then average them, a longer video will have a higher average framerate than a shorter video
[22:13:24 CEST] <OzgrK> ok, that makes sense, thanks. i have an1ther issue though
[22:13:26 CEST] <kepstin> and also the more change per frame the longer the frame takes to encode
[22:13:45 CEST] <kepstin> so if you make the hue cycle shorter, the frames are less similar, so they'll be slower to encode
[22:14:00 CEST] <kepstin> although that depends on the codec, it's not always true
[22:14:46 CEST] <OzgrK> i also want to fade out a 16 hour sound starting the fade in the begiining and fade out at the end of 16 hour totally, so it will be a veeery slow fade out
[22:14:48 CEST] <OzgrK> -f lavfi -i sine=frequency=1000:sample_rate=44100:duration=57600,afade=t=out:st=0:d=57600
[22:15:00 CEST] <furq> kepstin: i assume that's not the case for lossless libvpx
[22:15:35 CEST] <kepstin> yeah, I haven't played with that yet.
[22:15:42 CEST] <OzgrK> when i use this it doesn't work for such a long audio but when i use a smaller duration for total audio duration and fade duration, for example 60 seconds. it works as aspected. any idea?
[22:15:59 CEST] <kepstin> but with such a slow color fade, it's possible that you might have a bunch of identical frames in a row, so it could just be doing fast skip...
[22:16:16 CEST] <durandal_1707> OzgrK: define doesnt work
[22:17:35 CEST] <durandal_1707> near end it shouldbe silence
[22:17:49 CEST] <OzgrK> it was silence when i tried it yesterday but know i cannot reproduce it. gimme a min, pls
[22:17:49 CEST] <durandal_1707> if not its some kind of bug
[22:18:20 CEST] <OzgrK> not near the end but from the very beginning. i am tryin with ffplay now, lemme encode
[22:19:00 CEST] <cryptodechange> my encode jumps up by 2mbits when I change the horizontal cropping from 800 to 802
[22:19:11 CEST] <furq> durandal_1707: thanks for crossfeed btw
[22:19:13 CEST] <OzgrK> yes i have reproduced it.
[22:19:17 CEST] <OzgrK> -f lavfi -i sine=frequency=1000:sample_rate=44100:duration=57600,afade=t=out:st=0:d=57600
[22:19:22 CEST] <furq> i'll probably rebuild tomorrow and check it out
[22:19:32 CEST] <OzgrK> this produces a silence when run with ffplay. lemme try to encode once more
[22:19:58 CEST] <kepstin> cryptodechange: what codec?
[22:20:06 CEST] <OzgrK> without the fade out filte it works fine and creates a sine sound
[22:20:29 CEST] <kepstin> cryptodechange: note that 800 is divisible by standard macroblock sizes like 8 and 16, while 802 is not, so codecs are less efficient with the larger crop
[22:21:03 CEST] <kepstin> cryptodechange: as for a "2mbit jump", well, that's meaningless without context
[22:23:17 CEST] <durandal_1707> OzgrK: i will reproduce and fix ASAP
[22:25:25 CEST] <willbarksdale> Hey Folks, got a question, I was hoping someone could point me in the right direction. I am using FFmpeg to decode an RTMP stream. The stream opens find and streams for a bit, but after somewhere between 1-10 minutes, I get a hanging call to av_read_frame(...) which I can't seem to recover from without tearing down everything and reconnecting to the stream. Are there any known gotchyas that might be causing this? I am using FFmpe
[22:25:25 CEST] <willbarksdale> g compiled for iOS
[22:25:29 CEST] <OzgrK> thanks i am also trying to encode with opus in webm container and will report result. but encoding also didn't work when i tried yesterday. probably because of veeery long fade out option. if i change the 57600 (16h) with 60 for example it works. do you have an idea about the couse of the problem. is it really a bug
[22:26:34 CEST] <OzgrK> when i encode it is also total silence of 16 hours
[22:26:53 CEST] <OzgrK> just completed
[22:41:23 CEST] <CoJaBo> Anyone happen to know anyone who creates Youtube videos (professionally or semi-professionally..)?
[22:46:14 CEST] <james999> CoJaBo: well i have an account and ffmpeg but don't make videos
[22:46:17 CEST] <james999> what's your question?
[22:46:43 CEST] <CoJaBo> Uless you used it, you won't have been affected by The Incident :/
[22:51:48 CEST] Action: kepstin posts silly videos every week, but doesn't do any monetization or have any sizable fan base.
[22:51:59 CEST] <jgirot> Sorry, not sure which channel to ask for help registering a new account on trac.ffmpeg.org. I'm getting an error after filling in new username/password etc.
[23:04:31 CEST] <durandal_1707> OzgrK: fixed afade with very long durations in latest master
[23:05:12 CEST] <OzgrK> great!thanks!
[23:50:26 CEST] <kms_> ALSA buffer xrun
[23:50:30 CEST] <kms_> wtf?
[23:55:54 CEST] <debianuser> kms_: "alsa buffer" is what soundcard writes data to (capture) or reads data from (playback). When the app records some sound it asks the soundcard to write data to that buffer, and it's app duty to read the data from it in time, if it doesn't, the buffer overflows and you get "alsa buffer overrun" error.
[23:56:48 CEST] <debianuser> It's not a fatal error, application should automatically recover from it and restart the capture, but you may hear a slight click sound in recorded data when that happens
[23:56:49 CEST] <kms_> how to improve?
[23:57:03 CEST] <debianuser> make sure app has enough CPU to read the buffer in time
[23:57:46 CEST] <kms_> sound is bad, it is stream from mic
[23:58:58 CEST] <kms_> after restart is ok, but after 20 sec error repeat
[00:00:00 CEST] --- Thu May 18 2017
1
0
[00:26:11 CEST] <jkqxz> Can it be assumed that files uploaded to the bug tracker are ok to be put in fate?
[00:33:17 CEST] <J_Darnley> I think not.
[00:33:43 CEST] <J_Darnley> I seem to recall some fuss over the "standard" lena image a few years ago.
[00:33:58 CEST] <J_Darnley> Maybe because it was porn, maybe because it is copyrighted.
[00:34:49 CEST] <J_Darnley> Uploaded samples may have the same problems.
[00:36:08 CEST] <Threads> lol do people actually upload porn samples ?
[00:42:33 CEST] <nevcairiel> technically lena is "porn", it is a scan from playback afterall
[00:42:46 CEST] <nevcairiel> but yes, some of the most broken and weirdest samples are porn
[00:42:54 CEST] <nevcairiel> playboy*
[00:47:07 CEST] <Compn> jkqxz : ask whoever maintains fate about adding whatever sample
[00:47:22 CEST] Action: Compn not helping
[00:47:23 CEST] <Compn> hehe
[00:54:36 CEST] <jamrial> J_Darnley: lena was debian and because licenses
[00:55:49 CEST] <J_Darnley> ah
[00:57:55 CEST] <thebombzen> hey, I'd like to submit a short documentation patch
[00:58:04 CEST] <thebombzen> (http://0x0.st/gpn.patch)
[00:58:29 CEST] <thebombzen> do these go through the mailing list anyway, even ones small like this
[00:59:08 CEST] <J_Darnley> If you don't have commit access then you will need to ask someone to do that somewhere.
[00:59:38 CEST] <thebombzen> well yea but I meant do I need to go through the mailing list or is putting it here enough
[01:08:18 CEST] <JEEB> I've seen plenty of doc patches on the ML
[01:08:40 CEST] <JEEB> git send-email is your friend if you like command line (once you set up SMTP with it)
[01:08:54 CEST] <JEEB> (and yes, it's got a dry-run switch)
[01:11:03 CEST] <J_Darnley> just make sure you install all the required bits before editing an email.
[01:11:27 CEST] <J_Darnley> otherwise you'll hit save, it will try to send, fail, then you'll have to make it again.
[01:24:14 CEST] <thebombzen> I've used send-email before, I just didn't know if it was necessary to use something heavyweight like that for such a minor patch. but will do
[01:26:29 CEST] <thebombzen> JEEB: do I need a message ID?
[01:26:47 CEST] <nevcairiel> no, thats only for replying to existing mails
[01:28:04 CEST] <thebombzen> alright sent it
[01:36:12 CEST] <thebombzen> oops
[01:38:47 CEST] <thebombzen> alright rejoined and resent
[01:50:21 CEST] <jamrial> nevcairiel: push your hvcc patch already :p
[01:51:21 CEST] <nevcairiel> hvcc?
[01:51:24 CEST] <nevcairiel> you mean vpcc?
[01:51:34 CEST] <jamrial> right, that
[01:58:25 CEST] <nevcairiel> my fate box should also be back up soon, been doing a long-overdue rebuild now that the disc was finally full, purging old msvc versions is such a pain, better to start fresh
[02:15:21 CEST] <cone-685> ffmpeg 03Hendrik Leppkes 07master:64ad44a3817a: movenc/isom: update vpcC box to version 1.0 of the specification
[02:23:59 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07master:f08122fbe039: avcodec/tiff: reset sampling[] if its invalid
[02:24:00 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07master:a6eb006ad47b: avcodec/svq3: Fix runtime error: left shift of negative value -6
[02:28:09 CEST] <DHE> libavfilter is not very friendly to being updated for parallel processing. I wanted to add either per-filter threads (a true pipeline using threading) or at least allow [a]split to distribute, but it's a lot less friendly to that...
[02:28:31 CEST] <DHE> are the internals of libavfilter documented for hacking somewhere?
[02:29:21 CEST] <J_Darnley> In my opinion: not really, no
[02:30:02 CEST] <DHE> I was afraid of that...
[02:30:07 CEST] <J_Darnley> I recall that I never understood it quite well enough to finish my idea of writing an example filter
[02:30:58 CEST] <J_Darnley> One that does nothing but pass frames through but shows the places where you should buffer, should return more than 1 frame, etc.
[02:31:50 CEST] <J_Darnley> Even that sounds like it isn't enough for what you're asking
[02:32:50 CEST] <DHE> I'm more interested in the avfilter framework itself. the graph builder, filter allocator and connector, and so on
[03:18:26 CEST] <jamrial> J_Darnley: "h264_idct.asm:1144: warning: redefining multi-line macro 'STORE_DIFFx2'"
[03:20:07 CEST] <J_Darnley> Ah. I thought I had fixed that. It should still work though.
[03:21:04 CEST] <J_Darnley> Oh no. I had to comment out that %unmacro
[03:53:44 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07release/3.2:c521f9a5cd8c: avcodec/tiff: reset sampling[] if its invalid
[03:53:45 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07release/3.2:8e6d9d48a0b4: avcodec/svq3: Fix runtime error: left shift of negative value -6
[03:53:46 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07release/3.2:1274e920152d: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int'
[03:53:47 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07release/3.2:f61c888743d1: Update for FFmpeg 3.2.5
[04:23:08 CEST] <cone-685> ffmpeg 03Gregory J. Wolfe 07release/3.2:5d737a3d0ca2: avformat/tests/fifo_muxer: includes libavformat/network.h to define ETIMEDOUT for fate build.
[04:37:19 CEST] <cone-685> ffmpeg 03Michael Niedermayer 07n3.2.5:HEAD: avcodec/svq3: Fix runtime error: left shift of negative value -6
[04:50:48 CEST] <jamrial> looks like we're getting some spam in trac
[04:51:29 CEST] <jamrial> and now it doesn't even load
[04:52:53 CEST] <alevinsn> nevcairiel: Did you have to patch d3d9.h to fix the issue with the IDirect3D9Ex vtable
[04:52:54 CEST] <alevinsn> ?
[04:53:01 CEST] <alevinsn> when building with MSVC?
[04:55:33 CEST] <alevinsn> I had to do that to get hwcontext_dxva2.c to work properly (with regard to dxva2_device_create9ex())
[05:02:07 CEST] <jamrial> michaelni: who manages trac? we're getting spam from what looks like a single user with several accounts in the above ticket
[05:02:46 CEST] <jamrial> llogan isn't around
[05:10:57 CEST] <michaelni> jamrial, ive added you to the spam fighters so you have some more permissions, maybe it will come in usefull
[05:11:20 CEST] <michaelni> iam a bit tired ATM (should go to bed ...) :(
[05:11:23 CEST] <jamrial> michaelni: cool, thanks
[07:10:51 CEST] <alevinsn> jkqxz: you there?
[07:49:53 CEST] <ubitux> wtf is wrong with the guy in #6389
[09:08:19 CEST] <wm4> [amediaformat @ 0x2030432300] No Java virtual machine has been registered
[09:08:35 CEST] <wm4> mateo`: I guess ffmpeg.c doesn't work with mediacodec due to missing JNI crap?
[09:15:48 CEST] <JEEB> wm4: yea
[09:16:19 CEST] <JEEB> since the JVM instance auto-get thing wasn't something usable
[09:19:34 CEST] <jkqxz> alevinsn: Yes.
[10:29:24 CEST] <cone-630> ffmpeg 03Aman Gupta 07master:376247a1028f: configure: jni no longer requires -ldl
[11:17:18 CEST] <durandal_170> llogan is adding bad ips out of where?
[11:18:42 CEST] <wm4> probably spam?
[11:21:21 CEST] <durandal_170> votes are not spam
[11:24:00 CEST] <nevcairiel> if its the same person doing the voting, it is =p
[11:24:11 CEST] <stevenliu> It's not
[11:25:18 CEST] <stevenliu> The winlin is my friend, he invitation many people to append message vote to the ticket :)
[11:25:27 CEST] <nevcairiel> you should find better friends
[11:25:56 CEST] <stevenliu> There have lots of people invitation him add the hevc codec into flv and his SRS rtmp server
[11:26:18 CEST] <stevenliu> for support real time live stream
[11:26:39 CEST] <nevcairiel> supporting a new codec in a container is not something you can just make appear, it requires an official specification, otherwise you just produce unreadable files
[11:26:41 CEST] <JEEB> basically he should stop ignoring what I actually said and not focus on what I mentioned regarding HLS/DASH
[11:27:06 CEST] <nevcairiel> especially in a container like flv which doesnt use FourCCs or whatever
[11:27:09 CEST] <nevcairiel> but a simple numeric index
[11:27:10 CEST] <JEEB> switching solutions to Matroska/MPEG-TS/fragmented mp4 over HTTP will make you more future-proof
[11:27:26 CEST] <JEEB> the fact that current software media server solutions don't have that is just... too bad
[11:27:34 CEST] <JEEB> FLV has come to the end of its useful lifespan
[11:27:37 CEST] <stevenliu> mhmm, i think mpegts is better way
[11:27:38 CEST] <AaronL> anyone here familiar with hwcontext_dxva2.c?
[11:27:52 CEST] <JEEB> stevenliu: well whatever you prefer. both matroska and mpeg-ts should be workable
[11:28:06 CEST] <JEEB> the fun fact of that person *completely* ignoring my points about that is just welp
[11:28:20 CEST] <JEEB> he just focuses ASDF ASDF HLS/DASH can't do 3-5 seconds of latency
[11:28:22 CEST] <stevenliu> but the CDN Compnay maybe not friendly support them
[11:28:40 CEST] <stevenliu> JEEB, Don't care that
[11:28:58 CEST] <JEEB> whatever stops them from breaking with your hacked-up RTMP
[11:29:08 CEST] <AaronL> nevcairiel: you there?
[11:29:09 CEST] <JEEB> if you hack up RTMP (FLV) with HEVC
[11:29:18 CEST] <stevenliu> He just want get a low latency result of HLS or DASH
[11:29:25 CEST] <nevcairiel> AaronL: everything builds just fine for me
[11:29:40 CEST] <AaronL> nevcairiel: the d3d9.h issue is a run-time problem
[11:29:43 CEST] <AaronL> not a build issue
[11:29:55 CEST] <AaronL> only occurs if using DXVA hardware frame context
[11:30:13 CEST] <AaronL> it may depend on the version of the Windows 10 SDK installed
[11:30:24 CEST] <AaronL> older versions of d3d9.h are missing an entry
[11:30:40 CEST] <AaronL> for one of the interfaces--only affects C-style COM usage
[11:31:11 CEST] <AaronL> anyway, I think I've found a bug having to do with hwcontext_dxva2.c (unrelated to the d3d9.h issue)
[11:31:17 CEST] <AaronL> I'm not sure what the proper way to fix it
[11:31:24 CEST] <AaronL> it is freeing memory that it shouldn't be freeing
[11:33:40 CEST] <nevcairiel> all win10 sdks I have seem to have the missing function, the 8.1 sdk seems to lack it though
[11:34:06 CEST] <alevinsn> yeah
[11:34:18 CEST] <alevinsn> at least with my install of Visual Studio 2015
[11:34:26 CEST] <alevinsn> it uses d3d9.h from the 8.1 SDK
[11:34:46 CEST] <alevinsn> and there are only UCRT related headers in the 10 directory
[11:35:33 CEST] <alevinsn> but, I just installed the latest Windows 10 SDK
[11:35:36 CEST] <alevinsn> and that has all the headers
[11:35:51 CEST] <jkqxz> What is the problem?
[11:36:01 CEST] <alevinsn> and it also fixes the source stepping issue with the CRT
[11:36:29 CEST] <alevinsn> as in, I can step through _aligned_malloc, etc
[11:36:45 CEST] <alevinsn> at least when using the debug CRT
[11:36:53 CEST] <alevinsn> ok, so, it crashes in buffer_pool_free()
[11:37:04 CEST] <alevinsn> for the pool associated with hwcontext_dxva2
[11:37:11 CEST] <nevcairiel> we should check for RegisterSoftwareDevice to be present and only then make use of 9ex then, i guess
[11:37:19 CEST] <alevinsn> I'm doing this through qsv (hw encoding)
[11:37:57 CEST] <alevinsn> so, there is the sort of fake qsv pool
[11:38:12 CEST] <alevinsn> and then the child hw frame context which is dxva2
[11:38:33 CEST] <alevinsn> it is crashing at the line buf->free(buf->opaque, buf->data);
[11:38:39 CEST] <alevinsn> for the dxva2 pool
[11:38:59 CEST] <alevinsn> the problem is, buf->data was not allocated by hwcontext_dxva2.c
[11:39:10 CEST] <alevinsn> each of the elements stored in buf->data are DXVA2 surfaces
[11:39:41 CEST] <alevinsn> that were originally created by CreateSurface()
[11:40:04 CEST] <alevinsn> a search for surfaces_internal
[11:40:16 CEST] <alevinsn> will demonstrate that's how data is assigned to buf
[11:40:26 CEST] <alevinsn> with the call to av_buffer_create() in dxca2_pool_alloc()
[11:40:59 CEST] <alevinsn> I think perhaps the solution is to pass in a dummy free
[11:41:03 CEST] <alevinsn> as the third parameter
[11:41:13 CEST] <alevinsn> to av_buffer_create()
[11:41:30 CEST] <alevinsn> qsv_pool_alloc() does that
[11:41:36 CEST] <alevinsn> when it calls av_buffer_create()
[11:42:12 CEST] <nevcairiel> alevinsn: for the record, building with msvc here uses the latest windows 10 sdk, but then again I do actually have them fully installed and not only the ucrt :)
[11:42:24 CEST] <alevinsn> nevcairiel: That's one way--but, there is a good reason to use 9ex--works with headless displays
[11:42:39 CEST] <alevinsn> I think it would be preferable to display a warning
[11:42:48 CEST] <nevcairiel> we dont do that
[11:42:50 CEST] <alevinsn> than revery to dx9
[11:43:13 CEST] <alevinsn> nevcairiel: I examined the check-in log that added support for Ex
[11:43:20 CEST] <alevinsn> that was specifically mentioned as the reason for doing that
[11:43:24 CEST] <nevcairiel> it should just check if the interface is working properly in configure, and only compile the 9ex code if that is the case
[11:43:40 CEST] <nevcairiel> well we still dont randomly spout warnings about missing features
[11:43:57 CEST] <wm4> you mean git commit?
[11:43:58 CEST] <alevinsn> if its done that way, then users won't know that they are missing something that is easily corrected
[11:44:09 CEST] <alevinsn> I just manually edited the file to correct it
[11:44:12 CEST] <nevcairiel> modifying a SDK header is not an "easy correction" in my book
[11:44:26 CEST] <wm4> what's wrong with the SDK header?
[11:44:28 CEST] <alevinsn> the line is already there for the non-ex interface
[11:44:33 CEST] <alevinsn> just copy and paste
[11:44:57 CEST] <nevcairiel> pre-win10 headers lack one function in the vtbl of the IDirect3D9Ex header, which makes its offsets wrong for C-style use
[11:45:18 CEST] <alevinsn> this has been an issue for many years and Microsoft only fixed it recently supposedly
[11:45:20 CEST] <wm4> ouch
[11:45:24 CEST] <wm4> so use win10 headers?
[11:45:28 CEST] <alevinsn> because almost no one uses the C-style
[11:45:37 CEST] <alevinsn> well, even some Win10 headers didn't have it fixed
[11:45:41 CEST] <alevinsn> was apparently fixed in 10240
[11:45:51 CEST] <wm4> ask MS to fix them?
[11:45:56 CEST] <alevinsn> but, if you just get it via Visual Studio 2015
[11:46:02 CEST] <alevinsn> it only installed the 8.1 d3d9.h header
[11:46:02 CEST] <nevcairiel> it is fixed, but they are not going to fix old releases of the windows sdk
[11:46:03 CEST] <wm4> alternatively we could provide our own headers in compat/
[11:46:27 CEST] <nevcairiel> meh its not worth that headache, just add a check and only use ex when the header is correct
[11:47:08 CEST] <alevinsn> I guess that's better than crashing
[11:47:10 CEST] <wm4> seems good
[11:47:23 CEST] <alevinsn> but, it would be nice to inform the user that their header is bad, I think
[11:47:31 CEST] <nevcairiel> like I said, we dont do that
[11:47:48 CEST] <alevinsn> I know, I think this is a special case
[11:47:52 CEST] <jkqxz> alevinsn: I think I agree with your surfaces_internal / buffer comments above. Dummy free function looks like the right solution.
[11:48:09 CEST] <jkqxz> Not sure why it doesn't always die, though.
[11:48:29 CEST] <alevinsn> jkqxz: it gets past it without any problems when built without using the debug C-runtime
[11:48:38 CEST] <alevinsn> with the debug C-runtime, it notices what appears to be
[11:48:42 CEST] <alevinsn> memory corruption
[11:48:47 CEST] <alevinsn> after the fake "free"
[11:48:54 CEST] <alevinsn> or rather, the free attempt
[11:49:12 CEST] <alevinsn> it isn't memory corruption
[11:49:49 CEST] <alevinsn> but, because of code in the debug version of _aligned_free
[11:50:19 CEST] <alevinsn> that expects 0xCD (or somethhing like that) to show up before the allocation returned to the user
[11:50:21 CEST] <alevinsn> and that isn't there
[11:50:27 CEST] <alevinsn> it reports memory corruption
[11:50:47 CEST] <wm4> uh wait
[11:51:08 CEST] <wm4> if no free callback is set, it should do nothing
[11:51:28 CEST] <wm4> you mean the last arg to av_buffer_pool_init2?
[11:51:46 CEST] <alevinsn> no, this is av_buffer_create()
[11:51:55 CEST] <alevinsn> the third arg is used to override the default free behavior
[11:52:02 CEST] <jkqxz> No, av_buffer_create(). It uses av_buffer_default_free(), which is av_free(), if you don't pass an argument.
[11:52:06 CEST] <alevinsn> otherwise, it uses av_buffer_default_Free()
[11:53:46 CEST] <wm4> ok
[11:54:32 CEST] <wm4> I'm fairly sure the AVBuffer should reference the surface though
[11:54:42 CEST] <wm4> instead of implicitly relying that something else does
[11:54:43 CEST] <wm4> maybe
[11:56:41 CEST] <alevinsn> nevcairiel: do you know if Zeranoe builds with MSVC or gcc for Windows?
[11:58:02 CEST] <nevcairiel> probably gcc
[11:58:27 CEST] <nevcairiel> msvc would probably hell to get going with all those useless external libraries
[11:59:05 CEST] <BtbN> Pretty sure it's a cross-compile aswell
[11:59:27 CEST] <nevcairiel> that isnt exactly required
[12:00:08 CEST] <alevinsn> do you know anyone else that builds using MSVC?
[12:01:03 CEST] <nevcairiel> unless you need it for static linking or debugging purposes, there probably isnt a good reason to do that, builds are slower and its hard
[12:01:09 CEST] <nevcairiel> so likely very little people do that
[12:02:10 CEST] <alevinsn> debugging is the main reason it seems
[12:02:15 CEST] <alevinsn> you can't do static linking with gcc?
[12:03:23 CEST] <nevcairiel> it uses a different crt, so static linking a msvc build app to a mingw-gcc library is a bit iffy
[12:03:59 CEST] <alevinsn> possibly even true for dynamic linking?
[12:04:01 CEST] <nevcairiel> it is possible, but requires hacking
[12:04:07 CEST] <nevcairiel> dynamic linking works fine
[12:05:03 CEST] <wm4> the only "real" reason to build on MSVC is apparently winrt, which doesn't support dxva2 anyway
[12:05:21 CEST] <nevcairiel> i would use msvc builds at all times if they werent quite a bit slower
[12:06:18 CEST] <alevinsn> nevcairiel: I guess it works fine because all memory passed to ffmpeg DLLs is allocated and deallocated in ffmpeg code
[12:06:29 CEST] <alevinsn> if someone used free() instead of av_free(), might be problematic
[12:06:59 CEST] <nevcairiel> well of course, the public API documents which memory requires using av_malloc/av_free
[12:07:48 CEST] <nevcairiel> under the hood its also _aligned_malloc, so even if it would be the same crt you would have to use _aligned_malloc as well, ordinary memory from malloc or new would never be fine
[12:09:02 CEST] <nevcairiel> (although its generally not that commong for user-allocated memory to be free'ed by the library, or vice-versa)
[12:10:36 CEST] <alevinsn> jkqxz: yeah, that fixes it
[12:10:47 CEST] <alevinsn> a pretty easy fix
[12:13:21 CEST] <alevinsn> the whole way the QSV hwcontext is setup is incredibly complicated
[12:18:39 CEST] <jkqxz> Well, yes. Do you think any of the complexity is unjustified, though?
[12:19:41 CEST] <alevinsn> I don't know--much of it seems to be there to support Windows and Linux
[12:19:54 CEST] <alevinsn> I don't understand why the qsv code bothers doing some of the things it is doing
[12:19:55 CEST] <alevinsn> though
[12:21:39 CEST] <alevinsn> for example, in qsv_init_pool()
[12:22:00 CEST] <alevinsn> is allocates a surfaces_internal and fills out each surface
[12:22:20 CEST] <alevinsn> I don't know why it needs this if it is just going to use the child frame context for everything
[12:22:37 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:e6ec482b429b: opusenc: initialize PVQ prng seed
[12:22:38 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:8e7e74df93d1: opus_pvq: port to allow for SIMD functions
[12:22:39 CEST] <cone-630> ffmpeg 03Daniil Cherednik 07master:9c4e69b8eac8: avcodec/dcaenc: Do not abort process in case of bitrate deficit
[12:22:53 CEST] <alevinsn> furthermore, qsv.c allocates its own HW frame context as well
[12:23:14 CEST] <jkqxz> The mfxFrameSurface1 structures have to exist somewhere.
[12:24:11 CEST] <jkqxz> (The child context only supplies the MemId for each one.)
[12:25:34 CEST] <jkqxz> qsv.c allocates one if the user doesn't supply one.
[12:25:53 CEST] <alevinsn> I supplied one, and it is allocated no matter what
[12:26:34 CEST] <alevinsn> ok, I see how the mfxFrameSurface1 stuff is done
[12:26:49 CEST] <jkqxz> With H.265?
[12:26:51 CEST] <alevinsn> although, the Intel sample code has it being populated in a way that perhaps more sense
[12:26:54 CEST] <alevinsn> H.264
[12:26:59 CEST] <alevinsn> although I don't think that matters
[12:27:23 CEST] <alevinsn> in my code, I have something like:
[12:27:43 CEST] <alevinsn> // Allocate surface headers (mfxFrameSurface1) for encoder
[12:27:43 CEST] <alevinsn> mfxFrameSurface1 *pmfxSurfaces = new mfxFrameSurface1[numSurfaces];
[12:27:43 CEST] <alevinsn> memset(pmfxSurfaces, 0, sizeof(mfxFrameSurface1) * numSurfaces);
[12:27:43 CEST] <alevinsn> mfxU16 i;
[12:27:43 CEST] <alevinsn> for (i = 0; i < numSurfaces; i++)
[12:27:43 CEST] <alevinsn> {
[12:27:45 CEST] <alevinsn> memcpy(&(pmfxSurfaces[i].Info), &(m_mfxEncParams.mfx.FrameInfo), sizeof(mfxFrameInfo));
[12:27:47 CEST] <alevinsn> if (m_bUseVideoMemory)
[12:27:49 CEST] <alevinsn> {
[12:27:53 CEST] <alevinsn> pmfxSurfaces[i].Data.MemId = m_mfxResponse.mids[i];
[12:27:55 CEST] <alevinsn> }
[12:27:57 CEST] <alevinsn> else
[12:27:59 CEST] <alevinsn> {
[12:28:01 CEST] <alevinsn> mfxU8 *surfaceBuffer = (mfxU8 *) _aligned_malloc(surfaceSize, 32);
[12:28:03 CEST] <alevinsn> pmfxSurfaces[i].Data.Y = surfaceBuffer;
[12:28:05 CEST] <alevinsn> pmfxSurfaces[i].Data.U = pmfxSurfaces[i].Data.Y + (width * height);
[12:28:07 CEST] <alevinsn> pmfxSurfaces[i].Data.V = pmfxSurfaces[i].Data.U + 1;
[12:28:09 CEST] <alevinsn> pmfxSurfaces[i].Data.Pitch = width;
[12:28:11 CEST] <alevinsn> }
[12:28:13 CEST] <alevinsn> }
[12:28:22 CEST] <jkqxz> Please don't paste nontrivial things into the channel.
[12:28:32 CEST] <alevinsn> ok
[12:28:41 CEST] <alevinsn> rather than filling bogus parameters in surf->Info
[12:28:53 CEST] <alevinsn> like a frame rate of 25/1
[12:29:28 CEST] <atomnuker> planning to push the librsvg library wrapper in a few moments, any objections (patches have been on the ML for a week)
[12:30:05 CEST] <alevinsn> jkqxz: regarding qsv.c, what I see happen is
[12:30:08 CEST] <jkqxz> I'm not entirely familiar with it, but IIRC the external allocation requirement is because H.265 doesn't work properly with hardware surfaces input without it (due to additional buffer requirements).
[12:30:25 CEST] <alevinsn> it gets to qsv_frame_alloc()
[12:30:36 CEST] <alevinsn> hits the internal_frame case
[12:30:54 CEST] <alevinsn> and that automatically triggers the creation of a hwframe_ctx
[12:31:04 CEST] <alevinsn> this hwframe_ctx is different from the one
[12:31:07 CEST] <alevinsn> that is used by the user
[12:31:08 CEST] <jkqxz> And once you have the external allocator, the library forces you to use it for everything else as well. Hence it getting used for the reconstructed surfaces, separately to the input surfaces.
[12:31:25 CEST] <alevinsn> it has lock and unlock implemented, for example
[12:31:41 CEST] <jkqxz> And that's your second hwframes context in H.264.
[12:32:15 CEST] <alevinsn> I'm not aware of any special HEVC requirements
[12:32:31 CEST] <alevinsn> I basically use the same code for HEVC as I use for H.264
[12:32:58 CEST] <jkqxz> And you give it hardware surfaces at the input?
[12:33:04 CEST] <alevinsn> yes
[12:33:12 CEST] <jkqxz> (It would probably be easier to ask elenril about this.)
[12:33:19 CEST] <alevinsn> works with software memory as well, but it is more robust to use hardware memory
[12:34:23 CEST] <alevinsn> its just sort of odd to have two hwframe contexts and basically two different mfxFrameAllocator objects
[12:35:12 CEST] <alevinsn> elenril is on libav-devel?
[12:35:48 CEST] <alevinsn> yeah
[12:43:44 CEST] <alevinsn> I'd like to fix the memory leak with default_lockmgr_cb (in utils.c) for the AV_LOCK_OBTAIN case
[12:43:53 CEST] <alevinsn> but I'm not sure if a good way to free this memory
[12:44:00 CEST] <alevinsn> its only 87 bytes, but still....
[12:44:05 CEST] <alevinsn> sure of a
[12:44:29 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:a13eac5a9959: lavc: add codec ID and description for SVG
[12:44:30 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:f68ea9283347: img2dec: add support for piped SVG demuxing
[12:44:31 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:5fd4cffe3214: lavc: add a librsvg rasterization library wrapper
[12:44:54 CEST] <nevcairiel> you cant really fix this case
[12:45:46 CEST] <nevcairiel> a tiny one-time leak in an executable is rather irrelevant, it gets freed on exit anyway
[12:45:47 CEST] <durandal_170> omg, i forgot to block this svg nonsense
[12:45:57 CEST] <alevinsn> yeah, its allocated once for all the codecs
[12:46:14 CEST] <alevinsn> some sort of static cleanup I guess would be needed to eliminate the leak
[12:47:14 CEST] <durandal_170> vectorized video when?
[12:47:43 CEST] <alevinsn> maybe the reverse of av_register_all()?
[12:47:48 CEST] <alevinsn> that is called at the end of the program
[12:49:30 CEST] <nevcairiel> better would be to eliminate the need for the lockmgr and make everything thread safe, then we can just delete it :)
[12:49:55 CEST] <wm4> yes, the lock manager is bullshit and will be removed once all codecs have been fixed
[12:50:11 CEST] <nevcairiel> some people started working on it, but its along and tedious process
[12:50:36 CEST] <kierank> derek did a lot of work on it
[12:50:57 CEST] <kierank> but iirc it's not just needed for threadsafe stuff
[12:51:04 CEST] <kierank> there is some other reason
[12:51:09 CEST] <nevcairiel> he identified a bunch of codecs that were already safe
[12:51:12 CEST] <nevcairiel> not sure he fixed many
[12:51:27 CEST] <nevcairiel> but thats already helpful, to identify areas that need work
[12:52:36 CEST] <cone-630> ffmpeg 03Carl Eugen Hoyos 07master:66e56e7b2e76: librsvgdec: Fix pix_fmt on big-endian hardware.
[13:09:18 CEST] <atomnuker> J_Darnley, BBB: patch to use strip -x instead of -wN ..@ sent to the ML
[13:10:01 CEST] <alevinsn> jkqxz: I submitted a patch just now for the issue in hwcontext_dxva2.c
[13:10:40 CEST] <nevcairiel> your commit message would benefit from some whitespace
[13:10:41 CEST] <nevcairiel> :D
[13:12:10 CEST] <alevinsn> ?
[13:12:29 CEST] <alevinsn> not sure I follow
[13:13:08 CEST] <nevcairiel> an appropriate newline here and there increase readability
[13:13:37 CEST] <alevinsn> its a single paragraph
[13:13:41 CEST] <alevinsn> with like 3 sentences
[13:13:53 CEST] <alevinsn> maybe 5
[13:15:01 CEST] <nevcairiel> well my mail client shows it as 13 lines without a single line break
[13:15:39 CEST] <alevinsn> hmm
[13:15:55 CEST] <alevinsn> Each line is 72 characters long
[13:16:00 CEST] <alevinsn> there are technically line breaks
[13:16:05 CEST] <alevinsn> at most 72 characters long I mean
[13:16:25 CEST] <alevinsn> if you compare it to the lines of actual code
[13:16:35 CEST] <alevinsn> you'll see that there are no lines as long as those
[13:17:43 CEST] <alevinsn> but, if you meant, 13 lines without any blank lines in between
[13:17:46 CEST] <alevinsn> yes, that's correct
[13:17:56 CEST] <nevcairiel> who ever shortened the 80 col limit which was already insanely tiny even further to 72 anyway
[13:18:07 CEST] <alevinsn> It still seems to me to be a fairly short paragraph
[13:18:25 CEST] <nevcairiel> all I know is that it doesnt look extremely readable to me
[13:19:56 CEST] <alevinsn> ok, I don't think I'll do anything with it now though after 4 AM here
[13:20:18 CEST] <alevinsn> at least I now know how to use a hw frame context for encoding
[13:20:30 CEST] <alevinsn> there is only a qsv decoding example in doc/examples
[13:20:51 CEST] <alevinsn> its a bit non-intuitive
[13:20:54 CEST] <alevinsn> I think
[13:20:55 CEST] <nevcairiel> the hwcontext stuff is still rather new and under development
[13:21:28 CEST] <J_Darnley> atomnuker: thanks. I'll send a reply at some point.
[13:21:43 CEST] <alevinsn> maybe I'll create a sample to demonstrate how to do this
[13:21:46 CEST] <nevcairiel> ultimately jkqxz even dreams of a world without qsv decoding, and instead mapping dxva2 or vaapi surfaces into the qsv encoder
[13:22:01 CEST] <alevinsn> its already doing that
[13:22:14 CEST] <alevinsn> mapping dxva2 or vaapi surfaces into the qsv encoder
[13:22:17 CEST] <nevcairiel> was that merged ? i didnt pay much attention
[13:22:18 CEST] <alevinsn> it has to
[13:22:36 CEST] <alevinsn> I can't imagine that it ever worked without that
[13:22:59 CEST] <nevcairiel> well it could use the qsv pix_fmt, which hides a bit what it actually is
[13:23:05 CEST] <alevinsn> there is no such thing as a QSV surface
[13:23:08 CEST] <nevcairiel> straight from the qsv decoder
[13:23:13 CEST] <alevinsn> yeah, the QSV pix fmt is a little odd
[13:23:27 CEST] <nevcairiel> the point is to actually use dxva2 or vaapi decoding
[13:23:28 CEST] <alevinsn> but, it really is just a layer on top of DXVA2 or VAAPI pix fmt
[13:23:29 CEST] <nevcairiel> not qsv decoding
[13:23:36 CEST] <alevinsn> it has to use QSV decoding
[13:23:44 CEST] <alevinsn> I mean, I want it do use QuickSync
[13:23:52 CEST] <alevinsn> that's what actually provides the hardware encoding or decoding
[13:23:53 CEST] <nevcairiel> its the same hardware, so why?
[13:24:04 CEST] <alevinsn> DXVA2 doesn't provide any codecs
[13:24:06 CEST] <J_Darnley> More generally: I was looking at adding checkasm tests for the simple_idct code I wrote but I see there is already a test in 8x8dct. Does this test predate the creation of checkasm?
[13:24:07 CEST] <nevcairiel> if you can use dxva2 decoding and qsv encoding
[13:24:16 CEST] <nevcairiel> without system memory round-trips
[13:24:21 CEST] <nevcairiel> why have qsv decoding?
[13:24:31 CEST] <alevinsn> there is no such thing as dxva2 decoding
[13:24:37 CEST] <nevcairiel> of course there is
[13:24:39 CEST] <nevcairiel> i use it e very day
[13:25:23 CEST] <alevinsn> ok, I see that
[13:25:30 CEST] <alevinsn> it doesn't appear to be using QuickSync
[13:25:31 CEST] <alevinsn> though
[13:25:57 CEST] <nevcairiel> no, it uses dxva2, thats the entire point =p
[13:26:11 CEST] <alevinsn> yes, but there is good reason to use QuickSync
[13:26:17 CEST] <nevcairiel> which is?
[13:26:17 CEST] <alevinsn> if the hardware supports it
[13:26:28 CEST] <nevcairiel> dxva2 accesses the same decoder hardware
[13:26:30 CEST] <alevinsn> possibly better quality encoding, more flexibility
[13:26:39 CEST] <nevcairiel> we're talking about decoding
[13:26:45 CEST] <nevcairiel> decoding with dxva2 -> encoding with qsv
[13:26:54 CEST] <alevinsn> there are different knobs that can be controlled
[13:26:56 CEST] <nevcairiel> dxva2 doesnt have encoding support
[13:27:37 CEST] <alevinsn> plus, can use pipelines in theory with QSV
[13:27:44 CEST] <alevinsn> decode then VPP
[13:27:49 CEST] <alevinsn> all in hardware memory
[13:27:55 CEST] <alevinsn> which in theory should be faster
[13:28:14 CEST] <nevcairiel> you can do that with a dxva2 decoder, as we established, qsv just outputs dxva2 surfaces anyway
[13:29:04 CEST] <alevinsn> true, but need to setup the entire session to use QSV if you want to use VPP too in the most efficient way possible
[13:29:27 CEST] <alevinsn> if it is setup properly, could be using VPP on one frame while performing decoding with another
[13:29:37 CEST] <alevinsn> don't think you can get that kind of setup if you use DXVA2
[13:29:44 CEST] <nevcairiel> why not?
[13:29:57 CEST] <BtbN> why wouldn't you? Except for ffmpeg.c not supporting that kind of parallelism.
[13:30:08 CEST] <nevcairiel> sounds pretty normal, decode frame A, process frame B, encode frame C
[13:30:11 CEST] <nevcairiel> sounds perfectly normal
[13:30:42 CEST] <nevcairiel> (for more logical outcome, probably invert the letters :p)
[13:31:07 CEST] <alevinsn> ok, here's a good reason to use qsv--it will work cross-platform, since it will do the right thing for either Windows (DXVA2) or Linux (VAAPI)
[13:31:13 CEST] <alevinsn> qsv for decoding
[13:31:28 CEST] <BtbN> If you want to go through the pains of getting QSV to work on Linux, sure
[13:31:58 CEST] <nevcairiel> thats not really a good argument, ffmpeg could just have a magic switch that does the right thing
[13:32:48 CEST] <nevcairiel> ie. specify -hwaccel qsv and it uses dxva2 on windows and vaapi on linux
[13:32:49 CEST] <nevcairiel> or whatever
[13:32:54 CEST] <jkqxz> alevinsn: Patch looks ok. Commit message is a bit funny. Maybe "hwcontext_dxva2: Don't incorrectly free IDirect3DSurface9 objects", and please write in the present like all other commit messages.
[13:33:34 CEST] <jkqxz> Yeah, I'm intending to replace -hwaccel qsv with "magically do the right thing and then map back to qsv pixfmt".
[13:34:01 CEST] <alevinsn> that's in reference to decoding, right?
[13:34:22 CEST] <jkqxz> Though really you don't want the qsv pixfmt except in the last step, it's just that the VPP stuff exists and equivalent D3D implementation currently doesn't.
[13:34:30 CEST] <jkqxz> Yes, for decoding.
[13:34:48 CEST] <alevinsn> jkqxz: OK, I'll adjust the text to do everything in the present
[13:34:49 CEST] <jkqxz> Getting rid of the QSV decoder entirely is the end goal, though probably legacy people will force it to persist forever.
[13:35:19 CEST] <alevinsn> jkqxz: I would think that there are some knobs that can only be controlled with QSV decoding
[13:35:38 CEST] <jkqxz> Like what? Decoding has one answer, so there isn't anything you can do differently.
[13:35:40 CEST] <nevcairiel> decoding doesnt have many knobs
[13:35:54 CEST] <nevcairiel> you can control performance a bit by messing with the async thing
[13:36:04 CEST] <nevcairiel> but thats not very relevant
[13:36:56 CEST] <jkqxz> The async thing is trivially implementable by the user delaying frames, anyway. It could maybe have an option in lavc so that it can be used with all hardware decoders.
[13:37:07 CEST] <jkqxz> ... in the command line tools.
[13:37:31 CEST] <nevcairiel> .. and if any and every usecase of the qsv decoder can be easily replicated with dxva2+map, we can just deprecate it and remove it after due time
[13:38:16 CEST] <jkqxz> Anyway, the biggest gain of using dxva2/vaapi + hwmap is that it uses the proper decoder, so you don't have to specify the codec in advance and you get proper software fallback and full support of every feature you would expect normally without it having to be separately implemented in the special qsv decoder.
[13:39:17 CEST] <alevinsn> what about HEVC?
[13:39:24 CEST] <alevinsn> there are a bunch of different QSV plugins
[13:39:27 CEST] <alevinsn> for HEVC
[13:39:38 CEST] <nevcairiel> dxva2 implements full hevc decoding on intel
[13:39:44 CEST] <nevcairiel> not sure how well vaapi works
[13:39:52 CEST] <jkqxz> What about it? DXVA2 and VAAPI give you H.265 support directly without having to mess around with plugins.
[13:39:54 CEST] <alevinsn> there are a bunch of different HEVC plug-ins for QSV from Intel
[13:40:04 CEST] <alevinsn> there is reason to use different plugins
[13:40:09 CEST] <alevinsn> there is the Skylake HW plugin
[13:40:19 CEST] <alevinsn> but there are also hybrid software/hardware plugins
[13:40:30 CEST] <alevinsn> that are availablbe as part of the Intel Media Server Studio
[13:40:33 CEST] <BtbN> why would you use the worse ones?
[13:40:37 CEST] <alevinsn> that apparently result in better quality
[13:40:42 CEST] <alevinsn> than the HW plugin
[13:40:45 CEST] <BtbN> it's a decoder.
[13:40:52 CEST] <alevinsn> may not matter for the decoder
[13:40:54 CEST] <jkqxz> "better quality" is not a thing for a decoder. There is one right answer. If you don't get that, it's wrong.
[13:40:55 CEST] <alevinsn> not sure
[13:43:16 CEST] <jkqxz> (Certainly it makes sense to support the different encode plugins, but there is no intent here to change anything about the encoder.)
[13:44:28 CEST] <nevcairiel> dxva2 at least supports the hybrid decoding
[13:44:33 CEST] <nevcairiel> not sure about vaapi, probably not
[13:44:38 CEST] <alevinsn> to me, it seems a little bit odd to use one path for decoding and another for encoding--are you wanting qsvdec.c and related qsv files to disappear?
[13:44:48 CEST] <nevcairiel> (hybrid is only used when no full hw support is available)
[13:45:36 CEST] <alevinsn> nevcairiel: not true (for encoding)--there is reason to use hybrid for HEVC even if hardware support available because the HEVC hardware encoder in Skylake isn't very good
[13:45:49 CEST] <alevinsn> at least, that's what the person from Intel told me
[13:46:04 CEST] <nevcairiel> we've been only talking about decoding here
[13:46:18 CEST] <nevcairiel> encoding remains with qsvenc at all times anyway
[13:46:26 CEST] <jkqxz> Media SDK VAAPI doesn't have hybrid, there is a separate project for the free stuff which kindof works.
[13:47:31 CEST] <BtbN> the hybrid stuff is terrible anyway
[13:47:32 CEST] <jkqxz> alevinsn: Yes, I would like to delete qsvdec.c. Most of the other qsv stuff in lavc stays because it is used by the encoder.
[13:47:37 CEST] <cone-630> ffmpeg 03Rostislav Pehlivanov 07master:3fefaeaa0b85: img2dec: use standard way to probe for svg/svgz files
[13:48:43 CEST] <alevinsn> so, if programmatically setting up decoding and want to use QSV for decoding
[13:48:46 CEST] <alevinsn> how would you do that?
[13:49:56 CEST] <alevinsn> assuming qsvdec.c were removed
[13:50:06 CEST] <jkqxz> Use DXVA2 or VAAPI and point it at your Intel device.
[13:50:32 CEST] <alevinsn> then you don't have a cross-platform solution anymore
[13:51:08 CEST] <jkqxz> You need to specify the QSV device anyway in different ways on the two platforms, and after that the only difference is the pixfmt.
[13:51:39 CEST] <alevinsn> won't "auto" do the right thing regardless of the platform?
[13:52:52 CEST] <jkqxz> Not if you have a non-Intel graphics device as well.
[13:53:40 CEST] <alevinsn> are you talking about the third argument to av_hwdevice_ctx_create()?
[13:53:59 CEST] <alevinsn> the value of which is different depending on DXVA2 or VAAPI?
[13:54:11 CEST] <alevinsn> for the child device in hwcontext_qsv.c
[13:54:38 CEST] <jkqxz> In this setup you use device derivation to make the QSV device, so that never gets run.
[13:55:42 CEST] <alevinsn> ok, not exactly following, but that's okay
[13:56:13 CEST] <jkqxz> You start by making the VAAPI / DVXA2 device. (See command line examples in <https://lists.libav.org/pipermail/libav-devel/2017-April/083488.html> or <https://lists.libav.org/pipermail/libav-devel/2017-April/083487.html>.)
[13:56:27 CEST] <alevinsn> regarding the commit message, I'm not sure how to make some of the things make sense if stated in the present
[13:56:55 CEST] <BBB> atomnuker: any reason why? I have no opinion on the patch basically
[13:57:39 CEST] <jkqxz> I mean the changes you make should be happening in the present.
[13:58:22 CEST] <alevinsn> "Add dxva2_pool_release_dummy() and use it in call to av_buffer_create() in dxva2_pool_alloc()."
[13:58:32 CEST] <jkqxz> Yes, precisely.
[13:58:36 CEST] <alevinsn> It sounds odd to me, but I think that's what you are looking for, right?
[13:58:48 CEST] <alevinsn> because it hasn't happened yet (in a sense)
[13:59:04 CEST] <alevinsn> the rest of the text referred to what currently exists--was that written in the right tense?
[13:59:12 CEST] <jkqxz> Yes, that's fine.
[13:59:21 CEST] <alevinsn> ok, I think I have it, I'll resubmit
[13:59:26 CEST] <jkqxz> You don't need to repeat the subject line inside the patch, either.
[14:00:15 CEST] <atomnuker> BBB: I too dislike seeing .loops in perf printouts
[14:00:15 CEST] <jkqxz> So subject "hwcontext_dxva2: Don't incorrectly free IDirect3DSurface9 objects", commit message "Add dxva2_pool_release_dummy() and use it in call to av_buffer_create() in dxva2_pool_alloc().\n\n[Explanation for why that is the right thing to do]".
[14:00:23 CEST] <alevinsn> I usually try to flesh out the subject line in a little more detail, although in this case, I didn't really do that
[14:00:55 CEST] <BBB> atomnuker: aha, I see& ok, understood
[14:05:29 CEST] <alevinsn> jkqxz: ok, new version that is hopefully the last version just sent
[14:05:58 CEST] <alevinsn> nevcairiel: and it has not just one, but two new lines separating the text :-)
[14:12:12 CEST] <jkqxz> alevinsn: LGTM. I can push it later today when I'm next to a machine with keys, assuming nevcairiel doesn't want to say anything else.
[14:12:50 CEST] <alevinsn> thanks, and good night, going to get a few hours of sleep and then back at it....
[14:17:35 CEST] <jkqxz> You're in UTC-7? Good morning :P
[14:52:14 CEST] <saulotoledo> Hello all :D I need some help with MPEG2 Transport Stream. Is there somebody here that can help me? I want to understand how the TS works, and I do not know where I can get some help about. I do not understand how the descriptors are transferred inside the PMT table. Can somebody help me? If this is off-topic, please send me a PM. Thanks in advance.
[16:26:48 CEST] <cone-630> ffmpeg 03Matt Wolenetz 07release/3.1:0abc88f0fdb8: lavf/mov.c: Avoid OOB in mov_read_udta_string()
[16:26:49 CEST] <cone-630> ffmpeg 03Matt Wolenetz 07release/3.1:5cd2fcd0a723: lavf/mov.c: Avoid heap allocation wraps in mov_read_{senc,saiz}()
[16:26:50 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:3364c8c53a4b: avformat/http: Check for truncated buffers in http_connect()
[16:26:51 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a6b5e670f49e: avcodec/wavpacl: Fix runtime error: left shift of negative value -1
[16:26:52 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:eb322e44eaa2: avcodec/mpeg12dec: Fix runtime error: left shift of negative value
[16:26:53 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:654942045137: avcodec/pngdec: Check bit depth for validity
[16:26:54 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ad2f9874b5cc: avcodec/srtdec: Fix signed integer overflow: 1811992524 * 384 cannot be represented in type 'int'
[16:26:55 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:5fcb98f34f5a: avcodec/pictordec: Do not read more than nb_planes
[16:26:56 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:aa5e396d42f9: avcodec/rv34: Simplify and factor get_slice_offset() code
[16:26:57 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:751f3f4f5ab1: avcodec/mpegaudiodec_template: Correct return code on id3 tag discarding
[16:26:58 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:c0b9d223902a: avcodec/vp56: Fix sign typo
[16:26:59 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:eee75451e117: avcodec/pngdec: Fix runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
[16:27:00 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:fccbd911fb09: avcodec/amrwbdec: Fix 2 runtime errors: left shift of negative value -1
[16:27:01 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:eca3cfe9c4bd: avcodec/vp56: Implement very basic error concealment
[16:27:02 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b541a79c99b8: avcodec/vp56: Clear dimensions in case of failure in the middle of a resolution change
[16:27:03 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:38c7a1ef5cb0: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -1
[16:27:04 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:2015c109ac93: Add CHECK/SUINT code
[16:27:05 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:aff4b91b8df0: avcodec/vp3dsp: Fix multiple signed integer overflow: 46341 * 47523 cannot be represented in type 'int'
[16:27:06 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0db93a9d403d: avcodec/vp56: Factorize vp56_render_mb() out
[16:27:07 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e587594741c8: avcodec/vp8: Check for bitsteam end in decode_mb_row_no_filter()
[16:27:08 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a7e924324e7c: avcodec/vp3: Do not return random positive values but the buf size
[16:27:09 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:17444379696d: avcodec/vp56: Require a correctly decoded frame before using vp56_conceal_mb()
[16:27:10 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b6cbbd22739c: avcodec/vp8: remove redundant check
[16:27:11 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:7ba15a631501: avcodec/vp568: Check that there is enough data for ff_vp56_init_range_decoder()
[16:27:12 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e365921419e1: avcodec/vp8: Check for the bitstream end per MB in decode_mb_row_no_filter()
[16:27:13 CEST] <cone-630> ffmpeg 03Thomas Guilbert 07release/3.1:4c66ead5b7a8: avcodec/vp8: Fix hang with slice threads
[16:27:14 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b8814515c63f: avcodec/vp56: Reset have_undamaged_frame on resolution changes
[16:27:15 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8c36b7ab360d: avcodec/vp6: clear dimensions on failed resolution change in vp6_parse_header()
[16:27:16 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:77ffc7596cb7: avcodec/htmlsubtitles: Fix reading one byte beyond the array
[16:27:17 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e82cddfd05ac: avcodec/eac3dec: Fix runtime error: left shift of negative value
[16:27:18 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f03df423ab02: avcodec/mjpegdec: Fix runtime error: left shift of negative value -507
[16:27:19 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:535c1411d746: avcodec/mpeg4videodec: Fix runtime error: shift exponent -2 is negative
[16:27:20 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:11c2a96c2306: avcodec/h264_cabac: runtime error: signed integer overflow: 2147483647 + 14 cannot be represented in type 'int'
[16:27:21 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d837140eb4e0: avcodec/rv40: Fix runtime error: left shift of negative value
[16:27:22 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f0f4b66dff89: avcodec/ituh263dec: Fix runtime error: left shift of negative value -22
[16:27:23 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cae07dd27fc6: avcodec/mpeg4video: Fix runtime error: left shift of negative value
[16:27:24 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0df55b0ffc2e: avcodec/mpeg4videodec: Check sprite_offset in addition to shifts
[16:27:25 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:72d01d4c14f7: avcodec/mpeg4videodec: Check the other 3 sprite points for intermediate overflows
[16:27:26 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b8883af656eb: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -2
[16:27:27 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:fc5b7e109217: avcodec/eac3dec: Fix runtime error: left shift of negative value -3
[16:27:28 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0456e2f3e050: avcodec/mpeg4videodec: Fix runtime error: left shift of negative value -2650
[16:27:29 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a0366ef7e74f: avcodec/pictordec: Check plane value before doing value/mask computations
[16:27:30 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a72b17ca403d: avcodec/h264_direct: Fix runtime error: left shift of negative value -14
[16:27:31 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cd09ad190f03: avcodec/mjpegdec: Fix runtime error: left shift of negative value -511
[16:27:32 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e34feaf93e9f: avcodec/mpeg4videodec: Improve the overflow checks in mpeg4_decode_sprite_trajectory()
[16:27:33 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b69f97933126: avcodec/adxdec: Fix runtime error: left shift of negative value -1
[16:27:34 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:67d84d2c48a6: avcodec/h264_mvpred: Fix multiple runtime error: left shift of negative value
[16:27:35 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ce54743d8280: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -13
[16:27:36 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:49697df49c72: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 134527392 * 16 cannot be represented in type 'int'
[16:27:37 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e92e587ceeb0: avcodec/wavpack: Fix runtime error: left shift of negative value -2
[16:27:38 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9beb60855beb: avcodec/wavpack: Fix runtime error: left shift of negative value -5
[16:27:39 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:90c408fa65f3: avcodec/mjpegdec: Fix runtime error: left shift of negative value -127
[16:27:40 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f487f9bfdfa7: avcodec/h264_mvpred: Fix runtime error: left shift of negative value -1
[16:27:41 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d9e54c335d56: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: -135088512 * 16 cannot be represented in type 'int'
[16:27:42 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:92d6b2b9342d: avcodec/amrwbdec: Fix runtime error: left shift of negative value -1
[16:27:43 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:025dc25ecbf1: avcodec/rv34: Fix runtime error: signed integer overflow: 36880 * 66288 cannot be represented in type 'int'
[16:27:44 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:bafec54a9328: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int'
[16:27:45 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:139a5390623b: avcodec/tiff: Check for multiple geo key directories
[16:27:46 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f4b8e7f2c692: avcodec/mpegaudiodec_template: Make l3_unscale() work with e=0
[16:27:47 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:91f821ed5d55: avcodec/tiff: Check stripsize strippos for overflow
[16:27:48 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:184d957b5401: avcodec/vp56: Check avctx->error_concealment before enabling EC
[16:27:49 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8fc7fd63f21f: avcodec/tiff: Check geotag count for being non zero
[16:27:50 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:840d5bf994d9: avcodec/h264_ps: Fix runtime error: signed integer overflow: 2147483647 + 26 cannot be represented in type 'int'
[16:27:51 CEST] <cone-630> ffmpeg 03Philip Langdale 07release/3.1:987675ba0d94: avcodec/vdpau_hevc: Fix potential out-of-bounds write
[16:27:52 CEST] <cone-630> ffmpeg 03Timothy Gu 07release/3.1:6522a5dcf09f: omx: Fix OOM check
[16:27:53 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d4aea81f2cce: avcodec/tiff: Perform multiply in tiff_unpack_lzma() as 64bit
[16:27:54 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8c54c2934371: avfilter/avfiltergraph: Add assert to write down in machine readable form what is assumed about sample rates in swap_samplerates_on_filter()
[16:27:55 CEST] <cone-630> ffmpeg 03wm4 07release/3.1:2f8356df12af: avcodec: fix uninitialized variable read
[16:27:56 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e80a525934ab: avfilter/af_sofalizer: Fix bad shift
[16:27:57 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:dc4fc2520072: avformat/oggparsedaala: Check duration for AV_NOPTS_VALUE
[16:27:58 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0a966b056fd6: avformat/oggparsedaala: Do not leave an invalid value in gpshift
[16:27:59 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:da25519aff84: avcodec/dvdsubdec: Fixes 2 runtime error: left shift of 170 by 24 places cannot be represented in type 'int'
[16:28:00 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:500212310944: avformat/oggparseogm: Check available data before reading global header
[16:28:01 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a46e0879b9ac: avformat/oggparseogm: Check ff_alloc_extradata() for failure
[16:28:02 CEST] <cone-630> ffmpeg 03Derek Buitenhuis 07release/3.1:a1d740ff098e: avformat/webmdashenc: Require the 'adaptation_sets' option to be set
[16:28:03 CEST] <cone-630> ffmpeg 03Derek Buitenhuis 07release/3.1:82e5f2c76b6f: avformat/webmdashenc: Validate the 'streams' adaptation sets parameter
[16:28:04 CEST] <cone-630> ffmpeg 03Martin Vignali 07release/3.1:b391e4c8f4fe: libavcodec/exr : fix float to uint16 conversion for negative float value
[16:28:05 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:52d07518a32d: avcodec/x86/vc1dsp_init: Fix build failure with --disable-optimizations and clang
[16:28:06 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:388ef988f8ff: avcodec/mdec: Fix runtime error: left shift of negative value -127
[16:28:07 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f3d300497fc7: doc/developer: Add terse documentation of assumed C implementation defined behavior
[16:28:08 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:2b733acce9e0: avcodec/vp3: Check remaining bits in unpack_dct_coeffs()
[16:28:09 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:132796f1d15f: avcodec/indeo2: Check remaining bits in ir2_decode_plane()
[16:28:10 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:44fd56337616: avcodec/svq3: Increase offsets to prevent integer overflows
[16:28:11 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:2cfd230759e7: avcodec/svq3: Reject dx/dy beyond 16bit
[16:28:12 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cfc85cead9e9: avcodec/dcadsp: Fix runtime error: signed integer overflow
[16:28:13 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:6798f9c551b4: avcodec/h264_cavlc: Fix undefined behavior on qscale overflow
[16:28:14 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d4f008557ae7: avcodec/msvideo1: Check buffer size before re-getting the frame
[16:28:15 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:55d8fd38d66e: avcodec/pngdec: Use ff_set_dimensions()
[16:28:16 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cbc471d1b323: libavcodec/mpeg4videodec: Convert sprite_offset to 64bit
[16:28:17 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cc9b7db429f1: avcodec/dvdsubdec: Fix runtime error: left shift of 242 by 24 places cannot be represented in type 'int'
[16:28:18 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a6fb07d5ba3a: avcodec/cavsdec: Fix undefined behavior from integer overflow
[16:28:19 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ac74ac9e1d2f: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'
[16:28:20 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:67561969947e: avcodec/tiertexseqv: set the fixed dimenasions, do not depend on the demuxer doing so
[16:28:21 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0eb229a427cd: avcodec/wnv1: Fix runtime error: left shift of negative value -1
[16:28:22 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ba0081fbbe9c: avcodec/dss_sp: Fix multiple left shift of negative value -466
[16:28:23 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:45470150971a: avcodec/g722: Fix multiple runtime error: left shift of negative value -1
[16:28:24 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:dd907bec361e: avcodec/cdxl: Fix signed integer overflow: 14243456 * 164 cannot be represented in type 'int'
[16:28:25 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e01f02894931: avcodec/nellymoser: Fix multiple left shift of negative value -8591
[16:28:26 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:eb234fa89b94: avcodec/dfa: Fix off by 1 error
[16:28:27 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:092449179955: avcodec/mdec: Fix signed integer overflow: 28835400 * 83 cannot be represented in type 'int'
[16:28:28 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:fb4a81dc3aa3: avcodec/aacsbr_template: Do not leave bs_num_env invalid
[16:28:29 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1fe0de8934cd: avutil/softfloat: Fix multiple runtime error: left shift of negative value -8
[16:28:30 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e7755214bbf9: avcodec/snowdec: Check qbias
[16:28:31 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:23a76f1057bd: avcodec/mlpdec: Fix runtime error: left shift of negative value -22
[16:28:32 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ceb456e3e9e9: avcodec/fic: Fix multiple left shift of negative value -15
[16:28:33 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9f7bc8296bdd: avcodec/mimic: Fix runtime error: left shift of negative value -1
[16:28:34 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:677c9f27cc60: avcodec/g723_1: Fix multiple runtime error: left shift of negative value
[16:28:35 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:2c7e4e5e7176: avcodec/dfa: Fix signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
[16:28:36 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:5578f63494aa: avcodec/webp: Fix null pointer dereference
[16:28:37 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:22de9c949aba: avcodec/shorten: Check k in get_uint()
[16:28:38 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:cbd8be63cf34: avcodec/mss3: Change types in rac_get_model_sym() to match the types they are initialized from
[16:28:39 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:78b47e922961: avcodec/hq_hqa: Fix runtime error: left shift of negative value -207
[16:28:40 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:54eaa109ed8b: avutil/softfloat: Fix overflow in av_div_sf()
[16:28:41 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:94029d7e179e: avcodec/cdxl: Check format parameter
[16:28:42 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:47e2c70dcdbe: avcodec/dds: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[16:28:43 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8464f2508925: avcodec/msmpeg4dec: Correct table depth
[16:28:44 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ef40a32dbb0e: avcodec/svq3: Fix multiple runtime error: signed integer overflow: 44161 * 61694 cannot be represented in type 'int'
[16:28:45 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d9faa9bd6366: avcodec/ivi_dsp: Fix multiple left shift of negative value -2
[16:28:46 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b892a0b1c078: avcodec/texturedsp: Fix multiple runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[16:28:47 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:23853514e5af: avcodec/targa_y216dec: Fix width type
[16:28:48 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:a11e5577a253: avcodec/mss34dsp: Fix multiple signed integer overflow
[16:28:49 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b0f57bd32697: avcodec/ra144: Fix runtime error: left shift of negative value -798
[16:28:50 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:93f9d9dc6c3d: avcodec/g726: Fix runtime error: left shift of negative value -2
[16:28:51 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:aab7b9e6bcf9: avcodec/eamad: Fix runtime error: signed integer overflow: 49674 * 49858 cannot be represented in type 'int'
[16:28:52 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:71a568e47d04: avcodec/s302m: Fix left shift of 8 by 28 places cannot be represented in type 'int'
[16:28:53 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e2103ad36d45: avcodec/xwddec: Check bpp more completely
[16:28:54 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:be531b476236: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -12156865 cannot be represented in type 'int'
[16:28:55 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:782473f9dfca: avcodec/ffv1dec: Fix copying planes of paletted formats
[16:28:56 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:4f98b97b2ad1: avcodec/cdxl: Check format for BGR24
[16:28:57 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:7e5ece105227: avcodec/cavsdec: Check sym_factor
[16:28:58 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:45763713e81a: avcodec/hqxdsp: Fix multiple runtime error: signed integer overflow: 248220 * 21407 cannot be represented in type 'int' in idct_col()
[16:28:59 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:34a7677f296e: avcodec/vp8dsp: Fixes: runtime error: signed integer overflow: 1330143360 - -1023040530 cannot be represented in type 'int'
[16:29:00 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e3368b7f8217: avcodec/dvbsubdec: check region dimensions
[16:29:01 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d766376f4b53: avcodec/dss_sp: Fix multiple runtime error: signed integer overflow: -15699 * -164039 cannot be represented in type 'int'
[16:29:02 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ddef5acc3156: avcodec/bmvvideo: Fix runtime error: left shift of 137 by 24 places cannot be represented in type 'int'
[16:29:03 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d48a152b7cd8: avcodec/htmlsubtitles: Check for string truncation and return error
[16:29:04 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e82d6dafdef6: avcodec/g723_1dec: Fix several integer related cases of undefined behaviour
[16:29:05 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:99341b2a7fd1: avcodec/indeo2: Check for invalid VLCs
[16:29:06 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1e52bd434498: avcodec/takdec: Fix multiple runtime error: left shift of negative value -1
[16:29:07 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1ddb2441d6bf: avcodec/lagarith: Fix runtime error: left shift of negative value -1
[16:29:08 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9b14178421c7: avcodec/lagarith: Check scale_factor
[16:29:09 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:22f9831d0db1: avcodec/texturedsp: Fix runtime error: left shift of 218 by 24 places cannot be represented in type 'int'
[16:29:10 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9bc7868bc916: avcodec/svq3: Fix multiple runtime error: signed integer overflow: -237341 * 24552 cannot be represented in type 'int'
[16:29:11 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:24d048f3e6bf: avcodec/y41pdec: Fix width in input buffer size check
[16:29:12 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:4170c380247f: avcodec/cavs: Check updated MV
[16:29:13 CEST] <cone-630> ffmpeg 03N^ 07release/3.1:9f3267def692: avformat/wavdec: Check chunk_size
[16:29:14 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:159e5ba8d79a: avcodec/dss_sp: Fix runtime error: signed integer overflow: 2147481189 + 4096 cannot be represented in type 'int'
[16:29:15 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e4def6e0b608: avcodec/eatqi: Fix runtime error: signed integer overflow: 4466147 * 1075 cannot be represented in type 'int'
[16:29:16 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:41392c52499a: avcodec/truemotion1: Fix multiple runtime error: left shift of negative value -1
[16:29:17 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:8ec17629d72d: avfilter/vf_uspp: Fix currently unused input frame dimensions
[16:29:18 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:21b1dd8f74c9: avcodec/webp: Always set pix_fmt
[16:29:19 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:7edd1cd6fa9f: avcodec/mpeg12dec: Fixes runtime error: division by zero
[16:29:20 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:79c489952a8c: avcodec/aacdec_fixed: Fix multiple shift exponent 33 is too large for 32-bit type 'int'
[16:29:21 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e9b0d127b0da: avcodec/dvbsubdec: Check entry_id
[16:29:22 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:becd83e164db: avcodec/cllc: Factor VLC_BITS/DEPTH out, do not use repeated literal numbers
[16:29:23 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:5e23b4a8396e: avcodec/cllc: Check num_bits
[16:29:24 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1147b109b7e0: avcodec/msmpeg4dec: Check for cbpy VLC errors
[16:29:25 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:4476107e3acb: avcodec/diracdec: Fix Assertion frame->buf[0] failed at libavcodec/decode.c:610
[16:29:26 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:9f0f354a97bf: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -17047030 cannot be represented in type 'int'
[16:29:27 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:bf7bcd803a5c: avcodec/g723_1dec: Fix runtime error: left shift of negative value -1
[16:29:28 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f224214ae24f: avcodec/texturedsp: Fix runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[16:29:29 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d5c3132d6fbd: avcodec/avcodec: Limit the number of side data elements per packet
[16:29:30 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e85a3a1d3e3d: avcodec/vp8dsp: vp7_luma_dc_wht_c: Fix multiple runtime error: signed integer overflow: -1366381240 + -1262413604 cannot be represented in type 'int'
[16:29:31 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:f450115354ef: avcodec/mlp: Fix multiple runtime error: left shift of negative value -1
[16:29:32 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:84e272d4e23f: avcodec/aacsbr_template: Do not change bs_num_env before its checked
[16:29:33 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b6c8e4733330: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1
[16:29:34 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e5abfbf2abc1: avcodec/webp: Add missing input padding
[16:29:35 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b18a2cbdbf27: avcodec/ac3dec: Keep track of band structure
[16:29:36 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:536e29d4cf91: avcodec/mlpdec: Check that there is enough data for headers
[16:29:37 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d792783f5632: avcodec/svq3: Fix runtime error: signed integer overflow: 169 * 12717677 cannot be represented in type 'int'
[16:29:38 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:6d2a00d0f113: avcodec/webp: Fix signedness in prefix_code check
[16:29:39 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:536275b673c0: avcodec/ffv1dec: Fix runtime error: signed integer overflow: 1550964438 + 1550964438 cannot be represented in type 'int'
[16:29:40 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d5ac8a296a01: libswscale/tests/swscale: Fix uninitialized variables
[16:29:41 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:993671b570f3: avcodec/g723_1dec: Fix LCG type
[16:29:42 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:d8082e5e6cdf: avcodec/hqxdsp: Fix runtime error: signed integer overflow: -196264 * 11585 cannot be represented in type 'int'
[16:29:43 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:c1aa23caae2c: avcodec/ac3dec: Fix: runtime error: index -1 out of bounds for type 'INTFLOAT [2]'
[16:29:44 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0d3efe30b5ff: avcodec/mpeg4videodec: Clear sprite wraping on unsupported cases in VOP decode
[16:29:45 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:e964d47439d5: avcodec/dds: Fix runtime error: left shift of 210 by 24 places cannot be represented in type 'int'
[16:29:46 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:528fb0b27d70: avcodec/rscc: Check pixel_size for overflow
[16:29:47 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1cdc9447f423: avcodec/cllc: Check prefix
[16:29:48 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:6f4e69d661e0: avcodec/webp: Factor update_canvas_size() out
[16:29:49 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:4e5543571a10: avcodec/webp: Update canvas size in vp8_lossy_decode_frame() as in vp8_lossless_decode_frame()
[16:29:50 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:1e5d151417a6: avcodec/snowdec: Check width
[16:29:51 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:6fa860449f36: avcodec/flacdec: Return error code instead of 0 for failures
[16:29:52 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:70cda595c3f3: avcodec/opus_silk: Fix integer overflow and out of array read
[16:29:53 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:0159afe0c2f1: avcodec/aacps: Fix undefined behavior
[16:29:54 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:b25aca2af8e4: avcodec/tiff: reset sampling[] if its invalid
[16:29:55 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:ab22fca14b38: avcodec/svq3: Fix runtime error: left shift of negative value -6
[16:29:56 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07release/3.1:54918674f7cb: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int'
[16:36:18 CEST] <atomnuker> rcombs: are you going to push your flac patches?
[16:52:41 CEST] <wm4> so do we want to apply this libturing patch or not?
[16:55:24 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:7f2eeb2c7478: avformat/concatdec: fix the h264 annexb extradata check
[16:55:25 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:d2c6bcdbf181: avcodec/options: factorize avcodec_copy_context() cleanup code
[16:55:26 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:1564125e4eb1: avcodec/options: do a more thorough clean up in avcodec_copy_context()
[16:55:27 CEST] <cone-630> ffmpeg 03Aaron Levinson 07release/3.1:9ebbb29ad61d: avformat/utils: free AVStream.codec properly in free_stream()
[16:55:28 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:75f9fe1519de: avcodec/aac_adtstoasc: fix ASC passthrough on small frames
[16:56:58 CEST] <jamrial> wm4: not as is, unless they can prove it's better than libx265. the order in allcodecs.c as it is in the latest patch would make it the default encoder
[16:57:49 CEST] <wm4> hm does that even matter, since you have to explicitly enable those anyway
[16:59:11 CEST] <cone-630> ffmpeg 03James Almer 07release/3.2:d4241affd8e8: avcodec/aac_adtstoasc: fix ASC passthrough on small frames
[16:59:37 CEST] <jamrial> it does, there's a section in that file for external libraries that have less priority than others
[17:02:26 CEST] <J_Darnley> BBB: in the simple_idct C function, in the idctRowCondDC inline function, there is some stange code which I think checks for zeros. Is this some early termination for DC-only coeffs?
[17:03:05 CEST] <BBB> let me have a look
[17:04:00 CEST] <BBB> oh that
[17:04:05 CEST] <BBB> sort of
[17:04:13 CEST] <BBB> so, the dc only case is a very special one
[17:04:16 CEST] <BBB> this is a more generic one
[17:05:20 CEST] <BBB> but this basically checks that within the 1d of this lane only, all non-first coefs are zero, yes
[17:05:50 CEST] <J_Darnley> Ah, I guess DC-only is not strictly correct.
[17:05:52 CEST] <BBB> similarly, if (AV_RN64A(row + 4)) { checks whether the second half of the coefs have any non-zeroes
[17:06:00 CEST] <BBB> DC is the first coef of the first lane
[17:06:04 CEST] <J_Darnley> DC would be the top-left coeff only
[17:06:05 CEST] <BBB> but it does it for every lane
[17:06:08 CEST] <BBB> right
[17:06:09 CEST] <BBB> exactly
[17:06:35 CEST] <J_Darnley> thank you
[17:08:55 CEST] <BBB> its similar to the sub-idct mechanism in vp9s x86 simd code, except thats at 2d level and this is at 1d level
[17:13:15 CEST] <wm4> jamrial: then someone should post that
[17:13:56 CEST] <jkqxz> The problem with the libturing patch is that no developers are interested so noone wants any responsibility for it (I mean, it looks like an internal project wall-throw with no external use or involvement at all).
[17:14:30 CEST] <jkqxz> The lack of proper API also doesn't help, because it encourages comments which don't actually make any forward progress.
[17:15:58 CEST] <wm4> well, with all that patch review, there's somewhat of an implicit promise that we'd merge it
[17:34:09 CEST] <jkqxz> Yeah, it should probably just be merged.
[17:35:32 CEST] <jkqxz> (If it hangs there I'm sure people can come up with objections indefinitely.)
[17:36:00 CEST] <nevcairiel> if its setup in such a way that its never the default or preferred over x265, then merging it probably doesnt hurt anyone
[17:36:43 CEST] <jkqxz> It's sufficiently hard to build that I doubt anyone would be confused anyway.
[17:37:25 CEST] <jkqxz> Well, maybe "enable all the things" people will get it.
[17:48:36 CEST] <jamrial> jkqxz: exactly, builds like zeranoe's or some linux distros that ship a single binary with all the deps hardcoded must not find themselves with the hevc encoder default changed
[18:05:32 CEST] <jkqxz> At least if Linux distributions pick it up then they probably have to fix the internal boost library stuff to work properly.
[18:05:53 CEST] <jkqxz> But yes, that does need to be fixed.
[18:06:06 CEST] <nevcairiel> whoever pushes could just reorder the registration
[18:06:10 CEST] <jkqxz> Does anything else? Has anyone else even run the thing?
[18:06:48 CEST] <jkqxz> Yeah, avoiding another round trip just for that would be sensible.
[19:12:02 CEST] <cone-630> ffmpeg 03James Almer 07release/3.2:e958bfac8b9f: avcodec/hevc_sei: fix amount of bits skipped when reading picture timing SEI message
[19:18:13 CEST] <cone-630> ffmpeg 03Paul B Mahol 07master:5605108f4dca: avfilter/af_bs2b: add missing flag for options
[19:25:13 CEST] <alevinsn> No, I'm UTC-8.00
[19:25:30 CEST] <alevinsn> 8:00
[19:25:42 CEST] <alevinsn> It was 0500 when I went to sleep
[19:25:57 CEST] <alevinsn> nevcairiel: I thought some how to do the d3d9.h check
[19:26:14 CEST] <alevinsn> seems like the easiest thing is try to build some simple code that tries to use that interface method
[19:29:11 CEST] <wm4> that's how it's normally done
[19:34:02 CEST] <nevcairiel> we have checks for similar things already, iirc
[19:34:35 CEST] <PeterStream> Salutations all.
[19:35:29 CEST] <PeterStream> Does anyone know if there is a job board for ffmpeg-developers ( source developers ).
[19:36:23 CEST] <PeterStream> I'm looking to hire a consultant at the senior/architect level for a well funded/known company in the streaming industry.
[19:37:10 CEST] <alevinsn> nevcairiel: were you wanting to add that check to configure (and also make the appropriate changes to anywhere it is needed in the code base)?
[19:37:20 CEST] <alevinsn> you personally, I mean
[19:39:02 CEST] <alevinsn> because if not, I'm familiar enough with it that I can do it I think
[19:40:20 CEST] <alevinsn> PeterStream: I'm not aware of such a job board, but the FFmpeg Web site has a list of individuals at http://ffmpeg.org/consulting.html that you might find useful
[19:41:45 CEST] <PeterStream> alevinsn thank you! I will take a look.
[19:42:09 CEST] <PeterStream> It's a pretty cool gig and just looking for help with the nuances of ffmpeg.
[19:45:55 CEST] <cone-630> ffmpeg 03James Almer 07master:605c5ca3123a: avcodec/allcodecs: move librsvg_decoder to the external library section
[20:26:25 CEST] <thebombzen> what is "lgtm" mean
[20:27:45 CEST] <Gramner> "looks good to me"
[20:55:28 CEST] <tdjones> If I am to adapt the vorbis encoder to use the af buffer queue, is it necessary to store all frames within the primary encoder context? I'm not quite understanding how the 64-sample frames would be concatenated into one of the two frame sizes encoded in the file header
[20:56:22 CEST] <tdjones> Looking at the opus encoder doesn't quite fit since Vorbis only allows 1 frame per audio packet in the stream.
[20:56:59 CEST] <atomnuker> tdjones: ff_bufqueue_add(avctx, &s->bufqueue, av_frame_clone(frame));, that's all you need to do
[20:57:27 CEST] <atomnuker> then the frame is in the context's buffer queue and you can use it
[20:58:01 CEST] <atomnuker> (after you're finished with it you call av_frame_free() to free the frame
[21:00:22 CEST] <atomnuker> you can actually just copy opus_encode_frame() and use that as the main encoding function
[21:00:30 CEST] <atomnuker> just always assume you'll only have 1 packet
[21:00:51 CEST] <atomnuker> I mean 1 frame per packet
[21:02:17 CEST] <atomnuker> the simplest way to start would be to just make the encoder output the smallest frame size allowed since you'd need no buffer queue
[21:12:48 CEST] <tdjones> atomnuker: Thanks, I'll give that a try
[22:36:20 CEST] <J_Darnley> jamrial: regarding the pgp signed mails. I see what you were talking about. I seem unable to verify my own mail sent to the list recieved by another address.
[22:47:57 CEST] <cone-630> ffmpeg 03Aaron Levinson 07master:0c1c514643d5: avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
[22:49:14 CEST] <jkqxz> I'm still wtf at that bug not being world-breaking memory corruption, but apparently noone noticed for a year. Oh well.
[22:51:47 CEST] <J_Darnley> Nobody uses it?
[22:53:14 CEST] <alevinsn> perhaps should be backported to production?
[22:53:15 CEST] <alevinsn> 3.1?
[22:53:51 CEST] <jkqxz> Everyone using qsv on Windows, and the players would use it too in many cases (mpv at least). Not a small sample.
[22:54:05 CEST] <alevinsn> well, only if hw frame context used
[22:54:13 CEST] <alevinsn> if software memory used, not relevant
[22:54:40 CEST] <alevinsn> I'm not sure if there is a way to cause qsv encoding to use hw frame context via ffmpeg
[22:55:24 CEST] <jkqxz> ? Feed it any hardware frames on input. (Either from hwaccel on a decoder or from hwupload.)
[22:55:24 CEST] <alevinsn> I only encountered this because I wrote code to do that using the shared libraries
[22:56:03 CEST] <jkqxz> Um, yeah. That should probabaly be backported to release branches.
[22:56:14 CEST] <alevinsn> if software memory is used for, the hw frame context object (the one declared in hwcontext_qsv.c) is not created, and it won't be used in that case
[22:56:43 CEST] <alevinsn> but, maybe relevant for the hw frame context created by qsv.c? not sure
[22:57:25 CEST] <alevinsn> the reason it might not have impacted things
[22:57:31 CEST] <jkqxz> hwupload and hwmap can also make new hw frames contexts in your filter chain.
[22:57:42 CEST] <alevinsn> is that, if any memory corruption occurs, it happens at cleanup, when the process is likely exiting anyway
[22:58:25 CEST] <alevinsn> and, release version of _aligned_free may not overwrite memory
[22:58:35 CEST] <jkqxz> mpv not dying is the more surprising case to me, since that definitely does reinitialise things in the same process repeatedly.
[22:59:01 CEST] <alevinsn> may be smart enough to realize those weren't allocated from the heap and it does nothing?
[22:59:19 CEST] <alevinsn> I find that hard to believe, but it might be possible
[22:59:35 CEST] <alevinsn> I imagine that libav will want this one
[22:59:48 CEST] <jkqxz> Yeah. Do you want to send it there?
[23:00:45 CEST] <alevinsn> I guess they don't have a merge process setup
[23:01:54 CEST] <alevinsn> I got lucky in finding it--if I hadn't build with MDd, I wouldn't have noticed it
[23:02:10 CEST] <alevinsn> and I built ffmpeg that way to figure out the cause of a large memory leak that MSVC was reporting
[23:02:37 CEST] <alevinsn> I think the memory leak might have been caused by the spurious frees
[23:03:04 CEST] <cone-630> ffmpeg 03Aaron Levinson 07release/3.3:19fea7d703b0: avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
[23:03:27 CEST] <jamrial> J_Darnley: yeah, mailman somehow screws up and alters the signed portions of enigmail formated mail
[23:03:56 CEST] <jamrial> with the MIME multipart boundaries
[23:04:34 CEST] <cone-630> ffmpeg 03Aaron Levinson 07release/3.2:7793fc5b339d: avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
[23:05:54 CEST] <cone-630> ffmpeg 03Aaron Levinson 07release/3.1:f125c54b7a5f: avutil/hwcontext_dxva2: Don't improperly free IDirect3DSurface9 objects
[23:06:57 CEST] <jkqxz> And 3.0 predates hwcontext, so not relevant.
[23:08:28 CEST] <cone-630> ffmpeg 03James Almer 07release/3.1:c823d72a5f43: avcodec/hevc_sei: fix amount of bits skipped when reading picture timing SEI message
[23:13:52 CEST] <alevinsn> question: regarding commit log e-mails received on ffmpeg-cvslog
[23:14:16 CEST] <alevinsn> If I remove the
[23:14:23 CEST] <alevinsn> "ffmpeg | ..." line
[23:14:28 CEST] <alevinsn> and put the next line in the subject
[23:14:32 CEST] <alevinsn> is that the equivalent of a patch?
[23:16:04 CEST] <alevinsn> besides the git.videolan stuff
[23:16:09 CEST] <alevinsn> forget it, I'll create it manually
[23:16:23 CEST] <jkqxz> The subject should be fine already because git am ignores the bit in [], so just remove the second line as well I think?
[23:17:28 CEST] <jkqxz> Easier to get it directly by pulling, though.
[23:18:29 CEST] <jkqxz> (ffmpeg and libav are sufficiently compatible that you can have a single repo with multiple remotes and cherry-pick patches between them.)
[23:19:16 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:e45226adc46e: avcodec/truemotion1: Fix multiple runtime error: signed integer overflow: 1246906962 * 2 cannot be represented in type 'int'
[23:19:17 CEST] <cone-630> ffmpeg 03Leo Izen 07master:f810c469223b: doc/filters: Added line to the af_bs2b filter docs mentioning --enable-libbs2b
[23:19:18 CEST] <cone-630> ffmpeg 03Michael Niedermayer 07master:5666b95c9f27: avcodec/scpr: mask bits to prevent out of array read
[23:25:46 CEST] <alevinsn> jkqxz: I did it in a more manual fashion, maybe I could have done it faster in a way that saved a few minutes :-)
[23:33:28 CEST] <jkqxz> One of the perils of git. However you do something, someone else will always be able to tell you a more obscure way you could have done it faster :P
[00:00:00 CEST] --- Wed May 17 2017
1
0
[00:33:57 CEST] <james999> oh sorry i was afk
[00:34:26 CEST] <james999> well wikipedia says that async is the concept of multiple things happening at same time
[00:34:35 CEST] <james999> which is what i thought threads do
[00:35:17 CEST] <kms_> ffmpeg -i rtsp://EEEE -vcodec copy -acodec libmp3lame -ar 44100 -f flv -y 1.flv dont readable result file
[00:35:28 CEST] <kms_> but stream in vlc is ok
[00:53:41 CEST] <sikilikis> yo, is furq or kepstin on?
[00:54:04 CEST] <furq> i am always online
[00:54:05 CEST] <kepstin> nope, i'm off doing something else right now.
[00:54:06 CEST] <furq> and i'm nice on there
[00:54:18 CEST] <sikilikis> so remember my complaining earlier?
[00:54:23 CEST] <furq> how could i forget
[00:55:02 CEST] <sikilikis> so I may have fixed it. Haven't fully tested yet. But I'm not sure what I did
[00:55:05 CEST] <sikilikis> or why
[00:55:15 CEST] <sikilikis> one, I did a firmware update on the raspberry pi
[00:55:47 CEST] <sikilikis> but at the same time when I was testing ffmpeg (before the update) I kept googling stuff and ran into the vcdbg reloc command
[00:56:03 CEST] <sikilikis> know what that does?
[00:56:20 CEST] <furq> it dumps the heap for debugging
[00:56:26 CEST] <furq> according to this thing i just googled
[00:56:38 CEST] <sikilikis> okay, so when I did that I noticed that it said something about heap corruption
[00:56:46 CEST] <sikilikis> only when running ffmpeg
[00:57:17 CEST] <furq> well vc is only for decoding and encoding
[00:57:23 CEST] <furq> so it's not going to be doing anything when you're not running ffmpeg
[00:57:54 CEST] <sikilikis> is that something that can get fucked up, even between OS installations? I mean its just memory allocation right?
[00:58:03 CEST] <furq> shrug
[00:58:18 CEST] <furq> if you weren't on the latest firmware then that could potentially cause issues
[00:58:21 CEST] <sikilikis> yeah I know it sounds stupid since memory is volatile but
[00:58:30 CEST] <furq> ffmpeg presumably expects a recent firmware
[00:58:42 CEST] <sikilikis> I'm just trying to piece together why updated firmware fixed it if it was working fine before
[00:59:02 CEST] <furq> did you install new firmware after reinstalling
[00:59:10 CEST] <sikilikis> yes
[00:59:14 CEST] <furq> no idea then
[00:59:18 CEST] <sikilikis> no the first time
[00:59:20 CEST] <sikilikis> not*
[00:59:27 CEST] <furq> well yeah i mean before this time
[00:59:44 CEST] <furq> depending on how you installed it, you could've ended up with old firmware
[00:59:46 CEST] <sikilikis> no I didnt. First time just installed the OS and eventually got it working
[00:59:59 CEST] <furq> i'd be inclined to blame that then
[01:00:01 CEST] <sikilikis> I'm using the same OS image I used the first time
[01:00:12 CEST] <furq> yeah i'm guessing you ran rpi-update on the old setup but didn't on the new one
[01:00:28 CEST] <furq> i was running quite old firmware when i first tried to get vc to work and it wouldn't even start encoding
[01:00:31 CEST] <sikilikis> I never ran rpi-update on the old setup and just ran it on this one
[01:00:45 CEST] <sikilikis> but it worked on the old setup for like a month straight
[01:00:46 CEST] <furq> shrug
[01:00:50 CEST] <furq> that's my best guess
[01:01:06 CEST] <sikilikis> I mean it's possible that its still broken. I only tested for like 2 minutes
[01:01:13 CEST] <furq> omx.c in ffmpeg hasn't been updated in a few months
[01:01:21 CEST] <sikilikis> but before it would start getting buffer overruns immediatly
[01:02:40 CEST] <sikilikis> anyway thought you would want to know
[01:08:38 CEST] <gabinante> Hi friends, looking for some direction on segment and concatenate used in sequence, per my question on the ffmpeg forums: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=3643 . I get tiny, near-imperceptible skips in my audio track when I use this method. Anyone have a clue why?
[01:11:40 CEST] <haroldp> Anyone feel like helping me add HLS or Dash support to an otherwise working nginx + ffmpeg setup? :)
[01:18:08 CEST] <Fenrirthviti> haroldp: In theory, you just make a new application block and use exec_push to send the stream there
[01:18:39 CEST] <haroldp> yeah, I have been copy & pasting examples I've found, but not having too much luck
[01:19:09 CEST] <Fenrirthviti> What isn't working?
[01:19:18 CEST] <Fenrirthviti> Can you share what you have now?
[01:19:23 CEST] <haroldp> Dash or HLS :)
[01:19:53 CEST] <haroldp> my RTMP setup is really trivial
[01:20:20 CEST] <haroldp> it just takes a shitty webcam that doesn't have any decent web support, and uses ffmpeg to convert it
[01:21:17 CEST] <haroldp> that works but I can't get RTMP working *reliably* in a browser
[01:22:40 CEST] <Fenrirthviti> well, the rtmp part is easy
[01:22:59 CEST] <Fenrirthviti> you just have to use flash to play it in a browser, no other way around that
[01:23:04 CEST] <haroldp> I was using Flowplayer in the browser
[01:23:25 CEST] <Fenrirthviti> dunno about that, I use video.js and have no issues with rtmp itself
[01:23:40 CEST] <haroldp> hmm, maybe I should try that
[01:23:44 CEST] <furq> er
[01:23:47 CEST] <furq> you don't need to use exec
[01:23:54 CEST] <furq> just add "hls on" to your existing rtmp block
[01:24:20 CEST] <Fenrirthviti> and you need the path
[01:24:27 CEST] <haroldp> don't i need an HTTP block to suppport HLS's meta info requirements too?
[01:24:42 CEST] <Fenrirthviti> and the http location, and doing hls on; disables rtmp playback for that block
[01:24:51 CEST] <furq> no it doesn't
[01:25:32 CEST] <furq> https://gist.githubusercontent.com/qruf/cbd22ebe6afed9cccc0481074aa6e309/ra…
[01:25:35 CEST] <furq> that's more or less what i use
[01:26:05 CEST] <Fenrirthviti> and both rtmp and hls playback work from that?
[01:26:07 CEST] <furq> yeah
[01:26:10 CEST] <haroldp> thanks. looking.
[01:26:12 CEST] <furq> you need worker_processes 1 iirc
[01:26:28 CEST] <Fenrirthviti> yeah that's true across the board for nginx-rtmp
[01:26:39 CEST] <Fenrirthviti> unless you're on sergey's fork where they sort of fixed multi-worker setups
[01:26:47 CEST] <furq> i'm not
[01:26:56 CEST] <furq> i need to update really
[01:27:06 CEST] <furq> i built this ages ago and i've not touched it since
[01:27:16 CEST] <Fenrirthviti> His fork fixes a ton of stuff, but breaks some key features I use, like recorder blocks
[01:27:35 CEST] <Fenrirthviti> And my HLS issue is not present on his branch, btw, from earlier
[01:27:46 CEST] <furq> i don't see why you'd need multiple workers really
[01:27:52 CEST] <furq> unless you're ingesting thousands of rtmp streams
[01:27:53 CEST] <Fenrirthviti> load balancing I guess?
[01:27:56 CEST] <haroldp> what''s up with the lua configs in your example?
[01:28:00 CEST] <furq> that's for auth
[01:28:01 CEST] <furq> you can ignore that
[01:28:08 CEST] <haroldp> thank you
[01:28:56 CEST] <haroldp> the HTTP examples I've seen include a lot of CORS stuff
[01:29:08 CEST] <Fenrirthviti> You need it depending on how your site is configured.
[01:29:25 CEST] <haroldp> it will be cross domain, so i guess I need that
[01:29:31 CEST] <furq> you don't need it for now
[01:29:41 CEST] <furq> access-control-allow-origin should just disable that
[01:29:42 CEST] <Fenrirthviti> The examples usually do a "allow everything from everywhere" just to bomb the issue out of existence
[01:29:44 CEST] <Fenrirthviti> so try it first without
[01:29:45 CEST] <furq> obviously don't do that in production
[01:30:39 CEST] <haroldp> roger that
[01:30:46 CEST] <furq> there is also no need to serve the fragments from your rtmp nginx
[01:31:01 CEST] <furq> i don't actually run that config, that's just for demonstration
[01:31:08 CEST] <haroldp> Imma see if I can adapt this to my setup. Thanks again for the example
[01:32:13 CEST] <furq> but yeah all you strictly need is hls on and hls_path
[01:32:35 CEST] <furq> everything else is more or less optional
[01:33:16 CEST] <haroldp> should be ok to omit server_name in the http block until i get a real hostname pointed at it right?
[01:34:01 CEST] <furq> use an ip
[01:34:05 CEST] <haroldp> k
[01:34:27 CEST] <furq> or "_"
[01:35:41 CEST] <haroldp> you just picked 1953 as the HTTP port right? Could be anything so long as hls_base_url, and on_publish point to it correctly?
[01:35:57 CEST] <Fenrirthviti> adding hls to my normal live block definitely breaks normal RTMP playback.
[01:35:59 CEST] <Fenrirthviti> Just tested it.
[01:36:01 CEST] <furq> on_publish is more auth stuff, you can ignore that
[01:36:15 CEST] <furq> Fenrirthviti: shrug
[01:36:17 CEST] <furq> works for me
[01:36:26 CEST] <furq> i specifically tested that because it was broken with multiple workers
[01:36:43 CEST] <Fenrirthviti> Wonder if it's a bug introduced in later versions then :\
[01:36:55 CEST] <furq> iirc it would actually break hls playback when i connected through rtmp
[01:37:00 CEST] <Fenrirthviti> I'm on latest master from arut
[01:37:08 CEST] <furq> yeah my build is probably a year old at this point
[01:37:37 CEST] <furq> good job it's not actually running or that would be a security concern
[01:37:45 CEST] <Fenrirthviti> haha
[01:37:57 CEST] <furq> although i disabled pretty much everything anyway
[01:37:59 CEST] <Fenrirthviti> HLS playback is working smoother though, when streaming right to the block itself
[01:38:09 CEST] <Fenrirthviti> wonder if push is breaking the stream somehow when it copies it.
[01:38:36 CEST] <furq> what ffmpeg version is that
[01:38:58 CEST] <Fenrirthviti> just nginx push directive, not exec_push
[01:39:00 CEST] <Fenrirthviti> but I'm on...
[01:39:07 CEST] <furq> oh right
[01:39:10 CEST] <furq> probably doesn't matter then
[01:39:11 CEST] <Fenrirthviti> 2.6.9
[01:39:24 CEST] <furq> worth upgrading anyway
[01:39:24 CEST] <Fenrirthviti> for ffmpeg, either method seems to break the playback. very frustrating.
[01:39:40 CEST] <furq> 2.6 is pretty old
[01:40:02 CEST] <Fenrirthviti> yeah, all I used it for on this box was taking screenshots, because the record blocks were broken
[01:40:17 CEST] <furq> https://www.johnvansickle.com/ffmpeg/
[01:40:22 CEST] <furq> assuming your distro isn't packaging anything newer
[01:40:26 CEST] <Fenrirthviti> but I patched those and now I haven't really used it for anything, until I started trying to get mobile playback working
[01:40:29 CEST] <Fenrirthviti> it's debian 8
[01:40:36 CEST] <Fenrirthviti> so not likely
[01:40:43 CEST] <furq> backports has 3.2.4
[01:41:11 CEST] <furq> i've heard fun things about installing ffmpeg from backports though
[01:41:14 CEST] <furq> although mostly on desktop systems
[01:41:22 CEST] <Fenrirthviti> yeah.... I've had nightmares about that.
[01:41:30 CEST] <Fenrirthviti> I can just compile, it's not a hassle
[01:41:36 CEST] <furq> just use the static builds
[01:41:50 CEST] <furq> if you don't have esoteric library requirements then they're perfectly good
[01:42:06 CEST] <Fenrirthviti> I don't really, just x264 is all I need
[01:46:41 CEST] <Fenrirthviti> Let's see if the new version helps any...
[01:47:28 CEST] <haroldp> does this look sane: https://pastebin.com/6Pc9pBRD
[01:47:29 CEST] <Fenrirthviti> furq: ffmpeg -re -i rtmp://stream.rachni.com/live/$name -c copy -f flv rtmp://stream.rachni.com/dash/$name Anything seem off about that for a simple pass-through?
[01:48:05 CEST] <furq> you don't need -re for live sources
[01:48:22 CEST] <Fenrirthviti> ah right, missed that
[01:52:49 CEST] <haroldp> can I test HLS with VLC?
[01:53:46 CEST] <Fenrirthviti> yes
[01:53:48 CEST] <haroldp> looks like I can. What will the URLs look like?
[01:53:58 CEST] <Fenrirthviti> http://yoursite/hls/name.m3u8
[01:53:58 CEST] <furq> open the m3u8
[01:54:07 CEST] <Fenrirthviti> or whatever you have the path set to
[01:56:06 CEST] <damdai> what is better? i7-3770k or ryzen5-1400 (without overclocking on both) ?
[01:56:47 CEST] <haroldp> so in VLC with RTMP I was using: rtmp://my.public.ip/live/cam1
[01:56:50 CEST] <Fenrirthviti> Hm. That command appears to be doing nothing. That's annoying.
[01:57:18 CEST] <haroldp> I should change that to http://my.public.ip:1953/live/cam1.m3u8 ?
[01:57:52 CEST] <Fenrirthviti> hls/cam1.m3u8 is your location you set
[01:58:03 CEST] <haroldp> duh, sorry
[01:59:28 CEST] <damdai> what is better? i7-3770k or ryzen5-1400 (without overclocking on both) ?
[01:59:40 CEST] <Fenrirthviti> damdai: Spamming your question is a really bad way to get an answer.
[01:59:49 CEST] <damdai> ok sorry
[01:59:54 CEST] <Fenrirthviti> Also this is a really weird place to be asking something like that.
[02:00:12 CEST] <damdai> not really, because i am asking what is better for doing ffmpeg related things
[02:00:29 CEST] <Fenrirthviti> Maybe you should include that in your question, with a better explanation on what you're trying to do.
[02:00:49 CEST] <damdai> what is better? i7-3770k or ryzen5-1400 (without overclocking on both) for doing ffmpeg related things?
[02:01:09 CEST] <Fenrirthviti> ...
[02:01:38 CEST] <haroldp> Getting this in my nginx logs: 2017/05/15 16:58:25 [error] 61664#101145: *14 open() "/tmp/hlscam1-36.ts" failed (2: No such file or directory)
[02:02:37 CEST] <haroldp> that file path looks weird
[02:03:14 CEST] <haroldp> it's complaining about no such file "/tmp/hlscam1-36.ts" but /tmp/hls/cam1-36.ts" *does* exist
[02:03:27 CEST] <haroldp> er
[02:03:32 CEST] <haroldp> no it doesn't
[02:03:53 CEST] <haroldp> but /tmp/hls/cam1-58.ts does
[02:04:44 CEST] <haroldp> looks like it in continually creating new files there
[02:04:52 CEST] <Fenrirthviti> yes, that's how HLS works
[02:04:59 CEST] <Fenrirthviti> you have the playlist, and then a rolling set of .ts fragments
[02:05:01 CEST] <furq> you're missing part of the path
[02:05:02 CEST] <haroldp> that path with the missing / is odd tho
[02:05:11 CEST] <furq> oh right
[02:05:19 CEST] <furq> i guess hls_path needs the trailing slash
[02:05:30 CEST] <haroldp> that was my first guess too
[02:05:31 CEST] <Fenrirthviti> doesn't on mine, weird.
[02:05:36 CEST] <furq> yeah mine doesn't have that either
[02:05:44 CEST] <Fenrirthviti> I just checked when I saw, and works fine without it
[02:05:47 CEST] <haroldp> tried it with a trailing /, but i get teh same result
[02:07:19 CEST] <haroldp> is "root /tmp" right in the HTTP block if I have "hls_oath /tmp/hls/ in the RTMP block?"
[02:07:59 CEST] <Fenrirthviti> yes
[02:08:10 CEST] <Fenrirthviti> because your location is /hls, with root of /tmp
[02:08:53 CEST] <haroldp> haha
[02:09:02 CEST] <haroldp> I tried it and the result was this error: 2017/05/15 17:08:36 [error] 63765#100621: *2 open() "/tmp/hls/hls/cam1.m3u8" failed (2: No such file or directory)
[02:09:15 CEST] <haroldp> pretty sure its just fucking with me now. :)
[02:14:12 CEST] <Fenrirthviti> urg, starting to get really annoyed at vlc locking up on me on these broken hls streams.
[02:15:07 CEST] <james999> Fenrirthviti: i've force quit VLC so many times on xbox and pc and phone I've lost track
[02:15:24 CEST] <james999> now i just sort of assume that's the default way of closing it
[02:15:29 CEST] <Fenrirthviti> hah
[02:15:46 CEST] <Fenrirthviti> I normally use mpc-hc, but vlc seems to do better with network stuff
[02:16:04 CEST] <Fenrirthviti> and I'm pretty sure it's in part due to the errors in the hls stream being sent there, but still annoying :\
[02:18:57 CEST] <haroldp> Working! It was hls_base_url that was missing a trailing slash.
[02:20:33 CEST] <haroldp> Would you recommend video.js to embed an HLS stream in a web page?
[02:20:45 CEST] <Fenrirthviti> Ah damn, I am going to need to compile myself. The static ffmpeg binaries don't have libfaac :(
[02:26:29 CEST] <james999> Fenrirthviti: what system/kernel?
[02:27:14 CEST] <Fenrirthviti> debian 8
[02:27:16 CEST] <furq> Fenrirthviti: you don't need libfaac any more
[02:27:26 CEST] <furq> the builtin aac encoder is better now
[02:27:32 CEST] <furq> not that that's difficult, faac was always shit
[02:27:36 CEST] <Fenrirthviti> oh is it? neat.
[02:27:57 CEST] <Fenrirthviti> So far I'm still getting the CC errors, but playback is working a little better with the updated binaries
[02:28:12 CEST] <furq> you'd need to rebuild for fdk-aac because that's nonfree
[02:28:17 CEST] <furq> but you only really need that for he-aac
[02:29:57 CEST] <Fenrirthviti> argh I don't fucking understand this. the command is running, it works fine when run via CLI, but when invoked from nginx it does nothing
[02:29:59 CEST] <furq> have they still not released debian 9
[02:30:09 CEST] <Fenrirthviti> april 17th I think it was released
[02:30:13 CEST] <furq> it's still not out
[02:30:30 CEST] <furq> all my boxes are on testing, so they've had frozen packages for three months now
[02:30:50 CEST] <Fenrirthviti> or maybe 15th? something happened on the 15th
[02:31:05 CEST] <Fenrirthviti> Ah wait, I'm thinking ubuntu, not debian, disregard.
[02:31:08 CEST] <furq> oh
[02:31:15 CEST] <furq> the 15th was the last status update
[02:31:17 CEST] <furq> coincidentally enough
[02:31:35 CEST] <Fenrirthviti> yeah I remember hearing something, and then ubuntu updated as well around the same time, got them mixed up
[02:32:06 CEST] <Fenrirthviti> and friggin stdout routing of course doesn't work reliably in nginx
[02:32:22 CEST] <mccc> Hi, for the last couple days I've been asking about a problem where my recorded audio has been playing about 5%-10% slower than it should - I think this was a hardware problem, when I swapped the soundcard it started recording at the correct speed. Thanks for those looking at it :) I've got HLS now working using MPEG2-TS and AAC, I think my next project is going to be getting HLS or DASH
[02:32:22 CEST] <mccc> working with fMP4.
[02:32:45 CEST] <furq> stdout routing?
[02:32:53 CEST] <furq> mccc: i wouldn't bother with fmp4 for hls
[02:32:57 CEST] <Fenrirthviti> for exec directives
[02:33:04 CEST] <furq> oh
[02:33:07 CEST] <furq> ffmpeg outputs on stderr
[02:33:13 CEST] <Fenrirthviti> you should be able to route stdout/stderr
[02:33:15 CEST] <Fenrirthviti> neither really works.
[02:33:18 CEST] <furq> fair enough
[02:33:26 CEST] <Fenrirthviti> &>> log.log does nothing
[02:33:29 CEST] <Fenrirthviti> very frustrating.
[02:34:04 CEST] <furq> does it have the right permissions
[02:34:15 CEST] <mccc> furq - why not, just because mpeg2-ts works for HLS so why bother? I'm also looking at using DASH instead where mpeg2-ts isn't supported on some platforms.
[02:34:29 CEST] <furq> mccc: yeah it's only worth doing if you want to use the same fragments for hls and dash
[02:34:35 CEST] <Fenrirthviti> it does, yeah
[02:34:38 CEST] <furq> but there isn't really much point using dash for live streams
[02:34:44 CEST] <furq> even youtube uses hls
[02:34:51 CEST] <furq> and they're the biggest user of dash
[02:36:21 CEST] <mccc> furq - sure, I'm pretty happy I've gotten this working fine with hls :) I do have a combination of on-demand and live content though and dash seems to offer more options - one in particular is specifying that only part of the last segment in a playlist should actually play out.
[02:36:26 CEST] <james999> furq: how long are package updates frozen with debian testing?
[02:36:33 CEST] <furq> until it becomes stable
[02:36:43 CEST] <furq> which has been "any day now" for about a month
[02:37:04 CEST] <james999> ok
[02:37:12 CEST] <haroldp> Holy! I have a working web cam in the browser!
[02:37:32 CEST] <furq> i bet you've got some world-class latency on it as well
[02:37:37 CEST] <haroldp> furq & Fenrirthviti: thanks so much for your help.
[02:37:53 CEST] <Fenrirthviti> probably around 20s on top of whatever else, yeah
[02:38:19 CEST] <haroldp> It's a dumb customer who bought dumb cams but still wants them embedded in his public web page
[02:38:46 CEST] <furq> well then who cares about the latency
[02:38:52 CEST] <haroldp> not me :)
[02:41:05 CEST] <Fenrirthviti> $name.m3u8
[02:41:05 CEST] <Fenrirthviti> wat.
[02:41:10 CEST] <Fenrirthviti> nginx has forgot how2variable
[02:41:15 CEST] <furq> noice
[02:41:35 CEST] <Fenrirthviti> That would explain why the command was failing in nginx, but not CLI
[02:44:07 CEST] <haroldp> wow, works in crome, ff and safari.
[02:44:20 CEST] <haroldp> dod I dare try IE? :)
[02:44:24 CEST] <Fenrirthviti> hls should work on most devices these days
[02:45:17 CEST] <DHE> anything that doens't do HLS natively should work with HLS.js
[02:45:39 CEST] <haroldp> Anyway, Imma go make dinner now. Seriously though, thanks again! Huge help.
[02:53:44 CEST] <Fenrirthviti> Well I have no idea what to do from here. Debugging nginx not parsing its own variable for some reason is well outside my abilities :(
[02:59:53 CEST] <james999> well Fen
[03:00:10 CEST] <james999> I couldn't even get an rtsp thing to ork in nginx after I searched for an hour to find a version fo nginx with rtmp support!
[04:32:59 CEST] <furq> https://pbs.twimg.com/media/C_6goddWAAAl8rR.jpg
[04:33:01 CEST] <furq> i changed my mind
[04:33:03 CEST] <furq> interlacing is good now
[04:33:37 CEST] <james999> @_@
[04:33:50 CEST] <james999> Hey furq speaking of eccentric politicians
[04:33:56 CEST] <james999> what do you think of this philip davies guy?
[04:34:10 CEST] <furq> i think i just had to google him
[04:34:35 CEST] <james999> ah ok. he got himself elected or something to a gender and equality committe in parliament
[04:34:38 CEST] <furq> also that was an excellent segue
[04:35:00 CEST] <james999> thanks
[04:35:16 CEST] <james999> I mean say what you will good or bad about trump
[04:35:20 CEST] <james999> he likes his steak well-done
[04:35:25 CEST] <furq> with ketchup
[04:35:25 CEST] <james999> which is pretty odd in my book
[04:35:37 CEST] <james999> yes.. lol
[04:36:02 CEST] <furq> my favourite thing about that was all the #MAGA people on twitter suddenly deciding that that was a manly way to eat steak
[04:36:30 CEST] <james999> lol sounds like that silly twitter meme about milk being racist
[04:36:35 CEST] <james999> but who knows maybe it's real
[04:39:03 CEST] <james999> By the way, an excellent method of finding overviews of technical stuff on google is with a search like "pci intro filetype:pdf site:.edu"
[04:39:22 CEST] <james999> even though you'll get a lot of crappy power point slides masquerading as pdfs. T_T
[06:51:42 CEST] <hanna> james999: it's even more fun when you have home HOME on NFS
[06:51:48 CEST] <hanna> pull cable -> entire desktop locks up, including all programs
[06:52:05 CEST] <hanna> that was re: blocking filesystem on linux
[07:07:44 CEST] <james999> hah wow
[07:08:28 CEST] <hanna> Oh and heaven help you if you try using anything that enumerates block devices while in the process of issuing an ATA secure erase
[07:08:34 CEST] <hanna> once had a system with load 200 due to it :D
[07:08:41 CEST] <james999> yeah that convo was me trying to see if anybody had a good book on writing concurrent programs
[07:08:50 CEST] <james999> but now with my new google fu mb i'll find one myself
[07:09:02 CEST] <hanna> james999: http://chimera.labs.oreilly.com/books/1230000000929 language specific but contains a lot of knowledge
[07:09:16 CEST] <hanna> free online
[07:09:36 CEST] <james999> hmm well i wasn't too sure about that concept
[07:09:41 CEST] <james999> but now i think i'm more open to it
[07:10:01 CEST] <hanna> also one of the best books about haskell ever written :p
[07:10:44 CEST] <james999> haha ok
[07:11:15 CEST] <james999> the one thing that seems to be constant in computers is constant new hardware and constant new languages
[07:11:23 CEST] <james999> without there necessarily being a relationship there
[07:12:09 CEST] <hanna> constant innovation is a human property
[07:12:13 CEST] <james999> there was a mathematician who wrote on his blog about some java app to draw diffeq graphs...
[07:12:23 CEST] <james999> he asked can he just write a program and have it work for all time
[07:12:24 CEST] <hanna> we're too curious/creative for our own good
[07:12:36 CEST] <james999> yeah
[07:12:56 CEST] <james999> i mean you could specify an abstract machine with xyz properties to run your code on
[07:13:08 CEST] <james999> but you have no guarantee anybody will emulate that machine
[07:13:19 CEST] <hanna> wow you're already thinking like a haskell programmer :^)
[07:13:41 CEST] <james999> lol more like 86box programming. been hanging out here for a few days
[07:13:51 CEST] <james999> i'm stunned how much knowledge of windows alone is in here
[07:14:23 CEST] <hanna> know your enemy, huh
[07:14:53 CEST] <damdai> what is better? i7-3770k or ryzen5-1400 (without overclocking on both) for doing ffmpeg related things?
[07:15:32 CEST] <hanna> TD-Linux ought to know this ^
[07:17:04 CEST] <TD-Linux> the CPU choice question?
[07:17:21 CEST] <james999> hanna: oh lol sorry i said it in wrong channel
[07:17:35 CEST] <james999> yeah i'm a secret undercover double agent or something. XD
[07:18:10 CEST] <hanna> TD-Linux: yes
[07:18:14 CEST] <TD-Linux> i7-3770k
[07:18:17 CEST] <hanna> (am also curious)
[07:18:27 CEST] <hanna> isn't it pretty old
[07:18:31 CEST] <TD-Linux> probably look it up to see
[07:18:32 CEST] <hanna> and the ryzen pretty new and hip
[07:18:42 CEST] <hanna> oh ryzen 5 not ryzen 7
[07:18:45 CEST] <TD-Linux> that was gut instinct
[07:18:49 CEST] <TD-Linux> 4c vs 4c
[07:18:51 CEST] <hanna> AKA the poor one
[07:31:03 CEST] <c3r1c3-Win> You're better getting the 6-core Ryzen 5.
[07:42:41 CEST] <c3r1c3-Win> Yeah, mark my last comment up for the "Captain Obvious" award of the year.
[11:47:32 CEST] <dystopia_> morning
[11:47:48 CEST] <dystopia_> ffmpeg.exe -i in.ts -c:v copy -c:a mp2 out.ts
[11:48:07 CEST] <dystopia_> trying to lower the bitrate of audio from 384 kbps to 192 kbps
[11:48:22 CEST] <dystopia_> what should i add to the "-c:a mp2 " ?
[11:48:43 CEST] <james999> i'm not sure i want to work in an office where people start out by saying "good morning. Can you execute ffmpeg -i ...."
[11:48:45 CEST] <james999> XD
[11:48:57 CEST] <furq> why would you use mp2
[11:49:08 CEST] <dystopia_> it already is mp2 furk
[11:49:15 CEST] <dystopia_> i just want to lower it's bitrate
[11:49:16 CEST] <furq> so use the opportunity to make it something better
[11:49:26 CEST] <dystopia_> i will need to do the same with ac3 later
[11:49:27 CEST] <dystopia_> well
[11:49:49 CEST] <dystopia_> this is a 1 second video, that will be appended on to the front of another video
[11:49:51 CEST] <james999> isn't it reencoding either way?
[11:50:00 CEST] <dystopia_> i just want to maintain encoding settings in a file
[11:50:08 CEST] <dystopia_> because the file i append to will be cut after encode
[11:50:38 CEST] <dystopia_> and loose it's settings
[11:50:58 CEST] <dystopia_> anyway :p
[11:51:13 CEST] <dystopia_> how should i issue the command
[11:51:49 CEST] <james999> I used -b before but i think it was total bitrate not audio alone
[11:54:26 CEST] <dystopia_> that did it james999
[11:54:30 CEST] <dystopia_> -b:a 192k
[11:54:32 CEST] <dystopia_> thank you
[11:57:43 CEST] <james999> np
[11:58:18 CEST] <james999> hey furq, apparently merkel is willing to sacrifice the german car industry in the talks
[11:58:26 CEST] <james999> does that mean no more cheap german cars for you guys?
[11:58:58 CEST] <durandal_170> offtopic
[14:52:40 CEST] <saulotoledo> Hello all :D I need some help with MPEG2 Transport Stream. Is there somebody here that can help me? I want to understand how the TS works, and I do not know where I can get some help about. I do not understand how the descriptors are transferred inside the PMT table. Can somebody help me? If this is off-topic, please send me a PM. Thanks in advance.
[14:55:01 CEST] <DHE> the descriptors are stream metadata, such as the language identifier for the audio. can you be more specific about what you need?
[17:14:29 CEST] <alexpigment> does anyone know if it's possible to have an LGPL version of FFMPEG link to a commercially licensed copy of x264 and use it as if it were a natively included copy?
[17:15:02 CEST] <alexpigment> i'd like to try and avoid creating elementary streams and muxing at the end of the process if possible
[17:20:39 CEST] <furq> alexpigment: there's nothing legally wrong with it but you'd have to patch configure yourself
[17:21:16 CEST] <alexpigment> furq: yeah, i was looking at this link earlier: https://ffmpeg.org/pipermail/ffmpeg-devel/2010-December/083754.html
[17:21:17 CEST] <furq> there was an ml thread about adding support in configure a while back and it seems to have gone nowhere (imagine that)
[17:21:20 CEST] <alexpigment> i assume that's what you're talking about
[17:21:20 CEST] <furq> yeah that's the one
[17:21:26 CEST] <alexpigment> k
[17:21:41 CEST] <alexpigment> just wanted to make sure there wasn't an easier solution since then
[17:21:44 CEST] <alexpigment> thanks
[17:22:05 CEST] <furq> i'm not really an expert on the matter
[17:22:09 CEST] <furq> it should be a simple fix though
[17:23:05 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L1505
[17:23:10 CEST] <furq> i think you'd just have to remove that line
[17:23:29 CEST] <alexpigment> oh gotcha
[17:23:32 CEST] <alexpigment> well that makes it easy :)
[17:23:37 CEST] <alexpigment> thank you furq
[17:23:47 CEST] <furq> obviously i am not a lawyer and what you do with this information is your own legal responsibility
[17:23:51 CEST] <furq> i'm pretty sure it's fine though
[17:25:02 CEST] <alexpigment> no worries, i'm very familiar with the "i'm not a lawyer" clause :)
[17:25:29 CEST] <alexpigment> anyway, thanks again
[18:05:44 CEST] <amosbird> hello
[18:05:50 CEST] <amosbird> how can I fix this https://la.wentropy.com/JAB5 ?
[18:05:58 CEST] <amosbird> is it due to deprecate argss
[18:06:00 CEST] <amosbird> ?
[18:13:54 CEST] <amosbird> what does this mean Past duration 0.800468 too large ?
[18:19:51 CEST] <dystopia_> [17:13:56] <amosbird> what does this mean Past duration 0.800468 too large ?
[18:20:02 CEST] <amosbird> huh?
[18:20:05 CEST] <dystopia_> your encoding at a diff frame rate than the video actually is
[18:20:21 CEST] <amosbird> so is it harmful?
[18:20:32 CEST] <dystopia_> no but you may have a dupe frame
[18:21:09 CEST] <dystopia_> i guess your encoding 23.97 stuff at 25fps or somthing like that
[18:24:20 CEST] <amosbird> um
[18:24:39 CEST] <amosbird> is it due to incorrect args? or because my cpu is slows
[18:24:41 CEST] <amosbird> ?
[18:26:18 CEST] <dystopia_> incorrect input settings
[18:27:50 CEST] <amosbird> thanks!
[19:11:25 CEST] <kepstin> I most often see that when ffmpeg misdetects the input framerate - if you have a file that ffmpeg detects as 24fps, but it has sections at 30fps, you'll get that message on the 30fps seconds and it'll drop frames.
[19:12:10 CEST] <kepstin> (particularly on vfr containers like mkv)
[19:38:13 CEST] <sikilikis> yo furq
[19:38:33 CEST] <sikilikis> quick question about the alsa buffer xrun stuff. Do you think it could be caused if I run ffmpeg at too low of a frame rate?
[19:56:01 CEST] <BtbN> sikilikis, as long as ffmpeg is running at 1x speed, it should be fine
[19:57:23 CEST] <ChocolateArmpits> Are filters threaded in any other way other than slice threads? I've built a pretty extensive filter graph and it's not keeping up realtime even though the cpu utilization is only around 7%
[19:58:51 CEST] <BtbN> pretty sure ffmpeg.c works the decoder->filters->encode graph in order, in a single thread
[19:59:16 CEST] <DHE> ChocolateArmpits: no, it's not.
[19:59:22 CEST] <DHE> (believe me, i want to fix that)
[19:59:42 CEST] <ChocolateArmpits> so all frames are sequenced rather than get processed out of order and then ordered correctly on output ?
[19:59:59 CEST] <BtbN> even with threads, you can't re-order them
[20:00:44 CEST] <DHE> I think at best you could pipeline them - have each filter run in its own thread, but still processing them in order
[20:00:51 CEST] <DHE> but that's still some major work
[20:01:20 CEST] <ChocolateArmpits> DHE, I used this prior, but it's additional stability risk to run several processes
[20:02:06 CEST] <DHE> it also introduces a lot of overhead for uncompressed frame copying between processes
[20:04:47 CEST] <ChocolateArmpits> In my case, the HD input of a capture card gets split across two filtergraphs, both deinterlacing and scaling to appropriate resolutions. The single input audio track gets split into 4 channels and each gets the loudness adjusted using loudnorm.
[20:05:36 CEST] <ChocolateArmpits> Processing of SD input is doing good, but the higher amount of data with HD makes it hard to achieve realtime processing
[20:06:05 CEST] <ChocolateArmpits> I'll probably have to drop loudnorm, doing simpler video filtering isn't enough
[20:06:20 CEST] <DHE> well, you might get better results with a single deinterlace filter and then rescale the output twice
[20:06:30 CEST] <DHE> not miracle worker levels, but a good first easy step
[20:06:44 CEST] <ChocolateArmpits> yeah it sort of works, until the audio processing step gets introduced
[20:09:42 CEST] <satinder___> Hi can we get microblock infomartation using ffmpeg
[20:10:08 CEST] <DHE> macroblock?
[20:10:25 CEST] <satinder___> yes
[20:10:36 CEST] <DHE> well, there's this: https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVectors
[20:10:37 CEST] <satinder___> DHE : macroblock
[20:10:53 CEST] <satinder___> ok
[20:14:06 CEST] <satinder___> DHE : thanks for share this link
[20:14:54 CEST] <satinder___> but can I do these things using api and compare each frame with reference frame
[20:15:01 CEST] <satinder___> Is that possible
[20:48:02 CEST] <saulotoledo> DHE: hi. Thank you for your response about the descriptors. I need to understand how they are transmitted. They are in the ES loop inside the PMT. Each loop item contains one ElementaryPID and a loop of descriptors. I also know that the descriptors are transmitted in the DSM-CC. SO the elementatyPID in the PMT loop points to a future TS Packet containing the DSM-CC?
[20:50:01 CEST] <saulotoledo> DHE: Also, what is the difference between the descriptor loop in the PMT body (PMT.descriptors) and the descriptor loop inside the each stream loop (PMT.streamLoop[n].descriptors)?
[20:50:10 CEST] <DHE> have you considered saving a .ts file to disk and opening it in wireshark? it can dissect it for you with a lovely GUI
[20:50:51 CEST] <DHE> no really. do it.
[20:50:55 CEST] <zerodefect> I am able to broadcast an mpeg-2v encoded (no audio) transport stream using the ffmpeg api. I can render the stream using ffplay. I was wondering how to configure avformat_alloc_output_context2(..) to encapsulate the ts stream within RTP instead of UDP. Is that possible?
[20:52:00 CEST] <saulotoledo> DHE: I was using a TS analyzer tool, but I am not sure about these questions :(
[20:52:24 CEST] <saulotoledo> DHE: I am still unable to understand the difference between the descriptors
[20:53:17 CEST] <DHE> if you are interested in the wire protocol (and it sounds like you are), playing with it in wireshark can be very useful. it will break the mpeg-ts into its 188 byte chunks and break down each stream's headers, descriptors and all the rest.
[20:56:29 CEST] <zerodefect> I've tried avformat_alloc_output_context2(&oc, NULL, "mpegts", rtp://127.0.0.1:5500), but the output errors with 'Data doesn't look like RTP packets.' It's fine with udp://127.0.0.1:5500 though.
[20:56:39 CEST] <zerodefect> It makes me think I'm using the wrong muxer?
[21:03:21 CEST] <saulotoledo> DHE: Thanks. I am already checking using Wireshark and I will come back here if I have more doubts. :)
[21:12:33 CEST] <kepstin> zerodefect: 'mpegts' is not rtp, so yes?
[21:14:31 CEST] <kepstin> zerodefect: rtp is a network protocol that directly contains codec data, so you need to encapsulate using the 'rtp' muxer for it to work
[21:17:00 CEST] <zerodefect> Thanks kepstin. If I used the 'rtp' muxer then the rtp payload would only contain the video essence (not any of the container)?
[21:18:05 CEST] <kepstin> zerodefect: rtp contains the video (and audio, etc.) streams directly, it does not transport other container formats.
[21:18:43 CEST] <kepstin> if you just want to transport mpeg-ts over udp, that's what the 'udp://' protocol is for.
[21:19:06 CEST] <zerodefect> Ok. As I suspected. Then what muxer do I use to encapsulate TS in RTP?
[21:22:41 CEST] <DHE> he literally just said you don't
[21:24:34 CEST] <zerodefect> So can I draw the conclusion that it's not possible?
[21:24:46 CEST] <BtbN> rtp _is_ a container.
[21:25:24 CEST] <zerodefect> Ok. That is where the confusion is coming in from my part :(
[21:27:08 CEST] <faLUCE> hello. Do you know any library for demuxing mpeg-ts in async way?
[21:28:32 CEST] <__jack__> libav ?
[21:28:51 CEST] <faLUCE> __jack__: it doesn't provide an async API for demuxing
[21:29:06 CEST] <zerodefect> Looking through the source, I've come across the 'rtp_mpegts' option which can be specified as a 'format name' to the aforementioned function.
[21:29:15 CEST] <__jack__> what do you mean by "async" (please be specific)
[21:29:17 CEST] <zerodefect> That looks to do as it says on the tin
[21:29:29 CEST] <__jack__> are you talking about things like asyncio ?
[21:29:41 CEST] <zerodefect> I'll give that a try
[21:30:34 CEST] <faLUCE> __jack__: I mean that it doesn't support non-blocking I/O.
[21:30:45 CEST] <faLUCE> and I need a non-blocking av_read_frame()
[21:34:42 CEST] <zerodefect> So 'avformat_alloc_output_context2(&oc, NULL, "rtp_mpegts", rtp://127.0.0.1:5500)' is encapsulating the TS stream in RTP packets.
[21:34:58 CEST] <zerodefect> That is what I needed.
[21:35:20 CEST] <kepstin> zerodefect: wait, that's actually a defined format?
[21:35:29 CEST] <kepstin> that's really weird, huh.
[21:35:51 CEST] <BtbN> why would you ever need that?
[21:35:56 CEST] <BtbN> Some weird destination or something?
[21:36:02 CEST] <zerodefect> Looks to work :) It plays fine from FFPlay and VLC :)
[21:36:25 CEST] <kepstin> i mean, what's the benefit in doing that over just putting the a/v directly in rtp?
[21:36:35 CEST] <BtbN> putting mpegts into rtp seems redundant to me
[21:36:35 CEST] <kepstin> or putting the mpegts directly in udp?
[21:36:57 CEST] <kepstin> I guess you have rtcp so it can do retransmits and stuff, so it's better than directly in udp, but...
[21:36:59 CEST] <BtbN> well, rtp can actually handle packet loss. mpegts in udp can't nearly as well
[21:37:12 CEST] <BtbN> But it can do so fine without mpegts
[21:37:15 CEST] <zerodefect> I was writing a bit of code to test a proprietary IRD. One of the formats it accepts is TS in RTP.
[21:37:36 CEST] <zerodefect> I have no affiliation with the manufacturer of the IRD (for the record).
[21:37:48 CEST] <BtbN> does it not accept normal rtp?
[21:38:49 CEST] <zerodefect> Not seen that listed yet, but it may be an option.
[21:39:07 CEST] <zerodefect> If you were using DVB, could RTP then have any added benefit?
[21:41:23 CEST] <BtbN> you're not putting a container into a container
[21:41:43 CEST] <BtbN> If you need some features mpegts supports but rtp doesn't, I can see it being useful
[21:41:59 CEST] <BtbN> Can also see why emdeded devices use it, as all they process is mpegts
[21:42:45 CEST] <zerodefect> What about FEC?
[21:43:00 CEST] <zerodefect> Could that have an impact of choice of protocol?
[21:43:20 CEST] <BtbN> I'm not aware of any fec in mpeg-ts
[21:43:28 CEST] <BtbN> It's just error-resilient by design
[21:43:47 CEST] <kepstin> you could probably use e.g. the rfc 5109 generic fec with it, but I doubt anything supports that :)
[21:43:47 CEST] <zerodefect> I see
[21:44:17 CEST] <BtbN> you rarely have actual transport errors over the internet anyway
[21:44:21 CEST] <BtbN> you lose packets whole
[21:44:58 CEST] <kepstin> well implemented fec (like in opus) can hide lost packets, which is kinda neat
[21:45:39 CEST] <zerodefect> Does it use a Row x Column matrix?
[21:45:54 CEST] <kepstin> I have no idea how that works, but opus fec is designed explicitly to fill in lost packets, rather than handle corrupt packets
[21:48:13 CEST] <zerodefect> Well, thanks for your help all.
[21:48:59 CEST] <kepstin> I suppose one of the benefits of mpegts in rtp is that it only needs one port for a+v, but many modern rtp implementations can do multiple rtp+rtcp muxed on a single port (RFC 5761)
[21:50:21 CEST] <zerodefect> Yes. Throwing it in mpegts instad of separate streams probably also makes lip sync easier?
[21:53:16 CEST] <kepstin> nah, rtp has a timestamping system that handles that just fine.
[21:53:31 CEST] <__jack__> faLUCE: I quick read the code, there is this: "One such case is when you want to use custom functions for reading input data instead of lavf internal I/O layer. To do that, create your own AVIOContext with avio_alloc_context(), passing your reading callbacks to it. Then set the @em pb field of your AVFormatContext to newly created AVIOContext."
[22:12:37 CEST] <phishy> Imagine my dismay when I used 92 physical cores for my ffmpeg command and it wasn't fast. https://www.packet.net/bare-metal/servers/type-2a
[22:15:46 CEST] <ChocolateArmpits> phishy, are you sure io isn't bottlenecking ?
[22:16:40 CEST] <phishy> ChocolateArmpits: does it get better than SSD?
[22:16:48 CEST] <kepstin> even with a codec like x264 which has pretty good thread scaling, you're not gonna be able to use all those cores with one ffmpeg command...
[22:17:02 CEST] <kepstin> and arm cores, so each individual cores is gonna be slow... :/
[22:17:29 CEST] <ChocolateArmpits> I think the troubles start with multiple processors
[22:17:39 CEST] <phishy> kepstin, I'm just bummed because I can't get anywhere near the performance that my friend can get on his Mac
[22:18:00 CEST] <phishy> I'm kinda wondering if there is more to it than CPU and disk
[22:18:01 CEST] <ChocolateArmpits> Then you have to turn on sliced threading and some additional parameters for the process if you're on windows
[22:18:25 CEST] <ChocolateArmpits> phishy, can't you check ssd utilization ?
[22:18:36 CEST] <DHE> phishy: how do I purchase such a machine and have it shipped to my location? :)
[22:19:07 CEST] <phishy> DHE, I think the guys at that web site will sell you their old ones
[22:19:13 CEST] <Mista_D> Has anyone tried muxing SCC Scenarist files with newest FFmpeg? What is the command please?
[22:21:37 CEST] <kepstin> phishy: basically, intel cpu cores (and recent amd ones) are really, really fast compared to the individual arm cores on that box, and x264 is much better optimized for them, so...
[22:22:15 CEST] <phishy> kepstin, thanks for that info. damned computer science, always getting in the way
[22:22:58 CEST] <kepstin> and video encoding multithreading is one of those diminishing returns with more cores kind of things... the slower settings and larger the video frames you're encoding, the more cores it can potentially use
[22:36:36 CEST] <ChocolateArmpits> try out slices, really
[22:41:12 CEST] <cryptodechange> could encoding with no audio, then muxing audio in from source produce an out of sync result?
[22:41:37 CEST] <ChocolateArmpits> cryptodechange, well does it ?
[22:41:44 CEST] <cryptodechange> haven't tried :P
[22:42:03 CEST] <cryptodechange> but in theory it shouldn't, right?
[22:42:08 CEST] <ChocolateArmpits> well yeah
[22:42:23 CEST] <ChocolateArmpits> Unless you do fast seeking
[22:42:34 CEST] <ChocolateArmpits> That may introduce problems
[22:42:59 CEST] <cryptodechange> is that a parameter?
[22:43:11 CEST] <cryptodechange> seeing as i haven't heard of it/used it, it shouldn't be a problem
[22:43:18 CEST] <ChocolateArmpits> well if you don't need to seek the file, then it shouldn't be of any bother
[22:43:48 CEST] <cryptodechange> I would like to with the end result
[22:44:47 CEST] <faLUCE> __jack__: I well know how to create a custom read callback linked to a custom I/O context. But this doesn't solve anything, nor it gives an asynchronous way of demuxing packets
[22:57:29 CEST] <rictan> Is there a way to configure ffmpeg binary to support only fragmented mp4 to mp4?
[22:58:31 CEST] <rictan> Something such as ./configure --disable-everything <parameters_to_enable fragmented mp4 to mp4>
[23:01:53 CEST] <cryptodechange> Is there any documentation on aq-mode=3?
[23:02:24 CEST] <faLUCE> anyway, I found that: https://github.com/frejoel/tsdemux . It supports async demuxing
[23:02:45 CEST] <cryptodechange> I am getting 'Too many packets buffered for output stream 0:1.' when trying to copy a TrueHD stream
[23:14:50 CEST] <kepstin> rictan: there's a few things that you can't disable while still having the ffmpeg cli work at all, and the mp4 muxer/demuxer can't be limited to just that use case, but you certainly can cut out a lot of the other stuff you don't need...
[23:34:07 CEST] <sikilikis> anyone know if I can increase the alsa buffer size on ffmpeg?
[23:34:37 CEST] <blue_misfit> hey guys! When using -ss and -to I normally have no issues, but when doing a job with 2 outputs ffmpeg seems to not respect the -to flag and encodes until the end of the file - how can I avoid this?
[23:35:10 CEST] <furq> -to is an output option
[23:35:14 CEST] <furq> you need to specify it for every output
[23:35:27 CEST] <blue_misfit> I see
[23:35:46 CEST] <blue_misfit> so if I'm doing -to 28 for video
[23:35:56 CEST] <blue_misfit> and I have a jpeg sequence also outputting at .1 fps
[23:36:07 CEST] <blue_misfit> do I need to make that 2.8?
[23:36:14 CEST] <furq> it should be the same
[23:36:15 CEST] <blue_misfit> or... hmm guessing no
[23:36:17 CEST] <blue_misfit> yeah
[23:36:18 CEST] <blue_misfit> ok
[23:36:21 CEST] <blue_misfit> let's see..
[23:36:28 CEST] <furq> or you could just use -t as an input option
[23:36:39 CEST] <kepstin> blue_misfit: -to takes a value in seconds, using a different framerate doesn't change how fast time passes ;)
[23:36:47 CEST] <blue_misfit> of course :)
[23:37:16 CEST] <Threads> nice to see someone from disney stop by
[23:37:23 CEST] <blue_misfit> hello! :)
[23:37:28 CEST] <furq> what if i use a really high negative framerate
[23:37:31 CEST] <furq> like in superman 1
[23:37:32 CEST] <blue_misfit> brilliant that totally works
[23:37:40 CEST] <blue_misfit> lol!
[23:37:46 CEST] <Threads> hello
[23:41:07 CEST] <sikilikis> Is there some way to increase the alsa buffer size? I'm still getting alsa xruns and I'm at my limit. At this point I figure I could just increase the buffer size and hope that it tanks any performance hits
[23:42:03 CEST] <durandal_170> isnt that becuse off high cpu usage
[23:42:24 CEST] <sikilikis> you'd think so but that isnt whats happening
[23:42:33 CEST] <BtbN> you're either fast enough to keep up, or you aren't
[23:42:36 CEST] <BtbN> no buffer can fix that
[23:43:03 CEST] <sikilikis> they dont happen constantly though. It's random
[23:43:23 CEST] <sikilikis> sometimes its often and sometimes its not
[23:45:02 CEST] <Cracki> cheers. looking for python bindings. what's the most advisable project/package/repo for that?
[23:45:53 CEST] <Cracki> I need to decode whole GOPs at a time, mostly.
[23:48:48 CEST] <debianuser> sikilikis: Have you checked ffmpeg CPU usage in `top` when that happens? Do you have xruns if you save to /dev/null instead of streaming it? Also, do you have xruns if you capture with `arecord` instead of `ffmpeg`?
[23:50:58 CEST] <sikilikis> ffmpeg uses between like 100% and 130% (4 cores)
[23:51:40 CEST] <sikilikis> haven't tried saving to /dev/null nor arecord. this is streaming live so im hesitant to just take it down
[23:52:52 CEST] <kepstin> sikilikis: it is probably limited by the speed of a single core on your system :/
[23:53:02 CEST] <Cracki> grml I remember asking this question before. someone pointed me to vlc's huge wrapper script that looks manually maintained.
[23:53:11 CEST] <Cracki> I'll just ust ctypes then...
[23:53:21 CEST] <sikilikis> it seems to be using each core fairly equally
[23:53:26 CEST] <sikilikis> each one is around 20-40%
[23:55:09 CEST] <sikilikis> maybe I should just try overclocking it a bit
[23:55:26 CEST] <sikilikis> though its using the hardware encoder
[00:00:00 CEST] --- Wed May 17 2017
1
0