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

[burek]

[00:00] <cone-688> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.1.4': unknown revision or path not in the working tree.
[00:00] <cone-688> Use '--' to separate paths from revisions
[00:00] <cone-688> refs/tags/n2.1.4:HEAD: Merge remote-tracking branch 'qatar/master'
[02:37] <cone-688> ffmpeg.git 03James Almer 07master:313a6c65b749: oggdec: validate VP8 keyframes
[07:39] <ubitux> BBB: seems your x86 32-bit statement was not very popular, but that was expected ;)
[08:39] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:a66be608883d: swresample: add swr_is_initialized()
[08:39] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:6c6e4dd13915: swr: check that the context for swr_convert() has been initialized
[08:39] <cone-707> ffmpeg.git 03James Almer 07master:3f3d748cab38: x86: Move XOP emulation to x86util
[08:47] <llogan> i know i've developed a problem when i begin typing words with two ff-s. "fflag".
[08:47] <llogan> *two "f"s
[09:20] <cone-707> ffmpeg.git 03Anton Khirnov 07master:746dca483a2f: avconv: support forcing codec tags for input streams
[09:20] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:cc6cc84bc4e0: Merge commit '746dca483a2f0f2639265f6e1c0085c8861875a1'
[09:20] <plepere> michaelni, I've redone my patches. Should I submit them back to ffmpeg-devel or just to you ?
[09:21] <michaelni> plepere, there where multiple people commenting, they couldnt comment if you submit them just to me
[09:22] <plepere> ok.
[09:23] <plepere> where do I be part of the mailing list once my changes are accepted ? I'll have to be part of it if ever someone asks something about the HEVC ASM
[09:26] <plepere> submitted
[09:27] <plepere> oh and found how to subscribe to ffmpeg-devel. :p
[09:33] <ubitux> plepere: did you the reviews from the others on ffmpeg-devel then?
[09:33] <plepere> I only had a reply from michaelni 
[09:34] <ubitux> only michael put you in cc i guess
[09:34] <ubitux> see http://ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154890.html and http://ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154870.html
[09:35] <plepere> ok thanks. :)
[09:39] <plepere> well,looks like I still have lots of work !
[09:43] <plepere> so now that I am part of the mailing list, I will see the other messages ?
[09:51] <cone-707> ffmpeg.git 03Anton Khirnov 07master:1155fd02ae7b: frame: add a convenience function for copying AVFrame data
[09:51] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:fff526230148: Merge commit '1155fd02ae7bac215acab316e847c6bb25f74fc3'
[09:55] <cone-707> ffmpeg.git 03Michael Niedermayer 07release/2.1:c7c724056ef4: avcodec/h264: clear chroma planes when flags gray is used
[10:19] <ubitux> trac down again?
[10:47] <cone-707> ffmpeg.git 03Anton Khirnov 07master:8feac29cc462: lavc: use AVFrame API properly in ff_reget_buffer()
[10:47] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:74bb1ca82c3b: avutil/frame_copy_audio: also check that channels match
[10:47] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:7a9946d386a3: Merge commit '8feac29cc46270cc89d6016340e7bac780877131'
[10:55] <plepere> michaelni, I've changed some stuff as indicated in the other reviews. not all of them, as rsbultje suggested something that would require some higher-level changes. Do I have to redo a new e-mail ?
[10:56] <michaelni> plepere, best to talk to / ask BBB (rsbultje)
[10:56] <plepere> ok
[10:57] <michaelni> ubitux, trac seems up ?
[10:58] <cone-707> ffmpeg.git 03Anton Khirnov 07master:30517a9f056c: Use av_frame_copy() to simplify code where appropriate.
[10:58] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:2a3cb1cfcaf4: Merge remote-tracking branch 'qatar/master'
[10:58] <ubitux> michaelni: OperationalError: database is locked
[10:58] <plepere> well the question was more like : I've submitted an e-mail this morning without seeing all of the reviews. can I submit another e-mail now that I've seen the other reviews and fixed most things ?
[10:59] <michaelni> plepere, yes of cousre you can
[10:59] <nevcairiel> your previous mail didn't show up on the mailing list yet anyway :p
[11:00] <plepere> ok. :)
[11:08] <plepere> there, sent
[11:08] Action: plepere crosses fingers
[11:10] <ubitux> there are a lot of unrelated cosmetics...
[11:10] <ubitux> like, what the hell happened in hevcdsp_template.c?
[11:11] <plepere> changed epel and qpel C functions
[11:11] <ubitux> i'm not talking about that
[11:11] <ubitux> look at your diff
[11:11] <plepere> hmmm
[11:11] <ubitux> it's like you based your work on an old ffmpeg
[11:11] <ubitux> and didn't rebase correctly
[11:12] <ubitux> also, just squash the patches
[11:12] <ubitux> and split them appropriately
[11:13] <plepere> oh yeah. sorry. :/
[11:14] <ubitux> i see the patches honoring a bunch of my comment; you should just squash them in the original patch
[11:14] <plepere> ok, so I do a single patch with the different commit messages ?
[11:15] <ubitux> well you'll probably keep only one message for all the changes
[11:15] <ubitux> of course, if it makes sense to split, do it
[11:15] <ubitux> but don't send additional patches after each iteration
[11:15] <ubitux> the split should be feature/bug wise, not review-iteration wise
[11:15] <plepere> ok
[11:23] <ubitux> trac repaired, cool
[11:36] <plepere> ubitux : can I send you the new patch files before doing again another mail ? 
[11:37] <ubitux> send "me"? why? :)
[11:37] <plepere> I'm embarassed of sending plenty of mails. :/
[11:37] <ubitux> just spam, no worry
[11:37] <plepere> ok ok
[11:38] <nevcairiel> we all started somewhere, every time you learn more, and the next time you won't need as many mails :)
[11:38] <plepere> yeah. :)
[11:39] <plepere> well I haven't (yet) forgotten to add the attached files. :D
[11:39] <plepere> voila !
[11:40] <plepere> bbl
[11:40] <nevcairiel> Now that you are subscribed to the ML, what you should do when sending new versions is trying to respond to your previous mail, so its clear that its a new version
[11:40] <plepere> ok. I'll try to think of that next time.
[11:41] <nevcairiel> from a brief look, the first patch at least looks better now, no unrelated formatting changes or anything like that
[11:44] <nevcairiel> it might make sense to split the second in two, one for qpel/epel and one for MC
[11:46] <nevcairiel> oh there is only the pel functions in there, nevermind then
[11:46] <nevcairiel> i got confused
[11:46] <ubitux> plepere: try to reply in the thread you started though, that's easier to track
[13:05] <BBB> ubitux: re: 32bit asm, yes I expected some comments re: that
[13:06] <BBB> ubitux: and I basically don't care - if someone wants to port it, please do, I think it's an awesome idea; but I don't think I'll want to do it myself, at least not right now
[13:06] <ubitux> oh i agree you know
[13:06] <ubitux> > Especially compared to VP9 which seems to encode using a wooden abacus
[13:06] <BBB> plepere: you know, all these macros make the main code very hard to understand, right?
[13:06] <ubitux> seems i'm not alone ^ \o/
[13:06] <BBB> lol
[13:07] <BBB> plepere: asm is nice to read if you can see exactly from the cglobal what it does, typically only idct does this differently because idct uses the same loop x2
[13:07] <BBB> (or iadst)
[13:07] <BBB> plepere: but I'll read your new patches before saying anything more...
[13:08] <BBB> plepere: do you have numbers on how much faster the mc functions for each size get, or decoding in general on a particular clip that uses mc a lot?
[13:19] <plepere> BBB : I can do some tests. we usually use ra_main basketballDrive qp 27 for our performance tests.
[13:28] <BBB> plepere: sure, pick whatever you want :)
[13:28] <BBB> plepere: pick something you like - you'll be using it for a long time to come :-p
[13:28] <plepere> time make fate-hevc SAMPLES=samples/ -j 6 gives me 17.543 without ASM and 15.056 with.
[13:29] <smarter> if you do that your testing both the decoder and the performance of your OS scheduler :]
[13:29] <smarter> *you're
[13:29] <plepere> ok ok
[13:30] <smarter> you can use ffmpeg -benchmark -i ...
[13:30] <smarter> -f null -
[13:31] <plepere> is it useful to test single threaded performance ? or should I just settle with the default settings ?
[13:31] <smarter> single threaded is useful yes
[13:31] <plepere> -threads 1 right ?
[13:31] <smarter> I think so
[13:31] <BBB> plepere: we typically do asm changes with single threading
[13:31] <BBB> time ffmpeg -threads 1 -i file -f null -v 0 -nostats -
[13:32] <BBB> or if you use START/STOP_TIMER, use -v error
[13:32] <BBB> (otherwise it won't print anything)
[13:33] <plepere> it still seems multi-threaded. I might need to tweak the thread_type
[13:33] <BBB> default is frame
[13:33] <BBB> that should be ok
[13:33] <BBB> but don't use multithreaded to measure asm changes
[13:34] <plepere> I've got the same times with or without threads 1. :/
[13:34] <plepere> and they are too good to be single threaded
[13:34] <smarter> what about -threads 0 ?
[13:35] <plepere> same
[13:35] <BBB> it's -threads 1, before -i
[13:35] <BBB> what's your exact commandline?
[13:35] <plepere> ah, before -i.
[13:35] Action: plepere facepalms
[13:35] <BBB> order matters :)
[13:35] <BBB> anything before -i is input
[13:36] <BBB> anything after -i is output
[13:36] <plepere> ok. :)
[13:37] <plepere> 21.552
[13:38] <plepere> 26.377
[13:38] <plepere> nice speed-up. :D
[13:38] <smarter> nice.
[13:38] <smarter> do you know if MC is still the bottleneck?
[13:39] <plepere> in our home-version, we are looking into the intra-pred now
[13:39] <smarter> cool
[13:39] <plepere> the intrinsics really boost the decoding.
[13:40] <BBB> depends on intra rate, clearly
[13:40] <plepere> I'm around 8.5 seconds on this sequence on our latest version I think
[13:40] <smarter> just because of intra intrinsics?
[13:41] <plepere> no
[13:41] <plepere> with everything enabled
[13:41] <plepere> on BasketBallDrive qp27
[13:41] <plepere> ra
[13:42] <BBB> I think this whole "working on 2 repositories" is a terrible idea
[13:42] <BBB> that might just be me, I don't know
[13:42] <BBB> I wonder if the intrinsics automatically unroll the h-loop in MC, which should give more gains
[13:42] <BBB> if you didn't unroll it already in your next patch
[13:43] <plepere> BBB : the problem is that for a single idx, there can be multiple widths
[13:43] <sspiff> ubitux: I remember somebody worked on the teletext subtitle codec the past few months. Is there a way I can get in touch with him?
[13:43] <BBB> plepere: what is an idx
[13:43] <plepere> it's the index we use to know how large the block is (and therefore calling the h4, h8 or h16)
[13:44] <BBB> so it's block size, and then each block has some form of partitioning?
[13:44] <plepere> it's from the log of the size coding block
[13:44] <BBB> so which widths exist in a idc of, say, h16?
[13:44] <smarter> 8x16 and 16x16 only I think
[13:44] <sspiff> anyone else is free to help me as well, of course. I just remember ubitux mentioned the work, so I figured he would know.
[13:44] <BBB> oh, h=height?
[13:44] <plepere> 32 and 64
[13:44] <BBB> refactor the code so w is constant
[13:44] <BBB> unroll more levels if uyou have to
[13:45] <BBB> fixed width is immensely important
[13:45] <plepere> well the problem is when the width has values like 12 or 24
[13:46] <plepere> BBB : I'm going to see which widths are associated to which index. I can unloop those with a singlewidth value
[13:46] <plepere> or do you think an if/else at the start of the function could be enough ?
[13:47] <ubitux> sspiff: git log -i --grep teletext raises Serhii Marchuk and Marton Balint as last contributors
[13:47] <smarter> plepere: in what case is width 12 or 24?
[13:47] <plepere> like in h4, width = 4 or 12. I do an in/else on width to the correct function
[13:48] <plepere> I think it goes like this : h2 => w = 2 or 6. h4 : w= 4 or 12. h8 : w = 8 or 24; h16 : w = 16, 32, 64
[13:50] <sspiff> ubitux: thanks. Sorry about the useless question.
[13:56] <plepere> so I could do an if/else in each function to know if we're on one width or another
[13:57] <BBB> plepere: 12 is simlpe: 8 and 4
[13:57] <BBB> plepere: 24 is even easier, assuming it's all in 8-width iterations: 3x8 (i.e. 8, 8, 8)
[13:57] <plepere> all are pretty simple.
[13:57] <plepere> BBB : I have a 16 width iteration
[13:58] <BBB> right, but the loop takes enormous overhead if you don't unroll it, esp. for such small loops
[13:58] <BBB> 16 pixels per iter?
[13:58] <plepere> so I  can do 16 + 8
[13:58] <BBB> or 16 bits per iter?
[13:58] <plepere> yes
[13:58] <BBB> hm, ok, 16 + 8 is even better then
[13:58] <plepere> 16 pixels
[13:58] <plepere> since the source is 8-bit, I can grab 16 per load
[13:59] <plepere> of course, once you go to 10-bit, you only go up to 8
[13:59] <BBB> sure, I guess it's the same as vp9's 16width unroll, it's essentially 2 8 combined right?
[13:59] <BBB> becuase the intermediates must be 16 bits
[13:59] <plepere> I do 2 stores, but the rest is the same, yes
[14:00] <BBB> 2 stores?
[14:00] <BBB> why
[14:00] <BBB> you can packuswb in the end right?
[14:00] <plepere> output of qpel/epel is on 16-bit
[14:00] <BBB> or is that b/c weighting requires 16bit input?
[14:00] <plepere> yes
[14:00] <BBB> ok
[14:01] <plepere> so unless we put the weighting in the pel functions...
[14:01] <BBB> which we should :-p
[14:01] <BBB> eventually
[14:01] <plepere> but that's a huge chunk of work, and the number of functions quadruples
[14:01] <BBB> sure, if it helps speed, that's totally ok
[14:02] <BBB> (helps by a _lot_, not by 1-2 cycles per block)
[14:02] <plepere> we did the change in intrinsics, but did not see any significant change
[14:02] <BBB> well yes, but
[14:02] <BBB> intrinsics
[14:02] <BBB> I mean, lol
[14:02] <plepere> :p
[14:03] <BBB> you have no idea what actually changed in terms of real code
[14:03] <BBB> ok work, bbl
[14:03] <BBB> I'll try to look at your patches
[14:03] <plepere> it's faster than C . :D
[14:03] <plepere> thanks a bunch, BBB
[14:03] <nevcairiel> if you dont use the compound intrinsics, in my experience it maps pretty nicely to asm, at least in MSVC, no experience with GCC
[14:14] <kurosu_> plepere: have you rewritten SAO to use pshufb? it may be non-negligible too
[14:15] <kurosu_> 26s -> 21s decoding seems a bit low if the 26s used C code for MC - but what do I know
[14:15] <plepere> the sao is being worked on too.
[14:15] <plepere> kurosu_, it's only epel_h, epel_v, epel_hv, qpel_h, qpel_v.
[14:16] <plepere> so all the idct, weighting and all aren't done
[14:16] <plepere> so it's "only" the 4 and 8 tap filters being done in ASM in that patch
[14:16] <plepere> and the 8-tap HV isn't done either.
[14:40] <kurosu_> plepere: vc1 and rv40 were closer to eg 26->17 without the rest being optimized
[14:40] <kurosu_> but probably hevc is needlessly complex in other parts :D
[14:42] <plepere> we did some other high level C optimizations, and as BBB noted, I'm not unrolling the loops in assembly
[14:42] <kurosu_> 8 tap HV? you mean only the 1D filtering (either vertical or hor) is done? then it makes sense
[14:42] <plepere> yes, the 2D isn't done.
[14:42] <plepere> the 2D 4-tap is done though
[14:42] <kurosu_> that's like half of them and probably the most consuming ones
[14:42] <plepere> :)
[14:42] <kurosu_> if they aren't done yet, the timing makes more sense
[14:42] <plepere> ok ok
[14:42] <kurosu_> I expect closer to 17 once they are done
[14:43] <plepere> I'll have to see how to make everything fit in 15 xmm registers first !
[14:43] <kurosu_> I have no idea, as I haven't looked at the code
[14:43] <plepere> it's my job. 
[14:43] <plepere> :D
[14:44] <kurosu_> are you loading the filter coefficients in regs? if yes, you can probably skip loading them and just do pmaddusb xmm, [filter]
[14:44] <kurosu_> (or whatever the insn name is)
[14:44] <plepere> kurosu_, well I'm loading them once, so I don't have to do it in the loop
[14:45] <kurosu_> yeah, but they are eating regs you seem to be in greater need of
[14:45] <plepere> I'll remember to do that if I'm in need of registers. :)
[14:45] <kurosu_> anyway, I'm uninformed on the topic of your asm so I'm probably spewing nonsense :)
[14:47] <plepere> I'll look how they do it in vp9. they look like competent people.
[14:58] <sspiff> how can I change codec-private options? I've tried av_opt_set() on an AVCodecContext (where I get AVERROR_OPTION_NOT_FOUND), and on an AVCodec (where it succeeds, or at least returns 0, but segfaults down the line...)
[14:59] <sspiff> is the latter approach correct, and is this just a bug in the codec?
[14:59] <sspiff> or is there a third option I'm missing?
[14:59] <nevcairiel> use AVCodecContext->priv_data
[15:06] <smarter> <plepere> I think it goes like this : h2 => w = 2 or 6. h4 : w= 4 or 12. h8 : w = 8 or 24; h16 : w = 16, 32, 64
[15:06] <smarter> I'm confused by these numbers, when exactly do you have something that has width 6 ?
[15:08] <plepere> in BasketBallDrive, ra, qp27
[15:08] <plepere> I've added a printf giving me H and W in epel_h
[15:08] <plepere> and I've got numerous instances of H= 2 W = 6
[15:09] <plepere> anyways, I've got to go. sorry.
[15:09] <plepere> I'll read when I'm coming back
[15:09] <smarter> but prediction blocks can't be 6x2
[15:09] <smarter> or is it something to do with edges?
[15:10] <plepere> yes, it's strange. I'd rather not have such cases too. I'll see with mraulet.
[15:11] <plepere> well when I say H, it's unrelated to the height of the block
[15:11] <plepere> it's just the name of the function
[15:11] <plepere> sorry for the confusion
[15:12] <smarter> ah, I forgot about the weird inter-only Prediction Blocks
[15:12] <plepere> basically,     int idx = log2_cb_size - 2; for idx = 0, we use h2, for idx = 1, we use h4, idx = 2, h8
[15:13] <plepere> but that means that for idx = 0, we have width = 2 or 6
[15:13] <plepere> really gtg. leave me PMs
[15:13] <smarter> which can be split into things like w=x,h=4*x and w=3*x,h=4*x
[15:13] <smarter> bye!
[15:20] <sspiff> nevcairiel: so privdata is in fact not private?
[15:21] <nevcairiel> you want to set a codec private option, they are in priv_data, since thats the codec private data :p
[15:21] <nevcairiel> so use that as the first param of the av_opt functions
[15:21] <sspiff> nevcairiel: so I'm doing something I shouldn't do, generally?
[15:21] <nevcairiel> why
[15:22] <sspiff> I don't know, I generally thought I shouldn't mess with priv_data/priv/... fields in structs?
[15:22] <sspiff> by the way, is there any reason why the av_opt_set call succeeds on the AVCodecContext?
[15:26] <nevcairiel> if it makes you feel better inside, you can also call it on AVCodecContext directly and set the AV_OPT_SEARCH_CHILDREN flag in the last param, it'll automatically descend into priv_data then
[15:27] <nevcairiel> i guess this is more of the "official" way to do  it
[15:28] <julienb> Hello
[15:28] <julienb> I contact the room because i would like to know if it's possible to cut videos from the end with ffmpeg.
[15:28] <av500> wrong room, use #ffmpeg
[15:29] <julienb> ok thanks
[15:44] <sspiff> nevcairiel: thanks for the tip :)
[17:00] <Daemon404> "Especially compared to VP9 which seems to encode using a wooden abacus 
[17:00] <Daemon404> (~1.4 minutes per frame).
[17:00] <Daemon404> i loled irl
[17:01] <ubitux> i quoted it earlier :))
[17:01] <thardin> hah
[17:11] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:d3736471948c: libx265: Update API usage
[17:11] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:d102925a6d4a: libx265: Support 4:4:4
[17:13] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:73ee4cf3073b: libx265: Support SAR
[17:13] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:87769d6c8f6d: libx265: Properly handled dynamic linking with MSVC
[17:13] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:6d18154f61d1: libx265: Use proper error code
[17:14] <Daemon404> slow bot is slow
[17:15] <nevcairiel> shouldnt x265 init internal bitdepth to something useful on its own
[17:15] <sspiff> hmmmm, building ffmpeg doesn't produce ffplay for me, and there doesn't seem to be a makefile for it. Configure seems to have a --disable-ffplay, but --enable-ffplay didn't work. How do I build ffplay?
[17:15] <nevcairiel> you're probably lacking a dependency
[17:15] <nevcairiel> ffplay needs SDL
[17:17] <ubitux> we should probably add an entry in the faq
[17:17] <ubitux> that ffplay is often asked
[17:17] <ubitux> not sure ppl look that much into that faq though
[17:17] <nevcairiel> ideally configure could  somehow tell you
[17:18] <nevcairiel> if you ask for an explicit --enable-ffplay, it tells you when something is missing
[17:20] <ubitux> the difference between explicit user request and enabled feature is always a bit tricky with the build system
[17:22] <Daemon404> g 31
[17:22] <Daemon404> ffs
[17:26] <sspiff> nevcairiel: thanks. I didn't read the FAQ for this I must admit.
[17:26] <nevcairiel> I have no clue whats in the FAQ or isnt
[17:27] <nevcairiel> never read the thing
[17:27] <sspiff> nevcairiel: ./configure produces a lot of output, so if the warning is early on, I probably missed it
[17:27] <nevcairiel> it  probably doesnt warn
[17:27] <nevcairiel> but it should
[17:27] <sspiff> it doesn't
[17:27] <sspiff> I just checked
[17:28] <sspiff> not even sure the --enable-ffplay is really a thing (./configure --help doesn't mention it)
[17:28] <sspiff> but I assume ./configure wouldn't just disregard non-existant flags
[17:28] <nevcairiel> its technically a thing, but ffplay is also enabled by default
[17:28] <nevcairiel> but of course only build when deps are present
[17:29] <Daemon404> the better question is
[17:29] <Daemon404> why do you want to use ffplay
[17:29] <Daemon404> its uselss to everyone but devs
[17:29] <nevcairiel> I only use it for occasional testing, easier than trying to transcode with ffmpeg and viewing the resulting file for artifacts :p
[17:29] <ubitux> Daemon404: testers?
[17:29] <kierank> useful for mucking around with libavfilter
[17:29] <Daemon404> aka devs
[17:29] <kierank> not really
[17:29] <ubitux> no, bug reporters
[17:29] <sspiff> Daemon404: testing, I'm writing a subtitle tool thing, and I'm encountering issues with libzvbi-teletext
[17:30] <kierank> for your filter chains
[17:30] <ubitux> and indeed testing filter chains
[17:30] <ubitux> i actually use it as a user... for looking at images now
[17:30] <sspiff> works fine in VLC's zvbi codec, but subtitle pages are said to be empty by ffmpeg
[17:30] <Daemon404> im going to go out on a limb and say most bug reporters cant build things
[17:30] <ubitux> since feh (imlib2) doesn't seem to support tga and bmp correctly here
[17:30] <kierank> Daemon404: there are packages
[17:30] <Daemon404> ubitux, i use feh too
[17:31] <Daemon404> but why do you want ta
[17:31] <Daemon404> tga*
[17:31] <Daemon404> lul
[17:31] <ubitux> because there are a lot of tga in the wild?
[17:31] <Daemon404> well i use feh solely or desktops
[17:31] <Daemon404> i.e. bg
[17:31] <Daemon404> no as an image viewer
[17:31] <ubitux> i use it to look as an image viewer
[17:31] <ubitux> but ffplay is actually better ;)
[17:31] <Daemon404> is thats the best foss has to offer, then it is a sad world
[17:32] <sspiff> ubitux: that's kind of ... depressing
[17:32] <ubitux> anyway, ffplay is useful when ppl report bugs in mplayer/mpv/vlc because it crashes in libavwhatever
[17:32] <ubitux> "does it work with ffplay?"
[17:32] <wm4> sspiff: AFAIK ffmpeg's teletext decoder has some issues with multiple pages
[17:32] <sspiff> wm4: it only picks up one page (888)
[17:32] <wm4> sspiff: the subtitle decoder interface wasn't made for it
[17:32] <Daemon404> g 42
[17:32] <wm4> not sure how this was solved
[17:32] <wm4> maybe you have to explicitly request a page or something
[17:33] <sspiff> wm4: you can, but by default it produces subtitles for all pages
[17:33] <sspiff> which, well, wouldn't work well if there were actually other pages.
[17:33] <sspiff> I think
[17:33] <sspiff> right now, it seems like my PES stream contains only page 888
[17:33] <sspiff> but ffmpeg thinks they're all transparant spaces
[17:34] <wm4> this stuff is relatively new
[17:34] <sspiff> while VLC, using the same VBI parser (zvbi) actually produces subtitles
[17:34] <wm4> so there might be bugs
[17:34] <sspiff> wm4: I'm fine with bugs & fixing them. I'm pretty sure this is a bug I'm encountering.
[17:35] <sspiff> I'm just not very good at asking the right/proper questions and getting answers :)
[17:35] <sspiff> And maybe I should look harder at the code :)
[20:08] <JEEB> did FFmpeg get into GSoC?
[20:09] <Daemon404> isnt the list public
[20:10] <nevcairiel> if the list is complete already, then no
[20:13] <Daemon404> [FFmpeg-devel] Fw: [FFmpeg] Your organization application has been rejected.
[20:14] <Daemon404> shocking
[20:14] <thardin> :/
[20:14] <Daemon404> nobody expected it to be accepted
[20:15] <tbarletz> Daemon404: how com?
[20:16] <tbarletz> come, even
[20:18] <JEEB> k
[20:18] <JEEB> so as expected
[20:19] <J_Darnley> Same reason as last year?  They won't want to take sides on the FFmpeg-Libav war?
[20:20] <wm4> lol gsoc
[20:20] <Plorkyeran_> libav didn't apply this year though
[20:26] <iive> did I miss the party? http://tech.slashdot.org/story/14/02/23/0544243/ffmpegs-vp9-decoder-faster-than-googles
[20:27] <llogan> GWoT: Google Waste of Time
[20:28] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:a908de7f4944: avformat/options_table: add named constants for avoid_negative_ts
[20:28] <iive> gsoc was really beneficial. It brought quite a few good developers who stayed around after the task.
[20:37] <Mavrik> hmm, do we have any sample of a TS file with DTS wraparound?
[21:02] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:d00a504b244e: libx265: Update API usage
[21:02] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:a88cbdfb90e4: Merge commit 'd00a504b244e136a0c82a55e21ed94659e0674ad'
[21:03] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:2142b2efcd63: libx265: Support 4:4:4
[21:03] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:3d53bbd0ac06: Merge commit '2142b2efcd631db05e4c7c26785e337ecf1258ff'
[21:05] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:0f7fa48cf1a3: libx265: Support SAR
[21:05] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:e1991c7d5f3a: Merge commit '0f7fa48cf1a36ed135c9e0cb01a6b84179aea25b'
[21:07] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:8aca00cc2b25: libx265: Properly handled dynamic linking with MSVC
[21:07] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:e66247e926aa: Merge commit '8aca00cc2b25810bdd85b75f5632844a5614b707'
[21:09] <rcombs> Mavrik: <24 hours later>
[21:15] <Mavrik> ^^
[21:17] <nevcairiel> TS timestamp wrap is at 26 hours, duh :p
[21:44] <cone-707> ffmpeg.git 03Anton Khirnov 07master:67f2a688143b: avconv: remove a write-only variable
[21:44] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:70a25587d223: Merge commit '67f2a688143b644f99360565a9f36c61a5f052e9'
[21:56] <Mavrik> indeed >(
[22:00] <wm4> TS wraparound sucks and I'm still not sure how to handle it robustly
[22:03] <Mavrik> mhm, that's why I'm asking if anyone has a sample of it... otherwise I'm off to waiting 26hrs :P
[22:03] <Daemon404> nevcairiel and kierank maybe?
[22:03] <Daemon404> wh do you want one? because you want to see ffmpeg murder itself?
[22:03] <kierank> wm4: the proper way to do it is to maintain a timestamp file
[22:03] <kierank> with an index
[22:04] <Daemon404> set top boxes obvious dont do this
[22:04] <wm4> kierank: I mean just for playback
[22:04] <wm4> which set top boxes do
[22:04] <kierank> Daemon404: why?
[22:05] <Daemon404> because how can a live stream be indexed?
[22:05] <kierank> a live stream is different
[22:05] <kierank> because you don't need to seek
[22:05] <Daemon404> true
[22:06] <Daemon404> the index should be pretty easy in theory
[22:06] <Daemon404> getting lavf to not fuck with stuff might be harder
[22:06] <wm4> lol
[22:06] <wm4> utils.c?
[22:08] <nevcairiel> the problem is that stuff records live streams and doesnt write an index file, and people of course expect playing and seeking them
[22:09] <wm4> seeking could be done somewhat reasonably if the API allowed relative seeking
[22:09] <wm4> so seeking would mean "skip 5 seconds of video", not "seek to time XX:XX:XX"
[22:10] <nevcairiel> people like full random access
[22:10] <cone-707> ffmpeg.git 03Anton Khirnov 07master:dcc7e4bf1d09: af_resample: preserve frame properties
[22:10] <wm4> if they just want interactive seeking around, byte based seeking can handle that just fine
[22:11] <Daemon404> something something ffms2
[22:11] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:fc10ed2cac71: Merge commit 'dcc7e4bf1d0913123bfafbc58bf47bd41dd5848d'
[22:11] <nevcairiel> unsuitable for playback daemon404
[22:11] <Daemon404> in which way
[22:11] <Daemon404> i rigged it up for playback before
[22:11] <nevcairiel> huge startup
[22:12] <nevcairiel> delay
[22:12] <Daemon404> basically your complain is "indexing"
[22:12] <Daemon404> which was my point
[22:19] <cone-707> ffmpeg.git 03Anton Khirnov 07master:39c2880eeae6: af_volume: preserve frame properties
[22:19] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:6b06f9f1bc4c: Merge commit '39c2880eeae6930b1036ce1f479afc1e1152c13f'
[22:28] <cone-707> ffmpeg.git 03Vittorio Giovara 07master:48d1ed9c83ee: doc: name correct header
[22:28] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:26dad980baaa: Merge commit '48d1ed9c83ee0c388e8c2898e81ffb4add509ab9'
[23:06] <cone-707> ffmpeg.git 03Vittorio Giovara 07master:c91488ab3367: doc: fix one accented word
[23:06] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:75f6ed8dc232: Merge remote-tracking branch 'qatar/master'
[00:00] --- Tue Feb 25 2014