[11:14:17 CEST] <JEEB> kierank: do I remember correctly that DTS > PTS with b-frames is invalid in MPEG-TS (that you just have to add enough difference between DTS and PTS that even with the re-order DTS is always <= PTS) [11:46:50 CEST] <nevcairiel> JEEB: just by sheer logic that would not make sense [11:47:16 CEST] <nevcairiel> decoding timestamp and presentation timestamp, you cant present something before it was decoded [11:52:25 CEST] <JEEB> yes [11:53:14 CEST] <JEEB> i'm mostly trying to double-check [14:05:11 CEST] <January> JEEB: are you sure they don't stand for display timestamp and processing timestamp? [14:06:06 CEST] <JEEB> yes [14:06:15 CEST] <JEEB> I am staring at PTS/DTS straight out of MPEG-TS [15:09:56 CEST] <cone-457> ffmpeg 03Carl Eugen Hoyos 07master:c51e0cd6edbe: lavf/flvdec: Remove an outdated comment. [15:13:52 CEST] <JEEB> wbs: do you remember if this was valid with negative CTS offsets? http://up-cat.net/p/c8f2b5e7 [15:13:58 CEST] <JEEB> at least libavformat doesn't seem to mind [15:14:05 CEST] <JEEB> (the DTS>CTS part) [15:14:25 CEST] <JEEB> or if even with negative CTS offsets you still had to keep DTS<=CTS [15:15:38 CEST] <BradleyS> is there a centralized place tracking deployment of ffmpeg releases by distro? or need to look at each's package repo? [15:16:00 CEST] <JEEB> with the raw values http://up-cat.net/p/899b422d [15:16:24 CEST] <JEEB> BradleyS: yea you'd probably have to check all distros [15:16:57 CEST] <nevcairiel> there is a trac page, but its probably not kept up to date [15:17:14 CEST] <JEEB> yea you'd have to have something dynamically regenerated [15:17:24 CEST] <JEEB> that checks with a cron every midnight or something [16:24:41 CEST] <wingrime> Hi all, I find why bug happends and need some developer agree https://trac.ffmpeg.org/ticket/7052 and comment somehow [17:18:35 CEST] <jdarnley> wingrime: those changes about 0 and EOF seem to have been causing trouble for a few people. The best you can do is produce a patch for it, otherwise just wait for someone who knows what they're doing to fix it. [17:34:46 CEST] <wingrime> jdarnley: nice, Patch indeed good, currenlty I have ugly durty fix, Better solution requires better knowlege in ffmpeg source code [17:35:18 CEST] <wingrime> that I curretly don't have [17:56:08 CEST] <atomnuker> BtbN: I think the bug above should help you nail down the rtmp issue you've had [19:28:57 CEST] <philipl> BtbN: Have you looked at the new nvidia video sdk 8.2 release? [19:51:01 CEST] <philipl> BtbN: Looks like the release notes are accurate. There are new calls to reconfigure a decoder and get decoder status. Everything else is unchanged. [19:59:06 CEST] <wbs> JEEB: that's valid, and that's exactly the whole concept of negative CTS offsets [19:59:14 CEST] <JEEB> yup [19:59:38 CEST] <JEEB> at some point after starting to write a bug report to a 3rd party I started to doubt myself :P [20:00:05 CEST] <JEEB> but I did note that it matches everything I've thought I knew of ISOBMFF and that case [20:02:37 CEST] <JEEB> thank you for verifying that I'm not insane [20:03:55 CEST] <JEEB> sfan5: btw was aarch64 FFmpeg still broken with --disable-avdevice ? or was the only failure with NDK 17b + clang the avdevice thing [20:05:57 CEST] <sfan5> last time i checked it was, no idea if it's the only failure [20:06:18 CEST] <JEEB> ok [20:06:42 CEST] <cone-457> ffmpeg 03Carl Eugen Hoyos 07master:fa35ab80f31e: lavf/isom: Make auxiliary_offsets consistently uint64_t. [20:06:45 CEST] <sfan5> https://0x0.st/sfH7.txt this one [20:06:59 CEST] <JEEB> > nlmeans \o/ [20:07:13 CEST] <JEEB> I didn't even remember that had aarch64 asm [20:23:24 CEST] <atomnuker> thank ubitux [20:30:09 CEST] <durandal_1707> ubitux is on very long vacation [20:31:24 CEST] <jamrial> durandal_1707: he was moving to some place closer to his dayjob, he said a week or so ago [20:41:36 CEST] <cone-457> ffmpeg 03James Almer 07master:81a18f219e2c: avutil/hwcontext_d3d11va: fix type arguments passed to IDXGIAdapter2_GetDesc() [20:43:24 CEST] <cone-457> ffmpeg 03Carl Eugen Hoyos 07master:d01d46ad860c: configure: Force pie for Android. [23:16:26 CEST] <jamrial> jkqxz: i can't realistically use cbs_av1 for a bsf autoinserted by a decoder meant for realtime playback [23:17:31 CEST] <jamrial> i just wrote an av1 packet splitter bsf using it, and compared to a version reading the raw bitstream, the cbs implementation is sixteen times slower [23:19:15 CEST] <jamrial> and this is without using the write/assemble functions, just the read ones, and also limiting the decomposition to only seq, frames/tilegroups and tds [23:20:21 CEST] <jamrial> i'm fairly sure cbs_av1 is a zero copy process, so i'm surprised [23:20:58 CEST] <jamrial> guess all the buffer references created when splitting units are not exactly free [23:27:47 CEST] <atomnuker> what does perf say? [23:28:04 CEST] <atomnuker> I'm still somewhat suspicious of the custom golomb reading function [23:29:09 CEST] <jamrial> haven't tried perf, will do it later [00:00:00 CEST] --- Thu Jul 26 2018