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

Sun May 7 03:05:02 EEST 2017

[00:10:03 CEST] <kierank> there are options not available on the cli
[00:19:46 CEST] <kierank> BBB: http://www.streamingmediaglobal.com/Articles/ReadArticle.aspx?ArticleID=118062
[00:19:47 CEST] <kierank> congrats
[00:22:11 CEST] <jamrial> whoa, neat
[00:27:09 CEST] <BBB> sweet
[00:27:19 CEST] <BBB> why is everyone still doing hevc?
[00:27:39 CEST] <BBB> I guess 10bit support in hevc is better developed than it is for vp9, particularly in terms of client support
[00:27:42 CEST] <BBB> (tvs etc.)
[00:28:20 CEST] <nevcairiel> vp9 also lacks  any kind of in-band metadata like SEI for HDR or whatnot, using the container is a bit awkward, wonder if they have that for av1
[00:28:45 CEST] <BBB> I think the reason is that for internet streaming this stuff is unlikely to change within a stream
[00:28:56 CEST] <BBB> and for stream switching you can use container-level stuff like HLS or whatever
[00:29:17 CEST] <BBB> I dont think av1 is doing this stuff differently ATM
[00:29:25 CEST] <BBB> (but I dont know all av1 details)
[00:29:32 CEST] <nevcairiel> i would still prefer all video relevant things to come from the bitstream
[00:29:44 CEST] <nevcairiel> piecing it together from different sources is always awkward
[00:30:01 CEST] <BBB> thats true
[00:30:22 CEST] <BBB> brb, dinner
[00:30:25 CEST] <nevcairiel> there is also problems with "who is right" which noone ever specifies
[00:30:42 CEST] <nevcairiel> like vp9 has some color matrix flags, but the container has more
[00:30:48 CEST] <nevcairiel> what if they disagree
[00:30:51 CEST] <BBB> I certainly agree vui-style signaling in vp9 could be improved
[00:31:05 CEST] <BBB> I think the container level takes priority becuse it was added since the codec level stuff was incomplete/suboptimal
[00:31:13 CEST] <BBB> but youre right, who knows, right? :)
[00:31:15 CEST] <BBB> brb
[00:33:37 CEST] <Compn> 8%!!!!!!!
[00:34:46 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:a234b5ade3ca: avcodec/mdec: Fix signed integer overflow: 28835400 * 83 cannot be represented in type 'int'
[00:34:47 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:a8ad83b793e8: avcodec/aacsbr_template: Do not leave bs_num_env invalid
[00:34:48 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:12dea8a5a153: avcodec/ivi: Free custom blk_vlc
[00:34:49 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:35f3df0d76e2: avutil/softfloat: Fix multiple runtime error: left shift of negative value -8
[00:36:33 CEST] <TD-Linux> nevcairiel, https://aomedia-review.googlesource.com/#/c/8738/
[00:37:30 CEST] <nevcairiel> man gerrits ui is so terrible
[00:37:45 CEST] <TD-Linux> ?polygerrit=0 makes it tolerable
[00:37:58 CEST] <nevcairiel> thats better
[00:39:16 CEST] <nevcairiel> those fields added there are the very least tehy should have, still no arbitrary metadata for eg. HDR
[00:39:49 CEST] <TD-Linux> yes, the HDR level information isn't there yet
[00:40:31 CEST] <nevcairiel> one problem with HDR is that the tech is still evolving, so without some extensible syntax elements like SEI it will be very limited very fast
[00:40:51 CEST] <nevcairiel> HEVC is adding a bunch new HDR signaling SEIs in the next spec update
[00:41:23 CEST] <TD-Linux> yes, extension points for metadata are quite desired so I expect them to get in at some point
[00:42:10 CEST] <nevcairiel> wasnt the bitstream supposed to freeze soon
[00:43:59 CEST] <TD-Linux> BBB, also nice
[00:44:49 CEST] <nevcairiel> everyone said vpxenc rate-control was garbage, but they never fixed it, so good for BBB :)
[00:45:02 CEST] <TD-Linux> atomnuker is fixing it t oo
[00:59:50 CEST] <jamrial> nevcairiel: pushed until the end of this year it seems
[01:10:49 CEST] <cone-036> ffmpeg 03James Almer 07master:214f4133c4cb: avcodec/hevc_parser: move hevc_find_frame_end() down in the file
[01:10:50 CEST] <cone-036> ffmpeg 03James Almer 07master:859cc5c8e662: avcodec/hevc_parser: cosmetics
[02:12:38 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:523205ce1ed9: avcodec/snowdec: Check qbias
[02:56:58 CEST] <james999> endrift: it said you closed a thread about mGBA link from 2015 a bit back
[02:57:20 CEST] <james999> was wondering if that's because the issue was fixed or you decided to drop it
[04:27:26 CEST] <wm4> Subject: [libav-devel] [PATCH 0-9/200] Introduction to a new channel layout  API
[04:27:29 CEST] <wm4> what a good start
[04:37:16 CEST] <kierank> wm4: not actually that many changes
[04:37:22 CEST] <kierank> but it's done as a 200 patchset
[04:38:05 CEST] <wm4> probably 1 per decoder/encoder/filter
[04:42:01 CEST] <jamrial> yeah, same as codecpar and such
[04:54:24 CEST] <philipl> It's a great way to catch up on being 1000 changes behind :-)
[04:57:34 CEST] <wm4> I expect most of those patches to be quite trivial (just converting between channel mask and the new struct)
[04:58:04 CEST] <jamrial> in some cases they squash it all into one as well
[04:58:06 CEST] <wm4> though the fact that ffmpeg for some reason kept a separate channel count complicates this
[04:58:10 CEST] <jamrial> codecpar was squashed, bitstream reader wasn't
[05:18:04 CEST] <cone-860> ffmpeg 03Michael Niedermayer 07master:e813df4fa345: avcodec: Avoid splitting side data repeatedly
[06:38:37 CEST] <alevinsn> jkqxz:  you there>
[06:38:38 CEST] <alevinsn> ?
[06:39:14 CEST] <alevinsn> jkqxz:  Before I submit the qsv patches to the ML, I wanted to confirm with you that the way I represented you and Luca are okay
[06:39:27 CEST] <alevinsn> in the patches on your Web site, you had signed-off-by for both you and Luca
[06:39:48 CEST] <alevinsn> I changed that to Reviewed-by, which I've seen James Almer do in his patches
[06:39:51 CEST] <alevinsn> is that okay?
[06:41:20 CEST] <atomnuker> (those things are mostly pointless and some people omit them, don't take them seriously)
[06:42:00 CEST] <atomnuker> signed-off means you "sign-off" to the policies of the project, whatever that means, but you already do by submitting so its pointless
[06:46:37 CEST] <Compn> doesnt hurt to ask
[06:59:36 CEST] <alevinsn> I think it is nice to give proper credit
[07:00:05 CEST] <alevinsn> but signed-off-by seems to be associated with the author of the patch
[07:07:14 CEST] <wm4> that's how I interpret it
[11:39:32 CEST] <jkqxz> alevinsn:  To my mind, signed-off-by is the set of people who signed off on something for it to be committed.  Therefore, I would add it to things which I commit as maintainer of the relevant thing.
[11:40:01 CEST] <jkqxz> If the author is committing it themselves to code they maintain, then maybe only they appear.  (Or not at all, since that is implicit.)
[11:40:08 CEST] <jkqxz> People are pretty inconsistent about using it, though.
[11:40:11 CEST] <nevcairiel> the SOB header means all sorts of different things to different people, the original usage the linux kernel uses is usually only used there =p
[11:40:25 CEST] <jkqxz> True.
[12:41:52 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:c535436cbeea: avcodec/mlpdec: Fix runtime error: left shift of negative value -22
[12:41:52 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:b20c71409b24: avcodec/fic: Fix multiple left shift of negative value -15
[12:41:52 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:c0ffcb34c7e9: avcodec/clearvideo: Fix multiple runtime error: left shift of negative value -1024
[13:17:03 CEST] <ubitux> nevcairiel: how do you deal with align for cropping?
[13:17:22 CEST] <ubitux> realloc when left cropping?
[13:18:26 CEST] <ubitux> same question with sample skipping
[13:19:15 CEST] <nevcairiel> probably
[13:19:37 CEST] <BtbN> wm4, feel free to push that cuvid patch btw.
[13:20:06 CEST] <wm4> already did
[13:20:07 CEST] <ubitux> nevcairiel: it could be much faster if the dsp was handling the unaligned part with C
[13:20:13 CEST] <ubitux> or something along these lines
[13:20:26 CEST] <BtbN> ah, missed that.
[13:20:44 CEST] <nevcairiel> ubitux: in most cases you would have to handle the entire thing in C then, which I doubt is going to be any faster then
[13:20:58 CEST] <nevcairiel> and it seems like a questionable optimization with a lot of complexity
[13:22:08 CEST] <ubitux> malloc+memcpy isn't great either when all you want is trimming 3 pixels on the left
[13:22:38 CEST] <ubitux> but i don't know, it's hard to have a general rule for that
[13:24:05 CEST] <BtbN> Why not just add an offset to the beginning, and reduce the width?
[13:24:20 CEST] <BtbN> Because of alignment of the initial pointer?
[13:24:49 CEST] <ubitux> yes
[13:25:08 CEST] <nevcairiel> alignment is two fold, you need to first pixel to be aligned properly of course, and the stride needs to be aligned so that further lines are also aligned
[13:25:54 CEST] <BtbN> yeah, probably not possible without either a memcpy, or a cropping parameter at the frame
[13:26:02 CEST] <ubitux> which reminds me that i never got done with png dsp on aarch64 because of the alignment requierement
[13:26:11 CEST] <ubitux> afaik the x86 dsp is handling it manually
[13:26:19 CEST] <ubitux> to support DR or whatever it was
[13:26:40 CEST] <ubitux> (or was it pngdec?)
[13:30:10 CEST] <ubitux> ah it wasn't about alignment but about padding
[13:30:25 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/189617.html
[13:31:05 CEST] <wm4> libav adds a cropping rect to AVFrame, so in theory you can crop by pixel
[13:31:30 CEST] <BtbN> But doesn't that mean that every single encoder/filter/.. needs to be aware of it?
[13:31:31 CEST] <wm4> of course that might be unusable in general
[13:31:35 CEST] <wm4> that too
[13:31:52 CEST] <ubitux> "if a user app returns pointers to some memory for direct rendering from get_buffer then it might be all kinds of stuff"
[13:31:56 CEST] <BtbN> filters probably not as much, as long as they pass it through untouched
[13:32:03 CEST] <ubitux> "for example it might be aligned but there might be data to the right like window decorations/border"
[13:32:10 CEST] <nevcairiel> get_buffer specifically documents alignment requirements
[13:33:12 CEST] <ubitux> shouldn't we have an alignment requirement check in avcodec encode side doing a realloc if needed?
[13:33:29 CEST] <nevcairiel> perhaps
[13:33:37 CEST] <ubitux> or we want it at frame level such that even lavfi could always assume alignment between filters?
[13:33:53 CEST] <nevcairiel> I also said as  much in my reply to nicolas, but I dont think per-codec alignment info is a practical thing
[14:44:14 CEST] <BBB> nevcairiel: I partially disagree with what you wrote
[14:44:23 CEST] <BBB> nevcairiel: I think a per-codec-*instance* is crazy
[14:44:28 CEST] <BBB> nevcairiel: but per-codec certainly makes sense
[14:44:37 CEST] <BBB> not all codecs have avx2
[14:44:48 CEST] <BBB> and updating that per-codec isnt so hard, you could even integrate that into the dsp_init functions
[14:45:27 CEST] <BBB> unsigned ff_h264dsp_init(H264DSPContext *ctx); <- return value is max_alignment
[14:45:33 CEST] <BBB> and then up that value for each arg dsp init
[14:45:39 CEST] <BBB> (or pointer; whatever)
[14:45:51 CEST] <BBB> however& I think it should be per-codec, not per-codec-instance
[14:46:02 CEST] <BBB> since its unlikely that one h264 needs 16 and another 32
[14:46:07 CEST] <BBB> they likely both need 32
[14:49:53 CEST] <nevcairiel> per codec makes determining that even harder though, since you cant call the dsp function to figure it out
[14:58:09 CEST] <BBB> maybe
[14:58:41 CEST] <BBB> or you declare it in the dsp header file, and then you can
[14:58:57 CEST] <BBB> we already have a substandard system (configure) to define which dec/* depends on which dsp
[14:59:09 CEST] <BBB> so why not use that and automatically generate alignment contraints from that?
[14:59:14 CEST] <BBB> this shouldnt be super-hard
[14:59:30 CEST] <BBB> per-codec enable/disable is also configure-generated
[15:24:59 CEST] <nevcairiel> I'm mostly worried about even more subtle bugs
[15:25:08 CEST] <nevcairiel> because our typical test cases of memory are always fully aligned
[15:25:15 CEST] <nevcairiel> so partial alignment will basically not be tested much
[15:33:25 CEST] <ubitux> pixelutils tests do test alignment :3
[15:35:17 CEST] <wm4> alignment of what?
[15:35:23 CEST] <ubitux> buffer
[15:35:28 CEST] <ubitux> :/
[15:35:40 CEST] <ubitux> the pointer passed to the dsp func
[15:35:54 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:4654baff125d: avcodec/opus_silk: Fix integer overflow and out of array read
[15:35:55 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:d58fe0177453: tools/target_dec_fuzzer: Do not use codec_id to look up decoder, but use selected decoder directly
[15:35:56 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:38e79d9d9c94: tools/target_dec_fuzzer: Do not attempt to fuzz VDPAU, its not supported
[15:35:57 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:fc2c420b8293: avcodec/mimic: Fix runtime error: left shift of negative value -1
[15:35:59 CEST] <ubitux> it misalign it before testing function that are supposed to support misaligned data
[16:10:13 CEST] <iive> nevcairiel: what is the issue here?
[16:10:28 CEST] <iive> also isn't avx a lot more relax about alignment?
[16:37:59 CEST] <BBB> nevcairiel: well
[16:38:06 CEST] <BBB> nevcairiel: I believe most affected code is simd, right?
[16:38:12 CEST] <BBB> nevcairiel: if we make it a goal to get 100% checkasm coverage
[16:38:19 CEST] <BBB> nevcairiel: we can test it effectively as part of checkasm
[16:38:22 CEST] <BBB> nevcairiel: which is part of fate
[16:38:27 CEST] <BBB> nevcairiel: wouldnt that be enough?
[16:57:32 CEST] <wm4> it's funny how I noticed problems with unaligned audio data and certain encoders years ago
[16:57:58 CEST] <wm4> I was all like "ok this is libavcodec bullshit" and simply changed my internal audio code to work like avframe
[16:59:45 CEST] <JEEB> sounds like a valid way of handling it
[17:12:32 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:4ace2d22192f: avcodec/g723_1: Fix multiple runtime error: left shift of negative value
[17:12:33 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:12936a4585bc: avcodec/dfa: Fix signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
[17:12:34 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:9bf4523e4014: avcodec/webp: Fix null pointer dereference
[17:15:27 CEST] <durandal_1707> ubitux: how is fft handled with avfft in lavc?
[17:16:21 CEST] <durandal_1707> first element and last one is 0 for img part
[17:34:22 CEST] <BBB> durandal_1707: the first elements img is the last elements real
[17:34:51 CEST] <BBB> durandal_1707: so that it doesnt require (2^n)+1 elements where the first/last img are 0, but instead just 2^n elements, thus making memory management slightly easier
[17:34:53 CEST] <BBB> (all this IIRC)
[20:53:23 CEST] <jamrial> michaelni: when were you planning on tagging 3.3.1?
[20:53:49 CEST] <jamrial> even if only a few fixes are backported, at least one of them is a very important CLI one
[21:04:15 CEST] <michaelni> jamrial, i wanted to fix and backport a few more issues, ossfuzz found quite a few new issues in the last days
[21:04:31 CEST] <jamrial> michaelni: ah ok
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:0884b1c5ffe0: avcodec/golomb: Assert that k is valid in get_ur_golomb_jpegls()
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:7b6a51f59c46: avcodec/shorten: Check k in get_uint()
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:2ef0f3927114: avcodec/mss3: Change types in rac_get_model_sym() to match the types they are initialized from
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:1283c4244767: avcodec/hq_hqa: Fix runtime error: left shift of negative value -207
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:df8575584dca: avcodec/shorten: Check residual size
[21:29:27 CEST] <ubitux> michaelni: "unsupportd" typo in df8575584dcacde187d92ee3142800373fd34882
[22:24:44 CEST] <cone-671> ffmpeg 03Aaron Levinson 07master:b9d2005ea5d6: avformat/utils: free AVStream.codec properly in free_stream()
[22:53:49 CEST] <cone-671> ffmpeg 03James Almer 07release/3.3:4f19268eee12: avcodec/options: factorize avcodec_copy_context() cleanup code
[22:53:50 CEST] <cone-671> ffmpeg 03James Almer 07release/3.3:8119efdbec1f: avcodec/options: do a more thorough clean up in avcodec_copy_context()
[22:53:51 CEST] <cone-671> ffmpeg 03Aaron Levinson 07release/3.3:329176adc52c: avformat/utils: free AVStream.codec properly in free_stream()
[23:25:19 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:277e397eb596: avutil/softfloat: Fix overflow in av_div_sf()
[23:25:20 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:e1b60aad77c2: avcodec/cdxl: Check format parameter
[23:25:21 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:8a8335de030a: avcodec/dds: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[00:00:00 CEST] --- Sun May  7 2017