Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2012

1 participants
62 discussions

ffmpeg-devel.log.20121010
by burek 11 Oct '12

11 Oct '12

[02:53] Action: Daemon404 builds clang ioc [03:35] <Daemon404> make: *** No rule to make target `doc/../tests/fate_config.sh.template', needed by `doc/fate.html'. Stop. [03:35] <Daemon404> make: *** Waiting for unfinished jobs.... [03:35] <Daemon404> ... [03:35] <Daemon404> i know ive seen this mentioned somewhere before [04:08] <Daemon404> man this thing needs a ton of ram [04:33] <burek> are we supposed to handle these kind of cases where some project X is based on ffmpeg and when an issue pops up in that project, they redirect users to our support: http://ffmpeg.gusari.org/viewtopic.php?f=12&t=697&p=1043 [04:33] <burek> what is the usual practice in such cases anyway? [04:34] <Compn> if its our bug [04:34] <Compn> they should report a sample to us and follow proper bug report guidelines [04:34] <burek> "I posted on the Serviio forum, and it was suggested that I post on the ffmpeg forum, hence why I did!" [04:34] <burek> now, his ffmpeg log is clear [04:35] <Compn> oh [04:35] <Compn> pebcak :P [04:35] <Compn> he needs to use ps3mediaserver or something [04:35] <Compn> :P [04:35] <Daemon404> the known issue is that we simply do not support dts-hd [04:36] <burek> oh yes, durandal11707 was speaking about that recently.. [04:36] <Compn> hes trying to reinvent ps3mediaserver i think? [04:36] <Compn> just point him in right direction and hope he steers that way :) [04:46] <Compn> oh [04:46] <Compn> is servillo the thing like ps3mediaplayer ? [04:46] <Compn> er ps3mediaserver [04:46] <Compn> maybe i misunderstood his report [04:47] <Compn> looks like he has a mkv which stops after 3 minutes unless he uses -ac 2 [04:47] <Compn> maybe we need his sample to reproduce [04:50] <burek> well, yes, he said it partially works [04:50] <burek> I redirected him to the bug tracker [04:56] <cone-919> ffmpeg.git 03Michael Niedermayer 0725f44b041c42: x86/dsputil_mmx: change assert() to av_assert() * 03http://tinyurl.com/9xbujvh03 [07:25] <ubitux> <@Daemon404> make: *** No rule to make target `doc/../tests/fate_config.sh.template', needed by `doc/fate.html'. Stop. // the file was moved, 'must be a .d lying [07:25] <ubitux> distclean should solve the problem :p [07:42] <Daemon404> ubitux, right. [09:29] <ubitux> meh [09:29] <ubitux> i don't remember the trick to specify protocols options... [09:36] <ubitux> oh my bad i think i get it [09:54] <cone-946> ffmpeg.git 03Paul B Mahol 07b4e516e30e70: pcx: use meaningful return values * 03http://tinyurl.com/9m2rtaz03 [10:10] <durandal_1707> j-b: does libdca handle xxch? [10:10] <j-b> of course not. [10:10] <j-b> libdca handles core and core [10:11] <j-b> and core [10:11] <j-b> did I mention core-only? [10:11] <durandal_1707> looks like libav one have more and ffmpeg one even more [10:13] <j-b> yes [10:13] <j-b> this is not really news [10:13] <durandal_1707> so why vlc still use libdca? [10:14] <j-b> I thought FFMpeg has X96 and both have XCh, or so [10:14] <j-b> durandal_1707: SPDIF [10:18] <merbanan> libdca fails to decode the lfe channel also [10:18] <merbanan> it is only silence [11:09] <nevcairiel> ffmpeg also has XBR and XXCH now [11:10] <nevcairiel> full support for HD HRA :) [11:11] <j-b> nevcairiel: does it? [11:12] <j-b> nevcairiel: never new that [11:12] <j-b> knew [11:12] <nevcairiel> only thing missing is XLL for lossless mode (also known as HD MA) [11:13] <durandal_1707> and lbr and x96 [11:13] <j-b> lbr is not really important, IMVHO [11:13] <nevcairiel> oh right it doesnt do X96 yet [11:13] <nevcairiel> lbr is only used on secondary audio on blu-rays, nice to have, but not crucial, imho [11:26] <j-b> nevcairiel: weren't there 2 different ways to store some extensions in the stream, btw? [11:27] <nevcairiel> yes [11:27] <nevcairiel> you can have a core+extensions, usually called dts-es [11:27] <nevcairiel> or is DTS HD, which has a HD header, and extensions after that [11:27] <nevcairiel> but core can only have x96 or xch, really [11:28] <j-b> nevcairiel: but XCH and X96 can be in dts-es, no? [11:29] <nevcairiel> yeah [11:29] <nevcairiel> so you can have 6.1 DTS-ES [11:29] <nevcairiel> or even 96Khz [11:32] <j-b> nevcairiel: and FFmpeg supports XCH in both core and ext? [11:32] <nevcairiel> yes [11:33] <nevcairiel> and lately, even XXCH, which usually only appears in HD extensions [11:33] <nevcairiel> have a 7.1 DTS HD HRA file which plays fine now :) [11:34] <j-b> nevcairiel: cool [12:22] <burek> this is absurd [12:23] <burek> cehoyos first flames me in one email about me not motivating people to submit tickets+samples [12:23] <burek> so that developers can investigate more on users' issues [12:23] <burek> instead of just showing them ways to workaround stuff so that it just works for them [12:23] <burek> (losing the opportunity to send user to bug trac to upload samples of media) [12:23] <burek> and when I did start to redirect them [12:24] <burek> then his attitute (again and again) drives people crazy [12:24] <burek> somebody should really tell him not to close any bug reports on the first reply [12:24] <burek> because it is really rude to cut off people like that [12:25] <burek> who have spent their time to register and create a new ticket, which takes time most of people don't have [12:25] <nevcairiel> yeah he can be quite annoying on the bug tracker [12:25] <burek> so at least that time and will should be respected and not just ignored by simply closing tickets [12:27] <burek> I mean, after all, ffmpeg team needs those reports, people dont care.. they will either fix things, pay someone to that for them or wait for sime time until the bug is fixed [12:27] <burek> so no big deal for them if they dont report bugs [12:27] <burek> but its a huge deal for ffmpeg if we loose those reports [12:40] <pettter> Apparently, MPEG streams can be enclosed in MOV files [12:41] <av500> yes [12:41] <pettter> codec tag " m1s".. [12:51] <divVerent> .long_name = NULL_IF_CONFIG_SMALL("FFM (FFserver live feed)"), [12:51] <divVerent> oops, sorry [13:05] <cone-946> ffmpeg.git 03Duncan Salerno 07a6363e3d89e7: url: Don't treat slashes in query parameters as directory separators * 03http://tinyurl.com/8k5wh7s03 [13:05] <cone-946> ffmpeg.git 03Duncan Salerno 07eea003814cc5: url: Handle relative urls being just a new query string * 03http://tinyurl.com/9e683wd03 [13:05] <cone-946> ffmpeg.git 03Duncan Salerno 0733893e6abcdc: url: Handle relative urls starting with two slashes * 03http://tinyurl.com/8oya5u703 [13:05] <cone-946> ffmpeg.git 03Martin Storsjö 077bc433b36dbb: fate: Add tests of the ff_make_absolute_url function * 03http://tinyurl.com/95mvl3q03 [13:05] <cone-946> ffmpeg.git 03Janne Grunau 073fbda309e553: avcodec: free extended_data instead address of it * 03http://tinyurl.com/9rwjtyx03 [13:05] <cone-946> ffmpeg.git 03Janne Grunau 078dd0650fe673: rtpdec_mpeg4: au_headers is a single array, simple av_free is enough * 03http://tinyurl.com/9h8uk4t03 [13:05] <cone-946> ffmpeg.git 03Diego Biurrun 07ac56ff9cc9d4: build: non-x86: Only compile mpegvideo optimizations when necessary * 03http://tinyurl.com/94dh2tb03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 0723d53c547391: atrac1: use planar sample format * 03http://tinyurl.com/8wymev903 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 07c1a9cfd1feb2: mace: use planar sample format * 03http://tinyurl.com/99pbnrd03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 077e5f04503901: pcmdec: use planar sample format for pcm_lxf * 03http://tinyurl.com/9av8zho03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 07176db0b8928a: adpcmdec: use planar sample format for adpcm_ima_qt * 03http://tinyurl.com/92qfd3h03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 071b9ac7290868: adpcmdec: use planar sample format for adpcm_ima_wav * 03http://tinyurl.com/9xxgskc03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 074356d66d784c: adpcmdec: use planar sample format for adpcm_4xm * 03http://tinyurl.com/8osnn6503 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 078b854283c346: adpcmdec: use planar sample format for adpcm_ima_ws for vqa version 3 * 03http://tinyurl.com/8cxa5uk03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 07d2b6ae02aa4d: adpcmdec: use planar sample format for adpcm_xa * 03http://tinyurl.com/9pa62yw03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 07da9620e8e593: adpcmdec: use planar sample format for adpcm_ea_r1/r2/r3 * 03http://tinyurl.com/9ck2k2k03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 07327cdb04e354: adpcmdec: use planar sample format for adpcm_ea_xas * 03http://tinyurl.com/9ptkwdl03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 074ebd74cec75c: adpcmdec: use planar sample format for adpcm_thp * 03http://tinyurl.com/8wah7oj03 [13:05] <cone-946> ffmpeg.git 03Justin Ruggles 07cbcd497f384f: adxdec: use planar sample format * 03http://tinyurl.com/9vtmtfe03 [13:05] <cone-946> ffmpeg.git 03Michael Niedermayer 07eadba3e94daa: Merge commit 'cbcd497f384f0f8ef3f76f85b29b644b900d6b9f' * 03http://tinyurl.com/8d7wcdx03 [13:06] <j-b> planar! [13:06] <durandal_1707> vlc borken [13:07] <j-b> yep [13:12] <cptspiff> i've said that for years. [13:13] <j-b> cptspiff: unlike your software... [13:13] <durandal_1707> xbmc supports planar sample formats? [13:15] <cptspiff> lol. take the lame joke for what it is [13:16] <nevcairiel> i still use rather crude small C snippets to interleave the audio again, i should add native support to my own audio buffers and let avresample do it :d [13:16] <cptspiff> vlc is the best rat oriented video player there is. i just don't like the rat, so if anything, i'm broken. [13:24] <cone-946> ffmpeg.git 03Mans Rullgard 070fb3b24adac1: build: link test programs only against static libs * 03http://tinyurl.com/8gvj3mz03 [13:24] <cone-946> ffmpeg.git 03Janne Grunau 0753e122dd4afb: swfenc: error out for more than 1 audio or video stream * 03http://tinyurl.com/93f8r3k03 [13:24] <cone-946> ffmpeg.git 03Janne Grunau 074ffbe3f3a5d9: matroskaenc: check cue point validity before reallocation * 03http://tinyurl.com/8ejpe8t03 [13:24] <cone-946> ffmpeg.git 03Janne Grunau 0718ff4d20201a: avconv: simplify memory allocation in copy_chapters * 03http://tinyurl.com/9fy7q4n03 [13:24] <cone-946> ffmpeg.git 03Janne Grunau 071afd7a118fd7: af_channelmap: free old extended_data on reallocation * 03http://tinyurl.com/95pa4p703 [13:24] <cone-946> ffmpeg.git 03Janne Grunau 07714f5ab59780: vc1dec: prevent memory leak on av_realloc error * 03http://tinyurl.com/9rkqhjv03 [13:24] <cone-946> ffmpeg.git 03Janne Grunau 076f8ef5320f4d: vc1dec: prevent memory leak in error path * 03http://tinyurl.com/9bwefs803 [13:24] <cone-946> ffmpeg.git 03Janne Grunau 078501c098687b: af_amix: prevent memory leak on error path * 03http://tinyurl.com/93dgfbz03 [13:24] <cone-946> ffmpeg.git 03Janne Grunau 07ac9a89562adc: af_resample: unref out_buf when avresample_convert returns 0 * 03http://tinyurl.com/948q5gh03 [13:24] <cone-946> ffmpeg.git 03Janne Grunau 07b94e4acb4874: cmdutils_read_file: increment *size after writing the trailing \0 * 03http://tinyurl.com/9odn5ya03 [13:24] <cone-946> ffmpeg.git 03Michael Niedermayer 0750b5477616c8: Merge commit 'b94e4acb4874843e914fd3cb8e089aff0756bb4a' * 03http://tinyurl.com/95xz54c03 [13:26] <burek> durandal11707, have you been working something on dts-hd lately? [13:26] <durandal11707> why? [13:26] <burek> if so, can you please take a look at this topic http://ffmpeg.gusari.org/viewtopic.php?f=12&t=697 [13:27] <nevcairiel> i havent had a DTS-HD file yet which didnt play properly [13:27] <nevcairiel> of course, in most cases it only plays the core [13:27] <nevcairiel> but it usually works just fine [13:27] <durandal11707> .dtshd files [13:28] <cone-946> ffmpeg.git 03Paul B Mahol 071470c8a9a3a7: takdec: remove redundant/wrong avio_tell() * 03http://tinyurl.com/9tlq4xs03 [13:28] <cone-946> ffmpeg.git 03Paul B Mahol 07eb71f027f058: dtshd: remove redundant/wrong avio_tell() * 03http://tinyurl.com/8rgobs303 [13:28] <nevcairiel> that person is playing a mkv :p [13:28] <burek> that's what he says [13:36] <durandal11707> burek: DTS-HD have limited support, OP in this case have DTS-HD-MA file which is not supported but core should still work, in other words all 6 chans should play without problems [13:39] <durandal11707> burek: i see nowhere that OP claim that issue is in ffmpeg, so clarification is needed... [13:40] <burek> durandal11707, ok, I was just asking if that's what you were working on, if he creates the ticket, so that you know what is it related to [13:40] <pettter> are there provisions for restarting parsing etc. with a different format? [13:43] <durandal11707> burek: DTS-HD-MA is not for streaming... [13:45] <burek> durandal11707, what do you suggest (if ffmpeg can actually decode that dts-hd stream), which format should he use? aac? [13:47] <durandal11707> burek: he is not transcoding (which works) but he wants to stream it as is [13:48] <durandal11707> and nothing in topic points that issue is in ffmpeg [13:49] <durandal11707> burek: and just to be sure - ffmpeg can decode dts-hd [13:49] <burek> ok, I'll try to get some more log outputs from him, to make sure what exactly is the issue [13:49] <burek> oh, I should correct my reply then [13:50] <burek> somebody did suggest that ffmpeg doesn't [13:50] <burek> [04:35] <Daemon404> the known issue is that we simply do not support dts-hd [13:50] <burek> :) [13:50] <j-b> who is gusari.org, btw? [13:50] <ubitux> burek [13:51] <ubitux> eeeh regression in webm encode! [13:51] <ubitux> (libvpx or libvorbis) [13:52] Action: ubitux bisects [13:53] <burek> j-b, gusari.org is just used as a domain hoster, to avoid registering new domains just for ffmpeg related stuff [13:53] <durandal11707> burek: that just not true, there are extensions which are part of dts-hd which are supported and there are some which are not [13:54] <burek> when we (if) decide to create an official ffmpeg forum at forum.ffmpeg.org, I'll shut that subdomain down [13:54] <burek> durandal11707, I've added a reply about that, asking him for more logs [13:54] <burek> I just wanted to be sure if I understand what the actual problem was [13:56] <cone-946> ffmpeg.git 03Anton Khirnov 07fb722a900fc5: avconv: remove -same_quant * 03http://tinyurl.com/8lp6ozf03 [13:56] <cone-946> ffmpeg.git 03Michael Niedermayer 07b7ebb49d0352: Merge commit 'fb722a900fc5cc9e003b9fef25b27ed7fc5547a2' * 03http://tinyurl.com/9v6owxf03 [14:10] <cone-946> ffmpeg.git 03Anton Khirnov 07233a5a807e76: lavc: split asv12 encoder/decoder * 03http://tinyurl.com/8u74zxz03 [14:10] <cone-946> ffmpeg.git 03Janne Grunau 0779e6e8eba203: avfilter: correct memcpy size avfilter_copy_buf_props() * 03http://tinyurl.com/8mul2oa03 [14:10] <cone-946> ffmpeg.git 03Janne Grunau 074a7c0c455547: http: use av_strlcpy instead of strcpy() without size checks * 03http://tinyurl.com/8npupt903 [14:10] <cone-946> ffmpeg.git 03Janne Grunau 07f1de23faaa61: g722enc: fix size argument in memset * 03http://tinyurl.com/9n5yxzt03 [14:10] <cone-946> ffmpeg.git 03Janne Grunau 07d5ef9354ce01: rtspdec: use av_strlcpy for writing into fixed size buffer * 03http://tinyurl.com/9fshz9l03 [14:10] <cone-946> ffmpeg.git 03Diego Biurrun 076d0beefbf6ee: swscale: Do not make ff_ symbols globally visible. * 03http://tinyurl.com/8m9dqkj03 [14:10] <cone-946> ffmpeg.git 03Michael Niedermayer 07cd6f5c4895c4: Merge commit '6d0beefbf6ee6dbf8efb522a9307e54c6ed5f702' * 03http://tinyurl.com/8c56f3403 [14:11] <ubitux> michaelni: ping [14:12] <ubitux> michaelni: 2c34367b4a17856584b3e8b64cefa1900342ebcd broke webm encoding (output unplayable with firefox for instance) [14:15] <ubitux> to reproduce: ./ffmpeg -f lavfi -i 'testsrc[out0]; aevalsrc=sin(440*2*PI*t)[out1]' -t 5 -y out.webm [14:15] <michaelni> ubitux, does -avoid_negative_ts 1 help ? [14:15] <ubitux> michaelni: yes [14:16] <michaelni> then add it to the write header of webm (and probably mkv) (could be under if(avoid_negative_ts<0)) [14:18] <cone-946> ffmpeg.git 03Diego Biurrun 07096a5d76a547: fate: Refactor setting of environment variables for groups of tests * 03http://tinyurl.com/8r93uhn03 [14:18] <cone-946> ffmpeg.git 03Mans Rullgard 074b895cb294d6: build: sanitize linking of tools and test programs * 03http://tinyurl.com/9o2bypd03 [14:18] <cone-946> ffmpeg.git 03Michael Niedermayer 07c6d39fb3c5a7: Merge remote-tracking branch 'qatar/master' * 03http://tinyurl.com/8ug7a3b03 [14:19] <ubitux> michaelni: ok will try, thx [14:28] <ubitux> michaelni: ffplays it fine btw [14:28] <ubitux> -s [14:28] <ubitux> wow. [14:28] <ubitux> ffplay plays* it fine [14:30] <divVerent> I wonder how avealsrc=tan(440*2*PI*t) would sound, if using floating point samples ;) [14:31] <pettter> is there any comprehensive list of defined ISOM/FourCC tags, apart from the one in isom.c? [14:32] <nevcairiel> for mp4 specifically? there probably is an official list somewhere [14:32] <pettter> well, I was hoping for more general .mov [14:32] <nevcairiel> well ISOM is mp4, not mov :d [14:33] <pettter> true enough, my bad [14:34] <ubitux> divVerent: ./ffplay -f lavfi -i 'aevalsrc=tan(440*2*PI*t),aformat=sample_fmts=flt' [14:34] <ubitux> like this [14:34] <divVerent> my hardware can't do this ;) [14:34] <divVerent> seriously, I am just calculating its fourier coefficients [14:36] <divVerent> apparently, its fourier series nowhere converges ;) [14:36] <MP4_maniac> pettter: http://www.mp4ra.org/codecs.html [14:37] <pettter> MP4_maniac: thanks, but the tag I'm looking for isn't there.. [14:37] <durandal11707> what tag you are looking for? [14:38] <pettter> " m1s" [14:38] <pettter> I'm currently checking if I can share the sample [14:38] <nevcairiel> what codec is that supposed to be? [14:39] <MP4_maniac> there are many unofficial fourcc in the world :P [14:39] <pettter> it looks like it's not a codec per se, but a complete MPEG stream (haven't checked if it's ES/PS/TS yet) [14:39] <nevcairiel> ew, i know of those files [14:39] <nevcairiel> they should be burned [14:39] <nevcairiel> with a passion [14:39] <av500> there is also MPEG TS in asf [14:40] <av500> TS can go anywhere :) [14:40] <nevcairiel> you can get lucky if you just open it wit ha mpeg-ts demuxer [14:40] <MP4_maniac> i cant find m1s in headers in xcode and quicktime [14:40] <nevcairiel> because they are meant to re-sync when the sync bytes get lost [14:41] <ubitux> michaelni: the tests change, i'm not sure if it makes sense: http://b.pkh.me/0001-lavf-mkv-avoid-negative-ts-by-default.patch [14:41] Action: MP4_maniac guesses " m1s" is one of unofficial fourcc [14:41] <pettter> MP4_maniac: really? I'm told the file opens in both QT and WMP [14:44] <pettter> it's actually a PS stream [14:47] <Compn> pettter : i made a list of isom for mp4 ... [14:48] <Compn> from quicktime [14:48] <Compn> but it was a few years ago [14:48] <Compn> pettter : does it play with mplayer -vc +ffmpeg12 yourfile ? [14:48] Action: Compn digs up list [14:49] <pettter> heh, I don't actually have mplayer installed [14:49] <Compn> http://wiki.multimedia.cx/index.php?title=QuickTime_container [14:49] <Compn> doh [14:50] <Compn> this site lists m1s as a isom [14:50] <Compn> http://wiki.awkwardtv.org/wiki/QT_Codec_Information [14:50] <Compn> M1S MPEG component [14:50] <Compn> google for "m1s" imdc to get good results [14:50] <Compn> imdc is the name of the quicktime decoder [14:52] <pettter> Compn: thanks! [14:52] <Compn> pettter : is it mpeg1 or mpeg2 ? [14:53] <Compn> i can just add it to ffmpeg now... [14:53] <Compn> if you cant share sample [14:53] <Compn> altho we love having samples :) [14:53] <pettter> mpeg1 video [14:53] <MP4_maniac> so mpeg-1 video in mpeg-2 ps? [14:53] <pettter> format_long_name=MPEG-PS format [14:54] <nevcairiel> its not mpeg video, its supposedly a mpeg program stream [14:54] <nevcairiel> you cant justh ook that up to the mpeg decoder [14:54] <Compn> is it .mov or ? [14:54] <pettter> it's a .mov originally yes [14:54] <Compn> m1s in .mov [14:54] <Compn> heh [14:55] <pettter> stripping the MOV header (990 bytes) gives me a parseable MPEG-PS stream [14:55] <pettter> with mpeg1video and mp2 audio [14:55] <Compn> does ffplay -f mpeg1video yourfile work ? [14:55] <nevcairiel> ffmpeg -f mpeg -i file.mov? :p [14:55] <michaelni> ubitux, probably makes sense ... [14:56] <pettter> nevcairiel: indeed [14:57] <pettter> so it's a matter of recognising the tag and restarting the parsing with the proper format? [14:57] <nevcairiel> i dont think anything like that is supported at this point [14:57] <Compn> ffmpeg is setup so that you have to add .mov tags to libavformat/isom.c [14:58] <pettter> yeah, that much I know, but as it's a format and not a codec.. [14:58] <Compn> but i'm not sure if adding it there will fix it [14:58] <Compn> yeah [14:58] <Compn> sounds like dv-in-avi stuff [14:58] <Compn> they kind of jammed a format in another format [14:58] <pettter> myeah [15:00] <ubitux> michaelni: ok, submitted, i'll wait a bit for more comments [15:00] <ubitux> thx :) [15:11] <cone-946> ffmpeg.git 03Paul B Mahol 0703cc52a07d51: takdec: fix seeking * 03http://tinyurl.com/8osje4k03 [15:17] <michaelni> ubitux, if there are no comments then the patch should be ok (/me drops it from my que of still needing a review patches) [15:17] <ubitux> michaelni: i keep that in mind [15:17] <ubitux> i'll push tomorrow or after tomorrow then [15:18] <ubitux> unless you want to fix quick [15:18] <michaelni> no hurry [15:51] <pettter> Compn, nevcairiel: http://titan.codemill.se/~peteri/scarecrowdance2.mov [15:51] <pettter> that's the sample [16:00] <Compn> ehe, mplayer plays it fine [16:01] <pettter> huh, fancy that [16:01] <Compn> it does report BUG! Invalid demuxer type in new_demuxer(), big troubles ahead. [16:01] <Compn> :) [16:01] <pettter> :) [16:01] <pettter> well, ffplay/ffmpeg doesn't [16:01] <Compn> yes, its a sample that needs some fixing [16:03] <pettter> and there's no Easy(tm) fix, is there? [16:14] <MP4_maniac> pettter: apparently, that sample is indeed mpeg-ps. one sample is mapped to one mpeg-ps stream. MPC MPEG splitter can split it lol [16:15] <pettter> MP4_maniac: lovely [16:16] <pettter> MP4_maniac: should I make a ticket? [16:19] <MP4_maniac> pettter: better than nothing [16:20] <pettter> right-o [16:26] <MP4_maniac> that mov sample has only one track http://up-cat.net/p/0b5aed3f . so the track has two separate stream (audio and video). this is similar with dv-in-avi i think [16:29] <pettter> sounds reasonable [16:30] <pettter> oh dear, and that is implemented by keeping a DVDemuxContext* inside the AVIContext? [16:49] <cone-946> ffmpeg.git 03Matthieu Bouron 07f94edfe484e9: vf_idet: remove some unnecessary statement and unused variable * 03http://tinyurl.com/9f54ows03 [16:49] <cone-946> ffmpeg.git 03Michael Niedermayer 07229e33a2b6de: avidec: override sample size of 1024 for VBR AAC * 03http://tinyurl.com/8dx2wr303 [17:02] <ubitux> michaelni: av_log(s, AV_LOG_DEBUG, "overriding sample_size\n", ast->dshow_block_align); looks wrong [17:03] <maker> how am i going to use ld for using the development version of ffmpeg? I have a foo.c file using libavsample, and after setting the correct PKG_CONFIG_PATH I get this error: /usr/bin/ld: cannot find -lavresample [17:03] <maker> I tried to remap LD_PATH, but probably I should do also $ ldconfig. Is it going to break something? [17:04] <ubitux> yay animated gif patch \o/ [17:04] <pettter> LD_LIBRARY_PATH maybe? [17:04] <ubitux> is avresample built? (--enable-avresample) [17:05] <durandal_1707> not and should not [17:05] <maker> same error, note that I have not done anything with $ ldconfig. [17:06] <maker> ubitux: yay [17:06] <ubitux> or you could just use libswresample. [17:07] <maker> ubitux: probably not, I was looking at the trac for some issues, and found one notifying a memoryleak there. [17:09] <ubitux> is Vitaliy Sugrobov on IRC? [17:09] <cone-946> ffmpeg.git 03Michael Niedermayer 0773ad355d23ab: avidec: fix 10l typo * 03http://tinyurl.com/8n2m2ws03 [17:53] <cone-946> ffmpeg.git 03Paul B Mahol 07ee109c6bc2cf: dtshd: fix seeking * 03http://tinyurl.com/8msoeun03 [18:27] <Daemon404> durandal_1707, do not push things with useless commit messages while blatantly ignoring replies. [18:36] <Daemon404> michaelni, just fyi, ffmpeg passes clang-ioc [18:36] <Daemon404> ill set up an ioc vm once my ram arrives this week [18:36] <Daemon404> and once baptiste gets my key approved... [18:42] <michaelni> Daemon404, great, thx [18:50] <cone-946> ffmpeg.git 03Paul B Mahol 072c5b1a2a6abb: txd: remove duplicated header inclusion * 03http://tinyurl.com/9c4rwu303 [18:51] <cone-946> ffmpeg.git 03Michael Niedermayer 0792c3173c84a9: qt-faststart: fix printf argument type * 03http://tinyurl.com/8nkrugp03 [18:51] <cone-946> ffmpeg.git 03Michael Niedermayer 079586db6ae504: lavc: docs: the field_order is set by the demuxer and not libavcodec for decoding * 03http://tinyurl.com/8wkuq2v03 [19:14] <burek> can someone help me with some h264 raw video from logitech c920 camera [19:14] <burek> a guy wrote a tool to capture the h264 stream from the web cam [19:14] <burek> https://github.com/csete/bonecam/blob/master/capture/capture.c#L498 [19:14] <burek> im just not sure how to pipe it to ffmpeg [19:15] <burek> something like ./capture -o | ffmpeg -f ? -r ? -i - ... [19:17] <relaxed> burek: -o - 2>/dev/null| ffmpeg -f h264 -vcodec h264 ? [19:17] <burek> let me try [19:18] <relaxed> you may also need framerate, framesize and pix_fmt [19:18] <burek> http://pastebin.com/R2BnEbYC [19:19] <burek> ill update ffmpeg just to be sure [19:19] <relaxed> add -r and -s [19:20] <burek> i dont know where to see -r [19:20] <burek> -s would be 640x480 i guess [19:22] <relaxed> output a sample from ./capture (without piping) and analyze the stream [19:22] <burek> I have a sample video.raw if it will help [19:22] <burek> :) [19:26] <burek> this is with the latest ffmpeg: http://pastebin.com/QGSAZC99 [19:41] <relaxed> -s $framesize -pix_fmt yuv420p [19:42] <Daemon404> you should not need -s for an annexb strea, [19:43] <burek> Option video_size not found. [19:43] <burek> it does not allow -s before -i [19:43] <Daemon404> i do not think its feasible to pipe h264 like that [19:43] <burek> ./ffmpeg -f h264 -s 640x480 -pix_fmt yuv420p -vcodec h264 -i video.raw -c copy -f null - [19:43] <Daemon404> it uses v4l2 [19:43] <burek> well c920 has its own internal h264 encoder (in the webcam) [19:44] <Daemon404> the proper solution is to add h264 support to our v42l code [19:44] <Daemon404> if it is not there yet [19:44] <burek> so im just trying to pipe/mux that with ffmpeg and thats it [19:44] <burek> yes, there was some talk about v4l2 not yet supporting h264 pix format [19:44] <burek> something like that [19:44] <burek> but i think its implemented in their latest head [19:45] <burek> I can upload a sample [19:45] <burek> just a sec [19:45] <Daemon404> support needs to be added to out code too [19:46] <burek> http://ffmpeg.gusari.org/uploads/sample-raw-h264-video-from-logitech-c920-w… [19:46] <burek> first 10 MB of data [20:03] <michaelni> burek, the raw can be played with ./ffplay -f rawvideo -pixel_format yuyv422 -s 640x480 -i ... [20:04] <burek> oh great :) [20:04] <burek> thanks :) [20:12] <burek> michaelni, is that sample a rawvideo or h264 video or both :D [20:13] <burek> i would expect less size with h264 for 200 frames [20:14] <burek> it's raw.. [20:14] <burek> i forgot -f [20:14] <Daemon404> lol [20:19] <ubitux> is it normal to have an aweful quality with libvpx and -quality best? [20:20] <ubitux> (and it's slow to encode) [20:23] <ubitux> it looks like something fishy: http://lucy.pkh.me/libvpx/orig.mkv http://lucy.pkh.me/libvpx/encoded.webm [20:24] <durandal_1707> i64? [20:24] <ubitux> (encoded with ffmpeg -i orig.mkv -avoid_negative_ts 1 -quality best -q:a 7 encoded.webm) [20:25] <ubitux> -quality best being a libvpxenc specific option [20:25] <ubitux> durandal_1707 ? [20:25] <ubitux> yes it's in a i64? [20:27] <durandal_1707> ubitux: bisect [20:27] <ubitux> yeah i guess so :( [20:27] <durandal_1707> ubitux: you do not set bitrate? [20:28] <ubitux> i don't, isn't it facultative with a "quality" setting? [20:29] <durandal_1707> dunno, maybe it is merge bug [20:32] <burek> michaelni, this was supposed to be the raw h264 output from the webcam: http://ffmpeg.gusari.org/uploads/sample-h264-video-from-logitech-c920-webca… [20:32] <burek> sorry :) [20:33] <burek> when I run it like this: # ./capture -f -o | ffmpeg -f h264 -i - -f null - [20:34] <burek> it doesn't start at all, but after I press ctrl+c, it says this http://pastebin.com/JKbp1bMH [20:34] <ubitux> same in 1.0... same with -crf... :( [20:35] <durandal_1707> ubitux: bisect from last time it worked, do you know when it was? [20:35] <ubitux> i don't know if it ever worked [20:36] <ubitux> i'm wondering if it's not a bad usage or something [20:38] <michaelni> burek, -f h264 [20:39] <ubitux> i don't get it, the encode really is a lot slower with quality best [20:39] <ubitux> but the video is still awful [20:39] <Daemon404> ubitux, -crf works fine [20:39] <burek> michaelni, it works like: ffmpeg -f h264 -i sample.raw ... [20:39] <Daemon404> vimeo uses it [20:39] <ubitux> Daemon404: what setting did you use? [20:39] <burek> but it doesn't work like this: ./capture -f -o | ffmpeg -f h264 -i - -f null - [20:40] <Daemon404> ubitux, -crf <crf val> [20:40] <Daemon404> as seen by x264 [20:40] <Daemon404> generally 18-20 [20:40] <ubitux> Daemon404: yes right, but what value? [20:40] <burek> -o just redirects output to stdout instead of file [20:40] <ubitux> i've tried 15-18 [20:40] <ubitux> it's still awful [20:40] <Daemon404> from what input [20:40] <Daemon404> and preset [20:40] <ubitux> i didn't set any preset [20:40] <Daemon404> medium then [20:40] <ubitux> 20:23:59 <@ubitux> it looks like something fishy: http://lucy.pkh.me/libvpx/orig.mkv http://lucy.pkh.me/libvpx/encoded.webm [20:40] <ubitux> this input [20:40] <Daemon404> >webm [20:40] <Daemon404> why are you using h264 with webm [20:41] <ubitux> ffmpeg -i orig.mkv -crf 18 -q:a 7 encoded.webm ? [20:41] <Daemon404> thats vp8 [20:41] <Daemon404> nto x264 [20:41] <Daemon404> -_- [20:41] <Daemon404> crf is x264. [20:41] <ubitux> where did i said it was h264? [20:41] <Daemon404> >crf [20:41] <Daemon404> is an x264 option [20:41] <ubitux> (libvpx also has a crf private option) [20:41] <Daemon404> ubitux, well its abusing it [20:41] <Daemon404> because avaik libvpx has no concept ofr 'crf' [20:41] <Daemon404> of* [20:41] <ubitux> {"crf", "Select the quality for constant quality mode", offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.dbl = 0}, 0, 63, VE}, [20:42] <ubitux> whatever, i tried to play with quality and crf [20:42] <ubitux> and it doesn't help [20:42] <Daemon404> thats not what crf is in x264 [20:42] <Daemon404> constant rate factor != constant quality [20:42] <Daemon404> anyway, i cant help with vp8 [20:43] <Daemon404> because... lolvp8 who uses that [20:47] <burek> wholly cannoli it works :))) [20:47] <burek> thanks a lot michaelni :))) [20:51] <burek> :beer: to relaxed and Daemon404 too, of course :))) [20:51] <burek> this is awesome... cpu on my machine is 0% :) [20:51] <burek> i can now use even raspbery :) [21:47] <ubitux> using the bitrate seems to work [21:47] <ubitux> but well.. [21:48] <cone-946> ffmpeg.git 03Michael Niedermayer 0794f5470a20d4: lavf: add a AVPROBE_SCORE_RETRY instead of using hardcoded values. * 03http://tinyurl.com/8gbjnua03 [21:48] <cone-946> ffmpeg.git 03Michael Niedermayer 07b47396b6143c: img2dec: detect .raw files only with a low score as img2 * 03http://tinyurl.com/9lur9mv03 [21:48] <cone-946> ffmpeg.git 03Michael Niedermayer 07317505b56691: lavf: do not prematurely accept a format with low score in init_input() * 03http://tinyurl.com/8uvudqb03 [22:53] <llogan> fuck. people are STILL thinking FFmpeg is dead due to that damned "This program is not developed anymore" message in ubuntu. [22:54] Action: llogan leaves to pick up ppc machine for saste to monkey with. [23:08] <ubitux> llogan: i proposed burek to write a wiki page about this [23:08] <ubitux> but he's not confortable with it [23:08] <ubitux> comfortable* [23:08] <ubitux> so feel free to write one [23:08] <Daemon404> if they didnt care to do anything but read that line that it output [23:09] <Daemon404> what makes you think theyd find said wiki page [23:09] <Daemon404> also why do you care what some lazy person thinks [23:09] <ubitux> what are they supposed to do? [23:09] <ubitux> "oh ok ffmpeg is renaming the tool okay" [23:10] <ubitux> now you're not on #ffmpeg, and regularly ppl are coming there "hey i have a problem with avconv" etc [23:10] <ubitux> it would be easier to paste them the link to the wiki page [23:10] <ubitux> with a brief summary [23:10] <ubitux> instead of wasting time derping about ffmpeg, libav, debian etc [23:11] <ubitux> like it happens half of the time [23:12] <ubitux> Daemon404: i don't think you realize how much users are abused by that message :p [23:13] <Daemon404> itll go away with 0.9 [23:13] <Daemon404> at least [23:13] <Daemon404> (libav) [23:13] <ubitux> lts and stuff will likely ship it for a while [23:14] <ubitux> and it's just a fucking patch to apply to drop/reword that message [23:14] <ubitux> they just refuse to change it... for obvious reasons. [23:14] <iive> btw, there is debian bugzilla entry, and somebody (you) should post a patch to change this message with a better one. [23:14] <ubitux> it's already done [23:14] <ubitux> i'm not a debian user [23:14] <Daemon404> i agree the message is overly vague [23:14] <iive> siretart is really just dragging his feet on the formality that there is no patch. [23:15] <iive> is it just proposal, or real patch? [23:15] <ubitux> no it's not vague Daemon404, it's a pretty obvious lie :) [23:15] <Daemon404> no it isnt [23:15] <Daemon404> it's true [23:15] <Daemon404> for libav. [23:15] <Daemon404> which is what they package. [23:15] <Daemon404> it's just misleadingly vague [23:15] <ubitux> yes but it's packaged under what name? "ffmpeg" [23:16] <iive> it is misleading at best and outright lie. [23:16] <ubitux> and the sentence doesn't say it's only true in the small libav mind scope [23:16] <Daemon404> thats for backwards compat with debian [23:16] <Daemon404> and it is being changed [23:16] <Daemon404> quite soon i hear [23:16] <iive> ubitux: this too. you should ask Debian packagers to stop abusing your trademark. [23:16] <Daemon404> ffmpeg package is beign dropped entirely. [23:16] <ubitux> but in that situation, it's a lie Daemon404. [23:16] <Daemon404> also [23:16] <Daemon404> lol @ you all [23:16] <Daemon404> so butthurt [23:16] <ubitux> it's not the problem about "it's gonna change" [23:16] <iive> Daemon404: it have been 2 years. [23:16] <ubitux> it's been 2yr like this [23:16] <ubitux> and it will stay for at least 2-3 yrs [23:16] <Daemon404> talking to siretart, he's wanted to change it for a long time [23:16] <ubitux> (lts & stuff) [23:17] <Daemon404> but been held up by otehr package maintainers [23:17] <ubitux> yeah [23:17] <ubitux> lol [23:17] <ubitux> please. [23:17] <llogan> i didn't get that impression [23:17] <iive> Daemon404: ffmpeg have been dropped from debian 2 years ago. without any discussion on the wim of a single developers. [23:17] <Daemon404> i met and talked with him irl [23:17] <Daemon404> so im pretty sure i got teh right impression [23:17] <ubitux> Daemon404: he is the sole maintainer... [23:17] <Daemon404> ubitux, OTHER package maintainers [23:17] <Daemon404> who use the fucking package [23:17] <Daemon404> asa dep [23:18] <ubitux> why do they care about the message? [23:18] <Daemon404> i was talkign about teh "ffmpeg" package name [23:18] <Daemon404> which offends you so [23:18] <iive> Daemon404: this is why you don't drop the original project when a fork appears. [23:18] <ubitux> Daemon404: in that case, if it has to be kept as "ffmpeg" the message must be changed [23:18] <Daemon404> i agree the message should be less vague and misleading [23:18] <ubitux> because it's willingly misleading [23:19] <Daemon404> i think you should stop peppering everythign with conspiratorial words [23:19] <ubitux> it's been 2yr man [23:19] <ubitux> and you're not doing user support [23:19] <Daemon404> .. you are nto familiar with debian i see [23:19] <iive> Daemon404: are you trying to say that we are over reacting? [23:19] <Daemon404> yes [23:20] <Daemon404> yes i am [23:20] <iive> this is kind of insulting. [23:20] <Daemon404> stop being butthurt [23:20] <Daemon404> youre reminded me of mans and diego [23:20] <ubitux> you don't understand Daemon404, this is a real problem [23:20] <Daemon404> with your ffmepg tribalism [23:20] <ubitux> we have to do avconv support on #ffmpeg most of the time [23:20] <ubitux> and explain users [23:20] <ubitux> it's a fucking problem for 2 years [23:20] Action: llogan wouldn't say "most". [23:20] <iive> Daemon404: then tell me, why is there no ffmpeg package in debian. [23:21] <ubitux> it's not about butthurting [23:21] <Daemon404> it really is [23:21] <ubitux> it's a real pain in practice [23:21] <Daemon404> every time libav makes a commit oyu dont like [23:21] <Daemon404> there's this bitchign session [23:21] <ubitux> that is another story [23:21] <Daemon404> its the same thing. [23:21] <llogan> all one all one all one, all one or none! [23:21] <Daemon404> and the answer is really simple [23:21] <Daemon404> "debian switched to libav. go to #libav." [23:22] <Daemon404> end. of. story. [23:22] <iive> it is the wrong approach altogether. [23:22] <ubitux> this is not helping the users, and doesn't help us either [23:22] <Daemon404> it is the correct approach [23:22] <llogan> Daemon404: did you have a bad morning or something? [23:22] <Daemon404> send them to teh channel of the people who maintain the fucking package [23:22] <ubitux> (especially when only ffmpeg is solving their problem) [23:22] <Daemon404> its simple logic [23:22] <Daemon404> a 2 year old coudl do it [23:22] <Daemon404> yes [23:23] <ubitux> we care about our abused users :) [23:23] <iive> no, it is not users fault that the most spread distribution have switched versions. [23:23] <Daemon404> remember what i said about tribalism [23:23] <Daemon404> and butthurt [23:23] <nevcairiel> if they want ffmpeg, send them to a distro that has it available :P [23:23] <Daemon404> ubitux, youre doign them a disservice. [23:23] <ubitux> how? [23:23] <ubitux> what am i doing wrong? [23:23] <Daemon404> [17:22] <@Daemon404> send them to teh channel of the people who maintain the fucking package [23:23] <ubitux> i believe they are happy about the services i provide [23:23] <Daemon404> either you do this [23:24] <Daemon404> or you stop bitching [23:24] <Daemon404> because its your own damn fault [23:24] <iive> Daemon404: actually it is the opposite of tribalism. We are helping their users too, because we are nice guys. And for this they may decide that they do want ffmpeg. [23:24] <ubitux> now it's my fault... [23:24] <ubitux> Daemon404: users installed "ffmpeg" [23:24] <Daemon404> "i need help with this package" [23:24] Action: llogan now blames ubitux for the dumb libav message [23:24] <ubitux> i believe they wanted ffmpeg. [23:24] <ubitux> llogan :DD [23:24] <Daemon404> "we dont maintain this package but let em entertain you with our fork backstory before we try and help you with a different packages" [23:25] <ubitux> i don't do that. [23:25] <ubitux> i make them try the static build first [23:25] <Daemon404> thats altogether wrong [23:25] <ubitux> and.or help them with the avconv cmd line [23:25] <Daemon404> if youre having them install or build ffmpeg [23:25] <Daemon404> youre doing it wrong [23:26] <ubitux> i'm not [23:26] <ubitux> 23:25:29 <@ubitux> i make them try the static build first [23:26] <iive> Daemon404: if you were been sold iPhone6 and go into apple store, and instead of kicking you, people there give you a real iphone5, would you be happy? [23:26] <Daemon404> ^ tribalism [23:26] <Daemon404> "ffmpeg is better so its ok" [23:26] <ubitux> isn't it? [23:26] <ubitux> :) [23:27] <ubitux> if we're working on ffmpeg it's because we believe the project is better, same for libav... [23:27] <iive> Daemon404: the whole point is, when you buy iPhone, you expect that it is Apple product. This is why you go to apple Store, not Samsung or Nokia [23:27] <Daemon404> yes but users dont give a fuck [23:27] <ubitux> exactly [23:27] <Daemon404> so dotn waste their time tryign to convert them [23:27] <Daemon404> send them to the proper place for THEIR package [23:27] <ubitux> so i'm helping the users instead of making them go in the wrong direction [23:27] <ubitux> aka: not to the project they didn't selected [23:27] <Daemon404> ... you people [23:27] <Daemon404> serious [23:27] <Daemon404> for real? [23:28] <ubitux> and yes i often point out the libav support [23:28] <Daemon404> sending them to teh support channel for the teh fuckign package theyre using is wrong? [23:28] <Daemon404> because the distro chose for them? [23:28] <ubitux> if they insist on using the non-working avconv [23:28] <Daemon404> what sort of fuckign convluted logic is this? [23:28] <ubitux> ppl come to #ffmpeg to get help on the ffmpeg package they installed [23:28] <ubitux> they ask why it's deprecated often [23:28] <nevcairiel> but its not a ffmpeg package :) [23:28] <Daemon404> ^ [23:28] <ubitux> or just use avconv [23:28] <ubitux> nevcairiel: yes, because it's a lie [23:29] <Daemon404> ugh [23:29] <nevcairiel> make them go complain at debian or ubuntu why their ffmpeg package installs libav [23:29] <Daemon404> sanity has no place in libav or ffmpeg [23:29] Action: Daemon404 goes off for a whi;e [23:29] <ubitux> nevcairiel: that's generally in the panel of options i provide [23:30] <ubitux> "try this cmd line" -> "try static build" -> if it works: build/install it (!wiki), and/or complain to your distro + long explanations [23:30] <ubitux> this is why a wiki page with a summary of these steps would be welcome. [23:31] <ubitux> if it works with the avconv, well then be it, i don't want to enter in long explanations, unless they ask [23:31] Action: michaelni upgraded debian and read a message that debian is deprecated and not maintained anymore and that i should use gentoo instead, after asking on the debian lists iam beint told that my package is now maintained by gentoo and i should ask for support there aha [23:31] <ubitux> :D [23:31] <iive> this may be a good 1'st april joke [23:32] <ubitux> oh again a deprecated message user who doesn't understand on the ml [23:32] <ubitux> Daemon404: i don't think you understand how much pain it is to deal with this [23:32] <j-b> use Windows :) [23:33] <iive> ubitux: i think he understands, and his position is that we shouldn't deal with it at all. [23:34] <llogan> back to the message...the "original" said: "This program is not developed anymore and is only provided for compatibility. Use avconv instead (see Changelog for the list of incompatible changes)" [23:34] <iive> "5B G5;>25:, =5B ?@>1;5<0" as Stalin likes to say. [23:34] <llogan> the new says: "*** THIS PROGRAM IS DEPRECATED ***\n "This program is only provided for compatibility and will be removed in a future release. Please use avconv instead." [23:34] <ubitux> haha [23:34] <ubitux> much better!... [23:34] <ubitux> caps! [23:34] <llogan> anyone know which ubuntu versions, if any, still use the old one? [23:35] <iive> indeed. much better. at least now it means that this program may be still developed. [23:35] <ubitux> the message should be "This program is deprecated in the Libav project, an alternative to the FFmpeg project" [23:36] <llogan> i tried to get some wording like that, but it was not accepted. i'll try again. [23:37] <iive> honestly, we should first force debian to stop package libav as ffmpeg [23:37] <ubitux> i can understand they have some technical issues with the name [23:37] <iive> they are quite sensitive to IP violations and we can make a huge fuss about it. [23:37] <iive> this is not our problem. [23:37] <llogan> iive: i don't know if that will cause dependent programs to hate us. [23:37] <ubitux> but refusing to change the message is a blatant hostile move [23:38] <iive> the easiest solution would be to package ffmpeg. [23:38] <iive> i mean, the real ffmpeg. [23:38] <ubitux> ffmpeg is deprecated iive ! [23:38] <iive> trademarks exists to prevent THIS exact situation. [23:39] <iive> that is, somebody smearing your good name. [23:39] <burek> you should stop wasting your time on libav.. just find a decent lawyer and sue them for copyright infringement and take some money from that [23:39] <llogan> i'm too poor to need money. [23:39] <burek> they don't care about changing that message, since they came up with the same, for a good reason [23:40] <iive> what copyright infringement? [23:40] <ubitux> it's easier in the debian policy to just add a patch changing the message [23:40] <burek> but since they are a fork, they are not allowed (legally) to use your brandings, names, copyrighted stuff and trade marks (like FFmpeg or ffmpeg) [23:40] <ubitux> "This program is deprecated in the Libav project, an alternative to the FFmpeg project" really sounds perfect for that... [23:40] <Compn> we should just ask debian to stop packaging ffmpeg [23:40] <burek> especially not in a context "Copyright by Libav developers team" [23:40] <nevcairiel> libav doesnt even have a ffmpeg anymore, debian is either shipping a rather old version or they re-added the app for compat reasons :p [23:40] <Compn> :P [23:41] <Compn> nevcairiel : they cant just axe ffmpeg binary, too many programs _require_ it [23:41] <ubitux> nevcairiel: can you say that for stable/unstable/testing and the various ubuntu releases? [23:41] <burek> the point is libav shouldn't (and mustn't) use the name ffmpeg anywhere in their fork [23:41] <iive> they can always make a symlink named ffmpeg. [23:41] <llogan> ok. my next step is to see what ubuntu versions use the old really crappy message, if any, and re-visit the bug report to get it re-worded. [23:41] <burek> no matter if it breaks the whole damn debian [23:42] <Compn> burek : mail fabrice [23:42] <nevcairiel> looks like it was released after the last release, libavs last major release is quite old already [23:42] <ubitux> the problem doesn't lie in libav anymore burek [23:42] <nevcairiel> er [23:42] <nevcairiel> removed after the last release [23:42] <ubitux> burek: they don't have ffmpeg for a long time now [23:42] <ubitux> it's just in the debian packaging [23:42] <ubitux> for retro compat issues and stuff [23:42] <ubitux> that is EXACTLY why we are pushing to fix that message [23:42] <burek> Compn, you guys are way longer in this whole business to suggest me to send an e-mail to Fabrice :) [23:43] <ubitux> i believe Fabrice is aware and don't want to mess with that [23:43] <burek> well, then why are we even discussing it anymore :) [23:43] <burek> if he doesn't care, why should we? [23:43] <ubitux> because we do user support [23:43] <Compn> no one wants to mess with it [23:43] <Compn> :P [23:44] <ubitux> arh i'm tired :( [23:44] <burek> I would mess with it a lot, if it was my project [23:44] <Compn> so email fabrice then [23:44] <Compn> dont matter if you are new or old [23:44] <burek> those guys showed who they are by the way they were acting [23:44] <Compn> fabrice is nice guy [23:44] <ubitux> burek: remember, libav can't do much now to change that [23:44] <Compn> i dont think i've ever actually talked to him... [23:44] <burek> well, it's a kinda insult that a newbee cares more about the project, then its developers who are far longer in all this.. [23:44] <ubitux> burek: the problem is now totally on debian-like distro side [23:45] <burek> so, I'm gonna skip sending that email [23:45] <ubitux> burek: and that mean the packager(s?) are just refusing to fix the message [23:45] <nevcairiel> the debian package maintainer for that package is a libav dev, so there is that [23:45] <j-b> Fabrice is aware [23:45] <ubitux> is he really a "dev"? [23:45] <nevcairiel> well some sort of dev anyway [23:45] <burek> you should've sue debian community for changing the official ffmpeg source code with their lie [23:45] <ubitux> but anyway, there is nothing to change on libav side [23:45] <ubitux> except the maintainer(s) [23:46] <llogan> i'll revisit the "message" issue, so hopefully i can resolve that, and then i'll try to get ffmpeg package to actually be FFmpeg in Ubuntu+. or at least see what they have to say. [23:46] <iive> fabrice holds the ffmpeg.org domain too, so the restoration of the project under this name happened with his blessing. [23:46] <ubitux> llogan: would you mind proposing my message so they just have to do a copy/paste? :) [23:46] <llogan> yes. a copy/paste lazyproof is in mind. [23:46] <iive> He is not active ffmpeg developer at the moment, so there is no reason for him to engage into legal conflicts on his own. [23:48] <iive> but there is that thing with the trademarks that if you don't protect them, you can loose them. [23:48] <iive> So, writing a page with explanation, then publishing a news on the homepage would be a good start. [23:49] <Compn> burek : also is good faith to give fork team some time to migrate [23:49] <burek> Compn, they gave you a fair fight for you to give them anything? :) [23:49] <Compn> burek : thats the point, we are nice people [23:49] <burek> I would just ddos them for a month to return the favor of taking over the servers like a bunch of kids [23:50] <iive> 1 year should be enough for such elite coders like them. [23:51] <iive> burek: ddos-ing service provider is quite lame and may not be entirely legal. We should not drop to their level. [23:51] <burek> anyway, I gave up on that topic, because I'm too fresh and newbee to even discuss those things.. you guys do whatever you feel like it's right [23:51] <llogan> ok, i should actually do some meatspace work today... [23:51] <burek> iive I agree, I'm just comparing things [23:52] <iive> we have given them enough time to sort out the problems. [23:52] <iive> I want to know if everybody agree that we cannot tolerate the situation in its current state. [23:53] Action: ubitux just wants to fix the message [23:54] <ubitux> there is not a single technical problem to do that [23:54] <ubitux> (in comparison to renaming the package, or trying to distribute ffmpeg in addition to ffmpeg or other solutions) [23:54] <iive> there is one, it should be done by the person who wrote the original message. [23:55] <ubitux> mmh that message comes from libav come, and in the libav scope it's "true" [23:55] <ubitux> and it got droppped from their repo so who care [23:55] <ubitux> again, the problem is in the packaging policy [23:56] <ubitux> anyway, unrelated: no one to comment/review the metadata patchset? [00:00] --- Thu Oct 11 2012

1 0

ffmpeg.log.20121010
by burek 11 Oct '12

11 Oct '12

[00:49] <bparker> I'm having a big problem with ffmpeg/libavformat not saving (or maybe corrupting?) options I'm setting in the muxer.... the problem is described and shown here: http://dpaste.com/811746/ [00:50] <bparker> like the metadata I set, as well as the bitrate, time base etc. are all removed/corrupted on the final output file, but dumping the context itself all shows the correct infop [00:50] <bparker> info* [00:50] <bparker> and I have no idea why this is happening :( [00:50] <bparker> I'm using libavformat directly in my own application [00:50] <bparker> and latest version (1.0) of ffmpeg [00:51] <bparker> on x64 arch linux [00:53] <ubitux> it's missing your cmd line [00:53] <bparker> huh? [00:53] <ubitux> for the encoded_by, -map_metadata is your friend [00:53] <bparker> I'm not using the command line program [00:53] <bparker> I'm using the libavformat library itself [00:53] <ubitux> oh, ok sorry [00:53] <bparker> in my own application [00:53] <ubitux> then it's better with the code :) [00:54] <bparker> well yes... but I was hoping there was something I obviously overlooked or that someone might know to check something, before having to create an entire (smaller) test program that reproduces this, since I can't post the full code [00:55] <ubitux> at least paste the ffmpeg related code :p [00:55] <ubitux> it's hard to guess what you are doing [00:56] <bparker> ok [00:56] <ubitux> it's a bit late for me to start reading some other code though so... [00:56] <ubitux> gl ;) [00:56] Action: ubitux & [00:56] <ubitux> (hint: you have a dedicated ml for api usagee) [00:56] <ubitux> (might get more help there) [01:03] <lake> hi guys, I am using silencedetect filter and it works well thus far. [01:03] <lake> It generates outout like this: https://gist.github.com/3862017 [01:04] <lake> I am trying to figure out the best way to remove those silent parts from my input. [01:04] <lake> I want to automate it since I have about a hundred mpeg files I need to use it on. [01:05] <lake> before i go writing a ruby or bash script, i figured i would ask if anyone had advice [01:12] <ubitux> lake: i just sent a patch to simplify this [01:12] <ubitux> but for your needs right now, just split the string :p [01:13] <ubitux> lake: at some point, you will be able to exploit results like in the ffprobe example at the end: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-October/132180.html [01:13] <lake> ubitux: can you please link me to your patch. i would be more than happy to try it out and comment if it helps [01:13] <ubitux> :) [01:13] <bparker> ubitux: http://pastebin.com/F073SBxv [01:13] <bparker> there's the code [01:14] <lake> ubitux: btw, thanks so much for your email months ago. you were quick to respond to me! thanks! [01:14] <ubitux> what mail? :p [01:15] <ubitux> i send quite a bunch of mails everyday i'm sorry i don't remember :p [01:15] <ubitux> bparker: did you base your code on the files in doc/examples? [01:16] <bparker> yea [01:16] <lake> ubitux: i don't expect you to. i'm just excited to see you here. Re: [ffmpeg] Silencedetect filter [01:16] <lake> from July [01:16] <lake> lol [01:17] <ubitux> i don't remember :( [01:18] <lake> no worries, really, i was just asking for more information and you helped. thanks. [01:19] <ubitux> okay :) [01:19] <ubitux> bparker: ok so one issue at a time... [01:19] <ubitux> are you able to keep the encoded_by with the ffmpeg cmd line? [01:20] <ubitux> if so, check how its done in ffmpeg.c/ffmpeg_opt.c [01:21] <bparker> I tried this: ffmpeg -i ~/121009-1AAA.mp4 -metadata encoded_by=test -vcodec copy test.mp4 [01:21] <ubitux> about the encoding settings, same thing, compare with ffmpeg tool, and try to play with libx264 AVOptions maybe (x264opts for instance) [01:21] <bparker> but test.mp4 does not have encoded_by tag [01:21] <bparker> I've been playing with them for days on end now >< [01:22] <bparker> really out of ideas as to what to try [01:22] <ubitux> there might be a bug with the metadata then [01:22] <ubitux> or just unsupported feature [01:22] <ubitux> like the mp4 muxer just ignoring them. [01:23] <ubitux> anyway, it's 1:22 o clock here, and i have to wake up in 5œh [01:23] <ubitux> so i'm leaving for real now :) [01:23] <bparker> mov ignores it also, but then I tried flv and it worked. [01:23] <bparker> sigh [01:23] <bparker> ok [01:24] <bparker> well thanks [04:43] <pzich> http://www.reddit.com/r/AskReddit/comments/117q87/c/c6k1tou [08:05] <lfiebach> Hi, what can be wrong if ./configure for ffmpeg says libv4l2 not found ? [08:14] <ubitux> lfiebach: because you added --enable-libv4l2 switch without having the libv4l2 library available? [08:14] <ubitux> note: this library is a wrapper, you don't actually need it most of the time [08:15] <ubitux> it just helps with some particular devices [08:19] <lfiebach> ok, what do i need for webcam support ? Only indevs ? [08:20] <lfiebach> --enable-libv4l is enabled but sysroot is different so i think ffmpef did not find it [08:28] <lfiebach> ubitux: [08:47] <ubitux> lfiebach: yes indevs should be enough [08:47] <ubitux> grep V4L2 config.h to confirm it is enabled [08:47] <ubitux> you should have: #define CONFIG_V4L2_INDEV 1 [08:48] <ashka> hello [08:49] <ashka> I'm trying to loop a video for a precise amount of time [08:49] <ashka> (I mean, not x times, just something like precisly 1h) [08:49] <ashka> I'd like to cut out a part out of the end of the original video as well. [08:49] <ashka> I've found -loop but it doesn't exists [08:49] <ashka> I'm using ffmpeg version 0.8.3-6:0.8.3-7 [08:50] <ubitux> you sure it's ffmpeg? [08:50] <ubitux> we are in ffmpeg 1.0 [08:50] <ashka> that's the latest version available in my repos [08:50] <ashka> it's sid [08:51] <ubitux> that's not ffmpeg then, it's a fork, but well. [08:51] <ashka> I should comp ffmpeg1.0 and come back then ? [08:51] <ubitux> let's try to solve your problem instead :) [08:51] <ubitux> so anyway, what is this loop thing, i don't understand [08:52] <ubitux> you want to store loop info in your output file? [08:52] <ashka> I have a video which is a musical thing [08:52] <ashka> it's very short, something like 30 sec [08:52] <ashka> and I'd like to loop it for a certain amount of time, like 1 hour [08:52] <ubitux> oh ok. [08:53] <ubitux> mmh let me think.. [08:54] <ubitux> i'm not sure that's supported but i'm gonna test something [08:54] <ubitux> give me a while [08:54] <ashka> sure, thanks for your help [08:59] <ubitux> mmh i'm kind of able to do it with a loop count, looking for doing it with a duration now [09:00] <ashka> ubitux: don't give yourself a headache huh [09:01] <ashka> the original has a fixed time [09:01] <ashka> I can fussy the loop count to get the right duratio [09:01] <ashka> duration* [09:01] <ashka> s/fussy/guess/ [09:02] <ubitux> mmh it doesn't work :( [09:03] <ubitux> a cmd line like ffmpeg -f lavfi -i movie=loopme.mkv:loop=0 -t 60 -y out.mkv was supposed to work, but it doesn't unfortunately [09:04] <ubitux> i'm opening a bug [09:10] <ashka> well at least I made you discover a bug [09:11] <ubitux> the ticket if you want to watch it: https://ffmpeg.org/trac/ffmpeg/ticket/1799 [09:11] <ubitux> now i don't see much solution [09:11] <ashka> do you have the line to loop it x times ? [09:11] <ubitux> except concatening manually several times with the concat filter or something [09:12] <ubitux> ashka: i thought it was working, but it isn't :p [09:12] <ashka> even for a non-given duration [09:12] <ashka> ?* [09:12] <ubitux> yes [09:12] <ubitux> it's the same issue [09:12] <ashka> oh well. [09:12] <ashka> thanks for your help [09:12] <ubitux> sorry :) [09:13] <ubitux> i'm trying to find another trick. [09:14] <ubitux> maybe with a pipe.. [09:14] <ubitux> ashka: what's the input format? [09:15] <ashka> WebM [09:15] <ashka> but I could convert it [09:16] <brontosaurusrex> ashka, how about playback side? mplayer can loop [09:16] <ashka> I'm open to any solution [09:16] <ashka> yet, the machine has no X server [09:17] <brontosaurusrex> uhmm, explain where the playback will happen, elaborate, ill be back in 10, smoke time .... [09:18] <ashka> I want to get the new video into a file [09:18] <ubitux> ashka: i'm going to try to add the feature somehow, do you have some time? :) [09:18] <ashka> looped video* actually [09:18] <ashka> ubitux: if you've got motivation, well yes [09:18] <ashka> I've got pleny [09:18] <ashka> plenty* [09:19] <ubitux> perfect, then give me something like 1 hour to see if that's possible easily [09:19] <lake> I have videos recorded at 640x480. When I use dvdauthor it complains about "unknown mpeg2 aspect ratio" [09:20] <lake> my capture script looks like this: https://gist.github.com/3863702 [09:21] <ubitux> ashka: while i'm trying to patch it, you should start cloning the repository and build ffmpeg [09:21] <ubitux> so you can apply the patch later [09:21] <ashka> I have just cloned it [09:21] <ashka> thanks for your time [09:32] <divVerent> again one of those "why doesn't this work" questions... https://gist.github.com/3863736 [09:32] <divVerent> reordering the filter_complex commands doesn't fix it [09:32] <ubitux> i don't think -filter_complex options can be stacked [09:33] <divVerent> they can't? damn [09:33] <divVerent> oddly, I get the same error when I reverse the order of the options [09:33] <divVerent> so it apparently does store them both [09:33] <ubitux> -filter_complex '[0:0]null[VIDEO_IN]; [VIDEO_IN]null[VIDEO_OUT]' [09:33] <divVerent> ubitux: yes, that works [09:33] <divVerent> but that's hard to edit ;) [09:33] <divVerent> I prefer the command line to stay orderly... so if possible, I'd like to avoid that [09:33] <ubitux> calling -filter_complex again will overrid the string [09:33] <ubitux> (i believe) [09:33] <divVerent> ubitux: nope ;) [09:33] <divVerent> when I reverse them [09:33] <divVerent> it still complains about [VIDEO_IN]null[VIDEO_OUT] [09:34] <divVerent> there can be more than one graph, just how to connect them [09:34] <ubitux> it might be parsed, then overrided [09:34] <divVerent> why would anyone code that ;) [09:34] <ubitux> cause you're not supposed to need multiple -filter_complex? [09:34] <divVerent> what is the nb_filtergraphs variable good for then? [09:34] <ubitux> ok i think i've the loop patch but i'm unable to test it :( [09:35] <ubitux> divVerent: ah dunno, then i might be wrong [09:35] <ubitux> maybe for multiple outputs? [09:35] <ubitux> (output files) [09:35] <divVerent> apparently, the feature to have multiple graphs is intended [09:35] <divVerent> and I am trying to figure out how to use it [09:36] <divVerent> yes, possibly the graphs have to be independent [09:36] <divVerent> that'd be an annoying limitation though [09:40] <ashka> oh btw ubitux [09:40] <ashka> what is it with avconv ? [09:40] <ashka> ffmpeg says that avconv should be used instead [09:44] <ubitux> it's the fork i was talking about [09:44] <ubitux> http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html [09:44] <ashka> oh okay [09:45] <ubitux> tl;dr: ^F packaging on that page [09:45] <ashka> btw, are you using a fork of the git repo for your patch ? [09:45] <ashka> I could push your changes into my local repo to build ffmpeg [09:45] <ubitux> i'll likely send you a patch to git am, if i succeed [09:46] <ubitux> that's not yet guaranted :( [09:51] <ubitux> oh i get it working. [09:51] <ubitux> but it will only work with mpeg files (so you have to re-encode or remux it) [09:54] <ubitux> ashka: do you have a working ffmpeg git/master? [09:57] <ubitux> ashka: anyway, with git/master: wget 'http://b.pkh.me/0001-lavf-file-WIP-loop.patch'; git am 0001-lavf-file-WIP-loop.patch [09:57] <ubitux> and then something like ./ffmpeg -fileloop 1 -i loopme.mpg -t 3600 -y out.mkv [09:58] <ubitux> (assuming you ffmpeg -i loopme.webm loopme.mpg) [09:58] <ubitux> i'll submit this patch later [10:54] <ubitux> ashka: so? :) [10:55] <ashka> ubitux: it just finished compiling [10:55] <ashka> currently trying it out [10:56] <ashka> [matroska,webm @ 0x1da3340] Unknown entry 0x18538067\n[matroska,webm @ 0x1da3340] Unknown entry 0x1A45DFA3 [10:56] <ashka> got a whole lot of these all of the sudden [10:56] <ashka> it's spamming [10:56] <ashka> not sure if it's still writing output [10:56] <ubitux> what's your cmd line? [10:56] <ashka> no, output is stuck [10:56] <ashka> ffmpeg -fileloop 1 -i in.webm -t 3600 out.mkv [10:57] <ashka> oh nvm [10:57] <ashka> I didn't see the line assuming blah [10:57] <ashka> my bad [10:59] <ubitux> explaination: mpeg streams are concatanable, so you i can just restart sending packets from the beginning [10:59] <ubitux> it's not possible with mkv [11:00] <ubitux> ideally we should fix the movie=...:loop=0 thing, but hopefully the patch should be a temporary workaround for your needs :p [11:00] <ubitux> btw, you might even be able to ffmpeg -fileloop 1 -i loopme.mpg -t 3600 -c copy -y out.mpg [11:01] <ashka> oh really ? [11:01] <ashka> should be way faster [11:01] <ashka> I'll try [11:01] <ashka> hmm nope [11:01] <ashka> av_interleaved_write_frame(): Invalid argument [11:01] <ubitux> ok :( [11:01] <ashka> ([matroska @ 0x222dca0] Can't write packet with unknown timestamp) [11:01] <ubitux> note the mpg mpg [11:01] <ashka> oh [11:02] <ashka> [mpeg @ 0x2e38ca0] packet too large, ignoring buffer limits to mux it\n[mpeg @ 0x2e38ca0] buffer underflow i=0 bufi=44059 size=44461 [11:02] <ashka> still, is that okay ? [11:02] <ubitux> dunno i didn't try [11:02] <ashka> yet it looks like it's copying anyway [11:02] <ashka> I'll wait for it to be done [11:20] <ashka> hmm [11:20] <ashka> ubitux: it worked [11:20] <ashka> I have a little additional question [11:21] <ashka> can I cut out a few frames every time at the beginning of the original ? [11:21] <ashka> since it's a music thing I need to make it so it syncs [11:21] <ubitux> in multiple steps :p [11:22] <ubitux> ./ffmpeg -i in.webm -ss 12 loopme.mpg [11:22] <ubitux> to skip 12 seconds [11:22] <ashka> oh [11:22] <ashka> how can I skip 15 frames ? [11:22] <ubitux> mmh a bit more painful [11:22] <ashka> hmm [11:22] <ashka> maybe a precise amount of ms [11:23] <ubitux> is it only video? [11:23] <divVerent> hm... I suppose I am compiling ffmpeg wrong... with virtually identical options, my mplayer based libavcodec encoding code outperforms ffmpeg's own conversion by far... just looking for ideas where to look [11:23] <ashka> video + audio [11:23] <ubitux> then use a precise ts [11:23] <ubitux> -ss 12.345 [11:23] <ashka> okay, I'll try [11:23] <divVerent> ah, okay... the x264 parameters differ, just why... ;) [11:23] <JEEB> haha, yeah -- ffmpeg has problems if you just want to do trim(0,100) or something like that, because you have to set stuff by times [11:24] <JEEB> divVerent, ffmpeg should nowadays use stuff pretty close to x264's defaults by default [11:24] <divVerent> exactly [11:24] <divVerent> that's why I wonder [11:24] <divVerent> so does my mplayer based encoding code (NOT mencoder) [11:24] <divVerent> I found one differing x264 option... took it out now [11:24] <JEEB> I think one of the only things it does differently from command line x264 is that libx264 doesn't limit refs by level [11:25] <JEEB> but that's comparing x264cli and libx264 [11:25] <divVerent> tune=animation... okay, that brings ffmpeg up to 54fps, still with mplayer I get like up [11:25] <divVerent> yes, and I am comparing two different libavcodec/libavformat frontends [11:25] <divVerent> which are compiled against the same library [11:26] <divVerent> CPU usage is 200% (I have two cores) in both cases [11:26] <divVerent> AH... I see ONE difference. The aac codec... [11:26] <divVerent> wonder if libfdk_aac is slow ;) [11:26] <divVerent> nope, that's not it [11:27] <divVerent> is there any way to "Profile" ffmpeg in a simple way? [11:27] <divVerent> like, to get simple output like "25% time in decoding, 30% in filtering, 50% in encoding, -5% in lying"? ;) [11:27] <ubitux> someone was asking on the devel channel yesterday i think :p [11:28] <divVerent> HA! found the cause [11:28] <divVerent> ffmpeg not at fault ;) [11:28] <divVerent> stupid notebook... suddenly reduced clock speed [11:28] <ubitux> you have a -benchmark(_all?) option btw [11:28] <divVerent> still, such profiling would be nice [11:29] <divVerent> BTW, style question regarding ffmpeg options: be lazy or add stream suffix always? ;) [11:29] <divVerent> for options that only the v codec but not the a codec knows [11:29] <divVerent> e.g. -tune:v animation [11:30] <ubitux> no idea :) [11:30] <divVerent> and thanks, -benchmark_all is nice but weirdly inaccurate [11:30] <divVerent> probably needs processing the output (summing up by the various step names) [11:31] <Mavrik> divVerent: you'll have to use a tool like gprof on ffmpeg build with debug information in [11:31] <Mavrik> for profiling [11:32] <divVerent> right, I didn't want the large cannons though ;) [11:32] <divVerent> just the little info useful for tuning options, like, in which of the major steps most time is spent [11:32] <divVerent> so I know if I e.g. have to change the swscale parameters or the x264 codec ones [11:32] <divVerent> gprof slows down the run a lot, which makes it somewhat unattractive [11:33] <divVerent> (okay, actually, compiling with -pg does </nitpick>) [11:34] <Mavrik> yeah well, that's because it's collecting data about function calls :) [11:34] <divVerent> sure, I know what gprof does... it's just not the tool of choice in many cases [11:34] <divVerent> in fact, I'd be highly surprised if it even works right when linking against a non-profiling libx264 [11:38] <ashka> ubitux: works fine :) thanks a lot for the workaround [11:38] <Mavrik> divVerent: it works, just the x264 data is missing :) [11:38] <ubitux> ashka: great, i'll submit a patch tonight, it might get upstream later [11:38] <Mavrik> anyway, as you noticed, if you want fast benchmarking you won't get accurate results [11:39] <divVerent> sure [11:41] <divVerent> why is the hall of shame page down "until it is updated"... C&D? [12:11] <ashka> oh btw ubitux [12:11] <ashka> this is minor, but you might be able to fix it [12:12] <ashka> a video of 10h will last 10:00:00.01 [12:12] <ashka> totally minor [12:14] <divVerent> ubitux: my current (mostly autogenerated) filter chain: [12:14] <divVerent> -filter_complex '[SUBVIDEO_IN]scale=max(480\,floor(320*dar/2+.5)*2):max(floor(480/dar/2+.5)*2\,320)[scaled]; [scaled] setsar=1:1 [VIDEO_OUT];[0:0][0:1]overlay[SUBVIDEO_IN]' [12:51] <divVerent> .long_name = NULL_IF_CONFIG_SMALL("FFM (FFserver live feed)"), [12:51] <divVerent> is this format considered stable in ffmpeg? [12:51] <divVerent> i.e. can I "safely" use this as interchange format from a program to ffmpeg? [12:51] <divVerent> it is probably the simplest somewhat feature complete format we have [12:52] <divVerent> the one catch probably is that it depends on some enums in ffmpeg headers, especially AVCodecID and that pixel format enum [12:53] <divVerent> (in my application, I'd only want to send rawvideo and PCM audio, and let ffmpeg do the encoding) [12:53] <burek> divVerent, did you check format 'nut' [12:54] <burek> ffm is ffserver-specific format [12:54] <divVerent> nut is quite complex [12:54] <divVerent> I want something I can generate from like 100 lines of code [12:54] <divVerent> or is there a spec of nut and what ffmpeg's muxer does is way over the top? [12:55] <divVerent> I mean, probably nut is far from that complex, when you restrict it to the particular use case (rawvideo/pcm) [12:55] <burek> check the source code :) [12:55] <divVerent> the source code is exactly what doesn't help me here :) [12:55] <divVerent> nutenc.c is quite complex still [12:56] <divVerent> a spec would help here, obviously [12:56] <burek> did you try [12:56] <burek> :) [12:57] <divVerent> I actually did some months ago [12:57] <divVerent> but found nothing useful [12:57] <divVerent> ah, now I see [12:57] <divVerent> the spec is hidden in mplayer sources [12:57] <burek> wtf [12:58] <divVerent> http://code.google.com/p/mplayer-mirror/source/browse/trunk/DOCS/tech/mpcf.… looks like what I had wanted [12:58] <burek> fflogger doesn't like nut format apparently :) [12:58] <divVerent> hehe [13:00] <divVerent> one thing about nut format I don't get though [13:00] <divVerent> is it allowed if the timestamps are "messy"? ;) [13:00] <divVerent> like, can one happily encode half a second of video, then half a second of audio, etc. [13:01] <divVerent> or do timestamps have to monotonous across all streams (like e.g. ogg requires IIRC) [13:02] <burek> http://wiki.xiph.org/Nut_Container [13:57] <divVerent> is it a bug or a feature that I can't extract subtitles from an ogm file to ass directly [13:57] <divVerent> but can when going via mkv? [13:57] <divVerent> ogm uses CODEC_ID_TEXT subtitles [13:57] <divVerent> trying to convert this to ass says that there is no decoder for the codec, which is true [13:57] <divVerent> but using the "copy" codec to plug into mkv, then going from mvk to ass works [13:59] <divVerent> i.e. "works as intended", or "to the tracker"? [13:59] <divVerent> https://gist.github.com/3865174 - the shell script part in question [14:01] <divVerent> $t here is the codec_type [14:05] <divVerent> the mkv file claims to have the subtitles in "subrip" format, which is what I would also expect here [14:07] <ubitux> i don't understand the question/problem [14:07] <ubitux> what are you trying to do? [14:07] <divVerent> I want to export ogm subtitles as .ass [14:07] <divVerent> so I can use them with the vf_ass filter [14:10] <divVerent> haha, I now see why my hack works [14:10] <divVerent> {"S_TEXT/UTF8" , AV_CODEC_ID_SUBRIP}, [14:10] <divVerent> {"S_TEXT/UTF8" , AV_CODEC_ID_TEXT}, [14:10] <divVerent> {"S_TEXT/UTF8" , AV_CODEC_ID_SRT}, [14:10] <divVerent> I start with AV_CODEC_ID_TEXT, which I plug into mkv via -codec copy [14:10] <divVerent> it becomes S_TEXT/UTF8 in the mkv [14:10] <divVerent> now, when READING this mkv file again, it becomes AV_CODEC_ID_SUBRIP [14:10] <divVerent> which can be converted to .ass fine [14:12] <divVerent> so... doesn't that mean that the ogm would have chances to work, if the demuxer decided on AV_CODEC_ID_SUBRIP instead of AV_CODEC_ID_TEXT? [14:13] <divVerent> if yes, this sounds like trac material [14:27] <ubitux> divVerent: and ffmpeg -i in.ogm out.ass doesn't work? [14:27] <divVerent> exactly [14:28] <divVerent> to do it with two short commands: ffmpeg -i in.ogm -codec copy -map 0 temp.mkv && ffmpeg -i temp.mkv out.ass [14:28] <divVerent> works fine [14:28] <divVerent> oops, actually the latter may not work [14:28] <divVerent> needs -vn -an probably ;) [14:28] <divVerent> but you get the idea [14:37] <ubitux> can i have a sample? [14:37] <divVerent> don't have one at a place from where I can upload... but my guess is that any ogm with subs will work [14:38] <divVerent> hm... maybe I can make one quickly somehow [14:41] <divVerent> I just encoded real crap quality... don't care ;) [14:42] <relaxed> divVerent: -map 0:s would copy just the subs [14:42] <divVerent> damn... ffmpeg refuses to write the ogm file I want... need ogmmerge then ;) [14:43] <divVerent> it also refuses to plug srt INTO ogm [14:43] <ubitux> :) [14:46] <divVerent> http://ompldr.org/vZnRxbw/out2.ogm [14:46] <divVerent> test file for this [14:46] <ubitux> thx [14:47] <ubitux> nice video test source [14:47] <divVerent> hehe [14:47] <divVerent> it's a test image generator I am working on [14:47] <ubitux> maybe we could improve our -f lavfi -i testsrc :) [14:48] <divVerent> probably not. Different applications need different test images. [14:48] <divVerent> haha, that one also uses a LCD hack [14:48] <divVerent> to get simple digit rendering code ;) [14:48] <ubitux> :) [14:50] <divVerent> my filter BTW is a dynamically loadable filter for some mplayer fork... it PROBABLY should be easy to port to other code bases [14:50] <divVerent> given it basically works on raw yuv444p output [14:50] <divVerent> in planes [14:50] <divVerent> the background is BTW a nice test for telecine/detelecine filters ;) [14:50] <ubitux> Dialogue: 0,0:00:00.50,0:00:02.50,Default,Hello, world! [14:50] <divVerent> mplayer's -vf filmdint horribly fails it, -vf pullup works [14:50] <ubitux> ok got it. [14:51] <divVerent> but only via mkv, right? [14:51] <divVerent> these are the exact times I set [14:51] <ubitux> just a quick hack [14:51] <ubitux> - st->codec->codec_id = AV_CODEC_ID_TEXT; [14:51] <ubitux> + st->codec->codec_id = AV_CODEC_ID_SUBRIP; [14:51] <divVerent> hehe, I see [14:51] <ubitux> in libavformat/oggparseogm.c [14:51] <ubitux> i'm looking at making a text decoder [14:51] <ubitux> i though we had one.. [14:52] <ubitux> divVerent: do you know the markup of subtitles in ogg? [14:52] <ubitux> no markup at all? that's really plain text? [14:52] <divVerent> don't know [14:52] <divVerent> never seen them have any markup [14:52] <divVerent> they always look plain [14:52] <ubitux> not even <i> and crap like that? [14:52] <divVerent> haha, now I see the difference between CODEC_ID_SRT and CODEC_ID_SUBRIP [14:52] <divVerent> I am not aware of any [14:52] <ubitux> ok [14:53] <ubitux> yeah the SUBRIP is to workaround a problem [14:53] <ubitux> originally the packets included the timestamps [14:53] <divVerent> right [14:53] <divVerent> like in SRT files [14:53] <ubitux> and it was a pain for mkv demuxer for examples [14:53] <ubitux> (it had to write the ts in the payload) [14:53] <divVerent> and SUBRIP is the timestamp-less version [14:53] <divVerent> which uses pts [14:53] <ubitux> yes, that's actually the "codec" [14:53] <ubitux> the srt demuxer should be fixed [14:53] <ubitux> to output subrip packets [14:54] <divVerent> so is CODEC_ID_SRT still in use? [14:54] <divVerent> ah, THERE it still is used ;) [14:54] <ubitux> and we could get rid of CODEC_ID_SRT [14:54] <ubitux> :) [14:54] <divVerent> right [14:54] <ubitux> i need to do a lot of work on the subtitles [14:54] <divVerent> personally, I think the right way to handle ogm is to use the SUBRIP format [14:54] <ubitux> a long work in progress :) [14:54] <divVerent> because you almost always embed srt files into ogm [14:54] <ubitux> really? [14:54] <divVerent> this is just how these are made with ogmmerge [14:54] <divVerent> it wants srt input [14:54] <divVerent> and just sticks them in with no conversion of markup if any [14:54] <ubitux> what happens if you merge a file with markup? [14:54] <divVerent> it doesn't care [14:54] <divVerent> it just plugs it in [14:54] <ubitux> great.. [14:55] <ubitux> well then i guess the patch i propose could be pushed [14:55] <ubitux> if you can wait until tonight i'll submit it [14:55] <divVerent> ogm isn't very common any more [14:55] <ubitux> (or you can submit the patch right now) [14:55] <divVerent> and I doubt thsi has ever been specified [14:55] <divVerent> given ogm was created as a hack to make an "avi replacement that can embed subtitles" [14:55] <divVerent> based on ogg [14:55] <ubitux> what about ogg? [14:56] <divVerent> at least ffmpeg's ogg demuxer has no subtitle support [14:56] <divVerent> not sure if the container supports them [14:56] <divVerent> of course, one can always cause the ogm specific code to be invoked ;) [14:56] <divVerent> as ogm basically is a superset [14:56] <divVerent> with FOURCCs and such crap [14:56] <divVerent> xiph.org probably should know if this ever was intended... [14:56] <ubitux> i mean, does ogg defines the way to store text subtitles? [14:57] <ubitux> anyway, i'll submit tonight for comments [14:57] <ubitux> we'll see [14:57] <divVerent> right [14:58] <divVerent> if anyone has a complaint, they will say so ;) [14:58] <ubitux> rhaa i need to find some time for all the subtitles thing :( [14:58] <divVerent> this MAY break players that use lavf to decode subtitles (hint: mplayer) if for some reason they handle ogm/text but not ogm/srt [14:58] <divVerent> can't imagine why though [14:58] <ubitux> why would it break? [14:58] <ubitux> the demuxer is changing the codec [14:58] <divVerent> exactly [14:58] <ubitux> so mplayer will be aware of it [14:59] <divVerent> if a player for some reason only supports CODEC_ID_TEXT but not CODEC_ID_SUBRIP [14:59] <divVerent> then it will break [14:59] <divVerent> in fact, it looks like it WILL break in mplayer2 at least [14:59] <divVerent> but wonder how it plays srt-in-mkv then [15:00] <divVerent> https://gist.github.com/3865504 - this code section makes me think that [15:00] <ubitux> oh that sucks. [15:01] <divVerent> just, IF that is the case, shouldn't mkv playback with such subs already be broken [15:01] <ubitux> i remember seeing some patches in mplayer indeed [15:01] <ubitux> but not mplayer2 [15:01] <ubitux> since it's still mostly based on libav by default [15:02] <ubitux> but mplayer2 has its own demuxer by default so.. [15:02] <divVerent> it IS broken [15:02] <ubitux> mkv* demuxer [15:02] <divVerent> in mplayer2 [15:02] <divVerent> but only with -demuxer lavf [15:02] <divVerent> because it has its own mkv demuxer [15:02] <divVerent> and thus by default doesn't hit this issue [15:02] <ubitux> the mkv demuxer is pretty nice in mplayer2 :p [15:02] <divVerent> okay, go ahead then [15:02] <ubitux> so no reason to fallback on lavf :D [15:02] <divVerent> it's easy to fix in mplayer2 [15:02] <ubitux> no it's not [15:02] <divVerent> sure it is [15:02] <ubitux> because libav has no SUBRIP codec id [15:02] <divVerent> they just have to support CODEC_ID_SUBRIP too [15:02] <ubitux> have fun. [15:02] <divVerent> haha [15:03] <divVerent> even then, should this really stop ffmpeg? [15:03] <divVerent> okay, mplayer-svn then can add CODEC_ID_SUBRIP to that list ;) [15:03] <ubitux> it's already done i believe [15:03] <divVerent> and mplayer2 uses libav anyway so they won't ever see the patch [15:03] <ubitux> (in mplayer) [15:03] <ubitux> mplayer2 is supposed to be buildable against the two [15:03] <ubitux> so you need some conditional crap [15:03] <divVerent> I just wonder one thing [15:03] <ubitux> you might want to discuss this with uau :) [15:03] <divVerent> the alternative would be better CODEC_ID_TEXT support, BUT... [15:04] <divVerent> in case of ogm, the proper type is actually SUBRIP I am pretty sure [15:04] <ubitux> we could introduce a codec id text decoder [15:04] <ubitux> but it's different [15:04] <divVerent> I think I once saw <i> tags on the screen with mplayer years ago [15:04] <divVerent> in ogm files [15:04] <ubitux> it would mean raw text [15:04] <divVerent> so apparently someone did it [15:04] <divVerent> right, in case of ogm, the actual source is typically srt though [15:04] <divVerent> and ogm encodes no "more exact" info [15:04] <ubitux> maybe we could assume text is subrip in all/most of the case [15:05] <ubitux> because most muxers will end up muxing crap at some point [15:05] <ubitux> under the "text" name [15:05] <divVerent> is the markup even a subrip feature [15:05] <divVerent> or is that just an extension by many players and then used by srt scripts? [15:05] <ubitux> it's supposed to be [15:05] <ubitux> i don't know much the history [15:05] <ubitux> but it's associated with it at least [15:06] <divVerent> basically, in my opinion two things are needed to fulyl resolve all of this ;) [15:06] <divVerent> 1. the ogm demuxer change (it is correct for typical ogmmerge usage, and ogmmerge IS the one reference ogm muxer) [15:06] <divVerent> 2. adding proper CODEC_ID_TEXT support wouldn't be bad either ;) [15:06] <ubitux> ok so far [15:07] <divVerent> as CODEC_ID_TEXT can still come out of other sources, even mkv [15:07] <ubitux> it's pretty easy to write actually [15:07] <divVerent> sure, probably copypaste the srt file and remove all parsing ;) [15:08] <ubitux> yes [15:09] <ubitux> ok i'm going to write it asap [15:09] <ubitux> hopefully submitted tonight [15:09] <ubitux> so much pending patches today.. [15:10] <ubitux> lavfi meta inject, loop in file protocol, webm regression, ogg/text/subrip, and now text decoder... [15:10] <ubitux> quite a productive day [15:13] <divVerent> and I have replaced my mplayer encoding use by ffmpeg for a change... just wondering whether it'd be a good or bad idea to release these horrible shell scripts ;) [15:13] <divVerent> which do language based stream selection, hardsubbing (both of DVD and ASS subs) and still support custom filter options by the caller [15:13] <ubitux> :D [15:14] <divVerent> is there BTW an easier way to do this: [15:14] <divVerent> scale=\ [15:14] <divVerent> $mode($w\\,floor($h*dar/$div+.5)*$div):\ [15:14] Action: ubitux thinks he's going to support all the mpl2 vplayer and crap in one row.. [15:14] <divVerent> $mode(floor($w/dar/$div+.5)*$div\\,$h)\ [15:14] <divVerent> I basically want to scale with 1:1 pixel aspect so that it in both dimensions is >= 480x320 (iPhone half res) [15:15] <divVerent> $mode is max here :P [15:15] <divVerent> so the general idea is, width = larger of (original width, target height * DAR) [15:15] <divVerent> and height = larger of (original height, target width / DAR) [15:15] <ubitux> did you look at the different variables in libavfilter/vf_scale, and the function in eval? [15:15] <divVerent> yes [15:15] <ubitux> i don't see any avg() [15:15] <divVerent> but I saw no easier way [15:15] <ubitux> :( [15:16] <divVerent> the $div crap is also needed... [15:16] <divVerent> mainly because x264 refuses odd dimensions [15:16] <divVerent> rint() is missing BTW [15:17] <ubitux> it's pretty easy to add functions in eval [15:17] <divVerent> oh, BTW, the reason why I do so weird scaling... the iPhone basically has a zoomed out view (default, image is letterboxed) and zoomed in view (i.e. cropped to screen aspect, scaled as large as possible) [15:17] <divVerent> and I optimize for the zoomed in view here [15:18] <divVerent> I just don't like havikng to use an expression evaluator for this... there should really rather be a way to say "fit into 480x320" or "crop and center to 480x320" [15:19] <ubitux> i agree with this [15:19] <ubitux> like the rescale in imagemagick? :) [15:19] <divVerent> yes [15:19] <divVerent> I was just looking up imagemagick's syntax for that ;) [15:19] <ubitux> i often wonder about this [15:19] <divVerent> 480x320^ [15:19] <ubitux> -resize WxH [15:19] <divVerent> would be imagemagick's name for what I want [15:19] <divVerent> and 480x420 would be the letterboxing version [15:20] <divVerent> 480x320! is the aspect-breaking version [15:20] <ubitux> maybe it would be possible to have a keep-aspect-ratio thing [15:20] <ubitux> anyway, i won't do it, but feel free to send a patch :) [15:20] <divVerent> yes, basically I was thinking of adding flags for this [15:20] <divVerent> two modes for that, obviously... just like imagemagick [15:21] <divVerent> of course [15:21] <divVerent> if the expression evaluator could work with complex numbers... [15:21] <divVerent> then we could do -filter:v "scale=aspect_letterboxed(w,h,480,320)" [15:21] <divVerent> and scale would work with a single expression returning w*i+h ;) [15:22] <ubitux> you can define custom functions [15:22] <divVerent> sure [15:22] <ubitux> with eval [15:22] <divVerent> but with the current way, you'd need two expressions still [15:22] <divVerent> like, width_letterboxed(w,h,480/320):height_letterboxed(w,h,480/320) [15:22] <divVerent> s!/!,! [15:22] <divVerent> g [15:22] <ubitux> oh, right. [15:22] <divVerent> that' [15:22] <ubitux> that's because of the nasty format :) [15:22] <divVerent> s how I got to complex numbers [15:23] <ubitux> args[strcpsn(s,":")]='x' [15:23] <ubitux> here you go \o/ [15:23] <uau> divVerent: there's no good spec for what markup subrip "should" support AFAIK [15:23] <uau> so CODEC_ID_SUBRIP would still be ambiguous [15:23] <divVerent> ubitux: the x is really the smallest issue ;) [15:24] <ubitux> mmh i'm stupid yeah. [15:24] <divVerent> also, width_letterboxed() even contains one ;) [15:25] <uau> also there are files with markup that could not conform to any sane spec [15:26] <ubitux> divVerent: i don't think that's really a problem to define two local functions in vf scale named lboxw() and lboxh() :p [15:26] <uau> like relying on the behavior of some players where libass tags are interpreted too (because srt support is implemented with an ASS renderer, and the implementation fails to properly quote things that can be interpreted as ASS tags) [15:29] <creep> hi [15:37] <divVerent> ubitux: it is not [15:37] <divVerent> but -vf scale=lboxw(DAR,320,240):lboxh(DAR,320,240) [15:37] <divVerent> is still a lot more verbose than [15:37] <divVerent> -vf scale=320:240:lbox [15:37] <ubitux> yup better syntax :) [15:38] <divVerent> also, lboxw is not sufficient alone ;) also need to round to codec specific mutliples [15:38] <divVerent> so... [15:38] <divVerent> -vf scale=round(lboxw(DAR,320,240),8):round(lboxh(DAR,320,240),8) [15:38] <divVerent> vs [15:39] <divVerent> -vf scale=320:240:lbox:round=8 [15:39] <divVerent> also, this is stupid anyway [15:39] <divVerent> real men would use [15:39] <divVerent> -vf scale=DAR 320 240 lboxw 8 round DAR 320 240 lboxh 8 round [15:39] <divVerent> and then wonder... why not... [15:39] <ubitux> you can add another filter [15:39] <ubitux> using the same internals as scale [15:40] <ubitux> with a different syntax [15:40] <ubitux> i don't remember how scale syntax was extended [15:40] <divVerent> -vf scale=8 DAR 320 240 4 dupn lboxw exch round lboxh exch round [15:40] <divVerent> ;) [15:40] <divVerent> it's longer, bit shows you know your RPN ;) [15:40] <ubitux> the current vf scale syntax parsing is quite hacky atm [15:40] <divVerent> yes, especially the comma abuse [15:41] <divVerent> using comma as separators both inside and outside is stupid [15:41] <divVerent> but... I know no better idea [15:41] <ubitux> comma? what comma? [15:41] <divVerent> semicolon is also already a separator in filter chains [15:41] <divVerent> in function args [15:41] <ubitux> oh in the eval [15:41] <divVerent> you actually can't do -vf scale=func(x,y):func(x,y) [15:41] <ubitux> yeah but i wasn't talking about that [15:41] <divVerent> but need -vf "scale=func(x\\,y):func(x\\,y)" [15:41] <ubitux> look at the sws flags parsing [15:41] <divVerent> mplayer has the same issue :P [15:41] <ubitux> or interl=1 thing [15:42] <divVerent> ah, I see [15:42] <ubitux> maybe you can just add another hack like strstr(args,"ratiorules=") [15:42] <divVerent> hehe [15:42] <divVerent> hack-on-hack-on-hack... ;) [15:42] <ubitux> :) [15:43] <divVerent> my favorite solution for -vf scale is still using complex numbers as an alternate interface [15:43] <divVerent> if only one expression is given, real part is w and imaginary part is h ;) [15:43] <ubitux> my favorite solution would be to have it in swscale if the api allows it [15:43] <ubitux> (through sws flags) [15:43] <divVerent> hehe [15:43] <divVerent> swscale that huge mess ;) [15:43] <ubitux> i'm not sure if you can change the specified sizes with sescale [15:43] <divVerent> I recently found lots of nasty bugs/features in swscale [15:43] <ubitux> maybe michaelni can tell [15:44] <divVerent> my favorite one: it loves writing between the image row end and the next row [15:44] <divVerent> i.e. it writes into the stride spacing [15:44] <divVerent> I know why it does that, it makes for faster SIMD code [15:44] <divVerent> and I also know the workaround - make sure your width is 16 bytes aligned [15:44] <divVerent> the main issue is that this fact is nowhere documented [15:45] <divVerent> and at any time, someone could write a SIMD scaler that works in 32 bytes blocks [15:45] <divVerent> ffmpeg.c is MOSTLY unaffected by this issue [15:46] <divVerent> except that when the block size of swscale is raised, there may happen reads beyond allocation which needs slightly larger av_malloc where images are allocated [15:47] <ubitux> did you notice some valgrind issues? [15:47] <divVerent> no [15:48] <divVerent> I had abused libswscale to scale part of an image to part of another image [15:48] <ubitux> then there is no problem ;) [15:48] <divVerent> (convert, actually) [15:48] <divVerent> there is, it does read beyond the stride [15:48] <divVerent> and write [15:48] <divVerent> but NORMALLY this is no issue [15:51] <divVerent> I can produce a valgrind log with a "tightly allocated" image, but the thing is that this is no bug, it's just missing documentation ;) [15:52] <divVerent> it's sensible that libswscale behaves the way it does [15:53] <divVerent> ideally, there should be a macro in swscale.h that defines the alignment libswscale wants, and a comment explaining that writes may happen in blocks of that size [16:40] <ashka> hmm [16:40] <ashka> ^ nevermind that [16:47] <tuxhat> hey [16:48] <tuxhat> can some give me a good idea on codecs for screencasting with ffmpeg [16:48] <tuxhat> someone^ [16:50] <zap0> how do they relate? [17:55] <Spideru> Hi. Is there a way - from ffplay - to see when ffmpeg is streaming an rtp channel? Thank you [18:58] <burek> Spideru, can you rephrase your question please? [18:59] <Spideru> burek: ok, thank you. If i start ffplay (with SDP file) and then connect an rtp stream with ffmpeg, all things works well. Then, if I stop ffmpeg, I can't recognize it from ffplay. How can I do that? [19:00] <Spideru> I need to know from ffmpeg and ffplay If the stream is not working [19:00] <burek> what does this mean: and then connect an rtp stream with ffmpeg [19:01] <burek> can you show some sample command lines? [19:01] <burek> (please use pastebin if commands are too big) [19:01] <Spideru> yes thank you [19:03] <Spideru> burek: http://pastebin.com/eTg9MW1e [19:03] <Spideru> the stream is perfect and finally the patch for SDP generation is up :) [19:04] <Spideru> but I would to know if something stop working [19:04] <burek> Spideru, if I get this right, you are using ffmpeg to feed some unknown rtp server (?) and then you use ffplay to connect to the server? [19:04] <Spideru> I use ffmpeg to feed ffplay server [19:05] <burek> what is ffplay server? [19:05] <Spideru> :| just realized now that I'm using it in wrong way [19:05] <burek> ffplay is just a player [19:05] <burek> your streaming server is located at 192.168.1.95 [19:06] <burek> and ffmpeg is just a stream source [19:06] <Spideru> Well, what can I use to wait and get the ffmpeg stream source? [19:06] <burek> I don't understand :/ [19:07] <Spideru> Ok, I try to explain it better [19:08] <Spideru> I would to transfer audio live stream from a client to a server. What can I use to do that? [19:08] <Spideru> Now I'm using ffmpeg as client, and ffplay as server. But ffplay is not a server [19:09] <Spideru> So, what I should use instead of ffplay? [19:09] <Spideru> and, ffmpeg is the right choice as client side? [19:10] <burek> ffmpeg - as a source [19:10] <burek> ffserver - as a server/broadcaster [19:10] <burek> ffplay/vlc/winamp/... - as a player [19:10] <Spideru> ahh so -> ffmpeg ----> ffserver <---- ffplay ? [19:10] <burek> yes [19:11] <Spideru> \o/ thank you! [19:11] <burek> :) :beer: [19:11] <Spideru> of course [19:11] <Spideru> where are you from? [19:11] <burek> still earth :) [19:11] <burek> serbia :) [19:11] <Spideru> I can offer you a pizza if you'll come to Italy :) [19:12] <burek> I've tried your pizzas and they are good :) [19:12] <Spideru> I know, and my fat too [19:14] <burek> :) [19:17] <Spideru> burek: What kind of protocol should I use? RTP or RTMP? [19:18] <Spideru> I'll prepare two pizzas instead one [19:19] <burek> :) [19:19] <burek> i use ffm between ffmpeg-ffserver and flv between ffserver-media players [19:19] <burek> so its more compatible for streaming [19:23] <Spideru> ffm? Never heard about it before [19:23] <Spideru> of course excluding youporn [19:24] <burek> read a little bit about it [19:25] <Spideru> Yes, I'll read all the doc, of course. [19:26] <Spideru> and thank you [19:26] <Spideru> your help saved me a lot of time [19:28] <burek> you're welcome :) [19:36] <Spideru> 2.7.2 The audio and video lose sync after a while. [19:36] <Spideru> Yes, they do. [19:36] <Spideru> Wonderful [20:31] <wallerdev> does the latest ffmpeg release support apple prores 422 decoding? it seems to give me a black video output [20:59] <wallerdev> built from git head and am seeing the video now, so that's good [21:34] <Jan-> hi [21:35] <Jan-> We need to uncompress an MPEG-2 file (Derived from a DVD) to an uncompressed AVI. We've got usable video (using -vcodec rawvideo), but what would the equivalent be for audio? I assume we just need to specify 16 bit PCM somehow? [21:36] <relaxed> -acodec pcm_s16le [21:36] <relaxed> ffmpeg -codecs | less [21:37] <Jan-> I'm aware of the pcm codecs but I wasn't aware which one was most suitable. [21:37] <Jan-> The There's no documentation other than that they exist. [21:38] <relaxed> signed 16bit little endian is the most common [21:38] <Jan-> hmm [21:39] <Jan-> sound works [21:39] <Jan-> picture less well [21:39] <Jan-> I guess "Rawvideo" just gives us raw 8 bit rgb [21:39] <Jan-> is there something else we might try that a nonlinear editor would deal with better? [21:40] <relaxed> which one are you using? [21:40] <Jan-> premiere [21:40] <Jan-> but it hardly matters [21:40] <Jan-> most of 'em would read an uncompressed AVI... usually. [21:42] Action: Jan- tries v210 [21:43] <Jan-> bingo :) [21:44] <Jan-> it always starts with "error decoding stream #0.1" [21:44] <Jan-> is that bad? [21:44] <relaxed> It can't be good. [21:45] <relaxed> is the exit status 0? [21:46] <Jan-> it didn't exit [21:46] <Jan-> it just said error decoding stream and continued. [21:46] <Jan-> To be fair weirdness is sort of expected, this is a VOB off a dvd. [21:46] <Jan-> the issue is that we need to extract a chunk of it that crosses a VOB boundary, and trying to get a nice clean decode of every single frame each side of the join is tough. [21:47] <relaxed> you could use mplayer's -dumpstream to read the dvd [21:47] <Jan-> wanted to avoid having to do that if possible [21:48] <Jan-> om nom nom all ur disk space r belong 2 mplayer etc [21:48] <Jan-> but I guess we're already having to convert the entire preceding vob. [22:09] <lake> what does -vcoded copy mean? [22:10] <lake> the command in question is this: ffmpeg -i input-file.m2ts -ab 256k -vcodec copy -acodec aac output-file.mp4 [22:10] <tmatth> lake: "vcodec copy" means "use the same video codec in the output as the input" [22:11] <relaxed> copy the video stream [22:11] <lake> tmatth: does that result in loss of quality? [22:11] <llogan> lake: simply put, it means to "copy and paste" the video stream from input to output. it does not re-encode. [22:11] <llogan> no loss o' quality [22:12] <relaxed> cp llogan pasteeater [22:12] <lake> would this result in any loss of quality: ffmpeg -i input-file.m2ts -ab 256k -vcodec x264 -acodec aac output-file.mp4 [22:12] <lake> i assume it would result in a reduced file size [22:13] <llogan> you probably mean "libx264", not "x264" [22:13] <llogan> and yes, it would reduce quality with the default settings. [22:13] <lake> llogan: yes, sorry, just trying to wrap my mind around it [22:14] <llogan> since you are re-encoding to a lossy format..but you may not notice a difference with high enough quality settings/bitrate [22:14] <lake> so, we are talking about transcoding vs compressing then? [22:14] <llogan> of course x264 can encode lossless as well, but it doesn't mean that there will be no loss (such as going from rgb to yuv). [22:15] <lake> sorry, i'm a noob, but finding that ffmpeg is amazing [22:18] <llogan> transcoding refers to re-encoding while using information from the input such as motion vectors. re-encoding means to decode the stream into individual pixels and encode with no additional information from the input [22:18] <llogan> at least that's how i interpret it [22:19] <llogan> most of the time those terms are used as if they are the same process [22:20] <wallerdev> is there a way to specify the library path for libx264 when building from source? [22:20] <wallerdev> seems to be not finding it or using the wrong one [22:24] <llogan> wallerdev: did you try --extra-cflags and --extra-ldflags? [22:25] <wallerdev> no i didnt [22:25] <llogan> some examples here: http://ffmpeg.org/pipermail/ffmpeg-user/2012-August/008552.html [22:26] <wallerdev> would it just be something like --extra-ldflags "-L/usr/local/lib" or somethin [22:26] <llogan> i don't know how "good" those examples are [22:26] <wallerdev> ill check that out thanks [22:26] <relaxed> --extra-cflags="-I/path/to/prefix/include" --extra-ldflags="-L/path/to/prefix/lib" [22:27] <llogan> that's better [22:31] <wallerdev> well hopefully it works, otherwise something is just messed up with my system haha :) [22:32] <llogan> burek, relaxed: interested in making a mini guide on trac wiki on how to make static builds? [22:53] <ubitux> ashka: i don't think i'll submit the patch now, it still has some issues [22:53] <ashka> oh okay [22:53] <ashka> well the workaround is okay for me so it's great [22:54] <ubitux> :) [22:54] <mykul> hi, i have a nub question for you all: how can I use ffmpeg to combine (multiplex) audio files into one [22:55] <llogan> when did noob become nub? nubs seem to outnumber noobs now. [22:56] <mykul> haha [22:56] <mykul> i like the way it sounds, nuhb [22:56] <mykul> nublet [22:59] <mykul> it's&cuter [23:00] <Spideru> burek: how can I tell to ffm (of ffserver) that I don't want video inside feed? [23:00] <llogan> mykul: you mean to simply add several audio streams into one container, or to concat them all into one continuous stream? [23:01] <ubitux> mykul: look at concat, amerge, pan and amix filters [23:01] <ubitux> depending on your needs [23:01] <mykul> llogan, not concat, but have them combined so that they play at once. is that what adding to one container means? [23:02] <mykul> thanks ubitux, i'm drowning in options :D [23:03] <Spideru> Found it thank you [23:05] <llogan> mykul: not exactly what i had in mind. i guess you want "option 3" that i didn't think to list. as ubitux mentioned, see amerge and amix. [23:06] <mykul> cool, thanks llogan, i am armed with some language now. [23:06] <ubitux> https://www.ffmpeg.org/ffmpeg.html#amerge [23:14] <mykul> amix worked great [00:00] --- Thu Oct 11 2012

1 0

ffmpeg-devel.log.20121009
by burek 10 Oct '12

10 Oct '12

[00:00] <ubitux> given a ./ffprobe -f lavfi movie=... -show_frames [00:01] <saste> filter buffer -> avframe [00:01] <saste> what am i missing? [00:02] <ubitux> the lavfi device is a classic format filling AVPackets [00:02] <ubitux> so you av_read_frame() and just get a AVPacket [00:02] <ubitux> how can the tool (in this case ffprobe, but it's the same problem with the other) can get extra info? [00:03] <ubitux> i may be missing something as well :p [00:05] <ubitux> saste: you don't see the problem? [00:06] <ubitux> in the case of a lavfi device, the buffersink is only in the scope of that device/format [00:08] <ubitux> well anyway, the other way would be to make a sink printer like you proposed, with the probe writers :p [00:09] <ubitux> also, there is still side_data :-° [00:13] <saste> well yes lavfi is like a rawvideo demuxer, so can't store metadata info [00:13] <saste> right now only tiff supports that [00:13] <saste> yes side data is a possibility [00:14] <ubitux> what should i put into the side_data? [00:14] <saste> metadata? [00:14] <ubitux> badly worded sorry [00:14] Action: saste don't have a clue about side_data [00:14] <ubitux> how am i supposed to store it? :) [00:14] <ubitux> i guess i can't store a pointer [00:15] <saste> you can copy the textual data [00:15] <ubitux> klv? :p [00:15] <cone-907> ffmpeg.git 3Tim Nicholson 7a02762995bc5: movenc.c: Force correct value for "Samples per packet" for pcm audio * 3http://tinyurl.com/9h85j6l3 [00:15] <saste> but again, that's beyond my current knowledge [00:15] <ubitux> [len][key][len][value] ? :p [00:16] <ubitux> or well, just key\0value\0 should do the trick. [00:16] <ubitux> ok, let's try this. [00:28] Action: beastd is going to sleep [00:28] <beastd> bye... [00:29] <ubitux> i think i'll do the same.. :) [00:29] Action: ubitux & [00:29] <Daemon404> fg [00:33] <ubitux> no :( [01:35] <burek> <nevcairiel> why are some hashes pink? :d [01:35] <burek> you noticed it well :) [01:35] <burek> <cone-907> ffmpeg.git 3Anton Khirnov 7716d413c1398: Replac [01:35] <burek> this should have been [01:36] <burek> <cone-907> ffmpeg.git 3Anton Khirnov 7 716d413c1398: Replac [01:36] <burek> (if you look at the url) [01:36] <burek> the problem is the bot uses mirc color codes [01:36] <burek> ctrl+K+7 [01:36] <burek> and when another digit is added, it becomes ctrl+K+77 [01:39] <burek> just using double digits, like 07, should work [01:40] <burek> btw, who maintains cone-907 ? [02:01] <cone-907> ffmpeg.git 3Carl Eugen Hoyos 7b49d94e4f25e: Support decoding of targa files with 32bit palette. * 3http://tinyurl.com/8qd3zzv3 [02:03] <llogan> burek: it's an irker bot I think. maybe j-b or thresh? [02:05] <burek> oh, ok, they are both here, so they can read the logs [02:59] <RT|AO> so where are the separators in bot's commit log? separating with color doesn't work in plain text logs. [03:14] <Compn> hah, got firefox 15 working on win2k [03:18] <Compn> and most other msvc2010 compiled apps i hope [03:18] Action: Compn flaunts to Daemon404 [03:18] <Compn> :P [03:21] <Compn> only took a bunch of hacked beta winxp dlls :P [03:21] <Compn> a completely unofficial service pack :D [03:36] Action: llogan sees no use for win2k [03:39] <ohsix> it's an operating system :] [03:44] <Compn> it kinda was an os [03:44] <Compn> 12 years ago [03:45] <ohsix> and xp 11 years ago, heh [03:47] <Compn> kinda makes me feel better about win2k :P [03:48] <TheRyuu> that sounds retarded [03:49] <ohsix> differently abled? [03:49] <ohsix> xp is just as obsolete as win2k, i'm still using xp [03:50] <ohsix> there's not much practical consequence [03:50] <ohsix> software that doesn't work on win2k or xp you just wouldn't use, hasn't really happened yet [03:52] <TheRyuu> I was under the impression a lot of stuff doesn't work for 2k [03:52] <TheRyuu> basically everything should work with xp (sp3) though [03:53] <ohsix> about the only thing that may not work is hardware [03:53] <ohsix> and things that use XP, Vista, windows 7 features that define the software (surprisingly almost none of this exists) [03:54] <ohsix> it's always been common practice to dynamically load or detect new features, too; as part of being able to run on different versions of windows, you may get degraded functionality but stuff just failing to start is very unusual [03:54] <ohsix> even the way microsoft distributes runtimes comports with this usage [04:24] <cone-907> ffmpeg.git 3Michael Niedermayer 78da7907a4a89: adpcmenc: switch to av_assert() * 3http://tinyurl.com/8fr4kbx3 [04:24] <cone-907> ffmpeg.git 3Michael Niedermayer 772c2d8a34692: dsputil: convert asserts to av_asserts * 3http://tinyurl.com/8gmeafw3 [05:27] <cone-907> ffmpeg.git 3Michael Niedermayer 7d07940b76d03: motion_est: switch asserts to av_asserts * 3http://tinyurl.com/8kuq7su3 [05:54] <cone-907> ffmpeg.git 3Bobby Bingham 73d9cdfdce76a: targa: use named constants for flag values * 3http://tinyurl.com/8ms9c5y3 [05:54] <cone-907> ffmpeg.git 3Bobby Bingham 7c2eec3df8996: targa: support 2-way and 4-way interleaved files * 3http://tinyurl.com/952gzr83 [05:54] <cone-907> ffmpeg.git 3Bobby Bingham 750787fe350c2: targa: remove unused context members * 3http://tinyurl.com/9qgs3jg3 [05:54] <cone-907> ffmpeg.git 3Bobby Bingham 7b56f94cc363c: targa: cosmetics - add some whitespace * 3http://tinyurl.com/9777r6m3 [06:19] <cone-907> ffmpeg.git 3Michael Niedermayer 7e73bac484f71: configure: add support to nicely enable ftrapv * 3http://tinyurl.com/9xvwzfc3 [06:19] <cone-907> ffmpeg.git 3Michael Niedermayer 703f5043f5d13: eval: Fix eval test with ftrapv * 3http://tinyurl.com/8j5u6sl3 [06:19] <cone-907> ffmpeg.git 3Michael Niedermayer 71e83e6ad7a8b: ra144: fix code with ftrapv. * 3http://tinyurl.com/8nfcnkg3 [06:34] <koorogi> Who do I talk to about being able to close tickets I've fixed? [07:17] <thresh> burek: it is a bug in irker, was fixed this night [09:53] <burek> thresh great :) [10:07] <ubitux> huh, is AVFrame->metadata unused at the moment? [10:09] <durandal_1707> it should be used by GeoTIFF [10:11] <ubitux> ah right, indeed [10:11] <ubitux> thx [10:12] <durandal_1707> also png could make use of it... [10:15] <cone-932> ffmpeg.git 3Carl Eugen Hoyos 761a9f099b7da: Write 32bit palette to Targa files. * 3http://tinyurl.com/8crp2et3 [10:32] <durandal_1707> hmm, why fate reports memory leak for tak that have single key in ape2 tags? [10:35] <ubitux> durandal_1707: -f s16le -f crc - [10:35] <ubitux> -f re-dup [10:35] <durandal_1707> ? [10:35] <ubitux> in the fate test [10:35] <ubitux> remove -f s16le [10:36] <ubitux> it will fix the leak [10:36] <durandal_1707> but other tests had it too [10:36] <ubitux> i don't think so [10:38] <durandal_1707> fate-lossless-monkeysaudio: CMD = md5 -i $(SAMPLES)/lossless-audio/luckynight-partial.ape -f s16le [10:39] <ubitux> md5 [10:39] <ubitux> ` crc [10:39] <ubitux> md5 doesn't add a -f md5 or something [10:40] <ubitux> crc will add a -f crc [10:40] <ubitux> and then, format=av_strdup("s16le"); [...] format=av_strdup("crc") [10:41] <durandal_1707> leak should not happen [10:41] <ubitux> see the av_freep() commented in the appropriate place [10:41] <ubitux> michael removed it because it was causing problems [10:42] <ubitux> durandal_1707: see a1bcc76e6036e78f25cbb7323c145056cfca9d93 [10:42] <ubitux> but it was reverted [10:43] <ubitux> durandal_1707: the leak should not happen, but the -f should not appear two times in the fate test anyway [10:43] <ubitux> you can remove the -f s16le, it doesn't affect your test [10:44] <ubitux> related: 6a0dfe3b9dc6b9420b25bfd089c655583cf045d6 [10:51] <cone-932> ffmpeg.git 3Paul B Mahol 73a2d3df0e02d: fate-lossless-tak: remove unneeded -f s16le * 3http://tinyurl.com/9rzldn63 [10:53] <thresh> I've updated the irker instance on videolan git, the colors should be fixed now :) [11:02] <xxthink> how to profile ffmpeg? [11:02] <xxthink> there are no configure options now [11:02] <cone-932> ffmpeg.git 03Paul B Mahol 07238e904df398: DTS-HD demuxer * 03http://tinyurl.com/9xfmf4k03 [11:02] <burek> it works good now thresh :) [11:03] Action: ubitux still doesn't like tinyurl :( [11:04] <j-b> this SUXX [11:04] <thresh> what [11:10] <j-b> What is a DTSHD demuxer ? a demuxer for .dtshd files? How is that different from .dts? samples? [11:11] <durandal_1707> j-b: you do not have samples for .dtshd ? [11:12] <j-b> durandal_1707: unmuxed? no. [11:13] <durandal_1707> what? [11:13] <durandal_1707> you have files with dtshd extension or not? [11:13] <ubitux> xxthink: mmh, valgrind/cachegrind, START_TIMER, ... ? [11:14] <ubitux> callgrind* [11:14] <xxthink> ok [11:14] <j-b> durandal_1707: no. [11:14] <xxthink> ubitux: I use oprofile [11:14] <xxthink> add the -pg options to the CFLAGS [11:15] <ubitux> if it makes sense, maybe add a --enable-oprofile :p [11:19] <durandal_1707> j-b: http://dotwhat.net/dtshd/10632/ [11:24] <av500> j-b: I read on internet your vlc is borken [11:27] <j-b> av500: how is it? [11:27] <burek> ubitux, there could be a simple redirect, created within .htaccess on videolan that would translate all these: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=61a9f099b7da38722f758db38d… into something shorter like this: http://url.videolan.org/ffmpeg/61a9f099b7da [11:28] <burek> that way you'd avoid tinyurl or any other external dependency [11:28] <av500> j-b: that avengers dvd or sp [11:28] <av500> so [11:28] <j-b> av500: indeed. ARCCOS DRM [11:28] <ubitux> burek: if you trim the hash to 7 char it's short enough [11:29] <burek> I just followed cone's output :) [11:29] <burek> but ok, even better with 7 chars only [11:37] <j-b> durandal_1707: that does not answer the question. [11:37] <j-b> ubitux: burek: I tried to register v.lc domain... I failed [11:38] <ubitux> :( [11:38] <ubitux> what about g.it? [11:45] <burek> j-b, v.lc is already taken, but the owner is: Nic LC Admin [11:45] <burek> so you might ask for just a DNS A record maybe [11:45] <j-b> burek: nic is the registar of .lc [11:45] <burek> yes i know [11:46] <j-b> I asked them :) [11:46] <burek> :) [11:46] <j-b> they told me: "do a correct business proposal" [11:47] <durandal_1707> j-b: http://www.atsc.org/cms/index.php/standards/standards/296-a1032012-non-real… [11:50] <burek> j-b how about videol.an [11:51] <j-b> .an exists? [11:51] <ubitux> batman ananananaan [11:51] <burek> http://www.controloye.com/whois/an.php [11:51] <av500> j-b: yes [11:51] <burek> anyway domain whois shows it's not been taken [11:51] <j-b> ok, that's because our name registar does not [11:52] <durandal_1707> video.xxx [11:52] <av500> +1 [11:52] <av500> hotvlc.xxx [11:53] <j-b> probably already taken [11:53] <av500> bringing you the best of variable length coding... [11:53] <ubitux> Le domaine videol.an existe déjà, et ne peut pas être créé. [11:53] <ubitux> according to ovh [11:53] <j-b> getv.lc [11:54] <av500> j.bk [11:55] <j-b> unlikely [11:55] <j-b> if I cannot get v.lc with a popular software, I doubt I can get a single-letter domain for me [11:56] <durandal_1707> what is correct business proposal? [11:57] <j-b> that is a good question [11:57] <j-b> but > 10k probably [11:57] <durandal_1707> per year? [11:58] <j-b> per acquisition, I guess [12:31] <burek> btw, ffmp.eg is free if there is an interest for such thing.. http://lookup.egregistry.eg/english.aspx [12:35] <av500> people dont remember domain names anyway [12:35] <av500> they google "yahoo" [12:35] <av500> I stopped typing domains long ago [12:35] <av500> I just mash a few matching letters into el goog [12:35] <av500> fmfge : [12:35] <av500> :) [12:44] <divVerent> ffmpeg's -vf scale is great [12:44] <divVerent> expression evaluator... [12:57] <durandal_1707> what extensions libdca have? [13:10] <cone-932> ffmpeg.git 03Janne Grunau 07ea14a655f7b8: avutil: skip old_pix_fmts.h since it is just a list * 03http://tinyurl.com/8qgjj4p03 [13:10] <cone-932> ffmpeg.git 03Mans Rullgard 0727a310e3813c: doc: allow building with old texi2html versions * 03http://tinyurl.com/8uq22tk03 [13:10] <cone-932> ffmpeg.git 03Martin Storsjö 0766d652cbf38e: rtpdec_vp8: Make the depacketizer implement the latest spec draft * 03http://tinyurl.com/95rahqn03 [13:10] <cone-932> ffmpeg.git 03Martin Storsjö 07c9b10cc4dbb6: rtpenc_vp8: Update the packetizer to the latest spec version * 03http://tinyurl.com/9fmn3hs03 [13:10] <cone-932> ffmpeg.git 03Mans Rullgard 078f23907f3e4c: build: add -Mdse to PGI optimisation flags * 03http://tinyurl.com/8m3jbsq03 [13:10] <cone-932> ffmpeg.git 03Mans Rullgard 07643933f51d1c: build: add LTO support for PGI compiler * 03http://tinyurl.com/8cf975t03 [13:10] <cone-932> ffmpeg.git 03Mans Rullgard 07f79364b2c30a: ppc: fix Altivec build with old compilers * 03http://tinyurl.com/9javb5w03 [13:10] <cone-932> ffmpeg.git 03Yusuke Nakamura 07e04826c34e9b: file: Set the return value type for lseek to int64_t. * 03http://tinyurl.com/93ycxaz03 [13:10] <cone-932> ffmpeg.git 03Martin Storsjö 07c136a813d77e: rtp: Support packetization/depacketization of opus * 03http://tinyurl.com/9zza5m303 [13:10] <cone-932> ffmpeg.git 03Diego Biurrun 07f75f4194d1ea: Restructure av_log_missing_feature message * 03http://tinyurl.com/8n8kxn303 [13:10] <cone-932> ffmpeg.git 03Diego Biurrun 07a75b9a180476: mingw/cygwin: Stop adding -fno-common to gcc CFLAGS * 03http://tinyurl.com/8zhwlsp03 [13:11] <cone-932> ffmpeg.git 03Michael Niedermayer 07ef9fe5bedd19: Merge remote-tracking branch 'qatar/master' * 03http://tinyurl.com/8casapo03 [14:09] <maker> FYI: Firefox 15 signals https://ffmpeg.org as insecure [16:29] <burek> <maker> FYI: Firefox 15 signals https://ffmpeg.org as insecure [16:29] <burek> https://support.google.com/chrome/bin/answer.py?hl=en&answer=95617&p=ui_sec… [16:29] <burek> it shows me: The site uses SSL, but Google Chrome has detected insecure content on the page. [16:30] <burek> which means there are some src="http://..." content inside html [16:30] <burek> i.e. not all content is from https://ffmpeg.org [16:31] <burek> for example this image http://americancensorship.org/images/stop-censorship-small.png is included above the text "FFmpeg supports the fight against American Internet censorship." [16:31] <burek> and that's considered an insecure content [16:40] <maker> burek: ah uh [16:55] <cone-932> ffmpeg.git 03Anuj Mittal 07ce19aec15b42: Check resync marker only when enabled. * 03http://tinyurl.com/8p5bgkx03 [16:55] <cone-932> ffmpeg.git 03Anuj Mittal 078d2e0e2c7058: Check for resync marker based on vop coding type- vop_fcode_forward and vop_fcode_backward L * 03http://tinyurl.com/9j5k3bz03 [17:18] <ubitux> saste: any reason you're not storing the the g_XX as bitfields? [17:19] <saste> ubitux: i just ported the original code [17:19] <saste> i didn't feel like i wanted to process the table with an hand-written program [17:20] <saste> ah you say to change uint8_t with uint8_t:1? [17:20] <saste> yes that's possible [17:20] <saste> what I'm mostly concerned is the integer implementation, which is rather tricky [17:20] <saste> *concerned with [17:21] <ubitux> i don't think you can do a uint8_t:1 [17:21] <ubitux> you'll need to change the code :p [17:21] <saste> whatever syntax it is [17:21] <ubitux> i don't think the syntax will allow it in this context [17:22] <saste> anyway reply by email or i'll discard it in the next iteration (which may well be after a few months) [17:22] <ubitux> i was just asking a random question :) [17:22] <cone-932> ffmpeg.git 03KO Myung-Hun 073a45688abc5c: lavc: include os2threads.h in vp8.h if HAVE_OS2THREADS is enabled * 03http://tinyurl.com/9yv3bxu03 [17:22] <cone-932> ffmpeg.git 03Andrey Utkin 07d2b18c8f5b08: Introduce ff_network_wait_fd_timeout() * 03http://tinyurl.com/9ncesq503 [17:22] <cone-932> ffmpeg.git 03Andrey Utkin 07949acefc11b4: tcp: use timeout option consistently * 03http://tinyurl.com/9ma2ojv03 [17:23] <ubitux> saste: anyway, please at least commit the '-' thing for the help output :( [17:40] <saste> ubitux, i wonder if it is a good idea after all... [17:40] <ubitux> why? [17:40] <ubitux> i'm talking about removing it only for the filters, right? [17:40] <saste> the output looks less structured [17:41] <saste> no you can't do that only for filters [17:41] <saste> all or nothing [17:41] <ubitux> mmh. [17:42] <saste> some reindentation may help [17:42] <saste> but that's kinda subjective, also that would need some changes in opt.c code [17:42] <ubitux> that was one of the other patch [17:42] <ubitux> i would personally add 2 spaces index [17:42] <ubitux> indent* [17:43] <ubitux> (and more padding for the other options btw) [17:44] <saste> what about XML output? [17:45] <saste> uhm no i never reindented [18:26] <cone-932> ffmpeg.git 03Andrey Utkin 072e009c6042bd: tcp: accept params through avio_open2() options * 03http://tinyurl.com/95zg2bo03 [18:26] <cone-932> ffmpeg.git 03Andrey Utkin 07b6f435fbc87c: http: add 'timeout' AVOption * 03http://tinyurl.com/9k4fwu703 [20:12] <michaelni> if someone wants to setup a ffmpeg IOC fate box, it seems there are now also binaries on the IOC page (http://embed.cs.utah.edu/ioc/) [20:33] <Compn> michaelni : guess its good that ffmpeg supports clang :) [20:33] <Compn> ehe [20:33] <Compn> since ioc is based on clang [20:46] <Daemon404> libav has had an ioc fate instance for ages [20:46] <Daemon404> should be trivial to set up [20:47] <Daemon404> on another note [20:47] Action: Daemon404 still waiting for baptiste [20:48] <nevcairiel> he answered the same day for me when i setup mine [20:48] <nevcairiel> you must've hit him at a bad time =p [20:58] <burek> one question, what does 'start' represent in input's info: Duration: 00:07:35.04, start: 0.481967, bitrate: 23837 kb/s [20:58] <burek> or this, if more convenient: http://pastie.org/5025652 [21:45] <burek> it seems that -map option is broken [21:46] <burek> http://pastie.org/5025843 [21:46] <burek> http://pastie.org/5025918 [21:51] <michaelni> burek, is that a -map O or -map 0 ? [21:53] <michaelni> btw, if the 2 l00k the same t0 y0u then y0u maybe sh0uld try an0ther f0nt [21:53] <burek> geez .. he typed letter 'O' [21:53] <burek> thanks :D [22:20] <ubitux> - [X264_LOG_INFO] = AV_LOG_INFO, [22:20] <ubitux> + [X264_LOG_INFO] = AV_LOG_VERBOSE, [22:20] <ubitux> hehe [22:20] <cone-932> ffmpeg.git 03Duncan Salerno 07bd2f8e8f79e9: Fix second use of AVOptions in HLS * 03http://tinyurl.com/9oy5s9903 [22:20] <ubitux> reminds me something :)) [22:27] <nevcairiel> INFO = INFO, i fail to see why everyone wants to change it =p [22:27] <ubitux> :) [22:31] <cone-932> ffmpeg.git 03Clément BSsch 076ac5e3fe9d92: lavfi/silencedetect: add av_opt_free() call. * 03http://tinyurl.com/8bfsj4w03 [22:41] <Daemon404> nevcairiel, inorite [22:41] <Daemon404> because it offends them or something [22:41] <Daemon404> how DARE a lib have its own output [22:42] <ubitux> TAG:lavfi.silence_start=3.40735 [22:42] <ubitux> yay. [22:43] <Daemon404> >_> [22:43] <Daemon404> outputting via tags... [22:43] <Daemon404> really? [22:44] <ubitux> ? [22:45] <ubitux> lavfi will use the metadata for communication [22:45] <Daemon404> i see [22:45] <ubitux> at the end of the chain ffprobe is able to dump them :) [22:45] <Daemon404> thats seems majorly bad for anything with lots [22:45] <Daemon404> like, i was thinking, scene change info [22:45] <ubitux> so you get the xml/json/etc benefits [22:45] <Daemon404> this will be really ugly... [22:45] <ubitux> Daemon404: yes that's what i was planing to do [22:45] <ubitux> (see my mail) [22:45] <ubitux> very easy to do now that i did the hard part [22:57] <cone-932> ffmpeg.git 03Duncan Salerno 07f3f35f7430f1: crypto should allow passing of options to the underlying protocol via the url_open2 interface * 03http://tinyurl.com/9m3hngr03 [00:00] --- Wed Oct 10 2012

1 0

ffmpeg.log.20121009
by burek 10 Oct '12

10 Oct '12

[01:10] <zule> can anyone tell me why when creating a mp4 from a set of jpg's everything works fine until I specify a frame rate of 5 (-r 5) at which point is only encodes a small percentage of the available frames... [01:52] <aleray> hi, is it possible to get metadata from a byte range? [01:57] <aleray> to get the metadata of an online og resource i meant [02:07] <burek> ? [05:54] <Sashmo> can anyone help me out? trying to compile on mac http://pastebin.com/z7myyHCs [06:10] <grepper> sashmo: perhaps wrong version of texi2html ? [06:12] <Sashmo> Im trying again [06:16] <grepper> sashmo: guess you could always --disable-doc as a last resort [06:16] <Sashmo> good idea [06:17] <Sashmo> what is texi2html? [06:18] <grepper> documentation system [06:19] <grepper> "info ffmpeg" for example [06:20] <Sashmo> or man ffmpeg? [06:23] <grepper> well, I guess "2html" is a clue. I was speaking in general about Texinfo [07:00] <Sashmo> can anyone point me to some tutorial for using ffmpeg and a webcam on mac? [07:25] <grepper> dunno, on linux you would use /dev/video0 or similar [08:31] <newenc> how to i create multi-channel wav from separate tracks? [08:41] <klaxa> newenc: i'm not sure if ffmpeg supports it, but sox does, maybe try that out [08:44] <newenc> I've been playing with sox for the past hour but I'm not getting very far [08:46] <zap0> you might progress to shoes one day.. [08:50] <klaxa> if nothing works and you have a gui, you could try out audacity [09:24] <newenc> @zap0 touche [09:25] <newenc> well heres the deal [09:26] <newenc> i have a bunch of prores files with 7 audio tracks. 1-6 are mono 5.1 and 7-8 are a stereo pair. [09:27] <newenc> i want to take all 8ch and mix them into one 8ch track [09:28] <newenc> and so far this kind of seems to work http://pastebin.com/HE5Jega7 [09:30] <newenc> so far so good. [09:34] <newenc> the audio is all there in only one track. [10:05] <brontosaurusrex> is there a deinterlacer that works directly with 4:2:2 material in ffmpeg? [10:06] <brontosaurusrex> yadif is craping out [10:06] <brontosaurusrex> aliasing [10:21] <divVerent> Hi... I need some small help using ffprobe [10:21] <divVerent> how to get XML output? [10:21] <divVerent> https://gist.github.com/3857325 - I tried ffprobe -print_format xml and failed horribly [10:22] <ubitux> divVerent: -show_format, -show_streams, etc [10:22] <ubitux> -v 0 is your friend too [10:22] <divVerent> ah, thanks [10:23] <divVerent> manpage a bit non-obvious, but good help here ;) [10:24] <divVerent> now wondering which of the formats is best to use with shell or perl scripts... ;) [10:24] <ubitux> flat [10:24] <ubitux> with sep=_ + eval [10:24] <divVerent> well, eval probably is bad due to evil characters possibly somewhere [10:25] <ubitux> it's escaped [10:25] <ubitux> hopefully correctly [10:25] <divVerent> codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [10:25] <divVerent> that is sure not correctly escaped ;) [10:25] <ubitux> ffprobe -of flat=s=_ ? [10:25] <divVerent> [rpolzer@nb-04 ~]$ codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [10:25] <divVerent> bash: /: Is a directory [10:25] <divVerent> oh, it doesn't have the flat option [10:25] <divVerent> I thought you meant default [10:26] <divVerent> okay, looks like I need to compile a current build then ;) [10:26] <ubitux> 1.0 should have it [10:26] <divVerent> okay, know what to do then [10:27] <divVerent> system upgrade, and if it's still a 0.11 one, click the nice trolly "Mark outdated" button ;) [10:27] <ubitux> :) [10:28] <divVerent> yes, they have newer ffmpeg [10:28] <divVerent> ah, flat format looks indeed somewhat shell compatible [10:28] <divVerent> in case I find issues, is the escaping "supposed" to be shell compatible? [10:28] <divVerent> or is that just a coincidence [10:28] <ubitux> it's supposed to be shell compatible [10:28] <divVerent> but it still uses dots by default as sep ;) [10:28] <divVerent> but nice, that's the smallest issue one can have [10:29] <divVerent> haha, I actually see a small bug already ;) [10:29] <divVerent> streams.stream.8.index=8 [10:29] <divVerent> ... [10:29] <divVerent> streams.stream.tags.filename="mriam.ttf" [10:29] <divVerent> streams.stream.tags.mimetype="application/x-truetype-font" [10:29] <divVerent> the .8. is missing [10:29] <ubitux> 10:25:46 <@ubitux> ffprobe -of flat=s=_ ? [10:29] <ubitux> use flat=s=_ [10:30] <divVerent> streams_stream_8_nb_read_packets="N/A" [10:30] <divVerent> streams_stream_tags_filename="mriam.ttf" [10:30] <divVerent> same issue [10:30] <ubitux> i don't have that problem with git/head [10:30] <ubitux> maybe it was fixed by saste [10:30] <divVerent> ah, ok then [10:30] <divVerent> right :) [10:30] <ubitux> streams_stream_2_disposition_attached_pic=0 [10:30] <ubitux> streams_stream_2_tags_creation_time="2008-05-27 18:40:35" [10:30] <ubitux> streams_stream_2_tags_language="eng" [10:30] <ubitux> streams_stream_2_tags_handler_name="Apple Alias Data Handler" [10:30] <divVerent> I of course could work around this from my code... but not sure if worth it [10:30] <divVerent> if I can just compile from git [10:32] <divVerent> while I am waiting for the compile... is there a way to find the number of streams from the output? [10:32] <saste> divVerent, -show_format tells the number of streams [10:32] <divVerent> ah, ok [10:32] <divVerent> just asking because there MAY be already a variable streams_stream_N_whatever in the shell ;) [10:33] <divVerent> yes, it's me and my weird corner cases that never happen anyway again ;) [10:33] <ubitux> divVerent: if you have issues with the escaping please raise them [10:33] <ubitux> it might even depends on the shell [10:33] <ubitux> here are the two functions FYI: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffprobe.c;h=2187ce2652a9cae5… [10:35] <divVerent> looks MOSTLY good to me... except for some smaller suggestions [10:35] <divVerent> it is probably better to use single quotes, as then only \ and ' need escaping at all [10:36] <divVerent> \ to '\\' and ' to '\'' [10:36] <divVerent> also, this \n and \r escape doesn't work, but you probably know that [10:36] <divVerent> shells don't interpret these in double quoted strings [10:36] <divVerent> but none of these cause actual breakage, and changing newlines and carriage returns to \n and \r anyway may actually be for the better [10:37] <divVerent> e.g. so one can grep the output for a prefix easily before using it [10:37] <ubitux> mmh [10:38] <ubitux> iirc ' escaping is a bit special with some shells :( [10:38] <ubitux> divVerent: if you have a failing string in mind... [10:38] <ubitux> for the \n i wanted to avoid multilines [10:40] <divVerent> right [10:41] <divVerent> no, I see nothing failing [10:41] <divVerent> I don't care for csh, though ;) [10:41] <divVerent> but for posix shells, this is all right except for the \n/\r, and these two are harmless [10:46] <divVerent> how to use -dump_attachment? [10:47] <divVerent> I tried -dump_attachment:0:3 filename.ttf -i filename.mkv [10:47] <divVerent> this does extract it, but complains at the end with "At least one output file must be specified" [10:48] <divVerent> i.e. the extraction works fine, but I want exit status 0 ;) [10:49] <ubitux> mmh [10:49] <ubitux> looks like a bug [10:49] <divVerent> hm... from the source of 0.11.2 I have lying around here, nb_output_files really has to be > 0 [10:51] <divVerent> -f null -frames 0 /dev/null kind of works around ;) [10:52] <ubitux> haha :) [10:52] <ubitux> divVerent: care to open an issue? [10:52] <divVerent> sure, if this is a bug, that is [10:53] <ubitux> i believe so, doesn't look correct [10:53] <divVerent> I see why it does this, and I see no good way to fix it... but e.g. sox has a workaround for this kind of thing [10:53] <divVerent> it has a -n option which means "no output" [10:53] <divVerent> if you e.g. just want to run analysis on a file [10:54] <divVerent> my goal BTW is to try to implement automatic language based stream selection, extracting fonts, coercing fontconfig, then trying to use -vf ass [10:54] <divVerent> from a frontend script [10:54] <divVerent> I am unsure about the coercing fontconfig part though ;) [10:55] <divVerent> I now have the stream ID -> language mapping working, and the font extraction too [10:55] <divVerent> hehe, srt2ass already has been written too :P [10:56] <ubitux> ffmpeg -i in.srt out.ass ? [10:56] <divVerent> haha, really? [10:56] <ubitux> sure. [10:56] <divVerent> that's even neater... [10:56] <divVerent> especially given I need to extract the subtitle script anyway [10:56] <divVerent> so I can just select the subtitle stream, and let it write to the ass file [10:56] <ubitux> ffmpeg -i in.mkv out.ass ? :p [10:56] <divVerent> exactly [10:56] <divVerent> apart from selecting the stream still ;) [10:57] <ubitux> :) [10:57] <divVerent> which is easy, as I already have the data in a variable [10:57] <divVerent> what will be harder is making the selection a bit more clever [10:57] <divVerent> especially, cleverer than mplayer's [10:57] <divVerent> which e.g. tends to lead to viewing english with english subs ;) [10:57] <ubitux> mplayer's selection is kind of nice afaict [10:58] <divVerent> an annoyance not really fixable without a scripting facility [10:58] <divVerent> it is [10:58] <divVerent> and fixing this is not really easy there [10:58] <divVerent> what I want is something like "try jpn/eng; if it failed, try eng/-" [10:59] <divVerent> but doing such things just doesn't fit into mplayer's option syntax, or in fact, any option syntax I have ever seen+ [10:59] <divVerent> this is more like a job for some kind of control file [10:59] <ubitux> you should look at honoring disposition/default as well btw :) [10:59] <divVerent> how is that set exactly? [11:00] <ubitux> libavformat/matroskadec.c: st->disposition |= AV_DISPOSITION_DEFAULT; [11:00] <divVerent> no, I mean [11:00] <divVerent> what is it used for [11:00] <divVerent> is this for the english subs that are only meant to replace e.g. signs [11:00] <divVerent> but not dialogue? [11:00] <ubitux> if the stream is the default or no so... [11:00] <divVerent> I wanna decide the default, not the author of the file ;) [11:01] <ubitux> if you have two audio streams and the second has default bit, then it should be selected by default :p [11:01] <divVerent> no ;) [11:01] <divVerent> the one which I understand should [11:01] <divVerent> but I see, if multiple matches remain, these should be preferred [11:01] <divVerent> so this is useful e.g. for different audio encodings of the same language [11:01] <divVerent> to pick the "better" one [11:01] <ubitux> i was talking about the case where you have no preferences obviously [11:01] <ubitux> (like when doing the default picking stream) [11:02] <divVerent> sure [11:02] <divVerent> I will keep that in mind when writing my script [11:02] <ubitux> and yeah it could influence the selection with preferences [11:02] <ubitux> in case of equality, like you said [11:03] <divVerent> there is more disposition flags though... [11:03] <ubitux> :) [11:03] <divVerent> is there a spec? ;) [11:03] <ubitux> avformat.h? :) [11:04] <divVerent> nope.avi [11:04] <divVerent> that just tells me their bitmask values [11:04] <divVerent> for some of them, that is [11:04] <divVerent> I am mainly interested about what "disposition/dub" is [11:05] <divVerent> and "original" [11:06] <ubitux> i can't tell :) [11:56] <KING_LEE> hello again [11:57] <KING_LEE> i had a problem with MTS files yesterday [11:57] <KING_LEE> i solved that now but i now noticed that the recoded clips i get are all shortened by a second [12:01] <KING_LEE> http://pastie.org/5023383 [12:01] <KING_LEE> this i my script [12:01] <KING_LEE> http://pastie.org/5023386 [12:03] <KING_LEE> i gave cinelerra and ffmpeg a fresh install and it worked then, i have this script from the cinelerra mailing list and added the deinterlaceing [12:11] <burek> KING_LEE, http://stackoverflow.com/questions/965053/extract-filename-and-extension-in… [12:13] <burek> also "-deinterlace is deprecated, use -filter:v yadif instead" [12:13] <burek> http://ffmpeg.org/ffmpeg.html#yadif [12:16] <KING_LEE> i testes i few clips and i dont really see a difference but the duration is always shortened by 1 sec [12:17] <burek> you might run your ffmpeg with -debug_ts [12:17] <burek> to see if all the frames are being processed [12:17] <KING_LEE> and that shortens the clips? [12:19] <KING_LEE> oh, its even more in that longer clip [12:20] <KING_LEE> burek: my battery runs out, can i get back to you tonight? [12:20] <burek> ping me, and if im online ill answer [12:20] <KING_LEE> thanks man [12:21] <xxthink> can ffmpeg generate mkv format files? [12:22] <burek> xxthink it should [12:22] <burek> ffmpeg -formats [12:22] <burek> E matroska Matroska file format [12:26] <xxthink> ok [12:26] <xxthink> I use -f mkv, [12:26] <xxthink> it should be -f matroska [12:26] <burek> -f matroska [12:26] <xxthink> yes [12:47] <kakohari> Hi all [12:47] <kakohari> bcoudurier: did you receive my email? [12:53] <divVerent> which of the aac encoding libraries is recommended? [12:54] <divVerent> if I see it right, possibly good chances have libfdk-aacenc and libvo-aacenc, but which is better? ;) [12:55] <JEEBsv> fdk [12:55] <divVerent> ok, thanks [12:55] <JEEBsv> vo-aacenc is barely ffaac level IIRC :< [12:55] <divVerent> ah, good to know [12:55] <JEEBsv> and fdk is the "fast" fraunhofer encoder [12:55] <JEEBsv> <3 [12:55] <divVerent> and does fdk-aac have to be current git or is 0.1.0-1 good too? [12:56] <JEEBsv> it should be in that release too, methinks (if that's the "1.0" release) [12:58] <divVerent> and how does libfdk-aac compare to neroAacEnc? [12:58] <divVerent> (asking while compiling it) [12:58] <JEEBsv> should be similar or better [12:59] <burek> divVerent recommend for what exactly [12:59] <divVerent> burek: listening to sound of videos with crappy headphones ;) [12:59] <burek> ed* [12:59] <JEEBsv> the only negative point of fdk is that it's not GPL-compliant atm [12:59] <JEEBsv> :< [12:59] <burek> for that you can use wav too [12:59] <divVerent> previously I was using the aac or libfaac codecs for that, but these are both crap [12:59] <JEEBsv> but not like nero is [12:59] <JEEBsv> and not like faac is :D [12:59] <divVerent> sure [12:59] <JEEBsv> yeah, faac is derp, too by now [12:59] <divVerent> I know I am creating an illegal ffmpeg binary [12:59] <divVerent> sue me ;) [12:59] <JEEBsv> nah, only illegal to distro [13:00] <JEEBsv> IIRC [13:00] <divVerent> sure [13:00] <JEEBsv> and only if it's GPL [13:00] <divVerent> is it then BTW also illegal to e.g. back up my notebook to an external HDD? ;) [13:00] <JEEBsv> lol [13:00] <divVerent> sure I am linking in some GPL stuff [13:00] <JEEBsv> dunno, don't care [13:00] <divVerent> but I consider it equally evil as the nvidia driver [13:00] <JEEBsv> I wish fdk would've not written their own license [13:00] <divVerent> except that it actually has SOME source [13:01] <JEEBsv> I actually wonder how the fdk's license works within the Android framework [13:01] <divVerent> also, anything is better than "aac" ;) [13:01] <JEEBsv> vo-aacenc is close to that [13:01] <JEEBsv> afaik [13:01] <burek> better in what? [13:01] <JEEBsv> some japanese guy tested [13:01] <divVerent> burek: "aac" codec in ffmpeg is REALLY broken [13:01] <divVerent> even does clipping [13:01] <burek> recommended/better is usually used with some criteria [13:01] <divVerent> it also is way below LAME for mp3... [13:01] <divVerent> at same bitrate [13:01] <JEEBsv> yes, LAME is actually pretty good [13:01] <JEEBsv> encoder-wise [13:01] <burek> what are your goals [13:01] <divVerent> and being at least as good as LAME/mp3 is something I'd really expect of an aac codec [13:02] <JEEBsv> while ffaac is well... something that semi-works [13:02] <divVerent> burek: no audiophile stuff though [13:02] <divVerent> just getting videos to work at all on the iCrap [13:02] <divVerent> for that it has to be aac [13:02] <burek> my point is that each of those codecs have something they are good at [13:02] <divVerent> yes, faac seems to be not buggy [13:02] <divVerent> but also below LAME level [13:02] <JEEBsv> yeah [13:02] <burek> so, it depends what exactly do you need [13:02] <JEEBsv> faac is one of the LC-AAC reference implementations [13:02] <JEEBsv> (with a small wrapper IIRC) [13:03] <divVerent> why is it so bad then? ;) [13:03] <divVerent> it should beat LAME then [13:03] <burek> if by the "level" you refer to a perceived audio quality, then try libaacplus [13:03] <JEEBsv> burek: fdk has HE-AAC as well [13:03] <burek> at the same rate you would usually use aac [13:03] <JEEBsv> so derp [13:03] <burek> JEEBsv, we already covered that topic [13:03] <divVerent> burek: sure, I always used 128k though [13:03] <JEEBsv> did we? [13:03] <divVerent> as that makes "aac" bearable and "libfaac" somewhat good [13:03] <burek> it doesn't correctly produce HE-AAC v2 [13:03] <burek> aka aac+ [13:03] <JEEBsv> is it incorrect or just uses more features? [13:04] <JEEBsv> I don't think anyone got an opinion from a person that has read the AAC spec [13:04] <burek> well, I don't know, but it's not comparable to libaacplus [13:04] <burek> if it doesn't produce aac+ [13:04] <JEEBsv> well, it does [13:04] <JEEBsv> it does have problems with QuickTime tho it seems [13:04] <JEEBsv> V: [13:04] <burek> whatever [13:04] <burek> divVerent if you like, try libaacplus at -ab 48k [13:04] <burek> and see the results [13:05] Action: JEEBsv sighs [13:05] <burek> also, compare to whatever mp3s you have [13:05] <JEEBsv> divVerent: vo-aacenc and faac are the two reference implementations lol [13:05] <JEEBsv> they're both relatively bad [13:05] <JEEBsv> to terribad [13:05] <divVerent> 13:04:35 JEEBsv | it does have problems with QuickTime tho it seems [13:05] <divVerent> ah, that means it's out ;) [13:06] <divVerent> because one doesn't simply install another player on the iPhone [13:06] <divVerent> (or rather, they all are either slow or based on Quicktime...) [13:06] <JEEBsv> dunno if the hardware decoder fails [13:06] <JEEBsv> just quicktime fails with its he-aacv2 output. he-aac seems to work [13:06] <divVerent> thing is, an app can only access the HW decoder through quicktime [13:06] <divVerent> sandbox madness... [13:07] <JEEBsv> well, I'm not sure if anyone has tested it on the actual portable stuff [13:07] <divVerent> and I've never seen an app that decodes video on HW and audio separately (with other formats supported) [13:07] <divVerent> it may be quite hard to do that on iCrapOS [13:07] <JEEBsv> the quicktime I meant was the OS X app IIRC [13:07] <JEEBsv> not even sure which version [13:07] <JEEBsv> anyways, that should be looked into [13:07] <divVerent> yes, but I assume Apple uses quite similar code on iOS [13:07] <divVerent> anything else would be madness [13:07] <JEEBsv> well, if it uses a hw decoder on the portable things [13:07] <divVerent> it still has to demux and verify some stuff [13:08] <divVerent> but yes, the actual decoder may even be by some other company [13:08] <JEEBsv> I don't think there's a HW decoder ASIC on the PC versions [13:08] <JEEBsv> yes [13:08] <JEEBsv> the iThings have been able to decode shit QT hasn't been for ages [13:08] <JEEBsv> ever since 3GS [13:08] <JEEBsv> or so [13:08] <divVerent> but compat problems TYPICALLY are at container level, because someone wrote moov with too many os or stuff like that ;) [13:08] <divVerent> or at "let me just annoy you" level, e.g. try feeding VFR video to an iPhone [13:09] <JEEBsv> lol [13:09] <divVerent> it displays the first frame then stays there [13:09] <JEEBsv> the PSP handled VFR well, surprisingly [13:09] <divVerent> and the best part: how does it even know it's VFR [13:09] <divVerent> at the first frame already [13:09] <divVerent> IIRC in mov/mp4, the time base is just the denominator [13:10] <divVerent> so for NTSC stuff, the numerator goes up by 1001 each frame [13:10] <divVerent> which looks quite close to VFR already ;) [13:10] <JEEBsv> it does have the timestamps in the index methinks, no? [13:10] <JEEBsv> yeah [13:10] <JEEBsv> the parsers have to be crazy limited to fail at VFR and so [13:10] <divVerent> well, if it actively wants to find out, it sure can check if all frame timestamps are divisible by 1001 in the index [13:10] <divVerent> or stuff like that ;) [13:10] <divVerent> but why should anyone do that [13:11] <JEEBsv> I think I've mostly just found integer overflows with timestamp parsing with regards to MP4/MOV [13:11] <divVerent> mp4 is basically an always-VFR format due to the encoding of timestamps [13:11] <JEEBsv> nah, it can be exactly CFR, unlike MKV [13:11] <divVerent> true :P [13:11] <JEEBsv> but it naturally /can/ have VFR in there too [13:11] <JEEBsv> MKV did lately get proper X/Y stuff too I think tho [13:11] <divVerent> mp4 can be "totally sane CFR with timestamps going up by one each frame" only if fps are integer [13:11] <divVerent> i.e. in Europe only ;) [13:12] <JEEBsv> nah, I didn't mean like that [13:12] <divVerent> but yes, I know that mkv issue [13:12] <JEEBsv> in mkv before this you couldn't even get 24000/1001 there exactly [13:12] <divVerent> which can't even represent many frame rates [13:12] <divVerent> at least PAL works [13:12] <JEEBsv> yeah [13:12] <JEEBsv> anyways, they added stuff to make proper X/Y rates possible [13:12] <JEEBsv> for mkv4 I think? [13:12] <JEEBsv> not finished [13:12] <JEEBsv> it's on the spec now tho [13:13] <divVerent> does that mean... that they didn't even fix this when rebranding a subset of mkv as WebM? [13:13] <JEEBsv> yeah [13:13] <divVerent> morons at google... [13:13] <divVerent> just to troll everyone, we should invent a container format that stores timestamps as float32 [13:14] <divVerent> or float16 ("half" like GPU vendors tend to call it), which is accurate for just long enough for a single rickroll [13:14] <divVerent> not even that, probably :P [13:15] <JEEBsv> but at least they finally fixed that now, and now they might want to do something about preroll [13:15] <JEEBsv> for intra refresh in H.264 and opus [13:16] <divVerent> BTW, I noticed ffmpeg got a lot better in the last year... I just managed to actually write a script to pick streams by language and render subtitles... even using attached fonts [13:16] <divVerent> the latter was awful XDG_ vars hacks to tell fontconfig where the fonts are, though ;) [13:17] <divVerent> just some TheDailyWTF worthy error messages... [13:17] <divVerent> fontconfig: Selected font is not the requested one: 'CronosPro-BoldDisp' != 'Cronos Pro Display' [13:17] <JEEBsv> lol [13:17] <divVerent> wonder how that can even happen... I am amazed that it found the font, but is that fuzzy matching? [13:17] <divVerent> why do we do fuzzy matching in a font system? ;) [13:18] <divVerent> is that an old Microsoft hack so they could remap TmsRmn into Times New Roman in Windows 3.1? ;) [13:18] <divVerent> and fontconfig had to perfect it [14:14] <knoch> I wrote an application using libav* libraries, the goal is to stream MPEG2-TS over RTP. To accomplish that, I create an AVFormatContext to read an input file, which is in MPEG2-TS format, then I create another AVFormatContext to remux all streams from the file, and finally, I use an AVFormatContext RTP muxer. It works fine with the VLC client but not with another RTSP client. What can I do? [14:14] <knoch> I basically followed this : http://libav-users.943685.n4.nabble.com/Output-mpeg-ts-to-rtp-td2234066.html [15:44] <zule> Hello, still having trouble with avconv/ffmpeg dropping frames on me if I try to specify the framerate when encoding a stream of jpg's to a mp4 [15:44] <zule> Please see the following pastie: [15:44] <zule> http://pastie.org/private/ojuply3xjyxuxxwcyiana [15:45] <zule> I have no idea why this is happening, the only change I make is adding "-r 5" to the command line [16:06] <iive> zule: if ffmpeg doesn't drop frames. the video would loose sync with the audio. [16:07] <iive> zule: are you trying to change the speed of the video? [16:07] <zule> there is no audio [16:07] <zule> can I prevent the drop somehow? [16:07] <zule> this is pretty much just a fast paced slide show [16:09] <iive> i'm not that familiar with ffmpeg... [16:09] <iive> wait... you encode jpg's? not another video? [16:10] <zule> jpg to video [16:10] <zule> no audio is present or mixed in however [16:11] <iive> try to move the -framerate before the -i [16:13] <zule> I'll be damned [16:13] <zule> :D [16:13] <iive> the position of the options matter, because it may apply to different system. for example, if you put it in the decoder section, then the demuxer (reading files) would use a default value and the codec section would try to change from one fps to another, while preserving same speed. [16:13] <zule> why would it matter, I thought I was specifying output framerate to 5, why would a jpg stream need a framerate? [16:14] <zule> regardless that does it [16:14] <iive> because it is abstracted as virtual container, where each jpg is a frame. [16:14] <zule> thank you! [16:16] <iive> i'm glad i was able to help you :) [16:25] <zule> pwd [16:57] <divVerent> what am I doing wrong when I get [16:57] <divVerent> Stream #0:1[0xa0], 0, 1/90000: Audio: pcm_s16be, 48000 Hz, stereo, 1536 kb/s [16:57] <divVerent> from the Input section [16:57] <divVerent> but later [16:57] <divVerent> [abuffer @ 0x1bf9400] Setting entry with key 'sample_fmt' to value '(null)' [16:57] <divVerent> [abuffer @ 0x1bf9400] Setting entry with key 'channel_layout' to value '0x3' [16:57] <divVerent> [graph 0 input from stream 0:1 @ 0x1bf9880] Invalid sample format '(null)' [16:57] <burek> paste everything at pastebin [16:57] <burek> don't let as guess the rest [16:57] <tonsofpcs> how do I force audio codec on input? is it ffmpeg -acodec foo -i input -acodec bar output , with input in format foo and output in format bar? [16:58] <burek> tonsofpcs yes [16:58] <tonsofpcs> thanks burek :) [16:58] <tonsofpcs> I'm doing crazy now :D [16:58] <divVerent> https://gist.github.com/3859359 [16:58] <divVerent> burek: not much more info, though [16:58] <tonsofpcs> ( ffmpeg -acodec ac3 -i input.aiff -acodec copy output.ac3 ) [16:59] <burek> divVerent as I can see ffmpeg has a hard time recognizing your input [16:59] <divVerent> ffplay plays it fine though [17:00] <divVerent> including audio [17:00] <burek> tonsofpcs, sorry, not -acodec foo [17:01] <burek> but -f format [17:01] <burek> the file is a container [17:01] <burek> that contains multiple acodec/vcodec/scodec streams [17:01] <divVerent> burek: do I maybe need special options to read directly from a DVD ISO? [17:01] <burek> container/format is what you want to set [17:02] <divVerent> burek: mounting the iso and playing from there is no option, because these stupid VOBs are split at every GB [17:02] <burek> divVerent, not sure, never used it :) [17:02] <tonsofpcs> burek: it seems to be working... [17:02] <divVerent> burek: haha [17:02] <divVerent> "by not using ffmpeg" [17:02] <divVerent> is the answer there [17:02] <tonsofpcs> ffmpeg -acodec ac3 -i input.aiff -acodec copy output.wav makes an output that vlc can handle... [17:03] <divVerent> okay, assume I have the iso mounted... how would I do it then? [17:03] <tonsofpcs> I'll try ffmpeg -f ac3 -i input.aiff -acodec copy output.wav and compare them [17:03] <ubitux> < divVerent> burek: do I maybe need special options to read directly from a DVD ISO? // there is still no dvd input device :( [17:03] <divVerent> the problem is that a title consists of multiple VObs [17:03] <divVerent> but I want o "seams" [17:03] <ubitux> so mount -o loop :( [17:03] <divVerent> that alone doesn't help [17:03] <divVerent> I want the second vob follow right after the first one without any clicks, stutter or the like [17:04] <divVerent> just like on a real DVD player [17:04] <divVerent> wonder if catting the vobs and encoding from that does the right thing? [17:04] <divVerent> mc [17:05] <ubitux> it's mpeg2 so it should work [17:05] <ubitux> you have a concat protocol for this [17:05] <divVerent> damn... that means large changes to the encoding script... :P [17:05] <divVerent> as I rely on e.g. ffprobe on it [17:06] <ubitux> divVerent: working on the dvd input device is welcome :) [17:06] <divVerent> maybe it'll rather be dvdunauthor then... [17:06] <divVerent> which eats over 9000 MB temp space [17:06] <divVerent> oh wait, concat: is an URL scheme [17:06] <divVerent> that works for me ;) [17:07] <tonsofpcs> burek: interesting. If I use -f ac3 , the output is a WAV header followed by an AIFF header (FORM, COMM chunk, ANNO chunk, etc.). If I use acodec, it outputs just a WAV header and data. [17:11] <knoch> hello ubitux, have you read my problem ? [17:11] <ubitux> knoch: i have no idea about your problem [17:12] <divVerent> can one hardsub a DVD subtitle somehow? [17:12] <ubitux> yes [17:12] <knoch> do you know someone who can help me ? [17:12] <divVerent> okay, how? [17:12] <ubitux> nicolas added something recently [17:12] <ubitux> just a sec [17:12] <divVerent> also, is it possible with -filter or only with -complex_filter? [17:13] <tonsofpcs> is there a way to properly parse byte-reversed AC3? If I try decoding it, I get endless frame sync errors. [17:13] <burek> tonsofpcs, why are you using -f before -i at all? [17:13] <burek> why dont you let ffmpeg auto-recognize the content [17:14] <tonsofpcs> burek: because the content is byte-reversed AC3 in a container that flags it as PCM. [17:14] <knoch> thank you again ubitux [17:14] <ubitux> knoch: i can't help you :p [17:14] <tonsofpcs> (well, technically the container flags it as none and the pointer to the container flags it as PCM... long story :) [17:14] <ubitux> divVerent: mmh i can't find it again :( [17:14] <knoch> but if you know someone who can, then you helped me :D [17:15] <tonsofpcs> (read: AIFF is a horrible RIFF implementation) [17:15] <ubitux> knoch: i don't know any [17:15] <knoch> it's sad [17:15] <ubitux> divVerent: ah, got it [17:16] <ubitux> divVerent: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=88fc1438c693ffb7793aeb… [17:16] <burek> divVerent http://blog.rot13.org/2009/10/encoding_dvd_into_hq_flash_video_using_ffmpeg… [17:17] <divVerent> ubitux: okay, so this really needs a complex filter.... will do this tomorrow then :P [17:19] <divVerent> ubitux: I take it, assuming I use -filter_complex with implicit output [17:19] <divVerent> -filter_complex FOO gets a filter appended by -filter_complex "FOO [XYZZY] ; [XYZZY] BAR" [17:19] <divVerent> where XYZZY is an unused label [17:20] <divVerent> with that, it'll just be a job of string appending again ;) [20:15] <KING_LEE> hello [20:15] <KING_LEE> burek: you here? [20:20] <KING_LEE> i changed the -deinterlace to -v yadif and testet my script with a longer clip, it still shortens the duration, seems like it plays it slightly faster [20:45] <KING_LEE> http://pastie.org/5025636 [20:46] <KING_LEE> the original MTS had a duration of 8:08 and it came out 7 mins and 35 sec [20:47] <KING_LEE> http://pastie.org/5025641 [20:47] <KING_LEE> thats the script [20:47] <burek> KING_LEE, what is the ffmpeg's cmd line? [20:47] <burek> try running: bash -x <scriptname> [20:47] <burek> or sh .. something [20:47] <burek> for debug [20:47] <KING_LEE> ok [20:49] <KING_LEE> http://pastie.org/5025652 [20:49] <KING_LEE> like this? [20:53] <burek> just a sec [20:54] <burek> hm [20:54] <burek> Input #0, mpegts, from '00009.MTS': Duration: 00:07:35.04, start: 0.481967, bitrate: 23837 kb/s [20:54] <burek> your input is 7:35 long [20:55] <KING_LEE> but when i play it in my videoplayer it says 8:08 [20:56] <burek> which file exactly? [20:56] <burek> 00009.MTS ? [20:56] <KING_LEE> yes [20:57] <burek> try: mediainfo 00009.MTS [20:59] <KING_LEE> gotta install that first [21:01] <KING_LEE> what that mediainfo? it says that it cannot be trusted [21:01] <KING_LEE> WARNUNG: Die folgenden Pakete können nicht authentifiziert werden! [21:01] <KING_LEE> libtinyxml2.6.2 libzen0 libmediainfo0 mediainfo [21:01] <burek> ? [21:01] <burek> do you have vlc [21:01] <KING_LEE> no [21:02] <KING_LEE> eer yes [21:02] <burek> do you have any other tool [21:02] <burek> you can check that file with [21:06] <KING_LEE> ok, when i play it in vlc it says 7:35 [21:10] <KING_LEE> seems like totem is not very reliable [21:10] <KING_LEE> the mts plays wierd in vlc [21:10] <KING_LEE> and i cant close it [21:10] <KING_LEE> hmm,... vlc... [21:10] <burek> well, where did you see 8:08? [21:11] <KING_LEE> in totem [21:11] <KING_LEE> in the info box and on the timeline [21:16] <KING_LEE> how wierd, when i open it in gnome mplayer it says 11:46 on the timeline [21:18] <burek> KING_LEE, your input might be damaged [21:19] <burek> try extracting the video with various tools [21:19] <burek> to get uncompressed video [21:19] <burek> and check if all those are of the same length [21:19] <burek> you'll surely figure out that something is wrong, using one of the tools [21:20] <KING_LEE> i am not very experienced in taht [21:21] <KING_LEE> my main goal is getting that stuff to work in cinelerra [21:22] <burek> what do you mean to work in cinerella? [21:22] <burek> you cant open .MTS files in that video editor? [21:22] <KING_LEE> no [21:24] <KING_LEE> it assumes a raw pcm and there is no video and the audio is plain noise [21:25] <burek> try ffmpeg -i 00009.MTS -map 0 -c copy output.mkv [21:25] <burek> just remux it to mkv and try opening in cin. [21:25] <KING_LEE> getting MTS into cinelerra would be even better but i have no info about that. [21:28] <KING_LEE> http://pastie.org/5025843 [21:37] <burek> hm [21:37] <burek> KING_LEE, it should work if it's ffmpeg, but try this instead [21:37] <KING_LEE> cant really read ffmpeg errors [21:37] <burek> ffmpeg -i 00009.MTS -map O.0 -map 0.1 -c copy output.mkv [21:40] <burbas> Hi. I'm having problems when capturing data from an rtsp stream. The output I get is http://pastebin.com/BrAB4zcx . The problem is that it takes forever in order to get that output. The command I use is "ffmpeg -i rtsp://192.168.1.90/11 output.mp4" [21:40] <burek> why don't you paste entire cmd output, not just fragments burbas [21:41] <KING_LEE> http://pastie.org/5025918 [21:41] <KING_LEE> same thing [21:42] <burbas> burek: Sorry, thought it was that part that was interesting [21:42] <burbas> I'll repost the entire thing [21:45] <burek> KING_LEE try just: ffmpeg -i 00009.MTS -c copy output.mkv [21:46] <KING_LEE> jep [21:47] <KING_LEE> but it does not load into cinelerra [21:47] <burek> why not [21:47] <burek> same errors? [21:48] <KING_LEE> yes [21:48] <KING_LEE> assuming raw pcm [21:49] <burek> then your audio/video stream is either broken or unsupported by cinerella [21:49] <burek> so, find another video editor [21:51] <KING_LEE> hmm,... i guess the camera bring the same output in every file but i will check a newer one [21:51] <KING_LEE> it's not mine and we have 4 of them [21:53] <KING_LEE> hmm, i got kinda used to cinelerra and i want something good. not just a simple editor only for putting clips together [21:53] <burek> btw KING_LEE, it's -map 0 (zero) [21:54] <burek> not -map O (letter 'o') [21:54] <burek> like 0-indexed input [21:54] <burek> 0.0 = input 0, stream 0 [21:54] <burek> so -map 0.1 means input zero, stream one [21:54] <burek> and -map 0 means all streams from input zero [21:54] <burek> ok? [21:56] <KING_LEE> ffmpeg -i 00009.MTS -map 0.0 -map 0.1 -c copy output.mkv [21:56] <KING_LEE> ? [21:59] <burek> or just -map 0 [21:59] <burek> if you want all streams [21:59] <burek> it's shorter to type [22:00] <KING_LEE> you mean ffmpeg -i 00009.MTS -map 0 -map 0 -c copy output.mkv [22:00] <KING_LEE> or [22:00] <KING_LEE> ffmpeg -i 00009.MTS -map 0 -c copy output.mkv [22:00] <burek> ffmpeg -i 00009.MTS -map 0 -c copy output.mkv [22:01] <burek> -map 0 = -map 0.0 -map 0.1 -map 0.2 -map 0.3 ... [22:04] <KING_LEE> still no cinelerra input [22:05] <burek> try kdenlive [22:13] <KING_LEE> i'll give it a try [22:13] <KING_LEE> but i would really like to stick with cinelerra [22:14] <KING_LEE> a reasonable script to turn the MTS to something that fits into it all i need [22:15] <burek> it's not MTS that cinellera has problem with [22:15] <burek> it's either audio or video [22:16] <burek> it doesn't support ac3 I guess [22:16] <burek> since h264 is widely supported [22:16] <burek> by most popular video editors [22:25] <KING_LEE> well, the script i have now is ok [22:26] <KING_LEE> the size of the output is a bit large sometimes but i guess i have to live with that [22:38] <KING_LEE> the 0009.MTS is 1.4 gb and the 0009.mov gets up to 9.7 gb [22:44] <KING_LEE> kdenlive looks ok but cinelerra seems to have more functions to me [22:49] <KING_LEE> is there a way to cut down some size? [00:00] --- Wed Oct 10 2012

1 0

ffmpeg-devel.log.20121008
by burek 09 Oct '12

09 Oct '12

[00:16] <Compn> >I don't think lavfi should be remove. [00:16] <Compn> liaaaarrrrrrrrr [00:17] <Compn> :P [00:34] <ubitux> haha Compn :) [02:16] <cone-223> ffmpeg.git 3Michael Niedermayer adcfc0535db8 7libavformat/mxfenc.c: mxfenc: fix av_log data type for dts paramater [02:16] <cone-223> ffmpeg.git 3Michael Niedermayer fc6860a3ebae 7libavcodec/8svx.c: 8svx: remove unused variable [02:16] <cone-223> ffmpeg.git 3Michael Niedermayer 106790a4e92f 7libavcodec/ffv1.c: ffv1: fix array data types [03:18] <cone-223> ffmpeg.git 3Michael Niedermayer bd2613a32205 7libavcodec/rangecoder.c: rangecoder: fix "incompatible pointer type" warning [03:18] <cone-223> ffmpeg.git 3Michael Niedermayer c5fdd0696ab5 7libavcodec/tiff.c: tiff: fix "assignment discards qualifiers from pointer target type" warning [03:18] <cone-223> ffmpeg.git 3Michael Niedermayer b9a77198280f 7libavcodec/tscc.c: tscc: fix "assignment discards qualifiers from pointer target type" warning [03:18] <cone-223> ffmpeg.git 3Michael Niedermayer 89074e9066d1 7libavcodec/wmalosslessdec.c: wmalosslessdec: remove unused variable [05:32] <cone-223> ffmpeg.git 3Michael Niedermayer 43bbc3f477a2 7libavutil/xtea.c: xtea: give constants the correct type [05:32] <cone-223> ffmpeg.git 3Michael Niedermayer f464b02d2214 7libavformat/mpegts.c: mpegts: fuzzy crc check for not so spec compliant files [05:45] <cone-223> ffmpeg.git 3Pavel Koshevoy 9425dc3dba0b 7libavcodec/ppc/fmtconvert_altivec.c: Fix build failure on osx 10.5.8 ppc [09:07] <cone-907> ffmpeg.git 3Clément BSsch f7c46d251c9a 7ffmpeg_opt.c libavformat/ffm.h libavformat/ffmenc.c: ffserver: fix seeking with ?date=... [11:04] <cone-907> ffmpeg.git 3Clément BSsch 208a5d132282 7tests/Makefile tests/ref/fate/ffprobe_compact tests/ref/fate/ffprobe_csv tests/ref/fate/ffprobe_default tests/ref/fate/ffprobe_flat tests/ref/fate/ffprobe_ini tests/ref/fate/ffprobe_json tests/ref/fate/ffprobe_xml tests/test.ffmeta: fate/ffprobe: add some stream metadata. [11:05] <ubitux> isn't the bot supposed to trim the affected files? [11:06] <ubitux> would be nice to have an url to the git with a shortened hash too [11:13] <cone-907> ffmpeg.git 3Paul B Mahol d7a473926504 7Changelog configure doc/general.texi libavcodec/Makefile libavcodec/allcodecs.c libavcodec/avcodec.h libavcodec/codec_desc.c libavcodec/tak.c libavcodec/tak.h libavcodec/tak_parser.c libavcodec/takdec.c libavcodec/version.h libavformat/Makefile libavformat/allformats.c libavformat/takdec.c libavformat/version.h tests/fate/lossless-audio.mak tests/ref/fate/lossless-tak: TAK demuxer, decoder and parser [11:20] <ubitux> :) [11:20] <durandal_1707> j-b: libav is switching decoders/encoders to planar audio sample formats so some sunny day VLC will fail to play anything remotely useful [11:21] <j-b> durandal_1707: is there any actual use of using planar? [11:22] <ubitux> simpler decoders, easier filtering sometimes? [11:22] <durandal_1707> j-b: each decoder do not need to interleave stuff on its own.... [11:23] <j-b> ok. Still playback needs interleaving [11:23] <j-b> durandal_1707: I guess we'll just reinterleave it [11:25] <j-b> durandal_1707: all APIs decode_ do that [11:25] <j-b> durandal_1707: all APIs decode_ do that? [11:27] <durandal_1707> j-b: ??? [11:28] <j-b> durandal_1707: avcodec_decode_audio3, avcodec_decode_audio4, avcodec_decode_audio5, avcodec_decode_audio6 or whatever the new name is? [11:29] <durandal_1707> j-b: no, it is decoder specific, it it sets SAMPLE_FORMAT_U8P/S16P/S32P ... [11:30] <j-b> durandal_1707: ok. So I need to block to a version before that, right? [11:32] <durandal_1707> version of what? [11:34] <j-b> of libavcodec [11:35] <durandal_1707> j-b: such sample formats are introduced long before coders started to use them.... [12:08] <nevcairiel> alac decoder already does it today [13:21] <cone-907> ffmpeg.git 3Martin Storsjö e67b0f99520e 7libavformat/gxf.c: gxf: Include the right header for the avpriv_frame_rate_tab declaration [13:21] <cone-907> ffmpeg.git 3Diego Biurrun 62ae37decde7 7libavdevice/timefilter.c: timefilter: De-doxygenize normal code comments and drop silly ones [13:21] <cone-907> ffmpeg.git 3Justin Ruggles 5364327186fb 7libavcodec/adpcmenc.c: adpcmenc: ensure calls to adpcm_ima_compress_sample() are in the right order [13:21] <cone-907> ffmpeg.git 3Justin Ruggles 37f701f1c396 7libavcodec/utils.c: avcodec: allow either planar or interleaved sample format when encoding mono [13:21] <cone-907> ffmpeg.git 3Justin Ruggles 7b556be67353 7libavfilter/af_resample.c: af_resample: avoid conversion of identical sample formats for 1 channel [13:21] <cone-907> ffmpeg.git 3Michael Niedermayer 43c157f4a46c 7: Merge remote-tracking branch 'qatar/master' [13:23] <divVerent> s/deoxygenize/deoxydize/; s/deoxydize/reduce/ ;) [13:37] <thresh> hello [13:40] <cone-907> ffmpeg.git 3Paul B Mahol 7d7a473926504: TAK demuxer, decoder and parser * 3http://tinyurl.com/9fqd8ex3 [13:40] <thresh> ubitux: ^^ [13:42] <ubitux> thresh: why tinyrul? [13:42] <ubitux> you could make a source.ffmpeg.org url [13:43] <ubitux> with a trimed hash [13:43] <thresh> wouldnt that be longer? [13:43] <ubitux> does it really matter? [13:43] <thresh> well, I used what's already available in irker without modifying it [13:43] <ubitux> i'm not very fond of the tinyurl thing :( [13:43] <ubitux> isn't it configurable? [13:47] <TimNich> you can make your own tinyurl if you want [13:49] <thresh> ubitux: looks like it isnt [13:50] <ubitux> :/ [13:51] <thresh> let me try updating just in case [14:05] <thresh> suggestions on colorscheme are also welcomed, btw [14:05] <ubitux> colors are fine imo [14:07] <thresh> ...and last test [14:08] <cone-907> ffmpeg.git 3Paul B Mahol 7d7a473926504: TAK demuxer, decoder and parser * 3http://tinyurl.com/9fqd8ex3 [14:10] <ubitux> looks like it won't be the last [14:11] <nevcairiel> personally i prefer bit.ly for shortening, its just shorter then tinyurl :P [14:12] <thresh> please send patches to irker upstream :) [14:13] <ubitux> i don't think it's worth shortening these urls [14:14] <nevcairiel> also, the standard short-hash form is 7 chars. ;) [16:04] <ubitux> michaelni: one of the main other races raised by helgrind is ff_h264_decode_mb_cabac writing a lot of stuff on the AVFrame s->current_picture.f [16:04] <ubitux> do you see any simple fix for this? [16:06] <ubitux> same in lavc/h264_pred.h:decode_mb_skip [16:06] <ubitux> it seems there are a lot of write around this [16:07] <ubitux> and since it's touching the private data, it leads to races [16:48] <thresh> the 12 vs. 7 thing will be sorted soon-ish, irker upstream says [16:48] <thresh> also, they'll fix the short hash generation in the commit links [16:49] <thresh> so once they do that, I'll update videolan instance, and it'd be set to do just what you wanted [17:10] <ubitux> thresh: thank you :) [17:53] <divVerent> what am I doing wrong with libswscale [17:53] <divVerent> when after converting yuv444p to yuv420, the chroma plane changes like this: [17:53] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/081e22f10498dbb69456b2a41eaf667a.png [17:53] <ubitux> saste: i grep'ed all over my irc logs and couldn't find where you linked to the metadata in bufferref :( [17:53] <divVerent> I fwrote() out the u plane right before and after calling into swscale... [17:54] <divVerent> it's the fast bilinear resampler, BTW [17:54] <divVerent> does the resampler even matter when not changing the size? [17:56] <divVerent> also, what resampler SHOULD I be using [17:56] <divVerent> when I convert yv12 to yuv444p, then want to screw with non subsampled chroma, then convert back to yv12? [17:56] <divVerent> I want the yv12 -> yuv444p -> yv12 conversion to not change chroma at all when I do no changes in between [17:57] <divVerent> nearest is no option, because that handles the pixels wrong that I did change [17:57] <saste> ubitux: https://github.com/kuehnelth/libav/commits/geotiff-encoder [17:57] <ubitux> oh i saw that link, but not the metadata thing [17:58] <saste> ubitux: https://github.com/kuehnelth/libav/commit/b8e9baf7f93c1b8e6c9e897dbb23393e2… [17:58] <ubitux> yeah i saw it now :) [17:58] <ubitux> i just looked at the url first :p [17:59] <ubitux> saste: btw do you mind to dig a bit about the -help full formating patch? :x [18:00] <saste> ubitux: i can already remove the "-" prefix [18:00] <saste> other formatting can go into separate commits [18:00] <ubitux> "lavfi: Keep frame-based metadata." "a year ago" has it been submitted? [18:00] <ubitux> saste: sure [18:01] <saste> ubitux, never [18:01] <ubitux> mmh. [18:01] <saste> so it will need some rebasing, but seems ok overall [18:01] <ubitux> no activity since a long while [18:02] <ubitux> i'll try to pick it and make something out of it, eventually. [18:02] <saste> i contacted the author, and he wrote that he has no time [18:02] <ubitux> ok [18:56] <michaelni> divVerent, are you downscaling something ? fast bilinear is just for upscaling [19:15] <ubitux> saste: any idea what kind of convention we should follow in filter's metadata for the keys? [19:15] <ubitux> like "<filtername>.<keyname>" [19:15] <ubitux> "filter.<filtername>.<keyname>" [19:15] <ubitux> "filter.<keyname>" [19:15] <ubitux> ? [19:15] <saste> ubitux: that's a good question [19:15] <saste> also how can we avoid to meddle with external metadata? [19:16] <saste> i suppose there is no way [19:16] <ubitux> maybe we could write a function taking a AVFilter and key [19:16] <saste> we could even think about keeping two different metadata dictionaries [19:16] <saste> but i'm not sure i like it [19:17] <ubitux> well maybe the AVDictionary can have a signature or something [19:17] <saste> a meta-meta tag [19:17] <ubitux> :D [19:17] <saste> or just keep two different dictionary for the moment [19:17] <ubitux> well we can just add a const char *id in the AVDictionary [19:17] <saste> *dictionaries [19:18] <ubitux> ah but i'm stupid it will require multiple dict [19:18] <ubitux> then in the entry. [19:18] <saste> multiple dictionaries could be an idea [19:18] <ubitux> well it's a pain [19:18] <saste> so you have metadata_dicts [19:19] <saste> but yes it could be a pain [19:19] <ubitux> looks overkill [19:20] <ubitux> i'll go for "lavfi.<keyname>" [19:20] <saste> X-Lavfi/foo=bar [19:20] <ubitux> key="X-Lavfi/foo" ? [19:20] <saste> yes, keep it simple for the moment [19:20] <saste> doesn't solve the (theoretical) namespace conflict [19:21] <saste> since you don't know what the user may write in the metadata [19:21] <ubitux> i'll kill the first user who will want to put a key named "lavfi.silence_start" in the metadata of his file [19:21] <ubitux> and anyway, it's a frame-level meta [19:21] <ubitux> shouldn't even reach the file metadata [19:21] <iive> don't forget filters could be inserted multiple times [19:22] <iive> you need something to identify them uniquely [19:22] <saste> and the user may want to export the created tags (in the encoded file) [19:22] <saste> so a simple solution may consist into having - for the moment - two dictionaries [19:23] <ubitux> iive: it's a pain to extract in the common cases if you do that [19:24] <iive> ubitux: hum? [19:24] <saste> in other words, at some point you have to decide if to put the metadata back to the file, or to drop it [19:24] <saste> also, i think it would be useful to be able to *specify* a filter instance name [19:24] <ubitux> iive: if you have a meta key like "filter.<random>.silence_start" if the user want to extract the value, it's harder than just av_get_dict("lavfi.silence_start") [19:25] <saste> so you don't have to rely on the somehow unpredictable auto-assigned name [19:25] <ubitux> mmh [19:25] <saste> something like silencedetect/first_one=..., silencedetect/second_one=... [19:26] <ubitux> well i think we need a simple injection first [19:26] <ubitux> we'll try to overthink it after :p [19:26] <saste> at that point you can tell (globally?) to the internal filters to always use a custom prefix for metadata entries, like X-Lavfi/... [19:26] <saste> which is then discarded by the buffersink [19:26] <saste> ubitux, yes get it working, get it correct, get it fast [19:27] <saste> in this order ;-) [19:27] <durandal_1707> are here any lavfi experts? [19:28] <ubitux> eeeh we don't have a lavfi/utils.c :( [19:29] <saste> durandal_1707, what's the problem? [19:32] <durandal_1707> saste: i get segv in lavfi when samplerate changes midstream [19:33] <saste> durandal_1707, yes you filed a ticket, right? [19:33] <durandal_1707> yes [19:33] <saste> i believed it was supported, but I may be wrong [19:34] <saste> at least at some point we had "normalization" in the buffer source [19:34] <saste> now i don't know how it is handled [19:43] <cone-907> ffmpeg.git 3Anton Khirnov 778071a1420b4: pixfmt: add AV_ prefixes to PIX_FMT_* * 3http://tinyurl.com/98goofl3 [19:43] <cone-907> ffmpeg.git 3Michael Niedermayer 7ae77266fce26: Merge commit '78071a1420b425dfb787ac739048f523007b8139' * 3http://tinyurl.com/9g7dyrc3 [20:05] <ubitux> ! [20:05] <ubitux> oh it's the typo in old_pix_fmt.h [20:05] <ubitux> michaelni: fate is gonna get red if you don't merge the typo fix :p [20:07] <Daemon404> red is for rage [20:07] <Daemon404> FATE SMASH [20:07] <ubitux> :D [20:17] <cone-907> ffmpeg.git 3Anton Khirnov 789715a3cf187: lavu: fix typo in Makefile * 3http://tinyurl.com/97fta693 [20:18] <ubitux> :) [20:21] Action: beastd starts fate client again [20:21] <Daemon404> i am still waiting for baptiste to approve my key [20:21] <Daemon404> :V [20:22] <ubitux> saste: any idea why avfilter_copy_buf_props() is never called with a classic ffprobe -f lavfi -i amovie=... -show_frames? [20:23] <saste> ubitux, uhm... no [20:23] <ubitux> ffmpeg -f lavfi -i amovie=... -f null - calls it correctly [20:23] <ubitux> but ffprobe never [20:23] <ubitux> i wonder how that's supposed to happen [21:19] <cone-907> ffmpeg.git 3Anton Khirnov 7716d413c1398: Replace PIX_FMT_* -> AV_PIX_FMT_*, PixelFormat -> AVPixelFormat * 3http://tinyurl.com/95kjza43 [21:19] <cone-907> ffmpeg.git 3Michael Niedermayer 7ac627b3d38d3: Merge commit '716d413c13981da15323c7a3821860536eefdbbb' * 3http://tinyurl.com/8mbx7en3 [21:20] <nevcairiel> why are some hashes pink? :d [21:21] <iive> i think that these that start with number are pink [21:21] <nevcairiel> wut [21:22] <Daemon404> no [21:22] <Daemon404> i think it's if they are part of merges [21:22] <iive> indeed, i'm wrong. [21:22] <nevcairiel> and grey? [21:22] <nevcairiel> :D [21:32] <thresh> color change looks like a bug to me [22:03] <cone-907> ffmpeg.git 3Anton Khirnov 78728b958ff1b: lavu: fix typo in Makefile * 3http://tinyurl.com/9htqjhw3 [22:03] <cone-907> ffmpeg.git 3Luca Barbato 70826d8513d14: segment: drop global headers setting * 3http://tinyurl.com/99pxe3p3 [22:03] <cone-907> ffmpeg.git 3Luca Barbato 7175d0d94da11: doc: initial nut documentation * 3http://tinyurl.com/8duknz53 [22:03] <cone-907> ffmpeg.git 3Luca Barbato 791f5f8756168: doc: remove a warning from filters.texi * 3http://tinyurl.com/9jgs9aq3 [22:03] <cone-907> ffmpeg.git 3Luca Barbato 7d19d01bf6281: doc: support the new website layout * 3http://tinyurl.com/8vgljly3 [22:03] <cone-907> ffmpeg.git 3Janne Grunau 7f101eab1be1a: x86: call most of the x86 dsp init functions under if (ARCH_X86) * 3http://tinyurl.com/8f728pk3 [22:03] <cone-907> ffmpeg.git 3Janne Grunau 7cb36febcbc59: x86: cavs: call ff_cavsdsp_init_x86() under if (ARCH_X86) * 3http://tinyurl.com/9kj7dhx3 [22:03] <cone-907> ffmpeg.git 3Janne Grunau 77e522859fc46: x86: vc1: call ff_vc1dsp_init_x86() under if (ARCH_X86) * 3http://tinyurl.com/8rx3lrv3 [22:03] <cone-907> ffmpeg.git 3Michael Niedermayer 752dc18d414f4: Merge remote-tracking branch 'qatar/master' * 3http://tinyurl.com/9hj6ewk3 [22:06] <llogan> saste: is there something obvious i missed when testing flite in ubuntu 12.04? [22:06] <saste> llogan, no i realized what the problem was [22:07] <saste> the guy told that he compiled a local static library [22:07] <saste> if you have a dynamic lib, it is not required to specify the -lasound flag [22:07] <saste> so this explains the failure [22:07] <saste> the failure should be reproducible, with a static build of libflite [22:08] <saste> i'm gonna to try that later if i find the time, and push it [22:10] <Daemon404> google doesnt do a good job and telling me where to find libflite [22:10] <Daemon404> the 3rd result is ffmpeg... [22:11] <llogan> did you find it? http://www.speech.cs.cmu.edu/flite/download.html [22:11] <Daemon404> yes [22:11] <Daemon404> libflite -> flite [22:12] <llogan> flite reminds me of a prank call to a friend telling him to report to work at Taco Bell at 7 am. [22:21] <llogan> maybe i shouldn't have been sitting on my ass so long on that new site design... [22:24] <saste> llogan, customizable skin? [23:23] <ubitux> saste: i think i get it [23:24] <ubitux> ffmpeg is always using avfilter to get buffers; those buffer have props, which are copied to a local AVFrame etc [23:24] <ubitux> ffprobe is just getting a AVFrame directly from the lavfi device [23:24] <ubitux> i think the lavfi device should set the meta [23:26] <ubitux> mmh i'm missing a step. [23:57] <ubitux> saste: it doesn't look simple to do the bufref->metadata to avpacket to avframe :p [23:57] <ubitux> (in case of lavfi input device) [23:57] <ubitux> (which looks like the only way to make ffprobe communicated with lavfi) [23:57] <ubitux> :( [23:58] <saste> ubitux, what's the problem? [23:58] <ubitux> lavd/lavfi fills AVPackets [23:58] <ubitux> so at that point [23:58] <ubitux> how do you get the metadata from the bufferref [23:58] <ubitux> up to the avframe? [23:59] <saste> you need to copy that [23:59] <ubitux> where? [23:59] <saste> in the buffersink i suppose [23:59] <ubitux> i'm not sure how that will help [00:00] --- Tue Oct 9 2012

1 0

ffmpeg.log.20121008
by burek 09 Oct '12

09 Oct '12

[03:54] <praveenkumar_> hi everyone, I am trying to compile ffmpeg on arm arch and getting error http://fpaste.org/ROCy/ , any idea? [04:56] <buu> Hey, how do I drop a stream during transcoding? [05:05] <buu> I've figured out it needs to be -map [05:05] <buu> But what option do yous pecify to go 'delete this' [05:06] <buu> Oh, -vn [05:06] <buu> That appears workable. [06:30] <kn1000> If I want my resultant file to be x264 encasulated with mkv, and I've got a video file and an audio file that aren't neccessarily the same length, is ffmpeg capable of taking the video and the audio and truncating the longer (audio or video) as soon as the other part has finished [06:30] <kn1000> basically audio = 30 seconds, video = 29 seconds, ffmpeg would encode audio and video together for 29 seconds but last second of audio would be lost [12:09] <relaxed> knoch: -shortest [12:56] <knoch> relaxed: -i_dont_understand [13:01] <burek> buu or -map -0.1 [13:01] <burek> minus in front of a stream index makes what you want [15:01] <relaxed> knoch: sorry, that was intended for kn1000 [15:01] <relaxed> but he parted [15:17] <EricAhn> what is the meaning of MPEG-TS interleaved streams? [15:17] <EricAhn> and differen between interleaved stream and non-interleaved stream. [15:17] <EricAhn> and difference between interleaved stream and non-interleaved stream. [15:18] <KING_LEE> hey guys [15:18] <KING_LEE> i get this error from a script when i try to make a .mov out of a .MTS [15:18] <KING_LEE> [mov @ 0x94e1ae0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1 >= 1 [15:18] <KING_LEE> av_interleaved_write_frame(): Invalid argument [15:19] <KING_LEE> what does that mean and how can i fix it? [15:19] <KING_LEE> it worked on my old system :/ [15:30] <iive> EricAhn: actually it is quite hard to create mpeg-ts that doesn't have interleaved steams. [15:31] <EricAhn> iive : hm I understood [15:32] <iive> non-interleaved stream is when you have audio as one big chunk and video as another big chunk [16:12] <KING_LEE> like this? http://pastie.org/5014898 ,... sorry [16:20] <pzich> KING_LEE: well, they're probably going to want to see the actual args you're passing FFMPEG inside your script [16:26] <KING_LEE> thats the script [16:26] <KING_LEE> http://pastie.org/5018997 [16:27] <KING_LEE> i try to make my MTS files from a canon xa10 work in cinelerra [16:28] <KING_LEE> i had this other script but the files came out huge (176mb .mov from a 11mb MTS) and i still cant work with it in cinelerra prperly [16:44] <relaxed> KING_LEE: That script is awful. [16:47] <ibsk8in31> I'm using FFmpeg for windows and once and a while it freezes. This time, I try to run again and it claims ffmpeg is not a valid win32 application. Has anyone else experienced this? Is it reboot time? [16:48] <KING_LEE> relaxed: i have no clue about scripts and ffmpeg, i only want to get these videos to work in cinelerra. this other script a have from http://www.g-raffa.eu/Cinelerra/HOWTO/get_media_ready.html#_how_to_convert_… produces these huge files and i want to have something lighter [16:48] <relaxed> KING_LEE: for a in *.MTS; do ffmpeg -i "$a" -vcodec copy "${a%.*}".mov; done [16:49] <relaxed> KING_LEE: The problem in this case is not the script but you should change it. [16:51] <relaxed> KING_LEE: cinelerra can't take mpegts as input? [16:53] <KING_LEE> it does not take the MTS. i have worked with other files about a year ago on my old system, then i had these MTS files and i got stuck with it and left it alone. now on this machine i want to get it going again [16:54] <relaxed> hmm, rename one of the files to filename.ts and see if it will import it. [16:56] <KING_LEE> no, that makes cinelerra think its a raw PCM [16:58] <KING_LEE> the MTS will import but there is no video and the audio is just loud noise [17:03] <relaxed> rename it to filename.m2t [17:07] <burek> KING_LEE and plus, you are not using ffmpeg [17:07] <burek> you are using a fork of ffmpeg [17:08] <KING_LEE> burek: what do you mean? [17:08] <burek> avconv is not the same thing as ffmpeg [17:09] <burek> take a look at your output: "Copyright (c) 2000-2012 the Libav developers" [17:09] <burek> libav is a fork of ffmpeg [17:09] <relaxed> He is using ffmpeg but it's from libav. All you're doing is confusing him further. [17:09] <burek> they just kept the ffmpeg tool, falsely added a message that ffmpeg is deprecated and let you believe you are still using the ffmpeg [17:09] <burek> which you are not [17:10] <burek> ffmpeg is ffmpeg, no need to confuse people with "ffmpeg from libav" [17:10] <burek> such thing shouldn't even exist [17:10] <KING_LEE> relaxed: assumes raw PCM if i rename it to .m2t [17:10] <burek> and if it was the same thing, they wouldn't create avconv (as a synonim for ffmpeg tool) [17:12] <relaxed> KING_LEE: ok run the followin the dir container the mts files -> for a in *.MTS; do ffmpeg -i "$a" -vcodec copy -acodec pcm_s16le "${a%.*}".mov; done [17:14] <relaxed> burek: Users could care less about ffmpeg/libav politics. [17:15] <zap0> couldn't [17:15] <relaxed> oh, right :) [17:16] <relaxed> also, containing* [17:17] <burek> never mind, I'll just stop wasting time helping people using something else but ffmpeg [17:19] <KING_LEE> relaxed: it produces the same error as my first script [17:25] <relaxed> KING_LEE: ugh, you can try rawvideo if you have the space. ffmpeg -i input.mts -vcodec rawvideo -acodec -acodec pcm_s16le output.mov [17:32] <KING_LEE> relaxed: that gives me another error message i cannot make sense of :/ [17:32] <KING_LEE> http://pastie.org/5019297 [17:36] <KING_LEE> maybe its my ffmpeg? [17:36] <relaxed> hold on [17:36] <KING_LEE> or avconv or whatever i am using ^^ [17:38] <ubitux> KING_LEE: try this [17:38] <ubitux> and check if it works better [17:43] <relaxed> KING_LEE: yes, a newer version my help and you can also try ffmpeg -i input.mts -vcodec ffvhuff -acodec pcm_s16le output.avi [17:44] <ziggyzero> Can somebody help me to convert MPEG Layer I files to MPEG Layer III? [17:57] <KING_LEE> relaxed: that is still quite large and has no video [18:03] <duvnell2> this is a room I can ask questions about the API of libavformat? or is there another room for that? [18:04] <saste> duvnell2, yes you can ask here [18:04] <saste> or in the libav-user mailing list [18:06] <duvnell2> thx.. does libavformat (or other parts of the library suite) support getting 'cue' or 'labl' tags from .wav files and the equivalent from other formats.. basically meta data within the files that goes with the audio tracks? [18:06] <duvnell2> e.g. 'labl' chunks in .wav are points within the audio with an attached label text.. [18:09] <duvnell2> I'm guessing those types of things would be just additional streams in the file of some type other than audio or video [18:11] <ziggyzero> Running files through mp3gain. Some complain saying that they are Layer I and not Layer III. Can somebody advise me how I convert the mp3's to layer III? [18:13] <saste> ziggyzero, re-encode with -acodec libmp3lame [18:14] <saste> if you don't have libmp3lame enabled, ffmpeg will create MPEG Layer II files (IIRC) [18:18] <relaxed> KING_LEE: maybe someone in #cinelerra can guide you in the right direction. [18:21] <KING_LEE> relaxed: thanks for your help, i will try my luck there again. i think i had this script from #cinelerra and they forwarded me to #ffmepeg for further details [18:22] <relaxed> ask them which lossless formats it supports [18:24] <KING_LEE> ok, but i need some food first [18:24] <KING_LEE> laters [20:13] <duvnell2> google shows some unpromising result.. is there a good C++ library that wraps encoding/decoding of files? [20:13] <duvnell2> (using ffmpeg) [20:23] <saste> duvnell2, why do you want a wrapper? [20:24] <duvnell2> presumably to make things easier [20:24] <saste> wrapper => more complicated [20:50] <goudkov> hi guys. i would like to have ffmpeg decode a stream and store it as a series of jpg images. i'm using format image2 with codec mjpeg and output file pattern like out%03d.jpg. would it be possible to set up ffmpeg to loop over that specified range instead of continuously increasing the file "number"? [20:51] <goudkov> i need to keep the latest x images at any given time [20:51] <tonsofpcs> anyone know what the AC3 (A/52) fourcc is? [20:57] <iive> ac-3 would do the trick. avi uses twocc for audio and 0x2000 may be the one. [21:00] <tonsofpcs> well, I have an aiff that is referenced by an mov that is flagged as PCM (twos) when it's really AC3 [21:02] <tonsofpcs> just seeing if I can fix it in file space without forcing a command-line option [21:03] <tonsofpcs> hmm. It appears VLC will open the adjusted .mov but won't actually decode the audio... I wonder how AIFF stores such information (it's in an SSND chunk) [21:04] <tonsofpcs> I've forced ffmpeg to decode it before, but I'd rather just make it usable as-is [21:07] <Sashmo> can anyone tell me which guide is best to follow for installing ffmpeg on mac 10.7.5 ? [21:08] <ziggyzero> **FIXED** All thanks for the suggestions with my MP3 issue. It was that the MP3 headers were corrupt. Running them through mp3val restored :-) I think was able to analyse them with mp3gain and apply the gain adjustments. Thanks. [21:08] <Sashmo> I see a few links out there, but all seem varied in what they do.. [21:23] <tonsofpcs> @^(*@*^@( chunked filetypes [21:32] <buu> burek: oh cool. [21:37] <saste> Sashmo, !wiki [21:37] <saste> => compilation guide [21:38] <llogan> i now have access to a OSX machine, so I'll eventually re-write the OSX guide [21:38] <llogan> or at least i tell myself i will [21:39] <Sashmo> thanks everyone [21:51] <saste> llogan, there are a few ancient tickets related to osx [21:51] <saste> could you check that they still stand? [21:57] <llogan> saste: ill take a look once i learn how to use it. (also it's the girlfriend's so i won't get to hog it). [21:58] <saste> llogan, they're mostly building bugs, i suppose they are already fixed but we need someone to check [21:58] <saste> ah and there is the openal thing [21:59] <saste> if someone has an old cheap mac to spare, let me know :) [21:59] <llogan> powerpc? [21:59] <saste> yeah that would be interesting [21:59] <llogan> i might be able to acquire some really old stuff. any model in particular? [21:59] <saste> one of the few bigendian CPUs [22:00] <llogan> i know a guy who has a personal Apple "museum" [22:00] <llogan> i'll see waht he may have and i'll get back to you [22:00] <saste> no no model in particular, that would be for testing purposes only [22:14] <llogan> saste: would shell access suffice? [22:15] <saste> llogan, that's better than nothing, but only useful for building problem [23:11] <lake> All, I have film videos @ 640x480. Should I try to scale them up to 720x480 for widescreen? Would that affect the quality? [23:11] <lake> also, I have this script i use. Does anyone notice anything glaringly wrong about this? [23:11] <lake> http://pastie.org/5020914 [23:11] <lake> i feel like the vbitrate may be a little to high [23:11] <lake> but i am a real noob and i don't even know how i got this far. : [23:11] <lake> :p* [23:27] <llogan> lake: you're using mencoder. this is ffmpeg. [23:33] <lake> llogan: llogan but mencoder is an interface to ffmpeg, right? [23:36] <llogan> i don't know much about it actually. i only use ffmpeg. [00:00] --- Tue Oct 9 2012

1 0

ffmpeg-devel.log.20121007
by burek 08 Oct '12

08 Oct '12

[01:42] <Compn> reading Daemon404 mail now [01:42] <Compn> u mad? [01:42] <Compn> :P [01:42] <Daemon404> ;p [01:43] <Compn> somewhat hilarious that no one has a problem with it but you [01:43] <Compn> :P [01:43] Action: Compn trolls harder [01:44] <Daemon404> noone has a problem [01:44] <Daemon404> because noone uses it [01:44] <Compn> you know mplayer can use it , right ? [01:44] <Compn> -vf lavfi [01:44] <Daemon404> mplayer devs == ffmpeg devs [01:44] <Daemon404> theyre the same people [01:44] <Daemon404> and this not relevant [01:44] <Compn> well doesnt it answer your question about what its supposed to be ? [01:45] <Compn> a filter library for ffmpeg and 3rd party encoders/players ? [01:45] <Compn> i'm only asking dumb questions because i am dumb [01:45] <Compn> so dont be offended by them [01:47] <Compn> to answer your question on dynamic plugins , yeah i think its a great idea [01:47] <Compn> it would just take one dynamic loader to be compiled, then any filter could be dropped in [01:58] <Compn> ok finished reading your mail [01:58] <Compn> you did quote someone who has a problem with lavfi :) [01:58] <Compn> dont mind me [01:59] <Compn> Daemon404 : i am curious since you bring up NIH, do you want ffmpeg to just add avisynth support or do you want them to port filters ? [02:00] <Daemon404> ffmpeg has avisynth support [02:00] <Daemon404> and im working on vapoursynth support for my own purposes [02:00] <Compn> then i'm curious what you want lavfi to be [02:00] <Daemon404> i dont htink lavfi should exist. [02:00] <ubitux> do you have a better solution on linux? [02:01] <Compn> you think its not good for users and wastes time for devels ? [02:01] <Daemon404> vapoursynth runs on linux [02:01] <Daemon404> and mac [02:01] <Daemon404> and windows [02:01] <Daemon404> and even bsd. [02:01] <ubitux> ok [02:01] <Compn> ubitux : there is also avxsynth , bbut i'm not sure what it is :P [02:01] <Daemon404> Compn, its an abomination created by netflix [02:01] <Compn> i just reading wikipedia, i dont know these things [02:02] <Compn> to answer your question about why lavfi started [02:03] <Compn> was it my idea? so ffmpeg could take the filters, and mplayer wouldnt have to maintain them ? [02:03] <Compn> so vlc could use them too [02:03] <Compn> and then make it a wrapper for all other opensource filters [02:04] <Compn> combine forces [02:04] <Compn> since ffmpeg had all the decoders and muxers [02:05] <Daemon404> [20:03] < Compn> and then make it a wrapper for all other opensource filters [02:05] <Daemon404> problem right here [02:05] <Daemon404> dat monolthism [02:06] <Compn> its like arguing the kernel should stop supporting systems ... because its too big [02:06] <Compn> or something [02:06] <Compn> a strange position to be , i dont understand [02:07] <Daemon404> actually [02:07] <Daemon404> the linux kernel [02:07] <Daemon404> design wise [02:07] <Daemon404> is the shittiest of all modern kernels [02:07] <Compn> of course , i come from mplayer , which bundled so much stuff ... [02:07] <Daemon404> it just has buttloads of devs [02:07] <Daemon404> it wasnt to long ago when you had to make powerpc drivers pretend to be i386 [02:07] <Daemon404> to make the kernel happy [02:08] <Compn> i just want to be clear that you are arguing against what basically open source was founded on (supporting everything) [02:09] <Daemon404> no [02:09] <Daemon404> im arguing it's a crap design [02:09] <Daemon404> and that all teh filters exist in better places [02:09] <Daemon404> opensource wasnt foudned om shitty design [02:09] <Daemon404> it was founded on technical merit, and political ideology [02:10] <Daemon404> not recreating the wheel 9000 times [02:10] <Compn> thats true, it wasnt my idea to rewrite the filters [02:11] <Daemon404> im not saying it shouldnt exist [02:11] <Compn> i'm remembering someones quote [02:11] <Daemon404> im saying it shouldnt exist in its current form [02:11] <Daemon404> as its utterly useless [02:11] <Daemon404> a call to arms [02:11] <Daemon404> so to speak [02:11] <Compn> 'theres no reason to reinvent the wheel, but if the wheel is square...' [02:11] <Daemon404> except [02:11] <Daemon404> our wheel is also square [02:11] <Daemon404> were porting logn ancient filters [02:11] <Compn> quite possible :) [02:12] <Compn> those filters are old [02:12] <ubitux> what about a sphere wheel? [02:12] <Compn> i like sphere wheel idea, more stability [02:12] <Daemon404> me and a prominent avs plugin dev were giggling in teh VDD room for lavfi [02:12] <Daemon404> when they were like "hwdn3d is so cuttign edge!" [02:12] <Daemon404> "and gradfun! [02:12] <Daemon404> (hes teh AUTHOR of gradfun) [02:14] Action: Daemon404 goes to grab a slice of pizza quickly [02:14] <Compn> ugh [02:14] <Daemon404> forgot to eat dinner because of trolling... [02:14] <Compn> google for vaporsynth not get results for vapoursynth [02:14] Action: Compn upset [03:21] <cone-191> ffmpeg.git 3jamal 7tests/Makefile: tests/Makefile: fix ffprobe-test.nut with target-exec [03:21] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/h264.c: h264: fix integer avoption types [03:21] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/libvpxenc.c: libvpcenc: fix flags voption types [03:21] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/mpeg4videodec.c: mpeg4videodec: fix integer avoption types [03:21] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavformat/mov.c: mov: fix integer avoption types [06:06] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavformat/movenc.c libavformat/movenc.h: movenc: support an alternative to edit lists to handle the first DTS != 0 case. [06:09] <Daemon404> oh wow [06:09] <Daemon404> michaelni, whats the functionality of use_editlist [06:10] <Daemon404> it might be exactly what i was going to implement [06:15] <Daemon404> btw michaelni, do we support edit lists properly with timestamp offsets when demuxing? [06:15] <Daemon404> i.e. skip the first N samples based off the edit list [06:15] <Daemon404> thats the other thing i was going to implement [06:34] <brimestone> Im getting a weird result when i add -timecode my footage end up 5 times longer than it should.. [11:25] <michaelni> "<Daemon404> michaelni, whats the functionality of use_editlist" <--- its to prevent the muxer from writing edit lists as some software doesnt support it [11:25] <thresh> michaelni: hey, where do you want the hash id in the string? [11:25] <michaelni> Daemon404, i belive the full commit message explains this [11:26] <michaelni> thresh, dunno, no real preferrance, where it looks good or maybe where CIA had it [11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Check the output UrlContext before accessing it [11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Properly return errors from ism_flush to the caller [11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Move the output_chunk_list and write_manifest functions up [11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Try writing a manifest when opening the muxer [11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Ignore the return value from mkdir [11:43] <cone-49> ffmpeg.git 3Martin Storsjö 7libavformat/smoothstreamingenc.c: smoothstreamingenc: Add a more verbose error message [11:43] <cone-49> ffmpeg.git 3Anton Khirnov 7doc/RELEASE_NOTES: doc/RELEASE_NOTES: update for the 9 release. [11:43] <cone-49> ffmpeg.git 3Mans Rullgard 7libavutil/parseutils.c: parseutils: fix parsing of invalid alpha values [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavformat/ffmdec.c libavformat/ffmenc.c tests/ref/lavf/ffm: ffm: do not write or read the audio sample format [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/vorbisenc.c: vorbisenc: use float planar sample format [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/libmp3lame.c: libmp3lame: use planar sample formats [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/libvorbis.c: libvorbis: use planar sample format [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/adpcmenc.c: adpcm_ima_wav: simplify encoding [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/adpcmenc.c: adpcmenc: fix 3 instances of variable shadowing [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/adpcmenc.c: adpcmenc: move 'ch' variable to higher scope [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/adpcmenc.c: adpcmenc: use planar sample format for adpcm_ima_wav and adpcm_ima_qt [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/aacenc.c: aacenc: use planar sample format [11:43] <cone-49> ffmpeg.git 3Justin Ruggles 7libavcodec/ac3enc_fixed.c libavcodec/ac3enc_float.c libavcodec/ac3enc_template.c libavcodec/eac3enc.c: (e)ac3enc: use planar sample format [12:02] <cone-49> ffmpeg.git 3Michael Niedermayer s537ef8bebf8a 7libavformat/movenc.c libavformat/movenc.h: movenc: support an alternative to edit lists to handle the first DTS != 0 case. [12:03] <thresh> michaelni: like that? [12:04] <michaelni> thresh, hmm s537ef8bebf8a doesnt work 537ef8bebf8a does [12:04] <thresh> oups, indeed [12:04] <michaelni> otherwise it looks fine [12:05] <thresh> sweet [12:12] <nevcairiel> s is obviously not a char valid in a hex hash :p [12:53] <cone-49> ffmpeg.git 3Michael Niedermayer 87244c8f2015 7libavformat/matroskaenc.c: matroskaenc: remove MATROSKA_ID_VIDEODISPLAYUNIT 3 [12:56] <thresh> nevcairiel: yeah, it was a leftover I had when copy-pasting message template into ffmpeg.git update hook. [13:47] <burek> one unusual use case question :) would using: "ffmpeg -i input -map 0 -c copy -vcodec libx264 ..." cause all the streams to be copied except the videos, which would be re-encoded? [13:47] <burek> the point is in using "-c copy -c:v <codec>" [13:48] <burek> was it designed this way at all? [14:04] <burek> Daemon404, ubitux, JEEBsv, etc.. can you please check #ffmpeg and advise a guy accordingly [15:31] <ubitux> Daemon404: how does the metadata work in *synth? [15:31] <ubitux> should we consider some communication channel such as dbus or something? or just associate some AVDictionary with each bufferref? [15:34] <ubitux> saste: the logger you're talking would be some kind of logging callback? [15:34] <ubitux> talking about* [15:34] <saste> yes [15:34] <saste> ubitx: dbus?? [15:34] <saste> no please don't [15:34] <ubitux> :) [15:35] <ubitux> how would you configure the logging callback? [15:35] <saste> metadata injection was implemented with a simple AVDictionary in the buffer [15:35] <saste> opaque [15:35] <ubitux> and how would you use it to make our filters communicate between then? [15:35] <ubitux> them* [15:35] <saste> through the evil opaque field [15:35] <ubitux> mmh [15:36] <saste> opaque could be used to define a callback [15:36] <saste> communication: several flavours [15:36] <saste> metadata or commands [15:36] <saste> and a combination of them [15:36] <saste> for example your filter processes metadata, and send a command to another filter [15:36] <saste> the filter receive a command, and send metadata [15:37] <saste> the exact interaction depends on the tackled problem [15:38] <ubitux> i see two problems to solve: making our own filters re-use information from the previous one (like -af ebur128,volume), and make some metadata available for lavfi user (like the silencedetect filter mentioned) [15:39] <ubitux> mpf, afk for a while, i'll be back in a few minutes [15:45] <saste> ubitux, i already replied [15:45] <saste> re-use information: you write metadata in the buffer, the next filter reads it, process it [15:46] <saste> export metadata: you may have a metadata sink, which prints the metadata (or logs it, or sends it, or speaks it, etc.) [15:53] <ubitux> yep right ok [16:00] <ubitux> speak sink filter, yay :D [18:17] <durandal_1707> i get segv in avfilter when checking decoder for robustness [18:17] <durandal_1707> is runtime switching between channel number supported? [18:35] <durandal_1707> is it allowed for decoder to change number or channels in decode_frame? [18:39] <michaelni> yes, a decoder can do that [18:40] <nevcairiel> yeah quite some decoders do that, doesnt mean lavfi can deal with that, though :) [18:40] <durandal_1707> but without using get_side_data stuff? [18:40] <michaelni> no need for side data [18:41] <durandal_1707> than why i get segfault, codecs get 10 channels, and i get segfault when copying stuff to frame.data[] [18:42] <michaelni> hmm you arent changing channels in the demuxer ? the decoder can the demuxer cannot directly (would be a race) [18:42] <nevcairiel> for more then 8, you need to use frame.extended_data [18:42] <michaelni> yes that too [18:42] <durandal_1707> aww!! [18:43] <michaelni> and extended data is poorly tested so it may have bugs [19:07] <burek> just to say, I'm not sure if the guy has created a new ticket or just uploaded a sample media file (Love Thy Brother.m4v) to ffmpeg's ftp server, but if he didn't create an appropriate ticket, then this is the post related to that file: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=695&p=1030 [19:08] <burek> I'm not sure should I create the ticket or ask him to create the ticket [19:43] <cone-223> ffmpeg.git 3Michael Niedermayer 1822aee7e6d9 7libavcodec/dsputil_template.c: dsputil_template: replace assert() by av_assert2() [19:43] <cone-223> ffmpeg.git 3Michael Niedermayer 979b9b1f470a 7libavcodec/h264.c: h264: switch some asserts to av_assert1/2() [20:00] <cone-223> ffmpeg.git 3Paul B Mahol 27a341518e91 7libavformat/avformat.h: avformat: fix typo in comment [20:58] <nevcairiel> hm, how does one flush any remaining frames out of a lavfi filter graph? right now my yadif is "losing" the last frame, because i don't flush it out, but i couldnt directly find a way how to [21:00] <Compn> burek : just create the ticket for him [21:00] <Compn> if he makes another we can merge/close whichever [21:00] <Compn> rather have dup tix than no-tix [21:07] <ubitux> Daemon404: hey we have some nice filters! [21:08] <ubitux> :( [21:10] <Daemon404> where? [21:10] <Daemon404> audio? yes. [21:10] <Daemon404> video? no. [21:10] Action: michaelni like his mandelbrot filter ;) [21:10] <ubitux> overlay, select, tile, life :D [21:10] <ubitux> ebur128 \o/ [21:11] <ubitux> (ass!) [21:11] <Daemon404> [15:10] <@ubitux> overlay, select, tile, life :D <-- all in avs and vs in betetr capacities [21:11] <Daemon404> and ass STARTED as an avs plugin [21:11] <ubitux> life in avs? [21:11] <Daemon404> ebur128 might be useful [21:11] <Daemon404> what is it? [21:11] <ubitux> ffplay -f lavfi life=s=300x200:mold=10:r=60:ratio=0.1:death_color=#C83232:life_color=#00ff00,scale=1200:800:flags=16 [21:11] <ubitux> now what! [21:11] <Daemon404> also mandelbrot [21:11] <Daemon404> isnt really, like [21:11] <Daemon404> useful. [21:12] <ubitux> pff :( [21:12] <ubitux> deshake should be improved [21:12] <ubitux> Daemon404: we have showspectrum/showwaves too which are kind of nice [21:12] <Daemon404> deshake as a better version of itself [21:12] <Daemon404> which is foss [21:12] <Daemon404> but not gpl compatible [21:13] <Daemon404> :/ [21:13] <ubitux> showinfo filters are nice too [21:13] <Daemon404> also existed in every otehr framework [21:13] <ubitux> + as you said, audio. [21:13] <Daemon404> everything you have mentioned as existed in avs (and now vs) for almost 10 years [21:14] <ubitux> (ah and testsrc e) [21:14] <Daemon404> yes, audio i have no alternative to [21:14] <Daemon404> i should have made it clear i was talkign about video [21:14] <ubitux> lavfi is kind of nice to deal with multiple and different inputs & outputs types [21:15] <Daemon404> not really better than anything else [21:16] <ubitux> ./ffplay -f lavfi -i 'testsrc,hue=H=2*PI*t:s=sin(2*PI*t)+1' e [21:17] <ubitux> 21:11:21 <@Daemon404> ebur128 might be useful [21:17] <ubitux> 21:11:24 <@Daemon404> what is it? [21:17] <burek> Compn ok [21:17] <ubitux> loudness thing [21:17] <Daemon404> right [21:17] <Daemon404> audio [21:17] <ubitux> audio 2 video to be exact [21:17] <ubitux> ffplay -f lavfi -i "amovie=input.mp3,ebur128=video=1:meter=18 [out0][out1]" [21:18] <ubitux> IMO the biggest problem right now is the metadata [21:18] <ubitux> but according to saste it should be fixable without much effort [21:18] Action: michaelni wonders if theres another filterframwork than libavfilter thst can be used allocate buffers that can be used as internal buffers for a decoders like h264 [21:19] <michaelni> that is direct rendering / avoiding memcpies [21:21] <Daemon404> i dont think anythign sane would do that [21:21] <Daemon404> thats needlessly coupled with a decoder [21:21] <Daemon404> and is messy [21:21] <Daemon404> also it's nto the bottleneck [21:21] <Daemon404> filtering is [21:21] <Daemon404> so it really is irrelevant [21:22] <Daemon404> come to think of it, ffms2 might decode directly into avs's buffer [21:23] <michaelni> so you are saying its doing something messy and irrelevant ? [21:23] <Daemon404> it's micro-optimizationt [21:23] <Daemon404> athat im willign to be, when filtering, has very little benefit [21:23] <Daemon404> with teh cost of coupling libarries to one another [21:25] <michaelni> theres no coupling though [21:26] <michaelni> its just using the get/release buffer callbacks of the decoder [21:26] <Daemon404> i need to check [21:26] <Daemon404> i think avs and vs can do this [21:26] <Daemon404> with input plugins [21:26] <Daemon404> it should be entirely possible [21:26] <Daemon404> i was mistaken abotu what you meant before [21:26] <Daemon404> apologies. [21:36] <Daemon404> michaelni, i think i semi-agree with paul about the boatloads of packed yuv stuff being put in decoders [21:37] <Daemon404> at the very least i think all the vXXX decoders should be in one file [21:37] <Daemon404> its geting out of hand.. [21:37] Action: Daemon404 can volunteer to do it, if he wont get flamed [21:37] <Compn> which decoders would you merge together ? [21:38] <Daemon404> v<numbers>.c [21:38] <Compn> ah [21:39] Action: michaelni has no plans to flame [21:40] <Compn> might want to see what carl thinks :P [21:40] <Daemon404> i dont think hell mind [21:40] <Daemon404> but i can ask [21:40] <Compn> always good to ask authors / maintainers [21:40] <Daemon404> were adding a huge number of packed formats to libavcodec [21:40] <Daemon404> its pretty ugly [21:56] <Daemon404> looks liek avs would handle direct render perfectly fine [22:30] <cone-223> ffmpeg.git 3Justin Ruggles d58b25aaa261 7libavcodec/adpcmenc.c: adpcmenc: ensure calls to adpcm_ima_compress_sample() are in the right order [22:30] <Daemon404> \o/ [22:45] <michaelni> Daemon404, well compressed (0.1k) ---> 1007 22:07 Buitenhuis, Der (0.1K) Public Key for FATE [22:46] <Daemon404> compressed? [22:46] <michaelni> there is no attachment [22:47] <Daemon404> uh [22:47] <Daemon404> yeah im awesome [22:47] <Daemon404> let me resend that [22:47] <nevcairiel> is it just me, or is that something everyone screws up at least once every other week? :d [22:48] <Daemon404> sent [22:49] <michaelni> Daemon404, i confirm reception, you need to wait for baptiste though, his admin powers are needed to add keys [22:50] <Daemon404> k [23:34] <cone-223> ffmpeg.git 3Michael Niedermayer f9b0694cc8ff 7libavcodec/motion-test.c: motion-test: fix height parameter [23:34] <cone-223> ffmpeg.git 3Michael Niedermayer 2714e841bcfd 7libavcodec/x86/motion_est.c: x86/motion_est: assert->av_assert2() [23:34] <cone-223> ffmpeg.git 3Michael Niedermayer f2a7e1a62b6d 7libavformat/mux.c: mux: change 1 assert->av_assert1() [00:00] --- Mon Oct 8 2012

1 0

ffmpeg.log.20121007
by burek 08 Oct '12

08 Oct '12

[04:26] <whiplash> hey guys [04:27] <whiplash> got a question here, not exactly related to ffmpeg but i thought you guys might be able to help [04:27] <whiplash> i'm trying to write a vfw codec that utilizes intel's quick sync feature [04:27] <whiplash> and i'm having trouble building the encoder example [04:28] <whiplash> this is the sdk: http://software.intel.com/en-us/vcsource/tools/media-sdk [04:28] <whiplash> according to the documentation, it should be built using vs2012 on windows 8 [04:54] <thevdude> :/ I've got an mp4 video and I'm trying to cut a short section out. The video has aac audio and h264 video, and apparently I want to split it off of an I frame (whatever that is), so setting -vcodec h264 works fine for that (and the video starts where I want it to), but the audio seems to be playing from that I Frame instead. [04:55] <thevdude> I'm doing -acodec aac and setting the other settings to match the old one [04:55] <thevdude> trying -async 1 now [04:56] <thevdude> audio matches up at about 4seconds in, but is missing before that :/ [05:28] <qeed> hi, im using ffmpeg to encode some image files into a video, ffmpeg -f image2 -r 1 -i pix/%03d.png -target ntsc-dvd -aspect 4:3 out.mpg the command im using [05:28] <qeed> for some reason some of the png files is opened but skipped and not encoded [05:28] <qeed> (from what i see from strace) is there a reason how that can be? [05:29] <qeed> i looked at the images being skipped, the dimensions to them are bigger than the ones that are encoded 3264 x 2448 [05:29] <qeed> other than the dimension it the png encoding is the same [05:46] <nachii> hello [05:46] <nachii> i have a problem with a video h264 [05:46] <nachii> can somebody help me? [05:48] <nachii> can anybody help me? [05:48] <nachii> http://pastebin.com/HtWy1CSi [05:48] <nachii> there it is the line i use and the reslt [05:48] <nachii> result [05:58] <nachii> please anyone? [06:03] <nachii> can anybody help me? [06:03] <nachii> i have a problem with a video h264 [06:03] <nachii> http://pastebin.com/HtWy1CSi [06:03] <nachii> there it is the line i use and the result [06:05] <qeed> i found some online answers saying it has to be the same size, so i guess i need to resize them [06:33] <brimestone> Im getting a weird result when i add -timecode my footage end up 5 times longer than it should.. [11:11] <Marlinc> Is it possible to get [11:11] <Marlinc> frame= 23 fps= 5 q=23.9 Lsize= 813kB time=6.60 bitrate=1008.9kbits/s [11:11] <Marlinc> Is it possible to get [11:11] <Marlinc> More frequent?* [13:43] <burek> Marlinc, what exactly are you trying to accomplish? [13:44] <burek> can you provide a pastebin of your command line + output? [13:45] <burek> thevdude can you please use a pastebin site (like www.pastebin.com) to show your ffmpeg command and the complete console output? [13:52] <Marlinc> ffmpeg -y -f x11grab -i 1300x744|:0.0+65,24 -r 60 -s 2806x900 -b 50k -minrate 50k -maxrate 50k -bufsize 1835k -vcodec libx264 -f flv hoi.flv [13:52] <Marlinc> brb [13:53] <Marlinc> Back [13:53] <Marlinc> burek, ^ [13:54] <burek> are you sure this is valid "-f x11grab -i 1300x744|:0.0+65,24" [13:54] <burek> http://ffmpeg.org/ffmpeg.html#x11grab [13:55] <burek> maybe you wanted to say something like this: -f x11grab -s 1300x744 -i :0.0+65,24 [13:56] <Marlinc> I thought the same [13:56] <burek> unless your 'hostname' is actually named '1300x744|' [13:56] <burek> which is not likely [13:56] <Marlinc> But okay [13:57] <Marlinc> My question was about the " frame= 23 fps= 5 q=23.9 Lsize= 813kB time=6.60 bitrate=1008.9kbits/s" messages [13:57] <burek> Marlinc can you please use a pastebin site (like www.pastebin.com) to show your ffmpeg command and the complete console output? [13:58] <Marlinc> https://gist.github.com/08b41b27125186e90d05 [13:59] <burek> you are not using ffmpeg [13:59] <Marlinc> apparently avconv is the same as ffmpeg [13:59] <Marlinc> According to the ffmpeg command [14:00] <burek> if it was, you would be using ffmpeg [14:00] <burek> go to libav support channels and ask there for the support [14:00] <burek> it's just a fork project of ffmpeg [14:00] <Marlinc> The ffmpeg command saids that ffmpeg is deprecated [14:00] <burek> ubitux :) [14:00] <Marlinc> And that I should use avconv [14:00] <burek> we should really create that wiki page [14:00] <Marlinc> *** THIS PROGRAM IS DEPRECATED *** [14:00] <Marlinc> This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. [14:00] <burek> that explains all the mess that debian/ubuntu maintainers have created.. [14:01] <burek> Marlinc, long story short [14:01] <Marlinc> I see... [14:01] <burek> that's a lie.. [14:01] <burek> sadly.. [14:01] <Marlinc> Okay.. [14:01] <burek> they forked ffmpeg project and wanted all people to just forget about ffmpeg [14:01] <burek> just like it never existed [14:01] <burek> can't help much about that [14:01] <burek> but if you install ffmpeg I might help [14:01] <Marlinc> Okay that's pretty sad [14:01] <burek> until then, you'll have to ask there [14:02] <burek> i know.. [14:02] <Marlinc> As far as I know I have ffmpeg installed [14:02] <burek> we will soon create a page where people will be able to get ffmpeg deb package from [14:02] <Marlinc> Okay [14:02] <burek> but until then, you'll just have to compile it from source.. [14:02] <Marlinc> So [14:02] <Marlinc> I'm creating a software package [14:02] <Marlinc> That uses ffmpeg (or avconv) [14:03] <Marlinc> And I would like to use the apt software manager for Ubuntu [14:03] <Marlinc> So using debs [14:03] <Marlinc> As a way to distribute the software [14:04] <Marlinc> Does the matter if I specify ffmpeg as dependency? [14:04] <Marlinc> Because it looks like it installs avconv if that's what you're saying [14:05] <burek> you might join #ffmpeg-devel and ask there, because it's kinda mess right now with debian/ubuntu [14:05] <burek> so to get the precise answer [14:05] <burek> you would need to ask developers for advice [14:06] <Marlinc> Damn [14:06] <Marlinc> Are there bug differences? [14:06] <Marlinc> Big* [14:06] <burek> obviously :) [14:06] <Marlinc> Can I use ffmpeg and avconv with the same arguments? [14:06] <burek> I wouldn't know, since I don't use avconv, so, I dunno really.. [14:07] <Marlinc> Okay [14:07] <Marlinc> But okay is it possible in ffmpeg [14:07] <Marlinc> To get the " frame= 23 fps= 5 q=23.9 Lsize= 813kB time=6.60 bitrate=1008.9kbits/s" messages more frequently [14:07] <Marlinc> I'm assuming ffmpeg has it too? [14:08] <burek> why do you need those log messages more frequent? [14:08] <Marlinc> Because I'm using the fps and frame parts in my application [14:09] <Marlinc> I'm trying to make a indicator that activates if the fps drops or the amount of frames get slowed down [14:09] <burek> maybe -log_level 99 ? [14:09] <Marlinc> And I can't really create a accurate indicator if I don't get the frame amount that often [14:09] <burek> did you check the docs? [14:09] <Marlinc> Yes but I didn't know that to look for [14:10] <Marlinc> I did use the man page [14:10] <Marlinc> brb [14:12] <King_Rat> could anyone give me some help with using x11grab for fullscreen wine windows? [14:12] <Marlinc> back [14:12] <King_Rat> i dont really have a clue how fullscreen programs like that work [14:13] <Marlinc> Unrecognized option 'log_level' [14:13] <Marlinc> Failed to set value '99' for option 'log_level' [14:13] <Marlinc> :p [14:13] <Marlinc> burek, ^ [14:13] <burek> it's not ffmpeg.. [14:14] <King_Rat> do any of x's numerous little tools allow you to list all displays? [14:14] <burek> maybe -loglevel [14:14] <burek> instead of log_level [14:14] <burek> or something [14:14] <Marlinc> O yes.. [14:14] <burek> Marlinc: http://ffmpeg.org/ffmpeg.html [14:14] <burek> ctrl+f loglevel [14:14] <Marlinc> I thought I changed the command but yes.. Ubuntu uses avconv [14:15] <Marlinc> What mess [14:15] <burek> King_Rat: https://ffmpeg.org/trac/ffmpeg/wiki/How%20to%20grab%20the%20desktop%20(scre… [14:15] <Marlinc> Is it possible to provide a binary with my software? [14:15] <Marlinc> Or would it cause library problems [14:16] <burek> Marlinc, if you're asking for licensing stuff or so, read here: http://ffmpeg.org/legal.html [14:16] <burek> for libs dependencies and stuff, please ask in #ffmpeg-devel, since I can't help a lot with it [14:16] <Marlinc> Okay [14:16] <King_Rat> when I try and capture in fullscreen everything goes black [14:17] <Marlinc> Really realizing this software is getting harder and harder [14:17] <m3thyl> when creating a video from from images, with an explicit video size (i.e "-s WxH"), is there a way to have the image preserve its aspect while fitting within the boundaries of the video (the images are resizing to WxH, but don't necessarily have a W:H aspect ratio) [14:18] <burek> m3thyl you might use pad filter [14:18] <burek> http://ffmpeg.org/ffmpeg.html#pad [14:18] <burek> King_Rat can you please use a pastebin site (like www.pastebin.com) to show your ffmpeg command and the complete console output? [14:19] <m3thyl> ok; i was looking at that but was wondering if ffmpeg could do the calculations for me; thanks [14:19] <burek> Marlinc, at least it's never boring :) [14:19] <King_Rat> wait, i'll brb in 10 minutes or so [14:19] <burek> m3thyl, it can, just take a look at examples [14:19] <m3thyl> alright [14:36] <Marlinc> burek, https://gist.github.com/a830ddb9d1038367bacb [14:36] <Marlinc> Whats the difference between the two frame amounts [14:37] <Marlinc> One says 281 and the other says 323 [14:38] <burek> shevy, did you try: ffmpeg -i input.mpg -map 0 -c copy -c:v libx264 -crf 25 -preset slow output.mp4 [14:39] <burek> Marlinc one is reported by ffmpeg (that is calling the libx264 lib) and another is the output of the libx264 lib itself [14:39] <burek> the timing of those 2 is what makes it different [14:39] <Marlinc> Okay.. [14:40] <burek> (I guess) [14:40] <burek> btw, if you need that accuracy, why don't you code your own libav* wrapper [14:40] <burek> instead of using cmd line [14:41] <burek> or modify ffmpeg to display that log line more frequently and recompile it again [14:41] <Marlinc> I'm using Java because it makes it easier to make it cross-platform [14:41] <shevy> burek not yet, will try, thanks [14:41] <burek> and java is calling ffmpeg? [14:41] <burek> shevy :beer: :) [14:41] <shevy> hehe [14:41] <Marlinc> Yes at the moment I'm using the ProcessBuilder class from Java [14:42] <burek> that means you'll expect from the end-users to have to install ffmpeg on their computer prior to using your app? [14:43] <Marlinc> I'll let the application download it I think [14:43] <Marlinc> Or provide it in the package [14:43] <Marlinc> For Ubuntu I can simply add a dependency to the deb file [14:43] <burek> if you provide it in the package, you'll have to know the target platform before you pack it [14:43] <Marlinc> I know [14:43] <burek> to know which ffmpeg binary to pack (exe, elf, etc) [14:44] <Marlinc> But I already need to that because of SWT (the window library I'm using) [14:44] <burek> also, I think, legally, you'll have some issues if you "just pack ffmpeg binary" into your app package [14:45] <Marlinc> Then I think I should do the same as ffsplit [14:45] <burek> did you read this already: http://ffmpeg.org/legal.html [14:45] <burek> it might help [14:45] <Marlinc> Okay [14:45] <burek> just so you don't waste time on something that will end up like not recommended approach anyway [14:46] <Marlinc> Yes I would need some help with that [14:48] <Marlinc> But okay [14:49] <Marlinc> I'm running the ffmpeg library quite literally [14:49] <Marlinc> The application just provides the right arguments [14:50] <burek> you mean binary? [14:51] <ubitux> burek: still need help? [14:51] <burek> always :) [14:51] <Marlinc> binary yes [14:51] <Marlinc> Sorry [14:52] <ubitux> i guess i'll have to backlog? [14:52] <burek> Marlinc is one of those debian/ubuntu users [14:52] <burek> who were affected by avconv and stuff [14:52] <burek> so, in order not to advise him badly, I've asked you (and others) to suggest Marlinc what should he do [14:52] <Marlinc> Jup.. [14:53] <ubitux> does the static build solve his problem? [14:53] <Marlinc> You're asking burek right? [14:54] <ubitux> yeah but talking about you :p [14:54] <Marlinc> :p [14:54] <burek> I didn't advise him to use static build, as I didn't know what exactly is his use case [14:54] <ubitux> Marlinc: did you try the static build? :) [14:54] <Marlinc> Nope [14:54] <ubitux> ok ok well, i just woke up, give me a few minutes i'll backlog [14:54] <burek> ok :) [14:54] <Marlinc> I just heard about the difference between avconv and ffmpeg [14:55] <Marlinc> I though it was the same so I could just use the Ubuntu package and have the same results on other platforms using ffmpeg itself [14:58] <ubitux> ok well, first i don't even understand what the problem is [14:58] <ubitux> Marlinc: do you mind explaining again what's not working? [14:59] <Marlinc> There wasn't really a problem [14:59] <Marlinc> More of a question [14:59] <Marlinc> I'm using the "frame= 323 fps= 10 q=69.0 size= 192kB time=27.65 bitrate= 56.8kbits/s" messages to provide some useful information in my application [14:59] <Marlinc> But because it only shows op like one's a second? [15:00] <Marlinc> I can't really provider accurate data [15:00] <Marlinc> Provide* [15:00] <Marlinc> So my original question if it is possible to get those status messages more often [15:01] <Marlinc> So my original question was if it is possible to get those status messages more often [15:01] <ubitux> check if the -progress option has a higer rate [15:01] <ubitux> higher* [15:02] <Marlinc> Okay thanks [15:02] <Marlinc> I didn't know what to look for [15:02] <Marlinc> So thats why I came here [15:02] <ubitux> it might be the same, but it looks easier to exploit for apps than the cmd output you're pasting [15:03] <ubitux> i never used it so well.. [15:03] <ubitux> anyway, i'm not sure it's available in the fork [15:03] <ubitux> so if not [15:03] <Marlinc> Okay thanks [15:03] <ubitux> you can try this ^ [15:03] <Marlinc> Is it allowed to provide the binary package with my application? [15:03] <ubitux> and check if it helps with your problem [15:03] <ubitux> it depends [15:04] <Marlinc> It isn't commercial [15:04] <ubitux> is the source code available? [15:04] <Marlinc> Fully open-source [15:04] <ubitux> it also depends if you build ffmpeg with --enable-gpl or no [15:05] <Marlinc> I read about some license problems with libx264? [15:05] <Marlinc> On the legal page [15:05] <ubitux> as well as if you build it with --enable-nonfree and stuff like that [15:05] <Marlinc> Because I do need libx264 [15:05] <ubitux> i'm not sure, but afaict, the safe choice is to have your app under GPL [15:06] <ubitux> but i'm not a lawyer so.. [15:06] <Marlinc> But one moment going to take a look at the progress option [15:07] <ubitux> mmh afaict it seems the progress rate is also 1 second [15:09] <ubitux> do you really need a higher rate? [15:09] <Marlinc> I'm trying to make a indicator so the user of the application can listen to the amount of FPS he has [15:09] <Marlinc> While in game [15:10] <Marlinc> So he can hear what happens to the FPS when he is in game [15:10] <Marlinc> Without looking at the application [15:10] <ubitux> huh? [15:11] <Marlinc> How do I explain it [15:11] <Marlinc> When in game you can't see the FPS of ffmpeg right? [15:11] <Marlinc> Because your games window is in front of it [15:12] <Marlinc> You can't see ffmpeg and you can't see my application that runs ffmpeg [15:12] <Marlinc> Okay? [15:12] <ubitux> yeah right ok [15:12] <ubitux> and then why ~1 second is not fast enough? [15:12] <Marlinc> My application makes a sound every 50 frames or so [15:13] <Marlinc> So the use can sort of listen to the speed of the frames [15:13] <Marlinc> So the user can sort of listen to the speed of the frames [15:13] <Marlinc> Sometimes it doesn't work correctly because there is to much time between progress update [15:14] <ubitux> well, increasing the rate will likely slowdown the processssssssss [15:14] <ubitux> oups [15:14] <Marlinc> Could have various reasons one being the FPS goes very high. Higher then 50 fps and thus missing a beep [15:14] <ubitux> progress* [15:14] <Marlinc> Really that much? [15:15] <ubitux> i'm not sure how much but well... [15:16] <ubitux> anyway, your approach looks weird [15:16] <Marlinc> I don't know what is does on the ffmpeg backend but isn't it just a message? [15:16] <ubitux> what would happen if you have a sound each 50 frames and ffmpeg was producing 50 frames each 0.0001 sec? [15:17] <Marlinc> That's not likely [15:17] <ubitux> why? [15:17] <Marlinc> It is for live streaming [15:17] <ubitux> ok [15:17] <ubitux> anyway, the fps is printed every second for obvious reason [15:18] <Marlinc> Pretty obvious indeed [15:18] <ubitux> since it counts the number of frame per second :p [15:18] <ubitux> another solution would be to use the api [15:18] <ubitux> and do something every 50 frames [15:18] <Marlinc> Okay [15:19] <Marlinc> Are there Java bindings for the API? [15:19] <ubitux> no [15:19] <ubitux> ah maybe you could trick with -vf showinfo [15:20] <Marlinc> What would that do? [15:20] <ubitux> and parse the n value [15:20] <Marlinc> Moment I'll try it [15:20] <Marlinc> See what it does [15:23] <Marlinc> How does it work ubitux ? [15:23] <burek> try ffmpeg -f lavfi -i testsrc -t 10 -vf showinfo -f null /dev/null [15:24] <burek> ffmpeg -f x11grab -i ... -vf showinfo -f null /dev/null [15:24] <ubitux> *"-f null -" is even simpler!) [15:24] <ubitux> ("-f null -" is even simpler!) [15:24] <burek> oh right [15:24] <Marlinc> Ah I see [15:25] <Marlinc> And n provides the frame? [15:25] <ubitux> it's the frame count [15:25] <Marlinc> Ah nice [15:25] <Marlinc> So I get info about every frame [15:26] <burek> http://ffmpeg.org/ffmpeg.html#showinfo [15:26] <ubitux> yes [15:26] <Marlinc> Thats I'll take a look [15:26] <Marlinc> Thanks* [15:28] <Marlinc> What did the -t option do? [15:28] <Marlinc> Time in seconds? [15:28] <burek> http://ffmpeg.org/ffmpeg.html#Main-options [15:28] <Marlinc> Ah [15:28] <Marlinc> Okay [15:29] <Marlinc> Thanks I'll see that I can do with this [17:12] <thevdude> It's been a while. My issue is that audio isn't starting from where I'm telling the video to start from when cutting a clip out, it's starting from the I frame before the cut. [17:14] <thevdude> command is ffmpeg -ss 00:05:13.0 -i ~/videos/to_trim.mp4 -vcodec h264 -acodec aac -ac 2 -ar 48000 -ab 225k -t 00:00:14.0 -strict -2 -y ~/videos/trimmed.mp4 and output is http://sprunge.us/ZjcS [17:18] <relaxed> thevdude: move the seek after the input, and -vcodec libx264 [17:18] <thevdude> :/ my video is fine, but I'll try it [17:18] <thevdude> the video is starting in the right place, the audio isn't. [17:18] <relaxed> add -async 1 [17:19] <thevdude> that makes the audio sync up after about 4 seconds [17:19] <thevdude> and makes grey frames show up at the start, let me try it with all the changes [17:19] <spaam> :D [17:22] <thevdude> holy poop it works [18:29] <Marlinc> So I just noticed that ffmpeg can run using pipes [18:29] <Marlinc> Is possible to have one output [18:29] <Marlinc> And multiple input processes [18:30] <Marlinc> And switch between multiple inputs so that something else appears on the output stream? [18:30] <Marlinc> If so can somebody push me in the right direction? [18:31] <Marlinc> burek, ubitux ? [18:33] <ubitux> i don't understand [18:34] <Marlinc> You can pipe video output from one process to the other right? [18:36] <ubitux> yes? [18:36] <ubitux> -f rawvideo -pix_fmt ... [18:37] <Marlinc> Okay [18:37] <Marlinc> So is it possible to switch between inputs? [18:39] <ubitux> i don't know what that means :p [18:40] <Marlinc> So I would have multiple ffmpeg [18:40] <ubitux> ffmpeg -i ... -i ... -i ... ? [18:40] <Marlinc> So I would have multiple ffmpeg's that read a file and put the output to stdout [18:40] <Marlinc> Okay? [18:40] <Marlinc> And one ffmpeg that reads the video from stdin [18:41] <ubitux> really i have a hard time figuring out what you want to achieve. [18:41] <Marlinc> I don't know how to explain it.. [18:42] <ubitux> describe what are your different inputs, and what's your output [18:42] <Marlinc> For example [18:42] <Marlinc> One ffmpeg captures my screen [18:42] <Marlinc> One captures a file [18:42] <Marlinc> And then I have a ffmpeg that reads from stdin and puts it on a livestream [18:42] <Marlinc> See where I'm going? [18:43] <ubitux> how do you want to merge those 3 inputs? [18:43] <ubitux> you want one livestream out of these 3? [18:43] <Marlinc> Yes but I don't want to merge [18:43] <Marlinc> I want to be able to select which one gets send to the livestream [18:43] <Marlinc> And switch between them without stopping the streaming [18:44] <ubitux> i'd say you would push to 3 ffm streams on a ffserver and let the user decide which one to lurk [18:44] <ubitux> otherwise i dunno [18:45] <ubitux> with the api most likely [18:45] <ubitux> with the tool dunno [18:45] <Marlinc> Okay okay.. [18:45] <Marlinc> I think I'm just going try some things and see what it does [18:47] <klaxa> quick question, how do i apply the fade video filter correctly? as of now it isn't giving me any results here's the ffmpeg output and input: http://pastebin.com/9cG4txEH [18:49] <ubitux> works for me, and it should start fading around frame 960 [18:49] <ubitux> with your cmd line [18:50] <klaxa> ah fuck... that was my bad the video has 900 frames :P [18:51] <ubitux> it should do something like what you get with ./ffplay -f lavfi -i testsrc -vf fade=out:50:40 [18:51] <ubitux> (at 2 seconds) [18:51] <ubitux> (25 fps) [18:54] <klaxa> yes works perfectly, was totally me being stupid [18:54] <ubitux> klaxa: btw, sameq doesn't mean sameq [18:55] <ubitux> same quality* [18:55] <ubitux> :) [18:55] <ubitux> also, why do you select mpeg4 codec? [18:58] <burek> ubitux, could 'select' video filter maybe be upgraded so that it supports selecting an input stream (just like -map does) based on some criteria [18:58] <burek> that could solve the switching input's problem :) [19:01] <ubitux> someone could write a streamselect right :) [19:01] <ubitux> could be fun [19:01] <ubitux> shouldn't be that hard [19:01] <ubitux> maybe there are some problem between framerate or resolution mismatch [19:02] <burek> yes but it can always spit out an error and refuse to play along if prerequisites are not met :) [19:03] <burek> it would be like watching the tv :) [19:03] <ubitux> you tv spit out errors? [19:03] <ubitux> your* [19:03] <ubitux> i'm not willing to write such filter anyway [19:03] <ubitux> but yeah, that could be done [19:04] <burek> I was just asking if it would be too much of work, so that I know if it makes sense to write a feature request :) [19:05] <ubitux> could make sense yes [19:07] <klaxa> <@ubitux> also, why do you select mpeg4 codec? <-- because the video will be played on a machine i don't know, i don't want it to lag, quality is good enough, i didn't notice any artifacts [19:09] <ubitux> ok [19:42] <thevdude> http://www.youtube.com/watch?v=9JsDU3CuWNs this is what you guys helped me do. <3 thanks. [19:44] <ubitux> is it me or most of the sound is on the left channeL? [20:50] <shevy> Codec is experimental but experimental codecs are not enabled, try -strict -2 [20:50] <shevy> ^^^ Anyone knows how to enable experimental codecs? so I can omit typing -strict -2 [20:50] <shevy> is from converting a .flv to .mp4 [21:15] <burek> shevy, why do you need to omit -strict -2 [21:15] <burek> or -strict experimental (same thing) [21:24] <shevy> burek I dunno, it seems to be not useful for me to type it [21:26] <shevy> I suppose there is no configure option to allow this [21:26] <shevy> (I compile ffmpeg from source usually) [21:35] <burek> it's not a configure option [21:35] <burek> but cmd line option [21:37] <klaxa> why not just alias ffmpeg in your .bashrc (or whatever shell you are using) [21:58] <nachii> hello, can anybody help encoding mp4 to flv? i am getting an error [21:58] <nachii> i can past it in paste bin [00:00] --- Mon Oct 8 2012

1 0

ffmpeg-devel.log.20121006
by burek 07 Oct '12

07 Oct '12

[00:01] <cone-429> ffmpeg.git 3Stefano Sabatini 7Changelog doc/ffprobe.texi ffprobe.c: ffprobe: add -select_streams option [00:01] <cone-429> ffmpeg.git 3Stefano Sabatini 7ffprobe.c: ffprobe: reindent after previous commit [00:06] <cone-429> ffmpeg.git 3Stefano Sabatini 7Changelog: Changelog: add empty line after version lines [00:20] <Daemon404> durandal_1707, pelase refrain from giving such useless reviews [00:21] <durandal_1707> Daemon404: not useless [00:21] <Daemon404> "I do not like this." [00:21] <Daemon404> useless [00:21] <Daemon404> as [00:21] <Daemon404> fuck [00:21] <durandal_1707> _not_ useless [00:22] <Daemon404> how [00:22] <Daemon404> on earth is that useful [00:22] <Daemon404> do explain [00:22] <Daemon404> im all ears [00:22] <Daemon404> maybe he should use telepathy [00:22] <Daemon404> to figure out whats wrong [00:22] <Daemon404> and why you dont like it [00:23] <JEEB> "I do not like this." <- always try to give at least some kind of a reasoning [00:23] <JEEB> otherwise it's as useless as a spit on a face [00:23] <JEEB> and leads to "OK, so he doesn't like it. How can I fix it?" [00:24] <JEEB> instead of "OK, X could be done better." [00:24] <durandal_1707> people are just ignorant [00:24] <Daemon404> it soudns mroe liek youre jus ta ragain asshole [00:24] <Daemon404> let me restate that without typos: [00:24] <Daemon404> youre an asshole. [00:24] <burek> it's never boring here :) [00:24] <JEEB> durandal_1707, it might be clear to you why something's bad [00:25] <JEEB> but it might not be for the other person [00:25] <JEEB> tl;dr explain it [00:25] <durandal_1707> Daemon404: thank you for so kind words [00:25] <Daemon404> im doing my paul b mahol impression [00:25] <Daemon404> i hope you like it [00:26] <Daemon404> (but if you dont, feel free to say so. but not why.) [00:28] <saste> Daemon404, moderate terms [00:28] <saste> you made your point, no need to give names [00:28] <saste> blame the attitude, not the person [00:28] <Daemon404> saste, youre right [00:34] <gnafu> "<@Daemon404> it soudns mroe liek youre jus ta ragain asshole" <-- I like how you only spelled one word right, and it was the most important word. It kinds adds emphasis in its own, "he must be drunk or something" kinda way ;D. [00:34] <nevcairiel> "it" is also spelled correctly! [00:34] Action: Daemon404 looks at the beer on his desk [00:34] <gnafu> nevcairiel: Yeah, but that's too short to count :-D. [00:35] <Daemon404> i spell 'it' wrong all the time [00:35] <nevcairiel> hey he screwed up shorter words in that sentence [00:35] <Daemon404> as 'i' [00:35] <gnafu> Daemon404: I had a friend from Canada who only typed correctly when he /was/ drunk. [00:35] <Daemon404> we call them newfies [00:35] <gnafu> XD [00:38] <saste> michaelni, I need something like 576 words for xface bigint [00:38] <saste> lavu/integer supports 8 words [00:39] <saste> should I extend the number, make it configurable or use a custom biginter implementation? [00:39] <saste> second option will break compatibility, but not that this would be a problem, since possibly nobody is (still) using it [00:40] <saste> ah and the author of the code (~1990) agreed to relicense the code [00:41] <Daemon404> this reminds me [00:41] <Daemon404> we can ditch x11grab [00:41] <Daemon404> vlc has xcbgrab [00:41] <Daemon404> whic his lgpl [00:41] <Daemon404> and also uses xck [00:41] <Daemon404> xdc* [00:41] <saste> Daemon404, patches welcome :) [00:41] <Daemon404> saste, that requires me to touch stuff related to X [00:41] <Daemon404> never. again. [00:42] <saste> i somewhat envy mplayer for x11 output [00:42] <saste> from time to time, people tries to reimplement X from scratch [00:42] <saste> i recall a nice project, it was called "Y" [00:43] <Daemon404> wayland sounds like it may become something [00:43] <Daemon404> its got people like keithp on it [00:46] <gnafu> It definitely has a lot of people and groups behind it. [00:46] <gnafu> It'll be interesting to see what happens. [00:46] <gnafu> I probably won't start using it until Fedora switches to it as the default (if that ever happens, which I would think it will). [00:47] <gnafu> I'm too lazy to do otherwise. [00:56] <michaelni> saste, what exactly is "bigint" needed for ? [00:56] <saste> it's used to store the image as a bit integer [00:56] <saste> image is a 48x48 bitmap [00:57] <saste> uhm no, wait when i'll be awake [00:57] <saste> but anyway, i may need to extend the number [00:58] <saste> but seems i can't count now [03:21] <cone-532> ffmpeg.git 3Michael Niedermayer 7libavcodec/ffv1.c: ffv1: remove commented asserts [03:21] <cone-532> ffmpeg.git 3Michael Niedermayer 7libavcodec/ffv1.c: ffv1: change w/h asserts to check as the condition can likely happen [03:33] <cone-532> ffmpeg.git 3Michael Niedermayer 7libavcodec/ffv1.c: ffv1enc: fix assert in put_vlc_symbol() and update to av_assert2() [05:08] <cone-532> ffmpeg.git 3Michael Niedermayer 7libavcodec/arm/mpegvideo_armv5te.c: mpegvideo_armv5te: change asserts to av_asserts [06:21] <cone-532> ffmpeg.git 3Carl Eugen Hoyos 7Changelog doc/general.texi libavcodec/Makefile libavcodec/allcodecs.c libavcodec/avcodec.h libavcodec/codec_desc.c libavcodec/targa_y216dec.c libavcodec/version.h libavformat/isom.c: Pinnacle TARGA CineWave YUV16 decoder (fourcc Y216). [12:15] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/libvorbisenc.c: libvorbisenc: fix afq delay setting [12:15] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavformat/segment.c: segment: reverse pass avoid_negative_ts from the muxer [12:53] <cone-191> ffmpeg.git 3Stefano Sabatini 7doc/filters.texi: doc/filters: fix typo [13:57] <cone-191> ffmpeg.git 3Anton Khirnov 7libavcodec/avcodec.h libavcodec/resample.c libavcodec/resample2.c libavcodec/version.h: lavc: deprecate the audio resampling API. [13:57] <cone-191> ffmpeg.git 3Anton Khirnov 7avplay.c libavfilter/af_asyncts.c libavfilter/af_resample.c libavresample/audio_data.c libavresample/audio_data.h libavresample/avresample-test.c libavresample/avresample.h libavresample/utils.c: lavr: change the type of the data buffers to uint8_t**. [13:57] <cone-191> ffmpeg.git 3Anton Khirnov 7doc/APIchanges libavresample/version.h: lavr: bump major to 1 and declare it stable. [13:57] <cone-191> ffmpeg.git 3Anton Khirnov 7doc/APIchanges: doc/APIchanges: fill in missing dates and hashes. [13:57] <cone-191> ffmpeg.git 3Dmitry Samonenko 7libavcodec/libspeexenc.c: libspeexenc: Add an option for enabling DTX [13:57] <cone-191> ffmpeg.git 3Dmitry Samonenko 7libavcodec/libspeexenc.c: libspeexenc: Updated commentary to reflect recent changes [13:57] <cone-191> ffmpeg.git 3Mans Rullgard 7libavcodec/x86/dsputil_mmx.c: x86: dsputil: kill VLA in gmc_mmx() [13:57] <cone-191> ffmpeg.git 3Mans Rullgard 7libavcodec/ppc/fmtconvert_altivec.c: ppc: fmtconvert: kill VLA in float_to_int16_interleave_altivec() [13:57] <cone-191> ffmpeg.git 3Mans Rullgard 7libswscale/ppc/swscale_altivec.c: ppc: swscale: rework yuv2planeX_altivec() [13:57] <cone-191> ffmpeg.git 3Mans Rullgard 7configure: build: error on variable-length arrays [13:57] <cone-191> ffmpeg.git 3Anton Khirnov 7libavfilter/vf_pad.c libavfilter/vf_scale.c: vf_pad/scale: use double precision for aspect ratios. [13:57] <cone-191> ffmpeg.git 3Diego Biurrun 7libavutil/parseutils.c: parseutils-test: Drop random colors from parsing test [13:57] <cone-191> ffmpeg.git 3Diego Biurrun 7tests/fate/libavutil.mak tests/ref/fate/parseutils: fate: Add parseutils test [13:57] <cone-191> ffmpeg.git 3Diego Biurrun 7: Give all anonymously typedeffed structs in headers a name [13:57] <cone-191> ffmpeg.git 3Anton Khirnov 7libavformat/yuv4mpeg.c: yuv4mpeg: return proper error codes. [13:57] <cone-191> ffmpeg.git 3Michael Niedermayer 7: Merge remote-tracking branch 'qatar/master' [13:57] <cone-191> ffmpeg.git 3Michael Niedermayer 7libswresample/swresample-test.c: swr-test: avoid VLA [14:07] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/snowenc.c: snowenc: get rid of VLA (well it wasnt really variable anyway) [14:07] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavutil/pca.c: pca: get rid of VLA [14:07] <cone-191> ffmpeg.git 3Michael Niedermayer 7configure: configure: enable -Werror=vla [15:02] <siretart> ubitux: yes, debian/stable still ships 0.5 [18:38] <cone-191> ffmpeg.git 3Bobby Bingham 7libavfilter/libmpcodecs/vf_tile.c: vf_tile: fix typos/grammar in comments [18:42] <ubitux> do we still need this filter? [20:23] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavformat/movenc.c: movenc: fix regression with yuyv caused by c5f23d [21:32] <saste> what's so awesome about sed?? [21:33] <ubitux> tetris.sed? [21:33] <ubitux> arkanoid.sed? [21:33] <Daemon404> nothing [21:33] <Daemon404> perl > sed [21:34] <saste> i mean what's so awesome about s/PIX_FMT/AV_PIX_FMT/ [21:35] <saste> apart from annoying michael at the next merge [21:35] <Daemon404> <insert rehtoric about poluting the namespace) [21:35] <Daemon404> ironically, when we added AV_ to the codec ids [21:35] <Daemon404> they added a #define CodecID [21:36] <Daemon404> which i had to udnefine in my downstream project [21:36] <saste> yes, but what's so awesome about cleanup? [21:36] <Daemon404> ... because they pollutedt he namespace [21:36] <saste> it's necessary, but is boring [21:36] <Daemon404> [15:36] <@saste> yes, but what's so awesome about cleanup? <-- as a downstream user, clean up is very welcome and i appreciate it [21:36] <Daemon404> since libav* libs have always been catastrophic messes [21:37] <saste> Daemon404, libav* mess is overrated [21:37] <Daemon404> i disagree [21:37] <saste> cleaner than most libs i know of [21:37] <Daemon404> if i didnt work on the libs themselves, using it work be even more horrible [21:37] <Daemon404> some stuff is still impossible with public api only [21:37] <saste> finding a lib which is really clean is hard, i challenge you [21:37] <Daemon404> its really fun [21:37] <Daemon404> [15:37] <@saste> finding a lib which is really clean is hard, i challenge you <-- ffms2 [21:37] <Daemon404> which i in fact use in favour of libav* many times [21:38] <ubitux> will we sed s/AV/AVS/ when the project has an honorable subtitles support? [21:38] <saste> Daemon404, but it's another layer of complexity [21:38] <saste> the classical carpet over the dirt [21:38] <Daemon404> libav* api is too generic [21:38] <Daemon404> and low level [21:38] <Daemon404> it doesnt even have "get me a frame" [21:38] <Daemon404> most people do NOT want that [21:39] <Daemon404> also it has fraem accuarte indexed seeking [21:39] <Daemon404> i dare you to try and implement that in libav* [21:39] <saste> yes i wonder if there is a reason for *not* to implement that cleanly in libav* [21:39] <saste> sometimes people try, and disappear [21:40] <saste> no i never tried that [21:40] <ubitux> i often hear "vfr" when talking about that [21:41] <Daemon404> ffms2 handles vfr properly [21:41] <Daemon404> so whats your excuse? [21:42] <saste> "less than straightforward and less than perfectly documented libav API" [21:42] <ubitux> Daemon404: what do you think is preventing that in libav*? [21:42] <ubitux> except "lavf is a mess" [21:42] <Daemon404> saste, thats entirely accurate [21:42] <Daemon404> especially when it was written, eyars ago [21:42] <Daemon404> ;) [21:42] <saste> this is the usual argument: ouch this is a mess, i'll build another layer of complexity rather than fix it properly at the right level [21:42] <saste> then the next guy comes and see the wrapper [21:43] <Daemon404> saste, libav* will never ever have that simple of an api [21:43] <Daemon404> ever [21:43] <saste> ouch this is a mess, i'll build *another* layer to cover this bloody mss [21:43] <saste> and again and again [21:43] <Daemon404> because certain people have moral objections [21:43] <Daemon404> to simplicity [21:43] <Daemon404> and non-genericism [21:43] <saste> this is the story of audio in linux [21:43] <Daemon404> "it should only decode packets!" [21:43] <saste> but people is free to do whatever they seem fit them [21:44] <Daemon404> i would really like a lot of the logic from ffmpeg.c [21:44] <Daemon404> moved to api [21:44] <Daemon404> it would be -really- useful [21:44] <saste> that's what freedom is about after all [21:44] <Daemon404> freedom doesnt mean its practical [21:44] <saste> Daemon404, my Great Evil Plan is to move all ffmpeg functionality to libavfilter [21:44] <Daemon404> eh [21:44] <Daemon404> tahts just not feasible [21:44] <saste> then you basically need a movie source, plus some filters [21:44] <Daemon404> for a lot of libavcodec specific things [21:45] <saste> like? [21:46] <Daemon404> things that would make useful higher level api for lavc [21:46] <Daemon404> without mixing in lavfi [21:46] <Daemon404> which [21:46] <Daemon404> shock [21:46] <Daemon404> adds a layer of compelxity [21:46] <saste> yes that's true [21:47] <saste> i realized it soon after [21:47] <saste> but at least it is in the same low level project [21:47] <Daemon404> that is irrelevant [21:47] <Daemon404> (fwiw i am very soon disabling libavfilter entirely for us) [21:47] <Daemon404> and moving to vapoursynth [21:48] <saste> ah windows specific stuff? [21:48] <Daemon404> no [21:49] <Daemon404> its cross platform [21:49] <Daemon404> avisynth replacement [21:49] <Daemon404> i plan on writign lua bindings and makign an input module for lavf [21:50] <JEEB> supports video atm, and after that gets more or less finished there probably will be some kind of audio support [21:50] <JEEB> official bindings are for python [22:16] <ubitux> (did i miss something?) [22:50] <michaelni> ubitux, no, just <Daemon404> (fwiw i am very soon disabling libavfilter entirely for us) [22:50] <ubitux> ok :( [22:50] <ubitux> thx :) [22:50] <Daemon404> keep in mind i am keepign essential ones for ffmpeg.c [22:51] <Daemon404> audio mostly. [22:51] <michaelni> Daemon404, why ? [22:51] <michaelni> you should remove them too, really :) [22:51] <Daemon404> ? [22:51] <Daemon404> im not sure i follow [22:52] <michaelni> well, i think if there are problems in libavfilter, they should be fixed [22:52] <michaelni> if people want a higher level interface that is simpler [22:52] <michaelni> one should be added [22:52] <Daemon404> the problems cannot be fixed [22:52] <Daemon404> its the very design that is wrong [22:52] <Daemon404> i.e. a monolithic library [22:53] <ubitux> Daemon404: we're almost to the point were we could have a 150-line tools feeding libavfilter with a filtergraph supporting the whole chain; like: ./ffstreamer "movie=in.avi,...,outmovie=out.avi" [22:53] <Daemon404> it's "scripting" rapes my eyes [22:53] <Daemon404> more or less [22:53] <Daemon404> id rather have real langauge bindings, and many newer plugins [22:54] <Daemon404> not to mention easy frame accurate seeking for input [22:54] <ubitux> well libav closed the api recently so it doesn't help supporting additionnal users filters or stuff like that :( [22:54] <Daemon404> its still wrong [22:54] <ubitux> Daemon404: did you see the [a]sendcmd from saste? [22:54] <Daemon404> it would still require a recompile [22:54] <Daemon404> (of the user app) [22:54] <michaelni> Daemon404, this is not hard to fix [22:54] <Daemon404> ubitux, tl;dr it's no repalcement for avs or vs and its use cases [22:54] <Daemon404> ive said this so many times [22:57] <michaelni> Daemon404, if it fails for some use case, please open a ticket on trac and explain the use case as a feature request [22:58] <michaelni> i think libavfilters low level API is quite well designed, whats missing is as you say / i understand you dynamic loading a nice easy API for such plugins [22:58] <Daemon404> i dont feel liek opening several hundred tickets [22:58] <Daemon404> and a real way to bind languages [22:59] <Daemon404> i.e. lua or python [22:59] <michaelni> Daemon404, you seem to feel like complaining alot though (not just about libavfilter) [22:59] <michaelni> and no offense intended, this is IMHO not helping anyone [22:59] <michaelni> we should try to improve what doesnt work as it should [22:59] <Daemon404> you are indeed correct [23:00] <Daemon404> you must understand though, many times when i mention things, "why arent you usign libav* for this?" and similar rhetoric shoved down my neck [23:00] <Daemon404> thats in fact what suprred this (in a different network/channel with a different dev) [23:01] <Daemon404> apologies for carrying it over. [23:01] <ubitux> Daemon404: we would really appreciate a well written mail/blogpost/article/whatever about the needs and expectations you and some other people have about a filtering library, and how libavfilter fail to achieve that, as well as what kind of things would be nice [23:01] <ubitux> because we can't do much except listening to your incomplete complains here [23:02] <Daemon404> i summed it up once before for libav [23:02] <Daemon404> general response i got was "we're nto gstreamer" [23:02] <Daemon404> or [23:02] <Daemon404> "why would you want to do that?" [23:03] <Daemon404> and at least one lecture on why dlopen is bad [23:03] <Daemon404> i will write one now though and send [23:03] <ubitux> thank you [23:04] <Daemon404> warning: i know ill forget some [23:04] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/get_bits.h: get_bits: get_bits_long() support n=0 as the docs allow it [23:04] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/x86/dsputil_mmx.c: dsputil_mmx: put optimized gmc code back and avoid a VLA without loosing features. [23:05] <ubitux> Daemon404: take your time :) [23:06] <Daemon404> its the public api for lavfi documented? [23:06] <Daemon404> is* [23:06] <Daemon404> iirc there were complains -- i dont know if it's been rectified [23:07] <ubitux> there are filtering examples [23:07] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc/examples;hb=HEAD [23:07] <Daemon404> exampels are not documentation [23:07] <ubitux> i personally still find the public api a bit complex [23:08] <ubitux> aren't they? [23:08] <Daemon404> they are not a substitute. [23:08] <ubitux> the functions are likely doxified [23:08] <Daemon404> oh [23:09] <Daemon404> i should also sent an email about why print_options is not a good solution [23:09] <Daemon404> (separate issue) [23:09] <Daemon404> also a tricky one. [23:20] <kierank> "Greek harmony" = golden ratio? [23:22] <ubitux> saste: didn't you have a patch to remove the '-' in the ffmpeg help for the filters? [23:23] <ubitux> and pretty-printing related patches [23:23] <saste> kierank, yes, join the phi lovers club [23:24] <saste> ubitux, yes, if i remember where i put it [23:27] <ubitux> i wonder if we shouldn't remove the "AVOptions" thing too [23:27] <ubitux> anyway, adding some more padding, remove the '-' and put some little indent would really help [23:27] <ubitux> iirc your patch(es) was/were improving this [23:28] <ubitux> btw, kind of related, but the "Getting help" message should appear with no input [23:29] <Compn> michaelni : i have a complaint about ffmpeg. the whole thing is monolithic, and gigantic! and i dont have any idea how to make it smaller, but its all rubbish ... :) [23:29] <Compn> :P [23:30] <Daemon404> ffmpeg's libraries have deps on the otehr libraries in ffmpeg in a bad way [23:30] <Daemon404> i.e. non oublic symbols [23:30] <Daemon404> nonpublic* [23:30] <Daemon404> so yes, youre sort of right [23:30] <Daemon404> :) [23:30] <Compn> we should make every symbol public and that way mplayer wont have trouble.... ;) [23:31] <Daemon404> lol [23:31] <Compn> or we could just rename every symbol every three months so it looks like we are developing code... [23:31] <Compn> breaks api? who cares! [23:32] <Daemon404> eh [23:32] <Compn> already renamed the main programs, that was important... [23:32] <Daemon404> api breaks more than every 3 months [23:33] <Compn> ffmpeg will be depreciated so use avconv! [23:33] <Compn> wonder when it will finally be depreciated... [23:33] <Compn> in the year 2022 [23:34] <Compn> wait [23:34] <Compn> did you just complain about ffmpeg's libavfilter options being like a script [23:35] <Compn> and then immediately say it should be like avisynth's .. options ... being like a script that you have to make a script to use? [23:35] <Compn> Daemon404 : do you want feature request to be able to use ffmpeg via script like avisynth ? [23:36] <Daemon404> Compn, either that or people stop pushing lavfi on me as an avs replacemeny so zealot-like [23:36] <ubitux> Compn: give him a chance to express him properly, let's not ask him to much for trolling here :) [23:36] <Compn> ubitux : lol ok , we troll later :) [23:37] <ubitux> we'll troll after the post explaining deeply the issue [23:37] <Compn> k [23:37] <ubitux> which will be far more interesting and constructive :) [23:37] <ubitux> (hopefully) [23:37] <Compn> Daemon404 : who said to replace avisynth with libavfilter ? thats dumb. libavfilter doesnt have half of the filters that avisynth has [23:37] <Compn> its not ready to be a replacement [23:37] <Daemon404> Compn, response: [23:37] <ubitux> i said stop it Compn! :( [23:37] <Daemon404> PORT IT ALL [23:37] <Daemon404> PATCHES WELCOME [23:38] <ubitux> see... :() [23:38] <ubitux> :( [23:46] Action: Compn realizes that avisynth is based on vfw, remembers getting scolded about using ffdshow because it was too 'ancient' and lav filters wat hte future [23:46] Action: Compn brain explodes [23:47] <Compn> ah avisynth 3 was going to use a real language for scripts, instead of crazy-reinventing windows batch files [23:47] <Compn> ubitux : so talk to me about something so i stop trolling [23:47] <Compn> multimedia.cx is back up [23:47] <ubitux> do you love pokémons? [23:47] <Compn> yay [23:48] <Compn> no not really [23:48] <ubitux> :( [23:48] <Compn> like power rangers, their novelty has died on me [23:48] <Compn> and pogs [23:48] <ubitux> pogs... i almost forgot about that :D [23:49] <kierank> 22:23:31 <saste> kierank, yes, join the phi lovers club --> can you perhaps call it the golden ratio instead [23:50] <kierank> i don't think i've ever heard it called greek harmony in english [23:51] <saste> kierank, it was subtly humorous [23:51] <kierank> oh [23:51] <kierank> whoosh [23:51] <saste> but i don't mind if you want to change it (PAWE) [23:59] <cone-191> ffmpeg.git 3Michael Niedermayer 7libavcodec/x86/dsputil_mmx.c: gmc_mmx: enable also for large pictures when emu edge isnt needed. [00:00] --- Sun Oct 7 2012

1 0

ffmpeg.log.20121006
by burek 07 Oct '12

07 Oct '12

[00:09] <burek> rainmaker1 can you please use a pastebin site (like www.pastebin.com) to show your ffmpeg command and the complete console output? [00:25] <rainmaker1> burek: sure if you are still awake :) [00:25] <burek> :) [00:25] <rainmaker1> cool :) [00:29] <rainmaker1> Here it is http://pastebin.com/UB3PzGpC [00:38] <rainmaker1> burek: ant idea how to discard some streams? ie subtitles [00:41] <burek> im here [00:41] <burek> just a sec [00:43] <rainmaker1> ok ok [00:45] <burek> rainmaker1, you did select correct program id [00:45] <burek> so, now, you want what? [00:45] <burek> discard everything except audio/video? [00:47] <rainmaker1> hmmmm [00:47] <rainmaker1> if you look at pastebin [00:47] <rainmaker1> I have a mux of multiple live channels [00:47] <rainmaker1> every channel I want to transcode [00:48] <rainmaker1> audio/video [00:48] <rainmaker1> and nothing else [00:48] <rainmaker1> is this possible? [00:48] <burek> well, you selected only one program (channel) 7002 [00:49] <burek> meaning, you selected all of its streams [00:49] <rainmaker1> yes and I want to use audio/video only and I don;t want subtitles as I receive above error [00:49] <burek> and there are 4 of them, exactly how ffmpeg selected them [00:49] <rainmaker1> ok [00:49] <burek> ok, so you want to specify only audio/video from program 7002 ? [00:49] <rainmaker1> bingo :D [00:50] <burek> take a look at the format of the -map option: http://ffmpeg.org/ffmpeg.html#Advanced-options [00:50] <burek> -map [-]input_file_id[:stream_specifier] [00:50] <burek> now, what is <stream_specifier> ? take a look here: http://ffmpeg.org/ffmpeg.html#Stream-specifiers-1 [00:50] <burek> p:program_id[:stream_index] [00:50] <burek> now, you might try: -map 0:p:7002:a -map 0:p:7002:v [00:50] <burek> instead of: -map 0:p:7002 [00:51] <rainmaker1> Aha! [00:51] <rainmaker1> Now tha main error [00:52] <rainmaker1> Failed to compensate for timestamp delta of -21867.146792 [00:52] <rainmaker1> I always get this error [00:53] <rainmaker1> Now I have read something like I can specify a synchronization stream or something like that but it is not clear to me [00:53] <rainmaker1> how I know what is synchronization stream? [00:53] <burek> pastebin? [00:54] <rainmaker1> sure [00:56] <rainmaker1> http://pastebin.com/amaZH6Ly [00:59] <burek> rainmaker1, for some reason that didn't work [00:59] <burek> try this [00:59] <burek> -map 0:p:7002:0 -map 0:p:7002:1 [01:00] <rainmaker1> same error :* [01:00] <rainmaker1> :( [01:00] <rainmaker1> not * but ( [01:00] <burek> :D [01:00] <burek> pastebin? :) [01:01] <rainmaker1> sec [01:03] <rainmaker1> here it is [01:03] <rainmaker1> http://pastebin.com/HEJymGdt [01:05] <burek> pastebin sure got slow in last couple of days [01:06] <burek> became* [01:06] <rainmaker1> I dont use it on a daily basis [01:06] <rainmaker1> :) [01:06] <burek> that's good so far (your pastebin) [01:07] <burek> now [01:07] <burek> can you start with something like this [01:07] <burek> ffmpeg -f mpegts -y -i udp://237.0.0.230:5000?overrun_nonfatal -map 0:p:7002:0 -map 0:p:7002:1 output.ts [01:07] <burek> and slowly add more and more options [01:08] <burek> until you get your current command line [01:08] <burek> just to be able to see where does the error occur [01:08] <rainmaker1> well I am not sure [01:08] <rainmaker1> frame= 0 fps=0.0 q=0.0 Lsize= 246kB time=00:00:00.00 bitrate= 0.0kbits/s dup=0 drop=344 [01:09] <rainmaker1> is this ok to have a huge number of drops? [01:09] <burek> well, if fps stays at 0 thats not good [01:09] <rainmaker1> well yes [01:10] <rainmaker1> it's a strange [01:10] <burek> either your input is invalid, or the ffmpeg's decoders are buggy [01:10] <rainmaker1> I belive in second :( [01:10] <burek> it would also be good to capture a raw input and save it as a dump file [01:10] <rainmaker1> because input is used on some pro equipment [01:10] <burek> like 10-20 mb [01:11] <burek> in case you need to provide a sample, so that developers can see what is wrong [01:11] <burek> and fix the bug (if any) [01:11] <rainmaker1> I will try to open a bug report just need to read a rules how to post a bug report [01:12] <rainmaker1> Thank you for your time burek, and have a good night :) [01:12] <burek> you might try also: ffmpeg -y -f mpegts -i udp://237.0.0.230:5000?overrun_nonfatal=1 -map 0 -c copy -t 120 output.ts [01:13] <burek> np :) [01:13] <rainmaker1> nope [01:13] <rainmaker1> [mpegts @ 0x2eeb200] sample rate not set [01:14] <rainmaker1> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [01:14] <burek> it would help to capture that udp input to some raw file.. [01:14] <burek> I'm just not sure how [01:14] <rainmaker1> yes, via tcpdump or tshark [01:15] <burek> I guess [01:15] <rainmaker1> will try [01:15] <rainmaker1> thanks again :) [01:15] <burek> :beer: :) [01:15] <rainmaker1> and good night, take a look at a clock :P [01:15] <burek> :) [01:16] <burek> the night is young :) [01:16] <burek> gn :) [01:16] <rainmaker1> :D [06:07] <DGMurdockIII> hey have you guys heard of http://www.theaudiodb.com? [10:54] <newenc> how do you do I-frame only mpeg2? [12:35] <King_Rat> can someone explain how I can map two different audio streams to the same output file? [12:36] <King_Rat> im currently using "ffmpeg -y -f x11grab -s "1366x768" -r 10 -i :0.0 -f alsa -i pulse -f pulse -i default -vcodec libx264 -s "640x360" -acodec libmp3lame -ab 128k -map 0:0 -map 1:0 -map 2:0 asdasd.mp4" [12:36] <saste> King_Rat, -map, check examples in the doc [12:36] <King_Rat> i did, and got confused [12:38] <King_Rat> i'd have thought it would work but it only seems to take a first audio stream [12:38] <saste> pb King_Rat [12:39] <King_Rat> http://pastie.org/pastes/4921439/text [12:40] <saste> King_Rat, looks correct [12:40] <saste> what's wrong with it [12:41] <saste> (FUCK I need to scroll xchat to see the posted messages) [12:41] <saste> King_Rat, if you want to *merge* the audio streams you need amerge/amix [12:41] <King_Rat> oh right [12:45] <King_Rat> so I don't need to use maps at all? [12:46] <saste> King_Rat, I don't think so, you should find some examples in the docs (amerge/amix, with somewhat different features) [12:46] <King_Rat> oh cool, i got it working [12:46] <King_Rat> sorry, i naively thought ffmpeg would merge the streams by default [12:48] <saste> no, fortunately ffmpeg doesn't try to be "clever" and preserve the input structure [12:48] <King_Rat> yeah, i suppose that's much more sensible [12:49] <King_Rat> thanks for the help, and sorry about my incompetence [12:49] <saste> you're welcome [12:49] <saste> ::donate button:: :) [12:52] <King_Rat> im afraid i dont have much money to spare [12:52] <King_Rat> i can draw you a picture of you like though [12:54] <saste> King_Rat, if you're an artist you may consider to send us a logo [12:54] <saste> we have a sort of contest for a new winter logo [12:55] <saste> http://ffmpeg.org/trac/ffmpeg/wiki/SubmitALogo [13:01] <King_Rat> i'm a terrible artist [13:02] <King_Rat> and im generally against software having logos [17:10] <cheeseduck> I recently read news that ffmpeg 1.0 was out. [17:10] <cheeseduck> So why does mine say "ffmpeg version N-45080-gd9dfe9a"? [17:10] <cheeseduck> (Just downloaded it.) [17:11] <cheeseduck> What absurd version number is that? [17:12] <bigmeow> hi all [17:12] <creep> cheeseduck<< its the trend, you don't like that cool name ? [17:13] <dzan> hi, i'm using Serviio which uses ffmpeg to transcode video and serve it over dlna/upnp or flash ( http ), I used this guide to build it myself: http://wiki.serviio.org/doku.php?id=build_ffmpeg_linux and my version info looks like this: http://pastebin.com/BDbQKYZa I'm on a ubuntu server 11.04 with a amd 760g chipset and the kind of output I always get is this: http://www.zimagez.com/zimage/schermafdruk-05-10-12-142254.php , and the sound is ver [17:13] <dzan> y screechy and unuseable. does anyone have any idea what could go wrong? I searched for a solution since a week without result. [17:13] <cheeseduck> No. [17:13] <cheeseduck> Can you explain what the hell is going on? [17:13] <creep> i don't even read those numbers [17:14] <creep> doesn't really matter [17:14] <creep> i have one problem with ffmpeg currently, it fails to handle the datastream of my cheap webcam [17:29] <bigmeow> how to compile ffmpeg using vs on windows? [17:49] <creep> bigmeow<< no idea [17:50] <mooglenorph> Hi, I'm on debian screeze and I'm trying to record a screencast for youtube. I'm trying to capture lossless video first, using this command: ffmpeg -f x11grab -r 30 -s 1280x800 -sameq -i :0.0 -f alsa -i pulse meow.avi [17:51] <creep> and it doesn't work? [17:51] <mooglenorph> But it seems kind of laggy when I play back the video. [17:51] <creep> the sound? [17:51] <mooglenorph> No, the video, the sound is fine. [17:51] <creep> try mjpg [17:51] <mooglenorph> Also, I have no idea what I should transcode it to, if anything, for upload to youtube. [17:51] <creep> or something faster [17:52] <creep> h264 mkv is the smallest [17:52] <mooglenorph> Okay, thanks, I'll try that... [17:53] <creep> you might want to try out h264 fastest setting, if your computer can handle that [17:53] <creep> as a compromise [17:55] <mooglenorph> Is there a way to list available codecs? [17:56] <mooglenorph> I tried -vcodec libx264 and it says it cannot find that codec. [17:56] <mooglenorph> But I've installed all the x264 packages in squeeze [17:58] <mooglenorph> Specifically, Unknown encoder 'libx264' [18:22] <luft> hi, I need some help with encoding [18:23] <luft> I'm using the comman ffmpeg -i \[Coalgirls\]_Mobile_Suit_Gundam_Unicorn_01_$1920x1080_Blu-ray_FLAC$_\[CF793FEE\].mkv -c:v copy -aq 200 Gundam_Unicorn_01.mp4 [18:23] <luft> command* [18:23] <luft> and I'm getting the error: Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height [18:26] <JEEB> paste the terminal output onto a pastebin and link there [18:26] <JEEB> *here [18:26] <JEEB> I'm pretty sure the actual error is higher up :P [18:29] <luft> it was [18:30] <luft> hold on [18:31] <luft> http://pastie.org/4922687 [18:31] <ubitux> "Codec is experimental but experimental codecs are not enabled, see -strict -2" [18:32] <JEEB> yup [18:32] <JEEB> -strict experimental or -strict -2 [18:32] <JEEB> is needed [18:32] <JEEB> to enable the internal aac encoder [18:32] <JEEB> also I'm pretty sure aq 200 doesn't do what you think it does [18:33] <luft> variable rate encoding? [18:33] <luft> I thought that was supposed to be variable rate encoding for aac with 255 the highest quality, and 0 the lowest [18:34] <JEEB> I think it's the other way around, and I'm not sure if it even goes 0-255 [18:35] <luft> oh ok [18:35] <JEEB> at least looking from the side of H.264 where QPs go from 0-51, but not like I know how to the -aq setting works [18:38] <luft> any idea how to extract the subtitles from an mkv? [18:39] <JEEB> -c:s copy [18:40] <luft> ok [18:41] <creep> mooglenorph<< try ldconfig [18:47] <luft> -c:s copy isn't working [18:48] <luft> -scodec copy does try to copy the english subs, but it errors out [18:48] <luft> mainly because the codec is not supported in mp4 [18:50] <ubitux> try -c:s mov_text [18:51] <ubitux> you won't retain the advanced ass markup though [18:51] <luft> ubitux: ok [18:51] <ubitux> your version might be too old btw. [18:52] <ubitux> you are two major versions behind [18:52] <ubitux> at least upgrade to 1.0 [18:53] <luft> ok [18:57] <luft> I downloaded a static build and I'm getting this now: [libvo_aacenc @ 0x2d62b60] Unable to set encoding parameters [19:02] <luft> ok, maybe I now have it working, switched to mp3 for audio codec [19:38] <mickkie> Hi All, trying to extract subtitles with: ffmpeg -i /data/Masters\ of\ Money_121001.rec -an -vn -sbsf mov2textsub -c:s copy -f rawvideo sub.txt and I'm getting this error: "Unrecognized option 'sbsf' Failed to set value 'mov2textsub' for option 'sbsf'" Am I doing something wrong? [19:38] <mickkie> The video is from a Topfield PVR [19:59] <cheeseduck> I recently read news that ffmpeg 1.0 was out. So why does mine say "ffmpeg version N-45080-gd9dfe9a"? [19:59] <cheeseduck> What absurd version number is that? [20:17] <ubitux> a git identifier [20:18] <ubitux> [/tmp/ffmpeg-1.0]- ./version.sh [20:18] <ubitux> 1.0 [20:18] <ubitux> it's likely your 1.0 is build from a different version [20:19] <ubitux> likely a more recent one [20:21] <ubitux> with git/master you would have: N-45112-g51211d3 [20:21] <ubitux> N-45080-gd9dfe9a is 32 commits before the latest bleeding edge "version" [20:22] <cheeseduck> Hrm... [20:22] <cheeseduck> ubitux: I got mine from here: http://ffmpeg.zeranoe.com/builds/ [20:22] <cheeseduck> "FFmpeg git-d9dfe9a 64-bit Static (Latest)" [20:22] <cheeseduck> Which looks like the last stable? [20:23] <ubitux> a bit more recent [20:23] <cheeseduck> Then I have no idea what the actual latest stable is on that page. [20:23] <cheeseduck> Why a billion download links? [20:23] <ubitux> why do you care about the "stable" one? [20:23] <ubitux> unless you are a distributor, the latest git version is recommended [20:23] <cheeseduck> Because I don't like running unstable stuff? [20:24] <ubitux> git head isn't less stable [20:24] <cheeseduck> Let's say I *am* a distributor. Where is that? [20:24] <ubitux> you have to build it yourself [20:24] <cheeseduck> I don't understand this weird ambiguity. [20:24] <cheeseduck> And why they don't use proper version numbers. [20:24] <ubitux> do you understand what git is? [20:25] <cheeseduck> Yes. [20:25] <ubitux> zeranoe is just distributed (automated?) build based on the latest version [20:25] <ubitux> you have multiple build for multiple configuration preset [20:25] <ubitux> we recommend our users to use the latest git because we don't release "stable" version often [20:26] <ubitux> maybe you could ask in the zeranoe forum for 1.0 releases [20:27] <ubitux> so well, the version you see is just a commit identifier [20:28] <ubitux> if you want to do yourself some "stable" ffmpeg windows builds, you can go grab the 1.0 sources on http://ffmpeg.org/download.html#releases [20:28] <ubitux> and make it yourself [20:28] <cheeseduck> Well... [20:29] <ubitux> most (all?) the developers are *nix only people, so we don't have windows-manpower to do that ourselves [20:29] <cheeseduck> I don't see why I'd want to build it locally. [20:29] <ubitux> i don't know your needs [20:30] <cheeseduck> The latest is probably gonna cut it for me, but I still find it odd. [20:30] <ubitux> you can discuss this with this particular distributor [20:30] <ubitux> as ffmpeg developers, we don't really control that [20:53] <shevy> guys, question - there is a video stream, made available to us as .mpg file. the file is huge though 400 mb [20:54] <shevy> can ffmpeg convert this to an acceptable quality, to .mp4 or some other smaller, more efficient container / format? [20:54] <shevy> I dont wanna backup 10 x 400 mb :( [20:54] <shevy> 5-30% quality loss is absolutely fine [21:11] <KING_LEE> hello, i have some problems with an MTS file. i want to turn into a .mov but i get this error [21:12] <KING_LEE> [mov @ 0x8312ae0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1 >= 1 [21:12] <KING_LEE> av_interleaved_write_frame(): Invalid argument [21:12] <KING_LEE> what does that mean? [22:49] <Marlinc> Hellooo [22:50] <Marlinc> Is it possible to get [22:50] <Marlinc> frame= 23 fps= 5 q=23.9 Lsize= 813kB time=6.60 bitrate=1008.9kbits/s [22:50] <Marlinc> More frequent? [23:58] <Marlinc> Hello? [00:00] --- Sun Oct 7 2012

1 0