Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2015

1 participants
60 discussions

ffmpeg-devel.log.20150929
by burek 30 Sep '15

30 Sep '15

[00:33:23 CEST] <atomnuker> durandal_1707: yeah, I am [00:34:14 CEST] <atomnuker> laptop broke down just as soon as I got it working so I haven't been able to make comparisons yet [04:45:58 CEST] <cone-198> ffmpeg 03Thierry Foucu 07master:7f72f2d75e58: libavformat/flvdec.c: free always the packet after a resync. [05:02:46 CEST] <cone-198> ffmpeg 03Ganesh Ajjanagadde 07master:b3066be0e460: avcodec/videotoolbox: fix -Wunused-but-set-variable [09:12:08 CEST] <saste_> I dislike the way the GSoC notice is shown on the website [09:17:28 CEST] <fritsch> saste_: impressive tasks [11:36:27 CEST] <saste_> really, are we going to translate the wiki to chinese? ^^ [11:46:45 CEST] <wm4> PHP? wtf [12:18:05 CEST] <blez> hello [12:18:19 CEST] <blez> I get "Unknown Error" using ffmpeg, how can I see what's the actual error? [12:36:24 CEST] <atomnuker> Who wrote this stuff? It's wrong [12:36:41 CEST] <wm4> what stuff [12:36:43 CEST] <wm4> ffmpeg? [12:36:50 CEST] <atomnuker> TNS worked pretty good for low bitrates up until Claudio's RC push broke it [12:37:09 CEST] <atomnuker> (nobody say anything about that, it'll probably delay him another week) [12:37:51 CEST] <atomnuker> whatever, I can't be bothered to care [12:52:50 CEST] <iive> atomnuker: i think you should tell him. [13:05:39 CEST] <durandal_170> atomnuker: can you fix it? [13:06:39 CEST] <durandal_170> btw, you have working machine? [13:28:13 CEST] <superware> I'm playing a live h264 over udp stream, but sometimes (network glitches etc) the stream hangs indefinitely. Restarting ffmpeg continues playback. Since it's very hard to reproduce, I've complied a very messed up stream which reproduces the issue, please see log http://pastebin.com/QuA5nCvQ up to line 229 where is some video, but after that - nothing. [13:41:25 CEST] <cone-619> ffmpeg 03Michael Niedermayer 07master:1b82b934a166: avcodec/x86/sbrdsp: Fix using uninitialized upper 32bit of noise [13:46:02 CEST] <cone-619> ffmpeg 03Rémi Denis-Courmont 07master:b10b6ac7a902: vdpau: deprecate av_vdpau_get_profile() [13:46:03 CEST] <cone-619> ffmpeg 03wm4 07master:a5d58fea68b9: lavc: reimplement avcodec_get_type() using codec descriptors [13:46:04 CEST] <cone-619> ffmpeg 03wm4 07master:cc8db760616a: mpegts: use avcodec_get_type() to set codec_type [13:46:05 CEST] <cone-619> ffmpeg 03wm4 07master:a41e5e192ed8: vdpau: fix constrained baseline fallback [13:46:06 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:b123d82c4182: Merge commit 'b10b6ac7a902f28e09e37a29c392e2f0c19e9526' [13:46:07 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:2f63e83c26f1: Merge commit 'a5d58fea68b9212e0065a71939e921505504a9bb' [13:46:08 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:4b7685b6c626: Merge commit 'cc8db760616a7ec3bd39b22ca45888c01326db13' [13:46:09 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:d0bf83ff1dd3: Merge commit 'a41e5e192ed8f79f6607f978dee3205580ba5039' [13:46:34 CEST] <superware> anyone? :| [13:48:07 CEST] <kierank> use latest ffmpeg [13:48:21 CEST] <cone-619> ffmpeg 03Henrik Gramner 07master:5405584b7b54: checkasm: Use a self-balancing tree [13:48:22 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:fd0fa9af80fe: Merge commit '5405584b7b54ca889c341743de1d58792449830d' [13:48:30 CEST] <kierank> i.e ffmpeg git [13:48:38 CEST] <cone-619> ffmpeg 03Henrik Gramner 07master:cc2855210000: checkasm/x86: Correctly handle variadic functions [13:48:39 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:88dbdf4845e3: Merge commit 'cc285521000020ab237d183dc3a26f99fce3030f' [13:51:19 CEST] <superware> kierank: thanks, tried that, same... [13:51:36 CEST] <kierank> open it in gdb and see where it blocks [13:52:00 CEST] <kierank> I used to get these issues a lot [13:52:35 CEST] <nevcairiel> i think his definition of hang is different, ffmpeg seems to still function, it just doesnt output frames anymore [13:52:47 CEST] <superware> I don't think the code blocks, no video frame is playing after "the event", you can see the log keeps going... [13:52:52 CEST] <kierank> ah [13:52:58 CEST] <kierank> different bug to mine perhaps [13:53:09 CEST] <superware> it's as if a specific packet/frame causes FFmpeg to enter a certain state from which it cannot recover [13:53:13 CEST] <cone-619> ffmpeg 03Anton Khirnov 07master:ae25413daf42: lavfi: do not exclude hwaccel formats from ff_all_formats() [13:53:14 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:c36e85b3d9a1: Merge commit 'ae25413daf42a06f078ed81bb545ec23a8e0b482' [13:54:41 CEST] <superware> the relevant lines from the log: reference count 2 overflow; reference picture missing during reorder; reference count overflow; decode_slice_header error; mmco: unref short failure; number of reference frames (0+2) exceeds max (1; probably corr [13:54:41 CEST] <superware> upt input), discarding one; ... [13:54:48 CEST] <kierank> that's just packet loss errors [13:55:18 CEST] <superware> but it only happens when the issue occurs [13:56:20 CEST] <kierank> anyway run in gdb and get a trace for all the threads where it hangs imo [13:56:21 CEST] <superware> before that the video is very choppy (to non-existent) but none of those are reported [13:56:25 CEST] <kierank> and open a ticket [13:57:42 CEST] <superware> I don't think I have sufficient knowledge to debug ffmpeg h264 [13:57:46 CEST] <DHE> superdump: does 4 minutes, 20 seconds sound like the time before the stream shuts down? or is it more erratic? [13:58:28 CEST] <DHE> (this assumes you're using multicast) [13:59:09 CEST] <superware> superdump is here, but not me :) [13:59:34 CEST] <superware> it happens after 1 minute and 38 seconds. [14:01:41 CEST] <superware> I couldn't reproduce in normal operation, so I recorded the network pcap and discarded half of the packets. [14:02:26 CEST] <DHE> oops [14:03:24 CEST] <superware> now I have a file which I'm playing via PlayCap, ffplay starts playing some very messed up frames, but always stops outputting frames at the same time. restarting ffplay continues with the bad video. [14:04:21 CEST] <DHE> so, half of 4:20.... [14:04:31 CEST] <superware> naa :) [14:04:42 CEST] <DHE> ah, not quite... [14:04:52 CEST] <DHE> sorry it's still early [14:06:06 CEST] <superware> do you know of someone that has h264 experience? [14:06:31 CEST] <DHE> me? [14:07:10 CEST] <durandal_170> superware: could you upload file you give to ffplay? [14:07:25 CEST] <cone-619> ffmpeg 03Anton Khirnov 07master:741b352b16da: qsvdec: list supported pixel formats [14:07:26 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:4554178f072e: Merge commit '741b352b16dad74b87c4a39bade8902633a2b0e6' [14:07:56 CEST] <durandal_170> does it happens with -threads 1? [14:08:07 CEST] <DHE> it sounds to me like you've got a multicast stream that's possible encrypted, and missing an IGMP querier [14:08:37 CEST] <superware> durandal_170: uploading to expirebox.com [14:09:30 CEST] <superware> plus checking -threads 1 [14:10:36 CEST] <superware> http://expirebox.com/download/55e58de3de92c1203dc8a220ea7b1b76.html [14:10:55 CEST] <cone-619> ffmpeg 03Anton Khirnov 07master:83847cc8fa97: qsvenc: do not try to close the encoder if the session is NULL [14:10:56 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:49a25d02ddf6: Merge commit '83847cc8fa97e0fc637a0962bafb837acdb6eacc' [14:12:07 CEST] <superware> durandal_170: -threads 1 didn't help [14:14:04 CEST] <cone-619> ffmpeg 03Anton Khirnov 07master:5d2daebf3cc8: qsvenc: mark the encoders as INIT_CLEANUP [14:14:05 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:66682145216f: Merge commit '5d2daebf3cc8de4cee1973db6a2229beaad3b7cd' [14:14:31 CEST] <cone-619> ffmpeg 03Anton Khirnov 07master:d0c8c380ecf3: qsv: document AVQSVContext members [14:14:32 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:029aa8ff1407: Merge commit 'd0c8c380ecf3d9bb16621a4fb59ebbcde301002a' [14:14:40 CEST] <superware> durandal_170: could you download it? [14:17:21 CEST] <cone-619> ffmpeg 03Anton Khirnov 07master:2c32eace5ec4: qsvdec: close the MFX decoder on uninit [14:17:22 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:9457a11a220c: Merge commit '2c32eace5ec4d1d7ca4e0220856cd2815ccc71b2' [14:17:46 CEST] <cone-619> ffmpeg 03Anton Khirnov 07master:3ee462dca103: examples/qsvdec: do not free the surfaces in the frame_free() callback [14:17:47 CEST] <cone-619> ffmpeg 03Anton Khirnov 07master:539e5ac2ecfe: examples/qsvdec: free the lavc decoder before closing MFX/VAAPI [14:17:48 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:d0a1605134a8: Merge commit '3ee462dca1038e63b8e8d5e751121736d5772a5d' [14:17:49 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:b1284a4b4a6c: Merge commit '539e5ac2ecfec2e2f441222a43fb0583643ea607' [14:19:03 CEST] <durandal_170> superware: downloading it, how I can use it? [14:19:40 CEST] <superware> PlayCap [14:20:39 CEST] <cone-619> ffmpeg 03Anton Khirnov 07master:8aecec84021a: qsvdec: make ff_qsv_decode_init() static [14:20:40 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:27673f1bea1a: Merge commit '8aecec84021a61b943718ff3d7c2c57fcd4af199' [14:24:24 CEST] <cone-619> ffmpeg 03Gregory J. Wolfe 07master:1a4c5fe56008: libopenh264enc: Use av_log() to log messages [14:24:25 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:4d9b78a875b2: Merge commit '1a4c5fe56008c61b0362c75bea5d446dc5b256bc' [14:26:59 CEST] <durandal_170> superware: could you open bug report on tracker? [14:27:41 CEST] <cone-619> ffmpeg 03Luca Barbato 07master:678f788fea33: configure: Set the initial ldflags to match the cflags [14:27:42 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:071f6edb985d: Merge commit '678f788fea3380e5cbbf75baac5cc0ce07a56a42' [14:35:45 CEST] <cone-619> ffmpeg 03Luca Barbato 07master:1016a75cf317: configure: mips: Support mips r6, r2 and r1 [14:35:46 CEST] <cone-619> ffmpeg 03Vicente Olivert Riera 07master:d00bb8addccb: mips: intreadwrite: Only execute that code for mips r1 or r2 [14:35:48 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:c096226ae614: Merge commit '1016a75cf3170648dc9b59fdef170cbfc142f8ad' [14:35:49 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:a2426798d602: Merge commit 'd00bb8addccb63fa3feacb06d2a310731dc0113b' [14:35:56 CEST] <saste_> who's the website maintainer? [14:36:50 CEST] <saste_> there is this annoying margin-top: 180px attribute for h4 elements, how can I fix it? [14:37:33 CEST] <wm4> there is a name I've never seen before in MAINTAINERS for the website [14:38:31 CEST] <nevcairiel> isnt ubitux to blame for the recent redesign [14:38:35 CEST] <nevcairiel> or do i mis-remember [14:39:13 CEST] <ubitux> BBB: i'm sorry i won't have time [14:39:17 CEST] <ubitux> wm4: api, not abi (subtitles) [14:39:20 CEST] <BBB> oh youre still alive! [14:39:23 CEST] <BBB> no problem [14:39:24 CEST] <ubitux> nevcairiel: not really [14:39:24 CEST] <Compn> the html of the website is in ffmpeg-web repo [14:39:31 CEST] <ubitux> nevcairiel: db0 is the author [14:39:41 CEST] <Compn> saste_ : i can commit to ffmpeg-web repo if you have a patch or just tell me what to edit [14:40:12 CEST] <ubitux> grep website MAINTAINERS [14:40:16 CEST] <saste_> Compn, I know where the ffmpeg web repository is [14:40:32 CEST] <saste_> I wanted to ask, is she on IRC? [14:41:12 CEST] <ubitux> she was, seems she hasn't been for a while [14:41:20 CEST] <superware> durandal_170: sure, but I first want to verify it's a real issue, can you please try to reproduce? [14:41:53 CEST] <saste_> there is something about the h4 attribute which is not immediately obvious, I can't grep for top-margin on the local repo [14:43:51 CEST] <ubitux> BBB: yeah, surviving :) [14:44:05 CEST] <BBB> awh :( [14:44:25 CEST] <ubitux> (joking, i'm fine, just heavy load on various aspects) [14:48:21 CEST] <superware> durandal_170? [14:51:53 CEST] <superware> are there several different h264 decoders in ffmpeg? [14:53:22 CEST] <wm4> there's only one, although there are several other wrappers for hw decoding APIs which decode h264 [14:54:20 CEST] <durandal_170> superware: I can't apt-get deps for playcap [14:55:29 CEST] <superware> durandal_170: are you on Windows? [15:08:45 CEST] <BBB> does anyone remember if theres an instruction on x86 (sse2 or so) to move just the higher half of a xmm register from one reg to another, but leave the lower half untouched? [15:09:21 CEST] <BBB> (or move lower half and leave higher bits untouched) [15:10:04 CEST] <BBB> the best I can think of is shufps but Im wondering if theres something better [15:10:09 CEST] <nevcairiel> there is movhlps which moves the high-quadword from origin to the low-quadword of dest, without touching dests high-quadword, but i guess thats not quite what you need [15:11:22 CEST] <nevcairiel> (and the reverse also exists) [15:11:50 CEST] <BBB> right, thats low to high, I need high to high or low to low [15:12:02 CEST] <BBB> shuffling is such a pain on x86 sometimes [15:12:11 CEST] <BBB> too many instructions that do just a small subset of the general thing [15:12:12 CEST] <nevcairiel> movhps can load the high quad from memory [15:12:28 CEST] <nevcairiel> still no good eh? [15:12:39 CEST] <BBB> hehehe right [15:12:42 CEST] <BBB> I want movhps from reg to reg [15:13:01 CEST] <durandal_170> superware: no, ubuntu [15:13:05 CEST] <BBB> punpcklqdq is sort of like movlhps, in fact [15:13:25 CEST] <BBB> but still not what I want [15:16:01 CEST] <cone-619> ffmpeg 03Ganesh Ajjanagadde 07master:d3e5fbb14069: avcodec/apedec: fix undefined left shifts of negative numbers [15:21:28 CEST] <nevcairiel> i think its funny if warning fixes introduce new warnings [15:21:35 CEST] <nevcairiel> someone wasnt very good at fixing [15:21:54 CEST] <wm4> trollol [15:23:19 CEST] <cone-619> ffmpeg 03wm4 07master:948f3c19a8bd: lavc: Make AVPacket.duration int64, and deprecate convergence_duration [15:23:20 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:b01891a9f08b: Merge commit '948f3c19a8bd069768ca411212aaf8c1ed96b10d' [15:23:20 CEST] <superware> durandal_170: is this ok? http://trac.ffmpeg.org/ticket/4893 [15:23:25 CEST] <Daemon404> every valid line of C code produces a warning with some C conpiler [15:23:37 CEST] <nevcairiel> gcc is like our main target [15:23:42 CEST] <martijnb> I thought the challenge was to introduce increasingly obscure warnings until no one can understand it anymore [15:24:02 CEST] <Daemon404> nevcairiel, holds true hetween gcc versions [15:24:09 CEST] <Daemon404> between* [15:26:04 CEST] <BBB> martijnb: mission accomplished! [15:27:35 CEST] <cone-619> ffmpeg 03Ganesh Ajjanagadde 07master:977f41e274a6: mlpdec: Fix a undefined left shift of negative number [15:27:36 CEST] <cone-619> ffmpeg 03Ganesh Ajjanagadde 07master:4885bde3187a: motion_est_template: Fix undefined left shift of negative number [15:27:37 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:cbed8dbb7e1e: Merge commit '977f41e274a66c9d257186ca1df8373a09cc4d40' [15:27:38 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:fe294b34030b: Merge commit '4885bde3187a2bb0cae85b67796e07db233bf77f' [15:29:20 CEST] <cone-619> ffmpeg 03Ganesh Ajjanagadde 07master:84dfc426cea7: avresample: Remove an unused variable [15:29:21 CEST] <cone-619> ffmpeg 03Vittorio Giovara 07master:cf7d2f2d2134: lavc: Simplify checking quant bias option [15:29:23 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:24fea8998375: Merge commit '84dfc426cea7242099aea9d47121cea65dffd936' [15:29:24 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:773570a9dce9: Merge commit 'cf7d2f2d2134c0854edf2db91e7436ac2bc9874f' [15:30:34 CEST] <cone-619> ffmpeg 03Vittorio Giovara 07master:3973f0f773e0: Revert "avconv_opt: Allow printing private options" [15:30:35 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:e490fee6b971: Merge commit '3973f0f773e0bd212734eccda78aa798f8b20692' [15:30:55 CEST] <BBB> nevcairiel: hey since you know x86 asm, can you review my loopfilter 10/12bpp vp9 patch? [15:31:02 CEST] <BBB> nevcairiel: much more exciting than hevc [15:31:06 CEST] <cone-619> ffmpeg 03Vittorio Giovara 07master:b5e4f393b675: avconv: Make the private options discovery more manifest [15:31:07 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:7255cf003ef1: Merge commit 'b5e4f393b6757629281f58c3f3f6d55ca522ab60' [15:31:19 CEST] <nevcairiel> i know basic asm/simd, but my brain always starts to hurt when i try to understand complex algorithms [15:31:41 CEST] <BBB> loopfilter is very simple [15:31:51 CEST] <BBB> you just close your eyes and imagine pink flying ponies [15:31:54 CEST] <BBB> thats a loopfilter [15:36:25 CEST] <cone-619> ffmpeg 03Thierry Foucu 07master:c5e5e6306223: riff: Add support for RV40 codec in AVI [15:36:26 CEST] <cone-619> ffmpeg 03Christophe Gisquet 07master:c49cbecbae5a: dnxhddec: Decode and use interlace mb flag [15:36:27 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:b3bf41cb75d4: Merge commit 'c5e5e6306223623de8352a3ecd224956aa5beb37' [15:36:28 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:1342d7b2f941: Merge commit 'c49cbecbae5a42f4ca004197b0118cc50aaaca2e' [15:37:41 CEST] <ubitux> ffmpeg -ss 30 -f lavfi -i testsrc -ss 20 -t 10 -y out.avi 50 60 [15:37:43 CEST] <ubitux> ffmpeg -ss 30 -f lavfi -i testsrc -ss 20 -to 60 -y out.avi 50 90 [15:37:46 CEST] <ubitux> is this a wanted behaviour? [15:38:34 CEST] <cone-619> ffmpeg 03Vittorio Giovara 07master:e94e651c762f: dnxhddec: Enable frame threading [15:38:35 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:b03260fde08c: Merge commit 'e94e651c762f90ac5fd2dc9bd3ba1336a77d5b5c' [15:44:27 CEST] <cone-619> ffmpeg 03Vittorio Giovara 07master:c9943f00cfa2: vf_framepack: Use av_image_copy() where appropriate [15:44:28 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:f35c4ede9e0e: Merge commit 'c9943f00cfa2471d1b8a3a9ddc7a21049a71090e' [15:45:09 CEST] <cone-619> ffmpeg 03Vittorio Giovara 07master:26e8fa3b508e: tiny_psnr: Use the correct abs() version [15:45:10 CEST] <cone-619> ffmpeg 03Hendrik Leppkes 07master:fc97b1f091ff: Merge commit '26e8fa3b508eb047e85f4e923fc8e82a1aa656ba' [15:45:32 CEST] <nevcairiel> BBB: i'll give it a look, but i cant promise much [15:46:12 CEST] <BBB> nevcairiel: well, more generally, Im looking for someone tor review anything assembly at all [15:46:22 CEST] <BBB> Ill have a few more coming up and nobodys reviewing, which kind of sucks [15:47:05 CEST] <durandal_170> I just commit what nobody reviews [15:51:58 CEST] <saste_> ubitux, are you optimizing testsrc or what? [15:52:31 CEST] <ubitux> saste_: no, just wondering about the inconsistency between -t and -to [15:52:42 CEST] <superware> is cehoyos here? [15:52:50 CEST] <Daemon404> not usually [15:53:08 CEST] <superware> ok [16:29:50 CEST] <nevcairiel> getting rid of the convergence_duration hackery from my own code sure made my feel good [16:29:56 CEST] <nevcairiel> s/my/me/ [16:33:45 CEST] <wm4> oh it's already in? [16:34:13 CEST] <nevcairiel> an hour ago or so [16:47:32 CEST] <BBB> I never understood why convergence_duration was introduced [16:47:50 CEST] <nevcairiel> i think it was introduced for something else entirely [16:48:00 CEST] <nevcairiel> it was then abused as a 64-bit duration field for subtitles [16:48:03 CEST] <BBB> it seemed like somebody mistook a doxy comment for abi [16:48:23 CEST] <BBB> hm, ok [16:48:34 CEST] <nevcairiel> the comment still states its original concept [16:48:40 CEST] <nevcairiel> or well used to until it was removed [16:48:54 CEST] <Paranoialmaniac> i though it is used for gradual decoder refresh but... [16:49:06 CEST] <nevcairiel> thats what it kinda was for [16:49:18 CEST] <nevcairiel> time until the stream "converges", ie. when the refresh is done [16:49:25 CEST] <nevcairiel> but it was never used for that [17:24:37 CEST] <Gramner> BBB: for merging parts of registers; shufps with SSE, pblendw/blendps with SSE4.1, vpblendd with AVX2 [17:24:49 CEST] <BBB> ah, blend [17:24:54 CEST] <BBB> ok, this is sse2 targetted, so shufps it is [17:24:56 CEST] <BBB> ty [17:25:20 CEST] <Gramner> in AVX-512 you can use an opmask blend with every instruction as well [17:25:52 CEST] <durandal_1707> BBB: I want to write simd for maskedmerge filter [17:26:54 CEST] <BBB> Gramner: uh ok that sounds a little overkill [17:26:58 CEST] <BBB> typically intel I guess [17:27:13 CEST] <BBB> durandal_1707: algo desc in C? and did you dspize the function? [17:27:32 CEST] <BBB> (i.e. put it in a blaDSPContext in its own file with a nice header etc., and write a checkasm test, etc.) [17:28:09 CEST] <durandal_1707> not yet [17:28:56 CEST] <BBB> px1*weight+px2*(1-weight)? [17:29:00 CEST] <BBB> (in fixed point) [17:29:07 CEST] <Gramner> I'd say it's typical intel to invent this completely new backwards-incompatible future-proof instruction encoding called VEX (AVX), just to replace it again a few years later with EVEX. as a matter of fact, they had probably dropped VEX internally before hardware using it was even released to the general public [18:41:43 CEST] <nevcairiel> so much for future proof =p [18:53:34 CEST] <wm4> is anyone against applying that videotoolbox patch from Stefano Pigozzi? [18:59:52 CEST] <TheRyuu> https://sourceware.org/bugzilla/show_bug.cgi?id=19011 <---do my eyes decieve me, sanity from gnu? [19:01:46 CEST] <Gramner> TheRyuu: nice [19:03:18 CEST] <JEEB> wow [19:03:44 CEST] <TheRyuu> he's gonna be sad when it's a patch series though (if I do it) [19:05:37 CEST] <cone-619> ffmpeg 03Michael Niedermayer 07master:ed18c49f5ff8: fate: Add basic license header check [19:07:41 CEST] <jamrial> ^ i'd say tools/patcheck is the proper way to check this and not fate, but it wouldn't work for libav merges which is the source of the wrong headers, so guess it's ok [19:10:41 CEST] <wm4> fate now tests source code too! [19:11:36 CEST] <wm4> (I think someone wants to force someone else to change the project name on merges?) [19:14:37 CEST] <durandal_1707> thats ok [19:16:42 CEST] <durandal_1707> ubitux: is it ok to have assumefps? [19:24:02 CEST] <DHE> there, hopefully that'll be the last revision of the a53 CC patch [19:35:32 CEST] <cone-619> ffmpeg 03PrzemysBaw Sobala 07master:01dd7e025c24: lavf/img2dec: Fix memory leak [19:49:38 CEST] <cone-619> ffmpeg 03Ganesh Ajjanagadde 07master:308e7484a3b1: avcodec/x86/rnd_template: silence -Wunused-function on --disable-mmx [20:09:35 CEST] <ubitux> durandal_1707: what is it? [20:13:02 CEST] <durandal_1707> changes fps and pts without dropping or adding frames [20:25:55 CEST] <ubitux> durandal_1707: what would be the difference with setpts? [20:26:39 CEST] <durandal_1707> setpts changes framerate? [20:27:12 CEST] <ubitux> no because of the expression i guess [20:28:01 CEST] <ubitux> what field are we talking about? [20:28:07 CEST] <ubitux> we have a link->framerate or sth? [20:29:38 CEST] <durandal_1707> frame_rate [20:30:02 CEST] <ubitux> just add a setframerate filter maybe [20:30:11 CEST] <ubitux> that just changes this field [20:30:30 CEST] <ubitux> but well, then adding a setpts filter would be annoying [20:30:43 CEST] <ubitux> yeah well, dunno, no opinion [20:32:26 CEST] <durandal_1707> setfps is shorter [20:48:00 CEST] <wm4> why are the old vdpau hwaccels (h264_vdpau etc.) still not gone? [20:53:58 CEST] <durandal_1707> nobody removed them [20:59:02 CEST] <cone-619> ffmpeg 03Paul B Mahol 07master:a01914924969: avfilter/vf_atadenoise: do not use uninitialized data [21:13:22 CEST] <iive> somebody said that libav have delayed ff_api_vdpau once again, so we are doing that too. [21:13:56 CEST] <nevcairiel> welcome to 4 weeks ago [21:14:41 CEST] <nevcairiel> the deprecation just isnt that old yet [21:17:13 CEST] <wm4> Libav have removed these codecs ages ago [21:17:23 CEST] <wm4> what they didn't remove are some API symbols [21:17:25 CEST] <durandal_1707> JEEB: tried zscale? [21:17:38 CEST] <BBB> wm4: I believe the deprecation works functionally, so if you dont like that feature, just use -DFF_API_blabla=0 as extra-cflags=..; configure arg [21:17:41 CEST] <wm4> (like CODEC_CAP_HWACCEL_VDPAU) [21:18:11 CEST] <JEEB> durandal_1707: I did before, I should test a newer version [21:18:11 CEST] <wm4> but hey lets keep this crap because we're so misinformed! [21:19:04 CEST] <nevcairiel> noone intentionally prolonged its life, but noone send a patch to remove it either [21:19:13 CEST] <nevcairiel> someone put it under the same deprecation guards as the API [21:19:16 CEST] <nevcairiel> so now its tied to it =p [21:19:48 CEST] <wm4> how about a patch that removes the implementation [21:19:58 CEST] <wm4> or is going through pointless untested ifdeffery mandatory [21:22:16 CEST] <nevcairiel> its a decoder, the existance of a decoder is not API [21:23:29 CEST] <wm4> so I'll send a patch to remove them tomorrow (without the API) [21:23:38 CEST] <wm4> and then it'll get rejected and I'll be angry [21:24:07 CEST] <durandal_1707> JEEB: its always much slower than swscale [21:24:32 CEST] <durandal_1707> wm4: voting! [21:24:51 CEST] <BtbN> Hm, should I just merge the OpenCL stuff I made? Nobody seems to care. [21:25:23 CEST] <durandal_1707> fix keyspill [21:25:41 CEST] <BtbN> I'm thinking about putting that into an entirely seperate filter [21:25:56 CEST] <BtbN> As it's also usefull without chroma/colorkey [21:26:15 CEST] <durandal_1707> ok [21:26:24 CEST] <JEEB> durandal_1707: the idea wasn't really to be faster than swscale, rather being a more correct but still fast thing [21:26:27 CEST] <JEEB> http://up-cat.net/p/9b8d5c6b [21:26:39 CEST] <JEEB> it seems like there's more SIMD now [21:27:07 CEST] <durandal_1707> but results on doom9 are paradise [21:28:38 CEST] <durandal_1707> I test bilinear only [21:37:11 CEST] <cone-619> ffmpeg 03Carl Eugen Hoyos 07master:98ed0716fb79: lavf/rawenc: Force one stream for hevc and m4v. [21:40:46 CEST] <jamrial> BtbN: if the opencl maintainers didn't comment and noone else knows much about that stuff, then go ahead i guess [21:41:11 CEST] <BtbN> I think i'll ping it once again, and directly CC the maintainer(s) [21:43:13 CEST] <BtbN> Great, there's a name and a GnuPG Fingerprint, but no E-Mail. [21:44:35 CEST] <nevcairiel> wasnt there a mail in the license on top of the generic opencl header [21:44:59 CEST] <BtbN> ah, right [21:45:03 CEST] <BtbN> 4 E-Mails [21:46:51 CEST] Action: ubitux smiles to nevcairiel [21:47:57 CEST] <nevcairiel> i'm sure he'll find some obscure reason to still protest [21:48:52 CEST] <ubitux> no i don't think so :) [22:17:42 CEST] <jamrial> nevcairiel: derp, i thought i was replying to the license header email and not a new one about typos [22:17:53 CEST] <jamrial> yeah, typo check on fate is silly [22:18:38 CEST] <nevcairiel> I honestly don't even care a single bit about typos in comments [22:18:48 CEST] <nevcairiel> and having fate break because of that? please. [23:55:23 CEST] <cone-619> ffmpeg 03Stefano Pigozzi 07master:78cc19f15ead: videotoolbox: require hardware acceleration [00:00:00 CEST] --- Wed Sep 30 2015

1 0

ffmpeg.log.20150929
by burek 30 Sep '15

30 Sep '15

[00:29:08 CEST] <votz> How can ffmpeg be instructed to stop stream copying at a keyframe? -ss before -i seeks to a keyframe and thus starts at a keyframe. What's the analog to stop at a keyframe? [00:34:16 CEST] <waressearcher2> it should stop automatically, no ? at a nearest keyframe [00:40:19 CEST] <votz> waressearcher2: unless I'm mistaken, it does not. [03:33:40 CEST] <benzrf> hey! [03:33:53 CEST] <benzrf> i have an mkv file that references another mkv file (two actually) [03:34:01 CEST] <benzrf> is there a way to 'compile' them together into a single file? [03:34:13 CEST] <benzrf> preferably without even any muxing; i just want to be able to serve it [03:36:16 CEST] <benzrf> wait, 'muxing' is the wrong word there isnt it. ugh [03:36:59 CEST] <klaxa> you can use mkvmerge for that: mkvmerge -o output.mkv input1.mkv + input2.mkv [03:37:16 CEST] <klaxa> you can also use ffmpeg's concat demuxer: https://trac.ffmpeg.org/wiki/Concatenate [03:37:26 CEST] <benzrf> cool, thanks! [03:37:52 CEST] <klaxa> i'm not sure if you can do it based on references (do you mean chapters perhaps?) [03:38:20 CEST] <benzrf> as in, playing it with mpv says: [03:38:22 CEST] <benzrf> This file references data from other sources. [03:38:24 CEST] <benzrf> Will scan other files in the same directory to find referenced sources. [03:38:53 CEST] <klaxa> ah [03:40:37 CEST] <benzrf> hmm [03:41:25 CEST] <benzrf> augh [03:42:00 CEST] <benzrf> klaxa: any ideas? [03:42:04 CEST] <c_14> You can use the mkvmerge gui [03:42:16 CEST] <c_14> Open the "main input" and then append all other files. [03:42:20 CEST] <c_14> Then just mux to a new output [03:42:39 CEST] <benzrf> :| [03:42:40 CEST] <c_14> Don't have to worry about order since the virtual timeline will get that. [03:42:42 CEST] <benzrf> i dont know this stuff [03:43:00 CEST] <c_14> Install mkvtoolnix [03:43:02 CEST] <benzrf> done [03:43:06 CEST] <benzrf> already had it :} [03:43:08 CEST] <c_14> open the mkvmerge gui [03:43:16 CEST] <benzrf> oh, well. the gui version is installing :p [03:43:33 CEST] <benzrf> kk [03:43:56 CEST] <benzrf> er, what's the command for the gui [03:44:02 CEST] <c_14> mkvmerge-gui iirc [03:44:09 CEST] <benzrf> not in my PATH [03:45:15 CEST] <c_14> What distro? [03:45:43 CEST] <benzrf> well, my laptop is arch, but tbh i was hoping to merge the files on my VPS (which is ubuntu) [03:45:49 CEST] <benzrf> however i'm having trouble with x forwarding [03:45:51 CEST] <benzrf> :>>>> [03:45:57 CEST] <benzrf> ~funtimes~ [03:46:30 CEST] <c_14> According to what I'm reading, what klaxa mentioned earlier with regards to mkvmerge -o output.mkv input.mkv + input2.mkv etc should work [03:46:35 CEST] <benzrf> oh, is the + critical? [03:46:37 CEST] <benzrf> :| [03:46:39 CEST] <c_14> yes [03:46:43 CEST] <benzrf> what does it mean [03:46:55 CEST] <c_14> A single '+' causes the next file to be appended instead of added. [03:47:25 CEST] <benzrf> what's the difference? [03:47:37 CEST] Action: benzrf really needs to brush up on how media files work [03:47:51 CEST] <klaxa> if you add the file, both files start at timestamp 0 [03:47:58 CEST] <klaxa> and you can switch between them in your player [03:48:00 CEST] <c_14> All streams, anyway. [03:48:00 CEST] <benzrf> ooh [03:48:21 CEST] <klaxa> if you append a file, the second file starts at the timestamp when the first file ends [03:48:29 CEST] <c_14> Unless there's a virtual timeline. [03:48:35 CEST] <klaxa> that's wha the + does [03:48:45 CEST] <c_14> Well, if the virtual timeline mentions the files to be appended. [03:48:52 CEST] <benzrf> did not work :\ [03:48:59 CEST] <c_14> What did it output? [03:49:49 CEST] <benzrf> Warning: The track number 1 from the file '<referenced file>' can probably not be appended correctly to the track number 1 from the file '<main file>': The codec's private data does not match (lengths: 8491 and 67880). Please make sure that the resulting file plays correctly the whole time. The author of this program will probably not give support for playback issues with the resulting file. [03:49:55 CEST] <benzrf> and a similar error for 2 [03:50:20 CEST] Action: c_14 is installing mkvtoolnix on his system and will test with some of his files [03:50:20 CEST] <benzrf> when i say 'did not work' i mean i opened it and it didnt work btw [03:50:37 CEST] <benzrf> screw it ill just find another source for the media that doesnt do references [03:50:39 CEST] <benzrf> ;-; [03:50:58 CEST] <klaxa> can you run mkvinfo on all of the files and pastebin it? [03:51:13 CEST] <klaxa> and maybe ffprobe too (for good measure?) [03:51:26 CEST] <benzrf> th-that sounds like it might be work [03:51:47 CEST] <klaxa> ok, well you can also just re-encode the file [03:51:52 CEST] <klaxa> that will degrade quality though [03:51:55 CEST] <klaxa> and take some time [03:52:38 CEST] <benzrf> rip [03:53:18 CEST] Action: benzrf finds an alternate source [03:53:20 CEST] <benzrf> thanks anyway [03:54:01 CEST] <klaxa> c_14: where do i find documentation about virtual timelines? i did not find it on matroska.org? [03:54:36 CEST] <c_14> http://www.matroska.org/technical/specs/chapters/index.html [03:54:49 CEST] <c_14> Though reading the manpage is better. [03:54:53 CEST] <c_14> Not quite as technical. [03:54:56 CEST] <klaxa> ah [03:55:00 CEST] <klaxa> thanks [03:55:49 CEST] <klaxa> wait, which manpage? [03:56:10 CEST] <c_14> The mkvmerge one [03:56:17 CEST] <c_14> Has a really big section on linking [03:56:42 CEST] <c_14> Though it mainly goes into syntax. [07:11:47 CEST] <pinPoint> anyone here write a gui front end to run with ffmpeg. [11:04:18 CEST] <blez> hello [11:04:36 CEST] <blez> I have this: ffmpeg -re -loop 1 -i test.jpg -r 10 -vcodec mpeg4 -f mpegts udp://127.0.0.1:1234 [11:04:51 CEST] <blez> I've tried to open udp://127.0.0.1:1234 with vlc to test, but nothing happened [11:04:55 CEST] <blez> I wonder what's the problem [11:06:14 CEST] <termos> are there any benchmarks running ffmpeg on multi-core arm cpus? [11:20:44 CEST] <blez> someone? [11:42:31 CEST] <iive> blez: doesn't loop 1 repeat the frame just once? [11:42:59 CEST] <quovadis> Hi, I'm struggling converting rgb565 to gray: "-f rawvideo -pixel_format rgb565 -video_size 480x480 -i tex.565 -f rawvideo -pixel_format gray test.raw" any help ? [11:43:00 CEST] <iive> hum,, no, i'm wrong, sorry [12:15:24 CEST] <blez> iive no [12:15:33 CEST] <blez> but the problem seems different [12:15:42 CEST] <blez> when I try to use http:// I get "unknown error" [12:40:05 CEST] <satiender> Hi , is there any why generate a C code for video encoding [12:42:33 CEST] <satiender> ?? [12:42:43 CEST] <satiender> any one can help for that [12:42:47 CEST] <satiender> please ?? [13:24:59 CEST] <superware> I'm playing a live h264 over udp stream, but sometimes (network glitches etc) the stream hangs indefinitely, while restarting ffmpeg continues playback. Since it's very hard to reproduce, I've made a very messed up stream which can reproduce the issue, please see http://pastebin.com/QuA5nCvQ line 229 seems to start the whole mess :) [13:29:21 CEST] <voice> udp as the input? [13:31:22 CEST] <superware> ffplay udp://192.168.19.121:40002 [13:31:24 CEST] <superware> yes [13:32:13 CEST] <voice> I know I had problems with a UDP stream until I added ?fifo_size=1000000&overrun_nonfatal=1 to the end of the udp url [13:32:49 CEST] <superware> let me check [13:35:50 CEST] <superware> :( same, ffplay udp://192.168.19.121:40002?fifo_size=1000000&overrun_nonfatal=1 [13:46:44 CEST] <superware> voice: any other ideas? [13:47:00 CEST] <voice> not off the top of my head unfortunately [13:48:34 CEST] <superware> it's as if a specific packet/frame causes FFmpeg to enter a certain state from which it cannot recover [13:49:52 CEST] <voice> all I know is with that url addon instead of a full quit I get a second or two freeze [13:50:48 CEST] <superware> I guess my issue is more esoteric [13:51:37 CEST] <voice> http://pastebin.com/pcRKbZZq that is what command my streaming script is using [14:09:06 CEST] <DHE> ah, so it's not multicast then... [14:12:19 CEST] <blez> I can't stream to http... [14:12:47 CEST] <blez> ffmpeg -re -loop 1 -i test.jpg -r 10 -v 1 -f mp4 http://localhost:8787/test.mp4 // gives unknown error [15:17:56 CEST] <Nolski> .close [15:46:53 CEST] <xerox> Mavrik, DHE, thanks for the help the other day, by using your suggestions I have been able to achieve 43% of the original file size of my very still-image-y high res videos! I wonder if I can do even better, right now I'm using --preset slow --tune stillimage -qmax 30. Maybe lower the number of bframes? [15:47:39 CEST] <DHE> if you're going for better compression, bframes are a good thing. [15:48:45 CEST] <taolei> Hi, all. If I want to keep input's format unchanged, must I first know the format and use -f xxx to set output format? Can ffmpeg keep original format automatically? [15:48:46 CEST] <xerox> oh right, the opposite then, have more of them, they are the most compressed ones [15:49:53 CEST] <DHE> if you keep the same file extension then you should get the same container [15:52:09 CEST] <xerox> DHE: what could be a good number to try? [15:52:52 CEST] <mustafam> Hi, I want to capture using vlc and pipe raw video to ffmpeg, is this possible? thanks [15:53:25 CEST] <DHE> xerox: I believe 2 to be the most common option especially in broadcast, though the codec permits up to 15 [15:59:37 CEST] <xerox> bframes=10:b-adapt=2 fun for all the family :D [16:00:22 CEST] <taolei> Hi, DHE, the input is a stream, so there is no file extension. I want to record this stream and save to a file, is it possible to use the stream's format as the file's format automatically? [16:02:09 CEST] <obiwahn> i am am recording a video and i wonder what i need to to in order to improve the quality of the video a bit [16:02:23 CEST] <obiwahn> at the moment i use the following commandline: [16:02:35 CEST] <obiwahn> ffmpeg -f x11grab -y -s "1920"x"1200" -i :0.0+0,0 -framerate 25 ~/video1.mkv [16:03:50 CEST] <obiwahn> the image is a bit slushy (matschig) [16:04:56 CEST] Action: taolei slaps taolei around a bit with a large trout [16:05:38 CEST] <maldo> Hey. First time around here. I am streaming differents MP3 files publishing with ffmpeg. When a mp3 finish, the next one starts. I just want to know if it is possible to MIX the next audio file and fade out the finihing one and fadein the starting one. I guess not, but maybe something to explore... [16:06:06 CEST] <maldo> Im publishing to a RTMP point. [16:17:28 CEST] <durandal_170> maldo: afade, acrossfade filter [16:17:37 CEST] <maldo> mmmmmmmm [16:17:40 CEST] <maldo> GREAT [16:17:42 CEST] <maldo> thanks [17:37:31 CEST] <keyser7654> Hello! Are libavcodec API questions welcome here? [17:45:54 CEST] <DHE> yes [17:48:01 CEST] <keyser7654> I am decoding live rtp with H264 content and due to network packet loss i sometimes get the error: 'decode_slice_header error'. avcodec_decode_video2 does categorize this as a real error and returns a non negative value and a decoded frame. [17:48:51 CEST] <keyser7654> how do I capture that error programatically? I can see it in my log callback, but at that stage I do not know exactly which decode context it is in reference to. [17:49:25 CEST] <keyser7654> clarifcation: avcodec_decode_video2 does NOT mark this as error [17:50:27 CEST] <keyser7654> using ffmpeg 2.7 and libx264 [19:09:10 CEST] <kyleogrg> hey [19:11:12 CEST] <kyleogrg> so i am using a build helper to cross-compile ffmpeg for windows. i can use the option "--disable-nonfree=n" to "include nonfree like libfdk-aac." Do you know how I might include AAC HE as well? [20:11:45 CEST] <Axydlbaaxr> Is anyone around? [20:13:26 CEST] <durandal_1707> nobody, just you [20:16:45 CEST] <ptomblin> My video camera records in "MOV" format, but breaks it up into chunks. I want to make a single file for input into Garmin VIRB Edit. [20:17:12 CEST] <ptomblin> I've tried most of the ideas in https://trac.ffmpeg.org/wiki/Concatenate and most of them don't give me audio. [20:17:30 CEST] <ptomblin> http://pastebin.com/yjTFcc18 and http://pastebin.com/RXUq9r5E [20:18:00 CEST] <ptomblin> I've also tried the mmcat script but it takes 12 hours to process 1.5 hours of video. [20:19:12 CEST] <Axydlbaaxr> Does anyone know how to set up ffserver so that it streams a video file as if it were live, so that clients connecting to it will get the video already in progress instead of from the beginning? [20:19:57 CEST] <BtbN> ptomblin, remux to mpeg-ts first, and then use a concat list. [20:20:21 CEST] <ptomblin> Isn't that what I'm doing in http://pastebin.com/yjTFcc18 [20:20:27 CEST] <ptomblin> ? [00:00:00 CEST] --- Wed Sep 30 2015

1 0

ffmpeg-devel.log.20150928
by burek 29 Sep '15

29 Sep '15

[01:15:29 CEST] <cone-328> ffmpeg 03Christophe Gisquet 07master:235381e674bf: dnxhddec: use unsafe bitstream reader [02:33:28 CEST] <atomnuker> god damn it my commts have been bitrotting for so long I started writing an af_ssim [02:35:23 CEST] <jamrial> we don't have that already? [02:35:36 CEST] <jamrial> oh, vf_ssim [05:22:33 CEST] <Zeranoe> Is it worthwhile to include kvazaar in the Windows builds? [05:35:50 CEST] <jamrial> not if you include x265 [09:25:40 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:691a7df3c5b7: avfilter: add maskedmerge filter [09:25:40 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:238ca2d72360: doc/filters: move mcdeint above mergeplanes [10:01:00 CEST] <cousin_luigi> Greetings. [10:24:53 CEST] <cone-210> ffmpeg 03Alex Smith 07master:a58c22d61260: configure: Support for HEASLR on mingw targets [12:39:24 CEST] <cone-210> ffmpeg 03Christophe Gisquet 07master:6110a55b7d0d: dnxhddec: reindent/cosmetics [12:50:30 CEST] <cone-210> ffmpeg 03Christophe Gisquet 07master:578f721f5dcf: dnxhddec: add my contributions [13:12:00 CEST] <wm4> BBB: so where do we get a fast vp9 encoder? [13:13:22 CEST] <av500> wm4: "google" for it [13:13:25 CEST] Action: av500 hides [13:14:44 CEST] <wm4> google only has a slow one [13:20:21 CEST] <BBB> you copy some concepts from ffvp9, you put a few competent devs together that understand the spec + understand performance, you shake it and wait two years [13:20:21 CEST] <BBB> ... [13:20:22 CEST] <BBB> ? [13:21:21 CEST] <nevcairiel> judging from BBB's presentation, its not that slow anymore, you can get like 30% quality over x264 at same speed or something? [13:21:34 CEST] <BBB> thats still slow [13:21:55 CEST] <BBB> the decoder is _faster_ than (ff)h264 [13:22:03 CEST] <J_Darnley> Would that be at x264's veryfast or veryslow? [13:22:03 CEST] <nevcairiel> it could do with proper threading [13:22:03 CEST] <BBB> why isnt the encoder faster (and 50% better in quality)? [13:22:36 CEST] <BBB> they all use threading [13:22:41 CEST] <BBB> I think people overthink threading [13:22:49 CEST] <BBB> threading just shares equal workload over two cpus [13:22:56 CEST] <BBB> it doesnt decrease workload in any significant way [13:23:00 CEST] <Compn> is ffh264 still slower at single core decoding than coreavc ? [13:23:04 CEST] <nevcairiel> x264 can use all my cores, if vpxenc cant do that, its not threaded properly [13:23:10 CEST] <BBB> true [13:23:22 CEST] <BBB> so that needs fixing (it does, Im aware of several threading issues in libvpx) [13:23:36 CEST] <BBB> but the more interesting thing (academically speaking) is why we are not 50% better at same speed than x264 [13:23:46 CEST] <BBB> the decoder stats suggest thats possibly, at same-quality at least [13:23:58 CEST] <nevcairiel> because new encoding magic also needs CPU to analyze the image more? [13:24:09 CEST] <BBB> apparently not that much [13:24:32 CEST] <BBB> if vp9 _de_coding is faster than hevc, why isnt _en_coding also at all speed settings? [13:24:35 CEST] <BBB> its a little, but not much [13:24:38 CEST] <BBB> it should be a lot more [13:24:59 CEST] <J_Darnley> Here's the obvious answer: there is not a bunch of people working hard to see their hardwork become the best encoder [13:25:06 CEST] <nevcairiel> i think extrapolating encoding performance scaling based on the decoder is a bit far fetched [13:25:38 CEST] <BBB> nevcairiel: maybe, but you should target it at least [13:25:45 CEST] <nevcairiel> give an encoder a long list of different modes to consider, it has to test them all to some degree, while the decoder just gets told which mode to use and apply [13:25:57 CEST] <BBB> nevcairiel: heres another way of saying the same thing: the line of vpx/x265 hould always be parallel to the x264 line, just shifted up/left [13:26:04 CEST] <nevcairiel> so more modes, slower encoder, while d ecoder doesnt change [13:26:16 CEST] <BBB> if it ever moves towards the x264 line in diagonally decreasing distance, it means were worse than x264 at that point [13:26:21 CEST] <BBB> (relative to previous points) [13:27:05 CEST] <BBB> more practically speaking, x264 does some pretty cool magic in its mode selection which vpx doesnt do [13:27:10 CEST] <BBB> so theres a lot of opportunity for improvement [13:27:34 CEST] <BBB> example: x264 has analyze; vpx simply turns of all non-h/v/dc/tm modes at 16x16/32x32 at speed>=1 [13:27:50 CEST] <nevcairiel> you could probably expect small gain at same performance, but expecting the full 50% promised gain at same encoding performance seems a bit out there, imho at least [13:27:51 CEST] <BBB> thats sort of the general story of comparing these two encoders [13:27:59 CEST] <nevcairiel> not to say that vpx already did all that it could [13:28:04 CEST] <nevcairiel> but x264 is also a decade older, more or less [13:28:08 CEST] <BBB> the taget should be 50% [13:28:12 CEST] <BBB> you might never get there [13:28:20 CEST] <BBB> but (esp. for x265) 10% is embarassing [13:28:30 CEST] <BBB> and after that it actually itnersects [13:28:36 CEST] <BBB> thats terrible [13:29:16 CEST] <BBB> again, what Im primarily after is shapes of the second graph being equal [13:29:33 CEST] <BBB> so the goal should be that the lines never get closer together as the speed target moves up, idealistically speaking [13:29:55 CEST] <BBB> and the vpx line almost touches upon the x264 line, and the x265 line actually intersects with it [13:30:02 CEST] <BBB> thats terrible, and means lots of work left to do [13:30:31 CEST] <BBB> if we cant improve that, it means the new codecs arent that great after all, and it means we need to change our codec research groups to include speed research in addition to quality research [13:30:49 CEST] <BBB> (or alternatively, face the risk of the new codec not being picked up by companies) [13:31:53 CEST] <BBB> or beg intel to reinstate moores law? [13:32:39 CEST] <nevcairiel> not every use case really cares, if i'm authoring a UHD Blu-ray I might simply not care, i have tons of bitrate and tons of time, while a broadcaster probably uses a real-time encoder, which is a different beast entirely and probably often hardware [13:32:45 CEST] <nevcairiel> that leaves youtube and the likes [13:33:11 CEST] <BBB> true [13:33:30 CEST] <BBB> like I said in my blogpost, its written for the example scenario of youtubeish types [13:33:42 CEST] <BBB> netflix is indeed very different [13:34:42 CEST] <nevcairiel> hevc is still young, and as it matures hopefully both encoder and decoder get faster [13:34:46 CEST] <BBB> the sad thing is that at high bitrates, the diff between old/new codecs goes down in most cases I looked at :( [13:35:03 CEST] <BBB> so then the bluray savings go down also [13:35:12 CEST] <nevcairiel> for 4k there is still quite some difference [13:35:16 CEST] <nevcairiel> from bigger blocks alone [13:35:29 CEST] <BBB> yeah, my example here is 1080p, so it helps a fair bit [13:35:45 CEST] <BBB> but not as much already, I guess it depends on the complexity of the content, but it decomposes a lot at high bitrates [13:35:52 CEST] <BBB> unless the area is highly static [13:36:15 CEST] <nevcairiel> its the same reason why noone cares that the commercial h264 encoders used for Blu-rays are all crap [13:36:16 CEST] Action: Daemon404 notes the comments on BBB's blog post show a lot of misinformation / failure to interpret the post still around [13:36:20 CEST] <nevcairiel> let them waste bits, who cares [13:36:48 CEST] <cone-210> ffmpeg 03Jean Delvare 07master:3e5b02bdb8e5: avfilter/delogo: Fix show option when band is small [13:36:54 CEST] <BBB> Daemon404: well, thats why we discuss it, right? :) [13:37:17 CEST] <BBB> nevcairiel: well, I guess thats the interesting thing - companies can save a lot of money (yes, $$$) on this [13:37:23 CEST] <Daemon404> BBB, mostly its the normal stuff [13:37:29 CEST] <Daemon404> like "BTU GPU ENCODING" [13:37:31 CEST] <Daemon404> and whatnot [13:37:33 CEST] <Daemon404> BUT* [13:37:45 CEST] <fritsch> Are there any VP9 gpu encoders already? And if yes - which parts can they accelerate that much so that they outperform cpu? [13:38:06 CEST] <BBB> Daemon404: comments where? my blog has 0 comments [13:38:06 CEST] <nevcairiel> there arent even any non-vpx cpu encoders [13:38:14 CEST] <Daemon404> BBB, hacker news and reddit [13:38:47 CEST] <fritsch> BBB: i sent you an email :-) did not trust myself to comment [13:38:59 CEST] <BBB> fritsch: yes, thanks for that [13:39:01 CEST] <fritsch> nevcairiel: cpu / gpu? [13:39:08 CEST] <BBB> reddit? I dindt see it [13:39:09 CEST] <BBB> letmesee [13:39:19 CEST] <Daemon404> its recent on reddit [13:39:22 CEST] <Daemon404> on proggit [13:39:31 CEST] <Daemon404> https://www.reddit.com/r/programming/comments/3mocaj/vp9_encodingdecoding_p… [13:40:34 CEST] <nevcairiel> someone should pick up hevc decoding performance, the intrinsics in openhevc are all rather crude i've been told, and carefully written yasm would probably be quite a bit faster still [13:41:04 CEST] <Daemon404> some people seem to be conflating encoding and decoding speed as well, i think [13:41:08 CEST] <Daemon404> or i read their stuff wrong [13:42:48 CEST] <fritsch> nevcairiel: there I also have a question. Which code paths did they optimize and for which CPU? did they use generic extensions in their asm code? As I might think AMD vs Intel would reveal different results? [13:43:05 CEST] <nevcairiel> AMD performance is in the crapper no matter what you do [13:43:24 CEST] <fritsch> lol [13:43:38 CEST] <fritsch> i will look at the code [13:43:57 CEST] <nevcairiel> but its mostly just various SSE versions, from 2 to 4.1 or so, it should benefit all CPUs [13:44:11 CEST] <Daemon404> unless you save sse2slow or w/e x264 calls it [13:44:12 CEST] <Daemon404> ;) [13:44:17 CEST] <Daemon404> have* [13:44:22 CEST] <nevcairiel> only very old CPUs fall into that [13:44:39 CEST] <Daemon404> there is a guy on on doom9 still running a p2 and xp [13:44:39 CEST] <Daemon404> so. [13:44:42 CEST] <Daemon404> :D [13:44:53 CEST] <Daemon404> sorry [13:44:53 CEST] <Daemon404> p3 [13:44:54 CEST] <nevcairiel> who cares about those guys [13:44:59 CEST] <Daemon404> not me [13:45:11 CEST] <Daemon404> its just that they also tend to be the noisiest [13:45:24 CEST] <fritsch> yeah i know those kind of people ... [13:45:29 CEST] <fritsch> amd legacy gpu users ... [13:45:40 CEST] <fritsch> are the worst that can happen for you if you change the way your software decodes and renders [13:45:44 CEST] <fritsch> :-) [13:45:46 CEST] <nevcairiel> of course, they need to tlel the world about the kind of hero they are, and block innovation for everyone else because their decades old OS needs to work =p [13:46:15 CEST] <J_Darnley> Excuse me but XP is the best OS Microsoft has ever made. [13:46:38 CEST] <nevcairiel> And you are free to use it, just not with my software xD [13:46:39 CEST] <Daemon404> i'm invoking poe's law here. [13:46:55 CEST] <J_Darnley> (that wasn't satire) [13:47:01 CEST] <fritsch> nevcairiel: that i will use in my kodi forum signature :-) too funy [13:47:01 CEST] <Daemon404> my condolences [13:47:32 CEST] <nevcairiel> Right now all my things even work on XP still, but i'll probably destroy it some day [13:47:50 CEST] <nevcairiel> (or at least I havent been told otherwise) [13:48:24 CEST] <Daemon404> i am, in fact, working on something that will break xp support in ffmpeg right now, maybe. [13:48:33 CEST] <nevcairiel> pthread_once? [13:48:35 CEST] <Daemon404> yep! [13:48:51 CEST] <Daemon404> if someone cares so much about xp, they can write some emulated version [13:48:51 CEST] <nevcairiel> emulation isnt impossible, or even htat hard [13:48:52 CEST] <Daemon404> i will not. [13:48:55 CEST] <nevcairiel> i'm sure SO has some code [13:49:04 CEST] <Daemon404> nevcairiel, sure. but i dont care. [13:49:09 CEST] <Daemon404> someone who cares can [13:49:31 CEST] <J_Darnley> Meybe that will prompt me to finally learn multithreading [13:49:43 CEST] <Daemon404> and an emulated version might end up not even fixing what im trying to fix anyway [13:49:56 CEST] <Daemon404> (lock contention in avcodec_open2, when using lavc in multiple threads) [13:50:22 CEST] <nevcairiel> pthread_once implementation isnt very complex, so emulating that with mutexes isnt that hard [13:50:34 CEST] <nevcairiel> http://pastebin.com/XU2ak89c [13:50:36 CEST] <Daemon404> and with mutexes, youre right back at lock contention [13:50:37 CEST] <nevcairiel> thats the original function [13:50:42 CEST] <nevcairiel> it a lso uses mutexes [13:50:42 CEST] <Daemon404> depending on how it's done. [13:51:58 CEST] <BBB> Daemon404: I think the hackernews comments are somewhat ok [13:52:47 CEST] <nevcairiel> Daemon404: in before the os2 "maintainer" sends you angry mails =p [13:55:21 CEST] <Daemon404> excuse me, but is called os/2, not os2. [13:56:51 CEST] <nevcairiel> i r lazy [13:58:09 CEST] <fritsch> nevcairiel: in which scenaria is such a pthread_once unavoidable? E.g. when it is not possible to setup everything before hand? So what's a typical usecase? in your implementation as fallback which data type is PTHRAD_NEEDS_INIT ? integer define? [13:58:48 CEST] <wm4> nevcairiel: now try on xp [13:59:01 CEST] <wm4> os/2 can probably be ignored [13:59:05 CEST] <wm4> it's used by only 1 person [13:59:23 CEST] <Daemon404> wrong! 2! [13:59:54 CEST] <wm4> nevcairiel: actually, I don't understand your code either, how is the mutex initialized? [14:00:10 CEST] <nevcairiel> wm4: thats the original pthread implementation [14:00:13 CEST] <nevcairiel> it uses static init [14:00:29 CEST] <wm4> what do you mean by "original pthread"? [14:00:43 CEST] <nevcairiel> how is that hard to understand [14:00:48 CEST] <nevcairiel> thats pthread_once source [14:00:55 CEST] <wm4> from where? [14:01:25 CEST] <wm4> pthread is a standard, there are many implementations [14:01:59 CEST] <wm4> anyway, the only way to get static mutex init on windows is some hack that only works unofficially, isn't it [14:02:22 CEST] <nevcairiel> just use atomic pointer switching to work around it [14:02:36 CEST] <nevcairiel> the glibc function of pthread_once looks similar, just uses different function names [14:02:46 CEST] <wm4> that gives a minor memory leak, which will be bikeshedded about for months [14:03:01 CEST] <nevcairiel> its either that or no XP [14:03:02 CEST] <nevcairiel> :P [14:04:09 CEST] <nevcairiel> (in before os/2 doesnt even have atomics) [14:04:10 CEST] <Daemon404> nevcairiel, could just make xp require an external pthreads [14:04:11 CEST] Action: Daemon404 runs [14:04:23 CEST] <wm4> Daemon404: +1 [14:04:33 CEST] <nevcairiel> meh, mixing pthreads and native threads is a big mess [14:04:40 CEST] <Daemon404> ofc [14:04:40 CEST] <nevcairiel> it leaks handles everywhere [14:04:51 CEST] <wm4> you're not mixing them, you use either of them [14:05:05 CEST] <wm4> what the user does is another question (and his fault!!!1) [14:14:21 CEST] <nevcairiel> i should send my hack-y patch to enable the udp worker thread with w32threads, just to see how much bikeshed it produces [14:14:39 CEST] <Daemon404> :D [14:14:51 CEST] <Daemon404> we havent had a nevcairiel patch dump in a while [14:15:04 CEST] <nevcairiel> most of them i just submit right away these days [14:15:33 CEST] <Daemon404> ah [14:16:08 CEST] <nevcairiel> http://git.1f0.de/gitweb?p=ffmpeg.git;a=commitdiff;h=06010e2475bd888e691b17… [14:16:13 CEST] <nevcairiel> seems slightly evil, but works fine =p [14:17:39 CEST] <nevcairiel> (it doesnt need cancel because closing the socket will automatically unblock the thread) [14:41:26 CEST] <BBB> nevcairiel: coming back to what you said earlier, ffhevc needs work, but all these companeis that are dying to see hevc being adopted will have to pay for it [14:41:38 CEST] <BBB> nevcairiel: I am not doing it for free, its too much of a ripoff [14:43:23 CEST] <J_Darnley> That's the spirit! [14:46:32 CEST] <JEEB> :) [14:46:35 CEST] <BBB> lol [14:46:38 CEST] <BBB> sorry for being blunt [14:46:43 CEST] <JEEB> well, it makes sense [14:46:55 CEST] <JEEB> it's currently not yet the savior of current-gen video [14:47:00 CEST] <BBB> I just feel that for h264 (also x264), for a long time, a bunch of companies made great money from our (or x264s) efforts [14:47:02 CEST] <JEEB> thus it's not widely used in general as AVC [14:47:06 CEST] <J_Darnley> I didn't mean to sound sarcastic [14:47:11 CEST] <BBB> x264 licensing definitely helps, but ffh264 didnt get anything [14:47:16 CEST] <JEEB> true [14:47:33 CEST] <JEEB> although since x264/AVC had a lot of usage the community got more out of it [14:47:33 CEST] <wm4> and there's still the patent situation (lol) [14:47:57 CEST] <JEEB> HEVC doesn't exactly have a situation like that yet [14:47:59 CEST] <BBB> the hevc patent situation is also funny, yes [14:48:12 CEST] <JEEB> yeah, it's a "more pop corn, please" kind of situation [14:48:28 CEST] <JEEB> it's as if there's people who don't want to see adoption of it happen ;) [15:14:02 CEST] <BBB> JEEB: more popcorn it is indeed - Im loving it so far :D [15:15:46 CEST] <Daemon404> needs more v-nova [15:16:31 CEST] <Daemon404> BBB, oh i wante to point out, re: x265 stats - its 'placebo' preset is a lie [15:16:47 CEST] <Daemon404> you can still enable more stuff to get better quality [15:17:01 CEST] <Daemon404> but it is so ludicrously slow, im guessing they didnt want to look bad by having it in placebo? [15:17:09 CEST] <Daemon404> (even though thats the intent of the name 'placebo'!) [15:17:49 CEST] <BBB> veryslow is actually same quality as placebo for x265 [15:17:59 CEST] <Daemon404> yes [15:18:04 CEST] <BBB> for x264 theres a 5% difference [15:18:28 CEST] <Daemon404> theres some stuff to fiddle with for ME, bframes, and refs beyond placebo in x265 [15:18:32 CEST] <Daemon404> among others [15:18:36 CEST] <BBB> thats true [15:18:37 CEST] <Daemon404> it's a marketing thing [15:18:40 CEST] <Daemon404> i guess. [15:18:41 CEST] <BBB> Im sure you can get better quality [15:18:49 CEST] <BBB> you can do a full motion search in libvpx as well [15:18:52 CEST] <BBB> did anyone say slow? [15:18:58 CEST] <Daemon404> :D [15:19:13 CEST] <Daemon404> iirc in x264 the full motion search didnt even have any real gains iirc [15:19:19 CEST] <Daemon404> er x265 [15:19:28 CEST] <BBB> star is not a bad ME approximation [15:19:33 CEST] <BBB> neither is UMH, for that matter [15:19:47 CEST] <BBB> libvpx uses a trivial staged hex search, which & uhm & is not that good? :) [15:19:57 CEST] <BBB> (exponential stepwise hex) [15:20:09 CEST] <Daemon404> for reasons? [15:20:25 CEST] <BBB> I dont know, thats a good question [15:20:30 CEST] <BBB> it never came up while I worked there [15:20:41 CEST] <BBB> maybe just because it was like that yesterday and isnt obviously broken? [15:20:48 CEST] <Daemon404> probably [15:20:54 CEST] <Daemon404> though that doesnt explain RC [15:20:55 CEST] Action: Daemon404 runs [15:21:18 CEST] <BBB> :D [15:21:36 CEST] <Daemon404> i fel like this generation of New Codecs (TM) is far less exciting than the last [15:21:44 CEST] <Daemon404> maybe i have rose tinted nostalgia glasses. [15:21:55 CEST] <BBB> people said the same when mpeg4 transitioned into h264 [15:21:58 CEST] <BBB> it just takes time [15:22:08 CEST] <BBB> Im just pointing out the obvious elephants in the room [15:22:17 CEST] <Daemon404> there were reasonably usable h264 encoders fairly early on, in the form of ateme [15:22:20 CEST] <BBB> now some big company should pay some big engineering team to fix these problems, and well repeat for h266 [15:22:47 CEST] <BBB> hm& yeah, well, x265 is kinda disappointing so far [15:22:59 CEST] <Daemon404> nobody works on x265 except paid people right now [15:23:04 CEST] <Daemon404> which is why 'good enough' is where its at [15:23:16 CEST] <Daemon404> x264 had people with goals [15:23:19 CEST] <Daemon404> ("make my anime look good") [15:25:28 CEST] <BBB> right [15:25:29 CEST] <Daemon404> and lots of free time (univesty) [15:25:33 CEST] <Daemon404> university even [15:25:43 CEST] <BBB> time doesnt have to be free [15:25:45 CEST] <BBB> time can be paid [15:25:48 CEST] <BBB> *blink* [15:26:03 CEST] <Daemon404> my point was nobody cares enough to pay [15:26:06 CEST] <Daemon404> so x264 was born from passion [15:26:07 CEST] <BBB> :) [15:26:28 CEST] <BBB> some companies should pay [15:26:46 CEST] <BBB> I mean, vimeo must spend reasonable amounts of money on encoding time and bandwidth, if you can decrease these costs, isnt that worth $$$? [15:27:04 CEST] <Daemon404> i dont know how much we spend [15:27:04 CEST] <BBB> and vimeo is only moderately big, there may be bigger players in that space? [15:27:10 CEST] <Daemon404> i bet encoding time is more expensive than bw [15:27:13 CEST] <BBB> you can estimate it [15:27:25 CEST] <BBB> youtube tells you how many video uploads per hour [15:27:33 CEST] <BBB> amazon tells you how expensive 1 core per hour is [15:27:58 CEST] <BBB> you know how much spf you get when encoding 1080p on a reasonably recent sandybridge at youtube-y settings [15:28:03 CEST] <BBB> voila [15:28:46 CEST] <Daemon404> id have to look those up for us [16:00:00 CEST] <BBB> theres a lot of public confidence in opencl/gpu, y'know [16:00:16 CEST] <BBB> if I were an advertising firm hired to make gpus sound cool, I would cash out right now [16:02:33 CEST] <JEEB> yeah [16:02:58 CEST] <JEEB> almost once a month some poor soul hits #ffmpeg with questions on GPU-based (as in, not ASIC-based) encoding [16:03:11 CEST] <JEEB> and then the usual lecture is needed [16:03:23 CEST] <BBB> maybe vnova should re-spin and target gpus exclusively [16:03:35 CEST] <BBB> seems like a magical fit [16:04:20 CEST] <BtbN> GPUs aren't exactly usefull for video encoding though, even if someone would write a full OpenCL encoder, it wouldn't be crazy fast or good. [16:04:44 CEST] <BBB> thats our point, sort of [16:04:58 CEST] <BBB> maybe our sarcasm is too well-hidden :D [16:05:45 CEST] <JEEB> :) [16:07:18 CEST] <iive> doesn't x264 support some opencl acceleration? [16:07:57 CEST] <Daemon404> it does, but it is useless [16:08:21 CEST] <iive> what does it accelerate? Motion Estimation? [16:08:32 CEST] <iive> dct ? [16:08:34 CEST] <BBB> probably does a full ME [16:09:00 CEST] <BBB> (as opposed to software hex/umh ME) [16:09:25 CEST] <BBB> I think it does help compression tiny bits, on some clips [16:09:26 CEST] <Daemon404> lookahead [16:09:29 CEST] <BBB> but only a bit [16:09:41 CEST] <Daemon404> http://git.videolan.org/?p=x264.git;a=commit;h=f49a1b2ef6d95d8f0f186df0fc3b… [16:10:05 CEST] <Daemon404> (it's not faster than cpu fyi) [16:10:24 CEST] <DHE> x264 acceleration is situationally useful. sometimes it helps (by something small like 10%) and sometimes it makes things a bit worse [16:10:35 CEST] <BBB> ubitux: wanna review my 10/12bpp loopfilter asm for vp9? [16:10:39 CEST] <Daemon404> 10% aint small, and ive never seen it be that much [16:10:43 CEST] <DHE> now, some GPUs have actual H264 encoding hardware. nvidia has shadowplay on windows. [16:10:58 CEST] <BBB> Gramner: wanna give final approval to checkasm itxfm_add vp9 tests? [16:11:08 CEST] <DHE> but that's not opencl related [16:11:32 CEST] <BBB> and now I need a victim for the dc/tm/h/v intra pred asm [16:11:38 CEST] Action: BBB stares around [16:11:52 CEST] <DHE> as in someone to write it? [16:11:54 CEST] <BBB> iive: tag youre it [16:11:59 CEST] <BBB> DHE: no, someone to review it [16:12:11 CEST] <BBB> I wrote it and posted it before weekend, nbody responded [16:12:30 CEST] <BBB> DHE: hows your x86 assembly? [16:12:40 CEST] <DHE> borderline non-existant [16:12:58 CEST] <BBB> &%^*% [vnova translator] -> expert [16:13:00 CEST] <BBB> great [16:13:03 CEST] <BBB> can you review my patch? [16:13:26 CEST] <BBB> :-p [16:16:33 CEST] <DHE> I am neither qualified, competent nor coherent enough to do so [16:16:56 CEST] <BBB> haha ok Ill find another victim [16:17:16 CEST] <BBB> maybe I need to pull a fiona and start giving x86 simd classes [16:17:24 CEST] <BBB> that worked quite well for a while [16:18:47 CEST] <durandal_1707> I want that! [16:19:17 CEST] <BBB> oh I didnt notice, reddit has a duplicate detector [16:19:20 CEST] <BBB> thats quite useful! [16:20:03 CEST] <iive> you mean, repost detector? [16:20:13 CEST] <Daemon404> no [16:20:17 CEST] <BBB> other discussions (7) [16:20:18 CEST] <Daemon404> it's meant to correlated between subreddits [16:20:47 CEST] <DHE> it also does duplicate detection over long periods of time [16:24:16 CEST] <BBB> durandal_1707: ok lets try to figure something out (once youve started it, youll notice its not hard at all) [16:24:24 CEST] <BBB> durandal_1707: did you read through fionas original materials? [16:26:08 CEST] <durandal_1707> I don't remember anything even if I had read [16:26:53 CEST] <BBB> https://wiki.videolan.org/X264_asm_intro [16:28:08 CEST] <nevcairiel> I considered writing some hevc asm at some point, but the important missing parts are IDCTs, and well, those are unreadable in C as it is, not a good place to start [16:29:31 CEST] <martijnb> tbh I have to blankly stare at the math for a few minutes before IDCTs start making sense again [16:30:10 CEST] <BBB> I feel all parts of hevc could use some attention [16:30:14 CEST] <BBB> it wont make it 10x faster [16:30:20 CEST] <BBB> but youll get 5% or 10% from various parts [16:30:34 CEST] <BBB> idct would be a big gain, yes [16:31:04 CEST] <nevcairiel> some of the things have already been looked at by james and others, those are probably ok [16:31:14 CEST] <nevcairiel> MC is a bit of a mixed bag [16:32:00 CEST] <Gramner> BBB: ok with me to push itxfm tests [16:35:00 CEST] <BBB> ty [16:44:41 CEST] <cone-210> ffmpeg 03Henrik Gramner 07master:19b28d047daa: checkasm: Fix the function name sorting algorithm [16:49:36 CEST] <mateo`> hello o/, when using the hwaccel api, if you want to reconstruct the bitstream of a full frame, you have to concatenate the buffer given to start_frame with each buffer given by each call of decode_slice ? [16:52:16 CEST] <cone-210> ffmpeg 03Ronald S. Bultje 07master:0b227c6d4725: checkasm: add vp9dsp.itxfm_add tests. [17:06:44 CEST] <gnafu> BBB: Thanks for your most recent blog post. Good read :-). [17:07:51 CEST] <BBB> yw:) [17:29:32 CEST] <nevcairiel> mateo`: start_frame gives you the full buffer, slices only slice buffers, so you can just use the start_frame buffer as a whole [17:36:30 CEST] <mateo`> nevcairiel: thanks ! [17:52:15 CEST] <mateo`> nevcairiel: i was asking because it looks like the videotoolbox hwaccel differentiate the case when the h264 stream is of format bytestream and avc [18:55:04 CEST] <Gramner> BBB: oh, you changed iszero() in your second patch, I missed that. it's incorrect now :) [18:55:06 CEST] <Gramner> patch sent [19:47:44 CEST] <Zenk_BR> Hey, good afternoon (2;24pm In Brazil:] ) [19:52:37 CEST] <BBB> ? [19:53:03 CEST] <BBB> Gramner: isnt that identical? [19:53:35 CEST] <BBB> oh oops it isn't [19:53:38 CEST] <BBB> ok patch ok :D [19:53:39 CEST] <Gramner> the current code reads 4 bytes, skips 4 bytes, etc [19:55:28 CEST] <cone-210> ffmpeg 03Henrik Gramner 07master:69e456d7fbc5: checkasm/vp9dsp: Fix iszero() to read the correct data [20:57:04 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:1d0487f77f07: avcodec/pngdec: reset has_trns after every decode_frame_png() [21:03:39 CEST] <Zenk_BR> Hey guys [21:03:49 CEST] <Zenk_BR> i have a question =x [21:04:43 CEST] <Zenk_BR> i'm trying convert .dav to any video formats...avi, mp4, mov...any one!! [21:04:56 CEST] <nevcairiel> whats a dav video [21:05:37 CEST] <Zenk_BR> http://www.openthefile.net/extension/dav [21:06:37 CEST] <nevcairiel> its encrypted, so good luck [21:06:40 CEST] <nevcairiel> also, you want #ffmpeg [21:08:04 CEST] <Zenk_BR> so, ffmpeg don't convert? [21:16:02 CEST] <durandal_1707> atomnuker: writing assim? [21:33:27 CEST] <wm4> ubitux: wasn't part of your subtitle problem dealing with the ABI? [21:33:35 CEST] <wm4> the ABI is free to change currently [21:34:25 CEST] <nevcairiel> although we should probably lock it down at some point again [00:00:00 CEST] --- Tue Sep 29 2015

1 0

ffmpeg.log.20150928
by burek 29 Sep '15

29 Sep '15

[03:43:55 CEST] <pinPoint> i'm curious about ffmpeg and prores. How was it possible to create a prores option when it is not open? [03:45:43 CEST] <c_14> Implementing the format spec? [03:45:50 CEST] <c_14> That or reverse engineering a working encoder. [03:45:52 CEST] <pinPoint> yes. [03:46:02 CEST] <pinPoint> I mean it is not open from apple is it? [03:46:34 CEST] <pinPoint> reversing a codec is insane no? [03:46:41 CEST] <c_14> Been done before. [03:47:19 CEST] <pinPoint> I've haven't spent much time in prores space but does it look good in production environment? [03:47:49 CEST] <waressearcher2> what is that "prores" ? [03:48:03 CEST] <c_14> It's a video codec [03:48:11 CEST] <waressearcher2> better than V9 ? [03:48:18 CEST] <waressearcher2> or h264 [03:48:30 CEST] <waressearcher2> or its proprietary from apple [03:48:39 CEST] <c_14> It's main use is with high bitrates for post-processing. [03:48:42 CEST] <c_14> Not for good compression. [03:49:24 CEST] <pinPoint> c_14: indeed. waressearcher2 it is really good.. good colors too [03:49:46 CEST] <pinPoint> hence the use of it in production for Post work and colorspace. [03:49:56 CEST] <c_14> It's meant for use-cases where rawvideo is too big, and other codecs lose too much information or take too much time. [03:50:00 CEST] <pinPoint> waressearcher2: it is an apple thing [03:50:56 CEST] <pinPoint> waressearcher2: I got an example if you want to see. Its a color graded file but you can see it. I think. :) [03:51:08 CEST] <waressearcher2> no need [03:51:39 CEST] <pinPoint> ok [03:52:35 CEST] <pinPoint> c_14: I'm suprised nobody out there has come up with something just as good. I mean there is DNxHD, CinemaDNG, R3D Raw [03:52:53 CEST] <c_14> As good as prores? [03:53:30 CEST] <pinPoint> yes [03:53:49 CEST] <pinPoint> the only problem is editing in windows without support. [03:54:08 CEST] <c_14> tbh, I usually either encode directly to H.264 or use a lossless codec [03:54:26 CEST] <pinPoint> btw, I took those HEVC .mp4/.mkv files to work and they fly well on Samsung UHD and Vizio UHD with sound finally. [03:54:35 CEST] <c_14> If you need support in $video_application, utvideo is supported almost everywhere. [03:54:55 CEST] <pinPoint> Finally, I can grab 4k videos of off youtube and convert to hevc and flash drive those things for demos [03:57:43 CEST] <pinPoint> utvideo? [03:58:04 CEST] <pinPoint> c_14: what lossless codec do you go for usually? [03:58:42 CEST] <pinPoint> utvideo is lossless. I see [03:59:18 CEST] <c_14> If what I'm using has lavc support ffv1. Had the best speed/compression tradeoff in my tests. [05:11:19 CEST] <pinPoint> so is AAC also a reversed version too? [05:11:59 CEST] <c_14> Think there's an open spec for that one. [05:12:09 CEST] <pinPoint> open spec? [05:12:21 CEST] <c_14> And you can learn from the other implementations. [05:12:24 CEST] <pinPoint> I used -strict experimental.. is that what that is? [05:12:38 CEST] <waressearcher2> can ffmpeg use CUDA or opencl for encoding ? [05:12:44 CEST] <c_14> A spec you can get your hands on without belonging to some ominous association or paying sums of money. [05:12:53 CEST] <waressearcher2> will it be some day ? [05:13:37 CEST] <c_14> waressearcher2: besides some minor x264 optimization, no. (and one or 2 video filters) [05:15:08 CEST] <waressearcher2> are there plans for full support ? [05:15:20 CEST] <waressearcher2> I mean can you imagine reusing thouthands CUDA cores for encoding ? [05:15:24 CEST] <c_14> It's not worth it for encoding. Might be worth it for some filters. [05:15:28 CEST] <c_14> *usually not worth it [05:15:44 CEST] <waressearcher2> by the way what is the reason it doesn't use GPU ? CUDA is available like for years [05:17:03 CEST] <waressearcher2> but there are video cards that are specificaly for video processing, like "Sony Vegas" can use "geforce 570" features to speed up encoding, does it uses some specific features and not CUDA ? [05:17:19 CEST] <pinPoint> would cuda/opencl even help much? [05:17:26 CEST] <c_14> Those are usually special chips on the graphics cards. [05:17:34 CEST] <c_14> Whatever they're called [05:17:36 CEST] <pinPoint> my hexa cranks to fulltime when I push some x265 out [05:17:36 CEST] <c_14> eh [05:17:45 CEST] <waressearcher2> can ffmpeg use them or isit driver specific ? [05:17:56 CEST] <pinPoint> c_14: "get your hands on" oh boi. [05:17:58 CEST] <waressearcher2> pinPoint: what is hexa ? [05:18:03 CEST] <pinPoint> hexacore [05:18:14 CEST] <waressearcher2> pinPoint: 8 core ? [05:18:21 CEST] <pinPoint> 6 [05:18:22 CEST] <c_14> waressearcher2: nvenc & related hwaccels [05:20:02 CEST] <pinPoint> c_14: is the reason that its better for rendering instead? on my premiere the cuda does come online. It's still dealing with video so ffmpeg can never do it? [05:21:08 CEST] <c_14> The GPU is good for doing millions of small operations simultaneously, encoding video doesn't usually fit that bill [05:23:06 CEST] <pinPoint> ah [05:23:22 CEST] <waressearcher2> cracking passwords ? [05:24:32 CEST] <pinPoint> from what's on the net, yes. [05:24:45 CEST] <pinPoint> like a 8 way sli titans [05:24:51 CEST] Action: pinPoint shudders [05:27:55 CEST] <pinPoint> c_14: have you messed around with prores ffmpeg encodes and tested them on a final cut X timeline? Where they compliant without fcp complaining? [05:28:43 CEST] <c_14> Haven't personally tried it, but they should be compliant. [05:30:02 CEST] Action: pinPoint thinks of a tutorial article [05:34:48 CEST] <waressearcher2> "8 way sli titans", one even cheap smartphon will be as powerful as that thing [05:34:55 CEST] <waressearcher2> one day [05:35:20 CEST] <waressearcher2> 13:32 here [05:37:38 CEST] <pinPoint> in the afternoon. cool [05:37:41 CEST] <pinPoint> :) [05:38:11 CEST] <pinPoint> waressearcher2: one day but GPUs will be just as ahead. [05:38:13 CEST] <Nosomy> CUDA encode? [05:38:16 CEST] <Nosomy> lol [05:38:20 CEST] <pinPoint> :D [05:38:39 CEST] <Nosomy> "Best Quality" [/ironic mode off] [05:38:53 CEST] <waressearcher2> 13:36 [05:38:57 CEST] <waressearcher2> wait for it [05:39:05 CEST] <pinPoint> l33T [05:40:55 CEST] <Nosomy> Cuda Implementation last time i saw is a s***, maybe today it can be improved . [05:41:03 CEST] <waressearcher2> 13:38 ta-da-a [05:41:29 CEST] <pinPoint> Nosomy: opencl? [05:41:50 CEST] <Nosomy> nop, before opencl. [05:42:02 CEST] <pinPoint> libx264 crf 23 is good, libx265 crf 23 is even better? [05:43:40 CEST] <pinPoint> that hevc is making the cpu purr [05:43:51 CEST] <pinPoint> water cooled fans are whirrin [05:43:55 CEST] <Nosomy> crf 23 is medium good. [05:44:09 CEST] <Nosomy> i prefer crf 20.5 [05:44:11 CEST] <pinPoint> on libx265 its better though [05:44:21 CEST] <c_14> You can't compare the crfs between x264 and x265. They're not meant to measure the same "quality". [05:44:55 CEST] <pinPoint> that is why I think on x265 a crf 23 is actually better than just good. [05:45:28 CEST] <waressearcher2> what is crf ? [05:45:52 CEST] <Nosomy> control rate factor [05:46:02 CEST] <pinPoint> http://slhck.info/articles/crf [05:46:14 CEST] <pinPoint> Constant [05:46:37 CEST] <Nosomy> c_14 and VQMCalc avs plugin? [05:46:44 CEST] <Nosomy> lol [05:47:31 CEST] <c_14> Isn't that just a psnr? [05:48:03 CEST] <Nosomy> Based on VQM work from Watson and Feng Xiao. [05:49:59 CEST] <pinPoint> i have to admit, libx265 compression is just amazing. [05:50:27 CEST] <pinPoint> I know hevc is not cheap but the compression levels are just insane [05:50:31 CEST] <Nosomy> but hevc have cpu use cost to decode [05:50:59 CEST] <pinPoint> the tv's do it just fine. I've tested a few of them [05:51:13 CEST] <pinPoint> from a usb flash drive [05:54:07 CEST] <pinPoint> I just went from a 346.08MB to 102MB with x265. o_O [06:03:54 CEST] <Nosomy> reencode? [06:04:02 CEST] <Nosomy> or the source is lossless? [06:05:10 CEST] <pinPoint> webm 3840x1620 DASH video 17346k , VP9, 24fps, video only, 346.07MiB [06:05:38 CEST] <pinPoint> combined it with m4a audio only DASH audio 255k , m4a_dash container, aac @256k (44100Hz), 8.92MiB [06:06:09 CEST] <pinPoint> i don't think its lossless, its from youtube. https://www.youtube.com/watch?v=xyIAV5YVjA4 [06:14:09 CEST] <Nosomy> lossy... [06:14:35 CEST] <Nosomy> For UHD youtube use VP9? [06:14:48 CEST] <Nosomy> lol [06:15:18 CEST] <pinPoint> its either that or mp4 [06:15:35 CEST] <pinPoint> so I started with a larger file hopefully a bit more quality that the small mp4 [06:16:16 CEST] <Nosomy> More bitrate isn't always more quality [06:16:29 CEST] <Nosomy> depends of codec [06:16:29 CEST] <pinPoint> file size [06:16:41 CEST] <pinPoint> how about this one? mp4 5120x2700 DASH video 24998k , 30fps, video only, 506.46MiB [06:17:14 CEST] <Nosomy> maybe very good. [06:17:27 CEST] <Nosomy> don't see the video. [06:17:36 CEST] <pinPoint> https://www.youtube.com/watch?v=nRt4Duf7GoI [06:18:27 CEST] <pinPoint> Nosomy: mp4 vs webm [06:18:53 CEST] <Nosomy> for decode or encode? [06:19:14 CEST] <pinPoint> youtube->mkv [06:19:27 CEST] <Nosomy> video complexity rules the encodes bitrates. [06:20:07 CEST] <Nosomy> for encode i prefer h264, is more fast to encode. [06:20:24 CEST] <Nosomy> for decode, vp9 hevc h264 is ok to this [06:20:53 CEST] <pinPoint> these videos end up on a uhd tv displays for demo [06:21:08 CEST] <pinPoint> either .mp4/mkv container(h265)(aac) [06:21:25 CEST] <Nosomy> vp9 is slow like hevc to encode. [06:21:46 CEST] <Nosomy> youtube using vp9 is funny... [06:22:02 CEST] <pinPoint> they have been for quite a while now [06:22:04 CEST] <pinPoint> since v8 [06:22:09 CEST] <pinPoint> now v10 is rolling around [06:23:36 CEST] <Nosomy> normally youtube streaming i don't reencode. [06:24:15 CEST] <pinPoint> Nosomy: i know but they won't play back on uhd tv displays. The manufactures have really locked it down. [06:24:16 CEST] <Nosomy> is not recommended, if you looks quality [06:24:27 CEST] <pinPoint> they want hevc with aac for UHD video, nothing less [06:24:40 CEST] <pinPoint> i have tried Samsung/vizio/sharp/lg [06:25:18 CEST] <waressearcher2> what hard ware youtube uses to encode all those videos when you upload them ? [06:25:35 CEST] <pinPoint> their servers probably [06:25:52 CEST] <Nosomy> batching ffmpeg with fast presets. [06:25:57 CEST] <Nosomy> lol [06:25:59 CEST] <waressearcher2> something i7 ? [06:26:10 CEST] <pinPoint> try Xeons [06:26:21 CEST] <pinPoint> 2x12Core Xeons or better [06:26:23 CEST] <waressearcher2> they use normal CPU that average gaming PC has, right ? [06:27:05 CEST] <pinPoint> the editors I've read run on 2x12core Xeons on 128GB RAM, 2way sli Titan X ++ [06:27:50 CEST] <waressearcher2> why they have Titan, they use CUDA ? [06:28:56 CEST] <pinPoint> the editing programs use it. Premiere, Avid, Final Cut(hackintosh) [06:29:16 CEST] <pinPoint> its for 3K,4K,5K,6K video [06:30:15 CEST] <waressearcher2> that Titan thing has only 12GB memory, do you think its all NVIDIA can do or they just don't want to go ahead of themselves ? [06:30:27 CEST] <Nosomy> time is expensive for an encode video to youtube, youtube using vp9 is very funny. [06:31:15 CEST] <waressearcher2> its like 40hours videos uploaded per minute [06:31:47 CEST] <pinPoint> Nosomy: actually the list is different, let me link you. http://pastebin.com/vcxnHePb [06:31:56 CEST] <waressearcher2> or 40 minutes every second [06:38:19 CEST] <Nosomy> Well, what should I see? [06:40:16 CEST] <pinPoint> they have like different formats for just one video. its weird how youtube works [06:40:25 CEST] <pinPoint> that's all from one video [06:40:37 CEST] <pinPoint> and bandwidth sizes too [06:42:36 CEST] <waressearcher2> is xvid still in use nowadays ? [06:42:46 CEST] <Nosomy> youtube processing video is so little funny, out the demos them, every video uploading going to bad quality. [06:42:51 CEST] <pinPoint> for nonhd yes. [06:43:10 CEST] <Nosomy> warezs yet use xvid [06:43:22 CEST] <waressearcher2> why would someone need nonhd and for how long do you think xvid will be used ? [06:43:39 CEST] <Nosomy> more 8~10 years [06:43:47 CEST] <Nosomy> i think [06:45:11 CEST] <Nosomy> why would someone need nonhd? ans: preference [06:46:25 CEST] <Nosomy> nowadays h264 is good enough for encode video. [06:46:48 CEST] <Nosomy> including nonhd [06:49:23 CEST] <pinPoint> indeed [06:51:55 CEST] <Nosomy> xvid encoding looks likes a hispter video encoder, only overcome if guy used dirac, dirac is too so old. [06:55:33 CEST] <Nosomy> ans2: xvid is compatible with old dvd\vcd players. [06:58:34 CEST] <Nosomy> while there is old DVD\VCD player working, going to exist xvid encoding [07:39:42 CEST] <razzledazzle> Can anyone see this paste? http://pastie.org/private/w6ksuwbnxqqihjcoxprnza [07:41:22 CEST] <razzledazzle> Not able to understand what the starting duration has to do with the partial file issue, it even doesn't work when ss is set to 0. [07:41:49 CEST] <razzledazzle> Works well without pipe but pipe is mandatory as streams are being used to pass in data [11:28:09 CEST] <razzledazzle> please help, posted a question: http://superuser.com/questions/979144/unable-to-trim-piped-video-stream-wit… [11:53:17 CEST] <relaxed> razzledazzle: mp4 isn't the best container for piping [11:56:40 CEST] <razzledazzle> I'm actually developing for Android and generally they support mp4, even the camera there produces in mp4 [17:11:36 CEST] <sine`> I have this audio clip in amr format amr_nb samr 8000htz mono 12/kbs [17:12:05 CEST] <sine`> whenever I convert it to any format it is distorted with compression peaks etc, but playing it back on windows is fine without conversion [17:12:22 CEST] <sine`> what would be the best way to preserve the audio but have it in wav/editor friendly format [17:14:28 CEST] <sine`> its ok i fixed it [18:55:56 CEST] <millican> Is ffmpeg no longer in the Debian (8) repos? I must be going blind. [18:56:41 CEST] <BtbN> I don't think it was ever in there? [18:57:38 CEST] <BtbN> 9 should have it though [18:57:57 CEST] <millican> I didn't know there was a 9. [18:58:08 CEST] <BtbN> Well, the one after 8 is usualy 9 ;) [18:58:22 CEST] <relaxed> yeah, it's in unstable now [18:58:34 CEST] <BtbN> No, testing has 2.7 [18:58:41 CEST] <BtbN> Well, of course it's also in unstable [18:59:01 CEST] <millican> I may adjust my sources.list temporarily or compile it. [18:59:16 CEST] <relaxed> millican: or http://johnvansickle.com/ffmpeg/ [18:59:51 CEST] <millican> relaxed: Thanks. [19:33:52 CEST] <pinPoint> sine`: how did you fix it? [19:34:14 CEST] <pinPoint> you got the ffmpeg command? :D just curious. bbl [20:09:35 CEST] <Djerkaf> Hello! I'm copying the left audio channel to the right using -filter_complex "pan=stereo|c0<c0|c1<c0" but the audio quality doesn't seem to stay the same as the original. Is there any way to change the default quality into original quality? [20:13:48 CEST] <c_14> Djerkaf: what's the rest of your command [20:13:53 CEST] <c_14> It's probably encoding settings [20:18:39 CEST] <Djerkaf> "C:\path\ffmpeg.exe" -i "L:\path\input.mp4" -filter_complex "pan=stereo|c0<c0|c1<c0" -map 0:v -c:v copy -shortest "L:\path\output.mp4" [20:19:08 CEST] <waressearcher2> at first I thought why do you use "escape" symbol, then I realised its windows path [20:19:19 CEST] <c_14> How new is your version? [20:19:32 CEST] <c_14> Anyways, https://trac.ffmpeg.org/wiki/Encode/AAC [20:19:54 CEST] <Djerkaf> 2.2.2 [20:20:32 CEST] <c_14> If you're using the builtin aac encoder you might want to update to recent git, lots of improvements have been added. [20:38:36 CEST] <Djerkaf> Tried adding -c:a libvo_aacenc -vbr 1 but that "-vbr 1" seems to be completely ignored as it should be low quality and still is at a steady 128 kbit throughout the whole clip [20:40:19 CEST] <Djerkaf> (CBR) [20:48:45 CEST] <Nosomy> try -q:a 1 [21:06:10 CEST] <Djerkaf> Nosomy: Still CBR 128 [21:10:14 CEST] <Axydlbaaxr> Hi, good people of #ffmpeg. I'd like to know how I can configure ffserver so that it will stream video from a file in a "live" style. By that, I mean I want the server to start streaming from the file from the beginning at t=0 when the server is launched. Then when a client connects to it at t=5, the client will receive video starting at 5 seconds in, and clients connecting later will also... [21:10:16 CEST] <Axydlbaaxr> ...get the video already in progress. Instead of the current way I'm seeing it work, where each connection starts the video from the beginning, I want each connection to join the stream already in progress as though the source video file were a live source. [21:22:03 CEST] <fffelix> Hi, I want to transcode a stream (mp3) to a lower quality (for mobile). the standard -i input output creates a recording, but I want ffmpeg to "forget" everything thats older than ~10 seconds from the stream. Is this possible with ffmpeg? [21:23:51 CEST] <fffelix> It should be a continous stream, but instead of the 128kbit/s mp3 a 12kbit/s opus (for mobile streaming) and kind of keep the file to a given size/length [21:32:45 CEST] <ChocolateArmpits> fffelix: by stream you mean a file or an actual live streaming audio, like an internet radio station ? [21:33:27 CEST] <fffelix> ChocolateArmpits: an actual stream that is provided via an mp3 [21:35:28 CEST] <ChocolateArmpits> fffelix: what do you mean by "forget" ? to only output silence until a specific time? [21:38:35 CEST] <fffelix> ChocolateArmpits: I want to transcode the stream to a smaller opus stream, bc the station only offers 128kbit/s which is too much for my mobile plan, so I want to transcode it. When I use ffmpeg i xyz.mp3 xyz.opus it generates a recording, but I want to create a second stream with anoter codec/bitrate [21:39:06 CEST] <ChocolateArmpits> fffelix: yes I understand that fully [21:39:16 CEST] <ChocolateArmpits> but what does the "forget" part mean in your plan [22:18:18 CEST] <Djerkaf> Hello71, I see that you've had a similar problem, remember if you solved it? https://mplayerhq.hu/pipermail/ffmpeg-devel-irc/2014-February/001947.html [22:27:27 CEST] <woopdeedoodaa> Hey does anyone have experience with the nvenc encoder? I've build it from source and can encode video with it (no errors) but the colour range is limited, blacks are crushed and look washed out. Anyone know how to specify full colour range (0-255) with nvenc? I can provide examples if the would help [22:29:10 CEST] <Nosomy> nvidia color range problem [22:35:36 CEST] <woopdeedoodaa> So is that a hardware limitation or the codec implementation? [22:58:32 CEST] <frenda> Hey there [22:59:47 CEST] <frenda> May you take a look at this 10-sec video: http://uploadkon.ir/fl/dd/76929 and let me know if ffmpeg can capture the screen by zooming in/out to the zone that the curser is acting via shortcut keys; (in linux realm) [23:01:49 CEST] <fffelix> ChocolateArmpits: sorry, that was very unspecific. I want to create another stream, not a recording that writes every bit from when i started the ffmpeg. [23:20:53 CEST] <Hello71> Djerkaf: don't remember [23:21:18 CEST] <Hello71> Djerkaf: maybe try reordering the options or using "vbr:v" or something [23:24:41 CEST] <Djerkaf> Alright [00:00:00 CEST] --- Tue Sep 29 2015

1 0

ffmpeg-devel.log.20150927
by burek 28 Sep '15

28 Sep '15

[00:22:01 CEST] <cone-626> ffmpeg 03Alex Smith 07master:20b079963bf8: configure: Combine dynamicbase and nxcompat checks [00:56:21 CEST] <cone-626> ffmpeg 03Ganesh Ajjanagadde 07master:265b106b9296: ffplay: introduce key repeats [01:25:56 CEST] <cone-626> ffmpeg 03Christophe Gisquet 07master:08a7510fcad5: dnxhddec: implement slice multithreading [01:41:24 CEST] <cone-626> ffmpeg 03Ganesh Ajjanagadde 07master:23acb982a3c7: ffplay: dynamically allocate filename buffer [05:05:40 CEST] <Timothy_Gu> kurosu: what's the advantage of slice mt over frame mt? [08:58:49 CEST] <kurosu> Timothy_Gu, delay in decoding and speed of preview, but it's minor [09:07:02 CEST] <kurosu> the speed benefits of both are codec-dependent: for instance, with temporal prediction, frame threading may not scale [09:07:50 CEST] <kurosu> slice threading may not scale if the jobs are unbalanced, and it has a different kind of overhead [10:19:59 CEST] <Timothy_Gu> kurosu: I was specifically referring to dnxhd [10:20:23 CEST] <Timothy_Gu> but that makes sense, thanks [11:04:52 CEST] <durandal_1707> assumefps or setfps? [12:20:17 CEST] <cone-433> ffmpeg 03Christophe Gisquet 07master:8e8ed57ea7d3: dnxhddec: remove unused qscale parameter [12:20:17 CEST] <cone-433> ffmpeg 03Christophe Gisquet 07master:5c6e3a019c5c: dnxhddec: simplify block parsing calls [12:58:32 CEST] <durandal_1707> no homework for me :( [13:00:57 CEST] <wm4> or for me [13:02:52 CEST] <Daemon404> both of you should probably do the homework [13:03:05 CEST] <Daemon404> especially in case j-b invaldes germany [13:06:49 CEST] <nevcairiel> j-b doesnt want to give it out before talking to us in person, preferably =p [13:09:34 CEST] <wm4> I wonder why [13:09:36 CEST] <Daemon404> nevcairiel, so there is a scheduled invasion time? [13:11:26 CEST] <durandal_1707> zuffing ffv1 for 22:30 hours and still nothing [13:11:57 CEST] <nevcairiel> Daemon404: apparently, although i didnt get a date yet [13:12:36 CEST] <Daemon404> :D [13:15:59 CEST] <kierank> durandal_1707: are you using a script [13:17:13 CEST] <durandal_1707> kierank: nope [13:17:30 CEST] <ubitux> durandal_1707: zzuf? why not afl? [13:18:30 CEST] <durandal_1707> afl, it already found 2 bugs but that was long ago [13:19:11 CEST] <kierank> I am running afl on opusdec [13:19:21 CEST] <kierank> supposedly lots of hangs but I can never reproduce them [13:19:22 CEST] <Compn> durandal_1707 : did you do flv1 codec already? :) [13:19:55 CEST] <durandal_1707> Compn: just one hour, nothing [13:20:20 CEST] <Compn> thansk :) [13:20:40 CEST] <durandal_1707> kierank: i run hangs via valgrind [13:22:26 CEST] <Compn> kierank : disable threading ? if there is on opus dec... [13:22:28 CEST] <Compn> nevermind [13:30:00 CEST] <kierank> durandal_1707: I have hundreds of supposed opus hangs but nothing happens [13:39:18 CEST] <durandal_1707> well, i was just lucky then [15:03:47 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:485057f71572: avfilter/vf_mcdeint: add missing "This file is part of FFmpeg" [15:03:48 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:549d10924894: avfilter/vf_yadif: add missing "This file is part of FFmpeg" [15:03:49 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:c4d50314c087: avcodec/d3d11va: Fix project name [15:03:50 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:7d636d02b113: swresample/dither_template: Add missing license header [16:55:21 CEST] <TheRyuu> so what's the story with my other two patches (adding HEASLR flag and the image base one) [16:56:00 CEST] <nevcairiel> i assume the heaslr one only sets a PE flag and is ignored whenever not supported? [16:56:38 CEST] <TheRyuu> it also sets the image base > 4GB [16:57:03 CEST] <TheRyuu> https://github.com/TheRyuu/FFmpeg/commit/f2b805d02ee12af5593130ef06f0924422… [16:57:34 CEST] <nevcairiel> do the PE flags and image base match a msvc build after? [16:57:43 CEST] <TheRyuu> yes [17:00:12 CEST] <nevcairiel> did you complain to binutils about the entry point massacre? [17:01:25 CEST] <TheRyuu> I have not [17:02:09 CEST] <TheRyuu> if it was up to me I would completely revamp the linker defaults for mingw-w64 [17:02:30 CEST] <TheRyuu> the defaults are shit [17:02:36 CEST] <Gramner> indeed, the defaults are quite bad [17:02:42 CEST] <TheRyuu> (even on linux IIRC) [17:03:34 CEST] <Gramner> they should use whatever msvc uses by default when linking windows binaries [17:04:05 CEST] <TheRyuu> that's what I made ffmpeg do with these patches [17:04:46 CEST] <Gramner> you should submit a patch to upstream and save everyone else the trouble [17:05:41 CEST] <nevcairiel> windows usualy just enables new features by default, binutils for some reason doesnt enable anything by default =p [17:06:55 CEST] <TheRyuu> I find the reloc shit particularly amusing since it basically means any open source project which gets compiled with it has a fixed base [17:07:06 CEST] <TheRyuu> e.g. openvpn [17:07:53 CEST] <TheRyuu> or you can look at it as punishment for not using msvc [17:08:30 CEST] <TheRyuu> when did binutils finally stop using cvs [17:08:53 CEST] <Gramner> at least it doesn't strip relocs from shared libs [17:10:45 CEST] <nevcairiel> only from executables =p [17:11:12 CEST] <Gramner> it msvc just fixes support for inline assembly on x64 I would probably stop using mingw altogether [17:11:36 CEST] <nevcairiel> they have never supported that, its unlikely they start anytime soon [17:12:02 CEST] <Gramner> well, people used to say that about c99 [17:12:39 CEST] <nevcairiel> even ignoring inline asm, sadly gcc builds of ffmpeg are still non-trivially faster [17:13:27 CEST] <nevcairiel> although i didnt compare 2015 yet [17:13:29 CEST] <Gramner> are you using msvc with the most sane settings? I never checked [17:13:39 CEST] <nevcairiel> define most sane [17:14:27 CEST] <Gramner> -zomg-fast [17:14:52 CEST] <Gramner> no, but optimized for performance instead of just defaults basically [17:15:04 CEST] <nevcairiel> sure [17:15:26 CEST] <Gramner> it uses stuff like stack cookies by default with has a significant overhead in some functions [17:17:08 CEST] <nevcairiel> i should run a bench on ffmpeg itself again one of these days, I'm sure the options used in ffmpegs configure arent that precise [17:18:39 CEST] <nevcairiel> disabling security features for performance is one of those arguable areas, but i should check how much stack cookies really cost [17:20:31 CEST] <Gramner> honestly, there are so many attack vectors in libavcodec that I wouldn't trust it to decode untrusted data in anything other than a fat sandbox environment anyway [17:20:34 CEST] <nevcairiel> but in the end that still leaves inline asm, and even if microsoft would fix that for x64, ffmpeg sitll uses the w rong syntax [17:21:49 CEST] <Gramner> if you're relying on stack cookies for security you've basically already lost. but I'm sure others disagree [17:22:17 CEST] <TheRyuu> stack cookies with the default settings should be almost free [17:22:37 CEST] <TheRyuu> you should never have to disable /GS for performance [17:23:52 CEST] <TheRyuu> 17:20 < Gramner> honestly, there are so many attack vectors in libavcodec <---IIRC most are actually in parsing (libavformat) [17:24:30 CEST] <Gramner> libav* then [17:33:29 CEST] <TheRyuu> does binutils have an irc channel [17:34:27 CEST] <Daemon404> LOL [17:35:40 CEST] <TheRyuu> should I take that as a no [17:40:14 CEST] <TheRyuu> https://sourceware.org/bugzilla/show_bug.cgi?id=17321 [17:40:56 CEST] <TheRyuu> yes another option to fix a string of other broken options pls [18:26:23 CEST] <durandal_1707> kierank: do you use asan? [18:49:34 CEST] <TheRyuu> https://sourceware.org/bugzilla/show_bug.cgi?id=19011 [18:49:51 CEST] <TheRyuu> inb4no replies [18:53:12 CEST] <Gramner> good post [18:58:34 CEST] <Daemon404> enjoy your GNU [18:58:46 CEST] <nevcairiel> gnus should be eaten, not reasoned with [18:59:40 CEST] <TheRyuu> honestly I don't really care what happens now, now they know about it so it's up to them to do something about it [19:00:39 CEST] <Gramner> I mean, it might break some legacy code from -92 that stores data in pointers, so it's going to get rejected. you should've suggested at least 3 new commandline flags instead [19:01:27 CEST] <TheRyuu> I even went out of my way to reject the idea of adding a command line flag in my post [19:01:37 CEST] <TheRyuu> I guess I'm doing it wrong [19:01:56 CEST] <nevcairiel> Gramner: and usually MS is into those weird-ass backwards compat things [19:02:29 CEST] <nevcairiel> (like largeaddressaware which actually makes it 32-bit for pointers, and not just 31) [19:02:36 CEST] <nevcairiel> +use [19:02:59 CEST] <Gramner> I guess "ms is doing it, so we're doing the opposite" is a possible explanation (which is also usually an ms tactic) [19:03:50 CEST] <wm4> GNU usually prefers the most broken and awkward solution to anything [19:04:07 CEST] <TheRyuu> granted the reloc section shit is actually broken compared to my other suggestions [19:04:30 CEST] <TheRyuu> and should probably be fixed regardless of whatever else happens with it [19:33:26 CEST] <cone-328> ffmpeg 03Alex Smith 07master:6e61231d641b: configure: Disable automatic image base calculation [20:13:28 CEST] <kierank> durandal_1707: no [20:25:14 CEST] <cone-328> ffmpeg 03Henrik Gramner 07master:7ca1de5b4f1a: checkasm/x86: Correctly handle variadic functions [21:40:27 CEST] <fritsch> https://github.com/01org/libyami/blob/master/encoder/vaapiencoder_hevc.cpp#… <- I think the libva version that will actually define VAAPI_PROFILE_HEVC_MAIN10 [21:40:33 CEST] <fritsch> they will release some day? [21:42:36 CEST] <wm4> oh wait is that the official libyami repo? [21:43:03 CEST] <fritsch> jep [21:43:09 CEST] <fritsch> but see: https://github.com/01org/libyami/commit/bb75c8d35ded275b7511d70913683f77b83… [21:43:15 CEST] <fritsch> at least he knows something we don't :-) [21:43:38 CEST] <fritsch> let me spam his github :-) [21:43:39 CEST] <fritsch> and ask [21:49:52 CEST] <JEEB> nice s tuff [21:50:46 CEST] <wm4> call me if there's a driver/hw combination where this works [21:51:34 CEST] <fritsch> i will [21:52:43 CEST] <fritsch> BtbN: https://github.com/01org/libyami/blob/master/decoder/vaapidecoder_h265.cpp <- if something concerning scaling lists is still missing [21:55:45 CEST] <BtbN> they are not missing, they just don't decode correctly. [22:11:00 CEST] <fritsch> perhaps they do something differently [22:11:05 CEST] <fritsch> to workaround some driver specialities [22:11:12 CEST] <fritsch> btw. they also have VP9 decoder in there [22:11:17 CEST] <fritsch> profile matching the hybrid-driver [22:36:33 CEST] <cone-328> ffmpeg 03Christophe Gisquet 07master:b8b8e82ea140: dnxhddec: check and report bitstream errors [22:55:07 CEST] <cone-328> ffmpeg 03Thomas Mundt 07master:2b6567722a48: h264: Fix ticket #3147 H264 - Wrong field order [22:56:46 CEST] <wm4> we should have standards for commit messages [22:59:04 CEST] <JEEB> wow [22:59:15 CEST] <JEEB> that commit message looks straight out of some corporate commit machine [22:59:27 CEST] <JEEB> not saying the fix isn't good but wow [23:07:12 CEST] <cone-328> ffmpeg 03Ganesh Ajjanagadde 07master:f1a9583305d9: ffplay: add support for interactive volume control [23:07:13 CEST] <cone-328> ffmpeg 03Ganesh Ajjanagadde 07master:fd44892073cc: doc/ffplay, ffplay: add information regarding volume control [23:27:49 CEST] <kierank> JEEB: it's a bit weirdly worded [23:28:07 CEST] <kierank> but "Default" is a verb iirc [23:29:59 CEST] <JEEB> kierank: it was the avc intra field order thing, right? [23:30:04 CEST] <kierank> yes [00:00:00 CEST] --- Mon Sep 28 2015

1 0

ffmpeg.log.20150927
by burek 28 Sep '15

28 Sep '15

[00:01:08 CEST] <c_14> freezway: ffprobe -show_entries format=format_name [00:04:39 CEST] <freezway> that shows me mov,mp4,m4a,3gp,3g2,mj2 as format_name [00:05:01 CEST] <freezway> but when i pass that into -f of ffmpeg it complains [00:05:31 CEST] <freezway> Requested output format 'mov,mp4,m4a,3gp,3g2,mj2' is not a suitable output format [00:06:15 CEST] <c_14> Pick any one of those, they're (mostly) identical. [00:06:56 CEST] <freezway> Requested output format 'm4a' is not a suitable output format [00:07:22 CEST] <c_14> Just pick mov or mp4 [00:07:24 CEST] <c_14> m4a is audio-only [00:07:35 CEST] <freezway> i want the container thats used when i output to a .m4a file [00:07:45 CEST] <freezway> yeah, and my input is audio only [00:07:52 CEST] <rsgm2> So, I tried using the concat demuxer, but it made my 3.5 minute video into a 5 second video at 19Mbits/s [00:08:20 CEST] <freezway> i have a bunch of music in video containers instead of audio containers [00:08:33 CEST] <freezway> and im trying to fix that [00:09:07 CEST] <freezway> but because of the way my script is structed i can't have it output to a file with an extension (long story) [00:09:15 CEST] <c_14> The format is called "ipod" [00:09:18 CEST] <c_14> for whatever reason [00:09:38 CEST] <freezway> okkkayyy ill try that [00:10:31 CEST] <freezway> cool that worked, thanks [00:14:17 CEST] <rsgm2> klaxa, I tried using the concat demuxer, but it made my 3.5 minute video into a 5 second video at 19Mbits/s, it is normally 150Kbits/s [00:19:19 CEST] <klaxa> huh, that's weird, how did you use it? [00:33:01 CEST] <freezway> one more question: can you get ffmpeg to NOT display every option it was compiled with? [00:33:36 CEST] <c_14> -hide_banner [00:33:45 CEST] <freezway> thanks [00:36:30 CEST] <rsgm2> klaxa, ffmpeg -f concat -i list -c copy output.webm [00:37:06 CEST] <klaxa> can you pastebin the output of ffmpeg? (the command looks right) [00:39:29 CEST] <rsgm2> yeah, one second [00:41:38 CEST] <rsgm2> klaxa, https://mega.nz/#!hhwTQaxC!PG7JQs3L0YST1DaKOaoITMsLMszghtQpKiAV3QyWT3o [00:41:53 CEST] <klaxa> i meant the console output [00:42:07 CEST] <klaxa> oh wait [00:42:09 CEST] <rsgm2> There is a lot of errors in the output, this may be what was causing my original concat problems [00:42:09 CEST] <klaxa> that is it? [00:42:18 CEST] <rsgm2> that was the console output [00:44:01 CEST] <klaxa> hmm... are all the webm files in the same "format"? [00:46:22 CEST] <rsgm2> I thought so, but I did notice a few said opus instead of vorbis [00:46:34 CEST] <rsgm2> for the audio [00:46:43 CEST] <chungy> webm is allowed to contain vorbis, opus, vp8, and vp9 [00:47:06 CEST] <klaxa> yes, but you cannot concatenate vorbis and opus [00:47:13 CEST] <klaxa> maybe re-encoding is easier after all [00:47:34 CEST] <klaxa> seeing it's 176x144 i don't think the noise added by a second encode will be very visible [00:47:49 CEST] <rsgm2> Hmm, thanks that would not be too hard to do, but I will also look into why there are a few opus when the majority is vorbis [00:48:58 CEST] <rsgm2> Thanks for the help [01:29:54 CEST] <fling> How to only keep video parts containing movement? [02:35:03 CEST] <DHE> fling: might consider the 'decimate' filter if your input can take it [02:36:57 CEST] <fling> DHE: but I want to keep audio in sync. [02:37:37 CEST] <DHE> s/input/output/ [02:38:26 CEST] <DHE> if the output supports variable FPS then it'll just jolt the framerate to maintain sync... [02:38:33 CEST] <DHE> at least that's how it works on other encoders. :) [02:38:49 CEST] <fling> ahh [02:39:06 CEST] <fling> But the input is noisy& ok, I will investigate, thanks. [02:49:09 CEST] <pinPoint> If I have an HEVC/h265 file with .mp4 extension does that make .mp4 the container and the other the codec? [02:49:44 CEST] <fling> pinPoint: probably. [02:49:51 CEST] <fling> pinPoint: what does `file` say? [02:50:14 CEST] <pinPoint> vlc says its HEVC but it has an .mp4 extension [02:51:05 CEST] <fling> pinPoint: what does `ffprobe` say? [02:51:07 CEST] <c_14> pinPoint: yes [02:51:28 CEST] <pinPoint> c_14: ok [02:54:22 CEST] <c_14> The people at the MPEG consortium are really good at naming things. [02:56:08 CEST] <fling> pinPoint: and mp4 means nothing, as the file might be renamed to any extension name. ffprobe will tell you what the container is on the Input line. [02:56:59 CEST] Action: fling seen people renaming between avi/mp4/VOB& [02:57:33 CEST] <pinPoint> it hasn't been renamed. Just pulled from a display demo [03:13:29 CEST] <pinPoint> supposed I want to output a .mp4 file with hevc codec. How do I use libx265 and output .mp4 without 'libx265: Invalid argument' [03:13:35 CEST] <pinPoint> suppose* [03:13:49 CEST] <c_14> ffmpeg -i file -c:v libx265 out.mp4 [03:14:25 CEST] <pinPoint> weird. I thought I had that [03:18:18 CEST] <pinPoint> c_14: ffmpeg -i "INK DROPS 4K (ULTRA HD)-k_okcNVZqqI.mp4" -c:v libx265 -preset slow -x265-params crf=23 -i "INK DROPS 4K (ULTRA HD)-k_okcNVZqqI.m4a" -c:a aac -strict experimental -b:a 256k INK_DROPS_HEVC_SLOW_CRF23_256k.mp4 [03:18:53 CEST] <pinPoint> Unknown decoder 'libx265' [03:19:38 CEST] <c_14> The -c:v -preset and -x265-params need to go after the -i "blah.m4a" ad before the output.mp4 [03:19:54 CEST] <c_14> *and [03:21:33 CEST] <pinPoint> I see its all about the order I guess [03:29:53 CEST] <pinPoint> thanks c_14 [09:30:16 CEST] <dannyzb> I noticed that in the FFMPEG/HLS guides online , they use "copy" as the encoding method before segmenting .. but does copy align the keyframes with the segments as required for HLS? what happens when I use COPY on an MP4 file to segmented format ? [12:12:39 CEST] <luc4> Hello! Is it possible to transcode from 1080p to 1080i? I tried this command http://stackoverflow.com/questions/22471099/how-to-convert-a-1080p-to-1080i… but it doesnt seem the result is interlaced& any idea? [12:13:53 CEST] <razzledazzle> input via pipe fails http://pastie.org/private/h1cazomvekc6lj5g4ze3w# [12:14:48 CEST] <razzledazzle> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1f8ada0] stream 1, offset 0x62e28: partial file pipe:0: Invalid data found when processing input [12:15:35 CEST] <razzledazzle> what is stream 1? shouldn't it be stream 0? [12:16:18 CEST] <razzledazzle> the video is a local file and it works when passed via -i filename [12:19:38 CEST] <JEEB> is that a file that has the index on which side? [12:19:57 CEST] <JEEB> it might just be complaining about the first stream for which it can't get info about [12:20:30 CEST] <JEEB> + you should generally test with the latest version of ffmpeg if you have an issue with an older version [12:21:07 CEST] <razzledazzle> JEEB: what do you mean by side? [12:21:34 CEST] <razzledazzle> I have tested with another video from Youtube, it works [12:21:57 CEST] <razzledazzle> the video now in question was recorded with an Android phone [12:26:25 CEST] <razzledazzle> qt-faststart echoes this: last atom in file was not a moov atom [12:38:23 CEST] <luc4> I also tried to use the interlace filter (-vf "interlace) but the result is a little weird. Opening it with vlc seems to have a different framerate. Im not probably using it properly. Anyone who can advice a proper command to interlace a progressive video? [12:44:32 CEST] <razzledazzle> the problem seems to be with seeking.. [16:04:40 CEST] <razzledazzle> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x21b2b40] stream 1, offset 0x65ea3: partial file pipe:0: Invalid data found when processing input [16:05:07 CEST] <razzledazzle> Why doesn't that happen when ss is set to something greater than 2? [20:41:39 CEST] <freezway> so I have a file in a mp4 container (audio + video container, but the file only has audio streams) and its stream says its " Stream #0:0(und): Audio: vorbis (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 105 kb/s (default)" [20:41:48 CEST] <freezway> what does that mean? is it vorbis or mp4a? [20:42:09 CEST] <JEEB> vorbis, the other thing is an identifier [20:44:45 CEST] <freezway> what exactly is an indetifier in this case [20:46:28 CEST] <JEEB> something in the container most probably, you can use L-SMASH's boxdumper to get a text dump of the container's contents to see what exactly it is :P [20:47:07 CEST] <Logicgate> hey guys [20:48:39 CEST] <freezway> hey [20:49:47 CEST] <Logicgate> I'm making software that needs to handle multiple different video input formats and output them in a specific format with FFMPEG (which I'm already doing), I want to lose as little quality as possible from the audio/video. [20:50:11 CEST] <Logicgate> Basically, I need to take any incoming video and transform it into a compatible Vine video. [20:50:37 CEST] <Logicgate> It needs to end up in an MP4 format typically recorded on either an iPhone or an Android device [20:50:59 CEST] <Logicgate> Right now these are the flags that I'm using: -c:v libx264 -c:v libfaac -ac 2 -deinterlace -b:a 128k -c:v libx264 -preset:v slow -profile:v baseline -level 3 -f mp4 -threads 0 -strict experimental -movflags faststart -vsync 2 -pix_fmt yuv420p [20:51:26 CEST] <Logicgate> The problem is that the audio quality gets deteriorated when the incoming bitrate is higher than 128 obviously [20:54:17 CEST] <c_14> Use a higher audio bitrate? [20:54:26 CEST] <c_14> Also -deinterlace is deprecated [20:54:31 CEST] <c_14> Use the yadif filter [20:55:01 CEST] <Logicgate> Would the be a way to optimize this so it accepts most incoming videos without deteriorating video quality/audio quality? [20:55:15 CEST] <Logicgate> Would the -preset veryslow work better? [20:56:19 CEST] <c_14> It'll make the video smaller [20:57:29 CEST] <Logicgate> I need it to be under 2mb [20:57:30 CEST] <Logicgate> always [23:03:10 CEST] <Dexstarrrr> $10 to the person who can get me set up with qsv encoding in Ubuntu [23:06:55 CEST] <waressearcher2> Dexstarrrr: I need money but I have no idea what qsv is [23:07:05 CEST] <Nosomy> the writer of libmfx for ffmpeg led this then. [23:07:19 CEST] <Nosomy> XD [23:07:26 CEST] <Dexstarrrr> I can't get libmfx to build [23:07:59 CEST] <Dexstarrrr> I gave up on that. Then I tried vaapi, it works with the use of Transmageddon, but the syntax is vague [23:08:11 CEST] <Dexstarrrr> then I tried libyami. Like, wtf? [23:09:05 CEST] <Dexstarrrr> So, after feeling tired, and not wanting to use windows for this.. or anything for that matter, I thought I'd try to incentivise [23:09:17 CEST] <Dexstarrrr> I'll go to $30 dollars [23:09:46 CEST] <waressearcher2> I really need new 64GB flash drive, but I don't know the answer [23:10:41 CEST] <Nosomy> libmfx is here: github.com/lu-zero/mfx_dispatch [23:11:27 CEST] <Dexstarrrr> it builds, but ffmpeg won't find it [23:11:47 CEST] <Dexstarrrr> it needs the intel sdk installed too right? [23:11:58 CEST] <Nosomy> probably [23:13:06 CEST] <Dexstarrrr> I guess I'll leave my email address here. If anyone can help, get in touch [23:13:20 CEST] <Dexstarrrr> the money will be paypal-ed [23:14:45 CEST] <Nosomy> Dexstarrrr talk to with Zeranoe, when him stay online, maybe can help [23:16:11 CEST] <BtbN> Isn't the stuff that the dispatcher did part of ffmpeg by now? [23:18:03 CEST] <Nosomy> i think not. [23:18:24 CEST] <BtbN> The actual mfx library is some closed source intel blob [23:18:32 CEST] <Dexstarrrr> yeah [23:20:11 CEST] <Dexstarrrr> whenever I try to ./configure --enable-libmfx I get libmfx not found using pkg-config [23:25:34 CEST] <nik2208> hey there [23:25:41 CEST] <nik2208> anyone in here? [23:25:44 CEST] <Dexstarrrr> dpatten91(a)gmail.com If anyone can help me out I would be incredibly greatful [23:29:40 CEST] <nik2208> Hi everyone I'd need to know what's the official (if any) PPA for mint 17.2 those I found give me this message on adding: Cannot add PPA: 'No JSON object could be decoded' [23:30:05 CEST] <BtbN> There is no official one. Best you can get are the ones linked on the homepage. [23:31:17 CEST] <nik2208> ,,,ehmm.. on the homepage? cannot find any ppa [23:31:44 CEST] <BtbN> you're not very good at finding stuff then. [23:31:51 CEST] <BtbN> http://ffmpeg.org/download.html#build-linux [23:33:28 CEST] <nik2208> Ubuntu Multimedia for Trusty this one you mean [00:00:00 CEST] --- Mon Sep 28 2015

1 0

ffmpeg-devel.log.20150926
by burek 27 Sep '15

27 Sep '15

[00:07:17 CEST] <baptiste> is the experimental flag for the aac encoder removed yet ? :) [00:12:22 CEST] <atomnuker> not yet [00:20:16 CEST] <nevcairiel> claudio still busy, I assume [00:20:58 CEST] <atomnuker> yes, he's busy working on the encoder [00:21:06 CEST] <Compn> ooo baptiste , long time no see :) [00:22:17 CEST] <iive> are there still critical bugs remaining? [00:24:22 CEST] <atomnuker> problem is the amount of testing Claudio does on every single patch is an overkill [00:24:54 CEST] <baptiste> the work is awesome though [00:25:01 CEST] <baptiste> hey Compn :) [00:25:28 CEST] <Compn> atomnuker : yes, we are all amazed someone fixed up aac encoder. thats why i was so interested in your working on it [00:41:50 CEST] <DHE> I think I'm ready to submit my patch to the mailing list [00:57:55 CEST] <jamrial> just found a case of xmm register clobbering on libswresample that the fate suit didn't catch with --enable-xmm-clobber-test [00:58:12 CEST] <jamrial> because we apparently have little to no coverage of multichannel tests [01:01:05 CEST] <BBB> checkasm!!!!! [01:01:09 CEST] <BBB> dude, seriously [01:01:12 CEST] <BBB> checkasm all these functions [01:01:39 CEST] <jamrial> heh [01:07:52 CEST] <BBB> I see you dont like the idea :-p [01:19:05 CEST] <jamrial> i might give it a try. this is the audioconvert module which is a lot like the flac dsp i added to checkasm the other day [01:19:43 CEST] <jamrial> although it deals with float audio, so a checkasm test may not be feasible [01:20:37 CEST] <Gramner> it should handle floats fine now [01:26:34 CEST] <cone-387> ffmpeg 03Christophe Gisquet 07master:e19ea0218aee: dnxhddec: indicate colorspace [01:50:02 CEST] <Compn> carl : did you mirror these new samples yet? https://trac.ffmpeg.org/ticket/2690#comment:26 [02:18:23 CEST] <cone-387> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:5c1acf0a09b0: ffserver: rm whitespace c&p leftovers from macro [02:18:24 CEST] <cone-387> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:83411d73313e: ffserver: drop error counting when parsing ACL row [02:18:25 CEST] <cone-387> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:086718e8f783: ffserver: drop unneeded branching [03:39:30 CEST] <cone-387> ffmpeg 03Rodger Combs 07master:f559812a8437: tests/checkasm: make randomize_buffers a function for easier debugging [09:51:56 CEST] <cone-626> ffmpeg 03Claudio Freire 07master:0f98fd30e2d3: AAC encoder: fix OOB access in search_for_pns [10:02:37 CEST] <TheRyuu> v2'ed the HEASLR patch and sent the seperate dynamicbase/nxcompat combined patch to the ML [11:08:51 CEST] <cone-626> ffmpeg 03wm4 07master:f290e48d86e1: mmal: drop the h264 BSF [11:08:52 CEST] <cone-626> ffmpeg 03wm4 07master:49623f531972: mmal: Remove setting extradata on input format [11:08:53 CEST] <cone-626> ffmpeg 03wm4 07master:a9b8c638cfe2: mmal: Fix AVBufferRef usage [11:08:54 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:c5a312dd6afb: Merge commit 'f290e48d86e10f34b5ddc519127636bcebec7c43' [11:08:55 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:f3310df8538d: Merge commit '49623f531972be5dc2dd8c1b4b8748cad7c424ff' [11:08:56 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:2b61cc44433e: Merge commit 'a9b8c638cfe2f82191db65e3e3a39f3b35df81f5' [11:15:55 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:588a5619da0d: dxv: Parse ancillary encoder information [11:15:56 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:fb2889691cb7: dxv: Support the original first version [11:15:57 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:bbf71d46db34: dxv: Print texture information after header parsing [11:15:58 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:1bcd4a476ba4: dxv: Support RAW intermediate compression [11:15:59 CEST] <cone-626> ffmpeg 03Vittorio Giovara 07master:b2417ee6d1ee: dxv: Improve error message [11:16:00 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:d0aec0aae872: Merge commit '588a5619da0d041e55b365f63d0fa9c72bdbd4d3' [11:16:01 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:234c7378ca19: Merge commit 'fb2889691cb7720d2680e188eb6036a35afa2392' [11:16:02 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:f6048e4920de: Merge commit 'bbf71d46db3417b43bcbd745cbf235e8e2ff69ae' [11:16:03 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:b4ea8a730521: Merge commit '1bcd4a476ba45a7fdf59d1701b8f0e274418cc32' [11:16:04 CEST] <cone-626> ffmpeg 03Hendrik Leppkes 07master:9c3c8d2c5602: Merge commit 'b2417ee6d1ee0c5e9b170a642d73bdf68908966f' [11:27:54 CEST] <anshul> is there any encryption or encoding done when mails are sent to mailing list, because mails from ffmpeg-devel mailing list when saved to .eml file looks like encrypted [11:35:41 CEST] <TheRyuu> isn't there some base64 stuff going on [12:21:08 CEST] <Compn> anshul : probably just your mail client compressing emails [12:32:32 CEST] <DHE> anshul: could be user error. (ie mine) [12:32:50 CEST] <nevcairiel> the patch on the ML is fine [12:32:59 CEST] <nevcairiel> its user error alright, but not yours =p [12:34:12 CEST] <nevcairiel> well, mostly fine. copy-pasting a patch into a mail will often break, so either use git send-email to send it directly as a mail, or just attach it [12:38:38 CEST] <DHE> yeah I'll do that next time... [12:39:11 CEST] <DHE> anyway, that closed caption patch has been tested (by me) on a set top box vendor and some mobile video players. [12:49:54 CEST] <cone-626> ffmpeg 03Ronald S. Bultje 07master:7a4b97e946f5: checkasm: clip vp9 loopfilter test pixels inside allowed bitdepth range. [12:49:58 CEST] <anshul> DHE: testing that new attached patch [12:50:35 CEST] <anshul> and with which set top box you tested it, just for info [12:50:48 CEST] <DHE> anshul: Entone Kamai 500 and Amulet 450 series [12:51:08 CEST] <DHE> also is there a command that checks the whitespace thing? [12:52:24 CEST] <anshul> I get those warning with git apply, and if you reset and do git diff then it show in red marks [12:52:57 CEST] <JEEB> anshul: just fyi the ARIB (ISDB) captions are in a separate PID so they're not together with the things that use stuff within the video stream [12:53:15 CEST] <JEEB> unless the countries that adopted ISDB that are not japan went for something else :D [12:54:28 CEST] <DHE> why have I never seen that before? [12:54:49 CEST] <DHE> I'm gonna blame github for making me complacent [12:56:23 CEST] <anshul> JEEB: yes I know, but there ts is totally different, i ran into lot of problem when I was implemting closed caption and using ffmpeg mpegts muxer [12:57:15 CEST] <anshul> so I was asking if we have some flags in ts that could suggest whether they are dvb or isdb [12:58:47 CEST] <anshul> Compn: I see that message source same in web gmail ui and thunderbird, and if it is compression then why its done only to mails from mailing list [13:00:46 CEST] <anshul> DHE: it was not your error on that mail since i see source of simple mails with question in ffmpeg-user, i see them encrypted if i save it as .eml or in gmail use show source [13:05:41 CEST] Action: DHE is testing out how git-send-email works now... [13:16:21 CEST] <anshul_> DHE: I am not able to use the command here is pastebin http://pastebin.com/gqjJkrzC [13:17:40 CEST] <anshul_> am i using that option incorrect [13:19:44 CEST] <DHE> use "-a53cc 1" [13:20:02 CEST] <DHE> -x264opts are given the x264 library directly and it doesn't have such a command [13:23:08 CEST] <anshul_> ok got it thanks [13:24:19 CEST] <DHE> does this suggest the doc part needs fixing? [13:24:26 CEST] <anshul_> DHE: if you find it ok then add the command with -a53cc in encoder.texi [13:24:44 CEST] <anshul_> yes there may be more lame user like me [13:26:52 CEST] <anshul_> I tested it your patch works fine with ccextrator too. :) [13:27:44 CEST] <DHE> now it shows "a53cc _boolean_". the description still says 0 means off so I'm hoping that's enough. [13:30:00 CEST] <DHE> still messing with send-email before I actually use it to post to the list [13:31:17 CEST] <anshul_> DHE: generally I dont use git send-email, i prefer git format-patch -1. but majority of people here prefer git-send-email [13:51:36 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:10bbf6cf622f: avcodec/ffv1dec: Explicitly check read_quant_table() return value [13:51:37 CEST] <cone-626> ffmpeg 03Michael Niedermayer 07master:2d221d9e069e: avcodec/ffv1dec: Fix off by 1 error in quant_table_count check [13:53:03 CEST] <BtbN> I guess the OpenCL maintainer(s) isn't/aren't the most active [14:14:18 CEST] <mahesh> Hi hello i am mahesh . i would like to start contributing to ffmpeg [14:14:26 CEST] <mahesh> how should i start with ? [14:14:35 CEST] <mahesh> got my git cloned . THen? [14:14:41 CEST] <Compn> mahesh : try building ffmpeg [14:14:45 CEST] <JEEB> start by compiling it, and then looking at what you wanted to work on [14:14:47 CEST] <Compn> make sure you can build and test ffmpeg. [14:15:05 CEST] <JEEB> for the tests you do need the FATE suite though, so that can take quite a bit of time :P [14:15:13 CEST] <JEEB> or at least a part of the suite [14:15:23 CEST] <mahesh> any page how to compile , build [14:15:25 CEST] <mahesh> ? [14:15:28 CEST] <mahesh> Please [14:15:39 CEST] <Compn> mahesh : yes on ffmpeg.org , one sec [14:15:54 CEST] <Compn> mahesh : https://trac.ffmpeg.org/wiki/CompilationGuide [14:16:06 CEST] <mahesh> thank you comp [14:16:15 CEST] <JEEB> those compilation guides tend to have the kitchen sink, it's really not that hard :) [14:16:20 CEST] <JEEB> what OS are you on? [14:16:27 CEST] <mahesh> i am on ubuntu [14:16:40 CEST] <JEEB> then you just need build-essential(s) and yasm [14:17:12 CEST] <JEEB> then make an ffmpeg_build directory somewhere and run the configure script from the cloned directory [14:17:41 CEST] <mahesh> yes [14:17:43 CEST] <mahesh> thank you [14:17:46 CEST] <JEEB> so for example if I have directories ffmpeg and ffmpeg_build next to each other, I go into ffmpeg_build and do `../ffmpeg/configure` [14:17:50 CEST] <JEEB> that should be enough [14:18:01 CEST] <JEEB> it should output the configuration [14:18:12 CEST] <JEEB> and after that by using make you should be able to get it building [14:19:01 CEST] <mahesh> referring to the document or page i can do it right ? without hiccups [14:19:46 CEST] <JEEB> yes, the document should be alright, but it has all kinds of libraries etc. there :P [14:19:56 CEST] <mahesh> yes thank you [14:20:09 CEST] <mahesh> do i need to take all the libraries [14:20:12 CEST] <JEEB> no [14:20:21 CEST] <JEEB> as I said you can just have build-essential and yasm installed [14:20:26 CEST] <JEEB> and then you can run the configure script [14:20:42 CEST] <JEEB> that will give you a basic configuration ffmpeg [14:21:23 CEST] <JEEB> you might need to add more libraries depending on if you're working on a wrapper or whatever, but the very basic thing is what you should start with [14:22:14 CEST] <mahesh> superb ... thats a lot help jeeb [14:22:19 CEST] <mahesh> thank you so much [14:22:30 CEST] <JEEB> lorf [14:22:50 CEST] <Compn> and thus another developer was born [14:22:56 CEST] <Compn> good job JEEBster [14:23:53 CEST] <JEEB> I can never remember if the package is build-essential or build-essentials, and I always end up ssh'ing into a ubuntu box and searching [14:24:08 CEST] <BtbN> build-esse<TAB> [14:26:45 CEST] <JEEB> BtbN: that only works if you're already in a terminal so the ssh part doesn't change :P [14:26:58 CEST] <JEEB> also it only works if you're not already sudo -s -H'd as root [14:27:15 CEST] <BtbN> why wouldn't bash-completion work as root? [14:27:31 CEST] <JEEB> many things don't enable it for the root users [14:27:50 CEST] <JEEB> *user [14:27:57 CEST] <JEEB> if you do just sudo -s it works in ubuntu [14:28:02 CEST] <JEEB> but -H strips that [14:28:26 CEST] <JEEB> I think debian's sudo default might be different, I think there even without -H it doesn't work [14:28:47 CEST] <BtbN> Use -i then [14:29:23 CEST] <JEEB> but yeah, I agree there's enough of ways :) [14:37:12 CEST] <mahesh> i am compiling ffmpeg . can i directly install those packages without needing to build , but directly from sudo apt-get install ? for eg:yasm,libx264-dev [14:37:52 CEST] <durandal_1707> BtbN: you have questions about keyspill removal for colorkey filter [14:38:51 CEST] <JEEB> mahesh: if you haven't even built basic ffmpeg yet, just install yasm from apt-get for now (it's a tool btw, not a library used in ffmpeg) together with build-essential [14:38:56 CEST] <BtbN> I haven't bothered with that at all yet. [14:39:11 CEST] <BtbN> The results are quite ok with out it already though [14:39:17 CEST] <mahesh> what about other libs ? [14:39:26 CEST] <mahesh> @jeeb [14:39:50 CEST] <mahesh> libx264-dev [14:40:00 CEST] <BtbN> I think i'd have an idea how to do it with the colorkey filter, as it's RGB based. But not too sure about (Y)UV chromakey. [14:40:58 CEST] <BtbN> And the colorkey filter is the one where it basicaly doesn't matter, as it's intended for removing pink backgrounds from static images and stuff like that. [14:41:14 CEST] <iive> does somebody know why firefox includes libvpx encoder and what does it use it for? [14:41:46 CEST] <BtbN> Because they are years behind on their audio/video agenda. [14:42:41 CEST] <iive> my question is more like... why they need encoder... [14:43:00 CEST] <JEEB> mahesh: your first thing is to get ffmpeg itself building. don't care about any other libs for now [14:43:08 CEST] <JEEB> I mean, you get most decoders within ffmpeg itself [14:43:13 CEST] <JEEB> and a lot of encoders [14:43:26 CEST] <JEEB> also please don't send private messages to me [14:43:29 CEST] <JEEB> it's rude [14:43:52 CEST] <iive> BtbN: and to be clear... perf top indicates that vp9_ssim_parms_8x8_sse2 is the main function slowing down my startup/shutdown . [14:44:25 CEST] <mahesh> Jeeb : sorry [14:44:55 CEST] <mahesh> Jeeb : so just with the above yasm and the build essentials are enough . no need to go below it for installation [14:44:58 CEST] <mahesh> ? [14:45:29 CEST] <JEEB> yes, after that you should have the configure script work without any parameters [14:45:47 CEST] <JEEB> and a nice output of all decoders, encoders, demuxers etc. that are enabled with that configuration [14:48:50 CEST] <BtbN> iive, uhm, what? [14:49:07 CEST] <iive> BtbN: yeh... my question exactly. [14:50:59 CEST] <iive> BtbN: something in firefox uses the encoder, and that function works a lot.... for not so short periods of time, hanging the browser... [14:51:42 CEST] <mahesh> Jeeb : wget http://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 . Is this necessary ? [14:52:14 CEST] <JEEB> didn't you say that you already cloned it? [14:52:19 CEST] <JEEB> I mean, FFmpeg [14:52:59 CEST] <JEEB> if you are going to try and develop FFmpeg then you will most probably want to use git to be able to work with your changes and FFmpeg updates easily :P [14:53:22 CEST] <JEEB> for just compilation of a random ffmpeg version that of course doesn't matter [14:53:22 CEST] <mahesh> thats the place where i had confusion . because i had git cloned [14:53:38 CEST] <JEEB> then you just use the git clone you have [14:53:58 CEST] <mahesh> thank you jeeb ... [14:54:00 CEST] <JEEB> it's not rocket science: have build-essential and yasm, then run the configure script within the FFmpeg code :P [14:54:21 CEST] <JEEB> then you get the output of the configure script on the terminal, most probably without errors and showing you a very long list of stuff that was enabled [15:06:14 CEST] <durandal_1707> iive: its encoding your camera video and seending away [15:06:42 CEST] <iive> durandal_1707: good thing i don't have camera plugged in :P [15:20:06 CEST] <cone-626> ffmpeg 03Henrik Gramner 07master:2ab65b652dc5: checkasm: Use a self-balancing tree [15:34:26 CEST] <cone-626> ffmpeg 03Paul B Mahol 07master:4cf60b4fa12f: avfilter/vf_blend: add addition128 mode [16:44:03 CEST] <cone-626> ffmpeg 03Christophe Gisquet 07master:e4b7c3a9f21b: dnxhddec: proper rule for interlaced mb flag [17:44:09 CEST] <cone-626> ffmpeg 03Christophe Gisquet 07master:dc218bd08305: dnxhddec: parse and print adaptive color transform [18:44:42 CEST] <cone-626> ffmpeg 03Ganesh Ajjanagadde 07master:db9de9b954a7: avformat/hls: remove unused function [18:53:55 CEST] <Gramner> is anything other than two's complement supported in ffmpeg? e.g. can I use -1 to set all bits in an integer? [18:54:20 CEST] <wm4> (unsigned type)-1 should always be valid to set all bits [18:54:32 CEST] <wm4> (even in 100% language-lawyer conformant C) [18:55:48 CEST] <BtbN> Are there seriously platforms that don't use it? [18:55:54 CEST] <wm4> no [18:57:44 CEST] <Gramner> I belive two's complement, one's complement, and sign-magnitude are allowed according to the C standard [19:00:26 CEST] <nevcairiel> that concept is used in other places as well [19:00:30 CEST] <nevcairiel> so just do [19:00:40 CEST] <Gramner> ok, thanks [20:34:53 CEST] <cone-626> ffmpeg 03Timo Rothenpieler 07master:31ee86cd9869: avutil/opencl: Fix volatile pointer [20:43:25 CEST] <iive> Gramner: two's complement is mandatory for ffmpeg. [20:45:18 CEST] <Gramner> i see, good to know [20:47:28 CEST] <wm4> iive: where does it say that? [21:11:01 CEST] <kurosu> IEEE754 32bits floats is also a requirement in ffmpeg - a lot of code does bitwise operations according to this [21:11:27 CEST] <kurosu> (audio codecs obviously do it a lot) [21:36:11 CEST] <cone-626> ffmpeg 03James Almer 07master:af990d72b7e3: checkasm/Makefile: add missing testclean target [21:36:12 CEST] <cone-626> ffmpeg 03James Almer 07master:4e03f0ab08e2: checkasm/vp9dsp: add const to suppress "discards const qualifier" warnings [21:51:00 CEST] <J_Darnley> iive Gramner wm4: I'm sure I've read that two's complemet is required, but I can't find it in any of the files in git. [22:06:02 CEST] <Gramner> maybe it should be documented somewhere if that's the case. I know that x264 does, along with signed right-shift and >=32 bit int [22:15:49 CEST] <J_Darnley> Ah, maybe it was in x264 some where that I read it. [22:16:17 CEST] <J_Darnley> oh yes: doc/standards.txt [22:16:24 CEST] <cone-626> ffmpeg 03Henrik Gramner 07master:ad9a543e9351: avutil/avstring: Inline some tiny functions [22:18:15 CEST] <kurosu> ">=32 bit int" is also a requirement in ffmpeg [22:19:09 CEST] <kurosu> some code used (int scalar product dsp) or is using int instead of int32_t [00:00:00 CEST] --- Sun Sep 27 2015

1 0

ffmpeg.log.20150926
by burek 27 Sep '15

27 Sep '15

[00:52:24 CEST] <foreverska> Anyone want to take a guess at what processor it would require to do a realtime h.264 encode of raw 1920x1080 [00:52:59 CEST] <fritsch> better get a dedicated gpu [00:53:07 CEST] <fritsch> using nvenc or vaapi encoding [00:53:20 CEST] <fritsch> and it's not really a resolution issue but a fps issue [00:53:27 CEST] <fritsch> 1080p@5 :-) i can do for you [00:54:18 CEST] <chungy> x264 [00:54:31 CEST] <chungy> x264's ultrafast preset works with 1920x1080 even on fairly old CPUs :P [00:54:51 CEST] <chungy> It produces huge files/streams, better have the bandwidth for it :D [00:54:52 CEST] <foreverska> lol my machine can stream 1080@15 [00:57:42 CEST] <foreverska> I'd like to see good quality at 25fps. The dream would be to throw out three feeds at once, 1080, 720 and SD [01:02:29 CEST] <foreverska> Maybe I'll look into nvenc. Couldn't hurt as the need grows. [01:26:09 CEST] <DHE> depending on your quality needs I'm doing fine on a not-too-unusual core i7 [01:41:17 CEST] <foreverska> Is 1080 always 1080? Like 1080 recorded from my desktop vs 1080 fed from a blackmagic capture card? [01:41:27 CEST] <foreverska> As far as processing requirements go. [01:42:52 CEST] <DHE> image complexity and framerate will have impacts. I mostly deal with 30fps interlaced (over the air signals) [01:45:25 CEST] <foreverska> Our native format right at this second is 1080i(a)59.96. I've done 1080@60 screen records on my home pc, that should be comparable right? [02:11:36 CEST] <JodaZ> don't capture cards encode for you sometimes? [02:12:52 CEST] <foreverska> Not BMs. They just blurt out massive data streams [07:17:28 CEST] <mnero> is there any parameter to override the rtp payload type? [07:18:13 CEST] <mnero> like if I want h264 to be 126 instead of 96 [07:31:37 CEST] <bairav> i`m trying to create mpeg-ts file with opus audio but its not working [07:33:07 CEST] <bairav> help me [07:34:00 CEST] <bairav> i`m using ffmpeg 2.8 [08:15:09 CEST] <zenny1> Hi, how can one get rid of color keyspill and edge blur after applying color key filter in ffmpeg 2.8? [08:23:39 CEST] <durandal_170> you can't, yet [08:23:55 CEST] <zenny1> :( [08:24:54 CEST] <zenny1> Pretty excited about the color key, but seems to lack fine tuning filter parameters like keyspill removal and blur! [08:25:36 CEST] <zenny1> Without them, colorkey filter cannot be used in practical sense, or?! [08:36:42 CEST] <zenny1> According to changelog (https://raw.githubusercontent.com/FFmpeg/FFmpeg/release/2.8/Changelog) it seemed like colorkey seems to be the prominent feature of the release as it stood on top of changelog, but not really applicable. Pity! :( [09:21:12 CEST] <dasdas> hello everybody please where can i find ffserver ? [09:22:47 CEST] <dasdas> i mean downloading it [11:01:20 CEST] <anshul> all mails from ffmpeg user mailing list and ffmpeg-devel mailing list are encrypted when I look source [11:01:49 CEST] <anshul> even file saved as .eml and applying patch of it is also not working [11:02:53 CEST] <anshul> while mails from other friends are looking good in .eml file its just problem with ffmpeg mailing list [11:03:46 CEST] <anshul> anyone know any method to save encrypted mails in normal format, or git am those encrypted message [11:08:38 CEST] <chungy> encrypted how? [11:09:15 CEST] <chungy> and what is a .eml? [11:10:34 CEST] <anshul> when i open the email source it like following http://pastebin.com/qWwnHi2u [11:11:05 CEST] <anshul> .eml is file format to save emails [11:11:12 CEST] <chungy> odd. That's base64 encoded, you can just use "base64 -d" to decode it... [11:11:39 CEST] <chungy> probably an attachment [11:13:04 CEST] <anshul> no it was not attachment, it was like this before http://pastebin.com/JLqqCbUj [11:13:50 CEST] <anshul> My mail client show this mail properly but when I apply this email as patch git does not understand it [11:14:33 CEST] <chungy> yeah, git doesn't know about base64 encoding (it's the encoding used for attachments though) [11:14:42 CEST] <chungy> your mail client probably has a way to save attachments as plain files. [11:16:12 CEST] <anshul> no its not attachment, i am using well known thunderbird as my mail client [11:20:42 CEST] <anshul> there are all ffmpeg-user message encoded and I cant see there question(not attachment) in source [11:52:30 CEST] <anshul> I checked it with gmail webclient same problem [15:57:49 CEST] <noone_> hi guys [15:58:23 CEST] <noone_> how would I automatically create an .m3u8 multi-bitrate file using ffmpeg ? [15:59:42 CEST] <BtbN> you don't. [15:59:48 CEST] <RobotsOnDrugs> m3u8 is text [15:59:54 CEST] <noone_> something like in this example where I have lo/mid/hi profile and then merge those in one main file so the video can automatically shift [15:59:56 CEST] <noone_> http://stackoverflow.com/a/1070979/4916078 [16:00:15 CEST] <BtbN> You'll have to do that yourself, ffmpeg only creates simple playlists. [16:02:15 CEST] <noone_> yes, I would like to automatically create lo / mid / hi playlist and then one main playlist containing all three so the video can adjust and stream nicely even on the low bandwith [16:02:36 CEST] <noone_> like in that example I posted from stackoverflow [16:02:46 CEST] <BtbN> <BtbN> You'll have to do that yourself, ffmpeg only creates simple playlists. [16:03:48 CEST] <noone_> so I can't merge them into one main playlist ? [16:03:56 CEST] <BtbN> you can, ffmpeg can't. [16:03:56 CEST] <noone_> after creation [16:05:18 CEST] <noone_> ok, thanks for your answer [16:52:31 CEST] <web5|org|ua> Hey, can i use multiple cuts in one action & one input audio ? I would like to take several slices from the input and put it in one out piece ? [19:58:42 CEST] <NapoleonWils0n> hi all [19:58:53 CEST] <NapoleonWils0n> is there a way to hide dts pts errors [20:02:53 CEST] <NapoleonWils0n> im just piping sterr to stdout and using sed to remove the errors at the moment [22:03:36 CEST] <FiyreWyrkz> I'm hoping someone can help with transcoding a video downloaded from youtube (currently in an .flv that won't play as is) to play on a video mp3 player for my niece. It's a cheapo product and claims according to the manual that it supports for video (AVI/Xvid, WMV, FLV, 3GP, and RM/RMVB - in QVGA 320x240) and audio (MP3, WMA, APE, FLAC, OGG 32kbps-320kbps) [22:04:44 CEST] <FiyreWyrkz> I've tried "ffmpeg -i foo.flv -vcodec wmv2 -s qvga -acodec wmav2 foo.wmv" [22:05:09 CEST] <FiyreWyrkz> I'm not very fluent with ffmpeg options and would appreciate any thoughts [22:34:32 CEST] <klaxa> FiyreWyrkz: looks mostly correct, what went wrong? [22:34:59 CEST] <klaxa> you can try mpeg4 or libxvid as videocodecs too [22:37:14 CEST] <FiyreWyrkz> I get a file format error from the player - I'm trying in .avi playing with some preset options from WinFF altering them to output to QVGA/320x240 [22:39:45 CEST] <waressearcher2> is that correct: "ffmpeg -ss 40 -i in.avi -ss 40 -i in.wav -c copy -map 0:v:0 -map 1:a:0 -shortest -t 870 -y -f avi out.avi" ? [22:40:04 CEST] <waressearcher2> or should I also have two "-t 870" after each "-i" ? [22:42:03 CEST] <klaxa> you only need one -t since you only have one output [22:42:07 CEST] <klaxa> so yes, looks okay [22:42:14 CEST] <waressearcher2> like that: "ffmpeg -ss 40 -i in.avi -t 870 -ss 40 -i in.wav -t 870 -c copy -map 0:v:0 -map 1:a:0 -shortest -y -f avi out.avi" ? [22:43:03 CEST] <klaxa> not sure if because of seeking it might get A/V sync issues [22:43:10 CEST] <waressearcher2> should I use or remove "-shortest" ? [22:43:27 CEST] <klaxa> depends on what you want [23:30:56 CEST] <rsgm2> I am trying to concat 200 or so audio/video webm files that are 1 second each. I concat the video and audio seperatly, the video works completely fine and comes out to 3.5. The audio however comes out to be 2 minutes long, here is the audio command: http://pastebin.com/rDN1jPDs [23:31:24 CEST] <rsgm2> Has anyone encountered this problem? [23:52:37 CEST] <klaxa> have you tried just using the concat demuxer? https://trac.ffmpeg.org/wiki/Concatenate [23:53:23 CEST] <rsgm2> No, I will take a look at what that is, thank you [23:58:09 CEST] <freezway> can you get ffmpeg to tell you what format it used for the output in a way that is compatible with itself? [23:58:50 CEST] <freezway> like i want to convert and have the output file have no extension, but without the extension it doesn't know what to use for -f. [00:00:00 CEST] --- Sun Sep 27 2015

1 0

ffmpeg-devel.log.20150925
by burek 26 Sep '15

26 Sep '15

[00:07:55 CEST] <cone-643> ffmpeg 03Michael Niedermayer 07master:aa6c43f3fdec: avcodec/ffv1: seperate slice_count from max_slice_count [04:18:56 CEST] <rcombs> anyone object to https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179207.html? [04:21:27 CEST] <philipl> Don't some subtitles have durations? [04:21:41 CEST] <rcombs> they usually do! [04:22:11 CEST] <rcombs> but sometimes they're very long, and subtitle "frames" can overlap (unlike video or audio) within a single stream [04:23:05 CEST] <rcombs> I've got a file here with several events in the first several packets that have a combined duration several times longer than the total duration of the whole file [04:23:40 CEST] <rcombs> which results in avformat_find_stream_info thinking it's hit its max analyze duration and giving up [04:41:21 CEST] <philipl> I see. Fair enough. [04:42:54 CEST] <rcombs> I also considered just skipping subtitles altogether when deciding whether or not to bail out early in find_stream_info [04:43:24 CEST] <rcombs> I don't really have a strong opinion either way [04:43:32 CEST] <rcombs> but the current behavior is pretty clearly broken [04:53:16 CEST] <philipl> That seems the case. I think either approach is reasonable. [09:17:27 CEST] <cone-723> ffmpeg 03Claudio Freire 07master:9458a62decfc: AAC encoder: tweak PNS usage to be more aggressive [10:03:20 CEST] <j-b> Daemon404: yes [11:59:23 CEST] <ubitux> just curious, anyone aside from wm4 & myself willing to work with libav for the m:n async api model? BBB maybe (not here :()? [11:59:38 CEST] <nevcairiel> i am [11:59:53 CEST] <ubitux> any suggestion on how to approach this? [12:00:09 CEST] <ubitux> i mean, from the cooperation aspect, not technical one [12:00:56 CEST] <wm4> (rcombs also seemed to be interested) [12:01:16 CEST] <wm4> ubitux: well, we need to decide on a mailing list? [12:01:25 CEST] <wm4> where the discussion happens, and maybe patches [12:02:25 CEST] <ubitux> do you think it's possible/overkill to have a temporary 3rd mailing list to avoid butthurts? [12:02:33 CEST] <nevcairiel> just use theirs and dont think too much about it [12:02:53 CEST] <ubitux> okay [12:04:15 CEST] <ubitux> could be nice to send to both though [12:04:39 CEST] <ubitux> with the fear that it might degenerate fast [12:05:10 CEST] <nevcairiel> that always ends up silly for people that are not subbed to both, since people often forget to hit reply all [12:05:14 CEST] <wm4> cross-ML posts are icky [12:05:19 CEST] <wm4> they get broken really quick [12:06:30 CEST] <saste> ubitux, or you set up a new common mailing-list, but that might now work [12:06:44 CEST] <saste> so the safe bet is to use libav-devel [12:07:26 CEST] <ubitux> yeah, i can deal with it, but it might be nice to keep ffdev up-to-date; maybe some summaries should be sent on a regular schedule [12:08:04 CEST] <wm4> just send a mail to ffmpeg-devel that the new API is discussed on this and that thread [12:08:15 CEST] <ubitux> yeah, that was what i had in mind [12:31:42 CEST] <durandal_1707> 10 minutes of fuzzing nut+ffv1 and there already found hang [12:56:28 CEST] <haasn`work> nevcairiel: ping, wm4 told me to ask you about YV12->NV12 conversion on the CPU; you said it's as fast as memcpy? Is there a helper somewhere in ffmpeg libs? [12:57:20 CEST] <haasn`work> And mostly I'm wondering if this would improve rendering performance; currently we do the conversion on the GPU but it's slowing down on some iGPUs that suffer from the extra render pass [12:57:42 CEST] <haasn`work> So doing it on the CPU might be considerably easier [13:05:37 CEST] <JEEB> haasn`work: I'm pretty sure he wrote it himself [13:05:48 CEST] <JEEB> unless the swscale one suddenly got faster [13:05:54 CEST] <wm4> (haha) [13:06:05 CEST] <JEEB> check his repo @ http://git.1f0.de/gitweb?p=lavfsplitter.git;a=summary;js=1 [13:14:18 CEST] <durandal_1707> michaelni: found hang in ffv1, interested in sample? [13:15:39 CEST] <Compn> durandal_1707 : yes he is, just upload it somewheres and give him filename/link [13:19:45 CEST] <kierank> durandal_1707: open ticket [13:19:52 CEST] <kierank> durandal_1707: do you want access to the dev machine? [13:20:50 CEST] <durandal_1707> I'm on somehow already on powerful [13:21:25 CEST] <durandal_1707> Unless it have 16 cores.... [13:23:39 CEST] <Compn> no build enviro for compn to test bugs :( [13:29:05 CEST] <BBB> haasn`work: isnt that just nv12enc in ffmpeg? [13:29:29 CEST] <BBB> haasn`work: and yes perhaps that shouldve been in swscale, but its not [13:37:32 CEST] <wm4> fritsch: fernet is not on this IRC channel, or is he? [13:41:58 CEST] <fritsch> wm4: nope - but you reach via email easily [13:42:20 CEST] <fritsch> wm4: or - just add your comment to his commits - that's all squash stuff done by him and me [13:42:35 CEST] <fritsch> wm4: if it is about vaapi / egl [13:42:57 CEST] <wm4> yes... I got the vaapi egl interop to work yesterday, but to use it by default, I need to detect its presence on loading [13:43:11 CEST] <wm4> because for vdpau and old Mesa we still need GLX [13:43:23 CEST] <wm4> but it seems the only way to detect it is to actually try it [13:44:11 CEST] <fritsch> yes, you are right [13:44:17 CEST] <fritsch> can't you just check for the extension? [13:45:19 CEST] <wm4> which one? the closest I know is EXT_image_dma_buf_import, but that is available in Mesa 10 [13:46:35 CEST] <fritsch> https://github.com/FernetMenta/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDC… <- check for this? [13:46:48 CEST] <fritsch> which is used for creating the image? [13:48:02 CEST] <wm4> the code you're pointing to doesn't even check for the extension correctly (unless this is done elsewhere) [13:48:13 CEST] <fritsch> nope, we know that it will work [13:48:14 CEST] <fritsch> :-) [13:48:17 CEST] <wm4> anyway, they are available on Mesa 10 too [13:48:20 CEST] <fritsch> and no nullptr is returned [13:48:25 CEST] <fritsch> yeah, it's about the attribs [13:48:30 CEST] <fritsch> that method gets passed [13:49:42 CEST] <fritsch> perhaps trying to create an empty elgImageY from a mapped buffer? [13:49:51 CEST] <fritsch> and see if the resulting thing is an image? [13:50:09 CEST] <wm4> at this point it's more convenient to just probe it by running the code [13:50:13 CEST] <wm4> I hoped for a more elegant way [13:50:20 CEST] <fritsch> yeah - I don't know of any [13:50:30 CEST] <fritsch> but you could ask: chadv or bwidawski in #intel-gfx [13:50:45 CEST] <fritsch> they are intel's egl experts and perhaps know [13:51:22 CEST] <wm4> oh, thanks for the tip [13:53:14 CEST] <fritsch> yeah, let's wait - they will appear in some hours [14:46:47 CEST] <cone-019> ffmpeg 03Michael Niedermayer 07master:b2955b6c5aed: avcodec/rangecoder: Check e [14:50:46 CEST] <michaelni> durandal_1707, should be fixed [16:09:14 CEST] <saste> I'm getting no mail reply from Lukasz, is he ever online? [16:11:00 CEST] <Daemon404> no [16:11:28 CEST] <Daemon404> afaik he quite the communit when his dir listing thing was not well accepted by people [16:11:31 CEST] <Daemon404> quit* [16:13:20 CEST] <saste> ok, thanks [16:13:53 CEST] <wm4> drama [16:14:27 CEST] <JEEB> oh wow [16:17:12 CEST] <fritsch> wm4: no reply yet, right? [16:18:31 CEST] <wm4> fritsch: I didn't send a mail if you mean that [16:19:41 CEST] <fritsch> wm4: nope on irc [16:19:51 CEST] <fritsch> just though you got something new [16:20:05 CEST] <fritsch> btw. our vaapi 10 bit discussion you might have followed lately [16:20:36 CEST] <fritsch> it was forwarded to the "OTC [16:20:36 CEST] <fritsch> Media architect and responsible for driver development and features [16:20:37 CEST] <fritsch> for VAAPI at Intel." [16:20:44 CEST] <fritsch> guy [16:21:03 CEST] <fritsch> he then explained us, that hevc is supported on broadwell (!) and braswell [16:21:13 CEST] <fritsch> which is not right ... [16:21:27 CEST] <fritsch> but yeah, i kindly asked him to give us a solution for 10 bit content [16:21:32 CEST] <fritsch> no reply yet [16:22:24 CEST] <wm4> 10 bit with hevc? [16:23:04 CEST] <Compn> some devs here are good at telling other devs that their work is terrible [16:23:05 CEST] <Compn> :( [16:23:25 CEST] <Compn> vlc 3.0.0 now has dir listing support in http/ftp etc [16:23:44 CEST] <Compn> or will soon [16:24:56 CEST] <fritsch> wm4: yes - the gpu assisted work [16:25:12 CEST] <fritsch> wm4: that there already is on windows or even 8 bit hevc work which is there for broadwell [16:25:34 CEST] <fritsch> i think you were also online when we talked with __gb__ [16:26:44 CEST] <wm4> ok [16:26:57 CEST] <wm4> Compn: it still doesn't belong into libavformat, and most agreed with that [16:27:51 CEST] <Daemon404> Compn, you cant just accept every idea and design as good [16:33:27 CEST] <kierank> vlc isn't a multimedia library though [16:33:41 CEST] <Daemon404> that too [17:10:18 CEST] <nevcairiel> Compn: we never argued its a bad feature as such, and a player might be the right place to have it, but our only argument was that avformat isnt the right place [17:10:39 CEST] <Daemon404> yep [17:10:59 CEST] <cone-019> ffmpeg 03Michael Niedermayer 07master:25df7b1c35bf: avcodec/ffv1dec: Fix >8bps error concealment [17:20:13 CEST] <cone-019> ffmpeg 03Pedro Arthur 07master:a8602dde5e0a: swscale: fix ticket #4877 [17:23:05 CEST] <cone-019> ffmpeg 03Lucas de Andrade 07master:770dd105044d: avformat/hls: Update Cookies response with Setcookie [17:23:24 CEST] <ubitux> we need one more vote for the voting comittee; michaelni? reynaldo? jamrial? [17:25:48 CEST] <TimNich> sounds suitably recursive.. [17:27:07 CEST] <Daemon404> can we vote on who votes for the vote [17:27:19 CEST] <TimNich> now then! [17:29:57 CEST] <martijnb> before I go duck into the weekend [17:30:08 CEST] <martijnb> I think you handled Lucas on the mailinglist well, wm4, commendable [17:31:55 CEST] <wm4> huh [17:44:12 CEST] <BBB> Compn: I think the broader issue is that its a useful feature for some multimedia applications, but if we put all useful-feature-for-some-multimedia-apps in some lav* library, well soon maintain all of kde _and_ gtk [17:44:27 CEST] <BBB> Compn: not to mention libxml2, glib, gstreamer, helix, libvpx, x264, etc. [17:44:44 CEST] <BBB> Compn: we have to put a line in the sand somewhere and say, ok, were not going to do _that_ [17:46:53 CEST] Action: Daemon404 hesitantly points out the proposed charset conversion in libavutil [17:47:21 CEST] <wm4> (we should still agree on using some xml lib or at least NIH a simple xml parser) [17:48:04 CEST] <iive> isn't out there a xml lib that is THE xml lib? [17:48:13 CEST] <Daemon404> no really [17:48:15 CEST] <Daemon404> not* [17:48:17 CEST] <nevcairiel> thats libxml2 more or less [17:48:23 CEST] <Daemon404> nevcairiel, lots use expat [17:48:28 CEST] <iive> yes... that one. [17:49:35 CEST] <wm4> and _all_ those libs really suck [17:49:55 CEST] <Daemon404> parsing xml inherently sucks in C [17:50:04 CEST] <Daemon404> i dont think youll get around that [17:51:40 CEST] <BBB> right, what he just said [17:51:46 CEST] <BBB> xml is & just sucky [17:52:00 CEST] <BBB> libxml2 is pretty good btw, Ive worked with it a couple of times [17:52:08 CEST] <BBB> and its more or less a system lib [17:52:29 CEST] <BBB> as for charset conversion, I really dont understand the issue with using a system lib for that [17:52:41 CEST] <wm4> BBB: you mean iconv? [17:53:07 CEST] <BBB> for example [17:53:13 CEST] <wm4> because the proposed lavu thing is basically aviconv [17:53:20 CEST] <BBB> of course it is [17:53:31 CEST] <BBB> at some point michael proposed writing avgcc [17:53:36 CEST] <BBB> thank god we didnt do that [17:53:45 CEST] <BBB> so why is aviconv a good idea? [17:55:02 CEST] <wm4> <BBB> at some point michael proposed writing avgcc [17:55:04 CEST] <wm4> wat [17:55:22 CEST] <BBB> we all agree its a terrible idea [17:55:22 CEST] <BBB> now [17:55:28 CEST] <BBB> why is aviconv a good idea? [17:55:44 CEST] <wm4> I guess the idea is avoiding an iconv dependency if the user only needs utf-8 (and maybe latin1/utf-16/something else) [17:55:55 CEST] <wm4> the end [17:56:00 CEST] <BBB> (at some point our dear friends at mplayer implemented their own memcpy - also one of those great memories) [17:56:01 CEST] <wm4> you'll need to ask Nicolas [17:56:27 CEST] <wm4> these days custom memcpys are needed again [17:56:32 CEST] <iive> i don't remember avgcc, but it does sound like joke [17:56:32 CEST] <wm4> because uncacheable GPU memory [17:56:47 CEST] <iive> oh, and fabrice wrote tiny cc [18:01:02 CEST] <iive> mplayer does a lot of memcpy of big data. most of the system glibc doesn't use SIMD accelerated memcpy... [18:01:18 CEST] <Daemon404> uh, maybe 10 years ago [18:01:57 CEST] <wm4> or 20 [18:02:40 CEST] <BBB> mplayer is from 20 years ago [18:02:43 CEST] <BBB> ... [18:02:49 CEST] <iive> glibc have a thing where a version compiled for mmx or sse exists as separate library. [18:02:49 CEST] <BBB> anyway, all of these are terrible ideas [18:03:22 CEST] <BBB> if nicolas wants to do aviconv, then well, nothing I can do against it [18:03:31 CEST] <BBB> but I would personally just use iconv and move on with my life [18:03:46 CEST] <iive> iconv could be considered a system library. [18:03:48 CEST] <durandal_170> just vote no [18:05:14 CEST] <BBB> I thought voting would be reserved for contentious stuff that cannot be judged on technical merits alone? [18:05:35 CEST] <iive> well, if you have a hammer... [18:06:28 CEST] <BBB> iive: nah& I dont want to take others fun away [18:06:41 CEST] <BBB> iive: look, I personally think its a bad idea. but nicolas is smart and its his time [18:06:49 CEST] <wm4> I tried this: https://github.com/FFmpeg/FFmpeg/pull/153 [18:06:55 CEST] <BBB> iive: Im happy to discuss it with him and lay out my arguments, but Im not going to fight with him over it [18:06:55 CEST] <wm4> too lazy to write a bot or something [18:07:48 CEST] <wm4> "As much as I find it gratifying for my ego to see you all welcome us back [18:07:48 CEST] <wm4> like that, I must say all your votes are both invalid, a" [18:07:52 CEST] <wm4> this went well [18:08:25 CEST] <BBB> ? [18:08:28 CEST] <wm4> "If Margaret Thatcher were to crawl out of her grave and pretend she's a FFmpeg developer, " [18:08:33 CEST] <wm4> oh well [18:08:34 CEST] Action: wm4 hides [18:09:04 CEST] <iive> i think that ffmpeg already have its own utf8 parser. so we already support utf8 [18:09:54 CEST] <BBB> GET_UTF8 [18:09:57 CEST] <BBB> thats true [18:10:15 CEST] <wm4> do we need an iconv-style API around it? [18:11:33 CEST] <iive> as for utf16... that's can of worms. [18:12:46 CEST] <BBB> going back to useful subjects now :-p [18:12:52 CEST] <BBB> Gramner: have I mentioned how much I love checkasm? [18:13:06 CEST] <BBB> Gramner: I really dont know how to put it in words, its fantastic [18:13:33 CEST] <wm4> what does checkasm do? [18:13:35 CEST] <Gramner> BBB: thanks, that's why I wrote it :) [18:13:50 CEST] <BBB> wm4: it & uhm & (dont kick me) checks your asm [18:14:12 CEST] <wm4> we could probably use something like this for libass [18:14:14 CEST] <BBB> you prepare input in some custom way, then you run a c function, a simd function, and it compares the output to ensure its identical [18:14:41 CEST] <BBB> most functions use the same generic methods to prepare input, but some are somewhat customized, it depends on what your function does basically [18:14:42 CEST] <wm4> hm, neat [18:15:10 CEST] <BBB> and then if it doesnt match, it says (in red! yay! colors) FAILED! and the name of the function that failed [18:15:21 CEST] <BBB> pretty neat [18:15:46 CEST] <BBB> its basically a unit test for the dsp behind most codecs [18:16:14 CEST] <BBB> with the advantage being that its much more precise than a fate test (because it tests one fuction, not a codec), and also much faster [18:16:31 CEST] <BBB> (you still want fate, absolutely, but having both is neat) [18:17:12 CEST] <Gramner> it's part of fate as well [18:17:56 CEST] <BBB> oh right, well, I meant the sample md5 tests in fate [18:18:08 CEST] <BBB> play first n frames of file m and compare md5s to a ref [18:19:27 CEST] <BBB> Im wondering if I should play around with avx2 for the vp9 optimizations [18:19:43 CEST] <BBB> (10-12bpp loopfilter specifically could benefit from it) [18:20:27 CEST] <BBB> I guess Ill first finish what Im working on now [18:22:17 CEST] <Gramner> any function where the width of the data being processed is larger than 16 bytes is usally a good target for avx2. [18:23:08 CEST] <Gramner> you can make avx2 useful for smaller datasets as well, but it's harder and the gain is lower [18:23:39 CEST] <BBB> loopfilter uses 16 pixels, so for 16bpp thats 32 bytes [18:24:09 CEST] <michaelni> wm4: neat idea with the pull request, i wonder if that will work though [18:24:18 CEST] <Gramner> yes, with high-bit depth stuff it's usually easy to make good use of the larger registers [18:26:28 CEST] Action: BBB looks for victim^dvolunteer to donate a free haswell/skylake MBP [18:28:45 CEST] <wm4> michaelni: probably not [18:31:01 CEST] <wm4> saste: didn't you want to add a GPU memcpy to lavu? [18:32:45 CEST] <saste> wm4, would make sense, to optimize GPU <-> CPU memcpy [18:33:39 CEST] <saste> also, I measured significant performance improvements with dxva2 when using ASM memcpying instructions [18:33:50 CEST] <Compn> Daemon404 , nevcairiel , BBB , wm4 : yeah well make noise before it gets to our gsoc page lol :P [19:17:55 CEST] <BBB> Compn: stuff sometimes slips through ;) [19:18:11 CEST] <philipl> BBB: you're looking for a donor or a recipient? :-) [19:18:54 CEST] <BBB> Im the recipient [19:19:01 CEST] <BBB> so guess what Im looking for :-p [19:19:06 CEST] <philipl> heh. [19:44:16 CEST] <durandal_170> is there any simple and good stt engine? [20:30:25 CEST] <BBB> Compn: its not about excluding people - its about including people that are currently active [20:30:43 CEST] <BBB> Compn: and the exact criteria where designed in the irc meeting of which full transcripts were posted online [20:30:48 CEST] <BBB> Compn: so you can see details there [20:31:03 CEST] <BBB> Compn: to answer your question: no it was not to cut out old devs [20:42:12 CEST] <atomnuker> man the tiny_psnr tool is sometimes so far off it's ridiculous, but it's good enough to catch bugs & regressions [20:42:50 CEST] <atomnuker> I wonder if tiny_ssim will be more useful [20:44:04 CEST] <cone-019> ffmpeg 03Christophe Gisquet 07master:2801a1352dc8: dnxhddec: decode and use interlace mb flag [20:49:08 CEST] <Compn> BBB : it was literally "lets use this metric" with no discussion [20:49:12 CEST] <Compn> which is ok [20:49:16 CEST] <Compn> (yes i went back and re-read it) [20:49:40 CEST] <Compn> well a lot of discussions on how the committee could be made, 3 person 1 leader, 2 girls 1 cup, whatever. [20:50:23 CEST] <BBB> I think various people (including me) considered the question of how to improve the metric [20:50:33 CEST] <BBB> and we decided to go with this as an initial thing because its good enough" [20:50:36 CEST] <BBB> nobody objected [20:50:49 CEST] <BBB> do you want us to become philisophers and overthink everything and never get anywhere? [20:50:56 CEST] <BBB> or do you prefer ffmpeg to go places and rule the world? [20:58:24 CEST] <Compn> look thats why i asked my question [20:58:25 CEST] <Compn> the answer is [20:58:28 CEST] <Compn> "we dont know" [20:58:34 CEST] <Compn> its not rocket science [20:58:40 CEST] <Compn> simple question with a simple answer [20:58:45 CEST] <Compn> dont be so damn paranoid defensive about it [20:59:52 CEST] <BBB> your reaction (email) sounded a little tinfoil hat :) [21:00:07 CEST] <wm4> BBB: it definitely did [21:00:30 CEST] <Compn> if i was posting with a tinfoil hat i would have asked why only 4 people came up with this idea of who controls the project [21:00:53 CEST] <Compn> otherwise , i said i dont care. you can read "i dont care" as "tinfoil hat" if you want, but then you are projecting your fears and strawmans [21:01:59 CEST] <Compn> reynaldo : samsung is coming out with new VR goggles. can we get some goggles to make ffmpeg handle whatever formats they need? :) [21:02:24 CEST] <Compn> the world needs more 3d goggle vr porn. [21:04:07 CEST] <reynaldo> Compn: depends [21:04:35 CEST] <reynaldo> I actually have a vr team sitting nearby here at the office [21:04:47 CEST] <reynaldo> I just dont really know what they do but I can ask [21:04:49 CEST] <reynaldo> :) [21:04:55 CEST] <Compn> ok cool yeah ask, cant hurt :) [21:04:56 CEST] <Compn> thanks [21:05:14 CEST] <reynaldo> one thing though [21:05:37 CEST] <Compn> 3d vr stuff also used for movies, video games, uhhhh .............. yeah movies and video games. [21:05:38 CEST] <reynaldo> do we have anyone with an actual plan to work on this? [21:06:10 CEST] <Compn> well i just found out about this like 30 seconds ago, so i'm working on a plan [21:06:22 CEST] <Compn> maybe durandal_170 who works on filters would be interested in checking the 3d stereo filter works with it [21:06:22 CEST] <reynaldo> at the corporate side is either they needing something from us or we having an actuall plan leading to something they might be able to benefit from [21:06:46 CEST] <reynaldo> Compn: give it a round of thought then, email me once you have something so I can FWd it properly [21:07:28 CEST] <iive> Compn: repeat after me : "Oculus Rift" [21:07:40 CEST] <Compn> iive : yes i know oculus rift ,what about it ? [21:07:53 CEST] <reynaldo> the above "corporate" quote refers to situations in which we might be in position to request equipment / money and they actually willing to consider it [21:08:06 CEST] <iive> Compn: don't bother with anything else, until it's been 2 years after its release. [21:08:09 CEST] <reynaldo> (from experience at least) [21:08:34 CEST] <Compn> iive : oculus rift already works with ffmpeg, https://www.reddit.com/comments/2hbee5 [21:09:25 CEST] <Compn> and samsungs' vr goggles are reported to be cheaper than rifts' [21:09:35 CEST] <Compn> even though probably not :D [21:10:41 CEST] <Compn> reynaldo : i understand, but its kind of hard for me to organize a plan with people with no guarentee or funds or anything. i cant even name a single devel who likes 3d stuff [21:11:07 CEST] <Compn> (in fact, i'm pretty sure everyone here hates 3d crap) [21:12:08 CEST] <iive> i think interlace is more hated. [21:12:41 CEST] <iive> you can completely ignore 3D stuff, if you encode it e.g. side by side. [21:22:18 CEST] <cone-019> ffmpeg 03Jeremy James 07master:428424fe7520: dnxhddata: correct weight tables [21:28:33 CEST] <durandal_170> Compn: I don't hate 3d stuff [21:31:45 CEST] <cone-019> ffmpeg 03Paul B Mahol 07master:aff3acc54c07: avformat/iff: check for possible overflow in 2nd argument of av_new_packet [21:36:33 CEST] <durandal_170> Daemon404 searching for sexy elenril on web.... [21:37:13 CEST] <fritsch> durandal_170: http://images5.fanpop.com/image/polls/853000/853139_1318332851689_full.jpg <- that? [21:40:22 CEST] <durandal_170> why is asf demuxer always build? [21:42:08 CEST] <crot|2> is it okay to ask about issues getting the latest snapshot to run after fresh ubuntu install/compile or should I keep that in #ffmpeg [21:43:49 CEST] <wm4> #ffmpeg sounds more appropriate for this [21:44:30 CEST] <crot|2> fair enough wm4 thanks for the reply [21:45:19 CEST] <Compn> reynaldo : ok i thought up a bunch of ideas [21:45:25 CEST] <Compn> reynaldo : what email should i send to ? [21:45:33 CEST] <Daemon404> durandal_170, lol [21:45:36 CEST] <Daemon404> you just watched that sampke? [21:45:49 CEST] <Daemon404> im particularily proud of adding it to fate [22:04:39 CEST] <BBB> poor Gramner gets a real michael review :D [22:10:06 CEST] <wm4> lavu had trees? [22:10:13 CEST] <Gramner> yes [22:10:45 CEST] <Gramner> there's probably a web browser hidden there somewhere too [22:14:04 CEST] <Daemon404> Gramner, no that's in libavformat [22:14:08 CEST] <Daemon404> i wish i was joking [22:15:33 CEST] <BBB> sadly thats not even a troll [22:16:32 CEST] <kurosu> there are far useless stuff in ffmpeg, like that hevc decoder nobody knows about nor use [22:17:34 CEST] <Daemon404> ^ a proper troll [22:18:36 CEST] <kurosu> or a self deprecating joke [22:18:42 CEST] <wm4> what web browser [22:18:47 CEST] <kurosu> I have moved to more mainstream stuff like dnxhd [22:18:51 CEST] <Daemon404> oh, i misread wm4 [22:18:59 CEST] <Daemon404> i read web *server*... my bad [22:19:04 CEST] <wm4> oh, lol [22:19:25 CEST] <Daemon404> kurosu, it certainly is far more used currently [22:21:13 CEST] <jamrial> useless libavutil stuff? all the crypto stuff i wrote comes to mind [22:21:47 CEST] <Daemon404> i thought a lot of that was being used in rt(m)p [22:21:48 CEST] <Daemon404> and pals [22:22:11 CEST] <jamrial> not the modules i wrote :p [22:22:24 CEST] <Daemon404> o olol k [22:22:43 CEST] <drv> clearly everyone needs IBM CGA fonts [22:23:13 CEST] <drv> how in the world did that end up in lavu? [22:23:34 CEST] <jamrial> rtmp uses hmac sha256, support for which i did add, so i guess that's something not-so-useless i did for lavu crytpo [22:27:00 CEST] <wm4> drv: maybe for rendering text in lavfi or so? dunno [22:28:10 CEST] <drv> yep, seems so, bit of a shame that it always gets built in now [22:28:35 CEST] <drv> and not only when you --enable-useless-codecs ;) [22:29:54 CEST] <durandal_170> new filter in progress: maskedmerge [22:31:42 CEST] Action: kurosu sheds a tear [22:32:17 CEST] <kurosu> durandal_170, are you going to implement the whole suite of masktools afterwards? [22:32:56 CEST] <kurosu> (I'm not sarcastic) [22:33:08 CEST] <J_Darnley> I think its useful to have all the hash functions available in one library [22:35:21 CEST] <J_Darnley> I was considering using them for a generic hash program (some thing to replace this DAMN Hash Calc I've been using for years [22:38:02 CEST] Action: BBB looks for asm review victims [22:38:24 CEST] <BBB> kurosu: dear sir, hi, can i ask you a question? [22:39:27 CEST] <durandal_170> kurosu: blend is already there [22:39:47 CEST] <kurosu> didn't you just ? or what is a ploy to avoid me playing dead ? [22:40:11 CEST] <durandal_170> if something is useful shuts, why not.. [22:40:22 CEST] <durandal_170> *shure [22:40:53 CEST] <kurosu> durandal_170, no, it was more about nostalgia [22:51:28 CEST] <DHE> I have a patch that passes closed captions from MPEG2 to libx264. I've mentioned it before but many months ago. Tested working on set top boxes (a few models from a single vendor) and mobile video players. [22:53:46 CEST] <iive> DHE: i assume you've sent it to the maillist. you are just asking for someone to review it. [22:54:47 CEST] <iive> DHE: also, it's ok to bump it (aka reply to your own mail) if so much time have passed. [22:55:17 CEST] <DHE> I have not actually... need to read up on the procedure... [22:55:24 CEST] <DHE> right now I just have it thrown up on github [22:58:32 CEST] <DHE> maybe this should wait until tomorrow then. I'm not firing on all cylinders right now.. [23:05:24 CEST] <iive> :) [23:07:47 CEST] <BBB> hah, the current vp9 10/12bpp decoder is 35% faster than libvpx [23:07:51 CEST] <BBB> and itxfm_add is still pure c code [23:07:53 CEST] <BBB> nice \o/ [23:08:04 CEST] <BBB> directional ipred also, but thats relatively unimportant [23:13:14 CEST] <iive> BBB: do you profile the code and are you using something else than `perf` ? [23:13:28 CEST] <BBB> iive: I got exactly that question at my vdd talk :D [23:13:42 CEST] <BBB> shall I give you a link to the youtube video fragment where I answer that question? [23:14:04 CEST] <iive> there are videos of VDD talks? I do want link to them. [23:15:07 CEST] <Gramner> https://goo.gl/Fg1vci VDD talks [23:15:28 CEST] <BBB> https://www.youtube.com/playlist?list=PLQLpBN3oI7E44HIdTOovThc1MNHLchgHE [23:15:31 CEST] <BBB> oh crap [23:16:41 CEST] <iive> that might go into the topic :) [23:17:08 CEST] <BBB> relevant question at 27:15 of the last talk in that list [23:17:48 CEST] <kurosu> I use perf or codeXL under windows, but the later requires compiling with msvc which in turn doesn't have critical asm such as cabac [23:18:16 CEST] <BBB> https://youtu.be/_Q6J2_nvLSI?t=27m12s [23:18:28 CEST] <kurosu> I think I noticed perf being off by an insn or 2 [23:18:37 CEST] <iive> are you the one with the red shirt? [23:18:42 CEST] <BBB> yes [23:19:02 CEST] <iive> kurosu: isn't codexl AMD cpu only? [23:19:23 CEST] <kurosu> no, but maybe the most useful stuff is AMG gpu only [23:19:31 CEST] <BBB> so short answer: I use mac instruments, its pretty good at doing per-instruction highlighting although its not perfect [23:21:25 CEST] <kurosu> there's also an intel tool that instrument your code in object files according to a cpu family of your choice if you surround it with some specific indicators, but it's overkill [23:21:42 CEST] <kurosu> tells you where the bottleneck is on execution ports etc [23:21:54 CEST] <iive> i'll watch the whole talk. I'm sure there are more interesting things in there. [23:29:31 CEST] <BBB> per-block adaptive color transform? [23:29:32 CEST] <BBB> w [23:29:33 CEST] <BBB> t [23:29:34 CEST] <BBB> f [23:29:38 CEST] <BBB> is that for real? [23:30:00 CEST] <kurosu> actually the adaptive part is just saying on or off [23:30:06 CEST] <kurosu> and it's yuv->rgb [23:30:29 CEST] <BBB> so its to switch between two transform functions? [23:30:34 CEST] <BBB> a custom and a generic one? [23:30:48 CEST] <kurosu> no color transform and yuv->rgb [23:30:59 CEST] <kurosu> I didn't even use the specs name which was confusing to me [23:31:37 CEST] <kurosu> the only stream I seen using it flags every block [23:31:57 CEST] <kurosu> akin to saying "hey it's rgb content but in fact it's yuv" [23:32:11 CEST] <kurosu> *I've seen [23:32:28 CEST] <BBB> hm& weird [23:33:12 CEST] <kurosu> well they have 11 bits for quantization scale, of which only 5 are probably useful, so there's room to suddenly find something more useful [00:00:00 CEST] --- Sat Sep 26 2015

1 0

ffmpeg.log.20150925
by burek 26 Sep '15

26 Sep '15

[00:10:43 CEST] <C0nundrum> is there a windos compiled version of ffmpeg that supports screen capture on nvidia cards ? [00:57:36 CEST] <C0nundrum> anyone here [00:57:52 CEST] <C0nundrum> How come this room is always so dead [00:58:31 CEST] <c_14> Because nobody understood your question? [00:58:48 CEST] <c_14> Is "windos" supposed to mean "Windows" or is it an evil amalgamation of Windows and DOS? [00:58:57 CEST] <c_14> Also, why wouldn't gdigrapb work on nvidia cards? [00:58:59 CEST] <c_14> *gdigrab [01:00:04 CEST] <C0nundrum> what i'm trying to do is [01:00:14 CEST] <C0nundrum> ffmpeg -f dshow -i video="screen-capture-recorder" -ac 6 -strict -2 -c:a aac -c:v libx264 -preset ultrafast "rtmp://192.168.1.145/live1/test" [01:00:51 CEST] <C0nundrum> But i get Unable to find a suitable output format for 'rtmp://192.168.1.145/live1/test' [01:00:51 CEST] <C0nundrum> rtmp://192.168.1.145/live1/test: Invalid argument [01:01:05 CEST] <c_14> -f flv rtmp:// [01:01:23 CEST] <c_14> Why did you assume that had something to do with either the graphics card or screen capturing? [01:01:54 CEST] <C0nundrum> and if i specify that way i get [01:02:32 CEST] <C0nundrum> http://i.imgur.com/PKyIAHu.png [01:02:56 CEST] <C0nundrum> well c_14 i know new vidia cards have a api for low latency capture [01:03:32 CEST] <C0nundrum> but anyway desided to got with screeen capture recorder and i get the above error [01:03:38 CEST] <C0nundrum> go with* [01:04:01 CEST] <c_14> You're not encoding fast enough. (probably) [01:04:04 CEST] <c_14> So the input buffer is too full. [01:06:35 CEST] <C0nundrum> What could do to prevent that ? [01:06:42 CEST] <C0nundrum> could i* [01:07:47 CEST] <C0nundrum> it happens even if i set framerate to 1 [01:08:12 CEST] <c_14> How's the cpu usage? [01:09:51 CEST] <C0nundrum> while incrementing last messeage repeated the process uses 4-7% [01:09:56 CEST] <C0nundrum> using the following command [01:10:04 CEST] <C0nundrum> ffmpeg -f dshow -i video="screen-capture-recorder" -framerate 1 -ac 6 -strict -2 -c:a aac -c:v libx264 -preset ultrafast -f flv "rtmp://192.168.1.145/live1/test" [01:10:33 CEST] <c_14> -framerate has to go before -i [01:12:08 CEST] <C0nundrum> moved it an ffmpeg ran for prob 3 secodns and gave this error http://i.imgur.com/URlUGdV.png [01:14:10 CEST] <C0nundrum> if i do a fileoutput instead however it works [01:14:23 CEST] <c_14> Oh, then your network is just too slow. [01:14:47 CEST] <C0nundrum> the rtmp server is on the same machine [01:14:57 CEST] <C0nundrum> how can it be to low at 1fps... [01:16:27 CEST] <C0nundrum> could it be that for some reason it isn't sending to the rtmp server ? [01:17:09 CEST] <C0nundrum> ah fixed it [01:19:32 CEST] <C0nundrum> well kinda it streams now but there is a large delay [01:19:54 CEST] <c_14> How large is large? [01:22:42 CEST] <C0nundrum> ffmpeg cpu usage is around 14% Stream has a delay of 12 seconds and goes grey sometimes. is there anway to improve performance, my pc should be able to do better than that [01:23:21 CEST] <C0nundrum> the the logs are like this http://i.imgur.com/TQP2mvL.png [01:23:40 CEST] <C0nundrum> with frametime set tp 20 fps i would like to have 30fps or evenr 60fps with less than a second delay [01:24:25 CEST] <c_14> Have you tried using gdigrab instead of screen-capture-recorder? [01:25:08 CEST] <C0nundrum> well i tried ffplay with the same input and there is almost no delay so i would asume it is in the encoding process but i will try streaming gid now [01:31:34 CEST] <C0nundrum> gdigrab seems to stream better but it still has a playback delay of 10 seconds. Could this be because of ffmpeg buffer ? [01:31:50 CEST] <c_14> ffmpeg + x264 + network probably [01:53:23 CEST] <C0nundrum> alright i managed to reduce the delay to 1 second [01:53:34 CEST] <C0nundrum> ffmpeg -f gdigrab -i desktop -f flv rtmp://192.168.1.145/live1/test2" [01:53:42 CEST] <C0nundrum> is there anwya to get it down durther ? [01:58:19 CEST] <c_14> Under a second? Have you tried -tune zerolatency? [01:59:07 CEST] <DHE> that's x264 only which he doens't specify a codec [01:59:27 CEST] <c_14> Doesn't flv default to x264? [01:59:39 CEST] <c_14> Ah, no it does not. [01:59:46 CEST] <C0nundrum> http://i.imgur.com/fsACD86.png [02:00:37 CEST] <c_14> -fflags +nobuffer maybe? [02:01:03 CEST] <c_14> Wait, no that's an avioflag [02:01:11 CEST] <c_14> No, it is an fflag [02:01:23 CEST] <c_14> This section needs some decent indentation or something. [02:06:12 CEST] <C0nundrum> also i'm trying to set framerate for gdidraw but it won't let me do anything over 14 fps ? [02:06:53 CEST] <C0nundrum> even if i do ffmpeg -f gdigrab -framerate 60 -i desktop -f flv rtmp://192.168.1.145/live1/test2" [02:06:58 CEST] <C0nundrum> it says it recording at 13 fps [02:07:35 CEST] <c_14> Where's it say that? [02:08:09 CEST] <C0nundrum> http://i.imgur.com/G9Amrzi.png [02:08:57 CEST] <c_14> That just shows you how fast it's encoding. [02:09:11 CEST] <c_14> Your system can't encode using that encoder at more than 13ish fps [02:09:40 CEST] <C0nundrum> what ecnoder is it defaulting to ? i thought it was just sending it raw ? [02:09:53 CEST] <c_14> flv1 [02:10:33 CEST] <c_14> If you want it raw, use -c:v rawvideo (though I don't know if that fits in flv) [02:10:51 CEST] <C0nundrum> Hm well which encoder whould i try out. with this encoder i get pretty good results. what seems like less than 500ms but i want more than 13 fps :/ [02:12:22 CEST] <onyx_> hello [02:12:42 CEST] <onyx_> Im trying to use nginx rtmp with ffmpeg [02:12:53 CEST] <c_14> maybe something i-frame only? [02:13:08 CEST] <onyx_> when I tried before it says libfdk_aac error or something [02:13:19 CEST] <onyx_> is there a way to use another audio other than libdfk? [02:13:25 CEST] <c_14> -c:a aac -strict -2 [02:13:35 CEST] <onyx_> would that work on iphone? [02:13:50 CEST] <c_14> It produces standards compliant AAC just like every other aac encoder. [02:14:14 CEST] <waressearcher2> is aac codec better than libmp3lame ? [02:14:43 CEST] <waressearcher2> I know its good for youtube uploads to have audio track in "aac" format but other than that, why use "aac" ? [02:15:06 CEST] <c_14> In git ffmpeg, probably. Might soon even be about as good or better than libfdk_aac (don't quote me on that). [02:16:58 CEST] <waressearcher2> libfdk_aac is the best implementation ? [02:17:15 CEST] <c_14> Currently, yes. [02:17:49 CEST] <waressearcher2> they have dfferent licenses ? thats why they can't be merged ? [02:18:06 CEST] <c_14> The libfdk_aac license is incompatible with GPL [02:18:12 CEST] <onyx_> like this? http://pastebin.com/BCMedBvF [02:18:25 CEST] <c_14> onyx_: yep [02:19:10 CEST] <onyx_> c_14: do you see anything on there that can be improved? [02:19:58 CEST] <c_14> Do you need the -g 50 for something? [02:20:10 CEST] <onyx_> I have no idea what that is [02:20:34 CEST] <c_14> get rid of it [02:20:41 CEST] <onyx_> ok [02:21:21 CEST] <onyx_> what does that -g 50 do? [02:21:46 CEST] <c_14> Sets the gop size to 50. [02:22:06 CEST] <c_14> No point changing it from the default if you don't need it any different. [02:22:43 CEST] <onyx_> basically what Im trying to do is restream a live feed from an IP camera to rtmp and hls [02:23:00 CEST] <onyx_> rtmp for desktop browsers and hls for mobile [02:24:04 CEST] <waressearcher2> will these options "-c:v h264 -vb 2000k -preset ultrafast" generate good quality or should I use another "preset" ? [02:24:24 CEST] <c_14> Use the slowest preset you can stomach. [02:27:43 CEST] <onyx_> mmm =( is not playing... [02:28:55 CEST] <c_14> onyx_: any error? [02:29:13 CEST] <onyx_> nginx started fine [02:53:52 CEST] <waressearcher2> c_14: with "ultrafast" it took 11 minutes [02:55:15 CEST] <waressearcher2> c_14: will I get smaller size with slower preset ? its a record of a desktop, do I need better "preset" ? [02:57:20 CEST] <c_14> Since you're specifying an average bitrate, no the video won't get smaller. [02:57:24 CEST] <c_14> The quality will get better. [02:58:13 CEST] <waressearcher2> how to specify variable bitrate ? [02:59:25 CEST] <c_14> There's only average bitrate, constant bitrate, and "constant quality" the last one being crf [03:29:24 CEST] <votz> I want to find the nearest keyframe after N seconds in a video. ffprobe can't seek. How can ffmpeg be used to create a subtrack, centered around N seconds, where the H.264 stream therein is preserved such that ffprobe can analyze it and get the nearest keyframe relative to the original, larger file. [03:39:43 CEST] <c_14> ffmpeg -ss $((time - 5)) -t 10 -i input -c copy out.mkv [03:39:53 CEST] <c_14> ffprobe that and take the middle keyframe? [03:40:33 CEST] <c_14> You can also change the deltas, -c copy means it'll pick the nearest keyframe anyway so a smaller delta should be fair game as well [03:41:00 CEST] <votz> c_14: I'll try that. Thank you. [03:41:40 CEST] <votz> c_14: The tricky part is stream copying (-c copy) will adjust the pts and dts values appropriately, thus destroying the time relationship with the original video. [03:41:45 CEST] <votz> -copyts looks like the key to solving this problem. [04:50:53 CEST] <waressearcher2> c_14: it took 11 minutes on "ultrafast" preset, now I changed "-preset" from "ultrafast" to "medium" and its 3 hours allready and it still converting [04:52:28 CEST] <c_14> Yes, each step down makes it take longer for less qualitative gain compared to the previous step. [04:52:34 CEST] <c_14> Diminishing returns and all taht. [04:52:36 CEST] <c_14> *that [05:05:05 CEST] <waressearcher2> actually it took 70 minutes [05:05:17 CEST] <waressearcher2> but still noticeably longer than 11 minutes [06:27:14 CEST] <sr> im trying to figure out how to get ffmpeg to use more than a single core.. i tried using the -threads switch but that doesnt help.. google isnt helping either.. any ideas? [06:38:32 CEST] <na-g> Not all codecs support multi-thread encoding. Which one are you using? [06:51:26 CEST] <sr> im trying to extract the audio from a video, looks like im trying to go from aac to mp3 i guess [06:54:28 CEST] <votz> sr: lame is single threaded iirc [06:57:57 CEST] <sr> ah [07:47:43 CEST] <koz_> Hi! I normally use this command to convert video: ffmpeg -i "$1" -codec:a opus -b:a 48k -codec:v vp9 -crf 10 -b:v 500k -cpu-used 8 -threads 4 "$2" (with appropriate $1, $2). Is there a way I can modify this command so it only converts a 5-minute segment from 30 minutes into the video? [08:17:46 CEST] <relaxed> koz_: -t 00:05:00 [08:18:11 CEST] <relaxed> oh, wait [08:18:50 CEST] <relaxed> that will work [08:19:19 CEST] <relaxed> -ss 00:30:00 -t 00:05:00 [08:23:39 CEST] <koz_> relaxed: Thanks! [08:34:20 CEST] <koz_> relaxed: I keep getting this: [aac @ 0x562c173c16e0] element type mismatch 3 != 0 [08:34:20 CEST] <koz_> Last message repeated 198 times [08:34:29 CEST] <koz_> Like, over and over and over again. [08:47:27 CEST] <relaxed> koz_: you can ignore them [08:48:32 CEST] <koz_> OK. [08:49:03 CEST] <koz_> Why do they occur? [09:07:14 CEST] <koz_> relaxed: Why do these messages even come up? [09:11:24 CEST] <koz_> Also, holy crap do I get shit fps on encoding into VP9... [09:16:57 CEST] <chungy> yeah vp9 badly needs hardware acceleration (IIRC, nvidia 970/980 cards can do it) [09:18:03 CEST] <koz_> chungy: Via CUDA, I assume? [09:18:40 CEST] <chungy> not sure [09:18:49 CEST] <chungy> nvenc was the API name [09:19:07 CEST] <koz_> 970/980 is Maxwell architecture, IIRC. Will look into nvenc. [09:19:23 CEST] <chungy> I might be totally mistaken, mind you :P [09:19:32 CEST] <koz_> Huh, nvenc is available as early as Kepler. [09:19:38 CEST] <koz_> It's an API for an ASIC block. [09:19:48 CEST] <koz_> (designed for H264 apparently) [09:21:55 CEST] <koz_> chungy: Do you know (even in rough terms) why CPUs are so bad at video encoding? [09:22:06 CEST] <koz_> I.e. why do we even need GPU-embedded ASICs to do it fast? [09:23:06 CEST] <chungy> I don't [09:23:23 CEST] <chungy> most mobile devices have ASICs for H.264 and maybe HEVC too [09:23:44 CEST] <koz_> Well, hopefully Daala will blow them out the sky. [09:24:35 CEST] <chungy> hehe yes, it's supposed to beat VP9 too [09:24:47 CEST] <JEEB> koz_: uhh, cpus are pretty good at encoding, unlike gpus. asics are for a different use case [09:24:57 CEST] <chungy> actually hardware VP8 and VP9 is common on mobiles too [09:25:01 CEST] <koz_> JEEB: Enlighten me? [09:25:14 CEST] <koz_> I'm genuinely not knowledgeable here, and would like to know why we need those ASICs. [09:25:48 CEST] <JEEB> it's for the people who don't want or can't use cpu cycles [09:25:55 CEST] <JEEB> or use cases [09:25:58 CEST] <koz_> Ah. [09:26:06 CEST] <koz_> How does it compete with just using a CPU? [09:26:06 CEST] <chungy> It's no secret that HEVC and VP9 encoding are extremely slow on CPUs ... [09:26:23 CEST] <chungy> There's probably complicated math reasons [09:26:43 CEST] <chungy> like, bitcoin mining is dominated by ASICs that do the sole job of computing sha256 hashes really, really fast. [09:27:19 CEST] <JEEB> chungy: you can tweak that and botg implementations are in early stages. also asic-based cosing is never aimed for high comptession [09:27:34 CEST] <koz_> botg? [09:27:53 CEST] <JEEB> i'm on a tpuchscreen device on a bus :p [09:28:04 CEST] <chungy> Ah, both [09:28:18 CEST] <koz_> Right, I see. [09:28:31 CEST] Action: koz_ is actually curious why they're so slow now. [09:28:57 CEST] <JEEB> well remember x264 and 2006 or so? [09:29:23 CEST] <chungy> tbh I don't remeber x264 before around 2012-2013... I'm kind of late on the encoding thing [09:29:31 CEST] <chungy> in 2006 I knew of xvid and that was about it [09:29:50 CEST] <JEEB> my encodes on amd pcs were roighly what i get off my 4790k now with x265, aiming at high compression [09:30:39 CEST] <JEEB> of course, by now x264 is so well optimized in psychovisuals and speed + cpus have gone forward [09:31:20 CEST] <JEEB> vp9 is a sad case because google doesn't care about general public encoding :p [09:31:41 CEST] <koz_> JEEB: Have they left it to a few enthusiasts or something? [09:31:42 CEST] <chungy> *nods* [09:31:48 CEST] <koz_> (and plus, they're already on VP10 apparently...) [09:31:52 CEST] <chungy> I'd prefer VP9 generally because it lacks all the patent drama [09:33:01 CEST] <JEEB> well give me a good encoder and I'll side with that :p and as vp9 is largely copypasta'd from hevc it's better than avc as a spec [09:33:13 CEST] <JEEB> if only we had a spec, that is [09:34:41 CEST] <JEEB> anyways asic coding is meant to not be optimized for compression but rather usually for low latency or speed. not that they don't get better with new generations of course [09:36:14 CEST] <JEEB> intel's haswell+ avc coding seemed usable if you didn't want to use your cpu f.ex. and I think most recent nvidia weren't too far from that either [09:37:34 CEST] <JEEB> never tested them too much because I just needed the compression and could use a cpu [09:38:41 CEST] Action: koz_ wonders how many SLoC the vp9 encoder/decoder thing is. [09:52:09 CEST] <noone_> hi guys [09:52:26 CEST] <noone_> to have hls support in ffmpeg, do I need to compile it with --enable-nonfree option ? [09:52:26 CEST] <koz_> Hi noone_. [09:53:23 CEST] <noone_> as I always get the following error: Unrecognized option 'hls_segment_filename'. [09:53:55 CEST] <noone_> or am I doing something wrong ? [09:58:16 CEST] <DHE> your version of ffmpeg up to date? ffmpeg -h full # and search for 'hls' [10:06:02 CEST] <noone_> DHE thanks for the reply, I see it now with the `-h full` flag [10:06:26 CEST] <koz_> How can I check what the bitrates for a .mp4 video file are? [10:06:41 CEST] <noone_> I used the latest static build version from the site [10:06:58 CEST] <noone_> it's working now, thanks guys [10:22:10 CEST] <koz_> How can I check what the bitrates for a .mp4 video file are? [10:50:23 CEST] <koz_> Also, how can I enable the -lossless and -frame-parallel options for VP9 in FFMPEG? [10:56:08 CEST] <relaxed> koz_: ffmpeg -h encoder=vp9 [11:02:02 CEST] <Nindustries> Hello [11:02:16 CEST] <Nindustries> Is passmark score the best guideline to use when picking out CPUs ? [11:06:46 CEST] <quovadis> Hi, simple question but cannot find any snippets: how to make a video form a set of raw rgb565 image ? [11:07:14 CEST] <quovadis> "ffmpeg -framerate 25 -f image2 -pixel_format rgb565 -video_size 640x480 -i out_%04d.raw -b 65536k out.mp4" return Decoder (codec id 0) not found for input stream #0:0 [11:12:21 CEST] <durandal_1707> add -c:v rawvideo before -i [11:16:41 CEST] <quovadis> durandal_1707: Thanks a lot ! [11:27:21 CEST] <quovadis> durandal_1707: by the way... how can I simply view an rgb565 with ffplay ? ffmpeg -f rawvideo -pixel_format rgb565 -s 640x480 -i out_0000.raw does not work [11:28:13 CEST] <quovadis> durandal_1707: nor ffmpeg -f image2 -pixel_format rgb565 -video_size 640x480 -c:v rawvideo -i out_0002.raw [11:47:50 CEST] <smirky> hello [11:48:16 CEST] <relaxed> quovadis: you probably cat them together [11:49:31 CEST] <smirky> I'm using ffserver and ffmpeg to feed a .ffm file, recording the camera and the microphone of my laptop. The image seems to be rotated with 180 degrees. I tried toggling vflip,hflip by inserting -vf but that didn't help. If I dump the recording to a regular file, not a http:// link, the recording seems to be ok. This narrows down things to the ffserver itself I guess. Any ideas what I can set to rotate it from the ffserver.conf? [12:01:24 CEST] <saste> smirky, ffserver won't apply filtering [12:01:34 CEST] <saste> there is a workaround though [12:01:47 CEST] <smirky> that's what I'm here to ask for : )) [12:01:58 CEST] <smirky> what to apply to ffserver [12:02:39 CEST] <smirky> if the workaround is "ffplay -vf "hflip,vflip", this won't do [12:03:00 CEST] <saste> ffserver [12:03:13 CEST] <saste> -override_ffserver I mean [12:03:23 CEST] <smirky> huh? [12:03:43 CEST] <smirky> oh, nice [12:03:47 CEST] <smirky> let me check [12:05:30 CEST] <saste> it's an ffmpeg option [12:07:32 CEST] <smirky> I know [12:07:41 CEST] <smirky> but I face invalid data found when processing input [12:07:57 CEST] <smirky> this is probably because I have to pass correct variables [12:08:08 CEST] <smirky> and before, ffserver was fixing it [12:12:26 CEST] <saste> smirky, what's you command? use pastebin [12:14:21 CEST] <smirky> saste: https://paste.smirky.net/view/raw/69799d21 [12:14:33 CEST] <smirky> this is the script only, I'll show you the ffserver.conf [12:15:07 CEST] <smirky> saste: https://paste.smirky.net/view/raw/16d3e0ad [12:19:44 CEST] <saste> smirky, try to remove all AVCodec options from the ffserver file [12:20:06 CEST] <saste> also, what kind of error do you get? from ffmpeg or from ffserver? [12:20:32 CEST] <koz_> What arguments to ffmpeg should I add if I want to include a subtitle stream? [12:20:40 CEST] <smirky1> http://192.168.1.105:8090/live.flv: Invalid data found when processing input [12:20:45 CEST] <smirky1> saste: ^ [12:21:44 CEST] <smirky1> oops [12:21:51 CEST] <smirky1> those errors are not related to ffmpeg or ffserver [12:21:56 CEST] <smirky1> that's ffplay [12:22:16 CEST] <saste> smirky, mmh ok [12:22:47 CEST] <smirky1> [flv @ 0x55e26e978b90] Codec for stream 0 does not use global headers but container format requires global headers [12:22:47 CEST] <smirky1> [flv @ 0x55e26e978b90] Codec for stream 1 does not use global headers but container format requires global headers [12:22:47 CEST] <smirky1> [flv @ 0x55e26e978b90] FLV does not support sample rate 48000, choose from (44100, 22050, 11025) [12:22:47 CEST] <smirky1> [flv @ 0x55e26e978b90] Audio codec mp3 not compatible with flv [12:22:49 CEST] <smirky1> there we go [12:23:03 CEST] <smirky1> I think I found it, need to set bitrate to 44100 [12:23:06 CEST] <saste> allright add those flags to the ffmpeg command [12:23:16 CEST] <saste> smirky, yes [12:23:18 CEST] <smirky1> I had ffserver 2>/dev/nill [12:23:31 CEST] <smirky1> and I remembered that it spits out stuff :) [12:24:25 CEST] <smirky1> on the other hand, Audio codec mp3 not compatible with flv [12:24:27 CEST] <smirky1> hm..... [12:27:53 CEST] <saste> Audio codec mp3 not compatible with flv? [12:27:55 CEST] <saste> sure it is [12:29:01 CEST] <smirky1> fixed that [12:29:07 CEST] <smirky1> I got it working properly [12:29:22 CEST] <smirky1> now some sync and bitrate settings [12:29:27 CEST] <smirky1> and I'm done with the script [12:29:57 CEST] <saste> smirky, do you know why you was getting that error about MP3 and FLV? [12:30:14 CEST] <smirky1> no, but -ar 44100 made it go away [12:31:38 CEST] <smirky1> saste: any thoughts? [12:32:24 CEST] <koz_> This AAC thing is annoying the shit out of me. [12:33:08 CEST] <saste> smirky, I was checking the code, it is silly error reporting [12:33:51 CEST] <saste> i'll send a patch if $gods want [12:33:54 CEST] <koz_> Also, how would I add a subtitle stream to something using ffmpeg? [12:34:16 CEST] <saste> koz_, you reading from files? [12:34:28 CEST] <saste> what's wrong with -i subs.fmt [12:36:56 CEST] <koz_> saste: Yeah, from a file, adding to a video which I'm also encoding to a different format and into a different container. [12:36:59 CEST] <koz_> My sub file is an srt. [12:37:21 CEST] <saste> koz_, show commandline and output in a pastebin [12:37:25 CEST] <smirky1> how should I calculate what bitrate I need [12:37:29 CEST] <smirky1> for the webcam [12:37:40 CEST] <smirky1> not just inserting random numbers [12:39:11 CEST] <koz_> saste: http://dpaste.com/059MPKP [12:39:48 CEST] <saste> koz_, show the ffmpeg output [12:39:59 CEST] <saste> also, you already have the subtitle stream in the input file? [12:40:23 CEST] <saste> I mean the *console* ffmpeg output [12:40:44 CEST] <saste> !paste [12:41:34 CEST] <koz_> saste: No, the subs are in a separate file. [12:42:19 CEST] <saste> koz_: so you need to add this ffmpeg -i subs.srt -i in.mp4 ... [12:42:49 CEST] <koz_> Ah, is that all? Neat. [12:43:29 CEST] <koz_> saste: Is there a way to shut this up? [aac @ 0x562c110c7ea0] element type mismatch 3 != 0 [12:43:35 CEST] <koz_> It's annoying as hell. [12:44:03 CEST] <saste> koz_, I don't think so [12:44:16 CEST] <saste> it could be a broken file or something [12:45:38 CEST] <koz_> Well, there's only one input file (I did tests without subs). [12:45:57 CEST] <koz_> I have no idea if this is fixable or something... [13:15:46 CEST] <quovadis> Does anyone knows how to display and rgb565 raw image with ffplay ? [13:19:27 CEST] <durandal_1707> Just replace ffmpeg with ffplay [13:23:15 CEST] <satiender> Is any one compile ffmpeg for arm [13:23:28 CEST] <satiender> Or use ffmpeg API for arm [13:23:38 CEST] <satiender> ?? [13:23:41 CEST] <satiender> API [13:23:47 CEST] <satiender> ?? [13:26:52 CEST] <JEEB> yes, it can be compiled and used on ARM just fine [13:26:55 CEST] <JEEB> see fate.ffmpeg.org [13:27:02 CEST] <JEEB> there's plenty of ARM testing [13:37:50 CEST] <satiender> ok thanks [13:38:33 CEST] <smirky1> saste: forgot to thank you, btw [13:46:34 CEST] <quovadis> durandal_1707: I tired but get error: "Failed to set value 'rawvideo' for option 'c:v'" for the command ffplay -framerate 25 -f image2 -pixel_format rgb565 -video_size 640x480 -c:v rawvideo -i out_0000.raw [13:49:34 CEST] <durandal_1707> -f rawvideo not image2 [13:50:14 CEST] <relaxed> omit -c:v rawvideo [13:50:22 CEST] <durandal_1707> or -codec instead of -c:v [13:50:56 CEST] <quovadis> durandal_1707: thanks it work well [13:54:39 CEST] <daggs1> greetings, how can I replace a video track within a file? [17:15:18 CEST] <DrSlony> Hey, does ffmpeg need sequential input image names when creating a video from image files, or cna a glob *.jpg work even if the filenames have no order? [17:16:55 CEST] <c_14> glob works [17:20:00 CEST] <DrSlony> thanks [18:55:26 CEST] <Bermond> relaxed: are you there? [19:23:44 CEST] <Bermond> relaxed: hi [19:44:36 CEST] <waressearcher2> one more time, will it increase quality if I change "-c:v h264 -vb 2000k -preset ultrafast" to "-c:v h264 -vb 2000k -preset medium" ? [19:44:55 CEST] <manel2020> hello [19:44:56 CEST] <waressearcher2> it will be encoded 7 times longer but will it brings better quality ? [19:45:02 CEST] <c_14> waressearcher2: yes [19:45:21 CEST] <waressearcher2> c_14: have you seen terminator [19:45:22 CEST] <waressearcher2> ? [19:45:28 CEST] <c_14> yes? [19:45:37 CEST] <waressearcher2> did they sent T-800 back in future in that movie ? [19:45:48 CEST] <waressearcher2> back in past [19:45:59 CEST] <waressearcher2> to where "terminator 2" begins [19:47:17 CEST] <c_14> No, what does this have to do with ffmpeg? [21:08:11 CEST] <JodaZ> is it possible when seeking to not have it touch the audio packets at all and just cut them cleanly? [21:16:58 CEST] <crot^^^> Hello all, Im having some issues on a fresh ubuntu 15.04 with a compile following the guide complie guide [21:17:43 CEST] <crot^^^> the compile goes well but when I execute ffmpeg it seems to stall after it presents libpostproc..... [21:18:49 CEST] <crot^^^> has anyone expirenced this [21:22:02 CEST] <aiena> I have some video tutorials whose audio qulaity is not very good for comfortable listening I would like to split the audio component from the file and then enhance it and combine it again with the video to create a new video. FFmpeg has lots of options and I am not sure with methodology is appropriate. [21:22:17 CEST] <aiena> *which [21:22:42 CEST] <aiena> can someone please guide me. I am planning to use audacity to enhance the audio and then merge it back with the video [21:31:24 CEST] <crot^^^> http://pastebin.com/jQnb57EA is a showing of what I'm executing with and output in console [21:36:04 CEST] <aiena> googling has me just more confused because I am finding variety of approaches and no clear answer [21:38:31 CEST] <DelphiWorld> hi ffmpegsters [21:38:42 CEST] <DelphiWorld> i'm sponing ffmpeg process from nginx rtmp server [21:38:49 CEST] <DelphiWorld> to transcode udp ts to rtmp [21:38:54 CEST] <DelphiWorld> mpeg to h264/AAC [21:39:08 CEST] <DelphiWorld> but sometime channel dont have video [21:39:15 CEST] <DelphiWorld> i'm transcoding to h264 baseline 3.0 [22:27:51 CEST] <crot^^^> anyone around with closed caption experience [22:28:37 CEST] <DHE> what kind? [22:29:52 CEST] <crot^^^> CEA-608 [22:31:03 CEST] <DHE> not me then [22:31:48 CEST] <crot^^^> what we are doing is taking an mpeg2 dumped live out of an hdhomerun and transcoding it into x264/mpeg4 but after the transcode I cant see it in the stream [22:32:16 CEST] <DHE> oh. oh that's easy. I have a patch for that [22:32:36 CEST] <crot^^^> you rock! [22:34:07 CEST] <DHE> I run a mostly uptodate Git checkout. Add this patch onto it: https://github.com/DeHackEd/FFmpeg/commit/05d5069ca3 [22:34:13 CEST] <DHE> I've been meaning to offer it up to ffmpeg [22:34:35 CEST] <crot^^^> let me give it a shot [22:48:17 CEST] <crot^^^> I'll let you know once this finishings recompiling if it works [23:17:45 CEST] <DelphiWorld> yo [23:18:05 CEST] <DelphiWorld> how should i know what passtrue codecs is supported on my tv over hdmi? [23:32:38 CEST] <fred1807> I am looking for a GUI only for the cut job , any good minimalistic one ? [23:33:34 CEST] <DHE> crot^^^: still building? :) [23:37:06 CEST] <crot^^^> just finished [23:37:19 CEST] <crot^^^> do i need any special switches [23:37:29 CEST] <crot^^^> or arguments [23:41:07 CEST] <DHE> add "-a53cc 1" before the output filename [23:42:02 CEST] <fred1807> exactly what I was looking for http://www.popmedic.com/popmsplit/ [23:42:40 CEST] <fred1807> what a wonderfull piece of softwware to add to another wonderful code that is ffmpeg [23:42:58 CEST] <fred1807> what a wonderfull time to be living in [23:43:38 CEST] <crot^^^> showing 4 subtitle streams in media info no output of subs on vlc however [23:44:27 CEST] <crot^^^> take that back there they are [23:45:11 CEST] <DHE> so it works? [23:45:47 CEST] <crot^^^> yeah once I find the correct language :) [23:46:13 CEST] <crot^^^> thanks a bunch we really apprecaite [00:00:00 CEST] --- Sat Sep 26 2015

1 0