[Ffmpeg-devel-irc] ffmpeg-devel.log.20150727

[burek]

[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-hijacked-by-malicious-text-messages/
[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