[FFmpeg-devel-irc] IRC log for 2010-03-26

[irc at mansr.com]

[00:38:21] <CIA-24> ffmpeg: diego * r22686 /trunk/doc/general.texi: Add FreeBSD subsection with compilation instructions.
[00:39:45] <CIA-24> ffmpeg: diego * r22687 /trunk/doc/general.texi: Reorder platform sections alphabetically.
[00:58:20] <mfg> Does anyone want to checkin my patch (proe_buffer11.diff from tuesday)?
[01:03:42] <mru> http://thenewsh.blogspot.com/2010/03/three-cats.html
[01:05:25] <hyc> sad, very sad...
[01:05:32] <mfg> LOL
[01:06:21] <hyc> I seem to recall an email thread on the linux-standard-base mailing list about how /bin/true didn't conform to the LSB
[01:06:29] <hyc> because it lacked a --version option or something
[01:07:41] <mru> if it did, it wouldn't conform to the real standards
[01:08:25] <mru> I usually use : though
[01:08:28] <mru> less typing
[01:08:40] <hyc> yep
[01:09:26] <hyc> http://lists.mplayerhq.hu/pipermail/rtmpdump/2010-March/000697.html
[01:10:48] <mru> hmm, let's write something where -help, -version, -verbose etc trigger some catastrophic action like deleting everything
[01:11:24] <mru> make -e -r -o combine to do that of course
[01:13:04] <CIA-24> ffmpeg: stefano * r22688 /trunk/libavformat/utils.c:
[01:13:04] <CIA-24> ffmpeg: Fix updating condition for the probe_size variable in the internal
[01:13:04] <CIA-24> ffmpeg: loop of ff_probe_input_buffer(), making sure that probe_size is always
[01:13:04] <CIA-24> ffmpeg: set to probe_max_size in the last iteration.
[01:13:04] <CIA-24> ffmpeg: Also make the function return an error if we get to the max probe
[01:13:05] <CIA-24> ffmpeg: length and still cannot figure out what the format is.
[01:13:06] <CIA-24> ffmpeg: Patch by Micah Galizia micahgalizia A gmail D com.
[01:13:44] <hyc> life used to be so simple, you type an invalid option, the program prints its usage
[01:13:48] <mfg> sweet!!!
[01:13:52] <hyc> then you get it right and move on
[01:14:14] <mfg> TY!
[01:14:20] <hyc> I would just use "-," for any program I needed help with
[01:14:33] <mfg> who is Stefano (I mean, IRC handle)
[01:14:39] <mru> saste
[01:14:40] <hyc> now GNU tools unhelpfully say "use --help" ... bleah
[01:14:50] <mfg> saste: ty!
[01:15:00] <mru> gnu is getting more bloated by the hour
[01:15:06] <DonDiego> mru: i committed a docs update for freebsd
[01:15:12] <mru> DonDiego: I noticed
[01:15:59] <mru> I'm still curious as to whether anyone has contacted any bsd devs
[01:16:15] <DonDiego> it would be interesting to know
[01:16:19] <hyc> mru: regarding librtmp into libavformat - we had length discussion of that here in irc last week
[01:16:26] <DonDiego> we can talk to them at the next conference
[01:16:28] <mru> I don't personally know the spell to summon them
[01:16:31] <hyc> I don't have the energy to summarize it back to email at the moment
[01:16:45] <mru> must have missed it
[01:17:05] <DonDiego> they are at all the fosdem, linuxtag, froscon and whatnot events..
[01:17:14] <mru> no
[01:17:17] <mru> they have people there
[01:17:21] <mru> clueless people
[01:17:28] <DonDiego> not all of them
[01:17:36] <mru> people who will only tell you they're not responsible for _that_ particular mess
[01:17:48] <DonDiego> ever tried talking to them?
[01:17:52] <mru> yes
[01:17:57] <mru> always got that reply
[01:19:58] <saste> mfg: np
[01:22:31] <Compn> mru : should print up some tshirts for them
[01:22:35] <Compn> 'not my department'
[01:23:10] <mru> soon it'll be "not my bsd"
[01:23:23] <mru> they could rename all of them MyBSD
[01:27:16] <hyc> well, one nice thing about gnu, it makes it harder to accidentally type "rm --recursive --force /"
[01:27:52] <mru> it still supports -rf
[01:27:56] <mru> thank goodness
[01:27:59] <hyc> yeah, was just joking
[01:28:17] <mru> it is kinda nice that you can put flags after filename arguments
[01:28:29] <mru> I always type rm /some/path -rf
[01:28:44] <mru> just to make sure I don't accidentally hit enter after rm -rf /
[01:35:01] <Compn> shouldnt there be a block anyways?
[01:35:08] <Compn> really how many times do people NEED rm -rf / ?
[01:35:22] <Compn> rm -rf / --yes-i-mean-it
[01:35:23] <Compn> ...
[01:35:30] <hyc> lol
[01:35:40] <mru> that's windows-think
[01:35:41] <hyc> "-f" *is* "yes i mean it"
[01:35:49] <mru> protecting the users from themselves
[01:35:55] <mru> redhat does it to
[01:35:58] <Compn> -f is yes i want to remove a directory
[01:36:02] <mru> aliasing rm to rm -i by default
[01:36:07] <Compn> but sure, its used twice, which is stupid
[01:36:36] <mru> -f has nothing to do with directories
[01:36:54] <Compn> oop
[01:37:23] <mru> -f does two things
[01:37:56] <mru> if not specified, rm will ask before deleting non-writable files
[01:38:26] <mru> it also suppresses error messages and exit status when files don't exist
[01:41:24] <ohsix> hurr cat -e is handy
[01:42:09] <mru> I agree with whoever said unix bloat started the day cat started taking options
[01:48:06] <DonDiego> gnite
[01:55:18] <hyc> has anyobody played with gource?
[01:55:31] <hyc> it can output a stream of pnm's to be assembled into a movie
[01:55:46] <hyc> sometimes it appears to output an incomplete/partial pnm frame
[01:56:26] <hyc> and that can sometimes cause a crash
[01:56:52] <hyc> I had this patch sitting in my tree for a few months, just remembered it
[01:57:28] <hyc> http://hyc.pastebin.com/DUpLuZe0
[02:00:19] <Kovensky> how does one use avcodec_decode_audio3?
[03:05:35] <pengvado> is there an ffmpeg option to not mess with the terminal state?
[03:06:30] <pengvado> I'm trying to run `valgrind --db-attach=yes ffmpeg`, and I can't do anything in gdb once it's attached because the terminal is in raw mode or something
[03:07:14] <Dark_Shikari> ./ffmpeg 2>&1 | cat -  ? ;)
[03:07:36] <pengvado> that kills valgrind's and gdb's output too
[03:08:40] <Dark_Shikari> why do you need db-attach?
[03:08:48] <Dark_Shikari> (you could also just comment out any of the relevant stuff in ffmpeg.c)
[03:08:53] <pengvado> oh wait, redirecting input through cat works
[03:09:38] <pengvado> db-attach to let me debug an invalid but non-crashing memory access
[03:11:50] <astrange> i just comment out the curses stuff in ffmpeg.c when i need to
[03:16:16] <mru> I'd like to remove that terminal interference entirely
[03:16:35] <mru> ctrl-c is as easy to type as q
[03:30:21] <CIA-24> ffmpeg: astrange * r22689 /trunk/libavcodec/h264_cabac.c:
[03:30:21] <CIA-24> ffmpeg: h264: Simplify decode_cabac_residual() specialization
[03:30:21] <CIA-24> ffmpeg: Gives more consistent inlining with some compilers (such as llvm).
[03:32:47] <CIA-24> ffmpeg: astrange * r22690 /trunk/libavcodec/h264_cabac.c: h264: Remove unused function argument
[04:13:18] <CIA-24> ffmpeg: ramiro * r22691 /trunk/libavcodec/libxvidff.c:
[04:13:18] <CIA-24> ffmpeg: libxvid: Clear extradata pointer when freeing it.
[04:13:18] <CIA-24> ffmpeg: Fixes crash when avcodec_close() tried freeing it again.
[04:13:18] <CIA-24> ffmpeg: Fixes issue 1846.
[04:24:37] <ramiro> NSFW bug reports... Sturgeon was wrong: 90% of everything is porn.
[04:25:00] <mru> and 90% of porn is crap
[04:25:24] <ohsix> and 8% of that is crap porn
[04:26:14] <mru> speaking of nsfw bugs, at nds we sometimes had bugs related to pay-per-view stuff...
[04:26:51] <mru> most of them could be reproduced on the test systems
[04:26:57] <mru> but sometimes the real signal was required
[04:28:40] <astrange> the rsync for the fate samples takes a while...
[04:29:04] <mru> only the first time
[04:29:33] <drv> i think it's mainly the slow connection, not very big
[04:29:34] <mru> it's only 300MB
[04:29:40] <mru> that's smaller than openoffice
[04:29:46] <drv> haha
[04:29:52] <ramiro> smaller than xcode
[05:04:52] <CIA-24> ffmpeg: astrange * r22692 /trunk/libavcodec/h264_cabac.c:
[05:04:52] <CIA-24> ffmpeg: h264: Use + instead of | in some places
[05:04:52] <CIA-24> ffmpeg: 6 insns less on x86-64/gcc 4.2.
[05:16:00] <elenril> are those -mt backports?
[05:36:49] <astrange> no, just local patches
[07:09:23] <superdump> has that marcelo guy been in at all?
[07:10:25] <superdump> it seems that he, as i was, is not familiar with fixed point math
[07:10:46] <superdump> so i think a floating point amr-wb decoder is a good option
[07:53:57] <hyc> fixed point is a lot faster
[07:56:13] <merbzt1> hyc: not on modern cpu's
[07:57:20] <superdump> merbzt1: that's what i was thinking, but how about arm/mips/whatever?
[07:57:32] <superdump> or snapdragon, whatever arch that is
[07:57:49] <superdump> i guess such devices have dsps if they need them
[07:58:00] <merbzt1> neon for the win
[07:58:08] <hyc> yes, but getting your generic code to run on the dsp is another trick
[07:58:50] <hyc> merbzt1: most integer ops are single cycle. you're claiming that most floating point ops are equally fast?
[07:59:09] <hyc> seems pretty unlikely
[08:00:02] <wbs> but fixed-point code needs more operations to achieve the same (e.g. multiplication + shifts, instead of simply doing the multiplication in floating point)
[08:00:09] <hyc> and how hard is it to teach someone the principles of fixed-point math?
[08:00:46] <merbzt1> hyc: no, but you can't compare ops 1 to 1 as the usage would be different
[08:00:49] <hyc> most DSPs are still faster as fixed point...
[08:00:51] <superdump> not hard, but it's more confusion on top of learning how to work with ffmpeg, how to decipher a spec and how to make an implementation
[08:01:18] <hyc> well, it's more intensive education, at least
[08:01:30] <merbzt1> if you take a mul for example, a float one is just a mul, but for a fixed point implementation mul you might need to shift the result
[08:01:32] <wbs> hyc: nevertheless, there's for example a suggested task with an floating point mpeg audio decoder: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010#Floating-point_MPEG_audio_decoder
[08:01:36] <superdump> plus as other CELP codecs have been implemented in floating point, we can reuse stuff
[08:01:41] <hyc> do you want to train a codemonkey, or someone who understandshow things really work...
[08:02:57] <hyc> ah well, never mind
[08:03:03] <hyc> at least ffmpeg is still written in C
[08:03:25] <merbzt1> hyc: that said, fixedpoint stuff is nicer in alot of other ways
[08:03:30] <merbzt1> hyc: :)
[08:04:11] <astrange> probably more people care about amr in fixedpoint than in floating point
[08:04:39] <superdump> i'm sure
[08:04:44] <merbzt1> those who care have opencore
[08:04:45] <astrange> actually, what do you even use amr for? is it the codec in .3gp?
[08:04:51] <hyc> yes
[08:04:54] <superdump> yes
[08:05:15] <hyc> so phones, embedded devices with limtied resources
[08:05:23] <hyc> of course, these days even phones are pretty beefy
[08:05:28] <superdump> indeed
[08:05:31] <wbs> does anybody know about how widespread amr-wb is in practice?
[08:05:34] <astrange> iirc those get uploaded to video sites a lot
[08:05:41] <astrange> and of course fp is fine there
[08:05:46] <superdump> mmm
[08:06:13] <wbs> symbian phones have managed to decode such files well (e.g. over rtp), but I really don't know about any of them producing it themselves
[08:06:17] <merbzt1> wbs: not so much
[08:07:09] <merbzt1> maybe I should add g723.1 and g729
[08:07:14] <merbzt1> for SoC
[08:12:51] <superdump> probably speech codecs are pretty easy now we have a pool of code
[08:13:56] <wbs> superdump: how much do they share in the actual design? what i've wikipediad about -nb vs -wb, i've gathered that they don't share much except for the name
[08:13:59] <CIA-24> libswscale: diego * r30961 /trunk/libswscale/yuv2rgb.c: HAVE_MMX2 implies HAVE_MMX, so checking the latter is enough.
[08:14:32] <superdump> from what i saw a while ago, they looked pretty similar in a lot of the functions
[08:14:42] <superdump> the big difference was LSP versus ISP
[08:14:55] <superdump> aside from the sample rate and whatnot
[08:15:00] <merbzt1> and they are sooo different
[08:15:15] <superdump> if you have functions supporting variable numbers of samples, you should be fine
[08:15:38] <superdump> heh
[08:47:15] <twnqx> wow, fedex won the race
[08:47:41] <twnqx> yesterday UPS was ahead, first to arrive in germany from Thief River Falls
[08:47:50] <twnqx> now fedex already delivered :X
[08:47:58] <superdump> anything shiny?
[08:48:12] <twnqx> integrated circuits!
[08:48:32] <superdump> mmmm, chips
[08:48:51] <twnqx> gah
[08:48:56] <twnqx> i'm craving chips atm
[08:49:06] <twnqx> dieting causes such annoying side effects...
[09:49:03] <KotH> anyone here who knows someone doing QNX contractor work?
[09:49:18] <kshishkov> what does that mean?
[09:49:45] <KotH> we've a customer who wants to have something what we do not provide
[09:49:46] * kshishkov knows few people employing QNX in nuclear power plant control systems
[09:49:58] <kshishkov> I don't think that will help though
[09:50:00] <KotH> err...
[09:50:07] <KotH> no thanks.. i still remember 1986
[09:50:58] * kshishkov also remembers how his company searched for VxWorks developer
[09:51:20] <KotH> anyways, we'd like to pass that customer to someone else
[09:52:11] <kshishkov> the funniest thing is that only I knew what requirements (s)he should have
[09:52:24] <twnqx> your insurance doesn't cover nuclear fallout?
[09:53:47] <superdump> i don't think insurance would help much
[09:54:24] <kshishkov> insurance = 20m thick lead sheets
[09:54:42] <merbzt1> that sounds cozy to have in bed
[09:57:47] <CIA-24> ffmpeg: diego * r22693 /trunk/doc/general.texi: Add (Open)Solaris section to platform documentation.
[10:02:27] <lu_zero> wbs: you around?
[10:02:33] <wbs> lu_zero: yeah
[10:02:54] <lu_zero> got the time to discuss a bit about dss and your usage of it?
[10:03:02] <wbs> absolutely
[10:03:12] * lu_zero today has some time spared 
[10:03:37] <lu_zero> first: how ANNOUNCE/RECORD is supported there?
[10:04:12] <lu_zero> I have javanx there that is looking at the dss docs and he just found stuff about reflectors and .sdp files
[10:04:22] <lu_zero> (that's pretty much the same as in feng)
[10:05:49] <wbs> yeah, I think the concept is called reflection
[10:06:06] <Dark_Shikari> kshishkov: ping
[10:06:14] <wbs> the client does an ANNOUNCE with any path that doesn't exist currently, (normally a .sdp filename), then setup and RECORD instead of PLAY
[10:06:43] <wbs> as long as that session is active, the URL that was used in the ANNOUNCE is available for normal DESCRIBE/PLAY
[10:06:58] <wbs> and after teardown, the URL gives 404 again
[10:07:32] <wbs> I guess the server could store the packets somewhere to replay them on demand later, too, but DSS doesn't do that afaik (or I haven't seen such a configure option at least)
[10:07:34] <lu_zero> uhm, that's something not in the documentation picked up so far
[10:08:07] <Dark_Shikari> kshishkov or anyone else who knows--can ffmpeg output to rtmp now?
[10:08:12] <Dark_Shikari> i.e. send video to an rtmp server via rtmp
[10:08:17] <Dark_Shikari> ffmpeg -i blah blah blah rtmp://blah blah/
[10:08:21] <wbs> Dark_Shikari: yes
[10:08:26] <wbs> you need to add -f flv though
[10:08:35] <Dark_Shikari> thx.
[10:13:24] <lu_zero> storing would be useful?
[10:13:43] <lu_zero> I mean you have the network in between and your channel isn't as reliable as a local storage
[10:14:10] <wbs> nah, not that useful to me, only theoretically
[10:14:20] <lu_zero> (our suggested workflow is to have ffmpeg do the recording locally and then upload later
[10:14:23] <lu_zero> )
[10:14:37] <wbs> how does feng serve static files btw, do they have to be rtp-hinted, or does it handle that itself?
[10:14:50] <lu_zero> it does handle that itself
[10:15:07] <wbs> ah, nice. dss requiring hinting feels stupid. :-)
[10:15:45] <lu_zero> basically it just use what ffmpeg tells
[10:18:24] <wbs> so in practice, it has rtp packetizers for a bunch of formats internally
[10:18:56] <lu_zero> yes
[10:21:09] <lu_zero> possibly I'll replace them with ffmpeg ones
[10:21:30] <lu_zero> (since would be pointless keeping them there if they work the same way)
[10:23:33] <wbs> probably yes, if lavf would happen to support more formats
[10:33:29] * lu_zero notices that seeking is broken in ffmpeg in the end =P
[10:33:39] <lu_zero> I eventually built and installed a local dss
[10:33:41] <lu_zero> ^^
[10:33:50] <wbs> ah. :-)
[10:34:14] <lu_zero> you can seem correctly by percent but not by offset
[10:34:46] <wbs> yes, dss sucks quite a bit. i've polished it up and gathered some fixes for running it on 64bit, and made some shellscripts for running it installed for a local user, not requiring root, not requiring to spread things around /usr/local :-)
[10:34:52] <wbs> I guess I should put it up somewhere sometime
[10:39:12] <lu_zero> wbs: since you have lots experience with it I would be delighted to get some feedbacks on how to make feng a nicer toy to play with ^^
[10:40:10] <wbs> lu_zero: I'm starting to look at feng now actually - I've been put off by the amount of dependencies (of which I noticed that most are available on debian or debian-multimedia.org anyway, so it's a moot point), I'll get back to you with comments later when I've used it a bit more :-)
[10:40:45] <lu_zero> uhmm
[10:41:22] <justlooking> KotH, the only active outlet for QNX people these is the http://www.openqnx.com/index.php?name=PNphpBB2 but on a quick look i dont see any old time QNXRTP 6 devs/contractors posting ,but werth a shot i guess as  even the main IRC channels they used are no more, shame.
[10:41:30] <lu_zero> flameeyes had a bundle-script that should fetch and build feng+deps
[10:41:45] <lu_zero> I'll ask him to publish it
[10:41:53] <lu_zero> Honoome: around?
[10:43:27] <wbs> lu_zero: so, feng doesn't support announce/streaming at the moment, right?
[10:45:17] <lu_zero> wbs: nope
[10:45:34] <wbs> what's "live streaming supported...... : yes" that configure mentioned?
[10:45:49] <lu_zero> we have an rtp mixer that uses posix queues right now
[10:46:09] <lu_zero> so if you are on systems not supporting them that part won't be built
[10:46:22] <wbs> I see - what apps do you use to push content into that then?
[10:48:04] <lu_zero> the chain is
[10:48:17] <lu_zero> any rtp producer (vlc, ffmpeg had been used a lot)
[10:48:39] <lu_zero> a flux that picks the rtp streams and tunnels them to the remote server
[10:48:45] <KotH> justlooking: thanks
[10:48:59] <lu_zero> a flux in the remote server picking them and feeding feng
[10:49:11] <lu_zero> feng delivers them to the end user
[10:49:46] <wbs> ah, ok
[10:50:37] <wbs> if you'd have rtsp announce support, I guess the flux steps inbetween could be removed and the rtp producer could talk straight to the rtsp server
[10:50:57] <lu_zero> if you like that way yes
[10:52:17] <lu_zero> flux has some features you might like
[10:53:26] <wbs> hmm, interesting
[10:54:42] <lu_zero> it is a mixer so you can do some processing there
[10:55:05] <lu_zero> like use it to splice the rtp streams between different servers
[10:55:18] <lu_zero> or do on the fly conversions
[10:57:49] <wbs> btw, if using feng, what stats interfaces are available? i.e., if I'd like to know which streams are being served at the moment, with how many active viewers at each stream?
[10:58:28] <lu_zero> wbs: I already had this request
[10:58:50] <lu_zero> I'm writing it more or less now so tell me what you'd expect to get and you'll have it =)
[10:59:24] <lu_zero> right now feng has a sort of accesslog that is like the apache one
[11:00:01] <wbs> that's probably quite ok for checking how many total views different streams have had, but it'd be good with some kind of interface where one could poll the amount of current streams
[11:00:06] <lu_zero> and a server log in which it states how many clients are connected
[11:01:13] <lu_zero> Honoome: was thinking about providing a way to issue a get to a specific path
[11:14:30] <justlooking> well lu_zero it appears that serching oin win32 feng wants to give you lots of fang virus link info so i take it ,its not a good app for small self contained  cross platform streamign then ?, and this included 'flux tunnel' isnt a multicast capable one to many tunnel?
[11:14:52] <justlooking> searching on...
[11:15:41] <lu_zero> justlooking: ?
[11:16:52] <justlooking> feng is not written to be compiled and run on win32 so its useage is limited to unix like systems only?
[11:17:13] <lu_zero> so far nobody requested win32 support
[11:18:03] <lu_zero> probably you would be able to build it in cygwin
[11:18:36] <lu_zero> the only annoying thing it uses is the posix queue facility that is a bit too recent...
[11:20:02] <justlooking> i gather that, but whats your core usage, you came from amiga/QNX type small and self contained simple apps is good mindset if i understand ? and so im suprised you didnt make/patch it be cross platform and self contained.
[11:22:22] <lu_zero> justlooking: feng build deps like ragel aren't require for usage
[11:22:43] <lu_zero> beside that feng needs just glib, netembryo and ffmpeg
[11:22:59] <lu_zero> netembryo being a thin network abstraction
[11:23:19] <lu_zero> all of them being fairly portable
[11:29:39] <lu_zero> [Fri Mar 26 12:29:27 2010] Range header: npt=-816375531.124-
[11:29:44] <lu_zero> interesting =_=
[11:35:44] <lu_zero> wonderful
[11:36:08] <lu_zero> ffmpeg tries to send an npt range as negative?
[11:36:15] <lu_zero> (invalid range)
[11:39:43] <justlooking> ffmpeg OR DSS? http://lists.apple.com/archives/streaming-server-dev/2003/May/msg00019.html "...We thoroughly tested the version 4.1.3 and found that, as we previously
[11:39:43] <justlooking> noted, DSS:
[11:39:44] <justlooking> - never returns a range header in the response
[11:39:44] <justlooking> - responds OK to an invalid range but does not stream any packets.
[11:39:44] <justlooking> The proper handling of the Range header is extremely important for
[11:39:45] <justlooking> precise media synchronisation and more generally for finding out the
[11:39:47] <justlooking> exact media time that corresponds to the timestamp of the first RTP
[11:39:49] <justlooking> packet...."
[11:40:55] <lu_zero> ...
[11:41:15] <lu_zero> sigh
[11:41:36] <lu_zero> I'm playing with dss default files to see the different behaviour
[11:41:49] * justlooking Ok, AFK sorry Lu...
[11:42:51] <lu_zero> np
[11:44:00] * justlooking just trying to learn how it fits together you understand, afk for real .
[11:54:06] <lu_zero>   Duration: 00:01:10.01, start: -816374104.-875422, bitrate: N/A
[11:54:09] <lu_zero> hum...
[12:22:35] <lu_zero> nobody used valgrind on ffmpeg lately....
[12:25:40] <wbs> lu_zero: I use it quite regularly and don't see any leaks nor memory errors, for the things I run
[12:27:26] <ramiro> lu_zero: there's a fate box running it under valgrind
[13:09:35] <BMintern> hello. i was wondering if there's anyone here who could take a few minutes to get me up to speed on libavfilter. i'm interested in developing a filter to fade in/fade out, but i have never worked on ffmpeg at all before
[13:15:09] <BMintern> ahh... i see http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_howto
[13:15:17] <BMintern> hopefully that will be enough to get me started
[13:30:42] <merbzt1> BMintern: you can ask vitor if you get stuck
[13:34:55] <BMintern> thanks merbzt1
[13:38:15] <Vitor1001> lu_zero: nobody used valgrind on ffmpeg lately....
[13:38:29] <Vitor1001> lately == less than 6 hours? http://fate.multimedia.cx/index.php?build_record=206164
[14:05:39] <BMintern> Vitor1001: would it be sensible to have a filter that produces frames? i'm thinking along the lines of something that would replace the usage of -vframes in conjunction with -ss
[14:06:36] <Vitor1001> Looks reasonable at a first glance.
[14:07:09] <Vitor1001> You mean, a simple pass-throught filter that would send an end-of-stream when some condition is met?
[14:08:06] <BMintern> not exactly. right now i'm using ffmpeg -vframes 1 -ss $duration -i $video $image_name in order to grab the last frame of a video
[14:08:55] <BMintern> what i would like to be able to do is to do this inside the filter chain on the output of a filter
[14:09:08] <Vitor1001> Ok, so it would drop all the frames but the last?
[14:09:23] <BMintern> pretty much. i think it would probably be more useful if it was more flexible
[14:09:27] <Vitor1001> Sounds reasonable too, if it has a flexible syntax
[14:09:50] <Vitor1001> Note that having a very powerful syntax is not completely possible
[14:10:12] <Vitor1001> For ex., there is no easy way to know how many frames a file contains
[14:10:36] <Vitor1001> But accepting things like "one frame every 100" should be doable
[14:11:12] <BMintern> ok, one more thing... i was wondering if it would be sensible to have a filter that only accepts a single frame (an image) as input
[14:11:38] <Vitor1001> what is the point?
[14:11:39] <BMintern> specifically i would like to take an image and fade it to/from black over a specified duration
[14:11:52] <Vitor1001> hmmm
[14:12:01] <BMintern> in order to produce an output stream
[14:12:24] <Vitor1001> it would be better to implement it chaining a frame duplicating filter + a fade-to-black one.
[14:12:55] <BMintern> i like that idea
[14:13:20] <BMintern> so my frame filter could replicate a requested frame a given number of times
[14:13:37] <BMintern> and then a fade to black frame could take that and fade it
[14:13:39] <Vitor1001> the frame duplicating one should be very similar to the timestamp modification filter
[14:14:21] <Vitor1001> yes
[14:15:35] <BMintern> one last question... for a fade filter like that, you'd have to manually specify the total number of frames in the stream because there is no knowledge of the number of frames until you read the entire input?
[14:16:40] <BMintern> or at least, specify begin-fade, end-fade parametrs
[14:16:49] <BMintern> where the parameters are frame numbers
[14:17:27] <Vitor1001> looks a good idea
[14:17:46] <Vitor1001> anyway, most uses of a fade filter will not be for a whole video anyway.
[14:18:00] <BMintern> right, that's what i was thinking
[14:18:14] <Vitor1001> The most common one would be fading the last n frames, but this is not possible :p
[14:18:28] <BMintern> i was thinking something like fade=in:0:30 would fade in the first 30 frames
[14:18:50] <BMintern> and fade=out:1000 would fade out from the 1000th frame to the end of the video
[14:19:00] <BMintern> oh, whoops that wouldn't work
[14:19:31] <Vitor1001> exactly :p
[14:19:33] <BMintern> i guess you'd have to know the video is 1030 frames and fade=out:1000:1030
[14:19:38] <Vitor1001> And the most useful case
[14:19:45] <Vitor1001> fate=out:-10
[14:19:51] <BMintern> right
[14:19:51] <Vitor1001> to fade the last 10 frames
[14:20:05] <Vitor1001> is not very doable with current way it works
[14:20:23] <BMintern> it seems trivial to write a frame-counting filter
[14:20:30] <Vitor1001> and them?
[14:20:37] <Vitor1001> to cache in ram the whole movie?
[14:20:44] <Vitor1001> to write raw data to a random file?
[14:20:52] <Vitor1001> or doing two pass...
[14:20:58] <BMintern> sorry, i was just thinking out loud
[14:21:29] <Vitor1001> Its sad, but some things does not play well with a filtering lib concept
[14:21:43] <Vitor1001> like a play-backward filter.
[14:21:44] <BMintern> well, i was thinking of hacking around some of the limitations
[14:22:12] <Vitor1001> But yes, a bash script that first count frames and them do the fading should work
[14:22:30] <BMintern> so a certain filter could produce a stream that is not actually a stream but just a dummy stream where a certain struct field is used to give some information
[14:22:32] <Vitor1001> but is inefficient in the sense it will decode the video twice
[14:22:36] <BMintern> such as number of frames
[14:22:46] <Vitor1001> no need a filter for that
[14:23:12] <Vitor1001> ffmpeg -i file.avi -f framecrc - | grep -c "$1"
[14:23:18] <BMintern> except that sometimes you might want to count the number of frames in a filter stream without having to first write out the file
[14:24:03] <BMintern> but i guess i'm probably getting into less-useful territory now
[14:24:12] <Vitor1001> you can avoid writing the file, but not decoding it twice, unless you store the decoded data somewhere
[14:24:22] <BMintern> ahh
[14:24:26] <BMintern> i didn't realize that
[14:24:26] <Vitor1001> outlandish brainstorming is fun ;)
[14:25:01] <BMintern> so the streams that are handled by vfilters are being decoded and re-encoded along the way?
[14:25:48] <Vitor1001> Yes, it is just not possible to cache a whole decoded movie
[14:25:58] <Vitor1001> and inefficient to store it in the disk
[14:26:11] <BMintern> right, that makes sense. it just seems that if you had too many filters you would start to see degradation
[14:26:33] <Vitor1001> A single filter would be enough
[14:26:49] <Vitor1001> imagine resizing a DVD while storing all the frames in RAM
[14:27:01] <Vitor1001> better have hundreds of GB of it.
[14:27:06] <BMintern> yeah, i gotcha
[14:27:21] <BMintern> well, thanks for the help. i'm going to see about implementing a "frame" and a "fade" filter
[14:27:28] <Vitor1001> ok, good luck
[14:27:45] <Vitor1001> don't forget to give a look at our developer doc before posting your patch
[14:28:04] <BMintern> i took a look at http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_howto if that's what you mean
[14:28:09] <ramiro> what fate id is the valgrind box?
[14:28:16] <Vitor1001> ramiro:183
[14:28:16] <BMintern> and also the stuff in ffmpeg about proper code formatting
[14:28:29] <BMintern> anything else i need to look at
[14:28:36] <Vitor1001> yes, the formatting before sending your patch
[14:28:48] <Vitor1001> just because is silly to lose time with such thing ;)
[14:29:03] <BMintern> i've never worked with an open source project like this before, so i don't know much about patching
[14:29:37] <BMintern> is there a good guide for me to follow?
[14:29:38] <Vitor1001> Use "svn diff" and you can't go wrong.
[14:29:40] <BMintern> ok
[14:29:48] <BMintern> thanks a lot
[14:29:51] <Vitor1001> and read its output before expecting people to do it.
[14:30:04] <BMintern> will do
[14:30:13] <Kovensky> anyone has any samples on how to use avcodec_decode_audio3 + libavformat?
[14:30:15] <Vitor1001> for example, if you reindent a big block of code it is almost impossible to tell apart what changed and what was just reindented
[14:30:22] <ramiro> Kovensky: ffmpeg.c?
[14:30:31] <Kovensky> ramiro: scary code there :S
[14:30:42] <BMintern> well i wouldn't be expecting to change many existing source files (hopefully!) :)
[14:31:06] <ramiro> BMintern: you'll have to svn add your files before doing svn diff...
[14:31:08] <Vitor1001> Yes, very likely you will be just adding a single file
[14:31:17] <Kovensky> well, the problem I'm having is that av_free_packet crashes if I modify .data or .size; and the decoded audio sounds horrible =p
[14:31:46] <BMintern> i would just write vf_fade.c, vsrc_frame.c, and add the two to allfilters.c
[14:32:10] <BMintern> well, i should probably do those as two separate patches :)
[14:32:37] <Vitor1001> instead of vsrc_frame, maybe it is better a vf_duplicate
[14:32:53] <BMintern> ahh, ok
[14:33:05] <Vitor1001> that may duplicate the first frame 100 times then EOF, or just duplicate every one, or whatever...
[14:33:33] <Vitor1001> maybe a better name would be vf_clone...
[14:33:57] <Kovensky> ramiro: http://pastebin.org/124789 <-- current code
[14:34:29] <BMintern> it should probably be made to duplicate a sequence of frames, correct?
[14:34:48] <BMintern> just in my case, it would only duplicate a sequence of length 1
[14:34:59] <Kovensky> ramiro: can you spot any obvious mistakes?\
[14:35:03] <Kovensky> s/\\//
[14:35:11] <BMintern> a sequence of frames for a specified number of repetitions
[14:35:41] <ramiro> Kovensky: where does it crash?
[14:36:31] <Kovensky> ramiro: av_free_packet
[14:36:37] <Kovensky> (and the decoded audio sounds horrible)
[14:36:47] <Kovensky> http://kovensky.project357.com/files/audio.dump (lol eroge op)
[14:38:13] <ramiro> Kovensky: is that thread-safe?
[14:38:34] <Kovensky> ramiro: no, but it's not multithreaded code
[14:38:36] <ramiro> Kovensky: also look at ffplay.c for queue and such
[14:39:03] <Vitor1001> Maybe giving as parameters first_frame:last_frame:number_of_times_duplicated
[14:40:10] <BMintern> i was thinking that
[14:40:27] <BMintern> the only problem i run into is that it would be nice to be able to say clone:-1:30
[14:40:33] <BMintern> to clone the last frame 30 times
[14:40:45] <BMintern> oops clone=
[14:40:59] <BMintern> but perhaps the 2nd parameter could be optional?
[14:41:20] <BMintern> first_frame:[last_frame:]number_of_times_duplicated
[14:42:03] <BMintern> and if first_frame is -1 then number_of_times_duplicated (assuming last_frame is given) would be ignored (as last_frame would be used instead)
[14:42:07] <Kovensky> ramiro: my enqueue_packet / dequeue_packet are almost identical to ffplay's code, except without SDL code
[14:42:29] <Kovensky> (comparing to packet_queue_get and packet_queue_put)
[14:43:30] <BMintern> Vitor1001: should be take some of this discussion about specifics out of #ffmpeg-devel?
[14:44:02] <ramiro> Kovensky: hmm. if you pkt.data += something, how do you expect free to find the start of the buffer to free it?
[14:45:09] <BMintern> also, is there yet a filter to just take a bunch of inputs and concatenate them?
[14:46:43] <Kovensky> <@ramiro> Kovensky: hmm. if you pkt.data += something, how do you expect free to find the start of the buffer to free it? <-- that's why I'm looking for better sample code than http://dranger.com/ffmpeg/tutorial03.html (which uses decode_audio2)
[14:48:34] <Vitor1001> BMintern: Yes, maybe before you start coding, you should send a RFC to ffmpeg-devel
[14:49:03] <Vitor1001> So if someone think about a better design, you can implement it at first.
[14:49:22] <BMintern> well i need this like yesterday, so i'm going to go ahead and write it to do what i need and worry about changing it later
[14:50:44] <BBB___> KotH: help!
[14:51:09] <ramiro> the underline count has grown to 3
[14:51:12] <ramiro> ah, too late =)
[14:54:17] <BBB> does anyone here know mailman?
[14:54:18] <BBB> a
[14:54:49] <kshishkov> look at KotH/mru again
[14:56:17] <BBB> hm, I think I found iot
[14:58:02] <KotH> BBB: what do you want?
[14:58:09] <BBB> nothing
[14:58:14] <BBB> I figured it out myself
[14:58:16] <BBB> thanks
[14:58:24] <KotH> good
[14:58:39] <kshishkov> if all users were like that...
[14:59:05] <scaphilo> does anyone know if a decoded picture AVFrame still has its qscale_tab filled so that i can use this values in the encoder? same for motion_val
[15:03:58] <kshishkov> IIRC, all of that is stored in MPEG decoder pictures which are AVFrame extensions
[15:04:45] <kshishkov> I don't remember but it may be either copy full picture reference or only buffer pointers, so I'd not bet on it
[15:05:16] <scaphilo> thx, ill better try to copy the values than just the pointer
[15:05:38] <scaphilo> seems to happen here static void copy_picture_attributes(MpegEncContext *s, AVFrame *dst, AVFrame *src)
[15:17:58] <BBB> Vitor1001: do you mind if I change ff_acelp_apply_order_2_transfer_function() to take a const float *in and a float *out, so I don't have to memcpy() from synthesis buffer to the output buffer afterwards?
[15:18:10] <BBB> Vitor1001: that'd make it a *lot* easier to address Michael's concerns in the clipping patch
[16:02:29] <BMintern> is there a standard type to use in ffmpeg development for frame count or frame number?
[16:02:40] <wbs> uint64_t? :-)
[16:02:45] <BMintern> ok, thx
[16:02:53] <BMintern> i've never done ffmpeg development
[16:05:28] <CIA-24> ffmpeg: mstorsjo * r22694 /trunk/libavformat/ (tcp.c udp.c rtpproto.c): Don't report EINTR from select as an error, retry select instead
[16:07:12] <wbs> BBB: thanks, that was the last outstanding patch I had :-)
[16:07:39] <kshishkov> wbs, how many less great patchs do you have?
[16:07:45] <kshishkov> *patches
[16:08:25] <wbs> kshishkov: haven't any left locally that I'm aiming to submit, at the moment
[16:09:04] <wbs> but I've got a small list of stuff that I might do if I gather time again... but perhaps I should let BBB rest for a while :-)
[16:09:11] <kshishkov> well, you've said "outstanding" which means you may have patches of different quality
[16:09:40] <BBB> outstanding = unfinished work
[16:09:55] <BBB> at least in dutch ;)
[16:09:59] <BBB> not sure if it translates literally
[16:10:01] <wbs> yeah, that was the version I meant
[16:10:23] <DonDiego> ik spreek geen nederlands
[16:10:32] <wbs> as in, "number of patches submitted, with hopes of getting approval" == 0
[16:10:33] <kshishkov> BBB: I use MacOSX dictionary.app to verify, and there it's the second meaning
[16:10:51] <wbs> (which also can be achieved by outright rejecting all suggestions) ;P
[16:11:04] <BBB> DonDiego: \o/
[16:11:47] * kshishkov wonders is unfinished work _supposed_ to be extremely good since it can be described with the same word
[16:14:01] <kshishkov> BBB: Diego lives in a couple of kilometers from Netherlands, so he should be able to speak Dutch anyway
[16:15:00] <BBB> oh really
[16:15:19] <wbs> kshishkov: http://dictionary.reference.com/browse/outstanding has my meaning of the word, #3 ;P
[16:15:32] <BBB> DonDiego: http://www.dumpert.nl/mediabase/827601/ef98cc85/stephen_colbert_over_nederlanders.html
[16:15:34] <kshishkov> I'm not sure but his street may run straight into German-Dutch border too
[16:16:02] <mru> yep, been there
[16:16:18] <mru> and for the record, outstanding has two meanings
[16:16:48] <mru> it can mean either "to be completed" or "exceptionally good"
[16:17:25] <mru> comes in handy when dealing with customers :-)
[16:17:32] <kshishkov> still better than Swedish "tack" eller "hej"
[16:20:29] <DonDiego> BBB: hilarious :)
[16:20:36] <BBB> did you get the dutch parts?
[16:20:44] <BBB> boerenkool stampot met wurst
[16:21:17] <kshishkov> Dutch sounds like German with a touch of Finnish
[16:23:11] <BBB> no, german sounds like dutch with a little bit of something else
[16:23:15] <BBB> don't forget german is dutch-derived
[16:23:19] <BBB> not the other way around
[16:23:21] <BBB> ;)
[16:24:28] <kshishkov> well, judging by who owns whom (and rides on colonial roads in caravans)...
[16:24:38] <BBB> we always beat htem in soccer games
[16:25:46] * kshishkov lives in a country which is hard _not_ to beat in soccer
[16:25:57] <wbs> same here ;P
[16:26:11] <mru> sweden got the gold once
[16:26:14] <mru> in 1952 iirc
[16:26:21] <BBB> we in '88
[16:26:27] <mru> the games were hosted in stockholm...
[16:26:34] <mru> odd coincidence...
[16:26:37] <wbs> finland hasn't even qualified to any kind of higher level championships ;P
[16:26:55] <kshishkov> wbs: but you have too much racers though
[16:26:59] <mru> the best sweden has done in modern times was the bronze in '94
[16:27:13] <wbs> kshishkov: true
[16:27:41] <superdump> why are you talking about medals for football?
[16:27:52] <superdump> people win cups in international football competitions
[16:27:58] <superdump> cup or no cup
[16:28:06] <kshishkov> squashed cups then
[16:54:36] <DonDiego> BBB: please, the game is called football, not soccer
[16:54:57] <DonDiego> those us-devils have brainwashed you already..
[16:55:03] <kshishkov> depends on locale
[16:55:35] <kshishkov> DonDiego: you too. FFmpeg documentation does not have many instances of word "colour" for example
[16:55:55] <DonDiego> i fully support american english
[16:55:58] * BBB is a us-devil now
[16:56:16] <DonDiego> but not the hijacking of the word football for some rugby variant
[16:56:59] <kshishkov> at least word "soccer" reminds me of local football player quality
[16:58:23] <mru> superdump: let's start a drive for more british spelling in ffmpeg
[16:58:33] <superdump> :)
[16:58:52] <kshishkov> you have Book of Wisdom to write - all in British spelling
[16:58:54] <BBB> FFmpeug?
[16:59:23] <kierank> ffmpegh
[16:59:57] <kshishkov> DonDiego: do you know that St.Putinsburg is sometimes called "Porebrik-city" because that's their local word for curb not used anywhere else. And that's not the only example.
[17:01:16] <mru> kerb, please
[17:01:34] <kshishkov> here it's called "bordure" anyway
[17:01:47] <kshishkov> and "trottoir" for pavement
[17:02:31] <mru> same in swedish
[17:02:44] <kshishkov> and better not ask any French
[17:02:50] <mru> bloody french, poisoning our language
[17:03:00] <kshishkov> could be Germans instead
[17:04:07] <mru> or, heaven forbid, russians
[17:04:52] <kshishkov> yes, that'd be awful
[17:07:36] <kshishkov> mru: would it surprise you that original Ukrainian word for vodka is similar to "akvavit"?
[17:08:45] <mru> yes, that would surprise me
[17:08:59] <mru> akva is clearly latin-derived
[17:09:03] <kshishkov> it is - they have the same origin after all
[17:09:21] <kshishkov> yes, something like "water of life"
[17:27:42] <BMintern> Vitor1001: looking at vsrc_movie.c, i'm pretty sure there's a bug in the init function -- http://ffmpeg.pastebin.com/bBqGw8j7
[17:28:05] <BMintern> i haven't observed any buggy behavior, but i'm pretty sure that "else" doesn't belong there
[17:30:53] <BMintern> i'll just go ahead and e-mail the patch to ffmpeg-soc
[19:05:00] <lu_zero> wbs: valgrind tells me quite inane things about memory corruption
[19:05:30] <lu_zero> and s->start_time gets corrupted apparently
[19:07:02] <wbs> lu_zero: hmm, when doing what? have you made clean and rebuilt to be sure there's no build out of sync?
[19:07:09] <lu_zero> yes =|
[19:07:24] <lu_zero> pick the dss test streams for 1mbit h264
[19:07:36] <lu_zero> and try to open it
[19:07:40] <lu_zero> with ffplay
[19:08:01] <lu_zero> you'll get a start time that's quite nonzero
[19:08:43] <lu_zero>   Duration: 00:01:10.00, start: -816347974.-516000, bitrate: N/A
[19:08:58] <lu_zero> in rtsp.c it is set correctly
[19:09:55] <lu_zero> does it happen to you as well?
[19:12:46] <wbs> hmm, yes, I get this: Duration: 00:01:10.00, start: -816347762.-521000, bitrate: N/A
[19:13:01] <lu_zero> it's quite strange
[19:13:21] <lu_zero> the ntp-time range is parsed correctly
[19:13:42] <BBB> in gdb, put a watch on s->start_time
[19:13:49] <BBB> in a top function of ffmpeg.c
[19:13:52] <BBB> and see
[19:14:03] <BBB> if you give me a uri I'll look at it :)
[19:14:22] <lu_zero> BBB: localhost/any-h264-file.mov
[19:14:25] <lu_zero> ^^
[19:14:31] <lu_zero> (pick feng or dss)
[19:14:41] <BBB> playback
[19:14:41] <BBB> ?
[19:14:44] <BBB> or streaming to?
[19:15:10] <wbs> doesn't this stem from the fix for syncing multiple rtp streams, from rev 21857?
[19:15:20] <lu_zero> ffplay rtsp://media.lscube.org/tests/tc.mov
[19:15:24] <lu_zero> just streaming
[19:15:41] <lu_zero> let me have a look
[19:15:48] * lu_zero had been in a meeting for the whole day
[19:16:12] <wbs> that is, this: http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=9e9169fcb48f1fc64bf6f65ec021958c03e20762;hp=f1b4abc81054ca62ceed4f8189e4a72d8103d51c
[19:16:26] <kshishkov> lu_zero: so if you had some portable PC you could do a lot of useful things
[19:16:57] <lu_zero> kshishkov: speaking and discussing and ignoring it mostly ^^;
[19:17:24] <lu_zero> or driving and paying attention to the trucks getting next to collide
[19:17:26] <kshishkov> lu_zero: the third is more fun
[19:17:26] <lu_zero> ^^
[19:17:54] * kshishkov had done a lot of RE at lectures
[19:18:09] <lu_zero> wbs: it doesn't change s->start_time
[19:18:58] <wbs> lu_zero: no, but it changes pts of returned packets from starting at 0 previously, to starting at any arbitrary time nowadays
[19:19:22] <lu_zero> wbs: hmm
[19:19:29] <lu_zero> I'll check soon
[19:19:31] <lu_zero> now dinner ^^
[19:20:07] <wbs> lu_zero: the reason being, previously, we mapped pts=0 individually in each rtp stream to the first rtcp sender report for that stream
[19:20:13] <BBB> seems to me like start_time computation overflowed
[19:20:17] <BBB> possibly because it's negative
[19:20:23] <BBB> no memory corruption otherwise
[19:20:49] <wbs> lu_zero: ... which is fine as long as all the streams get the first rtcp at the same time, but BBB had some case where that wasn't the case, leading to pts=0 mapping to completely different times for each stream
[19:23:01] <wbs> the simple solution was to remove the subtraction of the timestamp of the first rtcp packet completely, making pts start at any arbitrary point, but them always being correctly synced
[19:23:23] <wbs> the more complex solution would be to map all streams to pts=0 when the first rtcp is received for any stream
[19:24:16] <BBB> av_update_stream_timings() changes it
[19:24:39] <BBB> -816347045215744
[19:24:41] <BBB> weird value
[19:24:52] <kshishkov> looks loke nopts
[19:24:53] <BBB> looks like a bug in that function (overflow)
[19:24:55] <BBB> no
[19:24:57] <BBB> that's -9...
[19:25:05] <BBB> -9223372036854775808
[19:25:27] <BBB> so look at that function
[19:25:33] <BBB> lu_zero: ^^
[19:27:32] <DonDiego> libavutil/error.c:38:5: warning: "HAVE_STRERROR_R" is not defined
[19:27:40] <DonDiego> (from mplayer)
[19:27:44] <DonDiego> what's going on?
[19:27:50] <DonDiego> ffmpeg is trying to replace libc now?
[19:28:03] <kshishkov> it's not in standard
[19:28:37] <mru> it's in the standard, but it's optional
[19:28:54] <kshishkov> i.e. not so standard
[19:29:05] <mru> incorrect
[19:29:11] <mru> it's standard, just optional
[19:29:19] <mru> _if_ it exists, it's defined what it does
[19:29:33] <mru> but there's no promise it'll exist
[19:32:05] <BBB> lu_zero, wbs: also
[19:32:06] <BBB> (gdb) print ic->streams[0]->start_time
[19:32:06] <BBB> $8 = -73471195502672
[19:32:06] <BBB> (gdb) print ic->streams[1]->start_time
[19:32:07] <BBB> $9 = -73471195549214
[19:32:10] <BBB> weird...
[19:32:22] <kshishkov> printf in hex
[19:33:09] <wbs> BBB: like I said, due to rev whateveritwas, the packets pts will start at (whatever random value) depending on the NTP timestamp of the first RTCP
[19:33:19] <wbs> and that's what gets stored in those fields, right?
[19:33:42] <BBB> probably
[19:33:52] <BBB> but the values a are a little wacky
[19:34:01] <BBB> might want to check that there's no overflow there already
[19:48:40] <Vitor10011> BBB: just saw your message
[19:49:51] <Vitor10011> I'm fine with making ff_acelp_apply_order_2_transfer_function() get one input and one output if it does not do any supplementary operations
[19:50:05] <Vitor10011> And it works fine for in == out
[19:50:28] <Vitor10011> And that in can be equal to out be documented in the doxy
[19:50:45] <BBB> I'll document it as such
[19:50:57] <BBB> and yes I'm not changing the function, so in==out will work
[19:54:35] <Vitor10011> So fine for me
[19:54:47] <BBB> thanks
[20:24:56] <nfl> join #beagle
[20:25:06] <nfl> sorry..
[21:06:49] * lu_zero is back
[21:07:55] <lu_zero> hmm
[21:14:45] <lu_zero> we might parse the rtpinfo
[21:15:01] <lu_zero> (if you didn't find something to solve both issues
[21:15:11] <lu_zero> BBB: which were the problematic cases?
[21:16:14] <BBB> utils.c does some wacky stuff, possibly because our start_time is random and it overflows when rescaling it
[21:17:43] <lu_zero> BBB: our start_time is -
[21:17:46] <lu_zero> err
[21:17:47] <lu_zero> 0
[21:17:56] <BBB> yes
[21:18:01] <BBB> but the rtp stream is non-zero
[21:18:03] <lu_zero> but our packet time right now is whatever...
[21:18:17] <lu_zero> which was the problem you had?
[21:18:17] <BBB> and utils.c then recalculates AVFormatCtx->start_time based on AVStream->start_time
[21:18:25] <lu_zero> meh
[21:18:30] <BBB> no problem, I was trying to help you why it had a weird value
[21:18:32] <lu_zero> understandable
[21:18:34] <BBB> that's why ;)
[21:18:49] <lu_zero> I mean what cause this patch introduction? ^^
[21:19:00] <BBB> oh
[21:19:16] <BBB> a/v sync issues between rtp streas
[21:19:26] <lu_zero> do you have a sample of them?
[21:19:34] <BBB> not publically :(
[21:19:48] <BBB> but luca A had the same experience, and so had some others, I had it with axis cameras serving h264/aac over rtp
[21:19:56] <BBB> the patch fixed it
[21:19:58] <BBB> so we applied it
[21:20:15] <BBB> I sort-of knew it'd set random start-times but decided to not care too much
[21:20:17] <BBB> maybe that's bad
[21:20:25] <BBB> av_rescale() should better handle this though :(
[21:21:35] <lu_zero> well that breaks seeking
[21:21:41] <lu_zero> completely ^^;
[21:21:54] <lu_zero> before it was just half broken ^^
[21:22:14] <lu_zero> the problem happens on pure rtp or rtsp as well?
[21:24:04] <BBB> rtsp
[21:24:12] <BBB> sorry I broke seeking :(
[21:24:16] <lu_zero> we are ignoring rtp-info
[21:24:24] <lu_zero> my fault for not testing it before ^^;
[21:24:26] <BBB> I think av_rescale() overflows
[21:24:41] <BBB> it's supposed to scale the timestamps rightly for us
[21:24:45] <BBB> so that for the app, it starts at zero
[21:24:48] <BBB> but it doesn't do that
[21:24:49] <BBB> ...
[21:25:40] <lu_zero> hmm
[21:25:56] <lu_zero> reverting the patch makes us sending something correct
[21:26:01] <lu_zero> now
[21:26:13] <lu_zero> we do not parse the RTP-Info: field
[21:26:17] <lu_zero> I think
[21:26:29] <sander> Do anyone know where the ffmpeg mailing lists are hosted?
[21:26:49] <lu_zero> mphq
[21:26:50] <lu_zero> why?
[21:27:54] <sander> Because me and 6 other friends is about to start a new python ffmpeg batch encoding tool also with php web admin interface..
[21:28:13] <sander> ..And we are looking for a mailing list like yours.
[21:28:29] <lu_zero> if is python wouldn't make more sense have it made in pylons?
[21:28:42] <lu_zero> (or any wsgi compatible framework?)
[21:28:58] <sander> We will make it command line.
[21:29:06] <lu_zero> http://ffmpeg.org/contact.html
[21:29:07] <lu_zero> ah
[21:29:17] <lu_zero> so you aren't going to redo the bindings ^^;
[21:29:26] <sander> and use that command line in the php web admin interface.
[21:29:55] <sander> lu_zero, which bindings?
[21:30:10] <lu_zero> python bindings to libav
[21:30:32] <sander> I have no idea what that is.
[21:30:50] <lu_zero> ffmpeg libraries have bindings in many languages
[21:30:55] <sander> Cool.
[21:31:12] <sander> Where can I download the python bindings?
[21:31:21] <lu_zero> to my knowledge there aren't pure cpython bindings around...
[21:31:23] <lu_zero> let me check
[21:32:55] <lu_zero>  http://fobs.sourceforge.net/index.html should have the python ones among the others...
[21:33:41] <lu_zero> BBB: _probably_ parsing and mapping the offset the RTP-Info should provide would fix your issues
[21:33:50] <lu_zero> ops, too late =_=
[21:34:54] <sander> lu_zero, if I'm going to use this bindings, does ffmpeg needs to be installed from source then?
[21:35:19] <sander> ..unless I some how get my package into some distros
[21:35:44] <lu_zero> no idea
[21:35:58] <lu_zero> I do not develop those bindings
[21:36:05] <lu_zero> probably there are other as well
[21:36:52] <sander> You dont know how to use the bindings?.. if the bindings only call ffmpeg.. or if they are apart of ffmpeg source?
[21:38:54] <sander> I'll find out.
[21:40:21] <sander> Too complicated installation process..
[21:40:25] <sander> Cant use it.
[21:41:17] <sander> Works good to just call ffmpeg from the command line.
[21:42:48] <sander> Anyway.. lu_zero: do you know if its possible that ffmpeg can host our mailing list?
[21:44:16] <sander> We can always wait untill we've made the first alpha version tho..
[21:47:02] <lu_zero> sander: I doubt it
[21:47:40] <thresh> i do have patches in ffmpeg indeed, weird (i was checking for my CV)
[21:53:03] <lu_zero> thresh: ?
[21:53:49] <wbs> lu_zero: patch sent that shows my solution suggestion for the start time sync problem - ugly but should work
[21:54:06] <wbs> but I guess we'd need BBB to test if it actually still fixes his sync issue
[21:54:34] <thresh> lu_zero: well, i could only find patch from 2006. That's why i couldnt remember which one of those i sent actually made it into mainline.
[22:31:29] <BMintern> Vitor10011: i'm lost
[22:31:39] <BMintern> i have clone finished, but it's clearly not right :-\
[22:33:48] <BMintern> well, i'm going to write up an e-mail (with a link to what i have so far) to ffmeg-soc. hopefully someone there can point me in the right direction
[22:42:01] <CIA-24> ffmpeg: darkshikari * r22695 /trunk/ffpresets/ (12 files):
[22:42:01] <CIA-24> ffmpeg: Use the newly available x264 parameters in ffmpeg in the x264 preset files.
[22:42:01] <CIA-24> ffmpeg: Patch by Lou Logan.
[22:47:37] <CIA-24> ffmpeg: stefano * r22696 /trunk/cmdutils.c: Use av_strerror() in print_error().
[23:15:15] <astrange> i introduced a perian bug by being compatible with ffmpeg -i .vob -vcodec copy .mov :/
[23:15:38] <astrange> seems like streamcopy to mov doesn't set DTS properly for lots of things, not just h264
[23:15:43] <ohsix> hur
[23:16:23] <ohsix> astrange: my bug got _some_ love; some dupes point at it now (the unreleased unused frames thing)