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

[burek]

[00:13:55 CET] <cone-652> ffmpeg 03Andreas Cadhalpun 07master:d637a58750ef: diracdec: fix idwt_stride calculation in bytes
[00:54:46 CET] <kierank> how do I make avctx->execute actually use multiple threads
[00:57:18 CET] <philipl> pass it a thread pool?
[00:57:19 CET] Action: philipl runs
[00:57:43 CET] Action: kierank slaps philipl around a bit with a large spiny-back
[00:57:49 CET] <atomnuke1> kierank: isn't that already set up properly because low delay mode used it
[00:57:54 CET] <kierank> doesn't work
[00:58:01 CET] <kierank> uses one thread in reality
[00:58:35 CET] <kierank> ok missing AV_CODEC_CAP_SLICE_THREADS seems to help
[00:59:54 CET] <kierank> caps out at 26fps, dunno why
[01:06:02 CET] <J_Darnley> Up yours Telenet!  Stop dropping my connections!
[01:16:38 CET] <Compn> trouble in belgian paradise ? :P
[01:26:39 CET] <cone-652> ffmpeg 03Ricardo Constantino 07master:d50b5d547f40: rtmpdh: Initialize gcrypt before using it
[01:26:49 CET] <kierank> is there a way to allocate thread local storage
[01:43:33 CET] <kierank> atomnuker: are slice widths guaranteed to be mod-8?
[01:44:40 CET] <atomnuker> nope
[01:44:52 CET] <atomnuker> but for all practical purposes - yes
[01:45:20 CET] <kierank> well it matters unfortunately
[01:45:41 CET] <kierank> for simd
[01:45:50 CET] <atomnuker> well yeah, the current encoder and decoder supports odd-numbered lenghts and widths
[01:46:18 CET] <kierank> bugger
[01:46:32 CET] <iive> isn't linesize invented to help with that?
[01:46:33 CET] <atomnuker> we could limit them to powers of two only
[01:46:53 CET] <kierank> doesn't change the fact files could exist that aren't
[01:47:03 CET] <atomnuker> oh yeah, damn
[01:49:19 CET] <kierank> ah vc2hqdecode has hardcoded slice hights
[01:49:20 CET] <kierank> lol
[01:49:29 CET] <kierank> with special simd for each
[01:49:35 CET] <kierank> that's clever
[01:51:50 CET] <atomnuker> no, it's not actually hardcoded
[01:51:55 CET] <atomnuker> you can still set them
[01:52:14 CET] <kierank> the simd has harcoded slice heights
[01:52:34 CET] <atomnuker> ah
[01:52:45 CET] <atomnuker> but it rejects any slice dimensions it doesn't like
[03:39:17 CET] <cone-652> ffmpeg 03Michael Niedermayer 07master:7c97946d6131: avcodec/mpeg4video: Check time_incr
[05:23:48 CET] <thebombzen> I noticed a typo: libavdevice is not build with libv4l2 support.
[05:24:00 CET] <thebombzen> should be libavdevice is not built with libv4l2 support.
[05:24:19 CET] <thebombzen> not important enough for a bug report but figured I'd mention it here.
[05:51:48 CET] <Timothy_Gu> thebombzen: fixed, thanks!
[05:53:20 CET] <cone-652> ffmpeg 03Timothy Gu 07master:d64d6edfc7f5: Correct two build/built typos
[08:58:21 CET] <kierank> michaelni: any suggestions about how to make dirac_get_se_golomb faster?
[08:59:04 CET] <kierank> It takes up 80% of decode time...
[10:18:13 CET] <kierank> nevcairiel: I think slice threaded encoding is supported via avctx->execute actually
[10:18:57 CET] <kierank> lol ganesh and mats
[10:32:02 CET] <wm4> ganesh is still sending completely useless patches
[10:32:14 CET] <wm4> like checking fclose() return values for files opened read-only
[10:32:29 CET] <wm4> (which is still a "good idea")
[10:33:32 CET] <BtbN> Well, having a lot of commits has an effect now.
[12:04:52 CET] <michaelni> kierank, it should be possible to write a function like svq3_get_se_golomb for dirac, that is to use a LUT for the small and likely cases that already contains the sign
[12:05:09 CET] <kierank> michaelni: in the new dirac decoder they wrong a simd golomb decoder
[12:05:11 CET] <kierank> heard of that before?
[12:05:15 CET] <kierank> wrote*
[12:06:06 CET] <kierank> https://github.com/bbc/vc2hqdecode/blob/master/vc2inversetransform_sse4_2/vlc_sse4_2.cpp
[13:45:59 CET] <michaelni> kierank, did anyone benchmark that ?
[14:36:44 CET] Action: Daemon404 really wonders how the heck ami_stuff finds this ... stuff
[14:55:15 CET] <cone-090> ffmpeg 03Mats Peterson 07master:adef8ee794aa: lavf/matroskadec: Use av_realloc() in get_qt_codec()
[15:23:32 CET] <J_Darnley> What?  libavcodec doesn't already have a pb_255 constant?
[15:24:19 CET] <iive> i thought that one is easy to generate?
[15:24:24 CET] <J_Darnley> Oh it is
[15:24:32 CET] <J_Darnley> I just assumed I could cextern it
[15:27:44 CET] <ubitux> http://pastie.org/pastes/10685605/text
[15:27:50 CET] <ubitux> any idea why causes this ^
[15:27:52 CET] <ubitux> ?
[15:27:54 CET] <ubitux> what*
[15:28:18 CET] <wm4> cause what exactly?
[15:28:32 CET] <ubitux> the inexact duration in aac
[15:28:34 CET] <wm4> isn't it because of frame sizes?
[15:29:13 CET] <wm4> (so the duration would be aligned on frame sizes by padding or discarding some audio)
[15:30:09 CET] <ubitux> if i extract again the aac to a wav, the duration is back to 6
[15:32:10 CET] <ubitux> the start time is also 0.023220 for some reason
[15:32:29 CET] <wm4> ah
[15:32:35 CET] <wm4> that's the skip mechanism
[15:32:36 CET] <ubitux> so maybe it's padding the 5736 extra sample at the beginning?
[15:32:38 CET] <wm4> it cheats a bit
[15:32:46 CET] <wm4> something like this
[15:32:57 CET] <wm4> but it sounds like the reported duration is wrong then
[15:34:01 CET] <durandal_170> ubitux: did I got answer from you yesterday?
[15:34:06 CET] <ubitux> >>> 0.023220 * 44100
[15:34:08 CET] <ubitux> 1024.002
[15:34:18 CET] <ubitux> durandal_170: mmmh
[15:34:41 CET] <ubitux> durandal_170: i don't know for ifft api
[15:34:59 CET] <ubitux> well
[15:35:10 CET] <ubitux> i guess you need to put it back if you had it outside
[15:36:01 CET] <ubitux> like, with ifft you need to feed N/2+1 complex (2 samples) for N real (1 sample)
[15:36:09 CET] <ubitux> your buffer is likely of size N
[15:36:20 CET] <ubitux> and not N+2
[15:36:46 CET] <ubitux> so the real part of the last sample should be placed in the imaginary part of the first one before you feed it
[15:37:10 CET] <ubitux> wm4: yeah reported duration is wrong
[15:37:16 CET] <ubitux> by a margin of 1024
[15:37:28 CET] <wm4> ubitux: so something has to subtract the padding... but who
[15:37:41 CET] <wm4> (I find this start time hack to adjust timestamps a bit questionable too)
[15:37:56 CET] <ubitux> the first pts is like -1024
[15:38:14 CET] <wm4> huh
[15:38:22 CET] <wm4> and yet start_time is 1024?
[15:38:24 CET] <Daemon404> ubitux, there is a stupid padding removal thing in movdec iirc
[15:38:29 CET] <Daemon404> for itunes aac padding
[15:38:30 CET] <Daemon404> or some shit
[15:38:32 CET] <Daemon404> mayeb related?
[15:38:44 CET] <ubitux> streams.stream.1.start_pts=-1024
[15:38:46 CET] <ubitux> streams.stream.1.start_time="-0.023220"
[15:38:48 CET] <ubitux> streams.stream.1.duration_ts=265624
[15:38:50 CET] <ubitux> streams.stream.1.duration="6.023220"
[15:39:09 CET] <Daemon404> oh, that looks normal
[15:39:18 CET] <Daemon404> thats a standard way of chopping off the aac primign samples.
[15:39:29 CET] <Daemon404> (in mp4)
[15:39:40 CET] <ubitux> but shouldn't we duration -= start_time?
[15:39:59 CET] <wm4> just got an email
[15:40:01 CET] <wm4> "Recently, I meet a lots of mp3 file  probe as H263 mime.  It's make me very confuse."
[15:40:12 CET] <Daemon404> ubitux, yes... if youre demuxer is sane
[15:40:12 CET] <wm4> mp3 misdetected has h263?
[15:40:16 CET] <Daemon404> your*
[15:40:32 CET] <Daemon404> i bet lavf defines duration simply as sum of all samples
[15:40:34 CET] <wm4> Daemon404: should the demuxer do it?
[15:40:38 CET] <Daemon404> regardless of if theyre ona timeline
[15:40:44 CET] <nevcairiel> wm4: and i thought everything misdetected as mp3
[15:41:00 CET] <Daemon404> wm4, in ubitux's case it's chopped off using edts
[15:41:08 CET] <Daemon404> so yes demuxer imo
[15:41:17 CET] <Daemon404> (our edts support is lulz)
[15:41:47 CET] <wm4> nevcairiel: yeah...
[15:41:54 CET] <Daemon404> ubitux, if you look at the file in box dumper, youll probably see something like
[15:42:09 CET] <Daemon404> edts with an edit saying to play 0.023220-6.023220
[15:42:14 CET] <Daemon404> and a duration of 6.023220
[15:42:25 CET] <Daemon404> because duration, i dont think counts edits
[15:42:37 CET] <Daemon404> it's just the duration of the physical track
[15:42:43 CET] <ubitux> ah, this edts shit again
[15:42:53 CET] <Daemon404> because ffmpeg has no cocnept of presentatio timeline
[15:42:54 CET] <Daemon404> at all.
[15:45:13 CET] <wm4> ah wtf the website is 163.com, and it loads scripts from 162.net
[15:45:16 CET] <wm4> very funny, china
[15:46:16 CET] <omerjerk> Hi
[15:46:39 CET] <omerjerk> I'm a student developer from Delhi and would like to apply for GSoC this year.
[15:47:37 CET] <omerjerk> Does ffmpeg has its ideas page for GSoC'16 up yet ?
[15:47:50 CET] <omerjerk> or if not, from where should I begin ?
[15:47:56 CET] <omerjerk> Thanks in advance. :)
[15:48:01 CET] <J_Darnley> The 2015 page, probably
[15:48:25 CET] <Daemon404> er... orgs cant even apply yet
[15:48:29 CET] <Daemon404> we dont even know if well be accepted
[15:51:02 CET] <omerjerk> I'm sure ffmpeg will get in.
[15:58:55 CET] <durandal_170> libavfilter GUI, idea for example
[15:59:24 CET] <Daemon404> ... that should definitely not be in ffmpeg.git
[16:00:05 CET] <durandal_170> it should, in python for example
[16:00:22 CET] <atomnuker> durandal_170: what about the whole audiovisual filters in mpv thing?
[16:00:23 CET] <wm4> wat
[16:00:36 CET] <wm4> atomnuker: well that has nothing to do with ffmpeg
[16:00:53 CET] <Daemon404> ... no it definitely does nto belong in ffmpeg.git
[16:01:02 CET] <Daemon404> it's a downstream api/cli-use tool
[16:01:05 CET] <wm4> ffmpeg.git should be split!
[16:01:09 CET] <Daemon404> dont shit everything into ffmpeg.git
[16:01:12 CET] <wm4> then we don't need to think too hard about such things
[16:01:29 CET] <j-b> split it!
[16:01:45 CET] <durandal_170> atomnuker: mpv needs to be rewritten anyway
[16:01:54 CET] <J_Darnley> Do any of you use GDB's save-history feature?  If so do you make it write to a particular file?
[16:03:41 CET] <durandal_170> have someone tried listening pictures via spectrumsynth
[16:04:58 CET] <J_Darnley> Not me.
[16:14:39 CET] <cone-090> ffmpeg 03Carl Eugen Hoyos 07master:27fa70fdfe87: lavc/mjpeg2jpeg: Check for jpeg file header.
[16:51:45 CET] <mateo`> are there guidelines regarding what a decoder is supposed to do with frame->pts/pkt_pts/pkt_dts ? is the decoder supposed to rescaled the input packet pts with the avctx->time_base or framerate ?
[16:52:12 CET] <nevcairiel> its not supposed to do anything, iirc
[17:02:19 CET] <mateo`> the mediacodec decoder is working a bit like the qsv one, it has an internal queue of packets, a parser to convert the bitstream, so it's not one input - one output
[17:02:50 CET] <wm4> timestamps are to be passed through (for video codecs with reordering)
[17:03:03 CET] <wm4> and yes, with such an API it's going to be very painful
[17:03:09 CET] <wm4> (I've done it with mmal, sort of)
[17:03:28 CET] <wm4> might actually be easier to go through with adding a m:n decoding API first
[17:03:41 CET] <nevcairiel> that doesnt really resolve your timestamp trouble
[17:07:18 CET] <wm4> what's the problem?
[17:09:16 CET] <mateo`> I'm not sure I have a problem. I just want to make sure i'm doing things right.
[17:09:53 CET] <mateo`> mediacodec wants its input buffer pts in us (and this the output buffer pts is in us)
[17:10:57 CET] <Daemon404> sounds simple enough
[17:10:59 CET] <mateo`> so i'm rescaling the input packet pts to us (using avctx->time_base), then i'm doing the opposite on the output buffer to set the frame->pts
[17:11:02 CET] <Daemon404> but that is pretty odd
[17:11:07 CET] <Daemon404> literallu nothing uses us
[17:12:13 CET] <mateo`> for reference, http://developer.android.com/reference/android/media/MediaCodec.html#queueInputBuffer%28int,%20int,%20int,%20long,%20int%29
[17:12:34 CET] <Daemon404> .............
[17:12:36 CET] <Daemon404> long for PTS
[17:12:38 CET] Action: Daemon404 deskfaces
[17:13:06 CET] <nevcairiel> long in java is 64-bit
[17:13:19 CET] <Daemon404> hmm ok
[17:13:24 CET] <Daemon404> i thought it mirrored the C api
[17:13:51 CET] <mateo`> the C API uses an int64_t for it
[17:13:52 CET] <wm4> mateo`: do these have to be real timestamps? I know lavc doesn't need a time_base
[17:14:06 CET] <Daemon404> mateo`, am i correct in thinking the only timebase that the api supports is ¼s?
[17:15:14 CET] <mateo`> wm4: maybe i can just put the packet->pts into it if the decoder in software mode (and not to a surface)
[17:16:05 CET] <wm4> software mode as opposed to hw decoding?
[17:16:33 CET] <mateo`> nope, software mode means you actually get main memory buffers as ouput
[17:19:51 CET] <mateo`> the other mode let the decoder output directly to a surface
[17:20:02 CET] <BBB> do you really need to rescale the output back?
[17:20:16 CET] <BBB> I mean, the output is not changed from input right?
[17:20:22 CET] <BBB> so you can just give back the original value
[17:20:47 CET] <BBB> a linear lookup in a list of N entries is not that bad if N is very small (like, 5-10 frames?)
[17:22:00 CET] <BBB> mateo`: and I think you only set pkt_*, not pts itself, pts itself is a best-effort calculated based on pkt_* IIRC
[17:22:10 CET] <BBB> (in utils.c)
[17:22:50 CET] <mateo`> BBB: I think it might work (I will have to test) to not rescale the pts at all and let the value pass through mediacodec
[17:23:01 CET] <BBB> even better
[17:23:03 CET] <Daemon404> why does it even care about timestamps mateo` ?
[17:23:11 CET] <BBB> it probably doesnt
[17:23:15 CET] <BBB> :)
[17:23:21 CET] <Daemon404> i mean, that would make sense.
[17:24:53 CET] <mateo`> Daemon404: I don't know why mediacodec would care about the values
[17:25:41 CET] <Daemon404> exactly
[17:26:46 CET] <mateo`> BBB: I'll have to take a look at what utils.c is doing to generate the frame pts, it's a bit of a blackbox to me atm (that's why i'm asking all those questions, i guess)
[17:27:15 CET] <cone-090> ffmpeg 03Michael Niedermayer 07master:782c4ab4ede2: avcodec/truemotion2: Cleanup in case of tm2_read_stream() failure
[17:36:59 CET] <kierank> michaelni: yes authors did and it's faster
[17:39:50 CET] <Timothy_Gu> gi/tb
[17:39:54 CET] <Timothy_Gu> oops
[17:41:18 CET] <michaelni> kierank, faster than what ? previous dirac code or ffmpegs or something else ?
[17:41:28 CET] <kierank> faster than their previous code of course
[17:41:29 CET] <kierank> their c
[17:41:45 CET] <kierank> why would they compare their on decoder to ffmpeg
[17:42:01 CET] <michaelni> also the distribution of the values does matter for that stuff, the code we have is optimized for small values
[17:42:56 CET] <kierank> that may not be the fastest, no?
[17:43:02 CET] <michaelni> it would be interresting to know if their code is faster compared to ffmpegs
[17:43:25 CET] <kierank> their decoder is faster yes
[17:43:44 CET] <kierank> 80% of the time in our decoder is spent on golomb and dequant
[17:44:05 CET] <michaelni> this should not be, 80 sounds too much
[17:44:39 CET] <kierank> on a 700mbit file though
[17:44:45 CET] <michaelni> is *golomb() inlined ?
[17:44:55 CET] <kierank> yes
[17:45:26 CET] <michaelni> where can i find the file used for testing ?
[17:45:49 CET] <kierank> I will need to upload it somewhere
[17:45:50 CET] <kierank> it is large
[17:46:13 CET] <kierank> http://pastie.org/private/gy3t0aa80ldmymqqioqmw
[17:46:59 CET] <michaelni> would be usefull to have the same video for testing
[17:47:18 CET] <kierank> yes uploading it now
[17:51:38 CET] <kierank> michaelni: obe.tv/Downloads/output.drc
[17:51:50 CET] <kierank> and you will also need the slice thread patch I posted
[17:52:24 CET] <kierank> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186943.html
[18:04:06 CET] <dinux5> may I know the time zone in which most of the community members reside so that i know the perfect hours to ping you all when I have doubts ? :)
[18:05:08 CET] <kierank> mostly europe
[18:05:32 CET] <dinux5> ohk .thank you. 
[19:33:20 CET] <durandal_1707> anybody knows anything about overlap-add and audio synthesis?
[19:35:23 CET] <llogan> michaelni, Compn: I'll be gone from Jan 15-25. My ML queue clearing may be non-existant then.
[19:37:07 CET] <J_Darnley> Cock.  I forgot which operand was not-ed in pandn.
[19:48:51 CET] <BBB> durandal_1707: something, very little but I did write a decoder once
[19:48:59 CET] <BBB> durandal_1707: what the question?
[19:49:16 CET] <BBB> durandal_1707: and re: why are people obsessing about that patch, Ill try not to, Im just trying to not get more unnecessary code in if I can prevent it
[19:49:23 CET] <BBB> but my attention span only goes so far
[19:50:03 CET] <durandal_1707> BBB: I'm doing ifft and overlapping so I get back reasonable sound
[19:50:14 CET] <BBB> ok
[19:51:38 CET] <BBB> (but what is the question?)
[19:51:39 CET] <durandal_1707> the idea is allow users to modify signal in frequency domain, its spectrogram and ifft back to time domain
[19:52:29 CET] <durandal_1707> some stuff I did by guessing
[19:52:45 CET] <TD-Linux> like an equalizer?
[19:53:04 CET] <durandal_1707> Like what to multiply signal after overlap and ifft
[19:53:38 CET] <durandal_1707> equalizer can be done in time domain
[19:54:14 CET] <TD-Linux> well any linear filter can be done in time domain :)
[19:54:48 CET] <BBB> durandal_1707: Id almost certainly do what other codecs do, like on2avc uses straight fft
[20:01:37 CET] <michaelni> Compn (or someone else), do you want to create a sponsors page for ffmpeg ? Theres at least one person who wants to donate and is asking about the possiblity of having a logo or link somewhere
[20:14:58 CET] <durandal_1707> BBB: question is what's best windows to do fft  with overlap do editing and then ifft back with overlapping 
[20:19:36 CET] <durandal_1707> idea is to edit video spectrogram
[20:19:36 CET] <cone-090> ffmpeg 03Michael Niedermayer 07master:d73f0c586e7e: avformat/asfenc: Flush packet before duration becomes unrepresentable
[20:19:37 CET] <cone-090> ffmpeg 03Michael Niedermayer 07master:7c0b84d89911: avformat/asfenc: Check pts
[20:23:01 CET] <BBB> durandal_1707: Id do the same as what on2avc does, from what I remember it does 50% overlap (so each sample is always windowed exactly twice)
[20:30:32 CET] <durandal_1707> BBB: I do with magnitude and amplitude reduced to 8bit and 85% overlap with hann window works pretty well so far
[20:31:08 CET] <durandal_1707> s/amplitude/phase
[20:32:09 CET] <BBB> you can always make it configurable :D
[20:32:12 CET] <durandal_1707> 0.875 exactly
[20:32:24 CET] <BBB> I guess each sample twice is called 100% overlap
[20:32:26 CET] <BBB> so 100% is ok
[20:32:58 CET] <durandal_1707> no, that's 50%
[20:34:40 CET] <durandal_1707> so does doing compression in frequency domain like with video makes sense?
[20:36:50 CET] <TD-Linux> durandal_1707, absolutely, you might like to look at the opus demos
[20:36:54 CET] <cone-090> ffmpeg 03Carl Eugen Hoyos 07master:405abdbaee52: lavf/mpjpegdec: Do not call av_log() while probing.
[20:37:04 CET] <TD-Linux> https://people.xiph.org/~xiphmont/demo/
[20:37:52 CET] <TD-Linux> all modern audio codecs use the MDCT, not FFT though
[20:39:21 CET] <BBB> if you ever wonder why I bring up on2avc, its b/c afaics its the only codec using an actual full fft
[20:39:23 CET] <BBB> :-p
[20:39:24 CET] <BBB> so ys
[20:39:26 CET] <BBB> yes*
[20:49:24 CET] <Compn> michaelni : maybe llogan would volunteer ? its not really a donation if they request a sponsored link though....
[20:49:54 CET] <Compn> more like buying real estate on a website that gets a high google ranking :P
[20:51:41 CET] <michaelni> yes, thats a valid way to see it too
[20:54:13 CET] <llogan> is this regarding "We would like to become Sponsor"?
[20:57:47 CET] <Compn> (we get a lot of those crap emails)
[20:57:58 CET] <Compn> "business opportunity"
[20:57:59 CET] <Compn> heh
[20:59:15 CET] <TD-Linux> I got a lot of those when I controlled a .edu domain
[20:59:55 CET] <TD-Linux> they are after the high pagerank of a well known domain
[21:01:35 CET] <Compn> right
[21:02:08 CET] <Compn> i've explained the "we want to help protect your domain by registering ffmpeg.com.cn for you" emails to michaelni before. :)
[21:02:41 CET] <Compn> michaelni is too nice really. thats what the problem is.
[21:03:13 CET] <michaelni> llogan, yes, that guy was asking since a long time and reynaldo talked with him but reynaldo is busy now and its not entirely clear if its  "bad" guy or not
[21:06:49 CET] <michaelni> also does adding "nofollow" avoid any "SEO" & "bad" guy issues ? if so we could easily require that to be on any sponsor links
[21:07:57 CET] <llogan> ill add it to my todo list and maybe take a look after work
[21:08:08 CET] <michaelni> llogan, ok thx
[21:23:12 CET] <durandal_1707> why is google now fuzzing encoders and muxers?
[21:26:10 CET] <cone-090> ffmpeg 03Paul B Mahol 07master:2009d922db7a: avfilter/avf_showspectrum: add posibility to display phase
[21:26:11 CET] <cone-090> ffmpeg 03Paul B Mahol 07master:57df71eaf7c4: avfilter/avf_showspectrum: reduce number of operations
[21:34:58 CET] <durandal_1707> Compn: who complained about swscale?
[21:35:00 CET] <bencoh> maybe because they heavily rely on those for their transocding farm with user-supplied contentand want them to be not too unsafe?
[21:38:42 CET] <Compn> [15:08] <wm4> fritsch: yeah, seems to add libswscale deps (why)
[21:38:54 CET] <Compn> durandal_1707 : usual suspects :p
[21:39:35 CET] <durandal_1707> Compn: there should not be such dep
[21:39:48 CET] <Compn> it needs to convert some colors for the intel driver hw accel
[21:39:52 CET] <Compn> what should happen ?
[21:40:05 CET] <Compn> previous patch had colorspace conversion in the decoder
[21:40:19 CET] <nevcairiel> it should just define the appropriate input format and let ffmpeg.c do the conversion is what should happen
[21:41:03 CET] <Compn> nevcairiel : great, reply to my mail and put that useful comment on the ml so person can fix it
[21:41:22 CET] <Compn> i think you already did before
[21:41:28 CET] <Compn> maybe got ignored/missed
[21:41:44 CET] <nevcairiel> he didnt even bother to fix the obvious ugly mistakes and re-posted this giant patch without a single  line of acknowledgement of the feedback we have given
[21:42:22 CET] <Compn> perhapse a mail linking to the missed comments is in order then
[21:42:32 CET] <nevcairiel> it certainly doesnt feel likely at this stage that the commit is going to be acceptable anytime soon
[21:42:46 CET] <Compn> i'm not saying to commit anytime soon either.
[21:42:55 CET] <Compn> just talkin bout it bout it.
[21:48:51 CET] <durandal_1707> I'm really proud of writing first VV->A filter in lavfi
[22:00:14 CET] <llogan> which one is it? sorry, i was just sitting here mouthbreathing and not following lately
[22:32:42 CET] <durandal_170> llogan: spectrumsynth, reverses showspectrum
[22:36:40 CET] <wm4> how does it sync the two video streams?
[22:37:49 CET] <cone-090> ffmpeg 03Paul B Mahol 07master:57e4571679cd: configure: showspectrum now uses fft, add showspectrumpic
[22:40:26 CET] <durandal_170> wm4: they must have same properties, it picks one by one
[22:40:48 CET] <durandal_170> in fifo
[22:50:59 CET] <wm4> so what if one stream has 30 fps and the other 60?
[22:51:33 CET] <kierank> loooool mixing vfr streams
[22:51:49 CET] <kierank> goodluckwiththat
[22:52:36 CET] <nevcairiel> could be cfr, but  different 
[22:58:25 CET] <durandal_170> wm4: it check frame rate, if it doesn't match it aborts
[22:58:40 CET] <wm4> that's... not very robust
[23:06:12 CET] <J_Darnley> Does ffmpeg have a difference video filter?
[23:06:46 CET] <Compn> dont think so
[23:07:10 CET] <Compn> would be nice to make wrapper script for other filter/features of image processing
[23:07:24 CET] <Compn> that way we dont have to reinvent wheel for every thing , but hey i'm crazy...
[23:09:03 CET] <durandal_170> J_Darnley: see blend filter
[23:09:25 CET] <durandal_170> and tblend
[23:09:48 CET] <J_Darnley> ah thanks
[23:10:10 CET] <durandal_170> Compn: you should learn or keep calm
[23:17:08 CET] <J_Darnley> Damn.  I've just seen that I've got a stuck pixel.
[23:21:07 CET] <J_Darnley> Difference too small to see with naked eye
[23:22:02 CET] <J_Darnley> time for an expression!
[23:26:23 CET] <J_Darnley> good.  it isn't always wrong
[23:26:24 CET] <durandal_170> On monitor?
[23:26:29 CET] <J_Darnley> yes
[23:26:36 CET] <J_Darnley> stuck on bright red
[23:27:01 CET] <J_Darnley> or rather green and blue are stuck on 0
[23:54:57 CET] <cone-090> ffmpeg 03James Zern 07master:1a876cc581e7: libvpxdec: fix 'ISO C90 forbids mixed declarations and code' warning
[23:56:58 CET] <kierank> michaelni: can you elaborate on what else could be done to speed things up
[23:59:16 CET] <michaelni> not open/close the reader between each symbol, and decode multiple symbols at once (there are many ways to do that) like do 2symbols at once like we do for huffyuv or decode a run of zeros with the fllowing symbol as one symbol if its bitlength fits in a LUT / VLCtab
[00:00:00 CET] --- Wed Jan 13 2016