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

[burek]

[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:b85a939633c7: configure: create the tests directory like the doc directory
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:3a8ad4b87819: avformat/hdsenc: Use av_freep() avoid leaving stale pointers in memory
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:23a17b4a3d52: avformat/flvdec: Use av_freep() avoid leaving stale pointers in memory
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:b850b01533b8: avcodec/vmdvideo: Check len before using it in method 3
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:991ef3a67ec6: avcodec/xface: correct the XFACE_MAX_* values
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:71b1abe63856: avcodec/xface: Add asserts to limit nb_words from becoming too large
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:3d1972d182c0: avcodec/utvideodec: Fix handling of slice_height=0
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:d85e25fe0b52: avformat/mov: check atom nesting depth
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:4400385d5fd6: avformat/mov: fix integer overflow of size
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:c9b25252cbce: swscale: increase yuv2rgb table headroom
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:4b4d0b029045: avcodec/h264: make the first field of H264Context an AVClass
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:3a5b749d7caf: avcodec/indeo3: use signed variables to avoid underflow
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:5aead5ee0537: avcodec/dcadec: Check that the added xch channel isnt already there
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:e911f125fc30: avcodec/hevc: clear filter_slice_edges() on allocation
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:0663aab1d9af: avcodec/h264: Clear delayed_pic on deallocation
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:bf2c9e1ad4ba: avcodec/hevc_ps: Check diff_cu_qp_delta_depth
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:f13e6ec7a610: avcodec/h264: Check *log2_weight_denom
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:1344e91f33c8: avcodec/indeo3: ensure offsets are non negative
[03:33] <cone-538> ffmpeg.git 03Anton Khirnov 07release/2.5:50f4543c6b37: jvdec: check frame dimensions
[03:33] <cone-538> ffmpeg.git 03Anton Khirnov 07release/2.5:f5631d23e06a: mmvideo: check frame dimensions
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:9f8cdd520b24: Add FFMPEG_VERSION into the binary libs
[03:33] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:c96c75532016: Makefile: add dependencies which require ffversion.h
[03:56] <cone-538> ffmpeg.git 03Michael Niedermayer 07release/2.5:46db3121c665: update for 2.5.2
[04:37] <fffan> does that guy(Zeranoe) provide compilation script?
[05:07] <bryno> fffan: i think i remember seeing one, but i don't remember where i saw it...
[05:31] <Compn> fffan : ask on zeranoe forums 
[09:00] <AuXFire> Anyone here?
[09:01] <AuXFire> Nobody?
[09:03] <AuXFire> -_-
[12:47] <cone-164> ffmpeg.git 03Michael Niedermayer 07master:5dfae3f40a73: avformat/os_support: Use av_freep() to avoid leaving stale pointers in memory
[12:47] <cone-164> ffmpeg.git 03Michael Niedermayer 07master:fd3e7447c83b: avformat/riffdec: Use av_freep() to avoid leaving stale pointers in memory
[12:48] <cone-164> ffmpeg.git 03Michael Niedermayer 07master:03b84f2fb2a4: avformat/rtmpproto: Use av_freep() to avoid leaving stale pointers in memory
[15:46] <ubitux> i'm not sure to understand the stream side data
[15:46] <ubitux> are they going to end up in the packets?
[15:46] <ubitux> or just the first one? (beginning and after seek)
[15:46] <ubitux> or not at all?
[16:25] <saste> I'm testing fspp and I can't see significant improvement with video encoded with low quality
[16:25] <saste> is that expected
[16:25] <saste> ?
[16:25] <saste> also arwa's port is not bitexact with mp=fspp
[16:27] <arwa> I compared the outputs with different qp values, they are not coming out to be same.
[16:27] <arwa> I was trying to figure out the mistake, but I am not able to find out, where it is going wrong!
[16:29] <ubitux> try first with -cpuflags 0
[16:29] <arwa> Also, I have modified the code to take into account the filter strength as well. I will update the patch.
[16:29] <ubitux> so you can check if it's the asm or not
[16:29] <arwa> Okay, I will try to do that.
[16:31] <saste> ubitux, arwa: you ok with porting pp7?
[16:31] <arwa> Nope, its still not same :/
[16:31] <ubitux> saste: i think we're better without it, but people will complain if we drop it
[16:31] <saste> this will be probably the last port, then we have to wait for James Darnley to finish his eq/eq2 port
[16:31] <ubitux> saste: so the only salvation is to port it
[16:32] <saste> about softpulldown and ilpack I would drop them
[16:32] <ubitux> we still need confirmation from kierank about ilpack
[16:32] <saste> I have no idea what they are useful for...
[16:32] <saste> kierank, ^^
[16:32] <arwa> Okay, I am okay with pp7.
[16:32] <saste> if you won't replay will probably burn it
[16:32] <ubitux> ilpack might be doable with swscale but that's not obvious how, and we need the equivalent
[16:32] <kierank> ubitux: the chroma will need to be fixed in vf_scale for ilpack
[16:33] <saste> kierank, can you guide arwa's in the process?
[16:33] <kierank> yes
[16:33] <saste> kierank, thanks :-)
[16:33] <ubitux> publicly if possible
[16:33] <ubitux> (because i'm interested)
[16:33] <kierank> ubitux: why would I not do it publicly =p ?
[16:33] <saste> arwa, another thing that would need to be done, is documenting how the various pp filters compare
[16:33] <ubitux> kierank: i don't know :)
[16:34] <arwa> Okay!
[16:34] <saste> are you willing to spend something like a week testing and writing a document (on the wiki) comparing the various pp filters?
[16:34] <saste> arwa, I think 1/2 weeks should be enough
[16:34] <arwa> Okay, after they are ported, right?
[16:35] <saste> otherwise people will wonder and ask what the heck all these pp filters are about
[16:35] <saste> arwa, as you prefer
[16:35] <saste> we are left with fspp and pp7
[16:35] <arwa> Yes, I will do it after they are ported
[16:36] <saste> arwa, fine
[16:36] <arwa> What should I do for fspp? I am not able to figure out, where its going wrong!
[16:37] <ubitux> isolate the issue
[16:37] <ubitux> is it only one mode, does it differs with both asm and without?
[16:37] <saste> can someone confirm that fspp has almost no visual improvement on the output?
[16:37] <ubitux> how much does it differs (maybe use blend filter to make a diff)
[16:38] <saste> I can provide a complete reproducible use-case
[16:38] <arwa> It differs alot!
[16:39] <ubitux> saste: you need to compare with blocky videos
[16:39] <arwa> With increasing value of qp, it should get blurred(kind of), but the output is not coming out to be that!
[16:43] <saste> arwa, yes, I'm testing with 200 Kbps version of matrix_benchmark, and the output is not significantly better than the input
[16:43] <saste> same with mp=pp7
[16:45] <arwa> its good with mp=fspp?
[16:46] <saste> arwa, no
[16:47] <arwa> Ohh.. !
[16:48] <arwa> What are you setting your input arguments?
[16:51] <saste> arwa, mp=fspp
[16:53] <arwa> So, its default. Try something like mp=fspp=4:30. I think it will give a better output.
[17:00] <saste> arwa, no much difference...
[17:02] <arwa> Okay.
[17:03] <saste> michaelni, are you aware of an use case for fspp?
[17:04] <ubitux> imaginary users
[17:10] <Daemon404> im nto aware of a single person using any of the pp filters...
[17:23] <michaelni> Daemon404, iive and i do use them sometime, they improve the quality of low bitrate files
[17:24] <michaelni> saste, mp=fspp does now work
[17:24] <michaelni> noT
[17:25] <saste> Daemon404, what do you use instead?
[17:25] <michaelni> mp=pp7 also does not work
[17:25] <ubitux> ah?
[17:25] <ubitux> so we can actually drop them
[17:25] <ubitux> ;)
[17:25] <saste> also, I think with huge bandwidth and video encoded in high quality with H.264 and such PP is not that much needed
[17:25] <ubitux> won't be a regression then.
[17:25] <saste> michaelni, was it ever working before?
[17:26] <michaelni> i do not know, i only used spp IIRC
[17:26] <michaelni> it surely worked in mplayer
[17:26] <ubitux> really, if pp7 doesn't work, let's just drop it.
[17:27] <michaelni> -vf mp=pp7=20 works
[17:27] <michaelni> i guess qp passing does not work
[17:27] <saste> michaelni, that's my guess as well...
[17:27] <saste> but the port also is not "working"
[17:28] <michaelni> -vf mp=fspp=5:10 works too
[17:41] <iive> spp filters are quite nice spatial denoisers 
[17:42] <ubitux> there is no reason we need pp, pp7, spp, fspp, uspp, ...
[17:42] <ubitux> but well.
[17:44] <saste> ubitux, we did most of the work for porting them, pp7 also should be easy
[17:44] <saste> I don't know if anybody ever asked for porting fspp/uspp/pp7, when I asked nobody replied
[17:44] <saste> anyway since we're almost done, I suggest to go on with the port, or all the work would have been wasted
[17:45] <michaelni> the problem with fspp is something with the qp and p->threshold_mtx_noq
[17:49] <michaelni> also saste if the width/height removial you suggested was wrong, better suggest to undo it (i didnt test)
[17:49] <saste> michaelni, ok
[17:49] <Compn> https://www.justinribeiro.com/chronicle/2014/09/01/ffmpeg-prores-concat-filters-for-the-win/ , mentions artifacts when not using prores_ks , not sure if bug.
[17:49] <Compn> maybe carl could look into it ^
[17:50] <michaelni> hmm fspp looks cool now mostly black and green, how did i manage to break it taht way ;)
[17:51] <Compn> screenshots...
[17:51] <kierank> haha concat working
[17:51] <Compn> kierank : lol
[17:51] <ubitux> it's the filter, not the demuxer
[17:51] <ubitux> nor the protocol concat
[17:51] <kierank> nobody has explained to me what the duration of a vfr frame is
[17:51] <kierank> and how you therefore concat vfr video
[17:54] <michaelni> I think editing vf_fspp.c while having libmpcodecs/vf_fspp.c open can lead to interresting things, both windows look so similar
[17:54] <ubitux> :)
[17:59] <michaelni> Compn, for the black/green bug replace 71. by .71 and try something like -vf mp=fspp=5:5
[17:59] <Compn> ah maybe later, must go work, bbl
[18:14] <Compn> http://www.dirk-farin.net/projects/nlmeans/index.html
[18:14] <Compn> nlmeans filter for ffmpeg
[18:14] <Compn> someone should review and or apply it :)
[18:15] <Compn> merge whatever
[18:15] Action: Compn runs
[18:15] <ubitux> why wasn't this submitted..
[18:15] <ubitux> it looks very interesting
[18:15] <Compn> i dont ask questions, i just google for hours and hours...
[18:17] <nevcairiel> man his repository is full of weird shit
[18:19] <nevcairiel> unorganized mega commits at any case
[18:20] <Daemon404> well >research
[18:20] <ubitux> the weird shit you're seeing in the repository is just ffmpeg nevcairiel :(
[18:20] <Daemon404> theyre usually not the best at anythign resemblign organization
[18:20] <Daemon404> or best pratcices
[18:21] <ubitux> >working in master
[18:21] <Daemon404> also avs has had nlmeans (and an opencl nlmeans) for years
[18:21] Action: Daemon404 runs
[18:21] <ubitux> >random merges
[18:23] <nevcairiel> that particular algorithm is apparently also patented
[18:25] <kierank> and?
[18:26] <ubitux> -vf lena
[18:37] <saste> uhm, what if we extend codecview to show quantization values?
[18:37] <ubitux> saste: yeah, there are many things you could display
[18:37] <ubitux> see libavcodec/mpegvideo.c for the remaining stuff i didn't port
[18:40] <ubitux> nlmeans looks very small
[18:40] <ubitux> i'm pretty sure we can sanitize it without much efforts
[18:41] <ubitux> just need to add real threading
[18:41] <ubitux> not the omp parallel thing
[18:41] <Daemon404> lol omp.... >researchers
[18:42] <ubitux> oh... they also put asm intrinsics..
[18:42] <ubitux> https://github.com/farindk/ffmpeg/blob/master/libavfilter/x86/vf_nlmeans.c
[18:42] <ubitux> shouldn't be that much effort to port
[18:47] <ubitux> i might work on this one :P
[18:53] <ubitux> there are many papers on this actually
[18:53] <ubitux> http://www.ipol.im/pub/art/2011/bcm_nlm/ i see also this
[18:53] <ubitux> tritical also has its own implementation (referencing 3 papers)
[18:53] <ubitux> his*
[18:53] <ubitux> and i see that handbrake also has its own flavor
[18:54] <ubitux> i guess i'll have a look to this
[19:00] <Daemon404> /act/g 23
[19:01] <gnafu> Impressive results on that Dick Farin page.
[19:03] <Daemon404> old news to anyone on d9 :P
[19:12] <gnafu> Daemon404: I'm sure :-).  I haven't done any looking into noise reduction before.  Haven't really needed it.
[19:13] <gnafu> But I could see making use of that someday if I ever wanted to attempt digitizing some of the older VHS tapes in my church's sermon archives.
[20:35] <ubitux> animated webp?
[20:35] <ubitux> is that... webm?
[20:44] <cone-164> ffmpeg.git 03Piotr Bandurski 07master:75cc85b23970: cdxl: fix duration
[21:56] <cone-164> ffmpeg.git 03Michael Niedermayer 07master:fe439c20698f: avcodec/h264: also show frames with missing fields when CODEC_FLAG2_SHOW_ALL is set
[22:10] <kierank> very interesting file
[22:10] <kierank> they seem to be reducing bitrate by just encoding at 1920x540
[22:10] <kierank> and having the decoder resize
[23:49] <kierank> does ffmpeg support frame threaded encoding?
[23:53] <llogan> kierank: i guess it depends on the encoder. for example "ffmpeg -h encoder=mjpeg" then look for "Threading capabilities".
[23:53] <kierank> I mean can I just add CODEC_CAP_FRAME_THREADS and it'll do the rest?
[23:54] <kierank> all of them appear to be decoders
[23:56] <llogan> i'm not sure
[23:57] <nevcairiel> kierank: for intra-only codecs it should be possible to hook this up in ffmpeg
[23:57] <nevcairiel> (not in libav though)
[23:57] <kierank> oh
[23:57] <nevcairiel> for inter-codecs, i dont think there is an example to draw from
[23:57] <kierank> just intra for now
[23:57] <kierank> 10:57 PM <"nevcairiel> (not in libav though) --> I literally emailed ffmpeg and libav MLs about it
[23:58] <ubitux> libavcodec/dvenc.c:    .capabilities   = CODEC_CAP_SLICE_THREADS | CODEC_CAP_FRAME_THREADS | CODEC_CAP_INTRA_ONLY,
[23:58] <nevcairiel> ie setting ".capabilities   = CODEC_CAP_FRAME_THREADS | CODEC_CAP_INTRA_ONLY," on the encoder should be enough
[23:58] <ubitux> ?
[23:58] <ubitux> libavcodec/huffyuvenc.c:    .capabilities   = CODEC_CAP_FRAME_THREADS | CODEC_CAP_INTRA_ONLY,
[23:58] <kierank> ubitux: ok my bad I was in the wrong repo :)
[23:58] <ubitux> i see a bunch of others
[23:58] <ubitux> not sure how relevant it is
[23:58] <kierank> might be useful on 4K v210
[23:59] <nevcairiel> just set the flag and enjoy then!
[00:00] --- Tue Dec 23 2014