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

[burek]

[00:06:11 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:1edf129cbc89: swscale/utils: Use normal bilinear scaler if fast cannot be used due to tiny dimensions
[00:19:12 CET] <michaelni> rcombs, did you see https://trac.ffmpeg.org/ticket/5090 (regression since 4ab56667594842283dc5ae07f0daba2a2cb4d3af according to the ticket)
[00:32:13 CET] <rcombs> hmm, I'll take a look
[01:27:06 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:7cc01c25727a: avcodec/h264_slice: Fix integer overflow in implicit weight computation
[02:25:23 CET] <cone-546> ffmpeg 03Ganesh Ajjanagadde 07master:43624a669b70: lavc/pcm_tablegen: slight speedup of table generation
[02:56:55 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:eb8a67de75ef: avcodec/dxv: Check idx in CHECKPOINT()
[03:35:45 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:68eb20801d69: avcodec/dxv: Check idx in dxv_decompress_dxt5()
[10:32:20 CET] <Franciman> Hello, is there a way to know how many samples does an audio stream contain without reading all data from it?
[10:36:28 CET] <av500> Franciman: depends on the container
[10:36:37 CET] <av500> what file format is your stream in?
[10:36:44 CET] <av500> or is it a real "stream"
[10:37:46 CET] <wm4> in general it's not possible without reading and decoding the whole stream, but some formats might allow you to make a pretty good guess
[10:43:31 CET] <Franciman> av500, uh I don't have a fixed format
[10:43:44 CET] <av500> so what do you have?
[10:44:47 CET] <Franciman> I want to accept as many formats as ffmpeg supports
[10:45:21 CET] <Franciman> btw, my objective was to add a progress bar that tracks the reading and decoding process of the stream
[10:45:35 CET] <Franciman> maybe I could use the duration in AVCodecContext
[10:45:41 CET] <av500> if its a real "stream", like a TS file, then no
[10:45:46 CET] <Franciman> and pts_time in AVFrame
[10:45:48 CET] <Franciman> ?
[10:46:01 CET] <av500> if you read a WAV or MP4 file, then yes you know how many samples there are
[10:46:08 CET] <nevcairiel> if it doesnt need to be entirely accurate, you could use the file position for a "progress" bar
[10:46:16 CET] <av500> if you have a file size, you can of course guess the position
[10:46:19 CET] <nevcairiel> ie. check pkt->pos returned from av_read_frame
[10:46:23 CET] <Franciman> yeah, doesn't have to be accurate
[10:46:28 CET] <av500> so use file pos
[10:46:37 CET] <av500> unless you have duration and/or samples
[10:46:56 CET] <Franciman> what you mean by samples?
[10:47:18 CET] <av500> same as duration
[10:47:39 CET] <av500> if you have sampling freq and duration, you have number of samples
[10:47:43 CET] <Franciman> oh right
[10:47:45 CET] <Franciman> :P
[10:48:05 CET] <Franciman> but it's not guaranteed that I have them for all types of stream?
[10:48:15 CET] <av500> correct
[10:48:16 CET] <nevcairiel> no, in fact most wont have that
[10:48:53 CET] <av500> if the file is constant bitrate you can use the file pos to know the time
[10:49:03 CET] <av500> if its variable bitrate, then no
[10:49:22 CET] <av500> if its just for a progress bar, then you can use file pos / total size
[10:49:28 CET] <Franciman> you're right
[10:49:35 CET] <Franciman> thanks a lot for your help
[10:49:40 CET] <Franciman> both of you
[10:49:41 CET] <Franciman> :)
[10:50:07 CET] <Franciman> ah just the last thing
[10:50:44 CET] <Franciman> for the file size do I use some ffmpeg related thing or use C library?
[10:50:51 CET] <wm4> I wouldn't use pos/size for a progress bar (although I do for transport streams)
[10:50:52 CET] <Franciman> C std library*
[10:51:24 CET] <Franciman> uhm
[10:51:32 CET] <Franciman> ok then, I'll just add an Extracting...
[10:51:47 CET] <Franciman> and if I have duration and sample rate, also add a progress percentage
[10:52:13 CET] <nevcairiel> wm4: why not, if its just a progress bar and not a seek bar, you get an OK approximation of progress anyway
[10:52:55 CET] <Franciman> just progress bar
[10:55:35 CET] <wm4> for some files it could in theory go backwards (mov)
[10:55:51 CET] <av500> for files with large index at the end, it wont reach 100%
[10:55:56 CET] <wm4> or not progress at all (things which don't set the packet pos, because it makes no sense)
[10:55:57 CET] <av500> but in both cases you should have duration
[11:03:08 CET] <Franciman> I see, ok thanks again
[11:03:49 CET] <av500> so basically try for duration first, if that fails fall back to pos
[11:04:17 CET] <Franciman> yes, thanks
[14:51:41 CET] <wm4> nevcairiel: so why is codec->sample_rate set to a "wrong" value when muxing?
[14:55:06 CET] <kierank> so for various *reasons* I might need a bitrate of > 2gbit/s - is this something ffmpeg might support?
[14:55:38 CET] <J_Darnley> Didn't bitrate just get bumped up to a 64-bit int?
[14:56:03 CET] <J_Darnley> (the restof the code I don't know about)
[14:56:08 CET] <kierank> yeah but it doesn't let you encode more than 2gbit
[14:57:17 CET] <J_Darnley> Is that just because the option's max value wasn't increased?
[14:59:20 CET] <kierank> probably
[15:17:47 CET] <cone-763> ffmpeg 03Paul B Mahol 07master:0d3b31ae898f: avfilter/avf_showspectrum: add yet another color map
[15:17:47 CET] <cone-763> ffmpeg 03Paul B Mahol 07master:c31fa1d7b44c: avfilter/avf_showspectrum: use av_clip/lrintf
[15:17:47 CET] <cone-763> ffmpeg 03Paul B Mahol 07master:c13216ac0801: avfilter/window_func: add tukey window function
[15:17:47 CET] <cone-763> ffmpeg 03Paul B Mahol 07master:206f65b06d0f: avfilter/avf_avectorscope: add line drawing support
[15:22:06 CET] <nevcairiel> wm4: its not "wrong", but opus has a nominal sample rate of 48kHz, and apparently the spec wants the padding to always be in 48kHz units
[15:24:13 CET] <wm4> the demuxer uses the codec->sample_rate field (which I suppose reflects the same EBML element in the mkv file)
[15:29:27 CET] <nevcairiel> I think Opus is a bit special when it comes to sample rates, from what I understand, the decoder can kind of choose at which sample rate to decode a file, and 48kHz is the nominal case
[15:30:01 CET] <nevcairiel> and it only contains "informational" metadata what the input sample rate once was
[15:31:18 CET] <nevcairiel> hence metadata like the trim info always relating to the 48kHz case
[15:31:52 CET] <BtbN> so kind of like those image formats where you can decode only the beginning and get a thumbnail?
[15:40:15 CET] <nevcairiel> From my basic understanding its simpler than that, opus consists of two codecs, CELT and SILK, and it appears CELT always decodes to 48kHz, while SILK can change sample rate (between 8000, 12000 and 16000) depending on content needs, so in effect a decoder could always just output 48kHz and no harm would be done
[15:40:22 CET] <nevcairiel> in fact the ffmpeg decoder deos just that, as it seems
[15:41:26 CET] <nevcairiel> (to combine these two parts of the stream, the SILK part is internally upsampled to 48000Hz)
[15:42:11 CET] <ubitux> durandal_170: *p = lrintf(av_clipf(s->combine_buffer[3 * y + plane], 0, 255));  why not av_clip_uint8(lrintf(s->combine_buffer[3 * y + plane]))?
[15:44:20 CET] <durandal_170> Is there difference?
[15:44:36 CET] <nevcairiel> in effiency only
[15:44:50 CET] <nevcairiel> efficiency*
[17:06:22 CET] <ubitux> i have a weird thing while decoding jpeg with ffmpeg
[17:06:45 CET] <ubitux> decoding the first packet decodes 994202/994295 bytes
[17:07:27 CET] <ubitux> strangely, doesn't call again the decode function with the remaining 93 bytes (while i do with the api, leading to an error)
[17:07:47 CET] <ubitux> ffmpeg cli* doesn't
[17:07:56 CET] <wm4> it doesn't have to
[17:08:01 CET] <ubitux> why?
[17:08:09 CET] <ubitux> packet is not fully consumed
[17:08:15 CET] <ubitux> no EOF is reached
[17:08:21 CET] <ubitux> and a frame was outputed
[17:08:33 CET] <wm4> because it's not required for video
[17:09:11 CET] <ubitux> i thought there were some streams like this?
[17:09:20 CET] <wm4> no, the parsers take care of this
[17:09:28 CET] <ubitux> mmh
[17:09:40 CET] <ubitux> can this still be considered a bug from the decoder?
[17:09:48 CET] <ubitux> (as in, not saying it consumed the whole packet)
[17:09:55 CET] <wm4> probably... but couldn't the remaining data just be junk?
[17:10:35 CET] <ubitux> i'll check
[17:10:48 CET] <bencoh> what happens if you flush the decoder (call with NULL packet)?
[17:11:21 CET] <wm4> bencoh: its internal state is reset and remaining buffered frames and data is discardedc
[17:11:24 CET] <wm4> -c
[17:11:50 CET] <bencoh> hm
[17:12:22 CET] <bencoh> (I was talking about the jpeg one in this case)
[17:12:37 CET] <bencoh> (but I guess it wouldnt be different)
[17:12:41 CET] <wm4> oh ok
[17:13:14 CET] <wm4> I mean it's just 93 bytes
[17:13:17 CET] <wm4> what could it be?
[17:13:39 CET] <nevcairiel> Jpeg doesn't sound like a decoder with delay, hence no NULL flushing
[17:14:21 CET] <wm4> nevcairiel: hm, there was at least 1 image codec which you had to flush to get a frame
[17:14:26 CET] <wm4> was it jpg or png
[17:15:30 CET] <ubitux> wm4: http://pastie.org/pastes/10671477/text
[17:15:33 CET] <ubitux> this is the junk
[17:15:35 CET] <ubitux> :(
[17:15:55 CET] <ubitux> (unrelated by wth is av_hex_dump*() in avformat and not avutil)
[17:17:16 CET] <nevcairiel> Technically it's a bug when a video decoder doesn't consume the entire packet, but in general its not required to send data again for video
[17:17:27 CET] <nevcairiel> While it is requires for audio
[17:17:55 CET] <wm4> ubitux: what's the packet from?
[17:18:04 CET] <ubitux> a jpeg
[17:18:23 CET] <wm4> just a file? not too surprising then
[17:18:35 CET] <wm4> isn't it perfectly normal to prepend or append random trash
[17:18:42 CET] <wm4> like with mp3
[17:18:58 CET] <ubitux> yes just a file
[17:19:04 CET] <ubitux> taken from a random android a while ago
[17:19:55 CET] <ubitux> nevcairiel: soon for subtitles too
[17:20:04 CET] <wm4> w-what
[17:20:23 CET] <nevcairiel> What subtitle format could ever require that
[17:20:25 CET] <wm4> flushing doesn't make sense for subtitles
[17:21:11 CET] <ubitux> (flushing will make sense for resetting the read order in the decoder after a seek)
[17:21:24 CET] <nevcairiel> That's what avcodec flush is for
[17:21:26 CET] <ubitux> nevcairiel: dunno yet, but i assume it could happen
[17:21:30 CET] <ubitux> nevcairiel: sure
[17:21:35 CET] <nevcairiel> Not NULL packets
[17:21:41 CET] <wm4> yeah, mixed terminology
[17:21:45 CET] <ubitux> i'm not talking about null packets :p
[17:21:47 CET] <ubitux> anyway
[17:22:09 CET] <wm4> some subtitle decoders already require avcodec_flush
[17:22:15 CET] <ubitux> http://b.pkh.me/blue-sky.jpg
[17:22:18 CET] <ubitux> here is the jpeg btw
[17:22:28 CET] <wm4> ubitux: btw. we added an API to libass to ignore readorder for deduplication
[17:22:41 CET] <ubitux> ok
[17:22:57 CET] <ubitux> i'm going to try to submit the sub patchset asap
[17:29:24 CET] <ubitux> if (strstr(name, "image2") || strstr(name, "_pipe")) {
[17:29:26 CET] <ubitux> guess what i'm doing
[17:29:28 CET] <ubitux> :(
[17:29:55 CET] <ubitux> can't use stream->nb_frames unfortunately :( (since 0)
[17:30:19 CET] <wm4> I do that too
[17:30:51 CET] <wm4> (actually I check for "image2pipe", and "image2" doesn't work due to custom IO)
[17:31:11 CET] <ubitux> but don't you get jpeg_pipe or stuff like that?
[17:31:12 CET] <wm4> and "_pipe" of course
[17:31:21 CET] <wm4> maybe a flag would be nice here
[17:31:31 CET] <wm4> but then, image formats can be ambiguous, like gif or apng
[17:31:45 CET] <ubitux> well technically, image2 could be a stream
[17:31:48 CET] <ubitux> jpeg as well
[17:32:00 CET] <ubitux> like if you're trying to play img%4d.jpg
[17:32:38 CET] <wm4> broken concept etc.
[17:32:48 CET] <ubitux> something annoying is that the demuxer actually set a duration for that
[17:32:48 CET] <wm4> (the % pattern matching I mean)
[17:32:58 CET] <ubitux> yeah well it's actually pretty useful
[17:33:05 CET] <ubitux> many people use it (me the first)
[17:33:06 CET] <wm4> what framerate does it assume?
[17:33:18 CET] <ubitux> 25 iirc but you can specify your own
[17:33:22 CET] <wm4> sure, it's useful, but it shouldn't interpret characters in random URLs
[17:33:37 CET] <ubitux> don't we have different pattern matching engines?
[17:37:11 CET] <wm4> (not sure what you mean)
[17:37:34 CET] <nevcairiel> We do
[18:21:36 CET] <cone-763> ffmpeg 03Aman Gupta 07master:e7271e6d078a: libavcodec/ccaption_dec: remove unnecessary include
[18:21:37 CET] <cone-763> ffmpeg 03Michael Niedermayer 07master:5b4da8a38a5e: avcodec/motion_est: Fix mv_penalty table size
[18:48:17 CET] <prelude2004c2> hey guys.. pulling in a source with ffmpeg " skipping 1 segments ahead, expired from playlist" i get those errors and my frame rates start to drop below 25fps ...i get freezing and stuff but yet when i play the same source with VLC i don't have any issues... anyone know why ?
[21:37:09 CET] <cone-763> ffmpeg 03Carl Eugen Hoyos 07master:c3c22bee6362: lavf/matroskaenc: Assume 48kHz sample rate for Opus initial padding.
[21:37:54 CET] <ubitux> i wonder why the "redundant commands" are ignored in ccaption decoder
[21:49:06 CET] <ubitux> lo >= 0x40 || lo <= 0x5f
[21:49:23 CET] <ubitux> is it me or || should be &&?
[21:49:27 CET] <ubitux> (or sth like that?)
[21:50:16 CET] <ubitux> where is the specs...
[21:50:17 CET] <durandal_170> yes
[21:50:29 CET] <ubitux> where is anshul
[21:51:01 CET] <ubitux> :((
[21:51:36 CET] <ubitux> i wonder why this weird condition wasn't detected by any static analyzer
[22:39:45 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:fa74cdc60d19: parser: add av_assert1 to make sure the codec matches
[22:39:46 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:da3c3c446cb4: avpacket: fix size check in packet_alloc
[22:49:40 CET] <Timothy_Gu> lol at reimplementing cbrt()
[22:51:47 CET] <tmm1> ubitux: i wondered that too
[22:52:02 CET] <tmm1> lots of questionable code in that decoder
[22:52:19 CET] <tmm1> i fixed a number of bugs last night
[22:56:17 CET] <ubitux> i really don't like this command caching
[22:56:35 CET] <ubitux> i feel like it's a workaround for a bug
[22:56:57 CET] <ubitux> anyway, i'm translating all the commands to the appropriate masks right now
[22:58:30 CET] <wm4> so, what about this event buffering the CC decoder does?
[23:01:58 CET] <tmm1> ubitux: i'm not sure the masks are more readable, esp when comparing to the spec or wikipedia docs
[23:02:28 CET] <tmm1> wm4: i'm working on a patch that fixes the buffering issue
[23:02:36 CET] <ubitux> tmm1: do you have the specs?
[23:03:34 CET] <tmm1> not the official one, no. using wikipedia and other random resources on google
[23:08:34 CET] <ubitux> oh wikipedia indeed has some good doc
[23:08:54 CET] <tmm1> yea its all there
[23:09:49 CET] <tmm1> i can try to remove this redundant check, that will allow us to kill the buffering as well
[23:10:29 CET] <ubitux> if you have a small sample which cover the code well that would be welcome
[23:10:44 CET] <ubitux> i can add a fate test if you don't feel like it (but i'll need the sample)
[23:10:55 CET] <ubitux> (there is already one but for 2 small events)
[23:11:11 CET] <ubitux> so i don't trust it much
[23:11:18 CET] <tmm1> yea i have a couple, for painton and rollup
[23:32:02 CET] <tmm1> sliced up a few samples, uploading now
[23:32:15 CET] <tmm1> ubitux: https://s3.amazonaws.com/tmm1/ccaptions/movie.ts
[23:34:33 CET] <tmm1> also uploaded news.ts, news2.ts, sports.ts and music.ts to the same dir
[23:36:23 CET] <tmm1> btw i exchanged some emails with anshul last month, but haven't been able to get in touch since the new year
[23:40:54 CET] <ubitux> cool, thx
[23:41:10 CET] <ubitux> they're quite large though, they won't make it to fate
[23:41:21 CET] <ubitux> (around 500k would be ideal)
[23:41:25 CET] <ubitux> (or less)
[23:41:36 CET] <ubitux> but i'm grabbing them for personal testing :p
[23:41:44 CET] <tmm1> ah, they're 30s so you can trim them down to 5s or so
[23:41:58 CET] <ubitux> yeah but then you probably fucked up a bunch of events
[23:42:44 CET] <tmm1> seemed to be fine when i cut down to 30s, could also perhaps re-encode the video quality down but leave the sidedata intact
[23:43:47 CET] <tmm1> do you think this whitespace cleanup patch will be merged?
[23:43:54 CET] <tmm1> not sure what to base further bugfix patches on
[23:45:16 CET] <ubitux> i could push the patch, but right now i'm going afk, so maybe tmr
[23:45:28 CET] <tmm1> ok, thanks
[23:45:47 CET] <tmm1> i'll submit another patchset assuming that will be merged
[00:00:00 CET] --- Wed Jan  6 2016