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

[burek]

[02:00:23 CEST] <kierank> durandal_1707: keep a counter of relative position and flash on nearest frame
[02:59:12 CEST] <cone-753> ffmpeg 03James Zern 07master:1bee78a0198d: libvpxenc: allow aq-mode 4 (equator360)
[03:55:29 CEST] <cone-753> ffmpeg 03Lucas Cooper 07master:77bc507f6f00: avformat/movenc: Explicitly address potential division by zero.
[11:46:14 CEST] <cone-821> ffmpeg 03Paul B Mahol 07master:b8b0cece794d: doc/filters: add one lowpass filter example
[12:44:17 CEST] <cone-821> ffmpeg 03Anton Khirnov 07master:1783d7ec03d7: Changelog: add some missing entries
[12:44:18 CEST] <cone-821> ffmpeg 03Clément BSsch 07master:fe86fa7c0abf: Merge commit '1783d7ec03d730c5bd96c07bc5fa7aa566f85c66'
[12:45:45 CEST] <cone-821> ffmpeg 03Anton Khirnov 07master:ea8b730d8e67: hevcdec: add a VAAPI hwaccel
[12:45:46 CEST] <cone-821> ffmpeg 03Clément BSsch 07master:b893f3f54333: Merge commit 'ea8b730d8e67152107d7fcdd5590bbb51ec236b1'
[12:46:22 CEST] <cone-821> ffmpeg 03Anton Khirnov 07master:cfa4eb4fba78: vaapi_decode: use the correct logging context
[12:46:23 CEST] <cone-821> ffmpeg 03Clément BSsch 07master:5729acee8214: Merge commit 'cfa4eb4fba782f3f37a33be997b27a91a07053c9'
[12:51:55 CEST] <cone-821> ffmpeg 03Anton Khirnov 07master:46191a2da16f: mov: fix a possible invalid read in mov_read_mac_string()
[12:51:56 CEST] <cone-821> ffmpeg 03Clément BSsch 07master:e166fe2e1f0a: Merge commit '46191a2da16f751e53d93646ae1388d421d12bee'
[12:54:15 CEST] <ubitux> michaelni: is 740959fdbfbf804ccd8a6e426b1b1ba321fe5cfb enough to fix the overflow fixed in 58405de0951a843765625159402870c1eea3c3b1?
[12:55:53 CEST] <ubitux> same question with e807491fc6a336e4becc0cbc981274a8fde18aba
[13:21:45 CEST] <michaelni> ubitux, the libav code refered to is wrong for us and i doubt the problem it fixes applies to us.
[13:24:30 CEST] <ubitux> michaelni: ok, for both commits?
[13:33:55 CEST] <michaelni> yes, they do more or less the same thing
[13:45:40 CEST] <ubitux> ok
[13:46:23 CEST] <ubitux> thanks
[13:51:07 CEST] <cone-821> ffmpeg 03Anton Khirnov 07master:58405de0951a: mpegvideo_parser: avoid signed overflow in bitrate calculation
[13:51:08 CEST] <cone-821> ffmpeg 03Anton Khirnov 07master:e807491fc6a3: mpeg12dec: avoid signed overflow in bitrate calculation
[13:51:09 CEST] <cone-821> ffmpeg 03Clément BSsch 07master:85452f9ab7aa: Merge commit 'e807491fc6a336e4becc0cbc981274a8fde18aba'
[16:39:17 CEST] <ubitux> who wants to merge/skip the next commits?
[17:15:35 CEST] <jamrial> ubitux: the mpeg2video commit doesn't apply cleanly, but does after you look where the code was moved. i however don't know if we even need it at all
[17:17:54 CEST] <ubitux> the libav sample doesn't work in ffmpeg
[17:18:13 CEST] <ubitux> like, it's detected as mp3 and can't make it interpret it properly as mpeg (or i'm doing something wrong)
[17:18:17 CEST] <jamrial> which is it?
[17:18:27 CEST] <ubitux> https://github.com/asarubbo/poc/blob/master/00037-libav-signedintoverflow-mpegvideo_parser
[17:18:44 CEST] <ubitux> see https://bugzilla.libav.org/show_bug.cgi?id=981 + 999
[17:20:54 CEST] <jamrial> try ffmpeg -f mpegvideo -i sample
[17:20:57 CEST] <jamrial> that worked for me
[17:21:11 CEST] <thardin> what's the state of html5 video these days?
[17:21:47 CEST] <thardin> I got a request from my old buss to consult for some attempt to do frame-accurate stuff on the web. but not enough time for it (or desire for hair-pulling tbh)
[17:21:53 CEST] <thardin> boss*
[17:22:51 CEST] <jamrial> ubitux: that sample fails the same way without merging this patch than after merging it
[17:23:00 CEST] <jamrial> invalid data error then conversion failed
[17:23:05 CEST] <jamrial> no segfault
[17:25:58 CEST] <jamrial> ubitux: https://pastebin.com/raw/91z5V5uX that's the patch merged. fate passes, but it doesn't seem to change how that file is handled
[17:27:02 CEST] <ubitux> yeah that's how i assumed it should be merged but the sample didn't seem to reach the decoder in the first place and so i couldn't test
[17:27:47 CEST] <jamrial> try the above command to force mpeg2video demuxer. for some reason it detects it as mp3
[17:28:38 CEST] <jamrial> the h264 commit after this doesn't seem to apply at all. without looking much into it i'd say we should skip it, since our slice code is very different than theirs
[18:04:30 CEST] <wm4> can anyone confirm how formats like AV_PIX_FMT_GBRP10 work? in my opinion, it simply uses the range [0,2^10) - is that wrong?
[18:10:32 CEST] <J_Darnley> wm4: I would assume so.  Like with the 10-bit yuv formats it allows some head room for doing math in just 16-bit data.
[18:21:58 CEST] <jamrial> michaelni: could you check if this is useful/superfluous/harmless? https://github.com/jamrial/FFmpeg/tree/mergework
[18:22:20 CEST] <jamrial> the file (see ubitux's link above) this fixes in libav "works" the same with ffmpeg with or without this commit merged
[18:22:38 CEST] <wm4> J_Darnley: any certainty how gray formats are represented?
[18:23:01 CEST] <wm4> like AV_PIX_FMT_GRAY10
[18:29:37 CEST] <wm4> just going by hevc_ps.c (where's the h264 part of this?), I'd guess it actually depends on the vui->matrix_coeffs field
[18:30:03 CEST] <wm4> (also why does it not export vui->video_full_range_flag as color_range)
[18:38:11 CEST] <nevcairiel> it does, but setting avctx from sps is in another place
[18:38:22 CEST] <wm4> where?
[18:38:31 CEST] <nevcairiel> export_stream_params in hevcdec.c
[18:39:01 CEST] <nevcairiel> since you can have multiple sps'es, parsing and activating are split
[18:39:42 CEST] <wm4> ah, overlooked it
[18:39:58 CEST] <wm4>         if (vui->video_full_range_flag && sps->pix_fmt == AV_PIX_FMT_YUV420P)
[18:39:58 CEST] <wm4>             sps->pix_fmt = AV_PIX_FMT_YUVJ420P;
[18:40:02 CEST] <wm4> that confused me
[18:40:13 CEST] <nevcairiel> all those shitty hacks for the J formats
[18:40:23 CEST] <wm4> indeed
[18:43:34 CEST] <jamrial> they have been "deprecated" for what, five years now?
[18:43:51 CEST] <wm4> at least
[18:44:05 CEST] <nevcairiel> unfortunately a bunch of stuff still has no replacement handling
[18:44:09 CEST] <wm4> last time this came up, libavfilter and libavcodec encoding "relied" on them for format negotiation
[18:44:52 CEST] <JEEB> I thought that was swscale?
[18:45:14 CEST] <wm4> no swscale could handle it
[18:45:22 CEST] <wm4> for the conversions it supports
[18:45:29 CEST] <JEEB> hmm
[18:45:58 CEST] <nevcairiel> sws basically abstracts it away on input anyway and converts it into a flag
[18:46:35 CEST] <nevcairiel> which you can set manually
[18:46:47 CEST] <nevcairiel> but avfilter format negotiation probably doesnt account for it
[18:47:02 CEST] <wm4> correct
[18:47:27 CEST] <wm4> and encoding has generally no handling of it either (I recently had a bad experience with mjpegenc)
[18:51:43 CEST] <durandal_1707> fine to push smthing?
[19:00:20 CEST] <jamrial> yes
[19:13:40 CEST] <cone-509> ffmpeg 03Paul B Mahol 07master:8341d0dd0e5f: avfilter: add pixscope filter
[19:13:40 CEST] <cone-509> ffmpeg 03Paul B Mahol 07master:399c7ab9c6bc: avfilter: add video oscilloscope filter
[21:18:13 CEST] <michaelni> jamrial, i dont really see what this fixes, i also dont see what it would break. 
[21:19:09 CEST] <jamrial> michaelni: if it's harmless then maybe it's worth merging to reduce differences with libav a bit
[21:19:13 CEST] <jamrial> but if you prefer to play it safe i can noop it
[21:19:57 CEST] <michaelni> choose what you prefer, i cant really tell for this one
[21:19:59 CEST] <jamrial> and it probably fixes some crash/overread you fixed a long while ago, back when you moved the code around
[21:20:59 CEST] <jamrial> ok, thanks
[21:21:44 CEST] <uau> jamrial: doesn't that commit have a fairly clear problem description?
[21:21:53 CEST] <uau> so it should be possible to tell whether the problem can occur or not
[21:21:55 CEST] <jamrial> wm4: it doesn't apply to us
[21:22:16 CEST] <jamrial> the file it mentions it fixes behaves the same without this merger and without
[21:22:40 CEST] <jamrial> michaelni probably fixed this long ago in a differnent way, which is why it doesnt apply cleanly to begin with, since the code was moved around
[21:22:52 CEST] <jamrial> sorry, uau
[21:23:18 CEST] <uau> from the commit message it looks like something you should be able to tell from the code
[21:23:26 CEST] <uau> without needing to rely on testing
[00:00:00 CEST] --- Sun Apr 30 2017