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 2015
- 1 participants
- 62 discussions
[00:26:51 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07master:2025e803cd0c: avformat/mov: Do not read ACLR into extradata for H.264
[02:02:00 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:fbc998ce3f90: avformat/flvdec: do not inject dts=0 metadata packets which failed to be parsed into a new data stream
[02:02:01 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:bfdf15943d65: avformat/flvdec: Increase string array size
[02:02:02 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:19475c0d749c: avfilter/vf_sab: fix filtering tiny images
[02:02:03 CEST] <cone-837> ffmpeg 03wm4 07release/2.1:0bdbf1aba3b1: avcodec/dvdsubdec: fix out of bounds accesses
[02:02:04 CEST] <cone-837> ffmpeg 03Dale Curtis 07release/2.1:6832b1fde7b6: mov: Avoid overflow with mov_metadata_raw()
[02:02:05 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:71d0cfff15ea: avformat/mov: fix integer overflow in mov_read_udta_string()
[02:02:06 CEST] <cone-837> ffmpeg 03Dale Curtis 07release/2.1:13d4d8a9c6bb: mov: Fix negative size calculation in mov_read_default().
[02:02:07 CEST] <cone-837> ffmpeg 03Paul B Mahol 07release/2.1:ac1905cd5bff: lavfi: check av_strdup() return value
[02:02:08 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:83700aced191: avformat/matroskadec: Use av_freep() to avoid leaving stale pointers in memory
[02:02:09 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:fa0194e9ca70: avformat/utils: Clear pointer in ff_alloc_extradata() to avoid leaving a stale pointer in memory
[02:02:10 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:36ac58454832: avformat/mov: Fix mixed declaration and statement warning
[02:02:11 CEST] <cone-837> ffmpeg 03Johan Andersson 07release/2.1:e4fddd18e7f4: cmdutils: update copyright year to 2015.
[02:02:12 CEST] <cone-837> ffmpeg 03wm4 07release/2.1:f04b323a460f: avcodec/dvdsubdec: error on bitmaps with size 0
[02:02:13 CEST] <cone-837> ffmpeg 03wm4 07release/2.1:5a98a000018e: avcodec/dvdsubdec: fix accessing dangling pointers
[02:02:14 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:ccca7ae8c6db: ffmpeg: Clear error message array at init.
[02:02:15 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:9d156e24d779: avcodec/flac_parser: fix handling EOF if no headers are found
[02:02:16 CEST] <cone-837> ffmpeg 03Vittorio Giovara 07release/2.1:d00e2fa28410: swscale: check memory allocations
[02:02:17 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:7c54f1416859: avformat/rmdec: Check for overflow in ff_rm_read_mdpr_codecdata()
[02:02:18 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:e651a2f88c21: avformat/utils: Fix number suffixes in tb_unreliable()
[02:02:19 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:364bdddaad04: swresample/dither: Cleanup number suffixes
[02:02:20 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:201d626bb90e: avformat/matroskadec: Fix number suffixes
[02:02:21 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:633ce6baaaab: avformat/smacker: Fix number suffix
[02:02:22 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:6862970dbfd8: avformat/omadec: fix number suffix
[02:02:23 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:5feffd62688b: avcodec/h264_cabac: use int instead of long for mbb_xy
[02:02:24 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:37723e0d0c3e: avcodec/mpegvideo_enc: Fix number suffixes in rc_buffer_size calculation
[02:02:25 CEST] <cone-837> ffmpeg 03wm4 07release/2.1:6e7f183ae632: avformat/tta: fix crash with corrupted files
[02:02:26 CEST] <cone-837> ffmpeg 03wm4 07release/2.1:28f303542e90: avformat/mpc8: fix hang with fuzzed file
[02:02:27 CEST] <cone-837> ffmpeg 03wm4 07release/2.1:55b75ece7043: avformat/mpc8: fix broken pointer math
[02:02:28 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:af0544ca3d40: avformat/mpc8: Use uint64_t in *_get_v() to avoid undefined behavior
[02:02:29 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:a6ba4c1116c1: avcodec/mjpegdec: Check number of components for JPEG-LS
[02:02:30 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:b844584c1017: avcodec/mjpegdec: Check escape sequence validity
[02:02:31 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:813054c4bd5d: swscale/utils: Limit filter shifting so as not to read from prior the array
[02:02:32 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:07a55344e636: avformat/thp: Check av_get_packet() for failure not only for partial output
[02:02:33 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:17ecc8a7716e: avcodec/h264_ps: More completely check the bit depths
[02:02:34 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:01e2e746bad3: avcodec/h264: Be more strict on rejecting pps/sps changes
[02:02:35 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:cab930604011: avcodec/h264_slice: Do not change frame_num after the first slice
[02:02:36 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:6c67cc2ad119: avcodec/h264_slice: Check picture structure before setting the related fields
[02:02:37 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:6ab48096f5bd: avcodec/h264_slice: ignore SAR changes in slices after the first
[02:02:38 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:1aea2213a686: avformat/idcin: Use 64bit for ret to avoid overflow
[02:02:39 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:1480d9b3d39b: avformat/gxf: Use 64bit for res to avoid overflow
[02:02:40 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:3b17f32ec3cc: avformat/mvdec: Use 64bit for ret to avoid overflow
[02:02:41 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:f8b6ba5574c7: avformat/vqf: Use 64bit for ret to avoid overflow
[02:02:42 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:94ebfef2fb69: avformat/omadec: Use 64bit for ret to avoid overflow
[02:02:43 CEST] <cone-837> ffmpeg 03Anton Khirnov 07release/2.1:d005972995ee: h264: initialize H264Context.avctx in init_thread_copy
[02:02:44 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:b62a3478e92b: avcodec/x86/mlpdsp_init: Simplify mlp_filter_channel_x86()
[02:02:45 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:d0da72ebb04a: avcodec/a64multienc: use av_frame_ref instead of copying the frame
[02:02:46 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:91ced1608cf4: avcodec/a64multienc: don't set incorrect packet size
[02:02:47 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:1a8f9f0e5898: avcodec/a64multienc: fix use of uninitialized values in to_meta_with_crop
[02:02:48 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:a79e5c994cf9: swscale/utils: More carefully merge and clear coefficients outside the input
[02:02:49 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:7afb16c9a1c8: avcodec/snowdec: Fix ref value check
[02:02:50 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:232b1f83de57: avcodec/h264: Only reinit quant tables if a new PPS is allowed
[02:02:51 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:41ca0489ba92: avcodec/zmbv: Check len before reading in decode_frame()
[02:02:52 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:c417b7b5663b: avcodec/hevc_ps: Sanity checks for some log2_* values
[02:02:53 CEST] <cone-837> ffmpeg 03James Cowgill 07release/2.1:11141fb9ff32: mips/acelp_filters: fix incorrect register constraint
[02:02:54 CEST] <cone-837> ffmpeg 03Dyami Caliri 07release/2.1:b49f8de4ec33: Fix buffer_size argument to init_put_bits() in multiple encoders.
[02:02:55 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:cd74b344c235: avformat/adxdec: check avctx->channels for invalid values
[02:02:56 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:81196b6d6018: avformat/bit: check that pkt->size is 10 in write_packet
[02:02:57 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:8a9d5a8140d5: avformat/bit: only accept the g729 codec and 1 channel
[02:02:58 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:dfc3cd73ff55: avcodec/mjpegdec: Skip blocks which are outside the visible area
[02:02:59 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:0b0a8cd133c7: swscale/utils: clear formatConvBuffer on allocation
[02:03:00 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:86c024ea9e65: avformat/flvenc: check that the codec_tag fits in the available bits
[02:03:01 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:dc2d15360cd7: webp: ensure that each transform is only used once
[02:03:02 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:3f30c49f7ed0: avcodec/utils: Align YUV411 by as much as the other YUV variants
[02:03:03 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:6e43bb2dc29c: avcodec/tiff: move bpp check to after "end:"
[02:03:04 CEST] <cone-837> ffmpeg 03Vittorio Giovara 07release/2.1:803db3b6fe86: aic: Fix decoding files with odd dimensions
[02:03:05 CEST] <cone-837> ffmpeg 03Federico Tomassetti 07release/2.1:0b84dbeca95d: mdec: check for out of bounds read
[02:03:06 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:66a1ed96bf3d: avcodec/rv10: check size of s->mb_width * s->mb_height
[02:03:07 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:3f5a2831744c: avcodec/webp: validate the distance prefix code
[02:03:08 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:61d5ec7c32b8: avformat/rm: limit packet size
[02:03:09 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:9a52cbdb0097: ffmdec: fix infinite loop at EOF
[02:03:10 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:907d7d972ada: ffmdec: limit the backward seek to the last resync position
[02:03:11 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:fa5ec2c354af: avcodec/options_table: remove extradata_size from the AVOptions table
[02:03:12 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:41dffa883a17: roqvideoenc: set enc->avctx in roq_encode_init
[02:03:13 CEST] <cone-837> ffmpeg 03Xiaohan Wang 07release/2.1:0b25a4d253ba: Fix read-after-free in matroska_read_seek().
[02:03:14 CEST] <cone-837> ffmpeg 03Martin Storsjö 07release/2.1:436f530a51ab: arm: Suppress tags about used cpu arch and extensions
[02:03:15 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:560b3895387e: avcodec/012v: Check dimensions more completely
[02:03:16 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:95d92601771b: avcodec/012v: redesign main loop
[02:03:17 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:2aa21e8d9551: ffmdec: make sure the time base is valid
[02:03:18 CEST] <cone-837> ffmpeg 03Rainer Hochecker 07release/2.1:eface550b9d3: hevc: delay ff_thread_finish_setup for hwaccel
[02:03:19 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:88f2d31d4e92: avformat/mov: Use sizeof(filename) instead of a literal number
[02:03:20 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:f000df4ce2a7: avformat/mov: Check for string truncation in mov_open_dref()
[02:03:21 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:5922e5a84eb3: avformat/mov: Disallow ".." in dref unless use_absolute_path is set
[02:03:22 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:5da5e47a1797: avcodec/dnxhddec: Check that the frame is interlaced before using cur_field
[02:03:23 CEST] <cone-837> ffmpeg 03Anton Khirnov 07release/2.1:e4f32ef80633: hevc: make the crop sizes unsigned (cherry picked from commit c929659bdd7d2d5848ea52e685a3164c7b901bb0)
[02:03:24 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:5628a5406299: avcodec/hevc_ps: More complete window reset
[02:03:25 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:09a5a754fe56: avcodec/hevc_ps: Check cropping parameters more correctly
[02:03:26 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:99a692498370: avcodec/msrledec: restructure msrle_decode_pal4() based on the line number instead of the pixel pointer
[02:03:27 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:44d447f31cf9: avutil/pca: Check for av_malloc* failures
[02:03:28 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:dcf23f12979e: avcodec/h264_refs: Do not set reference to things which dont exist
[02:03:29 CEST] <cone-837> ffmpeg 03Timothy Gu 07release/2.1:ba7ccddb82dc: tests/fate.sh: report different status for different errors
[02:03:30 CEST] <cone-837> ffmpeg 03Timothy Gu 07release/2.1:a43f9e6895fe: tests: Fix test name for pixfmts tests(cherry picked from commit e1ee0521a698809ed216e9e5c11bd2bbb466ed04)
[02:03:31 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:38c8264d193c: avcodec/aacdec: Fix storing state before PCE decode
[02:03:32 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:12e005f7e7a9: msrledec: use signed pixel_ptr in msrle_decode_pal4
[02:03:33 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:11752d17b8b4: aacdec: consistently use avctx for logging in decode_eld_specific_config
[02:03:34 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:13178541369f: aasc: return correct buffer size from aasc_decode_frame
[02:03:35 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:49ff079f0c0e: aacpsy: avoid psy_band->threshold becoming NaN
[02:03:36 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:307c5cb9d4cc: ac3: validate end in ff_ac3_bit_alloc_calc_mask
[02:03:37 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:bfd65092a2b7: alsdec: ensure channel reordering is reversible
[02:03:38 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:455bc87c8f00: avcodec/alsdec: Use av_mallocz_array() for chan_data to ensure the arrays never contain random data
[02:03:39 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:d18f8959b3c6: alsdec: validate time diff index
[02:03:40 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:74e714f81597: avformat/utils: Ensure that AVFMT_FLAG_CUSTOM_IO is set before use
[02:03:41 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:0b5405c443ec: alsdec: check sample pointer range in revert_channel_correlation
[02:03:42 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:3339bae2197a: mpeg4videodec: only allow a positive length
[02:03:43 CEST] <cone-837> ffmpeg 03Vittorio Giovara 07release/2.1:bb95df33a0d4: lavf: Reset global flag on deinit
[02:03:44 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:89b83042a9c5: alsdec: only adapt order for positive max_order
[02:03:45 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:3144044e0142: alac: reject rice_limit 0 if compression is used
[02:03:46 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:fb5f3241e40d: tests/fate-run: do not attempt to parse tiny_psnrs output if it failed
[02:03:47 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:be7dc34bcf00: apedec: set s->samples only when init_frame_decoder succeeded
[02:03:48 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:60201e27efa6: apedec: prevent out of array writes in decode_array_0000
[02:03:49 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:0397e998b3aa: ffmpeg: remove incorrect network deinit
[02:03:50 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:ac323fa46330: nutdec: check for negative frame rate in decode_info_header
[02:03:51 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:84981c8a87a3: nutdec: check chapter creation in decode_info_header
[02:03:52 CEST] <cone-837> ffmpeg 03Andreas Cadhalpun 07release/2.1:e7cb5d41d1d6: nutdec: fix illegal count check in decode_main_header
[02:10:40 CEST] <Compn> release time heh
[02:26:48 CEST] <cone-837> ffmpeg 03Michael Niedermayer 07release/2.1:68f89b8264d4: Update for 2.1.8
[04:02:37 CEST] <cone-549> ffmpeg 03Michael Niedermayer 07master:d2184bf3b653: avfilter/lavfutils: disable frame threads when decoding a single image
[08:48:26 CEST] <rcombs> so I implemented Secure Transport
[08:53:27 CEST] <nevcairiel> do show
[09:12:34 CEST] <rcombs> nevcairiel: https://gist.github.com/81f621317bcec3c02306
[09:13:52 CEST] <nevcairiel> that looks pretty straight forward
[09:17:50 CEST] <rcombs> verification works
[09:17:59 CEST] <rcombs> the most complex part is really the PEM reading
[09:18:26 CEST] <rcombs> and I haven't done anything for listening, or for cert_file/key_file yet
[09:18:28 CEST] <nevcairiel> yeah its kinda annoying that there are options to read a PEM <.<
[09:18:47 CEST] <rcombs> the other 2 libs just take a filename and go "OK thanks"
[09:19:00 CEST] <rcombs> Secure Channel wants an array of DER-formatted certs
[09:20:07 CEST] <rcombs> by default, `-verify 1` means "verify against the CAs in the system keychain"
[09:26:03 CEST] <rcombs> when not configured with OS X or Windows's builtin TLS libs, curl sets a default cert bundle at configure time; it can be set on the command line, but by default it's the first of these paths that exists and is a regular file: /etc/ssl/certs/ca-certificates.crt, /etc/pki/tls/certs/ca-bundle.crt, /usr/share/ssl/certs/ca-bundle.crt, /usr/local/share/certs/ca-root.crt, /etc/ssl/cert.pem
[09:32:15 CEST] <wm4> rcombs: pretty nice, though you'd win bonus points if you move it to a separate file
[09:32:50 CEST] <nevcairiel> not sure th at works
[09:32:54 CEST] <rcombs> wm4: what, move the PEM reading and such to lava?
[09:32:56 CEST] <rcombs> *lavu
[09:33:18 CEST] <nevcairiel> the core tls code is in a #ifdef inside the big tls function
[09:33:25 CEST] <nevcairiel> could move some helper stuff i guess, but other than that..
[09:34:42 CEST] <wm4> looking at tls.c in git, it looks like a rather misguided attempt at sharing code
[09:35:07 CEST] <rcombs> wm4: it was a bit awkward to add to, yeah
[09:35:27 CEST] <rcombs> felt like there was one implementation, and then someone crammed another one in
[09:35:30 CEST] <rcombs> and now I'm doing it again!
[09:35:44 CEST] <rcombs> I should probably test it against more servers, and make sure verification works properly in a variety of attack scenarios
[12:09:22 CEST] <penthief> Hello, I put a small patch on the mailing list, I assume that someone needs to approve it because it is my first submission.
[12:11:40 CEST] <wm4> penthief: you need to subscribe to the mailing list to send mails without waiting for moderator approval
[12:12:49 CEST] <penthief> Ah, OK. Now subscribed.
[13:04:12 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07n2.1.8:HEAD: avfilter/lavfutils: disable frame threads when decoding a single image
[14:31:16 CEST] <cone-243> ffmpeg 03Nedeljko Babic 07master:a1c7fe431c50: libavutil/softfloat: exponent adjusted for aac fixed point dec
[15:03:29 CEST] <cone-243> ffmpeg 03Nedeljko Babic 07master:7bab28147533: libavutil/softfloat: Added av_normalize_sf in av_add_sf
[15:17:08 CEST] <cone-243> ffmpeg 03Nedeljko Babic 07master:1fae26830797: libavutil/softfloat: Add functions.
[16:24:30 CEST] <cousin_luigi> Greetings.
[17:17:51 CEST] <Timothy_1u> rcombs: why doesn't lavf just use libcurl or something like that?
[17:21:49 CEST] <wm4> Timothy_1u: because NIH?
[17:52:18 CEST] <Compn> libcurl does hls ? :P
[17:58:38 CEST] <Compn> so whos going to the IETF meeting on ffv1? :P
[17:59:24 CEST] <wm4> who said anythign about HLS
[17:59:50 CEST] <BBB> michaelni: tree for merging (if patches are OKed) at https://github.com/rbultje/ffmpeg/commits/vp9-profile1-wip
[18:50:08 CEST] <michaelni> BBB, merging this leads to conflicts and duplicate commits, can you rebase it so it merges cleanly? or should i cherry pick the commits ?
[19:10:09 CEST] <Timothy_1u> wm4: probably
[19:10:57 CEST] <wm4> not just probably
[19:13:32 CEST] <Timothy_1u> BBB: Is "vp9: copy bug in libvpx for 4:2:2 chroma bs=8x4/4x4 prediction." reported upstream anywhere?
[19:13:48 CEST] <Timothy_1u> If so it would be cool to reference the URL in the commit message
[20:57:25 CEST] <canbal> Anyone know how to register the decoder for timed_id3? I dont want to compile the libs and register all codecs using av_register_all(). However without this avformat_find_stream_info() hangs
[20:58:02 CEST] <BBB> michaelni: Ill rebase, give me a few hours
[21:00:46 CEST] <BBB> Timothy_1u: yes, I reported it and my local branch has a comment to indicate the upstream bug report
[21:01:05 CEST] <BBB> Timothy_1u: but that was after I sent the original patches, sorry for that
[21:02:05 CEST] <BBB> michaelni: updated (I had no conflicts on rebase...)
[21:02:24 CEST] <BBB> Timothy_1u: https://code.google.com/p/webm/issues/detail?id=993
[21:02:25 CEST] <Timothy_1u> BBB: np
[21:14:44 CEST] <Compn> damn
[21:14:49 CEST] <Compn> downloaded my first hevc rip
[21:14:53 CEST] <Compn> whyyyyyyyyyyyyyy hevc why
[21:22:38 CEST] <rcombs> Compn: because people want to be in the future but don't realize that we're not actually there yet
[21:32:44 CEST] <cone-243> ffmpeg 03Vignesh Venkatasubramanian 07master:e2784a1d9660: lavf/webm_chunk: Use dyn_buf to write chunks
[21:34:09 CEST] <jamrial> BBB: did you see the threading related vp9 failures? http://fate.ffmpeg.org/report.cgi?time=20150430053919&slot=x86_64-archlinux…
[21:34:46 CEST] <jamrial> seems to happen only when threads >2
[21:36:44 CEST] <michaelni> BBB, ill merge the vp9 stuff in 24h (once all the fate samples have reached all clients)
[21:37:10 CEST] <BBB> jamrial: no, any specific samples? or any?
[21:38:22 CEST] <BBB> jamrial: for show-prev-frame, file bug, Ill look, I think I know what it is
[21:38:24 CEST] <jamrial> BBB: just those three tests as far as i could see
[21:38:37 CEST] <BBB> for intraonly, I have no idea, file seaprate bug and Ill put it in my queue
[21:38:41 CEST] <BBB> I dont think its related...
[21:59:32 CEST] <jamrial> BBB: ^
[21:59:40 CEST] <BBB> ty
[21:59:43 CEST] <BBB> I already found 1 of the 2
[21:59:45 CEST] <BBB> the other Im on
[22:03:40 CEST] <BBB> jamrial: fixed (both)
[22:03:42 CEST] <BBB> jamrial: see ML
[22:15:09 CEST] <cone-243> ffmpeg 03Luca Barbato 07master:82a10225f817: xcbgrab: Do not assume the non shm image data is always available
[22:15:10 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:dc83733f2bf2: Merge commit '82a10225f817b2612fdd2b23af9d4f0a3408df3b'
[22:22:45 CEST] <cone-243> ffmpeg 03Luca Barbato 07master:e8c4db0d4d07: xcbgrab: Validate the capture area
[22:22:46 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:f5c5aa968c3c: Merge commit 'e8c4db0d4d07738fed716b1d2f20c85aac944641'
[22:30:09 CEST] <cone-243> ffmpeg 03Luca Barbato 07master:06f4b1e37a08: avplay: Do not print a possibly uninitialized value
[22:30:10 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:7ad528cf23da: Merge commit '06f4b1e37a08f3fd269ecbfeb0181129e5bfc86e'
[22:41:23 CEST] <cone-243> ffmpeg 03James Almer 07master:39fbb27ec3a3: avutil/softfloat_tables: add missing stdint.h include
[23:32:27 CEST] <cone-243> ffmpeg 03Ronald S. Bultje 07master:5935513c0ed1: vp9: fix show-existing-frames for multi-threading.
[23:44:40 CEST] <cone-243> ffmpeg 03Vignesh Venkatasubramanian 07master:ccb8f674995d: lavf/webm_chunk: Fix a memory leak.
[00:00:00 CEST] --- Fri May 1 2015
1
0
[00:05:12 CEST] <kepstin-laptop> cool, that makes it easy on the encoder side.
[00:14:01 CEST] <maqr> kepstin-laptop: yeah, a little bit worse for the user though in terms of switching quality quickly
[00:16:23 CEST] <maqr> i wonder if i'd get different behavior with shorter -hls_time
[00:18:51 CEST] <nathanpickles> I am getting an error: http://hastebin.com/ahijivafov.txt
[00:19:18 CEST] <nathanpickles> http://hastebin.com/ahijivafov
[00:20:02 CEST] <maqr> kepstin-laptop: if i'm using a bufsize of 5 sec, and the last segment is only 2 sec... it should still be fine right?
[00:20:05 CEST] <maqr> i assume that's handled somehow
[00:22:00 CEST] <nathanpickles> I think the problem is with -vf scale=-1:360
[00:23:22 CEST] <maqr> actually, nevermind, i'm using a bufsize of 1 sec, it'll be safe and always work
[02:06:19 CEST] <Miesco> Hi
[02:07:14 CEST] <Miesco> I did ffmpeg -i f.mkv -vf subtitles=f.mkv -o f.mp4; how come the quality is decreased significantly?
[02:10:02 CEST] <Miesco> I tried this: @debian ffmpeg$ ./configure --enable-libass --enable-nonfree --enable-libfaac --enable-gpl --enable-libx26
[02:10:07 CEST] <Miesco> Will this help?
[02:21:12 CEST] <Miesco> ~/src/ffmpeg/ffmpeg -i Crouching\ Tiger\ Hidden\ Dragon\ \(2000\)\ 720p.BRrip.Sujaidr\ \(dual\ audio\ chi\,eng\).mkv -c:v libx264 -preset slow -crf 22 -c:a copy -vf subtitles="Crouching\ Tiger\ Hidden\ Dragon\ \(2000\)\ 720p.BRrip.Sujaidr\ \(dual\ audio\ chi\,eng\).mkv" Crouching_Tiger_Hidden_Dragon_\(2000\)_burn.mp4
[02:21:17 CEST] <Miesco> Thats what I typed
[02:21:21 CEST] <Miesco> Is that good quality?
[02:27:42 CEST] <smo_> hi
[02:28:31 CEST] <smo_> i try to convert a m4a 253 kb/s , when i use ffmpeg -i .... -f mp4 it show 128kb/s how can i keep the bitrate ? (if it s not normal)
[04:00:49 CEST] <kyleogrg> hey
[04:01:27 CEST] <kyleogrg> to reduce video file size, is it better to reduce the resolution or the bit rate? what's a good ratio?
[04:16:17 CEST] <kepstin> I assume you mean reducing resolution & bitrate vs. reducing only bitrate
[04:17:25 CEST] <kyleogrg> in other words, when a video encode size is too large, what should be reduced?
[04:17:40 CEST] <jookiyaya> kyleogrg you cannot reduce bitrate per se
[04:17:56 CEST] <kepstin> doesn't seem that hard to measure; try doing a (two-pass) encode to the same bitrate with one video downscaled, one video not downscaled, see which looks better.
[04:18:01 CEST] <kyleogrg> if i drastically reduced the resolution, that would reduce output size.
[04:18:12 CEST] <jookiyaya> reducing resolution results in "reducing bitrate"
[04:18:17 CEST] <jookiyaya> kyleogrg you cannot reduce bitrate per se
[04:18:35 CEST] <kyleogrg> hmm, but i'm setting the bitrate...
[04:18:43 CEST] <kepstin> there's nothing stopping you from encoding a smaller video at a higher bitrate than a larger video...
[04:19:08 CEST] <kyleogrg> exactly, so how do i know the resolution-bitrate ratio
[04:19:46 CEST] <kyleogrg> does higher res and lower bitrate look better than lower res and higher bitrate?
[04:19:52 CEST] <kepstin> depends on the video
[04:19:59 CEST] <kepstin> try it and see with your video.
[04:20:00 CEST] <jookiyaya> reducing resolution results in "reducing bitrate"
[04:20:25 CEST] <jookiyaya> kyleogrg your question makes no sense
[04:20:39 CEST] <kyleogrg> jookiyaya: what do you mean exactly? because i can set the "bitrate value" right?
[04:20:56 CEST] <jookiyaya> for video?
[04:21:03 CEST] <kepstin> if you reduce the bitrate, you'll get a smaller video. resolution doesn't come into it at all...
[04:21:14 CEST] <kyleogrg> jookiyaya: yeah, it's a video
[04:21:20 CEST] <jookiyaya> what video codec?
[04:21:29 CEST] <kyleogrg> two-pass x265
[04:21:35 CEST] <kepstin> depending on the video source, it might have better quality or might not have better quality if you downscale it before encoding to a particular bitrate.
[04:21:42 CEST] <jookiyaya> don't use that setting
[04:21:47 CEST] <jookiyaya> use constant quality
[04:22:13 CEST] <kyleogrg> kepstin: you're saying downscaling won't change the file size? only bitrate?
[04:22:32 CEST] <kepstin> kyleogrg, downscaling doesn't directly change the filesize or bitrate (filesize and bitrate are the same thing)
[04:22:35 CEST] <c_14> downscaling on its own won't change the file size or the bitrate
[04:22:54 CEST] <kyleogrg> then all it does it adjust "quality" right?
[04:22:56 CEST] <jookiyaya> c_14 yes it will
[04:23:22 CEST] <jookiyaya> c_14 lowering resolution will always results in lower bitrate/filesize
[04:23:26 CEST] <c_14> jookiyaya: no. I can downscale a video and increase bitrate at the same time.
[04:23:51 CEST] <kyleogrg> c_14: yeah, but if you keep bitrate the same and downscale, the size reduces?
[04:23:58 CEST] <jookiyaya> who uses "bitrate" settings on video these days
[04:23:59 CEST] <c_14> no
[04:24:01 CEST] <kepstin> kyleogrg, bitrate and size *are the same thing*
[04:24:02 CEST] <c_14> because the bitrate is the same
[04:24:08 CEST] <c_14> bitrate is bits per second
[04:24:16 CEST] <c_14> not bits per pixel per second
[04:24:34 CEST] <kyleogrg> ok. so what is the result of downscaling?
[04:24:35 CEST] <jookiyaya> c_14 why don't you use constant quality
[04:25:19 CEST] <kepstin> kyleogrg, if you downscale, then the encoder can use more bits on each pixel, which in some videos might change the perceived "quality"
[04:25:41 CEST] <kepstin> (for better or worse, hard to say.)
[04:25:49 CEST] <kyleogrg> uh-huh, ok i got it
[04:25:56 CEST] <c_14> jookiyaya: I usually (but not always) do, I'm just trying to keep you from expressing things as absolute truths that can't be expressed in absolute terms.
[04:26:01 CEST] <c_14> But what kepstin said
[04:26:28 CEST] <kyleogrg> ok, different subject
[04:26:30 CEST] <kyleogrg> vp9
[04:26:46 CEST] <kyleogrg> vp9 vs x265
[04:27:08 CEST] <jookiyaya> kyleogrg just use constant quality
[04:27:10 CEST] <kyleogrg> any strong opinions?
[04:27:12 CEST] <kepstin> to be honest, in a choice between vp9 and x265, i'd pick x264.
[04:27:27 CEST] <jookiyaya> kepstin why? x264 iso ld
[04:27:32 CEST] <jookiyaya> kepstin why? x264 is old
[04:27:49 CEST] <c_14> It's still the best thing out there for _many_ use-cases.
[04:27:51 CEST] <kepstin> vp9 and x265 are too new :)
[04:27:51 CEST] <jookiyaya> vp9/x265 is newer/better
[04:27:57 CEST] <kyleogrg> jookiyaya: why is constant quality preferable?
[04:28:17 CEST] <kyleogrg> kepstin: you mean they haven't gotten all the bugs out?
[04:28:42 CEST] <kepstin> kyleogrg, mostly they haven't spent as much time finding optimizations and encoding gains as the x264 devs have
[04:29:03 CEST] <jookiyaya> [19:22] <jookiyaya> handbrake recommends to use Constant quality yet why do i see so many people use "bitrate/2pass" settings
[04:29:03 CEST] <jookiyaya> [19:25] <dkeav> old habits die hard
[04:29:03 CEST] <jookiyaya> [19:26] <jookiyaya> what is the reason people does not use CQ
[04:29:03 CEST] <jookiyaya> [19:28] <dkeav> because people has the stupids
[04:29:21 CEST] <c_14> x265 and vp9 aren't necessarily bad, x264 is just too damn good
[04:29:44 CEST] <kepstin> if you're encoding to a specific target filesize/bitrate (which are the same thing), 2-pass mode still makes sense...
[04:29:48 CEST] <kyleogrg> jookiyaya: ok, but why exactly is it better? 2pass lets you target a size
[04:30:04 CEST] <jookiyaya> why do you need targetted size?
[04:30:32 CEST] <kepstin> but there's not much cause to do that nowadays unless you're e.g. encoding content for physical disks or something.
[04:30:40 CEST] <c_14> kyleogrg: using a crf allows the encoder to choose where to spend more bits and where to save them. ie if you have some scenes with lots of motion and some with lots of nothing it averages better
[04:30:49 CEST] <kyleogrg> jookiyaya: basically you're saying CQ is better, unless i need to target a size, right?
[04:31:06 CEST] <c_14> kyleogrg: or you're trying to stream and have bandwidth limitations
[04:31:24 CEST] <kyleogrg> c_14: sure. but 2pass also will distribute bits this way, right?
[04:31:24 CEST] <jookiyaya> kyleorgrg i don't see any reason these days that somebody would require target size
[04:31:43 CEST] <kyleogrg> jookiyaya: ok
[04:32:18 CEST] <kepstin> kyleogrg, in x264 (other codecs differ), two-pass average bitrate mode and crf mode give the exact same quality for a given bitrate.
[04:32:40 CEST] <kepstin> but crf mode lets you pick the quality, and 2pass mode lets you pick the bitrate
[04:32:52 CEST] <kyleogrg> yes
[04:33:23 CEST] <kepstin> (if you start using vbv buffers for streaming, i'm not entirely sure how that interacts)
[04:33:49 CEST] <kyleogrg> many seem to still prefer x264. although x265 encodes smaller sizes at same quality (right?), i guess it's not as optimized yet
[04:34:12 CEST] <kepstin> x265 can encode smaller sizes at the same quality if you wait longer.
[04:34:19 CEST] <kepstin> a *lot* longer.
[04:34:24 CEST] <kyleogrg> kepstin: yeeees
[04:35:20 CEST] <kyleogrg> and with this kind of thing, will future tweaks (to libx265) make it encode much faster?
[04:35:41 CEST] <kepstin> much faster? probably not.
[04:35:52 CEST] <kyleogrg> yes, the only hope is to have a very fast computer
[04:36:07 CEST] <kepstin> the reason the h.265 standard can compress better than h.264 is that it has more choices the encoder can make on how to compress things
[04:36:18 CEST] <kyleogrg> yes, makes sense
[04:36:22 CEST] <kepstin> in order to determine which choice is good, the encoder has to spend more time if there are more choices
[04:36:51 CEST] <kyleogrg> kepstin: like a chess AI looking farther and farther ahead
[04:37:18 CEST] <kyleogrg> it's exponential
[04:37:33 CEST] <kyleogrg> i wonder if vp9's encoding speed is about the same
[04:37:41 CEST] <jookiyaya> is there really an advantage of using slow setting on x265 ?
[04:37:43 CEST] <kepstin> so the optimizations that can be made are mostly on finding things that are heuristics - basically "the human eye sees motion in this kind of way, so if there's that type of motion, prefer this option"
[04:38:15 CEST] <kyleogrg> kepstin: yeah, which x264 is mature in and x265 is a mere child
[09:41:37 CEST] <kagami_> Hi guys. Probably noob question, but is it possible to use different than the current pixel component in lutrgb filter (or some other similar filter)? I'm trying to set alpha component depending on the red component like this: lutrgb=a=if(r,val,0) but it doesn't work...
[11:28:20 CEST] <Richlv> can i add metadata to a file without encoding/copying it ?
[11:28:39 CEST] <Richlv> the examples on the wiki and elsewhere use input/output files
[11:30:52 CEST] <Dark-knight> if i do a system restore on my computer to an earlier state, will that revert my firefox cookies too?
[11:34:12 CEST] <Anoia> system restore (assuming windows) shouldn;t touch user files, but I can't say for certain
[11:38:07 CEST] <Richlv> http://stackoverflow.com/questions/11474532/how-to-change-metadata-with-ffm… says that can't be done...
[12:03:51 CEST] <klaxa|work> Richlv: you cannot really edit files in-place
[12:03:59 CEST] <klaxa|work> you will have to use a temporary file
[12:04:21 CEST] <klaxa|work> (that also adds security against accidentally overwriting sensible data)
[12:05:12 CEST] <Richlv> klaxa|work, thanks, that's what i started doing, yes :)
[12:05:53 CEST] <Richlv> in this case i'm already operating on a copy, so overwriting that would not be a huge issue, but yeah
[13:12:29 CEST] <fffan> does mp4 has 32 bit version and 64 bit version?
[13:13:01 CEST] <klaxa|work> no
[13:13:46 CEST] <fffan> when I muxing mp4 in 32 bit ffmpeg, it crashed when the mp4 is larger than 4G
[13:13:55 CEST] <fffan> 64 bit is ok
[13:16:26 CEST] <klaxa|work> i don't know how things are handled internally, but it sounds like an address-space issue
[13:16:41 CEST] <klaxa|work> it's probably not a problem with mp4 itself
[13:17:05 CEST] <fffan> address space should only 2G for windows user mode application
[13:17:12 CEST] <fffan> my case is 4G
[13:17:44 CEST] <fffan> just look at open broadcast soft, it has a macro
[13:17:54 CEST] <fffan> #ifdef USE_64BIT_MP4 fileOut.OutputQword(0); #endif
[13:18:09 CEST] <fffan> what is USE_64BIT_MP4?
[13:19:05 CEST] <klaxa|work> oh?
[13:19:26 CEST] <fffan> ?
[13:19:39 CEST] <klaxa|work> maybe there is "64bit mp4" after all
[13:19:51 CEST] <fffan> just google USE_64BIT_MP4
[13:20:17 CEST] <fffan> so what is 64 bit mp4? can anyone tell me?
[13:20:48 CEST] <klaxa|work> i can't because i don't know
[13:21:19 CEST] <klaxa|work> i can only guess that it could be something with addressing data within the mp4 file internally
[13:21:25 CEST] <klaxa|work> like pages for a book
[13:21:29 CEST] <fffan> so klaxa, could you just google USE_64BIT_MP4 and give me some tip?
[13:21:32 CEST] <Anoia> does anyone know of an mercurial clone of the ffmpeg git repo?
[13:21:46 CEST] <Anoia> I have ~4 hours left on a convert :)
[13:21:54 CEST] <fffan> and how to set 64 bit mode mp4 for ffmpeg
[13:23:09 CEST] <klaxa|work> fffan: the easiest would probably be to just use 64 bit ffmpeg
[13:23:38 CEST] <klaxa|work> if that is no option, please file a bugreport, also address the USE_64BIT_MP4 thing from OBS
[13:24:10 CEST] <fffan> yes, it is the easiest way, but I wanna know why? and I believe there are a lot of people still using 32 bit os
[13:24:56 CEST] <fffan> maybe ffmpeg already solved that problem, I just I don't know how to use it correctly
[13:44:56 CEST] <]R[> is there any way to override the max analyzeduration ?
[16:00:55 CEST] <Demos> Hey so I just built ffmpeg on windows using msys2 and mingw32. I used --enable-nonfree --enable-nvenc but when I try and encode a video with -c:v nvenc I get "Failed loading CUDA library", which seems to be printed on line 356 of nvenc.c if the call to LoadLibrary or dlopen fails
[16:04:01 CEST] <Demos> nvcuda.dll is in c:\windows\System32 and c:\windows\SysWOW64
[16:14:31 CEST] <edsonmenegatti> Hi guys, I'm trying to set the metadata of a video stream with the avformat library, however the following code fails to do it http://pastebin.com/BHqw8ai2. Any thoughts on what could be the issue?
[16:22:30 CEST] <mtcjayne> What are some things that still aren't ready regarding DASH playback?
[16:23:06 CEST] <mtcjayne> Is there a timeline or bug tracker milestone of sorts I can use to track the progress?
[16:28:42 CEST] <cousin_luigi> Greetings.
[16:31:45 CEST] <BtbN> mtcjayne, you mean playing das as input format, or the dash muxer?
[16:31:50 CEST] <BtbN> +h
[16:37:04 CEST] <mtcjayne> A Kodi/XBMC developer stated that there is no demuxer in ffmpeg and that until there is Kodi will not be able to support DASH streams. I'm trying to figure out the accuracy of that statement, as he didn't give any citations.
[16:37:44 CEST] <JEEBsv> "DASH" is not as simple as that generally
[16:37:54 CEST] <JEEBsv> I mean, there is a demuxer for the container parts
[16:38:21 CEST] <JEEBsv> but how you find the container parts and if you need to load extra files...
[16:39:23 CEST] <mtcjayne> I know of a library called libdash, whose developer has a reference player that uses ffmpeg.
[16:40:06 CEST] <mtcjayne> Does anyone know of it or have any idea if that's remotely relevant to this type of discussion?
[16:42:51 CEST] <BtbN> basicaly you need a pre-demuxer for dash. Something that parses the xml, and pieces together the resulting mp4, and passes it to the mp4/mov demuxer.
[16:43:03 CEST] <BtbN> No such code currently exists in ffmpeg.
[16:43:52 CEST] <mtcjayne> Is this code likely to be included? What you're describing almost sounds like it's outside ffmpeg's scope.
[16:45:08 CEST] <BtbN> There is no such code that could be included.
[16:45:21 CEST] <BtbN> Someone has to write it first.
[16:45:32 CEST] <BtbN> If you do so, it could be merged.
[16:45:59 CEST] <mtcjayne> That was my concern. It seems to me a lot of people are sitting on their hands hoping it's someone else's job.
[16:46:27 CEST] <BtbN> A lot of people don't need a dash demuxer, so why would they be hoping for that?
[16:46:35 CEST] <mtcjayne> Oh, I had to scroll down. I thought you were saying it WON'T be part of ffmpeg.
[16:48:09 CEST] <mtcjayne> But in response to your comment, I agree. It's a limited use case outside of the web (as far as I can tell) and I would have preferred it be worked on by the small apps that will benefit (Kodi, Kodi addons, etc)
[16:48:54 CEST] <JEEBsv> well the web really doesn't even seem to be using "proper" DASH
[16:49:02 CEST] <JEEBsv> rather they are loading random files from JS
[16:49:11 CEST] <JEEBsv> like 'tube for example
[16:49:31 CEST] <BtbN> youtube is using DASH, and a huge bunch of JavaScript to feed it to the browser.
[16:49:49 CEST] <BtbN> As Browsers don't support JS, but a JavaScript api to feed them with mp4 parts.
[16:49:58 CEST] <BtbN> *don't support DASH.
[16:50:25 CEST] <JEEBsv> yeah, thus "proper" DASH isn't really used on the web
[16:50:36 CEST] <JEEBsv> other than in educational/academic spheres
[16:50:44 CEST] <BtbN> DASH is some scary thing anyway
[16:50:45 CEST] <JEEBsv> and the part of it that is used is already supported
[16:51:06 CEST] <BtbN> mp4 parts... the last container format I'd think about for that.
[16:51:15 CEST] <JEEBsv> what you need is something like youtube-dl that actually then supports the random ways those services are providing you the media parts
[16:51:27 CEST] <mtcjayne> Right. So I'm thinking Kodi needs to implement its own (or someone else's) similar library to get (is it elementary?) streams passed to ffmpeg in their software?
[16:51:36 CEST] <BtbN> It is mp4
[16:51:42 CEST] <JEEBsv> not elementary since the streams are in a container
[16:51:50 CEST] <JEEBsv> 'tube does mp4 and matroska
[16:52:01 CEST] <BtbN> mp4, cut into pieces. With one special piece that contains the moov atom.
[16:52:11 CEST] <JEEBsv> (which is why they implemented the muxer for their matroska "DASH" in ffmpeg IIRC)
[16:52:31 CEST] <JEEBsv> but yeah, mpv just implemented youtube-dl
[16:52:36 CEST] <JEEBsv> so it gets called
[16:52:41 CEST] <JEEBsv> everyone seems happy enough
[16:52:48 CEST] <BtbN> yes, mkv seems like a way better choice for DASH
[16:52:50 CEST] <mtcjayne> OK otherwise is that an accurate description of the issue which I can leave as a comment on their forum?
[16:53:09 CEST] <BtbN> I don't think a propperly made DASH demuxer would be rejected from ffmpeg.
[16:53:19 CEST] <BtbN> It's just that nobody is intersted in writing one.
[16:53:21 CEST] <JEEBsv> but that is not something users actually want :P
[16:53:26 CEST] <mtcjayne> Yeah
[16:53:26 CEST] <JEEBsv> because nothing actually uses DASH
[16:53:36 CEST] <JEEBsv> people just want to watch their youtubes and so forth
[16:53:47 CEST] <JEEBsv> basically just integrate calling youtube-dl and call it a day
[16:53:48 CEST] <BtbN> Steam does, Twitch is experimenting with it.
[16:53:51 CEST] Action: mtcjayne raises his hand
[16:54:10 CEST] <JEEBsv> I'd really be surprised if they're actually doing proper DASH
[16:54:14 CEST] <mtcjayne> I want to watch my 1080p 'Tubes
[16:54:24 CEST] <JEEBsv> mtcjayne: exactly. so you are not needing real DASH
[16:54:31 CEST] <JEEBsv> you just need the glue that gets the streams
[16:54:33 CEST] <BtbN> You need an external tool for youtube anyway
[16:54:35 CEST] <JEEBsv> in other words, youtube-dl
[16:54:45 CEST] <JEEBsv> (it supports various other sites, too)
[16:54:49 CEST] <mtcjayne> I don't really care if it's done properly, but I would like to see progress at all in the project
[16:55:00 CEST] <JEEBsv> no, not proper
[16:55:07 CEST] <JEEBsv> I just mean that it's not fucking DASH
[16:55:24 CEST] <BtbN> JEEBsv, well, at least the DASH reference "player" is able to play it.
[16:55:34 CEST] <mtcjayne> I'd suggested youtube-dl which was dismissed as wacky and "We're waiting on ffmpeg demuxer" /eyeroll
[16:55:47 CEST] <mtcjayne> *hacky
[16:55:48 CEST] <JEEBsv> then XBMC folk are sitll idiots
[16:55:57 CEST] <JEEBsv> *still
[16:56:35 CEST] <JEEBsv> it's a moving target, so anything that grabs videos from sites is bound to be "wacky" or a "hack". The sites can change or block you at any point.
[16:56:39 CEST] <klaxa|work> would it be so hard to make youtube-dl into a library with C-bindings?
[16:56:48 CEST] <JEEBsv> and that kind of shit really should not go into a demuxer
[16:57:00 CEST] <JEEBsv> youtube-dl works just fine how mpv is using it
[16:57:25 CEST] <JEEBsv> it gets the stream and pushes it to the demuxers
[16:57:27 CEST] <JEEBsv> *streams
[16:57:31 CEST] <[fade]> greetings, anyone know how to cut a piece of the video out? like from 2:30 to 3:50? I spend like 3 hours using multiple solutions, nothing works
[16:57:34 CEST] <klaxa|work> oh right, i forgot they do that, do they just call the shellscript?
[16:57:43 CEST] <JEEBsv> it's a python script, but yes
[16:57:43 CEST] <[fade]> using avconv
[16:57:46 CEST] <JEEBsv> it's internally called
[16:58:02 CEST] <mtcjayne> So basically it's not even a Kodi issue.
[16:58:11 CEST] <mtcjayne> It's a Kodi YouTube add-on issue.
[16:58:18 CEST] <BtbN> I don't think xbmc is a bad place to implement a dash demuxer in.
[16:58:22 CEST] <BtbN> It already does so for hls.
[16:58:24 CEST] <mtcjayne> Since they're basically Python anyway
[16:58:32 CEST] <JEEBsv> mtcjayne: or well some plugin, yes
[16:58:41 CEST] <JEEBsv> if it can feed the stuff to the actual demuxers
[16:58:43 CEST] <klaxa|work> [fade]:
[16:58:48 CEST] <mtcjayne> There is even a Kodi youtube-dl library
[16:58:51 CEST] <BtbN> xbmc plugins can't feed raw video.
[16:58:57 CEST] <BtbN> They can only send urls to play.
[16:58:59 CEST] <[fade]> thank you klaxa
[16:59:04 CEST] <JEEBsv> ah
[16:59:21 CEST] <JEEBsv> BtbN: actual true DASH demuxer could go into lavf but it's a real mess and would require xml parsers etc
[16:59:29 CEST] <JEEBsv> or well
[16:59:32 CEST] <JEEBsv> input?
[16:59:34 CEST] <JEEBsv> not sure
[16:59:53 CEST] <mtcjayne> (Where are IRC logs? I'd like this for a record...)
[17:00:03 CEST] <JEEBsv> nfi
[17:00:14 CEST] <BtbN> yes, i don't see an issue with a conformant DASH demuxer.
[17:00:34 CEST] <BtbN> But i see an issue with people sending patches for it, to make it play non-conformant files which they found in the wild.
[17:00:57 CEST] <[fade]> depends on your irc client mtcjayne
[17:01:07 CEST] <mtcjayne> I'm on webchat.
[17:01:48 CEST] <[fade]> in that case, i doubt it has such option
[17:01:50 CEST] <JEEBsv> BtbN: although it goes close to playlists
[17:02:17 CEST] <BtbN> HLS does, but DASH isn't realy comparable to playlists.
[17:02:29 CEST] <BtbN> HLS is nothing more than a fancy playlist.
[17:02:30 CEST] <JEEBsv> HLS is a whole separate piece of horse shit
[17:03:48 CEST] <[fade]> is it possible to remove a piece of the media out using ffmpeg? all i found is cutting and saving that piece, not cutting as in removing it
[17:03:56 CEST] <mtcjayne> BtbN if plugins can only pass URLs does that mean a plugin could demux the DASH XML or no?
[17:04:21 CEST] <BtbN> Nope, it can't.
[17:04:39 CEST] <[fade]> that was an answer to my question, BtbN ?
[17:04:51 CEST] <BtbN> Nope
[17:04:54 CEST] <[fade]> okai :/
[17:04:57 CEST] <mtcjayne> Hmm. At this time I don't see how Kodi would be able to support DASH in any capacity then.
[17:05:08 CEST] <mtcjayne> Due to design decisions they've made.
[17:05:11 CEST] <c_14> [fade]: cut and then concat
[17:05:35 CEST] <[fade]> can you give a bit more info c_14 ? i spend 2+ hours trying multiple options, no sucess
[17:06:17 CEST] <JEEBsv> mtcjayne: can it take input from stdin?
[17:06:55 CEST] <c_14> [fade]: either create 2 files using -ss and -t that contain the parts you want and then use the concat demuxer, or create the 2 parts using trim in a filtegraph and concat with the concat filter
[17:06:59 CEST] <JEEBsv> if yes, then just run youtube-dl yourself and make it output to stdout and pipe to xbmc
[17:07:28 CEST] <BtbN> i don't think you can pipe to xbmc
[17:07:39 CEST] <BtbN> As it's usualy already running
[17:07:48 CEST] <mtcjayne> JEEBsv at that point users would be better served by a standalone media player called by a Kodi add-on.
[17:07:52 CEST] <mtcjayne> I believe.
[17:08:07 CEST] <[fade]> i see, thank you c_14
[17:08:25 CEST] <mtcjayne> Like the addons which can start game emulators and whatnot.
[17:08:29 CEST] <JEEBsv> well if you could just plug mpv there then you could be golden :P
[17:08:38 CEST] <JEEBsv> since mpv can internally call youtube-dl
[17:08:59 CEST] <JEEBsv> mpv "url-to-my-dirty-laundry-videos"
[17:09:36 CEST] <mtcjayne> I'll also contact the guy(s) who made youtube-dl and see if he/they have advice on an implementation.
[17:10:31 CEST] <mtcjayne> I'm beginning to think "hacky" is what Kodi is going to have to aim for. Or "wontfix"
[17:10:53 CEST] <JEEBsv> you can take a look at the mpv youtube-dl code if ye want
[17:11:16 CEST] <mtcjayne> That too.
[17:17:09 CEST] <mtcjayne> Thank you for your comments and discussion
[19:26:54 CEST] <kyleogrg> greetings
[19:26:59 CEST] <kyleogrg> opus
[19:27:25 CEST] <kyleogrg> opus vs aac - is opus better in every way??
[19:30:49 CEST] <Plorkyeran> not compatibility
[19:31:08 CEST] <Plorkyeran> other than that it's not worse than aac
[19:31:13 CEST] <Plorkyeran> at worst
[19:35:59 CEST] <kyleogrg> so it's definitely at least a good as AAC (except compatability)?
[19:38:23 CEST] <kyleogrg> same or better quality at same file size?
[19:41:52 CEST] <c_14> kyleogrg: https://opus-codec.org/comparison/ if you trust comparisons made by the people who designed the codec in the comparison
[19:42:14 CEST] <kyleogrg> c_14: yeah, i've seen that. do you trust it?
[19:42:51 CEST] <c_14> Whenever I encode to a lossy audio format I use opus, so&
[19:43:39 CEST] <kyleogrg> it's probably fair to say it's very competitive with aac
[19:44:47 CEST] <c_14> yeah
[20:57:06 CEST] <canbal> Anyone know how to register the decoder for timed_id3? I dont want to compile the libs and register all codecs using av_register_all(). However without this avformat_find_stream_info() hangs
[21:22:35 CEST] <Fyr> guys, how to calculate psnr for audio with ffmpeg?
[21:45:10 CEST] <llogan> Fyr: i don't think you can
[21:46:18 CEST] <Fyr> =(
[21:46:32 CEST] <llogan> perform ABX testing instead.
[22:26:34 CEST] <dna_592> jkhkj
[22:26:35 CEST] <dna_592> hi
[22:27:41 CEST] <dna_592> i'm a developer, and new to ffmpeg libraries, i'm working on a project and even with the code finished i can't compile it
[22:28:10 CEST] <dna_592> it always send me the same message "undefined reference to "av_frame_alloc""
[22:28:46 CEST] <dna_592> i did some research but didn't find anything helpfull
[22:28:52 CEST] <dna_592> can u guys help me?
[22:29:48 CEST] <Fyr> dna_592, I recommend ##ffmpeg-devel
[22:30:15 CEST] <dna_592> ok
[22:30:16 CEST] <dna_592> ty
[23:06:33 CEST] <llogan> Fyr: #ffmpeg-devel is not for user help
[23:58:00 CEST] <kittonian> hi all. i just got a 12-core mac pro (24 threads) and though it is definitely faster doing command line transcoding over my quad-core mac pro 1,1, when i look in activity monitor it only shows 1 thread being used. i tried setting -threads 23 but it still only showed it using 1 thread. is this correct?
[00:00:00 CEST] --- Fri May 1 2015
1
0