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

[burek]

[01:11:27 CEST] <atomnuker> durandal_1707: better just mark the function as sse4 since its been around for 11 or so years now
[09:23:44 CEST] <cone-829> ffmpeg 03Paul B Mahol 07master:c3f10ea4bb04: avcodec/alsdec: remove unused header
[09:25:51 CEST] <cone-829> ffmpeg 03Paul B Mahol 07master:cbbd330abc95: avcodec/alsdec: fix some undefined shifts
[10:00:59 CEST] <durandal_1707> isnt aac-sls storing lossless part in separate stream?
[10:11:10 CEST] <wm4> API question: we're doing some kind of live streaming with HLS (with ffmpeg being on both muxing and demuxing side), which involves a sliding window of active content
[10:11:19 CEST] <wm4> apparently HLS has mechanisms for that, but there's no API that could be used to let the HLS demuxer report the current window start/end to the API user
[10:11:26 CEST] <wm4> any ideas
[10:22:51 CEST] <cone-829> ffmpeg 03Paul B Mahol 07master:1212041c91b7: avfilter/vf_ssim: use unsigned so result can be properly stored
[13:21:28 CEST] <wm4> jkqxz: does that patch apply to ffmpeg too?
[13:22:42 CEST] <jkqxz> Maybe?  I didn't try.
[13:23:11 CEST] <wm4> would be more convenient because I have my ffmpeg build configured to link to mfx
[13:26:13 CEST] <wm4> it did
[13:26:31 CEST] <wm4> jkqxz: what's the command line for it?
[13:27:53 CEST] <jkqxz> "-hwaccel d3d11va -hwaccel_output_format d3d11 -i in.mp4 -an -vf 'hwmap=derive_device=qsv,format=qsv' -c:v h264_qsv -frames:v 1000 out.mp4"
[13:29:51 CEST] <wm4> jkqxz: Error during encoding: device failed (-17)
[13:31:56 CEST] <jkqxz> Ha.
[13:32:14 CEST] <jkqxz> A third behaviour, then.
[13:33:47 CEST] <wm4> using h264_qsv without any hw stuff works
[13:34:12 CEST] <jkqxz> Does it work with dxva2?
[13:34:25 CEST] <jkqxz> (Replace above with "-hwaccel dxva2 -hwaccel_output_format dxva2_vld".)
[13:35:54 CEST] <wm4> different error
[13:36:10 CEST] <wm4> Error in child device handle setup: type mismatch (3 != 1)
[13:36:15 CEST] <jkqxz> Oh, you need to do that on vanilla.
[13:36:31 CEST] <jkqxz> The patch breaks DXVA2 because I didn't sort out how to manage the differences.
[13:38:47 CEST] <wm4> I get tons of get_buffer failures
[13:45:58 CEST] <jkqxz> Running out of surfaces?
[13:57:34 CEST] <wm4> possibly
[13:58:41 CEST] <wm4> or leaking them
[13:58:48 CEST] <wm4> encoding a small number of frames makes it work
[13:59:39 CEST] <jkqxz> Ohyeah, ffmpeg h264_qsv defaults to 9001 frames of lookahead.
[14:00:03 CEST] <jkqxz> -look_ahead 0
[14:01:15 CEST] <BBB> 9000 frames lookahead o_O
[14:02:38 CEST] <jkqxz> Well, some number which is, relatively speaking, over nine thousand.  It might atually be 50 or something.
[14:02:52 CEST] <wm4> it doesn't find a -look_ahead option
[14:03:35 CEST] <nevcairiel> if your qsv sdk is too old its not available
[14:03:47 CEST] <nevcairiel> otherwise it should be called look_ahead
[14:04:12 CEST] <jkqxz> This one: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/qsvenc_h264.c;h=389335f39d260c571cd2db0457d8a84ab35003bf;hb=HEAD#l110>.
[14:04:19 CEST] Action: J_Darnley loves that vintage meme
[14:17:06 CEST] <iive> over 9000 !
[15:12:20 CEST] <cone-362> ffmpeg 03Kevin Mark 07master:d32a6c36e44c: libavfilter/scale2ref: Maintain main input's DAR
[15:19:26 CEST] <durandal_1707> atomnuker: im adding 960 support to aac decoder and ffmpeg stills decodes with frequency response lower than faad2
[15:20:02 CEST] <durandal_1707> all frequencies are lower than they should be
[15:21:00 CEST] <atomnuker> oh hey I did some work on that too
[15:21:06 CEST] <atomnuker> I almost got it to run as well
[15:21:40 CEST] <atomnuker> anyway, just add a 960 mdct context and a 120 mdct context
[15:21:55 CEST] <atomnuker> change the nb_samples on the output depending on whether short_frame is on
[15:22:01 CEST] <nevcairiel> i was told some time ago that its still more work then just replacing the mdct
[15:22:51 CEST] <atomnuker> set the mdct scale to be the same as the mdct480 transform
[15:23:14 CEST] <atomnuker> and write a new imdct_and_windowing function
[15:23:36 CEST] <atomnuker> I got as far as to change all the windowing to what I believe to be right and almost got correctly decoded stuff
[15:24:01 CEST] <atomnuker> but the issue was the tables
[15:24:13 CEST] <atomnuker> the tables need to be either rewritten or patched
[15:24:31 CEST] <atomnuker> some tabled have the last entry set to 0 and some are completely different
[15:26:51 CEST] <atomnuker> search for 960 in ISO 13818-7, that has all the tables
[15:30:04 CEST] <atomnuker> durandal_1707: here's my diff https://pars.ee/temp/aac_960.diff
[15:38:02 CEST] <atomnuker> the only 960 sample I have is that weird 20sec lounge music which seems to have SBR as well
[15:38:29 CEST] <atomnuker> (and oddly enough SBR works as is, without any changes)
[15:38:42 CEST] <atomnuker> maybe my window is wrong as well
[15:44:03 CEST] <J_Darnley> WTF!  That VC2 reference encoder needs boost?!  What a POS!
[15:45:45 CEST] <JEEB> :D
[15:46:53 CEST] <wm4> whatever vc2 is, it's probably a POS too
[15:47:14 CEST] <J_Darnley> also known as Dirac, a "professional" video format
[15:47:19 CEST] <wm4> oh
[15:47:22 CEST] <kierank> J_Darnley: oh forget about the reference encoder
[15:47:26 CEST] <kierank> seriously it's a world of pain
[15:47:37 CEST] <kierank> atomnuker can tell you
[15:47:49 CEST] <J_Darnley> No.  I need a correct video file.
[15:48:22 CEST] <J_Darnley> One that is supposed to have slices
[15:48:28 CEST] <kierank> ffmpeg can do that
[15:49:02 CEST] <kierank> seriously the reference encoder is near-impossible to use
[15:49:11 CEST] <atomnuker> there is no special sliced version of dirac, it always has slices and they're all individually decodable
[15:49:27 CEST] <kierank> yeah it's not like h264
[16:17:13 CEST] <J_Darnley> You were right.  It is even more rubbish than I thought.
[16:17:38 CEST] <J_Darnley> 4fps and a file 10x bigger than ffmpeg's
[16:17:50 CEST] <J_Darnley> even then ffmpeg cannot decode it
[16:37:19 CEST] <J_Darnley> I have no idea what's wrong
[16:40:47 CEST] <J_Darnley> changing the strides just makes it worse
[16:41:24 CEST] <kierank> can you push your latest code and I will look
[16:41:40 CEST] <J_Darnley> It is already on gitlab, apparently
[16:45:26 CEST] <kierank> i would still suggest implementing your own naive haar
[16:53:41 CEST] <kierank> J_Darnley: i think the dsp functions assume stuff you can't assume per slice
[17:13:02 CEST] Action: J_Darnley signs
[17:13:09 CEST] <J_Darnley> well I sigh
[17:47:51 CEST] <durandal_1707> atomnuker: i dont see 960 related numbers in that pdf
[17:50:27 CEST] <atomnuker> durandal_1707: they start on page 62 (as printed on the pdf) or page 73 (as total document page number goes)
[17:56:59 CEST] <durandal_1707> atomnuker: those are for 128
[18:00:56 CEST] <atomnuker> durandal_1707: actually you're right, check out page 561 in 2010318163752818.pdf
[18:04:33 CEST] <durandal_1707> atomnuker: gone from net
[18:05:49 CEST] <atomnuker> durandal_1707: https://0x0.st/0y2.pdf
[18:15:36 CEST] <J_Darnley> atomnuker, kierank: where can I find the basic description of the haar transform?  I couldn't see it in the two BBC papers I have
[18:15:44 CEST] <kierank> J_Darnley: in the spec, no?
[18:17:15 CEST] <atomnuker> yeah, I think the spec has 'em
[18:17:25 CEST] <J_Darnley> where did I put that then
[18:17:28 CEST] <atomnuker> or just look at the forward transforms and change the signs IIRC
[18:19:28 CEST] <J_Darnley> oh right, I got it from your NAS so it won't be in my d/l folder
[18:44:23 CEST] <J_Darnley> up yours Telenet
[19:00:35 CEST] <atomnuker> 53 euro for unlimited 200mbps with only 20mpbs upload?
[19:01:15 CEST] <atomnuker> well its not much better here, in fact its worse
[19:02:11 CEST] <atomnuker> I miss getting 150mpbs symmetric unfiltered ftth for 15 euros
[19:03:55 CEST] <J_Darnley> It isn't the worst advertised but their infrastructure leaves much to be desired.
[19:04:05 CEST] <JEEB> 100/10 in my case for 49
[19:04:16 CEST] <JEEB> would go 1000/10 for like 70 or 80
[19:04:37 CEST] <BtbN> 10 Mbit upload can't even saturate 1Gbit down
[19:05:02 CEST] <JEEB> yea
[19:05:05 CEST] <J_Darnley> UDP man!  No need to send any acks!
[19:05:11 CEST] <JEEB> :D
[19:06:45 CEST] Action: J_Darnley goes afk
[19:13:44 CEST] <durandal_1707> atomnuker: so whats missing for 960 case?
[19:23:09 CEST] <atomnuker> fix the tables where actually needed and investigate why the window seems wrong (makes a spike every 20msec)
[19:23:43 CEST] <atomnuker> in the opposite order of importantness, the tables will work as they are
[19:24:06 CEST] <atomnuker> (just won't be correct/up to spec but they'll sound alright)
[19:26:00 CEST] <durandal_1707> with sinc sample i have i only see different spectrum comparing to faad2/fdk output
[19:26:25 CEST] <durandal_1707> eg its have some artefacts but not spikes
[19:26:42 CEST] <atomnuker> you do use the 960 transform, right?
[19:26:48 CEST] <atomnuker> what's the scaling factor you have?
[19:26:51 CEST] <durandal_1707> yes
[19:26:53 CEST] <atomnuker> (mine is wrong too)
[19:28:02 CEST] <atomnuker> try -1.f/(16*1024*480) for the 960 transform
[19:28:40 CEST] <atomnuker> and -1.f/(16*1024*3840) for the 120 transform
[19:34:22 CEST] <durandal_1707> worse
[19:39:48 CEST] <durandal_1707> if i multiply 960 one with 2 i get perfect result for long part
[19:40:07 CEST] <atomnuker> okay, then its that
[19:40:42 CEST] <atomnuker> according to peloverde the only way to know the correct scale is to trial and error until it sounds correct
[19:41:12 CEST] <atomnuker> (certainly helped for opusenc, 68 << transform size is weird but works exactly)
[19:42:56 CEST] <durandal_1707> atomnuker: you forgot to increase buffer pointer for half case
[19:43:11 CEST] <durandal_1707> thats source of artifacts
[19:44:16 CEST] <atomnuker> huh
[19:44:21 CEST] <atomnuker> so it sounds right now?
[19:47:50 CEST] <durandal_1707> i get frequencies which shouldnt be there
[19:49:31 CEST] <atomnuker> spectrogram?
[19:51:43 CEST] <durandal_1707> https://transfer.sh/15Wwmp/o.png
[19:52:32 CEST] <durandal_1707> left is ffmpeg
[19:55:05 CEST] <atomnuker> hm, do you have the original uncompressed sample somewhere?
[20:01:13 CEST] <durandal_1707> no, i have only what faaad and fdk decompress and its same
[20:03:10 CEST] <atomnuker> are they audiable?
[20:06:16 CEST] <durandal_1707> nope
[20:07:03 CEST] <durandal_1707> do you have better sample?
[20:08:08 CEST] <atomnuker> durandal_1707: https://pars.ee/temp/2013_03_02_16.49.29_LoungeFM.DAB_.mp4
[20:47:07 CEST] <durandal_1707> atomnuker: i get very bad artifacts with that one, something is not right with your code
[20:50:31 CEST] <atomnuker> durandal_1707: maybe its because this is SBR
[20:50:40 CEST] <atomnuker> could you give me your sample?
[20:51:45 CEST] <durandal_1707> if its SBR it should report that somehow
[20:52:07 CEST] <atomnuker> it is SBR
[21:00:11 CEST] <durandal_17> atomnuker: http://streams.videolan.org/Mpeg_Conformance/ftp.iis.fhg.de/mpeg4audio-conformance/compressedMp4/
[21:01:32 CEST] <durandal_17> specifically: http://streams.videolan.org/Mpeg_Conformance/ftp.iis.fhg.de/mpeg4audio-conformance/compressedMp4/al00sf_44.mp4
[21:03:48 CEST] <atomnuker> durandal_17: seems like they do a lowpass
[21:04:13 CEST] <atomnuker> and it seems like SBR needs to be adjusted for 960 so it doesn't work
[21:04:27 CEST] <atomnuker> (SBR does stuff in the time domain so it'll be a pain)
[21:15:12 CEST] <durandal_1707> why it reports sbr -1
[21:15:49 CEST] <atomnuker> dunno, broken sample maybe
[21:16:13 CEST] <atomnuker> its cut from a larger one and AFAIK SBR data is not sent on every frame
[21:22:55 CEST] <durandal_1707> atomnuker: it doesnt look so complicated, how other decoders managed it..
[21:40:22 CEST] <durandal_1707> also this sbr is very generic
[21:50:24 CEST] <durandal_1707> atomnuker: for example if i decode 960 as 1024 i get no artifacts at all
[21:54:38 CEST] <atomnuker> yes, but everything is slowed down
[22:02:55 CEST] <cone-835> ffmpeg 03Martin Storsjö 07master:d086e40459ab: lavf: Remove codec_tag from dashenc and smoothstreamingenc
[22:02:56 CEST] <cone-835> ffmpeg 03John Stebbins 07master:95f3c85976ff: movenc: use correct tag list for AVOutputFormat.codec_tag
[22:03:01 CEST] <durandal_1707> atomnuker: and disabling sbr have minimal effect
[22:04:58 CEST] <atomnuker> huh, so maybe its the window then
[22:05:14 CEST] <atomnuker> yep, it probably is, I don't do LONG_START and LONG_END
[22:21:42 CEST] <durandal_1707> i think it does
[22:22:09 CEST] <atomnuker> no, it doesn't, the shape of the window is different
[22:22:16 CEST] <atomnuker> and the decoder only has tables
[22:22:30 CEST] <atomnuker> so there's nothing to handle 960 sample windows
[22:22:40 CEST] <atomnuker> hence you get artifacts
[22:23:53 CEST] <durandal_1707> so whats missing?
[22:26:26 CEST] <atomnuker> nevermind, the function does something clever so it doesn't have to have tables to do transitions
[22:27:30 CEST] <atomnuker> so dunno what's missing, but on my sample it sounds like the window has an issue
[22:27:48 CEST] <atomnuker> maybe its using some other feature like tns
[22:50:24 CEST] <dcherednik> atomnuker: Hi! About dcaenc and fft function. I had a chat with author of original dcaenc codec. He told that indeed, function named fft is not fft function )
[22:53:26 CEST] <atomnuker> dcherednik: yep, certainly looks like a forward mdct (2x in, 1x out)
[22:53:34 CEST] <dcherednik> Yep
[22:58:56 CEST] <atomnuker> apparently he wrote it fixed point because of arm almost 10 year ago
[22:59:00 CEST] <atomnuker> little did he know...
[23:01:24 CEST] <dcherednik> atomnuker: Moreover, situation with psychoacoustic model also is not good
[23:02:53 CEST] <dcherednik> atomnuker: so, I am thinking about porting musepack psychoacoustic... It also should be suitable for mp2 encoder...
[23:05:42 CEST] <dcherednik> Or this is overkill?
[23:09:44 CEST] <atomnuker> dcherednik: musepack?
[23:14:27 CEST] <dcherednik> https://www.musepack.net/ Probably this is one of the best subband encoders
[23:14:46 CEST] <atomnuker> no, we don't need a fourth psychoacoustic system in ffmpeg
[23:14:54 CEST] <atomnuker> use the AAC encoder one
[23:15:02 CEST] <atomnuker> just use it to get the energy per band
[23:15:11 CEST] <atomnuker> and the thresholds, it'll be all you need
[23:15:24 CEST] <atomnuker> you'll have to convert the encoder to use floats though
[23:16:13 CEST] <dcherednik> Ok.
[23:20:44 CEST] <dcherednik> If I use AAC psychoacoustic can I consider filterbank aliasing?
[23:21:22 CEST] <dcherednik> Ou. It looks I can
[23:22:30 CEST] <atomnuker> you can also just use the functions that the aac psychoacoustic system calls directly, it uses a bunch of QMFs internally IIRC
[23:23:10 CEST] <atomnuker> (if you don't care about masking effects which can be pretty important in these codecs)
[23:38:18 CEST] <atomnuker> basing a codec on mpeg2 audio, this was begging to see no usage anywhere
[23:42:33 CEST] <dcherednik> Why?
[23:43:26 CEST] <atomnuker> lets say you'd like to support that codec in some hardware or sell software to encode or decode that format
[23:44:16 CEST] <atomnuker> you have to pay patent fees to whatever patents may be in it
[23:45:04 CEST] <atomnuker> unless you'd like to only sell your device to china or whatever other country which won't confiscate it
[23:45:42 CEST] <atomnuker> and thats if you manage to get the patent holders to sell you the rights to sell your stuff
[23:46:26 CEST] <atomnuker> they won't be happy to hear someone has modified it and if they even suspect that they might just say no
[23:46:48 CEST] <atomnuker> this is the hell software patents are
[23:47:33 CEST] <atomnuker> (some even require that you use their encoder binary or they'll say no, like dolby)
[23:50:13 CEST] <atomnuker> so to avoid this shit reject software patents, give your stuff out for free with source code in a nice license and make sure your research is public
[23:52:45 CEST] <atomnuker> also opus demonstrated that avoiding patents leads to discovering new ways of being more efficient
[23:54:34 CEST] <atomnuker> it also doesn't help that everything related to audio or video encoding IS FUCKING MATHEMATICS, but no, to the free companies participating in the open market of the us its not mathematics if its done on a computer
[23:57:43 CEST] <dcherednik> I see
[23:58:16 CEST] <J_Darnley> Putting math together in the right order is an innovative invention and needs protection.
[23:59:25 CEST] <durandal_1707> with patents?
[23:59:32 CEST] <atomnuker> too bad mostly everyone who wrote it hundreds of years ago is dead and spinning in their graves!
[00:00:00 CEST] --- Wed Jul  5 2017