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

[burek]

[00:05] <yayoi> so anyway, should i do the 2/3 remaining or someone has a better suggestion on how i could contribute something potentially more useful to ffmpeg?
[00:33] <jamrial> any performance improvement is welcome, so consider submitting it to the mailing list to get a proper review thread going
[00:33] <jamrial> and if it's simple as you said, go ahead with the other 2
[00:36] <cone-388> ffmpeg.git 03Michael Niedermayer 07master:c1cdce5dcb95: avformat/matroskadec: Check av_mallocz() return values
[00:36] <cone-388> ffmpeg.git 03Michael Niedermayer 07master:a1062e1437c0: avformat/matroskadec: Use av_malloc_array() for index_entries
[00:52] <BBB> yayoi: did you actually look into a profiler to measure how much cpu time (single-threaded) is taken by colormtrix over other overhead in your pipeline?
[00:53] <BBB> yayoi: if the overhead is 80% and you go from 35 to 32 fps with 1->2 threads, Id say thats exactly expected (as you said; colormatrix isnt complex, so &)
[01:04] <wm4> yeah, testsrc is probably slow, and it also converts whatever testsrc outputs to uyvy422
[01:17] <ubitux> yay i finally got good rendering with my gif encode \o/
[01:20] <ubitux> http://lucy.pkh.me/gone-nutty.gif
[01:20] <ubitux> only one palette
[01:21] <ubitux> size is still a bit indecent (6.3M) but well
[01:22] <ubitux> ah and currently for reference: http://lucy.pkh.me/gone-nutty-current.gif
[01:22] <ubitux> (<1M though)
[01:23] <ubitux> the dithering makes the size explode, i can probably write a better one
[01:45] <kierank> colormatrix is pretty fast as it is
[01:45] <kierank> considering a lack of simd
[02:20] <ubitux> https://github.com/ubitux/FFmpeg/compare/colorquant 
[02:20] <ubitux> ffmpeg -i in -vf palettegen -y palette.png
[02:21] <ubitux> ffmpeg -i in -i palette.png -lavfi paletteuse out.gif
[02:26] <cone-388> ffmpeg.git 03Michael Niedermayer 07master:85d7e02e4af4: ffmpeg: allow overriding and amending AVStream->disposition
[08:33] <j-b> 'morning
[11:51] <filterAMI> I am getting  error: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[11:53] <filterAMI> I am getting error while using scale filter: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[13:45] <cousin_luigi> bbl
[15:08] <cone-504> ffmpeg.git 03Michael Niedermayer 07master:c50ddc10b2f0: doc/APIchanges: fill in the remaining missing dates
[15:09] <cone-504> ffmpeg.git 03Michael Niedermayer 07master:47785b44b554: avformat/movenc: fix cleanup on insufficient reserved_moov_size
[15:09] <cone-504> ffmpeg.git 03Michael Niedermayer 07master:da048c6d2472: avformat/movenc: Check failure of allocation of ctts_entries and propagate error
[16:17] <cone-504> ffmpeg.git 03Michael Niedermayer 07master:49456ed6069a: avfilter/vf_uspp: Use FF_CEIL_RSHIFT() correct rounding of odd w/h
[16:17] <cone-504> ffmpeg.git 03Michael Niedermayer 07master:fd048e690b0e: avfilter/vf_uspp: fix gop_size
[16:17] <cone-504> ffmpeg.git 03Michael Niedermayer 07master:ec28cdedde81: avfilter/vf_mcdeint: fix gop_size
[18:22] <arwa> For rebasing against the latest master, we just have to use git pull --rebase, right?
[18:34] <JEEB> or fetch and rebase, yes
[18:35] <JEEB> pull is fetch and merge or rebase together
[18:35] <JEEB> sometimes if you have stuff that has already gone to master it's a good idea to fetch and do an interactive rebase (-i) to make sure you're not trying to merge stuff that's already merged on top of the new HEAD
[18:43] <arwa> Okay thanks
[18:43] <arwa> :)
[18:53] <arwa> When I am requesting pull, then I am getting merge conflicts. How do I resolve these conflicts? I tried various things, but the conflicts are still there :/
[18:55] <nevcairiel> manually
[18:55] <Daemon404> you should rebase your branch, not merge
[18:56] <ubitux> i'm more and more annoyed at the duplication between the options description and the documentation
[18:57] <ubitux> we should have all the documentation inside the code and generate the doc from it or something
[18:57] <Daemon404> that doesnt work well in practice
[18:58] <Daemon404> you cannot have proper expository documentation that way
[18:58] <ubitux> i'm pretty sure it can work for filters
[18:58] <Daemon404> well i mean in general
[18:58] <Daemon404> e.g. platform.texi
[18:59] <ubitux> it's not for the whole doc, but at least for those that are redundant
[19:00] <ubitux> i mean we have a mechanism of self documentation (ffmpeg -h filter=foobar)
[19:00] <ubitux> it's just very rarely in sync with the documentation in doc/filters.texi
[19:00] <ubitux> doc/filters.texi being often more complete but not exactly matching the code
[19:00] <ubitux> (because of option re-ordering or whatever)
[19:00] <ubitux> anyway, it's kind of annoying
[19:02] <wm4> <ubitux> i mean we have a mechanism of self documentation (ffmpeg -h filter=foobar)
[19:02] <wm4> lol first time I see this
[19:03] <nevcairiel> unfortunately, the whole help system thing isnt well known
[19:04] <llogan> works for other stuff too. encoder, decoder, muxer...
[19:04] <llogan> we should document this documentation
[19:34] <rcombs> heh, so that's where that help text goes!
[20:13] <ubitux> > Firefox cannot guarantee the safety of your data on ffmpeg.org because it uses SSLv3, a broken security protocol.
[20:13] <ubitux> damn :))
[20:23] <nevcairiel> the website doesnt offer tls?
[20:23] <nevcairiel> someone should really fix that
[20:23] <nevcairiel> hm uses tls 1.0 here
[20:24] <wm4> j-b: what was the name of your smb library?
[20:27] <j-b> wm4: libdsm
[20:27] <j-b> wm4: it's not ready, be careful
[20:28] <wm4> is that why it's not on git.videolan.org?
[20:31] <j-b> wm4: it's on gituhb
[20:31] <j-b> wm4: https://github.com/videolabs/libdsm/
[20:33] <wm4> thanks
[20:45] <jamrial> kurosu_: did you also test movsd instead of movq?
[20:47] <cone-504> ffmpeg.git 03Michael Niedermayer 07master:961353d842bc: avfilter/vf_mcdeint: Set no_bitstream=1
[20:55] <michaelni> ubitux, sslv3 is disabled on ffmpeg.org since quite some time
[20:57] <ubitux> i just tried to set security.tls.version.min to 3 in about:config
[20:58] <ubitux> and firefox didn't appreciate accessing ffmpeg.org then
[20:59] <JEEB> mitm?
[21:01] <ubitux> maybe firefox just reports a stupid message
[21:01] <drv> it looks like ffmpeg.org only supports tls 1.0, and tls.version.min wants tls 1.2 only
[21:01] <JEEB> ah
[21:02] <kurosu_> jamrial, err, movsd? as in mov double? no, I just supposed that integer versions had lower latencies
[21:02] <kurosu_> I think we did that or thought about it on sbr dsp some years ago
[21:03] <jamrial> i checked and got similar numbers as movq (still much faster than movlps, so thanks for noticing that)
[21:03] <kurosu_> nice to see that corroborated - i thought that would be some gimmick optimization
[21:04] <jamrial> so i was wondering if movsd is a better choice since it remains in float domain
[21:04] <kurosu_> I've heard some new cpus have penalties when mixing integer and float insn, but I never noticed the actual issue
[21:04] <kurosu_> I can bench movsd - what's the insn set? sse2 or ?
[21:05] <jamrial> sse2, same as movq
[21:05] <kurosu_> ok
[21:10] <kurosu_> jamrial, same here, so why not
[21:11] <jamrial> ok
[21:13] <jamrial> I couldn't reproduce the gains you got by using m8 to store the mask here
[21:13] <jamrial> win64 as well
[21:48] <kurosu_> yeah, they are below the 1 cycle/loop so they are likely very dependant on cpu
[21:48] <kurosu_> so no big deal
[21:49] <kurosu_> tried replacing the movlhps with various unpacks - no change
[21:50] <kurosu_> otherwise good for me
[21:54] <jamrial> ok, thanks
[22:22] <cone-504> ffmpeg.git 03James Almer 07master:449b21bfab25: x86/sbrdsp: add ff_sbr_autocorrelate_{sse,sse3}
[22:22] <cone-504> ffmpeg.git 03Christophe Gisquet 07master:7aeafacfd0da: x86/sbrdsp: Use different mem moves
[00:00] --- Mon Jan 26 2015