[00:14:56 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:d41dceb14e06: avcodec/dvbsubdec: Add option to select when to computer clut (always/never/"if needed") [00:14:57 CEST] <cone-084> ffmpeg 03Michael Niedermayer 07master:33c4fc0a2d70: doc/decoders: Add entry for dvbsub and document compute_clut [00:31:52 CEST] <iive> "to computer"? [00:41:00 CEST] <jamrial> iive: he clearly meant compute, so typo [00:47:41 CEST] <iive> it's probably too late to amend [05:00:58 CEST] <cone-621> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:2ea642ff4b73: ffserver: move decl to start of func [05:00:58 CEST] <cone-621> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:c75bc268a289: ffserver: simplify assignment with ternary [05:00:58 CEST] <cone-621> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:b16b8c815c2c: ffserver: drop superfluous else clause [11:02:09 CEST] <ubitux> nevcairiel: btw, the iphone seems to actually be able to decode everything at 240fps [11:02:28 CEST] <ubitux> i see something between 700 to 1100µs [11:02:41 CEST] <ubitux> so about 1ms per frame [11:04:23 CEST] <nevcairiel> what resolution was that at? [11:04:29 CEST] <ubitux> 720p [11:04:40 CEST] <nevcairiel> i guess thats in the realm of possibility then [11:04:54 CEST] <ubitux> but maybe i'm not timing the good thing, let me check again [11:05:22 CEST] <nevcairiel> recent hardware decoders can do 720p at like 1000 fps raw decoding performance [11:05:39 CEST] <nevcairiel> but mobile devices may be memory bandwidth constrained [11:05:46 CEST] <nevcairiel> but 720p at 240 fps seems plausible [11:16:23 CEST] <__gb__> a HW decoder that claims to support H.264 HP @ L5.1 can perfectly do 720p240 [11:17:54 CEST] <nevcairiel> they often dont claim 5.1 officially, since that also includes 4k which they often choke on, although no clue what the iphone says [11:21:43 CEST] <ubitux> anyway, with ffmpeg hwaccel that seems not possible for some reason [11:21:57 CEST] <nevcairiel> works for dxva2 on windows [11:22:01 CEST] <nevcairiel> no experience with anything else [11:22:01 CEST] <nevcairiel> :D [11:22:17 CEST] <ubitux> a call to the decode function takes about 6ms on iOS with the vt accel [11:22:38 CEST] <ubitux> which is at least twice too slow [11:22:46 CEST] <ubitux> :( [11:23:16 CEST] <__gb__> apple claims HP @ L4.2 for iPhone 6+, but some people indicated it could support 4K with "low" bitrates (< 50 mbps) [11:24:31 CEST] <__gb__> based on that, I'd say you should be fine for 720p120 (and up to 140) [11:24:51 CEST] <__gb__> so, if you can't sustain 720p120, then there is room for improvement :) [11:25:24 CEST] <ubitux> the same hw is able to 720p240; i want to achieve the same with ff :p [11:26:36 CEST] <__gb__> ok, fair comparison, but the minimum should be 720p120 I'd say :) [11:34:42 CEST] <__gb__> what kind of video are you testing? raw or with some container that directly exposes avcC data? [11:35:54 CEST] <__gb__> are you measuring only the VT calls? e.g. if you don't have "native" avcC data, maybe some time is spent to actually generate avcC compatible bits for VT [11:35:58 CEST] <nevcairiel> 240 fps sounds like these slowmo iphone videos, so mov/mp4 [11:41:05 CEST] <ubitux> yeah slowmo iphone video; the code i'm looking at is abusing AVFoundation [11:41:26 CEST] <ubitux> playback is at 30Hz, but it's decoding 8 buffers anyway [11:46:15 CEST] <zugzwang> Hi. Could someone point to where can I learn how to add a custom codec to ffmpeg? [11:46:32 CEST] <BtbN> read other encoders/decoder. [11:46:54 CEST] <zugzwang> Is it too difficult? [11:47:06 CEST] <zugzwang> no documentation besides the source code right? [11:47:09 CEST] <BtbN> I'm just not aware of any written documentation. [11:47:30 CEST] <zugzwang> ok [11:48:38 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:c719b7a42b3e: ffserver: add (), fix order of operations [11:57:26 CEST] <cone-006> ffmpeg 03Anton Khirnov 07master:f3bd3810d274: qsvdec_*: add missing CODEC_CAP_DR1 [11:57:27 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:d12be9ed70f5: Merge commit 'f3bd3810d274a7f51b5925fc3d2fc33e8043a5d4' [12:22:16 CEST] <rcombs> doesn't the 6+ supposedly have some sort of HEVC support as well [12:23:05 CEST] <nevcairiel_> only kind of [12:23:24 CEST] <nevcairiel_> they dont expose it directly, only use it for their video chat thingy iirc [12:25:13 CEST] <rcombs> it was listed on the tech specs page at launch (though only in the FaceTime section, yeah), but seems to have been removed since [12:27:42 CEST] <cone-006> ffmpeg 03Henrik Gramner 07master:65c148015270: checkasm: Modify report format [12:27:43 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:b940145c67db: Merge commit '65c14801527068fcaf729eeffc142ffd4682a21a' [12:41:15 CEST] <cone-006> ffmpeg 03Alexandra Hájková 07master:9e8627a1ff92: asfdec: interpret the first flag in an asf packet as length flag [12:41:16 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:90696ef36881: Merge commit '9e8627a1ff9207b9e272d248da2e1bd0cc6fe2fe' [12:43:55 CEST] <wm4> that reminds me, what is the VideoToolbox support doing? [12:50:58 CEST] <cone-006> ffmpeg 03Martin Storsjö 07master:6d3081e6c374: doc: Remove the now unnecessary remark about PATH and link.exe [12:50:59 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:46f01e413320: Merge commit '6d3081e6c374ff7da12b07ed33d1662be1b32dbc' [13:00:12 CEST] <cone-006> ffmpeg 03Martin Storsjö 07master:e4015b00d4e9: configure: Simplify, remove an unnecessary intermediate variable [13:00:13 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:a74e3fc18b56: Merge commit 'e4015b00d4e9e40dc1693a018edd51bf7a04993e' [13:07:57 CEST] <cone-006> ffmpeg 03Martin Storsjö 07master:2192ff84dd72: configure: Default to armasm for --toolchain=msvc when targeting arm [13:07:58 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:d9f3efd3d611: Merge commit '2192ff84dd720968108bc1ca54e239f4c94eb61d' [13:18:43 CEST] <cone-006> ffmpeg 03Martin Storsjö 07master:616b409c8f1e: configure: Check MSVC defines for identifying hardfloat [13:18:44 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:8324d427c21a: Merge commit '616b409c8f1e4fa568908212c01f6530da8d2e71' [13:32:18 CEST] <cone-006> ffmpeg 03Martin Storsjö 07master:60a21b3d81c1: configure: Check for _M_ARMT to detect thumb when using MSVC [13:32:19 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:d06ea6e5ce51: Merge commit '60a21b3d81c1a11cf5a08950eadd4e84ca2e597c' [13:48:27 CEST] <Compn> zugzwang : http://wiki.multimedia.cx/?title=FFmpeg_codec_HOWTO , but its possibly outdated :( [15:06:03 CEST] <ubitux> valgrind seems not happy with the fixed aac; but that's known, right? (i think i saw it mentioned on the ml) [15:21:21 CEST] <kierank> hmmm no ludmila [15:59:32 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:42aa02418e43: avformat/mpegts: Use DVB_TELETEXT timestamp heuristic also for DVB subtitles [16:14:24 CEST] <durandal_1707> anybody against pushing acrossfade? [16:55:38 CEST] <kurosu> are the other fixed point decoders (ac3, anything from imgtech, basically) ok either? [16:55:54 CEST] <kurosu> I remember fixing some stuff in eac3, but I never ran valgrind on those [17:25:30 CEST] <cone-006> ffmpeg 03Shivraj Patil 07master:71aede3ced76: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 bilinear functions [17:50:06 CEST] <JEEB> is duration - start_time the effective duration of the clip as long as start_time isn't negative? in which case those are leading samples etc? [18:16:27 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:c8c86b8f9b8c: avformat/mpegts: Replace silent cliping of language_count by asserts [18:26:36 CEST] <nevcairiel> JEEB: duration should not include the start_time [18:26:49 CEST] <nevcairiel> its always the duration [18:26:51 CEST] <JEEB> ok [18:27:18 CEST] <nevcairiel> so duration+start_time is the highest timestamp in the filer [18:27:19 CEST] <nevcairiel> -r [18:27:22 CEST] <nevcairiel> theoretically anyway [18:27:43 CEST] <JEEB> yea, makes sense [18:55:38 CEST] <BtbN> michaelni, what's the policy on backporting stuff to stable branches? I'd like to backport the nvenc performance fix to 2.7. (commit 9f4bff834c) [19:12:03 CEST] <michaelni> BtbN, bugfixes should be ok [19:17:41 CEST] <BtbN> It increases the encoding performance drastically, and makes some 4K stuff possible in realtime that formerly it was too slow for. [19:18:41 CEST] <nevcairiel> technically its not a stable-worthy change [19:19:01 CEST] <BtbN> yeah, that's why i'm wondering. [19:19:02 CEST] <Compn> BtbN : are you going to test the patch before commit with the release ? [19:19:08 CEST] <Compn> if so , its fine with me [19:19:11 CEST] <michaelni> nevcairiel, about ff_alloc_packet2(), should i add a flag argument or can the patch be applied or you prefer something else ? [19:19:46 CEST] <BtbN> Compn, yeah, i'd do some extended testing with it. At least as much as my hardware allows. [19:20:05 CEST] <BtbN> Can't test h265 stuff [19:20:24 CEST] <Compn> BtbN : i think "fixing" 4k is an important enough fix to backport :) [19:21:32 CEST] <BtbN> it's not an overly complicated functional change. Basicaly it's just waiting a bit longer before reading frames from the gpu [19:22:01 CEST] <nevcairiel> michaelni: i still find simply null-ing the context for a behaviour change quite odd api, but its internal api so i don't really care that much, if you think its fine just push it [19:22:37 CEST] <BtbN> Though i wonder if anybody actualy using nvenc doesn't use master anyway [19:29:13 CEST] <cone-006> ffmpeg 03Claudio Freire 07master:59216e0525a5: AAC Encoder: clipping avoidance [20:19:13 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:e36db49b7b31: avcodec: Add a min size parameter to ff_alloc_packet2() [20:19:14 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:0dbfb5386f1e: avcodec/internal: Deprecate ff_alloc_packet() in favor of ff_alloc_packet2() [20:19:15 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:9fe873bec8b6: avcodec/utils: do not use internal->byte_buffer when little downsizing is expected [20:19:16 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:af5f707e46f0: avcodec/v410enc: do not use internal->byte_buffer [20:22:58 CEST] <jamrial> michaelni: why deprecate? it's internal [20:27:04 CEST] <michaelni> i can revert if preferred but i thought people want consistency [20:30:02 CEST] <BtbN> I don't see a problem with deprecating internal functions. Helps cleaning up. [20:30:33 CEST] <michaelni> yep that was the idea [20:41:19 CEST] <cone-006> ffmpeg 03Vittorio Giovara 07master:a67b67944aa9: ac3enc_template: Use the correct context field [20:41:20 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:c7074375724e: Merge commit 'a67b67944aa9e6e794934d15f9fd9a9cf7173e09' [20:51:23 CEST] <cone-006> ffmpeg 03Vittorio Giovara 07master:03eb55741427: wmv2enc: Check memory allocation [20:51:24 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:59b009411fcc: Merge commit '03eb55741427c6608f63972c105e565ca0ba4f15' [21:14:17 CEST] <cone-006> ffmpeg 03Vittorio Giovara 07master:4b6b1082a739: lavc: Deprecate avctx.me_method [21:14:18 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:0b6f092ed31b: Merge commit '4b6b1082a73907c7c3de2646c6398bc61320f2c6' [21:52:53 CEST] <cone-006> ffmpeg 03Paul B Mahol 07master:4a2836eaf33b: avfilter: add acrossfade filter [21:57:18 CEST] <philipl> Oh, stagefright. [21:57:19 CEST] <philipl> http://arstechnica.com/security/2015/07/950-million-android-phones-can-be-hi... [22:10:05 CEST] <BtbN> Well, better than the cars that can be hacked and remote controled by malicious radio broadcasts. [22:10:33 CEST] <philipl> There' [22:10:43 CEST] <philipl> s probably at least one car that's vulnerable to this one :-P [22:11:10 CEST] <J_Darnley> Wait... isn't that a video decoding lib? What's it doing with text messages? [22:11:42 CEST] <JEEB> previews [22:11:47 CEST] <J_Darnley> oh, an MMS [22:11:58 CEST] <JEEB> and yes [22:20:14 CEST] <cone-006> ffmpeg 03Vittorio Giovara 07master:7c6eb0a1b7bf: lavc: AV-prefix all codec flags [22:20:15 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:94d68a41fabb: Merge commit '7c6eb0a1b7bf1aac7f033a7ec6d8cacc3b5c2615' [22:53:16 CEST] <cone-006> ffmpeg 03Vittorio Giovara 07master:def97856de60: lavc: AV-prefix all codec capabilities [22:53:17 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:444e9874a75c: Merge commit 'def97856de6021965db86c25a732d78689bd6bb0' [22:56:18 CEST] <lglinskih> kierank: hi! About draw_horiz_band-test: now it works for h263 and huffyuv (yuv420p and yuv422p), but only for decoding in one thread [22:58:34 CEST] <wm4> lglinskih: what happens with multiple threads? [23:03:18 CEST] <lglinskih> wm4: mmm... I use only one buffer to store results of draw_horiz_band... as I understand draw_horiz_band is called from different threads in which different frames are decoded [23:04:06 CEST] <wm4> so it's not known yet whether the lavc API works in multithreaded mode [23:07:43 CEST] <lglinskih> wm4: it works! it really corrupts my buffer=) [23:08:33 CEST] <wm4> I'm not convinced whether it can be used [23:08:37 CEST] <wm4> the API I mean [23:08:43 CEST] <wm4> (in multithreaded mode) [23:20:20 CEST] <cone-006> ffmpeg 03Vittorio Giovara 07master:059a934806d6: lavc: Consistently prefix input buffer defines [23:20:21 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:29d147c94dd4: Merge commit '059a934806d61f7af9ab3fd9f74994b838ea5eba' [23:28:56 CEST] <rcombs> philipl: the first time I saw anything about that, they were calling the vuln itself "stagefright" and I got mad about dumb naming collisions [23:34:27 CEST] <cone-006> ffmpeg 03Vittorio Giovara 07master:b94ec30428b9: lavc: Update version and APIchanges [23:34:28 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:e3ec2cde2c39: Merge commit 'b94ec30428b9696f99b08055735689623fe63954' [23:45:46 CEST] <cone-006> ffmpeg 03Tom Butterworth 07master:43dd004747fa: hap: Move some per-stream setup into decoder init rather than per-frame [23:45:47 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:f01e3c5d000d: Merge commit '43dd004747fa697396b47d034a80e069facbea09' [00:00:00 CEST] --- Tue Jul 28 2015