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

[burek]

[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