Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2015

1 participants
62 discussions

ffmpeg-devel.log.20151025
by burek 26 Oct '15

26 Oct '15

[01:49:04 CEST] <Tom012> Hello people. Is it possible to add support to detect an encrypted file and print an error message? [01:52:40 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.1:206129843857: videodsp: don't overread edges in vfix3 emu_edge. [01:52:41 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.2:beaf2728cea1: videodsp: don't overread edges in vfix3 emu_edge. [01:52:42 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.3:f6006295c037: videodsp: don't overread edges in vfix3 emu_edge. [01:52:43 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.4:d3af86c867c7: videodsp: don't overread edges in vfix3 emu_edge. [01:52:44 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.5:11579f7e4e99: videodsp: don't overread edges in vfix3 emu_edge. [01:52:45 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.6:743d6a2782ca: videodsp: don't overread edges in vfix3 emu_edge. [01:52:46 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.7:131f2c366e40: videodsp: don't overread edges in vfix3 emu_edge. [01:52:47 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07release/2.8:6616762134e1: videodsp: don't overread edges in vfix3 emu_edge. [01:55:38 CEST] <c_14> Tom012: what kind of encryption are we talking about here. For the most part, the purpose of encryption is to make something indistinguishable from random data, so unless it's explicitly tagged as encrypted, no. [01:56:43 CEST] <Tom012> c_14: I mean copy protected vob and m4v files. [01:58:39 CEST] <c_14> Assuming they're properly tagged (and they should be otherwise proprietary software wouldn't be able to play them either, it should be possible (I don't know anything about the related format specs though.) [02:01:45 CEST] <c_14> Looks like there might already be a ticket open for it https://trac.ffmpeg.org/ticket/4016 [02:04:20 CEST] <J_Darnley> Sure, I think that works for mp4 because the content of its "frames" are what is encrypted [02:04:56 CEST] <J_Darnley> but isn't VOBs with CSS protects just all encrypted? [02:15:30 CEST] <BBB> do we have infrastructure now to force the use of bitstream filters when muxing? [02:15:54 CEST] <BBB> I thought someone wrote that a while ago [02:15:57 CEST] <BBB> was that applied? [02:16:10 CEST] <J_Darnley> I'm not sure. [02:16:19 CEST] <J_Darnley> I remember the patch and the discussion. [02:17:22 CEST] <J_Darnley> I don't see it in my cvslog messages though [02:22:45 CEST] <wm4> rcombs has a patch [02:22:49 CEST] <wm4> not applied yet I think [02:23:18 CEST] <rcombs> sitting on the ML [02:23:30 CEST] <rcombs> I don't think anyone has explicit problems with any of it though [02:37:47 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:2ee51ef259e6: avfilter/vf_deshake: use a void * comparator for consistency [02:39:05 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:94f333f9dcfb: avutil/tree: improve documentation for av_tree_find, av_tree_insert [02:40:16 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:7c8fcbbde3a2: avutil/tree: add additional const qualifier to the comparator [02:35:34 CET] <BBB> rcombs: quite the contrary, I love the concept of it [02:35:39 CET] <BBB> rcombs: Id love for it to go in [02:35:48 CET] <BBB> rcombs: does it just need review? any explicit concerns that need to be resolved? [02:37:35 CET] <rcombs> BBB: another review pass certainly wouldn't hurt [02:38:47 CET] <rcombs> there was one concern about whether or not we should allow allocations in AVOutputFormat::init [02:39:11 CET] <rcombs> and the favorite solution seemed to be to add a `deinit` cleanup function [02:40:54 CET] <rcombs> which would also let you close a muxer without actually writing the trailer [02:41:03 CET] <rcombs> (useful in error cases, or in weird situations like segment.c) [02:42:12 CET] <rcombs> but that's kinda tangential [02:44:33 CET] <BBB> kind of, yes [02:44:38 CET] <BBB> ok Ill look at the review [02:45:09 CET] <rcombs> thanks [05:18:59 CET] <Timothy_Gu> weryuijokp532aq6w44qyugiytrd [05:19:41 CET] <Timothy_Gu> sorry it's my younger brother [05:20:04 CET] <Timothy_Gu> no its' not [05:20:12 CET] <Timothy_Gu> itfs me [05:20:19 CET] <Timothy_Gu> i love u [05:20:32 CET] <Timothy_Gu> homecoming? [05:20:53 CET] <Timothy_Gu> respond [05:20:57 CET] <Timothy_Gu> please [05:22:04 CET] <Timothy_Gu> sorry again. somebody hacked my machine physically. control now restored [05:24:39 CET] <Timothy_Gu> hi [05:24:45 CET] <Timothy_Gu> shit [05:24:57 CET] <Mark__> wtf is wrong with this guy [05:25:11 CET] <Mark__> who made him mod [05:25:45 CET] <Mark__> amirite [05:39:01 CET] Action: rcombs rebuilds an MP4 index by searching for 00 00 00 02 09 [07:32:25 CET] <atomnuker> hm, not sure how I missed the ridiculously long fabsf() vs FFABS() thread on the ML [07:34:45 CET] <atomnuker> a nice compromise would be to use C11's awesome generics to determine type and pick the usual for ints or fabsf() for floats [07:36:53 CET] <atomnuker> but being in the (C)90's has its upsides and downsides [07:40:54 CET] <atomnuker> or you know, the best and easiest way is to just use fabs(f)() directly in the code which is what the AAC encoder does [09:29:56 CET] <nevcairiel> noone wanted to rewrite the macro, it always was about replacing usage of FFABS with fabs(f) in float code [10:05:19 CET] <durandal_1707> my stuff is trivial to review [11:36:59 CET] <JEEB> was it possible to set -v debug only for specific things? [12:14:41 CET] <cone-463> ffmpeg 03Paul B Mahol 07master:6f3ba23ae0d4: avformat: add xvag demuxer [12:14:41 CET] <cone-463> ffmpeg 03Paul B Mahol 07master:1f36b43c280d: doc/general: update after recent additions [12:40:53 CET] Action: Daemon404 prods wm4 [12:41:28 CET] <wm4> ow [12:42:14 CET] <Daemon404> i think perhaps you may have a differing opinion re: locales [12:42:18 CET] <Daemon404> to nicholas [12:42:31 CET] <wm4> oh, potential flame again? [12:42:40 CET] <Daemon404> s/flame/bikeshed/ [12:42:51 CET] <Daemon404> nothing inflamatory pls [12:43:46 CET] <Daemon404> i am not against saying "stuff may not work unless locale=C" or something, however we ought to not set it. [12:43:53 CET] <Daemon404> (i cant tell which nicholas is adocating( [13:08:41 CET] <wm4> holy fuck claws-mail is in one of its fuckup periods where it scans the entire mail dir, and can't send emails [13:09:08 CET] <Daemon404> eh [13:09:12 CET] <Daemon404> thunderbird does this periodically [13:09:18 CET] <Daemon404> as well. [13:09:21 CET] <Daemon404> dont know why. [13:09:40 CET] <wm4> the log keeps showing "** IMAP error on imap.gmail.com: FETCH error" [13:09:56 CET] <wm4> could blame gmail [13:10:06 CET] <wm4> on the other hand, claws' network code seems to be the worst ever [13:11:02 CET] <Daemon404> you havent looked at irssi's then [13:19:54 CET] <wm4> #define ALIGN (HAVE_AVX ? 32 : 16) [13:20:00 CET] <wm4> this is in libavutil/mem.c [13:20:12 CET] <Daemon404> but why [13:20:16 CET] <wm4> so what happens if you compile lavu with AVX disabled, but lavc with AVX enabled? [13:20:20 CET] <Daemon404> why not just always 32 [13:20:30 CET] <wm4> gotta go faster? [13:20:36 CET] <Daemon404> [12:20] < wm4> so what happens if you compile lavu with AVX disabled, but lavc with AVX enabled? <-- how is this even possible [13:20:46 CET] <wm4> they're completely different libs, formally [13:20:48 CET] <J_Darnley> Why waste 16 bytes on alignment when you don't need it? </s> [13:24:53 CET] <Gramner> I wonder if aligning to 64 instead of 32 would actually improve cache hit rate since you'd always start on the beginning of a cache line [13:25:14 CET] <Gramner> for modern cpus with 64-byte cache lines that is [13:26:39 CET] <Daemon404> interesting idea... [13:29:05 CET] <kierank> Gramner: what about THPs as well then [13:29:20 CET] <rcombs> setting the locale in a lib is definitely super rude [13:30:50 CET] <Gramner> kierank: what about it? [13:31:07 CET] <kierank> well if you're aligning to 64, might as well do the THP stuff as well [13:31:15 CET] <kierank> on linux at least [13:32:11 CET] <Gramner> might want to consolidate mallocs as well in that case [13:32:31 CET] <Gramner> no idea how many mallocs are done in typical use cases with ffmpeg [13:32:37 CET] <kierank> not sure you can do that with buffer referencing [14:09:54 CET] <cone-463> ffmpeg 03Paul B Mahol 07master:f7751a5e5368: avformat/aiffdec: give friendly message if compressed codec tag is unsupported [15:08:18 CET] <cone-463> ffmpeg 03Ganesh Ajjanagadde 07master:c7131762c021: all: add const-correctness to qsort comparators [15:15:58 CET] <cone-463> ffmpeg 03Ganesh Ajjanagadde 07master:104f8ea873ad: version.sh: add note that ffversion.h is auto-generated [15:21:36 CET] <cone-463> ffmpeg 03Ganesh Ajjanagadde 07master:9bc3d3355f66: avcodec/huffman: replace qsort with AV_QSORT [15:38:00 CET] <cehoyos> durandal_1707: Will you upload the sample? [15:38:48 CET] <durandal_1707> no, first pay me [15:39:06 CET] <cehoyos> So the ticket can be closed? [15:40:18 CET] <durandal_1707> No, I'm uploading, arent you smart? [15:41:24 CET] <durandal_1707> first failed because of nonsense limit [15:41:25 CET] <cehoyos> I just couldn't know if you forgot to upload, that's why I asked... [15:55:50 CET] <cehoyos> Did you already fix it or may I? [15:56:39 CET] <wm4> ubitux: didn't you say you're doing something into direction of async API? [16:03:48 CET] <durandal_1707> cehoyos: no, go ahead and fix it if you can [16:07:20 CET] <cehoyos> I'll send a patch in a moment. [16:25:36 CET] <ubitux> wm4: yes, work in progress [16:27:17 CET] <wm4> ubitux: hm, into what direction is it going? [16:28:29 CET] <durandal_1707> cehoyos: I have encoder/decoder if you want to re it [16:30:47 CET] <cehoyos> That seems unnecessary: I just had to set "st->codec->extradata[14] = 224;" and bps has to be set. [16:31:09 CET] <cehoyos> The waveformatex header sets bps to 16, all our wmapro samples have 24. [16:31:16 CET] <ubitux> wm4: one async context, wrapping async "readers" (user set a pull packet callback, generally associated with a format context but can be anything), wrapping async codecs (user set push frame callback) [16:31:33 CET] <cehoyos> The decoder needs the value, I set it to 24 but I don't know if 16 could be "more correct". [16:32:02 CET] <ubitux> thread at every levels, and possibility for accel such as vtb to call the user callback themselves; and in standard codecs, it will be called post decode [16:33:09 CET] <cehoyos> Patch sent. [16:33:49 CET] <wm4> ubitux: not the API we discussed? [16:34:09 CET] <durandal_1707> cehoyos: does it sounds louder if you change it? [16:34:23 CET] <cehoyos> Where did you get the demuxer from? [16:34:30 CET] <cehoyos> Not sure... [16:35:58 CET] <ubitux> wm4: i'm trying to abstract more actually [16:36:08 CET] <ubitux> and i'm not fond of the query granularity [16:36:25 CET] <ubitux> i need to implement it myself to see if my model is viable so nothing more to propose so far [16:36:39 CET] <ubitux> i'll probably realize soon if it's flawed [16:36:46 CET] <nevcairiel> too much abstraction adds overhead, if i have to pass through 3 layers of threads to get to my decoded frame, thats bad =p [16:36:48 CET] <wm4> if there's really a packet pull callback, it sounds hard to deal with in general [16:36:50 CET] <cehoyos> 16 (as in the waveformatex header of the xwma file) is louder. [16:37:10 CET] <wm4> (have to block it until the demuxer is ready, if the queue got empty, etc.) [16:38:05 CET] <ubitux> i want to try it out, we'll discuss the details when i'm comfortable with what i wrote [16:38:29 CET] <wm4> ok [16:39:43 CET] <durandal_1707> cehoyos: what demuxer? [16:41:10 CET] <cehoyos> You wrote above that have a "encoder/decoder", I thought you meant a demuxer... [16:41:15 CET] <cehoyos> that you have [16:41:27 CET] <cehoyos> We have a decoder in libavcodec anyway. [16:44:47 CET] <durandal_1707> one from ms [16:46:17 CET] <cehoyos> Perhaps you can compare which loudness is more similar to ms? [16:53:39 CET] <BBB> Daemon404: I believe there was resistance from e.g. mru back in the days to making it 32 for everyone, since then arm would suffer for x86 (and admittedly, it makes no sense to have 32byte alignment on arm systems, and theres something to say to always using 16byte on these systems) [16:53:52 CET] <durandal_1707> cehoyos: the ms one is louder [16:53:58 CET] <BBB> Daemon404: as for x86 always using 32byte, yes, perhaps, I guess nobody cared [16:56:30 CET] <durandal_1707> cehoyos: 16 is more correct [16:57:36 CET] <durandal_1707> now if this can be found in xwma bitstream is another question [17:08:26 CET] <cehoyos> Changed locally to "st->codec->extradata[ 0] = st->codec->bits_per_coded_sample;" [17:15:23 CET] <durandal_1707> ok [17:31:28 CET] <cone-463> ffmpeg 03Michael Niedermayer 07master:65ffca9f803a: avutil/tree: Document the guaranteed ordering of compare arguments for av_tree_find() [17:38:28 CET] <cone-463> ffmpeg 03Carl Eugen Hoyos 07master:6498b34bba8c: lavf/xwma: Support wmapro. [17:38:40 CET] <cehoyos> Pushed, thank you! [17:46:02 CET] <cone-463> ffmpeg 03Ganesh Ajjanagadde 07master:bbd6bc6bd088: avutil/tree: clean up pointer incompatibility warnings [17:48:07 CET] <BBB> rcombs: I looked briefly at the patches, I think its fine, but the memleak after init should probably be fixed, yes [17:51:56 CET] <wm4> ./libavfilter/af_amerge.c:35:#define SWR_CH_MAX 64 [17:52:01 CET] <wm4> ./libswresample/swresample-test.c:34:#define SWR_CH_MAX 32 [17:52:03 CET] <wm4> what [17:52:15 CET] <JEEB> wat :D [17:52:22 CET] <wm4> ./libswresample/swresample.h:130:#define SWR_CH_MAX 32 ///< Maximum number of channels [17:52:46 CET] <nevcairiel> swresample_internal.h defines it to 64 again =p [17:53:18 CET] <wm4> ./libswresample/swresample_internal.h:28:#define SWR_CH_MAX 64 [17:53:20 CET] <wm4> yep [17:53:30 CET] <wm4> the API enforced limit seems to be lower than 64 [17:53:32 CET] <nevcairiel> you can blame carl for that last one, apparently he bumped it in july [17:54:25 CET] <nevcairiel> and nothing on the ML to be found on the why [17:54:31 CET] <durandal_1707> cehoyos is here :) [17:54:41 CET] <wm4> ah, looking into swresample.h, it's guarded by #if LIBSWRESAMPLE_VERSION_MAJOR < 1 [17:54:44 CET] <wm4> (wat) [17:55:20 CET] <nevcairiel> i suppose the max is not meant to be part of the API anymore? [17:55:27 CET] <wm4> probably [17:56:24 CET] <nevcairiel> should remove the public header line then, its dead code anyway now [17:59:14 CET] <wm4> oh I get it, init fails because lavu has std channel layouts only up to 8 [18:00:01 CET] <wm4> or something else [18:05:08 CET] <kierank> wm4, j-b, others: any formats you care particularly about fuzzing [18:05:28 CET] <kierank> the formats I care about h264, h264s, mp2audio, vp9 seem ok [18:05:54 CET] <wm4> if there's an attacker, he could use anything libavcodec supports (and which happens to be enabled), so I have no opinion [18:07:04 CET] <kierank> I don't care about attackers per se, more about corrupt data causing a crash [18:08:54 CET] <durandal_1707> flv, there are some crashes already reported on libav tracker [18:17:18 CET] <cehoyos> nevcairiel: Please search the mailing list, it's all there, I have to go sorry [18:21:38 CET] <kierank> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/mem.c;h=323b18311… [18:21:44 CET] <kierank> what's going on with this if(size)? [18:24:45 CET] <BBB> kierank: its really true [18:24:52 CET] <BBB> kierank: I filed a bug about that on apples ML at some point [18:24:53 CET] <wm4> nice indentation [18:24:58 CET] <BBB> kierank: it was obviously never addressed [18:25:00 CET] <kierank> BBB: yeah I meant the indentation [18:25:07 CET] <BBB> oh that, not sure, someone was lazy [18:25:11 CET] <BBB> maybe me [18:25:13 CET] <BBB> who knows [18:25:14 CET] <kierank> looks weird, that's all [18:25:23 CET] <wm4> the whole function looks "weird" [18:25:32 CET] <BBB> the whole function is weird [18:25:47 CET] <wm4> 155 #if CONFIG_MEMALIGN_HACK [18:25:47 CET] <wm4> 156 //FIXME ... [18:26:02 CET] <wm4> (nice one... if hack then fixme) [18:28:13 CET] <wm4> fucking hell [18:28:29 CET] <wm4> channel layouts should be uint64, but swresample's options treat it as int64 [18:28:36 CET] <wm4> and reject it if bit 63 is set [18:29:12 CET] <BBB> hahahahahahhahahah [18:32:58 CET] <wm4> does anyone happen to have a file with more than 8 channels? [18:37:07 CET] <durandal_1707> there are brstm ones somewhere [18:37:44 CET] <durandal_1707> and you can create them with aevalsrc [18:41:29 CET] <wm4> durandal_1707: how? [18:41:45 CET] <wm4> it wants a channel layout [18:42:07 CET] <durandal_1707> just give number? [18:42:38 CET] <Tom01> Hello people. Would it be possible to add copy-protection-detection to ffmpeg? I don't know if there is a copy-protection flag in vob or m4v files. [18:42:50 CET] <wm4> durandal_1707: 'aevalsrc=1:channel_layout=16' results in "Audio: pcm_f64le, 44100 Hz, 1 channels (BL)," [18:43:35 CET] <durandal_1707> you need to give 16 expressions [18:43:39 CET] <wm4> ... [18:43:50 CET] <wm4> and how? [18:44:00 CET] <wm4> oh, | as separator [18:44:11 CET] <wm4> still gives mono [18:44:20 CET] <nevcairiel> layout 16 is not 16 channels though [18:44:31 CET] <nevcairiel> try "16c" or something like that [18:44:39 CET] <durandal_1707> hmm c16? [18:45:04 CET] <nevcairiel> 16c means 16 channel, while 16 is just one channel, back left as t happens [18:45:12 CET] <nevcairiel> (0x10) [18:45:24 CET] <durandal_1707> ok [18:46:34 CET] <durandal_1707> anyway bunch of fileters will reject unknown layouts [18:47:23 CET] <durandal_1707> I changed few filters to accept anything [20:44:42 CET] <wm4> michaelni: if you want, I could look into adding such an UINT64 AVOption type? [21:01:34 CET] <cone-463> ffmpeg 03Nicolas George 07master:559603dae1f6: lavfi/drawutils: add const to blending mask. [21:44:04 CET] <thardin> there, hopefully this alexis fellow can make sense of my mxfdec feedback [21:45:56 CET] <Daemon404> make sense of mxf? [21:45:58 CET] <Daemon404> unlikely. [21:47:28 CET] <thardin> we can try [21:47:48 CET] <thardin> but the mxf gods require offerings [21:48:43 CET] <Daemon404> in the form of xml? [21:55:22 CET] <thardin> some XSLT would be a fitting tribute [22:16:48 CET] <michaelni> wm4, sure, if you like [22:52:09 CET] <cone-463> ffmpeg 03Clément BSsch 07master:6b5412cbfa55: avutil/opt: print more meaningful default flags values [23:23:46 CET] <BBB> ubitux: thanks for that :) [23:30:52 CET] <ubitux> BBB: yw :) [00:00:00 CET] --- Mon Oct 26 2015

1 0

ffmpeg.log.20151025
by burek 26 Oct '15

26 Oct '15

[05:37:55 CET] <mischmerz> Quick question: Does current ffmpeg support dsd over pcm (decode) ? [05:55:03 CET] <Technicus> Hello :) [05:58:24 CET] <Technicus> I'm trying to figure out how to view a webcam, and record it at the same time. Will someone please direct me to a suitable tutorial? [05:58:46 CET] <mischmerz> Technicus: Pretty quiet in here :( [05:59:03 CET] <Technicus> What are you doing over there? [06:01:09 CET] <mischmerz> Waiting for an answer in regard to dsd over pcm. [06:04:45 CET] <Technicus> What is dsd? [06:07:21 CET] <mischmerz> Technicus: Digital audio format. [07:25:20 CET] <Technicus> I feel like I am circling a solution with this: < http://superuser.com/questions/322216/how-can-i-pipe-output-of-ffmpeg-to-ff… >, but I do not understand how to pipe the captured video into ffplay. [08:30:42 CET] <Technicus> I finally came up with a solution: < https://gist.github.com/Technicus/a923e0f6d60e42b40609 >. It is not optimum, but it satisfies my objective. [10:26:46 CET] <comets> sup, is it possible to convert .mkv files (with HEVC) in .avi files without losing quality? [10:35:24 CET] <JEEB> use a lossless video format and it will be lossless [10:36:47 CET] <comets> such as? some do a movie in less than 5 minutes, others take longer that 2 hours :( [10:37:33 CET] <JEEB> ut video or ffv1 or whatever :P [10:37:51 CET] <JEEB> but most probably you don't want that because if you want AVI you want to play that shit on a crappy plastic toy? [10:38:13 CET] <JEEB> which is so old it still doesn't have an AVC decoder and support for newer containers [10:38:52 CET] <comets> probably :( [10:39:01 CET] <JEEB> "probably"? [10:39:11 CET] <JEEB> so what's your use case? does it really have to be AVI? [10:39:39 CET] <comets> wanna watch it on TV lol connected via USB to the dvd player [10:39:52 CET] <JEEB> which only supports AVI? [10:40:07 CET] <comets> sadly, .avi is he only format apart from .vob that can work on tv's.. [10:40:13 CET] <JEEB> not really :P [10:40:26 CET] <comets> wll maybe .mpg oo but thats it.. [10:40:28 CET] <JEEB> I have seen plenty of TVs that decode a whole lot of stuff [10:40:38 CET] <comets> mines from 2002 :P [10:40:43 CET] <JEEB> ok [10:40:47 CET] <JEEB> rip then [10:40:48 CET] <comets> with that big ass backside :P [10:41:02 CET] <JEEB> mpeg-4 part 2 encoding is a pain in the arse [10:41:50 CET] <JEEB> your best bet is to use libxvid and libmp3lame (I think lame was called like that in lavc) and use -q:v 2 + -b:a 192k or so [10:41:54 CET] <comets> i used > ffmpeg -i Maze.mkv -vcodec mpeg4 -acodec libmp3lame -qscale:v 2 -qscale:a 5 output.avi [10:42:11 CET] <comets> it can't seem to find libxvid and libmp3lame :/ [10:42:37 CET] <JEEB> the mpeg4 encoder is also acceptable but IIRC it's even more "fun" to set up [10:42:56 CET] <JEEB> well then I guess you didn't build ffmpeg with those libraries [10:42:59 CET] <comets> no wonder it takes forever :/ [10:43:12 CET] <JEEB> yes, the mpeg-4 part 2 encoders are not exactly optimized [10:43:22 CET] <JEEB> it's funny when a newer video format's encoder is actually faster [10:43:24 CET] <comets> 4 conversion i did ogot stuck at 99% .. that sucks ;/ [10:43:53 CET] <JEEB> although with HEVC the decoder might be the limiting part because that's not fully optimized yet (nobody paid for that yet) [10:43:57 CET] <comets> yeah i used older tools for conersion like WinAvi 7.7 but those tools do not like HEVC.. [10:44:19 CET] <comets> handbrake fails epically..doesn't like source.. [10:44:30 CET] <JEEB> probably just old [10:45:03 CET] <JEEB> I recommend a) making sure you've got the latest version and b) if the latest release is not good, try out the nightlies [10:45:20 CET] <JEEB> handbrake is probably the simplest open source encoding UI :P [10:45:21 CET] <comets> winavi is good to convert mp4 to avi for use on TV, does it within 12mins ..just failing with HEVC (mkv) formats.. [10:45:52 CET] <comets> i have the latest ffmpeg.. [10:47:21 CET] <JEEB> did you build it yourself or what? [10:48:30 CET] <comets> i can't build...i can't even make paper planes :( [10:49:03 CET] <JEEB> well I'm just asking because a) I'm guessing you're on windows and b) zeranoe's windows builds seem to include libxvid [10:49:18 CET] <JEEB> and you're saying you don't have libxvid in there [10:50:24 CET] <comets> its there, its just not used, i tried many variations of the name, won't use any..odd.. [10:51:01 CET] <comets> wow took 2 hours to convert a 110mb .mkv file into a 1.2gb mp4file :/ [10:51:38 CET] <JEEB> if it's that command line you pasted then it's not mp4 [10:51:58 CET] <JEEB> it's mpeg-4 part 2 in AVI and neither the HEVC decoder or MPEG-4 Part 2 encoder are optimized too hard [10:52:14 CET] <comets> oh yeah, a.vi , my bad.. i converted like 7 films in both formats lol [10:52:41 CET] <JEEB> also you didn't set a preferred bit rate but a quantizer (which kind of makes sense with MPEG-4 Part 2, although with any newer video format you wouldn't be using it) [10:52:52 CET] <JEEB> so complaining about any file size is kind of moot [10:53:36 CET] <comets> yeah i'll set 600kbps in the next one.. [10:53:40 CET] <JEEB> also your input most probably was bit rate starved anyways and is encoded in a newer video format so it's not exactly surprising [10:54:18 CET] <comets> yeah can you give me a good setting to use in the future? [10:54:25 CET] <JEEB> if you are going to do bit rate based then you have to use 2 passes, otherwise you'll end up with a bad result [10:54:54 CET] <JEEB> no, I don't know about mpeg-4 part 2 and it was before any video encoder started having presets or anything resembling user friendliness [10:55:26 CET] <JEEB> I'm kind of happy all of my hardware boxes can decode AVC [10:55:41 CET] <JEEB> that stuff has understandable profiles and levels, and easily usable + optimized encoders :P [10:55:58 CET] <JEEB> even my 1st gen xbox from '01 can handle it :D (well, it's a celeron inside so welp) [10:58:10 CET] <comets> anyone know a good film editor to cut off the end bit of a movie fast? [10:58:27 CET] <JEEB> if you know the timestamps you can just use -ss and -t [10:58:38 CET] <comets> its messing up wit hteh conversion i think, the idiots who 'pirated' the film decided to add their shitbit at the end :/ [10:59:10 CET] <JEEB> oh, then you can just set a -t that is just before the time that such things start [10:59:20 CET] <JEEB> so it will only encode until that point [10:59:45 CET] <comets> *facepalm* took me 2 hours to convert one vid :/ [11:00:27 CET] <JEEB> also you can cut matroska files on the random access points with mkvmergegui [11:00:31 CET] <JEEB> without re-encoding [11:00:35 CET] <JEEB> ffmpeg can also do it [11:00:44 CET] <JEEB> that way you can cut it physically off of the source [11:02:00 CET] <comets> damn, had mkvtoolnix, will get that one too.. [11:33:53 CET] <JEEB> ok, now bt.2020->bt.709 works with zimg :) https://github.com/sekrit-twc/zimg/commit/04076c121b4b078bff70972ce3cfa0df6… [11:34:17 CET] <JEEB> too bad the colorspace whiner is no longer here I see :/ [11:47:43 CET] <ChocolateArmpits> I think he was more outspoken about ffmpeg than colorspaces [11:48:19 CET] <JEEB> well his bottom line seemed to be "swscale sucks" [11:59:01 CET] <durandal_1707> he added avx optimizations [12:59:42 CET] <Skippy_42> Hey, guys, can anyone tell me what is wrong with this command "ffmpeg -i "/my/test/folder/testfile with spaces.flv" -c:v libx264 -c:a copy "/my/test/folder/testfile with spaces.flv.mp4" [13:00:20 CET] <Skippy_42> k sry [13:21:47 CET] <Skippy_42> Another question: What is my mistake when a command works when directly written into the terminal, but not when called from a shellscript? [13:22:21 CET] <c_14> probably escaping [13:24:01 CET] <Skippy_42> as I thought, I am still searching for solutions, didn'T find anything yet, if you have an idea tell me [13:26:34 CET] <ChocolateArmpits> use escape characters in paths or if the command has illegal characters then escape them too [13:29:11 CET] <iive> in unix escape char is \, so "\ " [13:30:52 CET] <Skippy_42> I thought I died, hehe [13:31:08 CET] <furq> Skippy_42: you need more quotes [13:31:13 CET] <Skippy_42> I am still searching for what is not escabed correctly [13:31:14 CET] <furq> or you have too many quotes [13:31:21 CET] <furq> or you have the right number of quotes distributed incorrectly [13:31:32 CET] <Skippy_42> I post those 2 lines, I guess it doesnt need to be pastebin for that, right? [13:31:54 CET] <furq> if you pastebin it then it's easier for us to fix it [13:31:59 CET] <Skippy_42> kk [13:33:09 CET] <Anoia> Skippy_42: at what point will a paste become an annoying paste? It's best to put anything that isn;t conversation elsewhere [13:33:32 CET] <Skippy_42> http://pastebin.com/r7Mf4Fpi [13:34:59 CET] <Skippy_42> ok wait that suxx I put the outputs there too, I just need afk aaaaaahhh everybody around me is driving me crazy, sry for wasting your click, I do a usefull post in 15 mn [13:35:02 CET] <Skippy_42> min* [13:35:27 CET] <furq> i take it you're storing ffcmd in a variable for a good reason [13:37:17 CET] <furq> Anoia: i'm pretty sure the internationally recognised size for an annoying paste is three lines [13:47:16 CET] <Skippy_42> I'm sorry for that. It works now when I don't put the command in a variable, so thx for that, I will check why another time [13:54:32 CET] <JEEB> I have found that in the end things tend to work most expected when you create the parameters yourself and launch the application with an array you have created yourself. I don't think shells let you do such things, but python f.ex. should [13:54:44 CET] <JEEB> or ruby [13:55:48 CET] <furq> i generally stop writing shell scripts as soon as escaping becomes necessary [13:56:05 CET] <c_14> bash/zsh etc have arrays, but they're really ugly to use [13:56:18 CET] <c_14> As is most shell scripting [13:56:29 CET] <furq> i also restrict myself to /bin/sh to further resist temptation [13:57:10 CET] <JEEB> c_14: most specifically they probably lack and exec() that takes in an array [13:57:19 CET] <JEEB> and properly separates the arguments thus [13:58:02 CET] <JEEB> the good part is that you skip shell in that case, the bad part is that you have to create lists of files and stuff like that yourself [16:56:39 CET] <inflex> Trying to enable 'faststart' to movflags programatically in C++, already have dsr = av_dict_set(&pmetadata, "movflags", "faststart", 0); but that doesn't seem to enable it. Other attributes I set via av_dict_set() are working (such as stream title). [16:59:18 CET] <BtbN> is your output seekable? [17:00:41 CET] <inflex> once once the stream has been fully written, in which case it's no different to when I've not tried applying the faststart flag [17:01:05 CET] <BtbN> what do you mean? [17:01:30 CET] <BtbN> ffmpeg can't write the moov atom to the front imediately. It only does so at the end, seeking back to the front and writing it. [17:01:42 CET] <BtbN> So if the output is not seekable, it has no effect. [17:02:36 CET] <inflex> source is from a h264 security cam, being written in 10 minute blocks to mp4 files. Sometimes it's desirable to download and view events prior to the termination of the 10 minute block [17:02:56 CET] <inflex> (ie, partially complete file) [17:03:04 CET] <BtbN> Don't use mp4 then? [17:03:48 CET] <inflex> mp4 is preferrable because the stream is already h264 encoded and mp4 otherwise is well supported by most browsers with HTML5 players; also transcoding to another format adds quite a chunk of load [17:04:07 CET] <BtbN> Well, watching before the file is done isn't going to happen then. [17:05:19 CET] <inflex> So all the fragmented / moov options are more about making the mp4 seekable /post-completed/. [17:05:38 CET] <BtbN> The information that's needed to create the moov atom does not exist before the file is complete. [17:05:39 CET] <inflex> ie, no doubt I'd be able to seek/stream it just fine once the 10 minute block is done and the stream closed. [17:05:45 CET] <BtbN> It's impossible to write it at the beginning. [17:06:16 CET] <inflex> okay, np, that was my dud assumption then about the nature of the fragmenting process. [17:06:45 CET] <inflex> mkv does work I've found (at least, partially), just that it's not supported too well in-browser. [17:07:23 CET] <BtbN> nothing is supported too well in a browser. [17:07:29 CET] <inflex> True enough. [17:08:24 CET] <BtbN> Use flash if you want stuff that just works. [17:12:09 CET] <DHE> is mpegts browser supported? it will hold h264 with only a -bsf required [17:12:36 CET] <ChocolateArmpits> ts will most likely need a player [17:13:22 CET] <JEEB> mpeg-ts is only supported with HLS playlists and only with mobile configurations [17:13:24 CET] <JEEB> for whatever reason [17:14:01 CET] <JEEB> I think edge is the only desktop browser that supports it [17:14:24 CET] <DHE> damn [17:17:46 CET] <inflex> thanks for the clarification BtbN [17:18:12 CET] <inflex> Might have to go with mkv container + custom viewing clients for win/*nix [17:24:24 CET] <pcroland> Hi [17:24:59 CET] <pcroland> How can I concatenate multiple VOB files and using yadif at the same time? [17:26:19 CET] <durandal_1707> with concat filter [17:28:57 CET] <pcroland> Filtergraph 'yadif=deint=interlaced' was specified through the -vf/-af/-filter option for output stream 0:0, which is fed from a complex filtergraph. [17:28:57 CET] <pcroland> -vf/-af/-filter and -filter_complex cannot be used together for the same stream. [17:30:11 CET] <pcroland> I get this error when I try this command: http://pastebin.com/raw.php?i=JYBSRMSM [17:35:32 CET] <durandal_1707> use only filter complex [17:39:04 CET] <pcroland> How? :S [17:39:28 CET] <fred1807> can I convert 1 png image to a 30 second movie? [17:41:12 CET] <durandal_1707> yes [17:42:04 CET] <fred1807> Am I missing anything here? ffmpeg -loop 1 -i image.png -c:v libx264 -t 15 -vf scale=1920:1080 out.h264 [17:42:08 CET] <durandal_1707> pcroland: -lavfi ...concat, yadif... [17:44:06 CET] <fred1807> I see a tutorial with "-pix_fmt yuv420p" <-- Is this related to 420p resolution? (I want 1080p...) [17:44:59 CET] <c_14> If you want a 30s movie, why are you specifying a length of 15s? [17:45:01 CET] <pcroland> fred1807, there is no connection with the 420p [17:45:08 CET] <pcroland> to the resolution [17:46:11 CET] <fred1807> this is what I did, ffmpeg -loop 1 -i fundoinsta1080p.png -t 15 -vf scale=1920:1080 out.h264 [17:46:12 CET] <fred1807> I got a warning about yuv420p , but I guess I dont need to use it becuase my output is raw h264, am I right? [17:47:17 CET] <pcroland> durandal_1707, Still have no idea how to deinterlace the concated video :S [17:47:42 CET] <durandal_1707> with yadif [17:48:30 CET] <pcroland> I know that I have to use yadif but as I said I get an error when I use it with the concat filter [17:53:32 CET] <durandal_1707> Pastebin output [17:57:26 CET] <pcroland> http://pastebin.com/raw.php?i=aPMyvNQ8 [17:58:10 CET] <ChocolateArmpits> fred1807: pixfmt sets chroma subsampling, basically the resolution of chroma channels. The subsampling model you use largely depends on video delivery. [17:59:58 CET] <durandal_1707> pcroland: I told you to use only filter_complex , add yadif after concat [18:01:37 CET] <ChocolateArmpits> That's not how you concat vob parts [18:02:15 CET] <ChocolateArmpits> it should be -i concat:"VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB|VTS_01_4.VOB" [18:02:26 CET] <ChocolateArmpits> upward slash is used to separate different files [18:02:54 CET] <ChocolateArmpits> after that you can use normal video filters [18:02:57 CET] <ChocolateArmpits> -vf yadif [18:03:05 CET] <durandal_1707> no, concat protocol should not be used [18:03:20 CET] <ChocolateArmpits> why ? I never had trouble with it with dvs [18:03:23 CET] <ChocolateArmpits> dvds* [18:03:45 CET] <durandal_1707> specially if vobs have different params [18:03:59 CET] <ChocolateArmpits> Well the file names suggest same source [18:04:18 CET] <ChocolateArmpits> and the format output does so too [18:04:24 CET] <ChocolateArmpits> I really see no problem here [18:05:19 CET] <pcroland> http://pastebin.com/86HQD2S9 durandal_1707 [18:05:56 CET] <ChocolateArmpits> filter complex isn't needed when using concat filter after that [18:06:18 CET] <ChocolateArmpits> as it's treated as a single input [18:06:34 CET] <pcroland> Those files have the same params [18:06:40 CET] <pcroland> It's a film [18:06:56 CET] <ChocolateArmpits> You might just want to map the video stream only -map 0:v [18:06:56 CET] <pcroland> So what should I do? [18:07:19 CET] <ChocolateArmpits> remove filter_complex, and replace existing -map to -map 0:V [18:07:24 CET] <ChocolateArmpits> -map 0:v that is [18:07:27 CET] <ChocolateArmpits> lowercase [18:07:49 CET] <ChocolateArmpits> You can also disable audio with -an [18:19:58 CET] <pcroland> It works, thanks [18:20:02 CET] <pcroland> ChocolateArmpits [18:20:08 CET] <ChocolateArmpits> pcroland: np [18:24:20 CET] <pcroland> Is it possible tho crop odd pixel from the left and odd pixel from the right? [18:25:50 CET] <ChocolateArmpits> pcroland: You can use a crop filter after yadif [18:28:52 CET] <pcroland> yadif=0:0:0 should be good, am I right? [18:30:03 CET] <ChocolateArmpits> If the source is top field first then yes [18:32:52 CET] <pcroland> It is [22:01:45 CET] <ribasushi> greetings [22:02:00 CET] <ribasushi> https://github.com/FFmpeg/FFmpeg/commit/e786e96be <--- this commit broke some use of ffmpeg for me [22:02:40 CET] <ribasushi> I use rtp as a *secondary* -c:v copy stream of a crappy built-in camera which produces non-standard jpeg frames [22:03:04 CET] <ribasushi> the secondary stream is needed only to "tune-in" to the recording to check that focus/position are correct [22:03:27 CET] <ribasushi> the result with older versions of ffmpeg is absolute crap, but it is sufficient for my purposes as stated above [22:03:50 CET] <ribasushi> is there any way a "continue anyway" option could be added to the RTP muxer? [22:04:53 CET] <c_14> It's possible, but I don't think support for creating invalid output streams should be commited to master. You could probably just revert that commit for local builds. [22:04:56 CET] <ribasushi> alternatively if someone can suggest a different container to stream arbitrary (sometimes really broken) frames in copy-mode, I can simply switch away from RTP [22:05:15 CET] <c_14> Just use udp or tcp? [22:05:33 CET] <ribasushi> c_14: but which container format? [22:06:35 CET] <ribasushi> "just use udp" is what's confusing for me... [22:07:39 CET] <c_14> Maybe matroska, that usually supports all formats. [22:08:41 CET] <ribasushi> this indeed works, I wasn't aware I can do that [22:08:59 CET] <ribasushi> a "local build" is not possible as this is supposed to be a generic tool, supporting whatever one throws at it [22:09:03 CET] <ribasushi> but this is good enough [22:09:12 CET] <ribasushi> ... -c copy -f matroska udp://127.0.0.1:1234 [22:09:19 CET] <ribasushi> c_14++ # thanks! [23:59:16 CET] <pcroland> Is it possible that an tff interlaced (MediaInfo) PAL film is progressive regardless what MediaInfo says? [23:59:54 CET] <iive> yes [00:00:00 CET] --- Mon Oct 26 2015

1 0

ffmpeg-devel.log.20151024
by burek 25 Oct '15

25 Oct '15

[00:00:39 CEST] <nevcairiel> in any case, it also helps to ensure surfaces are free'ed in the correct order, since the decoder has a ref on the surfaces, so if i free it last, it ensures that all surfaces are free'ed in one go when all are unused [00:00:52 CEST] <nevcairiel> since they are also allocated as one block [00:01:04 CEST] <nevcairiel> in any case, it prevented problems =p [00:07:55 CEST] <mateo`> nevcairiel: where (in the code) do you actually do the refcounting part ? i wonder if there's an api to do some refouncting other than the avbuffer one [00:08:38 CEST] <nevcairiel> its in ffmpeg_dxva.c [00:08:47 CEST] <nevcairiel> and it uses windows refcouting things [00:08:53 CEST] <nevcairiel> avbuffer is the only thing it has [03:40:38 CEST] <BBB> kierank: fixed (4935, that weird vp9 file that eats memory) [04:42:14 CEST] <kierank> BBB: cool, will see if that fixes the rest of the fuzz crashes [04:42:48 CEST] <BBB> it didnt crash [04:42:52 CEST] <BBB> it just upsets your computer [04:42:58 CEST] <BBB> its totally valid whats happening in fact [04:43:12 CEST] <BBB> (in this case its not intended, but it could easily happen for a real file) [09:34:18 CEST] <rishi_> Hello, [09:35:06 CEST] <rishi_> I am student of computer science. I wanted to contribute in your organization how can I contribute ? [09:35:19 CEST] <rishi_> In the past I cracked GSoC 2015 [13:02:25 CEST] <cone-146> ffmpeg 03Michael Niedermayer 07master:e06ef9aa5fe8: avcodec/dpxenc: Fix "libavcodec/dpxenc.c:250:44: warning: passing argument 3 of av_image_copy_to_buffer from incompatible pointer type" [13:11:47 CEST] <cone-146> ffmpeg 03Carl Eugen Hoyos 07master:9c069bf71af2: lavc/hapdec: Use correct no-transparency colour space. [14:06:54 CEST] <cone-146> ffmpeg 03Carl Eugen Hoyos 07master:a3bed3f3e1a0: lavf/ingenientdec: Add a probe function. [16:13:30 CEST] <cone-146> ffmpeg 03Marton Balint 07master:03037a4aad8b: ffplay: use a separate struct for the rescaled YUVA AVSubtitle rectangles [16:13:31 CEST] <cone-146> ffmpeg 03Marton Balint 07master:5e9f14e4bf3a: libzvbi-teletextdec: fix AVSubtitleRect pict compatiblity code [16:20:10 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:683462911db5: avfilter: avoid zero arguments to variadic macro [17:29:46 CEST] <mateo`> llllllllllllllllllllllllllllll588888888888888888888888888888888888=$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$odddddddddddddddddddddddddddddddddddddddddddçikkkkkkkkkkkkkkkkkkkkkkkkkk*****è$bùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùù [17:29:47 CEST] <mateo`> ùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùy9+++++++++++++++++++++++++++++++++++++++++++++++++++ [17:29:49 CEST] <mateo`> *mlùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùù)-666666666663+++ppppppp [17:29:51 CEST] <mateo`> ôooo [17:30:31 CEST] <JEEB> cat on the keyboard? [17:30:41 CEST] <mateo`> mmm sorry :\, my cat tried to say something ... [17:30:55 CEST] <JEEB> I guessed it :) [17:31:05 CEST] <JEEB> I have seen some "catwalks" on IRC before [17:31:17 CEST] <mateo`> JEEB: héhé :) [18:20:29 CEST] <wm4> so why the fuck do these fragmented http streaming things not just slice the data on the byte level? it might increase the latency in some cases, but can't be so bad compared to all the other messes [18:28:36 CEST] <kierank> wm4: slice on the byte level? [18:29:02 CEST] <kierank> so just cut arbitrarily like an mpegts? [18:29:18 CEST] <wm4> yes [18:29:31 CEST] <wm4> the problem is that they want to use http CDNs to distribute the load, right [18:29:44 CEST] <JEEB> well, I think I just got relatively correct BT.2020->BT.709 out of ffmpeg with zscale :) [18:30:02 CEST] <kierank> wm4: yes [18:30:12 CEST] <kierank> wm4: you can't switch bitrate segments [18:30:16 CEST] <kierank> if the cut is arbitrary [18:30:42 CEST] <wm4> kierank: then just switch to an entirely different stream [18:31:08 CEST] <kierank> yes but it won't be seamless [18:37:08 CEST] <kierank> "Picture size 262864x262752 is invalid" lol [18:46:56 CEST] <wm4> sounds a bit high [18:55:29 CEST] <kierank> fuzzed file [21:09:21 CEST] <BBB> kierank: I believe any picture size where wxh>INT_MAX is invalid [21:09:26 CEST] <BBB> kierank: thats ff_set_dimensions [21:11:34 CEST] <wm4> the threshold is much lower, but something like this [21:12:12 CEST] <wm4> I think it's actually INT_MAX/8 [21:12:44 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07master:52f84d82bdf1: videodsp: don't overread edges in vfix3 emu_edge. [21:12:45 CEST] <cone-146> ffmpeg 03Ronald S. Bultje 07master:49d8a70dc51e: vp9: uses ff_set_dimensions (which sets coded_width/height). [21:13:04 CEST] <BBB> kierank: fix pushed, vp9 should be good again [21:14:14 CEST] Action: durandal_1707 there so many sdx2 aifc files [21:15:52 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:4c96985af1b8: all: remove some casts of function pointer to void * [23:59:36 CEST] <cone-146> ffmpeg 03Ganesh Ajjanagadde 07master:38f4e973efef: all: fix -Wextra-semi reported on clang [00:00:00 CEST] --- Sun Oct 25 2015

1 0

ffmpeg.log.20151024
by burek 25 Oct '15

25 Oct '15

[00:01:22 CEST] <onefix> Ok, so my CHIP took ~15x the time to encode a 30 second video as my AMD ... that's without any hardware drivers, but I don't suspect it will get much better with those ... has anyone done an extensive test of several systems with FFMPEG encoding??? [00:01:50 CEST] <onefix> I would really like to find out what would give the best "bang for the buck" so to speak [00:12:12 CEST] <furq> which amd cpu is that [00:16:35 CEST] <Mavrik> O.o [00:36:19 CEST] <TD-Linux> probably using one thread on the AMD [01:06:43 CEST] <BullHorn> is there a way to use ffmpeg inside Adobe Premiere's encoder? [01:06:52 CEST] <BullHorn> they use h264 mainconcept and its TERRIBLE [01:06:59 CEST] <BtbN> ask adobe? [01:09:22 CEST] <TD-Linux> no, export to a lossless or near lossless format and encode separately [01:13:20 CEST] <xsi> mavrik here [01:14:49 CEST] <xsi> mavrik It is usually 44100 and 96k or so but i started trying lesser and lesser for sound to break through working [01:20:19 CEST] <TD-Linux> xsi, since you mention it works with other codecs, and presumably you are stuck with AAC, have you tried ffmpeg's built in aac encoder? [01:20:35 CEST] <TD-Linux> also you should probably only use 44100 or 48000 [01:36:26 CEST] <xsi> how to go built aac? just to clarify.. [01:38:55 CEST] <xsi> 44100 48000 ok i'll be testing within those parameters [01:39:34 CEST] <xsi> ffmpeg -f alsa -ac 2 -i hw:0,0 -f x11grab -framerate 30 -video_size 1280x1024 -i :0.0+0,0 -vcodec libx264 -preset veryfast -maxrate 1984k -bufsize 3968k -vf format=yuv420p -g 60 -acodec libmp3lame -b:a 96k -ar 44100 -f flv 'rtmp://live.twitch.tv/app/live_100571654_3GRona33f8mCtHKYeCjnqLzNDNewf7' [01:40:05 CEST] <xsi> almost sure that lots of parameters bufsize maxrate.. preset.. are excessive [01:40:32 CEST] <xsi> but i see video and try again and reemerge. so to bo builtin i used [01:40:42 CEST] <xsi> libfaac or aac -strict experimental [01:40:59 CEST] <xsi> again, not very sure how.. [01:41:38 CEST] <xsi> It's really a pain here on forum they advice to use ffcast (i guess its' only a frontend): http://www.linuxquestions.org/questions/showthread.php?p=5439297#post5439297 [01:41:52 CEST] <xsi> so little dishearten me from cmdline parameters(( [01:49:42 CEST] <xsi> so again, its very bad i'm stuck with sound and codecs and it shows again that it's not ffmpeg but my system, which is fresh anew a kernel 4.2.3 and other yesterday emerged updated stuff [01:49:56 CEST] <xsi> it shows picture but not sound [01:55:15 CEST] <xsi> /upd: the same with mp4 and libmp3lame / libfaac . mb wrong library? or alsa problems as i thought previously [02:29:41 CEST] <DHE> is the ffmpeg native AAC encoder better than libfdk at this point? or should I stick with libfdk [02:30:57 CEST] <meh`> what am I supposed to do with the avcodec_encode_subtitle output buffer? [02:31:38 CEST] <meh`> just stick it into an AVPacket like there's no tomorrow and write it to the format? [02:47:18 CEST] <koz_> What kind of bitrate should I set for music encoded with opus? [02:47:38 CEST] <koz_> I'm aiming for minimal size without sounding like ass. [02:54:25 CEST] <furq> koz_: 96k should be more than enough for all your azis videos [02:56:11 CEST] <koz_> Hi furq! Nice to see you again. Will 48k still sound OK? [02:56:50 CEST] <furq> no idea, i'm just looking at http://listening-test.coresv.net/nonblocked_means_all2.png [02:57:40 CEST] <furq> 64k opus scored a 4 on the same test so i'd probably stick with that for music [02:58:06 CEST] <koz_> OK. [03:56:10 CEST] <BullHorn> wait wat [03:56:21 CEST] <BullHorn> apparently ffmpeg already has support for exporting from premiere pro [03:56:21 CEST] <BullHorn> https://trac.ffmpeg.org/wiki/Encode/PremierePro [03:56:32 CEST] <BullHorn> so why are you guys telling me to go ask adobe [03:56:33 CEST] <BullHorn> ;/ [04:38:49 CEST] <BullHorn> anyway [04:38:53 CEST] <BullHorn> i followed the guide at https://trac.ffmpeg.org/wiki/Encode/PremierePro [04:39:10 CEST] <BullHorn> and when i do the final stage of using ffmpeg i get an error 'frameserver.avs: Unknown error occurred' [04:39:14 CEST] <BullHorn> not very helpful ;x [04:39:42 CEST] <BullHorn> the cmd i used was [04:39:47 CEST] <BullHorn> ffmpeg -i f:\frameserver.avs -c:v libx264 -preset veryfast -crf 19 -pix_fmt yuv420p -c:a libfdk_aac -vbr 4 Output.mp4 [09:28:38 CEST] <worstje> Does anyone here have experience generating a video from an image+sound file combination? No matter what I try, the result always ends up longer than the audio source file for some weird reason. [12:57:38 CEST] <Jan-> hihi guys [12:58:06 CEST] <Jan-> this is not directly ffmpeg related, but you guys might be able to help. Does the string "AVC_VBR150M_3840_2160_25P_High(a)5.1" mean anything in terms of a type of video codec? [13:00:34 CEST] <JEEB> AVC is the MPEG name for MPEG-4 Part 10 aka H.264, VBR just means variable bit rate (which is what most video is), 150M = probably 150 megabits per second, the next two values are probably the resolution, and then you get the progressive rate (pictures in a second), and the last thing is the AVC profile and level [13:00:58 CEST] <Mavrik> yp. [13:01:11 CEST] <Mavrik> So I guess a 4K record at 25FPS? :) [13:01:28 CEST] <ChocolateArmpits> i'd say broadcast 4k [13:01:34 CEST] <JEEB> UHD you mean, while "4K" is often misused for that [13:01:42 CEST] <JEEB> "4K" is a bit wider [13:01:52 CEST] <ChocolateArmpits> and has a different aspect [13:02:03 CEST] <Mavrik> Point there. [13:04:13 CEST] <Jan-> it's a file made by a jvc gy-ls300 camera. [13:04:38 CEST] <Jan-> and yes it does support UHD and 4K :D [13:04:39 CEST] <JEEB> well, it's AVC [13:05:04 CEST] <JEEB> and that's pretty much all you have to know about that is somewhat relevant about the file from the file name :) [13:05:42 CEST] <Jan-> ah [13:05:46 CEST] <Jan-> ffmpeg -i thing.mov [13:05:47 CEST] <Jan-> Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 100647 kb/s, 25 fps, 25 tbr, 2500 tbn, 50 tbc (default) [13:06:05 CEST] <JEEB> yup [13:06:16 CEST] <Jan-> so that's "good" h.264? [13:06:24 CEST] <JEEB> in what sense "good"? [13:07:21 CEST] <Jan-> I uhoh. [13:07:28 CEST] <Jan-> I guess it's hard to evaluate how good a job an encoder is doing. [13:07:45 CEST] <Jan-> probably a hardware encoder in a camera is doing less of a good job than a piece of software could. [13:08:23 CEST] <Jan-> can ffmpeg determine if the stream is 10 bit? [13:08:32 CEST] <JEEB> yes [13:08:33 CEST] <Jan-> does yuv420p imply 8 bit? [13:08:36 CEST] <JEEB> yes [13:08:40 CEST] <Jan-> bummer [13:08:41 CEST] <JEEB> yuv420p10 would be 10bit [13:08:57 CEST] <Jan-> there's no chance that's incorrect? because this is supposed to be a broadcast camera. [13:09:07 CEST] <JEEB> nope [13:09:13 CEST] <Jan-> Bumfluff :/ [13:09:15 CEST] <JEEB> as long as your ffmpeg is not from like 2011 [13:09:29 CEST] <Jan-> errr [13:09:30 CEST] <Jan-> 2013 [13:09:32 CEST] <Mavrik> Also because it's a broadcast camera it probably records in YUV420P [13:09:42 CEST] <Mavrik> Since that's the only widely supported pix format for players. [13:09:44 CEST] <JEEB> yeah, that's way more than new enough [13:09:55 CEST] <Jan-> fmpeg version N-57245-gf6b56b1 Copyright (c) 2000-2013 the FFmpeg developers [13:09:55 CEST] <Jan-> built on Oct 18 2013 18:08:17 with gcc 4.8.2 (GCC) [13:10:16 CEST] <JEEB> the camera seems to be able to do 4:2:2 with 1080p [13:10:22 CEST] <JEEB> but no word about 10bit [13:10:41 CEST] <Jan-> interesting that the 4k is 420 [13:10:46 CEST] <Jan-> it doesn't say that on the advertisements :) [13:11:03 CEST] <Jan-> to be fair it is a low end broadcastish camera, it records to sdxc cards. [13:11:04 CEST] <JEEB> well with progressive you don't really need 4:2:2 [13:11:20 CEST] <JEEB> 4:4:4 would be best, but almost nothing supports that :P [13:11:41 CEST] <JEEB> and well of course, but usually good such things (hardware encoders) compensate by throwing bit rate at the problem [13:12:01 CEST] <Jan-> 150 megabits is quite a lot I suppose. Although not for uhd. [13:12:09 CEST] <Mavrik> Yeah, IMO 4:4:4 would be way more useful than 10bit :) [13:12:33 CEST] <Mavrik> The realtime camera encoders are generally terrible, so it never hurts throwing more bitrate at them [13:12:34 CEST] <Jan-> to be honest we often shoot 4k for hd output, and you get almost-444 and almost-10bit when you scale it down anyway :) [13:12:56 CEST] <JEEB> well, yeah - 2160p contains 1080p chroma [13:13:09 CEST] <Jan-> I'm not sure if there's a way of making ffmpeg do that. [13:13:14 CEST] <Jan-> produce 10 bit out from 8 bit in, via scaling [13:13:16 CEST] <ChocolateArmpits> 10bit is better than 8 bit for color correction [13:13:30 CEST] <JEEB> ChocolateArmpits: yes your filtering workflow should be higher bit depth [13:13:38 CEST] <JEEB> but having the input be 8bit isn't *that* bad [13:13:42 CEST] <ChocolateArmpits> But 4:2:2 and up is better for keying [13:13:57 CEST] <ChocolateArmpits> However at high enough resolution chroma subsampling isn't really an issue [13:13:58 CEST] <JEEB> and of course with AVC 10bit helps with compression [13:14:14 CEST] <Mavrik> Jan-, well, make a filterchain, convert to 10bit first, scale second, do the processing ? [13:14:32 CEST] <JEEB> you could test the new scaling/colorspace conversion filter [13:14:34 CEST] <JEEB> zscale [13:14:43 CEST] <Mavrik> Since your input is 8bit anyway and you need additional precision when running filters. [13:14:48 CEST] <JEEB> it uses the z.lib library https://github.com/sekrit-twc/zimg [13:15:19 CEST] <JEEB> although I'm not sure if it supports switching colorspaces yet... will have to see, I was meaning to poke it today [13:15:25 CEST] <JEEB> (I mean the ffmpeg wrapper) [13:15:25 CEST] <Mavrik> What's the benefit over swscale? [13:15:30 CEST] <ChocolateArmpits> JEEB: Oh I saw that before for Vaporsynth [13:15:32 CEST] <JEEB> much better quality [13:15:38 CEST] <ChocolateArmpits> So it got "ported" or something? [13:15:43 CEST] <JEEB> no, it's a library [13:15:51 CEST] <JEEB> unlike fmtconv [13:15:55 CEST] <JEEB> which is a vapoursynth filter [13:16:23 CEST] <JEEB> z.lib does have a vapoursynth filter as well, but the library part exists which is generic [13:17:01 CEST] <ChocolateArmpits> aww SD PAL colorspace not supported [13:18:31 CEST] <lyss> hi [13:18:35 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_zscale.c;h=50… [13:18:40 CEST] <JEEB> these seem to be the ones it actually supports [13:19:14 CEST] <JEEB> it seems to support all of the main primaries and matrices and transfers [13:19:31 CEST] <JEEB> I'd just guess the readme was never updated :P [13:19:36 CEST] <ChocolateArmpits> k [13:20:53 CEST] <JEEB> I still wonder if you can do colorspace conversion with the libavfilter thing (well, it often does it when it's required internally in zimg, but I mean as in output format being not input format) [13:21:48 CEST] <JEEB> you can set output subsampling at least [13:22:49 CEST] <JEEB> Mavrik: and some benchmarks from the author http://forum.doom9.org/showpost.php?p=1744072&postcount=33 [13:23:08 CEST] <JEEB> and yes, it seems like the guy likes his bullshit ;) [13:23:19 CEST] <JEEB> "Behind the scenes, "z" has been thoroughly rearchitected to be scalable from the living room to the datacenter." [13:23:32 CEST] <Mavrik> For start I'd like to know what the numbers on Y axis are :P [13:23:42 CEST] <JEEB> fps [13:23:48 CEST] <Mavrik> Ah. [13:23:55 CEST] Action: Mavrik interpreted that as ms per frame. [13:23:58 CEST] <Mavrik> No idea why. [13:24:09 CEST] <JEEB> I will guess the X axis is threads [13:24:23 CEST] <Mavrik> That actually looks rather good, but we kinda only do PAL stuff :/ [13:25:01 CEST] <JEEB> I'm pretty sure this supports all of the colorspaces you have ;) [13:25:42 CEST] <JEEB> looking at the list of zimg_{matrix,transfer,primaries,range} variables :) [13:26:04 CEST] <Mavrik> That's what I get for not clicking the link :P [13:28:32 CEST] <JEEB> but yeah, the avfilter filter is very young and was literally pushed when I was asking the (filter) author regarding the latest version of the patch for testing :D [13:28:46 CEST] <JEEB> seems to work, though [13:28:55 CEST] <JEEB> made some simple tests, nothing too fancy yet [13:44:53 CEST] Action: Jan- doesn't get this whole filter thing [13:44:57 CEST] Action: Jan- is not an experienced ffmpeg user [13:57:55 CEST] <durandal_1707> JEEB: use format filter after zscale to change pixel format [13:58:38 CEST] <JEEB> ah [13:58:44 CEST] <JEEB> so that's where it gets the output pixfmt [13:59:12 CEST] <JEEB> I always thought it converts [14:01:59 CEST] <durandal_1707> it must be immediately after zscale otherwise sws is used [14:02:05 CEST] <JEEB> yeah [14:10:44 CEST] <Jan-> I assume there's some way to turn something to 10 bit RGB, then scale it down [14:10:47 CEST] <Jan-> but I have no idea how [14:11:37 CEST] <JEEB> with a good scaler you only have to care about the input and output format and the size of both [14:12:05 CEST] <Jan-> I have no idea. [14:12:08 CEST] <JEEB> it should do internal filtering in a higher bit depth when required and only do YCbCr<->RGB conversions when absolutely required [14:12:22 CEST] <Jan-> theoretically I agree but this is open sores we're talking about :) [14:12:49 CEST] <JEEB> well, I recommend you take a look at zimg and the zscale filter [14:13:08 CEST] <Jan-> is there a decent guide on filtering basics anywhere? [14:13:59 CEST] <JEEB> you should just look for examples in the docs, it's not really that hard. esp. when you just want to do scaling/colorspace conversion [14:14:26 CEST] <JEEB> -vf 'zscale=w=1024:h=576' is what I used to test the zscale filter a couple of days ago [14:14:48 CEST] <JEEB> it is comma-delimited if I recall correctly [14:14:52 CEST] <Jan-> how does that differ from just -s [14:15:14 CEST] <JEEB> -s is an internal shoot-off to swscale and can do almost everything to your cat [14:15:31 CEST] <JEEB> basically currently I think it uses the normal scale filter with very similar parameters [14:15:32 CEST] <Jan-> you leave my cat out of this! [14:15:37 CEST] Action: Jan- gives izzy a tickle between the ears [14:16:45 CEST] <JEEB> so I guess if I wanted my output to be 10bit YCbCr with the zscale filter it'd be -vf 'zscale=w=1024:h=576,format=yuv420p10' [14:16:55 CEST] <JEEB> *10bit 4:2:0 YCbCr [14:17:20 CEST] <JEEB> it's two filters but it seems like the latter sets the output format for the previous [14:17:50 CEST] <JEEB> if the zscale is not there to be able to do the conversion, it would automagically put the swscale scaler there [14:18:21 CEST] <JEEB> so I guess it's a marker more than a filter? "at this point I want the video to be of this format" [14:19:20 CEST] <durandal_1707> yes [14:22:17 CEST] <Jan-> um, er [14:22:38 CEST] <Jan-> so if I have a uhd video in 8 bit 420 and I want an HD video in 10 bit 422 or even better 444...? [14:23:01 CEST] <JEEB> -vf 'zscale=w=1024:h=576,format=yuv444p10' [14:23:10 CEST] <Jan-> well, 1920x1080 ideally :) [14:23:16 CEST] <JEEB> switch the numbers then :) [14:23:39 CEST] <JEEB> and of course you will have to actually have a very recent ffmpeg built with the zimg library [14:23:52 CEST] <Jan-> ohdear. [14:24:05 CEST] Action: Jan- copies JEEB's suggestion carefully to notes.txt [14:24:53 CEST] <Jan-> if I then have it output that to prores will I get 10 bit prores? [14:25:25 CEST] <JEEB> I think prores was always 10bit? but yes [14:25:56 CEST] Action: JEEB builds himself a new FFmpeg with zimg for testing on his server [14:27:02 CEST] <furq> has he really called this library zlib [14:27:07 CEST] <JEEB> z.lib [14:27:10 CEST] <JEEB> but yes [14:27:17 CEST] <furq> that's some confidence [14:27:18 CEST] <JEEB> also the header is called zimg I think [14:28:51 CEST] <JEEB> and the library is called libzimg.{a,so} as well [14:29:13 CEST] <JEEB> so I guess he just named it z.lib but actually didn't go full troll mode regarding the library/header file names [14:30:50 CEST] <Jan-> arrrgh [14:30:58 CEST] <furq> http://abload.de/img/desktopajjie.png [14:31:05 CEST] <furq> i saw that and got really confused for a second [14:31:48 CEST] <JEEB> it doesn't help that he didn't name his axises [14:32:14 CEST] <furq> 75 scales per desktop [14:32:39 CEST] <Jan-> I think the open source community needs to be clearer on who's a user and who's a developer [14:32:42 CEST] <Jan-> nobody should have to do this stuff :/ [14:33:02 CEST] <furq> what stuff [14:33:28 CEST] <Jan-> know about headers :/ [14:33:40 CEST] <JEEB> uhh, as a user you wouldn't care [14:33:52 CEST] <Jan-> you would if you wanted any help on say a mailing list [14:33:58 CEST] <Jan-> "we only support current git head" [14:34:52 CEST] <JEEB> yes, there is no LTS. primarily bugs are to be tested on the latest code and if they still happen they get fixed and possibly backported to some release(s) that have already been made [14:35:50 CEST] <JEEB> if it's not broken in the latest code then the search for what fixed it begins, and if it can be considered just a bug fix which is something that can be backported to older rleeases [14:35:51 CEST] <Jan-> teehee open sores authors fix bugs? [14:35:57 CEST] <JEEB> har har har, yes [14:36:54 CEST] <JEEB> most systems (windows, 32bit and 64bit linux) seem to have automated git HEAD binaries available by third parties [14:37:08 CEST] <JEEB> so testing with one shouldn't be too hard [14:37:10 CEST] <Jan-> there's a reason we're still using one from 2013. It works. [14:37:20 CEST] <JEEB> sure [14:37:32 CEST] <furq> that's the same reason why i'm using 2.8.1 [14:37:40 CEST] <Jan-> if it ain't broke etc [14:37:58 CEST] <JEEB> but if you get a bug, you might want to reproduce it in the latest code, and see if it's still broken [14:38:04 CEST] <JEEB> no need to actually, you know, switch your production [14:38:05 CEST] <JEEB> :D [14:38:18 CEST] <Jan-> and if it is still broken? [14:38:31 CEST] <furq> then you're already running git head so you can report it on the ml [14:38:35 CEST] <JEEB> then you make a bug report on the trac with a way to replicate it [14:39:13 CEST] <JEEB> it would be best if there could be a sample attached (and there is a private FTP for private samples) [14:39:21 CEST] <Jan-> trac? [14:39:26 CEST] <JEEB> trac.ffmpeg.org [14:39:29 CEST] <JEEB> the issue tracker [14:39:42 CEST] <Jan-> usually I'd expect there to be a support(a)ffmpeg.org but hey. [14:39:56 CEST] <JEEB> if you were actually paying for support there might be [14:40:13 CEST] <Jan-> I find it easier to assume there isn't any support and you can get what you can get. [14:40:48 CEST] <durandal_1707> you can ask for paid support [14:41:24 CEST] <Venti^> for most software, you are lucky if the company provides a forum for the users to support them selves [14:41:45 CEST] <Jan-> there isn't even that for ffmpeg [14:41:48 CEST] <JEEB> uhh [14:41:59 CEST] <JEEB> there's the users mailing list for random user stuff [14:42:06 CEST] <JEEB> and then there's trac for issues [14:42:19 CEST] <furq> and then there's this irc channel for complaining about them both [14:42:25 CEST] <Jan-> from what I've seen of the mailing list, the "user" part of it is mainly about coding, and I haven't even dared look at the "developer" part. [14:42:42 CEST] <JEEB> it might have API users there, but it's a general users' mailing list :P [14:42:42 CEST] <Jan-> I mean it's fine in its way but it isn't very helpful for people who aren't coders [14:42:54 CEST] <JEEB> the developer part is strictly for internals development [14:43:20 CEST] <furq> is it really that off-putting that people are asking questions about issues that you don't have [14:43:20 CEST] <c_14> Most of the mails on ffmpeg-user aren't about coding. [14:43:45 CEST] <JEEB> but seriously, I don't find it hard to grasp: users mailing list for users (together with this IRC channel), and trac for actual bugs/issues [14:44:05 CEST] <Jan-> usually when you post an issue there you get told to "use git head" so you spend a day trying to set up a cygwin build environment, verify the fault still exists, get told to "build with debug symbols" (?!) and use "valgrind" (!?) or some other analysis tool [14:44:25 CEST] <Jan-> basically they just don't want to do support. Which again is fine, but I wish they'd just say so. [14:44:39 CEST] <JEEB> did you provide any way for a developer to test the issue? [14:44:48 CEST] <JEEB> I mean, developers if given a simple way to test can test it as well [14:45:06 CEST] <JEEB> they will require you to do it only if you cannot produce out any way of testing it [14:45:27 CEST] <JEEB> (or if they are lazy, but most of the cases I've seen revolve around there being no simple way to test it) [14:45:53 CEST] <JEEB> I mean, some devs have even signed NDAs with places in case the sample is not something to be shared with other eyes [14:46:03 CEST] <Jan-> that's mainly the problem we have [14:46:10 CEST] <Jan-> but usually you can make a test file that's just color bars or something [14:46:16 CEST] <JEEB> yes [14:46:46 CEST] <Jan-> and they go "Upload it to ftp://wherever.org" and you upload it and it vanishes. [14:47:00 CEST] <Jan-> Or you get partway through and it says "too big!" because everyone who works on ffmpeg is used to 360p youtube videos. [14:47:59 CEST] <JEEB> then you complain about that, and when possible make sure that your test case is as small as possible for the issue to happen (like, if the issue doesn't need hours of content to happen you can usually cut it to a few dozen megabytes) [14:48:00 CEST] <Jan-> they don't make it very easy, is all I'm saying. In fact they seem to be deliberately making it really hard. [14:48:55 CEST] <JEEB> I have no idea what kind of issues you've been running into with the trac :P and I know people like cehoyos aren't the best in all cases (but he does like check every goddamn issue there is, which as such is kind of commendable) [14:49:19 CEST] <Jan-> he's a complete dick [14:49:23 CEST] <JEEB> but in general, as long as it gets to the point where there's a sample available somewhere, it should generally get chugging [14:49:28 CEST] <Jan-> I've been assuming it's some sort of language problem [14:49:36 CEST] <Jan-> I think he's austrian [14:49:45 CEST] <durandal_1707> Jan-: what bugs have you encountered? [14:50:26 CEST] <Jan-> mainly improper handling of color conversions 601 to 709 or srgb to 709 luma levels, even when you specify it properly (not that it is easy to work out what it is even trying to do) [14:50:34 CEST] <JEEB> ah [14:50:36 CEST] <JEEB> swscale [14:50:51 CEST] <JEEB> you should really test out zscale then :D [14:51:00 CEST] <Jan-> I don't think there are many (any?) real video engineers on the coding team. And they really won't listen to anyone else, so.. [14:51:47 CEST] <durandal_1707> we have video devs [14:52:17 CEST] <JEEB> but yeah, swscale is a monstrocity that in the worst case can do a lot of things wrong [14:52:30 CEST] <durandal_1707> and I listen others [14:52:34 CEST] <JEEB> in many cases it does things more or less right and is very quick [14:52:53 CEST] <JEEB> but then you can easily hit cases where only the quick part applies [14:53:41 CEST] <Jan-> this is what you get when you get software guys with no management. [14:53:47 CEST] <durandal_1707> some stuff in swscale are simply missing [14:54:12 CEST] <Jan-> "Hey it works really fast and it's sort of roughly vaguely approximately right, that'll do" :D [14:54:24 CEST] <JEEB> Jan-: also remember swscale is something developed over 10 years ago [14:54:31 CEST] <durandal_1707> swscale is old [14:54:43 CEST] <JEEB> speed was a *thing* in the early 2000s with video processing [14:54:53 CEST] <Jan-> Then it's a lot younger than the international telecommunications union's recommendation bt.709 :) [14:54:55 CEST] <JEEB> nobody was really thinking of colorimetry or higher bit depths [14:55:18 CEST] <JEEB> sure [14:55:28 CEST] <JEEB> also not a lot of people were thinking of conversions between things ;) [14:55:37 CEST] <JEEB> I mean from one colorimetry to another [14:55:50 CEST] <Jan-> We noticed. [14:56:19 CEST] <JEEB> that kind of stuff only caught on like... five+ years ago, first with avisynth filters and then vapoursynth filters [14:56:36 CEST] <JEEB> we finally got enough of the CPU power, and started looking into correct solutions [14:57:17 CEST] <Jan-> well that's sort of the issue. [14:57:25 CEST] <Jan-> it actually caught on a lot longer ago than that. [14:57:31 CEST] <Jan-> it's just that nobody on the ffmpeg team noticed. [14:57:40 CEST] <JEEB> not limited to ffmpeg in any way [14:57:57 CEST] <Jan-> we still can't make mp4 videos where black is actually black not gray. [14:58:59 CEST] <ChocolateArmpits> what? [14:59:01 CEST] <JEEB> the only reason why it was less pronounced in avisynth world was that everyone was doing every step pretty much manually. you had no way of signaling the metadata through, so... [14:59:18 CEST] <JEEB> you just knew that input was this, then you did filter, that filter etc [15:00:03 CEST] <JEEB> but only like around 2010 or so? you started getting avisynth filters with functionality like internal filtering done in a higher bit depth to make it more accurate etc [15:00:13 CEST] <durandal_1707> Jan-: with h264? [15:00:50 CEST] <Jan-> uhhuh [15:01:03 CEST] <Jan-> hollywood trailers (encoded in mainconcept) on youtube have black blacks [15:01:07 CEST] <Jan-> ffmpeg ones have grey. [15:01:22 CEST] <Jan-> because swscale STILL doesn't understand studio luma ranges. [15:01:53 CEST] <ChocolateArmpits> I don't see how's that possible [15:01:56 CEST] <JEEB> welp, wanted to try out zscale BT.2020->BT.709 and then remembered that my sample was HEVC [15:02:12 CEST] <durandal_1707> hmm, I think that might get fixed [15:03:26 CEST] <durandal_1707> if source is properly marked as full or limited range zscale should do right job [15:03:28 CEST] <ChocolateArmpits> JEEB: Does the colorspace conversion there include any rendering intents ? [15:04:00 CEST] <JEEB> Jan-: that's why often people used avisynth or vapoursynth to do the actual colorspace conversions before that and just pushed the already converted stuff into ffmpeg or so :) [15:04:33 CEST] <JEEB> ChocolateArmpits: ./ffmpeg -i ~/samples/Japanese_Rugby_Game-4K_Channel.ts -vf 'zscale=w=1280:h=- [15:04:36 CEST] <JEEB> 2:p=709,format=yuv420p' -c:v libx264 -crf 21 -c:a copy bt2020_to_bt709.mp4 [15:04:56 CEST] <JEEB> or wait, I should have set the other ones too [15:04:56 CEST] <JEEB> shit [15:05:00 CEST] <JEEB> transfer and matrix [15:05:18 CEST] <Jan-> ffmpeg -i -vf 'rumpelstiltskin monkey caboose' [15:05:35 CEST] <Jan-> yes yes very obvious :) [15:06:10 CEST] <JEEB> at least the options are at least somewhat well documented [15:06:13 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#Options-72 [15:07:23 CEST] <ChocolateArmpits> JEEB: By "transfer characteristics" it means the gamma transform? [15:07:27 CEST] <Jan-> The filter accepts the following options: rumpelstiltskin monkey caboose underside intrinsic blancmange blancmange furtive. [15:07:39 CEST] <Jan-> now implement HDR :) [15:07:59 CEST] <JEEB> yes, and "rumpelstiltskin" is "Set the dither type." f.ex. [15:08:18 CEST] <JEEB> HDR is a marketing term, you generally mean some colorspace with it [15:08:28 CEST] <Jan-> does it do 3D lookup tables yet? I remember it being talked about, but it's not like there's a changelog [15:08:33 CEST] <ChocolateArmpits> b-bbut the 4000 nits display [15:08:40 CEST] <Jan-> ChocolateArmpits: it's the future. [15:08:56 CEST] <JEEB> basically even just having content as BT.2020 right now is "HDR" as far as the blu-ray consortium is concerned [15:09:03 CEST] <Jan-> but it's OK, you can repurpose it as a tanning bed if it isn't the future after all. [15:09:19 CEST] <JEEB> as it is a wider space than BT.709 [15:09:47 CEST] <Jan-> if you guys were any good, you'd use the open jpeg2000 library and implement xyz color, and have it be able to make DCPs :D [15:10:01 CEST] <durandal_1707> Jan-: lut3d filter, but currently without high bitdepth support [15:10:34 CEST] <Jan-> *facepalm* whynot [15:11:27 CEST] <Jan-> by the way the documentation is wrong [15:11:33 CEST] <JEEB> Jan-: I think when I mentioned digital cinema XYZ support he said it wasn't possible as it wasn't specified well enough or whatever. there was just some "semi-standard" that is what most such content seems to use or whatever. he said it shouldn't be too hard [15:11:34 CEST] <Jan-> or at least incomplete [15:11:48 CEST] <Jan-> smmmrrrnnkkk not specified well enough that's hilarious [15:11:58 CEST] <JEEB> XYZ is specified well enough of course [15:12:02 CEST] <JEEB> let me find the logs [15:12:09 CEST] <Jan-> for a piece of software that still doesn't know about studio swing luma [15:12:10 CEST] <Jan-> snrrrrrk! [15:12:27 CEST] <JEEB> zimg is a separate library [15:12:34 CEST] <JEEB> which is now used in the zscale filter in ffmpeg [15:13:09 CEST] <JEEB> ok... let's see how this went [15:13:19 CEST] <Jan-> that remark comes under the heading of "I don't care about your internal engineering" :/ [15:14:12 CEST] <JEEB> welp, I had forgotten that the frame count in ffmpeg isn't the amount of frames already encoded... [15:14:26 CEST] <JEEB> stopped it at ~40 with HEVC input and x264 output and I got a couple of fabulous frames [15:14:54 CEST] <JEEB> just not too fancy of encoding this whole thing on this 8core atom box [15:14:55 CEST] <JEEB> lol [15:15:11 CEST] <Jan-> there are very fast gpu based hevc encoders now [15:15:14 CEST] <Jan-> may be hard to catch those [15:15:33 CEST] <JEEB> yeah, but those are meant for completely different use cases, just like hw AVC encoders [15:15:49 CEST] <furq> JEEB: is that one of those avoton NAS boards [15:15:55 CEST] <JEEB> furq: ye [15:16:09 CEST] <furq> neat [15:16:22 CEST] <JEEB> a dediserver provider had it for a good price per month as a cheap ECC'd server box [15:16:30 CEST] <JEEB> with an SSD [15:16:36 CEST] <JEEB> so I grabbed it for random usage [15:16:46 CEST] <Jan-> mmmm [15:16:48 CEST] <Jan-> coooores :) [15:17:29 CEST] <JEEB> yeah, if I was either more wealthy or was actually buying/renting this for work then I'd just get a much more expensive xeon thing [15:17:42 CEST] <JEEB> might buy a xeon box for homeserver use next year with a nice amount of HDDs [15:17:49 CEST] <Jan-> happily the sort of computers that are good at video editing also tend to be quite good at encoding. [15:19:27 CEST] <JEEB> but yeah, the only reason why I had asked the zimg developer regarding digital cinema JPEG2000 content was because I was thinking of using zimg to convert the tears of steel 4K master into 16bit YCbCr for encoding [15:19:35 CEST] <JEEB> because JPEG2000 decoding is slow as molasses [15:19:42 CEST] <Jan-> tell barco that [15:19:45 CEST] <JEEB> so it's faster and simpler if I just make a lossless intermediated [15:20:02 CEST] <JEEB> *intermediate [15:20:44 CEST] <Jan-> "Intel(R) Xeon(TM) CPU E5-2630 @ 2.60GHz 2.60GHz" [15:20:48 CEST] <Jan-> I don't know if that is good [15:20:50 CEST] <Jan-> it was certainly expensive [15:21:14 CEST] <JEEB> which version? [15:21:22 CEST] <JEEB> there's like three versions of that ID from intel now [15:21:23 CEST] <JEEB> :D [15:21:29 CEST] <Jan-> I uhoh. I'm copypastaring from properties on "my computer£" [15:21:57 CEST] <JEEB> but the latest from late 2014 is pretty good. 20MB of cache, 8 cores [15:22:31 CEST] <JEEB> I hope there will be more broadwell/sky lake server stuff soon'ish [15:22:41 CEST] <JEEB> there's already the xeon d series for broadwell [15:23:21 CEST] <Jan-> I have no idea how to find out how many cpu cores this computer has. [15:23:33 CEST] <JEEB> on windows there's cpu-z [15:23:44 CEST] <JEEB> that is what I usually launch up to see what's in the box [15:23:48 CEST] <JEEB> if I don't already know [15:24:18 CEST] <BtbN> Well, technicaly there are no GPU based encoders. [15:24:24 CEST] <BtbN> They just happen to be on graphics cards. [15:24:29 CEST] <JEEB> yeah [15:24:37 CEST] <JEEB> thankfully they gave up on the GPGPU based stuff [15:24:43 CEST] <Jan-> in device manager under "processors" it says " "Intel(R) Xeon(TM) CPU E5-2630 @ 2.60GHz" 24 times. [15:25:09 CEST] <JEEB> Jan-: http://www.cpuid.com/downloads/cpu-z/cpu-z_1.74-en.zip [15:25:12 CEST] <JEEB> I recommend this :) [15:25:18 CEST] <Jan-> two six core chips with hyper threading? [15:25:31 CEST] <furq> if it's dual-cpu then yeah [15:25:31 CEST] <JEEB> yeah, could be [15:25:37 CEST] <Jan-> hur hur [15:25:39 CEST] <Jan-> 24 cores [15:25:40 CEST] Action: Jan- wins [15:25:44 CEST] <furq> 12 cores [15:25:49 CEST] <furq> HT cores don't count [15:26:18 CEST] <JEEB> HT does help with the latest CPU types nicely, but yeah - you should compare by actual core count/speed/architecture [15:26:20 CEST] <Jan-> the scheduler thinks they do. [15:27:54 CEST] <JEEB> also it seems like my issue with not enough pictures getting muxed was due to one of the things I find "fun" explaining to users (bit stream filters). at least I think that's being improved now so maybe in the future the user shouldn't care about how their streams are encapsulated and if the encapsulation has to be changed between two containers [15:28:41 CEST] <JEEB> f.ex. transport streams have usually AAC streams in one type of packets, and when muxing into mp4 a different scheme is used 8) [15:30:03 CEST] Action: Jan- doesn't care or want to have to care [15:30:27 CEST] <JEEB> yes, in theory that should all be automatized. [15:31:24 CEST] <Jan-> I just wrote a riff file parser. That was about my limit. [15:32:25 CEST] <JEEB> also I guess I should have enabled verbose debugging to see if I got swscale in there somewhere with this filtering... [15:33:01 CEST] <JEEB> durandal_1707: 'zscale=w=1280:h=-2:p=709:t=709:m=709,format=yuv420p' should in theory have no swscale, right? [15:36:10 CEST] <Jan-> p? t? m? [15:38:06 CEST] <JEEB> (output) primaries, transfer, matrix [15:38:17 CEST] <JEEB> I think they have a longer name too if you like longer options :) [15:38:46 CEST] <JEEB> I'm currently comparing the result with mpv's video rendering which should be one of the few things handling BT.2020 rendering correctly [15:41:11 CEST] <JEEB> oh of course [15:41:29 CEST] <JEEB> seems like the output didn't get tagged with those primaries, transfer, matrix... [15:41:40 CEST] <JEEB> at least ffmpeg -v debug -i file.mp4 doesn't tell [15:41:43 CEST] <Jan-> Er, [15:41:45 CEST] <Jan-> okay [15:42:00 CEST] <Jan-> surely you need to specify input and output primaries and gamma function [15:42:33 CEST] <JEEB> at least with this input file the input information should be in the bit stream [15:42:49 CEST] Action: Jan- sounds error klaxon [15:42:55 CEST] <Jan-> *NRRRK* [15:42:59 CEST] <Jan-> must allow user to override :/ [15:43:09 CEST] <Jan-> also where do you specify the luma ranges [15:43:18 CEST] <JEEB> yuv420p10le(tv, bt2020nc/bt2020/bt2020-10) [15:43:25 CEST] <JEEB> yes, there are overrides [15:43:28 CEST] <JEEB> just not used by me [15:43:34 CEST] <JEEB> because the input data was correct [15:43:37 CEST] <Jan-> usually best to be very specific [15:44:05 CEST] <JEEB> luma range by default is "same as input" except maybe with RGB input/output? [15:44:11 CEST] <JEEB> not sure, didn't check how the zscale filter handles it [15:44:31 CEST] <Jan-> it's very very very bad to make any sort of assumptions with that stuff [15:44:39 CEST] <Jan-> without printing out a big warning in 100 point red letters [15:45:21 CEST] <Jan-> from what we've seen ffmpeg outputs in studio swing no matter what if it's yuv input. [15:45:25 CEST] <JEEB> yeah, except for data that is actually written to the input stream. and that "not sure" was regarding cases where one side is RGB and the other isn't [15:45:29 CEST] <Jan-> we have never been able to make it do anything else. [15:45:52 CEST] <JEEB> Jan-: this is not swscale so as long as swscale is not related we're now discussing a whole different thing regarding colorspaces [15:45:55 CEST] <JEEB> and their conversions [15:46:08 CEST] <Jan-> if you can even control that [15:46:25 CEST] <JEEB> before now you couldn't really [15:46:26 CEST] <Jan-> also, are there better scaling options for subsampled chroma now? [15:46:28 CEST] <JEEB> it was up to swscale [15:46:49 CEST] <JEEB> zscale should be up your alley for that, too [15:48:12 CEST] <JEEB> and yes, I agree that things that are not written in the input file shouldn't be assumed upon [15:48:27 CEST] <Jan-> even if they are, they're often wrong [15:48:28 CEST] <JEEB> and there should always be a force-option in case that stuff is wrong [15:48:38 CEST] <JEEB> which is what is the case here f.ex. [15:48:47 CEST] <JEEB> the levers are there [15:48:51 CEST] <Jan-> for the longest time ffmpeg seemed to assume that anything that was less than 1280 pixels wide was in rec 601 color. [15:49:01 CEST] <Jan-> which was horribly broken for some dslrs that recorded video in 601, but hd resolution [15:49:05 CEST] <JEEB> yes [15:49:32 CEST] <JEEB> and it would have been broken for Japanese DTV where SD content was also BT.709 (although properly signaled) [15:50:04 CEST] <Jan-> it was properly signaled by canon too [15:50:13 CEST] <Jan-> but ffmpeg went "nono, you don't want THAT, you want THIS..." [15:50:27 CEST] Action: Jan- beats on ffmpeg with a mallet [15:50:29 CEST] <JEEB> I know it painfully well that the signaled information was not properly used, and it probably still isn't [15:50:50 CEST] <Jan-> it's because none of the coders really know what they're doing, and they won't listen to anyone who isn't a coder. [15:50:50 CEST] <JEEB> poked the zimg developer with the sample and stuff regarding the BT.2020->BT.709 thing I did: [15:50:59 CEST] <JEEB> 16:47 < anon32> idk, I'll have to look into it [15:50:59 CEST] <JEEB> 16:47 < JEEB> thanks :) [15:51:00 CEST] <JEEB> 16:47 < anon32> gamut reduction is not support anyway, so nothing will be fixed [15:51:00 CEST] <JEEB> 16:47 < anon32> not supported* [15:51:20 CEST] <Jan-> if at this stage you don't have a way to just plug in xy coords of primaries and a gamma function, your software is Not Finished Yet. [15:51:54 CEST] <JEEB> nobody is saying anything is finished :) [15:52:10 CEST] <Jan-> no, but if you mention it on the mailing list you'll get a buttload of butthurt in response. [15:54:25 CEST] <JEEB> there's this "old" quote by loren [15:54:26 CEST] <JEEB> <pengvado> making an alpha product into final is easy [15:54:26 CEST] <JEEB> <pengvado> the hard part is adding features so that it stays alpha [15:56:03 CEST] <Jan-> I guess to be fair, having written a colorspace converter, if you did implement actually being able to punch in primaries and gamma function, you would probably have to stop calling it ffmpeg and start calling it reallyfrickenslowmpeg [15:56:26 CEST] <Jan-> unless you calculated a really high precision lut on the fly [15:56:28 CEST] <Jan-> that might work [15:59:29 CEST] <durandal_1707> JEEB: so what conversion is not supported? [16:00:13 CEST] <JEEB> well he officially doesn't support gamut reduction, but we're still looking into if it's otherwise done correctly or not [16:01:25 CEST] <Jan-> how can you not support gamut reduction [16:01:25 CEST] <JEEB> also does the -colorspace option *really* only take in integers? [16:01:52 CEST] <JEEB> Jan-: it's called "I haven't tested that yet with large gamut reduction", basically :P [16:02:30 CEST] <Jan-> [r,g,b]out = ([r,g,b]in * (1-factor)) + (sum([r,g,b]in/3) * factor) [16:02:33 CEST] <Jan-> gamut reduction [16:02:34 CEST] <JEEB> 17:01 < anon32> looks fine to me [16:02:34 CEST] <JEEB> 17:01 < anon32> 709->2020->709 reverses exactly [16:02:35 CEST] <JEEB> 17:01 < anon32> everything else is associated with clipping, so it's as described in the manual [16:03:20 CEST] <Jan-> why would -colorspace take only integers? you might want to say "p3" or "xyz" or "adobergb" [16:03:36 CEST] <Jan-> or "srgb" ffs [16:03:42 CEST] <Jan-> srgb should be really, really common [16:03:57 CEST] <JEEB> it most probably does support string-based arguments but it's just not mentioned in the docs [16:03:59 CEST] <Jan-> in a practical sense it's almost never corrected for because 709 looks okay on srgb displays, but... [16:05:13 CEST] <Jan-> I would take the position that "709" in that context is not a number anyway, it's an abbreviation of the name of a standard. [16:05:24 CEST] <Jan-> thus it is a string [16:05:34 CEST] <Jan-> it's not like changing it to 710 is valid [16:07:14 CEST] <Jan-> also clipping gamuts is worth testing because good converters will implement a soft rolloff (optionally) to minimise ugliness. [16:18:03 CEST] <JEEB> I think I might have my first patch idea for the zscale filter [16:18:10 CEST] <JEEB> [Parsed_zscale_0 @ 0x3423d00] w:3840 h:2160 fmt:yuv420p10le sar:1/1 -> w:1280 h:720 fmt:yuv420p sar:1/1 [16:18:19 CEST] <JEEB> guess what this debug output lacks ;) [16:18:57 CEST] <Jan-> primaries and gamma function? [16:19:11 CEST] <Jan-> of course it becomes even more entertaining when you're considering yuv [16:19:13 CEST] <JEEB> well yes, colorimetry information on the whole :) [16:19:29 CEST] <Jan-> also luma range [16:19:35 CEST] <JEEB> ye [16:19:37 CEST] <Jan-> which ffmpeg still likes to pretend doesn't exist and isn't a thing [16:19:54 CEST] <JEEB> actually everything but swscale seems to handle it relatively well now [16:19:55 CEST] <Jan-> and bear in mind, the chroma ranges for yuv are different for the y range. [16:20:00 CEST] <JEEB> yes [16:20:31 CEST] <JEEB> the issue of course is that until now swscale was the only thing doing colorspace conversions and scaling [16:20:55 CEST] <Jan-> it's not THAT hard. [16:21:01 CEST] <Jan-> there's a number of bases to cover with a conversion tool [16:21:05 CEST] <Jan-> but it's just math and it's easy to test [16:21:21 CEST] <JEEB> anyways, at this point I would be more interested in having to make sure that zscale does it right [16:21:26 CEST] <JEEB> rather than trying to fix swscale [16:21:32 CEST] <Jan-> I guess... have they made it hard for themselves by not breaking everything down into floats internally? [16:22:05 CEST] <Jan-> if I had to design somethin like this I'd probably fire it all into linear 32 bit float and go from there [16:22:19 CEST] <JEEB> that's what people have done during the last five years or so [16:22:23 CEST] <Jan-> this is what aces is for but I bet you guys have never heard of it. [16:23:05 CEST] <JEEB> basically swscale is a massive lump of issues that seems to kind of work well enough as long as you're not poking it the wrong way. which is why nobody really likes it [16:23:28 CEST] <Jan-> Personally I think we should probably set it on fire. [16:24:13 CEST] <JEEB> that might happen if zscale covers all the ground well enough [16:26:29 CEST] <Jan-> I suppose if they made it work in linear float internally you wouldn't be able to do lossless conversions. [16:27:00 CEST] <Jan-> But then if it is supposed to be lossless you wouldn't be scaling. [17:01:24 CEST] <waressearcher2> if I amplify level of audio by increasing or decreasing dBm do I loose quality ? say I increased it by 5dBm and then decided I don't want it so I decreased it by -5dBm, was there loss in data or quality after these two changes ? [17:02:33 CEST] <ChocolateArmpits> waressearcher2: normally depends on bit depth and if the resulting audio has clipping, if the clipping happens after +5db increase you will lose quality [17:08:38 CEST] <waressearcher2> ChocolateArmpits: what if its a wav file ? and no bit clipping [17:08:59 CEST] <waressearcher2> "bit depth" doesn't matter for wav right ? [17:09:08 CEST] <ChocolateArmpits> waressearcher2: To be more specific about the bit depth, say if you have 24bit audio but the audio filter performs only at 16bit precission, after the very first operation you will lose audio quality [17:09:26 CEST] <ChocolateArmpits> It's usually a one-way relation between the filter and audio, where filter plays the major role [17:10:09 CEST] <ChocolateArmpits> wav can store pcm at various bit depths, most common is 16bits [17:11:03 CEST] <ChocolateArmpits> Unless there's clipping introduced I don't think even a 16bit precision filter will do any real harm to the audio [17:11:58 CEST] <ChocolateArmpits> provided your input is no more than 16 bits [17:13:22 CEST] <waressearcher2> can bit clipping happen if I not increase but decrease dBm very much ? [17:15:34 CEST] <ChocolateArmpits> Not only clipping but the dynamic range will also suffer [17:17:41 CEST] <ChocolateArmpits> If it's processed digitally and then transmitted over cables noise can be introduced [17:18:35 CEST] <ChocolateArmpits> Which one is more destructive (increasing or decreasing) depends really on the loudness of the content [18:01:17 CEST] <waressearcher2> is dynamic range compression destroying music ? [18:03:24 CEST] <ChocolateArmpits> Conceptually probably yes, as the artists's or audio engineer's vision gets warped [18:03:49 CEST] <ChocolateArmpits> It's all very relative [18:04:58 CEST] <ChocolateArmpits> Orchestra will suffer more from audio compression than say pop music [18:05:18 CEST] <ChocolateArmpits> Former usually utilize a much broader range of volumes [18:05:30 CEST] <ChocolateArmpits> or should I loudness [18:05:32 CEST] <ChocolateArmpits> say* [19:29:34 CEST] <RobotsOnDrugs> yes, it very much depends on the genre [19:30:46 CEST] <RobotsOnDrugs> in some genres, loudness and compression are very much part of the music, and in others, it's meant to be mostly quiet [19:31:54 CEST] <RobotsOnDrugs> of course, compression is a necessary evil in many environments where one cannot simply focus solely on the music [19:35:56 CEST] <zhanshan> hi [19:36:07 CEST] <zhanshan> I got problems trying to record my screen with audio [19:36:13 CEST] <zhanshan> running jack using cadence [19:38:31 CEST] <zhanshan> I always get "[alsa @ x] cannot open audio device hw:0 (Device or resource busy)" [19:56:42 CEST] <Bhaskar> How to merge mp3 and image to generate video? I tried "ffmpeg -i 1.png -i 1.mp3 output.mp4" but video generated is having error [19:56:48 CEST] <Bhaskar> what is correct way to do it? [19:57:04 CEST] <Bhaskar> i want to generate video in mp4 forat [19:57:07 CEST] <Bhaskar> format [20:12:59 CEST] <grublet> Bhaskar: i think you need to use -loop to let ffmpeg know to repeat the image, i dont know the specifics of the loop command though maybe someone else can help [20:16:44 CEST] <Bhaskar> i tried using loop as well but didnt work :( Might be i am missing sumthing [21:14:12 CEST] <lauren> hey folks, anyone used the nvenc encoder? [21:15:56 CEST] <lauren> I'm trying to encode jpegs to single-frame h264 files as fast as possible [21:16:22 CEST] <lauren> (because h264 is a way better compressor for single frames than jpeg is, even though it's designed for video) [21:21:39 CEST] <DHE> x264 produces better images, but nvenc is crazy fast [21:23:04 CEST] <lauren> the command I used was: ffmpeg -i -y -vf "crop=1280:720:0:0" -pix_fmt yuv420p -c:v nvenc_h264 -qmax 22 -qmin 22 -bsf:v h264_mp4toannexb -f mpegts "$2" [21:23:11 CEST] <lauren> unfortunately, it wasn't faster [21:23:27 CEST] <lauren> oops, I deleted one of the arguments while I was editing the command for understandability [21:23:52 CEST] <lauren> anyway, I gave it a jpeg on the input and .ts file on the output [21:24:10 CEST] <lauren> I tried again with mp4 to mp4, and that *was* fast [21:24:18 CEST] <DHE> you don't need the bsf for transcoding. just for copying [21:24:29 CEST] <lauren> oh, ok [21:26:58 CEST] <furq> is there some reason you're using h264 over webp [21:29:40 CEST] <lauren> yes, it can also be decoded quickly on nvidia cards [21:29:51 CEST] <lauren> and ultimately this is just an intermediate format that has to be fast [22:16:59 CEST] <cs_> hi, i'm trying to batch convert .flac files to .ogg - what command should i use? [22:29:17 CEST] <IntelRNG> cs_: I'd just script it with oggenc if you have it around. [22:29:55 CEST] <IntelRNG> Use flac -d to decode it and oggenc to encode it. Asuming you have them. [22:37:31 CEST] <cs_> sorry, but i'm a bit of a linux noob. i hate to ask this, but can you give me the full command? [22:48:19 CEST] <tp__> find -name "*.flac" -exec ffmpeg -i {} -acodec libvorbis {}.ogg \; [22:52:44 CEST] <cs_> thanks tp__ [22:53:02 CEST] <cs_> but i get "Unknown encoder 'libvorbis' [22:53:02 CEST] <cs_> " [22:53:07 CEST] <cs_> even though i have it installed [22:53:40 CEST] <tp__> ffmpeg should be compiled with libvorbis support [22:55:30 CEST] <tp__> you could try "-codec:a vorbis -strict experimental" as arguments instead, but lower quality encodes [23:03:30 CEST] <cs_> okay thanks tp__ ill try fiddling around some more [23:09:28 CEST] <TD-Linux> ehhh don't use the built in vorbis encoder [23:10:16 CEST] <TD-Linux> ah he left [23:22:52 CEST] <rsully> I'm converting a wmv -> mp4, how can I deinterlace it? [23:24:18 CEST] <relaxed> rsully: yadif filter [23:26:18 CEST] <rsully> relaxed what params? 0,-1,0 is an example in the wiki, and im looking at the page that explains them but I have no idea what I would want [23:29:51 CEST] <JEEB> in general the defaults should work [23:29:56 CEST] <JEEB> as in, no params [23:30:14 CEST] <JEEB> the parameters are documented @ https://www.ffmpeg.org/ffmpeg-all.html#yadif-1 [23:30:44 CEST] <JEEB> and yes, they are named so a command line can be less black box'd than that example [23:31:36 CEST] <JEEB> the last number is the only non-default value from 0,-1,0. and it just means that will deinterlace all pictures even if they would be signaled as non-interlaced [23:31:56 CEST] <JEEB> you should only use that when the source file is incorrectly created [23:32:33 CEST] <rsully> ok I'll try without the params [23:34:16 CEST] <relaxed> create some small samples with -t 60 and see what works best [00:00:00 CEST] --- Sun Oct 25 2015

1 0

ffmpeg-devel.log.20151023
by burek 24 Oct '15

24 Oct '15

[00:00:17 CEST] <nevcairiel> its fun when people upload samples to place where no developer other than carl can find them =p [00:00:59 CEST] <BBB> crap the ssim one is also broken [00:01:56 CEST] <llogan> "...I know there are people like you who do not understand such things" [00:03:25 CEST] <llogan> trash talkin' [00:06:05 CEST] <nevcairiel> so who do i ask? I suppose michaelni_ would know [00:10:08 CEST] <iive> atomnuker: shouldn't assertion cause program abort? [00:10:34 CEST] <iive> atomnuker: also, if you have fix, why not commit it right away and wait for more bugreports. [00:10:52 CEST] <llogan> nevcairiel: it's a videolan server i think, so maybe on of them if all else fails. [00:11:16 CEST] <nevcairiel> i got it now :) [00:14:50 CEST] <wm4> how? [00:16:01 CEST] <nevcairiel> i was told the secret [00:17:42 CEST] <llogan> who was the fount of knowledge? [00:18:07 CEST] <nevcairiel> beastd and michael both told me at the same time, more or less :p [00:20:23 CEST] <wm4> can I know the secret too? I had it, but apparently it's out of date now [00:21:32 CEST] <nevcairiel> my client is being weird, did you get the url [00:23:13 CEST] <wm4> yes [01:08:10 CEST] <cone-206> ffmpeg 03Ganesh Ajjanagadde 07master:a7c5005d7bec: avdevice/pulse_audio_common: add av_warn_unused_result [01:12:02 CEST] <llogan> kierank: that is the most useless patch i've ever seen [01:12:11 CEST] <kierank> I know [01:12:43 CEST] <nevcairiel> this one r ight here, or which one [01:12:53 CEST] <kierank> the legal one [01:12:53 CEST] <nevcairiel> oh the legal thing [01:14:03 CEST] <Daemon404> "grammer fixes" made me smile. [01:14:31 CEST] <nevcairiel> i saw that, typo'ing in a typo-fix mail is always funny [01:15:11 CEST] <Daemon404> i am probably guilty of this. [01:23:35 CEST] <llogan> oops. forgot the "web/" in my patch [01:26:18 CEST] <llogan> ...not that i don't agree that the logo shenanigans was a bullshit move [01:58:50 CEST] <wm4> llogan: did you remove the image too? [02:04:56 CEST] <llogan> wm4: no, sorry. i forgot it. [02:07:06 CEST] <llogan> doesn't appear to be in the git repo, so i can delete it next time i log into server, but i don't think it would hurt to leave it [02:48:05 CEST] <J_Darnley> I think I finally reached the end of today's internet. Everywhere I go I just see the same things as I did earlier. [02:51:25 CEST] <pross> whats at the end? are there no 'this page is still under construction' [02:55:47 CEST] <J_Darnley> It just loops so that you don't realise you've reached the end and gone back to the begining. [02:56:42 CEST] <J_Darnley> But it has a shuffle so you don't see things in the same order [02:57:13 CEST] <J_Darnley> So the things you overlooked the first time make it seem like new [10:06:25 CEST] <__gb__> nevcairiel mateo` , I think you can work or slightly extend the current hwaccel api to support frame level decode [10:06:34 CEST] <__gb__> we had discussed that in the past iirc (well, 5+ years ago) :) [10:06:45 CEST] <__gb__> start_frame(), end_frame() are not enough? [10:08:38 CEST] <nevcairiel> there is a difference to consider here though, if it just wants the entire bitstream and still decodes that frame immediately, it might work, but if its a full decode API with its own delay and re-order handling and whatnot, the hardware decoder and the avcodec code would not agree on which frame is which and you get all kinds of trouble [10:09:40 CEST] <mateo`> __gb__: the problem is that you can't expect the decoder to return immediately a frame after pushing one into it [10:10:08 CEST] <__gb__> mateo`, no sync api? [10:10:20 CEST] <mateo`> i'm submitting the whole frame bitstream on end_frame but it's not enough [10:11:15 CEST] <__gb__> wm4 or luca had other views iirc to address async apis, but I did not follow that discussion [10:11:54 CEST] <nevcairiel> chaining a full blown decoder through the hwaccel API will likely not work, so a separate decoder in avcodec is best [10:12:13 CEST] <nevcairiel> hwaccels rely on the software decoder still performing re-ordering and all that [10:12:22 CEST] <nevcairiel> if the hwaccel tries to do that itself, its going to be weird [10:14:09 CEST] <BtbN> How would it even happen that a decoder doesn't return a frame imediately? Aren't the frames ordered so there are no references to frames not parsed yet? [10:14:32 CEST] <mateo`> __gb__: there is a sync api, but you can't expect a 1 input - 1 output mapping afaik [10:14:36 CEST] <nevcairiel> it would happen if it tries to do the re-ordering into display order [10:14:45 CEST] <nevcairiel> instead of just being a slice decoder [10:18:34 CEST] <__gb__> btw, what kind of hwaccel is it? you probably can indeed get inspiration from mmal, qsv, vt, etc. [10:20:59 CEST] <mateo`> i've looked at qsv yesterday and i'm about to go this way, ie: creating a separe decoder [10:24:32 CEST] <mateo`> __gb__: the api let you feed a single nal per buffer to the decoder, when the decoder has enough buffer, you can buffer out of it in two distinct ways [10:25:40 CEST] <mateo`> the first one is cpu buffer in the format the decoder has decided (and you have no control over it) and it could be painful to deal with (it's device depend) [10:26:43 CEST] <mateo`> the second one is having the decoder output to a surface from where you can render direct on screen or render to a 2D texture [11:22:35 CEST] <canaar> What is the need to SDL mutex in ffplay? Started reading the code today morning. [11:26:11 CEST] <wm4> canaar: it uses threads [11:26:20 CEST] <wm4> I'm pretty sure there are some race conditions left [11:27:11 CEST] <canaar> Can you summarize in short what kind of race condition? Race amongst multiple threads? [11:29:53 CEST] <wm4> yes [11:29:55 CEST] <wm4> I don't remember [11:30:03 CEST] <wm4> just be very careful with this code [11:30:50 CEST] <canaar> Why, can it damage my hardware? [11:30:58 CEST] <nevcairiel> no, but it can just break [11:31:12 CEST] <wm4> canaar: in theory they could crash or glitch ffplay [11:37:31 CEST] <cone-769> ffmpeg 03Michael Niedermayer 07master:573334da8242: avformat/mov: Autodetect mp3s which need parsing [11:38:42 CEST] <wm4> michaelni: such patches should go through review [11:40:44 CEST] <michaelni> do you see a problem in the code? [11:42:46 CEST] <michaelni> if theres a problem i can revert but i tested this and found no case where it failed [11:43:25 CEST] <nevcairiel> why not enable mp3 parsing all the time instead of relying on some heuristic? would it cause problems? [11:44:00 CEST] <nevcairiel> such heuristic conditions always smell a bit [11:46:43 CEST] <michaelni> there are some files which contain packets which seem to have a framesize different from what their headers indicate, if run through the parser they break [11:47:09 CEST] <michaelni> https://dl.dropboxusercontent.com/u/76042064/packed_maindata.mp3.mp4 <-- this (url found by searching for the filename didnt double check its the right file) [11:50:05 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:ca09eacbced6: avfilter: add shuffleframes filter [12:38:10 CEST] <cone-769> ffmpeg 03Tom Butterworth 07master:a60539bb5e30: avcodec/hap: set bits_per_coded_sample [12:38:55 CEST] <cone-769> ffmpeg 03Ronald S. Bultje 07master:0c7b44a01c15: vf_psnr/ssim: don't crash if stats_file is NULL. [12:44:16 CEST] <wm4> michaelni: does libswresample clamp output values, or can it return out of range values? (if rematrix_maxval is higher than 1) [12:56:43 CEST] <michaelni> values should be clamped to within the representable range, so for float&double values outside -1.0 .. 1.0 are possible as these can be represented [13:00:13 CEST] <wm4> would some clipping be possible? simple clipping, and possibly soft clipping? [13:00:34 CEST] <wm4> (and also, lavfi af_volume should also clip) [13:05:23 CEST] <michaelni> it could certainly be added [13:55:31 CEST] <nevcairiel> wm4: __gb__: I re-posted my hwaccel frame-mt patch with a proper long commit message, if you want to read it again to make sure i didnt write too much crap =p [14:32:37 CEST] <__gb__> nevcairiel, sounds ok to me. probably add a minor note in APIchanges, since this is an indirect change in application programming model? [14:33:02 CEST] <__gb__> and how long before j-b yells at us since vlc is another major player around? :) [14:35:14 CEST] <j-b> 2seconds [14:36:08 CEST] <wm4> __gb__: requiring an APIchanges entry sounds fair [14:44:02 CEST] <cone-769> ffmpeg 03Ganesh Ajjanagadde 07master:8ed79c45b47f: avutil/qsort: use the do while form for AV_QSORT, AV_MSORT [14:48:06 CEST] <cone-769> ffmpeg 03Ganesh Ajjanagadde 07master:e6a93e59adee: configure: add -Wstrict-prototypes when available [14:49:41 CEST] <Daemon404> one day i will correctly remember snprintf's return value [14:49:47 CEST] <Daemon404> today is not that day [14:49:57 CEST] <av500> 42 [14:50:14 CEST] <Daemon404> i always mess up causwe it's like "it's X, except when Y is true, then it is Z" [14:50:29 CEST] <wm4> just blame C for being unnecessarily complex [14:51:16 CEST] Action: av500 never checks that value anyway [14:51:20 CEST] <av500> what can go wrong... [14:51:22 CEST] <Daemon404> i legitimately forgot about the radix/locale problem though [14:51:32 CEST] <Daemon404> i just dont think of !english a lot :X [14:51:39 CEST] <J_Darnley> It use Windows like conventions, the return is a status and a returned value is done through a pointer argument. [14:52:05 CEST] <Daemon404> i personally like languages with multiple return values [14:52:10 CEST] <Daemon404> ret, err = func(...) [14:52:13 CEST] <wm4> I'm still not clear how ffmpeg handles the local issue [14:52:20 CEST] <Daemon404> wm4, probably "it doesnt" [14:52:24 CEST] <J_Darnley> (Try C99 and structs then) [14:52:30 CEST] <wm4> I think there was a hack at least for parsing [14:52:38 CEST] <Daemon404> oic [14:52:59 CEST] <Daemon404> wm4, i am also surprised we use a union to read float values [14:53:05 CEST] <Daemon404> i wouldnt think that is nto very portable [14:53:14 CEST] <Daemon404> and depends on the float impl for that arch [14:53:27 CEST] <wm4> heh, yeah [14:53:34 CEST] <wm4> and all while we have intfloat stuff? [14:53:39 CEST] <wm4> or softfloat [14:53:42 CEST] <wm4> or what it was called [14:53:43 CEST] <Daemon404> the intfloat stuff uses unions [14:53:49 CEST] <Daemon404> softfloat is ... as its name says [14:54:37 CEST] <wbs> intfloat is the right way; whoever says "what about non-ieee" doesn't know what they're talking about. the only case where it'd fail is when the fpu and cpu use a different endianness; some old (very much deprecated and very much not available anywhere) arm fpus did that [14:55:33 CEST] <wbs> (and using unions are important; just doing *(int32_t*)&myfloat can fail if the compiler is aliasing-aware) [14:55:40 CEST] <Daemon404> i know that much [14:55:44 CEST] <Daemon404> aliasing rules are insane [14:56:01 CEST] <Daemon404> i am not 100% informed about why "what about non-ieee" is a red herring though [14:56:07 CEST] <Daemon404> (unless you mean they simply dotn exist in practice) [14:56:44 CEST] <wbs> everything since 1985 has been ieee-754, more or less [14:56:50 CEST] <Daemon404> ok [14:56:51 CEST] <ubitux> note: i'm working on a midly high level async api for ffmpeg, i will try to provide a PoC by the end of next week [14:57:03 CEST] <wbs> worrying about 64 bit 'int' is more real of an issue :P [14:57:06 CEST] <Daemon404> ubitux, i assume it will be optional [14:57:08 CEST] <Daemon404> for sanity [14:57:16 CEST] <ubitux> Daemon404: it's on top of current api [14:57:25 CEST] <Daemon404> that sounds insane :D [14:57:31 CEST] <ubitux> :) [14:57:37 CEST] <Daemon404> wbs, ofc [14:57:37 CEST] <ubitux> it will be optional ofc. [14:57:52 CEST] <Daemon404> ubitux, model it after mmal [14:57:54 CEST] <Daemon404> wm4 will love you [14:58:07 CEST] <ubitux> it's already modeled [14:58:09 CEST] <wm4> mmal is a pretty general async API [14:58:21 CEST] <ubitux> an implementation is already in progress [14:58:23 CEST] <ubitux> i need a few days [14:58:25 CEST] <Daemon404> wm4, ive heard nothing but bad things; perhaps its the impl which is bad [14:58:26 CEST] <wm4> really [14:58:32 CEST] <wm4> ubitux: post us the API changes for review [14:58:42 CEST] <wm4> Daemon404: from who? [14:58:53 CEST] <wbs> wm4: I don't think it's bad; it's pretty much exactly how any such api is [14:59:03 CEST] <wm4> yes, the API is sort of fine [14:59:04 CEST] <wbs> (the same for mediacodec/omx/whatever, just with less boilerplate than omx) [14:59:18 CEST] <wm4> just the integration with lavc is terrible, and the RPI decoder itself can behave terribly too [14:59:24 CEST] <wm4> (you can crash the GPU so easily) [14:59:38 CEST] <wm4> although when it works it does its thing properly [14:59:38 CEST] <Daemon404> wm4, a couple people here + elsewhere [14:59:49 CEST] <Daemon404> maybe i am thinking of a different hwaccel api [15:00:07 CEST] Action: ubitux discovers av_thread_message_queue @_@ [15:00:15 CEST] <Daemon404> i was pretty sure it was mmal on teh rpi though [15:00:38 CEST] <wm4> Daemon404: if you want a sync API, mmal is definitely very hard to use [15:00:56 CEST] <wm4> (and lavc makes it a bit harder because of 1:1 input/output) [15:01:51 CEST] <Daemon404> right [15:02:11 CEST] <Daemon404> 1:1 i/o has bit be lots, and not even with async apsi [15:02:12 CEST] <Daemon404> apis* [15:11:35 CEST] <cone-769> ffmpeg 03Ganesh Ajjanagadde 07master:8738885c7d65: Revert "configure: add -Wstrict-prototypes when available" [15:12:26 CEST] <Daemon404> lul [15:13:47 CEST] <J_Darnley> . . . [15:21:50 CEST] <wm4> what [15:22:11 CEST] <wm4> "Missed it, it is already enabled. Reverted." [15:22:12 CEST] <wm4> ok [15:22:15 CEST] <nevcairiel> not even waiting a full day and pushing due to "lack of review", then reverting immediately because it was wrong [15:22:34 CEST] <nevcairiel> and people questioned me when I wondered why we give new developers push access right away [15:22:48 CEST] <wm4> meh [15:27:11 CEST] <Daemon404> nevcairiel, it was not a day [15:27:13 CEST] <Daemon404> it was like 16 hrs [15:27:41 CEST] <nevcairiel> "not even a day" [15:28:14 CEST] <Daemon404> look, reading is hard, you cant expect me to read my own native language [15:28:15 CEST] <Daemon404> pfft. [15:28:43 CEST] <nevcairiel> and here I am even writing a foreign language so you pleebs understand my brilliance! [15:42:50 CEST] <Daemon404> wm4, the least bad way i see of doing this is uselocale() but that is still prone to issues im sure... [15:42:57 CEST] <Daemon404> this, being using a . for teh radix [15:43:14 CEST] Action: Daemon404 stabs whoever thought changing the radix with locale is a good idea [15:43:48 CEST] <wm4> fuck locales [15:43:58 CEST] <wm4> fuck library devs who want you to set locale to non-C [15:44:01 CEST] <wm4> (yes they exist) [15:44:12 CEST] <Daemon404> also impressive that C provides no way to ingest such strings [15:44:13 CEST] <Daemon404> afaict? [15:44:17 CEST] <Daemon404> maybe im just dumb [15:45:58 CEST] <nevcairiel> C, strings, two things which if they appear in a sentence together will make your life harder [15:47:33 CEST] <wm4> somehow I rarely have trouble with C and strings [15:47:47 CEST] <wm4> it's just everyone else who insists on doing stupid tricky crap that breaks very quickly [15:48:00 CEST] <Daemon404> i do, but only with locales and encodings [15:48:20 CEST] <Daemon404> c++11 has codecvt or w/e [15:49:03 CEST] <Daemon404> and the non-C language i use most has teh concept of "runes" [15:49:09 CEST] <Daemon404> and a string can be made up of a set of 'runes' [16:01:25 CEST] <durandal_1707> that revert is funny, how he could miss flag several lines bellow [16:04:04 CEST] <J_Darnley> By not putting things in alphabetical order. [16:04:23 CEST] <nevcairiel> I even told him that the flag was active for me, hence how I found the warning [18:15:01 CEST] <BBB> awh man [18:15:02 CEST] <BBB> flags [18:15:15 CEST] <BBB> michaelni: I hope you understand Im having swscale flashbacks here, and that is not pretty [18:32:47 CEST] <Compn> BBB : you want to sponsor michaelni to rewrite swscale ? [18:32:49 CEST] <Compn> :P [18:39:35 CEST] <kierank> I'd sponsor Compn to shut up =p [18:40:20 CEST] <michaelni> BBB, sws flags are rather messy as they contain some multivalue things that should be in their own int. do you think the swr clip case will need more values or would otherwise benefit from being in its own int ? [18:42:06 CEST] <BBB> Im not so concerned about this flag, Im concerned about adding new features through flags and the flags field eventually blowing out of proportion the same way that swscale became the mess that it is [18:42:34 CEST] <BBB> (and dont get me wrong, I dont want anyone to spend time fixing it - I just am trying to convey the idea that we can prevent that mess from ever happening to swr) [18:58:13 CEST] <cone-769> ffmpeg 03Tom Butterworth 07master:abae43a7d41d: Add myself as maintainer for Hap [19:04:12 CEST] <mateo`> i would like to wrap in an avframe the cpu buffer (nv12) which comes from the mediacodec api and associate a release callback (i'm not using any hwaccel for now). I've looked at what videotoolbox was doing, frame->buf[0] = av_buffer_create, but i wonder how to map correctly the different planes in the avframe. Is it ok to map them using the frame->data pointers ? [19:04:50 CEST] <mateo`> is there a call to init the field of the avframe depending on the parameters of the avctx ? [19:09:22 CEST] <wm4> mateo`: the rule is: all AVFrame.data memory must be covered by a AVBufferRef (also, one AVBufferRef can cover multiple plane pointers, if the plane data is in the same memory alloc) [19:13:08 CEST] <mateo`> wm4: thanks a lot ! [19:20:32 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:dd456245b638: avformat/msf: extend format long description [19:20:33 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:8dea76180c3b: avcodec: extend long decription for adpcm psx codec [19:20:34 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:dfc64f4ddf4b: avformat/svag: extend format long description [19:20:35 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:a03fe8adba30: avformat/ads: extend format long description [21:13:09 CEST] <cone-769> ffmpeg 03Paul B Mahol 07master:daabc59c645c: avformat/genh: add ADPCM IMA DVI support [21:55:12 CEST] Action: J_Darnley must not send a snarky reply to the user mailing list. [21:58:35 CEST] <wm4> to what thread [21:58:59 CEST] <JEEB> I am only a masochist enough to be on the #ffmpeg IRC channel [21:59:08 CEST] <JEEB> I don't want that kind of stuff on my mail client, too :D [22:02:41 CEST] <BBB> hahaha thats funny [22:02:50 CEST] <BBB> video encoding costs money [22:03:04 CEST] <BBB> please help me [22:03:25 CEST] <J_Darnley> wm4: the javascript one [22:03:56 CEST] <wm4> must have missed it [22:04:02 CEST] <wm4> oh, the user ml [22:04:14 CEST] Action: J_Darnley thinks he said that [22:04:29 CEST] <J_Darnley> Yes "GPL implications of ffmpeg in the crowser" [22:04:32 CEST] <J_Darnley> uh [22:04:36 CEST] <J_Darnley> browser [22:04:39 CEST] <TD-Linux> the js one is actually a fairly reasonable question though the answer should be obvious reading the license [22:05:04 CEST] <J_Darnley> I agree [22:05:15 CEST] <J_Darnley> My reply was completely off topic and not useful in any way. [22:05:29 CEST] <J_Darnley> 'I think you mean "waste the client's computing power".' [22:06:36 CEST] <TD-Linux> hey man, you have to put the client's $2000 facebook machine to good use [22:14:00 CEST] <Daemon404> hey hey hey [22:14:03 CEST] <Daemon404> they use twitter too probably. [23:50:48 CEST] <mateo`> are the frames that come out a decoder are supposed to be valid (if the user keeps a ref) after the decoder has been destroyed ? [23:53:23 CEST] <wm4> yes [23:53:43 CEST] <nevcairiel> if thats a problem, you can ref the decoder object from the frame [23:53:46 CEST] <nevcairiel> i do that in dxva [23:53:52 CEST] <mateo`> i'm asking because if I wrap a mediacodec output buffer in an avframe, if the user decide to keep it after the decoder has been destroyed, i don't see how the release callback can still work [23:54:08 CEST] <mateo`> as it needs the mediacodec context [23:55:49 CEST] <mateo`> nevcairiel: i will do that then :) (and look at what you've done in dxva) [23:57:38 CEST] <wm4> nevcairiel: dxva frames are not valid after the decoder has been destroyed? [23:57:57 CEST] <nevcairiel> technically they are [23:58:05 CEST] <nevcairiel> but some drivers can be a bit annoyed when you do that [23:58:09 CEST] <wm4> lol [23:58:23 CEST] <nevcairiel> it caused issues on clips with resolution changes [23:58:33 CEST] <nevcairiel> since you trash the original decoder and create a new one [23:59:07 CEST] <wm4> I'd totally expect that some other drivers fuck up if you keep more than 1 decoder alive [23:59:23 CEST] <nevcairiel> nah [23:59:35 CEST] <nevcairiel> simultaneous stream decoding is supported on pretty much all of them [00:00:00 CEST] --- Sat Oct 24 2015

1 0

ffmpeg.log.20151023
by burek 24 Oct '15

24 Oct '15

[00:00:45 CEST] <muxan> many recommend foobar2000 but as im slowly moving away from windows i thought i'd see if ffmpeg could do it [00:01:18 CEST] <furq> fb2k isn't great if you're dealing with cuesheets [00:01:25 CEST] <muxan> i just cant find a gud doc bout it im pretty new to linux so yeah [00:01:45 CEST] <onefix> I guess you can buy a quad core AMD AM1 for ~$50 .. but you still need to buy the motherboard (another $50 for a Mini-ITX), a case with PSU ($30), and memory ($30 for 8GB) [00:01:47 CEST] <muxan> oh ok [00:03:00 CEST] <muxan> onefix if you must have a cluster go for a prebuilt one you can modd for linux its cheaper [00:03:29 CEST] <alexandros_c> good day is there a switch in ffmpeg that allows overscanning to filtered out when the join source is a vhs video? [00:03:32 CEST] <onefix> muxan: Where are those? [00:03:50 CEST] <muxan> if this is just an experiment id first do some tests b4 buying just my 2 cents [00:04:19 CEST] <muxan> amazon n newegg if you in the US [00:05:17 CEST] <onefix> muxan: Yeah, that's what I'm going to do...but I'll be comparing what I have which may or may not give me a good comparison... [00:05:39 CEST] <llogan> alexandros_c: you could use the crop filter. although personally all i'd do is deinterlace and put a black drawbox over the head switching noise [00:05:46 CEST] <onefix> muxan: Oh, so you're talking about just buying a pre-built "white box" desktop and putting Linux on it ... [00:06:10 CEST] <muxan> http://www.amazon.com/Asus-CHROMEBOX-M004U-ASUS-Desktop/dp/B00IT1WJZQ [00:06:21 CEST] <muxan> something like that [00:06:50 CEST] <muxan> its cheaper than building yourself [00:07:05 CEST] <alexandros_c> llogan: thanks for the response, but I read that if you use crop some of the video is lost. [00:07:30 CEST] <onefix> muxan: Yeah, but how good is a 1.4GHz Celeron versus say the Quad-Core 2.4GHz AMD Athlon that I configured for $160 ... [00:08:05 CEST] <muxan> that i dunno [00:08:09 CEST] <llogan> alexandros_c: the overscan is part of the video [00:08:15 CEST] <muxan> yours prolly faster [00:08:17 CEST] <llogan> so yeah, you'll lose some of the video [00:08:28 CEST] <alexandros_c> oh ok [00:08:31 CEST] <muxan> this is a 2013 model so yeah [00:08:39 CEST] <alexandros_c> llogan: thanks for the information [00:09:43 CEST] <llogan> this is kond of fun/interesting of VHS oddball stuff: http://avaa.bavc.org/artifactatlas/index.php/Image_Gallery [00:11:17 CEST] <furq> onefix: bear in mind the A13 is single core [00:11:29 CEST] <furq> the rpi2 is quad core [00:12:26 CEST] <onefix> muxan: I'm going to try and do a comparison with my 30 second video ... I can't seem to find good comparisons ... I mean I know that a single core 1GHz x86 processor is faster than a 1GHz ARM, but I know that that is partially based on the FPU [00:13:20 CEST] <muxan> i think its a dual core the one i mentioned [00:13:43 CEST] <llogan> alexandros_c: drawbox=x=0:y=ih-h:w=iw:h=5:color=black [00:13:53 CEST] <llogan> for the head switching noise if you encouter it [00:14:16 CEST] <llogan> (if you prefer not to crop it) [00:14:20 CEST] <muxan> http://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache-… [00:14:48 CEST] <furq> a 15W celeron isn't going to be up to much video encoding [00:15:11 CEST] <furq> the AM1 stuff is all low-power as well iirc [00:15:12 CEST] <muxan> better than the arm furq [00:15:31 CEST] <furq> well yeah but it had better be for 13 times the price [00:15:32 CEST] <muxan> much better [00:16:01 CEST] <muxan> 13x2 is 26fps [00:16:07 CEST] <muxan> i think it can [00:16:23 CEST] <furq> you can do much better than that though [00:16:51 CEST] <muxan> owhat on rpi? [00:16:57 CEST] <furq> no on x86 [00:17:18 CEST] <furq> you can get an x86 system which will destroy that for not much more [00:17:38 CEST] <onefix> muxan: Yeah, but I'm looking at total cost ... [00:19:05 CEST] <onefix> furq: That's why I was looking at a quad-core AMD with 8GB of RAM for $160 ... but I still wonder if that will be significantly better than say 16 CHIPs [00:19:24 CEST] <furq> i'd be really shocked if it wasn't [00:19:33 CEST] <muxan> onefix most likely [00:19:42 CEST] <furq> i can't imagine you'll get more than 2fps out of an A13 [00:19:52 CEST] <muxan> as cpu isnt the only bottleneck in clusters [00:20:08 CEST] <furq> and yeah this is assuming zero overhead from chopping everything up [00:22:22 CEST] <muxan> how much power will your amd use onefix? [00:22:24 CEST] <nyuszika7h> I'm trying to convert Core Media Closed Captions (eia_608) to SRT/ASS, but the result is really strange: https://i.imgur.com/Eg4unDn.png [00:24:16 CEST] <nyuszika7h> nothing seems to able to handle this format... [00:25:31 CEST] <onefix> muxan: Looks like 25W [00:26:27 CEST] <muxan> you sure? [00:26:39 CEST] <furq> onefix: you'd probably be better off with an AM3+ 6-core [00:26:40 CEST] <muxan> you counting the mobo too? [00:26:42 CEST] <onefix> muxan: Yeah, it's what the spec sheet says [00:27:01 CEST] <onefix> muxan: Nope, just the processor ... I know it will eat more than that [00:27:32 CEST] <muxan> still 40 watt isnt bad either [00:27:40 CEST] <onefix> muxan: The only way to know for sure is to build the system and plug it into a meter [00:28:15 CEST] <muxan> pretty much it can never draw more than psu tho [00:28:54 CEST] <muxan> atleast its better for your health if it doesnt [00:30:10 CEST] <nyuszika7h> [Closed caption Decoder @ 0000000004e985c0] Data Ignored since exceeding screen width [00:30:10 CEST] <nyuszika7h> Last message repeated 282 times [00:30:19 CEST] <nyuszika7h> I'm getting this error, but I'll just get another release [00:34:26 CEST] <nyuszika7h> it was 2 lines, but yeah sorry, I forgot about the rest, one sec [00:36:34 CEST] <nyuszika7h> http://dpaste.com/0BHWGWE [00:36:39 CEST] <alexandros_c> thanks llogan [00:36:50 CEST] <nyuszika7h> I'm already getting a different version but I do wonder what's wrong with this [00:39:48 CEST] <llogan> nyuszika7h: this is bug #4616 [00:39:52 CEST] <llogan> https://trac.ffmpeg.org/ticket/4616 [00:40:25 CEST] <nyuszika7h> I see [02:13:35 CEST] <alexandros_c> llogan: http://pastebin.com/raw.php?i=AR2PTrg6 [02:21:28 CEST] <llogan> join filters with a comma: yadif,drawbox [02:22:46 CEST] <llogan> you since you're filtering you can use format instead of pix_fmt, fps instead of -r (maybe), and scale instead of -s. that way you can better control where in the filterchain such filtering should occur [02:23:57 CEST] <alexandros_c> thanks again llogan [02:27:20 CEST] <llogan> alexandros_c: and there is a typo in your drawbox. h5 needs to be h=5 [02:27:36 CEST] <alexandros_c> thanks [02:27:46 CEST] <llogan> also, why change frame rate and frame size anyway? [02:28:08 CEST] <alexandros_c> you are saying take them out? [02:28:29 CEST] <llogan> not if you have a good reason for them. [02:28:42 CEST] <alexandros_c> ok [02:29:23 CEST] <llogan> (for future reference you should use 30000/1001 [or the alias "ntsc"] instead of 29.97) [02:29:50 CEST] <alexandros_c> how is that done? [02:30:19 CEST] <llogan> -r ntsc or -r 30000/1001 [02:32:16 CEST] <alexandros_c> so take out -s 768x480? [02:33:24 CEST] <llogan> if you want it to be that size for some reason then go ahead and leave it [02:33:52 CEST] <llogan> i just don't know what reason that would be [02:35:16 CEST] <alexandros_c> I am new to this, and I built that command string based on the information I found. didn't know what all of it was doing but it work...for the most part [02:44:13 CEST] <alexandros_c> llogan: any other option I can safely removed from the command? [02:46:37 CEST] <llogan> alexandros_c: it depends on how you are going to use the output videos [02:47:05 CEST] <llogan> for editing, archiving, uploading to youtube, etc [02:47:14 CEST] <alexandros_c> just saving to a digital format [02:47:28 CEST] <alexandros_c> with the possible of burning to a dvd [02:47:43 CEST] <alexandros_c> but not for youtube [02:48:49 CEST] <alexandros_c> also what will be the best format to store the video in? [02:51:34 CEST] <llogan> it just depends on how archival paranoid you want to be. you could use a lossless format, but the file sizes will be huge. or you could use a lossy format and use enough quality to make it roughly "visually lossless" [02:58:28 CEST] <llogan> alexandros_c: ffmpeg -f v4l2 -i /dev/video1 -f alsa -i hw:2 -filter:v "yadif=0:0:0,drawbox=x=0:y=ih-h:w=iw:h=5:color=black,format=yuv420p" -c:v libx264 -crf 18 -c:a aac -strict -2 -b:a 192k -movflags +faststart -metadata title="Video Title" output.mp4 [02:58:56 CEST] <llogan> could be a good start. i had to make some assumptions about your builds since you didn't provide the complete console output from your command [02:59:23 CEST] <alexandros_c> what assumptions did you make? [02:59:29 CEST] <alexandros_c> btw, thanks [02:59:37 CEST] <llogan> available encoders [02:59:44 CEST] <alexandros_c> I have all [03:00:47 CEST] <llogan> a build with "all" would be both rediculous and unecessary. i'll guess you're using something from Arch AUR [03:02:01 CEST] <alexandros_c> nope linuxmint 17.2 Cinnamon [03:02:08 CEST] <alexandros_c> well most [03:02:22 CEST] <alexandros_c> ok [03:03:13 CEST] <furq> if you got it from repos then it won't have libfdk_aac [03:04:14 CEST] <alexandros_c> llogan: http://pastebin.com/raw.php?i=gEkaQSDN [03:04:31 CEST] <llogan> the complete console output is missing [03:04:37 CEST] <llogan> wait, nevermind [03:05:03 CEST] <llogan> paste failure on my part [03:05:33 CEST] <alexandros_c> lol [03:06:16 CEST] <llogan> 2.4.3 is considered kind of old. [03:06:48 CEST] <llogan> anyway, one other thing you can monkey with is hqdn3d filter if your input is noisy as some analog tapes are [03:07:05 CEST] <llogan> and of course try the various yadif modes and choose the one that looks best to you [03:07:38 CEST] <alexandros_c> is there away to get a preview of what is recording? [03:08:29 CEST] <llogan> maybe by using the tee muxer, or maybe split filter, and piping one of the outputs to ffplay [03:13:54 CEST] <llogan> if you want a newer build compile (see ffmpeg wiki), use a static build, or mc4man's ppa [03:15:28 CEST] <llogan> got to go [04:04:15 CEST] <k_sze> Does the ffmpeg program (as in ffmpeg.exe) have a built-in timeout for outputting to file? [04:08:10 CEST] <inflex> Is there a fn call to dump debug details about an AVPacket variable? Or is it just something I should whip up? [04:09:02 CEST] <inflex> ie, I'm calling av_interleaved_write_frame(), and if there's an error I'd like to dump the contents of the AVPacket to see what might have caused the issue. [04:10:01 CEST] <SaintNicholas> Hi [04:13:43 CEST] <SaintNicholas> I'm having trouble implementing, in C, a filter that puts an overlay on top of a video stream. I can get it to properly output 1 frame, but then it continually fails while trying to do av_buffersink_get_frame. Anyone able to help? [08:02:15 CEST] <anshul_> does any one know about documentation of run time command of ffmpeg which we get when we press c while ffmpeg is running [08:02:51 CEST] <anshul_> I have some live streams which runs whole day, what I want is to change bitrate at runtime [08:09:27 CEST] <anshul_> Inside I see avfilter_graph_send_command is called, I should see how this work [08:10:46 CEST] <anshul_> is there any filter for bitrate [09:46:04 CEST] <worstje> Does anyone here have an idea as to why I can't feel to get --shortest to create the appropriate amount of video footage (from an image input) to match my audio? Depending on the video encoder, my 5-second audio clip causes 5:30 or 7:38 or even other video clip lengths and it is driving me crazy. [10:49:51 CEST] <inflex> any particular reason why av_interleaved_write_frame() will clobber the contents of the AVPacket passed in if there's a fault? [11:50:38 CEST] <anddam> hello, how can add a subtitle stream to an MP4 container? [11:52:02 CEST] <anddam> from what I could find the MP4 container, namely MPEG-4 Part 14, can contain an MPEG-4 Part 17 subtitle stream, "Timed Text" or "Streaming text format" but it's not clear to me how I can tell ffmpeg to convert a srt (SubRip) to the former [11:52:36 CEST] <anddam> I -c:s copy and mov_text, that I read is an mp4 compatible format, with no luck [11:57:03 CEST] <anddam> I tried* [11:57:32 CEST] <relaxed> anddam: http://pastie.org/ your command and output [11:58:15 CEST] <anddam> I tried different combination, using a single -c option, or separated -c:v -c:a -c:s options or -map options with specific -c:v:0 -c:s:0 -c:s:0 to try to force the conversion [11:58:54 CEST] <anddam> relaxed: I made several and I have to re-run them to get the output, can you suggest one that is more insightful? [11:59:20 CEST] <anddam> oh btw, I have two input files, a .mp4 and a .srt [12:00:06 CEST] <anddam> let me start pasting ffprobe for them so we can cut to the chase, ok? [12:00:31 CEST] <relaxed> ffmpeg -i input.mp4 -i input.srt -map 0 -map 1 -c:v copy -c:a copy output.mp4 [12:01:44 CEST] <anddam> isn't that skipping subtitles? [12:01:46 CEST] <anddam> https://gist.github.com/anddam/32c1970cf92e12ee58d2 [12:01:50 CEST] <anddam> now to your command [12:03:22 CEST] <anddam> updated with the output you asked, the relevant bit is [12:03:25 CEST] <anddam> Stream #1:0 -> #0:2 (subrip (srt) -> ? (?)) [12:03:26 CEST] <anddam> Encoder (codec none) not found for output stream #0:2 [12:04:02 CEST] <relaxed> try again with -c:s mov_text [12:04:36 CEST] <anddam> wow, a lot of [12:04:38 CEST] <anddam> [mp4 @ 0x7fc0bd00ec00] Application provided duration: -4 / timestamp: 1208508 is out of range for mov/mp4 format [12:04:40 CEST] <anddam> [mp4 @ 0x7fc0bd00ec00] pts has no value [12:04:49 CEST] <anddam> but it completed with no error [12:05:18 CEST] <anddam> and the output file has got [12:05:19 CEST] <anddam> Stream #0:2(und): Subtitle: mov_text (tx3g / 0x67337874), 0 kb/s (default) [12:05:30 CEST] <relaxed> looks good [12:05:32 CEST] <anddam> thanks, I wonder what I was doing wrong before [12:05:57 CEST] <anddam> so mov_text is an encoder that works with MP4 container [12:06:08 CEST] <relaxed> probably not -map(ing) it to the output [12:07:58 CEST] <relaxed> worstje: try encoding the video with no bframes [12:08:11 CEST] <anddam> does that first -map 0 option map both streams from first -i option argument? [12:08:15 CEST] <relaxed> worstje: or use -t $time [12:08:31 CEST] <relaxed> anddam: yes [12:17:40 CEST] <anddam> thanks [13:05:21 CEST] <anshul_> can I use FFmpeg Logo as part of my software logo? [13:13:15 CEST] <BasisBit> anshul_, I don't think so. And this is the wrong place to ask. you would need a write permision or some free/public license [13:20:30 CEST] <anshul_> ok i wont use then [14:37:14 CEST] <sopparus> hello, is it possible to make any use of amd VCE for encoding with ffmpeg/linux? [15:00:53 CEST] <Mavrik> Nope. [15:10:42 CEST] <sopparus> ok [16:32:04 CEST] <hero_biz> hi guys. [17:43:06 CEST] <fred1807> is it possible to command ffmpeg to scale to 1080p Only if the input is higher than 1080p (example 4k)? (Dont upscale a 720p for example) [17:43:35 CEST] <fred1807> I am batch converting a lot of videos [17:47:24 CEST] <spicypixel> fred1807: http://www.renevolution.com/understanding-ffmpeg-part-ii-scaling-video/ scroll down [17:47:39 CEST] <spicypixel> the min() function basically [17:48:43 CEST] <fred1807> vf "scale='min(iw,1920)':-1" <---- is this it? [17:50:00 CEST] <hero_biz> guys,we cannot set libx264 qpfile via -x264opts? [17:52:53 CEST] <hero_biz> will -force_key_frames force key frames for my encoded h264 video? [17:54:10 CEST] <hero_biz> i want to force few I frames so I could split video after encoding on them. [18:11:37 CEST] <hero_biz> no one? [18:13:51 CEST] <hero_biz> should I set -forced-idr 1 too? [18:16:33 CEST] <fred1807> spicypixel: It worked, thank you! [18:16:49 CEST] <spicypixel> sure thing :D [18:16:53 CEST] <spicypixel> I had to do it myself this morning [18:25:41 CEST] <hero_biz> any idea what -forced-idr option do? [18:27:28 CEST] <DHE> you can use it to force keyframes on frames marked as such from upstream [18:32:18 CEST] <hero_biz> means i need to use -force_key_frames times -forced-idr 1 to add an I frame to specific position? [19:12:45 CEST] <xsi> I'm getting from "time to time" sound, how to say... choppy, intermittent 1 second it plays 2 seconds no sound: [19:12:48 CEST] <xsi> ffmpeg -f alsa -ac 1 -i hw:0,0 -f x11grab -framerate 25 -video_size 1280x1024 -i :0.0+0,0 -vcodec libx264 -maxrate 15000k -bufsize 15000k -acodec libfdk_aac -b:a 32k -ar 11025 -f flv num55.flv [19:14:49 CEST] <xsi> The more i change codecs for flv (that is the format i'm trying) the more i blame the codecs part? How could it be? Just mp3 or vorbis - ok, it works. But when i need flv for a twitch screencast - big NO((( [22:14:37 CEST] <Mavrik> 32k audio with 11025 sample rate? O.o [22:14:43 CEST] <Mavrik> What are you doing to the poor audio there? O.o [23:08:36 CEST] <rocktop> is there away to right standard ffmpeg output to the file ? [23:11:41 CEST] <c_14> &> file [00:00:00 CEST] --- Sat Oct 24 2015

1 0

ffmpeg-devel.log.20151022
by burek 23 Oct '15

23 Oct '15

[00:43:22 CEST] <cone-848> ffmpeg 03Andreas Cadhalpun 07master:957f92729a3e: avcodec: drop 2 suffix from avpriv_ac3_parse_header2 [00:43:24 CEST] <cone-848> ffmpeg 03Andreas Cadhalpun 07master:a4680e71707e: avcodec: rename avpriv_color_frame to ff_color_frame [01:49:45 CEST] <Timothy_Gu> kierank: thx for the heads up. dont think ill be using it [01:56:31 CEST] <kagami_> Hi. Is it possible to fix pkt_duration inside filter? I'm setting different value but it still doesn't change in the output. (I hope this is the appropriate channel for the question.) [02:13:26 CEST] <cone-848> ffmpeg 03Alexis Ballier 07master:94ec82f14ab1: libavformat/mxfdec.c: cosmetics: Add missing space after '?' in log message. [02:13:27 CEST] <cone-848> ffmpeg 03Alexis Ballier 07master:12628e3369de: libavformat/mxfdec.c: Report dark metadata keys only when they match no parser at all, not everytime they fail to match one. [04:22:13 CEST] <atomnuker> was ff_clz removed? [04:23:57 CEST] <atomnuker> nvm, it never existed, was thinking of ff_ctz [04:56:31 CEST] <pross> i have forgotten Paul Mahols nick [04:57:22 CEST] <pross> Paul: the samples you sent, were not relevant to your patch! [05:01:40 CEST] <atomnuker> pross: he's durandal_1707 [05:01:58 CEST] <cone-848> ffmpeg 03Timothy Gu 07master:ab5f43e6342c: vc1dsp: Port ff_vc1_put_ver_16b_shift2_mmx to yasm [05:10:22 CEST] <Compn> pross : durandal_1707 is paul i think [05:15:30 CEST] <pross> thx [05:23:47 CEST] <durandal_1707> pross: how so? [05:24:10 CEST] <cone-848> ffmpeg 03Marton Balint 07master:a1240c0522d1: ffmpeg: log failed av_write_trailer [05:24:11 CEST] <cone-848> ffmpeg 03Marton Balint 07master:f4730a584542: ffmpeg: exit on av_write_trailer failure if exit_on_error is set [05:24:12 CEST] <cone-848> ffmpeg 03Marton Balint 07master:e2b416b68e85: ffmpeg: factorize checking decoder result [05:24:13 CEST] <cone-848> ffmpeg 03Marton Balint 07master:b69b43e2c471: ffmpeg: exit on corrupt packets or decoded frames if exit_on_error flag is present [08:59:23 CEST] <cone-206> ffmpeg 03James Almer 07master:73353af6e559: x86/Makefile: move decoder/encoder objects out of the subsystems section [10:11:46 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181803.html [10:11:50 CEST] <ubitux> someone please explain :( [10:13:25 CEST] <flux> yes, please add those presets. k thx bai. [10:44:47 CEST] <wm4> _julian: hi [10:45:01 CEST] <_julian> wm4: hi :) [10:46:36 CEST] <cone-206> ffmpeg 03Julian Scheel 07master:7ebe12fc5559: mmaldec: Add mpeg2 decoding support [10:57:40 CEST] <kagami_> Could someone at least give a hint regarding pkt_duration? It just shouldn't work that way or I'm doing something wrong? [11:01:58 CEST] <cone-206> ffmpeg 03Paul B Mahol 07master:0d7c02748335: avformat/electronicarts: support ADPCM PSX [11:01:59 CEST] <cone-206> ffmpeg 03Paul B Mahol 07master:6debfce6a31b: avformat/electronicarts: fix demuxing of certain eam files [11:11:00 CEST] <_julian> wm4: are you running on Pi or Pi2, btw? [11:12:16 CEST] <wm4> pi2 [11:13:18 CEST] <nevcairiel> (everyone should be, its like 200x faster) [11:23:45 CEST] <cone-206> ffmpeg 03Carl Eugen Hoyos 07master:c52c78cc568f: lavf/mpjpegdec: Return 0 if an allocation inside the probe function fails. [11:38:32 CEST] <cone-206> ffmpeg 03Carl Eugen Hoyos 07master:775b84e30ef2: lavc/x86/vc1dsp_init: Fix compilation with --disable-yasm. [11:38:39 CEST] <nevcairiel> man what happened with git 2.6, rebasing has gotten like 20 times faster [11:57:02 CEST] <JEEB> nevcairiel: wow [11:57:52 CEST] <durandal_1707> ok to push shuffleframes? [12:27:35 CEST] <maurobaraldi> Hello world. I have a question. Does the ffmpeg load entire file when read? Where can I find it on source code? [12:36:04 CEST] <wm4> maurobaraldi: for most types of files it usually doesn't [12:40:19 CEST] <maurobaraldi> But it open only once? I mean, it doesn't not open and reopen along the process? [12:43:29 CEST] <wm4> usually not [12:56:51 CEST] <maurobaraldi> Thanks! [13:13:16 CEST] <cone-206> ffmpeg 03Peter Ross 07master:cdfc61de4eea: libavformat/electronicarts: also demux mpeg audio layer 2 [14:21:08 CEST] <cone-206> ffmpeg 03Michael Niedermayer 07master:00efaa798377: avutil/intmath: fix undefined behavior in ff_ctzll_c() [15:47:32 CEST] <cone-206> ffmpeg 03Anton Khirnov 07master:772c87c5a658: qsvenc: support passing arbitrary external buffers to the encoder [15:47:33 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:760dbdd3c561: Merge commit '772c87c5a658f36d7c0612f5da583fc2bfa54f79' [15:49:55 CEST] <cone-206> ffmpeg 03Anton Khirnov 07master:f6f32fc93d39: qsvenc: set the timestamp for PIX_FMT_QSV frames as well [15:49:56 CEST] <cone-206> ffmpeg 03Anton Khirnov 07master:2ec96b6bd5bf: qsvenc: cosmetics, reindent [15:49:57 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:2fece1e4d5ee: Merge commit 'f6f32fc93d39caf329869c1bff8ad024ccab1d42' [15:49:58 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:a440886a35e3: Merge commit '2ec96b6bd5bf7b22978711bcf2cee702bee89c6f' [15:57:26 CEST] <cone-206> ffmpeg 03Anton Khirnov 07master:dc923bc23b3e: qsvenc: add an API for allocating opaque surfaces [15:57:27 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:866a4174dba0: Merge commit 'dc923bc23b3efd949d0bf67ff1abdb95059e5843' [16:23:13 CEST] <cone-206> ffmpeg 03Anton Khirnov 07master:fb472e1a11a4: avconv: add support for Intel QSV-accelerated transcoding [16:23:14 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:dd8a4b0f8c39: Merge commit 'fb472e1a11a4e0caed2c3c91da01ea8e35d9e3f8' [17:02:58 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:b54d64511607: qsvdec: fix get_format and hwaccel_context handling [17:59:55 CEST] <mateo`> hello there o/ regarding the hwaccel api, is it possible for the end_frame to return no frame ? is so, which code is supposed to be returned ? EAGAIN leads hwaccel to fail [18:00:19 CEST] <nevcairiel> hwaccel is always supposed to return a frame, or return a failure code [18:00:52 CEST] <nevcairiel> it operates at a slice level, it gets handed all the slices in one frame, and its supposed to decode those and only those [18:00:57 CEST] <nevcairiel> if it cant, it should return an error [18:01:01 CEST] <nevcairiel> but nothing else is valid [18:01:31 CEST] <mateo`> meh [18:02:37 CEST] <mateo`> but if the hw api needs more input to actually output a frame ? [18:02:49 CEST] <nevcairiel> thats not something it can decide [18:03:04 CEST] <nevcairiel> sounds like you dont want to use the hwaccel API if thats questions you have to ask [18:04:23 CEST] <wm4> mateo`: if the hw API doesn't match the ffmpeg hwaccel framework, you'll have to create a separate decoder for it [18:04:28 CEST] <wm4> like e.g. qsv does [18:05:46 CEST] <mateo`> i guess i will have to do that [18:06:24 CEST] <nevcairiel> the hwaccel API is designed for the "traditional" hwaccels which all work on a slice level [18:06:37 CEST] <nevcairiel> like VDPAU, VAAPI and DXVA [18:07:06 CEST] <nevcairiel> many "newer" and vendor specific APIs work on a bitstream level instead and want the full thing, which just doesnt fit into there [18:09:31 CEST] <mateo`> good to know ..., I would have been more inspired to closely look at how it is working before rushing the mediacodec support over there ^^ [18:12:42 CEST] <mateo`> wm4, nevcairiel: thanks for the information [19:02:44 CEST] <cone-206> ffmpeg 03Marton Balint 07master:5821244b225b: ffmpeg: fix ffmpeg.h trailing whitespace [19:12:03 CEST] <cone-206> ffmpeg 03Marton Balint 07master:ddc6bd8c9586: ffmpeg: add abort_on option to allow aborting on empty output [19:42:22 CEST] <cone-206> ffmpeg 03Vittorio Giovara 07master:ac981d16415e: APIchanges: Fill in missing dates and hashes [19:42:23 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:e9a2ab3ac783: Merge commit 'ac981d16415e7fd99683e10297781c7d9ec1a8cd' [19:44:05 CEST] <cone-206> ffmpeg 03Vittorio Giovara 07master:3496cec43304: msrle: Use AVFrame instead of AVPicture [19:44:06 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:d3cc258a6167: Merge commit '3496cec43304ac040d6d05f9d500a6f93cc049e7' [19:52:57 CEST] Action: durandal_1707 started RE xma codec [20:02:01 CEST] <wm4> nevcairiel: seems like nobody is able to review your schannel patch [20:02:13 CEST] <nevcairiel> of course not [20:02:15 CEST] <nevcairiel> its windows code [20:02:50 CEST] <cone-206> ffmpeg 03Luca Barbato 07master:fcc1280acb6e: rawenc: Replace avpicture functions with imgutils [20:02:51 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:6d34ab1a08c0: Merge commit 'fcc1280acb6e6f682b34c2101b075b82f83d71ba' [20:09:09 CEST] <nevcairiel> and no actual feedback on hwaccel+mt either yet, other than "vlc uses it", well duh, i knew that :) [20:09:19 CEST] <cone-206> ffmpeg 03Luca Barbato 07master:ef3a3519c106: rawdec: Replace avpicture functions with imgutils [20:09:20 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:9a6f1eea3e1d: Merge commit 'ef3a3519c10620c4206738595bf03fc0bed71802' [20:09:39 CEST] <lotharkript> any one interested to review this "[PATCH] Adds support parsing the QuickTime Metadata Keys." [20:11:33 CEST] <jamrial> nevcairiel: if you get no actual feedback or concrete arguments agains the hwaccel patch then just push it [20:11:47 CEST] <J_Darnley> All I have to say about that is who thought it would be a good idea to store floats as metadata values. [20:12:21 CEST] <nevcairiel> jamrial: thats what I'll do in a couple days, dont want to rush it and get blamed later [20:12:44 CEST] <nevcairiel> my vp9 hwaccel is kidna waiting for it since its somewhat broken with mt [20:13:34 CEST] <nevcairiel> i'll probably write a proper commit message tomorrow and put it on the ML again, if i dont get anything back then either, thats that [20:15:45 CEST] <llogan> lotharkript: if nobody replies after a few days you can reply with "ping". we sometimes just forget. [20:18:25 CEST] <Daemon404> ill look at it. [20:19:12 CEST] <lotharkript> thanks.. my coworker is on my back :-( [20:24:14 CEST] <cone-206> ffmpeg 03Vittorio Giovara 07master:f0a106578d75: roqvideodec: Replace avpicture functions with imgutils [20:24:15 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:42b87ed01eb3: Merge commit 'f0a106578d759de6183eea3c75f8373b6d3153c1' [20:24:16 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:ef4fbee79df6: roqvideodec: use av_frame_copy [20:31:30 CEST] <cone-206> ffmpeg 03Vittorio Giovara 07master:48c063868316: dpx: Replace avpicture functions with imgutils [20:31:32 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:8fe1433ad4f8: Merge commit '48c06386831604921bdaf4fb77ea02766cd615f4' [20:34:51 CEST] <cone-206> ffmpeg 03Vittorio Giovara 07master:13bddab7de10: nuv: Replace avpicture functions with imgutils [20:34:52 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:422fab7fbe51: Merge commit '13bddab7de10aebf6efb98aa6d7ff0c51bb0e364' [20:41:41 CEST] <kierank> Daemon404: surely it's a $9.99 subscription/mon to look at patches now =p [20:44:08 CEST] <Daemon404> lotharkript, review sent [20:44:48 CEST] <Daemon404> kierank, harr harr [20:45:17 CEST] <cone-206> ffmpeg 03Lou Logan 07master:4c46f1d493f4: avfilter/vf_zscale: fix typo [20:45:27 CEST] <Daemon404> oho zscale went in [20:45:31 CEST] <Daemon404> neat. [20:46:06 CEST] <nevcairiel> great now i have to rebase my merge [20:46:10 CEST] Action: nevcairiel curses [20:46:47 CEST] <nevcairiel> thank the git gods for rerere [20:46:55 CEST] <Daemon404> for what now [20:47:23 CEST] <nevcairiel> rerere! [20:47:31 CEST] <nevcairiel> it remembers conflict resolutions [20:47:45 CEST] <Daemon404> sounds like an anime [20:47:46 CEST] <Daemon404> <_< [20:47:53 CEST] <nevcairiel> and since you cant really rebase merges, you have to re-do them [20:48:07 CEST] <Daemon404> or merge again. [20:48:11 CEST] <nevcairiel> but as long as no new conflicts appear, rerere does that for you [20:48:15 CEST] <Daemon404> just in the opposite directin [20:48:16 CEST] <J_Darnley> (Why isn't your git history a straight line?) [20:48:45 CEST] <nevcairiel> cant merge libav changes into a straight line =p [20:50:01 CEST] <cone-206> ffmpeg 03Vittorio Giovara 07master:f890677d05bc: Replace any remaining avpicture function with imgutils [20:50:02 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:470204218f37: Merge commit 'f890677d05bc4e8b494a73373ab4cc19791bf884' [20:50:49 CEST] <llogan> nevcairiel: heh, sorry. yet another one of my super useful commits. [20:51:05 CEST] <nevcairiel> i'm just happy that i found out rerere exists [20:57:51 CEST] <lotharkript> Deamon404: thanks. Will let my co-worker know. [21:02:42 CEST] <Plorkyeran> git rebase --preserve-merges works for simple merges [21:02:50 CEST] <Plorkyeran> but maybe the merges from libav aren't simple... [21:03:57 CEST] <nevcairiel> all that does is try to re-apply the merge after the rebase [21:04:08 CEST] <nevcairiel> it doesnt remember any of your changes or conflict resolutions [21:04:58 CEST] <NitLord> think about that makes me feel like a real gitard. [21:05:25 CEST] <NitLord> so does reading what I type. [21:32:48 CEST] <cone-206> ffmpeg 03Michael Niedermayer 07master:ea5a1d148530: avcodec/x86/vc1dsp: Remove unused macro [21:32:49 CEST] <cone-206> ffmpeg 03Michael Niedermayer 07master:37498a4b202e: avcodec/nuv: Fix 'libavcodec/nuv.c:83:19: warning: passing argument 3 of av_image_copy from incompatible pointer type' [21:43:15 CEST] <cone-206> ffmpeg 03Vittorio Giovara 07master:a17a7661906b: lavc: Add data and linesize to AVSubtitleRect [21:43:16 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:ee573b4d31d4: Merge commit 'a17a7661906ba295d67afd80ac0770422e1b02b3' [21:44:03 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:ce9736362896: avcodec/libzvbi: Update for AVSubtitleRect changes [21:46:27 CEST] <cone-206> ffmpeg 03Vittorio Giovara 07master:ff7956fcbf8e: avplay: Replace avpicture functions with imgutils [21:46:28 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:3c3997188ef9: Merge commit 'ff7956fcbf8e59b21654b95038de3ed88a850a9e' [21:48:05 CEST] <nevcairiel> anyone feel like updating ffplay to no longer use AVPicture? its used all over the place [21:49:13 CEST] <ubitux> only for bitmap subs, isn't it? [21:49:13 CEST] <cone-206> ffmpeg 03Vittorio Giovara 07master:3ee2c60cc296: utils: Use data buffers directly instead of an AVPicture [21:49:14 CEST] <cone-206> ffmpeg 03Hendrik Leppkes 07master:dde8e5ad02ad: Merge commit '3ee2c60cc296eee3f63d7b5fee9b4332eeeac9fa' [21:49:29 CEST] <nevcairiel> ubitux: also for generic video things, from the looks of it [21:50:31 CEST] <nevcairiel> (also, i hope none of the bitmap sub decoders broke now) [21:51:27 CEST] <jamrial> nevcairiel: poke marton balint. he's the main ffplay developer afaik [21:59:15 CEST] <ubitux> erm [21:59:33 CEST] <ubitux> isn't the AVSubtitleRect breaking ABI? [21:59:40 CEST] <ubitux> so we're still in that period? [22:02:27 CEST] <nevcairiel> noone has specifically closed it yet i su ppose [22:02:42 CEST] <nevcairiel> and barely anyone bothered to answer my mail on the subject [22:02:44 CEST] <nevcairiel> so shrug [22:04:17 CEST] <nevcairiel> i do wonder why koda didnt put the AVSubtitleRect.pict compat code into the main decode subtitle function though [22:15:55 CEST] <cone-206> ffmpeg 03Ganesh Ajjanagadde 07master:8507b98c10d9: avfilter,swresample,swscale: use fabs, fabsf instead of FFABS [22:19:34 CEST] <wm4> nevcairiel: me too [22:36:34 CEST] <RiCON> nevcairiel: schannel with gmp for rtmpe seems to be working fine with mpv [22:36:40 CEST] <RiCON> using your patch and https://raw.githubusercontent.com/jb-alvarado/media-autobuild_suite/master/… [22:56:32 CEST] <BBB> durandal_1707: which docs? [22:56:42 CEST] <BBB> durandal_1707: I dont tihnk the last line of the av_log output is documented [22:57:15 CEST] <BBB> durandal_1707: or maybe it is and Im blind? [23:00:29 CEST] <durandal_1707> I meant if its put in stats file [23:00:48 CEST] <durandal_1707> But it looks like not [23:11:01 CEST] <cone-206> ffmpeg 03Michael Niedermayer 07master:3f85552e402c: avcodec/libzvbi-teletextdec: Add variable to fix build [23:16:50 CEST] <BBB> durandal_1707: yeah I didnt want to update that just yet, this is just the log [23:16:57 CEST] <BBB> durandal_1707: so patch ok w/o doc adjustments then? [23:17:40 CEST] <durandal_170> BBB: yes [23:19:04 CEST] <BBB> ok, ty [23:35:29 CEST] <kierank> llogan: that larbi guy [23:35:36 CEST] <kierank> sent me emails, added me on linkedin [23:35:39 CEST] <kierank> ... [23:37:11 CEST] <llogan> kierank: heh. you are now friends. [23:37:59 CEST] <atomnuker> how'd you get yourself a stalker online? [23:38:53 CEST] <llogan> talking about stalking, when do you think experimental flag will be removed? [23:39:16 CEST] <nevcairiel> atomnuker needs to stalk claudio more, apparently [23:41:08 CEST] <nevcairiel> Last I heard we were waiting for a few small fixes of his [23:41:33 CEST] <kierank> atomnuker: that's what people do [23:41:48 CEST] <kierank> not sure why [23:42:32 CEST] <cone-206> ffmpeg 03Ronald S. Bultje 07master:81d7f118e20c: vf_psnr: remove %0.2f format specifiers for stream summary line. [23:42:34 CEST] <cone-206> ffmpeg 03Ronald S. Bultje 07master:e7d9061d4f93: vf_ssim: print per-channel dB values. [23:43:09 CEST] <llogan> it takes a certain type of person to send their questions to ffmpeg-*-owner(a)ffmpeg.org then then email the list asking to unsubscribe [23:44:27 CEST] <atomnuker> nevcairiel: he needs a few more days, and I think I'll wait, basically we found a huge retarded oversight which was what ruined the new coder on some techno tracks and need time to do regression testing [23:44:28 CEST] <kierank> llogan: you haven't seen the facebook ones [23:44:44 CEST] <kierank> either they pm you or they complain on the ffmpeg page [23:44:45 CEST] <wm4> isn't facebook all about stalking [23:44:50 CEST] <llogan> i'm surprised there aren't more help requests on twitter [23:45:15 CEST] <kierank> I wonder if you could get twitter verified [23:45:41 CEST] <llogan> AFAIK/IIRC they just have to anoint you with that on their own regard. [23:45:53 CEST] <TD-Linux> ffmpeg has a facebook page? [23:46:05 CEST] <nevcairiel> atomnuker: we've been waiting years, we can hold out a couple more days/weeks [23:46:07 CEST] <nevcairiel> but not months [23:46:10 CEST] <nevcairiel> just to be clear [23:46:10 CEST] <nevcairiel> :D [23:46:13 CEST] <llogan> TD-Linux: fcaebook/ffmpeg.org I think [23:48:56 CEST] <atomnuker> nevcairiel: well if you need to know the details IS marked bands and replaced their scalefactor indices but since those are transmitted as the difference between the previous and the next value IS was being an inconsiderate prick and resulted in sometimes an assertion being triggered and completely messing up the decoder even though the IS bands were fine on their own [23:49:35 CEST] <atomnuker> yeah, that's a very definite derp [23:51:15 CEST] <atomnuker> this basically resulted in warbling heard on some synth-heavy tracks and at low bitrates manifested itself as a freaking 440ish Hz tone (dependant on samplerate) [23:51:22 CEST] <nevcairiel> unrelated: how do i download stuff from the incoming ftp again? I cant remember, or remember where to find the info [23:54:15 CEST] <wm4> you need to login with a secret login [23:54:21 CEST] <wm4> (which everyone knows) [23:56:34 CEST] <llogan> the silence is a result of nobody knowing. [23:57:01 CEST] <llogan> i asked carl once, then also lost/forgot it and didn't have the foresight to write it down [23:59:21 CEST] <wm4> so was the login changed? [23:59:38 CEST] <BBB> durandal_1707: that psnr stdout stats patch is broken btw [00:00:00 CEST] --- Fri Oct 23 2015

1 0

ffmpeg.log.20151022
by burek 23 Oct '15

23 Oct '15

[00:00:37 CEST] <onefix> You could build a script that could be ran as a daemon that watches for a directory to show up and starts encoding a part [00:01:07 CEST] <onefix> If you did it right, the main system wouldn't need to know anything about the number of encoders available, it could just deposit the files and wait for them to finish [01:12:21 CEST] <BullHorn> erm [01:12:43 CEST] <BullHorn> ive been using my PC for a couple years, mostly gaming+recording video, never issues and the CPU never went above ~70c or so [01:12:53 CEST] <BullHorn> im now re-encoding a video with ffmpeg for the last 2 hours and http://i.imgur.com/XM7j8AH.png [01:12:57 CEST] <BullHorn> a little spoopy D: [01:17:17 CEST] <BullHorn> is there a way to use ffmpeg without avx2 [01:17:24 CEST] <dsl420> when i do encode on a notebook it looks like that, for an intel it might be Okish :) [01:17:31 CEST] <BullHorn> it raises my CPU's voltage beyond the limit i set it to [01:18:16 CEST] <dsl420> well 90°C is pretty high i guess i encode at 85°C on a notebook [01:20:16 CEST] <drv> 100C is usually the thermal limit where throttling starts to happen [01:20:23 CEST] <drv> looks like insufficient/incorrectly installed cooling [01:20:57 CEST] <BullHorn> it never went above 70 [01:21:04 CEST] <BullHorn> on the other hand i never used ffmpeg for 2h straight [01:21:15 CEST] <BullHorn> maybe its time to clean the dust filters and re-apply thermal paste [01:21:25 CEST] <BullHorn> ill do it during the weekend and avoid ffmpeg until then ;x [01:22:30 CEST] <BullHorn> i hope 2 year old thermal paste tube is still good [02:26:11 CEST] <BullHorn> hmm i need some help [02:26:16 CEST] <BullHorn> i currently use this command line: [02:26:18 CEST] <BullHorn> ffmpeg -i D:\Streaming\%1.mkv -c:a copy -c:v libx264 -crf 24 -preset:v veryfast -copyts F:\%2.mp4 [02:26:33 CEST] <BullHorn> issue is: i started recording 2 audio tracks but this only copies the first track [02:27:38 CEST] <xsi> [ALSA] Every audio codec which I use with ffmpeg has intermittent sound. I changed from libmp3lame to libfaac to aac to adpcm_swf (all compatible with .flv, for twitch screencast). The same intermittent sound. [02:28:11 CEST] <xsi> What could it be with the sound recording? (ffmpeg): https://youtu.be/XNT0pSHb5oI . My command line is: https://bpaste.net/show/ee4c3b03a95e [02:29:04 CEST] <xsi> sorry maybe i'm annoying #ffmpeg channel but my sound sucks( [02:31:06 CEST] <furq> BullHorn: afaik you have to use -map [02:31:14 CEST] <furq> probably -map 0:0 -map 0:1 -map 0:2 [02:32:13 CEST] <BullHorn> can you help me modify my line with this? [02:32:21 CEST] <BullHorn> i keep the line in a .bat file so i just convert a b and it goes [02:32:32 CEST] <BullHorn> although i have no idea about bat files or ffmpeg ;x [02:32:39 CEST] <furq> put it after -c:a copy [02:32:55 CEST] <furq> anywhere between the two filenames is fine [02:33:06 CEST] <xsi> [ALSA] Every audio codec which I use with ffmpeg has intermittent sound. I changed from libmp3lame to libfaac to aac to adpcm_swf (all compatible with .flv, for twitch screencast). The same intermittent sound when recording - what could it be? : (ffmpeg): https://youtu.be/XNT0pSHb5oI . My [02:35:26 CEST] <BullHorn> thats how it looks now: [02:35:26 CEST] <BullHorn> ffmpeg -i D:\Streaming\%1.mkv -map 0 -c:a copy -c:v libx264 -crf 23 -preset:v veryfast -copyts F:\%2.mp4 [02:35:30 CEST] <BullHorn> ill go try [02:35:42 CEST] <furq> that's totally not what i said [02:36:08 CEST] <BullHorn> i thought -map 0 would take all the values including :0, :1, :2 etc [02:36:08 CEST] <BullHorn> ;x [02:36:15 CEST] <furq> i do approve of the crf mysterously increasing though [02:36:35 CEST] <BullHorn> a 76gb file recorded with ultrafast went down to 30gb with veryfasy [02:36:43 CEST] <furq> oh that is actually right [02:36:44 CEST] <BullHorn> i can handle a bit more filesize/quality :p [02:36:46 CEST] <furq> the -map 0 thing [02:37:17 CEST] <furq> i've only ever used -map to remove russian audio tracks [02:37:24 CEST] <BullHorn> :D [02:37:29 CEST] <BullHorn> cyka blaty [02:37:34 CEST] <furq> sorry gavrilov [02:37:42 CEST] <BullHorn> drink dotka play vodka [02:39:54 CEST] <BullHorn> yes this worked furq [02:39:58 CEST] <BullHorn> -map 0 was all it took :) [06:37:05 CEST] <ohsnap> hey all. im running ffmpeg with the command line options " -i blahblah.mkv -c copy out.mp4 " to break a video out of a mkv container, but im a noob and i cant figure out how to change the audio track it dumps out with it [06:37:16 CEST] <ohsnap> this container had several different audio tracks available and i need a different one [06:55:44 CEST] <ohsnap> so yeah i rtfmd. -map [06:55:50 CEST] <ohsnap> stay seksi <3 [08:18:48 CEST] <deetwelve> Hello, I am using ffmpeg and rtmp to stream a file. Is there a command to start the file at a specific time? [08:27:24 CEST] <wt> hi...is is possible to pass args via a file instead of via the commandline? [12:16:09 CEST] <maurobaraldi> Hello world. Does the ffmpeg load entire file when read or there is a way to do so? [13:58:35 CEST] <pgunnars> where can i see the log for this channel [14:02:25 CEST] <waressearcher2> is that channel logged ? [14:06:57 CEST] <c_14> http://ffmpeg.gusari.org/irclogs/ [14:48:49 CEST] <pgunnars> BtbN: you here? [14:55:50 CEST] <BtbN> Not for too long [14:55:58 CEST] <BtbN> like, 5 minutes or so [14:59:58 CEST] <BtbN> I do read the backlog though, so if you're fine with a few hours of delay... [15:06:59 CEST] <pgunnars> was just wondering regarding the questions i was asking you yesterday [15:07:25 CEST] <pgunnars> the difference between outputting to "-" compared to "file.webm" [15:07:58 CEST] <BtbN> hm? [15:08:00 CEST] <pgunnars> lose the metadata when I create a file from the stdout output [15:08:13 CEST] <pgunnars> theres no duration etc [15:08:40 CEST] <pgunnars> how to add the duration info to the file [15:11:25 CEST] <BtbN> by using a seekable output format. [15:12:40 CEST] <pgunnars> could you elaborate? [15:13:46 CEST] <pgunnars> well, I don't think that's really viable for the application, I'm sending the request directly to a http request [15:13:57 CEST] <pgunnars> Don't want to have to extract it to a file and then send the file [15:15:38 CEST] <pgunnars> the stream directly..* [16:20:48 CEST] <tonsofpcs> I have an hour-long .ts, I want to extract the last 5 minutes of one of the ESs (video, MPEG2, 1920x1080, 30000/1001 frames per second, interlace), and possibly decode it too - what's the best way to do this? (I don't have the HDD space to decide the entire ES yet alone the entire file) [16:21:19 CEST] <tonsofpcs> PCR-on-Video, yes, I know what all of the PIDs are [16:28:09 CEST] <pgunnars> BtbN: will just transcode server side I guess, will probably need to use ffmpeg there anyway [16:30:32 CEST] <TikityTik> Why doesn't -to work? [16:33:19 CEST] <DHE> if it's CBR you can cut the file with 'dd'. it sometimes causes minor weirdness at the start of the video but it works [16:34:18 CEST] <TikityTik> I want it to be duration based though [16:35:49 CEST] <TikityTik> i got it working nvm [16:35:53 CEST] <BtbN> pgunnars, ffmpeg can't seek back to the beginning of the file if you are writing it to a pipe. [16:36:05 CEST] <BtbN> But it needs to do that, so it can write the information it only knows at the end. Like the duration. [16:36:44 CEST] <BtbN> You don't have to do full transcoding on the server. Just do a full -c copy of the file. [16:37:05 CEST] <pgunnars> cool [16:38:22 CEST] <pgunnars> thanks [17:39:36 CEST] <buu> This is a vague and slightly hard to research question, but is there any way of asking ffmpeg or another tool if a video can be compressed without losing quality? [17:45:34 CEST] <flux> buu, it seems to me ffmpeg does not store such an information in a general fashion about the codecs. so, no. [17:47:29 CEST] <JEEB> lol [17:47:36 CEST] <JEEB> use lossless compression, receive bacon [17:47:42 CEST] <JEEB> lossy compression *always* loses quality [18:18:00 CEST] <RobotsOnDrugs> also receive gigantic file sizes [18:18:30 CEST] <RobotsOnDrugs> but less gigantic than uncompressed, of course [18:37:30 CEST] <buu> I meant without a major loss in quality =/ [18:37:34 CEST] <buu> Not literally zero [18:38:07 CEST] <buu> Although I am downloading youtube videos so presumably google has a pretty major interest in compressing them [19:05:26 CEST] <RobotsOnDrugs> if you're downloading from youtube, why not just leave them the way they are? [19:51:29 CEST] <TD-Linux> buu, well there are metrics you can use like SSIM to measure the loss in quality. However, youtube already uses a constant quality metric, so they've already done the "analysis" for you [19:52:30 CEST] <TD-Linux> if the files are too big, make sure youtube-dl is grabbing the VP9 version. and then if they are still too big, reduce your max resolution [19:52:41 CEST] <buu> TD-Linux: Yeah, that ocurred to me afterwards [19:53:03 CEST] <buu> Any analysis I'm going to do is unlikely to beat theirs... I hope [20:15:35 CEST] <bofh_> Hi there! I have the following rather complex command to merge two files: http://pastebin.com/9JK0k5g8, but for some reason ffmpeg complains that it can't find stream from filter expression. I assume that it gets confused because those are the video files so I need to instruct ffmpeg to extract audio streams first - but not sure how to do that. [20:15:40 CEST] <bofh_> please advice [20:17:52 CEST] <bofh_> llogan: http://pastebin.com/1ryxfNRY [20:23:49 CEST] <llogan> bofh_: works for me [20:24:12 CEST] <llogan> oh, i see. [20:24:34 CEST] <llogan> use [0:a] instead of [0]. and [1:a] instead of [1] [20:24:51 CEST] <llogan> i just tested on audio only inputs [20:26:32 CEST] <bofh_> interesting, let me try [20:26:54 CEST] <llogan> ...and that's why your original command worked for me [20:29:16 CEST] <bofh> llogan: okay, I think now I know the problem - one of the files doesn't contain an audio stream [20:29:44 CEST] <bofh> is there any way to "ignore" it while applying filters? I may not know in advance which of input files may not contain an audio stream [20:30:01 CEST] <llogan> oh, heh. that will do it too. didn't even notice. [20:31:35 CEST] <llogan> as for ignoring; i doubt it but i'm not 100% sure. [20:31:59 CEST] <llogan> you could use ffprobe and scripting [20:32:34 CEST] <bofh> llogan: http://pastebin.com/m17kuhrE [20:33:12 CEST] <llogan> your first input has no audio [20:34:56 CEST] <bofh> yes, so perhaps I need to pre-filter the input data before starting the conversion [20:49:48 CEST] <hero_biz> hi guys [20:49:53 CEST] <hero_biz> a question. [20:50:28 CEST] <hero_biz> how i can encode some parts of video with ffmpeg? [20:51:19 CEST] <hero_biz> for example I want to only encode time 0 to 30 and 50 to 150 from a video.(time in seconds) [20:54:14 CEST] <NitLord> hero_biz: each segment as separate outputs, or both concatenated into one? [20:54:37 CEST] <hero_biz> no,for example original is a 200 sec video [20:54:56 CEST] <hero_biz> and i want to encode those 2 part of original into outputfile [20:55:31 CEST] <NitLord> so the 2nd option [20:55:57 CEST] <hero_biz> ?? 2nd option? [20:56:17 CEST] <NitLord> both segments concatenated into one output [20:57:06 CEST] <hero_biz> yea,I want it like this [20:57:13 CEST] <hero_biz> but how i should do it? [20:57:33 CEST] <hero_biz> how I should specify those segments for encoding from original file? [20:57:34 CEST] <NitLord> do you want different video/audio/container formats than the original? [20:58:20 CEST] <hero_biz> i will be probably forced to encode it to another format. [21:01:00 CEST] <NitLord> then use the concat filter. ffmpeg -t 30 -i input0 -ss 50 -t 100 -i input2 -filter_complex "[0:v][0:a][1:v][1:a]concat=n=2:v=1:a=1[v][a]" -map "[v]" -map "[a]" output [21:01:28 CEST] <NitLord> or use the trim/atrim filters instead of -ss/-t [21:02:17 CEST] <NitLord> alternatively, if you don't want to re-encode, you could make stream copied segments then use concat demuxer [21:03:25 CEST] <hero_biz> ty :) I think atrim filter will solve my problem,if I could use it multiple times :) [21:09:48 CEST] <hero_biz> can I use trim filter like this: -vf trim=0:30,50:100 ? [21:10:15 CEST] <NitLord> no [21:11:09 CEST] <NitLord> make a new trim instance per segment. also, don't forget that trim is just for video. atrim for audio. [21:11:48 CEST] <hero_biz> but I have 1 input file... [21:12:09 CEST] <hero_biz> which is 200 second long. [21:12:59 CEST] <hero_biz> trim manual says: "If multiple start or end options are set, this filter tries to be greedy and keep all the frames that match at least one of the specified constraints. " [21:13:14 CEST] <hero_biz> but I don't get what this means... [21:13:17 CEST] <NitLord> ffmpeg -i input -filter_complex "[0:v]trim=0:30[t0];[0:v]trim=50:100[t1];[t0][t1]concat=n=2:v=1:a=0[v]" -map "[v]" [21:14:19 CEST] <NitLord> i don't quite understand that sentence either. [21:14:28 CEST] <hero_biz> O.O complex.... [21:15:27 CEST] <hero_biz> what happens to audio with this command that you have posted? [21:15:33 CEST] <NitLord> it is ignored [21:16:41 CEST] <NitLord> if you want it add some atrim. then change the concat filter, then map it [21:19:02 CEST] <hero_biz> command will be like this? ffmpeg -i input -filter_complex "[0:v]trim=0:30[t0];[0:v]trim=50:100[t1];[0:a]atrim=0:30[a0];[0:a]atrim=50:100[a1];[t0][t1]concat=n=2:v=1:a=0[v];[a0][a1]concat=n=2:v=0:a=1[a]" -map "[v]" -map "[a]" [21:20:04 CEST] <NitLord> almost. [t0][a0][t1][a1]concat=n=2:v=1:a=1[v][a] [21:20:31 CEST] <hero_biz> got it [21:20:56 CEST] <hero_biz> i wonder if audio and video will remain synched if I do like this.... [21:21:08 CEST] <NitLord> you'll just have to watch it [21:21:17 CEST] <hero_biz> lol [21:22:16 CEST] <hero_biz> maybe encoding whole video and then spliting it will be better... [21:22:31 CEST] <hero_biz> split/concat [21:28:01 CEST] <hero_biz> btw another question [21:28:32 CEST] <hero_biz> i'm trying to deinterlace a video and have used yadif=1 filter. [21:28:45 CEST] <hero_biz> original was 1080i. [21:29:19 CEST] <hero_biz> my result video is 60 fps. how I go to 24000/1001 fps for output file? [21:32:12 CEST] <NitLord> -r 24000/1001 or -r ntsc-film. or try the fps filter. the results may differ, but i can't remember what the difference is between them [21:33:12 CEST] <NitLord> note that yadif=1 doubles the frame rate [21:37:36 CEST] <hero_biz> if i use -vf yadif=1 -r 24000/1001, result will be 24000/1001, isn't it? [21:38:04 CEST] <llogan> yes [21:38:17 CEST] <llogan> why do you want to change frame rate? [21:38:51 CEST] <hero_biz> it is 60fps... O.O I thought to change to common 24000/1001. [21:39:19 CEST] <worstje> I currently pipe a raw file to x264.exe for rendering like this: ffmpeg.exe -i "raw.avi" -an -c:v wrapped_avframe -f yuv4mpegpipe -an -pix_fmt yuv420p - | x264.exe ... but now I would like to squeeze in a small generated piece of footage at the start. Is there a way I can squeeze this extra footage in beforehand without having to re-encode my raw footage first? [21:41:05 CEST] <furq> hero_biz: yadif=0 will output 30fps video [21:41:17 CEST] <hero_biz> will decreasing output fps affect output file size too? (I think it should, just want to make sure) [21:41:23 CEST] <furq> you probably want to stick with that rather than dropping random frames [21:41:37 CEST] <furq> and yes it'll reduce the filesize [21:41:38 CEST] <llogan> hero_biz: i would probably leave it at 60. all the frame dropping might look crappy (but it will depend on content). [21:42:19 CEST] <llogan> you'll also have to compare yadif modes. sometimes 1 looks much better to me (again, all depending on the input) [21:42:39 CEST] <furq> generally for film content yadif=1 looks wrong [21:42:43 CEST] <hero_biz> when you deinterlace a 1080i video and scale it to 720p, what command line you normally use? [21:43:03 CEST] <hero_biz> i chcked for animation,yadif=1 was good [21:43:34 CEST] <furq> most stuff looks better with yadif=1 [21:43:43 CEST] <llogan> yadif,scale=-1:720 [21:43:50 CEST] <furq> you'll pay for it with filesize though [21:44:49 CEST] <llogan> worstje: i don't really understand your question. also, why not just use libx264 instead of piping? [21:45:03 CEST] <hero_biz> can we decerase frame rate in libx264 encoding process? [21:45:23 CEST] <furq> -r will do that [21:45:29 CEST] <furq> it won't look good though [21:45:54 CEST] <hero_biz> -r drops frames randomly? [21:45:57 CEST] <worstje> llogan: Because this is the way the script was before it ended up in my hands, and why break something that works? [21:46:01 CEST] <furq> pretty much [21:46:55 CEST] <hero_biz> I thought we can keep more important frame and drop less important ones when encoding and decreasing frame rate. [21:47:04 CEST] <furq> which frames are less important [21:47:28 CEST] <llogan> worstje: seems unecessarily complex and harder to maintain [21:48:20 CEST] <hero_biz> @furq those which has lease change in frames. [21:48:29 CEST] <hero_biz> *least [21:48:37 CEST] <llogan> worstje: and what is "wrapped_avframe"? [21:49:16 CEST] <c_14> llogan: the format used by the yuv4mpegpipe muxer [21:49:26 CEST] <c_14> s/format/codec/ [21:49:28 CEST] <c_14> "codec" [21:50:25 CEST] <furq> hero_biz: i'm not aware of any way to do that but maybe i've missed something [21:50:30 CEST] <furq> -r certainly won't do that [21:51:33 CEST] <furq> personally i would just use yadif=0 and leave it at 30fps [21:51:44 CEST] <llogan> c_14: ah, it's new. less than 2 weeks old [21:51:57 CEST] <hero_biz> then people that rip a ts interlaced video and you normally always see 24000/1001 fps, they have just used -r to decerase fps? [21:52:31 CEST] <furq> i assume they've IVTC'd it [21:53:43 CEST] <hero_biz> what is that? [21:54:07 CEST] <furq> https://en.wikipedia.org/wiki/Telecine#Reverse_telecine_.28a.k.a._inverse_t… [21:55:28 CEST] <furq> it only makes sense for film content which has duplicated frames at 30fps [21:55:49 CEST] <furq> i live in a PAL region so i've never had much cause to use it [22:12:11 CEST] <worstje> Why is the libx264 encoder creating too much footage? I am expecting it to match the sound file (exactly 5s), but I am getting a bit more than 7.2s whenever I try to create a file using this cmdline: ffmpeg.exe -loop 1 -y -i image.png -i sound.wav -c:a libfdk_aac -shortest -vcodec libx264 -pix_fmt yuv420p result.avi [22:12:33 CEST] <worstje> Other encoders do in fact produce 5 seconds worth of footage. [22:14:40 CEST] <worstje> Command output is here: http://pastebin.com/7gZtSg3L [22:34:53 CEST] <muxan> hi i have a question about encoding into lossless(FLAC) specificly if the verification was ever implemented? [22:36:32 CEST] <deetwelve> Hello, I am using ffmpeg and rtmp to stream a file. Is there a command to start the file at a specific time? [22:43:35 CEST] <grublet> deetwelve: i dont know if it works for rtmp but you might want to try using -ss before the url [22:44:02 CEST] <grublet> if that doesn't work maybe someone else can help you [22:50:48 CEST] <deetwelve> i did try -ss with no luck [22:50:55 CEST] <deetwelve> thanks though [22:55:38 CEST] <onefix> So, anyone know if there are any scripts available to do split encoding using (for instance) and NFS share? [22:59:51 CEST] <onefix> I have a script built for TVHeadend to re-encode programs recorded from cable ... I would like to create an NFS share that I could point something like a Raspberry Pi to, it would determine the new encoding process and begin encoding 1 of many split files using a command of my determination [23:01:10 CEST] <buu> Your rpi is going to encode hd video? [23:08:21 CEST] <onefix> buu: Actually, a CHIP http://www.cnx-software.com/2015/05/08/chip-is-a-9-linux-development-board-… [23:09:36 CEST] <buu> What kind of fps do you get on that? [23:09:37 CEST] <muxan> alwinner bleh [23:10:26 CEST] <onefix> buu: It's a matter of scalability ... it may take 2 minutes to encode a 1 minute video on a CHIP, versus 30 seconds on a 6 core AMD ... but at $9 a piece, you could throw 10 of those at it for less than $100 [23:10:56 CEST] <buu> um. [23:11:10 CEST] <buu> Those numbers sound unlikely. [23:11:18 CEST] <muxan> totally [23:11:19 CEST] <buu> But it sounds hilarious, so good luck [23:11:33 CEST] <buu> Are you trying to chop a video into pieces? [23:11:44 CEST] <onefix> buu: How so? What kind of encoding times are we talking about? [23:12:59 CEST] <onefix> buu: Right, I envision splitting say a 15 minute video into 100 pieces and then letting the "cluster" encode ... then waiting for all of them to complete and merging them back together [23:13:07 CEST] <muxan> does ffmpeg use the official flac.exe to encode? [23:14:26 CEST] <buu> onefix: I'd guess a $100 amd would encode at about 8 times the speed of an rpi, but maybe there's fpga magic I don't know about [23:14:34 CEST] <onefix> buu: I gave up on hardware encoding a long time ago [23:14:54 CEST] <buu> But I adore the idea of clusters of pis [23:15:04 CEST] <DHE> ffmpeg doesn't use external apps typically. it would bundle a FLAC codec library [23:15:21 CEST] <onefix> buu: Yeah, but if the rPi was $9, (like the CHIP), you could run 10 of them for the same $100 [23:15:42 CEST] <buu> Yes, but you aren't going to run 10 of them for $100 [23:15:53 CEST] <buu> Not that you get the cpu for just 100, but anyway [23:16:00 CEST] <buu> onefix: The simplest case is that you're recording the cable show in a container that's splittable by a dumb program [23:16:11 CEST] <onefix> muxan: IT would likely use the same library that FLAC.exe uses, just like it uses libx264 for h.264 encoding [23:16:14 CEST] <muxan> i like to verify the encoded flac to the original. flac seems to use the -y flag for that [23:16:27 CEST] <onefix> buu: It is, it's MPEG2 TS [23:16:30 CEST] <buu> I think stuff like mpeg1/2 has very little look-ahead in the encoding [23:16:32 CEST] <muxan> is there something simular in ffmpeg? [23:16:54 CEST] <onefix> buu: It's coming directly from a HDHomerun [23:17:02 CEST] <muxan> onefiz, ah ok [23:17:34 CEST] <buu> hrm [23:17:55 CEST] <llogan> worstje: the paste link has been removed [23:18:25 CEST] <muxan> using the same lib doesn't always mean same features unfortunatly [23:18:44 CEST] <buu> Ok, mpeg2 is actually way more complicated than I realized [23:18:50 CEST] <onefix> buu: There is a script that processes the programs ... it runs COMSKIP to cut out commercials (if applicable), extracts closed captioning to a SRT file, and then reencodes to x264 + AAC and optionally resizes the video [23:19:18 CEST] <buu> onefix: So why not just have that encode the files? [23:19:30 CEST] <onefix> buu: There's also a test for cropping 480p video [23:19:32 CEST] <furq> onefix: for fun i just started a 1080p > 576p x264 encode on my rpi [23:19:51 CEST] <furq> i get about 65fps on an i7 920, on the rpi it's running at 2fps [23:19:55 CEST] <buu> haha [23:20:00 CEST] <furq> on an rpi2 clocked at 1.1ghz [23:20:10 CEST] <buu> Oh wait, you can't hardware encode [23:20:17 CEST] <buu> yeah that's just never going to go well [23:20:29 CEST] <furq> idk if it could use hardware but i'm not doing [23:20:48 CEST] <onefix> buu: It does, but I would like to see what I could make it do if all of my devices could start an encoding job ... presumably you could use Linux desktops and even Windows desktops to do the encoding if used CygWin [23:20:51 CEST] <buu> furq: I had a conversation about it in here a while ago, rpi and related things can have decoder chips but not encoder chips [23:21:01 CEST] <buu> onefix: dist-ffmpe [23:21:04 CEST] <buu> what fun [23:21:06 CEST] <furq> i don't have the decoders or anything installed anyway, i'm running it headless [23:21:29 CEST] <furq> but yeah it's an order of magnitude slower than a core 2 duo at stock clocks [23:21:30 CEST] <buu> furq: rpi2s come with a hardware x264 decocder, that's why they're able to play hd streams [23:21:54 CEST] <furq> i should point out it's reading from and writing to a cifs share, because obviously it's going to be even slower writing to sd [23:21:59 CEST] <furq> but i doubt that's making any difference at 2fps [23:22:14 CEST] <buu> That's a lot of rpis for your cluster. [23:22:23 CEST] <buu> furq: But just imagine if you had 80 of them. [23:22:28 CEST] <buu> It'd go like lightning. [23:22:45 CEST] <furq> you could probably do some pretty cool stuff with 80 rpis [23:22:49 CEST] <furq> but i don't think video encoding is one of them [23:22:57 CEST] <onefix> Yeah, the current box that I have doing the transcoding is a 6 core AMD ... I have built in use of a sqlite database and 2 /tmp files to do simultaneous encoding [23:23:10 CEST] <muxan> 80x2 160fps [23:23:13 CEST] <buu> simultaneous? [23:23:30 CEST] <buu> You know ffmpeg is threaded right [23:23:47 CEST] <furq> yeah x264 makes good use of multiple cores [23:23:48 CEST] <muxan> rpi 30$x80 is $2400 [23:24:03 CEST] <furq> muxan: don't forget the power adapters [23:24:09 CEST] <furq> unless you have a pc with 80 usb ports [23:24:11 CEST] <muxan> oops [23:24:35 CEST] <muxan> luckely usb stacks [23:25:05 CEST] <buu> haha [23:25:12 CEST] <onefix> buu: Yeah, but it's to account for the fact that I can be recording up to 3 programs at once ... you wouldn't want to hammer the system with 8 encode processes at once, so I have it run through the script and then delete the "lock file"...which throttles the encoding. [23:25:12 CEST] <buu> daisy-chained usb ports lighting your house on fire [23:25:25 CEST] <buu> ah [23:25:35 CEST] <buu> Recording cable is just so 2009 [23:25:56 CEST] <furq> it would probably be cheaper to just buy two more cheap amd systems [23:26:00 CEST] <furq> and much faster [23:26:12 CEST] <muxan> ive got an nice linux setup to record cable [23:26:19 CEST] <buu> This is clearly less fun furq [23:26:23 CEST] <onefix> buu: It sometimes means that programs take a while to transcode, but they are available in the "raw" mpeg2-ts stream until they are encoded to MKV files [23:26:27 CEST] <furq> oh yeah sorry i'm being no fun [23:26:39 CEST] <onefix> muxan: Using a HDHomeRun? [23:26:48 CEST] <muxan> most cable streams are mp4 prolly x264 anyway a simple copy will do [23:27:10 CEST] <buu> or you could just torrent the already encoded files -_- [23:27:22 CEST] <furq> are you recording three simultaneous programs constantly [23:27:22 CEST] <muxan> no settop box i mean [23:27:25 CEST] <onefix> buu: There's no fun in that :) [23:27:27 CEST] <furq> because it seems like you could just queue them up [23:27:37 CEST] <furq> +otherwise [23:27:53 CEST] <onefix> muxan: I'm pretty sure that cable is all still MPEG2-TS since that's what the HDHR outputs [23:28:34 CEST] <furq> also if this is progressive SD then you should be able to transcode them much faster than realtime [23:28:36 CEST] <muxan> well same copy applies [23:29:42 CEST] <muxan> a settop box like a dreambox or something records cable just fine without reencodes [23:30:11 CEST] <muxan> is prolly cheaper than rpi cluster [23:30:18 CEST] <TD-Linux> the raspberry pi actually has a hardware h264 encoder too. but it's trash [23:30:59 CEST] <onefix> furq: Well, that's what I 'm doing now...but presumably putting a CHIP or a rPi or another desktop on the encoding process should improve performance ... I'm not thinking that it will be as fast as a multi core x86 processor, but it should do something ... I also wonder what the cost vs performance difference would be between say a $500 6-core AMD box and 50 CHIPs [23:31:36 CEST] <furq> well if you already have a 6-core AMD box then that's cheaper [23:31:46 CEST] <TD-Linux> onefix, I've already done the math, basically zillions of cores wins [23:31:53 CEST] <TD-Linux> (x86 cores) [23:32:07 CEST] <TD-Linux> and generally intel beats AMD [23:32:19 CEST] <muxan> cheapes chips are rpi n they go $30 here [23:32:59 CEST] <TD-Linux> why am I even giving this advice [23:33:29 CEST] <DHE> anyone tried encoding with an Intel Phi? [23:33:31 CEST] <onefix> muxan: The CHIP is $9 and it comes with a 1GHz R8, 4GB Flash, 512GB RAM, WiFi, and Bluetooth [23:34:29 CEST] <muxan> i think 3 celerons beats a 100rpis [23:34:58 CEST] <muxan> n those chips of 1ghz too arm [23:35:50 CEST] <onefix> muxan: Yeah, the R8 is an ARM processor ... [23:35:59 CEST] <muxan> indeed [23:36:24 CEST] <muxan> a cheap celeron is prolly 150 [23:36:46 CEST] <muxan> like those chromebox you can mode to run linux [23:37:16 CEST] <muxan> modd* [23:37:43 CEST] <muxan> asus cn62 or so [23:38:14 CEST] <onefix> I'm going to try transcoding a 30 second MPEG2-TS video on a rPi, a CHIP, my 6-core AMD, and a 4-core Intel and comparing the speeds [23:39:07 CEST] <muxan> ill be interested in results [23:39:35 CEST] <muxan> who knows you may proof me wrong [23:39:59 CEST] <furq> http://sprunge.us/GYQY [23:40:11 CEST] <furq> that's what i get on an ntsc dvdr on an rpi2 at 1100mhz [23:42:04 CEST] <furq> compared to ~160fps on an i7 920 [23:44:13 CEST] <muxan> you have a 920 too? [23:44:21 CEST] <furq> i do [23:44:28 CEST] <muxan> what are the odds [23:45:07 CEST] <muxan> i guess bigger than with AMD [23:45:24 CEST] <onefix> Besides, I think the CHIP is really what the rPi should have been [23:45:56 CEST] <furq> the rpi would be a much nicer proposition if it had onboard emmc [23:46:05 CEST] <onefix> furq: https://www.kickstarter.com/projects/1598272670/chip-the-worlds-first-9-com… [23:46:12 CEST] <furq> the thing that really kills it is the sd card [23:46:21 CEST] <furq> 1gbit ethernet wouldn't go amiss either [23:47:01 CEST] <muxan> i got a cb2 for $10 more than rpi [23:47:26 CEST] <onefix> furq: The CHIP doesn't have an ethernet port builtin, it does USB OTG, WiFi, or Bluetooth out of the box [23:47:48 CEST] <muxan> but everyone jumped on the rpi bandwagon [23:48:50 CEST] <furq> i don't remember cubieboard's website being this bad [23:48:58 CEST] <onefix> muxan: Well, the CHIP is also newer ... the R8 is a 1GHz processor, vs the 700MHz processor on the rPi and it has 512M of RAM by default [23:50:34 CEST] <furq> the rpi2 is 900mhz and clocks easily to 1.1ghz [23:50:41 CEST] <furq> and it has 1gb ram [23:51:46 CEST] <onefix> furq: Yeah, but you still need to add an SD card to the rPi :) [23:51:55 CEST] <muxan> rpi are overrated [23:52:32 CEST] <furq> also i'm in the uk so the rpi is comparatively cheaper here [23:53:17 CEST] <onefix> furq: Well, not cheaper than $9 ... [23:53:24 CEST] <furq> that's why i said comparatively [23:54:04 CEST] <furq> i can't imagine the onboard storage on the CHIP is any good for that price [23:54:11 CEST] <furq> but it could hardly be worse than an sd card [23:54:27 CEST] <onefix> furq: It's NAND [23:54:38 CEST] <furq> i bought a pretty good toshiba uhs-i sd card and it's still terrible [23:56:08 CEST] <muxan> terrible compared to sammy 850 pro? [23:56:23 CEST] <furq> i think all sd cards are terrible for this job [23:56:50 CEST] <muxan> i guess you right [23:56:53 CEST] <furq> i wouldn't mind a SATA port on this thing either [23:57:04 CEST] <muxan> real time stuff is not for sd [23:57:07 CEST] <furq> one of these days i'll be bothered to get it running over iSCSI [23:57:58 CEST] <furq> neat, the chip is armv7 [23:58:15 CEST] <furq> that's a big selling point [23:58:18 CEST] <muxan> still anyone know how i can verify a flac encode? [23:58:38 CEST] <furq> do you mean a cd rip [23:58:46 CEST] <furq> you can use accuraterip but i don't know of a way to do it with ffmpeg [23:59:08 CEST] <muxan> yeah ive also got an old wavpack i want to mux [23:59:23 CEST] <muxan> but i need to be sure its errorless [23:59:30 CEST] <furq> cuetools is great for this but it's windows only [23:59:43 CEST] <furq> i think it runs in wine [23:59:58 CEST] <furq> http://www.cuetools.net/wiki/Main_Page [00:00:00 CEST] --- Fri Oct 23 2015

1 0

ffmpeg-devel.log.20151021
by burek 22 Oct '15

22 Oct '15

[00:32:17 CEST] <cone-732> ffmpeg 03Andreas Cadhalpun 07master:95687dc310ba: avutil: install des.h, rc4.h and tree.h as public headers [00:32:18 CEST] <cone-732> ffmpeg 03Andreas Cadhalpun 07master:3dfb643cd407: avcodec: remove unused avpriv_ac3_parse_header [00:32:19 CEST] <cone-732> ffmpeg 03Andreas Cadhalpun 07master:451b6a990a11: avutil: merge avpriv_float_dsp_init into avpriv_float_dsp_alloc [00:50:36 CEST] <cone-732> ffmpeg 03Tobias Rapp 07master:1ec8c1554ed8: avfilter/vf_psnr: Add support for writing stats to stdout [02:19:43 CEST] <BBB> are all statics inited to zero? [02:19:51 CEST] <BBB> I thought that was only true for static const (rodata stuff) [02:20:08 CEST] <wm4> yes all are [02:20:25 CEST] <wm4> const doesn't matter [03:27:09 CEST] <cone-732> ffmpeg 03Timothy Gu 07master:6b41b4414934: huffyuvencdsp: Convert ff_diff_bytes_mmx to yasm [05:26:55 CEST] <cone-732> ffmpeg 03James Zern 07master:6540fe04a3f9: libvpxenc: remove some unused ctrl id mappings [05:49:22 CEST] <Timothy_Gu> jamrial: so does the alignment requirement depend on coding of the opcode (VEX-/non-VEX-coded) or the width of the register [05:50:14 CEST] <Timothy_Gu> the instruction set reference just says "Legacy SSE" [05:50:21 CEST] <Timothy_Gu> versus "AVX" [05:51:43 CEST] <Timothy_Gu> oh that it's VEX-coded [05:52:01 CEST] <Timothy_Gu> "With the exception of explicitly aligned 16 or 32 byte SIMD load/store instructions, most VEX-encoded, [05:52:04 CEST] <Timothy_Gu> arithmetic and data processing instructions operate in a flexible environment regarding memory address [05:52:07 CEST] <Timothy_Gu> alignment, i.e. VEX-encoded instruction with 32-byte or 16-byte load semantics will support unaligned load [05:52:10 CEST] <Timothy_Gu> operation by default. " [05:58:01 CEST] <jamrial> yeah, it's the instruction encoding. "legacy sse" referers to that, not the size of the reg [06:31:29 CEST] <atomnuker> so far there have been no objections to adding Daala parsing support [06:31:50 CEST] <atomnuker> so unless someone here has something to say, I'm getting ready to push [06:53:11 CEST] <jamrial> atomnuker: just make sure to put the codec id in the right place, and bump libavcodec minor in the same commit [06:53:58 CEST] <jamrial> atomnuker: also, maybe bump libavformat micro in the oggparsedaala commit. but not minor [07:02:57 CEST] <cone-732> ffmpeg 03Rostislav Pehlivanov 07master:b7c9873bed7d: lavc: add AV_CODEC_ID_DAALA to the list of codec IDs and bump minor [07:02:58 CEST] <cone-732> ffmpeg 03Rostislav Pehlivanov 07master:0f87cbdd51f4: lavf: add oggparsedaala and bump micro [07:07:19 CEST] <atomnuker> my parser was tested by the other guy (who also added support for libdaala encoding & decoding) and it works [07:07:36 CEST] <rcombs> daala hype [07:08:16 CEST] <atomnuker> so, now a proper, full speed decoder which runs real time on my celeron can be started [07:10:17 CEST] <atomnuker> with copius amounts of assembly, 4 space indentations and nice C90 inlines everywhere [08:08:48 CEST] <fritsch> wm4: congrats to the new job - just seen it in the media - as you might know about the past (xbmc, plex) it was not a nice past at all - but yeah - they now did the right technical decision in hiring you. So congrats to this [08:23:34 CEST] <atomnuker> whaaaaat, wm4 has a job? what will happen to mpv? libass? all the great popcorn worthy arguments with cehoyos? [08:26:17 CEST] <fritsch> https://blog.plex.tv/2015/10/20/introducing-the-plex-media-player <- see [08:28:15 CEST] <rcombs> as you can see, there are no plans to stop development of libass or mpv :) [08:30:41 CEST] <atomnuker> I wasn't really concerned that :) [08:31:07 CEST] <rcombs> hey, with some companies it's a legit concern [09:05:13 CEST] <wm4> well the job is not that new [09:07:34 CEST] <nevcairiel> doesnt rcombs also work for plex, or do i misremember [09:07:42 CEST] <rcombs> yeah [09:13:09 CEST] <wm4> fritsch: anyway, thanks - yeah, xbmc and plex apparently had a bumpy past, but obviously they're getting better with open source [09:53:46 CEST] <fritsch> wm4: tomorrow today is already yesterday :-) so concentrate on the future [12:20:39 CEST] <kierank> wm4: congratulations I guess [12:46:31 CEST] <nevcairiel> this function pointer business is confusing [12:46:38 CEST] <nevcairiel> we use both "func" and "&func" in the source [12:46:47 CEST] <nevcairiel> both seem to work the same way [12:46:52 CEST] <nevcairiel> which one is more C-correct? [12:57:24 CEST] <nevcairiel> apparently both are equally valid in C [12:57:26 CEST] <nevcairiel> oh well [13:03:51 CEST] <wm4> isn't even &&&func valid? (don't quite remember) [13:47:53 CEST] <thardin> wm4: no, &&foo gets counted as the address of a local variable [13:48:09 CEST] <thardin> and &&&foo simply won't compile [13:55:31 CEST] <nevcairiel> if someone feels like reading overly verbose windows code, review my tls schannel patch =p [13:59:18 CEST] <__gb__> unary operator && is a GCC extension, that served the purpose of "computed gotos" [13:59:27 CEST] <__gb__> mainly used in the past to implement fast VMs [14:01:40 CEST] <__gb__> see literature for inline threaded dispatchers [14:01:45 CEST] <wm4> nevcairiel: oh, nice [14:05:15 CEST] <kierank> atomnuker: looking forward to http://www.theverge.com/2015/10/21/9575901/eurostar-new-train-design-pictur… ? [14:06:46 CEST] <J_Darnley> I was thinking those can't be Eurostar star trains they're too nice. Then I scroll down and see what they're really like. [14:07:18 CEST] <kierank> THERE IS A TRAC OUTAGE TONIGHT FROM 0000 - DON'T SAY YOU WEREN'T TOLD [14:11:02 CEST] <__gb__> what? no more Alsthom TGVs? [14:17:55 CEST] <kierank> they are a bit old [14:28:26 CEST] <cone-848> ffmpeg 03Hendrik Leppkes 07master:4da52e363034: aacdec: fix strict prototype warning [14:49:38 CEST] <j-b> kierank: they feel cheap. [14:51:16 CEST] <Daemon404> nevcairiel, re: 4da52e363034, i was aware, but i personally think that warning is stupid. [14:51:43 CEST] <nevcairiel> its 4 extra characters, so just add em :d [14:51:49 CEST] <nevcairiel> its just C being C [14:51:49 CEST] <Daemon404> does any compiler even care [14:52:04 CEST] <RiCON> nevcairiel: what about http://j.fsbn.eu/Kogc.txt [14:52:23 CEST] <Daemon404> RiCON, that is very wrong [14:52:27 CEST] <nevcairiel> also entirely unrelated [14:53:35 CEST] <RiCON> rtmpe works with schannel [14:54:34 CEST] <RiCON> (with gmp) [14:54:46 CEST] <nevcairiel> in any case, it should not link these without the user explicitly enabling them [14:54:57 CEST] <nevcairiel> we dont usually do that [14:55:28 CEST] <nevcairiel> hence why its tied to gnutls, since that adds deps on those libraries already anyway [14:55:34 CEST] <Daemon404> s/should not/must not/ [14:55:36 CEST] <Daemon404> it changes the license [14:56:03 CEST] <nevcairiel> i dont know whats gnutls license situation [14:56:22 CEST] <Daemon404> it has a transitive dep on lgplv3 [14:56:34 CEST] <Daemon404> so it requires --enable-v3 [14:56:34 CEST] <nevcairiel> configure doesnt seem to enforce that [14:56:46 CEST] <Daemon404> kinda wrong then [15:03:06 CEST] <RiCON> right, gmp depends on lgplv3 or gplv2 [15:09:38 CEST] <iive> there must be versions of gnutls that are not gplv3. do we support them? [15:16:57 CEST] <cone-848> ffmpeg 03Julian Scheel 07master:da43e9e157a3: mmaldec: Fix avpriv_atomic_get usage [15:19:14 CEST] <RiCON> nevcairiel: gcrypt is lgpl so that could be used? [16:01:47 CEST] <nevcairiel> the same limitation of not magically linking to an external library without user request applies, however [16:22:21 CEST] <nevcairiel> wm4: how well does mmal work if i just take yuv420p from it? still usable for realtime playback? [16:25:56 CEST] <wm4> low bitrate 720p just about works [16:26:27 CEST] <wm4> but normally the opaque format is needed, then 1080p bluray streams are no problem [16:26:47 CEST] <nevcairiel> i feared as much [16:33:41 CEST] <RiCON> nevcairiel: what would be the proper way of supporting ffrtmpcrypt then? find corresponding support for crypt stuff in schannel? [16:55:31 CEST] <nevcairiel> RiCON: you can still use gmp or gcrypt, just need to add an option to let the user specifically select it, instead of automatically using it [16:55:47 CEST] <nevcairiel> i dont think schannel exposes the required functionality [16:55:52 CEST] <nevcairiel> or any other windows component [17:00:29 CEST] <RiCON> i remember looking for it the first time you mentioned the patch [17:01:18 CEST] <RiCON> i think there is, but i couldn't tell for sure [17:24:52 CEST] <mateo`> i have a quick question regarding the h264 codec extradata, it is always stored in the avcC format ? [17:27:35 CEST] <nevcairiel> no [17:27:46 CEST] <nevcairiel> either either that or just the sps/pps in annexb format [17:27:50 CEST] <Compn> mateo` : in mp4 or other container ? [17:27:51 CEST] <nevcairiel> -either [17:28:18 CEST] <wm4> nevcairiel: what container stores it in annexb format? [17:28:18 CEST] <mateo`> Compn: in AVCodecContext.extradata [17:28:47 CEST] <nevcairiel> wm4: avi probably, but I was talking about what AVCodecContext can contain [17:29:04 CEST] <Compn> ... dont put h264 in avi [17:29:27 CEST] <wm4> avi? but of course! [17:29:35 CEST] <wm4> the container that fucks up everything [17:29:49 CEST] <Mavrik> MPEG2-TS is AnnexB [17:30:06 CEST] <nevcairiel> but that doesnt store extradata [17:30:18 CEST] <nevcairiel> not separately, anyway [17:30:32 CEST] <Mavrik> Yep. [17:30:37 CEST] <nevcairiel> but avformat will find it and extract it into AVCodecContext in AnnexB format, so you need to handle both [17:30:58 CEST] <nevcairiel> incidentally, you can usually use the format of the extradata to determine if the bitstream is annexb or mp4 [17:31:48 CEST] <mateo`> is there a function somewhere that determines which kind is it ? [17:32:08 CEST] <nevcairiel> if extradata[0] == 1 then avcC else annexb [17:32:12 CEST] <Mavrik> Doesn't libx264 give you headers in AnnexB in libx264.c as well? [17:32:31 CEST] <mateo`> nevcairiel: ok :) [17:43:04 CEST] <RiCON> nevcairiel: "just need to add an option to let the user specifically select it" <- can/must that be done without repeating the tests? [17:45:38 CEST] <ubitux> libavdevice/decklink_common.h:typedef struct AVPacketQueue { [17:45:40 CEST] <ubitux> ugh. [17:45:49 CEST] <ubitux> > decklink [17:45:52 CEST] <ubitux> > define AV* [17:47:42 CEST] <mateo`> nevcairiel: do you know if there is already a function that extract the pps/sps from the avcC extradata ? [17:49:59 CEST] <wm4> I don't think there's any reusable function, but some code does it [17:50:04 CEST] <wm4> like mp4toannex bsf [17:50:10 CEST] <wm4> or the h264 code itself [17:52:32 CEST] <mateo`> thanks, i'll look at mp4toannexb [17:56:52 CEST] <ubitux> michaelni_: lol, like that swamp mail leak? [17:57:22 CEST] <ubitux> nice, an fbi address [18:03:09 CEST] <BBB> ? [18:05:02 CEST] <RiCON> Daemon404: like this? http://sprunge.us/MUKB?diff (looks stupid) [18:05:42 CEST] <ubitux> BBB: https://continuousassurance.org/ [18:05:51 CEST] <ubitux> we tried this for ffmpeg a while ago [18:06:06 CEST] <ubitux> and i just received a mail from them about a security issue [18:06:23 CEST] <ubitux> but all their users are in CC [18:06:47 CEST] <ubitux> so we have many gov addresses, an fbi one, and some other interesting ones [18:06:59 CEST] <BBB> hahaha [18:07:05 CEST] <BBB> thats terrible [18:07:10 CEST] <ubitux> yes [18:07:12 CEST] <Gramner> hit reply all a few times to start an epic reply all chain that kills a few mail servers [18:07:13 CEST] <BBB> wordpress vuln btw [18:07:25 CEST] <BBB> omg [18:07:31 CEST] <BBB> like, dont they keep their software uptodate? [18:09:42 CEST] <kierank> ubitux: lol, yes [18:09:44 CEST] <kierank> saw that [18:56:25 CEST] <wm4> oh nice, git rebase now shows the rebase progress in comments when committing while rebasing (must be a new feature of git 2.6 or so) [19:34:03 CEST] <Timothy_Gu> "michael.e.snowden2.ctr(a)mail.mil" LOL [19:58:31 CEST] <Timothy_Gu> Gramner: any more comments on "https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181728.html" :) [20:30:54 CEST] <Gramner> Timothy_Gu: are you allowed to overread src in that code? [20:33:16 CEST] <Gramner> if you are, then you could implify the trailing part to read an entire register and just write out parts of it [20:33:21 CEST] <Gramner> simplify* [20:40:24 CEST] <Timothy_Gu> Gramner: idk but the original code didn't so I assumed no [20:40:42 CEST] <Gramner> fair enough [20:41:48 CEST] <Gramner> ok, should be fine. it'd be nice if you could make a checkasm test though [20:58:51 CEST] <atomnuker> kierank: I still dislike the eurostar [20:59:24 CEST] <atomnuker> "Let's make it as close as possible to an aeroplane flight, including all the bad stuff like security and price!" [21:00:23 CEST] <atomnuker> they even check your passport twice at gare du nord [21:00:52 CEST] <Plorkyeran> everything but the speed of a plane [21:01:18 CEST] <atomnuker> like, the booths are less than 25 meters apart in a straight walkway [21:01:57 CEST] <atomnuker> what's the worst that can happen if you have a gun on the eurostar? [21:02:13 CEST] <BBB> ... [21:02:40 CEST] <atomnuker> "I'm derailing this train (with survivors) because I don't know how to control my speed!" [21:03:05 CEST] <atomnuker> "Only the stewardess cared who I was until I pulled out my gun!" [21:03:20 CEST] Action: J_Darnley resists the urge [21:04:36 CEST] <atomnuker> "The passenger list has me, the stewardes and some doctor, but only one of you! First one to talk spares himself a few broken bones and a concussion by not gettin thrown out!" [21:05:12 CEST] <J_Darnley> Lotta loyalty for a hired cleaner! [21:05:23 CEST] <atomnuker> Suddenly another eurostar train pulls up on the other side [21:05:36 CEST] <atomnuker> Must be someone on the inside since the stopped any train on those rails [21:05:49 CEST] <J_Darnley> *turbulence intensifies* [21:06:50 CEST] <J_Darnley> "At least you can talk." [21:07:23 CEST] <J_Darnley> DaMN i MISSED A LINE [21:07:33 CEST] Action: J_Darnley has fat fingers today [21:07:47 CEST] <atomnuker> I think another Speed sequel except with a train would be awesome [21:08:17 CEST] <atomnuker> Speek 4 could explore the dangers of a hijacked submarine [21:08:21 CEST] <atomnuker> *Speed [21:08:46 CEST] <Plorkyeran> which somehow plows through an island [21:08:52 CEST] <atomnuker> There would be no need for a Speed 5 since there already was a Speed knockoff with Liam Neeson on a plane [21:08:53 CEST] <Gramner> Speed 5: a mars rover [21:09:00 CEST] <atomnuker> that could work [21:09:20 CEST] <durandal_1707> starring k. K. [21:10:58 CEST] <atomnuker> written by Philip K. Dick and directed by Cronenberg [21:21:41 CEST] <Timothy_Gu> Gramner: ok i'll take a look at it [21:26:17 CEST] <cone-848> ffmpeg 03Timothy Gu 07master:5e586e1befaa: huffyuvencdsp: Add ff_diff_bytes_{sse2,avx2} [21:34:28 CEST] <Timothy_Gu> should I add Reviewed-by lines? [21:35:16 CEST] <jamrial> Timothy_Gu: you didn't push the fixed version [21:41:12 CEST] <Timothy_Gu> jamrial: wat [21:41:15 CEST] <Timothy_Gu> oops [21:43:19 CEST] <cone-848> ffmpeg 03Timothy Gu 07master:98da061461f5: huffyuvencdsp: Cherry pick changes left out in the last commit [21:43:29 CEST] <Timothy_Gu> ok fixed [22:02:54 CEST] <pico4743> I'm having problems with mp3 headers written by ffmpeg re:joint_stereo and I've found the offending place in mp3enc.c, but a repair does not look simple. Is this the place to discuss this? [22:04:22 CEST] <J_Darnley> pico4743: if you want to try fixing it yes, people can probably guide you [22:04:38 CEST] <J_Darnley> If you just want to make a bug report, do that on trac [22:05:20 CEST] <pico4743> I'm willing to help, but new to your code. on this one I could get in over my head, methinks [22:07:29 CEST] <pico4743> I guess I'll start on trac. thanks [22:08:00 CEST] <J_Darnley> Yes, a bug report is probably a good start [22:08:30 CEST] <J_Darnley> it lets you post long paragraphs of text with a record of what's been said [22:09:53 CEST] <pico4743> Am I understanding that trac is a mailing list? I subscribe and then send email to ffmpeg-trac(a)avcodec.org? [22:10:00 CEST] <J_Darnley> no and no [22:10:09 CEST] <J_Darnley> http://trac.ffmpeg.org/ [22:10:29 CEST] <J_Darnley> oh wait, who owns that domain name? [22:10:50 CEST] <J_Darnley> oh it redirects to ffmpeg.org [22:11:13 CEST] <pico4743> no redirect for me. [22:11:51 CEST] <J_Darnley> The Trac software might send emails from that address. [22:12:37 CEST] <pico4743> oh, you mean the avcodec.org. yeah what I was seeing was from https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-trac/ [23:06:29 CEST] <Gramner> http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_window… that's pretty interesting [23:06:46 CEST] <nevcairiel> i saw their talk on cppcon, it definitely is [23:07:03 CEST] <nevcairiel> will have to see about getting ffmpeg to build with that [23:08:14 CEST] <Gramner> shouldn't be too much of an issue I think, msvc2015 is pretty decent standards-wise and I doubt that would make it worse [23:08:26 CEST] <nevcairiel> yeah likely just some build system dealing [23:08:53 CEST] <Gramner> maybe we can finally get inline asm on x86-64 then [23:11:56 CEST] <nevcairiel> thats one of my hopes as well [23:12:11 CEST] <nevcairiel> not only that, but also on x86, since msvc doesnt understand the current syntax [23:13:42 CEST] <kierank> THERE IS A TRAC OUTAGE TONIGHT [23:13:59 CEST] <kierank> DO NOT COMPLAIN AND SAY YOU WEREN'T TOLD (mumble mumble certain people) [23:14:12 CEST] <J_Darnley> WHO EVEN USES TRAC? [23:14:33 CEST] <kierank> I AM TRYING TO MAKE IT REALLY REALLY CLEAR TO certain people (tm) [23:14:57 CEST] <kierank> The fibre is being rerouted to make way for the Northern Line [23:15:00 CEST] <wm4> nevcairiel: random question, does buffering dxva2 decoding help? i.e. does it inflict a high latency [23:15:41 CEST] <nevcairiel> wm4: you mean like keeping a couple frames in a circle buffer before further processing them? [23:16:01 CEST] <wm4> well, I just read them back to CPU immediately [23:16:05 CEST] <nevcairiel> (ie. common pipelining) [23:16:17 CEST] <nevcairiel> you wont like the answer though [23:16:33 CEST] <nevcairiel> it helps nvidia, hurts intel [23:16:39 CEST] <nevcairiel> no clue about amd [23:16:39 CEST] <nevcairiel> :D [23:16:42 CEST] <wm4> lol [23:17:17 CEST] <nevcairiel> i think it helps nvidia because they do a DMA for you [23:17:34 CEST] <wm4> well, I'm not buffering anything (because normally ffmpeg multithreaded decoding does this), so I guess I should add some more threads [23:17:50 CEST] <nevcairiel> you dont need threads for that [23:18:05 CEST] <nevcairiel> just keep an array of AVFrames and circle 2 through that [23:18:35 CEST] <wm4> I see [23:18:38 CEST] <nevcairiel> that alone can give you a 50% decoding performance boost [23:19:38 CEST] <nevcairiel> but dont do it on intel gpus, for some reason it makes them slower [23:19:50 CEST] <nevcairiel> (although not much, while the speedup for nvidia is real) [23:20:51 CEST] <wm4> why does it hurt intel? [23:21:03 CEST] <nevcairiel> if i knew [23:21:32 CEST] <cone-848> ffmpeg 03Tobias Rapp 07master:18e8fac531cb: avfilter/vf_ssim: Add support for writing stats to stdout [23:21:40 CEST] <nevcairiel> the difference for intel wasnt that big though, maybe 10% [23:21:52 CEST] <nevcairiel> and their recent decoders are all really fast [23:25:14 CEST] <nevcairiel> intel also really needs one of those movntdqa custom memcpys to be fast [23:25:38 CEST] <nevcairiel> well, amd too [23:26:10 CEST] <BBB> kierank: do you remember that vp9 ticket where the file eats all your memory? [23:29:29 CEST] <kierank> BBB: https://trac.ffmpeg.org/ticket/4935 [23:30:16 CEST] <BBB> ty [23:43:18 CEST] <atomnuker> kierank: what's happening with the northen line? [23:43:42 CEST] <kierank> they are digging near/under the office so the fibre is getting rerouted [23:43:58 CEST] <atomnuker> so you got like a letter telling you that? [23:44:10 CEST] <kierank> yes, an email [23:44:15 CEST] <kierank> I forwarded it to ffmpeg-devel [23:44:34 CEST] <J_Darnley> Oh I remember seeing that [23:44:35 CEST] <kierank> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180554.html [23:44:47 CEST] <J_Darnley> I didn't put that and this together though [23:45:26 CEST] <atomnuker> virgin actually give out gigabit fiber too? [23:45:32 CEST] <atomnuker> they're too big now [23:45:35 CEST] Action: nevcairiel will giggle in the morning at the outraged comments about how trac was down and noone was told [23:46:19 CEST] <kierank> atomnuker: it's a virgin point to point link I believe [23:46:22 CEST] <atomnuker> I bet you need like a special license from the government to even rent out fiber here, let alone host stuff on it [23:46:28 CEST] <kierank> from the office to our isp PoP [23:46:54 CEST] <kierank> I don't have a licence [23:47:16 CEST] <kierank> I have a contract that allows the fibre to pass through the building [23:48:17 CEST] <kierank> avdev will go down as well (Timothy_Gu might affect you) [23:48:21 CEST] <kierank> possibly BBB as well [23:48:25 CEST] Action: J_Darnley loves the monopoly on fibre that got renewed here [23:50:27 CEST] <atomnuker> I'm not sure how to feel about extending the Northern line [23:50:56 CEST] <kierank> not sure why the trac server rebooted yesterday [23:50:59 CEST] <kierank> looks like someone did [23:51:44 CEST] <atomnuker> I bet this extension was made by the same guys who though it would be a good idea to have the circle line not make a circle [23:51:59 CEST] <thardin> hrm, that mxfdec patch [23:55:32 CEST] <kierank> atomnuker: why [23:55:44 CEST] <kierank> we lack tube connectivity here [00:00:00 CEST] --- Thu Oct 22 2015

1 0

ffmpeg.log.20151021
by burek 22 Oct '15

22 Oct '15

[00:02:39 CEST] <sor_> anYc, it would appear to be a problem with ffplay [04:54:06 CEST] <sor_> anYc, I figured the problem out sorry for all the trouble, it work snow with ffmpeg and your cool program that i am going to add to my /bin... thanks again [05:44:33 CEST] <Renari> I'm trying to convert a series of images to a video [05:44:35 CEST] <Renari> ffmpeg -framerate 24 -i AM_TOZ_OP_001%04d.png -c:v libvpx-vp9 -pix_fmt yuv420p -b:v 6000k out.webm [05:44:53 CEST] <Renari> Can someone tell me why when using this command the output bitrate is 3k and not 6k? [05:49:45 CEST] <relaxed> Renari: did you see https://trac.ffmpeg.org/wiki/Encode/VP9 ? [05:50:10 CEST] <relaxed> maybe it can't use that many bits [05:51:12 CEST] <Renari> Hm, I'll try that then. Thanks. [06:35:54 CEST] <ibrahim_> hi, good morning i followed step found in hear `https://trac.ffmpeg.org/wiki/CompilationGuide/Centos` but i have an error in this picture `http://imgur.com/08VFwoy` [06:37:55 CEST] <ibrahim_> in breif the compile of ffmpeg without `--enable-libvpx` succeeded and with '--enable-libvpx' fails [06:38:13 CEST] <ibrahim_> so i googled alot but no lick [07:38:34 CEST] <ibrahim_> hey anybody here [07:42:21 CEST] <relaxed> ibrahim_: there were some changes in libvpx git that broke support. You can download 1.4.0 or try git again in a few days. [07:43:53 CEST] <ibrahim_> @relaxed: i tried libvpx-1.4.0.tar.bz2 but give me the same error [07:44:28 CEST] <ibrahim_> from here `http://www.linuxfromscratch.org/blfs/view/svn/multimedia/libvpx.html` [07:44:58 CEST] <relaxed> ibrahim_: run make clean; make distclean in ffmpeg and try again [07:45:40 CEST] <ibrahim_> ok i will try again i let you know the result [07:45:43 CEST] <ibrahim_> thanks [07:46:54 CEST] <relaxed> ibrahim_: also make sure you removed the files installed from libvpx git [07:48:27 CEST] <ibrahim_> @relaxed: how can i know the files installed form libvpx git [07:48:52 CEST] <relaxed> what prefix did you use to install? [07:49:38 CEST] <relaxed> my static builds have libvpx support, http://johnvansickle.com/ffmpeg/ [07:49:52 CEST] <ibrahim_> --prefix="$HOME/ffmpeg_build" [07:51:11 CEST] <relaxed> if you don't mind to start over, rm -rf $HOME/ffmpeg_build/* [07:51:39 CEST] <ibrahim_> ok i will [07:51:50 CEST] <ibrahim_> thanks @relaxed: [09:04:46 CEST] <anYc> sor_: thanks for trying! I'll check if I can reproduce it with ffplay [09:57:02 CEST] <Mysoft> so, i'm trying to decode a cineform video... (on windows) any directshow based video player... can play it... since i have the propietary encoder installed... but how can i make ffmpeg to use that codec to decode the video? or any other tool that i can use from command line to decode it and pass to ffmpeg... [10:23:19 CEST] <kahrl> hi, when converting a stream to mp4, I can't play back the video until ffmpeg is done converting [10:23:35 CEST] <kahrl> while ffmpeg is converting, mpv says: [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: moov atom not found [10:24:08 CEST] <kahrl> is there a switch so ffmpeg periodically writes a moov atom so I can watch the video while it is still converting? [10:25:17 CEST] <kahrl> (or writes it once at the beginning, assuming that would be sufficient) [10:26:08 CEST] <Anoia> kahrl: it will have a moov atom, but I expect it'll be truncated (not finished writing yet) so the viewer ignores it [10:26:25 CEST] <Anoia> IIRC, the moov contains each frame [10:26:30 CEST] <kahrl> I see [10:26:39 CEST] <Anoia> or is taht AVIs... [10:47:13 CEST] <c_14> kahrl: you can use moov_fragment (or whatever the fflag is called) to create a fragmented moov atom (many players won't support that though) [10:47:59 CEST] <c_14> ie -movflags frag_keyframe [10:49:58 CEST] <kahrl> ah nice. I also thought about trying -f ismv [10:50:21 CEST] <kahrl> now my problem is that I don't actually know how to get youtube-dl to pass these options on to ffmpeg, but that's offtopic for here [10:51:29 CEST] <Mavrik> kahrl, why not use mpegts? [10:51:44 CEST] <Mavrik> It's built for streaming and will play immediately. MP4 MOOV just cannot be generated before the file is done. [10:53:24 CEST] <kahrl> Mavrik: thanks, I'll try that as well [10:56:43 CEST] <Mysoft> ok fixed my problem using avysynth as input... altough directshow decoding the 4k is using 700mb and encoding a 4k video with too many reference frames makes it blown my 2gb limit :D [10:56:48 CEST] <Mysoft> thanks anyway [11:00:47 CEST] <hero_biz> guys [11:02:17 CEST] <hero_biz> i want to just deinterlace and scale a 1080i .ts file (1440x1080). is following command correct: [11:02:19 CEST] <hero_biz> ffmpeg -i file.ts -vf "yadif=1,scale=1280x720" -sws_flags lanczos out.mkv [11:04:28 CEST] <Mavrik> hero_biz, might wanna copy the audio track so you won't reencodfe [11:04:38 CEST] <Mavrik> hero_biz, and set video codec and CRF explicitly for quality. [11:06:44 CEST] <hero_biz> marviv, I did this on purpose so I could encode video later with x264. but I will add audio. [11:06:56 CEST] <hero_biz> but my main problem is that: [11:07:25 CEST] <hero_biz> 1- scaling to 1280x720 will be correct?or it will be considered as upscale? [11:07:53 CEST] <hero_biz> 2- is my yadif option correct? what is best approach for deinterlaceing? [11:08:28 CEST] <hero_biz> i have seen people use "yadif=3:1,mcdeint=2:1" for deinterlacing too. [11:10:13 CEST] <Mavrik> Yadif is fine. [11:10:24 CEST] <Mavrik> And I don't understand your "I'll encode later" comment. [11:10:30 CEST] <Mavrik> If you mess up the quality here, no encoding later will fix it. [11:11:02 CEST] <hero_biz> I need to encode video here? [11:11:10 CEST] <hero_biz> while deinteracing? [11:11:12 CEST] <c_14> Unless you output rawvideo, yes. [11:11:32 CEST] <c_14> ffmpeg "always" encodes output [11:11:55 CEST] <hero_biz> unless i use -c:v copy? [11:13:03 CEST] <hero_biz> i hav never deinterlaced a video before, then I don't know its process exactly. [11:13:04 CEST] <c_14> You can't use that when filtering the video [11:13:14 CEST] <hero_biz> oh [11:13:21 CEST] <c_14> In order to apply a video filter to a video, ffmpeg has to decode the video. [11:13:32 CEST] <c_14> Unless you then output the decoded rawvideo, you need to reencode it to something. [11:14:12 CEST] <hero_biz> then how you encode to something that can be encodd with x264 later? [11:15:07 CEST] <Mavrik> hero_biz, of course you have to encode the video [11:15:20 CEST] <Mavrik> you can't deinterlace encoded video, frames change afterall. [11:16:36 CEST] <hero_biz> what should i use for encoding too? [11:16:52 CEST] <hero_biz> i saw a commaand like this for video deinterlacing too: ffmpeg -i file.ts -vf "yadif=0:0:0,scale=1280x720" -sws_flags lanczos -f yuv4mpegpipe -pix_fmt yuv420p - | x264_64.exe --stdin y4m --level 3.1 --output output.mkv - [11:17:28 CEST] <hero_biz> so i thought maybe i can save ffmpeg result to a file and then use x264 on resulting file. [11:17:50 CEST] <Mavrik> Is there a reason you don't wanna do that in a single step? [11:18:09 CEST] <Mavrik> Since it'll cause you significantly less problem, storing raw video takes up a huge amount of space and brings a ton of problems. [11:18:15 CEST] <hero_biz> my ffmpeg is not compiled with libx264 [11:18:40 CEST] <hero_biz> so i thought to use x264 for video later. [11:20:01 CEST] <hero_biz> any good option to preserve quality in ffmpeg so I could encode it later again? [11:21:49 CEST] <relaxed> hero_biz: http://johnvansickle.com/ffmpeg/ [11:26:48 CEST] <hero_biz> ty for link relaxed, but sadly my kernel is too old for it :D [11:35:00 CEST] <hero_biz> encoding with this command is not good idea? ffmpeg -i file.ts -vf "yadif=0:0:0,scale=1280x720" -sws_flags lanczos -f yuv4mpegpipe -pix_fmt yuv420p - | x264_64.exe --stdin y4m --level 3.1 --output output.mkv - [11:38:19 CEST] <Mavrik> It still doesn't set quality. [11:38:29 CEST] <Mavrik> And you're piping stuff through for no apparent reason. [11:38:40 CEST] <Mavrik> Just burning CPU. [11:40:20 CEST] Action: hero_biz had copy/paste it from what has found in internet. [11:40:41 CEST] <hero_biz> marvik, what will you use as command if you don't have libx264? [11:41:06 CEST] <hero_biz> i mean ffmpeg is not compiled with libx264? [11:46:41 CEST] <Mavrik> You compile ffmpeg with libx264. [11:46:43 CEST] <Mavrik> You got a link. [11:47:20 CEST] <hero_biz> hm.....k,k :) [11:47:27 CEST] <hero_biz> I willl recompilel again [11:48:01 CEST] <Mavrik> Trust me, way easier than alternatives. [11:48:07 CEST] <Mavrik> Get fdk_aac while you're at it. [11:48:19 CEST] <n_tish> Hie all, I have one issue. When I try to load native libavcodec.so libavformat.so libavutil.so in Android I get the Relocation error. The android OS is M and the target is 23. [11:48:56 CEST] <hero_biz> @marvik, I compiled it with fdk_aac [11:49:21 CEST] <hero_biz> my compilation is this: configuration: --enable-shared --enable-openssl --disable-ffplay --enable-libfdk-aac --enable-libmp3lame --enable-libopus [11:49:33 CEST] <n_tish> the error is "java.lang.UnsatisfiedLinkError: dlopen failed: /data/app/com.my.application/lib/arm/libav.so: has text relocations " [11:52:45 CEST] <benbro> anYc: now avcut run without errors [11:53:13 CEST] <benbro> but there is a gap between the first and middle parts (maybe end as well, didn't check) [11:53:21 CEST] <benbro> maybe you are skipping a keyframe? [12:00:06 CEST] <benbro> anYc: ok. the API let you drop parts. I thought that you choose what part to keep [12:00:12 CEST] <anYc> hm, at least at the end there shouldn't be missing frames as I compared the last frames of the input and output video yesterday [12:00:40 CEST] <benbro> anYc: what if I have 60 seconds and I want to keep only 40 seconds in the middle? [12:00:55 CEST] <benbro> do I need to drop the last part with exact frame accuracy? [12:01:13 CEST] <benbro> or can I just leave the last part and avcut we'll fill it for me? [12:01:29 CEST] <benbro> avcut in.mp4 out.mp4 0 10 50 60 [12:01:30 CEST] <anYc> ah ok. you use "0 10 50 60" to drop the first and last 10 seconds. But I'm thinking about adding a switch to accept a "whitelist" [12:01:45 CEST] <benbro> anYc: a whitelist will be nice [12:01:49 CEST] <benbro> maybe: [12:01:57 CEST] <benbro> avcut in.mp4 out.mp4 0 10 50 [12:02:12 CEST] <benbro> will automatically expand the last part to the exact video length? [12:02:20 CEST] <anYc> in your case it would be: out.mp4 10 50 [12:02:38 CEST] <benbro> in whitelist but how do I do it with blacklist? [12:02:56 CEST] <benbro> the last part has to match the exactu duration or will you expand it automatically? [12:03:07 CEST] <benbro> "avcut in.mp4 out.mp4 0 10 50" last part is missing. avcut could guess it [12:03:18 CEST] <benbro> maybe "avcut in.mp4 out.mp4 0 10 50 -" [12:03:29 CEST] <benbro> or "avcut in.mp4 out.mp4 0 10 50 end" [12:03:38 CEST] <anYc> right now you have to provide a sufficiently large last value if you don't know the exact length, e.g., you can write "50 99999" to drop all frames after 50 seconds [12:03:49 CEST] <benbro> ok [12:03:56 CEST] <anYc> yeah, I also thought about using "-" or something similar [12:04:01 CEST] <benbro> whitelist will be useful [12:04:14 CEST] <benbro> I'll test it with my videos. [12:04:44 CEST] <benbro> my python script has an issue where I combine the parts so yours probably better :) [12:04:53 CEST] <benbro> cutting takes a bit of time [12:05:04 CEST] <benbro> is it because you extract all the frames? [12:05:19 CEST] <benbro> maybe you can just extract the frame info around the borders? [12:05:52 CEST] <benbro> "avcut in.mp4 out.mp4 20 40" -> you only need the info near 20 and near 40 [12:05:52 CEST] <anYc> ok, thank you! Yes, I also think decoding takes the biggest part. I was thinking about some optimizations but I tried to get it to work first [12:06:01 CEST] <benbro> cool [12:06:17 CEST] <benbro> do you expect it to be stable now? [12:08:28 CEST] <anYc> I only tested it shortly with three videos yesterday as I had to go to bed but with those it worked flawlessly [12:08:49 CEST] <anYc> but I wouldn't delete the original videos yet ;) [12:08:53 CEST] <benbro> ok [12:11:02 CEST] <anYc> I will also test the result with more players. As avcut sometimes has to change the format to mix frames from different encoding sessions there might be players that don't like this [12:14:06 CEST] <benbro> different encoding in the same file? [12:19:17 CEST] <anYc> different encoding sessions. I don't know much about the actual h264 internals but some parameters of the encoder cannot be read from the input file and I had to set them manually (like quality). Hence, the extradata ("header" data) might differ between the copied and the new encoded frames [12:21:24 CEST] <anYc> it seems like at least mplayer, mpv and vlc don't have an issue with it [12:21:57 CEST] <anYc> for me it's also important that they work with kodi (xbmc) [12:42:59 CEST] <pgunnars> yo [12:51:48 CEST] <yongyung> Does someone here have a prebuilt 64 bit Windows built of ffmpeg with all the "usual" libs (like http://ffmpeg.zeranoe.com/builds/) but with libfdk_aac? [12:51:58 CEST] <yongyung> -t +d [12:52:50 CEST] <pgunnars> I'm slicing a segment out of a video stream I'm playing with ffserver, how can I get the segment to include a duration? [12:54:53 CEST] <c_14> yongyung: FFmpeg built against libfdk_aac is non-redistributable [12:56:01 CEST] <yongyung> c_14: That's why I'm asking here, I guess ;) Building it myself is going to be a pita... [13:05:00 CEST] <pgunnars> can any1 help me with my question? [13:05:55 CEST] <pgunnars> ffserver outputs a stream (so no set duration), but I'm slicing out a specific segment with -t duration. What I need is for that video slice to have a duration field, doesn't come automatically [13:06:44 CEST] <bove> Can a concat list hold multiple streams (video and audio) on each line? [13:08:50 CEST] <pgunnars> is it possible to just set the video length to duration? [13:11:33 CEST] <pgunnars> fprobe -i birds.mp4 -show_format -v quiet | sed -n 's/duration=//p' just gives me N/A [13:36:40 CEST] <benbro> anYc: maybe we can pass these paramters that you can't read manually in the command line? [13:54:23 CEST] <anYc> good idea, yes [14:57:05 CEST] <__jack__> ffmpeg -i ... -hls_ts_options fix_teletext_pts=0 output.m3u8 : what's wrong with that ? [14:57:35 CEST] <__jack__> (http://pastebin.com/qWLnwvrf) [15:32:26 CEST] <pgunnars> how can a video file not know its duration [15:32:30 CEST] <pgunnars> it knows the framerate [15:32:35 CEST] <pgunnars> it must know the amount of frames rightÞ [15:32:36 CEST] <pgunnars> ? [15:32:39 CEST] <BtbN> No. [15:33:08 CEST] <pgunnars> how can I let it know the amount of frames [15:33:16 CEST] <BtbN> Parse the entire file and count. [15:33:54 CEST] <pgunnars> can I then tell the file how many frames it has? [15:34:16 CEST] <BtbN> Not neccesarily. [15:34:32 CEST] <BtbN> Depends entirely on the container which kind of metadata it supports. [15:34:37 CEST] <pgunnars> webm [15:36:20 CEST] <pgunnars> can i do it then? [15:57:32 CEST] <pgunnars> any1 know how I can simulate ffserver output stream, so I can create tests for ffmpeg execution with ?date on the stream [16:33:49 CEST] <phibonacci> Hello. My old MP3 player, an Archos that supports mp3, ogg, flac, can't read one of my FLAC songs so I converted it in ogg with FFmpeg but it reads it as a 15mn long song even so it's 5mn long. Do you have any idea what could create this issue and how to fix it? Everything works fine with both the FLAC and ogg on VLC. [17:26:01 CEST] <sor_> anYc, I figured the problem out sorry for all the trouble, it work snow with ffmpeg and your cool program that i am going to add to my /bin... thanks again [17:40:34 CEST] <brbblnch> hello [18:03:13 CEST] <dot> hello, why doesnt video size work in this case: ffmpeg -f avfoundation -i "<screen device index>:<audio device index>" out.mov [18:03:33 CEST] <dot> even tough I set this: -video_size 1280x720 [18:30:01 CEST] <worst[je]> I am trying to adapt a script I found online which should be ready to interact with the exact kind of files I'm using it on to adapt it to my needs. However.. it does not seem to work to begin with. Can someone point out where the problem lies? http://pastebin.com/zS8rGVnw [18:42:58 CEST] <sor_> worst[je], it's not that you don't have the codec it's that it is using "incorrect codec parameters" -- i would say this is a clue "deprecated pixel format used, make sure you did set range correctly" -- my guess would be you are converting compressed to raw uncompressed and they are incompatible formats [18:45:14 CEST] <c_14> Nah, you can ignore that warning. [18:48:02 CEST] <worst[je]> I wouldn't know how to improve the parameters though. They are indeed gigantic raw files in a sense.. I know Windows needs a special codec in order to have media players and editing software interact with them, but that's about as far as it goes. All I know for sure is that people have used the commandline I used in that script successfully in the past, so I am pretty certain it ought to be [18:48:03 CEST] <worst[je]> possible somehow.. my best guess right now is that ffmpeg may have seen some development or default settings change which screws it over. [18:51:20 CEST] <c_14> Get rid of the -c:v rawvideo [18:51:59 CEST] <c_14> (Or set it to wrapped_avframe) [18:54:03 CEST] <worst[je]> A quick command line tests brings a lot of garbledeegook, so looks good! Will throw it into the script and see how the results come out, but I assume it ought to be fine as this involves the reading and not the output part of the command. :) Thanks! [19:10:02 CEST] <brontosaurusrex> Can I use alac in mp4 with AVC video? [19:12:18 CEST] <c_14> I think you have to use the mov muxer [19:13:55 CEST] <brontosaurusrex> c_14: thanks [20:15:48 CEST] <worst[je]> Suppose I have a set of AVI files. I want to concatenate and x264 re-encode these to eventually put them into a mp4 container. Should I re-encode all my files separately and then find a way to concatenate them whole, or should I first concatenate them all and then encode them in a single go? Since I have the first half of the former figured out, I'd prefer that, but then I am not sure which [20:15:48 CEST] <worst[je]> concat option to use.. demuxer is my guess? So much to learn. [20:18:48 CEST] <durandal_1707> there is concat filter [20:21:58 CEST] <worst[je]> Right, but that says 'if you want to re-encode' when I check the FAQ. Since in that case (encode separately first, concatenate second) I am already done with all the encoding, I obviously wouldn't want to make ffmpeg re-encode it and shit all over the hard work x264 did, right? [20:25:45 CEST] <durandal_1707> you can concat and after that encode [20:26:10 CEST] <durandal_1707> In one command [20:27:02 CEST] <aargh> hi all [20:27:47 CEST] <aargh> i have a question (hopefully a simple one) about ffmpeg command line options [20:28:48 CEST] <aargh> i have a stereo mp2 source, but when converting to mp3 the output becomes joint stereo [20:29:12 CEST] <aargh> how can i force stereo output? [20:29:51 CEST] <JEEB> it is stereo IIRC, just a method of coding it. the mode is IIRC defined by the encoder library, so you should try raising the bit rate [20:30:02 CEST] <durandal_1707> look at encoder options [20:30:09 CEST] <JEEB> and that, if it exists [20:30:44 CEST] <durandal_1707> ffmpeg -h encoder libmp3lame [20:30:48 CEST] <aargh> bitrate is 256k source and i specify 256k out [20:31:28 CEST] <aargh> hmm, i'll try that, durandal_1707. thanks [20:31:40 CEST] <JEEB> then it might just be a setting. that said I have no idea why you'd be recoding it like that [20:31:48 CEST] <durandal_1707> the options are also documented [20:31:59 CEST] <JEEB> lossy and then some more lossiness without anything gained [20:32:35 CEST] <aargh> yeah, the options are documented. but not necessarily intelligible [20:33:20 CEST] <durandal_1707> they should be simple to understand [20:33:52 CEST] <aargh> if they were simple, i wouldn't be here. but i do thanks you for the response [20:35:08 CEST] <hero_biz> guys. how I can compile ffmpeg with 10 bit support? I need to compile x264 as 10 bit and then use its library to build ffmpeg? [20:35:18 CEST] <JEEB> yes [20:35:46 CEST] <JEEB> decoding is in always unless you disable the avc decoder, but x264 has to be built with 10bit encoding support [20:36:24 CEST] <hero_biz> ty info [20:36:51 CEST] <furq> libmp3lame encoder AVOptions: [20:36:51 CEST] <furq> -joint_stereo <int> E...A... use joint stereo (from 0 to 1) (default 1) [20:36:55 CEST] <furq> that seems pretty intelligible to me [20:39:41 CEST] <hero_biz> hm... [20:39:57 CEST] <aargh> thanks, furq. i was looking on that option as only a way to specify joint, not to turn it off. [20:40:18 CEST] Action: hero_biz wonders how I can compile x264 and ffmpeg in a way that both support x264 and lavf... [20:40:20 CEST] Action: aargh pats aargh on top of the head..... amusing child [20:40:38 CEST] <JEEB> aargh: btw do you know what joint stereo is? [20:41:10 CEST] <hero_biz> when I want to compile x264, I need ffmeg for lavf support. for compiling ffmpeg I need x264 for libx264... [20:41:28 CEST] <hero_biz> how should I compile that both support both features? [20:41:33 CEST] <aargh> not well enough to explain it, JEEB. but i have heard some people consider it inferior quality [20:42:40 CEST] <JEEB> hero_biz: just build x264 with --disable-lavf and link it against FFmpeg [20:42:40 CEST] <JEEB> done [20:42:41 CEST] <furq> if anything it should be better quality with mp3 [20:43:32 CEST] <JEEB> hero_biz: if you really want to use x264cli with lavf support, you then build x264cli without libraries with lavf enabled [20:43:35 CEST] <JEEB> done [20:43:57 CEST] <hero_biz> ok,ty info :) [20:43:58 CEST] <JEEB> the lavc/lavf thing is from before FFmpeg was easily correctly usable from the command line [20:44:08 CEST] <aargh> furq - you are saying that in my scenario you would expect joint to be a better output option? [20:44:34 CEST] <JEEB> "Some early MP3 encoders didn't make ideal decisions about what mode to use from frame to frame in joint stereo files, or how much bandwidth to allocate to encoding the side channel. This led to a widespread but mistaken belief that an abundance of M/S frames, or the use of joint stereo in general, always negatively impacts channel separation and other measures of audio quality. This is not an issue with mode [20:44:40 CEST] <JEEB> rn encoders. Modern, optimized encoders will switch between mid-side coding or simple stereo coding as necessary, depending on the correlation between the left and right channels, and will allocate channel bandwidth appropriately to ensure the best mode is used for each frame." [20:44:44 CEST] <furq> with a cbr encode from mp2 i wouldn't expect there to be any difference at all [20:44:56 CEST] <hero_biz> btw JEEB, is it possible for x264 to use static libraries of lavf? or it only use dynamic ones? [20:45:04 CEST] <furq> but joint stereo should provide identical quality at a lower bitrate [20:45:10 CEST] <furq> s/cbr/256k cbr/ [20:45:17 CEST] <JEEB> hero_biz: of course it is possible to link static lavc/lavf against x264 [20:45:21 CEST] <JEEB> *x264cli [20:46:01 CEST] <hero_biz> ty :) [20:47:03 CEST] <aargh> hmm, obviously i was not aware of this. i assumed conversion to joint would open up possibility of translation error [20:47:23 CEST] <JEEB> anyways, you're re-encoding lossy mpeg-1 part 2 [20:47:30 CEST] <furq> it does in theory but it's not an issue with a good mp3 encoder [20:47:32 CEST] <JEEB> which by itself makes no sense [20:47:35 CEST] <furq> and lame is a very good mp3 encoder [20:48:11 CEST] <furq> there's a reason why joint stereo is the default [20:48:52 CEST] <aargh> yeah, i'm doing it for someone who has an old mp3 player that doen't seem to recognize mp2 [20:49:21 CEST] <aargh> i'll go with the joint then. thanks [20:49:59 CEST] <aargh> got to run.... thanks again for the help, furq and JEEB [21:23:05 CEST] <massimodipierro> hello everybody. new here. I have a question. Has anybody used ffmpeg with Mobotix MxPEG files? Is there any documentation about ffmpeg supporting this format. The Mobotix site claims ffmpeg supports it but I did not see any proof on the ffmpeg side. [21:23:39 CEST] <BtbN> Well, does it work? [21:24:25 CEST] <massimodipierro> I have not tried it. First I would like to know if there is an official stand on it. [21:24:40 CEST] <Anoia> when I looked at mxpeg, it was JPEG with a different chunking [21:25:09 CEST] <massimodipierro> yes but they claim to compress in time too and not in space. [21:25:33 CEST] <BtbN> So... like every normal video codec? [21:25:52 CEST] <JEEB> lol time and space. just call it intra and inter coding :V [21:26:17 CEST] <massimodipierro> Hey. I am a physicist. Always time and space. [21:26:28 CEST] <JEEB> yes, but you know... video compression :P [21:26:34 CEST] <massimodipierro> OK [21:26:50 CEST] <JEEB> intra is within something, inter is between things [21:27:09 CEST] <massimodipierro> So back to my question. Has anybody tried it? Is there any thing the docs that mentioned this file format? [21:27:12 CEST] <JEEB> aka intra coding codes whatever is being coded within that thing, and inter coding can use other things to code what it is coding :P [21:27:24 CEST] <JEEB> massimodipierro: pretty sure people don't give a damn about that proprietary format in general [21:27:29 CEST] <JEEB> thus you will have to get a sample and test [21:27:33 CEST] <JEEB> otherwise nothing can be said [21:27:52 CEST] <massimodipierro> That's fair. that's what I expected. [21:28:02 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9d09ebf1ed489b26d2bb095490… [21:28:07 CEST] <JEEB> there's a demuxer for their container [21:28:13 CEST] <JEEB> from 2010 [21:28:35 CEST] <JEEB> but nothing is found with "mobotix" as a search term otherwise from the git history [21:29:40 CEST] <massimodipierro> That is a good sign. I will give it a try. [21:29:52 CEST] <massimodipierro> At least there is hope. :-) [21:29:57 CEST] <massimodipierro> Thank you [21:39:28 CEST] <Rene_> hey guys [21:39:58 CEST] <Rene_> rasample audio in ffmpeg in c [21:40:37 CEST] <Rene_> does anyone know how to do? [21:41:00 CEST] <JEEB> two libraries are available for that [21:41:19 CEST] <JEEB> libavresample which is both in libav and ffmpeg, and libswresample which is only in ffmpeg [21:41:27 CEST] <JEEB> both have very similar APIs [21:41:40 CEST] <JEEB> I'm pretty sure there's an example in using one of them in the docs :P [21:42:42 CEST] <furq> http://www.ffmpeg.org/doxygen/trunk/resampling__audio_8c_source.html [21:42:47 CEST] <hero_biz> I want to compile ffmpeg with these options: --enable-openssl --enable-libfdk-aac --enable-libmp3lame --enable-libopus --enable-avisynth --enable-libx264 --enable-libvpx --enable-libass --enable-libfreetype --enable-libvorbis --enable-libtheora --enable-libxvid [21:43:06 CEST] <hero_biz> any other options is recommanded for enabling? [21:43:42 CEST] <JEEB> I bet you don't even use half of those [21:43:59 CEST] <JEEB> just build shit with what you're actually using [21:44:05 CEST] <hero_biz> I added some for their decoders [21:44:18 CEST] <JEEB> like literally one I see [21:44:36 CEST] <Rene_> I can send you my code? For already I tried to do and I am not knowing where to draw the function of ffmpeg to do the exchange format [21:44:45 CEST] <JEEB> since lavc supports aac decoding, mp3 decoding, opus decoding, vp8/9 decoding, vorbis decoding, theora decoding, mpeg-4 part 2 decoding [21:44:52 CEST] <JEEB> without any extra libs [21:45:09 CEST] <JEEB> ok, I can't see a single one :P [21:45:39 CEST] <Rene_> http://pastebin.com/qCHBhZdb [21:45:46 CEST] <hero_biz> but it is said that vorbis support is primitive.that's why I added. [21:45:52 CEST] <JEEB> *encoding* [21:45:52 CEST] <furq> does it actually use any of those libs for decoding if they're available [21:45:53 CEST] <hero_biz> I can remove easy :P [21:46:06 CEST] <TD-Linux> yeah if you plan on encoding a lot of stuff then that's fine [21:46:09 CEST] <JEEB> vorbis *encoder* in libavcodec is fucking atrocious [21:46:33 CEST] <JEEB> probably somewhere worse than the libavcodec WMA encoder [21:50:58 CEST] <hero_biz> jeeb: I was thinking if I should add --enable-libtesseract to support ocring subtitles... [21:51:17 CEST] <JEEB> suit yourself [21:51:33 CEST] <hero_biz> is it usefull? [21:53:38 CEST] <Rene_> JEEB you looked? [21:53:48 CEST] <yongyung> I want to decode a 44.1khz mp3 file to a 48khz wav file. Tried it with -r:a 48000 but the output wav is still 44.1khz. How do I do it? :/ [21:54:13 CEST] <JEEB> Rene_: no. I was going to write that if you have absolutely no idea, you should look into getting paid help for your application [21:54:55 CEST] <yongyung> okay -ra worked lmao... all the other options were converted to q:a, b:a c:a format, but I guess not r:a [22:42:28 CEST] <kagami_> Hi. Does anyone know why mpdecimate doesn't actually want to drop frames? I have sequence of 8 frames like this: A A A B B B C C and want to get A B C. I run ffmpeg like this "ffmpeg -i t.y4m -vf mpdecimate -y t2.y4m" and still get 8 frames in output. Though I can see "dup=5 drop=0" in ffmpeg's output. [23:02:31 CEST] <durandal_1707> Perhaps because framerate is same ? [23:04:22 CEST] <kagami_> durandal_1707: thanks, you are right, it works with "-r 8". But how can I know target framerate in general case? [23:05:50 CEST] <pamra> hi, can anyone tell me how to generate HLS variant playlist file with ffmpeg? [23:33:02 CEST] <onefix> I have a project I'm wanting to do, and I just wanted to make sure that I'm not reinventing the wheel before I jump into it [23:42:20 CEST] <durandal_1707> onefix: what project? [23:59:49 CEST] <onefix> My plan is to run FFmpeg on a small, cheap device (like the $9 CHIP) ... write a script to split a file [00:00:00 CEST] --- Thu Oct 22 2015

1 0