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

[burek]

[00:13] <durandal_1707> michaelni: i need frame->nb_samples to follow exactly same pattern as described in specification
[00:15] <ubitux> michaelni: are you in the middle of a merge?
[00:19] <durandal_1707> probably, because stack is full
[00:20] <durandal_1707> ... more that 10 entries....
[00:28] <cehoyos> Hi! Is there a bug in ticket #2484 or do I miss someting?
[00:28] <ubitux> cehoyos: options not transmitted
[00:28] <cehoyos> options not transmitted?
[00:29] <ubitux> known limitations to our playlist-like demuxer
[00:29] <ubitux> oh wait
[00:29] <cehoyos> Sorry, I don't understand...
[00:29] <ubitux> wrong bug
[00:29] <ubitux> sorry forget what i said
[00:29] <cehoyos> Is that #2485 you are talking about?
[00:29] <ubitux> yeah
[00:29] <cehoyos> Since I don't understand #2485, it would be great if you could comment
[00:29] <ubitux> keyboard derp
[00:30] <ubitux> yeah i'll do eventually
[00:30] <cehoyos> Is is a duplicate of another ticket?
[00:30] <cehoyos> s/Is is/Is it
[00:30] <ubitux> not really
[00:30] <cehoyos> But it is reproducible?
[00:31] <ubitux> if there is a related ticket, it's hls options thing
[00:31] <cehoyos> Will the fix be the same?
[00:31] <ubitux> anyway, it's just a guy from my previous company, so i'm a bit lazy to get active on the ticket
[00:31] <ubitux> that's more a design limitation, maybe a hack can be added but well..
[00:31] <cehoyos> I see. Am I correct that #2484 is a bug, or do I miss something?
[00:32] <cehoyos> (My question is mostly; Was atempo never tested?)
[00:32] <ubitux> i never used it, can't help you
[00:33] <cehoyos> I wonder if the most common use-case isn't PAL-NTSC conversion, and it appears that it can't do that.
[00:33] <cehoyos> (But as said: I may absolutely misunderstand something.)
[00:34] <durandal_1707> the guy who write it is still active
[00:34] <cehoyos> Can video filters buffer frames?
[00:34] <durandal_1707> sure
[00:34] <cehoyos> So is the comment in ticket #1430 wrong?
[00:34] <durandal_1707> i read that vid. thing, and i decided to stay away from it
[00:35] <cehoyos> You have a point...
[00:36] <durandal_1707> but don't push it...
[00:38] <michaelni> ubitux, no iam not in the middle of a merge
[00:39] <ubitux> ok i can push then
[00:39] <cone-429> ffmpeg.git 03Clément BSsch 07master:0f1250b7e52f: lavc/gif: make possible to disable offsetting.
[00:39] <cone-429> ffmpeg.git 03Clément BSsch 07master:e1b35bdde2fc: lavc/gif: add flag to enable transparency detection between frames.
[00:39] <cone-429> ffmpeg.git 03Clément BSsch 07master:5927ebab513d: doc/general: animated GIF are now compressed.
[00:39] <cone-429> ffmpeg.git 03Clément BSsch 07master:7004cad36df2: Changelog: notify GIF improvements.
[00:39] <cone-429> ffmpeg.git 03Clément BSsch 07master:f5ede48fbb41: lavc/gif: miscellaneous cosmetics.
[00:39] <cone-429> ffmpeg.git 03Clément BSsch 07master:a16c20569db6: lavf/gifdec: add loop support.
[00:39] <cone-429> ffmpeg.git 03Clément BSsch 07master:67cc31d6c74b: lavf/gif: add final_delay option.
[00:39] <ubitux> here we go, i'm done with gif
[00:40] <durandal_1707> but 2pass
[00:40] <ubitux> whatever
[00:40] <ubitux> it's good enough for me
[00:40] <cehoyos> Did you mention somewhere (Changelog?) that the gif muxer does not support rawvideo anymore?
[00:40] <ubitux> nope..
[00:40] <durandal_1707> i seriosly doubt anyone used that encoder ....
[00:41] <ubitux> my gif sample went from 3M to < 400kB
[00:41] <ubitux> and that's not violent optim
[00:41] <ubitux> using the rawvideo muxer previously was definitely a bad idea :P
[00:42] <cehoyos> What used the rawvideo muxer previously?
[00:42] <durandal_1707>  /* better than nothing gif encoder */ :)))))
[00:43] <durandal_1707> cehoyos: gif muxer
[00:51] <durandal_1707> ugh, i must add more pixel formats to stereo3d so i can dump down3dright
[00:53] <durandal_1707> ubitux: funny. but does ffmpeg -i in.gif -codec copy out.gif works?
[00:55] <ubitux> mmh good question
[00:56] <ubitux> might need some adjustments :)
[00:56] <ubitux> it doesn't seem to work previously anyway
[00:57] <durandal_1707> the only case it would be useful is to change delay thing...
[01:09] <durandal_1707> ubitux: gonna add yourself to (c)?
[01:12] <ubitux> i don't really care
[01:12] <ubitux> should i?
[01:12] <durandal_1707> dunno...
[01:14] <ubitux> btw
[01:14] <ubitux> what do i do about timeline?
[01:14] <ubitux> i need that feature :(
[01:16] <durandal_1707> outvote?
[01:17] <ubitux> well, i just have nicolas that isn't really excited about that
[01:18] <ubitux> i got reviews from stefano, so well the code is ready
[01:18] <ubitux> but... no explicit lgtm or anything
[01:18] <ubitux> durandal_1707: not interested in the feature?
[01:19] <durandal_1707> feature - yes, implementation - so, so
[01:19] <ubitux> what would you prefer?
[01:20] <durandal_1707> that everyone is happy
[01:20] <ubitux> of course
[01:23] <durandal_1707> nevcairiel: what is this BLZ0 fourcc?
[02:45] <cone-429> ffmpeg.git 03Michael Niedermayer 07master:8ebfd7c49e44: h264: remove unused variable
[02:45] <cone-429> ffmpeg.git 03Michael Niedermayer 07master:a0fbc28c3881: vc1dec: Fix non pullup tff
[02:45] <cone-429> ffmpeg.git 03Michael Niedermayer 07master:6c9d28a2294d: vc1dec: Fix tff == 0 handling in init_block_index()
[02:58] <Compn> highgod is writing a vp8 gpu decoder, thats pretty awesome :)
[02:58] <Compn> i wonder for what video card?
[03:13] <kierank> amd i think
[03:13] <kierank> amd seem to be sending a ton of money to that company
[03:58] <highgod> Hi,I want to ask a question, how can I set the value in HAVE_LIST, such as that I add a CL_CL_H to detect whether there is a cl/cl.h exist 
[03:59] <highgod> @Compn:about the vp8 decoder,hehe, the performance is very low, and the result is not correct
[04:01] <iive> you've implemented vp8 decoder in opencl?
[04:02] <highgod> we want to, but it is so hard to use GPU to implement
[04:04] <highgod> and we are doing the work, it is very hard
[04:05] <iive> why is it hard? gpu are not good when code needs to branch a lot?
[04:06] <oneal> Yes, gpu doesn't good at the codes with more branch
[04:07] <oneal> this is limited by the gpu architecture.
[04:08] <highgod> GPU is not suitable for the data which has a strong correlation
[04:09] <highgod> So, can anyone give me some help on the configure thing? hehe, I am not familiar with the configure,hehe I reference the openjpeg, but still can't set the value
[04:11] <drv> add a check_header line down by check_header direct.h, then add an entry in HAVE_LIST
[04:16] <highgod> OK, I will try it, thanks
[04:17] <Skyler_> eesh, doing a video decoder on a gpu sounds very difficult
[04:19] <highgod> @drv:sorry, I can't find the direct.h file
[04:20] <iive> maybe a hybrid one would be more feasible. doing MC, quant/idct/pp look like tasks that could easily be done in parallel.
[04:21] <drv> highgod: sorry, that is a line in 'configure' :)
[04:21] <drv> as is the HAVE_LIST variable
[04:21] <highgod> @iive:what is pp?
[04:22] <iive> post processing
[04:22] <iive> like loop filter
[04:22] <Skyler_> iive: idct+predict can at best be done in wavefront order, it's very hard to get enough parallelism (because of the dependencies with intra pred)
[04:22] <oneal> Yes, MC, quanti/idct can be one in parallel.
[04:23] <Compn> what about using the driver api itself
[04:23] <Compn> without going into opencl
[04:23] <Compn> not even sure ati has open api on windows...
[04:23] <Compn> just to offload the mdct or cabac
[04:23] <Compn> (or whatever vp8 uses)
[04:23] <Compn> that shares with h264
[04:23] <oneal> but gpu can have a speedup just in the case of enough data to be processed by GPU.
[04:23] <Skyler_> um... both nvidia and amd use ASIC decoders that do the whole process basically
[04:24] <Skyler_> and are programmed by microcode on the graphics card
[04:24] <Skyler_> vp8 doesn't use the same idct as h264, nor the same entropy coder
[04:24] <Skyler_> nor the same prediction (very /similar/, but not the same)
[04:24] <Skyler_> nor the same MC, nor the same deblock...
[04:24] <oneal> in the pipeline of decoder, there is a strict serial process procedure.
[04:25] <Compn> Skyler_ : darn, i thought something was similar :\
[04:25] <highgod> @drv:OK, find it, thanks
[04:25] <Skyler_> they're similar, but not in ways that are really useful
[04:27] <oneal> I have tried to optimze the inter-predication and MC. but there is a dependency between the MC in a frame. 
[04:27] <highgod> @drv: it works, thanks
[04:29] <oneal> the design I have done is all blocks which to be process by inter predicton is done in one function(like OpenCL kernel).
[04:30] <leo2013> hello
[04:30] <leo2013> ?
[04:31] <Compn> yo
[04:31] <leo2013> I met one problem in vp8
[04:31] <oneal> we assume the blocks inter-predicted just dependent the reference block in the reference frame. in fact, there is a dependency from the adjacent mb. 
[04:32] <leo2013> My problem is that the edge processing.
[04:33] <leo2013> for the input image whose size is 1920*1080
[04:33] <leo2013> the 1080 can't be dived well by 16
[04:33] <leo2013> so that it'll be the 67.5 blocks.
[04:33] <leo2013> and for the last block 68
[04:33] <leo2013> we have half block in dst.
[04:34] <leo2013> but the edge processing will fill it by using 16*16
[04:34] <oneal> in this case, it should to be paded to 16 multiple
[04:34] <leo2013> so that the overflow for more than 8 lines.
[04:34] <leo2013> I checked that mc_fun[][]
[04:35] <leo2013> this function in one mode is that only copy the data to dst.
[04:35] <Skyler_> cropping is done after decoding
[04:35] <Skyler_> e.g. the buffer is allowed to be 1920x1088; the decoder should not have to special-case that internally
[04:35] <Skyler_> (h264 and all similar formats have the same kind of thing)
[04:36] <leo2013> but the height of dst is 1080.
[04:36] <Skyler_> then there's something wrong; you should be allocating a frame of the size of the decoded video, not the size of the displayed video
[04:38] <weixuan> the dst comes from the decoded video, not the displayed video   the height of it is 1080
[04:39] <Skyler_> um... you decide in your decoder what frame size to allocate, unless I'm totally missing something
[04:39] <Skyler_> because that's how every decoder works
[04:39] <Skyler_> look at how vp8.c does cropping, or how h264.c does cropping
[04:40] <leo2013> #define PUT_PIXELS(WIDTH) \
[04:40] <leo2013> static void put_vp8_pixels ## WIDTH ##_c(uint8_t *dst, ptrdiff_t dststride, uint8_t *src, ptrdiff_t srcstride, int h, int x, int y) { \
[04:40] <leo2013>     int i; \
[04:40] <leo2013>     for (i = 0; i < h; i++, dst+= dststride, src+= srcstride) { \
[04:40] <leo2013>         memcpy(dst, src, WIDTH); \
[04:40] <leo2013>     } \
[04:40] <leo2013> }
[04:40] <Skyler_> ?
[04:40] <leo2013> in ffmpeg,vp8 will use this func.
[04:40] <Skyler_> yes...?
[04:40] <leo2013> yes.
[04:40] <Skyler_> that's a C implementation of the 00 MC position
[04:40] <leo2013> yes.
[04:40] <leo2013> that the c implementation for 00
[04:40] <Skyler_> but what does this have to do with post-decode cropping?
[04:41] <leo2013> that'll overflow for the last line.
[04:41] <Skyler_> erm, no it won't
[04:41] <leo2013> if the last block value can't get dived well.
[04:41] <Skyler_> No, again, it won't.
[04:41] <leo2013> why?
[04:42] <leo2013> dst height is 1080, and the block after padded is 1088
[04:42] <Skyler_> dst height is 1088
[04:42] <Skyler_> Your video has a coded size of 1920x1088.
[04:42] <Skyler_> Your video has a DISPLAY size of 1920x1080.
[04:43] <Skyler_> Your video could, in theory, have a display size of 532x362, with a coded size of 1920x1088 (this is possible with h264, for example)
[04:43] <leo2013> no,the codes size is 1984*1088
[04:43] <leo2013> so it's 124 block in horizonal.
[04:44] <Skyler_> Um....
[04:44] <Skyler_> how did it go from 1920 to 1984?
[04:45] <leo2013> I used the av_log to check the real width.
[04:46] <leo2013> s->mb_width
[04:46] <weixuan> 1984 is the linesize of the y plane
[04:47] <weixuan> and it is the decoder video linesize
[04:47] <Skyler_> Linesize is not width!
[04:47] <weixuan> yes
[04:47] <Skyler_> They are two different things.
[04:47] <leo2013> yes.
[04:48] <leo2013> but it's calculated in mc_fun
[04:48] <leo2013> in the func:mc_func[0][0](dst, linesize, src + y_off * linesize + x_off, linesize, block_h, 0, 0);
[04:48] <leo2013> just like you see,for block 68,the block_h is 16
[04:48] <Skyler_> ???? that function has nothing to do with what you're talking about
[04:48] <Skyler_> that's the height of a macroblock, which has nothing to do with cropping frames
[04:49] <leo2013> where does the other data(more than 8 lines) come from ?
[04:49] <iive> i actually don't remember how MC handled the down/right edges. does it emu_edge/pad on the visible image boundary or on MB boundary? 
[04:49] <Skyler_> You're confusing the coded and display resolution again.
[04:49] <Skyler_> iive: the spec itself does decoding to the coded size
[04:49] <leo2013> the other data(more than 8 lines) will come from ref-frames.
[04:50] <Skyler_> Your decoder literally does not know it is possible to create frames that are not divisible by 16.
[04:50] <Skyler_> If your decoder knows this, your decoder is written incorrectly.
[04:50] <Skyler_> Cropping is done after decoding.
[04:50] <iive> fair enough.
[04:50] <Skyler_> The actual specification dictates that decoding is done on the coded frame, not the display frame.
[04:50] <iive> i assume that encoders should pad the extra pixels before encoding.
[04:51] <Skyler_> actually.  I'm 98% sure of that.  Need to confirm it's true for VP8, I'd assume it is, but
[04:51] <leo2013> yes.but before the cropping, need loopfilter.
[04:51] <leo2013> the loopfilter use the filled data from dst in the last block line,right?
[04:51] <Skyler_> Yes, loopfilter is part of decoding.  It is not something that happens after decoding.
[04:51] <Skyler_> This is why it is called a loopfilter.
[04:52] <Skyler_> okay, confirmed, the code in MC does this:
[04:52] <Skyler_>     int width = 16*s->mb_width, height = 16*s->mb_height;
[04:52] <Skyler_> VP8 operates the same way as H.264 then.
[04:52] <Skyler_> From the perspective of the decoder, all decoding is done on a plane of macroblocks whose width and height are divisible by 16 pixels.
[04:53] <iive> things are much simpler this way :)
[04:53] <Skyler_> After the decoder is done, it says "oh, and by the way, you should only display 1920x1080 of this, not 1920x1088 of this."
[04:53] <Skyler_> But for the decoder, decoding a 1920x1080 and 1920x1088 stream is exactly, precisely, identical.
[04:53] <Skyler_> In fact, if the decoder doesn't do it that way, its output won't be correct.
[04:54] <leo2013> yes.so the width and the hieight will be cropping results.but for the last block line,it depends the ovreflow parts,right?
[04:54] <Skyler_> What do you mean?
[04:54] <Skyler_> Yes, the decoder will use parts of the frame that are not displayed.  This is by design, and the decoder does not know about this or care.
[04:54] <leo2013> we decoded the last block line.
[04:55] <leo2013> in fact, the last block line is 8 lines for input(1080p)
[04:55] <iive> only half of the last block line would be shown.
[04:55] <leo2013> how about the overflow 8 lines in dst[0]?
[04:55] <Skyler_> *sigh* how many times do I have to repeat myself before you will read what I am saying?
[04:55] <leo2013> yes.you're right.
[04:55] <iive> but it is decoded as a whole
[04:55] <leo2013> but how to fill it?
[04:55] <Skyler_> The same way you fill any other chunk of memory, by writing to it?
[04:56] <iive> it is not decoder problem.
[04:56] <leo2013> only filled the last 8 lines according to 8 lines in dst[0]?
[04:57] <Skyler_> *sigh*
[04:57] <iive> leo2013: imagine this. you get 1920x1080 before encoding. you expand it to 1920x1088 and encode it.
[04:57] <leo2013> we haven't more than 8 lines data to fill it.
[04:57] <Skyler_> What do you mean?
[04:57] <Skyler_> Your reference frame is 1920x1088.
[04:57] <Skyler_> Your current frame is 1920x1088.
[04:57] <Skyler_> All your frames are 1920x1088.
[04:57] <Skyler_> If they're not, your code is incorrect and will not decode VP8 correctly.
[04:57] <iive> you always decode 1920x1088 and then cut the last 8 lines.
[04:57] <leo2013> I want to know where the data comes from for the last 8 lines?
[04:58] <Skyler_> Um, you create it.  You're the decoder.
[04:58] <Skyler_> Your job is to decode the video
[04:58] <Skyler_> which means decoding the pixels coded in the video file...
[04:58] <iive> leo2013: the data is padded (filled) before encoding.
[04:58] <Skyler_> which includes those last 8 lines.
[04:58] <Skyler_> for a total of 1920x1088.
[05:01] <oneal> leo2013: the encoded video stream contains 1920x1088, not the 1920x1080.
[05:02] <Skyler_> exactly !
[05:03] <iive> Skyler_: btw does x264 repeat the edge pixels, when padding like this?
[05:04] <Skyler_> yup
[05:04] <Skyler_> I tried some other approaches (e.g. mirroring), but inter prediction makes mirroring a lot worse than repeating
[05:04] <Skyler_> in pure intra mode it might help?  I'm not sure if I tried that (I think JPEG generally does repeating)
[05:05] <iive> ok, i'm off
[05:06] <leo2013> your mean my reference frame is the 1920*1088 too?
[05:06] <Skyler_> correct
[05:07] <leo2013> and the key frame is 1920*1088 to fill the refrence frame.
[05:07] <oneal> Skyler, what's mean of "I tied some other apporache(e.g. mirroring), but inter prediction makes mirroring a lot worse than repeating"
[05:08] <Skyler_> oh, it's not related to what you're doing, but the encoder gets to decide how to fill those padded pixels (to pad up to divisible-by-16)
[05:08] <Skyler_> the easy way is padding, but in theory there could be something smarter
[05:08] <leo2013> so the padded data(8 lines) comes from key frame which more than 1080.
[05:08] <Skyler_> JPEG encoders typically use a technique called mirroring where they "mirror" the pixels over the edge, instead of repeating the last line over and over
[05:08] <Skyler_> but I found this was pretty useless for video.
[05:09] <oneal> oh, I understand what's you mean
[05:09] <Skyler_> so basically, the encoder gets 1920x1080, and needs to turn it into 1920x1088
[05:09] <Skyler_> in the way that takes the fewest possible extra bits.
[05:09] <Skyler_> the decoder then decodes it to 1920x1088, and throws away the last 8 lines when it's done, to get 1920x1080 again.
[05:23] <leo2013> In emulated_edge_mc,for(; y<end_y; y++){
[05:23] <leo2013>         memcpy(buf, src, w*sizeof(pixel));
[05:23] <leo2013>         src += linesize;
[05:23] <leo2013>         buf += linesize;
[05:23] <leo2013>     }
[05:25] <leo2013> the end_y can be 21, and the src is from 1071, so when copy src to buf, it'll be more than 1088.
[05:47] <Skyler_> leo2013:     end_y = FFMIN(block_h, h-src_y);
[05:47] <leo2013> I met another problem in vp8 is the edge processing in inter_predict.Especially for the last block line in emulated_edge_mc.There will be the possibility of overflow when fill the td->edge_emu_buffer.
[05:48] <leo2013> yes.
[05:48] <leo2013>  end_y = FFMIN(block_h, h-src_y);
[05:48] <leo2013> this min value can be 21
[05:48] <leo2013> 21 for Y
[05:49] <leo2013> 8+8+5
[05:50] <Skyler_> What is block_h?
[05:50] <leo2013> block_h is 16
[05:51] <leo2013> h-src_y
[05:51] <Skyler_> What is the maximum value of MIN(16,x)?
[05:55] <leo2013> block_h + subpel_idx[1][my]
[05:55] <leo2013> but if the block_h is 21,how about it?
[05:55] <weixuan> block_h + subpel_idx[1][my]
[05:56] <weixuan> and the block_h = 16 and the subpel_idx[1][my] = 5
[05:56] <weixuan> so the final value of the block_h = 21
[05:57] <weixuan> so it will overflow the range of the src
[05:57] <leo2013> static const uint8_t subpel_idx[3][8] = {
[05:57] <leo2013>     { 0, 1, 2, 1, 2, 1, 2, 1 }, // nr. of left extra pixels,
[05:57] <leo2013>     { 0, 3, 5, 3, 5, 3, 5, 3 }, // nr. of extra pixels required
[05:57] <leo2013>     { 0, 2, 3, 2, 3, 2, 3, 2 }, // nr. of right extra pixels
[05:57] <leo2013> };
[05:57] <Compn> you guys have to talk to BBB-
[05:57] <Compn> hes the vp8 guy :)
[05:58] <Compn> i am not, and its time for me to sleep. night and good luck :)
[05:58] <Compn> probably michaelni knows something about it as well 
[05:58] <leo2013> extra pixels required
[05:58] <Skyler_> except, no.
[05:58] <Compn> and of course Skyler_ :)
[05:58] <Skyler_> end_y = FFMIN(block_h, h-src_y); 
[05:58] <Skyler_> put simply:
[05:59] <weixuan> good night
[05:59] <Skyler_> The loop you pointed to copies the pixels that do not need to be emulated.
[05:59] <Skyler_> The MIN() statement says "we don't copy more pixels than we need rows of pixels (obviously)"
[05:59] <Skyler_> that's the h-src_y part
[05:59] <Skyler_> er, correction
[05:59] <Skyler_> that's the block_h part
[05:59] <Skyler_> h-src_y is the constraint on the number of rows available.
[05:59] <Skyler_> But the inner workings of emulated_edge_mc aren't actually important; it's probably easier to understand _what_ it does than how it works.
[06:00] <Skyler_> All it does is "if a pixel is off the frame, calculate it to be equal to the closest pixel that is on the frame".  That's it.
[06:00] <Skyler_> It's a bit obfuscated, yes <.<
[06:02] <leo2013> I found there are sevral blocks fit that condition extra.the over the bottom of scr,what's the nearest value could be gotten?
[06:03] <Skyler_> The phrasing I used is equivalent to "any pixel past the edge is equivalent to what you'd get if you padded the edge by repeating the last line over and over"
[06:03] <Skyler_> So this generally leaves you with two options in a codec:
[06:04] <Skyler_> 1) pad the edges of the frame with the last line/column, repeated ~16 times or however many is necessary to guarantee correct behavior.  Don't implement emulated_edge_mc.
[06:04] <Skyler_> Advantage: faster MC, no extra special case
[06:04] <Skyler_> Disadvantage: requires, well, padding every fram
[06:04] <Skyler_> *frame
[06:04] <Skyler_> 2) emulated_edge_mc, which eliminates the need for padding.
[06:04] <Skyler_> I think technically you need about 19 lines of padding because of subpel.
[06:05] <Skyler_> I think vp8 used to support both, but 1) was eventually removed due to not being faster?  I'm not sure.
[06:05] <Skyler_> But which one you do is totally your choice.
[09:53] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:68d8238cca52: hpeldsp: Add half-pel functions (currently copies of dsputil)
[09:53] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:23de9e91df1c: Merge commit '68d8238cca52e50e8cc81bf2edcaf8088c52d4c0'
[10:08] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:3bd062bf7f81: vp3: Use hpeldsp instead of dsputil for half-pel functions
[10:08] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:cb7ecb75635d: vp56: Use hpeldsp instead of dsputil for half-pel functions
[10:08] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:8f992dc8c7c5: indeo3: Use hpeldsp instead of dsputil for half-pel functions
[10:08] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:0f0a11d5768e: bink: Use hpeldsp instead of dsputil for half-pel functions
[10:08] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:8071264f2196: interplayvideo: Use hpeldsp instead of dsputil for half-pel functions
[10:08] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:3c6621708b93: Merge commit '8071264f2196d71ff49c3944c33f8d3d83f548f1'
[10:22] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:c10470035e60: mimic: Use hpeldsp instead of dsputil for half-pel functions
[10:23] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:6caa44aa7df0: svq1: Use hpeldsp instead of dsputil for half-pel functions
[10:23] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:f4fed5a2f97e: mpegvideo: Use hpeldsp instead of dsputil for half-pel functions
[10:23] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:2f6bc5f7c193: svq3: Use hpeldsp instead of dsputil for half-pel functions
[10:23] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:ab4ba6b74d9e: Merge commit '2f6bc5f7c193477c2ebc0acce8f2d5551445e129'
[12:50] <saste> ubitux: comments on interleave?
[13:05] <ubitux> saste: ok, will do in a moment
[13:05] <ubitux> thanks for the timeline reviews btw
[13:28] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:1277dc07fbe6: svq1enc: Use hpeldsp instead of dsputil for half-pel functions
[13:28] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:28bc406c84b0: mjpeg: Use hpeldsp instead of dsputil for half-pel functions
[13:28] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:3fee9fa02232: Merge commit '28bc406c84b04a5f1458b90ff52ddbec73e46202'
[13:44] <durandal_1707> michaelni: so any ideas for s302m?
[13:46] <saste> ubitux: ffplay IN -vf "select='if(gt(random(0), 0.2), 1, 2)':n=2 [tmp], edgedetect, [tmp] interleave"
[13:48] <durandal_1707> michaelni: if not, i will push it with experimental flag and be done with it... (hoping others can fix it...)
[13:50] <michaelni> durandal_1707, iam not sure how to solve it best, a s302 muxer would be an option instaead of a encoder, or a private option that contains the frame rate but that would need a change in ffmpeg*.c to set it, i also dont mind if you push with the flag ...
[13:51] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:8db00081a37d: x86: hpeldsp: Move half-pel assembly from dsputil to hpeldsp
[13:51] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:d0aa60da1022: Merge commit '8db00081a37d5b7e23918ee500bb16bc59b57197'
[13:53] <durandal_1707> michaelni: s302m muxer is useles, how would you than put it in ts?
[13:54] <michaelni> the s302 muxer would have to pass the stuff into a ts muxer, not sure how that would look
[13:54] <durandal_1707> whats wrong with internal approach that when variable frame size flag is set than interleave thing sets frame size that s320m expects?
[13:55] <durandal_1707> or additional flag could be introduced
[13:55] <michaelni> what interleave code exactly do you speak of ?
[13:56] <durandal_1707> whatever code that sets frame->nb_samples when its 0 in init
[13:57] <michaelni> my concern is just that complexity should not be moved into the user application
[13:57] <michaelni> that is the encoder or avcodec or avformat should do thze work
[13:58] <michaelni> needing every user app to have code to get the interleaving right would be annoying, thats why i asked which code you meant ...
[13:59] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:47e5a98174eb: ppc: hpeldsp: Move half-pel assembly from dsputil to hpeldsp
[13:59] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:055e5c8e01c5: Merge commit '47e5a98174eb9c07ad17be71df129719d60ec8b7'
[13:59] <durandal_1707> so variable frame flag just means user app can set wheterever it wants?
[14:03] <durandal_1707> saste: buffer queue overflows do not happens with interleave anymore?
[14:04] <michaelni> durandal_1707, about var-frame within limits id say yes
[14:05] <durandal_1707> michaelni: and it can't be changed after set in init, because for some fps, it cant be same for every frame, so it goes 161,162,161,162 or similar
[14:05] <durandal_1707> so the only way how it can be currently handled is from user app
[14:07] <durandal_1707> hmm, it can be changed ..., from decoder, but from encoder and without flag?
[14:08] <durandal_1707> it simply can't, or i'm missing something?
[14:08] <durandal_1707> so its API limitation
[14:09] <durandal_1707> i could do internaly buffering ...
[14:10] <ubitux> saste: ok, will try soon, but first: since i'm lazy, do you have a out-of-box working command injection test?
[14:10] <ubitux> (i've restored the enable command, and now for all filters)
[14:10] <ubitux> (supporting the timeline of course)
[14:14] <michaelni> durandal_1707, yes internal buffering may be an option 
[14:21] <saste> ubitux: out-of-box working command injection test??
[14:21] <saste> I use sendcmd to test process_command() callbacks
[14:22] <ubitux> yeah it's ok i've finally made one
[14:25] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:7384b7a71338: arm: hpeldsp: Move half-pel assembly from dsputil to hpeldsp
[14:25] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:c4010972c4a7: Merge commit '7384b7a71338d960e421d6dc3d77da09b0a442cb'
[14:26] <durandal_1707> kierank: could you provide useful file with s302m codec for coverage test? (the one i found is 0 only)
[14:27] <kierank> not sure if i can make any s302m public
[14:27] <kierank> i think vlc have some
[14:29] <kierank> you have the spec folder access, right?
[14:29] <durandal_1707> where?
[14:29] <kierank> oh apparently not
[14:29] <kierank> do you have dropbox
[14:31] <kierank> https://dl.dropboxusercontent.com/u/2701213/Specs/SMPTE/SMPTE%20Standards/s302m-2007.pdf
[14:32] <kierank> whatever you end up doing in ffmpeg, i'll probably have to make a small fork of s302m because i need to set the frame size manually
[14:34] <durandal_1707> kierank: why?
[14:36] <durandal_1707> in that case i just leave code as is, (it will obviosly need changes in ffmpeg ....)
[14:36] <durandal_1707> and where are those vlc's s302m samples?
[14:39] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:bfb41b5039e3: bfin: hpeldsp: Move half-pel assembly from dsputil to hpeldsp
[14:39] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:c5a11ab6d106: Merge commit 'bfb41b5039e36b7f873d6ea7d24b31bf3e1a8075'
[14:55] <durandal_1707> hmm, what about w3fdif deinterlacer from FFmbc?
[14:55] <kierank> durandal_1707: because 302m is used for low latency and so i get frames with 1601, 1602, 1601 etc. I will need to pass whether i am 1601 or 1602 straight from hardware
[14:56] <kierank> durandal_1707: in vlc samples repo i guess
[14:57] <durandal_1707> sorry, i dont know where that is
[15:01] <kierank> http://streams.videolan.org/ somewhere but i can't seem to find it
[15:09] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:278bd2054ca6: sh4: hpeldsp: Move half-pel assembly from dsputil to hpeldsp
[15:09] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:4bdec0e71edc: Merge commit '278bd2054ca61ab70dfe38f1774409cda2da5359'
[15:13] <durandal_1707> kierank: well private option to not use interneal buffering at could be added, leaving it to the calling code
[15:20] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:78ce568e43a7: sparc: hpeldsp: Move vis half-pel assembly from dsputil to hpeldsp
[15:20] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:fdb1f7eb7a80: Merge commit '78ce568e43a7f3993c33100aa8f5d56c4c4bd493'
[15:27] <ubitux> saste: hey the blur effect is awesome :)
[15:27] <ubitux> i believe you can do the same with enable now though :)
[15:27] <durandal_1707> how you repeat Nth frame  X times?
[15:30] <ubitux> ./ffplay ~/samples/matrixbench_mpeg2.mpg -vf "boxblur=enable='if(gt(random(0), 0.2), 0, 1)'"
[15:30] <ubitux> hehe
[15:30] <ubitux> durandal_1707: from the cmdline?
[15:30] <durandal_1707> how that can be useful?
[15:30] <durandal_1707> ubitux: with lavfi
[15:31] <ubitux> maybe we could ajudst copy to re-inject the same frame
[15:31] <ubitux> re-inject each frame copied N times
[15:31] <ubitux> (and use enable to make the copy only once)
[15:31] <durandal_1707> FFmbc have repeatframe
[15:32] <ubitux> (durandal_1707: the boxblur thing make some kind of wave effect)
[15:32] <ubitux> (so that's awesome)
[15:33] <ubitux> durandal_1707: how can this dup thing be useful?
[15:34] <durandal_1707> dup thing?
[15:34] <ubitux> repeatframe
[15:34] <ubitux> what you are talking about
[15:34] <durandal_1707> filter from FFmbc
[15:34] <ubitux> yes but what is the purpose?
[15:35] <durandal_1707> to repeat frame
[15:35] <ubitux> what for?
[15:36] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:2957d29f0531: alpha: hpeldsp: Move half-pel assembly from dsputil to hpeldsp
[15:36] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:6ec26157b96b: Merge commit '2957d29f0531ccd8a6f4378293424dfd92db3044'
[15:42] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:54cd5e4f92de: dsputil: Remove hpel functions (moved to hpeldsp)
[15:42] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:d2d2c309e8f3: Merge commit '54cd5e4f92de6bd0fb8e24069153b0156c8136bc'
[15:42] <durandal_1707> ubitux: to repeat single image with blend filter....
[15:50] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:c443117f25e0: dsputil: Remove dct_bits
[15:50] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:c3624cfe7638: Merge commit 'c443117f25e034c1e3ef35334b61b937e1e208ff'
[15:54] <ubitux> http://lucy.pkh.me/youtube-free.webm youtube and my ISP, yepee.
[15:55] <ubitux> 0kb/sec regularly ffs
[15:55] <ubitux> (i can in practice download up to 1.6MBytes/sec)
[15:59] <Compn> ubitux : dang
[16:00] <Compn> ubitux : throttling ?
[16:00] <ubitux> it's been like this since about 2 years
[16:00] <ubitux> it's particularly painful nowadays
[16:01] <ubitux> Compn: it's a ping pong about who will pay between google & my isp
[16:01] <Compn> too bad you cant use youtube over https
[16:01] <Compn> the video urls still seem to be http
[16:01] <Compn> html over https tho
[16:01] <ubitux> it's the same with https
[16:02] <Compn> hows the speed on googlevideo or vimeo ?
[16:03] <ubitux> it's fine most of the time for vimeo
[16:03] <ubitux> (googlevideo still exists?)
[16:03] <Compn> yeah they were going to kill it, but then didnt
[16:03] <Compn> but the last video i tried to watch there was missing or unavailable
[16:03] <Compn> they were thinking about migrating it to youtube, but i dunno current status
[16:04] <Compn> they pestered me about moving my single video to youtube, which i finally did
[16:04] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:619e0da19119: dsputil: Remove unused 32-bit functions
[16:04] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:f6dcd844ee65: Merge commit '619e0da19119bcd683f135fe9a164f37c0ca70d1'
[16:06] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:c9f5fcd08c3a: dsputil: Merge 9-10 bpp functions for get_pixels and draw_edge
[16:06] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:bf66016e4c03: Merge commit 'c9f5fcd08c3a33bfb1b473705c792ab051e7428d'
[16:20] <cone-132> ffmpeg.git 03Ronald S. Bultje 07master:d4d186d185df: dsputil: Remove non-8bpp draw_edge
[16:20] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:9ae56b85b664: Merge commit 'd4d186d185df98492d8935a87c5b5cf369db9748'
[16:24] <cone-132> ffmpeg.git 03Martin Storsjö 07master:287c8db39e71: cosmetics: bfin: Fix indentation in the dsputil init function
[16:24] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:0e3d2b2c8d02: Merge commit '287c8db39e71af7047e551bbfd1264d771cccbc9'
[16:28] <saste> btw there will be socis this year?
[16:29] <saste> in case we are going to propose something very much space oriented (like the star mapper proposed by michaelni)
[16:29] <j-b> saste: ping
[16:29] <saste> j-b: pong?
[16:32] <cone-132> ffmpeg.git 03Martin Storsjö 07master:a60136ee570c: vc1: Remove now unused variables
[16:32] <cone-132> ffmpeg.git 03Martin Storsjö 07master:b71a0507b01e: x86: Remove unused inline asm instruction defines
[16:32] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:0dd25e46996d: Merge remote-tracking branch 'qatar/master'
[16:59] <BBB-> ?
[17:06] <Compn> just gpu devs looking for vp8 help 
[17:11] <kierank> durandal_1707: who's  Darryl Wallace?
[17:13] <BBB-> hm I'll respond to the ML again
[17:14] <BBB-> next time they're on IRC, please ask them for samples. I don't like the thought of a bug at all, better to confirm quickly or just confirm that it's a bug on their end
[17:16] <Compn> sounds like it was a bug on their end with edge emulation and display res
[19:24] <durandal_1707> kierank: the guy who added pull request on ffmpeg github mirror
[19:24] <kierank> ah
[19:27] <durandal_1707> michaelni: how fast is subsampled yuv to unsubsampled yuv conversion in sws?
[19:37] <xlinkz0> can i ask library usage questions here? #ffmpeg seems to be pretty dead
[19:39] <michaelni> durandal_1707, someone would have to benchmark 
[19:40] <funman> win 15
[19:49] <cone-132> ffmpeg.git 03Paul B Mahol 07master:a56fd051ee64: lavfi/stereo3d: support more formats for non-anaglyph outputs
[19:57] <cone-132> ffmpeg.git 03highgod0401 07master:fdad04e75628: avfilter/deshake_kernel: fix reset value bug of deshake kernel
[21:08] <michaelni> j-b, "http://download.videolan.org/pub/contrib/c99-to-c89/" seems dead (https://ffmpeg.org/trac/ffmpeg/ticket/2487)
[21:09] <michaelni> s/dead/404/
[21:11] <funman> there's https://github.com/mstorsjo/c99-to-c89
[21:11] <funman> dunno if we should make a tarball
[21:12] <funman> ah apparently it was binaries
[21:12] <michaelni> yep, the link from github.com/mstorsjo/c99-to-c89 points also to videolan for binaries
[21:12] <michaelni> same 404
[21:13] <funman> i can't find that folder somewhere else on the ftp, i guess it has been deleted..
[21:13] <funman> j-b: was it you?
[21:13] <j-b> no, but I think it was a weird old script
[21:14] <j-b> I'll re-put that in place
[21:15] <cehoyos> j-b: Hi, is there a reason why the c99-wrap.exe binaries disappeared from http://download.videolan.org/pub/contrib/c99-to-c89/
[21:15] <cehoyos> ?
[21:16] <cehoyos> nevcairiel: Could we provde the binaries you use on ffmpeg.org ?
[21:16] <funman> cehoyos: you just missed the conversation ^_^
[21:16] <cehoyos> (Iirc, this is the third download location that disappeared)
[21:16] <funman> 21:14 <@j-b> I'll re-put that in place
[21:16] <funman> 21:14 -!- cehoyos [~cehoyos at chello080108089202.30.11.tuwien.teleweb.at] has joined #ffmpeg-devel
[21:16] <cehoyos> Enlighten me please
[21:16] <cehoyos> ok, thank you!
[21:17] <cehoyos> Ah, you mean "just" as in "really just" =-)
[21:36] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:4824aea7afd4: avcodec/mpegvideo: change asserts to av_asserts
[22:09] <cone-132> ffmpeg.git 03Marton Balint 07master:40693ba3ac3f: ffplay: simplify aspect ratio calculation
[22:09] <cone-132> ffmpeg.git 03Marton Balint 07master:d148339d19c6: ffplay: use AV_NOPTS_VALUE video frame pts instead of using 0
[22:09] <cone-132> ffmpeg.git 03Marton Balint 07master:b8facbeecb66: ffplay: only do early frame drop if video queue is not empty
[22:09] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:eda61abc846b: Merge remote-tracking branch 'cus/stable'
[22:15] <cehoyos> ubitux: I never tried to reproduce ticket 2446, could you test and close the ticket if it is fixed?
[23:03] <ubitux> cehoyos: sure, will do
[23:06] <cehoyos> Merci
[23:51] <ubitux> hey btw
[23:51] <ubitux> just came accross this: http://cr.i3wm.org/
[23:51] <ubitux> it looks awesome for contributions
[00:00] --- Sun Apr 21 2013