Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2014

1 participants
64 discussions

ffmpeg-devel.log.20140614
by burek 15 Jun '14

15 Jun '14

[01:06] <BBB> michaelni: if its get_delay, I think this patch should fix it [01:06] <BBB> not sure, didnt have a ton of time to test [01:07] <BBB> will do over weekend or so... [01:09] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:10012fa961a1: ffmpeg: Fix bitstream filters manipulating AVCodecContext [01:19] <michaelni> BBB, ok, thx, ill maybe do some testing as well [11:48] <J_Darnley> When writing a filter with audio input, is there a short hand way of saying it accepts "all sample formats" like there is for channel layouts and sample rates? [11:50] <wm4> hm, af_ashowinfo accepts everything [11:50] <wm4> but it just doesn't implement the format query fn [11:51] <J_Darnley> Oh, might it be ff_all_formats()? [11:51] Action: J_Darnley wonders how he failed to spot that. [11:52] <wm4> but depending on what you do, it's probably a bad idea to support all formats, just because you can handle all formats right now [11:52] <J_Darnley> Yes, there it is in concat, resample, pan, ... [11:52] <wm4> because someone could always add a really weird format that breaks everything in creative ways [11:52] <J_Darnley> True [11:53] <J_Darnley> You would need a test for an "unknown" format [11:53] <J_Darnley> because at the very least you would need to convert the data pointer into the correct type. [11:55] <J_Darnley> Then I think I will just make my example take a few explicitly defined formats [11:56] <wm4> sounds like a better idea, especially if it's example code (?) [16:44] <michaelni> Timothy_Gu, as you are maintainer now, you get OP in #ffmpeg-devel, also if anyone else is in MAINTAINERs and doesnt have op here, ping me [16:54] Action: michaelni wonder why cone isnt here [17:01] <j-b> michaelni: should come [17:25] <BtbN> Interesting. The hevc decoder is that big that i can't create a static ffmpeg.exe anymore. It fails to link it because stuff gets out of range for relative jumps. [17:25] <wm4> that must be a sucky linker [17:26] <BtbN> just normal gcc [17:26] <BtbN> http://bpaste.net/show/fNabl66Xjmu20ywlOOLA/ [18:35] <Daemon404> will swscale always bitshift while upsampling from e.g. 10 to 16 bits? [18:40] <wm4> hm, what else would it do? [18:40] <Daemon404> no idea [18:40] <j-b> magic [18:42] <wm4> libswscale is a software implementation of murphy's law, so I guess it's hard to tell what exactly it does [18:42] <wm4> weren't there complaints that it introduces bias? [18:42] <wm4> something about being too green? [18:44] <J_Darnley> IIRC you need to do something about the new low bits [18:45] <Daemon404> right [18:46] <J_Darnley> perhaps that IIRC should be "as I understand it" [18:46] <michaelni> if sws doesnt set the low bits correctly please open a ticket with testcase [18:47] <BtbN> what else than 0 should it set them to? [18:47] <J_Darnley> the most basic demonstration I can think of is: 255<<8 != 65535 [18:47] <J_Darnley> (not that I am saying that swscale does this) [19:08] <kierank> Daemon404: what do you want it to do [19:08] <Daemon404> no i was just asking [19:08] <Daemon404> easier than grepping swscale [19:08] <Daemon404> usually. [19:08] <kierank> swscale should shift iirc [19:08] <kierank> for yuv [19:08] <kierank> and for rgb it should shift and add [19:09] <Daemon404> i meant for yuv, so yeah [19:09] <Daemon404> are you back in the motherland yet kierank [19:09] <kierank> yes [19:09] <Daemon404> \o/ [19:10] <Daemon404> it is already getting too hot here. [19:10] Action: Daemon404 has to have a fan pointed at him at all times. [19:11] <kierank> had a lovely whale steak yesterday [19:11] <Daemon404> i saw [19:11] <Daemon404> lol [19:13] <kierank> norway is beatiful [19:13] <kierank> albeit expensive [19:13] <Daemon404> the nature photos you posted [19:13] <kierank> photos don't do it justice [19:13] <Daemon404> pretty much look like where i grew up in Canada :P [19:14] <Daemon404> 800km radius of nature around my hometown [19:14] <Daemon404> lakes, mountains, forest, etc [19:15] <Daemon404> did you see any maelstrom? [19:16] <kierank> duno [19:17] <kierank> the train into the mountains is crazy [19:17] <kierank> really crazy [19:17] <kierank> you see so much nature [19:17] <kierank> it's like the train in the hunger games [19:17] <kierank> that's the only way to put it [19:18] <Daemon404> :P [19:20] <cone-576> ffmpeg.git 03Carl Eugen Hoyos 07master:6ac3c8c6a0c6: Fix compilation with --disable-everything --enable-parser=vc1. [19:54] <cone-576> ffmpeg.git 03Marton Balint 07master:66f4891e6422: mpeg12enc: add support for PANSCAN side data in sequence_display_extension [19:54] <cone-576> ffmpeg.git 03Marton Balint 07master:9236f7b5a23b: mpeg12enc: add seq_disp_ext option for deciding when to write a sequence_display_extension [20:01] <Timothy_Gu> michaelni: thanks! [20:03] <BBB> that should clean things up a bit... [20:09] <Timothy_Gu> BBB: swri_resample() moves out of [20:09] <Timothy_Gu> resample_template.c into resample_template.c <--- this doesnt make sense [20:10] <BBB> oh [20:10] <BBB> I guess I should fix that [20:11] <BBB> fixed [20:22] <ubitux> https://github.com/alankila/Junk/tree/master/wav2png haha wat [20:31] <jamrial> BBB: why not use the macros from x86/cpu.h in swresample_dsp_x86_init()? [20:31] <Daemon404> ubitux, hand picked sample [20:31] <Daemon404> its a load of crap [20:31] <Daemon404> :D [20:34] <jamrial> well, they acknowledge as much [20:34] <jamrial> not only they call it a toy that only works with samples like the one they used. it's also part of a repository named "junk" :P [20:34] <Daemon404> lol [20:42] <cone-576> ffmpeg.git 03Ronald S. Bultje 07master:7128a35f8c4b: swr: split out DSP functions. [20:43] <Timothy_Gu> ironically, the "junk" repo has 44 stars and is the user's most popular repo [20:45] <wm4> 44 internet points [20:48] <cone-576> ffmpeg.git 03Michael Niedermayer 07master:b065d0014be3: avcodec/ppc/idct_altivec: add plain idct() [20:52] <BBB> jamrial: no idea they existed [20:52] <BBB> jamrial: feel free to simplify and use the macros if you like that [20:53] <BBB> jamrial: I was thinking of actuall removing some inline asm now - sounds like a good time [20:53] <jamrial> cool [20:53] <BBB> or you could do it too, I think most of the digging is finished now [20:53] <jamrial> and yeah, there are macros for both external and internal checks [20:54] <BBB> aha [20:54] <BBB> ok [20:54] <Timothy_Gu> guys, what is the use of different idct implementations else than optimization? E.g. how is ipp better than faani, or how is simplemmx is better than xvidmmx? [20:54] <BBB> Timothy_Gu: idct isnt exactly defined [20:54] <BBB> Timothy_Gu: so each has slightly different output [20:54] <BBB> b/c of rounding etc. [20:54] <BBB> Timothy_Gu: so which one you want to use typically might depend on multiple factors [20:54] <BBB> most users just care about speed, but sometimes people want higher precision [20:54] <ubitux> yay, hq4x working. [20:55] <ubitux> ~150 lines [20:55] <ubitux> and i may be able to get it down to 100 lines [20:55] <ubitux> hq3x remaining [20:58] <BBB> whats hq4x? :-p [20:59] <jamrial> giving round corners to pixel art, basically :P [20:59] <Timothy_Gu> BBB: can you give a rough rank of precision of simple, faani, ipp, and int? [21:00] <BBB> jamrial: oh that, Ive seen that before, cool [21:01] <iive> imho, it could be quite useful for subtitle enlarging, dvdsub etc... [21:01] <BBB> Timothy_Gu: & like from the top of my head? no, not really& I can try to look up what they are exactly and which one is better or worse, whats the purpose? [21:02] <Timothy_Gu> none really, but i can document them so that other confused users can understand what the option is used for. [21:06] <BBB> ok I can try to figure out for a few of them, as far as I understand them [21:07] <ubitux> BBB: what i just sent [21:08] <BBB> how come the md5 of all filters is identical? [21:08] <Timothy_Gu> BBB: thanks! [21:08] <BBB> Timothy_Gu: do you have a list of all idcts you want information on? [21:09] <Timothy_Gu> From http://ffmpeg.org/ffmpeg-codecs.html [21:09] <Timothy_Gu> I assume that simple* is basically the same algo, so you dont need to test/look at them [21:10] <Timothy_Gu> *you only need to look at one of them [21:10] <ubitux> iive: heh yeah maybe; but... we need subtitles in libavfilter lalala here we go again [21:10] <Timothy_Gu> im not interested in sh4 or altivec either [21:11] <BBB> alpha/neon is also just arch-specific [21:11] <BBB> as is all the arm ones [21:11] <Timothy_Gu> so what's left is int, ipp, faani, xvidmmx, and simple [21:11] <BBB> sh4 same [21:11] <BBB> Ill look at simplemmx also [21:12] <BBB> I bet its not identical [21:13] <Timothy_Gu> i remember seeing somewhere that some functions of simplemmx is bit-identical with simple (C) [21:13] <BBB> the high bit ones likely aren't [21:13] <BBB> maybe the 8bit is [21:13] <BBB> the high bit ones are tricky, I remember that from prores [21:13] <kierank> Is Pierre-Edouard LEPERE on irc? [21:13] <BBB> you can get them bitexact but its slightly slower [21:13] <BBB> kierank: plepere [21:13] <kierank> ah not online currently [21:14] <kierank> I'm wondering why he uses 3 operand in his asm but then only defines sse4 [21:14] <BBB> not sure [21:14] <BBB> doesnt x86inc.asm take care of that? [21:14] <BBB> i.e. it automatically introduces a mova [21:15] <kierank> yeah but he only does INIT_XMM sse4 [21:15] <kierank> and doesn't do avx for some reason [21:15] <jamrial> in his latest patch he added an avx version for functions where he used three operand instructions [21:15] <jamrial> but before that use used mova + instruction. i was the one that merged them. at least in hevc_deblock.asm [21:16] <jamrial> i didn't touch hevc_mc.asm. kurosu did [21:18] <jamrial> hevc_mc.asm still needs some work. most functions there are ssse3, and a couple sse2 even. but they are all defined as sse4 [21:18] <kierank> ah [21:22] <michaelni> some of the simple idcts for arm arent identical to simple C in output [21:24] <michaelni> about precission, see libavcodec/dct-test --help [21:25] <michaelni> and the best idct to use in a decoder is one that matches the encoder [21:25] <michaelni> if a encoder used a "inaccurate" one, its better to use that same "inaccurate" one than a accurate one [21:27] <kierank> michaelni: should have let smarter comment [21:28] <michaelni> kierank, well i didnt push yet, i can wait [21:31] <michaelni> also, we have noone listed in MAINTAINERs for hevc, if someone, smarter? wants to maintain it, please say so or send patch for MAINTAINERs [21:31] <Timothy_Gu> michaelni: do you mean the "official" encoder when you say "encoder" or the lavc one? [21:31] <michaelni> I meant the encoder used to encode a specific file [21:32] <michaelni> if someone encodes foobar.mpg with a very inaccuarte IDCT, it can look bad when decoded with a accurate IDCT [21:33] <Timothy_Gu> how do you know which idct the file used? especially for codecs like MPEG-4 [21:34] <michaelni> some encoders leave their name & version in the file in user data in the video stream or metadata in the container or cna be identified from the used fourcc in avi [21:34] <michaelni> libavcodec generally tries to use a matching idct when it can figure out that one would be better [21:35] <michaelni> an example for this is FF_IDCT_XVIDMMX [21:36] <Timothy_Gu> OK, thanks alot for the information [21:36] <michaelni> np [21:36] <kurosu> last bench on mpeg2 was xvid idct > simple idct, but that's mostly because the former is sse2 [21:36] <kurosu> the AAN one I think is mostly historical [21:36] <Timothy_Gu> one last question: can you give some common use case for each idct? [21:37] <kurosu> idct should match forward dct, in particular for temporal prediction [21:38] <kurosu> otherwise you get drift, even if you acertain your idct conforms to the max/average requirements in some mpeg specs [21:38] <michaelni> no, you get drift if the idct in the encoder and the idct in the decoder mismatch [21:39] <Daemon404> Timothy_Gu, http://guru.multimedia.cx/the-mpeg124-and-h26123-idct/ [21:39] <Daemon404> michaelni's own post [21:40] <nevcairiel> in practice, idcts are not "special", all you have to do is match the algorithm used in the encoder [21:40] <nevcairiel> and every implemented idct does that for some codec [21:40] <Daemon404> "all you have to do" [21:40] <michaelni> the dct in the encoder could significnatly mismatch the idcts and it should still not drift as the encoder always performs the mc+idct steps from the decoder so their intenal state should not drift apart [21:40] <Daemon404> because its so simple! [21:40] Action: Daemon404 runs [21:40] <nevcairiel> Daemon404: just because you failed with your latest codec endavour [21:40] <JEEB> and this, boys and girls, is why AVC and HEVC have bit-exact specified IDCTs [21:41] <Daemon404> nevcairiel, technically kostya used simple_idct :P [21:42] <nevcairiel> and luckily what JEEB said, modern codecs got smarter and figured out that its useful to specify the idct [21:42] <nevcairiel> in mpeg2 it was implementation dependendent, which kinda sucked [21:42] <kurosu> jamrial, the hevc_mc.asm is very very wrong - but it actually does not matter [21:43] <kurosu> the effort to fix it has probably an equivalent magnitude to rewriting it [21:43] <J_Darnley> Wow. I didn't expect to see IDCTs discussed in 2014 [21:44] <nevcairiel> blame Timothy_Gu [21:44] <Daemon404> J_Darnley, how else would someone learn the basics? [21:44] <J_Darnley> Good point [21:44] <J_Darnley> I only learned the same things from using DGDecode [21:45] <JEEB> all these animoos on my screen, they're there thanks to it 8) [21:45] <Daemon404> oh holy shit, michaelni's blog was updated twice this year [21:45] <Daemon404> and i missed it because planet doesnt track it anymore [21:45] <Daemon404> :< [21:45] <Daemon404> J_Darnley, bad ida [21:45] <Daemon404> dgdecode code base is so terrible [21:46] <Daemon404> (fyi i replaced dgdecode with a ffmpeg-based d2v reader :P) [21:48] <llogan_> kierank: where did you ride to and from on the train in Norway? [21:48] <kierank> llogan_: oslo to bergen [21:48] <kierank> bergensbanen [21:48] <jamrial> the last blog entry is about ffhufffyuv, and gives some numbers. wonder if it changed after kurosu's work from the past few weeks [21:49] <Daemon404> gmx too [21:50] <llogan_> fun. i went from trondheim to oslo (partially by bus). some parts reminded me of home, but it was so much cleaner. no yard refrigerators. [21:51] <llogan_> a beer costs at least 2x though. [21:52] <J_Darnley> Daemon404: I didn't (and probably still don't) care what the code base was like. [21:53] <Daemon404> heh [21:54] <J_Darnley> It must have been 10 years since I first used it. [21:55] <J_Darnley> Maybe not quite [21:56] <J_Darnley> It was probably on my first DVD rip. Futurama. It want alright apart from the interlacing. [21:57] <J_Darnley> *it went [21:57] <kurosu> jamrial, maybe 10% better for decoding - but most of my test files were actually low entropy <-> short codes, therefore less memory-bound [21:57] <kurosu> on one of those test files, random changes can cause a 5% speedup, but there's no way to control it :( [22:00] <kurosu> when looking at how utvideo encoded inexisting values, I saw there was assembly for the vlc, but I really don't want to go down that road [22:00] <kurosu> I don't think there's much to improve in the encoder, except for context=1 multithreading [22:01] <llogan> so that's what my quit message is. how dumb. [22:50] <kierank> what does "epel" refer to? [22:50] <kierank> oh eighth [22:50] <kierank> duh [22:54] <cone-576> ffmpeg.git 03Lou Logan 07master:3fc37a3d2f13: doc/filters: remove double quotes from zoompan example [22:59] <cone-576> ffmpeg.git 03Michael Niedermayer 07master:d82ecfce07d1: cmdutils: implement FFREPORT=level=... [23:09] <llogan> michaelni: seeing cmdutils reminds me that there is a trivial patch involving it in ML: "version string: add copyright line to version string" [23:33] <cone-576> ffmpeg.git 03Michael Niedermayer 07master:378ad2249231: ffmpeg: print values of mismatching has_b_frames [23:33] <cone-576> ffmpeg.git 03Michael Niedermayer 07master:5ded0b390b61: ffmpeg: for h264 we need has_b_frames from the decoder [23:36] <michaelni> llogan, yes, should it be applied ? if so dont hesitate to apply [23:44] <kierank> gah why can changing hevc asm break resample [23:45] <kurosu> kierank, hevc asm clobbers some regs it doesn't declare as using? [23:46] <kierank> literally all i've done is move the init_xmm below and got rid of the sse4 name in the table [23:46] <kierank> and resample breaks [23:46] <kurosu> ok then that's too small a change to cause that at first guess [23:49] <kurosu> kierank, was it passing before *with* resampling ? [23:49] <kierank> http://pastebin.com/kLXXQvKV is all i did [23:50] <kierank> hmmm breaks from git as well [23:52] <kurosu> so your test was already broken even before your change ? [23:54] <kurosu> beware than in some places, widths are not multiple of 4 (eg 2/6) and so pextrw is used [23:54] <kurosu> though that should only happen for epel, indeed [23:54] <kurosu> but for those sse4 is needed [23:55] <kurosu> *that in some places [23:56] <kierank> dunno but on my machine i've always had fate fail sometimes [23:56] <kierank> I remember why at some point [23:56] <kierank> I'll* [23:56] <kurosu> hevc or ? [23:56] <kierank> random tests [23:56] <kierank> just used to fail [23:56] <kierank> there was a reason iirc [23:57] <kurosu> overheating would cause errors only with simd code on a pc I had [23:59] <kurosu> btw, openhevc intrinsic code is really faster - like 3-5% overall [23:59] <kurosu> I didn't even start to study why [23:59] <kierank> dunno [00:00] --- Sun Jun 15 2014

1 0

ffmpeg.log.20140614
by burek 15 Jun '14

15 Jun '14

[01:09] <waressearcher2> I used command "ffmpeg some_stuff_here 2>&1 > out.txt" but it still outputs on the screen, is there an option for ffmpeg to output everything to file ? [01:10] <c_14> What you're looking for is ffmpeg tthththt 2&>1 > out.txt [01:10] <c_14> the location of the & is wrong [01:16] <waressearcher2> no, its not wrong [01:16] <waressearcher2> &1 is the thing [01:16] <waressearcher2> I always do 2> and &1 are two things [01:16] <waressearcher2> check "man bash" [01:17] <c_14> hmm, you're right [01:17] <c_14> guess my bash knowledge is a bit funky [01:17] <c_14> ffmpeg test >& out.txt works though [01:18] <sacarasc> ffmpeg blah &> cheese.txt [01:19] <waressearcher2> sacarasc: the "&> cheese.txt" is quite the same as "2>&1 > cheese.txt" [01:20] <sacarasc> http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html [01:20] <waressearcher2> but actually &> works [01:21] <waressearcher2> yes, I usually use &> in stead of 2>&1 but that time I kind of forgot [05:15] <Cykon> Anyone have any idea about my C++ piping problem as described here http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=15&t=2021&e=0#p6896 [05:39] <waressearcher2> c_14: you here ? [05:39] <waressearcher2> ffmpeg -f concat -i list_all.txt -i ../../_5/all.ac3 -ab 320k -ar 44100 -ac 2 -acodec libmp3lame -vcodec h264 -vb 3000k -s 1280x720 -r 30 -vf "fade=out:24900:360" -y -f avi out_all_2.avi [05:39] <waressearcher2> that is the output of that command http://sprunge.us/QFGg [05:39] <waressearcher2> I use that command to make file out_all_2.avi and it should be 14:02 long, now if I use mplayer on my PC it shows it is 14:02 long, correct one, but if I use ffprobe to check it's length it says its 15:07 long and also if I upload it on youtube it does show it is 15:07 long and after 14:02 there is black scree, where is the problem ? it should be [05:40] <waressearcher2> 14:02 long there is no more video, mplayer shows it right, why youtube thinks its 15:07 ? also when I upload it on youtube it says "we can't recognize video codec and audio codec" but they still process the video ? [05:42] <another> i guess c_14 is asleep [05:42] <waressearcher2> give me another c_14 [05:44] <waressearcher2> anyone else ? [05:45] <Cykon> You can call me whatever you want if you figure out why ffmpeg stops sending data to my windows pipe :) [05:46] <waressearcher2> can I call you with "C" word ? [05:46] <waressearcher2> "Cykon" [05:46] <Cykon> Well, the code is in C, so you sure can! [05:46] <waressearcher2> it will be long long word or even double float word [05:47] <Cykon> lol [05:47] <Cykon> This is getting frustrating -.- I wrote the same thing in python and it worked just fine... port it to C and it only sends over half a frame and then sends no data after [05:49] <waressearcher2> imagine if ffmpeg was written in python, how fast it could've been ? 20x slower ? [05:51] <Cykon> Lol [05:51] <Cykon> I'm trying to pipe raw rgb 24 data in, edit it, and pipe it back out [05:51] <Cykon> Piping in and out worked fine in python... but man [05:51] <Cykon> imagine trying to edit it... [05:52] <Cykon> In my C code piping data out works completely fine... but the input pipe stops reading after like 40k bytes [05:53] <waressearcher2> there are #c and #programming [05:54] <Cykon> Yeah, I might have to try hopping over there soon. [05:59] <Cykon> Hmm, changing the output to rgb8 and data is coming through now [06:07] <Cykon> ffmpeg.exe -i testvid.avi -f rawvideo -pix_fmt rgb8 - [06:07] <Cykon> anyone see anything wrong with this? Should take testvid.avi and output it in the raw in rgb8 into stdout? [06:50] <Cykon> Hmmm.... it seems even a pipe I wrote from scratch stops sending data through after some time [08:57] <Cykon> When ffmpeg delivers a sample downstream to a pipe, does it wait until that data is read until it sends a new chunk of data? [08:57] <Cykon> or does the pipe keep filling up [11:41] <erle-> is there a way to tell ffmpeg that it should just encode but stop when a certain size is reached/ [11:41] <erle-> ? [11:41] <erle-> for example: i specify input video, codecs and bitrate [11:41] <erle-> and then it starts [11:41] <erle-> and it should just cut the video at 5MB size [12:28] <c_14> waressearcher2: The reason the resulting video is 15:06.10 long is because ffmpeg is detecting the length of the ac3 stream to be 15:06.10 [12:30] <c_14> erle-: If you manually set the bitrate you can calculate duration = size / bitrate and then use -t duration [12:31] <c_14> waressearcher2: you can add -shortest to the output options and ffmpeg will stop encoding when the end of the shortest input (in this case the video) is reached. [13:15] <erle--> c_14, it is obvious, that I can do that, but that is not what I want [13:17] Action: c_14 just found -fs it looks like that should do what you want [13:24] <erle--> c_14, thanks, i will try [13:25] <erle--> c_14, it is exactly what i was looking for [14:01] <waressearcher2> strange I can't find "-preset" in "man ffmpeg" but if I use ffmpeg with option "-preset ultrafast" it understands it [14:02] <c_14> It's in ffmpeg-codecs under libx264 [14:02] <waressearcher2> but I also tryed search in "man ffmpeg-all", not here but should be that man page should contain all information [14:03] <waressearcher2> not in "man ffmpeg-codecs" also [14:03] <c_14> Just go into man ffmpeg-codecs, search for libx264 and scroll down a bit. [14:03] <c_14> It's listed as preset not -preset [14:04] <waressearcher2> but there is no keyword "ultrafast" [14:05] <c_14> The actual presets are listed in x264 --help [14:05] <JEEB> preset is a libx264 (and libx265 now) specific option [14:05] <JEEB> basically if you set an unknown preset there, it's not ffmpeg that will bark at you, but the libx264 library [14:05] <JEEB> because it's all built in there [14:06] <JEEB> http://mewiki.project357.com/wiki/X264_Settings#preset [15:37] <Fyr> guys! how to get ffmpeg to make two-pass encoding? [15:37] <Fyr> I set -pass 2, but get error: [15:37] <Fyr> "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [15:38] <Fyr> if I run the program without it, it goes normally. [15:39] <Fyr> (h264) [16:00] <Fyr> I recompiled ffmpeg, nevertheless it can't load cpu more than 900%. [16:22] <bornpilot1> would using CRF and b:v together be defeating the purpose of CRF? I am guessing that I should use either one or the other? [16:23] <BtbN> they are mutualy exclusive [16:24] <BtbN> crf means a constant quality while adjusting the bitrate. cbr means a constant bitrate while adjusting the quality. [16:24] <BtbN> crf is able to take some hints, like max bitrate, though [16:25] <BtbN> where it stops increasing the quality at some point [16:36] <bornpilot1> BtbN so if I use minrate and maxrate without bitrate and use CRF I should each image should be consistently good based on the bitrate range? [16:37] <BtbN> well, if there is a lot of movement and it hits the max rate quality will still degrade [16:37] <BtbN> and a min rate doesn't make much sense for vbr [16:39] <bornpilot1> So, if I understand CRF it will provide a consistent looking image for each frame based on the the potential of the maxrate? [18:10] <Kiliko> When i cut of start and the end with 3-6 seconds, but now when i play my video i need to wait 2-3 seconds untill i get a picture. How can do so ill have picture from the start of my video? i run ffmpeg with "-ss 4 -tt 90 -vcodec copy -acodec copy" [18:11] <c_14> First of all, -tt isn't a valid option. Do you mean -t or -to? [18:11] <Kiliko> ops, it should be just "-t" [18:12] <c_14> try using -ss as an input option [18:14] <c_14> But, since you're stream copying ffmpeg can only cut at vframes, so the accuracy of the cut will change depending on the source [18:18] <Kiliko> c_14: Is it posiable to recode it with the same video codec format/settings and etc? [18:20] <c_14> If you know the settings, yes. But if you're using a lossy codec, you will lose quality even if it isn't noticeable. [19:32] <_genuser_> hello people [19:34] <_genuser_> I'm trying to extract a video stream from an mp4 (x264 video) to another *.mp4 container. and ffmpeg gives me an error. is this not possible? [19:35] <_genuser_> http://dpaste.com/1PPZ1G4 [19:36] <_genuser_> in this example. I change the output to .h264 to see if it change. even when I have .mp4 as extension for the outptu file, it says the same thing. [19:39] <c_14> I think the problem is that ffmpeg can't determine the video stream's resolution or display aspect ratio. [19:39] <_genuser_> even if you tell it to just copy it? [19:40] <c_14> apparently so [19:41] <_genuser_> original generated by handbrake. So possible they both write mp4 headers out differently. [19:42] <_genuser_> ln #20 also seems problematic. [19:43] <c_14> I think 40 is the issue, but if you put both lines together I'd assume there's something wrong with the original file/stream. [19:44] <_genuser_> c_14: thanks. :) I guess this file is not process-able then. :) [19:44] <c_14> You can always try reencoding and manually setting a dar or something. [19:44] <_genuser_> dar? [19:45] <sfan5> display aspect ratio [19:45] <_genuser_> I originally convert is using handbrake where I set dimensions, fps, etc. --keep-display-aspect -w 720 -l 480 --display-width 720 [19:46] <_genuser_> I know those are handbrake options and mean nothing for ffmpeg. Just saying I thought I controlled like a dictator. [19:47] <_genuser_> oh wait, let me try to set dimensions in ffmpeg manually if itallows [19:47] Action: _genuser_ goes to read the output of ffmpeg -h [19:48] <sfan5> man ffmpeg is probably more helpful [19:50] <_genuser_> windows world. [19:50] <_genuser_> well I do have ffmpeg on a linux machien too. so nm. [19:50] <c_14> https://ffmpeg.org/ffmpeg.html [19:50] <c_14> You can also use the online docu. [19:54] <_genuser_> heh, no go. shouldn't have deleted the source. :) [19:55] <_genuser_> x264 is indeed pretty crappy for editing. converted original with extra space in in front and behind the vide. [19:55] <_genuser_> and decided to chop it in ffmpeg using -ss and -t and audio is off. which trigger this de-merging and re-merging effort. [20:08] <_genuser_> found it. [20:09] <_genuser_> I think ffmpeg craps the dimensions when doing an -ss on a video/audio feed both. [20:09] <_genuser_> otherwise, it's been working on the source just fine extracting the video alone. [20:10] <c_14> works just fine for me [20:12] <_genuser_> 1) I generated mp4 (x264/aac) in handbrake. 2) If cut if in ffmpeg using ffmpeg -i <file> -ss 00:09:50 -t 00:20:03 .... 3) audio was off. 4) I tried to extra just the first and it gave the error we saw above. [20:12] <_genuser_> so I cange it to [20:12] <_genuser_> 1) handbrake 2) extra video alone, 3) extract audio alone, 4) cut each -ss -t, 5) cut audio again to align it with source 6) merge into single mp4 container. [20:13] <_genuser_> sorry for the horrible typos. My wireless keyboard batts are going out. dropping letter, adding extras.... [20:16] <c_14> I just took some random video I had lying around and did `ffmpeg -ss 50 -t 200 -i video.mp4 -codec copy out.mp4' and the resolution stayed fine [20:17] <_genuser_> and you can further process it in ffmpeg to let's say extract the vid only? [20:18] <c_14> `ffmpeg -i tmp.mp4 -codec copy -an video.mp4' works just fine [20:20] <_genuser_> interesting. this is the specific scenario that broke on my machine. [20:20] <_genuser_> as long as I was able to fix it using more chopping, eh? [20:21] <c_14> Maybe handbrake is generating corrupt output? Have you tried it with an mp4 not generated with handbrake? [20:22] <_genuser_> well, I extracted video only from a handbrake generated mp4. And ffmpeg worked just fine and extract the video alone. And then audio along separately. both in mp4 containers. [20:22] <_genuser_> so for that bit ffmpeg didn't have trouble recognizing the necessary resolution, etc. [20:23] <_genuser_> but hndebrake does have it's own problems. an update has fixed a bug that used to bug me. and broken what used to work before. requiring manual intervention on conversions. [20:23] <_genuser_> I can't just seem to put in place a script that can convert all my recordings quickly and efficiently. [20:23] <c_14> Why are you using handbrake to convert? You could just use ffmpeg. [20:26] <_genuser_> I spent lot of time testing and finding just the right handbrake options so that there's a really nice quality mp4 (x264) file generated that doesn't interlace or have blurs around fast motions. [20:26] <_genuser_> I just haven't spent the time to figure out how to map those options in ffmpeg. And just using plain ole x264 has generated lesser quality files. e.g.: [20:26] <waressearcher2> how to flip image or invert it upsidedown ? [20:27] <_genuser_> ffmpeg -i file.wtv -vcodec h264 -acodec aac output.mp4. [20:27] <_genuser_> also all my windows binaries do not support h264 conversion. only copy/decoding. I can compile my own on linux with enabled x264 and the quality didn't match. [20:27] <c_14> waressearcher2: look at the -vf vflip [20:28] <waressearcher2> found it -vf "hflip" [20:28] <waressearcher2> that pesky youtube blocking my video world wide so I need a fast solution [20:29] <c_14> _genuser_: pretty sure the static ffmpeg builds have x264 [20:29] <c_14> also, all handbrake does is pass the options to x264 which ffmpeg can do as well [20:29] <_genuser_> c_14: all my win binaries show D V D never E when doing ffmpeg -codecs [20:30] <c_14> http://ffmpeg.zeranoe.com/builds/ <- these ones have x264 [20:30] <_genuser_> c_14: but I'll try to download latest ffmpeg binary for windows. And do a quick map of options. if it just passes them along they might be exactly the same [20:30] <_genuser_> c_14: yeah, I was really thinking of setting a build environment on windows to compile it myself one day. but those will do. [20:31] <_genuser_> I used to have a build environment but that machien HD went out. [20:31] <c_14> -x264opts is probably what you want. IIRC handbrake used to (maybe still does) have a tab that listed what x264 options everything broke down to [20:31] <_genuser_> c_14: didn't use the GUI much. just used the docs to find what I wnated and spent hours, lol.' [20:35] <_genuser_> c_14: nice, this one does. I thought I had downloaded this one before too. but may not have checked it on this one. [22:13] <vtorri> hey [22:14] <vtorri> is it normal that ffmpeg 2.2.2 and 2.2.3 releases do not appear on the main page ? [22:27] <llogan> vtorri: it should have been done. probably by michael or me, but the download pages always have the newest release info. [22:28] <llogan> i'll try to remember to update the news too next time [22:30] <llogan> vtorri: there's also the FFmpeg twitter if you prefer that for getting release news (although a few of the releases for the older branches were missed). [22:31] <vtorri> llogan: ok [22:34] <llogan> vtorri: and of course the obligitory note that general users are usually recommended to use ffmpeg from git head instead of a release [22:36] <vtorri> ok [23:42] <waressea1cher2> can ffmpeg combine 4 videos with size of 640x360 into one 1280x720 ? [23:42] <waressea1cher2> 2x2 [23:43] <c_14> https://trac.ffmpeg.org/wiki/FilteringGuide#multipleinputoverlayin2x2grid [23:43] <c_14> a variation of that should do the tric [23:47] <c_14> *trick [23:59] <llogan> waressea1cher2: i just updated that example to be easier to read, hopefully. [00:00] --- Sun Jun 15 2014

1 0

ffmpeg-devel.log.20140613
by burek 14 Jun '14

14 Jun '14

[00:03] <J_Darnley> Well, that's quite obvious! I was only generating 1 video frame for each audio frame. [00:03] <J_Darnley> I needed to make ~6 times more. [00:28] <kurosu> -vf & co are actually kind of difficult to get/long to write [00:28] <kurosu> Am I that mad to think that maybe it could be instead read from a script a la avisynth? [00:28] <J_Darnley> Do you mean the actual filters or just the command line arguments? [00:29] <kurosu> imagine having .ffs file with #!/bin/ffmpeg ? [00:29] <J_Darnley> oh [00:29] <kurosu> command line [00:29] <wm4> kurosu: there's vapoursynth [00:29] <J_Darnley> I don't disagree with you [00:29] <kurosu> plus complex filtering like you get to see with avisynth are hardly manageable with command-line [00:29] <J_Darnley> I saw four (4) backslashes having to be used for paths on Windows [00:30] <ubitux> kurosu: that's why you can write them into files [00:30] <kurosu> wm4, ok, but doesn't your reply mean "scrap ffmpeg whole libavfilter ?" [00:30] <ubitux> you don't need to escape much when you're into a file [00:30] <wm4> kurosu: it could be made a libavfilter filter [00:30] <wm4> I mean, you could make a filter adaptor [00:31] <wm4> I've written one for my mplayer fork, I'd "only" have to port it to libavfilter [00:31] <kurosu> yeah, depends on how much you want to have a strong grammar/... (hmmm lex and bison...) [00:32] <kurosu> anyway, that's semi-serious [00:32] <kurosu> I'm already struggling with passing option to the noise filter [00:32] <ubitux> ? [00:32] <wm4> IMO the worst about lavfi API-wise is that it doesn't support proper seeking [00:33] <kurosu> ubitux, don't mind me, my first discovery of -vf was with that, 1 day ago [00:34] <ubitux> wm4: could you send a rfc on how that could be achieved? [00:34] <wm4> ubitux: seeking? [00:34] <ubitux> es [00:34] <ubitux> yes [00:34] <wm4> I'm not sure myself... [00:34] <wm4> I see two issues [00:35] <wm4> one is seeking the graph itself [00:35] <wm4> the other is being able to do precise seeking with lavfi [00:35] <wm4> (they're orthogonal to each other) [00:35] <ubitux> what would be the use case of seeking btw? [00:36] <wm4> example for the second issue: a filter adjusts timestamps 1 second into the future; so if you seek to time position 60 seconds, you really want to seek the decoder to the 59 seconds position; if you don't, you'll end up at 61 seconds instead [00:37] <wm4> for seeking the lavfi graph itself: don't know, maybe so that the libavdevice lavfi demuxer works? [00:38] <J_Darnley> Removing ads from the middle of a file. [00:38] <ubitux> you don't need seeking for that [00:38] <J_Darnley> Just request every frame in the middle? That's quick. [00:39] <ubitux> ? [00:39] <kurosu> not being sarcastical, but I kind of recall different projects using their own index to achieve accurate seeking with libav*? is it still needed? if yes then that's a first issue with having this in libavfilter [00:39] <ubitux> wm4: so you can seek when using a movie/amovie you mean? [00:39] <wm4> ubitux: I guess so [00:39] <Plorkyeran> yes, you still need an external index to be able to seek reasonably [00:40] <ubitux> wm4: is that really something blocking? [00:40] <wm4> ubitux: just an inconvenience [00:40] <wm4> kurosu: projects like ffms use an index [00:40] <wm4> others try to play tricks with the ffmpeg demuxer with moderate success (e.g. mplayer2/mpv) [00:41] <ubitux> J_Darnley: i'm not sure what causes you a problem; you probably use a select filter typically, or even do that at demuxing level with ffmpeg [00:41] <wm4> it'd be nice if lavf could create in index itself, especially for these broken audio formats like mp3, tta, ... [00:42] <J_Darnley> ubitux: perhaps, I've never done any non-linear filtering of video in ffmpeg. [00:42] <kurosu> the issue is that you need random amount of data prior to a timestamp, and I bet it's kind of hard to take this into account without knowing what the applications actually does [00:42] <ubitux> wm4: ffmpeg -i bla.mp3 bla.index && ffmpeg -idx bla.index -ss 12.3 out.mp3 ? [00:43] <ubitux> wm4: for that kind of usage? [00:43] <wm4> ubitux: since I have the playback case in mind, more like scanning the whole file on opening [00:43] <ubitux> J_Darnley: see also timeline [00:43] <wm4> so I can actually do precise seeking in semi-broken (unseekable) files and get correct duration info too [00:44] <kurosu> the case I had in mind was with libavfilter where you could get arbitrary requests of samples (audio or video) [00:44] <wm4> yes that would be nice [00:44] <wm4> probably something for a hypothetical high level API [00:44] <kurosu> that's what ffms does, but I don't know how much a pain it actully is [00:45] <ubitux> except that lavfi is stream based; you push frames into it& [00:45] <kurosu> ok [00:45] <Plorkyeran> ffms has to do very ugly things to support the api it offers [00:45] <Plorkyeran> but you could maybe make a similar api that allowed a simpler implementation [00:47] <wm4> what aspect of the api makes it complicated? [00:47] <Plorkyeran> guaranteeing that it can always give an accurate total frame/sample count is a big chunk of it [00:48] <Plorkyeran> it's what forces the indexing to parse every frame and decode the audio [00:48] <ubitux> j45: d150a147dac67faeaf6b1f25a523ae330168ee1e [00:49] <ubitux> didn't you actually rewrote that? [00:49] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d150a147dac67faeaf6b1f… [00:50] <Plorkyeran> a lot of the ugliness in the audio stuff is due to that lavc's decoders don't really try to support sample-accurate seeking to begin with [00:51] <Plorkyeran> and there's no real solution to that other than lots of test cases and lots of developer effort [00:54] <ubitux> j45: anyway, ffmpeg supports the multiple objects in pgs since this date (beginning 2012), it would be nice to avoid re-inventing the wheel once again [00:59] <wm4> is this about finally fixing pgs subs in libav? [00:59] <ubitux> it seems there is also the cropping feature in [01:19] <nevcairiel> i think its weird how so many people rather spent hours and hours re-inventing a feature instead of spending 5 minutes looking if a patch already exists =p [02:03] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:c5fc8ae12622: avcodec/mpegvideo: fix edge emulation with uvlinesize below 25 [02:41] <Compn> removing ads is so easy with mencoder [02:42] <Compn> because mencoder multiple file input [02:42] <Compn> mencoder file1.avi -ss 30 -endpos 5:00 file1.avi -ss 8:30 -endpos 5:00 etc [02:42] Action: Compn looks at concat and sighs [02:45] <wm4> Compn: use mpv, it doesn't regularly create broken files that can only be played by mplayer [02:50] <Compn> wm4 : well i dont edit commercials , nor do i use mencoder much either [02:55] <cone-609> ffmpeg.git 03Vittorio Giovara 07master:4321e507564b: configure: use pkg-config for libx264 [02:55] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:1c5aa64a5927: Merge commit '4321e507564b2d8a5dfc630f8d6fefba6fdc1e92' [04:31] <cone-609> ffmpeg.git 03Michael Niedermayer 07master:cf9050c715b4: libavcodec/wmv2: remove dead code [07:37] <ubitux> so the pkg-config libx264 commit wasn't applied? [07:37] <ubitux> i really don't think prefering our hack to proper pkg-config and then fallback to pkg-config to be a good idea [07:38] <ubitux> anyone feeling that the hack as a fallback is the least insane compromise? [07:52] <jamrial> why would switching x264 detection to pkg-config generate so much trouble and user complains as Carl mentions? [07:52] <jamrial> has it done it for the other fifteen libraries we check with pkg-config? [07:53] <ubitux> because users currently explicit flags with --extra-cflags and --extra-ldlibs [07:53] <ubitux> and also because pkg-config is not installed everywhere [07:54] <ubitux> i guess that's his concerns [07:54] <ubitux> that's why i suggested to improve configure in his way to report a missing pkg-config (do it earlier than currently, because it's never displayed when needed) [07:55] <ubitux> and document the behaviour change [13:45] <Anshul_m> I am adding an AVOption in dvbsub module, i am taking reference from libavcodec/h264.c , I did not undestood why we are saving .option = h264_option in AVClass h264_class [13:47] <wm4> Anshul_m: so you can find the AVOptions when you have an AVClass [13:49] <Anshul_m> Thanks, It means i dont need that AVClass stuff. [13:49] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:681868cbbe8a: avcodec/mpegvideo: Fix psnr calculation with slice threads [13:50] <wm4> Anshul_m: well, lavc's architecture kind of forces you to use AVClass... [13:53] <BBB> Anshul_m: specifically, the avclass/avoptions combination allows the new options youre adding to be auto-exposed to the commandline (e.g. ffmpeg) [13:53] <BBB> Anshul_m: otherwise module-specific options wouldnt be visible in ffmpeg and they would be practically useless for a large subset of our users [13:57] <Anshul_m> BBB, I dont want to expose them to ffmpeg user, I am adding option compute_edt if we use it then end display time would be computed using pts [13:58] <nevcairiel> there is only one kind of option, if its available to API users its also available to ffmpeg users [13:59] <Anshul_m> so do I need to implement AVClass also [14:10] <BBB> why wouldnt you want to expose this to ffmpeg users? [14:10] <BBB> I mean, whats an option for if not exposed to the user? [14:11] <wm4> Anshul_m: how do you intend to use the option? [14:21] <Anshul_m> This option would be used when transcoding dvbsubtitle to any subtitle codec, to calculate timing correctly. [14:22] <Anshul_m> This option used by ffmpeg but not ffmpeg user [14:24] <wm4> ffmpeg is not the only user of libavcodec [14:24] <wm4> and also ffmpeg must only use public APIs of libavcodec [14:24] <wm4> so it needs to be an option anyway [14:25] <wm4> no idea if there's a way to make ffmpeg.c hide it, if it's not useful for the end user [14:27] <Anshul_m> My intension are not to hide for libavcodec user but I dont find it would be useful for ffmpeg user [14:30] <BBB> Anshul_m: how would ffmpeg use it? [14:30] <BBB> calling a specificly named option in response to some specific condition? [14:31] <BBB> thats kind of hideous [14:32] <Anshul_m> Thats what we agreed in mailing list :( [14:33] <Anshul_m> BBB, you should also write this opinion in Re: [FFmpeg-devel] [PATCH] dvbsub fix transcoding mailchain [14:34] <Anshul_m> my opinion was, this sollution ugly [14:34] <BBB> I agree [14:35] <wm4> that thread is big [14:35] <BBB> michaelni: where does swr calculate timestamps/durations? [14:35] <BBB> (assuming it does) [14:36] <wm4> hm I assume timestamp stuff happens in af_resample in lavfi [14:37] <michaelni> BBB, maybe swr_get_delay() returns a different value [14:37] <michaelni> wm4, wrong file [14:43] <michaelni> ist af_aresample [14:45] <wm4> eh [14:45] <wm4> so there's af_resample and af_aresample [14:45] <wm4> ok [14:51] <nevcairiel> sounds like one was merged [15:25] <Daemon404> ubitux, OK to push with the config option noted? [15:25] <ubitux> i don't care much, mostly suggestion [15:25] <Daemon404> ok [15:25] <ubitux> you can warn that it's an advanced option if you're not comfortable with it [15:26] <Daemon404> i only worry that it gets cargo culted [15:26] Action: Daemon404 remembers sameq [15:26] <ubitux> the worst that can happen is bad values [15:26] <wm4> what again were the reasons that better solutions are not possible? [15:26] <Daemon404> dynamically doing it is basically rewriting that part of swscale [15:27] <wm4> blargh [15:27] <Daemon404> that is the correct response [15:50] <cone-197> ffmpeg.git 03Derek Buitenhuis 07master:a4bd4733c0af: swscale: Allow the max filter size to be set at compile time [15:57] <plepere> michaelni, I've got problems trying your ./configure line. when adding the cflags, I've got a "gcc is unable to create an executable file" error. :/ [15:57] <J_Darnley> Obvious reply: what does the log say? [15:58] <michaelni> i would guess some package for 32bit x86 support in gcc isnt installed [15:59] <plepere> gcc -m32 -o /tmp/ffconf.zLn7rLGS /tmp/ffconf.uinrdnTd.o [15:59] <plepere> /usr/bin/ld: cannot find crt1.o: No such file or directory [15:59] <plepere> yeah, I guess so [16:00] <Daemon404> toolchain isnt multilib then [16:00] <Daemon404> afaik only debian based OS come with such a toolchain by default [16:00] <plepere> ok, works [16:01] <plepere> had to do : sudo apt-get install libc6-dev-i386 [16:03] <J_Darnley> On an unrelated topic... When trying to expand docs about writing filters, where would you people like me to do so? [16:04] <J_Darnley> At the moment I have written 2 more verbose example filters, one based on vf_null. They've got some good comments based on what I have learned. [16:05] <J_Darnley> I thought that it might be a "bad idea" to split this documentation into more files. [16:09] <J_Darnley> I will also send an email, later, and attach the two files. They need checking for correctness anyway. [16:20] <ubitux> any suggestion on a beat detection algorithm? [16:20] <ubitux> i might try to implement one in lavfi [16:22] <ubitux> i see the causal beat tracking [16:22] <ubitux> but there is also a non-official paper (more like a howto from a tech guy) using simple fft & subbands [16:22] <ubitux> which i'm tempted to try [16:23] <J_Darnley> The one from Nullsoft's AVS? I would have to get to that eventually if I want to rewrite the entire library. [16:29] <cone-197> ffmpeg.git 03Tim.Nicholson 07master:6a65f3fc162f: MAINTAINERS: Added Tim Nicholson's key fingerprint [16:29] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:4a0ec85b8509: avcodec/rv34: fix edge emu with uv stride <= 25 [16:59] <plepere> michaelni, what else will you test, so I don't have to send a patch adding a single character to the previous one ? [17:01] <michaelni> i have no list, was just trying to detect as many issues as possible before it gets approved and pushed [17:02] <plepere> ok ok [17:03] <plepere> it's just sad to do a patch just to add a single character. [17:03] <nevcairiel> you could smiply wait a bit for more feedback if you dont want to send a new one immediately [17:04] <plepere> I can do it and be done with it. :p [17:06] <plepere> anyways, i'll be going now. see you all [17:09] <gerion> good day [17:09] <gerion> do you have something like linked lists or vectors in the framework predefined? [19:01] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:dffb85a98271: avcodec/mpegvideo: check that linesize is not too small [19:09] <cone-197> ffmpeg.git 03Diego Biurrun 07master:f0ce9913d097: Rename tpel_template.c ---> pel_template.c [19:09] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:684a9152c3b9: Merge commit 'f0ce9913d0974ac0c7371a62c3324dd2863b5d1b' [19:51] <cone-197> ffmpeg.git 03Diego Biurrun 07master:27631796c9d1: ac3: Only initialize float_dsp for the float encoder variant [19:51] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:97c285e61bc3: Merge commit '27631796c9d1b8146ad4a16e6539ecc08afa7565' [21:12] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:1df441eaa81b: vfilter/avf_showcqt: fix 'mixed declarations and code' [21:12] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:043bcdcdb00e: avcodec/svq1enc: fix encoding of small widths [23:20] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:263aeb826d1f: avfilter/vf_unsharp: use av_malloc_array() [23:20] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:d03eefae4a88: avfilter/vf_dejudder: Use av_mallocz_array() [23:20] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:0a7ad6bf5122: avfilter/formats: Use av_realloc_array() [23:24] <Compn> heh [23:24] <Compn> wasnt able to access my isp mail [23:25] <Compn> access using webmail , crash webmail server :) [23:25] <Compn> access using webmail server in other state, crashes other state's webmail server :D [23:25] <llogan> it did not know how to handle Windows 3.1 users [23:25] <Compn> oh look they fixed it today :) [23:26] <Compn> what distro you using llogan ? [23:28] <llogan> Arch Linux mostly. [23:29] <Compn> probably asked you before :D [23:29] <Compn> need to switch to that soon... [23:30] <llogan> I thought you and Win 2k were going steady? [23:30] <llogan> i probably asked you that before too [23:30] <Compn> i had to upgrade because there werent drivers for 4tb hd in win2k [23:30] <llogan> upgrade to what? [23:31] <Compn> xp [23:31] <Compn> turns out winxp drivers cant handle more than 2tb :\ [23:31] <llogan> <whaa whhaaaahhhh trombone sound> [23:31] <Compn> yes [23:31] <Compn> lol [23:32] <Compn> my old motherboards wont even boot with the 4tb drive attached :) [23:32] <llogan> i bought a bunch of WD Red 4 GB for a network file server. seem to work goodnuff. [23:32] <Compn> probably need a sata pci card or somethin [23:33] <Compn> or just upgrade to a non-10 year old puter [23:33] <Compn> they dont make bios updates for the old mobo either , so pfft [23:34] <Compn> first world problems [23:34] <llogan> i said that same phrase to myself earlier today [23:36] <Compn> picked up a googletv device [23:36] <Compn> learned that GTV is an android fork , so basically most android apps dont work on it [23:36] <Compn> worthless! :D [23:37] <Compn> maybe i will install gtv ndk and try to compile mplayer for it [23:43] <iive> Compn: looks like you are having fun :) [23:47] <iive> llogan: 4GB disks? (not 4TB) [23:51] <llogan> oops. a 12 GB server. awesome. [23:55] <iive> :) [00:00] --- Sat Jun 14 2014

1 0

ffmpeg.log.20140613
by burek 14 Jun '14

14 Jun '14

[00:00] <sanmarcos> ok [00:00] <sanmarcos> formats now shows avfoundation [00:00] <sanmarcos> it must be only in git [00:02] <sanmarcos> http://pastie.org/9284895 [00:03] <sanmarcos> getting : Input/output error on listing devices [00:03] <sanmarcos> both with qtkit and avf [00:03] <sanmarcos> apparently it doenst support audio [00:03] <sanmarcos> only video? [00:04] <MDTech-us_MAN> c_14 [00:04] <llogan> nothing from: ffmpeg -f avfoundation -list_devices true -i ""? [00:04] <MDTech-us_MAN> I'm confused [00:05] <MDTech-us_MAN> is -ss the length from -t or length from the beginning of the audio [00:05] <c_14> -ss seeks from the beginning of the file to the point specified. [00:06] <MDTech-us_MAN> -ss is where to start [00:06] <MDTech-us_MAN> cutting [00:06] <c_14> yes [00:06] <MDTech-us_MAN> what about -t ? [00:06] <sanmarcos> http://pastie.org/9284899 [00:06] <sacarasc> How long to cut for, MDTech-us_MAN. [00:06] <MDTech-us_MAN> Thats it! [00:06] <MDTech-us_MAN> I was getting these very long files [00:06] <MDTech-us_MAN> no I understand [00:06] <MDTech-us_MAN> *now [00:07] <MDTech-us_MAN> I was specifing where to stop instead of the length [00:07] <sacarasc> To do that, you use -to [00:13] <johny-b-goode> hello folks. I'm trying to extract a video out of a mp4 file. Is the following not the correct format? (it gives me an error). [00:13] <johny-b-goode> ffmpeg -i Friends_The\ One\ With\ the\ Boobies.dvr-ms.mp4 -vcodec copy video.mp4 [00:14] <johny-b-goode> it generates an error: aac @ 0x9422900] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it. [00:14] <c_14> add -an [00:14] <c_14> If you only want the video that is. [00:14] <johny-b-goode> c_14: does mean audio none? [00:14] <c_14> ye [00:15] <johny-b-goode> ok, thank you. that worked. :) [00:16] <johny-b-goode> On my windows machine I extract the audio the same way by doing a -acodec copy without having to specify any video options. [00:16] <llogan> sanmarcos: i'm not sure if it supports audio. docs don't explicitly mention it. might have to ask on ffmpeg-user or look at code. [00:17] <c_14> johny-b-goode: ffmpeg by default usually maps one video and one audio track, but with the audio you're probably using a format that only supports audio so ffmpeg throws away the video [00:17] <llogan> sanmarcos: and i wonder why it is not listed in ffmpeg -devices [00:17] <johny-b-goode> c_14: that makes sense. I'm extract it to a .wav file. [00:18] <c_14> If you were to extract it to something like .h264 then it should throw away the audio by itself. [00:19] <sanmarcos> llogan: i think I Will give up for now [00:19] <sanmarcos> llogan: file a bug with VLC and have them fix their crash on OS X [00:20] <johny-b-goode> c_14: I see, I was extract video to mp4 so it probably kept the audio because of that. [00:20] <johny-b-goode> *extracting [00:21] <johny-b-goode> lol: [mp4 @ 0x93b0140] Malformed AAC bitstream detected: use audio bitstream filter 'aac_adtstoasc' to fix it ('-bsf:a aac_adtstoasc' option with ffmpeg [00:22] <johny-b-goode> but the aac was formed by ffmpeg itself by converting from ac3. heh. [00:30] <DelphiWorld> sup guuys [00:30] <DelphiWorld> hi c_14 [00:30] <DelphiWorld> that work for some seconds then saying convertion failed [00:30] <c_14> Can I have some context again? [00:31] <DelphiWorld> c_14: pushing to rtmp [00:31] <DelphiWorld> using that cmd [00:31] <DelphiWorld> it works for some seconds [00:31] <DelphiWorld> then x264 saying convertion failed [00:34] <DelphiWorld> c_14: what the best way to redirect ffmpeg log to file? [00:34] <c_14> -report [00:34] <DelphiWorld> -report filename? [00:34] <c_14> ye, without a filename it goes into ffmpeg-date or something [00:35] <DelphiWorld> hehe, fun one [00:35] <DelphiWorld> ok c_14 http://pastebin.com/J7izza9S [00:37] <DelphiWorld> flv complain about malformed aac [00:37] <c_14> What's your current commandline? Have you tried adding -bsf:a aac_adtstoasc to it? [00:38] <llogan> DelphiWorld: how many times have you been here, yet you omitted your actual command [00:38] <DelphiWorld> command: [00:38] <DelphiWorld> i am changing it, yes [00:38] <DelphiWorld> .../usr/local/bin/ffmpeg -re -f mpegts -i http://192.168.0.188:4271/bysid/3017 -r 30 -c:v libx264 -crf 18 -profile:v baseline -maxrate 400k -flags -global_header -c:a libfdk_aac -b:a 64k -ar 44100 -f flv rtmp://192.168.0.13:1935/live/sunna2 [00:38] <relaxok> my console output when encoding video, shows the bitrate i passed with -b, but when i check the output file that was created, it's a different bitrate [00:38] <relaxok> blargh [00:39] <relaxok> (the original one) [00:40] <DelphiWorld> here you go c_14, /usr/local/bin/ffmpeg -re -f mpegts -i http://192.168.0.188:4271/bysid/3017 -r 30 -c:v libx264 -crf 18 -profile:v baseline -maxrate 400k -flags -global_header -c:a libfdk_aac -b:a 64k -ar 44100 -bsf:a aac_adtstoasc -f flv rtmp://192.168.0.13:1935/live/sunna2 [00:40] <DelphiWorld> but still shutting down [00:40] <relaxok> http://pastebin.com/nSriuEiQ [00:40] <relaxok> wtf? [00:41] <c_14> DelphiWorld: does it work when encoding to a file? [00:42] <DelphiWorld> c_14: good pointed, yes its ongoing into a file [00:43] <c_14> So it only doesn't work with rtmp? [00:45] <relaxok> ffmpeg.org ha been dying all day for me on and off [00:46] <DelphiWorld> c_14: yep [00:46] <llogan> relaxok: the bitrate should be set automatically depending, AFAIK, on your frame size, frame rate, and profile (proxy, LT, standard, HQ, 4444) [00:47] <c_14> If you were to dump say 1 minute into a file and then use ffmpeg to stream that to the rtmp server with -codec copy, does that work? [00:48] <DelphiWorld> c_14: mmmm, you're so vissious:P [00:48] <DelphiWorld> you know what c_14 ? [00:48] <DelphiWorld> flag [00:48] <DelphiWorld> global header [00:48] <DelphiWorld> not accepting it in rtmp [00:52] <relaxok> llogan: -profile standard should work? [00:52] <DelphiWorld> -crf is abr? [00:52] <relaxok> -profile:v standard [00:53] <relaxok> std [00:53] <relaxok> i tried everything listed on the ffmpeg-codecs page [00:53] <relaxok> as a profile for prores [00:54] <relaxok> e.g. just tried: ffmpeg -i 42496EJ-00001_EJ0007.mov -an -c:v prores -profile:v proxy -y out.mov [00:54] <relaxok> 'undefined constant or missing ( in proxy' [00:54] <DelphiWorld> c_14: ok, stream up, now testing with client on hls [00:55] <relaxok> ah with the integer value it works [00:57] <llogan> standard is default [00:58] <DelphiWorld> llogan: all is up now:P [01:00] <DelphiWorld> llogan: 30fps is recomanded for hls, right? [01:01] <llogan> i'm not familiar with the HLS specifications [01:59] <ParkerR> Any idea what could be going on here? http://hastebin.com/itutafuxuv.pas [01:59] <ParkerR> I've tried a few different audio condecs to no avail [02:00] <ParkerR> Aha -c;a opus -strict -2 [02:11] <klaxa> if you want something more widely supported try vorbis [02:11] <klaxa> libvorbis provides more flexible encoding than the native encoder i think [05:06] <MDTech-us_MAN> hello [05:08] <MDTech-us_MAN> c_14 [05:08] <MDTech-us_MAN> you there? [05:09] <sacarasc> Just ask your question, there are more people than just c_14 here often. [05:10] <MDTech-us_MAN> What would be the best way to do the following: concatinate say... about 20 files I will do something and then split them up again the same exact way [05:11] <sacarasc> Write down the lengths and do it slowly? :D [05:11] <MDTech-us_MAN> :| [05:11] <MDTech-us_MAN> you are kidding? [05:11] <MDTech-us_MAN> I have to do this many times [05:11] <sacarasc> Why would you need to do that, may I ask? [05:12] <MDTech-us_MAN> I want to put everything together and apply ReplayGain to all of them [05:12] <MDTech-us_MAN> to average all the peaks out [05:13] <MDTech-us_MAN> I can do it individually, but then the tracks will still be different volume [05:15] <MDTech-us_MAN> sacarasc, sound ok? [05:18] <sacarasc> You might be able to script it to make it work better, but I am not sure how. [05:19] <MDTech-us_MAN> where would I go to get help on this? [05:21] <MDTech-us_MAN> sacarasc [10:25] <Darkfang1> Hi [10:26] <Darkfang1> Quick question: Is it an expected behaviour that x265-params option are ignored without any warning if the syntax is not key=val:key=val? It seems it is the same for x264 btw. [11:28] <wh-hw> ffmpeg -f video4linux2 -i /dev/video0 -an -vcodec libx265 cam.mkv [11:29] <wh-hw> hi, all , why this command take a [30536.203147] ffmpeg[17459]: segfault at 8 ip 00007f482a2ccd25 sp 00007fffaa618008 error 4 in libx265.so.1.1[7f482a1a0000+204000] error [11:29] <wh-hw> > [11:29] <wh-hw> ? [11:29] <wh-hw> any body help me ? [14:30] <KCLA5555> Anyone looking for a new apple laptop? I got 2 17" Apple MacBook Pro's 2.3GHz Quad i7 new in box. $500 each MSG ME [14:30] <sacarasc> KCLA5555: Please do not spam, you'll get banned from the network. [15:49] <dericed> anyone got a working example of the metadata option in drawtext, i can seem to get it to work? [16:41] <dericed> for instance this command doesn't show the last pix_fmt value: ffplay -f lavfi -i color=white -vf drawtext="fontfile=/Library/Fonts/Courier New.ttf:text='test %{pts\:hms} %{metadata\:frame=pix_fmt}'" [17:15] <Moonlightning> sacarasc: what? o.o [17:38] <tlsa> hi [17:39] <tlsa> I want to skip certain frames from an input video to create an output video [17:39] <tlsa> I can read frames with av_read_frame(), and determine whether I want to skip them [17:40] <tlsa> what's the simplest way of putting the frames I want to keep into an output video? [17:40] <tlsa> ideally I want to leave the format and codec unchanged [17:59] <Mavrik> tlsa, you have to reencode the video [17:59] <Mavrik> so pretty much the full encoding loop [17:59] <Mavrik> you'll also have to renumber PTS/DTS to plug the holes [18:09] <iive> tlsa: you can skip frames that are not used as reference. that's mostly b-frames (and no b-pyramid). [18:11] <tlsa> what do you mean by renumber PTS/DTS? [18:11] <iive> if you remove i/p frames, everything that depends on them would be broken. [18:11] <iive> tlsa: he means to smooth it out. [18:12] <iive> like decimate filter. [18:13] <tlsa> by frames I mean "images", and I'm considering the "video" to be a series of "images", and I am skipping particular "images" in the output [18:13] <tlsa> I don't mind that I have to reencode it [18:13] <tlsa> if you see what I mean [18:13] <tlsa> so I don't think I need to worry about PTS/DTS [18:13] <iive> well, i thought you need something like stream copy and cut some parts. [18:14] <tlsa> yeah, but I can do that the lossy way [18:15] <iive> well, let's say that you remove every second frame. this would result of halving the fps. but you can pack them together, as result doubling the speed. [18:15] <tlsa> what I need to do is simply set up an output format/codec that matches the input (same dimensions, same frame rate, ideally same codec) [18:16] <tlsa> and I'm not sure how do do that [18:16] <iive> well, ffmpeg won't change image size and fps without explicit instruction to do that. [18:17] <iive> the output container is usually guessed by the extension or set by -f option. [18:17] <iive> as for the codec... i really don't know. [18:18] <tlsa> I'm not using the ffmpeg program [18:18] <iive> are you using ffmpeg libraries? [18:18] <tlsa> I'm using the ffmpeg C libraries (avformat, and avcodec) [18:18] <tlsa> yeah [18:18] <iive> then it should be easier to handle that. [19:23] <waressearcher2> ffmpeg -f concat -i list.txt -i audio.ac3 -ab 320k -ar 44100 -ac 2 -acodec libmp3lame -vcodec h264 -vb 3000k -s 1280x720 -r 30 -vf "fade=out:24900:360" -y -f avi video.avi [19:23] <waressearcher2> I use that command to make file video.avi and it should be 14:02 long, now if I use mplayer on my PC it shows it is 14:02 long so its correct, but if I use ffprobe to check it's length it says its 15:07 long and also if I upload it on youtube it does show it is 15:07 long and after 14:02 there is black scree, where is the problem ? it should be [19:24] <waressearcher2> 14:02 long there is no more video, mplayer shows it right, why youtube thinks its 15:07 ? also when I upload it on youtube it says "we can't recognize video codec and audio codec" but they still process the video ? [19:24] <waressearcher2> or should I say use *.mp4 as output format ? [19:25] <waressearcher2> s/scree/screen/ [19:27] <c_14> Try adding a -shortest, or a -to 14:02, and maybe pastebin the command and output so we can look at what ffmpeg is saying [19:32] <waressearcher2> I will recode it again and paste output but it will take few hours [19:33] <c_14> As long as you're just testing, you could add -preset ultrafast so that it doesn't take as long. [19:52] <Fyr> how many cores can I utilize with ffmpeg? [19:52] <c_14> Depends on the codec. [19:52] <Fyr> libx264? [19:53] <c_14> All of them. [19:53] <c_14> Should do so by default. [19:53] <Fyr> I set 12 cores, but I see only 600% cpu load. [19:53] <c_14> using -threads ? [19:53] <Fyr> yeah [19:54] <c_14> With libx264 you don't have to bother setting threads, it should do that automatically. [19:54] <Fyr> well, I set manually. [19:54] <Fyr> on 16-cored system, I see 400-600% workload a swell. [19:55] <c_14> It depends a lot on what you're doing. If the cpu isn't the limiting factor then you'll see 'low' cpu usage. [19:55] <Fyr> ok, how to find what limits ffmpeg? [19:57] <c_14> You'd probably have to check you system stats. It could be the IO. [19:57] <Fyr> now I have 900% cpu load! [19:58] <Fyr> IO isn't an option. [19:58] <c_14> IO as in your disks, if they're too slow reading, writing or seeking. [19:58] <Fyr> no, it's very fast. [19:59] <Fyr> how hardware acceleration such as opencl and cuda can increase conversion speed? [20:01] <c_14> opencl/cuda encoding for h264 is generally considered to be not worth it, but I'm not an expert [20:07] <c_14> https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ [20:07] <c_14> 4th question [20:10] <Fyr> I have two files - original video file and converted one. how to compare their quality? [20:10] <Fyr> is there a tool to do that? [20:10] <llogan> i never bothered to benchmark the opencl stuff [20:11] <llogan> i guess i should. got 800 vids in the queue [20:11] <c_14> Fyr: the only tool I know of that can give you an accurate analysis of the quality of a video file is the human eye [20:17] <sfan5> <c_14> opencl/cuda encoding for h264 is generally considered to be not worth it [20:17] <sfan5> why? [20:17] <Fyr> c_14, no it's not accurate. [20:18] <Fyr> I don't see any artifacts in picture. [20:19] <Fyr> but I'm pretty much sure that signal/noise ratio is beyond the limits [20:20] <Fyr> video is a signal. there were invented many methods to analyze it. [20:21] <Fyr> how can I subtract pictures? [20:21] <Fyr> the result will be a 2d-signal. [20:22] <Fyr> I will see signal/noise ratio in Fourier image of the picture. [20:25] <c_14> sfan5: I said that based mainly on internet sources I have found (which I can't find the links to right now) and the link I posted above where the faq for encode/h.264 states it. [20:26] <c_14> Fyr: As I stated, "the only tool _I know of_ [..]". There might be something that can do that for you, but I don't know of it. [21:11] <Fyr> c_14, just in case if someone ask you again: [21:11] <Fyr> http://superuser.com/questions/338725/compare-two-video-files-to-find-out-w… [21:12] <c_14> hmm, I'll look it over. Thanks. [21:43] <mjuszczak> Are there other ways to see how ffmpeg might have been compiled other than using ldd on it and running "ffmpeg" without options to see a truncated ./configure string (limited to 1k unfortunately). [21:52] <llogan> mjuszczak: what's wrong with "ffmpeg -version | grep configuration"? [21:54] <mjuszczak> Oh, HOLY COW! Thank you! :) [22:09] <mjuszczak> llogan: Are there other things I might need in order to know how ffmpeg was setup/installed? Use flags for instance? [22:12] <llogan> mjuszczak: what are you trying to do, exactly? [22:13] <llogan> maybe you'll want to know how any external libraries were configured? [22:34] <llogan_> my power strip shorted out on this server. cheap ass shit. [22:34] <llogan_> bad connection, not overload. [22:41] <Fjorgynn> why is 22050 better than 44100? [22:51] <iive> it is sampling rate, not max audio frequency. [22:52] <iive> if you want to represent a sine wave at 22050Hz, you need 2 values, one maximum and one minimum. this means that sampling rate must be at least double of the maximum audible rate. [22:53] <Fjorgynn> aha [22:56] <Mavrik> hmm, I doubt 22050 is ever better than 44100 :) [22:56] <Mavrik> well, except of generating half of data per second :) [22:57] <Fjorgynn> btw sox <3 [23:02] <Fjorgynn> sox input.wav -n noiseprof | sox input.wav sox-output.wav noisered - 0.2 && ffmpeg -i sox-output.wav -c:a libmp3lame -b:a 128k podcast.mp3 [00:00] --- Sat Jun 14 2014

1 0

ffmpeg-devel.log.20140612
by burek 13 Jun '14

13 Jun '14

[00:01] <kurosu> what's the specified max bitsize for a macroblock in MPEG2? 4000bits or something? [00:02] <kurosu> err 2400 [00:06] <kurosu> actually 4608 for 4:2:0, twice that for 4:4:4 [00:07] <michaelni> from quick approximation > 18kbit [00:07] <michaelni> for 4:4:4 [00:07] <kurosu> I've looked at the specs, it was clearly listed as the values I mention [00:08] <michaelni> its bad spec then [00:08] <kurosu> though I haven't checked how up-to-date they are [00:08] <kurosu> oh [00:08] <kurosu> mpeg-1 [00:09] <michaelni> coefficients can be stored as escape and that takes 6bit vlc 6bit run 12bit level * 2x2 blocks 8x8 per block x3 for yuv [00:09] <kurosu> actually not, it is mpeg-2 [00:09] <michaelni> this maxium is possibly not allowed though in valid bitstreams [00:10] <kurosu> table 8-6, ISO/IEC 13818-2: 1995 [00:12] <kurosu> https://www.itu.int/rec/T-REC-H.262/recommendation.asp?lang=en&parent=T-REC… <- this too [00:12] <michaelni> "8 Profiles and levels" <--- this lists whats allowed which isnt what could be stored in the bitstream [00:13] <kurosu> agreed [00:13] <michaelni> and i suspect many simple encoders do not check that they stay below this limit [00:14] <kurosu> anyway, 4:2:2 mentions unconstained, which is what you describe [00:15] <kurosu> anyway2, this is an example of probably how soon you may need to switch to cautious parsing with a granuality of a MB [00:19] <michaelni> yes [00:22] <kierank> iirc 4:4:4 is not defined fully [00:55] <cone-113> ffmpeg.git 03Christophe Gisquet 07master:508e7a5c16c9: x86: huffyuv: fix {add,diff}_int16 [01:02] <llogan> ffplay -f x11grab -video_size $(xwininfo -root | awk '/geometry/ {print $2}' | cut -d "+" -f 1) -fs -i :0.0 [01:02] Action: llogan convulses [01:05] <llogan> even better w/o -fs [01:08] <ubitux> llogan: http://trac.ffmpeg.org/ticket/2563 [01:09] <wm4> llogan: what am I looking at [01:10] <wm4> does it multiply the conversion errors? [01:11] <llogan> just weirdness. for me at least. flickering and duplicating rendered windows [01:11] <llogan> hundreds of mouse arrows [01:13] <ubitux> oh i didn't realize [01:13] <ubitux> ahah awesome [01:14] <llogan> ubitux: https://github.com/lolilolicon/FFcast2/blob/master/xrectsel.c [01:14] <ubitux> i don't know what the hell is going on but it's awesome [01:14] <wm4> llogan: well I see blue and orange goo emerging [01:14] <wm4> llogan: and conquering the screen and travelling left [01:14] <llogan> goo? also weird. [01:15] <ubitux> llogan: so why isn't this an option in the x11grab code? [01:15] <ubitux> i don't understand people :( [01:15] <llogan> not sure if it is useful or clean, but allows user to draw a box on screen or select a window to select area to record. [01:15] <llogan> IIRC+AFAIK [01:16] <ubitux> yeah right [01:16] <ubitux> but it could be in the lib. [01:16] <ubitux> as a simple option [01:16] <llogan> yes, that would be nice [01:21] <wm4> so, how does ffplay actually set options? [01:21] <wm4> I find this pretty confusing [01:21] <cone-113> ffmpeg.git 03Luca Barbato 07master:2f4170312f60: libx264: Support bitrate reconfiguration [01:21] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:8159fe255cca: Merge commit '2f4170312f605c1f02a14c01347e94cf46726dbd' [01:21] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:3a1c8951bc88: avcodec/libx264: fix "bitrate reconfiguration" [01:21] <wm4> with ffplay -video_format just works, but API-wise it's not clear what to use... [01:22] <wm4> seems like av_opt_set doesn't work, but putting it into the AVDictionary passed to lavf works [01:25] <BtbN> Anyone familiar with using vdpau with libavcodec? I got it somewhat working, but the resulting image is jumping around like it's not propperly ordered by pts, and the quality is extremely bad, i have extreme movement artefacts which aren't present when decoding in sw mode. [01:25] <wm4> BtbN: new or old api? [01:25] <BtbN> uhm [01:26] <BtbN> i looked at the XBMC code to learn how to do it [01:26] <wm4> sounds like a bad idea [01:26] <wm4> xbmc love hacks [01:26] <BtbN> well, i couldn't find any documented examples, so looking at existing code was the only way i found to learn about it [01:27] <BtbN> i believe XBMC uses the new api. It uses get_format to select the VDPAU pixel format [01:27] <wm4> here is the "example": https://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_vdpau.c [01:27] <wm4> yes that sounds like new api [01:27] <wm4> and they also don't set the slice callback? [01:28] <BtbN> it sets a AVVDPAUContext in the AVCodecContext and set render2 there [01:28] <wm4> render2? sounds wrong [01:29] <wm4> although it should also work [01:29] <BtbN> From looking at the ffmpeg vdpau code render2 is just the same as setting render + decoder, just that you can do some more stuff on render. [01:29] <BtbN> XBMC creates the decoder there, i believe to react to format changes [01:29] <wm4> yeah [01:30] <wm4> no [01:30] <wm4> that shouldn't be needed [01:30] <wm4> fromat changes call get_format, so you can do it there [01:30] <wm4> although render2 might be useful for some things, it's probably better not to use it [01:30] <wm4> and libav doesn't have this callback at all [01:30] <BtbN> ah, ok. That makes the code a little easier [01:31] <wm4> pts is handled like with the software decoder [01:31] <wm4> and the decoder of course returns the frames in display order [01:32] <BtbN> I completely ignored PTS in sw decoding mode, and just displays the images in the order decode2 returned them [01:33] <BtbN> https://gist.github.com/BtbN/040907be634ac3595433 that's what i got so far [01:37] <wm4> there's an avcodec function somewhere to map the codec profiles [01:38] <wm4> assigning reorderd_opaque shouldn't be needed anymore [01:39] <wm4> setting the thread count in get_format is probably not sane [01:39] <wm4> setting slice_flags should be unneeded and is probably harmful too [01:40] <wm4> in general I'd set all these fields right from the start [01:40] <BtbN> that part is basicaly straight from XBMC code [01:40] <wm4> instead of trying to forcing them in get_buffer [01:40] <wm4> that doesn't mean it's a good idea [01:40] <Daemon404> get_buffer is deprecated [01:40] Action: Daemon404 runs [01:40] <wm4> err I mean get_format [01:41] <BtbN> I kind of feel like avcodec is doing its job fine, and it's something in my rendering code that chokes [01:41] <wm4> it's setting SLICE_FLAG_CODED_ORDER [01:41] <wm4> what [01:42] <wm4> p->extradata = std::vector<uint8_t>(p->vstream->codec->extradata, p->vstream->codec->extradata + p->vstream->codec->extradata_size); [01:42] <wm4> p->lavcCtx->extradata = p->extradata.data(); [01:42] <wm4> p->lavcCtx->extradata_size = (int)p->extradata.size(); [01:42] <wm4> broken [01:42] <wm4> extradata needs input padding [01:43] <wm4> it also sets a bunch of wtf fields [01:43] <wm4> debug_mv - what [01:43] <wm4> so yeah I'd rather copy&paste the ffmpeg_vdpau.c code, if you must [01:44] <BtbN> I'm not in a rush, it was more like me beeing "meh, they're propably setting that for a reason" [01:45] <Daemon404> wm4, btw xmbc is the only other project besides mplayer which has hacks inside ffmpeg [01:45] <wm4> the xbmc style of development seems to be to hack on stuff as hard as they can until it somehow works [01:45] <Daemon404> there was some // for xmbc [01:45] <Daemon404> and stuff [01:45] <wm4> lol [01:45] <BtbN> The XBMC render code is extremely wtf, yes [01:45] <Daemon404> some people hered a derp when i removed a private symbol that was being exported with a //hack for xmbc comment [01:45] <BtbN> but it works somehow [01:45] <Daemon404> herped* [01:45] <wm4> well if it wouldn't work they'd obviously hack it some more until it does [01:45] <BtbN> xbmc also has its private fork of ffmpeg which they keep patching [01:46] <wm4> yeah, stuff like that [01:46] <Daemon404> reminds me of ffdshow [01:46] <BtbN> mainly to overcom the libav situation, but as it's already there, they can as well patch it [01:46] <Daemon404> //ffdshow custom code [01:46] <Daemon404> all over the place [01:50] <BtbN> https://btbn.de/files/screen.png that's what the rendered video looks like. The artifacts is where the thing has moved along [01:52] <wm4> BtbN: remove hacks first [01:53] <BtbN> removed most of them, didn't change a thing. I don't realy think its a problem in libavcodecs side of things [01:53] <wm4> next make sure you manage frames correctly [01:53] <wm4> e.g. you don't reuse a frame when you shouldn't [01:54] <BtbN> I'll update the gist, wait a second [01:55] <BtbN> https://gist.github.com/BtbN/040907be634ac3595433 i forgot about the extradata, could that alone be the source of my issues? I'm doing the same for swdecoding and it seems to work [01:56] <wm4> forgot what? [01:56] <BtbN> to fix the extradata padding size adjustment [01:56] <wm4> well extradata needs alignment and padding [01:57] <wm4> so it's best to alloc it with av_mallocz [01:57] <wm4> and not C++ stuff [01:57] <wm4> but I don't know if it actually can lead to issues or if it's more a theoretical thing [01:57] <BtbN> av_mallocz automaticaly gives aligned memory? [01:57] <wm4> yes [01:57] <BtbN> ok, i'll just use that then. [01:58] <Daemon404> ... is an std::vectors's data even guaranteed to be contiguous? [01:58] <BtbN> yes [01:59] <Daemon404> right ok [02:03] <BtbN> https://gist.github.com/BtbN/040907be634ac3595433#file-decoder-cpp-L405 that should be ok? [02:04] <wm4> yeah [02:06] <BtbN> For the output frame management i'm using a class which has two state variables. One for "is in use by ffmpeg", i set it to 1 when the frame is got in GetBuffer2, and reset it to 0 after i got the frame from avcodec_decode_video2(). Maybe that is part of the problem, should i keep it occupied and not re-use it until ReleaseBuffer is called? [02:06] <Daemon404> man is there anything qt *doesnt* (re)implement... [02:07] <BtbN> Daemon404, well, Qt supports some exotic compilers and runtimes, and it had that stuff well before it got a C++ standard [02:07] <Daemon404> that doesnt mean qt5 needs it [02:07] <BtbN> they still do support stuff like msvc2008 [02:08] <wm4> BtbN: wrong [02:08] <BtbN> oh, they dropped 2008? [02:08] <wm4> BtbN: just because a frame is returned by the decoder it doesn't mean the frame is not needed anymore [02:08] <wm4> BtbN: you have to release the frame when the avbuffer for it is released [02:08] <wm4> BtbN: the avbuffer controls the lifetime of the frame [02:08] <Daemon404> should it automatically do that for you if you set the callback properly [02:09] <Daemon404> shouldnt* [02:09] <BtbN> ok, so that might already be part of the problem then. Is it ok to imediately use it for rendering? [02:09] <BtbN> Daemon404, currently i set the ffState to 0 after i got the frame from decode2, and not at all in the release callback [02:09] <BtbN> which i just realized seems wrong while writing up what i'm doing [02:10] <wm4> Daemon404: no, because lavc doesn't actually access vdpau [02:10] <BtbN> yep, that was it [02:10] <BtbN> image is de-broken now [02:10] <wm4> except for the render callback (which is very strange and why a mplayer dev added render2) [02:11] <BtbN> lol, i'm nearly completely using up my poor gt gpu with that. [02:11] <BtbN> 5 1080p videos at 120 fps is aparently a little much [02:12] <BtbN> The OpenGL vdpau interop seems to be fine with my massive multithreading. I suspected that to be the problem and was kind of afraid i have to completely redesign for hw acceleration [02:13] <BtbN> Now i just have to merge the sw decoding part back in [02:14] <nevcairiel> that reminds me that i need to write a opengl video renderer, i'm not looking forward to that [02:14] <Daemon404> nevcairiel, for work [02:14] <Daemon404> ? [02:14] <nevcairiel> yeah [02:15] <Daemon404> lul [02:15] <Daemon404> wm4 wrote a gl3 one iirc [02:15] <BtbN> nevcairiel, that was the easiest part. For vdpau as well as for swdecoding. [02:15] <nevcairiel> expanding to mac and linux [02:15] <BtbN> It's not even a lot of code [02:15] <BtbN> and it works on every platform [02:15] <wm4> BtbN: yeah vdpau is generally fine with threading [02:15] <nevcairiel> its probably not all that hard, but my last opengl was like 10 years ago [02:15] <BtbN> well, it's not a normal video render. More like a "render 5 videos and apply a magic shader to it" renderer [02:16] <wm4> how painful using opengl is depends mostly where it has to run [02:16] <BtbN> with all 5 videos beeing 1080p and 120 fps [02:16] <nevcairiel> does "not windows" help? [02:16] <BtbN> I'm using OpenGL 3.2 Core, it should work on a reasonable ammount of machines [02:17] <wm4> nevcairiel: also the driver... e.g. binary AMD drivers on linux are the worst shit ever [02:17] <wm4> mobile GLES drivers are often low quality etc. [02:18] <nevcairiel> for now only x86 desktop things are in focus, but that doesnt exclude amd shit sadly [02:18] <wm4> also Intel drivers [02:18] <wm4> there's one popular intel gpu that doesn't support any non-ancient opengl stuff [02:19] <BtbN> I was pretty surprised when using OSX in a VM lately [02:19] <BtbN> their OpenGL software renderer has full support for OpenGL up to 4.0 or 4.1 [02:19] <wm4> hm so opengl does work with osx in a vm? [02:19] <nevcairiel> one interesting tidbit is that i'll have to make it work flawlessly on a baytrail atom and its gpu, since we also have hardware devices that use that :p [02:19] <BtbN> wm4, yep [02:20] <BtbN> it's not fast, because software rendering, but it has full support [02:20] <wm4> soudns useful [02:20] <wm4> what vm? [02:20] <BtbN> HW acceleration isn't supported for OSX guests in vmware [02:20] <BtbN> i'm using VMWare workstation [02:20] <nevcairiel> oh well, i just started with the playback pipeline today, wont get to the renderer until a few more days [02:20] <BtbN> It's fine with running OSX as FreeBSD aparently [02:21] <BtbN> It even detected it's OSX and emulated an EFI [02:21] <BtbN> so i could install from my normal disk [02:21] <nevcairiel> i'm mostly worried about properly syncing audio and video up, but maybe it just manages to fall into place [02:22] <BtbN> yeah, timing stuff allways is extremely annoying [02:25] <BBB> ubitux: got more details? [02:27] <BBB> oh trac, I see [02:34] <BtbN> It seems to have issues with rewinding. It's jumping between old and new frames there [02:34] <BtbN> But apart from that it's seems to be running perfectly now. [02:37] <wm4> do you flush the decoder? [02:37] <BtbN> yeah [02:38] <BtbN> It's also not perfectly in sync between the 5 decoders. Sometimes one of them seems to be ahead for a frame or two, however that is even possible. [02:39] <wm4> why wouldn't it [02:40] <BtbN> because they are all decoding videos which have the exact same number of frames. So i'd kind of expect to get the matching frames if i call decode2 the same ammount of time on each decoder [02:40] <wm4> not at all [02:41] <wm4> scheduling etc. can introduce difference, so if you don't explicitly synchronize them, it's not surprising they desync [02:41] <BtbN> I am synchronizing the rendering if you mean that. I render the next frame only if i got a new frame from all 5 decoders [02:41] <BtbN> in sw decoding mode that works perfectly. [02:42] <wm4> yeah sounds like that should work [02:47] <BtbN> It's realy strange, like it's jumping ahead one frame, and then gives up on it. I have an idea where that's coming from though, the vdpau decoder might be too fast, so it's exhausting the texture pool and start over writing it from the beginning. [02:48] <wm4> you might have to wait for a vdpau surface before displaying it, not sure [02:52] <BtbN> yeah, i'm rendering it again into an OutputSurface, and then bind that to an OpenGL texture, which is then rendered. [02:52] <BtbN> maybe it just needs a glFinish call somewhere [02:53] <BtbN> but thank you very much, would have propably taken me ages to find that problem otherwise [02:57] <wm4> in my code I don't need glFinish [03:10] <Timothy_Gu> [10:07] <@Daemon404> why the fuck do people reply with "fails build because no default" <--- mind your language [03:10] <BBB> ubitux: fixed [03:11] <Timothy_Gu> Daemon404: i didnt see your "that was dumb of me" email [03:12] <Timothy_Gu> sorry about that [04:16] <cone-113> ffmpeg.git 03Ronald S. Bultje 07master:385a3420d1da: vp9/x86: fix overwrite in ipred_vl_4x4_ssse3. [04:24] <jamrial> wow, the cinepak encoder is absurdly slow [04:28] <BBB> lol cinepak encoder [04:49] <jamrial> bah, the whole split lanes in AVX sucks [04:49] <jamrial> it's all fine and dandy when you do stuff vertically, but as soon as you need to do stuff horizonally most of the benefits of having wider regs go down the drain [04:50] <jamrial> pshufb, psrl*, all with lane constrains [04:50] <fionag> yup ^^; [04:53] <jamrial> i'm looking at porting the rest of the intra pred vp9 functions, but they all need shifting and the split lanes ruin everything [04:53] <jamrial> they are probably going to need some palignr fest [04:58] <BBB> hehe [04:58] <BBB> jamrial: yeah thats a known issue :/ [06:52] <BtbN> wm4, yes, it actualy was just a glFinish it needed [06:53] <BtbN> i have 5+5+1 threads. 5 threads with the ffmpeg decoders, 5 OpenGL upload threads(which are quite pointless for VDPAU but present for swdecode compat) and the main render thread. Calling glFinish in the upload threads after mapping the VDPAU surfaces made it work perfectly. [08:04] <ubitux> BBB: thx :) [08:54] <cone-614> ffmpeg.git 03Ronald S. Bultje 07release/2.2:98f33430a2a7: vp9/x86: fix overwrite in ipred_vl_4x4_ssse3. [10:09] <durandal_1707> ubitux: are you going to apply showcqt fullhd option patch? [10:10] <ubitux> ah, i missed it [10:11] <ubitux> i guess i'll rebase it and resubmit it, since i fixed the style in between [10:12] <ubitux> durandal_1707: why do you ask, interested in this? [10:12] <durandal_1707> i expected it gonna be applied [10:14] <durandal_1707> changes looks fine to me (a tried it yesterday) [10:15] <ubitux> ok [10:16] <ubitux> well if you're motivated, go ahead [10:16] <ubitux> i'll try to do it in a day or two [11:16] <cone-614> ffmpeg.git 03Muhammad Faiz 07master:0a64fb7fb0bb: avfilter/avf_showcqt: add option for lower resolution [13:24] <BBB> ubitux: np [13:25] <cone-614> ffmpeg.git 03Anton Khirnov 07master:48e509213379: avconv: make -shortest work with streamcopy [13:25] <cone-614> ffmpeg.git 03Michael Niedermayer 07master:52ce6be86b6a: Merge commit '48e50921337984ba4ec2c1cafe45d43787f84498' [13:42] <BBB> michaelni: any more comments on the swr patch? [13:44] <BBB> michaelni: exposing ResampleContext is probably a bad idea, so Im not sure whats the right way yet - I suppose a function that returns -(c->index>>c->phase_shift) would be OK, any better ideas [13:44] <BBB> (unless you think this isnt ugly, in which case I suppose its fine) [14:03] <BBB> plepere: hm, why start over? whats so bad about the current asm that it needed a restart? [14:04] <plepere> I think it's better if things look the same for the same function [14:04] <BBB> then you should look at vp9 :-p [14:04] <BBB> its much more tuned for the big transforms [14:04] <plepere> and I guess that the x264 guys are better than be. :) [14:05] <plepere> D: I don't know what to believe now ! [14:05] <BBB> you should honestly do whatever you want [14:06] <plepere> where is your idct ? [14:06] <BBB> the problem of the h264/vp8 approach is that youll have two versions of functions, one for dc_add and one for regular idct [14:06] <BBB> for big transforms, thats very not-ideal [14:06] <BBB> the vp9 approach is more granular [14:06] <plepere> BBB : that's how it's done in openHEVC [14:06] <plepere> I think it's done for better ARM compatibility [14:06] <BBB> ffh264 has this nice trick where we do multiple 4x4s per call, vp9 doesnt do that yet (its on my TODO list, not sure Ill ever get to it) [14:07] <BBB> I call it the chicken-way out approach [14:07] <BBB> as in, you get 50% of the speed benefit, and thats enough for lazy people who can claim 50% of the credit [14:07] <BBB> I believe vp9s approach is much better, but its also harder for the dude writing the asm (ask ubitux) [14:07] <BBB> not much harder, but still a bit [14:08] <plepere> you'll have to convince mraulet. [14:08] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp9itxfm.asm;… [14:09] <BBB> it splits it in 4 function-parts, one for the dc only, one for the topleft 2x2, one for the topleft 4x4, and one for the full 8x8 [14:09] <BBB> and thats just for the 8x8 [14:10] <BBB> the 16x16/32x32 dont do all subsizes, because that was too much code and actually slowed it down (code cache) [14:10] <plepere> is it the same granularity for the 32x32 ? [14:10] <BBB> 32x32 does dc-only, topleft-8x8, topleft-16x16 and full 32x32 [14:11] <BBB> 16x16 does only topleft-8x8, full 16x16 or dc-only [14:12] <plepere> bah, I don't have much to say about how things are done in OpenHEVC. Maybe once I'm unemployed from here I'll take liberties. :p [14:12] <BBB> your decision structure is obscure, youre not a corportaion [14:13] <plepere> but for the moment I need to do the transform non-dc in asm [14:13] <BBB> mraulet isnt here btw [14:13] <plepere> yeah [14:13] <BBB> ... [14:14] <plepere> but basically, I'm going with the flow, He wants things done in a certain way and with results, so I just get it done. [14:14] <BBB> ok [14:14] <BBB> I dont mind the earlier patch you posted, but anyway, Ill await the h264 way of doing things [14:15] <BBB> how do you guys plan to manage people submitting code directly to ffmpeg? [14:15] <BBB> what if I send a patch to ffmpeg to add new/better asm? [14:16] <plepere> I think it's integrated back in openHEVC. The chanes are quite minimal for now (like ASM opts) [14:17] <plepere> if you change how transforms are done, it might be more tricky [14:18] <plepere> BTW, I might disconnect, some electric testing being done. [14:18] <BBB> ok [14:18] <plepere> openHEVC is open source [14:20] <BBB> ffmpeg and libav are both opensource, yet people rarely send patches to both [14:20] <j-b> which is why we need to do a 3rd fork :) [14:21] <ubitux> not enough ppl, there are only 2 dev split between 2 projects [14:21] <plepere> the horror [14:22] <plepere> anyways, once I'll be out of here, (and found another job) I'll try to keep working on FFmpeg's HEVC. [14:23] <plepere> I really want to do AVX2 functions [14:27] <Daemon404> [13:20] <@BBB> ffmpeg and libav are both opensource, yet people rarely send patches to both <-- basically only me [14:28] <BBB> //////////// [14:28] <BBB> ' [14:28] <Daemon404> wat [14:28] <BBB> ;/ mm./.;/ [14:28] <BBB> ? [14:29] <Daemon404> you typed a bunch of gibberish [14:29] <j-b> plepere: when do you chage job? [14:30] <plepere> j-b : my contract ends at the end of october. [14:30] <plepere> but I can leave mid september. [14:31] <plepere> I'm trying to find an opportunity outside of France if possible, but its complicated. [14:31] Action: Daemon404 notes most good engineers seem to be fleeing France for jobs elsewhere [14:32] <j-b> plepere: why complicated? [14:33] <plepere> Daemon404, I must admit that France is much like a sinking ship. I hope that after a couple of years abroad, I'll be able to come back with a good enough background to have a nice job back in France [14:33] <plepere> j-b : lots of people want to go abroad and companies prefer getting local engineers rather than going through the hassle of sponsoring a visa and all that. [14:34] <plepere> got an interview for a 2 year contract in Singapore, though, which is like... the best thing ever for me. :D [14:35] <plepere> ok, turning things off. brb [14:37] <Daemon404> michaelni / ubitux -- any comments on the sws filter size patch besides configure stuff? [14:38] Action: ubitux will only comment on the configure part [14:38] <ubitux> Daemon404: configure is annoying? [14:38] <BBB> Daemon404: that was my kid [14:38] <Daemon404> BBB, oh ok [14:38] <BBB> :) [14:38] <Daemon404> i thought maybe a cat [14:38] <Daemon404> a child makes sense too. [14:38] <BBB> close [14:39] Action: Daemon404 fiddles with lcms2 [14:39] <Daemon404> icc profiles can go to hell [14:54] <Daemon404> ubitux, i see [14:54] <Daemon404> so should i send a v3... or await more comments [15:01] <plepere> back ! [15:18] <ubitux> Daemon404: btw, no sanity check like pow of 2 required? [15:18] <Daemon404> ask michaelni [15:19] <ubitux> anyway no more comment from me i guess [17:44] <cone-335> ffmpeg.git 03Derek Buitenhuis 07master:4e9b46b05681: libx265: Actually use X265_API_IMPORTS [17:44] <cone-335> ffmpeg.git 03Derek Buitenhuis 07master:6ee95af8a118: libx265: Add 4:2:2 support [17:44] <cone-335> ffmpeg.git 03Derek Buitenhuis 07master:7ed89addb7f6: libx265: Remove unneeded bit depth check [19:19] <llogan> user is told to use something newer than 0.6. user "upgrades" to SVN-r15261 [19:19] <nevcairiel> is that actually newer [19:20] <llogan> idk [19:20] <llogan> still, a laugh track played out of thin air [19:20] <llogan> or Yackety Sax [21:12] <cone-714> ffmpeg.git 03Diego Biurrun 07master:dca7ba4bffe3: Remove some unnecessary CONFIG_FOO_COMPONENT ifdefs [21:12] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:c600c8e96699: Merge commit 'dca7ba4bffe3e4aeb620cb62955256a0d87561f4' [21:27] <cone-714> ffmpeg.git 03Derek Buitenhuis 07master:180e6b48060f: libx265: Actually use X265_API_IMPORTS [21:27] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:ff0631ab058b: Merge commit '180e6b48060f97fdd8497320395b61dc85664ecd' [21:30] <cone-714> ffmpeg.git 03Derek Buitenhuis 07master:61a344916d32: libx265: Add 4:2:2 support [21:30] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:451469fd1aa1: Merge commit '61a344916d324c8ca52064964478f46c877f02e2' [21:31] <cone-714> ffmpeg.git 03Derek Buitenhuis 07master:ceada893bec1: libx265: Remove unneeded bit depth check [21:31] <cone-714> ffmpeg.git 03Michael Niedermayer 07master:6286bb5c07dd: Merge commit 'ceada893bec1e29e457bd2b81d8a0b6fcba5f1f7' [21:43] <J_Darnley> Well... [21:43] <J_Darnley> I am sucessfully drawing frames with my skeleton of a filter [21:43] <J_Darnley> Just not as many as needed. [22:43] <cone-714> ffmpeg.git 03sfan5 07master:ffe6ecc418ad: lavd/avfoundation: Support user selected pixel formats and pixel format autoselection. [00:00] --- Fri Jun 13 2014

1 0

ffmpeg.log.20140612
by burek 13 Jun '14

13 Jun '14

[02:29] <relaxok> ffprobe with -report only logs the console output up to the point the data (like show_frames) starts [02:31] <relaxok> whats up with that? [02:34] <c_14> maybe with a line up to the point report logs? [02:39] <relaxok> here's the output up to the first frame of probed frames in the console window itself: http://pastebin.com/QjH1uE2W [02:40] <relaxok> and here's what's in the report log file: http://pastebin.com/B3Gcii00 [02:44] <c_14> I think -report only dumps those things that are written to STDERR (ie all ffmpeg encoding/decoding/etc output) but not the ffprobe output because that is sent to STDOUT and considered separate or something. [02:51] <relaxok> alright i just redirected it to another file [03:02] <c_14> ye, If I'm reading tho code right -report hangs itself into ffmpeg's log section. So it'll get a copy of everything that ffmpeg considers part of the log but not the special output of for example ffprobe -show_frames. [03:51] <MDTech-us_MAN> hello [03:52] <MDTech-us_MAN> when I execute command "ffmpeg -f concat -i <file>.wav -i <file>.wav ... -c copy output.wav" I get the following: [03:52] <MDTech-us_MAN> [concat @ 02898de0] Line 1: unknown keyword 'RIFF^¬ó?WAVEfmt' [03:52] <MDTech-us_MAN> C:\Users\Maxwell\Music\Fathers Day 2014\Act 1\normalized\123\cleaned\01 Clouds.w [03:52] <MDTech-us_MAN> av: Invalid data found when processing input [03:52] <MDTech-us_MAN> plz disregard the very long path [04:52] <relaxok> is there a way to use -map_channel without knowing the stream index of the audio? [04:52] <relaxok> -map_channel 0.a:0.0 or something doesn't work [06:18] <Moonlightning> Does ffmpeg compress better if invoked with no arguments? [06:19] <Moonlightning> I seem to remember running a video through it and getting out a much, much smaller file. Half the size or something. [06:19] <Moonlightning> Just `ffmpeg -i video.mp4 other-video.mp4` [06:20] <sacarasc> No. [06:20] <sacarasc> It does shit without you telling it to do better. [06:21] <sacarasc> Looks like arse, etc. [07:38] <BtbN> getting a video file small isn't hard [07:38] <BtbN> getting it small and good looking is [07:55] <gogoat100> anyone know why ffmpeg has been shelved for avconf in linux? [08:18] <superyes> can't seem to ffmpeg -f alsa grab audio, most I ever get is _incredibly_ quiet, static-y audio (like you can hear it with mplayer -af volume=100, but it's awful) [08:24] <gogoat100> same same [10:27] <termos> I get this weird output from ffplay after encoding with libx264 into mpegts "Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 720x480, 24 fps, 24 tbr, 90k tbn, 48 tbc". Is there something missing from some header? [11:05] <reactormonk> I'm streaming to witch via castawesome, but it breaks off after a while - console output: http://pastie.org/9282911 - ideas? [11:08] <wh-hw> hi, all [11:08] <wh-hw> how to transcoding a video over http use ffserver? [11:08] <JackWinter> is there some way to use lanczos3 for rescaling videos on ffmpeg/linux? [11:15] <cbreak-work> Hmm... ffmpeg still crashes with out of bounds memory access in sws' ff_rgb24ToY_avx [11:15] <cbreak-work> but the bounds that are passed to sws seem all correct [11:21] <wh-hw> hello [11:32] <cbreak-work> the input image has a size of 1280x720, so it is a perfect multiple of 4k, the page size of OS X here. [11:32] <cbreak-work> and the image ends exactly at a page boundary [11:33] <cbreak-work> and ffmpeg tries to read past the page boundary [11:33] <sekon> help ffmpeg spawned from shell works .. while the same spawned from python does not seem to work. Relevant code at https://dpaste.de/EozDC [11:33] <sekon> the output of ffmpeg is appended to the bottom of the post [11:35] <sekon> someone told me that ffmpeg is opening 'udp://127.0.0.1:27000&overrun_nonfatal=1': Permission denied [11:35] <sekon> as a file that is why i am getting the error [11:36] <sekon> this is the command i am trying to execute [11:36] <sekon> ffmpeg -re -i 'udp://localhost:27000&overrun_nonfatal=1' -flags -global_header -codec:a libfaac -ar 44100 -ac 2 -b:a 96k -b:v 500k -s 1280x720 -vcodec libx264 -crf 30 -preset ultrafast -r 25 -map 0 -bsf h264_mp4toannexb -f segment -segment_list /var/www/playlist.m3u8 -segment_list_flags +live -segment_time 2 -segment_list_size 5 /var/www/out%03d.ts [11:36] <sekon> from shell everything works as expected [11:36] <sekon> but from python it does not work [11:38] <cbreak-work> it seems ff_rgb24ToY_avx tries to read two times 16 bytes into two xmm registers [11:38] <cbreak-work> but of course since there are only 24 bytes per pixel, this fails with the last pixel [11:39] <cbreak-work> it uses vmovdqu, so it doesn't matter that it's an unaligned read [11:57] <JackWinter> or is the ffmpeg lanczos implementation actually lanczos3? [12:09] <sekon> running ffmpeg with pythons subprocess.Popen is giving a lot of problems [12:09] <sekon> the same string can be execed in a OS shell with no problems [12:12] <cbreak-work> sekon: maybe it's a python problem :) [12:12] <cbreak-work> sekon: do you read the standard output? [12:12] <cbreak-work> or do you tell ffmpeg to be quiet? [12:17] <sekon> cbreak-work: i read the ouput .. just a sec sorry [12:18] <sekon> i can exec the command its supposed to execute from shell [12:18] <sekon> but not from python's subprocess.Popen [12:19] <sekon> https://dpaste.de/O8CZ [13:26] <maksimkaaa> hello, I was trying mmcat, when passing two clips with frame rates of 12 and 1, the output seems to have just frame rate of 12 is there a way to retain the frame rate of each video as it is ? [13:43] <max246> hello [13:43] <max246> I have few qestions about the fading system [13:44] <klaxa|work> ask away then [13:46] <ph8> hey all i'm trying to build ffmpeg and fetch a file from a url to transcode, but when it tries to fetch i see: [http @ 0xe0a50a0] inflate return value: -3, unknown compression method [13:46] <ph8> any idea what i might be doing wrong? [13:55] <ph8> http://pastebin.com/dejnXURH [13:55] <ph8> thx [13:58] <klaxa|work> unknown compression method sounds like the httpd is sending the data compressed and ffmpeg does not know how to decompress [13:58] <klaxa|work> can you download the file with a browser or something similar? [14:46] <max246> hello [14:46] <max246> there is a command line to get the amount of frames in a video? [14:57] <Hello71> ffprobe [15:54] <termos> when using the aresample filter I get an about 1-2 second delay between audio and video (audio is delayed). What could be the cause of this? [16:53] <Swoxxx> Hi all. I got a bit of a tricky situation and would appreciate your guidance. I have 2 folders with PNGs. One folder contains the "background frames" from 1 to 1100, the other contains overlays, like overlay_1.png etc. but with some gaps when there are no overlay. How can I add these overlays to the background, in sync (based on the frame number in the file name) ? [16:54] <Swoxxx> I have the required shell skills but not necessarily the ffmpeg knowledge. I've heard some people say, build one, build the overlay video, superpose them using alphachannel, but thats like rendering 3 times [16:54] <Swoxxx> If someone has a more cost-effective and time-effective approach that would be awesome [17:00] <Swoxxx> Anyone? It would be extremely awesome [17:02] <klaxa|work> try using imagemagick to generate intermediate new frames from which to generate a video? [17:02] <klaxa|work> that's what i would do [17:07] <Swoxxx> Alright [17:09] <mva|birthday> hello there! [17:09] <mva|birthday> is it any plans to add libquvi-0.9 support to ffmpeg? [17:10] <mva|birthday> [I just checked 2.2.3 and it don't want to build with 0.9 :(] [17:43] <MDTech-us_MAN> help [17:43] <MDTech-us_MAN> when I execute ffmpeg -i "concat:01 Clouds.wav|02 River.wav" -c copy output.wav [17:43] <MDTech-us_MAN> I get only the first file [17:44] <MDTech-us_MAN> instead of both concatinated [17:44] <MDTech-us_MAN> thy? [17:44] <MDTech-us_MAN> *why? [17:52] <MDTech-us_MAN> mva|birthday [17:52] <MDTech-us_MAN> anyone? [17:56] <MDTech-us_MAN> mva [17:58] <c_14> MDTech-us_MAN: try the concat demuxer: https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20(join,%20merge)%20med… [17:59] <MDTech-us_MAN> one sev [17:59] <MDTech-us_MAN> *sec [18:04] <MDTech-us_MAN> c_14 [18:04] <MDTech-us_MAN> Line 1: unknown keyword ')Wfile' [18:05] <MDTech-us_MAN> that is what I get [18:05] <MDTech-us_MAN> is it because of windows line endings? [18:06] <c_14> that looks a lot like utf8 problems or something, can you pastebin your command line, output and the concat file? [18:06] <MDTech-us_MAN> one sec [18:09] <MDTech-us_MAN> c_14 [18:09] <MDTech-us_MAN> http://pastebin.com/LLCydT4A [18:09] <MDTech-us_MAN> there ^ [18:15] <c_14> It looks like ffmpeg thinks there is some sort of character in front of the file part of the concat list [18:18] <MDTech-us_MAN> lets see in notepad++ [18:19] <MDTech-us_MAN> nope. nothing there [18:19] <c_14> Can notepad convert the file from windows encoding to unix encoding? [18:19] <c_14> Maybe try that? [18:20] <c_14> notepad++ that is, pretty sure notepad cannot [18:24] <MDTech-us_MAN> nope [18:24] <c_14> can't do it or didn't help? [18:24] <MDTech-us_MAN> i converted, but still [18:25] <MDTech-us_MAN> same thing [18:28] <c_14> Can you do a hexdump of the file? it should start with 6669 6c65 2027 [21:06] <ardese> I have an rtsp/h274 video source which often delivers frames with damaged macroblocks. This results in a smeared image from the point of the damaged mb on until the next key frame. Is there any way to simply discard these frames and avoid the smear rather than attempting to fill in the blocks/save them? [21:07] <ardese> That should be h264 not h274 of course& [21:17] <MDTech-us_MAN> c_14 [21:18] <MDTech-us_MAN> you there? [21:18] <MDTech-us_MAN> c_14 [21:18] Last message repeated 2 time(s). [21:18] <c_14> Hmm? [21:18] <llogan> MDTech-us_MAN: no need to pingspam [21:18] <MDTech-us_MAN> sorry [21:18] <MDTech-us_MAN> so c_14 [21:19] <MDTech-us_MAN> I opened it with a hex viewer an I get the following: [21:19] <MDTech-us_MAN> first 7: ef bb bf 66 69 6c 65 [21:19] <MDTech-us_MAN> https://hexdump.pieterhordijk.com/a75163bd8bef5e7404ca7ff630133ec47b6107a1 [21:20] <c_14> that ef bb bf shouldn't be there. I'm guessing that's the weird characters ffmpeg is seing. [21:21] <MDTech-us_MAN> That is a byte-order mark [21:21] <MDTech-us_MAN> http://www.pcreview.co.uk/forums/extra-characters-beginning-file-ef-bb-bf-t… [21:24] <c_14> can you try saving the file as ansi/ascii plain text and then testing with that? [21:24] <c_14> Other than that, I wouldn't know why ffmpeg is failing. [21:38] <MDTech-us_MAN> c_14 the ting is that I am generating and writing the file from a VB program [21:39] <MDTech-us_MAN> *thin [21:39] <MDTech-us_MAN> *thing [21:39] <MDTech-us_MAN> lemme force it to use ASCII [21:41] <c_14> If it really is that efbbbf thing that's making it fail (which I think it is since adding that to the front of concat files on my computer is causing ffmpeg to fail) that might be seen as a bug and you should put a bugreport on trac [21:41] <MDTech-us_MAN> you ming giving me the bug reported do I would not have to search around [21:42] <c_14> I don't think a bug has been reported, what I'm saying is that you might want to report it as a bug. [21:46] <MDTech-us_MAN> I ment where to report the bug [21:46] <MDTech-us_MAN> sorry. its just not my day when it comes to spelling [21:46] <c_14> https://ffmpeg.org/bugreports.html [21:47] <RobertNagy> How do I get the delayed from from a decoder that has frame threading but not CODEC_CAP_DELAY? [21:47] <RobertNagy> delayed frames* [22:25] <MDTech-us_MAN> c_14: https://trac.ffmpeg.org/ticket/3718 [22:58] <MDTech-us_MAN> c_14 [22:58] <MDTech-us_MAN> is this ok? [22:58] <MDTech-us_MAN> DTS -406750698126725248, next:345745125 st:0 invalid dropping [22:58] <MDTech-us_MAN> PTS -406750698126725248, next:345745125 invalid dropping st:0 [22:58] <MDTech-us_MAN> DTS -406750698126724224, next:345745125 st:0 invalid dropping [22:58] <MDTech-us_MAN> PTS -406750698126724224, next:345745125 invalid dropping st:0 [22:58] <c_14> As long as ffmpeg isn't violently quitting it should be fine. It means that there are some invalid timestamps in the source file. [22:59] <MDTech-us_MAN> oh I see [22:59] <MDTech-us_MAN> thats ok [23:00] <MDTech-us_MAN> hmmm [23:01] <MDTech-us_MAN> for some reason, when i select all files and check their length, it is 49:49 but the concatinated file is now 50:00 [23:02] <MDTech-us_MAN> since after I do some operations with the whole file I will chop it up again, there could be problems [23:03] <c_14> Each file might be x milliseconds longer and those add up, I'm guessing. [23:04] <MDTech-us_MAN> why would it be longer? [23:04] <c_14> How are you checking the lengths of the individual files? [23:05] <MDTech-us_MAN> in windows explorer [23:06] <MDTech-us_MAN> just highlight them all and it is in details [23:07] <c_14> I'm guessing windows explorer is not considering the milliseconds is the song length. assume you have two files. a = 3:29.5 and b = 1:30.5, if you count the milliseconds you get 5:00.0 if you don't you get 4:59. I'm guessing that might be the 'problem'. [23:22] <sanmarcos> I am trying to get AVFoundation input (to get Built in line in input) on OS X and I get Unknown input format: 'avfoundation [23:22] <sanmarcos> from both http://www.evermeet.cx/ffmpeg/, and homebew binaries [23:22] <sanmarcos> what can I do? [23:23] <sanmarcos> trying to do a simple rtsp or udp multicast stream for low latency audio streaming [23:23] <sanmarcos> ffmpeg -re -f avfoundation -i "Built-in Input" -ar 8000 -f mulaw -f rtp rtp://127.0.0.1:1234 [23:24] <MDTech-us_MAN> c_14 [23:24] <MDTech-us_MAN> you there [23:24] <MDTech-us_MAN> ffmpeg -i output.wav -acodec copy -t 00:00:00 -ss 00:05:45 "01 Clouds.wav" [23:25] <MDTech-us_MAN> Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) [23:25] <c_14> You mixed up -t and -ss [23:25] <c_14> -ss is from -t is duration [23:25] <MDTech-us_MAN> oh [23:25] <MDTech-us_MAN> I see [23:27] <llogan> sanmarcos: what does "ffmpeg -devices" show? [23:28] <llogan> (disclaimer: I know very little about avf) [23:28] <sanmarcos> unrecog option [23:29] <llogan> your build must be old [23:31] <llogan> you can parse -formats instead to see if avfoundation is in there [23:32] <sanmarcos> nope [23:32] <sanmarcos> i'll recompuile with enable-indev=avfoundation [23:37] <sanmarcos> thank you llogan [23:37] <sanmarcos> 2.2.3 i am recompiling [23:39] <sanmarcos> doesnt work [23:39] <sanmarcos> there is no mac os x support [23:39] <sanmarcos> for inputs [23:46] <MDTech-us_MAN> c_14 [23:46] <MDTech-us_MAN> ffmpeg -i output.wav -acodec copy -t 00:05:45 -ss 00:00:00 "output\01 Clouds.wav" [23:47] <MDTech-us_MAN> I cet file not found [23:47] <MDTech-us_MAN> *get [23:47] <spaam> do you have an file with the name output.wav ? [23:47] <MDTech-us_MAN> yes [23:48] <MDTech-us_MAN> output\01 Clouds.wav: No such file or directory [23:48] <MDTech-us_MAN> I get that error [23:48] <c_14> do you have a directory called output? [23:48] <llogan> sanmarcos: which OS X? [23:49] <MDTech-us_MAN> i see [23:49] <MDTech-us_MAN> that was the problem [23:49] <MDTech-us_MAN> though it sould have given a clearer message [23:50] <llogan> how would you prefer that it would be worded? [23:50] <sanmarcos> llogan: mavericks, from homebrew I wanst able to get it, i am trying Git now [23:50] <llogan> is that 10.7? [23:50] <sanmarcos> 10.9 [23:51] <sanmarcos> all the prebuitl binaries dont have it [23:51] <llogan> http://trac.ffmpeg.org/wiki/CompilationGuide/MacOSX#Shortcut:CompileFFmpegt… [23:51] <llogan> oh, that apparently doesn't use git, but a release. [23:52] <sanmarcos> yeah I edited the formula to enable avf and qtkit [23:52] <sanmarcos> but apprently avf and qtkit are only ing it? [23:52] <llogan> i'm not sure what release(s) support avf [23:52] <sanmarcos> git [23:52] <sanmarcos> i can make it use git [23:52] <llogan> i don't think you'll need to explicitly enable the indev [23:53] <sanmarcos> brew edit ffmpeg && brew instal ffmpeg --HEAD --build-from-source [23:53] <sanmarcos> ok, lets see, give me a sec while it compiles [23:54] <llogan> that wiki page could use a "git via homebrew" example [00:00] --- Fri Jun 13 2014

1 0

ffmpeg-devel.log.20140611
by burek 12 Jun '14

12 Jun '14

[00:08] <cone-6> ffmpeg.git 03Luca Barbato 07master:f121dbd9f760: mpegts: Provide an option to override the pcr period [00:08] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:aff0912da551: Merge commit 'f121dbd9f76031d7f6d56261be2f14937a19d2dd' [00:21] <J_Darnley> While doc/writing_filters.txt is helpful, I still have no idea why, when, or how I should be using the functions of an AVFilterPad. [00:22] <J_Darnley> Do frames get pushed from the input or pulled from the output? [00:25] <llogan> michaelni: feel free to try your imxdump _codec_tag() idea if you want. i don't know how. if you do i can update my crappy patch. [00:29] <michaelni> jamrial, sounds logic but seems not to make a difference to any file in fate [00:33] <michaelni> smarter llogan iam not sure we should or should not assume without user "command" that inpt that looks like imx from w/h/bitrate is [00:33] <michaelni> sorry s/smarter// [00:34] <ubitux> J_Darnley: only if it's dynamic? [00:35] <ubitux> it's the i/o pads can not be defined staticlly [00:35] <michaelni> jamrial, btw, probably best to notify the author of that shuffle discrepancy [00:38] <llogan> michaelni: probably not worth the time investment. we can leave it up to the user to supply the proper vtag if it is needed as mentioned by my updated patch. [00:39] <J_Darnley> ubitux: how does filter_frame on the input make its way to the output? [00:40] <llogan> J_Darnley: bad timing [00:41] <llogan> (as in 1 second later ubitux times out) [00:42] <J_Darnley> yes... [00:42] <J_Darnley> oh well [00:43] <J_Darnley> I'll try reading some more filters [00:44] <llogan> are you making a filter? [00:45] <J_Darnley> Trying to. [00:45] <J_Darnley> Specifically an A->V filter [00:47] <llogan> good. i wanted another for https://trac.ffmpeg.org/wiki/Encode/YouTube#Usingfilters [00:49] <J_Darnley> If I ever finish you should be impressed. [01:43] <Timothy_Gu> jamrial: isnt imm==0 means to broadcast the least significant dword of src? [01:43] <Timothy_Gu> doesn't [01:44] <Timothy_Gu> then how does shufps/pshufd matter? [01:44] <jamrial> shufps uses both dst and src. pshufd only src [01:47] <Timothy_Gu> oh wait [01:47] <Timothy_Gu> now i get what you meant [01:49] <Timothy_Gu> i missed the important sentence in the instruction manual because i thought it was a typo ;) [01:50] <Timothy_Gu> yeah i agree with you that overwriting a just calculated value is kinda odd [02:07] <J_Darnley> Woo! I drew a line moving left at ipx per frame! [02:07] <J_Darnley> *1px [02:09] <J_Darnley> but I don't create enough frames [02:13] <J_Darnley> Must be something to do with timestamp-shenanigans [02:27] <J_Darnley> Why do you only produce 206 frames? [02:33] <cone-6> ffmpeg.git 03Diego Biurrun 07master:205fdd4ea5e1: ppc: Fix runtime CPU detection for apedsp, huffyuvdsp, svq1enc [02:33] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:26be0e31fc48: Merge commit '205fdd4ea5e1264946917a26fde01e137a485f5a' [02:50] <jamrial> kurosu, michaelni: seems there's a lot of fate systems having trouble with five vsynth3 tests [02:51] <cone-6> ffmpeg.git 03Diego Biurrun 07master:27860819d508: ppc: Consistently use convenience macro for runtime CPU detection [02:51] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:1290143fda93: Merge commit '27860819d508068f056cf48473af04868791ad77' [03:09] <cone-6> ffmpeg.git 03Vittorio Giovara 07master:d7705be9617e: mpegvideoenc: check color_range [03:09] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:b3a647d9ce59: Merge commit 'd7705be9617ed691c7a2924a2088de2d96f38af1' [03:18] <Timothy_Gu> jamrial kurosu michaelni: to be exact, literally *all* slots with vsynth are failing [03:19] <cone-6> ffmpeg.git 03Vittorio Giovara 07master:641e57230b46: fate: add on2avc audio test [03:19] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:b2fb65cbebba: Merge commit '641e57230b460bef52c88e61087d97c223910bea' [03:33] <BBB> Daemon404: I dont work for chrome... [03:33] <BBB> sorry, cop-out response, I know, but I cant speak for them so responding doesnt make much sense [03:48] <wm4> what was the gcc 4.9 ffmpeg/flac bug? [03:51] <BBB> jamrial: I might have all of swri_resample() ready for yasmification of that buttugly inline asm of yours. are you interested in that or should I do that? [03:52] <wm4> ah https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 [04:04] <jamrial> no, not really interested. but you can use the yasm port i submitted a while ago if it's useful to save you some time [04:04] <jamrial> and that buttugly inline asm of mine is merely an extension of an already existing buttugly asm :P [04:05] <michaelni> Timothy_Gu, jamrial, kurosu, i cant reproduce any vsynth3 failures locally, though i know why qtrlegray fails, ill push a "fix" in a moment for that one [04:07] <jamrial> i can't reproduce it here with mingw-w64 (native) either. oddly enough nevcairiel's did fail [04:13] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:43d995e865f7: fate: Disable qtrlegray 34x34 test [04:13] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:c69defd4d014: avcodec/qtrleenc: Check that width is a multiple of 4 for grayscale [04:13] <BBB> jamrial: acknowledged :-p ok Ill do it then; the early asm may not help because I basically rewrote the function so its a double loop now [04:14] <BBB> jamrial: that basically makes it tons faster, and less jumpy, so the dsp portion is slightly bigger (because its double loop instead of single), but should be faster than inline, or at least as fast [04:58] <wm4> why does av_register_codecs exist? [05:14] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:60ab6e24574a: avcodec/mpegvideo_enc: fix padding for odd dimensions and interlaced video [10:24] <YNT> hi [10:33] <YNT> Removing old source Cloning into ffmpeg... ERROR: libx264 not found [10:33] <YNT> FFMPEG installation Failed [12:00] <ubitux> > [PATCH 1/1] ppc: fix the bug of fft for little endian Environment on POWER7 and later [12:00] <ubitux> 5 files changed, 1104 insertions(+), 0 deletions(-) [12:00] <ubitux> "fix a bug" o_o [12:56] <cone-113> ffmpeg.git 03Timothy Gu 07master:5c57e2b51bc0: MAINTAINERS: numerous grammar and discrepancy fixes [13:41] <plepere> hmm. Should there be a rule for mova on INIT_AVX to use vmovdqa instead of movdqa ? [13:42] <plepere> I'm seeing the rules for INIT_XMM and INIT_YMM [13:43] <plepere> but they use only the 128b mov [13:46] <BBB> plepere: INIT_AVX is INIT_XMM avx [13:46] <BBB> plepere: so no [13:46] <BBB> plepere: dont ever use INIT_AVX, its deprecated [13:46] <plepere> ok [13:46] <BBB> if you want avx2, just use INIT_YMM avx2 [13:46] <BBB> if you want float avx, use INIT_YMM avx [13:47] <BBB> if you want avx 3-part instructions on xmm/sse4, use INIT_XMM avx [13:47] <plepere> well I'm using h264 dc_add, so it's INIT_XMM avx [13:47] <BBB> yes [14:00] <plepere> BBB, what's the benefit of using the 3 instruction avx paddw instead of mova + paddw ? [14:01] <BBB> its typically faster [14:01] <BBB> and saves a register [14:02] <J_Darnley> WTF? Why is this AVFrame filled with NULLs? [14:10] <J_Darnley> I'm going backwards now! [14:21] <plepere> BBB : if I'm inspiring myself with h264 assembly code, where should I say it ? [14:38] <BBB> plepere: nowhere imo [14:39] <BBB> plepere: but if you insist, put it in a comment above the function maybe? [14:39] <BBB> ; this was somewhat inspired by h264 code in function abc in file xyz by author a b. c <d(a)e.f> [14:39] <BBB> do whatever you think feels right [14:40] <plepere> ok ok [14:44] <plepere> dang it. my idct16 works, but when I re-use it in a idct32 wrapper, it breaks in a most cases. [15:15] Action: Daemon404 sees ubitux enjoying c-e again [15:16] <ubitux> that's fine with me [18:27] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:27b8ef5bb709: avformat/oggparsevorbis: Dont attempt to calculate timestamps from gp=0 [18:57] <nevcairiel> Daemon404: am I blind or do you not define a default value for the filter size [18:57] <Daemon404> yes [18:57] <Daemon404> i noticed that 2 seconds later [18:57] <Daemon404> i am very smart. [19:01] <ubitux> what's the impact of a larger filtersize? [19:02] <ubitux> slower init? larger memory consumption? [19:02] <nevcairiel> both i guess [19:02] <ubitux> anything else? [19:02] <nevcairiel> should reallz just bump the default up as well [19:02] <ubitux> anyway to make it dynamic? [19:02] <nevcairiel> it was designed years ago when memory was smaller [19:03] <nevcairiel> ubitux: very hard, since asm has offsets to the table [19:03] <ubitux> ok [19:03] <nevcairiel> could make them pointers and make the asm deref those, but thats still effort and potentially a bit slower :p [19:03] <ubitux> what about making it slow/dynamic when a certain size is required? [19:03] <Daemon404> [18:02] <@ubitux> anyway to make it dynamic? [19:03] <Daemon404> not easily [19:04] <Daemon404> i discussed it with michaelni before [19:04] <Daemon404> and the conclusion was compile time option [19:04] <Daemon404> its nontrivial to make dynamic [19:04] <ubitux> ok [19:04] <Daemon404> it even used to use fixed offsets before michael fixed it a while back ;) [19:07] <Daemon404> you know [19:07] <Daemon404> why the fuck do people reply with "fails build because no default" [19:07] <Daemon404> after i *already* replied with that [19:08] <Daemon404> just to rub it in? [19:08] Action: ubitux going to try the patch and report problems [19:11] <Daemon404> v2 send [19:11] <Daemon404> sent* [19:11] <Daemon404> ubitux, ^ [19:11] <Daemon404> if youre gonna test, then test that [19:12] <ubitux> too late [19:24] <Daemon404> kurosu, http://fate.ffmpeg.org/report.cgi?time=20140611171420&slot=i686-windows-icl [19:27] <cone-113> ffmpeg.git 03Timothy Gu 07master:881ee369e637: tests: Add aic decoder test [19:27] <Daemon404> msvc is broken too [19:28] <Daemon404> and mingw [19:28] <Daemon404> i guess all 32bitwindows. [19:28] <nevcairiel> looks like all builds running on native windows fail [19:28] <nevcairiel> 32 that is [19:28] <Daemon404> yea [19:34] <Daemon404> eh [19:34] <Daemon404> http://fate.ffmpeg.org/report.cgi?time=20140611112041&slot=x86_32-linux-gnu… [19:34] <Daemon404> all 32bit is broken. [19:37] <jamrial> vsynth3-svq1 and vsynth3-wmv2 are also failing in a couple x86_64 systems [19:38] <jamrial> and all the mpeg4 ones are failing with valgrind http://fate.ffmpeg.org/report.cgi?time=20140611143502&slot=x86_64-archlinux… [19:39] <jamrial> guess vsynth3 works as intended. It found a lot of corner cases :P [20:31] <kurosu> regarding some of the huffyuv tests, the int16 encoder asm wrecks the stack and crashes [20:31] <kurosu> I haven't investigated more why [20:32] <kurosu> (int16 asm: can't even get a backtrace with it) [20:36] <nevcairiel> stack smashing is fun like that [20:43] Action: Daemon404 just saw the £400 a day contract on ffmpeg-devel [20:43] <Daemon404> too bad im employed [20:45] <llogan> i wonder what a "multimedia management platform" really is. [20:46] <Daemon404> llogan, if theyre willing to pay £400 a day i doubt it will be a fun experience [20:46] <Daemon404> on-site requirement too [20:47] <llogan> you mean I'd have in live in a place whose name is an archaic for "hymen"? [20:47] <Daemon404> relocating for 6 months isnt exactly a pleasing thing to o [20:47] <Daemon404> do [20:48] <Daemon404> reeks of enterpriseness too [20:49] <Daemon404> theres someone in here who lives 40 minutes from tere, but theyre also employed [20:49] Action: Daemon404 likes 2 hrs [20:49] <Daemon404> lives* [20:50] <llogan> have you developed an accent yet? [20:50] <Daemon404> no [20:50] <Daemon404> i probably wont [20:50] <Daemon404> iirc accents develop in childhood [20:50] <Daemon404> after some age, they dont go away [20:51] <llogan> i've known some people who have lived in the US south that have come back talkin' funny...temporarily. [20:54] <kierank> Daemon404: 400 quid a day is cheap [20:55] <kierank> but yes it'll be a mess [20:55] <kierank> and so they'd have to offer more [20:56] <Daemon404> yeah [20:56] <Daemon404> exactly [20:56] <Daemon404> kierank, 400 quid a day works out to a pretty decent salary [20:56] <Daemon404> but for that job, it is shit pay [20:56] <Daemon404> contracting etc [20:59] <JEEB> and often the more you're paid the more the people expect you to actually do per day if you're on such a payment scheme [20:59] <Daemon404> JEEB, jobs like that tend to be akin to "bend over and lube up" [20:59] <JEEB> yes [20:59] <llogan> an on site they can loom over you while you're busy in #ffmpeg-devel [20:59] <JEEB> reminds me of a tweet I saw today [21:00] <JEEB> "HOW MUCH PIZZA AND COKE DO I HAVE TO GIVE THESE NERDS SO THEY WON'T COMPLAIN ABOUT THE 80 HOUR WORK WEEK" [21:01] <JEEB> https://twitter.com/PHP_CEO/status/448821416113475584 [21:01] <JEEB> :3 [21:02] <Daemon404> thats a different thing [21:02] <Daemon404> thats lolstartups [21:03] <Daemon404> this is lolcontracting [21:03] <JEEB> still shit [21:03] <JEEB> like they both are [21:03] <Daemon404> well yes. [21:04] <Daemon404> i dont really know why peple restrict themselves to "on-site" a lot [21:04] <Daemon404> it cuts off ... well most of this channel [21:04] <JEEB> J_Darnley, unless you are enjoying that wbk person I recommend you set him on ignore [21:04] <JEEB> he's been banned there twice or so already [21:05] <JEEB> he's either retarded, or trolling [21:05] <Plorkyeran> there are a lot of managers who can't comprehend any way to determine if someone is working other than seeing if their butt is in a seat in the office [21:05] <J_Darnley> I should email the guy. I am not experienced and I "dislike" c++ but its £400! [21:05] <llogan> how long can they pay you befor ethey realize? [21:05] <J_Darnley> 1 minute? [21:06] <JEEB> I like "on-site" because it keeps a distinct difference between "work" and "not work" [21:06] <Daemon404> Plorkyeran, my manager is also a coworker [21:06] <Daemon404> he sees my code directly [21:06] <JEEB> I'm still not sure how much my manager can code [21:07] <J_Darnley> JEEB: I thought I recognised the name [21:07] <Daemon404> JEEB, i know how intel management is [21:07] <JEEB> he is a "software engineering manager", but I mostly see him doing random stuff in JIRA [21:07] <Daemon404> if there is one thing that can kill intel [21:07] <Daemon404> it's its management [21:07] <JEEB> I'm kind of noticing it [21:07] <JEEB> at the very least we're generally on OK terms [21:07] <Daemon404> do they force you to use IBM "Rational" ClearShit [21:07] <Daemon404> like i had t? [21:08] <JEEB> haven't seen at least yet [21:08] <Daemon404> lucky [21:08] <Daemon404> you know how jira can be evil when used by management? [21:08] <Daemon404> this is far worse. [21:08] <llogan> i often make my own hours. and that's why i'm a thousandaire. [21:09] <Daemon404> i keep EST hours but im in BST [21:09] <JEEB> OTC seems to be relatively sane regarding tools [21:09] <Daemon404> sleep patterns -> fucked [21:19] <kurosu> One bug down, 6+ to go ? [21:19] <Daemon404> kurosu, you mean [21:19] <Daemon404> such is coding. [21:25] <cone-113> ffmpeg.git 03Clément BSsch 07master:76bce46d8fab: avfilter: add signalstats filter [21:26] <kurosu> actually, it seems to have fixed all huffyuv cases here [21:31] <jamrial> yeah, it did here as well [21:31] <Daemon404> \o/ [21:32] <kurosu> 2 bugs down, 5 to go ? [21:33] <nevcairiel> valgrind complains on a few others, but at least this should be the last actual failure on "normal" fate systems [21:33] <jamrial> svq1, wmv2 on some x86_64, and mpeg4 and rgb with valgrind [21:33] <Daemon404> theres a patch for one there [21:34] <kurosu> I'd thought 60ab6e24 would have fixed mpeg4 as well [21:34] <jamrial> ah right, missed michaelni's email [21:35] <kurosu> ah nice that it is such a small issue [21:35] <cone-113> ffmpeg.git 03Clément BSsch 07master:1786cd850f90: avfilter/showcqt: fix misc style issues [21:35] <cone-113> ffmpeg.git 03Clément BSsch 07master:0180c4692864: avfilter/showcqt: move qsort_sparsecoeff closer to where it belongs [21:35] <kurosu> err, that's just a single test - I thought it fixed mpeg* [21:36] <kurosu> fate-vcodec passes here (win32/64) [21:37] <kurosu> cpu is sse4.2 at most [22:02] <cone-113> ffmpeg.git 03Lou Logan 07master:edeefeaaf9b6: doc/filters: add forgotten " to zoompan example [22:06] <ubitux> BBB: it seems there is a bug in ff_vp9_ipred_vl_4x4_ssse3 (at least) [22:28] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:ef8725122d23: avcodec/motion_est: Only clip MVs which are used [22:28] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:67d29da4bd23: avcodec: increase FF_INPUT_BUFFER_PADDING_SIZE to 32 [22:33] <ubitux> llogan: the quotes are wrong [22:33] <ubitux> why did you do that? [22:38] <cone-113> ffmpeg.git 03Janne Grunau 07master:0ddc53dabbc6: mpegvideo: synchronize AVFrame pointers in ERContext fully [22:38] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:67911cc57bbe: Merge commit '0ddc53dabbc6f636d062b187ea27934610aaad30' [22:43] <jamrial> i may be missing something, but why are the results of vsynth*-zlib and vsynth*-mpng lossy? aren't both supposed to be lossless? [22:44] <Compn> png has both lossy and lossless modes [22:44] <Compn> but no idea on those specific tests [22:48] <jamrial> maybe it's related to colorspace conversion [22:48] <llogan> ubitux: i'll revert it. [22:50] <kurosu> png might be lossy if forced to palettize, ie reduce number of different colors? [22:51] <llogan> ubitux: why was there a trailing "? [22:51] <ubitux> missed that one [22:52] <ubitux> the correct fix was to remove it [22:53] <llogan> i'll remove them both then [22:53] <cone-113> ffmpeg.git 03Janne Grunau 07master:cd62c04d009b: h263enc: keep block_last_index always valid during advanced intra coding [22:53] <cone-113> ffmpeg.git 03Michael Niedermayer 07master:2cf4d91cf221: Merge commit 'cd62c04d009b3baf7582556866a7029291b54573' [22:54] <llogan> that's what i get for thinking it was trivial [22:54] Action: Compn looks around for evrc decoder :( [23:12] <llogan> ubitux: the examples are often inconsistent, but your version is at least easier to human read [23:18] <wm4> https://git.videolan.org/?p=ffmpeg.git;a=commit;h=67d29da4bd23057a1f6465684… [23:18] <wm4> what [23:18] <wm4> michaelni: I consider that an ABI breakage [23:19] <wm4> michaelni: you can't just do this [23:19] <wm4> how about lavc doesn't just read out of bounds of memory buffers by design [23:19] <wm4> this is so unclean [23:19] <wm4> /rant [23:21] <kurosu> ... [23:24] <michaelni> wm4, how is padding buffers by twice the amount an ABI breakage ? [23:24] <wm4> because library users have to pad the buffer [23:25] <michaelni> how is this related to the commit you point at ? [23:26] <wm4> it's a bug that lavc reads outside of the bounds [23:26] <michaelni> lavc does not read outside the old bounds AFAIK, some filters do [23:27] <kurosu> has bitstream reading been changed in that way ? because that was the original intent, right ? [23:28] <michaelni> bitstream reading can read a few bytes over, like 3 or 4 or so [23:28] <michaelni> on damaged streams its possible slightly more overread happens and the 0 padding arrests that [23:29] <wm4> and that's why you potentially force every API user to copy the input buffer? [23:29] <wm4> (same for buffer alignment) [23:32] <michaelni> wm4, what do you suggest ? that there would be a flag that does the copy internally ? [23:33] <michaelni> also, which applications actually do need a copy ? [23:33] <wm4> a clean solution would probably revolve around not requiring such a padding in the reader, but maybe it's too late to realistically change this, if at all [23:33] <wm4> all applications that don't have direct control over the buffer allocation [23:33] <wm4> imagine something that tries to do zero-copy by passing a pointer into a mmaped file to lavc [23:34] <michaelni> not requiring the pading makes the reader slower [23:34] <kurosu> there are actually 2 very different usages of this define. One is internally, to guarantee we don't have to waste code and speed [23:35] <kurosu> the other is when those buffers are provided by the application I guess [23:35] <kurosu> and that's where the issue is? [23:36] <michaelni> wm4, i understand in what cases the copy is needed, i was wondering which actual real world applications are affected by this [23:37] <wm4> michaelni: every API user who is naive enough to assume that the API doesn't require such intuitive and hard to track down artifacts [23:37] <wm4> the bitstream reader could just copy an amount of bytes ahead when the buffer runs out or such [23:37] <wm4> and the copy could be padded or whatever [23:38] <TheFluff> a lot of api users don't seem to understand what FF_INPUT_BUFFER_PADDING_SIZE is for, in my experience [23:38] <TheFluff> if they use it they usually use it wrong [23:42] <michaelni> wm4, if one adds a check into get_bits() to copy and pad before the end, this could easily be slower than unconditional copying of the whole buffer before use. It would be possible of course to do the check and copy padding at some larger granularity like per row but that then would need changes and extra code to litterally every decoder [23:43] <wm4> I suppose I don't enough about the bitstream reader to tell, but somehow I doubt it's impossible to improve this situation [23:44] <michaelni> improvment is certainly possible, it almost always is for non trivial code [23:45] <michaelni> the most obvious 2 things i see is 1. if users dont know how to use FF_INPUT_BUFFER_PADDING_SIZE there must be somethig seriously wrong with our documentation [23:45] <wm4> maybe if a user has a lot of time, 100% attention, and reads all the docs, he won't miss this [23:45] <michaelni> and we could check if the padding area is filled with zeroes and warn if its not but IIRC we dont strictly require zero filling the area [23:46] <wm4> actually you could just read the padding on each packet and verify it's zerod [23:46] <wm4> yeah [23:46] <wm4> huh [23:46] <wm4> you don't? [23:47] <michaelni> "Note: If the first 23 bits of the additional bytes are not 0, then damaged * MPEG bitstreams could cause overread and segfault." [23:48] <wm4> so, you don't require zeroing the padding, but you might segfault then? [23:48] <michaelni> on damaged streams, yes [23:48] <wm4> that's a strange definition of "not required" [23:50] <michaelni> instead of 0 bytes at the end a sufficient amount of any bytes should also prevent segfaults, which may be usefull for mmap files [23:51] <wm4> michaelni: how much slower would decoding become overall if the bitstream reader would check for the bounds in some way? [23:55] <kurosu> wm4, no idea, but seeing how some small changes provided several % on a lossless video codec, I'd expect 10% worst-case [23:56] <kurosu> more often 1% for the most common codecs [23:57] <michaelni> wm4 also if you force UNCHECKED_BITSTREAM_READER to 0 then the overread i think would be limited to 3-4 bytes independant of if they are 0 at the end [23:58] <michaelni> these checks probably could be extended to switch the buffer before the end to prevent that remaining overread [00:00] --- Thu Jun 12 2014

1 0

ffmpeg.log.20140611
by burek 12 Jun '14

12 Jun '14

[00:02] <llogan> JackWinter: ignore it [00:03] <JackWinter> llogan: thanks [04:03] <eclipse_> ow x264 is much better than divx [04:06] <wh-hw> hi,guys [04:07] <wh-hw> how streaming a video to H.265 format ? [04:10] <eclipse_> wow x264 is much better than divx [04:10] <eclipse_> is x265 much better than x264 [04:13] <sacarasc> I am not sure how optimised it is currently, but I think people have tested positively for that. [04:32] <Ultima> how long ago was x265 added? [06:25] <kittonian> hi all. when converting an mkv that has subtitles, to an m4v, is there any way to retain those subtitles during the conversion? [10:22] <YNT> hi [10:23] <YNT> Removing old source Cloning into ffmpeg... ERROR: libx264 not found [10:23] <YNT> FFMPEG installation Failed [10:32] <bencc> is this the correct syntax to make mp4 play faster? [10:32] <bencc> ffmpeg -f concat -i files.txt -c copy -movflags +faststart output.mp4 [10:33] <bencc> the browser still need to download more than 10MB after adding this flag [11:34] <c_14> kittonian: try adding -map 0:s, but mp4 only officially supports mpeg-4 timed text subtitles [13:52] <mazi> Hi, can anyone help me on this: I want to know how much time does it take for each frame in a video to be decoded/encoded. I have tried "time ffmpeg" and -becnhmark, but the result is not what I was exactly looking for. -benchmark gives good information about each frame but not the CPU time it took for each frame to be transcoded. [14:00] <c_14> mazi: I'm guessing if it works it might be benchmark_all, but damn that's spammy. [14:05] <mazi> Thank you for the reply. I have tried benchmark-all, but it does not declare the frame number on that list. By the way I have also tried filters such as -vf "showinfo". My purpose is to compare the processing time for each frame type (I, P or B) in a video. [15:41] <n1n0> hi. how to vf transpose 45 degrees clockwise? tried with the value 0.5, but flips it. [15:49] <saste> n1n0, rotate [15:52] <n1n0> was refering to this blog http://phayz.wordpress.com/2011/10/28/howto-rotate-a-video-using-ffmpeg/ [15:53] <n1n0> what would be the command line to rotate the video clockwise 45 degrees? [15:53] <c_14> n1n0: transpose only works on 90 or 180 degree angles, look at the docu or rotate: https://ffmpeg.org/ffmpeg-filters.html#rotate [15:54] <c_14> *for [15:54] <intima> Hi all, I'm using motion on a Raspberry Pi as a security camera. However, when I set ffmpeg to record to .mov, I get the following error in the console: ffmpeg_open: avcodec_open - could not open codec mov Does anyone know how to rectify this? [15:56] <intima> https://paste.ee/p/txMMz [15:57] <intima> I am not directly typing the ffmpeg command, instead Motion passes the video stream to ffmpeg for encoding [15:58] <c_14> First of all, mov isn't a codec. It's a format. Second of all if I don't know what Motion is doing I can't help you. [16:03] <intima> Thanks for the info. Is there any way I can find out what Motion is doing? [16:04] <intima> As in, what command it's using for ffmpeg? [16:05] <n1n0> c_14 thank you! [16:10] <clever_> intima: its likely not using a command directly, but just compiled against the ffmpeg libs [16:11] <clever_> read the source! [16:20] <intima> Hmm good idea - line 613 is where my error is. I can't figure out why it's being triggered though. https://github.com/dozencrows/motion/blob/mmal-test/ffmpeg.c [16:35] <Fjorgynn> haha [16:35] <Fjorgynn> I found an old fraps file which was 255 MB, I used ffmpeg libx264 and fdk aac and got it down to 8,67. [16:35] <clever_> wow [16:36] <clever_> it must have been encoded with a cheap routine to avoid cpu usage [16:37] <Fjorgynn> clever_: what? [16:37] <Fjorgynn> 255 MB for 23 sec. [16:37] <clever_> to avoid using too much cpu power and messing up the game, fraps may have taken many shortcuts [16:37] <clever_> or possibly just done it raw, without any compression [16:37] <Fjorgynn> fraps is practically raw [16:38] <Fjorgynn> It's 330364 kbps data speed [16:38] <Fjorgynn> and total bit rate 331776 kbps [16:38] <Fjorgynn> with 1411 kbps sound [16:39] <Fjorgynn> but ffmpeg says [16:39] <Fjorgynn> Duration: 00:00:23.37, start: 0.000000, bitrate: 91795 kb/s [16:39] <Fjorgynn> pcm 16 audio: Duration: 00:00:23.37, start: 0.000000, bitrate: 91795 kb/s [16:39] <Fjorgynn> no [16:39] <Fjorgynn> Audio: 1411 kb/s [18:04] <XHFHX> hi :) Would someone like to help me, I was here about one week ago and I was told to ask at StackOverflow/Superuser, but nobody would help me over there [18:05] <XHFHX> i currently want to concat 2 or more videos, which have different scale and size [18:05] <sacarasc> Use the concat filter. [18:05] <XHFHX> the syntax I use and the error message are here: http://pastebin.com/89yw9mCN [18:06] <XHFHX> oh, I see that I have written setdar=1:1 two times, but wouldn't help anything if I write it only one time, still the same error message [18:09] <c_14> you never created a pad for the first command, and you never define what the v1 pad is. [18:09] <c_14> s/command/filterchain [18:10] <XHFHX> better? http://pastebin.com/s7KDEyih [18:10] <XHFHX> still the same error [18:10] <c_14> how is that better? you didn't fix what I told you to fix [18:10] <c_14> "[0:v]scale=1280x720,setdar=1/1[v1]; [1:v]scale=1280:720[v2]; [v1][0:a][v2][1:a]concat=n=2:v=1:a=1[outv][outa]" [18:11] <c_14> try that [18:11] <XHFHX> sorry, its the first time i use ffmpeg [18:12] <XHFHX> still the same error [18:17] <c_14> question, why are you using setdar? [18:18] <XHFHX> i want to concat 4:3 and 16:9 [18:19] <XHFHX> but it seems the error was that i set setdar to 1:1 instead of 16:9 [18:19] <XHFHX> strange, because when i tried it out on a video and set it to 16:9 it was distorted [18:19] <c_14> do you want the smaller video to have black (or white or any color) bars on the side or do you want it stretched [18:20] <XHFHX> bars [18:20] <XHFHX> mh, i see. setdar "zooms in" :/ [18:21] <XHFHX> mh, no, actually its distorts it, thats not so good [18:21] <c_14> setdar isn't what you want [18:21] <XHFHX> i actually thought i should use pad, but pad wouldn't upscale my video for some reason [18:22] <XHFHX> probably its possible, but I couldn't figure out the syntax [18:22] <c_14> you want to scale the video to x:720 and then pad the x portion so it's 1280 [18:24] <XHFHX> is this the right syntax? [0:v]scale=-1:720,pad=width=-1:height=720[v1] [18:24] <c_14> so scale=1.5*iw:1.5*ih,pad=1280:720:(1280-iw)/2:0 [18:24] <c_14> that -1 should work too [18:24] <c_14> but not sure pad takes -1 [18:25] <c_14> take your scale and my pad [18:25] <bencc> I have mp4 video that starts playing only after the browser loads more than 10MB of it [18:25] <bencc> I make it using: ffmpeg -f concat -i files.txt -c copy -movflags +faststart output.mp4 [18:25] <bencc> is this the correct syntax? [18:25] <XHFHX> yes, you're right, pad wont accept negative integers [18:27] <c_14> bencc: that should be right [18:27] <bencc> c_14: for some users the mp4 doesn't play on IE9. any idea what can cause it? [18:27] <c_14> IE9 being shit? [18:28] <bencc> anything I can do about it? [18:28] <c_14> If it works in other browsers but not IE, then it's IE's fault (usually) [18:28] <XHFHX> wow, thank you c_14, its working perfectly! :) [18:29] <c_14> bencc: I wouldn't know what IE supports. [18:31] <XHFHX> I have another question: Currently i concat the videos in ffmpeg, but I'd like to have them in xd5c (some XDCAM format), but this is only supported by ffmbc, which doesn't support concat. So, can you recommend a codec which is fast and doesn't have a big quality loss? [18:31] <bencc> thanks [18:32] <c_14> XHFHX: if you have the hard drive space just pick some random lossless codec like rawvideo or throw it into a yuv4mpeg pipe and pipe that to ffmbc [18:36] <XHFHX> ok, thank you, i'll check the bitrate of rawvideo [18:39] <XHFHX> mh, its slower then x264 ultrafast -qp 0 because the disk isn't fast enough :D [18:40] <bencc> maybe I have a problem with the audio codec? [18:40] <bencc> http://dpaste.com/1B9K3KX/ [18:40] <bencc> aac is supported in IE9? [18:42] <c_14> try ffmpeg -i file -an -codec copy outfile and test it? [18:46] <XHFHX> c_14: i tried to expand the example with 3 inputs, this is the error i get: http://pastebin.com/STS62J8j [18:49] <c_14> One of those three videos doesn't have square pixels. [18:52] <c_14> prepend this filter: 'scale=iw*sar:ih' to the filterchain of the video with anamorphic pixels [18:54] <c_14> you might also need to append setsar=1:1 to the end of that scale before the other filters [18:59] <XHFHX> mh, videoencoding is not really funny... :D [19:01] <c_14> I rather like it. There are still a lot of things I don't know though. [19:02] <XHFHX> could you help me with the exact syntax for the filter? it worked, but the video was still small, somehow I need to upscale it [19:02] <c_14> can you show me the commandline? [19:02] <XHFHX> [0:v]scale=-1*iw:720*sar:ih,pad=1280:720:(1280-iw)/2:0[v1] [19:02] <XHFHX> is that enough or do you need the full syntax? [19:02] <c_14> that's enough [19:05] <c_14> [0:v]scale=iw*sar:ih,scale=-1:720,pad=1280:720:(1280-iw)/2:0[v1] [19:05] <c_14> try that [19:07] <XHFHX> already tried that to, gives out the following error: http://pastebin.com/4X29ZnuQ [19:08] <c_14> can you ffprobe all the input files and tell me what their SAR values are? [19:12] <XHFHX> part1 and part3 have SAR=1:1 [19:12] <XHFHX> part2 is a HD video, in which he doesn't show any SAR number [19:12] <XHFHX> but part3 makes problems [19:13] <XHFHX> Stream #2:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yu [19:13] <XHFHX> v420p, 480x352 [SAR 1:1 DAR 15:11], 494 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59. [19:13] <XHFHX> 94 tbc (default) [19:14] <c_14> add a setsar=1 to the end of each filterchain, right before the [] part [19:15] <XHFHX> seems to work, at least it started rendering [19:15] <c_14> now let's hope none of them are distorted [19:20] <XHFHX> yes, works nicely :) [20:17] <_genuser_> hello people. [20:17] <_genuser_> compiling latest ffmpeg from sources. I understand it supports WTV. is the following cmd correct? [20:18] <_genuser_> ffmpeg -i <filename>.wtv -vcodec copy -acodec copy -f mpeg2video output.mpg [20:19] <c_14> should work [20:19] <c_14> you can simplify to just -codec copy [20:19] <c_14> and you probably don't need the explicit format definition [20:20] <llogan> c_14: i approved your patch in the mail queue, if you were curious. sorry for the wait. [20:21] <c_14> No problem, not sure why it complained about implicit destination though. [20:21] <_genuser_> c_14: ok, thanks. [20:21] <_genuser_> c_14: so .mpg should be able to auto determine the format, correct? [20:21] <c_14> Normally, yes. [20:22] <_genuser_> I've been pushing wtv files, dvr-ms files thru it. and it's been hap-hazard (sp?). [20:22] <_genuser_> sometimes it would work great and pull out a mpg file, and other times it just says av_interleaved_write_frame(): something something. lol. [20:22] <llogan> c_14: your to: was "@ffmpeg-devel"@ffmpeg.org [20:23] <_genuser_> so step 1, get the latest src and compile. enabled the x264 that I will finally need. so let's see. [20:23] <c_14> hmm, maybe I made a typo with git send-email [20:25] <llogan> you can always set "git config sendemail.to ffmpeg-devel(a)ffmpeg.org" to add it to ffmpeg/.git/config for future laziness points. but you probably know this. [20:32] <_genuser_> great. nice, my xubuntu decided to just reboot in the middle of my ffmpeg install. [20:32] <_genuser_> thanks, you failure of a windows clone! [20:32] <llogan> you can always try a build from the FFmpeg download page [20:34] <_genuser_> llogan: I noticed in the docs that libx264 is disabled by default. So I thought I'd compile it and enable it. [20:34] <llogan> the builds i referred to has --enable-libx264 [20:34] <_genuser_> ah, I see. so get the static linux build of the website? [20:35] <llogan> sure. unless you want more customization and/or a neck beard. [20:35] <_genuser_> neck beard? Is it really that long to compile? [20:36] <c_14> Nah, but most people don't want to go through the effort. [20:36] <llogan> no. that was a bad joke. the builds are good for quick testing, but compiling offers advantages [20:37] <_genuser_> gentoo user here. kinda used to taking 5-10 minutes to install stuff vs. instantaneous install. [20:38] <_genuser_> it's been compiling for a about 2 min now on reboot. plus whatever it built before. So I'll give it another 10 minutes on this slow laptop. [20:38] <_genuser_> if not, I'll download the bins. [20:42] <_genuser_> nice installed. [20:53] <_genuser_> odd audio is missing in complete vid but can be extracted separately. [20:53] <_genuser_> ffmpeg -i <filename>.dvr-ms -acodec copy output.ac3; mplayer output.ac3 plays audio [20:54] <_genuser_> ffmpeg -i <filename>.dvr-ms -codec copy output.mpg; mplayer output.mpg plays only video [20:54] <_genuser_> that command is all I'm using. the ffmpeg output is huge... let me recapture. I'll paste bin shortly. [20:55] <llogan> you can omit multiple repeating lines [21:02] <_genuser_> still working on it, computer got really slow. [21:03] <llogan> compiling ffmpeg also allows you to heat your room. [21:04] <_genuser_> lol true that. [21:07] <_genuser_> ok, no pastebin will accept an input so large. [21:08] <llogan> the first ~50 and last ~50 lines will probably suffice [21:10] <_genuser_> http://dpaste.com/3G0Y16Q/ <--- generate an .ac3 file that mplayer can play and the audio is just fine [21:13] <JackWinter> ffmpeg is a quick build... try building wine or the kernel instead [21:13] <JackWinter> or qt/kde :) [21:14] <_genuser_> yeah, I've spent 1-2hrs building kdelibs. not fun. [21:17] <_genuser_> http://dpaste.com/2GZMJM4/ <--- generates an .mpg file that plays video but not audio [21:17] <_genuser_> I think I see a helpful error in there: ac3 in MPEG-1 system streams is not widely supported, consider using the vob or the dvd muxer to force a MPEG-2 program stream. [21:27] <_genuser_> ok, per the error I can use -f vob to force it to use the vob container and put in the audio file. I suppose I just need to de-interlace now. :) [21:27] <llogan> you will have to re-encode to deinterlace [21:28] <llogan> and if you want to deinterlace try the yadif filter [21:28] <llogan> or just set your place to deinterlace upon playback [21:28] <llogan> *player [21:39] <_genuser_> llogan: messing with the -deinterlace option. [21:40] <llogan> -deinterlace is deprecated, IIRC, and maps to yadif, AFAIK. [21:40] <_genuser_> oh, so I should just learn the darn yadif format, then. [21:40] <_genuser_> I'm looking to convert them to valid mpg. so trying -f mpeg2video. Next edit them. and then convert to x264. long process. [21:41] <llogan> http://ffmpeg.org/ffmpeg-filters.html#yadif [21:41] <llogan> if you want to edit use a lossless intermediate like huffyuv or utvideo [21:43] <_genuser_> is mpg lossy or lossless? [21:43] <_genuser_> ok mpeg2video didn't work. no audio. [21:44] <llogan> lossy [21:44] <llogan> (but you may not notice) [21:44] <_genuser_> may it isn't the de-interlacing then. (looks like blinds on fast scenes). maybe it's the lossy bit. [21:51] <_genuser_> llogan: will look at the huffyuv too. [22:00] <relaxok> Guys: I have a quicktime .mov using the prores codec, with 16 channels of pcm audio in it (from a blackmagic hyperdeck video recorder). When i use -ss + -t to trim clips, even if i give it 0 as a start point and the duration as an end point, there are multi-frame hangs in the output video - BUT only if i don't -an, e.g. only if it also trims the audio. [22:00] <relaxok> if i just trim the video, no artifacts [22:01] <relaxok> sometimes it'll be like 1 second in, sometimes 5 seconds in (of a 7 second clip) [22:01] <relaxok> any idea how to fix this or why? [22:02] <relaxok> oh, also, i'm using copy for video codec [22:06] <relaxok> http://pastebin.com/8yzGTcRd [22:07] <relaxok> sorry, this is a 5.62 second video [22:07] <relaxok> 3* [22:07] <llogan> with a -t 5.63 [22:08] Action: llogan will return in ~1 hour [22:08] <relaxok> basically i just was trying to see if even if it wasn't actually chopping out any of the video, it still caused frame hangs [22:08] <relaxok> and it does [22:10] <relaxok> ah hah, even if i do a pure copy with no seek or trim, the glitch is there [22:10] <relaxok> that wasn't in the original [22:10] <relaxok> i do get 'Packet with invalid duration -320 in stream 1' though [22:11] <relaxok> http://pastebin.com/g56Nh95H [22:13] <_genuser_> oh ouch! overheated my laptop and turned if off. lol [00:00] --- Thu Jun 12 2014

1 0

ffmpeg-devel.log.20140610
by burek 11 Jun '14

11 Jun '14

[00:38] <cone-168> ffmpeg.git 03Michael Niedermayer 07release/1.2:9e9d92bbcc4f: avformat/avidec: allow rounding errors between scale/rate and timebase [00:38] <cone-168> ffmpeg.git 03Carl Eugen Hoyos 07release/1.2:0983720cf2b4: avcodec/utvideodec: Increase vlc len [00:38] <cone-168> ffmpeg.git 03Martin Storsjö 07release/1.2:71516ac175aa: adpcm: Fix trellis encoding of IMA QT [00:38] <cone-168> ffmpeg.git 03Martin Storsjö 07release/1.2:401b3dafd989: adpcm: Write the proper predictor in trellis mode in IMA QT [00:38] <cone-168> ffmpeg.git 03Michael Niedermayer 07release/2.1:be4d4a61b534: avformat/avidec: allow rounding errors between scale/rate and timebase [00:39] <cone-168> ffmpeg.git 03Carl Eugen Hoyos 07release/2.1:bdba204bd073: Do not limit blocksize when reading PCM from aiff. [00:39] <cone-168> ffmpeg.git 03Carl Eugen Hoyos 07release/2.1:60e2f9bf8b7c: avcodec/utvideodec: Increase vlc len [00:39] <cone-168> ffmpeg.git 03Michael Niedermayer 07release/2.1:e8bb67c2a912: avcodec/h264: in the absence of recovery points, be more tolerant on accepting plain I frames [00:39] <cone-168> ffmpeg.git 03Michael Niedermayer 07release/2.1:992cdbc56a56: avcodec/mjpegdec: Improve intel jpeg flip heuristic [00:39] <cone-168> ffmpeg.git 03Martin Storsjö 07release/2.1:39256e54d1a4: adpcm: Fix trellis encoding of IMA QT [00:39] <cone-168> ffmpeg.git 03Martin Storsjö 07release/2.1:c5606c04cf04: adpcm: Write the proper predictor in trellis mode in IMA QT [00:39] <cone-168> ffmpeg.git 03Michael Niedermayer 07release/2.2:8c33d40a7b8a: ffmpeg: prevent pts < dts to be passed through to the muxer on stream copy [00:39] <cone-168> ffmpeg.git 03Michael Niedermayer 07release/2.2:29c8fac3f72c: avformat/avidec: allow rounding errors between scale/rate and timebase [00:39] <cone-168> ffmpeg.git 03Carl Eugen Hoyos 07release/2.2:d1b62a9a0771: Do not limit blocksize when reading PCM from aiff. [00:39] <cone-168> ffmpeg.git 03Carl Eugen Hoyos 07release/2.2:09d406eec811: avcodec/utvideodec: Increase vlc len [00:39] <cone-168> ffmpeg.git 03Michael Niedermayer 07release/2.2:989adf5ee521: avcodec/h264: in the absence of recovery points, be more tolerant on accepting plain I frames [00:39] <cone-168> ffmpeg.git 03Michael Niedermayer 07release/2.2:dae6c199950f: avcodec/mjpegdec: Improve intel jpeg flip heuristic [00:39] <cone-168> ffmpeg.git 03Martin Storsjö 07release/2.2:1e8ff7d21dc4: adpcm: Fix trellis encoding of IMA QT [00:39] <cone-168> ffmpeg.git 03Martin Storsjö 07release/2.2:3002e5976d43: adpcm: Write the proper predictor in trellis mode in IMA QT [02:04] <llogan> michaelni: what's the use case for the remove_extra bsf? [02:07] <michaelni> llogan, remove unneeded data, make frames slightly smaller, remove maybe disallowed data (some formats like mp4 expect global headers in their own atoms/chunks instead of in stream) [02:09] <llogan> what about the a, k, e values? [02:11] <BBB> michaelni: whos responsible for sample buffering in swr? [02:11] <BBB> michaelni: caller, or does swr do that somewhere that I cant find? [02:20] <michaelni> BBB, if the user passes more input than there is output space available, swr buffers that for the user in "in_buffer" [02:21] <michaelni> the codepath for this differs a bit between the case of insamplerate != outsamplerate and them being == [02:23] <michaelni> llogan, "a" == Auomatic , "k" == drop it from non Keyframes, 'e' maybe meant Everything maybe [02:25] <michaelni> and automatic is suppsoed tp mean "drop if the muxer has global headers and doesnt need them in stream" [02:30] <llogan> michaelni: ok. thanks for the info. [02:36] <BBB> michaelni: ok Ill see what I can do w/o breaking fate [04:08] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:9c9eac5c2666: tools/fourcc2pixfmt: Avoid using non public AV_PIX_FMT_NB [04:08] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2351ea8a2e8c: avformat/nutenc: Fix error handling in write_sm_data() [06:05] <UtUser> thanks for fixing the utvideo decoder [09:46] <kriegerod> michaelni: regarding MJPEG recognition. If you need, i can make port forwarding and make that camera's HTTP server reachable to you [13:07] <michaelni> kriegerod, if you could make the http accessible, yes, that might be usefull [13:17] <michaelni> j-b, reminder for zopan branch removial [14:16] <j-b> michaelni: done [14:17] <michaelni> j-b, thx [14:50] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:65571ee4e3c7: avformat/rawdec: add FF_DEF_RAWVIDEO_DEMUXER2, which allows specifying the flags [14:50] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:b45a451dbecb: avformat/rawdec: mark raw vc1 and mjpeg as having no timestamps [14:50] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:ec2b6ee59afa: avformat/utils: dont wait for a first dts on demuxers which have AVFMT_NOTIMESTAMPS set [14:50] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:0f0f6260484e: avformat/rawdec: Increase probe score when "Content-Type: image/jpeg" is found at the file start [15:17] <Daemon404> BBB, this isnt making have faith in chrome: https://code.google.com/p/chromium/issues/detail?id=333619 [15:21] <nevcairiel> Because they didn't implement this before? [15:38] <kierank> Daemon404: nobody gives a shit about that on the web [15:43] <J_Darnley> What functions does ffmpeg have for reading an arbitrary file? [15:43] <J_Darnley> I'm looking for something that you would use to open a file for controling a filter. [15:44] <ubitux> J_Darnley: av_file_map() maybe [15:45] <ubitux> look at vf_curves for an example [15:45] <ubitux> otherwise it depends on the file [15:45] <ubitux> we have helpers for opening just an image iirc [15:46] <J_Darnley> Thanks for the pointer, I'll look [15:46] <ubitux> otherwise probably just fopen like it's done in various filters [15:47] <ubitux> lut3d uses fopen for reading [15:47] <ubitux> psnr use fopen for writing [15:47] <ubitux> +s [15:52] <Daemon404> kierank, chrome is the only browser which does it wrong [15:52] <Daemon404> afaik [15:52] <Daemon404> safari does it right, firefox does it right, i think even IE does it right [16:04] <J_Darnley> I'm already using fopen so I will stick with that for now (rather that switching to av_file_map) but lut3d gave me a better idea about how I should handle file-related errors. [16:05] <Daemon404> using fopen directly probably isnt a great idea [16:06] <Daemon404> (inside a libav* i mean) [18:02] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:d7f398c54233: avformat/nutenc: Fix error handling in nut_write_packet() [18:02] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:3a76d7f73d49: avformat/nutenc: cleaner version check [18:27] <cone-6> ffmpeg.git 03Carl Eugen Hoyos 07master:5482780a3b6e: Allow values >31bit for -analyzeduration. [18:28] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:fbc133915bb0: Merge remote-tracking branch 'cehoyos/master' [18:34] <cone-6> ffmpeg.git 03Martin Storsjö 07master:0776e0ef6ba4: adpcm: Write the proper predictor in trellis mode in IMA QT [18:34] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:a2faa3d85809: Merge commit '0776e0ef6ba4160281ef3fabea43e670f3792b4a' [18:48] <cone-6> ffmpeg.git 03Martin Storsjö 07master:570d4b21863b: x86: h264: Don't keep data in the redzone across function calls on 64 bit unix [18:48] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:1a2ff628593c: Merge commit '570d4b21863b6254d6bbca9c528bede471bb4478' [19:51] <llogan> Plorkyeran: you were correct about the recursive box. thanks. [20:01] <ubitux> Daemon404: why? [20:08] <michaelni> is github broken ? error: The requested URL returned error: 403 while accessing https://github.com/michaelni/fateserver.git/info/refs [20:08] <michaelni> thats from a "git clone https://github.com/michaelni/fateserver.git" url copy and pasted from github [20:10] <Daemon404> michaelni, https://status.github.com/ [20:10] <michaelni> ahh, ok, thx [20:49] <cone-6> ffmpeg.git 03Christophe Gisquet 07master:8d02a55b1b93: tests: add a third, 34x34, target [22:16] <Daemon404> ubitux, why what [22:18] <J_Darnley> The use of fopen? [22:19] <J_Darnley> You said it was "probably bad" [22:19] <Daemon404> nothing is simple in libav* [22:19] <Daemon404> youre supposed to use avio_open [22:19] <Daemon404> iirc [22:19] <Daemon404> :D [22:19] <nevcairiel> but not from avcodec, it adds inter-lib deps! [22:21] <Daemon404> side data obv [22:21] Action: Daemon404 runs [22:28] <ubitux> Daemon404: ah for the protocol layer... yeah well shouldn't matter that much for filters [22:40] <J_Darnley> What function does the following approximate? (unsigned char) XOR 128 [22:42] <kierank> J_Darnley: force msb to one [22:50] <kierank> well not force [22:50] <kierank> xor it [22:51] <nevcairiel> that is kinda forcing [22:51] <nevcairiel> whatever the outcome [22:51] <nevcairiel> not sure whats the use on a unsigned [22:53] <J_Darnley> What if it was actually a signed char? [22:53] <nevcairiel> then it would ensure the number is negative after [22:53] <nevcairiel> by setting the sign bit [23:01] <J_Darnley> This must be signed data, its for an oscilloscope [23:26] <cone-6> ffmpeg.git 03Luca Barbato 07master:a736ae1e96b8: doc: Document mpegts muxrate [23:26] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:ac26d7ea9da4: Merge commit 'a736ae1e96b8718af0962106aa40df5f4b246b55' [23:26] <jamrial> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/hevc_deblock.… look at this "beta calculations" code [23:26] <jamrial> shouldn't that pshufd be a shufps? [23:27] <jamrial> judging by the comments, it seems to me that it's meant to combine the contents of m13 and m14 (something that shufps does) rather than discarding the contents of m13 (what pshufd is doing in this case) [23:41] <cone-6> ffmpeg.git 03Luca Barbato 07master:3f7e94eccd1c: mpegts: Move the option section to the bottom [23:41] <cone-6> ffmpeg.git 03Michael Niedermayer 07master:2d99b4041fb8: Merge commit '3f7e94eccd1c0d64679f2c4eda8bb942a158dfac' [23:47] <cone-6> ffmpeg.git 03Carl Eugen Hoyos 07master:723adfb1df13: Fix standalone compilation of the webvtt encoder. [00:00] --- Wed Jun 11 2014

1 0

ffmpeg.log.20140610
by burek 11 Jun '14

11 Jun '14

[00:06] <tyler1> if i use glob with test*.png, I'm getting the output video just have the last image [00:08] <tyler1> c_14: http://pastie.org/private/5uipecov6tyqk9qzbpaiq [00:08] <c_14> you need -f image2 [00:09] <c_14> At least, I think you od. [00:09] <c_14> *do [00:09] <tyler1> is that before the input options? [00:09] <c_14> should be [00:09] <c_14> And try putting the -r as an input instead of an output option as well. [00:10] <tyler1> yea i get the same log with -f image2 [00:10] <c_14> Well the log isn't [that] interesting, does the output file change? [00:10] <tyler1> still a tiny file of just the last frame [00:11] <tyler1> everything works fine if i use pattern type sequence [00:11] <c_14> try it with -loglevel debug? [00:11] <c_14> other than that I'm kinda out of ideas [00:12] <tyler1> :\ [00:12] <tyler1> thanks so much for your help though [00:12] <tyler1> i know what i'm trying to do is at least possible [00:12] <c_14> I've used pattern_type glob before, so I know it at least worked for me. [00:16] <jgh-> What is the unit of measurement for -frag_duration and -min_frag_duration? I am having a hard time finding much in the way of documentation on either of these parameters other than they exist and take an integer value. [00:16] <llogan> jgh-: looks to be microseconds [00:17] <jgh-> where did you see that? [00:17] <llogan> man ffmpeg-all [00:17] <jgh-> ah very good, thank you. I didn't know that man page existed. [00:18] <llogan> "man ffmpeg-formats" if you want more specifity [00:19] <jgh-> great, thanks for your help [00:19] <llogan> i mean if you don't want all of the other content that comes with ffmpeg-all [00:19] <jgh-> search works well enough in it in this case anyway. Good to know these exist now! [03:37] <|szn|1> Stream #0:0: Audio: mlp, 96000 Hz, stereo, s32 [03:37] <|szn|1> how come ffprobe is showing as s32 when it's s24 [03:37] <|szn|1> is this a bug [03:43] <Plorkyeran> 24-bit audio is often actually 32-bit audio with 8 bits always zero [03:45] <|szn|1> huh [08:17] <groundnuty> hey, I'm trying to create a dummy mp3 file. I isolated ID3 tag and MPEG header from real mp3 file [08:18] <groundnuty> both sumup to 130 bytes of data [08:18] <groundnuty> i tried to feed this to ffmpeg [08:20] <groundnuty> http://pastie.org/9275838 [08:20] <groundnuty> however when I copy into the dummy file not 130 but 756 bytes of orginal file all works fine [08:21] <groundnuty> *757 [08:21] <groundnuty> http://pastie.org/9275842 [08:21] <groundnuty> 757 seems like a magc number because 756 produces the same results as 130 [08:22] <groundnuty> if anyone had any idea why this is happening please help :) [08:23] <Musashi1> Hello, does anyone have any experience converting .movs to .oggs? I am trying to do it and the resultant video looks terrible. [08:27] <sacarasc> Musashi1: Might I ask why you're doing it? [08:27] <Musashi1> Sure - to create videos which can be played using html5 in firefox. [08:28] <sacarasc> Ah, okay. [08:28] <Musashi1> Unfortunate that it must be done.. [08:29] <sacarasc> I would go with WebM over OGG, Theora is pretty bad. [08:31] <sacarasc> https://trac.ffmpeg.org/wiki/Encode/VP8 is a guide to do that. [08:31] <Musashi1> Jeez. Id have to check with my coder to see if we can accept WebMs [08:32] <Musashi1> Thank you. Is it just not possible to have it look good with theora? [08:32] <sacarasc> It probably is, but I don't know how. [08:33] <sacarasc> http://trac.ffmpeg.org/wiki/TheoraVorbisEncodingGuide is a bit limited. [08:39] <Musashi1> ill try that [08:39] <Musashi1> thank you by the way [08:51] <Musashi1> Dude. [08:52] <Musashi1> That worked. Thank you very much. [09:14] <ubitux> theora looking good? erm, at what bitrate cost... [09:14] Action: sacarasc giggles at ubitux. [09:14] <ubitux> blast from the past [10:35] <Musashi1> ubitux: why is theora a blast from the past? [10:36] <ubitux> well, technically& it kind of sucks [11:51] <Musashi1> Wow these mp4s are way smaller than oggs [16:44] <sfan5> is it normal for ffserver to complain about PTS when I run ffmpeg two times with different files to stream to it? [16:45] <c_14> ye, that's probably normal. it's expecting new pts > end pts of previous file and is getting pts < end pts of previous file [16:46] <sfan5> is there an easy way to prevent this? [16:48] <c_14> you could try manually setting the pts in the second command or give both files as input to the first command [16:48] <sfan5> I can give both [16:49] <sfan5> that is convenient [17:05] <sfan5> c_14: how do I give it multiple inputs? ffmpeg -i foo -i bar http://.... does not work and ffmpeg -i foo http://.... -i bar http://.... doesn't either [17:05] <c_14> ffmpeg -i foo -i bar http:// [17:05] <c_14> should work anyway. [17:05] <sfan5> hm [17:06] <sfan5> oh, sure [17:08] <sfan5> c_14: http://ix.io/cTB [17:09] <c_14> eh, wait. [17:09] <c_14> use the concat demuxer [17:10] <c_14> https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20(join,%20merge)%20med… [17:10] Action: c_14 's brain went all poof [17:11] <sfan5> seems to work [17:12] <sfan5> thanks [17:12] <c_14> np [17:17] <sfan5> another one: can I tell ffserver to pass through the metadata or is the meta not even sent to the server on encoding? [17:18] <sfan5> seems like there is no meta in music.ffm [17:18] <c_14> try adding -map_metadata 0 [17:19] <sfan5> I'll try that later, thanks again [17:25] <vklimkov> hello. trying to compile trunk version of ffplay.c. is it possible to do it with sdl 2.0? [17:27] <vklimkov> from errors it looks like aold sdl api is used [19:11] <needmorespeed1> trying to compile ffmpeg with OpenGL with QT: /Qt5.3.0/5.3/gcc/include/QtGui/qopenglext.h:6276: error: 'uint64_t' does not name a type [19:16] <sfan5> needmorespeed1: which OS/Distro? [19:17] <_genuser_> hello folks. I understand that .WTV files arere ow supported. However, I noticed that it work sometimes and doesn't work at other times. [19:17] <_genuser_> sometimes, two files from the same channel behave differently. One work and the oher doesn't. But then there are channels that encode a WTV file that doesn't work ever in ffmpeg or even in handbrake. those can most likely be blamed on media center recording format. [19:18] <_genuser_> so the question is has this been investigated/documented. Is it just a matter of getting the latest and compiling it? [19:19] <_genuser_> cmd used: ffmpeg -i <filename.wtv> -vcodec copy -acodec copy -f mpg2video output.mpg [19:28] <Fjorgynn> *compiling* [19:28] <Fjorgynn> _genuser_: might be able to encode but not decode or vice versa [19:29] <tyler1> how can i make ffmpeg not drop duplicate frames? [19:29] <tyler1> when turning a sequence of images into a video [19:38] <_genuser_> Fjorgynn: it sounds like microsoft isn't too strict on how they write the files. Files from certain tv channels always have audio encoded differently and in a different order in teh container. Which causes handbrake/ffmpeg to just assume the audio doesn't exist. [19:54] <llogan> tyler1: [19:55] <llogan> _genuser_: yes, testing a recent build is the first step. if you're lazy just get one at ffmpeg download page. [19:57] <_genuser_> sure, I can compile the latest , no issue. [19:58] <tyler1> llogan: sorry, I think I figured it out [19:58] <tyler1> i put -r on the input options instead of output [20:34] <llogan> dericed1: ping [20:39] <dericed1> llogan: pong [20:39] <llogan> dericed1: what FCP version did you test for imxdump? [20:39] <dericed1> 7 [20:40] <llogan> thanks for testing...and i should have caught the imx_dump_header name difference. that wasn't the first one like that. [20:41] <llogan> maybe I'll just remove the bsf instead. i wonder what FCP/QT versions it was for [20:43] <dericed1> i didn't have a chance to test with fcp x, but did see that both qt 7 and qt x handled it differently [20:43] <dericed1> but i guess that difference was because of vtag not the bsf [20:44] <llogan> do you even use fcp x? [20:54] <dericed1> i have access to fcp x [21:05] <llogan> dericed1: what happens if you stream copy without -vtag mx3n (and without the bsf)? [21:07] <dericed1> llogan: similar results as with bsf [22:03] <DX099> hello all, I'm trying to mux some h264 vid and aac audio but the output files only gets audio : http://hastebin.com/utukuwagup.pas [22:03] <DX099> can someone help ? [22:04] <c_14> try it with the ffmpeg static builds [22:05] <ss_> Hi, I am new to ffmpeg.. I have searched the web but could not find any solution..Pl help me with the following scenario.. Eg: I have an image of size x*y in a fixed frame.. I want to move the image to left keeping the frame static and introducing a blank background on the right side of shifted image.. Is it possible using ffmpeg? Usecase: Want to generate the right eye image from a left eye image to generate a stereo pair.. Also let me [22:05] <ss_> better way [22:05] <c_14> ss_: crop and pad? [22:07] <ss_> for cropping: ffmpeg -i Food-L.jpg -filter:v "crop=1950:1521:50:0" x.jpg.. I get error http://pastebin.com/y2N21RNn [22:07] <c_14> how big is the input picture? [22:08] <ss_> 2000x1510 [22:08] <ss_> lets suppose I want to crop left rectangle of 50*height of image [22:10] <smalltock> DX099: I don't really have any idea what I'm doing with ffmpeg, but maybe use -f on the input streams to make sure neither is overwriting the other for whatever reason. [22:12] <c_14> ss_: try crop=iw-50:ih:50:0 [22:14] <DX099> samllstock, where do I put the -f options ? [22:14] <c_14> smalltock: I had a similar problem with someone yesterday and switching to the static ffmpeg builds (from libav) fixed it. cc DX099 [22:14] <DX099> yeah but this is a headless server [22:14] <c_14> so? [22:15] <DX099> starting compiling ffmpeg just for this is too much hassle for one vid [22:15] <c_14> That's why I linked you the static binary. [22:15] <c_14> No need to compile. [22:15] <c_14> Just download and use. [22:15] <DX099> meh ? such a thing exists on Linux ? [22:15] <c_14> yes [22:16] <smalltock> DX099: Before the -i options. It's `-f «format»`, but nevermind my suggestion. I highly doubt that's it. [22:16] <ss_> This works! [22:16] <DX099> ok, so basically I just untar it and it's clear to go ? [22:16] <c_14> ye [22:20] <DX099> yeah ! it worked :) [22:20] <DX099> thanks ! [22:20] <c_14> np [22:20] <DX099> I was so down when you told me to use another build [22:20] <DX099> so it's an old bug hmm ? [22:21] <DX099> may I link /usr/bin/ffmpeg to that static binary ? [22:21] <c_14> you can just copy it over if you want, if you don't mind overwriting the file [22:22] <c_14> libav (of which avconv is a part) is actually a fork of ffmpeg [and for reasons unknown to me usually doesn't work as well] [22:22] <DX099> hmm, I'll back up distro's exe and copy it [22:22] <c_14> if you're interested [22:23] <DX099> I already read a bit on that but what I fail to understand is : how do you know which one you're using ? I got the impression that even when compiling ffmpeg, it'll warn about being renamed avconv [22:23] <DX099> how do I know when "apt-get install ffmpeg" (Debian 7) which project I'm using ? [22:25] <c_14> ffmpeg -version, and then if you look in the first line. If it's ffmpeg it should say copyright the FFMpeg developers, libav has copyright the Libav developers [22:25] <ss_> c_14: padding failes using: ffmpeg -i x.jpg -filter:v "pad=iw:ih:50:0:white" food-lr.jpg, I want to introduce a white pad to the right 50*h dimension of image. Error: http://pastebin.com/1dJEY4ge [22:27] <c_14> pad=iw+50:ih:iw-50:0 [22:32] <ss_> fails: http://pastebin.com/U1eRRQad [22:33] <c_14> pad=iw+50:ih:0:0 one should read the documentation thoroughly before handing out examples [22:37] <c_14> DX099: I lied, ffmpeg at least only shows the copyright on commands that aren't -version. so just `ffmpeg' would give the copyright notice [22:37] <DX099> c_14, hmm yah noticed that [22:38] <DX099> thanks anyway [22:38] <DX099> they could have changed exe name once and for good, it's quite misleading :/ [23:02] <vtorri> hey [23:03] <vtorri> can ffmpeg (the library) save video with mpeg4 layer 2 without external dependency (that is, without xvid, for example) ? [23:03] <c_14> it should be able to [23:07] <vtorri> c_14: thank you [23:54] <JackWinter> i get this msg "[swscaler @ 0xed8980] deprecated pixel format used, make sure you did set range correctly" when trying ton encode to prores 422 with -pix_fmt yuv422p10le, command and output on: https://gist.githubusercontent.com/anonymous/93955a11816854672fb1/raw/9d44a… any thoughts? [00:00] --- Wed Jun 11 2014

1 0