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

[burek]

[00:04] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:5047849584f2: avformat/utils: fix order of buffers in timestamp update code
[00:24] <cone-17> ffmpeg.git 03Anton Khirnov 07master:feded990e3ef: mpegvideo: set reference/pict_type on generated reference frames
[00:24] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:532b93b51631: Merge commit 'feded990e3ef9af4a0b827d5b6d8fe86f0b94942'
[00:47] <cone-17> ffmpeg.git 03Anton Khirnov 07master:a6a2282c25ab: rv30: fix extradata size check.
[00:47] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:3cf1503beb35: Merge commit 'a6a2282c25abe43e352010a7c3fbc92994c0bc1c'
[01:06] <cone-17> ffmpeg.git 03Anton Khirnov 07master:5569146d48f0: adx: check that the offset is not negative
[01:06] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:c13e73c25b6d: Merge commit '5569146d48f06564e8fa393424782cceed510916'
[01:13] <cone-17> ffmpeg.git 03Anton Khirnov 07master:24057c83207d: eacmv: check the framerate before setting it.
[01:13] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:405b1ef898bf: Merge commit '24057c83207d6ea8bfd824155ac37be8a33dfd0c'
[01:35] <cone-17> ffmpeg.git 03Anton Khirnov 07master:94a417acc05c: mathematics: remove asserts from av_rescale_rnd()
[01:35] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:3929c17405e0: Merge commit '94a417acc05cc5151b473abc0bf51fad26f8c5a0'
[01:42] <cone-17> ffmpeg.git 03Anton Khirnov 07master:1b5d065ca722: pmpdec: check that there is at least one audio packet.
[01:42] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:4a055f91bec2: Merge commit '1b5d065ca722eb8028c7a08e054b6da3419faf5d'
[02:06] <cone-17> ffmpeg.git 03Anton Khirnov 07master:e89aa4bf56e5: lzw: switch to bytestream2
[02:06] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:508229adb930: Merge commit 'e89aa4bf56e5b5c45f569eb12733519789e057da'
[02:12] <cone-17> ffmpeg.git 03Anton Khirnov 07master:58312b2472d3: h264: reset data_partitioning if decoding the slice header for NAL_DPA fails
[02:12] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:8e6af036b957: Merge commit '58312b2472d3a44d7458865c459d59ef2e02bf1a'
[02:18] <cone-17> ffmpeg.git 03Anton Khirnov 07master:3d95d27376e5: audio_mix: initialize the data pointers to NULL
[02:18] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:fadec4f6dbc7: Merge commit '3d95d27376e59de14f984e7a22a52e066d85df35'
[02:31] <cone-17> ffmpeg.git 03Anton Khirnov 07master:fc6a3ef40d34: audio_mix: fix zeroing output channels in certain cases
[02:31] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:4b8bc6d2b0a9: Merge commit 'fc6a3ef40d34ce8443ae57c2452f3f273d7d4891'
[02:36] <cone-17> ffmpeg.git 03Anton Khirnov 07master:cc976a75dffa: audio_mix: print (SKIP) instead of 0.0 for matrix columns removed along with output zeroing
[02:36] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:781fd58838ca: Merge commit 'cc976a75dffa148d655b52604331679ff669e8a2'
[02:41] <cone-17> ffmpeg.git 03Anton Khirnov 07master:a8cc88b1a23d: tests/Makefile: allow FILTER* to be called with lists of filter names
[02:41] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:cf867517f15b: Merge commit 'a8cc88b1a23dc1515f27cfa98af16a273c539091'
[02:49] <BBB> ubitux: ok 32x32 works now, not too bad
[02:51] <BBB> 7.6sec (libvpx) vs. 8.2sec (ffvp9) without lf simd
[02:51] <BBB> and idct32x32 gave me about 1sec speedup
[02:51] <BBB> so I think after lf simd we'll beat libvpx by quite a bit
[02:53] <cone-17> ffmpeg.git 03Anton Khirnov 07master:b318106fae65: FATE: add a test for the lavr mixing case fixed in fc6a3ef40d34ce8443ae57c2452f3f273d7d4891
[02:53] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:ad5e4e0f947a: Merge commit 'b318106fae65149356934fc72feafef3272fd4ea'
[03:03] <cone-17> ffmpeg.git 03Anton Khirnov 07master:aec25b1c4650: mpegvideo: split the encoding-only parts of frame_start() into a separate function
[03:03] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:fb17f03dadc3: Merge commit 'aec25b1c4650944d32706bfd40eb02bbd5587303'
[03:13] <cone-17> ffmpeg.git 03Anton Khirnov 07master:a4d0c6e05035: mpegvideo: move dct_unquantize functions up to avoid forward declarations
[03:13] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:9b9f64fe315c: Merge commit 'a4d0c6e0503562d4cc8f9f6d02d84d7b32583b15'
[03:21] <cone-17> ffmpeg.git 03Anton Khirnov 07master:a3a55645f09f: mpegvideo: remove disabled bfin asm
[03:21] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:adc09a353c5f: Merge remote-tracking branch 'qatar/master'
[04:36] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:958e31197431: avcodec/rv10: cleanup rpr handling
[04:36] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:a881b9aa08af: avcodec/rv30: cleanup rpr handling
[04:36] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:d08c6e1101aa: avcodec/rv30: check rpr before use against maximum
[04:36] <cone-17> ffmpeg.git 03Michael Niedermayer 07master:be524ffc16bf: avcodec/rv30: put the rpr check back in init with the max vs bits bug fixed
[09:44] <cone-644> ffmpeg.git 03Clément BSsch 07master:307b6b8cb4f8: avfilter/lut3d: fix channel order in Iridas format parsing.
[10:43] <ubitux> can i compare strings in yasm macro?
[12:02] <ubitux> the lpf byte clipping in vp8/9 really is sick
[12:35] <nevcairiel> if 8 also had, steal from there! :D
[12:36] <BBB> ubitux: maybe check how vp8 did it (it's likely similar), or how libvpx' simd does it, if you're having trouble
[12:41] <ubitux> nevcairiel, BBB, yes the part i'm messing with is mostly the same as vp8, and yes i'm looking
[12:47] <BBB> and ask questions, sometimes I have ideas
[12:47] <BBB> if this is still about clip_u8(u8+i8), what michaelni said is probably a good idea
[12:48] <BBB> (i.e. split i8 over two registers, negative and positive, and then use add/sub instructions per-register)
[12:48] <BBB> (paddusb/psubusb)
[12:49] <ubitux> yes i did that
[12:49] <ubitux> just like in vp8
[12:50] <ubitux> i'm trying to understand what you did for the (f1+1)>>1
[12:50] <ubitux> f1 being of course int8_t
[12:50] <ubitux> (and 127>>1 ` 128>>1 so i cant just paddsb :p)
[12:59] <ubitux> > According to the WebM mailing lists, the VP9 codec supports 4:4:4 chroma subsampling in profile 1.
[12:59] <ubitux> ah?
[13:03] <j-b> you mean, according to the spec, right?
[13:04] <JEEB> > VPx > spec > laughing_schoolgirls.jpg
[13:04] <j-b> libraries using abort > *
[13:05] Action: JEEB ^5s j-b 
[13:07] Action: ubitux would use andthenisaid.jpg
[13:09] <BBB> ubitux: sounds like a candidate for psrl{d,w,q}(pand(paddb(x, 1), 0xfe), 1)
[13:09] <BBB> or pxor(pavgb(pxor(x, 0x80), zero), 0x80)
[13:14] Action: j-b gives libdvdread/libdvdnav source code to JEEB and laughs
[13:17] Action: JEEB quietly marks the package "undeliverable" and pokes it back to the mailer daemon
[13:20] <cone-815> ffmpeg.git 03Martin Storsjö 07master:2ad4ee345a42: arm: Add a missing endfunc macro call
[13:20] <cone-815> ffmpeg.git 03Michael Niedermayer 07master:63ce041a7d06: Merge commit '2ad4ee345a4216aef3999f57dd14c56128d27a13'
[13:39] <cone-815> ffmpeg.git 03Martin Storsjö 07master:3348e3492d0c: arm: Use the matching endfunc macro instead of the assembler directive directly
[13:39] <cone-815> ffmpeg.git 03Michael Niedermayer 07master:d8e65e9224b9: Merge remote-tracking branch 'qatar/master'
[13:48] <BBB> ubitux: can I haz review plz?
[13:53] <ubitux> BBB: give me a few hours plz :p
[13:53] <ubitux> like 3-4
[13:53] <BBB> lol
[13:53] <BBB> ok
[13:53] <BBB> I'll work on a fixme to prevent another 3 shuffles in pass 2 and work on the sub-idcts or so
[13:54] <BBB> kierank: can I borrow your sandybridge machine at some point in the next few days? I'd like to test some basic avx functions for speed and accuracy
[15:04] <BBB> ubitux: also, my repo has some small modifications to the simd to fix an outstanding fixme (prevent 3 stack moves)
[15:04] <BBB> ubitux: I can send new patch but basically look at github, not ML
[15:04] <ubitux> noted :)
[15:05] <BBB> it's 10-20 cycles faster overall in the nodc version, so quite a bit
[15:05] <BBB> (it's basically what you'd expect)
[15:06] <ubitux> btw, a load from rodata is generally faster than from stack, right?
[15:06] <BBB> I'm not sure
[15:07] <BBB> it all depends on where it is in your cache right?
[15:07] <BBB> if you just put it there, it's proabbly in L1 = very fast
[15:07] <BBB> if you put it there last week, it's probably not so fresh
[15:07] <BBB> = slow
[15:07] <BBB> rodate ... I don't know how that's scheduled, but I'm sure the schedulers are quite smart there
[15:08] <BBB> maybe pengvado knows
[15:08] <cone-815> ffmpeg.git 03Michael Niedermayer 07master:8113e838a811: avformat/nut: add support for per frame side & meta data with version 4
[15:22] <cone-815> ffmpeg.git 03Michael Niedermayer 07master:de5b6c736bcb: Changelog: add nuts side & metadata support
[15:22] <cone-815> ffmpeg.git 03Michael Niedermayer 07master:b317f9459f4c: avutil/mathematics: add av_add_stable()
[15:22] <cone-815> ffmpeg.git 03Michael Niedermayer 07master:cd7037dd7ac1: avutil/rational: av_add_stable() test code
[15:22] <cone-815> ffmpeg.git 03Michael Niedermayer 07master:863f4c3c7170: avformat/utils: fix rounding error accumulation for generated dts in compute_pkt_fields()
[15:32] <pengvado> BBB: caching is totally independent of sections
[15:33] <BBB> ok, good to know, thanks
[15:34] <BBB> pengvado: does the scheduler do anything clever w.r.t. pre-caching rodate sections? or is it just on-use?
[15:37] <pengvado> I don't know what you mean by "pre-caching"
[15:37] <pengvado> if you meant "prefetching" then no.
[15:45] <ubitux> BBB: btw, do you have the same stack valgrind issue with 32x32?
[15:51] <BBB> pengvado: yes I meant prefetching
[15:51] <BBB> thanks
[15:51] <BBB> ubitux: possibly, didn't check
[15:51] <ubitux> +    VP9_UNPACK_MULSUB_2W_4X   2, 13, 6270, m15137, [pd_8192], 0, 7 ; y21, t26
[15:51] <ubitux> t21*
[15:52] <BBB> oh nice typo
[15:54] <ubitux> BBB: http://pastie.org/8600340 i think m0 is scrapped in this area, it shouldn't be in the comments, no?
[15:54] <BBB> fixed (locally)
[15:55] <BBB> sort of ... yes m0 is scratch there, but that's just because we've moved the instructions that do m0 a little higher up
[15:55] <BBB> (since we don't have enough instructions)
[15:55] <BBB> yes it's a little confusing but the comments try to follow the c code whereas the real code follows the flow of "I don't have enough registers"
[15:56] <BBB> I'll think of how to do that cleverer
[15:56] <BBB> this is indeed kinda weird
[15:56] <ubitux> i guess it's the same for "; store t16-23 - keep t24-31 in registers for the final sumsub"?
[15:56] <ubitux> (it's storing t17+)
[15:57] <ubitux> t17-22 even
[16:00] <BBB> hm no that comment is broken, it stores only t16-t19 and t23
[16:01] <BBB> and t16/t23 are done earlier
[16:01] <BBB> so it only stores t17-19
[16:01] <ubitux> you could write a macro for the bunch of stores in 2nd pass
[16:01] <ubitux> also, haven't you free a reg at that point for pw_512?
[16:03] <ubitux> don't you have*, :english:
[16:08] <ubitux> no more comment from me, except that maybe in this bunch of store we have the possibility to jungle with some dstq+N*strideq in the store macro to drop a few "add dstq, stride2q"
[16:08] <ubitux> might not be possible without a neg strideq
[16:08] <ubitux> but well, maybe not worth the effort
[16:08] <ubitux> LGTM otherwise :p
[16:08] <ubitux> i'd really like to have valgrind happy though :(
[16:10] <BBB> so valgrind has been unhappy ever since the original first 16x16 landed?
[16:11] <BBB> (i.e. only the full)
[16:11] <ubitux> wasn't it pushed with all of them at once?
[16:11] <ubitux> ah the sub might have appear after.. mmh i don't remember
[16:13] <BBB> holy shit
[16:13] <BBB> it just went from 2300 to 1450 cycles
[16:13] <BBB> (by introducing the sub16x16 idct)
[16:13] <BBB> sub landed later, I think you said this happened with the ful
[16:13] <BBB> I'll add it on my plate to look at
[16:14] <kierank> BBB: iirc you have an account
[16:14] <BBB> kierank: oh it's still active? thanks, will check
[16:19] <BBB> yay decoding tiem is under 8sec now
[16:19] <ubitux> BBB: did you upload the sample btw? :P
[16:19] <BBB> ohright
[16:19] <BBB> doesn't ffmpeg have an upload somewhere?
[16:19] <Compn> ftp://upload.ffmpeg.org/
[16:20] <BBB> incoming?
[16:20] <BBB> or elsewhere?
[16:20] <Compn> incoming yes
[16:20] <Compn> sorry, the ftp stuff got all jumbled around i dont remember exactly :)
[16:21] <BBB> ubitux: ftp://upload.ffmpeg.org/incoming/ped1080p.webm
[16:21] <BBB> probably needs to be moved somewhere to be readable
[16:21] <Compn> hope ubitux remembers http password to access it
[16:21] <ubitux> i think i have an access
[16:21] <ubitux> iirc it's a videolan one, dunno how those match
[16:22] <Compn> yes
[16:22] <Compn> upload.ffmpeg.org points to streams.videolan.org
[16:22] <Compn> http://streams.videolan.org/incoming/ped1080p.webm
[16:22] <Compn> is the final url of course
[16:23] <ubitux> go it, thx
[16:24] <ubitux> got*
[16:26] <ubitux> 13:09:02 <@BBB> ubitux: sounds like a candidate for psrl{d,w,q}(pand(paddb(x, 1), 0xfe), 1) // will that really work? oO
[16:30] <BBB> why not?
[16:30] <BBB> sub16x16 uploaded to github
[16:30] <ubitux> sounds like it's missing something
[16:30] <BBB> will write a sub8x8 also, maybe it's faster
[16:40] <ubitux> BBB: it doesn't work for unsigned
[16:41] <ubitux> BBB: http://pastie.org/pastes/8600473/text
[16:42] <ubitux> this is what you are suggesting, right?
[16:42] <ubitux> well anyway, i'll figure out something
[16:45] <BBB> oh it's signed
[16:45] <BBB> I thought it was unsigned
[16:45] <BBB> signed is much easier pavgb(x, zero)
[16:46] <BBB> oh wait no that was unsigned
[16:46] <BBB> duh
[16:46] <BBB> ok
[16:46] <BBB> hm
[16:46] <BBB> let me think
[16:46] <BBB> let's do pxor(pavgb((pxor(x, 0x80), zero), 0x80)
[16:52] <ubitux> how does the pavgb() works really? (x+(x<0?-1:1))/2 with x being i8?
[16:54] <nevcairiel> pavgb is unsigned, so simply (a+b+1)>>1
[16:56] <ubitux> if so, then the trick doesn't work
[16:56] <ubitux> but i'll figure out something
[17:08] <ubitux> psubb(pxor(psrlq(pand(x, 0xfe), 1), 0x40), 0x40)  this works for a signed x>>1
[17:09] <ubitux> it's basically similar to psubb(pxor(psrlq(pand(x, 0xf8), 3), 0x10), 0x10) for x>>3
[17:10] <ubitux> now if i do psubb(pxor(psrlq(pand(paddb(x, 1), 0xfe), 1), 0x40), 0x40) i will have one mismatch for x=127
[17:10] <ubitux> (only case mismatching)
[17:16] <BBB> why a mismatch? I mean, paddb and pand are sign-unaware
[17:16] <BBB> so 127 -> 128 -> 128
[17:17] <BBB> psrlq makes it 64
[17:17] <ubitux> mismatch with i=127 (unsigned:127): -64 ` 64
[17:17] <BBB> oh because you pxor and then sub
[17:20] <BBB>     uint8_t u = x;
[17:20] <BBB>     u += 0x80;
[17:20] <BBB>     u = (u + 1) >> 1;
[17:20] <BBB>     u -= 0x40;
[17:20] <BBB>     return u;
[17:20] <BBB> works for me
[17:21] <ubitux> oh :)
[17:21] <BBB> so psubb(pavgb(pxor(x, 0x80), zero), 0x40)
[17:21] <ubitux> great!
[17:21] <ubitux> thanks
[17:24] <iive> there is no byte wise shift, so you clear the bit that would move into the other byte. aka the 0xfe constant.
[17:25] <ubitux> iive: x is signed full range, and you need (x+1)>>1
[17:25] <ubitux> last suggestion from BBB works great :)
[17:25] <iive> i'm talking about some of the previous code...
[17:26] <ubitux> ok so it seems masks, filter2 and filter4 now work
[17:26] <ubitux> debugging the 2 remaining monsters.
[17:26] <BBB> lol
[17:27] <ubitux> actually, filter6() seems to work too
[17:27] <BBB> so filter14 is left?
[17:27] <BBB> that one is kinda big
[17:29] <ubitux> https://github.com/ubitux/FFmpeg/compare/vp9-lpf#diff-651121e4f3585d617f2de38cdfbcc3adR473
[17:29] <ubitux> not "that much"
[17:30] <ubitux> btw
[17:30] <ubitux> up to how much args can i have?
[17:31] <BBB> nice
[17:31] <BBB> lf is 30.9% of runtime now
[17:32] <BBB> args, you mean gprs?
[17:32] <BBB> cglobal name, args, gprs, xmms, [mem,] name1, name2, ...
[17:32] <BBB> gprs can be anything up to 7 on x86-32
[17:32] <BBB> and anything up to 15 on x86-64
[17:34] <BBB> I love that simd, very pretty
[17:34] <BBB> better commented than most stuff I write ;)
[17:34] <ubitux> i won't keep all comments
[17:34] <ubitux> at least not in that state
[17:34] <ubitux> that's just markers for debugging mostly
[17:35] <BBB> sure
[17:35] <BBB> http://pastebin.com/vEa2JZ9m
[17:35] <BBB> profile
[17:36] <ubitux> :)
[17:36] <ubitux> did you get this with perf?
[17:36] <BBB> I'm a maccie
[17:36] <BBB> I use instruments
[17:37] <ubitux> ah, ok
[17:37] <ubitux> and yeah i meant gprs, ok for 15, too bad i wanted 16 (and actually already wrote that value :p)
[17:38] <nevcairiel> its not too bad to load one or two args from the stack later on
[17:38] <BBB> e.g. https://developer.apple.com/library/mac/documentation/developertools/conceptual/instrumentsuserguide/Art/iprofiler_TP_result_2x.png
[17:39] <BBB> the values will be on stack anyway
[17:39] <ubitux> lol at the lcd style on top
[17:39] <BBB> anything after arg 6 is on stack (r15m)
[17:41] <BBB> or argm
[17:41] <BBB> e.g. cglobal name, 5, 5, 0, a,b,c,d,e,f,g
[17:41] <BBB> gm is the stack location of that argument
[17:42] <BBB> gmp is the same as <ptrsize>word gm
[17:42] <BBB> e.g. qword gm
[17:42] <ubitux> shouldn't it be 5,6,0 in this case?
[17:42] <BBB> yeah, I guess, or even 6, 6, 0
[17:42] <ubitux> ah well
[17:42] <ubitux> 6,7,0 i'd say
[17:42] <ubitux> g being local
[17:42] <ubitux> no?
[17:44] <ubitux> well anyway, i'll see later
[17:48] <BBB> 6,7 means load 6 arguments into registers, but reserve 7 registers
[17:49] <BBB> so it just depends on what you want :)
[17:49] <ubitux> i can't reserve 16 reg right?
[17:51] <BBB> no
[17:52] <BBB> just 15
[18:16] <Compn> starving the registers again? :)
[18:23] <ubitux> Compn: no it's fine
[18:23] <ubitux> i just wanted to do something nasty :p
[18:47] <wm4> it seems yadif is still broken with some input pixel formats, like 10 bit
[18:48] <nevcairiel> its intentional
[18:48] <JEEB> to get prores users to pay for an update? :D
[18:48] <nevcairiel> so that we can brand mark everyone that reports it as a interlace sympathizer
[18:48] <JEEB> (10bit 4:2:2)
[18:49] <wm4> why would an interlace sympathizer use yadif?
[18:51] <ubitux> yay it almost works
[18:52] <ubitux> it visually works, but not bitexact
[18:52] <ubitux> it's gonna be really fun to find the problem now
[18:53] <ubitux> wm4: it's broken because of the legal reverts
[18:53] <ubitux> iirc
[18:54] <nevcairiel> which can be reverted now :p
[18:54] <ubitux> https://trac.ffmpeg.org/ticket/3250
[18:54] <nevcairiel> post on the ML said that the agreement came in,a nd the reverts can be reverted
[18:55] <wm4> clearly a license change to make questionable external entities hapopy is much better than working code
[19:21] <cone-115> ffmpeg.git 03Michael Niedermayer 07master:5e0c7eab2a9d: avformat/oggdec: dont read timestamps from EOS pages of ogm videos
[19:22] <ubitux> http://b.pkh.me/vp9lpf-ref.png http://b.pkh.me/vp9lpf-out.png
[19:22] <ubitux> who wants to play the N differences game with me?
[19:23] <Daemon404> well first of all give us yuv
[19:23] <Daemon404> not rgb :P
[19:23] <Daemon404> cmp(1) that stuff!
[19:23] Action: Daemon404 runs
[19:25] <ubitux> :)
[19:29] <JEEB> michaelni, thank you :)
[19:33] Action: Daemon404 prods nevcairiel 
[19:34] <nevcairiel> wat
[19:34] <Daemon404> do you accept problem samples for our mkv demuxer code over irc?
[19:34] Action: Daemon404 runs
[19:34] Action: Daemon404 is :lazy:
[19:34] <Daemon404> s/our/your/
[19:34] <nevcairiel> sure
[19:34] <Daemon404> notice'd you it
[19:35] <Daemon404> plays fine with haalis mkv demuxer
[19:35] <Daemon404> borks with lav
[19:35] <Daemon404> seems ot be fine in vlc and mplayer
[19:35] <nevcairiel> define borks
[19:35] <nevcairiel> the timestamp mess?
[19:35] <nevcairiel> hm maybe its just vfr
[19:36] <Daemon404> it i vfr but thats never been an issue
[19:36] <Daemon404> it only happens wth native (non-vfw) mpeg4-asp
[19:36] <nevcairiel> so whats the issue with the file? :P
[19:36] <Daemon404> im dlgn to remember
[19:36] <Daemon404> <_<
[19:36] <Daemon404> it was very obvious
[19:36] <nevcairiel> despite the odd vfr timestamps it looks okish smooth and plays fine
[19:36] <Daemon404> oh right
[19:37] <Daemon404> it looked horribly not-smooth for me and JEEB 
[19:37] <Daemon404> i thought it ws the encode itelf, but it is fine with haali
[19:38] <JEEB> I'll retest with current git after I finish this thing
[19:38] <Daemon404> yeah its very obvious on e.g. the scrolling credits
[19:39] <nevcairiel> bet i can blame avformats timestamp code somehow
[19:39] <Daemon404> lol
[19:46] <nevcairiel> hm ok, every frame in the mkv has a proper timestamp and the demuxer outputs it too, most interestingly is that every frame has a duration of 41ms though :p
[19:47] <wm4> where's the sample?
[19:47] <Daemon404> wm4, noticed it to you
[19:47] <wm4> thanks
[19:48] <Daemon404> nevcairiel, it seems to be dropping frames maybe in the 30fps section
[19:48] <Daemon404> but the 24 fps sections are jerky too
[19:49] <nevcairiel> appears that avformat doesnt mess with the timestamps
[19:50] <nevcairiel> i get them out of avformat the same way the mkv reader has them
[19:50] <Daemon404> do they appear correct?
[19:50] <nevcairiel> well they are re-ordered, so its always hard to judge
[19:51] <Daemon404> ah
[19:52] <nevcairiel> i wonder
[19:52] <nevcairiel> found the difference
[19:53] <nevcairiel> i bet its those stupid peoples fault that mux vfw mpeg4
[19:53] <Daemon404> ?
[19:53] <Daemon404> as in hacks for vfw mpeg4 broke my native stream?
[19:53] <nevcairiel> kinda
[19:53] <nevcairiel> well
[19:54] <nevcairiel> vfw containers use dts timestamps
[19:54] <nevcairiel> and native uses pts
[19:54] <nevcairiel> so decoders usually can deal with both and need to somehow decide which to use
[19:54] <Daemon404> ... ew
[19:54] <nevcairiel> but since mpeg4 in avi is really quite common, thats probably the fallback
[19:54] <Daemon404> [18:54] <+nevcairiel> vfw containers use dts timestamps <-- thats pretty gross imo
[19:55] <nevcairiel> avi has no timestamps as such, so they cant have re-ordereing
[19:55] <JEEB> and yeah, most people muxed mpeg-4 part 2 from avi
[19:55] <nevcairiel> just a frame count and a timebase
[19:55] <wm4> and there's no way to get correct timestamps with lavf
[19:55] <Daemon404> well yes
[19:55] <wm4> err, lavc
[19:55] <JEEB> and mkvmerge just muxed everything as-is from avi
[19:55] <wm4> because lavc assumes mpeg style timestamps
[19:55] <JEEB> thus almost everyone encoding mpeg-4 part 2 ended up with avi-mkv
[19:55] <JEEB> ( Ÿ
[19:55] <nevcairiel> but no worries
[19:55] <nevcairiel> i can fix it
[19:56] <Daemon404> ;)
[19:56] <Daemon404> \o/
[19:56] <JEEB> nais
[19:56] <nevcairiel> mpeg4asp in mp4 for example is always native
[19:56] <nevcairiel> at least as far as i've seen
[19:56] <Daemon404> mpeg4 in mkv is easily distiguishable from vfw-mpeg in mkv
[19:56] <Daemon404> seems liek a 2 line fix
[19:56] <nevcairiel> yeah
[19:56] <nevcairiel> just need to figure out if that information is actually available where i need it
[19:57] <Daemon404> lavf should expose the matroska codec string no?
[19:57] <nevcairiel> not sure where it would be in
[19:57] <wm4> hehe, lavc probably has the same problem as nevcairiel 
[19:58] <wm4> or at least somewhat similar
[19:58] <nevcairiel> in the demuxer i have a "ms_compat" flag which is set for those vfw streams
[19:58] <nevcairiel> should add a private option to read it
[19:59] <wm4> e.g. if I use the lavf demuxer with my player, vfw muxed mkvs will have the wrong timestamp for the first frame, because the avi-style timestamps clash with lavc assuming mpeg style timestamps
[19:59] <nevcairiel> if my code knows that its getting dts timestamps it will simply handle them outside of lavc, so thats not a problem
[20:00] <nevcairiel> but it needs that information, which is the problem here :D
[20:00] <Daemon404> most of this seems the rsult if lavf insanity
[20:00] <Daemon404> afaik
[20:00] <Daemon404> s/if/of/
[20:00] <nevcairiel> not really
[20:01] <Daemon404> the dts handling in lavf has always been insane (in that its not really dts sometimes)
[20:01] <nevcairiel> its not lavfs fault that there are files with the same codec but different muxing modes which result in completely different timestamps
[20:01] <Daemon404> and shouldnt that be handled in the matroska demuxer
[20:02] <Daemon404> transparently
[20:02] <nevcairiel> whats the demuxer supposed to do? know about all codecs and generate pts from the dts encoded in the file?
[20:02] <wm4> Daemon404: the lavf mkv demuxer does return dts for vfw muxed shit, but lavc assumes it's mpeg style dts, which means the timestamps get "delayed" - which apparently means that mpeg streams starting at 0 have negative dts for the first frames
[20:02] <wm4> Daemon404: at least that was my problem wrt. difference between vfw muxed and native
[20:02] <Daemon404> nevcairiel, to an extent that its possible
[20:03] <Daemon404> vfw stuff is all sub-ids
[20:03] <Daemon404> with a common prefix
[20:03] <nevcairiel> but it cant generate pts
[20:03] <nevcairiel> it also shouldnt really
[20:03] <nevcairiel> it should output whats in the file
[20:03] <nevcairiel> and for mkv that usually works ok
[20:03] <Daemon404> yes but it cant have pts anyway
[20:04] <Daemon404> or expose some sort of dts == pts flag
[20:04] <Daemon404> wm4, the mpeg delay stuff has bit me a few times
[20:05] <wm4> so to handle avi timestamps correctly, I had to special case avi and vfw-mkv, and enable the old mplayer timestamp sorting code
[20:11] <nevcairiel> ah now the sample looks really smooth
[20:12] <nevcairiel> now i just need to find a vfw sample to make sure i didnt break those
[20:12] <JEEB> ugh, wanted to link you one but then remembered that it was highly VFR
[20:12] <JEEB> as in
[20:12] <JEEB> very loooong pictures
[20:12] <nevcairiel> i found one
[20:13] <wm4> JEEB: long pictures?
[20:13] <JEEB> wm4, http://www.cccp-project.net/beta/test_files/cbed_lavc_vfr.mkv
[20:14] <wm4> oh I see
[20:37] <ubitux> http://pastie.org/8601146
[20:37] <ubitux> b hello_gdb
[20:37] <ubitux> profit
[20:37] <ubitux> (yes, fuck gdb scripting)
[20:37] <nevcairiel> lol
[20:38] <nevcairiel> conditional break points in gdb are hard, i take it?
[20:38] <ubitux> i didn't even try
[20:39] <nevcairiel> do I just not see them, or did the yadif patches not reach the ML at all?
[20:40] Action: beastd doesn't see them too
[20:41] <Daemon404> nevcairiel, yeah i didnt either
[20:41] <Daemon404> they might be in moderation
[20:41] <nevcairiel> its a bit weird, since he said only one patch didnt show up for him, which is why i was confused
[20:41] <nevcairiel> but i guess so
[20:41] <Daemon404> i saw his post on libav's and went to look
[20:41] <Daemon404> and i saw nothing
[20:42] <nevcairiel>  I can see that the fourth patch with the actual license change
[20:42] <nevcairiel> has not made it to the list yet.
[20:42] <nevcairiel> that kinda implies the first 3 made it to the list
[20:42] <nevcairiel> but maybe i read it wrong =p
[20:43] <nevcairiel> also, i should really stop being lazy and publish a new release already
[22:06] <mark4o> michaelni: re oggparseopus issue:
[22:06] <mark4o> try: ffmpeg -i http://opus-codec.org/examples/samples/music_orig.wav -b:a 34k -vbr off -frame_duration 60 out.opus
[22:06] <mark4o> ffplay out.opus
[22:06] <mark4o> click middle of window to seek to middle
[22:25] <michaelni> does this need a specific version of libopus ?
[22:25] <Daemon404> i must ask
[22:25] <Daemon404> (unrelated)
[22:26] <mark4o> michaelni: I am using 1.1
[22:26] <Daemon404> why do we set the frame duration differently than libopus
[22:26] <Daemon404> by default
[22:26] <Daemon404> seems silly.
[22:26] <Daemon404> s/libopus/opus-tools/
[22:26] <michaelni> mark4o, i think its 1.0.1 here
[22:26] <michaelni> ill update it
[22:26] <mark4o> Daemon404: that was fixed to 20ms for ffmpeg.  I think it is still 10ms in libav.
[22:27] <Daemon404> oh so it was fixed
[22:27] <Daemon404> dice
[22:27] <Daemon404> er nice
[22:28] <mark4o> Daemon404: 74906d3727ec3bd9b7b28dfa7a98ff6e8cf8b6d7
[22:30] <mark4o> michaelni: yeah I think there were some CBR issues in older libopus versions, where it didn't output the exact rate that was requested
[22:31] <bais> there is a web gui for ffmpeg ?
[22:31] <michaelni> mark4o, i confirm its reproduceable with 1.1
[22:32] <Daemon404> g 30
[22:32] <mark4o> michaelni: ok cool
[22:46] <cone-115> ffmpeg.git 03Mark Harris 07master:262451878bab: avformat/oggparseopus: fix segmented timestamps
[00:00] --- Sun Jan  5 2014