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

[burek]

[00:24:24 CEST] <thebombzen> I believe I've found a solution that allows using -r:v as an input option for streamcopy
[00:24:40 CEST] <thebombzen> and it passed "make fate". should I just send it to the email list?
[00:26:28 CEST] <thebombzen> it's here https://0x0.st/sEtq.patch
[15:25:35 CEST] <uau> https://github.com/mpv-player/mpv/issues/6218 <- that's apparently caused by "avctx->skip_frame = AVDISCARD_NONREF;" no longer working right with new x265-encoded files (used by mpv when doing precise seeks; what the PR says about "--hr-seek" not mattering is misleading)
[15:25:46 CEST] <uau> can anyone tell whether that's a libavcodec bug or x265 bug?
[15:27:12 CEST] <uau> the issue is visible in ffplay too if you add "d->avctx->skip_frame = AVDISCARD_NONREF;" as the first line of decoder_decode_frame() in ffplay.c
[15:38:29 CEST] <jamrial> uau: it could be a bug in libavcodec, like a nal unit wrongly listed in ff_hevc_nal_is_nonref() that new x265 generates
[15:46:02 CEST] <jamrial> uau: try removing HEVC_NAL_IDR_N_LP from that list, see if that helps
[15:51:38 CEST] <uau> ok testing
[15:54:03 CEST] <uau> commenting out "case HEVC_NAL_IDR_N_LP:" does remove visible corruption under ffplay
[17:48:37 CEST] <cone-281> ffmpeg 03Paul B Mahol 07master:8baaed7889f3: avfilter: add sinc source filter
[19:05:47 CEST] <durandal_1707> atomnuker: what is status of fft/mdct ?
[19:59:07 CEST] <atomnuker> durandal_1707: I think I need to scrap the work I did on having a wrapper layer for complex.h
[20:00:49 CEST] <atomnuker> I don't think c99 complex variables have a standard abi across all x86 platforms so we can't really pass them off to SIMD functions
[20:01:28 CEST] <atomnuker> plus they're now optional under c11 and they really don't improve anything either
[20:02:08 CEST] <atomnuker> I don't know why I thought they would be a nice idea but I probably looked at how the fftw api work and thought it was nice
[20:02:49 CEST] <atomnuker> they use their own float types but if you include <complex.h> before their header you can give it _Complex floats/doubles
[20:03:41 CEST] <atomnuker> oh well, I only did this for mdct15.c, not much at all
[20:04:22 CEST] <atomnuker> and I still need bofh_ to tell me how to modify that code to work for non-multiples of 15
[20:19:44 CEST] <cone-281> ffmpeg 03Carl Eugen Hoyos 07master:feb05ffa99fc: lavf/dump: Fix a typo: comentary -> commentary.
[20:33:54 CEST] <cone-281> ffmpeg 03Carl Eugen Hoyos 07master:10f468156c01: lavc/sinewin: Do not declare AAC 120/960 tables as const.
[20:37:34 CEST] <cone-281> ffmpeg 03Carl Eugen Hoyos 07master:6871c1717359: lavf/matroskadec: Simplify string length calculation.
[22:46:26 CEST] <durandal_1707> why we do not have 8k alias for frame size?
[22:46:39 CEST] <JEEB> we don't have aliases for a whole lot of frame sizes
[22:46:48 CEST] <JEEB> also do you mean UHD 8K or cinema 8K?
[22:47:20 CEST] <JEEB> 2K/4K/8K are not exactly something meaning a single thing :P
[22:47:32 CEST] <durandal_1707> we already have some uhd4320
[22:47:55 CEST] <JEEB> that's fun
[22:48:52 CEST] <durandal_1707> so i think our 2k/4k is cinema one
[22:51:47 CEST] <atomnuker> I think we can change it given it really didn't take off
[22:52:02 CEST] <durandal_1707> what change?
[22:52:32 CEST] <JEEB> atomnuker: you can just go look at which aspect ratio f.ex. tears of steel uses
[22:52:55 CEST] <JEEB> but yea, it's mostly just used in cinema and since we only get BD/UHD BD versions those are always 16:9 :P
[22:53:21 CEST] <durandal_1707> i prefer to type less
[00:00:00 CEST] --- Sat Oct 20 2018