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

[burek]

[00:02] <cone-662> ffmpeg.git 03Paul B Mahol 07master:2a7545951926: pngdec: do not release buffer on failure instead report full progress
[00:21] <wm4> lol that youtube patch
[00:22] <wm4> converted from a perl script
[01:11] <cone-662> ffmpeg.git 03Michael Niedermayer 07master:3941a4f5c2a4: snowenc: change a bunch of assert() to av_assert()
[01:11] <cone-662> ffmpeg.git 03Michael Niedermayer 07master:5cc8b816875d: mpeg4videodec: fix GEOV/GEOX fliping
[01:22] <durandal_1707> oh why lavc needs to do flipping?
[01:22] <cone-662> ffmpeg.git 03Paul B Mahol 07master:83b915d495ea: truemotion1: use av_freep()
[01:22] <cone-662> ffmpeg.git 03Paul B Mahol 07master:b8ff4f5ea3d3: truemotion1: check av_fast_malloc() return value
[01:26] Action: durandal_1707 wonders why vp3.c does not have K&R commit
[01:27] <ubitux> better delete it
[01:27] <ubitux> "it's too ugly"
[01:27] <durandal_1707> why, only theora part looks ugly
[01:27] <ubitux> dunno
[01:28] <ubitux> havent opened the file
[02:27] <BBB> ubitux: uses two predictors instead of one (like B-frame prediction in classic MPEG-like codecs; in vp9, this is a per-partition/per-block decision)
[02:27] <BBB> ubitux: and the references to predict from are stored in b->ref[0] and b->ref[1]
[03:12] <ubitux> BBB: you mean if b->comp is set, it means picking from 2 different references instead of one?
[03:12] <BBB> yes
[03:13] <BBB> we have dsp->mc[6-log2sz][filter][0=put,1=avg][xfilter][yfilter]()
[03:13] <BBB> 0=put is first reference, 1=avg is second reference
[03:14] <ubitux> if there is a second one it's doing an average between the two i guess?
[03:14] <ubitux> (50-50?)
[03:14] <BBB> yes
[03:15] <BBB> think of it as two separate predictor filters (with separate MVs), and then averaging between the two as (a+b+1)>>1
[03:15] <BBB> in simd, it's faster to do one store, then a load, avg, store, rather than two stores, two loads, avg, store
[03:15] <BBB> so that's why it's implemented like this
[03:15] <BBB> but it does the same thing
[03:38] <ubitux> BBB: btw, mmh, there is no 10-bit with vp9?
[03:38] <ubitux> (yeah totally unrelated i know)
[03:39] <BBB> no
[03:40] <ubitux> do you know the reasons?
[03:45] <BBB> I think it's planned for a future extension profile or something along those lines
[03:46] <ubitux> ah, cool, ok
[03:46] <BBB> just like the current profile is 420 only and 3-plane only (yuv), but the codebase already supports 444 and alpha, which are also planned for stabilization in a future profile
[03:47] <ubitux> yeah, ok
[03:48] <ubitux> michaelni: please use FF_CEIL_RSHIFT :(
[03:49] <ubitux> (in reference to 5cc8b8168)
[03:50] <michaelni> ubitux, you could write a cronjob that does a checkout, replaces them and commits it and sends me a pull req :)
[03:50] <ubitux> yeah that sounds like the most optimal way :D
[03:53] <cone-662> ffmpeg.git 03Michael Niedermayer 07master:9a271a9368ea: jpeg2000: check log2_cblk dimensions
[04:15] <cone-662> ffmpeg.git 03Michael Niedermayer 07master:b99d3613cfdb: avcodec/h263dec: use FF_CEIL_RSHIFT()
[04:25] <BBB> ubitux: also I think I may soon have all keyframes decoding correctly in terms of giving same output as libvpx
[04:29] <kierank> 02:38:53 <"ubitux> BBB: btw, mmh, there is no 10-bit with vp9? --> not much point
[06:50] <BBB> ubitux: ok, all non-emuedge fate tests I added pass now; still a few emuedge bugs remaining, will fix those next
[06:50] <BBB> ubitux: any progress on your end?
[11:21] <cone-129> ffmpeg.git 03Diego Biurrun 07master:8506ff97c9ea: vp56: Mark VP6-only optimizations as such.
[11:21] <cone-129> ffmpeg.git 03Michael Niedermayer 07master:f9418d156fe6: Merge commit '8506ff97c9ea4a1f52983497ecf8d4ef193403a9'
[11:27] <BBB> what was the method again to use valgrind for all fate tests?
[11:30] <cone-129> ffmpeg.git 03Diego Biurrun 07master:84784c297fe6: libfdk-aacdec: formatting cosmetics
[11:30] <cone-129> ffmpeg.git 03Michael Niedermayer 07master:edf6fb64e07c: Merge commit '84784c297fe6a6e538a7e111dcdbd8b893c2d275'
[11:40] <michaelni> BBB, --valgrind=valgrind
[11:43] <cone-129> ffmpeg.git 03Diego Biurrun 07master:f407856968dc: arm: h264chroma: Do not compile h264_chroma_mc* dependent on h264 decoder
[11:43] <cone-129> ffmpeg.git 03Michael Niedermayer 07master:6067186f3a76: Merge remote-tracking branch 'qatar/master'
[14:50] <wm4> ubitux: the webvtt patch has bogus OOM handling; it should do av_free_packet(pkt) instead of av_free(pkt), right?
[14:51] <wm4> or, that should be additional
[14:52] <wm4> it also doesn't check av_malloc return values
[15:50] Action: BBB pokes ubitux 
[16:09] <ubitux> BBB: yeah i think i start to get it, but it takes me some time
[16:09] <BBB> ok
[16:09] <ubitux> wm4: no idea, will look later eventually
[16:09] <ubitux> BBB: why the 4 inter pred modes start at 10?
[16:10] <BBB> so they can be used in the same context as intra modes (of which there are 10)
[16:10] <BBB> if we can somehow separate that, then I'm fine with removing that
[16:12] <ubitux> ah ok; it would have been more obvious if that enum was in vp9.h below its brother (and eventually using N_INTRA_PRED_MODES as start value)
[16:13] <ubitux> i see 16 intra pred modes though
[16:13] <ubitux> (maybe that was supposed to be 0x10?)
[16:19] <ubitux> BBB: am i missing sth obvious?
[16:23] <ubitux> on a side note, it would be nice to have some prefix for inter & intra pred mode macro
[16:27] <BBB> ubitux: 10 are coded, the rest are inferred
[16:27] <BBB> naming is just to be consistent with h264pred.h and vp8.h
[16:28] <BBB> eventually I'd like to merge these kind of things
[16:28] <BBB> ubitux: basically there's 10 modes
[16:28] <BBB> ubitux: but some modes mean something different depending on which edges are available
[16:28] <BBB> ubitux: e.g. DC on top row means something else than DC in the middle of the image
[16:29] <ubitux> oh, ok
[16:29] <BBB> so for code simlicity (simd) reasons, we do that branch in the calling code, and thus add extra intra modes which we use if the coded mode is dc but not all edges are available
[16:29] <BBB> so that's dc_top, dc_left, dc_128
[16:29] <BBB> then dc_127/dc_129 are just variations thereof (vp9 defines dc with no edges as 128, but the top edge is 127 and the left edge is 129 for all other intra pred modes
[16:30] <BBB> vp8 did that too
[16:30] <ubitux> ok
[16:30] <BBB> so b->mode is only 0-9
[16:30] <BBB> but the intra pred simd functions can be called with 0-14
[16:38] <BBB> my todo list is shrinking quite quickly now
[16:38] <BBB> nice
[16:40] <ubitux> BBB: i don't get the difference between NEAREST and NEAR mv
[16:40] <ubitux> is it related to the reference used?
[16:41] <ubitux> zeromv is suppose that's the latest one (no further sub division), and newmv is the opposite (a subdivision, so in case of 8x8 the latest possible 4 partitions?)
[16:41] <BBB> it's what motion vector you use
[16:41] <ubitux> s/is supposed/i suppose/
[16:41] <BBB> ZEROMV means the motion vector is y=0, x=0
[16:41] <BBB> NEWMV means we code an actual motion vector difference in the bitstream using NEARESTMV as a reference
[16:42] <BBB> NEARESTMV is whatever is the first motion vector returned from find_ref_mvs()
[16:42] <BBB> NEARMV is the second motion vector returned from find_ref_mvs()
[16:43] <ubitux> ah.
[16:43] <BBB> the first/second motion vector simply are unique MVs found in surrounding blocks
[16:43] <BBB> first the left neihgbour, then the top, then the topleft, then those further away
[16:43] <BBB> see the table in find_ref_mvs()
[16:43] <BBB> we first try to find one that uses the same reference as us
[16:44] <BBB> if that didn't work, we look for ones that use a different reference
[16:44] <BBB> larger blocks use a larger neighbourhood search radius, so to say, so they more sparsely look in blocks that are located further away
[16:45] <BBB> then once you know your motion vector, the rest is straightforward
[16:46] Action: BBB goes to bed
[16:47] <ubitux> ok thx, 'night :)
[19:06] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:7495186fd49f: avcodec/h263dec: fix aspect of lead h263 EHC
[20:00] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:5c6a58746b41: ffplay: make next_nb_channels[] static const
[22:13] <ubitux> BBB: ping
[23:13] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:f55a7ba0376d: avcodec/ituh263dec: detect and warn about RTP
[23:28] <cone-549> ffmpeg.git 03Michael Niedermayer 07master:88909beca39e: avcodec/movenc: move chapter_properties under the #if of the code that uses it
[23:31] <ubitux> michaelni: avformat*
[23:36] <michaelni> ^^;;
[00:00] --- Sun Aug 25 2013