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

[burek]

[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