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

[burek]

[02:35:23 CEST] <pross> uartie: github/gitlab/gitee/etc bug trackers have limitations too. but i am glad no-one said jira -- that seems to be as infectious today as microsoft office once
[02:35:26 CEST] <pross> .was
[14:08:21 CEST] <cone-072> ffmpeg 03Paul B Mahol 07master:a9bf65657752: avfilter/vf_lut2: add slice threading
[14:37:57 CEST] <mkver> jkqxz: In 4d56f7ab8f627aa140c1ede1bb61305f01cefcdd you made BSF see EOF so that they can flush any delayed packets. Does this really work? Because it seems that EOF does not even reach process_input_packet. Maybe it did work for avconv and not ffmpeg?
[14:40:01 CEST] <rcombs> huh, Network.framework TLS is built on top of BoringSSL
[19:02:02 CEST] <kierank> mkver: you could theoretically have every byte of H.264 in a separate PES
[19:02:50 CEST] <mkver> Yes, that seems to be spec-compliant. I would have expected the specs to bann such nonsense.
[19:04:37 CEST] <kierank> mkver: the intention I believe is to allow muxers to make sure bytes are not wasted
[19:04:55 CEST] <kierank> so you can start the next AU immediately after the last one ends
[19:05:11 CEST] <kierank> at low bitrates 1-180bytes wasted per AU is a lot
[19:06:01 CEST] <mkver> Ok, that makes sense.
[19:08:17 CEST] <mkver> If a new H.264 access unit doesn't immediately start at the beginning of the payload of a TS packet, then payload unit start indicator mustn't be set for said packet, I presume?
[19:08:54 CEST] <mkver> And then the container doesn't contain information to know where frames begin and end at all, so one needs to rely on the parser.
[19:10:51 CEST] <kierank> yes
[19:11:17 CEST] <kierank> high performance muxers do all sorts of things to reduce bitrate
[19:11:25 CEST] <kierank> a whole gop in the same pes is common
[19:12:30 CEST] <mkver> What about timestamps in such cases? How are they signalled?
[19:21:21 CEST] <kierank> just one at the beginning
[19:21:29 CEST] <kierank> it's cfr
[19:23:05 CEST] <mkver> And in case of frame reordering the parser/decoder needs to figure out the pts?
[00:00:00 CEST] --- Mon Jun 10 2019