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

[burek]

[00:06] <burek> we need some beer factory to be hour donator/sponsor or something :)
[00:06] <Daemon404> bikeshed beer
[00:09] <burek> hour... omg...
[00:09] <burek> our*
[00:10] <burek> i think its time to sleep :D
[00:21] <orbisvicis> is there an example of using av_audio_convert? particularly, how to create the output buffer
[00:21] <orbisvicis> (without AVCODEC_MAX_AUDIO_FRAME_SIZE)
[00:22] <burek> did you check ffmpeg's source code
[00:29] <orbisvicis> burek: what in particular?
[00:29] <burek> grep av_audio_convert |?
[00:30] <orbisvicis> i mean there is the api documentation (not helpful for me in this case), but nothing in the examples
[00:31] <burek> the best api docs is the source code itself
[00:31] <burek> see how does ffmpeg use it
[00:31] <burek> and copy/paste the logic
[00:31] <orbisvicis> ok, ill take a look
[00:36] <saste> orbisvicis: av_audio_convert is deprecated, you're supposed to use the new libswresample
[00:37] <saste> orbisvicis: and yes some resampling/converting examples in doc/examples may help
[01:26] <maker> saste: !
[01:26] <saste> maker: hi!
[01:27] <saste> maker: just see your application
[01:27] <maker> Considering that submissions for the summer of code in spece are going to end today, am I still in time for developing the application requirements?
[01:27] <saste> note: the task will *not* require to finish all the listed items
[01:27] <saste> that's only a list of ideas
[01:28] <saste> maker: there is time for evaluation until july 31
[01:28] <saste> so until the next tuesday
[01:29] <saste> so yes i suppose there is still time for the qualification task
[01:29] <maker> I am confident that once understood libavfilter's descriptors logic most of the time will be spent on algorithmics. 
[01:29] <saste> qualification task doesn't need to be *completed*, it's just to give evaluation elements
[01:29] <saste> of course the better you do, the more chances you have to be selected
[01:30] <saste> maker: yes, keep in mind that libavfilter is quite complex, so it's quite difficult to get familiar with its API
[01:30] <saste> luckily we have lots of examples
[01:31] <maker> Is socis popular? I don't think is a private data, so I was wondering, as ffmpeg organization, did you receive many applications? 
[01:31] <saste> maker: you will know tomorrow ;-)
[01:32] <maker> Which is today ;D
[01:32] <saste> we have received three applications so far
[01:33] <saste> maker: do you have an idea for a qualification task?
[01:34] <maker> Nope, I was just googling for ideas/inspiration
[01:35] <saste> maker: did you have some experience with VLC? maybe you could port some filter from there
[01:41] <maker> saste: my experience with vlc steps just through the player's api, not filters. 
[01:58] <saste> great, James Ashton just replied to me
[01:58] <saste> regarding a library he wrote more than twenty years ago o_O
[02:56] <highgod> Hi,all.I want to ask a question.I read ffmpeg code,but I didn't find any CODA code to optimize ffmpeg.I want to ask why CUDA is unsuccessful in ffmpeg?Thanks
[02:56] <highgod> Sorry,CUDA
[03:02] <Skyler> What precisely are you looking to "optimize"?  ffmpeg is a large application.
[03:05] <highgod> video filter,such as scale
[03:07] <Skyler> There's been some effort towards this in the Handbrake project, which AMD/Multicoreware contributed some GPU-accelerated code to
[03:14] <highgod> Yes,they use opencl.
[03:18] <highgod> So I want to ask why ffmpeg don't use it to optimize?
[03:18] <Skyler> Because nobody has submitted a patch to do it
[03:30] <highgod> Hehe.Thanks.our team want to add opencl code to optimize ffmpeg.will you accept it?
[03:32] <Skyler> Michael Niedermayer would be the one to "accept" something, but nobody can "accept" something before you even write the code.  A patch gets accepted if it passes code reviews and developers believe it should be included.
[03:32] <Skyler> If you want to discuss the idea of adding it, start an RFC on the mailing list.
[03:34] <Skyler> Going and developing a large patch independently and dumping it on the mailing list without discussion almost invariably leads to abandoned code.
[03:41] <highgod> OK,Thanks.We have write some code.Witch developers should we send the code to?
[03:49] <Skyler> You need to participate on the ffmpeg-devel mailing list.
[03:50] <oneal> there is one pipeline path(software pipeline) in currently ffmpeg(decoder(demuxer --> single or multi thread)-->filters processing-->encoder(single or multi threads) -->muxer), in our optimizing plan, there is another pipeline path(acclerate pipeline). it's easy for use to switch between software pipeline and accelerating pipelin. this can make  more flexibility.
[03:54] <oneal> Are there any other suggestions or ideas about this.
[03:55] <oneal> there are some algorithm which are suitable for running on CPU, but there are a lot of algorithm which can be suitable for running on GPU.
[04:00] <oneal> according our profiling about the currente video transcode procedure, there are some block in the transcode pipeline. so I think if the computation of some stages in transcode pipeline are moved to other computing device. this can speed up the whole pipeline.
[06:46] <philipl> ubitux: I've updated the mov_text branch and posted a new diff.
[06:47] <philipl> ubitux: Also, I looked at mplayer, and I know why you saw weird timing. it's handling of packet duration is messed up.
[06:47] <philipl> It doesn't read duration properly, and then it doesn't set the AVPacket dts or duration properly (no timebase conversion, etc).
[06:47] <philipl> The end result is that it falls back to its 3 second default duration.
[06:48] <philipl> Most people don't go down this path as they're decoding srt or ass where the inline timing information is used by ffmpeg and the broken AVPacket values ignored.
[06:53] <philipl> ubitux: Ok, got it. So there are two problems. 1) It only looks at convergence_duration for subtitle duration. *sigh* 2) If I try and switch it from using its own minimal mov_text decoder to my one, the mplayer code doesn't get the timebase conversion right, so all times and durations end up rounding to zero.
[12:02] <durandal_1707> michaelni: wavpack (demuxer) spits bogus error after addition of picture support in ape tags
[13:15] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * ra2cd13f04f 10ffmpeg/libavcodec/zmbv.c: 
[13:15] <CIA-41> ffmpeg: zmbv: Fix warning about discarded qualifier
[13:15] <CIA-41> ffmpeg: Based on patch by: jamal <jamrial at gmail.com>
[13:15] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:15] <CIA-41> ffmpeg: 03jamal 07master * rc49e0d2cdd 10ffmpeg/libavformat/aviobuf.c: 
[13:15] <CIA-41> ffmpeg: aviobuf: Fix warning about discarded qualifier
[13:15] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:15] <CIA-41> ffmpeg: 03jamal 07master * rcb40d36074 10ffmpeg/libavcodec/ffv1.c: 
[13:15] <CIA-41> ffmpeg: ffv1: Fix warnings about incompatible pointer type and discarded qualifiers
[13:15] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:47] <CIA-41> ffmpeg: 03Marton Balint 07master * r3be02afb56 10ffmpeg/libavformat/mxfdec.c: 
[13:47] <CIA-41> ffmpeg: mxfdec: fix off by one error in d10 aes3 decoding
[13:47] <CIA-41> ffmpeg: Without this fix the last sample was missing from the packet.
[13:47] <CIA-41> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[13:47] <CIA-41> ffmpeg: Reviewed-by: Matthieu Bouron <matthieu.bouron at gmail.com>
[13:47] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:47] <CIA-41> ffmpeg: 03Matthieu Bouron 07master * r789f8cb03a 10ffmpeg/ (4 files in 2 dirs): 
[13:47] <CIA-41> ffmpeg: avutil: support 50 and 60 frame rates in timecode api
[13:47] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:00] <CIA-41> ffmpeg: 03Steven Robertson 07master * rb3841db133 10ffmpeg/libavfilter/vf_alphamerge.c: 
[14:00] <CIA-41> ffmpeg: vf_alphamerge: Fix reversed conditional
[14:00] <CIA-41> ffmpeg: Reviewed-by: Nicolas George
[14:34] <ubitux> wow.
[14:34] <ubitux> another huuuuuge patch from mips
[14:59] <nevcairiel> i wonder if the ac3 fixed point decoder couldnt be made generally useful, wonder what makes it depend on mips
[15:00] <nevcairiel> its also probably plenty of code duplication
[16:04] <iive> nevcairiel: afaik ac3 decoders are compiled from common template. Probably mips doesn't have fpu so float point emulation makes it horribly slow.
[16:05] <nevcairiel> mips isnt the only system with slow floats, so the question remains why not make it a generic option
[16:06] <iive> ^_^
[17:48] <Daemon404> hey nevcairiel, does lav have its own channel?
[17:57] <nevcairiel> no
[17:58] <nevcairiel> i'm not really interested in a place where users can bother me all day :P
[18:01] <Daemon404> nevcairiel, o
[18:01] <Daemon404> lulz
[18:01] <Daemon404> also: holy crapsticks @ jamal's patches
[18:02] <Daemon404> a savior has appeared
[18:02] <Daemon404> at least, someone willing to do it.
[19:50] <CIA-41> ffmpeg: 03jamal 07master * r52a62f9085 10ffmpeg/libavcodec/x86/dwt.c: 
[19:50] <CIA-41> ffmpeg: dwt: Fix several warnings about incompatible pointer type
[19:50] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:43] <CIA-41> ffmpeg: 03Carl Eugen Hoyos 07master * r4f2549e3d0 10ffmpeg/libavformat/Makefile: Fix aiff demuxer dependencies.
[21:51] <slackyman> Hi
[21:51] <slackyman> one simple question
[21:51] <slackyman> what does the "enable-sram" option means?
[21:52] <Compn> good question
[21:53] <slackyman> obviously, I guess that it allows ffmpeg for using sram
[21:54] <Compn> sure
[21:54] <slackyman> but what's the point? FFmpeg can be more fast? Can it use sram cpu cache?
[21:55] <slackyman> or whatever?
[21:55] <slackyman> does it increase performances?
[21:56] <Compn> sram sounds like secure ram to me
[21:56] <iive> seems to be blackfin related.
[21:57] <slackyman> thanks iive 
[21:57] <iive> it defines L1CODE macro, most probably level 1 cache. static ram.
[21:57] <slackyman> so if I want to compile ffmpeg for linux workstations and pcs or cross-compile for linux I don't need, right?
[21:58] <iive> correct, no effect on x86 architectures.
[21:58] <slackyman> thanks, it's what I needed to know
[21:59] <iive> and even in bfin it seems to be used only for swscale.
[22:00] <slackyman> so, maybe my point of view it's a little hard, why ffmpeg doesn't refuse to compile with that option enabled when compiling for x86 archs?
[22:01] <slackyman> I've just tried and it configure both for linux and windows without a word about that option
[22:02] <slackyman> maybe something like "warning: you're using --enable-sram for non compliant arch!" can be of some help
[22:03] <slackyman> but never mind
[22:03] <iive> well, at lest the help could mention what it is about.
[22:04] <slackyman> the help say that it enable on-chip sram
[22:04] <slackyman> but even pcs can have an on-chip sram (e.g. the cache sram)
[22:05] <iive> I personally find the configure horribly obfuscated and full of too clever hacks. sometimes to the point of becoming too hard to do actual correct checks.
[22:06] <slackyman> I don't except for some options
[22:06] <slackyman> something is really obscure
[22:06] <slackyman> but the most are clear
[22:07] <slackyman> someone here never tried to cross compile Opencv?
[22:07] <slackyman> for windows, I meant
[22:08] <slackyman> I succeded but then get lots of errors including it in ffmpeg
[22:08] <slackyman> no matter how I use LDFLAGS, CFLAGS and all the hell of options
[22:09] <slackyman> Opencv is great but it's a pain to cross-compile
[22:09] <slackyman> and they support only windows native compiling via cygwin and mingw
[22:09] <slackyman> My project is to build a windows and Linux huge-monolithic-static build of ffmpeg.current
[22:10] <slackyman> so that no *.so and *.dll are required
[22:10] <slackyman> but I give up in using opencv
[22:11] <slackyman> ok, I have to go
[22:11] <slackyman> bye and thanks
[22:11] <iive> you are welcome. 
[22:44] <CIA-41> ffmpeg: 03jamal 07master * r94c3e11a6f 10ffmpeg/libavutil/imgutils.c: 
[22:44] <CIA-41> ffmpeg: imgutils: Fix warnings about incompatible pointer type and discarded qualifiers
[22:44] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:00] --- Sat Jul 28 2012