[00:00] <cone-453> ffmpeg.git 03Michael Niedermayer 07master:067a9cf81a78: avformat/img2dec: make image2dec capable to be used from seperate demuxers [00:00] <cone-453> ffmpeg.git 03Michael Niedermayer 07master:13bcb4de33b3: avformat: add image2 alias pix demuxer [00:00] <cone-453> ffmpeg.git 03Michael Niedermayer 07master:075d6c066bc9: avformat: add image2 brender pix demuxer [00:00] <cone-453> ffmpeg.git 03Michael Niedermayer 07master:1c13e1ef368a: avformat/img2dec: Use avformat probing interface to identify format if it has not been otherwise identified [00:49] <cone-453> ffmpeg.git 03Michael Niedermayer 07master:2cffdcbdd7f6: avformat/img2dec: try to read PROBE_BUF_MIN instead of just enough for .pix probing [00:49] <cone-453> ffmpeg.git 03Michael Niedermayer 07master:657cee1aef72: avformat/img2_alias_pix: rewrite probe function [03:11] <LoH> I've run into a problem compiling FFMpeg from source with avxsynth support. It looks like configure is looking for dlopen/LoadLibrary. [03:12] <LoH> I think what's going on is that I'm trying to compile on FreeBSD10, and that system comes with dlopen support bakedi n [03:12] <LoH> *baked in [03:15] <LoH> Is this the right channel, or should I go back to #ffmpeg? [03:17] <LoH> What I have done is comment out the check for dlopen in configure. Hopefully it works out [03:59] <cone-453> ffmpeg.git 03Michael Niedermayer 07master:067ada04d196: avcodec/xbmdec: redesign parser to handle more cases [04:02] <michaelni> LoH, if you get no reply, maybe write the author/maintainer of the avxsynth code in ffmpeg [04:02] <Compn> LoH : it probably wont, bug reports and user questions still go to #ffmpeg tho [04:04] <LoH> Compn, it appears to work, but I don't have anything else to check the output with -.-; [04:06] <LoH> I'll head back to #ffmpeg though [04:07] <Compn> i dont mind, but some of these other guys :P [04:07] <Compn> ehe [04:13] <LoH> There's a guy who managed a freebsd port of ffmpeg, but their version is slightly older than what's wanted by ffms2 [04:17] <Compn> why using avxsynth with ffms2 ? [04:17] <Compn> er, i'm thinking of a diff project, nevermind [04:40] <cone-453> ffmpeg.git 03Michael Niedermayer 07master:46f72ea507af: avcodec/vp7: check buffer size [15:03] <cone-447> ffmpeg.git 03Luca Barbato 07master:85698be461c0: cmdutils: Mark exit_program as av_noreturn [15:03] <cone-447> ffmpeg.git 03Michael Niedermayer 07master:d840266633c6: Merge commit '85698be461c07be10d873dd34348bcfe9ffc56e0' [15:22] <jnvsor> How do you pipe the ffmpeg output to sed? The framerate updates don't newline so you get no flush [15:43] <cone-447> ffmpeg.git 03John Stebbins 07master:6adf3bc42e36: movenc: Add dvd subtitle support [15:43] <cone-447> ffmpeg.git 03Michael Niedermayer 07master:b8f5b0713e81: Merge remote-tracking branch 'qatar/master' [15:43] <cone-447> ffmpeg.git 03Michael Niedermayer 07master:8a9d0a156147: avformat/movenc: fix if vs if else [16:10] <J_Darnley> jnvsor: ffmpeg printes messages to stderr [16:10] <J_Darnley> *prints [16:14] <jnvsor> J_Darnley: Yeah, but it doesn't flush the fps messages so if I redirect stderr to stdout and pipe the lot to sed it doesn't flush [16:27] <J_Darnley> Other tools usually only flush with \n [16:28] <J_Darnley> ffpeg only prints \r for progress reports [16:42] <jnvsor> J_Darnley: So any way to get sed to flush on \r? [16:44] <J_Darnley> no idea [16:44] <J_Darnley> change it to \n? [16:45] <jnvsor> J_Darnley: Huh, didn't think that might work [16:48] <jnvsor> J_Darnley: Nah, with `sed -e "s%\r%\n"` it doesn't flush, guessing the flushing is done before the replace [17:13] <cone-447> ffmpeg.git 03Lukasz Marek 07master:fd786bad6321: tools/uncoded_frame: fix audio codec generation [17:13] <cone-447> ffmpeg.git 03Lukasz Marek 07master:27256e69ab2d: lavd/pulse_audio_enc: implement write_uncoded_frame callback [17:13] <cone-447> ffmpeg.git 03Lukasz Marek 07master:cd50a44beb01: lavu/mem: add av_dynarray_add_nofree function [17:13] <cone-447> ffmpeg.git 03Lukasz Marek 07master:85ed32d2ed15: lavd/pulse_audio_common: add device detecting code [17:13] <cone-447> ffmpeg.git 03Lukasz Marek 07master:255cf03af81e: lavd/pulse_audio_dec: implement get_device_list callback [17:13] <cone-447> ffmpeg.git 03Lukasz Marek 07master:3937b40e87c9: lavd/pulse_audio_enc: implement get_device_list callback [17:13] <cone-447> ffmpeg.git 03Michael Niedermayer 07master:bcd5fd5346be: Merge commit 'lukaszmluki/master^' [17:25] <ubitux> BBB: [17:25] <ubitux> * dimension 4: x subpel interpolation (0: none, 1: 8tap/bilin) [17:25] <ubitux> * dimension 5: y subpel interpolation (1: none, 1: 8tap/bilin) [17:25] <ubitux> second line, "0: none", right? [17:26] <nevcairiel> its probably safe to assume as much [17:26] <ubitux> just wanna confirm before pushing :) [18:06] <BBB> ubitux: yes [18:06] <BBB> ubitux: did i write that> [18:06] <ubitux> seems so [18:06] <BBB> :( [18:06] <BBB> ohwell [18:06] <ubitux> lavc/vp9dsp.h [18:07] <ubitux> BBB: can you have a quick look to the patch for vp9 namespace in mc? [18:07] <BBB> okie [18:08] <BBB> yeah looks good [18:08] <ubitux> ok thanks [18:13] <BBB> no other patches right? [18:13] <BBB> I'm looking to see if there's a mc hevc update,e but don't see anything yet [18:14] <ubitux> no other patch yeah, i didn't have time to work on it until today [18:14] <ubitux> i'm slowly starting to work on neon again [18:17] <BBB> cool [18:21] <cone-447> ffmpeg.git 03Clément BSsch 07master:c4148a6668b7: x86/vp9mc: add vp9 namespace. [18:21] <cone-447> ffmpeg.git 03Clément BSsch 07master:af3b6aed0da5: avcodec/vp9dsp: fix typo in mc doxy. [19:34] <ubitux> anything better than this: [19:34] <ubitux> sub r3, #16 [19:34] <ubitux> vld1.8 {q0}, [r2]! [19:34] <ubitux> vld1.8 {q1}, [r2], r3 [19:34] <ubitux> ? [19:34] <ubitux> i'd like to get rid of the sub (stride -= 16) [19:35] <ubitux> something like "vld1.8 {q0}, [r2], #16" + "vld1.8 {q1}, [r2,#16], r3" [19:44] <ubitux> BBB: btw, is it ok for put4/avg4 to read 8 instead of 4? [19:45] <ubitux> i'm still not sure how to deal with those in neon [19:45] <ubitux> assuming it makes any sense [19:46] <ubitux> i mean, there is no simd to write for those [20:01] <BBB> ubitux: I believe it's fine, the buffer is padded, but you can't write 8 [20:02] <BBB> ubitux: isn't there an instruction to read sets of 4 bytes and interleave? [20:02] <BBB> you could read 4 sets of 4 bytes separated by "stride" bytes and interleave, to do 4x4 pixels in a single go [20:02] <ubitux> yeah probably, dunno [20:03] <BBB> neither do I :-p [20:03] <ubitux> put8/16/32/64 done btw, i'm working on avg [20:03] <BBB> cool [20:03] <BBB> you'll have to help me decrypt your asm btw, my neon isn't as good as yours [20:03] <BBB> like, I still don't know 100% sure what ! means [20:04] <BBB> it's something like pre or post-increment or something [20:04] <ubitux> something like that [20:04] <ubitux> :D [20:04] <ubitux> afaict it's postinc [20:06] <BBB> post-inc of what? [20:06] <BBB> and by what? [20:06] <BBB> shouldn't post-inc be vld1.8 {q0},[r2]!, r3? [20:06] <BBB> or so [20:06] <BBB> (dunno) [20:07] <ubitux> ! will post inc of #16 [20:07] <ubitux> but you can't do vld1.8 {q0},[r2],#16, so you do vld1.8 {q0},[r2]! [20:07] <ubitux> i guess your line would do #16+r3? [20:07] <ubitux> but... no idea :D [20:08] <ubitux> the doc really sucks honestly [20:11] <BBB> neon is kinda weird [20:11] <BBB> well anyway it doesn't have to be 100% perfect every first try, plus feel free to copy mpeg/h264 optimizations from neon, they should be self-explanatory [20:11] <BBB> or vp8 [20:12] <ubitux> yup [20:23] <ubitux> https://github.com/ubitux/FFmpeg/commits/vp9-arm not much atm [20:23] <ubitux> put8/16/32/64 and avg8 [20:24] <ubitux> i'd really like to avoid these sub in put32/put64 [20:52] <BBB> why does put16 use vld1.8? [20:54] <ubitux> the value aren't 8-bit coded? [20:54] <BBB> oh it's bits? [20:54] <BBB> I didn't know, I thought it was bytes (load 8 bytes) [20:54] <BBB> lol [20:54] <BBB> functions look good then [20:54] <BBB> I'd commit it already [20:55] <BBB> does it help speed-wise? [20:55] <ubitux> maybe it means something else... :x [20:55] <ubitux> BBB: not much so far [20:56] <ubitux> BBB: i wouldn't push them immediately [20:56] <BBB> and so ! is pre-increment [20:56] <ubitux> there are a few things i want to check first [20:56] <BBB> whereas , X is post-increment [20:56] <ubitux> pre? no don't think so [20:56] <BBB> anyway I'd be interested in the real mc [20:56] <ubitux> i'd say post [20:56] <ubitux> , X is also post increment [20:56] <ubitux> but with a reg [20:56] <BBB> we should still merge 2d 8taps in x86 simd [20:57] <BBB> oh [20:57] <BBB> I guess you're right [20:57] <BBB> mis-read stuff [20:57] <ubitux> also, there are some stuff with alignment [20:57] <ubitux> i can probably add align hints in some places [20:57] <BBB> yeah we never did that in x86 either [20:57] <BBB> plus prefetch still big todo [20:57] <BBB> all these can help quite a lot [20:58] <BBB> anyway, we're already fast so who cares :-p [21:12] <ubitux> these functions doesn't make much difference on overall time for now [21:13] <ubitux> don't* [21:13] <BBB> it's possible that when compiled with neon support, gcc outputs that same assembly already through memcpy [21:13] <ubitux> it's like 0m15.864s ’ 0m15.756s [21:13] <ubitux> yeah probably [21:14] <BBB> 0.1sec is still a good start though, always worth it [21:14] <BBB> how much fps do you get on HD material (1080p)? [21:14] <ubitux> about 3 [21:14] <BBB> ... [21:14] <ubitux> :) [21:15] <ubitux> these ~16s were 50 frames of etv5k [21:15] <BBB> omg [21:15] <ubitux> :D [21:15] <BBB> I thought it was like 1000 frames or so [21:15] <BBB> ok, carry on, ignore me :-p [21:16] <ubitux> yeah i don't do 60 fps on arm :)) [21:16] <ubitux> BBB: src and dst are always aligned? [21:18] <ubitux> mmh seems not [21:19] <ubitux> source isn't but dst is. ok [21:34] <BBB> right [22:38] <Ove_88> Hello everyone. I'm trying to seek to an exact frame number using AVSEEK_FLAG_FRAME in av_seek_frame and avformat_seek_file, but they always return -1. Do you know what I'm doing wrong? [22:39] <Ove_88> I've also looked at the source code for the demuxers in ffmpeg, and as far as I can tell, none of them work with AVSEEK_FLAG_FRAME, although I might be wrong. [22:40] <Mavrik> hmm [22:40] <Mavrik> checking out how ffmpeg.c does it would probably help you [22:44] <Ove_88> ffmpeg.c does not use AVSEEK_FLAG_FRAME [22:45] <nevcairiel> I doubt it works, and even if it would accept such parameters, its doubtful it would be frame accurate [22:45] <Ove_88> also, ffmpeg.c can't seek using frame numbers, it can only seek using hh:mm:ss.ms [22:46] <ubitux> mmh how is there any special tricks i should be aware of for running a fate instance with cross compiled tools? [22:46] <ubitux> -how [22:48] <Ove_88> ok, I thought it worked since I saw it in the docs [22:48] <Ove_88> I'll have to seek by timestamp instead [23:15] <ubitux> BBB: going to merge the x86 2d 8taps? [23:24] <J_Darnley> ubitux: I guess that will depend on your host and target [23:25] <J_Darnley> I tried using cygwin's cross compilers for native windows but the test script was doing strange things to file paths [23:50] <ubitux> :/ [23:50] <ubitux> i guess i'll just build ffmpeg on the board and copy the cross compiled one after each iteration [23:59] <J_Darnley> Well if you're staying with linux paths my particular issue won't bother you [23:59] <BBB> ubitux: sure I can try [00:00] --- Sun Mar 30 2014