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

[burek]

[00:28:59 CEST] <atomnuker> jkqxz: what should the device_init function do?
[00:29:20 CEST] <atomnuker> also when does it get called? after device create?
[00:52:57 CEST] <jkqxz> It's called after device_create for internal devices, and it's the first thing for external devices.
[02:30:10 CEST] <atomnuker> jkqxz: also how would vaapi->vulkan->vaapi mapping work? when I try to map back to vaapi I get an error saying the vadisplay is invalid
[03:52:11 CEST] <atomnuker> jamrial: could you resubmit the flac picture embedding patch again before we release? I'd like for that to make it in if possible
[03:53:19 CEST] <jamrial> atomnuker: the avpacketlist patch hasn't been reviewed/committed yet
[03:53:28 CEST] <jamrial> but yes, i plan to in any case
[04:32:57 CEST] <cone-523> ffmpeg 03James Almer 07master:4d89b5f844b3: avcodec/clearvideo: add missing wrappers to clearvideodata.h
[04:32:57 CEST] <cone-523> ffmpeg 03James Almer 07master:9df784db6ef3: avcodec/sheervideo: add missing wrappers to sheervideodata.h
[05:05:48 CEST] <cone-523> ffmpeg 03Jun Zhao 07master:51e3010575ca: lavf/hls: Remove the dead code in  parse_playlist()
[05:57:31 CEST] <cone-523> ffmpeg 03James Almer 07master:3a4d74c1fff8: avformat/utils: make AVPacketList helper functions shared
[05:57:32 CEST] <cone-523> ffmpeg 03James Almer 07master:58ce4fdeaebc: avformat/utils: optimize ff_packet_list_free()
[05:57:33 CEST] <cone-523> ffmpeg 03James Almer 07master:78b96be7580e: avformat/matroskadec: use AVPacketList to queue packets
[05:57:34 CEST] <cone-523> ffmpeg 03James Almer 07master:15ca8311e68d: avformat/ttaenc: use AVPacketList helper functions to queue packets
[05:57:35 CEST] <cone-523> ffmpeg 03James Almer 07master:d95f15b14d5c: avformat/mp3enc: use AVPacketList helper functions to queue packets
[05:57:36 CEST] <cone-523> ffmpeg 03James Almer 07master:fefe47b70101: avcodec/clearvideo: fix mixed code and declarations
[05:57:37 CEST] <cone-523> ffmpeg 03James Almer 07master:a866cc3ad3fb: avcodec/mpeg4videodec: free studio profile VLCs when closing the decoder
[05:59:53 CEST] <jamrial> kierank: ^
[06:31:18 CEST] <jamrial> atomnuker: done
[06:35:18 CEST] <TD-Linux> jamrial, fyi if you build libaom with CONFIG_LOWBITDEPTH it should (eventually) actually output I420 8-bit frames for 8-bit video
[06:35:47 CEST] <jamrial> TD-Linux: ah, nice
[06:35:54 CEST] <jamrial> it should work with the wrapper as is, in any case
[06:36:59 CEST] <jamrial> assuming the bit_depth field in aom_image_t is still populated with a value of 8
[06:42:09 CEST] <TD-Linux> should be.
[06:42:55 CEST] <jamrial> cool
[06:57:29 CEST] <rcombs> >_t
[06:57:31 CEST] <rcombs> who did this
[07:14:34 CEST] <cone-523> ffmpeg 03James Almer 07master:2accdd3871a1: avcodec/libaomdec: fix broken pix_fmt changes from the previous commit
[07:18:28 CEST] <jamrial> wm4: there are "Buffer returned by get_buffer2() did not zero unused plane pointers" errors on gray/yuv400p files ever since d6fc031caf
[08:31:14 CEST] <thardin> so how about that av1
[09:51:51 CEST] <durandal_1707> atomnuker: i do not know how to do dct4 with 320 coefficients (input size)
[10:06:19 CEST] <spaam> i saw that cert for lists.mplayerhq.hu have some ffmpeg domains in it.. maybe the one who is in charge of the server should fix the cert for lists.mplayerhq.hu :)
[13:11:47 CEST] <durandal11707> atomnuker: i used fftw3 and its dct IV is borked or something
[13:12:24 CEST] <durandal11707> it is slower than dct4 from libsiren and gives not correct output
[13:13:04 CEST] <durandal11707> maybe i'm wrong, in that case dct4 have misleading name
[15:56:31 CEST] <cone-745> ffmpeg 03James Almer 07master:2f0e0deadc4e: avformat/matroskadec: address a missing AVPacket free
[15:57:09 CEST] <jamrial> kierank: ping
[15:57:17 CEST] <kierank> jamrial: pong
[15:57:19 CEST] <kierank> thanks for patch
[15:57:36 CEST] <jamrial> about that, the fix doesn't seem to be correct/enough
[15:57:38 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-threads-auto&time=20180404073400
[15:57:47 CEST] <jamrial> complains about double frees or something like that
[15:58:29 CEST] <jamrial> i guess i'm freeing them the wrong way?
[15:58:59 CEST] <jamrial> maybe they should be static like the others, and initialized in ff_mpeg4videodec_static_init()
[15:59:37 CEST] <kierank> static initaliasers suck
[15:59:55 CEST] <jamrial> do you have any idea what could be wrong then?
[16:00:23 CEST] <kierank> ff_free_vlc
[16:00:29 CEST] <jamrial> because every mpeg4 test is failing in multhreading scenarios
[16:00:39 CEST] <kierank> hmm using that
[16:00:48 CEST] <kierank> is it leaking or crashing?
[16:00:50 CEST] <kierank> oh
[16:00:52 CEST] <kierank> you linked
[16:01:20 CEST] <jamrial> "double free or corruption (!prev)" SIGABRT
[16:01:35 CEST] <kierank> is there a way to get a backtrace
[16:01:57 CEST] <jamrial> run any of those tests using more than one thread and under valgrind i guess
[16:02:53 CEST] <kierank> jamrial: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/cfhd.c#L836
[16:02:55 CEST] <kierank> might need to do that
[16:03:10 CEST] <jamrial> let me test
[16:05:52 CEST] <jamrial> kierank: yeah, that did it
[16:06:13 CEST] <kierank> jamrial: sorry about that, thanks for help
[16:09:46 CEST] <cone-745> ffmpeg 03James Almer 07master:2f273701119f: avcodec/mpeg4videodec: unbreak multithreading decoding
[16:14:35 CEST] <durandal_1707> Compn: see ml!
[16:27:40 CEST] <jkqxz> durandal_1707:  Which Siren codec(s) is that?  (Aren't Siren 7 (G.722.1), Siren 14 (G.722.1C) and Siren 22 (G.somethingelse) all different?)
[16:54:27 CEST] <durandal_1707> jkqxz: this is siren as found in vivo 2. and 3. files
[16:55:42 CEST] <atomnuker> what makes vivo format files?
[16:57:45 CEST] <durandal_1707> atomnuker: ask Compn 
[17:03:58 CEST] <durandal_1707> i think this siren codec can easily be extended to siren7 and siren14
[17:04:06 CEST] <durandal_1707> if samples are found
[17:21:39 CEST] <durandal_1707> jamrial: checksum bits are used for other codec variant
[17:27:11 CEST] <atomnuker> durandal_1707: he asked you to use lavu's crc
[17:28:15 CEST] <durandal_1707> i cant
[17:28:34 CEST] <wm4> <jamrial> wm4: there are "Buffer returned by get_buffer2() did not zero unused plane pointers" errors on gray/yuv400p files ever since d6fc031caf <- ah, lol
[17:32:29 CEST] <atomnuker> durandal_1707: why not?
[17:35:05 CEST] <atomnuker> it looks like a very typical CRC-16
[17:36:56 CEST] <atomnuker> just replace sum ^= (s->input_frame[idx] & 0xFFFF) << (idx % 15); with an av_crc() call and keep the rest
[17:37:27 CEST] <atomnuker> you'll need to repack the input_frame into a byte buffer rather than extending it to an int
[17:45:44 CEST] <durandal_1707> atomnuker: what you mean by this last one sentence?
[17:46:19 CEST] <atomnuker> well s->input_frame is an int
[17:46:34 CEST] <atomnuker> oh, wait, you memcpy the packet data there
[17:46:42 CEST] <wm4> jamrial: which fate tests have that?
[17:47:31 CEST] <jamrial> wm4: it's not making it fail any tests afaics. i noticed it while decoding a gray pic
[17:48:14 CEST] <atomnuker> durandal_1707: so you index the buffer as ints (32 bits) but you take the first 16 bytes? that doesn't sound right
[17:48:20 CEST] <jamrial> just do ffmpeg -i INPUT -pix_fmt gray out.png && ./ffmpeg -i out.png -f null - and you'll see it
[17:48:34 CEST] <atomnuker> a crc shouldn't skip over
[17:48:47 CEST] <jamrial> it's in validate_avframe_allocation(), decode.c
[17:50:42 CEST] <wm4> jamrial: just asking which test would do it so I don't have to build command lines
[17:53:55 CEST] <jamrial> wm4: png1/lena-gray8.png in the fate samples suite is a gray image, but no test uses it, and i have no idea if there is another
[17:54:16 CEST] <jamrial> as i said, no test is failing
[17:56:34 CEST] <wm4> thanks
[17:58:18 CEST] <durandal_1707> atomnuker: that crc code is for another variant which actually stores crc in bitstream, and have packet size of 80 bytes instead of 40 bytes
[17:59:17 CEST] <atomnuker> okay, so are there any files with such CRCs?
[17:59:49 CEST] <durandal_1707> maybe one, wav siren in samples.ffmpeg.org
[18:00:02 CEST] <atomnuker> maybe?
[18:01:14 CEST] <durandal_1707> atomnuker: its little modified siren, packets are double in size
[18:02:02 CEST] <atomnuker> oh so its not supported yet by the decoder
[18:02:11 CEST] <durandal_1707> atomnuker: better comment on fft part, we do not have 320 fft, so i do 512 fft and lerp, which is ugly and not perfect
[18:02:28 CEST] <atomnuker> oh damn, right
[18:03:05 CEST] <durandal_1707> actully it is 1024 fft
[18:03:09 CEST] <atomnuker> btw if the decoder doesn't support that file yet you should delete the crc
[18:03:41 CEST] <atomnuker> durandal_1707: so you do 1024 fft to get a 320 dct?
[18:03:54 CEST] <durandal_1707> lol, yes
[18:04:02 CEST] <atomnuker> okay, simple
[18:04:08 CEST] <atomnuker> we have a dct-32
[18:04:32 CEST] <atomnuker> do 10 of them and do twiddles to combine their outputs
[18:05:19 CEST] <nevcairiel> that sounds inefficient
[18:05:35 CEST] <atomnuker> its the way FFTs and DCTs are done
[18:05:49 CEST] <atomnuker> to get a 1024 fft we combine 64 point ffts
[18:06:01 CEST] <atomnuker> and in those 64 point ffts we have 32 point ffts
[18:06:13 CEST] <nevcairiel> because making bigger ffts would break peoples heads?
[18:06:45 CEST] <atomnuker> well, 32 point ffts are the last we have that are specialized
[18:06:57 CEST] <atomnuker> only if you have AVX iirc
[18:07:13 CEST] <atomnuker> if you don't, the code recurses down to the last specialized implementation we have
[18:07:59 CEST] <atomnuker> if you don't have any optimizations it goes down to 2 point FFTs
[18:11:31 CEST] <BBB> atomnuker: hey wait, youre not allowed to work on audio, you should work on video
[18:11:38 CEST] <BBB> atomnuker: whats going on here!!!11one
[18:12:17 CEST] <nevcairiel> (even more so, totally irrelevant audio)
[18:13:01 CEST] <jamrial> i mean, he worked on Opus
[18:14:01 CEST] <durandal_1707> atomnuker: twiddles? what that means?
[18:14:07 CEST] <BBB> jamrial: theres a time and a place for everything, and thats called college [tm southpark]
[18:16:45 CEST] <atomnuker> durandal_1707: sorry, I meant butterflies
[18:17:00 CEST] <atomnuker> well twiddles are butterflies
[18:25:26 CEST] <durandal_1707> atomnuker: for every pair of 10? a b c d ... (a, b), (c, d), (e, f).. ?
[18:34:26 CEST] <atomnuker> durandal_1707: erm I think this is a fucked up DCT
[18:34:35 CEST] <atomnuker> or an FFT, whichever
[18:34:55 CEST] <atomnuker> since 320 can be done as 10 32-ffts
[18:35:25 CEST] <atomnuker> and if you have a non-ptwo combination of FFTs you can't really do a simple twiddles to combine them
[18:36:17 CEST] <atomnuker> you can however do what the opus mdct does and decompose 320 into 64 5-point FFTs
[18:36:43 CEST] <nevcairiel> yeah i was going to say, opus or aac 960  also use odd sizes, learn from that
[18:37:07 CEST] <atomnuker> so reindex, 5-point FFTs combined by 64-point FFTs, postreindex
[18:39:08 CEST] <atomnuker> bofh_: you there?
[18:41:46 CEST] <atomnuker> I'll try to dig out the original optimized opus fft (which got specialized to an mdct)
[18:48:40 CEST] <durandal_1707> atomnuker: why? does calculating 10 dct32 and doing butterflies does not give correct output?
[18:53:32 CEST] <atomnuker> hmm, maybe not, PFA applies if the FFT can be decomposed into N1xN2 where N1 and N2 are both only divisible by 1, and 10 and 32 aren't relatively prime
[19:02:00 CEST] <atomnuker> durandal_1707: nope, you can't
[19:02:14 CEST] <atomnuker> suppose you have 10 ffts you want to combine
[19:02:42 CEST] <atomnuker> you combine 0+1, 2+3, 4+5, 6+7, 8+9 which gives you 5 ffts you need to combine
[19:03:20 CEST] <cone-745> ffmpeg 03James Almer 07master:4f55b94663cf: avformat/matroskadec: address some more missing AVPacket frees
[19:03:30 CEST] <atomnuker> you need to use PFA then and decompose it into 64 5-point ffts
[19:03:45 CEST] <atomnuker> give me a few hours and I'll give it a go
[19:06:06 CEST] <atomnuker> opus combines 3 5-point ffts to make a 15-point fft and then combines them, so it should be as easy as changing the reindexing constants and removing the 15-point intermediaries
[19:12:44 CEST] <cone-745> ffmpeg 03Timo Teräs 07master:94d831f3886a: ffmpeg: allow setting attached_pic disposition
[19:12:45 CEST] <cone-745> ffmpeg 03Timo Teräs 07master:53688b62ca96: avformat/movenc: add rtp_hinting_needed() helper function
[19:17:06 CEST] <durandal_1707> atomnuker: i found code that does fft of any order
[19:18:49 CEST] <atomnuker> what, kiss fft? some rubbish O(N^2) or worse one? I'll NAK it
[19:19:50 CEST] <atomnuker> ffmpeg has been known to have the fastest FFTs and MDCTs out there and I won't let some 20 year old codec ruin that reputation
[19:20:40 CEST] <atomnuker> I should really clean up that code and put it in lavu
[19:22:04 CEST] <atomnuker> I really wish someone hadn't botched the job and made the avfft wrapper in lavc
[19:22:17 CEST] <durandal_1707> atomnuker: https://github.com/rafat/hsfft
[19:23:00 CEST] <atomnuker> wow, this one's worse than kissfft
[19:23:17 CEST] <durandal_1707> you had not even tried it
[19:23:46 CEST] <atomnuker> I took a glance at it and saw it doesn't even bother to combine FFTs where it can
[19:23:53 CEST] <atomnuker> look at hsfft.c
[19:24:07 CEST] <atomnuker> its 2000 lines
[19:32:07 CEST] <daddesio> I'm finally writing that EA MicroTalk decoder for FFmpeg, and the only problem is that the first MicroTalk frame of the first SCDl chunk contains a special 15-bit header, which applies to the rest of the file. So technically, MicroTalk doesn't support seeking, but in practice, this header is the same across all game files across all games.
[19:32:38 CEST] <daddesio> And it looks like our Electronic Arts SCXl demuxer (electronicarts.c) doesn't support seeking anyway.
[19:33:24 CEST] <daddesio> If it were a 16-bit header, I could just pass those 2 bytes to the microtalk decoder as extradata. But it's 15 bits, and the next bit starts the audio frame.
[19:34:56 CEST] <atomnuker> so? get the 15 bits and just just say the last bit is junk
[19:35:10 CEST] <atomnuker> or you can 0 it out, its just an AND after all
[19:35:11 CEST] <daddesio> So we want the MicroTalk decoder to also not support seeking then?
[19:35:58 CEST] <atomnuker> you can implement seeking if you want to, its not the first format we support to have a single header somewhere
[19:36:09 CEST] <nevcairiel> what atomnuker is saying, you can still pass 2 bytes as extradata and just ignore that 16th
[19:39:13 CEST] <daddesio> and tell microtalk to also skip 15 bits
[19:39:23 CEST] <daddesio> before decoding its audio frame
[19:43:57 CEST] <nevcairiel> even better if you dont need to tell the decoder that but it can recognize that the frame has the header and skip it on its own
[19:45:08 CEST] <durandal_1707> atomnuker: i used this hsfft code and it still gave me even worse output than my naive approach...
[20:06:35 CEST] <BBB> atomnuker: what do I need to do to get you to work on av1 again?
[20:08:30 CEST] <bofh_> atomnuker: any reason why this can't be done as 5x64?
[20:08:53 CEST] <bofh_> OHH this is Siren7?
[20:11:26 CEST] <bofh_> atomnuker: Yeah that uses a 320-point lapped DCT, tho it's been so long that I don't recall if they do a DCT-IV like sane people, or if they use a DCT-III instead. It should easily work with an adaptation of the PFA code used for Opus + some twiddles
[20:12:33 CEST] <bofh_> atomnuker: the reindexing is modular inverses, you need to compute 5^-1 mod 64 and 64^-1 mod 5 via extended Euclidean algo and then the rest is exactly as you described
[20:16:29 CEST] <durandal_1707> BBB: people claim av1 is complete and finished, even had news on their web page
[20:17:01 CEST] <BBB> the internet says so, therefore it must be true
[20:19:59 CEST] <atomnuker> durandal_1707: wait, so its an mdct? I thought you said dct
[20:20:24 CEST] <atomnuker> if its mdct then it'll be much simpler to replace
[20:20:42 CEST] <atomnuker> bofh_: yeah, I was wondering how you calculated the inv_1 and inv_2 constants
[20:20:54 CEST] <atomnuker> how is 15^-1 == 0xeeeee....f?
[20:21:06 CEST] <bofh_> er, 640-point lapped DCT, 320-point FFT. iirc the codec is ~identical to G722.1
[20:21:28 CEST] <jamrial> jkqxz, nevcairiel: https://aomedia.googlesource.com/aom/+/8acdbfc1faa5707824891a9c231e83f08aedfdcd
[20:21:33 CEST] <atomnuker> well yeah, 320 complex
[20:23:32 CEST] <BBB> totally not a normative change
[20:23:38 CEST] <BBB> av1 is totally frozen
[20:23:39 CEST] <nevcairiel> jamrial: wtf is annexbprime now
[20:23:48 CEST] <jamrial> i have no idea
[20:23:59 CEST] <TD-Linux> annex b prime is a modified annex b that has frame lengths as well
[20:23:59 CEST] <nevcairiel> apparently annexb in isom is not going away
[20:24:06 CEST] <TD-Linux> nested lengths btw
[20:24:06 CEST] <jamrial> BBB: you joke, yet there have been at least 4 or those a day for the past couple days :p
[20:24:24 CEST] <nevcairiel> because rtp fuckers had to save a byte here or there
[20:24:24 CEST] <TD-Linux> nevcairiel, what gave you that impression?
[20:24:25 CEST] <BBB> I know, I know
[20:24:29 CEST] <BBB> I want to show people my encoder
[20:24:33 CEST] <BBB> and I Can't
[20:24:45 CEST] <BBB> because as soon as I send it to them, it doesnt work anymore with git/master of libaom
[20:24:49 CEST] <BBB> argh
[20:24:53 CEST] <jamrial> yeah, as i said, i'm not encoding anything until this is fully frozen
[20:24:55 CEST] <TD-Linux> annex b prime is a bigger reason to not have it in isombff
[20:25:01 CEST] <bofh_> atomnuker: https://pastebin.com/sE1eaAjz
[20:25:37 CEST] <nevcairiel> TD-Linux: the response in the ticket didnt seem very hopeful
[20:25:44 CEST] <bofh_> (basically they simplify to what's in the code due to mathematical structure in Z_{15} x Z_{2^k})
[20:26:38 CEST] <durandal_1707> atomnuker: i pointed you to dct4 source code, it is dct I, and fftw3 managed to give similar output as that code, after doing 4N fft
[20:27:59 CEST] <wm4> nice committee codec
[20:28:41 CEST] <atomnuker> durandal_1707: welp, if it doesn't comply with what the spec says it should it's still incorrect
[20:29:38 CEST] <durandal_1707> wm4: ?
[20:36:57 CEST] <bofh_> http://csclub.uwaterloo.ca/~pbarfuss/G722-1E-200505+Cor1.pdf if we're talking about the same codec then the MLT *should* be a DCT-IV (page 12)
[20:39:08 CEST] <TD-Linux> nevcairiel, I've sent an email and will see who the people I need to convince are
[20:40:32 CEST] <BtbN> "stride" in "off += stride" looks like a copy-paste error. <- What?
[21:17:20 CEST] <atomnuker> bofh_: can the same code you wrote be used for any N x N^2 fft?
[21:18:02 CEST] <atomnuker> or only for pfa (so both numbers must be coprime wrt each other)
[21:51:32 CEST] <bofh_> atomnuker: the same code I wrote works for any N x 2^K fft, since either N has no factors of two or it does and you split them off :P (more generally with some modification it will do N x M, gcd(M,N) = 1, but it's somewhat heavily optimized for doing the 2^K bit fast)
[21:52:51 CEST] <bofh_> (so yea, in theory you could do PFA on the 15pt FFT to decompose it into 3pt FFTs & 5pt FFTs, in practise for very small orders like that it makes sense to just hand-code the Cooley-Tukey impl)
[21:56:26 CEST] <durandal_1707> what about using already written dct code?
[21:56:57 CEST] <nevcairiel> TD-Linux: all the politics instead of technical merit? :D
[22:12:07 CEST] <atomnuker> bofh_: hmm, so if N=1 and K=1 would the pre/post reindex essentially be N[i + 1] = N[i] + 1?
[22:12:17 CEST] <atomnuker> e.g. 0, 1, 2, 3...
[22:16:21 CEST] <atomnuker> I think I'll move the FFT from lavc to lavu and change it such that it could handle any even length
[22:17:41 CEST] <atomnuker> wouldn't lose on any performance either, the init function would take a length in samples, not bits and set the function pointers to either the PFA method or the regular power of two if the length is a power of two
[22:21:20 CEST] <TD-Linux> nevcairiel, of course
[22:36:01 CEST] <bofh_> atomnuker: I believe so, yes.
[22:36:29 CEST] <bofh_> also tbh I think moving the FFT code to lavu has been years overdue
[22:42:41 CEST] <atomnuker> welp, what sucks is that av_fft_init is taken as a function name, its already public API and its in lavc, so I can't really use the same name
[22:43:31 CEST] <nevcairiel> technically there is ways to solve that
[22:43:37 CEST] <nevcairiel> but its super annoying
[22:43:57 CEST] <atomnuker> I could call it av_init_fft, av_calc_fft and so on
[22:44:12 CEST] <nevcairiel> thats super inconsistent with anything else
[22:44:50 CEST] <atomnuker> how could the conflicts be solved? keep in mind the names will be different but the arguments and return values will differ
[22:45:14 CEST] <nevcairiel> that you cant solve, a plain move you could possibly do
[22:45:27 CEST] <atomnuker> yeah, I figured
[22:50:35 CEST] <atomnuker> I'll call it av_dft, will deprecate av_fft and after 2 years I'll deprecate av_dft and bring back av_fft
[22:51:25 CEST] <atomnuker> well, after the next bump, I don't know why I still think there's a bump every 2 years strictly
[23:01:31 CEST] <jamrial> atomnuker: bumps can happen any time, but deprecated stuff nonetheless needs ~2 years before it can be removed
[23:03:17 CEST] <jamrial> you could bump five times in two years. what matters is the amount of time, not the number in the library
[23:03:23 CEST] <jamrial> since the point is to give downstream projects time to migrate
[23:13:44 CEST] <daddesio> Is it ok to do MicrotalkExtra *extra = (MicroTalkExtra*)avctx->extradata in my decoder? Then the EA demuxer can fill in various fields in the struct (revision, platform, etc.) which aren't all in one place in the EA container.
[23:14:33 CEST] <nevcairiel> structs are a bit iffy
[23:15:45 CEST] <daddesio> Right, that's the pattern I've been seeing. Most decoders, like cook.c/wmavoice.c, set up a bitreader/bytereader on extradata, since the extra data is supposed to be a standard format, not a personal struct.
[23:18:19 CEST] <daddesio> But that's the sad nature of this codec. A couple of parameters change, depending on the revision of the overall EA SCxl file.
[23:19:37 CEST] <BBB> I think the binary format of extradata is because typically the data comes from a container field which in itslf is binary, like a moov atom or a avi chunk
[23:19:39 CEST] <daddesio> just like there's EA ADPCM R1/R2/R3, there's also MicroTalk R1/R3. R3 is the same as R1 except there's an extra field (0xee) in the audio frame.
[23:20:10 CEST] <BBB> if the format of extradata is not binary (i.e. its an aggregate of fields not tied to a particular container structure), then its difficult to say how it should be done
[23:20:21 CEST] <BBB> maybe we havent seen that yet is the best way to describe it
[23:20:27 CEST] <BBB> (even if thats not very helpful)
[23:21:31 CEST] <daddesio> I can create two separate codecs (microtalk_r1 and microtalk_r3) but it's a bit wasteful
[23:22:22 CEST] <daddesio> The demuxer can't just strip out that extra 0xee field from the audio frame, because there are in fact multiple MicroTalk frames per SCDl packet, which are not length-delimited.
[23:22:33 CEST] <daddesio> hence, multiple 0xee fields
[23:23:21 CEST] <BBB> right, thats pretty typical fo audio codecs to contain multiple frames per packet
[23:23:31 CEST] <BBB> esp. for simple codecs like adpcm or speech codecs etc.
[23:23:48 CEST] <BBB> how many fields do you need to convey?
[23:24:18 CEST] <BBB> what we sometimes do is make it separate codecs and use the same code, just a different init sequence
[23:24:23 CEST] <BBB> that would not be wasteful at all
[23:24:36 CEST] <BBB> and then the 0xee filtering can be done based on codec id in the otherwise shared init function in the decoder
[23:24:39 CEST] <BBB> is that reasonable?
[23:24:58 CEST] <BBB> its not like speed is an issue for these kind of codecs so a branch is ok
[23:25:03 CEST] <daddesio> There are 1-4 microtalk frames per SCDl packet. I wanted to pass all 4 of them with a single call to mt_decode_frame(), since the total duration of all 4 is known (specified in the SCDl header).
[23:25:37 CEST] <daddesio> Right, having 2 codecs wouldn't be wasteful in cpu cycles, just wasteful in the codec namespace maybe.
[23:25:52 CEST] <BBB> yeah, thats not too bad IMO
[23:25:57 CEST] <BBB> we do that in a lot of places already
[23:26:09 CEST] <BBB> listing codecs gets kind of messy, admittedly, but I dont think anyone cares about that
[23:29:15 CEST] <daddesio> There's another tricky issue though: there's that one-time, 15-bit header that appears in the first microtalk frame of the first SCDl packet. But generally, the header is always 0xf138 (big-endian) for MicroTalk 10:1 and 0xf038 for MicroTalk 5:1.
[23:30:22 CEST] <daddesio> If we want to support seeking, without having access to the first SCDl packet in the file, we can just guess the header depending on MicroTalk 10:1/5:1 (codec id 0x4 and 0x16, respectively).
[23:31:00 CEST] <daddesio> OTOH, electronicarts.c doesn't currently support seeking, anyway. (I think might be useful to add, though.)
[23:31:22 CEST] <BBB> global headers like that should go in avctx->extradata :)
[23:31:45 CEST] <BBB> (at least thats how we do things like sps/pps in annexb h264/hevc, which is essentially the same thing)
[23:32:24 CEST] <BBB> that way, seeking is easily done by accessing the header in avctx->extradata from whatever frame you started from
[23:35:25 CEST] <daddesio> Do we want to create separate MicroTalk 10:1 and MicroTalk 5:1 codecs to help with guessing the header in case we don't have access to the first SCDl packet (e.g. realtime streaming from an HTTP server)? probably not...
[23:36:16 CEST] <daddesio> that would total to 2*2= 4 codecs (revision 1/3, and 10:1 vs. 5:1)
[23:37:19 CEST] <daddesio> See, in sx.exe, MicroTalk 10:1 (codec id 0x4) and 5:1 (codec id 0x16) are technically two different codecs -- but they can both be decoded by the same decoder. The encoder just picks different parameters in that 15-bit header when you ask for 10:1 vs. 5:1.
[23:38:11 CEST] <daddesio> and the encoder always chooses the same parameters every time (0xf138 for 10:1, 0xf038 for 5:1), across all games.
[23:38:20 CEST] <BBB> I dont think I can give a reasonable answer to that question, I dont know how common such use cases are and if the header is repeated over the wire or not
[23:38:55 CEST] <BBB> sicne you clearly studied it, youre probably in the best position to give an answer to that question that is a good compromise for common use cases without being overly complex
[23:38:59 CEST] <BBB> again, sorry, not helpful :-p
[23:39:25 CEST] <daddesio> SCXL-over-HTTP isn't even a thing. I just asked because I know FFmpeg is supposed to be good for streaming.
[23:39:32 CEST] <BBB> ah
[23:39:34 CEST] <BBB> ok
[23:39:46 CEST] <BBB> well it sounds like the rtp layer would have to resolve repeatedly sending the header over the wire
[23:39:53 CEST] <BBB> kind of like sps/pps repeats in rtp h264
[23:39:57 CEST] <BBB> or keyframe intervals
[23:40:26 CEST] <BBB> so maybe not worth worrying about right now, I understand why youre asking but it doesnt appear to be a seriously common use case so its a little bit of a stretch trying to solve it
[23:41:01 CEST] <daddesio> ok
[23:41:43 CEST] <daddesio> so it sounds like a clean solution then is to just create 2 codecs for now (microtalk microtalk_r3), and pass the first SCDl frame as extradata,
[23:42:45 CEST] <BBB> yes
[23:42:47 CEST] <daddesio> All I need is a way to inform the decoder if it's currently decoding the first SCDl packet. If it is, then it needs to skip forwards over the 15-bit header before decoding.
[23:43:42 CEST] <daddesio> actually, there's a 0x00/0x01 field at the beginning of the SCDl packet which I think might indicate the first SCDl packet. (need to confirm)
[00:00:00 CEST] --- Thu Apr  5 2018