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

Sun Aug 18 02:05:02 CEST 2013

[00:14] <michaelni> llogan, you run it 
[00:14] <michaelni> and it creates tools/ffbisect
[00:18] <llogan> i figured out that part right after I asked.
[00:24] <llogan> michaelni: your compile benchmarks are almost a year old. have the times changed much since then?
[00:25] <michaelni> dunno, let me try
[00:28] <michaelni> gcc 4.6 --enable-gpl -> 0m42.779s
[00:29] <michaelni> so id say its still pretty accurate
[00:30] <michaelni> gcc 4.6 --enable-gpl --disable-debug --disable-optimizations -> 0m15.803s
[00:31] <llogan> eh, close enough
[00:32] <michaelni> gcc 4.5 --enable-gpl --disable-debug --disable-optimizations -> 0m15.901s
[00:33] <michaelni> i can rerun all if you think it makes sense ...
[00:35] <llogan> up to you
[00:35] <llogan> i'll update the page if you want to re-run them
[00:49] <michaelni>  --enable-gpl --disable-debug  --cc=gcc-4.5 0m35.061s
[00:51] <michaelni> --enable-gpl  --cc=gcc-4.5 0m42.026s
[00:53] <michaelni> --cc=gcc-4.5 --enable-gpl --disable-debug --disable-optimizations --extra-cflags='-O1' 0m23.473s
[00:55] <michaelni> --cc=gcc-4.4 --enable-gpl 0m42.787s
[00:57] <michaelni> --cc=gcc-4.4 --enable-gpl --disable-debug --disable-optimizations 0m15.643
[00:59] <michaelni>  --cc=/usr/bin/clang --enable-gpl --disable-debug --disable-optimizations 0m13.199s
[01:00] <michaelni> --cc=/usr/bin/clang --enable-gpl --disable-debug --disable-optimizations --extra-cflags='-O1' 0m18.819s
[01:01] <michaelni>  --cc=/usr/bin/clang --enable-gpl --disable-debug 0m22.653s
[01:02] <michaelni> --cc=/usr/bin/clang --enable-gpl 0m25.556s
[01:04] <michaelni> --cc=/usr/bin/clang --enable-gpl    ; time make fate -j12 0m53.423s
[01:06] <michaelni>  --cc=/usr/bin/clang --enable-gpl --disable-debug   ; time make fate -j12 0m51.460s
[01:08] <michaelni>  --cc=/usr/bin/clang --enable-gpl --disable-debug --disable-optimizations   ; time make fate -j12 1m24.252s
[01:11] <michaelni> --cc=/usr/bin/clang --enable-gpl --disable-debug --disable-optimizations  --extra-cflags='-O1'  ; time make fate -j12 0m47.401s
[01:13] <michaelni> --cc=clang --enable-gpl --disable-debug --disable-optimizations  --extra-cflags='-O1'  ; time make fate -j12 0m51.419s
[01:15] <michaelni> --cc=gcc-4.5 --enable-gpl --disable-debug --disable-optimizations  --extra-cflags='-O1'  ; time make fate -j12 0m51.920s
[01:19] <michaelni> --cc=gcc-4.5 --enable-gpl --disable-debug --disable-optimizations   ; time make fate -j12 1m27.695s
[01:21] <michaelni> --cc=gcc-4.5 --enable-gpl --disable-debug    ; time make fate -j12 1m3.025s
[01:23] <michaelni> --cc=gcc-4.5 --enable-gpl    ; time make fate -j12 1m9.592s
[01:49] <cone-741> ffmpeg.git 03Michael Niedermayer 07master:eeb3fb9e62d4: ffv1enc: check for malloc failure
[01:49] <cone-741> ffmpeg.git 03Michael Niedermayer 07master:c8d89be477ac: ffv1enc: propagate error code from write_extradata()
[01:49] <cone-741> ffmpeg.git 03Michael Niedermayer 07master:2c1a215ddb8b: ffv1: update years in header
[02:14] <BBB> ubitux: the rest is b/c of the switch statement, gcc doesn't know there's only 4 possible labels there
[02:15] <ubitux> i didn't look
[02:15] <ubitux> at all :p
[02:16] <BBB> ubitux: and the have_topright is indeed broken
[02:18] <BBB> ubitux: http://pastebin.com/Kcza73EL ?
[02:23] <ubitux> BBB: doesn't build; have_topright is used elsewhere
[02:23] <BBB> oh
[02:23] <ubitux> L1117,             (tx != TX_4X4 || !edges[mode].needs_topright || have_topright)) {
[02:27] <BBB> right
[02:27] <BBB> one sec
[02:27] <BBB> too many changes related to inter coding so it didn't build anyway
[02:27] <BBB> http://pastebin.com/U4pLUkwJ ?
[02:28] <BBB> I still have to parse motion vectors in the bitstream, and do neighbourhood motion vector search for referencing
[02:28] <BBB> then inter frame parsing is done and I can move on to inter reconstruction (but I'll probably commit the parsing already at that point, assuming it doesn't just crash)
[02:30] <ubitux> still crashes
[02:32] <ubitux> seems to happen with ffplay in particular
[02:33] <ubitux> anyway, i still have 4/6 functions to write
[02:33] <BBB> oh ffplay
[02:33] <BBB> hm...
[02:33] <BBB> I only test ffmpeg
[02:33] <BBB> ffmpeg -i vp9file.webm -vframes 1 out.y4m
[02:34] <BBB> that works for me
[02:34] <ubitux> i changed the logic with the 2 functions so we can use memcpy for writing; and logic is quite simple to ease auto unrolling
[02:34] <ubitux> yeah
[02:34] <BBB> memcpy for writing?
[02:34] <ubitux> yes
[02:34] <ubitux> i mean
[02:34] <ubitux> just a sec
[02:34] <BBB> I think I know what you mean
[02:34] <BBB> it's what simd functions do
[02:34] <BBB> is it faster?
[02:34] <ubitux> didn't bench at all
[02:35] <ubitux> but code is short and pretty straightforward
[02:35] <BBB> (the reason it might not be is b/c it requires 2 mem access instead of 1 for the current code)
[02:35] <BBB> hm ok
[02:35] <ubitux> i use a "rolling buffer" which i memcpy
[02:36] <BBB> right, that's what simd does
[02:36] <ubitux> in libvpx?
[02:36] <BBB> and then shift by 1-2 bytes depending on what version
[02:36] <BBB> in ffmpeg also
[02:36] <BBB> see e.g. h264/vp9
[02:36] <BBB> er, vp8
[02:36] <ubitux> ah, fun ok
[02:36] <ubitux> i also use a memset in the first func
[02:37] <ubitux> https://github.com/ubitux/FFmpeg/blob/vp9/libavcodec/vp9dsp.c#L589
[02:37] <ubitux> https://github.com/ubitux/FFmpeg/blob/vp9/libavcodec/vp9dsp.c#L625
[02:37] <ubitux> so anyway, i'll do that for the others; and if it's not slower we can use it for the c 32x32 only
[02:37] <BBB> can do memset outside the loop
[02:38] <BBB> just set the buf as-is, and make it twice as big, and memset the rest with top[size-1]
[02:38] <BBB> then just index as &v[y] as src for memcpy
[02:38] <ubitux> i thought it was likely faster to memset instead of re-reading N times the same value
[02:38] <ubitux> but didn't bench anyway so..
[02:38] <BBB> :)
[02:38] <BBB> well anyway yeah this is fine
[02:39] Action: Compn remembers someone long ago saying something about memset not being fastest
[02:39] <BBB> the others are slightly more complex b/c the memset approach only works for the outer two
[02:39] <Compn> or memcpy
[02:39] <BBB> Compn: we'll write simd
[02:39] <BBB> so it's ok
[02:39] <BBB> this is just for the reference
[02:39] <ubitux> BBB: yeah i'm wondering about the next one
[02:39] <ubitux> BBB: but we can do it with 2 buffers
[02:39] <ubitux> 2 interleaved rollings buffers should work
[02:39] <ubitux> at least for the next one :p
[02:40] <BBB> next 2
[02:40] <ubitux> :)
[02:40] <BBB> yes that's what simd does for vert_left/right
[02:40] <ubitux> am i re-inventing the wheel?
[02:40] <BBB> and then for horiz_up/down, it uses 1 buffer which is 4x as big, and shifts index by 2 instead of 1 per line
[02:40] <ubitux> we already have that same code? :)
[02:40] <BBB> in simd
[02:40] <BBB> not in c
[02:41] <BBB> I don't think anyone ever cares about c :-p
[02:41] <ubitux> :D
[02:41] <BBB> because in practice it doesn't run
[02:41] <ubitux> that's a good reason to re-roll them then
[02:42] <BBB> http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=blob;f=vp9/common/x86/vp9_intrapred_ssse3.asm;h=8ba26f310990ee2a651a8460ed31edb0923f4c21;hb=HEAD#l114
[02:43] <BBB> yeah I guess I agree
[02:43] <BBB> just as an indication of how many instructions these functions are in simd
[02:43] <ubitux> ok :)
[02:44] <BBB> I think I wrote versions of all these functions but theyre' sitting in a patch tracker somewhere while I am on vacation
[02:44] <BBB> you read assembly right?
[02:45] <Daemon404> [20:41] <@BBB> I don't think anyone ever cares about c :-p <-- mobile world would likely disagree
[02:45] <BBB> mobile world uses neon
[02:45] <BBB> not c
[02:45] <ubitux> BBB: a bit; aka it takes me a long time to read simd, and i can read simple compiler assembly relatively easily
[02:45] <Daemon404> BBB, nobody writes neon for libav*
[02:45] <Daemon404> hence. c.
[02:46] <BBB> then nobody in the mobile world uses libav*
[02:46] <BBB> if they used it, they'd write neon code for it
[02:46] <Daemon404> it's pretty popular
[02:46] <BBB> (note mru works on libvpx right now)
[02:46] <Daemon404> oic
[02:46] <Daemon404> that makes more sense
[02:47] <Daemon404> since there is no vp8/9 hw
[02:48] <BBB> ubitux: but yes I like this
[02:58] <BBB> ubitux: ok found the issue
[02:59] <BBB> ubitux: it was another memcpy I think, valgrind found it for me
[02:59] <BBB> ubitux: valgrind is clean again now
[02:59] <ubitux> yeah i believe pasted you the valgrind ;)
[02:59] <ubitux> thx :)
[02:59] <ubitux> will retry, but it's late now, so tomorrow
[03:00] <BBB> ubitux: well yes your valgrind didn't help b/c my line numbers are different
[03:00] <BBB> (that happens when you add a ton of code)
[03:01] <BBB> anyway it showed me valgrind is sweet so I gave it a chance
[03:02] <BBB> and g'nite
[03:27] <ruby> Hi I am looking for Nicolas Bertrand
[03:27] <ruby> Does anyone know his irc nick?
[03:27] <Compn> hmm
[03:27] <Compn> dont remember it
[03:29] <kierank> ruby: buxiness
[03:31] <ruby> kierank: Thank you!
[04:29] <KGB> 01[13FFV101] 15michaelni pushed 1 new commit to 06master: 02http://git.io/FmrKAw
[04:29] <KGB> 13FFV1/06master 14cca0bab 15Michael Niedermayer: Update minor_version...
[10:36] <cone-322> ffmpeg.git 03Luca Barbato 07master:c59967fa7cc5: h261: check the mtype index
[10:36] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:bd7107106660: Merge commit 'c59967fa7cc5bc2fa06b36c17d2c207240c06b3e'
[11:41] <durandal_1707> michaelni: gonna commit that license thing?
[11:51] <cone-322> ffmpeg.git 03Luca Barbato 07master:5ef7c84a9374: dxa: Make sure the reference frame exists
[11:51] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:7a342f97c48f: Merge remote-tracking branch 'qatar/master'
[11:51] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:186e47ef6d7d: dxa: only fail with an error about reference frames if the reference frame would be used
[11:51] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:9640ea1da4e0: dxa: fix support of decoding all frames even in the absence of references
[12:09] <michaelni> durandal_1707, that kind of change is for the community to decide and apply (or not apply)
[12:15] <durandal_1707> define 'community', define 'decide'
[13:01] <ubitux> BBB: no more crashes, thx :)
[13:06] <ubitux> btw, http://wiki.libsdl.org/moin.fcg/MigrationGuide
[13:07] <ubitux> might be relevant for ffplay
[13:19] <durandal_1707> too late
[14:38] <durandal_1707> anyone need replaygain scanner?
[15:19] <cone-322> ffmpeg.git 03Stephen Hutchinson 07master:2c25e83b1d02: avisynth: Support video input from AviSynth 2.5 properly.
[15:19] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:0a141b0e49ba: avcodec/dxa: Support printing picture debug info
[20:03] <xlinkz0> If I cut on timestamps that do not correspond to keyframes and try to use those segments with the concat demuxer the resulting file is not linear
[20:03] <xlinkz0> I suspect this is because of the metadata of the cut files
[20:03] <xlinkz0> is this a known issue? does it have a workaround?
[20:10] <xlinkz0> does anyone know how i can modify this metadata? Duration: 00:01:04.00, start: -3.978667
[20:10] <xlinkz0> to test if this is the problem with the concat demuxer
[22:02] <ragedragon> Hello the room, does one of you know please i have got this error:
[22:03] <ragedragon> ...libavformat.a(swfdec.o): In function `swf_read_packet': ..... libavformat/swfdec.c:328: undefined reference to `uncompress'
[22:04] <ragedragon> + a long list of fail
[22:04] <ragedragon> s
[22:04] <ragedragon> tried to compil mlt 0.9 with external build of ffmpeg-2.0 (not distro repo)
[22:05] <Compn> ragedragon : sounds like missing zlib ?
[22:07] <ragedragon> checking...
[22:07] <ragedragon> i think zlib is present...
[22:08] <ragedragon> pkg-config --cflags --libs zlib indicates me: -lz
[22:09] <ragedragon> trying to put the error output into pastebin...
[22:17] <cone-322> ffmpeg.git 03Reinhard Tartler 07release/0.5:2abf5eeea6e4: update year to 2013
[22:17] <cone-322> ffmpeg.git 03Reinhard Tartler 07release/0.5:588571d41ddb: Bump version number for the 0.5.11 release
[22:17] <cone-322> ffmpeg.git 03Michael Niedermayer 07release/0.5:b5f685211cd4: Merge remote-tracking branch 'qatar/release/0.5' into release/0.5
[22:25] <ragedragon> Compn, http://pastebin.com/ZvQ5Ft0E
[22:25] <ragedragon> any idea please?
[22:27] <ragedragon> i'm now wondering if i need to use an old version of ffmpeg with the last release of mlt
[22:28] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:a0c6c8e53ebc: Revert "Merge commit of 'vdpau: remove old-style decoders'"
[22:28] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:6e4b9b8a2fb5: avcodec: fix compilation without vdpau
[22:29] <wm4> uh what
[22:29] <wm4> old style vdpau decoders are back?
[22:30] <ubitux> "Keeping support for the old VDPAU API has been requested by our VDPAU maintainer"
[22:34] <wm4> and who is that?
[22:35] <ubitux> i'd say Carl according to /MAINTAINERS
[22:36] <wm4> well, why do I care, not my mess to maintain
[23:02] <ragedragon> Compn, you right... -lz was missing into one of makefile present into mlt...
[23:13] <Compn> cool
[23:58] <durandal_1707> thing is i need to recompile whole tree again because adding back stuff that nobody uses
[00:00] --- Sun Aug 18 2013