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

[burek]

[00:33:39 CEST] <pross> kurosu: i am gonna run some CACHED_BITSTREAM_READER test. this is a global change, and will alter the decodeing performance of all codecs in vp3.c
[01:36:12 CEST] <BBB> pross: "all codecs in vp3.c" isn't that many, it's just vp3 and theora, no?
[01:39:57 CEST] <jamrial> and soon vp4 :p
[01:51:31 CEST] <TD-Linux> vp4 in the wild???
[07:38:16 CEST] <sigdrak> pross : libav went over something similar a few years back. iirc, ac3 caused some specific pain. I guess the biggest drawback is potential regressions, but hey, easy CVEs!
[09:59:33 CEST] <kurosu> pross: ok, I guess that means you need to run fate also for these codecs mentioned by BBB
[12:10:02 CEST] <kurosu> Whenever I read that Amazon Prime Video specialist over doom9, I'm flabbergasted Amazon can't pay up for his request
[12:15:53 CEST] <j-b> which request?
[12:17:32 CEST] <kurosu> "Plz provide an overview of this vvc feature"
[12:18:10 CEST] <kurosu> Last time, it was "oh, ffmpeg is slow at decoding hevc, I need it faster"
[12:19:27 CEST] <kurosu> nevcairiel: isn't the last one something we discussed at the time?
[13:37:51 CEST] <nevcairiel> what last one? wanting faster hevc? :)
[14:06:35 CEST] <kurosu> nevcairiel: yeah, I think you had the same reaction as me on that occasion, thus my asking you. Though I understand it's out of the blue and so unremarkable...
[14:07:31 CEST] <nevcairiel> I can only guess that maybe he isnt posting in a professional capacity in some cases, or that big companies are just cheap :)
[14:34:52 CEST] <durandal_1707> nevcairiel: who?
[16:02:48 CEST] Action: JEEB wonders if anyone tested the HLS master playlist generation with subtitles
[17:09:58 CEST] <JEEB> ok, so it is partially because of the "silent" _vtt.m3u8 stuff in the HLS muxer
[17:10:17 CEST] <JEEB> and then someone copied the if/else needing logic for the master playlist variant list stuff
[17:10:40 CEST] <JEEB> while probably not understanding the consequences of having to add the if/else logic into places
[19:33:07 CEST] <durandal_1707> Lynne: gonna push your tx patch
[19:35:32 CEST] <Lynne> I can do that myself, there's a couple of documentation clarifications I've made
[19:38:23 CEST] <durandal_1707> Lynne: than when you gonna push it?
[19:38:29 CEST] <cone-010> ffmpeg 03Lynne 07master:f62ee527cbda: aarch64/asm-offsets: remove old CELT offsets
[19:38:30 CEST] <cone-010> ffmpeg 03Lynne 07master:b79b29ddb15c: libavutil: add an FFT & MDCT implementation
[20:44:34 CEST] <cone-010> ffmpeg 03Philip Langdale 07master:89bd7554b209: avfilter/vf_scale_cuda: Fix incorrect scaling of > 8bit content
[20:44:35 CEST] <cone-010> ffmpeg 03Philip Langdale 07master:bfbde996cfa5: avfilter/vf_scale_cuda: Add support for YUV444P16
[20:44:36 CEST] <cone-010> ffmpeg 03Philip Langdale 07master:13168ecbdc03: avfilter/vf_scale_cuda: Simplify output plane addressing
[20:53:08 CEST] <durandal_1707> Lynne: what is diff between DCT and MDCT? and does siren use MDCT?
[20:58:28 CEST] <kurosu> audio codecs usually use overlapped blocks for applying transforms because the discontinuities would be very disturbing
[20:58:46 CEST] <kurosu> and to conciliate decoding of samples belonging to 2 blocks, you apply a window
[20:59:23 CEST] <kurosu> durandal_1707: oh well, the wikipedia entry is good enough for a reading
[20:59:39 CEST] <kurosu> that or ask the daala/opus/xiph guys
[21:00:52 CEST] <kurosu> (or maybe the question was more technical and it's more about some specific difference)
[21:01:53 CEST] <Lynne> durandal_1707: a DCT is just an FFT with all imaginary parts set to 0
[21:05:41 CEST] <Lynne> dct4 from libsiren looks as if it does folding on the output so maybe its an mdct
[21:06:27 CEST] <Lynne> but there's no way to set transform direction so they can't be using that same code for forward transforms
[21:06:36 CEST] <durandal_1707> i get segv when using MDCT
[21:07:10 CEST] <Lynne> make sure the length is correct
[22:18:00 CEST] <durandal_1707> Lynne: forward mdct seems broken
[22:18:25 CEST] <durandal_1707> it crashes here
[22:19:48 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/pull/310 wtf
[22:21:17 CEST] <durandal_1707> lol
[22:22:49 CEST] <nevcairiel> i could punch people that just randomly click shit on github until they get a textbox
[22:23:32 CEST] <durandal_1707> Lynne: i cant get siren to work, i get artifacts when overlaping segments
[22:24:27 CEST] <durandal_1707> like overlapping does not work at all
[22:25:23 CEST] <TheAMM> lol that pr
[22:25:32 CEST] <durandal_1707> https://github.com/richardpl/FFmpeg/tree/siren
[22:30:12 CEST] <Lynne> durandal_1707: I think it might not be a standard dct but some other DCT-IV variant with another form of lapping
[22:30:37 CEST] <Lynne> "Modulated Lapped Transform" according to wikipedia
[22:35:02 CEST] <durandal_1707> and what that means?
[22:36:24 CEST] <Lynne> wait, if this is an mdct where do you manage lapping? you need to do e.g. https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/atrac9dec.c#L754
[22:38:18 CEST] <durandal_1707> right bellow transform? it uses sine window of 320 elements
[22:39:46 CEST] <Lynne> right, then you need an FFT if your code does lapping, not an mdct
[22:40:19 CEST] <Lynne> although that does look like a normal mdct written in a weird way, do you have a sample?
[22:43:50 CEST] <durandal_1707> Lynne: http://samples.ffmpeg.org/vivo/vivo2/rolandinter1.viv
[23:06:30 CEST] <cone-010> ffmpeg 03Guo, Yejun 07master:ae6486c62510: configure: replace 'pr' with printf since busybox does not support pr
[00:00:00 CEST] --- Thu May 16 2019