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
August 2015
- 1 participants
- 62 discussions
[00:33:19 CEST] <cone-247> ffmpeg 03Mariusz SzczepaDczyk 07master:bf5b2f9df876: lavf/ftp: implement move and delete callbacks
[01:57:43 CEST] <llogan> michaelni: what's the logo email about?
[02:11:35 CEST] <michaelni> llogan, you should have gotten the original mail
[02:11:59 CEST] <michaelni> ffmpeg won in some category in some magazine ...
[02:12:29 CEST] <michaelni> i can forwrd the origina mail if you dont have it
[02:14:57 CEST] <llogan> sure. i don't see it
[02:17:45 CEST] <michaelni> llogan, forwarded, i hope you like reading html
[02:22:33 CEST] <llogan> i see ocassional spams for magazine/business awards. i assumed this was one, but i guess it is ok.
[02:23:49 CEST] <llogan> i missed it earlier because it went into spam and i was too lazy to root through it all
[02:25:49 CEST] <llogan> anyway i sent a SVG logo for them to convert to gif then upscale to 8 inches.
[02:54:33 CEST] <atomnuker> sooo yeah, turns out the aac MIPS encoder must have been broken for around 1.5 months now
[02:54:56 CEST] <atomnuker> both my and klaussfreire's fault since we both changed the function definitions
[02:55:17 CEST] <atomnuker> but the fact that no one even complained speaks volumes about how many people actually use it
[02:56:34 CEST] <rcombs> if the MIPS people care they should add tests
[03:02:43 CEST] <atomnuker> broken, as in, it shouldn't compile, no need to test for that
[03:08:35 CEST] <BBB> atomnuker: dont we have mips qemu fate stations?
[03:12:55 CEST] <atomnuker> looking at fate, we do
[03:13:40 CEST] <atomnuker> it seems aac-aref-encode and aac-ln-encode
[03:14:27 CEST] <atomnuker> actually on second though they probably compile fine
[03:15:04 CEST] <atomnuker> it's just that they put differently defined functions in function pointers
[03:15:09 CEST] <BBB> ah
[03:15:11 CEST] <BBB> right
[03:15:26 CEST] <BBB> yeah we should have fate tests that catch that
[03:15:27 CEST] <BBB> ..
[03:17:39 CEST] <atomnuker> hmm, that's odd, looking at the logs they don't even print warnings about the function pointers
[03:57:05 CEST] <cone-546> ffmpeg 03Michael Niedermayer 07master:db91e0edb63a: avformat/mux: Update sidedata in ff_write_chained()
[07:52:13 CEST] <rcombs> "nothing helps a couple reconcile like a good lawsuit. Against a third party, that is."
[08:55:49 CEST] <nevcairiel> atomnuker: personally i would've just disabled the mips optimized functions months ago instead of trying to fix them all the time, you two are doing massive changes to the encoder, let some mips person fix them once you are done
[08:57:23 CEST] <rcombs> +1
[09:06:06 CEST] <nevcairiel> also re hevc simd, if they dont get to their senses and actually backport finished simd instead of writing their own version of everything (which they won't, of course), i'll just not merge anything of it. if someone that knows how our hevc dsp is structured wants to adapt any of it to work for us in some way, they are welcome to it
[09:09:14 CEST] <nevcairiel> i just dont understand how someone can start writing something extremely complex like simd for hevc and not even consider if one of the other two places using the same decoder base doesn't have it already
[09:09:22 CEST] <nevcairiel> tiny bubbles everywhere
[09:10:19 CEST] <iive> you mean, they don't do that on purpose?
[09:10:28 CEST] <nevcairiel> it would be extremely stupid
[09:10:32 CEST] <nevcairiel> but maybe they are
[09:10:34 CEST] <nevcairiel> i dont know
[11:24:59 CEST] <ubitux> do we have an example of creating an AVFrame with custom data?
[11:25:29 CEST] <wm4> "custom data"?
[11:26:06 CEST] <ubitux> user data
[11:26:35 CEST] <ubitux> like, what's going to happen if i alloc a frame, set frame->data/linesize and feed it to lav*
[11:27:35 CEST] <ubitux> (and delete my data right away)
[11:33:44 CEST] <wm4> if you don't set the bufs to (essentially) invalid values, then with some luck the receiving API will either just use it for the duration of the function call, or make a copy if it's needed longer
[11:33:49 CEST] <wm4> that's how it should work
[11:40:33 CEST] <wm4> using av_frame_get_buffer and then just changing the data pointers is highly illegal
[11:43:04 CEST] <nevcairiel> if it needs to keep a copy and there is no valid bufs for ref counting, it'll make a copy, and thats that
[11:56:31 CEST] <durandal_1707> when is next release?
[12:19:46 CEST] <cone-497> ffmpeg 03Carl Eugen Hoyos 07master:9bd305be91fd: lavf/mpeg: Allow users to force audio codec MLP.
[12:34:06 CEST] <cone-497> ffmpeg 03Ganesh Ajjanagadde 07master:ecf6b26aa500: avformat/ftp: use correct enum type
[14:29:34 CEST] <cone-497> ffmpeg 03Janne Grunau 07release/2.4:02477323b92a: aac_parser: add required padding for GetBitContext buffer
[14:29:35 CEST] <cone-497> ffmpeg 03Janne Grunau 07release/2.4:a9f108bd78e8: ac3_parser: add required padding for GetBitContext buffer
[14:29:36 CEST] <cone-497> ffmpeg 03Janne Grunau 07release/2.4:aa3ec219e1a5: imc: add required padding for GetBitContext buffer
[14:29:37 CEST] <cone-497> ffmpeg 03Luca Barbato 07release/2.4:859ce02c9815: h263: Always check both dimensions
[14:29:38 CEST] <cone-497> ffmpeg 03Anton Khirnov 07release/2.4:c49b88b93bca: opusdec: properly handle mismatching configurations in multichannel streams
[14:29:39 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:80b1cc31b8f0: Merge commit '02477323b92aacdabe0a2d129eeb0c15fbd1ec9e' into release/2.4
[14:29:40 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:8b0a063ba912: Merge commit 'a9f108bd78e842a47ade2f7c8b22a1764d01d4e6' into release/2.4
[14:29:41 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:7da1e8a0d891: Merge commit 'aa3ec219e1a5cc0e96ddec6ea83312ec780448f5' into release/2.4
[14:29:42 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:e0f859e8fe14: Merge commit '859ce02c9815b492da627d3098548b4f69bbc80e' into release/2.4
[14:29:43 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:f141ac2d7028: Merge commit 'c49b88b93bca53c04f18d78c27dbf1dc6daea909' into release/2.4
[14:53:52 CEST] <cone-497> ffmpeg 03Ganesh Ajjanagadde 07release/2.4:35ab85884b66: swresample/dither: check memory allocation
[14:53:53 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:39430866566a: avformat/mxfenc: Accept MXF D-10 with 49.999840 Mbit/sec
[14:53:54 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:8498cf60b209: Revert "avformat/rtpenc: check av_packet_get_side_data() return, fix null ptr dereference"
[14:53:55 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:df2258f18d18: swresample/swresample: Cleanup on init failure.
[14:53:56 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:0081afeaa741: avcodec/atrac3plusdec: consume only as many bytes as available
[14:53:57 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:4121c1db15e1: avcodec/alsdec: Check for overread
[14:53:58 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:5709ac5c42a7: avcodec/adpcm: Check for overreads
[14:53:59 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:8fc8b3eebe95: avformat/ffmdec: Check ffio_set_buf_size() return value
[14:54:00 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:84cf7418618f: avcodec/jpeg2000dec: Check that coords match before applying ICT
[14:54:01 CEST] <cone-497> ffmpeg 03Simon Thelen 07release/2.4:d7682421528f: libavutil/channel_layout: Correctly return layout when channel specification ends with a trailing 'c'.
[14:54:02 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:402f83298463: avdevice/lavfi: do not rescale AV_NOPTS_VALUE in lavfi_read_packet()
[14:54:03 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:6ff5c4cd49ec: avcodec/h264_slice: Use AVFrame diemensions for grayscale handling
[14:54:04 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:670832e2a273: takdec: ensure chan2 is a valid channel index
[14:54:05 CEST] <cone-497> ffmpeg 03Deliang Fu 07release/2.4:d54ca4167c48: avformat: Fix bug in parse_rps for HEVC.
[14:54:06 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:22349b9f7d4f: ffmpeg_opt: Check for localtime() failure
[14:54:07 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:cd83ff5d4c70: mov: abort on EOF in ff_mov_read_chan
[14:54:08 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:18aef7c07560: libopenjpegdec: check existence of image component data
[14:54:09 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:8c8406462bb5: arm: only enable setend on ARMv6
[14:54:10 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:9da5ba1f57a4: vp9: change type of tile_size from unsigned to int64_t
[14:54:11 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:13a9a0c1a492: vp8: change mv_{min,max}.{x,y} type to int
[14:54:12 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:c5dd6fefd41e: sonic: set avctx->channels in sonic_decode_init
[14:54:13 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:5302adb32367: h264: er: Copy from the previous reference only if compatible
[14:54:14 CEST] <cone-497> ffmpeg 03wm4 07release/2.4:9d0aa058c997: avio: fix potential crashes when combining ffio_ensure_seekback + crc
[14:54:15 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:7de7d81ee55a: postproc: fix unaligned access
[14:54:16 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:e588252a429c: avcodec/dpxenc: implement write16/32 as functions
[14:54:17 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:933ae708c5fc: matroskadec: validate audio channels and bitdepth
[14:54:18 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:b3745ce8c261: matroskadec: check audio sample rate
[14:54:19 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:00772989041a: swr: Remember previously set int_sample_format from user
[14:54:20 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:60a3bd625f4d: swscale/rgb2rgb_template: Disable shuffle_bytes_2103_c on big endian
[14:54:21 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:2f1bff169000: swscale/rgb2rgb_template: Implement shuffle_bytes_0321_c and fix shuffle_bytes_2103_c on BE
[14:54:22 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:bada03d74634: swscale/rgb2rgb_template: Fix signedness of v in shuffle_bytes_2103_c()
[14:54:23 CEST] <cone-497> ffmpeg 03Sebastien Zwickert 07release/2.4:d50d11c56cd4: vda: unlock the pixel buffer base address.
[14:54:24 CEST] <cone-497> ffmpeg 03James Almer 07release/2.4:1795bef7c736: swscale/x86/rgb2rgb_template: add missing xmm clobbers
[14:54:25 CEST] <cone-497> ffmpeg 03James Almer 07release/2.4:286e14667fe4: swscale/x86/rgb2rgb_template: fix signedness of v in shuffle_bytes_2103_{mmx,mmxext}
[14:54:26 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:925adad3e074: ffmpeg: Do not use the data/size of a bitstream filter after failure
[14:54:27 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:a47bc9a05601: swscale/swscale_unscaled: Fix rounding difference with RGBA output between little and big endian
[14:54:28 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:2789d15114cf: wmavoice: limit wmavoice_decode_packet return value to packet size
[14:54:29 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:e35c5348900a: avcodec/pngdec: Only allow one IHDR chunk
[14:54:30 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:3dfadef52216: avfilter/vf_transpose: Fix rounding error
[14:54:31 CEST] <cone-497> ffmpeg 03James Zern 07release/2.4:c6e16ec711c2: vp9/update_prob: prevent out of bounds table read
[14:54:32 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:47a5cde6ac03: avcodec/h264_slice: Use w/h from the AVFrame instead of mb_w/h
[14:54:33 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:514d0e29c8cd: avcodec/aacsbr: check that the element type matches before applying SBR
[14:54:34 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:7fdc2ba3d46e: avcodec/aacsbr: Assert that bs_num_env is positive
[14:54:35 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:7ecaa736e781: avcodec/rawenc: Use ff_alloc_packet() instead of ff_alloc_packet2()
[14:54:36 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:9e52f6b98672: wmalosslessdec: avoid reading 0 bits with get_bits
[14:54:37 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07release/2.4:9463930faf9f: wmalosslessdec: reset frame->nb_samples on packet loss
[14:54:38 CEST] <cone-497> ffmpeg 03Chris Watkins 07release/2.4:3fb241210af6: oggparsedirac: check return value of init_get_bits
[14:54:39 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:c58b0d981ea7: avcodec/mpegvideo: Clear pointers in ff_mpv_common_init()
[14:54:40 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:cbc5d2bf30d0: avcodec/utils: use a minimum 32pixel width in avcodec_align_dimensions2() for H.264
[14:54:41 CEST] <cone-497> ffmpeg 03Anton Khirnov 07release/2.4:a23a6bf06b99: bytestream2: set the reader to the end when reading more than available
[14:54:42 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:41fba53525f7: avcodec/alac: Clear pointers in allocate_buffers()
[14:54:43 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:f78573466d44: avcodec/sanm: Reset sizes in destroy_buffers()
[14:54:44 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:bd5cf1dd8f9e: avcodec/pthread_frame: check avctx on deallocation
[14:54:45 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:cf27b297ca0b: ffmpeg: Fix cleanup with ost = NULL
[14:54:46 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:634605f79e36: avformat/mov: Fix deallocation when MOVStreamContext failed to allocate
[14:54:47 CEST] <cone-497> ffmpeg 03Zhang Rui 07release/2.4:7a7ec3ccd9b6: avutil/fifo: Fix the case where func() returns less bytes than requested in av_fifo_generic_write()
[14:54:48 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:3bc20fe48c5e: swscale/utils: Clear pix buffers
[14:54:49 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:e3bacdbaadda: avcodec/pthread_frame: clear priv_data, avoid stale pointer in error case
[14:54:50 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:649f09c4cfe9: avfilter/af_aresample: Check ff_all_* for allocation failures
[14:54:51 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:24f1698758f0: avcodec/rv34: Clear pointers in ff_rv34_decode_init_thread_copy()
[14:54:52 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:7ae349a324f1: avcodec/diracdec: Check for hpel_base allocation failure
[14:54:53 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:8fe79605fdce: avcodec/vp8: Fix null pointer dereference in ff_vp8_decode_free()
[14:54:54 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:d2b0aae5e1b2: avcodec/vp8: Check buffer size in vp8_decode_frame_header()
[14:54:55 CEST] <cone-497> ffmpeg 03wm4 07release/2.4:2d582d142c18: rawdec: fix mjpeg probing
[14:54:56 CEST] <cone-497> ffmpeg 03wm4 07release/2.4:43956940ea20: rawdec: fix mjpeg probing buffer size check
[14:54:57 CEST] <cone-497> ffmpeg 03Emanuel Czirai 07release/2.4:33629ff60fb3: libavcodec/aacdec_template: Use init_get_bits8() in aac_decode_frame()
[14:54:58 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:595af5a036f4: avcodec/dcaenc: clear bitstream end
[14:54:59 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:eac75d405b97: avcodec/svq1enc: Check dimensions
[14:55:00 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:ac3358d73ad2: avcodec/flashsvenc: Correct max dimension in error message
[14:55:01 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:cbaa9ef0d601: avformat/mux: Update sidedata in ff_write_chained()
[14:56:43 CEST] <wm4> I didn't know we have someone maintaining releases
[15:01:19 CEST] <BBB> I still have 5 patches (or 4, I guess) awaiting review, anyone want to help?
[15:01:53 CEST] <BBB> https://github.com/rbultje/ffmpeg/commit/e5bb803bdee35d67e1ffd4cc001a155fdf…, https://github.com/rbultje/ffmpeg/commit/dc8062fa28d3462fd952f6e27193b27d07…, https://github.com/rbultje/ffmpeg/commit/304586445ffe85eae1a87b3a37fd38a0f2… and https://github.com/rbultje/ffmpeg/commit/87cb730a91e4e6cd08fe9ee152c1e0815a…
[15:05:30 CEST] <wm4> send them to the ML?
[15:17:23 CEST] <cone-497> ffmpeg 03Michael Niedermayer 07release/2.4:98f167202262: Update for 2.4.11
[15:22:57 CEST] <BBB> wm4: they are there, unresponded-to
[15:23:03 CEST] <wm4> send them again
[15:50:30 CEST] <Compn> did someone already bring up the audible decoder license header ?
[15:50:42 CEST] <Compn> i dont want to read 50 replies to the patch :\
[15:51:26 CEST] <Compn> oh yes durandal_1707 did
[15:51:30 CEST] <Compn> good, i dont have to reply then
[16:51:49 CEST] <ubitux> anyone opposed to a c muxer? :)
[17:11:09 CEST] <wm4> a what
[17:20:15 CEST] <kierank> ubitux: a what
[17:20:54 CEST] <ubitux> kierank: a .c file muxer, with "unsigned char *buf = { ... } " and actually other meta
[17:21:01 CEST] <ubitux> for direct inclusion within code
[17:21:05 CEST] <ubitux> gimp does that for images typically
[17:21:29 CEST] <ubitux> (seems i'm going to hell soon)
[17:21:33 CEST] <Compn> it muxes c code
[17:21:37 CEST] <Compn> from what kind of input ? :P
[17:21:54 CEST] <ubitux> let's say rgb rawvideo
[17:21:56 CEST] <nevcairiel> probably something silly as raw rgb or something
[17:21:57 CEST] <nevcairiel> see
[17:21:58 CEST] <nevcairiel> :D
[17:22:00 CEST] <Compn> lol
[17:22:01 CEST] <ubitux> :D
[17:22:28 CEST] <ubitux> seems nevcairiel wanted to do that as well but never dare to propose it
[17:22:33 CEST] <ubitux> i'll take that as a ack!
[17:22:44 CEST] <nevcairiel> no, i dont have any clue what you would want to use that for
[17:22:53 CEST] <ubitux> stupid shit obviously
[17:23:14 CEST] <nevcairiel> for the one time in a lifetime i would need it, i would just dumb the rawvideo with a hex editor and wrap { } around it =p
[17:23:19 CEST] <nevcairiel> dump*
[17:23:29 CEST] <ubitux> yeah, i muxed to rawvideo and used xxd -i
[17:41:54 CEST] <wm4> ubitux: that wouldn't be a muxer, but a protocol
[17:44:41 CEST] <nevcairiel> i dont know, its kind of a container for raw formats
[17:54:39 CEST] <wm4> it just wraps a byte stream, nothing else is special about it
[18:10:08 CEST] <oreWizard> someone use ffmpeg with c#?
[18:12:08 CEST] <kierank> ubitux: my joylent finally arrived
[18:13:49 CEST] <podman> Is there any reason why -map_metadata -1 wouldn't remove menu metadata?
[20:35:15 CEST] <cone-497> ffmpeg 03Lou Logan 07master:538ea9a20976: doc/indevs: Remove non-existent decklink option examples
[20:56:36 CEST] <durandal_1707> so nobody against?
[21:03:33 CEST] Action: durandal_1707 started debate with inocent patch
[21:22:35 CEST] <cone-497> ffmpeg 03Ganesh Ajjanagadde 07master:b772847eb04e: avformat/webmdashenc: fix uninitialized variable
[21:31:17 CEST] <cone-497> ffmpeg 03Ganesh Ajjanagadde 07master:c3052c9e8a91: avcodec/aacsbr_fixed: remove unused variable
[22:07:29 CEST] <cone-497> ffmpeg 03Ludmila Glinskih 07master:e23a01c06df3: api-seek-test: first version
[22:42:19 CEST] <cone-497> ffmpeg 03Andreas Cadhalpun 07master:96f5fdebc3c6: graph2dot: use avfilter_pad_get_name accessor function
[23:56:23 CEST] <cone-497> ffmpeg 03Ganesh Ajjanagadde 07master:e8319f602e94: avcodec/metasound_data: comment out unused variable
[00:00:00 CEST] --- Fri Aug 21 2015
1
0
[01:21:48 CEST] <nanoEng> Can someone help me with an error I am getting while trying to compile FFmpeg? http://pastebin.com/BF2Pv5Gk
[01:22:12 CEST] <nanoEng> It occurs when doing the make command
[01:22:48 CEST] <nanoEng> For my configure, I am using:
[01:22:51 CEST] <nanoEng> ./configure --target-os=win64 --enable-sdl --disable-programs --disable-encoders --enable-ffplay --disable-d3d11va --disable-dxva2 --disable-shared --enable-static --disable-doc --prefix=TEST2 --disable-ffmpeg --disable-ffprobe --disable-ffserver --disable-network --enable-gpl --enable-swscale --enable-memalign-hack --enable-yasm --disable-mmx --disable-mmxext
[01:23:45 CEST] <nanoEng> Am I to understand this is a problem with YASM?
[01:54:44 CEST] <nanoEng> can someone tell me why I am getting this error on compile: http://pastebin.com/BF2Pv5Gk ??
[01:57:45 CEST] <nanoEng> ./configure --target-os=win64 --enable-sdl --disable-programs --disable-encoders --enable-ffplay --disable-d3d11va --disable-dxva2 --disable-shared --enable-static --disable-doc --prefix=TEST2 --disable-ffmpeg --disable-ffprobe --disable-ffserver --disable-network --enable-gpl --enable-swscale --enable-memalign-hack --enable-yasm --disable-mmx --disable-mmxext
[01:58:13 CEST] <nanoEng> says that arch x86 (general) ????
[01:58:51 CEST] <nanoEng> after running ./configure
[01:59:12 CEST] <nanoEng> yet when i type arch it says x86_64
[01:59:28 CEST] <nanoEng> so why when i try to build does it set it to x86 ?
[02:00:03 CEST] <nanoEng> hence why i get error libavfilter/x86/af_volume.asm:45: warning: `rdx' is a register in 64-bit mode ???
[02:00:18 CEST] <nanoEng> Or is something else the cause of the error?
[02:00:47 CEST] <nanoEng> The error occurs after the outputline: YASM libavfilter/x86/af_volume.o
[02:01:31 CEST] <klaxa> wow that's quite the error
[02:01:49 CEST] <klaxa> sorry, but i have no idea about that
[02:02:14 CEST] <nanoEng> :(
[02:02:21 CEST] <nanoEng> damnit
[02:03:31 CEST] <relaxed> the error is from undefined symbols, but you can try disabling that filter to see if it will compile without it
[02:04:00 CEST] <nanoEng> how do i disable it?
[02:04:20 CEST] <nanoEng> Is it indeed coming from yasm, hence --disable-yasm
[02:04:23 CEST] <nanoEng> ?
[02:05:00 CEST] <relaxed> --disable-filter=volume
[02:05:01 CEST] <nanoEng> I'll try it right now with that
[02:05:04 CEST] <nanoEng> oh...
[02:05:18 CEST] <nanoEng> and leave yasm alone then?
[02:05:34 CEST] <relaxed> yes, unless you want super slow decoding
[02:05:53 CEST] <nanoEng> ah, ok
[02:06:05 CEST] <relaxed> maybe you should state what you're trying to achieve
[02:06:09 CEST] <nanoEng> its just that i read here http://gopherproxy.meulie.net/sdf.org/0/users/wisdomc0/article_assembly/ass…
[02:06:19 CEST] <nanoEng> i'm just trying to compile ffplay
[02:06:29 CEST] <nanoEng> 64bit
[02:07:02 CEST] <relaxed> you can download ffplay builds from http://ffmpeg.zeranoe.com/builds/
[02:07:40 CEST] <nanoEng> on that site, it says "some of 64 bit registers are: - rdx (edx) - rsi (esi) , ..."
[02:07:48 CEST] <nanoEng> so i thought the error had to do with yasm.
[02:08:17 CEST] <relaxed> could be
[02:08:51 CEST] <nanoEng> i'm trying make right now with --disable-yasm
[02:09:05 CEST] <nanoEng> after that fails to solve the problem, i'll try it with --disable-filter=volume as you suggested
[02:10:11 CEST] <relaxed> I suggest you download the binary from the above url :)
[02:10:43 CEST] <nanoEng> zeranoe is for compiling for windows using Debian
[02:10:55 CEST] <nanoEng> I'm not using Debian, or other linux.
[02:11:23 CEST] <relaxed> Did you even look? They're windows binaries
[02:11:34 CEST] <nanoEng> And i'm trying to customize ffplay. I've already downloaded builds of ffplay; I want to modify the program.
[02:11:50 CEST] <nanoEng> But first i want to see if i can just do a test compile; and i can't...
[02:12:52 CEST] <nanoEng> You are right though, the binary from Zeranoe works great.
[02:12:55 CEST] <relaxed> nanoEng: try adding --arch=x86_64 to your configure line.
[02:13:11 CEST] <relaxed> and keep --enable-yasm
[02:13:37 CEST] <nanoEng> relaxed: I tried that already :\ still tells me arch x86 (general) when i do that.
[02:13:52 CEST] <relaxed> that's normal
[02:14:16 CEST] <nanoEng> oh, x86 (general) means the it will make a 64bit program?
[02:14:37 CEST] <chungy> x86 can be 32-bit or 64-bit
[02:15:16 CEST] <nanoEng> ah
[02:15:18 CEST] <chungy> can also be 16-bit but that's not very relevant in this channel :P
[02:15:26 CEST] <nanoEng> i thought x86_64 could be 32 or 64-bit.
[02:15:42 CEST] <nanoEng> and x86 was strictly 32-bit.
[02:15:49 CEST] <chungy> x86_64 is the 64-bit variant specifically (likewise x86_32 for 32-bit, but more often called IA32)
[02:17:53 CEST] <nanoEng> hmm... so when it says the arch is set to x86 (general) i can expect a 64-bit program to be output?
[02:18:41 CEST] <nanoEng> Well, using --disable-yasm didn't give the error i've been having... although, it is Still compiling....
[02:18:43 CEST] <relaxed> which compiler are you using?
[02:19:06 CEST] <nanoEng> I read the breif wikipeida on yasm (just says it is the replacement of nasm) ...
[02:19:59 CEST] <nanoEng> needless to say, i'm new to the world of compiling stuff (I'm only self taught in Python, and took a C++ hello world level programing class a long time ago).
[02:20:49 CEST] <nanoEng> So, my concern is, will compiling w/o yasm result in a lower-performance program than with it?
[02:21:05 CEST] <relaxed> yes
[02:21:20 CEST] <nanoEng> damnit
[02:21:47 CEST] <nanoEng> ..... hmm.. maybe i should just terminate the compile right now then... and try your --disable-filter-volume method.
[02:22:14 CEST] <relaxed> which compiler are you using?
[02:22:34 CEST] <nanoEng> still, i'm curious to see if it will actually do it. If it does it will be the first successful compile of ffplay after about 36 hours of trying to get a successful compile.
[02:22:44 CEST] <nanoEng> msys2/mingw-w64
[02:23:12 CEST] <nanoEng> using the msys2 shell to emulate linux
[02:24:16 CEST] <nanoEng> i've already resolved many other issues i was having, now it seems i've finally gotten ./configure settled. now i'm on to getting make to work.
[02:24:40 CEST] <nanoEng> yay it finished, f***, it crapped out
[02:24:55 CEST] <nanoEng> CC ffplay.o
[02:25:04 CEST] <nanoEng> <command-line>:0:6: error: no previous prototype for SDL_main [-Werror=missing-prototypes]
[02:25:12 CEST] <nanoEng> ffplay.c:3678:5: note: in expansion of macro main
[02:25:24 CEST] <nanoEng> int main(int argc, char **argv)
[02:25:28 CEST] <nanoEng> ^
[02:25:34 CEST] <nanoEng> cc1: some warnings being treated as errors
[02:25:39 CEST] <nanoEng> common.mak:57: recipe for target 'ffplay.o' failed
[02:25:44 CEST] <nanoEng> make: *** [ffplay.o] Error 1
[02:25:52 CEST] <relaxed> this is not pastebin.com
[02:25:57 CEST] <nanoEng> then it just returns me to prompt...
[02:26:17 CEST] <nanoEng> yeah, but it was only 6 lines, so i figured give pastebin servers a rest.
[02:28:22 CEST] <llogan> the mingw guide in the wiki is ugly.
[02:28:46 CEST] <llogan> "rogerdpack". well, that explains it.
[02:29:20 CEST] <llogan> "stream of consciousness" guide writing
[02:29:30 CEST] <nanoEng> ?
[02:29:38 CEST] <llogan> https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW
[02:30:10 CEST] <nanoEng> rogerdpack ?
[02:30:21 CEST] <llogan> view history
[02:30:27 CEST] <nanoEng> that string does not occur in that website
[02:30:46 CEST] <llogan> no, i was simply bitching about it
[02:31:05 CEST] <relaxed> nanoEng: oh, did you download the 32bit version of yasm.exe ?
[02:31:20 CEST] <nanoEng> no i don't think so.
[02:31:29 CEST] <nanoEng> i'm quite certain i did not
[02:31:58 CEST] Action: relaxed is glad he doesn't have to compile things on windows
[02:31:58 CEST] <nanoEng> i renamed yasm-1.3.0-win64 to yasm.exe as instructed, and put it in msys64/usr/bin
[02:32:40 CEST] <nanoEng> i also tried pacman -Ss yasm
[02:32:53 CEST] <nanoEng> then installed both pacman -S msys/yasm
[02:33:14 CEST] <nanoEng> and pacman - S mingw64/mingw-w64-x86_64-yasm
[02:34:05 CEST] <nanoEng> I am now trying it with --disable-filter-volume and yasm turned back on.
[02:35:07 CEST] <nanoEng> the yasm msys2's pacman service gives seems to be from April 2015, and the one i was using was from.. just gives the date i downloaded it.. so dont know., but it was from yasm website, so latest i suppose.
[02:35:54 CEST] <nanoEng> tho file sizes are different, i'll use the one msys2 gives me, since it wasn't happy when i used SDL i downloaded myself
[02:36:09 CEST] <nanoEng> and using pacman -S fixed the SDL issue i was having
[02:36:16 CEST] <nanoEng> thought it might fix the yasm..
[02:36:29 CEST] <nanoEng> oh lame
[02:36:51 CEST] <nanoEng> --disable-filter-volume makes the orignal error i posted worse
[02:37:22 CEST] <nanoEng> now i have waaayy more 'is a register in 64-bit mode' warnings
[02:39:06 CEST] <nanoEng> http://pastebin.com/TUbi9Qr9
[02:39:58 CEST] <nanoEng> hi relaxed
[02:41:10 CEST] <nanoEng> relaxed: your --disable-filter-volume suggestion didn't work. In fact, i got even more 'is a register in 64-bit mode' warnings: http://pastebin.com/TUbi9Qr9
[02:46:56 CEST] <relaxed> looks like your yasm and gcc are trying different bit modes, 32 vs 64
[02:47:33 CEST] <nanoEng> hmm... what tips you off to that, and how do I go about resolving it?
[02:47:57 CEST] <nanoEng> That last pastebin is with --disable-yasm
[02:48:10 CEST] <nanoEng> hmm then why did it show up...
[02:48:14 CEST] <relaxed> it's clearly using yasm
[02:48:31 CEST] <nanoEng> oh crud, i think i had both --enable-yasm and --disable-yasm >.<
[02:48:34 CEST] <relaxed> --yasmexe=/path/to/64bit/yasm.exe
[02:52:23 CEST] <nanoEng> hmm ok then
[02:52:31 CEST] <DHE> libav* question. I want to be able to check frames of an H264 (probably no other codecs) to determine whether a frame is IDR or not. preferably without doing a full decode or else this is liable to kill my CPU... pointers?
[03:18:40 CEST] <nanoEng> Anyone know why I am getting this compile error: http://pastebin.com/BF2Pv5Gk ??
[03:19:02 CEST] <nanoEng> ./configure --target-os=win64 --enable-sdl --disable-programs --disable-encoders --enable-ffplay --disable-d3d11va --disable-dxva2 --disable-shared --enable-static --disable-doc --prefix=TEST2 --disable-ffmpeg --disable-ffprobe --disable-ffserver --disable-network --enable-gpl --enable-swscale --enable-memalign-hack --enable-yasm --disable-mmx --disable-mmxext
[03:24:41 CEST] <voltagex> I'm trying to follow the instructions for building with MSVC but when launching msys2_shell.bat from the Developer Tools prompt, it closes.
[03:25:40 CEST] <nanoEng> hmmm
[03:25:53 CEST] <nanoEng> i have no idea.
[03:44:48 CEST] <occupant> hrm I noticed that a binary I recently compiled from latest stable didn't report the configure flags anymore. there's a place for it, just blank. did something change in that respect?
[06:58:38 CEST] <jasom> Encoding from a dvd with subtitles, (stream 3 is dvd subtitles) I get: Application provided invalid, non monotonically increasing dts to muxer in stream 3: 397316401 >= 388567824 is there anything I can do about this?
[08:15:50 CEST] <buu> What determines the default bitrate when transcoding a file?
[08:57:47 CEST] <rcombs> buu: default rate control settings are up to the encoder
[10:26:38 CEST] <theeboat> Hi. is there anybody that could advise me on using the -probesize flag within ffmpeg? I have been using it and it doesn't seem to have the intended effect
[10:27:52 CEST] <Fyr> guys, how resampling influences on audio quality?
[10:28:28 CEST] <ln-> in english you need to use the auxiliary verb 'do' in questions like that.
[10:28:40 CEST] <Fyr> =)
[10:28:43 CEST] <Fyr> alright
[10:29:12 CEST] <Fyr> I'll tattoo it on my hand.
[10:29:19 CEST] <ln-> great
[10:31:20 CEST] <Fyr> opusenc resamles file into 48 kHz, I want to know if resampling has an effect on output quality.
[10:31:53 CEST] <Mavrik> Of course it does.
[10:32:02 CEST] <Fyr> how?
[10:32:06 CEST] <Fyr> ln-, do you know that or you just grammar nazying people on the channel?
[10:32:36 CEST] <JEEB> opus is special regarding sample rates
[10:32:54 CEST] <JEEB> also you already are losing plenty of quality during the lossy encoding phase
[10:33:20 CEST] <JEEB> so if you are only bothered by the fact that opus seems to be doing something different to others, I wouldn't put too much issue into that
[10:33:29 CEST] <Fyr> my library has files with sampling rate from 22 kHz to 192 kHz, but opusenc sets only 48 kHz.
[10:33:32 CEST] <JEEB> otherwise, keep resampling to a minimum
[10:33:59 CEST] <JEEB> yes, and I'm telling you that if you're just wondering about opusenc then just don't think too much about it. it's how opus works :P
[10:34:25 CEST] <JEEB> you can ask the opus folks about it if you really want to :)
[10:34:50 CEST] <Fyr> =)
[13:18:30 CEST] <satiender> Hi how I can run binary of ffmpeg on android
[13:18:32 CEST] <satiender> ??
[13:19:25 CEST] <Sefid_par> satiender: Of course this is an android development question I think
[13:19:38 CEST] <Sefid_par> How can I get better quality form desktop capturing?
[13:19:48 CEST] <Sefid_par> Here is the details: http://www.linuxquestions.org/questions/showthread.php?p=5408355
[13:21:33 CEST] <satiender> ok
[14:37:52 CEST] <barneygale_> Hi all. How can I overlay black bars on the left/right of the video. I don't want to do any scaling or moving of the video, only an overlay
[14:41:39 CEST] <DHE> sounds like you want the 'pad' filter
[14:53:19 CEST] <barneygale_> sorted, thanks :)
[16:17:07 CEST] <PlanC> a guy has sent me 121 audio files from lectures
[16:17:22 CEST] <PlanC> the audio files were originally extracted from videos
[16:17:44 CEST] <PlanC> (a guy is classmate, just to make it clear)
[16:18:15 CEST] <PlanC> I noticed that he's set the bitrate of all of them to 256 kbps
[16:18:52 CEST] <PlanC> I checked the video on a few of the videos and the audio quality in the videos were at around 128 kbps
[16:19:05 CEST] <PlanC> that's double the size and it's taking up a lot of space on my computer
[16:19:28 CEST] <PlanC> (each audio file is at least an hour long)
[16:19:55 CEST] <PlanC> is there a way to optimize the audio files and have FFmpeg automatically decrease the quality of the files?
[16:20:24 CEST] <PlanC> so if the audio file is using a bitrate that's too high, then it'll simply decrease and save it
[16:25:04 CEST] <DHE> it doesn't work that way. he probably transcoded them to 256k rather than just ripping the audio out of the video files
[16:25:19 CEST] <PlanC> DHE: yeah, that's exactly what he did
[16:25:33 CEST] <DHE> you can transcode them yourself. there's a quality loss, obviously.
[16:25:51 CEST] <PlanC> the result is that they're in a higher bitrate even if the video originally had an audio of let's say 96k
[16:27:42 CEST] <PlanC> but, will there really be a quality loss if I decrease it from 256k to 192k even if the original video had an audio bitrate of 96k?
[16:32:34 CEST] <DHE> transcoding a transcoding will try to preserve the audio degredation of the original. it's always assumed to be worse than the original
[16:58:40 CEST] <PlanC> is there a way to change the ID3 without having to transcode the entire file?
[17:05:00 CEST] <janemba> hi
[17:05:41 CEST] <janemba> I'm trying to convert a mkv file to a mp4 file with subtitles. I extract subtitles from the mkv file and I use the following command -> http://pastebin.com/MnMPDYdN
[17:06:08 CEST] <janemba> I compiled ffmpeg with libass do you know how to resolv that ?
[18:00:02 CEST] <podman> Does anyone have an idea as to why -map_metadata -1 wouldn't remove a menu metadata?
[18:16:36 CEST] <Fyr> is ffmpeg.org working?
[18:19:12 CEST] <klaxa> yes
[18:22:09 CEST] <Fyr> it looks like down to me. =(
[18:23:50 CEST] <Fyr> I meant http://its.ffmpeg.org
[18:24:10 CEST] <Fyr> http://ffmpeg.org is working, http://its.ffmpeg.org is down.
[18:24:17 CEST] <jasom> Fyr: proper upsampling of audio has no effect on quality
[18:24:49 CEST] <Fyr> jasom, but every resampling reduces it, right?
[18:25:17 CEST] <jasom> Fyr: not if you do it properly and the frequencies are all within Nyquist
[18:27:22 CEST] <jasom> Downsampling from 192 to 48 will have a tiny effect on quality, as you will need to low-pass the signal first, and that will change the signal, but that one time loss is essentially zero compared to running the signal through speakers (which would have to low-pass anyway) and unless you have a 192kHz DAC you'll be doing the identical transform at playback
[18:28:02 CEST] <jasom> A good 24 kHz low-pass shouldn't have an audible effect on the frequencies the human ear can hear anyway
[18:28:46 CEST] <jasom> lastly pretty much all lossy codecs operate in the frequency domain, so resampling happens implicitly even when not converting the sampling rate.
[20:21:37 CEST] <circ-user-daFNu> If I'm trying to convert a png sequence to dnhd 175, what should my qmax be? I've tried everything from 1 to 1000 but I keep getting errors to increase qmax, but 1100 gives me errors
[20:21:58 CEST] <circ-user-daFNu> dnxhd*
[20:27:33 CEST] <antiatom> Hi all, trying to encode a VP8 stream here, but it turns out looking TERRIBLE with the following settings:
[20:27:36 CEST] <antiatom> vcodec=libvpx vb=8000 crf=9 g=120 bf=2 threads=0 rc_lookahead=16 quality=good speed=1 vprofile=0 qmax=51 qmin=11 slices=4 arnr_max_frames=7 arnr_strength=5 arnr_type=3
[20:29:20 CEST] <KarlFranz> There mist be something wrong in there.
[20:29:30 CEST] <KarlFranz> qmin is over your crf
[20:32:02 CEST] <antiatom> I just deleted it and tried simply
[20:32:04 CEST] <antiatom> vcodec=libvpx vb=8000 crf=9 g=120 bf=2 threads=8
[20:32:07 CEST] <antiatom> But it looks WORSE
[20:34:18 CEST] <KarlFranz> 8 threads???
[20:34:41 CEST] <buu> What's wrong with 8?
[20:35:08 CEST] <KarlFranz> Multithreading is good for speed, but it can mess with the result, or so I have been told.
[20:35:21 CEST] <buu> That's disturbing
[20:35:23 CEST] <KarlFranz> I suppose you won't notice anything bad with just 2.
[20:35:43 CEST] <KarlFranz> The reason is that you break the video in many parts that are compressed independently.
[20:35:53 CEST] <antiatom> So does 2 work worse than 1?
[20:36:12 CEST] <KarlFranz> Supposedly. But I doubt that is the problem
[20:36:21 CEST] <KarlFranz> crf is designed to run in multipas, by the way.
[20:36:47 CEST] <KarlFranz> I would not expect crf to look very well in single pass.
[20:37:26 CEST] <antiatom> ok
[20:45:42 CEST] <Anonaly> Hi, I run Ubuntu 12.04, and also I use from time to time WinFF to convert multimedia files
[20:46:03 CEST] <Anonaly> however I am getting a codec error about libfaac
[20:53:39 CEST] <Anonaly> The ffmpeg program is only provided for script compatibility and will be removed
[20:53:39 CEST] <Anonaly> in a future release. It has been deprecated in the Libav project to allow for
[20:53:39 CEST] <Anonaly> incompatible command line syntax improvements in its replacement called avconv
[20:53:39 CEST] <Anonaly> (see Changelog for details). Please use avconv instead.
[20:54:39 CEST] <durandal_1707> you are using ffmpeg from libav and not from ffmpeg
[20:56:18 CEST] <Anonaly> ok hmm how can I fix this ?
[20:56:23 CEST] <Anonaly> remove libav ?
[20:57:58 CEST] <Anonaly> durandal_1707, ?
[20:59:00 CEST] <durandal_1707> or ask for help on libav channel
[21:01:36 CEST] <Anonaly> thank you
[21:01:52 CEST] <Anonaly> putting this PPA in right now https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media
[21:03:09 CEST] <Anonaly> of course.. doesn't work
[21:03:11 CEST] <Anonaly> damn ppa'
[21:03:13 CEST] <Anonaly> s
[21:03:55 CEST] <iive> ffmpeg is in debian and soon it should be in ubuntu too...
[21:04:07 CEST] <iive> but you are with LTS version, aren't you?
[21:04:20 CEST] <Anonaly> yes
[21:04:29 CEST] <Anonaly> Ubuntu 12.04 LTS
[21:05:40 CEST] <Anonaly> I guess I will just have to compile it
[21:16:03 CEST] <Fyr> guys, kick the maintainers, its.ffmpeg.org still isn't working.
[21:23:54 CEST] <iive> "its" ?
[21:24:38 CEST] <Fyr> http://its.ffmpeg.org/wiki
[21:26:58 CEST] <Fyr> it's down.
[21:34:29 CEST] <iive> Fyr, what does "its" stand for... where did you get that url?
[21:34:36 CEST] <iive> the wiki is in trac.ffmpeg/org
[21:34:48 CEST] <Fyr> oops
[21:36:05 CEST] <Fyr> one of the first links in google on mp3 tags ffmpeg.
[21:36:27 CEST] <Fyr> I thought that "its" refers to ffmpeg's wiki.
[21:37:14 CEST] <Fyr> if it's not ffmpeg's, then whose is it?
[22:24:09 CEST] <llogan> never seen that url before
[23:22:34 CEST] <oscarpal> hello everyone how to hardsub to an mpeg dvd compliant file
[23:30:25 CEST] <llogan> oscarpal: see subtitles filter and use -target option with appropriate value
[00:00:00 CEST] --- Fri Aug 21 2015
1
0
[00:00:17 CEST] <Compn> http://ffmpeg.org/developer.html
[00:00:26 CEST] <Compn> Whichever way, changes should be reviewed by the maintainer of the code before they are committed.
[00:00:40 CEST] <Compn> or later on
[00:00:40 CEST] <Compn> Send your changes as patches to the ffmpeg-devel mailing list, and if the code maintainers say OK, you may commit. This does not apply to files you wrote and/or maintain.
[00:00:49 CEST] <Compn> Also note, the maintainer can simply ask for more time to review!
[00:01:02 CEST] <Compn> and then rule 19
[00:01:03 CEST] <Compn> Make sure that no parts of the codebase that you maintain are missing from the MAINTAINERS file. If something that you want to maintain is missing add it with your name after it. If at some point you no longer want to maintain some code, then please help finding a new maintainer and also dont forget updating the MAINTAINERS file.
[00:01:40 CEST] <Compn> please dont get upset, and feel free to request to change maintainers file (or rm it)
[00:01:47 CEST] <Compn> i'm just pointing out how you are wrong :)
[00:02:49 CEST] <Compn> >why bother, no one cares about developer policy/rules anymore, its anarchy
[00:05:36 CEST] <wm4> yep, means nothing
[00:07:14 CEST] <wm4> in this case the maintainer apparently wasn't aware that his maintained code was deprecated for years
[00:07:39 CEST] <Compn> yes i read the discussion
[00:08:03 CEST] <Compn> Daemon404 : i'm 90% sure that even clone will fail if you use wrong login (instead of anonymous clone)
[00:10:48 CEST] <Compn> sorry, its just hilarious, years ago commit messages were "fix bug" and then devs complained, so we made policy , now devs complain they dont like the policy anymore :P
[00:11:10 CEST] <Compn> obviously different waves of devs over the past 10 years. still, amusing.
[00:12:14 CEST] <Compn> why no one bothers to change policy if they dont like it, sigh
[00:13:45 CEST] <wm4> I kind of opened the wrong door with doubting the maintainer thing
[00:14:02 CEST] <wm4> because the bikeshed and infighting might go into this direction
[00:14:04 CEST] <wm4> well whatever
[00:14:31 CEST] <Compn> ahhhh dont worry about it
[00:14:36 CEST] <Compn> i predict peaceful negotiations.
[00:14:38 CEST] <Compn> :P
[00:22:39 CEST] <jamrial> doens't matter. let that thread devolve into shit flinging if that's the end result
[00:22:55 CEST] <jamrial> carl's commit is not valid so it wont go in
[00:43:55 CEST] <philipl> JEEB: Kodi has transitioned, althought they do grumble that with the new API ffmpeg is making vdpau calls. Apparently they liked how the old API made the application do more work :-)
[01:27:32 CEST] <BBB> __gb__: in case it matters, I think (for consistency) that removing the vld suffix in the non-deprecated code sounds good
[01:29:02 CEST] <wm4> philipl: I had the same issue
[01:29:20 CEST] <wm4> vdpau preemption is hard to handle, and the new api makes it harder
[01:41:44 CEST] <philipl> wm4: blame libav? :-P
[01:42:30 CEST] <philipl> Because it allocates resources internally that need to be invalidated?
[01:43:07 CEST] <philipl> There's a reset flag in the context which looks like it's supposed to be related to pre-emption but I don't see it being used properly.
[02:02:46 CEST] <BBB> whoooo wants to review https://github.com/rbultje/ffmpeg/commit/6a770eabd16bcd9c61f9b7a896d4f93ee8… ?
[02:03:03 CEST] <BBB> or any of the -ab related ones
[02:12:59 CEST] <jamrial> huh, i thought i replied to that email
[02:13:19 CEST] <BBB> you did?
[02:13:42 CEST] <jamrial> no, i didn't. i thought i did :p
[02:13:59 CEST] <BBB> ah, ok, I thought my mail client had gone blind
[03:53:19 CEST] <cone-190> ffmpeg 03Michael Niedermayer 07master:c1507db61760: fate: Force simple idct for fate-asf-repldata
[03:57:20 CEST] <llogan> i wonder if there is a more efficient way to keep docs updated. such as dumping directly from AVOption.
[04:23:07 CEST] <cone-190> ffmpeg 03Ronald S. Bultje 07master:6495c4c68713: lavfi: fix compilation with FF_API_OLD_FILTER_OPTS=0.
[05:14:52 CEST] <philipl> ubitux: Can you reply to Niklesh about the ASS default style?
[05:14:59 CEST] <philipl> I don't see how you access that
[10:01:16 CEST] <ubitux> philipl: ah damn, forgot to answer, will do
[11:44:18 CEST] <wm4> nevcairiel: so, are we ok with the VAAPI pixfmt renaming?
[11:44:45 CEST] <wm4> (seems a bit unnecessary, but I don't mind, especially if it comes with larger API changes)
[11:45:40 CEST] <nevcairiel> i find it unnecessary, but i dont really care
[11:49:58 CEST] <__gb__> I still think this is necessary for sanity purposes :)
[11:52:08 CEST] <wm4> then let's just give green light
[11:55:21 CEST] <wm4> __gb__: do you have push access?
[11:59:09 CEST] <__gb__> if the server is still on videolan.org, yes, of course
[11:59:22 CEST] <__gb__> but backlogging shows some issues at the moment?
[11:59:38 CEST] <wm4> dunno, try it
[12:01:15 CEST] <nevcairiel> it works fine for everyone except Daemon404 with his yodel internet
[12:08:48 CEST] <cone-247> ffmpeg 03Paul B Mahol 07master:fa95965f5aee: avfilter/vf_histogram: make it possible to pick color components for levels mode
[12:21:05 CEST] <wm4> __gb__: one minor thing: you could mention in APIchanges that AV_PIX_FMT_VAAPI has the same function and value as AV_PIX_FMT_VAAPI_VLD
[13:26:09 CEST] <__gb__> michaelni, ok with lavu 54.30.101 & lavc 56.57.102 or do you prefer bumping the minor instead?
[13:30:20 CEST] Action: __gb__ opted for lavu 54.31.100 & lavc 56.58.100 based on statistical analysis
[13:31:23 CEST] <wm4> that should be fine
[13:32:12 CEST] <j-b> use 100.100.100
[13:38:29 CEST] <michaelni> __gb__, ok
[13:38:50 CEST] <cone-247> ffmpeg 03Neil Birkbeck 07master:3dabebc272b0: libavformat/matroskaenc.c: fix small memory leaks on error
[13:50:58 CEST] <cone-247> ffmpeg 03Sven Dueking 07master:6eecb91fbc27: avcodec/qsvenc: Added PicTiming SEI
[14:17:00 CEST] <cone-247> ffmpeg 03Gwenole Beauchesne 07master:9f8e57efe440: vaapi: define a unique pixel format for VA-API (AV_PIX_FMT_VAAPI).
[14:17:01 CEST] <cone-247> ffmpeg 03Gwenole Beauchesne 07master:babd340f5849: vaapi: streamline public context structure.
[14:17:02 CEST] <cone-247> ffmpeg 03Gwenole Beauchesne 07master:8813d55fa597: vaapi: fix usage of invalid buffer ids.
[14:17:03 CEST] <cone-247> ffmpeg 03Gwenole Beauchesne 07master:9d1d7b367eeb: vaapi: drop unused include.
[14:30:24 CEST] <cone-247> ffmpeg 03Ivan Uskov 07master:fffae8e605c8: libavcodec/qsvdec.c: the ff_get_format() missed at refactoring has been restored
[14:58:54 CEST] <Daemon404> nevcairiel, no it works now
[15:44:15 CEST] <cone-247> ffmpeg 03Pedro Arthur 07master:62d176de1224: swscale: refactor vertical scaler
[15:48:41 CEST] <BBB> michaelni: do you have further thoughts on the -ab -> -b:a thing?
[16:16:00 CEST] <cone-247> ffmpeg 03Ronald S. Bultje 07master:99b9f0136c6e: fate: rename -error option to -error_rate.
[16:20:03 CEST] <cone-247> ffmpeg 03Henrik Gramner 07master:18b101ff595c: checkasm: Explicitly declare function prototypes
[16:20:04 CEST] <cone-247> ffmpeg 03Henrik Gramner 07master:e6b8797b827c: checkasm: x86: properly save rdx/edx in checked_call()
[16:43:07 CEST] <michaelni> BBB, if nothing breaks and all keeps working i have no further comments or thoughts
[16:44:12 CEST] <BBB> stuff seems to work for me
[16:44:23 CEST] <BBB> (I tested that -ab works after the patch with FF_API_OLD_AVOPTIONS=0)
[16:44:41 CEST] <BBB> (in ffmpeg bla bla -i bla bla -ab bla bla output.mp2)
[17:15:36 CEST] <wm4> what does the h264 decoder do if it gets 2 frames in 1 packet?
[17:17:53 CEST] <nevcairiel> thats an invalid API call =p
[17:18:09 CEST] <nevcairiel> probably error out or complain loudly
[17:18:16 CEST] <nevcairiel> or just skip one and error later about missing things
[17:18:35 CEST] <wm4> I don't know if that's what's happening, but at least I see no misbehavior
[17:18:47 CEST] <wm4> so, seems unlikely
[17:36:11 CEST] <BBB> wm4: I think it decodes both, but only returns one
[17:36:19 CEST] <BBB> (probably the first one)
[17:36:27 CEST] <BBB> and the second one may be cached for future return
[17:36:42 CEST] <BBB> so if you do that a lot, youll eventually have a ton of frames cached internally, causing huge decoder delay
[17:37:23 CEST] <nevcairiel> in short, we have a parser for that :D
[17:37:36 CEST] <BBB> wm4: I think the part where it may screw up has to do with frame threading, since well call setup_finished after the first frame is set up, even though the second ref isnt available yet then for next threads to use as one
[17:37:50 CEST] <BBB> wm4: but if you disable (frame) threading, it may work
[17:37:57 CEST] <BBB> and yes, use a parser
[17:38:26 CEST] <wm4> I'm comparing the MMAL decoder and the ffmpeg software decoder, and I'm trying to figure out why the MMAL decoder does not return a timestamp for a specific frame
[17:38:46 CEST] <wm4> but so far it looks like they decode exactly the same data
[17:38:55 CEST] <wm4> just that MMAL sometimes misses the timestamp
[17:40:55 CEST] <wm4> (and of course changing threads doesn't change anything in ffmpeg's results)
[17:50:02 CEST] <Daemon404> frozen summer fun will have ended?!
[17:50:04 CEST] <Daemon404> VDD is ruined.
[17:51:30 CEST] <kierank> you mean I can't get drunk and sing let it go
[17:51:47 CEST] <j-b> Daemon404: I'm sooo sorry
[17:51:58 CEST] <Daemon404> kierank, sure you can
[17:52:01 CEST] <j-b> yep
[17:53:01 CEST] <tab1293> Can anyone explain what the read, write, and seek callback functions are supposed to do in avio_alloc_context http://ffmpeg.org/doxygen/trunk/avio_8h.html#a853f5149136a27ffba3207d852017…
[17:53:28 CEST] <Daemon404> tab1293, you dont need them unless you want custom i/o
[17:53:41 CEST] <tab1293> Daemon404, yes I know, I do want custom I/O
[17:53:44 CEST] <Daemon404> ok
[17:53:50 CEST] <Daemon404> they do what they say on the tin
[17:54:02 CEST] <Daemon404> is there anything specific you need to know?
[17:54:42 CEST] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper…
[17:54:53 CEST] <tab1293> I am just a little confused as to what the docs mean when saying 'the function for refilling the buffer'
[17:55:02 CEST] <JEEB> basically you do something like this and set them accordingly
[17:55:04 CEST] <Daemon404> tab1293, it reads from your i/o
[17:55:06 CEST] <nevcairiel> it gives you a buffer, and a number of bytes it wants
[17:55:14 CEST] <nevcairiel> read buf_size bytes, put them into buffer
[17:55:17 CEST] <nevcairiel> return buf_size
[17:55:20 CEST] <nevcairiel> done!
[17:55:40 CEST] <nevcairiel> (return a number smaller than buf_size if there arent that many bytes left)
[17:56:01 CEST] <nevcairiel> JEEB: you really build that in C? you mad.
[17:56:12 CEST] <JEEB> inorite
[17:56:33 CEST] <nevcairiel> interestingly your other files are cpp =P
[17:57:03 CEST] <Daemon404> i heard JEEB does COM packing at night
[17:57:07 CEST] <Daemon404> for kinks
[17:57:42 CEST] <tab1293> so when exactly is your read_packet function called. should it be responsible for putting data into your i/o buffer?
[17:58:02 CEST] <JEEB> it's pretty much c, but it was easier to compile the rest as c++
[17:58:16 CEST] <Daemon404> tab1293, it is called whenever libavformat wants to read more into the buffer
[17:58:23 CEST] <JEEB> you still need a whole lot pf COM shit
[17:58:35 CEST] <Daemon404> aka when it exhausts the previois read, or needs more data
[17:59:45 CEST] <tab1293> Daemon404 I am trying to do custom i/o over a network. If I am trying to read a stream off of a socket, should the read or write packet function be pulling data off the socket and putting into the buffer?
[18:00:00 CEST] <Daemon404> you know we have networking built in for many protocols right?
[18:00:27 CEST] <Daemon404> tab1293, how you buffer your i/o is up to you, i guess
[18:00:40 CEST] <Daemon404> you can look at the socket code for our internal read/write if you want
[18:00:44 CEST] <Daemon404> it may be helpful
[18:01:43 CEST] <tab1293> okay I'll take a look is it libavformat/network.c?
[18:01:56 CEST] <tab1293> and also do you know the answer to my previous question?
[18:02:00 CEST] <philipl> ubitux: thanks!
[18:02:14 CEST] <Daemon404> tab1293, which question?
[18:03:46 CEST] <tab1293> Should read_packet or write_packet be responsible for loading an input stream's data into the custom buffer?
[18:04:35 CEST] <tab1293> still having trouble wrapping my head around the purpose of each function
[18:04:54 CEST] <Daemon404> int(*)(void *opaque, uint8_t *buf, int buf_size) read_packet,
[18:04:58 CEST] <Daemon404> it's exactly as nevcairiel said
[18:05:07 CEST] <Daemon404> you get a pointer, and a size, you fill that much
[18:09:26 CEST] <tab1293> Daemon404, okay but where is the opaque object coming from?
[18:09:51 CEST] <Daemon404> when you create the avio context you set it
[18:09:55 CEST] <Daemon404> as avioctx->opaque
[18:09:59 CEST] <Daemon404> it's whatever you want
[18:10:05 CEST] <Daemon404> your own thing
[18:10:46 CEST] <Daemon404> it can be e.g. state for your custom i/o
[18:12:25 CEST] <tab1293> Daemon404, okay i didn't see any explicit setting of that member in https://www.ffmpeg.org/doxygen/2.5/avio_reading_8c-example.html
[18:13:04 CEST] <Daemon404> ?
[18:13:07 CEST] <Daemon404> it's right there
[18:13:08 CEST] <Daemon404> &bd
[18:13:47 CEST] <tab1293> ohh whoops, was confusing bd with something else
[18:13:53 CEST] <tab1293> okay makes sense now
[18:20:56 CEST] <cone-247> ffmpeg 03Paul B Mahol 07master:2fa019958b4f: avfilter: add showfreqs filter
[20:11:03 CEST] <BBB> volunteer wanted for reviewing https://github.com/rbultje/ffmpeg/commit/e5bb803bdee35d67e1ffd4cc001a155fdf… ?
[20:12:52 CEST] <sanjana> Hello everyone. I am Sanjana Sharma, a third year undergraduate CSE student in IIIT Hyderabad. I would like to contribute to this community. Can anyone guide me how I can start with it?
[20:12:58 CEST] <wm4> BBB: emuedge seems like dark magic to me
[20:13:17 CEST] <wm4> BBB: and that lowres change looks strange, but that too is dark magic to me
[20:13:33 CEST] <BBB> always enable emu-edge is the basic assumption
[20:15:57 CEST] <jamrial> sanjana: there are many ways you can contribute. you could check http://trac.ffmpeg.org/ for bug tickets and fix some of them, or for feature requests and implement them
[20:16:55 CEST] <jamrial> you can browse ffmpeg's source tree for FIXME/TODO stuff and see if you can do something about them
[20:17:31 CEST] <jamrial> find something you're interested into and see if you can improve it
[20:17:57 CEST] <sanjana> jamrial: Thank you. Will get back to you. :)
[20:18:05 CEST] <jamrial> you could add new decoders, demuxers/muxers, filters, or improve/extend existing ones
[20:18:13 CEST] <llogan> you can subscribe to ffmpeg-devel to watch how patch submissions and reviews occur (but it's a high volume list)
[20:18:32 CEST] <jamrial> basically, whatever you feel like doing and think it will be useful
[20:19:31 CEST] <llogan> make sure to know basic git usage. if you're into hardware you can setup a fate client.
[20:19:38 CEST] <jamrial> take a look at https://ffmpeg.org/developer.html#Contributing as well
[20:20:34 CEST] <sanjana> Thanks a lot! :)
[20:35:20 CEST] <cone-247> ffmpeg 03Lou Logan 07master:4918726d4123: doc/indevs: add various missing options
[20:49:09 CEST] <cone-247> ffmpeg 03Lou Logan 07master:2edb7ab1cba6: MAINTAINERS: add myself as a docs maintainer
[21:39:23 CEST] <cone-247> ffmpeg 03Michael Niedermayer 07master:0b7829901bc9: */version.h: Add note/recommandition about bumping major
[21:41:53 CEST] <wm4> BBB, j-b: so what's the latest day and time of day I could appear on VDD?
[21:42:48 CEST] <BBB> saturday morning 9am
[21:43:30 CEST] <wm4> sounds impossible
[21:44:40 CEST] <Daemon404> people who show up late are forced to respond to users on libav-user
[21:45:03 CEST] <JEEB> lol
[21:45:13 CEST] <JEEB> a day on #ffmpeg could be enough :P
[21:47:15 CEST] <llogan> guest ML queue monkey
[22:10:50 CEST] <klaxa> okay, i think i found what i was doing wrong with AV_OPT_TYPE_BINARY, in any case, i now have a string representing binary data, are there convenience functions to turn such a string into binary again?
[22:11:04 CEST] <klaxa> i want to fill a sockaddr_storage struct with the data i get from av_opt_get()
[22:11:32 CEST] <klaxa> like i said, the string is in hex-representation, how do i reverse that?
[22:11:32 CEST] <BtbN> It's C. A string _is_ binary data.
[22:12:02 CEST] <klaxa> yes, av_opt_get() writes the binary data in ascii in a string though
[22:12:15 CEST] <nevcairiel> hm libav working on hevc simd, i bet it'll conflict bad with our stuff :(
[22:12:39 CEST] <klaxa> i.e. "1234" which in binary is not "1234" but whatever the ascii chars' numbers are as integers
[22:14:12 CEST] <klaxa> for example, getting a byte with the value 0x02 returns "02" which has the value 0x3032
[22:14:47 CEST] <klaxa> do you understand what my problem is?
[22:30:47 CEST] <BBB> nevcairiel: why?
[22:30:57 CEST] <BBB> nevcairiel: and why not just copy what the openhevc people wrote?
[22:31:15 CEST] <BBB> in the end, what matters is whos faster :)
[22:31:35 CEST] <nevcairiel> BBB: its libav, its NIH
[22:32:00 CEST] <nevcairiel> i should check how the things are written in our copy, and make sure th eirs doesnt diverge entirely
[22:32:39 CEST] <BBB> klaxa: snprintf(buf, %02x , data[0]); <-> sscanf(buf, %02x , &data[0]);
[22:32:43 CEST] <BBB> klaxa: is that helpful?
[22:33:16 CEST] <klaxa> ah, scanf is probably even better, i implemented a function that uses strtol()
[22:33:21 CEST] <klaxa> thanks BBB
[22:33:30 CEST] <BBB> yw
[22:37:27 CEST] <BBB> nevcairiel: a very quick look suggests we already have these optimizations that theyre talking about there
[22:37:36 CEST] <BBB> our mc is split by width (otherwise you cant write efficient assembly)
[22:37:46 CEST] <BBB> nevcairiel: and we have neon+x86
[22:38:21 CEST] <nevcairiel> which is why i am afraid they do something differently and we cannot benefit from each others things
[22:38:23 CEST] <BBB> nevcairiel: whats annoying about our simd is that its sse4/avx2 only
[22:38:41 CEST] <kierank> BBB: what's wrong with sse4/avx?
[22:39:25 CEST] <BBB> kierank: not everyone has sse4 cpus
[22:39:29 CEST] <philipl> 10 year old computers are computers too...
[22:39:32 CEST] <BBB> I typically recommend sse2/ssse3 as baseline
[22:39:36 CEST] <kierank> yes but to play hevc
[22:39:59 CEST] <wm4> I couldn't play HEVC with my previous core 2 duo
[22:40:00 CEST] <BBB> Im pretty sure I can play 1080p vp9 at 100fps
[22:40:09 CEST] <nevcairiel> BBB: for hevc, i wouldnt really want to play it at anything without sse4
[22:40:19 CEST] <philipl> Yeah.
[22:40:23 CEST] <BBB> (and I have a pre-sandybridge system)
[22:40:23 CEST] <iive> i've heard that sssse3 and sse4 doesn't have many new instruction useful for multimedia
[22:40:39 CEST] <iive> how hard is porting to sse2?
[22:40:40 CEST] <BBB> iive: you were sadly misinformed
[22:40:46 CEST] <ubitux> (these optims are just NIH provocation or half of it is actually new?)
[22:40:51 CEST] <BBB> ssse3 introduced pmaddubsw, which is probably the best thing in the world
[22:41:05 CEST] <BBB> theres some other instructions also that are good
[22:41:11 CEST] <iive> multiply and add bytes to word
[22:41:19 CEST] <JEEB> sse3 was the useless'ish
[22:41:23 CEST] <wm4> ubitux: why do you call it a provocation
[22:41:23 CEST] <philipl> __gb__: Will the skylake vp9 acceleration be exposed through vaapi?
[22:41:37 CEST] <wm4> skylake has vp9?
[22:41:46 CEST] <BBB> nevcairiel: I think we can play hevc on ssse3 machines
[22:41:47 CEST] <BBB> nevcairiel: I
[22:41:49 CEST] <ubitux> wm4: dunno, what would be the other reason?
[22:41:53 CEST] <philipl> It has partial dedicated vp9 with GPGPU doing other parts
[22:41:55 CEST] <BBB> nevcairiel: not sure about sse2& that may be far off
[22:42:03 CEST] <BBB> nevcairiel: but ssse3 should work, even for hd material (1080p)
[22:42:10 CEST] <wm4> ubitux: they prefer to ignore ffmpeg's existence, thus it can't be a "NIH provocation"
[22:42:37 CEST] <ubitux> dunno, i don't believe in this ignore
[22:42:44 CEST] <ubitux> that would be too stupid
[22:42:52 CEST] <philipl> wm4: I'm guessing it will be as they've added vp9 to vaapi - I assume they wouldn't do that if there's no hardware to back it this year.
[22:43:12 CEST] <nevcairiel> i'm still sad dxva2 doesnt have specs for vp8/vp9 to use the intel hardware
[22:43:38 CEST] <philipl> nevcairiel: yeah, but that would require MS acknowledge that vp8/9 exist.
[22:43:47 CEST] <philipl> nvidia hardware has support too, but no API.
[22:44:18 CEST] <BBB> well, so
[22:44:23 CEST] <BBB> ubitux: the good thing is
[22:44:32 CEST] <BBB> ubitux: we can now use checkasm to quickly check perf of theirs vs ours asm
[22:44:34 CEST] <nevcairiel> even the CUVID API doesnt support vp8/9, which is weird
[22:44:36 CEST] <BBB> and then we know which is better
[22:45:20 CEST] <jamrial> anton's patches don't mention openhevc as the source of the asm, so i wonder if they really rewrote it...
[22:45:21 CEST] <ubitux> assuming usages match
[22:45:22 CEST] <philipl> nevcairiel: There was a linux nvidia driver release that claimed to add vp8 support but no cuda release has vp8 headers
[22:46:09 CEST] <philipl> nevcairiel: In theory, it's on the vdpau todo list but low priority
[22:47:54 CEST] <BBB> jamrial: I think its new
[22:48:03 CEST] <BBB> jamrial: since its sse2/ssse3/avx, not sse4/avx2
[22:48:10 CEST] <BBB> its like, they wrote exactly that which we dont have
[22:48:25 CEST] <BBB> Id almost suggest to merge it so we have complete instruction set coverage, but that would be stupid
[22:48:37 CEST] <BBB> would be very ffmpeg though, MERGE EVERYTHING!!112
[22:48:45 CEST] <BBB> :-p
[22:48:59 CEST] <BBB> (j/k, in case anyone is thinking thats serious)
[22:50:06 CEST] <iive> can you write better ones?
[22:50:07 CEST] <jamrial> heh
[22:50:13 CEST] <jamrial> looks like they refactored some stuff. the prototypes don't match
[22:50:24 CEST] <jamrial> it wont be a conflic-less merge
[22:50:29 CEST] <cone-247> ffmpeg 03Michael Niedermayer 07master:034e6fbd9cdb: configure: Check for CoreServices/CoreServices.h and make vda+viedotoolbox depend on it
[22:50:48 CEST] <iive> jamrial: refactoring is their second name :)
[22:50:55 CEST] <wm4> nice typo
[22:51:25 CEST] <BBB> iive: yes
[22:51:29 CEST] <BBB> iive: the question is if I will
[22:51:51 CEST] <iive> write them under GPL, and ask for ransom :)
[22:51:55 CEST] <BBB> no
[22:52:03 CEST] <BBB> most companies use gpl code internally in their datacenters
[22:52:07 CEST] <BBB> it doesnt help anyone
[22:52:26 CEST] <BBB> iive: theres very expensive and elite companies out there using our code. hevc is extremely valuable and difficult to understand and write
[22:52:43 CEST] <BBB> if they want me to write their corporate code and make it 2x as fast as anything theyll ever see, theyll have to pay me
[22:52:51 CEST] <BBB> they can also wait for someone else to write it for free
[22:53:05 CEST] <iive> they will wait...
[22:53:09 CEST] <BBB> I know
[22:53:10 CEST] <BBB> :)
[22:54:00 CEST] <BBB> I still get questions about why the vp9 decoder ubitux/me wrote (+ some simd from jamrial) is so much faster than xyz
[22:54:05 CEST] <BBB> people do see its faster
[22:54:08 CEST] <BBB> they also dont understand why
[22:54:28 CEST] <iive> :))
[22:54:41 CEST] <BBB> so &
[22:55:03 CEST] <iive> do you have a fixed bounty for the task?
[22:56:28 CEST] <BBB> nothing specific
[22:56:43 CEST] <jamrial> before the high bitdepth changes, VP9 had probably the most clean looking and slick code in our tree
[22:57:15 CEST] <BBB> yeah the hbd stuff made it a little ugly :(
[22:57:28 CEST] <BBB> it also got ~2% slower or so?
[22:57:33 CEST] <BBB> it wasnt ideal
[22:57:38 CEST] <BBB> but it does support hbd now&
[22:58:05 CEST] <jamrial> no idea, didn't bench before and after
[23:00:00 CEST] <BBB> it sounds like you consider vp9 a snowflake (http://www.stilldrinking.org/programming-sucks)
[23:00:08 CEST] <BBB> sorry about that
[23:03:07 CEST] <jamrial> haha
[23:25:30 CEST] Action: Daemon404 catches up on vdpau lulz
[23:26:41 CEST] <jamrial> libav's hevc is wildly different to our. they apparently lack a lot of openhevc changes from the past two years
[23:39:59 CEST] <smarter> yeah, I gave up reviewing and merging those changes in libav
[23:42:48 CEST] <j-b> wm4: what can you do?
[23:42:50 CEST] <smarter> if there's an effort to make the two projets converge I'd be willing to spend time to merge the two codebases, otherwise it's not very motivating work
[23:45:31 CEST] <BBB> I second that
[23:46:10 CEST] <j-b> smarter: can I talk to you in private?
[23:46:13 CEST] <smarter> j-b: sure
[00:00:00 CEST] --- Thu Aug 20 2015
1
0
[00:13:41 CEST] <TikityTik> What's the point of deinterlacing?
[00:14:38 CEST] <KarlFranz> Progressive video looks better on some screens.
[00:14:57 CEST] <KarlFranz> non-progressive supposedly looks better on some TV sets.
[00:15:56 CEST] <KarlFranz> When I am playing non progressive on my computer, I run a deinterlacing filter at playback time. I don t encode for appying deinterlacing
[00:19:13 CEST] <DHE> eyes want to see progressive. only use interlacing if going to an interlacing-aware device (eg: television)
[00:29:08 CEST] <TikityTik> KarlFranz: why on TV sets?
[00:29:16 CEST] <TikityTik> Aren't TV sets basically like PC monitors now?
[00:33:14 CEST] <KarlFranz> That is why I didn't say every TV set :-)
[00:33:37 CEST] <KarlFranz> My own sets are old and I don watch TV, actually.
[00:34:07 CEST] <KarlFranz> I am dettached of the current state of thinngs with TV technology
[01:34:01 CEST] <jasom> ffmpeg 2.6.3 on gentoo, dvd source, overlaying subitles, I get messages like: frame=258747 fps=162 q=23.0 size= 474149kB time=02:23:52.45 bitrate= 450.0kbits[Parsed_overlay_0 @ 0x25ba530] [framesync @ 0x22c9a68] Buffer queue overflow, dropping.
[02:11:29 CEST] <nanoEng> Can anyone help me with a compile error?
[02:13:00 CEST] <nanoEng> http://pastebin.com/RYYpeCqU
[02:18:44 CEST] <deivor> Hi, I'd like to know if there's any way to set the 'strength' of the highpass/lowpass audio filters. Audacity has this feature and I have to use audacity only for that some times
[02:19:01 CEST] <llogan> nanoEng: how do we reproduce the issue?
[02:24:51 CEST] <deivor> I meant "rolloff" not strength
[02:27:30 CEST] <nanoEng> Anyone know how I can enable 64bit compile? I keep getting http://pastebin.com/RYYpeCqU
[02:30:35 CEST] <llogan> nanoEng: how can we reproduce the issue?
[02:30:59 CEST] <nanoEng> compiling using windows 8.1,
[02:31:12 CEST] <nanoEng> ./configure --host-os=x86_64 --enable-sdl --disable-programs --disable-encoders --enable-ffplay --disable-d3d11va --disable-dxva2 --arch=x86_64 --disable-shared --target-os=win32 --enable-static --disable-doc --prefix=TEST2 --disable-ffmpeg --disable-ffprobe --disable-ffserver --disable-network --enable-gpl --enable-swscale --enable-memalign-hack --enable-yasm --disable-mmx --disable-mmxext
[02:31:27 CEST] <nanoEng> using MSYS2 and mingw-w64
[02:31:33 CEST] <deivor> do you need host-os / arch if compiling native?
[02:31:48 CEST] Action: llogan becomes comatose at mention of "windows 8.1"
[02:31:59 CEST] <nanoEng> yeah, so do i
[02:32:35 CEST] <nanoEng> I get ARCH=x86 (general)
[02:32:40 CEST] <nanoEng> after ./configure
[02:32:57 CEST] <nanoEng> i am now thinking my problem is --target-os=win32
[02:33:16 CEST] <nanoEng> but there's no such thing as --target-os=win64
[02:35:14 CEST] <nanoEng> I must include --tagrget-os
[02:35:35 CEST] <nanoEng> If I do not, I get Unknown OS 'msys_nt-6.3'.
[02:37:14 CEST] <nanoEng> If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-user(a)ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net. Include the log file "config.log" produced by configure as this will help solve the problem.
[02:37:45 CEST] <nanoEng> would you like the config.log ?
[02:47:15 CEST] <c_14> nanoEng: Have you tried the zeranoe forums? There might be someone there who has experience compiling for Windows 8.1
[02:52:15 CEST] <nanoEng> c_14 zeranoe is useless, that is for compiling for Windows, but using Debian.
[02:54:27 CEST] <c_14> Have you tried asking on the user mailing list?
[02:54:32 CEST] <c_14> Might reach someone that way.
[02:57:47 CEST] <nanoEng> hmm
[02:58:35 CEST] <nanoEng> alright c_14, thanks
[02:58:44 CEST] <nanoEng> i'll keep checking here and see about the mailing list
[03:12:05 CEST] <occupant> so I tried compiling with static x264 and it complains about a missing .so when I execute, which seems to defeat the purpose of having it statically compiled. I'm guessing I did something wrong?
[03:12:28 CEST] <c_14> Which .so is missing?
[03:12:37 CEST] <occupant> even though I'm on the same box where I built it, so it should know where to find the path regardless
[03:12:48 CEST] <c_14> What was your configure line?
[03:13:24 CEST] <occupant> libx264.so.148, used --enable-libx264 and --pkg-config-flags=--static
[03:14:05 CEST] <c_14> --enable-static --disable-shared
[03:15:12 CEST] <occupant> ah crap, I did not do --enable-static
[03:15:19 CEST] <occupant> did do --disable-shared though
[03:30:35 CEST] <occupant> c_14: still complaining of missing .so. my full config: --enable-runtime-cpudetect --enable-static --disable-debug --disable-ffserver --disable-ffplay --disable-shared --enable-libfaac --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-gpl --enable-nonfree --pkg-config-flags=--static
[03:31:18 CEST] <occupant> whoah, how did --enable-gpl creep in there
[03:31:58 CEST] <llogan> because you wanted libx264
[03:32:58 CEST] <occupant> so I'm guessing I still got some option wrong relating to static
[03:40:12 CEST] <c_14> Do you have a libx264.a?
[03:42:08 CEST] <occupant> yeah I made it from source just now, but it doesn't seem like it's being baked into the build properly.
[03:42:20 CEST] <occupant> the configure script found it and built against it
[03:42:27 CEST] <c_14> Where is it?
[03:42:46 CEST] <occupant> /usr/local/lib
[03:43:14 CEST] <c_14> Is that in your PKG_CONFIG_PATH ?
[03:43:31 CEST] <c_14> Well, /usr/local/lib/pkgconfig in that case
[03:47:32 CEST] <occupant> yeah, there's a pc file for it
[03:47:45 CEST] <c_14> Yes, but is it in your PKG_CONFIG_PATH ?
[03:48:00 CEST] <c_14> export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
[03:48:18 CEST] <c_14> The other order might be better though
[03:49:37 CEST] <c_14> This is under the assumption that you have another x264.pc file flying around somewhere
[03:51:33 CEST] <occupant> it isn't, but the fact that the binary knows about the specfic revision of the .so makes me think it found it okay, but that's not an environment variable I'm used to twiddling.
[03:52:05 CEST] <c_14> It just tells pkg-config where to look for .pc files
[03:53:00 CEST] <occupant> and didn't the .pc file tell it about the specific .so.148?
[03:53:11 CEST] <occupant> so the fact that it's complaining about its absence means that it was initially found
[03:53:59 CEST] <occupant> maybe I'm entirely misunderstanding this though
[03:59:30 CEST] <c_14> I'm pretty sure pkg-config doesn't set the rpath, so even if it links it could still fail on runtime because the so isn't in one of the default paths
[04:00:58 CEST] <c_14> Or rather, isn't used to set the rpath. It can't set it itself.
[04:06:05 CEST] <occupant> yeah, if I set my ld_library_path to include /usr/local/lib and run ldconfig, it works fine. so the problem is that it's never being statically linked to begin with
[04:06:36 CEST] <c_14> Well, if it were statically linked it wouldn't ask for a .so
[04:08:02 CEST] <occupant> yeah that IS entirely sensible, but why wasn't it? I had static options in my config but apparently I didn't do 'em right.
[04:16:58 CEST] <c_14> What does pkg-config --static --libs --cflags x264 output?
[04:34:30 CEST] <occupant> c_14: alright, I shouldn't have doubted when I didn't really understand. I thought that configure picking up the location meant everything was good, but pkg_config_path was indeed necessary. binary is fully portable. thanks for the nudge.
[05:43:25 CEST] <k_sze> Would somebody be explain to me what's the deal with YUVJ vs YUV?
[05:43:35 CEST] <k_sze> *be able to
[05:44:48 CEST] <k_sze> I have some video files on hand with yuvj422p pixel format. When I decode using PyAV (a wrapper over the ffmpeg libraries in Python), I get a deprecated pixel format warning.
[05:48:32 CEST] <haole> my ffmpeg install says that the filter "mp" doesn't exist... I wanted to increase the brightness with -vf mp=eq2=1:1:0.3:1:1:1:1
[05:48:36 CEST] <haole> what dependency am I missing?
[05:52:26 CEST] <c_14> haole: the mp filters were all ported recently. the filter you want is now called 'eq'
[05:55:21 CEST] <haole> c_14: thanks
[05:56:33 CEST] <haole> c_14: do you know how to do a passthrough with the audio? don't want to lose time transcoding it
[05:56:38 CEST] <c_14> -c:a copy
[05:56:49 CEST] <haole> or is this already happening: Stream #0:1 -> #0:1 (aac (native) -> aac (libfaac))
[05:56:54 CEST] <haole> thanks
[05:56:55 CEST] <c_14> No, that's reencoding.
[05:57:01 CEST] <c_14> It'll say copy if it's copying it
[05:57:53 CEST] <haole> I want to increase the brightness, but it's so slow for x264
[05:57:54 CEST] <haole> Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
[05:58:07 CEST] <c_14> -preset ultrafast
[05:58:09 CEST] <haole> is there a way to make this faster? or my computer simply sucks for this? :D
[05:58:11 CEST] <haole> ha!
[05:58:14 CEST] <haole> :)
[05:58:18 CEST] <c_14> (there's also veryfast and faster)
[05:58:33 CEST] <c_14> Note, with crf encoding (the default) they will make the output bigger
[05:59:03 CEST] <haole> sweet! 5x speed boost
[05:59:06 CEST] <haole> thanks a lot :)
[05:59:33 CEST] <haole> chromecast is stupid, so I'm making some scripts to automagically convert my files to play in my TV and look good
[06:00:02 CEST] <haole> chromecast usually gets very dark there and increasing the TV brightness will give me "gray" areas instead of black ones
[06:00:07 CEST] <haole> must be related to gamma, don't know
[06:01:04 CEST] <c_14> k_sze: yuvj is full-range yuv (ie 0-255), while yuv is limited range (16-240 iirc). The deprecation message occurs afaik because the "yuvj*" formats were deprecated in favor of "yuv*" with color_range jpeg
[06:03:29 CEST] <c_14> haole: I don't know much about chromecast, but that shouldn't happen. Unless the colors on your TV are weird
[06:03:43 CEST] <buu> What would be the correct set of options to force keyframes every 2 seconds?
[06:04:56 CEST] <c_14> Either -g [fps * 2] (the preferred method) or -force_key_frames expr:gte(t,n_forced*2)
[06:05:27 CEST] <buu> Oh
[06:05:31 CEST] <buu> Is that actually in the man page?
[06:05:52 CEST] <c_14> yes
[06:06:33 CEST] <buu> it totally isn't!
[06:06:37 CEST] <buu> I just checked, there's no -g option
[06:07:13 CEST] <buu> It's mentioned in a couple of examples
[06:07:23 CEST] <pzich> yeah, look at tips
[06:07:59 CEST] <buu> That's not really documented
[06:08:16 CEST] <buu> Anyway, what if the fps is like, 29.whatever
[06:08:32 CEST] <pzich> then pass in 30000/1001
[06:08:52 CEST] <buu> !
[06:09:10 CEST] <buu> -g expr:3000.. ?
[06:10:13 CEST] <c_14> buu: https://www.ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
[06:10:39 CEST] <c_14> The third option listed there under options
[06:12:10 CEST] <c_14> The gop is always codec specific so it'll be lited under the options for the specific codec.
[06:12:16 CEST] <c_14> *listed
[06:12:53 CEST] <buu> Nifty
[06:46:13 CEST] <FunkyELF> where can I get static builds? I thought there used to be a link from the ffmpeg.org site
[07:01:14 CEST] <relaxed> FunkyELF: there still is, http://johnvansickle.com/ffmpeg/
[07:01:44 CEST] <relaxed> (or mouse over your OS)
[07:01:54 CEST] <FunkyELF> relaxed: yeah... I guess it was a little better before when ffmpeg linked there. Now its just some guy's website with binaries to download
[07:03:07 CEST] <relaxed> I'm that some guy. How was it better in the past?
[07:05:03 CEST] <pzich> I think I've used those before, thanks!
[11:21:41 CEST] <qFox> hi. is there a trick to merging two audio tracks at different volumes? whatever I try it seems the result has the same volume.
[11:22:11 CEST] <qFox> i've tried pan=stereo|c0=c0*0.1+c2|... when amerge or amixing but that doesn't seem to help
[11:22:24 CEST] <qFox> i've tried applying individual volume filters, same result
[11:23:54 CEST] <qFox> i was getting to that :) https://gist.github.com/qfox/9951355d38da548136ee
[11:23:55 CEST] <c_14> (for the record I've had it work with volume filters followed by amix)
[11:24:31 CEST] <qFox> well it seems whatever i try, the end result has the same volume levels
[11:24:45 CEST] <qFox> so i'm very likely to be missing a key element in the process :)
[11:28:25 CEST] <c_14> works for me
[11:28:31 CEST] <c_14> What version of ffmpeg are you using?
[11:28:47 CEST] <qFox> ultimately the whole thing was one mkv to start with. it has a video track and three audio tracks; 0=everything, 1=background only, 2=microphone only. i'm trying to produce a new mkv with a single audio track and specific volume levels of the second and third audio track, something like this: https://gist.github.com/qfox/37a7f36e60bd8d7e8f82
[11:29:01 CEST] <qFox> ffmpeg version 2.5.8-0ubuntu0.15.04.1
[11:29:24 CEST] <c_14> update
[11:29:26 CEST] <c_14> preferably to git
[11:29:32 CEST] <qFox> oh :/
[11:29:32 CEST] <c_14> You can use a static build to try
[11:29:34 CEST] <c_14> http://johnvansickle.com/ffmpeg/
[11:32:23 CEST] <qFox> ok. no change in the mkv (the last gist)
[11:32:35 CEST] <qFox> trying the mp3 only one
[11:33:29 CEST] <qFox> same. meh
[11:34:49 CEST] <c_14> hmm, I tried with flac instead of mp3, but that shouldn't be it
[11:38:36 CEST] <qFox> may have found the problem. for some reason this video also had the background recorded into the mic track
[11:39:12 CEST] <qFox> well either that or I messed it up in post processing somehow. regardless, that would explain a lot for me.
[11:40:06 CEST] <c_14> It works now?
[11:40:31 CEST] <qFox> and the video recorded after this one also has that "problem". must have screwed something up in the recording software config.
[11:40:43 CEST] <qFox> well it wont work on that file since i no longer have a mic-only track
[11:41:08 CEST] <c_14> You can test with this command: ffmpeg -f lavfi -i aevalsrc="sin(440*2*PI*t):s=48000:c=stereo" -f lavfi -i aevalsrc="sin(800*2*PI*t):s=48000:c=stereo" -filter_complex '[0][1]amerge,pan=stereo|c0=0.1*c0+c2|c1=0.1*c1+c3' -t 10 out.flac
[11:41:10 CEST] <qFox> i was under the assumption i had a background-only and a mic-only track, as most of my videos do.
[11:41:14 CEST] <c_14> to rule out any file-specific issues
[11:41:46 CEST] <qFox> thanks
[11:42:14 CEST] <c_14> (note, sine waves are very annoying)
[11:42:23 CEST] <qFox> yep
[11:43:25 CEST] <qFox> meh. recording software is indeed set to record the background music into all tracks. probably a default setting it used when switching audio inputs. well that blows :/
[11:43:51 CEST] <qFox> anyways. guess it can't be helped for this video. thanks for the help :)
[11:44:14 CEST] <c_14> np
[12:27:25 CEST] <satiender> Hi how we can use ffmpeg for android OS
[12:27:31 CEST] <satiender> please help ??
[14:35:05 CEST] <satiender> hi anybody compile ffmpeg for android
[17:08:14 CEST] <barbek> Hi guys! I'm trying to create desktop streaming solution on Wondiws using ffmpeg and Qt. I've managed to make it using ffmpeg and ffplay commands http://pastebin.com/aVRQJEdQ .
[17:09:20 CEST] <barbek> I have few question: 1. what output formats I can choose or where can I find this info? I tried to use matroska instead of mpegts but ffplay doesn't play that. I fairly new to ffmpeg so my question might sound silly.
[17:10:23 CEST] <barbek> 2. How can I change grabbing quality? Currently it looks awful at full-screen resolution and I don't know why
[17:11:51 CEST] <barbek> 3. ffplay start to play stream from the moment stream was launched, to from the moment ffplay was launched. Looks like ffmpeg has internal queue - how can I disable it in order to play see only live image?
[17:19:39 CEST] <Oleg_> c_14, are you there?
[17:51:26 CEST] <tab1293> Can anyone explain what the read, write, and seek callback functions are supposed to do in avio_alloc_context http://ffmpeg.org/doxygen/trunk/avio_8h.html#a853f5149136a27ffba3207d852017…
[18:42:35 CEST] <klaxa> tab1293: those are functions called by avio_read/write/seek
[18:53:41 CEST] <Laurenceb> hi
[18:53:53 CEST] <Laurenceb> how can i extract all frames over a specific timerange?
[18:54:10 CEST] <Laurenceb> ffmpeg -i GOPR0080.MP4 -r 240 -f image2 -ss 9 image%d.jpg
[18:54:14 CEST] <Laurenceb> this is failing
[18:54:16 CEST] <Laurenceb> no outpuit
[19:02:04 CEST] <klaxa> try moving -ss before -f image2
[19:03:49 CEST] <Laurenceb> aha thanks
[23:24:05 CEST] <newtoFFmpeg> hello
[23:25:33 CEST] <newtoFFmpeg> Hello All,
[23:27:27 CEST] <newtoFFmpeg> ffserver allows delivering content using http and rtsp. I want to know if this means client is streaming or progressively downloading the media. Can someone elaborate?
[23:39:40 CEST] <newtoFFmpeg> Another question, does ffserver support adaptive streaming?
[00:00:00 CEST] --- Thu Aug 20 2015
1
0
[00:03:17 CEST] <Compn> BBB : just make an alias for -ab to -b:a
[00:03:30 CEST] <Compn> we make these kinds of aliases all day long to keep user scripts working
[00:03:31 CEST] <Compn> no big deal
[00:03:35 CEST] <BBB> Compn: alias?
[00:03:37 CEST] <Compn> mask
[00:03:40 CEST] <Compn> whatever its called
[00:03:41 CEST] <BBB> mask?
[00:03:57 CEST] <BBB> Compn: sorry, Im going to sound very stupid here
[00:04:03 CEST] <BBB> but I know tons of stuff about codecs
[00:04:07 CEST] <BBB> but ffmpeg.c is black magic to me
[00:04:21 CEST] <BBB> ffmpeg_*.c also
[00:04:41 CEST] <Compn> ah, we have killed old options before, we just reuse the old option name and map it to the new option name
[00:05:03 CEST] <Compn> i can probably find a commit if you want to see how its done before
[00:05:13 CEST] <BBB> that sounds lovely
[00:05:14 CEST] <BBB> ty
[00:08:27 CEST] <ubitux> BBB: Compn is refering to opt_old2new()
[00:08:31 CEST] <ubitux> in ffmpeg_opt.c
[00:08:36 CEST] <BBB> aha
[00:08:39 CEST] <BBB> ok, Ill have a look
[00:08:52 CEST] <BBB> does that also work for the avfilter syntax changes?
[00:08:56 CEST] <BBB> (: -> |)
[00:09:32 CEST] <ubitux> it justs maps ffmpeg option like -absf to -bsf:a
[00:09:36 CEST] <ubitux> for compatiblity
[00:09:45 CEST] <ubitux> it's a 5 lines function
[00:10:52 CEST] <cone-889> ffmpeg 03Ronald S. Bultje 07master:cdbd3b1e7d0d: fate: move -flags +mv0 -> -mpv_flags +mv0.
[00:11:14 CEST] <ubitux> BBB: and yeah, these are subtitles; it's just ass, but you have to keep in mind that each "time tick" is basically a shit load of markup which are generated with some kind of lua scripting
[00:11:29 CEST] <BBB> creepy
[00:11:39 CEST] <BBB> Im just going to assume subtitles are from some alien world
[00:11:42 CEST] <ubitux> which you can find in "comments" in ass; aegisub uses them as templates
[00:11:46 CEST] <BBB> video codecs are much easier
[00:11:51 CEST] <ubitux> yeah...
[00:12:02 CEST] <wm4> they're also more efficient
[00:12:03 CEST] <ubitux> let's say codecs are way more structured
[00:12:04 CEST] <wm4> much more
[00:12:15 CEST] <Compn> ubitux : thanks , i was googling and was not finding that :\
[00:12:25 CEST] <wm4> to the point there are performance problems playing "subtitles", while the high bitrate 10 bit h264 doesn't make a dent on the CPU
[00:12:35 CEST] <ubitux> problem with subtitles is that we are giving weapons to monkeys
[00:12:57 CEST] <ubitux> and they love to abuse them, obviously
[00:13:07 CEST] <ubitux> still, it's funny to watch
[00:13:18 CEST] <cone-889> ffmpeg 03Ronald S. Bultje 07master:61043777d747: fate: explicitly specify audio bitrate for adpcm/mp2fixed tests.
[00:13:23 CEST] <ubitux> i personally really enjoy when i see such karaoke madness in animes
[00:13:29 CEST] <ubitux> (not that common anymore unfortunately)
[00:13:44 CEST] <wm4> "unfortunately"
[00:13:59 CEST] <ubitux> well, maybe i'm just watching different kind of animes nowadays
[00:14:30 CEST] <ubitux> wm4: i love when i see ASS nicely exploited
[00:15:01 CEST] <ubitux> i generally notice them when it puts my war machine on its knees
[00:15:20 CEST] <ubitux> it's crazy that a computer won't have troubles decoding 4k in any insane codecs
[00:15:21 CEST] <wm4> "war machine"?
[00:15:27 CEST] <ubitux> but can't handle text
[00:15:36 CEST] <ubitux> yeah well, powerful computer if you prefer
[00:15:36 CEST] <wm4> well that's just ASS being shit
[00:15:43 CEST] <ubitux> dunno
[00:15:49 CEST] <j-b> it's a bad format.
[00:15:51 CEST] <wm4> I got a new computer, I need to test that 80MB subtitle script
[00:15:55 CEST] <ubitux> font handling is some crazy shit man
[00:16:02 CEST] <ubitux> haha
[00:16:12 CEST] <wm4> still not realtime
[00:16:16 CEST] <wm4> drops frames like crazy
[00:16:19 CEST] <ubitux> j-b: it's by far the best out there
[00:16:37 CEST] <wm4> I don't know how old this file is, but the file date says 2012
[00:16:38 CEST] <BBB> font handling is shit indeed
[00:16:45 CEST] <wm4> and this is a skylake cpu
[00:16:47 CEST] <BBB> I did some playing around with gl stuff
[00:16:54 CEST] <wm4> (ok skylake is shit, but you get the idea)
[00:17:17 CEST] <BBB> overlays for mvs, no issue
[00:17:23 CEST] <ubitux> wm4: yeah well, i suppose it was meant to be hardsubbed anyway
[00:17:25 CEST] <BBB> as soon as you do text overlays, *poof*, it all dies
[00:17:31 CEST] <BBB> (performance-wise)
[00:18:08 CEST] <ubitux> shaping, kerning, aliasing
[00:18:22 CEST] <ubitux> hey btw, aren't they introducing some kind of freaky turing machines in font now?
[00:18:30 CEST] <wm4> uh you're late
[00:18:38 CEST] <ubitux> no i mean, new gen
[00:18:44 CEST] <ubitux> where did i see that
[00:18:44 CEST] <wm4> truetype bytecode is how old, 30 years?
[00:19:00 CEST] <ubitux> yeah but now more advanced
[00:19:18 CEST] <ubitux> ah yeah
[00:19:20 CEST] <ubitux> http://blogs.windows.com/bloggingwindows/2015/02/23/windows-shapes-the-worl…
[00:19:22 CEST] <ubitux> this
[00:19:27 CEST] <wm4> I know they're putting colors and pngs in fonts now
[00:19:43 CEST] <ubitux> yeah, to fix racist emojis
[00:20:06 CEST] <ubitux> anyway, harfbuzz implemented that universal shaping engine in 1.0.0
[00:20:28 CEST] <wm4> this shaping stuff is a good thing
[00:20:36 CEST] <wm4> it actually simplifies software
[00:20:40 CEST] <wm4> or so I heard
[00:20:47 CEST] <wm4> while before, everything had to be hardcoded
[00:21:02 CEST] <wm4> just don't run your font code in an OS kernel
[00:21:27 CEST] <Compn> so is google going to fix this stagefright bug or what
[00:21:35 CEST] <Compn> also, windows caring about security? hahaha
[00:21:42 CEST] <Compn> er s/windows/microsoft
[00:21:58 CEST] <rcombs> Compn: they did
[00:22:03 CEST] <rcombs> a while ago
[00:22:12 CEST] <rcombs> but phone vendors aren't updating
[00:25:22 CEST] <BBB> ubitux: can you check that patch?
[00:25:25 CEST] <BBB> I hope its correct
[00:25:28 CEST] <BBB> but no idea for sure
[00:25:34 CEST] Action: BBB goes home, also
[00:25:35 CEST] <BBB> bbl
[00:25:45 CEST] <ubitux> which one?
[00:25:49 CEST] <ubitux> meh
[00:28:17 CEST] <rcombs> that one!
[00:30:41 CEST] <jamrial> ubitux: the one he sent one minute before he left i assume :p
[01:13:33 CEST] <rcombs> "it'd be neat for the mailing list to have a submission mechanism other than SMTP, and maybe have a nicer thread-based web viewer and& crap, I've invented forums"
[01:15:19 CEST] <Compn> or gmane and its nntp ;p
[01:15:22 CEST] <Compn> if it still has nntp
[01:15:25 CEST] <wm4> forums have nice thread-based views?
[01:16:09 CEST] <cone-889> ffmpeg 03Ronald S. Bultje 07master:a27c9f61bf69: fate: add -fflags +bitexact in a few places.
[01:26:51 CEST] <llogan> rcombs: who said that?
[01:27:56 CEST] <rcombs> me
[01:27:57 CEST] <rcombs> just now
[01:28:22 CEST] <atomnuker> I think gnu mailman 3.0 has some fancy interface, but good luck convincing people to upgrade
[01:29:10 CEST] <llogan> migrating mailman was annoying enough
[01:29:45 CEST] <atomnuker> https://lists.stg.fedoraproject.org/archives/
[01:29:59 CEST] <atomnuker> why did they feel they needed to add like/dislike buttons? just why
[01:30:04 CEST] <Plorkyeran> obv you should use the D forum software
[01:30:17 CEST] <Plorkyeran> can use it as a forum, mailing list, or nntp
[01:31:04 CEST] <llogan> the forum can have one person who answers who doesn't know shit.
[01:31:45 CEST] <wm4> Plorkyeran: I hope that isn't serious
[01:31:54 CEST] <wm4> I used to have the pleasure to use this POS
[01:32:14 CEST] <wm4> atomnuker: mailing lists are social networks
[01:32:19 CEST] <wm4> just like IRC
[01:32:55 CEST] <llogan> mailing lists also act as a filter to (sometimes) keep out the stupidest of people
[01:33:51 CEST] <llogan> it also traps stupid people into receiving ML messages forever because they can't figure out how to unsubscribe
[01:34:23 CEST] <wm4> it's a barrier of entry, both in good and bad ways
[01:37:03 CEST] <cone-889> ffmpeg 03Pedro Arthur 07master:e0a3173a94f2: swscale: refactor horizontal scaling
[01:37:04 CEST] <cone-889> ffmpeg 03Pedro Arthur 07master:737aa902f069: swscale: process horizontal lines in batches
[01:42:21 CEST] <Plorkyeran> it's easy to unsubscribe: you hit the mark as spam button in gmail
[01:43:55 CEST] <kierank> oh god swscale patches
[01:45:20 CEST] <kierank> mind you much more readable
[01:59:28 CEST] <BBB> they are?
[01:59:30 CEST] <BBB> thats good!
[02:03:20 CEST] <kierank> the swscale pipeline is much more unclear
[02:03:25 CEST] <kierank> but the code is at least readable
[02:05:38 CEST] <BBB> so youre happy?
[02:05:39 CEST] <BBB> or not?
[02:14:28 CEST] <kierank> dunno
[02:32:41 CEST] <michaelni> BBB i think your av_dlog patch missed 2 in ftp.c, unless my local tree is messed up
[02:32:51 CEST] <BBB> michaelni: yes, I just rebased
[02:32:53 CEST] <BBB> and one was gone
[02:33:02 CEST] <BBB> Im removing that patch and replacing it with one that uses ff_dlog
[02:33:05 CEST] <BBB> so ignore it for now
[02:33:11 CEST] <michaelni> ko
[02:33:12 CEST] <michaelni> ok
[02:33:25 CEST] <BBB> wm4: will you be at vdd?
[02:46:35 CEST] <BBB> michaelni: done
[02:47:17 CEST] <BBB> does anyone understand how removal of -flags +bitexact forwarding to -fflags +bitexact could break rtp hinting in mov?
[02:47:41 CEST] <BBB> (thats my last outstanding issue for FF_API_LAVF_BITEXACT)
[03:16:00 CEST] <llogan> michaelni: you beat me to the kernel again...was wondering why it didn't respond at the Y/N prompt.
[03:16:53 CEST] <llogan> oh, duh, nevermind. i just assumed that's what happened.
[03:18:51 CEST] <michaelni> llogan, i didnt update yet, i assume you are updating the boxes ?
[03:19:28 CEST] <llogan> just ffbox0.
[03:21:02 CEST] <llogan> i don't have access to trac machine
[03:22:20 CEST] <llogan> anyway, ffbox0 is up-to-date.
[04:00:59 CEST] <michaelni> llogan, ive added your key, you should be able to login
[04:01:06 CEST] <michaelni> to trac box
[04:21:13 CEST] <llogan> michaelni: thanks
[06:12:29 CEST] <philipl> BtbN: so did __gb__ rescue you? sounded nasty
[08:46:31 CEST] <ubitux> > modern codecs (eg. h264) are ...
[08:46:35 CEST] <ubitux> wait, what
[09:01:33 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:26ac22e5e739: movenc: Add a new flag for writing global sidx indexes for dash
[09:01:33 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:1907e19d0ce2: Merge commit '26ac22e5e7394346e9d59f800e7d4e91f4518d33'
[09:01:53 CEST] <cone-467> ffmpeg 03Henrik Gramner 07master:44b444412031: x86inc: Various minor backports from x264
[09:01:54 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:9c22aedd265e: Merge commit '44b44441203177690305c294be6eff8d9c668954'
[09:02:10 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:cb2dbe2c762d: configure: arm: Assume softfp ABI on darwin
[09:02:11 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:fdca9350139b: Merge commit 'cb2dbe2c762dae44d890aa26620bcdd9022fd0f3'
[09:02:24 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:87de6ddb7b76: libfdk-aacdec: Bump the max number of channels to 8
[09:02:25 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:9dc30d081140: Merge commit '87de6ddb7b7674e329d5c96677bd8685bc7f7855'
[09:09:41 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:1b90433f79de: libfdk-aacdec: Always decode into an intermediate buffer
[09:09:42 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:4cf4831ae7e2: Merge commit '1b90433f79de857550d4d8c35c89fbe954920594'
[09:10:03 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:f34b152eb7b7: libfdk-aacdec: Clean up properly if the init fails
[09:10:04 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:e721cb8d8b5c: Merge commit 'f34b152eb7b7e8d2aee57c710a072cf74173fbe1'
[09:16:23 CEST] <cone-467> ffmpeg 03Federico Tomassetti 07master:7bf964726430: vp7: bound checking in vp7_decode_frame_header
[09:16:24 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:983fa5a1a922: Merge commit '7bf9647264308d2df74b2b50669f2d02a7ecc90b'
[09:23:59 CEST] <cone-467> ffmpeg 03Luca Barbato 07master:72839fce6457: hlsenc: Use AV_TIME_BASE units for all the computations
[09:24:00 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:316825f3e9d5: Merge commit '72839fce6457fdb5d51b4a5381ac52914ee66389'
[09:35:48 CEST] <cone-467> ffmpeg 03Alexandra Hájková 07master:58c3720a3cc7: fate: Make sure a corner-case for ASF is covered
[09:35:49 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:4b6ccccb03ba: Merge commit '58c3720a3cc71142b5d48d8ccdc9213f9a66cd33'
[09:36:09 CEST] <cone-467> ffmpeg 03Alexandra Hájková 07master:317cfaa5e097: asfdec: prevent the memory leak in the asf_read_metada_obj
[09:36:10 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:649b2e4c8308: Merge commit '317cfaa5e09755ed0b34af512ec687963a67bdbf'
[10:25:42 CEST] <BtbN> philipl, well, gdb did. libva, or rather the intel driver, has no real error reporting except for returning "Invalid Parameter" after you gave it a set of ~200 parameters.
[10:26:01 CEST] <BtbN> So you have to step through there, and see which parameter check returns it.
[10:26:30 CEST] <BtbN> And i learned that gdb reverse debugging is not reliable aparently
[10:26:59 CEST] <BtbN> my idea was to just set a breakpoint on vaEndPicture, and then step backwards, which should bring me right to the failing check
[10:27:46 CEST] <BtbN> But it ended up with an entirely impossible backtrace that caused confusion
[10:28:25 CEST] <BtbN> So now i'm slowly working my way through everything it complains about.
[10:29:10 CEST] <BtbN> It seems to successfully decode I frames though. The reference handling is still broken
[10:50:36 CEST] <__gb__> nevcairiel, people are already required to zero-allocate vaapi_context, so Version would end up to be 0, which is fine. I have also considered renaming the struct, but AVVAAPIContext didn't look quite entertaining to read. If you have suggestions...
[10:50:56 CEST] <__gb__> besides, I anticipate that the version field is read only once when we initialize the internal (real) context
[10:51:10 CEST] <__gb__> well, at a single location
[10:58:00 CEST] <BtbN> Does any other struct in ffmpeg use a version field? Isn't it usualy just "provide an allocation function and add new fields at the end"?
[11:02:28 CEST] <__gb__> afaik, no, but if we want to ever be compatible in every weird combination, I believe this is the proper way
[11:03:14 CEST] <__gb__> oh well, maybe renaming to vaapi_config is more appealing after all
[11:03:38 CEST] <__gb__> since, at the end of the day, that would just hold some lavc/vaapi config options
[11:06:13 CEST] <__gb__> still, ABI can be broken even if we "add new fields at the end"
[11:08:06 CEST] <BtbN> Only if applications manualy allocate the struct
[11:13:36 CEST] <__gb__> how do you prevent him from manually allocating the struct, while preserving existing usage?
[11:19:09 CEST] <BtbN> The classic approach to that is to hide the fields, so the size is unknown.
[11:19:19 CEST] <BtbN> Fields are then only accessible through functions
[11:20:33 CEST] <BtbN> But i don't think there is a clean way to transition to that
[11:21:07 CEST] <__gb__> that's also my concern, and why I introduced that Version field :)
[11:21:39 CEST] <__gb__> thinking further, I believe it's reasonable to start introducing AVOptions until "hwaccel v2" ever happens
[11:21:53 CEST] <__gb__> but AVOptions tied to vaapi only atm
[11:22:07 CEST] <__gb__> e.g. av_init_context(flags, AVDict *)
[11:22:58 CEST] <__gb__> but we still need a way to identify old vs. new vaapi_context, or at least still support older vaapi_context allocated into hwaccel_context
[11:32:19 CEST] <nevcairiel> just stop supporting manual allocations, problem solved :d
[11:33:18 CEST] <__gb__> until I receive tons of angry e-mails saying why my favorite video player no longer works? :)
[11:33:37 CEST] <rcombs> fuck 'em
[11:33:38 CEST] <__gb__> I have just thought about an obscene way to coerce this:
[11:33:41 CEST] <nevcairiel> tell them to complain to the developers of that player, its a one line change to fix that
[11:33:42 CEST] <rcombs> rule #1 of software
[11:33:43 CEST] <rcombs> fuck 'em
[11:34:12 CEST] <wm4> __gb__: sent a reply on the ML
[11:34:38 CEST] <__gb__> 1. have av_vaapi_context_alloc() return a pointer OR'ed with 1
[11:35:14 CEST] <__gb__> this serves as a way to identify the struct was lavc allocated, and ensure the user goes to hell if he doesn't configure the struct through the supplied helper function
[11:35:46 CEST] <wm4> then you may as well use a completely different struct
[11:35:51 CEST] <wm4> (and keep it opaque)
[11:36:01 CEST] <rcombs> rule #2 of software
[11:36:04 CEST] <rcombs> make all structs opaque
[11:36:21 CEST] <wm4> I never liked AVcodecContext.hwaccel_context anyway
[11:36:23 CEST] <__gb__> but I still want to support old usages, whereby older vaapi_context can still be provided to hwaccel_context...
[11:36:27 CEST] <wm4> it has such confusing lifetime rules
[11:36:51 CEST] <wm4> __gb__: so distinguish old and new API users by whether hwaccel_context is set
[11:37:05 CEST] <wm4> if that is possible
[11:37:16 CEST] <nevcairiel> inventing yet another way to handle extensible structs that has no precedence in ffmpeg is just not a good way to go
[11:38:19 CEST] <__gb__> wm4, this would require the introduction of an extra hwaccel_config :-/
[11:38:21 CEST] <nevcairiel> we have slowly moved away from all sorts of user-allocated structs, and given a decent deprecation period, this should just follow
[11:38:58 CEST] <__gb__> oh, well, maybe just time to get people accept AVOptions then :)
[11:39:57 CEST] <__gb__> at least luca & I agreed on the benefits of that but iirc courmisch objected for type safetyness
[11:42:09 CEST] <wm4> __gb__: hm yes, I guess there's no simple way
[11:42:39 CEST] <nevcairiel> i really dont like avoptions for pointers, but i dont know if you need any
[11:42:42 CEST] <wm4> I think vdpau got away by actually requiring av_vdpau_alloc_context for everything and waiting for a deprecation period
[11:43:07 CEST] <wm4> nevcairiel: you can just add accessors for those
[11:43:28 CEST] <wm4> also I'm confused why vdpau has AVVDPAUContext and VDPAUHWContext
[11:43:47 CEST] <__gb__> nevcairiel, I'd only need one for the VADisplay, but I guess I could live with an extra function
[11:43:48 CEST] <wm4> and vdpau_picture_context
[11:43:59 CEST] <__gb__> I don't really want multiple accessors either...
[11:44:22 CEST] <__gb__> but I think I could live with AVOptions + some av_vaapi_context_set_display() for the pointer thing
[11:46:26 CEST] <wm4> __gb__: I'd say just go with a completely internal context for the new API
[11:46:32 CEST] <BtbN> Could also do something like keeping a list of all lavc-allocated hwaccel contexts. And when the one given to hwaccel_context is not in said list, assume it's a user allocated old-style struct, and convert it to the new, opaque one.
[11:46:38 CEST] <wm4> and emulate the old API, which sets hwaccel_context
[11:47:27 CEST] <BtbN> As there isn't usualy a lot of those contexts, this wouldn't be much overhead.
[11:48:23 CEST] <__gb__> nevcairiel, wm4: what do you think of my "obscene way to coerce people"? at least, we can: (i) keep vaapi_context name as is, (ii) identify old/new vaapi_context, new vaapi_context would only have additional flags + AVOptions, (iii) great benefit to have user forced to use the very few accessors
[11:49:35 CEST] <__gb__> wm4, yes, I only use the internal context (FFVAContext) now, but I need some extra configuration options and handle (VADisplay)
[11:50:05 CEST] <wm4> __gb__: so the init function could have a VADisplay argument, and maybe an AVDictionary (for avoptions)
[11:50:34 CEST] <wm4> I'm not quite sure what you mean by your "obscene way to coerce people", but as long as it doesn't crash old programs, it's potentially fine
[11:51:17 CEST] <__gb__> it's obscene because program will crash if developer did not bother going through the accessors :)
[11:51:45 CEST] <wm4> if we make the context really internal, and leave hwaccel_context to NULL, the user won't even get a chance
[11:51:48 CEST] <wm4> (stupid API user!)
[11:53:59 CEST] <__gb__> imho, this is not possible because hwaccel_priv_data is allocated later after user get_format() is called
[11:54:59 CEST] <wm4> oh I see utils.c messes with this
[11:55:00 CEST] <__gb__> when/how do you communicate or instruct initialization of the internal context then?
[11:55:05 CEST] <__gb__> yes
[11:55:05 CEST] <wm4> you could just add a new (internal) field
[11:55:34 CEST] <__gb__> to the struct? this is not possible unless you have a way to identify public/privately allocated struct :)
[11:55:37 CEST] <wm4> (I think that would be ok, because all the existing hwaccel code is a big mess anyway)
[11:56:23 CEST] <wm4> my thinking is: av_vaapi_context_alloc() would set a new AVCodecContext.internal.hwaccel_context field
[11:56:31 CEST] <__gb__> well, I believe this is not so messy as the newer ff_get_format() / setup_hwaccel() bits have a chance to handle fallbacks to SW decode now
[11:56:45 CEST] <wm4> and then the vaapi code can distinguish between new and old API user by whether this field is set, or by a flag set in this context
[11:57:50 CEST] <__gb__> hwaccel_priv_data would be reset in setup_hwaccel() as it only cares to check wether the hwaccel codec has non-zero priv_data_size :)
[11:59:47 CEST] <__gb__> but we could handle this gracefully, without the need to check all existing hwaccels, by adding a new HWACCEL_CODEC_CAP_xxx and checking for it in setup_hwaccel()
[12:00:37 CEST] <__gb__> doable, but I didn't initially want to pollute the existing HWACCEL_CODEC_CAPs
[12:00:45 CEST] <wm4> or just don't use hwaccel_priv_data, or do we have to?
[12:01:48 CEST] <__gb__> .init(), .uninit(), .priv_data_size are existing and convenient to use already, looking for some other infrastructure to initialize the hwaccel codec is not very pretty...
[12:03:43 CEST] <iive> just use hwaccel pixel formats and get_format
[12:58:28 CEST] <cone-467> ffmpeg 03Arttu Ylä-Outinen 07master:b807f7e28664: configure: Use pkg-config for libkvazaar.
[14:20:15 CEST] <__gb__> nevcairiel, wm4: new suggestion: don't change anything, just (i) add a new private AVCodecInternal.hwaccel_config field; (ii) populate it with a single public av_vaapi_set_config() / av_vaapi_set_config_int() ; then AVHWAccel.init() can gracefully populate its own private FFVAContext fields through av_opt_set_dict(). WDYT?
[14:20:28 CEST] <__gb__> + mark everything in vaapi_context as deprecated, except the VADisplay
[14:21:01 CEST] <__gb__> that way, the transition path to an hypothetical hwaccel v2 is even simpler
[14:21:24 CEST] <wm4> sounds kind of ok
[14:21:48 CEST] <wm4> I'd get rid of vaapi_context completely, at least from an API point of view (even if it's still used internally for a while)
[14:21:55 CEST] <nevcairiel> didnt we have an internal context storage for hwaccels somewhere already
[14:21:58 CEST] <__gb__> this means, no get possible -- but we don't care, if the user sets some values, we can expect that he can remember about it later...
[14:22:54 CEST] <__gb__> wm4, I can't get rid of the vaapi_context completely, I'd need to communicate the VADisplay (pointer) as a pointer, and we haven't reached consensus yet for that on options :)
[14:23:05 CEST] <wm4> e can expect that he can remember about it later... <- at least for something as static as the decoder context, sure
[14:23:27 CEST] <wm4> __gb__: couldn't it be passed via av_vaapi_set_config()?
[14:23:30 CEST] <wm4> or similar
[14:23:50 CEST] <nevcairiel> avctx->internal->hwaccel_priv_data? whats with that? no need to use a new one? :)
[14:24:21 CEST] <BtbN> There is also one that's per-frame.
[14:24:22 CEST] <__gb__> the suggested av_vaapi_set_config() would populate an internal hwaccel_config, which is an AVDict
[14:24:22 CEST] <wm4> it's deallocated on reinit I think
[14:24:51 CEST] <__gb__> I don't mind populating AVDict with random pointers but others object to that approach, so we need to find something else
[14:24:52 CEST] <wm4> __gb__: I see... does it have to be an AVDict?
[14:25:21 CEST] <__gb__> if you want hwaccel_config to be fine-tuned per hwaccel, then we have chances to increase messery
[14:25:40 CEST] <__gb__> i.e. you'd need another hook for hwaccel_config init/deinit/ and such :)
[14:26:00 CEST] <__gb__> sticking to AVDict looks simple enough to me and not too intrusive
[14:26:59 CEST] <__gb__> nevcairiel, avctx->internal->hwaccel_priv_data is forcibly initialized in setup_hwaccel()
[14:27:55 CEST] <__gb__> alternative, proposed previously, was to add yet another HWACCEL_CAP flag to be checked thus telling to not deallocate a prior allocation of hwacccel_priv_data
[14:28:52 CEST] <wm4> or add another pointer field
[14:29:55 CEST] <__gb__> yes, and that pointer field can actually be the options/dict hence this new suggestion :)
[14:30:26 CEST] <__gb__> I mean, while we are at adding a new pointer field, let's make it actually useful with little extra effort
[14:31:08 CEST] <__gb__> e.g. av_dict_free() exists already, etc. no need to add other hooks
[14:31:35 CEST] <wm4> I mean I was suggesting adding another field like hwaccel_priv_data, which the vaapi code would manage
[14:31:56 CEST] <wm4> also, note that in theory it's allowed to change the hwaccel method mid-stream
[14:32:17 CEST] <wm4> which is probably why the context is deallocated in the first place
[14:33:17 CEST] <__gb__> this is not an issue in the second proposed model (with AVDict)
[14:34:22 CEST] <__gb__> now, regarding to another field like hwaccel_priv_data but only useful to vaapi, well, this not good either
[14:34:53 CEST] <__gb__> FFVAContext perfectly fits hwaccel_priv_data
[14:35:08 CEST] <__gb__> no need for extra specific-ness for vaapi
[14:35:25 CEST] <__gb__> and the hwaccel_config can actually be useful to others, imho
[14:35:37 CEST] <wm4> then what was this about the HWACCEL_CAP flag?
[14:36:18 CEST] <__gb__> that's the first model so that to avoid setup_hwaccel() to av_mallocz() the hwaccel_priv_data itself
[14:36:26 CEST] <__gb__> in the second model (avdict), I don't need that
[15:02:09 CEST] <__gb__> on further thought, IMHO, type safetyness is a non issue here imho as we know that when an hwaccel is active, the hwaccel_config options are bound to be specific to that specific hwaccel, i.e. hwaccel_config is not public
[15:02:35 CEST] <__gb__> so having an av_vaapi_set_display() looks perfectly fine to me, no matter we internally store it in the hwaccel_config dict or not
[15:02:41 CEST] <__gb__> that's internal sauce
[15:04:27 CEST] <__gb__> nevcairiel, would you accept that now? i.e. av_vaapi_set_config() / av_vaapi_set_config_int() + av_vaapi_set_display() that internally populates the avdict, no extra change needed but deprecation of vaapi_context
[15:05:05 CEST] Action: __gb__ will cook a patch to demonstrate this
[15:22:40 CEST] <ubitux> michaelni: you need to force the dependency from scale filter to scale2ref filter
[15:22:42 CEST] <ubitux> afaict..
[15:47:42 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:70a19c482a62: Move ff_dlog from lavc to lavu.
[15:50:54 CEST] <BBB> I have 20 patches outstanding that dont have an explicit ok or rely on other patches, anyone want to review a couple? https://github.com/rbultje/ffmpeg/commits/api
[16:08:57 CEST] <cone-467> ffmpeg 03Michael Niedermayer 07master:db0f8f3f9d9f: avfilter/vf_scale: Set scale2ref ref output timebase
[16:08:57 CEST] <cone-467> ffmpeg 03Michael Niedermayer 07master:22f85543ed92: scale2ref: override request_frame() and correctly connect them to the corresponding inputs
[16:19:02 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:ad7d972e08dd: lavfi: add error message to help users convert to new lavfi syntax.
[16:47:35 CEST] <kvz> michaelni: Is there still discussion about my hosting proposal? Haven't heard back. We're rolling out something similar now for ImageMagick and tus. Thought maybe this illustrates better what my proposal is about: https://github.com/tus/tusd/blob/master/INFRA.md. We could set this up in a private repo and invite everyone involved as admin, to play around with it, and make a final decision.
[16:47:43 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:229843aa359a: Replace av_dlog with ff_dlog.
[17:08:14 CEST] <BBB> whats the diff between idr and keyframe? is this the can a following frame use previous frames as reference"?
[17:08:23 CEST] <nevcairiel> yes
[17:08:30 CEST] <BBB> and which is which? :)
[17:08:38 CEST] <nevcairiel> idr is a complete reset
[17:08:51 CEST] <nevcairiel> no previous refs afterwards
[17:09:17 CEST] <BBB> (so the case for non-idr is obvious, it allows seeking but gives slightly better compression)
[17:09:27 CEST] <BBB> I just had to get my wording right :-p
[17:09:29 CEST] <nevcairiel> how does it allow seeking
[17:09:40 CEST] <BBB> its an encoder choice
[17:09:40 CEST] <nevcairiel> i cant seek to a normal I frame, it would still distort
[17:09:56 CEST] <BBB> imagine display order of PBBIBBP
[17:10:19 CEST] <BBB> coding order may be IPBBPBB or whatever
[17:10:25 CEST] <BBB> (can get complicated)
[17:10:31 CEST] <BBB> the I and second PBB can still be decoded
[17:10:33 CEST] <BBB> just not the first
[17:11:05 CEST] <nevcairiel> not necessarily, h264 can reference a whole lot of things
[17:11:07 CEST] <BBB> its an encoder choice to discard the frames before the I at encoding of second BBP input set
[17:11:10 CEST] <BBB> I know it can
[17:11:15 CEST] <BBB> but this is an encoder choice
[17:11:24 CEST] <BBB> if I want to allow seeking, I tell my encoder to stop fucking up
[17:11:28 CEST] <BBB> and it does
[17:11:32 CEST] <BBB> and everyone is happy
[17:11:39 CEST] <michaelni> ubitux "./configure --disable-filters --enable-filter=scale2ref" works, so i dont know what to fix
[17:11:40 CEST] <nevcairiel> but whats the point of forcing normal I frames, they dont allow seeking or cutting
[17:11:51 CEST] <kierank> BBB: you can have keyframes in intra-refresh that are not idr or I
[17:11:55 CEST] <muken> > recovery point sei
[17:12:12 CEST] <BBB> i frames allow seeking
[17:12:18 CEST] <BBB> just not every frame afterwards is necessarily decodable
[17:12:30 CEST] <nevcairiel> i can seek to a B frame then and claim the same =P
[17:12:33 CEST] <BBB> but if the encoder did it right, the seek will succeed and decoding of any _display_ frame after the i will be correct
[17:12:43 CEST] <BBB> no, because the b frame wont decode correctly
[17:13:00 CEST] <BBB> hevc even has explicit nal unit types to indicate this difference
[17:13:08 CEST] <BBB> so its not like Im making this up
[17:13:09 CEST] <nevcairiel> if i want to ensure seeking to a certain point, ie. a chapter boundary, i need to put a IDR there
[17:13:34 CEST] <nevcairiel> otherwise there can be corruption after a seek
[17:14:06 CEST] <nevcairiel> with 16 possible reference frames, a single I is not going to clear up any following frames
[17:14:35 CEST] <BBB> that depends on the encoder
[17:14:41 CEST] <BBB> this is the whole point of radl
[17:14:47 CEST] <nevcairiel> if it does, its essentially a IDR
[17:15:35 CEST] <BBB> do you consider both n_lp and w_radl idr, or just n_lp?
[17:15:49 CEST] <nevcairiel> hevc is not relevant for this discussion =p
[17:15:50 CEST] <muken> you can seek to I with recovery_frame_cnt==0
[17:16:23 CEST] <BBB> the fact that h264 doesnt explicitly indicate nal types doesnt mean the same isnt possible withh h264 also
[17:17:14 CEST] <muken> though discarding undecodable leading frames depends on decoder :P
[17:18:46 CEST] <BBB> I dont see the issue with seeking to a w_radl point
[17:19:02 CEST] <BBB> (which is basically the non-idr case in the x264 patch)
[17:19:52 CEST] <nevcairiel> does it guarantee perfect reconstruction of any frames in display order afterwards? does the other x264 option really do that?
[17:20:34 CEST] <ubitux> michaelni: ./configure --disable-filters --enable-filter=scale ?
[17:20:57 CEST] <BBB> nevcairiel: yes and yes
[17:21:42 CEST] <BBB> (also, guarantee is an obscure word; in the case of x264, yes, it will work; in the sense that the standard guarantees it, no, I dont think so)
[17:22:20 CEST] <ubitux> michaelni: i'm refering to +AVFilter ff_vf_scale2ref; in libavfilter/vf_scale.c
[17:22:38 CEST] <ubitux> it looks like some weird dependency
[17:22:52 CEST] <ubitux> ah wait you declare it in the same file, all the time
[17:22:54 CEST] <ubitux> mmh
[17:23:05 CEST] <ubitux> we don't usually do that
[17:31:01 CEST] <BBB> nevcairiel: will you be at vdd?
[17:31:12 CEST] <BBB> nevcairiel: I can explain the use case for this and the quality implications on a whiteboard if you want
[17:31:36 CEST] <Daemon404> BBB, that is torture and banned under the geneva convention
[17:31:59 CEST] <BBB> doesnt that apply only under war?
[17:32:07 CEST] <BBB> I believe outside war, we can do whatever we want
[17:32:07 CEST] <Daemon404> i actually dont know
[17:32:35 CEST] <nevcairiel> within the countries laws in any case =p
[17:32:41 CEST] <BBB> or I can set up an ethics committee consisting of psychiatrists that I paid to say for me that this is not torture
[17:32:54 CEST] <BBB> theres legal precedence for that, I hear
[17:33:31 CEST] <nevcairiel> sounds like something the US would do to legalize waterboarding
[17:37:11 CEST] <__gb__> fyi, I have updated https://github.com/gbeauchesne/FFmpeg/tree/11.vaapi.lavc.config and https://github.com/gbeauchesne/ffvademo/commits/staging to reflect what I had in mind with AVDict
[17:37:59 CEST] <__gb__> I think it's in good shape now except maybe the actual names... not much inspired today :)
[17:39:03 CEST] <BBB> nevcairiel: whiteboarding != waterboarding
[17:39:13 CEST] <BBB> nevcairiel: they are similar, remarkably so, but not legally identical
[17:39:17 CEST] <nevcairiel> hehe
[17:39:22 CEST] <prelude2004c> hey everyone.. question maybe more poised at the development team. If i want to create a playout server. HOw do i set ffmpeg so it plays one file after another but without delayed start ? Eg. i don't want to loose frames or 1 second while it gets data from DB and starts to play the next one andwhen finished pull data gaain from DB and play the next one, etc etc. Is there some way to load the new video before the other is finished bu
[17:39:30 CEST] <nevcairiel> i always feel like drowning either way
[17:41:53 CEST] <BBB> Ill take that as a yes :-p
[17:42:11 CEST] <michaelni> ubitux, "./configure --disable-filters --enable-filter=scale && make -j12" <-- works too
[17:42:25 CEST] <nevcairiel> in any case I do not know yet if i'll be at vdd
[17:42:56 CEST] <BBB> oh.. :(
[17:43:06 CEST] <BBB> anyone want to review more patches? https://github.com/rbultje/ffmpeg/commits/api
[17:43:13 CEST] <BBB> FF_OPT_TYPE_* -> AV_OPT_TYPE_*. should be easy
[17:43:25 CEST] <BBB> or options: mark av_get_{int,double,q} as deprecated.
[17:44:04 CEST] <BBB> lavc: fix compilation with FF_API_XVMC. should be easy also
[17:44:45 CEST] <iive> hum?
[17:44:59 CEST] <iive> is there ticket for that?
[17:49:48 CEST] <BBB> iive: ticket for & ?
[17:52:00 CEST] <wm4> re keyframe discussion, aren't ffmpeg "keyframes" more similar to IDRs?
[17:52:18 CEST] <wm4> I mean the term "keyframe" is pretty inprecise in general anyway...
[17:52:39 CEST] <wm4> BBB: re VDD, seems unlikely...
[17:52:56 CEST] <iive> BBB: broken compilation...
[17:53:05 CEST] <BBB> why do people fundamentally object to vdd or meetings?
[17:53:23 CEST] <BBB> iive: why would there be a ticket for that?
[17:56:14 CEST] <wm4> __gb__: to be honest, I'd still prefer an "atomic" init call, which then could also take options of any type, instead of pulling it through avdict and avoption...
[17:57:21 CEST] <__gb__> I thought about varargs but this complexifies things for no real gain imho
[17:57:34 CEST] <wm4> no, varargs are terrible for anything but printf
[17:58:59 CEST] <wm4> is it really necessary for the user to set config/context id? I imagine the new code could do this automatically
[17:59:08 CEST] <muken> wm4: i dislike the keyframe term since keyframe does not guarantee that the frame is seekable or not and it depends on file format
[17:59:22 CEST] <__gb__> wm4, what do you suggest then? a basic (key,value) array?
[17:59:55 CEST] <wm4> __gb__: maybe a va_vaapi_initialize_with_existing_context()? (ok the name is too long)
[17:59:55 CEST] <__gb__> wm4, yes, config/context id are not needed in future patches, but this is currently optional
[18:00:32 CEST] <__gb__> I really need flexible config options to the pipeline :)
[18:00:44 CEST] <wm4> and we still can have an avdict for whatever else there might be, I just find it rather awkward to use it for the display, which is always needed, and is a pointer
[18:01:44 CEST] <__gb__> I don't really see other possible changes that remain non intrusive, flexible, and small
[18:02:29 CEST] <Compn> BBB : iive maintains xvmc stuff, he is wondering if xvmc is currently broken because your patch "fixes" it...
[18:02:30 CEST] <wm4> are you opposed to having separate av_vaapi_initialize_with_existing_context() and av_vaapi_initialize_automatically() functions?
[18:02:56 CEST] <iive> BBB: your xvmc patch is correct.
[18:03:40 CEST] <__gb__> wm4, no (names to be improved though), but I don't see how to implement that without touching more to the common hwaccel infrastructure
[18:04:07 CEST] <__gb__> I'd like to avoid having to test every possible other hwaccel
[18:04:14 CEST] <wm4> of course
[18:04:18 CEST] <iive> I would speculate that somebody coded these ifdefs with the thought that FF_API_XVMC indicates if XVMC is compiled... not that it list an api change.
[18:04:18 CEST] <BBB> iive: ty, do you want to mail that to the list?
[18:05:07 CEST] <iive> you can commit it right away
[18:05:31 CEST] <BBB> ty
[18:05:55 CEST] <wm4> __gb__: if we go with such functions, the second argument could be VADisplay, the "low level" one could also take config/context ID, and all of them could take an avdictionary parameter... and we _could_ of course use avdictionary for all of them internally
[18:06:07 CEST] <wm4> but I'm not very convinced, because the vdpau code does just fine without it
[18:06:31 CEST] <wm4> vdpau requires the user to call av_vdpau_bind_context() only, and that's it
[18:06:46 CEST] <wm4> (and get_buffer2 needs to be overridden of course)
[18:08:40 CEST] <__gb__> everything is possible but I believe the latest patch series optimizes best under the following constraints: compatibility, little changes to the common hwaccel structure, flexibility for future pipeline options, very little changes needed
[18:08:50 CEST] <__gb__> vdpau allocates hwaccel_context, which we want to avoid
[18:08:51 CEST] <__gb__> too
[18:09:00 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:6471040f5650: FF_OPT_TYPE_* -> AV_OPT_TYPE_*.
[18:09:01 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:b07d2a250955: libvpxenc: make flags i64 instead of dbl.
[18:09:02 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:ad45121d562d: options: mark av_get_{int,double,q} as deprecated.
[18:09:03 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:e3b7298aedd4: lavc: fix compilation with FF_API_XVMC.
[18:09:23 CEST] <wm4> __gb__: the user doesn't need to access hwaccel_context though (except for deallocation, which strikes me as an API bug)
[18:09:39 CEST] <wm4> I mean, the user doesn't need to access hwaccel_context with the new vdpau APU
[18:09:41 CEST] <wm4> *API
[18:10:07 CEST] <wm4> and I believe our idea how it should look like are very similar anyway
[18:10:09 CEST] <__gb__> yes, but as you mention, he further needs to deallocate the hwaccel_context himself
[18:10:19 CEST] <wm4> but that could surely be fixed
[18:11:39 CEST] <__gb__> I will need other config options, and extending vaapi_context is not an option
[18:13:02 CEST] <wm4> muken: what interests me here is what AV_PKT_FLAG_KEY actually means (although I think it's not relevant to what was discussed)
[18:13:17 CEST] <__gb__> going after the vdpau way means we need to further live with vaapi_context, which we don't need
[18:13:38 CEST] <wm4> __gb__: I don't see this, this has nothing to do with any user-visible contexts
[18:14:28 CEST] <wm4> vdpau kept using hwaccel_context mainly for internal compatibility
[18:15:20 CEST] <wm4> for now feel free to go ahead with your latest approach I guess
[18:15:43 CEST] <wm4> but I think putting mandatory parameters in avdicts (as far as the user API is concerned) is pretty ugly
[18:15:52 CEST] <wm4> especially for pointers
[18:16:05 CEST] <__gb__> it's not a pointer, it's a uintptr :)
[18:16:46 CEST] <__gb__> but you are right, there is a bug for 32-bit systems
[18:23:13 CEST] <__gb__> I now see your point, and that you are not fundamentally opposed to using AVDict internally
[18:24:19 CEST] <muken> wm4: AV_PKT_FLAG_KEY means a packet contains at least one complete frame with an indicator which indicates the decoder does output correctly after a specified frame in output order.
[18:24:46 CEST] <__gb__> I guess I can refactor the 3 functions into a single av_vaapi_set_pipeline_config(avctx, VA-display, options);
[18:25:08 CEST] <wm4> __gb__: yep, that looks nicer IMHO
[18:25:39 CEST] <__gb__> and let the old fashioned way to provide VA config/context with the old vaapi_context, and exclusively use av_vaapi_set_pipeline_config() to let lavc allocate the decoder itself
[18:25:58 CEST] <wm4> sounds good
[18:26:00 CEST] <__gb__> at the end of the day, most of the users would only care to provide a VA display anyway
[18:26:18 CEST] <muken> wm4: this definition of cource requires initialization of the decoder
[18:26:20 CEST] <__gb__> ok, I will work on that
[18:26:41 CEST] <wm4> muken: next problem: do all libavformat demuxers actually follow this definition?
[18:27:21 CEST] <muken> wm4: afaik yes. this defintion covers closed gop, open gop and gradual decoder refresh
[18:29:16 CEST] <muken> this definiton does not gurantee that a packet with AV_PKT_FLAG_KEY is a random accessible point
[18:30:04 CEST] <wm4> then I'd imagine that remuxing to mkv is often broken
[18:32:20 CEST] <muken> yes. current libavformat marks IDR without required parameter sets as keyframe. this issue is sometimes exposed on AVC-in-TS
[18:33:42 CEST] <kierank> is that even legal?
[18:33:57 CEST] <muken> kierank: i have a such sample
[18:34:20 CEST] <kierank> muken: ah so the carl approach :)
[18:35:20 CEST] <muken> i found such streams in anime BDs
[18:35:53 CEST] <muken> the spec of avc does not forbid idr without parameter sets
[18:36:05 CEST] <muken> dunno about the bd spec
[18:36:28 CEST] <kierank> mpegts spec i think forbids that
[18:36:39 CEST] <kierank> and I think gary sullivan said it's illegal
[18:38:27 CEST] <kierank> oh wait mp4
[18:38:29 CEST] <kierank> so it is legal
[18:42:39 CEST] <muken> anyway, theoretically such wild implementations could be appeared, regardless of whether it's legal or illegal, we should handle them
[18:45:14 CEST] <kierank> muken: ok carl
[18:45:34 CEST] Action: kierank trolls muken
[18:46:01 CEST] <muken> no more cehoyos
[19:00:12 CEST] <wm4> does libavcodec/utils.c mess with the timestamps output by the decoder?
[19:00:39 CEST] <nevcairiel> isnt that all in avformat
[19:00:44 CEST] <nevcairiel> timestamp messing
[19:01:00 CEST] <wm4> I thought so too, but right now I'm debugging a strange issue I'm running into
[19:03:04 CEST] <wm4> oh
[19:03:17 CEST] <wm4> it overwrites pkt_dts
[19:03:31 CEST] <wm4> it sets it from the AVPacket passed to the decode call
[19:03:36 CEST] <wm4> which is not useful in mmal...
[19:03:48 CEST] <wm4> because the decoder is asynchronous
[19:04:02 CEST] <nevcairiel> pkt_dts can easily get useless depending on the decoder delay and whatnot
[19:04:30 CEST] <wm4> no, it's actually useful to determine the pts
[19:04:42 CEST] <wm4> the frame threading wrapper handles it specially too
[19:05:16 CEST] <nevcairiel> it still assumes the delay is "perfect"
[19:05:31 CEST] <wm4> seems to work well enough for mpeg stuff
[19:05:39 CEST] <nevcairiel> if the decoder buffers any more than required, it'll go out of sync with pts
[19:26:22 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:3285005347b2: Undeprecate av_opt_set_defaults2().
[19:29:14 CEST] <BBB> nevcairiel: I dont believe thats how it works
[19:29:22 CEST] <BBB> nevcairiel: most decoders assume one in one out
[19:29:30 CEST] <BBB> nevcairiel: so assuming the pts is correct on the input packet
[19:29:47 CEST] <BBB> nevcairiel: you can put that packets timestamp on the AVFrame returned through get_buffer
[19:30:00 CEST] <nevcairiel> pts works
[19:30:00 CEST] <BBB> and then it doesnt matter how long its cached, its always correct
[19:30:02 CEST] <nevcairiel> but dts doesnt
[19:30:04 CEST] <BBB> right
[19:30:27 CEST] <nevcairiel> because it assigns the dts of the latest input packet to the currently outgoing frame
[19:30:29 CEST] <wm4> anway, for some codecs/containers you need DTS to figure out the PTS
[19:30:31 CEST] <nevcairiel> which depends on decoder delay
[19:30:35 CEST] <BBB> if the decoder buffers any more than required, it'll go out of sync with pts < it semeed you were suggesting pts cant work in all cases either
[19:30:44 CEST] <BBB> if not, then nevermind
[19:30:56 CEST] <wm4> so what's the suggested solution?
[19:31:16 CEST] <BBB> you throw timestamps out of the window
[20:46:22 CEST] <Daemon404> nevcairiel / BBB - any opinion on the IDR patch?
[20:46:39 CEST] <Daemon404> (i didnt follow the talking in here completely)
[20:48:16 CEST] <BBB> its ok with me
[20:48:31 CEST] <BBB> michael is right that the option naming is clunky, but thats ok
[20:48:39 CEST] <BBB> its private codec options so -EWHOCARES
[20:49:41 CEST] <Daemon404> BBB, yeah i couldnt think of a better name though
[20:49:58 CEST] <BBB> its ok
[20:50:08 CEST] <BBB> its not just the name, it also feels that the option is kind of spaghetti
[20:50:32 CEST] <Daemon404> no, it definitely is
[20:50:41 CEST] <BBB> but again, codec private option, so its ok
[20:52:16 CEST] <Daemon404> huh... i cant full ffmpeg.git
[20:52:18 CEST] <Daemon404> times out
[20:53:50 CEST] <jamrial> if you meant pull, just tried and it worked
[20:54:49 CEST] <Daemon404> ]$ git pull --rebase
[20:54:49 CEST] <Daemon404> fatal: read error: Connection reset by peer
[20:54:56 CEST] <Daemon404> getting this now
[20:55:38 CEST] <kierank> git.ffmpeg.org?
[20:55:40 CEST] <kierank> or source.ffmpeg.org
[20:57:27 CEST] <nevcairiel> I always use videolan, fuck this redirect business
[21:01:20 CEST] <kierank> same
[21:23:06 CEST] <cone-467> ffmpeg 03Stephen Hutchinson 07master:c5308eea2921: configure: force -mconsole when linking SDL under MinGW
[21:26:20 CEST] <BBB> wm4: do you feel like you could review the outstanding vdpau patches? you tested them at elast
[21:26:51 CEST] <BBB> michaelni: can you approve mpeg4video: use ff_dlog instead of av_log under debug&FF_DEBUG_GENPTS.?
[21:30:24 CEST] <wm4> BBB: right, forgot to reply with LGTM
[21:31:30 CEST] <michaelni> BBB s/FF_DEBUG_GENPTS/FF_DEBUG_PTS/
[21:31:42 CEST] <michaelni> with that it LGTM
[21:32:18 CEST] <BBB> updated on github with that, and will push, ty
[21:33:16 CEST] <BBB> wm4: https://github.com/rbultje/ffmpeg/commits/api
[21:33:33 CEST] <BBB> wm4: its lavc: put remaining bits of vdpau-in-decoder under FF_API_CAP_VDPAU., then yours, and then lavu: disable wrong value check in get_version() upon api bump.
[21:33:50 CEST] <wm4> acked the first 2, the 3rd was ok'ed by mini
[21:33:58 CEST] <BBB> https://github.com/rbultje/ffmpeg/commit/9e787b03fac0abe626605b21fee64b8444…, https://github.com/rbultje/ffmpeg/commit/7c553d8ca7fcf4c3e95c92dd43502cb45d… (yours) and https://github.com/rbultje/ffmpeg/commit/49c4bd0944a26738f60bc39573f964aae0…
[21:34:03 CEST] <BBB> ok ty
[21:34:05 CEST] <wm4> so what about that branch, should I test it, or review commits?
[21:34:25 CEST] <BBB> no my email showed just one review
[21:34:36 CEST] <BBB> the other one popped in as you said I acked the first 2
[21:34:43 CEST] <BBB> so ignore me
[21:35:10 CEST] <BBB> was your comment to the FF_IDCT_* one approval btw?
[21:35:14 CEST] <BBB> or just a question?
[21:37:58 CEST] <wm4> count it as approval (I just replied too)
[21:39:30 CEST] <BBB> ty
[21:40:44 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:9468207e1cba: mpeg4video: use ff_dlog instead of av_log under debug&FF_DEBUG_PTS.
[21:56:41 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:7a629186ba04: Prepare for removal of obsolete FF_IDCT_* members.
[22:06:07 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:030b5a4f777b: lavc: put remaining bits of vdpau-in-decoder under FF_API_CAP_VDPAU.
[22:06:08 CEST] <cone-467> ffmpeg 03wm4 07master:a383f226f02b: lavc: move vdpau decoders under FF_API_VDPAU.
[22:06:09 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:87068ea5c5c8: lavu: disable wrong value check in get_version() upon api bump.
[22:12:41 CEST] <Daemon404> this i really bizzarre
[22:12:45 CEST] <Daemon404> i can clone x264 from videolan
[22:12:51 CEST] <Daemon404> but ffmpeg.git ends with reet by peer
[22:13:44 CEST] <Daemon404> vlc.git either
[22:13:44 CEST] <jamrial> just add the github mirror as remote and fetch from there for the time beign
[22:14:55 CEST] <Daemon404> github works yeah
[22:20:27 CEST] <Daemon404> gah cant push either
[22:20:41 CEST] <Daemon404> someone want to push?
[22:24:18 CEST] <nevcairiel> are you using yodel internet now?
[22:25:13 CEST] <Daemon404> just some videolan repos seem to have issues...
[22:25:15 CEST] <Daemon404> i dunno.
[22:27:12 CEST] <BBB> it works for me
[22:27:17 CEST] <BBB> I think the problem is on your end
[22:27:37 CEST] <BBB> or I s3kr3tly h4x0r3d videolan/ffmpeg git and kicked you guys out
[22:27:42 CEST] <BBB> muhahahaha
[22:27:54 CEST] <Daemon404> probably
[22:27:57 CEST] <Daemon404> it's weird
[22:29:56 CEST] <Daemon404> i guess someone else can push in the meanwhile. oh well.
[22:36:05 CEST] <jamrial> the libx264 idr commit? i can push it
[22:36:13 CEST] <jamrial> no changes to the version in the ml, right?
[22:36:56 CEST] <Daemon404> yea.
[22:37:16 CEST] <Daemon404> as long as the version bump is still valid
[22:42:18 CEST] <llogan> i'm kind of surprised fflogger is still alive. burek vanished a while ago.
[22:42:25 CEST] <cone-467> ffmpeg 03Derek Buitenhuis 07master:c981b1145a85: libx264: Add option to force IDR frames
[22:43:39 CEST] <Daemon404> thx
[22:45:03 CEST] <jamrial> np
[23:06:36 CEST] <philipl> heh.
[23:06:57 CEST] <cone-467> ffmpeg 03Pedro Arthur 07master:0f3687d6fb87: swscale: add license headers and copyrights
[23:06:58 CEST] <cone-467> ffmpeg 03Pedro Arthur 07master:ed80dec621f6: swscale: fixed compiler warnings
[23:06:59 CEST] <cone-467> ffmpeg 03Pedro Arthur 07master:4545906f6038: swscale: Fixed typos
[23:08:19 CEST] <nevcairiel> BBB: told you
[23:14:44 CEST] <Compn> Daemon404 : did you mess up your git credentials ?
[23:14:55 CEST] <Compn> it will reset by peer if you dont have the right login
[23:15:30 CEST] <cone-467> ffmpeg 03Lou Logan 07master:5d410a1db2bf: doc/indevs: fix fbdev typos
[23:16:21 CEST] <jamrial> doesn't that apply only to ssh connections and not pull/fetch?
[23:16:26 CEST] <Daemon404> yes
[23:16:37 CEST] <Daemon404> couldnt clone either
[23:17:40 CEST] <philipl> nevcairiel: Does carl have some secret application he's responsible for but they've lost the source code so it can never be updated to use new APIs?
[23:19:48 CEST] <llogan> works fine for me with remote origin url = git@source.ffmpeg.org:ffmpeg
[23:20:16 CEST] <nevcairiel> philipl: usually its just mplayer, which due to its brokenness constitutes an almost similar situation, but i dunno
[23:20:17 CEST] <BBB> Daemon404: I had a port mapping that screwed me over
[23:20:25 CEST] <BBB> (although that was very old)
[23:21:18 CEST] <philipl> nevcairiel: I would assume he knows mplayer uses the new vdpau API. Hence my wondering if there's something else.
[23:21:39 CEST] <BBB> a 3 year old version of mplayer, maybe?
[23:21:50 CEST] <BBB> like, one that can still be compiled with gcc-2.95
[23:22:20 CEST] <philipl> Good ol' gcc 2.95.
[23:22:23 CEST] <philipl> And glibc 2.1.3
[23:22:31 CEST] <philipl> Those were the days.
[23:31:26 CEST] <JEEB> I think XBMC guys were really into the old VDPAU stuff
[23:31:41 CEST] <JEEB> but I'd bet they've moved to the new one already?
[23:31:41 CEST] <nevcairiel> i think they migrated because the old way was broken
[23:32:30 CEST] <nevcairiel> (or at least lacking some features)
[23:36:58 CEST] <wm4> rage
[23:37:15 CEST] <wm4> when did he ever "maintain" anything in vdpau
[23:38:10 CEST] <jamrial> btw, regarding the vdpau stuff, shouldn't the guards from a383f226 be FF_API_CAP_VDPAU and not FF_API_VDPAU? The latter is a lavu deprecation guard
[23:39:06 CEST] <wm4> actually he has a bunch of vdpau commits, but I still don't care
[23:39:49 CEST] <wm4> jamrial: maybe both
[23:40:07 CEST] <wm4> there are various other things that would prevent the code from compiling anyway
[23:43:21 CEST] <jamrial> regardless of him having or not vdpau related comits, he's completely in the wrong this time. adding missing guards to prevent compilation failures once a bump takes place does not constitute a new deprecation
[23:59:34 CEST] <Compn> wm4 : our maintainers list actually does mean something
[23:59:41 CEST] <Compn> libav is the one who rm'd theirs
[00:00:00 CEST] --- Wed Aug 19 2015
1
0
[00:08:52 CEST] <techtopia> just don't open the vob file?
[00:09:07 CEST] <techtopia> ffmpeg -i somefile.notvob etc...
[00:09:45 CEST] <techtopia> or if the vob file is a track of somthing you can omit it with -map
[00:09:55 CEST] <techtopia> but i can't see that ever being the case
[00:52:57 CEST] <JohnnyonFlame> Hello. I'm trying to run 'moonlight' on a CI20 running Debian 7 wheezy w/ non-free+backports, however I'm getting "Error: Invalid data found when processing input" from libavcodec, and I'm unsure on how to debug this.
[00:53:06 CEST] <JohnnyonFlame> any ideas? Thanks.
[00:54:52 CEST] <JohnnyonFlame> oh, and the error code comes from "avcodec_decode_video2"
[01:01:37 CEST] <silverfox> Does anyone on here known how to use MSYS2?
[01:06:23 CEST] <silverfox> I am trying to compile ffmpeg but get error: "Unknown OS msys_nt-6.3'
[06:11:57 CEST] <nanoEng> is it normal that when compiling there are a ton of Warning: -fPIC ignored for target (all code is position independent) ?
[06:56:47 CEST] <DHE> depends on the CPU type, but it could happen sure. everything would get -fPIC by default
[09:44:51 CEST] <nanoEng> how do i get SDL installed in msys2?
[09:45:38 CEST] <nanoEng> i used pacman -S mingw64/mingw-w64-x86_64-SDL
[09:45:43 CEST] <nanoEng> i used pacman -S mingw64/mingw-w64-x86_64-SDL2
[09:46:49 CEST] <nanoEng> i used pacman -S mingw32/mingw-w64-i686-SDL
[09:47:05 CEST] <nanoEng> it says they are all installed when doing pacman -Ss sdl
[09:47:44 CEST] <nanoEng> and yet when i try to compile ffmpeg using ./configure enable-sdl I get Error: SDL not found.
[09:48:15 CEST] <nanoEng> someone care to explain?
[09:51:56 CEST] <JEEB> 1) are you sure you are using the mingw-w64 32bit or 64bit cross-compiler (since "native" for msys2 is, of course, msys2)
[09:52:02 CEST] <JEEB> 2) see config.log
[09:52:16 CEST] <JEEB> also if there are any development packages for those SDLs, you probably want those
[09:52:49 CEST] <nanoEng> let me check
[09:54:09 CEST] <nanoEng> well when you type pacman -Ss sdl you get the entries listed here: http://sourceforge.net/p/msys2/wiki/Packages/
[09:59:16 CEST] <nanoEng> Are you saying that I should also install the SDL_gfx and SDL _ttf packages?
[09:59:46 CEST] <nanoEng> And I need SDL-1.2 for ffmpeg, correct? As according to here: http://trac.ffmpeg.org/wiki/CompilationGuide/MinGW ?
[10:04:20 CEST] <JEEB> you should install the packages containing the development libraries for the SDL you are planning to use
[10:04:30 CEST] <JEEB> I don't know if there is SDL2 support yet :P
[10:04:50 CEST] <nanoEng> well as it says on http://sourceforge.net/p/msys2/wiki/Packages/
[10:05:14 CEST] <nanoEng> MSYS2 lets you download and install SDL2
[10:05:20 CEST] <nanoEng> oh.. you meant for FFmpeg
[10:05:53 CEST] <nanoEng> i'm just trying to compile ffplay
[10:06:41 CEST] <JEEB> basically look at what ffmpeg's configure is looking for by staring at what is written into config.log
[10:06:50 CEST] <nanoEng> and it has turned into a @*#%& nightmare (i'm not very experienced with compiling; I'm self-taught in Python, that's about it, took a C++ class and wrote Hello World stuff a long time ago)
[10:07:20 CEST] <JEEB> also make sure you are using either i686-w64-mingw32-* tools or x86_64-w64-mingw32-* tools depending on if you want a 32bit or 64bit mingw-w64 compile :P
[10:07:33 CEST] <JEEB> because the default for msys2 is msys2, which you probably don't want
[10:08:37 CEST] <nanoEng> not sure what you mean by that last statement
[10:08:48 CEST] <nanoEng> default for what is msys2?
[10:09:10 CEST] <nanoEng> Also, i'm trying to make a 64bit compile
[10:10:27 CEST] <nanoEng> but installing the 64bit SDL-1.2 didn't work, and that site says you need SDL-1.2, so i thought maybe install the i686 one, even though that went against common sense to me, and sure enough, installing it still turned up Error: SDL not found.
[10:15:15 CEST] <nanoEng> When you say, the SDL i'm planning to use,... don't you mean SDL-1.2 ? since http://trac.ffmpeg.org/wiki/CompilationGuide/MinGW says you have to???
[10:16:49 CEST] <JEEB> nanoEng: well first of all check from config.log or otherwise if you're even trying to configure with the right tools
[10:17:11 CEST] <JEEB> as I said, msys2 by default has the tools aimed for the "msys2" OS
[10:17:36 CEST] <JEEB> the mingw-w64 tools usually have the cross-prefix of i686-w64-mingw32 or x86_64-w64-mingw32
[10:19:47 CEST] <nanoEng> hmm.. well MSYS2 has a MSYS shell and a MinGW-w64 shell; Are you saying I should use the MinGW-w64 shell?
[10:22:14 CEST] <nanoEng> ffs... now it's telling me it doesn't like --arch=AMD64, well it didn't like --arch=win32 or --arch=win64.... . EVEN THOUGH typing env gives PROCESSOR_ARCHITECTURE=AMD64
[10:22:41 CEST] <nanoEng> well wtf are my choices then???
[10:23:00 CEST] <nanoEng> ./configure --help doesn't tell me jack
[10:23:58 CEST] <nanoEng> and when i did --arch=x86_64... it said after doing ./configure that arch=x86 ...... wtf?
[10:27:42 CEST] <nanoEng> Also, i just deleted and re=ran ./configure with my settings.
[10:27:57 CEST] <nanoEng> Here is the config.log, if you can make any sense of it: http://pastebin.com/jV9S9a3M
[10:33:24 CEST] <goht> Hi. I'm looking for ffplay statistics parameters (A-V fd aq vq sq f) description. Docs didn't help me.
[10:35:11 CEST] <nanoEng> hi goht
[10:35:17 CEST] <nanoEng> are you able to compile ffplay?
[10:36:56 CEST] <goht> yes, but I use precompiled windows package
[10:38:43 CEST] <nanoEng> How did you compile it?
[10:38:50 CEST] <nanoEng> msys2?
[10:38:58 CEST] <nanoEng> or well, msys2 shell?
[10:39:22 CEST] <nanoEng> by anychance, or are you on linux?
[10:40:50 CEST] <nanoEng> btw, this isn't what your looking for is it: http://linux.die.net/man/1/ffplay ?
[10:43:05 CEST] <goht> I've alrady seen it. so I'm looking for 37.79 A-V: -0.016 fd= 13 aq= 10KB vq= 51KB sq= 0B f=0/0 parameters description
[10:43:44 CEST] <nanoEng> what's 37.79 A-V ?
[10:44:19 CEST] <goht> it is the ffplay process console output
[10:44:30 CEST] <nanoEng> I ask since it might be useful, since i'm trying to modify ffplay, but i can't even get it to compile.
[10:44:58 CEST] <nanoEng> output after inputting what?
[10:45:29 CEST] <nanoEng> ah.............. i think i see what your saying
[10:45:37 CEST] <nanoEng> that's what you're trying to figure out
[10:45:53 CEST] <goht> Maybe I'm too bad english speaker.
[10:46:08 CEST] <goht> sorry
[10:46:11 CEST] <nanoEng> I'm not used to compiling, I taught myself Python.
[10:46:21 CEST] <nanoEng> Python has very good documentation.
[10:46:44 CEST] <nanoEng> Try to use anything else, and you will be disappointed with the documentation of anything else.
[10:46:58 CEST] <nanoEng> (after using python)
[10:47:00 CEST] <BtbN> Sounds like you haven't used anything else yet.
[10:47:07 CEST] <nanoEng> yup
[10:47:19 CEST] <nanoEng> well, like i said earlier, i took a C++ class a long time ago.
[10:47:49 CEST] <nanoEng> all we did was Hello World stuff though. Print one * then print ** on the next line, then ***, etc. upto 8 *'s.
[10:48:17 CEST] <nanoEng> silly stuff that i could write code for in python in 3 lines.
[10:48:50 CEST] <nanoEng> How are you BtbN?
[10:49:44 CEST] <nanoEng> your a bit of a celebrity here, arn't you BtbN?
[10:49:50 CEST] <nanoEng> I know you from: http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2015-June/002873.html
[10:50:08 CEST] <nanoEng> :P
[10:51:37 CEST] <nanoEng> In any case, I wanted to strengthen my C language muscles (or grow some) and I thought modifying ffplay would make for a fun project.
[10:52:06 CEST] <nanoEng> Unfortunatly, I can't even get it to compile.
[10:52:15 CEST] <BtbN> It's propably easier to just setup a linux somewhere.
[10:52:51 CEST] <nanoEng> Yeah.. i don't have an extra computer laying around to install linux on, unfortunatly..... elsei woulda done that ages ago.
[10:53:04 CEST] <BtbN> virtual machines do exist
[10:53:10 CEST] <nanoEng> true..
[10:53:33 CEST] <nanoEng> but if i wanted to installl a vertual machine and an entire operating system....
[10:53:50 CEST] <nanoEng> i would have just downloaded Microsoft Visual Studio
[10:54:07 CEST] <nanoEng> and followed the FFmpeg compilation instructions for MSVC
[10:54:11 CEST] <BtbN> which doesn't help you at all with your problem.
[10:54:26 CEST] <BtbN> building ffmpeg with MSVC only makes things even more complicated any annoying.
[10:54:32 CEST] <BtbN> *and
[10:54:32 CEST] <nanoEng> but when i saw MSVC is 4 GB, i said f that.
[10:55:04 CEST] <nanoEng> hmm..
[10:56:09 CEST] <nanoEng> That's not what it says here
[10:56:10 CEST] <nanoEng> http://trac.ffmpeg.org/wiki/CompilationGuide
[10:56:30 CEST] <nanoEng> "Compiling FFmpeg using MSVC is easy; follow the instructions on the main page or CompilationGuide/MSVC for more details. "
[10:58:03 CEST] <nanoEng> yet, if you follow that link, you'll see something siding more with your statement... serveral lines of instructions, instread, (section 4.1) is only 7 lines... unfortunatly, it explains jack-S.
[10:58:45 CEST] <nanoEng> " In order to compile FFplay, you must have the MinGW development library of SDL and pkg-config installed. "
[10:59:18 CEST] <nanoEng> Yeah, thanks for not explaining how to go about doing any of that.
[10:59:39 CEST] <nanoEng> By some miracle, i finally got the damn pkg-config thing to work.
[11:00:36 CEST] <nanoEng> and before that I couldn't get anything, it was just telling me Unknown OS: msys_nt-6.3... then i think by doing ./configure --disable-d3d11va or --disable-dxva2 finally fixed that
[11:01:45 CEST] <nanoEng> which i got from the http://trac.ffmpeg.org/wiki/CompilationGuide/WinRT for compiling for Windows 8.1 64bit (which is what i'm running)
[11:02:03 CEST] <nanoEng> but those instructions are assuming you have MSVC
[11:02:34 CEST] <nanoEng> but i just stole the config settings of d3d11va and dxva2
[11:02:57 CEST] <nanoEng> why the f did that fix it not recognizing the OS, i haven't a clue.
[11:03:24 CEST] <nanoEng> hi orewizard, abandon all hope.
[11:03:28 CEST] <oreWizard> ?
[11:03:41 CEST] <oreWizard> i did compile ffmpeg
[11:03:45 CEST] <nanoEng> Yee have entered the land of the damned.
[11:03:47 CEST] <oreWizard> but idk how to use it on vs2015
[11:04:33 CEST] <nanoEng> i'm trying to compile it w/o VS
[11:04:47 CEST] <nanoEng> what did you compile it with?
[11:05:29 CEST] <nanoEng> msys2?
[11:05:30 CEST] <oreWizard> ms2015 msys2 yasm gas-processor
[11:05:34 CEST] <oreWizard> yes
[11:05:43 CEST] <nanoEng> ah, you were using: http://trac.ffmpeg.org/wiki/CompilationGuide/WinRT ??
[11:05:53 CEST] <oreWizard> yes
[11:06:00 CEST] <oreWizard> but i got errror on pkg-config
[11:06:06 CEST] <nanoEng> Ah!
[11:06:09 CEST] <nanoEng> i had same problem
[11:06:15 CEST] <nanoEng> i spent last 6 hours working on that
[11:06:18 CEST] <oreWizard> but i made an install ok
[11:06:22 CEST] <nanoEng> finally fixed it
[11:06:27 CEST] <nanoEng> oh...
[11:06:29 CEST] <nanoEng> well anyway
[11:06:35 CEST] <oreWizard> the interop
[11:06:36 CEST] <nanoEng> if you wanted to fix the pkg-config thing
[11:06:45 CEST] <nanoEng> you use MSYS2 shell
[11:06:46 CEST] <oreWizard> its not working for me th einterop
[11:07:05 CEST] <nanoEng> and type pacman -S msys/pkg-config
[11:07:16 CEST] <oreWizard> yes true
[11:07:48 CEST] <oreWizard> i will try to compile again
[11:07:50 CEST] <oreWizard> thanks
[11:07:58 CEST] <oreWizard> are u using it on vs?
[11:08:41 CEST] <nanoEng> do NOT use pacman -S mingw64/mingw-w64-x86_64-pkg-config
[11:08:54 CEST] <nanoEng> no
[11:09:00 CEST] <nanoEng> vs is like 4 GB
[11:09:14 CEST] <nanoEng> i'm trying to compile it w/o having to download vs
[11:09:29 CEST] <nanoEng> i mean, if i was a computer programer, i wouldn't mind having vs on my computer
[11:09:57 CEST] <nanoEng> but since i'm just doing this for fun, nothing extreem, just editing ffplay.c is what i want to do
[11:10:37 CEST] <nanoEng> maybe add a menu dialog pop=up window for some user input... have to learn how to do that. but that's it.
[11:10:54 CEST] <nanoEng> So i don't think i need a 4 GB IDE just for that.
[11:11:04 CEST] <oreWizard> i dont use it for working so?
[11:11:07 CEST] <oreWizard> u*
[11:11:35 CEST] <nanoEng> I'm from the old days, back when 4 GB is huge.
[11:11:46 CEST] <oreWizard> i seee
[11:11:48 CEST] <nanoEng> I know 4 GB is small to you young people.
[11:11:55 CEST] <oreWizard> i am making some app for windows phone
[11:12:03 CEST] <oreWizard> i have 30 yo =)
[11:12:12 CEST] <nanoEng> But it still bothers me, why the hell i should need a 4 GB IDE.
[11:12:20 CEST] <oreWizard> i see
[11:12:29 CEST] <nanoEng> you are 30 yr old, or you have a 30 year old son or daughter?
[11:12:39 CEST] <oreWizard> lol
[11:12:42 CEST] <oreWizard> i dont have kids
[11:12:45 CEST] <oreWizard> i have only 30
[11:12:48 CEST] <oreWizard> :)
[11:12:54 CEST] <nanoEng> oh, you said you have a 30 year old
[11:13:01 CEST] <nanoEng> you mean you ARE 30 years old.
[11:13:05 CEST] <oreWizard> sory
[11:13:13 CEST] <nanoEng> people might get confused., just fyi
[11:13:13 CEST] <oreWizard> need pratice for writting text
[11:13:19 CEST] <oreWizard> in english
[11:13:22 CEST] <nanoEng> no worries
[11:13:29 CEST] <oreWizard> not my native language
[11:13:31 CEST] <nanoEng> i am turning 30 in a few days -_-
[11:13:40 CEST] <oreWizard> congratz
[11:13:48 CEST] <oreWizard> 30 is the best age so far =)
[11:13:53 CEST] <nanoEng> my last days being in my 20s and this is how i am spending them -_-
[11:14:00 CEST] <nanoEng> lol
[11:14:06 CEST] <oreWizard> in my 30 yo birhday
[11:14:09 CEST] <oreWizard> i spend 30 dolares
[11:14:17 CEST] <oreWizard> on a virtual striper
[11:14:18 CEST] <oreWizard> show
[11:14:21 CEST] <nanoEng> on what? hookers and booz?
[11:14:21 CEST] <oreWizard> lol
[11:14:29 CEST] <nanoEng> lol
[11:14:37 CEST] <nanoEng> virtual? not even a real one? :p
[11:14:40 CEST] <oreWizard> i donnt like hoojer
[11:14:43 CEST] <oreWizard> for sex
[11:14:52 CEST] <nanoEng> i wouldn't know myself.
[11:14:54 CEST] <oreWizard> i never did it wiht one
[11:15:11 CEST] <nanoEng> keep ur peter clean
[11:15:22 CEST] <oreWizard> yes
[11:15:37 CEST] <nanoEng> anyway, what happened to the geniuses on here?
[11:15:40 CEST] <oreWizard> the clubs around arent the best place to be in it
[11:15:45 CEST] <nanoEng> i can't even spell geniuses
[11:15:50 CEST] <nanoEng> lets ask google
[11:15:50 CEST] <oreWizard> idk here is 6.0 am
[11:15:58 CEST] <oreWizard> geniuses?
[11:16:01 CEST] <oreWizard> ops
[11:16:17 CEST] <oreWizard> nanoEng
[11:16:19 CEST] <nanoEng> geniuses
[11:16:19 CEST] <oreWizard> greate news
[11:16:26 CEST] <oreWizard> no error again on pkg-config
[11:16:32 CEST] <nanoEng> ta da! you win
[11:16:36 CEST] <oreWizard> sucessful msys2 download
[11:16:40 CEST] <oreWizard> thx man!
[11:16:41 CEST] <nanoEng> hey, i win too! i'm also a genius!
[11:16:50 CEST] <oreWizard> cool we can be 40 now
[11:17:06 CEST] <nanoEng> lol
[11:17:24 CEST] <nanoEng> ah, the msys/pkg-config thing worked?
[11:17:42 CEST] <oreWizard> pacman -S pkg-config
[11:17:48 CEST] <nanoEng> ?
[11:17:56 CEST] <nanoEng> oh you don't need the part in front? hmm
[11:17:57 CEST] <oreWizard> pacman -S msys/pkg-config
[11:18:04 CEST] <nanoEng> ah.
[11:18:05 CEST] <nanoEng> yeah
[11:18:11 CEST] <nanoEng> with msys
[11:18:29 CEST] <oreWizard> nanoEng thank you again, i going out for breakfest
[11:18:32 CEST] <oreWizard> see you later
[11:18:35 CEST] <nanoEng> not mingw64/mingw-w64.blahblabh
[11:18:43 CEST] <nanoEng> ok c ya man
[11:18:57 CEST] <nanoEng> glad i could help
[11:20:26 CEST] <nanoEng> BtbN you wouldn't happen to know how to get MSYS to say SDL yes in that list you get after doing ./config [blahblah] would you?
[11:20:35 CEST] <nanoEng> MSYS2 that is.
[11:21:25 CEST] <BtbN> I have no idea about the various linux-simulators that are available for windows.
[11:22:08 CEST] <nanoEng> various?
[11:22:21 CEST] <BtbN> i can think of at least 5 right away.
[11:22:23 CEST] <nanoEng> mingw and msys are the defacto
[11:22:29 CEST] <nanoEng> i thought anyway
[11:22:32 CEST] <BtbN> mingw, msys, msys2, cygwin, ...
[11:22:37 CEST] <nanoEng> yeah
[11:22:43 CEST] <nanoEng> those are all releated to each other
[11:22:47 CEST] <nanoEng> first was cygwin
[11:22:53 CEST] <nanoEng> then mingw was an offshoot of that
[11:23:04 CEST] <nanoEng> i forgot how msys comes into the picture
[11:23:49 CEST] <nanoEng> and then msys2 was to integrate 64bit capability, and rewrite the headers or something-arother, better less pain in the ass than regular msys
[11:24:06 CEST] <nanoEng> the end.
[11:24:46 CEST] <nanoEng> so i decided to try and use the less-pain-in-the-butt one, msys2, the latest and greatest.
[11:24:58 CEST] <nanoEng> seemed like it would have the smallest learning-curve
[11:25:31 CEST] <nanoEng> unfortunatly, being newest, it has the least documentation/stack-overflow posts.
[11:27:49 CEST] <nanoEng> However, i wanted to build a 64bit build of ffplay
[11:28:31 CEST] <nanoEng> so i went with msys2 since it uses mingw-w64.
[11:28:51 CEST] <nanoEng> And besides that's the FFmpeg website says to use.
[11:29:18 CEST] <nanoEng> And then the FFmpeg website says to: In order to compile FFplay, you must have the MinGW development library of SDL and pkg-config installed.
[11:29:54 CEST] <nanoEng> But doesn't tell you how to install that, even though the link above that tells you explicitly how to get msys/mingw-w64 up and running.
[11:30:20 CEST] <nanoEng> then they just give you a link to libsdl.org and that's it.
[11:30:22 CEST] <BtbN> How to install stuff just changes way too frequently. It's not the job of ffmpeg to document how to use your package manager.
[11:30:45 CEST] <eightfold> howdy
[11:30:50 CEST] <nanoEng> Its not mine
[11:31:00 CEST] <nanoEng> its the one THEY told me to use.
[11:31:18 CEST] <eightfold> i have a ts file that should contain an AAC stream and an H.264 stream according to ffprobe
[11:31:42 CEST] <eightfold> i want to put the data in a MKV container instead, mostly because VLC wont play the TS
[11:32:19 CEST] <eightfold> so i use:
[11:32:22 CEST] <eightfold> ffmpeg -i input.ts -vcodec copy -acodec copy -f matroska output.mkv
[11:32:55 CEST] <eightfold> however, with that i get error messages (although the file converts)
[11:32:55 CEST] <BtbN> replace the middle with -c copy, those options are deprecated.
[11:33:17 CEST] <BtbN> you also don't need -f, the .mkv extension is enough.
[11:33:52 CEST] <nanoEng> let me guess.... lack of good documentation...
[11:33:59 CEST] <eightfold> heres the output: https://gist.github.com/anonymous/46903af82d569ae20c7d
[11:34:04 CEST] <nanoEng> ... or any..
[11:34:05 CEST] <eightfold> BtbN: ok!
[11:34:19 CEST] <BtbN> No just tons of years of outdated examples everywhere on the internet.
[11:34:43 CEST] <nanoEng> exactly, which no one would look at, if there was good documentation too look at instread.
[11:34:54 CEST] <nanoEng> why are people even looking at all those outdated examples?
[11:35:01 CEST] <nanoEng> Because there's nothing else to look at!
[11:35:02 CEST] <BtbN> Because google lists them first.
[11:35:07 CEST] <eightfold> so both vcodec and acodec should be replaced with -c copy?
[11:35:18 CEST] <BtbN> -c copy is enough
[11:35:30 CEST] <BtbN> it matches all streams
[11:35:36 CEST] <eightfold> Error parsing AAC extradata, unable to determine samplerate.
[11:35:53 CEST] <BtbN> Your file is propably corrupted then
[11:35:57 CEST] <eightfold> ffprobe shows 94 kb/s
[11:36:00 CEST] <BtbN> try increasing the analyze duration
[11:36:08 CEST] <eightfold> i dont think its corrupt
[11:36:22 CEST] <eightfold> every file that this program outputs gets the same message
[11:36:33 CEST] <eightfold> of course every file could be corrupt, but what do i know
[11:36:57 CEST] <eightfold> ffprobe shows: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 94 kb/s
[11:36:58 CEST] <eightfold> to be exact
[11:37:26 CEST] <nanoEng> is there a way to test for corruption?
[11:37:51 CEST] <eightfold> what is a good length for -analyzeduration to try?
[11:38:53 CEST] <BtbN> just try something very high first, and if it works, reduce it step by step
[11:39:11 CEST] <BtbN> It's in microseconds iirc., so it needs big numbers
[11:39:11 CEST] <eightfold> -analyzeduration 1000000000
[11:39:25 CEST] <eightfold> sitll [matroska @ 0x7f9af4806000] Error parsing AAC extradata, unable to determine samplerate
[11:39:42 CEST] <nanoEng> And if that doesn't work, do a Fourier transform on it.
[11:40:00 CEST] <BtbN> Almost looks like the aac extradata is ineeded corrupted
[11:40:00 CEST] <eightfold> nanoEng: i dont know how to do that
[11:40:16 CEST] <nanoEng> (eightfold neither do i)
[11:40:32 CEST] <BtbN> You could try re-encoding the audio, maybe ffmpeg is able to understand it still
[11:40:34 CEST] <eightfold> BtbN: the file converts/remuxes and audio works
[11:40:35 CEST] <nanoEng> i'm just kidding, ignore me, i don't know i'm talking about
[11:40:45 CEST] <nanoEng> <--sleep deprived
[11:40:54 CEST] <eightfold> i just want to be sure that the audio is not transcoded
[11:40:57 CEST] <eightfold> that is very important to me
[11:41:48 CEST] <nanoEng> transcoded=re-encoded?
[11:41:56 CEST] <eightfold> yes
[11:42:08 CEST] <eightfold> i just want to move the streams into a new container
[11:42:33 CEST] <eightfold> the process takes some time and shows something like this:
[11:42:35 CEST] <eightfold> frame=26587 fps=8859 q=-1.0 size= 363577kB time=00:17:43.46 bitrate=2800.7kbits/s
[11:42:47 CEST] <eightfold> so im a bit afraid its being re-encoded
[11:42:49 CEST] <eightfold> is it?
[11:44:00 CEST] <nanoEng> AviDemux ?
[11:44:35 CEST] <eightfold> not the best on os x i believe
[11:44:56 CEST] <nanoEng> oh :\
[11:45:15 CEST] <nanoEng> and that's why i don't trust apple....
[11:45:44 CEST] <eightfold> also, i have an srt file that id like to get into the MKV in this process
[11:45:47 CEST] <nanoEng> then again, i wouldn't be here if i didn't trust MS either...
[11:45:49 CEST] <eightfold> how would i do that?
[11:46:08 CEST] <nanoEng> you can do that?
[11:46:27 CEST] <eightfold> yeah, i should be able to
[11:46:37 CEST] <eightfold> seems you should specify srt as -i
[11:46:38 CEST] <eightfold> too
[11:46:43 CEST] <eightfold> but that doesnt seem to work
[11:50:07 CEST] <nanoEng> In file included from /usr/include/SDL/SDL_stdinc.h:30:0, from /usr/include/SDL/SDL_main.h:26, from /usr/include/SDL/SDL.h:30, from libavdevice/sdl.c:26: /usr/include/SDL/SDL_config.h:42:32: fatal error: SDL_config_minimal.h: No such file or directory #include "SDL_config_minimal.h" ^ compilation terminated. common.mak:57: recipe for target 'libavdevic
[11:50:33 CEST] <nanoEng> hmmm, no multi-line, huh?
[11:51:59 CEST] <nanoEng> Anyone understand this? pastebin.com/RjPQ3jMC ??
[11:52:35 CEST] <nanoEng> error after running $ make
[11:53:19 CEST] <nanoEng> what happend to link. try again: pastebin.com/RjPQ3jMC
[11:53:25 CEST] <nanoEng> hm... http://pastebin.com/RjPQ3jMC
[11:53:27 CEST] <nanoEng> there we go
[13:11:29 CEST] <claz> hey, i want to modify the fps of a file and i'm using the setpts filter like so : "ffmpeg -i src.mp4 -vf 'setpts=N/(25*TB)' out.mp4' but my problem is about 3/4 of the frames are dropped
[13:11:35 CEST] <claz> is there any way to not drop frames?
[13:12:59 CEST] <Mavrik> O.o
[13:13:11 CEST] <BtbN> What output fps does ffmpeg think the file is?
[13:13:23 CEST] <BtbN> Maybe it tries to adjust from the 25 you are generating with setpts
[13:15:03 CEST] <claz> googled some more and turns out i need to also use the -r 25 option
[13:15:14 CEST] <claz> otherwise output file has same fps as input
[13:15:19 CEST] <claz> which was 6fps
[13:15:29 CEST] <claz> all good now, thanks :)
[13:15:56 CEST] <BtbN> you also might want to increase the encoding quality, the default is usualy quite bad.
[13:16:17 CEST] <claz> yep, just wanted to see if i can fix the fluidity first
[15:10:28 CEST] <satiender> Hi there have any which is develop ffmpeg for android
[15:11:02 CEST] <satiender> actually I want try to compile ffmpeg for android but there have multiple errors
[15:11:29 CEST] <satiender> So, There have anybody which compile the ffmpeg library for android
[15:11:36 CEST] <satiender> please help
[16:30:02 CEST] <luks> hi, can somebody help me how to set these options when using ffmpeg as a library? https://www.ffmpeg.org/ffmpeg-protocols.html#http
[16:30:23 CEST] <luks> I guess I need to use av_opt_set, but I don't know what object to call it on
[17:12:34 CEST] <Oleg_> I still want to find out why sound eventually disappears from the video that I am trying to encode using these parameters:
[17:13:02 CEST] <Oleg_> ffmpeg -f oss -i /dev/dsp3 -f v4l2 -i /dev/video0 output.mkv
[17:16:17 CEST] <pzich> eventually disappears? like a few days later?
[17:17:18 CEST] <Oleg_> the video has these parameters: http://pastebin.com/ZxR63PmF
[17:18:05 CEST] <Oleg_> pzich, when the video starts, I can hear sound coming from it, but it disappears a few seconds later
[17:19:14 CEST] <pzich> have you tried recording them separately?
[17:20:46 CEST] <Oleg_> pzich, if I do that, how will I be able to put both video and audio into one file and make sure they are in sync with one another?
[17:24:22 CEST] <Oleg_> pzich, these are the encoder settings that are used: http://pastebin.com/V6PUraaN
[17:25:41 CEST] <Oleg_> c_14, sup
[17:25:57 CEST] <prelude2004c> hello everyone. Question. I would like to create a playlist with playout DB. I don't want to loose any time between shows.. Eg... I have a playlist , play 1, play2 play3, etc etc... I want ffmpeg to open play 1 , then play 2, then play 3 but dynamic. Eg.. If someone in the DB changes what comes in after 2 and say go to 4, then after every file it checks whats next and plays what is next. THe only thing is.. i dont want to have any delay be
[17:26:08 CEST] <prelude2004c> millisecond... i dont want to start loosing time
[17:26:54 CEST] <prelude2004c> any ideas on what tis the best approach ? eg.. is there some way to have ffmpeg pickup a file... load it get ready to play and only play file at the exact moment the other file ends ? I am going to be outputing to UDP so i dont want to loose any frames between one file to another
[17:37:54 CEST] <prelude2004c> anyone?
[18:15:51 CEST] <Oleg_> please help!!!!
[18:21:19 CEST] <jasom> ffmpeg 2.9.3 on gentoo, I get messages like: frame=258747 fps=162 q=23.0 size= 474149kB time=02:23:52.45 bitrate= 450.0kbits[Parsed_overlay_0 @ 0x25ba530] [framesync @ 0x22c9a68] Buffer queue overflow, dropping.
[18:21:59 CEST] <jasom> input is from a DVD, so mpeg-2 TS with dvd subs
[18:22:35 CEST] <jasom> There are multiple subtitle streams I want simultaneously displayed so I'm using multiple overlay filters in the filter graph
[18:23:10 CEST] <jasom> sorry should be 2.6.3 not 2.9.3
[18:33:57 CEST] <Oleg_> guys, how do I mux audio and video into one file?
[18:34:24 CEST] <KarlFranz> Which sort of file?
[18:34:31 CEST] <Oleg_> mkv
[18:34:43 CEST] <Oleg_> I want audio and video to be in sync with one another
[18:34:50 CEST] <JEEB> ffmpeg -i video -i audio -c copy out.mkv
[18:34:53 CEST] <JEEB> uhh
[18:35:03 CEST] <JEEB> with more tracks etc you might also want map
[18:35:11 CEST] <JEEB> like -map 0:v and -map 0:a
[18:35:15 CEST] <JEEB> *-map 1:a
[18:36:14 CEST] <Oleg_> JEEB, audio is the name of a file in your example?
[18:37:08 CEST] <JEEB> yes
[18:37:53 CEST] <Oleg_> and will audio and video be in sync in the new file?
[18:43:27 CEST] <jasom> Oleg_: only if they are in sync in the separate files.
[18:49:00 CEST] <Oleg_> JEEB, I need audio and video to be in sync
[18:51:18 CEST] <pzich> if the input files aren't already in sync, you can try following something like http://alien.slackbook.org/blog/fixing-audio-sync-with-ffmpeg/
[18:53:31 CEST] <Oleg_> pzich, if video and audio files are recorded separately, then, of course they will be out of sync
[18:55:03 CEST] <Oleg_> pzich, because they are different in the first place
[18:55:24 CEST] <Oleg_> pzich, I wanna record the video of myself talking using my webcam
[18:58:14 CEST] <Oleg_> please tell me what to do
[19:00:49 CEST] <Oleg_> JEEB?
[19:01:23 CEST] <Oleg_> is there something wrong with this command:
[19:01:26 CEST] <Oleg_> ffmpeg -f oss -i /dev/dsp3 -f v4l2 -i /dev/video0 output.mkv
[19:01:27 CEST] <Oleg_> ?
[19:06:22 CEST] <Oleg_> HELLO!!!!
[19:26:12 CEST] <phr3ak> how could I play audio file on text console?
[19:27:00 CEST] <iive> try -vn option
[19:28:25 CEST] <phr3ak> I tried already
[19:28:29 CEST] <phr3ak> Could not initialize SDL - No available video device
[19:28:29 CEST] <phr3ak> (Did you set the DISPLAY variable?)
[19:29:04 CEST] <phr3ak> I tried with ffplay
[19:29:57 CEST] <llogan> ffmpeg -i INPUT -f alsa default
[19:30:00 CEST] <phr3ak> thanks
[19:30:09 CEST] <phr3ak> ffmpeg -i V0099601.wav -vn -f alsa hw:0
[19:30:22 CEST] <phr3ak> default is also good thanks
[19:31:29 CEST] <phr3ak> is it possible to seek in the audio with keyboard?
[19:31:47 CEST] <llogan> im not sure. give it a try
[19:32:01 CEST] <llogan> i doubt it though
[19:32:32 CEST] <llogan> nevermind, i was thinking you were using ffplay, although i just gave a ffmpeg command
[19:33:46 CEST] <llogan> or you could try ffplay with -nodisp
[19:39:59 CEST] <Oleg_> phr3ak, /dev/dsp3 corresponds to what alsa node?
[19:40:25 CEST] <Oleg_> phr3ak, maybe with alsa, I won't have sound issues?
[19:43:14 CEST] <Oleg_> people!!!
[19:43:25 CEST] <Oleg_> -f oss -i /dev/dsp3 corresponds to what alsa node?
[19:43:33 CEST] <Oleg_> hw:3,3?
[19:43:34 CEST] <Oleg_> or what?
[19:45:11 CEST] <Oleg_> PEOPLE!!!!
[19:48:56 CEST] <Mavrik> Oleg_, stop yelling.
[19:49:07 CEST] <Mavrik> OSS and ALSA nodes don't correspond.
[19:49:24 CEST] <Mavrik> So you'll have to use alsa tools to figure out which input is the one you're looking for.
[19:50:19 CEST] <Oleg_> Mavrik, do you see anything that might cause issues if I execute this command:
[19:50:33 CEST] <Oleg_> ffmpeg -f oss -i /dev/dsp3 -f v4l2 -i /dev/video0 output.mkv
[19:50:57 CEST] <Mavrik> You're not setting codecs or quality.
[19:51:04 CEST] <Mavrik> Also not sure if OSS still works on modern distros?
[19:51:36 CEST] <Oleg_> Marvik: please tell me how to set codecs and quality
[20:19:04 CEST] <Oleg_> so, I uploaded this video: https://www.youtube.com/watch?v=Ye3FLXMKv1U , so you would be able to see what kind of problems I have with the sound
[20:19:52 CEST] <Oleg_> as you can see, the sound is either absent or not absent from the video
[20:20:01 CEST] <Oleg_> any idea what causes this issue?
[20:20:27 CEST] <Oleg_> as I said, this video was recorded with the command: "ffmpeg -f v4l2 -i /dev/video0 -f oss -i /dev/dsp3 output.mkv
[20:20:29 CEST] <Oleg_> "
[20:21:31 CEST] <Oleg_> folks?
[20:23:14 CEST] <Oleg_> Mavrik, can you take a look at this please: https://www.youtube.com/watch?v=Ye3FLXMKv1U ?
[20:28:01 CEST] <Oleg_> FOLKS!!!!
[20:29:40 CEST] <durandal_170> what you use for audio recording?
[20:30:28 CEST] <Oleg_> durandal_170, the microphone which is inside the webcam
[20:31:27 CEST] <durandal_170> and why you use oss?
[20:32:11 CEST] <Oleg_> durandal_170, you think that if I try using alsa, it might fix this problem?
[20:33:04 CEST] <durandal_170> dunno
[20:47:25 CEST] <Fjorgynn> :D
[23:26:51 CEST] <tonsofpcs> who should I report GPL violations (against ffmpeg) to?
[23:29:37 CEST] <KarlFranz> Hasn't the project's site a contact link?
[23:30:14 CEST] <tonsofpcs> I suppose the proper legal response is "I can't say for sure since the package I received did not include any license or contact information"
[23:32:23 CEST] <tonsofpcs> amyway, the contact page on the site just points to mailing lists and IRC
[23:36:02 CEST] <KarlFranz> I was checking that
[23:37:49 CEST] <KarlFranz> I suppose you could check who is the copyright holder in the license, if you have it.
[23:37:52 CEST] Action: KarlFranz checks
[23:38:42 CEST] <KarlFranz> I gpt something.
[23:38:54 CEST] <c_14> tonsofpcs: you can report license violations on trac
[23:39:06 CEST] <tonsofpcs> c_14: is trac public postable or do accounts need auth?
[23:39:25 CEST] <llogan> you need to register to make a bug report
[23:39:34 CEST] <llogan> but tickets are public visable
[23:40:06 CEST] <KarlFranz> It does not look very discrete to me.
[23:40:18 CEST] <KarlFranz> There is a document with the list of maintainers
[23:40:36 CEST] <llogan> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&type=l…
[23:40:42 CEST] <KarlFranz> And I found a list of gpg fingerprints for maintainers and contributors. I suppose you could get the keys and look at the addresses.-
[23:40:50 CEST] <tonsofpcs> oh, I could directly e-mail most of the maintainers but I don't know if maybe someone is nominally handling them
[23:41:06 CEST] <llogan> making a bug report is the best method
[23:41:34 CEST] <llogan> allows potential follow-up by the violator and the public shame is a good motivator
[23:41:39 CEST] <KarlFranz> There is a communication team.
[23:41:52 CEST] <KarlFranz> But yes, if you don t need secrecy, a bug report is probably better
[23:42:06 CEST] <tonsofpcs> llogan: generally you don't publicly shame someone unless they've been given a chance to rectify in private first...
[23:42:17 CEST] <Nolski> ^
[23:42:20 CEST] <Nolski> Agreed
[23:42:58 CEST] <Nolski> The Software Freedom Concervancy worked with VMware for 4 years before going public about the GPL violation
[23:42:59 CEST] <KarlFranz> Alexander Strasser, Michael Niedermayer, Carl Eugen Hoyos, Lou Logan <- Trac communication team.
[23:43:00 CEST] <llogan> then feel free to contact the violator and do it yourself
[23:43:08 CEST] <llogan> privately
[23:43:20 CEST] <KarlFranz> https://paste.debian.net/297544/ <- List of gpg keys
[23:43:27 CEST] <KarlFranz> I'd say that should suffice.
[23:43:50 CEST] <llogan> if you email me then i'll tell you to post it on trac.
[23:44:07 CEST] <tonsofpcs> KarlFranz: llogan is right here...
[23:44:20 CEST] <KarlFranz> heh, ok
[23:45:05 CEST] <llogan> if they violate then they can be listed. it's that simple. if they fix the issue (often it is simple misunderstanding) then it can get fixed.
[23:47:08 CEST] <llogan> if you prefer to pursue it via private communication between yourself and the violator then feel free to do so
[00:00:00 CEST] --- Wed Aug 19 2015
1
0
[00:00:51 CEST] <durandal_1707> i wonder how hw scopes work...
[00:02:44 CEST] <cone-455> ffmpeg 03Philip Langdale 07master:d3eb317b862c: ffmpeg_vdpau: Ignore decoder's max supported level
[01:27:34 CEST] <Compn> as long as no one deletes muh lowres.
[01:27:35 CEST] <Compn> :P
[01:29:19 CEST] <kierank> yes
[01:54:14 CEST] Action: rcombs scrolls up
[01:54:23 CEST] Action: rcombs finds this truncated issue description:
[01:54:30 CEST] <rcombs> (Incompatibilities between XBMC/Kodi & mkvalidator relating to how FFmpeg &)
[01:54:48 CEST] Action: rcombs headtilt
[01:58:03 CEST] <BBB_> the annoying thing is that half of these things scheduled for removal dont work
[01:58:17 CEST] <BBB> like, Im trying to build ffmpeg with half of these things set to 0
[01:58:21 CEST] <BBB> and it just doesnt work
[01:58:24 CEST] <BBB> its not just that it doesnt build
[01:58:33 CEST] <BBB> once you get it to build, fate fails on everything
[01:59:03 CEST] <BBB> (AVFormatContext.flags = bitexact is no longer automatically copied from AVCodecContext.flags = bitexact)
[01:59:09 CEST] <BBB> hugely annoying
[01:59:17 CEST] <BBB> why dont we hae a fate station for this?
[02:00:35 CEST] <wm4> lol
[02:00:57 CEST] <wm4> sometimes I wonder why bother with this ifdeffery shit
[02:08:40 CEST] <BBB> dunno
[02:08:48 CEST] <BBB> Im slowly trying to untangle some of this mess
[02:08:59 CEST] <BBB> but all I have is a laptop so running fate trillions of times takes forever :(
[03:01:08 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07master:7f769ae41e0d: avcodec/rv30: fix switching back to the original resolution
[03:20:53 CEST] <cone-455> ffmpeg 03Michael Niedermayer 07master:3afca32561d9: swscale/swscale-test: Fix slice height in random reference data creation.
[05:01:48 CEST] <Taniey> ask some questions about drawtext: I import windows fonts to centos 6.5 ,and use ttmkfdir to reload the windows fonts, so I can use the filter 'drawtext' of ffmpeg with version 2.7.2 to draw some text video , but some characters not in ansii table can`t draw to the video ,how can i resolve about this?
[05:02:08 CEST] <Taniey> command like this:
[05:06:52 CEST] <Taniey> ffmpeg.exe -y -i .\Ice.Age.Continental.Drift.2012.720sp.mkv -filter_complex "drawtext=textfile=\'drawtext.txt\':font=\
[05:06:52 CEST] <Taniey> 'arial\':fontsize=48:fontcolor=00ffff:x=50:y=200" -sn -codec:v h264 -codec:a aac -strict -2 out.mkv
[05:16:12 CEST] <Taniey> content of drawtext.txt like this: 'test draw text
[05:16:13 CEST] <Taniey> L€ž
[05:16:13 CEST] <Taniey> 'D5JFJ)'
[05:19:38 CEST] <Taniey> content of drawtext.txt contain : Korean ,english, etc.
[05:22:38 CEST] <Taniey> command :
[05:22:42 CEST] <Taniey> ffmpeg -y -i Ice.Age.Continental.Drift.2012.720sp.mkv -filter_complex "drawtext=textfile=\'drawtext.txt\':font=\'arial\':fontsize=48:fontcolor=00ffff:x=50:y=200" -sn -codec:v h264 -codec:a aac -strict -2 out.mkv
[06:42:21 CEST] <Taniey> anybody know about this question.
[07:48:03 CEST] <Taniey> ffmpeg drawtext filter draw Arabic string is reversed. the Arabic string in text is like [abcd], but draw on video is like [dcba],is it right?
[07:50:26 CEST] <Taniey> how can i use ffmpeg drawtext filter to draw bold fonts ?
[07:58:01 CEST] <ubitux> Taniey: you need --enable-libfribidi
[07:58:34 CEST] <Taniey> bold fonts?
[07:58:41 CEST] <ubitux> text reverse
[07:59:08 CEST] <Taniey> how can I use the command?
[07:59:41 CEST] <ubitux> at build time
[07:59:48 CEST] <Taniey> how can I spell the command?
[08:00:03 CEST] <ubitux> also, these are questions for #ffmpeg
[08:00:15 CEST] <ubitux> ./configure --enable-libfribidi
[08:02:33 CEST] <Taniey> i am sorry , i know how configure this option ,but the ffmpeg command is same like other ffmpeg drawtext ?
[08:03:01 CEST] <ubitux> to fix the reversed text string, yes
[08:05:31 CEST] <Taniey> thanks ,i will try it.
[08:06:09 CEST] <Taniey> can you know about other two question?
[08:13:01 CEST] <BtbN> philipl, well, I'm at a point where i'd at least hope to get _something_
[08:13:08 CEST] <BtbN> But it just tells me "invalid parameter"
[08:13:14 CEST] <BtbN> And there are hundrets of parameters.
[09:37:19 CEST] <j-b> 'morning
[10:22:07 CEST] <__gb__> hi BtbN, generally, you can get more information through the companion source code to the VA intel-driver :)
[10:23:21 CEST] <BtbN> You mean simply reading through the code of it? Or is there some kind of tool for that?
[10:23:43 CEST] <BtbN> The intel driver is unhappy about some parameters i'm setting, but it doesn't tell me which one.
[10:24:09 CEST] <__gb__> yes, through the code, doesn't INTEL_DEBUG report the line number?
[10:24:59 CEST] <BtbN> You mean the VA_INTEL_DEBUG environment variable?
[10:25:25 CEST] <__gb__> BtbN, for hevc specifics, as a hint, you can see dxva2 code, the VA-API seems to have built after that so that some people could just reuse some code in some driver
[10:25:27 CEST] <__gb__> yes
[10:26:02 CEST] <BtbN> I set that to 3, but there is no additional output except for one line confirming it was set to 3.
[10:29:53 CEST] <__gb__> if you get some INVALID_PARAMETER (18) for hevc, the most plausible cause could be that VAPictureParameterBufferHEVC sanity checks failed
[10:30:13 CEST] <__gb__> most probably ReferenceFrames[].flags
[10:30:36 CEST] <__gb__> ?
[10:31:08 CEST] <__gb__> and unfortunately, error reporting/debug is somewhat involved
[10:31:29 CEST] <__gb__> you'd probably want to instrument intel_decoder_check_hevc_parameter() if that is the one failing for you
[10:31:43 CEST] <nevcairiel> BtbN: just be happy you have soem way to debug, with dxva2 you get nothing, either it works, or it doesnt =p
[10:32:05 CEST] <__gb__> there is always a way if you have sources :)
[10:32:13 CEST] <nevcairiel> windows things dont give out sources
[10:32:43 CEST] <__gb__> BtbN, btw, I was about to start hevc decode this week, but go on if you want :)
[10:33:04 CEST] <nevcairiel> but by carefully comparing the dxva2 hevc spec, the actual hevc spec, and the avcodec code, it eventually worked out to find the exact values that need to go in there
[10:33:18 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commits/vaapi_hevc that's what i have so far.
[10:33:23 CEST] <nevcairiel> luckily microsoft defined a decent spec, and not only provides headers without explanation
[10:34:55 CEST] <wm4> <nevcairiel> windows things dont give out sources <- pretty sure the intel linux department gets to see the sources of the intel windows department (or at least it sounds so)
[10:35:06 CEST] <nevcairiel> well within a company certainly
[10:35:07 CEST] <__gb__> I believe that spec is jointly defined by the 3 GPU vendors too?
[10:35:11 CEST] <nevcairiel> but that doesnt help me :p
[10:35:20 CEST] <__gb__> wm4, absolutely not
[10:35:34 CEST] <__gb__> unless you want to be contaminated and inadvertally leak out some IP
[10:35:47 CEST] <BtbN> comparing the picture flags the gst decoder sets, and the one I set so far, it seems not too unlikely that something is missing there
[10:36:35 CEST] <__gb__> I'd say I also have reasons to believe that some people get to RE some things to better understand some things
[10:37:11 CEST] <wm4> interesting
[10:37:49 CEST] <__gb__> probably faster than getting through several layers
[14:07:32 CEST] <wm4> lol is ffmpeg-devel now about recommending nvenc-compatible devices
[14:07:47 CEST] <JEEB> lol
[15:19:51 CEST] <Compn> that would probably be a good idea to recommend compatable devices that are known to work with ffmpeg
[15:19:59 CEST] <Compn> but hey, i care about users...
[15:49:34 CEST] <BBB> so what is the proposed mechanism for having media-type specific defaults for codec options?
[15:51:04 CEST] <BBB> (Im looking at the av_opt_set_defaults2 deprecation and it breaks everything, which is expected)
[15:51:19 CEST] <BBB> (because libav removed ab , we didnt, so we now use audio default bitrate for video streams also)
[15:51:48 CEST] <durandal_170> huh?
[15:54:08 CEST] <durandal_170> isnt it -b:a ?
[15:54:31 CEST] <cone-075> ffmpeg 03Carl Eugen Hoyos 07master:84170d4be053: lavc/mjpegdec: Detect more CMYK images.
[15:54:33 CEST] <BBB> FF_API_OLD_AVOPTIONS removes av_opt_set_defaults2, which has a mask/flag, which is used in avcodec_get_context_defaults3 to have a masked default set
[15:54:46 CEST] <BBB> so after removal, we call av_opt_set_defaults without mask/flag
[15:54:53 CEST] <BBB> (or I assume thats the intention)
[15:54:56 CEST] <BBB> in the table, we have this:
[15:55:07 CEST] <BBB> {"b", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT, {.i64 = AV_CODEC_DEFAULT_BITRATE }, 0, INT_MAX, A|V|E},
[15:55:12 CEST] <BBB> {"ab", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT, {.i64 = 128*1000 }, 0, INT_MAX, A|E},
[15:55:28 CEST] <BBB> if we remove the mask, video streams now cant mask the audio ab out, so we use the audio bitrate for video streams
[15:55:32 CEST] <BBB> all fate results change as a result
[15:55:36 CEST] <BBB> so& what is the intention here?
[15:55:49 CEST] <BBB> do we want to keep the mask? do we want to follow libav and remove ab ?
[15:55:54 CEST] <BBB> something else?
[15:56:07 CEST] <BBB> (AV_CODEC_DEFAULT_BITRATE = 200 * 1000)
[15:57:04 CEST] <Daemon404> git blame and ask the person who wrote it?
[15:57:15 CEST] <BBB> it obviously comes from libav
[15:57:18 CEST] <BBB> and michael merged it
[15:57:26 CEST] <Daemon404> so ask teh author?
[15:57:36 CEST] <Daemon404> or is this one of those "i cant talk to X because Y"
[15:57:43 CEST] <BBB> no, libavs intention is obvious
[15:57:45 CEST] <BBB> remove av"
[15:57:48 CEST] <BBB> ab
[15:57:59 CEST] <BBB> but we didnt take that part of the patch when we merged it
[15:58:01 CEST] <BBB> and its unclear why
[15:58:05 CEST] <Daemon404> oh.
[15:58:06 CEST] <BBB> because thats why it breaks
[15:58:24 CEST] <Daemon404> probably because carl and otehr ffmpeg devs have a huge hardon for "not breaking user's scritps ever"
[15:58:24 CEST] <BBB> so I guess my question is: what is the intention of not merging ab ?
[15:58:37 CEST] <BBB> ...
[15:58:53 CEST] <BBB> then why merge it at all
[15:58:59 CEST] <Daemon404> don't ask me.
[15:59:28 CEST] <Daemon404> this same bullheadedness led to other problems and hilariousness
[16:00:19 CEST] <nevcairiel> because -b:a is hard to type, obviously
[16:00:27 CEST] <BBB> much harder than -ab, yes
[16:00:36 CEST] <BBB> statistically speaking, about 33% harder
[16:00:48 CEST] <BBB> plus its a non-alphanumerical character, so 17 extra bonus points for that
[16:00:54 CEST] <BBB> 50% harder
[16:00:56 CEST] <nevcairiel> it requires the shift key too!
[16:00:59 CEST] <nevcairiel> at least on german keyboards
[16:01:02 CEST] <nevcairiel> dont ask me where it is on US
[16:01:09 CEST] <Daemon404> shift semicolon
[16:01:10 CEST] <BBB> also shift (under emicolon)
[16:02:17 CEST] <durandal_170> You do not type -ab all the time
[16:02:23 CEST] <iive> michael doesn't merge anymore, does he?
[16:02:33 CEST] <Daemon404> iive, this was long long in the past
[16:06:55 CEST] <nevcairiel> BBB: worst case just make both have the same default
[16:07:41 CEST] <nevcairiel> the default bitrate is probably crappy for video no matter what, though
[16:17:12 CEST] <BBB> so are people generally ok with me just doing what libav did and thus effectively bumping the default audio bitrate to 200k?
[16:17:56 CEST] <BBB> (Im not suggesting anyone ever encode anything without setting a bitrate, but it affects fate so this will cause a lot of changes)
[16:18:23 CEST] <BBB> (to refs)
[16:19:29 CEST] <BBB> Ill just go ahead and do it
[16:19:36 CEST] <BBB> I cant imagine anyone even remotely caring about this cruft
[16:19:54 CEST] Action: Daemon404 waits for carl
[16:20:36 CEST] <iive> BBB: actually people expect the bitrate to be appropriate value for the used codec
[16:20:48 CEST] <Daemon404> iive, that was never true
[16:20:48 CEST] <Daemon404> ever
[16:20:53 CEST] <BBB> iive: patch welcome
[16:21:07 CEST] <iive> Daemon404: it's still true. But ffmpeg never did it :)
[16:21:10 CEST] <nevcairiel> some codecs have specific defaults, but i dont think any include a bitrate
[16:21:23 CEST] <Daemon404> iive, yes that's what i meany
[16:21:27 CEST] <Daemon404> meant*
[16:25:02 CEST] <BtbN> Hm, this is strange. While debugging into libva-intel-driver, i end up in the avc sanity check code, not in the hevc one.
[16:26:19 CEST] <nevcairiel> .. and thats why its not working! :)
[16:26:24 CEST] <iive> BBB: i'm more afraid by the bikeshed factor ...
[16:26:26 CEST] <nevcairiel> did you verify that it actually works with gst
[16:27:11 CEST] <BtbN> nope
[16:27:14 CEST] <BtbN> nevcairiel, https://gist.github.com/BtbN/96e9dbf6d3d10e592c5d
[16:27:22 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_decoder_utils.…
[16:27:39 CEST] <BtbN> it even says the profile parameter is HEVC Main
[16:27:44 CEST] <BtbN> why does it enter that branch?!
[16:27:58 CEST] <nevcairiel> they share the same value? :)
[16:29:07 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/libva/tree/va/va.h?id=libva-1.6.0#n283
[16:29:08 CEST] <BtbN> nope
[16:29:55 CEST] <nevcairiel> souce not matching your binary?
[16:30:09 CEST] <BtbN> Very unlikely
[16:30:21 CEST] <BtbN> The backtrace alone is quite obvious
[16:30:33 CEST] <BtbN> intel_decoder_sanity_check_input called with profile=profile@entry=VAProfileHEVCMain
[16:30:39 CEST] <BtbN> branches into intel_decoder_check_avc_parameter
[16:31:54 CEST] <BtbN> __gb__, any idea what might be going on here?
[16:32:21 CEST] <nevcairiel> i find it odd that the first two lines in your backtrace dont have a address anymore
[16:33:01 CEST] <BtbN> propably caused because i reverse-stepped through it
[16:35:16 CEST] <BtbN> nope, a normal backtrace also shows no addresses
[16:35:31 CEST] <BtbN> i'd guess they got inlined or something?
[16:43:22 CEST] <nevcairiel> the one call before that is in another file, makes inline unlikely, but maybe you use lto =p
[16:52:56 CEST] <BtbN> Ok, tracing it again I actualy end up in the right function...
[16:53:35 CEST] <BtbN> And it actualy points to a usefull error.
[16:53:47 CEST] <BtbN> pic_width/height_in_luma_samples seems to be wrong.
[16:55:31 CEST] <nevcairiel> how can that be wrong
[16:55:48 CEST] <BtbN> Because "pp->pic_width_in_luma_samples = h->ps.sps->min_cb_width;" is wrong.
[16:56:05 CEST] <nevcairiel> yeah well that is the wrong value =)
[16:56:34 CEST] <BtbN> Now the question is, is ctb_width/height the right one, or do i have to calculate it myself
[16:58:01 CEST] <nevcairiel> if it actually wants luma samples, then give it avctx->coded_width
[16:58:23 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_decoder_utils.…
[16:58:28 CEST] <BtbN> that's the sanity check that fails
[16:59:47 CEST] <nevcairiel> or sps->width for that matter
[17:00:04 CEST] <BtbN> That already is in that unit?
[17:00:20 CEST] <nevcairiel> its in samples
[17:00:22 CEST] <nevcairiel> ie. pixels
[17:00:32 CEST] <nevcairiel> min_cb_width is just derived from that
[17:00:33 CEST] <nevcairiel> sps->min_cb_width = sps->width >> sps->log2_min_cb_size;
[17:01:40 CEST] <nevcairiel> sps->width seems appropriate for that variable name anyway
[17:11:08 CEST] <__gb__> BtbN, btw, I'd like to submit to ML & push by EOW if no strong objections the following: https://github.com/gbeauchesne/FFmpeg/tree/10.vaapi.lavc.fixes
[17:11:37 CEST] <__gb__> this should allow you to extend the internal va context with anything else you'd like without breaking the public api/abi
[17:12:29 CEST] <__gb__> BtbN, pic_width_in_luma_samples is the encoded width
[17:14:21 CEST] <__gb__> wrt. slice_data_byte_offset, my notes from recent discussions have the following: make sure to supply slice-data with the start code prefix in there
[17:14:47 CEST] <__gb__> though, the open source driver seems to work either way, for now
[17:14:54 CEST] <BtbN> btw., do you have any idea why VASliceParameterBufferBaseHEVC is a thing?
[17:15:04 CEST] <BtbN> it seems like a very strange and annoying api break
[17:15:46 CEST] <__gb__> where do you see VASliceParameterBufferBaseHEVC?
[17:16:04 CEST] <__gb__> *Base* data structures are meant for "short-mode" decoding
[17:16:54 CEST] <__gb__> which is not implemented in the open source driver
[17:16:56 CEST] <BtbN> So far VASliceParameterBufferBase was used by ffmpeg to initialize the slice param buffers, because those base params worked for all structures
[17:17:08 CEST] <BtbN> It only contains the first 3 values of all SliceParamBuffer structs
[17:17:13 CEST] <__gb__> that was used because michael didn't want it to return void * :)
[17:17:13 CEST] <BtbN> for all of them, except HEVC
[17:17:43 CEST] <__gb__> I'd say, just don't care about it, return the usual VASliceParameterBufferHEVC allocated buffer
[17:19:00 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/libva/tree/va/va.h#n1213 <-> http://cgit.freedesktop.org/vaapi/libva/tree/va/va_dec_hevc.h#n210
[17:19:34 CEST] <BtbN> It's the same structure, with the same 3 values. But slightly diffrent size for one, so it's incompatible and makes the common ffmpeg vaapi code for allocating the slice param buffer useless for hevc
[17:19:37 CEST] <__gb__> it is indeed very annoying that that member was shortened to fit an extra slice_data_byte_offset...
[17:20:36 CEST] <__gb__> iirc, you still have the option to post-fix the value in vaapi_hevc.c right?
[17:21:41 CEST] <BtbN> yes, i could do that. Not very pretty though. Currently i just duplicated the entire alloc function for hevc
[17:22:23 CEST] <__gb__> some people argued that on LSB platforms it was safe to still use the original Base struct and only change slice_data_byte_offset
[17:22:45 CEST] <__gb__> s/LSB/little-endian/
[17:26:38 CEST] <cone-075> ffmpeg 03Michael Niedermayer 07master:21566b21d57e: avfilter: add scale2ref filter
[17:29:20 CEST] <BtbN> __gb__, the changes look nice btw. I think i'll rebase ontop of them right away
[17:29:43 CEST] <__gb__> (my personal point would have been: if something is called Base/Common, there are strong reasons to believe that this would really be base/common, forever)
[17:34:11 CEST] <BtbN> Was this change done at a later point, to squeeze another field in there without changing the size?
[17:53:49 CEST] <BBB> nevcairiel: Im happy to ignore, but theyll do it anyway. Making it impossible to do it does make life easier
[18:12:05 CEST] <klaxa> AV_OPT_TYPE_BIANRY is giving me a lot of trouble
[18:12:07 CEST] <klaxa> https://gist.github.com/klaxa/fa446a0141167924bfee
[18:12:16 CEST] <klaxa> that's the code i have + output up until a segfault
[18:12:37 CEST] <klaxa> i'm allocating a sockaddr_storage struct in tcp.c, but when i try to get it with av_opt_get() i get a segfault
[18:13:08 CEST] <klaxa> av_opt_get() is trying to read the memory location but the memory address of *dst is invalid and i don't know why
[18:14:11 CEST] <klaxa> you can get the full repo here: http://git.klaxa.eu/?p=ffmpeg.git;a=shortlog;h=refs/heads/ffserver_http_api…
[18:15:31 CEST] <BBB> did you try valgrind or did you try debugging how much it allocates and how much it writes?
[18:16:49 CEST] <klaxa> no i didn't, when i fill the sockaddr_storage struct with getpeername() it gets populated properly, i later read the address and port with getnameinfo() so i assumed it got allocated correctly?
[18:17:04 CEST] <klaxa> the address and port are correct too
[18:17:08 CEST] <BBB> Im not talking about that memory
[18:17:11 CEST] <klaxa> ah
[18:17:16 CEST] <BBB> Im talking about the memory allocated by av_malloc in that function
[18:17:24 CEST] <BBB> the segfault is when it writes into that memory
[18:17:33 CEST] <BBB> that suggests it wasnt allocated properly, or too short, or sth
[18:18:49 CEST] <klaxa> the address itself is invalid, the for loop with snprintf() segfaults with i == 0
[18:18:59 CEST] <klaxa> but i don't understand why it is incorrect
[18:19:13 CEST] <klaxa> >==960== Address 0x100007fdad70002 is not stack'd, malloc'd or (recently) free'd
[18:19:19 CEST] <klaxa> that's the address of bin
[18:19:39 CEST] <klaxa> which should be the address of TCPContext->sock_addr?
[18:27:47 CEST] <BBB> what is len?
[18:28:07 CEST] <klaxa> 16
[18:28:27 CEST] <klaxa> which is the correct value (from sizeof(struct sockaddr_storage))
[18:28:59 CEST] <klaxa> it is set after getpeername() populated sock_addr
[18:29:18 CEST] <BBB> does * (deref) take precedence over +?
[18:30:32 CEST] <BBB> I guess it does (unlike ++)
[18:30:54 CEST] <BBB> valgrind complains about invalid write, right? not invalid read?
[18:32:00 CEST] <klaxa> yes
[18:33:27 CEST] <klaxa> here's a screenshot from my debugger: http://dedi.klaxa.eu/public/nemiver_av_opt_get_segfault.png
[18:33:58 CEST] <klaxa> maybe that helps
[18:37:09 CEST] <klaxa> ah wait
[18:37:43 CEST] <klaxa> valgrind does say invalid read
[18:39:32 CEST] <klaxa> https://gist.github.com/klaxa/13143d5f782eba28671e
[18:39:39 CEST] <klaxa> that's the valgrind log
[18:41:36 CEST] <wm4> what debugger is this?
[18:41:41 CEST] <klaxa> nemiver
[19:15:52 CEST] <wm4> BBB: if you're not on linux, and need help to beat the vdpau shit into working, I could help
[19:29:33 CEST] <BBB> wm4: that would be lovely, can you apply that patch, disable the three vdpau version checks, and get it to compile?
[19:30:10 CEST] <BBB> (extra-cflags=-DFF_API_BUFS_VDPAU=0 -DFF_API_CAP_VDPAU=0 -DFF_API_VDPAU=0)
[19:55:52 CEST] <wm4> BBB: I'm not sure which patches I have to apply and in which order, do you just have a git tree?
[19:56:19 CEST] <BBB> [PATCH 1/2] lavc: put remaining bits of vdpau-in-decoder under FF_API_CAP_VDPAU.
[19:56:51 CEST] <BBB> [PATCH 2/2] lavu: comment out wrong value check in get_version() after api bump.
[19:56:53 CEST] <BBB> these two
[19:59:34 CEST] <wm4> the first patch fails to apply
[19:59:42 CEST] <wm4> error: patch failed: libavcodec/vc1dec.c:672
[20:00:04 CEST] <wm4> that's why a git branch would be better
[20:04:59 CEST] <Compn> BBB : default bitrates can break in different containers with certain codecs. i forgot which one but at least mp2 gives error in some default command lines
[20:05:26 CEST] <Compn> i'm not saying to not remove whate ver, i'm just letting you know that ive run into such problems (and yes forgot to report it lol)
[20:05:58 CEST] <Compn> and why mp2 is default for some container i have no idea...
[20:06:32 CEST] <jamrial> wm4: i can apply it with "patch -p1". it warns about line offset and fuzz, but it applies
[20:06:54 CEST] <BBB> $ git push github HEAD:api
[20:06:55 CEST] <BBB> error: unable to push to unqualified destination: api
[20:06:56 CEST] <BBB> The destination refspec neither matches an existing ref on the remote nor
[20:06:57 CEST] <BBB> begins with refs/, and we are unable to guess a prefix based on the source ref.
[20:06:58 CEST] <BBB> error: failed to push some refs to 'git@github.com:rbultje/ffmpeg.git'
[20:06:59 CEST] <BBB> ?
[20:07:12 CEST] <BBB> I feel stupid, but uhm& wtf?
[20:07:18 CEST] <BBB> did I forget how github worked?
[20:07:28 CEST] <Compn> do you have api branch on github ?
[20:07:32 CEST] <BBB> no
[20:07:36 CEST] <BBB> Im trying to create it
[20:07:39 CEST] <Compn> you have to create it first then
[20:07:48 CEST] <Compn> (i dont know how)
[20:08:09 CEST] <ubitux> BBB: git push -u github api ?
[20:08:21 CEST] <ubitux> (you are in a local api branch, right?)
[20:08:33 CEST] <jamrial> use -n first to simulate the push
[20:09:04 CEST] <BBB> my local branch has no name
[20:09:14 CEST] <BBB> detached branch
[20:09:39 CEST] <nevcairiel> That might be a problem, those things don't work well
[20:10:08 CEST] <BBB> ubitux: ty
[20:10:10 CEST] <BBB> wm4: https://github.com/rbultje/ffmpeg/tree/api
[20:10:14 CEST] <wm4> BBB: thanks
[20:10:38 CEST] <BBB> current cflags: -DFF_API_BUFS_VDPAU=0 -DFF_API_SET_DIMENSIONS=0 -DFF_API_ASPECT_EXTENDED=0 -DFF_API_ERROR_RATE=1 -DFF_API_MB_TYPE=0 -DFF_API_MAX_BFRAMES=0 -DFF_API_INPUT_PRESERVED=0 -DFF_API_NORMALIZE_AQP=1 -DFF_API_GMC=1 -DFF_API_MV0=1 -DFF_API_CODEC_NAME=0 -DFF_API_AFD=0 -DFF_API_OLD_FILTER_OPTS=0 -DFF_API_OLD_FILTER_REGISTER=0 -DFF_API_LAVF_BITEXACT=1 -DFF_API_LAVF_CODEC_TB=0 -DFF_API_XVMC=0 -DFF_API_XVMC=0
[20:10:39 CEST] <BBB> -DFF_API_CAP_VDPAU=0 -DFF_API_DEBUG_MV=0 -DFF_API_EMU_EDGE=0 -DFF_API_UNUSED_MEMBERS=0 -DFF_API_OLD_AVOPTIONS=0 -DFF_API_VDPAU=0 -DFF_API_DLOG=0
[20:10:45 CEST] <BBB> so you see I still have a bunch to go :(
[20:11:18 CEST] <wm4> so I add --extra-cflags='-DFF_API_BUFS_VDPAU=0 -DFF_API_CAP_VDPAU=0 -DFF_API_VDPAU=0' to configure?
[20:12:02 CEST] <BBB> yeah
[20:12:26 CEST] <BBB> probably also -DFF_API_OLD_AVOPTIONS=0
[20:12:36 CEST] <BBB> since that one causes a fate change which is part of my tree
[20:15:10 CEST] <wm4> http://privatepaste.com/c30098c967
[20:15:34 CEST] <wm4> I can try to make it compile (slightly later)
[20:15:37 CEST] <BBB> right, so I tihnk each of these codecs with vdpau need to be under #if FF_API_VDPAU
[20:15:47 CEST] <BBB> theres a bunch in various places
[20:15:52 CEST] <BBB> (they are replaced by hwaccel)
[20:16:09 CEST] <BBB> FF_API_CAP_VDPAU is also fine, I mean, theyre the same thing essentially
[20:16:19 CEST] <nevcairiel> That shit will never be removed as long as Carl can stall the entire dev process though
[20:16:19 CEST] <j-b> a1m
[20:17:11 CEST] <BBB> nevcairiel: Ill just push the change that removes it
[20:17:15 CEST] <BBB> Im happy to fight over it with carl
[20:17:26 CEST] <Compn> i dont think the list of api in version.h is what you think it is.
[20:17:35 CEST] <Compn> should probably make a new list...
[20:17:49 CEST] <BBB> ?
[20:18:31 CEST] <Compn> nevermind
[21:20:51 CEST] <BBB> so Im onfused about fate
[21:21:07 CEST] <BBB> I have one particular test that gives non-consistent results after removing the +bitexact flag forward (fate-lavf-mov)
[21:21:17 CEST] <BBB> so 3 runs of lavf-mov gives 3 different diffs
[21:21:30 CEST] <BBB> however, V=1 gives me a command that, when run, gives the same result every time
[21:29:23 CEST] <BBB> aha its the rtp hinting
[21:29:25 CEST] <BBB> wth
[21:32:27 CEST] <wm4> so I got kind of sidetracked, but I'll look at the vdpau things now
[21:34:46 CEST] <BBB> wbs: how did libav fix it? I dont see anything obvious on the libav side on getting rtp hinting to be bitexact for the fate-lavf-mov test
[21:35:36 CEST] <wm4> BBB: oh I get it... the vdpau decoder should have been disabled at config time
[21:35:41 CEST] <wm4> I'm not sure how we do this
[21:35:57 CEST] <wm4> disable a configure entry on a deprecation
[21:37:43 CEST] <BBB> I dont think we have methods for that yet
[21:37:56 CEST] <BBB> can we just #if FF_API_VDPAU && CONFIG_&_DECODER?
[21:38:01 CEST] <BBB> its knidna weird but ..
[21:39:08 CEST] <wm4> no, because the gloarious allcodecs.c crap ruins it
[21:39:19 CEST] <wm4> glorious even (but that works too)
[21:39:34 CEST] <BBB> but you can #if the registrations?
[21:39:35 CEST] <BBB> right?
[21:39:48 CEST] <BBB> #if 0
[21:39:52 CEST] <BBB> REGISTER_ENCDEC(..)
[21:39:52 CEST] <BBB> #endif
[21:39:53 CEST] <BBB> etc.
[21:40:47 CEST] <wm4> no
[21:40:54 CEST] <wm4> because that file is parsed by configure
[21:41:11 CEST] <jamrial> it's being done for mpeg_xvmc
[21:41:19 CEST] <jamrial> it's inside a FF_API_XVMC guard
[21:41:26 CEST] <BBB> we can ignore the configure check
[21:41:45 CEST] <BBB> as long as any CONFIG_BLA_VDPAU_DECODER is within a FF_API_VDPAU
[21:42:00 CEST] <wm4> jamrial: right, I guess it disabled it at runtime, even if configure still can enable it
[21:42:21 CEST] <wm4> doing that then
[21:47:24 CEST] <wm4> "make: *** No rule to make target 'libavutil/reverse.c', needed by 'libavcodec/qdm2_tablegen.o'. Stop."
[21:47:45 CEST] <wm4> I still had --enable-hardcoded-tables for testing
[21:47:59 CEST] <wm4> but I'm going to do what everyone does, and ignore compilation failures with this option
[21:48:16 CEST] <wm4> at least I can choose to intentionally code-rot optional features I don't like
[21:48:19 CEST] <wm4> !!!111
[21:48:41 CEST] <BBB> muahahhaah
[21:48:45 CEST] <BBB> isnt that what everyone does?
[21:48:48 CEST] <BBB> ...
[21:48:49 CEST] Action: BBB runs
[21:50:04 CEST] <wm4> hm same error
[21:50:05 CEST] <wm4> confusing
[21:50:10 CEST] <jamrial> i insist the reverse stuff in lavc should be undone. including lavu/reverse.c from lavc headers and c files is ugly
[21:50:49 CEST] <wm4> what does this tablegen stuff help with anyway?
[21:51:53 CEST] <Daemon404> init time
[21:51:55 CEST] <Daemon404> in theory.
[21:52:00 CEST] <Daemon404> emphasis on theory
[21:52:26 CEST] <atomnuker> really really memory constrained embedded systems?
[21:54:02 CEST] <BBB> like, those that cant play video anyway? :)
[21:54:29 CEST] <Daemon404> tabglgen is also for audio ;)
[21:57:39 CEST] <BBB> hm...
[21:57:47 CEST] <BBB> I guess audio only is one use case yes
[21:58:17 CEST] <Daemon404> yeah but nobody uses sw aac.
[22:03:39 CEST] <iive> what do you mean by sw aac?
[22:11:37 CEST] <wm4> BBB: http://sprunge.us/GFaQ
[22:12:01 CEST] <wm4> man how much code the old vdpau decoders duplicate
[22:12:19 CEST] <wm4> and it was done only because of mplayer (though to be fair, it helped finding bugs in the new code)
[22:12:37 CEST] <BBB> \o/
[22:12:45 CEST] <BBB> do you want to send it to the ML?
[22:12:52 CEST] <BBB> Ill add it to my queue so I can push it at the same time
[22:13:03 CEST] <BBB> or actually Ill just take this and set --author=..
[22:13:36 CEST] <wm4> just take it and squash it or whatever you want
[22:13:58 CEST] <wm4> I couldn't test with mpv, because mpv would crash due to the ABI mismatch caused by defining the FF_... directly
[22:14:43 CEST] <BBB> oh &
[22:14:44 CEST] <BBB> hm ...
[22:14:46 CEST] <BBB> right
[22:14:55 CEST] <BBB> I had not thought about that
[22:15:00 CEST] <BBB> ohwell
[22:15:11 CEST] <wm4> hm actually let me just edit version.h
[22:16:06 CEST] <Daemon404> iive, as in many embedded devices do not use software aac decoding
[22:18:22 CEST] <iive> Daemon404: and i've seen it used in embedded device firmware for the "hw" decoder.
[22:19:00 CEST] <jamrial> people bothered to write aac/ac3/mp3 asm for mips/arm, so some certainly do use sw decoding
[22:19:25 CEST] <nevcairiel> and there is apparently still systems without floating point units
[22:21:08 CEST] <durandal_170> we really should move forward, ff in ffmpeg have it
[22:36:27 CEST] <BBB> wm4: btw thanks for helping, it does sort of feel like everyone is bikeshedding over nothingnesses all over the place, good to get at least some positive feedback
[22:52:34 CEST] <BBB> does anyone want to look into the mov rtp hinting bitexact flag transfer issue?
[22:52:45 CEST] Action: BBB desperately looks for volunteers
[22:53:28 CEST] <wm4> I just bumped all libs majors, and now libavfilter has problems
[22:53:57 CEST] <wm4> tries to use AVFilterBufferRef and FF_QSCALE_...
[22:56:27 CEST] <BBB> I havent fixed FF_QSCALE yet
[22:56:32 CEST] <BBB> that one is really hard :(
[22:56:39 CEST] <BBB> AVFilterBufferRed, Andreas posted a patch for that
[22:56:45 CEST] <BBB> it might not have been applied to my tree yet
[22:57:02 CEST] <wm4> what's the deal with FF_QSCALE? is it just dead code?
[22:58:03 CEST] <BBB> & no & I mean
[22:58:08 CEST] <BBB> it depends how you define dead
[22:58:24 CEST] <BBB> it feeds into lavfilter -> postprocess filters
[22:58:31 CEST] <BBB> which use q to set filter strength
[22:58:44 CEST] <BBB> and then use a codec-specific scale modifier (since scales mean different things between codecs)
[22:59:17 CEST] <BBB> its utterly broken if you ask me, conceptually, since any new codec needs to add new api to postprocess to get anything to work, rather than scaling to a common unit
[22:59:40 CEST] <BBB> but what do I know, I dont design code, I just fix crap other people leave behind before they fall off the earth :(
[23:00:09 CEST] <wm4> blame people like cehoyos (KEEP ALL THE FEATURES)
[23:00:12 CEST] <BBB> libav doesnt have this issue because they deleted libpp
[23:00:58 CEST] <wm4> anyway, I guess this means we undeprecate FF_QSCALE, since nobody will fix it, but there are certain people refusing to delete it too
[23:01:29 CEST] <ubitux> why was ff_dlog in libavcodec&
[23:01:46 CEST] <ubitux> it obviously belongs in lavu
[23:01:47 CEST] <j-b> oh boy, a 7MB SSA file with moving subtitles, in a wave-pattern
[23:02:04 CEST] <ubitux> j-b: need
[23:02:22 CEST] <ubitux> j-b: probably just an usual lua-template generated
[23:02:23 CEST] <j-b> for 1:20 video
[23:02:44 CEST] <ubitux> does it include the generating code?
[23:03:00 CEST] <wm4> j-b: that's nothing
[23:03:07 CEST] <BBB> wm4: Im currently thinking to postpone deprecation& I dont know if itll ever go anywhere, indeed
[23:03:09 CEST] <wm4> j-b: I've seen 70MB files for the same length, and larger
[23:03:26 CEST] <BBB> wm4: but I consider it hugely unsatisfactory design, so undeprecation seems like me saying its ok , which it isn't
[23:03:27 CEST] <j-b> https://trac.videolan.org/vlc/ticket/15257#comment:1
[23:03:29 CEST] <wm4> BBB: from my point of view, it looks like QSCALE goes nowhere
[23:03:34 CEST] <j-b> wm4: sorry, master.
[23:04:10 CEST] <wm4> j-b: in libass there are actually people trying to fix such issues
[23:04:12 CEST] <wm4> kind of
[23:04:13 CEST] <jamrial> qscale_type element from AVFrame (used by av_frame_{get,set}_qp_table which is called by these pp filters) is deprecated with FF_API_AVFRAME_LAVC
[23:04:25 CEST] <jamrial> but the av_frame_{get,set}_qp_table functions are not
[23:04:35 CEST] <ubitux> doesn't include the code :(
[23:04:40 CEST] <ubitux> too bad
[23:07:25 CEST] <ubitux> j-b: actually sounds like classic karaoke
[23:07:52 CEST] <ubitux> not really evolved
[23:07:55 CEST] Action: ubitux disappointed
[23:08:14 CEST] <wm4> I don't want to know what "evolved" is
[23:08:38 CEST] <ubitux> well i mean, it's just vibrating kara with a small blur
[23:09:40 CEST] <ubitux> when you see shit like this https://www.youtube.com/watch?v=HWn4pxNu67I
[23:09:46 CEST] <ubitux> it's way more interesting :)
[23:12:37 CEST] <ubitux> https://www.youtube.com/watch?v=MDQTUwFcb2c or this e ~
[23:13:11 CEST] <ubitux> the result is really silly, but i admire so much the performance
[23:13:29 CEST] <ubitux> i think it's pretty sick to be able to do stuff like this
[23:13:51 CEST] <wm4> you could even do much more if it didn't use an inefficient old format designed for subtitles
[23:13:54 CEST] <j-b> h god
[23:14:06 CEST] <BBB> jamrial: so deprecate the functions
[23:14:16 CEST] <BBB> jamrial: and make it side-data
[23:14:22 CEST] <BBB> jamrial: or whatever you think is right
[23:14:23 CEST] <BBB> anyway
[23:14:43 CEST] <BBB> I have 4 issues to go and then Ill call it a day, Ive posted more than enough bikesheddy patches
[23:14:55 CEST] <BBB> and here I thought I would do something useful today :(
[23:15:30 CEST] <ubitux> j-b: you don't watch enough animes
[23:15:45 CEST] <ubitux> j-b: why do you think ffmpeg uses ass as internal format for decoded subtitles
[23:15:48 CEST] <ubitux> ass to rule them all
[23:16:10 CEST] <wm4> that's not a good match either
[23:16:12 CEST] <jamrial> BBB: how are they bikesheddy?
[23:16:26 CEST] <BBB> not a single one has been approved
[23:16:34 CEST] <wm4> ass is merely the most powerful format which ffmpeg supports most completely
[23:16:39 CEST] <ubitux> libass is pretty much the only usable subtitles engine supersetting almost any sub format
[23:16:50 CEST] <BBB> and half of them generate responses like but but but -ab is used in user scripts"
[23:18:06 CEST] <wm4> I wonder if I should start LGTM spam in reply to your patches
[23:18:16 CEST] <wm4> (moral support??)
[23:20:19 CEST] <ubitux> j-b: https://www.youtube.com/watch?v=C0wT7r9da9c if you hadn't enough
[23:20:29 CEST] <ubitux> anyway, afk
[23:21:23 CEST] <BBB> moral support is nice
[23:21:26 CEST] <BBB> lgtm spam is also nice
[23:21:32 CEST] <jamrial> BBB: "fate: move -flags +mv0 -> -mpv_flags +mv0." is pretty straighforward so it should be ok to commit
[23:22:41 CEST] <kierank> ubitux: omg
[23:22:46 CEST] <jamrial> same with the dbl -> i64 libvpx one
[23:24:22 CEST] <BBB> those are subtitles?
[23:24:24 CEST] <BBB> wth
[23:24:32 CEST] <BBB> :D
[23:27:48 CEST] <wm4> now my mail client is acting up, what a POS
[23:29:00 CEST] <BBB> how dare you approve patches that mplayer overlords would frown on!
[23:29:12 CEST] <BBB> (thats your mail client talking right there)
[23:54:49 CEST] <rcombs> ubitux: one ass to rule them all
[23:54:52 CEST] <rcombs> one ass to bind them
[23:54:58 CEST] <rcombs> erm, find them
[23:55:14 CEST] <rcombs> y'know I'm not as into LOTR as I should be
[00:00:00 CEST] --- Tue Aug 18 2015
1
0
[00:00:55 CEST] <JEEB> that is because there's an avformatcontext set with the required stuff
[00:01:03 CEST] <JEEB> and then that packet can be written
[00:01:42 CEST] <jim444> I see.
[00:02:29 CEST] <jim444> Thaks. Is it enough to set pts and dts for AVFrame or I have to do it for AVPacket as well?
[00:05:00 CEST] <JEEB> don't remember, I think it's most important to set the timestamps correctly when encoding
[00:05:12 CEST] <JEEB> it should then have timestamp information according to that in the packet
[00:05:29 CEST] <JEEB> anyways, skimmed through the muxing example, it seems pretty good
[00:05:34 CEST] <JEEB> you should get up to speed with it
[00:05:53 CEST] <jim444> Thanks JEEB.
[00:06:03 CEST] <jim444> I will try to go through it :)
[00:11:11 CEST] <TikityTik> JEEB: How can I lower the size of the video stream when it's just a still image?
[00:11:20 CEST] <TikityTik> ffmpeg -loop 1 -i in.jpg -i in.mp3 -c:v libvpx -r 1 -crf 5 -filter_complex format=yuv420p -force_key_frames expr:gte(t,n_forced*10) -s 400:400 -c:a libvorbis -ac 2 -q:a 1 -metadata title="Floating Cloud - Flower
[00:11:20 CEST] <TikityTik> Village 4/4" -threads 4 -shortest out.webm
[00:12:22 CEST] <chungy> -s needs to be in the form of 400x400
[00:13:13 CEST] <TikityTik> this 39 kB picture is making a videostream the size of 1603 kB
[00:13:38 CEST] <JEEB> that is because you are recoding it with libvpx with the settings you have set
[00:14:06 CEST] <TikityTik> what settings should i change to make it high quality but low size?
[00:14:15 CEST] <TikityTik> I assumed it would be somewhat automatic with crf
[00:14:24 CEST] <JEEB> uhh
[00:14:39 CEST] <JEEB> it's onyl automatic in the way that you find the highest crf value that still looks good
[00:14:51 CEST] <JEEB> also you are seemingly forcing keyframes every ten frames
[00:15:09 CEST] <JEEB> or I have no idea what n_forced is
[00:15:24 CEST] <JEEB> also you do have an audio stream there
[00:15:24 CEST] <TikityTik> yeah, for better seeking
[00:15:37 CEST] <TikityTik> the audio stream is ok, but the video stream size is too large
[00:15:41 CEST] <JEEB> well you are basically forcing the encoder to COMPLETELY code the picture again
[00:15:47 CEST] <JEEB> every ten frames
[00:16:10 CEST] <JEEB> you a) play with the CRF value or b) lengthen the GOP length
[00:16:23 CEST] <TikityTik> JEEB: and avoid using -b:v ?
[00:17:05 CEST] <TikityTik> yeah the forced key frames really messed with it
[00:17:13 CEST] <JEEB> they are two separate rate control modes (albeit libvpx has some brainfuck related to VBV+CRF)
[00:17:25 CEST] <TikityTik> am i able to have it seek better but not create the same issue?
[00:17:48 CEST] <JEEB> if the players you are aiming for suck dongs, then you can guess
[00:17:59 CEST] <JEEB> or if you otherwise have strict requirements
[00:18:22 CEST] <JEEB> if you require the encoder to code a full picture completely every ten frames, that will be done
[00:18:32 CEST] <JEEB> I noted you the two ways how to improve your situation
[00:18:46 CEST] <JEEB> pick one or two of them and see how far you get
[00:22:45 CEST] <TikityTik> yeah the size is good, just wished the seeking wasn't so bad lol
[00:24:49 CEST] <Agrajag-> g'day, i have a webcam that i can get an rtsp stream from, i would like to downscale it and output to a new rtsp stream, can ffmpeg do this?
[00:29:16 CEST] <TikityTik> I personally like VBV+CRF
[00:29:55 CEST] <JEEB> (that means maxrate+bufsize and crf, btw :P)
[00:29:57 CEST] <JEEB> and yes, it's good
[00:30:06 CEST] <JEEB> just that with libvpx there's some batshit insane shit there
[00:30:32 CEST] <JEEB> like, requiring a video bit rate also to be set although it is just pants-on-head retarded
[00:30:37 CEST] <JEEB> you have a maxrate and a bufsize
[00:30:47 CEST] <JEEB> and you have your primary way of rate control
[00:31:30 CEST] <JEEB> for whatever unfathomable reason the libvpx encoder wrapper (and possibly libvpx itself?) also requires a bit rate to be set in addition
[00:32:02 CEST] <TikityTik> Agrajag-: you probably can do so
[00:32:24 CEST] <TikityTik> But i might be confusing that with vlc, i'm not sure.
[00:34:30 CEST] <TikityTik> Agrajag-: https://trac.ffmpeg.org/wiki/StreamingGuide
[00:35:16 CEST] <TikityTik> and try to use -i "<your stream>" for the input
[00:49:58 CEST] <Guiri> Can someone explain how `trunc(ow/a/2)*2` works? I use it to avoid ffmpeg quitting when scaling weird resolutions with `-1`
[00:51:22 CEST] <pzich> it appears to be dividing the output width by the aspec ratio, dividing it by 2, flooring (truncating) it, then multiplying by two to assure it's a multiple of two
[00:52:20 CEST] <Guiri> Ah ow = output width. So, fi wanted to scale something to 480p, "scale=trunc(oh/a/2)*2:480"?
[00:52:46 CEST] <pzich> I think you'd need to multiply the aspect ratio instead
[00:53:56 CEST] <TikityTik> how can I do -pass 1 and -pass 2 right after another in Windows? Does ffmpeg have a function to do that for me?
[00:54:01 CEST] <TikityTik> Cannot use a bashscript.
[00:54:29 CEST] <Guiri> Ah, thanks pzich. I get it now
[00:54:36 CEST] <pzich> TikityTik: not 100% sure about DOS, but can't you put two commands after each other with a semicolon
[00:54:52 CEST] <TikityTik> It's even a pain to copy paste in DOS
[00:55:08 CEST] <TikityTik> it's block highlighting and not inline highlighting
[00:55:33 CEST] <ScottSteiner> I'm trying to make a recording of my desktop but when doing "ffmpeg -f x11grab -i :1 -t 1 test.webm" all I get is a black box. I'm trying to do it over vnc so I'm not sure if that is the correct display. How can I tell? thanks
[00:55:40 CEST] <cbsrobot> Guiri: use -2
[00:55:59 CEST] <pzich> it looks like you cant use & in DOS
[00:56:07 CEST] <pzich> err, -t, you *can* use
[00:56:13 CEST] <pzich> terrible typo
[00:56:18 CEST] <Guiri> cbsrobot: Can you explain a bit more? I was using 640:-1, but discovered it would break with odd integer resolutions
[00:56:32 CEST] <cbsrobot> Guiri: so try 640:-2
[00:56:58 CEST] <TikityTik> Is it bad to use 2-pass on low bitrates like 252 kbps?
[00:57:04 CEST] <TikityTik> when should i avoid 2-pass?
[00:57:23 CEST] <pzich> depends on the codec, I've been told it's basically never worth it for x264
[00:57:27 CEST] <TikityTik> I assume it only does good, althrough with larger filesize
[00:57:33 CEST] <TikityTik> for libvpx?
[00:58:08 CEST] <pzich> generally go 2-pass when you are aiming for best quality and looking for a target file size, but I'm not an expert
[00:59:03 CEST] <pzich> I haven't done much with vpx but it looks like most people 2-pass
[01:06:12 CEST] <JEEB> yes, if you want a *specific* file size, then 2pass average bit rate
[01:09:00 CEST] <Guiri> Cool, that works, cbsrobot. Thx
[01:10:00 CEST] <cbsrobot> Guiri: if you wonder, rtfm on https://ffmpeg.org/ffmpeg-filters.html#Options-1 the sentence starting with "If one of the values is -n with n > 1,"
[01:10:32 CEST] <tab1293> anyone know where I can find a simple sample of how to implement a video player with libavcodec? the dranger tutorials segfault and ffplay is a little to complex for learning
[02:37:43 CEST] <korain> say i want to recusively convert and clone a director tree from flac to opus what would be the best way to do that?
[03:09:50 CEST] <ted-E> using a provided binary, trying to make a video out of a string of jpgs
[03:09:52 CEST] <ted-E> http://pastebin.com/Lj5dTscQ
[03:10:15 CEST] <ted-E> it keeps wanting to overwrite the next image in the sequence, but I don't know why when there is an outfile
[03:13:39 CEST] <ted-E> i've simplified it to just the IMG*.JPG and the out file with the same issue
[03:15:16 CEST] <ScottSteiner> While trying to record the screen from within a vnc connection, I keep getting a black screen. What could be causing this?
[06:10:00 CEST] <Mister_D> cant figure out amerge problem. Trying to add music track to a video file and it works while processing without video - both audio tracks are in. While encoding with video get constant warnings Error while decoding stream #0:1: Cannot allocate memory while playing it back the audio stutters after 10 sec and then stops completely at 12 sec mark. Using Big buck bunny video with creative common MP3 file.
[06:10:00 CEST] <Mister_D> http://pastebin.ca/3110018
[06:14:05 CEST] <oreWizard> can someone helpme?
[06:14:09 CEST] <oreWizard> i am getting this error
[06:14:09 CEST] <oreWizard> cl is unable to create an executable file.
[06:14:09 CEST] <oreWizard> C compiler test failed.
[06:14:24 CEST] <oreWizard> i am tryign to compile for windows phone
[06:16:58 CEST] <Mister_D> same command without video processign executes fine. http://pastebin.ca/3110027
[06:25:34 CEST] <buu> Hey, where should I start reading to learn how to modify the output of ffmpeg to add things like text/graphics/etc on top of a video?
[06:27:18 CEST] <c_14> buu: https://ffmpeg.org/ffmpeg-filters.html especially drawtext and overlay
[06:27:44 CEST] <buu> thanks
[06:28:41 CEST] <c_14> Mister_D: have you tried without the scale?
[06:31:25 CEST] <c_14> Mister_D: that message is only thrown on malloc failures though
[06:31:50 CEST] <Mister_D> without scale, when using -map 0:v:0 -c:v copy it works.
[06:32:38 CEST] <c_14> ie: your OS is refusing to allocate memory
[06:33:44 CEST] <c_14> Do you have plenty of free RAM?
[06:35:45 CEST] <Mister_D> yes, its Amazon EC2 t2.micro with a Gig of RAM
[06:36:13 CEST] <c_14> And how much of that is free when ffmpeg is running the command?
[06:36:19 CEST] <c_14> (you can check with free -m)
[06:36:19 CEST] <Mister_D> 750
[06:36:31 CEST] <Mister_D> 742236 avail Mem
[06:37:46 CEST] <c_14> While ffmpeg is executing the command?
[06:38:03 CEST] <Mister_D> before it runs.
[06:38:29 CEST] <c_14> And while it runs?
[06:38:48 CEST] <c_14> I wouldn't be all that surprised if ffmpeg needs more than that.
[06:38:59 CEST] <fling> Is not it still possible to skip parts of videos not containing any movement?
[06:39:07 CEST] <fling> I have a bunch of footage from a security camera.
[06:39:19 CEST] <fling> I want to only keep parts containing motion on the video.
[06:40:49 CEST] <Mister_D> c_14: will check memory usage while it runs
[06:42:06 CEST] <c_14> fling: I don't think ffmpeg has a filter that detects motion
[06:42:49 CEST] <fling> c_14: Is there something external I could try?
[06:46:19 CEST] <Mister_D> c_14: its not RAM, its stays at ~705MB whil executing the command
[06:48:18 CEST] <c_14> fling: none I know of
[06:49:15 CEST] <fling> c_14: stupid solution would be splitting the video into frames and remove frames non containing any move with my script or imagemagick and then combining frames back into the video.
[06:49:34 CEST] <fling> c_14: but I will loose sound this way.
[06:49:56 CEST] Action: fling will probably use this method for silent videos btw.
[06:52:28 CEST] <c_14> Mister_D: Well, your libc is failing to allocate memory for some reason.
[06:53:03 CEST] <Mister_D> c_14: building 2.6.4 just to test&
[06:53:46 CEST] <fling> c_14: is 2.7.2 good to use btw?
[06:54:05 CEST] <c_14> fling: You could always write a filter for ffmpeg that does motion detection and then drops audio/video frames without motion. It'll be a lot of work though. Other than that I can only refer you to google for other solutions.
[06:54:23 CEST] <c_14> fling: It's fine, we prefer you use git builds when possible because they contain bugfixes not in the release versions.
[06:54:27 CEST] <c_14> *not yet
[06:54:45 CEST] Action: fling will update from git prior the next ffmpeg workload.
[08:44:54 CEST] <Taniey> I import fonts from windows to centos 6.5,and use ttmkfdir to reload the windows fonts, so I can use the windows fonts. but the filter 'drawtext' to draw some Korean or some other characters of not in ansii table can`t correctly draw or auto select correct fonts to draw the video ,how can I resolve this question?
[08:45:15 CEST] <Taniey> the ffmpeg commend like this:
[08:46:02 CEST] <Taniey> ffmpeg -y -i input.mkv -filter_complex "drawtext=textfile=\'drawtext.txt\':font=\'arial\':fontsize=48:fontcolor=00ffff:x=50:y=200" -sn -codec:v h264 -codec:a aac -strict -2 out.mkv
[08:47:15 CEST] <Taniey> the content of drawtext.txt contain : Korean , Arabic, English etc.
[08:57:12 CEST] <kode54> Taniey: is it a UTF-8 encoded text file?
[08:58:11 CEST] <Taniey> yes
[09:16:31 CEST] <Taniey> how can I use filter drawtext's font paramater get bold fonts?
[09:23:05 CEST] <durandal_1707> read docs
[09:35:29 CEST] <Taniey> I can't find dos about how bold fonts from ffmpeg docment?
[12:37:41 CEST] <Ecco> Hi everyone!
[12:38:13 CEST] <Ecco> I have a series of JPEG image that would make sense as a movie (it's a timelapse)
[12:38:30 CEST] <Ecco> I'd like to "pack" them in a single file, for *archiving*
[12:38:37 CEST] <Ecco> (I could zip them up, but it's tedious to read)
[12:39:01 CEST] <Ecco> Is it possible to pack them as a movie file *without* degrading the movie quality using ffmpeg?
[12:40:14 CEST] <JEEB> you could use mov or matroska and just copy the JPEGs as a "MJPEG" stream
[12:40:27 CEST] <JEEB> I wonder if that would just work with -c copy
[12:40:41 CEST] <Ecco> Nice
[12:40:47 CEST] <Ecco> ok, mov would be perfect
[12:40:51 CEST] <Ecco> Lemme give this a try
[12:44:36 CEST] <JEEB> because in theory MJPEG is just video where every picture is a separate JPEG :)
[12:45:16 CEST] <JEEB> yeah, it seems like people have done it at least with matroska, and I wouldn't be surprised about MOV either
[12:49:13 CEST] <Ecco> Sweet
[12:49:19 CEST] <Ecco> (I'm still fighting with the CLI syntax)
[12:52:04 CEST] <Ecco> Will it keep all the EXIF meta?
[12:52:53 CEST] <Ecco> I guess I'll try to unpack and see if the files are exactly the same
[12:53:48 CEST] <Ecco> Yay, it seems to be working
[12:54:40 CEST] <Ecco> Excellent
[12:54:42 CEST] <Ecco> same MD5
[12:54:44 CEST] <Ecco> perfect
[12:54:47 CEST] <Ecco> thanks a lot JEEB !
[12:54:50 CEST] <JEEB> np :)
[14:03:48 CEST] <oreWizard> pkg-config not found, library detection may fail.
[14:03:54 CEST] <oreWizard> someone can help me with this?
[14:08:26 CEST] <uvx3> I think you need the pkg-config to be installed.
[14:11:36 CEST] <oreWizard> ok
[14:11:48 CEST] <oreWizard> i need to write some paths on itw
[14:18:24 CEST] <oreWizard> ?
[14:51:22 CEST] <oreWizard> someone knows how to create pkg-config for compiling?
[14:56:18 CEST] <iive> oreWizard: most programs include files that pkg-config can parse and return stuff used for compilation
[15:07:34 CEST] <oreWizard> iive thkx
[16:19:22 CEST] <livingBEEF> Any idea if -start_at_zero is the opposite of -copyts? The description in documentation is very confusing...
[16:30:02 CEST] <livingBEEF> well, I'll probably just encode the audio separately, copyts seems to mess it up all the time
[16:38:25 CEST] <oreWizard> why i cant find swresample.h
[16:38:33 CEST] <oreWizard> ?
[16:39:20 CEST] <CalimeroTeknik> /usr/include/libswresample/swresample.h
[16:39:56 CEST] <CalimeroTeknik> I'm trying to burn subs into a video and pad it at the same time, but only the last -vf argument works!
[16:42:19 CEST] <oreWizard> Error C1083 Cannot open include file: 'libswresample/swresample.h': No such file or directory (
[16:42:22 CEST] <oreWizard> idk
[16:52:02 CEST] <c_14> CalimeroTeknik: either combine the two filterchains into one filterchain, or use -filter_complex and a filtergraph
[16:52:21 CEST] <c_14> Having more than one -vf isn't supported
[16:52:29 CEST] <c_14> oreWizard: does the file exist?
[17:01:32 CEST] <CalimeroTeknik> c_14, it appears that a comma did the trick!
[18:35:57 CEST] <kyleogrg> is there a way to automatically find the IVTC pulldown pattern for a video?
[18:42:16 CEST] <kyleogrg> i've recorded an HD show off TV onto a 29.97i DV AVI. now I want to detelecine, but i can't find the exact pattern
[18:43:30 CEST] <durandal_170> use fieldmatch or pullup
[18:44:57 CEST] <kyleogrg> if i recorded it off tv, does that suggest that it doesn't have a consistent pattern throughout the recording?
[18:49:16 CEST] <durandal_170> maybe, maybe not
[18:50:24 CEST] <JEEB> with ads most probably not
[18:50:55 CEST] <JEEB> in most cases you should be able to do it with fieldmatch (?) methinks, since that should look up the most probable matches
[18:51:06 CEST] <JEEB> it does always require some eye-checking
[18:54:18 CEST] <kyleogrg> JEEB: okay. so i'll try fieldmatch + yadif + decimate. so i want yadif to "Output one frame for each frame" right?
[18:55:47 CEST] <JEEB> yeah
[18:58:01 CEST] <kyleogrg> ok, thanks
[18:58:24 CEST] <kyleogrg> i guess i could do yadif + mcdeint with this?
[19:35:54 CEST] <kyleogrg> does AAC have a lossless mode?
[19:39:35 CEST] <JEEB> kyleogrg: no
[19:40:20 CEST] <kyleogrg> JEEB: well, i'm experimenting with lossless x264 in an MP4 container, and I also want to try a (compatible) lossless audio codec.
[19:40:49 CEST] <JEEB> almost none uses the MPEG-4 lossless audio thing
[19:40:53 CEST] <JEEB> *no-one
[19:40:58 CEST] <JEEB> but I think ffmpeg has support for it
[19:41:11 CEST] <c_14> You mean alac?
[19:41:20 CEST] <JEEB> no
[19:41:23 CEST] <JEEB> that's apple's thing
[19:41:49 CEST] <JEEB> ALS
[19:41:53 CEST] <JEEB> https://en.wikipedia.org/wiki/Audio_Lossless_Coding
[19:42:26 CEST] <kyleogrg> JEEB: but lossless quality shouldn't be any less compatible than lossy, right?
[19:42:35 CEST] <kyleogrg> why would crf 0 be less compatible than crf 18?
[19:42:56 CEST] <JEEB> because it uses a different profile and a different, lossless DCT?
[19:43:32 CEST] <JEEB> (among other things, read the specification for the gritty details on the lossless profile)
[19:43:39 CEST] <kyleogrg> hmm okay
[19:44:03 CEST] <JEEB> nvidia seems to have implemented it recently for AVC encoding, possibly decoding too... not sure though
[19:44:44 CEST] <JEEB> but in general lossless kills any sort of end-user hardware decoding, as well as all of the software decoders that are payware except for coreavc (which is by now dead as wood)
[19:45:17 CEST] <JEEB> also man, now that I look at it MPEG-4 Part 3 contains a whole truckload of audio formats
[19:45:36 CEST] <JEEB> everything from CELP to AAC/TwinVQ to TTSI to ALS/SLS
[19:46:04 CEST] <JEEB> https://en.wikipedia.org/wiki/MPEG-4_Part_3#Subparts
[19:46:19 CEST] <JEEB> ALS is the one supported by ffmpeg that is lossless
[19:59:38 CEST] <Oleg_> guys, when I type this command: ffmpeg -f v4l2 -framerate 25 -video_size 640x480 -i /dev/video0 output.mkv
[19:59:46 CEST] <Oleg_> it only records video
[19:59:54 CEST] <c_14> yep
[19:59:56 CEST] <c_14> that's intended
[20:00:05 CEST] <Oleg_> but how can I record audio with webcam's microphone, assuming it's /dev/dsp3?
[20:00:25 CEST] <c_14> alsa?
[20:00:27 CEST] <c_14> pulse?
[20:00:37 CEST] <Oleg_> alsa
[20:00:43 CEST] <Oleg_> what about oss?
[20:00:57 CEST] <Oleg_> can I record it with oss?
[20:01:17 CEST] <c_14> https://www.ffmpeg.org/ffmpeg-devices.html#oss
[20:06:33 CEST] <Oleg_> c_14, well, it looks like it tries to record audio with libvorbis, and it causes video/audio desynchronisation
[20:08:39 CEST] <Oleg_> I typed this:
[20:08:42 CEST] <Oleg_> ffmpeg -f v4l2 -framerate 25 -video_size 640x480 -i /dev/video0 -f oss -i /dev/dsp3 output.mkv
[20:17:19 CEST] <Oleg_> c_14, I wanna record audio with pcm_s16le, instead of vorbis
[20:17:27 CEST] <c_14> -c:a pcm_s16le
[20:17:37 CEST] <c_14> Not sure why it is desync though
[20:29:20 CEST] <Oleg_> c_14, okay, pcm_s16le also causes desynchronization, but what if I try recording with mp3lame?
[20:29:34 CEST] <Oleg_> c_14, can you please tell me how to record sound with mp3lame?
[20:30:36 CEST] <c_14> -c:a libmp3lame
[20:37:35 CEST] <Oleg_> c_14, if I record just audio, then I have no problems
[20:56:23 CEST] <Oleg_> c_14, how can I transcode audio to a lower bitrate?
[20:56:34 CEST] <c_14> -b:a your-bitrate-here
[21:08:28 CEST] <Oleg_> c_14, do you see anything odd in this output: http://pastebin.com/FqXM0Y0h ?
[21:09:14 CEST] <c_14> A lot of warnings
[21:09:19 CEST] <c_14> Nothing obvious though
[21:09:39 CEST] <LanDi> hey guys, I have a 1080 mkv video... my problem is: its file size is 10GB, I want to make it smaller... can someone help me or send me a link where I can lear how to do tha?
[21:09:55 CEST] <LanDi> learn*
[21:10:09 CEST] <c_14> https://trac.ffmpeg.org/wiki/Encode/H.264
[21:12:54 CEST] <LanDi> c_14, thanks
[22:17:07 CEST] <Fyr> guys, is it possible to make ffmpeg embed cover art automatically? all my files contain cover art, but ffmpeg when converts it, doesn't extract the art from input file and embed to the output.
[22:29:15 CEST] <uvx3> Have you tried using '-map 0:0 -map 0:1' or so?
[22:30:11 CEST] <bbert> Anyone know about ffmpeg's handling of mxf containers? Do you have access to either the System Item or the Data Item of Content Packages?
[22:30:39 CEST] <bbert> assuming you're using libav* from your own code
[22:41:33 CEST] <jim44> Hi Guys. How can I set h264 preset with ffmpeg api?
[22:41:49 CEST] <jim44> I am storing video in real time and I would like it to be as fast as possible.
[22:43:21 CEST] <JEEB> you set an avoption for the libx264 encoder in which you set the preset
[22:43:22 CEST] <jim44> I have tried using av_dict_set(&m_dictionary, "preset","veryslow",0); and av_opt_set(mCodecContext->priv_data, "preset", "ultrafast", 0);
[22:43:24 CEST] <uvx3> '-preset ultrafast'
[22:43:29 CEST] <jim44> but the encoding time does not change
[22:43:33 CEST] <uvx3> Read more here: https://trac.ffmpeg.org/wiki/Encode/H.264
[22:43:39 CEST] <JEEB> uvx3: he was talking about the API
[22:43:44 CEST] <JEEB> not command line
[22:43:54 CEST] <uvx3> Oh, sorry :)
[22:43:57 CEST] <JEEB> :)
[22:44:02 CEST] <jim44> no problem :)
[22:44:27 CEST] <jim44> so any ideas? :)
[22:45:27 CEST] <jim44> Here is a part of the code
[22:45:28 CEST] <jim44> http://pastebin.com/1UMpDp55
[22:47:38 CEST] <jim44> and I am using libavcodec
[22:48:45 CEST] <JEEB> while I would probably prefer setting x264opts or so, I can see that there's a thing called preset in libx264.c's avoptions
[22:51:22 CEST] <JEEB> or I guess it's this https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L878
[22:53:08 CEST] <jim44> Thanks JEEB. I will check it out.
[22:54:42 CEST] <JEEB> yeah, it seems like I haven't set avoptions myself
[22:54:43 CEST] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbn…
[22:54:57 CEST] <JEEB> I've only opened a decoder with an avdict
[22:56:16 CEST] <jim44> I have tried both av_opt_set and av_dict_set but there is no change in encoding time.
[22:59:01 CEST] <JEEB> are you sure you're getting the right encoder set? libx264 outputs the used parameters to standard error output, check if those change. could it be that you have a bottleneck somewhere else or that the thing you're running this thing on is just slow as molasses
[23:01:31 CEST] <jim44> Good point. How can I output the used parameters? sorry, I am quite new at ffmpeg api
[23:05:26 CEST] <JEEB> it should output to stderr always
[23:05:34 CEST] <JEEB> unless you are making lavc be completely silent
[23:09:15 CEST] <jim44> Thanks. Let me try.
[23:58:18 CEST] <Tom012> Hello everybody. Is there an option to tell ffmpeg to ignore vob files?
[00:00:00 CEST] --- Tue Aug 18 2015
1
0
[00:11:12 CEST] <michaelni> ubitux, deleted SAMI_ass_capability_tester.smi
[00:12:03 CEST] <ubitux> michaelni: thx! :)
[00:14:34 CEST] <michaelni> np
[00:39:20 CEST] <BtbN> Someone happens to know how to calculate http://cgit.freedesktop.org/vaapi/libva/tree/va/va_dec_hevc.h#n268 this field from the ffmpeg HEVCContext? I can't see any obvious indication for it there.
[00:39:32 CEST] <BtbN> Do I just have to add up the size of all NALs in the HEVCPacket?
[00:40:21 CEST] <nevcairiel> vaapi uses a long slice structure? well, "haw-haw" </nelson> :p
[00:40:40 CEST] <BtbN> vaapi also does some other bullshit for hevc
[00:41:02 CEST] <BtbN> like, ignoring its own common structures, and making new common structures with a HEVC suffix, rendering large parts of the common code useless
[00:41:10 CEST] <nevcairiel> for h264 long slices, it works doing this: slice->BitOffsetToSliceData = get_bits_count(&sl->gb);
[00:41:43 CEST] <nevcairiel> so, getting the number of read bits from the read buffer
[00:42:00 CEST] <nevcairiel> (in dxva2)
[00:42:10 CEST] <BtbN> yeah, for vaapi h264 it's the same code
[00:42:17 CEST] <BtbN> But for hevc it only wants bytes, not bits
[00:42:31 CEST] <nevcairiel> >> 3
[00:42:32 CEST] <nevcairiel> :P
[00:43:23 CEST] <BtbN> So my idea would be just to add up the sizes of all HEVCNAL's in the HEVCPacket of the HEVCContext
[00:43:44 CEST] <BtbN> Or maybe the raw_size?
[00:45:15 CEST] <nevcairiel> if its anything like the bitoffset field for h264, then thats not the value it wants
[00:47:55 CEST] <BtbN> The HEVC SliceHeader does have a size field, but it's an int*?
[00:54:31 CEST] <wm4> BtbN: are you trying hevc ffmpeg hwaccel decoding?
[00:54:36 CEST] <BtbN> yep
[00:54:42 CEST] <wm4> k
[00:55:19 CEST] <BtbN> i should propably not stop at every single weird thing, and put a TODO there instead
[01:08:46 CEST] <rcombs> http://puu.sh/jCXAR/f8da3ae246.mkv <-- user reports a regression decoding this file where MP3 frames don't line up with Matroska packets; mpv works with it fine, but ffplay and ffmpeg.c report "Header missing" and produce garbled audio
[01:11:21 CEST] <rcombs> somewhere between a5e5959d52860678d028df07ad1351a11aaf47f7 and fefe04259ae903f265074ef3e8db7e0941f00307
[01:13:46 CEST] <wm4> mpv actually uses libavcodec's mp3 parser for this
[01:14:36 CEST] <rcombs> I thought at first it was using mpg123 but apparently that was removed while I wasn't looking
[01:14:52 CEST] <wm4> yep
[01:34:24 CEST] <rcombs> wm4: ah, yeah, it behaves the same as ffplay with `-demuxer lavf`
[01:41:24 CEST] <rcombs> hmm, and I'm not quite sure why that would've regressed
[01:46:20 CEST] <rcombs> but it's definitely fine in the earlier version, so :shrug:
[01:46:40 CEST] <rcombs> well, for some definition of "fine"
[01:47:35 CEST] <rcombs> it warns once about an "incomplete frame" but that's about it
[02:16:25 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:72237ef6e933: ffmpeg_filter: Do not override the dimensions in sub2video_prepare()
[02:16:25 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:0ac83047f67b: ffmpeg: Print sub2video: rectangle coordinates in case of overflows
[02:16:25 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:bd5d11d9f5fd: ffmpeg: Use actual frame dimensions in checks in sub2video_update()
[02:16:25 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:4ada49f9dbed: ffmpeg: Use the decoders dimensions in sub2video_get_blank_frame()
[02:31:50 CEST] <jamrial> allyuv.png 28.2mb, allyuv.bpg (lossless) 6.3mb, allyuv.webp (lossless) 1.3mb
[02:34:03 CEST] <ubitux> yeah bgp is not really for lossless
[02:34:31 CEST] <ubitux> and webp is actually designed to replace both jpg & png, right?
[02:34:47 CEST] <jamrial> yeah
[02:35:10 CEST] <jamrial> i'm suprised at how badly png did here more than anything
[02:36:29 CEST] <ubitux> isn't it simply because our encoder is bad?
[02:36:45 CEST] <ubitux> what happened after an optipng on it?
[02:36:50 CEST] <jamrial> ah, could be
[02:38:40 CEST] <cone-144> ffmpeg 03Mariusz SzczepaDczyk 07master:767d780ec001: doc/examples: rename avio_list_dir -> avio_dir_cmd
[02:39:38 CEST] <jamrial> running optipng -o7, give me a few minutes :p
[02:39:54 CEST] <ubitux> i'm running it as well... :D
[02:43:53 CEST] <ubitux> this reminds me the dark ages of libvpx encoding vp9 hd footage
[02:45:00 CEST] <jamrial> did it get better since then?
[02:45:06 CEST] <ubitux> no idea
[02:45:28 CEST] <ubitux> zc = 9 zm = 9 zs = 0 f = 2IDAT size = 2073183
[02:45:33 CEST] <ubitux> so about 2M with these settings
[02:45:37 CEST] <jamrial> also, bgpenc took several minutes as well enconding this image, all while eating 1gb of ram
[02:45:44 CEST] <ubitux> haha
[02:46:00 CEST] <ubitux> zc = 9 zm = 9 zs = 1 f = 2IDAT size = 2071737
[02:46:04 CEST] <ubitux> ~2M again
[02:54:43 CEST] <ubitux> yeah in the end that's what you get
[02:54:47 CEST] <ubitux> 2M after optipng
[02:55:06 CEST] <ubitux> webp still much better, but png remains decent
[03:12:07 CEST] <wm4> ffmpeg's encoder can be made to use some extended png features
[03:12:21 CEST] <wm4> obscure avoptions
[03:27:12 CEST] <rcombs> welp I'm failing miserably at `git bisect run`
[03:27:21 CEST] <rcombs> landing on nonsense
[03:28:13 CEST] <rcombs> is there something I have to do to avoid libav merge funkiness
[03:37:21 CEST] <Plorkyeran> there's nothing built in to git for it
[03:38:10 CEST] <Plorkyeran> git bisect doesn't really work when you commit broken things then fix them in the next commit
[03:38:40 CEST] <Plorkyeran> unless there's something you can do to distinguish that sort of brokenness from the brokenness you're looking for
[04:52:57 CEST] <rcombs> ah-ha!
[04:52:59 CEST] <rcombs> regressed in 8ca098f4445cd12d39b2c55b0dfb8c988b7b28ce
[07:21:10 CEST] <atomnuker> libmodplug does a nice job with everything except midi files
[07:21:52 CEST] <atomnuker> it should support timidity samples (pat instruments) but it isn't working
[07:22:41 CEST] <atomnuker> the code apparently only pokes to see if timidity.cfg exists in some defined directory and falls back to horribly using software FM synthesis for instruments
[07:24:33 CEST] <atomnuker> If no one can confirm it has ever worked for them I'll probably write a decoder using libmodplug, an actual still living project
[07:24:48 CEST] <atomnuker> *libfluidsynth
[08:45:44 CEST] <rcombs> anyone around who knows mpegaudio_parser?
[08:45:55 CEST] <rcombs> wtb some examination of https://trac.ffmpeg.org/ticket/4776
[08:46:28 CEST] <rcombs> it's the `if (s1->flags & PARSER_FLAG_COMPLETE_FRAMES)` branch in 8ca098f4445cd12d39b2c55b0dfb8c988b7b28ce that causes the bug (removing it fixes it), but I'm not sure if that's there for a reason
[09:02:41 CEST] <nevcairiel> if its possible that frames dont line up with packets, then it probably shouldnt set the flag that triggers the complete frames thingy
[09:08:36 CEST] <nevcairiel> (in matroskadec)
[09:08:49 CEST] <nevcairiel> seems like a bad mux though
[09:10:02 CEST] <rcombs> yeah
[09:10:24 CEST] <rcombs> but apparently at least some other software handles it, and it used to work in ffmpeg
[09:24:42 CEST] <ubitux1> rcombs: there is a ffbisect to avoid the libav merges
[09:25:13 CEST] <rcombs> where?
[09:25:56 CEST] <ubitux1> rcombs: tools/bisect-create maybe
[09:26:18 CEST] <ubitux1> it will create a tools/ffbisect
[09:26:27 CEST] <ubitux1> dunno how it works in details, never used it
[09:27:24 CEST] <rcombs> looks like it basically checks if ffmpeg.c exists
[09:27:38 CEST] <rcombs> which is basically what I ended up doing but less dumb
[09:27:39 CEST] <ubitux1> yeah, it avoids landing in a libav state
[09:27:57 CEST] <rcombs> and skips otherwise
[09:28:02 CEST] <rcombs> simple enough
[12:35:14 CEST] <durandal_1707> michaelni: could you look at #3847?
[12:39:56 CEST] <cone-491> ffmpeg 03Michael Niedermayer 07master:31d6f8de53bf: doc/filter_design: Remove reference to the deprecated and unused cur_buf_copy
[12:39:56 CEST] <cone-491> ffmpeg 03Rodger Combs 07master:b4b2717ffe89: lavf/matroskadec: Fully parse and repack MP3 packets
[13:29:21 CEST] <Compn> ubitux1 / rcombs : does any of that need to be in developer documentation ?
[13:29:27 CEST] <Compn> re libav merge bisecting
[13:30:29 CEST] <rcombs> Compn: probably worthwhile
[13:31:02 CEST] <rcombs> just saying "make the first line of your `bisect run` script `[ -f ffmpeg.c ] || exit 125`" gets you a decent stretch of the way there
[13:31:47 CEST] <rcombs> and then the bisect-create script works if you're doing it manually
[14:21:33 CEST] <Compn> rcombs : post to ml if you can and someone will make a docs patch...
[14:21:35 CEST] Action: Compn afk
[15:27:25 CEST] <BtbN> Does HEVC only ever have one slice per frame?
[15:28:41 CEST] <cone-491> ffmpeg 03Michael Niedermayer 07master:0cb87cd7d4cf: avfilter/avfiltergraph: Implement and use find_best_sample_fmt_of_2()
[15:31:24 CEST] <iive> BtbN: only if you want to
[15:31:56 CEST] <BtbN> Well, I'm trying to write vaapi hevc hwaccel, and vaapi wants to know a slice_data_byte_offset
[15:32:03 CEST] <BtbN> And i have no idea where to get it from
[15:32:19 CEST] <BtbN> "Byte offset from NAL unit header to the begining of slice_data()"
[15:33:05 CEST] <BBB> BtbN: isnt that the same as slice header length?
[15:33:23 CEST] <BtbN> https://github.com/gbeauchesne/gstreamer-vaapi/blob/master/gst-libs/gst/vaa…
[15:33:28 CEST] <BtbN> that's how gstreamer calculcates it
[15:33:31 CEST] <BtbN> so i'd say yes
[15:34:46 CEST] <BBB> I dont think we export it at this point, but feel free to add a field with the appropriate value at the bottom of hls_slice_header
[15:35:12 CEST] <iive> BtbN: this is hunaly readable explanation of h265 features http://www.f265.org/f265/static/txt/h265_companion.html
[15:35:19 CEST] <iive> humanly...
[15:35:35 CEST] <BBB> do you call hls_slice_header in vaapi_hevc?
[15:35:41 CEST] <BBB> or is there some other interafce?
[15:35:56 CEST] <BtbN> The normal hevc code calls into the hwaccel i think
[15:36:00 CEST] <BtbN> so it should be called automaticaly
[15:36:17 CEST] <BBB> something like get_bits_count(s->HEVClc->gb) should work upon initial frame decoding
[15:36:45 CEST] <BBB> and then align and >>3 it to get byte
[15:36:56 CEST] <BtbN> But isn't that per-frame?
[15:37:05 CEST] <BBB> no, thats called for each slice
[15:37:11 CEST] <BBB> each nal unit
[15:37:24 CEST] <BBB> so if a frame has multiple nal units / slices, its called multiple times
[15:40:15 CEST] <BtbN> So basicaly slice_param->slice_data_byte_offset = (get_bits_count(h->HEVClc->gb) + 7) / 8; should be enough?
[15:40:34 CEST] <BBB> I believe so
[15:40:48 CEST] <BtbN> Maybe + 1, as the nal_unit_type has already been read before
[15:41:06 CEST] <BBB> thats possible, it depends on where the gb is initialized
[15:41:18 CEST] <BtbN> The h264 vaapi code adds 8
[15:41:22 CEST] <BtbN> for the same reason
[15:42:12 CEST] <BBB> init_get_bits8(gb, nal->data + 2, nal->size);
[15:42:17 CEST] <BBB> so it may be +2, not +1
[15:42:28 CEST] <BBB> anyway, try values, compare with gstreamer, and see what the correct value is :-p
[15:43:01 CEST] <BBB> buf[1] is the temporal id, apparently?
[15:43:43 CEST] <BBB> bbl
[16:03:32 CEST] <BtbN> The vaapi error communication is also very nice
[16:04:14 CEST] <BtbN> VA_STATUS_ERROR_INVALID_VALUE
[17:54:03 CEST] <durandal_1707> michaelni: thanks
[17:55:29 CEST] <michaelni> np
[18:17:44 CEST] <cone-491> ffmpeg 03Andreas Cadhalpun 07master:fbc8eb685784: ffmpeg: use av_buffersrc_add_frame instead of av_buffersrc_add_ref
[18:21:29 CEST] <BtbN> __gb__, do you happen to know if there is a way to get more information out of libva/the intel driver than "Error 18 - invalid parameter"? I tried enabling LIBVA_TRACE and setting VA_INTEL_DEBUG=3, but the trace log only contains the basic function calls and parameters.
[18:59:31 CEST] <kierank> atomnuker, Daemon404: so say 7pm at cheshire cheese?
[18:59:36 CEST] <kierank> on thursday
[19:10:33 CEST] <Daemon404> kierank, do i need to eat first or not
[19:10:37 CEST] <kierank> dunno
[19:10:47 CEST] <Daemon404> 145 Fleet St, London EC4A 2BU
[19:10:49 CEST] <Daemon404> this one?
[19:11:18 CEST] <kierank> yes
[19:11:46 CEST] <Daemon404> sure
[19:11:51 CEST] <Daemon404> tahts walking distance for me
[19:12:36 CEST] <atomnuker> fine by me as well
[22:38:56 CEST] <cone-455> ffmpeg 03Andreas Cadhalpun 07master:d90fbde06a80: buffersink: introduce FIFO_INIT_ELEMENT_SIZE to complement FIFO_INIT_SIZE
[23:06:28 CEST] <philipl> BtbN: sounds like vaapi is keeping you entertained.
[23:08:33 CEST] <wm4> intel stuff always does
[23:17:10 CEST] <Daemon404> lmao debian guy comparing breaking ffmpeg api BS with a libc
[23:18:56 CEST] <wm4> I must join the trolling
[23:19:03 CEST] Action: wm4 looks
[23:24:49 CEST] <wm4> don't see anything about libc
[23:25:45 CEST] <Daemon404> it might have been put in youre libav folder
[23:25:47 CEST] <Daemon404> its on both MLs
[23:25:52 CEST] <Daemon404> your*
[23:26:28 CEST] <wm4> google does that, but I don't see it
[23:26:40 CEST] <nevcairiel> the last mail from andreas, last paragraphj
[23:26:41 CEST] <wm4> or maybe it's an old mail
[23:26:57 CEST] <wm4> oh
[23:27:00 CEST] <wm4> I'm just blind
[23:27:03 CEST] <Daemon404> ;p
[23:27:33 CEST] <Daemon404> i must admit it's really damn annoying to have Mr Distro Maintainer NAK all deprecations ever
[23:28:11 CEST] <wm4> I don't get why he endlessly argues with us instead of the downstreams
[23:28:18 CEST] <wm4> maybe it's because the downstreams are dead or something
[23:28:47 CEST] <Daemon404> it's the least amount of effort
[23:28:58 CEST] <Daemon404> doesnt break -> sit on ass
[23:29:03 CEST] <Daemon404> the distro packager way.
[23:32:00 CEST] <jamrial> i'm with nevcairiel. if we postpone everything we'll be discussing this again in one year
[23:32:13 CEST] <Daemon404> yep
[23:32:50 CEST] <nevcairiel> indeed, a bunch of those have been postponed before
[23:34:00 CEST] <jamrial> i'm surprised this one guy even said two years between deprectation and removal was too short. and he was talking about the pixfmt stuff that's just adding an AV_ prefix to some defines
[23:34:47 CEST] <Daemon404> [22:29] <@Daemon404> the distro packager way.
[23:35:04 CEST] <Daemon404> clearly you have never dealt with one
[23:39:18 CEST] <wm4> jamrial: imagine you're a package manager... and then someone demands you to ACTUALLY MAINTAIN YOUR PACKAGES
[23:39:21 CEST] <wm4> the horror
[23:40:07 CEST] <JEEB> "wait... I can't just git checkout and build things?"
[23:46:38 CEST] <nevcairiel> its like people asking to update the ffmpeg integraiton in your project, which some random contributor wrote 3 years ago and noone knows how it works
[23:47:08 CEST] <durandal_1707> deprecate all the things
[23:47:47 CEST] <Daemon404> nevcairiel, rm -r?
[23:49:03 CEST] <nevcairiel> but features!
[23:49:16 CEST] <durandal_1707> they want maintainers for free
[00:00:00 CEST] --- Mon Aug 17 2015
1
0
[04:02:36 CEST] <jim_> Hi I have an issue with avcodec_open2() [18:56] <jim_> Please see the attached code. It works fine for AVRational{1,30} but gives an error for AVRational{1,31} [18:57] <jim_> Any ides?
[04:02:53 CEST] <jim_> http://pastebin.com/jSysGtj7
[07:51:19 CEST] <TikityTik> what encoding options should i use for making gifs?
[07:51:34 CEST] <TikityTik> I'm only changing the resolution and framerate.
[08:01:22 CEST] <relaxed> TikityTik: http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
[08:08:02 CEST] <TikityTik> ok i'm using palettegen but ffmpeg is still working and the time isn't increasing
[08:11:39 CEST] <TikityTik> relaxed: do you know why?
[08:12:00 CEST] <TikityTik> does -ss, -t, and fps interfere?
[08:15:53 CEST] <TikityTik> oh, it's just really slow
[08:31:18 CEST] <TikityTik> https://www.ffmpeg.org/ffmpeg-scaler.html
[08:31:23 CEST] <TikityTik> https://ffmpeg.org/ffmpeg-filters.html#scale-1
[08:31:42 CEST] <TikityTik> the 2nd link doesn't describe the sws_dither option for the scale filter
[08:37:22 CEST] <TikityTik> what's the difference between -lavfi and -vf?
[10:54:49 CEST] <TikityTik> I'm having issues with the overlay filter
[10:55:25 CEST] <TikityTik> ffmpeg -ss 21:20 -t 1:30 -i in.mkv -i in.jpg -map_metadata -1 -c:v libvpx -c:a libvorbis -bufsize 2M -crf 10 -qmax 50 -b:v 316k -ac 1 -q:a 0 -ar 22050 -filter_complex "[0:v] [1:v]overlay=enable='between(t,0,1)',scale=-1:300:flags=lanczos" -sn -cpu-used 0 -quality good -threads 4 -y out.webm
[10:55:29 CEST] <TikityTik> this is what i have so far
[10:55:43 CEST] <TikityTik> but the video is glitching out
[11:17:24 CEST] <TikityTik> apparently i needed -fmt_pix yuv420p
[12:31:16 CEST] <silverfox> Hello, I am having a problem compiling ffmpeg using MSYS2, as prescribed here under section 4.1: https://www.ffmpeg.org/platform.html#Windows . I am running on a laptop with Windows 8.1, Intel Core i5-3337U (2 core).
[12:33:47 CEST] <silverfox> I have followed all of the instructions in setting up MSYS2 according to these instructions, however ommitting the stuff about Microsoft Visual Studio, YASM, and the gas-preprocessor; https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT
[12:36:54 CEST] <silverfox> I start up MSYS2, type: cd /c/ffmpeg-master Followed by: ./configure --disable-network && make && make install
[12:38:18 CEST] <silverfox> And I get the error: Unknown OS 'msys_nt-6.3'.
[12:49:05 CEST] <silverfox> Additionally, I am trying to compile 64bit ffplay using MSYS2 and MinGW-w64, as it says you can in section 4.1 of https://www.ffmpeg.org/platform.html#Windows.
[12:52:05 CEST] <silverfox> When typing simply make && make install, a bunch of stuff flashes past the screen (no idea where it is saving this stuff to). However if I use ./compile [options] it gives the 'Unknown OS 'msys_nt-6.3' error
[13:01:17 CEST] <curmudgeon> Hi. I am trying to convert a .ts that I downloaded to a .mkv (without reencoding, of course). Can anyone tell me why this is not working (and if there is some way to fix it): http://pastebin.com/ZpwvW3sT
[13:04:58 CEST] <BtbN> Looks like the input file is damaged. You could try increasing the analyze duration, maybe it managed to find the extra data.
[13:06:19 CEST] <curmudgeon> Do you recommendation for what duration to use?
[13:07:24 CEST] <curmudgeon> Don't see that option in the man page.
[13:08:25 CEST] <curmudgeon> It plays perfectly as a .ts (but that is not compatible with certain devices).
[13:12:18 CEST] <jim__> Hi guys. I have an issue with avcodecContext time base.
[13:12:24 CEST] <jim__> Please check out the code
[13:12:30 CEST] <jim__> http://pastebin.com/jSysGtj7
[13:12:43 CEST] <jim__> it works for 30 fps but not for 31
[13:12:48 CEST] <jim__> am I missing somethnig
[13:12:49 CEST] <jim__> ?
[13:25:59 CEST] <jim__> Where can I find information about the valid tmiebase values for MPEG1codec
[13:52:19 CEST] <buu> Hey, if I'm using ffmpeg -i foo.mp4 -r 30 "rtmp://foo" to attempt to stream a file to an rtmp server, shouldn't the -r set the fps to 30?
[13:52:29 CEST] <buu> Why would the statu output of ffmpeg say 95+ fps?
[13:55:08 CEST] <klaxa> -r 30 sets the framerate for the file, not the framerate for encoding
[13:55:13 CEST] <klaxa> you probably want to look at the -re flag
[13:56:31 CEST] <klaxa> buu: ^
[13:57:43 CEST] <buu> To force the frame rate of the output file to 24 fps:
[13:57:43 CEST] <buu> ffmpeg -i input.avi -r 24 output.avi
[13:57:50 CEST] <buu> klaxa: What does that mean then?
[13:58:23 CEST] <klaxa> it means that when you play back the file, it will be played back at 24 fps
[13:58:52 CEST] <buu> ohhh
[13:58:54 CEST] <klaxa> or do you mean the -re flag? that means ffmpeg will read the file at "real-time" speed, i.e. as fast as it would be played back
[13:59:09 CEST] <buu> Yeah, the -re flag seems to work great
[14:11:54 CEST] <pauled> Hello, I am getting this "Error parsing AAC extradata, unable to determine samplerate." with this command: livestreamer twitch.tv/mathiaslager high -O | %ffmpeg% -i - -c:v copy -vcodec copy -c:a copy mathiaslager-%ldt%.mkv
[14:13:05 CEST] <buu> pauled: Have you tried explicitly setting an audio bit rate?
[14:13:22 CEST] <pauled> buu, nope, wanting to copy
[14:13:30 CEST] <buu> Might be worth a try
[14:22:13 CEST] <pauled> still working now
[14:22:30 CEST] <pauled> with "-f mpegts" livestreamer twitch.tv/mathiaslager high -O | %ffmpeg% -i - -c:v copy -vcodec copy -c:a copy -f mpegts mathiaslager-%ldt%.mkv
[14:22:47 CEST] <pauled> buu still working now
[14:23:08 CEST] <buu> Hrm. This is peculiar. I'm doing basically: ffmpeg -re -i foo.mp4 "rtmp://steam"; and it works perfectly, but if I change to: while read i; do ffmpeg ... -i "$i" ...; done < filellist
[14:23:32 CEST] <buu> It works fine if "filelist" has one line/file in it, but if it has, say, 10 lines, ffmpeg explodes and dies
[14:26:27 CEST] <buu> Is this confusing ffmpeg's stdin/out?
[14:28:48 CEST] <buu> wtf
[14:32:40 CEST] <pauled> you are trying to transcode multiple stream in same time?
[14:33:09 CEST] <pauled> or one after one in a batch?
[14:33:13 CEST] <pauled> buu ^
[14:35:58 CEST] <buu> pauled: one after the other
[14:36:03 CEST] <buu> a playlist
[14:41:12 CEST] <pauled> -i inputs.txt
[14:44:50 CEST] <pauled> buu ^
[14:45:01 CEST] <buu> pauled: Well, ok, but why does my way blow up ffmpeg?
[14:45:04 CEST] <pauled> or you can try http://stackoverflow.com/questions/10929453/bash-scripting-read-file-line-b…
[14:45:27 CEST] <buu> pauled: You realize the stackoverflow is what I did right?
[14:45:38 CEST] <pauled> probably while IFS='' read -r line || [[ -n "$line" ]]; do
[14:45:44 CEST] <buu> "There is a caveat with this method. If anything inside the while loop is interactive (e.g. reads from stdin), then it will take its input from $1. You will not be given a chance to enter data manually. carpie Jan 16 '14 at 16:25
[14:46:00 CEST] <buu> So ffmpeg is trying to read the file also
[14:46:08 CEST] <buu> Pesky.
[14:52:26 CEST] <buu> So -nostdin fixes it
[14:52:33 CEST] <buu> That seems.. wrong.
[14:54:01 CEST] <jim__> Hi, How do I check valid timbase values for avcodeccontext?
[14:54:07 CEST] <jim__> I am using MPEG1 codec
[14:54:30 CEST] <Fjorgynn> so
[14:54:31 CEST] <jim__> I am trying 31 fps but it gives an error
[14:57:36 CEST] <Mavrik> jim__, you can't have 31 fps with MPEG-1
[14:57:40 CEST] <Mavrik> because it doesn't support that.
[14:58:26 CEST] <jim__> Thanks Mavrik. How can I find supported values?
[14:58:36 CEST] <Mavrik> MPEG-1 standard I guess.
[14:58:55 CEST] <Mavrik> I doubt you get much more than 25, 30 and 29.97
[14:59:39 CEST] <jim__> I works for 50 as well
[14:59:51 CEST] <jim__> I have tested it
[15:00:04 CEST] <Mavrik> Which is interlaced rate for 25.
[15:00:16 CEST] <Mavrik> Also, why the heck MPEG-1 :)
[15:00:21 CEST] <Mavrik> That's like 1990 tech
[15:01:04 CEST] <jim__> I know :) just stuck with it for the moment :)
[15:01:59 CEST] <jim__> Any recommendation which encoder should I use in order to keep the output file as small as possible? sorry for a stupid question but I am new to this.
[15:03:18 CEST] <Mavrik> jim__, http://ffmpeg.org/doxygen/trunk/mpeg12data_8c_source.html#l00308
[15:03:25 CEST] <Mavrik> jim__, libx264 with slowest of presets
[15:03:40 CEST] <Mavrik> it's orders of magnitude more efficient thatn MPEG-1
[15:03:55 CEST] <Mavrik> H.265 would work too, but that's not as widely supported
[15:04:25 CEST] <jim__> wow. Thanks a lot. Really appreciate it :)
[15:07:10 CEST] <jim__> By the way I am storing file on the disk in near real time which means encoding should be fast as well.
[15:11:38 CEST] <pauled> jim__: use a GUI to find the right compromise between size and speed, is much simpler.
[15:12:05 CEST] <jim__> Thanks paul, will try so.
[15:12:16 CEST] <pauled> handbrake is good GUI to find the good preset
[15:13:07 CEST] <pauled> jim__: experiment with a small file.
[15:18:49 CEST] <jim__> great :)
[15:33:01 CEST] <DHE> besides /dev/null, is there an output target that discards the output? (for use with two-pass mode)
[15:39:32 CEST] <iive> you can use it multiple times :)
[16:25:17 CEST] <diq3> anyone any idea about that error here? https://pastebin.mozilla.org/8842899
[16:25:28 CEST] <diq3> ERROR: ffmpeg[7F37077FE700]: [mpeg2video] ac-tex damaged at 11 4
[16:25:32 CEST] <diq3> what does that mean?
[16:26:12 CEST] <diq3> its an error when playing a dvd in openelec. same dvd on same pc works perfectly fine with linux mint
[16:42:53 CEST] <iive> diq3: the error means that when decoding idct coefficient it had reached an impossible state. that happens on bitstream errors.
[16:43:36 CEST] <iive> if you get only errors and no image, then it might be encrypted stream.
[16:44:48 CEST] <diq3> iive: this is a strange problem i get on most recent version of openelec when playing one exact dvd. Openelec is an entertainment system based on kodi. I dont get such an error and everything is working fine on linux mint 17.2 and dvd playback in vlc. i also dont get that error in kodibuntu
[16:45:39 CEST] <diq3> iive: the unencryption is been done by libdvdcss2 and works fine by default without the need to install anything on the two named systems
[16:52:25 CEST] <iive> there are many reason you can get damaged bitstream...
[16:56:47 CEST] <diq3> iive: so you dont have out of your head an idea what i could tell the deveoper from you (the ffmpeg developer)
[17:15:29 CEST] <silverfox> Hi. I am new to msys and mingw. I am trying to compile ffplay 64bit, using msys2 and mingw-w64 using a windows 8.1 machine. I have msys2 setup, however when I use ./compile [options] i get 'Unknown OS msys_nt-6.3'.
[17:20:44 CEST] <intracube> is there a way to blur in only one direction?
[17:22:19 CEST] <intracube> i.e. vertical only
[17:23:55 CEST] <intracube> I could scale the video height to 1/4 size, then back up
[17:24:51 CEST] <intracube> which would have a similar effect
[17:54:32 CEST] <oreWizard> mLINK : fatal error LNK1117: syntax error in option ''
[17:54:33 CEST] <oreWizard> C compiler test failed.
[17:54:37 CEST] <oreWizard> someone can helpme?
[18:43:52 CEST] <TikityTik> when I use -pass 1, when do i have to use it again if i change an encoding option?
[18:43:57 CEST] <TikityTik> on filters? on bitrate?
[18:45:03 CEST] <TikityTik> did someone say my name?
[18:45:57 CEST] <TikityTik> can you PM me because I think i'm not getting any chat through this channel
[18:46:46 CEST] <oreWizard> fatal error LNK1181: cannot open input file 'WindowsPhoneCore.lib'
[18:47:05 CEST] <oreWizard> i am getting this error on try to compile
[18:48:28 CEST] <TikityTik> can't say i know how to fix that
[18:49:01 CEST] <TikityTik> maybe you're not using the right build script?
[19:13:15 CEST] <oreWizard> idk
[19:19:00 CEST] <TikityTik> I'm guessing you wouldn't use two-pass for a lossless h.264 encoding?
[19:20:40 CEST] <BtbN> two-pass makes no sense for lossless encoding.
[19:20:53 CEST] <BtbN> It's only use is to target a specific output file size
[19:21:00 CEST] <TikityTik> i see
[19:21:06 CEST] <BtbN> with the best possible overall quality
[19:21:12 CEST] <TikityTik> and you only need a preset and -qp 0 to make it lossless right?
[19:21:36 CEST] <TikityTik> also how can i make vorbis lossless? I find using -q:a 10 makes it even bigger than before
[19:23:22 CEST] <klaxa> vorbis cannot be lossless
[19:23:33 CEST] <klaxa> you can use flac for lossless audio
[19:23:33 CEST] <TikityTik> klaxa: what do you suggest? flac?
[19:23:36 CEST] <TikityTik> i see
[19:23:45 CEST] <TikityTik> Also I'm using this, ffmpeg -ss 22:50 -i in.mkv -t 1:30 -map_metadata -1 -c:v libx264 -preset veryslow -qp 0 -c:a libvorbis -q:a 5 -threads 4 out.mkv
[19:24:04 CEST] <TikityTik> and the output file is broken, it freezes at the start
[19:24:21 CEST] <klaxa> you probably have to move/split your -ss parameter
[19:24:30 CEST] <klaxa> see: https://trac.ffmpeg.org/wiki/Seeking
[19:24:51 CEST] <TikityTik> in what manner? I noticed on other files that input seeking works better than output seeking as it makes the start freeze
[19:25:04 CEST] <TikityTik> but now input seeking is freezing for this encoding
[19:26:32 CEST] <TikityTik> couldn't find any google results on that issue
[19:27:54 CEST] <klaxa> for starters you can move -ss 22:50 after -i in.mkv to see if that fixes it at all
[19:28:10 CEST] <TikityTik> yeah it did the trick
[19:31:08 CEST] <TikityTik> but i'm not sure why both of them would glitch for different files
[19:45:21 CEST] <klaxa> what do you mean with "both of them"?
[19:45:32 CEST] <klaxa> using -ss after -i should never glitch anything
[20:01:06 CEST] <TikityTik> sorry for the late response
[20:01:30 CEST] <TikityTik> yeah i think it glitched hard when I used -ss both before and after -i, so combined seeking
[20:02:01 CEST] <TikityTik> But I think that's when I was using -codec copy
[20:07:55 CEST] <klaxa> oh yeah, codec copy only works on keyframes
[20:08:13 CEST] <klaxa> that's the only case when -ss can "glitch"
[20:11:45 CEST] <TikityTik> should i use the subtitles filter before or after the scale filter?
[20:11:56 CEST] <TikityTik> I would assume after
[20:12:29 CEST] <klaxa> use -t 10, try both, use the one that looks better?
[20:14:02 CEST] <jim__> Hi Guys. Please have a look at the code http://pastebin.com/STguMPJg
[20:14:33 CEST] <jim__> I am configuring the codeccontext with 100 fps but when I play in the VLC it is played at 25fps
[20:14:40 CEST] <jim__> any idea what is going on?
[20:14:51 CEST] <jim__> I am using AV_CODEC_ID_MPEG2VIDEO
[20:20:16 CEST] <Koyhaku> Hey, I'm completely new to ffmpeg, I'm looking at the documentation and I can't seem to find out how to actually use it from the command line. Could someone help me out? I can take it from there once I know how to get to it with the command prompt > Using windows 10, 64bit
[20:20:54 CEST] <TikityTik> depends what codecs you're using
[20:21:26 CEST] <Koyhaku> I've just downloaded the windows build from the website
[20:21:57 CEST] <Koyhaku> I think it was this one, "Latest Zeranoe FFmpeg Build Version: git-767d780 (2015-08-16)"
[20:22:00 CEST] <TikityTik> do you know anything about codecs?
[20:22:11 CEST] <Koyhaku> Nothing, I just want to convert my videos.
[20:22:17 CEST] <TikityTik> to what?
[20:22:23 CEST] <Koyhaku> mp4 to webm
[20:22:39 CEST] <c_14> Koyhaku: https://ffmpeg.org/ffmpeg.html
[20:22:48 CEST] <Koyhaku> I tried using Miro but it converted that to a webmhd file which wouldn't play in firefox.
[20:22:55 CEST] <TikityTik> Koyhaku: https://boards.4chan.org/wsg/thread/700091
[20:23:06 CEST] <klaxa> when you downloaded ffmpeg as a 7z/rar/zip or whatever archive files are used, you navigate your command shell to the directory where you extracted it and just run: ffmpeg.exe -i in.mp4 out.webm
[20:23:10 CEST] <klaxa> for example
[20:23:14 CEST] <TikityTik> Koyhaku: someone wrote a pretty good guide on how to make webms there
[20:23:55 CEST] <Koyhaku> Thank you both for your very quick and timely help.
[20:29:47 CEST] <TikityTik> speaking of webms
[20:30:13 CEST] <TikityTik> I'm having significant differences in filesize encoding when i'm encoding 1:30 webms
[20:30:54 CEST] <TikityTik> the motion is similar but the videos that i'm encoding from are different. Possibly using the subtitles filter also increases filesize.
[20:31:06 CEST] <TikityTik> what's up with that
[20:31:33 CEST] <TikityTik> I'm using the same -crf and bitrates for audio and video
[20:31:50 CEST] <TikityTik> And I compensate with -qmax and scale
[20:34:11 CEST] <TikityTik> so i'm wondering, what source encoding can affect output encoding filesize?
[20:40:47 CEST] <TikityTik> also these videos have almost the same types of motion
[20:52:01 CEST] <silverfox> Hi. I am new to msys and mingw. I am trying to compile ffplay 64bit, using msys2 and mingw-w64 using a windows 8.1 machine. I have msys2 setup, however when I use ./compile [options] i get 'Unknown OS msys_nt-6.3'.
[20:56:49 CEST] <TikityTik> did you use the configure command? Not that I know if it has one.
[20:57:59 CEST] <silverfox> when i use ./configure --some-option it gives that error
[20:58:30 CEST] <silverfox> if i just type make or make install, a bunch of stuff flashes, that i have no idea where it puts
[20:59:08 CEST] <silverfox> but the point is, i only want ffplay, so i need to be able to do ./configure --enable-ffplay (which i assume disables the others, since --enable-ffplay was not in the --help)
[20:59:42 CEST] <silverfox> i just saw someone do --enable-ffplay in a post somewhere.
[21:00:22 CEST] <silverfox> i was hoping that i was simply making an obvious rookie mistake..
[21:23:17 CEST] <TikityTik> silverfox: why not just download an already compiled version for windows?
[22:15:32 CEST] <Fyr> guys, how to convert with ffmpeg preserving directory structure?
[22:17:20 CEST] <retard> i don't understand the question
[22:17:27 CEST] <Fyr> haha
[22:17:42 CEST] <Fyr> your nick explains why.
[22:17:57 CEST] <retard> ffmpeg converts content
[22:18:05 CEST] <retard> directories are a matter of organization
[22:18:19 CEST] <Fyr> agreed
[22:18:31 CEST] <Fyr> what is the method to keep the directory structure?
[22:18:49 CEST] <retard> entirely unrelated to ffmpeg?
[22:19:00 CEST] <retard> also, it clearly depends on the directory structure
[22:20:55 CEST] <c_14> Fyr: what you're looking for is a scripting language
[22:21:00 CEST] <Fyr> yes
[22:21:17 CEST] <Fyr> somebody speaking English
[22:24:00 CEST] <Fyr> actually, I expected a GUI or something. =)
[22:25:08 CEST] <Mavrik> O.o
[22:25:19 CEST] <Mavrik> Do you usually insult people trying to help you?
[22:26:07 CEST] <Fyr> I don't insult no one. =)
[22:26:55 CEST] <Fyr> Cartman is my favorite character, though.
[22:27:12 CEST] <retard> you come to ffmpeg expecting a gui
[22:28:39 CEST] <Fyr> yeah, what am I, a retard?
[22:30:28 CEST] <ln-> Fyr: please speak proper English yourself if you demand it from others.
[22:33:14 CEST] <retard> i'm retard
[22:33:33 CEST] <Fyr> alright, I don't have an excuse.
[22:33:44 CEST] <pauled> Fyr, there is no structure in a container, all are in one file
[22:33:55 CEST] <retard> i routinely and happily assist people with creating scripts and whatnot
[22:34:06 CEST] <retard> for some reason i don't feel motivated right now though
[22:34:16 CEST] <pauled> if you mean subltitles, language etc of a dvd
[22:36:13 CEST] <Fyr> I meant branchy structure of audio files. =/
[22:36:34 CEST] <pauled> just google convert dvd to mkv, mp4,
[22:37:40 CEST] <pauled> all audio and other stuff are converted into a container like MKV, MP4 AVI ETC
[22:39:27 CEST] <pauled> just google ffmpeg + dvd convert
[22:39:59 CEST] <pauled> also there are many GUI that use ffmpeg todo that
[22:41:26 CEST] <chungy> you should be able to modify this script for your purpose: https://gist.github.com/chungy/4a9e70c8b034d5b41aa6
[22:42:27 CEST] <Fyr> I'm using Windows. ='(
[22:43:24 CEST] <chungy> Hmm, I'm sorry to hear
[22:43:29 CEST] <chungy> It'd probably work in Cygwin though
[22:47:36 CEST] <Fyr> conscience of feeling embarrassed when you're saying that you're using Windows might change the world. =)
[23:24:31 CEST] <TikityTik> I'm having issues making this webm
[23:24:51 CEST] <TikityTik> I'm trying everything I can to make a webm from an image and an mp3.
[23:24:52 CEST] <TikityTik> ffmpeg -i in.jpg -i in.mp3 -map_metadata -1 -loop 1 -r 1 -c:v libvpx -crf 10 -qmax 35 -qmin 5 -b:v 1M -s 640x480 -c:a libvorbis -ac 2 -q:a 1 -threads 4 -shortest out.webm
[23:25:21 CEST] <TikityTik> but the video only ends up as 1 second long, and when I take out -shortest, the image doesn't show and the sound doesn't play
[23:31:45 CEST] <TikityTik> finally got it working. Had to put -loop 1 RIGHT AFTER FFMPEG
[23:35:08 CEST] <TikityTik> also why is it that mpc-hc shows greenbars on my webm, but that's not the case for firefox?
[23:40:34 CEST] <JEEB> depends on the version and used DShow filters
[23:42:30 CEST] <TikityTik> JEEB: what do you mean DShow filter? Also is it not a problem with my encoding?
[23:43:10 CEST] <JEEB> mpc-hc is a directshow (aka DShow) player, it uses dshow filters to form the chain from [file] to [something shown on the screen]
[23:43:39 CEST] <JEEB> you have one filter that reads the file, another that handles the container, another that decodes the video and so forth and so forth
[23:44:22 CEST] <TikityTik> which one do you recommend?
[23:44:41 CEST] <JEEB> in what sense?
[23:45:32 CEST] <JEEB> I'm just telling you to check what version your player is, and check if the vendor has a newer version available. if that doesn't help, you would have to start checking out your filter chain
[23:46:42 CEST] <TikityTik> MPC-HC 1.7.9, it's the newest.
[23:49:08 CEST] <JEEB> ok, now you can pastebin what's under play->filters when you right-click the player window
[23:49:41 CEST] <JEEB> of course this doesn't have much to do with ffmpeg any more
[23:50:02 CEST] <JEEB> we can move towards #mpc-hc with this issue
[23:50:21 CEST] <jim444> HI. I am trying to store video stream as MPEG2 file. I have set frame rate in Avcodeccontext to 100 fps but the file generated shows a frame rate of 25fps when I play it with VLC.
[23:50:25 CEST] <jim444> Here is the code
[23:50:32 CEST] <jim444> http://pastebin.com/STguMPJg
[23:50:36 CEST] <jim444> Any idea please?
[23:50:56 CEST] <JEEB> ok, you are setting the time base, are you also setting the PTS?
[23:51:05 CEST] <JEEB> + I hope you are actually storing video in a container
[23:51:17 CEST] <JEEB> because raw video rather rarely has timestamps
[23:51:45 CEST] <jim444> yes. I have timestamp configured as mFrame->pts=++mFrameCounter;
[23:52:14 CEST] <jim444> and storing the encoded frames as .mpg
[23:52:45 CEST] <JEEB> i hope that means you are using a container?
[23:52:53 CEST] <JEEB> an extension doesn't yet mean anything
[23:53:17 CEST] <JEEB> and if you are using a container, which is it? MPEG-PS?
[23:53:55 CEST] <jim444> http://pastebin.com/tcU0HxUs
[23:54:09 CEST] <jim444> Here is how I am writing it in .mpg file.
[23:54:16 CEST] <jim444> sorry, I am very new to this.
[23:55:04 CEST] <JEEB> so you are writing raw mpeg-2 video packets into a file
[23:55:12 CEST] <jim444> yes.
[23:55:17 CEST] <JEEB> that will not have any timestamps
[23:55:28 CEST] <JEEB> 25fps is a default in the standard
[23:55:36 CEST] <JEEB> you will most probably want to stick a libavformat muxer after that
[23:55:48 CEST] <jim444> but when I set fps as 50, the vidoe is played at 50 fps
[23:56:15 CEST] <jim444> how can I use a muxer? Any example/documentation please?
[23:56:30 CEST] <JEEB> see the muxing example under the examples dir under doc
[23:56:40 CEST] <JEEB> or I think there are multiple
[23:57:20 CEST] <JEEB> there's plenty of viable containers and you just choose something that matches your use case
[23:58:57 CEST] <jim444> The only difference between my code and the example muxer.c is ret = av_interleaved_write_frame(oc, &pkt); after calling avcodec_encode_video2()
[00:00:00 CEST] --- Mon Aug 17 2015
1
0