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

[burek]

[00:06] <Compn> durandal_1707 : lol
[00:06] <Compn> durandal_1707 : multiple people asked for more changelog when ffmpeg changes default behavior
[00:19] <BBB> ubitux: I would maybe prefer a multidimensional array, that makes the shifting unnecessary
[00:19] <BBB> ubitux: looks really good otherwise
[00:20] <BBB> ubitux: also the idea was to use that same design concept for other ones in that function also
[00:20] <BBB> ubitux: (if it's faster)
[00:24] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:e07ac727c1cc: avcodec/g2meet: Fix framebuf size
[00:25] <BBB> ubitux: maybe the multidimensional array would make the table a lot clutterier, not sure... 
[00:26] <BBB> ubitux: also a suggestion to make table smaller: ref has a value 0-2 and intra has a value 0 or 1, you can use these together to make a 2bit value (intra ? 0 : 1+ref), makes it smaller
[00:27] <BBB> ubitux: then you get a 7bit table instead of 9bit
[00:28] <BBB> ubitux: and the edge tables become 4bit instead of 5
[00:55] <durandal_1707> michaelni: why are you adding hacks to g2meet?
[01:01] <Compn> durandal_1707 : should he pm kshishkov to fix it ?
[01:01] <Compn> iirc kshishkov wasnt interested in g2m crap anymore
[01:01] <Compn> or is this a 'why add hacks instead of spending 20 hours to fix it properly, without a sample' type of bikeshed ?
[01:01] <durandal_1707> it could just error out
[01:02] <Compn> he said that in the commit message
[01:02] <durandal_1707> this (without in deepth looking) just band-aid certain file on trac
[01:02] <Compn> i like it when ffmpeg tries to decode instead of failing 'error out'
[01:02] <durandal_1707> yes, but instead it allocates bigger buffer
[01:03] <durandal_1707> file on trac is some fuzzed nonsense
[01:03] <Compn> good points, no idea
[01:03] <durandal_1707> so even if buffers are bigger, is overread really fixed?
[01:03] <Compn> averror invaliddata ?
[01:05] <durandal_1707> it does not need to abort decoding, it just should not overread/write
[02:03] <durandal_1707> michaelni: ffmpeg -f lavfi -i testsrc -qmin 0 -qmax 0 -vcodec mjpeg -f null -  <---- I get floating exception
[02:42] <michaelni> <durandal_1707> it does not need to abort decoding, it just should not overread/write
[02:43] <michaelni> thats what the thing you call "hack" does
[02:45] <michaelni> the code works in 16x16 blocks and unless you want to support decoding such blocks in a way that accesses less than 16x16 the buffer has to be big enough for that
[09:42] <ubitux> BBB: ah indeed we can reduce a lot the lut
[10:02] <ubitux> i wonder up to how many dimensions the multi dimensional lut is interesting
[10:02] <ubitux> aka v = lut[a][b][c][d][e][f]; vs v = lut[a<<SA | b<<SB | c<<SC | d<<SD | e<<SE | f<<SF];
[10:02] <ubitux> like, how sane the generated asm will be with the multi-dim
[10:22] <ubitux> http://pastie.org/8345851
[10:22] <ubitux> not sure which is best, but the flat one looks sexy 
[10:23] <ubitux> BBB: i think i'll keep the flat layout
[10:23] <ubitux> unless you mind
[10:28] <ubitux> it's not always a pow of two though.
[11:44] <cone-712> ffmpeg.git 03Kieran Kunhya 07master:e208e6d20972: lavu: Add interleaved 4:2:2 8/10-bit formats
[11:44] <cone-712> ffmpeg.git 03Kieran Kunhya 07master:90ca5a9b5fc3: Add interleaved 4:2:2 8/10-bit formats
[11:44] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:8310bccc9116: avutil/pixdesc: try to fix NV20* descriptors
[11:44] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:85f8a3cb50c3: Merge commit 'e208e6d209728d332343aa5390ae377ac0a6305c'
[12:10] <cone-712> ffmpeg.git 03Alex Smith 07master:08fa828b3fe2: avutil: Fix compilation with inline asm disabled on mingw
[12:10] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:361bc707319d: Merge remote-tracking branch 'qatar/master'
[12:23] <TheRyuu> https://privatepaste.com/05d42f9cc1 <---is there something wrong with the syntax here?
[12:24] <nevcairiel> it doesnt like absolute path because of the :
[12:24] <nevcairiel> since thats the option separator
[12:26] <TheRyuu> good to know
[12:31] <nevcairiel> i dont think anyone had any brilliant ideas how to fix that yet, so for now msvc builds of the cli tools cant open file withs absolute path :p
[12:42] <TheRyuu> is it just me or does fate run tets faster with ffmpeg than libav?
[12:43] <ubitux> make sure you ran it with the samples
[12:43] <ubitux> we have a few thousands more tests
[12:44] <ubitux> though, some optims to make it faster went in
[12:44] <TheRyuu> well yes obviously with the samples
[12:44] <TheRyuu> individual tests take longer (probably because there's more of them but it seem like with -j4 or what have you with make
[12:44] <TheRyuu> seems to be faster
[12:45] <ubitux> time it :p
[12:45] <TheRyuu> I've been trying to
[12:45] <TheRyuu> but stuff gets in the way
[12:46] <TheRyuu> I've actually been trying to see if the new icl passes fate before I do any of that
[12:46] <TheRyuu> fast forward a day later maybe I can actually run it all
[12:53] <TheRyuu> ok i liked maybe it isn't
[12:53] <TheRyuu> lied*
[12:55] <TheRyuu> and passes everything, good to know that still works
[13:07] <TheRyuu> ok maybe I didn't lie
[13:07] <TheRyuu> libav: real    11m55.694s
[13:08] <TheRyuu> ffmpeg: real    7m40.942s
[13:08] <ubitux> fun
[13:09] <ubitux> this sounds a bit large only because of the checksum optims though
[13:09] <ubitux> something is wrong somewhere :p
[13:09] <TheRyuu> it's probably just some stupid windows  thing
[13:09] <TheRyuu> I would think too much into it
[13:18] <ubitux> would that be related to the size of the binary?
[13:18] <ubitux> libav doesn't strip binaries by default
[13:18] <ubitux> while ffmpeg still provides 2 versions (ffmpeg & ffmpeg_g, etc) 
[13:18] <ubitux> avconv is 45M here, against < 10M for ffmpeg
[13:21] <TheRyuu> I'm building with icl
[13:21] <TheRyuu> everything is  stripped
[13:22] <TheRyuu> anybody sane would use --disable-debug anyway for this
[13:29] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:40ee4de6a6a9: atrac3: Error on impossible encoding/channel combinations
[13:29] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:90acd3bfe7fa: imc: Catch a division by zero
[13:29] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:b9dea1a085c4: adpcm: Write the correct number of samples for ima-dk4
[13:29] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:b64bd2e18bac: qdm2: refactor joined stereo support
[13:29] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:93c524c0f0fa: atrac3: Error on impossible encoding/channel combinations
[13:29] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:f33d5af1f35e: imc: Catch a division by zero
[13:29] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.10:a88ed5a481c3: Merge commit 'b64bd2e18bac1bd3e3e0ae4aebcad1c33f031c66' into release/0.10
[13:29] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:ef475620b55a: adpcm: Unbreak ima-dk4
[13:34] <BBB> ubitux: so what's the av_assertN rule? for higher call number, N increases, or N decreases? and what is the range of N?
[13:34] <BBB> or michaelni ^^
[13:34] <ubitux> 0, 1, 2
[13:34] <ubitux> 0  always
[13:35] <nevcairiel> 0 is always on, 1 and 2 are for more speed critical code
[13:35] <nevcairiel> and are only on with a special configure option
[13:35] <ubitux> 2 for really speed critical
[13:35] <BBB> ubitux: flat is fine btw, the assembly will be identical, the compiler generates the same code as you manually generated for a multi-dim array (since the memory layout of the table is essentially identical)
[13:35] <ubitux> 1 for speed critical
[13:35] <ubitux> BBB: the assembly isn't after a few test, see my pastie
[13:35] <ubitux> BBB: btw, i followed your recommendations
[13:35] <ubitux> i'm not done but you can check my branch
[13:35] <BBB> ubitux: the top 3 should be av_assert2, not 1
[13:36] <ubitux> ok
[13:36] <BBB> since check_intra_mode, decode_mode and inter_recon are all called in the context of decode_b
[13:36] <BBB> so within decode_sb
[13:36] <michaelni> btw i know the mov realloc issue isnt sexy but someone will have to look at it, it easily could be security relevant
[13:36] <ubitux> michaelni: yeah but i have several issue to look at at the moment :(
[13:36] <ubitux> (i know, vp9 isn't one of them :p)
[13:37] <michaelni> someone else interrested maybe ?
[13:37] <ubitux> i need to fix the vobsub thing asap, and then i have an annoying issue with subtitles being badly (re)muxed into mpegts
[13:37] <BBB> ubitux: so, a size of [3] is kind of annoying because it's not a power of 2
[13:37] <BBB> I don't mind keeping these two separate bits, even though it is kind of a waste
[13:38] <BBB> since it's not 9->7, but only 7 -> 6.5
[13:38] <ubitux> yeah i was unsure about the padding
[13:38] <BBB> if you make the [3] toplevel it's ok
[13:38] <BBB> so [3][4] is ok
[13:38] <BBB> [4][3] is not :-p
[13:38] <ubitux> yeah right
[13:38] <ubitux> i'm still trying to get done with all the tables, maybe we can concat some
[13:38] <ubitux> there is an annoying one
[13:38] <BBB> they're all annoying
[13:39] <ubitux> no it's ok ;)
[13:39] <ubitux> the one with the 2 varcompref
[13:39] <BBB> I wrote some of that code in libvpx, the contextualization provides nice compression gains
[13:39] <ubitux> it's going to be huge, unless you have a trick
[13:39] <BBB> I just didn't have time to merge them into tables like this back then
[13:39] <BBB> nah, no trick :(
[13:39] <BBB> that was on the todo list
[13:39] <ubitux> i check the size of that table and it will be really huge
[13:40] <ubitux> (6 dim)
[13:40] <ubitux> i can flatten it though
[13:40] <BBB> 6dim is ... 2+2+4*1 bit?
[13:40] <BBB> or more?
[13:40] <BBB> 8bit isn't too bad
[13:41] <BBB> I like the code btw, the tables look pretty
[13:41] <ubitux> 2 ref (2x4 since intra packed in) + 2 comp (2x3) + 2 vcr (2x3)
[13:41] <BBB> the multidimensional ones
[13:41] <BBB> ah
[13:41] <BBB> so 6*2=12bit
[13:41] <BBB> hm...
[13:42] <BBB> we can start with it
[13:42] <BBB> if it's faster, it's fine
[13:42] <BBB> we can try to make it smaller later on
[13:42] <BBB> it doesn't have to be perfect right away, the current code isn't quite pretty always either
[13:42] <BBB> and this is a lot shorter already
[13:42] <ubitux> it wont for that 6 dim unless i pack it
[13:42] <ubitux> pack/flat/..
[13:43] <BBB> right :)
[13:43] <BBB> well
[13:43] <BBB> don't worry about the 80 char limit for tables like that
[13:43] <BBB> if that helps any
[13:43] <ubitux> anyway, i'm gonna get done with two others
[13:43] <ubitux> yeah, sure.
[13:44] <ubitux> and multi dim is definitely different from flat assembly wise: http://pastie.org/8345851
[13:44] <ubitux> (random pow of 2 for each dim)
[13:45] <ubitux> (6 dim)
[13:45] <BBB> omg
[13:45] <BBB> well flat is fine then, how stupid
[13:45] <ubitux> :)
[13:45] <BBB> actually is it faster?
[13:45] <ubitux> didn't bench
[13:46] <ubitux> but it's different ;)
[13:46] <BBB> 12 vs 13
[13:46] <BBB> hm...
[13:46] <BBB> well make your own choice :)
[13:46] <ubitux> mixed one!
[13:46] <BBB> ...
[13:46] <ubitux> :(
[13:46] <BBB> I said nothing! :)
[13:46] <BBB> I just said "..."
[13:47] <BBB> also, I have some working mc assembly
[13:47] <BBB> decoder gets about 2x speed with that
[13:48] <ubitux> cool
[13:48] <BBB> 1080p now does ~32fps
[13:48] <BBB> so it's already realtime for hd
[13:48] <BBB> most time is now spent in itxfm_add functions
[13:48] <BBB> there's some special tricks there to do for assembly, so once you have some assembly, let's go through it and we'll take it from there
[13:49] <ubitux> ok
[13:49] <BBB> most importantly, I expect the simd function to take care of the dc-only etc. handling, rather than the caller
[13:49] <BBB> this is different from h264/vp8/etc
[13:49] <BBB> (and the c code doesn't do this)
[13:49] <ubitux> is this related to the eob flag you're passing along?
[13:50] <ubitux> TheRyuu: it's faster for me in libav
[13:50] <ubitux> make fate -j10 SAMPLES=$HOME/libav-fate-samples > /dev/null  330.42s user 19.41s system 629% cpu 55.613 total
[13:50] <ubitux> make fate -j10 > /dev/null  559.52s user 43.65s system 681% cpu 1:28.53 total
[13:50] <ubitux> (libav, then ffmpeg)
[13:51] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:57efb6d94ceb: qdm2: Conceal broken samples
[13:51] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:195b9f290cb6: iff: Do not read over the source buffer
[13:51] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:9c05debdcd75: wmavoice: conceal clearly corrupted blocks
[13:51] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:9c3c08ba984a: pcx: Do not overread source buffer in pcx_rle_decode
[13:51] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:47baf9ca8734: mlpdec: Do not set invalid context in read_restart_header
[13:51] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:62c35475396d: pcm: always use codec->id instead of codec_id
[13:51] <ubitux> which sounds correct to me, since we have more tests
[13:51] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:ce3ce08850f1: dca: Error out on missing DSYNC
[13:51] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.10:506ad68d87f9: Merge commit 'ce3ce08850f1690dff01d9bb4ed6a4274d52771e' into release/0.10
[13:51] <TheRyuu> like I said, probably antivirus/windows/derping
[13:53] <ubitux> "av" means antivirus, so it gets a lot more attention from the real av
[13:53] <ubitux> ;)
[13:53] <TheRyuu> symantec loves to eat up random cpu when running fate
[13:53] <TheRyuu> so random svcohost jumps up too sometimes
[13:53] <TheRyuu> s/so/some/
[13:56] <TheRyuu> ubitux: was that on linux btw?
[13:56] <ubitux> yes
[13:56] <TheRyuu> (or something not windows/mingw)
[13:58] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:521cbcb7d37f: dca: Respect the current limits in the downmixing capabilities
[13:58] <cone-712> ffmpeg.git 03Justin Ruggles 07release/0.10:763519536b63: ac3dec: validate channel output mode against channel count
[13:58] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.10:68b100871961: adpcm: Unbreak ima-dk4
[13:58] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.10:9e552b65127a: Merge remote-tracking branch 'qatar/release/0.8' into release/0.10
[14:04] <BBB> ubitux: yes it is
[14:05] <BBB> ubitux: you know eob > 0 (caller checks), so you can do things like if eob == 1 do dc-only (see vp8, libvpx also has specialized code for that, it's easy to derive from the full idct)
[14:06] <BBB> ubitux: and then in the 8x8, you can do smarter checks, e.g. if eob == 1 do dc-only, and if eob <= 10 (or so, forgot the exact number, check scantable) do a top-left 4x4 only (that's not the same as a full 4x4 idct)
[14:08] <BBB> ubitux: 16x16/32x32 are most of runtime in hd, so you can do more elaborate checks for these
[14:08] <BBB> ubitux: e.g. a 2x2 only, 4x4 only, 8x8 only, 16x16 only, etc. (I don't know how much specialization makes sense, it's worth testing)
[14:10] <ubitux> ok, i'll look at that, later
[14:35] <BBB> ubitux: and any thoughts on the bitfield in VP9Context thing? I guess -edontcare just like me so I'll change them to non-bitfields?
[14:36] <ubitux> sure, i don't care
[15:25] <Daemon404> oh
[15:25] <Daemon404> the vp9 patch was sent to my spa folder by gmail
[15:25] <Daemon404> too large -- must be suspicious
[15:26] <ubitux> google bans its own techno
[15:27] <Daemon404> yeah
[15:28] <ubitux> ok, one new lut, yay
[15:28] <ubitux> 2 left.
[15:29] <Daemon404> did you guys put a link to all the vp9 test vectors somewhere
[15:31] <kierank> Daemon404: same vp9 got spammed
[15:31] <Daemon404> ?
[15:52] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:091ba02cc836: avformat/movenchint: revert "Use av_reallocp() where suitable"
[15:52] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:63621762eccf: avformat/movenchint: only change queue size if reallocation succeeded
[15:52] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:05b7a635dc1e: avformat/movenchint: use realloc_array() to protect against integer overflow
[15:55] <ubitux> BBB: https://github.com/ubitux/FFmpeg/commit/8e690e76104378f8adc8ece51e2f19aae3ce48d4
[15:55] <ubitux> still not complete, 2 lut left, one simple and the nasty one
[16:04] <Compn> ubitux : why you want vp7 ?
[16:04] <Compn> or is this a new sample? :)
[16:04] <ubitux> i don't care
[16:04] <Compn> lol
[16:04] <ubitux> :)
[16:04] <ubitux> i just happened to see that bug with an unsupported sample
[16:09] <cone-712> ffmpeg.git 03Reimar Döffinger 07master:2aa8e33d7d86: Fix nonsense MPEG-4 hwaccel code.
[16:19] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:a5cbf1991c3d: avformat/mov: reset extradata size when extradata gets deallocated due to realloc failure
[16:20] <ubitux> oh i might have found a way a cool trick for the nasty lut
[16:21] <cone-712> ffmpeg.git 03Reimar Döffinger 07master:547c2f002a87: Make decoding alpha optional for some codecs.
[16:40] <durandal_1707> is there vp7 spec?
[16:40] <JEEBsv> ye
[17:22] <cone-712> ffmpeg.git 03Vicente Jimenez Aguilar 07release/0.8:c10582e703c5: doc: filters: Correct BNF FILTER description
[17:22] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.8:b6783b882682: indeo5: update AVCodecContext width/height on size change
[17:22] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.8:ee6b868ac835: oggdec: make sure the private parse data is cleaned up
[17:22] <cone-712> ffmpeg.git 03Reinhard Tartler 07release/0.8:8489c0599f0e: update year to 2013
[17:22] <cone-712> ffmpeg.git 03Reinhard Tartler 07release/0.8:c313f3160ae1: Update RELEASE file for 0.7.8
[17:22] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.8:d86a5ce03f69: vorbisdec: Error on bark_map_size equal to 0.
[17:22] <cone-712> ffmpeg.git 03Anton Khirnov 07release/0.8:5025dbc577c9: wmaprodec: return an error, not 0, when the input is too small.
[17:22] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.8:afe09e490a30: Merge commit '5025dbc577c9a9e0109cb363ac630a9eeda6dc1d' into release/0.8
[17:26] <cone-712> ffmpeg.git 03Anton Khirnov 07release/0.8:f13f6f82c63f: wmadec: require block_align to be set.
[17:26] <cone-712> ffmpeg.git 03Reinhard Tartler 07release/0.8:7e6625a9afbe: xxan: fix invalid memory access in xan_decode_frame_type0()
[17:26] <cone-712> ffmpeg.git 03Reinhard Tartler 07release/0.8:7d4c38d58d01: h264: check for luma and chroma bit depth being equal
[17:26] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.8:5bfa208e6565: matroskadec: request a read buffer for the wav header
[17:26] <cone-712> ffmpeg.git 03Justin Ruggles 07release/0.8:d785f6940144: shorten: validate that the channel count in the header is not <= 0
[17:26] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.8:0a41da3e9d20: Merge commit 'd785f6940144eb6ce4c24309ed034056b81395bc' into release/0.8
[17:32] <cone-712> ffmpeg.git 03Reinhard Tartler 07release/0.8:a694b2b15865: shorten: set invalid channels count to 0
[17:32] <cone-712> ffmpeg.git 03Reinhard Tartler 07release/0.8:5ebb5a32bdd9: shorten: report meaningful errors
[17:32] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.8:44ebb2556d09: Merge commit '5ebb5a32bdd910a8afb316c51ed0b322f5600ae5' into release/0.8
[17:36] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.8:6d4d186e9e9f: shorten: use the unsigned type where needed
[17:36] <cone-712> ffmpeg.git 03Mans Rullgard 07release/0.8:799000af702a: dsputil: fix invalid array indexing
[17:36] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.8:9c713f30e491: parser: fix large overreads
[17:36] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.8:49d597f058a9: Merge commit '9c713f30e4913a28d93eb37ea5db7f62be4c0ef6' into release/0.8
[17:41] <BBB> ubitux: cool!
[17:41] <BBB> ubitux: also, if you feel it helps, feel free to assign ref=0 in the intra case in decode_mode, so you can do 1-intra+ref (or ref+!intra) instead of the branchy version
[17:42] <BBB> ubitux: we could even change the meaning of ref to be more in line with what libvpx does (ref=0 is intra, and else ref=1,2,3 instead of what we have
[17:42] <BBB> ubitux: whatever makes most sense
[17:42] <BBB> ubitux: looks nice!
[17:42] <ubitux> i'll try to get done with the rest of the luts
[17:42] <ubitux> but it's starting to get pretty ugly for the last ones
[17:42] <ubitux> not sure i'll be able to make something sane
[17:43] <ubitux> ok for the branching simplification, but it can be done later
[17:43] <cone-712> ffmpeg.git 03Mans Rullgard 07release/0.8:c65763a2c677: lavf: fix arithmetic overflows in avformat_seek_file()
[17:43] <cone-712> ffmpeg.git 03Xi Wang 07release/0.8:78889be3fb4b: atrac3: avoid oversized shifting in decode_bytes()
[17:43] <cone-712> ffmpeg.git 03Xi Wang 07release/0.8:f8d3bb8961d2: flacdec: simplify bounds checking in flac_probe()
[17:43] <cone-712> ffmpeg.git 03Xi Wang 07release/0.8:530d10792de2: lzo: fix overflow checking in copy_backptr()
[17:43] <cone-712> ffmpeg.git 03Anton Khirnov 07release/0.8:280998b13cb8: wmaprodec: require block_align to be set.
[17:43] <cone-712> ffmpeg.git 03Kostya Shishkov 07release/0.8:f844cb9bced3: iff: validate CMAP palette size
[17:43] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.8:70a1182a4844: Merge commit 'f844cb9bced3148fca2db5bbb092929526108005' into release/0.8
[17:43] <BBB> ubitux: also, any reason you removed one half of the fixme in line 1357 but left the other half behind (line 1358)?
[17:43] <BBB> ubitux: agreed on branching-simpl-later
[17:43] <ubitux> i guess because i'm stupid
[17:44] <ubitux> will remove the last part of the sentence
[17:44] <BBB> ty
[17:45] <BBB> will start merging sometime soon once the baby is off my lap
[17:45] <BBB> hard to type anything efficient like this
[17:46] <cone-712> ffmpeg.git 03Anton Khirnov 07release/0.8:33c9e18b09f4: avfiltergraph: check for sws opts being non-NULL before using them.
[17:46] <cone-712> ffmpeg.git 03Anton Khirnov 07release/0.8:96cf80609af6: dfa: check for invalid access in decode_wdlt().
[17:46] <cone-712> ffmpeg.git 03Anton Khirnov 07release/0.8:76c97f19634f: lavf: make sure stream probe data gets freed.
[17:46] <cone-712> ffmpeg.git 03Anton Khirnov 07release/0.8:9b052bfb8609: rv10: check that extradata is large enough
[17:46] <cone-712> ffmpeg.git 03Anton Khirnov 07release/0.8:96481c5e1843: qdm2: check that the FFT size is a power of 2
[17:46] <cone-712> ffmpeg.git 03Luca Barbato 07release/0.8:053c19cd88b6: oggdec: fix faulty cleanup prototype
[17:46] <cone-712> ffmpeg.git 03Reinhard Tartler 07release/0.8:ade4f3e74635: aac: check the maximum number of channels
[17:46] <cone-712> ffmpeg.git 03Reinhard Tartler 07release/0.8:3197a9c4fa46: Update changelog for 0.7.8 release
[17:46] <cone-712> ffmpeg.git 03Michael Niedermayer 07release/0.8:9b0736c08ac5: Merge remote-tracking branch 'qatar/release/0.7' into release/0.8
[17:54] <ubitux> BBB: i pushed a new chunk for the 2 first lut, but i don't like it
[17:54] <ubitux> see c_above_and_left_2ref_lut_p1
[17:54] <ubitux> (first chunk of the diff)
[17:55] <ubitux> anyway, going to try again the last lut with the 2 varcompref
[17:55] <ubitux> that's definitely going to be the worst one
[18:34] <ubitux> oh, 'found a trick :)
[18:39] <cone-712> ffmpeg.git 03Paul B Mahol 07master:601eab2bbf16: avfilter: add ladspa wrapper filter
[18:46] <durandal_1707> can anyone convect inline asm in sws to yasm?
[18:52] <durandal_1707> all those deadlock appears to be in loops that checks bits left from bit reader
[18:52] <ubitux> BBB: Q: in the 2 ref code, the part with the varcompref; is it possible that [al]_ref are not equal to any of the two varcomprefs and not equal to fcr either?
[18:53] <ubitux> (and would that mean it's intra?)
[18:53] <ubitux> that would save me 2 bits and make the lut extremely decent :)
[18:57] <ubitux> i guess i'll try
[19:25] <BBB> ubitux: no, the fixcompred and two varcompref are all unique
[19:25] <BBB> ubitux: together, they make the three refs that are available in the single pred case
[19:26] <ubitux> mmh
[19:26] <ubitux> the idea i'm using is a lut with equalities as keys
[19:26] <BBB> so a_ref is always either one of the two varcomprefs or the fixcompref
[19:26] <BBB> it can not be neither or both
[19:26] <ubitux> basically: http://pastie.org/8346781
[19:27] <ubitux> so you get a 32x32 lut
[19:27] <ubitux> but i'm wondering if i can deduce the intra and/or comb bit based on those equalities
[19:28] <ubitux> <@BBB> so a_ref is always either one of the two varcomprefs or the fixcompref // oh so it's ok i can exploit that i guess
[19:28] <ubitux> maybe.
[19:29] <BBB> maybe :)
[19:29] <BBB> so I was always hoping you could do it in 4 bits per side
[19:30] <BBB> but maybe you can't, I'm not sure
[19:30] <BBB> I guess you need to know which one is the fixcompref, so that's another 2 bits per side
[19:30] <BBB> the varcompref is indeed derivable from fixcompref, so that maybe not necessary
[19:31] <cone-712> ffmpeg.git 03Paul B Mahol 07master:b00fb157bae7: avcodec/sgirledec: fix infinite loop in decode_sgirle8()
[19:33] <ubitux> oh?
[19:38] <BBB> ubitux: it has three values: 0, 1 or 2
[19:39] <BBB> ubitux: if fixcompref is 0, than varcompref is 1 and 2
[19:39] <BBB> ubitux: if fixcompref is 1, than varcompref is 0 or 2
[19:39] <BBB> ubitux: so if you know fixcompref, you know everything
[19:39] <BBB> ubitux: so for the sake of the table, you should only need fixcompref
[19:40] <BBB> and in the single-ref context, I think all you need is fixcompref == 0 for bit 0
[19:40] <BBB> the other bit of the single-ref is more complicated
[19:40] <BBB> or maybe it's different and I misremember
[19:40] <BBB> I guess regardless, you should at the very least only need fixcompref, which is 2 bits
[19:41] <BBB> (or 1.5)
[19:41] <ubitux> ah that's great then
[19:41] <ubitux> thanks!
[19:42] <ubitux> BBB: there is only one fixcompref for 2 varcompref
[19:43] <BBB> yes
[19:43] <ubitux> mmh
[19:44] <ubitux> i wonder how i can deduce the equalities from this
[19:45] <BBB> if one of the indices in the table is ref, and one is the fixcompref, the equalities follow automatically fromt he table positions right
[19:45] <BBB> e.g. int is_equal[3][3] = { { 1, 0, 0 }, { 0, 1, 0 }, { 0, 0, 1 } };
[19:45] <BBB> identity matrix?
[19:46] <BBB> if you use !intra+ref, it becomes a 0 before each
[19:46] <ubitux> just for the record, this is what i'm doing currently (it works): https://github.com/ubitux/FFmpeg/commit/dce2119dcd5a94677ab1fe4df616a03bf5c46619#L0R1377
[19:46] <ubitux> but well... :)))
[19:51] <BBB> the algorithm might not be immediately obvious to someone reading that table
[19:51] <BBB> but that's ok, that's what libvpx is for
[19:51] <BBB> the table looks like it would be a lot faster
[19:51] <BBB> so I think it's ok
[19:51] <ubitux> i would like to reduce it by 1 bit from each side
[19:52] <BBB> I would like to eat chocolate cake each day
[19:52] <ubitux> this should be doable
[19:52] <BBB> comp and intra ctx are 1bit btw
[19:52] <durandal_1707> how much it is faster?
[19:52] <BBB> so they are always 1 or 0
[19:52] <BBB> !! is unnecessary
[19:53] <ubitux> yeah it was just for testing, i'll remove them
[19:53] <ubitux> durandal_1707: dunno, i need to bench
[19:56] <BBB> I think the [3][2][4] that you have for the 1d is the best I can think of for the 2d
[19:56] <BBB> but that's not 4bit, it's more like 4.5 bit
[20:08] <cone-712> ffmpeg.git 03Kieran Kunhya 07master:283fb76d3d6e: lavc: Add support for interleaved chroma formats to libx264. Interleaved chroma is x264's native format
[20:09] <durandal_1707> anybody needs silenceremove plugin?
[20:48] <cone-712> ffmpeg.git 03Paul B Mahol 07master:f8e8932e9235: doc/filters: mention configure option for ladspa
[20:49] <ubitux> ok well nuff vp9 for now, will continue later on
[20:49] <ubitux> durandal_1707: @code{--enable-liadspa}
[20:50] <durandal_1707> i copy pasted it
[20:50] <ubitux> afaict most --enable- are using that
[20:50] <ubitux> try git grep -- --enable doc
[20:52] <durandal_1707> well to be ever worse i copied it from log and not from file......
[21:05] <BBB> ubitux: first 2 patches merged
[21:05] <BBB> ubitux: last one, want me to hold off until they're all done?
[21:05] <ubitux> BBB: as you wish, i'm not in a hurry
[21:05] <ubitux> it can be improved, and i will, in the next days
[21:07] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:b5b762b71402: avcodec/avcodec.h: skip_alpha should not be accessed directly (would cause ABI issues)
[21:07] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:fbf861cb84e2: tests/fate/prores: fix skip alpha tests on big endian
[21:23] <BBB> ubitux: oh, and for profiling, I'd just profile the whole decode_mode function
[21:24] <BBB> ubitux: otherwise it gets kind of iffy
[21:28] <ubitux> sorry i'm back on mpeg now :(((
[21:28] <ubitux> mpeg(ts) looks so broken...
[21:30] <BBB> lol
[21:30] <ubitux> i have 2 issues to deal with right now
[21:31] <ubitux> dvb subtitles not being remuxed properly (with not even a warning)
[21:31] <ubitux> and the pes parser in mpeg which break the vobsub parsing :(
[21:31] <BBB> I'll send a new vp9 patch with all this fixed
[21:47] <ubitux> is there something i should know about remuxing subtitles from mpegts to... mpegts with ffmpeg?
[21:49] <ubitux> oh fuck i'll just open a ticket
[21:56] <BBB> anyone interested in mips debugging?
[21:56] <BBB> I'm not
[22:11] <ubitux> you could mail the mips guys
[22:11] <ubitux> Nedeljko Babic
[22:11] <ubitux> nbabic at mips.com
[22:14] <BBB> why would it fail specifically on mips anyway?
[22:14] <nevcairiel> did you try the pure C variant, which i guess mips should use?
[22:15] <BBB> I can't find any assembly anywhere
[22:15] <BBB> so I'm pretty sure mips uses the c version
[22:15] <BBB> which works on all systems I have access to
[22:16] <BBB> I guess I can try ppc, which is somewhat picky on alignment sometimes
[22:16] <BBB> that's all I can imagine
[22:16] <BBB> mips is 32bit right?
[22:17] <nevcairiel> there is both mips32 and mips64, dont ask me which is in use here
[22:18] <nevcairiel> carl said ppc64 also fails
[22:26] <BBB> now? or with patch?
[22:26] <BBB> ppc32 fails for me
[22:26] <BBB> hm
[22:26] <BBB> I'll check
[22:26] <BBB> odd
[22:26] <BBB> maybe I screwed up somewhere
[22:41] <cone-712> ffmpeg.git 03Paul B Mahol 07master:0de4efb8d72f: doc/filters: put ladspa configure option into @code{}
[22:58] <ubitux> thx durandal_1707 
[23:50] <durandal_1707> it's ok if i push nicolas framesync ?
[23:56] <cone-712> ffmpeg.git 03Stefano Sabatini 07master:57618d80af25: doc/fftools: rework some paragraph in the AVOptions chapter
[23:56] <cone-712> ffmpeg.git 03Stefano Sabatini 07master:21f6ff380163: doc/filters: use between() function in select examples
[00:00] --- Mon Sep 23 2013