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

[burek]

[03:22:47 CEST] <cone-905> ffmpeg 03Jun Zhao 07master:af5f77011321: doc/codecs: Add missing documentation for nointra
[03:46:27 CEST] <Compn> btw a better email for the photosensitive patch might be thecybershadow+ffmpeg at gmail.com
[03:46:46 CEST] <Compn> if someone can relay that to the ml for me, i dont have mail stuff setup
[11:53:02 CEST] <durandal_1707> j-b: found IMM5 with HEVC instead of H264 in the wild
[11:53:11 CEST] <j-b> O_O
[15:58:55 CEST] <cone-962> ffmpeg 03Steven Liu 07master:234a5e058d7b: avformat/hlsenc: use old way for fragment mp4 in HLS PUT method
[15:58:56 CEST] <cone-962> ffmpeg 03Steven Liu 07master:ac22835db947: fate: add hls fmp4 segment type test case
[16:20:41 CEST] <cone-962> ffmpeg 03James Almer 07master:7cb4f8c962bd: avcodec: remove reference to AVPacket's destruct field
[16:28:01 CEST] <durandal_1707> jamrial: when you gonna apply matroska patches?
[16:34:24 CEST] <jamrial> durandal_1707: you can look at them and push them as well, you know? :p
[23:38:43 CEST] <durandal_1707> mkver: ask michaelni to give you commit rights
[23:41:49 CEST] <jamrial> imm5_decoder_select="h264_decoder hevc_decoder"
[23:41:54 CEST] <jamrial> what?
[23:42:22 CEST] <jamrial> holy shit, what is this codec?
[23:42:54 CEST] <durandal_1707> special CCTV codec for Police force
[23:47:34 CEST] <mkver> Are you intentionally not sending the timing info to the decoder?
[23:48:09 CEST] <durandal_1707> mkver: i feel stupid right now, what you mean exactly?
[23:48:39 CEST] <Lynne> no need for one if all frames are intra frames
[23:48:44 CEST] <mkver> You use a new packet structure and don't simply send the provided packet to the decoder.
[23:49:11 CEST] <mkver> The approach you use implies that data might be copied even when the original packet was refcounted.
[23:49:37 CEST] <jamrial> not might, will
[23:49:47 CEST] <jamrial> since he's sending a non ref counted packet to send_frame
[23:49:53 CEST] <jamrial> so it will be made refcounted, copying data
[23:50:26 CEST] <durandal_1707> can i reuse old packet somehow?
[23:51:18 CEST] <Lynne> can't this be handled in lavf?
[23:51:29 CEST] <mkver> You could just send avpkt and remove hpkt completely.
[23:52:11 CEST] <nevcairiel> he modifies the  packet content in various cases, that needs handling  still then
[23:52:11 CEST] <jamrial> mkver: there's the case where he uses imm5_buffer. in that case he does need a new packet
[23:53:19 CEST] <jamrial> unless he can just use an offset to change avpkt data and size
[23:53:29 CEST] <kierank> durandal_1707: interesting design
[23:53:50 CEST] <jamrial> this is kinda awful either way
[23:54:19 CEST] <durandal_1707> kierank: coders called themself "Zeus team" iiuc
[23:54:21 CEST] <kierank> is this not doable using a parser
[23:54:57 CEST] <durandal_1707> kierank: nope, you mean bitstream filter
[23:55:15 CEST] <kierank> can't parsers drop data?
[23:55:23 CEST] <durandal_1707> nope
[23:55:39 CEST] <durandal_1707> michaelni forbids it
[23:57:04 CEST] <durandal_1707> if you guys have some good solution, that enables DR1, I'm all ears
[23:57:29 CEST] <Lynne> lavf?
[23:57:55 CEST] <kierank> durandal_1707: it's part of the stream inside stream inside codec inside codec problem 
[23:58:02 CEST] <kierank> unfixable without ffmpeg rewrite
[23:59:59 CEST] <durandal_1707> Lynne: lavf? you want to add big hack to AVI demuxer?
[00:00:00 CEST] --- Tue Jul 16 2019