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

[burek]

[01:45:57 CET] <gnafu> atomnuker: I've seen that on YouTube before, too, though lately I think I've had Opus any time I've checked.
[01:46:11 CET] <gnafu> (VP9+AAC)
[01:52:56 CET] <atomnuker> I don't recally seeing any vp9 links without opus, maybe the player picked that combination for some reason
[01:53:18 CET] <jamrial> vp9+aac sounds unusual, though, since a broswer that supports vp9 should also support opus
[01:53:29 CET] <jamrial> except maybe safari
[08:18:34 CET] <nevcairiel> its not like thats actually a muxed combination, thats all dash and the browser c an pick
[08:48:39 CET] <kierank> atomnuker: have you been on a tour of SLAC?
[09:50:08 CET] <atomnuker> slac?
[10:39:23 CET] <durandal_1707> fixed one bug in bitstream parsing, more still left
[11:59:47 CET] <BtbN> philipl, I'll catch up next week, not really any time at the moment.
[12:29:41 CET] <atomnuker> oh, that slac? I think the train might stop through there
[12:30:17 CET] <atomnuker> but even if it did, you're still in the middle of nowhere, without a car, without any taxis nearby, and mobile internet is still 5 pounds per megabyte
[12:33:03 CET] <atomnuker> and I wouldn't have been fond of the prospect of walking >5km in both directions in the relative heat, I did 7km once there, I'd know
[12:37:33 CET] <durandal_1707> atomnuker: i found logic error in my code, problem is how to get right *i* index in max_quant_idx[g][i] ?
[12:41:44 CET] <kierank> atomnuker: not on three
[12:41:56 CET] <kierank> I'd like to go one day
[13:46:07 CET] <nevcairiel> durandal_1707: i got a bunch of TS satellite recordings with ac-4
[13:48:07 CET] <nevcairiel> now i just need to reach mpegts.c to understand those
[13:48:11 CET] <nevcairiel> teach*
[13:53:29 CET] <durandal_1707> nevcairiel: that software already have ts dshow file
[13:55:10 CET] <nevcairiel> but its more fun if i can actually read it myself
[14:21:02 CET] <nevcairiel> i do wonder how you are supposed to identify that its ac-4 however, it uses stream type 6 (private stream) and i dont see a registration decriptor
[14:21:16 CET] <kierank> they haven't registered an identifier which is odd
[14:21:48 CET] <durandal_1707> it is in some spec
[14:22:37 CET] <nevcairiel> apparently there is a AC-4 descriptor that you are supposed to use
[14:22:50 CET] <nevcairiel> as part of the PMT
[14:23:37 CET] <kierank> still out of spec iirc
[14:23:56 CET] <nevcairiel> i'm reading the DVB spec, so they just made it spec
[14:24:12 CET] <kierank> I mean out of spec for mpegts (h.222)
[14:24:20 CET] <kierank> iirc private stream requires a registration
[14:44:48 CET] <nevcairiel> at least the ac4-descriptor is present where the spec says it should be
[14:45:14 CET] <nevcairiel> but that binary decoder there still refuses to work
[14:45:21 CET] <nevcairiel> so it may as wlel do a license check or s omething
[14:46:17 CET] <durandal_1707> nevcairiel: can you share files?
[14:46:47 CET] <nevcairiel> uploading them to my share server now
[14:48:11 CET] <nevcairiel> durandal_1707: https://files.1f0.de/samples/ac4/
[14:48:41 CET] <nevcairiel> also put my hacky patch to make mpegts.c find them there
[14:50:46 CET] <durandal_1707> atomnuker: in the end i made huge offset2sfb table, i do not like it
[14:50:53 CET] <durandal_1707> nevcairiel: great, thanks!
[14:52:38 CET] <JEEB> hmm, wonder why we don't pass on maxrate/bufsize side data by default through encoders?
[14:52:46 CET] <JEEB> (for video/audio)
[14:53:41 CET] <JEEB> nevcairiel: there's two things specified, I linked both specs here earlier
[14:53:50 CET] <JEEB> one of them is the DVB descriptor
[14:54:03 CET] <nevcairiel> i found the dvb descriptor
[14:54:05 CET] <JEEB> the other is the registered thing where they literally registered id 'AC-4'
[14:54:13 CET] <nevcairiel> these  samples dont use that
[14:54:32 CET] <nevcairiel> but they are all DVB sat broadcast
[14:54:36 CET] <nevcairiel> other regions/standards may
[14:54:47 CET] <JEEB> yea, I'd guess the descriptor is more used although the other thing is supposed to be a fallback
[14:55:01 CET] <JEEB> "for devices that don't support the ac-4 descriptor"
[14:55:08 CET] <nevcairiel> according to the DVB spec, this is the only thing they list in there
[14:55:22 CET] <JEEB> yea, it's all in the back-log
[14:55:26 CET] <JEEB> both docs
[14:55:30 CET] <JEEB> the DVB one and the other one
[14:56:17 CET] <nevcairiel> also no clue where the 0xAC comes from that TsExtractor in exoplayer uses
[14:56:22 CET] <nevcairiel> probably yet another standard
[15:01:58 CET] <nevcairiel> anyhow these recordings have nothing else, a language descriptor, the dvb extension descriptor which contains the ac-4 descriptor, and sometimes a second dvb extension descriptor, which i didnt bother to find out whats in it :)
[15:29:03 CET] <durandal_1707> hmm, some of samples are mono with no presentations but with substreams
[15:29:58 CET] <durandal_1707> all are using speech spectral frontend
[15:31:59 CET] <durandal_1707> actually, i'm wrong need to look at this more
[15:34:49 CET] <durandal_1707> lol, need to skip bytes, packets have signature and crc
[15:36:42 CET] <nevcairiel> from TS, yeah
[15:51:55 CET] <JEEB> yea, it's the sync sample thing
[15:52:10 CET] <JEEB> 22:46 <@JEEB> it's like annex b I guess, except it also has frame_size() in front
[15:52:13 CET] <JEEB> 22:46 <@JEEB> it then includes the raw_ac4_frame (and optionally crc_word)
[15:52:16 CET] <JEEB> 22:46 <@JEEB> (crc_word when 0xAC41)
[16:00:22 CET] <OmniBlade> Hello, is make fate expected to pass when building against the msvc toolset? I keep getting Use of av_clip() where av_clip_uintp2() could be used despite the code I've added not using that function.
[16:00:34 CET] <OmniBlade> And indeed I get the same issue against master.
[16:01:26 CET] <OmniBlade> Its just after tests/checkasm/checkasm.h if that helps.
[16:01:31 CET] <nevcairiel> yes its supposed to pass
[16:01:44 CET] <nevcairiel> make sure you checkout the sources using unix line-endings, or some scripts might be thrown off
[16:01:59 CET] <OmniBlade> Ahh, that might have scuppered me.
[16:02:16 CET] <OmniBlade> I'll change the line endings and try again.
[16:04:08 CET] <OmniBlade> Thanks.
[16:19:34 CET] <philipl> BtbN: no problem
[16:41:51 CET] <JEEB> michaelni: I will check that specific use case when I get home. sounds like another sub2video FATE test is needed.
[17:21:40 CET] <JEEB> michaelni: while i'm on the road, does it happen with the value initialized to zero as well? (that's what the struct implicitly got init to until now)
[18:19:44 CET] <JEEB> nevcairiel: got back home and I had the PDF open - the 'A', 'C', '-', '4' identifier is defined in annex D of https://www.etsi.org/deliver/etsi_ts/103100_103199/10319002/01.02.01_60/ts_10319002v010201p.pdf
[18:20:02 CET] <JEEB> basically an addition to the regd_desc list
[18:20:12 CET] <JEEB> registration_descriptor  AC-4
[18:20:36 CET] <JEEB> but the (preferred) way is the thing described in DVB
[18:20:51 CET] <JEEB> "It is recommended that the last bytes of the descriptor are 0x41 0x43 0x2D 0x34 (AC-4) to provide a fallback signalling option for receivers that do not natively understand the respective descriptor."
[18:21:53 CET] <nevcairiel> what receivers would understand ac-4 and then not implement that descriptor
[18:21:54 CET] <nevcairiel> oh well
[18:22:20 CET] <JEEB> indeed
[19:22:09 CET] <JEEB> michaelni: ok, it works with a zero there (which is not surprising, the struct until this had been implicitly initialized to zero)
[19:37:55 CET] <durandal_1707> help! can't find bug in parsing
[21:08:09 CET] <cone-748> ffmpeg 03Lou Logan 07master:6f93868e464d: MAINTAINERS: remove myself as a docs & trac maintainer
[21:08:33 CET] <durandal_1707> atomnuker: i guess ac-4 will need your IMDCT patch too, as there are transfer lenghts of : 2048, 1920, 1536, 1024, 960, 768, 512, 480, 384, 256, 240, 192, 128 and 96
[21:09:36 CET] <atomnuker> yeah, some are non-base-15 so mdct15 won't cut it
[21:10:15 CET] <atomnuker> can the codec switch between any of them per-frame?
[21:10:48 CET] <atomnuker> also what do the samples you have use? 1024/128*8 for long/transient frames?
[21:11:39 CET] <atomnuker> I can't help but think they've rewritten an aac encoder to output ac4 since the terminology is similar
[21:13:18 CET] <durandal_1707> one sample use 2048 for long frames, and 128, 256, 512, 1024 for transient ones, other sample uses 1536 and less values like 768, 384, 192, and 96
[21:14:47 CET] <durandal_1707> like opus it also may(almost always) resample audio internally
[21:15:00 CET] <atomnuker> nice, that's kinda similar to opus
[21:15:19 CET] <atomnuker> resample the audio? so does it always output at a particular samplerate?
[21:15:28 CET] <durandal_1707> this is mostly to have 1:1 mapping from V to A packets
[21:15:53 CET] <atomnuker> we do support switching samplerates, the only reason opus doesn't is because it can combine silk and celt which may differ in samplerates
[21:16:13 CET] <durandal_1707> atomnuker: samplerate is 48000 (or 44100 and nothing else) with extensions to 96k and 192k
[21:17:16 CET] <durandal_1707> atomnuker: for 2048 frame len base it give 1920 output samples for 48000 sample rate ---> to have 1:1 mapping with Video
[21:17:38 CET] <durandal_1707> 1920 is just approximation, ....
[21:17:59 CET] <atomnuker> wait, what? so the transform is 2048 but it cuts out 128 samples?
[21:18:12 CET] <durandal_1707> atomnuker: resamples internally
[21:18:33 CET] <atomnuker> ah, ok, is that signalled? e.g. output_sample_rate or something?
[21:19:07 CET] <durandal_1707> yes, see resampling_ratios table in my code
[21:19:55 CET] <atomnuker> ok, that's somewhat sane, on one hand we could change the samplerate of the frame and let the user deal with it or we could resample it to whatever the decoder was configured with
[21:20:20 CET] <durandal_1707> it have 25 fps, 29.997 and not 30 fps :)
[21:20:42 CET] <atomnuker> I'm thinking letting the user deal with variable samplerates sounds better, it should just work provided they use the PTS correctly
[21:21:58 CET] <atomnuker> so there must always be 25/29.997 audio frames per second? weird, that kinda fixes encoder possibilities
[21:22:33 CET] <durandal_1707> there are other options for more FPS, 100 even
[21:23:12 CET] <atomnuker> eh, still weird and hard for encoders to comply with, with opus you knew you were always going to end with an integer amount of frames per second
[21:23:55 CET] <atomnuker> because you have to keep track of how many frames/samples you've encoded and not change transform size bases (since they're made to match with framerates)
[21:24:38 CET] <durandal_1707> i'm wrong, they have mode for 30fps and even 24fps
[21:25:48 CET] <durandal_1707> yes you get exactly same  number of audio frames as video frames
[21:26:28 CET] <durandal_1707> internal resampling deals with of by one samples in frames
[21:27:16 CET] <durandal_1707> there is special mode i think which is not limited, but only for 44100 rate
[21:31:25 CET] <kierank> durandal_1707: looking forward to see how you handle 29.97 fps
[21:32:02 CET] <durandal_1707> kierank: it is trivial, pick iframe and start decoding from it
[21:32:11 CET] <kierank> and how many samples do you return
[21:32:26 CET] <kierank> at 48khz
[21:32:29 CET] <atomnuker> this sounds like it simplifies video/audio sync and locks you from using any other codecs if you don't generalize
[21:32:58 CET] <durandal_1707> kierank: the amount that returns internal resampler
[21:33:10 CET] <kierank> how, it's a fractional rate
[21:33:32 CET] <durandal_1707> there is delay
[21:34:28 CET] <kierank> you will drift unless you are careful
[21:41:17 CET] <atomnuker> well, we can output more samples that the frame contains, its not like we have to respect x frames per second
[21:45:34 CET] <durandal_1707> i think there is sequence counter up to 1020 just for this crap
[22:53:33 CET] <gnafu> Did NDI ever get removed, per #7589?
[22:53:58 CET] <gnafu> (It came up in my browser's address bar suggestions, and I was reminded of the drama.)
[22:55:19 CET] <durandal_1707> gnafu: usually nothing happens here
[22:55:33 CET] <gnafu> :-P
[23:35:14 CET] <cone-748> ffmpeg 03Paul B Mahol 07master:c679119a73d9: avfilter/vf_amplify: add tolerance option
[00:00:00 CET] --- Sat Feb 23 2019