[Ffmpeg-devel-irc] ffmpeg-devel.log.20140424
burek
burek021 at gmail.com
Fri Apr 25 02:05:02 CEST 2014
[00:10] <michaelni> maybe someone should add a check to configure to test for 4.9.0 and print a big warning or fail
[00:13] <kurosu> michaelni, regarding your change on fic idct, you may as well merge loops for horizontal idct and clip+put
[00:13] <kurosu> not sure how to do that without code duplication and cleanly
[00:14] <michaelni> yes, thought about it too and thats was also why i didnt do it
[00:15] <michaelni> but if speed over clarity is preferred for fic i can surely do it
[00:15] <kurosu> no opinion
[00:15] <kurosu> this was more rethorical than of practical use
[00:15] <kurosu> I don't even know that codec and how useful it is
[00:17] <michaelni> the idct could also be optimized with conditional branches similar to the jpeg idct
[00:17] <michaelni> the higher coeffs should often be 0
[00:18] <kurosu> iirc, BBB optimized larger vp9 transforms by providing codepaths for some max count of coeffs
[00:19] <kurosu> makes even more sense, considering inter blocks
[00:19] <michaelni> and as you mention mmx, the idct could of course be done in mmx
[00:19] <michaelni> with idct + transpose + idct
[00:20] <kurosu> at that point, of higher priority would be to provide >=mmx implementation of vc1 transforms
[00:23] <kurosu> I'm not completely decided on the vc1 mc functions - main purpose would be to yasmify it but time + lambda*benefit suggests selecting skip instead
[00:23] <michaelni> lol
[00:25] <kurosu> anyway, good night
[00:26] <michaelni> good night to you too
[01:51] <cone-551> ffmpeg.git 03Michael Niedermayer 07master:291d464161a5: swresample: fix AV_CH_LAYOUT_STEREO_DOWNMIX input
[03:24] <BBB> kurosu: yeah it helps, particularly for bigger transforms... not sure if fic is worth optimizing extensively for (then again, is vp9? :-p), I guess I don't know what fic is...
[03:44] <jamrial> BBB: speaking of vp9, vp9dsp.h states that dst/left/top pointers are aligned by transform-size, but then the latter two are defined in vp9.c using LOCAL_ALIGNED_16()
[03:44] <jamrial> intra_pred, i mean
[03:45] <BBB> maybe they should've been aligned by 32 and I forgot
[03:45] <jamrial> I tried to write a quick avx2 version for some 32x32 functions and it crashes because they are not aligned
[03:45] <BBB> please do send a patch, I believe that's kinda important
[03:45] <BBB> right
[03:45] <BBB> avx2 work is awesome btw
[03:46] <BBB> anyway, consider it a bug, and feel free to send a patch, I'm obviously fine with changing it to LOCAL_ALIGNED_32, just an oversight
[03:46] <cone-551> ffmpeg.git 03YuDenzel 07master:443936d8b999: configure: Fix ld flags when rpath is enabled.
[03:47] <jamrial> ok
[03:54] <jamrial> it also crashed with dst for the same reason
[03:54] <jamrial> couldn't find where that one is defined, though
[03:55] <jamrial> then again i may be doing something wrong
[05:28] <cone-551> ffmpeg.git 03Michael Niedermayer 07master:31f2357fd0e2: avdevice/qtkit: fix include
[09:09] <cone-441> ffmpeg.git 03Michael Niedermayer 07release/2.1:8d6de877094f: swresample: fix AV_CH_LAYOUT_STEREO_DOWNMIX input
[09:09] <cone-441> ffmpeg.git 03Michael Niedermayer 07release/2.2:4f41717d0100: avformat/mux: Check for and remove invalid packet durations
[09:09] <cone-441> ffmpeg.git 03Michael Niedermayer 07release/2.2:4a479fd3e6a7: swresample: fix AV_CH_LAYOUT_STEREO_DOWNMIX input
[09:41] <ubitux> BBB: does make -j5 fate-vp9-00-quantizer-01 THREADS=2 works for you?
[09:41] <ubitux> i have a systematic fail here
[09:42] <ubitux> seems it's present since a while
[12:12] <wm4> where does crap like "avpicture_fill((AVPicture*)in_frame, data, PIX_FMT_YUV420P, width, height);" come from?
[12:12] <wm4> I see it all the time and I know it can cause actual problems
[12:12] <wm4> some tutorial? an example?
[12:13] <wm4> it was probably the standard way pre-TEP
[13:33] <BBB> ubitux: will have to recompile, that might take a while
[13:38] <BBB> ubitux: yes that fails
[13:43] <BBB> ubitux: the visible pixels seem identical according to glyuvplay
[13:43] <BBB> I heard somebody on some ML (maybe libav-devel) complaining also that vdpau tests fail because we're comparing invisible pixels - are we doing that?
[13:44] <BBB> or maybe it was dxva2, can't remember
[13:44] <BBB> anyway
[13:44] <BBB> the visible pixels are identical, so there's not much I can do beyond that
[13:45] <BBB> hm hexdiff says they're different
[13:45] <BBB> wait a minute
[13:45] <BBB> is glyuvplay buggy?
[13:45] <BBB> :(
[14:18] <BBB> hm it's chroma-only, that's odd
[18:56] <Mista_D> what web server modules are needed to accept "-progress http://..." please? The mailing list and manual have no info on that yet.
[21:35] <cone-441> ffmpeg.git 03Luca Barbato 07master:374fdc8c071d: flv: Improve log messages
[21:35] <cone-441> ffmpeg.git 03Michael Niedermayer 07master:277ae5a7b304: Merge commit '374fdc8c071dcd96422378b0a1a0d453336d8a01'
[21:45] <cone-441> ffmpeg.git 03Luca Barbato 07master:5d983fdbca55: flv: Warn only once
[21:45] <cone-441> ffmpeg.git 03Michael Niedermayer 07master:7da5ff5c18ae: Merge commit '5d983fdbca5570a1545a892583a372cfb3fffe92'
[22:05] <cone-441> ffmpeg.git 03Luca Barbato 07master:152b797cd687: flv: Do not mangle dts values for negative cts
[22:05] <cone-441> ffmpeg.git 03Michael Niedermayer 07master:ca9cc6fdcc78: Merge commit '152b797cd687e96a582a1cb908dddf3d330d7637'
[23:01] <cone-441> ffmpeg.git 03Derek Buitenhuis 07master:d66de5006bbc: fate: Add fic-in-avi test
[00:00] --- Fri Apr 25 2014
More information about the Ffmpeg-devel-irc
mailing list