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

burek burek021 at gmail.com
Thu Sep 20 02:05:02 CEST 2012


[00:00] <burek> the rachelfish (on #ffmpeg) just posted a link to one cms that actually uses one file for entire website
[00:00] <burek> (cmsimple)
[00:05] <Daemon404> sounds horridc
[00:05] <burek> but it works surprisingly fast, take a look at the demo: http://demo.cmsimple-xh.dk
[00:16] <burek> who is thom? :) https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1005536
[00:18] <Daemon404> burek, i hate when people file bugs on ubuntu or debians bug tracker
[00:18] <Daemon404> and of course they never get forwarded
[00:18] <Daemon404> or they fix it with a patch and dont upstream itr
[00:18] <Daemon404> scumbag package maintainers
[00:18] <Daemon404> etc
[00:18] <burek> what is the upstream for debian/ubuntu
[00:18] <Daemon404> ?
[00:18] <Daemon404> upstream of whatever package
[00:18] <burek> oh per package, ok
[00:18] <Daemon404> for ffmpeg/libav thats us
[00:19] <llogan> i never understood that either.
[00:19] <burek> i dunno.. i really liked debian a lot, but during the last year i really really changed my mind
[00:20] <llogan> (the lack of communication and forwarding patches)
[00:20] <burek> and im thinking about centos or similar, just because of these kind of things
[00:20] <burek> because, if they did it like this with ffmpeg, who knows what else did they do "for the good of end-users, of course"
[00:20] <Daemon404> i prefer debian
[00:20] <Daemon404> because administrating debian >>>>>>>>> rhel-based things
[00:21] <Daemon404> yum sux
[00:25] Action: gnafu has never had an issue with yum, though it was considerably slower than apt, like, 4+ years ago.
[00:27] <burek> well, package management is a great deal of work on linux, where everything was ment for compiling, so it's no wonder it's a bottleneck for each distro, but you can always default to compiling things if needed
[00:27] <llogan> burek: that bug reminds me of 939863
[00:28] <burek> so, I don't know.. I'm more into things that are created by normal people with progress on their mind rather than their ego
[00:29] <burek> llogan, let me read that one too :)
[00:32] <cbsrobot-> Compiling FFmpeg using MSVC is basically impossible and unsupported, however, you can consume the mingw builds (DLL or static) in an MSVC project.
[00:32] <cbsrobot-> is this still true ?
[00:32] <cbsrobot-> it's on the wiki
[00:33] <cbsrobot-> would be nice if somebody with a ms machine could write a ms compile guide
[00:34] <llogan> burek: the wording was eventually changed, but i don't know what versions of ubuntu it was ported to.
[00:38] <burek> llogan that was a one-man-show..
[00:38] <burek> so many people are suggesting "better wording"
[00:38] <burek> and he still "although I somewhat like the *** THIS PROGRAM IS DEPRECATED ***"
[00:38] <burek> that's the kind of egomaniac people that only see their goal, not taking care about anyone else
[00:38] <llogan> yes. i was flogigng a dead horse so i didn't attempt any more patches.
[00:39] <burek> that's how the Hitler was like
[00:39] <llogan> heh. that's quite the comparison.
[00:39] <ubitux> hitler is kinda cool
[00:39] <cbsrobot-> wut ?
[00:39] <ubitux> yeah, look http://www.youtube.com/watch?v=_tILqds7-jg
[00:39] <ubitux> i never saw a debian packager doing this
[00:39] <llogan> i'd only compare stalin to hitler, but that's a whole different discussion.
[00:40] <cbsrobot-> ubitux: I never click on links posted by random strangers ...
[00:40] <ubitux> :)
[00:40] <cbsrobot-> but the song is really cool
[00:41] <ubitux> you're aware it's a remix of the meme-song of the last weeks?
[00:41] <cbsrobot-> wow the lens flares @ 1:00 - classic
[00:42] <llogan> ffmpeg needs a star-wipe filter
[00:42] <ubitux> 00:40 to 01:10 is awesome
[00:43] <ubitux> star wipe filter?
[00:44] <llogan> http://en.wikipedia.org/wiki/Wipe_%28transition%29
[00:44] <llogan> it will be the new meme
[00:45] <ubitux> oh like the star wars and things
[00:45] <ubitux> right ok :)
[00:45] <cbsrobot-> http://cdn.memegenerator.net/instances/400x/26962502.jpg
[00:46] <llogan> damn! pre-memed.
[00:46] <ubitux> :)
[00:46] <cbsrobot-> it was already there when I got there !
[00:48] <Daemon404> cbsrobot-, git matser builds with msvc
[00:48] <Daemon404> it needs to be documented how
[00:48] <Daemon404> my job...
[00:48] <cbsrobot-> Daemon404: just a twoliner on the wiki
[00:49] <Daemon404> you need to use a wrapper for cl to do it :P
[00:49] <Daemon404> --cc="c99wrap cl" --ld="c99wrap link"
[00:49] <cbsrobot-> that's what I'm talking 'bout
[00:49] <Daemon404> the wraper & converter are currently beign cleaned up
[00:49] <Daemon404> for a tarball etc
[00:49] <Daemon404> and binaries
[01:04] <burek> I'm thinking of creating some kind of gui thingy for ffmpeg, which will work on linux/win and will be kinda like vlc, showing the actual ffmpeg command line produced, while users click some boring checkboxes (usual things they ask how to do with ffmpeg)
[01:04] <burek> but im not sure if it will be useful at all
[01:04] <burek> :)
[01:05] <burek> or even better :D a web page :D that would be ultimately useless :)
[01:08] <Daemon404> sounds like MeGUI
[01:08] <Daemon404> <_<
[01:08] <Daemon404> that horrid thing
[01:10] <burek> oh great :)
[01:10] <burek> thanks :)
[01:14] <burek> I just did make -j16 on some xeon and it finished in less than a minute.. or even less.. no comment
[02:11] <Compn> yet another request to take down an old mailing list post
[02:11] <Compn> do people not realize why we have nicknames on the internet? and that once posted on the internet, its there forever ?
[02:12] <ohsix> is it funny?
[02:12] <burek> is this some kind of bug: https://paste.lugons.org/show/WwmXEFtfr9BwV6CJDRmu/
[02:12] <burek> Invalid pixel format '-1'
[02:12] <burek> ?
[02:12] <burek> or some missing library
[02:12] <Compn> ohsix:  its a person who is trying to download video from http://www.ultimate-chatzone.com/adultschat.html
[02:13] <burek> cmd was ffmpeg -i bla.flv -map 0 -b:v 3M bla.avi
[02:13] <Compn> so yes, kind of funny, if you think downloading porn is funny ;P
[02:13] <Compn> and his name is on his email! oh noes!
[02:13] <Compn> (rtmpdump post )
[02:14] <burek> lolita :)
[02:14] <burek> well, a guy likes the porn, strangely :D
[02:15] <Daemon404> [20:11] <@Compn> yet another request to take down an old mailing list post
[02:15] <Compn> yeah, guys downloading porn on the internet, must only be a dozen of them
[02:15] <Daemon404> as if thats even possible
[02:15] <Daemon404> that stuff is archived in so many places
[02:15] <Compn> i dont even respond to them most of the time :D
[02:15] <ohsix> they probably won't learn anything about disclosing things even if you could
[02:15] <Compn> i want to ask if this guy learned a lesson tho :D
[02:16] <Daemon404> Compn, i dont get the connection between porn and mailing lists
[02:16] <Compn> Daemon404 : he posted on rtmpdump list asking how to download from porn site
[02:17] <Daemon404> smart dude
[02:17] <Compn> or maybe he was just having non-porn related discussions on a porn site ...
[02:17] <Compn> :P
[02:17] <Compn> i read it for the articles!
[02:18] <burek> what does this error mean: Invalid pixel format '-1'    Error opening filters!
[02:18] <Daemon404> orite
[02:18] Action: Daemon404 forgot about that mingw patch
[02:32] <CIA-55> ffmpeg: 03Mans Rullgard 07release/0.10 * re1608014c5 10ffmpeg/libavcodec/h264.c: (log message trimmed)
[02:32] <CIA-55> ffmpeg: h264: allow cropping to AVCodecContext.width/height
[02:32] <CIA-55> ffmpeg: Override the frame size from the SPS with AVCodecContext values
[02:32] <CIA-55> ffmpeg: if the latter specify a size smaller by less than one macroblock.
[02:32] <CIA-55> ffmpeg: This is required for correct cropping of MOV files from Canon cameras.
[02:32] <CIA-55> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[02:32] <CIA-55> ffmpeg: (cherry picked from commit 30f515091c323da59c0f1b533703dedca2f4b95d)
[02:32] <CIA-55> ffmpeg: 03Michael Niedermayer 07release/0.10 * rfcb8bbf264 10ffmpeg/libavcodec/escape124.c: (log message trimmed)
[02:32] <CIA-55> ffmpeg: escape124: fix integer overflow leading to excessive memory allocation
[02:32] <CIA-55> ffmpeg: Fixes Ticket1629
[02:32] <CIA-55> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:32] <CIA-55> ffmpeg: (cherry picked from commit 3d7817048cb387de87600f2152075f78b37b60a6)
[02:32] <CIA-55> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:32] <CIA-55> ffmpeg: (cherry picked from commit 9f1e01c9915fe0c86ad2b8f50e11fee9e1b00c62)
[02:32] <CIA-55> ffmpeg: 03Mans Rullgard 07release/0.10 * r2fb4be9a99 10ffmpeg/libavformat/mov.c: 
[02:32] <CIA-55> ffmpeg: mov: set AVCodecContext.width/height for h264
[02:32] <CIA-55> ffmpeg: This is required for correct cropping of files from Canon
[02:32] <CIA-55> ffmpeg: cameras.
[02:32] <CIA-55> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[02:32] <CIA-55> ffmpeg: (cherry picked from commit 8aa93e900449c88c3169ff5636fed03f41779cac)
[02:32] <CIA-55> ffmpeg: Signed-off-by: Reinhard Tartler <siretart at tauware.de>
[02:33] <CIA-55> ffmpeg: 03Michael Niedermayer 07release/0.10 * r38c5e8fec5 10ffmpeg/libavcodec/sp5xdec.c: (log message trimmed)
[02:33] <CIA-55> ffmpeg: sp5xdec: fix off by 1 error causing a crash
[02:33] <CIA-55> ffmpeg: Fixes Ticket1633
[02:33] <CIA-55> ffmpeg: Found-by: Piotr Bandurski <ami_stuff at o2.pl>
[02:33] <CIA-55> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:33] <CIA-55> ffmpeg: (cherry picked from commit f0896a6bd94e5b45447c7d640c8e8aa95d860d7a)
[02:33] <CIA-55> ffmpeg: 03Michael Niedermayer 07release/0.10 * r1301942248 10ffmpeg/libavcodec/mpegaudio_parser.c: (log message trimmed)
[02:33] <CIA-55> ffmpeg: mpegaudio_parser: reset state to prevent it to be random
[02:33] <CIA-55> ffmpeg: Fixes Ticket1718
[02:33] <CIA-55> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:33] <CIA-55> ffmpeg: (cherry picked from commit 93b240f4a59348c07d3d7e4862227f6949c51e14)
[02:33] <CIA-55> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:33] <CIA-55> ffmpeg: (cherry picked from commit 3581ab6ce0754544b06f34f7875b731a5ca2e061)
[02:33] <CIA-55> ffmpeg: 03Ben Jackson 07release/0.10 * re2c7b37fd2 10ffmpeg/libavcodec/pthread.c: (log message trimmed)
[02:33] <CIA-55> ffmpeg: pthread: Avoid crashes/odd behavior caused by spurious wakeups
[02:33] <CIA-55> (22 lines omitted)
[02:40] <CIA-55> ffmpeg: 03Michael Niedermayer 07release/0.10 * reed53a38c9 10ffmpeg/ (Doxyfile RELEASE VERSION): 
[02:40] <CIA-55> ffmpeg: Update for 0.10.5
[02:40] <CIA-55> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:41] <burek> ubitux, can I report a little typo in ffserver's output here?
[02:44] <burek> "Container doesn't supports the required parameters" <- should be "doesn't support" (without ending S)
[02:50] Action: Compn grumbles at people not just committing typo fixes
[02:51] <ohsix> unless you manage the strings separately you may as well ignore them
[02:52] <burek> Compn, well, I'm not a developer and believe it or not, it's too complicated for me to learn a series of git commands, just to submit a single typo :S
[02:53] <ohsix> strings are typically in a .po file for you to edit :]
[02:53] <ohsix> (and translated, and committed periodically or only at the string freeze instead of a patch per typo)
[02:55] <Compn> what
[02:56] <Compn> seperate .po files are you being silly
[02:56] <Compn> all them strings are in the .c files :p
[02:56] <ohsix> i know, that's why you ignore them :] they aren't going to be translated either, so typo's are pretty irrelevant
[02:56] <Compn> burek : just trying to troll you into learning git and such 
[02:57] <Compn> you're lucky diego isnt here to beat you with the typo stick
[02:57] <burek> I know, I probably got on everybody's nerves so far :) It would practically be the easiest thing for me to finally learn it, but I'm a persistent guy.. :)
[02:57] <ohsix> is he busy fixing typo's? he missed some
[03:12] <CIA-55> ffmpeg: 03Michael Niedermayer 07release/0.10 * r50032a75d6 10ffmpeg/Changelog: 
[03:12] <CIA-55> ffmpeg: Changelog for 0.10.5
[03:12] <CIA-55> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:12] <CIA-55> ffmpeg: 03Michael Niedermayer 07release/0.11 * rb06903e6c5 10ffmpeg/Changelog: 
[03:12] <CIA-55> ffmpeg: Changelog for 0.11.2
[03:12] <CIA-55> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:15] <koorogi> burek: I submitted a patch for that typo
[03:16] <Compn> koorogi : why not just commit it ??
[03:16] Action: Compn runs around in circles
[03:17] <koorogi> I haven't committed anything to ffmpeg since the repo was on subversion.  No idea if I even can anymore
[03:17] <burek> koorogi cool :)
[03:17] <burek> thanks :)
[03:39] <michaelni> koorogi, if you register your nick i can add you to the access list. all ffmpeg devels should have op
[03:41] Action: michaelni knows he probably has forgoten a few dozen people who should be on that list too
[03:42] <michaelni> so dont hesitate to ping me if some ffmpeg devel who has a registered nick is not on that list
[04:06] <burek> michaelni, what would you do if you would have to "stall" (buffer) the video output for, like, 15 seconds
[04:06] <burek> using only ffmpeg
[04:07] <burek> (to delay the input for 15 secs)
[04:09] <michaelni> add 15 sec to the video timestamps, or did you mean something else ?
[04:09] <burek> well, to capture the lightning, it would be cool if 1 ffmpeg could constantly capture the webcam input and send the output to udp localhost port (delayed for 15 seconds)
[04:10] <burek> so that RF sensor, that detects lightning can start ffmpeg when needed to capture udp port for next 10-20 seconds to record that lightning
[04:10] <burek> so 1st ffmpeg needs to send its output like 15 seconds delayed
[04:10] <burek> if you get what i mean
[04:11] <CIA-55> ffmpeg: 03Bobby Bingham 07master * rf1b6c14297 10ffmpeg/ffserver.c: 
[04:11] <CIA-55> ffmpeg: ffserver: fix typo in log message
[04:11] <CIA-55> ffmpeg: Signed-off-by: Bobby Bingham <uhmmmm at gmail.com>
[04:18] <michaelni> burek, something with a fifo should be able to delay but
[04:19] <michaelni> a filter that detects vissual changes in brightness and records surrounding that seems simpler
[04:19] <michaelni> surrounding in time that is
[04:19] <michaelni> so it would need to buffer a bit
[04:19] <burek> does it already exist as an ffmpeg video filter, or you are speaking about a theoretical future filter?
[04:20] <michaelni> it might be possible to achive something (less well working) with some skip frame parameters
[04:21] <michaelni> but the lightning filter would be theoretical
[04:21] <michaelni> but should be quite easy to write
[04:21] <burek> the point is when the lightning strikes, it has already started (since it changed the brightness) so the beginning of it would always go missing I guess
[04:21] <burek> can fifo filter be used by cmd line
[04:22] <burek> to just delay the input
[04:27] <michaelni> it can but theres no way to force a delay, without opening a .c file in a text editor and adding that feature unless iam missing something
[04:28] <burek> ok, I was thinking like delaying the output with fifo buffer but that's not an option
[04:28] <burek> anyway, I don't want to bug you a lot :)
[04:28] <burek> I was just asking for some quick idea :)
[04:28] <michaelni> burek, quick idea, send patch :)
[04:29] <burek> :D
[04:29] <burek> +1 :)
[04:50] <michaelni> ive uploaded 0.10.5 and 0.11.2, if someone wants to test them before i link them from the download page ...
[06:46] <CIA-55> ffmpeg: 03Bobby Bingham 07master * rd0c6ac0deb 10ffmpeg/cmdutils.c: 
[06:46] <CIA-55> ffmpeg: Fix segfault with -filters option
[06:46] <CIA-55> ffmpeg: Filters now use null pointers to indicate having no input/output pads,
[06:46] <CIA-55> ffmpeg: rather than empty lists of pads. We can't assume pad is non-null
[06:46] <CIA-55> ffmpeg: anymore.
[06:46] <CIA-55> ffmpeg: Signed-off-by: Bobby Bingham <uhmmmm at gmail.com>
[09:30] <ubitux> michaelni, j-b: so there was no problem with ffmpeg with the rtmpdump thing?
[09:30] <ubitux> how come it didn't happen with the fork?
[10:51] <RT|AO> JEEBsv: so the busybox-w32 sh issue seems to be fixed (https://github.com/rmyorston/busybox-w32/issues/6), you may try: http://roy.orz.hm/soft/busybox.exe
[11:17] <j-b> ubitux: the fork does not use the same thing
[11:17] <ubitux> j-b: do you mind giving some small insight? i'm a bit curious
[11:31] <j-b> ubitux: what is your email ?
[11:31] <ubitux> ubitux at gmail
[11:32] <j-b> ubitux: dans ton mail
[11:32] <ubitux> merci e
[11:37] <mateo`> michaelni: do you think the "mxfenc: factorize samples per frame code" patch is good enough ?
[11:51] <CIA-56> ffmpeg: 03Tim Nicholson 07master * rb90210e9c5 10ffmpeg/doc/filters.texi: 
[11:51] <CIA-56> ffmpeg: doc/filters: clarify use of graph2dot
[11:51] <CIA-56> ffmpeg: The GRAPH_DESCRIPTION string supplied to graph2dot must include explicitly
[11:51] <CIA-56> ffmpeg: defined inputs and outputs which are not normally part of the command line
[11:51] <CIA-56> ffmpeg: used in a real invocation.
[11:51] <CIA-56> ffmpeg: This clarifies that requirement, and provides an example.
[11:51] <CIA-56> ffmpeg: Signed-off-by: Stefano Sabatini <stefasab at gmail.com>
[11:51] <CIA-56> ffmpeg: 03Stefano Sabatini 07master * rf398617b19 10ffmpeg/ (doc/ffprobe.texi ffprobe.c): 
[11:51] <CIA-56> ffmpeg: ffprobe: fix CSV writer output
[11:51] <CIA-56> ffmpeg: Fix regression introduced in 749ddc14fc9ebcef09965dfd98c8bf2505dc3b58.
[11:54] <TimNich> saste:  Thnx
[11:54] <saste> TimNich, thank you :)
[12:02] <ubitux> saste: is it me or the comments are not utf-8 escaped in the json output?
[12:02] <ubitux> +            "comment2": "I e Üñîçød¬"
[12:03] <ubitux> same for "comment" above
[12:04] <saste> ubitux: looks correct to me
[12:04] <saste> what kind of escaping have you in mind?
[12:04] <ubitux> mmh above is fine
[12:04] <ubitux> for json i was expected some \u+...
[12:04] <ubitux> in case of unicode
[12:05] <ubitux> but i need to check again
[12:05] <saste> ubitux, well you're the author of the code, you should know better than me...
[12:05] <ubitux> yeah sure
[12:05] <ubitux> i was just wondering
[12:05] <ubitux> i'll look at it later
[12:06] <saste> Daemon404, ubitux, I actually don't like the disposition thing
[12:06] <saste> i think i'll revert it
[12:07] <saste> and add that properly when we'll have subsection nesting
[12:07] <saste> please wait before committing controversial patches
[12:13] <ubitux> i didn't think it was really controversial, sorry about that
[12:31] <michaelni> mateo`, the patch is probably good enough, but i need someone to maintain mxfenc, can one of our not 100% busy mxf experts (you, Tjoppen, TimNich, ...) take over mxfenc maintaince? That is review patches and make sure they get applied to some git repo and then ask me to merge when it should be merged into master ... ?
[12:34] <TimNich> I thought Baptiste was looking after mxfenc?
[12:35] <michaelni> I think he is too busy :(((
[12:42] <michaelni> bcoudurier, are you ok if someone helps with / takes over mxfenc maintaince ?
[12:55] <kriegerod> could somebody advise linux c profiler which does not ignore networking waits?
[12:56] <Skyler_> oprofile with vmlinux should work okay
[13:20] <kierank> ah nice someone has a test case for the hqdn3d crash
[15:29] <CIA-56> ffmpeg: 03Justin Ruggles 07master * r7bfd1766d1 10ffmpeg/libavcodec/binkaudio.c: 
[15:29] <CIA-56> ffmpeg: binkaudio: use float sample format
[15:29] <CIA-56> ffmpeg: Use planar for DCT codec, interleaved for RDFT codec.
[15:29] <CIA-56> ffmpeg: 03Justin Ruggles 07master * r0801b5979b 10ffmpeg/libavcodec/binkaudio.c: 
[15:29] <CIA-56> ffmpeg: binkaudio: use a different value for the coefficient scale for the DCT codec
[15:29] <CIA-56> ffmpeg: Eliminates the need for vector_fmul_scalar() in each frame.
[15:29] <CIA-56> ffmpeg: 03Martin Storsjö 07master * r84cc314e40 10ffmpeg/libavformat/ (Makefile smoothstreamingenc.c): 
[15:29] <CIA-56> ffmpeg: smoothstreaming: Export the mp4 codec tags
[15:29] <CIA-56> ffmpeg: This fixes stream copy from a format that already has incompatible
[15:29] <CIA-56> ffmpeg: codec tags set. The chained ismv muxer exports this same codec tag
[15:29] <CIA-56> ffmpeg: list, so set it on this one as well, to allow the caller (and
[15:29] <CIA-56> ffmpeg: lavf common code) to set them correctly.
[15:29] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[15:29] <CIA-56> ffmpeg: 03Justin Ruggles 07master * ree90119e9e 10ffmpeg/libavcodec/binkaudio.c: 
[15:29] <CIA-56> ffmpeg: binkaudio: remove unneeded GET_BITS_SAFE macro
[15:29] <CIA-56> ffmpeg: Normal get_bits() already has overread protection.
[15:30] <CIA-56> ffmpeg: 03Mans Rullgard 07master * raeeb782c2a 10ffmpeg/configure: 
[15:30] <CIA-56> ffmpeg: configure: add --toolchain option
[15:30] <CIA-56> ffmpeg: This allows creating canned shorthands for common combinations
[15:30] <CIA-56> ffmpeg: of cc, ld etc.
[15:30] <CIA-56> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:30] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r67d501b4f1 10ffmpeg/: (log message trimmed)
[15:30] <CIA-56> ffmpeg: Merge commit '1b3439b3055b083df51d7f7838ecc6b3f708b15c'
[15:30] <CIA-56> ffmpeg: * commit '1b3439b3055b083df51d7f7838ecc6b3f708b15c':
[15:30] <CIA-56> ffmpeg:  mpegvideo: move frame size dependent memory management to separate functions
[15:30] <CIA-56> ffmpeg:  configure: add --toolchain option
[15:30] <CIA-56> (7 lines omitted)
[15:37] <CIA-56> ffmpeg: 03Janne Grunau 07master * r435c0b87d2 10ffmpeg/libavcodec/ (mpegvideo.c mpegvideo.h): 
[15:37] <CIA-56> ffmpeg: mpegvideo: add reinit function for frame parameter changes
[15:37] <CIA-56> ffmpeg: This is mainly required for frame parameter changes during frame based
[15:37] <CIA-56> ffmpeg: multithreading but single threaded usage profits too from avoiding
[15:37] <CIA-56> ffmpeg: ff_MPV_common_end()/ff_MPV_common_init() cycles.
[15:37] <CIA-56> ffmpeg: 03Janne Grunau 07master * rb16d001b62 10ffmpeg/libavcodec/rv34.c: 
[15:37] <CIA-56> ffmpeg: rv34: use ff_MPV_common_frame_size_change()
[15:37] <CIA-56> ffmpeg: Specialised functionality for size changes with the advantage of
[15:37] <CIA-56> ffmpeg: supporting frame size changes during frame-based multithreading.
[15:37] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r8846115b1a 10ffmpeg/: 
[15:37] <CIA-56> ffmpeg: Merge remote-tracking branch 'qatar/master'
[15:37] <CIA-56> ffmpeg: * qatar/master:
[15:37] <CIA-56> ffmpeg:  rv34: use ff_MPV_common_frame_size_change()
[15:37] <CIA-56> ffmpeg:  mpegvideo: add reinit function for frame parameter changes
[16:12] <saste> ubitux:
[16:12] <saste> stream.N.key=value
[16:12] <saste> but
[16:13] <saste> format.tags.key=val
[16:42] <Daemon404> [06:06] <@saste> i think i'll revert it
[16:42] <Daemon404> fial
[16:42] <Daemon404> fail even
[16:42] <Daemon404> it gives one absolutely NO way of knowing when to skip e.g. thumbnail streams
[16:42] <Daemon404> makes ffprobe useless for automation
[16:43] <saste> Daemon404, i'll readd it as soon as my subsection nesting is committed
[16:44] <Daemon404> ... or you can not revert it till its done
[16:44] <Daemon404> is it offending you to keep it in?
[16:45] <saste> Daemon404, backward compatibility
[16:45] <saste> i could keep it, but i'll break parsing when adding it again
[16:45] <Daemon404> that leaves me with two choices:
[16:45] <saste> and i don't want users to get used to a syntax which will be changed soon
[16:46] <Daemon404> 1) do not upgrade ffmpeg
[16:46] <Daemon404> 2) use a local fork
[16:46] <ubitux> saste: i don't get what you wanted to tell me with stream.N.key/format.tags.key
[16:46] <saste> ubitux: never mind
[16:46] <saste> but the syntax: format.TAGKEY=TAGVAL
[16:46] <Daemon404> saste, well any sort of ETA?
[16:46] <ubitux> saste: i think we can consider the output instable for 2-3 week
[16:46] <ubitux> assuming it's not in the next release
[16:46] <saste> seemed more logical
[16:47] <ubitux> unstable*
[16:47] <Daemon404> im not a very big fan of "hold back crucial functionality until it's done the way i like"
[16:47] <saste> Daemon404, patch is posted, now i don't know how much time it will require to review it
[16:48] <saste> Daemon404, anyway i can keep it, but keep in mind that syntax will change soon
[16:48] <ubitux> saste: i like having the metadata in a sub tree
[16:48] <ubitux> saste: what happens if a key matches a format field?
[16:48] <Daemon404> saste, ive noted that to the relevant commit message internally
[16:49] <Daemon404> git master isnt supposed to be stable
[16:49] <saste> but soon we'll release 0.12
[16:49] <Daemon404> if your stuff isnt in by that time
[16:49] <Daemon404> we can rever it in the 0,12 branch?
[16:49] <Daemon404> revert*
[16:50] <ubitux> saste: do you think your generic writer subsection still needs a lot of work?
[16:50] <saste> yes
[16:50] <saste> ubitux, it's done
[16:50] <ubitux> i can help reviewing this quickly
[16:50] <ubitux> ok in that case, let's switch soon
[16:51] <ubitux> i'll give a review round tonight if i don't forget
[16:51] <saste> ubitux, I didn't test it thoroughly (will all the possible combinations of options), but sure it passes regression tests and other custom tests
[16:51] <ubitux> ok
[16:51] <Daemon404> does ffprobe even have regression tests?
[16:51] <saste> since it is sort of a rewrite it may contains bugs
[16:51] <Daemon404> i never remember any in fate
[16:51] <ubitux> saste sent a patchset for this
[16:51] <saste> Daemon404, i posted a patch, maybe you can help reviewing it since i'm not such a fate expert
[16:52] <Daemon404> ok
[16:52] <Daemon404> oh boy im smart
[16:52] <Daemon404> i send a reply from libav-devel to ffmpeg-devel
[16:53] <Daemon404> s/send/sent/
[16:54] <ubitux> :)
[16:54] <ubitux> btw, anyone can check the waiting antispam list on ffmpeg-devel?
[16:55] <ubitux> i sent a patch from another mail, not registered
[16:55] <ubitux> so it's stuck in queue since yesterday morning
[16:55] <ubitux> i don't mind resending it, but i don't want it duplicated at some point
[16:55] <ubitux> Compn: aren't you a ml moderator?
[16:56] <Daemon404> saste, those fate tests look really annoying to maintain
[16:56] <ubitux> why?
[16:56] <ubitux> i think the main issue might be the floating printing :p
[16:57] <Daemon404> never said they were wrong -- just annoying
[16:57] <saste> Daemon404, why annoying?
[16:58] <Daemon404> need to be updated manually every time ffprobe gets a new field
[16:58] <Daemon404> like i said.. not wrong
[16:58] <saste> yes, but i fail to see better ideas
[16:59] <ubitux> i like the idea of printing all these fields
[16:59] <ubitux> i'm pretty sure it might help to trigger some other issues at some point
[17:02] <Daemon404> nut! hah!
[17:06] <gnafu> NUT: When you need a container format that is also a punchline.
[17:10] <Daemon404> gnafu, i use nut internally
[17:10] <Daemon404> (man that sounds dirty)
[17:15] <Daemon404> saste, btw so i dont sound ungrateful, your work on ffprobe is very appreciated here!
[17:16] <Daemon404> before it, it was never viable to use in productiob
[17:18] <gnafu> Daemon404: Have you ever... busted a NUT during your internal use?
[17:18] Action: gnafu runs away.
[17:18] <Daemon404> only during an easy phase
[17:21] <saste> nut is the only format where we have full control
[17:21] <saste> so it's useful, especially with regards to the testing framework
[17:22] <Daemon404> it makes me nervous to rely on it in-house
[17:22] <Daemon404> fear of random changes and lack of docs
[17:48] <saste> Daemon404, "to test has_b_frames and pals"
[17:48] <saste> if we need to test for B-frames we could add a specific test for it
[17:48] <Daemon404> saste, yes
[17:49] <Daemon404> use one of the mpeg4 samples maybe
[17:49] <saste> but to test ffprobe output it is not that useful
[17:49] <saste> i want to add fine tuned field selection, so the output from ffprobe will only show the requested fields
[17:50] <Daemon404> if its just testing output
[17:50] <Daemon404> then thats fine
[17:50] <Daemon404> i thought it was meant to test functionality too
[17:53] <burek> is there no way to edit the original ticket for enhancement on the trac?
[17:54] <nevcairiel> i dont think trac has edit features by default, post comments
[17:54] <burek> i forgot to put '=' between delay and 10
[17:54] <burek> ok
[18:04] <saste> burek: that's not going to work
[18:04] <saste> i.e. can't work at the filtering level
[18:04] <saste> you already can add a delay using setpts/asetpts
[18:05] <saste> but the running process doesn't care about the initial PTS
[18:08] <burek> changing pts will buffer the output?
[18:09] <burek> it doesn't need to be at the filtering level, but I just showed the general idea
[18:09] <burek> could be simply a new output parameter, that will do the same, like -delay 10
[18:09] <teratorn> guys, do you know why there is no content here? found off web search index: http://ffmpeg.org/libavfilter.html
[18:09] <burek> -parameter +option
[18:10] <burek> teratorn, it looks nice :)
[18:11] <teratorn> heh
[18:11] <teratorn> I just need to know how to do a png overlay
[18:12] Action: teratorn digs deeper
[18:14] <saste> teratorn, libavfilter.html was merged into ff*.html
[18:15] <saste> burek: basically you want a process which buffer data for ten seconds, and finally release it (a delayer)
[18:15] <burek> yes
[18:15] <saste> burek: why don't you simply have a process waiting on a socket, and ffmpeg starts to send data to that process only when it detects some "event" occurring
[18:16] <burek> i'm not sure i understand that idea
[18:16] <burek> the goal is to record the beginning of that process itself
[18:17] <burek> if you start recording when it already started
[18:17] <burek> you've lost the first couple of moments
[18:18] <TimNich> burek: Oh, cache recording&.
[18:19] <burek> well, I guess :)
[18:19] <burek> the goal is to catch for example a thunderbolt
[18:19] <burek> without saving to avi file for hours and later editing it
[18:19] <TimNich> Yes, some of the newer cameras include that option
[18:20] <burek> rather to have a sensor that will trigger on lightning and ffmpeg will start recording for the next, say 30 seconds
[18:20] <burek> that way we can have only vids of lightnings
[18:20] <burek> videos*
[18:21] <saste> burek: you configure a filter to detect an event
[18:21] <saste> when the event is detected, a command is sent to another filter in the filtergraph, and that starts recording
[18:21] <saste> that is forwarding frames to a given output
[18:21] <saste> (or you could mark each frame one by one, through metadata)
[18:22] <TimNich> So you feed the input into a ring buffer, then only start ffmpeg when the event happens, and it will capture everything for the ring buffer length before you started it
[18:22] <burek> saste, the problem is not to detect the moment, the problem is that when you detect a change, that means that the change already occured
[18:22] <saste> the listening process is already started, but no data is sent to it until the event happens
[18:22] <burek> TimNich exactly
[18:23] <saste> burek: you can cache frames in some filter
[18:23] <saste> and release them when the event occurrs
[18:23] <burek> saste are there any examples that I can start from?
[18:23] <saste> not saying that this is possible, but it might be (with a lot of coding)
[18:23] <TimNich> whats the capture device?
[18:24] <burek> TimNich webcam usually
[18:25] <TimNich> so could you feed the output of /dev/video, or whatever into a buffer, and pipe the output to ffmpeg?
[18:25] <burek> well, yes, but how
[18:26] <michaelni> teratorn, libavfilter.html fixed, well removed as theres no such file generated anymore
[18:28] <michaelni> we have filters.texi that gets included in ff*
[18:32] <TimNich> burek: http://lwn.net/Articles/378262/ any help?
[18:34] <burek> TimNich, well, I'm aware of circular buffers, I was just wondering is there some tool readily available that can buffer/delay a stream or maybe even ffmpeg filter/option/feature :)
[18:35] <burek> I've tried with some udp repeater tool, which was supposedly able to buffer udp packets, which would also be perfect for this
[18:35] <burek> but it failed so much, since the delay was not implemented, but rather sleep() was called to ignore packets for some time :)
[18:36] <burek> so, I should search for something that can buffer the piped data in linux or can do some udp buffering, which might also help
[18:36] <TimNich> I thought it might not be too difficult to knock up a generalised utility that read stdin and output to stdout with a vrb in the middle...
[18:37] <burek> this looks promising http://stackoverflow.com/questions/10297060/how-to-build-a-delayed-buffered-pipe
[18:41] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rd5fd610dab 10ffmpeg/libavcodec/wmavoice.c: 
[18:41] <CIA-56> ffmpeg: wmavoice: initialize best_hist_ptr to NULL to prevent (incorrect) warning.
[18:41] <CIA-56> ffmpeg: As a sideeffect this makes the code more robust if a future change leaves
[18:41] <CIA-56> ffmpeg: a path where it may be uninitialized otherwise.
[18:41] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:58] <Compn> ubitux : yes, i am mod
[18:59] <ubitux> do you mind looking at the queue?
[19:00] <Compn> i am loading it up now
[19:02] <Compn> what a am i looking for ?
[19:02] <Compn> theres 5 spams
[19:03] <Compn> its possible that llogan already deleted it 
[19:03] <ubitux> f4v
[19:03] <ubitux> ah
[19:03] <ubitux> :(
[19:03] <Compn> can you resend ?
[19:03] <ubitux> ok then
[19:03] <ubitux> i'll resend it tomorrow
[19:03] <ubitux> thx
[19:04] <Compn> blame him! :)
[19:04] <Compn> did it have [PATCH] in subj ?
[20:09] <CIA-56> ffmpeg: 03Andrey Utkin 07master * rcb3591e697 10ffmpeg/libavutil/avutil.h: 
[20:09] <CIA-56> ffmpeg: avutil: Cast AV_NOPTS_VALUE to int64_t explicitly
[20:09] <CIA-56> ffmpeg: Thus comparsion against int64_t value will not raise warning
[20:09] <CIA-56> ffmpeg: (from -Wextra set) about comparsion of unsigned and signed integer
[20:09] <CIA-56> ffmpeg: commiter added () and changed the litteral to unsigned
[20:09] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:30] <ubitux> Compn: yeah i think so, it was a git send-email
[21:34] <llogan> there's a black bear on the stairs behind my office...
[21:34] <llogan> must be the one eating garbage around town.
[21:36] <Compn> llogan : did you delete ubitux's f4v patch on ffmpeg-devel moderation queue?
[21:36] <Compn> ubitux : or did you not config git-send-email correctly ?
[21:40] <llogan> Compn: i didn't see a patch...but the queue is now empty, so i may have missed it.
[21:40] <Compn> i blame ubitux
[21:42] <llogan> i only cleared the queue within the last 30 minutes
[21:43] Action: llogan goes back to animal viewing
[21:43] <Compn> he says he posted it yesterday
[21:43] <Compn> not important
[21:43] <Compn> he can resend
[21:45] <ubitux> yeah no worry
[21:45] <ubitux> i just wanted to see it twice
[21:46] <ubitux> to avoid seeing it twice*
[21:47] Action: Compn bangs head against wall
[21:50] Action: ubitux does it as well
[22:06] <ubitux> michaelni: do you mind waiting just a bit for 0.12?
[22:06] <ubitux> i'll be done with the ogg fix soon, and we have some controversial things pending for ffprobe (in its current state)
[22:06] <ubitux> also, i'd like to push the webvtt by the end of the week
[22:07] <ubitux> so if you could wait just a little, that would be great :)
[22:43] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r270a325f0c 10ffmpeg/libavutil/des.c: 
[22:43] <CIA-56> ffmpeg: av_des_init: suppress warning about unused parameter
[22:43] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:43] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rf5326dc68e 10ffmpeg/libavfilter/filtfmts.c: 
[22:43] <CIA-56> ffmpeg: bavfilter/filtfmts: fix type for channel layouts
[22:43] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:43] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rc1f3a4d1e3 10ffmpeg/libavfilter/filtfmts.c: 
[22:43] <CIA-56> ffmpeg: libavfilter/filtfmts: fix argv/argc checks
[22:43] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:45] <Daemon404> woot
[22:45] <Daemon404> msvc fate instance is crashing
[22:45] <nevcairiel> wtf
[22:46] <nevcairiel> why is the compile step crashing now
[22:47] <Daemon404> probably converter 
[22:47] <nevcairiel> libav still works
[22:47] <Daemon404> ffmpeg tends to have changes libav doesnt
[22:47] <Daemon404> what file does it explode on?
[22:47] <Daemon404> i cant tell
[22:47] <nevcairiel> no idea
[22:48] <nevcairiel> damn -j8 jumbles everything up
[22:48] <Daemon404> yea
[22:48] <nevcairiel> let me run it manually
[22:55] <nevcairiel> i think its fixed, it compiles way too long without a crash now
[22:55] <Daemon404> well
[22:55] <Daemon404> at least let it finish
[22:56] <nevcairiel> its nearly there, and the log has it crash somewhere in avformat/avfilter
[22:56] <nevcairiel> mostly avformat i guess
[22:56] <nevcairiel> there, finished
[22:56] <nevcairiel> no crash
[22:57] <Daemon404> weird
[23:42] <michaelni> Tjoppen, mateo` what is this supposed to do: mxfdec.c: if (mxf->index_tables <= 0) { <--- index_tables is a pointer
[23:43] <michaelni> did you mean nb_index_tables <= 0 ?
[23:50] <Tjoppen> uh, is that in master?
[23:51] <Tjoppen> but: yeah, probably. I suspect it works because index_tables is NULL when nb_index_tables is zero
[23:54] <michaelni> Tjoppen, should i replace it by mxf->index_tables == 0 or nb_index_tables  <= 0 or something else ?
[00:00] --- Thu Sep 20 2012


More information about the Ffmpeg-devel-irc mailing list