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

[burek]

[06:08:43 CET] <cone-249> ffmpeg 03Gyan Doshi 07master:fda793f6fa76: configure: select rotation filters for ffmpeg
[06:30:00 CET] <cone-249> ffmpeg 03Gyan Doshi 07master:73b62f302695: doc/protocols: move option follow entry to correct section
[10:21:53 CET] <BtbN> nothing in that yadif_cuda ticket makes sense
[10:40:14 CET] <durandal_1707> nobody working on full DNG support in FFmpeg?
[12:18:18 CET] <kurosu> can confirm maseck's numbers for cdef_dir_8bpc_avx2: 96->86 on HSW
[12:18:38 CET] <j-b> that is cool.
[13:19:21 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:1eb35eb50ed3: avcodec/diracdec: Correct max pixels check
[13:19:22 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:b8ecadec0582: avcodec/bethsoftvideo: Check block_type
[13:19:23 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:5cf42f65b60d: avcodec/gdv: Check for truncated tags in decompress_5()
[13:19:24 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:951bb7632fe6: avcodec/aic: Check remaining bits in aic_decode_coeffs()
[13:19:25 CET] <cone-249> ffmpeg 03Michael Niedermayer 07master:b819472995f5: avcodec/qpeg: Limit copy in qpeg_decode_intra() to the available bytes
[17:07:20 CET] <philipl> BtbN: Yeah. Nothing makes sense. I don't know how people get into these situations.
[17:35:59 CET] <JEEB> durandal_1707: mp4 has bit rate info since it literally reads the index, btw. I went through that with the guy
[17:36:06 CET] <JEEB> and I'm not going to waste any more time on that person
[17:36:15 CET] <durandal_1707> lol
[17:36:48 CET] <JEEB> how libavformat/-codec decide to set a bit rate to something is more or less random and/or guesswork so that's the best reply you can give the guy
[18:13:25 CET] <durandal_1707> could we guess audio bitrate from some info like we do for video?
[18:13:57 CET] <JEEB> we probably do already
[18:34:25 CET] <durandal_1707> JEEB: not really, ff_guess_coded_bitrate() only do for raw video
[18:34:56 CET] <JEEB> ok, dunno. but really, I'm not liking adding more and more random guesswork just because users complain that there's no bit rate value somewhere
[18:35:17 CET] <JEEB> I think we already report bit rates in way too many places where we're potentially just guesstimating it
[18:44:38 CET] <cone-799> ffmpeg 03Paul B Mahol 07master:a367a932d36a: avcodec/utils: remove commented out obsolete code
[18:57:37 CET] <taliho> Hello, I've been looking over the libavformat/mpegts.c code. The function mpegts_read_header currently needs to buffer 8192bytes to identify raw packet size (i.e. 188, 192 or 204 bytes). To avoid having to buffer 8192bytes, I would like to modify this part of the code so that it is similar to av_probe_input_format (dynamic buffer until a good score is identified). Anyone have feedback or objections?    
[18:59:31 CET] <JEEB> taliho: so adding a read_probe there?
[18:59:43 CET] <JEEB> into AVInputFormat of MPEG-TS
[19:01:34 CET] <JEEB> in theory it makes sense but I do wonder how much the framework would like that you don't have any streams or anything
[19:02:04 CET] <JEEB> if I understand it correctly you just want to be able to open the demuxer without any buffer handled
[19:02:27 CET] <JEEB> since in mpegts_read_header it also checks for SDT/PAT
[19:11:57 CET] <taliho> in mpegts_read_header, the only role of buffering 8192bytes is to first set the variable raw_packet_size. I looked at git blame, and the size of buffer appears to have changed from 1024 -> 5*1024 -> 8*1024 bytes. I was thinking why not iteratively check the score (for 188/192/204). If the score is high enough, then we do not need to continue to buffer data, else grow the buffer and check again.  
[19:12:33 CET] <JEEB> yes, but if your idea is to minimize buffering?
[19:12:57 CET] <JEEB> then you would be basically wanting the thing to read a minimum amount of stuff and not wait for SDT/PAT?
[19:12:58 CET] <taliho> JEEB: once raw_packet_size is set, only then set SDT/PAT
[19:13:09 CET] <JEEB> ah
[19:13:14 CET] <JEEB> yes now I see
[19:13:22 CET] <JEEB> it was there even more in the beginning of the function
[19:13:34 CET] <taliho> yes
[19:19:07 CET] <JEEB> taliho: anyways, what is your idea of your change other than just utilizing any buffer that you have around and then possibily implementing the probe callback for further probing?
[19:25:53 CET] <taliho> JEEB: I believe this change would reduce latency to real-time streaming. I.e. For a 100kbps stream, having to buffer 8192bytes is 0.65 seconds of latency    
[19:27:40 CET] <JEEB> no, I understand that
[19:27:46 CET] <JEEB> I was just interested in the changes otherwise
[19:28:16 CET] <taliho> oh I see, for now that's the only change :)
[19:28:30 CET] <JEEB> being what exactly?
[19:28:42 CET] <JEEB> your comments didn't exactly show me what exactly you thought of changing
[19:28:52 CET] <JEEB> I get the idea of what you're attempting to affect
[19:29:17 CET] <JEEB> but I don't yet grasp what exactly you are planning on doing to get that effect
[19:29:34 CET] <taliho> I see
[19:29:58 CET] <JEEB> also does libavformat even successfully open the demuxer if you don't get *any* streams etc?
[19:31:22 CET] <JEEB> also so that ffmpeg.c etc could keep getting similar results, what about making a probe function then that would do similar stuff just to get some stuff initialized?
[19:31:44 CET] <JEEB> if what I'm saying makes any sense :P
[19:33:14 CET] <taliho> that's a good question, I know once you open the stream. You know the number of AVStreams present. I would have to check if the stream is not valid
[19:34:15 CET] <JEEB> the AVStream count can raise with time, of course. that by itself is not a problem
[19:34:29 CET] <JEEB> I just wonder if lavf had any stupid limitations
[19:39:28 CET] <taliho> that's a good question, I know once you open the stream. You know the number of AVStreams present. I would have to check if the stream is not valid
[19:39:54 CET] <JEEB> you only know that if you have read enough of the input
[19:40:01 CET] <taliho> sorry, posted wrong message
[19:40:10 CET] <JEEB> I'm talking about a case where you open an AVInputFormat without any data in the buffer
[19:41:14 CET] <JEEB> since effectively to have "zero buffering" during opening that's what you'd do
[19:41:23 CET] <JEEB> and then you would just start reading packets
[19:42:54 CET] <taliho> yes, I believe the function avio_read() blocks if you are waiting for data 
[19:49:10 CET] <taliho> JEEB, just to summarize this is what I would like to modify: In function mepgts_read_header: Modify the way that ts_raw_packet_size is evaluated. Then, continue with the flow of the code after the check (ts->raw_packet_size <= 0) 
[19:53:34 CET] <taliho> To evaluate raw_packet_size: 1) Read a buffer 1024bytes 2) Calculate the score for packets 188/192/204. If the score is above a threshold, then set raw_packet_size. Else read another packet, and recalculate the probe scores. Continue until a limit is reached, else set a default ts_raw_packet_size=188 
[20:06:05 CET] <BtbN> philipl, I'd say it's a permission error on /dev/nvidia, but then again, nothing would work in the first place then?!
[20:22:57 CET] <cone-799> ffmpeg 03Paul B Mahol 07master:17008a010753: avcodec/hcom: check that index into array is valid
[22:43:46 CET] <cone-799> ffmpeg 03Jan Ekström 07master:4635f649534b: lavc/libx265: signal CPB properties through side data
[23:51:23 CET] <philipl> BtbN: unless he's selectively using sudo and not telling us, which is sort of what I read out of the last couple of comments.
[00:00:00 CET] --- Mon Mar  4 2019