Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2013

1 participants
62 discussions

ffmpeg-devel.log.20131015
by burek 16 Oct '13

16 Oct '13

[00:00] <smarter> michaelni: wait, there's no need to rush this [00:01] <iive> smarter: wait for what and how long? [00:06] <smarter> wait until it's merged until libav, you're welcome to help if you think this is taking too long [00:07] <mraulet> can I ask a question for those who participated to AVC/H.264? how was the code before it has been accepted by ffmpeg? [00:08] <iive> smarter: is there even a review process going on there? [00:09] <mraulet> yes [00:09] <iive> on the maillist? [00:09] <mraulet> yes [00:09] <iive> I don't see any comments. can you provide a link? [00:12] <wm4> iive: libav.org [00:12] <iive> e.g. http://lists.libav.org/pipermail/libav-devel/2013-October/051938.html [00:13] <mraulet> http://patches.libav.org/patch/43132/ [00:13] <iive> I see patchsets and no comments or review at all. [00:13] <smarter____> There's a TODO here: https://etherpad.mozilla.org/lKtGkT3W3b [00:14] <mraulet> this is not the first round on libav [00:14] <Paranoialmaniac> iive: http://lists.libav.org/pipermail/libav-devel/2013-August/049753.html [00:14] <smarter____> and recently people have been contributing changes instead of commenting on the patch [00:15] <iive> i think i've seen previous rounds on libav, with the same amount of comments (0) [00:15] <smarter____> the first round a year ago did have some comments at least :) [00:16] <iive> so either there is no discussion, or everything happens behind closed doors. [00:17] <mraulet> irc [00:17] <mraulet> is not so closed [00:17] <iive> it is, because I cannot see the discussion. [00:17] <iive> e.g. this channel is publicly logged [00:18] <smarter____> So the problem is that libav-devel is not logged? [00:20] <smarter____> people post their proposed changes to some public branch, like https://github.com/lu-zero/libav/commits/hevc_upstream [00:20] <iive> look... [00:21] <iive> you can do development however you like... in norad bunker if you feel like it. [00:21] <iive> however for outside spectator the whole thing is solid wall. [00:22] <iive> there is zero information when that thing would be merged in libav. [00:22] <iive> there is zero information of the issues that should be resolved. [00:22] <smarter____> "When it's done" [00:22] <smarter____> there's a TODO I just posted [00:22] <smarter____> I think you're exagerating, but I agree that the whole process could be better [00:23] <iive> lim (when it's done)=infinite. [00:23] <mraulet> and those split does not help [00:23] <iive> libav is not done, ffmpeg is not done, x264 is not done... i guess xvid is done... [00:24] <mraulet> in fact we are in between an uncomfortable position [00:25] <mraulet> so you can take your own responsabiltty, the code is available btw [00:25] <smarter____> iive: I'm not sure what your point is, do you want to help in some way? [00:26] <iive> go on. [00:26] <kierank> smarter____: personally I think you should let them commit it [00:26] <kierank> even though their reasons are wrong [00:26] <smarter____> kierank: I told them I was not opposed to it [00:26] <kierank> ah [00:26] <kierank> they'll get a ton of bug reports [00:26] <iive> so... you would not give explicit permission, because this would put you in odds with the libav people who are working on the project [00:27] <smarter____> libav people don't care [00:27] <smarter____> afaik [00:27] <iive> but you would be happy your code to be actually seen by the outside world. [00:28] <mraulet> yes we would... and we would like both community use the same code base [00:29] <iive> ffmpeg have no problem merging code. [00:29] <smarter____> iive: I'm just saying, if it was my decision I wouldn't do it now. It's your decision so you can do whatever you want [00:31] <iive> ffmpeg also have no problem merging work in progress. [00:31] <michaelni> mraulet, about h264, the first version commited ( to svn back then IIRC) lacked many things and had bugs, i see multiple references b frames, multiple slices after the initial code in the log [00:31] <michaelni> and i remember there where other decoders that where commited siilarly early [00:32] <iive> i think that the first vc1 code was bitstream parser only... but it might have been h264 too.. [00:32] <michaelni> more likely vc1 probably [00:32] <michaelni> and there where decoders that where commited with just intra support [00:32] <michaelni> and inter added later [00:33] <j-b> smarter____: come on, it's not your fault. [00:33] <iive> and this was during the time when the ffmpeg review process was harder than a boxing match. [00:33] <smarter____> j-b: what's not my fault? :) [00:33] <mraulet> doing a great decoder ^^ [00:33] <j-b> smarter____: if it is not merged. [00:33] <michaelni> and we even have some h263 variant that currently we can only decode intra frames of because its not known AFAIK how to decode the inter frames and its too rare format for anyone caring [00:33] <j-b> smarter____: it's almost impossible to get anything merged anyway. [00:34] <j-b> anything not trivial [00:34] <j-b> JBr0ck29! [00:34] <j-b> :) [00:34] <j-b> An no, that's not my pass :) [00:35] <j-b> smarter____: seriously, both projects are impossible to work with. [00:35] <wm4> videolan fork of ffmpeg when? [00:36] <j-b> wm4: lol [00:36] <j-b> wm4: I hope you are not serious [00:36] <michaelni> tell me the git url ill add it to our download page :) [00:36] <wm4> j-b: half joking [00:36] <mraulet> okay so this decoder supports all conformance tests from 8 to 10 bits [00:36] <j-b> wm4: maintaining compatibility with 2 libavcodecs is already hard. [00:37] <mraulet> ahah [00:37] <j-b> wm4: 3 would be daunting [00:37] <wm4> well, that wouldn't exactly be the point [00:37] <Paranoialmaniac> btw, hevc is not finalized yet. michaelni, was h264 decoder commited at a draft? [00:37] <mraulet> hevc is finalized [00:38] <j-b> wm4: who would have the skillz to do that? [00:38] <Paranoialmaniac> ? h264 is finalized [00:38] <mraulet> transport of hevc is not [00:38] <michaelni> when was h264 finalized ? [00:38] <Paranoialmaniac> *h265 [00:38] <Paranoialmaniac> itu-t finalized h265 [00:38] <wm4> j-b: dunno, I thought vlc had manpower? I see many vlc devs around here [00:38] <Paranoialmaniac> but iso/iec have not finalized hevc yet [00:38] <mraulet> it has [00:38] <j-b> wm4: lol. the 4 of us? [00:39] <j-b> wm4: I see only one other deve here. [00:39] <michaelni> h264 was commited "Fri Apr 4 14:42:28 2003" according to git log dunno if that was final at that point or not [00:39] <mraulet> 15 march 2003 [00:39] <mraulet> and HEVC is 15 march 2013 [00:39] <Paranoialmaniac> mraulet: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35424 hevc is still in FDIS [00:40] <wm4> but seriously, since libav and ffmpeg will never ever merge again (unless hell freezes over), a third project could actually solve this mess [00:40] <wm4> (or create an entirely new mess, oh well) [00:40] <mraulet> FDIS means international standard at iso [00:40] <mraulet> it has been accepted on march 15 [00:40] <iive> "The standardization of the first version of H.264/AVC was completed in May 2003." wikipedia [00:41] <mraulet> I can send an email from MPEG boss and quoting him [00:41] <iive> so h264 was definitely committed at draft stage. [00:41] <mraulet> it seems so [00:45] <j-b> wm4: http://xkcd.com/927/ [00:45] <wm4> I know, I know [00:45] <wm4> ffmpeg vs. libav is like a chronic live-long disease [00:46] Action: wm4 grumbles [00:48] <mraulet> from my pov the decoder is quite stable and at least it is good that both libav and ffmpeg is working on the same patchsets [00:51] <mraulet> L&. said "10 years because AVC was approved in Pattaya on 2003/03/14" [00:52] <smarter____> I guess ISO standard != MPEG standard != ITU standard [00:53] <mraulet> yep [01:13] <smarter____> one thing I'm afraid of is that you'll starting accepting patches and start diverging. If you merge the decoder that means you maintain it and you should make an honest effort to get your changes in libav [01:14] <smarter____> If you can do that, then I'm happy with it [01:15] <smarter____> once again, this is my opinion, feel free to do whatever you want [01:17] <iive> smarter____: would you accept changes from ffmpeg? [01:18] <wm4> maybe a certain someone is right and ffmpeg just wants to claim to have a hevc decoder before Libav does [01:18] <smarter____> iive: sure, why not? [01:18] <michaelni> smarter____, if you and or mraulet would be maintainers of hevc in ffmpeg then you would have the last word on patches but you of course would need to review them on ffmpeg-devel and fix regressions if there ever are any reported to trak [01:19] <michaelni> and if you maintain it then you could ensure that all changes stay in sync with libav [01:19] <michaelni> if you make sure all things get into both projects [01:21] <iive> wm4: imho, libav are not merging it, because they want to point that ffmpeg always merges low-quality, unfinished, work in progress code. [01:22] <BBB> saste: it's true [01:22] <smarter____> there is no libav conspiracy, the goal as far as I know is to get the decoder in the next release [01:23] <iive> is there some time frame for that? [01:23] <smarter____> I don't know [01:23] <smarter____> you seem to be eager to merge it. Great, but you should accept the maintainance burden them [01:27] <michaelni> i dont mind to maintain the code, but iam baned of libav-devel and hated there, so this might not work out so well with keeping the 2 forks in sync [01:28] <michaelni> so i think it would be better if a more neutral person did maintain it [01:35] <smarter____> we might be able to work around the banning situation, I don't know [01:36] <smarter____> I'd be happy to help with keeping things in sync, but not to assume the responsabilities of the maintainer [01:36] <smarter____> anyway, I have stuff to do, bye [01:37] <saste> good night [01:38] <michaelni> saste, n8 [01:48] <cone-360> ffmpeg.git 03Michael Niedermayer 07master:1bf8fa75ee14: avcodec/x86/dsputil_init: fix cpu flag checks [06:59] <Compn> that was an interesting hevc discussion [07:00] <Compn> wm4 / j-b : i'm curious if you think splitting the devels has increased devel speed and decreased bikeshed/conflicts? [07:01] <Compn> wm4 / j-b : or if you dont think that has changed, or wont change if projects are merged? or maybe just dont even care about that and only care about one codebase [07:02] <Compn> i have a theory (which carl does not agree with) that the split has made things better in some respects [07:05] <Compn> or maybe i'm just subtly trolling [07:09] <JEEB> btw, I second smarter on that there's no "we're not merging hevc yet" conspiracy, elenril/koda/vmani have been working on getting it finalized quite a lot as far as I can see :V (merging changes, adding nalff support, general functional and visual prettification) [07:09] <smarter> lu_zero too [07:09] <JEEB> yeah [07:10] <JEEB> also picture-based threading but I am not sure if that's gonna go in with the first review or not [07:54] <ubitux> michaelni_: done, but i can't review api design alone; and i must say i didn't follow the teletext debate enough [08:14] <michaelni_> ubitux, thanks [08:16] <michaelni_> about API, maybe i dunno, iam not working on subtitles [08:17] <ubitux> you're more familiar with the codec caps typically [08:17] <michaelni_> s/maybe/maybe nicols/saste have comments/ [08:17] <ubitux> you might want to check if it's consistent with the way we deal with a & v [08:25] <michaelni_> ubitux, sounds consistent [09:23] <ubitux> lol @ 2 pass cosmetics [09:33] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:ab8cbfe0dd77: avcodec/x86/dsputil_init: remove duplicated sse2 idct init [09:33] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:c35d29a9c824: avcodec/x86/dsputil_init: move ff_idct_xvid_mmxext init [09:45] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:708b32b6f72c: http: Check the auth string contents and not only the pointer [09:45] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:0a6ce255ab49: Merge remote-tracking branch 'qatar/master' [11:18] <kierank> Compn: the julian assange film name drops FFmpeg [11:27] <Daemon404> wat [11:27] <Daemon404> also i heard that fil is full of bs [11:28] <Daemon404> film* [11:30] <Daemon404> [06:09] < JEEB> btw, I second smarter on that there's no "we're not merging hevc yet" [11:30] <Daemon404> -> [11:30] <Daemon404> http://i.imgur.com/ePDZN6V.png [11:47] <kierank> Daemon404: meh ffmpeg should just merge it [11:47] <Daemon404> im merely making fun of the conspiracy theories [11:47] <Daemon404> no comment on merging [11:47] <kierank> yes clearly there is an undertone of libav conspiracy here [11:48] <kierank> but who cares [11:51] <Daemon404> im not too concerned either way [11:51] <Daemon404> since there is no HEVC encoder whch isnt worse than x264. [11:51] <kierank> yes but there is some content out there [11:51] <kierank> not much admittedly [11:51] <Daemon404> where? [11:52] <kierank> on satellite [11:52] <Daemon404> really? [11:52] <Daemon404> wow. [11:52] <kierank> yes [11:52] <kierank> pre-encoded though [11:52] <Daemon404> ah [11:52] <Daemon404> probably MC [11:52] <kierank> ateme i think [11:52] <Daemon404> is ateme hw only now [11:52] <Daemon404> isnt* [11:52] <kierank> no ateme hevc is software [11:53] <Daemon404> oic [11:53] <kierank> imo they'd be pissing money away doing it in hardware [11:53] <Daemon404> i see very little public info on this [11:53] <Daemon404> other tan some tiny press releases [11:53] <Daemon404> the usual "Contact us for the useful info" [11:53] <kierank> ask the developer in #x265 if you want [11:54] <kierank> :) [11:54] <Daemon404> lul [13:09] <mraulet> kierank: how do you know? [13:10] <kierank> it's the one on eutelsat iirc [13:16] <mraulet> hardware encoder? [13:16] <mraulet> hmmm [13:17] <mraulet> this is an offline 4K encoding [13:17] <mraulet> could be HM [13:18] <saste> how can i get a patch file from this: https://github.com/FFmpeg/FFmpeg/pull/38/files [13:18] <saste> ? [13:29] <michaelni_> you could checkout the git repo and use git show, dunno if theres a easier way [13:30] <michaelni_> saste, https://github.com/FFmpeg/FFmpeg/pull/38.diff [13:31] <michaelni_> saste or this https://github.com/FFmpeg/FFmpeg/pull/38.patch [13:36] <saste> michaelni_, thanks [13:38] <kierank> mraulet: no software and offline [13:38] <kierank> could be hm [14:31] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:a1b9004b768b: avcodec/jpeg2000dec: fix context consistency with too large lowres [14:42] <cone-101> ffmpeg.git 03Paul B Mahol 07master:ccfb550b2c5d: fate: add pxr24 exr test [14:42] <dol> guys can anyone please look at the problem that I described in detail here: http://forum.doom9.org/showthread.php?t=169036 [14:43] <dol> I could solve it by increasing the width information by 1 but I don't think that this is the right way to do [14:43] <dol> so, could anyone explain me why I have this strange effect? [14:46] <michaelni_> dol, does this only happen with SWS_FAST_BILINEAR ? [14:46] <dol> I will check it with SWS_LANCZOS, just a moment [14:49] <dol> michaelni_, no I have the same issue with SWS_LANCZOS as well [14:49] <dol> it works without this effect if I set the width +1, but I dunno what is wrong [14:50] <michaelni_> whats the width and height ? also i guess you are only converting colorspace no change in w/h ? [14:51] <dol> michaelni_, width= 932 height=582 [14:51] <dol> and I dont do any scaling [14:51] <kierank> stride probably [14:51] <dol> +kierank, could you be more specific? [14:52] <kierank> is your linesize allocated correctly [14:52] <dol> +kierank, do you mean av_pic->linesize or fRGB->linesize? [14:52] <kierank> both [14:53] <dol> well, the first one comes from avcodec_decode_video2 [14:53] <dol> so it is filled there [14:54] <dol> for the second one, I use avpicture_fill and tehre I specify width and height [14:54] <dol> so I suppose it is filled there [14:54] <dol> when I debug the code, I see that the fRGB->linesize[0] = 3728 [14:54] <dol> the rest is 0 [14:56] <michaelni_> dol, also i assume this is the latest swscale from ffmpeg git ? (i mean not from 3 year old ffmpeg or so) [14:57] <dol> michaelni_, it is very recent [14:57] <dol> 1.1.2 [14:58] <ubitux> it's not at all then [14:58] <michaelni_> can this be reproduced with command line ffmpeg ? [14:59] <ubitux> dol: almost one year now [14:59] <cone-101> ffmpeg.git 03Stefano Sabatini 07master:3b9f8e7cd919: lavf/segment: simplify segment_count update [14:59] <cone-101> ffmpeg.git 03Billy Shambrook 07master:67e507e10e97: lavf/segment: log segments as they end to AV_LOG_VERBOSE [14:59] <dol> well, I have another system where I use the recent check out and it is also there [14:59] <dol> michaelni_, I tried it but couldn't reproduce [15:03] <dol> but how come width+1 can solve the issue? [15:03] <michaelni_> unscaled uses seperate codepathes in several cases, that could affect it [15:04] <michaelni_> also not being a multiple of 2,4,8,.. can affect things but the failure would then be expected on the %2!=0 side [15:05] <dol> michaelni_, yes but then I should have seen the same effect when I use command line [15:05] <dol> of course there I used y4m but shouldn't be different i guess [15:06] <michaelni_> i would first suggest that you try latest swscale [15:06] <michaelni_> and you could put a printf in the sws init to see what exact parameters are used by ffmpeg over the comad line [15:07] <michaelni_> including linesizes and flags [15:19] <cone-101> ffmpeg.git 03Stefano Sabatini 07master:1120fd7852cb: lavf/segment: simplify logic and fix !=0 check on segment_end return value [16:10] <Compn> kierank : lol! we need a clip now. [16:11] <Compn> i havent seen it, but i dont get why they need to even embellish the facts , the real story is exciting and crazy enough as-is... [16:11] Action: kierank makes no comment [16:14] <Compn> ah it doesnt have great movie scores [16:14] <Compn> how unfortunate :P [16:16] <Compn> oh thats why, its an adaptation of that guy who left [16:16] <Compn> er adaptation of that guys book [16:46] <cone-101> ffmpeg.git 03Michael Niedermayer 07master:51df6169091b: configure: Warn when inline asm is disabled for ICL [16:48] <Compn> hehe [16:48] <Compn> ffmpeg -i in.png out.png [16:48] <Compn> 600k > 800k [16:48] <Compn> maybe i have to play with compression [17:52] <cone-101> ffmpeg.git 03Derek Buitenhuis 07master:00aa24ffee91: tableprint: Fix use of a size_t print with MSVC [17:52] <cone-101> ffmpeg.git 03Derek Buitenhuis 07master:008014b5e724: tablegen: Don't use cbrtf in host tools [17:52] <cone-101> ffmpeg.git 03Derek Buitenhuis 07master:50867209930f: cos_tablegen: Don't use lrint [17:52] <cone-101> ffmpeg.git 03Derek Buitenhuis 07master:e51692114354: mpegaudio_tablegen: Don't use llrint [17:52] <Daemon404> 9 months later... [17:53] <Daemon404> michaelni_, ^ you can ignore the libav versions of these (which differ) during merge [17:54] <michaelni_> Daemon404, ok, lets hope i wont forget [17:55] <Daemon404> theyre almost the same [17:55] <Daemon404> so it will be a really obvious merge conflict [18:37] <saste> michaelni_, for example, we allow pix_fmt to be set through an int, and so far nobody complained about a bugreport with aformat=42 [18:40] <michaelni_> thats unrelated, we didnt change the meaning or decimal formats [18:42] <michaelni_> oF [18:47] <wm4> lol mixing up user-facing option parsing and internal API usages [18:56] <michaelni> saste, wm4, iam happy with any solution you two agree on [19:08] <saste> michaelni, it's getting boring, i'll push my latest patch if noone is against [19:08] <michaelni> +1 [19:08] <saste> more bikering about what should be deprecated can be done later (not by me) [19:08] <michaelni> ill post a patch about that if i dont forget [21:10] <michaelni> mraulet, smarter, did you after the standard vs draft discussion yesterday find a consensus ? iam asking as i really would like to have hevc support in ffmpeg 2.1 which we wil probably release soon [21:12] <smarter> You're the one who decides to merge or not [21:13] <JEEB> there are two samples still failing on PPC it seems [21:13] <JEEB> but it seems like mraulet got that one of the last uninitialized memory accesses done after some valgrinding was done [21:13] <smarter> If you merge it, I expect you to try very hard to not diverge, that's all [21:14] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:59352a07d856: avcodec: improve precission for cbrtf() emulation [21:16] <mraulet> michaelni_: can I have a request on you last commit related to hevc/h.265? I reallly would like the raw_parser to be HEVC [21:16] <mraulet> then I will think :-) [21:17] <mraulet> but yes I did fix some valgrind issues [21:18] <mraulet> https://github.com/OpenHEVC/libav/commits/hevc_upstream [21:19] <mraulet> when is the release? [21:19] <michaelni> i was hoping within the next 1-2 weeks [21:21] <mraulet> I have 2 yuv that I would like to get back [21:22] <mraulet> I support smarter on his request [21:27] <michaelni> I have no intent to diverge, but of course i will probably fix bugs if i run into any, and might even add a feature here or there if i find the time. [21:27] <smarter> and as I said, I hope you'll make it easy to port these changes to libav [21:32] <Compn> smarter : we need someone to mail patches from michael to libav list, since hes banned [21:33] <smarter> it'd be nice if an ffmpeg dev could do that [21:34] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:12cc3bf29ae4: avformat: rename a few more h.265 to HEVC [21:34] <Compn> ffmpeg devs seem busy doing other things. but its always possible [21:35] <Compn> maybe i could put a word out looking for a volunteer patch person to help with this [21:36] <Compn> nah [21:37] <JEEB> personally I'm fine with any help towards the development of the HEVC decoder :) If the PPC failures can get fixed, and then some general polish / fuzzing can be added, I'd almost say it'd be ready for prime time. [21:38] <mraulet> good [21:38] <michaelni> smarter, i dont think there will be that many patches, so you should be able to git fetch , cherry pick and send-email them yourself [21:51] <smarter> If you could ensure your patches apply to the https://github.com/OpenHEVC/libav/commits/hevc_upstream branch, that would be satisfactory [21:53] <mraulet> it sounds good to me too [21:58] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:2a19fcc12311: avcodec/mpegaudio_tablegen: remove dead branch [22:21] <michaelni> mraulet, smarter where can i find the samples for fate ? [22:28] <JEEB> michaelni, http://wftp3.itu.int/av-arch/jctvc-site/bitstream_exchange/under_test/ [22:29] <JEEB> koda has poked people regarding if they can be provided elsewhere (FATE mirrors) [22:37] <michaelni> JEEB, atm i first want to make sure the decoder passes the tests here locally [22:38] <michaelni> and thx for the link [22:41] <wm4> <Compn> smarter : we need someone to mail patches from michael to libav list, since hes banned <- oh god I'm dying [22:41] <wm4> most retarded thing I've heard today [22:44] <iive> well, i'm quite sure that there are libav developers who are well aware of the michaelni work in ffmpeg. [22:45] <iive> given how much effort they spend writing their own alternatives of his fixes. [23:53] <cone-770> ffmpeg.git 03Guillaume Martres 07master:c8dd048ab8cf: lavc: add a HEVC decoder. [23:53] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:af980aa4f68e: lavc/hevc_ps: fix PIX_FMT enums [23:53] <cone-770> ffmpeg.git 03Michael Niedermayer 07master:f2dd45d06c60: lavc/hevc: mark decoder as experimental [23:53] <cone-770> ffmpeg.git 03Mickaël Raulet 07master:93c1fe4de393: hevc: add ts demux support [23:54] <michaelni> Paranoialmaniac, ok if i push the mkv & mov demux support too ? [23:55] <smarter> michaelni: will you update the hevc decoder snapshot you pushed before releasing ffmpeg 2.1 with the fixes that are currently getting in? [23:55] <michaelni> smarter, i intend to of course [23:55] <smarter> good :) [23:55] <michaelni> and if i miss any fix, tell/ping me [00:00] --- Wed Oct 16 2013

1 0

ffmpeg.log.20131015
by burek 16 Oct '13

16 Oct '13

[00:26] <AndrzejL> so I am looking at this: [00:26] <AndrzejL> ffmpeg -i "mms://193.164.132.195:2124/aguizzardi" -vcodec libx264 -vpre default -vpre baseline -g 60 -vb 150000 -strict experimental -acodec aac -ab 96000 -ar 48000 -ac 2 -vbsf h264_mp4toannexb -f mpegts udp://127.0.0.1:10000?pkt_size=1316 [00:26] <AndrzejL> this looks like exactly what I need ;) some parameters would have to be changed and I would prefer the xvid codec rather then x264 - all doable [00:26] <MarcWeber> hls output, then uploading to a server causes some stalls. Is there a way to tell the client to start about 5 segments before the last one? [00:37] <buhman> AndrzejL: magic [00:37] <buhman> AndrzejL: told you so [00:43] <AndrzejL> :) [00:51] <AndrzejL> how do I access such stream as lets say udp://127.0.0.1:5999/Stream1.ffm [00:51] <AndrzejL> from lets say mplayer or vlc? [00:51] <AndrzejL> I want to test it on local network before I will open ports for wan [00:56] <wald0> what means -crf 0 ? how i can set the quality/size for libx264 vcodec ? [00:59] <llogan> wald0: https://trac.ffmpeg.org/wiki/x264EncodingGuide [01:08] <wald0> thx [01:11] <wald0> when i record my desktop, the colors of my terminal looks "poor", seems like by recording chars of one-pixel width is not an easy thing, i have read about "subpixel sampling" or a similar name but i dont understand how this works, anybody knows what i need to do for record perfectly those colors? [01:12] <wald0> so i want to create video tutorials of desktops and i want to be them look perfect before the video-editing step [01:12] <llogan> thats an effect from RGB to YUV conversion [01:14] <wald0> mmh, so how i can record in yuv ? [01:14] <wald0> if this is the answer :) [01:18] <llogan> i'm not sure what you can do about it [01:24] <wald0> llogan: you mean that we cannot record videos in yuv format ? [01:24] <wald0> oh wait [01:24] <wald0> i meant rgb maybe [01:27] <llogan> you can (libx264rgb, qtrle, among others, IIRC), but upon playback it will probably be converted to yuv [01:28] <llogan> huffyuv too [01:30] <wald0> if is saved correctly is enough for now, so i can edit it correctly in the ML [01:30] <wald0> NLE [01:31] <wald0> later will be converted to any other format, but having got resizes and stuff which could make it look better [01:31] <MorehouseJ09> st = avformat_new_stream(context, codec); [01:31] <MorehouseJ09> c = st->codec; [01:31] <MorehouseJ09> avcodec_get_context_defaults3(c, codec); [01:31] <MorehouseJ09> printf("%p" "\n", c->codec); [01:31] <MorehouseJ09> printf("%p" "\n", codec); [01:31] <MorehouseJ09> hey, sorry for the weird paste. I'm trying to figure out why when I create a stream, its not linking up the codec properly? [01:32] <MorehouseJ09> for instance, c->codec returns 0x0 [01:34] <llogan> wald0: i forgot that by default with libx264 the pixel_fmt will be yuv444p, thus avoiding the loss (I think), but it looks shitty because it's being converted to 420 in your player [01:34] <llogan> (...by default when your input is RGB...) [01:35] <llogan> i can't remember this stuff. [08:46] <t4nk426> hi [08:46] <t4nk426> ffmpeg does not spilt video data to multiple file every segment_time [08:46] <t4nk426> the command : [08:46] <t4nk426> ffmpeg -loglevel debug -sn -f video4linux2 -r 30 -s 1280x720 -input_format h264 -i /dev/video1 -vcodec copy http://localhost:23791/feed2.ffm -vcodec copy -map 0 -flags -global_header -f ssegment -segment_time 4 -segment_format mpegts /var/stream%05d.ts [08:47] <t4nk426> the option "-segment_time 4" does not function [08:47] <t4nk426> because when I test for about 1 minute, there is file only [08:47] <t4nk426> does anyone have idea? [08:47] <t4nk426> because when I test for about 1 minute, there is 1 file only [08:48] <t4nk426> ffmpeg does not split video data to multiple file by each 4 seconds [10:12] <Apic> A wonderful spendid Bureaucracy the 69th in the YOLD 3179! [10:17] <dol> hi. here is my scaling call: sws_scale(convertCtxDec, decodedpic->data, decodedpic->linesize, 0, aHeight, avFrameRGB->data, avFrameRGB->linesize); [10:17] <Mavrik> mornin everyone [10:17] <dol> I see a problem in some resolutions that the image is a bit cropped from the right side [10:17] <dol> I got a comment that I should use viewable width instead of linesize [10:17] <dol> but I coulndn't succeed [10:18] <dol> could anyone tell me how I should do it? [10:18] <dol> btw: this call converts from yuv 420 to rgb32 [10:18] <Mavrik> hmm [10:18] <Mavrik> you should certanly use linesize [10:19] <dol> then where is the problem? [10:19] <Mavrik> now that's a good question, that code does look correct [10:20] <dol> this code works good for known resolutions [10:20] <Mavrik> the problem might be in initialization of your sws context or in the player [10:20] <dol> you mean convertCtxDec? [10:21] <Mavrik> mhm [10:22] <dol> I use the follwoing to set it: sws_getContext(aWidth, aHeight, PIX_FMT_YUV420P, aWidth, aHeight, PIX_FMT_RGB32,SWS_SPLINE, NULL, NULL, NULL); [10:22] <dol> perhaps this is not correct? [10:23] <Mavrik> well [10:23] <Mavrik> only if your output image is the same size as the input [10:24] <dol> by input, you mean the size of the decoded frame ? [10:24] <Mavrik> the input into sws_scale [10:24] <Mavrik> that's all it matters :) [10:25] <dol> i think there is the mistake as you have pointed [10:25] <dol> then I should set the source width after decoding every frame [10:26] <Mavrik> basically, your context needs to have correctly set frame sizes for input and output of sws_scale call [10:27] <Mavrik> if your input size changes, you need to call sws_getCachedContext() before each sws_scale [10:27] <Mavrik> note that height/width and linesize might not match always :) [10:27] <cauffe> Hey all, I seem to be having some formatting issues. ffmpeg -f mp4 -i sj.mp4 -ss 871.13 -t 1 sj2.mp4 . Seems to be outputting a invalid video file? [10:27] <cauffe> is -f mp4 a valid param? [10:28] <Mavrik> mhm [10:28] <Mavrik> cauffe, why are you reencoding whole video to just cut it? :) [10:28] <cauffe> trying to cut a segment :) [10:28] <Mavrik> yeah [10:29] <Mavrik> why are you reencoding the video? without encoding parameters? that probably destroys your quality :) [10:29] <cauffe> When I don't put the -f pram in I get [aac @ 0x7fd40b81cc00] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it. [10:30] <cauffe> then i get an invalid video file again [10:30] <Mavrik> ywah, because you're reencoding everything [10:30] <Mavrik> instead of just copying streams [10:30] <Mavrik> use -codec copy [10:31] <cauffe> so ffmpeg -codec copy -i ? [10:31] <Mavrik> em no [10:31] <Mavrik> after -i [10:31] <dol> Mavrik, I moved sws_getContext call before sws_scale and changed it to the following: sws_getContext(decodedpic->width, decodedpic->height, PIX_FMT_YUV420P, aWidth, aHeight, PIX_FMT_RGB32, SWS_FAST_BILINEAR, NULL, NULL, NULL); [10:32] <dol> but everytime decodedpic->width = aWidth and the same for height [10:32] <dol> so it didn't solve my problem [10:32] <cauffe> ffmpeg -i -codec copy gave me "-codec: No such file or directory " [10:33] <Mavrik> cauffe, just how ancient is your ffmpeg? [10:33] <cauffe> just downloaded it [10:33] <Mavrik> from where? [10:34] <cauffe> ~_~ http://ffmpegmac.net/ [10:34] <Mavrik> uh [10:34] <Mavrik> your error message makes no sense then [10:34] <Mavrik> what did you type in EXACTLY? [10:35] <cauffe> ffmpeg -i -codec copy sj.mp4 -ss 871.13 -t 1 sj2.mp4 [10:35] <Mavrik> ah [10:35] <Mavrik> so you just basically told ffmpeg that input filename is "-codec" ;) [10:35] <cauffe> >_< [10:36] <cauffe> its supposed to be after the I though, right? [10:37] <cauffe> if I put it before the -i then I get "Unknown decoder 'copy' [10:39] <cauffe> sorry for being such a n00b [10:39] <cauffe> just super frustrating [10:39] <Mavrik> yes, because you haven't really read what you're doing and what the options you're using are doing [10:40] <Mavrik> just blindly stumbling about [10:40] <Mavrik> you set OUTPUT options AFTER you tell to ffmpeg what the input is [10:40] <Mavrik> so "-codec copy" paramter goes after the "-i <input file>" parameter [10:40] <Mavrik> ffmpeg -i <something> -codec copy -ss <bla> -t <bla> output.mp4 [10:43] <cauffe> lol, thanks, got it to output now but with no video [10:44] <Mavrik> then your input file is broken. [10:44] <cauffe> yeahhh [10:44] <Mavrik> can you paste full output of your command on a pastebin? [10:46] <bouba> hi all, any ffmpeg guru who know a method to extract lossless thumbs from a video ? it seems like jpeg output is lossy... ffmpeg -y -i ${input} -an -vf fps=fps=1/20 -f image2 ${input}_%05d.jpeg [10:47] <Mavrik> bouba, any thumbnails will be lossy [10:47] <Mavrik> bouba, you're missing the quality specifier for jpegs that's why they look ugly [10:48] <Mavrik> bouba, use -qscale:v 3 or something [10:48] <Mavrik> 1 being the best, 31 the worst quality [10:48] <bouba> Mavrik, thx, i'll try this method and google it [11:16] <vl4kn0> Hi, I have continuous growth of memory usage in my program using ffmpeg and valgrind suspects avcodec_video_decode2 (it's from the internet stream). Are there any particular memory allocations I should be aware of? [11:20] <Mavrik> vl4kn0, the output frame is allocated by the decoder [11:43] <vl4kn0> Mavrik: I call av_frame_unref(frame) when it's not longer needed [11:45] <dol> Mavrik, I got disconnected form the chat [11:45] <dol> I have placed my question in detail here :http://forum.doom9.org/showthread.php?t=169036 [11:45] <dol> could you please have a look at it? [11:45] <dol> or anybody else [11:52] <dol> nobody? [14:40] <dol> guys can anyone please look at the problem that I described in detail here: http://forum.doom9.org/showthread.php?t=169036 [14:41] <JEEBsv> dol: you might get better replies over at the -devel channel [14:41] <dol> oh really. thanks. I will go there [16:58] <fling> Who are encoding videos with black bars? I hate them! [16:58] <zap0> dat wasist! it's african american bars :p [17:01] <fling> zap0: :D [17:01] <foonix> fling: i guess ppl who hate aspect ratio error [17:02] <zap0> or those that like to be able to read sub titles [18:05] <edinny> I am trying to convert an MP3 file to a format that Facebook will let me upload. [18:05] <edinny> So far, no luck [18:16] <edinny> I found this online, but it does not seem to make a format FB likes: [18:16] <edinny> ffmpeg -y -i /path_to_your/song.mp3 -f flv -ab 131072 -ac 1 /path_to_your/video.flv [18:26] <edinny> I am trying to convert an MP3 file to a format that Facebook will let me upload. [18:26] <edinny> So far, no luck [18:28] <_8680_> Using ffprobe from MacPorts, it spews information about how it was built and such: <https://dpaste.de/oXHu>. How can I make it be quiet about that and only print the information about the given file? [20:18] <MorehouseJ09> I'm trying to demux a clip and am getting an "inconsistent channel configuration" error [20:18] <MorehouseJ09> Shouldn't the ContextFormat take care of this when you open the file? [20:35] <edinny> I found this online, but it does not seem to make a format FB likes: [20:36] <edinny> ffmpeg -y -i /path_to_your/song.mp3 -f flv -ab 131072 -ac 1 /path_to_your/video.flv [20:36] <edinny> any ideas? [20:48] <khali> edinny: you may have to create a fake video stream [20:48] <khali> using .flv for audio only seems weird [20:49] <edinny> got a suggestion on how to make an mpg or avi or mp4 with a static picture? [20:49] <edinny> khali? [20:53] <relaxed> edinny: ffmpeg -loop 1 -i input.jpg -t 00:01:00 output [20:53] <relaxed> that would give you a minute long video of a static image [20:53] <edinny> I wanted to use an mp3 as the audio in that [20:55] <relaxed> edinny: ffmpeg -i input.mp3 -loop 1 -i input.jpg -c:a copy -q:v 3 -shortest output [20:56] <edinny> Unrecognized option 'c:a' [20:56] <edinny> Failed to set value 'copy' for option 'c:a' [20:57] <JEEB> by chance, do you have an old or libav-based ffmpeg? [20:57] <edinny> I have the default for ubuntu 12.04 [20:57] <JEEB> then you have libav [20:57] <JEEB> use avconv [20:58] <JEEB> because the ffmpeg binary is not updated in libav [20:58] <edinny> can you post the entire line? [20:58] <JEEB> just switch ffmpeg to avconv [20:58] <edinny> oh! [20:58] <JEEB> because that's the updated binary with the project that ubuntu/debian uses [20:59] <JEEB> (which is not the ffmpeg (project)) [20:59] <edinny> installing... [21:00] <JEEB> huh [21:00] <edinny> huh? Says already there, but is says it is not... [21:00] <edinny> got it I think... [21:01] <JEEB> anyways, if you are going to use libav-based stuff then use avconv, not ffmpeg. If you ever use ffmpeg-based things, then you use ffmpeg [21:01] <JEEB> :) [21:01] <edinny> what do I put for "-shortest output"? [21:01] <JEEB> -shortest is the option [21:02] <JEEB> output just means the output file name [21:02] <edinny> so output.avi? [21:02] <relaxed> no one needs avi in this day and age [21:02] <JEEB> basically it's an option without a value [21:02] <relaxed> use output.mp4 [21:03] <llogan> edinny: if you're using libav stuff, and it looks like you are, then please continue this discussion at #libav [21:03] <edinny> thanks. Did not know [21:04] <relaxed> edinny: we can discuss llogan there [21:05] <relaxed> llogan: did you read my thoughts on the compilation guide? [21:06] <llogan> i don't think so. when? where? [21:07] <relaxed> Maybe last week here in this channel. I mentioned it would be helpful if each external lib had ffmpeg ./configure requirements for those that use it as a reference. [21:07] <edinny> relaxed: Facebook does not like that format for video uploads [21:08] <llogan> relaxed: can you show me an example? i'm not feeling very smrt today [21:08] <relaxed> for example, libx264 requires --extra-ldflags="-ldl" and --enable-gpl [21:09] <relaxed> some require --enable-nonfree, etc [21:09] <llogan> oh, i see. sure. sounds good to me. would you be willing to add the info? [21:09] <relaxed> Can anyone edit the wiki? [21:10] <llogan> yes, once you register (i don't think registration requires a humon) [21:11] <llogan> ...to approve [23:33] <Maverick|MSG> given the instructions on this page: [23:33] <Maverick|MSG> https://trac.ffmpeg.org/wiki/Seeking%20with%20FFmpeg [23:33] <Maverick|MSG> it says you can cut sections out of a movie by specifying the -to option [23:34] <Maverick|MSG> however if you specify the -ss option before or after the -i you'll get different results [23:34] <Maverick|MSG> what happens if you specify the -ss twice, as the top section "Fast and accurate seeking" recommends? [23:46] <cbsrobot> Maverick|MSG: try it ... [23:46] <cbsrobot> and in what sense different ? [23:46] <cbsrobot> maybe pastebin some info ? [23:47] <Maverick|MSG> I don't have my system for ffmpeg setup here so I can't really try much at the moment [23:47] <Maverick|MSG> was more trying to just pesudocode things [23:47] <Maverick|MSG> basically in the "Cutting small sections" it shows two simular command lines [23:47] <Maverick|MSG> the first, the -ss specified first, will produce a 2 minute video [23:48] <Maverick|MSG> whereas the second, the -ss after the -i will produce a 1 minute video [23:49] <cbsrobot> what's the value for -to ? [23:50] <Maverick|MSG> on the page it is 00:02:00 [23:54] <Maverick|MSG> I guess if I specify both it'll just cut it twice [00:00] --- Wed Oct 16 2013

1 0

ffmpeg-devel.log.20131014
by burek 15 Oct '13

15 Oct '13

[00:07] <BBB> ubitux: no, you can mathematically prove that it's the same thing - try it :) [00:08] <ubitux> ok [00:08] <BBB> a*b+c>>d is the same as a*(b<<1)+(c<<1)>>d>>1 [00:09] <BBB> with brackets where appropriate, but you know what I mean [00:09] <BBB> do you want me to upload my current working version of 32x32? [00:09] <ubitux> no, don't spoil me the fun [00:09] <ubitux> :) [00:09] <BBB> lol [00:09] <BBB> glad you're liking it [00:09] <BBB> it's certainly more fun to figure out yourself [00:10] <ubitux> i want to struggle a bit more before i get more hints [00:10] <BBB> feel free to send me code if there's something you'd like me to review or comment on [00:10] <ubitux> ok [00:10] <BBB> sgtm [00:11] <cone-735> ffmpeg.git 03Derek Buitenhuis 07master:eb90a2091ffb: pthread: Fix deadlock during thread initialization [00:11] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:005200887b2c: Merge commit 'eb90a2091ffb94d8c29aaa5ff50f4192520254fc' [00:22] <ubitux> BBB: pmaddwd is cool, but there is no pmsubwd :( [00:36] <cone-735> ffmpeg.git 03Martin Storsjö 07master:eb8b05a3824a: http: Add an option for forcing basic authentication [00:36] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:5dee3e8bb45d: Merge commit 'eb8b05a3824a9fa85e20d603595ac8a3b83505d4' [00:42] <BBB> ubitux: make the multiplier negative [00:42] <BBB> ubitux: the multiplication is signed [00:42] <BBB> (awh I just gave away the trick, now you didn't have to suffer) [00:42] <BBB> (anyway...) [01:41] <cone-735> ffmpeg.git 03Martin Storsjö 07master:71549a857b13: http: Support auth method detection for POST [01:41] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:6b1b63df85ff: Merge commit '71549a857b13edf4c4f95037de6ed5bb4c4bd4af' [01:42] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:5970f4bb027c: avformat/http: check the auth string contents not the pointer which cannot be NULL [01:58] <michaelni> wbs, if you improve or change a patch taken from ffmpeg-devel, please post or CC changed versions to ffmpeg-devel, this decreases the chance of bugs being missed and gives all a chance to comment [02:09] <cone-735> ffmpeg.git 03Luca Barbato 07master:14ddbb477fae: cavs: K&R formatting cosmetics [02:10] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:fb8a10db5d77: Merge commit '14ddbb477faef359983151b763fd8b20e578651b' [02:16] <cone-735> ffmpeg.git 03Luca Barbato 07master:1b20d0f581f0: cavs: Return meaningful error values [02:16] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:d794b7db1453: Merge commit '1b20d0f581f01f2df601c9e68d0d321672d97af7' [11:25] <cone-360> ffmpeg.git 03Luca Barbato 07master:39185ec4faa9: cavs: Check for negative cbp [11:25] <cone-360> ffmpeg.git 03Michael Niedermayer 07master:8d9f08ef32f1: Merge remote-tracking branch 'qatar/master' [13:22] <cone-360> ffmpeg.git 03James Almer 07master:aae8975ffbb5: oggparseopus: use ff_alloc_extradata() [13:22] <cone-360> ffmpeg.git 03James Almer 07master:00408f95e7fa: oggparsecelt: use ff_alloc_extradata() [13:22] <cone-360> ffmpeg.git 03James Almer 07master:1d4476d5dab1: movenc: use ff_alloc_extradata() [13:41] <smjd> ubitux: http://trac.ffmpeg.org/ticket/2936#comment:9 it's a regression because I can't use an external tool like Gifsicle to join single GIF images to an animation, to get an optimal palette instead of the generic one [13:42] <ubitux> ok [13:51] <ubitux> smjd: and gifsicle can't take png as input? [13:53] <smjd> nope [13:55] <ubitux> only gif? [13:56] <smjd> "gifsicle: image.png: file not in GIF format" [13:56] <Daemon404> eh [13:56] <Daemon404> use somthing better [13:56] <Daemon404> like imagemagick [13:57] <smjd> I tried ImageMagicks layer optimization on a file ffmpeg created and output was about 50% larger [13:58] <ubitux> :) [13:58] <Daemon404> ive only every use it via its C api [13:58] <Daemon404> it could also be the difference in dither quality [13:58] <ubitux> smjd: i won't have time to make that feature soon, are you willing to work on it? [14:01] <smjd> I don't think I have good enough programming skills yet [14:02] <smjd> but I'll take a look [15:05] <Compn> where did i see those unroll every loop instruction [15:05] <Compn> seems like some programming guidelines [15:05] <Daemon404> maybe from 1997 [15:06] <Daemon404> you dont need to manually unroll too many things in 2013 [15:07] <Compn> good point [15:07] <Compn> seems like an old cpu problem [15:07] <Compn> now no one cares about bloated operations :P [15:08] <Daemon404> Compn, more like compilers arent as shit [15:08] <Daemon404> still shit [15:08] <Daemon404> but not as much. [15:09] <Compn> talking about gcc 2.95? :) [15:09] <Compn> ehe [15:10] <Daemon404> the holy 2.95 [15:11] <Compn> maybe we've gone too far in a few places [15:11] <Compn> with the 2.95 [15:12] <Daemon404> ive had changes rejected because they broke 2.95 before [15:12] <Daemon404> ;) [15:29] <michaelni> only 2.95 ? [15:29] <Daemon404> yeah [15:29] <Daemon404> it was a 2.95 bug [15:29] <Daemon404> it was ages ago, and mru flamed me [15:36] <cone-360> ffmpeg.git 03Martin Storsjö 07master:84a125c4c28f: rtmp: Allocate the prev_pkt arrays dynamically [15:36] <cone-360> ffmpeg.git 03Michael Niedermayer 07master:953dd72321b7: Merge commit '84a125c4c28f3e3e215d2e6c32f7f0ec43bbc04c' [15:48] <cone-360> ffmpeg.git 03Derek Buitenhuis 07master:15748773bf33: avresample/x86: Switch operand order for mulps [15:48] <cone-360> ffmpeg.git 03Michael Niedermayer 07master:12ca544aa0fc: Merge commit '15748773bf33c110e6e2e9526c7ba5478274c74c' [15:50] <Compn> of course, you could say, devotion to 2.95 ensured our compliance and easy transistion to newer compilers (icc, clang, etc) [15:50] <Compn> and of course, breaking those newer compilers :) [15:53] <cone-360> ffmpeg.git 03Henrik Gramner 07master:c108ba0175d4: x86inc: Use VEX-encoded instructions in AVX functions [15:53] <cone-360> ffmpeg.git 03Michael Niedermayer 07master:12e4493f9c14: Merge commit 'c108ba0175d4fc3a3253a8b0f782fbfb96ba5098' [16:05] <cone-360> ffmpeg.git 03Derek Buitenhuis 07master:206895708ea2: x86inc: Remove our FMA4 support [16:05] <cone-360> ffmpeg.git 03Michael Niedermayer 07master:9ac124c889a6: Merge commit '206895708ea2b464755d340e44501daf9a07c310' [16:08] <saste> what's the name of the function which counts bits in a number? [16:09] <saste> av_popcount [16:12] <cone-360> ffmpeg.git 03Jason Garrett-Glaser 07master:c6908d6b4b37: x86inc: FMA3/4 Support [16:12] <cone-360> ffmpeg.git 03Michael Niedermayer 07master:e3e0e3d0c913: Merge commit 'c6908d6b4b377a04a5d055ba874bdbcf06c80497' [16:21] <cone-360> ffmpeg.git 03Jason Garrett-Glaser 07master:a3fabc6cb389: x86: more AVX2 framework [16:22] <cone-360> ffmpeg.git 03Michael Niedermayer 07master:f9bef2bec9dc: Merge remote-tracking branch 'qatar/master' [16:31] <cone-360> ffmpeg.git 03Carl Eugen Hoyos 07master:f7ed044eeaf3: Support H.264 fourcc UMSV. [16:42] <Daemon404> oh [16:42] <Daemon404> TheRyuu, [16:42] <Daemon404> see [15:42] < fflogger> [editedticket] cehoyos: Ticket #3048 (ICL and HAVE_INLINE_ASM) updated https://trac.ffmpeg.org/ticket/3048#comment:1 [16:43] <Daemon404> and of course [16:43] <Daemon404> carl's response is as uninformed as usual. [18:54] <cone-360> ffmpeg.git 03Vignesh Venkatasubramanian 07master:0f99aad80f65: lavc: Adding seek_preroll to AVCodecContext [18:57] <TheRyuu> Daemon404: that patch doesn't look complete to me [19:45] <Daemon404> TheRyuu, its not [19:50] <beastd> hi [19:52] <durandal_1707> good morning [20:31] <cone-360> ffmpeg.git 03Paul B Mahol 07master:42a8d8aee858: avformat/rpl: use avpriv_report_missing_feature/avpriv_request_sample [21:58] <cone-360> ffmpeg.git 03Vignesh Venkatasubramanian 07master:d6f86d74edfa: matroskadec: Demux support for SeekPreRoll and CodecDelay [22:11] <michaelni> ubitux, do you want to review "[FFmpeg-devel] [PATCH 4/6] lavc: support multiple frames in a singe AVPacket in avcodec_decode_subtitle2" [22:11] <michaelni> and the other subtitle related patches in that thread ? [22:35] <llogan> durandal11707: "Broken." Providing no comment would have been better than that. [22:41] <michaelni> mraulet, did you get a chance to talk with elenril and could you find a consensus ? [22:47] <mraulet> well I think smarter did answer for us [22:54] <michaelni> mraulet, ohh, ok, understood [22:55] <durandal11707> llogan: i'm guilty [23:10] <saste> BBB: That makes my hobbyist life a lot easier [23:10] <saste> :D [23:12] <cone-360> ffmpeg.git 03Lou Logan 07master:a06dcde5073b: doc: make x11grab examples consistent with option names [23:22] <llogan> saste: thanks [23:22] <saste> llogan, you lazy ;) [23:22] <llogan> and terrible at git [23:32] <iive> so, what is the fate of the hevc decoder? [23:53] <saste> iive, we wait [23:53] <saste> we lost the penis waving contest [23:53] <iive> we wait for what? libav to finally merge it? [23:54] <saste> iive, don't listen to me, i'm just saying silly things [23:54] <michaelni> mraulet, smarter, I understand you are not opposed to the merge, and i thank you for that :) but id like to do exactly what you/ the authors prefer, its your code and i dont want to do something that you guys dont want, thus a clear "merge it" vs. "wait" would be ideal. [23:58] <mraulet> there is no "clear" wait no "clear" merge [00:00] --- Tue Oct 15 2013

1 0

ffmpeg.log.20131014
by burek 15 Oct '13

15 Oct '13

[01:47] <Fandekasp> hi there [01:49] <Fandekasp> I'm trying the gource software, and cannot get a mp4 file out of it. Trying the 2-steps methods, I get a ppm file, and when I try to run the ffmpeg command, it fails with this error: http://sprunge.us/bTFC?console [01:50] <Fandekasp> I tried slighly different commands, but all fail, and I'm don't know ffmpeg enough. Anyone has some time to help me debug this through ? [01:54] <DrSlony> Fandekasp [01:55] <Fandekasp> hi DrSlony [01:57] <DrSlony> for s in "0.8" "1.0" "1.2" "1.4"; do fps="30"; vid="gource_${s}spd_${fps}fps"; bitrate="2M"; preset="slower"; gource --multi-sampling -r ${fps} -1280x720 --seconds-per-day ${s} --title "Your Program" -o - | ffmpeg -y -b:v 10000K -r ${fps} -f image2pipe -vcodec ppm -i - -vcodec libx264 -preset ultrafast -crf 12 -bf 0 -threads 0 /tmp/${vid}.mp4 && ffmpeg -y -i /tmp/${vid}.mp4 -an -vcodec libx264 -pass 1 -preset ${preset} -b:v ${bitrate} -bf 0 -threads [01:57] <DrSlony> 0 -f rawvideo /dev/null && ffmpeg -y -i /tmp/${vid}.mp4 -an -vcodec libx264 -pass 2 -preset ${preset} -b:v ${bitrate} -bf 0 -threads 0 /tmp/${vid}_${bitrate}_${preset}_`date +%F_%H%M`.mp4 && ls -lh /tmp/${vid}*.mp4; done [01:57] <DrSlony> that's one command, so copy and join the two lines [01:57] <DrSlony> and tweak as you see fit [01:59] <Fandekasp> DrSlony: why are we creating 4 different videos ? [01:59] <DrSlony> you dont want to bore your viewers, yet you dont want to zoom through your program too fast, so tweak the seconds-per-day values in my example, which are 0.8, 1.0, 1.2 [01:59] <Fandekasp> Already set it to 0.2, project is quite huge [01:59] <DrSlony> alrighty then :]\ [02:00] <Fandekasp> ok let me try [02:03] <DrSlony> by the way, dont change the crf 12 or preset ultrafast - at that stage you want maximum quality and speed [02:07] <Fandekasp> DrSlony: when running the command, I see those errors http://sprunge.us/ANYI . Nothing important ? [02:08] <Fandekasp> Something that annoys me is that even with seconds-per-day 0.15, after 3 months, it starts becoming super slow like 30sec per day :( Nothing to do with ffmpeg though hehe [02:13] <DrSlony> is that in the second part? then you could try moving it before the "-i /tmp/${vid}.mp4" [02:14] <DrSlony> i dont remember which version of gource i ran it on [02:15] <DrSlony> must have been 0.37, worked well, didnt notice any seconds-per-day issues [02:18] <Fandekasp> yeah no /tmp/*avi file is been created [02:19] <Fandekasp> I ran gource v0.3 [02:19] <Fandekasp> gource v0.4* [02:21] <Fandekasp> DrSlony: error is as follow http://sprunge.us/aUHR [02:38] <DrSlony> Fandekasp: i'd replace the && with newlines to be sure of the place where it screws up, and then run just the problematic part. Then i'd move the "-i -" to the end right before the output file (first check the documentation of the ffmpeg version youre using) [02:39] <DrSlony> worked fine 1.5 years ago :] [02:39] <DrSlony> good night [10:22] <jankarlitos> When using ffmpeg for streaming and the Internet connection is lost, ffmpeg hangs forever. Is there any timeout i can set for this? [10:25] <Apic> A splendid wonderful fine Morning (UGT) on this gorgeous Boomtime! [11:03] <sim590> hi! I'm trying to screencast using this command ffmpeg -f x11grab -y -r $FRAMERATE -s $SIZE -i :0.0 -f alsa -i hw:0,0 -acodec flac -vcodec ffvhuff -qscale 0 ./out.mkv and it works but the audio is getting spike lags [11:03] <sim590> the audio just cuts and uncuts [12:08] <dol> hi all. when I call avcodec_decode_video2(c1, av_pic, &got_picture, &pkt); it fills the av_pic information and I use this information when converting from YUV to RGB. I see that 50 is added into the value of av_pic.linesize[0]. [12:08] <dol> this is the reason I see a crop in my output image [12:09] <dol> is there any way to omit this or to know that 50 is already added? [12:09] <dol> this happens only in some specific resolutions [12:34] <cheri> hi how do I create the index on a mpeg2ts file [12:48] <starfox21> hey guys I am trying to convert an mp4 to an ogv on a mac but I am getting this error -> Encoder (codec none) not found for output stream #0:0 [12:48] <starfox21> how do I install the missing codecs? [14:21] <allengreen> can Faac encode a sample rate to another? [14:22] <JEEB> no, you do it with a resampling filter before pushing the samples into an encoder [14:23] <allengreen> thanks, Could you tell me more about filter? [14:24] <JEEB> I think it's just -ar after the input? In older versions of ffmpeg it used something else, in newer ones it uses libswresample [14:25] <JEEB> generally you don't need to change the rate, though [14:25] <JEEB> also, if you are going to encode AAC I recommend you compile ffmpeg with fdk-aac [14:25] <allengreen> I mean do you know any independent project of filter? ffmpeg is too big. [14:25] <JEEB> that encoder is much better [14:26] <JEEB> allengreen, libswresample or libavresample (both included in ffmpeg, the former enabled by default) contain the actual features [14:26] <JEEB> and are the libraries called to do this [14:26] <JEEB> also there are plenty of non-ffmpeg related libraries that do this stuff :P [14:26] <JEEB> sox and friends come into mind as well [14:28] <allengreen> understand. [14:29] <JEEB> btw, if you are making a project that is supposed to be distributing binaries, faac will not fly [14:30] <JEEB> it's not really GPL (since it uses code from one of the reference implementations, which is not under a license that is compatible) [14:30] <allengreen> yes, GPL sucks, I like BSD. [14:31] <JEEB> well, the reference code doesn't fit either :P [14:31] <JEEB> if you are making a project that just needs an AAC encoder, I recommend using libavcodec's, as it's better than the vo-aacenc one and LGPL. If you are making something payware then I recommend just taking a license from fraunhofer or whatever for their open source fdk-aac encoder [14:32] <JEEB> this is for binary distribution, btw [14:32] <JEEB> if you can just ship source code to users or in case of open source just ship source code, then you can just expect the user to build his/her own fdk-aac binary [14:34] <allengreen> I' gonna first solve the usability problem, then solve the license problem. [14:35] <JEEB> well, just saying [14:35] <JEEB> since it's not fun to find out that the thing you were going to use isn't distributable as binaries :P [14:36] <allengreen> BTW, do you known independent project about PCM resampling? I mean ffmpeg is too big for me currently. [14:37] <JEEB> well, I said that there are those two libraries within ffmpeg that handle that, one of which you can start using. Or then there's (lib)sox and so forth :P [14:37] <allengreen> I can use ibswresample or libavresample without ffmpeg? [14:38] <JEEB> all the libraries are separately usable, although the libavutil helper library might be most useful to be used as well :P [14:38] <allengreen> sounds like resampling is not a difficult algorithm, if I am familiar with audio codec, I can write my own. [14:40] <JEEB> anyways, I don't know what you're doing but I'd generally not try to reinvent wheels :D I already noted two alternatives from within the ffmpeg's source tree (since we're at #ffmpeg after all), and even noted one separate alternative ((lib)sox) [14:40] <JEEB> so yeah [14:41] <allengreen> get it. [16:38] <dharriso> Hi, having problems setting libfdk_aac codec private options on the CLI, see http://pastebin.com/Xbh9wge2 [16:39] <dharriso> Im not sure how to set the VBR quality everything else works well i.e. profile and CBR options but not VBR [16:39] <dharriso> I followed the recommendations here; http://www.hydrogenaudio.org/forums/index.php?showtopic=95989 [16:39] <dharriso> any thoughts on what im doing wrong? [17:01] <Mavrik> dharriso, you're probably looking for this: https://trac.ffmpeg.org/wiki/AACEncodingGuide [17:01] <Mavrik> the parameter is "-vbr" apparently. [17:01] <dharriso> yea [17:03] <dharriso> ah -vbr without the flags options then [17:07] <dharriso> thanks for the link [17:20] <xlinkz0> is flv better for live streaming than mp4? [17:22] <Mavrik> those are just containers [17:23] <Mavrik> there isn't much difference except that mp4 might be better supported [17:24] <xlinkz0> thanks [17:24] <ubitux> mp4 was never designed for streaming [17:25] <Mavrik> yet it's still used for it -_- [17:25] <ubitux> it's one of the worse for streaming, even though it's used a lot for this [17:25] <Mavrik> yep [17:25] <Mavrik> sadly MPEG2-TS isn't as widely supported as I would liek [17:25] <ubitux> flv is good enough [17:25] <ubitux> for most cases [17:26] <JEEB> <ubitux> it's one of the worse for streaming, even though it's used a lot for this <- I don't actually agree, at least with movie fragments [17:26] <Mavrik> unless your device won't read it. [17:26] <ubitux> JEEB: yeah, with a giant muxing factory :) [17:26] <JEEB> too bad fragments aren't actually that supported >_> [17:26] <JEEB> ? [17:27] <ubitux> mp4 is complex, adding a segmenting/playlist layer on top really looks like a hack to me, but well [17:27] <JEEB> I thought fragments were just mini-indexes, just like the main index in the moov atom and related [17:27] <ubitux> if you want to live stream, you're forced to chunk your output [17:27] <JEEB> huh [17:28] <JEEB> you just pipe a movie fragment using mp4 into some libavformat-using parser/player just fine, and get a picture [17:28] <JEEB> and then how quickly you get that depends on how often you put the fragment-related indexes [17:28] <JEEB> (methinks) [17:29] <ubitux> yeah sure ok you can do that [17:29] <JEEB> but in any case, the main problem is the support for that feature :P [17:29] <JEEB> because while it is useful, it is still quite rarely used [17:30] <ubitux> muxing flv is way simpler :) [17:30] <ubitux> 13B header, then interleaved a/v packets with ts [17:30] <ubitux> izi [17:30] <JEEB> sure, but you have libavformat/l-smash/whatever to do most of the hard work for you in any case if you're doing the muxing from your code [17:30] <JEEB> most people don't NIH muxing [17:31] <ubitux> depends [17:31] <ubitux> flv can be hand muxed without much pain [17:31] <JEEB> but as I said, the problem here is not is it good or not, but the fact if stuff is supported or not :P [19:01] <chrisstreeter> hi all, i'm trying to debug why an audio file (m4a) is having trouble getting converted using ffmpeg. I run ffmpeg and got the following output: http://dpaste.com/1416644/ [19:02] <chrisstreeter> is there any way to better understand what would cause an issue like this? [19:03] <chrisstreeter> the source audio file is from a recording on an iPad. I'm also thinking that the source audio file is generated by combining two files together. my initial hunch is that the first part of the audio is recorded with single channel aac audio, and then the second half is multiple channel [19:46] <vl4kn0> Hi, how do I create thumbnail every 1/4 of second from 00:00:00 to 00:30:00 ? [20:38] <ka1ser> *we* are getting several messages of this kind while using ffmpeg h264 codec: [h264 @ 0x50c8ba0] no frame!..... but video looks fine, any idea of what could make these appear as errors while video seems to be fine? this is on a h264 stream being decoded through network (softphone) [22:30] <vl4kn0> Hi, is it required to call av_frame_unref() after calling the avcodec_decode_video2 or avcodec_decode_audio4? [22:33] <vl4kn0> The problem is that I have a program using ffmpeg decoding and it usually after 20 minutes starts to consume huge amounts of memory until it gets killed by the kernel. I suspect that either AVFrame is not deallocated or I do not read all the data from packet buffer. [23:03] <jkli> Does anybody know how to apply denoise / deblock filter on images when creating thumbnails from a video file? [23:05] <llogan> ffmpeg -i input -ss 12 -vframes 1 -vf <one of several avilable denoise filters> output.png [23:08] <jkli> thanks [23:08] <jkli> How do I auto pace thumbnails, like every 5% of the movie length? [23:08] <jkli> is there a way? [23:10] <llogan> you can possibly use the select filter, or maybe -r [23:11] <llogan> http://ffmpeg.org/ffmpeg-filters.html#select_002c-aselect [23:14] <Chat5388> Hi [23:14] <jkli> thanks a lot llogan :) [23:15] <MorehouseJ09> hey anyone ever gotten the error "bitrate tolerance too small for bitrate" [23:15] <MorehouseJ09> can't find too much information on actually working with this using the libav* libs [23:28] <Mavrik> MorehouseJ09, well I think the message it pretty clear [23:35] <AndrzejL> hi folks [23:35] <AndrzejL> I need something that grabs the stream inside the lan then changes the res and bitrate and then streams it to the wan [23:36] <AndrzejL> I hear that ffmpeg can do that - what am I looking for exactly? how can I achieve such thing? [23:36] <Mavrik> with that little info. [23:36] <Mavrik> magic. [23:38] <AndrzejL> ok lets say I have a local machine that streams video and music. I would like to be able to access it from my tablem when I am not at home but I dont want to use to much bandwidth so I would like to use my server that faces wan to grab the local stream, change the bitrate and the resolution of the videos AND then stream it to wan. [23:39] <AndrzejL> s/tablem/tablet [23:40] <AndrzejL> is this possible to do with ffmpeg? [23:41] <Mavrik> yes, but you will require alot of knowledge [23:41] <Mavrik> just buy Plex [23:41] <Mavrik> it does exactly what you want. [23:41] <AndrzejL> is plex available for linux? :) [23:42] <MorehouseJ09> Mavrik: yeah, I've been playing around with the tolerance but can't get anything to work :( [23:42] <AndrzejL> I would preffer to actually gain the knowledge and do it using ffmpeg ;) [23:43] <Mavrik> MorehouseJ09, well, with that info we can't really help you [23:43] <Mavrik> I suggest you look under doc/examples [23:43] <Mavrik> and step through ffmpeg code with gdb to see what triggers the error [23:46] <MorehouseJ09> definitely. So its not looking like a trivial fix unfortunately :( [23:47] <Mavrik> it probably is, but I forgot my crystal ball at home [23:47] <Mavrik> it'll take you whole two minutes to step through code with a debugger ;) [23:48] <MorehouseJ09> Mavrik: thanks. Working on it now [00:00] --- Tue Oct 15 2013

1 0

ffmpeg-devel.log.20131013
by burek 14 Oct '13

14 Oct '13

[00:00] <wm4> also, I myself use codec names, not the define, so the "redundant" define doesn't help me much [00:00] <wm4> s/redundant/compatibility [00:00] <smarter> michaelni: ah, another important issue that hasn't been resolved (afaik) is whether or not the conformance streams can be uploaded to FATE legally [00:01] <michaelni> wm4, if you just use a name like "hevc decoder" how does the codec_id affect that ? [00:01] <michaelni> j-b, maybe we should not and make it non experimental, no string oppinion on that [00:02] <michaelni> strOng [00:02] <michaelni> smarter, tell them to sue me if i upload them [00:02] <wm4> michaelni: well, ffmpeg uses "h265" for AVCodecDescriptor.name, and I expect Libav will choose "hevc" [00:03] <wm4> I won't be the only one affected by this, think of scripts etc. [00:03] <j-b> like normal people will call it hevc [00:04] Action: michaelni wonders why they dont call h.264 avc [00:05] <michaelni> wm4, so if i change that "h265" string to "hevc" that solves the problem with 2 codec ids for you ? [00:06] <michaelni> i dont see a problem with that chnage ATM but i might be missing someting [00:06] <wm4> yes, at this point everyone could just pretend AV_CODEC_ID_H265 doesn't exist [00:06] <wm4> *does [00:06] <ubitux> .name = "h264,hevc" isn't supported? [00:06] <mraulet> agree with wm4 [00:07] <BBB> you guys are totally out of your mind [00:07] <BBB> this is a development channel for codecs and video technology [00:07] <BBB> and you're talking about scripts and naming and indenting and ... shit man [00:07] <wm4> uh this is a ffmpeg development channel [00:07] <wm4> quite a different thing [00:08] <BBB> maybe for you it is [00:08] <BBB> not for me [00:08] <wm4> then you're offtopic here [00:08] <BBB> ok [00:10] <ubitux> :') [00:10] <beastd> data matters, algorithms matter and the color of the little bikeshed can of course be neglected for now [00:11] <j-b> then you should vote :) [00:11] <j-b> I vote hevc [00:12] <mraulet> &. why not keeping the original of the decoder of those who developed it [00:12] <j-b> because of a quick google fight [00:12] <ubitux> mraulet: i think the original question is about retro compat with the h265 codec id added a while ago [00:13] <mraulet> but the decoder does not exist [00:13] <wm4> there's a hevc raw demuxer [00:13] <mraulet> okay but it is not the same amount of code... [00:14] <beastd> BTW are you talking about the decoder implementation name or the codec id symbolic name now? [00:14] <ubitux> mraulet: i'm not sure you understand the issue here; and anyway, the original plan was and always is to follow compat with libav and be retro compatible [00:15] <mraulet> all, we should be compatible with the name of the files it makes more sense [00:15] <iive> if I understand the issue here, it is application compatibility. So it should be decided before the codec is in wider use. [00:32] <smarter> considering there was no release of ffmpeg with AV_CODEC_ID_H265, removing it doesn't seem like a bad idea [00:33] <smarter> anyway, feel free to release ffmpeg with a half-working hevc decoder behind the experimental flag. I hope that won't have any bad consequence. [00:34] <smarter> as long as you don't start diverging from the libav decoder [00:35] <cone-656> ffmpeg.git 03Michael Niedermayer 07master:87fe0bbd69bf: lavc: rename h265 to hevc, add AV_CODEC_ID_H265 with identical value for backward compatibility [00:35] <wm4> michaelni: nice! [00:36] <smarter> AV_CODEC_ID_HEVC = MKBETAG('H','2','6','5'), [00:36] <smarter> shouldn't that be 'H','E','V','C' ? [00:36] <wm4> well, the value literally doesn't matter [00:36] <smarter> even if it's different from libav? [00:36] <ubitux> binary compat [00:36] <wm4> it's just a really dumb trick to ensure ABI compatibility even if Libav adds a codec id [00:37] <ubitux> how is that dump? [00:37] <ubitux> dumb* [00:37] <smarter> alright [00:37] <wm4> smarter: Libav doesn't use tags here [00:37] <wm4> it's a straight enum (though some codec IDs add weird offsets) [00:39] <wm4> ubitux: if it were an enum without gaps, codec_descriptors could for example be indexed by codec id [00:39] <wm4> and also using fourccs here is kind of confusing (because the enum values actually have no meaning) [00:39] <ubitux> there is no better solution for abi compat afaik [02:05] <BBB> why doesn't check_lib2 pick up --extra-ldflags=.. configure flags (or --extra-libs)? [02:44] <BBB> oh nm I had ldflags mixed up it was picking up a wrong oen [02:44] <BBB> weird [07:00] <cone-130> ffmpeg.git 03Anton Khirnov 07master:df6737a55f5d: audio_mix: fix channel order in mix_1_to_2_fltp_flt_c [07:00] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:830a567e96a2: Merge commit 'df6737a55f5dc7c0ae5272bc5fa6182836d5481c' [07:50] <cone-130> ffmpeg.git 03Anton Khirnov 07master:9ab5f7107d2f: FATE: add lavr mixing tests [07:50] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:de80cebdd7fb: Merge commit '9ab5f7107d2f1411e9fda6c36af64524e5ed31d1' [08:07] <cone-130> ffmpeg.git 03Anton Khirnov 07master:364af376f343: FATE: add lavr resampling tests [08:08] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:b35ef855a4fa: Merge commit '364af376f343d4706c4cdb7ab9fe0863994e6c01' [08:16] <cone-130> ffmpeg.git 03Anton Khirnov 07master:66d3f5fd5ca4: lavc doxy: remove false statements about alignment requirements. [08:16] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:29d64b1d8ebe: Merge commit '66d3f5fd5ca4cb3d09b52ad1041cd4359325a21a' [08:26] <cone-130> ffmpeg.git 03Anton Khirnov 07master:16ea20c827ef: lavc doxy: extend/clarify avcodec_decode_audio4() doxy [08:26] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:40ade0714110: Merge commit '16ea20c827ef2ffaf77d5e05d5cf9983689f7b2b' [08:33] <cone-130> ffmpeg.git 03James Almer 07master:9c15ef35d404: oggparsevorbis: support official chapter extension [08:33] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:b6ffe8afd928: Merge commit '9c15ef35d404fca2adc31276c1eedb11cf485461' [08:58] <cone-130> ffmpeg.git 03Vittorio Giovara 07master:ed9245dba83f: oggparsevorbis: check allocations [08:58] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:3ce0eddeab39: Merge commit 'ed9245dba83f9add60f55718b537b0af2105c60e' [09:21] <cone-130> ffmpeg.git 03Nicolas George 07master:ecab1c77410f: oggdec: add support for Opus in Ogg demuxing [09:21] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:8dbf98e68a9b: Merge commit 'ecab1c77410f023b437c6ed3a3281be8f039e574' [09:46] <cone-130> ffmpeg.git 03James Almer 07master:601d6228c481: flac: move picture parsing code in a separate file [09:46] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:92b03cf926ef: Merge commit '601d6228c4811d8971a2412a759e1a4ab775ebe8' [09:56] <cone-130> ffmpeg.git 03James Almer 07master:c18375ec8040: oggvorbisdec: add support for embedded cover art [09:56] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:77caa31f717a: Merge commit 'c18375ec8040a9fe0f186b2033dc975883143758' [10:11] <cone-130> ffmpeg.git 03Vittorio Giovara 07master:fd2384f02b90: oggparsevorbis: fail on memory allocation error [10:11] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:0c7bd3402306: Merge commit 'fd2384f02b905a106fba9222ece4ddbe2ec61937' [10:23] <cone-130> ffmpeg.git 03Luca Barbato 07master:0cb83c563848: indeo4: Check the block size if reusing the band configuration [10:24] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:d3850ac5b9c7: Merge commit '0cb83c563848bf8f8365e7bd30e7e6b57ef360f0' [10:43] <cone-130> ffmpeg.git 03Luca Barbato 07master:c9ef6b09326a: indeo4: Check the inherited quant_mat [10:43] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:43dec5ef9a36: Merge remote-tracking branch 'qatar/master' [11:41] <cone-130> ffmpeg.git 03Michael Niedermayer 07master:4b948dcadb8b: doc/developer: Merge license related policy items [11:51] <cone-130> ffmpeg.git 03Paul B Mahol 07master:fa7e9f940140: avformat/vocdec: return AVERROR_EOF when EOF is reached [13:44] <ubitux> BBB: ping [13:45] <ubitux> i'm likely missing something obvious in the calling convention; http://pastie.org/8398856 [13:46] <ubitux> the "movq m0, [blockq+ 0]" is doing a rsi dereferencing [13:46] <ubitux> but it's set to 0x7a0 (likely a stride value) [13:47] <ubitux> (don't mind the c code addition, it's just a working unrolled 4x4 to use as a reference) [13:48] <ubitux> oh god i've switched block and stride [13:48] <ubitux> eyes crossing [13:48] <ubitux> my bad. [13:49] <BBB> lol [13:54] <ubitux> weird order btw [13:54] <ubitux> since the stride is related to block access and not dst [13:58] <BBB> no [13:58] <BBB> stride is for dst [13:58] <BBB> block has no stride [13:58] <BBB> block is just a 2d array of 32x32 int16_ts, or 4x4 int16_ts [13:58] <BBB> so the stride of it is the size of the iadst/idct [13:59] <ubitux> ah urm i got confused with the 1d arg [13:59] <BBB> right, that's a different stride [13:59] <BBB> that's not the function argument [13:59] <BBB> maybe that's confusing indeed [13:59] <BBB> feel free to rename :) [13:59] <ubitux> no it's fine [14:00] <ubitux> btw, what's the maximum number of m registers i should use? [14:00] <ubitux> 8? [14:00] <ubitux> m0..m7? [14:00] <durandal_1707> depends [14:05] <BBB> ubitux: so for mmx, m0-7 [14:05] <BBB> ubitux: for sse(xmm) or avx(ymm - not relevant yet), you have 16 on x86-64 [14:06] <BBB> so if you want portable code, use only m0-7, if you want optimal performance, use m0-15 [14:06] <BBB> for idct32x32, I don't care about x86-32, it's kind of sad but I have better tihngs to do with my free time, and x86-32 is dead [14:06] <ubitux> i think i can do it with m0-7 [14:06] <BBB> for mc asm, it wasn't hard to keep within 8, so I used only m0-7 [14:06] <BBB> yeah idct4x4 should be possible with 8, I'd think [14:07] <BBB> 8x8 may be harder... so give it a look, and if it looks complex, don't bother [14:07] <ubitux> 5-6-7 are for the 3 constants, i wanted to avoid reloading [14:07] <BBB> if it's "almost" possible, feel free to use m8 and beyond for "optional" stuff to allow %if/%else/%endif style code [14:07] <BBB> ffvp8 does that too [14:07] <BBB> then it works on both but still uses >8 regs on x86-64 [14:07] <ubitux> ok [14:08] <BBB> but if the code gets too complex, just make a x86-64 only version that uses all regs [14:08] <BBB> whatever is easiest for code writing or maintenance purposes [14:08] <ubitux> for example SUMSUB_BA using an extra register for tmp ? [14:08] <BBB> well, you can't just switch right? [14:08] <ubitux> ? [14:08] <BBB> oh wait you could [14:08] <BBB> yes it is [14:08] <ubitux> SUMSUB_BA can work without an extra register [14:09] <ubitux> so i could do that to keep under 8 reg [14:09] <BBB> right, don't feel obliged to use these macros if they make it harder to understand [14:09] <ubitux> and i guess i could call it differently if i have extra registers [14:09] <BBB> esp. for first versions [14:09] <ubitux> i think it's actually simpler to use them [14:10] <ubitux> since i would likely have used 2x the number of registers to do the same op :p [14:18] <BBB> I'd have pointed out what you did wrong ;) [14:30] Action: Daemon404 wonders what this cherry picking idiocy is... [14:30] <Daemon404> why merge unfinished code [14:31] <Daemon404> to be "first"? -_- [14:31] <ubitux> are you refering to hevc? [14:31] <Daemon404> yes. [14:31] <ubitux> we're not allowed to review it? [14:32] <Daemon404> review? sure. but i see no involvement at all from its atual authors. [14:32] <Daemon404> and pushng before teh authors are happy with it is just retarded [14:33] <ubitux> consider it's submitted to ffmpeg-devel so ffmpeg dev can review it [14:33] <ubitux> no need to extrapolate further [14:33] <Daemon404> i wonder if the review will actually make it to the authors [14:33] <Daemon404> since they dont seem to have even been informed. [14:33] <durandal_1707> its fork [14:34] <BBB> question [14:34] <BBB> it took them 2 years to get ffhevcdec into shape? [14:37] <michaelni> Daemon404, at least 2 of the hevc authors are on this channel [14:37] <Daemon404> as long as they actually get the review points. [14:38] <Daemon404> it's only going to be a giant mess if ffmpeg merges it a) before theyre happy b) solely to be 'first'. [14:39] <michaelni> Daemon404, libav seems VERY unhappy about ffmpeg merging anything especially if its something important and libav doesnt have it yet [14:40] <Daemon404> ... [14:40] <Daemon404> i dont see how thats at all relevant [14:40] <Daemon404> you seriously dont see how merging incomplete coe is fucking stupid? [14:40] <michaelni> the crying is from libav devels not so much from openhevc devels [14:40] <Daemon404> or at least, against the athour's wishes? [14:41] <Daemon404> openhevc is a temporary thing [14:41] <durandal_1707> merge it before k&r [14:41] <Daemon404> the trop so far has been "don't make your incomplete code public, or michael will merge it"... youre not exactly proving this to b untrue. [14:41] <Daemon404> be* [14:41] <Daemon404> er, trope. [14:43] <ubitux> stealing free code! [14:43] <Daemon404> ... [14:43] <Daemon404> you people are children [14:43] <durandal_1707> similar was with wmall, which is still incomplete [14:43] <Daemon404> or dirac [14:43] <Daemon404> or rememer flashv2? [14:43] <michaelni> Daemon404, I asked the main author yesterday [14:44] <Daemon404> what was smarter's response? [14:44] <michaelni> and and his awnser was "sure" so that doesnt sound like is is against it being merged [14:44] <ubitux> michaelni: make sure you address the remaining issues though [14:44] <ubitux> (http://lists.libav.org/pipermail/libav-devel/2013-October/051938.html) [14:45] <durandal_1707> perhaps if it get merged into ffmpeg more people will send patches? [14:45] <ubitux> Daemon404: also, "experimental" flagged afaik [14:46] <ubitux> ...and actually still not merged, but waiting for reviews [14:46] <Daemon404> i mostly see this as an impatient race between children [14:46] <Daemon404> or perhaps the quintissential youtube comment: FIRST!!!11one [14:47] <michaelni> Daemon404, you are are a libav supporter of course you argue that libav should have it first :) [14:47] <durandal_1707> so now we are children, when it get merged, we will become what? [14:47] <Daemon404> michaelni, i suppose sanity [14:47] <Daemon404> something which neither project sports. [14:47] Action: Daemon404 is so tired of this tribalistic bs [14:49] <durandal_1707> sorry for spam [14:49] <michaelni> Daemon404, do something about it, for example force both projects to merge back tgether into one, if you know how to achive that [14:50] <Daemon404> i think the term for that is the apocalypse [14:50] <Daemon404> but it sure would be nice to go a ay without hearing some sort of childish animosity between the two [14:50] <Daemon404> day* [14:50] <durandal_1707> simple: ditch devs that are against it [14:53] <michaelni> also about hevc review, review comments to the hevc patch should posibly be CCed to the openhevc developers, their emails are in the commit message anyway, that is if they arent subscribed [14:54] <Daemon404> the patches are mostly smarter and Paranoialmaniac [14:54] <Daemon404> and vittoro i think [14:54] <Daemon404> a bunch of openhevc stuff has no been brought in [14:54] <Daemon404> such as walls of intrinsics [15:00] <Paranoialmaniac> i don't touch image decoding process [15:02] <Paranoialmaniac> i only contribute non-annexb format decoding [15:03] <michaelni> Paranoialmaniac, ok if i push your patch to ffmpeg master ? [15:03] <michaelni> ffmpeg git master branch that is [15:04] <Paranoialmaniac> what patch? [15:05] <michaelni> [FFmpeg-devel] [PATCH 2/7] lavf/mov: Support HEVC demuxing. AND [FFmpeg-devel] [PATCH 3/7] lavf/matroskadec: Support HEVC demuxing. [15:06] <michaelni> of course with review comments from ffmpeg-devel taken care of [15:06] <Paranoialmaniac> does pushing these patch make sense without the decoder? [15:09] <michaelni> They could be usefull for remuxing, testing and should improve ffprobe output (codec name). Also its a step toward hevc support, we have to start somewhere with commiting and pushing [15:11] <Paranoialmaniac> michaelni: i don't recommend pushing these patches. the format is still in a draft. not finalized yet [15:15] <michaelni> Paranoialmaniac, IMHO we should support draft based files even after the specifications become final, we do similarly with mpeg4-asp for example where all kinds of pre final cases are supported in the decoder [15:15] <Paranoialmaniac> l-smash and divx uses configurationVersion=0 which indicates a draft ver. and the draft format may be changed more. [15:24] <Paranoialmaniac> michaelni: i dislike supporting draft files. this is similar with the reason supporting a bugged file which makes a spec-compliant file broken result [15:26] <michaelni> spec compliant files must always be decoded correctly, and none of the pre spec support we have in mpeg4-asp should affect spec compliant files though i guess iam drifting off topic [15:27] <michaelni> Paranoialmaniac, would you be interrested in maintaining the mkv or mp4 demuxers in ffmpeg ? [15:27] <Paranoialmaniac> i don't know mkv [15:27] <michaelni> ok [15:28] <michaelni> i was asking because generally ffmpeg tries to support everything (at least when its easy and files exist in the wild) [15:30] <michaelni> and these 2 dont have active maintainers so theres no maintainer to ask about his oppinon on possible pre spec support [15:33] <Paranoialmaniac> i don't have much time. my hand is full by my own project [15:34] <michaelni> "not much" is more than the current maintainers put into mp4, and this is quite sad as .mp4 is an important format [15:34] <Daemon404> this reminds me... [15:35] Action: Paranoialmaniac dislikes mp4 :P [15:35] <Daemon404> at VDD, Thierry Foucu mentioned ending multiple edit list entry support [15:36] Action: Daemon404 wonders what happened to that; would love to ditch his scripting for that edge case [15:40] <Paranoialmaniac> i don't want to maintain unless it is a paid work or what i need [15:42] <michaelni> Paranoialmaniac, maybe thierry would pay for it if you also implement full edit list support [15:42] <Daemon404> michaelni, thierry told me he already wrote a patch for this [15:42] <Daemon404> supposedly. [15:43] <Daemon404> maybe is misheard [15:43] <Daemon404> i* [15:43] <michaelni> yes, i rememer too, i thought he wanted to send it to the ML [15:43] <Daemon404> he told me he would... [15:43] <michaelni> not sure if it was sent [15:43] <Paranoialmaniac> edit list support is so hard... [15:43] <Daemon404> it wasn't [15:53] <mraulet> michaelni, the patch on openhevc/wrapper is not needed since most of the code is reported to the patch 4/7 [16:31] <michaelni> mraulet, what to you mean by "the patch on openhevc/wrapper" ? the "[PATCH 7/7] lavc: add libopenhevc support" ? [16:33] <mraulet> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-October/149333.html [16:33] <mraulet> this one is enough [17:19] <michaelni> ubitux, Daemon404 durandal_1707, others, does anyone of you object to the hevc patch being applied ? [17:19] Action: michaelni wishes he could just do usefull work instead of this [17:22] <saste> michaelni, ping on [RFC] Change av_get_channel_layout() syntax [17:22] <iive> i didn't quite get what the issue with the patch is... [17:23] <durandal_1707> that ffmpeg would get hevc before libav [17:23] <Daemon404> michaelni, ... have the issues ubitux linked to been addressed? [17:23] <Daemon404> they are not small issues. [17:24] <michaelni> ubitux, linked to the patch itself unless iam mistaken [17:24] <Daemon404> he did not [17:24] <Daemon404> you clearly didnt read what he linked [17:24] <Daemon404> the hevc decoder still suffers from invali memory use, causing failures in some areas [17:24] <Daemon404> and some frame mt 'issues' [17:25] <michaelni> so does jpeg2000 [17:25] <iive> openhevc or elenril's hevc? [17:25] <Daemon404> both [17:25] <Daemon404> it has overreads etc [17:25] <Daemon404> initially they thought it was a BE arch issue, but its not. [17:25] <iive> mpeg2 also have overreads. [17:25] <Daemon404> ... [17:26] <iive> maybe we should disable it... [17:26] Action: Daemon404 cant believe how ridiculous these arguments for merging RIGHT AWAY GODDAMMIT [17:26] <Daemon404> gotta have it first!!!! [17:26] <michaelni> jpeg2000 also has overreads and its not marked experimental [17:26] <Daemon404> it alos uses unitiliazlied data [17:26] <Daemon404> which ALSO causes failures [17:26] <Daemon404> it is not ready to be erged [17:26] <Daemon404> learn soem goddamn patience [17:26] <Daemon404> -_- [17:27] <iive> well, none of these are ffmpeg problem..., are they? [17:27] <Daemon404> uhhhhhhh [17:27] <Daemon404> what? [17:27] <iive> i mean, hevc problems... [17:27] <Daemon404> problems with code being merged into ffmpeg is not ffmpeg's problem? [17:27] <iive> or more specificly openhevc... [17:27] <Daemon404> what sort of drugs do ou do? [17:27] <durandal_1707> if michaelni what to fix those problems, i'm ok with merge, otherwise noe [17:27] <durandal_1707> *not [17:28] <durandal_1707> Daemon404: libmpcodecs [17:28] <Daemon404> durandal_1707, id rather not repeat that [17:28] <Daemon404> ever. [17:28] <wm4> merge mplayer's libvo to improve libavdevice! [17:29] <durandal_1707> wm4: patchwelcome [17:30] <iive> michaelni: are you talking about openhevc patch or merging elenril's hevc, or both? [17:30] <michaelni> Daemon404, the link from ubitux does not link to any clear or useable bug descriptions and no hint to overreads [17:30] <durandal_1707> iirc openhevc one is already rejected [17:31] <iive> why? [17:31] <Daemon404> michaelni, yes because theyre being discussed by teh actual authors of the patch [17:31] <Daemon404> on irc [17:31] <michaelni> and the frame threading issue thats mentioned sounds lie just a performce thing [17:31] <iive> authors don't want ffmpeg to use it? [17:31] <Daemon404> this is what happens when you just go and try to merge shit without the involvement of the authors [17:31] <Daemon404> iive, no its *not done yet* [17:31] <Daemon404> which is my point [17:31] <iive> what is not done? [17:31] <Daemon404> the hevc decoder! [17:32] <Daemon404> michael just suddenly decided he wants to merge it [17:32] <iive> x264 is not done yet, is it? [17:32] <Daemon404> .... all of your arguments are fuckign retarded [17:32] <Daemon404> at bets [17:32] <Daemon404> strawmen [17:32] <Daemon404> best* [17:32] <michaelni> iive, none of the authors objected [17:32] <Daemon404> michaelni, yes merge it *once it's fixed* [17:33] <Daemon404> uninitialized data usage is kind of Not Cool [17:33] <iive> Daemon404: is there bugreport for it? with a test case? [17:33] <michaelni> the decoder would be marked as experimental [17:33] <Daemon404> why would there be a bug report [17:33] <Daemon404> for a WIP? [17:33] <iive> to fix it. of course [17:33] <michaelni> yes [17:33] <iive> this is ffmpeg, not libav [17:34] <Daemon404> how is this at all relevant [17:34] <Daemon404> seriosly, do you ever have idea what the hell youre talking about, iive? [17:34] <Daemon404> like, ever? [17:34] <iive> Yes, I do. The problem is that you are unable to understand me. [17:35] <iive> don't worry, you are not the only one. [17:35] <michaelni> Daemon404, that "merge it *once it's fixed*" story is told since how long ? years ? [17:35] <Daemon404> what exactly is teh benefit or merging in a broken decoder? [17:36] <ubitux> decoding hevc [17:36] <Daemon404> emphasis on broken [17:36] <Daemon404> it relies on uninit'd data on all archs [17:36] <Daemon404> if it works [17:36] <Daemon404> its by coincidence [17:36] <ubitux> michaelni: i don't really mind if that eases your work on it [17:36] <iive> Daemon404: in essence it is cathedral vs bazaar development model. we are waiting for somebody to fix something, instead of working together to fix it. [17:37] <iive> I got that ffmpeg is not that territorial in its philosophy. [17:37] <ubitux> Daemon404: it's experimental, so... [17:37] <Daemon404> again [17:38] <Daemon404> hat is the benefit of merging [17:38] <Daemon404> otehr than being "First" [17:38] <ubitux> ease the work on it [17:38] <Daemon404> what work [17:38] <ubitux> fixing those issues? [17:38] <Daemon404> ffmpeg has literally done nothing on it [17:38] <Daemon404> until a few hrs ago [17:38] <ubitux> because it was never submitted to ffmpeg-devel? [17:38] <iive> well, this is because we've been waiting for over a year [17:38] <iive> to be done and merged in libav... [17:38] <Daemon404> OH NOES WE CANT DECODE ALL THE NON-EXISTENT HEVC STREAMS [17:39] <Daemon404> the spec wast even finalized until recently [17:39] <iive> you are aware that the mpeg4-asp decoder doesn't implement all iso14496-2 features, are you? [17:39] <wm4> what the hell is the problem? on Libav side, the decoder is becoming ready for merge [17:40] <Daemon404> iive, again. strawman argument. [17:41] <iive> Daemon404: maybe it is not that you can't understand me, maybe you just don't want. [17:54] <durandal_1707> let them cry! merge time. [17:56] <durandal_1707> and than release 3.0 [18:00] <durandal_1707> much better than certain fork that still have fully broken decoder [18:00] <wm4> make it 4.0, to be one step ahead [18:07] <michaelni> Daemon404, ive decoded 2 hevc files under valgrind there are no anomalies here [18:07] <Daemon404> iirc its only with some samples [18:07] <Daemon404> and no, i dont have info on which [18:08] <Daemon404> if you really feel you need to merge right goddamn now, im just going to sit back with popcorn [18:08] Action: Daemon404 is no longer involved, disavows all knowledge, and awaits lulz [18:09] <michaelni> its no problem to wait a day, also no problem for me to fix a few bugs, but this "ohh god dont apply that patch its not done" is very puzzling to me [18:10] <iive> it's just fud [18:10] <Daemon404> and waiting until a few days before its merged in libav and deciding "i must merge it right now" is puzzling to me [18:10] <michaelni> its "few days" ? [18:10] <michaelni> can you be more specific ? [18:10] <iive> say a number [18:10] <Daemon404> wat [18:11] <Daemon404> foss had deadlines now? [18:11] <iive> say how many days we should wait for these bugs to be fixed [18:11] <Daemon404> im saying i dont give a fuck [18:11] <iive> yes, 2 weeks for linux kernel. [18:11] <Daemon404> enjyo your penis waving competitio [18:11] <Daemon404> n [18:11] <Daemon404> as i said [18:11] <Daemon404> im am sitting back andd watching [18:11] <Daemon404> i am not ivolved. [18:11] <Daemon404> pretend im not here. [18:12] <durandal_1707> How many k&r rounds does it take to push a patch? [18:12] <iive> between 5 and 7 [18:14] <iive> don't forget to sort the files alphabetically. [18:14] <kierank> Daemon404: choose your poison [18:15] <Daemon404> kierank, ? [18:15] <kierank> Daemon404: spacing review or dick waving contest [18:15] <Daemon404> i chose a third option [18:15] <Daemon404> to sit with popcorn [18:15] <Daemon404> and watch. [18:31] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:522f78f8eabf: avformat/oggparseopus: fix nb_headers [18:39] <michaelni> mraulet, smarter, AFAIK you 2 are the 2 main authors of the hevc code, thus my question, should i merge it now (that is today/within a few days) or should i wait because of something (major bugs, the authors preferring that we dont merge it yet, whatever) ? [18:56] <mraulet> we now are 3, the code has been a lot refactored by elenril [19:02] <michaelni> i understand, and what preferrance do the 3 of you have ? merge or wait? [19:05] <mraulet> I like consensus between people, I need to interact with them [19:05] <michaelni> yes, of course [19:34] <BBB> Daemon404: you really should listen more carefully to intelligent bystanders such as kierank - there is a lot of highly satirical - but true! - commonsense coming out of 'em [19:35] <Daemon404> there's a relevant lesson from the simpsons here [19:35] <Daemon404> http://www.youtube.com/watch?v=nhjGoaKf52s [19:35] <Daemon404> ^ [19:36] <BBB> I like south park's morale: blame canada [19:36] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:ac3b01a9c060: avcodec/jpeg2000dec: check transform equality in MCT [19:42] <cone-735> ffmpeg.git 03Marton Balint 07master:b118d3e24d35: ffplay: factor out putting null packet into the queue [19:42] <cone-735> ffmpeg.git 03Marton Balint 07master:0258e4dc8ba8: ffplay: add null packet after attached pics packet [19:42] <cone-735> ffmpeg.git 03Marton Balint 07master:543d81a7072c: ffplay: cycle through the streams of the current program, and not every stream [19:42] <cone-735> ffmpeg.git 03Marton Balint 07master:3130416aecc8: ffplay: add support for changing the channel by the C key [19:42] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:ede7602cba81: Merge remote-tracking branch 'cus/stable' [21:49] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:e54f4510aa45: avcodec/jpeg2000: zero i/f_data [21:49] <cone-735> ffmpeg.git 03Michael Niedermayer 07master:fe448cd28d67: avcodec/jpeg2000dec: prevent out of array accesses in pixel addressing [22:09] <smarter> michaelni: as people said, the patch is still buggy, incomplete, and people are working on it [22:09] <smarter> I don't think merging it in ffmpeg and marking it experimental is going to be a big problem, which is why I'm not opposed to it [22:10] <smarter> but I don't think it's worth it (and certainly not worth the drama...) [22:24] <cone-735> ffmpeg.git 03Paul B Mahol 07master:3fd79833e266: avformat: add ff_alloc_extradata() helper [22:24] <cone-735> ffmpeg.git 03Paul B Mahol 07master:a807c68253b0: avformat: use ff_alloc_extradata() [22:24] <cone-735> ffmpeg.git 03Paul B Mahol 07master:5340c3dd8d2a: avformat/westwood_vqa: s/unsigned char/uint8_t & s/unsigned int/uint32_t [22:26] <llogan> i wonder why --compose ignored my subject. [22:27] <ubitux> isn't git already a synonym of stupid? [22:27] Action: durandal11707 spotted typo [22:27] <gitarded> where? [22:27] <gitarded> ubitux: then this (temp) nick is a double negative. [22:29] <gitarded> durandal11707: in my x11grab doc patch? [22:30] <durandal11707> no, in nick [22:34] <ubitux> durandal11707: are you registered to cvslog? [22:35] <durandal11707> you want to tell me something? [22:35] <ubitux> i was having a look to the extradata diff [22:35] <ubitux> and i was wondering if i could reply on cvslog [22:35] <ubitux> but if you prefer over irc fine with me as well [22:36] <ubitux> i have 2 things that bug me a little [22:36] <durandal11707> what is bugging you? [22:37] <ubitux> first is not important, but you are considering any ff_alloc_extradata as a ENOMEM error even if that function can actually raise different error code [22:37] <ubitux> you certainly did that so the diff is less error prone so fine with me [22:37] <ubitux> second one is the zero init of the full buffer in some cases [22:37] <ubitux> which doesn't happen all the time with your code [22:37] <durandal11707> and? [22:38] <ubitux> mallocz was likely called for padding, but sometimes it might not have [22:38] <ubitux> see for example bink [22:38] <ubitux> what happen if less than 4 bytes are read [22:38] <ubitux> probably relevant for a few other formats [22:38] <ubitux> you might have some uninitialized data in some cases [22:39] <durandal11707> well you can consider it as bug into bink [22:39] <ubitux> in the second case, i see a AV_WL32 [22:39] <durandal11707> i can use mallocz in ff_alloc_extradata and do not bother with it ... [22:39] <ubitux> oups no second one is fine [22:40] <ubitux> durandal11707: yeah, probably [22:40] <ubitux> or we could check every format [22:40] <ubitux> or have an extra parameter for zero full zero init [22:40] <ubitux> most extradata buffers are not so big anyway [22:41] <ubitux> see flv as well [22:41] <ubitux> and well, probably a bunch of others [22:42] <ubitux> i would suggest a 0 memset, since it could introduce random uninit reads [22:43] <wm4> uh so what's wrong with mallocz? [22:43] <ubitux> ? [22:43] <wm4> to clear [22:45] <durandal11707> hurts performance [22:45] <durandal11707> a little [22:45] <wm4> allocating big chunks of memory with calloc() makes clearing free (because mmap(), which will be used by calloc, already clears anyway) [22:46] <ubitux> wm4: see av_mallocz() [22:46] <ubitux> if (ptr) [22:46] <ubitux> memset(ptr, 0, size); [22:46] <wm4> hurr [22:46] <ubitux> it's not free in ffmpeg [22:46] <ubitux> we can't call calloc because of alignment [22:47] <durandal11707> there is av_calloc but it is not calloc [22:49] <ubitux> correct thing would just be to check reads() in those formats [22:51] <ubitux> s/would/could/ [22:57] <durandal11707> wm4: why mpv does not support gbrap16? [22:59] <ubitux> does changing the link->frame_rate in filters affects anything? [23:00] <ubitux> durandal11707: since decimate is adjusting the link frame_rate, is it enough for time stamping? [23:00] <ubitux> (is your patch dropping the ts adjustment fixing the sync issue?) [23:01] <durandal11707> dunno, the only problem would be some frames are too long displayed on screen [23:01] <ubitux> you mean it would defeat the purpose of the ivtc process? [23:01] <durandal11707> ubitux: for sample i have it fixes async [23:02] <ubitux> and what's the out frame rate? [23:02] <durandal11707> ubitux: input is ~29 out is ~25 [23:02] <ubitux> well then that's likely correct; did you check if the ts are constant in the output? [23:03] <ubitux> ts diff* [23:03] <durandal11707> is not constant obviously [23:03] <ubitux> then it's not correct [23:03] <durandal11707> but you do not change time_base .... [23:04] <ubitux> i guess the time base needs to be adjusted as well then [23:04] <ubitux> just like fps [23:04] <durandal11707> ubitux: do you mean created output of what decimate returns? [23:04] <durandal11707> i just checked what decimate returns [23:05] <durandal11707> s/of/or [23:05] <durandal11707> you can check yourself, there is sample on trac [23:05] <ubitux> yeah but i was lazy [23:05] <ubitux> or actually working on sth else [23:06] <ubitux> but i guess ill have to put it in standby again [23:06] <ubitux> well no, i can't stop right now, it will be a pain to start over [23:13] <ubitux> durandal11707: if adjusting frame_rate field makes no effect, then changing the time base (and dropping the ts computation) might do the trick [23:13] <ubitux> but now i'm curious about cases where frame_rate is inconsistent with the timebase [23:13] <ubitux> well, i'll eventually look at this later [23:27] <ubitux> BBB: i'm not sure i can use pmulhrsw [23:28] <ubitux> or well, maybe i should update the multiplier for the precision [23:31] <ubitux> i basically want this: [23:31] <ubitux> >>> '%04x' % ((0x3a * 0x2d41 + (1<<13)) >> 14) [23:31] <ubitux> '0029' [23:31] <ubitux> but i have this with pmulhrsw: [23:31] <ubitux> >>> '%04x' % ((0x3a * 0x2d41 + (1<<14)) >> 15) [23:31] <ubitux> '0015' [23:32] <ubitux> i'm afraid of ±1 rounding differences if i update the factor [23:33] <ubitux> (because of too accurate rounding) [23:40] <ubitux> so basically 0x5a82 instead of 0x2d41 do the trick for now, but i'm expecting potential problems [23:43] <ubitux> it looks like vp8 is doing a x2 on the source, for the same purpose [00:00] --- Mon Oct 14 2013

1 0

ffmpeg.log.20131013
by burek 14 Oct '13

14 Oct '13

[00:42] <undercash> hello [00:43] <undercash> did you had report with audio sync problems lately? [00:43] <undercash> i m just encoding standart files, and most of the video are out of sync [00:48] <beastd> undercash: See http://ffmpeg.org/bugreports.html [00:49] <undercash> thx [00:50] <undercash> but i guess if there was a major bug .. you would know yourself [00:50] <undercash> kinda curious.. [00:50] <beastd> you can search the ticket database if you do not find your problem and decide to report it provide commandline and full, uncut console output. if it is possible provide a small sample too. [00:50] <undercash> i dont want to report something I am ensure [00:50] <undercash> not sure* [00:51] <undercash> just thought you might have heard of something [00:51] <beastd> undercash: also it would be worth it too try with current ffmpeg git master [00:51] <undercash> i updated on 09/20 and since then , i think must of the videos are out of sync [00:52] <beastd> undercash: i do not know of any major regression on top of my head. but at any means update again and see if the problems you obeserve still exist [00:52] <undercash> yep why not [00:52] <undercash> thanks for your suggestions [00:52] <beastd> good :) [00:53] <beastd> also please understand that multimedia is a mean variety of all kinds of thinks chunked together in every conceivable way, so problems can appear in very isolated conditions :( [00:54] <undercash> yes but I didnt had this problem before [00:54] <undercash> it s either ffmpeg, either the remote rtmp server [00:54] <undercash> hard to say, only downloading a copy of what I am encoding [01:18] <denysonique> What is the safest format for an old TV to play? [01:18] <denysonique> it plays some .avi's [01:18] <denysonique> not sure about which codecs it understands [01:25] <beastd> denysonique: there is usually no satisfying answer to your question. best is to search for the model and see what others succeded with if you find any. other than that i am afraid you will have to use trial and error. [01:25] <denysonique> beastd: thanks. what codec should I begin with? [01:26] <beastd> i can't possible tell you because i know nothing about your tv [01:27] <denysonique> right, then what is the name of the codec which will play on a fresh install of Windows XP, without extra codecs being installed [01:27] <beastd> if you mention the AVI i would guess there was a time: mpeg4 video and mp3 audio in avi was very popular so i would start that direction. but i am just guessing here [01:28] <denysonique> yes, thats what I am thinking about as well, mpeg4 [01:32] <llogan> and provide a sample if possible so i can attempt to duplicate [01:33] <undercash> hm ok [01:34] <undercash> i dont use through terminal. but i can try [01:34] <llogan> how do you use it? [01:34] <undercash> webmin script [01:34] <undercash> well.. bash script [01:36] <undercash> -verbose? [01:36] <undercash> sorry dont have in mind the debug option [01:37] <llogan> no, just your command and the complete console output. [01:37] <llogan> the debug stuff is usually more annoying than useful [01:38] <undercash> -loglevel verbose [01:38] <undercash> ok [01:38] <llogan> omit that [01:38] <undercash> ah [01:38] <undercash> ok [01:47] <undercash> http://pastebin.com/pHWPGSnv [01:49] <llogan> undercash: which player are you using? does ffplay play it normally? [01:51] <undercash> i dont use ffplay [01:51] <undercash> i can download it .. but this vid in particular might not be very interesting regarding dialogues.. [01:53] <llogan> what's with your version number? i think it should be 56548 [01:53] <llogan> are you using a shallow git repository? [01:55] <llogan> maybe i should look in version.sh first but maybe it has issues with a shallow repo, or maybe I am confused [01:57] <llogan> undercash: does using a different aac encoder show the same behavior? [01:58] <beastd> hmm, the output seems to indicate that there is no audio stream at all... [01:58] <undercash> i don't know [01:59] <undercash> well i have audio for sure with my settings [01:59] <undercash> since i broadcast 20 channels [01:59] <undercash> but i notice this audio sync problem [02:00] <beastd> undercash: i am talking about your paste. can you make sure the input flv plays with audio. if it does can you test if ffplay plays it with audio too? [02:00] <undercash> gonna broadcast it in 5min live.. [02:00] <llogan> heh. i didn't even notice that [02:00] <llogan> at this point there isn't enough info from you to duplicate the issue or even narrow it down [02:01] <undercash> yes I don't know, really.. just noticing many documentaries have audio out of sync. and since it didnt happen before, I thought I might shoot a word here [02:02] <undercash> problem is I dont have the files locally.. it s downloaded directly on the server so I can't say.. gotta download them first [02:03] <undercash> the vid i paste must have audio.. it s from youtube [02:03] <llogan> if you play it i'm fairly sure you'll hear nothing due to a lack of an audio stream [02:07] <undercash> the converted file has no audio indeed, i guess i chose a bad example.. but i was trying to find a rather short file [02:10] <undercash> yea really unlucky video choice.. [02:10] <undercash> pff [02:10] <undercash> no audio either on original file [02:10] <llogan> problem solved. next! [02:15] <undercash> not really [02:16] <undercash> http://fr.justin.tv/xxxproducer1x#/w/7136049952/4 [02:16] <undercash> watch yourself [02:16] <undercash> if u understand, tell me if the mouth act as the sound [02:23] <undercash> you based your opinion on an unlucky example.. i didn't come here without reasons ;) [02:50] <llogan> undercash: looks ok to me [02:50] <undercash> no ;) [02:50] <llogan> but it might be harder for me since I don't speak Russian. [02:50] <undercash> slight delay [02:50] <llogan> just kidding. french [02:50] <undercash> ahah [02:51] <undercash> but yea , i ll make some testing locally with a random file, then see how the converted file behave [02:51] <undercash> i just thought it could have been a reported bug lately [02:51] <llogan> not that i know of [02:51] <undercash> i guess not [02:52] <llogan> but try a local file and also see if the problem is from faac (you can try -acodec aac -strict experimental) [02:54] <lakitu> i converted a file from avi to hv-whatever mp4, & it's got a bunch of green pixelation on it [02:55] <undercash> yea i know this one, never used it on "production" though [02:55] <lakitu> how to improve my command line fu to get rid of it? [02:55] <lakitu> i have five 4gig avi files i'm trying to convert [02:55] <undercash> i ll just recompile i guess [02:55] <undercash> but it s boring.. need to shutdown a lot of stuff [02:56] <llogan> if you recompile consider using fdk-aac instead of faac [02:56] <llogan> https://trac.ffmpeg.org/wiki/AACEncodingGuide [02:56] <undercash> interesting [02:56] <undercash> i have fdk-aac but i guess my command doesnt use it [02:57] <undercash> i kept using my libfaac command [02:57] <lakitu> http://pastebin.ca/2466232 [02:57] <llogan> it should provide better quality per bitrate compared to faac [02:57] <lakitu> ^ command [02:58] <lakitu> i just compiled with fdk-aac [02:58] <llogan> where's the complete console output? [02:58] <lakitu> lost out of the buffer [02:59] <lakitu> want me to run it again? [02:59] <llogan> yes, but add "-t 10" so you don't have to encode the whole thing [02:59] <undercash> gotta investigate this llogan [03:00] <undercash> a proper fdk command [03:00] <llogan> undercash: right now we don't know if: 1) it's faac's fault 2) it's ffmpeg fault 3) if it is RTMP or justin.tv fault 4) it is flash players fault 5) a combination [03:00] <undercash> i think ffmpeg changed quite a bit since february.. [03:01] <undercash> can't recognize much in what i see [03:01] <undercash> input.mp4 -c:v copy -c:a libfdk_aac -b:a 384k [03:01] <undercash> geez.. [03:01] <llogan> the old names still work too if you prefer them [03:01] <llogan> -vcodec -acodec -ab [03:01] <undercash> oh good [03:02] <undercash> -acodec fdk-aac is fine then? [03:02] <llogan> libfdk_aac as shown in the link i gave you [03:02] <undercash> ;) [03:02] <undercash> thank you [03:02] <undercash> i ll try asap [03:03] <undercash> ok ok -c:v -c:a [03:03] <undercash> donno why they always changed those stuff [03:03] <llogan> -codec:v/-c:v/-vcodec all do the same (ffplay only uses the old names still, AFAIK) [03:04] <lakitu> what frame should this get to [03:04] <llogan> it should create a 10 second output duration [03:04] <lakitu> it's on the 56 thousandth frame [03:04] <lakitu> seems much [03:05] <undercash> yes i understand, except in the manuals that have been updated.. i guess i just need to accept hollidays are over :P [03:05] <undercash> and work a bit [03:05] <llogan> i would expect it would end on frame 250 if the input is PAL [03:05] <lakitu> ok [03:05] <lakitu> can i truncate it with a ctrl+c break? [03:05] <llogan> or press "q" probably [03:05] <lakitu> there [03:05] <lakitu> it finished [03:07] <lakitu> i ran out of buffer; [03:07] <lakitu> extended my buffer & redoing it [03:07] <lakitu> thanks for the help - that was probably like my 5th compile ever [03:08] <llogan> you added -t 10? or you could use -vframes 100 instead [03:08] <lakitu> i'll try vframes so i don't have to wait [03:08] <lakitu> -t 10 is letting it run this long [03:08] <lakitu> altho it's huge: [03:08] <lakitu> 4gigs for 37minutes [03:08] <lakitu> each [03:08] <lakitu> i've got 5 of them [03:08] <lakitu> 5 4gig files of 37minutes each [03:08] <lakitu> which is why i need to compress them, obviously [03:10] <lakitu> did the arguments have to be placed somehwere special? [03:10] <llogan> yes. as output options they should be placed after "-i input" [03:11] <lakitu> lemme try again [03:11] <lakitu> ok [03:11] <lakitu> it was a placement issue - copying [03:12] <lakitu> http://pastebin.ca/2466234 [03:13] <lakitu> the no pixel format specified, is that it? [03:13] <lakitu> someone in linux gave me the command [03:13] <lakitu> #linux [03:13] <llogan> Use -pix_fmt yuv420p for compatibility with outdated media players. [03:13] <lakitu> so that? [03:14] <lakitu> had i enough experience with linux, i would've known to look at the output for errors [03:14] <llogan> it says that in the console output. so add -pix_fmt yuv420p as an output option [03:14] <lakitu> ok [03:14] <llogan> also see https://trac.ffmpeg.org/wiki/x264EncodingGuide [03:14] <lakitu> ok [03:15] <llogan> but if the output looks good enough then you don't need to do anything since the defaults are decent (except for -pix_fmt for general users) [03:15] <lakitu> ok [03:15] <llogan> what player was it looking shitty in? [03:15] <lakitu> what's a good linux video editor, to sharpen/etc my personal lectures? [03:16] <lakitu> these aren't just movies you know [03:16] <llogan> kdenlive seems ok [03:16] <lakitu> i made some video lectures - i'm not sure, the simplest one for fedora [03:16] <lakitu> ok [03:16] <llogan> but you should tweak the ffmpeg encoding presets in kdenlive [03:16] <lakitu> can you separate off the audio track, edit it, & then put it back on? [03:17] <lakitu> not sure what you mean [03:17] <llogan> i haven't looked in a long time, but the ffmpeg settings may not be that great in kdenlive [03:18] <llogan> as for the audio: ffmpeg -i video.mp4 -i audio.wav -map 0:v -map 1:a -codec:v copy -codec:a libfdk_aac output.mp4 [03:19] <llogan> this will take the video from video.mp4 and the audio from audio.wav. it will stream copy the video (no encoding) and encode the audio using libfdk_aac [03:19] <llogan> http://ffmpeg.org/ffmpeg.html#Stream-copy [03:21] <llogan> to get the audio: ffmpeg -i input output.wav [03:32] <buhman> is libswresample considered higher quality and/or faster than libasound's built-in resampler? [03:37] <lakitu> sweet, thanks logan. your advice worked, the pixel artifacts are gone [03:38] <lakitu> saving your commands for how to edit the audio [03:39] <lakitu> last question - i've got 1.5gigs for a 37 minute file - can i compress it (well) anymore? [03:39] <lakitu> good compression means meaningfully smaller but still enough quality to make out whiteboard writing [03:40] <lakitu> actually it's only 845 for some reason this time [03:40] <lakitu> 845mb [03:40] <lakitu> if that is optimal for quality being prioritized, what is optimal for size being prioritzied [03:41] <lakitu> what would be a good small format, that is [03:43] <undercash> its funny, been using -c:a libfdk_aac and the stream didnt work [03:43] <undercash> guess i dont have ffmpeg compiled with that library [03:43] <undercash> though it s installed [03:45] <lakitu> flv? [03:50] <lakitu> or limit the kb/s [05:05] <raytiley> Does anyone know the status of using directshow crossbar devices with ffmpeg. From googling seems like there was talk of support but I can't find anything less than 8 months old. [05:28] <llogan> buhman: i'm not sure. there is also libsoxr which ffmpeg supports [05:28] <llogan> https://trac.ffmpeg.org/wiki/FFmpeg%20and%20the%20SoX%20Resampler [05:28] <buu> Hey, how do you control how many threads ffmpeg uses? [05:29] <llogan> -threads <int> [05:29] <buhman> llogan: well, I was looking more for comparisions rather that yet more alternatives ;p [05:30] <buu> llogan: Well, ok, that's obvious, but why isn't it in man ffmpeg [05:30] <buhman> buu: because the ffmpeg manual is split [05:31] <buu> Oh my god [05:31] <llogan> see "man ffmpeg-all" for the monolithic man page [05:32] <buu> Don't have it =[ [05:32] <llogan> maybe your ffmpeg is old [05:32] <buhman> llogan: ffmpeg-codecs(1) line 805 [05:32] <buu> llogan: 1.1.3 [05:33] <buhman> buu: that's post-man-split [05:33] <llogan> i have no idea [05:33] <buhman> though I think ffmpeg-all came later [05:33] <buu> So I noticed =] [05:33] <buhman> buu: no doubt you have ffmpeg-codecs though [05:33] <buu> I do! I read it! [05:33] <buhman> :D [05:34] <buu> It says "threads: controls the number of threads" [05:34] <buu> High quality documentation! [05:34] <buu> =] [05:34] <llogan> lakitu: 845mb is the input or the output? [05:35] <llogan> buu: patches welcome [05:35] <buu> Hrm. Why does my cpu only have 4 threads =[ [05:35] <buhman> well it makes sense to me, it's organized mostly by library obviously [05:39] <llogan> buhman: i recall a resampler comparison with graphs 'n junk but i can't seem to find it [05:40] <buhman> but specifically one that compares libasound's resampler to libswresample [05:40] <buu> Does -threads default to something? [05:40] <llogan> buhman: i can't remember. useful, huh? [05:40] <buhman> buu: auto [05:41] <buu> Oh [05:43] <llogan> default 1, unless you're using en external encoding library that changes it, such as libx264 which is auto [05:43] <llogan> frame based threads: 1.5 * logical processors, rounded down; slice based threads: 1 * logical processors [05:43] <llogan> ^ for libx264 [05:44] <llogan> and you're probably doing frame based [05:47] <buu> llogan: so its a h264, so that invokes libx264, which invokes 6 threads? [05:47] <buu> 4 logical processors [06:19] <llogan> buu: you can see the console output to show the number of utilized threads [06:19] <buu> Oh. [06:19] <buu> Cool. [06:26] <llogan> buhman: old, but might be interesting and no mention of libasound: http://www.hydrogenaudio.org/forums/index.php?showtopic=99286 [10:06] <lakitu> some code i wrote from help i got earlier isn't quite working right - maybe osmeone can help me [10:06] <lakitu> i'm putting it on pastebin now [10:07] <lakitu> here's the bash shell code: http://pastebin.com/8nuZg3am [10:08] <lakitu> & then here's one result (it's a batch script). the goal was to lay wav audio tracks into mp4 files http://pastebin.com/HthUJ6nK [10:11] <lakitu> i have that library, it works in another script [10:11] <lakitu> or another command [10:11] <lakitu> i just compiled specifically with that library [10:27] <buu> What specifically isn't working? [10:28] <lakitu> it says can't find the library [10:28] <lakitu> like in the paste [10:29] <lakitu> but i have that library, & was just usin git [10:29] <lakitu> i'm pretty sure [10:29] <lakitu> yes. i was [10:29] <buu> Oh there's two pastes [10:29] <lakitu> yeah [10:29] <lakitu> i forgot i had it in a separate text file [10:29] <buu> TRICKY [10:29] <lakitu> gotcha. [10:30] Action: lakitu reveals the candid cameras [10:31] <buu> Are you sure you're using the same instance of ffmpeg in both places? [10:32] <lakitu> hm, how would i - oh you're right [10:32] <lakitu> i think! [10:32] <lakitu> good catch... [10:32] <lakitu> well [10:32] <lakitu> wait [10:32] <lakitu> i compiled it [10:32] <lakitu> does that mean it's in a folder somewhere [10:32] <lakitu> (directory =P) [10:32] <buu> lakitu: Unless you installed it somewhere else.. [10:32] <lakitu> or it's the default 'ffmpeg' [10:32] <lakitu> no [10:33] <lakitu> because i was just calling 'ffmpeg {arguments}' & it was working, with that library [10:33] <buu> lakitu: run this: ffmpeg -encoders [10:33] <lakitu> there's a lot [10:33] <lakitu> aac is x'd [10:34] <buu> lakitu: So wait, you compiled your own version of ffmpeg? Where did you do it? How did you do it? [10:35] <lakitu> https://trac.ffmpeg.org/wiki/CentosCompilationGuide [10:35] <lakitu> in some folder, if that's what you mean [10:36] <buu> lakitu: so you did the previous steps then ran ./configure ...; make; make install? [10:37] <lakitu> yes, with the pre-./configure steps of getting the plugins [10:37] <lakitu> or some of them [10:37] <lakitu> like it shows [10:37] <buu> lakitu: ok, what does find $HOME/ffmpeg_* | grep bin; show you? [10:38] <buu> In otherwords, where did you install ffmpeg? [10:38] <buu> And what does which ffmpeg; show you? [10:38] <lakitu> i just copied-n-pasted, i have no idea [10:38] <lakitu> the first says Is a directory [10:38] <lakitu> the second says /usr/bin/ffmpeg [10:39] <buu> lakitu: wait, what? it says is a directory? [10:40] <buu> lakitu: Let me rephrase that, what files are in $HOME/bin; ? [10:40] <lakitu> bash: /home/me/ffmpeg_build: Is a directory [10:40] <buu> lakitu: You're supposed to put 'find' in front of that! [10:41] <lakitu> oh =P [10:41] <lakitu> good catch again [10:41] <buu> lakitu: But I think you should have $HOME/bin/ffmpeg [10:41] <lakitu> a bunch of stuff [10:41] <buu> And that's the one you compiled [10:41] <lakitu> must've [10:42] <buu> Do you see what I'm getting at here? [10:42] <lakitu> but it worked when i just used ffmpeg with that library [10:42] <lakitu> do i have to specifically call that ffmpeg? [10:42] <buu> Yes [10:42] <buu> I have no idea what you did before [10:42] <lakitu> but i think i wasn't [10:43] <buu> Try it with $HOME/bin/ffmpeg instead [10:43] <buu> and see what happens [10:43] <lakitu> ok [10:45] <lakitu> doing [10:45] <lakitu> working. weird [10:45] <lakitu> not sure, but i need asian soup bowl now. thanks [10:46] Action: buu shrugs [14:17] <khali> are there options I can pass to ffmpeg to improve the quality when encoding audio to AAC? [14:17] <khali> I see suggestions for high quality video in the FAQ but nothing for audio [14:52] <LithosLaptop2> khali: you can use a higher VBR setting of 5 when using '-c:a libfdk_aac' by add '-vbr 5' instead of specifying the bitrate [14:57] <LithosLaptop2> khali: when using libfaac try instead of libfdk_aac' then try to keep the bitrate higher than 192Kbit/s. IMO libfaac doesn't wotk well below 192Kbps. libmp3lame would be a better choice [14:58] <LithosLaptop2> khali: for libfaac I would use something like: -c:a libfaac -q:a 330 -cutoff 15000 [15:00] <LithosLaptop2> khali: for the internal aac encoder try to keep the bitrate around/above 240Kbps: -c:a aac -b:a 240k -strict -2 For older ffmpeg builds you might need to add -cutoff 15000 [15:01] <LithosLaptop2> khali: never use libvo_aacenc [15:01] <LithosLaptop2> thats about it for aac [15:46] <khali> 192 kbps seems a lot for a movie audio track [15:47] <khali> the whole point of AAC is that it compresses better than MP3 [15:47] <khali> and I wouldn't even consider 192 kbps for MP3 [15:47] <khali> at 192 kbps even MP2 is good enough... [15:59] <sacarasc> khali: https://trac.ffmpeg.org/wiki/AACEncodingGuide [16:16] <iive> 192kbps is the minimum for mp2/3 [16:16] <khayyam> hello, I'm having a linking error with the current svn: libavcodec/libavcodec.so: undefined reference to `ff_idct_xvid_mmxext_put' (and other ff_idct_xvid_* refs). I was previously able to build the tree, the last being Sept 29th, but something seems to have changed. The build.log: http://bpaste.net/show/140133 ... any ideas? [16:50] <khali> iive: minimum for what? [17:20] <iive> for quality [17:20] <iive> and with mp2 i think it is the lowest possible bitrate [17:32] <who0> Hi All, I would like to convert into "profile High, level 4.0" with 700k but ffmpeg says " profile High 4:4:4 Predictive, level 4.0, 4:2:0 8-bit" lossless :( -- Have you got some clue ? [17:46] <khali> iive: mp2 128 kbps does exist [17:47] <iive> mono? [17:48] <khali> some DVB-T broadcaster use that for secondary languages here in France [17:48] <khali> iive: no, stereo [17:48] <khali> iive: but 128 kbps mp2 doesn't sound good [17:48] <iive> maybe I should look up the standard. [17:48] <khali> they really shouldn't be doing that [17:48] <iive> 128kbps mp3 doesn't sound good. [17:51] <khali> iive: I don't get your point on that [17:51] <sacarasc> 128kbps MP3 is poo. [17:51] <khali> iive: 128kbps mp3 used to be the standard for audio CD ripping [17:51] <khali> so for a movie it seems good enough to me [17:51] <who0> I found ... how to force rc=abr instead of rc=cpq with libx264 (it sounds good ?) [17:52] <sacarasc> khali: The operative part there is "used to be". Not any more. [17:53] <khali> sacarasc: isn't it odd given that encoder quality improved meanwhile? [17:53] <khali> 128 kbps today is better quality than it was in the early 2000s [17:53] <sacarasc> So has storage capacity. [17:53] <sacarasc> 5GB in 2000 to 5TB now. [17:54] <khali> sacarasc: that's a very good point, I admit [17:55] <khali> but I still don't think it makes sense to put too much bitrate on the audio when it brings no listening benefit [17:55] <khali> the audio streams come to me as 192 kbps or 256 kbps mp2, that's not CD audio quality [17:56] <khali> I doubt it makes sense to reencode 192 kbps mp2 to 192 kbps AAC, as LithosLaptop2 was suggesting above [18:00] <sacarasc> Reencoding lossy to anything is pointless, unless it's needed because of some hardware incapability. [18:07] <iive> khali: it is rare, but once I had an anime with such poor audio quality that I had to find another release... [18:08] <zap0> oh NO! [18:08] <iive> saving few kbps when your video is mbps is really pointless. [18:09] <LithosLaptop> try saying that to the people broadcasting our DVB-T2 channels [18:10] <LithosLaptop> every channel has crappy 64Kbps audio [18:32] <who0> it dosen't work :( I have = high profile doesn't support lossless ... and I don't know why (google didn't help me) [19:13] <iive> LithosLaptop: I hope thay are using at least aac :| [19:14] <LithosLaptop> yeah AAC-HE [19:16] <iive> well, aac-he have been developed for low bandwidth communication, like phones... [19:59] <khali> sacarasc: that's exactly the problem... I'd leave mp2 audio streams as is, but most hardware decoders can't cope with mp2 audio streams in mp4 containers [20:00] <khali> (192 kbps I'd leave as is... 256 kbps I'd certainly reencode anyway) [20:03] <khali> iive: my video streams are in the 600-900 kbps range [20:03] <khali> iive: so 128 vs. 192 vs. 256 kbps audio isn't that pointless [20:03] <khali> or even 112 kbps, as this is what I use at the moment in most cases [20:37] <Apic> Yoo hoo. [20:37] <Apic> (UGT) [21:13] <francogrex> is this for real? about ffmpeg: "*** THIS PROGRAM IS DEPRECATED *** This program is only provided for compatibility and will be removed in a future release. Please use avconv instead." [21:15] <JEEB> that is regarding the ffmpeg BINARY within the libav project [21:15] <JEEB> not the ffmpeg project [21:15] <francogrex> ah ok, because all I did was apt-get install ffmpeg and then got this message [21:15] <JEEB> basically elenril rewrote much of the ffmpeg cli application over at libav, and the rewrite was called avconv [21:15] <JEEB> yes, if you use a distro that uses libav, you use avconv [21:15] <JEEB> because that's the more updated binary [21:16] <JEEB> (within that project) [21:16] <francogrex> ok [21:16] <JEEB> ffmpeg (project) still has its ffmpeg (tool) [21:17] <JEEB> the ffmpeg tool was then removed with the next libav release, IIRC. So it only has the avconv tool. [21:24] <llogan> francogrex: for more info http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html [22:11] <DrSlony> Hi, what is the best way to deshake video using ffmpeg-2.0? Is the following line still valid? [22:11] <DrSlony> ffmpeg -i INPUT.mp4 -an -vcodec libx264 -preset superfast -crf 18 -vf "deshake=-1:-1:-1:-1:16:16:0:8:125:0:" -threads 0 out.mp4 [22:15] <durandal11707> DrSlony: it should still work [22:16] <DrSlony> is there any better method? or better parameters? [22:19] <llogan> DrSlony: also see http://ffmpeg.org/ffmpeg-filters.html#vidstabtransform [22:19] <llogan> (ive never tried it) [22:23] <ubitux> you need a git version of vid.stab installed if you don't want any surprise [22:50] <DrSlony> I have a MJPEG video which I would like to transcode to h.264 and also cut off the first 3 seconds, is this the most simple way to do it?ffmpeg -i [22:50] <DrSlony> oops [22:51] <DrSlony> ffmpeg -i foo.avi -ss 00:00:03 -vcodec libx264 -preset slower -crf 18 -threads 0 out.mp4 [22:52] <llogan> that will work [22:52] <llogan> may need to add -pix_fmt yuv420p for "dumb" players; depending on your input and ffmpeg version [22:53] <DrSlony> does it matter where i put that? [22:53] <llogan> as an output option [22:53] <llogan> but the console output will confirm if ffmpeg is outputting to yuv420p or not [22:54] <llogan> but if you're not going to use any dumb players then don't worry about it [23:10] <DrSlony> What audio format and library is recommended when transcoding typical home video (stereo) or screencasts intended to be emailed to friends and played on typical computers? [23:18] <DrSlony> I used "-vcodec libx264" and it worked, but http://ffmpeg.org/ffmpeg.html shows "-c:v libx264". Which oldest version of ffmpeg does that apply to? [23:18] <llogan> either works [23:19] <llogan> h264 video and aac audio in mp4 container should be fine (as long as you include -pix_fmt yuv420p if needed) [23:20] <llogan> some devices may require "-profile:v baseline" [23:20] <DrSlony> should I use fdk or other? [23:20] <llogan> fdk [23:29] <DrSlony> thank you very much [00:00] --- Mon Oct 14 2013

1 0

ffmpeg-devel.log.20131012
by burek 13 Oct '13

13 Oct '13

[01:58] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:ce994a03f5e2: avformat/movenc: make AVStream easier to access [01:58] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:713dcdbfcbaa: avformat/movenc: set pretty compressor name for XDCAM [01:58] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:e4d45673ca02: avformat/movenc: set XDCAM codec tag correctly [12:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:8c0687abdf64: avfilter/vf_removelogo: use av_freep() for saftey [12:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:8c582d1b2213: avfilter/vf_removelogo: fix offset for accessing pixels above and below [12:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:eedfee12c608: avfilter/vf_removelogo: fix pixel pointer so it points where its intended [12:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:aeddc6e3a552: avfilter/lavfutils: fix memleak of avpacket [13:43] <durandal_1707> ubitux: i think decimate should not change pts at all, i would just leave that to fps/setpts/settb filters [14:02] <iive> it would just cause stutter, people would not know to insert setpts filter. [14:05] <durandal_1707> iive: decimate from libmpcodecs does not change pts [14:06] <iive> but this filter doesn't work like decimate from mpcodecs, iirc [14:07] <durandal_1707> from functionality point it drops random frames which decimate do too [14:07] <iive> nope [14:08] <iive> lavf decimate drops one of N frames, mp decimate drops only frames that are similar. [14:09] <durandal_1707> iive: and to what would you set pts? [14:10] <iive> lavf decimate is frame reduction filter, that tries to drop the least different frame. so it is natural it changes the pts accordingly. [14:10] <durandal_1707> but to what? [14:11] <iive> I think it is used as a second stage in inverse telecine filter. [14:11] <iive> or rather... ivtc chain. [14:12] <iive> but i'd better let ubitux explain it. [14:13] <durandal_1707> i didn't ask that.... [14:14] <cone-157> ffmpeg.git 03Martin Storsjö 07master:a52b5a5a07b0: riff: Add a mapping for VP6A [14:14] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:23c8a3353bd9: Merge remote-tracking branch 'qatar/master' [14:19] <cone-157> ffmpeg.git 03Lukasz Marek 07master:7b1640c4a6e9: avdevice/pulse_audio_enc: fix stream index [14:19] <cone-157> ffmpeg.git 03Lukasz Marek 07master:e1fb3143bb3a: avformat/ftp: fix possible deadlock [14:19] <cone-157> ffmpeg.git 03Lukasz Marek 07master:3a92ee595316: avformat/ftp: add log regarding passive mode failure [14:19] <cone-157> ffmpeg.git 03Michael Niedermayer 07master:8de021fabe3a: Merge remote-tracking branch 'lukaszmluki/master' [14:42] <xlinkz0> is ffserver no longer maintained? [14:43] Action: Compn looks at maintainers [14:45] <xlinkz0> what does Compn see? [14:47] <Compn> looks unmaintained, yep [14:48] <Compn> some people working on it slowly [14:48] <xlinkz0> thanks [14:53] <michaelni> xlinkz0, do you want to maintain ffserver or why do you ask ? (no ffserver sadly doesnt have a dedicated maintainer currently) [14:59] <xlinkz0> sadly I don't have experience in C server coding [15:00] <xlinkz0> and practically zero with libav so couldn't even if I wanted to [15:01] <xlinkz0> if I can't find anything open source that works for what my employer demands I think I'll make something with boost asio [15:28] <Compn> xlinkz0 : whats your employer need ? [15:28] <Compn> sounds like some kind of stream server [15:32] <xlinkz0> we need rtsp restreaming for a couple of cameras [15:33] <xlinkz0> that is, take rtsp stream from camera and resend it to potentially thousands of people [15:33] <Compn> ah [15:33] <Compn> not sure how many connections ffserver can handle [15:33] <Compn> there are opensource rtsp servers [15:33] <Compn> good luck [15:33] <xlinkz0> thanks [15:42] <michaelni> Compn, iam not aware of a fundamental connection limit in ffserver, it would be interresting if someone tested it with thousands of connections [15:43] <Compn> :) [15:43] <xlinkz0> i would've tested it but since i can't get it to work :\ [15:44] <Compn> try with ffmpeg first [15:44] <Compn> er nevermind [15:55] Action: michaelni wonders why noone wants to maintain ffserver [16:04] <durandal_1707> because code reviewers [16:06] <durandal_1707> kierank: what you disagree about (hd) colorbars? [16:06] <kierank> the same thing that was on the mailing list [16:06] <kierank> you can't convert them to correct 709 yuv [16:08] <durandal_1707> so what colorspace must be set? [16:10] <kierank> hd is 709 [16:10] <kierank> but you can't get them like that [16:10] <kierank> because swscale only supports 609 [16:10] <kierank> 601* [16:24] <michaelni> what exactly does sws not support ? [16:26] <durandal_1707> 709 colorspace [16:26] <michaelni> grep for 709 in libswscale/yuv2rgb.c, its there [16:28] <michaelni> same with libavfilter/vf_scale.c [16:54] <Compn> kierank : we want to see a failing command line [16:55] <Compn> then we can fix it or show how to do it [16:57] <kierank> michaelni: rgb -> yuv [16:57] <kierank> the colourbars are rgb [16:59] <durandal_1707> you mean colourbars produced by filter? [17:02] <michaelni> git log --grep rgb2yuv libswscale [17:02] <michaelni> seems to suggest that sws supports user specified yuv for rgb2yuv [17:02] <michaelni> yuv TYPE that is [17:06] <kierank> durandal_1707: yes [17:06] <kierank> so you need to calculate the filter coeffs your self [17:06] <kierank> ok [17:06] <durandal_1707> filter output is in yuv [17:11] <cone-157> ffmpeg.git 03Paul B Mahol 07master:1d8ce109e91d: avfilter/vf_separatefields: do not reset pts to 0 [17:11] <kierank> draw_bar is in rgb no? [17:13] <durandal_1707> kierank: do you have colors values in yuv(709 colorspace)? [17:16] <kierank> https://dl.dropboxusercontent.com/u/2701213/Specs/SMPTE/Recommended%20Pract… [17:41] <ubitux> durandal_1707: and what would that setpts filter be set to? [17:42] <ubitux> decimate is used to drop frames in order to reach a particular frame rate [17:47] <durandal_1707> ubitux: ok, than you fix async [17:51] <ubitux> well, i don't know how what's the correct behaviour [18:12] <kierank> btw Compn to answer your old question full range sucks because there's nowhere for filter overflow to go [18:12] <kierank> or underflow [18:32] <Compn> ok :) [18:32] Action: Compn hasnt a clue [18:32] Action: Compn afk [19:08] <durandal_1707> kierank: same colors/colorspace is used in smptebars? [19:08] <kierank> no, smptebars is 601 [19:08] <kierank> sd = 601, hd = 709 [19:19] <durandal_1707> but it use same numbers? [19:24] <kierank> no [19:32] <durandal_1707> kierank: so smptebars should use bt470bg? [19:32] <kierank> yes [19:33] <durandal_1707> do you have spec of smptebars that gives 8-bit numbers like for hd version? [19:39] <kierank> dunno [19:39] <kierank> there are many types of SD bars [19:44] <durandal_1707> those are from EG 1-1990 [19:44] <kierank> https://dl.dropboxusercontent.com/u/2701213/Specs/SMPTE/Engineering%20Guide… [19:45] <kierank> probably from 1990 it'll be in mV [20:49] <cone-656> ffmpeg.git 03Paul B Mahol 07master:cfc9a4c732af: avfilter/vsrc_testsrc: smpte(hd)bars: use yuv directly [21:00] <kierank> durandal_1707: thanks will try next week [21:01] <durandal_1707> i cant spot difference [21:01] <durandal_1707> actually there is difference, yellow in mpv looked more orange before [21:35] <durandal11707> huh: /* TODO: implement AV_CODEC_ID_RAWAUDIO */ [21:39] <wm4> it'd odd how raw audio has one decoder per format, while raw video has a single decoder [22:00] <durandal11707> it would be odd that wav demuxer returns raw audio [22:01] <durandal11707> i guess you could add virtual rawaudio decoder [22:01] <durandal11707> but how would you separate signed/unsigned/float? [22:02] <durandal11707> by adding extradata? [22:02] <durandal11707> this would just complicate -c copy ... [22:06] <wm4> dunno, do like video formats and add every audio format ever? [22:07] <wm4> or it could be yet another avcodeccontext field, similar to samplerate etc. [22:08] <durandal11707> i see no reason for it [22:11] <durandal11707> you could use ff_get_pcm_codec_id [22:33] <cone-656> ffmpeg.git 03Paul B Mahol 07master:fd54f700720a: avformat/avr: use ff_get_pcm_codec_id() [23:11] <smarter> michaelni: I don't think it makes sense to have a wrapper to openhevc in ffmpeg [23:12] <smarter> openhevc is used by the IETRE people to experiment on the decoder without having to care about the rest of libav, but this is irrelevant to most people [23:13] <smarter> everything of interest they do is ported to https://github.com/OpenHEVC/libav [23:13] <smarter> (s/IETRE/IETR/) [23:14] <smarter> to add to the confusion, the branch which will actually be merged into libav is http://git.khirnov.net/cgit.cgi/libav/log/?h=hevc_upstream [23:14] <smarter> it removes some features which are not ready or can't be accepted (intrinsics mostly) and should be kept in sync with https://github.com/OpenHEVC/libav [23:22] <smarter> and I don't think merging the libav hevc decoder now is a good idea since it's still in flux [23:24] <mraulet> I agree with smarter (you shouldn't make a wrapper to openhevc git) you should rather use libav [23:25] <michaelni> mraulet, libav is a fork of ffmpeg, we dont "use" libav [23:25] <michaelni> about the openhevc wrapper, ok understood [23:26] <mraulet> ok you can copy paste hevc related files then from openhevc then [23:27] <michaelni> yes possible or apply the patch i ported today libav [23:27] <michaelni> i just wonder whats the difference and [23:28] <mraulet> from? [23:28] <michaelni> betweem that patch and openhevc/hm10.0 [23:29] <michaelni> i assume that hm10.0 is where development happens ? [23:29] <mraulet> wpp and tiles --> parallel tools from hevc [23:30] <mraulet> They are not included in the patch [23:30] <mraulet> and as smarter said on the IRC (intrinsics are not included in the patch) [23:30] <smarter> michaelni: what libav branch/patch is your patch based on? [23:31] <michaelni> smarter, the patch that was posted today to libav [23:31] <michaelni> libav-devel [23:31] <mraulet> so my comments are relevant to this patch [23:32] <smarter> michaelni: okay, so it's a snapshot of http://git.khirnov.net/cgit.cgi/libav/log/?h=hevc_upstream [23:33] <iive> if I understand correctly, havc is not yet merged in libav, is it? [23:33] <michaelni> ok, so i should merge that patch and not copy files from some git (that is assume noone on the ML objects) [23:34] <smarter> iive: it isn't [23:34] <iive> and the patch in question is posted to libav-dev in order to use standalone havc codec, isn't it? [23:35] <smarter> iive: I'm not sure what you mean [23:36] <iive> i mean, openhavc is standalone codec, isn't it? [23:36] <ubitux> hevc* iive [23:36] <iive> my bad. [23:36] <smarter> ignore openhevc, it's a sandbox for people to experiment with :) [23:36] <mraulet> it does have what I need to decode hevc streams [23:37] <smarter> this patch: http://lists.libav.org/pipermail/libav-devel/2013-October/051938.html is a *Work In Progress* patch to add an hevc decoder to libavcodec [23:37] <michaelni> the patch does decode hevc, yes, i tested it of course before posting :) [23:38] <smarter> it does, it could also set your machine on fire, no guarantee. [23:38] <iive> this applies to any *gpl software [23:38] <michaelni> also may i add someone of you to our MAINTAINERs file for hevc* when its merged ? [23:38] <wm4> so, why not just merge the libav hevc patch as soon as it lands in their git head? [23:38] <smarter> wm4: that sounds reasonable [23:38] <iive> btw, I think that x264 also started as sandbox... [23:39] <wm4> also please, only one codec ID/define for hevc [23:39] <wm4> (now is the chance to fix) [23:39] <ubitux> too late i presume [23:39] <ubitux> (see patch 1) [23:39] <michaelni> wm4, too late [23:39] <michaelni> H265 is already i there [23:39] <wm4> then change it [23:39] <ubitux> it's duped [23:40] <ubitux> see patch 1 [23:40] <smarter> yes, you should have taken a look at the wip hevc patch before merging an hevc demuxer into ffmpeg... [23:40] <wm4> patch 1 just says "Some developers have choosen to use AV_CODEC_ID_HEVC, so we need that to be compatible" [23:40] <wm4> which has 0 info [23:40] <ubitux> what info? [23:40] <wm4> information [23:40] <ubitux> ... [23:40] <ubitux> information about what? [23:40] <smarter> wm4: the libav HEVC decoder has been using AV_CODEC_ID_HEVC since it's creation more than a year ago [23:40] <wm4> what developers, why can't it be changed, etc. [23:41] <wm4> smarter: I'm arguing for dropping AV_CODEC_ID_H265 [23:41] <smarter> wm4: I'm just providing context :) [23:41] <wm4> ok [23:41] <wm4> anyway, this will turn into a mess without doubt [23:41] <wm4> fix it now and reduce the pain for everyone [23:42] <wm4> well, could also try to convince Libav to use H265, but that'd be even harder [23:42] <ubitux> won't happen [23:42] <mraulet> HEVC is the general name [23:43] <iive> isn't h264 named AVC? [23:44] <mraulet> ... [23:44] <michaelni> about waiting for hevc to hit libav, that doesnt seem reasonable honestly. The patch is there, it works, it was trivial to port and i assume there are user who would want to use it [23:45] <ubitux> any idea what they are waiting for? [23:45] <mraulet> no [23:45] <BBB> I bet you it has to be reindented 20 times [23:45] <smarter> ubitux: http://lists.libav.org/pipermail/libav-devel/2013-October/051938.html lists some of these things [23:45] <wm4> the latest patch iteration (re?)added multithreading [23:45] <BBB> for optimal diego performanc [23:45] <BBB> hi smarter [23:45] <smarter> security is also an issue [23:45] <smarter> hi BBB :) [23:46] <BBB> still liking it over there? [23:46] <smarter> yep! [23:46] <BBB> good [23:46] <ubitux> smarter: ok, looks like a few things might be important [23:47] <michaelni> its marked as experimental in my patchset so it wont be used without user interaction thus security should not be an issue [23:47] <BBB> ubitux: how's 4x4idct going? [23:47] <ubitux> BBB: slowly progressing, i worked a little on it today [23:47] <mraulet> michaelni, you should add this to read ts [23:47] <mraulet> https://github.com/OpenHEVC/libav/commit/925ee44364a7bce58e2ac5bac91077ce0a… [23:47] <BBB> cool [23:47] <iive> my theory is that libav want to keep havc out of ffmpeg and the only way to do that is to not merge it themselves. ;) [23:48] <ubitux> BBB: i'll give you a report tomorrow at the end of the day [23:48] <smarter> HEVC-In-MKV is also not standardized yet, merging now would impose a de facto standard [23:48] <ubitux> iive: why do you insist on writing havc? :P [23:48] <wm4> didn't the mkv guys come to a conclusion? [23:48] <iive> did I said hevc is bad name? [23:48] <smarter> wm4: I'm not sure. JEEBsv ^ ? [23:49] <iive> i confuse it with avc... that's why... [23:49] <mraulet> it works on divx mkv files and others [23:49] <michaelni> mraulet, thx, merged to my local hevc-wip branch [23:49] <wm4> http://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.ht… [23:49] <michaelni> cant push to master as theres no HEVC codec id yet [23:50] <llogan> opus in mkv didn't seem to make any issues before, AFAIK&IIRC (what is the situation on that anyway?) [23:50] <michaelni> smarter, about mkv, please reply to the patch on ffmpeg-devel [23:50] <michaelni> with that so people know [23:51] <j-b> DivX is not using the standard mkv [23:51] <mraulet> j-b: ok [23:52] <mraulet> at least the current implementation works for ts and mp4 [23:52] <mraulet> I can confirm it on all samples I have [23:52] <smarter> michaelni: I'm not really qualified to talk about mkv [23:53] <j-b> mraulet: mp4 is not standardised, AFAIK [23:53] <mraulet> hmmm you can consider it as standardized [23:53] <j-b> and "almost" is not a standard [23:53] <mraulet> the latest draft does not have any changes [23:53] <j-b> _draft_ [23:54] <mraulet> then you can postpone all :-) [23:54] <mraulet> ^^ [23:54] <michaelni> btw, who cares if a demuxer supports something that is not standarized ? [23:54] <j-b> noone [23:54] <j-b> well, one day, MP4 people will stop being a bunch of suckers... [23:55] <michaelni> for a muxer yes, sure we dont want to create invalid files but for a demuxer that doenst make sense [23:55] <j-b> but that is not for now [23:55] <j-b> michaelni: you have to support the current mp4 one and the DivX [23:55] <j-b> but they are not the final standards [23:56] <michaelni> we should support everything that exists on the demuxer & decoder side ideally [23:56] <kierank> 22:45:31 <"BBB> for optimal diego performance -> lol [23:59] <michaelni> wm4, about the codec id, what is the problem with 2? (yes i prefer just 1 too but i cant add "now" the one that libav will be adding at some point in the future beause i dont know the future) [23:59] <j-b> michaelni: but then, why keep the decoder as experimental? [23:59] <wm4> michaelni: one more shitty ifdef for libav vs. ffmpeg [00:00] --- Sun Oct 13 2013

1 0

ffmpeg.log.20131012
by burek 13 Oct '13

13 Oct '13

[00:18] <DelphiWorld> hey guys, i'm getting this error while ffprobing a rtmp stream: HandShake: client signature does not match! [00:18] <DelphiWorld> any clue? [00:18] <DelphiWorld> this is crtmpserver [01:31] <alesan> how do I specify the bandwidth with avconv? for the video stream?>> [01:45] <sacarasc> alesan: #libav is avconv's channel. [01:46] <alesan> sacarasc, so what is discussed here? I thought it was only an alias [01:46] <sacarasc> No, libav is a fork of ffmpeg. [01:46] <sacarasc> They are two projects. [01:52] <alesan> well my first question was about ffmpeg [01:52] <alesan> then I saw bubuntu uses avconv so I asked this way [02:23] <blast_hardcheese> Am I correct in my assessment that ffmpeg will not preserve nonstandard metadata keys from my iPhone when reencoding movies? [02:24] <blast_hardcheese> I can use -f ffmetadata to look at the metadata, but beyond that it seems ffmpeg doesn't care about it. [02:35] <blast_hardcheese> It might be fun to write something to re-insert the metadata afterwards, but it's probably something ffmpeg/libav should just do [04:28] <xingchao_> hi guys, i met an issue on video mosaic, the details is here:http://ffmpeg.org/pipermail/ffmpeg-user/2013-October/017937.html [04:28] <xingchao_> does anyone could provide some guide? [04:29] <xingchao_> the issues is from playing some rmvb video with ffplay 0.8 [04:29] <xingchao_> if disable audio, the mosaic disappear [04:29] <xingchao_> it's really weird [04:31] <llogan> use a newer ffplay [04:31] <llogan> and provide a sample in your ffmpeg-user message thread [04:32] <llogan> (sample input file) [04:34] <xingchao_> @llogan: yes, the newer ffplay could fix the issue [04:34] <llogan> that's probably the answer you'll get on the mailing list [04:34] <xingchao_> the test sample is too big, i cannot upload it [04:35] <xingchao_> newer ffplay(1.13) could play well, but ffplay 0.8 not. [04:35] <llogan> if it has been fixed in a newer release (or git head) then is may be possible to backport to an older release if you require an older release (but usage of newer is encouraged) [04:36] <xingchao_> but based on ffmpleg 1.13, i used android's player, the mosaic issue still exist. that's why i need find out the rootcause [04:36] <llogan> you can try git-bisect, but i'm not sure how time consuming that would be to test on android [04:39] <xingchao_> yes, thanks. [04:39] <xingchao_> when disable audio, the mosaic disappear [04:39] <xingchao_> @llogan, do you know why this happen? [04:40] <llogan> i don't know the cause, but from your information it appears to have been fixed. so either use newer ffplay or find the responsible commit(s) [04:40] <llogan> is the issue reproducable on desktop ffplay 0.8? [04:41] <llogan> maybe a short sample that shows the issue can be made with dd as shown in http://ffmpeg.org/bugreports.html [04:42] <xingchao_> okay [04:45] <llogan> i didn't know RMVB was actually used by anyone [04:45] <xingchao_> done, i will upload the test files [04:45] <llogan> is RMVB popular in china? i think i heard that it may be. [04:46] <xingchao_> yes, a lot of video files are rmvb [04:49] <llogan> i have to go now, but maybe someone will reply to your mailing list thread later [04:50] <xingchao_> thanks [05:32] <xingchao_> i have uploaded the test sample to ftp [08:16] <MorehouseJ09> is this the correct place to discuss libavformat libraries that ffmpeg uses? [08:16] <relaxed> MorehouseJ09: yes [08:19] <MorehouseJ09> relaxed: I'm having trouble applying a bitstream filter. Ever played with those before? [08:23] <MorehouseJ09> when I call av_bitstream_filter_filter() with the correct args, I'm getting a zero return [08:23] <MorehouseJ09> while trying to apply the h264_mp4toannexb filter [14:00] <DelphiWorld> Hi guys [14:00] <DelphiWorld> how to add two audio stream to a video so user can select the sound input? [14:01] <Mavrik> look up "-map" in the documentation [14:15] <xlinkz0> I have this ffserver setup : http://codepad.org/kQVApCq2 [14:16] <xlinkz0> why can't I stream from the ffserver with ffmpeg? [14:21] <Mavrik> xlinkz0, um, you're defining RTP output not RTSP [14:21] <Mavrik> and no port [14:23] <xlinkz0> hmm ok [14:23] <xlinkz0> just there's an example that uses Format rtp [14:23] <xlinkz0> and says the stream url is rtsp://.. [14:24] <Mavrik> hmm, that sounds wierd tbh :) [14:24] <DelphiWorld> thank Mavrik [14:31] <xlinkz0> Mavrik: changed the conf file to http://codepad.org/wkqbBihD , still can't get anything :( [14:32] <xlinkz0> the sample ffserver.conf doesn't say anything about stream ports [14:32] <xlinkz0> http://ffmpeg.org/sample.html [14:39] <DelphiWorld> xlinkz0: what you're trying to do? [14:40] <xlinkz0> i'm trying to restream rtsp [14:40] <DelphiWorld> xtrfrom rtsp to what? [14:40] <DelphiWorld> xlinkz0: from rtsp to what? [14:41] <xlinkz0> DelphiWorld: to rtsp [14:41] <DelphiWorld> xlinkz0: i honestly dont recomand ffserver anymore, i heare is not longer maintained [14:41] <DelphiWorld> xlinkz0: try out ffmpeg with crtmpserver [14:41] <xlinkz0> tried crtmpserver in the past, it didn't work [14:42] <xlinkz0> couldn't stream from it with ffmpeg nor rtmpdump [14:42] <DelphiWorld> xlinkz0: use svn, work for me [14:43] <xlinkz0> svn? [14:58] <DelphiWorld> xlinkz0: checkout crtmpserver from svn, dont install it using your system package manager [15:00] <xlinkz0> hmm ok [17:46] <jure> heya [17:47] <jure> is there a way to normalize audio to a specified amplitude with ffmpeg? [18:34] <fahadash> What does this error mean "[mov,mp4,m4a,3gp,3g2,mj2 @ 000000000273a5c0] moov atom not found" [18:34] <Katharsis> hi [18:34] <Katharsis> how to remove audio delay in my screencast? i'm working on linux (debian) [18:34] <Katharsis> async/vsync doesn't work [19:00] <Katharsis> problem fix - i used async + vsync togheter [21:40] <jure> I'd like ffmpeg to take in a quad-channel wav and output a normalized stereo wav [21:40] <jure> ffmpeg -channel_layout quad -i input.wav <some normalize filter?> -ac 2 out.wav [22:04] <dowdle> Ok, when I give -vf scale=xxx:-1 it says it is going to scale as desired in the program output but the resulting video is the original size. Any idea why it isn't working? [22:17] <dowdle> ffmpeg version 2.0.2 [22:17] <dowdle> Converting mp4 to webm [22:17] <dowdle> Output shows: Stream #0:0(und): Video: vp8 (libvpx), yuv420p, 640x438 [SAR 949:800 DAR 26:15] [22:18] <dowdle> Actual video produced is the original size of 758x438 [22:18] <jure> that's not scaled [22:19] <jure> shouldn't it be 640x370 then? [22:19] <dowdle> jure: Yes, calculating it by hand and specifying the y makes it work. [22:20] <dowdle> jure: So I guess the -1 just isn't scaling it? [22:20] <jure> it should be afaik [22:21] <dowdle> Input stream is: Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 702x480 [22:21] <jure> if the input is 702x480, how can you claim the original size is 758x438 [22:21] <dowdle> jure: Ok. Since I can manually fix it I'm happy. The -1 has worked for me so much I didn't think it was doing it wrong. Now I know. [22:22] <dowdle> jure: IN a player, that's the playback size. [22:22] <dowdle> jure: But in any case, my statement was incorrect... so use the updated info provided by the input stream output. [22:23] <jure> could it be that the player's scaling settings are set that way? [22:24] <jure> you have to pay attention to the sar and dar settings as well [22:24] <dowdle> jure: If I'm going to have to manually set the sar and dar values I might as well compute the y. :) [22:26] <dowdle> jure: Or maybe I misunderstood you. [22:27] <dowdle> jure: In any event, for whatever reason the -vf scale=640:-1 isn't scaling it for me but if I comput the y and put in -vf scale=640:370 then it works. [22:27] <dowdle> jure: Is there any other setting you are aware of that would make the -1 work? [22:28] <jure> what about -vf scale=640,-1 ? [22:29] <dowdle> jure: syntax error on the , [22:39] <ubitux> i'm assuming you have multiple -vf or something like this [22:39] <ubitux> or -c copy maybe [22:40] <dowdle> ubitux: Ok. I"ll fpaste it. Just a minute [22:43] <dowdle> I guess it is scaling the actual video... but playback adjusts it. [22:43] <dowdle> VO: [null] 640x438 => 758x438 Planar YV12 [22:43] <dowdle> That's what mplayer -identify says. [22:44] <ubitux> that's because of aspect ratio [22:44] <ubitux> you can use sar constants in scale filter for your expressions [22:44] <dowdle> http://fpaste.org/46380/ [22:44] <dowdle> ubitux: Could you give me an example? Just copy what is in the input stream? [22:47] <ubitux> look at http://ffmpeg.org/ffmpeg-filters.html#scale [22:48] <ubitux> maybe scale=640/sar:-1 or sth like that [22:49] <dowdle> ubitux: I'll try that. [22:49] <ubitux> it's likely wrong [22:50] <dowdle> ubitux: I looked at those docs but I wasn't groking it well enough for my question. :) [22:50] <ubitux> but use your brain, you should be able to figure it out [22:50] <ubitux> mine is dead [22:51] <dowdle> ubitux: Your example worked. [22:51] <ubitux> ah? [22:51] <ubitux> i guess it was a lucky guess [22:55] <dowdle> ubitux: Thanks for your help. I guess when input videos have odd stretched aspects, obviously scale needs more info to adjust. [22:56] <dowdle> So how is vp9 support coming? :) It seems that google is still in the process of optimizing their reference implimentation. It seems a lot of compression savings can be gained with it but it takes a lot more computational resources. [22:56] <ubitux> there is a native decoder in ffmpeg [22:57] <ubitux> and a libvpx wrapper if you need the official implementation [22:57] <dowdle> ubitux: I've not used ffmpeg (directly) for playback. That's a different command? I mainly use gnome-mplayer and vlc... and am ignorant about ffmpeg playback. [22:58] <ubitux> ./ffplay [22:59] <ubitux> it's not present in 2.x releases though, see git/master [23:00] <dowdle> ubitux: So it is only in the devel version? I've not compiled ffmpeg from source before. [23:00] <ubitux> no release includes the vp9 decoder yet, so yes you need to build it yourself [23:01] <ubitux> it's still no optimized btw, we are working on it [23:01] <ubitux> i mean, it's good enough for most playback on a recent machine, but don't expect to play 1080p smoothly everywher [23:01] <ubitux> +e [23:02] <dowdle> ubitux: I periodically go to the webm website's vp9 page and it has a direct link to an ffmpeg search for vp9 stuff... and yeah, I see that. No one else has it either. The stock tool they provide requires the original video to be in some weird format... and I haven't figured that out yet. [23:02] <dowdle> http://www.webmproject.org/vp9/ (link at bottom) [23:03] <dowdle> http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=libvpx [23:03] <dowdle> Or more properly libvpx. [23:03] <ubitux> libvpx is all about the wrapper [23:03] <ubitux> see libavcodec/vp9*.c [23:03] <dowdle> Given the frequency of vp9 updates and the fact that they are still working on optimizations, I would assume everyone is waiting for them to get it (closer to) finalized before they try to support it. [23:04] <ubitux> bitstream is finalized, they won't change it anymore [23:04] <dowdle> ubitux: I think I had it all properly setup with their tools once it took a long time for 1 frame. [23:05] <MorehouseJ09> should avformatcontext have a video_codec field? [23:05] <ubitux> dowdle: encoding is still extremely slow with libvpx, and last time i tried it wasn't multithreaded so.. [23:06] <ubitux> MorehouseJ09: a format can have multiple video streams, and thus multiple video codecs [23:06] <dowdle> ubitux: And they are pretty much requiring two pass encoding if I understand correctly. [23:06] <ubitux> probably, but don't expect a native vp9 encoder in ffmpeg soon [23:07] <ubitux> a decent encoding for such codec is really hard, and it is often isolated in a dedicated project (see x264 for h264 encoding for instance) [23:07] <MorehouseJ09> ubitux: definitely. So do I need to manually add that into the output format context? [23:07] <MorehouseJ09> ubitux: or is it automatically created when I do the avformat_alloc_output_context2() call? [23:07] <dowdle> ubitux: Any opinion about vp9 vs x265? I prefer patent unencumbered codecs. [23:07] <ubitux> dowdle: this is the native decoder in ffmpeg: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9.c;hb=HEAD and wrapper around libvpx for encoding and decoding is in the libvpx*.c files of that same directory [23:09] <ubitux> dowdle: http://forum.doom9.org/showthread.php?t=167081 http://forum.doom9.org/showthread.php?t=168947 make your own opinion :p [23:10] <ubitux> MorehouseJ09: i'm not familiar with encoding, check the examples or the appropriate mailing list, or existing working code [23:11] <MorehouseJ09> ubitux: thanks [00:00] --- Sun Oct 13 2013

1 0

ffmpeg-devel.log.20131011
by burek 12 Oct '13

12 Oct '13

[01:13] <cone-389> ffmpeg.git 03Michael Niedermayer 07master:a72bf5fd1188: ffmpeg: set the source_index for trivial filter graphs [03:29] <BBB> llogan: yes, need exactly sse or sse2 only, not pre-sse or post-sse2 [08:28] <cone-717> ffmpeg.git 03Maxim Poliakovski 07master:be7641504737: atrac3: Remove unused gain compensation tables [08:28] <cone-717> ffmpeg.git 03Maxim Poliakovski 07master:ed796fba761f: atrac3: Better name for IMDCT window initialization [08:28] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:964f9ca22994: Merge commit 'ed796fba761f4794bec7735d467c1b2c8e1858fe' [09:20] <cone-717> ffmpeg.git 03Tim Walker 07master:5f5ada3dbf97: shorten: Fix out-of-array read [09:21] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:bb8ce36dc285: Merge commit '5f5ada3dbf97e306a74250ba8dcf8619ad59b020' [09:28] <cone-717> ffmpeg.git 03Matthieu Bouron 07master:054454c63a2e: mxf: Add jpeg2000 codec to intra only codecs [09:28] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:08b22c0ea536: Merge remote-tracking branch 'qatar/master' [09:29] <michaelni> mateo`, do you want to review "1007 18:22 To FFmpeg devel (1.2K) [09:30] <michaelni> or should i just apply them ? [09:30] <michaelni> they are of course tested ... [10:24] <cone-717> ffmpeg.git 03Carl Eugen Hoyos 07master:d24da748c308: Add H.264 fourcc GAVC for GeoVision cameras. [11:38] <durandal_1707> why frame_count starts from 0? [11:38] <durandal_1707> bah [12:04] <TheFluff_> what are you, a lua programmer? [12:09] <durandal_1707> lua programmers counts from 1? [12:09] <ubitux> yes [12:10] <ubitux> array indexing starts at 1 iirc [12:11] <Daemon404> yep. [12:12] <durandal_1707> i am ex-lua programmer so i think lavfi should start counting from 1 [12:15] <Daemon404> durandal_1707, vf_lua.c time?\ [12:15] <durandal_1707> nope i'm using AVExpr and exposing link->frame_count via it [12:16] <Daemon404> because everybody loves typing several kb of shit on the cmd line [12:18] <durandal_1707> nobody comes with patch that gives alternative [12:21] <durandal_1707> and what would vf_lua.c do if you can't call filter within filter [12:21] <durandal_1707> of if filter can't control filtergraph [12:22] <durandal_1707> and i guess recreating filtergraph resets all frame counts thus you are damned [13:07] <ubitux> Daemon404: you can write the filtergraph in a file and you know it [13:07] <ubitux> it's just more convenient on the cli 95% of the time [13:08] <durandal_1707> what filtergraph in while? [13:08] <ubitux> parse error [13:09] <durandal_1707> can you give example of such filtergraph in file? [13:10] <ubitux> i was refering to -filter_script and -filter_complex_script durandal_1707 [13:11] <durandal_1707> i use that, and that is just command line [13:11] <ubitux> yeah but i was talking to Daemon404 [13:12] <durandal_1707> ok let me paraphrase what he said: because everybody loves typing several kb of shit in file [13:13] <ubitux> maybe i misunderstood everything :) [13:22] <Daemon404> [12:07] <@ubitux> Daemon404: you can write the filtergraph in a file and you know it [13:22] <Daemon404> i actuall did not. [15:26] <cone-717> ffmpeg.git 03Michael Niedermayer 07release/1.1:2a7bdbf67efb: ffserver: strip odd chars from html error messages before sending them back [15:26] <cone-717> ffmpeg.git 03Reinhard Tartler 07release/1.1:58287d3b10a2: update Changelog [15:26] <cone-717> ffmpeg.git 03Reinhard Tartler 07release/1.1:bb81b2b2e06a: Fix top-level description [15:27] <cone-717> ffmpeg.git 03Michael Niedermayer 07release/1.1:835bc39b2608: Merge remote-tracking branch 'qatar/release/9' into release/1.1 [15:27] <cone-717> ffmpeg.git 03Michael Niedermayer 07release/1.1:e31e66948d0a: Delete changelog [15:35] <cone-717> ffmpeg.git 03Timothy Gu 07release/1.1:4ad0330b3dd1: doc/encoders: reformat libmp3lame doc [15:35] <cone-717> ffmpeg.git 03Timothy Gu 07release/1.1:ed2c15eadc3b: doc/encoders: reformat and add some clarification in libtwolame doc [15:35] <cone-717> ffmpeg.git 03Timothy Gu 07release/1.1:852ee0e0ad26: doc/encoders: Remove options that were not there when branch was cut from master [15:35] <cone-717> ffmpeg.git 03Timothy Gu 07release/1.1:3eee21406a9f: doc/encoders: improve libvo-aacenc doc [15:35] <cone-717> ffmpeg.git 03Timothy Gu 07release/1.1:c42fd4c6eee4: doc/ffmpeg-formats: Add documentation for 2 parameters that have been missing [15:35] <cone-717> ffmpeg.git 03Timothy Gu 07release/1.1:a4acb5b90038: doc/encoders: add doc for AAC encoder [15:35] <cone-717> ffmpeg.git 03Michael Niedermayer 07release/1.1:eb3330b050ba: Merge remote-tracking branch 'TimothyGu/release/1.1' into release/1.1 [15:44] <cone-717> ffmpeg.git 03Michael Niedermayer 07release/1.1:f0bb0aaaa7a8: avcodec/ffv1enc: update buffer check for 16bps [15:44] <cone-717> ffmpeg.git 03Michael Niedermayer 07release/1.1:0efb4ff86c20: avcodec/parser: reset indexes on realloc failure [15:44] <cone-717> ffmpeg.git 03Michael Niedermayer 07release/1.1:4bc7c1ba8e9a: update for 1.1.7 [16:24] <cone-717> ffmpeg.git 03Carl Eugen Hoyos 07master:a12ab37d1f7a: lavf/riff.c: Fix GeoVision H.264 fourcc. [16:41] <cone-717> ffmpeg.git 03Stefano Sabatini 07master:f02bab6d0978: doc/filters/scale: do not explicitly state the default swscale flags value [16:54] <durandal_1707> if nobody wants to review telecine patches its time now (an no reviews like 'ok if tested' are not reviews) [16:55] <durandal_1707> i will also make big changes to MA* file [16:55] <cone-717> ffmpeg.git 03Luca Barbato 07master:c0de9a23c708: prores: Reject negative run and level values [16:55] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:e7fa0417b31a: Merge remote-tracking branch 'qatar/master' [16:56] <durandal_1707> michaelni: are you gonna push qp? [17:11] <cone-717> ffmpeg.git 03Michael Niedermayer 07master:dfb89fee2d2b: doc/codecs: document skip_alpha [17:48] <durandal_1707> ubitux: why is decimate changing pts when it does not change time_base ? [17:48] <ubitux> maybe it's broken [17:49] <durandal_1707> it should change time_base? [17:49] <durandal_1707> well it could... but there is no need .... [17:50] <durandal_1707> also the fps thing seems fishy, filter just eats random frames...., why care about fps [20:06] <cone-717> ffmpeg.git 03Timothy Gu 07master:a55e813e5394: doc/codecs: Cosmetics in the flags2 description [20:06] <cone-717> ffmpeg.git 03Timothy Gu 07master:db4a677433a6: doc/codecs: Remove no longer existing options [20:06] <cone-717> ffmpeg.git 03Timothy Gu 07master:1fdae1017c5b: doc/codecs: Add ignorecrop [20:06] <cone-717> ffmpeg.git 03Timothy Gu 07master:024bf3a1c2d3: doc/codecs: Add missing mpeg2 aac profiles [20:10] <ubitux> durandal_1707: maybe we should just divide the pts by the same frame count divider.. [20:10] <ubitux> in decimate [20:11] <durandal_1707> why? [20:11] <durandal_1707> test with audio where first pts != 0 [20:11] <durandal_1707> and where pts are not increasing one by one [20:12] <durandal_1707> it probably should be rescaled once time_base is changed too [20:12] <durandal_1707> but i do thing its not required [20:12] <durandal_1707> *think [20:12] <ubitux> mmh [20:13] <durandal_1707> well if you want each frame have same duration than yes, you need to change time_base too [20:13] <durandal_1707> and rescaled every pts [20:15] <ubitux> but where is the pts adjustement supposed to happen? [20:18] <durandal_1707> pts are a, b, c, d, e; when you drop for example c, you rescale all other frames to take same timeframe, which current code does, but it resets pts to 0 thus causes async [20:22] <ubitux> yes i understand the problem with the current solution [20:22] <ubitux> but i don't understand how you address the issue by simply dropping the pts negociation [20:26] <durandal_1707> i don't :) [20:27] <durandal_1707> i could pick min and max pts between frames and interpolate using them... [20:27] <ubitux> durandal_1707: then maybe try frame->pts *= outlink->frame_rate [20:28] <ubitux> ah er [20:28] <ubitux> well, pick the correct multiplie [20:28] <ubitux> r [20:40] <ubitux> frame->pts = frame->pts * (dm->cycle - 1) / dm->cycle; something like this probably [20:53] <durandal_1707> that cant work [20:55] <cone-717> ffmpeg.git 03Timothy Gu 07fatal: ambiguous argument 'refs/tags/n1.1.7': unknown revision or path not in the working tree. [20:55] <cone-717> Use '--' to separate paths from revisions [20:55] <cone-717> refs/tags/n1.1.7:HEAD: doc/codecs: Add missing mpeg2 aac profiles [22:30] <durandal11707> michaelni: can this be solved at all? [22:30] <durandal11707> i see vf_fps code doesn't do anything similar [00:00] --- Sat Oct 12 2013

1 0

ffmpeg.log.20131011
by burek 12 Oct '13

12 Oct '13

[03:09] <Zarxrax> how can i reencode a video using ffmpeg, and take softsubtitles and hardcode them into the new encode [03:09] <Zarxrax> im trying to avoid the extra step of first extracting the subtitle stream [03:27] <mark4o> Zarxrax: ffmpeg -i in.mp4 -vf subtitles=sub.srt out.mp4 [03:33] <Samus_Aran> is there some way to limit the max bitrate when using crf encoding? I tried -maxrate 15m, but it still went up to 80Mbps [03:33] <Samus_Aran> or is the only way to raise the crf? [03:34] <mark4o> Samus_Aran: you need both -maxrate and -bufsize [03:38] <Zarxrax> mark4o: im referring to using the subtitle file that is already present in the video file. is that the way to do it? [03:41] <mark4o> Zarxrax: oh sorry, you want to avoid extracting them to a file; hmm, I don't know that there is any way to do that [03:42] <Zarxrax> well, i guess i can extract them then [03:42] <Zarxrax> im just really lazy [03:44] <Samus_Aran> mark4o: how do I choose the buffer size? [03:45] <Samus_Aran> I'm encoding PNG animation frames, 1080p/30 [03:48] <mark4o> Samus_Aran: -maxrate is the maximum rate over some period, specified by -bufsize. Wherever you got the -maxrate you are using should also specify a size or duration. [03:49] <Samus_Aran> I just don't want the maximum bitrate to spike beyond 15Mbps, as my laptop is slow [03:52] <mark4o> Samus_Aran: try -bufsize 4M [04:09] <Samus_Aran> mark4o: will try, thanks. [04:18] <ExceptionlCatch> hello, i'm new and still finding out about max_analyze_duration reached [04:18] <ExceptionlCatch> it happens when playing the file in ffplay and i can't tell whether its benign or a problem [04:19] <ExceptionlCatch> i tried convertnig the wav to an mp3 but playing the mp3 still has that message [05:32] <Zeranoe> Does ffmpeg's http protocol require a server to stream? I know VLC offers a HTTP streaming option, does that run a server too? [13:36] <burek> can anyone suggest what could be wrong with this: http://pastebin.com/aVVzyYzU [13:38] <durandal_1707> why is - used for -i ? [13:53] <ubitux> burek: -f h264 ? [13:53] <ubitux> durandal_1707: stdin [13:53] <ubitux> ah wait ok [13:53] <ubitux> burek: -r as output option i guess [14:02] <burek> i guess -r specifies the input frame rate [14:02] <burek> since it's a stdin [14:03] <burek> wait http://ffmpeg.gusari.org/viewtopic.php?f=16&t=1100&p=2727 [14:03] <burek> that's the original post [14:03] <burek> there is an example without -r at all [14:03] <burek> experiencing the same issue [14:20] <burek> I can't even understand what does this guy talk about http://ffmpeg.gusari.org/viewtopic.php?f=16&t=1092 :( [14:43] <ubitux> burek: i see -r 25 as input option as well here [14:43] <ubitux> i think it's supposed to be set as output optoin [14:43] <ubitux> (or not at all?) [15:30] <burek> ubitux, in his 1st cmd line, there was no -r for input [15:30] <burek> pi@raspberrypi ~/ffmpeg $ raspivid -vf -t 0 -w 450 -h 200 -fps 25 -b 2000000 -o - | ffmpeg -i - -c:v libx264 -vcodec copy -f h264 -loglevel debug test.mp4 [15:30] <burek> but he still got "[h264 demuxer @ 0x31be320] Unable to parse option value "25" as video rate" [15:47] <ubitux> burek: the error wasn't the same afaict [16:20] <fling> I have a bunch of videos from a security cam. [16:20] <fling> I want to only keep parts of video with movement [16:28] <durandal_1707> fling: so you need some kind of movement detection filter? [16:29] <fling> durandal_1707: yes ;P [16:29] <durandal_1707> there is no such thing (yet) in libavfilter [16:29] <fling> durandal_1707: I may convert everything to images and just drop similar frames [16:29] <fling> durandal_1707: but I want to keep sound [16:41] <willvarfar> can ffmpeg transcode a video from an mp4 file passed over stdin before the moov is received? [16:41] <durandal_1707> no [16:42] <willvarfar> what general approaches are there to consuming mp4 that hasn't yet got the moov? [16:43] <ubitux> chunked mp4 [16:43] <ubitux> ah, as input [16:43] <ubitux> you can't [16:44] <willvarfar> hmm tricky then. I can get an android phone to record h264 in mp4 and send it straight to my server live, [16:45] <willvarfar> but on the server I can't do anything with it until its stopped anyway, making it not live after all. [16:46] <ubitux> send chunked mp4 [16:46] <ubitux> or just use another container [16:48] <willvarfar> yes on android the pick seems limited [16:53] <willvarfar> thx. [18:17] <diroots> hi all [19:21] <xlinkz0> can i make ffserver stream copy from feed to stream? [19:25] <ezekiel> I'm not entirely sure what you're asking, but I'll guess - ffserver will try to do as little transcoding as possible, if I recall correctly [19:25] <ezekiel> so if your OUTPUT parameters are similar/same to your input feed, then it's not going to transcode [19:25] <xlinkz0> i don't want it to transcode at all [19:26] <xlinkz0> ok [22:16] <Mista_D> Trying to read a redirected STD and ERR out from a file. tail -f is working, but tail with grep and cut are not. [23:48] <alesan> hi I have some full HD movies 60fps that I would like to reduce to 1280x710 and 30fps, keeping the audio and if possible other parameters similar [23:49] <alesan> so far I've found ffmpeg -i $i -vf scale=1280:-1 small/$i [00:00] --- Sat Oct 12 2013

1 0