Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2014

1 participants
56 discussions

ffmpeg-devel.log.20140227
by burek 28 Feb '14

28 Feb '14

[00:32] <cone-376> ffmpeg.git 03Diego Biurrun 07master:a63ac1106d2e: build: Do not redundantly specifiy H.263-related object files for MSMPEG4v* [00:32] <cone-376> ffmpeg.git 03Michael Niedermayer 07master:c4c5351f0857: Merge remote-tracking branch 'qatar/master' [03:32] <cone-376> ffmpeg.git 03Michael Niedermayer 07master:b5005def8a8f: avcodec/h264: avoid using lost frames as references [05:06] <Zeranoe> Looks like there might be a bug in 2.1.4: http://paste.debian.net/84274/ [05:10] <Zeranoe> Looks like it's vidstab related [05:16] <Zeranoe> Fixed, I just saw https://trac.ffmpeg.org/ticket/3296 [08:08] <cone-763> ffmpeg.git 03Michael Niedermayer 07master:64bb64f704f7: avcodec/h264: fix droped frame handling also for threads > 1 [09:35] <ubitux> OperationalError: database is locked [09:35] <ubitux> *RAGE* [10:48] <cone-763> ffmpeg.git 03Anton Khirnov 07master:291e49d4e7db: af_compand: add a dependency on strtok_r [10:48] <cone-763> ffmpeg.git 03Michael Niedermayer 07master:33a2b45c2e18: Merge remote-tracking branch 'qatar/master' [11:56] <cone-763> ffmpeg.git 03Michael Niedermayer 07master:649686d89bfa: avcodec/h264_refs: remove lost frames instead of disfavoring them [11:57] <ubitux> ah, trac repaired [11:57] <nevcairiel> sounds more like an issue that fixes itself briefly and then re-occurs a day later [11:58] <ubitux> :( [12:06] <b_jonas> (stupid bug came back) [14:14] <ubitux> michaelni: i think that's better if we keep the av_strtok code [14:14] <ubitux> libav is replacing the strtok_r with av_get_token but i don't think that's a good idea to follow that [14:16] <ubitux> also, about the incoming frei0r crash fix, iirc i fixed that problem already [14:16] <ubitux> not sure if it's done the same, but you probably want to be careful about it when merging [14:18] <ubitux> it seems libav is going to not tolerate unset parameters [14:18] <ubitux> if you prefer that version, you could revert e85ea7d387a34328c44a2e06c7098ffca341e310 [14:18] <ubitux> but i think it's ok not to have mandatory parameters [14:19] <ubitux> iirc this crash was actually a regression, and it was tolerated originally, but i might be wrong [14:22] <funman> http://pastebin.com/39c1qpeb (backtrace from vlc) [14:28] <ubitux> funman: can we reproduce with ffmpeg? [14:30] <ubitux> funman: like maybe ffmpeg -f alsa -i hw:0,0 -ar 44100 -ac 1 -b:a 128k out.mp3 or something? [15:00] <plepere> ubitux : in VP9, the 2D 8-tap filter is only done by doing 2 successive 1D filters. is it not possible to blend them in a single function / loop ? [15:02] <ubitux> plepere: BBB wrote those filters so i don't know [15:02] <plepere> ok thanks. :) [15:03] <plepere> I'll try doing it here. :) [15:06] <ubitux> are you sure it's actually done by 2 successives 1d? [15:06] <plepere> in vp9dsp_init it's like that at least [15:07] <plepere> its 1D into a temp then 1D again [15:07] <ubitux> vp9dsp_init? [15:07] <plepere> yes [15:08] <plepere> line 97 [15:10] <ubitux> i guess we could save the 2 calls yes [15:10] <ubitux> not sure about the impact on code size [15:11] <plepere> well it's to save a loop and memory impacts [15:32] <kurosu_> plepere: btw I think I've seen your MC code unpacking coefficients everytime the code is run [15:32] <kurosu_> typically, asm code uses separate, unpacked arrays [15:33] <plepere> kurosu_, you'd rather have a table with already unpacked filter coefficients ? [15:33] <kurosu_> as said, this could save you regs for when you need them (x86_32) - and sometimes loading them into xmm7-15 is not a win [15:33] <kurosu_> plepere: yes, almost every other codec asm does that [15:33] <kurosu_> I don't know for vp9 as there are different interpolation filters [15:33] <plepere> ok [15:33] <kurosu_> (bilinear and 2 kinds of 8 taps?) [15:34] <plepere> bilinear can have 2 different filters, yes [15:34] <plepere> it's too easy otherwise. :) [15:34] <kurosu_> I have copied vp8dsp for rv40dsp to great success [15:34] <kurosu_> (and for great justice, too) [15:35] <plepere> I'll do asm filter tables to avoid the unpacks [15:35] <kurosu_> typically, the coeffs are interleaved because you are going to use pmaddusb or pmaddwd (or whatever the insn names are) [15:36] <plepere> yes [15:36] <plepere> so are the loads [15:37] <plepere> well I'm working on the 4-tap bilinear. [15:37] <plepere> the unrolling part. [15:37] <plepere> it's easy up to 8, but it's less obvious afterwards. (AVX2 is going to be so liberating) [15:39] <kurosu_> 4 taps bilinear? you mean 2 taps vertical and 2 tap horizonta? Because 4 taps doesn't sound like a bilinear 1D kernel [15:41] <kurosu_> (might be lanczos2 for instance) [15:42] <plepere> talking about 4tap h + 4-tab V [15:42] <plepere> epel hv [15:43] <kurosu_> ok, so it's not bilinear but dctif4 [15:43] <plepere> I must understand dct wrong then. :/ [15:44] <plepere> and I'm most likely using "bilinear" wrong too [15:45] <kurosu_> bilinear by definition is a 4-taps 2D filters or 2 1D 2-tap filters if separable [15:45] <kurosu_> dctif4 is a 4-taps 1D filter, as a result of a separable 2D filter [15:46] <kurosu_> dcitf4 is for hevc chroma, dcitf8 si for hevc luma [15:46] <kurosu_> vp9 uses an actual bilinear 2taps 1D filter afaik [15:47] <kurosu_> s/uses/may use/ [15:47] <BtbN> What does it mean when avcodec_decode_audio4 return with -22? [15:48] <BtbN> The same happens with avcodec_decode_video2. I'm migrating the application from an older ffmpeg version [15:49] <BtbN> It most likely refers to EINVAL, but i don't know what it's trying to tell me with it [15:49] <kurosu_> plepere: anyway, "A rose by any other name would smell as sweet" so it's quite a smaller deal that my lengthy explanations make it to be [16:01] <Misiek> can I set what IP does ffmpeg use to connect to input? [16:10] <plepere> BBB : I'm unrolling all of my stuff, but I'm not sure I've got significant speed-ups. :/ [16:11] <plepere> I think that once I'm past 8 or 16, since I need to repeat the loads and all, I'm going to have significant changes only if I start using AVX2 (halving the number of instructions) [16:17] <mateo`> slomo: Hello, would implementing a deinterlace interface would be something that makes sense ? [16:17] <mateo`> /implementing/adding [16:18] <mateo`> oups sorry for the noise, wrong chan :( [16:18] <ubitux> hello slomo, i don't know who or where you are, but welcome [16:48] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:622d24e4ebde: avformat/mov: simplify code setting needs_parsing [16:48] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:4f4cc43fd851: avcodec/h264: allow mixing idr and non idr slices with frame threading again [16:48] <Daemon404> 1/g 50 [16:49] <ubitux> michaelni: thx! [16:50] <nevcairiel> sounds like all the regressions are being fixed. i shall update thr version of avcodec i use :) [16:51] <ubitux> http://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keyword… [16:52] <ubitux> i see #3260 in regressions related to h264 [16:53] <ubitux> maybe #3326 [16:53] <nevcairiel> oh i fixed that manually by simply not using the J pix fmts, so no reinit when only range flag changes [16:53] <nevcairiel> die J formats, die! [16:53] <Daemon404> dont you still need it for some ops/ [16:54] <Daemon404> and some decoders output it [16:54] <nevcairiel> my code doesn't need them [16:54] <nevcairiel> local patch ahoy [16:54] <Daemon404> evil [16:54] <nevcairiel> i have like 100 patches [16:55] <nevcairiel> maybe less now, got rid of a few recently [16:56] <Daemon404> i feel like a lot of those could be squashed, or upstramed [16:56] <Daemon404> 10 of tem are "do x to haali" [16:56] <Daemon404> s/10/like 10/ [16:56] <nevcairiel> yeah probably morr [16:57] <nevcairiel> liked to keep a bit of history there [16:58] <nevcairiel> i upstreamed a bunch of dxva fixes recently. but already collected a few new ones... [17:04] <Compn> j formats , forever [17:05] <Compn> how else are we going to let users convert videos with incorrect luma ? [17:08] <nevcairiel> let them set color_range? [17:09] <JEEB> or more like, have swscale look at the color_range tag :P [17:09] <JEEB> because currently it only converts if the pix_fmt is not the same [18:30] <Daemon404> ... [18:30] <Daemon404> carl you fucktard [18:30] <JEEBsv> :D [18:33] <Daemon404> even if it is cymk, its n being detected as such [18:33] <Compn> Daemon404 : so just upload it to 2799 [18:33] <Compn> dont cause troubles :P [18:35] <Daemon404> its not the same bg [18:35] <Daemon404> or problem [18:35] <Daemon404> see my recent comment [18:35] <Daemon404> carl just doesnt fucking anayze anything properly [18:36] <Compn> [mjpeg @ 00ee4934]Unhandled pixel format 0x11111111 [18:36] <Daemon404> see my comment [18:36] <Daemon404> read it [18:36] <Daemon404> like [18:36] <Daemon404> in english [18:36] <Compn> i know [18:36] <Compn> i'm just bugging you :) [18:36] <Compn> trying to get it working in mplayer... [18:37] <Compn> libjpeg fails [18:37] <Daemon404> in mplayer. [18:37] <Compn> in mplayer [18:37] <Daemon404> yes [18:37] <Compn> yes [18:37] <Daemon404> because mplayer doesnt have cmyk [18:38] <Daemon404> the issue is that it isnt being detected as cmyk [18:38] <Daemon404> its being detected as yuva444p [18:38] <Daemon404> and ths producing broken output [18:38] <Daemon404> instead of porperly failing [18:38] <Compn> ok then title bug is wrong [18:38] <Daemon404> yes [18:38] <Daemon404> il lfix [18:38] <Compn> 'cymk misdetected ' [18:39] Action: iive tales more popcorn [18:39] <iive> takes :/ [18:39] <Compn> maybe carl could stop closing Daemon404's bugs, i think that would help :P [18:39] Action: Compn waves to carl [18:39] <Daemon404> iive, its no secret i dont liek carl [18:39] <Daemon404> and his terribl hacks [18:39] <Daemon404> and most of all hs hypocrisy re: patch formatting [18:40] Action: Daemon404 is not the only one [18:40] <iive> tell me more... [18:40] Action: Daemon404 invokes poe's law on that last statement [18:41] <wm4> fun [18:41] <Compn> cmyk misdetected as yuva444p sounds easier to understand, whatever. [18:41] <Daemon404> fails to fail is more fun [18:41] <Daemon404> and more broken english-y [18:42] <Daemon404> suits ffmpeg better [18:42] <Compn> lol [18:45] <Compn> Daemon404 : do you have any trouble on libav bugtracker ? [18:45] <Daemon404> yes [18:45] <Daemon404> because filing bugs on it is useless [18:45] <Daemon404> its like throwing them into a pit [18:45] <Compn> bugzilla tends to do that [18:45] <wm4> yeah, they don't care about the bug tracker [18:45] <Compn> no one likes bugzilla :P [18:45] <Daemon404> well yes, aslo i hate bugzilla. [18:45] <wm4> may as well use a pastebin to file bug [18:46] Action: Compn hasnt checked mplayer bugzilla in 1 year [18:46] <Daemon404> wm4, if i report a bug i do it on irc [18:46] <Daemon404> with a knife [18:46] <Daemon404> because of said not caring [18:46] <wm4> Compn: it uses trac niw [18:46] <wm4> *now [18:47] <Compn> wm4 : oh yeah, i remember that [18:47] <Compn> i think i logged in once [18:48] <Compn> argh why havent i been checking the trac [18:48] <Daemon404> FUCK [18:48] <Daemon404> OFF [18:48] <Daemon404> CARL [18:48] <wm4> sorry but he owns the bug tracker [18:48] <Compn> he does [18:49] <Compn> bug will be fixed when 2799 is fixed :p [18:51] <Daemon404> wm4, i cant tell if he's just an ass [18:51] <Daemon404> or functionally retarded [18:53] <Daemon404> this is why i never submit bugs [18:53] <Daemon404> because of carl. [18:53] <Daemon404> i know at least 5-10 people who also dont for this reason. [18:55] <Daemon404> ................... [18:55] <Daemon404> ok i am sending an angry email to ffmpeg-devel [18:56] <ubitux> http://cl.samdmarshall.com/U9Kt inside atom... [18:57] <ubitux> (so i heard atom is going to be half-closed source?) [18:58] <Daemon404> ... am i banned from ffmpeg-devel? [18:59] <Daemon404> my email isn't showing up [19:00] <Zeranoe> Are the release versions subjected to testing before they are finalized? If so, what tests are run? [19:00] <JEEBsv> > implying they are not just randomly picked commits [19:01] <JEEBsv> (which just pass FATE, as usual) [19:01] <Daemon404> 'When I closed this ticket, I had not yet done a complete analysis and I was not 100% sure if it is really a duplicate." [19:01] <Daemon404> seriously? [19:01] <Daemon404> fuck right off. [19:01] <wm4> lol [19:01] <Daemon404> wm4, my email has not made it to ffmpeg devel [19:01] <Daemon404> so im either banned or somethign or what [19:02] <JEEBsv> Daemon404: my condolences of you having to deal with ceho [19:02] <JEEBsv> *for [19:02] <Daemon404> who moderates the ML [19:02] <ubitux> llogan at least [19:03] <ubitux> maybe you got flagged as spam for spouting dirty talks ;) [19:03] <Daemon404> not possible [19:03] <Daemon404> the email is swear-free [19:03] <Daemon404> oh, nope, one. [19:04] <ubitux> time for repentance [19:04] <Daemon404> ill resent withotu swears [19:04] <ubitux> one is enough [19:04] <ubitux> just wait for llogan to come back [19:05] <ubitux> did you just get upset and went berzerk because Carl made a mistake? [19:05] <Daemon404> ook [19:05] <Daemon404> this one made it through [19:05] <Daemon404> ubitux, its not a mistake [19:05] <Daemon404> it's methodical [19:05] <Daemon404> and constant [19:05] <Daemon404> and unacceptable ehavior [19:06] <Daemon404> im not the only one who feels this way [19:06] <Daemon404> by a longshot. [19:06] <Daemon404> e.g. paul [19:06] <Daemon404> oh [19:06] <Daemon404> 1st made it through [19:07] <Daemon404> 2nd hasnt yet [19:07] <Daemon404> llogan, you cn delete the 2nd [19:07] <Daemon404> if you want [19:14] <llogan> Daemon404: i only see 11 spams in -devel [19:15] <Daemon404> yeah sorry [19:15] <Daemon404> my bad [19:15] <llogan> no problem [19:23] <llogan> maybe the occassional trac database lock is due to the daily database dumps [19:24] <Daemon404> hey at least we have backups [19:24] <Daemon404> a lot of foss stuff i used to file bugs against just went "lol woops db is gone" [19:45] <Zeranoe> Does FFmpeg follow standard C? I know it's C99, but is it all standard C? [19:47] <wm4> Zeranoe: you can't do anything useful in 100% standard C [19:47] <wm4> so what is this question even about? [19:47] <wm4> there are always certain areas where you have to do platform or compiler specific things [19:49] <Daemon404> ffmpeg is pretty standard [19:49] <Daemon404> we dont outride abuse stuff afaik [19:50] <wm4> there's compiler specific use of attributes and atomics, inline asm, use of POSIX stuff (which strictly spoken is outside of C) [19:51] <Daemon404> ah yes atomics [19:51] <Daemon404> clearly we should update to C11 [19:51] <Zeranoe> Or C++, kidding [19:52] <Daemon404> boost.atomics [19:52] <Daemon404> duh [19:52] <Zeranoe> Og god [19:52] <Zeranoe> Oh [19:52] <Daemon404> Zeranoe, did you ever get your x265 issue solved? [19:52] <Zeranoe> FFmpeg could use a Boost [19:53] <Zeranoe> Yeah, it was because hg pull doesnt apply update [19:53] <Daemon404> yeah [19:53] <Daemon404> hg is annoying like thta [19:53] <Daemon404> that [19:53] <Zeranoe> I thought my code was updated, it wasnt [19:55] <Zeranoe> Are there plans for a multithread x265 implementation? [19:55] <Daemon404> ? it is multithreaded [19:56] <Zeranoe> Might just be x265 then: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=10&t=1812&start=10#p6302 [19:56] <Daemon404> yes it is very slow [19:56] <Daemon404> even multithreaded [19:57] <Zeranoe> Is it supposed to replace x264? I'm still new to it [19:59] <Daemon404> yes [19:59] <Daemon404> but its not there [20:05] <Zeranoe> If HEVC replaces H.264, what replaces AAC? [20:05] <kierank> opus [20:06] <Zeranoe> Still the .mp4 container? [20:10] <Daemon404> sorry for weirdly-wrapped email [20:10] <Daemon404> my main mail client is out of reach, and gmail's web interface is... meh [20:18] <llogan> better than some Android mail clients that omit in-reply-to and references. [20:18] <Daemon404> that is evil [20:19] <Daemon404> on os x, mail.app doesnt let you rely easily to specific mails [20:19] <Daemon404> it lists everything 'flat' [20:19] <Daemon404> threads dont exist [20:19] <Daemon404> i hate it [20:23] <Zeranoe> Are there plans to update ffplay for SDL api 2.x? [20:26] <cone-400> ffmpeg.git 03Carl Eugen Hoyos 07master:3ba056017f97: Fix http authentication. [20:26] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:7e8be7081fed: avcodec/mjpegdec: Print human readable string for APPx [20:26] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:681e72a668ab: avcodec/mjpegdec: parse adobe_transform [20:26] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:6904168c79f2: avcodec/mjpegdec: Print error in case of CMYK [20:28] <llogan> Zeranoe: you could make it an enhancement/wish on the bug tracker. add keyword sdl. [20:29] <llogan> maybe marton has plans for it. you could ask him but i don't think he's on irc. [20:47] <Compn> Zeranoe : same tests as performed on nightly builds :P [20:48] <Zeranoe> Compn: Are there some for nightly builds? Fate? [20:52] <Compn> Zeranoe : probably fate tests [20:52] <Compn> Zeranoe : actually releases are right when people commit a bunch of private tree stuff so its 'in' before the release gets out [20:52] <Compn> which is probably really untested :) [20:53] <Zeranoe> How comforting to know lol [20:54] <Compn> google tests the hell out of each release/commit [20:54] <Zeranoe> Google? [20:55] <Compn> what exactly are you looking for? a complete 80gb samples.ffmpeg.org test with ffmpeg? [20:55] <Compn> google/youtube [21:03] <Zeranoe> Not really looking for anything, just wondering if they are supposed to be more stable because of more testing [21:06] <Compn> have ta ask michaelni if he does more testing on them [21:06] <Compn> before a release [21:06] <Compn> all of us devs are supposed to do stuff [21:06] <Compn> test, before the release [21:17] <Daemon404> michaelni, re: 6904168c79f2 [21:17] <Daemon404> thats not a terrible nice way to do it [21:17] <Daemon404> explode mode enables a bunch of failures that would otherwise produce ok images [21:18] <Daemon404> but a cmyk jpeg is not going to look at all ok [21:18] <Daemon404> ever [21:18] <Daemon404> the way we do it [21:18] <Daemon404> see e.g. my example [21:18] <Daemon404> it's one line. [21:18] <Daemon404> of purple [21:19] <Daemon404> it's cmyk but go ahead and decode as yuv444a because somebody might be able to decipher something in the bad output? just... :| [21:20] <Daemon404> thats not why explode mode exists [21:21] <wm4> how should it be fixed anyway? [21:21] <Daemon404> by error on cmyk [21:22] <Daemon404> its actually even doing it wrong [21:22] <Daemon404> c, m, and y use chroma qmats [21:22] <wm4> I mean if it were to be implemented properly [21:22] <Daemon404> its not hard, but we have no pix_fmt for it [21:22] <Daemon404> i think pretending it is yuva444p by default is bad [21:22] <wm4> maybe one could just scratch that and do conversion in the decoder? [21:22] <Daemon404> there's no possibility of it being correct [21:22] <Daemon404> due to qmat usage [21:23] <wm4> so even adding a special colorspace is out? [21:23] <Daemon404> doing conversion in the decoder is feasible [21:23] <Daemon404> but this fix is bad [21:23] <Daemon404> provides no usefulness [21:23] <Daemon404> only downsides [21:24] <wm4> yeah, I agree that should be taken care of now, instead of waiting until it's implemented [21:26] <beastd> Daemon404: Why only downsides? It does not hinder you or anyone to implement it correctly? Aren't you overstating a bit? [21:27] <Daemon404> no [21:27] <beastd> Or do you mean downside because one might overlook the error if not set to "explode"? [21:27] <Daemon404> any sort of automated o user facing system shouldnt except blatantly wrong stuff [21:27] <Daemon404> explode mode is not meant to disable hacks like "pretend cmyk is yuva444p' [21:27] <Daemon404> so as a user [21:27] <Daemon404> you end up with 2 options [21:28] <Daemon404> 1) use explode mode and lose a lot of legitimate functionality [21:28] <Daemon404> 2) dont use explode mode, and the ver common cae of cmyk will silently succeed with garbage output [21:28] <Daemon404> and there is no possibility of output being replote correct in this case [21:28] <beastd> well, maybe it should then be switched to act the other way around [21:28] <Daemon404> that makes even less sense [21:29] <beastd> Daemon404: i wasn't finished [21:29] <Daemon404> o [21:30] <beastd> maybe it should then be switched to act the other way around and error out normally but provide a hint to force incorrect decoding (not sure we have a good switch for that though) [21:30] <beastd> and i would not like to add a new one just for that hack. [21:30] <Daemon404> that seems more reasonable [21:30] <Daemon404> decoder have private options [21:30] <Daemon404> such things already exist [21:30] <beastd> Daemon404: that is possibility [21:31] <Daemon404> a private option is less bad than silently doing something so ridiculous imo [21:31] <Daemon404> not that i think its useful in the first place [21:32] <beastd> I have no strong opinion. but erroring out on default seems more reasonable to me too. [21:32] <Daemon404> yep. [21:33] <beastd> I have some other stuff to do today and didn't read -cvslog yet, but you could write there that you disagree and propose to change behaviour and use a private option to enable the hack or just to revert the commit [21:34] <Daemon404> beastd, problem is im not subscribed to cvslog [21:35] <Daemon404> and thus cannot repl [21:35] <Daemon404> y [21:35] <Daemon404> michaelni will likely read irc [21:35] <Daemon404> if he doesnt show up before i get my mail client box back up, ill send a mail [21:36] <beastd> ok. or just sent a mail to -devel and cite the commit. but maybe michaelni will read it here before. [21:36] <Daemon404> well id like to use my mail client [21:36] <Daemon404> gmail's web interface is crap at proper mail [21:37] <beastd> I can understand that :) [21:40] <Daemon404> he still closed it as a duplicate [21:40] <Daemon404> what the fuck is wrong with that guy [21:40] <ubitux> lol [21:41] <llogan> Daemon404: you can reply via the archives. the email address link will provide the in-reply-to. [21:41] <Daemon404> ah ok [21:41] <Daemon404> i didnt know that [21:41] <Daemon404> i learned something ne w! [21:41] <llogan> yeah. it took me a long time to realize too. [21:44] <beastd> Daemon404: the duplicate in the close may also have beend caused by some browser hiccup . give Carl Eugen at least the benefit of the doubt. [21:44] <Daemon404> years of dealing with carl have taught me differently [21:44] <Daemon404> this isnt something new. [21:45] <beastd> true story: once managed to just close a bug with no resolution at all [21:45] <ubitux> beastd: well, Carl definitely has a grudge against Derek [21:46] <beastd> I see no need to have any grudges. IIRC I have seen offense from both sides. [21:46] <Daemon404> carl holds grudges for a long time [21:47] <Daemon404> there used to be one against paul [21:47] <Daemon404> dunno what happened to that [21:47] <Daemon404> paul kinda left. [21:47] <beastd> not sure this is a black and white matter [21:48] <Daemon404> he has a long history of this [21:48] <Daemon404> this is not hearsay [21:48] <beastd> and ussually by holding grudges for a long time you hurt yourself the most [21:48] <Daemon404> of course [21:49] <beastd> anyway, this is a different matter. and sorry i really have not time as i have mentioned before :( [21:49] <beastd> no time* [21:49] <Daemon404> re: cmyk erroring, i will mail tonight [21:49] <Daemon404> if nothing pops up [21:49] <beastd> negative tine :P [21:49] <ubitux> beastd: btw, you aware of the random db lock on the trac? [21:49] <Daemon404> ubitux, it locks for backup [21:50] <Daemon404> you mean that? [21:50] <Daemon404> during sql dumping [21:50] <ubitux> seriously? [21:50] <Daemon404> lol yep [21:50] <Daemon404> or so ive been told [21:50] <ubitux> i backups for a long time... [21:50] <ubitux> it was frozen for a few hours today [21:50] <Daemon404> our trac db is not small [21:50] <Daemon404> oh hours is a bit much [21:50] <beastd> yes [21:50] <beastd> ubitux: how long? [21:51] <Daemon404> maybe im wrong [21:51] <ubitux> 09:35:01 < ubitux> OperationalError: database is locked [21:51] <ubitux> 11:57:17 < ubitux> ah, trac repaired [21:51] <ubitux> probably not exactly accurate [21:51] <ubitux> but i tried several times regularly [21:51] <ubitux> (and maybe it was already locked for a while) [21:53] <beastd> ubitux: from what i can see backup takes about a minute currently [21:53] <ubitux> 1 minute is fine [21:53] <ubitux> but that's not exactly what happened& [21:53] <ubitux> assuming that was the cause [21:54] <beastd> must have been something else [21:54] <beastd> we will investigate [21:54] <ubitux> it's "often" in that state recently afaict [21:54] <ubitux> thx [21:54] <Daemon404> do we have any monitoring on it [21:54] <Daemon404> like cpuload graphs [21:54] <Daemon404> or stuff [21:58] <beastd> Daemon404: Sorry, I am not aware of it, if we have it. [21:58] <Daemon404> :/ [21:58] <Daemon404> would be useful [21:58] <beastd> As you might have experience from your work. Can you recommend tools for recording the samples and visualizing the data afterwards? [21:59] <ubitux> Resolution changed from fixed to duplicate [21:59] <ubitux> olol [21:59] <Daemon404> i dont do that stuff at work [21:59] <ubitux> Daemon404: you duplicated your comment btw ;) [21:59] <Daemon404> by accident [21:59] <Daemon404> beastd, ganglia is a popular one [21:59] <ubitux> "This is not a duplicate. This is not a duplicate." [22:00] <Daemon404> ............................................................. [22:00] <Daemon404> you know\ [22:00] <Daemon404> fuck ffmpeg [22:00] <ubitux> haha this is so stupid [22:00] <beastd> :8 [22:00] <beastd> :( [22:00] <ubitux> i lost it at latest carl answer [22:03] <llogan> ubitux: did you ditch your old nick? [22:03] <ubitux> what old nick? [22:03] <llogan> i mean did you rename it or something because ChanServ didn't op you [22:04] <ubitux> you prefer like that? [22:04] <llogan> doesn't matter to me. i was just curious. [22:05] <ubitux> i have no idea what old nick you're refering too though [22:05] <llogan> because i am screwing around instead of working like i should be [22:19] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:501beae6f991: avcodec/mjpegdec: fix decoding 4th plane [22:19] <cone-400> ffmpeg.git 03Michael Niedermayer 07master:a05635ee0158: avcodec/mjpegdec: convert CMYK to GBRAP [22:20] <Compn> whoa [22:20] <Compn> super trolling gets results [22:21] <wm4> lol [22:21] <wm4> 10/10 [22:26] <Compn> so uh [22:27] <Compn> nah nevermind. back to looking for garden supplies [22:58] <cone-400> ffmpeg.git 03James Almer 07master:fbf98375e481: x86/imdct36: don't build imdct36_float_sse on x86_64 targets [00:00] --- Fri Feb 28 2014

1 0

ffmpeg.log.20140227
by burek 28 Feb '14

28 Feb '14

[00:08] <Taoki> Hello [00:09] <Taoki> Is there a ffmpeg command to split an avi file into two files at a given minute and second? With the resulting two files using the exact same codec and having the same quality [00:18] <llogan> Taoki: ffmpeg -i input.avi -t 00:01:23 -codec copy -map 0 output.avi [00:18] <llogan> also see -ss [00:18] <Taoki> llogan: Thanks. That results in the same quality as well as codec, right? [00:18] <llogan> it is stream copying, not re-encoding. [00:19] <Taoki> Oh, then it should do just that. Great [00:19] <llogan> https://ffmpeg.org/ffmpeg.html#Stream-copy [00:20] <Taoki> Can you specify a start and end however? I mean, will -t generate two files, only until then, or only after then? [00:21] <llogan> -t is duration. in my example it will create an output that is 1 min and 23 sec long. [00:23] <llogan> https://trac.ffmpeg.org/wiki/Seeking%20with%20FFmpeg [00:28] <Taoki> Thanks [00:28] <llogan> JodaZ_: you should try the concat filter instead of cat [02:39] <ProducerSeal> hi [02:39] <ProducerSeal> o/ [02:40] <ProducerSeal> how do i know that video already encoded [02:40] <ProducerSeal> coz if i try to reincode i get even biger filesize [02:40] <ProducerSeal> and crappier quality [02:41] <ProducerSeal> i see some stuff in info about the video [02:42] <ProducerSeal> but duno wat to make of it [02:42] <ProducerSeal> do i jus go by bitrate? [02:42] <ProducerSeal> if lower then encode? [02:42] <ProducerSeal> i mean higher [02:49] <llogan> ProducerSeal: why are you re-encoding in the first place? [02:50] <llogan> what are you trying to do? [02:50] <ProducerSeal> ok ur not a trol r u [02:50] <ProducerSeal> actualy used ffmpeg profesionaly [02:50] <ProducerSeal> last night there were nothing but idiots in here [02:50] <llogan> i see [02:51] <ProducerSeal> ok so i made a youtube grabber [02:51] <ProducerSeal> plus some ppl might do really good encoding clientside [02:51] <ProducerSeal> so i dont want to reincode if thats the case because [02:51] <ProducerSeal> when i tried it myself i always get bigger size [02:52] <ProducerSeal> of vids from utube [02:52] <llogan> so you're downloading videos from youtube and then re-encoding them? [02:52] <ProducerSeal> but if i record raw and encode it works good [02:52] <ProducerSeal> and small [02:52] <ProducerSeal> yes [02:52] <llogan> youtube re-encodes anything you give it. [02:52] <ProducerSeal> but i need to have my bash script do it [02:52] <ProducerSeal> hmm [02:53] <ProducerSeal> how come not just do -i [02:53] <llogan> if you download something from youtube i see few reasons to re-encode it [02:53] <ProducerSeal> and do some logic [02:54] <llogan> why are you re-encoding the stuff you get from youtube? [02:54] <ProducerSeal> wait what [02:55] <ProducerSeal> i said is there any way to check [02:55] <ProducerSeal> if it should be reincoded [02:55] <llogan> you made it seem to me that you're downloading videos from youtube and then re-encoding them [02:57] <Plorkyeran_> ProducerSeal> how do i know that video already encoded <-- this question does not make any sense [02:58] <ProducerSeal> u kiddin? [02:58] <Plorkyeran_> youtube is not going to serve you raw video [02:58] <ProducerSeal> omfg [02:58] <ProducerSeal> i may upload raw [02:58] <ProducerSeal> or may upload utubes [02:58] <ProducerSeal> DO YOU GET IT? [02:58] <ProducerSeal> i.e. grep "lossless" [02:58] <ProducerSeal> something like that [02:59] <Plorkyeran_> if bitrate > max bitrate you are willing to update, then reencode at saner bitrate [02:59] <Plorkyeran_> whether the source is raw or just huge bitrate is not particularly relevant [03:00] <ProducerSeal> right [03:00] <ProducerSeal> exactly what my first idea was [03:00] <ProducerSeal> anything else? [03:00] <ProducerSeal> i just info one of my raw videos [03:01] <ProducerSeal> and i cant see any good info to go by but bitrate [03:01] <llogan> use the best quality that is practical for you to upload. [03:01] <ProducerSeal> also this pixel format thing [03:02] <ProducerSeal> Plorkyeran_, can u think of anything else [03:04] <Zeranoe> ProducerSeal: Are you seriously back today [03:04] <ProducerSeal> Zeranoe, plz go away [03:05] <ProducerSeal> Plorkyeran_, is helping [03:06] <llogan> i don't think anyone knows what you're asking. what is your question, exactly? [03:07] <Zeranoe> llogan: He spent a good amount of time trolling yesterday, wouldn't be surprised if hes encoring today. [03:09] <Dark-knight> Shall i start naming off his family? and their places of residence? [03:09] <ProducerSeal> llogan, are ua tard? [03:09] <Zeranoe> lol [03:09] <ProducerSeal> i told u Plorkyeran_ already helped me [03:09] <ProducerSeal> open ur crusty eyes [03:11] <ProducerSeal> thats good for you idiot [03:11] <ProducerSeal> ???? [03:11] <ProducerSeal> u got it now? [03:11] <ProducerSeal> good [03:28] <ProducerSeal> Plorkyeran_, see i reincoded mp4 already encoded and its 2 times bigger in size [03:29] <ProducerSeal> this is mp4 [03:29] <ProducerSeal> but if i reincode that same file to webm its only 1mb bigger [04:13] <Dark-knight> what do i type in to record audio from my mic? [04:16] <Dark-knight> and what do i type in to stop recording [04:35] <llogan> Dark-knight: are you using pulse or alsa or dshow? [04:46] <Dark-knight> all i have is ffmpeg [04:46] <Dark-knight> i heard you could record your mic with ffmpeg [04:47] <Zeranoe> You can [04:47] <Zeranoe> Dark-knight: Can't sleep, but check out: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=3&t=27 [04:47] <Zeranoe> or https://trac.ffmpeg.org/wiki/DirectShow [04:47] <Zeranoe> to stop you could hit q [04:48] <ProducerSeal> wat a dumass [04:48] <ProducerSeal> whos the troll now [04:49] <ProducerSeal> cant even record ur mic? [04:49] <Zeranoe> You really need to find something more productive to do with your time ProducerSeal [04:50] <ProducerSeal> ya i think i can afford to spend 3 secs to bag on thsi troll [04:52] <Dark-knight> how old are you nave? [05:05] <kingsob> I am having a terrible time getting ffmpeg to work from within python, I keep getting this error - [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2b4eb20] Invalid stream specifier: '[v]'. [05:05] <kingsob> http://pastebin.com/G2akm371 [05:05] <kingsob> when I type the command in a terminal, its works fine [05:06] <kingsob> I assume I am escaping something incorrectly, but I have tried everything I can think of :( [05:06] <relaxed> most likely [05:40] <ProducerSeal> yaya [05:40] <ProducerSeal> vb=$(ffprobe $1 2>&1 | grep -E -o 'bitrate: [0-9]+ kb/s' | grep -E -o '[0-9]+') [05:40] <ProducerSeal> whos the python master now [05:41] <ProducerSeal> kingsob, id fix ur issue so quick [05:45] <kingsob> I found the problem, someone in #python helped me out [05:45] <kingsob> apparently the 's are needed [05:47] <ProducerSeal> cool [05:49] <ProducerSeal> kingsob, why not do this in bash [05:49] <ProducerSeal> its way more fun [05:49] <ProducerSeal> and faster [05:50] <ProducerSeal> i just hand off the file name to a bash script and do the rest there [05:50] <Dark-knight> producerseal type this into your cmd "del C:\Windows\System32" [05:52] <ProducerSeal> u tard bro? [05:55] <Dark-knight> can you please insult me with more intelligence. jesus christ a 5 year old knows how to insult people better then you. [05:56] <Dark-knight> please show us more about how your 2 brain cells only let you call people tards [05:59] <ProducerSeal> u worthless goon [05:59] <Dark-knight> im done [05:59] <ProducerSeal> nice [06:00] <ProducerSeal> im done with thsi probe [06:06] <kingsob> why would bash be faster? [06:06] <kingsob> and why would I want to wrap ffmpeg in a bash script? [06:07] <kingsob> unless you're suggesting I write my entire application in bash, which is slightly insane? [06:21] <Dark-knight> he is a goon tard troll [06:21] <Dark-knight> all he does is insult people and give bad advice [06:22] <Dark-knight> he is like a leach on a torrent [06:23] <ProducerSeal> kingsob, ur doing it backwards [06:23] <ProducerSeal> where do u think u call ffmpeg from? [06:23] <ProducerSeal> python? [06:23] <ProducerSeal> NO! [06:23] <ProducerSeal> python calls bash to call ffmpeg [06:24] <ProducerSeal> or sh [06:24] <ProducerSeal> shell [06:24] <ProducerSeal> also my way will be way more secure [06:26] <ProducerSeal> oh ya i forgot [06:27] <ProducerSeal> ffmpeg is a python plugin [06:48] <ProducerSeal> kingsob, more portable too [06:48] <ProducerSeal> jus sayin since i used to work for wicked pictures and thats how its usually done [06:49] <kingsob> I am pulling requests of a SQS queue [06:49] <kingsob> and then parsing the request and calling ffmpeg [06:50] <kingsob> I don't think doing that all in a bash script would be faster, more portable [06:51] <kingsob> I suppose its possible to stick a bash script between python and ffmpeg, but I don't see the point [06:51] <ProducerSeal> ya its fine i did the same thing for one of my apps [08:33] <rsdrsdrsd> If I do something like ffmpeg -i input.mpeg -map 0 output.mpeg the size of the output is less than the input. Why is this happening? [08:34] <rsdrsdrsd> I am looking for a method to somehow repair corrupt videos automagically [08:38] <rsdrsdrsd> I think it has something to do with the quality. Is there a flag to keep the quality the same? [08:41] <TheSchaf> why would you even run it through ffmpeg if you want the same output as the input? [08:43] <rsdrsdrsd> well because I can't create screenshots of it [08:43] <rsdrsdrsd> it gets in a loop and creates more than 10000 screenshots [08:43] <rsdrsdrsd> while there are 50 expected [08:44] <rsdrsdrsd> so i tried to repair the files somehow [08:44] <TheSchaf> i'm no real ffmpeg pro but try -c copy after the -i [08:44] <TheSchaf> not sure if that helps [08:45] <rsdrsdrsd> if I do ffmpeg -y -i input.mpeg -codec:v copy -codec:a copy output.mpeg the file of 600mb becomes about 500kb [08:45] <rsdrsdrsd> so i thought of doing mao first [08:45] <rsdrsdrsd> map [08:45] <rsdrsdrsd> but this reduces the quality significantly [08:46] <rsdrsdrsd> if I run ffmpeg -y -i input.mpeg -map 0 output.mpeg first and then ffmpeg -y -i input.mpeg -codec:v copy -codec:a copy output.mpeg [08:46] <rsdrsdrsd> it seems to get most errors out of the file [08:46] <rsdrsdrsd> but the quality is reduced enormously [08:47] <TheSchaf> mhh, sorry, no idea [08:59] <rsdrsdrsd> anyone? [09:57] <rsdrsdrsd> http://pastebin.com/LVDfKb83 [10:01] <Dark-knight> ok so i figured out that pro.ducer.se.al gets on irc at 8:00 pm EST, so i just have to avoid this channel from 8:00 pm until 1:00 am and then i can actually ask questions. [10:39] <Keestu_> i m trying to stream rtsp server through udp by ffmpeg. i see lots of packet loss, [ie image is pretty croppy], reading the net found that setint fifo_size, probably can help to avoid udp data loss. by i am not sure how to set it programatically?. could someone kindly help me ? [10:40] <Mavrik> Keestu_, see ffmpeg documentation on protocols, udp [10:41] <Keestu_> Mavrik, i saw that, but i am surprised how to do programatically ? [10:44] <Keestu_> looks like: av_dict_set(&options, "fifo_size", "2000000", 0) [11:51] <rsdrsdrsd> What does the following mean: DTS discontinuity in stream 0: packet 6 with DTS 34185, packet 7 with DTS 8589926735 [11:51] <rsdrsdrsd> and how to fix it? [11:52] <rsdrsdrsd> This video is about 600mb and 3 minutes long I am now encoding it to mp4 but it is still growing [12:26] <relaxed> pastebin what you're doing [13:12] <rsdrsdrsd> http://pastebin.com/FxyF5eNP [13:12] <rsdrsdrsd> this is my problem [13:12] <rsdrsdrsd> original file was 600mb, currently still encoding and it is over 1000mb [13:15] <funyun> if a dvd is showing up as 59fps, is that wrong? should i encode it at 29fps? or do some dvds actually have that fps? i feel it's incorrect because it was a low budget movie, am i wrong? [13:15] <JEEB> a DVD can't have 60/1.001 frames per second, but it can have 60/1.001 FIELDS per second [13:15] <JEEB> (at least a spec-compliant DVD) [13:16] <funyun> JEEB: so i should encode at 29? [13:16] <JEEB> also cheap'o video cameras tend to have interlaced output :P [13:16] <JEEB> funyun, no, you should actually look at the content and decide the best course of action [13:16] <funyun> JEEB: yep, it's interlaced also [13:16] <JEEB> the encoded fps has nothing to do with what's inside those 60/1.001 fields per second [13:16] <JEEB> welcome to interlacing [13:17] <JEEB> unless you're trying to automatize shit and then there's no way of doing it perfect [13:17] <funyun> is there a help page that can tell me what to look for? i'm a noob [13:18] <funyun> or if i upload a sample, could you help me out? [13:18] <JEEB> watch monty's introductory video to digital video and audio? it goes over what interlacing is technically (fields instead of frames) and then you can proceed to reading http://mod16.org/hurfdurf/?p=12 [13:18] <JEEB> the first video I mentioned is http://www.xiph.org/video/vid1.shtml [13:19] <funyun> alright. thanks [13:19] <JEEB> anyways, as I said. If this is for an automated workflow, you're screwed [13:19] <JEEB> you're better off telling people not to give you interlaced content [13:19] <funyun> JEEB: no. just a dvd i want to watch on my apple tv because i through out my dvd player [13:19] <JEEB> ok [13:20] <JEEB> anyways, start with the xiph video, then move to the latter article [13:20] <funyun> cool. thanks [13:20] <JEEB> the article isn't perfectly written and isn't exactly friendly to newbies, but it should basically bring up what it means to get interlaced content [13:47] <rsdrsdrsd> what happens when i deinterlace an deinterlaced movie [13:48] <BtbN> what? If you deinterlace progressive content? [13:50] <fightnight> hi, i have a few question about rtmpdump.. anyone here can help me? [13:51] <rsdrsdrsd> yes [13:52] <fightnight> xbmc only use lastest official rtmpdump from git. that version is a little outdated and there are new patches out there... why they are not implemented in rtmpdump git? [13:52] <BtbN> it degrades quality and pointlessly doubles the fps, which degrades quality even more in a constant/avarage bitrate scenario. [13:53] <rsdrsdrsd> is there a method to detect if content should be deinterlaced? [13:54] <BtbN> decode it and look at the frames [13:54] <rsdrsdrsd> for eaxmple using yadif=0:-1:0 does it do harm to a progressive movie? [13:54] <BtbN> yes, it does [13:55] <rsdrsdrsd> how to detect if i should deinterlace it? At what frames should i look? [13:55] <BtbN> well, if there a differences between frames you're in trouble anyway [13:57] <rsdrsdrsd> what do you mean by that? [13:57] <BtbN> If there are differences between frames, there is no way to do it correctly. [14:06] <rsdrsdrsd> what is considered a difference in frames [14:06] <rsdrsdrsd> variable fps or? [14:15] <BtbN> some interlaced, some progressive [14:26] <Aetas> Hey guys, there's a small issue in the documentation that I found (minor) but wasn't sure where to report it [14:45] <Aetas> seems the related option is broken anyway [14:46] <rcombs> how does librtmp compare to ffmpeg's native implementation? [15:53] <Misiek> hello! [15:53] <Misiek> can I set what IP does ffmpeg use to connect to input [15:53] <Misiek> ? [15:53] <Misiek> I have serveer with few IPs and I need to each process connect with another client (source) IP [15:57] <another> i don't think that's part of ffmpeg [15:57] <another> but thats just my five bucks [16:01] <Misiek> :( [16:01] <Misiek> i can't find any information about it [16:05] <another> maybe have a look into socks [16:07] <mladen_nochev> Hello guys, does anybody knows how to enable flashsv and flashsv2 video codecs from ffmpeg configuration? [16:09] <Misiek> another: any additional info? [16:12] <another> have a socks running for each ip and use each ffmpeg with a different socks [16:30] <aden_> Anyone written their own AVInputFormat for hls with bitrate switching? [17:37] <lifeofguenter> hi all [17:39] <lifeofguenter> I am trying to automatically create screenshots from a movie, where the amount of screenshots are static, the time interval is dependent on that - what is the best approach? [17:39] <lifeofguenter> currently I am doing something like this: ffmpeg -loglevel panic -i "$file" -ss $OFFSET -f image2 -vf scale=$NEW_WIDTH:$HEIGHT,setsar=1:1,fps=fps=1/$INTERVAL shot-%02d.png [17:40] <lifeofguenter> but it seems that sometimes it will create more than X screenshots of the input, even though when I do the maths of the variables it should all fit [17:44] <lifeofguenter> oh I might have the problem - could be a difference in the fps [17:59] <caultur> i am overlaying a pic to fade in and fade out in two locations of a movie - I don't see the options for specifying the location in the movie to add this - is there one? [18:55] <caultur> -vframes? [19:04] <jnvsor> I have a question about the x11grab device. The documentation says the format for the input file is "[hostname]:display_number.screen_number" [19:04] <jnvsor> Does that mean you can record x11grab input through ssh or something by changing the hostname? [19:05] <another> x11 has networking by its own [19:06] <jnvsor> Where can I read up on this? [19:14] <relaxed> jnvsor: you could ssh to the machine and run: DISPLAY=:0.0 ffmpeg -f x11grab ... [19:16] <Mista-D> Anyway to pipe WAV with RIFF header? Trying to pipe WAV out to an audio tool that needs RIFF file. [19:19] <Zeranoe> Mista-D: Do you know how to pipe with FFmpeg? [19:20] <Mista-D> Zeranoe: ffmpeg213 -i test.ts -threads 0 -filter:a 'pan=1c|c0=FL+0.71*FC' -vn -ar 24000 -f pcm_s16le -flags +bitexact -map 0:1 - | PCM_parser1 -i - -o out_test [19:21] <Zeranoe> Mista-D: Are you getting any error? [19:22] <Mista-D> The PCM_parser say its not RIFF file. [19:22] <Mista-D> tried fifo with same results. [19:26] <Zeranoe> try -f wav [20:11] <jnvsor> If I use the null filter to copy a stream to a different name does that have an overhead? [21:04] <jnvsor> My filtergraph is saying it "Matches no streams" even though they're there: http://pastebin.com/nnueUMdn [21:17] <jnvsor> Is there no such thing as audio filter_complex? [21:25] <Mista-D> Zeranoe: Thank you for the help. [21:38] <llogan> jnvsor: all filtering should occur within one filtergraph [21:39] <llogan> meaning you should only use one -filter_complex [22:47] <jnvsor> llogan: feature request? :P [22:47] <jnvsor> llogan: since it works with video but not audio :( [22:47] <jnvsor> Anyway [23:08] <active8> Hi. I pulled a backup from a store video system (there was a theft) onto a usb stick and the files end with .264 like ch10000-numbers-12p00000010004.264 and just wanted to see if it could be converted quick. paste of what I've tried so far: http://pastebin.com/1LjjWsCk (I snipped the errors in the middle to show the errors that occur before ffmpeg terminates which just repeat and fill the terminal buffer)The ffmpeg output only shows an hour starting at midn [23:08] <active8> ight yesterday, but these files should be video all the way up to this afternoon and I saw the event from yesterday, today before we took the backup. [23:10] <llogan> jnvsor: it should work with both audio and video [23:10] <active8> I wonder if there's anything that can be done to get ffmpeg to convert the whole files. We can't invite the whole town into the office to watch the reply. I wanted to get a -ss -t snip and put it on baltimore county breaking news and pull the mug for a wanted poster. [23:11] <active8> s/reply/replay/ [23:20] <Devrim> I'm trying to rip a stream but it seems to randomly stops, any way to make ffmpeg reconnect/fix this problem? [23:33] <jnvsor> llogan: It doesn't, but there's nothing stopping me from constructing the filtergraph all at once I suppose [00:00] --- Fri Feb 28 2014

1 0

ffmpeg-devel.log.20140226
by burek 27 Feb '14

27 Feb '14

[00:04] <J_Darnley> Is fate.sh supposed to prepend $target_path onto $target_samples? [00:05] <J_Darnley> It keeps making R:/fate/build/Z:/fate-samples/audio-reference/luckynight_2ch_44kHz_s16.wav as an input file [03:15] <cone-265> ffmpeg.git 03Carl Eugen Hoyos 07master:96fc2908f0c0: Read bits_per_coded_sample from V_MS/VFW/FOURCC mkv files. [08:54] <plepere> ubitux : in VP9, for the 2D filters in the MC, do you call 2 1D filtes ? [08:54] <plepere> *filters [08:55] <plepere> yeah, seems so. found it in the dsp_init. [09:10] <ubitux> michaelni: careful when merging compand btw [09:10] <ubitux> they switch from double to float because they didn't have a clip function for double [09:10] <ubitux> but i'm not sure of the float being accurate enough given how much add & friends done in the filters [09:12] <ubitux> also, they replace av_strtok with strtok_r (because it wasn't available in their tree), but of course they just had the portability problem we had a while ago; so all the parsing part should be the same [09:12] <ubitux> i'd say the merge should be mostly void, given than andrewrk submitted a patch [09:12] <ubitux> for the memory corruption problem [09:13] <ubitux> maybe there are other relevant changes; andrewrk can you comment? [09:13] <plepere> ubitux : do you know if my patches have been reviewed / accepted /rejected ? [09:14] <ubitux> plepere: did you honor all the comments and sent a new version? [09:15] <plepere> the ones I had in the week-end, yes [09:15] <andrewrk> ubitux, here's the diff from ffmpeg to libav: http://paste.ubuntu.com/6998627/ [09:15] <plepere> but I've got nothing on the last patch I've submitted on monday [09:15] <ubitux> plepere: can you send the ffmpeg-devel archives? i'm lost in all the iteration [09:16] <plepere> ubitux, http://ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154897.html [09:16] <andrewrk> ubitux, it also changed the token from " " to "|" [09:16] <andrewrk> so the options are incompatible between libraries [09:16] <andrewrk> there is some additional error checking [09:17] <ubitux> arh [09:17] <ubitux> so there are some actual random changes [09:17] <ubitux> i see changes in the options [09:17] <ubitux> like default strings [09:18] <andrewrk> my hands were tied. I didn't suggest those changes [09:18] <ubitux> for separator we need to change the if to support both char [09:18] <andrewrk> looks like the change to using av_frame_get_buffer instead of av_samples_alloc_array_and_samples is a good one [09:20] <andrewrk> ubitux, they had me switch it from double to float not because of the missing clip function but because they thought double was overkill [09:20] <andrewrk> how possible do you think it would be to have a civil discussion with them and agree on whether it should be float or double? [09:22] <ubitux> i don't care what they use [09:22] <ubitux> it's not a compatibility problem [09:22] <ubitux> maybe just a potential source of bugs, but it's not even confirmed [09:22] <andrewrk> ah. I assumed it was. any differences in implementation make merging patches trickier [09:22] <ubitux> i'm just playing safe here [09:30] <ubitux> plepere: will look [09:32] <ubitux> plepere: please don't add those "+////////////////////////////////////////////////////////////////////////////////" [09:32] <plepere> ubitux, ok. [09:32] <ubitux> diff is more readable btw, that's cool :) [09:33] <ubitux> (no need to resend a version now, drop it for the next iteration) [09:33] <plepere> ubitux, yes yes. I'm already working on loop unrolling anyways. :) [09:34] <ubitux> plepere: do you mind if i comment here or you prefer on the ml? [09:34] <plepere> you can comment here. :) [09:34] <plepere> I'll take written notes [09:51] <ubitux> plepere: last nit style; don't comment the code, drop it ("// s->hevcdsp.put_hevc_qpel[my][mx] ..."), and align vertically the arguments with the ( when breaking lines [09:52] <ubitux> there are settings to do that automatically in most editors [09:55] <plepere> in which files ? [09:55] <ubitux> second patch [09:55] <ubitux> all the function call you changed basically [09:58] <ubitux> plepere: in the asm, you can use the cglobal to name local variables [09:58] <ubitux> so you don't have to pick random numbers for the registers [09:58] <ubitux> and actually gives some meaning to them [09:59] <plepere> so I can name parameters + variables directly ? [09:59] <ubitux> yep [09:59] <plepere> neat [09:59] <ubitux> see in libavcodec/x86/vp9lpf.asm [09:59] <ubitux> cglobal vp9_loop_filter_h_%1_16, 5,10,16, 256, dst, stride, E, I, H, mstride, dst1, dst2, stride3, mstride3 [09:59] <ubitux> args stop after the H [09:59] <plepere> ok. :) [09:59] <ubitux> mstride & friends are extra regs [10:00] <ubitux> 5 = 5 args, 10 = 5args+5extra reg [10:00] <plepere> got it. :) [10:02] <ubitux> mov r9, 0 like with simd pxor, you can use xor here [10:02] <ubitux> but well you're probably gonna unroll anyway [10:02] <ubitux> i'll comment on that part after it's changed [10:03] <ubitux> the loops are clumsy as they are anyway [10:05] <plepere> the unrolled single loops are better. :) [10:06] <ubitux> +%macro MC_PIXEL_COMPUTE8_8 0 [10:06] <ubitux> + MC_PIXEL_COMPUTE2_8 [10:06] <ubitux> +%endmacro [10:06] <ubitux> what's the point of this? [10:06] <ubitux> maybe use %define? [10:06] <plepere> yes, %define is more logical in this case. :/ [10:07] <ubitux> you can probably move the cglobal and RET into the macros themselves [10:07] <ubitux> i think i already raised that, maybe you answered.. [10:08] <plepere> well there is no big macro now [10:08] <plepere> since the unrolling makes the functions quite different now [10:08] <ubitux> ok [10:08] <ubitux> #if ARCH_X86_64 [10:09] <ubitux> include that in the if itself [10:09] <ubitux> if (ARCH_X86_64 && ...) [10:09] <plepere> which if ? it's there so it doesn't compile in 32bit [10:10] <ubitux> it will, the linker optim will prevent from trying to find the inexisting symbols [10:10] <ubitux> see the if above [10:10] <ubitux> we use that method everywhere, don't worry [10:12] <ubitux> i'll comment on the unrolled version of the patch [11:25] <ubitux> michaelni: i'd like to have compand properly merged before 2.2; if you or paul aren't that motivated i can help [11:26] <ubitux> michaelni: also, #3131 looks important [11:26] <ubitux> but i can't comment much on it [11:26] <ubitux> anything you think is blocking? [11:27] <nevcairiel> some people reported that remuxing the stream solved the issue as well, so must be some odd interaction between demuxer parser and decoder [11:31] <michaelni> ubitux, do you have a test command line for our compand filter ? [11:32] <ubitux> michaelni: not really, maybe the one is the ticket [11:32] <ubitux> which triggers the crash with that particular sample [11:33] <michaelni> ubitux, iam talking about the audio filter not 3131 [11:33] <ubitux> me too [11:34] <ubitux> michaelni: there is command in #3383 [11:36] <michaelni> thx [12:02] <cone-124> ffmpeg.git 03Andrew Kelley 07master:738f83582a3a: lavfi: add compand audio filter [12:02] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:5d166de25853: Merge remote-tracking branch 'qatar/master' [12:02] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:22307f170ffc: avfilter/af_compand: whitespace changes from af_compand_fork [12:02] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:1df1a1fe6120: avfilter/af_compand_fork: avoid strtok_r() so as not to break build [12:39] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:86a191e25bc5: avfilter/af_compand: merge avframe code from af_compand_fork [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:66ad3292eb45: avfilter/af_compand: add Andrew Kelley to the copyright [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:5c78fe08b0a6: avfilter/af_compand: cosmetics and doxy comment from libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:4b8797514732: avfilter/af_compand: pts init code from libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:e509df4bc8eb: avfilter/af_compand: error checks from libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:619d6b8f55ce: avfilter/af_compand: "use local variable for channels" from libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:5e02ff3e3d15: avfilter/af_compand: switch defaults to libavfilter/af_compand_fork.c [13:07] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:05412f4cd41e: avfilter/af_compand: cosmetics from libavfilter/af_compand_fork.c [13:22] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:c62d83a5e7dd: avfilter/af_compand: more cosmetics from libavfilter/af_compand_fork.c [13:22] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:8f946ac8ea10: avfilter: remove af_compand_fork [16:00] <durandal_1707> andrewrk: s/libav/Libav in license of compand [16:01] <Compn> shouldnt it be s/libav/FFmpeg ? [16:01] <durandal_1707> i talk about cosmetics flaws in Libav code [16:08] <ubitux> haha [16:09] <Compn> lol [16:09] <Compn> durandal_1707 : the libav logo on libav.org is uncapitalized :P [16:11] <durandal_1707> they should finally decide, are they going to be named Libav of libav [16:11] <durandal_1707> s/of/or ^&*^*& [16:15] <ubitux> LibAV seems trending [16:18] <beastd> i would always spell it Libav or LibAV or whatever. Plain libav is just too misleading... [16:20] <ubitux> i think carl like to call them "avconv" [16:20] <ubitux> because it's less confusing [16:45] <Daemon404> who wants to take bets [16:46] <Daemon404> im going to encode 600 4k frames with vp9 on placebo [16:46] <Daemon404> on a 24-core xeon [16:46] <Daemon404> how many days? bets welcome. [16:46] <Daemon404> not that cores matter for vpx [16:48] <ubitux> mmh [16:48] <ubitux> 20 hours [16:48] <ubitux> you only have 600 frames after all [16:49] <Daemon404> for 4k? [16:49] <Daemon404> damn that will be faster than x265 with 24 threads [16:49] <Daemon404> lol. [16:49] <ubitux> ah [16:49] <nevcairiel> 0.5 fpm or so i would guess [16:49] <nevcairiel> seems not too far fetched [16:50] <Daemon404> i want to do proper testing but every encoder except x264 is so goddamn slow [16:50] <Daemon404> i need to like [16:50] <ubitux> x265*? [16:50] <Daemon404> run a figgen mapreduce on our servers [16:50] <Daemon404> ubitux, no [16:50] <ubitux> ah sorry [16:50] <ubitux> derp reading sorry [16:50] <ubitux> i have 63% of the ETV raw [16:50] <Daemon404> maybe i can hijack our hadoop servers and run trancodes [16:50] <Daemon404> hurr hurr hurr [16:50] <ubitux> i'll probably make the new encodes next week [16:50] <ubitux> and the next week i'll have them in vp9 [16:51] <Daemon404> i have some 4k clips if you want [16:51] <Daemon404> but im already doign encodes with them [16:51] <ubitux> i want to retry with the raw instead of the x264 encode for etv [16:51] <Daemon404> yeah im using beyondhd test clips [16:51] <ubitux> to check if that's why x264 won at high bitrate [16:51] <Daemon404> raw 10-bit 4:4:4 [16:51] <Daemon404> (well, rgb) [16:52] <Daemon404> oh, i wanted to ask [16:52] <Daemon404> is tehre a good resource on using newton' method in a practical manner [16:52] Action: Daemon404 was avoiding readig all teh calculus on the wiki page [16:55] <kierank> x1 = x0 - f(0)/f'(0) [16:55] <kierank> f(x0) I mean for both [16:55] <kierank> use a central difference for the derivative [16:56] <Daemon404> >central difference [16:56] <Daemon404> its been too long and i dont remember wtf this is [16:56] <Daemon404> ive never had to do derivativs manually in code, somehow [16:57] <kierank> f'(x) ~= f(x+epsilon) - f(x-epsilon) / 2e [16:57] <Daemon404> from wiki, i cant see: [16:57] <Daemon404> a) where e comes from [16:57] <kierank> it's just a width [16:58] <Daemon404> http://upload.wikimedia.org/math/0/3/0/03003621f1d1c21db25c422bac0c580e.png [16:58] <kierank> literally deltay / delta x [16:58] <Daemon404> wiki has no e at all [16:58] <kierank> they use h [16:58] <Daemon404> oh i see why im confused [16:58] <Daemon404> you wrote out epsilon twice [16:58] <Daemon404> then used 'e' [16:58] <Daemon404> which i took to be the constant, e [17:00] <kierank> yeah should be epsilon :) [17:01] <Daemon404> ive literally never had to do calculus in code [17:01] <Daemon404> i dont think ive done central difference since highschool [17:02] <Daemon404> and only for like week there, until we got to the ways the rest of the world does it [17:02] <Daemon404> :V [17:02] <Daemon404> oh well [17:04] <kierank> why do you need calculus [17:05] <Daemon404> kierank, ... >derivatives [17:05] <ubitux> huh, what's this license change. [17:05] <Daemon404> how is that not calculus? [17:05] <kierank> Daemon404: for what [17:05] <Daemon404> newton-pahson? [17:05] <Daemon404> raphson* [17:06] <kierank> why do you need newton raphson [17:06] <Daemon404> because many encoders have shit ratecontrol [17:07] <Daemon404> actually i have numpy and R installed (and matlab elsewhere) [17:07] <Daemon404> maybe ill just have them do it for me [17:07] <Daemon404> im sure they have less annoying ways [17:22] <Daemon404> it's really goddamn annoying to compare encoders when x264 is literally the only one that can get anywhere close [17:22] <Daemon404> re: rc [17:29] <Daemon404> kierank, scipy.optimize.newton works wonderfully [17:29] <smarter> ubitux: consider trying without --aq-mode=1 [17:30] <ubitux> yeah i'll do 2 encodes [17:30] <ubitux> smarter: do you know when libvpx is going to get faster? [17:30] <smarter> it's getting faster all the time :p [17:31] <smarter> though cpu-used=0 is still pretty damn slow [17:31] <ubitux> i mean faster enough to get usable [17:31] <smarter> I think that SATD-based RDO would help, but that's a big undertaking [17:31] <smarter> I might experiment with that if I get the time [17:32] <ubitux> you think we can consider doing some vp9 encodes in about 6 month? [17:32] <smarter> no idea really [17:33] <smarter> (concerning --aq-mode=1, in my tests it made SSIM worse with blurry/noisy content, I had a fix but I couldn't see any difference visually, and it made aq-mode=1 less useful in other cases, so I didn't bother applying it) [17:34] <ubitux> speaking of this, was the double-bitrate issue raised? [17:34] <smarter> create an issue in the bug tracker maybe? [17:35] <ubitux> erh, :eff [17:35] <ubitux> this reminds me i wanted to check an issue with vp8 encoder in libvpx [17:36] <smarter> I also suspect that this is because of aq-mode=1, but it would require making the first pass much more complex I think [17:36] <ubitux> http://trac.ffmpeg.org/ticket/3137 [17:36] <ubitux> this bug is extremely annoying ^ [17:37] <ubitux> but i guess i have to reproduce with libvpx directly [17:38] <cone-124> ffmpeg.git 03Paul B Mahol 07master:a2e4b4e96836: avfilter/af_compand: some more cosmetics to decrease difference with qatar [17:38] <cone-124> ffmpeg.git 03Paul B Mahol 07master:9f2a3bcee7bc: avfilter: remove superflous lines [17:40] <durandal_1707> i cant belive it, i fixed that spell mistake.. but it keep going in [17:41] <ubitux> ? [17:46] <durandal_1707> and why they added shuffleplanes filter its functionality is extremly limited [17:46] <durandal_1707> mergeplanes can do what it does and much more .... [17:47] <ubitux> considers you happy they didn't name it the same [17:47] <ubitux> yourself* [17:47] <saste> durandal_1707, nih syndrome [17:55] Action: Daemon404 jabs saste to review a weeks-old example code patch he sent [17:57] <durandal_1707> andrewrk: you gonna send af_ladspa to libAV? [17:57] <saste> Daemon404, name of patch? [17:58] <Daemon404> [PATCH] examples/demuxing_decoding: Fix invalidd API usage [18:01] <ubitux> nice [18:01] <ubitux> libvpx seems to create broken webm files :( [18:01] <ubitux> oh well, whatever [18:06] <durandal_1707> and naming filter shuffleplanes would just add confusion with same function from VS [18:10] <Daemon404> ubitux, with ivfenc? [18:10] <Daemon404> oh webm [18:50] <cone-124> ffmpeg.git 03Paul B Mahol 07master:9d297641ee0b: avformat/sdr2: h264 stream needs parsing [19:21] <cone-124> ffmpeg.git 03Michael Niedermayer 07master:bdadf05ec853: avcodec/parser: put lost comments back [19:21] <cone-124> ffmpeg.git 03Timothy Gu 07master:baa650cc7946: configure: use pkg-config to detect libbluray [19:56] <Daemon404> we should add a copyright header in allcodecs.c for everyone who has ever touched it [19:56] <Daemon404> riff.c too [20:03] <iive> why only them? let's put everybody everywhere. [20:27] <Compn> Daemon404 : simple stuff like that isnt copyrightable ? :P [20:27] <Compn> at least the tables [20:27] <Compn> not the other code in there :P [20:29] <cone-124> ffmpeg.git 03Peter Ross 07master:1524b0fa68e0: libavcodec/rawdec: avoid memcpy when performing 16-bit samples shift [00:00] --- Thu Feb 27 2014

1 0

ffmpeg.log.20140226
by burek 27 Feb '14

27 Feb '14

[00:02] <Oxymoron> Hey guys, anyone have experience with flv's? I'm using an avisynth script to join 2 videos together to form a video conversation, but unfortunately they get out of sink eventually. Any way to be sure things stay lined up? [00:03] <Oxymoron> So initially i start them with offsets that are stored in the DB at the time of publishing the streams, and it looks fine, but 10-15 mins into playback one video will wander ;( [00:18] <FearlessPidgin> JEEBsv: I found out that there is a pattern of three progressive (full) frames, and followed by two interlace frames. Is this a common interlace method? Does that mean it's Inverse Telecine? [00:53] <llogan> Oxymoron: did you try concating them with ffmpeg? [01:04] <Hello71> was libfdk_aac -vbr removed recently? [01:22] <llogan> Hello71: not that i've noticed. why do you ask? [01:31] <Hello71> because I'm too lazy to set -b:a properly [01:31] <Hello71> and it doesn't work anymore [01:31] <Hello71> well, I get: [01:32] <Hello71> $ ffmpeg -v warning -y -i in.y4m -c:v libx264 -preset slower -tune animation -movflags empty_moov -profile:v baseline -c:a libfdk_aac -vbr 1 out.mp4 [01:32] <Hello71> Codec AVOption vbr (VBR mode (1-5)) specified for output file #0 (out.mp4) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream. [01:48] <Hello71> Encoder did not produce proper pts, making some up. [01:48] <Hello71> what does this message mean? [01:48] <Hello71> I don't care about timestamps. [01:55] <Hello71> same command. [01:56] <llogan> and? [05:00] <Dark-knight> For anyone that cares I just found out that "-c copy" means copy ALL codecs. whereas "-acodec copy" or "-vcodec copy" only copy the audio or video. [05:01] <Dark-knight> i just shortened all my codes [05:01] <Dark-knight> thanks to this [05:02] <Dark-knight> although it doesn't copy subtitles for some reason, but it copys everything else [05:07] <rcombs> subtitles work very differently from audio and video in ffmpeg (though there are plans to change that eventually) [05:07] <Dark-knight> good [05:19] <Dark-knight> whats the command to copy/transfer the subtitles over to the new video [05:22] <klaxa> try -map [05:24] <Dark-knight> just -map? [05:24] <Dark-knight> nothing else? [05:39] <kingsob> I am trying to concat two videos, the 1st one doesn't have any audio, and I can't figure out the correct filter_complex, here is my input and output http://pastebin.com/GSfkWaEC [05:49] <klaxa> i started using the concat demuxer instead lately [05:49] <klaxa> http://trac.ffmpeg.org/wiki/How%20to%20concatenate%20%28join,%20merge%29%20… [05:51] <kingsob> let me give that another try, but I recall having a problem where the audio of the 2nd video would start playing at the beginning of the 1st video [05:51] <klaxa> hmm i haven't had that usecase yet so that might happen [05:52] <Keshl> Why not seproate the audio, add in a period of silence equal to the first video, then put it back, oÉo? [05:53] <kingsob> I got it working by adding a audio stream from /dev/null to the 1st video [05:53] <Keshl> Or dat. -É-. [05:53] <kingsob> but I'd rather not have to deal with the case where a video doesn't have an audio stream if there is a better solution [05:56] <relaxed> there isn't [05:56] <kingsob> http://pastebin.com/iWkDWUex [05:56] <kingsob> that seems to work [05:56] <kingsob> at least its down to a single command :) [05:58] <kingsob> I take it back, the command runs fine, but it looks like its generating me a never ending video [05:58] <relaxed> because /dev/zero is never ending [05:58] <Dark-knight> just ÷ by 0 [05:59] <relaxed> there's -shortest but I don't see how to work that into your current command [05:59] <Keshl> I think there's a command to end when a particular stream ends.. [05:59] <relaxed> you may need two commands [05:59] <relaxed> -shortest [05:59] <Keshl> No, a stream of your choosing, not whichever ends first, oÉo. [06:00] <relaxed> stream selection with -t would be handy [06:00] <kingsob> I assume its doomed anyways, wouldn't the audio always be from /dev/null, sicne its never ending, it wouldn't know when to switch to the 2nd stream [06:00] <Keshl> That was it OÉO I dink OÉO [06:01] <kingsob> II can live with my current solution of adding an audio stream to the video's [06:02] <relaxed> kingsob: like I said, you'll need two commands: use -shortest with the /dev/zero input [06:02] <kingsob> ahh [06:03] <kingsob> yeah didn't realize already doing that [06:03] <kingsob> ffmpeg -ar 48000 -ac 2 -f s16le -i /dev/zero -i intro_640x960.mp4 -shortest -c:v copy -c:a libfdk_aac test.mp4 [06:24] <Dark-knight> can a .mp4 video have a XVID video codec? [06:25] <klaxa> XviD is MPEG-4 Part 2 compliant, .mp4 can hold MPEG-4 Part 2 video streams, so yes [06:26] <Dark-knight> will the .mp4 container be happy about that? [06:26] <klaxa> why should it be sad about it? [06:26] <Dark-knight> or would mpeg4 be better [06:26] <Zeranoe> How could I calculate the actual displayed WxH in pixels if I know the SAR, DAR and resolution? [06:27] <Dark-knight> what is better for .mp4 a XVID codec or a MPEG4 codec? [06:27] <klaxa> Dark-knight: the mp4 container should happily take xvid streams [06:27] <klaxa> when in doubt, try both [06:27] <Dark-knight> what is the default for .mp4? [06:28] <Zeranoe> Dark-knight: H.264 [06:28] <Dark-knight> is H.264 mpeg4 or xvid? [06:29] <Zeranoe> No, it's AVC [06:29] <Dark-knight> avc? [06:29] <Zeranoe> Dark-knight: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC [06:29] <Dark-knight> so it is mpeg4 [06:29] <Zeranoe> Not in the way your thinking [06:29] <Dark-knight> but it is [06:29] <klaxa> H.264 is MPEG-4 Part 10 [06:30] <klaxa> xvid and mpeg4 are MPEG-4 Part 2 [06:30] <Dark-knight> ughh [06:30] <Dark-knight> so confused [06:31] <klaxa> well instead of asking specific questions without context, what is your usecase exactly? [06:32] <Dark-knight> ffmpeg -i input.avi -c:v mpeg4 -c:a aac output.mp4 [06:32] <Dark-knight> i was wondering what i could type instead of -c:v mpeg4 [06:32] <klaxa> what do you want to achieve? [06:32] <Zeranoe> Dark-knight: libx264 [06:32] <Dark-knight> like what other video codecs would be a better choice [06:32] <klaxa> generally yes [06:33] <Zeranoe> Dark-knight: https://trac.ffmpeg.org/wiki/x264EncodingGuide [06:33] <klaxa> libx264 is probably the best in terms of quality per filesize [06:33] <Dark-knight> i don't care how big the file is, all i care about is quality [06:34] <Zeranoe> Dark-knight: Try x264, -crf 20 to -crf 23 [06:34] <Dark-knight> whats that? [06:34] <Dark-knight> -crf? [06:34] <Zeranoe> Dark-knight: Constant quality, read the link about crf [06:36] <Dark-knight> is x264 like 1080p? [06:36] <Dark-knight> or better? [06:37] <klaxa> wha- [06:37] <Zeranoe> 1080p is a resolution [06:37] <Dark-knight> like i said, im new to this [06:37] <Zeranoe> p, for progressive, 1080 resolution [06:37] <Zeranoe> x264 can encode to 1080p, but then again so can mpeg4 [06:37] <Dark-knight> does x264 affect resolution? [06:37] <Dark-knight> ok [06:38] <Zeranoe> x264 is your encoder, it compresses the video. The resolution is another topic [06:38] <Dark-knight> if the input video isn't 1080p then the output can't be encoded to 1080p can it? [06:38] <Zeranoe> it can, you can resize up [06:39] <Dark-knight> how wouldn't that degrade the quality? [06:39] <Zeranoe> keep in mind the p is for progressive. When talking about the resolution you mean 1920x1080 [06:39] <Dark-knight> sure [06:40] <Dark-knight> really nice graphics is what i meant [06:41] <Zeranoe> transcoding/encoding/converting all will degrade quality. Other than -crf 0 which is lossless [06:41] <Zeranoe> not advised to do -crf 0 fyi, because 'Consider 18 to be visually lossless or nearly so' [06:42] <klaxa> well that highly depends on the other parameters chosen [06:42] <klaxa> and it really depends on the source material [06:43] <Zeranoe> klaxa: I just copied that from the Wiki [06:43] <klaxa> ah [06:43] <klaxa> well yeah generally it's not wrong [06:44] <Dark-knight> if the input video is 360p can the output video be 1080p? [06:44] <klaxa> yes but it will look bad [06:44] <Dark-knight> i mean exactly what im asking [06:44] <Dark-knight> ok how bad? [06:44] <klaxa> worse than the 360p input [06:44] <klaxa> you cannot encode lossy without losing quality [06:45] <klaxa> that's why it's called "lossy" [06:45] <klaxa> you cannot magically increase the quality of a video [06:45] <Dark-knight> if i can make a 60x60 picture turn into a high quality 1920x1080 picture why can't i do the same with a video? [06:45] <klaxa> what? [06:45] <klaxa> show me how you do that [06:45] <Zeranoe> ENHANCE http://www.youtube.com/watch?v=Vxq9yj2pVWk [06:46] <Zeranoe> Dark-knight: maybe if it's a solid color, or your talking about inches/cm [06:46] <ProducerSeal> ok umm [06:47] <ProducerSeal> is lossless raw [06:47] <ProducerSeal> or jsut a name [06:47] <ProducerSeal> my friend was being a bich about it [06:47] <Zeranoe> it is, but there might be better options [06:47] <ProducerSeal> lossless is not a format is it [06:47] <ProducerSeal> just means raw stream right [06:47] <Zeranoe> no, but dumping to raw isn't generally the best move [06:48] <ProducerSeal> nono im jus asking [06:48] <ProducerSeal> what is lossless [06:48] <ProducerSeal> is it a format? [06:48] <Zeranoe> no, its a compression type [06:48] <klaxa> lossless is a type of codec [06:48] <klaxa> raw is a lossless "codec", a lossless codec is not neccessarily raw though [06:48] <ProducerSeal> dafuq [06:49] <klaxa> x264 has a lossless mode for encoding [06:49] <Zeranoe> basically it means you aren't losing any quality, data wise [06:49] <klaxa> the result is lossless, it is not raw though [06:49] <klaxa> like... [06:49] <klaxa> when you have a text-file [06:49] <ProducerSeal> ok ill jus tell him [06:49] <klaxa> and compress it with zip [06:49] <Zeranoe> lol [06:49] <klaxa> it's lossless compression [06:49] <klaxa> but it's not raw, is it? [06:49] <ProducerSeal> omfg [06:49] <ProducerSeal> now were both confiz [06:50] <Dark-knight> what is raw? [06:50] <Zeranoe> hes explaining it in abstract terms... [06:50] <klaxa> i'm trying to dumb it down [06:50] <Dark-knight> lol JK [06:50] <ProducerSeal> i kno wat im saying [06:50] <ProducerSeal> losless is not compresed [06:50] <Zeranoe> raw is raw data, it's lossless in nature, but it isn't the definition of lossless [06:50] <klaxa> lossless can be compressed [06:50] <ProducerSeal> but he said its a compressed [06:50] <ProducerSeal> oh [06:51] <ProducerSeal> wait [06:51] <ProducerSeal> how can lossles be compresed [06:51] <Zeranoe> like zip [06:51] <Zeranoe> or 7z [06:51] <ProducerSeal> then its not losles [06:51] <Zeranoe> no... your rearranging the data, not removing any [06:51] <ProducerSeal> well dun even bring up zip [06:51] <ProducerSeal> lol [06:51] <ProducerSeal> ya exactly [06:51] <ProducerSeal> lossless is raw [06:51] <ProducerSeal> cant be compresed [06:52] <klaxa> WTF NO [06:52] <klaxa> no no no no no [06:52] <ProducerSeal> no [06:52] <Zeranoe> raw is a form of lossless [06:52] <ProducerSeal> he said zip [06:52] <ProducerSeal> zip doesnt count [06:52] <ProducerSeal> im talking about video audio compresion [06:52] <Zeranoe> you clearly don't understand the concepts here [06:53] <Zeranoe> ProducerSeal: read up: http://en.wikipedia.org/wiki/Lossless_compression [06:53] <ProducerSeal> no i did [06:53] <ProducerSeal> thats the problem [06:53] <klaxa> ProducerSeal: please run: ffmpeg -codecs | grep -E "^ ..V..S" [06:53] <Zeranoe> you didnt [06:54] <klaxa> it will list all video codecs that support lossless encoding [06:54] <klaxa> which are compressed [06:54] <klaxa> and lossless [06:54] <klaxa> compressed and lossless are not mutual exclusive [06:54] <klaxa> flac audio is lossless [06:54] <klaxa> tta audio is lossless [06:54] <klaxa> ffv1 video is lossless [06:54] <klaxa> huffyuv is lossless [06:54] <ProducerSeal> right [06:54] <ProducerSeal> which means lossless is raw [06:54] <Zeranoe> so what is lossless? [06:54] <Keshl> No. [06:54] <klaxa> NO [06:55] <ProducerSeal> yes [06:55] <klaxa> NO NO NO [06:55] <Zeranoe> oh god [06:55] <klaxa> LOSSLESS IS NOT RAW [06:55] <Keshl> Mind if I explain this to him? [06:55] <Keshl> *God [06:55] <ProducerSeal> i told u [06:55] <Keshl> I think I can. <É< [06:55] <klaxa> ProducerSeal, if you are just trolling you can just leave [06:55] <ProducerSeal> gzip compresion doesnt count [06:55] <Zeranoe> hes trolling [06:55] <ProducerSeal> gzip compresion doesnt count!!!!!!!!!! [06:55] <ProducerSeal> i told u [06:55] <ProducerSeal> god damit [06:55] <Keshl> *God [06:55] <Keshl> And yeah, nevermind, you're right. [06:55] Action: Keshl pawwaves ProducerSeal away and resumes doing STUFF. -É-. [06:55] <ProducerSeal> ill jus tel my frind he is a idiot [06:56] <ProducerSeal> and ill tel him that he is talking about compression that doesnt even mater [06:56] <Zeranoe> yeah, because clearly you understand this more than him [06:56] <klaxa> obviously [06:56] <ProducerSeal> unless ur talking about actualy codec comrpesion [06:56] <Dark-knight> lol i understood it better then him [06:56] <klaxa> ProducerSeal, just leave please [06:56] <klaxa> if you are unable to understand [06:56] <klaxa> stop wasting our time [06:56] <Zeranoe> trolls arent too smart [06:57] <Dark-knight> hahaha [06:57] <another> what klaxa said [06:57] <klaxa> you are showing no will to learn where you are wrong [06:57] <ProducerSeal> ok Zeranoe [06:57] <klaxa> all you are trying to do is to prove your friend wrong [06:57] <klaxa> even though he is right [06:57] <klaxa> so just go away [06:57] <ProducerSeal> wats the diff then between compression of video and compresion like zip [06:58] <Zeranoe> ProducerSeal: You need to be more specific [06:58] <ProducerSeal> right [06:58] <ProducerSeal> u see how idiotic this is now? [06:58] <klaxa> Zeranoe, why are you even responding? [06:58] <another> zip is a lossless codec. you don't lose data [06:58] <Dark-knight> its called a boot to the face. [06:58] <Dark-knight> BEGONE NAVE [06:58] <ProducerSeal> ya exactly [06:58] <ProducerSeal> which is why u need diff words for each [06:59] <ProducerSeal> coz most ppl dont get into the details [06:59] <ProducerSeal> they jus yap about lossless [06:59] <klaxa> *YOU* don't get into the details [06:59] <another> different word for what? [06:59] <klaxa> i listed about 5 codecs which provide lossless encoding for video and audio [06:59] <re-G_> I think that _real_ lossless can be decoded and you will get the original file (wav->flac->wav), but H.264 lossless mode is _visually_ lossless, not real. Am I right? [06:59] <klaxa> you said those are raw [06:59] <Zeranoe> Anyway, anyone know how to calculate the displayed pixels if I know the DAR, SAR, and res of the video? [06:59] <klaxa> you are obviously stupid [06:59] <Keshl> re-G_: Depends. [06:59] <Keshl> re-G_: h.264 has a real lossless mode (Set -crf 0) [06:59] <klaxa> re-G_: x264 lossless is true lossless [07:00] <klaxa> there is no "false lossless" [07:00] <ProducerSeal> Keshl, yes we know [07:00] <ProducerSeal> gah [07:00] <Keshl> re-G_: However, you can make it /visually/ lossless instead too. Generally -crf 18 is considered that. [07:00] <klaxa> there is either lossless or lossy [07:00] <Keshl> But of course, "visually" depends on the person looking at it. [07:00] <ProducerSeal> ya i kno [07:00] <ProducerSeal> i was teling them [07:00] <ProducerSeal> that zip compresion doesnt count [07:00] <ProducerSeal> wen talking about video [07:01] <Zeranoe> It's weird because ffplay is outputting a pretty weird size [07:01] <klaxa> Zeranoe: http://forum.doom9.org/showthread.php?t=106656 [07:01] <another> oh god [07:01] <Zeranoe> but I guess with such different dar and sar it's bound to happen... [07:01] <klaxa> maybe that helps? [07:01] <Keshl> And it does compress.. "Fairly" well. Depends a lot on content, obviously. [07:01] <ProducerSeal> no im saying if ur not losing quality [07:02] <ProducerSeal> just to say ur compressing coz ur a nerd [07:02] <ProducerSeal> ? [07:02] <Zeranoe> klaxa: Do you know if ffplay outputs 1:1? [07:02] <Keshl> *God -- Regardless, re-G_, point is H.264 does have a truebluestew lossless mode. Just don't expect your computer to be able to play it. XD [07:02] <klaxa> explain 1:! [07:02] <klaxa> *1:1 [07:02] <ProducerSeal> wen i talk about compresin media im talking about lossy [07:02] <ProducerSeal> end of story [07:02] <re-G_> Keshl: haha, ok :D [07:02] <Dark-knight> hey seal is your connection getting choopy? [07:02] <ProducerSeal> lossless compression is just a fkn idiocy [07:02] <Zeranoe> klaxa: When the video pops up, is it displaying the actual size? or does it get resized in the process somehow [07:02] <ProducerSeal> its pointless to even bring that up [07:02] <klaxa> ProducerSeal: explain that to all the audiophiles, kthxbai [07:03] <ProducerSeal> its pointless to even bring that up [07:03] <ProducerSeal> comon [07:03] <Dark-knight> hey seal is your connection getting choppy? [07:03] <klaxa> Zeranoe: it should display it in the correct size [07:03] <klaxa> if your window manager doesn't interfere or something [07:03] <klaxa> the default window size should be the correct rendering size [07:04] <Zeranoe> so 720x480 [SAR 8:9 DAR 4:3] is actually 640x360? [07:04] <another> ProducerSeal: ok. so don't use zip, gzip, bz2, xz, rar, flac, etc. anymore [07:04] <klaxa> well let's try to do some math [07:04] <ProducerSeal> omfg dood [07:04] <ProducerSeal> stop [07:05] <ProducerSeal> u know what i said [07:05] <klaxa> we have 720x480 samples [07:05] <ProducerSeal> saying ur lossless has compression on it is fkn tarded [07:05] <klaxa> wait... hmm... [07:05] <klaxa> this won't work... [07:05] <ProducerSeal> and u sound like a fkn idiot [07:05] <klaxa> ProducerSeal: just fuck off already [07:05] <klaxa> seriously [07:05] <ProducerSeal> ya duh its a fkn computer format [07:05] <Dark-knight> his ip is 108.184.154.132 [07:06] <Dark-knight> just ping it [07:06] <ProducerSeal> obviously its gona be fkn algoed [07:06] <Keshl> Why not jus' add him to /ignore? oÉo? When he stops getting attention he'll go away. -É-. [07:06] <another> ProducerSeal: stop talking 'bout things you don't understand [07:06] <ProducerSeal> i do understand fool [07:06] <ProducerSeal> im trying to explain to you [07:06] <ProducerSeal> do u not get it? [07:07] <Zeranoe> klaxa: ffplay displays it with that res, something like MPC is a different res [07:07] <Dark-knight> ProducerSeal do you live in budapest? [07:07] <klaxa> huh? that is weird [07:07] <klaxa> is mpc not using libav*? [07:07] <Zeranoe> umm [07:07] <Zeranoe> i think so [07:08] <Zeranoe> MPC is 853x480 [07:09] <Keshl> o.O' Using H.264? I thought that didn't support odd numbers.. [07:09] <klaxa> according to the thread on doom9, mpc will be using a different SAR then [07:09] <klaxa> the thread i linked actually explains exactly that [07:09] <Zeranoe> Keshl: mpeg2video [07:09] <Keshl> Ohhh. -É-. [07:09] <klaxa> if you have a video sorce with 720x480 with SAR 8:9 it will result in a 4:3 video [07:10] <klaxa> with SAR 32:27 it will be 16:9 (which is roughly 853x480) [07:10] <klaxa> oh yeah that makes sense [07:10] <klaxa> divide 720 by 9 [07:11] <klaxa> then multiply by 8 [07:11] <klaxa> you get 640 [07:11] <Zeranoe> so ffplay is right? [07:11] <klaxa> probably [07:11] <Zeranoe> it seems small... [07:11] <klaxa> does the video look distorted in any player? [07:12] <klaxa> if so, the distorted one is probably wrong [07:14] <Zeranoe> it looks fine in both, just smaller in ffplay. plus it can't be that resolution in ffplay, without some scaling [07:14] <Zeranoe> but thats what it pops open as [07:14] <Dark-knight> hey ProducerSeal you live at 4188 Oak Pl Dr. right? [07:14] <klaxa> is the aspect ratio the same? [07:14] <Dark-knight> ill send a card [07:14] <klaxa> Dark-knight: knock it off pleas [07:14] <klaxa> *please [07:14] <Dark-knight> am i not allowed to dox in her? [07:15] <Dark-knight> here* [07:15] <klaxa> no [07:15] <Dark-knight> awww [07:15] <Dark-knight> no fun [07:15] <Dark-knight> fine ill obay [07:15] <klaxa> what's with all the skiddies tonight? [07:15] <ProducerSeal> ill beat ur fkn ass [07:15] <ProducerSeal> fkn snitch [07:15] <ProducerSeal> faget [07:15] <Dark-knight> lol [07:15] <relaxed> why don't I have ops in this channel yet? [07:15] <ProducerSeal> the internet age [07:15] <klaxa> relaxed: i wish i knew [07:16] <ProducerSeal> breeding a bunch of snich fagets [07:16] <klaxa> could use some ops for days like this [07:16] <ProducerSeal> come get it queef [07:16] <klaxa> then again, pretty rare [07:16] <Zeranoe> klaxa: Yeah, aspects are both 16/9 [07:16] <klaxa> huh [07:16] <ProducerSeal> ill fkn hang u from that fkn power cord [07:17] <Dark-knight> good bye seal, enjoy your ban [07:17] <relaxed> Zeranoe: what does ffmpeg report as the SAR for both video? [07:17] <klaxa> oh right 640x360 is 16:9 all right [07:17] <Zeranoe> creeps me about a little that you found his address... [07:18] <klaxa> Zeranoe: it's probably just his ISPs address... [07:18] <Zeranoe> relaxed: both? its the same [07:18] <relaxed> which would be...? [07:18] <Zeranoe> 720x480 [SAR 8:9 DAR 4:3] [07:18] <Dark-knight> lol no klaxa that IS his address, why else would he get so mad? [07:19] <relaxed> Dark-knight Zeranoe please stop this offtopic garbage [07:19] <Dark-knight> ok sorry [07:19] <Zeranoe> ? [07:19] <klaxa> well like i said according to the thread that video should actually be 640x480 [07:19] <relaxed> the dar is probably wrong on one of the videos [07:20] <relaxed> SAR = DAR*(H/W) [07:20] <Zeranoe> relaxed: But MPC gets it right? [07:21] <relaxed> sometimes both the video stream and container can have this info, and be different [07:25] <Zeranoe> so don't trust ffplay? [07:25] <i336_> oookay.... google isn't being helpful right now... how do I specify the output soundcard in ffplay? (not ffmpeg) [07:25] <i336_> as in, for audio output :P [07:26] <relaxed> maybe using some SDL variable? [07:26] <i336_> O.o [07:26] <i336_> does ffplay use SDL for audio out? interesting [07:27] <relaxed> and video [07:27] <i336_> oh ok [07:28] <Zeranoe> relaxed: Are you a dev? [07:28] <relaxed> Zeranoe: you should file a bug report if ffplay doesn't behave correctly. [07:29] <relaxed> Not really, I have a handful of patches in. [11:26] <Keestu> join #libav [11:30] <Mavrik> hmm, does FLV support timestamp wrap? [11:34] <JEEB> the specification isn't too long, you could check [11:35] <JEEB> http://download.macromedia.com/f4v/video_file_format_spec_v10_1.pdf [11:35] <JEEB> it begins with f4v, and then the latter part is FLV [11:37] <bais> hi I'm using Linux Encoding install.sh and I have a problem [11:37] <bais> when I try to convert an x264 video it said Unknown encoder 'libx264' [11:43] <Mavrik> JEEB, I seem to be totally incompetent at Google for not finding that doc -_- [11:43] <Mavrik> thanks [11:44] <Keshl> bais: You gotta compile with --enable-x264. That's all I know, though. Anything about how to actually compile is beyond me. xwx [11:46] <bais> Keshl: thx I will try [11:46] <JEEB> Mavrik, but as far as I can see, it's a 0-UI24+UI8 timestamp value , the specification is rather silent about wrapping [11:46] <bais> in this moment: ==> build_libx264() Running make && make install :) [11:46] <JEEB> as in, going back to 0 [11:47] <JEEB> Mavrik, might want to ask fileformat(a)adobe.co [11:47] <JEEB> *com [11:47] <bais> I'm trying to use it on a youtube-like php portal called clipbucket [11:47] <Mavrik> mhm [11:47] <Mavrik> anyway, ffmpegs flv muxer chokes :) [11:49] <JEEB> well, lavf used to not support AAC with !44.1kHz audio rate at one point :P [11:49] <JEEB> of course timestamp wrapping /will/ make lavf barf for seeking and stuff [11:49] <JEEB> but that's the same thing for mpeg-ts as well [11:49] <JEEB> just ask adobe [11:49] <JEEB> and see what they respond [14:27] <troulouliou_dev> hi can somebody point me to a small easy exemple of opening an audio stream in raw and seek/pos .. in it like in a file ? [14:29] <JEEB> see the examples under docs [14:29] <JEEB> there's a demuxing/decoding example [14:30] <JEEB> then just look at the doxy for the libavformat seeking part [14:31] <troulouliou_dev> JEEB, yeah was in that direction atm :) thanks [14:37] <Oxymoron> Hey guys, anyone have experience with flv's? I'm using an avisynth script to join 2 videos together to form a video conversation, but unfortunately they get out of sink eventually. Any way to be sure things stay lined up? [14:37] <Oxymoron> So initially i start them with offsets that are stored in the DB at the time of publishing the streams, and it looks fine, but 10-15 mins into playback one video will wander ;( [14:38] <Oxymoron> brb [15:43] <bais> is it possible, with 1 line of syntax, create 3 different output? like low medium high files [15:43] <bais> other thing: I have this problem atm: http://pastebin.com/czUEV5JD [15:44] <Keestu> hello, i have a question about size of packet and complete frame. is it correct to think in such a way that sum(all packets size) = size (complete frame?) [16:24] <Rural> Why does the following generate out-of-sync audio? avconv -f alsa -ac 2 -i pulse -r 15 -f x11grab -i :0.0 -acodec flac -vcodec libx264 -preset ultrafast -crf 0 -threads 0 output.mkv [16:25] <Rural> If just leave the framerate at the default, the audio is sync'd. [16:27] <Rural> Here is the output from 'avconv -version': http://pastebin.com/k2BCLKzG [16:29] <Rural> I get around the issue by doing the initial capture at the default frame rate, then reencode to my distribution format and framerate in second pass. But if there is a bug here, it might be harder to work around for others. [16:36] <JEEB> just gonna note that avconv doesn't come from the FFmpeg project, but the Libav project, as the copyright says :) ( #libav ) Also, I think there was a separate frame rate setting [16:36] <JEEB> you're just forcing the input to be read as 15fps [16:36] <JEEB> -framerate it seems [16:37] <JEEB> although the documentation for x11grab notes usage with -r :s [16:46] <Rural> JEEB: Oops! Thanks for pointing those two things out. [16:48] <lkiesow> What is the easiest way of getting a list of all frames selected by a select filter? [16:49] <lkiesow> Atm I'm blacking them out and then run the blackframe filter [16:49] <troulouliou_dev> hi does anybody know a good tuto to raw copy an audio track from a matroska file to a file; [16:50] <troulouliou_dev> i need only the cluster block data; not any metadata [18:01] <rsdrsdrsd> Can someone help me on this issue: http://pastebin.com/NGxPWzyX [18:07] <eurobit> can ffmpeg insert a piece of clipart over a videa [18:20] <durandal_1707> eurobit: see overlay filter [18:25] <rsdrsdrsd> is it normal that when making every 10 seconds a screenshot of a video it gets in a loop and it makes 10000 of it? [18:28] <durandal_1707> rsdrsdrsd: select filter should be better [18:34] <rsdrsdrsd> ok i'll look into that one [18:38] <rsdrsdrsd> but I need it every 10 seconds because I want to build an vtt file with screenshots every 10 seconds [18:39] <durandal_1707> have you read documentation of select filter? [18:43] <rsdrsdrsd> I am trying to do so [18:45] <eurobit> thanks durandal_1707 [18:45] Action: eurobit thinks that is one huge man page ;) [18:47] <durandal_1707> there are some example on trac.ffmpeg.org/wiki [18:48] <rsdrsdrsd> so vf select="not(mod(n\,10*fps))" should do the magic ;-) [18:54] <rsdrsdrsd> why does the wiki say something else? [18:58] <durandal_1707> no, but it have same examples and images .... [19:00] <rsdrsdrsd> is the fps variable available in the function or do I have to calculate it myself? [19:07] <durandal_1707> you do not need fps [19:07] <durandal_1707> use timestamp [19:16] <eurobit> rsd*3 do you do ffmpeg for a living? [19:21] <OnkelTem> Hi all. I try to follow this guide https://encrypted.pcode.nl/blog/2010/10/17/encoding-webm-using-ffmpeg/ to transcode a screencast video created with the same ffmpeg to WEBM [19:22] <OnkelTem> but what I get is just a small file with no video [19:23] <klaxa> i think vpre is outdated [19:23] <klaxa> also pastebin your complete input with the complete console output [19:24] <OnkelTem> http://pastebin.com/t4ce4rEM [19:24] <klaxa> barely anyone does two-pass encodes anymore too [19:24] <klaxa> that's not the output of ffmpeg [19:24] <OnkelTem> oh, sorry [19:26] <OnkelTem> klaxa: http://pastebin.com/SKiyKpVa [19:27] <OnkelTem> (btw, what does it mean "this program is deprecated"? does it mean ffmpeg itself?) [19:27] <klaxa> it means the binary shipped with debian and debian based distributions [19:27] <klaxa> with the libav package [19:27] <klaxa> or rather the avconv package [19:27] <klaxa> that being said, the support channel for avconv is #libav [19:28] <Oxymoron> I'm trying to convert an flv to h264 mp4 with strange results. Using avi synth and DirectShowSource I get audio that doesn't syncronize with the video. Has anyone come across this before? [19:28] <OnkelTem> Thank you [19:28] <klaxa> the version you are using is also very outdated [19:31] <OnkelTem> klaxa: I've updated to 0.10.11 from this ppa https://launchpad.net/~jon-severinsson/+archive/ffmpeg?field.series_filter=… [19:32] <klaxa> the current version is 2.1 [19:32] <OnkelTem> oops [19:32] <klaxa> you can get one of those [19:32] <klaxa> wait no... [19:32] <OnkelTem> here is the output: http://pastebin.com/DPpiSavV [19:33] <klaxa> those don't support x11grab [19:33] <OnkelTem> In this particular case I'd like to not rerecord the video. [19:34] <OnkelTem> It's strange the versions are so different. Maybe they concern different packaging? [19:34] <klaxa> well for starters try this: ffmpeg -i video.mpg -s 1280x760 -c:v libvpx video.webm [19:35] <klaxa> or rater skip the -s part entirely too [19:36] <OnkelTem> huh, would glad to! [19:36] <klaxa> actually... [19:36] Action: OnkelTem hates outdated blog posts [19:36] <klaxa> the input has audio, right? [19:36] <klaxa> do you want to preserve that? [19:36] <klaxa> if so, just try to run: ffmpeg -i video.mpg video.webm [19:37] <OnkelTem> right. My first command was to not include audio just for testing. With your suggested command audio seems to be preserved (vorbis) [19:37] <klaxa> that should select the correct default values for codecs and quality [19:37] <klaxa> if you are unsatisfied with the result we can tweak it to increase or decrease quality [19:38] <OnkelTem> klaxa: it works. And you are right, I'd like to increase video q :) [19:41] <klaxa> you can try to use the flag -quality which works with the libvpx encoder [19:41] <klaxa> so: ffmpeg -i video.mpg -quality best video.webm [19:42] <klaxa> if you run ffmpeg --help encoder=libvpx it will show all available options for libvpx [19:43] <klaxa> i'll be afk for a while [19:43] <OnkelTem> klaxa: I see, good! [19:52] <llogan> OnkelTem: http://trac.ffmpeg.org/wiki/vpxEncodingGuide [20:19] <Nosomy> have the way to cut a piece of video using ffmpeg and copy a video? [20:39] <rsdrsdrsd> eurobit why ar e you asking that? [20:47] <rsdrsdrsd> still not a working solution to select an image every x seconds using the select filter [20:48] <rsdrsdrsd> can somebody maybe explain how to do it using timestamps? [20:48] <rsdrsdrsd> is it the BT optionin the select filter and how to implement it [20:59] <Zeranoe> Does AAC have a max bitrate? like 320k for MP3? [21:03] <Oxymoron> Speaking of, it takes forever to encode my flv to h264, what's a lower acceptable bitrate? Now I'm setting to vid 512k, audio 48k. Also, will this speed up the process? [21:04] <sacarasc> Using a faster x264 preset will make it go faster, too. [21:05] <OnkelTem> Does anybody know how to increase volume of the audio in a WEBM video? [21:07] <llogan_> Nosomy: ffmpeg -ss 12 -i input -t 30 -codec copy -map 0 output [21:07] <JodaZ> OnkelTem, oh come on, that should be easy to google, use the volume audio filter: -af volume=2.0 [21:08] <llogan> http://ffmpeg.org/ffmpeg-filters.html#volume [21:08] <Zeranoe> Does AAC have a max bitrate? like 320k for MP3? [21:09] <JodaZ> i don't think going over 320k makes sense, you'd use lossless by then [21:09] <Zeranoe> I agree, but http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=13&t=1780 [21:09] <brontosaurusrex> Zeranoe, i don't think so [21:11] <brontosaurusrex> well, every lossy encoder will get saturated at some point [21:11] <OnkelTem> JodaZ: it says: Unrecognized option 'af' [21:12] <JodaZ> OnkelTem, then your ffmpeg is too fuckin old oO [21:12] <OnkelTem> JodaZ: one search result http://trac.ffmpeg.org/wiki/How%20to%20change%20audio%20volume%20up-down%20… [21:12] <OnkelTem> JodaZ: damnit. I wish to update [21:12] <JodaZ> OnkelTem, it is easy, you can just download a static build [21:12] <llogan> or you're not using ffmpeg but some shit from a fork [21:13] <Zeranoe> OnkelTem: What OS are you on [21:13] <JodaZ> the shit of a fork is sadly lacking in filters, but it has the -af option [21:14] <OnkelTem> llogan: most likely. I'm on Ubuntu 12.04 and had updated ffmpeg from a PPA which claims it provides newer ffmpeg. Well, it really updated ffmpeg, from 0.8.x to 0.10.x [21:14] <llogan> Zeranoe: just tell him "bitrate=file size/duration" and he can find out himself if he doesn't want to look at the code or the specifications. [21:14] <JodaZ> OnkelTem, i am just using this http://johnvansickle.com/ffmpeg/ [21:14] <JodaZ> OnkelTem, Zeranoe also has some [21:14] <llogan> OnkelTem: the 0.10 branch is considered old [21:15] <Zeranoe> For Windows [21:15] <JodaZ> oh, didn't notice that [21:17] <OnkelTem> JodaZ: what OS are you on? I'm getting static build you have linked [21:17] <OnkelTem> Or rather, how to "install" it? Just copy binaries to /usr/local/bin? [21:17] <llogan> download, extract, execute. [21:17] <llogan> ./ffmpeg -i input output [21:17] <OnkelTem> ok [21:17] <JodaZ> OnkelTem, i am running debian wheezy, i don't even copied the binary anywhere and am just running it from where it is ./ffmpeg [21:18] <JodaZ> OnkelTem, but i guess you can copy it somewhere to your path if you like [21:18] <OnkelTem> thanks. Ok. [21:18] <llogan> if you want you can move it somewhere in your PATH [21:19] <OnkelTem> if it doesn't depend on hunderds of other files somewhere in the system - it's ok :) [21:19] <Nosomy> llogan, have a way to do a cut specifying frames? like --seek and --frames of x264? [21:19] <llogan> i'm not sure what uses the binary directly and what accesses the binary via your user's PATH as compared to using the full path to the binary. [21:20] <llogan> Nosomy: you can output a number of frames with -vframes or -frames:v [21:20] <llogan> there is also the select filter if you want a more advanced option [21:20] <Nosomy> thanks... [21:21] <JodaZ> does anyone know why i get a stop/pop in the sound if i concatenate two .ts files? [21:22] <JodaZ> llogan, i think i might post to the forums, the commands are slightly complicated [21:22] <llogan> that's what pastebin is for [21:22] <llogan> and which forums? [21:22] <JodaZ> the one mentioned in the topic [21:23] <llogan> oh. usually that's just me and burek answering anyway. [21:23] <llogan> you can use wahtever you prefer [21:29] <JodaZ> llogan, http://pastebin.com/DvM37nBe [21:30] <llogan> you're missing the console outputs [21:30] <JodaZ> they aren't relevant, theres no warnings/errors [21:30] <JodaZ> (also depend on how many of the debugging options i keep in) [21:30] Action: llogan moves on to other ffmpeg questions with console outputs [21:31] <JodaZ> llogan, sure, i'll paste em if you enjoy them [21:35] <JodaZ> llogan, http://pastebin.com/2XVASyM2 [21:40] <JodaZ> llogan, any idea? [22:59] <MDTech-us_MAN> hello [22:59] <MDTech-us_MAN> I need to convert a wma file to mp3 [23:03] <rsdrsdrsd> I have a problem with the following issue: http://pastebin.com/m5LkVEh3 [23:03] <rsdrsdrsd> I want to check the video by copying the bitstreams [23:03] <MDTech-us_MAN> when I execute "04 Track 4.wma" -acodec mp3 output.mp3" I get bit depth more then 16 not implemented [23:03] <MDTech-us_MAN> what do I do? [23:04] <rsdrsdrsd> but the command reduces the video to a very small size [23:04] <rsdrsdrsd> it also returns the error av_interleaved_write_frame(): Invalid argument [23:05] <MDTech-us_MAN> to be exact: Bit-depth higher than 16 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [23:05] <MDTech-us_MAN> I executed "ffmpeg -i "04 Track 4.wma" -acodec mp3 output.mp3" [23:15] <rsdrsdrsd> really weird problem [23:16] <rsdrsdrsd> if I issue the copy command it cuts the video from 600mb to 2mb and strips a lot of data off [23:17] <Dark-knight> does it still work? [23:18] <rsdrsdrsd> yes [23:18] <Dark-knight> then what is the problem? [23:19] <rsdrsdrsd> but only plays 2 seconds or so [23:19] <rsdrsdrsd> total video is 10 minutes or so [23:19] <Dark-knight> ohhh ok [23:19] <rsdrsdrsd> and now it plays just 2 seconds of it [23:19] <Dark-knight> nvm [23:19] <rsdrsdrsd> and size has become much smaller [23:25] <rsdrsdrsd> anyone has a clue? [23:50] <rsdrsdrsd> so doing copy stream over an output file which just was created by also copying the stream results in a corrupt mpeg [00:00] --- Thu Feb 27 2014

1 0

ffmpeg-devel.log.20140225
by burek 26 Feb '14

26 Feb '14

[00:11] <cone-707> ffmpeg.git 03Timothy Gu 07master:774239be7171: ffmpeg_opt: get_preset_file_2(): fix avio_open2() return code check [00:16] <llogan> c91488a may break docs [00:18] <llogan> like ticket 2243 [00:20] <Daemon404> it actually fixes the breakage [00:40] <ramiro> hi, I'm REing some microcontroller code and stumbled upon a function I believe tries to do 24-bit multiplication, but gives an error if the result is over 16-bit. the overflow check seems wrong to me, could anyone else take a look? http://pastebin.com/Vwz8e1Lk [00:41] <Daemon404> PIC code? [00:43] <ramiro> upd7810. old dot-matrix printer [00:44] <Daemon404> 0 -> error i suppose [00:46] <Daemon404> i see what it does, but im not sure what the question is [00:46] <Skyler_> ramiro: 0x1ff * 0xff will overflow, but the if won't trigger overflow, I think [00:46] <Skyler_> because overflow is predicated entirely on the contents of mh, but mh + ml can overflow when mh doesn't [00:46] <ramiro> Skyler_: that's exactly what I was thinking =) [00:47] <Skyler_> looks like a bug. [00:47] <ramiro> maybe I can use the bug to make glitch art with the printer [00:47] <Skyler_> I guess I'd say if(mh&0xff00 || (mh + (ml>>8))&0xff00) would be more correct or something [01:59] <cone-707> ffmpeg.git 03Lukasz Marek 07master:314444000494: lavu/buffer: add release function [08:40] <andrewrk> hi, trac is taking too long to send me an email verification so I am here [08:40] <andrewrk> here is a fix to http://trac.ffmpeg.org/ticket/3383 [08:40] <andrewrk> http://patches.libav.org/patch/47615/ [08:41] <andrewrk> that's going into libav but they had me squash it so that it won't merge cleanly into ffmpeg [09:15] <ubitux> andrewrk: thanks! [09:15] <andrewrk> no problem [09:15] <ubitux> andrewrk: do you mind sending a patch rebased on ffmpeg to ffmpeg-devel mailing list? [09:16] <andrewrk> not a problem. do I need to be subscribed? [09:16] <ubitux> no but if you don't you won't get any feedback (unless you track the archive), and you'll have to wait for moderation [09:16] <andrewrk> ok [09:21] <cone-170> ffmpeg.git 03Janne Grunau 07master:5ea14d48a82a: texi2pod: always declare the pod file as UTF-8 encoded [09:21] <cone-170> ffmpeg.git 03Michael Niedermayer 07master:a8ad7e47fb59: Merge remote-tracking branch 'qatar/master' [09:25] <Zeranoe> I think the way configure is checking for x265 is causing a configure error. Looks like there were two recent patches relating to it: http://git.videolan.org/?p=ffmpeg.git;a=history;f=configure My version is 0.7, and i am unable to configure with it [09:26] <ubitux> Daemon404 ^ [09:27] <ubitux> Zeranoe: the header has X265_BUILD >= 7? [09:28] <Zeranoe> ubitux: I'm testing now, but it should be [09:30] <c10ud> ubitux, can I abuse your patience and knowledge with a quick question about sse and unrelated to ffmeg? if it's inappropriate just say no, no worries [09:31] <ubitux> i'm definitely not a sse expert but feel free to ask here [09:31] <c10ud> alright thanks, I figured where all the AV gurus are would be the better place :))) [09:31] <c10ud> I am trying to learn a bit how to operate with gcc intrinsics and my test code is a simple conversion from 6bytes uyvyyy (yes, Canon's viewfinder data uses this format) to yuyv422. I am fiddling with sse but I can't get my head around how to properly access the 6bytes data :s [09:32] <Skyler_> I suggest lots of pshufb [09:34] <Skyler_> also, wouldn't that be 4:2:0, not 4:2:2? [09:34] <Skyler_> since there's 2 u/v bytes per 4 luma bytes [09:35] <c10ud> hey, I am new in the field, I am just doing: uy1vy2y3y4 -> y1uy2v y3uy4v [09:35] <c10ud> and the image is good [09:35] <c10ud> at least, ffmpeg gets it with -f raw yuyv422 [09:36] <ubitux> c10ud: read 8/16, do your shuffling, then palignr? [09:37] <Skyler_> my standard strategy is shuffle -> punpcklqdq/punpckldq/shufps/similar to combine multiple groups of bytes [09:38] <c10ud> btw- regarding this sse "issue" I dont get how to properly go to the next input bytes: e.g. I read 16 bytes, process 12 of them, then how to tell the pointer to increase only of 12 instead of 16? ofcourse (__m128i *)++ won't do the trick [09:38] <Skyler_> your input pointer should be uint8_t*, not __m128i [09:38] <Skyler_> and you should be doing unaligned loads [09:38] <Skyler_> this is, unfortunately, the most convenient option when your inputs don't divide nicely into 16 bytes [09:39] <c10ud> yea i thought of processing 48 bytes per iteration but, registers :) [09:39] <Skyler_> I suggest doing 24 per iteration if you have 3 bytes per pixel [09:39] <Skyler_> so 2x 12 [09:39] <c10ud> I'll try again now with the uint8_t* but _mm_load_si128 was crashing :x [09:40] <Skyler_> is that the unaligned load intrinsic? [09:40] <c10ud> should be aligned, I'll try loadu now [09:40] <Skyler_> if you're increasing by 12, that's going to be unaligned [09:41] <c10ud> fuck me, it works [09:41] <c10ud> and I must say yesterday I tried loading unaligned etc. but I must have had some other error so I thought I was doing bad things [09:41] <c10ud> :( [09:42] <c10ud> thank you guys, sorry for the noise :) now I can finally play with conversion [09:43] <Zeranoe> ubitux: The only X265_BUILD I'm finding is: '#define x265_encoder_open x265_encoder_glue2(x265_encoder_open_, X265_BUILD)' [09:52] <Zeranoe> Interesting, it's actually in x265_config.h, mine says '#define X265_BUILD 5' but it was built from hg today so it's at least 7. x265.pc reports 'Version: 0.7' so at least that is correct. Perhaps that isn't the safest way to check for the API version? [09:52] <relaxed> Zeranoe: be sure and run "hg pull" and "hg update" in x265's dir [09:53] <Zeranoe> relaxed: Good call, used to git [09:54] <relaxed> yes, I could stab them for not using it too. [09:58] <Zeranoe> Working now, thanks [10:38] <andrewrk> ubitux, submitted [10:39] <andrewrk> ubitux, I subscribed to ffmpeg-devel but it still says awaiting moderator approval [10:40] <ubitux> i guess you'll have to be trusted once [10:40] Action: andrewrk rubs his hands together evilly [10:40] Action: ubitux doesn't know the exact rules [10:40] <ubitux> :) [11:43] <ubitux> http://tech.slashdot.org/comments.pl?sid=4823359&cid=46316735 lol [11:44] <av500> nice [11:44] <J_Darnley> :) The troll got two bites [12:22] <ubitux> https://lists.libav.org/pipermail/libav-devel/2014-February/056409.html anyone to reason Diego? [12:33] <plepere> my FFmpeg-devel thread(s) disappeared ? [12:39] <pross-au> Some one is outta space. [12:39] <ubitux> and here you go, just pushed [12:44] <pross-au> 'The rule "no commits without review" ensures that another set of qualified eyes looks over code prior to commit. Adopting that policy for all developers - maintainers, committers or first time contributors - puts everybody on equal footing.' [12:45] <ubitux> utopy gone wrong [12:45] <plepere> well I'm all for reviewing my code, but I'd like to see feedback on it. :) [12:46] <ubitux> we're not against review [12:46] <ubitux> and guess what, we do some [12:47] <plepere> :D [12:48] <plepere> so my patch submission has to be re-done ? [12:49] <BBB> I'm against cosmetic-only review [12:49] <BBB> it's such an utter waste of brainpower [12:49] <pross-au> its dick flapping what it is [12:49] <BBB> something like that yes [12:49] <iive> and don't forget to sort your variables in alphabetical order! [12:50] <BBB> I believe functional review can truly improve the quality of a patch, and that's where two people working together (which is really what review is) make more than either one alone [12:50] <ubitux> iive: and headers! [12:50] <BBB> cosmetic changes should just be done by someone who likes doing that, and then just don't involve the original coder at all - whether he or the "reviewer" makes the cosmetic changes doesn't matter much [12:51] <BBB> since it doesn't require intelligence or code understanding [12:51] <BBB> it's just monkey-spacebar-pressing [12:51] <BBB> (or sometimes, if you're lucky, enter) [12:51] <nevcairiel> funny enough those monkeys frequently keep breaking code :D [12:51] <ubitux> yeah actually i'd better have someone who knows how to write code before shuffling around spaces [12:52] <BBB> I just updated from mac 10.6.8 to mac 10.9.1, and also Xcode 4.2 to 5.2 [12:52] <BBB> new software once in a while is quite nice [12:54] <plepere> BBB : I'm changing my ASM fuctions to eliminate the width loop. [12:54] <pross-au> plepere: lots of empty 'if (EXERNAL_SSE2(flags) {}' blocks in your patch. are you expected these to come later? [12:55] <plepere> we have a loop_filter in sse2 [12:56] <plepere> it's just not in this patch [12:57] <plepere> BBB : the problem is that I've got a lot of unused pointers. is it ok ? [13:10] <BBB> plepere: what do you mean? [13:10] <BBB> don't tell me you're calling it as dsp->function[width](...) [13:11] <BBB> plepere: you should use some incremental index that has lower resolution (typically you can derive that from block_width * n_partitioning_methods + partitioning_index [13:11] <BBB> or something smaller than that [13:11] <BBB> or make a lookup table that gives index from partitioning and block width [13:11] <BBB> like in vp9, index is log2(block_width) [13:12] <BBB> plepere: or do you mean something else? [13:14] <plepere> BBB : I'm using width / 2 [13:16] <plepere> BBB : it's for a first version at least [13:27] <smarter> plepere: I was planning to submit the loop filter to libav/ffmpeg [13:28] <BBB> plepere: hm... well can you make it a lookup table? [13:28] <smarter> I cleaned it up the other month, but got lazy while reviewing it [13:28] <smarter> I'll try to do that soon [13:28] <BBB> plepere: i.e. try to make a table that indexes all valid widths to an incremental index, and all others to MIN_INT or some other invalid integer (-1?) [13:29] <BBB> smarter: it is assembly, not crazy intrinsics, right? [13:29] <smarter> yes [13:29] <smarter> it's asm :) [13:29] <BBB> \o/ [13:30] <smarter> stseppo wrote it, and he's now doing arm assembly [13:30] <BBB> plepere: so assuming that 2, 4, 6, 8, 12, 16, 24, 32, 48, 64 are valid widths, use static const uint8_t table[65] = { [2] = 0, [4] = 1, [6] = 2, [8] = 3, [12] = 4, [16] = 5, [24] = 6, [32] = 7, [48] = 8, [64] = 9 }; [13:31] <BBB> plepere: and then call the function table as dsp->function[table[width]](..) [13:31] <BBB> it's one more dereference but at least it makes the table normal-size [13:32] <BBB> maybe even make the sizes an enum so their name makes it clear what actual width they're associated with, but only if you care about that (I'm fine with straight numbers) [13:34] <plepere> oh, you're smart, BBB. [13:36] <plepere> thanks [13:47] <cone-170> ffmpeg.git 03Peter Ross 07master:bef6b27f106f: avcodec/vp8dsp: use AV_ZERO64 to clear idct coefficient rows [13:47] <ubitux> ah thanks for this ^ [13:47] <JEEB> all the HEVC talk reminds me that I was thinking if I should ask for extra info on the VUI time_scale thingy [13:48] <JEEB> because currently it isn't AFAIK defined as either frame or field rate [13:48] <JEEB> in AVC it was IIRC field rate [13:48] <JEEB> HM seems to imply it's the frame rate [13:48] <smarter> really? [13:49] <JEEB> we had a quick look with muken [13:49] <JEEB> didn't seem to find any specifics [13:49] <JEEB> which then led to https://github.com/l-smash/l-smash/commit/c7fc06c3cf02ca46b129244034cc643a9… [13:49] <JEEB> "follow HM" [13:50] <smarter> looks like you're right [13:50] <smarter> so maybe the time_base in hevc.c should be changed [13:51] <smarter> I don't know how it's interpreted [13:51] <JEEB> I guess I should ask JCT-VC? [13:51] <JEEB> it really should be specified methinks [13:51] <smarter> probably [13:51] <muken> time_scale / num_units_in_tick does not always represent framerate [13:52] <JEEB> yes, but it should still be defined, no? [13:52] <smarter> so how the hell does ffmpeg decide how to interpret the time_base? :p [13:53] <muken> for instance, let say time_scale = 24, num_units_in_tick = 1, user might have specified fps=24, 12, 8, 6, and so on... [13:54] <muken> time_scale / num_units_in_tick doesnt tell us what fps is intended [13:55] <JEEB> yes, but unfortunately it's too often used as the frame rate >_> [13:55] <muken> time_scale / num_units_in_tick just tell us about the resolution of steam timeline [13:55] <muken> *stream [13:56] <JEEB> yes [13:58] <JEEB> For [13:58] <JEEB> example, when the picture rate of a video signal is 25 Hz, vui_time_scale may be equal to 27 000 000 and [13:58] <JEEB> vui_num_units_in_tick may be equal to 1 080 000, and consequently a clock tick may be equal to 0.04 seconds. [13:58] <JEEB> I will guess since it's a "picture rate" it can be either field or frame rate, depending on the coding mode [14:01] <JEEB> HM can encode interlaced pictures now, right? [14:18] <cone-170> ffmpeg.git 03Hendrik Leppkes 07master:fa84231ee8f3: mpegvideo: fix overwriting hwaccel surface objects [14:18] <cone-170> ffmpeg.git 03Hendrik Leppkes 07master:bc249bd6736f: mpegvideo: re-indent buffer clearing code [15:54] <ubitux> JEEB: so, what's a bit stream, i'm not sure i understand ;) [16:21] <Daemon404> Zeranoe, did you ever get it worked out? [16:35] <ubitux> http://www.mplayerhq.hu/design4/news.html over on the tux; is that the "cola" joke? :P [16:35] <ubitux> hover* [16:36] <Daemon404> ubitux, im more interested in that design [16:36] <Daemon404> the best 1998 had to offer? [16:36] <ubitux> design7 to jump in the future [16:36] <Daemon404> 'future' [16:37] <Daemon404> that designs been around for like 10 year [16:37] <Daemon404> i swear [16:37] <Daemon404> -s [16:37] <ubitux> it was slightly ironic ;) [16:37] <Daemon404> ;p [16:38] <ubitux> but well, it has some little charm :) [16:39] <ubitux> i actually like the style of that site [16:40] <ubitux> design3 is nice too [16:40] <ubitux> 5 as well [16:40] <ubitux> there is quite some work on the logo [16:41] <saste> hi [16:42] <saste> i was off in the last two weeks [16:42] <saste> did i miss something important (apart gsoc reject)? [16:44] <ubitux> saste: aca working on getting ffmpeg back in debian, libvpx vs vp9 optim done, hevc optims incoming [16:45] <ubitux> bayer [16:45] <ubitux> various asm improvements by James Almer [16:45] <ubitux> 2.2 release incoming to match libav10 [16:45] <ubitux> libx265 wrapper [16:45] <ubitux> did i forget anything? [16:48] <saste> ubitux: i don't know, thanks [16:49] <JEEBsv> btw, was anyone working on E-AC3 stuff that's not supported yet? [17:13] <nevcairiel> you mean the blu-ray eac3 tracks? [17:13] <nevcairiel> i briefly looked into it, and iirc the decoder already has all the parts to decode it, it just needs to stitch everything together [17:14] <JEEBsv> k [17:19] <nevcairiel> in any case, i never found the time to do anything more with it [18:03] <aca> Hi all, I changed the Debian FFmpeg bug to ITP and promptly Moritz replied... (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#430) [18:17] Action: Daemon404 seems to have found a bug in the jpeg decoder \o/ [19:03] <ubitux> aca: so Moritz suggest to replace libav with ffmpeg, is that how i understand it? ;) [19:03] <ubitux> it's funny that we have to fight for keeping both libav and add ffmpeg [19:09] <cone-596> ffmpeg.git 03Diego Biurrun 07master:ed61f3ca8a06: parser: Remove commented-out cruft [19:09] <cone-596> ffmpeg.git 03Michael Niedermayer 07master:030643641648: Merge commit 'ed61f3ca8a0664a697782253b354055136c5d303' [19:11] <ubitux> aca: anyway, it looks like he's trying to gain time by playing the "ffmpeg vs libav" endless debate and the immobilism of debian to keep the current state as is [19:12] <ubitux> aca: a ctte discussion should probably be opened asap if you don't want to waste time [19:15] <aca> ubitux: I don't think the few days until FFmpeg will get into unstable will matter much, but I guess this will end before the TC anyway, so it can happen it as well now. [19:16] <aca> ubitux: I guess I should ask the libav maintainers (pro forma) to consider transitioning to FFmpeg. When they reject, this can go straight to the TC as 'matter of overlapping jurisdiction'. [19:18] <cone-596> ffmpeg.git 03Luca Barbato 07master:a1c699659d56: parser: K&R formatting cosmetics [19:18] <cone-596> ffmpeg.git 03Michael Niedermayer 07master:72d580f819ed: Merge commit 'a1c699659d56b76c0bf399307f642c6fd6d28281' [19:45] <llogan> andrewrk: i just approved your message. sorry about the wait. [20:00] <cone-596> ffmpeg.git 03Andrew Kelley 07master:9e329185d701: avfilter/af_compand: fix invalid read [20:03] <ubitux> andrewrk: thx ^ :) [20:25] <iive> ubitux: aca: IMHO moritz words that he ends the discussion because he doesn't want to argue, basically means he doesn't want ffmpeg, but he doesn't have a single argument against it. [20:26] Action: Daemon404 watches highschool drama [20:30] <aca> iive: That's a reasonable interpretation. [20:30] <aca> iive: But he obviously doesn't want to say so in the open. [20:34] <iive> the level of politics in debian is scary. [20:40] <cone-596> ffmpeg.git 03Anton Khirnov 07master:e7dfaf16a403: libavfilter: example audio filtering program [20:40] <cone-596> ffmpeg.git 03Michael Niedermayer 07master:1f2bacc89722: Merge commit 'e7dfaf16a403972eb6aed5ce8f84c0085bd2fb5a' [20:51] <wm4> so what can one do to throw oil into the drama fire? [20:54] <ubitux> well, wait for it to start at least [20:54] <ubitux> if we can package both ffmpeg and libav that would be for the best [20:55] <Plorkyeran_> security team's vetoed that a few times [20:55] <Plorkyeran_> both there and on debian-devel [20:55] <iive> is that for all repos or just for stable? [20:56] <Plorkyeran_> well everything has to eventually go to stable [20:57] <Plorkyeran_> dual-packaging in testing would only to be to evaluate which one to use [20:57] <Plorkyeran_> and not a long-term thing [20:58] <iive> so, the decision could be taken after the evaluation. [21:01] <aca> iive: It would be possible to have FFmpeg in experimental and probably even unstable, but that wouldn't be of much use. [21:01] <aca> iive: Then nobody could use FFmpeg to compile his programs, because they wouldn't make it into stable. [21:02] <aca> On the other hand, evaluating both alternatives is possible in unstable as well as in testing. [21:03] <aca> I would be interested in how many other package maintainers would prefer to use FFmpeg over libav. I think most upstreams use FFmpeg. [21:05] <Daemon404> BBB, im sure youve seen http://www.prweb.com/releases/2014/02/prweb11612574.htm [21:05] <wm4> what led to debian deciding to switch to libav anyway? [21:05] <JEEB> siretart? [21:05] <wm4> there must have been some formal decision with arguments [21:06] <JEEB> Daemon404, LOL :D [21:06] <wm4> I suppose a single maintainer can't just change everything [21:06] <iive> wm4: no, siretart was in the fork team, so he switched without telling anybody. [21:07] <Plorkyeran_> at the time there was no technological difference [21:07] <Plorkyeran_> so I'm not sure what a discussion about which version to use would even consist of [21:07] <Plorkyeran_> the choice was to let the maintainer switch to his preferred fork or find a new maintainer [21:10] <aca> wm4: In Debian a package maintainer can to pretty much anything with the package he maintains. [21:10] <wm4> even if half of everything depends on it? [21:11] <aca> Well, if the change is sort of compatible, it's not easy to complain, without offering to maintain the other fork. [21:11] <iive> well, technically, ffmpeg is trademarked and debian is breaking it, by using it for completely different project... [21:12] <Plorkyeran_> they did eventually remove the ffmpeg compat package [21:12] <llogan> how many years did that take? [21:12] <iive> yes, but the debian package is still named ffmpeg, isn't it? [21:13] <Plorkyeran_> no [21:13] <aca> iive: The Debian source package is now called libav. [21:13] <Plorkyeran_> only stable and oldstable have packages named ffmpeg [21:14] <iive> do these packages contain ffmpeg or fork? [21:14] <Plorkyeran_> oldstable is ffmpeg 0.5 [21:14] <Plorkyeran_> stable is libav 0.8 [21:16] <Plorkyeran_> and the ffmpeg package in stable does in fact install the program named ffmpeg [21:16] <nevcairiel> thats the one that yells at you for using a deprecated function, isnt it :p [21:20] <wm4> that was really a fuckup [21:21] <nevcairiel> they dont see it like that :D [21:21] <nevcairiel> anyway [21:21] <nevcairiel> back to implementing icy [21:23] <llogan> yes, it was a great side effect for them. convinced many users that FFmpeg is no longer developed since distinction between ffalse ffmpeg and FFmpeg project is not always known. [21:26] <andrewrk> np ubitux. thanks llogan [21:28] <andrewrk> llogan, it's true. that was what I thought at first as well [21:29] <andrewrk> I'm really unhappy about the whole situation. I wish everybody could get along :( [21:31] <cone-596> ffmpeg.git 03Diego Biurrun 07master:4ec336484d63: parser: cosmetics: Drop some unnecessary parentheses [21:31] <cone-596> ffmpeg.git 03Michael Niedermayer 07master:2673357048eb: Merge remote-tracking branch 'qatar/master' [21:32] <aca> andrewrk: I also wish everybody could get along, but it seems this is not possible. :( [21:33] <andrewrk> I console myself that this "competition" might motivate development [21:33] <andrewrk> as long as everybody plays fair [21:33] <wm4> haha [21:34] <wm4> well, look at this way: if all ffmpeg and libav developers were in the same project, development wouldn't be possible because drama and bikeshedding would not allow any progress [21:36] <andrewrk> I guess it makes sense - given any sufficiently large body of people there will be disagreements about the direction of the project [21:41] <nevcairiel> wm4: you contributed the ICY support for the http protocol, right? [21:41] <wm4> yes [21:42] <nevcairiel> is the metadata block always string? i figured it would possibly be a binary ID3 block or something, but the code wouldn't support that [21:42] <nevcairiel> i'm only getting headers, the packet option is always empty [21:43] <wm4> at least I haven't seen anything like that yet [21:43] <wm4> what's your test source? [21:43] <nevcairiel> the avoption handles it like a string, so if it happens to start with a 0 byte, it would show up empty [21:43] <nevcairiel> http://dradio-ogg-dlf-l.akacast.akamaistream.net/7/629/135496/v1/gnl.akacas… [21:44] <wm4> hm [21:44] <nevcairiel> time to debug into the code that reads it [21:45] <nevcairiel> too bad avoptions are really crappy at string handling [21:45] <nevcairiel> AV_OPT_TYPE_BINARY is an evil hack :p [21:45] <wm4> returning data via avoptions is an evil hack too [21:45] <nevcairiel> i guess [21:46] <wm4> I had some evil ideas like injection ID3 tags (so the demuxer could read them), but unfortunately this just can't work [21:46] <wm4> this stream doesn't seem to send a Icy-MetaInt header [21:48] <nevcairiel> hm looks like you're right, the icy headers i have are only of rather generic nature [21:49] <nevcairiel> hm ok an mp3 stream i tried has data in a text format [21:49] <nevcairiel> oh well, just going to build a parser for that then [21:51] <nevcairiel> i need better string parsers, hate quoted strings w ith possible escapes in them :( [21:52] <wm4> I'm not sure what convention icy "packets" follow [21:53] <wm4> seems generally very unreliable [21:55] <nevcairiel> maybe i should just hack together a rather dumb parser, in the long run it may turn out to be more reliable on inconsistent input [21:55] <wm4> that's what I did [21:56] <nevcairiel> too bad the protocol can't reach the demuxer to just inject it into the metadata [21:56] <wm4> some streams have icy _and_ ogg metadata, but the stream you posted doesn't seem to have anything on song changes [21:56] <wm4> yeah [21:57] <nevcairiel> the same station also has a mp3 stream, it had proper icy packets [21:57] <wm4> weird [21:58] <nevcairiel> anyway something for tomorrow, shouldn't be too hard to parse the headers and the packet [21:58] <nevcairiel> headers dont usually change, do they [21:59] <nevcairiel> wonder if the http protocol ever reconnects [21:59] <nevcairiel> probably not if it doesnt have to [22:00] <wm4> not sure if http.c reconnects automatically if the connection is dropped [22:55] <kierank> andrewrk: yes but it's a pita for users [22:58] <andrewrk> agreed [23:10] <andrewrk> so when I ported the compand filter to libav, they had me change it from double to float [23:11] <andrewrk> I've heard arguments on both sides for one or the other [23:11] <andrewrk> honestly I don't think it makes too much of a difference. but it would be nice if both projects agreed... [23:12] <Compn> andrewrk : whichever is fastest on most hardware :p [23:13] <andrewrk> hmm good point. that is objectively measurable [23:40] <durandal_1707> you are making audiophiles unhappy [23:41] <thardin> pacify them with some $500/m CAT5 [00:00] --- Wed Feb 26 2014

1 0

ffmpeg.log.20140225
by burek 26 Feb '14

26 Feb '14

[02:06] <Keshl> Is there a magical set of settings I should use for H.265 encoding? It "works", but the video's of.. Very, questionable, quality.. XD [02:08] <Keshl> I tried "ffmpeg -i rawuncompressedfootagehere.flv -vcodec libx265 -preset medium -crf 18 -movflags faststart -pix_fmt yuv420p -vf scale=1366:768 -acodec copy blah.mkv I don't care which container is used. MKV was just the first to come to mind after MP4. [02:36] <iive> Keshl: where did you got libx265 ? (5 as in Five) ;) [02:36] <Keshl> Newest builds have support built in, oÉo. [02:37] <Keshl> They have since the 11th, I think. [02:37] <Keshl> In my case, I got'd from http://ffmpeg.zeranoe.com/builds/ -É-. [02:45] <Keshl> WHOA °²° [02:45] <Keshl> Figured it out. [02:45] <Keshl> And and whooooooa o_o [02:46] <Keshl> Uh, right [02:46] <Keshl> ffmpeg -i awesomevideohere.flv -x265-params crf=18 -movflags faststart -pix_fmt yuv420p -vf scale=1366:768 -acodec copy blah.mp4 [02:47] <Keshl> Yes, you do *not* specify -vcodec. -x265-params does that, appearntly. [02:49] <Keshl> I personally see a loss in quality. It's extremely minor, though, and the filesize is redced by 50% even with highly unpredictable motion scenes. [02:49] <Keshl> For a 50% reduction with 264 the loss of quality's far more noticable. [03:01] <Keshl> Uh, the fudge? [03:02] <Keshl> Maybe more changed during the update than I thought. I was on a fairly old build. [03:02] <Keshl> I noticed changing the CRF in 265 didn't change the videos at all. Same appearnt quality, same output filesize. [03:02] <Keshl> For kicks I ran a CRF of 23 in 264. Same appearnt quality as 265, and same exact filesize. [03:02] <Keshl> Default CRF if not supplied is 23. [03:02] <Keshl> So, what's going on here? o_o [03:05] <relaxed> Keshl: try -preset veryslow [03:06] <relaxed> also pastebin.com [03:06] <Keshl> ... D'oh. [03:07] <Keshl> Hold on a moment. Think I see what I did wrong. <É<' [03:07] <Keshl> Nope. Seems that as soon as I specify -x265-params it just ignores any -preset or -crf I give it. [03:08] Action: Keshl pastes. [03:08] <relaxed> well, support for libx265 is fairly new. [03:09] <Keshl> relaxed: http://pastebin.com/zuhRH4uG [03:09] <Keshl> I know. I think I found a bug. D: [03:09] <Keshl> Either that or I'm horribly misunderstanding the syntax of the command. [03:09] <Keshl> Note: Windows is stupid and linewraps at 80 characters. I didn't actually put that command on 3 lines. [03:10] <Keshl> .... Oh. [03:10] <Keshl> "Codec AVOption x265-params (set the x265 configuration using a :-separated list of key=value parameters) specified for output file #0 (E:\crf_crf_265_18.mp4) has not been used for any stream." [03:10] <Keshl> So it /is/ ignoring what I tell it. [03:11] <Keshl> That still doesn't explain why the filesize for 264 and 265 are completely identical down to the kb. [03:11] <Keshl> And why the apparent visual quality of the frames are identical, assuming a crf of 23. [03:12] <Keshl> Really seems like it's using the same encoder, and that encoder seems to be 264. [03:13] <relaxed> Stream #0:0 -> #0:0 (h264 -> libx264) [03:13] <relaxed> add -c:v libx265 [03:13] <Keshl> ... How'd I miss that?! [03:13] <Keshl> Should I add it before or after -x265-params? [03:14] <relaxed> before gives me the warm fuzzies [03:14] <Keshl> oÉo. [03:14] Action: Keshl snugs dem warm fuzzies. -É-. [03:15] <Keshl> Yes, now it's using 265 for sure cuz it won't write to .mp4.. [03:15] Action: Keshl tries MKV. [03:16] <Keshl> MKV works. Encoding is terrifyingly slow. This is encouraging. <É< [03:22] <Keshl> ... Uh. [03:22] <Keshl> The output file's 28 bytes. [03:22] <Keshl> Wait. [03:22] <Keshl> brain. [03:22] <Keshl> Got it. [03:23] <Hello71> -map 0: [03:23] <Keshl> Colors are a little off, but the fidelity's what I expect from crf 18 now. [03:23] <Keshl> Sorry, silly my played the bad mp4 first. <.< MKV's.. "Fine". [03:23] <Keshl> Size's far larger than 264, though. 50% larger. [03:24] <Keshl> Trying CRF23, just to see if the quality's the same and CRF needs rebalancing.. [03:36] <Keshl> Okay, 17.9 megs. 15-20% smaller. Video quality is better than 264 crf23 but worse than 264 crf18, and in different areas. I get that that's by design, but I felt it's worth saying. [04:29] <Keshl> In h.265, CRF22 is roughly equal to h.264's CRF18. The quality's visually identical from what I can tell apart from some momentary stutters at the start of the video, but the difference in filesize is amazing. [04:30] <Keshl> First, let me say that, at 23 CRF, the default for 264 and 265, the video I have comes to 22.1 megs. [04:30] <Keshl> At a CRF of 22 in 265 (Which looks like a CRF of 18 in 264), the file is 20.4 megs. [04:30] <Keshl> A CRF of 18 in 264 is 38.3. [04:31] <Keshl> So, essentially, 265's become "free" visually lossless video, as far as I'm concerned. [04:32] <Keshl> And it turns out the bad colors are due to me playing 265 files in another player. 264 files are discolored the same way there, so it's the decoder at fault. [04:36] <Keshl> Playing with the usual player (Updated) does fix the color issues, and fixes the skipping. By replacing it with a black screen. [04:37] <Keshl> Regardless. Shiny. -É-. [05:46] <Keshl> Wow, encoding's only about four to five times as long as 264.. XD [06:07] <Keestu> hi all, i have a basic question. how can i find how many frames per second i am receiving by programatically ? [06:08] <Keestu> for example, if fps is said to be 25, then does this av_read_frame() retrieves 15 frames per second ? [06:21] Action: Keshl snugs a Zeranoe cuz builds. -É-. [06:26] <Dark-knight> If i use "-c copy" in the command line, doesn't to do the same thing as putting "-acodec copy -vcodec copy" in the command line? [06:26] <Dark-knight> also if it does, what is the difference? [06:44] <Dark-knight> and when changing the container (for ex: from avi to mp4) could i just leave out the copy commands completely? had just have a code that looks like this? [06:44] <Dark-knight> ffmpeg -i input.avi output.mp4 [06:51] <LithosLaptop> dont think so [06:53] <Dark-knight> don't think what? [06:56] <Zeranoe> Keshl: Whats up? [07:05] <Keshl> Zeranoe: Jus'huggin. I 'preciate the builds and never knew'ya came here. oÉo. [07:05] <Keshl> Dark-knight: No, ffmpeg is stream-based. You'd have to reencode while changing containers. Pretty sure, anyway. [07:06] <Dark-knight> so i would have to use a copy command? [07:07] <Keshl> At least. [07:07] <Dark-knight> now back to my question. which copy command should i use? [07:07] <Keshl> -vcodec copy -acodec copy [07:07] <Dark-knight> I have used -c copy and it did the same thing. what is the difference? [07:07] <Keshl> Do note that not all containers support all formats. [07:07] <Keshl> Probably nothing. Just shorthand. [07:08] <Keshl> There's -c:v that you can use instead of -vcodec too. [07:08] <Dark-knight> so is -c copy the same code just shortened? [07:09] <Keshl> Possibly. I don't know for sure, but if it seems to do the same thing, then it could be. [07:09] <Dark-knight> i assume that -c copy is a combination of -vcodec copy -acodec copy [07:14] <Dark-knight> I need to confirm if that is true [07:16] <Keshl> Well, wait until someone else comes around. [07:17] <Keshl> Remember that we are not paid to help you, by you or by anyone else. We all have lives. Be patient. You are not automatically entitled to free support at any point. If you want help, you gotta act nice. [07:21] <bparker> or you could just try it yourself [07:22] <Keshl> Indeed. <É< [07:23] <Dark-knight> i understand that, if you noticed, I didn't demand anybody to immediately answer my question. I simply made anyone reading this aware that I needed confirmation on my clam. So before you spout things at me about being unpatient understand I didn't provide any sense of urgency in my statement. [07:23] <Dark-knight> please refrain from such statement in the future [07:25] <Keshl> You /did/ provide a sense of urgency. You didn't intend to, but it's what you did. [07:25] <Keshl> On top of that, you answered your own question and told us that, twice, and then asked us for help on it anyway. [07:25] <Keshl> What do you expect us to do? o.O' [07:31] <Keestu> can someone kindly help me, regarding this frame per second concept?. [07:31] <Keshl> ... I wonder if -preset placebo works with 265. That'd be painful. x.x With Medium on an i7 I'm getting 2.6 FPS. [07:31] <Keshl> Keestu: What was it, oÉo? [07:32] <zap0> Keestu, there are these things called 'frames'. somewhere in the header, a value is set called 'fps'. players use this as a guide to the rate they display them. [07:34] <Keestu> thanks for the reply keshl, i am a newbie and trying to understand the concepts behind ffmpeg/video. fps -> frame per second , for example 25fps -> 25 frames are captured in a second. Now i have written a simple video player in ffmpeg to display. i read frames by av_read_frame(), who can i related this 25 fsp to this API? [07:35] <Keestu> that meas ,av_read_frame() , does it require to read 25 fps ? [07:35] <Keshl> That's way beyond my skillset, sorry D: I just "kinda sorta" know how stuff works, and just barely enough to know what some of the more important paramaters do when I'm encoding stuff. [07:35] <Keshl> And until this second, I didn't even know ffmpeg had an API. [07:37] <Keestu> Keshl, no issues, you helping intention really appreciable . :) [07:37] <Keestu> if anyone knows the link also, kindly share with me, i can read the same and try to understand. [08:22] <Dark-knight> I understand that putting "-vcodec copy -acodec copy" in the command line will produce the same video as putting "-c copy" in the line, BUT causation doesn't always mean correlation. so I was wondering if "-c copy" is in-fact a shortened code for "-vcodec copy -acodec copy" or if the videos are slightly different because of the different code? [08:23] <Dark-knight> i can't tell [08:23] <relaxed> -map 0 -c copy means copy everything [08:24] <relaxed> get in the habit of mapping what you want [08:25] <relaxed> for just the audio and video streams, ffmpeg -i input -map 0:v -map 0:a -c copy ... [09:22] <Keestu> hi all, avformat_open_input () -> when i tried to open with rtsp://<ip>:<port> , it works in all mobiles [htc, samsung], but when i change to http://<ip>/test.sdp , it works only with samsung, but not in HTC. In which context can i look this issue ? [10:10] <Waster> hey all, is it possible to have multiple encodings with ffmpeg with one of these recording to the file also? [10:16] <Waster> ffmpeg -i <RTSP_URL> -c:v libx264 -b:v 128k -f flv rtmp://localhost:1935/hls/stream_low -c:v libx264 -b:v 256k -f flv rtmp://localhost:1935/hls/stream_mid -c:v libx264 -b:v 512k -f flv rtmp://localhost:1935/hls/stream_hi [10:16] <Waster> it works well [10:16] <Waster> but I want to record last 512k encoding to the file also [10:17] <Waster> -f tee for the last stream does not work [10:35] <Waster> anyone? [11:05] <Keshl> I now understand why hardware decoding is a wonderful thing. [11:05] <Keshl> Turns out, no, a single core at 3.6 ghz cannot handle playing 1920x1080 video at 60 FPS when encoded with h.265. [11:05] <Keshl> That was a very bad idea. [11:05] <Keshl> XD [11:09] <BtbN> well, that'll improve a lot in the future [11:09] <BtbN> the code isn't yet optimized [11:19] <Keestu> Keshl, may i ask you how to do harware decoding?, i am aware of software encoding with the help of libx264. [11:19] <Keshl> Keestu: Hardware decoding happens when playing video back in a media player. To my knowledge, ffmpeg doesn't do it. [11:20] <Keestu> ok, that means media player uses hardware encoding ? [11:24] <Keshl> Depends on the player. Most do. [11:29] <Mavrik> there are also several layers of hardware acceleration [11:34] <Keshl> ... I'm just full of bad ideas today. XD [11:34] <Keshl> So I tried using ultrafast rather than medium since ultrfast's usually easier for my system to decode. [11:34] <Keshl> Bitrate: 144000ish. [11:35] <Keshl> ... I don't think this is a good idea anymore. XD [11:38] <Keshl> Man. This reminds me of the days when I was still running an nVidia card with four digits and trying to play h.264 at 1080/60. It just wasn't happening. XD Doesn't help that no GPU supports h.265.. [11:42] <esperegu> Hi. I have a annoying noice on an audiostream. anyone knows how I can get rid of it? Is there a way to filter out noice or maybe play nothing unless above a certain amount? thx! [11:49] <Keshl> esperegu: it depends on the sound, speciffically. Some are easier to take out than others. [11:49] <esperegu> Keshl: you have any commands for me I can test? [11:50] <Keshl> esperegu: Start by extracting the audio from the video. Run this, substituting filenames where required: [11:51] <Keshl> ffmpeg -i myvideo.avi audio.wav (Make sure you use .wav) [11:51] <Keshl> Then play the audio, make sure it actually plays. If it does, good. [11:51] <Keshl> next, grab http://audacity.sourceforge.net/ and open it there. [11:52] <Keshl> Depending on the specific type of sound you're hearing, the next step may be dead simple or it may require some experimentation. [11:53] <Keshl> If it's something along the lines of a high-pitched squeal, just import the .wav file (FIle > Import > Find it > Just hit OK), then do Effect > Low Pass filter. Set the rolloff to 48db and the cutoff to 16000, hit okay, be patient, then play it and see if you still hear it. [11:54] <Keshl> If you still do but it's quieter, undo (Ctrl Z) and try again but with a lower cutoff. If you bring it too low you'll eventually notice it affect more of the audio than you want it to, so that might take some experimentation. [11:54] <Keshl> If it has no effect, then you gotta do something a bit more complicated. It "should" work, provided you spend some time with it, though. [11:55] <esperegu> and then howto get it into ffmpeg? [11:55] <Keshl> First, find a part of the audio that has /just/ the sound you want to remove and nothing else. [11:55] <Keshl> (I'll explain that in a minute.) [11:55] <esperegu> Keshl: thats no problem cause its a noice playing all the time [11:56] <Keshl> Once you've found it, select it (Just click and drag over it), then do Effect > Noise Removal, and click "Get Noise Profile". The window'll just dissappear and look like nothing happened. [11:56] <Keshl> next, select everything (Ctrl A), then run Noise Removal again. Instead of hitting that first button though, just hit OK. This might take a while for it to process depending on the complexity of the noise, but eventually it'll finish. [11:57] <Keshl> Once it does, play and see if you still hear it. If you do but it at least sounds a little different, select another part of audio that has just the noise and repeat both steps until it's all gone. [11:57] <Keshl> It's rare you'll get rid of it /all/ on your first try, but there is a chance you'll get lucky. [11:57] <Keshl> Regardless, whenever it's cleaned up enough for'ya, export it as .wav again (You can overwrite the same file if you want, just make sure you /export/, not /save/). [11:58] <Keshl> Then in ffmpeg, do this: ffmpeg -i videowithnoise.avi -i fixedaudio.wav newvideo.avi Yes, you specify -i twice. I don't know if that's /exactly/ what you do to fix it, but I know it's something along those lines. [12:00] <Keshl> I can't check right now since I'm busy encoding a video myself and if I try to start another up my computer's gunna scream bloody murder at me. <.< But if that doesn't work, try: ffmpeg -i video.avi -i fixed.wav -vcodec copy newvideo.avi or something. [12:01] <Keshl> (It's possible you'll need to use "-map". I have _no_ clue how this switch works or what you'd need to type to make it replace audio. Hopefully somebody else does..) [12:05] <esperegu> Keshl: k. trying it. if you interested its the noice in the beginning of this file: http://babilejo.org/misc/noise2.wav [12:06] <Keshl> Oh, that hiss. [12:07] <Keshl> Yeah, got rid of it. That one's rather easy. XD [12:07] <Keshl> If it's something like a crowded subway it's harder but still doable. This though, first try, second method. [12:07] <esperegu> that be awesome [12:08] <Keshl> Select some of the noise, Effect > Noise removal, get noise profile, select all, effect > Noise removal, hit OK, done. [12:08] <Keshl> (By "some" I mean "1-2 seconds") [12:08] <esperegu> Keshl: in you example you join them again. [12:08] <Keshl> It works? [12:09] <esperegu> Keshl: this can't be done by ffmpeg? [12:09] <Keshl> What can't be done, exactly? Join what things? [12:09] <esperegu> Keshl: ffmpeg -i videowithnoise.avi -i fixedaudio.wav newvideo.avi [12:10] <esperegu> Keshl: remove the noice [12:10] <esperegu> Keshl: I am looking for an option so ffmpeg can remove that hiss [12:11] <Keshl> esperegu: It can't. [12:11] <Keshl> It's for video processing, not audio processing. [12:11] <Keshl> The most ffmpeg can do with audio, as far as I know, is transcode it (from like, wav to mp3 and such) -- No actual effects. [12:11] <JEEB> there are audio filters [12:12] <Keshl> Oh, shiny. -É-. [12:12] <Keshl> JEEB: Any chance you know if the command I'm giving him is right, and it'll overwrite the audio stream already in the .avi? [12:13] <JEEB> it most definitely isn't correct without -c:v copy IMHO (since audio has to be re-encoded again unless you want uncompressed audio in that avi) :P [12:13] <esperegu> Keshl: its not an avi but a stream but I suppose its the same [12:14] <JEEB> also mapping is good [12:14] <JEEB> ffmpeg cli app will select of course one audio and video track by default, but you really can't know if you're getting the right one otherwise :P [12:14] <esperegu> isn't there a filter that plays no audio unless above a threshold or so? [12:14] <Keshl> esperegu: I think there is, but then you'll hear the hiss when there's that instrument playing. [12:15] <Keshl> If you did what I said, it'd become crystal clear. (It did for me.) [12:15] <JEEB> feel free to go through the listing :P http://ffmpeg.org/ffmpeg-all.html#toc-Audio-Filters [12:16] Action: Keshl tilts his head at "earwax".. [12:20] <esperegu> Keshl: it is clear indeed. but if ffmpeg is not able to do it it does not really help [12:20] <Keshl> Why not? o.O [12:21] <esperegu> Keshl: it is a live stream [12:21] <Keshl> Ohhh. [12:21] <Keshl> Is there any reason you can't record the stream and process it later? [12:22] <esperegu> Keshl: cause I listen to it real time ;-) [12:22] <JEEB> anyways, go through the ffmpeg cli audio filters [12:22] <JEEB> and see if you can use any of them [12:22] <Keshl> JEEB: I looked. There's none. D: [12:22] <esperegu> JEEB: I already tried a few but heard no difference. I might be using it wrong though [12:22] <Keshl> esperegu: Why not just do it on your sound card, then? [12:23] <Keshl> Just go to the equalizer and lower 16000 hz all the way or something. [12:23] <JEEB> lowpass/highpass sound like something useful for denoising if that's what you want :P [12:24] <esperegu> JEEB: I tried: -filter:v highpass [12:24] <esperegu> but did not notice a difference [12:24] <JEEB> > :v [12:24] <JEEB> u w0t m8t [12:24] <esperegu> JEEB: is the command correct? [12:25] <JEEB> you are applying a filter to :v [12:25] <JEEB> which is VIDEO [12:25] <Keshl> JEEB: It's not a high-pitched or low-pitched sound. [12:25] <JEEB> anyways, go read the fine documentation since it's there [12:25] <JEEB> Keshl, that's not what high/lowpass does [12:25] <Keshl> It's about 8,000 hz and it's just random mic static. [12:25] <JEEB> unless I misunderstand [12:25] <Keshl> You do. XD [12:25] <Keshl> See, I've got sensitive ears. I actually /have/ to run my audio through a lowpass filter or I can't listen to 90% of stuff online. [12:26] <Keshl> So believe me I know how it works. [12:26] <Waster> is it possible to use tee and flv rtmp output? [12:26] <Keshl> It basically does frequency analysis on the audio, and then removes audio that's higher or lower frequency than that from the audio stream. [12:30] <Keshl> It /could/ work with a lowpass filter, but then it's sound like he's underwater. The noise ragnes from 5k to 8k, so if he cut down to 5k that'd be.. Intense. XD [12:30] <Keshl> Usually if you cut down to even 12k you'll hear a bit of an underwater effect. [12:31] <Keshl> And if he tried a highpass instead, he'd have to cut up to 8k. His audio only goes to 7k or so, so then it'd just be silence. [12:32] <esperegu> isnt there a filter that cuts off everything under a certain level? [12:32] <Keshl> If you want to see a visual demonstration, open up Audacity and any audio file. Click the little down arrow by the "mute" and "solo" buttons (Upper right corner of that section) and change it to a spectrogram. [12:32] <Keshl> esperegu: There is not. [12:32] <Keshl> esperegu: If you want to do something like that just for you, you can do that on your sound card instead. [12:32] <Keshl> (provided you have one. A good one that actually supports stuff like that.) [12:41] <esperegu> Keshl: its a bit more involved. ffmpeg streams my pulseaudio via rstp [12:42] <Keshl> Oh, Linux? I have no idea how to get sound cards to do magic stuff there. Sorry. x.x [12:44] <Waster> ok, solved it with -map 0 -flags +global_header [12:44] <Waster> now tee works with rtmp [12:44] <Keshl> Shiny -É- [12:44] <Keshl> And thanks for telling us, oÉo [12:45] <Waster> welcome...) [12:45] <Waster> btw, is it possible to do daily archive then with ffmpeg? [12:45] <Keshl> Can'ya describe what a "daily archive" is, oÉo? [12:46] <Waster> I mean one recording per day with date in filename [12:46] <Waster> automatically [12:49] <Keshl> Assuming you know how to do some scripting (With Bash or powershell), sure. [12:50] <Waster> sure I know, you mean I can create template for ffmpeg command line and run it through cron every day klling ffmpeg? [12:50] <Keshl> Yes, that should be rather simple provided you know how to use Bash. [12:50] <Keshl> I don't, though. [12:51] <esperegu> Keshl: so there are no options for me? [12:52] <Keshl> esperegu: There might be, but I don't know of any. [12:52] <Waster> great, thanks [12:53] <Keshl> Welcomes, oÉo [12:54] <esperegu> JEEB: you have any idea? [13:14] <Keshl> ... Blah D: The Linux version ain't compiled with libx265 xwx.. [13:43] <_aeris_> hello ! [13:43] <_aeris_> is there any option to force png output with image2 output format ? [13:43] <_aeris_> if you specify an output file with png extension, ffmpeg generate a png [13:44] <_aeris_> but with «-f image2 pipe:1», only jpeg :( [13:48] <relaxed> _aeris_: try -c:v png [13:51] <_aeris_> \o/ [13:51] <_aeris_> thanks relaxed [13:54] <relaxed> Keshl: which linux version? [13:55] <relaxed> _aeris_: you're welcome [13:56] <Keshl> relaxed: The.. One? [13:56] <Keshl> Any from http://ffmpeg.gusari.org/static/ . [13:56] <relaxed> my build has it http://johnvansickle.com/ffmpeg/ [13:59] Action: Keshl pooookes.. [14:02] <Keshl> Nupe, dun gots. D: [14:02] <Keshl> You have to compile with --enable-libx265 , oÉo. [14:02] <JEEB> I will have to note though that x265 is very often broken in either compilation or in what it actually does [14:03] <JEEB> also it is only useful if you do --preset placebo --ref 16 --bframes 16 level encoding [14:03] <Keshl> Works fine for me on windows. D: [14:03] <relaxed> Keshl: that build has support, trust me [14:03] <JEEB> that's just because you're lucky [14:03] <JEEB> (and --tune ssim since otherwise it optimizes for PSNR) [14:03] <relaxed> I just tested it. [14:03] <Keshl> relaxed: "Unknown encoder 'libx265'" [14:03] <Keshl> I just tested it too. Fresh download. [14:03] <Keshl> I'm using 26/five/, not 26/four/. [14:03] <relaxed> are you using the 10bit binary? [14:03] <relaxed> use the regular one [14:03] <Keshl> No. No sane media player can play that. D: [14:04] <JEEB> he wants to encode HEVC [14:04] <Keshl> Using regular. [14:04] <JEEB> not AVC [14:04] <relaxed> my build has libx26FIVE support [14:04] <Keshl> JEEB: Incredibly lucky, appearntly. The video I'm encoding is.. Scary-evil impossible-to-compress. XD [14:04] <Keshl> relaxed: It really, truly, does not. [14:04] <JEEB> Keshl, it actually doesn't get better than x264 in things unless you really push it to the max though :P [14:05] <Keshl> relaxed: http://pastebin.com/Z53PHyXT [14:05] <JEEB> it gets very slow then, but that's what you get (about ~10 times slower than x264's placebo) [14:05] <Keshl> JEEB: Must be pushed to max by default, then. That'd explain why it takes 20 minutes with 264 and about 4 hours with 265. XD [14:05] <JEEB> no, it is not [14:05] <JEEB> and yes, it is generally slower [14:05] <JEEB> also any of the other presets are comparably useless [14:05] <JEEB> just max it out and you are going to get some efficiency :P [14:06] <relaxed> Keshl: "built on Jan 22 2014" [14:06] <Keshl> relaxed: Too old. [14:06] <Keshl> relaxed: Support for x265 didn't come out until Feb 11th. [14:06] <relaxed> The freaking build on the download page is "built on Feb 25 2014" [14:06] <Keshl> Oh. [14:06] <Keshl> wait, wh -- .. [14:06] <Keshl> ..... [14:06] Action: Keshl facedesks. [14:06] <relaxed> the git build [14:07] <Keshl> Hold, misclicked.. x.x [14:07] <Keshl> yep, I see it now, sorry, thanks x.x [14:07] <JEEB> but yeah, for whatever reason libx265's preset placebo doesn't actually do the same as x264's. [14:07] <JEEB> so you don't get ref16 bframes16 [14:07] <JEEB> which does help [14:08] <JEEB> and then of course you need to set tune to ssim [14:08] <JEEB> because otherwise you get BLUUURR (PSNR optimization) [14:09] <Keshl> D: It hates me! [14:09] <Keshl> http://pastebin.com/MGV1Jn5B -- Says that the aspect ratio's zero. I don't understand how he's getting that idea o_o [14:10] <Keshl> JEEB: I already messed it up horribly once. XD [14:10] <Keshl> That was *fun* =D! [14:10] <JEEB> anyways, just to make sure you know, x265's development is purely done by MCW, which has zero of the x264 devs on board [14:10] <JEEB> they just got the name :P [14:11] <Keshl> Really though. I already get 50% filesize reductions with the same visual quality using just -vcodec libx265 -x265-params crf=22 -preset medium and nothing else. It's nuts. o_o [14:11] <JEEB> (and the rights to use the x264 code base) [14:11] <relaxed> and that sucks :( [14:11] <JEEB> Keshl, no [14:11] <JEEB> no [14:11] <Keshl> No? [14:11] <JEEB> it does not produce that [14:11] <JEEB> also don't mux into matroska with ffmpeg [14:11] <JEEB> only output raw hevc files [14:12] <JEEB> and mux with L-SMASH or so [14:12] <Keshl> I don't know what you're saying D: [14:12] <JEEB> Output #0, matroska, to 'OU265.mkv': [14:12] <Keshl> Here, gimme a second, lemme just make this dead simple.. [14:12] <JEEB> THIS IS NOT GONNA BECOME SPEC-COMPLIANT [14:12] <relaxed> I may start including l-smash in my archive [14:13] <JEEB> because libavformat doesn't support HEVC muxing into anything yet (except maybe, maybe in to mpeg-ts, but I'm not sure about that either) [14:13] <JEEB> as far as containers go [14:13] <JEEB> so just stick to dot-hevc [14:13] <relaxed> what are the x264 looking at? kvazaar? [14:13] <Keshl> Oh, you're talking specs. I thought you were gunna say that it doesn't encode, period. [14:13] <relaxed> x264 devs* [14:13] <JEEB> oh it will encode and mux shit into matroska [14:14] <JEEB> but it's not standard [14:14] <Keshl> I was just about to toss you an FTP to an .mkv with 265. [14:14] <Keshl> oÉo. [14:14] <JEEB> and it will ONLY work with lavf [14:14] <Keshl> ... This explains much. oÉo. [14:14] <JEEB> it only "works" because lavf has a default muxing mode for matroska etc. [14:14] <JEEB> which is just "throw extradata there, and actual data there, and give it some random ID specified as a FourCC" [14:15] <Keshl> So what's the file extension? .hevc? [14:15] <JEEB> yes [14:15] <JEEB> relaxed, btw if you're going to build L-SMASH you pretty much have to patch it with https://github.com/l-smash/l-smash/pull/14 [14:15] <JEEB> because the cli app has HEVC muxing disabled right now [14:15] <Keshl> Anything else, oÉo? Besides the -placebo stuff. I know it'll help, but right now I'm still trying to figure out how low I can push the CRF before things get too big. [14:15] <JEEB> I don't usually go lower than 24 [14:15] Action: Keshl has no clue what L-SMASH is. D: [14:16] <JEEB> crf 24, preset to placebo, refs and bframes to 16, tune to ssim [14:16] <JEEB> that's pretty much sanely'ishly maxing it out [14:16] Action: Keshl is obsessed with quality and fine detail. With H.264, he woulfn't go higher than 18. [14:16] <JEEB> there's the full ME mode [14:16] <JEEB> Keshl, well you can't really do visual comparisons with too high rate now can you? [14:16] <JEEB> because there will be no differences :P [14:16] <Keshl> That's the point, oÉo. [14:17] <Keshl> At 18, as long as you don't pause, the encoded video looks the same as the raw, uncompressed, freshly-captured video. [14:17] <JEEB> anyways, the crf range is completely different from x264 [14:17] <JEEB> personally at least with 720p 24 was as low as I'd go for testing purposes [14:18] <Keshl> I know it's different, that's why I'm uisng medium and xperiemtning with crf now, rather than placebo and trying to experiement with crf. XD [14:18] <Keshl> ... Whoa, typos. [14:20] <JEEB> anyways, always use tune ssim with x265 until they default to it or visual psy-opts [14:21] <JEEB> otherwise AQ and other stuff will just be disabled [14:21] <Keshl> Whus AQ, oÉo? [14:21] <JEEB> adaptive quantization [14:21] <Keshl> Ohhhh.. [14:21] <Keshl> That's why it always says q=0.0, isn't it? x.x [14:21] <Keshl> And why parts with -- Ohhh.. [14:22] <Keshl> Where were you twelve hours ago? My CPU would be screaming less.. XD [14:22] <JEEB> uhh, no. I don't even know if the q value says anything except when you're using constant quantizer mode [14:22] <Keshl> It does. When you use libx264 it says stuff, oÉo. [14:22] <Keshl> And it changes depending on the amount of motion in the scene. [14:22] <JEEB> yes, but that isn't really useful per se [14:23] <JEEB> and has nothing to do with AQ/no AQ [14:23] <Keshl> o.O? [14:24] <Keshl> o.O''' Uh, encoding to .hevc made stuff break *weird*. [14:24] <Keshl> Now the seek bar doesn't work, the timing information seems to be lost, it's playing at 25 FPS (Because it guessed, not because it's lagging -- CPU and GPU usage are down really far), and the audio's not playing. [14:24] <JEEB> uhh [14:25] <JEEB> let's start with the most obvious [14:25] <JEEB> it's raw HEVC, there's no audio [14:25] <Keshl> ... Oh. [14:25] <JEEB> second, I'm pretty sure x265 doesn't yet write any VUI timing information because there are patches for that on its mailing list [14:25] <JEEB> third, it's raw HEVC, no real chances of seeking in that without indexing it before hand [14:25] <Keshl> What do you suggest I do, then? D: Audio's kinda important. So's playing at 60 FPS. D: [14:26] <JEEB> mux it with L-SMASH patched with the patch I have in the pull request? [14:26] <Keshl> I don't know what L-SMASH is. o_o [14:26] <JEEB> muxer -i hurr.hevc?fps=60 -o out.mp4 [14:26] Action: Keshl hugs the word "hurr" -É-.. [14:28] <JEEB> but yeah, clone the main L-SMASH repo and then grab that one commit from my repo on the top :P [14:28] <JEEB> and L-SMASH itself is very simple to compile, ./configure and then make [14:29] <Keshl> Any deps? I'm on a weird-butt version of Gentoo that has like, zero usable developement libraries in its repo. x.x [14:29] <JEEB> not really [14:29] <Keshl> And earlier, you said to use -ref 16. It claims it's not found. Did you miss a character, oÉo? [14:29] <JEEB> it's either refs or ref [14:29] <JEEB> same for bframe(s) 16 [14:29] <Keshl> Refs, oÉo. [14:29] <Keshl> ...Now bframes isn't found. XD [14:29] Action: Keshl puts singular. [14:30] <Keshl> Also not found! [14:30] <JEEB> also I'm pretty sure you have to use x265opts for those [14:30] <Keshl> Maybe it wants cframes. oÉo. [14:30] <JEEB> because daemon404 decided that the way that shit was done for libx264 was crazy [14:30] <relaxed> indeed [14:30] <Keshl> x265-params got it, oÉo. [14:30] <Keshl> Wait. Nope. [14:30] <Keshl> ... Wait, that's me being an idiot. [14:31] <Keshl> Yeah, got it. -É-. [14:31] <Keshl> Forgot that they're seporated by commas in lists like that, not spaces. [14:31] <Keshl> OH GOSH THE PAIN °²° [14:31] <relaxed> I'll proabaly include a static x265 with my build along with kvazaar. [14:31] <JEEB> kvazaar's pretty cool [14:32] <JEEB> and much simpler to participate in [14:32] <Keshl> One frame encoded, roughly every 15, sixteen, seventeen.. [14:32] <Keshl> 20ish seconds. o_o [14:33] <Keshl> Whelp, that's why I wanted the Linux build. Least I have a second computer to run other STUFF with. [14:33] <Keshl> Now, L-thingy.. Okay, lesse how bad I mess this up. [14:33] Action: Keshl cracks his compiling knuckles. [14:33] <relaxed> JEEB: think your patch will be included soon? [14:33] Action: Keshl realizes he only knows how to use Mercurial and SVN. x.x [14:35] <Keshl> I officially have no idea what I'm doiiiiing o_o [14:35] <Keshl> That statement probably shoudl've been said when I first mentioned twosixfiiiive o_o [14:42] <JEEB> relaxed, VFR Maniac/muken's official opinion is that it will fully go in only after the FDIS ballot ends [14:42] <JEEB> which is in two months [14:42] <JEEB> technically you can't really have changes after the FDIS ballot has been started, but he is kind of heavy on the "only official specs" stance [14:44] <JEEB> so yes, for the time being you will have to get the stuff from that pull request [14:44] <JEEB> I'll try to get some parts of it to be merged before that, but I bet the cli won't be enabled before the FDIS ballot is over [14:54] <Keshl> Okay, stuff hates me. x.x Firstly, let me say that I don't plan on erasing the original uncompressed file, and I only plan to send these videos to one person because he's got a really lousy connection that likes to randomly drop to 10kb/sec. I know I'm breaking standards here, but if it plays on his system, that's all I care about at the moment, otherwise I'm still using H.264 for the foreseeable future primarily due to support for [14:54] <Keshl> hardware acceleration. [14:55] <Keshl> My windows system has a processor half as fast as my Linux system. On windows, I'm running "./ffmpeg -ss 135 -i MushVis_RAW.flv -vcodec libx265 -x265-params crf=22,refs=16,bframes=16 -preset placebo -movflags faststart -pix_fmt yuv420p -tune ssim -vf scale=1366:768 -acodec copy -t 20 out16.mkv". It works fine. Encoding's still in progress. [14:55] <JEEB> just make sure that file only gets played with lavf and that it doesn't go around the internets [14:56] <Keshl> That's ensured, don't worry. oÉo. [14:56] <Keshl> On Linux, that very same command results in an error saying a value of "22,refs=16,bframes=16" is invalid for "crf", this I have to specify -x265-params three times. That makes it take. .. Almost. [14:56] <Keshl> Even if I take out the refs and bframes, I get this error on the Linux system only: "Sample Aspect Ratio width must be greater than 0". [14:56] <Keshl> Any suggestions? xwx [14:58] <JEEB> btw, you will be using AVC/H.264 for the foreseeable future because it will just be bringing you more bang for the buck for right now, maybe in a 6-12 months period it will get better [14:58] <JEEB> granted, the fact that you can kind of get better results with x265 already is kind of promising given how damn broken that thing can be with random revisions [14:58] <Keshl> What do you mean "bang for your buck"? If you mean in terms of filesize vs quality, no. 265, at least for the videos I'm using, is already 50% smaller with the same visual quality, even without refs= and bframes= specified. [14:58] <Keshl> And without -tune. [14:59] <JEEB> then you're testing in a bit rate range that is useless for testing :P [14:59] <Keshl> Here, seriously, lemme send you a 20 second clip. No refs, no bframes, no tune, and preset set to medium, not placebo. [14:59] <Keshl> o.O? What do you mean by that, exactly? [14:59] <JEEB> and/or your content can take a lot of blurring without visual problems [14:59] <Keshl> ... No, trust me it can't. XD [15:00] <JEEB> then it's the first case [15:00] <JEEB> and I'm not going to lecture you on how to do testing properly because I will be a nerve wreck rather quickly [15:01] <Keshl> oÉo.. I guess 18,000 could be considered a bit high <É<' [15:01] <JEEB> in any case, if you are CURRENTLY getting "50% smaller and looks better or no difference seen", then you're way higher than you should be in the bit rate range [15:01] <Keshl> 140,000 could be considered even higher. o_o Already made that mitake. x.x [15:01] <Keshl> ... Wait. I think I severely misunderstand wgat a bitrate is. [15:01] <JEEB> because x265 most definitely is NOT better than x264 on any standard preset [15:01] <Keshl> *what [15:02] <nyuszika7h> hi, does anyone know how to burn in subtitles from an .srt file? [15:02] <Paranoialmaniac> btw i dont recomment use of ref=16. this has doubt of a bug of the spec... [15:02] <Keshl> I've been assuming that bitrate is how fast data is read from storage medium. Is that what it is? [15:02] <JEEB> it is the amount of bits in average used over the clip for a second of content [15:03] <Keshl> "used" how? By reading from storage medium or by decompressing and tossing at the screen? [15:03] <JEEB> oh for fuck's sake [15:03] <JEEB> THE FUCKING BIT STREAM YOU IMBECILE [15:03] <JEEB> or byte stream if you do Annex B [15:04] <JEEB> coded picture sizes [15:04] <Keshl> I really don't know what that is. o_o Look, you've been doing this for years and years. I've been doing this, maybe six or seven months. You program for the project. You obviously have a deep understanding of this. I don't. [15:04] <Keshl> What you think is common knowledge, is not common knowledge. [15:05] <Keshl> I am trying my best here. I am admitting I may be wrong about stuff rather than just assuming that I'm right and there's a bug somewhere. [15:05] <Keshl> Would you rather have someone like me, or someone saying "rawr ffmpeg sux, fix it!!1"? [15:05] <JEEB> I would ignore the latter, so I probably would rather have him [15:05] <Keshl> Interesting train of thought.. [15:06] <JEEB> in this case you're under my limit of ignoring someone, and thus I end up using my time [15:06] <JEEB> in any case, if you don't understand the concept of average bit rate over the whole clip you're really out of the range I can help, sorry :P [15:07] <Keshl> And this is one of the many reasons you'll never see me ask for commit access here. XD [15:07] <JEEB> because it's literally <amount of bits the whole clip takes> divided on the length of the clip in seconds [15:08] <Keshl> I think we're stuck in an infinite loop. Shall we move on? XD [15:11] <Keshl> Regardless, I do appreciate the help you give and you not exploding on me until now. [15:11] Action: Keshl snugs at -É- [15:45] <esperegu> Keshl: fuck me. probably was a mic somewhere that was causing this. [15:46] <esperegu> Keshl: thx 4 your help [15:46] <Keshl> Welcomes, oÉo. [18:06] <FearlessPidgin> Is there any way to determine the deinterlace method needed, based on the frame types obtained from ffprobe? [18:07] <JEEBsv> no [18:08] <JEEBsv> since you can't really decide such things by that only [18:08] <JEEBsv> but in any case if you are just running with eyes closed and want to automatize you either say no to interlaced content from whomever is providing stuff to you, or you yadif all pictures noted as interlaced. [18:09] <JEEBsv> because that's the only way you're getting something semi-sane automated [18:13] <FearlessPidgin> JEEBsv: But since there are different types of interlacing (Inverse Telecine comes to mind), does yadif handle a wide range well? [18:17] <klaxa> my test encodes i did some months ago with yadif and telecined source weren't so good [18:17] <klaxa> note: months ago [18:17] <JEEBsv> it's not perfect, esp. if you default to full bobbing [18:18] <JEEBsv> but I know many people being completely OK with using normal yadif [18:18] <klaxa> back then i used fieldmatch,decimate which seemed to work better [18:18] <JEEBsv> for IVTC'd content [18:18] <JEEBsv> and heck [18:18] <JEEBsv> you can't automate IVTC [18:18] <JEEBsv> s/IVTC'd/telecined/ [18:18] <JEEBsv> anyways, the bottom line is that if you don't know what you're being fed [18:19] <JEEBsv> you can only automate stuff with yadif, pretty much [18:19] <FearlessPidgin> the problem is I don'y know what type it is, that's why I wanted to find out based on frame types so I could choose the correct deinterlace method [18:19] <JEEBsv> well the frame types don't contain anything related to that [18:19] <JEEBsv> just the coding mode [18:19] <klaxa> sounds like an AI problem to me [18:20] <FearlessPidgin> Oh... I thought the order of the interlaced frames mattered [18:20] <FearlessPidgin> klaxa: AI? [18:20] <klaxa> artificial intelligence [18:20] <JEEBsv> well, with hard telecine all you will be getting is that all pictures are coded interlaced [18:20] <JEEBsv> gather much from this other than 'shit's interlaced' [18:20] <JEEBsv> :P [18:23] <klaxa> well what one *could* try is to extract a couple of frames and try to find a pattern, as in 3 interlaced frames, 2 full frames [18:23] <klaxa> that would mean you have to judge whether or not a frame is a full frame based on its actual content [18:23] <klaxa> which could become hard depending on the content [18:23] <klaxa> however, the pattern would become easier visible with a lot of frames [18:24] <JEEBsv> well, IIRC you could mish-mash the fieldmatch filter with yadif somehow, but generally trying to automate with more complexity is very error-prone [18:24] <FearlessPidgin> yadif has to do it somehow so it can correctly deinterlace right? [18:25] <JEEBsv> no [18:28] <FearlessPidgin> Well I don't really need to automate, I just want to be sure I know what type of interlacing I'm dealing with so I can properly get it to progressive with decent quality... Is there any way to do with with some level of certainty? [18:28] <JEEBsv> using your eyes, mostly [18:28] <JEEBsv> only way of being relatively sure [18:33] <FearlessPidgin> JEEBsv: By extracting the frames and looking for patterns of interlaced frames? [18:35] <JEEBsv> well, fields to be exact, but yes. And patterns of two-fields-per-picture and one-field-per-picture, and possible duplicate pictures [18:37] <FearlessPidgin> JEEBsv: After that can yadif take input to specify a more specific interlace type? [18:38] <JEEBsv> well, after you have already checked the content you can then already make the decision on which type of 'creating progressive content out of whatever you have on hand' you need to use [18:38] <JEEBsv> or multiple ones, depending on if it's mixed content [18:38] <JEEBsv> (always fun) [18:38] <FearlessPidgin> oh god [18:40] <FearlessPidgin> Next question then, how to dump all frames, or a large amount of frames, to images? [18:41] <JEEBsv> personally if I were to want to do things properly I'd look into frame servers instead of ffmpeg :P [18:41] <JEEBsv> or something that uses frame-exact methods and lets you check the content, and do stuff like SeparateFields() easily [18:42] <FearlessPidgin> JEEBsv: Any examples of what your talking about? [18:42] <JEEBsv> avisynth or vapoursynth [18:46] <FearlessPidgin> JEEBsv: So you would dump to images with avisynth? [18:47] <JEEBsv> no, I would use AvsPmod to scroll through the clip [18:47] <JEEBsv> and look at various parts [18:49] <FearlessPidgin> "look for various parts"? [18:49] <JEEBsv> at [18:49] <JEEBsv> as in, go through the clip's various parts and see what kind of content there is [18:49] <FearlessPidgin> ah [18:50] <JEEBsv> (telecined, true interlaced, etc.) [18:50] <JEEBsv> and when I've gotten enough spots from it done, I then proceed to handling the source correctly [18:50] <FearlessPidgin> JEEBsv: Would you then yadif after you found out, or use something built into avisynth to do the deinterlacing and feed into ffmpeg? [18:51] <JEEBsv> yeah, I would then proceed to using TIVTC or QTGMC or whatever is the best tool for the job in avisynth. And then that I would pipe with avs2pipemod or something into ffmpeg or whatever [18:53] <FearlessPidgin> JEEBsv: I really appreciate the help [18:55] <FearlessPidgin> JEEBsv: What do you think about DGIndex? [18:55] <FearlessPidgin> I think that does a sort of frame analysis ? [18:55] <JEEBsv> DGindex or the d2vsource thingamajig can be used for MPEG-2 input reading [18:55] <JEEBsv> it doesn't do any ANALYSIS [18:56] <JEEBsv> as in, worthwhile analysis for your problem :P [18:56] <JEEBsv> the analyzer will be _you_ [18:56] <FearlessPidgin> ah ok [18:56] <JEEBsv> looking at the pictures (fields, frames) [18:57] <FearlessPidgin> since I'm on windows none of this is a problem, but I feel like the Linux guys are left behind when it comes to weird interlacing [18:58] <JEEBsv> avisynth has worked on wine for over 10 years now [18:59] <JEEBsv> so they're really not [18:59] <JEEBsv> and if they want something similar there's always the reimagining called vapoursynth [18:59] <JEEBsv> which is cross-platform [20:48] <mikeflynn> I'm looking for a little ffmpeg help if anyone can lend a hand. I just posted this stackoverflow question, but I'm happy to rehash the details in here if that's preferred: http://stackoverflow.com/questions/22024376/ffmpeg-2nd-pass-segfault [21:02] <llogan> mikeflynn: SO is for programming questions. next time FFmpeg cli tool questions can be asked at Super User (or ffmpeg-user mailing list) [21:03] <llogan> also your complete console output is required. [21:03] <mikeflynn> Good point. [21:03] <mikeflynn> Ok, one second. [21:03] <llogan> why are you not simply using a libx264 encoding preset? [21:04] <mikeflynn> I didn't start from scratch, I'm trying to recreate an existing and working transcoding server to a new enviroment so I don't have any of the original context for these decisions. [21:06] <llogan> why 2-pass? are you trying to get a certain output file size? [21:07] <mikeflynn> 2-pass is what the current codebase calls. I was hoping to get this up and running without having to do any major code surgery, but at this point I'm open to anything. [21:09] <llogan> start with something like this: ffmpeg -i input -vcodec libx264 -preset slower -crf 23 -acodec libfaac -q:a 100 output.mp4 [21:09] <llogan> the "slower" preset is probably closest to your previous, messy settings. [21:11] <mikeflynn> That command in place of the 2nd pass, or replacing both passes? [21:11] <mikeflynn> Here's the full output of the failing 2nd pass: http://pastebin.com/1Kuc7W5F [21:13] <llogan> i'm assuming you don't need two passes, so you can just use one pass using -crf. [21:14] <llogan> https://trac.ffmpeg.org/wiki/x264EncodingGuide [21:14] <llogan> https://trac.ffmpeg.org/wiki/AACEncodingGuide [21:14] <llogan> use the highest crf value that still give an acceptable quality. use the slowest preset you have patience for. use those settings for the rest of your videos. [21:15] <mikeflynn> Yeah, I was going through that last night. I'm just wary to modify this setup too much, as crazy as it might be. This confirmation helps though, I'll dive in for surgery! [21:15] <mikeflynn> Ok [21:15] <llogan> but your input is already H.264 and AAC, so just don't re-encode. [21:16] <mikeflynn> This one was h.264/aac but will have other sources: flv, avi, etc.. [21:16] <mikeflynn> (video upload site) [21:18] <llogan> what is the output file going to be used for? [21:18] <elf__> hi, I have a question. I have a video file, I am trying to extract the audio to a wav file using " -acodec pcm_s16le -ac 2 -f wav output.wav". But if I change output.wav to be just - (-acodec pcm_s16le -ac 2 -f wav - | hexdump), there is a difference. The header of the wav file has a chunk size. The output.wav has a valid value but the output to the command line always has zero. Has anyone seen this before and is there a known work around? [21:21] <mikeflynn> @llogan - Web display through a flash or html5 player. [21:22] <llogan> add "-movflags +faststart" and "-pix_fmt yuv420p" [21:28] <mikeflynn> Great, thanks. Again, I was nervous to change what they had too much, but this conversation gives me a little more confidence. [21:28] <mikeflynn> I appreciate the help! [00:00] --- Wed Feb 26 2014

1 0

ffmpeg-devel.log.20140224
by burek 25 Feb '14

25 Feb '14

[00:00] <cone-688> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.1.4': unknown revision or path not in the working tree. [00:00] <cone-688> Use '--' to separate paths from revisions [00:00] <cone-688> refs/tags/n2.1.4:HEAD: Merge remote-tracking branch 'qatar/master' [02:37] <cone-688> ffmpeg.git 03James Almer 07master:313a6c65b749: oggdec: validate VP8 keyframes [07:39] <ubitux> BBB: seems your x86 32-bit statement was not very popular, but that was expected ;) [08:39] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:a66be608883d: swresample: add swr_is_initialized() [08:39] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:6c6e4dd13915: swr: check that the context for swr_convert() has been initialized [08:39] <cone-707> ffmpeg.git 03James Almer 07master:3f3d748cab38: x86: Move XOP emulation to x86util [08:47] <llogan> i know i've developed a problem when i begin typing words with two ff-s. "fflag". [08:47] <llogan> *two "f"s [09:20] <cone-707> ffmpeg.git 03Anton Khirnov 07master:746dca483a2f: avconv: support forcing codec tags for input streams [09:20] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:cc6cc84bc4e0: Merge commit '746dca483a2f0f2639265f6e1c0085c8861875a1' [09:20] <plepere> michaelni, I've redone my patches. Should I submit them back to ffmpeg-devel or just to you ? [09:21] <michaelni> plepere, there where multiple people commenting, they couldnt comment if you submit them just to me [09:22] <plepere> ok. [09:23] <plepere> where do I be part of the mailing list once my changes are accepted ? I'll have to be part of it if ever someone asks something about the HEVC ASM [09:26] <plepere> submitted [09:27] <plepere> oh and found how to subscribe to ffmpeg-devel. :p [09:33] <ubitux> plepere: did you the reviews from the others on ffmpeg-devel then? [09:33] <plepere> I only had a reply from michaelni [09:34] <ubitux> only michael put you in cc i guess [09:34] <ubitux> see http://ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154890.html and http://ffmpeg.org/pipermail/ffmpeg-devel/2014-February/154870.html [09:35] <plepere> ok thanks. :) [09:39] <plepere> well,looks like I still have lots of work ! [09:43] <plepere> so now that I am part of the mailing list, I will see the other messages ? [09:51] <cone-707> ffmpeg.git 03Anton Khirnov 07master:1155fd02ae7b: frame: add a convenience function for copying AVFrame data [09:51] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:fff526230148: Merge commit '1155fd02ae7bac215acab316e847c6bb25f74fc3' [09:55] <cone-707> ffmpeg.git 03Michael Niedermayer 07release/2.1:c7c724056ef4: avcodec/h264: clear chroma planes when flags gray is used [10:19] <ubitux> trac down again? [10:47] <cone-707> ffmpeg.git 03Anton Khirnov 07master:8feac29cc462: lavc: use AVFrame API properly in ff_reget_buffer() [10:47] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:74bb1ca82c3b: avutil/frame_copy_audio: also check that channels match [10:47] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:7a9946d386a3: Merge commit '8feac29cc46270cc89d6016340e7bac780877131' [10:55] <plepere> michaelni, I've changed some stuff as indicated in the other reviews. not all of them, as rsbultje suggested something that would require some higher-level changes. Do I have to redo a new e-mail ? [10:56] <michaelni> plepere, best to talk to / ask BBB (rsbultje) [10:56] <plepere> ok [10:57] <michaelni> ubitux, trac seems up ? [10:58] <cone-707> ffmpeg.git 03Anton Khirnov 07master:30517a9f056c: Use av_frame_copy() to simplify code where appropriate. [10:58] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:2a3cb1cfcaf4: Merge remote-tracking branch 'qatar/master' [10:58] <ubitux> michaelni: OperationalError: database is locked [10:58] <plepere> well the question was more like : I've submitted an e-mail this morning without seeing all of the reviews. can I submit another e-mail now that I've seen the other reviews and fixed most things ? [10:59] <michaelni> plepere, yes of cousre you can [10:59] <nevcairiel> your previous mail didn't show up on the mailing list yet anyway :p [11:00] <plepere> ok. :) [11:08] <plepere> there, sent [11:08] Action: plepere crosses fingers [11:10] <ubitux> there are a lot of unrelated cosmetics... [11:10] <ubitux> like, what the hell happened in hevcdsp_template.c? [11:11] <plepere> changed epel and qpel C functions [11:11] <ubitux> i'm not talking about that [11:11] <ubitux> look at your diff [11:11] <plepere> hmmm [11:11] <ubitux> it's like you based your work on an old ffmpeg [11:11] <ubitux> and didn't rebase correctly [11:12] <ubitux> also, just squash the patches [11:12] <ubitux> and split them appropriately [11:13] <plepere> oh yeah. sorry. :/ [11:14] <ubitux> i see the patches honoring a bunch of my comment; you should just squash them in the original patch [11:14] <plepere> ok, so I do a single patch with the different commit messages ? [11:15] <ubitux> well you'll probably keep only one message for all the changes [11:15] <ubitux> of course, if it makes sense to split, do it [11:15] <ubitux> but don't send additional patches after each iteration [11:15] <ubitux> the split should be feature/bug wise, not review-iteration wise [11:15] <plepere> ok [11:23] <ubitux> trac repaired, cool [11:36] <plepere> ubitux : can I send you the new patch files before doing again another mail ? [11:37] <ubitux> send "me"? why? :) [11:37] <plepere> I'm embarassed of sending plenty of mails. :/ [11:37] <ubitux> just spam, no worry [11:37] <plepere> ok ok [11:38] <nevcairiel> we all started somewhere, every time you learn more, and the next time you won't need as many mails :) [11:38] <plepere> yeah. :) [11:39] <plepere> well I haven't (yet) forgotten to add the attached files. :D [11:39] <plepere> voila ! [11:40] <plepere> bbl [11:40] <nevcairiel> Now that you are subscribed to the ML, what you should do when sending new versions is trying to respond to your previous mail, so its clear that its a new version [11:40] <plepere> ok. I'll try to think of that next time. [11:41] <nevcairiel> from a brief look, the first patch at least looks better now, no unrelated formatting changes or anything like that [11:44] <nevcairiel> it might make sense to split the second in two, one for qpel/epel and one for MC [11:46] <nevcairiel> oh there is only the pel functions in there, nevermind then [11:46] <nevcairiel> i got confused [11:46] <ubitux> plepere: try to reply in the thread you started though, that's easier to track [13:05] <BBB> ubitux: re: 32bit asm, yes I expected some comments re: that [13:06] <BBB> ubitux: and I basically don't care - if someone wants to port it, please do, I think it's an awesome idea; but I don't think I'll want to do it myself, at least not right now [13:06] <ubitux> oh i agree you know [13:06] <ubitux> > Especially compared to VP9 which seems to encode using a wooden abacus [13:06] <BBB> plepere: you know, all these macros make the main code very hard to understand, right? [13:06] <ubitux> seems i'm not alone ^ \o/ [13:06] <BBB> lol [13:07] <BBB> plepere: asm is nice to read if you can see exactly from the cglobal what it does, typically only idct does this differently because idct uses the same loop x2 [13:07] <BBB> (or iadst) [13:07] <BBB> plepere: but I'll read your new patches before saying anything more... [13:08] <BBB> plepere: do you have numbers on how much faster the mc functions for each size get, or decoding in general on a particular clip that uses mc a lot? [13:19] <plepere> BBB : I can do some tests. we usually use ra_main basketballDrive qp 27 for our performance tests. [13:28] <BBB> plepere: sure, pick whatever you want :) [13:28] <BBB> plepere: pick something you like - you'll be using it for a long time to come :-p [13:28] <plepere> time make fate-hevc SAMPLES=samples/ -j 6 gives me 17.543 without ASM and 15.056 with. [13:29] <smarter> if you do that your testing both the decoder and the performance of your OS scheduler :] [13:29] <smarter> *you're [13:29] <plepere> ok ok [13:30] <smarter> you can use ffmpeg -benchmark -i ... [13:30] <smarter> -f null - [13:31] <plepere> is it useful to test single threaded performance ? or should I just settle with the default settings ? [13:31] <smarter> single threaded is useful yes [13:31] <plepere> -threads 1 right ? [13:31] <smarter> I think so [13:31] <BBB> plepere: we typically do asm changes with single threading [13:31] <BBB> time ffmpeg -threads 1 -i file -f null -v 0 -nostats - [13:32] <BBB> or if you use START/STOP_TIMER, use -v error [13:32] <BBB> (otherwise it won't print anything) [13:33] <plepere> it still seems multi-threaded. I might need to tweak the thread_type [13:33] <BBB> default is frame [13:33] <BBB> that should be ok [13:33] <BBB> but don't use multithreaded to measure asm changes [13:34] <plepere> I've got the same times with or without threads 1. :/ [13:34] <plepere> and they are too good to be single threaded [13:34] <smarter> what about -threads 0 ? [13:35] <plepere> same [13:35] <BBB> it's -threads 1, before -i [13:35] <BBB> what's your exact commandline? [13:35] <plepere> ah, before -i. [13:35] Action: plepere facepalms [13:35] <BBB> order matters :) [13:35] <BBB> anything before -i is input [13:36] <BBB> anything after -i is output [13:36] <plepere> ok. :) [13:37] <plepere> 21.552 [13:38] <plepere> 26.377 [13:38] <plepere> nice speed-up. :D [13:38] <smarter> nice. [13:38] <smarter> do you know if MC is still the bottleneck? [13:39] <plepere> in our home-version, we are looking into the intra-pred now [13:39] <smarter> cool [13:39] <plepere> the intrinsics really boost the decoding. [13:40] <BBB> depends on intra rate, clearly [13:40] <plepere> I'm around 8.5 seconds on this sequence on our latest version I think [13:40] <smarter> just because of intra intrinsics? [13:41] <plepere> no [13:41] <plepere> with everything enabled [13:41] <plepere> on BasketBallDrive qp27 [13:41] <plepere> ra [13:42] <BBB> I think this whole "working on 2 repositories" is a terrible idea [13:42] <BBB> that might just be me, I don't know [13:42] <BBB> I wonder if the intrinsics automatically unroll the h-loop in MC, which should give more gains [13:42] <BBB> if you didn't unroll it already in your next patch [13:43] <plepere> BBB : the problem is that for a single idx, there can be multiple widths [13:43] <sspiff> ubitux: I remember somebody worked on the teletext subtitle codec the past few months. Is there a way I can get in touch with him? [13:43] <BBB> plepere: what is an idx [13:43] <plepere> it's the index we use to know how large the block is (and therefore calling the h4, h8 or h16) [13:44] <BBB> so it's block size, and then each block has some form of partitioning? [13:44] <plepere> it's from the log of the size coding block [13:44] <BBB> so which widths exist in a idc of, say, h16? [13:44] <smarter> 8x16 and 16x16 only I think [13:44] <sspiff> anyone else is free to help me as well, of course. I just remember ubitux mentioned the work, so I figured he would know. [13:44] <BBB> oh, h=height? [13:44] <plepere> 32 and 64 [13:44] <BBB> refactor the code so w is constant [13:44] <BBB> unroll more levels if uyou have to [13:45] <BBB> fixed width is immensely important [13:45] <plepere> well the problem is when the width has values like 12 or 24 [13:46] <plepere> BBB : I'm going to see which widths are associated to which index. I can unloop those with a singlewidth value [13:46] <plepere> or do you think an if/else at the start of the function could be enough ? [13:47] <ubitux> sspiff: git log -i --grep teletext raises Serhii Marchuk and Marton Balint as last contributors [13:47] <smarter> plepere: in what case is width 12 or 24? [13:47] <plepere> like in h4, width = 4 or 12. I do an in/else on width to the correct function [13:48] <plepere> I think it goes like this : h2 => w = 2 or 6. h4 : w= 4 or 12. h8 : w = 8 or 24; h16 : w = 16, 32, 64 [13:50] <sspiff> ubitux: thanks. Sorry about the useless question. [13:56] <plepere> so I could do an if/else in each function to know if we're on one width or another [13:57] <BBB> plepere: 12 is simlpe: 8 and 4 [13:57] <BBB> plepere: 24 is even easier, assuming it's all in 8-width iterations: 3x8 (i.e. 8, 8, 8) [13:57] <plepere> all are pretty simple. [13:57] <plepere> BBB : I have a 16 width iteration [13:58] <BBB> right, but the loop takes enormous overhead if you don't unroll it, esp. for such small loops [13:58] <BBB> 16 pixels per iter? [13:58] <plepere> so I can do 16 + 8 [13:58] <BBB> or 16 bits per iter? [13:58] <plepere> yes [13:58] <BBB> hm, ok, 16 + 8 is even better then [13:58] <plepere> 16 pixels [13:58] <plepere> since the source is 8-bit, I can grab 16 per load [13:59] <plepere> of course, once you go to 10-bit, you only go up to 8 [13:59] <BBB> sure, I guess it's the same as vp9's 16width unroll, it's essentially 2 8 combined right? [13:59] <BBB> becuase the intermediates must be 16 bits [13:59] <plepere> I do 2 stores, but the rest is the same, yes [14:00] <BBB> 2 stores? [14:00] <BBB> why [14:00] <BBB> you can packuswb in the end right? [14:00] <plepere> output of qpel/epel is on 16-bit [14:00] <BBB> or is that b/c weighting requires 16bit input? [14:00] <plepere> yes [14:00] <BBB> ok [14:01] <plepere> so unless we put the weighting in the pel functions... [14:01] <BBB> which we should :-p [14:01] <BBB> eventually [14:01] <plepere> but that's a huge chunk of work, and the number of functions quadruples [14:01] <BBB> sure, if it helps speed, that's totally ok [14:02] <BBB> (helps by a _lot_, not by 1-2 cycles per block) [14:02] <plepere> we did the change in intrinsics, but did not see any significant change [14:02] <BBB> well yes, but [14:02] <BBB> intrinsics [14:02] <BBB> I mean, lol [14:02] <plepere> :p [14:03] <BBB> you have no idea what actually changed in terms of real code [14:03] <BBB> ok work, bbl [14:03] <BBB> I'll try to look at your patches [14:03] <plepere> it's faster than C . :D [14:03] <plepere> thanks a bunch, BBB [14:03] <nevcairiel> if you dont use the compound intrinsics, in my experience it maps pretty nicely to asm, at least in MSVC, no experience with GCC [14:14] <kurosu_> plepere: have you rewritten SAO to use pshufb? it may be non-negligible too [14:15] <kurosu_> 26s -> 21s decoding seems a bit low if the 26s used C code for MC - but what do I know [14:15] <plepere> the sao is being worked on too. [14:15] <plepere> kurosu_, it's only epel_h, epel_v, epel_hv, qpel_h, qpel_v. [14:16] <plepere> so all the idct, weighting and all aren't done [14:16] <plepere> so it's "only" the 4 and 8 tap filters being done in ASM in that patch [14:16] <plepere> and the 8-tap HV isn't done either. [14:40] <kurosu_> plepere: vc1 and rv40 were closer to eg 26->17 without the rest being optimized [14:40] <kurosu_> but probably hevc is needlessly complex in other parts :D [14:42] <plepere> we did some other high level C optimizations, and as BBB noted, I'm not unrolling the loops in assembly [14:42] <kurosu_> 8 tap HV? you mean only the 1D filtering (either vertical or hor) is done? then it makes sense [14:42] <plepere> yes, the 2D isn't done. [14:42] <plepere> the 2D 4-tap is done though [14:42] <kurosu_> that's like half of them and probably the most consuming ones [14:42] <plepere> :) [14:42] <kurosu_> if they aren't done yet, the timing makes more sense [14:42] <plepere> ok ok [14:42] <kurosu_> I expect closer to 17 once they are done [14:43] <plepere> I'll have to see how to make everything fit in 15 xmm registers first ! [14:43] <kurosu_> I have no idea, as I haven't looked at the code [14:43] <plepere> it's my job. [14:43] <plepere> :D [14:44] <kurosu_> are you loading the filter coefficients in regs? if yes, you can probably skip loading them and just do pmaddusb xmm, [filter] [14:44] <kurosu_> (or whatever the insn name is) [14:44] <plepere> kurosu_, well I'm loading them once, so I don't have to do it in the loop [14:45] <kurosu_> yeah, but they are eating regs you seem to be in greater need of [14:45] <plepere> I'll remember to do that if I'm in need of registers. :) [14:45] <kurosu_> anyway, I'm uninformed on the topic of your asm so I'm probably spewing nonsense :) [14:47] <plepere> I'll look how they do it in vp9. they look like competent people. [14:58] <sspiff> how can I change codec-private options? I've tried av_opt_set() on an AVCodecContext (where I get AVERROR_OPTION_NOT_FOUND), and on an AVCodec (where it succeeds, or at least returns 0, but segfaults down the line...) [14:59] <sspiff> is the latter approach correct, and is this just a bug in the codec? [14:59] <sspiff> or is there a third option I'm missing? [14:59] <nevcairiel> use AVCodecContext->priv_data [15:06] <smarter> <plepere> I think it goes like this : h2 => w = 2 or 6. h4 : w= 4 or 12. h8 : w = 8 or 24; h16 : w = 16, 32, 64 [15:06] <smarter> I'm confused by these numbers, when exactly do you have something that has width 6 ? [15:08] <plepere> in BasketBallDrive, ra, qp27 [15:08] <plepere> I've added a printf giving me H and W in epel_h [15:08] <plepere> and I've got numerous instances of H= 2 W = 6 [15:09] <plepere> anyways, I've got to go. sorry. [15:09] <plepere> I'll read when I'm coming back [15:09] <smarter> but prediction blocks can't be 6x2 [15:09] <smarter> or is it something to do with edges? [15:10] <plepere> yes, it's strange. I'd rather not have such cases too. I'll see with mraulet. [15:11] <plepere> well when I say H, it's unrelated to the height of the block [15:11] <plepere> it's just the name of the function [15:11] <plepere> sorry for the confusion [15:12] <smarter> ah, I forgot about the weird inter-only Prediction Blocks [15:12] <plepere> basically, int idx = log2_cb_size - 2; for idx = 0, we use h2, for idx = 1, we use h4, idx = 2, h8 [15:13] <plepere> but that means that for idx = 0, we have width = 2 or 6 [15:13] <plepere> really gtg. leave me PMs [15:13] <smarter> which can be split into things like w=x,h=4*x and w=3*x,h=4*x [15:13] <smarter> bye! [15:20] <sspiff> nevcairiel: so privdata is in fact not private? [15:21] <nevcairiel> you want to set a codec private option, they are in priv_data, since thats the codec private data :p [15:21] <nevcairiel> so use that as the first param of the av_opt functions [15:21] <sspiff> nevcairiel: so I'm doing something I shouldn't do, generally? [15:21] <nevcairiel> why [15:22] <sspiff> I don't know, I generally thought I shouldn't mess with priv_data/priv/... fields in structs? [15:22] <sspiff> by the way, is there any reason why the av_opt_set call succeeds on the AVCodecContext? [15:26] <nevcairiel> if it makes you feel better inside, you can also call it on AVCodecContext directly and set the AV_OPT_SEARCH_CHILDREN flag in the last param, it'll automatically descend into priv_data then [15:27] <nevcairiel> i guess this is more of the "official" way to do it [15:28] <julienb> Hello [15:28] <julienb> I contact the room because i would like to know if it's possible to cut videos from the end with ffmpeg. [15:28] <av500> wrong room, use #ffmpeg [15:29] <julienb> ok thanks [15:44] <sspiff> nevcairiel: thanks for the tip :) [17:00] <Daemon404> "Especially compared to VP9 which seems to encode using a wooden abacus [17:00] <Daemon404> (~1.4 minutes per frame). [17:00] <Daemon404> i loled irl [17:01] <ubitux> i quoted it earlier :)) [17:01] <thardin> hah [17:11] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:d3736471948c: libx265: Update API usage [17:11] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:d102925a6d4a: libx265: Support 4:4:4 [17:13] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:73ee4cf3073b: libx265: Support SAR [17:13] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:87769d6c8f6d: libx265: Properly handled dynamic linking with MSVC [17:13] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:6d18154f61d1: libx265: Use proper error code [17:14] <Daemon404> slow bot is slow [17:15] <nevcairiel> shouldnt x265 init internal bitdepth to something useful on its own [17:15] <sspiff> hmmmm, building ffmpeg doesn't produce ffplay for me, and there doesn't seem to be a makefile for it. Configure seems to have a --disable-ffplay, but --enable-ffplay didn't work. How do I build ffplay? [17:15] <nevcairiel> you're probably lacking a dependency [17:15] <nevcairiel> ffplay needs SDL [17:17] <ubitux> we should probably add an entry in the faq [17:17] <ubitux> that ffplay is often asked [17:17] <ubitux> not sure ppl look that much into that faq though [17:17] <nevcairiel> ideally configure could somehow tell you [17:18] <nevcairiel> if you ask for an explicit --enable-ffplay, it tells you when something is missing [17:20] <ubitux> the difference between explicit user request and enabled feature is always a bit tricky with the build system [17:22] <Daemon404> g 31 [17:22] <Daemon404> ffs [17:26] <sspiff> nevcairiel: thanks. I didn't read the FAQ for this I must admit. [17:26] <nevcairiel> I have no clue whats in the FAQ or isnt [17:27] <nevcairiel> never read the thing [17:27] <sspiff> nevcairiel: ./configure produces a lot of output, so if the warning is early on, I probably missed it [17:27] <nevcairiel> it probably doesnt warn [17:27] <nevcairiel> but it should [17:27] <sspiff> it doesn't [17:27] <sspiff> I just checked [17:28] <sspiff> not even sure the --enable-ffplay is really a thing (./configure --help doesn't mention it) [17:28] <sspiff> but I assume ./configure wouldn't just disregard non-existant flags [17:28] <nevcairiel> its technically a thing, but ffplay is also enabled by default [17:28] <nevcairiel> but of course only build when deps are present [17:29] <Daemon404> the better question is [17:29] <Daemon404> why do you want to use ffplay [17:29] <Daemon404> its uselss to everyone but devs [17:29] <nevcairiel> I only use it for occasional testing, easier than trying to transcode with ffmpeg and viewing the resulting file for artifacts :p [17:29] <ubitux> Daemon404: testers? [17:29] <kierank> useful for mucking around with libavfilter [17:29] <Daemon404> aka devs [17:29] <kierank> not really [17:29] <ubitux> no, bug reporters [17:29] <sspiff> Daemon404: testing, I'm writing a subtitle tool thing, and I'm encountering issues with libzvbi-teletext [17:30] <kierank> for your filter chains [17:30] <ubitux> and indeed testing filter chains [17:30] <ubitux> i actually use it as a user... for looking at images now [17:30] <sspiff> works fine in VLC's zvbi codec, but subtitle pages are said to be empty by ffmpeg [17:30] <Daemon404> im going to go out on a limb and say most bug reporters cant build things [17:30] <ubitux> since feh (imlib2) doesn't seem to support tga and bmp correctly here [17:30] <kierank> Daemon404: there are packages [17:30] <Daemon404> ubitux, i use feh too [17:31] <Daemon404> but why do you want ta [17:31] <Daemon404> tga* [17:31] <Daemon404> lul [17:31] <ubitux> because there are a lot of tga in the wild? [17:31] <Daemon404> well i use feh solely or desktops [17:31] <Daemon404> i.e. bg [17:31] <Daemon404> no as an image viewer [17:31] <ubitux> i use it to look as an image viewer [17:31] <ubitux> but ffplay is actually better ;) [17:31] <Daemon404> is thats the best foss has to offer, then it is a sad world [17:32] <sspiff> ubitux: that's kind of ... depressing [17:32] <ubitux> anyway, ffplay is useful when ppl report bugs in mplayer/mpv/vlc because it crashes in libavwhatever [17:32] <ubitux> "does it work with ffplay?" [17:32] <wm4> sspiff: AFAIK ffmpeg's teletext decoder has some issues with multiple pages [17:32] <sspiff> wm4: it only picks up one page (888) [17:32] <wm4> sspiff: the subtitle decoder interface wasn't made for it [17:32] <Daemon404> g 42 [17:32] <wm4> not sure how this was solved [17:32] <wm4> maybe you have to explicitly request a page or something [17:33] <sspiff> wm4: you can, but by default it produces subtitles for all pages [17:33] <sspiff> which, well, wouldn't work well if there were actually other pages. [17:33] <sspiff> I think [17:33] <sspiff> right now, it seems like my PES stream contains only page 888 [17:33] <sspiff> but ffmpeg thinks they're all transparant spaces [17:34] <wm4> this stuff is relatively new [17:34] <sspiff> while VLC, using the same VBI parser (zvbi) actually produces subtitles [17:34] <wm4> so there might be bugs [17:34] <sspiff> wm4: I'm fine with bugs & fixing them. I'm pretty sure this is a bug I'm encountering. [17:35] <sspiff> I'm just not very good at asking the right/proper questions and getting answers :) [17:35] <sspiff> And maybe I should look harder at the code :) [20:08] <JEEB> did FFmpeg get into GSoC? [20:09] <Daemon404> isnt the list public [20:10] <nevcairiel> if the list is complete already, then no [20:13] <Daemon404> [FFmpeg-devel] Fw: [FFmpeg] Your organization application has been rejected. [20:14] <Daemon404> shocking [20:14] <thardin> :/ [20:14] <Daemon404> nobody expected it to be accepted [20:15] <tbarletz> Daemon404: how com? [20:16] <tbarletz> come, even [20:18] <JEEB> k [20:18] <JEEB> so as expected [20:19] <J_Darnley> Same reason as last year? They won't want to take sides on the FFmpeg-Libav war? [20:20] <wm4> lol gsoc [20:20] <Plorkyeran_> libav didn't apply this year though [20:26] <iive> did I miss the party? http://tech.slashdot.org/story/14/02/23/0544243/ffmpegs-vp9-decoder-faster-… [20:27] <llogan> GWoT: Google Waste of Time [20:28] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:a908de7f4944: avformat/options_table: add named constants for avoid_negative_ts [20:28] <iive> gsoc was really beneficial. It brought quite a few good developers who stayed around after the task. [20:37] <Mavrik> hmm, do we have any sample of a TS file with DTS wraparound? [21:02] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:d00a504b244e: libx265: Update API usage [21:02] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:a88cbdfb90e4: Merge commit 'd00a504b244e136a0c82a55e21ed94659e0674ad' [21:03] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:2142b2efcd63: libx265: Support 4:4:4 [21:03] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:3d53bbd0ac06: Merge commit '2142b2efcd631db05e4c7c26785e337ecf1258ff' [21:05] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:0f7fa48cf1a3: libx265: Support SAR [21:05] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:e1991c7d5f3a: Merge commit '0f7fa48cf1a36ed135c9e0cb01a6b84179aea25b' [21:07] <cone-707> ffmpeg.git 03Derek Buitenhuis 07master:8aca00cc2b25: libx265: Properly handled dynamic linking with MSVC [21:07] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:e66247e926aa: Merge commit '8aca00cc2b25810bdd85b75f5632844a5614b707' [21:09] <rcombs> Mavrik: <24 hours later> [21:15] <Mavrik> ^^ [21:17] <nevcairiel> TS timestamp wrap is at 26 hours, duh :p [21:44] <cone-707> ffmpeg.git 03Anton Khirnov 07master:67f2a688143b: avconv: remove a write-only variable [21:44] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:70a25587d223: Merge commit '67f2a688143b644f99360565a9f36c61a5f052e9' [21:56] <Mavrik> indeed >( [22:00] <wm4> TS wraparound sucks and I'm still not sure how to handle it robustly [22:03] <Mavrik> mhm, that's why I'm asking if anyone has a sample of it... otherwise I'm off to waiting 26hrs :P [22:03] <Daemon404> nevcairiel and kierank maybe? [22:03] <Daemon404> wh do you want one? because you want to see ffmpeg murder itself? [22:03] <kierank> wm4: the proper way to do it is to maintain a timestamp file [22:03] <kierank> with an index [22:04] <Daemon404> set top boxes obvious dont do this [22:04] <wm4> kierank: I mean just for playback [22:04] <wm4> which set top boxes do [22:04] <kierank> Daemon404: why? [22:05] <Daemon404> because how can a live stream be indexed? [22:05] <kierank> a live stream is different [22:05] <kierank> because you don't need to seek [22:05] <Daemon404> true [22:06] <Daemon404> the index should be pretty easy in theory [22:06] <Daemon404> getting lavf to not fuck with stuff might be harder [22:06] <wm4> lol [22:06] <wm4> utils.c? [22:08] <nevcairiel> the problem is that stuff records live streams and doesnt write an index file, and people of course expect playing and seeking them [22:09] <wm4> seeking could be done somewhat reasonably if the API allowed relative seeking [22:09] <wm4> so seeking would mean "skip 5 seconds of video", not "seek to time XX:XX:XX" [22:10] <nevcairiel> people like full random access [22:10] <cone-707> ffmpeg.git 03Anton Khirnov 07master:dcc7e4bf1d09: af_resample: preserve frame properties [22:10] <wm4> if they just want interactive seeking around, byte based seeking can handle that just fine [22:11] <Daemon404> something something ffms2 [22:11] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:fc10ed2cac71: Merge commit 'dcc7e4bf1d0913123bfafbc58bf47bd41dd5848d' [22:11] <nevcairiel> unsuitable for playback daemon404 [22:11] <Daemon404> in which way [22:11] <Daemon404> i rigged it up for playback before [22:11] <nevcairiel> huge startup [22:12] <nevcairiel> delay [22:12] <Daemon404> basically your complain is "indexing" [22:12] <Daemon404> which was my point [22:19] <cone-707> ffmpeg.git 03Anton Khirnov 07master:39c2880eeae6: af_volume: preserve frame properties [22:19] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:6b06f9f1bc4c: Merge commit '39c2880eeae6930b1036ce1f479afc1e1152c13f' [22:28] <cone-707> ffmpeg.git 03Vittorio Giovara 07master:48d1ed9c83ee: doc: name correct header [22:28] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:26dad980baaa: Merge commit '48d1ed9c83ee0c388e8c2898e81ffb4add509ab9' [23:06] <cone-707> ffmpeg.git 03Vittorio Giovara 07master:c91488ab3367: doc: fix one accented word [23:06] <cone-707> ffmpeg.git 03Michael Niedermayer 07master:75f6ed8dc232: Merge remote-tracking branch 'qatar/master' [00:00] --- Tue Feb 25 2014

1 0

ffmpeg.log.20140224
by burek 25 Feb '14

25 Feb '14

[01:01] <Snowleaksange> ok got video x264 flv video streaming working to my browser [01:01] <Snowleaksange> not yet audio tho [01:01] <Snowleaksange> last major issue w ffmpeg upgrade for osx [01:01] <Snowleaksange> FFMpeg: Crushing your soul for an entire weekend every 2 years in exchange for streaming capabilities [01:02] <Snowleaksange> if i can finish audio encoding, some minor guess_format issue, and windows porbability by tonight, ill have upgraded ffmpeg in a single weekend [01:05] <Snowleaksange> i msut admit the code and the binary build distribution both seems more professional [01:05] <Snowleaksange> as does the resampling lib [01:34] <rjp421> Snowleaksange, streaming to a server? [02:33] <Logicgate> Hey guys, is closed captioning stored in a separate file or it is extractable from an actual video [02:49] <rcombs> Logicgate: "closed captioning" is used to mean a lot of things, some of which are correct meanings of that term. What are you referring to, more specifically? [02:53] <Hello71> strictly speaking, closed captioning must be stored separately [02:53] <Hello71> or else it's just captioning. [02:56] <rcombs> Hello71: captions can definitely be stored in the same file as the video they accompany and still be closed [02:56] <rcombs> just as long as they're not burned into the video stream [02:58] <Hello71> "separately", not "separate file" [02:58] <Hello71> one file is still separately ;) [02:59] <rcombs> ah, I misparsed [03:00] <Hello71> poor wording. :) [03:26] <DjMadness> i seam to be having issues doing any sort of video playback, ie mplayer2 does not do any playback, same with dragonplayer the image is shown when i fast forward, but the actual playback does not happen (in xbmc the audio plays but there is a black screen where the video should be), has anyone heard of this before and is there a solution to this ? [03:27] <DjMadness> hard to explain 100% its like the video is paused in mplayer2 and dragonplayer [04:01] <oxez> hello, is there a parameter that would let me grab my second monitor (1920x1080, +1920 on X axis) and resize on the fly? The --video_size switch only changes the area that's grabbed, it does not resize [04:01] <oxez> ffmpeg -r 30 -f x11grab -i :0.0+1920,0 -q:v 1 output.avi -- that's what I'm using right now [05:16] <krabador> hi people, i've http://pastie.org/8763696 [05:16] <krabador> when i try to compile xbmc git [05:28] <llogan> krabador: install yasm [05:29] <krabador> llogan, i'm using archlinux x86_64 [05:29] <llogan> oxez: use the scale video filter as an output option: -vf scale=1280:-1 [05:29] <krabador> and i've ffmpeg installed [05:30] <llogan> oxez: http://ffmpeg.org/ffmpeg-filters.html#scale [05:30] <llogan> krabador: the If you think configure made a mistake... [05:30] <llogan> is from FFmpeg [05:35] <krabador> llogan, thanx [05:35] <krabador> i installed yasm [05:35] <krabador> and it works [05:35] <llogan> it's probably not using your ffmpeg [05:36] <llogan> but downloading the source and compiling it just for xbmc. [05:36] <llogan> --enable-external-ffmpeg would have been worth a try [05:36] <llogan> or just use xbmc from community repo [05:37] <krabador> llogan, i tried, before asking here [05:37] <krabador> to use --enable-external-ffmpeg [05:37] <krabador> but nothing [05:37] <krabador> llogan, i'm compiling the git , because radeon vdpau support [05:37] <llogan> did you also add "export PKG_CONFIG_PATH=/usr/lib/ffmpeg-compat/pkgconfig:$PKG_CONFIG_PATH"? [05:38] <krabador> no [05:38] <llogan> that's from xbmc PKGBUILD, but the path would be your ffmpeg path [05:39] <llogan> perhaps moddifying xbmc from ABS would have been a better method [05:40] <llogan> than xbmc-git. anyway, #archlinux is probabaly a more appropriate channel for this since it's not really a FFmpeg issue. [05:40] <llogan> or #xbmc [05:40] <krabador> llogan, yuo help me , you don't know how much, to understand the problem [05:41] <krabador> llogan, light years more than #archlinux, and #xbmc [05:42] <Snowleaksange> hmm frame->data == NULL in mp3lame_encode_frame [05:42] <llogan> krabador: i tend to also look at the PKGBUILDS in the official repositories before using a similar package in AUR [05:42] <llogan> or make my own if the AUR stuff is retarded [05:42] <krabador> llogan, i look at PKGBUILD of xbmc-git on aur [05:42] <Snowleaksange> somehow magically different params in mp3lame_encode_frame then my call to avcodec_encode_audio2 [05:43] <krabador> and i installed all dependencies inside it [05:43] <llogan> i guess the maintainer should also add yasm as a dependency. [05:43] <krabador> yes [05:44] <krabador> with yasm, my configure is gone right [05:44] <krabador> <llogan> or make my own if the AUR stuff is retarded --- that's what i want learn , ad this time [05:48] <llogan> krabador: you can adopt and maintain a simple package. that's a good way to learn. [05:49] <krabador> llogan, with git, you mean? [05:50] <llogan> no, i meant a package from AUR. i assumed you wanted to learn how to write PKGBUILD [05:51] <krabador> yes [05:51] <krabador> i was wrong, excuse me. [08:06] <sara> How I do wirte scrip for rip dvd while when I click right on inpute file , ffmpeg get name of file automatic as input in comman line ? [08:08] <sara> Is anybody here ? [09:10] <sspiff> hi, I'm trying to decode teletext subtitles, and I'm getting subtitles out, but they seem to contain nothing. [09:11] <sspiff> format is 0 (which I think is image based?), and there are 0 rects... [09:12] <cbreak> https://gist.github.com/cbreak-black/39e971057667d86d85f3, this crash has cost me hours of pain... [09:12] <cbreak> it really does seem though that there is a bug in ffmpeg as suspected. [09:17] <cbreak> so, updated it to an even smaller test case [09:26] <cbreak> originally my code was nicely wrapped C++ with real objects, RAII for memory management and so on. [09:26] <cbreak> this test case is just a stripped down version, I am aware it leaks resources. [09:29] <cbreak> the ffmpeg I use is built without optimization so it is probably not a bug in the optimizer [09:46] <Snowleaksange> windows portability went smooth [09:46] <Snowleaksange> ffmpeg 90% upgraded [09:48] <ubitux> cbreak: can you submit a bug report? [09:49] <ubitux> well, let me test first.. [09:52] <ubitux> cbreak: btw, av_malloc [09:53] <ubitux> i can reproduce the problem though [09:53] <cbreak> what's with av_malloc? [09:53] <ubitux> malloc will have align [09:53] <ubitux> but yeah it doesnt help [09:53] <ubitux> just a moment [10:02] <ubitux> cbreak: reproduced with http://pastie.org/8764613 [10:02] <ubitux> looks indeed fishy [10:03] <cbreak> it works if I disable avx/avx2 and mmx [10:06] <cbreak> it was quite troublesome to isolate, because in my real code, it randomly worked, and only broke on about 1% the frames. [10:06] <cbreak> (Maybe because the C++ code overallocated some data buffers for efficiency) [10:07] <ubitux> i'm trying to reproduce with ffmpeg [10:08] <cbreak> I didn't manage that [10:12] <ubitux> yeah seems not reproducible for some reason [10:12] <ubitux> probably because avpicture_alloc doesn't allocate enough padding while other builtins do [10:13] <cbreak> there should not be need for any padding :/ [10:14] <ubitux> i'm going to open a ticket [10:19] <ubitux> arrh trac locked. [10:20] <ubitux> cbreak: try to call av_image_alloc() instead [10:20] <ubitux> with an align of 32 or something [10:30] <cbreak> ubitux: the memory I get from new is 4kb aligned I think [10:30] <cbreak> exactly 375 pages [10:32] <cbreak> hmm. no. [10:34] <cbreak> 1125 pages of course [10:37] <cbreak> I guess that's the problem: if the image size is an exact multiple of the page size, then there will be no invalid-but-still-readable memory after the data, so even an off-by-one crashes. [11:23] <ubitux> cbreak: http://trac.ffmpeg.org/ticket/3413 [11:24] <cbreak> thanks. I think the problem is not in the allocation but the out-of-bound access [11:25] <sspiff> is there any example code to using/configuring the teletext subtitle decoder? Do I need to do something special somehow? I'm using a minimally adapted test program based on doc/examples/demuxing_decoding.c, which worked fine for DVB subtitles. [11:25] <cbreak> after all, even with highly aligned storage it fails here [11:26] <ubitux> cbreak: align is about the padding [11:26] <cbreak> my input is page-padded [11:27] <cbreak> the input consumes an exact number of pages [14:44] <sspiff> How can I change the options associated with a priv_class of a codec? [14:45] <sspiff> I'm assuming codec->priv_class shouldn't be accessed directly? [15:29] <julienb> Hello the room [15:29] <julienb> I contact you because i would like to know if it's possible to cut videos from the end with ffmpeg. [15:33] <Keshl> Yes, easily, just specify -t (seconds) for however long you want a video to last. [15:34] <ubitux> "from the end" is not easy [15:34] <julienb> kesh1, what i want to do is declare an offset 10mn from the end [15:34] <ubitux> ffmpeg is "stream based" [15:34] <julienb> and then cut 10mn [15:34] <ubitux> there is often no end [15:34] <ubitux> and in a lot of formats, you can't tell when the end is [15:35] <ubitux> so you have to obtain an (estimation/fast accurate-duration/slow) in a first pass [15:35] <julienb> they are all mp4 format [15:35] <ubitux> also duration of the container doesn't always match duration of the streams [15:35] <ubitux> so... per case. [15:36] <julienb> so it's not possible to do that? [15:36] <ubitux> it is, on a per case basis [15:37] <Keshl> It's possible, but you'll essentially have to go through the video twice. First ffmpeg has to figure out where the end (and thus, "ten minutes before") actually is. [15:37] <Keshl> As for how to do that, I haven't got a clue. xwx.. [15:38] <ubitux> julienb: try ffprobe -v error -of flat -show_entries format=duration:stream=duration foobar.mp4 [15:38] <julienb> ok thanks [15:38] <ubitux> this will give you all the estimated/stored durations in the format [15:38] <ubitux> they might not be accurate [15:38] <ubitux> deal with that [15:38] <julienb> i will try it ubitux [15:39] <julienb> ubitux i have to replace format and duration to something? [15:40] <julienb> in your line command [15:40] <ubitux> no [15:40] <ubitux> just copy paste the command with your input [15:40] <julienb> ok [15:40] <ubitux> you'll get what i mean [15:41] <ubitux> julienb: http://pastie.org/pastes/8767231/text [15:41] <ubitux> this is what i get here [15:41] <ubitux> as you can see, each stream has a different duration [15:41] <ubitux> and the presentation (format) duration is one of them [15:41] <ubitux> not the smallest, no the biggest... [15:42] <julienb> Unrecognized option 'of' [15:42] <julienb> Failed to set value 'flat' for option 'of' [15:42] <ubitux> you're not up-to-date [15:43] <ubitux> anyway, when you have that value you substract the time you want and ffmpeg -ss ... -i foobar.mp4 -c copy out.mp4 [15:43] <julienb> i have to update my ffmpeg version? [15:44] <julienb> oh yes with that value i can do what i want with the normal command [15:45] <julienb> this value is in second? [15:47] <ubitux> yes [15:47] <ubitux> and yes [15:48] <ubitux> what ffmpeg version are you running? [15:50] <julienb> second i will tell you [15:53] <julienb> ubitux: 0.10.6 on gentoo distrib [15:53] <ubitux> this is more that 2 years old [15:54] <julienb> oh [16:03] <Taiko3615> Hi :-) somebody here ? [16:04] <Taiko3615> I am using ffmpeg in an android application, and I would need some help to optimise a command line. Here's what I currently use : libffmpeg.so -y -i compiledAndMusic.mp4 -i overlay_video_720p.png -filter_complex overlay -strict -2 compiledWithO [16:05] <Taiko3615> But sadly the encoding takes wayyyyy too long, like 10 minutes for a 25s video, (0,9 fps) is there a way to optimise it ? Thanks !!! [16:05] <Taiko3615> libffmpeg.so -y -i compiledAndMusic.mp4 -i overlay_video_720p.png -filter_complex overlay -strict -2 compiledWithOvelray.mp4 [17:43] <SianaGearz> helloes. would you like to recommend me a codec? or give me some guidelines to design one myself possibly. my requirements: encoding performance: can tage ages, that's OK; decoding: must be frugal enough for 200MHz SH4 at SD resolution. bonus points for extra CPU time left over :P decent compression is a goal. [17:44] <SianaGearz> preferably without too much tendency for blockiness. [17:46] <SianaGearz> i guess snow is kinda slow? [17:59] <Taiko3615> Hmm.. I guess not so many active ffmpeg guys here. [17:59] <Taiko3615> mostly people asking questions [18:51] <jluttine> for testing, i'm using these four png files: http://users.ics.aalto.fi/jluttine/ffmpeg/ [18:51] <jluttine> (identical files) [18:51] <Taiko3615> do you know a bit of java ? [18:51] <jluttine> and then: ffmpeg -r 1 -i test%01d.png test.mpg [18:51] <jluttine> Taiko3615: me? a bit [18:51] <Taiko3615> because I use a java library that calls ffmpeg. here is the function that create a slideshow [18:51] <jluttine> i've tried other formats too: mpg, mp4, avi [18:51] <Taiko3615> public Clip createSlideshowFromImagesAndAudio (ArrayList<Clip> images, Clip audio, Clip out, int durationPerSlide, ShellCallback sc) throws Exception [18:51] <Taiko3615> { [18:51] <Taiko3615> final String imageBasePath = new File(mFileTemp,"image-").getCanonicalPath(); [18:51] <Taiko3615> final String imageBaseVariablePath = imageBasePath + "%03d.jpg"; [18:51] <Taiko3615> [18:51] Last message repeated 1 time(s). [18:51] <Taiko3615> ArrayList<String> cmd = new ArrayList<String>(); [18:51] <Taiko3615> [18:51] <Taiko3615> [18:51] <Taiko3615> String newImagePath = null; [18:51] <Taiko3615> int imageCounter = 0; [18:51] <Taiko3615> [18:51] <Taiko3615> Clip imageCover = images.get(0); //add the first image twice [18:51] <Taiko3615> [18:51] <Taiko3615> cmd = new ArrayList<String>(); [18:51] <Taiko3615> cmd.add(mFfmpegBin); [18:51] <Taiko3615> cmd.add("-y"); [18:51] <Taiko3615> [18:51] <Taiko3615> cmd.add("-i"); [18:51] <Taiko3615> cmd.add(new File(imageCover.path).getCanonicalPath()); [18:51] <Taiko3615> [18:51] <Taiko3615> if (out.width != -1 && out.height != -1) [18:51] <Taiko3615> { [18:51] <Taiko3615> cmd.add("-s"); [18:51] <Taiko3615> cmd.add(out.width + "x" + out.height); [18:51] <Taiko3615> } [18:51] <Taiko3615> [18:51] <Taiko3615> newImagePath = imageBasePath + String.format(Locale.US, "%03d", imageCounter++) + ".jpg"; [18:51] <Taiko3615> cmd.add(newImagePath); [18:51] <Taiko3615> [18:51] <Taiko3615> execFFMPEG(cmd, sc); [18:51] <Taiko3615> [18:51] <Taiko3615> for (Clip image : images) [18:51] <Taiko3615> { [18:51] <Taiko3615> cmd = new ArrayList<String>(); [18:51] <Taiko3615> cmd.add(mFfmpegBin); [18:51] <Taiko3615> cmd.add("-y"); [18:51] <Taiko3615> [18:51] <Taiko3615> cmd.add("-i"); [18:51] <Taiko3615> cmd.add(new File(image.path).getCanonicalPath()); [18:51] <Taiko3615> [18:51] <Taiko3615> if (out.width != -1 && out.height != -1) [18:51] <Taiko3615> { [18:51] <Taiko3615> cmd.add("-s"); [18:51] <Taiko3615> cmd.add(out.width + "x" + out.height); [18:51] <Taiko3615> } [18:51] <Taiko3615> [18:51] <Taiko3615> newImagePath = imageBasePath + String.format(Locale.US, "%03d", imageCounter++) + ".jpg"; [18:51] <Taiko3615> cmd.add(newImagePath); [18:51] <Taiko3615> [18:51] <Taiko3615> execFFMPEG(cmd, sc); [18:51] <Taiko3615> [18:51] Last message repeated 1 time(s). [18:51] <Taiko3615> } [18:51] <Taiko3615> [18:51] <Taiko3615> //then combine them [18:51] <Taiko3615> cmd = new ArrayList<String>(); [18:51] <Taiko3615> [18:51] <Taiko3615> cmd.add(mFfmpegBin); [18:51] <Taiko3615> cmd.add("-y"); [18:51] <Taiko3615> [18:51] <Taiko3615> cmd.add("-loop"); [18:51] <Taiko3615> cmd.add("0"); [18:51] <Taiko3615> [18:51] <Taiko3615> cmd.add("-f"); [18:51] <Taiko3615> cmd.add("image2"); [18:51] <Taiko3615> [18:52] <Taiko3615> cmd.add("-r"); [18:52] <Taiko3615> cmd.add("1/" + durationPerSlide); [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add("-i"); [18:52] <Taiko3615> cmd.add(imageBaseVariablePath); [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add("-strict"); [18:52] <Taiko3615> cmd.add("-2");//experimental [18:52] <Taiko3615> [18:52] <Taiko3615> String fileTempMpg = new File(mFileTemp,"tmp.mpg").getCanonicalPath(); [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add(fileTempMpg); [18:52] <Taiko3615> [18:52] <Taiko3615> execFFMPEG(cmd, sc); [18:52] <Taiko3615> [18:52] <Taiko3615> //now combine and encode [18:52] <Taiko3615> cmd = new ArrayList<String>(); [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add(mFfmpegBin); [18:52] <Taiko3615> cmd.add("-y"); [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add("-i"); [18:52] <Taiko3615> cmd.add(fileTempMpg); [18:52] <Taiko3615> [18:52] <Taiko3615> if (audio != null && audio.path != null) [18:52] <Taiko3615> { [18:52] <Taiko3615> cmd.add("-i"); [18:52] <Taiko3615> cmd.add(new File(audio.path).getCanonicalPath()); [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add("-map"); [18:52] <Taiko3615> cmd.add("0:0"); [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add("-map"); [18:52] <Taiko3615> cmd.add("1:0"); [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add(Argument.AUDIOCODEC); [18:52] <Taiko3615> cmd.add("aac"); [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add(Argument.BITRATE_AUDIO); [18:52] <Taiko3615> cmd.add("128k"); [18:52] <Taiko3615> [18:52] <Taiko3615> } [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add("-strict"); [18:52] <Taiko3615> cmd.add("-2");//experimental [18:52] <Taiko3615> [18:52] <Taiko3615> cmd.add(Argument.VIDEOCODEC); [18:52] <Taiko3615> [18:52] <Taiko3615> if (out.videoCodec != null) [18:52] <Taiko3615> cmd.add(out.videoCodec); [18:52] <Taiko3615> else [18:52] <Taiko3615> cmd.add("mpeg4"); [18:52] <Taiko3615> if (out.videoBitrate != -1) [18:52] <Taiko3615> { [18:52] <Taiko3615> cmd.add(Argument.BITRATE_VIDEO); [18:52] <Taiko3615> cmd.add(out.videoBitrate + "k"); [18:53] <impy> hmm [18:53] <Taiko3615> sorry... here is the paste bin http://pastebin.com/qN5BZiGv [18:53] <impy> That killed my irc client :s [18:53] <impy> better :) [18:53] <Taiko3615> lool sry... [18:53] <jluttine> Taiko3615: ok, thanks.. :) anyway, i really would prefer getting this to work on the command line with ffmpeg [18:54] <impy> Taiko3615: no worries. [19:10] <llogan> Taiko3615: is the overlay adding a significant amount of time to the process? [19:10] <llogan> you can stream copy the audio instead of re-encoding it with: -acodec copy [19:10] <llogan> you can use a faster encoding preset (assuming you have libx264 support) [19:21] <Taiko3615> I tweaked the preset and reached a pretty decent speed :-) [19:21] <Logicgate> Does anyone know about closed captioning [19:22] <Logicgate> Is there a way to convert SRT (SubRip Title) to SCC (Scenarist Closed Captioning) [19:22] <Taiko3615> My last issue is about the size of the overlay, I'll try to fix it myself first ;-) [19:22] <llogan> Taiko3615: you can add the scale filter to scale the image to be overlaid. [19:25] <Taiko3615> ffmpeg -y -i compiled.mp4 -vf scale=1280x720 -i payday.mp3 -i /overlay_720p.png -filter_complex overlay -acodec aac -b:a 192k -y -cutoff 15000 -s 1280x720 -t 3.984 -vcodec mpeg4 -strict -2 compiledAndMusic.mp4 [19:26] <Taiko3615> The overlay has a size of 720p, but the initial video input is bigger [19:26] <Taiko3615> the resulting video has the right size, but the overlay is not fullscreen [19:29] <Taiko3615> e.g. compiled.mp4 (the first input) is bigger than 720p, overlay.png is 720p, and the resulting compiladAndMusic.mp4 is 720p. Sadly, on the resulting video the overlay is sized down. How can I specify to first resize compiled.mp4 to 720p, then add the overlay? [19:32] <Taiko3615> Logicgate, to convert subtitles, I would use a third party software. Like http://www.3playmedia.com/services-features/tools/captions-format-converter/ (never tried it, but seems to do the job) [19:33] <llogan> Taiko3615: you should put all filters in one filterchain: ffmpeg -i video.mp4 -i image.png -filter_complex "[1:v]scale=320:-1[fg];[0:v][fg]overlay=W-w-10:H-h-10[out]" -map "[out]" output.mp4 [19:33] <llogan> s/filterchain/filtergraph [19:34] <Taiko3615> thanks llogan ! I'll try that :-) [19:46] <Taiko3615> Works like charm ! Awesome :-D Thank !!! [21:49] <JodaZ> how do i see the pts ffmpeg is generating ? [22:48] <Logicgate> http://pastebin.com/Qzd945xm [22:48] <Logicgate> I'm trying to extract the subtitle streams from an MOV [22:48] <Logicgate> and that's the error I get [23:00] <Logicgate> here are the streams for that video [23:00] <Logicgate> http://pastebin.com/7Sr231yg [23:33] <relaxed> -map:0:s:1 srt is wrong [23:37] <relaxed> Logicgate: example from the man page: ffmpeg -i file.mov -an -vn -bsf:s mov2textsub -c:s copy -f rawvideo sub.txt [23:44] <zh1> CLI video editing that doesn't include trial and error, playing video or audio, any? [23:55] <llogan> zh1: i don't understand your question. [00:00] --- Tue Feb 25 2014

1 0

ffmpeg-devel.log.20140223
by burek 24 Feb '14

24 Feb '14

[01:26] <cone-550> ffmpeg.git 03Carl Eugen Hoyos 07master:0aded6bf028f: Support MPEG-2 video mov files with sample description mp2v. [01:26] <cone-550> ffmpeg.git 03Carl Eugen Hoyos 07master:5d6fac114b5e: Support old qclp-in-mov files that do not store bytes_per_frame in the header. [01:40] <cone-550> ffmpeg.git 03Dave Yeo 07master:e5858fef38fe: configure: Revert commit 5176e9651bda5182df008a1226e2484fdd809985 [02:37] <cone-550> ffmpeg.git 03Peter Ross 07master:a3a4d07d6ae5: avutil/pixdesc: set bayer pixfmt descriptor flags [03:21] <Daemon404> ... lul [03:21] <Daemon404> only comment is about fricken gpu decodin [03:21] Action: Daemon404 sighs [03:22] <BBB2> there's some less silly comments on hn [03:22] <Daemon404> i saw [03:23] <Daemon404> top comment has a misunderstanding about how youtube transcodes their videos [03:24] <Daemon404> and also ignores the "no 32bit asm" thing [04:34] <cone-550> ffmpeg.git 03Peter Ross 07master:7e23cfba765a: avcodec/rawdec: for 16-bit pix fmts, shift pixels when bits_per_coded_sample < 16 [04:34] <cone-550> ffmpeg.git 03Peter Ross 07master:02b63246cf7f: libswscale: bayer to rgb24 & yv12 colorspace converters [11:01] <aca> Hi. I've sent my Debian packaging of FFmpeg to the RFP bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#410 [11:02] <ubitux> yay [11:02] <aca> But the security team seams unwilling to have both FFmpeg and libav in Debian. [11:02] <aca> Even more, they seem to think libav is more secure than FFmpeg, because FFmpeg has more experimental code. (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#435) [11:03] <aca> Do you have any solid numbers about security issues in FFmpeg/libav? [11:04] <aca> And they think that the long term branches of libav are a major benefit of libav. [11:04] <ubitux> aca: only j00ru report [11:04] <ubitux> "Also ffmpeg hasn't have long term branches which is a major [11:04] <ubitux> benefit of libav." [11:04] <ubitux> huh? [11:05] <nevcairiel> its debian, they like software that develops as slowly as they do [11:05] <ubitux> well, isn't 1.2 branch still maintained? [11:05] <nevcairiel> i think so [11:05] <ubitux> it's not because we have more release than the older in sync with libav is not maintained [11:05] <aca> How long will the current 2.1.3 be maintained? [11:06] <nevcairiel> I don't think there are such plans [11:06] <nevcairiel> its just maintained as long as its deemed useful [11:06] <aca> So if it is in Debian stable, it's useful? [11:07] <ubitux> note that we might have a release to somehow match with libav10 [11:07] <ubitux> (which we may maintain longer that 2.1.x?) [11:08] <aca> ubitux, What do you mean with 'somehow match with libav10'? [11:08] <ubitux> release around the same date [11:08] <ubitux> so kind of api compatible [11:08] <ubitux> (btw, didn't they release a beta or something?) [11:08] <ubitux> aca: is Moritz part of the security team? [11:08] <aca> Yes, they did. [11:08] <aca> ubitux, yes [11:09] <ubitux> what he says is pretty weird [11:09] <aca> ubitux: He is the only one from the security team that has made any statement about the security of FFmpeg. [11:10] <ubitux> "either because experimental code wasn't merged yet" is "experimental code" refering to ffmpeg code not cherry-picked from libav? [11:10] <aca> ubitux: I don't know. Perhaps you could ask Moritz in the RFP bug? [11:10] <ubitux> "or because code was rewritten in libav" everything libav rewrites ends up in ffmpeg anyway, so this is a weird statement as well [11:11] <aca> Yes, I didn't understand that one. [11:12] <ubitux> aca: well, if i start posting it will probably end up with flaming, so i'd better let someone else correct him :) [11:12] <ubitux> and lastly, the long term branch statement makes no sense either [11:12] <ubitux> it looks like he was brainwashed or something [11:12] <ubitux> :( [11:13] <aca> ubitux: OK. I don't want to see flames. I can respond to him, so let's collect some arguments. [11:13] <ubitux> btw, Timothy raised a point about qt-faststart [11:13] <ubitux> i forgot about the change he raised [11:14] <ubitux> (f4d9148fe, qt-faststart speedup; "decreased the processing time on a sample file from 1600 seconds to 4 seconds") [11:14] <ubitux> so it might be worth considering integration at some point [11:14] <aca> ubitux: Yes, I plan to have a qt-faststart package that diverts the libav qt-faststart. [11:14] <ubitux> the "limited usage" i was talking about is because now the mov muxer has a faststart flag, but it has its uses anyway [11:14] <aca> But the security team concerns seem somewhat more important. [11:15] <ubitux> sure [11:16] <ubitux> aca: do you have vim btw? [11:17] <aca> ubitux: vim the editor? [11:18] <ubitux> yes [11:18] <aca> yes, why? [11:18] <ubitux> it's not security relevant, but... you might want to run this: [11:18] <ubitux> for x in codec filter format device; do vim -E -d libav/libav$x/all${x}s.c ffmpeg/libav$x/all${x}s.c -c 'let g:html_no_progress=1' -c TOhtml -c "w! diff-${x}s.html" -c 'qa!'; done [11:18] <ubitux> assuming libav/ and ffmpeg/ in current dir [11:18] <ubitux> then look at the html generated [11:29] <aca> ubitux: It shows a lot of missing features of libav, that FFmpeg has. That's the reason why we want FFmpeg back. [11:30] <aca> ubitux: Thanks for sharing this command. I will send the output to the RFP bug. [11:31] <ubitux> :) [11:32] <ubitux> michaelni: diff_bytes_mmx seems to deal well with unaligned addresses here; any idea why? [11:54] <aca> Is it true, that libav didn't fix the issues reported by Google, but FFmpeg did? http://googleonlinesecurity.blogspot.fi/2014/01/ffmpeg-and-thousand-fixes.h… [11:55] <ubitux> http://j00ru.vexillium.org/?p=2211 is more complete iirc [11:56] <ubitux> "so even though some of the FFmpeg bugs might not apply to Libav, there are still many unresolved issues there which are already fixed in FFmpeg. Consequently, we advise users to use the FFmpeg upstream code where possible" [11:56] <aca> ubitux: Thanks, one argument more. [13:15] <michaelni> ubitux, about diffbytes, if callers dont align then writing an SSE version would be tricky [13:19] <cone-688> ffmpeg.git 03Sylvain Fabre 07master:526049ce61d0: Issue-#3407 : Enhance precision for double to string conversion, useful for GEOTIFF double values [13:52] <cone-688> ffmpeg.git 03Peter Ross 07master:dd5abb0bac21: avdevice/v4l2: add V4L2_PIX_FMT_SRGGB8 [13:52] <cone-688> ffmpeg.git 03Carl Eugen Hoyos 07master:5642dd41ccb9: Add more Bayer colour spaces to the video4linux2 device wrapper. [13:56] <BBB> ubitux: oh we're on slashdot now [13:57] <ubitux> BBB :) [13:57] <ubitux> we're still on the front page on HN [13:58] <kierank> ubitux: you are also on front page of reddit programming [13:58] <ubitux> yeah they sync by themselves ;) [13:58] <kierank> well I submitted it [13:58] <ubitux> ah :D [13:59] <BBB> yeah I saw that, ty :) [13:59] <kierank> and slashdot [13:59] <BBB> yay, thanks [13:59] <Skyler_> the trio of hives of scum and villainy [13:59] <Skyler_> congrats ^^ [13:59] <BBB> that's also true [13:59] <BBB> so, which hevc decoder is fastest? [14:00] <BBB> some people claim de265 is better than openhevc, is it? [14:00] <smarter__> haven't tested that other decoder [14:00] <BBB> Skyler_: I though news.y was sometimes not too awful? or am I behind? [14:01] <smarter__> bu ffhevc has already decent speed due to multi-threading [14:01] <Skyler_> I don't know, I'd consider them worse than proggit, from what I've seen [14:01] <smarter__> it depends really, sometimes there are interesting dicussions there, sometimes just stupidity [14:01] <Skyler_> I don't remember proggit having quite the same level of misogyny, racism, and "but why don't poor people just buy more money?!" outoftouchness [14:01] <Skyler_> but it varies, yeah [14:02] <Skyler_> it probably gets worse because it's not very programming-focused anymore; it's mostly startups and silicon valley get-rich-quick types, I think [14:02] <BBB> proggit is reddit/programming? [14:02] <Skyler_> yeah [14:03] <BBB> ah, ok [14:03] <kierank> well you saw the hacker news thread about the fuzzing [14:03] <kierank> FFmpeg should be written in $obscurelanguage [14:03] <BBB> "why don't you write ffmpeg in python" [14:03] <BBB> "nobody needs performance, 20% slower is just fine" [14:03] <BBB> I mean, that sentence has so many misconceptions that it's just +5 funny [14:04] <JEEB> oh wait until you get to the clojure/haskell/scala folk [14:05] <smarter__> Rust! :D [14:05] <JEEB> rust actually kind of makes sense [14:05] <smarter__> yeah [14:52] <gix-> ubitux: for example the dxva configure structs are identical, but have a different name. so putting them into such an union would not require the d3d9 code. [14:53] <wm4> what's the advantage of d3d11 over d3d9 for decoding? [14:55] <JEEB> winphone and winrt I would guess? [14:55] <JEEB> and better interop with d3d11 apis in general? not sure [14:55] <gix-> yeah [14:56] <gix-> and no need to load d3d9 if you're already using 11 [15:11] <Compn> aca : the security team answer about 'experimental code' is very vague. possibly he means the mplayer filters? which can of course be disabled and probably should for debian... [15:12] <Compn> i mean, experimental equals all code not in the fork ? what ? [15:12] <wm4> ffmpeg in debian? [15:12] <Compn> or experimental equals all new features ? is ffmpeg not supposed to add new features ? [15:13] <Compn> wm4 : yes, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 [15:13] <wm4> oh nice [15:18] <aca> Compn: The security team as a whole is probably rather indifferent about whether FFmpeg or libav is in Debian, they just don't want to have both. [15:19] <Compn> fair enough [15:23] <aca> Compn: Do you mean the filters in libavfilter/libmpcodecs? Why should they be disabled? Are they not tested well? [15:23] <kierank> __av500__: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 your kind of epic thread [15:23] <wm4> I wouldn't trust the libmpcodecs wrapper one bit [15:25] <aca> kierank: Epic? Take a look at: https://bugs.debian.org/727708 [15:25] <kierank> aca: I knew what that was before i clicked it [15:26] <kierank> I know av500 is an avid viewer of such threads [15:27] <Compn> aca : its wrapper and mplayer code, it only contains filters that have not been ported to ffmpeg yet. so its very much a work in progress. they arent needed by most users i think. [15:27] <wm4> work in progress for multiple years [15:27] <aca> Compn: Which configure option disables them? [15:28] <Compn> humm [15:28] <wm4> and now it contains only filters which nobody cards about (proof: nobody wants to port them) [15:28] <Compn> the difficulty is also increased on those filters :P [15:30] <Compn> aca : something like --disable-filter=mp_filter i think [15:31] <aca> Compn: I will try it, thanks. [15:31] <Compn> those filters have been included in mplayer for years of course [15:31] <Compn> and are still included [15:32] <Compn> ffmpeg has more security experts running tests against it than running against mplayer :) [15:32] <aca> mplayer is in no good shape in Debian. [15:32] <JEEB> it's not in a good shape anywhere [15:32] <Compn> i know, i help mplayer users on irc. so many distro problems :\ [15:33] <Compn> 'if you just compile from source, it will stop crashing' ... [15:33] <Compn> i've been sending users to vlc as much as possible [15:34] <Compn> or deb-multimedia repo [15:34] <Compn> when possible [15:34] <Mavrik> yeah, too bad VLC is a crashy piece of software as well -_- [15:35] <wm4> does debian try to package mplayer with libav? [15:36] <Compn> Mavrik : i havent noticed vlc crashes , but i use nightly builds [15:36] <JEEB> it generally shouldn't crash :P [15:36] <Compn> mplayer ffmpeg and vlc shouldnt crash, but distro versions do more often than self-compiled ones [15:37] <JEEB> well, most of my *nix use of VLC is the debian/ubuntu packaging [15:37] <Mavrik> well, I did use it as a long-running transcode process [15:38] <Mavrik> never seen it crash as a desktop player or one-time use software tho :) [15:51] <michaelni> aca, Compn about the libmpcodecs wraper, it probably contains bugs but as far as security is concerned iam not aware of any security issues in it also if there was one it would be very hard to exploit as first the user would have to use that filter [15:53] <Compn> yes, of course. i was just trying to figure out what 'experimental code' meant [15:53] <aca> michaelni: Thanks, so do you think it makes sense to enable them? I do not use them. [15:54] <michaelni> i dont know, its more a question for the users [15:56] <Compn> that is one reason people use ffmpeg over libav, for the filters [15:56] <aca> If there are no security concerns about them, I would enable them, and wait for bug reports. [15:56] <Compn> i agree , more features are better :) [15:56] <aca> Compn: WARNING: Option --disable-filter=mp_filter did not match anything [15:56] <Compn> hmm [15:56] <aca> Doesn't matter, I will leave them enabled. [15:56] <Compn> have to do ./configure --list-filters then find the name for it [15:57] <aca> Compn: Probably mp? [15:58] <wm4> <Compn> yes, of course. i was just trying to figure out what 'experimental code' meant <- maybe when e.g. hevc was marked as experimental? [15:58] <wm4> libav merged hevc only later [15:58] <wm4> so only ffmpeg had this "experimental" code for a while [16:02] <ubitux> aca: --disable-filter=mp probably [16:05] <smarter> wm4: I think the experimental flag was dropped very quickly [16:06] <wm4> yeah, I'm just trying to guess what that debian guy meant [16:07] <ubitux> does anyone knows if libav has branched out the v10? [16:08] <ubitux> or if the final version will include all the changes from master [16:08] <wm4> I think they made a branch, but who knows if that's the final one [16:08] <ubitux> i'm asking to know if it would make sense to release now to be in sync [16:08] <ubitux> or we have to wait until the final [16:09] <smarter> there's a branch [16:09] <ubitux> and that branch will only pick fixes from master so? [16:09] <smarter> https://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/10 [16:09] <smarter> it should, but I guess there can be exceptions [16:10] <ubitux> michaelni: should we have a "lts" release starting now so we can have a matching version of ffmpeg for libav10? [16:14] <wm4> you should definitely try to have a matching release [16:14] <wm4> and support it as long as libav10 is [16:18] <michaelni> ubitux, we are a bit late already anyway with our 2-3 month per release schedule so yes [16:22] <michaelni> ubitux, about matching,our major version for libavutil differs to libav10, so if someone wants truly matching he has to come up with some magic solution about that one [16:23] <ubitux> well it was more about api, features & bugs [16:23] <wm4> at this point it's a joke both projects use the same pkg-config names [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:8c6a976feeea: avcodec/takdec: always check bits_per_raw_sample [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:325feb8e0d51: avcodec/vc1: reset fcm/field_mode in non advanced header parsing [17:47] <cone-688> ffmpeg.git 03Justin Ruggles 07release/2.1:a644272a4a95: samplefmt: avoid integer overflow in av_samples_get_buffer_size() [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:f91ef98c9d74: avcodec/wmalosslessdec: fix mclms_coeffs* array size [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:4a28a3ddc4eb: avformat/mpegtsenc: Check data array size in mpegts_write_pmt() [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:656770e2aacf: avcodec/hevc: make *ps_id unsigned [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:f8985cb9d995: avcodec/utils: set AVFrame format unconditional [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:4cc18ee5da11: avcodec/msrle: use av_image_get_linesize() to calculate the linesize [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:18eac12c6d47: avcodec/ansi: fix integer overflow [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:a94f36742405: avcodec/snow: split block clipping checks [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:c9b961748f79: avformat/flac_picture: allocate buffer padding for picture [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:e266fcf0834a: avformat/flac_picture: clear padding area [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:f22e88c17772: avcodec/mjpegdec: pass into ff_mjpeg_decode_sos() and check bitmask size [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:9368b91834e4: avcodec/vc1dec: field pictures with direct mode MBs, followed by frame pictures are not supported [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:10a30e4de561: avcodec/vc1: factor read_bfraction() out [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:ab1c7113f9ec: avcodec/vc1: Check bfraction_lut_index [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:ebc490e7445c: avcodec/tiff: reset geotag_count in free_geotags() [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:d79419d0f993: avcodec/hevc: propagate error code from hls_coding_quadtree() [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:9fb364babdc7: avcodec/aacdec: Fix pulse position checks in decode_pulses() [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:9330bcff9ba2: avcodec/h264: Disallow pps_id changing between slices [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:e7b7e6941686: avcodec/h264: update current_sps & sps->new only after the whole slice header decoder and init code finished [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:69f99f80d125: avcodec/hevc: clear tab_slice_address in hevc_frame_start() [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:b959e6393e8a: avcodec/hevc: hls_decode_entry: check that the previous slice segment is available before decoding the next [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:aa672f5e6af4: avcodec/hevc: clear tab_slice_address of ctb on error. [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:ce5d9a2b4b30: avcodec/hevc: make check for previous slice segment tighter [17:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:7034e808f6b2: avcodec/hevc_ps: Use get_bits_long() in decode_vui() [17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:6341a7006d74: avcodec/alsdec: check predictor order against block length [17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:d0d441b35053: avcodec/h264: more completely check the loop filter parameters [17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:c8d363a3593a: avformat/bink: Check return value of av_add_index_entry() [17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:846a9c67ff6e: avcodec/h264: use subsample factors of the used pixel format [17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:ea7ccf374845: avcodec/mpeg4videodec: Check for bitstream overread in decode_vol_header() [17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:2368d08e701a: Merge commit 'e22ebd04bcab7f86548794556c28ecca46d9c2ac' [17:48] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:0909b8acf8f7: avcodec/hevc: Simplify get_qPy_pred() [17:53] <cone-688> ffmpeg.git 03Michael Niedermayer 07release/2.1:d3139c9733f1: update for 2.1.4 [18:03] <aca> I'm trying to build the Debian package for Debian experimental, as I think an upload there would be good for testing purposes. But the acodec-flac test fails: Error while decoding stream #0:0: Invalid data found when processing input [18:04] <aca> Any ideas which package could be at fault? Maybe gcc4.9? [18:05] <michaelni> yes, very likely 4.9 related [18:06] <aca> OK. I'll try depending on gcc-4.8. [18:27] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:42361bdf51c4: avcodec/mpegvideo: fix buffer clear code so it should work with negative linesizes [18:27] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:72e691314027: avcodec/h264: clear chroma planes when flags gray is used [18:56] <ubitux> bayer support is completely pushed? :o [18:58] <nevcairiel> looks like it [19:43] <llogan> some people just don't ever understand. this is the 6th time I've told someone not to send user help questions to -devel... [19:43] <llogan> setting to auto discard. [20:44] <cone-688> ffmpeg.git 03Clément BSsch 07master:57ec555e8ef3: avcodec/pngenc: fix invalid read in sub filter. [21:23] <Daemon404> does pross come on irc much? [21:24] <nevcairiel> i've seen him around, not sure i would say much [21:24] <Daemon404> hmm ok [21:24] <Daemon404> im curious how he intends to handle the differing bayer patterns that every camera format in existed uses [21:24] <nevcairiel> how many patterns can you really create [21:25] <Daemon404> a lot apparently [21:25] <Daemon404> sme formats even store them in metadata [21:25] <Daemon404> i.e. they can be custom [21:25] <nevcairiel> sounds quite unfun [21:25] <ubitux> speaking of this, i'd love to see support for canon & nikon "raw" formats [21:25] <Daemon404> which? [21:25] <Daemon404> each hae lke 10 formats [21:25] <Daemon404> that are 'raw' [21:26] <Daemon404> new one every year [21:26] <nevcairiel> add a libraw wrapper imho [21:26] <nevcairiel> its too much pain to try to support this directly [21:26] <Daemon404> and currently nothing decodes the c500 raw format [21:26] <Daemon404> i cant even get their own software to do it [21:26] <Daemon404> its a dir of files + 3 xml files [21:26] <ubitux> cr2 for canon [21:26] <ubitux> nef for nikon [21:26] <ubitux> http://wildtramper.com/sw/cr2/cr2.html they use some bayer stuff [21:26] <nevcairiel> libraw 0.16 claims support for canon c500, if thats what oyu mean [21:26] <Daemon404> oic [21:27] <Daemon404> nifty [21:27] <Daemon404> especially since i could not find a spec. [21:27] <Daemon404> orr even barely an acknowledgement of its existence [21:27] <Daemon404> outside of PR [21:27] <ubitux> it would be pretty cool for doing timelapse based on these raws [21:28] <Daemon404> libraw wrapper sounds sanest [21:31] <ubitux> the whole lib seems to fit on 4k lines of code unless i'm mistaken [21:31] <Daemon404> im sure NIH will win as usual [21:31] <ubitux> it doesn't look like an unbearable project [21:31] <Compn> someone came in here talking about a camera raw format demuxer being added [21:31] <Compn> i was asking about dcraw project , but he had his own code [21:31] <Compn> if you want to check old logs search for dcraw... [21:31] <ubitux> Daemon404: well, i'm not saying we should absolutely write our own, but it looks like an interesting project [21:32] <ubitux> and since we have bayer, and a lot of helpers for doing such jobs in ffmpeg [21:32] <ubitux> i would guess it probably fits as a builtin [21:41] <llogan> i can probably get some raw samples from that weird blackmagic cinema camera if anyone wants them [21:42] <Daemon404> kierank probably has loads already [22:10] <cone-688> ffmpeg.git 03Luca Barbato 07master:50c988aa6d6c: hevc: Drop unnecessary shifts in deblocking_filter_CTB [22:11] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:c2b5981afa4e: Merge commit '50c988aa6d6c6f0ceb8f922bcea34800b56b85d9' [22:17] <cone-688> ffmpeg.git 03Luca Barbato 07master:ff486c0f7f6b: hevc: Do not right shift a negative value in get_pcm [22:17] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:a2e4b23bfe2d: Merge commit 'ff486c0f7f6b2ace3f0238660bc06cc35b389676' [22:23] <cone-688> ffmpeg.git 03Luca Barbato 07master:8eeacf31c5ea: hevc: Do not left shift a negative value in hevc_loop_filter_chroma [22:23] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:1287b640f000: Merge commit '8eeacf31c5ea37baf6b222dc38d20cf4fd33c455' [22:30] <cone-688> ffmpeg.git 03Janne Grunau 07master:5800ba0db667: configure: disable cpunop if the check fails [22:30] <cone-688> ffmpeg.git 03Diego Biurrun 07master:96ea3dea5805: configure: Move cpunop into ARCH_EXT_LIST_X86 [22:30] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:38336f0fb10a: Merge commit '5800ba0db667630e6ff81d30f03961ea10726aa6' [22:32] <kierank> bayer to yv12 is a bit weird [22:41] <cone-688> ffmpeg.git 03James Almer 07master:10b0161d7814: x86: add missing XOP checks and macros [22:41] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:098243325349: Merge commit '10b0161d78148f46eaffb29ea022378947eaef2c' [22:42] <Daemon404> kierank, you mean evil [22:42] <Daemon404> im sure. [22:42] <kierank> seems weird [22:42] <kierank> to convert from raw bayer rgb to a subsampled yuv format [22:43] <Daemon404> ofc [22:43] <Daemon404> i bet it will silentl go through yv12 if you try to convert to 4:4:4 too [22:43] <Daemon404> would have made more sense to go to 4444 [22:43] <Daemon404> -4 [22:47] <cone-688> ffmpeg.git 03James Almer 07master:1b932eb1508f: x86: add detection for FMA3 instruction set [22:47] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:d9574069c14a: Merge commit '1b932eb1508f550fac9e911923a0383efda53aa3' [22:49] <nevcairiel> it has a direct path to rgb24, but we all know that swscale sucks at generic conversions. Well, at least it does generic conversions, which is why most people use it ... but it also sucks at it... :) [22:58] <cone-688> ffmpeg.git 03James Almer 07master:d59fcdaff36e: x86: add detection for Bit Manipulation Instruction sets [22:58] <cone-688> ffmpeg.git 03Michael Niedermayer 07master:bd8d73ea8bb7: Merge remote-tracking branch 'qatar/master' [23:09] <BBB> kierank: well yv12 is the internal sws format for indirect conversions [23:09] <kierank> ah right [23:09] <BBB> see, that was one thing the old imgconvert did better - indirect conversion [23:10] <BBB> so it would do a shortest-path between known-direct conversions to do indirect conversions [23:10] <BBB> I'm not saying it's faultless, but at least it was free-form [23:10] <Daemon404> BBB, and as such we get evil silent passs through yv12 [23:10] <Daemon404> and fuck chroma [23:10] <Daemon404> its happened to me so many times. [23:10] <BBB> oh you guys watch chroma :-p [23:10] <BBB> ;-) [23:10] <BBB> I fully support that complaint, in fact, at some point I wanted to rewrite swscale [23:10] <BBB> but fuck scaling, nobody uses that anyway [23:11] <BBB> if vimeo wants to downsample input videos, pay someone to write a better one [23:11] <BBB> I'm not going to do it for free, it has no direct use for me [23:11] <Daemon404> i got yelled at for saying scaling should be decoupled last time [23:11] <Daemon404> me == me personally [23:11] <nevcairiel> the problem is that chroma conversion is scaling [23:11] <Daemon404> not vimeo [23:12] <Daemon404> nevcairiel, i referring to the mixeed scaling/conversion stuff filled with macros [23:12] <Daemon404> not chroma [23:12] <BBB> for you pesonally, I'd recommend just to ignore scaling and act like it doesn't exist [23:13] <BBB> it's best for your heart [23:14] <Daemon404> cant really, last time it hit me was rgb->444yuv conversion [23:14] <Daemon404> which had an implicit pass through 420 [23:14] <nevcairiel> i only use swscale for converting rare/uncommon pixel formats, screw chroma on those :p [23:14] <Daemon404> (which has since been fixed... i think) [23:14] <Daemon404> yes everyone writes their own [23:16] <nevcairiel> the only thing i really wrote is a yuv->rgb converter, because swscale either does point scaling or is *extremely* slow, everything else i wrote is just minor byte shuffling to conform to directshow pixel formats, which swscale doesn't do anyway [23:16] <Daemon404> P010 and pals? [23:17] <nevcairiel> (not to mention swscales problems with difference transfer matrixes and color ranges) [23:17] <nevcairiel> Daemon404: yeah [23:18] <nevcairiel> that reminds me that i wanted to offer rgb48 output from my rgb converter, instead of dithering the output [23:19] <andrewrk> hello. Question about the compand audio filter. in compand_drain, why does ff_get_audio_buffer use FFMIN(2048, s->delay_count) ? [23:19] <Daemon404> nevcairiel, how many renderers can even take that? [23:19] <Daemon404> probably just madvr [23:20] <nevcairiel> probably [23:20] <nevcairiel> but its like 5 lines of code [23:20] <nevcairiel> sowhynot [23:20] <nevcairiel> probably a bit more lines since its sse2 intrinsics [23:20] <nevcairiel> but not much more [23:24] <andrewrk> also I see if (fabs(g1 - g2)) where g1 and g2 are doubles. Why not simply g1 != g2 ? [23:24] <nevcairiel> because doubles [23:24] <andrewrk> ah it does the epsilon check [23:24] <ubitux> 0 vs -0 maybe [23:24] <nevcairiel> one shall never check floating points for equality [23:25] <andrewrk> but isn't "if (fabs(g1 - g2))" still checking floating points for equality? or is it ok because it casts down to floats, and that's why [23:25] <andrewrk> if the 'f' was missing it would be not ok [23:25] <ubitux> it's handling 0 and -0 [23:25] <ubitux> not a proper check though [23:26] <ubitux> i guess [23:26] <andrewrk> what would a proper check look like? [23:26] <ubitux> i'd say something like fabs(g1-g2)<0.0001 or something [23:26] <nevcairiel> there is constants for that [23:26] <ubitux> (don't we have a builtin for that?) [23:27] <ubitux> yeah but iirc there is compat concerns about using the epsilon constant [23:27] <nevcairiel> i think i saw a builtin for that [23:27] <ubitux> don't remember the details though [23:28] <Daemon404> clearly you should have used fixed point [23:30] <nevcairiel> if only fixed point would be easier to use :p [23:30] <nevcairiel> i always get confused by some calculations in fixed point :( [23:30] <Daemon404> or better yet [23:30] <Daemon404> convert all the fp ops in ffmpeg to use mpfr [00:00] --- Mon Feb 24 2014

1 0

ffmpeg.log.20140223
by burek 24 Feb '14

24 Feb '14

[01:26] <Jan-> is there a windows executable available anywhere that represents "current git head" [01:29] <klaxa> Jan-: probably not, but i would think these are pretty recent: http://ffmpeg.zeranoe.com/builds/ [01:31] <Jan-> So why is someone on the ffmpeg mailing list telling people to "test current git head" [01:32] <Jan-> I mean, we're not coders [02:17] <Hello71> http://ffmpeg.zeranoe.com/builds/: [02:17] <Hello71> Latest Zeranoe FFmpeg Build Version: git-44b22bb (2014-02-22) [02:18] <Hello71> https://github.com/FFmpeg/FFmpeg/commits/master [02:18] <Hello71> ctrl+f 44b22bb [02:18] <Hello71> ~1 day old [07:12] <Snowleaksange> ok got audio/video decode and resampling working [07:12] <Snowleaksange> now for encoding [07:26] <kms_> what happens if I could combine the video and audio tracks of different lengths? [08:50] <Snowleaksange> lets try and take the api changes down a notch this decade [08:50] <Snowleaksange> sometimes precedent is better than innovation or naming consistency [12:26] <totaam_> hi, I'm trying to get the "h265" (aka HEVC) decoder to show up in "./ffmpeg -decoders" but not having much luck: [12:26] <totaam_> http://pastebin.com/TiQN5P2U [12:27] <totaam_> Here's a patch to allow ffmpeg trunk to build against x265 trunk BTW: http://pastebin.com/cwhBkQiX [12:27] <totaam_> not that I care about encoding side, just to get ffmpeg to build with everything enabled [12:28] <totaam_> the only thing that looks suspicious is "WARNING: library configuration mismatch" - any clue? [12:40] -:#ffmpeg- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp [13:32] <Snowleaksange> what container & codecs should a live stream for <embed video> to work in browsers? [13:34] <Snowleaksange> er <video> [13:43] <JEEB> Snowleaksange, welcome to HTML5 video and streaming [13:43] <JEEB> it doesn't exist [13:43] <JEEB> except for Android 3.x+ and iOS version something, which have support for Apple's HLS thingamajig which is a horrible hack [13:45] <Snowleaksange> hmm ok. my browsers dont support flash anymore [13:47] <Snowleaksange> ok im installing flash player? [13:47] <Snowleaksange> famous last words [13:48] <JEEB> with flash you basically only get rtmpe, which I guess is a bit less of a hack than HLS? [13:48] <JEEB> flv over their protocol [13:50] <Snowleaksange> i used to have webcam + opencv fx streamed via flv and it worked in browsers fine [13:50] <Snowleaksange> but now the world has changed [13:50] <Snowleaksange> this time i cant even blame ffmpeg [14:02] <china> Snowleaksange: you could always get livestreamer which has support for a number of streaming services if you're wanting to watch https://github.com/chrippa/livestreamer [17:46] <qote> hi [17:46] <qote> i have a problem processing a file to h264 in kdenlive [17:46] <qote> it keeps saying: start time is not set in estimate_timings_from_pts [17:46] <qote> running arch linux [19:09] <JodaZ_> °.° wow, libav diverged quite a bit from ffmpeg [19:48] <znf> So, would anyone have any idea what format/container etc. I should stream for a html5 live video feed? [20:11] <JodaZ_> znf, h264/aac in mp4 with fallback of a flash player [20:12] <JodaZ_> znf, or, if your users are 90% techies, webm ofc [20:15] <znf> JodaZ_, so what transport should I use? [20:15] <znf> for live streaming? [20:15] <JodaZ_> oh wait, live? [20:15] <JodaZ_> sorry [20:16] <JodaZ_> the answer is HLS then [20:16] <znf> yeah [20:17] <JodaZ_> most streaming pages are using HLS or DASH nowadays [20:17] <JodaZ_> hmm, wait, html5 can't do either °.° [20:18] <JodaZ_> come to think of it, i don't think anyone is using html5 for live streaming [20:19] <JodaZ_> well, DASH is html5 in theory, but the support isn't ready i think [20:22] <rcombs> JodaZ_: at Plex, we use HLS and DASH for that in <video> [20:22] <JodaZ_> rcombs, does that work for anything besides apple devices? [20:22] <rcombs> and ffmpeg also can generate WebM files that Chrome likes; not sure on Firefox [20:22] <rcombs> DASH works in Chrome, at least [20:23] <rcombs> (WebM live-streaming, that is) [20:24] <JodaZ_> rcombs, question, can plex HLS be used as a caching source, or are segments different when requested out of order? [20:25] <rcombs> I'm not sure what you mean there [21:11] <znf> Unable to find a suitable output format for 'out.m3u8' [21:11] <znf> well, crap [21:11] <znf> now what? [21:13] <sacarasc> I didn't know that ffmpeg could make playlists. [21:14] <znf> sacarasc, the docs seems to say so [21:14] <znf> Do I need a streaming server if I want to push to flash? :-/ [21:15] <znf> I have a webcam that produces a rtsp stream, and I have no idea how to easily publish it on the web :-/ [21:21] <rcombs> re-read the hls or segment muxer docs [21:22] <rcombs> the output arg shouldn't be out.m3u8; it should be an image2-style output that indicates the path to the actual segments [21:22] <rcombs> the playlist is specified in a separate arg [21:27] <znf> rcombs, well the docs just say ffmpeg -i in.file out.m3u8 [21:33] <rcombs> hmm, so it seems, for the HLS muxer (I usually use the segment one) [21:33] <rcombs> try adding `-f hls`? [22:21] <llogan> znf: are you using an ancient build? [00:00] --- Mon Feb 24 2014

1 0