Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2013

1 participants
54 discussions

ffmpeg-devel.log.20131230
by burek 31 Dec '13

31 Dec '13

[00:11] <BBB> smarter: shall i help? [00:51] <cone-251> ffmpeg.git 03James Almer 07release/2.1:b962157ce36f: matroskadec: Fix bug when parsing realaudio codec parameters [01:03] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:100a54da5264: avcodec/lagarith: disable lag_decode_zero_run_line() and ask for a sample [01:03] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:3410122c687b: avcodec/lagarith: fix src/src_size for esc_count < 8 [01:03] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:e80aa47abf74: avcodec/lagarith: fix init_get_bits() size in lag_decode_arith_plane() [01:33] <BBB> how times have changed [01:34] <BBB> I asked first during the msvc work whether we could kill compound literals [01:34] <BBB> the flamewar that that started is still in my mind, and not in a positive way [01:34] <BBB> well I guess it's good sentiments change [01:38] <wm4> is there any advantage to make the standard timebase independent from ABI? (that's the only effect such a change could have) [01:38] <wm4> are you planning changing the timebase every 2 months or so? [01:38] <wm4> or randomize it at program start? [01:41] <BBB> I'm not planning anything [01:41] <wm4> that goes to Daemon404 I guess [01:44] <Compn> lol randomize at program start [01:45] <wm4> yeah, that was some sarcasm, but I seriously wonder why it can't be a constant [01:46] <Compn> just make a patch -constanttb [01:46] <Compn> it will be applied [01:46] <Compn> so let it be written, so let it be committed [02:25] <cone-251> ffmpeg.git 03Carl Eugen Hoyos 07master:b4c89c90ffc7: Allow hiding the banner. [02:25] <cone-251> ffmpeg.git 03Carl Eugen Hoyos 07master:de40905f55cd: Fix condition for transparency warning in xsub encoder. [02:25] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:4aa9c9150820: Merge remote-tracking branch 'cehoyos/master' [04:33] <cone-251> ffmpeg.git 03James Almer 07master:d890db5f537b: oggdec: add support for VP8 demuxing [10:53] <ubitux> i have a weird bug i'm not sure how to solve [10:53] <ubitux> ./ffmpeg -i ~/samples/big_buck_bunny_1080p_h264.mov -vf scale=80:44,tile=10x1 -frames:v 1 -y out.jpg this works [10:54] <ubitux> ./ffmpeg -i ~/samples/big_buck_bunny_1080p_h264.mov -vf fps=0.10,scale=80:44,tile=10x1 -frames:v 1 -y out.jpg this doesn't [10:54] <ubitux> [mjpeg @ 0x216eba0] bitrate tolerance too small for bitrate [10:54] <ubitux> of course the mpeg encoder doesn't need a huge bitrate [10:54] <nevcairiel> i guess it somehow factors the fps into there [10:54] <ubitux> the problem is, that sanity check is based on the not filtered input [10:55] <ubitux> afaict [10:55] <saste> when you set the bitrate, how the encoder knows the framerate? [10:56] <ubitux> i have absolutely no idea [10:56] <ubitux> anyway i workarounded the problem using a constant scale (-q:v 0) [10:56] <ubitux> but i'd like to know if there is something fixable here [11:04] <ubitux> saste: why "or"? [11:04] <ubitux> it's a "and" [11:05] <ubitux> it pauses the playback if necessary, and then it steps to the next video frame [11:07] <saste> if you just press "s", it will pause AND step to the next frame? [11:08] <saste> or it will only pause? [11:08] <ubitux> it will pause AND step to the next frame [11:09] <ubitux> basically the step to next frame is only meaningful if the video is paused [11:09] <ubitux> so it pauses the video, and then does a one step frame [11:09] <ubitux> the code is pretty straightforward about this [11:09] <ubitux> there is even a comment about that [11:10] <saste> i'm fine with "and" if that's what the implementation does [11:10] <ubitux> mmh, comment is about sth else, sorry [11:12] <ubitux> in the ffplay logic, it actually unpause it if necessary, step one frame, then pause [11:12] <ubitux> which is equivalent and more user-friendly to saying "pause if necessary, and then step one frame" [11:34] <cone-510> ffmpeg.git 03Luca Barbato 07master:9a4c10e3af01: lavu: Move preprocessor macros in a separate file [11:34] <cone-510> ffmpeg.git 03Michael Niedermayer 07master:8ccc58bb7d72: Merge remote-tracking branch 'qatar/master' [11:44] <ubitux> saste: we don't have a -pix_fmts, -formats, etc output with the writers right? [11:46] <saste> ubitux, no [11:46] <ubitux> too bad :( [12:00] <ubitux> oh, got my rpi, i should be able to test your stuff clever [12:42] <saste> ubitux, why do you need them? [12:42] <saste> the output is already "more or less" parsable [12:43] <saste> adding an option for that would be from trivial to easy [12:43] <ubitux> accessing the number of components [12:43] <ubitux> to check if the pix fmt is alpha or not [12:44] <ubitux> yes it's more or less parsable, but if i could do a pix_fmts = json.loads(exec('ffprobe -of json -pix_fmts')) that would be even better :) [12:44] <ubitux> s/is alpha/has alpha/ [12:48] <cone-510> ffmpeg.git 03Reimar Döffinger 07master:b74eead27b47: compat: provide va_copy for old gcc versions. [12:48] <cone-510> ffmpeg.git 03Reimar Döffinger 07master:311f61e1b4d5: configure: check that pthreads is compatible with compiler. [12:48] <cone-510> ffmpeg.git 03Reimar Döffinger 07master:3cc0f335fe14: af_aresample: remove only use of array compound literals with non-const initializers in FFmpeg. [13:15] <ubitux> Daemon404: i'm pretty sure some other places assume 1000000 as timebase [13:15] <ubitux> so chagning it will likely break various things [13:15] <ubitux> i don't think the macro is here "to be changed at some point in the future" but more as a semantic constant [13:16] <ubitux> (try to grep 1000000 in ffplay for instance) [13:17] <ubitux> also maybe stuff like libavformat/tta.c: if(samplerate <= 0 || samplerate > 1000000){ [13:37] <cone-510> ffmpeg.git 03Nicolas George 07master:bcfcb8b8524d: lavc/ffwavesynth: fix dependency sizeof(AVFrame). [13:37] <cone-510> ffmpeg.git 03Nicolas George 07master:a55692a96099: ffprobe: check av_frame_alloc() failure. [13:37] <cone-510> ffmpeg.git 03Nicolas George 07master:38004051b53d: lavc/utils: check av_frame_alloc() failure. [13:37] <cone-510> ffmpeg.git 03Nicolas George 07master:a91394f4de63: lavc/diracdec: check av_frame_alloc() failure. [13:37] <cone-510> ffmpeg.git 03Nicolas George 07master:97af2faaba70: lavc/libopenjpegenc: check av_frame_alloc() failure. [13:37] <cone-510> ffmpeg.git 03Nicolas George 07master:19a2d101acc0: lavc/mjpegenc: check av_frame_alloc() failure. [13:37] <cone-510> ffmpeg.git 03Nicolas George 07master:2ebaadf35c93: lavc/mjpegenc: use proper error codes. [13:37] <cone-510> ffmpeg.git 03Michael Niedermayer 07master:905bac2cd30d: Merge remote-tracking branch 'cigaes/master' [14:13] <cone-510> ffmpeg.git 03Michael Niedermayer 07master:6f1b2967712e: avcodec/lagarith: reenable buggy lag_decode_zero_run_line() [14:13] <cone-510> ffmpeg.git 03Michael Niedermayer 07master:afd1245433e9: avcodec/lagarith: use init_get_bits8() [14:40] <j-b> so much fun on lagarith, as I see :) [16:26] <cone-510> ffmpeg.git 03Michael Niedermayer 07master:61d43a265176: avcodec/lagarith: check and propagate return value from init_get_bits8() [17:04] <Daemon404> [07:15] <@ubitux> Daemon404: i'm pretty sure some other places assume 1000000 as timebase <-- then it's wrong. [17:05] <ubitux> sure, but that's something you would have to deal with if you want to change it [17:05] <ubitux> changing this constant doesn't look trivial at all [17:06] <Daemon404> yes, but that's also beyond the scope here [17:08] <ubitux> note that AV_TIME_BASE is used in a lot of apps [17:08] Action: Daemon404 needs to go to an eye exam now... herp [17:08] <Daemon404> [11:08] <@ubitux> note that AV_TIME_BASE is used in a lot of apps <-- you could say this about *any* API bit [17:08] <Daemon404> it's not a useful argument [17:09] Action: Daemon404 really does go now [17:09] <iive> it means that changing it would break the abi [17:09] <ubitux> well, i think the constant has its usages [17:09] <ubitux> i would just make the getter return the constant [17:09] <ubitux> for people who want to be ABI compatible in a potential future [17:10] <ubitux> and keep the macro for ppl who don't bother [17:10] <Daemon404> [11:09] <@iive> it means that changing it would break the abi <-- again this is sad about any bump chnge [17:10] <Daemon404> which happen quuite often [17:10] <iive> thanks to the crap pouring from libav. [17:10] <ubitux> i think having the getter and the constant is nice [17:10] <Daemon404> lots of the stuff theyve done is atually use ful (ref counting) [17:10] <Daemon404> (and lots is not) [17:11] <wm4> can someone explain my why the constant can't be part of the ABI, and if not, why you just don't use custom timebases everywhere (stored in extra fields) [17:12] <ubitux> you mean having it as an extern int/int64? [17:12] <iive> constant is exported by .h headers and compiled directly into application code. [17:13] <iive> to be honest, I have no idea why there is timebase at all, ffmpeg had rational number support for quite long time. [17:13] <Daemon404> [11:12] <@ubitux> you mean having it as an extern int/int64? <-- this gave certain compilers issues (whatsup windows?) [17:13] <Daemon404> there was a big push to remove them all a while back [17:13] <ubitux> don't we have av_export for this? [17:13] <nevcairiel> data exports are evil [17:13] <ubitux> sure [17:14] <Daemon404> .. i really must go now or ill be late [17:14] Action: Daemon404 out [17:14] <ubitux> i'm just asking if that's what wm4 was asking [17:14] <wm4> no [17:15] <wm4> AFAIK AVFormatContext.duration is one of the fields which implicitly use AV_TIME_BASE [17:15] <wm4> so why not just add AVFormatContext.duration_timebase? [17:15] <ubitux> iive ? [17:16] <ubitux> afaik format don't have a global timebase, they're using AV_TIME_BASE [17:16] <iive> AVRational ? [17:16] <ubitux> which is needed for seeking typically [17:16] <ubitux> and they're probably some other usage [17:18] <nevcairiel> wm4: but why not simply define a constant timebase for all fields that don't have a file timebase they are derived from [17:19] <nevcairiel> you know, like today [17:19] <wm4> I'm not the one who wants to change everything for no reason :) [17:19] <wm4> I assume there's a problem with the current timebase [17:19] <wm4> which is why it apparently (?) has to change [17:19] <ubitux> i think the main reason is inline AVRational [17:20] <ubitux> in the _Q version [17:20] <ubitux> and for consistency AV_TIME_BASE is changed as well [17:20] <nevcairiel> the problem is the inline C99 feature in an installed header [17:20] <wm4> you don't have to use the C99 feature [17:21] <nevcairiel> i know, and i never did [17:21] Action: wm4 is searching for the problem [17:21] <wm4> ...has it been found yet? [17:21] <ubitux> dunno [17:21] <ubitux> Daemon404 certainly has a reason for wanting to change everything ;) [17:21] <nevcairiel> someone thought that was it, having a C99 feature in a public header [17:21] <iive> look, if I understand the problem correctly, e.g. the duration field is supposed to be in seconds. because it usually is a fraction of a seconds, you need to use a fixed of float point to get reasonable representation. [17:22] <iive> at the moment it is a fixed point with pre-defined constant time_base. [17:22] <iive> i guess you don't want to use floats, for various of reasons. [17:23] <iive> the other solution is to use rational number, where the nominator is the current value and the denominator just holds the time_base [17:23] <nevcairiel> borh are even worse api breaks [17:23] <nevcairiel> both [17:24] <ubitux> we should just add the 2 function helpers and keep the macro as well [17:24] <ubitux> that way c++ apps & friends can access it without trouble [17:24] <ubitux> and we are not annoying our users and changing the whole codebase [17:25] <ubitux> ...for no apparent reason except "making it sane/consistent/pretty/whatever" [17:25] <iive> sure, this is why there should be a good reason to break the api in first place and have an idea of cost/benefit ratio. [17:25] <iive> you want to turn the define into function call? [17:26] <ubitux> and btw, haters gonna hate but... it's gonna add a bunch of function calls! (since it's exported i don't think it will be inlined) [17:26] <ubitux> well, Derek wants, I don't [17:26] <iive> why does he wants it? [17:27] <iive> what problem does he solve? [17:27] <ubitux> 17:20:28 <+nevcairiel> the problem is the inline C99 feature in an installed header [17:27] <iive> or rather tries to solve. [17:27] <ubitux> which is already the case anyway (av_ts2str, av_err2str, probably more) [17:28] <nevcairiel> dont tell him, or he'll "fix" those too [17:28] <ubitux> he can't [17:28] <ubitux> there is no other way [17:28] <nevcairiel> he can make em private [17:28] <ubitux> no, users are already using it [17:29] <ubitux> so i will put a veto on it [17:29] <nevcairiel> any api change will screw users, its just a question of how much [17:29] <ubitux> there is no need for an api change& [17:30] <ubitux> we just need to provide one or more function helper for app not supporting the macro [17:30] <nevcairiel> tell that to the patch authors. :p [17:35] <wm4> also, even in C++, you can construct AV_TIME_BASE_Q trivially [17:35] <ubitux> yes. [17:35] <wm4> you can assign fields to structs, right? [17:36] <ubitux> yes, you can put that function in your c++ app [17:36] <wm4> AVRational r; r.num=1; r.den=AV_TIME_BASE; [17:36] <wm4> whoo! [17:48] <nevcairiel> in recent c++ compilers you can even do it in one line [17:48] <nevcairiel> not sure the old macro works in C++11 [17:48] <ubitux> oh, dvb sub patch. [17:50] <wm4> it should have been "#define AV_TIME_BASE_Q {1, AV_TIME_BASE}" [17:51] <ubitux> you can't inline it in function call without the cast [17:52] <wm4> C99 users could have added this themselves [17:52] <wm4> and it'd work as initializer in C90/C++ [17:53] <ubitux> you win 2 char with your method [17:53] <ubitux> macro is basically void [17:53] <ubitux> no purpose at all [18:19] <clever> ubitux: when using eosd, are there any utils to merge nearby elements? [18:20] <wm4> clever: no [18:21] <wm4> these come from libass, and libass returns a surface for each glyph [18:21] <wm4> actually, at least 2 per glyphs if the text has a border [18:21] <clever> i guess i'll have to do some merging myself then [18:22] <clever> dispmanx has a software limit of 128 elements [18:22] <wm4> you should branch them to the gpu [18:22] <wm4> oh [18:22] <wm4> s/branch/batch [18:22] <clever> the api does allow batching, but its hard limited to 128 elements at a time [18:23] <clever> so i need to create a few regions, like the top and bottom line of text [18:23] <clever> and merge the glyphs into a single line of text [18:23] <clever> then create 2 or 3 surfaces for those [18:23] <clever> that, or just do full 720p frames and kill performance [18:24] <wm4> most images can't be combined, because every image has a per-surface color/alpha [18:24] <clever> pallet based stuff? [18:24] <clever> i havent fully looked at exactly what its giving me yet [18:26] <clever> hmmm, bitmap is a 1 bit per pixel alpha map, color is a rgb value [18:26] <clever> so i would need to bulk up things with the same color into a single layer [18:27] <clever> and figure out if dispmanx can handle 1 bit per pixel alpha with solid color [18:27] <clever> wm4: one more question, if a glyph is reused many times, will they all have the same mp_eosd_image ? [18:27] <clever> will the opaque pointer survive between glyph reuse? [18:28] <wm4> I don't know that part of mplayer (my mplayer fork has relatively different internals here), but no [18:29] <clever> was thinking along the lines of drawing each glyph to a rgba resource and then reusing those [18:31] <clever> as for pallet support, ive seen another ticket, and the hardware can only handle a single pallet at a time [18:32] <clever> so i would likely need to merge all the colors into a single pallet, and create an 8bbp image [18:37] <j-b> m [18:37] <j-b> oops, sorry [19:16] <clever> size:18x19 pos:567x428 [19:16] <clever> wm4: looks like most of the glyphs are of a reasonable size [19:17] <wm4> clever: depends entirely on the input file [19:17] <wm4> but on insane stuff, little rpi will probably lock up forever anyway [19:18] <clever> its already locking up solid, not even ssh responds [19:18] <clever> and i'm not even trying to handle the glyph image! [20:00] <clever> wm4: each mp_eosd_image contains a *next pointer to the next image, so its imposible to reuse a single instance in a frame [20:00] <clever> so thats half of my question [20:00] <wm4> no, it doesn't do that [20:01] <wm4> clever: this is what libass outputs: http://repo.or.cz/w/libass.git/blob/HEAD:/libass/ass.h#l37 [20:01] <wm4> the image data (->bitmap) can be reused, but ASS_Image obviously not [20:01] <wm4> an application has to re-render stuff on every frame [20:02] <clever> i was trying to see if i could cache the converted bitmap, and then reuse it [20:02] <wm4> ass_render_frame() merely can signal to the application that the frame didn't change visually (even if the ASS_Images changed), mplayer maybe uses that [20:02] <wm4> no you can't [20:02] <clever> yeah, i do see a changed flag in eosd [20:02] <clever> vdpau will reuse the entire surface list unchanged [20:03] <clever> just need to think out how i'm going to draw 100 glyphs into 2 or 3 chunks [20:05] <wm4> it's a hard problem [20:06] <wm4> at least if you don't want to do cpu rasterization [20:06] <wm4> or rather, cpu blending [20:12] <clever> wm4: as long as no glyphs overlap, i should be able to do hardware blending [20:13] <wm4> many glyphs will overlap [20:13] <clever> it allows full rgba layers and blending between all 128 layers [20:13] <clever> i can handle glyph overlap cheaply by just creating 2 hardware layers [20:13] <clever> and letting the hw blend the overlap [20:13] <clever> the hard part is knowing which hw layer to put each glyph into [20:14] <clever> and how big to make each hw layer [21:24] <wm4> is there a primer for yasm+x86inc? [21:24] <nevcairiel> there is this: https://wiki.videolan.org/X264_asm_intro/ [21:24] <nevcairiel> and the comments in x86inc [21:25] <wm4> thanks [22:08] <llogan> kierank: wow. your license violation report actually got response (but i didn't check compliance for their updated stuff). [22:28] <Compn> on that dshow plugin ? [22:29] <Compn> on thier bug tracker or ours ? [22:32] <ubitux> wm4: gonna write som asm? [22:33] <wm4> ubitux: someone wants for libass [22:33] <ubitux> oh, ok. [22:33] <wm4> xy-vsfilter has pages over pages of instrinsics [22:34] <Daemon404> wm4: inline asm too iirc? [22:34] <Daemon404> also some of the mmx code is slower than C++ [22:34] <Daemon404> it's very great [22:34] <wm4> hm, possibly, but I don't remember [22:34] <Daemon404> i really like when people wrte naive SIMD intrinsics [22:34] <wm4> but xy-vfilter is literally "TOO SLOW? HERE IS MORE INTRINSICS" [22:34] <Daemon404> its so easy to be slower than compiler-generated code [22:34] <Daemon404> [16:34] <+wm4> but xy-vfilter is literally "TOO SLOW? HERE IS MORE INTRINSICS" <-- gnna sound bad but... china quarity [22:36] <iive> aren't intrinsics compiler generated code? [22:36] <Compn> if you guys keep insulting chinese devels, you might never see them join the project :P [22:37] <Daemon404> iive: well i mean generated from C/C++ [22:37] <nevcairiel> i dunno what people have against intrinsics [22:37] <Daemon404> nevcairiel: i dont have anything against them. [22:37] <Daemon404> i am against the horrible way they tend t be written [22:37] <Daemon404> by certain people [22:39] <Daemon404> nevcairiel: well also modern compilers do OK at generating SSE/SSE2 fp code [22:39] <Daemon404> without any help [22:39] <Daemon404> keyword: modern [22:40] <nevcairiel> if someone uses intrinsics just to write single-data fp code, they deserve to be yelled at [22:40] <nevcairiel> its for multiple-data code where its useful, read SIMD [22:40] <Daemon404> that sounds exactly like something xy would do [22:40] <Daemon404> and also no C path. [22:41] <iive> nevcairiel: intrinsics are SIMD code in C [22:41] <nevcairiel> i know what they are, but that doesnt mean you use them with the MD in mind :p [22:41] <iive> but compilers are quite unstable about the results they generate, even when the translation seems quite straight - forward. [22:42] <nevcairiel> nonsense, recent compilers process them rather well [22:42] <iive> last time i tried it was one year ago... so 4.7 or 4.8 ... [22:51] <iive> ffmpeg have its altivec (ppc) acceleration written as intrinsics [22:51] <wm4> anyway, when that guy tried instrinsics, he noticed that there weren't many SSE instructions in the generated code [22:51] <wm4> and the compiler (apparently) did many stupid things [22:52] <iive> you need to specify sse capable cpu and autogeneration of sse instructions. [22:53] <wm4> well he wasn't that dumb [22:53] <iive> this also means you need more makefile tricks if you want things as autodetection and conditional execution. [22:53] <wm4> i.e. he did make sure of that [22:53] <nevcairiel> have to be careful not to look at the generated code in a debug build, compilers like to add a copy back into memory after every intrinsic call then for better variable inspection [22:55] <iive> wm4: sure, as I said, compilers are known to do stupid things. [22:56] <nevcairiel> i never had issues, and i frequently inspected the generated code while testing, so i blame you or your compilers, mine works :D [22:57] <wm4> so does msvc generate better code from intrinsics than gcc? [22:57] <nevcairiel> no idea [22:57] <nevcairiel> msvc generates proper code at least [22:58] <nevcairiel> basically mapped 1:1 to the corresponding instruction [23:00] <nevcairiel> but since microsoft has been working to fade-out inline asm (like by not allowing it for 64-bit builds at all), they may have put more time into it [23:13] <ubitux> BBB: any reason in the dsp init not to make the loop_filter functions depends on each others? [23:13] <ubitux> i mean, calling dsp->loop_filter_... instead [23:13] <ubitux> that way typically in x86 if you add a small one it gets automatically used in all the dependency [23:14] <ubitux> ah i guess dsp is not actually accessible [23:41] <kierank> llogan: i told him [00:00] --- Tue Dec 31 2013

1 0

ffmpeg.log.20131230
by burek 31 Dec '13

31 Dec '13

[01:00] <kcm1700> Is there a way to pass so-called 'extradata' to mpeg4-video codec after avcodec_open# ? [01:00] <kcm1700> codec_id is AV_CODEC_ID_MPEG4 [02:42] <kcm1700> no one here? T.T [02:57] <llogan> try libav-user mailing list if you don't get an answer here [03:14] <kcm1700> thank you. is it ok to use libav-user mailing even if I use ffmpeg? [03:46] <rcombs> does ffmpeg not support building with SDL2 yet? [07:05] <sisco_dreamber> hi all [07:05] <sisco_dreamber> any one here able to help me plz [08:34] <zap0> just ask [08:35] <zap0> also, good luck, you said like a moron.. 'plz' [09:12] <sisco_dreamber> zap lol [09:12] <sisco_dreamber> well its more ruby [09:12] <sisco_dreamber> so im at ruby lobby [10:37] <matthias_> Can sb help me with some pulseaudio and ffmpeg scripting? [10:40] <saste> matthias_, don't ask to ask, just ask [12:13] <vvu|Log> hello! i am trying to save some images from an RTSP stream and i get "unimplemented RTP/JPEG restart marker header". from what i see this comes from libavformat/rtpdec_jpeg.c [12:13] <vvu|Log> the id of the jpeg decoder params is > 63 *don't really know what this means* [14:43] <feep> hi, can I use ffmpeg to convert a high-fps video (like 120) to a low-fps motion-blurred video? [15:08] <zap0> probably, but you really shouldn't think of ffmpeg as an fx thingy [15:08] <zap0> the rate conversion yes. blur.. maybe [16:56] <benbro2> when recording video from screen, how can I know the timestamp of the first frame? [17:09] <zap0> record the time in teh first frame. [17:10] <benbro2> zap0: how? [17:10] <benbro2> I want to use something like "ffmpeg -f dshow -i video="UScreenCapture" output.flv" [17:10] <benbro2> can I get the timestamp of the first frame from output.flv? [17:16] <viric> -vf showpts [19:12] <Xaser> hiho [19:13] <Xaser> I have a quick question about using ffmpeg to split audio streams. [19:14] <Xaser> Basically I want to losslessly extract a one minute sample from a) the original ac3 file, b) the aac encoded (nero) version of that original [19:16] <Xaser> I've been using this command: ffmpeg -i "org.ac3" -ss 00:02:30 -t 00:01:00 "Sample1.ac3" and ffmpeg -i "enc.m4a" -ss 00:02:30 -t 00:01:00 "Sample2.m4a" [19:17] <Xaser> now.. is that the correct way to do this and will the extracted sample2 sound different compared to the reencoded sample1 ? [19:28] <Xaser> anybody? [19:54] <clever> Xaser: i think that will re-encode the tracks by default [19:54] <Xaser> hm [19:54] <clever> you probly want to add -acodec copy [19:55] <Xaser> okay [19:55] <Xaser> i was wondering why the file sizes of all three samples turned out the same^^ [19:56] <Xaser> anything else I should take into concideration? [20:18] <benbro2> when starting a screen capture from the command line, how can I stop it? [20:18] <benbro2> just Ctrl+C ? [20:18] <benbro2> or will it leave a corrupted video? [20:28] <Xaser> it won't affect the input file, thats for sure [20:28] <Xaser> however it won't create a valid video file [20:29] <Xaser> @benbro2 that is [20:30] <relaxed> benbro2: did you try 'q'? [20:31] <benbro2> I need something like "ffmpeg -f dshow -i video="UScreenCapture" output.flv" under windows [20:31] <benbro2> 'q' is under linux? [20:32] <relaxed> Try it. You can also use -t $time after the input [20:34] <benbro2> relaxed: I need to stop it dynamically [20:34] <benbro2> maybe from powershell [21:00] <Davym123> I probably the 1000th person to be here for a problem, so first of all.. Sorry! Anyway, there is a php script that requires ffmpeg with xvid coddec support but I can't get it to work..! [21:00] <Davym123> http://prntscr.com/2f7mku [21:00] <Davym123> Look [21:01] <Davym123> http://prntscr.com/2f7n9a [21:11] <Davym123> Any idea, anyone? [21:33] <Davym123> Nobody here? :D [21:33] <llogan> Davym123: why are you trying to compile code from SVN? [21:33] <llogan> ffmpeg has been using git for a few years now at least [21:33] <Davym123> So how do I enable the xvid ? [21:34] <llogan> your version of ffmpeg is unsupported here [21:34] <Davym123> All the rest worked fine using the auto installer [21:34] <Davym123> Oh.. [21:35] <Davym123> So what the the recommended steps to fix this [21:35] <Davym123> are* [21:36] <llogan> 1. get recent ffmpeg via http://ffmpeg.org/download.html [21:36] <llogan> 2. mak sure /tmp does not have noexec [21:37] <llogan> your /tmp issue probably has nothing to do with ffmpeg [21:37] <Davym123> should I clean everything in my /tmp? [21:37] <llogan> no [21:38] <llogan> use pastebin.com or similar to show the output of: mount | grep noexec [21:38] <llogan> and also: ls -alh /tmp [21:39] <Davym123> http://pastebin.com/aJtefMuc [21:40] <Davym123> http://pastebin.com/Qk3vW3q7 [21:40] <llogan> your /tmp is mounted as noexec. why? [21:41] <Davym123> I don't really do stuff in my ssh [21:42] <llogan> what is your distro? [21:42] <Davym123> I had an indian installing security on my server though [21:42] <Davym123> distro? [21:42] <llogan> an indian? [21:42] <llogan> an indian from india, or a Native American? [21:42] <Davym123> India [21:43] <Davym123> Centos 5 btw [21:43] <Davym123> 6.5* [21:43] <Davym123> 6.4 [21:43] <Davym123> derp [21:43] <Davym123> CENTOS 6.4 x86_64 [21:44] <llogan> remount /tmp without noexec or set the TMPDIR environment vairable to another directory and make sure it is not mounted with noexec [21:45] <Davym123> Whoa [21:45] <Davym123> I guess I need to hire someone [21:45] <Davym123> :D [21:45] <clever> sudo mount /tmp -o remount,exec [21:45] <clever> this will force it to have the exec flag without loosing any data [21:45] <Davym123> done [21:45] <clever> then just try whatever failed in the first place [21:46] <Davym123> Well, installing Xvid codec [21:46] <llogan> but use ffmpeg from git, not that old, ancient, graybeard code from SVN [21:46] <Davym123> https://trac.ffmpeg.org/wiki/CentosCompilationGuide [21:46] <Davym123> use this? [21:46] <llogan> sure [21:47] <llogan> also, why do you want libxvid support? ffmpeg has a native mpeg-4 part2 video encoder. [21:47] <llogan> "-vcodec mpeg4" [21:47] <Davym123> It's for a php script that I found [21:47] <llogan> if you found some food on a sidewalk, would you eat it? [21:48] <Davym123> No [21:48] <Davym123> :D [21:48] <llogan> and who uses that format these days anyway? [21:49] <Davym123> The script, I'm not good at php coding so I can't change it [21:49] <Davym123> and the script is kinda good [21:56] <Davym123> Need to updatte my YASM [21:57] <Davym123> And I did, but still says i'm running older version, do I need to restart something, [21:57] <Davym123> ? [22:09] <llogan> Davym123: what is telling you that you are running an older version of what? [22:09] <Davym123> yasm [22:10] <Davym123> Found yasm 1.1.99.HEAD [22:10] <Davym123> Minimum version is yasm-1.2.0 [22:10] <llogan> then install a newer yasm [22:10] <llogan> and remove your old one [22:10] <Davym123> Well I followed the instructions but it's still saying that [22:10] <Davym123> Nvm, I'll find a way [22:10] <Davym123> Thanks ^^ [22:10] <llogan> it's probably detecting your old yasm first [22:11] <llogan> i guess [00:00] --- Tue Dec 31 2013

1 0

ffmpeg-devel.log.20131229
by burek 30 Dec '13

30 Dec '13

[01:05] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:8e90c7285d1c: avformat/iff: check avio_read() return in get_metadata() [02:28] <cone-703> ffmpeg.git 03Maxim Poliakovski 07master:2e1fb96af363: ATRAC+ decoder [02:28] <cone-703> ffmpeg.git 03Maxim Poliakovski 07master:54bb30bae2ec: omadec: Disable "Unsupported codec ATRAC3+" warning [03:35] <cone-703> ffmpeg.git 03Xidorn Quan 07master:344d6db978af: avcodec/vda_h264_dec: add format check [03:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:3477874abdd4: Merge branch 'master' of https://github.com/upsuper/ffmpeg-vdadec [03:35] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:fead24141af0: avcodec/vda_h264_dec: avoid declaring int in for arguments [11:41] <cone-251> ffmpeg.git 03Alexander Strasser 07release/1.2:dcd1acce1a69: configure: Special case libfreetype test [11:41] <cone-251> ffmpeg.git 03Alexander Strasser 07release/2.1:8c79730a8e2c: configure: Special case libfreetype test [11:44] <cone-251> ffmpeg.git 03Luca Barbato 07master:4d2bb289318c: h264: namespace the decode function [11:44] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:74a9c92840d3: Merge remote-tracking branch 'qatar/master' [12:43] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:5c74fa6ce020: avcodec/alsdec: skip cases where the master channel equals the current channel [13:02] <cone-251> ffmpeg.git 03Lukasz Marek 07master:ff8def21313a: configure: remove git url check [13:12] <cone-251> ffmpeg.git 03Timothy Gu 07master:eb38e684b4d5: doc/encoders: reformat libwavpack documentation [13:12] <cone-251> ffmpeg.git 03Timothy Gu 07master:f4c62b9f6405: doc/encoders: add wavpackenc doc [13:32] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:8a0d446ad618: avformat/siff: check avio_read() return value before returning packet [14:08] <ubitux> http://trac.ffmpeg.org/wiki/Debugging%20Macroblocks%20and%20Motion%20Vectors fun [14:08] <ubitux> some vismv info for j-b [14:08] <j-b> ah, nice! [14:09] <j-b> ubitux: in fact, --avcodec-vismv 7 works for VLC 2.1.2 but fails in trunk [14:09] <ubitux> vlc regression? or change in ffmpeg? [14:10] <j-b> compiled against the system ffmpeg, so I'd guess vlc issue [14:10] <j-b> but maybe it is related to the visible_width changes we had in our avcodec decoder [16:50] <cone-251> ffmpeg.git 03Marton Balint 07master:e98cd24a8905: ffplay: precalculate audio output frame size and byte per sec [16:50] <cone-251> ffmpeg.git 03Marton Balint 07master:e37d4920c104: ffplay: use precalculated frame size and bytes per sec values [16:50] <cone-251> ffmpeg.git 03Marton Balint 07master:379caaa77898: ffplay: remove unneeded avcodec_get_frame_defaults [16:50] <cone-251> ffmpeg.git 03Marton Balint 07master:e3ff6938b5d6: ffplay: remove some unneded av_frame_unref calls [16:50] <cone-251> ffmpeg.git 03Marton Balint 07master:e90aef9195d2: ffplay: remove two unneeded av_free_packet calls [16:50] <cone-251> ffmpeg.git 03Marton Balint 07master:ac7b4bfdeb6a: ffplay: do not wait for the picture allocation to finish on exit [16:50] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:1acd029f40de: avformat/wc3movie: Check strings before printing. [16:50] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:828ac6d1b515: Merge remote-tracking branch 'cus/stable' [19:01] <Daemon404> g 30 [20:43] <ubitux> no way with yasm to do inline macro with the same semantic as the multiline ones? [20:44] <ubitux> (aka no %define) [20:49] <ubitux> wow [20:49] <ubitux> it almost works at the first try [20:50] <ubitux> at least it passes a few tests, and doesn't look broken [20:50] <ubitux> BBB: first draft @ https://github.com/ubitux/FFmpeg/compare/vp9-lpf [20:50] <ubitux> now updated. [20:54] <ubitux> oups forgot again to push some stuff [20:57] <ubitux> and now, typo lookup... [21:01] <ubitux> ok sometimes quite some artifacts :P [21:13] <ubitux> btw, what happened to the hevc simd? [21:13] <nevcairiel> haven't heard from the guy for a while [21:18] <cone-251> ffmpeg.git 03Lukasz Marek 07master:247a8fa70f9d: lavf/libssh: fix file mode [21:19] <cone-251> ffmpeg.git 03Lukasz Marek 07master:8ba77dfbc2e0: lavf/libssh: improve authentication [21:19] <cone-251> ffmpeg.git 03Nicolas George 07master:fde219cfa8f6: lavd/xv: report if no adaptor present. [21:19] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:12fc0c89dc6b: Merge remote-tracking branch 'lukaszmluki/master' [21:19] <cone-251> ffmpeg.git 03Michael Niedermayer 07master:9ed640015bf3: Merge remote-tracking branch 'cigaes/master' [21:38] <BBB> ubitux: no [21:38] <BBB> ubitux: you're missing something obvious [21:38] <BBB> ubitux: any lf change will pass until like q-06 or so [21:38] <BBB> ubitux: because at that q, there is no lf :) [21:38] <BBB> (lf-level=0) [21:38] <BBB> ubitux: but anyway good luck debugging will look into it soon [21:38] <ubitux> i see :) [21:38] <ubitux> ok [22:09] <BBB> sorry I hope that wasn't discouraging, was just trying to be practical :/ [22:10] <ubitux> no it's fine :) [22:40] <smarter> ubitux: I think plepere is doing some refactoring of the hevc mv code before doing more simd [22:41] <ubitux> ok :p [22:44] <Daemon404> asm simd? [22:45] <nevcairiel> yes they are re-writing the intrinsic code to yasm, but some of the calling C code is not ideal for asm hooks in some cases [22:45] <nevcairiel> so they need to refactor that too [22:45] <Daemon404> fun [00:00] --- Mon Dec 30 2013

1 0

ffmpeg.log.20131229
by burek 30 Dec '13

30 Dec '13

[01:36] <nodie> hello [01:36] <nodie> someone in #mplayer told me that ffmpeg does not support files with multiple streams? [01:36] <nodie> I'm trying to reproduce a realplayer video file from the late 90's [01:36] <nodie> and, while it works with realplayer, no free player seems to be able to reproduce it [01:37] <nodie> the file is this [01:37] <nodie> ftp://ftp.aduni.org/videos/06_lect_01.rm [01:38] <nodie> could someone here, with more knowledge than I've, try to reproduce it and tell me what's wrong with it? [01:39] <jnvsor> He lied. Use the -map option for multiple streams. [01:41] <llogan> jnvsor: i think he means that ffmpeg is unable to decode any of the streams [01:41] <jnvsor> Ah [01:41] <llogan> nodie: does realplayer give any indication of the formats of the streams? [01:42] <nodie> llogan, I've been playing with GUI (horrible thing btw) and were not able to find where the heck is the format info [01:43] <jnvsor> The stream type has 5 hits on google. Total. Good luck, looks like that format's dead and buried. I'd just screengrab it if I were you. [01:43] <nodie> Unsupported codec with id 0 for input stream 0 [01:43] <nodie> Unsupported codec with id 0 for input stream 1 [01:44] <nodie> jnvsor, yeah I just want to know if it's a lost cause [01:44] <nodie> and it's better to just go to sleep instead :) [01:44] <jnvsor> "Unsupported stream type 4d4c5449" - 4d4c5449 has 5 hits on google. Lost cause. I'd play the video and screengrab it in your position [01:45] <llogan> 0:0 is probably audio (just guessing from the stream size), and 0:1 is the video [01:45] <nodie> oki doki [01:45] <llogan> filing a bug report could be useful [01:45] <nodie> btw, realplayer allows you to convert the video to "iphone/android format" (aka mp4/3gp) [01:46] <jnvsor> There is one - https://trac.ffmpeg.org/ticket/2152 [01:46] <jnvsor> Ah then do that [01:46] <nodie> and just extracts the audio, even Realplayer doesn't want to mess with the video [01:46] <jnvsor> Ew hah - screencast is the way to go then :) [01:46] <nodie> ook [01:47] <nodie> ok [01:47] <llogan> ah, yeah, searching for bug reports first is even more useful [01:47] <nodie> I didn't know that the "4d4c5449" was the codec id [01:47] <nodie> next time I will search for the id returned (if this thing ever happened to me again) [01:48] <jnvsor> Wierd thing is this format is so backwards it uses the same id for both audio and video streams (-_-) [01:48] <nodie> any suggestion on how to create a nice screencast? or just any screen cast software is good enough [01:48] <jnvsor> Are you on windows or linux? [01:48] <nodie> linux if possible [01:48] <llogan> http://ubuntuforums.org/showthread.php?p=8746719#post8746719 [01:48] <jnvsor> can you play the video on linux? [01:48] <nodie> yeap [01:48] <nodie> realplayer on wine ;) [01:48] <jnvsor> then let me build you a line [01:49] <jnvsor> know the framerate of the video btw? [01:49] <nodie> hey didn't know that you could use ffmpeg for screencasting :D [01:49] <nodie> jnvsor, nope [01:49] <nodie> but it's fine, with llogan link I've enough for starting [01:49] <jnvsor> I wrote a script to automate it [01:50] <nodie> is it in github or somewhere else? [01:50] <jnvsor> https://github.com/jnvsor/screencap [01:50] <nodie> many thanks, you have helped me a lot :) [01:51] <nodie> now I can got to sleep [01:51] <nodie> bye! [01:51] <jnvsor> `screencap --mute -i window out.avi` will get you the realplayer video, then use it's built in audio converting [01:51] <nodie> cheers jnvsor [01:53] <llogan> jnvsor: heh. "Avconv has several bugs including incomplete x11grab support" [01:54] <jnvsor> Yeah, best you can do for screencasting on avconv is `-r` but then you get av desync so that's no use :) [01:55] <llogan> so you're using -framerate instead? [01:55] <jnvsor> Yep [01:55] <jnvsor> It's in avconv, it just doesn't work xD [01:55] <llogan> that's YAAB [01:55] <llogan> yet another avconv bug [01:56] <jnvsor> I googled it before you said that and was confused :P [01:57] <llogan> i wonder if -s and -video_size are the same? i didn't look into it. [01:59] <llogan> do you want screencap on http://ffmpeg.org/projects.html ? [01:59] <jnvsor> Huh, don't know if it's big enough for that :) [02:00] <jnvsor> I mean it works great but it's not a big accomplishment xD [02:01] <jnvsor> But yeah I'd guess -video_size is implemented inside x11grab device and -s is outside [02:02] <jnvsor> For size I doubt there's any practical difference, but with framerate it can cause issues [02:03] <llogan> as in ticket 3045 [02:03] <jnvsor> Yep [02:05] <jnvsor> Easy way to demonstrate the difference is to sigstop ffmpeg while recording [02:05] <jnvsor> with `-r` the video will skip the time it was paused, with `-framerate` it will freeze but won't skip the time [02:05] <llogan> i see [05:15] <b1oodline> i noticed seeking is slower on .flv than .mp4, is this normal [05:15] <klaxa> are the same streams in the files? [05:16] <b1oodline> what do you mean [05:17] <klaxa> are both files the same video or different ones? [05:18] <b1oodline> different [05:18] <klaxa> maybe one file has a higher bitrate in that case you can't pin it down on the container [05:20] <b1oodline> no that's not it [05:21] <klaxa> streamcopy an flv to mp4 (ffmpeg -i file.flv -c copy file.mp4) and then benchmark [05:22] <b1oodline> it's faster [05:24] <klaxa> then it's normal [05:25] <klaxa> and flv is a bad container and you should not use it :) [05:25] <klaxa> or use it, it doesn't really matter [05:25] <b1oodline> how is it bad [05:25] <klaxa> it's slower in seeking, isn't it? [05:26] <klaxa> it's also weirdly restricted [05:26] <b1oodline> yes [05:26] <b1oodline> how so [05:26] <klaxa> audio has to be 44.1khz [05:26] <b1oodline> wow, really [05:26] <b1oodline> it cannot be 48khz? [05:26] <klaxa> nope [05:27] <klaxa> ran into that quite some times [05:27] <b1oodline> i am looking at 32khz flv right now [05:27] <klaxa> hmm... [05:27] <klaxa> let me do a quick check, last time at least it didn't support 48khz [05:28] <klaxa> hmm... it does it now... [05:28] <klaxa> maybe i'm mistaken [05:30] <b1oodline> hmm flv support sorenson video but mp4 does not [05:30] <klaxa> maybe it was only for mp3 audio? [05:30] <klaxa> >[flv @ 0x2188380] FLV does not support sample rate 48000, choose from (44100, 22050, 11025) [05:30] <klaxa> in general as a container i think matroska is the one mostly recommended [05:31] <klaxa> because it's so versatile and sophisticated [05:31] <b1oodline> but mkv has one really strange bug [05:31] <klaxa> oh? which one? [05:31] <b1oodline> mkv with aac does not show bitrate of aac audio [05:31] <b1oodline> mkv with mp3/ac3 shows fine [05:32] <b1oodline> and mp4 with aac shows fine too [05:32] <b1oodline> i never understood that [05:32] <klaxa> you are right [05:33] <klaxa> maybe that was just overlooked during development? [05:33] <klaxa> i doubt it's a matroska bug, but rather an unimplemented feature in ffmpeg [05:33] <b1oodline> only aac + mkv combination has that problem [05:33] <klaxa> maybe file a bugreport? [05:34] <b1oodline> to who [05:34] <klaxa> http://trac.ffmpeg.org/ [05:34] <b1oodline> how can such a known issue go undetected for a long time [05:34] <klaxa> wait.. [05:34] <klaxa> what the... [05:35] <b1oodline> mkv with mp3/ac3/vorbis shows fine [05:35] <klaxa> mediainfo and mkvinfo don't show aac bitrates in mkv either [05:35] <klaxa> mediainfo shows bitrate in mp4 though [05:35] <b1oodline> exactly [05:36] <klaxa> that's weird [05:36] <b1oodline> check for mp3/ac3/vorbis mkv, it will show fine [05:36] <b1oodline> so whose fault is this? [05:36] <b1oodline> aac or mkv or ffmpeg [05:37] <klaxa> apparently matroska [05:38] <klaxa> i think i noticed that too once, but never bothered [05:47] <b1oodline> i talked to people in matroska and they don't think this is mkv bug [07:26] <Voting> OK, I'm an idiot... never used ffmpeg... I want to crunch down some tech videos so I can watch them on my phone (android) using h264 at a pretty high res but low bit rate and I want to jack up the audio volume so I can hear the stuff over the subway. Can someone right out the command line for me? Tx!!! [10:24] <Zeranoe> To use inverse telecine in FFmpeg, how could I find the frame types for the top and bottom fields? Basically, how could I find the correct settings for my media to use in this example http://ffmpeg.org/ffmpeg-filters.html#Examples-8 [10:44] <Guest74627> hi ! ... excuse me ... is possible to generate images from canvas json object in server side ? [13:54] <calcifea> how to run commands like 'x264 --fullhelp' that on the wiki? [13:58] <saste> you type "x264 --fullhelp" in a terminal and press return [14:13] <calcifea> it doesn't exist saste :) [16:24] <edocod> Hi everyone! I'm trying to encode some videos for uploading to Youtube. I have a very powerful pc but a slow connection. What are the best settings to encode? [16:24] <edocod> I'd like to encode in h264, 720p widescreen [16:25] <edocod> using the more cpu/gpu i can, to have a small file but high quality [16:28] <edocod> Reposting question for the just logged users [16:28] <edocod> Hi everyone! I'm trying to encode some videos for uploading to Youtube. I have a very powerful pc but a slow connection. What are the best settings to encode? [16:28] <edocod> I'd like to encode in h264, 720p widescreen [16:28] <edocod> using the more cpu/gpu i can, to have a small file but high quality [16:28] <klaxa> i'm no expert, but use x264 with preset veryslow and crf maybe 21 or 22 since youtube messes with that anyway [16:29] <klaxa> that's what i would do at least, also encoding on gpu is not very sophisticated yet i think [16:29] <edocod> thanks klaxa [16:29] <edocod> i'll encode on cpu then, i have enough power [16:31] <edocod> klaxa, also, what about qt-faststart? can i move meta files at the start of the file directly with ffmpeg? [16:31] <klaxa> no idea, never done that, sorry [16:32] <edocod> klaxa, encoding right now, thanks for everything [16:36] <saste> edocod, yes, see the -faststart option of the mp4/mov muxer [16:37] <edocod> saste, Unrecognized option 'faststart' [16:37] <JEEB> -movflags faststart [16:37] <JEEB> IIRC [16:38] <edocod> perfect! :D [16:39] <edocod> i'm using [16:39] <edocod> avconv -i input.mp4 -c:v libx264 -preset veryslow -crf 21 -movflags faststart -tune animation -c:a copy -pix_fmt yuv420p output.mp4 [16:39] <edocod> and i get Could not write header for output file #0 (incorrect codec parameters ?) [16:39] <edocod> what am i doing wrong? [16:39] <JEEB> see what's before that [16:39] <edocod> [mp4 muxer @ 0x388f8c0] [Eval @ 0x7fff42c655f0] Undefined constant or missing '(' in 'faststart' [16:39] <edocod> [mp4 muxer @ 0x388f8c0] Unable to parse option value "faststart" [16:39] <edocod> [mp4 muxer @ 0x388f8c0] Error setting option movflags to value faststart. [16:40] <JEEB> ok, so you don't have that option :) [16:40] <edocod> ok, i will use qt-faststart post encoding then [16:40] <JEEB> <klaxa> that's what i would do at least, also encoding on gpu is not very sophisticated yet i think <- GPUs as such will never become useful for general purpose encoding, which is why everyone and their dog are putting ASICs on their hardware instead [16:41] <edocod> IMHO gpu conversion could be interesting if you want to do multiple streams [16:41] <edocod> like youtube does [16:42] <JEEB> no [16:42] <edocod> if you want to convert 1080p, 720p, 480p, 360p and 240p at the same time i don't think you can with a cpu [16:42] <JEEB> GPUs are only useful for stuff where they're good at [16:42] <edocod> games? [16:42] <edocod> 3d rendering? [16:42] <klaxa> floating point math [16:42] <klaxa> hrhr [16:42] <JEEB> think about stuff where you can throw thousands of threads that don't depend on each other onto the driver [16:42] <JEEB> general purpose video encoding is not like this :) [16:43] <JEEB> and yes, floating point math, although lately some GPUs have become better with integers [16:43] <edocod> what numbers do you need to encode? [16:44] <JEEB> most general purpose formats are bit exact so integer-based [16:44] <JEEB> and even more important is the fact that the whole process is intertwined [16:44] <edocod> wow 20mb for 1minute of video @ 720p [16:45] <saste> in general we only support ffmpeg here [16:45] <saste> i don't think avconv supports that option [16:45] <JEEB> basically when you calculate a lot and lot of hashes you don't care if the other thread has finished already or not [16:45] <edocod> isn't ffmpeg == avconv? [16:45] <JEEB> they aren't related to each other [16:46] <JEEB> a fork of ffmpeg (project) rewrote parts of ffmpeg (app) and called it avconv [16:46] <JEEB> libav at the moment only has avconv, and ffmpeg only has ffmpeg [16:46] <JEEB> they're similar but not exactly the same [16:46] <edocod> so, apt-get remove avconv [16:46] <edocod> apt-get install ffmpeg? [16:46] <JEEB> not really, your distro uses libav [16:46] <JEEB> so you're better off using avconv [16:46] <JEEB> than the old ffmpeg that you might still have there [16:46] <saste> edocod, follow the link, it will clarify [16:47] <JEEB> because libav left the old ffmpeg binary to wither for a while [16:47] <JEEB> without the changes [16:49] <edocod> ok i read all the link [16:49] <edocod> interesting, but that message is only confusing :\ [16:49] <JEEB> it only means that ffmpeg (binary) shouldn't be used within the libav project [16:49] <JEEB> and it was then subsequently removed with the next libav release after 0.8 [16:50] <edocod> yeah, but at a first glance i thought ffmpeg was dead, and someone made a fork of it to not discontinue the project [16:50] <JEEB> yeah, I don't disagree that the message could be better worded [16:52] <edocod> Thank you for all the help, now i can upload videos in HD :D [16:52] <edocod> 130mb to 25mb is a big difference to me [16:52] <JEEB> do note that since youtube will re-encode your stuff no matter what, you will want to upload the best stuff you can there [16:52] <JEEB> (and youtube does at times re-encode things with newer settings/whatever) [16:52] <JEEB> so lossless is best [16:52] <JEEB> if you can't handle lossless x264, then lossy of course :/ [16:53] <edocod> i'll try to convert with lossless, if the file size is still manageable i will convert with that [16:55] <saste> edocod, also see: https://trac.ffmpeg.org/wiki/EncodeforYouTube [16:55] <edocod> oh god, with lossless i get a higher size than the input file [16:55] <edocod> saste, i'm editing the first command [16:55] <JEEB> lossless is -crf 0 with libx264 basically [16:55] <edocod> ffmpeg -i input.mp4 -c:v libx264 -preset veryslow -crf 0 -tune animation -c:a copy -pix_fmt yuv420p outputlossless.mp4 [16:55] <JEEB> you can remove the tune with lossless :) [16:56] <JEEB> and yes, if your input wasn't lossless then you most probably are not gonna get a better file size from lossless [16:56] <edocod> the input is a mp4 file from kdenlive [16:56] <edocod> bitrate 8000 [16:56] <edocod> h264 [16:56] <JEEB> yeah [16:57] <edocod> i'll encode from avi to mp4 in the future, i'm just testing now [16:57] <JEEB> lossy - > lossless in general won't become smaller unless you've got some really simple stuff [16:57] <edocod> i have animations [16:58] <edocod> 32 animations, so many colors and shadows [16:58] <edocod> *3d [17:00] <DelphiWorld> hi all [17:01] <edocod> hi! [17:01] <DelphiWorld> hi saste ! [17:01] <DelphiWorld> Hey edocod [17:02] <edocod> hi DelphiWorld [17:04] <DelphiWorld> what's the best codec? aac or aacplus? [17:04] <edocod> x264 now supports OpenCL encoding acceleration. How much acceleration you get will depend on your graphics card's performance, on my GTS 450 I get none and with slower cards it actually slows down encoding. Better cards may help. All you need to do is add --opencl to the x264 command line. I believe handbrake makes use of the same x264 libraries and does offer the same OpenCL acceleration in newer builds. [17:04] <edocod> what's this? [17:07] <JEEB> DelphiWorld, if you mean 'the best encoder for AAC that I can use via ffmpeg' that would fdk-aac [17:07] <JEEB> edocod, it's ME lookahead [17:07] <DelphiWorld> JEEB: no no, i mean the diference bethwan AAC and AAC+ [17:07] <JEEB> you mean HE-AAC and friends most probably [17:08] <JEEB> the stuff that you get from HE-AAC and friends are meant to make low bit rate stuff sound better, but most definitely are not for actually keeping quality [17:08] <JEEB> so if you are using enough bit rate that the encoder uses LC-AAC, you probably want to use it [17:08] <JEEB> if you are using low enough bit rates you probably want HE-AAC or HE-AACv2 [17:09] <Mavrik> "low enough" being < 96kbps or so :) [17:09] <DelphiWorld> lol JEEB [17:09] <Plorkyeran> AAC+ is HE-AAC [17:09] <DelphiWorld> JEEB: do you know libaacplus [17:09] <JEEB> DelphiWorld, yes -- and it's a HE-AAC(v2) implementation [17:09] <DelphiWorld> then why there is libaacplus if libfdk_aac support it? [17:09] <edocod> ok, youtube just decided to mess my video [17:09] <JEEB> because someone took the reference code for HE-AAC(v2)? [17:09] <JEEB> and decided to implement an API for it? [17:09] <DelphiWorld> lol [17:10] <JEEB> do people really need reasons for their actions? [17:10] <DelphiWorld> JEEB: multi lib confuse me, that's all [17:10] <DelphiWorld> anyway see JEEB what i'm trying to do [17:10] <JEEB> anyways, it used to be the only thing capable of HE-AAC(v2) [17:10] <JEEB> now fdk-aac can do both LC and HE [17:10] <DelphiWorld> what i want to do. [17:10] <DelphiWorld> 1. fetch a RTMP stream from a RTMP Server. [17:10] <JEEB> and fdk-aac is not based on reference code so it is of better quality [17:10] <edocod> damn how it looks bad O_O [17:11] <DelphiWorld> 2. transcode it to AAC (removing the VIDEO *H.264*) [17:11] <JEEB> (or well, I lied -- it _is_ based on reference code, but so are most other things too. The fact is that it will give you a better result :P ) [17:11] <DelphiWorld> 3. push it to another RTMP Server, and fetching it out using hls from the same server [17:11] <DelphiWorld> :P [17:11] <DelphiWorld> so [17:11] <DelphiWorld> the current issue is: [17:11] <DelphiWorld> all all all working pretty well and neat and stable [17:12] <DelphiWorld> except of the -vn is not removing my video, i still see H.264 stream using ffprobe [17:12] <DelphiWorld> anyone know how to completly remove the video stream? [17:12] <JEEB> -map 0:a ? Where zero is the input number [17:12] <JEEB> that should only map the audio from that intput [17:13] <DelphiWorld> let me ffprobe [17:13] <JEEB> also you should see the log that ffmpeg gives [17:13] <JEEB> if you are not outputting H.264 but you are seeing H.264 from somewhere else then that something else is either adding it or doing something else weird with metadata :P [17:15] <DelphiWorld> JEEB: here's my cmdline: [17:15] <DelphiWorld> nohup ffmpeg -re -i rtmp://radio.gmo.ps/live/livestream -vn -c:a libfdk_aac -profile:a aac_he_v2 -b:a 64k -ac 2-f flv rtmp://172.16.10.100:1935/myapp/alray & [17:16] <saste> the command seems correct to me [17:18] <DelphiWorld> saste: and h264 still exist [17:19] <DelphiWorld> and with this: ffmpeg died [17:19] <DelphiWorld> nohup ffmpeg -re -i rtmp://radio.gmo.ps/live/livestream -vn -c:a libfdk_aac -profile:a aac_he_v2 -b:a 64k -ac 2 -map 1:a -f flv rtmp://172.16.10.100:1935/myapp/alray & [17:19] <JEEB> you only have one input [17:19] <JEEB> it begins from 0 [17:19] <DelphiWorld> JEEB: isnt stream 1 is audio in my case? [17:20] <DelphiWorld> mmmmmmmmmmmmm [17:20] <DelphiWorld> i think i understand now [17:20] <JEEB> -map INPUT:STREAM [17:20] <JEEB> or stream type [17:20] <JEEB> you could of course do -map 0:a:0 [17:20] <JEEB> that would only map the first of first input's audio tracks [17:20] <JEEB> IIRC [17:20] <DelphiWorld> in rtmp, am i obligated to use flv? no other container like mpeg4? [17:21] <saste> DelphiWorld, don't think so [17:21] <saste> but your map looks wrong [17:21] <DelphiWorld> -f mp4 will be mpeg4, right? [17:21] <saste> post a pastebin [17:24] <JEEB> rtmp is flv [17:25] <DelphiWorld> saste, pastebin: (Original Stream: http://paste.debian.net/73044/ ) [17:27] <matthias_> hi, how can i record only ingame sound with ffmpeg? I am runnign ArchLinux 64-bit. [17:28] <klaxa> what audio... stuff are you using? [17:28] <klaxa> alsa, pulse, jack? [17:28] <saste> DelphiWorld, the *ffmpeg* command&output [17:28] <klaxa> with pulse it's easy and i know how, the rest is... uhhh [17:28] <klaxa> dunno [17:30] <DelphiWorld> saste, ffmpeg output: http://paste.debian.net/73046/ [17:33] <saste> Stream #0:1 -> #0:0 (mp3 -> libfdk_aac) [17:33] <saste> looks correct [17:34] <DelphiWorld> yes, but if i do ffprobe on my stream, i still see a h264 stream [17:34] <JEEB> that's not ffmpeg's doing then :P [17:34] <JEEB> unless ffmpeg tells you you're outputting video [17:35] <JEEB> and yeah, ffmpeg is only muxing aac :P [17:35] <DelphiWorld> JEEB: lol... then my server is mad? [17:35] <DelphiWorld> JEEB: ok, i'm going to be mad too... wait a sec [17:35] <JEEB> I have no idea if it's mad or trying to do something in a simple way (always note a video track possible) [17:36] <JEEB> but in any case, it's not ffmpeg [17:37] <DelphiWorld> Ok guys, its my server [17:37] <DelphiWorld> JEEB: ffmpeg -re -i rtmp://radio.gmo.ps/live/livestream -vn -c:a libfdk_aac -profile:a aac_he_v2 -b:a 64k -ac 2 -map 0:a -f flv /dev/shm/test.flv [17:37] <DelphiWorld> this one output only audio to the file... my server is so mad:P [17:40] <saste> DelphiWorld, what (RTMP?) server are you using? [17:40] <DelphiWorld> saste: nginx rtmp module [17:40] <DelphiWorld> no other reliable open source one exist... [17:40] <saste> is red5 since the royal PITA it was a few years ago? [17:40] <saste> *still [17:41] <DelphiWorld> soryyyyyyyyyyyyyyy, kill java. [17:46] <matthias_> klaxa: i have pulse over alsa and i want to record ingame sound from for example minecraft or l4d2 [17:46] <matthias_> klaxa: could you explain me how please? [17:47] <klaxa> do you have anything else running that produces sound while playing? [17:47] <klaxa> or could there be something that produces sound during gameplay? like instant messaging? [17:48] <klaxa> you can isolate the game-sound or just record the monitor of your output [17:48] <matthias_> klaxa: yes, i have a skype call while playing coop games for example [17:48] <matthias_> klaxa: my mic and skype output [17:48] <klaxa> in that case you need a loopback module to isolate the game-sound [17:48] <klaxa> i'm not too sure about latency now that i think abou tit [17:48] <klaxa> *about it [17:48] Action: DelphiWorld express vm to saste [17:49] <klaxa> let me try to draw what you will do [17:49] <matthias_> klaxa: will i have to create this loopback module for every game or only once? [17:49] <matthias_> klaxa: yes drawing is always good :D [17:49] <klaxa> you will have to set that up every time you want to record something [17:50] <matthias_> klaxa: ok, but maybe i can put it into my recording script [17:50] <klaxa> oh definitly scriptable [17:52] <matthias_> klaxa: if your painting is ready, can you show me how to create this modules please? [17:53] <klaxa> http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modu… read null and loopback modules [17:55] <matthias_> klaxa: i also have the pavucontrol, but won't be needed if i will do it by a script [17:56] <matthias_> klaxa: i read null module and loopback module [18:00] <klaxa> matthias_: http://klaxa.eu/record%20game%20audio.svg [18:01] <matthias_> klaxa: i understand... [18:02] <klaxa> you can do all that with pavucontrol [18:02] <klaxa> except the module loading [18:02] <klaxa> once you figured it out and got it working with pavucontrol, you can script it [18:02] <klaxa> like i said, i'm not too sure about audio delay with the loopback module [18:03] <matthias_> klaxa: we can check and see if it is noticeable [18:06] <matthias_> klaxa: correct me pls if i am wrong. i did pacmd and then list-sink-inputs [18:06] <matthias_> klaxa: then i search the input index [18:08] <klaxa> sounds about right [18:08] <matthias_> klaxa: so minecraft/java has index number 3 [18:08] <klaxa> mmmhh i wouldn't bet on that [18:08] <klaxa> right now it has, but those numbers are dynamic [18:08] <matthias_> klaxa: but they will only change if i restart? [18:09] <matthias_> klaxa: or from time to time? [18:09] <klaxa> yeah if the audio stream is established it keeps its index [18:09] <klaxa> but if you quit minecraft and like... start a mediaplayer and then start minecraft again the index might be different already [18:10] <matthias_> klaxa: yes i understand [18:10] <matthias_> klaxa: after that create the null-sink with name game: pactl load-module module-null-sink sink_name=game [18:11] <matthias_> klaxa: will the sink be deleted if the index changes or when? [18:11] <klaxa> oh i've never looked that far into it [18:11] <klaxa> what i did was way uglier with grep and sed [18:11] <klaxa> just read help pages and test :) [18:14] <matthias_> klaxa: if i do pactl move-sink-input 3 game i get bad parameter [18:17] <klaxa> matthias_, sorry no idea, that should be correct :/ [18:19] <matthias_> klaxa: have you got a working example for me, because i am a little confused [18:21] <klaxa> well this is what i do to record the monitor of my output and an external usb soundcard: https://gist.github.com/klaxa/8172532 [18:32] <matthias_> klaxa: how do i get my source in set-default-source? [18:32] <matthias_> klaxa: when i do pacmd set-default-source alsa_output.pci-0000_00_1b.0.analog-stereo it says source does not exist [18:36] <matthias_> klaxa: ok the sound is now redirected into the null sink, but i can't hear it [18:50] <PowerCC> hey JEEB [18:56] <PowerCC> my hardware is only happy with -vb 5000k I have tried every combo. [18:57] <matthias_> klaxa: i want to hear the ingame sound [19:00] <klaxa> that's what the loopback module is there for [19:00] <JEEB> PowerCC, what are its official limitations in specs? [19:00] <matthias_> klaxa: i created one, but nothing [19:00] <JEEB> also what kind of media are you reading the stream off of? [19:00] <klaxa> did you set the correct sources and sinks? [19:00] <klaxa> souce is the game, sink is your default output [19:00] <JEEB> also, for control of bit rate you should use VBV [19:00] <JEEB> which is -maxrate and -bufsize [19:00] <JEEB> because -b:v/vb only sets the average rate over the WHOLE video [19:00] <JEEB> which really doesn't help if the spikes are the problem [19:00] <matthias_> klaxa: maybe i have a wrong source, how can i get the name of the gamesource? [19:00] <PowerCC> the minute the rate goes below 5000k the tivo won't play. [19:01] <PowerCC> it's possible due to a really old project being used (stream baby) [19:01] <klaxa> in pavucontrol you can select the sink of the game in the applications tab [19:01] <klaxa> the monitor of that sink is your source for the loopback module [19:01] <PowerCC> so it's possible this is more of a software limit vs hardware [19:01] <JEEB> what... how would the minimum rate have anything to do with it o_O [19:02] <PowerCC> JEEB: so -vbv 5000k -maxrate 5000k and -bufsize ? [19:02] <JEEB> no, maxrate and bufsize control the bit rate, so it keeps within the set limitations [19:02] <JEEB> those are VBV settings [19:03] <PowerCC> i see [19:03] <JEEB> but you should really set the limits accordingly to your hardware's specifications [19:03] <JEEB> and/or the limitations of your media [19:03] <PowerCC> -vb 5000k has worked flawleslly [19:03] <JEEB> be it network or discs or whatever [19:03] <JEEB> that doesn't make sense! [19:03] <PowerCC> -vbv will take more space? [19:03] <PowerCC> i agree... that's why i am here ;) [19:03] <JEEB> -vbv is not an option, maxrate and bufsize are VBV settings! [19:04] <JEEB> they are called vbv-maxrate and vbv-bufsize in x264, ffmpeg calls them -maxrate and -bufsize [19:04] <PowerCC> JEEB: this might give you an idea: https://code.google.com/p/streambaby/wiki/video_compatibility [19:04] <JEEB> anyways, now please tell me if the difference between working/non-working is ONLY the overall average bit rate set versus CRF rate control? [19:04] <PowerCC> however it used to work with older ffmpeg [19:05] <PowerCC> default CRF or any other CRF settings do not work AT ALL [19:05] <JEEB> goddamnit [19:06] <JEEB> answer my question [19:06] <JEEB> also no, that page tells you absolutely nothing [19:07] <PowerCC> working = average nitrate must be 5000k [19:07] <JEEB> NO [19:07] <JEEB> also answer my goddamn question already [19:07] <PowerCC> CRF rate control did not work for me [19:07] <PowerCC> not even if i got close to 5000k avg. [19:08] <JEEB> don't fucking squeal around, answer the goddamn question [19:08] <PowerCC> not sure what your asking... [19:08] <JEEB> was the only difference between working and non-working the rate control set? [19:08] <PowerCC> YES [19:08] <JEEB> thank you [19:08] <JEEB> now post both command lines [19:08] Action: PowerCC sending JEEB coffee! [19:09] <JEEB> now, your general note seems to be rather false at least according to "NOTE: In the above you can adjust video bit rate (-b 5000k) to be higher or lower depending on quality desired, for example using -b 2000k for SD sources." On the other hand, it might be a VBV violation or whatever, CRF is after all free'er to do random stuff with the rate without any limitations. [19:09] <PowerCC> ok first command just defaults ffmpeg -i -c:a copy -c:v libx264 [19:10] <matthias_> klaxa: my sink input index is 95 and the module null sink index is 7. why is pacmd move-sink-input 95 7 [19:10] <matthias_> klaxa: failing? [19:10] <PowerCC> so i also tried -crf 20 and 18 [19:10] <PowerCC> i tried -vb 4500k no go [19:11] <PowerCC> only -vb 5000k with the defaults commands... ffmpeg -i c:a copy c:v libx264 -vb 5000k [19:11] <JEEB> is this all with the same input file? [19:11] <PowerCC> yes [19:11] <PowerCC> but i have tried others [19:11] <JEEB> anyways, what kind of output are you doing? [19:12] <PowerCC> it's movies [19:12] <PowerCC> 720p mostly. [19:12] <JEEB> file format... [19:12] <JEEB> container [19:12] <JEEB> :V [19:12] <PowerCC> .mp4 [19:12] <JEEB> ok [19:12] <JEEB> that article notes that you will want to have the index in the beginning, so you will want to have -movflags faststart [19:13] <JEEB> (although if it actually worked already it sounds like bullshit, but still) [19:14] <PowerCC> i included the flags no go [19:14] <JEEB> anyways, you should really find out proper specs for the decoder :P [19:14] <JEEB> to know what VBV parameters you need [19:14] <PowerCC> it's a waste of space, but i'd live with it... just wanted to know why but then again it's all software/hardware crap [19:15] <PowerCC> it's a broadcom decoder... let me look for it. [19:15] <PowerCC> -copyts did not help either (timestamp) [19:16] <JEEB> stop throwing random stuff on the wall [19:16] <PowerCC> it's based on that silly page [19:16] <JEEB> forget about it [19:17] <JEEB> heck, it uses bit rate rate control and sets sameq at the same time (latter is not what you think it might mean) [19:17] <PowerCC> i will tell you this, if i manually transfer the videos to my tivo's hdd anything i throw at it but .avi (xvid) playback perfectly. [19:17] <JEEB> it's completely obvious that it was written by people who have absolutely no idea about things [19:17] <PowerCC> so i strongly believe it's the stream baby HME app that's screwing it up and wanting 5000k [19:17] <PowerCC> eggs-actly! [19:18] <PowerCC> so the page i sent you was written by the same java lover app [19:18] <PowerCC> the pytivo project ALOT more mature and will actually use ffmpeg to transcode only the audio to ac3 and -copy vid from .mkv and such [19:19] <PowerCC> however it requires the content to be copied, stream baby uses my tivo 30 minutes pause buffer [19:19] <PowerCC> yuck, think i just put salt in my coffee [19:19] <PowerCC> also it's near miracle it's even working my my Mac with Java completely abandon. [19:20] <matthias_> klaxa: i can move my firefox youtube, but not my minecraft, why? [19:20] <PowerCC> the weird thing it's not picky about picture size [19:20] <PowerCC> just odd [19:20] <JEEB> anyways, 1) I can have no idea about what the hell the custom software layer is doing and 2) all you generally should care about are levels and VBV [19:21] <JEEB> in other words, refs and VBV [19:21] <JEEB> find actual information, apply actual thought, handle it [19:21] <matthias_> klaxa: the two i can move have s16le 2ch 44100Hz but minecraft has float32le 2ch 44100Hz [19:21] <JEEB> :V [19:21] <PowerCC> defaults refs is 3 [19:22] <JEEB> that depends on the preset if it's x264's default that you mean [19:22] <PowerCC> well 9 and 4 is for 720p and 1080p respectively [19:23] <JEEB> so basically you have to calculate the maximum amount of usable refs from the resolution (amount of macroblocks) and the level you are trying to abide to [19:23] <PowerCC> both work as long as stupid bitrate is 5000k [19:23] <JEEB> the resolution should have nothing to do with what x264 selects [19:23] <PowerCC> specs, the maximum refs for 720p and 1080p video are 9 and 4 respectively. [19:23] <PowerCC> if adhering to 4.1 [19:24] <JEEB> ok, so you were talking about that [19:24] <JEEB> yup [19:24] <JEEB> so just make sure that calculation was correct, and limit the refs to those values when encoding [19:24] <PowerCC> going to try -vbv 5000k [19:24] <PowerCC> instead of -vb [19:25] <JEEB> <JEEB> -vbv is not an option, maxrate and bufsize are VBV settings! [19:25] <JEEB> <JEEB> they are called vbv-maxrate and vbv-bufsize in x264, ffmpeg calls them -maxrate and -bufsize [19:27] <PowerCC> -vb 5000k -maxrate 5000k -minrate 2000k -bf 2 -bufsize 1835008 foobar.mp4 [19:27] <PowerCC> like that [19:27] <JEEB> don't set minrate [19:27] <JEEB> seriously [19:28] <PowerCC> oh [19:28] <JEEB> maxrate and bufsize [19:28] <JEEB> bf shouldn't matter [19:28] <PowerCC> i'll take bf out [19:28] <PowerCC> lets see [19:28] <JEEB> also your stuff still hurts my eyes so please go find out where the weird bandwidth limitations come from [19:28] <JEEB> and please don't just put random VBV variables in [19:29] <PowerCC> you referring to stream baby reference page? ;) [19:29] <JEEB> I'm not referring to anything [19:29] <PowerCC> does my -bufsize calculation ok? [19:30] <JEEB> those are random numbers as far as I can see [19:30] <JEEB> both for maxrate and bufsize [19:30] <JEEB> I'm not being a dick, I'm just saying that you should find correct things to base your settings on top of instead of random slapping of things on the wall and hoping something sticks [19:31] <PowerCC> what's a good bufsize for 720p source? [19:31] <JEEB> and if the weird bandwidth limitations or whatever are coming from the third party app, you should start poking it -- or seeing if there's an alternative [19:32] <JEEB> there is no "good VBV variable", except maybe for level limitations. So far your values are based on random stuff and I'd like you to instead actually learn the actual limitations [19:32] <JEEB> even if it means to read the source code of the third party applications or whatever [19:33] <PowerCC> ok, i thought my needs were very basic - it's starting to hurt my head. [19:33] <PowerCC> was trying to avoid handbrake [19:34] <JEEB> well basically you have some unknown variables there and instead of just setting something random and hoping it works it'd be better to actually find the limitations and if they can be modified if it's a software thing [19:34] <PowerCC> i'd be a happy man if this freaking tivo/streambaby would simply play default -crf values [19:34] <PowerCC> i don't need anything fency. [19:35] <JEEB> well at the very least you have to abide to the levels [19:35] <JEEB> with VBV and refs [19:35] <JEEB> and then possible extra limitations of the decoder chip, if such exist [19:35] <PowerCC> by setting a -maxrate 5000k it will actually not use 5000k throughout the video, right? [19:35] <JEEB> PLUS whatever limitations the software you're using might be imposing [19:35] <JEEB> maxrate and bufsize work as a combination, not by themselves [19:35] <PowerCC> ok, i'll have to use my random value then. [19:35] <PowerCC> testing now... [19:36] <JEEB> basically, it will never go over average rate of maxrate over bufsize [19:36] <PowerCC> it sure putting a toll on the processing time [19:36] <JEEB> it shouldn't :P [19:36] <PowerCC> i was getting 70+ fps now only 40 [19:36] <JEEB> then there's something else doing things around [19:37] <JEEB> VBV itself shouldn't slow stuff down like that [19:37] <PowerCC> my random bufsize probably not helping [19:37] <JEEB> anyways, if you want to set some random VBV limitations, use the level's :| [19:37] <JEEB> after all, the specification contains it all [19:37] <PowerCC> ffmpeg spit out Use -pix_fmt yuv420p for compatibility with outdated media players. [19:38] <JEEB> ok, so that's the reason why it's going slower [19:38] <JEEB> you're encoding non-4:2:0 content now [19:38] <PowerCC> i c [19:38] <PowerCC> and this [19:38] <PowerCC> [mp4 @ 0x102800000] track 1: codec frame size is not set [19:38] <JEEB> -pix_fmt yuv420p on the encoding settings' side will make ffmpeg convert the stuff into 4:2:0 [19:38] <JEEB> I have no idea about that :P [19:38] <PowerCC> ha [19:39] <JEEB> also just single lines don't really help [19:39] <PowerCC> the funny thing is the video played back just fine on tivo now [19:39] <PowerCC> i am just puzzled with this streamBaby [19:39] <PowerCC> vid is around 4400k [19:40] <JEEB> have fun looking how it's built and what it's based on :P [19:40] <PowerCC> yeah [19:40] <JEEB> that's your Last Boss :P [19:40] <PowerCC> i agree [19:40] <Zeranoe> To use inverse telecine in FFmpeg, how could I find the frame types for the top and bottom fields? Basically, how could I find the correct settings for my media to use in this example http://ffmpeg.org/ffmpeg-filters.html#Examples-8 [19:40] <PowerCC> at least you recommendation is saving me a few megabytes here and htere [19:40] <PowerCC> thanks [19:41] <JEEB> Zeranoe, I think it could grab the order automagically with another setting? [19:41] <JEEB> otherwise it seems like the yadif after fieldmatch just deints only interlaced pictures, and then there's decimation [19:43] <Zeranoe> Well I have no idea if my source is interlaced or inverse telecine, so I'm not sure which to apply [19:44] <JEEB> time to pick a moving scene, output field by field and then go through it? first look at every second field and look if you have a different picture 1-2-3-4-5 or 1-2-3-4-4 (latter has one duplicate), and then you start checking every field, and see if you have two fields comprising of one picture, or if every field is its own picture [19:45] <JEEB> the latter check checks if you want to deint or fieldmatch, and then the first check tells you if you need to decimate (remove the duplicate) [19:45] <matthias_> How can i know record a null module with ffmpeg? [19:45] <clever> that reminds me, i'm getting seriously out of order frames from the omx decoder [19:45] <clever> JEEB: would interlacing cause it to skip back several frames and repeat frames silently? [19:46] <Zeranoe> JEEB: how do i output field by field? [19:46] <JEEB> unfortunately you will have to figure out what way is the simplest for you for that. I'm too used to avisynth for that, I guess vapoursynth makes it possible as well [19:47] <JEEB> possibly mplayer/mplayer2/mpv? I just have no idea [19:47] <JEEB> yadif also has a mode to output every field as its own picture, so you could check with that, although it will apply deint so it's not like you're looking at the fields as-is from the source... [19:50] <matthias_> klaxa: i figured it out now, but i need some help with the scripting [19:56] <JEEB> Zeranoe, basically ffmpeg is great for fully automated stuff, while if you start wanting to do stuff properly you kind of end up needing something else to check out various things :) Esp. when you start having to do commercial/ad cutting and actually picking the right way to make interlaced stuff progressive :) [19:57] <JEEB> although the fieldmatch/decimate filters have kind of partially removed some of the need (as in, you can do it -- but if you really have something like a TV airing with both interlaced and telecined content... and ads and the show itself... oh boy) [00:00] --- Mon Dec 30 2013

1 0

ffmpeg-devel.log.20131228
by burek 29 Dec '13

29 Dec '13

[00:05] <ubitux> < michaelni> ubitux, add 128 to each byte, do a shift, mask and subtract 16 from each byte [00:05] <ubitux> i still don't get the trick [00:05] <ubitux> what are you masking? [00:06] <michaelni> that stuff that a 8bit shift would have removed [00:06] <michaelni> shift + mask == 8bit unsiged shift [00:06] <ubitux> i think i understand the unsigned shift one; you just mask out the 3 bits before doing a whole shift so they don't reach the next byte [00:07] <ubitux> mmh.. [00:08] <ubitux> but you do that after the shift? [00:08] <ubitux> meh, i'm confused [00:16] <ubitux> michaelni: http://pastie.org/pastes/8581295/text [00:16] <ubitux> so what now? [00:16] <ubitux> (top down exec, top is the input, left is the action [00:16] <ubitux> ) [01:17] <michaelni> ubitux, was afk, but in>>3 == ((in+128)>>3)-16 [01:19] <michaelni> ubitux, in that pastie it looks like your right shift does 11101010 -> 01111101, that doesnzt look like a right shift of 3 [01:22] <michaelni> or if that was supposed to be just the 64bit shift result, you need a pand after that to clear off the bits that a 8bit shift would have removed [02:57] <kgp705> hi:) [03:08] <PwrSurge> ubitux: got it working by recompiling with --disable-mipsfpu, --disable-mipsdspr1 and --disable-mipsdspr2 [03:09] <PwrSurge> word of advice, CPU optimizations should be "opt-in" and NOT "opt-out" [03:10] <kgp705> somebody can help me? why ffmpeg always stop stream at stream start after 4hours? [03:10] <kgp705> RTMPSockBuf_Fill, recv returned -1. GetSockError(): 10060 (Unknown error) [03:10] <kgp705> RTMP_ReadPacket, failed to read RTMP packet header [03:10] <kgp705> No more output streams to write to, finishing. [04:04] <cone-330> ffmpeg.git 03Michael Niedermayer 07master:8efde6d80c94: avformat/mov: clear padding area in mov_read_extradata() [04:07] <michaelni> PwrSurge, talk with Nedeljko Babic, there are no mips experts here, so writing here about mips will likely not have much effect [04:08] <michaelni> s/there are no mips experts here/there are no mips experts here I THINK/ [04:09] <michaelni> PwrSurge, also Nedeljko is the maintainer of the mips code, so he is the person to speak with if theres a issue in the code [04:11] <PwrSurge> i'm ok now [04:11] <PwrSurge> is he on IRC? [04:13] <michaelni> AFAIK, no [04:13] <michaelni> but i might be wrong of course [04:14] <michaelni> you can find his email address in the source code ... [10:45] <ubitux> michaelni: ok i finally get it, thanks a lot! [10:48] <ubitux> http://pastie.org/pastes/8582132/text makes more sense now :) [10:49] <ubitux> ofc, with the >>3 or >>4 done unsigned on the whole 64b word [11:01] <ubitux> which makes me realize we can actually do that with a single data [11:02] <ubitux> like doing the shift first, then (x^16)-16 [11:16] <ubitux> http://pastie.org/pastes/8582156/text [11:16] <ubitux> seems to work :) [11:17] <ubitux> and that's better because i only need one reg of data [11:17] <ubitux> oups, not 0x10 in the next one [11:18] <ubitux> http://pastie.org/pastes/8582158/text [11:18] <ubitux> here it is [12:53] <ubitux> http://pastie.org/pastes/8582285/text more complete example [12:54] <ubitux> now i'm wondering about a shortcut for the >>1 case [13:12] <funman> so who's coming to fosdem? [13:12] Action: funman is [13:16] <ubitux> if we have a ffmpeg stand i might consider it [13:16] <ubitux> i don't think it's the case though [13:58] <BBB> michaelni: I'm listed as moderator for 2 MLs on mplayerhq.hu (ffmpeg-soc-mentor and ffmpeg-legal), can I be removed? I'm really not tending to the MLs anymore and to my knowledge they're not in use anyway (I think they should be archived and/or deleted) [13:58] <BBB> but I keep getting daily emails about pending admin requests that I don't want to handle [14:09] <ubitux> ok, filter4() and filter2() done (but probably broken) [14:09] <ubitux> i'm gonna have a good time debugging all of this [14:24] <BBB> good joy :) [14:30] <Compn> BBB : you should be able to moderate yourself off of the list [14:31] <Compn> if you still have the password [14:31] <Compn> (i dont have access to those lists) [14:44] <michaelni> BBB, done [14:45] <michaelni> does anyone want to take over ML admin/mod of the 2 lists ? [14:45] <michaelni> -legal has noone now [14:47] <michaelni> or should they be deleted ? [14:48] <Compn> is -legal even written anywhere ? [14:48] <Compn> i mean, how would a person know to contact it ? [14:48] <michaelni> no idea [14:48] <Compn> if not in docs/wiki/code just delete it [14:50] <Compn> No results found for "ffmpeg-legal(a)ffmpeg.org". [14:50] <Compn> only result for ffmpeg-legal(a)mplayerhq.hu is lists.mplayerhq.hu/mailman/listinfo/ffmpeg-legal [14:50] <Compn> in the googles [14:50] <Compn> i didnt check code/docs [14:51] <Compn> i think it was made so the team could discuss legal issues ? [14:52] <Compn> just another worthless private ml ? [14:54] <michaelni> last mail i seem to have locally from it is from Mon, 23 May 2011 [15:10] <BBB> the list is unused [15:10] <michaelni> Compn, posted the suggestion to delete it to the ML [15:10] <BBB> it was for foundation setup and for some legal settlements with license violators that I pursued 4-5 years ago or so [15:10] <BBB> I stopped doing that 3 year ago when I started working for goog [15:11] <BBB> and foundation-wise ffmpeg uses something else now [15:11] <BBB> so no need to use the list anymore [15:11] <BBB> open lists are better anyway [15:11] Action: michaelni agrees [15:25] <BBB> I find changing assembly for icl kinda odd, basically agree with reimar, let's fix MANGLE [15:30] <saste> michaelni, ffmpeg-soc-mentor also should be deleted as well [15:30] <saste> we're not using since two years, and we should use the regular -devel mailing lists for such projects [15:30] <saste> the idea is to "integrate" students in the natural development environment [15:31] <saste> ^^ ignore this one, -mentor was about mentors [15:34] <BBB> well I still agree [15:34] <BBB> we can restart the list when soc comes in again [17:43] <j-b> ubitux: do you know where vismv is implemented in ffplay.c? [17:44] <ubitux> it's in the mpeg decoder [17:46] <j-b> I understood that, but is it just setting p_context->debug_mv to 1 or something more than that? [17:46] <ubitux> i think that's all [17:47] <j-b> It fails in VLC, no idea why [17:48] <cone-703> ffmpeg.git 03Yu Xiaolei 07master:af228a9f9f00: swscale/arm: fix build error with --enable-shared [17:48] <ubitux> it fails how? [17:48] <ubitux> no effect? [17:50] <j-b> yep [17:51] <wm4> who uses vismv and why? [17:52] <michaelni> i used it occasionally to see the motion vectors [17:53] <nevcairiel> its more of a debug/dev tool then something that users should ever see [17:56] <j-b> wm4: me, when teaching [18:12] <iive> i think libav removed it. probably got merged. [18:12] <michaelni> iive, vismv is supported in ffmpeg [18:13] <j-b> no, it definitively works with my ffplay [18:14] <ubitux> j-b: look at setting p_context->debug as well maybe [18:14] <michaelni> also works in ffmpeg and valgrind shows nothing odd with either ffplay or ffmpeg and -vismv [18:14] <iive> well, you know I do not like the deletionism. [18:15] <ubitux> though, debug_mv should be enough [18:16] <ubitux> j-b: oh, make sure you're not using hwaccel [18:16] <clever> is there a command line flag to force hwaccel off? [18:17] <j-b> ubitux: I am not [18:17] <j-b> ubitux: and I force no EMU_EDGE [18:18] <ubitux> no idea then :p [18:27] <michaelni> j-b, "cvlc --avcodec-vismv 7 matrixbench_mpeg2.mpg" works here but --ffmpeg-vismv doesnt [18:30] <j-b> 7 ? [18:31] <michaelni> 1+2+4 [18:32] <michaelni> but 1 should behave the same id guess [18:32] <michaelni> dunno what the difference is between the avcodec and ffmpeg options [18:34] <j-b> ffmpeg should be deprecated name of the same option, since it is a libavcodec option [18:56] <j-b> ubitux: as you seemed to care: https://wiki.videolan.org/Libavcodec_regressions/ [18:57] <ubitux> cool [18:58] <j-b> ubitux: and sorry, but WTH do you need that many RGB pixfmt? [18:58] <ubitux> do I? [18:58] <j-b> you do :) [18:58] <ubitux> dunno [18:59] <ubitux> is it problematic ? [18:59] <wm4> I'm wondering what the heck is up with these bayer formats [19:00] <j-b> ubitux: tbh, it's not problematic, but for libavutil users, it means more work [19:00] <wm4> they're not used anywhere, and they look like they'd break everything [19:00] <wm4> j-b: IMO most pixel formats come from endian and bit width variants [19:01] <wm4> j-b: endian swapping could be done in the raw video decoders/encoders instead (who needs odd-endian natively?) [19:01] <wm4> j-b: the bit width variants could be reduced by padding them with LSB zeros instead of MSB zeros, but AFAIK would require more work in the decoders [19:01] <j-b> wm4: well, I do not see the need for RGB0 [19:01] <wm4> IMO RGB0 is useful to indicate the lack of alpha [19:02] <wm4> how else would you know [19:02] <j-b> RGB24 [19:02] <wm4> that's 3 bytes per pixel [19:03] <wm4> there are also some odd formats, like AV_PIX_FMT_MONOBLACK [19:03] <wm4> which seems to be redundant with AV_PIX_FMT_MONOWHITE, except it's inverse [19:04] <wm4> anyway, just removing the endian variants would literally half the number of pixfmts [19:04] <j-b> still, sorry, they are wayy too many [19:05] <wm4> and most of them are used only by raw decoders... [19:07] <wm4> IMO they aren't really a problem though... what's worse is that a decoder can output any format it likes [19:07] <wm4> instead of a user requested one (so a user has to be able to deal with any format) [19:07] <wm4> but that's because libavcodec is so low level [19:07] <wm4> and you have to swscale the output yourself [19:08] <kierank> wbs: what's wrong with bayer? [19:08] <kierank> wm4: [19:08] <kierank> sorry [19:09] <wm4> I don't know thus format, but it uses some extremely weird form of RGB subsampling [19:09] <kierank> it's what comes from the camera sensor [19:09] <wm4> which breaks everything that expects that RGB is sane [19:09] <kierank> almost everything that you ever watch has come from a bayer sensor [19:09] <wm4> e.g. a user might use pixdesc to access individual components, and this code would break with BAYER (there are actually some filters in lavfi that do this) [19:10] <wm4> what a sick world [19:10] <kierank> a user might try to use pixdesc [19:10] <j-b> planar RGB was alos breaking the "sane part" [19:10] <kierank> and then fail [19:10] <wm4> j-b: planar RGB is rather easy to handle and to detect, though [19:10] <j-b> yes [19:11] <wm4> kierank: I suspect it's more on the fail side usually... [19:11] <nevcairiel> its not ffmpegs fault some codecs encode their stuff like that :d [19:12] <kierank> I gave up trying to use pixdesc [19:12] <wm4> on the other hand, ffmpeg has only a small number of audio formats [19:12] <kierank> can't remember exactly why but it was a complete pita [19:12] <wm4> even 24 bit audio, which is rather widely used everywhere, is not supported [19:12] <nevcairiel> but its also really the only one missing [19:12] <j-b> ah, that! [19:12] <j-b> No way to show the user that it was 24bit audio in the UI [19:12] <wm4> heh [19:12] <nevcairiel> sure is [19:12] <j-b> sooo many user complaints [19:12] <nevcairiel> read raw_bits_per_sample [19:13] <kierank> i thought ffmpeg has 24-bit audio? [19:13] <wm4> j-b: always show 24 instead of 32, nobody will notice [19:13] <j-b> wm4: that's cheating [19:13] <wm4> kierank: it's converted to 32 bit [19:13] <nevcairiel> there is a variable for that in avcodeccontext, why not use it o.o [19:13] <nevcairiel> i send patches for various codecs to actually set it properly [19:13] <wm4> nevcairiel: there are many variables there [19:13] <wm4> the question is whether it's reliable (maybe it isn't...) [19:13] <wm4> hm I guess I could use it [19:14] <nevcairiel> not sure how many codecs really use S32 [19:14] <nevcairiel> could check how many of those set it [19:14] <kierank> anything packed uncompressed [19:14] <wm4> and then introduce a AF_FORMAT_S32_BUT_REALLY_24 in my code [19:14] <nevcairiel> i just lug around the bits per sample [19:14] <nevcairiel> since i also want to show 20, if appropriate [19:16] <wm4> nevcairiel: what's the correct spelling of that variable? [19:16] <kierank> wm4: i can understand why it's done that way though [19:16] <wm4> I only see av_get_exact_bits_per_sample [19:16] <kierank> because if you want to convert it you have to change to 32-bit each time [19:16] <nevcairiel> AVCodecContext bits_per_raw_sample [19:16] <wm4> nevcairiel: thanks [19:16] <kierank> wm4: would your S24 be three bytes, or 24-bits in 32-bits unshifted? [19:16] <wm4> kierank: 3 bytes [19:17] <nevcairiel> which is probably why its not done [19:17] <kierank> then it would be a pita to convert [19:17] <nevcairiel> SIMDing 24-bit audio is painful [19:17] <wm4> it's what the audio APIs expect [19:17] <nevcairiel> i tried once [19:17] <j-b> nevcairiel: this field is just an "information" field? [19:18] <wm4> nevcairiel: libavresample (which is the only thing which will have to deal with it) could perhaps convert it on the fly? [19:18] <nevcairiel> aren't all fields some kind of information? [19:18] <kierank> wm4: then it's pointless [19:18] <nevcairiel> but sure, its not mandatory, you can play it as S32 just fine since its shifted to MSBs [19:18] <kierank> wm4: it's the same as the people who wanted 10-bit video to be shifted into a uint16_t [19:18] <nevcairiel> it just informs you that 8 bits are zeros, for example [19:18] <kierank> to process it you'd have to shift it pointlessly [19:19] <wm4> well duh, all decoders shift around data [19:19] <wm4> but the purpose of doing that is to turn it into easy to handle information [19:19] <kierank> ????? [19:19] <kierank> wtf [19:19] <wm4> so there's a tradeoff [19:19] <nevcairiel> i always get that mixed up, ffmpeg doesnt shift video, right? [19:19] <kierank> some decoders do because they haven't been updated iirc [19:19] <kierank> wm4: it's bad because you need 32-bit intermediates [19:19] <nevcairiel> the stupid thing is, all the microsoft types for >8-bit video expect shifted [19:19] <nevcairiel> so i have to do it anyway :D [19:20] <kierank> whereas you can do simple processing on 10-bit [19:20] <wm4> kierank: yeah, and according to michaelni it'd be slightly less efficient [19:20] <wm4> but think of the display side... what takes 10 bit natively? [19:20] Action: kierank has a lot of equipment which does [19:20] <wm4> even 10 but yuv? [19:20] <wm4> *bit [19:20] <kierank> all the video processing I do is 10-bit 4:2:2 [19:20] <nevcairiel> remember his broadcast background, they do much more 10-bit then the average persons [19:20] <kierank> hundreds of channels doing that [19:20] <wm4> I guess that's "pro" stuff then [19:21] <kierank> for example to do an interlaced 422 -> 420 conversion I do a weighted average of the chroma fields [19:21] <kierank> if it was 16-bit I would have to use 32-bit intermediates [19:23] <nevcairiel> reminds me of my rgb converter, it starts to lose precision once input goes above 14 bits, since i didnt use 32-bit intermediates [19:24] <nevcairiel> luckily, thats rather are, and with a 8-bit rgb end result, you wouldnt notice anyway =P [19:30] <wm4> anyway, still could kill off 50% of the formats by removing the endian variants [19:31] <wm4> or is there a valid use case for these too? other than FATE possibly becoming a little bit slower [19:31] <nevcairiel> raw formats i suppose [19:32] <nevcairiel> dont want to byteswap them just because we lack a non-native endian format [19:32] <nevcairiel> on the other hand, audio does that too [19:32] <nevcairiel> (but then audio is usually not a cpu hog) [19:40] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:6ea05ef278b2: avcodec/h264: remove unused variable [19:40] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:833501657bed: avutil/frame: increase padding for frames [20:21] <ubitux> (probably broken) filter6() done [20:21] <ubitux> filter14 remaining, here we go. [20:22] <nevcairiel> so you write all of them first and fix them later? :D [20:23] <ubitux> yes [20:23] <ubitux> i know that's not really a good idea but well. [20:23] <ubitux> i've thought a lot on each of them so it should be fine ;) [20:24] <ubitux> at least it builds! [20:34] <ubitux> i love when the number of registers matches exactly the number i need [20:34] <ubitux> unfortunately it doesn't happen often :p [21:00] <rcombs> kierank: ProRes is 12-bit iirc [21:10] <kierank> rcombs: ? [21:10] <rcombs> a lot of TV stuff is 12bit, not even 10bit [21:12] <kierank> SDI is 10-bit [21:43] <BBB> ubitux: I do it that way too, I find it ok [22:10] <cone-703> ffmpeg.git 03Michael Niedermayer 07master:55fa898969d1: avcodec/jpeg2000dec: zero Jpeg2000QuantStyle structure before use in get_qcd() [00:00] --- Sun Dec 29 2013

1 0

ffmpeg.log.20131228
by burek 29 Dec '13

29 Dec '13

[02:56] <kgp705> hi:) [02:57] <kgp705> i need some help [11:07] <Zeranoe> if a file has a 720x480 resolution, and a 16:9dar,what is the actual dimension of the video playback [11:26] <viric> it depends on the sar [11:26] <viric> ah no [11:27] <viric> well, 16/9 = 720/480 * sar [11:56] <Floris497> good morning [11:57] <Floris497> i want to run ffserver on a server but is it https only and i cant get to the /status.html [12:04] <Floris497> can someone help me? [12:09] <AndrzejL> guys any "official" THE BEST howto of ripping dvd movie chapters to single avi files? [12:09] <AndrzejL> coz googling gets many hits but I dont need many I need one - THE ONE ;D [12:12] <AleXoundOS> AndrzejL, maybe using ffmpeg concat demuxer/protocol https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20%28join,%20merge%29%2… [12:12] <AndrzejL> Will check it out AleXoundOS thanks [12:42] <Floris497> does anyone know anything about ffserver? (am i on the richt place?) [12:44] <ShorTie> i would think your in the right place and some peeps know about ffserver, but it might be they are all asleep right now [12:47] <Floris497> ShorTie: ah oke, will try later then [13:10] <theholyduck> Floris497, good rule of thumb for irc [13:10] <theholyduck> if you have a question. ask it propperly. [13:10] <theholyduck> and completely [13:10] <theholyduck> and then wait :P [13:11] <theholyduck> often sumarized as, dont ask to ask, just ask [13:11] <Floris497> theholyduck: ah, but the problem is i don't really know what the problem is :S [13:12] <theholyduck> well then, you hae a problem guess [13:12] <Floris497> i have ffserver running on an remote server but i cant connect to the /status.html [13:13] <Floris497> think it's becoase it behind a firewall, the server is from my school [13:23] <lkiesow> Floris497: I guess you either have to configure the firewall or tunnel http over an available acces method [13:23] <lkiesow> i.e. SSH [13:23] <Floris497> i can ssh, but i cant open streams or status.html, and i have no sudo rights (school server) [13:28] <iive> sshd have the ability to forward ports, ssh even supports socks4/5 in order to work as tunneling proxy. Usually this is disabled on the sshd, but... [13:28] <iive> you can at least try it. [13:30] <Floris497> iive: oke, i have no knowledge of how that works, will look into that, i'm going to ask the systemadmin if he can do something for me. [13:32] <jacob___> what is ffserver? [13:32] <jacob___> never heard of it, i will google [13:34] <Floris497> jacob___: server stream tool for redistributing streams [13:35] <jacob___> mmm,.., why isnt a url to a flat file (mp4) sufficient ? [13:36] <jacob___> oh its for live streaming))) [13:36] <iive> Floris497: btw, you may try tcptraceroute to figure out if the port is open. [13:36] <iive> or just nmap -p 80 [13:36] <jacob___> ffserver sounds awesome,,.., like your own private broadcasting,..., can you do subtitles [13:37] <Floris497> i have it running on an other port, but the server is realy big cant just use port 80 [13:38] <iive> well, i gave 80 as it is the default http port... `man nmap` [13:46] <jacob___> can someone point me to a broadcast that uses ffmpeg? [13:46] <jacob___> i just want to see it working from the client side [13:46] <jacob___> what kind of client is needed? web? or an audio/video player? [14:09] <lkiesow> Floris497: If ffserver serves on port 8080 try something like: [14:09] <lkiesow> ssh -L 8080:localhost:8080 -o ServerAliveInterval=15 user(a)server.com [14:10] <lkiesow> This will listen to the port 8080 and, transmit te request to the remote host and forward it there to localhost:8080 [14:10] <Floris497> lkiesow: what does that do [14:10] <Floris497> so i can acces it by localhost on my computer [14:10] <lkiesow> So you can access it locally via http://localhost:8080 [14:10] <Floris497> *localhost:8080 [14:10] <lkiesow> jep [14:11] <Floris497> lkiesow: ah thanks going to try that :) [14:12] <lkiesow> A more general approach is to creat a ssh socks proxy using ssh -D PORT REMOTEADDR [14:12] <Floris497> first trying this :) [14:12] <lkiesow> With that you can use your remote host as a general proxy for your rowser [14:15] <Floris497> lkiesow: ssh -l works, how do i break it? closing the ssh? [14:16] <Floris497> lkiesow: this is cool thanks, now it probably wil work :) many thanks [14:18] <Floris497> lkiesow: very happy right now, didn't know this was even posible [14:26] <lkiesow> Having access via ssh basically means that you can access all services in the internal network. It is quite convinient :) [14:36] <Floris497> so many ssh windows.. [15:18] <Broomhandle> The .avi video files produced from DOSbox when recording seem to be damaged. When I try to heal them with ffmpeg, I get all sorts of errors. Usually, all files can be healed/converted in ffmpeg. [15:22] <AleXoundOS> I'm copying video from HLS stream to twitch.tv using flv rtmp output. http://www.twitch.tv/snipealot1 [15:22] <AleXoundOS> but image gets distorted once a second or 2 [15:23] <AleXoundOS> if I restart stream sometimes it gets better [15:25] <AleXoundOS> better check twitch.tv/snipealot4 [15:25] <AleXoundOS> maybe I need to specify some muxer parameters or something is wrong with output container? [16:09] <Rasi> ffmpeg -r 25 -f x11grab -s 2560x1440 -quality good -cpu-used 0 -b:v 5000k -qmin 10 -qmax 42 -bufsize 1000k -threads 4 now.webm [16:09] <Rasi> can anyone tell me whats wrong with this command? [16:09] <Rasi> it complains that x11grab is not a valid option. same thing for the filename (now.webm) [16:19] <Rasi> ok, got it [16:19] <Floris497> what was wrong? [16:20] <Floris497> ffmpeg: error while loading shared libraries: libx264.so.140: cannot open shared object file: No such file or directory [16:21] <Floris497> what do i do? [16:21] <AleXoundOS> Floris497, install x264 dependency [16:21] <Floris497> AleXoundOS: how? [16:21] <AleXoundOS> Floris497, what distribution do you use? [16:21] <Floris497> debian armhf [16:22] <Floris497> just recompiled ffmpeg with x264 (3 hours) [16:22] <Floris497> now it does nothing [16:23] <AleXoundOS> Floris497, not sure if debian arm has already x264 package with .140 version [16:23] <AleXoundOS> Floris497, do you compile ffmpeg manually? [16:23] <Floris497> yep [16:24] <Rasi> Floris497: missing -i $DISPLAY+0,0 [16:24] <AleXoundOS> then I think you'll have to compile recent x264 package too [16:24] <Floris497> i did [16:24] <AleXoundOS> Floris497, "ls -l /usr/lib/libx264*" [16:25] <Floris497> ls: cannot access /usr/lib/libx264*: No such file or directory [16:25] <Floris497> sudo find / -iname 'libx264.so.*' [16:25] <AleXoundOS> found something? [16:26] <Floris497> cant post? [16:26] <Floris497> :s [16:26] <Floris497> got: /usr/local/lib/libx264.so.140 /usr/lib/arm-linux-gnueabihf/libx264.so.123 /usr/src/x264/libx264.so.140 [16:27] <Floris497> AleXoundOS: do i need to link thinks? [16:27] <Floris497> *things [16:27] <AleXoundOS> hm, maybe ffmpeg cannot find the library in /usr/local/ [16:27] <AleXoundOS> /lib/ [16:27] <AleXoundOS> Floris497, I think it will work if you link it manually [16:28] <AleXoundOS> Floris497, but it's not considered to be a good way [16:28] <Floris497> you know how i link? [16:28] <Floris497> not very clean [16:28] <AleXoundOS> Floris497, probably you had to specify installation output directory when doing "make install" for x264 [16:29] <Floris497> do i need to install x264 again? [16:29] <Floris497> of ffmpeg? [16:29] <AleXoundOS> as you wish [16:29] <Floris497> *or [16:29] <AleXoundOS> no, ffmpeg is fine I think [16:29] <AleXoundOS> Floris497, ln -s /usr/local/lib/libx264.so.140 /usr/lib/libx264.so.140 [16:29] <Floris497> ffmpeg: error while loading shared libraries: libfaac.so.0: cannot open shared object file: No such file or directory [16:30] <Floris497> think i followed the wron tutorial.. [16:30] <AleXoundOS> go with same algorithm, find libraries, link them to /usr/lib/ if you want to make it work quickly [16:31] <AleXoundOS> or add /usr/local/lib path to "PATH" environment variable [16:31] <AleXoundOS> env|grep /usr/lib| grep PATH [16:31] <klaxa> PATH? not in your /etc/ld.so.conf.d/some_config.conf? [16:32] <Floris497> AleXoundOS: that does not output anything [16:32] <klaxa> or is archlinux being bleeding edge again? [16:32] <AleXoundOS> klaxa, he uses Debian ARM [16:32] <klaxa> oh [16:32] <klaxa> ah [16:33] <klaxa> isn't it LD_LIBRARY_PATH anyway? [16:33] <AleXoundOS> maybe [16:33] <AleXoundOS> I'm not a Debian user, I dunno [16:35] <AleXoundOS> Floris497, so figure out how to add /usr/local/lib path as a library path in your distribution [16:35] <Floris497> AleXoundOS: oke thaks for the help [16:35] <Floris497> *thanks [16:35] <Floris497> was very usefull [16:35] <AleXoundOS> )) [17:03] <jacob___> hi [17:03] <jacob___> I have a question about \Roaming\Bitcoin\blocks [17:03] <jacob___> i see 2 kinds of file [17:03] <jacob___> rev00xxx.dat [17:03] <jacob___> and blk000xx.dat [17:04] <jacob___> whats that? [17:06] <jacob___> oh shit [17:06] <jacob___> wrong channel sorry [17:10] <clever> been there, done that [19:08] <Malinux> trying to split a mkv-video. I used this command: "ffmpeg -acodec copy -vcodec copy -ss 00:06:52 -t 02:19:18 -i The\ Testamente\ of\ Dr\ Mabuse\ 1933\ 576p.mkv The\ Testamente\ of\ Dr\ Mabuse\ 1933\ 576pp.mkv" I got this error-message: "[matroska @ 0x22ff560] pts < dts in stream 0 [19:08] <Malinux> av_interleaved_write_frame(): Invalid argument" [19:24] <AleXoundOS> try to put "-i <VIDEO_FILE>" between -ss and -t options [19:25] <PowerCC> Hi, I'd like to upscale a video from 720x400, how would I apply variable bitrate? [19:26] <PowerCC> currently I am using -coder ac -level 41 -s hd720 -vb 5000k is that too high? [19:26] <Malinux> AleXoundOS: ok [19:27] <Malinux> AleXoundOS: That results in the same error message [19:35] <Malinux> AleXoundOS: I have done this earlier and it works. So I don't know why it does not work anymore [20:00] <Floris497> do i need a lot of power for a 720p stream? [20:01] <Floris497> i cant get a nice stream, it lags few seconds and then continues on superspeed [20:01] <Floris497> using ffmpeg and ffserver [20:03] <relaxed> Malinux: use mkvmerge [20:03] <Floris497> that is? [20:04] <relaxed> a tool for dealing with matroska files [20:04] <relaxed> PowerCC: which codec? [20:05] <relaxed> Floris497: yes to you your streaming question. [20:05] <Floris497> relaxed: can you help me? [20:06] <relaxed> perhaps, but I don't have much experience with ffserver. [20:11] <Floris497> relaxed: then ik go back to google :p [20:19] <Malinux> relaxed: ok [20:20] <relaxed> Malinux: look at --split in the mkvmerge man page [20:24] <Malinux> relaxed: aha :) I see, I checked out the gui and couldn't find split :) I check out the cli-version instead :) [20:24] <relaxed> man mkvmerge|less +/' --split' [20:25] <Malinux> is it in the mkvtoolnix package? [20:25] <relaxed> yes [20:25] <Malinux> ok :) [20:28] <PowerCC> libx264 [20:30] <relaxed> PowerCC: https://trac.ffmpeg.org/wiki/x264EncodingGuide [20:31] <PowerCC> should be the same for avconv? [20:31] <JEEB> generally yes [20:32] <PowerCC> hey JEEB [20:33] <PowerCC> -x264opts not working with avconf [20:33] <JEEB> most of the stuff you set with x264opts has its own settings, and I'm pretty sure nowadays ffmpeg's ffmpeg has the same features [20:34] <JEEB> (since that stuff mostly if not completely gets merged) [20:34] <PowerCC> k [20:34] <JEEB> as for setting specific settings I wonder if it was x264-params [20:34] <JEEB> but really, first thing you should do is check if those settings you're setting have a separate setting :P [20:34] <PowerCC> to overwrite defaults [20:35] <PowerCC> i am mostly interested in hardware compatibility. [20:35] <PowerCC> so i should be ok with defaults. [20:35] <JEEB> then you're mostly interested in -refs [20:35] <JEEB> which sets the amount of ref frames, so that you can be sure that x264 doesn't try to set more of them than your level lets you use [20:35] <JEEB> x264's cli encoder auto-limits refs when you use --level [20:35] <JEEB> but libx264 doesn't [20:35] <JEEB> -level just sets the flag [20:36] <PowerCC> i used to just put -coder ac -level 41 [20:36] <PowerCC> forces 4.1 profile [20:36] <JEEB> that just sets the flag [20:36] <PowerCC> i see [20:36] <JEEB> as for -coder ac I have no idea [20:37] <PowerCC> no one can know it all ;) [20:37] <JEEB> but I have a feeling you're possibly doing something wrong [20:38] <Malinux> relaxed: I tried, but it splits the film into several files. What I want is to shave away the first 6 minutes and 52 seconds and leave the rest into a single file [20:39] <PowerCC> all my output plays just fine now, i am just trying to have a better understanding what each function does and that my output is set for size&quality ratio. [20:39] <PowerCC> i also noticed subtitles filter -vf subtitle no longer works with avconf but c:s does [20:40] <JEEB> yes, that filter is not in libav [20:40] <PowerCC> libass [20:40] <JEEB> I recommend you poke them if you want them to add it [20:40] <PowerCC> will do. [20:40] <JEEB> also, well, first of all you're leaving out something that you would have to have in order to have the stream be compliant with all presets for that level [20:41] <JEEB> second of all please find out what exactly -coder ac does [20:41] <JEEB> and thus you can find out if you're doing something immensely stupid or not [20:41] <PowerCC> all i know about -coder ac is that it displays high profile 4.1 vs 3.1 (default) [20:41] <PowerCC> but my output plays back just fine without -coder as well. [20:42] <JEEB> that's one crappy way of having a setting set [20:42] <JEEB> please actually find out what it does, and then we can continue the discussion [20:44] <PowerCC> it appears to only set a flag for 4.1 high profile. [20:44] <JEEB> no [20:45] <JEEB> cause versus effect [20:46] <relaxed> -coder ac enables cabac [20:46] <PowerCC> according to help ac=arithmetic coder [20:46] <relaxed> you should be using a preset instead of setting it, though [20:46] <PowerCC> can also set variable length with -coder [20:47] <PowerCC> that's just it, i am reading the link relax sent to see which profile will provide that [20:47] <PowerCC> i am pretty much down to only that extra -coder ac -level 41 [20:47] <PowerCC> the rest is all preset [20:51] <PowerCC> i'll use -profile:v high -level 4.1 from now on [20:51] <PowerCC> i will test high10 on my Roamio as it should work [20:54] <PowerCC> i am not finding any preset that will use best -vb for hd720 [20:54] <PowerCC> i have to indicate -vb bitrate? [20:54] <PowerCC> default values seem too low [20:55] <ffmpegger> Dept. Of Silly Questions: I know what padding is in ffmpeg but what is a "pad" ? [20:56] <ffmpegger> Many error messages reference it.... [21:03] <PowerCC> relaxed: -profile:v high -level 4.1 does not work, what am i doing wrong? [21:03] <PowerCC> leaving -level 4.1 sets flag to level 3.1 [21:04] <JEEB> <relaxed> -coder ac enables cabac <- ugh, you need to be using a very, very high-speed preset to have CABAC disabled :/ [21:05] <PowerCC> so here is what i have so far without having to provide -vb # [21:05] <JEEB> PowerCC, having a lower level set is never a bad thing, though. Neither is profile. It just means that you're not using the features that would make it select a higher profile/level. [21:05] <PowerCC> -threads 4 -c:a copy -c:v libx264 -profile:v high -tune film -s hd720 [21:06] <JEEB> do you want your output be of specific size (not caring about the quality), or do you want to have "constant quality" and not care about having an exact file size [21:06] <JEEB> because when picking the rate control mode you pick one of those two [21:07] <PowerCC> i care more about quality, i'd say quality-60% size-40% [21:07] <ffmpegger> Anybody? [21:07] <JEEB> compression capabilities are the same with CRF and 2pass ABR, so if it goes over it means that the source needs more rate :P [21:07] <JEEB> (for that "rate factor") [21:08] <JEEB> in other words, your use case sounds like you'd want to use CRF [21:08] <JEEB> which is -crf [21:08] <JEEB> default is 23 [21:08] <PowerCC> size not a major concern for me but of course i don't want to get over 5gb for under 2 hours worth of video. [21:08] <JEEB> basically encode tests with 4000-5000 frames of content [21:08] <JEEB> and pick the highest crf value that still looks good [21:09] <PowerCC> got it [21:09] <JEEB> so start at 23 (the default), and then go up if it looks good, and down if it looks bad [21:09] <PowerCC> i'll use default and check for now... [21:09] <PowerCC> thx [21:09] <JEEB> basically looking at your pasted settings [21:10] <PowerCC> i'd probably yank -tune film out [21:12] <JEEB> video related stuff would go: -c:v libx264 -crf 23 -preset medium -level 41 -refs XX -vf scale=trunc(iw*sar/(ih/oh)/hsub)*hsub:720 [21:12] <PowerCC> 23 looks just fine [21:12] <JEEB> set refs according to your resolution [21:12] <JEEB> (and level) [21:13] <JEEB> at this point I'm really wanting to put level limiting for refs into the libx264 wrapper... but I'll still probably end up being too lazy [21:13] <JEEB> Because hardcoding the amount of refs isn't exactly the best idea, either. Esp. with faster presets (where the default amount might be lower than the level limit) [21:13] <PowerCC> -preset medium is default but you must include due to inserting level 41? [21:14] <JEEB> no [21:14] <JEEB> I'm just keeping it there to remind you that if you want better compression you can start poking that switch [21:14] <PowerCC> i see [21:14] <PowerCC> for scaling i just use -s [21:15] <PowerCC> ex: -s hd720 [21:15] <PowerCC> my hardware is not overly picky about size [21:15] <JEEB> well, what I wrote down should actually make it be 1:1 SAR and have a 720 height [21:15] <PowerCC> i see [21:15] <PowerCC> i'll try it now... [21:16] <JEEB> (input width * sar) makes it the original original width with aspect ratio applied [21:16] <JEEB> then I take (input height / output height) [21:16] <JEEB> to see how much bigger or smaller we're making the picture [21:17] <PowerCC> thanks for the forumla [21:17] <JEEB> then I divide the aspect ratio applied input width by that [21:17] <JEEB> and then divide by horizontal subsampling, and truncate that [21:17] <PowerCC> can you give me an example of padding to 720p? [21:17] <JEEB> then I again multiply by horizontal subsampling [21:17] <PowerCC> my iPhone app requires padding [21:17] <PowerCC> meaning it won't resize properly. [21:18] <JEEB> add a pad filter after scale that has the final resolution as the first two parameters and then just look at the example that makes the picture be in the middle of the output picture? :) [21:19] <PowerCC> i c [21:19] <JEEB> the documentation in both libav and ffmpeg should have those examples [21:20] <PowerCC> i seen it before, just thought i had to be a math wiz to use them. [21:25] <JEEB> ffmpegger, don't pm me unless you have something to say to me that is of utmost importance and actually related to me :P [21:25] <JEEB> it's very bad manners [21:25] <PowerCC> so JEEB your almost always here? [21:26] <ffmpegger> Sorry [21:26] <JEEB> and no, I have no idea of what this "pad" thing is you're talking about :P [21:26] <JEEB> PowerCC, enough to actually be surprised I'm still sane :P [21:26] <ffmpegger> ok [21:27] <ffmpegger> makes 2 of us [21:27] <PowerCC> that's very unconditional of you. [21:27] <PowerCC> true giver! [21:28] <ChocolateArmpits> Can ffmpeg rebuild index similarly to VirtualDub ? [21:28] <PowerCC> -bash: syntax error near unexpected token `(' [21:29] <JEEB> PowerCC, time to escape some characters? :) [21:29] <JEEB> ChocolateArmpits, not that I know of (in the same file). You will most probably be able to get a similar result by remuxing with ffmpeg though [21:29] <PowerCC> hell... i am starting to get a headache ;) [21:29] <JEEB> you should see my lavfi monstrocities :P [21:30] <PowerCC> ha [21:31] <ChocolateArmpits> JEEB, thanks for the info. The few times I tried, ffmpeg failed to deliver a good result. VirtualDub with direct stream copy for both video and audio did it without a problem, so I'll just use that [21:31] <JEEB> ChocolateArmpits, yeah -- vdub is rather lovely for AVI :) [21:32] <ffmpegger> JEEB From the ffmpeg docs "A filter with no input pads is called a "source", a filter with no output pads is called a "sink"." Whats a pad ?? [21:32] <JEEB> ffmpegger, I have no idea~ something to do with filter chains without implicit things most probably :) [21:33] <JEEB> PowerCC, this is with the mpv player's syntax but what I have currently (not perfect, seems to do something wrong at times): [21:33] <JEEB> "--vf=sub" "--vf-add=lavfi=[scale=trunc(if(gte(a\,873/480)\,720\,873/a)/hsub)*hsub:trunc(if(gte(a\,873/480)\,480/(a/(873/480))\,480)/vsub)*vsub]" "--vf-add=lavfi=[pad=720:480:(ow-iw)/2:(oh-ih)/2]" "--vf-add=lavfi=[setsar=40/33]" [21:33] <ffmpegger> I hate ambiguity.... [21:33] <JEEB> now guess what that does :D [21:35] <PowerCC> still thinking... [21:35] <PowerCC> well -vf filter adds padding to 480p [21:35] <PowerCC> but setsar i am lost [21:35] <JEEB> just as a hint, gte is a very short way of saying "greater than or equal" [21:36] <JEEB> the setsar one is probably the simplest [21:36] <JEEB> it just forces the sample aspect ratio to a certain value [21:36] <PowerCC> this is what you use for most vids? [21:37] <JEEB> nah [21:37] <JEEB> I was just making a script for PSP encoding automation [21:37] <PowerCC> i see you included subtitles [21:37] <JEEB> that's just mpv's filter, I'm telling it to render subtitles at that point [21:38] <PowerCC> so it will auto detect [21:38] <PowerCC> what if its not uft8? [21:38] <PowerCC> i assume all your stuff is ready to go [21:38] <JEEB> depends, this isn't really ffmpeg although I'm using lavfi filtering [21:38] <PowerCC> be awesome if i can do something like that [21:39] <PowerCC> tell pytivo, ffmpeg_pram to render subs if they are there. [21:39] <PowerCC> only worked for me if the sub is in the same path [21:39] <PowerCC> not sure why it wouldn't work. [21:39] <PowerCC> someone actually wrote a python script but it also only works if the sub are in the same path. [21:40] <JEEB> basically the scale tries to scale the picture into a 720x480 box in a way that by applying 40:33 SAR you get the correct picture ratio for the picture [21:40] <JEEB> then I pad the box so that the picture becomes 720x480 [21:40] <JEEB> and then I force that SAR [21:40] <PowerCC> and all that does not hurt your head? ;) [21:40] <JEEB> it's incorrect, at least I got one sample that doesn't work correctly with it :D [21:42] <PowerCC> so i am trying just -crf 2300 [21:42] <JEEB> lol [21:42] <PowerCC> oops take them 00 [21:43] <JEEB> and no, it doesn't hurt -- you just end up having to think some over how to get a certain kind of result, esp. if you want the filter chain to work with a lot of stuff :) [21:44] <PowerCC> i'll stick to -s hd720 ;) [21:44] <PowerCC> for when i need to upscale [21:45] <JEEB> well, my first example should work for "resize stuff to XXXx720 [21:45] <JEEB> so that the result will have a 1:1 SAR [21:45] <JEEB> as in, no aspect ratio compensation needed [21:45] <PowerCC> no i was getting escape issues [21:45] <ChocolateArmpits> Another one, how should 2 pass encoding for mpeg2 encoder be carried out?Another one, how should 2 pass encoding for mpeg2 encoder be carried out? [21:45] <PowerCC> i also tried [21:45] <JEEB> well it only had ( and ) [21:46] <JEEB> basically prepend \ to them? [21:46] <PowerCC> -vf "scale=iw*min(405/iw\,320/ih):ih*min(405/iw\,320/ih),pad=405:320:(405-iw)/2:(320-ih)/2 [21:46] <JEEB> uhh [21:46] <ChocolateArmpits> sorry for double paste [21:46] <PowerCC> but i am sure i fudge the math [21:47] <ChocolateArmpits> But JEEB, 720p's SAR, when PAR is 1:1, is 16:9, which yields DAR of 16:9 [21:47] <JEEB> ChocolateArmpits, mpeg2 encoder has no presets so good luck and have fun actually getting all out of the encoder, but 2pass encoding would just be -pass 1 with the first pass and -pass 2 with the second [21:47] <JEEB> ChocolateArmpits, oh goddamnit are you one of those who have read wikipedia's article on aspect ratios? [21:47] <JEEB> they made up their own SAR [21:48] <ChocolateArmpits> JEEB, I know that, but I was thinking if I have to have any bitrate settings set when encoding for the first pass [21:48] <ChocolateArmpits> I have read more than Wiki [21:48] <JEEB> well, you seem to be talking as if SAR and PAR are different things [21:48] <ChocolateArmpits> And they are, Storage Aspect Ratio, Pixel Aspect Ratio [21:48] <JEEB> no, not as long as you go by specifications [21:49] <ChocolateArmpits> What specifications are you talking about? [21:49] <JEEB> PAR is pixel aspect ratio (hi there MPEG-4 container and MPEG-4 Visual), and SAR is sample aspect ratio (hi there MPEG-2 Video and MPEG-4 AVC as well as MPEG-H HEVC) [21:49] <JEEB> also lavfi uses sar as sample aspect ratio [21:50] <JEEB> in reality they both mean the same thing, just that "sample" is more general than "pixel", which is why the latter specifications have used that word [21:50] <ChocolateArmpits> What does your SAR describe? [21:50] <JEEB> I am using the official lingo that ISO/IEC and ITU-T specifications use :P [21:51] <JEEB> although just as I now noted, ISO/IEC decided it was fun to use PAR instead of SAR with some MPEG-4 specifications [21:51] <JEEB> (and then AVC (H.264) and HEVC (H.265) use SAR again) [21:51] <ChocolateArmpits> Okay, but what "Sample Aspect Ratio" describe, as opposed to "Storage Aspect Ratio" ? [21:51] <ChocolateArmpits> does* [21:52] <JEEB> the aspect ratio of a single sample (usually a pixel) [21:52] <ChocolateArmpits> So it's the PAR of the SAR-PAR-DAR world? [21:52] <JEEB> there is no such world as far as I know where all of the three mean different things [21:53] <JEEB> I've only seen it on wikipedia and facepalmed [21:53] <JEEB> because it makes things even worse [21:53] <JEEB> although I partially blame ISO/IEC for using PAR in MPEG-4 Visual and the MPEG-4 container to begin with [21:54] <JEEB> SAR and PAR in usual technical video speak mean the same thing, as far as specifications are concerned [21:54] <ChocolateArmpits> I can understand SAR-PAR-DAR having little relevance in a world where 1:1 pixel aspect ratio is dominant; but that would mean that only display aspect ratio has any use [21:55] <JEEB> DAR is generally not specified anywhere (I think?) but is a generally used video-related term about the aspect ratio of the whole picture after aspect ratio correction has been applied [21:55] <ChocolateArmpits> Well, from the SAR-PAR-DAR, SAR is storage aspect ratio (for instance 5:4 for 720:480) while PAR means pixel aspect ratio (for instance 0,(90):1 ) [21:56] <ChocolateArmpits> DAR then describes the final picture aspect ratio [21:56] <JEEB> yes, I know what the definitions by wikipedia are. And I'm not gonna take that because SAR most definitely is not that according to the specifications [21:56] <JEEB> yes, I KNOW [21:56] <ChocolateArmpits> okay [21:56] <PowerCC> thanks a bunch JEEB, off to lunch... see you later on! [21:56] <ChocolateArmpits> But about that 2pass encoding, does the 1pass encoding use any of the settings to determine what to pump into the passlogfile ? [21:57] <JEEB> in general you should use the same rate control and if possible the same settings as with the second pass [21:57] <ChocolateArmpits> I've seen suggestions to stick in higher bitrate than will be used for 1st pass, then lower for the actual 2nd pass [21:58] <JEEB> Anyways, I just am gonna say that you should not use SAR in that way as you are trying to because as soon as you hit someone who has read some video format specifications you are going to end up using a word that actually has a completely different meaning. [21:58] <JEEB> and many settings in various applications including ffmpeg use the Sample Aspect Ratio [21:59] <JEEB> I've not seen a single one that uses SAR to mean the aspect ratio of the picture without any aspect ratio correction [22:00] <ChocolateArmpits> I'm also sceptical if pass encoding works as intended at all: even though minrate and maxrate are set above the target bitrate the encoder takes no use of them when it would seem to be needed [22:00] <JEEB> you should only be using maxrate and bufsize in general [22:01] <JEEB> also not all encoders are good enough to keep to your VBV limits [22:01] <ChocolateArmpits> the console output usually starts off a little higher than set target bitrate, then overtime evens out [22:01] <ChocolateArmpits> Can the console output be trusted? Doing encodes with HCEnc it seems to use the suggested maximum bitrate as well as go below to even out for average bitrate [22:02] <JEEB> esp. without a log (as in, without the first pass being done first) [22:02] <JEEB> anyways, maxrate and bufsize should be doing what you need, if they aren't the encoder fails at life :P [22:02] <ChocolateArmpits> I've always done 1pass when doing multipass encodes [22:02] <ChocolateArmpits> It just seems strange to report bitrates that are not near maximum set [22:02] <JEEB> but you can't use the cli output to get a 100% correct look at if the encoder followed your VBV limits [22:03] <ChocolateArmpits> >cli output [22:03] <ChocolateArmpits> care to explain? [22:03] <JEEB> x264 is nice enough that it actually yells if it couldn't follow your VBV limits, but unfortunately other encoders probably aren't as nice [22:03] <JEEB> command line interface output [22:04] <ChocolateArmpits> few previous times mpeg2video didn't encode or spew out red messages [22:04] <ChocolateArmpits> regarding buffer size or something [22:04] <ChocolateArmpits> But that was before I set proper settings [22:04] <ChocolateArmpits> Or at least did something else to solve them [22:05] <JEEB> anyways, if you set maxrate and bufsize (VBV) the only way to make sure your stream follows the set stuff is to use an app that can actually do the VBV calculations [22:05] <ChocolateArmpits> The mediainfo for the rendered m2v file reports a maximum bitrate at the maxrate set in the command line, but that I guess is just a straight write, not something that was measured all through encoding process? [22:05] <JEEB> you can't trust mediainfo at all for proper VBV analysis :P [22:06] <JEEB> (there's a perl script written by pengvado for raw AVC/H.264 streams, but I have no idea about MPEG-2) [22:07] <ChocolateArmpits> I suppose I could the file through VLC and check realtime statistics, would that suffice? [22:07] <JEEB> no [22:07] <ChocolateArmpits> run the file* [22:07] <JEEB> you actually have to have the app calculate VBV [22:07] <JEEB> basically the app can't do it automatically in most cases :P You have to tell it the VBV values you set (maxrate/bufsize and buffer fill at the beginning) [22:08] <JEEB> the buffer fill generally is 90%, at least in x264 it's set to that [22:08] <JEEB> also I'd really recommend dropping minrate unless the encoder fails at life otherwise, set only maxrate and bufsize -- those are the two variables you care about [00:00] --- Sun Dec 29 2013

1 0

ffmpeg-devel.log.20131227
by burek 28 Dec '13

28 Dec '13

[00:06] <Daemon404> nevcairiel: seems i forgot... [00:06] <Daemon404> icl ships with gdb now [00:06] <Daemon404> lol. [01:28] <cone-783> ffmpeg.git 03Michael Niedermayer 07master:0875a9e4fc4c: avformat/oggparseogm: check input size before reading t [01:28] <cone-783> ffmpeg.git 03Michael Niedermayer 07master:42b6805cc198: avcodec/huffyuvdec: clear remainder of the array on end of input in decode_422_bitstream() [02:02] <BBB> ubitux: why signed? the most common method is +128 (or pxor 0x80; i.e. make unsigned), then pand (0xf8 or 0xf0) and then psrlq/d/w 3 or 4, and then in the end -128 (or pxor 0x80) [02:03] <BBB> oh michael already said that [02:03] <BBB> ok nevermind me [02:55] <iive> BBB: why is the pand? if the operation is byte wise it shouldn't be needed. [02:55] <iive> and i see you do give example with shift that is quad/double/word ... [02:59] <iive> n8 [03:06] <BBB> because there is no bytewise shift [03:06] <BBB> :) [03:11] <cone-783> ffmpeg.git 03Michael Niedermayer 07master:f55bc96a5449: avcodec/pcm-dvd: reset last header on errors [07:28] <ubitux> BBB: why signed; because filter2()/filter4() are signed op [07:29] <ubitux> michaelni, BBB, ok thx will try that [07:30] <ubitux> BBB: btw, about the MC func, any reason to prefer 8 reads vs 2 reads (-3 and +4) and palignr/pshufb? [07:31] <ubitux> (at the beginning of the .loop) [07:32] <ubitux> all the data should overlap, unless i'm missing sth? [07:33] <ubitux> (for the horizontal one) [09:47] <j-b> 'morning [11:51] <richardus> there's no documentation for the -g flag on the ffmpeg-all page, should i file a big [11:51] <richardus> bug [11:51] <richardus> i'm having trouble searching trac for '-g' :p [11:54] <nevcairiel> g is keyframe interval [11:55] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:e630ca511107: avformat/mpegts: check sl.timestamp_len [12:18] <cone-205> ffmpeg.git 03Diego Biurrun 07master:b83d1ee3b41c: avutil: Move library version related macros to version.h [12:18] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:25b243759cb6: Merge commit 'b83d1ee3b41cfe8357836e2582104db2f3364cb0' [12:42] <saste> richardus, g in the codec options chapter [12:44] <BBB> ubitux: I tried palignr/pshufb, it was slower (see also vp8, it does the same thing, or 8px one, it does the same thing) [12:44] <BBB> ubitux: don't know why tbh [12:45] <ubitux> ah, okay& [12:45] <BBB> I'd expect it to be faster b/c non-i/o but what do I know [12:45] <BBB> maybe once it's cached it doesn't matter [12:46] <BBB> also I'm working on 32x32 again now [12:46] <BBB> (the sub4x4/sub2x2 made no speed diff so I left them aside for now) [12:47] <ubitux> btw, srcq and src4q aren't aligned all the time? [12:48] <cone-205> ffmpeg.git 03Stefano Sabatini 07master:8ea150187856: doc/protocols: fix level of udp examples subsection [12:49] <BBB> no, because a ref pixel in mc can be at any position [12:49] <BBB> (as opposed to a dst pixel, which is always blocksize-aligned) [12:50] <ubitux> ok [12:50] <ubitux> then i guess it LGTM, but i don't know MC enough :p [12:51] <ubitux> the sub func in 16x16 LGTM too btw [12:52] <ubitux> i can ofc reply on the ml but since you're here& [13:10] <BBB> tnx [13:10] <BBB> ok off to 32x32 then [13:10] <cone-205> ffmpeg.git 03Luca Barbato 07master:9ace13db77a2: doxy: Fix link in badge color [13:10] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:8102cdfc04a5: Merge commit '9ace13db77a22fd59c217175596a95775c5d25aa' [13:10] <BBB> ubitux: and the other one (sub8x8 I think) also ok? [13:12] <ubitux> the other one? [13:12] <ubitux> i'm talking about sub8x8 in 16x16 [13:25] <cone-205> ffmpeg.git 03Luca Barbato 07master:1ab91c7d4ac6: doxy: Update the css to have a flat style [13:25] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:7ad6515fd4b4: Merge remote-tracking branch 'qatar/master' [13:32] <BBB> I'm sleepy, just ignore me, it's easier [13:32] <ubitux> :) [13:32] <BBB> I missed that whole setence [13:32] <BBB> michaelni: merge of https://github.com/rbultje/ffmpeg/commits/vp9-simd please? [13:32] <BBB> I'll work on a 32x32 skeleton [13:33] <BBB> maybe in ~2 weeks or so that's finished [13:33] <BBB> how's lf? [13:33] <ubitux> in progress [13:33] <BBB> it's 27.4% of ffmpeg runtime here [13:33] <ubitux> https://github.com/ubitux/FFmpeg/compare/vp9-lpf [13:33] <BBB> where total video is like 70-80% or so [13:33] <BBB> so that's like 1/3rd [13:34] <ubitux> i'm doing filter2()/filter4() [13:34] <ubitux> filter14() is started [13:34] <ubitux> filter6() not started [13:34] <ubitux> rest of the function should be "done" [13:35] <ubitux> the flow can be done in different orders, so it's a bit chaotic right now [13:35] <ubitux> i'm trying to organize it so i can get enough reg when i need it [13:36] <ubitux> right now, i'm going for 1) calc flat8out/flat8in/hev 2) filter2()/filter4() 3) filter6() 4) filter14() [13:36] <BBB> yeah that looks good [13:37] <BBB> I mean we'd have to see the final assembly for the more specific comments, but the organization looks logical [13:38] <ubitux> i really enjoy writing that code btw [13:38] <ubitux> more than idct, because it looks like there are a lot of solution [13:38] <ubitux> it's somehow way more flexible [13:39] <BBB> that's the good and the bad part, right? [13:39] <BBB> it's more compartmentalized [13:39] <ubitux> i think it's a good thing :) [13:39] <BBB> but that also means you sometimes run the risk of doing the same calculation multiple times [13:39] <ubitux> i like that :p [13:40] <BBB> and for the perfect simd, you want to prevent that, but then you sometimes lose the compartmentalization again [13:40] <BBB> if you separate it too much, it becomes hard to do just that ;) [13:40] <ubitux> probably [13:40] <ubitux> but as you told me, it's indeed not really important [13:40] <ubitux> because on a whole 16x16 [13:40] <BBB> so the final code tends to be somewhat "messy" because it started pretty (look at vp8) and then I tried to do the final few instruction losses and then it got a little ugly at times [13:41] <ubitux> you basically can trigger every path [13:41] <ubitux> (even with branching i mean) [13:41] <ubitux> so i don't think it really matters [13:41] <BBB> yes [13:42] <ubitux> i'm looking forward the steps where it will work so i can start making it a spaguetti soup [13:42] <ubitux> :) [13:42] <BBB> e.g. limit() and fhev() both use abs(p1-p0) and abs(q1-q0) [13:42] <BBB> so you don't want to do that twice [13:42] <BBB> in vp8 [13:42] <BBB> vp9 might have something similar, I Don't remember [13:43] <ubitux> i reused a lot such thing already [13:43] <BBB> that's the sort of stuff where you can lose a few instructions but then it becomes a little bit intermingled [13:43] <BBB> ok cool [13:43] <BBB> then it'll be great [13:43] <ubitux> https://github.com/ubitux/FFmpeg/compare/vp9-lpf#diff-651121e4f3585d617f2de… [13:43] <ubitux> i'm computing flat8in and hev at the same time here for instance [13:43] <BBB> ah yes [13:43] <BBB> nice [13:43] <ubitux> and i'm also reusing a lot the previous calculation [13:43] <BBB> well I'm glad you like it, I remember going quite crazy with lf at the end [13:44] <ubitux> :D [13:44] <ubitux> what i'm afraid of is not having enough reg for the filter14() [13:44] <ubitux> but i've a B plan @_@ [13:45] <ubitux> anyway, it will take me a little more time [13:45] <ubitux> i'll keep you up to date :p [13:45] <nevcairiel> not even enough regs on 64-bit? :p [13:45] <ubitux> not really [13:45] <ubitux> :( [13:46] <ubitux> as the name suggests, filter_14() needs 14 lines [13:46] <ubitux> of course it's possible to re-read N times [13:47] <ubitux> but i'm trying to reuse a maximum of values [13:47] <BBB> I think it's possible, because you need some pixels only for 2 things [13:47] <BBB> for the flat [13:47] <BBB> and then for the actual filter [13:47] <BBB> so you can prioritized these calculations before anything else [13:47] <BBB> and then drop that register [13:47] <BBB> also for intermediates, feel free to use stack, vp8 does that too on x86-32 [13:48] <BBB> using a bit of stack is fine for such things [13:48] <ubitux> no i don't need the stack [13:48] <BBB> ok that's even better [13:48] <ubitux> the plan was to compute the other small filters so i can free the flat8in & hev and just keep the final mask [13:49] <ubitux> but the filters requires some cache [13:49] <ubitux> typically [13:49] <ubitux> dst[stride * -7] = (p7 + p7 + p7 + p7 + p7 + p7 + p7 + p6 * 2 + p5 + p4 + p3 + p2 + p1 + p0 + q0 + 8) >> 4; [13:49] <ubitux> then [13:49] <ubitux> dst[stride * -6] = (p7 + p7 + p7 + p7 + p7 + p7 + p6 + p5 * 2 + p4 + p3 + p2 + p1 + p0 + q0 + q1 + 8) >> 4; [13:50] <ubitux> here i'm reusing the previous calculation without the shift [13:50] <ubitux> and i'm substracting p7 and p6, and adding p5 [13:50] <ubitux> it's nice to have those cached [13:51] <ubitux> also unpack/repack is taking twice the amount of reg [13:51] <ubitux> so it's a bit short sometimes [13:51] <ubitux> but it should be possible :) [13:52] <ubitux> the filter2()/filter4() is not fun though :( [14:05] <cone-205> ffmpeg.git 03Ronald S. Bultje 07master:0d9375fc908c: vp9/x86: 16x16 sub-IDCT for top-left 8x8 subblock (eob <= 38). [14:05] <cone-205> ffmpeg.git 03Ronald S. Bultje 07master:18175baa54ea: vp9/x86: 16px MC functions (64bit only). [14:05] <cone-205> ffmpeg.git 03Michael Niedermayer 07master:c09bb235bf25: Merge remote-tracking branch 'rbultje/vp9-simd' [14:11] <ubitux> BBB: you still haven't uploaded ped1080p.webm btw? [14:13] <ubitux> i realized that the etv* ones are actually pretty bad quality wise [14:13] <ubitux> even the recent etv5k have quite some blocks [14:15] <ubitux> http://i.imgur.com/ogvjRtV.png like such area [14:15] <ubitux> (it's even worse in etv.webm and etv5000.webm) [14:32] <BBB> ubitux: not yet, will do this weekend [14:32] <ubitux> BBB: did you see my other regression crash btw? :p [14:32] <BBB> yes [14:32] <BBB> will look [14:32] <BBB> filter2/filter4 is similar to vp8, so feel free to look at them [14:33] <BBB> but yes they suck a bit [16:50] <funman> How can I debug this further? http://pastie.org/8580267 [16:50] <funman> ffmpeg version 2.1.1 [16:53] <ubitux> check with the cpuflags [16:53] <ubitux> like, is it reproducible with -cpuflags -mmx? [16:53] <funman> hm well I'm using vlc [16:54] <ubitux> you can't reproduce with ffmpeg/ffplay? [16:54] <funman> didn't try yet [16:54] <funman> I'll remove SWS_CPU_CAPS_MMX for now [16:58] <iive> funman: would you dissassemble a little around the point at fault? [16:58] <iive> actually, there is .c line number. [16:59] <ubitux> which is an inline asm macro [16:59] <funman> http://pastie.org/8580299 [17:00] <funman> http://pastie.org/8580308 [17:01] <ubitux> pointer looks valid [17:02] <ubitux> maybe some overread (odd or weird width maybe?), or a negative linesize somewhere (use of filters like vflip?) [17:06] <funman> http://pastie.org/8580333 [17:06] <funman> that's the context [17:09] <funman> hmm that's a C# app and mono doesn't like valgrind [17:11] <ubitux> VLC is a C# & mono app now? [17:12] <funman> you mean swscale is a C# & mono app [17:13] <funman> vlc has (several) C# bindings and mono is required to run C# afaik [17:14] <funman> ok I found the culprit [17:14] <funman> it's kodab [17:14] <funman> using width instead of coded_width gives me no crash anymore [17:15] <funman> although I wonder why I can't disable mmx code [17:16] <funman> cpu flags aren't given through getContext() anymore? [17:18] <ubitux> av_*_cpu_flags()? [17:18] <funman> how can I change that from vlc? [17:19] <funman> I see there's an av_parse_cpu_flags [17:19] <ubitux> av_force_cpu_flags()? [17:19] <funman> but sws_init_context uses av_get_cpu_flags() [17:19] <funman> ah right [17:19] <ubitux> see how opt_cpuflags() work in cmdutils.c [17:21] <funman> alright now it segfaults in C code [17:21] <ubitux> should be easier to debug :p [17:21] <ubitux> and you know it's a problem in the caller then [17:21] <funman> yeah [17:22] <funman> although it's still weird [17:28] <ubitux> funman: it's a regression? [17:28] <funman> in VLC yes [17:29] <funman> introduced by http://git.videolan.org/?p=vlc.git;a=commitdiff;h=b71c85b3d88b8d0ad2d4a63bf… [17:32] <funman> and that particular one is fixed by http://git.videolan.org/?p=vlc.git;a=commitdiff;h=983198b0fc68d2e2bcfe98b6f… [17:32] <funman> i_width = codec_width, i_visible_width = width [17:33] <iive> there is something I don't seem to get [17:33] <iive> the fault is in the last instructions of RGB_PACK16(). [17:34] <iive> they move %mm0 into (%1). but isn't %1 src[] ? [17:34] <iive> shouldn't it be writing packed rgb into the dst? [17:35] <ubitux> one width is larger than the other [17:35] <ubitux> afaiu [17:35] <ubitux> overread, boom [17:37] <iive> look at the fault instruction, is is write. [17:38] <iive> it is write. [17:39] <ubitux> dstw = srcw and src2w > srcw maybe? [17:40] <ubitux> overreading in src might be fine since it's actually src2w large [17:40] <ubitux> but dstw might have a width of the smallest announced size [17:45] <ubitux> iive: ah sorry, misread what you said; i guess it's an inplace thing :p [17:46] <iive> but... Y8->rgb16? [17:46] <iive> or rather yuv420/yv12->rgb16 [23:23] <PwrSurge> hi, anyone here working on MIPS optimization features? [23:23] <ubitux> hi, [23:23] <ubitux> better contact Nedeljko Babic first [23:24] <ubitux> he's the MIPS maintainer, and regularly send a large bunch of optimizations with some other mips folks [23:26] <PwrSurge> i'm doing embedded development on a mipsel board [23:27] <PwrSurge> was hitting my head against my desk as I could simply not understand why I kept getting "Illegal instruction" on my code after compiling for a new kernel version [23:27] <PwrSurge> lol [23:27] <PwrSurge> for a while, thought it was a bug in my new code [23:29] <PwrSurge> debugged with GDB and found out it was crashing when trying to call libavcodec.so [23:30] <PwrSurge> Program terminated with signal 4, Illegal instruction. [23:30] <PwrSurge> #0 0x76ea9f34 in ?? () from /data/buildsystem-cs/root/lib/libavcodec.so.55 [23:44] <cone-820> ffmpeg.git 03Michael Niedermayer 07master:4156df59f596: avformat/mov: check avio_read() return in mov_read_dref() [00:00] --- Sat Dec 28 2013

1 0

ffmpeg.log.20131227
by burek 28 Dec '13

28 Dec '13

[02:04] <PowerCC> hi JEEB [02:05] <PowerCC> i am not using presets no more silly -psy min-max ;) [02:05] <PowerCC> since when MEncoder is invite only? [03:36] <Miklos> I'm considering a local transcode cluster based on ffmpeg vs. cloud transcode (amazon or zencoder) - but for this I need some updated numbers of ffmpeg performance on Xeon E3 CPUs - any idea where I can find this? [03:36] <Miklos> Or do anyone here use Xeon E3s with ffmpeg [11:48] <newbie|2> hi [11:48] <newbie|2> excuse me ... is possible to create video from html pages with ffmpeg ? [11:49] <jnvsor> How exactly do you want the video? [11:49] <jnvsor> Like a screencast? [11:50] <jnvsor> Or is there a video on the page you want to download? [11:54] <newbie|2> I would like to create a video mp4 from html code ... [11:56] <newbie|2> for example ... create animation with css3 in html code ... and then create an mp4 video ... [11:56] <ubitux> record your desktop [11:58] <newbie|2> I would not do it from the desktop ... [11:59] <newbie|2> sorry ... maybe I'm saying something impossible [12:00] <ubitux> you have various ways of doing such things, but ffmpeg won't do the html/css parsing & rendering [12:00] <ubitux> so you can either use your browser and record the window with ffmpeg, or you could use a web engine like webkit and see if it can outputs rgb frames, which you would pipe to ffmpeg for encoding [12:03] <newbie|2> thank you very much for your answer ... [12:04] <newbie|2> I try to find something about [12:27] <DelphiWorld> ffmpeg -i $a -ar 48000 -cutoff 15000 -c:a libfdk_aac -b:a 128k -profile:a aac_he_v2 /mnt/hdd/Videos/$a.m4v [12:27] <DelphiWorld> is that good? [12:49] <ayad_> hello, can you help me to encoder .flv to .mp4 thank's [12:54] <spaam> how about mux it ? [12:54] <spaam> ffmpeg -i SuperDuperFile.flv -c copy HemligaFilen.mp4 [12:55] <spaam> if you going to use the same codecs in the .flv file in the .mp4 file [12:56] <ayad_> cool [12:57] <ayad_> but i have interrupting on encoding set [12:58] <ayad_> i have this message : Could not write header for output file #0 (incorrect codec parameters ?): Operation not permitted [13:01] <JEEB> the actual error should come before that [13:04] <DeadSix27> any idea -> ?"[matroska @ 0000000003e9d0e0] Can't write packet with unknown timestamp" [13:04] <JEEB> I think that error says it pretty clearly :D [13:05] <JEEB> you have an AVPacket that has an unknown timestamp, and you're trying to mux it into matroska [13:05] <DeadSix27> what is a unknown timestamp [13:05] <DeadSix27> unknown format? [13:05] <JEEB> timestamp is a timestamp (usually there are two types, DTS and PTS -- decoding and presentation timestamp) [13:06] <DeadSix27> on toe other hand, which stream would be affected.. the audio or the video stream [13:06] <DeadSix27> the* [13:06] <JEEB> basically the time stamp of that AVPacket (no idea which, probably PTS?) is set to the value that means "unknown" [13:06] <JEEB> well, that error at least doesn't tell you which it is :P [13:06] <DeadSix27> :| [13:07] <DelphiWorld> yo JEEB [13:07] <DeadSix27> its the video stream [13:07] <DeadSix27> the first [13:08] <JEEB> DeadSix27, a) check if you're doing anything funky b) if you are, try to strip that out, and if you aren't, try to make a small sample and minimum command that can replicate it and check if the trac issue tracker says anything about it :P [13:08] <JEEB> you will either get told that your input sucks, or that you're doing something wrong, or that it's a bug in libavformat or libavcodec or whatever [13:08] <DeadSix27> then i see no reason to even visit the track [13:10] <JEEB> you ain't going to get either a reply that tells you that you're doing it wrong, or a possible bug fixed if you don't, though :P [13:10] <DeadSix27> (wasnt supposed to sound so bad) [13:10] <JEEB> just look at what you're doing and what's failing, and if you're doing anything weird [13:10] <JEEB> then start minimizing the way you're replicating it [13:10] <JEEB> both sample and command line wise [13:13] <DeadSix27> thing is just i have no idea wether the source is fine or not [13:13] <DeadSix27> since ffmpeg doesnt complain about it in any way, other than when i try to mix it with another aac stream [13:13] <DeadSix27> into mkfv [13:13] <DeadSix27> -f [13:14] <JEEB> well, if you have no idea then you can't really lose anything by poking the trac. In the worst case scenario someone will just hack up a bad workaround for it, which isn't pretty :P [13:14] <ayad_> if i add strict -2 my enconding is locked on 43 seco [13:15] <DelphiWorld> Salut ayad_ [13:15] <ayad_> salut [13:15] <DelphiWorld> ayad_: vous êtes un arab se que je voi, je supose:) [13:16] <ayad_> oui melange [13:16] <DeadSix27> btw JEEB: when i dont modify the source and try to mux right away: test.h264: Invalid data found when processing input [13:16] <DelphiWorld> ayad_: et je ponce pas que c'est du magreb, se nom c'est plus eastern... non ? [13:17] <DelphiWorld> et pluto la région du "Sham" [13:17] <ayad_> oui mix avec Afrique central [13:17] <DelphiWorld> ayad_: oh, tré bien;) [13:18] <DelphiWorld> ayad_: moi je suis un algériain, êsse que je peux vous aidé? [13:19] <ayad_> oui je cherche à encoder pour une chaine communautaire [13:19] <DelphiWorld> ayad_: je suis la mon ami [13:19] <ayad_> les images sont en .flv mais je souhaite l'encoder en .mp4 /pour le faire passer dans le tuyau adsltv en france [13:20] <saste> can ffmpeg act as an RTSP server? [13:20] <saste> or is ffserver required for that? [13:20] <saste> DelphiWorld, ^ [13:20] <DelphiWorld> saste: FFServer... [13:20] <DelphiWorld> saste: but question, why RTSP? [13:21] <saste> because I see Martin added an RTSP muxer to ffmpeg [13:21] <saste> DelphiWorld, I don't know, I'm just trying to see what works and what not [13:21] <DelphiWorld> saste, if i'm correct... i *THINK* -f rtsp is a outbound filter not inbound i (THINK!) [13:21] <saste> uhmm... [13:22] <DelphiWorld> ayad_: envoyé moi en privé svp [13:22] <saste> no there is also an output [13:22] <saste> it was written in 2010 [13:22] <saste> DelphiWorld, why not to use RTSP? [13:22] <DelphiWorld> saste: yes, -f rtsp rtsp://user:Pass@blabla... to push to an rtsp server like wowza [13:23] <ayad_> allo delphi [13:23] <DelphiWorld> saste: honestly, i prefer hls or http but not rtsp... rtsp is not widely supported but http is everywhere, even in mars [13:23] <DelphiWorld> ayad_: privé... messagerie privé:P [13:23] <ayad_> je veux bientot quitter le burau, on peu poursuivre par email? [13:23] <DelphiWorld> ayad_: oui, mais envoyé moi un message perso a se moman pour que je te le donne, je peux pas l'écrir en plain public:P [13:24] <saste> DelphiWorld, i still have that problem with HTTP, streams freeze [13:24] <DelphiWorld> saste: using ffserver? [13:24] <saste> it is probably due to TCP segmentation issue [13:24] <saste> DelphiWorld, yes [13:24] <ayad_> daya078atgmaildotcom [13:24] <DelphiWorld> saste: Q: are you trying to evaluate & fix or seeking for a solution? so i may help? [13:25] <saste> DelphiWorld, the same doesn't happen for example with ffmpeg => UDP => udpxy => HTTP [13:25] <saste> DelphiWorld, if you know some way to set the TCP maximum segment size on linux [13:25] <DelphiWorld> ayad_: voir [13:25] <saste> i tried with setsockopt() on the code and it doesn't help [13:26] <DelphiWorld> saste: but like i asked. you want this as a solution or you're trying ffserver for ffmpeg dev? [13:26] <ShorTie> mornin guys [13:27] <DelphiWorld> ShorTie: i'm shortFF not ShortIE:P [13:27] <DelphiWorld> saste: pm [13:27] <ShorTie> does configure --disable-doc disable building all the doc's ?? [13:28] <saste> ShorTie, that's what i would expect [13:29] <ShorTie> ok, thankz, didn't know if i had to do the other doc's too [13:29] <ShorTie> running out of room, just trying to make it a little smaller [14:07] <M75> test [16:06] <smallfoot-> Who are the jerks, ffmpeg or libav guys? [16:08] <ubitux> that's a really gracious to go in both channel and ask such question [16:09] <ubitux> do you really expect a meaningful answer? [16:09] <smallfoot-> yes, i thought it wud be a good idea to ask in both channels to get it unpartial [16:09] <smallfoot-> yeah [16:09] <smallfoot-> Why did libav fork ffmpeg? [16:10] <ubitux> ask them [16:10] <ubitux> the whole multimedia community is a jerk area, so your question makes no sense [16:10] <smallfoot-> Was it because they wanted all the credz and run the show, or was it because ffmpeg refused to modernize and accept patches and make awsm? [16:10] <smallfoot-> oh, didnt know [16:10] <ubitux> you should look at the technical differencies instead [16:11] <smallfoot-> Which is technically superior? [16:11] <ubitux> make your own judgment [16:13] <smallfoot-> im incompetent and cant make a meaningful comparision [16:13] <smallfoot-> i can maybe decide which has the coolest name [16:13] <ubitux> then i'd say you shouldn't listen to anyone telling you who are the good and bad guys [16:13] <smallfoot-> well someone must know better than me [16:13] <smallfoot-> i want whoever knows better than me (anyone) to tell me which is best [16:14] <ubitux> at best, you'll get ffmpeg biased answers here, and libav biased answers on the other channel [16:14] <ubitux> if you want a seemingly objective opinion, you need to ask a third party [16:15] <smallfoot-> hmm, i know no such third party [16:16] <smallfoot-> is Ubuntu ditching ffmpeg? because gstreamer 0.10 was built against ffmpeg, but 1.0 is built against libav [16:16] <ubitux> https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav [16:16] <ubitux> here is a third party [16:17] <smallfoot-> thanks [16:17] <ubitux> the reason ubuntu is packaging libav and not ffmpeg is because at the moment of the fork the maintainer of the package moved with the libav folks [16:18] <ubitux> as a result, the ffmpeg package became a libav package, as libav was meant to be a "replacement" for ffmpeg [16:18] <ubitux> they made the bet that ffmpeg would die after the fork; that didn't happen [16:19] <ubitux> there is RFP to have ffmpeg back here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 [16:19] <ubitux> (it's the same maintainer for debian & ubuntu) [16:19] <smallfoot-> ah, I see [16:19] <ubitux> afaik, the choice of libav in gst is an historical choice, but feel free to ask them [16:20] <smallfoot-> but why did the libav guys try to steal ffmpeg from Fabrice Bellard? isnt Fabrice Bellard internationally recognized as a pimp? [16:20] <ubitux> steal ffmpeg? [16:20] <smallfoot-> yeah [16:20] <ubitux> Fabrice hadn't contributed to FFmpeg since a while [16:20] <smallfoot-> the github link says that before they forked it into libav they tried to steal it but Fabrice Bellard refused to give up the domain name [16:20] <smallfoot-> oh I see [16:21] <ubitux> long story short, some developers were angry at the way it was (see the about page on libav.org) and decided to take over; it didn't work, so they forked [16:22] <smallfoot-> oki [16:22] <ubitux> Fabrice didn't say a word in the conflict [16:22] <smallfoot-> hmm i see [16:22] <ubitux> but the dns was controlled by FFmpeg developers not wanting the fork [16:22] <smallfoot-> he was probably too busy pimping dope code to be having time to listen to people whine [16:23] <ubitux> he's not contributing to FFmpeg since years [16:23] <smallfoot-> hes probably working on some magic stuff [16:24] <smallfoot-> the guy is a pimp wizard, he wrote ffmpeg, qemu, tcc, and took the world record in Pi calculation with his own algorithm [16:25] <ubitux> you forgot jslinux [16:29] <smallfoot-> yeah that [16:34] <rsaf> hello, i'm using FFMPEG to capture H264 rtsp stream to .mp4 file [16:34] <rsaf> and i have problem with keyframe [16:34] <rsaf> video starts gray until ffmpeg receives first keyframe... can you help me with this? [16:36] <rsaf> my command line: http://pastebin.com/Pu3K7SJ0 [18:15] <eMBee> good evening [18:15] <jnvsor> evenin [18:16] Action: eMBee is struggeling with a wierd behavior, when converting a specific file format it does not prompt to overwrite of the target already exists [18:16] Action: eMBee is trying to convert files from here: http://30c3.ex23.de/fahrplan_d1.html [18:17] <jnvsor> pastebin input/output? [18:17] <eMBee> just: ffmpeg -i file.mp4 file.webm [18:18] <jnvsor> and output? [18:18] <eMBee> hold on [18:18] <eMBee> pastong the output will tell you the fileformat, sec... [18:19] <jnvsor> most likely it's not even trying to transcode the file since you didn't stipulate any codecs [18:19] <maujhsn> Hello eMBee, v4l2-ctl tool...I want it to be able to read the parameters of a new webcam that I have hooked up! i.e "frame sizes / frame rates your camera supports"! I want to see the results on the command line [18:20] <eMBee> http://paste.lisp.org/display/140690 [18:21] <eMBee> it is transcoding but it should prompot, or, if i use -n just exit [18:21] <eMBee> it does that correctly if i use another file format, as input like some mkv i have laying around [18:22] <jnvsor> are you sure the output file already exists? [18:22] <eMBee> yes, i ran the same command multiple times [18:23] <eMBee> and every time the file gets overwritten [18:23] <jnvsor> try a simpler output filename like out.webm and see what happens [18:24] <eMBee> interesting, now it's asking... [18:24] <eMBee> so the output filename is causing problems, hmm [18:24] <jnvsor> I'd assume you have some token variable in there that's changing between commands [18:25] <eMBee> in the filename? then i would have multiple output files [18:25] <eMBee> there is only one and it gets overwritten every time [18:26] <eMBee> it looks more like there is a bug in the way ffmpeg handles the filename failing to read it correctly for checking [18:27] <jnvsor> downloading the file to try it myself [18:27] <eMBee> and i just tested it with other input files but the same long output name, same problem [18:28] <eMBee> don't need to download anything, just try that filename as a target [18:28] <eMBee> the input format seems unrelated [18:28] <jnvsor> well I need an input either way so I might as well download it [18:29] <eMBee> of course :-) [18:30] Action: eMBee just figured, being active in this channel, you might already have some videos laying around :-) [18:33] Action: eMBee was hoping to just run find -name "*.mp4" -exec ffmpeg -n -i \{\} \{\}.webm \; in a loop to convert any new files while those are being mirrored, so that by morning all is mirrored and converted [18:34] <jnvsor> Might be able to write a bash loop around that that just numbers them [18:34] <jnvsor> Think it might be the length of the output file name, but it's not aligned to any power of 2 [18:35] <jnvsor> No, it's the escaped colons [18:35] <jnvsor> don't know why but they're messing it up [18:36] Action: eMBee nods [18:36] Action: eMBee just found that too [18:37] <jnvsor> Ah I see [18:37] <jnvsor> ffmpeg handles more than just files - it can output to rtmp streams for instance [18:37] <jnvsor> so when it hits a colon it assumes it's a protocol rather than a file [18:38] <jnvsor> giving it the file:// protocol doesn't help either - if I were you I'd just strip the colons [18:39] <eMBee> well, need to find a way to do it. can't strip them from the input as that breaks mirroring [18:40] <jnvsor> Ah better idea, wait a moment [18:41] <jnvsor> Nope - quoting it doesn't work either heh - tried stripping them from output before running the command? [18:41] <jnvsor> Mind you, I'll report this to ffmpeg's trac [18:42] <jnvsor> but anyway, if it's supposed to be automatic wouldn't overwriting automatically be the way to go? [18:43] <eMBee> well, the idea is if the target already exists it's already converted, so that file is done [18:46] <eMBee> the easiest will probably be a small shell script that cleans the output name and then call that from -exec in find [18:46] <jnvsor> I'd just list the files, stick that in an array, bash loop over it and process the output after parsing the filenames [18:52] <eMBee> well, the list keeps changing as the mirror is updated, so that's not practical [18:53] <jnvsor> I mean you make a list when the program runs - check for duplicate file names (minus the extension) and leave them out [18:53] <eMBee> anyways, i got that small script working, it's just: in=$1; out=${1//:/-}.webm; ffmpeg -n -i $in $out [18:53] <jnvsor> works too [18:54] <eMBee> yup, thanks for your help [18:54] <eMBee> let me know the trac id of that report, i am curious to follow... [18:54] <jnvsor> https://trac.ffmpeg.org/ticket/3249 [18:58] <eMBee> hmm, if ffmpeg interprets the filename as a protocol, it should fail because that protocol does not exist, or can't be accessed, or it should treat it as a normal filename (which it does) and then behave like file:// [19:00] <esing> Hi, why is copying the audio codec from an mp4 video file not working: ffmpeg -i video.mp4 -codec:a copy -vn copy.mp3 ... I get this error: mp3 @ 0x110d160] Invalid audio stream. Exactly one MP3 audio stream is required. [19:03] <esing> Maybe because the mp4 file's audio stream is AAC and that doesn't fit in mp3, hence I have to use ffmpeg video.mp4 -b:a 192K -vn audio.mp3 for mp4 [19:23] <jnvsor> esing: Sounds like your mp4 file has more than one audio track, pick one with -map [19:41] <jacob___> hi [19:41] <jacob___> I am a problem in my video that my sound is to low in volumen [19:41] <jacob___> how can i 'normalize' sound with ffmpeg? [19:41] <esing> mediainfo of video.mp4: http://sprunge.us/DjVJ error message: http://pastebin.com/nLWueC7T [19:47] <esing> Using .aac instead of .mp3 then -codec:a copy works [19:48] <jnvsor> Yeah cause it's aac audio codec, mp3 containers don't handle that codec [19:52] <esing> Looks like .mp4/.3gp/.flv always use .aac codec for their audiostreams on youtube. Just .webm uses vorbis (.ogg). [19:53] <DeadSix27> thats because webm only supports opus and vorbis. [19:54] <lkiesow> jacob___: http://ffmpeg.org/ffmpeg-filters.html#volume [19:54] <DeadSix27> esing: http://en.wikipedia.org/wiki/Comparison_of_container_formats [19:55] <lkiesow> The volume filter may be what you are searching for [19:55] <esing> Thanks for the link [19:57] <DeadSix27> for storing id go for mkv. [19:57] <mark4o> jacob___: first pass use -af ebur128 to check integrated loudness, second pass use -af volume=+3dB or whatever number is needed to bring it to -23dBFS or whatever volume level is desired [19:58] <mark4o> jacob___: there is a python script in tools/normalize.py that does it but it may need to modified for your use case [20:33] <jacob___> Id ont get it [20:33] <jacob___> i have a video with 1 hour of sound and a background pic (static) [20:33] <jacob___> but it is 700mb, something very wrong here [20:33] <jacob___> how can i improve this (mp4 file) [20:33] <jacob___> audio pcm_16 streame 44khz [20:34] <jacob___> wait i show output of ffmpeg about this file [20:35] <jacob___> http://pastebin.com/3DyvcvaX [20:36] <jacob___> how can i compress this,.., there is basicly no video movement just background image with spoken voice text, not even music [20:38] <jacob___> I can i see/detect that my video mp4 file is oversampled [20:39] <jacob___> and decrease bitrate without loosing quality, [20:44] <lkiesow> jacob___: If it is just a static picture, but you still want to keep it, you could decrease the framerate and maybe also increase the gop value [20:44] <jacob___> what is gop? [20:44] <lkiesow> the amount of frames to the next keyframe [20:45] <jacob___> cool [20:46] <jacob___> so , imagine i made a mjpeg (motion jpeg) video where every frame is a keyframe, so if i introduce a GOP, i can reduce the size significantly? [20:46] <jacob___> coolzzz [20:46] <jacob___> you ahve a commandline for this [20:46] <jacob___> ? [20:48] <lkiesow> As there are only keyframes, the gop size is practically alwasy 1 and you cannot modify it. This option only works if you have partial frames in between keyframes [20:48] <jacob___> lkiesow: ok,.,so how do i make the latter happen [20:49] <jacob___> how do i go from a situation where every frame is a keyframe to partial keyframes interleaved with keyframes [20:49] <lkiesow> If you still want to use mjpeg you can just decrease the framerate. [20:49] <lkiesow> Use a different video codec [20:49] <jacob___> nah, mjpeg was for archiving,.., [20:49] <lkiesow> At the moment, I would go for h264 [20:49] <jacob___> sure,, H264 looks good to me [20:49] <lkiesow> Use something like: [20:50] <lkiesow> ffmpeg -i input -c:v libx264 -r 1 -g 60 out.mp4 [20:50] <lkiesow> for the video [20:51] <jacob___> ok, for now i only copy the audio and deal with that later [20:51] <lkiesow> -r 1 meas that there is only 1 frame per second [20:51] <jacob___> ok [20:51] <lkiesow> -g 60 means that every 60th frame is a keyframe [20:51] <lkiesow> meaning you will get 1 keyframe per second [20:51] <jacob___> so i could do something like -r 60 -g 60 [20:52] <jacob___> that means 60 fms and keyframe every second? [20:52] <jacob___> cool [20:52] <jacob___> 60 fps and 1 keyframe ps [20:52] <lkiesow> yes [20:52] <jacob___> cool [20:52] <jacob___> i try this)) [20:52] <jacob___> moment [20:53] <lkiesow> But why do you want 60 frames a second? [20:53] <jacob___> oh ah 50? [20:53] <jacob___> whats they human eye, can only do 60 fps? [20:54] <jacob___> i forgot, i had a tv once (non flatscreen) , it had 100 fps [20:54] <jacob___> crips picture [20:54] <lkiesow> normal movies have about 25-30 fps [20:54] <lkiesow> The Hobbit has a revolutionary amount of 48fps :) [20:55] <jacob___> why did i double it? mmm maybe my brain is still on interlaced [20:55] <jacob___> haha [20:55] <jacob___> Hobbit? lol,.., i thought starwars was the cats wiskers [20:55] <jacob___> with all the fancy explosions and quick action [20:56] <lkiesow> :) [20:56] <lkiesow> But didn't you say that you do have a still image as video? [20:56] <lkiesow> Then why use a high frame rate? [20:57] <jacob___> lkiesow: yeah [20:57] <jacob___> i was thinking about other vid, [20:57] <jacob___> you right, sorry for confusion not providing context,.., [20:57] <lkiesow> In theory you could use one frame that last for the whole movie. Though a lot of players do not like that and fail if you try to seek [20:57] <lkiesow> ah, ok ^^ [20:58] <jacob___> yes, the seek is a problem,.., if they want to fast forward they end up with crap [20:58] <LithosLaptop2> any movie going past 24fps looks very cheesy to me [20:58] <jacob___> so 1 frame per second is good idea [20:58] <jacob___> http://pastebin.com/6Y9cbCkV [20:58] <jacob___> i ran a volume detect on my audio [20:58] <jacob___> ^^ [20:58] <jacob___> ok,.., i will try your command line now [21:44] <jacob___> lkiesow: fucking hell, the size dropped from 800 mb to 127 mb [21:45] <jacob___> thanks alot man [21:45] <jacob___> I have a lot of lecture videos that are way to "fat".., just a guy talking with near static background,.., nice trick you have.. [21:48] <jacob___> lkiesow: i want to use your filter loudness [21:48] <lkiesow> jacob___: May I ask what lecture videos you have? I'm curious because I'm an Opencast Matterhorn developer which is a lecture recording system :) [21:49] <jacob___> standford, coursera,.., some german universities, when i download them,.., they are way to freakin big for just talking in front of a blackboard [21:50] <lkiesow> Ah ok, though maybe you produce them youself& which German universities? ^^ [21:50] <jacob___> these professors are just recording stuff ad-hoc (classroom etc) I think they dont have your experties yet [21:51] <jacob___> Buch university, (Cryptography course, 22 vids) [21:51] <jacob___> MOOC is in its infancy [21:54] <lkiesow> We do that, too. They are being recoded automatically. They don't have to do anything. Everything else does not work execpt for very few lecturers who are in that topic. And you would have to spend a lot of time and money. This semester we produce exectly one pure MOOC. Everything else is lecture recording. But the good point is that a lot of universities start producing right now [21:55] <JEEB> we've had mooc at cs.helsinki.fi now for two or so years :) And we got a program where some of the people who did two specific courses through the MOOC can get in officially [21:56] <JEEB> so yeah, many places are starting to provide MOOC education :) [21:56] <jacob___> MOOC is cool, they should apply the itunes /appstore business model, $1.99 for a course,., but they can sell to millions of people [21:57] <jacob___> everybody can go to Harv/Stanford..., .. labwork is going to be problem, but with todays cheapmaterials a lab is not that hard compared to a years tution pay [21:57] <jacob___> tuition* [21:59] <lkiesow> The thing is that especially the US universities use the MOOCs as advertising material. They don't get much out of it, but their reputation increases. So people want to study there and pay for that [21:59] <jacob___> lkiesow: about the audo,.., what is the meaning of mprobe.exe what is that? [21:59] <jacob___> Standford had 2 courses MOOC credited by ACE [22:00] <jacob___> of course , i would feel cheated if someone could do same course online as i was paying 25k for brick and morter uni) [22:00] <jacob___> so i think big unis will go slow, but due to compitition we will see big shifts in future [22:03] <lkiesow> Well, most no-MOOC-recodings are for their students only and you will not get access to them if you are not a student at a specific university. We have 1 or 2 open courses a semester, but really record ~25 (Actually, I don't really know. I don't have to deal with that :) [22:04] <lkiesow> Mancester for example recods nearly every single couse [22:04] <lkiesow> They have about 60.000 recordings per semester :) [22:04] <lkiesow> And everything is processed by FFmpeg :D [22:05] <theholyduck> speaking of recorded classes [22:05] <theholyduck> https://sites.google.com/site/northwesternlightboard/home [22:05] <lkiesow> jacob___: Where did you get the mprobe.exe from? [22:05] <theholyduck> this guy has the best technique ive seen [22:05] <jacob___> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-March/141071.html [22:05] <theholyduck> i love his live, 1 shot, no post processing [22:05] <theholyduck> all physical effects [22:05] <theholyduck> approach to recording it [22:09] <jacob___> fucking heel,.., aweosme [22:10] <jacob___> theholyduck: awesome^2 [22:10] <jacob___> and its open source hardware too)) [22:10] <jacob___> great guy [22:10] <theholyduck> jacob___, well, he is a mechanical/electrical engineer [22:10] <lkiesow> There is no mprobe in that mail [22:10] <theholyduck> not a software one [22:10] <theholyduck> jacob___, and so he found a way to do everything physically [22:10] <theholyduck> and in one shot :P [22:10] <theholyduck> jacob___, the results are pretty stunning aswell [22:10] <jacob___> ffprobe [22:10] <jacob___> oops [22:12] <jacob___> dont know how is does correct for mirror image while facing the camera [22:12] <jacob___> doesnt make sense, [22:12] <jacob___> i bookmarked his page, thanks for the tip, theholyduck [22:13] <theholyduck> jacob___, if you read the rest of the pages [22:13] <theholyduck> you see he uses a mirror [22:13] <theholyduck> and records through it [22:14] <theholyduck> + uses a polarizer filter to hide the monitor he uses to see what he is doing in [22:14] <theholyduck> its all very wellw ritten up [22:15] <jacob___> what i mean is,.., sure you can make it look good for viewer [22:15] <jacob___> but think about it [22:15] <jacob___> if his had is writing in upper left corner, [22:15] <jacob___> hand* [22:16] <lkiesow> ah, ok. That was also the first thing I thought of: You have to write mirrored. But if it is for video only, I think it is a great ide [22:16] <lkiesow> Might as well try it out :) [22:16] <jacob___> if he flips mirror so we see it ok,.., but the letters start in upper right corner [22:16] <theholyduck> lkiesow, he writes the right way around [22:16] <theholyduck> but FILMS in the mirror [22:16] <theholyduck> so [22:16] <theholyduck> it comes out looking normal [22:16] <jacob___> oh wait [22:16] <theholyduck> cause the mirror flips it back [22:16] <jacob___> you dont see him writing only the text? [22:16] <jacob___> i mean you dont see they guy himself [22:16] <theholyduck> jacob___, you do [22:17] <theholyduck> look at the video [22:17] <theholyduck> on the first page [22:17] <theholyduck> i have to go now [22:17] <jacob___> doesnt make sense, you cant mirror his arm, [22:17] <jacob___> position, sure you can mirror the fluecense text but not NOT mirror his arm [22:17] <jacob___> at the same time [22:18] <lkiesow> I guess it does not matter if he is mirrored in the recording, does it? [22:18] <lkiesow> What was your problem with ffprobe [22:18] <jacob___> it would look weird [22:18] <jacob___> you see his arm left but letters appear right [22:18] <jacob___> lol [22:19] <jacob___> i dont see loudness filter used in ffprobe [22:20] <jacob___> i see something like this "ebur128=metadata=1" [22:20] <lkiesow> No, ffprobe is just for media analysis. You can use it to get the mean loudness of your audio. Then you can adjust it to a specific value [22:20] <lkiesow> using ffmpeg in the next step [22:20] <jacob___> how do i do that? [22:20] <jacob___> do you have example without all the fuzzyness in the script? [22:21] <lkiesow> If you just want to make it louder, you don't need ffprobe at all. Do you want that? [22:23] <jacob___> yeah, but how much louder, would i run the risk of over amplyfying? [22:23] <jacob___> and some parts of the video have loadness x and other parts loudness y (my ears detected it) , how do i normalize at one level [22:26] <lkiesow> Ah, ok. The volume filter will just increase/decrease the volume of the whole audio stream. [22:27] <lkiesow> I guess for what you want to do, you could try the compand filter: http://ffmpeg.org/ffmpeg-filters.html#compand [22:27] <lkiesow> Maybe even together with the volume filter. [22:28] <lkiesow> Hm, just looking at the first example [22:28] <lkiesow> That could help. But I'm just guessing [22:28] <jacob___> ok,, ia m looking aswell,.., not making much sense to me.., not media wizz, sorry [22:29] <lkiesow> Well, just try it out :) [22:31] <lkiesow> ffmpeg -i input -filter:a 'compand=.3 .3:1 1:-90/-60 -60/-40 -40/-30 -20/-20:6:0:-90:0.2' out.mp4 [22:31] <lkiesow> Or something like that [22:32] <jacob___> ok [22:32] <jacob___> i try [22:34] <jacob___> Unrecognized option '60/-40'. Error splitting the argument list: Option not found [22:34] <jacob___> ^^ lkiesow [22:34] <jacob___> something is wrong? [22:35] <lkiesow> Try using " instead of ' [22:35] <jacob___> i did, already [22:35] <jacob___> tanks [22:36] <lkiesow> Did that work? [22:36] <jacob___> its running now,,,,see what happens [22:37] <lkiesow> If the volume is to low in general afterwards you could try to prepend the volume filter: [22:38] <lkiesow> ffmpeg -i input -filter:a "volume=volume=1dB,compand=.3 .3:1 1:-90/-60 -60/-40 -40/-30 -20/-20:6:0:-90:0.2" out.mp4 [22:38] <lkiesow> And adjust the 1dB [22:38] <jacob___> volume=volume=1dB [22:38] <jacob___> ok [22:44] <jacob___> can ffmpeg be GPU accelerated? [22:44] <jacob___> my cpu is maxed out 100% [22:59] <jacob___> lkiesow: sounds good [22:59] <jacob___> i will try the option volume=1db, see what makes diff [23:30] <jacob___> lkiesow: i got NO SOUND on the last run,.., [23:30] <jacob___> no volume [23:36] <lkiesow> hm& just had a look at the normalize script: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=tools/normalize.py;h=e015913… [23:36] <lkiesow> Seems like they use ... -filter:a "volume=1dB,... [23:37] <lkiesow> So maybe there is an error in the docs [23:39] <lkiesow> No its not& it does not matter how you write it. Could you try [23:40] <lkiesow> ffmpeg -i input -filter:a "volume=+5dB,compand=.3 .3:1 1:-90/-60 -60/-40 -40/-30 -20/-20:6:0:-90:0.2" out.mp4 [00:00] --- Sat Dec 28 2013

1 0

ffmpeg-devel.log.20131226
by burek 27 Dec '13

27 Dec '13

[00:13] <cone-705> ffmpeg.git 03Michael Niedermayer 07master:e33b6ccfa782: avformat/mpc8: clear buffer padding area [00:13] <cone-705> ffmpeg.git 03Michael Niedermayer 07master:26ce266e3df8: avformat/mpc8: check avio_read() return in mpc8_parse_seektable() [00:21] <cone-705> ffmpeg.git 03Diego Biurrun 07master:bd0fba87972b: configure: Explicitly disable w32threads if the test for it fails [00:21] <cone-705> ffmpeg.git 03Michael Niedermayer 07master:f371a4a57d48: Merge remote-tracking branch 'qatar/master' [02:00] <cone-705> ffmpeg.git 03Michael Niedermayer 07master:1486ed0815a1: avcodec/shorten: clear bitstream buffer [04:36] <cone-705> ffmpeg.git 03Michael Niedermayer 07master:4e394a98f2ea: avformat/rmdec: check against mismatching int4 interleaver parameters which would leave uninitialized holes [04:36] <cone-705> ffmpeg.git 03Michael Niedermayer 07master:165f96cd2d68: avformat/rmdec: move packet allocation down [07:54] <ubitux> any simd trick to >> 3 signed bytes? [07:58] <ubitux> 3 avg per zero? [11:47] <cone-149> ffmpeg.git 03Stefano Sabatini 07master:e2b54464c6a9: lavu/opt: fix range check logic in set_format() [11:47] <cone-149> ffmpeg.git 03Stefano Sabatini 07master:1575a96b3af5: lavu/opt: factorize setting of format values from string [11:47] <cone-149> ffmpeg.git 03Stefano Sabatini 07master:55f046be1193: lavu/opt: apply range checks also when setting format string value [11:47] <cone-149> ffmpeg.git 03Stefano Sabatini 07master:3b8c7da7a36d: lavu,lavfi,lavd: do not hardcode AV_PIX_FMT_NB value when setting pixel format max value [11:47] <cone-149> ffmpeg.git 03Stefano Sabatini 07master:334e2e236383: lavu,lavc,lswr: do not hardcode AV_SAMPLE_FMT_NB value when setting sample format max value [11:47] <cone-149> ffmpeg.git 03Stefano Sabatini 07master:cd355d4d5966: lavfi/abuffersrc: use AV_OPT_TYPE_SAMPLE_FMT for sample_fmt option [13:36] <cone-149> ffmpeg.git 03Luca Barbato 07master:1716b4c7b888: mms: Remove non-utf8 characters [13:36] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:6b36f577a12a: Merge remote-tracking branch 'qatar/master' [13:49] <cone-149> ffmpeg.git 03Clément BSsch 07master:ec73bd1fe876: avfilter/avectorscope: fix {} mistake in alloc check. [13:52] <ubitux> avectorscope is really beautiful& [14:01] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:14bec7dcf829: avcodec/wnv1: clear padding area of rbuf [16:20] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:d164ad3298c1: avcodec/ivi_common: use av_mallocz() to allocate mbs array [16:20] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:635987287726: avformat/oggparseogm: check input size before reading parameters [16:22] <ubitux> is there anyone from ffmpeg going to fosdem this year? [16:22] <ubitux> i mean, is the project represented? [19:34] <Daemon404> hmm cool [19:34] <Daemon404> filter-volume is crashing on icl [19:35] <nevcairiel> its icl [19:35] <nevcairiel> color me surprised [19:35] <Daemon404> nevcairiel: miscompilation? [19:35] <Daemon404> i can maybe move to icl14 and see [19:35] Action: Daemon404 has it too [19:36] <nevcairiel> over-optimization is the term i would use [19:36] <nevcairiel> but sure [19:41] <saste> Daemon404, can you provide a gdb backtrace [19:42] <Daemon404> uh [19:42] <Daemon404> icl != gdb [19:42] <nevcairiel> can you provide a msvc backtrace? [19:42] <nevcairiel> :D [19:42] <Daemon404> ;) [19:42] <Daemon404> its a miscompilation im sure, so it will be asm [19:44] <Daemon404> i will poke it in a bit [19:44] <Daemon404> too busy playying snes. [21:42] <ubitux> BBB: any trick for a simd signed >> 3? (and >>4) [21:42] <ubitux> byte-wise [21:42] <ubitux> doing with avg is going to be painful [21:42] <ubitux> (or maybe not?) [21:45] <iive> ubitux: is there signed byte multiply that returns only the high part? [21:46] <iive> the high part would be like >>8, so you do <<5 by using a constant. [21:47] <ubitux> mul & shift are word and larger [21:48] <iive> not useful then. are you doing sse2 or 3,4... [21:49] <ubitux> no constraint so far [21:49] <ubitux> sse2 & 3 are fine, dunno if i need 4 [21:49] <ubitux> i might not even need 3 [21:51] <ubitux> right now i was doing the pavgb(pavgb(pavgb(x+1)+1)+1) [21:51] <ubitux> but i realized it will only work for unsigned [21:52] <ubitux> i was considering doing the unpack, doing it word wise, and the repack [21:52] <ubitux> but hey, i'm short in registers :( [21:53] <iive> so, no register to keep the sign? [21:53] <ubitux> well i guess i can do it [21:53] <ubitux> ideally i'd like to use only 2 registers [21:54] <ubitux> which was enough for the pavgb thing [21:54] <ubitux> i guess i can go up to 3 though [21:54] <iive> yes, cmp for the sign, shift >>3 for the data shift <<5 for the sign and or. [21:55] <iive> should be faster than doing 3 interdependent instructions. [21:55] <ubitux> well i'll see later [21:55] Action: ubitux & [21:56] <Daemon404> fg [22:00] <michaelni> ubitux, add 128 to each byte, do a shift, mask and subtract 16 from each byte [22:32] <iive> that was the first thing i thought, but that would need 2 different constants. [22:33] <iive> i also wasn't sure if there might be small difference in rounding. [00:00] --- Fri Dec 27 2013

1 0

ffmpeg.log.20131226
by burek 27 Dec '13

27 Dec '13

[00:41] <mark4o> kirbir: overlay a png that is black with a transparent circle in the middle where you want to see the video [00:43] <kirbir> mark4o: Thank you very much! [01:14] <DeadSix27> when you're skipping and it doesnt skip to exactly the position you actually wanted it to go to [01:14] <DeadSix27> thats done by keyframes right? [02:31] <DeadSix27> does that mean, what i believe it means: x264 [error]: malloc of size 30690048 failed [02:37] <DeadSix27> (apparently it does mean what i thought it means, kinda still used 32bit ffmpeg. 64bit one works fine now.) [12:14] <DeadSix27> what the heck is this: https://code.google.com/p/x265/downloads/detail?name=ffmpeg-patched.rar&can… [12:20] <spaam> ffmpeg-patched.rar [12:21] <spaam> everyone want to use x26N name! [12:21] <DeadSix27> 4khd is a pain for my setup [12:22] <DeadSix27> encoding wise [12:22] <DeadSix27> 1,7fps [12:23] <DeadSix27> look at the time (30s of 5m) gives me headache [12:23] <DeadSix27> looking* [12:29] <JEEBsv_> DeadSix27: that's a project started by a guy who had a couple of commits in 2004 in x264, and he seems to be working for MCW now [12:29] <JEEBsv_> at MCW they have the 'real' x265 project [12:29] <JEEBsv_> https://bitbucket.org/multicoreware/x265/wiki/Home [12:30] <JEEBsv_> also if you look at the part "compatible with HM X.x" you should see that you should not use any time with that thing ;) [12:30] <JEEBsv_> because only since HM 10.1 the streams that would be output would be compliant to the final specification :) [12:31] <JEEBsv_> thanks to smarter there also is a decoder for HEVC/H.265 in libavcodec already [12:41] <DeadSix27> ah [12:41] <DeadSix27> thanks for the info [12:42] <JEEBsv_> also x265 doesn't really have much to do with x264 :) [12:42] <JEEBsv_> it's basically HM's encoder and MCW got the rights to the name and the right to use the double-licensed code from x264 [12:42] <DeadSix27> ye just wondered [12:43] <DeadSix27> i googled info about x265 and ffmpeg [12:43] <DeadSix27> and that came up [12:43] <DeadSix27> main reason was, that ffmpeg has no 8k hd support [12:43] <DeadSix27> i mean x264* [12:43] <JEEBsv_> why not? [12:44] <DeadSix27> i tried, gave me errors [12:44] <JEEBsv_> the only thing you might hit is the 32bit memory limit with the defaults methinks? [12:44] <DeadSix27> nope got 64 [12:44] <JEEBsv_> can you post what exactly you got? [12:44] <DeadSix27> sec. [12:44] <JEEBsv_> because x264 at least should not have a problem [12:44] <JEEBsv_> pastebin, please :) [12:44] <JEEBsv_> not onto the channel itself, since logs tend to be longer :) [12:44] <DeadSix27> yep i know [12:47] <dannyzb> I convert videos for online streaming , and I want to create high-quality while using reasonable CPU .. my current conversion is : [12:47] <dannyzb> /usr/bin/ffmpeg -i $source_path -x264opts bitrate=1280:vbv-maxrate=1280:vbv-bufsize=640 -s 1280x720 -refs 4 -vcodec x264 -acodec libfdk_aac -ab 164k [12:48] <dannyzb> what would be the equivalent in crf value ? [12:48] <dannyzb> btw I use the veryfast preset [12:48] <JEEBsv_> there's no 'equivalent', basically the idea with crf is that you select the highest value that still looks good for you. Start with 23 [12:49] <JEEBsv_> and then go higher if it looks good [12:49] <JEEBsv_> lower if it looks bad [12:49] <JEEBsv_> also are you sure of those vbv values? [12:49] <JEEBsv_> you have 0.5 seconds of buffering there [12:49] <dannyzb> should i increase it? I don't even know what it means [12:49] <DeadSix27> JEEBsv_: can't reproduce what i did last night [12:49] <JEEBsv_> dannyzb: ugh [12:49] <DeadSix27> JEEBsv_: gives me malloc erros today [12:50] <DeadSix27> JEEBsv_: in which unit does x264 show those errors? [12:50] <dannyzb> I want to reach a similar bitrate , but a bit higher for action and lower for animation , which i thing crf would do [12:50] <dannyzb> JEEBsv_ : it works and it works well , it's well tested for conversion [12:50] <dannyzb> just uses too high quality for animation and it's not good enough for high-pace action [12:51] <JEEBsv_> dannyzb: basically -- you set maxrate for the minimum transfer speed that you want to support, and bufsize is then how much the player-side should buffer [12:51] <JEEBsv_> if you want to think of the buffering in seconds, you set bufsize to maxrate times seconds [12:51] <JEEBsv_> what you've set right now is *very* limiting [12:51] <dannyzb> limiting in what sense? [12:51] <DeadSix27> JEEBsv_: thats close to what i did yesterday: http://pastie.org/private/xlqiqaiicijpw3rtylglq [12:52] <dannyzb> anyway , i would rather use CRF instead of bitrate/maxrate .. due to the problems i noted [12:52] <JEEBsv_> ... [12:52] <JEEBsv_> you should _always_ use VBV if you are operating through a limited pipe [12:52] <JEEBsv_> ALWAYS [12:52] <JEEBsv_> you're just limiting it bad [12:53] <JEEBsv_> and yes, VBV can be used together with CRF [12:53] <dannyzb> man don't be rude .. i'm asking a question [12:53] <dannyzb> if I knew I wouldn't need help [12:53] <JEEBsv_> I'm not being rude, I'm trying to teach you :) [12:54] <relaxed> dannyzb: write a bash script to create a series of samples using a crf range and see what works best: for -i in {16..22}; do ffmpeg -i input -t 20 -crf "$i" output_crf_"$i".mkv; done [12:54] <relaxed> of course, add your other libx264 options [12:54] <dannyzb> "Depends on the profile level of the video being encoded. Set only if you're encoding for a hardware device." thats the documentation for vbv-bufsize [12:55] <JEEBsv_> ffmpeg -i hurrdurr.input -crf 23 -maxrate <minimum transfer rate you want to support>k -bufsize <maxrate * seconds of buffer>k -vf scale=1280:720 -c:v libx264 -c:a libfdk_aac -b:a 192k out.file [12:55] <relaxed> listen to the JEEBsv_ [12:55] <relaxed> er, the should be "for i", not "for -i" [12:56] <JEEBsv_> dannyzb: basically what it means is that you use it when you have something bandwidth-limited in the mix. One thing is strict pieces of hardware, the other is... network, for example! [12:56] <dannyzb_> what did you say ? I had a disconnect -_- [12:56] <JEEBsv_> 13:55 < JEEBsv_> ffmpeg -i hurrdurr.input -crf 23 -maxrate <minimum transfer rate you want to support>k -bufsize <maxrate * seconds of buffer>k -vf scale=1280:720 -c:v libx264 -c:a libfdk_aac -b:a 192k out.file [12:57] <JEEBsv_> 13:56 < JEEBsv_> dannyzb: basically what it means is that you use it when you have something bandwidth-limited in the mix. One thing is strict pieces of hardware, the other is... network, for example! [12:57] <sgfgdf> hello, guys! i'm trying to change the language of audio/video streams. i'm using this -- `ffmpeg -i in.mp4 -c:a copy -c:v copy -metadata:s:0 language=eng -metadata:s:1 language=eng out.mp4' which works, but i'm curious if i can do it without making separate file. is it possible? [12:57] <JEEBsv_> basically it means that if the user has at least maxrate amount of bandwidth, and buffer bufsize amount of data, the user will never have to buffer again [12:57] <dannyzb> isn't bufsize client-size in streaming ? what effect does it have on encoding format ? [12:57] <JEEBsv_> so you _need_ it for network streaming [12:58] <JEEBsv_> dannyzb: it limits the encoder so that you _know_ that's all you need to buffer [12:58] <relaxed> sgfgdf: I don't think so [12:58] <JEEBsv_> if you just put crf for example, it will never be limited [12:58] <JEEBsv_> crf + vbv is basically limited CRF, if the rate goes over your set VBV limits [12:58] <dannyzb> ah ok so it limits the size [12:59] <dannyzb> I think i may actually want to give freedom to CRF without maxrate [12:59] <JEEBsv_> you are doing "online streaming" [12:59] <JEEBsv_> I don't think so [12:59] <dannyzb> if a video is too high quality i would rather the bitrate rises [12:59] <relaxed> so bump maxrate up a little [12:59] <dannyzb> I do HTTP pseudo-streaming , not true streaming .. it's reasonable to have slower loads on super-high-quality [12:59] <relaxed> you still need it [13:00] <JEEBsv_> without VBV (maxrate/bufsize) you cannot say anywhere that you only need a connection X and Y amount of buffering [13:00] <dannyzb> so you're saying just to set it really high [13:00] <dannyzb> if i get you right [13:00] <JEEBsv_> no, you set it to the levels you want to support from the users' connection wise [13:00] <dannyzb> and lower-quality videos would have low bitrates anyway bcs of crf [13:00] <sgfgdf> relaxed, ah, okay thank you! [13:01] <dannyzb> if a user doesn't have a fast enough connection for HD video , he can just wait [13:01] <dannyzb> doesn't concern me [13:01] <dannyzb> basically I want the bitrate to be relative to video complexity [13:01] <JEEBsv_> yes, that's what CRF more or less does [13:02] <JEEBsv_> well, you can just set the VBV in a way that needs a higher speed then, it's still recommended to have a known limit that should enable the person to play the video with specific amount of buffering once [13:02] <JEEBsv_> of course if you're not really streaming you aren't as limited :P [13:02] <dannyzb> I still don't get the vbv-bufsize thing .. what buffer is it exactly? what difference does it make to encoding ? (different movie atom ? ) [13:03] <dannyzb> or is it just a recommendation to the video player running the video [13:03] <JEEBsv_> don't consider maxrate and bufsize separately [13:04] <JEEBsv_> in simple terms it means that the stream is encoded so that if the user buffers bufsize amount of bits, and has at least a transfer speed of maxrate, the user will never have to buffer again [13:04] <JEEBsv_> the information generally isn't encoded into the stream so the player side has to be just set accordingly [13:04] <JEEBsv_> when they both match, all works beautifully [13:05] <dannyzb> oh so basically it changes to bitrate [13:05] <dannyzb> maxrate is the maximum bitrate at every frame [13:05] <JEEBsv_> no [13:05] <JEEBsv_> maxrate is the maximum rate _over_ bufsize [13:05] <dannyzb> ooohhhhh [13:05] <dannyzb> ok [13:06] <JEEBsv_> basically average rate over bufsize will never go over maxrate [13:06] <dannyzb> so higher is much better fitting for action movies [13:06] <dannyzb> where you suddenly have 2-3 seconds of high-speed action [13:06] <dannyzb> spread over 20 seconds makes more sense [13:06] <iive> how does max-rate relate with the bitrate of the communication channel? [13:07] <JEEBsv_> iive: it just makes sure that maximum data rate of the video stream doesn't go over set maxrate over a set bufsize [13:07] <dannyzb> wouldn't a really high vbv-bufsize increase encoding time ? ( since it needs to reencode previous frames sometimes to fit the block ) [13:07] <JEEBsv_> so you can make some decisions [13:07] <JEEBsv_> regarding what kind of connections you want to support [13:08] <JEEBsv_> dannyzb: no -- x264 actually pretty much never has to re-encode the frame to fit into vbv [13:08] <Jellicent> Hey guys, I've been struggling with these little problems for a while now... I'm trying to stream to twitch but the volume is very low. Not the volume of me talking, I'm not recording my voice. But for instance, the ingame sounds or the music I'm listening to. Also, sometimes some frames are skipped. But the main problem is the sound.. I'm using ALSA on Arch Linux, I tried boosting all values to max, no [13:08] <Jellicent> changes.. [13:08] <JEEBsv_> it already during the encode of a frame tries to make it fit the left bits in VBV [13:08] <Jellicent> Damn it! :p [13:08] <dannyzb> ok so using a low value is stupid i guess , makes action scenes blocky [13:08] <dannyzb> thanks [13:09] <dannyzb> btw does crf 21 sound reasonable to you ? [13:09] <JEEBsv_> yes, but do make sure you actually found a value that is the highest that still looks good for you [13:09] <JEEBsv_> and then just decide on the connections you support with minimum buffering :D [13:09] <JEEBsv_> and set maxrate and bufsize accordingly [13:10] <JEEBsv_> (and possibly modify your players in a similar way) [13:10] <dannyzb> yea .. I'll do that [13:10] <dannyzb> btw whats the lowest quality-loss thing i can do to reduce encoding time? [13:11] <JEEBsv_> and yeah, ffmpeg itself can set -crf and -maxrate and -bufsize just fine, so you don't have to use -x264opts :) [13:11] <JEEBsv_> (you just need to add k at the end because ffmpeg uses bits while x264 uses kilobits) [13:12] <JEEBsv_> the lowest thing is to just match up the preset :P the presets should be a nice area between speed and quality [13:13] <dannyzb> I use veryfast .. superfast destroys quality for action scenes completely ( all blocky ) [13:13] <dannyzb> but it's super processor intensive [13:14] <JEEBsv_> DeadSix27: yeah -- it just seems to fail at allocating memory. Try ultrafast so it uses minimum features within x264 and thus uses the least memory? [13:14] <iive> Jellicent: in alsamixer you get recording volumes if you press <tab> once, pressing it second time would show all. You have seprate control for playback (to headphones) and recording (to capture device). [13:14] <JEEBsv_> -preset ultrafast that is [13:14] <iive> Jellicent: make sure you don't have pulse audio routing. [13:14] <JEEBsv_> dannyzb: yes -- x264 will try to go as fast as it can [13:14] <DeadSix27> JEEBsv_: in what unit does x264 show that? [13:14] <DeadSix27> if its kilobytes, that would be 200gb of memory allocation, bytes would be not even /4 of a gif [13:14] <JEEBsv_> DeadSix27: the malloc fail? That's in bytes I think [13:15] <DeadSix27> gig* [13:15] <DeadSix27> then why cant it allocate such a low size [13:15] <dannyzb> well i guess I can't push speed up anymore at this quality [13:15] <dannyzb> good enough .. time for a new super-server :D [13:15] <dannyzb> btw whats more cost effective ffmpeg-wise : intel or AMD ? [13:16] <JEEBsv_> DeadSix27: dunno, might just be a smaller allocation after a bigger one [13:16] <JEEBsv_> and the smaller one later just happens to be the one to fail [13:16] <iive> JEEBsv_: i'm afraid i don't fully understand your answer. If the communication channel is CBR (as are most channels) and is e.g. 1Mbps. should I set maxbitrate to 1Mbps. [13:16] <DeadSix27> JEEBsv_: it used ~5gb ram at the time [13:16] <DeadSix27> of 16gb available [13:16] <JEEBsv_> dannyzb: intel definitely if you're going to use x264 [13:16] <Jellicent> iive: I don't even have pulseaudio installed, so that won't be the problem. I'll have a quick look into what you said. [13:16] <JEEBsv_> AMD hasn't been giving good cost-performance for a long-long time [13:17] <iive> VBV is like the math taks with pools filling and draining water. the only difference is that they do that with variable rate on one side. [13:17] <dannyzb> ok thanks [13:17] <dannyzb> and one last thing [13:17] <dannyzb> do I have any use for "refs" ? [13:18] <JEEBsv_> only if you use slower presets and want to limit reference frames to a specific H.264 level [13:18] <JEEBsv_> because you can set -level in ffmpeg, but that will only set the libx264 flag [13:18] <JEEBsv_> not limit the reference frames to fit that level [13:18] <DeadSix27> now that we're on questioning time, yesterday i asked sommin about keyframes, and if they're doing the "skipping gabs" in playback [13:18] <dannyzb> ah right .. I heard "no" :) [13:18] <DeadSix27> how can i make skipping to specific times in a video (in player) more precise? [13:19] <DeadSix27> sometimes i can only skip to every 5s or so, which is kinda annoying [13:19] <JEEBsv_> iive: you should set it to the minimum bandwidth you support. If you want to use the whole speed of the communication channel then you use its speed - (possible audio overhead + possible container overhead) for maxrate, and then bufsize is set by how much you want to buffer (and how much freedom you want to give to the encoder) [13:21] <JEEBsv_> DeadSix27: -g sets the (maximum) GOP size, which is the maximum amount of pictures between two IRAPs [13:21] <JEEBsv_> (IRAP is a HEVC/H.264 wording but man do I love it more than IDR or 'keyframe' <3 ) [13:21] <JEEBsv_> uhh, HEVC/H.265 [13:21] <DeadSix27> and using the fps rate i can then calculate the seconds i want to have between right? [13:22] <iive> yes [13:22] <DeadSix27> like @ 25fps output i could use -g 25, to have a 1s precise skipping? [13:22] <JEEBsv_> no [13:22] <DeadSix27> mh [13:22] <JEEBsv_> you will get smaller or by max 25 frame GOPs [13:22] <JEEBsv_> basically the maximum length of a GOP is 25 frames [13:23] <DeadSix27> so 0-1s precising skipping [13:23] <JEEBsv_> yes [13:23] <DeadSix27> would setting 0,5s as minimum and 1,2s be better? [13:23] <DeadSix27> is doesnt it matter having it just set to -g 25 [13:24] <DeadSix27> or* [13:24] <DeadSix27> (what i mean is, would that impact quality/size or encoding speed much) [13:25] <JEEBsv_> not sure how x264 limited minimum keyint, but I would guess at that length most GOPs would be close to the full 1s [13:25] <JEEBsv_> but yes, you could try limiting the minimum keyint to at least half a second [13:25] <iive> it won't affect speed, but it would affect bitrate/quality [13:25] <DeadSix27> its -keyint_max right? [13:26] <JEEBsv_> no idea about the x264 setting [13:26] <JEEBsv_> uhh [13:26] <JEEBsv_> ffmpeg I mean [13:26] <JEEBsv_> I only know the x264 one [13:26] <DeadSix27> i had a page for that sec. [13:26] <JEEBsv_> I only know the equivalent of --keyint for ffmpeg [13:26] <JEEBsv_> which is -g [13:26] <JEEBsv_> I have no idea about the minimum keyint equivalent in ffmpeg :) [13:26] <DeadSix27> --min-keyint <integer> (x264) -keyint_min <integer> (FFmpeg) [13:26] <DeadSix27> accordign to that page [13:27] <JEEBsv_> possible, feel free to try if that works :D [13:27] <DeadSix27> should, i tried it yesterday [13:27] <DeadSix27> just didnt know how to handle keyint stuff [13:28] <DeadSix27> JEEBsv_: btw i successfully compiled ffmpeg, but cross from linux, didnt gwt it to work on windows [13:28] <DeadSix27> took like 2hrs and 5gb of my hdd space (crazy) [13:29] <JEEBsv_> dunno, I've compiled both from msys with a mingw-w64 toolchain by nev, as well as from lunix the same way I noted to you [13:29] <JEEBsv_> of course it's really easy to set up the msys/mingw(-w64) thing crappily, but I really don't consider that being a problem specific to ffmpeg in any way [13:30] <DeadSix27> i used that build script [13:30] <DeadSix27> i tried myself, but didnt get the librarys working for idk what reason [13:31] <DeadSix27> anyway, like you said, libdk_aac has way better quality [13:31] <DeadSix27> +f [13:31] <JEEBsv_> yeah, too bad it was released under a license that doesn't permit one to distro binaries of it coupled with ffmpeg+libx264 :< [13:36] <DeadSix27> ye [13:37] <DeadSix27> only together right? [13:37] <DeadSix27> wouldnt a second tool without x264 solve it funnily-workarround-ly [13:37] <JEEBsv_> well, you can't really distro fdk-aac binaries either unless you have taken the steps noted in the license [13:37] <JEEBsv_> and no, it needs enable-nonfree with LGPL setup as well [13:38] <JEEBsv_> so removing x264 really doesn't help either [13:38] <DeadSix27> k [13:38] <JEEBsv_> faac became nonfree a few years ago when it was found that it contained source code that was not GPL-compatible (while faac tried to imply it was GPL) [13:39] <JEEBsv_> so yeah, right now we're in the funny situation where the best aac encoder you can distro is the internal libavcodec one :D [13:39] <DeadSix27> and theres no way to write own stuff replacing that code? [13:40] <JEEBsv_> there is, but no-one cares about faac to be honest. Most people just build the best thing at that point on the machine (fdk-aac at the moment), and the rest are more interested in developing the internal one [13:40] <DeadSix27> ah [13:40] <JEEBsv_> there's a huge thread on the trac issue tracker about improving the internal one [13:40] <DeadSix27> internal = aac (the experimental one) right? [13:40] <JEEBsv_> yes, which I have no idea why it's still experimental [13:41] <JEEBsv_> because it's better than the two vo-aacenc library one for example [13:41] <DeadSix27> im not that exprienced with it that much [13:41] <JEEBsv_> which isn't set as "experimental" [13:41] <DeadSix27> but for some reason experi. aac kinda gave me bad quality [13:41] <DeadSix27> at the same settings as libvo_aacenc and libfdk [13:41] <DeadSix27> and those were better in qualtiy [13:41] <JEEBsv_> it should be worse than vo-aacenc in general [13:41] <JEEBsv_> fdk beats it [13:42] <DeadSix27> what i meant is libfdk > libvo > aac [13:42] <JEEBsv_> it's not a good encoder, but on the other hand neither is vo-aacenc :) [13:42] <JEEBsv_> yeah [13:42] <JEEBsv_> I just don't agree with that in general :) [13:42] <JEEBsv_> also vo-aacenc is limited to stereo [13:42] <DeadSix27> could be stupid encoding parameters and lack of knowledge i guess. [13:42] <JEEBsv_> also you could try the newest patch on that huge'o'licious thread [13:42] <JEEBsv_> lol [13:43] <JEEBsv_> that should improve the internal one nicely [13:43] <DeadSix27> how to get it? [13:43] <DeadSix27> im currently just using source of git [13:43] <JEEBsv_> https://trac.ffmpeg.org/ticket/2686 scroll to the bottom and start looking at the newest patch like that :D [13:43] <JEEBsv_> it's a long thread [13:44] <DeadSix27> my brain cant allocate that memory [13:44] <JEEBsv_> seems like three weeks ago he was 'close to releasing version 8' of the patch [13:44] <JEEBsv_> anyways, pretty cool that someone cares :) [13:45] <DeadSix27> someone with knowledge on how to improve it* [13:45] <DeadSix27> afterall i care as well [14:36] <DelphiWorld> hi guys [14:36] <DelphiWorld> stupid QUESTION:P [14:36] <DelphiWorld> anyone know how to make any mp3 file to be flac? [14:36] <DelphiWorld> all files not only one, including subdirs [15:20] <Jellicent> iive: Thank you for your tip a few hours(?) ago. I found something I could have tweaked earlier, but I didn't think of it. So when I tabbed I found it.. duh. Thank you! <3 [15:20] <iive> glad I had somehow helped :) [15:35] <dannyzb> frame= 2905 fps= 88 q=29.0 size= 21806kB time=00:02:01.45 bitrate=1470.8kbits/s [15:35] <dannyzb> does this bitrate include audio or not? [15:36] <dannyzb> i used crf=21:bitrate=1280:vbv-maxrate=1280:vbv-bufsize=12800 and that bitrate is obviously above that [15:39] <relaxed> dannyzb: you can't set both crf and bitrate, choose one rate control method [15:40] <dannyzb> relaxed : people already told me i can use both here .. i think you're confused [15:40] <relaxed> that's news to me [15:41] <dannyzb> well we're going to need someone neutral to clear this up [15:44] <relaxed> http://mewiki.project357.com/wiki/X264_Settings#Ratecontrol "This option is mutually exclusive with qp and bitrate." [15:44] <relaxed> look look under "crf" [15:46] <dannyzb> good to know ! [15:46] <relaxed> add -map 0:v after the input to only encode the video if you want to monitor the bitrate. [15:47] <dannyzb> woah crf encodes 20% faster for me [15:47] <dannyzb> excellent ! [15:49] <dannyzb> thanks man [15:49] <relaxed> you're welcome [17:36] <dannyzb> should i use main or baseline for mobile devices ? [17:39] <dannyzb> j [17:40] <klaxa> depends on how old your target devices are [17:40] <klaxa> most devices support high profile [17:40] <klaxa> *most recent devices [17:44] <dannyzb> ok cool [17:44] <dannyzb> so I'll do main for SD and high for HD [17:44] <dannyzb> another thing - i see all my encodings drop in framerate as they progress .. what causes that? [18:28] <PowerCC> recently installed ffmpeg on my debian squeeze and it's forcing me to use avconv [18:28] <PowerCC> that's not ffmpeg, new fork? [18:29] <PowerCC> it's very close but -x264opts aren't working the same [18:29] <JEEB> a) it's not forcing you as far as I know b) yes, it's recommending the usage of avconv because libav left that binary to wither after rewriting parts of ffmpeg (and renamed the rewritten thing to avconv) [18:30] <JEEB> PowerCC, depends on the version you have, but in general I think libav chose the way of actually having settings for x264's things instead of x264opts [18:30] <JEEB> and I think by now those work in ffmpeg as well, since most if not everything from libav gets merged into ffmpeg [18:30] <JEEB> PowerCC, so feel free to say what settings you're setting [18:30] <JEEB> and I'll try to note what you should be using [18:30] <PowerCC> i tend to modify as follows: -x264opts rc_lookahead=24:scenecut=0:chroma_me=1:analyse=1:ipratio=1.25 [18:31] <Jellicent> When streaming to twitch (gaming) I get a constant delay of 2-3 seconds constantly in the game. Is there a way to reduce it? [18:31] <PowerCC> avconv rejects it [18:31] <JEEB> PowerCC, yes the name of the option to specifically set x264 api settings is different @ libav [18:31] <JEEB> that said [18:31] <JEEB> why do you specifically need to set those settings o_O [18:31] <JEEB> presets not good enough [18:31] <JEEB> ? [18:32] <PowerCC> it actually speeds up the encode abit [18:32] <JEEB> uhh [18:32] <JEEB> if you want to speed up encoding you set a faster preset [18:32] <PowerCC> i believe the lookahead is defaulted to 40 or 50 [18:32] <JEEB> yes, presets handle that [18:32] <PowerCC> i like the quality produced. [18:32] <JEEB> there should be a similar preset http://mewiki.project357.com/wiki/X264_Settings#preset [18:32] <JEEB> just test them out [18:32] <PowerCC> thanks [18:32] <JEEB> you should not have to poke those settings by yourself [18:32] <esing> Hi, I'd like to convert a video (e.g. mp4) to only audio (.aif). I tried ffmpeg -i video.mp4 -vn -b:a 128k output.aif , but the output.aif will be too big ( http://sprunge.us/iCcg ). This is the input file: http://sprunge.us/CjgR (which has just 4,77 MiB of an audio stream, but the .aif results in +30MB?!) [18:32] <JEEB> everything but ultrafast or placebo should be usable [18:33] <JEEB> PowerCC, the option to set those in ffmpeg and avconv is -preset [18:33] <PowerCC> got it [18:33] <PowerCC> the defaults are not bad either... i may just dumped my preset from here on out. [18:34] <JEEB> default is preset medium [18:34] <PowerCC> yup [18:34] <PowerCC> loseless i rarely use [18:34] <JEEB> Jellicent, there are various things you can do on the encoder's side as well as if you are in control of the player software used for playback of the stream [18:34] <JEEB> Jellicent, although I have no idea how you take your input and how low latency ffmpeg has there [18:35] <JEEB> basically I know that if you really, really want to, you can get sub-100ms latency with (lib)x264 [18:35] <Jellicent> JEEB: I guess I can only do something on my side, since I'm streaming to twitch. [18:35] <Jellicent> Let me pastebin it, sec. [18:35] <PowerCC> your a developer jeeb? [18:36] <JEEB> PowerCC, I have some code in ffmpeg/libav/x264, but I can't really call myself anything special :P [18:36] <PowerCC> last i did anything with ffmpeg use back with MEnocder project [18:36] <PowerCC> remember -vo dxr2? ;) [18:36] <PowerCC> those were the days! [18:37] <JEEB> ugh, I really would rather not to remember mencoder :D [18:37] <Jellicent> JEEB: http://sprunge.us/NUSJ I'm open for any suggestions. Thing is I took the script from a site, so I'm not familiar with all the settings. [18:37] <JEEB> PowerCC, also that specific settings thing in libav/avconv seems to be -x264-params [18:37] <JEEB> but you really shouldn't need it :) [18:38] <JEEB> most things have their own setting in avconv (and by now most probably in ffmpeg as well) [18:38] <PowerCC> can i paste my entire cli here, it's not too long [18:39] <JEEB> Jellicent, you don't need to resample audio btw. FLV can handle !44.1kHz just fine :) [18:39] <Jellicent> Alright, JEEB. [18:39] <JEEB> also holy crap [18:39] <JEEB> 512kbps audio o_O [18:40] <Jellicent> Guess I could take THAT out... [18:40] <JEEB> 192kbps should be enough [18:40] <Jellicent> Yeah.. like a lot. [18:40] <JEEB> and AAC should be better [18:40] <Jellicent> Instead of lame I guess+ [18:40] <Jellicent> *? [18:41] <JEEB> if you are using someone else's binary, you can use -c:a aac -strict experimental, and if you have built it yourself with fdk-aac you can use -c:a libfdk_aac [18:41] <JEEB> anyways, I'm not sure how much ffmpeg buffers over at the input side [18:41] <Jellicent> Hmm okay. [18:42] <JEEB> you can get the latency minimized on the x264's side with -tune zerolatency [18:42] <JEEB> but do note that this will make encoding slower (it will thread within a single picture instead of multiple at once), and quality will suffer [18:42] <Jellicent> I see. Thank you. [18:42] <JEEB> also i don't see -maxrate or -bufsize [18:43] <JEEB> this is _needed_ for streaming [18:43] <Jellicent> I'll have a look into those, thank you. :) [18:43] <Jellicent> Guess the person writing this had a monster as a machine.... [18:43] <Jellicent> And the best internet in the world.. :p [18:43] <JEEB> look at twitch for the maxrate and buffering rules [18:43] <Jellicent> Will do, thank you. [18:43] <JEEB> basically usually they say the maximum rate, and then how many seconds the buffering is [18:44] <JEEB> you calculate how much you are giving to the audio, and then take that and a couple dozen kilobits off of the maxrate [18:44] <JEEB> and set it to -maxrate [18:44] <JEEB> and then set maxrate * seconds of buffer as bufsize [18:44] <JEEB> for example two seconds of buffering would be 2*maxrate [18:45] <Jellicent> I see. :) [18:45] <JEEB> this makes sure that you have a set bandwidth usage set [18:45] <Jellicent> Great, I guess that's what's missing for me. [18:46] <JEEB> so that a user with at least maxrate or so bandwidth and who has buffered bufsize of data can watch the stream without having to buffer again [18:46] <JEEB> this is called VBV [18:46] <JEEB> (maxrate + bufsize) [18:47] <Jellicent> Cool, I didn't know of that! :D [18:47] <JEEB> unfortunately even people who want to do streaming on the web often don't :P [18:47] <JEEB> as in, for money [18:49] <Jellicent> That makes a lot of sense. [18:49] <JEEB> anyways, try with vbv and AAC first, after that try with -tune zerolatency [18:50] <Jellicent> Will do that. :) [18:58] <PowerCC> -threads 4 -c:a ac3 -b:a 448k -ar 48000 -ac 6 -c:v libx264 -coder ac -level 41 -vb 5000k -bf 0 -refs 2 -flags +loop -weightp 2 -trellis 1 -mixed-refs 1 -weightb 0 -8x8dct 1 -fast-pskip 0 -mbtree 1 -me_method umh -subq 6 -me_range 16 -sc_threshold 0 -qmin 10 -qmax 50 -qdiff 3 -qcomp .5 -g 24 -keyint_min 2 -subq 6 -psy 1 -x264opts rc_lookahead=24:scenecut=0:chroma_me=1:analyse=1:ipratio=1.25 -sn -copyts output.mp4 [18:59] <PowerCC> that's usually what i do JEEB [18:59] <JEEB> let me guess [18:59] <JEEB> you just copied that off of some random mediainfo log [19:00] <JEEB> the x264 stuff that is :P [19:05] <PowerCC> no [19:05] <JEEB> well it very much seems so :P [19:05] <JEEB> because you're, among others, setting some old x264 defaults [19:05] <JEEB> like qmin and qmax [19:05] <PowerCC> why would i do anything that does not speed up my process [19:05] <PowerCC> remember i have used that for the last 4 years [19:06] <JEEB> well, that's what it is :P some of those settings have no effect on speed but instead just show that you're copy-pasting stuff from somewhere [19:06] <PowerCC> given the above syntax how would you apply it? [19:06] <PowerCC> i don't claim to be an expert. [19:07] <PowerCC> just pieced together a formula that has worked for me [19:07] <PowerCC> i use the output video to playback on my tivos. [19:07] <JEEB> qmin/qmax is just the default for QP range until 2011 or so? After that the lower part was set to zero or so because there was no longer any worry that the encoder would unneededly use lower QPs [19:07] <JEEB> http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=04256645537d17b66f… [19:07] <JEEB> ok, it was 2010 [19:08] <PowerCC> and OpenCL for libx264 is used by default if gpu/cpu supports it? [19:08] <JEEB> no [19:08] <PowerCC> so that's why i used lookahead [19:08] <PowerCC> to my understanding. [19:08] <JEEB> nope [19:08] <PowerCC> that's why i am here ;) [19:08] <JEEB> anyways, you can just rip out most of it [19:08] <PowerCC> thanks [19:09] <JEEB> and use -preset -level and then just match up -refs to the level maximum limit [19:09] <PowerCC> that would free up lots of real estate on my terminal [19:09] <PowerCC> as you wrote earlier, I am probably just fine with defaults (medium) [19:09] <JEEB> because -level only sets the flag in the stream, unlike x264cli that also matches up the reference frame count to the maximum to the given resolution + level combo [19:09] <PowerCC> i c [19:09] <JEEB> have been thinking about adding that code to libx264.c [19:09] <JEEB> but never got to it :D [19:10] <JEEB> basically there's a limit to macroblocks on every level, and the resolution thus decides how many reference frames you can use for a given level :) [19:12] <PowerCC> i am not encoding from pure source anyhow... most of what i do is transcode [19:12] <PowerCC> but if i did pure blu-rays i'd be more concern. [19:13] <JEEB> nah, if you're encoding for hardware players you generally want to create streams that comply to a level :) [19:13] <PowerCC> is it true OpenCL only speeds up process by using lookahead [19:13] <PowerCC> or can the gpu be more useful to do other encoding [19:13] <JEEB> yes, it's just an implementation of ME lookahead, not even the main lookahead [19:13] <PowerCC> pretty useless [19:14] <JEEB> it wouldn't be useless if GPUs were actually useful for a lot of that stuff [19:14] <JEEB> right now it gives little speed-up if any, and the fastest presets don't have either lookahead [19:14] <JEEB> because it's too slow for those [19:15] <PowerCC> well lookahead helps keep my file size down [19:15] <JEEB> GPU encoding in general is just marketing kool-aid [19:15] <PowerCC> hee [19:15] <JEEB> yes, lookahead is a useful feature, I'm just talking about the GPU implementation of ME lookahead being generally useless :P [19:15] <JEEB> it's a nice experiment and the first at least somewhat "useful" piece of code with the GPU [19:15] <JEEB> for others to look at [19:15] <PowerCC> i am pretty amazed my remote box which is just atom 1.8ghz with 4 threads can get around 11-15fps ;) [19:16] <JEEB> but really, there's a reason why most makers have quickly and silently switched to ASICs [19:16] <JEEB> :) [19:16] <JEEB> instead of GPU-based solutions [19:16] <PowerCC> yes, it works on my Mac mini with Intel HD3000 even though apple reads open cl 1.0 n/a [19:17] <PowerCC> i have a Mac mini mid-2011 [19:17] <PowerCC> but now i am trying to encode on my kimsufi mostly since it just sits there. [19:18] <PowerCC> you do much with -vf subtitles? [19:19] <JEEB> anyways, what I'm saying is that OpenCL will not get used by default in libx264 and it really is useless so you shouldn't use it :) [19:19] <PowerCC> i tend to burn them in [19:19] <JEEB> nah, I don't use that :) [19:19] <PowerCC> it's a pain at times, relies on font_config [19:19] <PowerCC> and everything must be utf8 [19:20] <PowerCC> i can say one thing, libx264 produces amazing results. [19:20] <JEEB> yes, x264 itself is quite awesomesauce [19:20] <PowerCC> by far better than any other commercial (junk ware) made out there. [19:20] <JEEB> it only loses by a bit to the reference encoder [19:21] <PowerCC> which by the way also use ffmpeg [19:21] <JEEB> while being quite a few times faster [19:21] <PowerCC> i thought it won by a hair last couple of years. [19:21] <PowerCC> that was 2005 ;) [19:22] <JEEB> I'd be surprised if it actually won the reference, because the reference encoder is slow as hell but pretty much brute forcing the best possible results [19:22] <PowerCC> passed Ateme by a hair [19:22] <JEEB> Ateme is not the reference :) [19:22] <JEEB> JM is [19:22] <PowerCC> expansive!!! [19:22] <JEEB> http://iphome.hhi.de/suehring/tml/ [19:23] <PowerCC> never heard of them [19:23] <JEEB> yeah, end users don't [19:23] <JEEB> it's the stuff used to decide if a feature should enter a standard or not [19:23] <PowerCC> thought you were referring to real cinema [19:23] <JEEB> JM for AVC/H.264 [19:23] <JEEB> HM for HEVC/H.265 [19:23] <PowerCC> $? [19:24] <JEEB> they're both open source for ObviousReasons [19:24] <PowerCC> i'll stick to what i know. [19:24] <PowerCC> or somewhat know [19:24] <JEEB> yes, and I'm not in any way saying that you should use JM or HM [19:24] <JEEB> reference software is reference software :) [19:25] <JEEB> (they are both open source because...) after all you can't do proper development and research on what should enter a standard without having access to a common platform :) [19:25] <JEEB> and basically getting to JM's level while being quite a bit faster is actually pretty awesome ;) [19:25] <JEEB> that's what I was trying to say [19:27] <PowerCC> what is JM using? [19:27] <PowerCC> what code, completely their own [19:27] <PowerCC> ? [19:28] <PowerCC> them .de always been up to snuff with codec [19:28] <JEEB> yeah, it's what was made during the research and development phase of AVC/H.264 [19:28] <PowerCC> i see... sony is on board right? [19:28] <JEEB> basically all kinds of companies and other research parties coming up with ideas, and they were then implemented [19:28] <PowerCC> yup [19:28] <JEEB> and then tested etc. [19:29] <JEEB> http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git [19:29] <JEEB> HM [19:29] <JEEB> (the HEVC/H.265 one) [19:29] <PowerCC> i just recently bought the latest tivo box (Roamio, forgive the silly name). [19:29] <PowerCC> it's got the brand new broadcom decoder it pretty much decodes anything i throw at it... the tivo premiere not as forgiven. [19:30] <PowerCC> it has an encoder built-in aka tivo stream... it's pretty amazing quality given it only does hw encoding (mpeg2 -> h.264) [19:30] <PowerCC> however frame rate wise it STINKS! [19:30] <PowerCC> not very noticeable on iPhone but on the iPad very much so. [19:31] <JEEB> I think the best hardware ASIC for encoding I've seen so far for end users is what Intel has on the Haswell platform [19:31] <PowerCC> I am considering sling box latest [19:31] <PowerCC> it does 60fps [19:31] <PowerCC> i would of never guessed intel to be a front runner. [19:32] <PowerCC> thought nvidia was ahead [19:32] <PowerCC> in hw encoding [19:32] <PowerCC> but quality wise no one is coming close to software encoding [19:32] <JEEB> nvidia's ASIC that they put from the 600+ series forwards wasn't too bad, but intel's thing is still the most fabulous one with haswell [19:32] <JEEB> also it's getting somewhat close to software encoding with its lookahead etc. modes that came with the latest iteration [19:33] <PowerCC> mmmmm [19:33] <JEEB> of course still not really too close to x264 [19:33] <JEEB> but it most definitely is getting somewhere [19:33] <JEEB> and the speeds are pretty good [19:33] <JEEB> ~200 frames [19:33] <JEEB> per second [19:33] <PowerCC> and even if it was, libx264 can use my Toaster's cpu to encode. [19:34] <JEEB> yup [19:34] <PowerCC> I am able to use an old has to serve up libx264, yes it's 1 frame per 3 seconds but heck what else is it doing [19:34] <PowerCC> has/nas [19:34] <PowerCC> python is also my friend runs on anything [19:35] <PowerCC> heard of pyTivo project? [19:36] <PowerCC> now that's a great use of ffmpeg project [19:38] <Jellicent> JEEB It seems that streaming just doesn't work out. I tried all the options and it's either me lagging, the stream skipping like 80% of the whole recording.. or both. [19:38] <JEEB> o_O [19:38] <Jellicent> Outrageous. [19:38] <JEEB> huh [19:38] <Jellicent> I don't know why. It worked fine under Windows, last time I tried at least. [19:38] <JEEB> does the encoder show that it's not being able to encode stuff fast enough or anything? [19:39] <JEEB> also I have no idea about screen capture on *nix :D [19:39] <PowerCC> drop frames? [19:39] <Jellicent> Yes, thanks. It drops frames. Like they are fucking hot. [19:39] <PowerCC> perhaps -r fps [19:39] <PowerCC> ha [19:39] <JEEB> Jellicent, try switching to a faster preset [19:39] <PowerCC> try matching [19:39] <Jellicent> They are set to 30, shouldn't be a problem. [19:40] <JEEB> http://mewiki.project357.com/wiki/X264_Settings#preset [19:40] <PowerCC> slap it in there just in case. [19:40] <PowerCC> -r 30 [19:40] <JEEB> > slap it in there just in case [19:40] <Jellicent> It's not only dropping them, but before dropping them it stops showing what happens on the screen, then fast forwards through all it missed and drops half of it. [19:40] <JEEB> > implying that is a good idea [19:40] <Jellicent> Will have a look at that. [19:40] <JEEB> Jellicent, anyways it's either the capture or the encoder not being fast enough [19:40] <Jellicent> Yup. [19:41] <JEEB> check presets and what you're setting with -preset [19:41] <JEEB> and if that doesn't help... [19:41] <JEEB> :s [19:41] <Jellicent> MY preset is faster right now. B( Should maybe try something lower. [19:41] <PowerCC> i have lots of issues with source being 23.81 [19:41] <PowerCC> force it to -r 24 [19:41] <PowerCC> makes the output in sync and smooth [19:41] <Jellicent> Worst thing is the delay though.. can't play an RTS with 5s delay, haha. [19:42] <Jellicent> I'll try 24. [19:42] <JEEB> PowerCC, use settings where they make sense... don't plaster them around randomly [19:42] <PowerCC> oh i have tried [19:42] <PowerCC> -r 24 was the only fix [19:42] <PowerCC> with 23.81 [19:42] <PowerCC> 23.976 didn't help [19:42] <PowerCC> i don't know why -r 24 fixes my output but it did. [19:42] <JEEB> that is 24000/1001 :| but in any case, my comment was just towards trying to push random settings to people [19:43] <PowerCC> most of what i do as you can tell is lots of guess-work. [19:43] <JEEB> also ffmpeg's architecture really doesn't care about frame rates but the timestamps of all pictures, and copies them over [19:43] <JEEB> yes, and I really want to stick a spork up to your eyeball for trying to recommend random stuff to random folk :P [19:43] <PowerCC> oh, sorry [19:43] <PowerCC> just thought it was helpful. [19:44] <PowerCC> i am just speaking out of my own experiance. [19:44] <JEEB> trying to be useful is a good thing. Just that you really should try to understand things instead of Cargo Culting [19:44] <PowerCC> so just so i understand why -r 24 did fix my problem? [19:44] <PowerCC> agreed [19:45] <JEEB> probably broken timestamps somewhere? or the hardware player not liking timestamps that don't confine to a certain area [19:45] <JEEB> I can't possibly know [19:45] <PowerCC> the other odd issue that makes no sense to me [19:45] <PowerCC> my tivo plays back 25 (pal) no dropped frames [19:46] <PowerCC> of course it won't do 1080p/24 but i'll take it over skipping frames. [19:47] <PowerCC> JEEB: is codec your hobby or also your profession? [19:47] <JEEB> mostly a hobby, I've not done it work-wise other than random projects [19:47] <PowerCC> I'm a network engineer so arp/netstat all day long... [19:48] <PowerCC> it does not stop to amaze me, ever since the days of divx [19:48] <PowerCC> my friend went on to really try and make it big with 3ivx [19:48] <PowerCC> he is in australia [19:48] <PowerCC> but i can't begin to understand half of how encoding works other than it's ALOT of number crunching. [19:49] <JEEB> you can watch xiph's monty's intro video for a nice introduction [19:50] <JEEB> http://www.xiph.org/video/vid1.shtml [19:50] <PowerCC> thx [19:50] <PowerCC> i do get excited enough if all my libs and ffmpeg just compile perfectly on my platform of choice ;) [19:50] <PowerCC> Jellicent: how is it going? [19:52] <PowerCC> if you ever need help with network jeeb i am your guy. [19:52] <PowerCC> cisco switch/telephone/modem you name it. [19:54] <PowerCC> this is out-dated: http://ffmpeg.gusari.org/viewtopic.php?f=8&t=874 [19:55] <PowerCC> thanks jeeb, i'll see you here next time... happy xmas! [20:12] <Jellicent> Haha.. man. The way my output came out on twitch.. priceless. [20:29] <Ulfr_> Hello all. I'm trying to install ffmpeg on a ubunutu 10.04 server to convert videos to flash. I was able to get the conversion to work, but couldn't get sound, so I followed a tutorial, realized it wasn't a system installation, and would genuinely appreciate some assistance [20:31] <Ulfr_> I'm not trying to get someone to do this for me, I'm just trying to migrate a server and ffmpeg isn't terribly understanding about that [20:31] <JEEB> anything on the 10.04 would be quite old so you most probably want to build it yourself :s [20:31] <JEEB> https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [20:32] <JEEB> only build those libraries that you need [20:32] <JEEB> x264 for H.264 encoding and fdk-aac for AAC encoding, for example [20:33] <Ulfr_> That's the tutorial I followed~ [20:33] <Ulfr_> worked great! [20:33] <Ulfr_> until www-data tried to use it [20:34] <Ulfr_> Tried to unfutz that situation and wound up with -formats missing the bottom half of it's results [20:34] <Ulfr_> JEEB: ^ [20:34] <JEEB> you have to use either the full path to the binary, or modify the PATH [20:34] <JEEB> to make it use the same ffmpeg binary [20:35] <Ulfr_> JEEB: I've done so, the binary executes fine, but when I run ffmpeg -formats it doesn't list codecs [20:35] <JEEB> of course not, -codecs is for "codecs" :P [20:36] <JEEB> also those listings don't just change [20:37] <JEEB> you are running a different binary, and thus you have to make sure that you are running the same one :P [20:37] <Ulfr_> JEEB: One moment. I'm basking in how profoundly stupid I feel at the moment. [20:39] <Ulfr_> Okay, all better. Yeah, I checked the timestamp to make sure it was the correct version. Codecs looks like it's supposed to, and I ran ./conifgure with --enable-libfaac, but it's not in the list. Is that normal? [20:40] <JEEB> yes [20:40] <JEEB> also don't build with faac [20:40] <JEEB> but fdk-aac [20:40] <JEEB> they both need --enable-nonfree [20:40] <JEEB> but fdk-aac is better [20:41] <Ulfr_> JEEB: I absolutely agree with you, but I am *so* not delving into this warren of confusion and hate that is this website to change things around [20:42] Action: JEEB shrugs [20:42] <JEEB> suit yourself [20:42] <Ulfr_> JEEB: For reference, videos conversions aren't triggered by upload events, it's done by a crontab. The dark wizard that built this also decided he didn't need a config file, he needed a database table for holding config settings [20:44] <Ulfr_> JEEB: Thank you very much though! [21:11] <Ulfr_> Am I losing my mind or is it supposed to take multiple executions of the program to convert a video [21:12] <JEEB> 2pass encoding (average bit rate rate control's best mode) needs two passes, yes [21:12] <JEEB> CRF and one-pass average bit rate rate control only needs one pass of course [21:12] <JEEB> (of which I definitely prefer CRF :D ) [21:13] <Jellicent> JEEB I think the problem is my upload rate. I give up for now... haha. [21:13] <Jellicent> I know I'll try again tomorrow. [21:14] <Ulfr_> Jellicent: I know that feel. [21:14] <Jellicent> Ulfr_: I've tried for 6 hours straight now. :p Need something else. [21:14] <Ulfr_> Jellicent: DEFINITELY know that feel. [21:14] <Jellicent> I think food and watching a show is good. [21:15] <Ulfr_> Jellicent: Consider a video game that teenagers play. Making them rage always makes me feel better [21:15] <Jellicent> I already do that. [21:15] <Jellicent> :D [21:15] <Ulfr_> JEEB: does this sound correct at all? It looks like the program runs 3 times. It graps a jpg image from the video, the second and third actually make the flv happen [21:15] <Jellicent> Ulfr_: I'll probably do that later, happily. ^_^ [21:16] <Ulfr_> Jellicent: It's my go-to for days like that [21:16] <Jellicent> Hehehe. :D [21:16] <Ulfr_> You know it's time to stop when some kid is sufficiently angry his voice sqeaks [21:16] <Jellicent> Ahahaha. :d [21:19] <JEEB> Ulfr_, yes -- although you could do the first pass of the 2pass encoding, and the jpg output together [21:20] <Ulfr_> JEEB: I'm beginning to think I might have to do that. This is becoming a nightmare. [21:40] <cassidy> hi there! I'm trying to dump the content of a rtsp stream (no transcoding) and get a lot of "Non-monotonous DTS in output stream 0:1" warnings. Is there something I can do to "fix" the file in a way I'll be able to properly transcode it later? Here is the full output with ffmpeg master: http://pastebin.com/88BVBrPD [21:42] <Ulfr_> cassidy: I'm not very fluent in ffmpeg, but as far as I knew warnings didn't mean anything as far as impeding anything working right [21:46] <cassidy> Ulfr_, ah ok. I was having some issues when transcoding to .webm afterwards and was assuming it was the reason [21:46] <Ulfr_> JEEB: Okay. I give up. I'm just going to rewrite this ffmpeg call. Any chance you could direct me to an example of a fancy pants one pass run that also does that jpeg thing? [21:47] <Ulfr_> cassidy: Hey, I have no idea to be perfectly honest. I've just never let warnings from something written for linux get me out of sorts. Those things are always warning me about stuff [21:48] <cassidy> Ulfr_, as a developer myself, if I add a warning somewhere it's generally that things are going pretty wrong :) [21:48] <Ulfr_> cassidy: you should've seen my box compile ffmpeg just recently then. there were hundreds of pages [21:50] <cassidy> gcc warnings are differents from runtime ones [00:00] --- Fri Dec 27 2013

1 0