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

burek burek021 at gmail.com
Fri Apr 28 03:05:04 EEST 2017


[00:24:43 CEST] <cone-627> ffmpeg 03Rostislav Pehlivanov 07master:4d59de399150: opus_pvq: minor cleanups
[02:55:28 CEST] <cone-627> ffmpeg 03James Almer 07release/3.3:cfca0b91399b: avformat/concatdec: fix the h264 annexb extradata check
[03:21:03 CEST] <cone-627> ffmpeg 03Rostislav Pehlivanov 07master:18a0d9d7ad02: opus_pvq: remove outdated/incorrect comments and redundant variables
[03:21:04 CEST] <cone-627> ffmpeg 03Rostislav Pehlivanov 07master:f16180f44859: opus_pvq: merge band encoding and decoding into one function
[04:28:28 CEST] <cone-627> ffmpeg 03Martin Vignali 07master:e46d63745215: libavcodec/exr : fix float to uint16 conversion for negative float value
[04:28:29 CEST] <cone-627> ffmpeg 03Michael Niedermayer 07master:fa8fd0808f10: avcodec/x86/vc1dsp_init: Fix build failure with --disable-optimizations and clang
[04:28:30 CEST] <cone-627> ffmpeg 03Michael Niedermayer 07master:966cbfbc83db: tools/target_dec_fuzzer: Fix return code on open failure
[04:28:31 CEST] <cone-627> ffmpeg 03Michael Niedermayer 07master:6ca82975b7a8: avcodec/mdec: Fix runtime error: left shift of negative value -127
[04:37:30 CEST] <KurousagiMK2> build failure after commit f16180f44859587e0211170bd82b1bfd26f24b5a https://pastebin.com/CZkyfF3E
[04:52:11 CEST] <jamrial> atomnuker: ^
[05:42:40 CEST] <cone-627> ffmpeg 03James Almer 07master:453f8ea24236: avcodec/opus_pvq: fix recursive inlining compilation failures
[05:43:30 CEST] <jamrial> atomnuker: pushed a fix for the above failure. feel free to replace it with a different/better one
[05:56:42 CEST] <atomnuker> huh, worked with clang, I guess gcc (or some version of it) doesn't support this
[05:59:44 CEST] <jamrial> some = almost every fate slot :p
[06:00:08 CEST] <jamrial> guess clang is more lax about the always_inline attribute
[06:54:08 CEST] <cone-627> ffmpeg 03Rostislav Pehlivanov 07master:f7542d7e35e9: opus_pvq: use function pointers for recursion
[10:28:56 CEST] <atomnuker> iive: do you think having a structure with function pointers and an init function to fill them is a good idea for pvq?
[10:29:37 CEST] <atomnuker> that's how its done in the aac encoder
[10:30:59 CEST] <iive> ??
[10:33:41 CEST] <iive> do you mean, for dsp ? i think this is done for all dsp functions
[12:21:19 CEST] <atomnuker> so supposing you have zeroed ymm vector except that one double word is all 1's
[12:21:52 CEST] <atomnuker> what's the best way to just get the index of that dword?
[12:23:28 CEST] <atomnuker> (this is for SIMD pvq search)
[12:24:07 CEST] <atomnuker> where you end up with 4 packed float values and you need to decide the largest one
[12:25:23 CEST] <atomnuker> my idea was to copy it and shuffle + compare it to the original and AND the results to get a single all 1'd dword
[12:32:21 CEST] <rcombs> atomnuker: is there no way to determine the size of an AAC ASC without parsing the whole damn thing
[12:32:50 CEST] <rcombs> (I'm trying to write aac_latmtoasc_bsf.c)
[12:33:24 CEST] <atomnuker> don't know much about AAC's muxing formats, I think peloverde might know
[12:33:28 CEST] <wm4> did they save a few bits by omitting a size field?
[12:35:55 CEST] <rcombs> I think they did
[12:36:03 CEST] <rcombs> afaict no size, and no syncword
[12:36:20 CEST] <rcombs> and lots of optional fields
[12:56:48 CEST] <nevcairiel> thats why you have wrapping formats for containers that dont hold proper size fields
[12:57:37 CEST] <nevcairiel> its not that uncommon in the mpeg series, h264 by itself also has no such information, hence enter annexb
[12:58:35 CEST] <wm4> I thought NALs exist always
[13:00:56 CEST] <nevcairiel> sure, without syncwords or size info
[13:01:16 CEST] <nevcairiel> not that anyone anywhere handles raw h264 without annexb, people are saner then that
[13:01:28 CEST] <nevcairiel> similar to how one really shouldnt have aac asc on its own
[13:01:37 CEST] <nevcairiel> put it in adts or in a container
[13:02:55 CEST] <rcombs> nevcairiel: it's in LATM
[13:03:05 CEST] <rcombs> afaik LATM doesn't have a size field for it
[13:04:05 CEST] <nevcairiel> latm has size info
[13:04:30 CEST] <rcombs> for the ASC in particular?
[13:04:39 CEST] <nevcairiel> for the latm frame
[13:04:40 CEST] <rcombs> I know it has a size for the packet in general (and also a syncword)
[13:04:56 CEST] <rcombs> but afaict not for the ASC
[13:04:58 CEST] <nevcairiel> what else is in there then the latm header and aac data after it though?
[13:05:04 CEST] <nevcairiel> also, why do you need to care?
[13:05:15 CEST] <rcombs> trying to pull out the ASC into extradata
[13:05:53 CEST] <nevcairiel> thats probably not a good idea
[13:07:13 CEST] <nevcairiel> anyhow latm can have size info for asc
[13:07:17 CEST] <nevcairiel> but its not required
[13:07:31 CEST] <rcombs> well right now we've got no mechanism for doing much of anything with LATM apart from decoding it
[13:07:36 CEST] <nevcairiel> (in audio mux version = 1, it has it)
[13:07:55 CEST] <rcombs> I'd like to be able to convert it to the ADTS or ASC format
[13:08:35 CEST] <wbs> ADTS is kinda limited in the sense that it can only hold the first few aac profiles (it's a 2 bit field in adts or something like that), so you can't have AAC-ELD in ADTS or something similar
[13:08:55 CEST] <nevcairiel> can always do what the latm decoder does, decode it to find its size
[13:09:02 CEST] <nevcairiel> its not liek decoding the config is hard work
[13:09:27 CEST] <rcombs> yeah, it's just an obnoxious quantity of code to copypaste or reference awkwardly
[16:37:07 CEST] <durandal_1707> when is nab show over?
[17:25:46 CEST] <Gramner> atomnuker: movmskps + tzcnt. why 4 floats in an ymm register though? wouldn't it be 8 floats or an xmm reg?
[17:39:10 CEST] <alevinsn> jamrial:  you there?
[17:39:51 CEST] <alevinsn> guess nit
[17:39:51 CEST] <alevinsn> niot
[17:39:52 CEST] <alevinsn> not
[17:54:39 CEST] <jkqxz> alevinsn:  <http://ixia.jkqxz.net/~mrt/ffmpeg/qsv/>?  Or would you prefer the commits not to appear as merges?  (I don't mind between those.)
[19:07:22 CEST] <peloverde> The aac header situation is unfortunate to say the least
[00:00:00 CEST] --- Fri Apr 28 2017


More information about the Ffmpeg-devel-irc mailing list