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

[burek]

[01:42:59 CEST] <AndrewR> https://github.com/OpenVisualCloud/SVT-AV1/issues/257 created issue for SVT-AV1
[10:49:43 CEST] <kurosu> EwoutH: didn't notice you were in that channel, which is more appropriate for ticket 7914
[10:49:52 CEST] <kurosu> *this channel
[10:50:26 CEST] <EwoutH> No props
[10:53:21 CEST] <EwoutH> I also opened an issue over at SVT-AV1 mentioning the trac ticket
[10:54:03 CEST] <JEEB> the integration patches for SVT-AV1 really seemed to be rather segfaulty last I gathered some anecdotal stats
[10:54:21 CEST] <JEEB> and I think they're still poking around with the SVT-HEVC patch set?
[10:55:25 CEST] <EwoutH> Maybe it's a bit early
[10:55:36 CEST] <EwoutH> When is 4.2 expected to branch?
[11:06:35 CEST] <kurosu> EwoutH: you can still play the role of user reviewer to verify the robustness of their integrations if you have time and will to do so
[11:07:22 CEST] <kurosu> Truth be told, I wouldn't know how to try and break the integrations to do so
[11:53:45 CEST] <kurosu> JEEB: The worst thing in the current ffmpeg "staffing" is Intel could become judge and party to some decisions. Maybe harsh but this means I'm not in favor of cutting them any slack
[12:00:29 CEST] <kierank> "Staffing" lol
[12:05:53 CEST] <kurosu> Sorry, not native speaker, and I didn't think it warranted 3 sentences to get the meaning across, hence the quotes
[12:06:36 CEST] <kurosu> Expert-enough, unbiased yet involved/caring, reviewers etc
[12:07:28 CEST] <kurosu> I'm missing at least one of these criteria
[12:12:38 CEST] <cehoyos> I'm missing reviewers so I am not sure if dismissing allegedly biased ones is the smartest move
[12:13:01 CEST] <cehoyos> (Apart from the question who is unbiased against what)
[19:50:38 CEST] <kierank> durandal_1707: does mp2float really have no delay at all
[20:01:26 CEST] <kurosu> kierank: apart from the transform one? (I don't know if it has one or what its size is)
[20:01:43 CEST] <kierank> yeah the transform one
[20:01:56 CEST] <llogan> michaelni: got a rough idea when 4.2 is due? a user is asking. he also wants to know if libdav1d support will be included.
[20:03:19 CEST] <kurosu> seems to be 36 samples (or some multiple of 12)
[20:13:49 CEST] <kierank> kurosu: hmm by my count I see a 10ms gap from where I'd expect to be to vs where I am
[20:15:30 CEST] <kurosu> mine was a cursory look at the transform size; I admit I don't know anything beyond that, eg if some temporal prediction occurs in addition
[20:15:54 CEST] <Lynne> its an MDCT-based codec so it'll have a delay of half the framesize
[20:17:32 CEST] <kurosu> oh yes, the overlap
[20:17:43 CEST] <kierank> Lynne: on the encoder or decoder or both?
[20:18:08 CEST] <kurosu> decoder also you need the "future" frame to know the output
[20:18:41 CEST] <kurosu> (I imagine)
[20:22:25 CEST] <Lynne> kierank: encoder
[20:23:33 CEST] <kierank> 576/48000 = ~0.012s
[20:23:36 CEST] <kierank> could be what I see
[20:25:15 CEST] <Lynne> 10ms is way higher than that, 36 samples at 48000 is ~0.75 ms
[20:25:15 CEST] <kurosu> but 576 is the framesize, right ?
[20:25:24 CEST] <kierank> 1152 is the framesize
[20:25:28 CEST] <kurosu> ok
[20:25:53 CEST] <Lynne> oh, its 576, so ~10ms is correct then
[20:30:45 CEST] <BBB> llogan: dav1d should be in next stable, yes
[20:33:36 CEST] <kierank> https://www.eetimes.com/document.asp?print=yes&doc_id=1274941&page_number=3
[20:36:44 CEST] <kurosu> 481 samples it would then be, but I imagine it is implementation-dependant after that ?
[20:38:35 CEST] <kurosu> ah no, it would be 1152+481, which is not consistent with what kierank sees
[20:39:23 CEST] <kierank> kurosu: I think that's including the delay of waiting for 1152 samples on the wire
[20:40:12 CEST] <michaelni> llogan, thanks for the reminder i posted a mail about 4.2 to the ML
[20:41:12 CEST] <JEEB> will have to try and make a FATE sample for that one sub2video case which has a fix on the ML
[20:41:31 CEST] <JEEB> since the only reason I've not merged it so far is because I didn't have time to make the test for it :<
[20:57:20 CEST] <cone-137> ffmpeg 03Michael Niedermayer 07master:3c0bfa7d1a90: avcodec/cpia: Check input size also against linesizes and EOL
[20:59:01 CEST] <jamrial> BBB: do i push the threading patch with Gramner's * 3 / 2 suggestion?
[21:00:18 CEST] <cone-137> ffmpeg 03Baptiste Coudurier 07master:b401a4ab8aa8: avformat/mxfenc: support XAVC long gop
[21:04:54 CEST] <BBB> ok
[21:29:09 CEST] <cone-137> ffmpeg 03James Almer 07master:fbc5a27694c2: avcodec/libdav1d: fine tune thread distribution
[22:50:43 CEST] <Lynne> why are there instances of shufps q3210 in the codebase at all when its just a mov (while shufps can't be optimized away)?
[22:51:53 CEST] <Lynne> wait, nevermind, I always confuse its 2-argument syntax
[22:54:52 CEST] <cone-137> ffmpeg 03Daniel Kucera 07master:8d9910a23ab3: ffplay: added option always on top for video window
[23:21:54 CEST] <cone-137> ffmpeg 03James Almer 07master:e1839283bc9a: doc: add basic documentation for libdav1d
[23:22:22 CEST] <jamrial> BBB: ^
[23:22:46 CEST] <BBB> "dav1d is an av1 decoder"?
[23:22:50 CEST] <BBB> :-p
[23:23:48 CEST] <BBB> looks ok
[23:23:59 CEST] <BBB> maybe it would be useful to explain the threading in the docs?
[23:24:04 CEST] <BBB> we also should do that in the dav1d docs
[23:24:11 CEST] <BBB> because it's a little bit "special"
[23:24:18 CEST] <BBB> different than normal, I mean
[23:24:22 CEST] <BtbN> I still wonder how av1 hwaccel is going to work with
[23:26:21 CEST] <jamrial> BtbN: hwaccel is unlikely to work with dav1d unless fully merged into the tree as a native decoder
[23:27:42 CEST] <jamrial> and doing that is probably going to mean only one kind of threading at a time for software decoding, unless the lavc internal threading framework is completely rewritten
[23:28:36 CEST] <mkver> @jamrial: The Matroska muxer still contains your workaround for libaom not propagating extradata during initialization. Is this still needed? The relevant bug you linked to has long been closed as fixed.
[23:28:44 CEST] <jamrial> BBB: i figured saying default being 0 (autodetect) is enough. do we even have documention about how threading works in general for internal decoders?
[23:29:07 CEST] <jamrial> mkver: yes, because libaom still has a bug when creating a sequence header for extradata
[23:29:20 CEST] <jamrial> where it doesn't match the one in key frames
[23:29:46 CEST] <jamrial> https://bugs.chromium.org/p/aomedia/issues/detail?id=2208
[23:31:09 CEST] <jamrial> and there's a patch, untouched since last october
[23:31:12 CEST] <jamrial> https://aomedia-review.googlesource.com/c/aom/+/73541
[23:35:15 CEST] <mkver> Ok, thanks.
[00:00:00 CEST] --- Tue May 21 2019