December 2013 - Ffmpeg-devel-irc

ffmpeg-devel.log.20131202
by burek 03 Dec '13

03 Dec '13

[00:43] <Timothy_Gu> Can someone explain this whole FF_QP2LAMBDA thing? [00:44] <Timothy_Gu> From what I understand avctx->global_quality is set in "lambda" unit [00:45] <Timothy_Gu> And ffmpeg -qscale is set in "QP" unit [00:45] <Timothy_Gu> Right? [00:46] <Timothy_Gu> Or maybe this should be in #ffmpeg channel... [00:59] <michaelni> yes thats true [00:59] <michaelni> some encoders i think use global_quality differently though [01:01] <michaelni> the original idea was that the quality values would be codec independant rate distortion factors [01:04] <michaelni> but for external libXYZ style encoders making the numbers passed as global quality match that libs command line tools seems to be prefered by more users & devels and or at least thats what most such encoders do [02:46] <cone-18> ffmpeg.git 03Michael Niedermayer 07master:ab6ea7a81921: avcodec/h264_refs: split conditions of if() up for better readability [02:46] <cone-18> ffmpeg.git 03Michael Niedermayer 07master:e3d7a3978b85: avcodec/h264_refs: improve key frame detection heuristic [02:59] <Timothy_Gu> Michaelni: and the ununified usage finally results in the vbr option for libfdk-aac [03:01] <Timothy_Gu> michaelni: also what is "lambda" [03:01] <Timothy_Gu> Well I know it is a Greek alphabet but what does it mean? [03:06] <cone-18> ffmpeg.git 03Michael Niedermayer 07release/2.1:1141a18e89d2: avcodec/h264_refs: split conditions of if() up for better readability [03:06] <cone-18> ffmpeg.git 03Michael Niedermayer 07release/2.1:c765b6464139: avcodec/h264_refs: improve key frame detection heuristic [03:06] <michaelni> its a factor that weights distortion and bits together, or to say it differently the amount of added distortion you are willing to accept per 1 byte or bit smaller file [03:07] <michaelni> i guess there are likely better explanations around. didnt try but maybe you find one when you search for rate distortion [03:12] <michaelni> and distortion in this can be anything, from sum of squared differences to various psycho vissual and acoustic things [03:19] <iive> http://cbloomrants.blogspot.com/2010/01/01-12-10-lagrange-rate-control-part… [03:19] <iive> (found by google). [11:00] <plepere> so, I'm trying to make my code PIC compatible for shared libraries. I used vp8dsp.asm as reference, but I get a "picregq undefined" when compiling. [11:09] <plepere> ok, I found the error, but I still have a ' relocation R_X86_64_32 against `.rodata' can not be used when making a shared object' error [11:10] <plepere> my code can be found at : http://pastebin.com/b9DiU2EA [11:12] <plepere> basically, I put my table declarations from SECTION_RODATA with the %ifdef PIC thing, and used them like in vp8 [11:23] <plepere> but I finally get the same error as before I did the modifications [11:47] <cone-672> ffmpeg.git 03Diego Biurrun 07master:7ffaa195704a: dsputil: x86: Move ff_inv_zigzag_direct16 table init to mpegvideo [11:47] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:be2312aa8f05: Merge remote-tracking branch 'qatar/master' [11:47] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:749eb46d643a: configure: put pthread_create() check back [11:49] <re-G> Hi guys. [11:49] <re-G> I used -metadata duration=123 with old 0.7 ffmpeg to set global duration metadata on destination. [11:49] <re-G> With newer ffmpeg builds (including git head) it doesn't work any more. Is this bug or feature? [11:50] <re-G> I found the commit which caused this: https://github.com/FFmpeg/FFmpeg/commit/714517b26a90eba208a0e3624193a7f4b8e… [11:50] <re-G> container was flv [11:51] <nevcairiel> its a feature obviously, it sets the duration based on the actual media duration it knows, and not some metadata that may or may not be correct [11:52] <re-G> ok thanks [11:54] <JEEB> re-G, the change itself makes sense in general, so the only way it's a bug is if it breaks something for you :P [11:56] <re-G> :) [12:19] <cone-672> ffmpeg.git 03Lenny Wang 07master:7b2534b0ea92: libavutil & opencl: remove opencl default device type [13:07] <BBB> ubitux: I found it funny that your 1d idct macros had 2d names (idct4_2x2_1d or idct8_2x2_1d), that's why I changed my to be 1d again :-p [13:08] <BBB> (given that 2x2 is 2d, not 1d; that'd be just 2) [13:08] <ubitux> that's the 1d for the 2x2 block [13:08] <ubitux> :p [13:09] <ubitux> but yeah feel free to rename as you please [13:13] <BBB> nah I'll keep it consistent for now [13:13] <BBB> 2x2/2 is the same thing [13:13] <BBB> maybe if we ever make assymetric 2d mixes I'll rename them [13:13] <BBB> or not, who knows :-p [13:14] <BBB> there's also vp9: minor refactorings in idct ssse3 assembly. [13:14] <ubitux> oh missed that one sorry [13:34] <BBB> I can also push this to a new branch to make merging easier [13:34] <BBB> I'm currently looking at the 32x32 and 16x16 [13:35] <BBB> also, re: using >13 registers, I typically don't move rodata into regs beyond xmm5, because on win64 that will be slower (b/c of xmm6-15 backing up), unless you use it at least 4-6 times or so [13:36] <BBB> I can fill up to xmm12 here I guess [13:36] <ubitux> reviewed [13:37] <ubitux> ok for >13 reg [13:37] <BBB> also xmm6 is currently unused [13:37] <BBB> because I free'ed it up in that macro [13:38] <BBB> so we can probably change idct8 to use m6 where it previously used m12 [13:38] <BBB> and then make it use 12 instead of 13 regs [13:38] <ubitux> that's cool :) [13:39] <ubitux> if you drop it, you go down to 11 reg; 3 reg remaining before 32-bit can be supported? :p [13:50] <Compn> re-G_ : i mean, if you have a patch that adds back in the feature you want, we can review it .. [13:51] <BBB> ubitux: is 32bit important for us? [13:51] <ubitux> for me, no [13:52] <BBB> hm... [13:55] <BBB> so we need to drop 5 [13:56] <BBB> my refactoring gives us 1 [13:56] <BBB> dropping rounding and 11585x2 gives us another 2 [13:56] <BBB> I think for the last two we can use stack as scratch-space on 32bit [13:56] <BBB> let me see what I can do [13:58] <ubitux> (oh i'm stupid, i understand why you removed the m% thing now, discregard my comment) [14:00] <BBB> I fixed the zero double comment [14:00] <BBB> 11585x2 can probably be split, sec [14:02] <ubitux> don't forget to add yourself in the copyright after the split btw [14:02] <ubitux> since you're doing changes to it [14:03] <ubitux> (i remember you only put my name into it) [14:03] <BBB> I'll do that after the 16x16 [14:04] <ubitux> are you doing the 16x16 before 32x32? [14:04] <BBB> https://github.com/rbultje/ffmpeg/tree/vp9-frame-mt [14:04] <BBB> I'm thinking about it, yes [14:04] <BBB> 32x32 is such a bloody pain, I need to get productive again [14:04] <BBB> so 16x16 first may be a more clever strategy [14:04] <ubitux> :) [14:04] <BBB> it seriously is [14:05] <BBB> so yes, the idea for 32bit is to use [pd_round] instead of m7 as rounding argument [14:05] <BBB> t [14:06] <BBB> that's why it has a m as part of the argument in the macro [14:06] <ubitux> yeah i realized that too late [14:06] <ubitux> :p [14:06] <BBB> whereas the others don't, so they can be used in SWAP [14:06] <BBB> :-p [14:06] <BBB> other patch: movq->movh done and macro renamed [14:07] <ubitux> iirc swap support both syntax [14:07] <BBB> I haven't done pre-loading yet, how about I make it 32bit compatible (which requires all kind of changes in this space anyway) [14:07] <BBB> oh it does? [14:07] <BBB> that's new [14:07] <BBB> it used to not suppport it [14:07] <ubitux> i see a "%ifnum ..." [14:08] <ubitux> SWAP_INTERNAL_{NUM,NAME} [14:08] <BBB> oh ok [14:09] <ubitux> <@BBB> https://github.com/rbultje/ffmpeg/tree/vp9-frame-mt // wrong branch? [14:09] <BBB> my git is fscked up [14:09] <BBB> I tried to push to a new branch and it wouldn't let me [14:09] <BBB> $ git push -f github HEAD^:vp9-simd [14:09] <BBB> error: unable to push to unqualified destination: vp9-simd [14:09] <BBB> The destination refspec neither matches an existing ref on the remote nor [14:09] <BBB> begins with refs/, and we are unable to guess a prefix based on the source ref. [14:09] <BBB> error: failed to push some refs to 'git@github.com:rbultje/ffmpeg.git' [14:09] <BBB> ?????? [14:09] <ubitux> remote "HEAD^:" ? [14:09] <ubitux> remove* [14:10] <BBB> I want to push HEAD^, not HEAD [14:10] <ubitux> dunno [14:10] <BBB> this works for frame-mt: [14:10] <BBB> $ git push -f github HEAD^:vp9-frame-mt [14:10] <BBB> [..] To git@github.com:rbultje/ffmpeg.git [14:10] <BBB> + 374bc5e...440120d HEAD^ -> vp9-frame-mt (forced update) [14:11] <ubitux> no idea [14:12] <BBB> https://github.com/rbultje/ffmpeg/tree/vp9-simd [14:12] <BBB> works now [14:12] <BBB> did some weird magic [14:12] <BBB> brb [14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:82e74ee6e486: doc/examples/filtering: make use of av_err2str() [14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:55c57658d212: doc/examples/filtering_audio: add more error checks [14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:a12bf9f50ff4: doc/examples/README: fix typo [14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:3aa601801027: doc/examples/filtering_video: add some error handling in init_filters() [14:37] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:c7a99d99bdce: doc/examples/filtering_video: do not make use of AVBufferSinkParams [14:39] <saste> ubitux, should we deprecate/drop buffersink_params stuff? [14:39] <ubitux> no idea [14:40] <saste> ubitux, also, what's wrong with filtering_audio? any reason why you didn't fix it (i see the ticket is still open) [14:40] <ubitux> because it's not chunked [14:40] <saste> ? [14:40] <ubitux> chunked packets, not supported [14:41] <ubitux> 1 packet = 1 frame currently [14:41] <ubitux> demux/decode is wrong [14:42] <saste> uh why? we push the frame only if we got_frame = 1 [14:43] <ubitux> we need to increment the pkt pointer according to the decode value [14:43] <ubitux> it changes the logic [14:44] Action: saste blames the API [14:46] <saste> ubitux, what about refcounting? why the inconsisteny between audio and video? [14:46] <ubitux> because i think nicolas attempted to fix the audio and not the video at some point [14:48] <ubitux> the buffersink param thing is interesting [14:49] <ubitux> code looks better without it :p [14:49] <wm4> does it? [14:50] <wm4> I'd think it's a nice way to pass the params without having to build an option string [14:51] <ubitux> it seems you can use av_opt_set_* [14:51] <ubitux> on the sink context [14:51] <ubitux> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commitdiff;h=… [14:51] <ubitux> i'm reading this ^ [14:52] <wm4> is that even safe [14:52] <wm4> it passes enum AVPixelFormat* to a function that expects an "int list" [14:52] <wm4> whatever that means [14:52] <wm4> but probably int* [14:52] <nevcairiel> enums are always ints [14:52] <saste> enum == int [14:52] <wm4> not to mention that Libav doesn't have this function [14:53] <wm4> does that make their pointer types compatible? [14:53] <saste> wm4, yes [14:53] <saste> libav buffersink is limited in the sense that you can't set a list of supported formats [14:53] <saste> you have to set only one [14:53] <wm4> then why is gcc complaining [14:53] <saste> so it doesn't use buffersink/list_set [14:54] <saste> not here [14:55] <saste> the bounces guy, again! [15:00] <ubitux> doesn't warn here either [15:09] <wm4> well it certainly does warn here against something like "enum Foo e; int *i = &e;" [15:09] <wm4> and gcc is probably right, because even though enums are almost ints, they're still different types [15:10] <wm4> but I see av_opt_set_int_list() is actually a macro [15:11] <wm4> doesn't stop it from being theoretically incorrect, lol [15:11] <wm4> look at av_int_list_length_for_size(), that sure is some baggage [15:15] <saste> wm4, what happened of the ffprobe patch? [15:16] <wm4> uh I'm not sure about editing xml schemas and changing fate tests [15:17] <ubitux> make -k fate |patch -p1 [15:17] <ubitux> it needs fate update because we check ffprobe output [15:17] <ubitux> the diff will be obvious [15:19] <saste> wm4, if it takes too much time for you i'll fix it, let me know [15:19] <saste> in case you still think the feature is useful [15:21] <ubitux> i think he did that mainly to report a bug [15:21] <ubitux> which used that feature [15:23] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:893f33e7f005: doc/examples/filtering_audio: fix style [15:23] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:c490cd4c1ae3: doc/examples/filtering_audio: fix chunked audio decoding [15:24] <saste> ubitux, is filtering_audio ref-counting correct? [15:24] <ubitux> i don't think so [15:24] <ubitux> i mean, it doesn't work iirc [15:25] <ubitux> saste: but you know the decoding video is a cheat as i said [15:25] <ubitux> it should have been correct [15:25] <ubitux> it should work without my latest patch [15:25] <ubitux> it just happens to not deal properly with ref counting [15:25] <ubitux> without* [15:26] <ubitux> somewhere in our api [15:26] <ubitux> saste: FFMIN(ret, packet0.size) [15:26] <ubitux> no? [15:26] <saste> that would be a bug in the decoder [15:27] <saste> bug should be fixed in the decoder, not in the application [15:27] <ubitux> no it's not a bug iirc [15:27] <ubitux> it just says how much it read [15:27] <ubitux> and it might read above the packet (in the padded area) but this is expected [15:27] <ubitux> you actually documented it in the demuxing_decoding example [15:28] <ubitux> maybe our codec helper could do that op, if not already the case [15:28] <saste> ubitux, not me, it was wm4 [15:29] <ubitux> ok [15:29] <saste> but even in this case, I check for size <= 0, if ret > packet0.size it will be negative, no deal [15:30] <ubitux> should we make the decode function do that FFMIN btw? [15:31] <ubitux> (even though it would have read more) [15:31] <wm4> the decoder should just return one frame for one packet [15:31] <ubitux> it can't [15:32] <wm4> either the codec parsers could segment the packets properly, or you could just have the decoder append to a frame [15:33] <nevcairiel> both solutions have negative consequences [15:33] <re-G_> Compn: ok, thanks. I'm using now my custom build and my patch just reverts the commit https://github.com/FFmpeg/FFmpeg/commit/714517b26a90eba208a0e3624193a7f4b8e… The commit was introduced between 0.8 and 0.9. Latest 0.8 does not include it. [15:35] <wm4> how many codecs do this anyway? AFAIK not many [15:40] <nevcairiel> mp3 at least [15:41] <nevcairiel> and afaik splitting it in the parser is also a bit complicated [15:41] <JEEBsv> re-G_: so it does break something for you? [15:41] <JEEBsv> please explain instead of staying silent [15:42] <nevcairiel> oh, and als is one of the codecs that definitely does it, no idea if it can be parsed though [15:51] <re-G_> JEEBsv: i'm very sorry and quite busy now. It breaks my way to send metadata to flash element but situation is not problem for me because i can use custom build. I just wanted to know is it bug or not. :) [15:51] <JEEBsv> so flash breaks if it doesn't get that info? [15:52] <JEEBsv> when you get the time please explain the problem and then we can see where the problem lies and how it can be fixed in the best way possible [15:52] <re-G_> JEEBsv: OK. Thanks a lot. [16:28] <ubitux> i need a ufltp :X [16:28] <ubitux> (audio sample format) [16:29] <nevcairiel> unsigend float, why? [16:30] <ubitux> some nasty opengl stuff [16:31] <ubitux> i need audio values in [0;1] :P [16:31] <nevcairiel> what does opengl do with audio? [16:31] <nevcairiel> visualization? [16:32] <ubitux> i'm doing that sort of thing [16:33] <ubitux> well i guess i'll add a personnal sampler on top of it [16:33] <ubitux> :p [18:00] <Mavrik> hey... is there a struct to somehow signal FPS to the output codec/encoder? [20:09] <cone-672> ffmpeg.git 03Diego Biurrun 07master:ad477710244c: build: Add shorthand for HOSTCC compile macro [20:09] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:a6c455cf6bb2: Merge commit 'ad477710244c761ad1c21246c34e0075fee12d11' [20:23] <cone-672> ffmpeg.git 03Diego Biurrun 07master:5a9fcc7d2524: build: Add rule for building host-specific object files [20:23] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:6f9be8120d29: Merge commit '5a9fcc7d2524d6c0f86b2855019ee9f4cf360276' [21:02] <j-b> Anyone around here looking for contract work? [21:03] <llogan> what kind of work is it? [21:04] <j-b> various, but mostly around codecs or VLC code [23:03] <cone-672> ffmpeg.git 03Diego Biurrun 07master:21710ea82118: dv: Move DV VLC data tables out of header file [23:03] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:b58c1dd63268: Merge commit '21710ea82118c9d19bea9277b2a85a33096fdd95' [23:13] <cone-672> ffmpeg.git 03Diego Biurrun 07master:97d19c2fec35: dv: Split off DV video encoder into its own file [23:13] <cone-672> ffmpeg.git 03Michael Niedermayer 07master:830be99ae167: Merge remote-tracking branch 'qatar/master' [23:54] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:d5d51cf04dea: lavfi/volume: support all channel counts [23:54] <cone-672> ffmpeg.git 03Stefano Sabatini 07master:6ca0ac5e5571: doc/ffserver: remove spurious NoAudio option from stream example [00:00] --- Tue Dec 3 2013

1 0

ffmpeg.log.20131202
by burek 03 Dec '13

03 Dec '13

[00:00] --- Mon Dec 2 2013 [00:03] <ian_m> For some reason if I capture using x11grab at 30 fps it works fine. However if I simultaneously capture from my webcam at 15 fps, then use the fps filter to change it to 30 fps and overlay to combine the two streams the webcam plays fine but the x11grab is now playing 2x too fast. [00:03] <ian_m> if I use setpts=2*(PTS-STARTPTS) + STARTPTS on the x11grab stream they are now in sync [00:03] <ian_m> is this intented behavior? [00:35] <Samus_Aran> vvvvvvvvvvvvv vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv dfer3e cd3333333333f322222222222222edddddddddddcccccffffffffffffffffffffffffffffffffffffff vbbbgtfr44444444bhtfr444444444444444tg~~~~~~~~~~~~~~yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy~ [00:35] <Samus_Aran> AAAAAAA [00:35] <Samus_Aran> sorry, toddler [00:36] <Samus_Aran> she moves fast for nine months. [00:47] <Timothy_Gu> Can someone explain this whole FF_QP2LAMBDA thing? [00:47] <Timothy_Gu> <+Timothy_Gu> From what I understand avctx->global_quality is set in "lambda" unit [00:47] <Timothy_Gu> <+Timothy_Gu> And ffmpeg -qscale is set in "QP" unit [00:47] <Timothy_Gu> <+Timothy_Gu> Right? [00:47] <Timothy_Gu> (Copied from #ffmpeg-devel) [01:07] <iive> Timothy_Gu: google gave me this, looks good http://cbloomrants.blogspot.com/2010/01/01-12-10-lagrange-rate-control-part… [02:28] <Samus_Aran> Timothy_Gu: I have no idea about that, sorry. [03:02] <Timothy_Gu> Samus_Aran: @michaelni> yes thats true [03:02] <Timothy_Gu> <@michaelni> some encoders i think use global_quality differently though [03:03] <Timothy_Gu> <@michaelni> the original idea was that the quality values would be codec independant rate distortion factors [03:03] <Timothy_Gu> <@michaelni> but for external libXYZ style encoders making the numbers passed as global quality match that libs command line tools seems to be prefered by more users & devels and or at least thats what most such encoders do [03:04] <Samus_Aran> the solution to that is to have an ffmpeg specific option for it, and also the lib's option in its own format. [03:04] <Samus_Aran> best of both worlds [03:05] <iive> Timothy_Gu: did you take a look of my link? [03:39] <dreikk> hi, lately my VLC for has been giving me a lot of problems with various .mkv and .avi, saying it can't play ".undf" files. I have read I should use an old VLC version or wimpy to play these files, but no solution has worked. And it happens already with 5 files so I don't think they file is corrupt, any ideas? [03:43] <klaxa> dreikk, run ffprobe on them and see if it lists anything weird [03:43] <klaxa> if it doesn't try ffplay to play it [03:43] <klaxa> if it plays, well... we'll see then [03:44] <dreikk> ok [03:48] <dreikk> klaxa: im not even sure of how to execute this [03:49] <klaxa> ffprobe some_file.mkv [03:49] <klaxa> in a terminal [03:49] <klaxa> do you have ffmpeg installed? are you on linux or bsd? [03:50] <dreikk> im in windows [03:50] <dreikk> maybe this is not the right channel? they sent me here from #freenode :S [03:50] <Samus_Aran> dreikk: ffplay.exe is available [03:51] <dreikk> yes but when i doubleclick it it just dies [03:51] <klaxa> it's not a gui program [03:51] <Samus_Aran> it's a text mode app, it displays info in the command line [03:51] <Samus_Aran> like DOS box [03:51] <dreikk> oh [03:52] <Samus_Aran> try dropping a file on it, but it probably doesn't pause before exiting [03:52] <Samus_Aran> it would be handy if it came with a batch file that paused after [03:52] <Samus_Aran> to drop files on. [03:52] <Samus_Aran> (I'm guessing, I've never used it on Windows) [03:53] <dreikk> so i should go to the folder with the .mkv [03:53] <dreikk> and then ffplay file.mkv [03:53] <dreikk> right? [03:53] <Samus_Aran> yes [03:53] <dreikk> it says it is not recognized [03:53] <dreikk> shouldnt i install it or something before? [03:54] <Samus_Aran> it shouldn't need to be installed [03:54] <Samus_Aran> if it's not in the folder with the movie, put it in a folder in your PATH [03:54] <dreikk> hmm should i have the .exe in the same folder? [03:54] <dreikk> ok [03:54] <Samus_Aran> such as your Windows folder [03:55] <frankdrey> What's a good way to have ffmpeg output under a specific max file size? [03:55] <Samus_Aran> frankdrey: which codec? [03:56] <frankdrey> Samus_Aran: h.264 and dvd [03:56] <Samus_Aran> https://trac.ffmpeg.org/wiki/x264EncodingGuide#twopass [03:56] <dreikk> wow something really weird happened [03:56] <Samus_Aran> two-pass is the best way to hit a target size with good quality [03:57] <Samus_Aran> constant-bit-rate can also do it, but with worse quality [03:57] <frankdrey> Samus_Aran: alright thanks, same applies for dvd? [03:57] <klaxa> yeah you don't want to do constant bitrate with x264 [03:57] <frankdrey> does dvd have two-pass? [03:57] <klaxa> frankdrey: what is dvd [03:57] <klaxa> dvd is not a codec [03:57] <frankdrey> mpeg2 [03:58] <Samus_Aran> frankdrey: do you mean you want a h.264 file to fit onto a blank DVD, or what? [03:58] <klaxa> i would think there's a dvd preset [03:58] <Samus_Aran> or converting a DVD to h.264? [03:58] <klaxa> i think he wants to be able to play it in a dvd player [03:58] <frankdrey> whatever -target ntsc-dvd is [03:59] <frankdrey> i convert a very high quality h.264 file to both a <4gb h.264 file and a dvd iso [03:59] <Samus_Aran> that sets options so it should work on that [03:59] <klaxa> that should set resolution and bitrate according to some standards [03:59] <frankdrey> it gave me a 4.7gb file, which is a bit too big... [03:59] <Samus_Aran> frankdrey: okay, the link I posted can help with a two-pass h.264 encode, I'm less familiar with DVD making [03:59] <Samus_Aran> it's been years since I did tha [04:00] <Samus_Aran> t*that [04:00] <frankdrey> Samus_Aran: alright thanks :) [04:00] <klaxa> frankdrey, if the only size restriction for the h264 file is "less than 4 gb" you might not want to do twopass with x264 [04:00] <klaxa> but rather crf [04:01] <klaxa> it will be faster with the same quality, but the filesize will be not known beforehand [04:01] <frankdrey> crf = constant or no? [04:01] <klaxa> constant rate factor [04:01] <klaxa> you should only use twopass encoding with x264 if you really need to match a specific target size [04:02] <klaxa> you should also only use bitrate-based encoding with x264 if you really need to match a specific bitrate [04:03] <Samus_Aran> klaxa: well if you have a very high quality source and want to maximise the quality, you'd want to use the whole DVD-5 or -9 space [04:03] <klaxa> DVD can't into h264 though [04:03] <klaxa> data dvd yes [04:03] <klaxa> video dvd no [04:04] <Samus_Aran> I meant data DVD for the 264 file [04:04] <frankdrey> oh, that brings me to another question...not too related to ffmpeg though [04:04] <klaxa> i don't think that was what he intended to do though [04:04] <frankdrey> would the 264 burnt on data dvd play in the average bluray player? [04:04] <klaxa> good question [04:04] <klaxa> i don't have a bluray player [04:04] <Samus_Aran> frankdrey: when I tried using FFmpeg in the past to encode DVDs, I was never satisfied with the quality, and I was unable to make it use high bitrates [04:04] <klaxa> i hope you have a lot of dvds [04:04] <Samus_Aran> it would produce low bitrate low quality encodes no matter what options were used [04:05] <Samus_Aran> frankdrey: there are multiple ways Blu-Ray players can play videos. one is as a data file, the other is as a Blu-Ray (they can be stored on DVDs or Blu-Ray discs) [04:06] <Samus_Aran> they can all play Blu-Ray formatted content, but may or may not play custom encoded stuff [04:06] <klaxa> i guess in the end it depends on the player [04:06] <frankdrey> Samus_Aran: yesterday, I added on a -b:v 3800k to get the dvd a little smaller (it was apparently going at 4000k most of the time) and it didn't seem any better then what we were making with Freemake [04:06] <Samus_Aran> .mp4 AAC/AVC will usually work if it's in standard encoding options [04:07] <frankdrey> and dvds aren't very high quality as is.... so quality isn't #1, but stability [04:07] <frankdrey> freemake crashes a LOT [04:07] <frankdrey> alright, I guess I'll ask people if they have bluray players that play the files...maybe give them a test disc [04:07] <Samus_Aran> crashing software gets tiring. that's why I left Windows 98. :p [04:07] <frankdrey> lol [04:08] <frankdrey> yeah, I set up an Arch VM with the hopes of using it for encoding/burning [04:08] <frankdrey> sadly, VirtualBox is crashy with DVD passthrough :( [04:08] <frankdrey> can't do native, SecureBoot :/ [04:08] <Samus_Aran> that's disappointing [04:09] <Samus_Aran> I had lots of issues with passthrough and VirtualBox [04:09] <Samus_Aran> for hard drives [04:09] <frankdrey> it would burn...and crash right after it finished [04:09] <frankdrey> dvd was fine... [04:09] <frankdrey> but if i was burning multiple, the first finishes, crashes, rest are now stuck, have to reboot to get them out [04:10] <Samus_Aran> might want to dual-boot. [04:10] <Samus_Aran> or set up one of those Linux things that runs natively in Windows [04:10] <frankdrey> SecureBoot :/ [04:10] <Samus_Aran> anyhow, this is off-topic for this channel. :) [04:10] <frankdrey> It may be backwards compatible with BIOS bootloaders though...so if I can find a second HDD or flash drive.. [04:10] <frankdrey> yes :p [04:16] <frankdrey> hmmm...I'm not finding any mpeg2/dvd guides [04:17] <frankdrey> specifically how crf works for it [04:26] <Timothy_Gu> Did you try QEMU [04:26] <Timothy_Gu> iive: I did. Seems like a good resource [04:27] <frankdrey> Timothy_Gu: does that do Vt-x? [04:27] <Timothy_Gu> I think so. [04:27] <frankdrey> will try, thanks [04:27] <Timothy_Gu> I might wanna check the lengthy QEMU man page [04:27] <Timothy_Gu> I mean you might ... [04:39] <frankdrey> as far as I can tell, only under Linux...but off-topic again :P thanks though, I think I'll figure that part out :D [04:40] <frankdrey> ok, I guess I'll just go with -crf 18 and set bitrate as per bitrate*time=size ? [04:53] <frankdrey> see...i'm not finding anything on how this works with mpeg2 [04:53] <frankdrey> just x264 [04:53] <frankdrey> not sure if the same rules apply [04:54] <frankdrey> (nobody cares about mpeg2 anymore, eh?:P) [04:54] <Samus_Aran> frankdrey: I was never able to get MPEG-2 encoding working well with FFmpeg, myself. and I also found it confusing. [04:56] <frankdrey> well...I mean it works pretty well right now, I'd just like file size to be a little more predictable [04:57] <Samus_Aran> that was what I was never able to figure out. :p [04:57] <Samus_Aran> it was always too small or big [04:57] <Samus_Aran> usually too small [04:57] <frankdrey> ah :p [05:05] <frankdrey> what about a VBR with max bitrate = max size / time [05:05] <frankdrey> max and target bitrate... [05:07] <frankdrey> wait, in that case, might as well use cbr with that bitrate >.> [05:07] <frankdrey> blargh... [05:08] <frankdrey> i'll go with two-pass encoding for dvd's and i'll use the crf for h.264 [05:09] <Samus_Aran> just be aware crf doesn't produce a predictable size. it can vary massively, depending on the content [05:10] <Samus_Aran> and read the description of crf if you haven't, as it's not a linear scale [05:10] <frankdrey> yeah, read it [05:10] <frankdrey> I guess it doesn't matter too much [05:10] <frankdrey> just so we get it down to a decent size [05:11] <frankdrey> I doubt we'll be burning those x264 dvd's [05:11] <frankdrey> i keep using x264 and h.264 interchangeably...should go look up the difference [05:15] <Samus_Aran> afaik, h.264 is the specification by the Motion Pictures Expert Group (MPEG). x264 is the encoder that goes with libx264, an open source implentation of h.264 [05:16] <Samus_Aran> but all of the MPEG stuff is patented, so open source apps are usually in grey areas [05:16] <frankdrey> aha [05:18] <Samus_Aran> they generally leave open source apps alone until they're put into commercial produts, then they quickly send in lawyers [05:18] <Samus_Aran> *products [05:19] <frankdrey> is using this in a church "commercial"?:p [05:21] <Samus_Aran> they don't seem to care about people encoding their videos, but always if they're selling a product, such as set-top boxes like TV recorders or video game consoles [05:21] <frankdrey> ah I see [05:21] <Samus_Aran> they make huge amounts from licenses [05:22] <Samus_Aran> music players have so many licenses, heh. MP3, WMA, AAC, etc. [05:22] <Samus_Aran> it's unfortunate that FLAC and Ogg/Vorbis and other open source ones don't have widespread support [05:24] <frankdrey> I wonder if I should convert my music to an open format... [05:24] <frankdrey> I strongly dislike RMS though... [05:25] <frankdrey> don't want to support him xD [05:30] <Samus_Aran> unpatented formats make sense. [05:30] <Samus_Aran> everyone benefits [05:40] <Timothy_Gu> Frankdrey: try ALAC [05:41] <Timothy_Gu> It's lossless, used by iTunes, and is open [06:08] <frankdrey> I doubt my crappy old phone will play it :p [06:46] <Samus_Aran> I would assume Apple Lossless would be patented. Apple likes to patent everything from scrollbars on up [06:47] <frankdrey> Apple once sued Samsung for having doors in their buildings [06:47] <Samus_Aran> heh, wouldn't surprise me [06:47] <frankdrey> I should wrote for The Onion [06:48] <frankdrey> Write [06:48] <Samus_Aran> http://www.theonion.com/articles/42-million-dead-in-bloodiest-black-friday-… [06:48] <Samus_Aran> just read that one [06:48] <Samus_Aran> heh [06:49] <Samus_Aran> I think software patents are not good for humanity. [06:49] <Samus_Aran> it is patenting ideas [06:49] <Samus_Aran> ideas shouldn't have owners [06:50] <frankdrey> I'm still split over the issue [06:51] <frankdrey> People need money to live [06:51] <Samus_Aran> it doesn't provide people with money to live, it takes it away [06:51] <frankdrey> Working another job, you may not have time to work on software [06:52] <Samus_Aran> patents only benefit the largest multinational corprations, to stifle competition [06:52] <frankdrey> But when software is your job [06:52] <frankdrey> I don't think so... [06:52] <Samus_Aran> Apple, IBM, Microsoft, Google, etc. all have thousands of patents. they could sue each other into oblivion... they instead agree to not sue each other [06:52] <Samus_Aran> and they then attack all the small companies and individuals [06:52] <Samus_Aran> it's a giant scam [06:53] <Samus_Aran> sane countries do not accept software patents. [06:53] <frankdrey> Hmmm [06:53] <Samus_Aran> they cross-license their patent portfolios [06:53] <frankdrey> Do small companies have patents? [06:53] <Samus_Aran> the big corporations destroy any small company that poses a threat [06:54] <Samus_Aran> sure, small companies can have patents, but they don't have the budget required to fight patent lawsuits [06:55] <Samus_Aran> big teams of lawyers are expensive [06:56] <Samus_Aran> patents are not supposed to apply to ideas, only manufacturing processes and inventions. off-topic again. I'm off to encode video and try out some of the filter [06:59] <frankdrey> Eh. Its not like anyone else is talking :p [09:56] <iMath> how to get the duration of a video file by ffmpeg command line ? [09:57] <viric> ffprobe will report that to you [09:58] <iMath> I am a newbie to ffmpeg ,can u give the command line ? [10:29] <iMath> what does this line return [10:29] <iMath> <(find . -name '*.wav' -printf "file '%p'\n") [10:29] <iMath> if I have three wav files named 1.wav ,2.wav ,3.wav in current dir ? [10:54] <bouba> hi there, i have a couple of broken H264/AAC files, and i'd like to find what is the issue...any1 knows where to begin please ? i already tried atomicparsley, dd and ffmpeg [11:25] <hrehf> hey, when i dump out images with something like ffmpeg -r 0.01 -ss 3 test/%3d.png -i <movie>, the first three frames that are dumped seem to consecutive frames instead of in 100s steps -- any idea why that might happen? (i'm using a fairly recent (~2weeks) windows build)_ [12:19] <_d0t> hello gentlemen [12:19] <_d0t> how do I force vdpau decoder to be used? [12:37] <Samus_Aran> bouba: what errors do the files have? what type of codecs are in what type of containers? why are they broken? [12:37] <Samus_Aran> what's the source? [12:38] <Samus_Aran> hrehf: try putting the -ss after the filename for accurate seeking, if it's not a long seek (it will decode the movie up until that point). sometimes if it's not accurate it will get confused about starting frames [12:40] <Samus_Aran> seeking in FFmpeg has quite a few bugs [12:41] <Samus_Aran> are you saying that you're getting a single frame repeating a few times, or it's giving you a different framerate at the start? [12:46] <hrehf> Samus_Aran: okay, i will try that [12:47] <Samus_Aran> frankdrey: I'm not sure if this channel cares about off-topic, but most don't want it. makes it hard for people to scroll past the fluff. :) [12:47] <hrehf> Samus_Aran: hrm, too bad, still happens [12:48] <Samus_Aran> hrehf: and the second question? [12:48] <hrehf> Samus_Aran: i think it's dumping the first 3 frames of the movie, and then skips correctly as i specified [12:50] <hrehf> Samus_Aran: okay, i double checked, (now) it seems like its dumping the first frame twice, then a frame that's quite near after that, and then proceeds as planned [12:52] <hrehf> Samus_Aran: hmm, even without the -r (so dumping every frame i presume), the first two frames that are dumped are identical images [12:52] <Samus_Aran> just a guess, might be dumping frames normally until it reaches the first 0.1 point [12:53] <Samus_Aran> my way to avoid the duplicate frames was to tell ffmpeg to ignore the first few frames [12:53] <Samus_Aran> when seeking and frame dumping [12:54] <hrehf> Samus_Aran: not sure what is happening here, but even without -ss and -r (so just -i <movie> <out>), the first two frames are identical. And they are identical to the frames written with -ss 6 [12:54] <hrehf> Samus_Aran: yeah, seems like its doing that [12:54] <hrehf> Samus_Aran: how do i ignore the first frames? [12:55] <Samus_Aran> with the -ss 6, after the repeat frames, does it go to second 6? [12:55] <hrehf> so, ffmpeg -r 0.01 -ss 6 -i <mov> <out> ? [12:56] <Samus_Aran> I think the -r should be before the output file if you're trying to set the option for the output [12:57] <hrehf> Samus_Aran: hmm, in vlc it seems more like second 2 or 3 [12:58] <Samus_Aran> http://www.ffmpeg.org/ffmpeg-all.html#select_002c-aselect [12:58] <Samus_Aran> that's the thing that sets which frames get included in the ouput [12:58] <Samus_Aran> or time ranges [12:59] <hrehf> ah, okay [12:59] <hrehf> so i use that instead of -ss [12:59] <Samus_Aran> for example: -vf 'select=between(n\,3\,100)' [12:59] <hrehf> thanks! [12:59] <Samus_Aran> the thing about select is it is a filter, so it needs to decode all the frames, there's no seeking [12:59] <Samus_Aran> it simply decides if a frame should go to the output [13:00] <Samus_Aran> you can easily tell it to include every 50th frame or whatever [13:00] <Samus_Aran> but it will decode all of them [13:00] <Samus_Aran> so it's slow, but accurate [13:00] <Samus_Aran> what is your overall objective? [13:00] <Samus_Aran> thumbnails of a movie? [13:02] <hrehf> yeah [13:02] <hrehf> i could easily just throw away the first few frames :-) [13:03] <hrehf> but i'm alos using it to dump videos to frames for video editing, so it's nice to know what's actually happening [13:03] <Samus_Aran> basically, -ss is great when it works, but it often causes timing issues and other confusion [13:04] <Samus_Aran> do you get any weirdness with select? [13:04] <Samus_Aran> -vf "select=not(mod(n\,100))" [13:04] <Samus_Aran> something like that, would do every 100 frames [13:04] <Samus_Aran> and should be perfectly accurate [13:08] <hrehf> Samus_Aran: yeah, took me a while to check out the filters. i'm using gte(t,6)*(isnan(prev_selected_t)+gte(t-prev_selected_t\,10)) now, and it seems to work fine. [13:09] <hrehf> thanks for all your help! [13:09] <Samus_Aran> hrehf: you're welcome. glad it's working the way you want. :) [13:10] <Samus_Aran> that's a long filter [13:10] <Samus_Aran> well, for select [13:10] <hrehf> ;-) [13:10] <Samus_Aran> some filters are waaaaaaaay too long [13:10] <Samus_Aran> several lines of options [13:11] <Samus_Aran> I've been learning how to use FFmpeg for high quality video production for YouTube. [13:11] <Samus_Aran> cutting segments and putting them together, fading in and out audio and video, adjusting colours [13:12] <Samus_Aran> my computer is too crappy to run a video editor [14:21] <bouba> Samus_Aran: thx for help, the files were generated from a custom IP camera thats generating H264/AVC streams (hardware) and muxed with libx264 (software)...they are probable broken because the camera did not correctly mux the H264 bit stream [17:12] <t4nk879> hi [17:13] <Samus_Aran> bouba: ah, okay. did you try putting them into a new container, such as: ffmpeg -i broken -codec copy output.mkv [17:13] <Samus_Aran> t4nk879: greetings [17:13] <t4nk879> i am broadcasting with ffmpeg (mp4 codec) with an input coming from vlc, everything is perfect but when it plays the next movie, ffmpeg is freezing [17:14] <t4nk879> the input is udp from vlc [17:14] <Samus_Aran> bouba: what errors were you getting with them? you could try to enable debug output to get more details from codecs [17:15] <t4nk879> what could be the problem any idea ? [17:15] <Samus_Aran> t4nk879: presumably it is sending the end-of-stream info at the end of the first, I would think ffmpeg would quit, but I've never done something like that [17:16] <t4nk879> i use the vlc option keep so it's supposed to not send an end of stream [17:17] <Samus_Aran> what happens if you turn that option off, does it quit? [17:17] <t4nk879> i did not try bcs it's not supposed to work without it [17:18] <Samus_Aran> is there any output on the console when it freezes? [17:18] <Samus_Aran> try enabling debug output to see if there's anything useful in that before it dies [17:18] <t4nk879> is it -debug ? [17:20] <t4nk879> i tried without keep and it's the same thing [17:20] <t4nk879> i don't know how to use the debug i have to check first [17:20] <Samus_Aran> try -loglevel verbose [17:20] <bouba> Samus_Aran: i get the following : [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1ca69c0] moov atom not found INPUT.mp4: Invalid data found when processing input [17:20] <Samus_Aran> I've only used it a couple times [17:21] <Samus_Aran> bouba: what does "file" say it is? [17:21] <Samus_Aran> bouba: it may be raw video without a container [17:21] <bouba> Samus_Aran: INPUT.MP4: ISO Media, MPEG v4 system, version 1 [17:21] <Samus_Aran> that's pretty vague, heh [17:22] <bouba> Samus_Aran : perhaps AtomicParsley can help ? [17:22] <Samus_Aran> try any media identifier you have [17:22] <Samus_Aran> if it's raw, you can tell ffmpeg what it is and it should work [17:23] <bouba> Samus_Aran: i'm 99% sure that it's a H264 High Profile 4 + AAC bitstream [17:23] <bouba> Samus_Aran: i'll check media info [17:23] <t4nk879> i tried with verbose and i get this message : Error while decoding stream #0:0: Invalid data found when processing input ; it repeats again and again [17:25] <bouba> Samus_Aran: mediainfo seems to validate MPEG4 muxer "Inform : MPEG-4 (Base Media): 449 MiB" [17:26] <bouba> AtomicParsley says : "Atom ftyp @ 0 of size: 32, ends @ 32 [17:26] <bouba> Atom free @ 32 of size: 8, ends @ 40 [17:26] <bouba> Atom mdat @ 40 of size: 470401518 (0*), ends @ 470401558" [17:27] <bouba> Samus_Aran: if the mdat atom is there, so the data stream can be remuxed no ? [17:28] <Samus_Aran> bouba: I don't know enough about the internals. does this do anything: ffmpeg -format h264 -i input.mp4 [17:28] <Samus_Aran> that should give file info if it can read it [17:28] <Samus_Aran> res, duration, etc. [17:30] <Samus_Aran> t4nk879: I really don't know much about streaming, sorry. maybe someone more skilled is around the channel. :) [17:30] <mbelaninja> hi everyone. I need to transcode mp4s into hls and embedd subtitles into the hls stream. It looks like ffmpeg can't do this? [17:30] <Samus_Aran> bouba: try putting different formats before the input to see if it helps. you can list them with: ffmpeg -formats [17:30] <Samus_Aran> I need to get back to work, later. [17:32] <t4nk879> ok thanks [18:10] <ltsampros> hello [18:11] <ltsampros> a very simple qeuestion. let's just say that some is still on 0.5 (bike shed) [18:11] <ltsampros> is there a restriction on the version of x264 he can use ? [18:11] <ltsampros> (hypothetical scenario) [18:11] <JEEB> most probably yes, not to mention that using x264 is much harder with such an old version [18:12] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=tag;h=110c4b2a211fbf6779edb63619316… [18:12] <JEEB> 2009 :D [18:13] <ltsampros> i know. [18:13] <ltsampros> it was a completely hypothetical scenario [18:13] <JEEB> even in hypothetical scenarios you would most probably not find support [18:13] <JEEB> if you hit a problem [18:15] <ltsampros> i'm looking mostly for a compatibility matrix [18:15] <JEEB> nobody is keeping a count of any kind [18:15] <ltsampros> between ffmpeg branches and x264 versions/tags/builds whatever they call them these days [18:16] <JEEB> after support was added for the x264's internal presets, I don't think there were many if any things that broke compatibility [18:16] <JEEB> but the problem then rather become possible problems with input or output [18:17] <ltsampros> x264_encoder_open breaks [18:17] <ltsampros> as well x264_log as well [18:18] <JEEB> I have no idea what exactly you're talking about and in what context :P [18:22] <ltsampros> JEEB http://upstream-tracker.org/versions/ffmpeg.html this should explain it better [18:23] <JEEB> yes, but I can't comment on any fails with x264 without you giving me some point to base the discussion on [18:24] <JEEB> also x264 has the API version, which changes every time there is a change there (which might or might not need code changes on the users' side) [18:25] <ltsampros> I just tried to use the latest x264 release with ffmpeg 0.5 (libavcodec) [18:25] <JEEB> yes, now tell me what exactly failed and I might be able to give you more information on why exactly it failed [18:26] <ltsampros> ok. [18:26] <ltsampros> stacktrace ? [18:28] <JEEB> so it actually was able to link? [18:30] <ltsampros> yeap only had to change the definition of x264_encoder_open() [18:30] <JEEB> so no, it doesn't link [18:30] <JEEB> as vanilla [18:31] <JEEB> so if you want to see what was the oldest version still supported, you could just look for the log of that one line in x264.h that defines the API version [18:31] <JEEB> and go to ~1 of the commit that changes it always to get the last commit from the previous API version [18:33] <ltsampros> I am using something like this git log --pretty=oneline -S"x264_encoder_open" [18:34] <JEEB> if it's a specific change to the actual function then yes, you can find the newest API version with that old definition like that [18:35] <ltsampros> it's just a change in the preprocessor that glues/appens x264_build number to x264_encoder_open(). [18:35] <ltsampros> I believe that is the start of my problems [18:35] <ltsampros> anyhow [18:35] <JEEB> uhh [18:35] <JEEB> if _that_ is the problem [18:35] <JEEB> then you are using the headers wrong [18:35] <JEEB> very, very wrong [18:35] <JEEB> and the library [18:36] <JEEB> you are supposed to be using the header and library from the same API version [18:36] <JEEB> thus basically if you get a version mismatch it will shout at you :P [18:37] <ltsampros> good old 2008 [18:37] <JEEB> eh [18:38] <JEEB> I don't see the connection [18:41] <Mavrik> hmm, does ffmpeg have a filter to adjust brightness/contrast? [18:41] <Mavrik> or at least luma/chroma directly? [18:42] <saste> Macey, lut [18:42] <saste> Mavrik, lut [18:43] <Mavrik> ah, that's it yea, thanks [21:55] <Rick28> Hey, I'm fairly new to ffmpeg. I know that I can compile ffmpeg to my needs, but I found a script at http://ffmpeginstaller.com/ which has all the packages I need. Is this a known script? Can I trust this site? Or is there another popular install script you can recommend? [21:57] <JEEB> there are compilation guides on the trac [21:58] <JEEB> and you should compile only those external encoders that you will be using [21:58] <JEEB> decoder-wise almost everything (there are like a couple of exceptions) is within libavcodec itself [21:58] <Rick28> JEEB: thanks, why is that? Performance? [21:59] <JEEB> no, because in 99% of all cases you just don't need the rest of it and you will be wasting your time [21:59] <JEEB> unless you are creating a package for a linux distribution I see many of the things that you can bolt onto ffmpeg rather unneeded :P [22:00] <Rick28> JEEB: basically I need x264 video and aac audio only. What do you suggest? [22:00] <JEEB> two things in addition to what's internal [22:00] <JEEB> x264 and fdk-aac [22:00] <JEEB> that's it [22:01] <Rick28> JEEB: that helped a lot! Thank you! [22:01] <JEEB> look at the guides on the trac [22:01] <Rick28> will do [23:23] <Ricky28> Are warnings while compiling ffmpeg normal? e.g. something like this "vp9.c:2151:24: note: topleft was declared here" [23:23] <Ricky28> Or this: ffmpeg_opt.c:2076:24: warning: m may be used uninitialized in this function [-Wuninitialized] [23:23] <cbsrobot> Ricky28: it's normal [23:23] <cbsrobot> and Ricky28 ... patch welcome :) [23:24] <Ricky28> cbsrobot: thanks. unfortunately I'm not that experienced :) [23:24] <Ricky28> cbsrobot: does this make the precompiled versions better than following the steps via trac? [23:26] <cbsrobot> doesn't matter much. See what JEEB said few minutes ago. [23:27] <Ricky28> cbsrobot: thanks [23:42] <ian_m> I am at a loss here... [23:43] <ian_m> if I capture at 30 fps from x11grab it works fine [23:44] <ian_m> however if I capture simultaneously from a webcam and overlay the two streams, I get 4-5 fps [23:50] <ian_m> here is what I get just using x11grab http://pastie.org/8524047 [23:51] <ian_m> libx264 gets approximately 30 fps [23:53] <llogan> ian_m: that does not look like your full command [23:54] <ian_m> here is what happens when I try to overlay my webcam http://pastie.org/8524055 [23:55] <ian_m> llogan: that command is just x11grab [23:55] <ian_m> llogan: to show that it seems to work by itself [23:56] <ian_m> llogan: sorry you're right [23:56] <ian_m> full command is ffmpeg -f x11grab -video_size 1680x1050 -framerate 30 -i :0.0 -y test.mkv [23:57] <ian_m> when I overlay the webcam libx264 only seems to get 4-5 fps, but I thought the overlay filter should take the timestamps directly from its first input stream [23:59] <ian_m> I suspect that maybe the timestamps from x11grab are incorrect? When I specify -r 30 to x11grab I at least get 30 fps to the encoder... but I want the real timestamps [00:00] --- Tue Dec 3 2013

1 0

ffmpeg-devel.log.20131201
by burek 02 Dec '13

02 Dec '13

[00:50] <ubitux> BBB: what does "fm" stands for? [00:50] <ubitux> same question for the E, I and H threshold [00:54] <ubitux> btw, should i add threading to the coverage fate instance? [21:20] <durandal_1707> michaelni: what's about those mans commits reverts from yadif? [21:21] <durandal_1707> exp. "lavfi: convert input/ouput list compound literals to named objects" is pathetic [21:21] <durandal_1707> how such changes could be considered to have copyright [21:22] <durandal_1707> does it means I can not change it back? [21:23] <nevcairiel> you can change it back, you just cant copy the commit [21:23] <wm4> what if the new change is almost literally the same as the old change? because it's trivial and there's no other way to do it? [21:23] Action: durandal_1707 was there any group lobotomy recently? [21:24] <nevcairiel> if you want to do it right, then dont look at the commit, just take the code and make it look good again. if you come to the same exact result in the end, there is no copyright violated [21:25] <nevcairiel> oif course someone could still claim that [21:25] <nevcairiel> but good luck in a court [21:25] <wm4> copyright sure is a strange thing [21:25] Action: durandal_1707 takes gun [21:33] <durandal_1707> K&R is copyrighted too? [21:34] <nevcairiel> i doubt its possible to win a copyright fight on whitespace changes [21:34] <nevcairiel> but if in doubt, easier to revert one commit and re-format the code later [21:49] <cone-359> ffmpeg.git 03Diego Biurrun 07master:3cd612d44789: gitignore: Ignore multilibrary example programs [21:49] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:d4268634155d: Merge commit '3cd612d44789948f72b52944474e0870c5c60964' [21:56] <cone-359> ffmpeg.git 03Diego Biurrun 07master:7b05845b1523: doc: Try to find nonstandard Perl path from the environment [21:56] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:003f405caf9f: Merge remote-tracking branch 'qatar/master' [22:11] <ubitux> BBB: the most annoying part is the !flat 1/2B case at the end :p [22:16] <nevcairiel> this donmoir person sure has some deranged views on things [22:17] <ubitux> why is he talking about avresample now? [22:17] <ubitux> oO [22:17] <ubitux> wth is going on in this thread [22:19] <ubitux> > the interface avpicture_delinterlace is elegantly simple [22:19] <ubitux> what am i reading [22:19] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:b2c89453dcc1: avformat/avisynth: remove duplicate av_new_packet() call [22:20] <nevcairiel> apparently API simlicity and resource usage are more important to him then actual deinterlacing quality [22:23] <nevcairiel> because the avpicture_deinterlace is really quite terrible [22:23] <nevcairiel> its a simple field blend, iirc [22:25] <wm4> he also complains about how yadif is "twice as slow" [22:27] <Compn> saste : bcourdurier is busy with ffmbc :) [22:28] <BBB> maybe I'll split vp8dsp.asm also [22:28] <nevcairiel> creating a filtergraph may need more boilerplate then necessary, but the actual filtering of the frames is not that bad (once you figured out how to interact with the buffer source/sink), not sure what goes on in his head :) [22:28] <ubitux> BBB: isn't it already split? [22:28] <nevcairiel> i thought diego split the loopfilter out or something [22:28] <ubitux> i thought diego did the split [22:28] <ubitux> ah, only lpf [22:29] <nevcairiel> admittedly the loopfilter is more asm then all that remains [22:29] <j-b> ah, nice, finally the reverts [22:30] <Compn> what flame level are we at now ? [22:30] Action: Compn goes to read mailing list [22:30] <nevcairiel> amazingly, the whole thread seems to stay quite clam @ deint discussion on the list [22:30] <nevcairiel> calm* [22:35] <wm4> to be fair, as much as the deint function sucks, there's no reason to actually remove it [22:35] <wm4> it could be dumped into libpostproc or something instead [22:35] <Compn> you mean the original deint stuff ? [22:35] <Compn> for people who dont want to use lavfi ? [22:35] <Compn> sure [22:35] <wm4> the lavc one [22:35] <nevcairiel> it should be removed from avcodec, if you want to preserve it in a code grave like postproc .. go ahead [22:36] <ubitux> Compn: no, just for don moir [22:36] <Compn> lol [22:36] <wm4> actually I think libpostproc has some deinterlacers too... [22:36] <ubitux> it has indeed [22:37] <nevcairiel> ever since yadif got slice threading, I havent had any speed complaints anymore [22:37] Action: Compn wonders if software will be advertising the fact that it has the amazing 'yadif deinterlacer' in the future [22:37] <Compn> heh [22:37] <Compn> has anyone ever done double blind deint comparasion ? [22:38] <Daemon404> yadif isnt amazing [22:38] <Daemon404> people use it because its realtime [22:38] <nevcairiel> yeah, anything really better is just extremely slow [22:39] <Compn> i'd agree with you except its the only deint i've seen anyone talk about in the past 5+ years [22:39] <Daemon404> you mstnt go on doom9 much [22:39] <Daemon404> QTGMC has been king for ages [22:39] <Compn> not with the security in their forums :P [22:39] <Daemon404> lol [22:39] <Daemon404> theyre on vb from like 2006 [22:39] <Daemon404> its awesome [22:39] <nevcairiel> QTGMC is pretty good, but also pretty slow [22:39] <Daemon404> 0 fucks given [22:40] <Compn> not that i use real passwords anywhere anyway [22:40] <Compn> nor real emails, real names, real info of any kind [22:52] <ubitux> https://github.com/ubitux/FFmpeg/compare/vp9-lpf#diff-f5653acbc04f21d22eaa6… [22:52] <ubitux> i wonder if i'm doing this right& [23:30] <ubitux> BBB: we can't mux vp9 ivf with ffmpeg? [23:48] <BBB> ubitux: I've never tried [23:51] <ubitux> ok [23:51] <ubitux> BBB: not sure if it's broken on purpose but libvpx/vp90-2-07-frame_parallel.webm has artifacts at the end [23:52] <BBB> ? [23:52] <BBB> not sure [23:52] <ubitux> (same for libvpx/vp90-2-05-resize.ivf btw) [23:53] <BBB> resize is not supported [23:53] <ubitux> ok [23:54] <ubitux> anyway, lpf in progress, i'll probably be done at the end of the month [23:54] <ubitux> gtg, 'night [23:54] <BBB> g'nite [00:00] --- Mon Dec 2 2013

1 0

ffmpeg.log.20131201
by burek 02 Dec '13

02 Dec '13

[00:34] <Samus_Aran> germanstudent: I'm not sure how to overlap tracks with ffmpeg, but you can easily dump both to .wav files, then merge them with something like Audacity [00:39] <germanstudent> Samus_Aran, thanks, I was hoping to use -filter_complex amerge to avoid a GUI. I think I have to try more

1 0