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

[burek]

[00:11] <kurosu> michaelni, while on the topic of those dsp functions, I can't find symbols for sse2 variants (they doesn't seem to be implemented anyway)
[00:11] <kurosu> in particular, I would expect the 16-wide functions to benefit from sse2
[00:11] <kurosu> but maybe they are simply named otherwise
[00:16] <michaelni> ff_put_pixels16_sse2 / ff_avg_pixels16_sse2
[00:19] <kurosu> yes, but that's the only ones
[00:20] <kurosu> michaelni, I'm thinking of the 2d ones like put_pixels16_x2
[00:21] <kurosu> most of the other ones are defined by called twice the 8-wide version (mmxext/3dnow)
[00:27] <michaelni> maybe they where forgotten somewhere between the early cpus that where not faster with sse2 than 2 x mmx and today
[00:30] <kurosu> I had the same issue with 3dnow and sse
[00:33] <kurosu> do you have any idea where the _x2_ and _y2_ would be used? for the others, it's mostly mpeg2, and it looks like this too
[00:51] <kurosu> some mpeg2 decoding going 3.71s -> 3.53s - I guess they are useful
[01:11] <jamrial> kurosu: 8388241 runs at 55 cycles each vs 49 cycles each is a ~12% difference, whereas 131042 runs at 449 cycles each vs 430 cycles each is ~4%
[01:11] <jamrial> so technically, and unless I'm failing hard at math, avg16 is the negligible one :P
[01:13] <kurosu> yes, strictly speaking
[01:13] <kurosu> but the bigger cycle difference may actually result in a bigger difference at the end
[01:13] <kurosu> that and 4*8x8 << 16x16 so the 16x16 might prevail
[01:15] <kurosu> anyway, we are checing hard on <1%, while sse2 cpus have a 10% slowdown because there are no sse2 version of other mpeg2 dsp functions :D
[01:54] <BBB> kurosu: pure laziness
[01:54] <BBB> kurosu: so no, not intentional
[01:55] <BBB> kurosu: I believe the big thing was (at that time) to get some codecs to compile w/o dsputil
[02:20] <michaelni> kurosu, _x2 _y2 _xy2 would be used in mpeg1, mpeg2, h263, mpeg4-asp, msmpeg4, some realvideo variants
[03:23] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:19e66c7232d9: avcodec/libvorbisenc: dont add the duration to AV_NOPTS_VALUE
[04:47] <cone-670> ffmpeg.git 03Christophe Gisquet 07master:d1a32c3f4912: x86: kill fpel_mmx.c
[04:48] <jamrial> great commit message there :P
[07:27] <kurosu> michaelni, ok, wasn't sure half pel was changed away from bilinear in mpeg4
[07:27] <kurosu> (or h263)
[07:28] <michaelni> mpeg4 asp supports qpel but its optional and not every video uses it
[11:05] <nevcairiel> you guys broke msvc builds again
[11:06] <nevcairiel> if you're messing with inline asm, test a --disable-inline-asm build after plz :P
[13:47] <cone-225> ffmpeg.git 03Hendrik Leppkes 07master:cd9e08e110b9: hpeldsp: fix build without inline asm
[13:47] <cone-225> ffmpeg.git 03Michael Niedermayer 07master:3d4e365073c0: avcodec/x86/hpeldsp_init: remove redundant if()
[14:13] <BBB> in a way I'm so happy with all the msvc support nowadays
[14:13] <BBB> even if I don't actually use it :-p
[14:14] <BBB> that was probably the most political issue ever
[14:14] <BBB> progress yay
[15:08] <compn> BBB : was it? i guess msvc had a lot of roadblocks , c89 > c99 stuff
[15:08] <compn> inline asm > external yasm
[16:07] <cone-225> ffmpeg.git 03Michael Niedermayer 07master:f0211f4189a5: ffprobe: Use av_malloc_array()
[16:07] <cone-225> ffmpeg.git 03Michael Niedermayer 07master:606a49d2e6f1: avcodec/atrac3: Use av_mallocz_array()
[16:07] <cone-225> ffmpeg.git 03Michael Niedermayer 07master:e61055fd8ba3: avcodec/atrac3plusdec: Use av_mallocz_array()
[17:40] <cone-225> ffmpeg.git 03Dale Curtis 07master:ef0c466a0fef: Replace assert with AVERROR when recode_subtitle called w/o ICONV.
[17:40] <cone-225> ffmpeg.git 03Michael Niedermayer 07master:91a8262b9dbc: avcodec/utils: add error message for the recode_subtitle() without iconv case
[19:02] <cone-225> ffmpeg.git 03Michael Niedermayer 07master:7f7080dc73df: avformat: add av_stream_get_end_pts()
[19:02] <cone-225> ffmpeg.git 03Michael Niedermayer 07master:1f359c85599b: ffmpeg: use av_stream_get_end_pts()
[19:12] <ubitux> michaelni: can't we replace most of the "last" stuff (pts & friends) in AVStream by a pointer to the last packet (since now it's ref counted)?
[19:14] <michaelni> i guess that should be possibe, does this simplify something ?
[19:15] <ubitux> i don't know, i was just wondering about the need to expose a new av_stream_get_end_pts()
[19:16] <ubitux> since api users can already keep the last packet with ref counting
[19:16] <ubitux> and iirc they're is not only the "end pts"
[19:16] <ubitux> i remember seeing other "last" stuff
[19:16] <ubitux> but i'm not familiar with that code
[19:18] <michaelni> well, api users cant get the last pts by just keeping the last packet before muxing when that packet had a AV_NOPTS_VALUE pts
[19:18] <michaelni> it would require some api from libavformat to keep a modified packet
[19:18] <ubitux> ok
[22:21] <cone-225> ffmpeg.git 03Michael Niedermayer 07master:ce4d91ba2a97: sws: document color range >8bit oddity
[23:10] <cone-225> ffmpeg.git 03Carl Eugen Hoyos 07master:afaa39b46dbc: Don't overwrite codec_id with 0 in ff_mp4_read_dec_config_descr().
[23:10] <cone-225> ffmpeg.git 03Anshul 07release/2.1:83f58778cb6a: ffprobe: fix crash happening because of new streams occuring
[23:10] <cone-225> ffmpeg.git 03Anshul 07release/2.2:acafd1814e68: ffprobe: fix crash happening because of new streams occuring
[23:57] <cone-225> ffmpeg.git 03James Almer 07master:7b05267239ed: x86/dsputil: port clear_block functions to yasm
[23:57] <cone-225> ffmpeg.git 03James Almer 07master:80ee2dfcf674: x86/dsputil: port ff_put_signed_pixels_clamped_mmx to yasm
[00:00] --- Thu May 22 2014