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

[burek]

[00:43:59 CEST] <Lynne> jamrial: "Add new installed header libavutil/tx.h with a new API for transforms." <- okay as a doc/apichanges line?
[00:44:17 CEST] <Lynne> its the template for all other added headers
[00:45:00 CEST] <jamrial> Lynne: no, look at other entries for new headers. for example hdr_dynamic_metadata near the top
[00:45:58 CEST] <jamrial> don't write "add new installed header". write the header name in the line with the library version, date and commit hash, then in the description list the new symbols
[00:52:39 CEST] <Lynne> jamrial: "Add av_tx_init(), av_tx_uninit() and related definitions." then?
[00:53:21 CEST] <jamrial> sounds good
[01:02:30 CEST] <cone-010> ffmpeg 03Lynne 07master:87ee9d580c44: lavu: bump minor and update APIchanges for the new transform API
[07:01:29 CEST] <cone-646> ffmpeg 03Gyan Doshi 07master:8cf947ca4c60: avfilter/drawtext: stop resource leak
[10:38:10 CEST] <Lynne> durandal_1707: https://0x0.st/zA0O.diff
[10:39:01 CEST] <Lynne> you left 5 minutes before I got it working, it was a simple standard mdct
[10:41:36 CEST] <Lynne> you should compare it to a reference, though I'm sure the warbling is due to lack of pre-echo avoidance and quantization
[10:43:08 CEST] <cone-646> ffmpeg 03Paul B Mahol 07master:7990df05f722: doc/filters: mention obvious operation, for our always clueless users
[11:54:39 CEST] <j-b> durandal_1707: NI-CE
[11:55:17 CEST] <j-b> Where is that 320 coming from, btw?
[11:56:01 CEST] <durandal_1707> from source code
[11:56:57 CEST] <durandal_1707> its size of frame in samples
[11:59:41 CEST] <j-b>  s->number_of_coefs = 320; OK
[11:59:56 CEST] <j-b> So then, everything is arrays of 320
[12:04:11 CEST] <durandal_1707> yes, one could use #define here
[12:15:15 CEST] <Lynne> btw you should output floats instead of s16, you just need to set the transform scale to 1.0 / 32768 + the sample_fmt
[12:16:24 CEST] <j-b> Lynne: what is the benefit of this?
[12:17:46 CEST] <Lynne> no sample fmt conversion, its a float decoder
[12:48:01 CEST] <cone-646> ffmpeg 03Paul B Mahol 07master:6276b4db974e: avfilter/vf_separatefields: switch to activate
[14:01:11 CEST] <pross> durandal_1707: siren7 decoder is cool, but it crashes when i feed it MSN (yeah) RIFF WAV files
[14:01:43 CEST] <pross> http://samples.mplayerhq.hu/A-codecs/msnsiren/msnsiren.wav
[14:02:04 CEST] <pross> https://developer.pidgin.im/attachment/ticket/393/voice_clip.wav
[14:02:49 CEST] <durandal_1707> pross: where it crashes?
[14:03:01 CEST] <pross> it worked once upon a ime with this patch: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-July/127801.html
[14:03:16 CEST] <pross> Program received signal SIGSEGV, Segmentation fault.
[14:03:18 CEST] <pross> decode_vector (number_of_available_bits=<optimized out>, scale_factor=1, coefs=0x5555570d41ac, power_categories=0x5555570d397c, decoder_standard_deviation=0x5555570d390c, number_of_regions=14, s=0x5555570d3840) at libavcodec/get_bits.h:529
[14:03:46 CEST] <pross> siren_decode (avctx=0x5555570cae40, data=0x5555570d6040, got_frame=0x7fffffffd400, pkt=0x5555570c7d80) at libavcodec/siren.c:628
[14:06:50 CEST] <pross> without optimizations:
[14:07:05 CEST] <pross> #0  0x000055555601245d in decode_vector (s=0x55555788d840, number_of_regions=14, number_of_available_bits=30341, decoder_standard_deviation=0x55555788d90c, power_categories=0x55555788d97c, coefs=0x55555788e1ac, scale_factor=1) at libavcodec/siren.c:491
[14:11:40 CEST] <pross> durandal_1707: category is < 0, causing decoder_tree ptr to be meaningless
[14:12:14 CEST] Action: pross going to bed
[15:02:48 CEST] <durandal_1707> Lynne: somehow with AC4 and 2048/1024/512/256/128 transforms I get after several frames NaNs in output
[15:06:49 CEST] <Lynne> are you sure your lengths are correct and you're handling lapping correctly? fate passes here for vorbis and aac
[15:07:34 CEST] <durandal_1707> Lynne: it worked with old imdct
[15:07:53 CEST] <durandal_1707> (ret = ff_mdct_init(&s->mdct_ctx[i], av_log2(N_w) + 1, 1, 1.0 / (N_w))))
[15:12:06 CEST] <Lynne> try av_tx_init(&ctx, &fn, 1, N_w, &scale, 0)?
[15:16:27 CEST] <durandal_1707> if ((ret = av_tx_init(&s->tx_ctx[j][i], &s->tx_fn[j][i], AV_TX_FLOAT_MDCT, 1, N_w, &scale, 0)))
[15:25:05 CEST] <durandal_1707> looks like i did something wrong...
[18:34:44 CEST] <cone-646> ffmpeg 03Lynne 07master:6044534964a4: avutil/tx: fix forward compound non-mod-15 based MDCTs
[19:38:07 CEST] <durandal_1707> Lynne: if for old imdct is initialized with 2 * N, tx is initialized with just N ?
[19:40:07 CEST] <Lynne> yes, to convert all old mdct code you need to halve the length
[19:43:49 CEST] <durandal_1707> Lynne: but i get unset values in output
[19:53:38 CEST] <durandal_1707> Lynne: for MDCT transform of size N in tx, i get N*2 output?
[20:01:00 CEST] <Lynne> no, you init with a length N, you supply N coefficients and you get N samples out from tx_fn()
[20:01:41 CEST] <Lynne> you then feed those new N samples into vector_fmul_window along with your old samples and you get N samples out
[20:06:15 CEST] <Lynne> you need to be careful as vector_fmul_window's output shouldn't point into your old or new samples but the avframe directly optimally
[20:06:23 CEST] <durandal_1707> Lynne: but previous imdct would return N*2 samples out?
[20:08:04 CEST] <dlevin> Hello, I would love to get some inputs on the following patch (https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244101.html). The AVCodecParameters codec_tag is documented as an AV fourcc and mpegts.c is (IMO) breaking that contract by populating it with a PES stream_type. From that thread, Hendrik is expressing his desire to have the PES stream_type (understandable) but would it be possible to have a new field for th
[20:08:04 CEST] <dlevin> is instead of the codec_tag ? Thanks
[20:08:32 CEST] <Lynne> durandal_1707: oh, you're using the second version of imdct, the one which outputted 2x
[20:08:55 CEST] <Lynne> what's in the new api is the standard mdct, imdct_half
[20:10:00 CEST] <Lynne> imdct_calc is different and only used in 2 or so codecs, so I thought it better to either make it a flag or leave the code itself to do the post-processing since its a loop with 2 lines
[20:11:10 CEST] <Lynne> I'm not sure why exactly those 2 codecs (cook and wma voice) need that special imdct but I think they can be converted to use the standard imdct
[20:11:46 CEST] <Lynne> and I think definitely ac4 shouldn't have any problems using the standard imdct as its based off of ac3 and aac which do use the standard imdct
[20:13:21 CEST] <Lynne> does the decoder output something yet? I could try to make it use the standard mdct
[20:14:44 CEST] <durandal_1707> Lynne: yes, i will give you also stereo sample
[20:15:28 CEST] <Lynne> if you just need something which works for now you can copy the loop from ff_imdct_calc_c, its in-place so you just need to run it on your output
[20:20:28 CEST] <Lynne> can you rebase your working branch on git master? that'll make it easier (and faster because ccache)
[20:21:51 CEST] <durandal_1707> Lynne: i did already
[20:22:25 CEST] <durandal_1707> i now need to figure this "mirroring"
[20:29:01 CEST] <durandal_1707> i got it working
[20:32:07 CEST] <Lynne> "The weird thing here, is that the two halves of the time domain buffer are swapped. Also, the newest data, that we save away for next frame, has the wrong sign."
[20:32:19 CEST] <Lynne> ^^comment from cook.c
[20:32:50 CEST] <Lynne> so cook.c uses imdct_calc which does exactly what the sentence says and then cook.c undoes it by doing what the sentence says
[20:34:01 CEST] <Lynne> who thought it was a good idea to name the special imdct imdct_calc and the regular one imdct_half? whoever wrote the cook decoder probably got confused and used the former
[20:34:34 CEST] <durandal_1707> lol
[20:41:34 CEST] <durandal_1707> Lynne: https://0x0.st/zAdN.ac4
[20:42:13 CEST] <durandal_1707> https://github.com/richardpl/FFmpeg/tree/ac4
[20:43:54 CEST] <durandal_1707> https://0x0.st/zAdq.mp4 ->this one uses 1536 <= transforms and have artifacts with tx
[20:44:39 CEST] <durandal_1707> 96, 192, 384, 768, 1536 ---> should be supported?
[20:56:15 CEST] <cone-646> ffmpeg 03Gyan Doshi 07master:c2771bbf815b: doc/filters: update URL for sr filter script repository
[21:04:11 CEST] <durandal_1707> actually this was bug in code
[21:04:32 CEST] <durandal_1707> but i still get some artifacts in transitions
[21:17:24 CEST] <durandal_1707> hmm, there is bug somewhere else, not in tx
[21:23:18 CEST] <Lynne> durandal_1707: https://0x0.st/zAdt.diff
[21:23:53 CEST] <Lynne> I get a somewhat normal normal.ac4 output and a more normal than normal.ac4 weird.mp4
[21:24:34 CEST] <Lynne> if I use winl instead of s->kbd_window directly I get a better normal.ac4 but a worse weird.mp4
[21:25:49 CEST] <Lynne> but I'm hearing no incorrect mdct artifacts so yeah, the code was undoing what imdct_calc was doing like cook.c
[21:26:42 CEST] <Lynne> I don't understand what the compute_window() function does to the window but if you fix it it should work
[22:02:33 CEST] <durandal_1707> Lynne: i fixed 99.99% of artifacts, i doubt ac4 can use fmul_window, it uses different windows for overlap and normal pcm
[22:03:32 CEST] <Lynne> yeah, and fmul_window mirrors the window symmetrically
[22:04:17 CEST] <Lynne> what did you change?
[22:04:39 CEST] <durandal_1707> i pushed it to github
[22:04:59 CEST] <Lynne> oh, its still doing and undoing what imdct_calc did
[22:05:58 CEST] <durandal_1707> yes, feel free to improve it, but I doubt it can be done
[22:06:41 CEST] <Lynne> it can be done, as my diff demonstrated
[22:07:03 CEST] <Lynne> there were no out of place samples
[22:13:47 CEST] <durandal_1707> Lynne: the winl & winr are not symetric
[22:16:48 CEST] <durandal_1707> at last sometimes
[22:16:56 CEST] <durandal_1707> *least
[23:26:07 CEST] <cone-646> ffmpeg 03Ruiling Song 07master:65646db8e8d5: avutil/tx: should check against (*ctx)
[00:00:00 CEST] --- Fri May 17 2019