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

[burek]

[03:07] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:98fd8a78487f: avcodec: Remove ff_packet_free_side_data, use av_packet_free_side_data
[04:11] <cone-455> ffmpeg.git 03Thilo Borgmann 07master:f18ccb529fb7: Fix wrong use of "an" in some comments.
[05:41] <BBB> Daemon404: ubitux: ok at this point loopfilter gives me almost correct (1 pixel off in first frame of vp90-02-size-64x64.webm Y plane; UV still completely broken)  output; any update on your stuff?
[06:06] <Daemon404> BBB, sorry ive lacked PRs... moving is more work than i anticipated
[06:06] <Daemon404> <-- n00b
[06:06] <Daemon404> (also laziness... :x)
[06:54] <BBB> moving n00b?
[06:54] <BBB> weird
[07:18] <Daemon404> BBB, indeed -- first permanent move
[07:18] <Daemon404> between countries
[07:18] <BBB> ok I guess
[07:19] <Daemon404> [00:06] <@Daemon404> (also laziness... :x) <--
[07:35] <BBB> Daemon404: ubitux: ok lf works now
[07:35] <BBB> ubitux: Daemon404: wanna review or can I commit?
[07:41] <Daemon404> its a WIP branch, commits are 'free'
[07:50] <BBB> ok pushed
[07:50] <BBB> hope that doesn't screw up other things but we'll see
[07:50] <BBB> so... inter coding now?
[07:51] <BBB> how far's your wip?
[07:54] <Daemon404> not far. im basically just not home ever. its scrapable if its holding people back.
[07:54] <BBB> hm... ok
[07:54] <BBB> ubitux: yt?
[09:50] <ubitux> BBB: here i am
[09:50] <ubitux> no update on my side
[09:51] <ubitux> i guess i'm gonna start trying to fill the 6 pred func, or there are other priorities?
[09:53] <BBB> ubitux: inter coding?
[09:53] <BBB> ubitux: I guess I'll start bitstream parsing for inter coding then
[09:53] <BBB> that way we don't overlap
[09:56] <BBB> ok added a slightly more simd-efficient way of doing loopfilter
[09:56] <BBB> still not perfect, but good enough for now
[09:56] <BBB> will do inter bitstream parsing now
[10:04] <ubitux> is the lf of vp9 special?
[10:04] <ubitux> i mean in comparison to some other codecs
[10:06] <BBB> not really
[10:06] <BBB> you just need to make sure to do it in the correct order, and not do the same lf twice
[10:10] <BBB> more details: the lf acts on 8px edges; adjecent edges can use the same lf settings, in which case you could (using 16byte sse2 simd instructions) do 16px at a time (instead of only 8, using mmx/mmx2 instructions)
[10:11] <BBB> avx2 would allow 32 maybe, haven't looked into it yet
[10:12] <BBB> need hardware anyway
[10:12] <ubitux> :)
[10:13] <BBB> the benefits are obviously doing more pixels in ~~same amount of instructions == ~~same amount of cycles/time
[10:16] <ubitux> BBB: can you tell me in a few hint words in what sense the intra pred code is different from libvpx?
[10:17] <BBB> ffvp9 vs libvpx?
[10:17] <BBB> I tried to mimic the code in h264pred.c
[10:17] <BBB> it's unrolled, basically
[10:20] <ubitux> h264 only goes up to 8x8?
[10:21] <ubitux> ah i see some 16x16 too
[10:21] <ubitux> but they are not unrolled for those
[10:22] <BBB> they are only h, v
[10:22] <BBB> not directional
[10:22] <BBB> do whatever is easier to code, there's some easy ways to write the directional ones as a loop
[10:23] <ubitux> 16 funcs are starting to be pretty huge unrolled
[10:23] <BBB> vp90-2-00-quantizer-23.webm uses one of the 32x32 directional intra predictors if you want a sample
[10:23] <ubitux> i'm not sure it's wise to unroll the 32 as well
[10:23] <ubitux> ok
[10:23] <BBB> it's up to you, you're the implementer :)
[10:24] <BBB> the libvpx c code is kind of slow, you can write it as a loop and still be a lot faster
[10:24] <BBB> it depends on how much code you want to write
[10:24] <BBB> and yes the 16x16 ones are not small, I'm aware of that and not necessarily liking it, but it's ok for now I guess
[10:26] <ubitux> ok ok, thx for the help
[10:26] <ubitux> gonna get up, and look at that today
[10:28] <cone-682> ffmpeg.git 03Hendrik Leppkes 07master:3ca5df36a50e: wmall: use AVFrame API properly
[10:28] <cone-682> ffmpeg.git 03Michael Niedermayer 07master:c103d5f538d9: Merge remote-tracking branch 'qatar/master'
[10:29] <BBB> in fact a lot of the vp90-2-00-quantizer-*.webm files use 32x32 intra predictors
[10:29] <BBB> probably good for some basic unit tests
[10:29] <BBB> also reminds me of a bug in the loopfilter/intra mixing which I guess I'll fix soon
[11:35] <durandal_1707> how one would handle mt in png decoder for this abdomination of non-keyframes?
[11:36] <durandal_1707> and not breaking performance with frame multithreading of normal pngs
[12:13] <BBB> durandal_1707: just handle them specially
[12:13] <BBB> durandal_1707: i.e. if keyframe-png, multithread as images. if not, multithread more specially
[12:15] <durandal_1707> what specially?
[12:16] <durandal_1707> non-key frames need previous frame - this just makes frame multithreading near useless
[12:17] <BBB> right, that's why codecs like h264 use frame-mt
[12:18] <durandal_1707> but how?
[12:19] <BBB> why don't you read the code
[12:20] <BBB> (I'm willing to explain if you really don't know, but you're typically not every interested in being lectured, so I won't bother if you don't care)
[12:22] <cbsrobot> BBB I guess you mean slice-mt &
[12:22] <BBB> no
[12:22] <BBB> I mean frame-mt
[12:23] <durandal_1707> why you think I'm not interested in being lectured?
[12:23] <BBB> commit 6a9c85944427e3c4355bce67d7f677ec69527bff
[12:23] <BBB> Author: Alexander Strange <astrange at ithinksw.com>
[12:23] <BBB>     H264/MPEG frame-level multi-threading.
[12:23] <BBB> cbsrobot: ^^
[12:24] <BBB> durandal_1707: I still don't know if that means yes please or no thankyou
[12:24] <cbsrobot> BBB I know, I just misread
[13:36] <durandal_1707> BBB: i'm really not interested in your subjective perspection
[14:51] <cone-301> ffmpeg.git 03Paul B Mahol 07master:9087dcbe5b7e: lavfi/trim: check for right default value
[14:51] <cone-301> ffmpeg.git 03Paul B Mahol 07master:d4ab1292e9ac: ffmpeg_filter: do not pick evil path for trim filters
[18:17] <cone-301> ffmpeg.git 03Kirill Gavrilov 07master:2395ae22ce8b: img2dec: fix typo (double "with with")
[18:18] <cone-301> ffmpeg.git 03Kirill Gavrilov 07master:53f309c61739: pixfmt: extend description for planar YUV 9/10 bits formats
[19:49] <burek> we could use youtube to showcase multiple cases of ffmpeg filters in action and make it cool, just for fun :)
[19:50] <burek> i mean, create multiple videos, showing ffmpeg filters in action, which look very cool and stuff
[19:50] <burek> create an ffmpeg youtube channel, etc.
[19:50] <durandal_1707> you gonna do this?
[19:51] <burek> man, you really know how to kill the great idea :D
[19:51] <durandal_1707> it is really great idea, there are many more great ideas too
[19:51] <burek> actually I just might do it :)
[19:51] <burek> do we have any kind of repository with video samples and stuff
[19:52] <burek> btw, it appears that av_seek_frame has got a bug
[19:52] <burek> which im not gonna report
[19:53] <burek> at least not on cehoyos' bug tracker
[19:53] <burek> http://ffmpeg.gusari.org/viewtopic.php?f=16&t=1011
[19:53] <durandal_1707> but i just wanted to say you should report youtube as bug ;-/
[19:54] <burek> they are fixing it every day :)
[19:56] <wm4> seeking is often quite buggy
[19:56] <wm4> it's probably the most buggy part of libavformat
[19:57] <wm4> I suspect the main reason is that ffmpeg.c barely needs seeking, and seeking with ffplay is awkward at best
[19:57] <wm4> so ffmpeg devs rarely test it
[19:57] <burek> oh ok
[20:03] <nevcairiel> seeking in files with timestamps or even an index usually works OK in my experience. files without either are not so good indeed.
[20:11] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:e1c44be80233: doc/filter_design.txt: Fix duplicate words
[20:11] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:a8163a786bcb: doc/filters.texi: Fix duplicate words
[20:11] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:7fabf3a4b71c: libavcodec/ac3enc_template.c: Fix duplicate words
[20:11] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:f10462377d93: libavcodec/ac3tab.c: Fix duplicate words
[20:11] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:9da6e742f45a: libavcodec/avcodec.h: Fix duplicate words
[20:11] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:c77c5f6c9f5b: libavcodec/bink.c: Fix duplicate words
[20:11] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:805fbbefb3a8: libavcodec/bintext.h: Fix duplicate words
[20:12] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:e458fd6cf9ca: libavcodec/dv.c: Fix duplicate words
[20:12] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:1e6816dcda7f: libavcodec/lpc.h: Fix duplicate words
[20:12] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:c6325e50dd12: libavcodec/mpegvideo.h: Fix duplicate words
[20:12] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:ad26aa362389: libavcodec/rv40.c: Fix duplicate words
[20:12] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:5347de881bf1: libavcodec/xsubenc.c: Fix duplicate words
[20:12] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:5086b26809bc: libavutil/file_open.c: Fix duplicate words
[20:12] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:3500f53c9375: libavutil/opt.h: Fix duplicate words
[20:13] <durandal_1707> use single one for such cosmetics
[21:05] <tborg> my nickname is registered?
[21:06] <tborg> can anyone read me? does anyone know what this means? WHO has registered this nick?
[21:07] <iive> we read you
[21:07] <tborg> thanks for replying. I'm relieved (a bit)
[21:09] <tborg> Don't we care for "Libav" in licence headers all over the place? (see your own grep) 
[21:10] <durandal_1707> why care?
[21:11] <tborg> If we do accept wrong license headers why care for them in the first place?
[21:12] <durandal_1707> how they are wrong?
[21:14] <tborg> the inconsistence in licenses like: "This file is part of FFmpeg/Libav."
[21:17] <durandal_1707> well if original file that got merged have such license, why it should be changed?
[21:19] <tborg> so we have 132 original files merged from Libav?
[21:23] <durandal_1707> you sure 132 is correct number?
[21:24] <ubitux> i believe the rule currently followed is: file originating from libav have header kept, otherwise it's set to FFmpeg
[21:24] <durandal_1707> but michaelni changed some of them ....
[21:24] <tborg> 113 if grepped more strictly: grep -i 'part of \<libav\>' `find . -iname '*.c' -o -iname '*.h'` | cut -f 1 -d ":" | uniq | wc -l
[21:24] <ubitux> some changes were done where libav actually changed FFmpeg to Libav, so that was reverted
[21:24] <ubitux> in case the code originated from FFmpeg
[21:28] <durandal_1707> and in some cases michaelni changed it to FFmpeg
[21:28] <tborg> so e.g. libavformat/network.c was originally created by Libav in 2007, eh?
[21:29] <ubitux> i guess it was a mistake during one of those merge/rename commit
[21:31] <ubitux> basically if you want to change that i would suggest a case by case, assuming you think it's really worth the effort spending time fixing these
[21:35] <tborg> I think it might be worth writing a script
[21:35] <ubitux> hf :p
[21:36] <durandal_1707> and do it with each file separate commit - so that it appears its very important
[21:37] <ubitux> so much bitterness... :))
[21:37] <durandal_1707> its candy
[21:38] <tborg> so much sweetness then? maybe it'll do a file separate pull-request to libav-devel...
[21:38] <tborg> cheers
[21:39] Action: ubitux wonders what just happened
[21:40] <durandal_1707> perhaps he realized how such thing is absurd
[21:41] <durandal_1707> personally i prefer consistency, and current situation is just confusing
[21:43] Action: ubitux really doesn't care
[22:38] <durandal_1707> huh, some people really get too much confused
[22:39] <Daemon404> ooo i missed drama?
[22:40] <durandal_1707> i'm not talking about useless drama...
[23:53] <cone-301> ffmpeg.git 03Michael Niedermayer 07master:4b101ab02ea7: avformat/asfdec: call ff_read_frame_flush() in asf_read_pts()
[00:00] --- Tue Aug 13 2013