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

[burek]

[01:06:08 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:f8f762c300e2: tests/fate/filter-video: increase fuzz for fate-filter-refcmp-psnr-rgb
[01:06:09 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:ab1319d82f0c: avformat/mpegts: Fix side data type for stream id
[01:06:10 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:68e011e4103b: avcodec/avcodec: Document the data type for AV_PKT_DATA_MPEGTS_STREAM_ID
[01:06:11 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:21f4b456f1ff: avformat/mov: Simplify get_stream_info_time()
[01:06:12 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:8a708aa99cb0: avcodec/rpza: Move frame allocation to a later point
[01:06:13 CET] <cone-290> ffmpeg 03Michael Niedermayer 07master:e63517e00a1a: avcodec/rpza: Check that there is enough data for all the blocks
[02:47:20 CET] <cone-290> ffmpeg 03Peter Ross 07master:fa0f898e3f78: configure: --help typo
[02:47:21 CET] <cone-290> ffmpeg 03Peter Ross 07master:d80eb8409c5a: configure: --help should dipslay --host-extralibs
[02:47:22 CET] <cone-290> ffmpeg 03Peter Ross 07master:16ec62bbf434: configure: make --windres option work
[11:58:05 CET] <cone-256> ffmpeg 03Jun Zhao 07master:90c45342066b: lavc/options_table: Change some options location in opt table.
[11:58:06 CET] <cone-256> ffmpeg 03Jun Zhao 07master:59deae5d1c4d: lavc/libkvazaar: Use avctx->frame_rate first for framerate setting
[11:58:07 CET] <cone-256> ffmpeg 03Jun Zhao 07master:3f08ed3920ee: lavc/libkvazaar: indent the code
[14:25:31 CET] <jamrial> michaelni: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88559
[14:25:50 CET] <jamrial> they don't plan to fix it, saying it was never meant to work
[14:26:13 CET] <jamrial> so if you want libpostproc to compile with gcc 9, you may want to work around this
[14:33:38 CET] <Compn> ehehe gcc
[14:33:54 CET] <Compn> always breaking ffmpeg compilation
[14:37:26 CET] <jamrial> michaelni: does any fate test cover that inline asm? has it ever worked?
[14:38:27 CET] <jamrial> i'd imagine that someone would have reported a crash if gcc has been silently generating bad assembly out of this code for the past 10 years
[14:39:37 CET] <Compn> are we still supporting 3dnow ?
[14:41:31 CET] <Compn> not that i'm against it. however i am not sure its useful to apply post process to 1080 h265 on a amd k6-2 :P
[14:41:33 CET] <jamrial> only what's already there
[14:44:09 CET] <Compn> although wikipedia says newer amd still had 3dnow
[14:44:17 CET] <Compn> https://en.wikipedia.org/wiki/3DNow!#Processors_supporting_3DNow
[14:45:16 CET] <jamrial> up to athlon 64, but starting with athlon xp they also have sse, so 3dnow is pointless
[14:45:25 CET] <Compn> https://web.archive.org/web/20131109151245/http://developer.amd.com/community/blog/2010/08/18/3dnow-deprecated/
[14:48:48 CET] <Compn> isnt the whole inline asm gcc why we switched to yasm/nasm in the first place ?
[14:49:37 CET] <Compn> just trying to refresh the old memory banks
[14:53:31 CET] <jamrial> for portability reasons, yeah
[14:54:06 CET] <jamrial> but nobody really cared about postproc, so it remained as is
[14:55:38 CET] <Compn> right it was a separate -pp option
[14:55:53 CET] <Compn> now i think it is also used in video filters maybe ? i know mplayer used it as a filter for ages
[14:56:27 CET] <Compn> gotta make those postage stamp resolution videos look better somehow :)
[14:58:09 CET] <jamrial> pretty much why nobody has cared about postproc for the better part of the last decade and a half, yes :)
[15:03:00 CET] <iive> jamrial, why do we need rsp marked as clobbered. from what i see in the code it does "push" then "pop" right away, without any branching inside.
[15:04:00 CET] <jamrial> iive: i have no idea, i didn't look at it
[15:37:22 CET] <michaelni> jamrial, iam not aware of the code failing in any case, well before today learning about next gcc not building it though thats more of a artifical failure
[15:39:00 CET] <jamrial> michaelni: they are taking the error at face value, it seems. i don't know if the code effectively tries to clobber the stack pointer or not
[15:40:03 CET] <jamrial> either it is and gcc silently generated invalid assembly for the past decade, or it isn't and this is a gcc regression they don't seem to want to look into
[15:50:59 CET] <michaelni> I think (but may be wrong) that the sp on the list was intending to tell gcc that it cannot use E/RSP as a general purpose register. The code does not clobber *sp in the sense that its different at the end compared to the begin but the code will push a value onto the stack. If a smart compiler would use rsp as a general purpose register then rsp would not point to the stack and something really bad would happen
[15:51:21 CET] <michaelni> in practice the clobber entry for sp can probably just be dropped
[15:56:16 CET] <jamrial> feel free to fix that, because gcc sure looks like they don't plan to :p
[15:56:39 CET] <iive> i think that the clobbering is more to signal that the stack itself is clobbered, aka that we use it
[15:58:10 CET] <iive> hum, i'm wrong
[15:58:32 CET] <iive> 78d2d1e0270 put rsp on the clobber list to prevent gcc from using it in "q" 
[15:59:31 CET] <iive> Fixes Ticket2675
[16:11:23 CET] <jamrial> michaelni: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00532.html
[16:11:36 CET] <jamrial> so looks like postproc needs to be fixed
[16:13:41 CET] <jamrial> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[16:13:50 CET] <jamrial> August 2003
[16:15:00 CET] <jamrial> so how did postproc even work after 78d2d1e0270?
[16:19:06 CET] <iive> jamrial, did you see what i said?
[16:19:25 CET] <jamrial> iive: yes
[16:19:37 CET] <iive> ok.
[16:20:02 CET] <jamrial> that commit technically made the code invalid, as gcc would not generate correct assembly
[16:20:13 CET] <iive> ??
[16:20:45 CET] <jamrial> it's clobbering rsp
[16:22:16 CET] <iive> https://trac.ffmpeg.org/ticket/2675
[16:22:58 CET] <iive> it seems to "workarond" or "hack" a gcc-4.7 bug, where the gcc would use rsp as gprs
[16:23:25 CET] <iive> we just have to check when this bug has been fixed, if it has been fixed at all.
[16:23:35 CET] <jamrial> yeah, yet it seems clobbering esp/rsp is not a valid workaround, seeing it was forcefully forbidden in the gcc patch in linked above
[19:22:36 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:4b5977fc5011: avfilter/af_sofalizer: add printing of license back
[19:22:36 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:1ead98ffd9cd: avfilter/af_sofalizer: increase max radius
[19:33:45 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:d06aae732c16: avformat: add vividas demuxer
[20:32:00 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:d6951e595a2b: avfilter/af_sofalizer: add framesize option
[21:22:41 CET] <cone-296> ffmpeg 03Paul B Mahol 07master:1b4c01631b1a: avcodec/vc1_parser: use init_get_bits8()
[21:57:34 CET] <cone-296> ffmpeg 03James Almer 07master:064f9505f498: avcodec/cbs_av1: fix parsing delta_frame_id_minus1
[22:31:34 CET] <cone-296> ffmpeg 03James Almer 07release/4.1:5356e610010a: avcodec/cbs_av1: fix parsing delta_frame_id_minus1
[23:33:12 CET] <cone-296> ffmpeg 03Jacob Trimble 07master:555f332e7adb: libavformat/mov: Fix NULL-dereference read for some encrypted content.
[00:00:00 CET] --- Fri Dec 21 2018